[mkgmap-dev] Commit 4710

Fri May 14 09:46:50 BST 2021

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 <rwb-mkgmap at 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_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> im
> > Auftrag
> > > > von Ticker Berkin <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> im
> > > > Auftrag
> > > > > von Ticker Berkin <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
> > > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > > > _______________________________________________
> > > > > mkgmap-dev mailing list
> > > > > 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
> > > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > > > _______________________________________________
> > > > mkgmap-dev mailing list
> > > > 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
> > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at 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 at lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev