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

Mikel Maron mikel.maron at gmail.com
Fri May 10 13:44:09 UTC 2019


> 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
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20190510/8add0663/attachment.html>


More information about the talk mailing list