Questions related to practical usage of MKGMAP
Hi. I have a few questions related to MKGMAP that I could not find answers to in the archives. My data source is mostly OpenStreetmap, but I used gpsmapedit for editing and adding my own traces, so I am using mp format files with the compiler. I am open to other suggestions on managing data, but I need strong editing capabilities. Q1. I have about sixty roads where I get the severe warning: SEVERE (RouteArc): Way ~212 contains an arc whose length is too big to be encoded so the road will not be routable As the warning gives no line number, I am at a loss to find the problem. Does anybody know how I might locate these 60 roads? I tried sorting the roads by number of points, but did not seem to find a match. Perhaps if I calculated the length of each road segment, and sorted by length? Q2. In encoding sea polygons, I must split the polygons up so that they have less than 256 points (I did this in gpsmapedit). When zooming in and out, sometimes polygons show white lines in between, where the shape has been optimized. It there a way to avoid this, or a better way to split up large polygons? Is there a utility to help with this problem? I would only need to do it once, so it does not matter if it is a convoluted route to what I want. Q3. I would like to use road numbers as labels. In gpsmapedit you use the a code like this ~[0X06]117 in the label for the road, but this did not work in MKGMAP. Is there some other way to display road numbers? Thanks for any help and suggestions. Garvan
Hi Garvan,
Hi.
I have a few questions related to MKGMAP that I could not find answers to in the archives. My data source is mostly OpenStreetmap, but I used gpsmapedit for editing and adding my own traces, so I am using mp format files with the compiler. I am open to other suggestions on managing data, but I need strong editing capabilities.
Q1.
I have about sixty roads where I get the severe warning:
SEVERE (RouteArc): Way ~212 contains an arc whose length is too big to be encoded so the road will not be routable
As the warning gives no line number, I am at a loss to find the problem. Does anybody know how I might locate these 60 roads? I tried sorting the roads by number of points, but did not seem to find a match. Perhaps if I calculated the length of each road segment, and sorted by length?
The message does give the way's name (~212), does that not help? Basically, you're looking for roads (or ferry routes) that have long(ish) distances between routing nodes. If you were using OSM input instead of MP input, it would not be a problem because mkgmap introduces fake nodes to avoid the long segments.
Q2.
In encoding sea polygons, I must split the polygons up so that they have less than 256 points (I did this in gpsmapedit). When zooming in and out, sometimes polygons show white lines in between, where the shape has been optimized. It there a way to avoid this, or a better way to split up large polygons? Is there a utility to help with this problem? I would only need to do it once, so it does not matter if it is a convoluted route to what I want.
Sorry, don't know anything about polygons.
Q3.
I would like to use road numbers as labels. In gpsmapedit you use the a code like this ~[0X06]117 in the label for the road, but this did not work in MKGMAP. Is there some other way to display road numbers?
A while back (when this topic was last discussed), I suggested that we supported that syntax but no one seemed keen. Also, if my memory is correct, someone posted a patch that allowed you to specify that labels are rendered in a chosen style. Cheers, Mark
OK - recently committed change(s) will now report the Way's id (OSM or RoadID) if an arc is too long to be encoded - this should help when trying to find the overly long roads. Cheers, Mark
Mark Burton wrote:
OK - recently committed change(s) will now report the Way's id (OSM or RoadID) if an arc is too long to be encoded - this should help when trying to find the overly long roads.
Cheers,
Mark _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Thank you for the update. I downloaded the latest version from svn, and I can now easily identify the roads with problems. Do you know where I would find the patch you mentioned related to label styles? Is there a list of all patches someplace? Thanks again, Garvan
Hi Garvan,
Thank you for the update. I downloaded the latest version from svn, and I can now easily identify the roads with problems.
Good.
Do you know where I would find the patch you mentioned related to label styles? Is there a list of all patches someplace?
The mailing list archive will contain the emails/patches and also the original author(s) may see these messages and respond. Cheers, Mark
On Wed, Jul 1, 2009 at 6:00 PM, Mark Burton<markb@ordern.com> wrote:
Do you know where I would find the patch you mentioned related to label styles? Is there a list of all patches someplace?
The mailing list archive will contain the emails/patches and also the original author(s) may see these messages and respond.
I believe there was a patch by Toby Speight posted to this list, and also patches and information from me with regard to this. Right now, I am using a combination of the two to get highway labels working. Let us know if this is enough information for you. If not, I can send you the patches and further information directly. Cheers!
On Wed, Jul 01, 2009 at 06:13:27PM +0200, Clinton Gladstone wrote:
Let us know if this is enough information for you. If not, I can send you the patches and further information directly.
I know have a fair amount of time to work on mkgmap and applying these pathes is going to be one of the first things I do as it is a pretty neat feature. Cheers, ..Steve
0> In article <4dda9d8f0907010913v4578a365g2b00b538393476db@mail.gmail.com>, 0> Clinton Gladstone <URL:mailto:clinton.gladstone@googlemail.com> ("Clinton") wrote: Clinton> I believe there was a patch by Toby Speight posted to this Clinton> list, and also patches and information from me with regard to Clinton> this. I don't have a reference to the archives, but could re-generate my patch if necessary. Sorry for the late reply - I've been out all afternoon taking advantage of calm weather to paddle around Soay, and didn't get back until after midnight.
I've attached Toby's patch. I'm using it and it works well, *if* the polyline is long enough. When using it for cycleroutes for example they tend to be made of lots of tiny pieces and the road symbols won't be displayed. Another patch you might be interested in is the "generate_highways_from_relations" patch. This allows to write something like type=route & route=bicycle & network=tcn [ 0x02 road_class=3 road_speed=6 level 3 ] into the relations file. It will generate a copy of all the ways that belong to that relation. The ways will get joined together, so that it is not lots of tiny pieces, but only as much ways as there are non- continuous parts of the route. Another patch: "bugfix_overlays". When using overlays and routing, the routing information is added once for each of the overlayed Garmin types without this patch. This is unnecessary, because the overlayed ways differ only in the Garmin type, but nothing else. Also a copy of the points that the way is made of is created, instead of simply copying a reference. Without it there was some weird behaviour, but I cannot put my finger at the reason for that. And finally one patch that you might want to apply: "start-with". This adds a text filter for variable substitution. You can say for example $ {name|start-with:Hospital }. This will put the string "Hospital " in front of the name, but only if that string doesn't contain "Hospital" somewhere already. Note that the trailing space of "Hospital " gets trimmed for the search. It is really useful for POIs, especially if you have different types of POIs that will all get displayed in the same category on the GPS. For example hotels and hostels. With start- with you can make sure that the string "Hotel" resp. "Hostel" is part of the name, so that you can distinguish them in the search results on the GPS. Regards Thilo
0> In article <56AA797E-5E8D-477F-B4A1-B2A113F41974@gmx.de>, 0> Thilo Hannemann <URL:mailto:thannema@gmx.de> ("Thilo") wrote: Thilo> And finally one patch that you might want to apply: "start-with". Thilo> This adds a text filter for variable substitution. You can say Thilo> for example $ {name|start-with:Hospital }. This will put the Thilo> string "Hospital " in front of the name, but only if that string Thilo> doesn't contain "Hospital" somewhere already. I like that idea! A corresponding 'end-with' would be really useful (certainly in English, where the name usually comes before the function, e.g. "Strathcarron Station"). Thilo> + searchPhrase = arg.trim().toLowerCase(); Thilo> + ... Thilo> + if (value.toLowerCase().indexOf(searchPhrase) != -1) That's not the best way to do a case-insensitive test - the reason being that in some languages (e.g. French, I think) upper case letters have no accents. So "Ecole" should match "école" (again, excuse my poor French if necessary!). Also, in German, "Straße" should match "STRASSE". Conversion of both values to uppercase is therefore a better simple solution. (I was surprised to find that java.text.Collator doesn't have an indexOf() method - that's where I'd expect to do locale-dependent matching). To do it properly, look at java.util.regexp - something like: /-------- | searchPattern = Pattern.compile(Pattern.quote(arg.trim()), | Pattern.UNICODE_CASE | Pattern.CANON_EQ); | ... | if (searchPattern.matcher(value).matches()) \--------
2009/7/2 Toby Speight <T.M.Speight.90@cantab.net>:
That's not the best way to do a case-insensitive test - the reason being that in some languages (e.g. French, I think) upper case letters have no accents. So "Ecole" should match "école" (again, excuse my poor French if necessary!). Also, in German, "Straße" should match "STRASSE".
Your point probably still stands (for the German case anyway, where you also need to regard, say, ae as equivalent to ä), but French does now place accents on uppercase letters. Dermot -- -------------------------------------- Iren sind menschlich
On Thu, Jul 02, 2009 at 09:30:30AM +0100, Dermot McNally wrote:
2009/7/2 Toby Speight <T.M.Speight.90@cantab.net>:
That's not the best way to do a case-insensitive test - the reason being that in some languages (e.g. French, I think) upper case letters have no accents. So "Ecole" should match "école" (again, excuse my poor French if necessary!). Also, in German, "Straße" should match "STRASSE".
Your point probably still stands (for the German case anyway, where you also need to regard, say, ae as equivalent to ä), but French does now place accents on uppercase letters.
Actually, the conversion to upper case also depends on the locale. Here is how: Turkish uses both a dotted i and a dotless I, both in upper and lower case. In most other locales, the upper-case variant of i is I, but not in Turkish. Also, comparing upper-case strings would not solve all issues. For example, in Swedish and Finnish, v and w are sometimes sorted at the same position. I'm not sure if these examples really matter that much when comparing common names. For proper names, there may be alternative spellings (such as old Finnish names containing W instead of V), but common names, such as station or hotel, should use a uniform spelling. Perhaps this could best be addressed by writing explicit rules for all the possible spellings and abbreviations (if they have been used contrary to advice). E.g., Straße, Strasse, Str.; Bahnhof, Hauptbahnhof, Hbf. One last word: instead of editing the name tags (with things like default_name or prefixing or affixing "station"), I would rather include the TYP file information in the mkgmap style definition. As far as I know, labels cannot be multilingual in the Garmin format except in the TYP file. Doing something about this is on my long-term TODO list. Marko
2009/7/2 Marko Mäkelä <marko.makela@iki.fi>
On Thu, Jul 02, 2009 at 09:30:30AM +0100, Dermot McNally wrote:
2009/7/2 Toby Speight <T.M.Speight.90@cantab.net>:
That's not the best way to do a case-insensitive test - the reason being that in some languages (e.g. French, I think) upper case letters have no accents. So "Ecole" should match "école" (again, excuse my poor French if necessary!). Also, in German, "Straße" should match "STRASSE".
Your point probably still stands (for the German case anyway, where you also need to regard, say, ae as equivalent to ä), but French does now place accents on uppercase letters.
Actually, the conversion to upper case also depends on the locale. Here is how: Turkish uses both a dotted i and a dotless I, both in upper and lower case. In most other locales, the upper-case variant of i is I, but not in Turkish. Also, comparing upper-case strings would not solve all issues. For example, in Swedish and Finnish, v and w are sometimes sorted at the same position.
I'm not sure if these examples really matter that much when comparing common names. For proper names, there may be alternative spellings (such as old Finnish names containing W instead of V), but common names, such as station or hotel, should use a uniform spelling.
Perhaps this could best be addressed by writing explicit rules for all the possible spellings and abbreviations (if they have been used contrary to advice). E.g., Straße, Strasse, Str.; Bahnhof, Hauptbahnhof, Hbf.
One last word: instead of editing the name tags (with things like default_name or prefixing or affixing "station"), I would rather include the TYP file information in the mkgmap style definition. As far as I know, labels cannot be multilingual in the Garmin format except in the TYP file. Doing something about this is on my long-term TODO list.
You think wrongly here, you don't have an infinite list of objects available for the typfile, so adding things like Bahnhof or Strasse has to be done in data, not TYP File (no conditions possible). TYP File tags will only show for streets/objects without name at all, so to achieve your goal you have to set name empty (but then you can't have streetnames at all).
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Best would be to be able to define start-with as a overall rule and not on a per object-basis. Otherwise you have to go in deep recursives to add several tags to the name.
On Thu, Jul 02, 2009 at 12:52:21PM +0200, Felix Hartmann wrote:
You think wrongly here, you don't have an infinite list of objects available for the typfile, so adding things like Bahnhof or Strasse has to be done in data, not TYP File (no conditions possible). TYP File tags will only show for streets/objects without name at all, so to achieve your goal you have to set name empty (but then you can't have streetnames at all).
Right, I take my words back. Some symbol codes, such as "Ground Transport" in the Find Places menu, are overloaded. If we want bus stops, tram stops, underground stations, bus stations, and train stations appear there nicely, the only way we can distinguish them is by a name prefix or suffix. On the other hand, if my findings on the Edge 705 apply to all recent Garmin models, there are plenty of spare symbols for restaurants and lodging. No need to add Hotel/Hostel/Motel/whatever to the name; each can have their own Find Places submenu. The default title of these spare codes in the Edge 705 is "Other". I haven't tried playing with TYP files yet, but I would assume that the submenu names can be overridden.
Best would be to be able to define start-with as a overall rule and not on a per object-basis. Otherwise you have to go in deep recursives to add several tags to the name.
I'm not sure if I understand what you mean. Can you elaborate a little, or give an example (using some made-up syntax)? Marko
Marko Mäkelä wrote:
... Some symbol codes, such as "Ground Transport" in the Find Places menu, are overloaded. If we want bus stops, tram stops, underground stations, bus stations, and train stations appear there nicely, the only way we can distinguish them is by a name prefix or suffix.
+1 to having more granularity to e.g. "Ground Transportation". I've always cheated up to now by messing about with the .OSM file used to create the map to append e.g. " (Railway Station)" to railway stations, but being able to select a less broad sub-category than "Ground Transportation" (as you can with "Food & Drink") would be much better. One slight caveat though - (at least on my Garmin eTrex) the items in the menus don't show category. For example, if I search for "Food & Drink" I see things like "The White Bear" and "Taj Regency". It's obvious from the name that the first of these is a pub and the second an Indian restaurant; I don't have to select the category "British Isles" (which is where I've mapped amenity=pub to) to see which is which. The same isn't true for stations though - it would be useful to be able to see "Alfreton (Railway Station)" and "Alfreton (Bus Station)" as separate items on the "Transportation / All Categories" list without having to select something like "Transportation / Bus" or "Transportation / Railway" to see which is which.
May I point you to the wiki page http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types where I try to collect the mapping of the Garmin types to the categories for different GPS units. If you own a GPS unit of a different product line it would be great if you could collect that data and add it. This will help everybody to optimize his map for all GPS units, not only for the one unit he happens to own. Regards Thilo
2009/7/2 Marko Mäkelä <marko.makela@iki.fi>
On Thu, Jul 02, 2009 at 12:52:21PM +0200, Felix Hartmann wrote:
You think wrongly here, you don't have an infinite list of objects available for the typfile, so adding things like Bahnhof or Strasse has to be done in data, not TYP File (no conditions possible). TYP File tags will only show for streets/objects without name at all, so to achieve your goal you have to set name empty (but then you can't have streetnames at all).
Right, I take my words back. Some symbol codes, such as "Ground Transport" in the Find Places menu, are overloaded. If we want bus stops, tram stops, underground stations, bus stations, and train stations appear there nicely, the only way we can distinguish them is by a name prefix or suffix.
On the other hand, if my findings on the Edge 705 apply to all recent Garmin models, there are plenty of spare symbols for restaurants and lodging. No need to add Hotel/Hostel/Motel/whatever to the name; each can have their own Find Places submenu. The default title of these spare codes in the Edge 705 is "Other". I haven't tried playing with TYP files yet, but I would assume that the submenu names can be overridden.
No the submenu structure can't be overrriden - well it can but only at the cost that you can't search for the POIs anymore. Hostel/Motel/Hotel actually is a special case that allows for many different symbols while still being searchable.
Best would be to be able to define start-with as a overall rule and not on a per object-basis. Otherwise you have to go in deep recursives to add several tags to the name.
I'm not sure if I understand what you mean. Can you elaborate a little, or give an example (using some made-up syntax)?
I.e. if you wan't to add tracktype to each ways name at the end it is easier by doint tracktype=grade1 {add name grade1} then by adding this to each line (i.e. highway=track & tracktype=grade1 name ({name} grade1)
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (11)
-
Clinton Gladstone -
Dermot McNally -
Felix Hartmann -
Garvan -
Garvan & maew -
Mark Burton -
Marko Mäkelä -
Someoneelse -
Steve Ratcliffe -
Thilo Hannemann -
Toby Speight