May 2011 - mkgmap-dev - The mkgmap lists

Empty Areas in US West (Area too small to split)?
by Dominik Röttsches 06 May '11

06 May '11

Hi, when I take the geofabrik US West extract, run it through splitter and then try to run mkgmap on it, I get errors on a couple of areas [1]. I tried reducing the max-nodes parameter for the splitter from 1000000 to 750000, that didn't help. The problem in this case seems to be not too many nodes, but rather *too few*. When I try loading those mentioned areas into JOSM, I get an error message: "No data found for this area." Mkgmap doesn't seem to handle this well. The map generation process stalls without any further error message. Could this be fixed? I can provide the original us-west.osm.pbf on request. Regards, Dominik [1] Log Output: SEVERE (MapSplitter): ../63240355.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=38.93716&mlon=-121.78252&zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): ../63240355.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=38.93716&mlon=-121.78252&zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): ../63240363.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=35.72533&mlon=-120.98516&zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): ../63240363.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=35.72533&mlon=-120.98516&zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): ../63240358.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=34.96583&mlon=-111.85854&zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): ../63240358.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=34.96583&mlon=-111.85854&zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): ../63240358.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=34.96583&mlon=-111.85854&zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): ../63240358.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=34.96583&mlon=-111.85854&zoom=17 (reduce the density of points, length of lines, etc.) SEVERE (MapSplitter): ../63240358.osm.gz: Area too small to split at http://www.openstreetmap.org/?mlat=34.96583&mlon=-111.85854&zoom=17 (reduce the density of points, length of lines, etc.)

2 3

Country specific rules and default country / region or "--country-name=..."
by Felix Hartmann 05 May '11

05 May '11

Could the locator version be changed in such a way, that there are options to set the country and region using commandline/variables (and then drop all processing for country/region). I'm not sure if there is a difference between default country and actual country, but if there is then there should be different commands than the current --country-name= --country-abbr= area-name= This would be more than useful when using a geofabrik extract from a country or from a region (e.g. German Bundesland, or English/French state). That way it would save processing time, and be probably more correct (the very small errors in the geofabrik polygons defining the area, don't matter, as one does not expect to search for addresses outside of the country / region). (or is this implemented already, because on the trunk the --country=ABC seems not to be used, or worse I suspect that the --geonames-file=cities15000 from splitter and it's joining are used (which places addresses outside of the country, if close to a big city but belonging to another region -- or do I have to drop the geonames file if using locator branch?)

2 4

continue statement and order of drawn ways?
by Thorsten Kukuk 04 May '11

04 May '11

Hi, I tried to create a map where you can see arrows for oneway streets. For this I have the normal street, and wanted to create an overlay containing an arrow and a transparent background. I tried this with the continue statement. I tried the following statements: highway=motorway & oneway=yes [0x01 road_class=4 road_speed=7 level 6 continue] highway=motorway & oneway=yes [0x10f01 level 6] and highway=motorway & oneway=yes [0x10f01 level 6 continue] highway=motorway & oneway=yes [0x01 road_class=4 road_speed=7 level 6] But with both statements, the arrow is always drawn below the street. Is it somehow possible to have the arrow on top of the street? Thanks, Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)

7 11

Re: [mkgmap-dev] Address search map information needed
by Francisco Moraes 04 May '11

04 May '11

On 5/3/2011 6:41 PM, mkgmap-dev-request(a)lists.mkgmap.org.uk wrote: > Any place tagged as city/town/village should be in the cities list. Not sure what that means. I searched for my street and it showed a near by area with a different name than the city the street is located at. Is there anything written on how the relationship of streets to city/state/country works for mkgmap purposes? > You need to send the map to the device from MapSource. The > gmapsupp.img generated by mkgmap doesn't (yet) include the address index. Ok, I will have to try that again then. I tried to install the gmapsupp.img file and didn't use MapSource to do it. Good to know so that next time I try, I will use MapSource. Francisco

2 1

Splitter output files are nearly empty
by Lambertus 04 May '11

04 May '11

Recently I've upgraded upgraded all my Garmin map making tools to the latest versions: Osmosis 0.39 Splitter r171 Mkgmap r1926 Since then I'm having a problem while splitting the planet file: all output files are empty (~160 bytes). In de commandline output I notice two things for which I seek input: - What does "***** Full GC *****" mean? - Is input from stdin still functional/supported for splitter? Below is the commandline and output. Commandline: bunzip2 -d -c -k /home/lambertus/planet.openstreetmap.org/world.osm.bz2 | ~/garmin/utils/osmosis/bin/osmosis --rx - --tf reject-ways building=* --tf reject-nodes type=communication --tf reject-ways admin_level=8 --tf reject-ways admin_level=9 --tf reject-ways admin_level=10 --wx file='-' | java -Xmx7500m -ea -jar ~/garmin/utils/splitter/splitter.jar --no-trim --cache=cache --mapid=63240001 --max-nodes=1400000 --write-kml=world.kml --geonames-file=/home/lambertus/garmin/utils/cities15000.zip /dev/stdin Commandline output (where [...] are multiple similar lines removed for readability): cache=cache description= geonames-file=/home/lambertus/garmin/utils/cities15000.zip legacy-mode=false mapid=63240001 max-areas=255 max-nodes=1400000 max-threads=4 (auto) mixed=false no-trim=true output-dir= overlap=2000 resolution=13 split-file= status-freq=120 write-kml=world.kml Elapsed time: 0s Memory: Current 119MB (2MB used, 117MB free) Max 6666MB Time started: Mon May 02 23:00:41 CEST 2011 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 /dev/stdin May 2, 2011 11:00:42 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Osmosis Version 0.39 May 2, 2011 11:00:43 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Preparing pipeline. May 2, 2011 11:00:43 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Launching pipeline execution. May 2, 2011 11:00:43 PM org.openstreetmap.osmosis.core.Osmosis run INFO: Pipeline executing, waiting for completion. Elapsed time: 2m 0s Memory: Current 119MB (4MB used, 115MB free) Max 6666MB A <bounds/> tag was found. Area covered is (-90.0,-180.0) to (90.0,180.0) 2,500,000 nodes processed... [...] 117,500,000 nodes processed... ***** Full GC ***** Elapsed time: 18m 0s Memory: Current 135MB (106MB used, 29MB free) Max 6666MB [...] 267,500,000 nodes processed... ***** Full GC ***** Elapsed time: 38m 0s Memory: Current 152MB (121MB used, 31MB free) Max 6666MB [...] 412,500,000 nodes processed... ***** Full GC ***** Elapsed time: 58m 0s Memory: Current 154MB (122MB used, 32MB free) Max 6666MB [...] 567,500,000 nodes processed... ***** Full GC ***** Elapsed time: 1h 18m 0s Memory: Current 152MB (122MB used, 30MB free) Max 6666MB [...] 717,500,000 nodes processed... ***** Full GC ***** Elapsed time: 1h 38m 0s Memory: Current 156MB (122MB used, 34MB free) Max 6666MB [...] 875,000,000 nodes processed... ***** Full GC ***** Elapsed time: 1h 58m 0s Memory: Current 151MB (121MB used, 30MB free) Max 6666MB [...] 1,060,000,000 nodes processed... Elapsed time: 2h 22m 0s Memory: Current 152MB (128MB used, 24MB free) Max 6666MB 1,062,500,000 nodes processed... in 1 file Time: Tue May 03 01:22:59 CEST 2011 Exact map coverage is (-90.0,-180.0) to (90.0,180.0) Trimmed and rounded map coverage is (-84.990234375,-180.0) to (85.078125,180.0) Splitting nodes into areas containing a maximum of 1,400,000 nodes each... Area (-84.990234375,-180.0) to (16.083984375,-89.47265625) contains 748,264 nodes. DONE! [...] Area (50.009765625,132.1875) to (85.078125,180.0) contains 858,788 nodes. DONE! 1158 areas: Area 63240001 covers (0x201000,0xffbed000) to (0x20d000,0xffbff000) [...] Area 63241158 covers (0xffc39000,0xff800000) to (0xb7000,0xffc06000) GT-Guatemala City Writing KML file to ./world.kml Writing out split osm files Tue May 03 01:23:04 CEST 2011 Processing 1158 areas in 5 passes, 232 areas at a time Starting pass 1 of 5, processing 232 areas (63240001 to 63240232) Making SparseMultiMap Making SparseMultiMap Processing /dev/stdin org.xmlpull.v1.XmlPullParserException: only whitespace content allowed before start tag and not a (position: START_DOCUMENT seen a... @1:1) at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1519) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:62) 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) coords occupancy MAP occupancy: 0 ways occupancy MAP occupancy: 0 Thread worker-1 has finished Thread worker-2 has finished Thread worker-0 has finished Starting pass 2 of 5, processing 232 areas (63240233 to 63240464) Making SparseMultiMap Making SparseMultiMap Processing /dev/stdin org.xmlpull.v1.XmlPullParserException: only whitespace content allowed before start tag and not m (position: START_DOCUMENT seen m... @1:1) at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1519) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:62) 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) coords occupancy MAP occupancy: 0 ways occupancy MAP occupancy: 0 Thread worker-0 has finished Thread worker-1 has finished Thread worker-2 has finished Starting pass 3 of 5, processing 232 areas (63240465 to 63240696) Making SparseMultiMap Making SparseMultiMap Processing /dev/stdin org.xmlpull.v1.XmlPullParserException: start tag not allowed in epilog but got t (position: END_TAG seen ...<tag k="abutters" v="residential"/>\n <t... @2:7) at org.xmlpull.mxp1.MXParser.parseEpilog(MXParser.java:1588) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1393) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:62) 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) coords occupancy MAP occupancy: 0 ways occupancy MAP occupancy: 0 Thread worker-1 has finished Thread worker-2 has finished Thread worker-0 has finished Starting pass 4 of 5, processing 232 areas (63240697 to 63240928) Making SparseMultiMap Making SparseMultiMap Processing /dev/stdin org.xmlpull.v1.XmlPullParserException: start tag not allowed in epilog but got t (position: END_TAG seen ...<tag k="maintenance" v="gritting"/>\n <t... @2:7) at org.xmlpull.mxp1.MXParser.parseEpilog(MXParser.java:1588) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1393) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:62) 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) coords occupancy MAP occupancy: 0 ways occupancy MAP occupancy: 0 Thread worker-1 has finished Thread worker-0 has finished Thread worker-2 has finished Starting pass 5 of 5, processing 230 areas (63240929 to 63241158) Making SparseMultiMap Making SparseMultiMap Processing /dev/stdin org.xmlpull.v1.XmlPullParserException: only whitespace content allowed before start tag and not g (position: START_DOCUMENT seen g... @1:1) at org.xmlpull.mxp1.MXParser.parseProlog(MXParser.java:1519) at org.xmlpull.mxp1.MXParser.nextImpl(MXParser.java:1395) at org.xmlpull.mxp1.MXParser.next(MXParser.java:1093) at uk.me.parabola.splitter.AbstractXppParser.parse(AbstractXppParser.java:62) 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) coords occupancy MAP occupancy: 0 ways occupancy MAP occupancy: 0 Thread worker-0 has finished Thread worker-1 has finished Thread worker-2 has finished Time finished: Tue May 03 01:23:04 CEST 2011 Total time taken: 8543s May 3, 2011 2:11:43 AM org.openstreetmap.osmosis.core.Osmosis run INFO: Pipeline complete. May 3, 2011 2:11:43 AM org.openstreetmap.osmosis.core.Osmosis run INFO: Total execution time: 11460683 milliseconds. lambertus@server:~/garmin/world$ ls -lh build total 5.3M -rw-r--r-- 1 lambertus lambertus 159 2011-05-03 01:23 63240001.osm.gz [...]

5 11

Re: [mkgmap-dev] [Talk-de] continue statement and order of drawn ways?
by Henning Scholland 04 May '11

04 May '11

Am 04.05.2011 00:08, schrieb Felix Hartmann: > > > On 04.05.2011 00:05, Henning Scholland wrote: >> Am 03.05.2011 23:37, schrieb Felix Hartmann: >>> >>> On 03.05.2011 23:27, Minko wrote: >>>> Yes, that is also a good alternative, 0x01 as a transparent line >>>> and on top either >>>> 0x10f01 or 0x10f02 >>>> >>> you cannot make a line transparent by omitting it from the typfile, but >>> go ahead and do your tries. >> Yes, but you can use a transparent png-file ;) >> >> Henning >> > And then you have streetnames shown, but no street.... If you remove > the streetnames on 0x01, you remove streetnames on the broken Oregon, > edge 800, gpsmaps 62 series, for all maps (until hard reset) The streetnames should be at 0x01, because this is rendered on top. 0x10f01 or 2 were rendered below and will be visible because of 0x01 is transparent. Henning

4 3

Address search map information needed
by Francisco Moraes 03 May '11

03 May '11

Hi, I've used the --index (and related options) to generate a map with address search for North Carolina. It worked in Map Source but the city relation is not present. What's the appropriate way for data to be marked as in a given city/state/country in OSM? I also was not able to perform any searches from my Oregon 450 with the generated map. Is this actually supported? It asked for the State/Province, but no matter what I typed, I always got an empty result. Francisco

2 1

Non way element X in multipolygon Y
by Carlos Dávila 03 May '11

03 May '11

I get a lot of warnings of the form "Non way element X in multipolygon Y" (e.g. Non way element 247735163 in multipolygon 339577) in which X is a correct "admin_centre" node of a boundary multipolygon relation. Would it be possible to detect "admin_centre" tag when the MP is processed to avoid this warnings in the log?

5 5

[locator] Osmosis parameters required
by WanMil 03 May '11

03 May '11

I have the problem that some ways are missing in the osmosis filtered dump. Here is my osmosis call: osmosis.bat --rb europe.osm.pbf --tf accept-ways boundary=administrative --tf accept-relations boundary=administrative --used-way --used-node --wx europe-boundaries.osm.gz One example what is missing so far: Relation 7374 (http://www.openstreetmap.org/browse/relation/7374) Missing way 41119221 (http://www.openstreetmap.org/browse/way/41119221) The way is not tagged with boundary=administrative but is a member of the boundary=administrative tagged relation 7374. WanMil

4 14

"set name" and Address search
by Felix Hartmann 03 May '11

03 May '11

It is really practical for driving instructions, to add stuff like /{set name='snowpark ${name}' | 'snowpark'}/ However in most cases, this is not wanted to be taken over to the address search. There ideal solution would be to have 3 modi: 1. set mkgmap:name ....=meaning, this name will only be used for the streetname, but not for the address search index 2. set name ...= current behaviour 3. set copy:name ...=take both the original and the new name into the address search. For 1. & 2. I hope they are easy to implement, and think it is really needed. For 3. I think there would need to be some more thought - probably more complicated, but could be nice to have. I would want to use it to have multilingual address search, but I don't know how much and what is possible. Currently I use this for cities, so cities are findable in the city poi search both under their local name, and under their english name. Even better would be of course, If I were able to find 12 Teststreet, Vienna, Austria, but also 12 Teststraße, Wien, Österreich but dunno whether this is acutally possible and won't blow up the index too much.

1 0