[mkgmap-dev] Commit 4710

Sat May 15 09:25:29 BST 2021

*Hi all,now I understand why the map got bigger with r4710 in the branch:
The oneway tag is also also evaluated for non-routable lines and has the
same effect as mkgmap:has-direction=trueIf a non-routable line has
oneway=yes or oneway=-1 and another connected one has no oneway, they where
possibly merged before r4710.I think it is correct to not merge them, but
maybe we should ignore oneway=* for non-routable lines?*

Yes I think for non routable lines the oneway tag should be ignored. It
will be easier and more correct than removing the oneway tag. Especially if
there is a combined highway=street, railway=... for a road that is shared
between cars and tramway for example (if you decide to show both railway
and road in that case).

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

> Hi all,
>
> now I understand why the map got bigger with r4710 in the branch: The
> oneway tag is also also evaluated for non-routable lines and has the same
> effect as mkgmap:has-direction=true
> If a non-routable line has oneway=yes or oneway=-1 and another connected
> one has no oneway, they where possibly merged before r4710.
>
> I think it is correct to not merge them, but maybe we should ignore
> oneway=* for non-routable lines?
>
> Gerd
>
>
> ________________________________________
> Von: Gerd Petermann <gpetermann_muenchen at hotmail.com>
> Gesendet: Freitag, 14. Mai 2021 09:59
> An: Development list for mkgmap
> Betreff: AW: [mkgmap-dev] Commit 4710
>
> Hi Felix,
>
> 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?
>
> You say simple list is enough, but then "give all options".  Quite
> confusing ;)
> I don't want to support different ways to specify a single bit unless
> there is a very good reason. If there is a good reason we need to define
> and document priorities and handle them properly.
>
> 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 09:42
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Commit 4710
>
> 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
> 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/20210515/8acd2114/attachment.html>