October 2019 - mkgmap-dev - The mkgmap lists

Commit r4311: Ignore turn restrictions in ElementSaver when map is not routable to supress warning "ignoring unspecified/unsupported restriction" for type=restriction relations.
by svn commit 21 Oct '19

21 Oct '19

Version mkgmap-r4311 was committed by gerd on Mon, 21 Oct 2019 Ignore turn restrictions in ElementSaver when map is not routable to supress warning "ignoring unspecified/unsupported restriction" for type=restriction relations. If map is not routable the tag type=restriction might not be used anywhere in the code as the RoutingHook is not enabled and the style probably doesn't use it. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4311

1 0

Commit r4310: Code cleanup, no change in output expected
by svn commit 21 Oct '19

21 Oct '19

Version mkgmap-r4310 was committed by gerd on Mon, 21 Oct 2019 Code cleanup, no change in output expected - use MultiHashMap for field deferredRelationMap in ElementSaver - use of HashMap.computeIfAbsent() in MultiHashMap might give small performance improvement http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4310

1 0

Commit r4309: Improve code readability for KdTree, no functional change
by svn commit 21 Oct '19

21 Oct '19

Version mkgmap-r4309 was committed by gerd on Mon, 21 Oct 2019 Improve code readability for KdTree, no functional change I thought I should replace the recursive calls but that turned out to be quite complex and some investigation showed that the tree is typically well balanced when used in mkgmap so that the depth is well below 100 and threrefore not a problem with the java stack. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4309

1 0

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