December 2012 - mkgmap-dev - The mkgmap lists

Strange routing directions
by Francisco Moraes 20 Dec '12

20 Dec '12

Hi, I've noticed several times this but never remembered to email about it. My GPS always tells me to turn right on Park Village Dr when I am driving the full extent of it (http://www.openstreetmap.org/browse/way/18912622) There seems to be something near the intersection with Trents Wood Way where it always says turn right into PV Dr, even when coming from PV Dr itself. I've noticed similar instructions before, for example when traveling south on Miami Blvd (http://www.openstreetmap.org/browse/way/111782086) and continuing straight south, it always says to turn right into NC-54/S Miami Blvd. Thoughts? Francisco

1 0

splitter xml support
by GerdP 20 Dec '12

20 Dec '12

Hi all, did anybody notice that splitter still ignores sub-relations when xml is used as input? Is that intended? I guess no. The question is: Should this be added to the xml parser or can we drop xml support (for input) in splitter ? I assume xml is most often only used to test something, but in this case it should work the same way as pbf or o5m, right? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-xml-support-tp5741216.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

1 0

splitter "fine tuning"
by GerdP 19 Dec '12

19 Dec '12

Hi all, some time ago we discussed whether splitter could somehow exchange information with mkgmap. I think the idea was that mkgmap (or the style system) can remove many or all nodes from a tile which leads to problems. I assume this problem is solved with the new split algorithm? If not: Splitter writes the file densities-out.txt, which contains the node counters. It can also read that file, and it would not be very difficult to manipulate the counters somehow. I stll see one option to improve splitter throughput: Before reading any osm file, mkgmap creates a list of all tag keys which are needed (hard coded keys and those from the style files). All other tags are simply ignored when reading OSM data to save memory. If we would give this list to splitter we could probably save a lot of processing time when splitter ignores these tags as well. On the other hand, you have to execute splitter again if you change a style. What do you think? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-fine-tuning-tp5741064.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 5

splitter: relations to be checked with keep-complete=true
by WanMil 19 Dec '12

19 Dec '12

Hi, splitter r260 with --keep-complete=true puts all members of all intersecting relations and all subrelations into a tile. This leads to "interesting" data in tiles, e.g. if a tile is crossed by an e-road (e.g. E 35 http://www.openstreetmap.org/browse/relation/2148378) the complete e-road is added to the tile. I think this is not required as long as mkgmap is not able to handle all of such relations: * subrelations: I think subrelations are not handled by mkgmap so they can be ignored completely by keep-complete. (Keep the code, sometime mkgmap will handle them ;-) * relations: I found code for the following relation types only: multipolygon boundary (is ignored by splitter?) restriction through_route I think all other relations can be ignored by keep-complete. (I don't know about the special marine code...) What do you think about? Any objections? WanMil

4 10

areas.poly from splitter
by Minko 19 Dec '12

19 Dec '12

Gerd, I observed a minor issue, the splitter produces an areas.poly file which JOSM can't read: Unable to parse 1,004957e+01 as a number Seems it can only read decimal points instead of commas. Minko

3 6

Re: [mkgmap-dev] Splitter crashing on asia.osm.pbf with --keep-complete
by Felix Hartmann 19 Dec '12

19 Dec '12

Thanks for the quick reply Gerd, Nope, same problem with 202. I don't know at all where the problem comes from. Too bad but Qlandkarte GT doesn't like the map either (shows blank only) - so I'm not sure why this happens. Maybe the single tiles are too big. The easternmost tiles span around 48°... Or the map should stop at 179° instead of 180°? I cannot remember, that an Asia extract from geofabrik, ever worked without that bug... Garmin did have a worldmap once, dunno if that could give clues to the max tile sizes? On 19.12.2012 16:47, Gerd Petermann wrote: > Felix, > > I don't think that this is related to the use of a polygon, because > that influences > only the sizes and positions of the tiles. Do you think the problem is > caused > by the way how splitter r264 splits asia.osm.pbf? > Does it work if you use r202 for splitting? > > Gerd > > > > Date: Wed, 19 Dec 2012 16:28:08 +0100 > > From: extremecarver(a)gmail.com > > To: mkgmap-dev(a)lists.mkgmap.org.uk > > Subject: Re: [mkgmap-dev] Splitter crashing on asia.osm.pbf with > --keep-complete > > > > Well I tried out 264 without a polygon, and it's fixed and the empty > > area in the west is taken out. But Mapsource still cuts the map when > > zooming in at around 142 East. Is this the same when using a polygon? > > On 19.12.2012 09:57, GerdP wrote: > > > Felix Hartmann-2 wrote > > >> yep. I think the actual data is no more than 150° (east 31 to > 180)- but > > >> the sea info around adds more to it so it starts already at W2°) > > >> On 18.12.2012 22:46, Gerd Petermann wrote: > > > The error was in the new split algorithm. This is fixed with r264. > > > > > > While fixing the error I found a general problem: > > > Some objects in the OSM database are crossing large areas, eg. > > > "The Arctic Circle" > > > http://www.openstreetmap.org/browse/way/162812278 > > > > > > Since the asia extract contains this way completely, splitter > creates a tile > > > that covers > > > almost whole Europe if you don't provide a bounding polygon. > > > I've attached the results, once with using > --polygon-file=asia.poly, once > > > without. > > > > > > asia.zip <http://gis.19327.n5.nabble.com/file/n5740975/asia.zip> > > > Gerd > > > > > > > > > > > > > > > > > > > > > -- > > > View this message in context: > http://gis.19327.n5.nabble.com/Splitter-crashing-on-asia-osm-pbf-with-keep-… > > > Sent from the Mkgmap Development mailing list archive at Nabble.com. > > > _______________________________________________ > > > mkgmap-dev mailing list > > > mkgmap-dev(a)lists.mkgmap.org.uk > > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > -- > > keep on biking and discovering new trails > > > > Felix > > openmtbmap.org & www.velomap.org > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

1 0

Re: [mkgmap-dev] Splitter crashing on asia.osm.pbf with --keep-complete
by Felix Hartmann 19 Dec '12

19 Dec '12

yep. I think the actual data is no more than 150° (east 31 to 180)- but the sea info around adds more to it so it starts already at W2°) On 18.12.2012 22:46, Gerd Petermann wrote: > Hi Felix, > > the problem is caused by the new check for large tiles. > The log shows a hint: > > Please specify a bounding polygon with the --polygon-file parameter. > You might try this. In the meantime I'll try to reproduce it and find > a better solution. > This is the geofabrik asia.osm.pbf, right ? > > Gerd > > > Date: Tue, 18 Dec 2012 22:22:20 +0100 > > From: extremecarver(a)gmail.com > > To: mkgmap-dev(a)lists.mkgmap.org.uk > > Subject: [mkgmap-dev] Splitter crashing on asia.osm.pbf with > --keep-complete > > > > Please see below output, this is happening since --keep-complete was > > introduced. This report is from splitter rev. 263 > > any idea on how to go on about it? Also I noted that Mapsource/Basecamp > > won't display the most eastern part of Asian map since quite a long > time.... > > > > I suppose it has something to do with >179°?? > > > > java -Xmx6600m -jar splitter.jar --max-nodes=800000 --output=pbf > > "--keep-complete" --max-areas=255 --geonames-file=cities15000 > > --description=as > > asia.osm.pbf > > Splitter version unknown compiled 2012-12-18T12:44:14+0100 > > cache= > > description=asia > > geonames-file=cities15000 > > keep-complete=true > > mapid=65400000 > > max-areas=255 > > max-nodes=800000 > > max-threads=8 (auto) > > mixed=false > > no-trim=false > > output=pbf > > output-dir= > > overlap=-1 > > polygon-file= > > problem-file= > > problem-report= > > resolution=13 > > split-file= > > status-freq=120 > > stop-after=dist > > write-kml= > > Elapsed time: 0s Memory: Current 122MB (2MB used, 120MB free) Max 5866MB > > Time started: Tue Dec 18 18:24:02 CET 2012 > > Map is being split for resolution 13: > > - area boundaries are aligned to 0x800 map units (0.0439453125 degrees) > > - areas are multiples of 0x800 map units wide and high > > Processing c:\openmtbmap\osmpbf_geofabrik\asia.osm.pbf > > Bounding box -179.99990000000003 -17.06773 179.99990000000003 84.52666 > > 10'000'000 nodes processed... id=345469396 > > 20'000'000 nodes processed... id=602633323 > > 30'000'000 nodes processed... id=735433109 > > 40'000'000 nodes processed... id=766952699 > > 50'000'000 nodes processed... id=929389508 > > 60'000'000 nodes processed... id=1054713652 > > 70'000'000 nodes processed... id=1169860237 > > 80'000'000 nodes processed... id=1244176605 > > 90'000'000 nodes processed... id=1296405869 > > 100'000'000 nodes processed... id=1346975878 > > 110'000'000 nodes processed... id=1401150913 > > 120'000'000 nodes processed... id=1451567888 > > 130'000'000 nodes processed... id=1502517075 > > 140'000'000 nodes processed... id=1594119652 > > 150'000'000 nodes processed... id=1667582161 > > 160'000'000 nodes processed... id=1730324902 > > 170'000'000 nodes processed... id=1799260316 > > 180'000'000 nodes processed... id=1864129020 > > 190'000'000 nodes processed... id=1943914135 > > 200'000'000 nodes processed... id=2017718514 > > in 1 file > > Time: Tue Dec 18 18:25:32 CET 2012 > > Exact map coverage is (-17.067711353302002,-179.9998927116394) to > > (84.52664136886597,179.9998927116394) > > Rounded map coverage is (-17.0947265625,-180.0) to (84.55078125,180.0) > > Splitting nodes into areas containing a maximum of 800'000 nodes each... > > Highest node count in a single grid element is 259'791 > > Trying to find nice split for (-17.0947265625,-180.0) to > > (84.55078125,180.0) with 207'716'938 nodes > > Trying non-natural splits with spread 3 ... > > Trying non-natural splits with spread 5 ... > > Trying non-natural splits with spread 7 ... > > stored states 10000 > > Split was not yet succesfull. Trying to remove large empty areas... > > Failed to calculate areas. See log for details. > > Failed to calculate areas. > > Sorry. Cannot split the file without creating huge, almost empty, tiles. > > Please specify a bounding polygon with the --polygon-file parameter. > > Time finished: Tue Dec 18 18:25:37 CET 2012 > > Total time taken: 95s > > > > -- > > keep on biking and discovering new trails > > > > Felix > > openmtbmap.org & www.velomap.org > > > > > > _______________________________________________ > > mkgmap-dev mailing list > > mkgmap-dev(a)lists.mkgmap.org.uk > > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

2 2

Splitter crashing on asia.osm.pbf with --keep-complete
by Felix Hartmann 18 Dec '12

18 Dec '12

Please see below output, this is happening since --keep-complete was introduced. This report is from splitter rev. 263 any idea on how to go on about it? Also I noted that Mapsource/Basecamp won't display the most eastern part of Asian map since quite a long time.... I suppose it has something to do with >179°?? java -Xmx6600m -jar splitter.jar --max-nodes=800000 --output=pbf "--keep-complete" --max-areas=255 --geonames-file=cities15000 --description=as asia.osm.pbf Splitter version unknown compiled 2012-12-18T12:44:14+0100 cache= description=asia geonames-file=cities15000 keep-complete=true mapid=65400000 max-areas=255 max-nodes=800000 max-threads=8 (auto) mixed=false no-trim=false output=pbf output-dir= overlap=-1 polygon-file= problem-file= problem-report= resolution=13 split-file= status-freq=120 stop-after=dist write-kml= Elapsed time: 0s Memory: Current 122MB (2MB used, 120MB free) Max 5866MB Time started: Tue Dec 18 18:24:02 CET 2012 Map is being split for resolution 13: - area boundaries are aligned to 0x800 map units (0.0439453125 degrees) - areas are multiples of 0x800 map units wide and high Processing c:\openmtbmap\osmpbf_geofabrik\asia.osm.pbf Bounding box -179.99990000000003 -17.06773 179.99990000000003 84.52666 10'000'000 nodes processed... id=345469396 20'000'000 nodes processed... id=602633323 30'000'000 nodes processed... id=735433109 40'000'000 nodes processed... id=766952699 50'000'000 nodes processed... id=929389508 60'000'000 nodes processed... id=1054713652 70'000'000 nodes processed... id=1169860237 80'000'000 nodes processed... id=1244176605 90'000'000 nodes processed... id=1296405869 100'000'000 nodes processed... id=1346975878 110'000'000 nodes processed... id=1401150913 120'000'000 nodes processed... id=1451567888 130'000'000 nodes processed... id=1502517075 140'000'000 nodes processed... id=1594119652 150'000'000 nodes processed... id=1667582161 160'000'000 nodes processed... id=1730324902 170'000'000 nodes processed... id=1799260316 180'000'000 nodes processed... id=1864129020 190'000'000 nodes processed... id=1943914135 200'000'000 nodes processed... id=2017718514 in 1 file Time: Tue Dec 18 18:25:32 CET 2012 Exact map coverage is (-17.067711353302002,-179.9998927116394) to (84.52664136886597,179.9998927116394) Rounded map coverage is (-17.0947265625,-180.0) to (84.55078125,180.0) Splitting nodes into areas containing a maximum of 800'000 nodes each... Highest node count in a single grid element is 259'791 Trying to find nice split for (-17.0947265625,-180.0) to (84.55078125,180.0) with 207'716'938 nodes Trying non-natural splits with spread 3 ... Trying non-natural splits with spread 5 ... Trying non-natural splits with spread 7 ... stored states 10000 Split was not yet succesfull. Trying to remove large empty areas... Failed to calculate areas. See log for details. Failed to calculate areas. Sorry. Cannot split the file without creating huge, almost empty, tiles. Please specify a bounding polygon with the --polygon-file parameter. Time finished: Tue Dec 18 18:25:37 CET 2012 Total time taken: 95s -- keep on biking and discovering new trails Felix openmtbmap.org & www.velomap.org

1 0

Commit: r2412: merge the o5m-support branch
by svn commit 18 Dec '12

18 Dec '12

Version 2412 was committed by gerd on 2012-12-17 13:41:46 +0000 (Mon, 17 Dec 2012) merge the o5m-support branch

5 16

Commit: r2415: - correction: o5m reader did not call OsmHandler.startWay()
by svn commit 18 Dec '12

18 Dec '12

Version 2415 was committed by gerd on 2012-12-18 12:37:04 +0000 (Tue, 18 Dec 2012) - correction: o5m reader did not call OsmHandler.startWay()

1 0