[mkgmap-dev] FW: mkgmap in NYC

Sat Oct 25 09:23:13 BST 2014

Hi Brian,

I fear the patch doesn't solve the problem, because the problem is somewhere else.

Here is what I found:
1) The way 265329468 is a polygon, the rule that matches is 
(building=* | amenity=*) & area!=no & amenity!=grave_yard [0x13 resolution 24]  
in the polygons file.
The finalize section of the polygons file doesn't contain the 
inc/address
because we think that polygons don't need address info. On the other hand,
the --housenumber option requires the info.

I think we also have to add 
include 'inc/address'; 
to the polygon rules.

Gerd

From: brianegge at gmail.com
Date: Sat, 25 Oct 2014 00:29:18 +0000
To: mkgmap-dev at lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] FW: mkgmap in NYC

Thanks Ben. I'll try it out next week. 
On Fri, Oct 24, 2014 at 4:52 PM Ben Konrath <ben at bagu.org> wrote:
Brian: Address search in the US map from 2014.10.23 should now works for New York. I've tested it in simulation mode but it would be great if you could test it out to confirm it's working as well. Thanks for pointing out the issue. 

Gerd: I've attached a patch that I'm using to fix the New York address search. I've also included a small change in Canada and the US which removes the 'City of' in front of city names when it's there. Nobody uses the official 'City of' form of city names so it doesn't make sense to have it in the default style. Let me know if there are any issues.

Thanks, Ben

On Tue, Oct 21, 2014 at 11:39 AM, Gerd Petermann <gpetermann_muenchen at hotmail.com> wrote:

Just noticed that I sent this to Greg only...

Gerd

From: gpetermann_muenchen at hotmail.com
To: gdt at ir.bbn.com
Subject: RE: [mkgmap-dev] mkgmap in NYC
Date: Tue, 21 Oct 2014 09:25:45 +0200

Hi Greg,

I thought about this. The precompiled bounds contain the needed info,
it is the LocationHook that fills the tags like mkgmap:admin_level6.
The LocationHook uses the --name-tag-list option to decide which
value is used.
It would be possible to fill an additional set of tags like
mkgmap:admin_level-alt-2 .. mkgmap:admin_level-alt-11,
but I don't see much use in this.
If I got it right, all we need for New York are a five rules like this:
mkgmap:country=USA & mkgmap:city!=* & mkgmap:admin_level5=New York City & 
mkgmap:admin_level6=New York County { set mkgmap:city=Manhattan } 
mkgmap:country=USA & mkgmap:city!=* & mkgmap:admin_level5=New York City & 
mkgmap:admin_level6=Kings County { set mkgmap:city=Brooklyn } 
...

With the additional alt_name values it would be one rule like this:
mkgmap:country=USA & mkgmap:city!=* & mkgmap:admin_level5=New York City {set mkgmap:city='${mkgmap:admin_level-alt-6}' }
(note that the rule doesn't check if the alt-name is filled)

Are there more places where this could be used?

Gerd

> From: gdt at ir.bbn.com
> To: gpetermann_muenchen at hotmail.com
> CC: mkgmap-dev at lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] mkgmap in NYC
> Date: Mon, 20 Oct 2014 08:37:36 -0400
> 
> 
> Gerd Petermann <gpetermann_muenchen at hotmail.com> writes:
> 
> > [1] This is because we use so called "precompiled boundaries", and changing them like that would
> > require hard coded rules in the source.
> 
> That might be the right place to fix this.  Unfortunately New York
> really is a weird case (I don't know of any other such case in the US),
> but arguably it's important because a lot of people live there :-)

_______________________________________________

mkgmap-dev mailing list

mkgmap-dev at lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________

mkgmap-dev mailing list

mkgmap-dev at lists.mkgmap.org.uk

http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20141025/35777851/attachment.html>