August 2011 - mkgmap-dev - The mkgmap lists

Suggestion for more flexibility in locator part of mkgmap
by Clifford Nolan 19 Sep '12

19 Sep '12

Hi Greg, Just to clarify ... the admin_levels for Ireland described here http://wiki.openstreetmap.org/wiki/Ireland/Boundaries#Boundary_Types don't seem to mention things like village boundaries - there's a big gap between admin_level=8 and admin_level=10. In situations like this, maybe the locator could be more flexible and use other kinds of boundaries too. Regards, Cliff

3 7

Overview map
by Steve Ratcliffe 19 Jun '12

19 Jun '12

Hi I have started to implement adding features into the overview map. You can find ready built jar files on the download page and in the 'overview' branch in subversion. It creates the overview map from the .img (as before) and so it is very quick to try out even on a set of tiles covering a whole country. There is no configuration yet, it just takes everything (lines and polygons) that is in the least detailed layer of the detailed maps and adds it into the overview. You will immediately notice a big problem in that the overview map shows up even when the detailed maps are being displayed, so you get ugly jagged lines across the top of the map. I remember this happening the last time we has an overview map and I wonder if anyone can remember if there was a solution then? I'm going to start by trying the (so-called) POI flags, as one of those has been noted to be set differently on detail and base maps before. ..Steve

5 15

Country names
by WanMil 24 Jan '12

24 Jan '12

Hi all, I am thinking about the country names that mkgmap puts into the map. (The following lines are valid for the locator branch but the differences to the trunk are quite small) At the moment the country name is taken from the country relation using the tag order defined by the name-tag-list option. This name is looked up in the LocatorConfig.xml. If there is a match (there should be one), the name defined in the LocatorConfig.xml is used as map wide country name. There is the shortcoming that this name need not be the same as specified by the name-tag-list option. So there is some work to do if you want to build a french map that uses french country names only. Would it make sense to use the LocatorConfig.xml just as a mapping tool for the three letter code (name:en => three letter code) and the real name is taken as defined by the name-tag-list option? This has the shortcoming that the relation names contains some administrative stuff "Federal Republic of Germany" instead of "Germany". Any thoughts? WanMil

4 12

License text
by Ralf Kleineisel 01 Jan '12

01 Jan '12

Is it possible to change the license info which is embedded in the IMG header? Now it reads "OSM Street map http://www.openstreetmap.org/ Map data licenced under Creative Commons Attribution ShareAlike 2.0 http://creativecommons.org/licenses/by-sa/2.0/", but this is not correct when making maps from other data sources. For example contour line layers made of SRTM data do not contain any OSM data.

6 14

exclude words from city / state
by Felix Hartmann 10 Dec '11

10 Dec '11

Using the locator branch, I noticed that many cities in Austria are not findable anymore. The problem is that there are words like "Gemeinde Mödling" or "Bezirk Mödling" or "county XYZ". There should be a list where one can enter words that get deleted. That is because for the boundary it is the correct name, but not for searching a street. Also there are problems in Austria in Vienna. Vienna is a state and a city, and ideally it should be possible to enter either the district or the city into the city field, in order to find a street. Currently it is not possible to properly separate cities outside Vienna from districts inside Vienna, as they have the same admin_level. But for the ise tags, there is a correct specification telling you that districts are not cities (from the standpoint of the admin_level, it is correct however to classify them the same as small cities outside of Vienna). So in effect if one does not enter specific rules for Vienna, address search can never work as expected. Admin_level was never intended to be used for address searching, hence taking it is flawed and will not provide correct results. Ise is intended for address searching, but mkgmap does not use it. In general after using the locator branch, I more and more think, that the whole matching is completly the wrong way of doing. Much better to support real addresses as entered in OSM, and not do so much guessing. Especially support housenumbers, as at least in Germany and Austria housenumbers including full ise tags are becoming the norm, and not the exception. Only footways, pathes, or tracks should be matched, as they usually have no real address - but then it's rare that one searches for a specific path/track/footway, only real use would therefore be

10 24

Short mkgmap HowTo
by WanMil 22 Nov '11

22 Nov '11

Hi, I have created a short HowTo in the wiki for first time users: http://wiki.openstreetmap.org/wiki/Mkgmap/How_to_create_a_map I think that's a good thing for first time users because the other wiki pages contain a bit too much information if you are using mkgmap for the first time. Please have a look on it if I have forgotten something or if something is wrong. Thanks! WanMil

11 28

Problems with latest splitter versions
by Michael Prinzing 12 Nov '11

12 Nov '11

Hi, I am getting the splitter from svn, compiling and running it unter Windows XP SP3 using JDK 1.6.0_25. There are 2 problems if I am using a splitter version newer than r161 (tryed until r167 so far). 1.) germany.osm.pbf from geofabrik cannot be split -------------------------------------------------- Invoking the splitter with java.exe -Xms256m -Xmx1536m -server -jar splitter.jar --resolution=14 --overlap=4000 --max-nodes=1200000 --max-areas=50 --geonames-file=cities1000.zip germany.osm.pbf The data is split into 76 areas, so there are 2 passes to go. First, everything looks fine, but then, at the and of the first pass, the splitter "falls asleep", the CPU load for the corresponding JVM drops to 0% and there ist no further progress (except the memory stats being printed periodically). The output looks like this (cut a lot of lines): cache= description= geonames-file=cities1000.zip legacy-mode=false mapid=63240001 max-areas=50 max-nodes=1200000 max-threads=1 (auto) mixed=false no-trim=false output-dir= overlap=4000 resolution=14 split-file= status-freq=120 write-kml= Elapsed time: 0s Memory: Current 247MB (1MB used, 246MB free) Max 1484MB Time started: Wed Mar 02 17:11:11 CET 2011 Map is being split for resolution 14: - area boundaries are aligned to 0x400 map units - areas are multiples of 0x800 map units wide and high Processing germany.osm.pbf Bounding box 5.864417 47.26543 15.050779999000001 55.14777 10.000.000 nodes processed... id=283576079 20.000.000 nodes processed... id=355168786 30.000.000 nodes processed... id=495365986 40.000.000 nodes processed... id=699656373 50.000.000 nodes processed... id=998291790 60.000.000 nodes processed... id=1127935431 1.000.000 ways processed... id=25049151 2.000.000 ways processed... id=28822644 Elapsed time: 1m 59s Memory: Current 247MB (20MB used, 227MB free) Max 1484MB 3.000.000 ways processed... id=34073254 4.000.000 ways processed... id=40593158 5.000.000 ways processed... id=49931588 6.000.000 ways processed... id=61188933 7.000.000 ways processed... id=83211109 8.000.000 ways processed... id=93106763 9.000.000 ways processed... id=101081600 100.000 ways processed... id=1124462 in 1 file Time: Wed Mar 02 17:14:00 CET 2011 Exact map coverage is (47.26541519165039,5.864403247833252) to (55.147762298583984,15.05077600479126) Trimmed and rounded map coverage is (47.28515625,5.8447265625) to (55.1513671875,15.029296875) Splitting nodes into areas containing a maximum of 1.200.000 nodes each... Area (47.5048828125,7.470703125) to (47.9443359375,8.7451171875) contains 663.137 nodes. DONE! [...] Area (53.8330078125,11.77734375) to (54.931640625,14.2822265625) contains 996.051 nodes. DONE! 76 areas: Area 63240001 covers (0x246800,0x4b000) to (0x24d800,0x4f800) DE-Dusseldorf [...] Area 63240076 covers (0x223000,0x63800) to (0x228800,0x70000) DE-Reutlingen Writing out split osm files Wed Mar 02 17:14:03 CET 2011 Processing 76 areas in 2 passes, 38 areas at a time Starting pass 1 of 2, processing 38 areas (63240001 to 63240038) Making SparseMultiMap Making SparseMultiMap Processing germany.osm.pbf Bounding box 5.864417 47.26543 15.050779999000001 55.14777 Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap MAP occupancy: 832878 MAP occupancy: 158237 MAP occupancy: 8339 MAP occupancy: 546 MAP occupancy: 1652236 MAP occupancy: 326019 MAP occupancy: 19669 MAP occupancy: 2076 MAP occupancy: 2474023 MAP occupancy: 491531 MAP occupancy: 31585 MAP occupancy: 2861 MAP occupancy: 3272326 MAP occupancy: 668457 MAP occupancy: 53049 MAP occupancy: 6168 Elapsed time: 3m 59s Memory: Current 267MB (121MB used, 146MB free) Max 1484MB MAP occupancy: 4072409 MAP occupancy: 847909 MAP occupancy: 73212 MAP occupancy: 6470 MAP occupancy: 4870695 MAP occupancy: 1026785 MAP occupancy: 94770 MAP occupancy: 7750 MAP occupancy: 5673776 MAP occupancy: 1203597 MAP occupancy: 111531 MAP occupancy: 11096 10.000.000 nodes processed... id=283576079 [...] 60.000.000 nodes processed... id=1127935431 MAP occupancy: 37091591 MAP occupancy: 8145968 MAP occupancy: 704292 MAP occupancy: 58149 MAP occupancy: 37918126 MAP occupancy: 8301600 MAP occupancy: 722028 MAP occupancy: 58246 MAP occupancy: 38711472 MAP occupancy: 8485566 MAP occupancy: 744601 MAP occupancy: 58361 Writing ways Wed Mar 02 17:26:02 CET 2011 Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap 1.000.000 ways processed... id=25049151 MAP occupancy: 798645 MAP occupancy: 184591 MAP occupancy: 15271 MAP occupancy: 1493 Elapsed time: 15m 59s Memory: Current 1484MB (705MB used, 779MB free) Max 1484MB 2.000.000 ways processed... id=28822644 [...] 7.000.000 ways processed... id=83211109 Elapsed time: 20m 2s Memory: Current 1484MB (928MB used, 556MB free) Max 1484MB MAP occupancy: 4795349 MAP occupancy: 1103602 MAP occupancy: 94312 MAP occupancy: 6736 MAP occupancy: 1 8.000.000 ways processed... id=93106763 9.000.000 ways processed... id=101081600 MAP occupancy: 5597978 MAP occupancy: 1283033 MAP occupancy: 110757 MAP occupancy: 8231 MAP occupancy: 1 Writing relations Wed Mar 02 17:32:01 CET 2011 100.000 ways processed... id=1124462 coords occupancy MAP occupancy: 39240504 MAP occupancy: 8605635 MAP occupancy: 752197 MAP occupancy: 58361 ways occupancy MAP occupancy: 5634593 MAP occupancy: 1292952 MAP occupancy: 111321 MAP occupancy: 8235 MAP occupancy: 1 Elapsed time: 22m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 24m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 26m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 28m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB Elapsed time: 30m 2s Memory: Current 1484MB (1144MB used, 340MB free) Max 1484MB At this point, nothing more happens, no second pass is done. 2.) File containing contour data cannot be processed ---------------------------------------------------- When generating my maps, I usually add data to draw contour lines. The file containing that data is available from http://osm.arndnet.de/contourdata.osm.gz (not my site!). It is in OSM format 0.5. When buildig a map, I am combining this data with the OSM data (please note that the contour data file contains node IDs starting at 2^31, so they collide with the IDs from "real" OSM data if used unchanged). But even when I am trying to split this file without additional OSM data, the same as above happens and the splitter stops at the end of the first and only pass: java.exe -Xms256m -Xmx1536m -server -jar splitter.jar --resolution=14 --overlap=4000 --max-nodes=1200000 --max-areas=50 --mixed --geonames-file=cities1000.zip contourdata.osm.gz cache= description= geonames-file=cities1000.zip legacy-mode=false mapid=63240001 max-areas=50 max-nodes=1200000 max-threads=1 (auto) mixed=true no-trim=false output-dir= overlap=4000 resolution=14 split-file= status-freq=120 write-kml= Elapsed time: 0s Memory: Current 247MB (1MB used, 246MB free) Max 1484MB Time started: Wed Mar 02 17:43:31 CET 2011 Map is being split for resolution 14: - area boundaries are aligned to 0x400 map units - areas are multiples of 0x800 map units wide and high Processing contourdata.osm.gz 2.500.000 nodes processed... 5.000.000 nodes processed... 7.500.000 nodes processed... 10.000.000 nodes processed... 12.500.000 nodes processed... 15.000.000 nodes processed... 17.500.000 nodes processed... in 1 file Time: Wed Mar 02 17:45:08 CET 2011 Exact map coverage is (47.2760796546936,5.877492427825928) to (55.02375841140747,14.999899864196777) Trimmed and rounded map coverage is (47.28515625,5.86669921875) to (55.0634765625,15.00732421875) Splitting nodes into areas containing a maximum of 1.200.000 nodes each... Area (47.5048828125,6.7236328125) to (49.1748046875,8.525390625) contains 958.841 nodes. DONE! [...] Area (52.822265625,10.17333984375) to (54.7119140625,14.47998046875) contains 885.962 nodes. DONE! 22 areas: Area 63240001 covers (0x23c000,0x54c00) to (0x247800,0x5ec00) DE-Koblenz [...] Area 63240022 covers (0x21c800,0x61000) to (0x22f800,0x6e800) DE-Stuttgart Writing out split osm files Wed Mar 02 17:45:10 CET 2011 Processing 22 areas in a single pass Starting pass 1 of 1, processing 22 areas (63240001 to 63240022) Making SparseMultiMap Making SparseMultiMap Processing contourdata.osm.gz Making SparseMultiMap Writing ways Wed Mar 02 17:45:14 CET 2011 Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap Making SparseMultiMap Elapsed time: 1m 59s Memory: Current 1484MB (1090MB used, 394MB free) Max 1484MB MAP occupancy: 783578 MAP occupancy: 190519 MAP occupancy: 25903 MAP occupancy: 1545344 MAP occupancy: 394559 MAP occupancy: 60097 MAP occupancy: 2398068 MAP occupancy: 533001 MAP occupancy: 68931 2.500.000 nodes processed... MAP occupancy: 3315227 MAP occupancy: 615842 MAP occupancy: 68931 MAP occupancy: 4195362 MAP occupancy: 728752 MAP occupancy: 75886 5.000.000 nodes processed... [...] [...] Elapsed time: 7m 59s Memory: Current 1484MB (1197MB used, 287MB free) Max 1484MB MAP occupancy: 16438198 MAP occupancy: 3986436 MAP occupancy: 575366 MAP occupancy: 17300217 MAP occupancy: 4121087 MAP occupancy: 578696 17.500.000 nodes processed... coords occupancy MAP occupancy: 17896316 MAP occupancy: 4149555 MAP occupancy: 578696 ways occupancy MAP occupancy: 180407 MAP occupancy: 43178 MAP occupancy: 6700 MAP occupancy: 21 MAP occupancy: 1 Elapsed time: 9m 59s Memory: Current 1484MB (1013MB used, 471MB free) Max 1484MB Elapsed time: 11m 59s Memory: Current 1484MB (1014MB used, 470MB free) Max 1484MB Elapsed time: 13m 59s Memory: Current 1484MB (1014MB used, 470MB free) Max 1484MB Elapsed time: 15m 59s Memory: Current 1484MB (1014MB used, 470MB free) Max 1484MB ***** Full GC ***** Elapsed time: 18m 1s Memory: Current 1484MB (923MB used, 561MB free) Max 1484MB Elapsed time: 20m 1s Memory: Current 1484MB (924MB used, 560MB free) Max 1484MB Elapsed time: 22m 1s Memory: Current 1484MB (924MB used, 560MB free) Max 1484MB and so on. I've then converted the data to OSM format 0.6 and sorted it (using --migrate and --sort-0.6 for osmosis) and stored it as .osm.bz2 and .osm.pbf. When I am trying to split these files, I am getting an exception: java.exe -Xms256m -Xmx1536m -server -jar splitter.jar --resolution=14 --overlap=4000 --max-nodes=1200000 --max-areas=50 --geonames-file=cities1000.zip contourdata06.osm.bz2 cache= description= geonames-file=cities1000.zip legacy-mode=false mapid=63240001 max-areas=50 max-nodes=1200000 max-threads=1 (auto) mixed=false no-trim=false output-dir= overlap=4000 resolution=14 split-file= status-freq=120 write-kml= Elapsed time: 0s Memory: Current 247MB (1MB used, 246MB free) Max 1484MB Time started: Wed Mar 02 19:28:48 CET 2011 Map is being split for resolution 14: - area boundaries are aligned to 0x400 map units - areas are multiples of 0x800 map units wide and high Processing contourdata06.osm.bz2 2.500.000 nodes processed... 5.000.000 nodes processed... 7.500.000 nodes processed... Elapsed time: 2m 0s Memory: Current 247MB (81MB used, 166MB free) Max 1484MB 10.000.000 nodes processed... 12.500.000 nodes processed... 15.000.000 nodes processed... Elapsed time: 4m 0s Memory: Current 247MB (61MB used, 186MB free) Max 1484MB 17.500.000 nodes processed... in 1 file Time: Wed Mar 02 19:34:21 CET 2011 Exact map coverage is (47.2760796546936,5.877492427825928) to (55.02375841140747,14.999899864196777) Trimmed and rounded map coverage is (47.28515625,5.86669921875) to (55.0634765625,15.00732421875) Splitting nodes into areas containing a maximum of 1.200.000 nodes each... Area (47.5048828125,6.7236328125) to (49.1748046875,8.525390625) contains 958.841 nodes. DONE! [...] Area (52.822265625,10.17333984375) to (54.7119140625,14.47998046875) contains 885.962 nodes. DONE! 22 areas: Area 63240001 covers (0x23c000,0x54c00) to (0x247800,0x5ec00) DE-Koblenz [...] Area 63240022 covers (0x21c800,0x61000) to (0x22f800,0x6e800) DE-Stuttgart Writing out split osm files Wed Mar 02 19:34:24 CET 2011 Processing 22 areas in a single pass Starting pass 1 of 1, processing 22 areas (63240001 to 63240022) Making SparseMultiMap Making SparseMultiMap Processing contourdata06.osm.bz2 Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: Start index (-30655339) is negative at it.unimi.dsi.fastutil.Arrays.ensureFromTo(Arrays.java:45) at it.unimi.dsi.fastutil.objects.ObjectArrays.ensureFromTo(ObjectArrays.java:351) at it.unimi.dsi.fastutil.objects.ObjectArrays.fill(ObjectArrays.java:313) at it.unimi.dsi.fastutil.objects.ObjectArrayList.size(ObjectArrayList.java:308) at uk.me.parabola.splitter.SparseInt2ShortMapInline.resizeTo(SparseInt2ShortMapInline.java:96) at uk.me.parabola.splitter.SparseInt2ShortMapInline.put(SparseInt2ShortMapInline.java:123) at uk.me.parabola.splitter.SparseInt2ShortMultiMap$Inner.put(SparseInt2ShortMultiMap.java:81) at uk.me.parabola.splitter.SparseInt2ShortMultiMap.put(SparseInt2ShortMultiMap.java:31) at uk.me.parabola.splitter.SplitProcessor.writeNode(SplitProcessor.java:208) at uk.me.parabola.splitter.SplitProcessor.processNode(SplitProcessor.java:118) at uk.me.parabola.splitter.OSMParser.endElement(OSMParser.java:243) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:57) at uk.me.parabola.splitter.Main.processMap(Main.java:399) at uk.me.parabola.splitter.Main.writeAreas(Main.java:355) at uk.me.parabola.splitter.Main.split(Main.java:188) at uk.me.parabola.splitter.Main.start(Main.java:116) at uk.me.parabola.splitter.Main.main(Main.java:105) Both files (the original file in OSM format 0.5 and the converted .osm.bz2 in OSM format 0.6) could be split without a problem using splitter r161. Any ideas what is going wrong there? Anything I could try? Michael

4 3

Coastline issues - analysis and possible solution
by Bartosz Fabianowski 15 Oct '11

15 Oct '11

Hi list I spent the last 12 hours debugging sea generation problems in Europe. After digging through a lot of mkgmap and splitter code, I believe I understand the source of the issues now. Since data is processed in tiles, the sea generator will often encounter coastlines clipped at the tile boundaries. There are heuristics in the code that should produce valid sea multipolygons for tiles with incomplete coastlines as well. However, the heuristics fail for the Geofabrik extracts of several European countries. Here is what I believe the problem to be: The sea generator correctly identifies incomplete coastlines. It then attempts to determine for each such coastline whether it was clipped by a tile boundary. It is this test that fails for some countries, leading to missing or inverted sea. The source of this issue can be traced back to the splitter. Here, tile boundaries are expanded to coarse multiples of Garmin map units. Tiles therefore become larger than originally requested. If map data for the entire expanded area is available, this is OK. But when dealing with country extracts, there may be no data available for some of the expanded regions. Here is an ASCII art example, a rectangular extract with a coastline inside, shown as a double line: +---------+ | | | | |=========| | | +---------+ If this data is fed to mkgmap directly, the sea generator will correctly determine that the coastline was clipped by the left and right tile boundaries. If the data is passed through the splitter first, even if no splitting into multiple tiles should be needed, the tile boundaries are rounded to the multiples of Garmin map units mentioned above. The tile may thus grow: +-----------+ | | | | | | | ========= | | | | | +-----------+ The problem is that now, the coastline no longer touches the tile boundaries. The mkgmap sea generator is confused by this and produces invalid or no sea at all. An obvious but incorrect solution is for the sea generator to check whether the coastline reaches the *original* tile boundary, not the rounded one. This would require the splitter to pass the original boundary to mkgmap along with each tile. The real issue with this solution would be that even if mkgmap correctly detects a clipped coastline, there is no valid data between the original and rounded boundaries. To construct a proper sea multipolygon, mkgmap would have to synthesize a coastline in that space, likely introducing ugly artifacts. A correct solution, already implemented in mkgmap today, is to read coastlines from a separate file. The file should contain coastlines that extend at least as far as the rounded tile boundaries. From the mail archives, it appears that WanMil has identified the same issue before and proposed this very solution [1]. Coastlines for a larger area can be extracted using: osmosis \ --rb larger_area.osm.pbf \ --tf accept-ways natural=coastline \ --tf reject-relations \ --used-node \ --wb coastlines.osm.pbf omitmetadata=true The coaslines.osm.pbf file can then be fed to mkgmap via the --coastlinefile option. While WanMil described this solution in December 2010 already, it seems to have been buried in the mailing list without becoming common knowledge. Another mailing list post [2] shows that the --coastlinefile had been broken for a while without anyone noticing, confirming that it is not in common use. After spending 12 hours on this today, I hope that others will benefit from this write-up instead of having to repeat my odyssey. Anyone wanting to use the --coastlinefile option will require coastlines for a larger region than the extract they are processing. While the option does allow several files to be specified whose contents are then concatenated, it is easiest to load a single file with coastlines for a larger area. I have prepared two such files, one from today's Geofabrik europe.osm.pbf extract, the other from the most recent planet-latest.osm.pbf. Both files can be found at [3]. I am providing these files so that anyone working with extracts can download compact coastlines only instead of having to extract them from the huge europe.osm.pbf or planet-latest.osm.pbf files. Right now, the files were generated once-off. If they are found to be useful by others, I am happy to automate the process and make updated coastline files available on a regular basis. Finally, a word of warning: When using coastlines_planet.osm.pbf, mkgmap needs a *lot* of memory. I found that even for small tiles, 4.5GB of RAM are consumed by the Java process. With coastlines_europe.osm.pbf, the memory consumption is about 2.5GB. - Bartosz [1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q4/009636.html [2] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2011q1/010138.html [3] http://www.fabianowski.eu/osm/coastlines/

7 27

Memory Consumption on Index Creation
by Felix Hartmann 15 Oct '11

15 Oct '11

1. I noticed that (at least for my style-file) 7500MB of RAM available does not suffice to compile a map of Europe including index! However if I recreate the index in another go, then it is no problem. How comes? The index creation seems to be completly independent of the maptiles creation. Is mkgmap leaving stuff inside the memory, that is in reality not needed anymore? 2. Also as running out of memory primarily happens on index creation, it would be great if mkgmap writes out the index under a temporary name, and once it has passed correctly, renames the file. Else it is not possible to easily assess in a bash/batch script whether mkgmap completed the map correctly or not (and hence one uploads broken maps if everything automated). Or at least I don't see any way to find out whether it passed correctly or not.

6 26

Routing - Documentation and Best Practice
by toc-rox 14 Sep '11

14 Sep '11

Currently I'm working on the routing feature of my garmin maps and run into some problems. I was looking for detailed information concerning routing (incl. best pratice) but couldn't find such a document. Question: Could someone point me to such a documentation or describe "the best practice"? Thanks and regards - Klaus -- View this message in context: http://gis.638310.n2.nabble.com/Routing-Documentation-and-Best-Practice-tp6… Sent from the Mkgmap Development mailing list archive at Nabble.com.

7 18