July 2009 - mkgmap-dev - The mkgmap lists

SEVERE consecutive identical nodes with --remove-short-arcs
by Greg Troxel 26 Jul '09

26 Jul '09

I am trying to build a routable map for all of Massachusetts as a first step towards hopefully improving the style rules slightly (some ramps on Rt. 2 are missing from the cloudmade img and I think it's because trunk_link is missing in the style file, but I haven't figured that out yet). My command line is pretty much as the one in README.example. After running the splitter on cloudmade's massachusetts.osm I ran: java -enableassertions \ -Xmx2048m \ -jar mkgmap.jar \ --tdbfile \ --gmapsupp \ --family-id=632 \ --overview-mapname=40000001 \ --country-abbr="US" \ --country-name="United States" \ --region-abbr="MA" \ --region-name="Massachusetts" \ --description="OSM gdt" \ --ignore-osm-bounds \ --net \ --route \ --add-pois-to-areas \ --remove-short-arcs \ -c template.args > OUT.02.mkgmap 2>&1 As you can see I do have remove-short-arcs. I think I am r1048 but will update and try again. I got the following errors, which I thought --remove-short-arcs was supposed to fix. I looked at NEW HOPE WAY, and it is nearly a loop with very close nodes even though it is really a simple linear alley for which two nodes would do fine. I looked at another one (29730871) and that looks bizarre as well: http://www.openstreetmap.org/?way=29730871 I think the ways appear multiple times due split tiles, which is fine. The rewulting img/gmapi loads into Garmin mapmanager (mac) but RoadTrip says it is broken and cannot be used. So two thoughts: if ways are still messed up, maybe they should just be omitted? it would be nice to give a URL to the way instead of just the id. I suspect a lot of these are messed up and should be fixed in the db regardless of mkgmap liking them or not liking them. I have done sort|uniq on the actual output: SEVERE (RoadNetwork): Road NEW HOPE WAY (OSM id 11175820) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 29730871) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30158233) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30574531) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30574585) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 30575415) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 9208777) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 9252537) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 9325924) contains consecutive identical nodes - routing will be broken SEVERE (RoadNetwork): Road null (OSM id 9563279) contains consecutive identical nodes - routing will be broken

2 1

Commit: r1104: Report OSM URL when griping about bad nodes and arcs.
by svn commit 26 Jul '09

26 Jul '09

Version 1104 was commited by markb on 2009-07-26 08:49:45 +0100 (Sun, 26 Jul 2009) Report OSM URL when griping about bad nodes and arcs.

1 0

natural=coastline not supported?
by Sven Sommerkamp 26 Jul '09

26 Jul '09

Currently my Garmin displays not the Elbe River at http://www.informationfreeway.org/?lat=53.55294476877115&lon=9.737941940023… And when I look to the Coast, I'll not see Water. Are there People working on that? Greetings Sven

4 3

proposed README organization
by Greg Troxel 25 Jul '09

25 Jul '09

I've been trying to use mkgmap and having a bit of a hard time. I'm a little compulsive about having all the lore be in the source tree, and it seems the README is a bit behind the code. I have a bit of time here and there but not enough to really dig into the code. So I'll be trying to send patches to improve the state of the in-tree documenation after receiving some off-list encouragement to do so. Here's a patch which adds a README.INDEX that describes multiple readme files. If people think this is sane, I will start adjusting the docs to follow this plan and fill in some of the missing pieces, asking for help about the content on the list. I have saved a number of list postings that should be of great help - I am assuming that people do not mind their emails being cut/pasted/edited into READMEs. Besides what I listed below, I think we need a README that explains to a newbie: if you want to make an img from osm data to use, what options should you use and why. Plus probably ones that explain how to get maps into MapSource and RoadTrip. Comments welcome. Index: README.INDEX =================================================================== --- README.INDEX (revision 0) +++ README.INDEX (revision 0) @@ -0,0 +1,49 @@ +$Id$ + +README.INDEX for mkgmap + +This file describes the various README files for mkgmap. Each file is +named README.name (where name is lower case) and covers a different +area of mkgmap usage. + +The intent is that everything known about mkgmap will be contained in +the various README files. Currently, README.INDEX describes a +proposed organization. Files are listed in an order intended to be +helpful to new users. + +* README.overview + +This file describes the purpose of the program and contains +acknowledgements. + +* README.invoking + +This file describes every command-line option for mkgmap. It assumes +that a .jar already exists and that there are no java issues. + +* README.splitter + +This file describes how to use the splitter with mkgmap. + +* README.styles + +This file describes how the style files work. + +* README.sizes + +This file contains information about how much memory is needed to +perform various operations. + +* README.img + +This files contains pointers to descriptions of the garmin formats. +It contains links to other related programs and documents. + +* README.java + +This file describes how to deal with java, CLASSPATH, which versions +work, etc. + +* README.building + +This file describes how to build mkgmap from source, producing a .jar. Property changes on: README.INDEX ___________________________________________________________________ Added: svn:keywords + Id

5 6

Commit: r1103: Add README files from Greg Troxel as the first step in
by svn commit 25 Jul '09

25 Jul '09

Version 1103 was commited by steve on 2009-07-25 22:29:47 +0100 (Sat, 25 Jul 2009) Add README files from Greg Troxel as the first step in a continuing documentation effort. - Greg Troxel

1 0

Commit: r1101: Further work on loop splitting code.
by svn commit 25 Jul '09

25 Jul '09

Version 1101 was commited by markb on 2009-07-24 00:02:50 +0100 (Fri, 24 Jul 2009) Further work on loop splitting code. Two changes: 1 - the recent commit that changed the test to see whether splitting a way would introduce a short arc was too strict in that it checked to see if the candidate splitting point was too close to its nearest neighbour points but as they may not be nodes it doesn't matter how close it is to them, what matters is that it isn't too close to any nodes in the way so this commit now adds method safeToSplitWay() that decides whether adding a node at a given point in a way does not introduce any short arcs. 2 - In the situation where the looped way cannot be split without introducing a short arc, it now aggressively prunes the way to remove the loop without producing a short arc. It removes the point that completes the loop and then, if it was the last point in the way, keeps removing the new last point until either no short arc will be created or all the points back to the start of the loop have been removed.

5 8

trying to pin down missing tooltips
by Valentijn Sessink 25 Jul '09

25 Jul '09

Hello List, I'm still trying to pin down the "missing tooltips/blanking map" issue. Here's what I managed to find so far. But now I'm sort of stuck. I have a map that has the problem. Decreasing or increasing the map boundaries would lose the problem. So instead I tried to find out if there is certain data on the map that will trigger the problem, by going through it with Splitter, then after running Splitter I would restore the map size to the original boundaries. This will give you a partially empty map, that will or will not have problems at the lower boundary. At this moment, there's a single digit that will trigger the error: Having (hexadecimal) 251000,25000 252280,33dbc (with map size artificially restored to 251000,25000,255000,39000) will show all right at the bottom; 251000,25000 252280,33dbd (map size restored as well) will blank when you zoom into the bottom part. These maps differ by about 55 nodes and 15 ways, which is still a bit too much to go over by hand. Does anyone have an idea about the next step? Would you like to get the resulting osm map? (It's 1.1M large, I shal put it up for download somewhere if someone is interested). Attached is the script I ran, it's crude and silly and the texts are in a strange language for most of you, but you get the idea of what I did. The 0x251000 - 0x252280 latitude is derived from a previous run of the script where I would change latitude instead of longitude. If it is silly or plain stupid what I'm doing, please say so. I'm not entirely sure anymore that this random grepping of data does any good (while the only thing I was trying is to get the map to show at boundaries on high zooming levels). Also, as a side note, (and to complicate things) I'm seeing a ghost road pop up at about 3.6663 lon 52.119140625 lat. It's a straight line that runs down the boundary of the map, i.e. the road is larger than the map boundary! As it is not 180 degrees down but a bit tilted, it is *not* a longitude line. The line disappears when you zoom out, or go up or down in the map. It shows up in maps that work (i.e. do not blank); when the map blanks, I cannot find the line anywhere (i.e. probably the line itself blanks out and when zoom level is lower so that the map is not blanked, it's also too low to show this ghost road). Any ideas appreciated. Best regards, Valentijn

1 0

routing and cycleway=track
by Sven Geggus 25 Jul '09

25 Jul '09

Hi there, quite a lot of cycleways around here alongside major roads (primary,secondary,trunk) are tagged as cycleway=track. In this case the Garmin device does not use this ways if "Avoid Highways" is enabled in routing option. The result is a very strange routing in these places. Would it be possible to generate fake cycleways in this cases simular to what --make-opposite-cycleways is doing? As I'm already asking for cycle routing here. Is it known to the developers of mkgmap what the option "Avoid unpaved roads" is actually doing? Looks like this option does not have any effect with current mkgmap generated maps. Is this just a limitation to certain types of roads or is this an additional per way flag which could be mapped in a way that routing does actually avoid tracks of tracktype >grade1? Sven -- The main thing to note is that when you choose open source you don't get a Windows operating system. (from http://www.dell.com/ubuntu) /me is giggls@ircnet, http://sven.gegg.us/ on the Web

3 7

Default mapping of highway=primary
by Dermot McNally 24 Jul '09

24 Jul '09

Hi, While hacking on my own TYP file, I've noticed that my preferred styling for highway=primary is never being respected, and that primary roads always assume the same style as trunk. In the TYP file, I've assumed that primary will be mapped to 0x03 [Principal HWY-medium] and trunk to 0x02 [Principal HWY-thick ]. I haven't got my head around how the sources are ordered, but some crude greps suggest to me that the default styles are using 0x02 for primary, though with primary_link using 0x03 as I would have expected. Obviously I could work around this with a custom config to achieve what I want, but is there any reason not to change the default to use 0x02 and allow trunk and primary to have, as default, different appearance? Dermot -- -------------------------------------- Iren sind menschlich

1 0

[PATCH v3] - make cycleway tracks
by Mark Burton 24 Jul '09

24 Jul '09

v3 renamed option for enabling this to --make-cycleways added --make-all-cycleways option to turn on all cycleway synthesising options Now removes bicycle access from the original way (unless that way has a "bicycle" tag) to force the routing to use the cycleway. BTW - this may be a complete red herring but mapsource was not showing me the cycleway names like "Foo (cycleway)" it was only showing the original road name "Foo". I then rebuilt the map without the --lower-case option and the cycleway names started appearing. So, either mapsource was just being its usual weird self or there is some badness related to using --lower-case. Just thought I would mention it! --------------------- v2 - Now matches extra tags (lane, left, right, both). Commented out setting of highway=cycleway until it's agreed that it's a good idea. --------------------- As requested, here's an option (--make-cycleway-tracks) to enable the synthesis of cycleways when a (non-cycleway) way is tagged cycleway=track. I have also tweaked the code for making opposite cycleways - it now gives the synthesised way a highway=cycleway tag which it wasn't doing before. So anyone who was using the --make-opposite-cycleways option, please test to see it hasn't been broken. Cheers, Mark

1 0