[OSM-talk] iD invents nosquare=yes for buildings which should not be squared

Fri May 10 17:57:17 UTC 2019

Hi,

Trying to get focus back on the thread topic.

Storing hints like nosquare=yes (or square=no) is not best practice of
data curation on w worldwide level.

At Thu., 9. Mai 2019 23:56 Simon Poole <simon at poole.ch> wrote:
> 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.
...
> I believe the issue is more about the unwillingness to take community
> feedback seriously ...

This attitude needs to be changed. I expect a discussion on tags like
this on a broader level (i.e. outside issue trackers) _before_ it's
being implement in an editor like iD.

> Which brings us back full circle to the discussion of the privileged position
> of the default editor on openstreetmap.org and the related transparency ...

Currently the OSMF Board is doing a community survey about topics and
issues that matter to us (https://osmf.limequery.org/489698?lang=en ).
I think this issue becomes one of my inputs.

:Stefan

Am Fr., 10. Mai 2019 um 15:47 Uhr schrieb Mikel Maron <mikel.maron at gmail.com>:
>
> > 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 <simon at poole.ch> 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 <osm-ml at michreichert.de> 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
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk