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

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

2021-05-04 Thread Felix Hartmann

I find that while using many levels the overall map size increases, each
zoom level is a bit better. So I use all resolution from 24-18 for the map,
and 11-17 for the overview map.
levels = 0:24, 1:22, 2:21, 3:20, 4:19, 5:18
overview-levels = 6:17, 7:16, 8:15, 9:14, 10:12, 11:11
For contourlines of course no overview map, and starting later.

As for highways - they usually are inside a highway relation, but without
specifying which is which direction or anything. In general each direction
has a oneway=yes/1/-1/reverse tag. but yes that relation will not help at
all I feel. There is no way inside osm data to directly tell that it goes
two ways and be able to say from resolution 18 or 19 onwards only to say
show direction=forward vs direction=forward and direction=backward lines.

On Tue, 4 May 2021 at 20:33, Gerd Petermann 
wrote:

> Hi Felix,
>
> it probably depends on the --levels option, means, how many levels you put
> into a gmapsupp.
>
> And yes, I don't have a clear idea how to detect parallel lines which will
> / should collapse into one line.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Dienstag, 4. Mai 2021 13:19
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> Wow - looks really good. The main problem I feel is now that sometimes
> highways you can see both directions apart - while before this was less
> rare - or lost in the jaggedness.
>
> --x-simplify-filter-line-errors=23:3.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,15:9
> --x-simplify-filter-polygon-errors=23:4.6,22:7,21:8,20:9,15:10
> --polygon-size-limits=24:16,23:14,22:12,21:11,20:10,19:9,18:8,17:7,16:6,15:5,14:4,13:3,12:2,11:0,10:0
> seems to give pretty nice results - and much faster on my Garmin 600 at
> lower resolutions.
>
> I guess those highways with dual directions are much harder to solve...
>
> On Tue, 4 May 2021 at 17:24, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> OK, I am happy to hear feedback regarding the latest changes the branch.
> Next planned step is to check if the simplify4.patch still improves things
> and maybe improve it further.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Dienstag, 4. Mai 2021 11:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> well I never got the merge-more patch actually running as together with
> simplify v4 it did not change anything for me. I'm waiting for updates on
> the new branch to test things.
> I still feel level>=1, the higher the level the less exact it needs to be.
> It just needs to be small and beautiful from resolution 21 and lower. While
> actually driving/riding/walking you will always use 24-22 (even 22 only in
> car I feel. Maybe 21 on highways).
>
> Those levels are important on PC and GPS device for orientation. And while
> actual switchback turns on a road would be quite worthwhile, those zig zag
> things aren't.
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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@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@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

2021-05-04 Thread Gerd Petermann

Hi Felix,

it probably depends on the --levels option, means, how many levels you put into
a gmapsupp.

And yes, I don't have a clear idea how to detect parallel lines which will /
should collapse into one line.

Gerd

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

Wow - looks really good. The main problem I feel is now that sometimes highways
you can see both directions apart - while before this was less rare - or lost
in the jaggedness.

--x-simplify-filter-line-errors=23:3.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,15:9
--x-simplify-filter-polygon-errors=23:4.6,22:7,21:8,20:9,15:10
--polygon-size-limits=24:16,23:14,22:12,21:11,20:10,19:9,18:8,17:7,16:6,15:5,14:4,13:3,12:2,11:0,10:0
seems to give pretty nice results - and much faster on my Garmin 600 at lower
resolutions.

I guess those highways with dual directions are much harder to solve...

On Tue, 4 May 2021 at 17:24, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

OK, I am happy to hear feedback regarding the latest changes the branch. Next
planned step is to check if the simplify4.patch still improves things and maybe
improve it further.

Gerd

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

well I never got the merge-more patch actually running as together with
simplify v4 it did not change anything for me. I'm waiting for updates on the
new branch to test things.
I still feel level>=1, the higher the level the less exact it needs to be. It
just needs to be small and beautiful from resolution 21 and lower. While
actually driving/riding/walking you will always use 24-22 (even 22 only in car
I feel. Maybe 21 on highways).

Those levels are important on PC and GPS device for orientation. And while
actual switchback turns on a road would be quite worthwhile, those zig zag
things aren't.

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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@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

2021-05-04 Thread Felix Hartmann

Wow - looks really good. The main problem I feel is now that sometimes
highways you can see both directions apart - while before this was less
rare - or lost in the jaggedness.

--x-simplify-filter-line-errors=23:3.6,22:4.2,21:5.4,20:6,19:7,18:7.5,16:8,15:9
--x-simplify-filter-polygon-errors=23:4.6,22:7,21:8,20:9,15:10
--polygon-size-limits=24:16,23:14,22:12,21:11,20:10,19:9,18:8,17:7,16:6,15:5,14:4,13:3,12:2,11:0,10:0
seems to give pretty nice results - and much faster on my Garmin 600 at
lower resolutions.

I guess those highways with dual directions are much harder to solve...

On Tue, 4 May 2021 at 17:24, Gerd Petermann 
wrote:

> Hi Felix,
>
> OK, I am happy to hear feedback regarding the latest changes the branch.
> Next planned step is to check if the simplify4.patch still improves things
> and maybe improve it further.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Dienstag, 4. Mai 2021 11:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> well I never got the merge-more patch actually running as together with
> simplify v4 it did not change anything for me. I'm waiting for updates on
> the new branch to test things.
> I still feel level>=1, the higher the level the less exact it needs to be.
> It just needs to be small and beautiful from resolution 21 and lower. While
> actually driving/riding/walking you will always use 24-22 (even 22 only in
> car I feel. Maybe 21 on highways).
>
> Those levels are important on PC and GPS device for orientation. And while
> actual switchback turns on a road would be quite worthwhile, those zig zag
> things aren't.
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@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@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

2021-05-04 Thread Gerd Petermann

Hi Felix,

OK, I am happy to hear feedback regarding the latest changes the branch. Next 
planned step is to check if the simplify4.patch still improves things and maybe 
improve it further.

Gerd


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

well I never got the merge-more patch actually running as together with 
simplify v4 it did not change anything for me. I'm waiting for updates on the 
new branch to test things.
I still feel level>=1, the higher the level the less exact it needs to be. It 
just needs to be small and beautiful from resolution 21 and lower. While 
actually driving/riding/walking you will always use 24-22 (even 22 only in car 
I feel. Maybe 21 on highways).

Those levels are important on PC and GPS device for orientation. And while 
actual switchback turns on a road would be quite worthwhile, those zig zag 
things aren't.


___
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

2021-05-04 Thread Felix Hartmann

well I never got the merge-more patch actually running as together with
simplify v4 it did not change anything for me. I'm waiting for updates on
the new branch to test things.
I still feel level>=1, the higher the level the less exact it needs to be.
It just needs to be small and beautiful from resolution 21 and lower. While
actually driving/riding/walking you will always use 24-22 (even 22 only in
car I feel. Maybe 21 on highways).

Those levels are important on PC and GPS device for orientation. And while
actual switchback turns on a road would be quite worthwhile, those zig zag
things aren't.
___
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

2021-05-04 Thread Gerd Petermann

Hi Felix,

the more-merge.patch patch is probably too aggressive. It changes data in NET
and that is probably not correct. NET contains information about all lines
which make up a road, at all resolutions. I don't know why but I think this
means that we really must not merge roads when we have a NET file.

Gerd

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

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><mailto:gpetermann_muenc...@hotmail.com<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><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
im Auftrag von Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<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

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

2021-05-03 Thread 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.

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

Work in progress...

Gerd

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

Gerd

Hi Felix,

Gerd

Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgm

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

2021-05-02 Thread Gerd Petermann

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  im Auftrag von Felix 
Hartmann 
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 
mailto:extremecar...@gmail.com>>
Gesendet: Sonntag, 2. Mai 2021 17:50
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

yes I tried it out now without additional DP changes. Routing was identical in 
18 out of 20 routes. Twice a tiny difference, hard to say if worse or better. 
Pretty similar. As for if the visual quality was improved, The jaggedness is a 
bit better - but still quite a lot of unneeded zig zags. Higher DP values of 
course improve it.

On Sun, 2 May 2021 at 21:16, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

please try first just my patch, not any further modifications from your side.
You can use  unpatched DouglasPeuckerFilter from trunk.

Gerd


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

Going to test out the patch a bit more right now. Only problem for me is - I 
cannot set custom dp filter anymore.. But I guess you will implement that 
anyhow soon?

compile:
[javac] Compiling 1 source file to C:\garmin\mkgmap_trunk\build\classes
[javac] 
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:64:
 error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance * 1.3 * 
(1<< config.getShift()); }
[javac] 
^
[javac]   symbol:   variable config
[javac]   location: class DouglasPeuckerFilter
[javac] 
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:66:
 error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance * 2 * 
(1<< config.getShift()); }
[javac]


I will try out at least 20 routes back to back on longer distances to see if 
something changes to the worse or better with the patch.

On Sun, 2 May 2021 at 17:54, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hot

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

2021-05-02 Thread Gerd Petermann

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  im Auftrag von Gerd 
Petermann 
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  im Auftrag von Felix 
Hartmann 
Gesendet: Sonntag, 2. Mai 2021 17:50
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

yes I tried it out now without additional DP changes. Routing was identical in 
18 out of 20 routes. Twice a tiny difference, hard to say if worse or better. 
Pretty similar. As for if the visual quality was improved, The jaggedness is a 
bit better - but still quite a lot of unneeded zig zags. Higher DP values of 
course improve it.

On Sun, 2 May 2021 at 21:16, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

please try first just my patch, not any further modifications from your side.
You can use  unpatched DouglasPeuckerFilter from trunk.

Gerd


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

Going to test out the patch a bit more right now. Only problem for me is - I 
cannot set custom dp filter anymore.. But I guess you will implement that 
anyhow soon?

compile:
[javac] Compiling 1 source file to C:\garmin\mkgmap_trunk\build\classes
[javac] 
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:64:
 error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance * 1.3 * 
(1<< config.getShift()); }
[javac] 
^
[javac]   symbol:   variable config
[javac]   location: class DouglasPeuckerFilter
[javac] 
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:66:
 error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance * 2 * 
(1<< config.getShift()); }
[javac]


I will try out at least 20 routes back to back on longer distances to see if 
something changes to the worse or better with the patch.

On Sun, 2 May 2021 at 17:54, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

attached patch allows to merge roads at levels > 0. This reduced file file and 
zig-zagging. I didn't see routing problems but didn't test this much.

The patch contains also experimtal code for DouglasPeuckerFilter which is not 
yet enabled. It reduces a bit more but is not yet tested.

Gerd


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

well I increased it to 0.5, and could not see any place which was actually 
different. I noticed in some places the labels were at different positions, so 
it indeed changed something. Also file size decreased a little bit. I tried 
about 15 routes with autorouting, and one actually routed a little bit 
different. It was more or less identical however. So not sure if this makes 
sense or not. It can save maybe 0.5% of filesize.

On Sat, 1 May 2021 at 14:02, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>>
 wrote:
Hi Felix,

the WrongAngleFixer takes care

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

2021-05-02 Thread Gerd Petermann

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  im Auftrag von Felix 
Hartmann 
Gesendet: Sonntag, 2. Mai 2021 17:50
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

yes I tried it out now without additional DP changes. Routing was identical in 
18 out of 20 routes. Twice a tiny difference, hard to say if worse or better. 
Pretty similar. As for if the visual quality was improved, The jaggedness is a 
bit better - but still quite a lot of unneeded zig zags. Higher DP values of 
course improve it.

On Sun, 2 May 2021 at 21:16, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

please try first just my patch, not any further modifications from your side.
You can use  unpatched DouglasPeuckerFilter from trunk.

Gerd


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

Going to test out the patch a bit more right now. Only problem for me is - I 
cannot set custom dp filter anymore.. But I guess you will implement that 
anyhow soon?

compile:
[javac] Compiling 1 source file to C:\garmin\mkgmap_trunk\build\classes
[javac] 
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:64:
 error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance * 1.3 * 
(1<< config.getShift()); }
[javac] 
^
[javac]   symbol:   variable config
[javac]   location: class DouglasPeuckerFilter
[javac] 
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:66:
 error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance * 2 * 
(1<< config.getShift()); }
[javac]


I will try out at least 20 routes back to back on longer distances to see if 
something changes to the worse or better with the patch.

On Sun, 2 May 2021 at 17:54, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

attached patch allows to merge roads at levels > 0. This reduced file file and 
zig-zagging. I didn't see routing problems but didn't test this much.

The patch contains also experimtal code for DouglasPeuckerFilter which is not 
yet enabled. It reduces a bit more but is not yet tested.

Gerd


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

well I increased it to 0.5, and could not see any place which was actually 
different. I noticed in some places the labels were at different positions, so 
it indeed changed something. Also file size decreased a little bit. I tried 
about 15 routes with autorouting, and one actually routed a little bit 
different. It was more or less identical however. So not sure if this makes 
sense or not. It can save maybe 0.5% of filesize.

On Sat, 1 May 2021 at 14:02, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>>
 wrote:
Hi Felix,

the WrongAngleFixer takes care about filtering at resolution 24. It calls the 
DouglasPeucker filter with maxErrorDistance = 0.05.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4172

Maybe try to play with the value 0.05.
WrongAngleFixer tries to produce a result that is closer to the OSM data than 
simple rounding to Garmin raster and removes points which
don't improve the rendered image if they are not needed for routing.

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<m

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

2021-05-02 Thread Felix Hartmann

yes I tried it out now without additional DP changes. Routing was identical
in 18 out of 20 routes. Twice a tiny difference, hard to say if worse or
better. Pretty similar. As for if the visual quality was improved, The
jaggedness is a bit better - but still quite a lot of unneeded zig zags.
Higher DP values of course improve it.

On Sun, 2 May 2021 at 21:16, Gerd Petermann 
wrote:

> Hi Felix,
>
> please try first just my patch, not any further modifications from your
> side.
> You can use  unpatched DouglasPeuckerFilter from trunk.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Sonntag, 2. Mai 2021 15:09
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> Going to test out the patch a bit more right now. Only problem for me is -
> I cannot set custom dp filter anymore.. But I guess you will implement that
> anyhow soon?
>
> compile:
> [javac] Compiling 1 source file to C:\garmin\mkgmap_trunk\build\classes
> [javac]
> C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:64:
> error: cannot find symbol
> [javac] this.maxErrorDistance = filterDistance *
> 1.3 * (1<< config.getShift()); }
> [javac]
>  ^
> [javac]   symbol:   variable config
> [javac]   location: class DouglasPeuckerFilter
> [javac]
> C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:66:
> error: cannot find symbol
> [javac] this.maxErrorDistance = filterDistance * 2
> * (1<< config.getShift()); }
> [javac]
> 
>
> I will try out at least 20 routes back to back on longer distances to see
> if something changes to the worse or better with the patch.
>
> On Sun, 2 May 2021 at 17:54, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> attached patch allows to merge roads at levels > 0. This reduced file file
> and zig-zagging. I didn't see routing problems but didn't test this much.
>
> The patch contains also experimtal code for DouglasPeuckerFilter which is
> not yet enabled. It reduces a bit more but is not yet tested.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Samstag, 1. Mai 2021 18:06
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> well I increased it to 0.5, and could not see any place which was actually
> different. I noticed in some places the labels were at different positions,
> so it indeed changed something. Also file size decreased a little bit. I
> tried about 15 routes with autorouting, and one actually routed a little
> bit different. It was more or less identical however. So not sure if this
> makes sense or not. It can save maybe 0.5% of filesize.
>
> On Sat, 1 May 2021 at 14:02, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote:
> Hi Felix,
>
> the WrongAngleFixer takes care about filtering at resolution 24. It calls
> the DouglasPeucker filter with maxErrorDistance = 0.05.
> See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4172
>
> Maybe try to play with the value 0.05.
> WrongAngleFixer tries to produce a result that is closer to the OSM data
> than simple rounding to Garmin raster and removes points which
> don't improve the rendered image if they are not needed for routing.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk> mkgmap-dev-boun...@lists.mkgmap.org.uk mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>>
> Gesendet: Freitag, 30. April 2021 16:42
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> 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

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

2021-05-02 Thread Gerd Petermann

Hi Felix,

please try first just my patch, not any further modifications from your side.
You can use  unpatched DouglasPeuckerFilter from trunk.

Gerd


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

Going to test out the patch a bit more right now. Only problem for me is - I 
cannot set custom dp filter anymore.. But I guess you will implement that 
anyhow soon?

compile:
[javac] Compiling 1 source file to C:\garmin\mkgmap_trunk\build\classes
[javac] 
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:64:
 error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance * 1.3 * 
(1<< config.getShift()); }
[javac] 
^
[javac]   symbol:   variable config
[javac]   location: class DouglasPeuckerFilter
[javac] 
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:66:
 error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance * 2 * 
(1<< config.getShift()); }
[javac]


I will try out at least 20 routes back to back on longer distances to see if 
something changes to the worse or better with the patch.

On Sun, 2 May 2021 at 17:54, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

attached patch allows to merge roads at levels > 0. This reduced file file and 
zig-zagging. I didn't see routing problems but didn't test this much.

The patch contains also experimtal code for DouglasPeuckerFilter which is not 
yet enabled. It reduces a bit more but is not yet tested.

Gerd


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

well I increased it to 0.5, and could not see any place which was actually 
different. I noticed in some places the labels were at different positions, so 
it indeed changed something. Also file size decreased a little bit. I tried 
about 15 routes with autorouting, and one actually routed a little bit 
different. It was more or less identical however. So not sure if this makes 
sense or not. It can save maybe 0.5% of filesize.

On Sat, 1 May 2021 at 14:02, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

the WrongAngleFixer takes care about filtering at resolution 24. It calls the 
DouglasPeucker filter with maxErrorDistance = 0.05.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4172

Maybe try to play with the value 0.05.
WrongAngleFixer tries to produce a result that is closer to the OSM data than 
simple rounding to Garmin raster and removes points which
don't improve the rendered image if they are not needed for routing.

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>>>
Gesendet: Freitag, 30. April 2021 16:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

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 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>>
 wrote:
Hi all,

attached is

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

2021-05-02 Thread Felix Hartmann

Going to test out the patch a bit more right now. Only problem for me is -
I cannot set custom dp filter anymore.. But I guess you will implement that
anyhow soon?

compile:
[javac] Compiling 1 source file to C:\garmin\mkgmap_trunk\build\classes
[javac]
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:64:
error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance *
1.3 * (1<< config.getShift()); }
[javac]
^
[javac]   symbol:   variable config
[javac]   location: class DouglasPeuckerFilter
[javac]
C:\garmin\mkgmap_trunk\src\uk\me\parabola\mkgmap\filters\DouglasPeuckerFilter.java:66:
error: cannot find symbol
[javac] this.maxErrorDistance = filterDistance * 2
* (1<< config.getShift()); }
[javac]


I will try out at least 20 routes back to back on longer distances to see
if something changes to the worse or better with the patch.

On Sun, 2 May 2021 at 17:54, Gerd Petermann 
wrote:

> Hi Felix,
>
> attached patch allows to merge roads at levels > 0. This reduced file file
> and zig-zagging. I didn't see routing problems but didn't test this much.
>
> The patch contains also experimtal code for DouglasPeuckerFilter which is
> not yet enabled. It reduces a bit more but is not yet tested.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Samstag, 1. Mai 2021 18:06
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> well I increased it to 0.5, and could not see any place which was actually
> different. I noticed in some places the labels were at different positions,
> so it indeed changed something. Also file size decreased a little bit. I
> tried about 15 routes with autorouting, and one actually routed a little
> bit different. It was more or less identical however. So not sure if this
> makes sense or not. It can save maybe 0.5% of filesize.
>
> On Sat, 1 May 2021 at 14:02, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> the WrongAngleFixer takes care about filtering at resolution 24. It calls
> the DouglasPeucker filter with maxErrorDistance = 0.05.
> See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4172
>
> Maybe try to play with the value 0.05.
> WrongAngleFixer tries to produce a result that is closer to the OSM data
> than simple rounding to Garmin raster and removes points which
> don't improve the rendered image if they are not needed for routing.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Freitag, 30. April 2021 16:42
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> 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_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@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

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

2021-05-02 Thread Gerd Petermann

Hi Felix,

attached patch allows to merge roads at levels > 0. This reduced file file and
zig-zagging. I didn't see routing problems but didn't test this much.

The patch contains also experimtal code for DouglasPeuckerFilter which is not
yet enabled. It reduces a bit more but is not yet tested.

Gerd

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

well I increased it to 0.5, and could not see any place which was actually
different. I noticed in some places the labels were at different positions, so
it indeed changed something. Also file size decreased a little bit. I tried
about 15 routes with autorouting, and one actually routed a little bit
different. It was more or less identical however. So not sure if this makes
sense or not. It can save maybe 0.5% of filesize.

On Sat, 1 May 2021 at 14:02, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

the WrongAngleFixer takes care about filtering at resolution 24. It calls the
DouglasPeucker filter with maxErrorDistance = 0.05.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4172

Maybe try to play with the value 0.05.
WrongAngleFixer tries to produce a result that is closer to the OSM data than
simple rounding to Garmin raster and removes points which
don't improve the rendered image if they are not needed for routing.

Gerd

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

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
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@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
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
im Auftrag von Felix Hartmann
mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@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

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

2021-05-01 Thread Felix Hartmann

well I increased it to 0.5, and could not see any place which was actually
different. I noticed in some places the labels were at different positions,
so it indeed changed something. Also file size decreased a little bit. I
tried about 15 routes with autorouting, and one actually routed a little
bit different. It was more or less identical however. So not sure if this
makes sense or not. It can save maybe 0.5% of filesize.

On Sat, 1 May 2021 at 14:02, Gerd Petermann 
wrote:

> Hi Felix,
>
> the WrongAngleFixer takes care about filtering at resolution 24. It calls
> the DouglasPeucker filter with maxErrorDistance = 0.05.
> See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4172
>
> Maybe try to play with the value 0.05.
> WrongAngleFixer tries to produce a result that is closer to the OSM data
> than simple rounding to Garmin raster and removes points which
> don't improve the rendered image if they are not needed for routing.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Freitag, 30. April 2021 16:42
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> 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_muenc...@hotmail.com<mailto:gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@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 mai

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

2021-05-01 Thread Gerd Petermann

Hi Felix,

the WrongAngleFixer takes care about filtering at resolution 24. It calls the
DouglasPeucker filter with maxErrorDistance = 0.05.
See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4172

Gerd

Von: mkgmap-dev im Auftrag von Felix
Hartmann
Gesendet: Freitag, 30. April 2021 16:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23
raster problems

Garmins maps in this aspect are clearly superior.

On Fri, 30 Apr 2021 at 21:50, Gerd Petermann
mailto:gpetermann_muenc...@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.

Gerd

Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
im Auftrag von Felix Hartmann
mailto:extremecar...@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
mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@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.

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

2021-04-30 Thread Felix Hartmann

I just tried out the simplify4 patch - it gives the best results so far.
Overall this is really a huge improvement now for contourlines! Strangely
also at resolution 24 there have been improvements (or is it changes?).
Actually I wanted to try DP at resolution 24 but removing those lines that
prevent it to run, and adding 24 * 1 into my patch, changed absolutely
nothing. Maybe the newest simplify4 patch does DP for resolution 24 too?

Still at resolution 24 the contourlines with B-Spline from kleineisel vs
phyghtmap look nicer - and I would guess are a little bit more correct -
but mkgmap cannot improve data and gnuplot just seems to work better than
phyghtmap. But from resolution 23 onwards it's exactly the opposite. My
contourlines with simplify v4, DP at 1.3 and then according to my patch,
look way way better in mountains. In flatter areas the differences are
anyhow smaller.

I'm still playing around a bit with values for the dp filter. The essential
is to have lower values for 23 and 22 and higher after. For contourlines a
lower value is needed IMHO than for maps - as contourlines look strange if
they get straightened too much. Maybe partly due to the underlying data
quality too. Compared to the current I feel for maps 23=3.6, 22=5.4, 21=8,
20and onwards 10.8 or so seems to work quite well. For contourlines 23=1.3,
22=2.6, 21=4, <=20=5.4 seems to work quite well. I think maybe move that
into the options file so it doesn't clutter up the commandline too much.
Now what to use default I find hard to say. Because without contourlines
higher values do not cause problems visually.

I have not toyed around with polygons. Polygons are a bit tougher anyhow
maybe, if too high values create holes?

On Fri, 30 Apr 2021 at 21:50, Gerd Petermann <
gpetermann_muenc...@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  im Auftrag von
> Felix Hartmann 
> 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  <mailto:extremecar...@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 supporti

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

2021-04-30 Thread Gerd Petermann

Hi Felix,

I can't be sure because nothing was coded yet. I like the general idea, I've
already described it in the todo list years ago:
https://www.mkgmap.org.uk/dev/todo

Gerd

Garmins maps in this aspect are clearly superior.

On Fri, 30 Apr 2021 at 21:50, Gerd Petermann
mailto:gpetermann_muenc...@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.

Gerd

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. (mk

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

2021-04-30 Thread Felix Hartmann

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_muenc...@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  im Auftrag von
> Felix Hartmann 
> 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  <mailto:extremecar...@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

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

2021-04-30 Thread Gerd Petermann

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  im Auftrag von Felix 
Hartmann 
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 
mailto:extremecar...@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

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

2021-04-29 Thread Felix Hartmann

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 
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_muenc...@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  im Auftrag von
>> Gerd Petermann 
>> 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

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

2021-04-29 Thread Felix Hartmann

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_muenc...@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  im Auftrag von
> Gerd Petermann 
> 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  im Auftrag von
> Felix Hartmann 
> 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_muenc...@hotmail.com<mailto:gpetermann_muenc...@

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

2021-04-28 Thread Gerd Petermann

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 im Auftrag von Gerd
Petermann
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 im Auftrag von Felix
Hartmann
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
mailto:gpetermann_muenc...@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
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
im Auftrag von Felix Hartmann
mailto:extremecar...@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
mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@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
mailto:po...@poczta.onet.pl><mailto:po...@poczta.onet.pl<mailto:po...@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@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@li

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

2021-04-28 Thread Gerd Petermann

Hi Felix,

The maps are very different at res 22, so it is hard to say if there are more
improvements then worsenings.

Gerd

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
mailto:gpetermann_muenc...@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

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

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
mailto:po...@poczta.onet.pl><mailto:po...@poczta.onet.pl<mailto:po...@poczta.onet.pl>>>
wrote:
Hi,

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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@lists.mkgmap.org.uk<mailto:mkgmap-dev@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@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

2021-04-28 Thread Felix Hartmann

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_muenc...@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  im Auftrag von
> Felix Hartmann 
> 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  <mailto:extremecar...@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  <mailto:po...@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@lists.mkgmap.org.uk<mailto:mkgmap-dev@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@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@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

2021-04-28 Thread Gerd Petermann

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  im Auftrag von Felix 
Hartmann 
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 
mailto:extremecar...@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 
mailto:po...@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@lists.mkgmap.org.uk<mailto:mkgmap-dev@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@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

2021-04-28 Thread Gerd Petermann

Hi Andrzej,

thanks, looks like a good approach. I have to run some tests to understand the 
effects.

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Dienstag, 27. April 2021 17:16
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

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@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

2021-04-27 Thread Andrzej Popowski


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
Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- src/uk/me/parabola/mkgmap/build/MapBuilder.java (revision 4685)
+++ src/uk/me/parabola/mkgmap/build/MapBuilder.java (working copy)
@@ -87,6 +87,7 @@
 import uk.me.parabola.mkgmap.filters.RemoveEmpty;
 import uk.me.parabola.mkgmap.filters.RemoveObsoletePointsFilter;
 import uk.me.parabola.mkgmap.filters.RoundCoordsFilter;
+import uk.me.parabola.mkgmap.filters.RoundCoordsFilter2;
 import uk.me.parabola.mkgmap.filters.ShapeMergeFilter;
 import uk.me.parabola.mkgmap.filters.SizeFilter;
 import uk.me.parabola.mkgmap.general.CityInfo;
@@ -1188,10 +1189,10 @@

LayerFilterChain filters = new LayerFilterChain(config);
if (enableLineCleanFilters && (res < 24)) {
-   filters.addFilter(new RoundCoordsFilter());
filters.addFilter(new SizeFilter(MIN_SIZE_LINE));
if(reducePointError > 0)
filters.addFilter(new 
DouglasPeuckerFilter(reducePointError));
+   filters.addFilter(new RoundCoordsFilter2());
}
filters.addFilter(new LineSplitterFilter());
filters.addFilter(new RemoveEmpty());
@@ -1243,7 +1244,6 @@
LayerFilterChain filters = new LayerFilterChain(config);
filters.addFilter(new PolygonSplitterFilter());
if (enableLineCleanFilters && (res < 24)) {
-   filters.addFilter(new RoundCoordsFilter());
int sizefilterVal =  
getMinSizePolygonForResolution(res);
if (sizefilterVal > 0)
filters.addFilter(new 
SizeFilter(sizefilterVal));
@@ -1251,6 +1251,7 @@
//Is there an similar algorithm for polygons?
if(reducePointErrorPolygon > 0)
filters.addFilter(new 
DouglasPeuckerFilter(reducePointErrorPolygon));
+   filters.addFilter(new RoundCoordsFilter());
}
filters.addFilter(new RemoveObsoletePointsFilter());
filters.addFilter(new RemoveEmpty());
Index: src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter2.java
===
--- src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter2.java   (nonexistent)
+++ src/uk/me/parabola/mkgmap/filters/RoundCoordsFilter2.java   (working copy)
@@ -0,0 +1,145 @@
+/*
+ * Copyright (C) 2007 Steve Ratcliffe
+ * 
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License version 2 as
+ *  published by the Free Software Foundation.
+ * 
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ * 
+ */
+package uk.me.parabola.mkgmap.filters;
+
+import java.util.ArrayList;
+import java.util.List;
+
+import uk.me.parabola.imgfmt.app.Coord;
+import uk.me.parabola.imgfmt.app.CoordNode;
+import uk.me.parabola.mkgmap.general.MapElement;
+import uk.me.parabola.mkgmap.general.MapLine;
+import uk.me.parabola.mkgmap.general.MapRoad;
+
+public class RoundCoordsFilter2 implements MapFilter {
+
+   private int shift;
+   private boolean keepNodes;
+   private int level;
+
+   @Override
+   public void init(FilterConfig config) {
+   shift = config.getShift();
+   level = config.getLevel();
+   keepNodes = level == 0 && config.hasNet();
+   }
+
+   /**
+* @param element A map element that will be a line or a polygon.
+* @param next This is used to pass the possibly transformed element 
onward.
+*/
+   @Override
+   public void doFilter(MapElement element, MapFilterChain next) {
+   if (shift == 0) {
+   // do nothing
+   next.doFilter(element);
+   } else {
+   MapLine line = (MapLine) element;
+   int full = 1 << shift;
+   int half = 1 << (shift - 1);// 0.5 shifted
+   int mask = ~((1 << shift) - 1); // to remove fraction 
bits
+   
+   // round lat/lon values to nearest for shift
+   List newPoints = new 
ArrayList<>(line.getPoints().size());
+
+   List coords = line.getPoints();
+   int

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

2021-04-26 Thread Felix Hartmann

Well yes in that case they must. However for overhanging rocks the hgt
files are incompatible. All sources we use for phyghtmap or srt2osm or
other tools rely on 2D models to show the altitude. So for what we have
right now - contourlines shall never cross.

On Mon, 26 Apr 2021 at 18:22, Thomas Morgenstern 
wrote:

> I think , your wish,  never cross contourlines, shows not the reality. In
> fact there are some rocks, cliffs with 90 ° declination. For exampel: the
> cliffs near Los Gigantes (tenerife) and the Baranco del Inferno
> (tenerife) . In such situations, the contourlines must touch each other.
> And how to procede, if the rocks hang over ? Contourlines must cross !?
> thomas
>
> Am 26.04.2021 um 11:02 schrieb Felix Hartmann:
>
> I'm not fully sure of the exact location anymore - not too far away
> from N47° 31.285' E12° 55.889' however. And using Basecamp map details at
> lowest (this will allow you to see the problems much easier).
>
> On Mon, 26 Apr 2021 at 16:40, Thomas Morgenstern 
> wrote:
>
>> @ Felix : please, can you post coordinates of your screenshots ?. i will
>> look at my own contourlines at this position.
>> thomas
>>
>> Am 26.04.2021 um 10:15 schrieb Felix Hartmann:
>>
>> yes - for contourlines it would be great if the algo could check that
>> lines never cross - and if moving one direction vs the other means not
>> touching vs touching - then move the other direction. So it would need to
>> loop at for each line, at the next 2 lines. The big advantage would be for
>> contourlines only maps (which makes most sense IMHO, as you don't need to
>> update contourlines except if there is newer better data which is rare)
>> that you can create them with resolution 23 as highest resolution
>> instead of 24. Saving about 50% of the space. Old Garmin devices scroll
>> notably slower with resolution 24 contourlines vs 23, even more of course
>> if 10m equidistance instead of 20m equidistance is used.
>>
>> As 0x20, 0x21 and 0x22 are always contourlines - those lines could easily
>> be distinguished (there is one second set of contour line types in newer
>> garmin maps, I don't know if that matters, and cant remember the types
>> right now). If this treatment is a lot slower - then it should have a
>> command option, so whoever integrates the contourlines has the choice of
>> chosing it. Because for separate contourlines even doubling or
>> tripling compilation times do not matter much.
>>
>> On Mon, 26 Apr 2021 at 15:45, Gerd Petermann <
>> gpetermann_muenc...@hotmail.com> wrote:
>>
>>> Hi all,
>>>
>>> the major problem with resolution 23 and lower is the rounding to garmin
>>> units without looking at the distortions (WrongAngleFixer does that for res
>>> 24)
>>>
>>> At res 23 we have to draw the lines using a "bed of nails" where the
>>> nails have ~5m distance to each other. If the original line "meanders"
>>> horizontally close to the nails there is no big problem, nodes are probably
>>> rounded to a straight line. If the same line is moved by ~2.5 m up or down
>>> we often hit the worst case scenario where one node is rounded to the north
>>> and the next is rounded to the south. This produces visible zig-zagging.
>>> If two or more almost parallel lines meat this worst case you see the
>>> obvious errros where contour lines overlap.
>>>
>>> The logic in WrongAngleFixer tries to detect this and sometimes decides
>>> to round to a different place to reduce zig-zagging. The problem is that
>>> this has to be done looking at all lines, not just one, at least with
>>> normal OSM data where we have intersections.
>>>
>>> For contourlines it would be best if the generator would only calculate
>>> nodes which are exactly at the positions of the Garmin nails, but that is
>>> probaby not easy.
>>> The special case here is that it doesn't really matter where the nodes
>>> are, we just need "good looking" lines and that each node is only used by
>>> one contour way.
>>>
>>> Maybe it is possible to do this with a separate program or a special
>>> method in mkgmap which just treats contour lines
>>> - take generated contour data as input
>>> - rerender each way with resolution 23 nodes so that the line looks
>>> almost like before. This means it may add nodes somewhere and remove others.
>>> - maybe re-iterate if the rerendering caused overlapping contour lines
>>> where original lines where not overlapping
>>>
>>> Gerd
>>>
&

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

2021-04-26 Thread Felix Hartmann

yes - for contourlines it would be great if the algo could check that lines
never cross - and if moving one direction vs the other means not touching
vs touching - then move the other direction. So it would need to loop at
for each line, at the next 2 lines. The big advantage would be for
contourlines only maps (which makes most sense IMHO, as you don't need to
update contourlines except if there is newer better data which is rare)
that you can create them with resolution 23 as highest resolution
instead of 24. Saving about 50% of the space. Old Garmin devices scroll
notably slower with resolution 24 contourlines vs 23, even more of course
if 10m equidistance instead of 20m equidistance is used.

As 0x20, 0x21 and 0x22 are always contourlines - those lines could easily
be distinguished (there is one second set of contour line types in newer
garmin maps, I don't know if that matters, and cant remember the types
right now). If this treatment is a lot slower - then it should have a
command option, so whoever integrates the contourlines has the choice of
chosing it. Because for separate contourlines even doubling or
tripling compilation times do not matter much.

On Mon, 26 Apr 2021 at 15:45, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi all,
>
> the major problem with resolution 23 and lower is the rounding to garmin
> units without looking at the distortions (WrongAngleFixer does that for res
> 24)
>
> At res 23 we have to draw the lines using a "bed of nails" where the nails
> have ~5m distance to each other. If the original line "meanders"
> horizontally close to the nails there is no big problem, nodes are probably
> rounded to a straight line. If the same line is moved by ~2.5 m up or down
> we often hit the worst case scenario where one node is rounded to the north
> and the next is rounded to the south. This produces visible zig-zagging.
> If two or more almost parallel lines meat this worst case you see the
> obvious errros where contour lines overlap.
>
> The logic in WrongAngleFixer tries to detect this and sometimes decides to
> round to a different place to reduce zig-zagging. The problem is that this
> has to be done looking at all lines, not just one, at least with normal OSM
> data where we have intersections.
>
> For contourlines it would be best if the generator would only calculate
> nodes which are exactly at the positions of the Garmin nails, but that is
> probaby not easy.
> The special case here is that it doesn't really matter where the nodes
> are, we just need "good looking" lines and that each node is only used by
> one contour way.
>
> Maybe it is possible to do this with a separate program or a special
> method in mkgmap which just treats contour lines
> - take generated contour data as input
> - rerender each way with resolution 23 nodes so that the line looks almost
> like before. This means it may add nodes somewhere and remove others.
> - maybe re-iterate if the rerendering caused overlapping contour lines
> where original lines where not overlapping
>
> Gerd
>
>
>
> ________
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Montag, 26. April 2021 08:55
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution
> 23 raster problems
>
> Thanks Andrzej for the patch.
> It produces better results in about 2/3 of cases, and worse in about 1/3
> of cases for resolution 23. So overall it's an improvement, and at least
> for compiling contourlines I didn't notice a significant difference in
> compile time. I could test this more in detail also against normal map data
> if needed...
> Using --simplifyContoursEpsilon= in phyghtmap helps a bit too, especially
> for resolution 24. However it runs super slow. It's like 1-30 times as much
> time, if not more (except for a value of 0.0 which is not changing the maps
> at all, and just making the .pbf file 10% smaller).
>
> This doesn't solve phyghtmap not using b-spline interpolation. That would
> improve even more (at least up to resolution 23, for resolution 22 maybe
> this patch matters more). In general if using 20m equidistance I feel in
> most cases it's good enough to compile contourlines only starting from
> resolution 23, much faster, less data just of course in very steep areas
> problematic. For 10m equidistance however it kinda means also going for
> resolution 24, else the improvement from 20m to 10m is more of a nuisance.
>
> On Mon, 26 Apr 2021 at 03:41, Andrzej Popowski  <mailto:po...@poczta.onet.pl>> wrote:
> Hi Gerd,
>
> I don't observe any significant differences in compilation. But to make
> it more optimized, we can put SizeFilter before DouglasPeuckerFil

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

2021-04-26 Thread Gerd Petermann

Hi all,

the major problem with resolution 23 and lower is the rounding to garmin units 
without looking at the distortions (WrongAngleFixer does that for res 24)

At res 23 we have to draw the lines using a "bed of nails" where the nails have 
~5m distance to each other. If the original line "meanders" horizontally close 
to the nails there is no big problem, nodes are probably rounded to a straight 
line. If the same line is moved by ~2.5 m up or down we often hit the worst 
case scenario where one node is rounded to the north and the next is rounded to 
the south. This produces visible zig-zagging.
If two or more almost parallel lines meat this worst case you see the obvious 
errros where contour lines overlap.

The logic in WrongAngleFixer tries to detect this and sometimes decides to 
round to a different place to reduce zig-zagging. The problem is that this has 
to be done looking at all lines, not just one, at least with normal OSM data 
where we have intersections.

For contourlines it would be best if the generator would only calculate nodes 
which are exactly at the positions of the Garmin nails, but that is probaby not 
easy.
The special case here is that it doesn't really matter where the nodes are, we 
just need "good looking" lines and that each node is only used by one contour 
way.

Maybe it is possible to do this with a separate program or a special method in 
mkgmap which just treats contour lines
- take generated contour data as input
- rerender each way with resolution 23 nodes so that the line looks almost like 
before. This means it may add nodes somewhere and remove others.
- maybe re-iterate if the rerendering caused overlapping contour lines where 
original lines where not overlapping

Gerd




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

Thanks Andrzej for the patch.
It produces better results in about 2/3 of cases, and worse in about 1/3 of 
cases for resolution 23. So overall it's an improvement, and at least for 
compiling contourlines I didn't notice a significant difference in compile 
time. I could test this more in detail also against normal map data if needed...
Using --simplifyContoursEpsilon= in phyghtmap helps a bit too, especially for 
resolution 24. However it runs super slow. It's like 1-30 times as much time, 
if not more (except for a value of 0.0 which is not changing the maps at all, 
and just making the .pbf file 10% smaller).

This doesn't solve phyghtmap not using b-spline interpolation. That would 
improve even more (at least up to resolution 23, for resolution 22 maybe this 
patch matters more). In general if using 20m equidistance I feel in most cases 
it's good enough to compile contourlines only starting from resolution 23, much 
faster, less data just of course in very steep areas problematic. For 10m 
equidistance however it kinda means also going for resolution 24, else the 
improvement from 20m to 10m is more of a nuisance.

On Mon, 26 Apr 2021 at 03:41, Andrzej Popowski 
mailto:po...@poczta.onet.pl>> wrote:
Hi Gerd,

I don't observe any significant differences in compilation. But to make
it more optimized, we can put SizeFilter before DouglasPeuckerFilter. I
have attached a second patch here.

There is a difference in results. See pictures with DouglasPeuckerFilter
after RoundCoordsFilter and new version with DouglasPeuckerFilter
before. This is for 22-bit resolution, so effects are probably more clear.

--
Best regards,
Andrzej

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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@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

2021-04-26 Thread Felix Hartmann

Thanks Andrzej for the patch.
It produces better results in about 2/3 of cases, and worse in about 1/3 of
cases for resolution 23. So overall it's an improvement, and at least for
compiling contourlines I didn't notice a significant difference in compile
time. I could test this more in detail also against normal map data if
needed...
Using *--simplifyContoursEpsilon*= in phyghtmap helps a bit too, especially
for resolution 24. However it runs super slow. It's like 1-30 times as much
time, if not more (except for a value of 0.0 which is not changing the maps
at all, and just making the .pbf file 10% smaller).

This doesn't solve phyghtmap not using b-spline interpolation. That would
improve even more (at least up to resolution 23, for resolution 22 maybe
this patch matters more). In general if using 20m equidistance I feel in
most cases it's good enough to compile contourlines only starting from
resolution 23, much faster, less data just of course in very steep areas
problematic. For 10m equidistance however it kinda means also going for
resolution 24, else the improvement from 20m to 10m is more of a nuisance.

On Mon, 26 Apr 2021 at 03:41, Andrzej Popowski  wrote:

> Hi Gerd,
>
> I don't observe any significant differences in compilation. But to make
> it more optimized, we can put SizeFilter before DouglasPeuckerFilter. I
> have attached a second patch here.
>
> There is a difference in results. See pictures with DouglasPeuckerFilter
> after RoundCoordsFilter and new version with DouglasPeuckerFilter
> before. This is for 22-bit resolution, so effects are probably more clear.
>
> --
> Best regards,
> Andrzej
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@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@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

2021-04-25 Thread Andrzej Popowski


Hi Gerd,

I don't observe any significant differences in compilation. But to make 
it more optimized, we can put SizeFilter before DouglasPeuckerFilter. I 
have attached a second patch here.


There is a difference in results. See pictures with DouglasPeuckerFilter 
after RoundCoordsFilter and new version with DouglasPeuckerFilter 
before. This is for 22-bit resolution, so effects are probably more clear.


--
Best regards,
Andrzej

Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- src/uk/me/parabola/mkgmap/build/MapBuilder.java (revision 4677)
+++ src/uk/me/parabola/mkgmap/build/MapBuilder.java (working copy)
@@ -1188,10 +1188,10 @@

LayerFilterChain filters = new LayerFilterChain(config);
if (enableLineCleanFilters && (res < 24)) {
-   filters.addFilter(new RoundCoordsFilter());
filters.addFilter(new SizeFilter(MIN_SIZE_LINE));
if(reducePointError > 0)
filters.addFilter(new 
DouglasPeuckerFilter(reducePointError));
+   filters.addFilter(new RoundCoordsFilter());
}
filters.addFilter(new LineSplitterFilter());
filters.addFilter(new RemoveEmpty());
@@ -1243,7 +1243,6 @@
LayerFilterChain filters = new LayerFilterChain(config);
filters.addFilter(new PolygonSplitterFilter());
if (enableLineCleanFilters && (res < 24)) {
-   filters.addFilter(new RoundCoordsFilter());
int sizefilterVal =  
getMinSizePolygonForResolution(res);
if (sizefilterVal > 0)
filters.addFilter(new 
SizeFilter(sizefilterVal));
@@ -1251,6 +1250,7 @@
//Is there an similar algorithm for polygons?
if(reducePointErrorPolygon > 0)
filters.addFilter(new 
DouglasPeuckerFilter(reducePointErrorPolygon));
+   filters.addFilter(new RoundCoordsFilter());
}
filters.addFilter(new RemoveObsoletePointsFilter());
filters.addFilter(new RemoveEmpty());
___
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

2021-04-25 Thread Gerd Petermann

Hi Andrzej,

at resolution 24 we only do simplification which doesn't have visual effects.
Your patch might help. I tried that once and found the improvement too small 
compared to the increased run time.

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Sonntag, 25. April 2021 17:47
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 153, Issue 40 Resolution 23 
raster problems

Hi,

maybe 10m contours are too dense for this area?

Please try attached patch. I have moved D-P simplification before
rounding of coordination. This should preserve shape of the line a bit
better. I'm not sure if this is a safe modification, but it seems to works.

I haven't found, where is done simplification of lines at resolution 24.
Angle fixer probably works on roads only or I don't understand this code
correctly.

--
Best regards,
Andrzej
___
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

2021-04-25 Thread Andrzej Popowski


Hi,

maybe 10m contours are too dense for this area?

Please try attached patch. I have moved D-P simplification before 
rounding of coordination. This should preserve shape of the line a bit 
better. I'm not sure if this is a safe modification, but it seems to works.


I haven't found, where is done simplification of lines at resolution 24. 
Angle fixer probably works on roads only or I don't understand this code 
correctly.


--
Best regards,
Andrzej
Index: MapBuilder.java
===
--- MapBuilder.java (revision 4677)
+++ MapBuilder.java (working copy)
@@ -1188,10 +1188,10 @@

LayerFilterChain filters = new LayerFilterChain(config);
if (enableLineCleanFilters && (res < 24)) {
+   if(reducePointError > 0)
+   filters.addFilter(new 
DouglasPeuckerFilter(reducePointError));
filters.addFilter(new RoundCoordsFilter());
filters.addFilter(new SizeFilter(MIN_SIZE_LINE));
-   if(reducePointError > 0)
-   filters.addFilter(new 
DouglasPeuckerFilter(reducePointError));
}
filters.addFilter(new LineSplitterFilter());
filters.addFilter(new RemoveEmpty());
@@ -1243,6 +1243,8 @@
LayerFilterChain filters = new LayerFilterChain(config);
filters.addFilter(new PolygonSplitterFilter());
if (enableLineCleanFilters && (res < 24)) {
+   if(reducePointErrorPolygon > 0)
+   filters.addFilter(new 
DouglasPeuckerFilter(reducePointErrorPolygon));
filters.addFilter(new RoundCoordsFilter());
int sizefilterVal =  
getMinSizePolygonForResolution(res);
if (sizefilterVal > 0)
@@ -1249,8 +1251,6 @@
filters.addFilter(new 
SizeFilter(sizefilterVal));
//DouglasPeucker behaves at the moment not really 
optimal at low zooms, but acceptable.
//Is there an similar algorithm for polygons?
-   if(reducePointErrorPolygon > 0)
-   filters.addFilter(new 
DouglasPeuckerFilter(reducePointErrorPolygon));
}
filters.addFilter(new RemoveObsoletePointsFilter());
filters.addFilter(new RemoveEmpty());
___
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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

35 matches

Site Navigation

Mail list logo

Footer information