January 2020 - mkgmap-dev - The mkgmap lists

Re: [mkgmap-dev] MKGMAP lost precision.
by Gerd Petermann 09 Jan '20

09 Jan '20

Hi John, please use r4406 or later, see also http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4405 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4406 Should have seen this problem before, seems I looked only at routing / search issues before committing r4360 :( Gerd ________________________________________ Von: Gerd Petermann <gpetermann_muenchen(a)hotmail.com> Gesendet: Mittwoch, 8. Januar 2020 18:56 An: john(a)the-thorns.org.uk Betreff: AW: MKGMAP lost precision. Hi John, thanks for reporting. I can reproduce the error but I do not yet see where it is. Looks like mkgmap is dropping on point in each shape. Will have a closer look tomorrow. Gerd ________________________________________ Von: John Thorn <johnrthorn(a)gmail.com> Gesendet: Mittwoch, 8. Januar 2020 18:04 An: Gerd Petermann Betreff: MKGMAP lost precision. Hi Gerd, I decided it was time to install a more recent version of MKGMAP. I have been running 4286 but downloaded 4398. My maps contain the Microsoft/Bing building outlines for the US so I am using Level0=24. With 4286 the result is good (screenshot 704) with 4398 the rectangles have become triangles as if precision is being lost (705). I am compiling from .MP files and a typical building is : [POLYGON] ; RhodeIsland.geojson 161666 EndLevel=3 Type=0x13 Data0=(41.682688,-71.277508),(41.682688,-71.277476),(41.682596,-71.277476),(41.682596,-71.277366),(41.682748,-71.277366),(41.682748,-71.277508),(41.682688,-71.277508) [END] Regards, John

1 0

Commit r4406: See log message for r4405. I wondered why none of the unit tests failed. Seems the tolerance for small changes is too high, so this adapts size values in function tests and lowers the range for RGN size with polish input to 3.
by svn commit 09 Jan '20

09 Jan '20

Version mkgmap-r4406 was committed by gerd on Thu, 09 Jan 2020 See log message for r4405. I wondered why none of the unit tests failed. Seems the tolerance for small changes is too high, so this adapts size values in function tests and lowers the range for RGN size with polish input to 3. Let's see if this causes too many failing tests in the future. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4406

1 0

Commit r4405: Fix error: Shapes are distorted when 2nd last and last point are at same position or when 1st and 2nd point are at same position (1st and last point are identical)
by svn commit 09 Jan '20

09 Jan '20

Version mkgmap-r4405 was committed by gerd on Thu, 09 Jan 2020 Fix error: Shapes are distorted when 2nd last and last point are at same position or when 1st and 2nd point are at same position (1st and last point are identical) This is rather unlikely with OSM data but (since r4360) it happened always with polish input as it removed code which caused coords at the same place to be the same object. I removed that in r4360 because I think it can cause problems with housenumber nodes or routing nodes. So, we have an old error which didn't show up until the change in r4360. This change fixes the old error and changes the code in the polish reader so that it doesn't produce this special case. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4405

1 0

Allow blanks in function parameters
by Gerd Petermann 08 Jan '20

08 Jan '20

Hi Ticker, I am still struggling with the insideness tests. I noticed that the scanner doesn't accept a blank in the functions parameters, e.g. these two rules are not accepted: building=* & building!=no & is_in(landuse,residential, any)=false [0x13 resolution 24] building=* & building!=no & is_in(landuse, residential,any)=false [0x13 resolution 24] I'd prefer to allow this as well. Maybe you can have a look at this? Gerd

3 6

Test cases for possible is-in-hook
by Gerd Petermann 06 Jan '20

06 Jan '20

Hi all, this is a follow up of http://gis.19327.n8.nabble.com/Commit-r4398-revert-changes-from-r4397-is-in… Attached is a new file which contains additional ways w28 .. w30 and w26 was changed from expected="?" to "in". The new ways are all very close to the residential polygon(s), but completely outside. I think w26 and w30 show very common cases in OSM. Some mappers prefer to "glue" landuse polygons to highways, others don't. There are probably good reasons for both methods. Because of the poor precision the current code in mkgmap adds mkgmap:residential to both of them. See http://gis.19327.n8.nabble.com/is-in-filter-tp5890564p5890566.html where Carlos stated that this would be welcomed (at least if the ways were e.g. highway=secondary instead of footway). If I change the code to be a lot more precise w30 would not be tagged. On the other hand, if you ask for landuse=cemetery you probably don't want to change a cycleway next to it. Any ideas how to handle this dilemma? Gerd P.S. In my hometown the cemetery expanded during the years and it now stretches across a residential road "Lehmkuhlenweg". See https://www.openstreetmap.org/way/11760536 I think in reality the cemetery is split into two parts, there are gates on the footways and barrier=fence or barrier=hedges along the road, but nobody mapped them until now.

4 6

New branch is-in for experiments on style function is_in
by Gerd Petermann 02 Jan '20

02 Jan '20

Hi all, with the help of Ticker I see a way to implement an is_in style function I've created branch is-in to experiment with this. Sorry for the different spelling is-in in the branch name! Unfortunately I got no response regarding the contents of the file is-in-hook-samples-v2.osm posted here: http://gis.19327.n8.nabble.com/Test-cases-for-possible-is-in-hook-tp5954103… So, Ticker and I have to guess what the function should do when a way or polygon crosses or touches the boundary of a polygon with the given attribute. The code in r4400 implements a function is_in with three parameters which returns either true or false. It allows a rule like this in the lines file: highway=* & bicycle!=* & (is_in(landuse,cemetery,all) = true | is_in(amenity,grave_yard,all) = true) {add bicycle=dismount} or this one in the polygons file: # render building only when completely outside of a residential area building=* & building!=no & is_in(landuse,residential,any)=false [0x13 resolution 24] A BIG question mark is the handling of rules which change the tags of polygons. Assume you have a rule like this in polygons: landuse=residential | landuse=commercial {set mylanduse=xyz} and somewhere else building=* & building!=no & is_in(mylanduse,xyz,any)=false [0x13 resolution 24] It might not be obvious but this could produce more or less unpredictable results as it depends on the order in which elements are processed. So, Ticker suggested to say "results of the is_in function are undefined when tags of polygons are changed". I hope we can change this to something like "changing tags of polygons in the style rules has no effect on the results of the is_in function" by creating copies of elements before the style rules are applied. Gerd

3 2