I am increasingly feeling like a parent relation type for a street would be a good idea. Our traditional model that the central highway line represents the whole street is clearly breaking down with the high level of detail being mapped these days. I still think of the central line as representing the whole street, but many others are saying it only represents the vehicle carriageway(s) where sidewalks and bicycle sidepaths (aka cycle tracks) are mapped separately. A highway can also be split up into many pieces in order to tag varying attributes (lanes, speed limit, surface, lighting, etc) and to accommodate various route relations that only follow part of the street. So we have a set of ways that each only represent part of the street and no single object that represents the street as a whole.
A relation could tie all these pieces together and specify the role each one fills. I’d imagine distinct roles for vehicle carriageways, sidewalks, and bicycle sidepaths. The unfortunate difficulty here is that relations of type=street and type=associatedStreet relations are already in use as a way to group together all aspects of a street including houses and addresses. This muddies the water about what a potential new street relation type would be. I’d want it to be a very specific thing that only includes the various routable highway=* ways that make up the street/road. Essentially similar to route relations and waterway relations.
Just yesterday created a type=street relation ** for a 15 part way, and surveying today, a few more side roads to add. Unfortunately, though I’ve been adding sidewalks and extended service pipestems, the only role OK with JOSM is street, leaving the role field blank balked at. Think sidewalk as a role was mentioned in one of the previous threads… think we could use a few more to be endorsed.
** done many, the biggest nearly 100 parts, a continuous series of housenumbers on the main carrier and side streets,
I think I would like a clear demarcation of the scope of this street object. Does it begin and end at a corner? At an intersection, are the parts of the intersection member of both streets, or is an intersection a separate object?
Are all streets supposed to be a relation, if not, when to use such a relation and when not?
My line of thinking is that the scope would be all the highway=* ways that are considered to be part of the same named street. So for a named street that is 10 blocks long then all the highway=* ways that share the same name within those 10 blocks would be included in the relation. Does that answer your question? I didn’t quite follow what you are asking about beginning and ending at a corner.
I’d say it depends on the intersection. If the ways of each street just intersect at single nodes, then I’d see no need for the ways within the intersection to belong to both street relations. In a complex intersection though, there may be ways that can’t be logically assigned to just one street. In that case adding those ways to both would make sense. Roundabouts come to mind. At some intersections, it could make sense for small sidewalk ways to be shared between the two street relations as well. When the layout is like this for example:
None of these three highlighted sidewalk segments can be attributed only one street or the other so it would make sense to include these bits in both relations. On the northwest corner the two sidewalk ways intersect at a node though, so in that spot each way could just be a member of one street relation.
I would say, like most things in OSM, it depends. If street relations were to catch on then probably we’d say it would be fine for all streets to be mapped as relations. But also for short, simple streets that can be sufficiently mapped as a single way, we’d say that adding a relation is optional.
My thought is, yeah you can do this, but it’s going to cause an awful lot of complexity and object count inflation. Would we simply be encoding spatial relationships here?
Maybe it’s time to start actually mapping multipolygons for landuse=highway, name=whatever the street is and let geospatial inference do the lifting.
My line of thinking is that the scope would be all the highway=* ways that are considered to be part of the same named street. So for a named street that is 10 blocks long then all the highway=* ways that share the same name within those 10 blocks would be included in the relation. Does that answer your question? I didn’t quite follow what you are asking about beginning and ending at a corner.
is it by name, or is the type relevant as well? E.g. if there is a residential road and lots of small traversing service roads with the same name, would they belong in the relation? Footways as well?
Is ownership or accessibility relevant (e.g. will we add private driveways?). Sidewalks?
None of these three highlighted sidewalk segments can be attributed only one street or the other so it would make sense to include these bits in both relations. On the northwest corner the two sidewalk ways intersect at a node though, so in that spot each way could just be a member of one street relation.
given that these 4 corners look all the same to me, will it depend on the individual mapper / representation where the sidewalks are counted to?
I definitely hear and feel this. More relations? Nooooo . I find myself feeling like complexity is already upon us though. The main street of my town is about 3.4km long and it is currently represented by 111 ways. 42 for the central carriageways and 69 for the parallel sidewalks and crossings. Among all these ways are members of 20 relations (10 routes and 10 turn restrictions). Adding one more relation representing the whole street here wouldn’t seem like a huge increase over the complexity that is already present. Re: object count inflation, are you referring to the relation version number incrementing every time someone adds or removes a member?
Spatial inference could certainly be another way to tackle this by mapping streets as (multi)polygons and then considering all the highway=* ways inside each polygon as part of the same street. I’m not opposed to this as a possible outcome, but it would also have some challenges to work out. For example, street polygons would have overlapping areas at intersections, bridges and tunnels. In these overlap areas it’s not obvious to me how a data consumer would figure out that some of the contained ways belong to one street and some belong to the other.
Maybe, but I’m not sure if it is really only a spatial relationship. There can be ways very close to each other but that aren’t part of the same street. As mentioned above, areas might be another way to handle the relationship between carriageways, sidewalks, and sidepaths.
I would say by name. If the type (assuming you mean highway=* tag here?) changes part way along a named street that is still one street to me, not two streets that happen to have the same name. This might vary around the world though.
I’m having a hard time picturing what this looks like.
I would not consider driveways to be part of the street they connect to, so I would not expect them to be included in a street relation. Do you consider them to be part of the street, or are you aware of parts of the world where this is the common mental model?
The exact geometry of how sidewalks intersect at corners does depend somewhat on the mapper. In this case, the reason they intersect at a single node on the northwest corner but have angled shared ways at the other corners is due to the position of the curb cuts. At the northwest corner they are close together allowing the sidewalk ways to meet at a node while keeping the angles somewhat close to 90 degrees. At the other corners the curb cuts are farther apart and if the sidewalk ways were to join at a single node it would make for very sharp angles between them.
I don’t have an extreme example at hand, but here is a fairly common similar situation:
there is this street made of these 2 ways
and then there is this other street with the same name ;-)
also here is a primary:
and nearby there is a residential road with the same name. Are these the same street?
or this one
Now I found an example for several comb like streets, the next road north to Herrenberger Straße, Gösstraße is incidentally like this, and also an example how a street can become a cycleway in the middle. All the same one street?
Well, since streets tend to vary a lot along their length, I though maybe one relation describes one section, so that the entire street is a series of street relations rather than one big sac of ways.
If it’s one relation per named street, what attributes would be in there beside the street name?
One of the possibilities of landuse=highway is exactly to show that some features can’t always be said to belong to one street only at junctions, ie corner sidewalks. It solves the vast majority of the problem between junctions at mid-block, and should be pursued first. Junctions can be solved later. type=street has a scalability problem when it tries to relate everything on a long street, meaning it can grow to become very large and diverse. For both topological and semantic purity, I too suggest nesting roadways in another type= eg =route + route=street (similar to =railway and =tracks ). This is coincidentally a request from Wiki users (for good or bad) to make it work for them, as Kartographer doesn’t support other type= yet.
Interesting examples. Not being familiar with this area, it’s hard for me to say for sure, but if people think of Herrenberger Straße as a one single entity and they think of Gösstraße as another single entity then I’d expect two relations each grouping them something like this with Gösstraße highlighted in blue and Herrenberger Straße highlighted in red:
If instead the local people view the situation as: there are several different streets named Gösstraße and several different streets named Herrenberger Straße, then I’d expect multiple relations for each.
I suppose it could go this way as well in cases where a street has several distinct sections and it makes more sense to the local mappers that they be mapped as separate OSM elements. My thought was that this hypothetical relation would represent a whole street in the spirit of One feature, one OSM element, but maybe what would be considered “one feature” might vary a bit around the world.
name would be the most common tag for sure. Others may apply to the whole named street could include:
Yeh, the only obvious benefit is that you can name the relation instead of the components of the road (but personally I think it’s better to just give the components all the same name, which hints in post-processing that they are related).
You can’t navigate between related elements (I don’t think?) so it’s not helpful from a routing perspective.
as long as people agree, there is no problem, but here I think one could ask several people and not get consistent answers. Having the same name is probably very important, so people will maybe say it is the “same” street, but they would also specify which “part” of the street they were speaking about, especially when it is about the small residential branch which then turns north (“Herrenberger Str.” means the road to Herrenberg, and I guess historically the residential part is the old road, but guess historically it didn’t turn north on the western end but continued where now is the primary).
name = Karl-Liebknecht-StraĂźe
name:etymology:wikidata = Q75886
wikidata = Q551773
wikimedia_commons = Category:Karl-Liebknecht-StraĂźe (Berlin-Mitte)
wikipedia = en:Karl-Liebknecht-StraĂźe
on this and 41 other ways (sidewalks don’t even have names there yet, so it’s really more like 100 ways), you could have them on 1 relation.
There’s not really a benefit if name=* is the only shared tag, so the majority streets wouldn’t benefit from a relation at all. But even though my first reaction is similar to yours, I have to admit that the “copy everything to all ways” approach looks worse the more shared tags there are.
Of course, better tools could make handling this duplication easier. Or better tools could make it easier to create and maintain relations. So I guess the question is which set of tools is more likely to become available and widely used.
though keeping wikidata = Q551773 tagged roads in sync would need to be implemented by one tool and handled by mapper(s) interested in this
dealing with this new relation would be something to handle by all the editors, and all the mappers
if keeping wikilinks and etymology data makes such relations needed/useful, then I prefer neither etymology data nor wikilinks nor this relations over having such relation and this data
though keeping this data and maintaining it without such relations seems preferable to either
. I find myself feeling like complexity is already upon us though. 