subject:"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_muenc...@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  im Auftrag von
> Felix Hartmann 
> 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@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] 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  im Auftrag von Felix 
Hartmann 
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 
mailto:gpetermann_muenc...@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 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@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@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] Commit 4710


Hi all,

I didn't know about mkgmap:has-direction. Good to see there is 
possibility to protect direction of the line. Please note, there are 
lines, which aren't roads but really have directions. Some example:

- waterway=river, stream, maybe canal, ditch too,
- natural=cliff,
- man_made=embankment,
- sidewalk=left, right.

Are there any situation, where mkgmap adds this tag by itself?

--
Best regards,
Andrzej

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

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

Re: [mkgmap-dev] Commit 4710

Well I just got to test routing - and the current version is a degradation
vs the intermediate version from yesterday for my maps. The current version
routes better than before, but worse than the intermediate version.

As for the list - it is a bit more complicated inside the style but doable.
I really do not know what happens to those ways where I first set a
direction for an downhill only way with higher priority, then remove the
direction for a way that can be used in both directions at lower priority.
Maybe sometimes also doing this the other way around. A list with type and
max resolution used would be much easier for writing your style. Instead of
adding 60-100 lines with the filter it would be done with 10 or so.  Canals
should not have a direction, they do not flow. Sidewalk=left, right is the
same as for the various cylceway,cycletrack options - those are really not
reversible. The underlying way could be reversed however - and I guess they
are only used for level 0.
Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only.
Cliffs are also only high resolution. For me rivers are the only thing
which really go into lower resolutions.

On Thu, 13 May 2021 at 16:03, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

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

Re: [mkgmap-dev] Commit 4710

Hi Andrzej,

the tag was introduced with r4703:
https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4703

Some of the code didn't work until r4713:
https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4713

Are there any situation, where mkgmap adds this tag by itself?
I might be added to roads, but because of an error: Only if you use r4713

This is still experimental. I have committed the code in r4703 to allow testing 
and get usability reports.

I'll probably add an alternative option to manage this direction flag based on 
type and resolution, the current handling seems too complex.

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Donnerstag, 13. Mai 2021 11:10
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Commit 4710

Hi all,

I didn't know about mkgmap:has-direction. Good to see there is
possibility to protect direction of the line. Please note, there are
lines, which aren't roads but really have directions. Some example:
- waterway=river, stream, maybe canal, ditch too,
- natural=cliff,
- man_made=embankment,
- sidewalk=left, right.

Are there any situation, where mkgmap adds this tag by itself?

--
Best regards,
Andrzej

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

Re: [mkgmap-dev] Commit 4710

Hi Felix,

please tell me exactly which versions you tested reg. routing.
Note that the branches do not yet contain the latest changes in trunk.

Gerd

Von: mkgmap-dev im Auftrag von Felix
Hartmann
Gesendet: Donnerstag, 13. Mai 2021 11:28
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Well I just got to test routing - and the current version is a degradation vs
the intermediate version from yesterday for my maps. The current version routes
better than before, but worse than the intermediate version.

As for the list - it is a bit more complicated inside the style but doable. I
really do not know what happens to those ways where I first set a direction for
an downhill only way with higher priority, then remove the direction for a way
that can be used in both directions at lower priority. Maybe sometimes also
doing this the other way around. A list with type and max resolution used would
be much easier for writing your style. Instead of adding 60-100 lines with the
filter it would be done with 10 or so. Canals should not have a direction,
they do not flow. Sidewalk=left, right is the same as for the various
cylceway,cycletrack options - those are really not reversible. The underlying
way could be reversed however - and I guess they are only used for level 0.
Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only.
Cliffs are also only high resolution. For me rivers are the only thing which
really go into lower resolutions.

On Thu, 13 May 2021 at 16:03, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

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
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
im Auftrag von Felix Hartmann
mailto:extremecar...@gmail.com>>
Gesendet: Donnerstag, 13. Mai 2021 09:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

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

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

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, 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.

Re: [mkgmap-dev] Commit 4710

I tried 4713 current on branch Vs before the updates 12.05 on branch

On Thu, 13 May 2021, 17:42 Gerd Petermann 
wrote:

> Hi Felix,
>
> please tell me exactly which versions you tested reg. routing.
> Note that the branches do not yet contain the latest changes in trunk.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 13. Mai 2021 11:28
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Well I just got to test routing - and the current version is a degradation
> vs the intermediate version from yesterday for my maps. The current version
> routes better than before, but worse than the intermediate version.
>
> As for the list - it is a bit more complicated inside the style but
> doable. I really do not know what happens to those ways where I first set a
> direction for an downhill only way with higher priority, then remove the
> direction for a way that can be used in both directions at lower priority.
> Maybe sometimes also doing this the other way around. A list with type and
> max resolution used would be much easier for writing your style. Instead of
> adding 60-100 lines with the filter it would be done with 10 or so.  Canals
> should not have a direction, they do not flow. Sidewalk=left, right is the
> same as for the various cylceway,cycletrack options - those are really not
> reversible. The underlying way could be reversed however - and I guess they
> are only used for level 0.
> Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only.
> Cliffs are also only high resolution. For me rivers are the only thing
> which really go into lower resolutions.
>
> On Thu, 13 May 2021 at 16:03, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> 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-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@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_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@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-boun...@lists.mkgmap.org.uk> mk

Re: [mkgmap-dev] Commit 4710

I just looked it up. It must have been 4709 with best routing for me
(unlikely but maybe it could have been 4708), while 4711 is a bit worse
(but better than before the first changes that made an impact on routing).
Both from low-res-opt branch.
I haven't tried trunk for quite a while.

On Thu, 13 May 2021 at 17:42, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> please tell me exactly which versions you tested reg. routing.
> Note that the branches do not yet contain the latest changes in trunk.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 13. Mai 2021 11:28
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Well I just got to test routing - and the current version is a degradation
> vs the intermediate version from yesterday for my maps. The current version
> routes better than before, but worse than the intermediate version.
>
> As for the list - it is a bit more complicated inside the style but
> doable. I really do not know what happens to those ways where I first set a
> direction for an downhill only way with higher priority, then remove the
> direction for a way that can be used in both directions at lower priority.
> Maybe sometimes also doing this the other way around. A list with type and
> max resolution used would be much easier for writing your style. Instead of
> adding 60-100 lines with the filter it would be done with 10 or so.  Canals
> should not have a direction, they do not flow. Sidewalk=left, right is the
> same as for the various cylceway,cycletrack options - those are really not
> reversible. The underlying way could be reversed however - and I guess they
> are only used for level 0.
> Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only.
> Cliffs are also only high resolution. For me rivers are the only thing
> which really go into lower resolutions.
>
> On Thu, 13 May 2021 at 16:03, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> 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-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@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_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@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 s

Re: [mkgmap-dev] Commit 4710

Hi Felix,

you totally lost me. There is no version r4713 in the branch.
It seems you report the version number that svn shows after an svn update?
That's not relevant, you must use svn info to find out the version of your
branch.
svn update always shows the latest commit, no matter in what branch it was made.

Gerd

Von: mkgmap-dev im Auftrag von Felix
Hartmann
Gesendet: Donnerstag, 13. Mai 2021 13:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

I just looked it up. It must have been 4709 with best routing for me (unlikely
but maybe it could have been 4708), while 4711 is a bit worse (but better than
before the first changes that made an impact on routing). Both from low-res-opt
branch.
I haven't tried trunk for quite a while.

On Thu, 13 May 2021 at 17:42, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

please tell me exactly which versions you tested reg. routing.
Note that the branches do not yet contain the latest changes in trunk.

Gerd

Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
im Auftrag von Felix Hartmann
mailto:extremecar...@gmail.com>>
Gesendet: Donnerstag, 13. Mai 2021 11:28
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

On Thu, 13 May 2021 at 16:03, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
wrote:
Hi Felix,

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
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, 13. Mai 2021 09:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

On Thu, 13 May 2021 at 14:07, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.co

Re: [mkgmap-dev] Commit 4710

Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.

On Thu, 13 May 2021, 19:37 Gerd Petermann 
wrote:

> Hi Felix,
>
> you totally lost me. There is no version r4713 in the branch.
> It seems you report the version number that svn shows after an svn update?
> That's not relevant, you must use svn info to find out the version of your
> branch.
> svn update always shows the latest commit, no matter in what branch it was
> made.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 13. Mai 2021 13:16
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> I just looked it up. It must have been 4709 with best routing for me
> (unlikely but maybe it could have been 4708), while 4711 is a bit worse
> (but better than before the first changes that made an impact on routing).
> Both from low-res-opt branch.
> I haven't tried trunk for quite a while.
>
> On Thu, 13 May 2021 at 17:42, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> please tell me exactly which versions you tested reg. routing.
> Note that the branches do not yet contain the latest changes in trunk.
>
> 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, 13. Mai 2021 11:28
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Well I just got to test routing - and the current version is a degradation
> vs the intermediate version from yesterday for my maps. The current version
> routes better than before, but worse than the intermediate version.
>
> As for the list - it is a bit more complicated inside the style but
> doable. I really do not know what happens to those ways where I first set a
> direction for an downhill only way with higher priority, then remove the
> direction for a way that can be used in both directions at lower priority.
> Maybe sometimes also doing this the other way around. A list with type and
> max resolution used would be much easier for writing your style. Instead of
> adding 60-100 lines with the filter it would be done with 10 or so.  Canals
> should not have a direction, they do not flow. Sidewalk=left, right is the
> same as for the various cylceway,cycletrack options - those are really not
> reversible. The underlying way could be reversed however - and I guess they
> are only used for level 0.
> Oneway arrows for streets are maybe used from resoltuion 24-22 or 24 only.
> Cliffs are also only high resolution. For me rivers are the only thing
> which really go into lower resolutions.
>
> On Thu, 13 May 2021 at 16:03, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote:
> 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-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: 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 f

Re: [mkgmap-dev] Commit 4710

Hi Felix,

are you sure that you tested the two versions with exactly the same input? (osm
data, style, options)?
If the changes in r4710 or r4711 really cause differences in routing quality
there must be an error, either in my understanding or in the code.
Maybe you can post links to two tiles where routing differs?

Gerd

Von: mkgmap-dev im Auftrag von Felix
Hartmann
Gesendet: Donnerstag, 13. Mai 2021 14:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.

On Thu, 13 May 2021, 19:37 Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

Gerd

Von: mkgmap-dev
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
im Auftrag von Felix Hartmann
mailto:extremecar...@gmail.com>>
Gesendet: Donnerstag, 13. Mai 2021 13:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

On Thu, 13 May 2021 at 17:42, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
wrote:
Hi Felix,

please tell me exactly which versions you tested reg. routing.
Note that the branches do not yet contain the latest changes in 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: Donnerstag, 13. Mai 2021 11:28
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

On Thu, 13 May 2021 at 16:03, 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,

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
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.o

Re: [mkgmap-dev] Commit 4710

Hi all,

I fear I've totally forgotten the case of extended line types. I think the
current code doesn't write the direction flag for them and I don't know if they
can have a direction.

Gerd

Von: Gerd Petermann
Gesendet: Donnerstag, 13. Mai 2021 14:33
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] Commit 4710

Hi Felix,

Gerd

Von: mkgmap-dev im Auftrag von Felix
Hartmann
Gesendet: Donnerstag, 13. Mai 2021 14:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.

On Thu, 13 May 2021, 19:37 Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

Gerd

On Thu, 13 May 2021 at 17:42, Gerd Petermann
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
wrote:
Hi Felix,

please tell me exactly which versions you tested reg. routing.
Note that the branches do not yet contain the latest changes in 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: Donnerstag, 13. Mai 2021 11:28
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

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

Re: [mkgmap-dev] Commit 4710


Hi Gerd,

I don't know particulars about direction flag, that is written into img. 
Maybe it gives some kind of protection against drawing a line in revers 
direction? Would be nice to test, if it were possible.


Anyway, for me problem is about reversing a line by mkgmap. I think that 
attribute, which prevents mkgmap from doing it, is necessary to control 
line merging.


--
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] Commit 4710

Hi Andrzej,

not sure what you mean. There are three ways to tell mkgmap that a line has a 
direction:
1) oneway=yes / oneway=-1
2) in polish (*.mp) format there is DirIndicator
3) mkgmap:has-direction=true (since r4703)

The flag is only written for lines with normal type, but maybe extended types 
also have a bit for that. Even the bit (0x40) might be the same.
A special case occurs with the overview map. The OverviewBuilder ignored the 
flag, I fixed that only in the low-res-opt branch, see 
https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4697

I don't know how or if Garmin software uses the flag with non-routable lines, 
GpsMapEdit shows an arrow.

For a long time mkgmap reverses lines with oneway=-1 (after style processing), 
because Garmin only has yes/no flag.

Does that help?

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Donnerstag, 13. Mai 2021 17:03
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Commit 4710

Hi Gerd,

I don't know particulars about direction flag, that is written into img.
Maybe it gives some kind of protection against drawing a line in revers
direction? Would be nice to test, if it were possible.

Anyway, for me problem is about reversing a line by mkgmap. I think that
attribute, which prevents mkgmap from doing it, is necessary to control
line merging.

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit 4710


Hi Gerd,

it is clear, but I was thinking about something else, about merging 
lines with reversed points. If mkgmap performs that kind of merging, 
there should be an option to block reversing for a particular object 
type. I got impression, that mkgmap:has-direction is a flag, that can be 
used.


--
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] Commit 4710

Hi Andrzej,

yes, sure, the tag mkgmap:has-direction=true was only implemented for that.

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Donnerstag, 13. Mai 2021 19:36
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Commit 4710

Hi Gerd,

it is clear, but I was thinking about something else, about merging
lines with reversed points. If mkgmap performs that kind of merging,
there should be an option to block reversing for a particular object
type. I got impression, that mkgmap:has-direction is a flag, that can be
used.

--
Best regards,
Andrzej
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit 4710


Hi Gerd,

here example of lines, that shouldn't be merged:
https://www.openstreetmap.org/way/481106241
https://www.openstreetmap.org/way/481106244
https://www.openstreetmap.org/way/481106242

I have tested with mkgmap-low-res-opt-r4711 and it works correctly. 
Lines are not merged with mkgmap:has-direction=true and merged without.


--
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] Commit 4710

2021-05-13 Thread Ticker Berkin

Hi

Various thoughts:

The 0x40 polyLine direction flag probably has no effect on modern
Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it
is set. In my notes from testing all line types, I found some cases
where an eTrex put compass bearings (N/NE/E/...) on some line types
where the top byte was 0x5 (ie this flag was set), so modifying the
meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f
but with the compass label.

I'll have a go at reproducing this - it was a while ago, I had to hack
some mkgmap code, and I can't remember which device it was.

Using the existing direction flag logic is overloading it; there is no
reason why another flag couldn't be introduced to inhibits line
reversal in attempts to merge. However, as the flag is already there,
seems to have correct meaning, doesn't have any known harmful effects
and might, possibly, be accessible to the TYP representation, then
there are many advantages in using it.

I notice an old posting by Andrzej saying one-way arrows are displayed
on some devices by default when no TYP graphics. @Andrzej - do you have
more details about this?

An option should allow the default setting of this flag per line Type.
It would be expected to be set for the types used for rivers, streams,
embankments, coastline The style/TYP author is responsible for
this. It could be one of the options allowed in style/options.

The oneway tag sets it, and it can also be set/cleared with mkgmap:has
-direction=yes/no. Should mkgmap:has-direction=no clear the flag if set
by one-way? Yes, as long as reversal is also inhibited by oneway.

I don't think there is any need for the style system to look for usages
of this tag and change behaviour.

Ticker

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

Re: [mkgmap-dev] Commit 4710

Hi Ticker and all,

reg. tests of the 0x40 flag:
Attached small patch would be my guess for the lines with extended type.

The oneway attribute is stored in NOD and in the direction flag, I think that 
makes sense. The oneway=yes tag used to set the direction flag since more than 
10 years (r738).

I do agree now that an option in the style to list types with direction is the 
better approach, the tag handling is much more complex. The size effects of 
r4710 reported by Felix show
that his style did not set the tag consistently for the same type and I think 
this can be really tricky.
So, I think I'll remove the code for mkgmap:has-direction=true and add a new 
option to list the types which should be treated as having a direction, e.g. 
--line-types-with-direction=0x18,0x1f, 0x10005, 0x10006 . The 
oneway=yes/oneway=-1 tag will continue to set the direction flag.
The default style might need some changes to distinguish waterways with 
direction from others, e.g. I think canals and rivers should have different 
types.

I'll change the option  --x-force-reverse-merge to --allow-reverse-merge with 
the default --allow-reverse-merge=no. These two options will effect RoadMerger 
and LineMerger.

I've not yet made up my mind regarding the reversing of lines (and roads) in 
LineMerger for the overview map. Felix says there is no need to care about 
direction in the overvew map.

I'll remove the code which tries to propagate the direction flag to underlying 
roads for now. Let's see first how often this is really needed.

Gerd




Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Donnerstag, 13. Mai 2021 23:36
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Hi

Various thoughts:

The 0x40 polyLine direction flag probably has no effect on modern
Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it
is set. In my notes from testing all line types, I found some cases
where an eTrex put compass bearings (N/NE/E/...) on some line types
where the top byte was 0x5 (ie this flag was set), so modifying the
meaning line types 0x10 to 0x1f. I think they looked like 0x01 to 0x0f
but with the compass label.

I'll have a go at reproducing this - it was a while ago, I had to hack
some mkgmap code, and I can't remember which device it was.

Using the existing direction flag logic is overloading it; there is no
reason why another flag couldn't be introduced to inhibits line
reversal in attempts to merge. However, as the flag is already there,
seems to have correct meaning, doesn't have any known harmful effects
and might, possibly, be accessible to the TYP representation, then
there are many advantages in using it.

I notice an old posting by Andrzej saying one-way arrows are displayed
on some devices by default when no TYP graphics. @Andrzej - do you have
more details about this?

An option should allow the default setting of this flag per line Type.
It would be expected to be set for the types used for rivers, streams,
embankments, coastline The style/TYP author is responsible for
this. It could be one of the options allowed in style/options.

The oneway tag sets it, and it can also be set/cleared with mkgmap:has
-direction=yes/no. Should mkgmap:has-direction=no clear the flag if set
by one-way? Yes, as long as reversal is also inhibited by oneway.

I don't think there is any need for the style system to look for usages
of this tag and change behaviour.

Ticker

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


dir-for-extended.patch
Description: dir-for-extended.patch
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit 4710

2021-05-14 Thread Ticker Berkin

Hi Gerd and others

I'll test setting of 0x40 flag for extended and the range of standard
types on various devices over the weekend.

Is there any real need for the force/allow-reverse-merge options?

When you say "remove the code for mkgmap:has-direction", I assume you
mean just the style-scan of tags used, rather than inspecting it on a
way after style conversion.

Styles don't have to use different tags for river/canal once this is
all implemented, can choose
1/ don't set the default direction for waterway type, or use mkgmap:has
-direction in style and get current behaviour.
2/ default it to direction, clear it with mkgmap:direction=no when used
as canal. This approach could be used if the device shows direction
markers on rivers that we want to see.
3/ use distinct types and appropriate representation.

I think it should be carried through into the overview img.

For the dual-carriageway lane merging, I presume it should turn off
direction (and one-way).

Ticker

On Fri, 2021-05-14 at 05:11 +, Gerd Petermann wrote:
> Hi Ticker and all,
> 
> reg. tests of the 0x40 flag:
> Attached small patch would be my guess for the lines with extended
> type.
> 
> The oneway attribute is stored in NOD and in the direction flag, I
> think that makes sense. The oneway=yes tag used to set the direction
> flag since more than 10 years (r738).
> 
> I do agree now that an option in the style to list types with
> direction is the better approach, the tag handling is much more
> complex. The size effects of r4710 reported by Felix show
> that his style did not set the tag consistently for the same type and
> I think this can be really tricky.
> So, I think I'll remove the code for mkgmap:has-direction=true and
> add a new option to list the types which should be treated as having
> a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005,
> 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the
> direction flag.
> The default style might need some changes to distinguish waterways
> with direction from others, e.g. I think canals and rivers should
> have different types.
> 
> I'll change the option  --x-force-reverse-merge to --allow-reverse
> -merge with the default --allow-reverse-merge=no. These two options
> will effect RoadMerger and LineMerger.
> 
> I've not yet made up my mind regarding the reversing of lines (and
> roads) in LineMerger for the overview map. Felix says there is no
> need to care about direction in the overvew map.
> 
> I'll remove the code which tries to propagate the direction flag to
> underlying roads for now. Let's see first how often this is really
> needed.
> 
> Gerd
> 
> 
> 
> ____________________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 13. Mai 2021 23:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
> 
> Hi
> 
> Various thoughts:
> 
> The 0x40 polyLine direction flag probably has no effect on modern
> Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it
> is set. In my notes from testing all line types, I found some cases
> where an eTrex put compass bearings (N/NE/E/...) on some line types
> where the top byte was 0x5 (ie this flag was set), so modifying the
> meaning line types 0x10 to 0x1f. I think they looked like 0x01 to
> 0x0f
> but with the compass label.
> 
> I'll have a go at reproducing this - it was a while ago, I had to
> hack
> some mkgmap code, and I can't remember which device it was.
> 
> Using the existing direction flag logic is overloading it; there is
> no
> reason why another flag couldn't be introduced to inhibits line
> reversal in attempts to merge. However, as the flag is already there,
> seems to have correct meaning, doesn't have any known harmful effects
> and might, possibly, be accessible to the TYP representation, then
> there are many advantages in using it.
> 
> I notice an old posting by Andrzej saying one-way arrows are
> displayed
> on some devices by default when no TYP graphics. @Andrzej - do you
> have
> more details about this?
> 
> An option should allow the default setting of this flag per line
> Type.
> It would be expected to be set for the types used for rivers,
> streams,
> embankments, coastline The style/TYP author is responsible for
> this. It could be one of the options allowed in style/options.
> 
> The oneway tag sets it, and it can also be set/cleared with
> mkgmap:has
> -direction=yes/no. Should mkgmap:has-direction=no clear the flag if
> set
> by one-way? Yes, as long as reversal is also inhibited by oneway.
> 
> I don't think there is any need for the style system to

Re: [mkgmap-dev] Commit 4710

Hi Ticker,

I meant I want to remove the evaluation of the special tag 
mkgmap:has-direction=true and only rely on the new option 
--line-types-with-direction

Do you see a need to have both?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Freitag, 14. Mai 2021 09:22
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Hi Gerd and others

I'll test setting of 0x40 flag for extended and the range of standard
types on various devices over the weekend.

Is there any real need for the force/allow-reverse-merge options?

When you say "remove the code for mkgmap:has-direction", I assume you
mean just the style-scan of tags used, rather than inspecting it on a
way after style conversion.

Styles don't have to use different tags for river/canal once this is
all implemented, can choose
1/ don't set the default direction for waterway type, or use mkgmap:has
-direction in style and get current behaviour.
2/ default it to direction, clear it with mkgmap:direction=no when used
as canal. This approach could be used if the device shows direction
markers on rivers that we want to see.
3/ use distinct types and appropriate representation.

I think it should be carried through into the overview img.

For the dual-carriageway lane merging, I presume it should turn off
direction (and one-way).

Ticker

On Fri, 2021-05-14 at 05:11 +, Gerd Petermann wrote:
> Hi Ticker and all,
>
> reg. tests of the 0x40 flag:
> Attached small patch would be my guess for the lines with extended
> type.
>
> The oneway attribute is stored in NOD and in the direction flag, I
> think that makes sense. The oneway=yes tag used to set the direction
> flag since more than 10 years (r738).
>
> I do agree now that an option in the style to list types with
> direction is the better approach, the tag handling is much more
> complex. The size effects of r4710 reported by Felix show
> that his style did not set the tag consistently for the same type and
> I think this can be really tricky.
> So, I think I'll remove the code for mkgmap:has-direction=true and
> add a new option to list the types which should be treated as having
> a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005,
> 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the
> direction flag.
> The default style might need some changes to distinguish waterways
> with direction from others, e.g. I think canals and rivers should
> have different types.
>
> I'll change the option  --x-force-reverse-merge to --allow-reverse
> -merge with the default --allow-reverse-merge=no. These two options
> will effect RoadMerger and LineMerger.
>
> I've not yet made up my mind regarding the reversing of lines (and
> roads) in LineMerger for the overview map. Felix says there is no
> need to care about direction in the overvew map.
>
> I'll remove the code which tries to propagate the direction flag to
> underlying roads for now. Let's see first how often this is really
> needed.
>
> Gerd
>
>
>
> ____________________
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Donnerstag, 13. Mai 2021 23:36
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Hi
>
> Various thoughts:
>
> The 0x40 polyLine direction flag probably has no effect on modern
> Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it
> is set. In my notes from testing all line types, I found some cases
> where an eTrex put compass bearings (N/NE/E/...) on some line types
> where the top byte was 0x5 (ie this flag was set), so modifying the
> meaning line types 0x10 to 0x1f. I think they looked like 0x01 to
> 0x0f
> but with the compass label.
>
> I'll have a go at reproducing this - it was a while ago, I had to
> hack
> some mkgmap code, and I can't remember which device it was.
>
> Using the existing direction flag logic is overloading it; there is
> no
> reason why another flag couldn't be introduced to inhibits line
> reversal in attempts to merge. However, as the flag is already there,
> seems to have correct meaning, doesn't have any known harmful effects
> and might, possibly, be accessible to the TYP representation, then
> there are many advantages in using it.
>
> I notice an old posting by Andrzej saying one-way arrows are
> displayed
> on some devices by default when no TYP graphics. @Andrzej - do you
> have
> more details about this?
>
> An option should allow the default setting of this flag per line
> Type.
> It would be expected to be set for the types used for rivers,
> streams,
> embankments, coastline The style/TYP author is responsible for
&g

Re: [mkgmap-dev] Commit 4710

I think it is enough with a simple list. As for why it changed for me is
Imho because those lines are mostly created with continue or continue with
action and it's really hard to see what happens concerning the other lines
related to it. I definitely did not miss any lines in my lines file that
should not be reversed.

So make it a list, and option for each type
other kines created with continue can change direction no, yes, from
resolution XX or lower.

That would be best. Gives it all options and you can set it how it works
best. I still feel I will always use other lines can be reversed to be
merged.

On Fri, 14 May 2021, 15:32 Gerd Petermann 
wrote:

> Hi Ticker,
>
> I meant I want to remove the evaluation of the special tag
> mkgmap:has-direction=true and only rely on the new option
> --line-types-with-direction
>
> Do you see a need to have both?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Ticker Berkin 
> Gesendet: Freitag, 14. Mai 2021 09:22
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Hi Gerd and others
>
> I'll test setting of 0x40 flag for extended and the range of standard
> types on various devices over the weekend.
>
> Is there any real need for the force/allow-reverse-merge options?
>
> When you say "remove the code for mkgmap:has-direction", I assume you
> mean just the style-scan of tags used, rather than inspecting it on a
> way after style conversion.
>
> Styles don't have to use different tags for river/canal once this is
> all implemented, can choose
> 1/ don't set the default direction for waterway type, or use mkgmap:has
> -direction in style and get current behaviour.
> 2/ default it to direction, clear it with mkgmap:direction=no when used
> as canal. This approach could be used if the device shows direction
> markers on rivers that we want to see.
> 3/ use distinct types and appropriate representation.
>
> I think it should be carried through into the overview img.
>
> For the dual-carriageway lane merging, I presume it should turn off
> direction (and one-way).
>
> Ticker
>
> On Fri, 2021-05-14 at 05:11 +, Gerd Petermann wrote:
> > Hi Ticker and all,
> >
> > reg. tests of the 0x40 flag:
> > Attached small patch would be my guess for the lines with extended
> > type.
> >
> > The oneway attribute is stored in NOD and in the direction flag, I
> > think that makes sense. The oneway=yes tag used to set the direction
> > flag since more than 10 years (r738).
> >
> > I do agree now that an option in the style to list types with
> > direction is the better approach, the tag handling is much more
> > complex. The size effects of r4710 reported by Felix show
> > that his style did not set the tag consistently for the same type and
> > I think this can be really tricky.
> > So, I think I'll remove the code for mkgmap:has-direction=true and
> > add a new option to list the types which should be treated as having
> > a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005,
> > 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the
> > direction flag.
> > The default style might need some changes to distinguish waterways
> > with direction from others, e.g. I think canals and rivers should
> > have different types.
> >
> > I'll change the option  --x-force-reverse-merge to --allow-reverse
> > -merge with the default --allow-reverse-merge=no. These two options
> > will effect RoadMerger and LineMerger.
> >
> > I've not yet made up my mind regarding the reversing of lines (and
> > roads) in LineMerger for the overview map. Felix says there is no
> > need to care about direction in the overvew map.
> >
> > I'll remove the code which tries to propagate the direction flag to
> > underlying roads for now. Let's see first how often this is really
> > needed.
> >
> > Gerd
> >
> >
> >
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Donnerstag, 13. Mai 2021 23:36
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Commit 4710
> >
> > Hi
> >
> > Various thoughts:
> >
> > The 0x40 polyLine direction flag probably has no effect on modern
> > Garmin devices. As Gerd says, GPSMapEdit puts an arrow on lines if it
> > is set. In my notes from testing all line types, I found some cases
> > where an eTrex put compass bearings (N/NE/E/...) on some line types
> > where the top byte was 0x5 (ie this flag was set),

Re: [mkgmap-dev] Commit 4710

Hi Felix,

please explain in more detail. Why would you add a line with a type that has a 
direction to be rendered at low resolution when you don't care about the 
direction at lower resolutions?

You say simple list is enough, but then "give all options".  Quite confusing ;)
I don't want to support different ways to specify a single bit unless there is 
a very good reason. If there is a good reason we need to define and document 
priorities and handle them properly.

Gerd

Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Freitag, 14. Mai 2021 09:42
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

I think it is enough with a simple list. As for why it changed for me is Imho 
because those lines are mostly created with continue or continue with action 
and it's really hard to see what happens concerning the other lines related to 
it. I definitely did not miss any lines in my lines file that should not be 
reversed.

So make it a list, and option for each type
other kines created with continue can change direction no, yes, from resolution 
XX or lower.

That would be best. Gives it all options and you can set it how it works best. 
I still feel I will always use other lines can be reversed to be merged.

On Fri, 14 May 2021, 15:32 Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Ticker,

I meant I want to remove the evaluation of the special tag 
mkgmap:has-direction=true and only rely on the new option 
--line-types-with-direction

Do you see a need to have both?

Gerd

Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Ticker Berkin 
mailto:rwb-mkg...@jagit.co.uk>>
Gesendet: Freitag, 14. Mai 2021 09:22
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Hi Gerd and others

I'll test setting of 0x40 flag for extended and the range of standard
types on various devices over the weekend.

Is there any real need for the force/allow-reverse-merge options?

When you say "remove the code for mkgmap:has-direction", I assume you
mean just the style-scan of tags used, rather than inspecting it on a
way after style conversion.

Styles don't have to use different tags for river/canal once this is
all implemented, can choose
1/ don't set the default direction for waterway type, or use mkgmap:has
-direction in style and get current behaviour.
2/ default it to direction, clear it with mkgmap:direction=no when used
as canal. This approach could be used if the device shows direction
markers on rivers that we want to see.
3/ use distinct types and appropriate representation.

I think it should be carried through into the overview img.

For the dual-carriageway lane merging, I presume it should turn off
direction (and one-way).

Ticker

On Fri, 2021-05-14 at 05:11 +, Gerd Petermann wrote:
> Hi Ticker and all,
>
> reg. tests of the 0x40 flag:
> Attached small patch would be my guess for the lines with extended
> type.
>
> The oneway attribute is stored in NOD and in the direction flag, I
> think that makes sense. The oneway=yes tag used to set the direction
> flag since more than 10 years (r738).
>
> I do agree now that an option in the style to list types with
> direction is the better approach, the tag handling is much more
> complex. The size effects of r4710 reported by Felix show
> that his style did not set the tag consistently for the same type and
> I think this can be really tricky.
> So, I think I'll remove the code for mkgmap:has-direction=true and
> add a new option to list the types which should be treated as having
> a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005,
> 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the
> direction flag.
> The default style might need some changes to distinguish waterways
> with direction from others, e.g. I think canals and rivers should
> have different types.
>
> I'll change the option  --x-force-reverse-merge to --allow-reverse
> -merge with the default --allow-reverse-merge=no. These two options
> will effect RoadMerger and LineMerger.
>
> I've not yet made up my mind regarding the reversing of lines (and
> roads) in LineMerger for the overview map. Felix says there is no
> need to care about direction in the overvew map.
>
> I'll remove the code which tries to propagate the direction flag to
> underlying roads for now. Let's see first how often this is really
> needed.
>
> Gerd
>
>
>
> 
> Von: mkgmap-dev 
> mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
>  im Auftrag
> von Ticker Berkin mailto:rwb-mkg...@jagit.co.uk>>
> Gesendet: Donnerstag, 13. Mai 2021 23:36
> An: Development li

Re: [mkgmap-dev] Commit 4710

2021-05-14 Thread Ticker Berkin

Hi

I think better/more flexible to have both. Mainly for when there are a
limited number of well defined garmin types for an element and some
have direction and some don't, eg the various waterways, direction
-merged motorways...

However, if there is no way of distinguishing the difference in the
final visible representation on any device then there isn't need.

Ticker
 
On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
> I think it is enough with a simple list. As for why it changed for me
> is Imho because those lines are mostly created with continue or
> continue with action and it's really hard to see what happens
> concerning the other lines related to it. I definitely did not miss
> any lines in my lines file that should not be reversed.
> 
> So make it a list, and option for each type 
> other kines created with continue can change direction no, yes, from
> resolution XX or lower.
> 
> That would be best. Gives it all options and you can set it how it
> works best. I still feel I will always use other lines can be
> reversed to be merged.
> 
> On Fri, 14 May 2021, 15:32 Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
> > Hi Ticker,
> > 
> > I meant I want to remove the evaluation of the special tag
> > mkgmap:has-direction=true and only rely on the new option --line
> > -types-with-direction
> > 
> > Do you see a need to have both?
> > 
> > Gerd
> > 
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Ticker Berkin 
> > Gesendet: Freitag, 14. Mai 2021 09:22
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Commit 4710
> > 
> > Hi Gerd and others
> > 
> > I'll test setting of 0x40 flag for extended and the range of
> > standard
> > types on various devices over the weekend.
> > 
> > Is there any real need for the force/allow-reverse-merge options?
> > 
> > When you say "remove the code for mkgmap:has-direction", I assume
> > you
> > mean just the style-scan of tags used, rather than inspecting it on
> > a
> > way after style conversion.
> > 
> > Styles don't have to use different tags for river/canal once this
> > is
> > all implemented, can choose
> > 1/ don't set the default direction for waterway type, or use
> > mkgmap:has
> > -direction in style and get current behaviour.
> > 2/ default it to direction, clear it with mkgmap:direction=no when
> > used
> > as canal. This approach could be used if the device shows direction
> > markers on rivers that we want to see.
> > 3/ use distinct types and appropriate representation.
> > 
> > I think it should be carried through into the overview img.
> > 
> > For the dual-carriageway lane merging, I presume it should turn off
> > direction (and one-way).
> > 
> > Ticker
> > 
> > On Fri, 2021-05-14 at 05:11 +, Gerd Petermann wrote:
> > > Hi Ticker and all,
> > >
> > > reg. tests of the 0x40 flag:
> > > Attached small patch would be my guess for the lines with
> > extended
> > > type.
> > >
> > > The oneway attribute is stored in NOD and in the direction flag,
> > I
> > > think that makes sense. The oneway=yes tag used to set the
> > direction
> > > flag since more than 10 years (r738).
> > >
> > > I do agree now that an option in the style to list types with
> > > direction is the better approach, the tag handling is much more
> > > complex. The size effects of r4710 reported by Felix show
> > > that his style did not set the tag consistently for the same type
> > and
> > > I think this can be really tricky.
> > > So, I think I'll remove the code for mkgmap:has-direction=true
> > and
> > > add a new option to list the types which should be treated as
> > having
> > > a direction, e.g. --line-types-with-direction=0x18,0x1f, 0x10005,
> > > 0x10006 . The oneway=yes/oneway=-1 tag will continue to set the
> > > direction flag.
> > > The default style might need some changes to distinguish
> > waterways
> > > with direction from others, e.g. I think canals and rivers should
> > > have different types.
> > >
> > > I'll change the option  --x-force-reverse-merge to --allow
> > -reverse
> > > -merge with the default --allow-reverse-merge=no. These two
> > options
> > > will effect RoadMerger and LineMerger.
> > >
> > > I've not yet made up my mind regarding the reversing of line

Re: [mkgmap-dev] Commit 4710

please explain in more detail. Why would you add a line with a type that
has a direction to be rendered at low resolution when you don't care about
the direction at lower resolutions?

Hi Gerd, sorry I didn't explain it well enough what I meant.

I mean for other lines that are either before or after in the style created
by continue. Of course the line itself in that list shall never be reversed
in order to be merged. But I still feel if there is cycleway=left no
problem to change the underlying street direction so it can be merged.
On the other hand If someone wants to prevent that - then add no reverse
for resolution up to XX and only reverse the other lines associated with it
from resolution XX or lower. The third setting would be never merge the
other lines (could also be set by setting resolution to 00 or lower than
your lowest resolution.

On Fri, 14 May 2021 at 16:01, Ticker Berkin  wrote:

> Hi
>
> I think better/more flexible to have both. Mainly for when there are a
> limited number of well defined garmin types for an element and some
> have direction and some don't, eg the various waterways, direction
> -merged motorways...
>
> However, if there is no way of distinguishing the difference in the
> final visible representation on any device then there isn't need.
>
> Ticker
>
> On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
> > I think it is enough with a simple list. As for why it changed for me
> > is Imho because those lines are mostly created with continue or
> > continue with action and it's really hard to see what happens
> > concerning the other lines related to it. I definitely did not miss
> > any lines in my lines file that should not be reversed.
> >
> > So make it a list, and option for each type
> > other kines created with continue can change direction no, yes, from
> > resolution XX or lower.
> >
> > That would be best. Gives it all options and you can set it how it
> > works best. I still feel I will always use other lines can be
> > reversed to be merged.
> >
> > On Fri, 14 May 2021, 15:32 Gerd Petermann <
> > gpetermann_muenc...@hotmail.com> wrote:
> > > Hi Ticker,
> > >
> > > I meant I want to remove the evaluation of the special tag
> > > mkgmap:has-direction=true and only rely on the new option --line
> > > -types-with-direction
> > >
> > > Do you see a need to have both?
> > >
> > > Gerd
> > >
> > > 
> > > Von: mkgmap-dev  im Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Freitag, 14. Mai 2021 09:22
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] Commit 4710
> > >
> > > Hi Gerd and others
> > >
> > > I'll test setting of 0x40 flag for extended and the range of
> > > standard
> > > types on various devices over the weekend.
> > >
> > > Is there any real need for the force/allow-reverse-merge options?
> > >
> > > When you say "remove the code for mkgmap:has-direction", I assume
> > > you
> > > mean just the style-scan of tags used, rather than inspecting it on
> > > a
> > > way after style conversion.
> > >
> > > Styles don't have to use different tags for river/canal once this
> > > is
> > > all implemented, can choose
> > > 1/ don't set the default direction for waterway type, or use
> > > mkgmap:has
> > > -direction in style and get current behaviour.
> > > 2/ default it to direction, clear it with mkgmap:direction=no when
> > > used
> > > as canal. This approach could be used if the device shows direction
> > > markers on rivers that we want to see.
> > > 3/ use distinct types and appropriate representation.
> > >
> > > I think it should be carried through into the overview img.
> > >
> > > For the dual-carriageway lane merging, I presume it should turn off
> > > direction (and one-way).
> > >
> > > Ticker
> > >
> > > On Fri, 2021-05-14 at 05:11 +, Gerd Petermann wrote:
> > > > Hi Ticker and all,
> > > >
> > > > reg. tests of the 0x40 flag:
> > > > Attached small patch would be my guess for the lines with
> > > extended
> > > > type.
> > > >
> > > > The oneway attribute is stored in NOD and in the direction flag,
> > > I
> > > > think that makes sense. The oneway=yes tag used to set the
> > > direction
> > > > flag since

Re: [mkgmap-dev] Commit 4710

Hi Felix,

I cannot reproduce your results. For me, both maps seem to give the same 
routing result in Mapsource: a route that is much longer than yours (146 km 
instead of 129) .
Do you use non-standard driving-speeds?

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Donnerstag, 13. Mai 2021 17:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Yes I am pretty sure. Because I just recreated the map and it is the same 
again.  https://openmtbmap.org/mtbaustria_4709.exe vs 
https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to 
another to have both in Basecamp) in windows format soon.
Here is one route that is different. Use with bicycle profile without any 
restrictions / avoidances set and shorter distance.

On Thu, 13 May 2021 at 21:14, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi all,

I fear I've totally forgotten the case of extended line types. I think the 
current code doesn't write the direction flag for them and I don't know if they 
can have a direction.

Gerd


Von: Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>>
Gesendet: Donnerstag, 13. Mai 2021 14:33
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] Commit 4710

Hi Felix,

are you sure that you tested the two versions with exactly the same input? (osm 
data, style, options)?
If the changes in r4710 or r4711 really cause differences in routing quality 
there must be an error, either in my understanding or in the code.
Maybe you can post links to two tiles where routing differs?

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Donnerstag, 13. Mai 2021 14:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.

On Thu, 13 May 2021, 19:37 Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

you totally lost me. There is no version r4713 in the branch.
It seems you report the version number that svn shows after an svn update? 
That's not relevant, you must use svn info to find out the version of your 
branch.
svn update always shows the latest commit, no matter in what branch it was made.

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, 13. Mai 2021 13:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

I just looked it up. It must have been 4709 with best routing for me (unlikely 
but maybe it could have been 4708), while 4711 is a bit worse (but better than 
before the first changes that made an impact on routing). Both from low-res-opt 
branch.
I haven't tried trunk for quite a while.

On Thu, 13 May 2021 at 17:42, 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,

please tell me exactly which versions you tested reg. routing.
Note that the branches do not yet contain the latest changes in 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>><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<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>><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>>>>
Gesendet: Donnerstag, 13. Mai 2021 11:28
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Well I just got to test routing - and the current version is a degradation vs 
the intermediate version from yesterday for my maps. The current version routes 
better than before, but worse than the intermediate version.

As for the list - it is a bit more complicated inside the style

Re: [mkgmap-dev] Commit 4710

Hi Felix,

> no problem to change the underlying street direction so it can be merged.
There is a possible problem with rendering but I agreed before to postpone this 
until users complain. So, I want to remove the code which tries to be clever 
and let only the user decide.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Freitag, 14. Mai 2021 10:20
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710


please explain in more detail. Why would you add a line with a type that has a 
direction to be rendered at low resolution when you don't care about the 
direction at lower resolutions?

Hi Gerd, sorry I didn't explain it well enough what I meant.

I mean for other lines that are either before or after in the style created by 
continue. Of course the line itself in that list shall never be reversed in 
order to be merged. But I still feel if there is cycleway=left no problem to 
change the underlying street direction so it can be merged.
On the other hand If someone wants to prevent that - then add no reverse for 
resolution up to XX and only reverse the other lines associated with it from 
resolution XX or lower. The third setting would be never merge the other lines 
(could also be set by setting resolution to 00 or lower than your lowest 
resolution.

On Fri, 14 May 2021 at 16:01, Ticker Berkin 
mailto:rwb-mkg...@jagit.co.uk>> wrote:
Hi

I think better/more flexible to have both. Mainly for when there are a
limited number of well defined garmin types for an element and some
have direction and some don't, eg the various waterways, direction
-merged motorways...

However, if there is no way of distinguishing the difference in the
final visible representation on any device then there isn't need.

Ticker

On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
> I think it is enough with a simple list. As for why it changed for me
> is Imho because those lines are mostly created with continue or
> continue with action and it's really hard to see what happens
> concerning the other lines related to it. I definitely did not miss
> any lines in my lines file that should not be reversed.
>
> So make it a list, and option for each type
> other kines created with continue can change direction no, yes, from
> resolution XX or lower.
>
> That would be best. Gives it all options and you can set it how it
> works best. I still feel I will always use other lines can be
> reversed to be merged.
>
> On Fri, 14 May 2021, 15:32 Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> 
> wrote:
> > Hi Ticker,
> >
> > I meant I want to remove the evaluation of the special tag
> > mkgmap:has-direction=true and only rely on the new option --line
> > -types-with-direction
> >
> > Do you see a need to have both?
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev 
> > mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
> >  im Auftrag
> > von Ticker Berkin mailto:rwb-mkg...@jagit.co.uk>>
> > Gesendet: Freitag, 14. Mai 2021 09:22
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Commit 4710
> >
> > Hi Gerd and others
> >
> > I'll test setting of 0x40 flag for extended and the range of
> > standard
> > types on various devices over the weekend.
> >
> > Is there any real need for the force/allow-reverse-merge options?
> >
> > When you say "remove the code for mkgmap:has-direction", I assume
> > you
> > mean just the style-scan of tags used, rather than inspecting it on
> > a
> > way after style conversion.
> >
> > Styles don't have to use different tags for river/canal once this
> > is
> > all implemented, can choose
> > 1/ don't set the default direction for waterway type, or use
> > mkgmap:has
> > -direction in style and get current behaviour.
> > 2/ default it to direction, clear it with mkgmap:direction=no when
> > used
> > as canal. This approach could be used if the device shows direction
> > markers on rivers that we want to see.
> > 3/ use distinct types and appropriate representation.
> >
> > I think it should be carried through into the overview img.
> >
> > For the dual-carriageway lane merging, I presume it should turn off
> > direction (and one-way).
> >
> > Ticker
> >
> > On Fri, 2021-05-14 at 05:11 +, Gerd Petermann wrote:
> > > Hi Ticker and all,
> > >
> > > reg. tests of the 0x40 flag:
> > > Attached small patch would be my guess for the lines with
> > extended
> > &

Re: [mkgmap-dev] Commit 4710

2021-05-14 Thread Ticker Berkin

Hi

I see various aspects to this discussion.

Routable one-way roads must have their correct direction preserved and
line-merging needs to know and respect this.

If, for a given line type, there is a way of visibly distinguishing
lines representing features with a direction from the same feature
without direction, then this is a feature worth supporting. It saves
having to have alternate, user-defined types.

Resolution isn't relevant, except for the new idea of taking 2 close
parallel lines with the same type but opposite direction/one-way and
making 1 line. Now it becomes more important to be able to indicate
that this result doesn't have a direction and, unless some other
mechanism is added to change the type, this needs to be imposed on the
existing type.

Ticker
  

On Fri, 2021-05-14 at 16:20 +0800, Felix Hartmann wrote:
> 
> please explain in more detail. Why would you add a line with a type
> that has a direction to be rendered at low resolution when you don't
> care about the direction at lower resolutions?
> 
> Hi Gerd, sorry I didn't explain it well enough what I meant.
> 
> I mean for other lines that are either before or after in the style
> created by continue. Of course the line itself in that list shall
> never be reversed in order to be merged. But I still feel if there is
> cycleway=left no problem to change the underlying street direction so
> it can be merged. 
> On the other hand If someone wants to prevent that - then add no
> reverse for resolution up to XX and only reverse the other lines
> associated with it from resolution XX or lower. The third setting
> would be never merge the other lines (could also be set by setting
> resolution to 00 or lower than your lowest resolution.
> 
> On Fri, 14 May 2021 at 16:01, Ticker Berkin 
> wrote:
> > Hi
> > 
> > I think better/more flexible to have both. Mainly for when there
> > are a
> > limited number of well defined garmin types for an element and some
> > have direction and some don't, eg the various waterways, direction
> > -merged motorways...
> > 
> > However, if there is no way of distinguishing the difference in the
> > final visible representation on any device then there isn't need.
> > 
> > Ticker
> > 
> > On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
> > > I think it is enough with a simple list. As for why it changed
> > for me
> > > is Imho because those lines are mostly created with continue or
> > > continue with action and it's really hard to see what happens
> > > concerning the other lines related to it. I definitely did not
> > miss
> > > any lines in my lines file that should not be reversed.
> > > 
> > > So make it a list, and option for each type 
> > > other kines created with continue can change direction no, yes,
> > from
> > > resolution XX or lower.
> > > 
> > > That would be best. Gives it all options and you can set it how
> > it
> > > works best. I still feel I will always use other lines can be
> > > reversed to be merged.
> > > 
> > > On Fri, 14 May 2021, 15:32 Gerd Petermann <
> > > gpetermann_muenc...@hotmail.com> wrote:
> > > > Hi Ticker,
> > > > 
> > > > I meant I want to remove the evaluation of the special tag
> > > > mkgmap:has-direction=true and only rely on the new option -
> > -line
> > > > -types-with-direction
> > > > 
> > > > Do you see a need to have both?
> > > > 
> > > > Gerd
> > > > 
> > > > 
> > > > Von: mkgmap-dev  im
> > Auftrag
> > > > von Ticker Berkin 
> > > > Gesendet: Freitag, 14. Mai 2021 09:22
> > > > An: Development list for mkgmap
> > > > Betreff: Re: [mkgmap-dev] Commit 4710
> > > > 
> > > > Hi Gerd and others
> > > > 
> > > > I'll test setting of 0x40 flag for extended and the range of
> > > > standard
> > > > types on various devices over the weekend.
> > > > 
> > > > Is there any real need for the force/allow-reverse-merge
> > options?
> > > > 
> > > > When you say "remove the code for mkgmap:has-direction", I
> > assume
> > > > you
> > > > mean just the style-scan of tags used, rather than inspecting
> > it on
> > > > a
> > > > way after style conversion.
> > > > 
> > > > Styles don't have to use different tags for river/canal once
> > this
&g

Re: [mkgmap-dev] Commit 4710

gt; > > That would be best. Gives it all options and you can set it how
> > > it
> > > > works best. I still feel I will always use other lines can be
> > > > reversed to be merged.
> > > >
> > > > On Fri, 14 May 2021, 15:32 Gerd Petermann <
> > > > gpetermann_muenc...@hotmail.com> wrote:
> > > > > Hi Ticker,
> > > > >
> > > > > I meant I want to remove the evaluation of the special tag
> > > > > mkgmap:has-direction=true and only rely on the new option -
> > > -line
> > > > > -types-with-direction
> > > > >
> > > > > Do you see a need to have both?
> > > > >
> > > > > Gerd
> > > > >
> > > > > 
> > > > > Von: mkgmap-dev  im
> > > Auftrag
> > > > > von Ticker Berkin 
> > > > > Gesendet: Freitag, 14. Mai 2021 09:22
> > > > > An: Development list for mkgmap
> > > > > Betreff: Re: [mkgmap-dev] Commit 4710
> > > > >
> > > > > Hi Gerd and others
> > > > >
> > > > > I'll test setting of 0x40 flag for extended and the range of
> > > > > standard
> > > > > types on various devices over the weekend.
> > > > >
> > > > > Is there any real need for the force/allow-reverse-merge
> > > options?
> > > > >
> > > > > When you say "remove the code for mkgmap:has-direction", I
> > > assume
> > > > > you
> > > > > mean just the style-scan of tags used, rather than inspecting
> > > it on
> > > > > a
> > > > > way after style conversion.
> > > > >
> > > > > Styles don't have to use different tags for river/canal once
> > > this
> > > > > is
> > > > > all implemented, can choose
> > > > > 1/ don't set the default direction for waterway type, or use
> > > > > mkgmap:has
> > > > > -direction in style and get current behaviour.
> > > > > 2/ default it to direction, clear it with mkgmap:direction=no
> > > when
> > > > > used
> > > > > as canal. This approach could be used if the device shows
> > > direction
> > > > > markers on rivers that we want to see.
> > > > > 3/ use distinct types and appropriate representation.
> > > > >
> > > > > I think it should be carried through into the overview img.
> > > > >
> > > > > For the dual-carriageway lane merging, I presume it should turn
> > > off
> > > > > direction (and one-way).
> > > > >
> > > > > Ticker
> > > > >
> > > > > On Fri, 2021-05-14 at 05:11 +, Gerd Petermann wrote:
> > > > > > Hi Ticker and all,
> > > > > >
> > > > > > reg. tests of the 0x40 flag:
> > > > > > Attached small patch would be my guess for the lines with
> > > > > extended
> > > > > > type.
> > > > > >
> > > > > > The oneway attribute is stored in NOD and in the direction
> > > flag,
> > > > > I
> > > > > > think that makes sense. The oneway=yes tag used to set the
> > > > > direction
> > > > > > flag since more than 10 years (r738).
> > > > > >
> > > > > > I do agree now that an option in the style to list types with
> > > > > > direction is the better approach, the tag handling is much
> > > more
> > > > > > complex. The size effects of r4710 reported by Felix show
> > > > > > that his style did not set the tag consistently for the same
> > > type
> > > > > and
> > > > > > I think this can be really tricky.
> > > > > > So, I think I'll remove the code for mkgmap:has
> > > -direction=true
> > > > > and
> > > > > > add a new option to list the types which should be treated as
> > > > > having
> > > > > > a direction, e.g. --line-types-with-direction=0x18,0x1f,
> > > 0x10005,
> > > > > > 0x10006 . The oneway=yes/oneway=-1 tag will continue to set
> > > the
> > > > > > direction flag.
> > > > > > The default style might nee

Re: [mkgmap-dev] Commit 4710

Hi Felix,

> There is no discussion that we ever reverse a routable line at level 0.
Why do you think that? Of course we do (and want to do) that when reversing is 
allowed.

Gerd

Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Freitag, 14. Mai 2021 11:02
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Routable one-way roads must have their correct direction preserved and
line-merging needs to know and respect this.

I do not think so. They must have their correct direction for level 0, but not 
for level 1 (except if you display one way arrows at level 1 - then they need 
to be added to the do not reverse list - and again only the line that uses 
oneway arrows if different from the routable line). E.g. nearly all motorways 
are oneway. Well very unlikely they are ever mapped in opposite direction, but 
even then I do not see why at level 1 or higher their direction matters. Only 
level 0 is responsible for routing. There is no discussion that we ever reverse 
a routable line at level 0.

And I suppose that there is no marker in Garmin maps to display arrows for 
oneway - but then you never know. Many things about Garmin maps were found out 
that Garmin never used before, especially when it comes to .typ-files. Often 
such not used features would be removed in newer generations however. E.g. 
Garmin had never used the possibility to display a route besides a road - or 
any typfile line out of center. I think I first used this widely, and while 
Mapsource and devices displayed it correctly, Garmin roadtrip just centered 
them (or it was some device or other software centering them). A couple of 
years later Garmin started using off center lines themselves and made all their 
software show this correctly. There is still the left/right bug that they never 
fixed because their own maps do not use it.

On Fri, 14 May 2021 at 16:46, Ticker Berkin 
mailto:rwb-mkg...@jagit.co.uk>> wrote:
Hi

I see various aspects to this discussion.

Routable one-way roads must have their correct direction preserved and
line-merging needs to know and respect this.

If, for a given line type, there is a way of visibly distinguishing
lines representing features with a direction from the same feature
without direction, then this is a feature worth supporting. It saves
having to have alternate, user-defined types.

Resolution isn't relevant, except for the new idea of taking 2 close
parallel lines with the same type but opposite direction/one-way and
making 1 line. Now it becomes more important to be able to indicate
that this result doesn't have a direction and, unless some other
mechanism is added to change the type, this needs to be imposed on the
existing type.

Ticker

On Fri, 2021-05-14 at 16:20 +0800, Felix Hartmann wrote:
>
> please explain in more detail. Why would you add a line with a type
> that has a direction to be rendered at low resolution when you don't
> care about the direction at lower resolutions?
>
> Hi Gerd, sorry I didn't explain it well enough what I meant.
>
> I mean for other lines that are either before or after in the style
> created by continue. Of course the line itself in that list shall
> never be reversed in order to be merged. But I still feel if there is
> cycleway=left no problem to change the underlying street direction so
> it can be merged.
> On the other hand If someone wants to prevent that - then add no
> reverse for resolution up to XX and only reverse the other lines
> associated with it from resolution XX or lower. The third setting
> would be never merge the other lines (could also be set by setting
> resolution to 00 or lower than your lowest resolution.
>
> On Fri, 14 May 2021 at 16:01, Ticker Berkin 
> mailto:rwb-mkg...@jagit.co.uk>>
> wrote:
> > Hi
> >
> > I think better/more flexible to have both. Mainly for when there
> > are a
> > limited number of well defined garmin types for an element and some
> > have direction and some don't, eg the various waterways, direction
> > -merged motorways...
> >
> > However, if there is no way of distinguishing the difference in the
> > final visible representation on any device then there isn't need.
> >
> > Ticker
> >
> > On Fri, 2021-05-14 at 15:42 +0800, Felix Hartmann wrote:
> > > I think it is enough with a simple list. As for why it changed
> > for me
> > > is Imho because those lines are mostly created with continue or
> > > continue with action and it's really hard to see what happens
> > > concerning the other lines related to it. I definitely did not
> > miss
> > > any lines in my lines file that should not be reversed.
> > >
> > > So make it a list, and option for each type
> > >

Re: [mkgmap-dev] Commit 4710

Ah sorry, I meant a routable line with oneway attribute. Except of course
oneway=reverse / -1 which has to be reversed.

On Fri, 14 May 2021 at 17:11, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> > There is no discussion that we ever reverse a routable line at level 0.
> Why do you think that? Of course we do (and want to do) that when
> reversing is allowed.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Freitag, 14. Mai 2021 11:02
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Routable one-way roads must have their correct direction preserved and
> line-merging needs to know and respect this.
>
> I do not think so. They must have their correct direction for level 0, but
> not for level 1 (except if you display one way arrows at level 1 - then
> they need to be added to the do not reverse list - and again only the line
> that uses oneway arrows if different from the routable line). E.g. nearly
> all motorways are oneway. Well very unlikely they are ever mapped in
> opposite direction, but even then I do not see why at level 1 or higher
> their direction matters. Only level 0 is responsible for routing. There is
> no discussion that we ever reverse a routable line at level 0.
>
> And I suppose that there is no marker in Garmin maps to display arrows for
> oneway - but then you never know. Many things about Garmin maps were found
> out that Garmin never used before, especially when it comes to .typ-files.
> Often such not used features would be removed in newer generations however.
> E.g. Garmin had never used the possibility to display a route besides a
> road - or any typfile line out of center. I think I first used this widely,
> and while Mapsource and devices displayed it correctly, Garmin roadtrip
> just centered them (or it was some device or other software centering
> them). A couple of years later Garmin started using off center lines
> themselves and made all their software show this correctly. There is still
> the left/right bug that they never fixed because their own maps do not use
> it.
>
> On Fri, 14 May 2021 at 16:46, Ticker Berkin  <mailto:rwb-mkg...@jagit.co.uk>> wrote:
> Hi
>
> I see various aspects to this discussion.
>
> Routable one-way roads must have their correct direction preserved and
> line-merging needs to know and respect this.
>
> If, for a given line type, there is a way of visibly distinguishing
> lines representing features with a direction from the same feature
> without direction, then this is a feature worth supporting. It saves
> having to have alternate, user-defined types.
>
> Resolution isn't relevant, except for the new idea of taking 2 close
> parallel lines with the same type but opposite direction/one-way and
> making 1 line. Now it becomes more important to be able to indicate
> that this result doesn't have a direction and, unless some other
> mechanism is added to change the type, this needs to be imposed on the
> existing type.
>
> Ticker
>
>
> On Fri, 2021-05-14 at 16:20 +0800, Felix Hartmann wrote:
> >
> > please explain in more detail. Why would you add a line with a type
> > that has a direction to be rendered at low resolution when you don't
> > care about the direction at lower resolutions?
> >
> > Hi Gerd, sorry I didn't explain it well enough what I meant.
> >
> > I mean for other lines that are either before or after in the style
> > created by continue. Of course the line itself in that list shall
> > never be reversed in order to be merged. But I still feel if there is
> > cycleway=left no problem to change the underlying street direction so
> > it can be merged.
> > On the other hand If someone wants to prevent that - then add no
> > reverse for resolution up to XX and only reverse the other lines
> > associated with it from resolution XX or lower. The third setting
> > would be never merge the other lines (could also be set by setting
> > resolution to 00 or lower than your lowest resolution.
> >
> > On Fri, 14 May 2021 at 16:01, Ticker Berkin  <mailto:rwb-mkg...@jagit.co.uk>>
> > wrote:
> > > Hi
> > >
> > > I think better/more flexible to have both. Mainly for when there
> > > are a
> > > limited number of well defined garmin types for an element and some
> > > have direction and some don't, eg the various waterways, direction
> > > -merged motorways...
> > >
> > > However, if there is no way of distinguishing the difference in the
> > > final visible representation on

Re: [mkgmap-dev] Commit 4710

Hi Felix,

I also tried with Basecamp (Version 4.7.3) It seems we have very different 
programs?
I did this:
1) Open Basecamp, press Ctrl+G two times to clear caches for map 
"omtb_austria_13.05.2021"
2)  drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it with 
a double click. Route shows "Total distance 179 km."
3) Click on recalculate button, new route looks very different and is 274 km .

Can't say for sure which version is installed right now (4009 or 4011), but I 
think the difference should not be that large?

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Freitag, 14. Mai 2021 10:38
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

I never tested Mapsource, only Basecamp. Routing in Basecamp is much more 
similar to modern devices.
But I just noticed that by accident I had faster time activated, and not 
shorter distance. On shorter distance the differences pop up much less often.

Here is a route that also routes different with shorter distance.

On Fri, 14 May 2021 at 16:31, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

I cannot reproduce your results. For me, both maps seem to give the same 
routing result in Mapsource: a route that is much longer than yours (146 km 
instead of 129) .
Do you use non-standard driving-speeds?

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Donnerstag, 13. Mai 2021 17:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Yes I am pretty sure. Because I just recreated the map and it is the same 
again.  https://openmtbmap.org/mtbaustria_4709.exe vs 
https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to 
another to have both in Basecamp) in windows format soon.
Here is one route that is different. Use with bicycle profile without any 
restrictions / avoidances set and shorter distance.

On Thu, 13 May 2021 at 21:14, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi all,

I fear I've totally forgotten the case of extended line types. I think the 
current code doesn't write the direction flag for them and I don't know if they 
can have a direction.

Gerd


Von: Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
Gesendet: Donnerstag, 13. Mai 2021 14:33
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] Commit 4710

Hi Felix,

are you sure that you tested the two versions with exactly the same input? (osm 
data, style, options)?
If the changes in r4710 or r4711 really cause differences in routing quality 
there must be an error, either in my understanding or in the code.
Maybe you can post links to two tiles where routing differs?

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, 13. Mai 2021 14:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.

On Thu, 13 May 2021, 19:37 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,

you totally lost me. There is no version r4713 in the branch.
It seems you report the version number that svn shows after an svn update? 
That's not relevant, you must use svn info to find out the version of your 
branch.
svn update always shows the latest commit, no matter in what branch it was made.

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>><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<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>><mai

Re: [mkgmap-dev] Commit 4710

Maybe the second route is now with shorter distance instead of shorter
time.
It's bicycle with either shorter time or distance and no avoidances at all.
And I use the most up to date Basecamp Version too.

Anyway part of the reason was that 4709 routed against oneway direction 2
times I think. Maybe those roads were wrongly turned around or sometimes I
enable very low priority routing against oneway and it chose that. Would
need to check in mapedit.

I just install both at the same time by changing fid and registry family
name of one map with mapsettoolkit.in shorter time the difference appears
more often on long routes.

On Fri, 14 May 2021, 18:07 Gerd Petermann 
wrote:

> Hi Felix,
>
> I also tried with Basecamp (Version 4.7.3) It seems we have very different
> programs?
> I did this:
> 1) Open Basecamp, press Ctrl+G two times to clear caches for map
> "omtb_austria_13.05.2021"
> 2)  drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it
> with a double click. Route shows "Total distance 179 km."
> 3) Click on recalculate button, new route looks very different and is 274
> km .
>
> Can't say for sure which version is installed right now (4009 or 4011),
> but I think the difference should not be that large?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Freitag, 14. Mai 2021 10:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> I never tested Mapsource, only Basecamp. Routing in Basecamp is much more
> similar to modern devices.
> But I just noticed that by accident I had faster time activated, and not
> shorter distance. On shorter distance the differences pop up much less
> often.
>
> Here is a route that also routes different with shorter distance.
>
> On Fri, 14 May 2021 at 16:31, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> I cannot reproduce your results. For me, both maps seem to give the same
> routing result in Mapsource: a route that is much longer than yours (146 km
> instead of 129) .
> Do you use non-standard driving-speeds?
>
> 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, 13. Mai 2021 17:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Yes I am pretty sure. Because I just recreated the map and it is the same
> again.  https://openmtbmap.org/mtbaustria_4709.exe vs
> https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change
> to another to have both in Basecamp) in windows format soon.
> Here is one route that is different. Use with bicycle profile without any
> restrictions / avoidances set and shorter distance.
>
> On Thu, 13 May 2021 at 21:14, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote:
> Hi all,
>
> I fear I've totally forgotten the case of extended line types. I think the
> current code doesn't write the direction flag for them and I don't know if
> they can have a direction.
>
> Gerd
>
> 
> Von: Gerd Petermann  gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com
> <mailto:gpetermann_muenc...@hotmail.com>>>
> Gesendet: Donnerstag, 13. Mai 2021 14:33
> An: Development list for mkgmap
> Betreff: AW: [mkgmap-dev] Commit 4710
>
> Hi Felix,
>
> are you sure that you tested the two versions with exactly the same input?
> (osm data, style, options)?
> If the changes in r4710 or r4711 really cause differences in routing
> quality there must be an error, either in my understanding or in the code.
> Maybe you can post links to two tiles where routing differs?
>
> 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: Donnerstag, 13. Mai 2021 14:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Yes, 4711 on branch vs best version 4709 on branch. 4709 was best so far.
>
> On Thu, 13 May 2021, 19:37 Gerd Petermann  <mailto:gpetermann_muen

Re: [mkgmap-dev] Commit 4710

Hi Felix,

OK, seems recalculate ignores the settings in the gdb file and uses the global 
settings. I now get the same 179.12 km long route, but I get it with both maps 
and I don't see any difference. Can you point me to a place where  the 4011 
version is different?

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Freitag, 14. Mai 2021 13:33
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Maybe the second route is now with shorter distance instead of shorter time.
It's bicycle with either shorter time or distance and no avoidances at all. And 
I use the most up to date Basecamp Version too.

Anyway part of the reason was that 4709 routed against oneway direction 2 times 
I think. Maybe those roads were wrongly turned around or sometimes I enable 
very low priority routing against oneway and it chose that. Would need to check 
in mapedit.

I just install both at the same time by changing fid and registry family name 
of one map with mapsettoolkit.in<http://mapsettoolkit.in> shorter time the 
difference appears more often on long routes.

On Fri, 14 May 2021, 18:07 Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

I also tried with Basecamp (Version 4.7.3) It seems we have very different 
programs?
I did this:
1) Open Basecamp, press Ctrl+G two times to clear caches for map 
"omtb_austria_13.05.2021"
2)  drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it with 
a double click. Route shows "Total distance 179 km."
3) Click on recalculate button, new route looks very different and is 274 km .

Can't say for sure which version is installed right now (4009 or 4011), but I 
think the difference should not be that large?

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Freitag, 14. Mai 2021 10:38
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

I never tested Mapsource, only Basecamp. Routing in Basecamp is much more 
similar to modern devices.
But I just noticed that by accident I had faster time activated, and not 
shorter distance. On shorter distance the differences pop up much less often.

Here is a route that also routes different with shorter distance.

On Fri, 14 May 2021 at 16:31, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

I cannot reproduce your results. For me, both maps seem to give the same 
routing result in Mapsource: a route that is much longer than yours (146 km 
instead of 129) .
Do you use non-standard driving-speeds?

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, 13. Mai 2021 17:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Yes I am pretty sure. Because I just recreated the map and it is the same 
again.  https://openmtbmap.org/mtbaustria_4709.exe vs 
https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to 
another to have both in Basecamp) in windows format soon.
Here is one route that is different. Use with bicycle profile without any 
restrictions / avoidances set and shorter distance.

On Thu, 13 May 2021 at 21:14, 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,

I fear I've totally forgotten the case of extended line types. I think the 
current code doesn't write the direction flag for them and I don't know if they 
can have a direction.

Gerd


Von: 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>>>>
Gesendet: Donnerstag, 13. Mai 2021 14:33
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] Commit 4710

Hi Felix,

are you sure that you tested the two versions with exactly the same input? (osm 
data, style, options)?
If the changes in r4710 or r4711 really cause differences

Re: [mkgmap-dev] Commit 4710

Hi Felix,

another point: Is it possible that you create the overview map without the 
--x-force-reverse-merge option? I would expect that 4711 is smaller than 4009 
since 4011 also reverses in LineMerger.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Freitag, 14. Mai 2021 13:33
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Maybe the second route is now with shorter distance instead of shorter time.
It's bicycle with either shorter time or distance and no avoidances at all. And 
I use the most up to date Basecamp Version too.

Anyway part of the reason was that 4709 routed against oneway direction 2 times 
I think. Maybe those roads were wrongly turned around or sometimes I enable 
very low priority routing against oneway and it chose that. Would need to check 
in mapedit.

I just install both at the same time by changing fid and registry family name 
of one map with mapsettoolkit.in<http://mapsettoolkit.in> shorter time the 
difference appears more often on long routes.

On Fri, 14 May 2021, 18:07 Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

I also tried with Basecamp (Version 4.7.3) It seems we have very different 
programs?
I did this:
1) Open Basecamp, press Ctrl+G two times to clear caches for map 
"omtb_austria_13.05.2021"
2)  drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it with 
a double click. Route shows "Total distance 179 km."
3) Click on recalculate button, new route looks very different and is 274 km .

Can't say for sure which version is installed right now (4009 or 4011), but I 
think the difference should not be that large?

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Freitag, 14. Mai 2021 10:38
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

I never tested Mapsource, only Basecamp. Routing in Basecamp is much more 
similar to modern devices.
But I just noticed that by accident I had faster time activated, and not 
shorter distance. On shorter distance the differences pop up much less often.

Here is a route that also routes different with shorter distance.

On Fri, 14 May 2021 at 16:31, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

I cannot reproduce your results. For me, both maps seem to give the same 
routing result in Mapsource: a route that is much longer than yours (146 km 
instead of 129) .
Do you use non-standard driving-speeds?

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, 13. Mai 2021 17:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Yes I am pretty sure. Because I just recreated the map and it is the same 
again.  https://openmtbmap.org/mtbaustria_4709.exe vs 
https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to 
another to have both in Basecamp) in windows format soon.
Here is one route that is different. Use with bicycle profile without any 
restrictions / avoidances set and shorter distance.

On Thu, 13 May 2021 at 21:14, 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,

I fear I've totally forgotten the case of extended line types. I think the 
current code doesn't write the direction flag for them and I don't know if they 
can have a direction.

Gerd


Von: 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>>>>
Gesendet: Donnerstag, 13. Mai 2021 14:33
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] Commit 4710

Hi Felix,

are you sure that you tested the two versions with exactly the same input? (osm 
data, style, options)?
If the changes in r4710 or r4711 really cause differences in routing quality 
there must be an error, either in my unde

Re: [mkgmap-dev] Commit 4710

HForget that about overview map. I looked at the wrong files. Overview Map is 
indeed much smaller with 4011.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Freitag, 14. Mai 2021 15:02
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Hi Felix,

another point: Is it possible that you create the overview map without the 
--x-force-reverse-merge option? I would expect that 4711 is smaller than 4009 
since 4011 also reverses in LineMerger.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Freitag, 14. Mai 2021 13:33
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Maybe the second route is now with shorter distance instead of shorter time.
It's bicycle with either shorter time or distance and no avoidances at all. And 
I use the most up to date Basecamp Version too.

Anyway part of the reason was that 4709 routed against oneway direction 2 times 
I think. Maybe those roads were wrongly turned around or sometimes I enable 
very low priority routing against oneway and it chose that. Would need to check 
in mapedit.

I just install both at the same time by changing fid and registry family name 
of one map with mapsettoolkit.in<http://mapsettoolkit.in> shorter time the 
difference appears more often on long routes.

On Fri, 14 May 2021, 18:07 Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

I also tried with Basecamp (Version 4.7.3) It seems we have very different 
programs?
I did this:
1) Open Basecamp, press Ctrl+G two times to clear caches for map 
"omtb_austria_13.05.2021"
2)  drag&dropped "St. Pölten111 to B32012.gdb" into Basecamp and opened it with 
a double click. Route shows "Total distance 179 km."
3) Click on recalculate button, new route looks very different and is 274 km .

Can't say for sure which version is installed right now (4009 or 4011), but I 
think the difference should not be that large?

Gerd


Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Freitag, 14. Mai 2021 10:38
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

I never tested Mapsource, only Basecamp. Routing in Basecamp is much more 
similar to modern devices.
But I just noticed that by accident I had faster time activated, and not 
shorter distance. On shorter distance the differences pop up much less often.

Here is a route that also routes different with shorter distance.

On Fri, 14 May 2021 at 16:31, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
 wrote:
Hi Felix,

I cannot reproduce your results. For me, both maps seem to give the same 
routing result in Mapsource: a route that is much longer than yours (146 km 
instead of 129) .
Do you use non-standard driving-speeds?

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, 13. Mai 2021 17:52
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Commit 4710

Yes I am pretty sure. Because I just recreated the map and it is the same 
again.  https://openmtbmap.org/mtbaustria_4709.exe vs 
https://openmtbmap.org/mtbaustria_4711.exe. (same FID/PID need to change to 
another to have both in Basecamp) in windows format soon.
Here is one route that is different. Use with bicycle profile without any 
restrictions / avoidances set and shorter distance.

On Thu, 13 May 2021 at 21:14, 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,

I fear I've totally forgotten the case of extended line types. I think the 
current code doesn't write the direction flag for them and I don't know if they 
can have a direction.

Gerd


Von: 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>>>>
Gesendet: Donnerstag, 13. Mai 2021 14:

Re: [mkgmap-dev] Commit 4710