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

[severin.menard via talk]

Automatic translation with Deepl below

Bonjour à tous,

Je reviens sur ce fil de discussion qui ne semble pas avoir fait émerger une 
décision quant au parti pris par Quincy Morgan concernant iD, et ne répond pas 
à une question plus large. Quelle est actuellement la gouvernance autour d’iD ? 
Je connais personnellement peu ce projet dans la mesure où je n’utilise pas cet 
éditeur, et la page https://wiki.openstreetmap.org/wiki/ID dédiée dans le wiki 
OSM ne parle pas de l’historique et sa gouvernance, tandis que ses pages GitHub 
ne mentionnent seulement que son financement initial. Il s’agissait au départ 
d’un projet de Mapbox, et au vu de la très rapide réaction de Mikel au courriel 
initial de Michael pour défendre la décision de Quincy Morgan, cela m’a laissé 
pensé que c’était toujours le cas. Le projet est hébergé sous 
https://github.com/openstreetmap qui gère également entre autres le site web 
openstreetmap.org, osmosis et autres projets liés à la Fondation OSM. D’après 
https://github.com/openstreetmap/iD/graphs/contributors les contributions 
actuelles ont essentiellement celles de Quincy Morgan qui indique être un 
full-time collaborator d’ID (financé, volontaire ?) et qui semble travailler 
pour la société http://www.critigen.com/, ainsi que Bryan Housel qui semble 
toujours travailler chez Mapbox.

Le souci est que ce n’est malheureusement pas la première fois que les 
développeurs d’iD décident d’implémenter le tagging de leur choix sans chercher 
à en discuter au préalable avec la communauté. WeeklyOSM s’était fait l’écho 
qu’il y a quelques semaines (http://weeklyosm.eu/archives/11846) de cette 
sortie de Bryan Housel : “I basically just disregard everything on the tagging 
mailing list and the OSM wiki”.

Il est évident que l’éditeur en ligne par défaut d’OSM ne peut être orienté par 
deux personnes qui décident de ne pas interagir avec la communauté ou 
n'acceptent pas la contradiction.

Séverin

-

Hi,

I come back to this thread that does not seem to have led to a decision about 
Quincy Morgan's bias on iD, and does not answer a broader question. What is the 
current governance around iD?  I personally know little about this project 
because I don't use this editor, and the dedicated page 
https://wiki.openstreetmap.org/wiki/ID in the OSM wiki doesn't talk about the 
history and governance, while its GitHub pages only mention its initial 
funding. It was initially a Mapbox project, and given Mikel's very quick 
reaction to Michael's initial email to defend Quincy Morgan's decision, it left 
me thinking that it was still the case. The project is hosted at 
https://github.com/openstreetmap, which also manages the openstreetmap.org 
website, osmosis and other projects related to the OSM Foundation. According to 
https://github.com/openstreetmap/iD/graphs/contributors the current 
contributions have mainly those of Quincy Morgan who indicates that he is a 
full-time ID collaborator (funded, voluntary?) and who seems to work for the 
company http://www.critigen.com/, as well as Bryan Housel who still seems to 
work at Mapbox.
The concern is that this is unfortunately not the first time that iD developers 
have decided to implement the tagging of their choice without first discussing 
it with the community. WeeklyOSM echoed that a few weeks ago 
(http://weeklyosm.eu/archives/11846) Bryan Housel's release: "I basically just 
disregard everything on the tagging mailing list and the OSM wiki".
It is obvious that the default online editor of OSM cannot be guided by two 
people who decide not to interact with the community or do not accept the 
contradiction.

Séverin

Translated with www.DeepL.com/Translator___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Simon Poole]

Just a general remark on the technical issue that sparked of this
discussion:  squaring buildings is not primarily about improving data
quality. Non-square buildings are simply visually annoying when
rendered, so much that I support squaring them "as a rule" too when it
can reasonably be assumed that there are 90° angles in the actual
building outline. But I'm not kidding myself that it improves "quality".
If we wanted to define quality of building outlines in OSM we would
probably be talking about deviations from the buildings footprint area,
average deviations from the outline and so on, any of these could be
very small even without squaring. Actually, squaring might impact them
negatively, particularly when the outline is rough, but as said: square
buildings are just so much easier on the eyes :-).

Simon

Am 10.05.2019 um 21:05 schrieb Pierre Béland via talk:
> May 20 2019 at 14 h 02 min 51 s UTC−4, Stefan Keller
>  wrote :
>
> > 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.
>
> I dont think either that this is the solution.  We have to look where
> these problems come and try to correct from the source.  Adding  such
> tag will not help software tools to identify where we have problems
> and can create some missunderstanding about its meaning. And
> experienced mappers are more and more reluctant to correct inprecise
> building mapping.
>
> For Newbies, Building Quality Analysis last year this show some
> Tasking Manager projects with some 60% of unsquarred buldings (see
> https://opendatalabrdc.github.io/Blog/#!Database_Quality_Analysis_Tasking_Manager.md).
>
> The same problem for the DR Congo Ebola response in november where we
> had to restart mapping Butembo in an emergency response and restrict
> mapping to experienced mappers.
>
> For an editor like iD, it can participate with other solutions like
> better training to assure that Newbies understand what Building
> tracing really mean and give then some feedback, like for example
> saying before save "You have 10 over 12 buildings that are
> unsquarred.  If you dont know how to make rectangular buildings, you
> should ask for help before you continue.  Do you want to send data
> anyway ?"
>
> We have the same problem with some Building import projects and I
> think that this needs to be fixed where it originates, before it goes
> in the database.  For newbies, this mean more training and monitoring
> in particular in the context of Mapathons.
>
> For Imports, this mean to analyze carefully and correct the data
> before the Import.
>  
> Pierre
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Mateusz Konieczny]

9 May 2019, 22:14 by osm...@michreichert.de:

> What do you think? Should the next version of iD be deployed on
> www.openstreetmap.org > ?
>
Before going for a nuclear solution - is there already refused issue that asks 
to reconsider
problematic parts (nosquare=yes, ability to validate all buildings, not just 
created/modified
or whatever part is considered as problematic)?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yuri Astrakhan]

On Fri, May 10, 2019 at 3:39 PM Yves  wrote:

> Some validation tools, like Osmose, make great efforts to maintain a
> 'false positive' database.
>

If the same validation is done by multiple tools, they need to share the
"false positive" data, otherwise only one tool would know not to change
something, while another tool will encourage the user to make the same
mistake.

So we either have to set up an OSM shadow database that contains all
exceptions, e.g. "object  is exempt from validation ", or this data
should be stored in the object itself, which seems to be a far more robust
approach (same data store allows data consistency / versioning / user
management / tracking / consistency between tools / same processing
pipeline / ...).

If the objection to this is that users don't want to see junk data, I agree
-- but we could simply dedicate a key namespace to validations, and hide it
by default in JOSM and iD.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yves]

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  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  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
>:
>>
>> > 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
> 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 

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

[Pierre Béland via talk]

May 20 2019 at 14 h 02 min 51 s UTC−4, Stefan Keller  wrote 
: 
> 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.
I dont think either that this is the solution.  We have to look where these 
problems come and try to correct from the source.  Adding  such tag will not 
help software tools to identify where we have problems and can create some 
missunderstanding about its meaning. And experienced mappers are more and more 
reluctant to correct inprecise building mapping.

For Newbies, Building Quality Analysis last year this show some Tasking Manager 
projects with some 60% of unsquarred buldings (see 
https://opendatalabrdc.github.io/Blog/#!Database_Quality_Analysis_Tasking_Manager.md).
 
The same problem for the DR Congo Ebola response in november where we had to 
restart mapping Butembo in an emergency response and restrict mapping to 
experienced mappers.

For an editor like iD, it can participate with other solutions like better 
training to assure that Newbies understand what Building tracing really mean 
and give then some feedback, like for example saying before save "You have 10 
over 12 buildings that are unsquarred.  If you dont know how to make 
rectangular buildings, you should ask for help before you continue.  Do you 
want to send data anyway ?"

We have the same problem with some Building import projects and I think that 
this needs to be fixed where it originates, before it goes in the database.  
For newbies, this mean more training and monitoring in particular in the 
context of Mapathons.
For Imports, this mean to analyze carefully and correct the data before the 
Import.
 
Pierre 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Stefan Keller]

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  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 :
>
> > 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  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 
>  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 

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

[Mikel Maron]

> 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  
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 
 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 

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

[Florian Lohoff]

Hola,

On Thu, May 09, 2019 at 06:00:20PM -0400, Jmapb wrote:
> This strikes me as a pretty bad idea. I map in NYC where we have lots,
> lots, lots of nearly-square buildings with official footprints imported
> from the city's open data initiative. When a mapper not familiar with
> the history here gets a message from iD (which, to many mappers, is
> indistinguishable from getting a message from OSM itself) encouraging
> them to square a building, they'll do it because it seems like the right
> thing to do. So the official, highly-accurate footprints are lost. And
> adjacent buildings with shared nodes are also distorted.

I agree on this. Its a bad idea for nearly square buildings to complain 
on them. Not everying is 90° - Not even in Germany where we love
rectangular things.

But the point is that i'd like a generic way to to qa/validation
hinting. I just sent a similar mail in in a similar thread on the 
German mailinglist.

I'd like to see qa/validation hinting tags be more organised:

qa:rectangular=no
qa:exit=no
qa:name=no
qa:housenumber=no

or the list form:

validation_hint=noexit;noname;norectangular;nohousenumber

So every validator could have the "suppress check XYZ" on this object.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Lester]

On 09/05/2019 23:21, Michael Reichert wrote:

JOSM runs its validation rules only on objects modified or created in
the current session. This seems more sensible both for experienced users
and newbies for two reasons:

- Uses don't get overwhelmed with dozens or hundreds of reports on
   objects they did not touch.

- If users follow suggestions how to fix blindly (we cannot expect an
   unexperienced iD user to have the same knowledge as the average JOSM
   user), they are used as living bots running validation rules on
   randomly selected areas of the map. One might call this a hidden
   automated edit.


Been some time since I put buildings in, but surely the the right way to 
handle ADDING a square building is just to select 'box' and position 2 
diagonal corners? With the logic picking up the adjacent corners of 
another square building? This is a drawing problem rather than something 
that gets tagged to sort out later? A row of houses simply square off an 
existing wall. Editing a block of building drawn as a single block to 
provide individual units needs the right tools rather than some tag 
saying 'this block was not square last time I drew it'?


--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

--
Lester Caine - G8HFL
-
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.co.uk
Rainbow Digital Media - https://rainbowdigitalmedia.co.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Greg Troxel]

Michael Reichert  writes:

> JOSM runs its validation rules only on objects modified or created in
> the current session. This seems more sensible both for experienced users
> and newbies for two reasons:

That seems like the right thing to do.

> - Uses don't get overwhelmed with dozens or hundreds of reports on
>   objects they did not touch.
>
> - If users follow suggestions how to fix blindly (we cannot expect an
>   unexperienced iD user to have the same knowledge as the average JOSM
>   user), they are used as living bots running validation rules on
>   randomly selected areas of the map. One might call this a hidden
>   automated edit.

It is very definitely an automated edit, and it is irresponsible to
deploy such a thing without going through the mechanical edit policy.

Obviouusly squaring all buildings would fail as a proposed mechanical
edit, because there is no basis to believe that this is almost always an
improvement.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Jmapb]

On 5/9/2019 6:21 PM, Michael Reichert wrote:


JOSM runs its validation rules only on objects modified or created in
the current session. This seems more sensible both for experienced users
and newbies for two reasons:

- Uses don't get overwhelmed with dozens or hundreds of reports on
   objects they did not touch.


This makes perfect sense, and in fact I see that "Almost right angle
buildings" is still in my JOSM validator option list, and still
checked.  I don't know what caused the rash of building squaring that I
saw in NYC -- perhaps the sensitivity was adjusted at some point? I
haven't had this validation error come up in my own work for a long time.


- If users follow suggestions how to fix blindly (we cannot expect an
   unexperienced iD user to have the same knowledge as the average JOSM
   user), they are used as living bots running validation rules on
   randomly selected areas of the map. One might call this a hidden
   automated edit.

In difference, iD runs its validation rules on all loaded objects.
https://github.com/openstreetmap/iD/issues/6332#issuecomment-490494331


That's a good way to describe a lot of iD's effects in general --
mappers become living bots implementing the iD devs' ideas, under the
impression that these are the official recommendations of the OSM project.

Jason


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Michael Reichert]

Hi,

Am 10.05.19 um 00:00 schrieb Jmapb:
> This strikes me as a pretty bad idea. I map in NYC where we have lots,
> lots, lots of nearly-square buildings with official footprints imported
> from the city's open data initiative. When a mapper not familiar with
> the history here gets a message from iD (which, to many mappers, is
> indistinguishable from getting a message from OSM itself) encouraging
> them to square a building, they'll do it because it seems like the right
> thing to do. So the official, highly-accurate footprints are lost. And
> adjacent buildings with shared nodes are also distorted.

JOSM runs its validation rules only on objects modified or created in
the current session. This seems more sensible both for experienced users
and newbies for two reasons:

- Uses don't get overwhelmed with dozens or hundreds of reports on
  objects they did not touch.

- If users follow suggestions how to fix blindly (we cannot expect an
  unexperienced iD user to have the same knowledge as the average JOSM
  user), they are used as living bots running validation rules on
  randomly selected areas of the map. One might call this a hidden
  automated edit.

In difference, iD runs its validation rules on all loaded objects.
https://github.com/openstreetmap/iD/issues/6332#issuecomment-490494331

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Christoph Hormann]

On Thursday 09 May 2019, Simon Poole 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.

Note the nosquare=yes concept is fundamentally different from things 
like noexit=yes because it classifies and aggregates multiple 
continuous values (the angles of all the corners of a building) into 
one binary yes/no value.  For the definition of nosquare=yes i will 
ultimately have to look into the iD validator source code to find out 
how exactly it checks if a building is square or not.  Strictly 
speaking it is not even a verifiable tag (which noexit=yes is).

> 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.

Indeed.

I had a bit of hope that the golf=cartpath debacle would be a bit of an 
eye opener and would lead to some increased awareness for the need of 
consultation with the broader community when making tagging related 
decisions.  But it does not look like it now.

-- 
Christoph Hormann
http://www.imagico.de/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Michael Reichert]

Hi Mikel,

Am 09.05.19 um 23:14 schrieb Mikel Maron:
> Absolutely. My understanding is this feature will greatly improve data 
> quality in OSM. I think it's fair to validate squareness of existing 
> buildings.

I did not say that I am against the validation rule itself. I agree that
the rule is a great step forward. However, the turn-validation-off tag
is not necessary because most buildings are edited only one time:

ways with building=* except building=no:  341403310
  thereof version == 1:   277493561 (81.3 %)
relations with building=* except building=no:630284
  thereof version == 1:  406731 (64.5 %)

Limited to objects edited after 2017-01-01T00:00:00Z:

ways with building=* except building=no:  151163160
  thereof version == 1:   125435755 (83.0 %)
relations with building=* except building=no:349731
  thereof version == 1:  184564 (52.8 %)

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[john whelan]

I agree it's a bad idea inflating the database size and I don't agree that
all buildings should be square.  Let iD warn about buildings mapped in this
session by all means but that does not require all existing buildings to be
square.

Cheerio John

On Thu, 9 May 2019 at 18:02, Jmapb  wrote:

> On 5/9/2019 4:14 PM, Michael Reichert wrote
>
> > 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.
>
> This strikes me as a pretty bad idea. I map in NYC where we have lots,
> lots, lots of nearly-square buildings with official footprints imported
> from the city's open data initiative. When a mapper not familiar with
> the history here gets a message from iD (which, to many mappers, is
> indistinguishable from getting a message from OSM itself) encouraging
> them to square a building, they'll do it because it seems like the right
> thing to do. So the official, highly-accurate footprints are lost. And
> adjacent buildings with shared nodes are also distorted.
>
> If I were to communicate with this mapper and say "Hi, welcome, please
> don't square the buildings" it will simply be confusing because the
> official editor, hosted at https://www.openstreetmap.org, told them they
> should.
>
> JOSM's validator used to flag nearly-square buildings here, and it
> caused thousands of unnecessary and inaccurate updates to building
> footprints. And of course people doing these thought they were doing the
> right thing -- if the validator says there's a problem, there's a
> problem, right? Fixing it is helping the map!
>
> I'd hate to see iD go down the same road. And I certainly don't want to
> mass-tag all of NYC's imported buildings with nosquare=yes.
>
> J
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Jmapb]

On 5/9/2019 4:14 PM, Michael Reichert wrote


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.


This strikes me as a pretty bad idea. I map in NYC where we have lots,
lots, lots of nearly-square buildings with official footprints imported
from the city's open data initiative. When a mapper not familiar with
the history here gets a message from iD (which, to many mappers, is
indistinguishable from getting a message from OSM itself) encouraging
them to square a building, they'll do it because it seems like the right
thing to do. So the official, highly-accurate footprints are lost. And
adjacent buildings with shared nodes are also distorted.

If I were to communicate with this mapper and say "Hi, welcome, please
don't square the buildings" it will simply be confusing because the
official editor, hosted at https://www.openstreetmap.org, told them they
should.

JOSM's validator used to flag nearly-square buildings here, and it
caused thousands of unnecessary and inaccurate updates to building
footprints. And of course people doing these thought they were doing the
right thing -- if the validator says there's a problem, there's a
problem, right? Fixing it is helping the map!

I'd hate to see iD go down the same road. And I certainly don't want to
mass-tag all of NYC's imported buildings with nosquare=yes.

J


___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Simon Poole]

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
>  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


signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Nelson A. de Oliveira]

On Thu, May 9, 2019 at 6:18 PM Mikel Maron  wrote:
> 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.

Instead inventing a new tag, it could simply be solved by only warning
if the non-square building was modified or created in the current
session.
If this is the case (object modified/created), then simply offer an
option to make it square or to ignore the message. That simple.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

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

[Yves]

Not the first time tagging is bent to editor's will, but this one is gross.
Yves 

Le 9 mai 2019 22:14:31 GMT+02:00, Michael Reichert  a 
écrit :
>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

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

[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. 
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.
-Mikel
* Mikel Maron * +14152835207 @mikel s:mikelmaron 

On Thursday, May 9, 2019, 4:18:20 PM EDT, Michael Reichert 
 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

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

[Michael Reichert]

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)



signature.asc
Description: OpenPGP digital signature
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk