Talk:Deprecated features

From OpenStreetMap Wiki
Jump to: navigation, search

boundary=national_park and aerialway=drag_lift

what is wrong with boundary=national_park and aerialway=drag_lift? Walley 17:01, 30 August 2007 (BST)

There is nothing wrong with boundary=national_park. It is currently in use more than 750 times in Europe alone according to tagwatch. Since there is also no alternative nor a reason given for its depreciation I'll remove it from this page. --Cartinus 21:56, 1 November 2008 (UTC)

According to Proposed_features/Power_Lines#Votes_4 power=line isn't deprecated. 21:12, 12 October 2007 (BST)SaschaR

Does anyone have or remember a reason why the tag lit=* has been added to this list in July 2007? It's still in the list of Map features and I couldn't find any reasons for deprecation, not from this Wiki nor the mailing list archives. In few days I will remove it from this list unless given some reason why it should be here. Alv 18:19, 6 March 2008 (UTC)

User:Hawke today updated description of why the abutters are deprecated. Page Key:abutters is not marked as deprecated, abutters are still on the Map_Features page. I tend to follow the current tagging "best practice" - but this is very confusing to me --Dido 20:39, 22 January 2009 (UTC)

[diff from march 19, 2008] also edited by Hawke, changes deprecation of abutters=mixed to more general abutters=*
I do not recall whether it was my intention to change that. It looks like that change was mostly intended to change to using the Tag template, and that change may have been accidental. I know there has been discussion in the past of problems with abutters. But if someone wants to modify it back to abutters=mixed that's fine by me. --Hawke 22:03, 22 January 2009 (UTC)

URL vs. Website

Looking for consensus to add url=* to the list of deprecated features, per content at Key:url. --Ceyockey 03:40, 8 July 2011 (BST)

I'm ok with this Ogmios 10:50, 15 July 2011 (BST)

sorting unclear

Should this table be sorted via date or Old Key/Value? :-) --Zuse 19:28, 21 December 2011 (UTC)

OpenStreetMap does not have "deprecated features"

Errr.. Stupid question: Why does this page state that "OpenStreetMap does not have 'deprecated features'" and then go on to list them? Isn't there a better way of explaining this at the top? -- Harry Wood 11:17, 15 February 2012 (UTC)

That's quite an old question, but the issue remains. Isn't the real problem here, not that the text is unclear, but that different people interpret "deprecated" in different ways. To most it means "discouraged because a better alternative has emerged" (which the opening paragraphs explain reasonably well). but to some it means "banned: this tag is a candidate to be removed through a mass edit" (which is what the opening statement tries to address). It is unlikely that anyone has the energy to reconcile these differences in general. So rather than trying to redefine "deprecated" what about creating two sub-pages here. One for the extreme case of any tags that are "banned and candidates for removal". The other aimed at contributors who want a quick run-down on "tags that have been superseded by better alternatives". My own view would be that initially the first sub-page should be empty, and any tags in the table that still exist in the database should be added to the second. Perhaps that would be more clear, and help build consensus around more rational classification in future. --Peter Reed 14:39, 29 August 2012 (BST)

Highway=ford

Could we have an explanation of why this is shown as deprecated? See also ford=* and highway=ford --Peter Reed 13:14, 28 August 2012 (BST)

One explanation is that highway=ford can only be used on nodes and not on ways whereas ford=yes can be applied to both. --Scai 07:26, 29 August 2012 (BST)

Scai - I understand that ford=yes has some advantages over highway=ford, particularly where a ford is large enough to be represented as a way. I think it is a good addition, and I have used it myself. What I don't get is why that means highway=ford should be deprecated. It is widely used, and convenient, and I don't see any problems in leaving it in place for small fords, which are represented by nodes. Deprecating has side effects, and unless there is a good reason I would prefer to see an approach that recommends ford=yes without deprecating highway=ford.

We should probably add a better description of what it means for a tag to be 'deprecated'. As already pointed out by Harry Wood there is no real deprecation in OSM and additionally you are even encouraged to use any tags you like. So it is no real problem for old objects to be still tagged as highway=ford and any tool looking for fords has to look for both tags anyway. You could even use highway=ford for new objects. Nevertheless ford=yes has some advantages as you noticed and consequently it should be preferred over highway=ford when adding it to new objects. Also any tool offering you tag presets has to decide which of the two tags to prefer and because of the advantages they should prefer ford=yes but ideally also understand the other version and maybe even offer to convert the old one into the new one, like JOSMs validator currently does. Yet there is no real problem with the older tag as long as you aren't using it on ways. --Scai 12:41, 29 August 2012 (BST)
It sounds as though we are in agreement, and have a common view of what "deprecated" means. I suspect Harry Wood has a similar view, and I know others do. Unfortunately, some do not share that view. They interpret "deprecated" as meaning "should be removed from the database". I can't see this being a huge issue with fords, but it is elsewhere, and might cause problems with fords that we can't foresee. So my suggestion is that highway=ford is removed from this page, and that (in the relevant pages) the ford=yes form is encouraged, and the highway=ford form is documented, but discouraged - with an explanation. In the spirit of Wiki editing, it's probably best to wait a while before changing anything - to see if there are other views. --Peter Reed 12:56, 29 August 2012 (BST)
My opinion is, that one tag is enough for exactly the same thing! I would vote for a transformation form highway=ford to ford=yes in the whole database. And if it's done, then someone can write it here to deprecated features, so every interpreter can handle this "new" tag. --MasiMaster 19:38, 29 August 2012 (BST)
What stops interpreters handling the new ford=yes tag now? Surely anything along the lines of "where ford=yes or highway=ford" would do it. Or am I missing something? --Peter Reed 20:21, 29 August 2012 (BST)
Nothing! But it is easier for all, to use only one tag. How can the interpreters see, that there is a new tag? Is there any page like "New/changed tags"? Now we have 2 similar tags, what about 3, 5 or 10 similar tags? It needs too much resources to ask for many similar tags. And it provoke that interpreters miss one or more tags. That makes the data inconsistent. Furthermore, mappers can be inspired to use the "old" tag. Or let me ask, why is it better to use more than one tag? --MasiMaster 13:12, 30 August 2012 (BST)
Maybe I should first restate that I am in favour of the ford=yes form, because it is simple, widely applicable and allows more information to be added alongside. I also think there are advantages in giving contributors one set of guidelines, because that makes life easy for them, and this should be it. I also see no problem with people changing individual fords from the old form to the new, in the spirit of OSM, as they see fit. What I am opposed to is a mass removal of the existing form. It has already been widely used and is already supported by renders. I fear that, however we interpret the "deprecated features" page, that is what will end up happening, because others see it as a useful database simplification. I have two issues with this. One is that mass edits very often have unexpected side-effects. Even when they are used properly, the mechanisms for discussing them are too fragmented and too transient to build a proper consensus. And the result is that contributors get upset, changes have to be reverted, and there is frustration and confusion all round. My second reason is that at last processes for introducing new tags are working well. This proposal, for example, is well thought through, adds value, seems well designed, and so on. Introducing it, documenting it properly, encouraging use by contributors and renders all add value and move things forward. I doubt if anyone has objected, or would object to it being added. But removing an existing tag often turns out to be destructive. If the pressure to remove old variants alongside introducing new ones was challenged more often I think it would help avoid conflict, and hence move consensus forward - to the benefit of everyone.
On this issue of "how many" options, we are only talking about two forms here. Any more than that is hypothetical. But there are already numerous examples where data users have to cope with at least two variants. Is there an upper limit? I imagine there is, but it isn't "one". Of course "one" is always going to be easier than "more than one". But in most cases the practical difference is marginal (if they truly are equivalent). It has to be balanced against the other costs of cleaning the data. In my own experience of using OSM data, I can often find a large number of tagging variants for a particular type of feature if I do a through search. But the most popular form normally catches the majority of cases. Any variants after the second tend to pick up only a small number of cases, so it's unusual for me to process more than two or three variants. Missing data gives me more problems than obscure tags.
And is there a "new / changed tags" page? Not that I am aware of, but I wish there was a page that covered "tag equivalences" - for the benefit of data users (more than for contributors). It could hold (for example) cases such as "highway=ford" is equivalent to "ford=yes". That would remove some of the pressure to change the underlying data (though it might - unfortunately - encourage people to try and "fix" it). It would though, help to collect cases that needed discussion into one place, and allow a wider, and less transient, discussion before they turn into disputes.

add Tag:amenity=public_building to the List?

--Reneman (talk) 14:35, 22 April 2013 (UTC)

Proposal for changing "deprecated" to "banned" in the preamble

As said before in 2012 the first sentence of the main page is contrary to the title of the site.

It is ambiguous to list "deprecated features" while stating that there are no "deprecated features". I suggest to change the first sentence to: OpenStreetMap does not have "banned features", as anybody is allowed and encouraged to use any tag they think is useful.

--Rudolf (talk) 17:48, 25 May 2014 (UTC)