[OSM-talk] weeklyOSM #459 2019-04-30-2019-05-06

2019-05-11 Thread weeklyteam
The weekly round-up of OSM news, issue # 459,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world: http://www.weeklyosm.eu/en/archives/12067/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
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

2019-05-11 Thread 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

2019-05-11 Thread 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


[OSM-talk] Why we square buildings (WAS: iD invents nosquare=yes for buildings which should not be squared)

2019-05-11 Thread Michael Reichert
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)



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


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

2019-05-11 Thread john whelan
>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, 
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
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk


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

2019-05-11 Thread Pierre Béland via talk
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
https://opendatalabrdc.github.io/Blog/img/JOSM-TM-4975-Ndorwa-County-Uganda.pnghttps://opendatalabrdc.github.io/Blog/img/Overpass-Kochi-India-Irregular-Forms-Validation.png
 
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
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk