[mkgmap-dev] change handling of railway=abandoned

Tue Jan 21 12:25:30 GMT 2020

Hi Ticker,

you are right, that's a good point.

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, 21. Januar 2020 13:18
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] change handling of railway=abandoned

Hi

The advantages of my rule is that it doesn't create a routable line if
there is no need for it and that it can become a footway or cycleway
depending on the tags.

Gerd's rule would create routable track then disable all access modes.
These are chosen as the start/end point of a route if closest and this
could be a problem.

Ticker

On Tue, 2020-01-21 at 11:34 +0000, Gerd Petermann wrote:
> Hi,
>
> @Bernhard:
> adding "access=no" doesn't make a way unroutable when the way has
> e.g. vehicle=yes or foot=yes. It just changes the default
> access which is assumed for highway=*. See also what happens in
> inc/access.
>
> Reg. Tickers Rule:
> I don't like it because it is more complex and somehow duplicates the
> code in inc/access.
>
> Reg. the missing highway!=* : Yes, that's needed. I forgot that we
> disabled the mop up rule for highway=*
>
> 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, 21. Januar 2020 12:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
>
> Hi
>
> Gerd rule should be OK with the addition clause of & highway!=*, but
> is
> there any reason not to have what I suggested.
>
> Ticker
>
> On Tue, 2020-01-21 at 11:36 +0100, Bernhard Hiller wrote:
> > Hi Gerd,
> > of course, {deletealltags} is a different action: it removes the
> > way
> > completely. "{add access=no}" just makes it unroutable, but leaves
> > it
> > visible on the map.
> >
> > Lte's take a look at the roads in my example (due to changes during
> > the
> > last couple of hours, be sure to look at last year's version):
> > - the road to the south-west is a tertiary, without explicit access
> > tags, and railway=razed:
> > https://www.openstreetmap.org/way/326001702/history
> > - the road north-east into Meinershagen is a residential, without
> > explicit access tags, and railway=razed:
> > https://www.openstreetmap.org/way/617284819/history
> > - the road to the east is a primary, without explicit access tags,
> > and
> > railway=razed:
> > https://www.openstreetmap.org/way/306731105/history
> >
> > True, there is another difference: railway=razed is not
> > railway=abandoned. Can we be sure that all those tags used for
> > indicating a former railway, like abandoned - dismantled - disused
> > -
> > razed etc., are always used correctly? I tried an overpass api
> > search
> > for railway=abandoned and highway=*, but could not find out how to
> > do
> > it
> > correctly.
> >
> > If those roads had railway=abandoned instead, they would no more be
> > routable with your rule. Or is there some catch?
> >
> > Let's look at some examples showing that railway=abandoned is not
> > always
> > used so strictly (or are milestones next to the way enough hints
> > for
> > the
> > former presence of a railway?):
> > - https://www.openstreetmap.org/way/121395347 has
> > railway=abandoned,
> > highway=path, with explicit access tags for foot and bicycle. I
> > think
> > the rule won't cause trouble here.
> >
> > - https://www.openstreetmap.org/way/130369751 has
> > railway=abandoned,
> > path=cycleway, and an access tag for foot (but not for bicycle). I
> > think
> > the rule would then remove the access of bicycles to that cycleway.
> >
> > - https://www.openstreetmap.org/way/101937226 has not yet been
> > detected
> > by the historic railway mappers, and lacks any railway tags. The
> > rule
> > won't do anything here ;-)
> >
> > https://www.openstreetmap.org/way/561220394 has railway=abandoned,
> > path=cycleway, and access tags for foot and bicycle. The rule won't
> > cause trouble here.
> >
> > We should make sure that "access" won't be removed from highways
> > with
> > that rule.
> >
> > Kind regards,
> > Bernhard
> >
> >
> >
> > Am 20.01.2020 um 19:49 schrieb Gerd Petermann:
> > > Hi Bernhard,
> > >
> > > well, {add access=no} is very different to action {deletealltags}
> > > My thinking is that a railway=abandoned without highway=* still
> > > might be used as a highway if a tag like foot=yes or bicycle=yes
> > > exists.
> > > Tickers idea should have more or less the same effect.
> > >
> > > Gerd
> > >
> > > ________________________________________
> > > Von: Bernhard Hiller <bhil at gmx.de>
> > > Gesendet: Montag, 20. Januar 2020 19:41
> > > An: Gerd Petermann
> > > Betreff: Re: [mkgmap-dev] change handling of railway=abandoned
> > >
> > > Hi Gerd,
> > > "add access=no" is a very dangerous option.
> > > In my style, I added a rule for removing such ways completely.
> > > And
> > > it
> > > failed terribly - today, there may be public roads on previous
> > > railways.
> > > See also my post in the forum at
> > > https://forum.openstreetmap.org/viewtopic.php?id=66451
> > > Kind regards,
> > > Bernhard
> > >
> > > Am 18.01.2020 um 19:51 schrieb Gerd Petermann:
> > > > Hi all,
> > > >
> > > > the default style has this rule:
> > > > # following really should be removed, but see:
> > > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q3/025104.htm
> > > > l
> > > > railway«andoned [0x0a road_class=0 road_speed=1 resolution 22]
> > > >
> > > > I agree with Ticker that it is not a good idea to make such a
> > > > way
> > > > routable. I would accept this when it has also a tag like
> > > > bicycle=s. I found a few ways like this, e.g.
> > > > https://www.openstreetmap.org/way/122268824 (I wonder why
> > > > nobody
> > > > added a highway tag since 2011)
> > > > BUT we should not assume access=s for a railway«andoned. So,
> > > > what
> > > > about this:
> > > > railway«andoned {add access=no} [0x0a road_class=0 road_speed=1
> > > > resolution 22]
> > > >
> > > > Gerd
> > > >
> >
> > _______________________________________________
> > mkgmap-dev mailing list
> > mkgmap-dev at lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev