[mkgmap-dev] Commit 4710

Fri May 14 09:20:29 BST 2021

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210514/29226239/attachment.html>