- mkgmap-dev - The mkgmap lists

Backtrace with housenumber branch
by Thorsten Kukuk 14 Apr '15

14 Apr '15

Hi, with the latest releases of the housenumber branch, including r3535, I get the following backtrace when building my bicycle map (the trunk version is fine and works): java.lang.NullPointerException at uk.me.parabola.imgfmt.app.net.RoadNetwork.addThroughRoute(RoadNetwork.java:651) at uk.me.parabola.mkgmap.general.MapDetails.addThroughRoute(MapDetails.java:135) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:658) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:250) at uk.me.parabola.mkgmap.reader.osm.bin.OsmBinMapDataSource.load(OsmBinMapDataSource.java:67) at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:130) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:167) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:63) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:253) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:249) at java.util.concurrent.FutureTask.run(FutureTask.java:274) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1157) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:627) at java.lang.Thread.run(Thread.java:863) Exiting - if you want to carry on regardless, use the --keep-going option Number of ExitExceptions: 1 It's the bicycle style from my web page, and I call mkgmap with: mkgmap --style-file=bicycling --family-name=TK-DACH-Bicycling --country-name=DACH --country-abbr=DACH --area-name=DACH --latin1 --license-file=TK-DACH-Bicycling_license.txt '--copyright-message=OpenStreetMap contributors, ODbL. See: http://www.openstreetmap.org/copyright. TK-DACH-Bicycling based on data from 2015-04-13.' --series-name=TK-DACH-Bicycling --product-version=150414 --add-pois-to-areas '--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance' --reduce-point-density=4 --reduce-point-density-polygon=8 --min-size-polygon=8 --polygon-size-limits=24:8,18:4,17:2,16:0 --make-opposite-cycleways --name-tag-list=name,place_name,loc_name --transparent --no-poi-address -c mkgmap.cfg --gmapsupp -c maps.cfg --description=TK-DACH-Bicycling TK_DACH.TYP 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)

2 4

r3535 with improved addr:place support
by Gerd Petermann 14 Apr '15

14 Apr '15

Hi all, I think addr:place is now also working well, so please test it. See also the description of changes in the svn log: http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3535 If you think that numbers with addr:housenumber=* & addr:street=* & addr:place=* should not be treated as described, feel free to delete the addr:place tag. I still don't fully understand the special cases in CZ, the page http://wiki.openstreetmap.org/wiki/Cs:WikiProject_Czech_Republic/Address_sy… is not available in english and the Google Translator doesn't help me much, so experts for this area: Please double check. Gerd

1 1

Options
by Gerd Petermann 14 Apr '15

14 Apr '15

Hi all, I'd like to change some defaults. My understanding so far is that most people want a routable map with address search and housenumber search. So, I think the following options should be on by default: --route --net --index --housenumbers --x-split-name-index --link-pois-to-ways --drive-on=detect We (the programmers) have to make sure that --no-xyz really disables these options. These are also candidates, but I think we can leave them optional: --make-opposite-cycleways --process-destination --process-exits Did I find a good selection? @Steve: I tried to implement this but found that some unit tests fail, e.g. TdbTest fails when I just add --net to the default options. Can you have a look at this, please?

4 8

r3527
by Gerd Petermann 10 Apr '15

10 Apr '15

Hi all, I've added addr:place support with r3527. Please note that this required some hacks like duplicating roads where the copies are not routable and adding/changing labels. I did not find routing or rendering problems, but I would not be surprised to hear about them. Please test and let me know. TODO : cleanup and improve code that splits intervals and the methods to find close objects. Gerd

2 8

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