Re: [Tagging] Proposal process [was: healthcare]
Vào lúc 03:26 2022-11-06, m...@marcos-martinez.net đã viết: Some time ago I asked Alexander Borsuk (Organic Maps). The context was the debate on the "contact" controversy but it can be extended to other less heated topics... (The conversation was in the open OM Telegram channel and can be found by everyone, so I am not disclosing opinion, subject to privacy) The key sentences for me are: "A bigger problem is different public transport schemes, where it’s way harder to write a “converter” from one into another. For example, subway map in Vienna was missing because local community decided that it’s ok to have two different level platforms in one stop_area. That is really a pain." "...the proper way would be to merge into multiple values for one chosen tag (and filter duplicate values, of course). That’s a bit of a hassle, but it is solvable." "Of course it is easier if all tags have the same scheme. Then we don’t spend our time on the scheme differences, focusing on a better product instead." Let me ask you then: Can you provide evidence or a few examples in which tag standardization is harmful or represents any disadvantage? Data consumers aren't a monolith. Churn in our tagging schemes can break existing software and harm end users in the real world, unless we set up migration paths and raise awareness. Conversely, if we don't clean up our tagging schemes at all, then we make it harder for developers to adopt new kinds of OSM data effectively. Fortunately, there aren't too many high-profile examples of tagging churn deliberately breaking data consumers. This community has been careful to preserve backwards compatibility -- you might say too careful. One example I'm aware of is that, for years, the definition of highway=trunk in the United States had differed from the global definition, focusing on physical characteristics, but since last year there has been an effort to harmonize the definition and shunt the physical characteristics over to expressway=yes. [1] This will require changes to some routers such as Valhalla that include highway=trunk in the "Avoid Highways" option, under the assumption that this tag consistently indicates an expressway. Sometimes breakage happens unintentionally. Several years ago, I and other mappers in the U.S. and Canada started using restriction=no_left/right_turn_on_red to indicate a turn-on-red restriction, which up to that point had no established tagging. [2] This *_on_red suffix briefly broke OSRM, which had been relying on an obscure clause that someone inserted into the restriction=* page stating that data consumers could ignore everything after the no_* or only_* prefix. Since turn-on-red restrictions are very common in downtown areas, these restrictions effectively made it impossible to route through these areas. Whoever added this clause to the wiki had good intentions for making OSM easier and more elegant to use, but data consumers noticed it before mappers did. Ironically, it was a premature optimization: OSRM ultimately required nothing more than a one-line change. [3] To the extent that we care about both new and existing data consumers, we should strive to balance their disparate needs. One reason that dual-tagging grace periods last so long is that we don't have a very clear understanding of who all is using OSM and how, but we know of plenty of software that's still in use but no longer maintained. Software engineers refer to Hyrum's law [4] as shorthand for the fact that churning an API will always break someone, even for the silliest of reasons. [5] Breaking changes are sometimes unavoidable, but there should be a convincing reason for the breakage when the stakes are high. Otherwise, the impact to OSM's reputation would be higher than any upfront messiness, which we already mitigate by providing a critical mass of data that you can't find anywhere else. Sometimes a convincing reason could be that the old tag is getting in the way of mapping things we want to map but can't express using existing tags. The crossing:markings=* proposal didn't deprecate crossing=* [6], but I think future proposals could chip away at crossing=*, as we find that there are more crossing configurations that we can't express using that key alone. [1] https://wiki.openstreetmap.org/wiki/United_States/Highway_classification [2] https://wiki.openstreetmap.org/wiki/No_turn_on_red [3] https://github.com/Project-OSRM/osrm-backend/pull/4811 [4] https://www.hyrumslaw.com/ [5] https://xkcd.com/1172/ [6] https://wiki.openstreetmap.org/wiki/Proposed_features/crossing:markings -- m...@nguyen.cincinnati.oh.us ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal process [was: healthcare]
Hi Martin, you are comparing the wrong things. What I tried to say: Generally speaking we should strive for improving things. As we are talking about a database, standardization can be part of the solution and should be something considered desirable. It shouldn't be a valid argument against it to say "we can also use a workaround, you see? It's only requires a little more effort and still provides the same result." Give me one reason for not doing it right from the start. I didn't compare OSM with sand and didn't advocate at all to move it with a caterpillar. But let me take it further: The sandcastle is actually a pretty good example for how OSM works. At the beginning people started to put the big chunks at the bottom, they were few and pretty soon were able to agree on building some kind of solid foundation (highways and buildings are generally speaking a de facto standardization right now) but with time more and more people got involved and started doing their own things and it has become increasingly difficult to agree on how to build them, making it more unstable (nowadays the only thing we know for sure when tagging something as " forest" or "wood" is that you will probably find some trees there. Additional value doesn't exist). More and more details and decoration is being built on top of it and the castle is more and more shaking. To fix things you now must use a tiny spoon to prevent the whole construction from coming down. Something that will happen on it sown the higher you build it without a proper structure below. Can we change it without destroying the whole castle? Sure, it is up to us. We should be able to decide what should be the means, the time and extend of what we want to amend, modify and improve according to its importance within the castle and its benefits. We should be able to decide that at least from now on we want any addition to be more structured and agreed on, if necessary with documented, local variations and exceptions, so that other people can build more safely on top. As I say, it is up to us and this community is full of competent and dedicated people, capable of finding the right balance. But only if we wanted to, because right now this doesn't exist and the castle keeps growing in size and instability. Cheers Am 06.11.2022 13:00, schrieb Martin Koppenhoefer: sent from a phone On 6 Nov 2022, at 12:34, m...@marcos-martinez.net wrote: Regarding standardization: First of all, I hope we all work on the basis that we want to improve things. Can you move a ton of sand with a spoon? thing is, we don't have just a heap of sand, we have hundreds of thousands of people having contributed by adding small parts of a gigantic castle like structure made of sand, and these people expect following mappers to use spoons so that the initial work isn't inadvertently destroyed, as would be the case when moving the castle with a caterpillar. They also object to people who propose changing the sand underneath the visible structure with sand of a different color, because they fear it could make the whole structure collapse and because it won't be visible anyway. ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal process [was: healthcare]
sent from a phone > On 6 Nov 2022, at 12:34, m...@marcos-martinez.net wrote: > > Regarding standardization: First of all, I hope we all work on the basis that > we want to improve things. Can you move a ton of sand with a spoon? thing is, we don’t have just a heap of sand, we have hundreds of thousands of people having contributed by adding small parts of a gigantic castle like structure made of sand, and these people expect following mappers to use spoons so that the initial work isn’t inadvertently destroyed, as would be the case when moving the castle with a caterpillar. They also object to people who propose changing the sand underneath the visible structure with sand of a different color, because they fear it could make the whole structure collapse and because it won’t be visible anyway. ;-) ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Proposal process [was: healthcare]
Hi Brian, I appreciate all the effort you underwent with the "river tagging scheme. I do mean it. And I support it. Now, the process to achieve it seems ridiculously hard. You say people "reached out across many channels to discuss the proposed changes", "I had to discuss the specifics of river tagging with many many people. Those people talked to other people." They "generated statistics, procedures, and visualizations of our progress". And in spite of 99% completion I personally could just go out and tag the old way with anyone having the right to "correct" it if I was willing to fight for it. This is why the process is dysfunctional. It is dysfunctional because there is no established path which people you need to talk to, which software support you need and how to do it, how many people you need to convince, etc. Sometimes you can be lucky. People like you can make a huge effort and what is proposed is overwhelmingly convincing. I won't deny that in those cases things can happen. At least from what I see here, if this isn't the case there is no way to reach any decision that really means something. I still don't understand why we are not able to create a space where all these people you mention can come together, discuss a scheme and the community finally adopts it - or not. It would be exactly the same as what you have done but in less time, with less effort, more transparent an inclusive. A space where regular mappers, software developers and any other stakeholders know that THIS is the space where we come together to add, improve, modify things, a space where decisions are made and everybody can be heard. And most importantly to finally reach a conclusion on how we want to do things. Regarding standardization: First of all, I hope we all work on the basis that we want to improve things. Can you move a ton of sand with a spoon? Sure, but it will take you days and with an excavator you are done in 5 minutes. My point is that you CAN do something or that somethings WORKS doesn't mean we can do something or make that somethings works better. Some time ago I asked Alexander Borsuk (Organic Maps). The context was the debate on the "contact" controversy but it can be extended to other less heated topics... (The conversation was in the open OM Telegram channel and can be found by everyone, so I am not disclosing opinion, subject to privacy) The key sentences for me are: "A bigger problem is different public transport schemes, where it's way harder to write a "converter" from one into another. For example, subway map in Vienna was missing because local community decided that it's ok to have two different level platforms in one stop_area. That is really a pain." "...the proper way would be to merge into multiple values for one chosen tag (and filter duplicate values, of course). That's a bit of a hassle, but it is solvable." "Of course it is easier if all tags have the same scheme. Then we don't spend our time on the scheme differences, focusing on a better product instead." Let me ask you then: Can you provide evidence or a few examples in which tag standardization is harmful or represents any disadvantage? Cheers Am 06.11.2022 01:00, schrieb Brian M. Sperlongano: On Sat, Nov 5, 2022 at 6:45 PM Robin Burek wrote: And if we now get to the point of just "throwing away" the consensus of 12 years ago. do we still need the proposal process at all? Because the result from 12 years ago is also completely ignored by you. it was already decided to deprecate in 2010, but no one has finally implemented it. What you are discovering firsthand, are the limits of the proposal system. Indeed I encountered the same challenges. A proposal compels nobody to do anything. A proposal is nothing more than a communication tool to demonstrate support for an idea to other players in the community. It's a signal to other parts of the ecosystem. In other words, if the participants thought something was a good idea a decade ago, but the rest of the community (mappers, renderers, editors, data consumers) didn't adopt the change, in reality, then the persuasive value of that approved proposal from 12 years ago has faded significantly. In this community, we seem to be moving further and further into a system where improvements to the system are massively prevented and established double tagging is simply left in place instead of finally being cleaned up. I don't agree this has "moved" at all! The project has always operated this way. Eliminating duplicate tagging that has been supplanted by a newer approved tag is obscenely difficult. I led an effort to resolve duplicate river area tagging to 99% completion[1]. which was also a change that was the subject of an approved 2010 proposal. Despite the approved proposal, it was still controversial, with some community members disagreeing about exactly what was approved due to how the proposal
Re: [Tagging] Proposal process [was: healthcare]
> If that sounds like a lot of work -- it was! And just for a single tag! > But THAT is the scope and scale of effort that it's going to take to > change tagging that has tens to hundreds of thousands of objects tagged. > You need overwhelming agreement AND enough support from motivated > community members to make all the pieces of the ground game come > together. Is this an indication that our community is dysfunctional? > Maybe. But it's 100% the reality that we live in if you want to > accomplish wide-ranging change. > > If you want to propose tagging for something that's never been mapped > before, a proposal is a great way to ensure that the tag you're making > up is reasonable. If you want to make a change of significant scope and > scale to tagging on the project, you must understand that a proposal is > only a single tool to generate support for your idea, which must be part > of a broader effort towards consensus-building and community action. > If you want to put it bluntly: YES, this project is really dysfunctional in this case. It takes time to "clean up" and organize one's system and effectively people misunderstand the implications of the proposal process. Editors in particular point out that a tag is not approved. However, the majority of users map according to wiki or editor specifications. (Where especially JOSM never followed the proposal and kept the old tagging in its specifications). And I don't go along with it at all that that's 100% reality. I work in the field of process optimization. Among other things with customers in the health sector, but also very many other areas, chemistry, construction. Companies from 500 to 50k employees. Nowhere have I seen such dysfunctional countercurrents to standardization and simplification. Not even remotely. It is well known and state of the art that simplification and systematization clearly lead to positive effects on a system. Anyone who ignores this does not think that there is a future. At some point I stopped counting how often I heard "We've always done it this way" at the beginning, but what I heard at the end, after many steps had been implemented and optimized: "Oh, that's going much better now". And that's exactly what we're hiding from here again. YES, such steps are uncomfortable. But structural optimization always brings positive effects at the end. Above all, I find it dysfunctional that criticism is not voiced right from the start, but only at the end, when it is the very last thing to be mentioned for adjustments (here in the proposal). Also always this "Mappers have decided" - no, it's the editors. It's the editors that provide presets. And if we as a community don't want to "push through" when a proposal has been accepted, then it will always be based on the decision of a few individual programmers. Who should own a project? And then it becomes clear again what the proposal itself has as a systematic building block for a meaning. And now I'm really asking: What speaks against standardization? And above all against the enforcement of consensus and proposals? I only see negative effects that many end up cringe in frustration if we don't take seriously the importance of this tool. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Proposal process [was: healthcare]
On Sat, Nov 5, 2022 at 6:45 PM Robin Burek wrote: > And if we now get to the point of just "throwing away" the consensus of 12 > years ago. > > do we still need the proposal process at all? Because the result from 12 > years ago is also completely ignored by you. > it was already decided to deprecate in 2010, but no one has finally > implemented it. > What you are discovering firsthand, are the limits of the proposal system. Indeed I encountered the same challenges. A proposal compels nobody to do anything. A proposal is nothing more than a communication tool to demonstrate support for an idea to other players in the community. It's a signal to other parts of the ecosystem. In other words, if the participants thought something was a good idea a decade ago, but the rest of the community (mappers, renderers, editors, data consumers) didn't adopt the change, in reality, then the persuasive value of that approved proposal from 12 years ago has faded significantly. In this community, we seem to be moving further and further into a system > where improvements to the system are massively prevented and established > double tagging is simply left in place instead of finally being cleaned up. > I don't agree this has "moved" at all! The project has always operated this way. Eliminating duplicate tagging that has been supplanted by a newer approved tag is obscenely difficult. I led an effort to resolve duplicate river area tagging to 99% completion[1]. which was also a change that was the subject of an approved 2010 proposal. Despite the approved proposal, it was still controversial, with some community members disagreeing about exactly what was approved due to how the proposal was worded and debating whether the old approval was still valid or even a good idea. The river project accomplished its goal because enough mappers cared about it to have community discussions about river tagging in countries worldwide. They reached out across many channels to discuss the proposed changes and the value it brought. And even with that, some people disagreed, and we had some rough spots early on in the process. The retagging was followed up with proposals and PRs to change software support across the project's tooling to drop the old tag. I was the biggest advocate for the change, but it only happened because I was met with strong agreement. Building consensus is hard. I had to write really clear and persuasive documentation. I had to discuss the specifics of river tagging with many many people. Those people talked to other people. Other mappers generated statistics, procedures, and visualizations of our progress. At one point, I even gave a "Mappy Hour" talk[2] on the project. If that sounds like a lot of work -- it was! And just for a single tag! But THAT is the scope and scale of effort that it's going to take to change tagging that has tens to hundreds of thousands of objects tagged. You need overwhelming agreement AND enough support from motivated community members to make all the pieces of the ground game come together. Is this an indication that our community is dysfunctional? Maybe. But it's 100% the reality that we live in if you want to accomplish wide-ranging change. This, by the way, is one reason why certain companies refuse to use OSM > data. The data structure is unnecessarily inflated and complicated by such > duplications. If we don't stick to our own conventions and enforce > consensus, perhaps the consensus process should be abolished altogether? > This point would be much stronger if you could point to a specific company that refused to use OSM data. I've asked for concrete examples about why our free-for-all is a problem, but I always seem to get hand-waving instead about the general benefits of standardization[3], which is the reason I've submitted a question to the candidates in the OSMF election to see where they stand on it[4]. While I don't like duplicate tagging, I have so far not seen a convincing argument that it's particularly troublesome, and this is speaking as someone that's built and operates a service that uses OSM data. If you want to propose tagging for something that's never been mapped before, a proposal is a great way to ensure that the tag you're making up is reasonable. If you want to make a change of significant scope and scale to tagging on the project, you must understand that a proposal is only a single tool to generate support for your idea, which must be part of a broader effort towards consensus-building and community action. [1] https://wiki.openstreetmap.org/wiki/WikiProject_Waterways/River_modernization [2] https://www.youtube.com/watch?v=c5YwXDKGr2Y [3] https://lists.openstreetmap.org/pipermail/tagging/2022-October/066238.html [4] https://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM2022/Election_to_Board#Question:_Tagging_Standards ___ Tagging mailing list Tagging@openstreetmap.org
