Re: [Tagging] navigational aid relation

[Sarah Hoffmann via Tagging]

On Thu, Jun 15, 2023 at 09:38:44AM -0700, Minh Nguyen wrote:
> Vào lúc 08:29 2023-06-15, Sebastian Gürtler đã viết:
> > You only would have to change the wiki page Key:entrance and encourage
> > people to allow single nodes with the tag entrance=yes and addr:xyz
> > (like this: https://www.openstreetmap.org/node/10979019687) if it is not
> > obvious where the entrance to the property is. (What happened before for
> > the whole row of houses you still can see if you plan a route to "Am
> > Rehwinkel 19, Bielefeld" (from the point you are led to you don't see
> > any entrance nor the house due to a high hedge, and you sometimes see
> > people walking down the Voltmannstraße looking for entrances...
> > Difficult, because you would have to turn in "Am Rottmannshof" to get to
> > "Am Rehwinkel" ;-) )
> 
> I neglected to mention another common heuristic: the geocoder can
> automatically bias the address point toward the street named in addr:street
> when coming up with a navigable point. The Mapbox Geocoding API is an
> example of a geocoder that does this [1][2], though unfortunately neither
> Nominatim nor Pelias has a similar feature so far.

You need to remember that routers are only one kind of client of
Geocoders and certainly not the most important by far. While a nice
gimmick, I certainly wouldn't consider it a main task of a geocoder to
return a routeable point. The main task is to return the place/object you
were searching for. In that sense, the root of the issue is that
routers usually underspecify their search query. If the query is
'airport Frankfurt', then the airport is what the geocoder returns. One can't
expect the geocoder to determine that what you actually wanted is the
street closest to the main entrance or the parking or the main bus stop.
'parking near airport frankfurt' does yield results although we'd have
to do something about priority ordering.

> Essentially, even if the address point corresponds to a rooftop, it can
> figure out where the driveway entrance or freestanding mailbox is likely to
> be. Typically, this is pretty crude, just a matter of finding the point on
> the named street that's closest to the address point.
> 
> In your example, the entrance is on Am Rehwinkel not only because the
> address names Am Rehwinkel, but also because there's a hedge along
> Voltmannstraße. Ideally, a geocoder would compute a visibility graph to
> determine the most accessible street, blurring the lines between a geocoder
> and a router.
> 
> Then again, none of this complexity is necessary if OSM has a publicly
> accessible driveway or footpath leading right up to the building. A router
> should consider that driveway or footpath to be part of the most direct
> route.

Exactly. It would be kind of counter-productive to add all this
functionality to a geocoder. A good router has all the right
data structures to make an informed decision about the navigation start point
and also the information about mode of transport etc. A geocoder's
data structures are rather unsuitable to solve these examples.

The initial examples of Florian are quite telling in that way. The
closest road to
https://osm.zz.de/dbview/?db=addresses-nrw=namemismatch#51.98796,8.57338,17z
would in fact be the service way right next to the buildings. The fault
is with the router who does not include non-accessible roads to
determine the access and thus finds the wrong road. If it would create a
full routing network that includes inaccessible service roads and footways,
it would be able to make the right decision and bring the car to the gate.

I'm not sure if there is any router around which does something even marginally
more clever than determining the closest road to the centroid. This even goes
as far as this:
https://www.openstreetmap.org/directions?engine=graphhopper_foot=43.28293%2C5.38709%3B43.29579%2C5.38222#map=16/43.2885/5.3889
(starting point given as: "47, Rue du Rouet, Marseille")

So there is a lot of room for improvement in the routers by just using
the information already available. Another example: the heuristic you mention
above, that the geocoder should bias the start point towards the street named
in address street, this is something that could be just as easily implemented
by routers when determining the start point. Street names are usually
available to them.

That said, I do think it would be a good idea if Nominatim could return
entrances for larger buildings or areas. That's why
https://github.com/osm-search/Nominatim/issues/536 is still open.
I would just draw the line where the geocoder needs to make any policy
decisions like deciding which is the best entrance point, as this
largely depends on the client's requirements. (It pretty much rules out
the Mapbox approach which is biased towards vehicle routing.)

Maybe a separate service that computes navigation points for an OSM
object wouldn't be such a bad idea. It might be easier to play around
with heuristics based on micro-mapping using a 

Re: [Tagging] Feature Proposal - Voting - historic

[Sarah Hoffmann via Tagging]

On Thu, Nov 03, 2022 at 11:56:45AM +, Anne-Karoline Distel wrote:
> Hello all,
> 
> Martin is too busy the next couple of days, so with his permission I
> have opened the voting booths for the key historic to be approved. The
> minimum 2 weeks passed a couple of days ago, and the discussion has died
> down, so hopefully everyone is ready to vote.
> 
> https://wiki.openstreetmap.org/wiki/Proposed_features/Historic

I'm not quite sure if that has been discussed yet with three places for
discussion to chose from, but the proposal has a rather big flaw in my
eyes:

historic=* is one of these keys that is used as a primary key to define
the object but also frequently seen as a property for other objects to
mark them as historic. In contrast to other keys, there doesn't even
seem to be any clear distinction for single values if they are meant to be
used as a property or a main tag.

Random example: historic=manor. About 77% of objects tagged with
historic=manor have a building=* tag, which makes perfect sense. A manor
is a building after all. So it looks like historic=manor is more of a
property tag to a building. But what about the 23% other manors that are
not tagged as building? Is a historic=manor without a builing=* tag
meant to be used as a primary key?

I would expect that an apporved wiki page to historic=* mentions this
problem and gives some guidance to mappers and data users how to handle
this situation.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - highway=scramble

[Sarah Hoffmann via Tagging]

On Thu, Sep 15, 2022 at 08:16:08AM -0700, Tod Fitch wrote:
> Interpreting OSM tags to decide if a way is a hiking trail is a hot mess. In 
> my hiking map rendering I look at over a dozen tags, individually and in 
> combination, to decide if a way is a hiking trail or not. Obviously this is 
> not ideal and we should consider a better way of dealing with this.
> 
> Even though I think improvements in hiking trail tagging are good to be 
> considered, this highway=scramble strikes me as being a first cut at best and 
> its entire purpose is to remove some specific items from the  rendering as 
> displayed at https://www.openstreetmap.org/ In other words, its intent is 
> “tagging for the renderer” which is against the general philosophy of tagging 
> in OSM.

This is the wrong way around. The root problem is that we have a lot
of OSM ways tagged highway=path just for the simple reason that they
get rendered on the main map. Moving some of the "paths" that really
stretch the limits of the definition out of the highway=path tag space
will correct this mistake and lead to less tagging for the renderer.

To get this mess sorted out we should probably start with the discussion
'what is a hishway=path'. The current definition in the wiki is
not helpful in any way. It basically says that anything can be a path,
i.e. a way with only highway=path carries no information at all.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[Sarah Hoffmann]

On Mon, Dec 21, 2020 at 07:05:10PM +0100, ipswichmapper--- via Tagging wrote:
> Okay. In this case I can rename to proposal page to "addr:range".
> 
> This new tag:
> 
> - applies to nodes and closed ways that have addr:housenumber
> - "addr:range=n" means every nth house is counted in a range
> - "addr:range=even/odd" means every even/odd house is counted
> - "addr:range=all" means every house is counted (default value for a 
> housenumber tag with a hyphen in it if no range is given).
> - "addr:range=no" means that the housenumber tag is NOT a range of values but 
> rather a single housenumber.

It's better. It would resolve half the issue. addr:housenumber would still
have a double interpretation but it's the smaller of the two issues.

addr:housenumber:range would capture a bit better what the tag means
but it starts to get uncomfortably long.

> "addr:range=all" is the default  because that is what the wiki says and what 
> software like streetcomplete suggests. Many buildings with multiple 
> housenumbers are tagged like this.

That would only make sense, when you define addr:range as being
applicable to housenumbers with hyphens only. However your definition
above was imo more sensible:
"applies to nodes and closed ways that have addr:housenumber"

If you look at all nodes and ways with addr:housenumbers 99.999% have
a addr:range=no. So that makes more sense as a default then.

> However, software can create different defaults for different countries. For 
> example, in the UK a hypenated address most probably means a range of 
> even/odd addresses (so "addr:range=2")
> 
> What are your thoughts on this?
> Also, I had linked the talk-gb thread, which discusses how addr:interpolation 
> on closed ways and nodes is already standard. That is the problem with 
> suggesting a new tag. This proposal would now require informing multiple 
> mappers to switch up the taggong scheme.

My guess would be that the main reason that people started using the
hyphen notation with addr:housenumber is that they wanted something
human readable on the map. And addr:housenumber was already rendered.

With that in mind, I think there is a reasonable way forward even for
a addr:range tag as you suggest and also for a separate
addr:housenumber_range=1-15 like I would prefer. For both it is relatively
easy to support a new agreed on proposal while still using the old
behaviour where the new one is not yet implemented. So the transition would
be:

1. Agree on proposal.
2. Get openstreetmap-carto, Nominatim and others to support new proposal.
3. Tell mappers about proposal.
4. Wait a few years.
5. Drop support for addr:housenumbers with interpolations.

Sarah

> 
> Thanks,
> IpswichMapper
> -- 
> 
> 
> 21 Dec 2020, 15:19 by lon...@denofr.de:
> 
> > On Mon, Dec 21, 2020 at 02:37:08PM +0100, ipswichmapper--- via Tagging 
> > wrote:
> >
> >> https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes
> >>
> >> Quick proposal I just created to accept this form of tagging. This follows 
> >> from a discussion on the Talk-GB mailing list.
> >>
> >> https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html
> >>
> >>
> >> Please comment if there are issues with accepting this form of tagging.
> >>
> >
> > I dislike this kind of tagging to the point that I've refused to
> > support it in Nominatim in the past. See
> > https://github.com/osm-search/Nominatim/issues/565 for the full disucssion.
> >
> > The problem is that it makes the interpretation of addr:housenumber and
> > addr:interpolation dependent on the presence of another tag.
> >
> > Note that addr:housenumber=40-48 can be a valid housenumber. Example:
> > https://www.openstreetmap.org/way/285077586 So to know if the tag needs
> > to be interpreted as a single housenumber or as a housenumber range
> > you need to check if the node/way has a addr:interpolation tag in addtion
> > to the addr:housenumber tag.
> >
> > Similarly, a way with addr:interpolation needs to be processed in two
> > different ways: If a addr:housenumber is present, then assume it's a
> > building and parse the addr:housenumber tag to get the range. If no
> > housenumber is on the way, assume it is a good old interpolation line
> > and look at the housenumbers along the nodes of the way.
> >
> > I find this kind of double meaning for tagging confusing and error-prone.
> > But I might be fighting wind mills here.
> >
> > Sarah
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
> 

> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - addr:interpolation on closed ways and nodes

[Sarah Hoffmann]

On Mon, Dec 21, 2020 at 02:37:08PM +0100, ipswichmapper--- via Tagging wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/addr:interpolation_on_closed_ways_and_nodes
> 
> Quick proposal I just created to accept this form of tagging. This follows 
> from a discussion on the Talk-GB mailing list.
> 
> https://lists.openstreetmap.org/pipermail/talk-gb/2020-December/025553.html
> 
> 
> Please comment if there are issues with accepting this form of tagging.

I dislike this kind of tagging to the point that I've refused to
support it in Nominatim in the past. See
https://github.com/osm-search/Nominatim/issues/565 for the full disucssion.

The problem is that it makes the interpretation of addr:housenumber and
addr:interpolation dependent on the presence of another tag.

Note that addr:housenumber=40-48 can be a valid housenumber. Example:
https://www.openstreetmap.org/way/285077586 So to know if the tag needs
to be interpreted as a single housenumber or as a housenumber range
you need to check if the node/way has a addr:interpolation tag in addtion
to the addr:housenumber tag.

Similarly, a way with addr:interpolation needs to be processed in two
different ways: If a addr:housenumber is present, then assume it's a
building and parse the addr:housenumber tag to get the range. If no
housenumber is on the way, assume it is a good old interpolation line
and look at the housenumbers along the nodes of the way.

I find this kind of double meaning for tagging confusing and error-prone.
But I might be fighting wind mills here.

Sarah


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] coastline v. water

[Sarah Hoffmann]

Hi,

On Sat, Nov 21, 2020 at 07:09:45PM +, Eric H. Christensen via Tagging wrote:
> You cannot point to other area that may, in fact, be improperly mapped as an 
> example when they are like that because locals have been shouted down for 
> doing it correctly. The fact that this keeps coming back up literally means 
> that there is not universal agreement that "marginal seas", whatever that 
> means, are to be mapped with natural=coastline.
> 
> The Chesapeake Bay is an estuary that, by definition, opens to the sea. It 
> can't be a sea and open to a sea at the same time. In this environment, it is 
> different from the ocean in which it opens into and is also different from 
> the tributaries that feed it. These are protected waters for ships. You won't 
> find any high seas forecasts for the Bay unlike the ocean. The Bay is also 
> brackish and not defined as salt water, unlike the ocean.

There is a very fundamental misunderstanding on how OpenStreetMap works
in here. The definition of a tag comes from the agreed-on understanding
of the OpenStreetMap community as a whole of what that tag should be. This
may or may not agree with defintion of the same word in other contexts.
That's just the way it is with defintions. They may differ. You cannot just
uniterally apply a definition of coastline that you think is more
appropriate, or scientifically correct or whatever and change the map.
It is OSM's definition that counts, and OSM's defintion only.

That doesn't mean that definitions can't evolve over time but that needs
to be discussed when it has a larger impact. natural=coastline
is a particular touchy tag here because it is one of the few tags where
we rely on a agreed-on definition that works on a planet-scale. Even if
you change something relatively locally, it has an effect on how the
planet map as a whole is rendered. You can't just apply a new definition
to one bay. We must agree on a new definition globally here and apply it
globally or the tagging becomes a worthless mess.

So please, by all means, start a discussion about a new definition of
coastline, make a wiki page, put it up for voting. But all this should
be done **before** making any larger changes. For now, please, put
the Chesapeake Bay back into its original state.

Kind regards

Sarah

> ‐‐‐ Original Message ‐‐‐
> On Saturday, November 21, 2020 1:14 PM, Joseph Eisenberg 
>  wrote:
> 
> > Eric,
> > I don't think the previous discussion is quite as inconclusive as your 
> > evaluation.
> >
> > While it is true that there is not widespread agreement on where the 
> > natural=coatline ways should transect a river mouth or river estuary, there 
> > is nearly universal agreement that marginal seas, including bays, are 
> > mapped with the natural=coastline.
> >
> > Using the rendering at https://www.openstreetmap.de/karte.html - which 
> > differentiates the marine water polygons outside of the coastline from 
> > lakes and rivers, by using slightly different colors, we can see how bays 
> > are mapped in other parts of North America and the world.
> >
> > For example, check out Delaware Bay, just up the coast from your area: 
> > https://www.openstreetmap.de/karte.html?zoom=10=39.14649=-75.07302=B000
> >  - it is mapped as a natural=bay with natural=coastline around it, not 
> > natural=water
> >
> > Upper and Lower New York Bay are mapped as bays outside of the 
> > natural=coastline - you can see the line where the waterway=riverbank area 
> > starts just at the north end of Manhattan island (though this placement is 
> > somewhat controversial) - 
> > https://www.openstreetmap.de/karte.html?zoom=10=40.63628=-73.93525=B000
> >
> > Tampa Bay: 
> > https://www.openstreetmap.de/karte.html?zoom=10=27.80801=-82.63368=B000
> >  - outside of the natural=coastline
> >
> > Galveston Bay: 
> > https://www.openstreetmap.de/karte.html?zoom=10=29.49869=-94.94249=B000TT
> >  - outside of the natural=coastline
> >
> > San Francisco Bay and connected bays: 
> > https://www.openstreetmap.de/karte.html?zoom=10=37.79939=-122.06911=B000TT
> >  - outside of the coastline
> >
> > Puget Sound - while Lake Washington on the east side of Seattle is 
> > natural=water, also most of the ship canal connecting them: 
> > https://www.openstreetmap.de/karte.html?zoom=11=47.59544=-122.39252=B000
> >
> > I would like to request that the tidal channels and estuaries around 
> > Chesapeake Bay be re-mapped with natural=coastline. If you wish to keep the 
> > natural-water polygons for the estuaries that is not a problem.
> >
> > But it would be contrary to normal practice to map the main body of 
> > Chesapeake Bay as natural=water because it is clearly part of the sea - 
> > there is no barrier between it and the open ocean, since there is an open 
> > channel through US 13 where the tunnel is. While it is an estuary by 
> > hydrological definitions, so are the Baltic Sea and all fjords and Puget 
> > Sound and San Francisco Bay - all of which are mapped as 

Re: [Tagging] [Talk-us] Large fire perimeter tagging?

[Sarah Hoffmann]

On Wed, Sep 30, 2020 at 01:55:35AM -0700, stevea wrote:
> On Sep 30, 2020, at 12:01 AM, Andrew Harvey  wrote:
> > So it seems then that what you're mapping here isn't so much the active 
> > fire front, it's the burnt area given you want it to stick around after the 
> > flames are out.
> 
> Neither of these two, really.  Certainly not the active fire front:  the fire 
> is out (for about a week now, but it burned for about six weeks).  Nor “the 
> burnt area” exactly, but rather a polygon which represents the EXTENT of 
> where firefighters kept the fire limited by building a perimeter around it.  
> Some (I’d guess much or even most) of it IS burned, no doubt, but exactly 
> where is not fully yet known — but burned areas certainly ARE inside of this 
> polygon.  This is useful because it shows not only where OSM mappers (like 
> me) will need to update landcover (and in some limited cases, landUSE, too) 
> as we update map data, but where map data consumers such as hikers in the 
> area (like me) will want to know “there may be closed roads, dangerous areas 
> and severely limited viewscapes, wildlife (both flora and fauna) et cetera to 
> enjoy were I to recreate here.”  These are but two valuable reasons for this 
> fire=perimeter remaining in the map, until the polygon's usefulness 
> essentially becomes exhausted (there are no longer reasons for these data to 
> remain).

This is a classic case where you should set up a separate
database to save the polygons and overlay them with OSM data.

For one thing, the description sounds like it is not really
suitable for OSM. It describes a past even ("the perimeter
firefighters used weeks ago") which is likely not ground
surveyable because I doubt that the firefighters have put
red tape all along the perimeters. The description is really
fuzzy. It just defines that the area is "of interest for
something". We have traditionally rejected this kind of
mapping, see e.g. recent discussions on no-go zones in
cities. The problem with them is that you don't find two
mappers really agreeing what they mean to represent. That
is bad in two ways: a) data consumers shy away from using them
because they cannot rely on that they mean what they think they
mean and b) the features tend to rot in the database because
most mapper don't dare to touch data they don't understand.

The other thing is that this kind of data is really easy to
merge with OSM data. You don't need to merge attributes into
specific OSM objects. You just want to state "anything inside
my polygon needs attention". Perfect for overlays. So there
really is no need at all to burden the OSM database with it.

Just to emphasize again: I'm not saying that the data is useless.
I just think it is better put elsewhere.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] We should stop using hyphens to denote address ranges

[Sarah Hoffmann]

On Tue, Aug 18, 2020 at 11:29:50PM +0200, Colin Smale wrote:
> I think you misunderstand hyphenated addresses in Queens. The second
> part of the hyphenation is not a flat/apartment number. As an example,
> the Dunkin Donuts at the corner of 31st St and 36th Ave has an address
> of 31-02 36th Ave, with no apartment number. The US Postal Service
> considers this to be equivalent to 3102 36th Ave, and will deliver mail
> to the same place regardless of whether you include the hyphen, though
> the address written on the entrance is hyphenated. Most building numbers
> in Queens have a hyphen before the last two digits. 
> 
> Thanks for the explanation.. It is indeed a while ago since I was there.
> Any idea how this is structured in IT systems? Is "house number"
> alphanumeric? Are the two parts stored separately? Or is it simply a
> question of formatting, inserting a "-" before the final two digits? 
> 
> Maybe we should use a different character to indicate a range, such as a
> slash? 

No matter what character you suggest, there will be some place in the world
where that is a valid addition to a house number.

Lets be honest, the main reason why we keep discussing how to get a range into
the addr:housenumber tag is good old tagging for the renderer:
addr:housenumber gets rendered on the map, a different tag doesn't. I've
even had people arguing that they must use housenumber ranges because single
housenumbers do not fit the map[1]. This is a slippery slope to go down.
It makes the tag less and less useful for uses beyond rendering.

[1] https://github.com/osm-search/Nominatim/issues/565#issuecomment-315131285

I'm strongly in favour of coming up with a new tag for ranges on building/nodes.
I'd be happy to quickly add such a tag to be searchable and I'm sure it would 
also be
fairly simple to convince the carto people to add support for an additional 
tagging
schema here.

Martin's suggestion of addr:housenumber:start/addr:housenumber:end wasn't half 
way bad.
Something like addr:housenumber_range=- with an explicit definition 
of the
hyphen as separator would work as well but add the restriction that you can't 
have
hyphened housenumbers in interpolation ranges (probably rare enough to be okay).

We'd also need a new tag to indicate the interpolation steps odd/even/all. It's 
not really
a good idea to reuse addr:interpolation because on a building outline it 
becomes ambigious:
you'd have to check for the presence of other tags to figure out if the way 
denotes an
interpolation line or an address range on a building.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Sarah Hoffmann]

On Mon, Aug 03, 2020 at 04:28:43PM -0400, Jmapb wrote:
> On 8/3/2020 6:07 AM, Sarah Hoffmann wrote:
> 
> > There is some fuzzy matching, you can expect to work, for example
> > abbreviations like street -> st or even New York -> NY. But going from
> > ref=NY-214 to 'State Highway 214' is already a long stretch that requires
> > special local knowledge.
> 
> Understood. And this is a little out of scope for the tagging list but I
> suspect this kind of long-stretch fuzzy matching for numbered routes
> will be necessary to return decent search results for a large portion of
> the rural USA -- and I'd guess similar problems will be found in other
> countries.
> 
> At least for the New York State routes, Google, Apple, Microsoft, and
> HERE seem to get this right. I don't know of any OSM-centric maps that
> do, and I'm not savvy enough to know which are using Nominatim and which
> aren't.
> 
> (Offhand, AI seems like overkill for this! The variations are pretty
> formulaic.)

It has already been done before: https://github.com/openvenues/libpostal

The problem is that there are 200+ countries, each with their own strange
name variation the locals claim to be 'perfectly obvious why wouldn't a
geocoder...'. ;)

Long-term I'd like to see emerge some kind of community-curated alias
database, where mappers can contribute the local variations. But that is
still far off.

> For now I've had a go with verbose explicit tagging using  _name tags as
> you've suggested (ignoring JOSM's "alternative name without name" warnings):
> 
> ref=NY 214
> official_name=State Route 214
> alt_name=Route 214;Highway 214;State Highway 214;New
> York 214;New York State Route 214
> 
> I've used the USPS-rectified format for the `official_name`, which isn't
> exactly right (`postal_name` might be a better tag) but seems close enough.
> 
> It's unclear to me how useful it is to cram in all those
> semicolon-separated values under `alt_name`. Since this update,
> Nominatim is now giving decent (one block away) results for "58 State
> Route 214, Phoenicia NY" but nothing for "58 State Highway 214,
> Phoenicia NY" so maybe I just have to pick a single `alt_name` and maybe
> throw in a `local_name`? (Must confess, this sort of shoehorning starts
> to feel a little odd.)

Now Nominatim screws up the search (ironically because it does shorten
'State Highway' to 'sh') but that is really an implementation
issue. Your house has now picked up the right street:
https://nominatim.openstreetmap.org/details.php?osmtype=W=304812543=amenity

>  * Q) How should `addr:street` be tagged for an address along an
> unnamed way which is part of a numbered road-type route relation?

Follow-up question on that: are all route relation names/refs mapped as
route=highway in the US usable as an address part or is that restricted to
certain routes and/or regions (for example, rural only)?

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Sarah Hoffmann]

On Fri, Jul 31, 2020 at 06:06:37PM -0400, Jmapb wrote:
> On 7/31/2020 4:24 PM, Sarah Hoffmann wrote:
> 
> > Put one of the variants into addr:street and then all the variants
> > as alternative names onto the road. Obviously that stretch of road
> > is referred to under all these names, so this is what we should map.
> 
> Putting aside the question of *which* variant to put into `addr:street`,
> this sounds like an approach that could work. But we might end up with
> something like `alt_name=Highway 214;Route 214;State Highway 214;New
> York 214;NY-214;New York State Route 214` (or the name_1 ... name_n
> equivalents). I could live with that if it actually helped the geocoding
> but it's not exactly graceful.

The question here is always how much guessing you expect a geocoder to
do. We could train the geocoder to do a lot of fuzzy matching on the
street name variants as the one above. This may sound like a good idea to
make mapping easier for you but in the long run it doesn't help.
For one thing, if Nominatim gives you two or three simple rules how the
matching works, then you can easily figure out yourself what is going on
and fix it. If the matching is more complicated (possibly even involving
AI), then you sooner or later run into an issue where you just don't
understand why things go wrong. The other problem is that Nominatim is
not the only geocoder out there. You may expect one geocoder to do clever
things to understand the tagging but there is very little chance that all
data users will go through the trouble. So being explicit in your tagging
makes the data more useful.

There is some fuzzy matching, you can expect to work, for example
abbreviations like street -> st or even New York -> NY. But going from
ref=NY-214 to 'State Highway 214' is already a long stretch that requires
special local knowledge.

> 
> Ultimately, though, these are alternate names for the route, not for the
> stretch of road. (Which might have its own list of names! For instance,
> a particular stretch of Ulster County Route 40 is known as Main Street,
> Plank Road, Old Plank Road, Old Route 28, and Mount Tremper-Phoenicia Road.)
> 
> > It really doesn't matter that the road has officially no name. The
> > goal is to map what's on the ground.
> 
> For the road itself, what's on the ground is simply the highway shield
> with the number 214. There's no textual version of the name anywhere
> (except as used for the addresses of residences and POIs.) Best practice
> for these sorts of roads, I'm told, is to omit `name=*`, tag `ref=*`,
> and add to a route relation.

Note that 'on the ground' doesn't always mean that there needs to be a
physical sign. I consider an envelope (of a letter) as much on the ground
as a street name you get by asking the inhabitants what they call the
street they live on. If you want to express these nuances you can always
use the different variants of name (offical_name, local_name, old_name, ...).
So, yes, in your situation I'd leave out the name tag, add the ref and
a couple of *_name tags that contain the names used in the addresses or
between locals.

> For the addresses along the road, the vast majority are signed with just
> a housenumber, and those POI signs that do include a street name are
> inconsistent. Government data sources are also inconsistent.
> 
> But an on-the-ground mapper can observe that those housenumbers belong
> to this road, which here is known only by its route number. I feel there
> should be a way to encode that observation without asking the mapper to
> choose a particular textual representation of the route's name...
> especially since it's hard to do that in a consistent manner.
> 
> (Whatever the solution, my aim here is to get an address search that works!)

Nominatim's algorithm currently is to match addr:street with any name or
ref tag on a highway (including service, footway, path, etc.) It allows a
little bit of fuzziness but ideally you use exactly the same spelling. If
nothing is found, it simply uses the nearest street. 

There is another solution, if you really don't like the requirement of
exactly matching names: associatedStreet relations. They do take precedence
over the matching as explained above. Using those relations you can
use a different addr:street name.

Disclaimer: I have a deep dislike of associatedStreet relations and consequently
they suffer from a bit of neglect in Nominatim. :)

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] addr:street for routes

[Sarah Hoffmann]

On Fri, Jul 31, 2020 at 03:44:13PM -0400, Jmapb wrote:
> On 7/31/2020 1:00 PM, Paul Johnson wrote:
> > I'd go with the official address.  It's not rare to find addresses in
> > the US where what goes on an envelope doesn't match what the street is
> > actually called. Nor is it rare to find the wiki to be wrong
> 
> Sometimes the official address is unclear. Example, the firehouse at
> housenumber 58. The fire department website says "58 NY-214", the county
> records list the parcel address as "58 Route 214" with "Route 214 PO Box
> 281" as the mailing address. The USPS website likes the address "58
> State Route 214" which is what I put for now.

Put one of the variants into addr:street and then all the variants
as alternative names onto the road. Obviously that stretch of road
is referred to under all these names, so this is what we should map.
It really doesn't matter that the road has officially no name. The
goal is to map what's on the ground.

As far as the wiki goes: it would be more precise to say that
addr:street should have _one of the names_. old_name, local_name,
name:es, ref, they all will do.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Finger- or guide-post text

[Sarah Hoffmann]

On Thu, Jul 16, 2020 at 07:24:25PM +0100, Andy Mabbett wrote:
> I am mapping a fingerpost, aka guidepost:
> 
>https://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost
> 
> I would like to add the inscription, for each of the three fingers,
> with their compass points. I note:
> 
>https://wiki.openstreetmap.org/wiki/Key:destination
> 
> is similar but "destination:forward" and "destination:backward" are
> meaningless in this context; and many finger posts have more than four
> fingers, or fingers not at 90-degree angles to each other, or to
> North. I propose something like:

Please have a look at 
https://wiki.openstreetmap.org/wiki/Relation:destination_sign

That's what it looks like in the wild:
https://hiking.waymarkedtrails.org/#guidepost?id=3673098550

The schema is a bit verbose but it has the advantage that you can clearly mark 
which
way the finger points to instead of giving compass degree approximations.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Sarah Hoffmann]

On Sun, May 24, 2020 at 03:03:40PM -0400, Kevin Kenny wrote:
> On Sun, May 24, 2020 at 5:42 AM Sarah Hoffmann  wrote:
> > The SAC scale grades 1-3 are quite helpful. It's just the blue scales 4-6
> > which are not really applicable in OSM because very few routes of that
> > scale would fall under the highway=path classification (even under the
> > catch-all definition of OSM).
> 
> The first problem with the sac_scale is that it's not got anything at
> the low end. For trails in urban and suburban areas, we want to know,
> for instance, whether the trail might be accessible to the disabled or
> to small children. That's actually the single biggest problem here.

sac_scale is useful for what it was made for, namely hiking trails.
It was never meant to be used on urban paths. In fact, the presence
of the tag tells you that the path in question is not an urban path.
Complaining that it has no values for urban accessibility is like complaining
that all the values for the waterway key are unsuitable for highways.

> Without delving into a ton of auxiliary information, there's no
> difference between an urban footway and a wilderness trail!  For that
> reason, 'surface' and 'smoothness' and 'incline' and 'sac_scale' are
> all trolltags: they destroy fundamental expectations (at least to
> urbanites) of what a 'path' is. (Those false expectations are
> responsible for many outdoor accidents in my part of the world - I'm
> close enough to several large cities that we get many unprepared
> tourists.)

I highly doubt that somebody who doesn't think twice about using a
path in the mountains/outback without experience and gear will be deterred
by a suitability tag. The real problem with those people is the lack
of thinking not the lack of tagging.

That said, my favourite solution here would indeed be to add a new main
tag highway=trail and slowly retag the existing mountain paths starting
with the most dangerous/abused ones. They would disappear from the map for
a while until renderers and apps have adapted to the new schema.
I'd consider this actually a plus because only the data users that
are really interested in outdoors would adapt while for everybody else the
trails are just gone. And for the ones who do want to use them, we'd
send a very strong message: this is a different kind of highway,
you cannot just handle it like every other path. (I hope even the
Carto people finally get the message. The fact that they thought it
was a good idea to munge path and footway together is partially what
got us into this mess.)

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Reviving the path discussion - the increasing importance of trails in OSM

[Sarah Hoffmann]

On Sat, May 23, 2020 at 09:58:50PM -0400, Kevin Kenny wrote:
> On Sat, May 23, 2020 at 9:52 PM Graeme Fitzpatrick
>  wrote:
> > We have a similar system here
> >
> > The Australian Walking Track Grading System
> >
> > Grade 1 is suitable for the disabled with assistance
> > Grade 2 is suitable for families with young children
> > Grade 3 is recommended for people with some bushwalking experience
> > Grade 4 is recommended for experienced bushwalkers, and
> > Grade 5 is recommended for very experienced bushwalkers
> 
> And all five of those grades are sac_scale=hiking, which is why I say
> that's an impossible scale to use for the purpose we're considering.

That's not correct. If you have a look at
https://wiki.openstreetmap.org/wiki/Key:sac_scale
you'll notice that only from sac_scale=demanding_mountain_hiking the
scale starts to have the requirement "basic alpine expericence" and
"good hiking shoes".

So: Only Grade 1 and 2 are clear sac_scale=hiking. Grade 4 would map
to sac_scale=mountain_hiking and Grade 5 to sac_scale=demanding_mountain_hiking.
Grade 3 is a bit inbetween but I'd probably put it under
sac_scale=mountain_hiking to be on the safe side.

The SAC scale grades 1-3 are quite helpful. It's just the blue scales 4-6
which are not really applicable in OSM because very few routes of that
scale would fall under the highway=path classification (even under the
catch-all definition of OSM).

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names that aren’t names

[Sarah Hoffmann]

On Thu, Apr 02, 2020 at 06:38:20PM -0700, Paul Norman via Tagging wrote:
> On 2020-04-02 2:33 p.m., Yves wrote:
> > Surely this can be fixed if needed, but Osm2pgsql still has a
> > route_name column?
> 
> osm2pgsql doesn't have any columns. It will produce a database with the
> columns you tell it to, transformed how you tell it to.

The C transform still has a obscure hidden reference
to 'route_name' and will actually copy the name tag
there:
https://github.com/openstreetmap/osm2pgsql/blob/master/src/tagtransform-c.cpp#L244

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Route names that aren’t names

[Sarah Hoffmann]

Hi,

On Sat, Mar 28, 2020 at 06:18:01PM +, Richard Fairhurst wrote:
> Route relation names aren’t in a great state, are they?
>
> The upshot: bad luck if you want to render the actual names of routes on a 
> map. You can’t.

Or want to search for them. The sad state of the name tag is the
only reason why you still can't search for hiking/cycling
routes on osm.org[1].

[1] https://github.com/osm-search/Nominatim/issues/413

> A modest proposal: let’s use the name= tag in route relations for route 
> names. Let’s use the ref= tag for route numbers. If it doesn’t have a name, 
> it shouldn’t have a name= tag. Same as we do everywhere else.
> 
> If you need somewhere for a mapper-facing route description (and I can see 
> that you need that for “part United Kingdom 5”), then I guess the obvious 
> place to put that is the note= tag. But let’s keep it out of the name tag; 
> and let’s have a concerted effort to remove them from existing name tags.

Problem is that a large part of routes is mistagged this way.
The public transport people even officially recommend this crappy
tagging for the name tag[2]. So I suspect that this particular ship
has sailed a long time ago.

[2] 
https://wiki.openstreetmap.org/w/index.php?title=Proposed_features/Public_Transport=625726#Route

These days I wonder if it wouldn't be better if we introduce a tag
that explicitly contains the name only. How about official_name for a,
well, official name of the route and local_name for one that is used
by everybody else.

On top of that, it would be good to encourage more use of tags for all the
other info that nowadays ends up in the name tag. Most of the are actually
defined somewhere already:

* ref
* symbol
* operator
* region [3]
* itinary (or, as PT people prefer: from, to, via)
* section_name (section? stage? leg?)
* section_ref

[3] Basically the entity that 'ref'refers to. Sometimes that is a touristic
area, sometimes the operator. I'd rather call it 'network' but that tag
is already used for something else.

If this kind of extended tagging gets widely enough used, then the
name tag can just fall into oblivion.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

[Sarah Hoffmann]

On Wed, Feb 05, 2020 at 05:28:03PM +0100, Christoph Hormann wrote:
> On Wednesday 05 February 2020, Jeroen Hoek wrote:
> > > the semantic ambiguity of the > 350k cases where barrier tags are
> > > currently used as a secondary tag on landuse/leisure/etc. polygons
> > > to incidate the polygon is enclosed by a linear barrier.
> >
> > The PR specifically removes the filled rendering from `barrier=hedge`
> > mapped with `area=yes` from 36665 hedges.
> 
> No, it does not, the PR removes the fill rendering of all *polygons* 
> tagged barrier=hedge.  This includes closed ways with barrier=hedge and 
> area=yes, closed ways with barrier=hedge and a different tag implying a 
> polygon and also multipolygons.  I explained the way the renderer 
> interprets the data in the PR discussion.  Understanding this and 
> understanding the current meaning of the area=yes tag is *essential* 
> for understanding the reasoning behind this change.

area=yes is a secondary tag that has the meaning "the way it is
on is an area, no matter what any other tag suggests". So clearly,
if something is tagged barrier=hedge+area=yes, it must be a hedge
mapped as an area. Our current interpretation of the tag leaves
no room for interpretation here.

The more interesting case is barrier+landuse. You argue that the
presence of landuse makes the entire OSM way a polygon. I know
that osm2pgsql implements it this way but I don't think that is
entirely correct. barrier and landuse are two main tags. The
rules what happens, when an OSM object has two main tags are a
bit on the fuzzy side. In general we have interpreted it as a short
cut for: there are essentially two objects that share the
geometry and the secondary tags. That does not mean that one
main tag inherites all the implicit assumptions of the other
main tag. So in this case a barrier does not automatically
inherit the implicit area=yes of the landuse tag.

In this interpretation the landuse inherently is a polygon,
the barrier inherently a line feature.

> What you essentially want is for barrier=hedge on polygons to have a 
> different meaning depending on the presence of area=yes.  Given the 
> very specific and highly significant technical meaning of area=* 
> overloading it with additional more specialized meanings w.r.t. 
> specific tags seems a very bad idea to me.

I don't understand what the special case here is. area=yes makes
a feature a polygon. Always. It doesn't matter what the main tag
is. It just means that the object has been mapped in two dimensions
instead of the usual one.

> I never claimed it to be.  What i did say is that what is mapped with 
> barrier=hedge on polygons with a different meaning than 'this polygon 
> is enclosed by a hedge' is elsewhere predominantly mapped with 
> natural=scrub/wood or landuse=forest.  I demonstrated this with links 
> to various places.

No, the meaning of a barrier=hedge on a closed way without area=yes
is exactly the same as for a barrier on a non-closed way:
there is a hedge that follows the path of the line. The fact
that the line meets at its ends is not relevant for the interpretation.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Rare route values route=inline_skates and route=running

[Sarah Hoffmann]

On Sat, Jan 11, 2020 at 02:21:50PM +0900, Joseph Eisenberg wrote:
> The tag  route=inline_skates was added to Map features, but it has
> only been added a few times in the past 4 years.
> 
> Are there actually signed, verifiable inline skate routes?

Yes, Switzerland has a whole network of those. See:
https://skating.waymarkedtrails.org/#routelist

And the Netherlands have started a network as well:
https://skating.waymarkedtrails.org/#routelist?map=13!51.9615!4.3303

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - hiking_trail_relation_roles

[Sarah Hoffmann]

On Fri, Dec 06, 2019 at 11:54:08AM +0100, Peter Elderson wrote:
> Andy Townsend :
> 
> > Michael Behrens:
> >
> >
> > There is no unique way to tag roles in hiking route relations
> >
> > I'd suggest making it clear that that table is currently for way members
> > only - it doesn't mention node members (start, end, marker, etc.).  This
> > may be deliberate, or you just haven't expanded it yet, but I'd definitely
> > mention node members.
> >
> >  Also, i guess backward and forward roles are for ways only, the other
> roles are more suited for relation members. Or not? Could I enter all the
> ways of a 3 Km  medieval castle excursion to a viewpoint into the hiking
> relation holding the ways of the main route, each with the 'excursion'
> role? I think this should be explicit.
> 
> It seems to me that use of these roles leads to relations containing
> non-contiguous trails. I would call those relations collections rather than
> routes. Processing non-contiguous routes presents extra challenges for
> processing such as exporting routes and making elevation profiles.

I have to strongly disagree with all of that.

1. Having alternatives and excursions does not make a route non-contiguous.
   It just makes it non-linear.
2. It is perfectly normal for a route to be non-linear. If the alternative
   route is marked, it's part of the route and should be mapped accordingly.
3. Non-linear routes are not a problem for processing per-se.

The point about the processing you have now made repeatedly in different
contexts. You seem to have come to this conclusion because waymarkedtrails
does not implement non-linear routes. As much as it honors me that you
consider waymarkedtrails the gold standard for what is doable with route
relations, I have to disappoint you here. Non-linear routes are simply not
implemented because of lack of time.

If I'd have to state a rule what makes processing easier then it would be:
avoid subrelations unless the relation is so large that it is a pain to
handle in the editor.

Kind regards

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] place or border_type ?

[Sarah Hoffmann]

On Tue, Oct 29, 2019 at 12:48:42AM +0100, Martin Koppenhoefer wrote:
> > Il giorno 28 ott 2019, alle ore 10:00, Sarah Hoffmann  ha 
> > scritto:
> > 
> > It is one possibility to tag such administrational oddities
> > as German "kreisfreie Städte" where an admin_level=6 may be
> > a county or a city.
> 
> 
> thank you, this is indeed a case where it actually adds detail and is not 
> simply replicating the meaning of the admin boundary tags. Looking at some 
> data, there’s also de:place=city, likely to avoid conflicts with place=city 
> areas seen as built up / settlement area, sadly the nature of many kreisfreie 
> Städte is still only tagged in note and de:place:note tags.

The tagging is very inconsistent in that matter. I don't think that
it was ever discussed anywhere. It just happened. But these oddities
are not a purely German matter. There are quite a few cities around the
globe with a special status, e.g. Algiers, Moscow, Vienne, Havanna.

So I'd be in favour of a globally applicable place=* tagging.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] place or border_type ?

[Sarah Hoffmann]

On Mon, Oct 28, 2019 at 06:17:29AM +0100, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > Il giorno 28 ott 2019, alle ore 02:56, Clifford Snow 
> >  ha scritto:
> > 
> > Counties in the US are tagged as admin_level=6 + boundary=administrative.
> 
> 
> +1, I have never understood why some people are double tagging administrative 
> entities not only with admin_level and boundary but also with place tags.

It is one possibility to tag such administrational oddities
as German "kreisfreie Städte" where an admin_level=6 may be
a county or a city.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Sarah Hoffmann]

On Mon, Aug 19, 2019 at 10:50:05AM +0200, Volker Schmidt wrote:
> On Mon, 19 Aug 2019 at 09:47, Sarah Hoffmann  wrote:
> 
> Assuming we don't care what happens to really botched relations, all cases
> > except one that I listed initially are covered with one single simple
> > instruction to the mapper: sort your route.
> 
> I strongly disagree with this advice, at least as far as cycle routes are
> concerned (disclaimer: I have mapped many bicycle route relations)
> Even many run-of-the mill "linear" (A-to-B) routes have the problem that
> the the precise A-to-B route is different form the B-to-A version of the
> "same" route. The reasons are mainly
> 
>- roundabouts
>- one-way cycle paths
>- oneway streets without bicycle:oneway=no (frequent in agglomerations,
>the route A-to-B uses different streets from the B-to-A route)

> At the practical level it is impossible to sort these route relations
> automatically (in JOSM for example) or manually.

I disagree that a) it is not possible to sort such routes and
b) that sorting doesn't help.

A route that goes like this:

  A -> X -> B
<- Y <-

can be put into the relation in order A, X, Y, B or A, Y, X, B.
Or to put it more formally: If you take only ways used to get from
A to B, you should get a linear route. And if you take only ways
that are used to get from B to A, you still get a linear route.

You get a nicely sorted route with one break in there. It's easy
to do in any editor where sorting is easy to do and there is no need
for nested relations.

To convert something like this into a linear geometry, do:

1. Go through relation and reverse all ways as necessary to create a
   route with minimal gaps.
2. For each way that is tagged forward/backward you can now determine
   from the direction of the way and its role if it is part of A->B
 or B->A.
3. Filter all ways that are two-way or marked A->B, line them up and
   you have one direction of the route.
4. Rinse and repeat for direction B->A.

Or to put it in other words: you can use exactly the same algorithm
as for linear routes and just add a bit of oneway detection on top.

(I am aware that roundabouts are a special case that should be handled
to spare the mapper splitting of roundabouts. But, again, if the route
is sorted, then detecting this is a piece of cake, even when the
roundabout is split at inconvenient places.)

> Let me also introduce a further complication in the "sorting" discussion
> for hiking and cycling route relations.
> Some mappers like the idea to keep signposts in the same route relation as
> the ways making up the route. This strategy has been adopted in an
> important collaboration between the Italian Alpine Club (CAI) and OSM (in
> Italy represented by WIkimedia Italia). Unfortunately the corresponding
> wiki page <https://wiki.openstreetmap.org/wiki/CAI> is only available in
> Italian.

This is not relevant for sorting during processing. Those members are stripped
away first thing. If it bothers you during editing, I have to say that I have
little sympathy as those guideposts don't belong into the relation in the
first place. Use https://wiki.openstreetmap.org/wiki/Relation:destination_sign
instead.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Sarah Hoffmann]

On Sun, Aug 18, 2019 at 09:25:01AM -0700, Richard Fairhurst wrote:
> But just as long established in OSM is the principle that - since mappers
> are our most precious resource - we optimise for the mapper, not for ease of
> consumption. Allowing relations to be unsorted is an example of that. If a
> relation represents a linear route, it's a SMOP to put the ways in the right
> order. 

Sure, we are not talking about the 80% linear routes (of which less than a
quarter is unsorted btw, so it doesn't seem to be a too difficult thing to
do for the mapper.) Happy to processed them in any order. 

We are talking about routes which are non-linear by design (split direction,
alternatives, accesses, circular, self-intersecting), broken relations,
unfinished relations, directed routes (think MTB downhill) and truely
botched relations.

> There are two obvious strategies. 1 is: create an empty polyline P with
> endpoints P1 and P2; iterate through the relation members; every time you
> encounter a way with an endpoint P1 or P2, add it to the polyline
> (potentially in reverse order) and remove it from consideration; repeat
> until there are no ways left. This is broadly the approach I've used until
> now.
> 
> 2 is more involved but more fault-tolerant and flexible; create a routing
> graph, then route from the relation's startpoint to its endpoint using a
> very heavy uplift for members of this relation. This is a useful approach
> where the route actually _is_ non-contiguous but you nonetheless want to
> include connecting routes between the sections. (Quite a lot of American
> rail-trails are like this, as are several UK National Cycle Network routes.)
> This is an approach I'm investigating at present.

I have experimented quite extensively with using routing algorithms for the
relation assembly. Even determining a start and endpoint of the relation is
already messy. There are corner cases everywhere. Example: a relation with
exactly two open ends should be an open and shut case, right? Wrong! It might
also be a circular route with two access ways.

Any sorting suggestion that either starts with "Step 1: install a planet-
wide OSRM with a foot profile" or involves a complicate algorithm that makes
a lot of undocumented assumptions about the relations cannot be in the
interest of OSM.

The first hinders the use of our data. You shouldn't need be able to afford a
2000$ server just to assemble a couple of routes.

The second makes life harder for mappers because it becomes non-obvious how
they can fix their stuff when it breaks in their favourite software. And
worse, even if they fix it for one, it might acutally breaks the other software
which is working on different assumptions.

We do happen to have a clear rule for unbroken linear routes: just assemble
in the obvious way, no matter if sorted or unsorted. We don't have any rule
for anything more complicated that mappers can follow to get the desired
effect. We already fail with something as simple as a directed unbroken
linear routes and circular routes. There is no single recommended way to
define the start point.

 
> Approach 1 does of course fail if the relation doesn't represent a single
> linear route. That would, however, still be true if the route was ordered.

With sorted routes, your approach 1 becomes quite a bit simpler: just take
ways in order, adapt direction so that the gaps are minimal. Assemble.

That algorithm gives you reasonable results for the following cases
automatically: linear, broken, unfinished, circular and self-intersecting
routes.

Assuming we don't care what happens to really botched relations, all cases
except one that I listed initially are covered with one single simple
instruction to the mapper: sort your route.
 
What remains are routes which are split/have alternatives/access routes etc.
Gut feeling tells that roles will solve those cases but I get back to you
on that once I had a go at implementing it.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Sarah Hoffmann]

On Sat, Aug 17, 2019 at 01:11:17AM -0700, Richard Fairhurst wrote:
> Peter Elderson wrote:
> > I would like to see this software in operation! Could you give me the 
> > links of some applications 
> 
> I use my code in the backend of cycle.travel. It's not open source. I've
> seen code used by one other OSM-based site and there's a further one that's
> clearly using something similar. There are at least two really obvious
> strategies for dealing with relations like this.
> 
> > The point is, as it is it's not good enough for data use besides 
> > rendering. you can't rely on route relations for anything but rendering
> 
> Once again: pretty much every OSM-based bike router uses route relations to
> influence routing. (That might give you a clue to one of the strategies.)

But this is a task which is essentially the same rendering. You only need
to know what routes are on a certain way segment and use that information
to adjust the weights for the road. Even if you do something fancy like
ensuring that you remain of the same cycling route, it still comes down to
using the relation information as a property of the ways. Our route relations
are well suited for that.

The problems come in if you want to go the other way. When you start with the
relation, want to determine where the route goes along. That information is
simply not contained in the route relations as long as you don't impose a
couple of restrictions. Sure, you can apply a couple of heuristics and get
a reasonably good result for most of the routes. But it remains guess-work.

I have no issue if relations require reasonable processing to get to a result
but I would like to see enough information encoded in the route relation that
the processing invariably gets me to the result that the mapper intended.
I consider sorting and the use of roles essential for that.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Sarah Hoffmann]

On Thu, Aug 15, 2019 at 04:50:26PM +0200, Peter Elderson wrote:
> Sarah:
> > There is relatively few software that can handle hierarchic relations.
> One could argue that putting alternatives in separate relations makes it
> actually harder to access those.
> 
> I think it's fair to say there is almost no software that does anything
> with route relations except rendering and exporting as a gpx. Dislaying
> elevation prophile is also one you can find, and it shows nicely what
> inconsistency does: break up the prophile.  Rendering looks OK because in
> the end you display the ways and it doesn't matter if they are out of
> order, double, running in loops or whatever. For A to B navigation you need
> single ordered chains without all the variations and reduplications.

There is a difference between what current software does and what software
could reasonably do. Yes, software needs a sorted relation and it
needs the information what the linear main route is and what diversions,
alternaitves and accesses are and how they relate to the main route.
Relations should contain enough information that software can extract
the information with resonable efford and without resorting to guessing.
But there is another side: relations are only useful when they are reasonably
easy to maintain by mappers because otherwise there are no relations.

Now, sorting is a beast. I haven't found a way to support unsorted relations
and guarantee a certain usefulness of the data even when relations get
broken. I prefer hardning against data breakage. It's always a trade-off.

Adding alternatives, links etc. is a different matter. When they are marked
with the proper role, than that is a very simple matter of filtering the
members of a relation by their role. That is a very, very simple excercise
for software. Much easier in fact than handling nested relations. So no need
to burden the mapper with complications like nested relations. Just add the
ways with the proper role and software can cope. We just need to come to
an agreement between software and mappers what the roles mean. 

What I'd like to see clarified is: what roles can be expected and when should
be used, i.e. I think we should make it clear that only a signed
alternative/excursion/access is eligible. And even there are some nuances:
is a single sign-post sufficient or should there be the same trailblazing
along the path as for the main route.

> If that can be done at mapping level, datausing software could actually be
> made to work with that. Now you can only export a track (losing the map
> info), strip it in an editor to create your own route, and then move it to
> the routing or planning software which then recombines it with a map.
> That's why I say:
> 1. Routes with only ways OR only part relations

I agree but more for making life of mappers easier.

> 2. No double ways

That cannot be avoided. There are routes that go past the same way twice.
These routes should be mapped as they are.

> 3. Always have one single strand main route; alternatives as separate
> single strand routes.

That's not possible unless you want to resort to separate relations for
backward and forward direction. (Think one-way streets along cycling
routes.) And we know to what kinds of hells that has led for PT mapping.

Sarah
(aka lonvia, maintainer of waymarkedtrails)

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Roles of route members (was: Merging tagging scheme on wiki pages of Hiking, ...)

[Sarah Hoffmann]

Hi,

(making this a new topic)

On Thu, Aug 15, 2019 at 11:56:30AM +0200, Peter Elderson wrote:
> I strongly prefer to have one relation for the main route, and separate 
> relations for alternatives. Put those together in a relation with roles for 
> the member relations, not for individual ways. So the lowest level always 
> contains only ways, the higher level contains only relations. 

Using subrelations is not consistent with the current use of forward/backward 
roles.
I'd consider alternatives, excursions and access routes to be equivalent
to those.

> The ways in the main relation should form one continuous sorted (sortable) 
> route, which data users can extract or link to for navigation or planner 
> software.

There is relatively few software that can handle hierarchic relations.
One could argue that putting alternatives in separate relations makes
it actually harder to access those.

In the end, it doesn't really matter if you put the role on way or
relation members. I'd just allow both. (Although I agree that ways and
relation member shouldn't be mixed in a single relation.)

The more important part is to agree on a couple of roles so that
mappers and software know what to use.

I did a quick count and that's what is in use most currently for roles
on hiking routes:

alternatives:  alternative(117), alternate(105)
side paths:excursion(166)
access paths:  link(85)

and for cycling:

alternatives:  alternative(74), alternate(64)
side paths:detour(25)
access paths:  link(78), connection(52)

NB: They are used almost exclusively on way members.

Sarah

> 
> Note that rendering routes is not that critical, but data use is increasingly 
> important.
> 
> Fr gr Peter Elderson
> 
> > Op 15 aug. 2019 om 09:35 heeft Warin <61sundow...@gmail.com> het volgende 
> > geschreven:
> > 
> >> On 15/08/19 17:00, Peter Elderson wrote:
> >> Where/to what exactly do you apply the role?
> > 
> > In the relation.
> > 
> > See https://www.openstreetmap.org/relation/1388126
> > 
> > Here the 'normal' members are simple ways with no role, these form the 
> > route itself.
> > 
> > Those that have a relationship role of 'alternate' in this instance are 
> > relations themselves but the could be more simple ways.
> > These form alternate routes to the main route.
> > They could be for any number of reasons - hight tides or flooded rivers.
> > In this case the Hornsby original goes through a firing range, Little 
> > Wobbly is a cheaper alternative to a private water taxi,
> > the other I am not certain of, possibly an 'access tack' from a train 
> > station - I would have to look.
> > 
> > Note I am not the author here of 'alternate', but I have done some work on 
> > the OSM route.
> > 
> >> 
> >> Mvg Peter Elderson
> >> 
> >>> Op 15 aug. 2019 om 01:20 heeft Warin <61sundow...@gmail.com> het volgende 
> >>> geschreven:
> >>> 
> >>> It would be usefull to document the method of  including alternate, side 
> >>> trips and access tracks to these routes.
> >>> 
> >>> At the moment I and others are using the role 'alternate' for track 
> >>> alternative paths.
> >>> 
> >>> For 'side trips' (short paths to features of interest) possibly the role 
> >>> 'side_trip'?
> >>> 
> >>> For 'access tracks' (paths from common and signed places that leas to teh 
> >>> main track) possibly the role 'access_track'?
> >>> 
> >>> 
>  On 13/08/19 18:50, s8evq wrote:
>  Hello everyone,
>  
>  On the discussion page of the wiki entry Hiking 
>  (https://wiki.openstreetmap.org/wiki/Talk:Hiking#Synchronize_wiki_page_Hiking.2C_Walking_Routes.2C_route.3Dhiking_and_route.3Dfoot_on_tagging_scheme.)
>   I have started a topic, but with little response so far. That's why I 
>  come here, before proceeding.
>  
>  
>  Currently, there are four tagging scheme tables describing how walking 
>  (or hiking) routes should be tagged.
>  https://wiki.openstreetmap.org/wiki/Hiking
>  https://wiki.openstreetmap.org/wiki/Walking_Routes
>  https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking
>  https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot
>  
>  Would it not be easier and more clear if we just keep one, and add a 
>  link to it in the others?
>  
>  Last month, I already started harmonizing these four tagging scheme 
>  tables. I changed the order, added some missing tags, adjusted the 
>  explanation etc... In my view, I only had to do minor edits. For those 
>  interested, here are my edits:
>  
>  https://wiki.openstreetmap.org/w/index.php?title=Hiking=revision=1878387=1873054
>  https://wiki.openstreetmap.org/w/index.php?title=Walking_Routes=revision=1881156=1879580
>  https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dhiking=revision=1878383=1853636
>  https://wiki.openstreetmap.org/w/index.php?title=Tag%3Aroute%3Dfoot=revision=1878384=1853797
>  
>  So these four tagging scheme tables are now almost 100% the 

Re: [Tagging] Misuse of name tag for route description

[Sarah Hoffmann]

On Sun, May 12, 2019 at 09:26:02AM +0200, Markus wrote:
> On Sun, 12 May 2019 at 00:19, Jo  wrote:
> >
> > OK, so I tested and I renamed one of the many bus routes I'm maintaining, 
> > moved from name to description. And you know what: both JOSM and the web 
> > interface now show the ref instead of the description, so until that gets 
> > resolved there is not very much chance people will want to move from the 
> > name tag to the description tag.
> 
> I know, this is why i misued the name tag, too. I mentioned that in my
> previous emails. [1][2]
> 
> [1]: https://lists.openstreetmap.org/pipermail/tagging/2019-May/045180.html
> [2]: https://lists.openstreetmap.org/pipermail/tagging/2019-May/045186.html
> 
> I'll file enhancement requests to the editors as soon as we find a
> consensus. Currently, it seems that for hiking routes, using the
> description tag instead of the name tag for route descriptions is
> undispued, but, oddly, for public transportation routes it is not.

In my experience, the course of the route is the most used descriptive
name fo nameless routes.

So, how about adding a new tag "itinerary"? This would contain a simple
" -  - ... - ". Works for simple routes (no vias) and
longer ones (two or three vias). As a data consumer, the advantage
is that it would have a semi-fixed format that is easily parsable
(for example: not enough display space? Drop the vias.)

I believe that tag would work for PT routes as well, although it seems
they would need a "headsign" tag in addition.

NB: you can already change what tag is displayed as name for relations
in JOSM. Go to "Advanced settings" and search for the setting
"relation.nameOrder". There you can state a list of tags that JOSM
should try for the display name. I've recently added 'symbol' there and
now I can finally get rid of all the "Gelber Strich" hiking route names
in the area.

Sarah


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Sarah Hoffmann]

Hi,

On Fri, May 03, 2019 at 01:24:49PM +0100, Andy Townsend wrote:
> Seriously, hoever wrote that section of that wiki page 
> https://wiki.openstreetmap.org/w/index.php?title=Relation:route=history
> must have done so out of their _desire_ that relations are kept ordered in
> OSM, not out of any observation that they actually _are_ ordered.

I haven't edited the wiki page but I'm likely responsible that it
appeared because of this post:
https://www.openstreetmap.org/user/lonvia/diary/42262

Please note the statistics at the end of the post. I actually
did bother to observe the state of affairs and I found that a
majority of routes in fact _are_ already sorted. The numbers
are from before waymarkedtrails stopped sorting routes, i.e.
they are not distored by the fact that people wanted to see
a clean elevation profile on the site.

> In OSM you need to deal with the data as it is, not as you'd like it to be -
> the nature of the project, where anyone can contribute, and they may not be
> even aware of concepts that you care deeply about makes it fundamentally the
> worst place to be an architecture astronaut (as per 
> https://www.joelonsoftware.com/2001/04/21/dont-let-architecture-astronauts-scare-you/
> etc.).

This judgement is a bit unfair unless you have actually tried to
sort routes. It's easy for the 2/3 or so routes that are strictly
linear. For everything else, it's hard. It's essentially an optimisation
problem. And no matter what you do, part of your algorithm involves
guessing what the mapper might have wanted. That is the point where
I argue that the mapping is flawed and might miss some information
that the mapper actual has at their disposal.

Here is an example of a route that is really hard to sort
automaticaly but is perfectly usable when used in the order it
appears in the relation:
https://hiking.waymarkedtrails.org/#route?id=1115137

> That's not to say that we can't try and make contributions better, but the
> way to do that is to modify the tools that people use to contribute to OSM
> not to write wiki pages that no-one reads before they start editing.

As everything in OSM, you don't need to read that wiki page and you
have the freedom to sort your routes or not. If you don't want to
bother, that's perfectly fine. An unsorted route is not wrong, it's
only less precise. Maps can show it without issues including
waymarkedtrails. It just can't give you some advanced features.

One more point:
Most editors are quite good at keeping route order these days (iD has
looong ago been fixed). But even when they get it wrong (mostly due to
complicated way splits or reversals) having routes sorted actually
means that the damage is less severe because when you stitch the
remaining parts together, the result is still very usable.

Kind regards

Sarah


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Walking Routes, how to tag alternatives/additions/shortcuts/approach tracks etc.

[Sarah Hoffmann]

Hi,

On Mon, Apr 22, 2019 at 11:47:35PM +0200, Peter Elderson wrote:
> Long walking routes often have a main route and several additions of
> various types. If these additions are not waymarked, they are not recorded
> in OSM. Easy.
> 
> But often, they are. On maps these are usually shown as a striped line,
> while the main route is usually a continuous line.

That´s actually quite similar to the problem of sections and superroutes
we had previously. They are basically sections that serve a special purpose.

> I would like to enable OSMrenderers and data users to render/process the
> additions/alternatives differently than the main route.
> 
> One solution just for rendering would be to optionally add "striped" to the
> colour tag. Or dotted.

Please don't tag what you want to see rendered. Tag the function
and then let the renderer decide how to show it.

> A more general solution would be something like alternative=yes,
> additional=yes, approach=yes. A tag that covers all the variants, I can't
> think of a suitable word.
> the other way around: main_route=no?

At the moment it is mostly done via the role. This has the advantage that
you don't need to create extra relations for short sections. Simply add
a role 'excursion' to a single way leading to that viewpoint that belongs
to the route and that's it. If the alternative is longer then it is still
possible to create an extra relation and add this with the appropriate role.

For subrelations, I'd still like to see them tagged with their function
as well, so that it is obvious that it is not a main route (and makes it
easier to render routes differently. Preferably use one tag for all of them,
e.g. route_segment=part/alternative/scenic.

That leaves the actual functions. For hiking routes there is:

alternative (1179 times)
main (945)
excursion (452)
alternate (420)
link (369)
part (310)
alternate_route (197)
access (196)
detour (150)

and a couple of others with even less use. That obviously needs some
sorting out.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] What is the role of "role=guidepost"

[Sarah Hoffmann]

Hi,

I'd argue that in most cases it is wrong to add the guidepost
at all to the route, with ot without role. They are not part of
the route they just happen to be along the side of it.

We don't add direction signs on motorways to a motorway relation
either just because the motorway happens to be mentioned on the
sign.

There are a couple of exceptions where adding the guidepost may
be valid (for example when they are official section markers
maybe even equipped with collection stamps) but then the role
is pretty much always something other than guidepost.

Kind regards

Sarah

On Sat, Apr 13, 2019 at 10:50:16PM +0200, Volker Schmidt wrote:
> I would like to see clearer on that one, as we have just launched the
> collaboration between OSM and the Italian Alpine Club (CAI). And that
> collaboration will insert a large number of guideposts.
> Anyone able to check how many information=guidepost without role=guidepost
> there are in route relations in the database (I still am a beginner at the
> level of Overpass turbo Wizard)
> 
> Volker
> 
> 
> Virus-free.
> www.avast.com
> 
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> On Sat, 13 Apr 2019 at 20:52, Martin Koppenhoefer 
> wrote:
> 
> >
> >
> > sent from a phone
> >
> > > On 13. Apr 2019, at 12:06, Volker Schmidt  wrote:
> > >
> > > But your example is different. You put the function into the name field.
> > For me the role of an object tagged information=guidepost is exactly that,
> > a guidepost.  I am sure I am missing something, otherwise it would not have
> > 50k uses.
> >
> >
> > I guess people are putting the guideposts into the relations because they
> > feel they belong to the route, and they add the role so it becomes evident
> > in the relation editor why there are node members.
> > It doesn’t seem to create problems, but it also doesn’t seem to add
> > anything (provided there would not be objects acting as guideposts that
> > aren’t guideposts)
> >
> >
> > Cheers, Martin
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >

> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Sarah Hoffmann]

On Fri, Mar 15, 2019 at 02:43:03PM +0100, Peter Elderson wrote:
> I like Sarah's proposal too, especially for walking routes. I'm not sure it
> would work for complex PT routes, where routability is involved.
> 
> One issue: a route relation can be a route on it's own AND part of a longer
> route (or node network), on any level of the hierarchy. segment=yes would
> not cover that, I think?

In that case, nothing would be needed. It is only important to know when
a relation is not a route on its own. Because then that route can be ignored
in lists or when adding markings to the map.

Sarah

> And when naming parts, you'll have to cover the case that a route can be
> part of multiple longer routes, the route itself may contain smaller parts
> that are also part of multiple routes.
> Parts can have any of the network tags.
> 
> This complication is not created by Sarah's idea, but I would like to see
> that solved too.
> 
> Fr gr Peter Elderson
> 
> 
> Op vr 15 mrt. 2019 om 14:26 schreef Richard Fairhurst  >:
> 
> > marc marc wrote:
> > > imho nearly no routing tools (nor foot nor bus) is currently
> > > able to use a relation type=route with relations as child.
> >
> > cycle.travel can.
> >
> > I don't particularly care what's decided, but I would like it to be
> > consistent (which right now it certainly isn't), and personally I don't see
> > the need for type=superroute when you can just have relations as children
> > of
> > type=route. I like Sarah's proposal for route_segment=yes.
> >
> > Richard
> >
> >
> >
> > --
> > Sent from: http://gis.19327.n8.nabble.com/Tagging-f5258744.html
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >

> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Superroutes - good, bad or ugly?

[Sarah Hoffmann]

On Fri, Mar 15, 2019 at 12:07:50PM +, marc marc wrote:
> Le 15.03.19 à 12:27, Hufkratzer a écrit :
> > is that a good/sufficient reason to define a new relation type?
> 
> imho nearly no routing tools (nor foot nor bus) is currently able
> to use a relation type=route with relations as child.
> so that's a good reason to create/improve a doc if superrelation is 
> needed for ex for routing (of course maybe some mapper need superroute 
> only for the fun of having a relation that collect all other).
> 
> for ex how a "data user" can detect "it 's a superroute" <> "it's 2 
> route with a shared segment" ?

waymarkedtrails uses the network tag as an indicator. With the
same network tag, the child is considered a segment. If the network
tag is different, then the child is considered a route on its own
that happens to be used by the superroute.

> maybe the tag network should be the same and/or the name (the country 
> XYZ may move the a scope tag)
> the main relation must/should/mustn't/shouldn't have all/some same tag 
> as the child ?
> all/a lot of child tag must move to the main relation only ? (that's 
> what we do with MP : we don't duplicate alls tags to way + relation)
> etc...

The disadvantage of all these proposals is that it is impossible
to figure out if a relation is a route or only part of a superroute
without looking at the parent. That information is much more
valuable than the information that a route is a 'superroute' (that's 
obvious anyway as soon as there is a relation member). So I'd
prefer seeing a dedicated tag added to relations that are just a segment.
'route_segment=yes', for example. Or even better, directly name the
sections, e.g. 'part=German section' or 'part=2. Etappe'. Then we can
get rid of the descriptive name tags.

Kind regards

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Status of oneway=cw oneway=ccw

[Sarah Hoffmann]

Hi,

I was pointed to the discussion from the waymarkedtrails issue
tracker. I haven't followed the whole discussion. Here's just my
two cents as somebody how processes route data.

On Wed, Mar 13, 2019 at 04:37:19PM +0100, s8evq wrote:
> > If you want to indicate the preferred direction of a walking route that is
> > basically loop-shaped, a concept that is different from the legally binding
> > oneway, then some kind of clockwise / anticlockwise tagging should be used.
> 
> Yes Volcker, this is what I'm after. It's about loop-shaped 
> walking/hiking/cycling routes, that should only by done in one direction, 
> because of way-marking and signposts.  (Most of the bicycle routes in this 
> overpass query fall in that category https://overpass-turbo.eu/s/GWB, quite a 
> lot!)
> I'm not talking about individual ways that are oneway restricted for 
> pedestrians.
> 
> 
> How to properly indicate the preferred direction of this kind of relation? 
> 
> method (1) With proper forward / backward roles on the members of the 
> relation? (as stated in the route=bicycle wiki page 
> https://wiki.openstreetmap.org/wiki/Tag:route%3Dbicycle and mentioned by 
> Volcker Schmidt and Kevin Kenny)

That's for the case where a route forks and follows different
ways for forwards and backward directions of the route. I'd still
expect both directions to be present.

> method (2) By using the tag oneway=yes, (as stated on the route=hiking and 
> route=foot wiki page  https://wiki.openstreetmap.org/wiki/Tag:route%3Dhiking 
> https://wiki.openstreetmap.org/wiki/Tag:route%3Dfoot but it causing a lot of 
> confusion here)
> 
> I have not seen anybody on this mailing list defend the usage of method (2). 
> Can I ask the question: why it is in the wiki?

Then let me defend the method. I like the simple oneway=yes
(or oneway=signed if you think it clashes with the legal
 restriction tags). It is the least hassle for a mapper.
In addition to using the tag  you need to make sure that
your members are correctly ordered in the direction where the
route is signed. Then it is also really easy to determine which
the recommended direction is, if you look at the entire
relation.

NB: There is a bit of a conflict though here between those who
just want to paint the routes on a map and those who want to
process entire routes. For the map creators the forward/backward
solution is much nicer because the role is relative to the way.
It makes it easier to simply add a couple of arrows to indicate
direction. The 'oneway=yes' is a pain because you first need to
determine if the way is forwards or backwards in the relation.
When assembling routes from the relation exactly the opposite
holds. Forward/backwards doesn't give any information about the
direction of the route the way belongs to.

So disclaimer here: I like oneway=yes because waymarkedtrails
fully processes relations.

oneway=cw/ccw might be useful for mappers to verify that the route
is correct but rather difficult for processing.

Sarah


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging