[mkgmap-dev] Commit 4710

Fri May 14 08:59:26 BST 2021

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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecarver at gmail.com>
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 <gpetermann_muenchen at hotmail.com<mailto:gpetermann_muenchen at 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkgmap at jagit.co.uk<mailto:rwb-mkgmap at 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 +0000, 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk<mailto:rwb-mkgmap at jagit.co.uk>>
> 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 at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev