March 2015 - mkgmap-dev - The mkgmap lists

Mapsource crashes while calculating a route
by Andrzej Popowski 29 Sep '16

29 Sep '16

Hi, I have observed crashes for some time. Mapsource 6.16.3 indicates a bug in module MPL_MAP.CPP. Basecamp reports an error or goes into infinite loop. Now I have extracted minimal source data, which creates faulty map. Removing any road or even a crossing point restore routing. Bug exist in mkgmap r2815, r2857, r2889, r2975 and r2976. Map created by mkgmap r2795 works correctly. I'm attaching here files to reproduce problem: mkgmap.bat - batch, which I have used to create the map, test-a.pbf - very simple OSM source data, route.gpx - short route, which causes a crash in Mapsource. -- Best regards, Andrzej

4 15

process-exits vs process-destination
by Franco Bez 08 Oct '15

08 Oct '15

Hi all, is there a way to combine the features process-exits and process-destination in a single style ? Based on my experience process-desitnation does a marvellous job when entering a motorway ( does it also work with also trunk roads ? ), while process-extis is perfect when leaving a motorway or trunk road. For instance the roundabout here http://www.openstreetmap.org/?lat=47.89665&lon=10.64805&zoom=17 has two exits towards the B12. Routing from the "Sudetenstraße" going North (maybe towards Augsburg) I would like the Garmin device to announce "5 th Exit - B12 (München)". On the other hand routing to the South (maybe Kempten) it should announce "2nd exit - B12 (Kempten)". Using process-exits this does not work, it's only "5th Exit - B12" resp. "2nd Exit - B12". I would have to use process-destination instead to get the desired messages displayed. Coming home from the trip, routing from the B12 towards "Sudetenstraße" I would like "exit to the right - Exit Kaufbeuren". Using process-exits this works perfectly. Would I use process-destination I would get "exit to the right towards B12 Verteilerring" or even "exit to the right towards Sudetenstraße" a really useless announcement as the sign on the trunk road reads "Kaufbeuren / Neugablonz / Mauerstetten". So this is why I would like to have an option that combines the functionality of process-exits and process-destination. Do you see any way to achieve this in one single style ? Ciao, Franco

7 6

address search and mixed index
by Gerd Petermann 04 Apr '15

04 Apr '15

Hi all, maybe you can help me with an open problem. I am not sure sure if this is a case of "garbage-in -> garbage-out" or not. I see a lot of houses with plausible tags addr:housenumber and addr:street which are close to a road that has no name or a different name. A typical example is a village like Stühren: http://www.openstreetmap.org/node/378300184#map=17/52.89235/8.71508 Almost all buildings are all tagged with addr:street="Stühren", but the main road through the village is the L340: http://www.openstreetmap.org/way/26701165 which has no name and many buildings are close to it. I think the postal address for these buildings is really something like "Stühren 28, 27211 Bassum,Germany" With trunk and r3477 in the housenumber2 branch I see rather bad results for this because the housenumbers are only added to those roads that have the name "Stühren". I wonder if the housenumber option should add the name "Stühren" to (a part of) L340 ? Or should we try to handle this with bounds containing villages and some style rules? Gerd

4 8

patch Interface Locatable and Kd-tree
by Gerd Petermann 02 Apr '15

02 Apr '15

Hi Steve, I plan to use a KD tree in the house number code. I noticed that the existing Kd-tree implementation in MapPointKdTtree is only usable with MapPoint instances, although it only uses the getLocation() method . I think this should be replaced using general interface Locatable() with method getLocation() and and general Kd-Tree implementaion for classes that implement the Locatable interface. The attached patch shows what I mean. What do you think about it? Do you see better names or packages for this? Gerd

3 5

FW: housenumbers2-r3502
by Gerd Petermann 26 Mar '15

26 Mar '15

From: gpetermann_muenchen(a)hotmail.com To: arndt(a)speichenkarte.de Subject: RE: [mkgmap-dev] housenumbers2-r3502 Date: Wed, 25 Mar 2015 23:44:40 +0100 Hi Arndt, thanks for reporting this. This messages with "distance to road too large" were caused by a special case for the group detection. Today I've committed r3505 to fix this problem as well. The address search in Godekinstraße http://www.openstreetmap.org/way/41808714#map=18/51.46352/7.49834&layers=N works now very well, only a few places are worse. (Not yet tested with many tiles, only with ~ 30 tiles) Gerd Date: Mon, 23 Mar 2015 17:49:09 +0100 From: arndt(a)speichenkarte.de To: mkgmap-dev(a)lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] housenumbers2-r3502 Hi, making maps from Nordrhein-Westfalen mkgmap shows this lines: SCHWERWIEGEND (ExtNumbers): C:\Kartenwerke\SpeicheLight\Splitter\80080016.osm.pb f: distance to road too large, road id=25526718, Godekinstra▀e house 38(12) http ://www.openstreetmap.org/way/59931228 SCHWERWIEGEND (ExtNumbers): C:\Kartenwerke\SpeicheLight\Splitter\80080016.osm.pb f: distance to road too large, road id=25526718, Godekinstra▀e house 40(12) http ://www.openstreetmap.org/way/59931126 SCHWERWIEGEND (ExtNumbers): C:\Kartenwerke\SpeicheLight\Splitter\80080016.osm.pb f: distance to road too large, road id=25526718, Godekinstra▀e house 42(12) http ://www.openstreetmap.org/way/59931160 SCHWERWIEGEND (ExtNumbers): C:\Kartenwerke\SpeicheLight\Splitter\80080016.osm.pb f: distance to road too large, road id=25526718, Godekinstra▀e house 44(12) http ://www.openstreetmap.org/way/59931224 SCHWERWIEGEND (ExtNumbers): C:\Kartenwerke\SpeicheLight\Splitter\80080016.osm.pb f: distance to road too large, road id=25526718, Godekinstra▀e house 46(12) http ://www.openstreetmap.org/way/54568353 now Germany is building, mkgmap show this: (The map ist now at work, it takes 2 hours...) Time started: Mon Mar 23 17:19:39 CET 2015 SCHWERWIEGEND (HousenumberIvl): C:\Kartenwerke\SpeicheDeutschland\Splitter\82280 009.osm.pbf: internal error: housenumber matches not properly set http://www.ope nstreetmap.org/way/32922367 6..8, step=2 SCHWERWIEGEND (HousenumberIvl): C:\Kartenwerke\SpeicheDeutschland\Splitter\82280 009.osm.pbf: internal error: housenumber matches not properly set http://www.ope nstreetmap.org/way/32922367 12..14, step=2 SCHWERWIEGEND (HousenumberIvl): C:\Kartenwerke\SpeicheDeutschland\Splitter\82280 009.osm.pbf: internal error: housenumber matches not properly set http://www.ope nstreetmap.org/way/32922367 16..18, step=2 Hope that helps? Greetings Arndt > GerdP <gpetermann_muenchen(a)hotmail.com> hat am 23. März 2015 um 16:25 geschrieben: > > > Hi all, > > I've committed r3502 now. > See > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3502 > and > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3499 > > If you have time, please try it and let me know any problems. > > Still open issues: > In mkgmap: > - implement support for addr:place > - maybe add name to unnamed service roads to improve address search > - improve the index creation and/or default style reg. names, highway > shields and refs. > - improve handling of numbers near tile boundaries > - clean up code > In splitter: > - use a small overlap (~150m) to make sure that house numbers near tile > boundaries > are complete > > ciao, > Gerd > > > > -- > View this message in context: http://gis.19327.n5.nabble.com/housenumbers2-r3502-tp5838259.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev(a)lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

4 4

routing problem: highways on different layers use the same node
by joern de 24 Mar '15

24 Mar '15

Sometimes one can find highways on different layers (e.g. one raod on and the other below a bridge) using the same node. Routing created with mkgmap seems not to care about the different layers of the highways and creates inappropriate turning instructions from the upper road directly to the lower. Is someone out there who can confirm that, is there someone to fix that? (Don't ask me for examples, I already seperated those discovered highway nodes in OSM).

2 1

housenumbers2-r3502
by GerdP 24 Mar '15

24 Mar '15

Hi all, I've committed r3502 now. See http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3502 and http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3499 If you have time, please try it and let me know any problems. Still open issues: In mkgmap: - implement support for addr:place - maybe add name to unnamed service roads to improve address search - improve the index creation and/or default style reg. names, highway shields and refs. - improve handling of numbers near tile boundaries - clean up code In splitter: - use a small overlap (~150m) to make sure that house numbers near tile boundaries are complete ciao, Gerd -- View this message in context: http://gis.19327.n5.nabble.com/housenumbers2-r3502-tp5838259.html Sent from the Mkgmap Development mailing list archive at Nabble.com.

4 6

addr:interpolation ways not along road
by GerdP 24 Mar '15

24 Mar '15

Hi all, I wonder if mkgmap should treat this a valid addr:interpolation way: http://www.openstreetmap.org/way/32922365 The wiki says: "How to interpolate the house numbers belonging to the way along the respective street." but this way connects house numbers which are up to 170 m away from the road named Bergweg, so I think it is not "along" the respective street. With r3502 I've added checks to ignore numbers which belong to invalid addr:interpolation ways, and this detection says it is invalid. I've kept this with r3503. This also happens for some other addr:interpolation ways for the way 25748155. Please let me know when you think that this is too aggressive. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/addr-interpolation-ways-not-along-road-tp583… Sent from the Mkgmap Development mailing list archive at Nabble.com.

3 4

weired housenumbers in Canada
by Gerd Petermann 23 Mar '15

23 Mar '15

Hi all, in Canada, a lot of OSM data comes from imports, e.g. source=NRCan-CanVec-8.0 or NRCan-CanVec-10.0 I think the house number data provided by these imports is more or less garbage. I see many ways like this: http://www.openstreetmap.org/way/133338396 It is an addr:interpolation way connecting two different points which both have addr:housenumber=5 addr:street=20th Sideroad In many cases I see two of these meaningless objects, one with source=NRCan-CanVec-8.0, one with source=NRCan-CanVec-10.0. I think the only way to handle this data is to ignore it, if mkgmap finds an addr:interpolation way connecting two equal numbers, we should ignore the numbers. Right? Gerd

3 2

Feedback to housenumbers2-r3500
by Bernd Weigelt 22 Mar '15

22 Mar '15

Hi with housenumbers2-r3500, i got some error messages, didn't happen with trunk- r3498 Bernd java.lang.IndexOutOfBoundsException: Index: 0, Size: 0 at java.util.ArrayList.rangeCheck(ArrayList.java:635) at java.util.ArrayList.get(ArrayList.java:411) at uk.me.parabola.mkgmap.osmstyle.housenumber.ExtNumbers.splitInterval(ExtNumbers.java:511) at uk.me.parabola.mkgmap.osmstyle.housenumber.ExtNumbers.tryChange(ExtNumbers.java:430) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberRoad.checkWrongRoadAssignmments(HousenumberRoad.java:473) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.checkWrongRoadAssignmments(HousenumberGenerator.java:950) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.buildNumberIntervals(HousenumberGenerator.java:909) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.assignHouseNumbersToRoads(HousenumberGenerator.java:660) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.matchCluster(HousenumberGenerator.java:555) at uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:501) at uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:599) at uk.me.parabola.mkgmap.reader.osm.ElementSaver.convert(ElementSaver.java:250) at uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinMapDataSource.load(O5mBinMapDataSource.java:53) 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:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:745) -- amarok2 now playing:

3 6