April 2015 - mkgmap-dev - The mkgmap lists

mp errors and basecamp hanging up
by nwillink 10 Apr '15

10 Apr '15

Hi Have spent a long time trying to work out why 2 seemingly identical files can cause havoc when parsing. My humble findings might be of use to anyone creating their own mp files from say a gpx or a kml I have attached 2 files: 1.mp parses correctly 1witherrors.mp contains several changes, one of which is difficult to spot but causes Java errors ie spot the difference: Level0=24 Level0=24 The first one causes Java errors download from http://files.mkgmap.org.uk/download/261/2mpfiles.zip Main problem: Some irrelevant spaces are not trimmed but cause the parser to choke [POLYLINE ] [ POLYLINE ] Level0=24(spcs) Uppercase specific [Polyline] (not allowed) [End] (not allowed but no error message) This is a fatal error, not fatal in mkgmap but basecamp etc as it creates empty maps. Perhaps an error msg is needed In fact it causes basecamp to hang up and a restart is impossible without uninstalling the offending mapset. Lowercase/Uppercase specific DATA0: causes a Java problem r Nick -- View this message in context: http://gis.19327.n5.nabble.com/mp-errors-and-basecamp-hanging-up-tp5840285.… Sent from the Mkgmap Development mailing list archive at Nabble.com.

2 2

SEVERE internal error in restriction relation
by Thorsten Kukuk 10 Apr '15

10 Apr '15

Hi, Today I found in the log files this severe error message: 2015/04/08 03:16:45 SEVERE (RestrictionRelation): 71200051.osm.pbf: internal error: number of via points and via ways no longer fits osm.thkukuk.de/tmp/71200051.osm.pbf is the input file. I don't know, but at least for me it would be helpful to have a reference, at least the coordinates, where this happens, so that I could check if the OSM data is buggy or what else the reason could be. Thorsten -- Thorsten Kukuk, Senior Architect SLES & Common Code Base SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)

3 7

Commit: r3531: disable debug code causing an error message
by svn commit 10 Apr '15

10 Apr '15

Version mkgmap-r3531 was committed by gerd on Fri, 10 Apr 2015 disable debug code causing an error message

1 0

Commit: r3530: fix handling of restriction relation with multiple via ways containing a self-intersection
by svn commit 10 Apr '15

10 Apr '15

Version mkgmap-r3530 was committed by gerd on Fri, 10 Apr 2015 fix handling of restriction relation with multiple via ways containing a self-intersection and via ways with additional junction. Relation 4769034 has 4 via ways building a square. The last via way ends at the beginning of the first. Some via ways are also connected to other roads. The old code did not properly identify the correct combination of via points and printed an error message "internal error: number of via points and via ways no longer fits"

1 0

addr:place support
by Gerd Petermann 09 Apr '15

09 Apr '15

Hi all, some month ago we discussed the idea to implement addr:place support. It it assumed that an address has addr:housenumber and either addr:place or addr:street. Up to now those with addr:place are ignored. It is also assumed that the addr:place tag is used in hamlets and small villages and that the roads in such a hamlet have no name. I've coded the following simple approach: For each element (node/way) with addr:housenumber=* and addr:place=* and addr:street!=* search the nearest routable way that has no name (mkgmap:street!=*) If the closest road is within a given range (150m), store the place name as a possible road name. Perform a 2nd search to find also the closest road with a name or ref. If we find exactly one possible name for the road, use it. Problem 1) What should happen if the algo finds multiple possible names for one road? This happens quite often. Typical reasons: a) The road is rather long and connects two or more hamlets. I think it would be best to split the road so that we can give it different names. Maybe split into three parts so that the part between the hamlets stays unnamed. b) The road is near the boundary (or on the boundary). Houses on the left belong to hamlet A, the others to B. This is a bit more complicated. I see these possible solutions: b1) ignore the road and the houses which are close to it (address search will not find them) b2) duplicate the road and give the original road the name A and the copy the name B Problem 2) What should happen when the closest road is one with a name and the closest unnamed road is too far away? I think in many cases we have to treat this as an error in the OSM data . Problem 2b) What should happen when the closest road is one with a name and the closest unnamed road is a bit more away, e.g. 20m and 50m ? I fear this will require complex analysis, so it will be ignored for now. Problem 3) What should happen when the closest road is one with a ref, but no name? I think this is like problem 1). We can split the road, give the part through the hamlet the name of the hamlet (in addition to the ref) Do you see other possible problems or solutions? Is one of the suggested solutions a no-go? Any input is welcome. Gerd

6 32

[Patch v1] display tool NodCheck
by Gerd Petermann 09 Apr '15

09 Apr '15

Hi Steve, I noticed that NodCheck reports an error when a road has no NOD information while the img file contains a NOD subfile. Attached patch seems to fix that. I fear the reason for this error is that no Garmin map with a NOD file contains roads with RoadDef.NET_FLAG_NODINFO = false or why didn't you face this problem up to now ? Gerd

2 2

Commit: r3528: improve logging: report restriction relation details in
by svn commit 08 Apr '15

08 Apr '15

Version mkgmap-r3528 was committed by gerd on Wed, 08 Apr 2015 improve logging: report restriction relation details in "internal error: number of via points and via ways no longer fits" message

1 0

several maps in a single "set" - how to avoid it?
by Johann Murauer 07 Apr '15

07 Apr '15

2 2

Strange Exception in Mkgmap
by UliBaer 07 Apr '15

07 Apr '15

Hi, i get a strange Exception in mkgmap: SCHWERWIEGEND (StyledConverter): 66923072.o5m: Found multiple points with equal coords as CoordPOI at http://www.openstreetmap.org/?mlat=52.343451&mlon=9.904486 &zoom=17 SCHWERWIEGEND (StyledConverter): 66923072.o5m: Found multiple points with equal coords as CoordPOI at http://www.openstreetmap.org/?mlat=52.343451&mlon=9.904486 &zoom=17 I got this exception on the last weekend with version 3498 but the resulting gmapsupp.img was working fine on my etrex Vista HCx. So today i downloaded the latest Europe extract from geofabrik, cut out Germany with osmconvert and a custom .poly file and compiled with the newest version 3523 of mkgmap. Same exception occurs and the resulting gmapsupp.img is working fine. Do i have to worry about this or is this just a glitch in the matrix, ääh, data, that should be mentioned at Openstreetmap? Regards, Uli -- View this message in context: http://gis.19327.n5.nabble.com/Strange-Exception-in-Mkgmap-tp5839969.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 2

error
by Steve Sgalowski 05 Apr '15

05 Apr '15

i am now getting lots of erros with java out of memory with gc i have jave 8 and java 7 installed as some programs wont work with 8 Stephen

1 0