[mkgmap-dev] Commit 4710

Fri May 14 09:01:23 BST 2021

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