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 <sfkel...@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 <si...@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.ma...@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 ><si...@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...@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@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk >> >> _______________________________________________ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk >> >> _______________________________________________ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk >> _______________________________________________ >> talk mailing list >> talk@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk > >_______________________________________________ >talk mailing list >talk@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
