mkgmap-dev

mkgmap-dev@lists.mkgmap.org.uk

March 2017

26 participants
62 discussions

Commit r3831: Correct Tags iterators
by svn commit 03 Mar '17

03 Mar '17

Version mkgmap-r3831 was committed by gerd on Fri, 03 Mar 2017 Correct Tags iterators The next() method did not return the correct value if not preceeded by a hasNext() call. This caused no problems in existing code. http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3831

1 0

Buildings in residential areas (is_in_filter)
by Gerd Petermann 02 Mar '17

02 Mar '17

Hi all, picking up this thread: http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2017q1/026079.html I've now done some experiments with this approach: - Collect all shapes after style processing - Collect those shapes added to the map with tag landuse=residential and build a fake BoundaryQuadTree by adding those ways as admin_level=10 boundary. - For each shape (or each with type 0x13) check if the BoundaryQuadTree returns a "location" with admin_level=10. If so, the shape is considered to lie inside a residential area and may be removed. The performance is no problem, these computations are performed in < 1s and the removal safes time later. I've tried with the default style with a map for Niedersachsen and got a size reduction of 154MB -> 133MB (I guess we have add some more MB when we draw the residential areas at res 24 instead). So, what we need now is a useful user interface for this function. Possible: - a new special tag mkgmap:remove-if-in-residential=true which tells mkgmap the objects to remove (do we need that for POI or lines as well? ) - a new special tag mkgmap:treat-as-residential=true for to tell mkgmap that a shape with that tag should be considered as a residential area , maybe not needed since you might add landuse=residential as well. I don't think that this simple function can be used to solve the routing problems, this would require a lot more logic. What do you think? Gerd

2 2