November 2012 - mkgmap-dev - The mkgmap lists

version numbers
by n Willink 08 Nov '12

08 Nov '12

I'm having problems on my Oregon with maps disappearing when I zoom in. Unfortunately, I can not establish what version of mkgmap I'm using as I'm , perhaps wrongly, justing extracting the contents of an mkgmap.zip into one folder. I notice there is not --help=version Would this be an idea? -- View this message in context: http://gis.19327.n5.nabble.com/version-numbers-tp5734654.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

6 15

splitter that generates problem list
by GerdP 07 Nov '12

07 Nov '12

Hi all, I am about to finish coding the new splitter algorithm. I am quite happy with the results now, so I'd like to ask you for testing it. Activate it with the parameter --keep-complete I've also changed the handling of the user written problem file, so please check this as well. I've committed the changes as r212 on the problem-list branch. When you test the --keep-complete parameter, please try also using --overlap=0. Be careful when you use large input files like planet or europe on a 32bit machine! Even if you use a split-file with only a few small tiles, the new algorithm has to save a few bits for every node and way. I suggest to use osmconvert with the -b or -B parameter first to cut out a reasonable part of planet. Reg. performance: Runtime is much higher for large input files because r212 with --keep-complete has to read the input at least two times more often than r202. I tried to keep heap requirements small, but you should expect problems processing files > 1.5GB on a 32bit system. With --overlap=0 and --keep-complete the size of the output files is almost the same. Any comments are welcome. Gerd P.S. For those that are interested: The problem list generator works like this (well, I hope it does): - calculate the bbox of the used areas - calculate additional "pseudo-areas" to cover the whole planet (these can be very large) - for each node: calculate the area that contains it and save it in a map - for each way: get the areas of each point. Save a list of all areas and save it in a map - for each relaton: get the areas of each member Each relation or way that is written to more than one area is a potential problem case, but only if at least one of the areas is a real writer area (and not a pseudo-area) or if the bounding box of the areas intersects with at least one real area. When this information is calculated, we have our problem list and can start a more detailed analyses using the real coordinates. This is done in the MultiTileProcessor. It starts reading (and storing) all relations. This requires a lot of heap. Next, it marks all elements (also sub relations) of the problem rels also as problem cases (recursively). When this is done, it marks the parent rels that contain problem rels also as problem rels. Now it releases the storage for all non-problem-rels and starts to read the ways that are marked as problem cases. For each way, it marks all nodes as problem cases. Next, it starts to collect the coordinates of all problem nodes (this also requires a lot of heap and is subject of tuning). Next it reads again all problem ways and calculates the exact bbox of each way as well as the real writer areas. For a closed way, it will also recognize fully enclosed areas. Both the area info as well as the writer set info is stored. Next it processes the stored problem relations to calculate the needed writers and stores them. To make sure that all elements of a relation are written to all tiles it combines the writer sets of the relation with the previously calculates writers and stores them. Finally it reads again the ways to update the writer sets of the problem nodes. Now the normal split process starts to write the output files, and whenever it finds a node or way that is in the special lists it will write it to more tiles. -- View this message in context: http://gis.19327.n5.nabble.com/splitter-that-generates-problem-list-tp57340… Sent from the Mkgmap Development mailing list archive at Nabble.com.

5 34

Garmin OSM Hack Weekend
by Gehling Marc 07 Nov '12

07 Nov '12

Dear garmin maps maker, some may have noticed it. We are planning a Garmin OSM Hack Weekend [1]. The aim is to bring together the makers of Garminmaps and implement two ideas: - A landing page for absolute beginners describes the use of existing Garminmaps, allows a choice and is being maintained - A map generator that allows anyone to create custom maps with different styles and regions. Through this service, we want to make the OSM maps with cyclists and hikers known and we hope to attract new mapper. Participants should thus produce either already own garminmaps or have desire to work on the landing page and the map generator. Steve Ratcliffe already committed and I hope that you, too, to the date the time and inclination. 1.2.-03.02.2013 at Linuxhotel Essen [2] The Linux Located on the edge of Essen in a lovely private park ◦ We will stay in a double or single room ◦ we can work in 3 seminar rooms ◦ The "fireplace" is used as a breakfast room, and for the social round ◦ Open WiFi on the whole site ◦ breakfast, bed and drinks for the whole day are included in the price Thanks to the support [3] by the FOSSGIS eV amount the participant cost for the three days (ie, breakfast, bed, drinks) to a maximum of 30 euros. To register, please send me (m.gehling(a)gmx.de)a mail with your arrival date, your departure dates.and whether a single or double room is required. (Two single rooms and 8 double rooms are available) This email get all that are on the list (# http://wiki.openstreetmap.org/wiki/Garmin_Project Maps_and_their_creators). If you do know someone who should come, write me a note. If there are any questions, you can feel free to ask me. with friendly greetings Marc Gehling [1] http://wiki.openstreetmap.org/wiki/Garmin_Project [2] http://www.linuxhotel.de/ [3] http://www.fossgis.de/wiki/Hackweekend_Kartenbau

1 0

mkgmap splitter error: java.lang.ArrayIndexOutOfBoundsException -- DensityMap.subset
by Felix Hartmann 06 Nov '12

06 Nov '12

Anybody seen this before?? - happens with splitter 202 from trunk: java -Xmx6600m -jar splitter.jar --max-nodes=800000 --output=pbf --overlap=5000 --max-areas=255 --geonames-file=cities15000 --description=us-pacific --mapid=65290000 us-pacific.osm.pbf cache= description=us-pacific geonames-file=cities15000 legacy-mode=false mapid=65290000 max-areas=255 max-nodes=800000 max-threads=8 (auto) mixed=false no-trim=false output=pbf output-dir= overlap=5000 resolution=13 split-file= status-freq=120 write-kml= Elapsed time: 0s Memory: Current 122MB (1MB used, 121MB free) Max 5866MB Time started: Tue Nov 06 17:53:17 CET 2012 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units - areas are multiples of 0x1000 map units wide and high Processing c:\openmtbmap\osmpbf_geofabrik\us-pacific.osm.pbf Bounding box -179.9965 15.92097 -129.7998 72.98845 in 1 file Time: Tue Nov 06 17:53:19 CET 2012 Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 2097151 at uk.me.parabola.splitter.DensityMap.subset(DensityMap.java:118) at uk.me.parabola.splitter.DensityMapCollector.getRoundedArea(DensityMapCollector.java:79) at uk.me.parabola.splitter.Main.calculateAreas(Main.java:303) at uk.me.parabola.splitter.Main.split(Main.java:164) at uk.me.parabola.splitter.Main.start(Main.java:119) at uk.me.parabola.splitter.Main.main(Main.java:108) -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

2 4

Node IDs greather than 2.147.483.647 - problems expected ?
by toc-rox 05 Nov '12

05 Nov '12

It is expected that the node ID count reaches this weak 2.000.000.000. Are there any problems expected when the int max limit (2.147.483.647) will be reached ? Regards Klaus -- View this message in context: http://gis.19327.n5.nabble.com/Node-IDs-greather-than-2-147-483-647-problem… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 1

OSM-Id accessable in style ?
by Chris66 05 Nov '12

05 Nov '12

Hi, is the OSM-Id accessible via style file? Example: highway=motorway & mkgmap:osm-id=12032234 { add name=test } Chris

4 4

[proposal] Display the destination
by Chris66 04 Nov '12

04 Nov '12

Hi, I added following lines to my style file in order to display the "destination"-Tag on motorway-junctions: ---------- # Set the routing direction (highway=motorway|highway=motorway_link) & destination=* { add display_name = '${ref} (${destination})' } (highway=trunk|highway=trunk_link) & destination=* { add display_name = '${ref} (${destination})' } # Set highway names to include the reference if there is one ---------- This works well (see pictures [2] and [3]), but: When using the Garmin Types 0x08 and 0x09 (Ramp), Garmin is evaluating the first way behind all the _link ways. This is not what is stated in the wiki [1]. In most cases, only the _link ways are tagged. So the idea is a new mkgmap option --process-destination which does following pre-processing: For all _link ways which have a destination-Tag copy the tag to the following non-link way (motorway or trunk). Chris [1] http://wiki.openstreetmap.org/wiki/Key:destination [2] http://up.picr.de/11670098jg.png [3] http://up.picr.de/11670102jj.png

4 9

Overlays
by Roger Calvert 04 Nov '12

04 Nov '12

Would it be feasible to process overlays directly in the "lines" file? Instead of 'highway=trunk & oneway=yes [0x123 road_class=3 road_speed=5 resolution 16]' in the "lines" file and '0x123: 0x02, 0x23' in the "overlays" file, how about 'highway=trunk & oneway=yes [0x02, 0x23 road_class=3 road_speed=5 resolution 16]' This would remove the need for an "overlays" file and for a dummy code for each overlaid feature. Roger -- ------------------------------------------------------------------------ Roger Calvert ------------------------------------------------------------------------

2 2

point number too big
by Minko 03 Nov '12

03 Nov '12

I'm trying to debug an error with the following 'Lambertus' mapset: Openfietsmap Lite France 15-10-2012, temp download location: http://osm.pleiades.uni-wuppertal.de/garmin/openfietsmap_lite/15-10-2012/58… This map is generated with mkgmap-r2337 If I send one or more tiles to the GPS, Mapsource crashes instantly: MDR_TRIM_ADDR.CXX-347-6.16.3.0 (it doesnt matter which tile I send) Other country sets don't have this issue as far as I have tested (NL, B) so there might be a few or more corrupt tiles in this France mapset. I ran mkgmap on the individual img tiles to recreate a new index, and notice that mkgmap complains several times about "point number too big". What is this error and might this be the reason for the MDR_TRIM_ADDR crash?

5 14

Commit: r2370: Do not try to make boundary nodes for elements located completely inside the bounding box
by svn commit 01 Nov '12

01 Nov '12

Version 2370 was commited by wanmil on 2012-11-01 11:07:58 +0000 (Thu, 01 Nov 2012) Do not try to make boundary nodes for elements located completely inside the bounding box The LineClipper is now able to indicate that an element is completely within the bounding box This can be used by the makeBoundaryNodes() method that tried to make boundary nodes for all elements located completely within the bounding box.

3 3