[mkgmap-dev] Slash character in name
For destinations or names with more than one line, it's common to have each line separated by a forward slash. I've tried to customize my map to replace semicolon with slash, but the slash does not appear. Is the slash an allowed character in a name or destination? I'm using the Latin1 character set. Brian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Exclude POIs from index
I've tried without success to have the unnamed POI's show their OSM id. This would make it easier to assign names where I know them. Unfortunately, I have not had any success in creating a rule to do this. Any ideas on how to do this? On Mon, Aug 24, 2015 at 8:34 PM Steve Sgalowski steve.sgalow...@gmail.com wrote: would not you be wise to construct your own style / poi file , then thoes pois you do not need are not added to your map ? Stephen On Tue, Aug 25, 2015 at 10:16 AM, Dave Swarthout daveswarth...@gmail.com wrote: When I search for All POIs on my Garmin Montana I get many useless unnamed POIs, even power poles, barriers, houses, etc. Is there some way to tell mkgmap to exclude such POIs from its search results? -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ 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
[mkgmap-dev] Street labels
Some change between 3434M and HEAD caused my street labels to change. With 3434M, my GPS typically displays something like 'Main Street (CT 35)', now it only shows '35'. Basically, every street/highway with a shield displays only the number of the shield instead of displaying the name. I'm not sure exactly which change caused this, but I can bisect it if needed. Brian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] patches
Moving the code to github would allow users to submit pull requests. It wouldn't produce a binary, but it would make the patches much more manageable. On Fri, Jan 30, 2015 at 5:45 AM GerdP gpetermann_muenc...@hotmail.com wrote: Hi Steve, again and again users report that they don't know what to do with patches. Do you think it would be possible to implement a service on http://www.mkgmap.org.uk/ which allows to upload a patch to get a binary? Gerd -- View this message in context: http://gis.19327.n5.nabble. com/patches-tp5831932.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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Commuter rail stations
When I look at POIs with a Garmin map, I have a category for 'Suburban Rail Station'. In the NYC area, there are hundreds of commuter rail stations and a handful of regional stations. Having the two listed separately in the POI search is useful, as usually you are searching for one or the other. When using an mkgmap, it only has the single railway station type. I believe the suburban railway stations can be tagged with commuter=yes, but I do not know what Garmin hex code causes this category to appear. Any idea what the code is or how to figure it out? Brian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] multi-word street search
This patch is interesting, although I don't think I would use it the way it is, it does give me some ideas for adding other road aliases. Many roads have an alt_name, which would be useful to index. I.e, Avenue of the Americas and 6th Avenue are the same. Ben has some patches for abbreviating street names, which works but you have to remember to use them when using address search. I.e., I'd like for both W 43rd St and West 43rd Street to be in the index. On Sat Dec 06 2014 at 7:27:35 AM Colin Smale colin.sm...@xs4all.nl wrote: Andrzej, I couldn't find the description of the problem this aims to fix but if I am guessing right it will add individual words from street names into the index so they can be found when searching for an address? Will this not add millions of entries for The and Road and similar articles, prepositions and road types? It will depend on the language as to what is written separately and what is joined to other words. In English/French everything is separate but in Dutch/German the rules are of course difference. To start with, does anyone have any idea how we could implement a language-dependent stop-word list (words to be ignored completely)? Colin On 2014-12-06 10:12, Minko wrote: Andrzej, I hope this will be committed soon, would be a great improvement for mkgmap search. Even better if it also works for address search. Hi, I have decided to try simple solution for this problem. I have modified addStreet() procedure in file imgfmt\app\mdr\MDRFile.java. While I don't know all ramification of this change, search seems to work as expected, see attached picture form Mapsource. Attached patch is created half-manually, I hope it will work in your environment. -- Best regards, Andrzej ___ mkgmap-dev mailing listmkgmap-...@lists.mkgmap.org.ukhttp://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
Re: [mkgmap-dev] relation associatedStreet
The use of relations is often required when the house/building is far away from the street. Here's an example of a building which is 700m away from the associated street: http://www.openstreetmap.org/way/75194717#map=16/41.3786/-73.5284 It probably needs a relation setup as most routers will not search far enough for the street (or it may be on another tile). On Mon Dec 01 2014 at 6:24:20 AM Andrzej Popowski po...@poczta.onet.pl wrote: Hi Gerd, The current algo searches for the closest street Doesn't mkgmap verify street names of an address and a way? The problem is that relation can be created *instead of* putting addr:street to node or building. See real examples and look at house members: http://www.openstreetmap.org/relation/65769 http://www.openstreetmap.org/relation/31709 I have compiled area around relation 65769 and there is no Berngariusstrasse 2, 5, 6, 8 in address search. The only house number is 1, in which case building include addr:street tag. -- Best regards, Andrzej ___ 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
Re: [mkgmap-dev] Driving on Trail
Hi Gerd, Here's an example area: http://www.openstreetmap.org/way/305805056#map=19/41.27951/-73.49803 The sidewalks are generally parallel to the road, but are sometimes set back quite a way, as is the case on Main Street. The planned route won't send me onto a sidewalk, but if I'm driving without a route set, it will try to place me onto the nearest street. I thought the following rule would disallow this when not in pedestrian mode: highway=footway|highway=path|highway=steps [0x16 road_class=0 road_speed=0 resolution 23] I haven't tried putting the nuvi into pedestrian mode, but I'm assuming it would try to route you on these types of roads. Brian On Sun Nov 16 2014 at 2:59:56 PM GerdP gpetermann_muenc...@hotmail.com wrote: Hi Brian, I never saw this text on my Oregon. If I got you right, you have two routable lines for the same OSM way, the device routes you over the way for the car, but it displays the info for the sidewalk. Could this be the reason? Gerd Brian Egge wrote Frequently in areas where sidewalks are drawn, my GPS decides we are driving on the sidewalk and not on the road. When this happens it displays 'Driving on Trail'. I've verified the footways are tagged, and I've viewed the default style rule. I've double checked to make sure my GPS is in driving mode, which it is. I can't figure out anyway to have it ignore pedestrian routes, short of removing them from the map. Any suggestions on how to fix this issue? Brian ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble. com/Driving-on-Trail-tp5824491p5824534.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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Driving on Trail
Frequently in areas where sidewalks are drawn, my GPS decides we are driving on the sidewalk and not on the road. When this happens it displays 'Driving on Trail'. I've verified the footways are tagged, and I've viewed the default style rule. I've double checked to make sure my GPS is in driving mode, which it is. I can't figure out anyway to have it ignore pedestrian routes, short of removing them from the map. Any suggestions on how to fix this issue? Brian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] RoadDef patch
Hi Gerd,
In Steve’s stack trace it shows RoadMap is being used by a LinkedHashMap in
TableA. A linked hash map maintains an ordered list of nodes, which is the same
in every JDK version. You can set a breakpoint in CompareTo and run the
SimpleRouteTest and see that it’s being used.
The TableA addArc method is trying to only add unique arcs. They containsKey
method at present will never return true, but it’s clear from the code that
there are case where it should return true. My change results in a slight
reduction of the NOD section, which seems to make sense.
The sole purpose of the Hash seems to be preventing multiple, duplicate arcs
from being created on the same RouteNode.
In MapNode, RoadDef is constructed with the osm id of the way, but when
constructed from the NETFileReader, the id is the record number, which will be
unique.
If every RoadDef should be unique, then one should not implement
equals/hashCode/compareable, and instead use the default implementations from
Object. However, one would then need to remove the LinkedHashMap from TableA
and replace it with something like Array.
Brian
When RoadDefs are created in NETFileReader, a unique id is generated for each
RoadDef.
On Nov 6, 2014, at 3:34 AM, Gerd Petermann gpetermann_muenc...@hotmail.com
wrote:
Hi Brian,
thanks for the patch. If I got it right, the compareTo() methid is obsolete
as we do no longer sort RoadDef instances anywhere. So,
it would be easier to remove the Comparable attribute from the class
public class RoadDef /*implements ComparableRoadDef*/ {
and remove the compareTo() method.
You are right regarding the hashCode() method, but I think
we should not use the fields id + name to implement it.
A style may add the same OSM way as a routable line multiple times,
in that case these two fields are equal.
A typical map has less than 100.000 RoadDef instances, so I see no problem
to add an int (or long) field like roadId which is filled with a unique value
and use that in hashCode().
What do you think?
Gerd
From: briane...@gmail.com
Date: Wed, 5 Nov 2014 22:28:38 -0500
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] RoadDef patch
I’m not sure what the concurrency issue is related to this class, but it
seems to have some problems around equality. First, it’s being used in a
HashMap, which means both equals and hashCode need to be implemented. Second,
the compareTo was using an unimplemented hashCode, which results in random
sorting and inability to find two identical objects.
I’m not sure I understand all the details of what RoadDef does, but I’ve
fixed up the basic methods in the class to be consistent and added a test
case around those methods.
Brian
___ mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
Re: [mkgmap-dev] RoadDef patch
Hi Gerd,
I was completely wrong about the compareTo. Thanks for pointing that out.
I agree the compareTo method should be removed. TableA should really be
using an IdentityLinkedHashMap, but this doesn't exist in the standard jdk.
Thanks,
Brian
On Thu, Nov 6, 2014 at 9:45 AM Gerd Petermann
gpetermann_muenc...@hotmail.com wrote:
Hi Brian,
I read again your posts. I think you got something wrong.
I think we allow to create multiple instances of RoadDef
having the same values in the id field and in the name field.
This happens when a style adds the same OSM way
with different routing attributes, e.g. one way for bicycles
and one for cars.
A public available style that does this is Minkos:
http://mijndev.openstreetmap.nl/%7Eligfietser/openfietsmap/Scripts/
I think your patch disables this feature.
Gerd
--
From: briane...@gmail.com
Date: Thu, 6 Nov 2014 06:34:43 -0500
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] RoadDef patch
Hi Gerd,
In Steve’s stack trace it shows RoadMap is being used by a LinkedHashMap
in TableA. A linked hash map maintains an ordered list of nodes, which is
the same in every JDK version. You can set a breakpoint in CompareTo and
run the SimpleRouteTest and see that it’s being used.
The TableA addArc method is trying to only add unique arcs. They
containsKey method at present will never return true, but it’s clear from
the code that there are case where it should return true. My change results
in a slight reduction of the NOD section, which seems to make sense.
The sole purpose of the Hash seems to be preventing multiple, duplicate
arcs from being created on the same RouteNode.
In MapNode, RoadDef is constructed with the osm id of the way, but when
constructed from the NETFileReader, the id is the record number, which will
be unique.
If every RoadDef should be unique, then one should not implement
equals/hashCode/compareable, and instead use the default implementations
from Object. However, one would then need to remove the LinkedHashMap from
TableA and replace it with something like Array.
Brian
When RoadDefs are created in NETFileReader, a unique id is generated for
each RoadDef.
On Nov 6, 2014, at 3:34 AM, Gerd Petermann
gpetermann_muenc...@hotmail.com wrote:
Hi Brian,
thanks for the patch. If I got it right, the compareTo() methid is obsolete
as we do no longer sort RoadDef instances anywhere. So,
it would be easier to remove the Comparable attribute from the class
public class RoadDef /*implements ComparableRoadDef*/ {
and remove the compareTo() method.
You are right regarding the hashCode() method, but I think
we should not use the fields id + name to implement it.
A style may add the same OSM way as a routable line multiple times,
in that case these two fields are equal.
A typical map has less than 100.000 RoadDef instances, so I see no problem
to add an int (or long) field like roadId which is filled with a unique
value
and use that in hashCode().
What do you think?
Gerd
From: briane...@gmail.com
Date: Wed, 5 Nov 2014 22:28:38 -0500
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] RoadDef patch
I’m not sure what the concurrency issue is related to this class, but it
seems to have some problems around equality. First, it’s being used in a
HashMap, which means both equals and hashCode need to be implemented. Second,
the compareTo was using an unimplemented hashCode, which results in random
sorting and inability to find two identical objects.
I’m not sure I understand all the details of what RoadDef does, but I’ve
fixed up the basic methods in the class to be consistent and added a test
case around those methods.
Brian
___ 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
___
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] patches
Thanks Ben for the hints with the boundary files. It looks like they are
published weekly on the site you linked to. I modify my build script to
download them when they change:
wget -N --user-agent=www.theeggeadventure.com
http://osm2.pleiades.uni-wuppertal.de/sea/latest/sea.zip
wget -N --user-agent=www.theeggeadventure.com
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip
http://osm2.pleiades.uni-wuppertal.de/bounds/latest/bounds.zip
The NYC addresses are working well. I have a minor correction as follows:
Index: resources/styles/default/inc/address
===
--- resources/styles/default/inc/address(revision 3342)
+++ resources/styles/default/inc/address(working copy)
@@ -66,8 +66,11 @@
# New York City has different admin levels than the rest of the US.
# https://wiki.openstreetmap.org/wiki/United_States_admin_level
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='New York County' { set mkgmap:city='New York' }
-mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Bronx County' { set mkgmap:city='The Bronx' }
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Bronx County' { set mkgmap:city='Bronx' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Kings County' { set mkgmap:city='Brooklyn' }
+# Queens uses neighborhoods for city in postal addresses
+# http://en.wikipedia.org/wiki/List_of_Queens_neighborhoods
+mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Queens County' mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8}' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Queens County' { set mkgmap:city='Queens' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level5='New York City'
mkgmap:admin_level6='Richmond County' { set mkgmap:city='Staten Island' }
mkgmap:country=USA mkgmap:city!=* mkgmap:admin_level8=* { set
mkgmap:city='${mkgmap:admin_level8|subst:City of }’ }
One always says ‘The Bronx’, but in addresses is it’s simply Bronx. For Queens,
the neighborhood is used in mailing addresses, though sometimes people will use
‘Queens’ instead. If you look up 40-01 43 AVENUE” www.usps.com
http://www.usps.com/, it says the standardized address is:
4001 43RD AVE
SUNNYSIDE NY 11104-3205
But, the school board
http://schools.nyc.gov/SchoolPortals/30/Q150/default.htm lists it’s address
as:
40-01 43 AVENUE
QUEENS, NY11104
While the school itself https://sites.google.com/site/ps150queens/ says it’s
address is:
40-01 43 Avenue Sunnyside, NY 11104
If I’m given an address, most likely it will have the neighborhood in it, and
not ‘Queens’.
Here’s an alternative patch to pick up place_name:
Index: src/uk/me/parabola/mkgmap/build/LocatorUtil.java
===
--- src/uk/me/parabola/mkgmap/build/LocatorUtil.java(revision 3342)
+++ src/uk/me/parabola/mkgmap/build/LocatorUtil.java(working copy)
@@ -28,7 +28,7 @@
.compile([,\\s]+);
public static ListString getNameTags(Properties props) {
- String nameTagProp = props.getProperty(name-tag-list, name);
+ String nameTagProp = props.getProperty(name-tag-list,
name,place_name);
return Arrays.asList(COMMA_OR_SPACE_PATTERN.split(nameTagProp));
}
Can we reduce the logging from the RuleFileReader by default? It produces a
huge amount of output which probably isn’t useful unless you are debugging the
rule reader.
Index: src/uk/me/parabola/mkgmap/osmstyle/RuleFileReader.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/RuleFileReader.java (revision 3342)
+++ src/uk/me/parabola/mkgmap/osmstyle/RuleFileReader.java (working copy)
@@ -243,7 +243,7 @@
* from the expression.
*/
private void saveRule(TokenScanner scanner, Op op, ActionList actions,
GType gt) {
- log.info(EXP, op, , type=, gt);
+ log.debug(EXP, op, , type=, gt);
// check if the type definition is allowed
if (inFinalizeSection gt != null)
Here’s a bit friendlier documentation:
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 3342)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy)
@@ -926,7 +926,10 @@
}
else {
mp = new MapPoint();
- log.warn(Motorway exit, node.getName(), ( +
node.getLocation().toOSMURL() + ) has no
Re: [mkgmap-dev] patches
I agree it should be fixed in OSM. I recently submitted a patch to JOSM to
flag this in the validation.
https://josm.openstreetmap.de/ticket/10693
There are still about 25,000 objects with place_name in them:
https://taginfo.openstreetmap.org/keys/place_name
That's too many for me to fix, and I'm not keen on trying to do a mass tag
change.
Since this tag is widely used for cities, I'd like for mkgmap to read it
in.
On Wed Nov 05 2014 at 9:45:37 PM Nelson A. de Oliveira nao...@gmail.com
wrote:
On Thu, Nov 6, 2014 at 12:13 AM, Brian Egge briane...@gmail.com wrote:
public static ListString getNameTags(Properties props) {
- String nameTagProp = props.getProperty(name-tag-list, name);
+ String nameTagProp = props.getProperty(name-tag-list,
name,place_name);
place_name is a key that should be fixed in OSM itself:
http://wiki.openstreetmap.org/wiki/Proposed_features/drop_
recommendation_for_place_name
___
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] RoadDef patch
I’m not sure what the concurrency issue is related to this class, but it seems to have some problems around equality. First, it’s being used in a HashMap, which means both equals and hashCode need to be implemented. Second, the compareTo was using an unimplemented hashCode, which results in random sorting and inability to find two identical objects. I’m not sure I understand all the details of what RoadDef does, but I’ve fixed up the basic methods in the class to be consistent and added a test case around those methods. RoadDef.patch Description: Binary data Brian___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: mkgmap in NYC
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_muenc...@hotmail.com wrote: Hi Brian, Ben Konrath wrote On Sat, Nov 1, 2014 at 6:03 PM, Brian Egge lt; brianegge@ gt; 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] FW: mkgmap in NYC
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 b...@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_muenc...@hotmail.com wrote:
Just noticed that I sent this to Greg only...
Gerd
--
From: gpetermann_muenc...@hotmail.com
To: g...@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: g...@ir.bbn.com
To: gpetermann_muenc...@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_muenc...@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
Re: [mkgmap-dev] Building northeast map
On Thu Oct 30 2014 at 6:24:48 AM Andrzej Popowski po...@poczta.onet.pl
wrote:
Hi,
I fear the meanings of the --country-xxx options are not well
documented.
I have once tried to find what are they for but failed. I would suggest
to not use --country-xxx or --region-xxx in command line options. I
think the real definitions are inside style, see include/address file:
# United States
mkgmap:country=USA mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
I think that setting country or region in options can damage these
rules. Or create some inconsistency in map.
--
Best regards,
Andrzej
___
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
Re: [mkgmap-dev] Building northeast map
Looking closer, I think it should be able to pick up the country from the
is_in:country tag, which is often set on cities and states.
The address rules contain:
# first set the country code
mkgmap:country!=* mkgmap:admin_level2=* { set
mkgmap:country='${mkgmap:admin_level2}' }
mkgmap:country!=* addr:country=* { set mkgmap:country='${addr:country}' }
mkgmap:country!=* is_in:country=* { set mkgmap:country='${is_in:country}'
}
An example city is Danbury:
http://www.openstreetmap.org/way/33271879
which has the country set:
is_in:country
http://wiki.openstreetmap.org/wiki/Key:is%20in:country?uselang=en-USUSA
is_in:country_code
http://wiki.openstreetmap.org/wiki/Key:is%20in:country%20code?uselang=en-US
US
I think it should be picking up the country from these tags. I'll have to
run some tests to see why this isn't happening.
Thanks.
Brian
On Thu Oct 30 2014 at 8:23:54 AM Brian Egge briane...@gmail.com wrote:
On Thu Oct 30 2014 at 6:24:48 AM Andrzej Popowski po...@poczta.onet.pl
wrote:
Hi,
I fear the meanings of the --country-xxx options are not well
documented.
I have once tried to find what are they for but failed. I would suggest
to not use --country-xxx or --region-xxx in command line options. I
think the real definitions are inside style, see include/address file:
# United States
mkgmap:country=USA mkgmap:region!=* mkgmap:admin_level4=* { set
mkgmap:region='${mkgmap:admin_level4}' }
I think that setting country or region in options can damage these
rules. Or create some inconsistency in map.
--
Best regards,
Andrzej
___
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
Re: [mkgmap-dev] Building northeast map
Hi Gerd,
I found the first issue why so many cities were missing. It turns out in my
area many boundaries contain 'place_name' instead of 'name'. Examples:
http://overpass-turbo.eu/s/5HL
I realize I could add this tag to name-tag-list, but i think it would be better
to have it searched as a last resort. Thus, I propose the following patch:
Index:
src/uk/me/parabola/mkgmap/reader/osm/boundary/BoundaryLocationPreparer.java
===
--- src/uk/me/parabola/mkgmap/reader/osm/boundary/BoundaryLocationPreparer.java
(revision 3341)
+++ src/uk/me/parabola/mkgmap/reader/osm/boundary/BoundaryLocationPreparer.java
(working copy)
@@ -69,6 +69,9 @@
int admLevel = getAdminLevel(tags);
boolean isISO = false;
String name = getName(tags);
+ if (name == null) {
+ log.warn(No name found for boundary, tags);
+ }
if (locator != null){
if (admLevel == 2) {
String isoCode = locator.addCountry(tags);
@@ -142,6 +145,11 @@
}
return nameParts[0].trim().intern();
}
+ String place_name = tags.get(place_name);
+ if (place_name != null) {
+ log.warn(Boundry has controversial place_name:,
place_name, tags,
http://wiki.openstreetmap.org/wiki/Proposed_features/drop_recommendation_for_place_name
http://wiki.openstreetmap.org/wiki/Proposed_features/drop_recommendation_for_place_name);
+ return place_name;
+ }
return null;
}
Secondly, while I don't have a complete admin_level2 in my boundary file, most
city, county and state boundaries contain is_in tags. For example, Danbury
(http://www.openstreetmap.org/way/33271879
http://www.openstreetmap.org/way/33271879), contains
is_in:country
http://wiki.openstreetmap.org/wiki/Key:is%20in:country?uselang=en-USUSA
is_in:state
http://wiki.openstreetmap.org/wiki/Key:is%20in:state?uselang=en-US
Connecticut
With these tags, I should be able to set state and country information even if
I don't have those boundaries explicitly loaded. I was thinking this extra
information could be added to the BoundaryLocationInfo class, much like how the
zip code is today. What do you think about that approach?
Brian
On Oct 30, 2014, at 4:00 AM, Gerd Petermann gpetermann_muenc...@hotmail.com
wrote:
Hi Brian,
I see.
I fear the meanings of the --country-xxx options are not well documented.
If I got it right, they have an influence on the address search indexes, but
they have no
meaning for the rules in the style.
Maybe your problem could be solved with an
additional line in the address rule. Something like this
mkgmap:admin_level5='New York City' mkgmap:admin_level2!=* { set
mkgmap:admin_level2='USA' }
as a first line in inc/address.
Another option would be to change the LocationHook to optionally use the
values given with --country-xxx to fill the mkgmap:admin_level2 tag.
Gerd
From: briane...@gmail.com
Date: Thu, 30 Oct 2014 02:38:17 +
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: Re: [mkgmap-dev] Building northeast map
Thanks Gerd,
I've been adding/fixing city boundaries in my area, so I'm trying to create
my own bounds file. If an admin_level2 can't be found, does it use the
--country-abbr option?
Brian
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Building northeast map
Thanks Gerd, I've been adding/fixing city boundaries in my area, so I'm trying to create my own bounds file. If an admin_level2 can't be found, does it use the *--country-abbr *option? Brian On Wed Oct 29 2014 at 3:28:37 AM Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Brian, I think your problem is caused by the fact that your input file doesn't contain the boundary for the USA. That's the reason for the --bounds option, the typical use is to download the boundaries for planet from e.g. http://www.mkgmap.org.uk/download/mkgmap.html If you want to create your own bounds file, you should make sure to have complete continents. The style rules in the inc/address file expect that mkgmap:admin_level2=USA but this will not happen if the bounds file doesn't contain enough of the boundary. Gerd -- From: briane...@gmail.com Date: Wed, 29 Oct 2014 01:53:28 + To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Building northeast map I've built my own gmappsup for the US Northeast and loaded it into my Garmin. My script for doing so is roughly as follows: [[ us-northeast-latest.osm.bz2 -nt northeast.om5 ]] bzcat us-northeast-latest.osm.bz2 | ../osmconvert/osmconvert - -o=northeast.om5 [[ northeast.om5 -nt northeast-boundaries.o5m ]] ../osmfilter/osmfilter northeast.om5 --keep-nodes= --keep-ways-relations=boundary=administrative =postal_code postal_code= -o=northeast-boundaries.o5m java -cp ../mkgmap/dist/mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreprocessor northeast-boundaries.o5m bounds/ java -jar ../mkgmap/dist/mkgmap.jar \ --gmapsupp \ --mapname=20355490 \ --description=Northeast United States \ --country-name=United States \ --country-abbr=US \ --region-name=Northeast \ --region-abbr=NE \ --index \ --location-autofill=nearest \ --housenumbers \ --route \ --add-pois-to-areas \ --bounds=bounds \ --add-pois-to-areas \ --process-destination \ --process-exits \ *.osm.pbf I've loaded the result onto my Garmin Nuvi. When I attempt to do an address search, it first asks me for the City, but the cities I'm looking for don't show up in the search. Oddly, when it shows the closest cities I can see some of them, but when I do a text search it shows distant oddballs. For example, with 'New York', I see: New York, FL New York, TX New York Mills, MN None of these are the New York I'm looking for. I don't even think they are in my input file, but are perhaps coming from the internal memory on my GPS. It does appear the NYC addresses are working better - I can see the Bronx Zoo is in The Bronx and Carnegie Hall is in New York, however, I can't key in an address to see if it works because of the address search issue. Another thing which has me puzzled is why some POIs are not showing the city/state. For example Desert Moon Grille http://www.openstreetmap.org/node/3139391561 is in Danbury http://www.openstreetmap.org/way/33271879, Connecticut. I can find it doing a Food POI search. That works fine. But, when I select it, it shows Not_set, Fairfield County. Nomination gets the address perfect: Desert Moon Fresh Mexican Grille, 113, Mill Plain Road, Danbury, Fairfield County, Connecticut, United States of America http://www.openstreetmap.org/node/3139391561 . I'm compiling my own bounds file, so I'm surprised it hasn't worked. Brian ___ 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
[mkgmap-dev] Building northeast map
I've built my own gmappsup for the US Northeast and loaded it into my Garmin. My script for doing so is roughly as follows: [[ us-northeast-latest.osm.bz2 -nt northeast.om5 ]] bzcat us-northeast-latest.osm.bz2 | ../osmconvert/osmconvert - -o=northeast.om5 [[ northeast.om5 -nt northeast-boundaries.o5m ]] ../osmfilter/osmfilter northeast.om5 --keep-nodes= --keep-ways-relations=boundary=administrative =postal_code postal_code= -o=northeast-boundaries.o5m java -cp ../mkgmap/dist/mkgmap.jar uk.me.parabola.mkgmap.reader.osm.boundary.BoundaryPreprocessor northeast-boundaries.o5m bounds/ java -jar ../mkgmap/dist/mkgmap.jar \ --gmapsupp \ --mapname=20355490 \ --description=Northeast United States \ --country-name=United States \ --country-abbr=US \ --region-name=Northeast \ --region-abbr=NE \ --index \ --location-autofill=nearest \ --housenumbers \ --route \ --add-pois-to-areas \ --bounds=bounds \ --add-pois-to-areas \ --process-destination \ --process-exits \ *.osm.pbf I've loaded the result onto my Garmin Nuvi. When I attempt to do an address search, it first asks me for the City, but the cities I'm looking for don't show up in the search. Oddly, when it shows the closest cities I can see some of them, but when I do a text search it shows distant oddballs. For example, with 'New York', I see: New York, FL New York, TX New York Mills, MN None of these are the New York I'm looking for. I don't even think they are in my input file, but are perhaps coming from the internal memory on my GPS. It does appear the NYC addresses are working better - I can see the Bronx Zoo is in The Bronx and Carnegie Hall is in New York, however, I can't key in an address to see if it works because of the address search issue. Another thing which has me puzzled is why some POIs are not showing the city/state. For example Desert Moon Grille http://www.openstreetmap.org/node/3139391561 is in Danbury http://www.openstreetmap.org/way/33271879, Connecticut. I can find it doing a Food POI search. That works fine. But, when I select it, it shows Not_set, Fairfield County. Nomination gets the address perfect: Desert Moon Fresh Mexican Grille, 113, Mill Plain Road, Danbury, Fairfield County, Connecticut, United States of America http://www.openstreetmap.org/node/3139391561 . I'm compiling my own bounds file, so I'm surprised it hasn't worked. Brian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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 b...@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_muenc...@hotmail.com wrote:
Just noticed that I sent this to Greg only...
Gerd
--
From: gpetermann_muenc...@hotmail.com
To: g...@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: g...@ir.bbn.com
To: gpetermann_muenc...@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_muenc...@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
Re: [mkgmap-dev] Eclipse
Hello, I’m using Eclipse Luna Service Release 1 (4.4.1) Build id: 20140925-1800 on OS X 10.10. I don’t think my changes make any difference to where you keep your working directory or source, or how you organize your workspace. What specific part of the patch do you think would break your eclipse setup? Can you apply the patch and identify any issues? I don’t have splitter checked out, so I added any ivy dependency to download it. If you have splitter in your workspace you can give that priority over ivy. Brian On Oct 23, 2014, at 3:22 PM, WanMil wmgc...@web.de wrote: Hi Brian, hi Gerd, just my two cents: I use Eclipse in the following way: I use one workspace (e.g. c:\workspace). I'll checkout the projects to this workspace named mkgmap_trunk, splitter_trunk etc. After checking out I run the ant target resolve within eclipse. After that the workspace is completely ready. When I want to implement a new feature or I want to try an older revision I checkout mkgmap into another directory below c:\workspace and run the ant script with resolve. In my mkgmap start scripts I define the directory below the workspace, e.g. MKGMAP_DIR=c:\workspace\mkgmap and use this variable in the startup call. It would also be possible to run ant dist first and define the dist directory in the workspace as mkgmap directory. This makes it easy to switch between different versions and development variants. WanMil Hi Brian, thanks for the patch. I agree that you can't use the current source in eclipse without manual work. When I started with mkgmap and splitter I also started using eclipse (and coding in Java), so I did more or less the same you did, but I did not dare to say that my solution is correct, probably it is far away from being a good solution. I am not sure if my environment will continue to work with your patch. 1) My current environment looks like this: - I am using Eclipse Version: Juno Service Release 2 Build id: 20130225-0426 on a Windows 7 64 bit machine - I have one directory called d:\eclipse_workspace containing sub directories mkgmap, splitter, display and others for each project - the source directories are located in d:\mkgmap or d:\splitter 2) When I try to reproduce problems in older mkgmap releases I close Eclipse, rename e.g. d:\mkgmp to d:\mkgmap_trunk and do a svn checkout of the wanted sources to d:\mkgmap. Next I use ant dist to build. After that I start Eclipse and do a refresh for the whole mkgmap project, maybe also a clean. Sometimes I have to repeat the ant dist and refresh to be able to debug mkgmap in Eclipse. Depending on the release of mkgmap that I am compiling I have to modify the names of libraries. If I got it right, you suggest to use the source directory (e.g. d:\mkgmap in my case) also as working directory for Eclipse? Gerd From: briane...@gmail.com Date: Wed, 22 Oct 2014 23:30:18 -0400 To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] Eclipse Hello, I’ve recently downloaded the mkgmap source. I had no trouble compiling it with ant, but getting Eclipse to work took some effort. I’ve attached a patch file containing changes for Eclipse. The specific changes are: * update classpath to find current version of jars * add ivyde settings * add Eclipse setting file to specify source=1.7 * add splitter to ivy to compile ‘optional’ bit * update URL of opengeo ivy repository * add bin/tmp to ignore list I see there is a git copy of this project, but it appears all commits are going through svn. I’d prefer to create a pull request on github than to attach a patch file, but am happy to do whatever works. Attached is the patch file for review and merging to http://svn.mkgmap.org.uk/mkgmap/trunk. Regards, Brian ___ 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Eclipse
Hello,I’ve recently downloaded the mkgmap source. I had no trouble compiling it with ant, but getting Eclipse to work took some effort. I’ve attached a patch file containing changes for Eclipse.The specific changes are:* update classpath to find current version of jars* add ivyde settings* add Eclipse setting file to specify source=1.7* add splitter to ivy to compile ‘optional’ bit* update URL of opengeo ivy repository* add bin/tmp to ignore listI see there is a git copy of this project, but it appears all commits are going through svn. I’d prefer to create a pull request on github than to attach a patch file, but am happy to do whatever works.Attached is the patch file for review and merging tohttp://svn.mkgmap.org.uk/mkgmap/trunk. eclipse.patch Description: Binary data Regards,Brian___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap in NYC
Hi Gerd, For NYC, one of the admin levels should be assigned to 'City' (http://wiki.openstreetmap.org/wiki/United_States_admin_level http://wiki.openstreetmap.org/wiki/United_States_admin_level). NYC is a special case in the United States, and it's often even confusing to find addresses in the Garmin database. NYC is composed of five borough's, and it's the borough that's used on standard addresses. For Bronx, Brooklyn and Staten Island people will use those borough names for their city. The exceptions are the borough of Manhattan, which for addressing purposes in simply 'New York', and Queens which uses various town names like Astoria. For example, you may live in Park Slope, which is a neighborhood in Brooklyn, but your postal 'city' will be Brooklyn. The postal service has this address: 440 5TH AVE BROOKLYN NY While Nomination has this one: 440, 5th Avenue, Park Slope, Brooklyn, Kings County, New York City, New York, 11215, United States of America http://www.openstreetmap.org/way/248237344 For my example, the standard postal address is: 311 W 51ST ST NEW YORK NY I see what you mean about the styles for mkgmap. Since it's not using the admin levels, it appears to be searching for the nearest city center, which is in a different state, and is completely wrong. I would guess the rule should be: For anything in mkgmap:admin_level5=New York City, then the city should be the alt_name of admin_level6. Manhattan: http://www.openstreetmap.org/relation/2552485#map=12/40.7812/-73.9778 http://www.openstreetmap.org/relation/2552485#map=12/40.7812/-73.9778 Queens: http://www.openstreetmap.org/relation/369519#map=11/40.6512/-73.8721 http://www.openstreetmap.org/relation/369519#map=11/40.6512/-73.8721 Brooklyn: http://www.openstreetmap.org/relation/369518#map=12/40.6446/-73.9449 http://www.openstreetmap.org/relation/369518#map=12/40.6446/-73.9449 Bronx: http://www.openstreetmap.org/relation/2552450#map=12/40.8516/-73.8467 http://www.openstreetmap.org/relation/2552450#map=12/40.8516/-73.8467 Staten Island: http://www.openstreetmap.org/relation/962876 http://www.openstreetmap.org/relation/962876 Is it possible to configure such a rule? If not, we should match on admin_level5 is a city name has not been set. I don't think I have the resources at home to load/run mkgmap, but I'm happy to test it. Thanks, Brian On Oct 18, 2014, at 5:11 AM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Brian, if I got that right, the problem is in the style rules. I don't know the rules that are used for your map (provided by Ben Konrath), but the default style doesn't assign mkgmap:city for the way with the id 265329468, and the way itself also doesn't contain the information. These are the tags which I see before style processing using a bounds file dated 2014-06-13: addr:housenumber=311, mkgmap:admin_level6=New York County, mkgmap:admin_level5=New York City, mkgmap:admin_level2=USA, addr:postcode=10019, building=yes, addr:street=West 51st Street, mkgmap:admin_level4=New York I see no rule in the default styles' address rules which handles this special case. I am not familiar with addresses in USA, so I don't know if only New York is special? Gerd From: briane...@gmail.com Date: Fri, 17 Oct 2014 16:14:49 -0400 To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] mkgmap in NYC Hi, I've been using a USA map from http://www.openmapchest.org/maps/united-states http://www.openmapchest.org/maps/united-states on my Garmin Nuvi 1450. In Connecticut it works quite well, but I drove into NYC yesterday and it couldn't find a single address. I was trying to find: 311 W 51 St. Nomination shows the address as: • House 311, West 51st Street, Midtown West, Manhattan, New York County, New York City, New York, 10019, United States of America http://www.openstreetmap.org/way/265329468 http://www.openstreetmap.org/way/265329468 I tried finding it in both New York and New York City. Manhattan and Midtown West are not listed as cities. I even tried the intersection search and nothing came up. NYC has a near complete set of street addresses, so I expected I would have good results using OSM data. I know the boundaries of NYC can be challenging at time, because the city has five boroughs, lots of neighborhoods and a ton of data. Today, I navigated to the approximate location on the GPS, and it decided the location was in Weehawken, NJ., (which is just across the Hudson). On my GPS, I did a reverse search, and it showed the address being in New Jersey! IMG_3891.jpeg I didn't build the maps myself, and I don't know how the splitter works. Clearly Nomination has the address figured out correctly, but mkgmap does not. Brian ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk
