iD invents nosquare=yes for buildings which should not be squared

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

iD invents nosquare=yes for buildings which should not be squared

Michael Reichert-3
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Mikel Maron-3
> 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 <[hidden email]> 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.


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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Yves-2
In reply to this post by Michael Reichert-3
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 <[hidden email]> 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


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Nelson A. de Oliveira
In reply to this post by Mikel Maron-3
On Thu, May 9, 2019 at 6:18 PM Mikel Maron <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

SimonPoole
In reply to this post by Mikel Maron-3


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 [hidden email] 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.


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

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Jmapb
In reply to this post by Michael Reichert-3
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

john whelan-2
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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Michael Reichert-3
In reply to this post by Mikel Maron-3
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)


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Christoph Hormann-2
In reply to this post by SimonPoole
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Michael Reichert-3
In reply to this post by Jmapb
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)


_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Greg Troxel-2
In reply to this post by Michael Reichert-3
Michael Reichert <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

lsces
In reply to this post by Michael Reichert-3
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Florian Lohoff-2
In reply to this post by Jmapb
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                                                 [hidden email]
        UTF-8 Test: The 🐈 ran after a 🐁, but the 🐁 ran away

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Mikel Maron-3
In reply to this post by SimonPoole
> 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 <[hidden email]> 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 [hidden email] 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.


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

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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 <[hidden email]>:

>
> > 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 <[hidden email]> 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 <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk
>
> _______________________________________________
> talk mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk
>
> _______________________________________________
> talk mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk
> _______________________________________________
> talk mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

General Discussion mailing list
May 20 2019 at 14 h 02 min 51 s UTC−4, Stefan Keller <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Yves-2
In reply to this post by Stefan Keller
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>:
>
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk

_______________________________________________
talk mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Yuri Astrakhan-2
On Fri, May 10, 2019 at 3:39 PM Yves <[hidden email]> 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 NNNN is exempt from validation XXXX", 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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
Reply | Threaded
Open this post in threaded view
|

Re: iD invents nosquare=yes for buildings which should not be squared

Mateusz Konieczny-3
In reply to this post by Michael Reichert-3



9 May 2019, 22:14 by [hidden email]:
What do you think? Should the next version of iD be deployed on
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
12