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