- mkgmap-dev - The mkgmap lists

Commit r4308: Let option --housenumbers imply option --net
by svn commit 21 Oct '19

21 Oct '19

Version mkgmap-r4308 was committed by gerd on Mon, 21 Oct 2019 Let option --housenumbers imply option --net http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4308

1 0

Option --housenumbers should imply --net
by Gerd Petermann 20 Oct '19

20 Oct '19

Hi all, the current code implies --net if option --route is given. It also ignores --no-net if --route is given. I think that option --housenumbers should work exactly like that, as both options don't make sense without a NET file. With the current code, if you specify --housenumbers without --net or --route, mkgmap processes the numbers and may adds number nodes, but since no NET file is written the result is just an increased RGN file size. The attached patch changes the code and the documentation for the options. Please suggest improvements, I want to commit this patch to trunk tomorrow. Gerd

3 3

Re: [mkgmap-dev] [mkgmap-svn] Commit r4300: experimental code to reduce NOD size (option --routable)
by Ticker Berkin 12 Oct '19

12 Oct '19

Hi Gerd (I started writing this before your next post arrived) Assuming I understand the resultant behaviour correctly concerning the 2nd change: I'm against the idea not having NODs for terminal roads becoming the default. It may not have obvious effects in heavily built up areas, but elsewhere, a reasonably proportion of places that someone might wish to navigate to are reached by a single track/driveway. The entrance to this access road will rarely be the closest point a road. Sometimes it is even a different road! Ticker On Sat, 2019-10-12 at 10:28 +0100, svn commit wrote: > Version mkgmap-r4300 was committed by gerd on Sat, 12 Oct 2019 > BRANCH: NET-no-NOD > experimental code to reduce NOD size (option --routable) > - don't add a route node for the ends of roads when they are not > connected to other roads > -don't write NOD info for roads which are not connected to other > roads and which do not have boundary nodes > Wanted effect: smaller NOD size > Problem of 2nd change: Routing at those roads behaves different, > large detours may be calculated instead of a straight line which > clearly says: routing problem > new option --x-all-roads-to-nod can be used to get the old behaviour > (with a larger NOD) > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4300 > _______________________________________________ > mkgmap-svn mailing list > To unsubscribe send an mail to mkgmap-svn-leave(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-svn

2 1

Commit r4299: Correction: avoid to split 'via' ways of turn restrictions when processing CoordPoi which set mkgmap:road-class or mkgmap:road-speed
by svn commit 11 Oct '19

11 Oct '19

Version mkgmap-r4299 was committed by gerd on Fri, 11 Oct 2019 Correction: avoid to split 'via' ways of turn restrictions when processing CoordPoi which set mkgmap:road-class or mkgmap:road-speed (avoid-to-split-via-ways.patch) http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4299

1 0

[Patch] improve handling of only-restrictions with via ways
by Gerd Petermann 11 Oct '19

11 Oct '19

Hi all, in http://gis.19327.n8.nabble.com/Turn-Restrictions-using-three-ways-design-gu… Thanks to blc I've learned that only_* restrictions with via ways should be interpreted a bit different. As you might know the Garmin IMG format only has restrictions of type "no", so mkgmap has to translate "only" restrictions to a list of "no" restrictions. For those "only" restrictions the current code in version r4295 checks the roads connected to (the last) "via"-node and adds a "no" restriction for all ways except the "to"-way. The meaning of an "only" restriction with "via"-way(s) is a bit different . I means something like "once you have reached the node that connects the "from"-way with the (first) "via"-way travelling on the "from" way you MUST use the route described in the restriction relation unless you have reached the "to" way. So, mkgmap must add restrictions for each route node on the "via"-way(s), not only the last. The patch implements this and no longer prints a warning for "only"-restrictions with "via" ways (severity was changed from warning to information). I've uploaded a binary here: http://files.mkgmap.org.uk/download/452/mkgmap.jar If I hear no complains I'll commit this patch next Monday. Gerd

3 10

Turn Restrictions using three ways - design guide for OSM mappers?
by blc 11 Oct '19

11 Oct '19

Hello, I thank all who have been working on this neat program to allow our otherwise old Garmins sit in the dust heap when we can't afford to subscribe to new maps. I've been trying to improve the quality of OSM by fixing the errors that mkgmap emits, which a lot of times mirrors what's seen in KeepRight. However there's one variant of turn restriction I've noticed that warns in mkgmap but do not show up in KeepRight (and iD seems to understand this type of turn restriction) - the way-way-way type restriction where three connected ways are in series for non no-u-turn restrictions. example: Turn restriction (only_left_turn) 2256354 (at https://www.openstreetmap.org/?mlat=47.777585&mlon=-122.319488&zoom=17) check: 'via' way(s) are used in only_left_turn restriction The way-way-way type is the proper method for restricting u-turns on dual carriageway roads which is understood by mkgmap. On the other hand, iD and KeepRight it seems to be valid to do way-way-way instead of way-POINT-way for no/only left/right turn restrictions, no/only straight on restrictions, etc. I've seen a lot of the non no-u-turn way-way-way restrictions in the USA. These type of non no-u-turn restrictions seems to cause a warning in mkgmap and probably not translating them. My question is that should these be supported in mkgmap, or should these be fixed in OSM so that they are simple way-via-way despite iD and KeepRight seem to claim them valid? Or perhaps way-way-way is deprecated but still supported by OSM but should be changed to way-point-way? way-point-way = relation from: some-street-way via: some-intersection-point to: some-street-way (this is the most common type of turn restriction) way-way-way = relation from: some-street-way via: some-street-way to: some-street-way (this is necessary specifically for dual carriageway u-turn restriction, but it's used for other types as well which mkgmap complains about.) Thanks for shedding some light on the discrepancy here! Note: I'm currently depending on OpenMapChest data for mkgmap runs as my computer and internet connection are not large or fast enough for the quantity of data I'd like to work with.

3 11

'loose' gates
by nwillink 03 Oct '19

03 Oct '19

Hi All Does anyone know a way of detecting gates and for that matter any barrier not linked to a highway? My area is strewn with farm gates which are not joined to any highway ; from the a routing point of view they are totally are irrelevant and purely aesthetic. Also, there might be barriers which look connected to a highway but are not and so have slipped through the net. As points are parsed before lines I suppose there is no way of doing this, and yet when parsing a highway, mkgmap must know if a line contains a barrier. Thanks Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

2 1

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 135, Issue 1
by John Thorn 02 Oct '19

02 Oct '19

The empty POIs are a mistake. Don’t do anything special as I will remove them. John Thorn On Wed, 2 Oct 2019 at 12:00, <mkgmap-dev-request(a)lists.mkgmap.org.uk> wrote: > Send mkgmap-dev mailing list submissions to > mkgmap-dev(a)lists.mkgmap.org.uk > > To subscribe or unsubscribe via the World Wide Web, visit > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > or, via email, send a message with subject or body 'help' to > mkgmap-dev-request(a)lists.mkgmap.org.uk > > You can reach the person managing the list at > mkgmap-dev-owner(a)lists.mkgmap.org.uk > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of mkgmap-dev digest..." > Today's Topics: > > 1. Commit r4295: avoid conversion to Integer, no funtional > change (svn commit) > 2. Re: Commit r4292: Fix problem with long roads producing the > error message "internal error? The nodeCount doesn't match value > calculated by RoadNetWork" (Gerd Petermann) > > > > ---------- Forwarded message ---------- > From: svn commit <svn(a)mkgmap.org.uk> > To: mkgmap-svn(a)lists.mkgmap.org.uk, mkgmap-dev(a)lists.mkgmap.org.uk > Cc: > Bcc: > Date: Wed, 2 Oct 2019 07:25:05 +0100 (BST) > Subject: [mkgmap-dev] Commit r4295: avoid conversion to Integer, no > funtional change > Version mkgmap-r4295 was committed by gerd on Wed, 02 Oct 2019 > > avoid conversion to Integer, no funtional change > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4295 > > > ---------- Forwarded message ---------- > From: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> > To: Development list for mkgmap <mkgmap-dev(a)lists.mkgmap.org.uk> > Cc: > Bcc: > Date: Wed, 2 Oct 2019 09:18:59 +0000 > Subject: Re: [mkgmap-dev] Commit r4292: Fix problem with long roads > producing the error message "internal error? The nodeCount doesn't match > value calculated by RoadNetWork" > Hi IMG experts, > > the message is produced because we have to different ways to calculate a > counter which is written to NET. It is not obvious which one is correct and > therefore we > have a check that compares the counters. Some special cases only occur > with polish (*.mp) input, others only with osm data. > > I've now started a new branch called "NET-no-NOD" to improve the code so > that it > - supports writing NET without NOD data from polish input > - doesn't write redundant data into RGN when neither housenumbers nor NOD > data is present for a road > - ignores empty POI instead of crashing (special case for John Thorne) > > This is complex because in OSM data each point (Node) has a unique ID > while in *.mp this is not the case. > On the other hand with *.mp input the user can produce roads which have > only one routable node in the middle (+-shaped crossing). > > I think the branch already works better than trunk but testing is > complicated. I test these fixed options --index --preserve-element-order > --bounds=f:\osm\bounds.zip > in combination with > 1) --net > 2) --route > 3) --net --housenumbers > 4) --route --housenumbers > both with various *.osm and *.mp data. > Whereever I find differences in the IMG output I try to find out if the > new result is an improvement or not. I use Mapsource to test effects on > routing and the display tool to analyse the differences in the RGN, NET and > NOD files... > > Gerd > > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von > Gerd Petermann <gpetermann_muenchen(a)hotmail.com> > Gesendet: Samstag, 28. September 2019 08:33 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Commit r4292: Fix problem with long roads > producing the error message "internal error? The nodeCount doesn't match > value calculated by RoadNetWork" > > Hi Ticker, > > thanks for the details, I've reverted the problemtatic patch for now, so > r4294 should work fine for most users (except John Thorne) > > Gerd > > ________________________________________ > Von: mkgmap-dev <mkgmap-dev-bounces(a)lists.mkgmap.org.uk> im Auftrag von > Ticker Berkin <rwb-mkgmap(a)jagit.co.uk> > Gesendet: Samstag, 28. September 2019 08:22 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Commit r4292: Fix problem with long roads > producing the error message "internal error? The nodeCount doesn't match > value calculated by RoadNetWork" > > Hi > > I've minimised the options and still get the problem. > > Downloading this morning from: > http://download.geofabrik.de/europe/great-britain/wales.html > > java -Xmx1540M -ea -jar splitter-r592/splitter.jar --mapid=74320089 - > -split-file=tstSep19.list wales-latest.osm.pbf >splitter.log 2>&1 > > where tstSep19.list contains: > > 4320089: 2398208,-194560 to 2437120,-155648 > # : 51.459961,-4.174805 to 52.294922,-3.339844 > > Then, with latest bounds downloaded from the link on mkgmap.org.uk > > java -jar mkgmap-r4293/mkgmap.jar --route --bounds=bounds.zip --input > -file=74320089.osm.pbf > > I get: > > Time started: Sat Sep 28 07:03:00 BST 2019 > SEVERE (RoadDef): 74320089.osm.pbf: internal error? The nodeCount > doesn't match value calculated by RoadNetWork: ( > http://www.openstreetmap.org/browse/way/26552046) > SEVERE (RoadDef): 74320089.osm.pbf: internal error? The nodeCount > doesn't match value calculated by RoadNetWork: ( > http://www.openstreetmap.org/browse/way/124109672) > SEVERE (RoadDef): 74320089.osm.pbf: internal error? The nodeCount > doesn't match value calculated by RoadNetWork: ( > http://www.openstreetmap.org/browse/way/139314867) > SEVERE (RoadDef): 74320089.osm.pbf: internal error? The nodeCount > doesn't match value calculated by RoadNetWork: ( > http://www.openstreetmap.org/browse/way/24556428) > Number of MapFailedExceptions: 0 > Number of ExitExceptions: 0 > Time finished: Sat Sep 28 07:03:44 BST 2019 > Total time taken: 44 seconds > > Ticker > > > On Fri, 2019-09-27 at 13:48 +0100, Ticker Berkin wrote: > > Hi Gerd > > > > I've just updated my build from 4288 to 4293 and I'm now getting > > quite > > a few of these errors > > > > SEVERE (RoadDef): 74220089.osm.pbf: internal error? The nodeCount > > doesn't match value calculated by RoadNetWork: ( > > http://www.openstreetmap.org/browse/way/26552046) > > SEVERE (RoadDef): 74220089.osm.pbf: internal error? The nodeCount > > doesn't match value calculated by RoadNetWork: ( > > http://www.openstreetmap.org/browse/way/40038526) > > > > My options include: > > --no-housenumbers > > --link-pois-to-ways > > --add-boundary-nodes-at-admin-boundaries=0 > > --style-file=../styles/mystyle > > and many others > > > > I'll try to reproduce with simpler options and the default style > > > > Regards > > Ticker > > > > > > On Wed, 2019-09-25 at 08:10 +0100, svn commit wrote: > > > Version mkgmap-r4292 was committed by gerd on Wed, 25 Sep 2019 > > > > > > Fix problem with long roads producing the error message "internal > > > error? The nodeCount doesn't match value calculated by RoadNetWork" > > > Problem was introduced with r4291 > > > > > > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=429 > > > 2 > > > _______________________________________________ > > > 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 > _______________________________________________ > 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 > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev(a)lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

2 1

Commit r4292: Fix problem with long roads producing the error message "internal error? The nodeCount doesn't match value calculated by RoadNetWork"
by svn commit 02 Oct '19

02 Oct '19

Version mkgmap-r4292 was committed by gerd on Wed, 25 Sep 2019 Fix problem with long roads producing the error message "internal error? The nodeCount doesn't match value calculated by RoadNetWork" Problem was introduced with r4291 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4292

3 4

Commit r4295: avoid conversion to Integer, no funtional change
by svn commit 02 Oct '19

02 Oct '19

Version mkgmap-r4295 was committed by gerd on Wed, 02 Oct 2019 avoid conversion to Integer, no funtional change http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4295

1 0