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

Yves yvecai at mailbox.org
Fri May 10 19:36:02 UTC 2019


Some validation tools, like Osmose, make great efforts to maintain a 'false positive' database.
Also, I don't think such validation of building orthogonality should take place at editing stage. A hint to the squaring tool or shortcut when someone is mapping almost square buildings is probably a better user experience.
Yves 

Le 10 mai 2019 19:57:17 GMT+02:00, Stefan Keller <sfkeller at gmail.com> a écrit :
>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
>
>_______________________________________________
>talk mailing list
>talk at openstreetmap.org
>https://lists.openstreetmap.org/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20190510/77f293bd/attachment.html>


More information about the talk mailing list