From the imagery, it looks like an area of rock that forms a well-defined river channel. It’s probably usually mostly dry with a small stream making its way through (see the Bing imagery) but occasionally a raging torrent.
The question, I guess is whether should be mapped one object or two. Is it only one (something that is sometimes wet and sometimes not), or two (the rock, and the water that’s there part of the year)?
However it gets mapped, there are ways for data consumers to decide what they want to show here. It’s much easier (using pretty much any rendering mechanism) if both sets of tags are on one object, but also possible if they’re not. Personally I don’t think “how easy it should be to render” should be the main factor here - it comes down to “do you think there is one object here or two”.
I’m not really sure if the RfC period should be extended, since I assume with most proposals the details have already been discussed on the mailing list and other places beforehand, but I’ve always felt that the two vote period is way to short and should really be extended by at least a week, if not two. It can take almost a week just for everyone to be notified. Let alone can most people read through the proposal, relevant mailing-list discussions, Etc. Etc. and made an informed decision in that short of a time.
(I’m aware that the general rule is “at least” 2 weeks and that it can be extended, but it’s clearly the default and people don’t usually extend it. One reason being that it can look bad on the proposer if they extend the vote period for a proposal that is likely going to be rejected after the 2 weeks ends.)
Proposals should include a machine readable description of each set of tag changes. This requires that the all the concepts described in human language are available in a form something that bots and renders can immediately process. This forces the proposal writers to create data object or modifier for each concept being covered in order to be considered complete. The resulting data objects can then be analyzed and used by companion software such as editors and routers.
The wiki isn’t well suited for machine-readable schemas, unless you’re suggesting data items about proposals, but that could be a challenge to model well. Maybe there could be a voluntary step of creating a pull request against the id-tagging-schema repository, showing how its list of deprecations and suggested upgrades would change. But I’m unsure about making that a required step, since deprecations aren’t always as straightforward as replacing one set of tags with another.
Proposer writes proposal, discusses it widely, and demonstrates consensus with a >75% approval during a 2+ week vote.
Proposer writes up technical procedure for making the change in the map.
Proposer discusses proposed change with the communities involved to ensure there are no objections to making the edits
Proposer makes the edits
There is your process, with no use of the passive voice. It’s also the process that exists today and anyone can use!
In practice, the change from an older tagging scheme to a newer one is rarely a 1:1 substitution and a bunch of work is involved to deal with edge cases, outliers, or cases where the old tag is replaced by more detailed tagging that requires the mapper to make a decision.
The problem isn’t that we don’t have a “process”. The problem (if you can even call it a problem) is that the community rarely agrees on what to do, and most people aren’t willing to put in the effort of listening, technical analysis, persuasive writing and diplomacy needed to do it on a global scale.
This is the reality of an anarchic, community-driven process. Some have suggested that the community process is no longer effective and that it would be better for the OSMF to introduce a formal, bureaucratic process for handling tagging changes. That would certainly “solve” the problem of tagging changes being too hard by appointing an arbiter to decide on such things. However, I suspect that the voting membership of the OSMF would oppose board candidates that would advocate for foundation involvement in tagging issues.
Wouldn’t it be more like they are just implementing the process you outlined that has already been decided on by the community? Otherwise, what exactly would they be deciding on that would be out of scope of the already exiting way of doing things?
However, I suspect that the voting membership of the OSMF would oppose board candidates that would advocate for foundation involvement in tagging issues.
I don’t see what the “issue” would be if they are just implementing a tag that the community has already voted on and approved. In a way bureaucrats/arbiters are already involved in tagging issues when for example DWG members revert edits done by people who are using unpopular or unapproved tags. At least in the case of deprecation it would have an actual, wider benefit to the community outside of just tag fiddling to indulge the preferences of a small minority of confrontational users or whatever.
the procedure for tag deprecation through the tag proposal process so far didn’t have automatic retagging included, it leads to the tag being labeled “deprecated” in the wiki. Judging from taghistory, there are sometimes also some larger retagging efforts after this labeling, but they are not part of the tag proposal process (often they are not discussed or announced and every case would have to be individually assessed).
Sure, that’s technically true. But there’s generally an assumption with most people in the community that if a tag is voted on and approved that it depreciates whatever non-approved options exist at the time. Otherwise, it really shouldn’t be called “approval” and there’s no point in talking about depreciation in the first place The fact is that whatever the “technical”, semantics are that “approval makes unapproved tags go down” and there should be a more streamlined, concise process for doing that then currently exists.
The constant meta discussions about the “technicalities” in discussions like this really just holds up the project. It serves no one if it takes 15 years to replace a few instances of a tag to something that is “approved” just because approval isn’t about dictating how people have to map or whatever. Personally, I want to find the chicken shack I’m looking for when I search for it, not have to have find another restaurant because some random user 15 steps down (or up?) the ladder thought it was better to “offer options” instead of going with a tag that everyone else agrees on. I’m sure I’m not the only who feels that way.
You’re definitely not the only contributor that feels that way. Recent proponents for tagging standards include an OSMF board member and its former chairman. Also, a question on tagging standards was posed to the 11 candidates to the OSMF board, and you can find their answers here.
Unfortunately, anarchy on the project is a fact of life, and a small vocal minority, or even a single vocal contributor, can have enormous impact on what is tagged in the map. For example, the fact that we cannot get rid of service=driveway2 is a testament to the persistence of a single contributor.
This is the process that worked for you, but it extends beyond the official process. Should the official process include any of these steps beyond step 1? Do the proposers themselves need to take care of everything, soup to nuts, or could there be a formal option to ask the community to take care of step 4, in case they aren’t confident in their JOSM skills?
Often, proposers need to consider how their proposals fit together coherently and how to stage them strategically. Last year’s street parking refactor didn’t include any kind of mass editing procedure, partly because we anticipated another refactor in short order.
More broadly, at what stage should proposers consult or at least consider software developers, and how much weight should their feedback receive? Proposals typically mention data consumers, but often only openstreetmap-carto, and sometimes only as an afterthought. This is not only an issue with deprecations. Infamously, the transit:lanes proposal enjoyed organic growth for more than three years until editor developers unanimously vetoed it down. It included detailed algorithms for renderers and routers, but the routing engineers at Mapbox were quite unsure how to actually implement the handwavy algorithm in their real router.
By contrast, proponents of street parking refactoring recognized that the wiki doesn’t operate in a vacuum; they proactively reached out to the developers of StreetComplete, the parking lanes viewer, and A/B Street and even implemented a replacement JOSM map style. Maybe a less ambitious refactor can get away with less. For example, my proposal to formally allow units in ele includes a best-effort survey of existing data consumers, but as the proposal already reflects the status quo for the most part, I don’t expect to conduct quite as much outreach to developers ahead of a future vote. (For the record, the proposal is on hold until the U.S. officially deprecates the survey foot. If you think OSM’s deprecation process is torturous…)
I want to be very precise in my language here. We do not have an official process. We have a de facto process developed by ad hoc community interactions over a period of years, documented by a variety of authors editing several wikipages and enforced in an arbitrary way by various community actors.
There is. no. official. process.
Many have argued that the project would benefit from an official process in which an OSMF-endorsed mechanism existed to manage some aspect of tagging or mapping. Until or unless such a mechanism is realized I continue to beat the drum that the project is governed entirely by ad hoc human relationships when it comes to getting anything done. What may look like “process” to an uninitiated observer is really just smoke and mirrors.
The closest I’ve seen to a candidate addressing this forthrightly is Sarah Hoffmann’s answer to the tagging question where she says:
[…] such a working group would need to start with a study that researches the different options of standardization or consolidation of our tagging system, so that the community can have an informed discussion. Only then can we talk about how the OSMF can support a concrete evolution step.
I think that would get a great start should the OSMF be willing to tackle this question.
Otherwise, it really shouldn’t be called “approval” and there’s no point in talking about depreciation in the first place
indeed, for many years, deprecation wasn’t a topic, it is only in the younger past that deprecation is formalized, has gotten templates in the wiki, and is proposed in the tag proposal process.
I agree we better not talk about deprecating tags, it’s a huge waste of time.
My larger point is that large-scale editing is not the only often overlooked aspect of proposal-writing. Indeed, a mapper probably has a better working mental model of how to carry out a large-scale edit than of the changes that would be needed in editors, validators, renderers, geocoders, or routers in various languages. Many proposals have suffered from dysfunction and a lack of credibility among developers, not because of their malice or stubbornness, but rather because a case was made to mappers and mappers alone. The good news is that better communication could go a long way in addressing this problem.
If you don’t mind me asking, why do you think that’s the case? Like is deprecation (or at least talking about it) something that your category against doing or do you just think it’s not something the community/platform at large is capable of coping with in any significant way?
The fact is that whatever the “technical”, semantics are that “approval makes unapproved tags go down” and there should be a more streamlined, concise process for doing that then currently exists.