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

Simon Poole simon at poole.ch
Sat May 11 19:09:50 UTC 2019

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


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
> <sfkeller at gmail.com> 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20190511/77916cf0/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20190511/77916cf0/attachment.sig>

More information about the talk mailing list