[mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 raster problems

Fri Apr 30 15:42:28 BST 2021

Are you sure it would be needing that much more memory? If there is a big
penalty this simplification could only be done for lower resolutions, which
contain much less data. Even if its only 13-20 that would be a huge
improvement. 21 could need some love too but not as important, while 22 is
usually still quite performant on GPS devices. 13-16 or 17 is
usually basemap only anyhow. Maybe we could create static basemaps in the
same way that we have the sea and boundary files? Yes if a new highway is
built at some point it should show up in the overview map - but as this one
is really only for orientation, I really feel it's okay to be updated
only twice per year or so.

Garmins maps in this aspect are clearly superior.

On Fri, 30 Apr 2021 at 21:50, Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> Hi all,
>
> attached is my proposed change based on the simplify3.patch by Andrzej and
> the idea to use that only for contour lines.
>
> I see no simple way to implement major improvements for the rendering of
> lower resolutions. Basically we need the WrongAngleFixer to work with a
> given resolution.
> So, something like a loop over each level  (starting with the highest)
> +  collect the elements that should be rendered at this level
> + use method like WrongAngleFixer for the corresponding resolution so that
> distortions caused by rounding are reduced
> + add code to detect parallel lines which should be deduplicated
> + store the objects, each only valid for this one level
>
> Finally do the sub division splitting, the merging of lines and shapes in
> each sub div and the binary encoding of the map.
> If possible, the merging and the Douglas-Peucker-Filter (or whatever)
> should be done before splitting into sub divs. I assume Garmins program is
> doing it that way because the data structures suggest that they fist
> calculate all the elements of all levels before it starts the splitting
> into sub divs.
>
> I guess this would produce nicer looking maps at lower resolutions. It
> would also require more heap memory (100% would be my guess) and more
> compilation time unless we find clever tricks to avoid that.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von
> Felix Hartmann <extremecarver at gmail.com>
> Gesendet: Donnerstag, 29. April 2021 14:39
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> here is what I mean - zig zagging like crazy if you look at it with lowest
> detail which is really helpful to see this problem. Those highways should
> be just straight. Oh yes - because the highways are two separate lanes they
> never have holes. Those holes with the patch are best visible on highway
> primary and secondary. Actually for highways maybe mkgmap could even
> include an algo to fix the double highway and just put it once into the map
> if it overlaps. So step a) remove zig zagging. Step two - remove any double
> highway if within 3-4 garmin units away from each other as long as we do
> not create a hole by this (at intersections). Every style has minimum width
> for highways of at least 3-4 units, if not 6-7, so drawing two highways on
> top of each other is waste of resources.  Actually this applies to all
> roads but will be mainly important for highways as they are nearly always
> entered into OSM with both directions as a separate line.
>
> On Thu, 29 Apr 2021 at 20:30, Felix Hartmann <extremecarver at gmail.com
> <mailto:extremecarver at gmail.com>> wrote:
> Yes - I also support Gerd that it doesn't work well for polygons.
> Now for lines it's another story.
> a) I love that lines are a bit straighter and looking better vs increasing
> douglas peucker.
> b) Sadly though there are bits and pieces of roads missing. If that is
> fixed I would be all supportive to use this for all lines. But not before
> those missing bits reappear.
> How to check for it - just use lowest detail level in Basecamp.
>
> Oh yeah and mkgmap without that patch also has a zig zagging problem.
> Maybe we would need a separate algorithm to check for zig zagging and make
> sure this does not happen. I really think we could need an algorithm that
> just checks for zig zagging from resolution 22 and lower and base it on the
> principle that 90% of all those zig zags are unwanted therefore just
> straighten lines if there is a zig zag.
> So nothing to do with this patch - but a general really needed improvement
> for mkgmap. (mkgmap is lacking a bit vs Garmin owns map at lower
> resolutions. At resolution 24 mkgmap produces fantastic maps, but garmins
> own maps are definitely better at lower resolutions regarding problems like
> zig zagging or reducing detail). Avoiding those zig zags would make the
> maps pan and load much faster on devices. I use a high DP value of 5.4
> because zoomed out further I feel this is needed. But the zig zagging
> occurs anyhow, or because of it?
>
> I really feel some little tweaks here could be a huge improvement for
> practical use on devices. We do not need exactness when zoomed out far -
> but we need the map to look nice. If a line is 1 or 2 points away from
> reality doesn't matter from resolution 17-21 and matters not too much for
> resolution 22. Only 23 and 24 should be more or less exact. (maybe for
> driving on highways with a car this is different - but is anyone actually
> using mkgmap created maps for this? I think nearly everyone uses google
> maps or smartphone. Garmin maps are mainly for outdoors or city maybe. But
> not for automobile use. Some people but not many motorcycle maybe. So the
> main importance for lower resolution is nice visual display and fast, not
> if a road misses some tiny turn or is 100m left or right. And with a car we
> have lock on road exactly for that. So visually it will be on the road
> anyhow even if the road is moved 1 or 2 garmin units to one side.
>
> On Wed, 28 Apr 2021 at 22:59, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
> wrote:
> Hi all,
>
> my observations at resolution 22:
> I think the patch re-introduces rendering problems at T-shaped crossings,
> sometimes they look like t-shapes at lower resolutions.
> Sample: https://www.openstreetmap.org/node/260418111
>
> It seems to filter more small polygons, even with  --min-size-polygon=0.
> I think it tends to make polygons smaller, not sure why.
>
> It sometimes reduces wrong zig-zagging, but only for ways with many
> points. In cities, where roads are often split into many small parts it
> sometimes makes things worse.
>
> It probably helps for the special case contour lines and therefore I
> suggest to limit it to them.
>
> Maybe the code to find the best place for a rounded coord should also
> consider to remove the point if that would give the best result.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>>
> Gesendet: Mittwoch, 28. April 2021 15:21
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> Hi Felix,
>
> I expect (more) small missing parts of complex shapes like forests or
> waterway areas (those without mkgmap:skipSizeFilter=true) and more obvious
> differences between shapes and lines, e.g. if a style renders outlines of
> buildings.
>
> The maps are very different at res 22, so it is hard to say if there are
> more  improvements then worsenings.
>
> I've experimented with different orders of filters in the past. It's
> difficult to test because the changes heavily depend on the Styte AND the
> mapped objects AND the mappers preferences. For example, if landuse areas
> are glued to highways or not, if landuse areas are glued to other landuse
> areas or if there nodes are just very close.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
> Gesendet: Mittwoch, 28. April 2021 14:58
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> Oh I thought it was mainly meant for contourlines. Did not know you intend
> it to be used in general. I am not really sure how and where to check for
> quality.
>
> On Wed, 28 Apr 2021 at 20:13, Gerd Petermann <
> gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com
> ><mailto:gpetermann_muenchen at hotmail.com<mailto:
> gpetermann_muenchen at hotmail.com>>> wrote:
> Hi Felix,
>
> your screen shots only show contour lines but the patch works on all types
> of lines and polygons. So, please also check the results with other maps.
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk><mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:
> mkgmap-dev-bounces at lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
> extremecarver at gmail.com<mailto:extremecarver at gmail.com><mailto:
> extremecarver at gmail.com<mailto:extremecarver at gmail.com>>>
> Gesendet: Mittwoch, 28. April 2021 04:54
> An: Development list for mkgmap; Andrzej Popowski
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> forgot 1.3 value - that is good enough (and this location is not the most
> difficult, but there are very few places that are worse. So I feel it's
> good enough as if it's fine here - there are very very few other places
> that are still problematic.
>
>
> On Wed, 28 Apr 2021 at 10:50, Felix Hartmann <extremecarver at gmail.com
> <mailto:extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com><mailto:extremecarver at gmail.com<mailto:
> extremecarver at gmail.com>>>> wrote:
> Thanks for that patch, the improvement is not as big as from the previous
> patch - but there is some.
> I analysed it a bit more - and I think there needs to be one more change -
> actually in general and not only for contourlines.
>
> We need different values for the douglas peucker algorithm depending on
> resolution!
>
> Right now we can only set one value, and that is multiplied for each
> resolution?
> Based on the current state I would like to have
>
> resolution
> 24= 0.0 or maybe actually have it active at 24 as well trying a value of
> 0.3 or so. Where there any problems with autorouting or why is it not
> possible to use it at resolution 24 as well?
> 23=1.3
> 22=2.6
> 21=3.9
> 20-11=5.4
>
>
> Especially if we produce a map without resolution 24, then resolution 23
> needs to have much lower DP value than the subsequent resolutions. Using
> 1.3 for resolution 23 makes the quality IMHO good enough to be used for an
> contourlines only map for GPS devices and skipping resolution 24
> altogether. For Desktop use resolution 24 may still make sense for
> contourlines - but even then the difference is only in very steep areas.
>
> Attached some screenshots at resolution 24, and at 23 with different DP
> values and one of patch2.
>
> On Tue, 27 Apr 2021 at 23:16, Andrzej Popowski <popej at poczta.onet.pl
> <mailto:popej at poczta.onet.pl><mailto:popej at poczta.onet.pl<mailto:
> popej at poczta.onet.pl>><mailto:popej at poczta.onet.pl<mailto:
> popej at poczta.onet.pl><mailto:popej at poczta.onet.pl<mailto:
> popej at poczta.onet.pl>>>> wrote:
> Hi,
>
> some more experiments, see attached patch. I have tried to optimize
> rounding of coordinates for lowest distance to line. This is not good
> for polygons, because can creates gaps between adjacent polygons.
>
> --
> Best regards,
> Andrzej
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk>><mailto:mkgmap-dev at lists.mkgmap.org.uk
> <mailto:mkgmap-dev at lists.mkgmap.org.uk><mailto:
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>>>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk
> ><mailto:mkgmap-dev at lists.mkgmap.org.uk<mailto:
> mkgmap-dev at lists.mkgmap.org.uk>>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210430/10e22a79/attachment-0001.html>