[mkgmap-dev] Line direction flag, merging etc

Wed May 19 11:54:25 BST 2021

Hi Gerd and anyone who uses the style/overlays file

It seems that /overlays were on their way to being depreciated. Should
this be made formal unless objections are received from style-writers
who can't easily convert to [continue]?

Is there scope for using more of the special handling of overlays when
multiple lines are generated from a single OSM way? I notice one
instance where it does this.

Ticker

On Wed, 2021-05-19 at 05:37 +0000, Gerd Petermann wrote:
> Hi Ticker,
> 
> I didn't notice that overlays are not documented. They appear in
> doc\styles\files.txt  but it seems this part is commented out, so the
> text doesn't make it into the pdf.
> 
> The major difference with overlays compared to [continue] is the data
> flow. The lines from overlays where possibly merged/reverse-merged by
> RoadMerger, they are even processed by the housenumber code. In that
> way they are better than lines from [continue] : They also have the
> added number nodes and there are fewer objects while StyledConverter
> is active, so theoretically they should perform better.
> 
> Anyhow, the concept is old and maybe we should even deprecate it.
> 
> I've committed your patch with small changes reg. oneway evaluation.
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> Gesendet: Dienstag, 18. Mai 2021 17:51
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
> 
> Hi Gerd (& Minko?)
> 
> overlay files are undocumented and probably unused except in
> OpenFietsMaps. It is a very restricted way of doing what is now done
> with [... continue {with_actions}] or, even simpler, something like:
> 
> tourism=camp_site [0x2b03 resolution 24] [0x2b05 resolution 24]
> 
> [continue] allows for different resolution ranges, routing attributes
> etc and now, with {set mkgmap:has-direction= }, explicit control of
> this for each generated line (although see following).
> 
> Thinking about my previous suggestion of looking up each overlay copy
> linetype to set has-direction, this could be very dangerous in
> allowing
> different merging/filtering behaviour/filtering between all the
> copies,
> so the lines might not overlay each other.
> 
> I don't think overlays should be allowed to add any ugliness. The
> lineType as given in the rule should be the one that is checked
> against
> --line-types-with-direction. The replacement and all copies should
> have
> the same value for has-direction.
> 
> My implementation preserves the existing behaviour. I think it is
> quite
> tidy and it doesn't need another flag in MapLine.
> 
> Ticker
> 
> On Tue, 2021-05-18 at 15:03 +0000, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > this is getting even more ugly than I expected when I wrote that I
> > don't want to support multiple ways to set the flag...
> > Whatever we decide there will be lots of confusion :(
> > 
> > With overlay types and --line-types-with-direction it is not clear
> > if
> > one has to list the type that is used in the style or one or more
> > of
> > those that appear on the "replacement" side.
> > The code in the branch only looks at the type used in the style but
> > assumes that the user wants only roads to have the dir-flag. There
> > is
> > no good reason for this.
> > 
> > So, I think we need a flag in MapLine which stores the info that
> > mkgmap:has-direction=no was used  and we have to evaluate the list
> > for each generated replacement type.
> > The attached patch for the branch should do that.
> > 
> > Gerd
> > 
> > 
> > 
> > ________________________________________
> > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > Gesendet: Dienstag, 18. Mai 2021 16:13
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
> > 
> > Hi Gerd
> > 
> > I had tried it on some in-between version that I think had
> > equivalent
> > logic to the patch and it didn't get overridden.
> > 
> > Doesn't the final (or only) lineAdder set it unconditionally for
> > oneway
> > roads? If I've misread it I'll build and test.
> > 
> > Ticker
> > 
> > On Tue, 2021-05-18 at 14:01 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > I don't see that oneway forces direction flag when the tag
> > > mkgmap:has
> > > -direction=no is set in the branch. Did you try it?
> > > 
> > > Gerd
> > > 
> > > ________________________________________
> > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > > Auftrag
> > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > Gesendet: Dienstag, 18. Mai 2021 15:53
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] Line direction flag, merging etc
> > > 
> > > Hi Gerd
> > > 
> > > The code in low-res-opt looks like ignore-oneway-for-lines.patch.
> > > The
> > > disadvantage of this, as I see it, is that has-direction can't be
> > > forced false for one-way roads.
> > > 
> > > I think my version is clearer.
> > > 
> > > Considering substitute lines from /overlays:
> > > 
> > > I had intended that they all (first and duplicates) have the same
> > > has
> > > -direction value as the original.
> > > 
> > > An alternative is that the first has the original has-direction
> > > value
> > > and the duplicate set has-direction solely from
> > > lineTypesWithDirection.
> > > 
> > > I don't know which is better.
> > > 
> > > Ticker
> > > 
> > > On Tue, 2021-05-18 at 12:35 +0000, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > > 
> > > > in the branch I found a solution which doesn't set the
> > > > direction
> > > > flag
> > > > for overlay lines when the OSM way is a oneway and a road with
> > > > overlay type is created.
> > > > With your patch still ALL lines created from the overlay type
> > > > have
> > > > the direction flag set in that case.
> > > > Tested this with the unchanged OFM style without any new
> > > > options.
> > > > 
> > > > Do you see something wrong in the current branch version r4723?
> > > > I think it's clearer.
> > > > 
> > > > Gerd
> > > 
> > > _______________________________________________
> > > 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