[mkgmap-dev] new branch low-res-opt to test improvements for filters

[Gerd Petermann]

Hi all,

as a result of the thread about raster problems I've started this new branch.

First commit implements experimental options to specify values for 
--reducePointError and --reducePointErrorPolygon for each resolution
Options are --simplify-filter-line-errors as replacement for --reducePointError 
and --simplify-filter-polygon-errors as replacement for 
--reducePointErrorPolygon. 
If --simplify-filter-line-errors is given and 
simplify-filter-polygon-errors is not given the values for lines are also 
used for polygons.
Meaning is similar to the --polygon-size-limits option, values are given in 
pairs 
Note that in resolution 24 the filter is not used.
Sample usage:
--x-simplify-filter-line-errors=23:1.3,22:2.6,20:4,18:6
--x-simplify-filter-polygon-errors=23:1.3,22:2.6,20:4
The old options are still supported, --reducePointErrorPolygon=1.3 is treated 
like --x-simplify-filter-line-errors=23:1.3

If none of the options is used the default is 2.6 for all resolutions.

There are a few more things to change:
- simplify4.patch with special code to improve rendering of contour lines 
- more-merge.patch to allow merging of roads at level > 0 
- Line merger could merge more lines if direction of the lines doesn't matter
- maybe I find a way to merge dual-carriage ways into one line (again, if 
direction doesn't matter)
- the --housenumber option should probably not assign numbers to trunk roads 
(similar to motorways), this can add lables to these roads and thus
prohibit merging.

None of these changes should change routing results. They can reduce img size 
and improve rendering.

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

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

[Gerd Petermann]

Hi Felix,

the branch is identical to trunk so far.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 3. Mai 2021 11:17
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

Is the branch already worthy for tryout? I guess this is a bigger projekt. Well 
sorry It would be great if the different DP level filters for mkgmap by 
resolution could be somehow make it into trunk. I think that should be pretty 
easy for you (notation can be the same as for the min-size-polygon).

On Mon, 3 May 2021 at 13:59, Felix Hartmann 
mailto:extremecar...@gmail.com>> wrote:
I think actually for any level >0 we do not need to keep specific points. The 
only important thing for level 1 and greater is that the roads have no holes. 
The lower the resolution the less important it is if they are starting ending 
at the correct point. Of course intersections need to share a common point, but 
it does not matter if that one is shifted a bit or not. Where roads are 
consisting of several parts - if they are merged then of course start-end 
points do not matter either.

Visually the zig zag is not too nice - but without using lower detail usually 
not too apparent. It's more the performance that suffers from all those not 
needed points. And yes for level 0 if a routing point is moved, then it needs 
to be moved for all lines that use it. I do also think moving by a tiny bit is 
not too important. But yes moving more than 7-8m at level 0 will be annoying I 
feel.  That's why only maps made for cars start at resolution 23, while 
topographic maps start at 24 because resolution 23 may not be exact enough even 
though with lock on road you will not notice it at all. having a line 7-8m to 
one side - and having the GPS wandering off to the opposite side would not be 
optimal. Anyting below 5m should however not matter. maybe anything below 10m 
actually doesn't matter? Clearly if a road is off by 20m or more at level 0 
that will matter.

On Mon, 3 May 2021 at 13:40, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

I started a new branch low-res-opt. I think the handling of the "preserved" 
status of points needs more work. Current code preserves too many points which 
are not important. Filters try to keep preseved points and that means more 
points and more zig-zagging.
I think
- we MUST preserve routing nodes and end nodes of roads, at least for level 0
- should preserve points which are shared by different lines or shapes so that 
connections are not removed

Work in progress...

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Montag, 3. Mai 2021 07:27
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

Actually I think I did some mistake concerning the patch - or the patch is not 
working together with the simplify v4 patch. I think I made a mistake and my 
changes were just based on having one version with wrong angle fixer 0.05 vs 
0.5 and that does create some tiny changes on autorouting. Mind though I did 
never use preserve-element-order. I'm just trying again and if again no change 
I will remove simplify v4 patch.

On Mon, 3 May 2021 at 12:38, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

if you see random results with routing please check if you use 
--preserve-element-order. For tests like this I really recommend it.
OTOH it would be very interesting to find out that the order of data has an 
influence on routing in a way that a better or worse route is calculated. So 
far I never found a hint for that.

Gerd



Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
 im Auftrag von Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>>>
Gesendet: Sonntag, 2. Mai 2021 19:15
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

Hi Felix,

the more-merge.patch  should have no effect on routing. In my tests NET and NOD 
data was identical. Did you really compare it with an unpatched version? If 
there are differences in routing my understanding of the data structures is 
wrong.

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
 im Auftrag von Felix Hartmann