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
|

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

SimonPoole

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

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

Why we square buildings (WAS: iD invents nosquare=yes for buildings which should not be squared)

Michael Reichert-3
Hi,

Am 11/05/2019 um 21.09 schrieb 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 :-).
Are buildings with rectangular corners buildings mappers from developed
countries want to see on a map because they look more professional/tidy? ;-)

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 (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Why we square buildings (WAS: iD invents nosquare=yes for buildings which should not be squared)

john whelan-2
>Are buildings with rectangular corners buildings mappers from developed
countries want to see on a map because they look more professional/tidy? ;-)

I think the original problem was some buildings mapped in Nepal were of very poor quality and one way to pick them out quickly was to look for none squared buildings.

My personal view is if you square a building you are approximating and that is never good on the quality side.

Cheerio John

On Sat, May 11, 2019, 3:38 PM Michael Reichert, <[hidden email]> wrote:
Hi,

Am 11/05/2019 um 21.09 schrieb 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 :-).

Are buildings with rectangular corners buildings mappers from developed
countries want to see on a map because they look more professional/tidy? ;-)

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: Why we square buildings (WAS: iD invents nosquare=yes for buildings which should not be squared)

General Discussion mailing list
In reply to this post by Michael Reichert-3
Am 11/05/2019 um 21.09 schrieb 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 :-).

See some annoying deviations from the building footprints we would prefer to no observe on the map

High ratios of Unsquarred buildings is often an indication of imprecise mapping with often significative deviations from the outlines. But, yes this is more then worry about squarred buidlings. We should also worry about the general problem of deviations from the footprint.  Dark and unaligned Imagery, various images with different offsets and inexperience in correcting the offsets also contribute to bad mapping.

An angle deviation of 1-2 degree is surely acceptable. But analysis of mapping shows in some areas very high ratio of unsquarred buildings or irrregular Round buildings with important deviations. We see the same with Building Imports projects. We cannot apply a strict Yes or No rule like for Topology errors. But how much shoud we deviate ?  Geography or Pop Arts ?

Pierre


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

Downsides of storing QA data in OSM data, Way ids! | Re: iD invents nosquare=yes for buildings which should not be squared

ebel
In reply to this post by Yuri Astrakhan-2

There certainly is benefit to piggybacking QA data on the OSM databases,
but there are downsides. Moving a node will not change the way's version
id. This change can make the building square/notsqure/overlap/whatever.
The way needs to be rechecked by the QA tool. But it can't know know
that from the way version.

On 10.05.19 22:17, Yuri Astrakhan wrote:

> On Fri, May 10, 2019 at 3:39 PM Yves <[hidden email]
> <mailto:[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
>


_______________________________________________
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
In reply to this post by Michael Reichert-3
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
[hidden email]
https://lists.openstreetmap.org/listinfo/talk
12