Proposal talk:Status

Comments from amidst the votes

(Someone removed these from the list of votes so I restored them here: )

Renderers will be actually faster, because hopefully in future other ways to express life cycle will be deprecated, so renderers rules will get simplier. --Jttt 21:05, 29 September 2008 (UTC)

I have tried and failed to find any grounding for the logic behind this statement. Perhaps you want that other universe over there? Chriscf 12:39, 1 October 2008 (UTC)

I would urge that users read the arguments on the talk page before approving. This is not efficient, not scalable, and (most importantly) not backwards-compatible. We should not under any circumstances be put in a situation where users of our maps and data have to make reference, or even are routed along, features that simply do not exist. We cannot make the assumption that all of the tools that will ever be used to display our data will necessarily be permanently kept up to date, let alone that they will interpret all features. Our data should be designed such that unknown tags can be safely ignored - ignoring this tag would be very, very dangerous. Chriscf 12:39, 1 October 2008 (UTC)

comments from voting section end here

Sorry to disagree, but life_cycle is perfectly scalable. You can add more values without breaking anything. Other keys is completely unaffected by life_cycle. If anything isn’t scalable, it’s the whole highway=disused + disused=motorway idea, because continuing this concept is impossible without getting things such as highway=access_destination access_destination=maxspeed_30 maxspeed_30=residential. I’m not going to elaborate on features with multiple major tags again, which are totally impossible with current tagging.

Secondly, you seem to believe that OSM should deliver data at fail-proof quality now. This whole idea is wrong, imo. Neither is our API stable, nor is our tagging. The attempt to avoid every modification that breaks backwards compatibility would slow down progress enormously and bind us to far-less-than-perfect decisions from the past. In fact, I do believe that tools using current OSM data need to be updated regularly.

Because how could your concept possibly work? „Our data should be designed such that unknown tags can be safely ignored“. Great – let’s abolish access=*, maxspeed=*, minspeed=*, maxheight=*, maxwidth=*, maxheight=*, disused=*, and so on. Of course you would also have to throw out oneway=*. I really find it hard to believe that you could come up with a usable tagging concept that is based on the exclusion of tags that limit a way's usability.

--Tordanik 17:22, 1 October 2008 (UTC)

maxspeed=* and minspeed=* can safely be ignored. As far as I'm aware, most tools are unaware of disused=*, but they generally know about access=*, which is officially sanctioned as the means to decide whether something is usable. If we don't know about some amenity=* tag, we ignore it, and the feature just doesn't get rendered. Tools need to be updated, but this does not mean that they will be updated. If the pool is polluted, the last thing we need to do is dump raw sewage in it. Chriscf 08:07, 2 October 2008 (UTC)

This is completly different case than the pointed article. We need something to mark disused/abandoned/in construction features. All features, not just highways and railways. I didn't see any other proposal which can do that (except life_cycle relation which is quite incovinient). If you know about some other way which won't break backwards compatibility I'm all for it. --Jttt 16:45, 2 October 2008 (UTC)

Here's a better idea: how about we don't until we come up with something which doesn't end up breaking all existing tools and services. Backward compatibility is important. We might move quickly, but not everyone else does. Chriscf 07:58, 3 October 2008 (UTC)

You mean such as using life_cycle=* + access=no? Yeah, that might work and does not break everything thanks to using the “officially sanctioned” access tag. --Tordanik 08:11, 3 October 2008 (UTC)

Try the <key>-<life_cycle>=<value> that I suggested before. Feel free to change syntax. -- Randomjunk 09:53, 3 October 2008 (UTC)

The argument used a lot here seems to be that limiting modifiers are equal to the state change caused by this proposal. I don't think this is true.

To take an example of a routing algorithm for HGVs: At the moment highway=unclassified indicates the presence of an unclassified road. So the question the routing algorithm has to ask is, "can I route an HGV down this road?". The answer is probably, "I don't really know, but I'll presume yes". So we come along and add a number of extra tags like maxspeed and width, and access (or hgv=no). Now if the routing algorithm ignores these, well, it's in the same position as it was when it started: not all unclassified roads are suitable for HGVs, and nobody ever said they were. The algorithm will need to be updated to take advantage of the extra data.

But an access/width/height/speed restricted unclassified road is still an unclassified road. A hole in the ground is not an unclassified road. A twinkle in the eyes of a passing highway planner is not an unclassified road (yeah, I know there is no life_cycle=planning proposed, but it's an obvious extension). These aren't modifiers for particular vehicle classes, or legal restrictions on use, this is an indicator that the object in question isn't actually what it says it is. It's not extra information about a road, because it isn't a road (it's either a construction site or a jungle of weeds).

Adding access=no doesn't make things much better. It doesn't even work for navigating programs which might suggest taking the 2nd right -- you probably still count no access roads in that. And lots of renderers just ignore the access tag as they're not trying to convey access rights at all. And it doesn't consider usage on other objects like pubs: a disused pub is no use to anyone but local historians, and no one checks for access tags on pubs.

-- Randomjunk 09:53, 3 October 2008 (UTC)

Disused pub on some abandoned place can be a landmark. Also the current proposal is for in construction/disused features. It's about the same as not accessible features. --Jttt 19:14, 3 October 2008 (UTC)

discussion

I like the proposal. I will probably withdraw my Proposed_features/Abandoned proposal in favour of this. --Jttt 05:20, 20 July 2008 (UTC)

A tag key 'lifecycle' might be better than 'status' as it states more clearly what is tagged. The term 'status' is used for many other purposes and mig--zorque 21:30, 20 July 2008 (UTC)ht lead to confusion. --Grungelborz 12:06, 20 July 2008 (UTC)

Indeed, 'status' is rather unspecific. I’d readily change it to 'lifecycle' or a similar term, but I’m going to wait for some more opinions/suggestions on that topic first. --Tordanik 12:30, 20 July 2008 (UTC)

I really don't like the term "lifecycle". To my north american mind, lifecycle is something that living things have. As for status being too generic, that is ok. We can load status up with more "statuses", which are keyed on the other tag being used. CoreyBurger 20:00, 20 July 2008 (UTC)

I would suggest a key roadworks or something more generic, which fits for highway elements as well, for things that are open, but can only be used with limitations due to maintenance etc. to distuinguish them from things that are (still) closed for construction

--zorque 13:42, 20 July 2008 (UTC)

I’m not so sure about this one. Of course, if there are roadworks, it would be good to tag this information somehow. However, the “can only be used with limitations” is the problem here: Does it mean “everyone can still get through, only slower”? What about roadworks that block the road for cars, but not for pedestrians? And what if the entire structure of the way changes or there are additional rights compared with the normal situation? (example: sometimes one direction of a motorway is completely blocked due to roadworks. Usually, a connection will be created that allows drivers to get to the part of the motorway that is normally reserved for the opposite direction. Therefore, a oneway=yes way temporarily becomes a oneway=no, and we’d need to draw a new way connecting the two directions…)

Would we generally keep all the other tags as they are (maxspeed etc.) and only add the roadworks info? Or would we change the other tags, too – e.g. put in the reduced maxspeed? With all that uncertainity, how is a router supposed to know what exactly the presence of a roadworks tag would mean?

The current cases (construction/disused/…) are rather clear – the object cannot be used for its original/intended purpose. Thus, for a router, a motorway that is not in_use might as well not exist. The handling of temporary roadworks is more complex, and I’m currently not aware of a solution – except maybe defining a maintenance value as completely unusable due to maintenance work and adding a new, temporary footway, lower-maxspeed road, or whatever there is to describe the situation during the roadworks.

Oh, and I don’t like the term roadworks at all, as it does not really fit anything except roads. I’d prefer maintenance or something like that. This is, nevertheless, not related to the general problems I see with that sort of information. --Tordanik 18:31, 20 July 2008 (UTC)

I'm not as pesimistic as you seem to be about that. At first I agree maintanance will be the better value than roadworks. What do the native-speakers think about that? Maybe let's allow a value maintenance and just see, how mappers would use it. I could imagine the combination status=maintenance + maintenance:motorcar=no + maintenance:foot=yes etc. Keys beginning with the status are only valid as long as the status isnt changed. There would be two ways of handling those. First: They are deleted when the status is changed, or the become inactive, but remain until the status is changed to maintenance for the next time. Don't know, but there are maybe roadworks that repeat regularly, so the tags could be used again without mapping them again. --zorque 21:30, 20 July 2008 (UTC)

The maintenance:-prefix still doesn’t solve the problem of new ways that exist only during maintenance operations, such as the ones created between dual carriageways when one of them is shut down. However, the prefix idea is fine with me, but I’d like to interpret status=maintenance as „no one can pass“ and specify the exceptions (like maintenance:foot=yes). This would be more consistent with the other values of status.

Still, if it requires more than only an additional value (which seems likely), i’d rather see a separate proposal to cover this, including all the ideas that come up during discussion and on the mailing lists would cause this one to explode, unfortunately. --Tordanik 22:11, 20 July 2008 (UTC)

I support this proposal. IMHO it is much better to tag highway=foobar status=construction instead of highway=construction construction=foobar or even worse railway=disused without any way to specify the type of the railway. I don't care much about the key name status or lifecycle. Bomm 22:09, 20 July 2008 (UTC)

I'd suggest to add a status planned to this proposal - before things get built, they are planned, and OSM lacks tagging support for anything planned yet. SvenR 22:34, 20 July 2008 (UTC)

Originally, I wanted to keep this proposal safe from “we only map things that are on the ground”-motivated attacks, but there seems to be strong demand for “planned” (also on talk_de) … I guess I’m going to put it in, but if there is significant resistance to it, I’ll take it out again and put it into a separate proposal before voting. --Tordanik 23:27, 20 July 2008 (UTC)

In general I really support this proposal. It makes it much clearer how to handle all different sorts of things as they come to live and decay again. Current solutions are not so general. However, I would reduce the number of states, as not all of them are clearly distinguishable. Especially "in_use" and "preserved" are to close to me. If it is no more in use it is disused, thats all. Same for disused and abandoned. So I would stay with only 4 states: "Planned", "construction", "in_use" and "disused" - this makes understandig this state much easier. --Kalauer 11:38, 21 July 2008 (UTC)

Someone posted a similar proposed feature a week or so ago, but the same response is probably required;

I originally proposed a status=* tag, but the suggestion at the time was that for a render it would have to scan every way checking for this tag. Any renderer without status=* support would render it as a highway open to traffic. The rendering rules were then added for either highway=construction or railway=construction with a range of associated construction=*. Note that we already have renderer support (on Mapnik) for planned infrastructure, use highway=proposed.Richard B 11:50, 21 July 2008 (UTC)

Of course, similar to how any client application without access=* support would consider access=no open to traffic. Also, this proposal aims to replace (among other things) disused=yes – any renderer without disused=yes support … well, you know. I think it can be expected that renderers are regularly updated to deal with new tagging.

Personally, I feel that the status proposal is superior compared with the highway=construction idea, because having an own tag is more intuitively readable, can be applied to every feature (stretching the idea to objects other than highways raises some problems, such as where to put the „construction“ in a building=yes amenity=*) and because new status information will never cause name clashes with existing values and keys. --Tordanik 13:14, 21 July 2008 (UTC)

Re: the access=no thingy, at least the object that renders on the map is actually there. With proposed or dismantled objects, there is nothing - yet would still render. Remember also that changing the rendering would require re-tagging existing data - unless you use both methods. Richard B 15:19, 21 July 2008 (UTC)

I don’t see whats so difficult about not rendering anything with an unknown status value – except for the period of time when the tag is still new, but this is temporary. About the re-tagging: In my opinion, if we come to the conclusion that a solution is superior, it should be used, even if tagging has to be changed for it. The long-time advantage of being able to use a better solution is more important than the immediate inconvenience of having a change period. Thus, I believe it mainly comes down to whether this proposal is a good solution or not, and that’s what should be discussed primarily. --Tordanik 16:18, 21 July 2008 (UTC)

What's difficult is that it has to be done -- for everything. Just off the top of my head, main mapnik style, tiles@home style, cycle map style, no-names style, anybody else rendering maps you don't know about, the GPS file converters (plain style, cycle style, and no-names style), any routing applications being developed... the list goes on. Now sure, if it's a quantifiable improvement to the tagging scheme it's worth considering, but this just isn't -- highway=construction and highway=proposed in my mind are much better than declaring something to be a secondary road when it isn't. There's a concept here known as "fail-safe", or "graceful failure/fallback", which I think we should follow whenever possible.

If you are worried about things being interpreted as usable roads despite being disused or under construction, simply add an access=no together with your state=* (which is implied in theory, but would help to avoid the problems you describe). As I acknowledge that there might be problems, I’ve added this as a tagging recommendation to the proposal. --Tordanik 13:20, 22 July 2008 (UTC)

But that's not the issue... The current renderers will, if you tag something as "highway=motorway" render it as a motorway. Any renderer that doesn't get updated - and there are probably many out there for various purposes - will render any "highway=motorway" as a motorway, regardless of any status= or access= tags - yet the way might not be there on the ground yet - or may no longer exist. A way tagged "highway=construction", "construction=motorway" will not render at all on any not updated versions - nothing lost because the real motorway does not exist yet. Richard B 23:16, 22 July 2008 (UTC)

But a motorway under construction or – especially – a disused motorway are objects on the ground. I’ll readily take out planned (and put it into a separate proposal), and I’d not recommend using abandoned to draw anything where there are no remains whatsoever visible. Not drawing anything isn’t closer to reality than drawing it as a completed motorway. The only problem that admittedly exists is that completed motorways tend to be used for driving, but then the problem is the same when an application doesn’t know access.

Of course, I was assuming throughout this discussion that you do consider access a legitimate tool. As it has quite similar “problems” as this one, I’m no longer quite sure about that. Still, I couldn’t find your proposal for highway=bicycle_no bicycle_no=residential yet.

That being said, trying to support every dead (that’s what “does not get updated” comes down to) application already in the rather early stages of this project will ensure that our tagging scheme becomes some unintuitive mess shackled with legacy constraints. --Tordanik 09:49, 23 July 2008 (UTC)

There was no change for more than one month. Isn't this a good time to start voting? --Jttt 18:33, 12 September 2008 (UTC)

I’m a bit hesitant about starting the voting process, because the mailing list and wiki debates suggest that this is a very controversial proposal, so a compromise would be better than a close majority decision (that would likely be only reluctantly, if at all, accepted by many mappers and developers). Based on recent discussion, I am going to try and create a proposal page for a relation based approach that would solve the most relevant problem (irritating applications) and would come with the additional benefit of supporting an arbitrary number of life cycle states together with start and end dates. I hope to get that proposal up this weekend, so we could discuss that alternative before we vote, thus making a more informed decision. --Tordanik 23:04, 12 September 2008 (UTC)

the value "preserved"

This for sure has been put in because of railway=preserved, but I think this value is wrong here from the perspective of life_cycle. What is a preserved railway? I think it's kind of a museum, with trains still being active, even having timetable service. Those museum railways might look "preserved", but are required by law (at least in Germany) to conform to all normal regulations of railway traffic. So even if the trains look old, there is no technical difference between "preserved" and "in_use".

The same thoughts apply to other things. What is a preserved street? Either it is a street that can be used - then it is "in_use", maybe with restricted access. Or it is broken, demolished etc., so any other life_cycle value applies. What is a preserved building? Either it is a building that can be used, or it is somehow ruined. The value "preserved" does not fit well within the other values.

If a usable infrastructure has been turned into a museum, it should be tagged as a museum somehow. For railways, the value "preserved" refers to a certain kind of old railways, often powered by enthusiasts, which does not fit into this tags values. SvenR 14:23, 15 September 2008 (UTC)

While the use of "preserved" is not usual for ways, it is relevant to many structures (e.g. a converted railway station, a church not in normal use...) and as such is perfectly appropriate. One might want to visit a church, even though it's not used as one anymore. Circeus 21:06, 28 September 2008 (UTC)

new proposal and comparison page

I’ve created an alternative proposal draft at Proposed_Features/Life_cycle_relation – I do not necessary think that it is superior in every aspect, but I wanted to show and discuss all possibilities first to prevent prematurely settling on an inferior solution. Also see the Comparison of life cycle concepts I created to clearly lay out the topic. --Tordanik 18:53, 14 September 2008 (UTC)

name: life_cycle vs. operating_state

Ok, last question before I’m going to put this out for voting: Someone on the lists suggested operating_state as a better name for the key. I’d like some quick opinions about name preferences. --Tordanik 17:48, 19 September 2008 (UTC)

Just go for the simplest: current_state? Circeus 21:02, 28 September 2008 (UTC)

Current state implies that the data is not out of date... you can't rely on that. --Lulu-Ann 12:11, 30 September 2008 (UTC)

Effects on renderers

I think this proposal will make it a lot harder to render OSM data. It will no longer be possible to render, for instance, highway=secondary. You will now need to check for highway=secondary, with either life_cycle=in_use or life_cycle missing. This is making it harder to use the data, and not a good idea. Gustavf 15:56, 29 September 2008 (UTC)

• It is already impossible to ignore tags associated with e.g. a highway=secondary when rendering a map, because doing so will severely mislead the user in every situation where there is something like access=no.
• With life_cycle a renderer will need only one additional tag. Currently, map features require it to watch out at least for the approved disused=yes tag (besides highway=construction, of course) – voila, there you have your second tag to watch out for. This even ignores other tags in the same domain (construction=yes, abandoned=yes, …).
• Depending on renderer architecture, something as simple as a filter for life_cycle=* might allow you to throw out possible problems without serious performance hit (linear operation). Otherwise, adding a pattern similar to access to the rendering will do it.
• The only tag-based solution that wouldn’t require renderers to take more than one tag into account is highway=construction, and that one cannot be used for all features, so it is not a possible universal solution.

--Tordanik 18:04, 29 September 2008 (UTC)

You've missed a few key points here:

• Ignoring an access tag just means you're not making claims about access rights. Ignoring the "life_cycle" tag might mean the object doesn't actually exist. This is a completely different order of magnitude.
• 1 tag/5 tags, it really makes no difference as long as I know they exist. You'll notice how few things pay attention to the disused tag. I didn't even know it existed as it's obviously been created since I last tried to read everything on Map Features. It's this kind of crap that needs to not happen. highway=construction was a specific solution to make someone happy without doing something silly with a tunnel to make the map look nice.
• I can filter out life_cycle objects as long as I know the tag exists. Which any current renderer/router/gps map creator won't. You're not asking us to change the front page render here, you're asking us to change at least 4 renderers for the front OSM page alone, plus at least 3 routing projects, plus anyone making Kosmos rules, and anyone else using OSM data that you don't even know about.
• well, what about doing "<tag>-<life cycle status>"="<standard tag value>"? ie: highway-disused=motorway, highway-construction=motorway, amenity-disused=pub (just ignore the in-use value as it's default)

--Randomjunk 11:14, 1 October 2008 (UTC)

• life_cycle and access (as well as limits to height, widths, minimum speed and so on) have very similar effects for the map’s user. He sees a street on the map, but might not be able to use it. Whether this is due to traffic signs, a barrier at the ends or a construction site is rather irrelevant. I also think that a street under construction is very different from a street that “doesn’t actually exist“.
• It does make a difference whether knowing a single tag will be enough to cover a whole category of information or whether adding a new variant will break everything again. The first is the case for life_cycle, the latter for disused=yes, abandoned=yes etc.
• The problem that nobody knows the tag is temporary. The benefits are permanent. Besides, routing applications that support access will not be affected right now if people add access tags as a fallback – which is explicitly recommended. The same is true for renderers.
• I don’t see severe problems with your proposal. Still, I’d much rather create a renderer that looks for a second tag and places a pattern on all ways with life_cycle=* than one that requires all that string splitting/parsing. Using a dash wouldn’t allow you to globally apply rules to all life cycle states due to the lack of a guaranteed key. I consider it less intuitive, too, as additional attributes are commonly added with additional tags instead of modifying existing ones. Finally, your method also wouldn’t really work well when you tried to use it on anything other than life cycle information, such as access, but you are probably aware of that.

--Tordanik 16:59, 1 October 2008 (UTC)

I guess you're talking mainly about Kosmos here. Both osmarender and mapnik can handle life_cycle quite easily in one place. I think if this get approved then renderers will get native support for life_cycle, like they need to have native support for ie multipolygon relation. So you will able to use set some option like "drawOnlyFeaturesInUse=yes" and then use simple highway=secondary as you do now. --Jttt 07:30, 4 October 2008 (UTC)

Changing one line will not work for Mapnik style/layer rules. E.g. look at how the tunnel tag is implemented. --Cartinus 16:49, 4 October 2008 (UTC)

Mapnik doesn't work directly on osm, it use database. Import script can be modified to ignore unknown life_cycle values. I'm not really a mapnik expert but I think it should be possible to select only tunnels in "tunnels" layer and then remove check from all tunnel rules. --Jttt 17:06, 4 October 2008 (UTC)

You can ignore unknown life_cycle values, and then you get non-existent rights-of-way shown as in use and interpreted as routable. Chriscf 16:53, 5 October 2008 (UTC)

This is probably a misunderstanig. I was trying to say you can ignore elements with uknown life_cycle values. So for example you won't have elements with life_cycle=disused in mapnik database at all.

repairs

I am missing state for things being repaired - there are two "types" of repair. In one, the object in question is closed completely for some major reconstruction (perhaps we can mark that as construction), in second the object can be used in some limited way (only half of the road is closed, only part of shopping mall closed, etc ...) . Is this worth two extra states (life_cycle=repaired_open, life_cycle=repaired_closed) or maybe only one (life_cycle=repaired, assuming "repaired while still somewhat functional") --Bilbo 20:58, 6 October 2008 (UTC)

Reverts

What's the objection the wording that was removed by this revert: diff ? To me it seemed neutral and exact. Alv 09:29, 13 November 2008 (UTC)

What's the objection to the previous version? Chriscf 10:21, 13 November 2008 (UTC)

Striking out others' opinions, mainly. Alv 11:40, 13 November 2008 (UTC)

"{{vote|yes}}" is not a statement of opinion. Chriscf 12:00, 13 November 2008 (UTC)

To me any vote is exactly a statement of opinion - voting is needed when facts don't suffice. I.e. "I think this is the best choise" Alv 21:02, 13 November 2008 (UTC)

So, do you have any valid objection to striking out an invalid vote? Chriscf 08:58, 14 November 2008 (UTC)

Yes, the fact that the vote is not invalid. If enough people think this feature makes sense after all, (Which I personally hope will never happen.) it will make it onto the Map Features page and will no longer be rejected. --Cartinus 23:59, 14 November 2008 (UTC)

A vote cast a whole month after the polls close is invalid by definition. Chriscf 09:07, 17 November 2008 (UTC)

The vote is no valid, the Status is still rejected. Anyway Lulu-Ann can still express agreement with the proposal and if more votes like this appears we may start a new voting. --Jttt 12:11, 17 November 2008 (UTC)

And nothing I've done changes this. Chriscf 09:26, 18 November 2008 (UTC)

The point is you make it look like Lulu-Ann's vote is no longer valid. That's what this is used for. The other way is much clearer. Also if you keep changing it, you should at least invalidate Firefishy's vote as well. --Jttt 18:08, 19 November 2008 (UTC)

It looks invalid because it is invalid. Chriscf 09:50, 20 November 2008 (UTC)

NO LONGER is the keyword here. The striking would be correct option if Lulu-Ann changed her mind. --Jttt 06:18, 21 November 2008 (UTC)

"No longer" is not the keyword here. The vote is not, never was and never will be valid. Chriscf 12:04, 21 November 2008 (UTC)

If four people disagree with you and nobody agrees with you, then it might be time to look in a mirror for some self reflection. --Cartinus 23:50, 18 November 2008 (UTC)

Again, do you have a point here? Chriscf 09:15, 19 November 2008 (UTC)

The tagging proposal part of this wiki is about working together to try to find tags that as many people as possible can agree on. For this process to work people have to listen to and respect other peoples opinions. One of the ways people express their opinion is by voting. This process is not helped by someone striking out other peoples opinions. And it is certainly not helped by one individual constantly modifying a page to a state that no one else interested in that page agrees with.--Cartinus 00:38, 20 November 2008 (UTC)

Who said anything about not respecting others' opinions? That's why the vote is struck and not removed. Chriscf 09:50, 20 November 2008 (UTC)

Chriscf, never again change my entries I have signed. What you do is simply forgery of documents. --Lulu-Ann 23:39, 22 November 2008 (UTC)

You missed the voting deadline. Deal with it. Chriscf 09:08, 24 November 2008 (UTC)

I was aware of it, and I don't complain about the result of the voting. I complain about you editing my signature. --Lulu-Ann 22:10, 24 November 2008 (UTC)

If you were aware of the long-passed deadline, then you must accept any consequence of this. This includes a visible indication that your vote is excluded. Your signature remains intact. Chriscf 15:23, 25 November 2008 (UTC)

It's probably more productive if you (Chriscf) learn to deal with the fact that nobody here agrees with with what you are doing. --Cartinus 04:35, 25 November 2008 (UTC)

You don't have to agree with it, because I certainly don't need your agreement. Being in a majority doesn't mean you're right, and doesn't give you the right to harrass users you believe to be wrong. Chriscf 15:23, 25 November 2008 (UTC)

Striking out votes does not directly help the reader of the page to find out why they were invalid -- most importantly they could also have been removed by their caster (it is common at least on Wikipedia to remove votes like this when the voter's opinion changed). Explicitly creating a section explaiing that those votes were late does show the reader both that these votes weren't counted and why. So I don't see any disadvantage of that option -- and that makes it the way to go, not majority. You also have not explained so far why you do not strike out Firefishy's vote as well. I hope it isn't because he shared your opposition of the proposal? --Tordanik 20:34, 25 November 2008 (UTC)

"Striking out votes does not directly help the reader of the page to find out why they were invalid ..." Of course, they'll have no idea why the vote was invalid. I mean, it's not as if the comment "voting closed a month ago" in any way explains it ... Chriscf 10:14, 27 November 2008 (UTC)

Making this proposal live again

I have a few --too late-- comments to say that would probably need this proposal to re-open. Sletuffe 01:23, 27 November 2008 (UTC)

Form

• 15 days for a voting period is far too few, I was not even aware it existed (aren't people allowed to go on holidays ?) 3 month seams to me a rather better choice.
• Votes were striked out, since that might change the issue, and the problem that went after that, we probably could start again
• Suspicion of cheat ? whaou ! from people with absolutely no objections in nothing than less 10 minutes, looks rather strange.

Sletuffe 01:23, 27 November 2008 (UTC)

OSM is not a democracy. The vote is indicative, not definitive. It doesn't need to be kept open for anywhere near 3 months. 2 weeks is fine as a rough gauge of opinion - the discussion is more important. Chriscf 10:23, 27 November 2008 (UTC)

Two weeks is the current suggestion on Proposed features. It's true that this might not be ideal, especially as discussion is more important than voting -- because apparently, once voting is over, there is no longer any discussion, but rather pointless edit wars about striking of votes. --Tordanik 20:03, 27 November 2008 (UTC)

One more proof that it wouldn't have happen with a 3 month period vote. ( And I could have voted or discussed on it) Two weeks is a suggestion, nothing prevent from using 3 month, and overall in a case like this where it is not easy to find a consensus. Since this edit war (where Chriscf is implied... ho ho ?) is useless, a re opening might me needed. Well at least if my new arguments make sense to at least a few people. Sletuffe 22:16, 27 November 2008 (UTC)

Content

• That proposal is clearly missing a Deprecate zone. construction=* that is accepted looks horrible, un-extensible and seams to have the same defaults
• ( same for other mentioned)

Sletuffe 01:23, 27 November 2008 (UTC)

Big problem that has been spotted

The main problem, to make a summary is : "how will a routing/renderer program make difference between a way that is usable and a way under-construction"

Cons :

• First is : it has to look for the tag... Well construction=* and friends have the exact same problem, merging them all in one will likely help in the future.
• Second is, too many programs to change : that is not completely true, most programs takes advantage of other to export the osm data (osm2pgsql & Osmosis) thus, just making them add a "access=no" will do.
• Last but not least, the one argument in favor, that no one has raised before :

Have you ever seen a construction way or disused way that is connected to the real traffic ? The answer is almost always "no", because for security reasons, it is always kept apart. Either with a barrier, or with a missing peace of road. And what are the general rules in osm tagging for something that is physically separated from another way ? Leave a hole or put an access=no or but a barrier. And what if someone just "forgot the barrier or the hole" ? then the mapping is wrong, and this is general to osm and not particular for this proposal, so there are no reasons to blame it for that.

Our routing problem is solved

• I approve this proposal. Sletuffe 01:23, 27 November 2008 (UTC)

construction=* needs no extra work - the procedure is to set primary tag=construction (e.g. highway=construction or railway=construction), which "guards" the feature from unknowing applications. For many target uses, knowing that this is there isn't necessarily that important. This proposal supports a "real" primary tag (e.g. highway=trunk), meaning all of our existing applications will break. We can't rely on the rest of the world to keep up-to-date. As for construction connected to real traffic, happens all the time - I drove past two on my way to work this morning. The "physical separation" between the new road and the open roads is highly temporary, and tends to move on a daily basis. Remember that the intent of the "construction" tag is to tag something under construction, along the path where it will eventually lead. The presence of any temporary separation doesn't change this. There is no need for a "barrier or hole", because the mapping would be wrong if someone inculded them. Chriscf 10:36, 27 November 2008 (UTC)

construction=yes, disused=yes etc. do need extra work -- and some of these are approved features. highway=construction, on the other hand, is not usable on things with more than one major tag. It also is conceptually weird and quite different in use from other tags. But we had those arguments before...

Also, I have always tried to point out that there is no added difficulty for users of the data if we use access tags or barriers in addition to life_cycle, which was explicitly recommended on the proposal page. This fact has largely been ignored by opponents of the proposal.

Probably, it would be worthwile to try proposing on this again (we might discuss switching to operating_state, as preferred by some users). As a compromise, we could explicitly focus on non-highways, and explicitly try to replace *=yes (rather than highway=construction) first -- I'd think that this proposal should at least be superior to those, as they share the first-level-key concept, but require more maintenance and are less easily extensible. --Tordanik 20:03, 27 November 2008 (UTC)

They don't need extra work. If an application doesn't know *=construction, it ignores it, so the feature mostly doesn't exist. This proposal is almost the same, except that unknowing applications are not protected. Chriscf 09:13, 28 November 2008 (UTC)

Have you ever read Key:disused? It says nothing about changing the value of the main tag (e.g. highway). You use it exactly as this proposal, except that instead of writing life_cycle=disused, you write disused=yes. I explicitly tried to distinguish between the two existing tagging schemes in my answer: a) disused/construction/...=yes without changing any other tag and b) highway=construction construction=highwayvalue, with the first sentence referring to a) and sentences 2+3 referring to b). --Tordanik 09:37, 28 November 2008 (UTC)

That argument reeks of adding sewage to an already polluted pond. Chriscf 13:02, 28 November 2008 (UTC)

So what's your way to deal with the pond? Mine is to try and exchange the polluted waters with cleaner water. You appear to stop others from bringing cleaner water, pointing out its inferiority to hypothetical 100 % pure water -- even if it would be better than what's currently there.

In other words: Of course this proposal has its flaws, but it's the least flawed universally applicable (i.e. not highway-only) concept I've seen so far. --Tordanik 16:33, 28 November 2008 (UTC)

"least flawed universally applicable" - i.e. it's still sewage. Chriscf 10:01, 2 December 2008 (UTC)

To make this a little more clear, there are tags in existence that are bad or broken. There is little we can do about existing breakage, but this proposal introduces new breakage. Chriscf 17:27, 2 December 2008 (UTC)

Re-open or not

It would be great if this proposal was rescued. What should be done before the voting starts again? I think we should make a page where would be explained some common objections from this page in shorter and clearer way than in the discussion. Anything else?--Jttt 19:21, 29 November 2008 (UTC)

I'm in favor of, given cons and pros, I start thinking it's not gone be perfect, but still, it worth doing it. It has been suggested that re-opening would need to create a proposal like Proposed_features/Status2 so that we know it's version 2 and we start from a new clean sumary of keys, values known objections and cons, and known advantages Sletuffe 19:41, 29 November 2008 (UTC)

You could move the previous page to, say, Proposed_features/Status/Archive (which preserves the history) and then recreate Proposed_features/Status (with the summary and a link to previous discussions). But I'd rather have a proposal and discussion on the form disused:highway=* (and planned:highway=* etc.). Alv 06:34, 5 August 2009 (UTC)

After much time for thinking, I withdraw my opinion. I wouldn't vote yes on that way of doing because breaking compatibility of renderer that don't support the additionnal tag. The Alv proposition of using disused:highway=motorway instead of highway=motorway + whate_ever_tag_to_say_disused=yes looks much better Sletuffe 11:06, 5 August 2009 (UTC)

I'm also in favor. It seems like the biggest problem is backwards compatibility. Maybe we should start with deprecating disused=yes for life_cycle=disused, get that approved, and go from there since I don't think too many renderers support disused=yes. Once the renderers start parsing for life_cycle=disused then it's a small change to parse for life_cycle=construction instead of *=construction. I think using a bot to change all of the tags at once is the best way to go; renderer maintainers are more likely to see that something deprecated no longer exists if everything breaks at once.--Elyk 05:11, 5 August 2009 (UTC)