Template talk:Deprecated features

tourism=museum

Change sets 31589602 and 31587433 removed the last of the deprecated historic=museum tags. I confirmed the removal with overpass-turbo. Do I remove the row in the table or is the deprecated information left in the table for reference? --Dr Kludge (talk) 03:18, 31 May 2015 (UTC)

As of July 12, there are still 3 elements with this tag - so it still remains in the table. However, if some deprecated tag is removed out of the database, it can be pulled out of the table. Bibi6 (talk) 20:45, 12 July 2015 (UTC)

why remove them? This page is for documenting deprecations, not only for deprecated tags still in database.A tag could reappear or get re-proposed, so having documentation about is good.--Jojo4u (talk) 22:10, 11 August 2015 (UTC)

Why a template ?

Is there a reason to create this template instead of simply using the page Deprecated features ? Otherwise I believe it's better to just keep it in the original page. Cheers --Jgpacker (talk) 21:23, 13 May 2015 (UTC)

Yes, because of the different languages. As an example, the Russian version did not take the latest updates into consideration - with the template, they now have an up-to-date table of deprecated features. As well as the French one - and you may want to have it in Portuguese ;)

By the way, I just noticed that tag opening_hours=* is more suitable than conditional=* as a replacement for day_on=* and hour_on=*. I'm going to change the template... which will update the 3 existing language pages in a row (Polish page has an issue I don't really understand, maybe it wasn't properly translated...).

Cheers, Bibi6 (talk) 22:21, 14 May 2015 (UTC)

I have conflicted feelings about this kind of template. While it does make it easier to translate new entries in other languages, it requires that the wiki editor be better at wiki editing than the average, but we have too little people like this (especially that knows other languages) and the focus is supposed to be OSM after all. Since this kind of template is already used in other places in the wiki anyway, I won't bother you, but I thought I should register my objection somewhere.

Also, when you are adding new keys in this page, you should check if they are really deprecated in the tagging mailing list, even if it seems like a straightforward deprecation (even this day_on=* you mentioned). Otherwise you shouldn't add it here.

Cheers --Jgpacker (talk) 01:40, 15 May 2015 (UTC)

it requires that the wiki editor be better at wiki editing than the average, but we have too little people like this (especially that knows other languages) and the focus is supposed to be OSM after all.

I agree with you on that point, but I also think that an up-to-date list of deprecated features, available in several languages, is a nice-to-have thing ;). Actually, I'm not really satisfied with the way to use it for now, and I will work on it to make it more user-friendly.

but I thought I should register my objection somewhere. Done :)

when you are adding new keys in this page, you should check if they are really deprecated in the tagging mailing list,

I wasn't aware of this mailing list, thank you for mentioning it. Looking around its archives, I noticed a deprecated tag that has't be listed: waterway=riverbank. One more entry to add! ;)

I will add your last remark in the template doc. Thank you!

Cheers, Bibi6 (talk) 15:44, 15 May 2015 (UTC)

It seems you have been adding some new tags here. I wasn't clear: don't add any tag here without consulting the tagging mailing list. Even if they are listed as deprecated in their own pages. There may be disagreements from people that don't watch the wiki (99% of the people don't). In OSM, the mailing list is more important than the wiki. Please remove the ones you added recently and consult the mailing list before re-adding (or just remove any that anyone disagrees about). You can list all of them in a single email. --Jgpacker (talk) 16:51, 19 May 2015 (UTC)

I just want to register complaint about unreasonable complexity of editing this. And I am an experienced OSM Wiki editor and a programmer, not sure how normal person is supposed to edit this Mateusz Konieczny (talk) 22:42, 27 December 2020 (UTC)

I've edited some pretty complex templates, and I also can't figure out how the heck to set the "reason" in this template. --ZeLonewolf (talk) 22:45, 27 December 2020 (UTC)

After ZeLonewolf figured it I documented it, but still it is a bit too much Mateusz Konieczny (talk) 23:29, 27 December 2020 (UTC)

deprecation of waterway=riverbank

I have recently modified waterway=riverbank back to "in use". Despite the fact that it has been officially deprecated since 2011 the new scheme did not and likely never will catch up: water=river:10.700 vs waterway=riverbank:283.231 . Also, the argument "adding riverbanks to canals is confusing" might be true but adding "natural=water" to canals is just about equally confusing.

The particular issue that I have with having riverbank listed in this table is that osmose uses this information to suggest replacement of tags. Replacing waterway=riverbank with natural=water however can be technically very tricky when tags are duplicated on parent relations and members as happens frequently and thus it is imho a very bad idea to give non-expert users motivation to attempt this.

Are there any strong objections to remove it from this table? RicoZ (talk) 16:10, 30 May 2015 (UTC)

I agree with most of your arguments - and I actually added it mainly only because it had the status "deprecated". I have no objection about changing the tag status and removing it from the table, but I mention Proposed_features/Water_details for the record. I think this should also be mentioned on the tag documentation. Bibi6 (talk) 20:45, 12 July 2015 (UTC)

Some more deprecations

Not sure how the list is sorted, otherwise I would add them myself. Several bridge=* values have been superseded by a new tagging scheme with Proposed features/Bridge types. Of those still listed in some numbers in taginfo:

• bridge=swing - ambiguous - should be changed to either bridge=movable+bridge=swing or bridge=yes+bridge:structure=simple-suspension
• bridge=arch should be changed to bridge=yes+bridge:structure=arch
• bridge=beam should be changed to bridge=yes+bridge:structure=beam
• bridge=suspension should be changed to bridge=yes+bridge:structure=suspension
• bridge=humpback should be changed to bridge=yes+bridge:structure=humpback
• bridge=pontoon should be changed to bridge=yes+bridge:structure=floating
• bridge=lift should be changed to bridge=movable+bridge:movable=lift

RicoZ (talk) 12:03, 31 May 2015 (UTC)

There is actually no defined order for the list encoding, but I'd suggest adding new tags at the bottom. I'm going to add these soon. You are welcome to add other ones if you know such! Bibi6 (talk) 20:45, 12 July 2015 (UTC)

What confuses me is the 5th column - "N" with some number. RicoZ (talk) 18:29, 14 July 2015 (UTC)

Deprecated or actually suggesting to replace: use of this page by QA tools

Hi, in an email exchange with the maintainers of Osmose I learned that the tool uses this template to look for tags that are deprecated. Beeing displayed in Osmose or other QA tools as obsolete will likely motivate some users to actively try to retag the objects.

Given that in the past many edits motivated by QA tools turned out to cause more problems than they solved I am convinced that this approach must be refined somehow to avoid problems or waste of work:

• not all tags that are deprecated should be actively replaced, often enough the old tags don't cause any problems and data consumers know them
• some tags should be replaced but the process is tricky and may require expert skills

So maybe this table could get one or two extra fields - "should be replaced y/n" and "difficulty"?

Or would it be better to have an extra page for the use of QA tools? RicoZ (talk) 21:55, 1 June 2015 (UTC)

Your argument is sensitive, and I agree with it. However, having another table for use by the QA tools is, IMHO, not a good option because it would mean duplicating some data - which goes the opposite way of this template's goal! Also, the Deprecated features page (as well as its French translation - and I suppose the Russian one too, as I don't know Russian) says two important points on this:

• There is no banned feature (Any tags you like...)
• The following are features for which alternative tagging is recommended by those engaged in tagging discussions. Note that some of these features are still on Map Features and should remain there as long as they are still widely used!

And I think it's the role of the QA tools to take care of this. For Osmose, for example, I think that just saying "This tag is deprecated - new tags" is not enough, as, as you said, that motivates to replace the deprecated tag by the suggestion without paying attention to what the tagging means. I think that they should use the comment column as information on how to retag, if necessary.

New fields, why not, provided they add valuable information... I'm not convinced by a "should be replaced" column, as this is essentially what the deprecation means; about "difficulty", how to define this? ... Bibi6 (talk) 20:45, 12 July 2015 (UTC)

Even if Osmose and similar display the comment/reason field this may not be good enough - in fact I think they do it even now. The map will be still full of little warning marks. People can click on "false positive" to make them disappear but that isn't a completely correct approach either - those are not really false positives but things that are not considered worth the effort or risk to replace.

My impression is that there is a difference between "should be replaced " and "is deprecated" - otherwise many of the deprecated tags would be easily done by mechanical edits and there would be hardly any opposition doing so. Also many tags are de-facto deprecated such as "culvert=yes" and do not appear in this list, it also appears nobody would consider it worth the effort to actually replace them. On the other hand something like "bridge=swing" should be replaced with high priority because it has been used for two different conflicting things.

Regarding the difficulty field, it is not very important and could be left empty in most cases. It could contain information like "tricky relations/multipolygons" or "local knowledge required". RicoZ (talk) 14:49, 14 July 2015 (UTC)

I regularly track down depreciated tags in my environment. The main problem I encounter is that there are 3 situations:

* conflicting changes (such as changes proposed by a well known web editor against the concesus). they don't bring any quality improvement. I think we should track all the item without a link to the approved proposal or discussion.

* changes with only one solution (for example diaper -> changing_table): the current template is good (despite I find no added value to do it manually in stead of following the rule for a mecanical edit)

* changes with more than one solution. for example power=sub_station deprecated because it have 3 meanings : power=substation and power=generator or power=plant in the reason but only one in suggestion or highway=unsurfaced. the current solution is not good. the freetext is hard to parse for QA tools

Marc marc (talk) 07:59, 30 December 2020 (UTC)

"I think we should track all the item without a link to the approved proposal or discussion." - note that some of this cases are blatantly obvious and I would say that discussion was not really necessary. Also, thanks for a reminder to link tagging thread in Tag:amenity=life_ring Mateusz Konieczny (talk) 09:13, 30 December 2020 (UTC)

Keep on the list

I saw that highway=minor was removed from the list, probably because its count was zero currently. However this tag is popping up again occasionally, I was just recently cleaning after some HOT mappers. It should remain in the list as a reference not to use it.

I would also like to keep the deprecated bridges a little longer in the list, mappers have long memory. RicoZ (talk) 15:26, 26 May 2016 (UTC)

landuse=reservoir

Tstraupis wrote in the changeset comment: "Stop adding landuse=reservoir to deprecated features. After FIVE years of "depreciation" landuse=reservoir has 379 752 while water=reservoir has only 77 745 objects. Mappers have voted with mapping!"

@Tstraupis, it would be good to start some talk before going into edit wars! You are quoting current number of the usage of this tag, but have you statistics for its development? Is the landuse tag growing? Is the water tag shinking? --Polarbear w (talk) 17:47, 29 May 2016 (UTC)

I really do not want to get to "edit wars". I do not try deleting proposal page or changing any of reservoir tagging pages, I just want to stop osmosis marking reservoirs as "errors" and thus calling armchair mappers to "fix" them. Look at waterway=riverbank above. Landuse=reservoir was "deprecated" in exactly the same proposal. And situation is exactly the same - it never got considerable acceptance. I would say that proposal system should have some guards against such not well thought out "proposals" in the first place. Landuse=reservoir was used before that proposal with hundreds of thousands objects marked, maps (slippy and device) created, validation rules (topology and other error) created, extracts for other users (shape files for students and commercial consumers) created with corresponding documentation etc. etc. There should be a very good reason to "deprecate" such a widespread tag and Zveriks proposal does not have a good reason other than "i like it that way" or "everything blue must have natural=water". Tstraupis (talk) 07:18, 30 May 2016 (UTC)

Nobody should try to add tag onto this list without the tag page listing this tag as deprecated as well. I don't see Tstraupis as the starter of an edit ware here. Just leave the tag as it is until a solution comes by a proposal, more debating on the usual channels or by decline of usage.--Jojo4u (talk) 18:20, 30 May 2016 (UTC)

Yeah but it was Tstraupis himself who removed the 'deprecated' label from the tag page. --Polarbear w (talk) 07:41, 4 June 2016 (UTC)

How can I add reason for deprecation?

"1=N (an integer that identifies the translatable reason below)" - how can I define new reasons? Mateusz Konieczny (talk) 07:22, 27 December 2020 (UTC)

Okay....I just figured it out. You have to edit Template:Deprecated_features/reason, so that'll need to get documented. --ZeLonewolf (talk) 22:47, 27 December 2020 (UTC)

https://wiki.openstreetmap.org/w/index.php?title=Template:Deprecated_features/doc&diff=2078697&oldid=1882739 (maybe tomorrow I will have enough strength to deal with that) Mateusz Konieczny (talk) 23:28, 27 December 2020 (UTC)

Right, it's a very strange way to do it, and most just use a standard "reason". I think it would be better to change this to free text. --Jeisenbe (talk) 06:04, 28 December 2020 (UTC)

unable to edit the template

I have a problem: I cannot edit this template. An attempt to save changes is requested for a confirmation code. Does anyone know how to fix this problem? Something B (talk) 22:10, 4 February 2021 (UTC)

It may be solved by waiting - accounts at least 4 days old and with at least 10 edits are put into "autoconfirmed" category, that removes some restrictions. Maybe it should be changed? BTW, what happens after you solve the CAPTCHA and write that code? Or is it not appearing? (@Something B: Mateusz Konieczny (talk) 06:48, 5 February 2021 (UTC)

CAPTCHA is not appeaing. Something B (talk) 08:41, 5 February 2021 (UTC)

P.S. I'll try to wait. Interestingly, the problem only occurs with this template. So I was trying to add amenity=swimming_pool. However, removing the duplicate amenity=education passed. Something B (talk) 09:36, 5 February 2021 (UTC)

@Something B: Are you editing from mobile device? It may be https://github.com/openstreetmap/operations/issues/449 Mateusz Konieczny (talk) 18:15, 16 February 2021 (UTC)

Yes, I edited from a mobile device. The problem has now been resolved. Something B (talk) 21:11, 16 February 2021 (UTC)

amenity=swimming_pool

The "amenity = swimming_pool" tag is not listed. Can it be added? wiki.openstreetmap.org/wiki/Tag:amenity=swimming_pool Something B (talk) 09:29, 5 February 2021 (UTC)

string number N to be translated

according to the doc, N represents a string number to be translated. i don't know why they display both the number and the string itself. but in addition many items have an empty sring and a different N, when there is nothing to translate. this makes tracking translations very fancy, or I miss something --Marc marc (talk) 18:33, 14 February 2021 (UTC)

Deprecated or list of all mistakes ?

Seeing the last add amenity=private_toilets (again without any link to a thread nor a wiki page) i wonder if there is not confusion between deprecated tag and list of all existing errors. adding a deprecated tag that will make a taginfo request at each display of the page, use human time when reading the list, an additional test in some QA tools that use it (osmose for example) all this for a "<250 in one city" mistake, I find that it contradicts the notion of deprecated tag. If it's one-shoot error, it's better to fix it. For common typo/error, Osmose (and perhaps others) use TagwatchCleaner (of course maybe it's better to move/copy it outside the userspace). Marc marc (talk) 19:08, 13 March 2021 (UTC)

I think this tag was not a mistake, rather it was made on purpose. I can remove this tag from the table, it doesn't matter to me. Something B (talk) 21:25, 13 March 2021 (UTC)

Cleanup

Some tags from the table do not have wiki pages and do not appear in the OSM database. I think they can be cleaned out. This will make the table easier to read. Something B (talk) 23:04, 13 March 2021 (UTC)

amenity=clubhouse

I have removed amenity=clubhouse and amenity=club_house from this list. The deprecation of these tags is disputed and should not appear here (at least not yet). They were deprecated only by Wiki edits and discussions are now on-going in the tagging mailing list. Casey boy (talk) 10:29, 1 April 2021 (UTC)

Resolved: apparently resolved Mateusz Konieczny (talk) 02:43, 3 March 2023 (UTC)

Reasons limited to 99?

I have tried to add a new item in Template:Deprecated features/reason with number 100, more specifically with this code...

|100={{LangSwitch|lang={{{2}}} |en=[[Proposed features/Manufacturer and Model#Rationale_of_the_proposal]] }}

...but nothing showed up. So i changed the number from 100 to 59 (which was not used neither in Template:Deprecated features/reason nor in Template:Deprecated features) and the new item showed up and I was able to use it in Template:Deprecated features.

Are the items in Template:Deprecated features/reason limited to 99? In the long run that could be a problem. --Danysan (talk) 09:10, 1 December 2022 (UTC)

Hi! Any number will work. They just don't show up in the preview table. --Chris2map (talk) 14:25, 4 January 2023 (UTC)

i think it's losing sight of the reason for this number: to allow translating an explanation in different languages. a url doesn't bring anything at all as an explanation and doesn't need to be translated (the url of the proposal should be in StatusLink of the old and new tags). having spent some time trying to translate this, i gave up due to inefficiency. i think the reasons should be grouped in a generic one: typo/error, avoid tag fragmentation in favor of a more common tag, new schema, ambiguous tag with several meanings, ... the complete detail of the arguments can be found in the proposal when there was one Marc marc (talk) 14:37, 4 January 2023 (UTC)

parking:condition:side and parking:lane

the suggestion for those tags are... not a suggestion of tags :) is somebody working on it ? if not I'll do it using https://wiki.openstreetmap.org/wiki/Proposed_features/street_parking_revision#Dictionary:_old_vs._new_tags Marc marc (talk) 13:00, 4 January 2023 (UTC)

Have fun. But it is complicated, as both schemes handle some aspects too differently for an easy replacement. Discostu36 (talk) 13:11, 4 January 2023 (UTC)

historic=icon

This tag listed with "usage completely unknown". But is this table about undocumented tags? Something B (talk) 13:11, 13 January 2023 (UTC)