- mkgmap-dev - The mkgmap lists

[PATCH v1] - fix routing problems caused by way's bbox being too large
by Mark Burton 03 Nov '09

03 Nov '09

Ok, I think I know what's been going wrong with some people's maps where the routing goes zig-zaggy when the way is longish. However, it's not the number of points in the way or even the length of the way that's wrong. It's because the bounding box becomes sufficiently large that it causes the line to be split by the LineSizeSplitterFilter. This ancient bit of code splits the line so that it doesn't have a bigger bounding box than it thinks is acceptable. Well, that may be OK for plain lines but for routable stuff like roads, it's bad news because there's no node between the two parts of the split line. If, by chance, the point at where the way was split was actually a node anyway, it probably worked OK but for other points, anything could happen! So the attached patch checks the way's bounding box earlier on when it's doing all that boring way size/arc size/node count checking and if the BB gets too large it snips the way in the accustomed fashion. Anyway, please try the attached patch and see if it works OK - (no new bad routing, no assertions, etc.) Bloody hell, another long evening spent hacking mkgmap...

2 1

Does road segmentation influence routing?
by Nakor 03 Nov '09

03 Nov '09

Hello, I was driving north on I-75 around http://www.openstreetmap.org/?lat=42.9038214683533&lon=-83.6452031135559&zo… when I approached exit 109, my GPS indicated to stay on the left. This is a motorway with a motorway_link going out of it as usual and I was wondering why I ot that message? Would it be because the motorway is split by a bridge just one node south of the junction? Thanks, N.

2 3

Commit: r1343: Revised MAX_ARC_LENGTH again, now back down to 75Km.
by svn commit 02 Nov '09

02 Nov '09

Version 1343 was commited by markb on 2009-11-02 17:28:40 +0000 (Mon, 02 Nov 2009) Revised MAX_ARC_LENGTH again, now back down to 75Km. 80Km should have been alright as that is less than 2^14 arc length units but, somehow, it let an arc through that was slightly too long.

3 2

Zero Length Arc Error again
by Chris-Hein Lunkhusen 02 Nov '09

02 Nov '09

Hi, In V1340 my error file is no longer empty : SCHWERWIEGEND (RoadNetwork): Road null (OSM id 24660945) contains zero length arc SCHWERWIEGEND (RoadNetwork): http://www.openstreetmap.org/?lat=47.61462&lon=9.95615&zoom=17 SCHWERWIEGEND (RoadNetwork): Road In den Weiden (50) (OSM id 25619933) contains zero length arc SCHWERWIEGEND (RoadNetwork): http://www.openstreetmap.org/?lat=48.72200&lon=9.37569&zoom=17 SCHWERWIEGEND (RoadNetwork): Road In den Weiden (50) (OSM id 41263850) contains zero length arc SCHWERWIEGEND (RoadNetwork): http://www.openstreetmap.org/?lat=48.72200&lon=9.37569&zoom=17 I am using the --remove-short-arcs option. Chris

3 8

Commit: r1342: Another stab at avoiding routing errors related to too many points in arc.
by svn commit 02 Nov '09

02 Nov '09

Version 1342 was commited by markb on 2009-11-02 16:00:18 +0000 (Mon, 02 Nov 2009) Another stab at avoiding routing errors related to too many points in arc. This version now splits ways at existing nodes if possible and avoids generating short arcs. Still only an interim solution until the real problem is fixed.

1 0

Commit: r1341: Now reports length (in arc length units) of overly long arc.
by svn commit 02 Nov '09

02 Nov '09

Version 1341 was commited by markb on 2009-11-02 16:00:15 +0000 (Mon, 02 Nov 2009) Now reports length (in arc length units) of overly long arc.

1 0

help with --index
by Bennie du Plessis 02 Nov '09

02 Nov '09

>Ok, I retried with V1340 and use the same options like Felix >i.e. --index and --location-autofill=1, now >I can search in MS. > >I've send Felix' openmtbmap to the Nuvi 250, but this device >is still asking for a State/Provinz and no search is possible. Maybe this is GPS related. I use a Nuvi200W Or else there is something missing in our OSM data that the rest have? Which country are you using? Is there any address data in the OSM data? I wish I could test my maps on another GPS to confirm. Or test someone elses map on my GPS. I have downloaded openmtbmap.org Berlin map and will try it tonight. Don't know if it was created with --index though. "Felix' openmtbmap"? Is that from openmtbmap.org? Which map? was it created with --index and did address search work on his GPS? In the mean time I try lots of different option combinations. Maybe I get lucky- I will inform you if it happens and I can determine what made it happen. BennieD

1 0

help with --index
by Bennie du Plessis 02 Nov '09

02 Nov '09

Hi, I still cannot get --index to work on the GPS. Find places in Mapsource is available, but the state/province is greyed out. In the GPS address search is still unavailable. It requires a province name, which it can’t find.(nothing new, but expected to be solved with --index) I set the --region-name & --location-autofill, but it does not seem to have an effect. City search in Mapsource shows City, City, Country indicating that the region info is maybe lost somewhere (if I understand this correct it should be City, City, Region, Country). This is actualy confusing. If I compile without --region-name, the Find shows up as City, City (leaving out the default ABC *country*name that shows up when compiled with --Region-name=***).Does this mean that region is actualy an alternative for country and not for province? The problem could also be device specific. I use a Nuvi 200W (SW Ver 4.00 & unwilling to update), and maybe it just can't cope, but it seems to me that the region province info is already missing in MapSource, so I don't want to give up on the device just yet. Could it be insufficient OSM data? I don't understand relations very well, but I have seen is_in info in the data, with province names (although I don't see where the device will be informed that it is a province name). Should the province be set as a point / node somewhere or is province / region data just collected from cities' / streets' is_in info, or maybe from the relations of admin borders? Shouldn't --region-name option overide bad OSM data in this case (I mean provide region info that is not available from the OSM data- but then again if region is not equivalent to province it won't help) What exactly is the difference between --region-name and --country-name? Can someone please direct me to an OSM area (small if possible) that is known to work correct, and indicate the --options used to compile a map. My apologies if this is a known issue and I missed it somewhere. Zipped forum archives remains unavailable to me. Do you plan to include --index in resources\help\en\options soon? Something like: --index creates mdr & mdx files to enable address searching. It will make the FIND PLACES function in MapSource available, and should enable address searching on a GPS if the maps are send to the GPS via mapsource. If --overview-mapname is not specified it will default to "OSM Map". This will make --road-name-pois redundant if the GPS unit is compatible. *Should the --tdbfile option still be used?* The reg file should look something like this: REGEDIT4 [HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\MapSource\families\FamilyName] "ID"= hex:CD,AB #hex format of family Id; least significant byte, most significant byte; Ax163 Bx162 Cx161 Dx160 "IDX"="C:\\Garmin\\OSM\\ TDBFileName.mdx" "MDR"="C:\\Garmin\\OSM\\ \TDBFileName_mdr.img" [HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\MapSource\families\FamilyName\ProductID] "LOC"="C:\\Garmin\\OSM\\ " "BMAP"="C:\\Garmin\\OSM\\ TDBFileName.img" "TDB"="C:\\Garmin\\OSM\\ TDBFileName.tdb" Regards BennieD

3 3

Invalid label offset found when using --index
by Felix Hartmann 02 Nov '09

02 Nov '09

I split with: max-nodes=1300000 but also lower max-nodes will not help here... Data is South-America from geofabrik.de without --index everything runs fine. with --index all maps are created, but no tdb/basemap and 0kb mdr.img South America is the only country extract where I found this error (does not happen in any european country, Asia, Australia-Oceania) I ran mkgmap with the following options: start /low /b /wait java -enableassertions -jar -Xmx2800M mkgmap.jar --index --max-jobs=3 --latin1 --delete-tags-file=deletetags --adjust-turn-headings --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs=4 --location-autofill=1 --description=openmtbmap_%abr%_%date% --route --country-abbr=%abr% --style-file=new2 --country-name=%country% --mapname=%mapid%0000 --family-id=%mapid% --product-id=1 --series-name=openmtbmap_%abr%_%date% --family-name=mtbmap_%abr%_%date% --tdbfile --overview-mapname=mapset %mapid%0*.osm.gz I have never seen this error mentioned so I though I will just send it in. It happens on mdr.img creation. without --index it works fine. SCHWERWIEGEND (RouteArc): Way RP4 (id 26633902) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way RP4 (id 26633902) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way RP5 (id 37687380) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way RP5 (id 37687380) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RoadNetwork): Road ruas (OSM id 39368817) contains zero length arc SCHWERWIEGEND (RoadNetwork): http://www.openstreetmap.org/?lat=-22.12247&lon=-51.40677&zoom=17 SCHWERWIEGEND (RoadNetwork): Road ruas (OSM id 39368817) contains zero length arc SCHWERWIEGEND (RoadNetwork): http://www.openstreetmap.org/?lat=-22.12245&lon=-51.40677&zoom=17 SCHWERWIEGEND (RoadNetwork): Road ruas (OSM id 39368877) contains zero length arc SCHWERWIEGEND (RoadNetwork): http://www.openstreetmap.org/?lat=-22.12247&lon=-51.40677&zoom=17 SCHWERWIEGEND (RoadNetwork): Road ruas (OSM id 39368877) contains zero length arc SCHWERWIEGEND (RoadNetwork): http://www.openstreetmap.org/?lat=-22.12245&lon=-51.40677&zoom=17 SCHWERWIEGEND (RouteArc): Way ?MS-320 (id 31572666) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way ?MS-320 (id 31572666) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way null (id 28294020) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way null (id 28294020) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RoadNetwork): Road avenida ParaÝba (OSM id 23726122) contains zero length arc SCHWERWIEGEND (RoadNetwork): http://www.openstreetmap.org/?lat=-14.85369&lon=-40.85925&zoom=17 SCHWERWIEGEND (RouteArc): Way ?BR-364 (id 23655710) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way ?BR-364 (id 23655710) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way ?BR-163 (id 31239020) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way ?BR-163 (id 31239020) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way ?BR-174 (id 28957743) contains an arc whose length is too big to be encoded so the road will not be routable SCHWERWIEGEND (RouteArc): Way ?BR-174 (id 28957743) contains an arc whose length is too big to be encoded so the road will not be routable Regions for map: *Exception in thread "main" java.lang.AssertionError: Invalid label offset found 2460949* at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.fetchLabel(LBLFileReader.java:83) at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.readPoiInfo(LBLFileReader.java:348) at uk.me.parabola.imgfmt.app.lbl.LBLFileReader.<init>(LBLFileReader.java:71) at uk.me.parabola.imgfmt.app.map.MapReader.<init>(MapReader.java:80) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onMapEnd(MdrBuilder.java:108) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:361) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:124) at uk.me.parabola.mkgmap.main.Main.main(Main.java:122)

1 0

How many output files?
by Nop 02 Nov '09

02 Nov '09

Hi! Normally, I always got 1 .img output file for each .osm input file when running mkgmap (+1 overview map). In the last run, mkgmap seems to have created 2 .img files for every .osm file. I have never seen this before. The map looks good in MapSource. Is this a deliberate feature or a bug? What could possibly trigger this behaviour? bye Nop

3 4