logo separator

[mkgmap-dev] Commit 4710

From Gerd Petermann gpetermann_muenchen at hotmail.com on Thu May 13 10:12:27 BST 2021

Hi all,

I've tried to modify my version of Minkos OFM Lite style to use new tag mkgmap:has-direction=true. I should have done this earlier :(
Maybe Felix was right when he suggested to add a new option to specify a list of types which have a direction: http://gis.19327.n8.nabble.com/new-branch-low-res-opt-to-test-improvements-for-filters-tp5990982p5991155.html

It can be very difficult to change an existing style. Minkos OFM style adds the overlay lines (with direction) first and the road last. Another style might do this in another order.
Maybe I am overly cautious here.

Most important is:  We have to make sure that lines with a direction are not reversed because of merging (I think we already might reverse them to handle oneway=-1), else the map will show wrong information.

With the --housenumbers option we already sometimes have the problem that an overlay line is not renderend exactly like the underlying road because number nodes are added to the road and not to the overlay line. The effect is that the overlay line(s) are straight where the road bends a little bit.
I expect the same problem when mkgmap merges roads because they have no direction and the overlaying ways are not merged because they have different types (e.g. for left/right cycle lanes)

I guess I have to produce a test case first to demonstrate the problem...

Gerd

________________________________________
Von: Gerd Petermann <gpetermann_muenchen at hotmail.com>
Gesendet: Donnerstag, 13. Mai 2021 10:03
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] Commit 4710

Hi Felix,

FYI:
I just found out that the current code to detect if the style sets mkgmap:has-direction=true doesn't work. Seems I didn't test this :(
The change in r4710 changed only the LineMerger in the branch. Even with r4711 LineMerger only merges roads in maps without NET, at least that's what's intended.

My understanding is that r4703 changed routing, possibly also r4704. The merge from trunk also changed routing in the branches (r4706 and r4707).

I'm now fixing the detection code, next I'm trying to figure out how to configure the details reg. direction handling.

Gerd



________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver at gmail.com>
Gesendet: Donnerstag, 13. Mai 2021 09:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

I kinda feel by default even oneway=yes should only mean do not change direction for level 0. If someone uses a style to have arrows showing the oneway, then only for that arrow line (defined by tag) the direction cannot be reversed. Yes the problem of DP filter rests - I feel this does not matter for resolution 24 and even 23, but if you display arrows for resolution 22 or higher then a tag should not merge the underlying lines. Besides rivers (then also many styles do not have an arrow for rivers, or you could decide to show the arrows only at resolution 24 and 23) few lines will be objection dependent.

I will try out now if there is any change in routing - but I will only write again if there unexpectedly is. The sharp angles changed routing for the better for my maps by quite a lot. So maybe with now some less lines being merged, there actually will be a little change for the worse back to the old behavior. Not sure..

On Thu, 13 May 2021 at 14:07, Gerd Petermann <gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at hotmail.com>> wrote:
Hi Felix,

yes, size increases if your style sets mkgmap:has-direction=true. I just want to make sure that the direction flag is treated correctly first.
As already discussed we might introduce a new option or tag to tell mkgmap the min. level at which the direction has to be kept. You suggested to ignore direction at level > 0, I think it might depend on the style and TYP. I'll play with the OFM style to find out more.

The change should not affect routing at all (none of the changes in the low-res-opt branch should).

Gerd

________________________________________
Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <extremecarver at gmail.com<mailto:extremecarver at gmail.com>>
Gesendet: Donnerstag, 13. Mai 2021 02:59
An: Development list for mkgmap
Betreff: [mkgmap-dev] Commit 4710

fix error in LineMergeFilter reg. lines with direction
The line merger should not merge lines if one has the direction flag set and the other has not. Problem exists also in trunk.


Hmm fixing this stopped all the nice size optimization. Map size got much bigger again.
I did not find any place where this mattered. Routing was also not affected badly. Maybe I did not look good enough?

I do not see why not to merge them. As long as it`s not the opposite it seems fine...
Map size increase/decrease is around 1.5% with my style. So thats quite a big difference.
--
Felix Hartman - Openmtbmap.org & VeloMap.org

_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Openmtbmap.org & VeloMap.org



More information about the mkgmap-dev mailing list