April 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

RFC: naming unnamed roads
by Gerd Petermann 06 May '15

06 May '15

Hi all, I see some cases where the automatic naming of "service roads" causes problems. Maybe you can help me to find better heuristics. The target is to produce data that enables Garmin software to find an address / a house when OSM data shows an address. Now, often houses have a tag addr:street=xyz, but the closest road(s) don't have the name xyz. This happens when 1) an unnamed service road or footway is connecting the house with a road named xyz 2) unnamed cylceways / footways are between the house and the named road 3) typos in the addr:street tag or the mkgmap:street tag prevent a clear match, e.g. the road is named "Alte Chausseestraße" and the houses have (probably wrong) "Alte Chaussestraße" (single e), or the addr:street tag is completely wrong, means, no street with a name like that is close. 4) a named road is close to one side of the house but an unnamed track/footway is closer on an other side. I think 1) is clear, we want that Garmin address search points us to a point on the service road. In case 2) I would prefer to find the named road, but it seems to cause no problems when mkgmap uses the closer way and gives it the name of the named road, at least as long as both roads are more or less parallel lines. Case 3) is a bit funny. The unnamed road will be used and address search will find the address as long as you type the (probably) wrong name. In trunk, these houses are ignored, which is sometimes better, sometimes not. Case 4) is causing real trouble. We don't want to be routed to the these roads, but up to now I found no rule(s) to distinguish them from 1) or 2) besides the tag mkgmap:numbers=false . Any ideas ? Gerd

4 8

Commit: r3552: improve address search in Ottawa and Toronto
by svn commit 29 Apr '15

29 Apr '15

Version mkgmap-r3552 was committed by gerd on Wed, 29 Apr 2015 improve address search in Ottawa and Toronto - Ben Konrath

1 0

mkgmap:city empty in large cities
by Gerd Petermann 28 Apr '15

28 Apr '15

Hi all, I noticed that our rules in inc/address do not set mkgmap:city in Ottawa/Ontario. Adding an additional line like the 2nd below solves the problem: # Canada mkgmap:country=CAN & mkgmap:region!=* & mkgmap:admin_level4=* { set mkgmap:region='${mkgmap:admin_level4}' } mkgmap:country=CAN & mkgmap:city!=* & mkgmap:admin_level6=Ottawa { set mkgmap:city='${mkgmap:admin_level6}' } mkgmap:country=CAN & mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8|subst:City of }' } or should we add a one to this block: mkgmap:city!=* & mkgmap:admin_level8=* { set mkgmap:city='${mkgmap:admin_level8}' } mkgmap:city!=* & mkgmap:admin_level7=* { set mkgmap:city='${mkgmap:admin_level7}' } mkgmap:city!=* & mkgmap:admin_level9=* { set mkgmap:city='${mkgmap:admin_level9}' } mkgmap:city!=* & mkgmap:admin_level10=* { set mkgmap:city='${mkgmap:admin_level10}' } e.g. a further line with mkgmap:city!=* & mkgmap:admin_level6=* { set mkgmap:city='${mkgmap:admin_level6}' } I assume that there are more large cities with this problem. Does anybody know how to find them without mkgmap ? Gerd

2 5

Re: [mkgmap-dev] error message in Cologne
by Bernd Weigelt 28 Apr '15

28 Apr '15

Hi Gerd Can't test the new functions until monday next week, i'm out for a motorcycle tour :-) Bernd Hier sollte eigentlich eine Signatur stehen. -----Original Message----- From: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> To: "mkgmap-dev(a)lists.mkgmap.org.uk" <mkgmap-dev(a)lists.mkgmap.org.uk> Sent: Di., 28 Apr. 2015 8:44 Subject: Re: [mkgmap-dev] error message in Cologne Hi Bernd, the problem was fixed with r3549. With r3550 I've implemented the new special tag mkgmap:numbers, see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3550 for details. Gerd > Date: Mon, 27 Apr 2015 12:59:30 -0700 > From: gpetermann_muenchen(a)hotmail.com > To: mkgmap-dev(a)lists.mkgmap.org.uk > Subject: Re: [mkgmap-dev] error message in Cologne > > Hi Bernd, > > forget it, I was able to reproduce the error message with a download of this > area: > http://www.openstreetmap.org/query?lat=50.06119&lon=14.40275 > > Gerd > > > GerdP wrote > > Hi Bernd, > > > > please post a link to the file 65030278.o5m > > > > Gerd > > Bernd Weigelt wrote > >> Hi Gerd > >> > >> There was only one message for my dach extract, all other extract are > >> build > >> without any noise. > >> > >> SCHWERWIEGEND (ExtNumbers): /home/bernd/map_build/tiles/65030278.o5m: > >> internal > >> error, worst house not found id=4672706, Na Neklance[731(10), 727(10), > >> 805/8(10)][] 2031/1(0) > >> > >> The option --x-name-service-roads=n seems to be no really problem, while > >> enabled, but i'll remove it from my options for the next build, too. > >> ;-) > >> > >> Bernd > >> > >> Am Montag, 27. April 2015, 20:07:54 schrieb Gerd Petermann: > >>> Hi Bernd, > >>> > >>> pleasse note one important change: > >>> I've removed the option --x-name-service-roads=n, > >>> it is no longer optional, mkgmap tries to find a name > >>> for roads with house numbers. This leads to > >>> some special effects, e.g. when a small unnamed footway > >>> is closer to the house than the named service road. > >>> I think about a new tag like mkgmap:number=false > >>> that tells mkgmap that a road should not be used for > >>> address search, e.g. cycleways or motorways. > >>> This would also speed up the search for the closest roads. > >>> > >>> Gerd > >>> > >>> > From: > > >> weigelt.bernd@ > > >>> > To: > > >> mkgmap-dev@.org > > >>> > Date: Mon, 27 Apr 2015 17:58:45 +0200 > >>> > Subject: Re: [mkgmap-dev] error message in Cologne > >>> > > >>> > Hi Gerd > >>> > i'll give it a try asap > >>> > > >>> > thx > >>> > Bernd > >>> > > >>> > Am Sonntag, 26. April 2015, 16:37:35 schrieb Gerd Petermann: > >>> > > please try r3546, I think it is stable again. > >>> > > I had to change the program logic to make sure that > >>> > > special cases with interpolation ways do not > >>> > > causes assertions. > >>> > > > >>> > > I have still some known problems, esp. > >>> > > the program logic for housenumbers assumes now that > >>> > > city/ zip code info attached to the housenumbers is written to the > >>> img > >>> > > file, but that doesn't happen yet (and is quite complicated as it > >>> seems > >>> > > to require big changes in the existing program logic) > >>> > > so address search for roads at city boundaries might still > >>> > > not work. > >> > >> -- > >> amarok2 now playing: > >> > >> > >> > >> > >> _______________________________________________ > >> mkgmap-dev mailing list > > >> mkgmap-dev@.org > > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > -- > View this message in context: http://gis.19327.n5.nabble.com/error-message-in-Cologne-tp5841730p5842108.h… > 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

2 1

Options
by Anna Leuchter 28 Apr '15

28 Apr '15

Hello Gerd, sorry for the delay. "better than nothing" simply means that this is actually the only possibility, to create Points along a way to mark a hiking trail based on relations. In fact this is not really satiesfying but it is actually the only way. That's the reason why i said "better than nothing". OSMCOMPOSER-Software which is a type of frontend to mkgamp has a builtin preprocessor, which is able to create points along way relation. Here you have the possibilty to configure which relations you wanna use e.g hiking|cycling|MTB and the minimum lenght, of way beeing part or a relation to get a poi. If there are multiple routes, the pois will be distributed, to fit in a way that they are all visible. Ok, it's clear, depending on length and amount of pois, they will overlap. regards Gert >>From Gerd Petermann gpetermann_muenchen at hotmail.com on Fri Apr 24 06:35:07 BST 2015 >>Hi Gert, >> yes, I think it must be useful, I also see it in Minkos styles at >> http://www.openfietsmap.nl/ >> I don't fully understand the "better than nothing" part . >> The current code adds a POI to each point, so each point has >> a mkgmap:line2poitype=* tag with values start,end,mid, or inner >> for the rest. >> The option should be handled with great care, it is likely to >> produce a large number of POI for highly detailed ways >> created by some imports. >> I already thought about an addtional parameter for the option, >> something like --add-pois-to-lines=n where n gives a value in meter >> for the minimum distance between two generated POI when the way >> has more than 3 points. >> Gerd

1 0

Re: [mkgmap-dev] error message in Cologne
by Bernd Weigelt 28 Apr '15

28 Apr '15

I have read the comment on r3541, but housenumbers2 was on a really good way, so i want to give it a chance. I can build my maps with trunk in the next days Hier sollte eigentlich eine Signatur stehen. -----Original Message----- From: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> To: "mkgmap-dev(a)lists.mkgmap.org.uk" <mkgmap-dev(a)lists.mkgmap.org.uk> Sent: Sa., 25 Apr. 2015 12:28 Subject: Re: [mkgmap-dev] error message in Cologne Hi Bernd, thanks for reporting. Please note that the branch is very experimental since r3541. I'll try to fix the problems that you have reported, but you should not expect good results until I post that I think a test should be done. Gerd > From: weigelt.bernd(a)web.de > To: mkgmap-dev(a)lists.mkgmap.org.uk > Date: Sat, 25 Apr 2015 12:04:36 +0200 > Subject: Re: [mkgmap-dev] error message in Cologne > > Am Samstag, 25. April 2015, 11:54:33 schrieb Bernd Weigelt: > > get lots of other problems with ... > > there is a second error > http://files.mkgmap.org.uk/download/263/65010116.o5m > > java.lang.ArrayIndexOutOfBoundsException: -2 > at > uk.me.parabola.mkgmap.osmstyle.housenumber.ExtNumbers.splitLargeGaps(ExtNumbers.java:1600) > at > uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberRoad.improveSearchResults(HousenumberRoad.java:602) > at > uk.me.parabola.mkgmap.osmstyle.housenumber.HousenumberGenerator.generate(HousenumberGenerator.java:682) > at > uk.me.parabola.mkgmap.osmstyle.StyledConverter.end(StyledConverter.java:607) > 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: > > > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

3 8

Options
by Anna Leuchter 27 Apr '15

27 Apr '15

3 8

Commit: r3548: correct typo add-poi-to-something -> add-pois-to-something
by svn commit 27 Apr '15

27 Apr '15

Version mkgmap-r3548 was committed by gerd on Mon, 27 Apr 2015 correct typo add-poi-to-something -> add-pois-to-something

1 0