[mkgmap-dev] change handling of railway=abandoned
From Bernhard Hiller bhil at gmx.de on Tue Jan 21 10:36:34 GMT 2020
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.html >> 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 >>
- Previous message: [mkgmap-dev] change handling of railway=abandoned
- Next message: [mkgmap-dev] change handling of railway=abandoned
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list