[mkgmap-dev] Commit 4710

Fri May 14 10:28:46 BST 2021

Ah sorry, I meant a routable line with oneway attribute. Except of course
oneway=reverse / -1 which has to be reversed.

On Fri, 14 May 2021 at 17:11, Gerd Petermann <
gpetermann_muenchen at hotmail.com> wrote:

> Hi Felix,
>
> > There is no discussion that we ever reverse a routable line at level 0.
> Why do you think that? Of course we do (and want to do) that when
> reversing is allowed.
>
> 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 11:02
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> Routable one-way roads must have their correct direction preserved and
> line-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
> <mailto: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
> <mailto: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<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
> > > > >
> > > > _______________________________________________
> > > > 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
> > >
> >
> > --
> > Felix Hartman - Openmtbmap.org & VeloMap.org
> >
> > _______________________________________________
> > 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
>
>
> --
> 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
>

-- 
Felix Hartman - Openmtbmap.org & VeloMap.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20210514/b3dbc4cf/attachment-0001.html>