Proposal talk:Segmented Tag

Comments

• If I have two different speed restrictions for different directions on an segment, I have to add to relations to it. Can we assume that maxspeed directly on way, and only one relation with directed maxspeed means the same as two directed speed restrictions? --Slimak 11:25, 10 February 2008 (UTC)
  • Yes, I think that the "default" tags can be given as usually, and additional "Segmented Tags" will overwrite the default values. For Germany you can tag a way outside city limits with maxspeed=100 (km/h), and if parts of this way have another speed limit, add Segmented Tag relations to this way. --BerndR 09:21, 11 February 2008 (UTC)
• How would this work with conflicts? For example a segmented relationship indicating maxspeed=100 for node A through D and another for node B through E at 120?--Bartv 16:34, 11 February 2008 (UTC)
• This to me is a problem with the editor. There should be a way to select individual segments and groups of segments withought splitting them up. The only example of this is http://www.wikimapia.org road editing feature, but it is not as defined as OSM. --Nickvet419 07:59, 16 June 2008 (UTC)
  • There's nothing the editor can do if there is not a way to store this information on the server. You can't do this on the editor because there is no convention agreed upon for storing tags about sections of ways (well, actually there is a convention today: splitting the ways  :). --Ehabkost 13:29, 16 June 2008 (UTC)
• I agree on this proposal and I urge to begin to implement ASAP because I really dislike to have to cut a way and moreover to duplicate DB entry for name of ways. Emilio 11:56, 22 June 2008 (UTC)
• I agree on this proposal although it needs to made very clear what happens to default tags on the way and when they collide with tags on the relation. The allowed tags on the relation need to be very generic aka maxspeed, oneway, access (yes - we have access restriction e.g. access=destination which happen to only exist when entering the street at one end), bridge, tunnel. --Flohoff 10:52, 23 October 2008 (UTC)
• Could the ways role be "via" or something? Makeing this empty sounds broken. --Flohoff 10:54, 23 October 2008 (UTC)
• I think thats a brake of data structures. Working with bike routes, we use relations as a parent element; now using it as a child element will not pass normalised data structures. Especially we'll get problems, when ways are divided within the segment. How will we secure data integrity at this point? --Wolfgang_Wasserburger 06:22, 3. December 2008 (UTC)
• I agree on this proposal and think it is truly urgent. Any tag appearing on such a relation should supersede a tag for the whole way. The name for the whole thing, "Segmented Tag", does not sound like a good name for a relation. I would rather suggest "Way Segment". --Mink 18:15, 16 December 2008 (UTC)
  • I would suggest just "segment". --Cohan 12:02, 18 August 2009 (UTC)
• I agree that we need something like this to allow for attributing portions of a way without breaking the way into lots of smaller ones. This would be useful in data import projects where you want to keep a reference to the source object id that the data came from but don't want to have subdivided roads into lots of small ways just because that is how the data source did it -- Stevens 03:06, 22 January 2009 (UTC)

work for relations in addition to tags

This proposal would be useful for streets with many bus routes with different entry/exit points: each section of the street need to belong to a different set of route relations, to make it work. So I propose we extend this proposal to use the same approach to allow relations refer to segments of ways. Maybe renaming it to "way section" instead of "segmented tag" would better reflect this. --Ehabkost 19:39, 15 June 2008 (UTC)

direction=negative

I fail to see the use case for direction=negative. In what cases would one use direction=negative rather than just switch the "from" and "to" nodes? --Frederik Ramm 22:56, 16 July 2008 (UTC)

I second that. If i understand this proposal correctly, each direction needs a different relation, so "negative" isn't needed.

But just one spontaneos, not-thought-through idea: Wouldn't it be nice to be able to describe a 2-way-different-maxspeed with just one relation, with something like direction_negative="tag", direction_positive="different_tag"? In other words, to provide the option to enter a condensed direction+tag-construct (additionally to the proposed way). --Linse 10:54, 17 July 2008 (UTC)

I see the use for direction=both and forward (which should be the default) but i dont see the need for negative. One would exchange from and to --Flohoff 10:43, 23 October 2008 (UTC)

I think that allowed values should be "forward", "backward" and "both". Note that route relations (bus routes, etc.) already use "forward" and "reverse" as "role" for "ways" making up the route. I believe these values are easier to understand. Naturally, be arranging "from" and "to" in a logical fashion, then perhaps "backward" does not really need to be used. But there can be moments when you may be unsure about re-tagging existing work done previously by another mapper: some experience is needed to understand all the consequences of reversing the basic definition of a relation, and so it is safer to just set "direction=backward" and move on to something else, if you are not sure. The tags can be simplified later, so as to use "direction=forward" instead, but only by someone with the experience to know what to look out for and what else to change, and the time to make those needed verifications.

--Neil Dewhurst, Lyon France (talk) 09:04, 25 July 2014 (UTC)

house numbers

This is a nice way to specify house numbers in places where interpolation works. Just have a tag with the starting house number for the first node and the ending house number for the last node and another that shows which side is even. --Zorko 01:29, 19 August 2008 (UTC)

I have tried to write together something on talk-de about this something like from/to/via and then one needs the notation and left and right so i'd propose something like left:number=50,54,even and right:number=51,55,odd --Flohoff 10:45, 23 October 2008 (UTC)

Isn't this already supported by Karlsruhe Schema? --Cohan 12:50, 18 August 2009 (UTC)

Node from/to n times in way

How is this relation defined when from/to are part of the way more than once? --Tordanik 12:48, 17 November 2008 (UTC)

My spontaneous feeling is that multiple from/to is a bad idea. While still working if there are exactly the same number of from and to nodes, it would be a terrible headache for human readability (i.e. editing) and therefore imo should be concidered an error. --Cohan 12:57, 18 August 2009 (UTC)

I'm no longer sure which example I had in mind when I formulated the question, but it is about nodes that are in the way more than once (such as the first/last node of a circular way), not in the relation. --Tordanik 14:35, 18 August 2009 (UTC)

Abandon this proposal

I think this proposal should be abandoned. I see three major problems:

1. It is unnecessary. Everything that can be modeled with this proposal can be modeled without it. You only add to confusion by introducing alternative way to do things. This is always a problem for mappers (which is a right way to model the data?) and for software using the data (must support all alternatives).
2. You work against other current proposals and features that actually require ways to be split. For instance Relation:route, Relation:restriction or Relations/Proposed/Destination_Signs. And you represent diametrically opposite proposal to Relations/Proposed/Collected_Ways. If any proposal deserved to be labeled as "misuse of relations" this one does.
3. Lacking editor support. Adding such relation is not a problem, you don't need editor support for that. But what will happen when someone splits a way in relation. You will end with relation that contains two or more ways. Either you will have to change proposal so that relation allows multiple ways or appropriate editor support will be required, to split a relation when member way is split. I guess first solution would be better. Second solution is far more complex and would simply substitute way fragmentation for relation fragmentation.

--Blaz 08:14, 20 September 2009 (UTC)

I agree with Blaz. Everything you can do with this proposal you can do without it. The only reason for this proposal is the nicer look of the map, wich is not a problem of the data but of the renderer.

--T3QU1LA 16:50, 10 November 2009 (UTC)

About the three major problems:

1. But if this model makes things better then how it is now it's hardly unnecessary. And if this is made to a superior way of entering the data there won't be much confusion.
2. (All of) those relations were proposed/created when relations could not have other relations as members. Since the new API allows for that there is absolutely no problem to have a relation=segment instead of a way as member in a e.g. Relation:route.
3. While the point of this relation is that the way should not have to be split that still has to be taken care of when it happens. But how is this different from when someone splits a road in a Relation:restriction or Relations/Proposed/Destination_Signs? Should those relations be abandoned as splitting a way breaks them?

--Cohan 19:43, 1 July 2010 (UTC)

Multi-way Editor Support as alternative

Attributes apply to things at different scales. At large scale is a long way that has one name. At smallest scale is one segment that is a bridge, or a segment that is part of a route relation. These same segments may be part of other route relations that cover multiple segments. Having the way chopped up into small pieces makes changing any attribute that applies to multiple pieces very awkward (in potlatch at least). Think about renaming a way that has 20 subsections.

I wonder if editor support for selecting multiple ways would help avoid the need for this proposal? Plus the ability to select ways sharing a name, or sharing certain attributes (eg name + relation). This would allow operating on the larger scale items while still using way-splitting for the smaller scales.

--EliotB 01:40, 19 December 2011 (UTC)