[mkgmap-dev] Commit 4710

Fri May 14 10:02:44 BST 2021

*Routable one-way roads must have their correct direction preserved
andline-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 <rwb-mkgmap at 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 <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
> _______________________________________________
> 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/ae23176e/attachment-0001.html>