Talk:Deprecated features

From OpenStreetMap Wiki
Jump to navigation Jump to 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)
Resolved: problematic entries were rolled back Mateusz Konieczny (talk) 14:56, 3 June 2021 (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)
Sounds good, may be a good idea to migrate the part about specific alternatives over to the website page (obviously omitting the part about the website tag). --Lyciathelycanroc (talk) 12:14, 27 August 2018 (UTC)

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)

Resolved: nowadays is present Mateusz Konieczny (talk) 14:56, 3 June 2021 (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)

I suggest remove the following from the list

waterway=rapids

Reasons:

1. rapids exist independant of watersports, therefore an independant tag should exist

2. despite the depreciating since 2010, the use of this tag is used more and more: https://taghistory.raifer.tech/#***/waterway/rapids

3. formal: neither https://wiki.openstreetmap.org/wiki/Tag:waterway%3Drapids nor https://wiki.openstreetmap.org/wiki/Whitewater_sports mark this tag as depreciated

Agreed. It makes sense to use along with waterway=waterfall and waterway=weir --Jeisenbe (talk) 01:59, 15 January 2021 (UTC)
Resolved: removed some time ago Mateusz Konieczny (talk) 14:54, 3 June 2021 (UTC)

I suggest we deprecate the following

route=riding -> route=horse

Reason: no wiki-page, little use, duplicate of route=horse. See Tag:route=horse--PangoSE (talk) 11:35, 27 August 2018 (UTC)

Resolved: no reply Mateusz Konieczny (talk) 14:53, 3 June 2021 (UTC)

type=region -> place=region

Reason: no wiki-page, little use, duplicate. See place=region--PangoSE (talk) 11:35, 27 August 2018 (UTC)

Commonly used in Poland for physiographic region relations: https://www.openstreetmap.org/relation/6533672
You can't replace it with place= because relation needs 'type' key.{{Signature|rafmar|27 augusti 2018 kl. 12.38‎ |pangoSE}}
Thank you for the reply. There seem to be no proposals regarding how to tag these psysiographic regions. Fennoscandia which includes Sweden is not found. Further these physiographic traits are never referred to or used in Sweden and the borders of e.g. Fennoscandia is not well defined anywhere. How are they used in Poland and polish culture? Are they clearly defined somewhere?
In the relevant WP-page I read "Even in the 21st century, some confusion remains as to exactly what "physiography" is."--PangoSE (talk) 13:29, 27 August 2018 (UTC)
You could use type=multipolygon, or are there special roles? —Dieterdreist (talk) 20:34, 27 August 2018 (UTC)

boundary=region -> boundary=administrative + boundary_type=region or place=region if not administrative

Reason: no wiki-page, little use, does not appear on Key:boundary or Relation:boundary.--PangoSE (talk) 11:35, 27 August 2018 (UTC)

Lack of documentation is not a sufficient reason for deprecationMateusz Konieczny (talk) 14:54, 3 June 2021 (UTC)
Resolved: not saying that this tag is a good idea but often lack of wiki page indicated that wiki page should be created rather than tag should be deprecated Mateusz Konieczny (talk) 06:47, 9 August 2021 (UTC)

Single mapper/community

@501ghost: re "Lithuanian mappers have banned most occurrences of natural=water + water=* in Lithuania" - is there any evidence that it is Lithuanian community decision? In all links a single mappers occurs. Specifically https://www.openstreetmap.org/changeset/100093213 discussion ended as soon as question was asked what is the decision of wider Lithuanian community, beyond that specific mapper. Mateusz Konieczny (talk) 14:52, 3 June 2021 (UTC)

@Mateusz Konieczny: From Tomas Straupis' messages I understand that he has made this decision together with fellow Lithuanian mappers in a pub in Vilnius. User empers has confirmed on Discord that all natural=water + water=* has been banned in Lithuania except for lakes. Tomas has also mentioned in a comment on changeset 104007471 that he is moving official documentation for Lithuania away from the Wiki to deny people like ZeLonewolf, who is conducting river modernisation efforts in North America, access to it. User Snaiperis has confirmed in the same changeset discussion that he uses the same tagging scheme for water bodies as Tomas Straupis. Apart from that, Tomas Straupis reverts most or all changesets that include natural=water + water=* in Lithuania and verbally abuses mappers who comment on this.
Frederik Ramm of the DWG is aware of the situation, but has said in personal communication that he gives priority to local tagging preferences over global popularity of tagging schemes. He has also suggested that "before you map anything in Lithuania, you establish contact with the Lithuanian community and ask them if your changes are welcome; if the result is yes, then proceed, if no, then don't." --501ghost (talk) 15:25, 3 June 2021 (UTC)
I am still very suspicious about group that meet long ago dictating things but if it is not obviously incorrect I will likely avoid that topic. Creating own OSM Wiki is especially silly. Hopefully they are not insulting/confusing any new mapper using iD/JOSM without their preferred presets Mateusz Konieczny (talk) 16:02, 3 June 2021 (UTC)
I agree it would be helpful if some documentation gets shared with the general OSM community that shows a wide community consensus, but Tomas has stated that unlike local mappers like him, "nerds", "intruders" and "uneducated inexperienced newbies" have no say in how Lithuania gets mapped. Frederik Ramm has at least in part confirmed this statement, so I don't have high hopes of any change happening. --501ghost (talk) 16:30, 3 June 2021 (UTC)

building=condominium not listed

building=condominium says "This feature has been labeled as deprecated. [...] The reason is documented in Deprecated features." but this page currently contains no mention of the tag.

Mentioned on https://wiki.openstreetmap.org/wiki/Talk:Tag:building%3Dcondominium#template_text and user was pinged. I also added some description on that page. Deprecated features has some unusuable template system that is too complex for me so I am not going to add it here (and I am working as a programmer! I am not someone easily scared by complex computer systems!). Thanks for noticing the problem and reporting it! Mateusz Konieczny (talk) 06:40, 9 August 2021 (UTC)
Wow, that template system is awful. It seems to be designed to avoid creating duplicate pages in other languages that would be impossible to keep in sync, but there has to be a better way.
I've added the tag without the reason listed, since I couldn't figure that part out. Took me an hour, but I figured it out. You have to edit both Template:Deprecated_features/reason and Template:Deprecated_features/reason/doc Tguen (talk) 03:58, 27 August 2021 (UTC)

sport=football deprecated??

Why is this? The suggested alternative <sport=* (various values)> is hardly helpful! Is this a bid to have Association/American/Aussie rules football distinguished from each other? If so could the suggested alternatives be made clearer? eteb3 (talk) 16:43, 1 September 2021 (UTC)

I edited this page to provide more clear answer - it was documented at sport=football page already Mateusz Konieczny (talk) 02:45, 3 March 2023 (UTC)

surface=granite and other similar

See https://community.openstreetmap.org/t/type-of-stone-in-surface-surface-granite-and-similar/9424 Mateusz Konieczny (talk) 02:46, 3 March 2023 (UTC)

malformed surface tags

Depending on your view these were always deprecated, or were deprecated recently - see Mechanical Edits/Mateusz Konieczny - bot account/fixing malformed surface tags

Note sure is listing them here is useful at all, but maybe bot edit is somehow worth linking (especially as more similar cases will be added soon to this edit - see https://lists.openstreetmap.org/pipermail/talk/2023-February/088076.html )

Mateusz Konieczny (talk) 02:49, 3 March 2023 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Deprecated_features&oldid=2486985"