Just noticed that I sent this to Greg only... Gerd From: gpetermann_muenchen@hotmail.com To: gdt@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@ir.bbn.com To: gpetermann_muenchen@hotmail.com CC: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] mkgmap in NYC Date: Mon, 20 Oct 2014 08:37:36 -0400
Gerd Petermann <gpetermann_muenchen@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 :-)
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@hotmail.com> wrote:
Just noticed that I sent this to Greg only...
Gerd
------------------------------ From: gpetermann_muenchen@hotmail.com To: gdt@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@ir.bbn.com To: gpetermann_muenchen@hotmail.com CC: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] mkgmap in NYC Date: Mon, 20 Oct 2014 08:37:36 -0400
Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thanks Ben. I'll try it out next week. On Fri, Oct 24, 2014 at 4:52 PM Ben Konrath <ben@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@hotmail.com> wrote:
Just noticed that I sent this to Greg only...
Gerd
------------------------------ From: gpetermann_muenchen@hotmail.com To: gdt@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@ir.bbn.com To: gpetermann_muenchen@hotmail.com CC: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] mkgmap in NYC Date: Mon, 20 Oct 2014 08:37:36 -0400
Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@gmail.com Date: Sat, 25 Oct 2014 00:29:18 +0000 To: mkgmap-dev@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@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@hotmail.com> wrote: Just noticed that I sent this to Greg only... Gerd From: gpetermann_muenchen@hotmail.com To: gdt@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@ir.bbn.com To: gpetermann_muenchen@hotmail.com CC: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] mkgmap in NYC Date: Mon, 20 Oct 2014 08:37:36 -0400
Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am Samstag, 25. Oktober 2014, 10:23:13 schrieb Gerd Petermann:
I think we also have to add include 'inc/address'; to the polygon rules. +1
this is my finalize section in polygons for a long time <finalize> # The finalizer section is executed for each element when a rule with an element type matches include '../inc/address'; include '../inc/name' ; IMHO only with this call housenumber routing works correct. Bernd -- amarok2 now playing:
Hi Bernd, sorry, I was wrong (looked at an old map while testing) Bens patch solves the problem with the building in NY, there is no need to include inc/address in polygons for this case. If I got it right, the housenumber code is only interested in streetnames given by mkgmap:street or addr:street. These may also be set in inc/address, but I don't think that this has an effect on the housenumber code. Do you have an example where it is needed ? Gerd
From: weigelt.bernd@web.de To: mkgmap-dev@lists.mkgmap.org.uk Date: Sat, 25 Oct 2014 10:37:45 +0200 Subject: Re: [mkgmap-dev] FW: mkgmap in NYC
Am Samstag, 25. Oktober 2014, 10:23:13 schrieb Gerd Petermann:
I think we also have to add include 'inc/address'; to the polygon rules. +1
this is my finalize section in polygons for a long time
<finalize> # The finalizer section is executed for each element when a rule with an element type matches
include '../inc/address'; include '../inc/name' ;
IMHO only with this call housenumber routing works correct.
Bernd
-- amarok2 now playing:
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Am Samstag, 25. Oktober 2014, 10:57:05 schrieb Gerd Petermann:
If I got it right, the housenumber code is only interested in streetnames given by mkgmap:street or addr:street. These may also be set in inc/address, but I don't think that this has an effect on the housenumber code.
Do you have an example where it is needed ?
Puuh last year i had some troubles with searches, that are solved, when i add this lines to polygons and points. i can't descripe this problems anymore, sorry, maybe something with incorrecct or incomplete boundaries, i have to look in my old mailings to Franco Bernd -- amarok2 now playing:
Am Samstag, 25. Oktober 2014, 11:11:50 schrieb Bernd Weigelt:
i can't descripe this problems anymore, sorry,
Got it, this has historical reasons in the original AIO-Style, my style is a fork with a lot of changes, points, lines and polygons starts with the address actions. i moved them to a single file address, because i want to have only one file and inc folder after your changes to the finalize section i moved most of the inc-files to this section without any problem and leave as it is. Bernd -- amarok2 now playing:
Hi Ben, thanks for the patch. I've committed it with r3338. Gerd Date: Fri, 24 Oct 2014 22:52:27 +0200 From: ben@bagu.org To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] FW: mkgmap in NYC 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@hotmail.com> wrote: Just noticed that I sent this to Greg only... Gerd From: gpetermann_muenchen@hotmail.com To: gdt@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@ir.bbn.com To: gpetermann_muenchen@hotmail.com CC: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] mkgmap in NYC Date: Mon, 20 Oct 2014 08:37:36 -0400
Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Ben, The latest maps you've created are working well - I can find addresses in NYC. The address search isn't quite as fluid as the Garmin maps, but perhaps this is related to how the map file is created. For "311 W 51st St", I must enter in "W 51" in order to find the street. With a Garmin map, I can input '50', and it will show me a list of streets and avenues. I'm not sure how streets names are shortened. In OSM, we have 'West 51st Street' and that becomes 'W 50st St'. However, when it's part of a route, it doesn't get shortened. Hence 'West 178th Street <http://www.openstreetmap.org/way/44763890>' is listed as 'West 178th Street (US 9)'. Since not all West's becomes W, one can't guess correctly which one to use. Sometimes names are shortened too much, as in 'West Lane' becomes 'W Ln', but I can't find any code which is doing this either. I've also been compiling my own map of the northeast, but with less success than when I use your weekly map. The main issue I'm having right now is I can only find cities by searching in all-caps. This is quite odd because the cities are shown in mixed case. If I search for NEW YORK, I'm able to find addresses, just like I can on your map. However, searching for 'New york', 'New York', or 'Ne' yields no results. I've tried including / excluding the "--lower-case" flag, but it makes no difference on my Nuvi 1450. Any idea what is causing the issue with the case while searching? Thanks, Brian On Fri Oct 24 2014 at 4:52:51 PM Ben Konrath <ben@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@hotmail.com> wrote:
Just noticed that I sent this to Greg only...
Gerd
------------------------------ From: gpetermann_muenchen@hotmail.com To: gdt@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@ir.bbn.com To: gpetermann_muenchen@hotmail.com CC: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] mkgmap in NYC Date: Mon, 20 Oct 2014 08:37:36 -0400
Gerd Petermann <gpetermann_muenchen@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Sat, Nov 1, 2014 at 6:03 PM, Brian Egge <brianegge@gmail.com> wrote:
Hi Ben,
The latest maps you've created are working well - I can find addresses in NYC.
The address search isn't quite as fluid as the Garmin maps, but perhaps this is related to how the map file is created. For "311 W 51st St", I must enter in "W 51" in order to find the street. With a Garmin map, I can input '50', and it will show me a list of streets and avenues.
Interesting. I don't know the details of the implementation of the address search in mkgmap so I don't know what the Garmin maps are more flexible. Does anybody have any ideas?
I'm not sure how streets names are shortened. In OSM, we have 'West 51st Street' and that becomes 'W 50st St'. However, when it's part of a route, it doesn't get shortened. Hence 'West 178th Street <http://www.openstreetmap.org/way/44763890>' is listed as 'West 178th Street (US 9)'. Since not all West's becomes W, one can't guess correctly which one to use.
I have some rules in my style file to shorten the names highway=* { name '${name|subst: Street=> St|subst: Avenue=> Ave| ... |subst:Ouest =>O }' } I can give you the whole list I use if you're interested. This rule is in resources/styles/default/lines but I'm not sure why the street name doesn't get shortened when it's part of a route. Sometimes names are shortened too much, as in 'West Lane' becomes 'W Ln',
but I can't find any code which is doing this either.
This is a bug in my implementation of the shortening. Fixing this issue is on my TODO list. I've also been compiling my own map of the northeast, but with less success
than when I use your weekly map. The main issue I'm having right now is I can only find cities by searching in all-caps. This is quite odd because the cities are shown in mixed case. If I search for NEW YORK, I'm able to find addresses, just like I can on your map. However, searching for 'New york', 'New York', or 'Ne' yields no results. I've tried including / excluding the "--lower-case" flag, but it makes no difference on my Nuvi 1450. Any idea what is causing the issue with the case while searching?
I've never seen this. Here are the options that I'm using for splitter / mkgmap. java -Xmx7500M -jar ~/osm/splitter/dist/splitter.jar --geonames-file=~/osm/data/cities1000.zip --precomp-sea=~/osm/data/sea_20141027.zip --output=o5m --mapid=24244000 --max-threads=1 --status-freq=0 --max-areas=50 united-states-141029.o5m java -Xmx7500M -jar -Dlog.config=~/osm/confs/logging.properties ~/osm/mkgmap/dist/mkgmap.jar --latin1 --gmapsupp --index --route --min-size-polygon --series-name="OSM United States 2014.10.29" --family-name="OpenStreetMap United States 2014.10.29" --location-autofill=bounds,is_in,nearest --remove-ovm-work-files --bounds=~/osm/data/bounds_20141027.zip --precomp-sea=~/osm/data/sea_20141027.zip --generate-sea --add-pois-to-areas --process-destination --process-exits --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance --check-roundabout-flares --remove-short-arcs --family-id=24244 --product-id=1 --make-opposite-cycleways --drive-on-right --check-roundabouts --housenumbers -c template.args --description="OSM United States 2014.10.29" Hopefully this will help you out. You should definitely be able to get a usable map for a smaller region of the US. Ben
Hi Brian, Ben Konrath wrote
On Sat, Nov 1, 2014 at 6:03 PM, Brian Egge <
brianegge@
> wrote:
Hi Ben,
The latest maps you've created are working well - I can find addresses in NYC.
The address search isn't quite as fluid as the Garmin maps, but perhaps this is related to how the map file is created. For "311 W 51st St", I must enter in "W 51" in order to find the street. With a Garmin map, I can input '50', and it will show me a list of streets and avenues.
Interesting. I don't know the details of the implementation of the address search in mkgmap so I don't know what the Garmin maps are more flexible. Does anybody have any ideas?
I've tested with MapSource and the map created with r3337 and the default style. I search for a street and type just "51". It shows a list starting with "51st Avenue" "51st Avenue (Ny 25a)" "51st Drive" "51st Road" "51st Street" "52nd Avenue" ... It doesn't contain "West 51st Street". When I enter "West 51" it shows a list starting "West 51st Street" "West 52nd Street" ... Are you sure that you find the right street ? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/mkgmap-in-NYC-tp5820682p5822993.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
I've tested with MapSource and the map created with r3337 and the default style.
Thanks Gird. I'm on a Mac and don't have MacSource. I tried running BaseCamp but I can't get it to load my files. Adding the '--latin1' setting fixed the city search on my Garmin Nuvi. I am still having some boundary issues, but these are caused because I'm trying to create my own boundary file out of just my Northeast US extract. Brian On Tue Nov 04 2014 at 5:00:56 AM GerdP <gpetermann_muenchen@hotmail.com> wrote:
Hi Brian,
Ben Konrath wrote
On Sat, Nov 1, 2014 at 6:03 PM, Brian Egge <
brianegge@
> wrote:
Hi Ben,
The latest maps you've created are working well - I can find addresses in NYC.
The address search isn't quite as fluid as the Garmin maps, but perhaps this is related to how the map file is created. For "311 W 51st St", I must enter in "W 51" in order to find the street. With a Garmin map, I can input '50', and it will show me a list of streets and avenues.
Interesting. I don't know the details of the implementation of the address search in mkgmap so I don't know what the Garmin maps are more flexible. Does anybody have any ideas?
I've tested with MapSource and the map created with r3337 and the default style. I search for a street and type just "51". It shows a list starting with "51st Avenue" "51st Avenue (Ny 25a)" "51st Drive" "51st Road" "51st Street" "52nd Avenue" ... It doesn't contain "West 51st Street".
When I enter "West 51" it shows a list starting "West 51st Street" "West 52nd Street" ...
Are you sure that you find the right street ?
Gerd
-- View this message in context: http://gis.19327.n5.nabble. com/mkgmap-in-NYC-tp5820682p5822993.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Ben Konrath -
Bernd Weigelt -
Brian Egge -
Gerd Petermann -
GerdP