> I believe the issue is more about the unwillingness to take community
> feedback seriously at all when it doesn't coincide with the opinions already
> held by the developers. Which brings us back full circle to the discussion of
> the privileged position of the default editor on openstreetmap.org and the
> related transparency (aka who is holding the purse strings) and the
> non-existent community control or even just control by the OSMF.
This is a very interesting paragraph, dense with deep topics for the OSM
project. These topics should separate this from the particulars of individual
situations, because the dynamics are not unique to any single component of the
OSM data and software ecosystem. OSM has always been a muddle and arguably one
of the reasons for its success. In OSM people disagree, there's strong points
of view and discussion, sometimes it resolves, often times we continue to
muddle through. Yes, the OSMF has ultimately legal authority over all aspects
of the project but by design and history, exercises it very selectively. And
community is a very amorphous concept, with disagreements over what that means
and how it functions.
Certainly the shape of the OSM project has outgrown the systems we haphazardly
put in place for governance and community back in 2007. It's worth stepping
back from many of the recent heated issues in the community, and look at how
they are the result of growth without intentional adaptation, and consider what
kind of approach we can take to imagine what OSM is like in the next 15 years.
-Mikel
* Mikel Maron * +14152835207 @mikel s:mikelmaron
On Thursday, May 9, 2019, 5:56:14 PM EDT, Simon Poole <[email protected]>
wrote:
Am 09.05.2019 um 23:14 schrieb Mikel Maron:
> What do you think? Should the next version of iD be deployed on
www.openstreetmap.org?
Absolutely. My understanding is this feature will greatly improve data
quality in OSM. I think it's fair to validate squareness of existing buildings.
Appreciate the great work of the iD team.
The question was not about validating square or not square buildings, it is
about storing a hint for iDs validation mechanism permanently in OSMs data.
There is some precedent for doing so, as was mentioned in the github issue,
still it is a bit controversial and discussion when adding such a feature
should be expected.
[Rant on the massively overrated concern for buildings in the first place and
the background why people think that such a validation is necessary omitted]
Also commend your attention to tagging issues Michael. There's certainly a
broader issue with how tags are managed in OSM. In short it's a mess all around
and is in need of a rethink. I don't think this minor issue is a "hill to die
on" however.
I believe the issue is more about the unwillingness to take community feedback
seriously at all when it doesn't coincide with the opinions already held by the
developers. Which brings us back full circle to the discussion of the
privileged position of the default editor on openstreetmap.org and the related
transparency (aka who is holding the purse strings) and the non-existent
community control or even just control by the OSMF.
Simon
-Mikel
* Mikel Maron * +14152835207 @mikel s:mikelmaron
On Thursday, May 9, 2019, 4:18:20 PM EDT, Michael Reichert
<[email protected]> wrote:
Hi,
this could be seen as a tagging discussion but I think that it is a
discussion on governance and power. That's why this email goes to the
Talk mailing list.
Quincy Morgan, one of the maintainers of iD, invented a new tag called
nosquare=yes today which should be added to buildings which are not
square and should not be flagged by iD's validator. I (and later Paul
Norman) pointed out issues with the tag. I asked Quincy to discuss the
addition with the wider community beforehand.
https://github.com/openstreetmap/iD/issues/6332
Here are the issues I pointed out in the bugtracker. At the beginning he
planned to use square=no which he later changed to nosquare=yes but this
change does not make things better:
> Although noname=yes is common, it is not that common that it can serve as
an argument in favour of introducing unsquare=yes. In difference to noexit=yes,
unsquare=yes and noname=yes only serve as a workaround for quality assurance
tools. noexit=yes also conveys information for map users: There road ends here.
>
> Some people prefer to tag as complete as possible and add oneway=no,
cycleway=no, lit=no etc. to any way. However, such a practice is not base on a
broad consensus and if you dig deep enough in the history of user blocks in
OSM, you might find blocks set due to an excessive use of negative binary tags.
>
> I think that iD does not need this tag and should only validate buildings
if they have been added or modified in the current session. If doing so, they
will be reported once which does not bother that much.
>
> Adding such a tag is not a simple change as it might seem to be and I ask
you to discuss it with the broader community on the Tagging mailing list.
What do you think? Should the next version of iD be deployed on
www.openstreetmap.org?
Best regards
Michael
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
_______________________________________________
talk mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk
