Proposal talk:Deprecated and unsupported status

render support

"the render would drop support" which renders? Mateusz Konieczny (talk) 11:34, 19 December 2021 (UTC)

Hi Mateusz. Thanks for all your suggestions. I guess you discovered our proposal via the weekly-osm. To be honest, at this step, we were not ready to internationalize the discussion: we were in a french discussion in order to finish the proposal before discussion. We still have a lot to finish before I send a message to the tagging mailing-list. Nervertheless your help is welcome, so we will consider your comments soon. Regarding "the render", I changed for "renders" because it should be all of them, in a general manner. Please keep in mind that it's a general purpose in introduction of the proposal. The list of the renders impacted comes later in the follow-up table Overflorian (talk) 12:28, 19 December 2021 (UTC)

Then "would drop support" is unreasonable, the most wiki proposal can do is "are recommended to drop support". Anyone can make any renderer rendering anything they want and wiki proposal is unable to stop them Mateusz Konieczny (talk) 12:34, 19 December 2021 (UTC)

You are right, I changed the proposal accordingly Overflorian (talk) 12:56, 19 December 2021 (UTC)

Resolved: Mateusz Konieczny (talk) 14:05, 19 December 2021 (UTC)

deprecating tag faster is also fine

In many cases new tags are created and removed immediately, there is no need to keep them for 2 years Mateusz Konieczny (talk) 11:35, 19 December 2021 (UTC)

I replied to this below Overflorian (talk) 13:18, 19 December 2021 (UTC)

What about tasks where automatic replacement is impossible?

It includes at least landuse=farm and waterway=wadi (and what about old-style multipolygons? Or natural=land?) Mateusz Konieczny (talk) 11:36, 19 December 2021 (UTC)

This is already excluded of the proposal with a proper exception: "the approved tag should exactly replace and describe the same object." Overflorian (talk) 13:00, 19 December 2021 (UTC)

In such cases at least following should not apply for tags with significant use

• "the new "deprecated and unsupported status" would apply"
• "the documentation would mention the "deprecated and unsupported" tag only as an historic feature"

Mateusz Konieczny (talk) 14:06, 19 December 2021 (UTC)

Yes I totally agree. In fact, for such cases, none of the proposal could apply at all. Overflorian (talk) 17:47, 19 December 2021 (UTC)

Where it is stated in proposal? Maybe make clear in Proposed_features/Deprecated_and_unsupported_status#Proposal_overview that it applies only to small subset of deprecations? Mateusz Konieczny (talk) 01:17, 20 December 2021 (UTC)

As I said before, it's already detailed as an exception. The "proposal overview" is just a global overview, there is no need to go too deep into details during the introduction. Overflorian (talk) 10:14, 20 December 2021 (UTC)

And as it stands many people will read "Create a 2 years buffer period after deprecating a tag before killing it once and for all" and will have a very negative reaction - it should be clarified also there or you will lose some part of audience Mateusz Konieczny (talk) 01:33, 20 December 2021 (UTC)

I changed the title to "Advice mechanical edit to get rid of deprecated tags after 2 years of close follow-up " Overflorian (talk) 10:14, 20 December 2021 (UTC)

Note that "List of already deprecated tags that respect all criteria:" contains at least one tag where automatic replacement is impossible Mateusz Konieczny (talk) 17:51, 20 December 2021 (UTC)

And at least one more where automatic replacement is possible but would introduce false data Mateusz Konieczny (talk) 17:53, 20 December 2021 (UTC)

As previously said, the proposal is still under construction. It's really in crash-test right nowǃ We did not plan to discuss it internationally yet. I think that the best would be to continue this discussion when it will be fully completed. Let's discuss again in some weeks, when I will publish a message in the tagging ML. Thanks. Overflorian (talk) 19:11, 20 December 2021 (UTC)

Hi, here's an update of this proposalː we closed it, because we feel that it's not the best way to solve the identified issues. Please see on the main proposal page the reasons why and the following steps we consider in order to move-on. Thanks for your feedback. Overflorian (talk) 14:44, 5 January 2022 (UTC)

Mapnik is not map style

"Send a request to render (Mapnik ...)" - see linked Mapnik page Mateusz Konieczny (talk) 11:37, 19 December 2021 (UTC)

You are right. I changed it accordingly Overflorian (talk) 13:03, 19 December 2021 (UTC)

Resolved: Mateusz Konieczny (talk) 14:07, 19 December 2021 (UTC)

What exactly marks tag as deprecated?

Approved proposal? What about proposals that

• "deprecate tag X but X should not be removed" (waterway=riverbank mess was partially caused by this)
• propose new replacement tag but never clearly proposed deprecation, but implied this

What about tags marked as deprecated in Data items and not on Wiki? What about tags marked deprecated in some translations only? Or only in translations? (I can make list of such problematic cases)

What about tags deprecated by quick discussion on tagging mailing list?

What about ones not listed on deprecated features (partially because editing it is a nightmare).

Mateusz Konieczny (talk) 11:44, 19 December 2021 (UTC)

Our proposal strictly applies to depreciated tags approved by a proper community vote. Having a page with such a vote should be the only but necessary requirement. Therefore it does not apply to "not-clearly" depreciated tags such as waterway=riverbank, marked as deprecated in the doc (data items, wiki pages...) but not properly deprecated , informally deprecated (on a mailing-list for example) or other cases. Updating the documentation to find the deprecated tags is not part of this proposal, this is a separated topic. Overflorian (talk) 12:57, 19 December 2021 (UTC)

Is it defined somewhere on the proposal page? Mateusz Konieczny (talk) 14:08, 19 December 2021 (UTC)

Now it is [1] Overflorian (talk) 17:57, 19 December 2021 (UTC)

Note that "List of already deprecated tags that respect all criteria:" now somehow lists waterway=riverbank Mateusz Konieczny (talk) 17:52, 20 December 2021 (UTC)

List of approved bot edits is missing

In light of "The currently deprecated tags should be part of the proposed process. We should apply the transition plan for them"

Given that this proposal approves multiple automatic edits - it really should include list of which automatic edits are being approved. Which tags are planned to be replaced with what?

Mateusz Konieczny (talk) 11:44, 19 December 2021 (UTC)

Good question. Will list them all soon. Overflorian (talk) 13:28, 19 December 2021 (UTC)

Why existing process is not enough

If people would approve such mass edits - have you did them? (I did, mostly limited to Poland due to lack of acceptance by general community)

Yes I did. With my dedicated account see https://wiki.openstreetmap.org/wiki/User:Overflorian-mass-edits

If people would not approve such mass edits - why you expect that this proposal will pass?

Mateusz Konieczny (talk) 11:47, 19 December 2021 (UTC)

The current proposal detailed a very strict frame under which such edits could happen. Our ambition is to identify every exception possible [[2]]. In a way, the regular process to make a mechanical edit happen is discussed right now for the upcoming edits. Also, there is a clear benefit to publicly assume the transition period. The tools/render developers and data users being aware of the process are more likely to take community's votes into account in the future. Overflorian (talk) 13:26, 19 December 2021 (UTC)

What about reappearing tags

"ban the use of any tag (as previously suggested). In particular, the use of the deprecated to tag will always be tolerated, even after automated edits."

So bot run would be one-time only and not repeated and further runs would be subject to normal bot approval? Mateusz Konieczny (talk) 11:49, 19 December 2021 (UTC)

We are still working on this one. Not sure how to deal with it for now. Overflorian (talk) 13:27, 19 December 2021 (UTC)

Maybe it would be better as a checklist?

Make checklist like shown on Deprecated_features_follow-up#Original_table and add it on pages describing deprecated tags. Maybe as template where one would fill relevant parameters, with automatic listing in relevant categories and some magic like not showing "create JOSM validator rule" for rare tags Mateusz Konieczny (talk) 12:47, 19 December 2021 (UTC)

Could you please detail what could be automated here? Because I don't see any Overflorian (talk) 13:18, 19 December 2021 (UTC)

listing all deprecated tags which are marked as still present in JOSM preset, listing all deprecated tags which are marked as still present in iD preset, listing deprecated tags which have more than N uses and are not being deprecated by iD/JOSM. It could be also done via data items Mateusz Konieczny (talk) 14:02, 19 December 2021 (UTC)

Nearly all actions can be done without resorting to some extra proposals and tracking this state would be quite useful and allow to catch missed cases

I'm totally convinced that we should move in that direction but it's not part of the current proposal. Too big to deal with it at once. Probably next step.Overflorian (talk) 10:18, 20 December 2021 (UTC)

It seems to me that such checklist showing current state of deprecation would be useful, far less controversial and allow coordination. While "lets approve multiple controversial bot edits at once" will not work

Mateusz Konieczny (talk) 12:41, 19 December 2021 (UTC)

You are right: nearly all actions could be done without the proposal. All these actions are not what the proposal is about. This proposal is about giving a clear view, predetermined deadlines, for depreciation. It's about giving visibility to the data users and tools developers. The checklist as much as the mechanical edits are just tools used by the community to make it happen. This is why we need a standard time schedule for depreciation, even if the depreciation process could happen much faster. Overflorian (talk) 13:18, 19 December 2021 (UTC)

Needs elaboration about data consumers

This proposal refers to editors, QA tools, and renderers, but as far as I can tell, it doesn't seem to cover other kinds of data consumers. For this proposal to have the intended effect without collateral damage, it should address the role of routers and search engines, which in some cases may be affected even more acutely by a deprecation than any renderer.

Additionally, a Web-based raster renderer may be easier to upgrade on a shorter timeline than a mobile application using vector tiles. For example, a vector tile provider like OpenMapTiles may need to restructure its schema to reflect certain deprecations, but that project needs to be careful about backwards-incompatible changes to avoid breaking downstream clients and third-party styles. A mobile application based on OpenMapTiles may be deployed to an app store, receiving new data to be rendered according to a schema that existed when the application was released. If it offers offline map downloads, it needs to ensure compatibility between those downloads and existing installations. A two-year period seems generous, but it's probably less generous for these data consumers than it would be for a Web-based raster renderer, considering their own long-term support needs.

Therefore, this proposal should elaborate on the ellipsis in "(standard tile layer ...)": what other projects are covered by this process? Should any non-community-developed data consumers be accounted for? To be sure, crafting a proposal is already a lot of work without having to contact a long tail of potentially affected data consumers. Should this burden lie with the proposer, or should it be coordinated by a dedicated team, perhaps one of the working groups?

 – Minh Nguyễn ^💬 22:47, 19 December 2021 (UTC)

This proposal is all about giving more visibility to all data users and developers. Therefore it's not possible to cover the whole scope of consumers. I believe it should be anticipated during the depreciation process. That's already part of the proposal [3]. I just added the routers & search engines in the list of potentially impacted projects. Also added it directly in the follow-up table [4]Overflorian (talk) 10:26, 20 December 2021 (UTC)

If this would be restricted solely to cases where automatic replacement can be done without data loss then it would be easy to handle it in say vector tiles. Though I am unsure how often such deprecations actually happen Mateusz Konieczny (talk) 01:14, 20 December 2021 (UTC)

Honestly, guys, the community has no time to loose to keep track of all external impacted projects. But, still, with our new table, it is possible to mention any other impacted project. Therefore this proposal give already these projects a lot more of information than previously, it's already an improvement. Any other improvement on this should be part of another proposal.Overflorian (talk) 10:32, 20 December 2021 (UTC)