subject:"\[Talk\-ca\] Building Import update"

I'm not hearing we have a clear consensus on modifying the shape of
buildings with scripts and the Q button.

My own personal view is it could introduce errors and unless it is very
obviously wrong when it should get picked up by the importing mapper it
should be left as is.

Cheerio John

On Sun, 3 Feb 2019 at 18:26, john whelan  wrote:

> I'm hearing we keep the single import project as such.
>
> I'm hearing that we should preprocess the data first splitting out
> outlines that meet Pierre's right angle checks.  This data can just be
> imported using the current processes.
>
> I'm hearing we should then run the correcting scripts and extract the
> corrected buildings.  This becomes the second stage.  This data should be
> imported separately to the first since it needs to be more closely
> inspected in case the script has caused some deformation.
>
> At the moment I'm not sure if the two scripts above exist.
>
> I'm hearing what is left becomes the third stage which needs to be sorted
> out manually before being made available for import.  Again I see this as a
> separate task since the outlines will have been modified from the original.
>
> Note to James is the above practical?  Do we have the resources to do it?
> Please do not do anything until we have an agreement to proceed.
>
> I'm hearing the existing imported building outlines will be subject to an
> overpass to pick out those building outlines that are not square.
>
> Then the "a miracle occurs" box on the project plan gets these into a JOSM
> todo list and mappers manually sort them out.  I'm not certain how this
> will happen.  I suspect if the overpass query is small enough and the
> buildings are loaded up from an off line source this might work.
>
> To come back to Toronto my feeling is this is best left to the local
> mappers in Toronto to decide how to proceed.  There is/was room for a local
> coordinator in the project plan.  Nate's expectations are different to mine
> and I think it makes sense for the local mappers to decide what they would
> like to do together with Nate and a Toronto mapper set themselves up to
> coordinate in Toronto.  The speed at which the buildings were added has
> been raised as a concern.  I'm unable to think of a way to address this
> other than a "please take it slowly" added to the instructions.
>
> Again this option is available to any other areas who would like to use
> this method.
>
> I feel for Quebec the best thing to do is hold back until we have an
> agreement for the rest of the country since there are Quebec mappers who
> are not following this thread on talk-ca and to be honest we do seem to be
> evolving on a hourly basis so waiting until the dust settles might well be
> sensible.
>
> Am I missing something apart from my sanity?
>
> Thanks John
>
> On Sun, 3 Feb 2019 at 17:07, Pierre Béland  wrote:
>
>> Je suggère oui, d'abord le script avec 2 fichiers d'output parce
>> qu'ensuite il sera beaucoup plus simple d'importer les données déja
>> corrigées. Sinon une variable pour distinguer les deux et risque de
>> l'importer dans OSM ? Et je pense à un autre aspect. Le script pourrait
>> s'assurer qu'il n'y a pas de superpositions entre bâtiments une fois les
>> données corrigées.
>>
>> L'importation des données orthogonales devrait être grandement facilitée.
>> Selon l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère
>> une fois les polygones qasi-orthogonaux corrigés. Pour ces données, il
>> s'agirait davantage de valider avec l'imagerie et de faire la conflation
>> avec les données existantes.
>>
>> Pour l'importation des données irrégulières, il faudrait oui valider /
>> corriger. A ne pas oublier que dans ce cas on retrouve des angles qui
>> s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement
>> facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la
>> touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un
>> angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le
>> greffon ToDo est très utilie pour réviser successivement des données et
>> s'assurer de toutes les réviser.
>>
>> A titre d'exemple, on peut décider d'orthogonaliser le bâtiment
>> ci-dessous avec beaucoup d'angles se rapprochant de 90 degrés mais avec une
>> variance plus grande que +-5 degrés. Pour détecter davantage de bâiments
>> quasi-orthogonaux, il serait possible de tenir compte de cette situation
>> uniquement pour angles à 90 avec critère tolérance +-10 degrés. Je vais
>> tester cette option et voir si cela permettrait de détecter un grand nombre
>> de cas.
>> angles entre 82.6 et 94.5 degrés
>>
>> {82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
>> https://www.openstreetmap.org/way/479048070
>>
>> Pierre
>>
>>
>> Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan <
>> jwhelan0...@gmail.com> a écrit :
>>
>>
>> I accept the nicest way is to check the data beforehand.

Re: [Talk-ca] Building Import update

2019-02-03 Thread OSM Volunteer stevea

I dislike sounding simply "like a cheerleader," here however, I am deeply 
encouraged by what I see as substantial progress.  This sort of discussion 
bodes very well for the future of the import.  Keep up the good work!

SteveA

On Feb 3, 2019, at 3:26 PM, john whelan  wrote:
> I'm hearing we keep the single import project as such.

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

I'm hearing we keep the single import project as such.

I'm hearing that we should preprocess the data first splitting out outlines
that meet Pierre's right angle checks.  This data can just be imported
using the current processes.

I'm hearing we should then run the correcting scripts and extract the
corrected buildings.  This becomes the second stage.  This data should be
imported separately to the first since it needs to be more closely
inspected in case the script has caused some deformation.

At the moment I'm not sure if the two scripts above exist.

I'm hearing what is left becomes the third stage which needs to be sorted
out manually before being made available for import.  Again I see this as a
separate task since the outlines will have been modified from the original.

Note to James is the above practical?  Do we have the resources to do it?
Please do not do anything until we have an agreement to proceed.

I'm hearing the existing imported building outlines will be subject to an
overpass to pick out those building outlines that are not square.

Then the "a miracle occurs" box on the project plan gets these into a JOSM
todo list and mappers manually sort them out.  I'm not certain how this
will happen.  I suspect if the overpass query is small enough and the
buildings are loaded up from an off line source this might work.

To come back to Toronto my feeling is this is best left to the local
mappers in Toronto to decide how to proceed.  There is/was room for a local
coordinator in the project plan.  Nate's expectations are different to mine
and I think it makes sense for the local mappers to decide what they would
like to do together with Nate and a Toronto mapper set themselves up to
coordinate in Toronto.  The speed at which the buildings were added has
been raised as a concern.  I'm unable to think of a way to address this
other than a "please take it slowly" added to the instructions.

Again this option is available to any other areas who would like to use
this method.

I feel for Quebec the best thing to do is hold back until we have an
agreement for the rest of the country since there are Quebec mappers who
are not following this thread on talk-ca and to be honest we do seem to be
evolving on a hourly basis so waiting until the dust settles might well be
sensible.

Am I missing something apart from my sanity?

Thanks John

On Sun, 3 Feb 2019 at 17:07, Pierre Béland  wrote:

> Je suggère oui, d'abord le script avec 2 fichiers d'output parce
> qu'ensuite il sera beaucoup plus simple d'importer les données déja
> corrigées. Sinon une variable pour distinguer les deux et risque de
> l'importer dans OSM ? Et je pense à un autre aspect. Le script pourrait
> s'assurer qu'il n'y a pas de superpositions entre bâtiments une fois les
> données corrigées.
>
> L'importation des données orthogonales devrait être grandement facilitée.
> Selon l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère
> une fois les polygones qasi-orthogonaux corrigés. Pour ces données, il
> s'agirait davantage de valider avec l'imagerie et de faire la conflation
> avec les données existantes.
>
> Pour l'importation des données irrégulières, il faudrait oui valider /
> corriger. A ne pas oublier que dans ce cas on retrouve des angles qui
> s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement
> facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la
> touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un
> angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le
> greffon ToDo est très utilie pour réviser successivement des données et
> s'assurer de toutes les réviser.
>
> A titre d'exemple, on peut décider d'orthogonaliser le bâtiment ci-dessous
> avec beaucoup d'angles se rapprochant de 90 degrés mais avec une variance
> plus grande que +-5 degrés. Pour détecter davantage de bâiments
> quasi-orthogonaux, il serait possible de tenir compte de cette situation
> uniquement pour angles à 90 avec critère tolérance +-10 degrés. Je vais
> tester cette option et voir si cela permettrait de détecter un grand nombre
> de cas.
> angles entre 82.6 et 94.5 degrés
>
> {82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
> https://www.openstreetmap.org/way/479048070
>
> Pierre
>
>
> Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> I accept the nicest way is to check the data beforehand.  Scripting it is
> fairly simple.  Are you suggesting a two stage process of take the data and
> run the script first then task manager the data to be imported to manually
> correct the data?  My eyesight isn't good enough to pick out none right
> angled corners so is there some way someone can come up with to feed them
> into a JOSM todo list?
>
> However we have a fairly large number of building outlines that have
> already been imported.  The issue here is different as

Re: [Talk-ca] Building Import update

Je suggère oui, d'abord le script avec 2 fichiers d'output parce qu'ensuite il 
sera beaucoup plus simple d'importer les données déja corrigées. Sinon une 
variable pour distinguer les deux et risque de l'importer dans OSM ? Et je 
pense à un autre aspect. Le script pourrait s'assurer qu'il n'y a pas de 
superpositions entre bâtiments une fois les données corrigées.

L'importation des données orthogonales devrait être grandement facilitée. Selon 
l'exemple d'Ottawa, quelque 75% des bâtiments répondent à ce critère une fois 
les polygones qasi-orthogonaux corrigés. Pour ces données, il s'agirait 
davantage de valider avec l'imagerie et de faire la conflation avec les données 
existantes. 

Pour l'importation des données irrégulières, il faudrait oui valider / 
corriger. A ne pas oublier que dans ce cas on retrouve des angles qui 
s'éloignent de plus de 5 degrés vs données orthogonal. C'est visuellement 
facile à repérer.  Souvent, il s'agirait simplement avec JOSM d'utiliser la 
touche «Q» pour orthogonaliser.  De nombreux appendices de batiments on un 
angle prononcé dans le fichier et cela peut etre redressé à 90 degrés. Le 
greffon ToDo est très utilie pour réviser successivement des données et 
s'assurer de toutes les réviser.

A titre d'exemple, on peut décider d'orthogonaliser le bâtiment ci-dessous avec 
beaucoup d'angles se rapprochant de 90 degrés mais avec une variance plus 
grande que +-5 degrés. Pour détecter davantage de bâiments quasi-orthogonaux, 
il serait possible de tenir compte de cette situation uniquement pour angles à 
90 avec critère tolérance +-10 degrés. Je vais tester cette option et voir si 
cela permettrait de détecter un grand nombre de cas.angles entre 82.6 et 94.5 
degrés
{82.6,85.7,87.4,90.3,96,94.5,85.5,84.8,91,90.8,89.3,89.8,90.4,91.1,91.1,93.6,87.1,82,87.3,84.7}
https://www.openstreetmap.org/way/479048070
Pierre 
 

Le dimanche 3 février 2019 15 h 45 min 33 s HNE, john whelan 
 a écrit :  
 
 I accept the nicest way is to check the data beforehand.  Scripting it is 
fairly simple.  Are you suggesting a two stage process of take the data and run 
the script first then task manager the data to be imported to manually correct 
the data?  My eyesight isn't good enough to pick out none right angled corners 
so is there some way someone can come up with to feed them into a JOSM todo 
list?

However we have a fairly large number of building outlines that have already 
been imported.  The issue here is different as extra tags have been added.  Can 
the questionable ones be identified in such a way that a JOSM todo list can be 
used to correct them rather than throw out all the work that has been done 
adding tags?
I think you are assuming a more top down management arrangement than exists 
with volunteer Canadian mappers.

Thanks John
  


  

  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

I accept the nicest way is to check the data beforehand.  Scripting it is
fairly simple.  Are you suggesting a two stage process of take the data and
run the script first then task manager the data to be imported to manually
correct the data?  My eyesight isn't good enough to pick out none right
angled corners so is there some way someone can come up with to feed them
into a JOSM todo list?

However we have a fairly large number of building outlines that have
already been imported.  The issue here is different as extra tags have been
added.  Can the questionable ones be identified in such a way that a JOSM
todo list can be used to correct them rather than throw out all the work
that has been done adding tags?

I think you are assuming a more top down management arrangement than exists
with volunteer Canadian mappers.

Thanks John

On Sun, 3 Feb 2019 at 15:33, Pierre Béland  wrote:

> John
>
> Oui, je suggère  à ceux qui préparent un plan d'importation, de modifier
> la donnée avant l'importation. Des critères comme ceux que j'ai présenté
> pourraient être utilisés dans un script pour simplifier les polygones qui
> sont quasi orthogonaux.
>
> Pour simplifier la procédue d'import, deux fichiers distincts pourraient
> être produits :
>
> 1. Formes géométriques quasi-orthogonales corrigées - import plus rapide -
> mais a voir si problèmes lorsque des bâtiments voisins partagent des nodes.
>
> 2. Formes géométriques irrégulières - Import avec révision / correction
> plus serrée.
>
> Il reste à ceux qui mènent le projet de faire ces développements
> logiciels. Et pourquoi pas, de proposer des outils que les communautés
> locales pourront ensuite utiliser. Par contre éviter qu'un petit groupe
> importe rapidement les données et ignore le rôle des communautés locales.
>
> Et l'argument, si tu t'opposes, tu est responsable pour ta communauté,
> nous ont fait le reste du pays, à mon avis cela ne tient pas la route.
>
> Pierre
>
>
> Le dimanche 3 février 2019 14 h 57 min 45 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> So you're proposing that a script is run to correct minor deviations in
> the remaining data which sounds a reasonable approach to me and would
> improve data quality.
>
> So run the data through the script.  Then import and run overpass to pick
> out those that need manual adjustment?
>
> If we do this though then I think we need to stay with the single import
> plan rather than have individual import plans popping up that didn't use
> the scripts.
>
> I have no control over the number of mappers importing or the rate at
> which they import and I'm not sure how you would mange this other than
> having a person identified in the wiki as leading a particular area and
> there is provision or rather was I'm not sure what the latest version says.
>
> Even with smaller import plans there would be nothing to stop one mapper
> bringing in building outlines very quickly.
>
> Cheerio John
>
>
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

John
Oui, je suggère  à ceux qui préparent un plan d'importation, de modifier la 
donnée avant l'importation. Des critères comme ceux que j'ai présenté 
pourraient être utilisés dans un script pour simplifier les polygones qui sont 
quasi orthogonaux. 

Pour simplifier la procédue d'import, deux fichiers distincts pourraient être 
produits :
1. Formes géométriques quasi-orthogonales corrigées - import plus rapide - mais 
a voir si problèmes lorsque des bâtiments voisins partagent des nodes.
2. Formes géométriques irrégulières - Import avec révision / correction plus 
serrée. 

Il reste à ceux qui mènent le projet de faire ces développements logiciels. Et 
pourquoi pas, de proposer des outils que les communautés locales pourront 
ensuite utiliser. Par contre éviter qu'un petit groupe importe rapidement les 
données et ignore le rôle des communautés locales. 

Et l'argument, si tu t'opposes, tu est responsable pour ta communauté, nous ont 
fait le reste du pays, à mon avis cela ne tient pas la route.
 
Pierre 
 

Le dimanche 3 février 2019 14 h 57 min 45 s HNE, john whelan 
 a écrit :  
 
 So you're proposing that a script is run to correct minor deviations in the 
remaining data which sounds a reasonable approach to me and would improve data 
quality.
So run the data through the script.  Then import and run overpass to pick out 
those that need manual adjustment?
If we do this though then I think we need to stay with the single import plan 
rather than have individual import plans popping up that didn't use the scripts.
I have no control over the number of mappers importing or the rate at which 
they import and I'm not sure how you would mange this other than having a 
person identified in the wiki as leading a particular area and there is 
provision or rather was I'm not sure what the latest version says.
Even with smaller import plans there would be nothing to stop one mapper 
bringing in building outlines very quickly.
Cheerio John


 


  
  
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

So you're proposing that a script is run to correct minor deviations in the
remaining data which sounds a reasonable approach to me and would improve
data quality.

So run the data through the script.  Then import and run overpass to pick
out those that need manual adjustment?

If we do this though then I think we need to stay with the single import
plan rather than have individual import plans popping up that didn't use
the scripts.

I have no control over the number of mappers importing or the rate at which
they import and I'm not sure how you would mange this other than having a
person identified in the wiki as leading a particular area and there is
provision or rather was I'm not sure what the latest version says.

Even with smaller import plans there would be nothing to stop one mapper
bringing in building outlines very quickly.

Cheerio John

On Sun, 3 Feb 2019 at 14:09, Pierre Béland  wrote:

> Le «acid test» de John, avec une architecture aussi irrégulière, a abimé
> les «Bay Windows» et l'eau fuit de partout tout comme son analyse basée sur
> Orléans à l'extérieur de la zone étudiée ! Une analyse plus approfondie de
> la zone du centre-ville nous montre qu'il y a peu de telles architectures.
> Cette réponse ne tient pas la route et n'explique pas le ratio élevé de
> polygones avec formes irrégulières dans la base OSM.
>
> Le feedback de Nate pour Toronto montre qu'il a a beaucoup de données à
> corriger pour orthognaliser. voir
> https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009080.html
>
> Ce que je comprends bien aux réactions de John depuis le début, c'est
> laissons les données telles qu'elles.  Plusieurs évitent de se pronconcer.
> Cela ne me convainct pas de l'urgence pour un petit groupe de se hâter à
> importer les données sans tenir compte de problèmes de qualité importants.
>
> J'ai révisé mon script qualité pour cerner davantage les formes
> régulières. Il tenait compte jusqu'ici des angles à 90 degrés et des autres
> formes régulières (hexagones, octogones, etc). Je l'ai révisé au cours des
> derniers jours acceptant une tolérance jusqu'à 5 degrés. Les angles à 45
> degrés  (ie. 45, 135, 225, 315) sont maintenant pris en compte.
>
> Ces modifications ont eu peu d'impact sur le nombre de bâtiments
> identifiés avec formes irrégulières. Cela confirme qu'il a a des polygones
> avec formes qui s'éloignent sensiblement de formes régulières.
>
> Avec une tolérance de 3 à 5 degrés, on constate que 17% des bâtiments
> peuvent être orthogonalisés automatiquement à l’aide de scripts. Ou encore
> il serait possible de réviser tous les bâtiments avec tolérance de 1 à 5
> degrés (ceux à moins de 1 degrés resteraient tels quels. Malgré tout, Il
> reste toujours 25% des bâtiments qui doivent être analysés manuellement et
> voir si des corrections sont nécessaires.
>
>
> Pierre
>
>
> Le jeudi 31 janvier 2019 20 h 48 min 03 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> I can't think of a way to pull in all the suspect buildings but if you
> have a look here:
>
>
> https://www.openstreetmap.org/search?query=k4a%201m7%20canada#map=19/45.47095/-75.48696
>
> 556, 558, 560 are all examples that I think would fail your test.  However
> they are the shape of the buildings.
>
> As far as I am aware we haven't had any outraged users complaining about
> the building shapes in Ottawa and that I think is the acid test.  The
> Ottawa building import has been useful certainly in gaining new mappers and
> adding tags to the outlines.
>
> Your test originally was to pick out very badly mapped buildings that had
> been done in iD and I would agree with you that some were very bad.
> Sometimes 3 or 4 times the size of the building and some very odd shapes
> indeed.  From memory most were done on HOT tasks with the iD editor.
>
> These I think we should definitely aim to avoid but where the
> representation of the building is reasonably accurate then I think they are
> acceptable.  We are using reasonably experienced mappers who would balk at
> importing some of the stuff we saw in Nepal etc and rightly so.  They'd
> almost certainly be very vocal about the quality of the data.
>
> There is a case to be made that most residential buildings would be
> acceptable if they were mapped with the JOSM buildings_tool plugin and all
> the small blobs take up database size.  There is also a case that you get a
> better sense of the building with the small blobs, bay windows etc.  I
> don't have strong feelings either way but I strongly suspect there are
> examples of both already in OSM in Canada.
>
> I note that both Google and Bing have most buildings these days and it has
> almost become a map user expectation.  Certainly there are apps that guide
> blind people that use the building outlines in OSM.  There is a case that
> says to keep up with the competitors we really ought to have buildings.
>
> I think someone else has commented that parts of the Microsoft building
> outline from scanned

Re: [Talk-ca] Building Import update

The Ottawa building outline import was done by the local Ottawa mappers to
a standard they were happy with.

Cheerio John

On Sun, 3 Feb 2019 at 14:42, Pierre Béland  wrote:

> De tes exemples sortis du chapeau ne font pas avancer la discussion.
>
> J'attends la démonstration de John que les données d'import pour Ottawa
> représentent bien le contour des bâtiments et sont des données de qualité.
>
> Pierre
>
>
> Le dimanche 3 février 2019 12 h 07 min 55 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> From OSMweekly 445 and I'm not sure if it is relevant or not.
>
> Cheerio John
>
> Imports
>
>- Frederik Ramm suggested
>
> 
>reverting a four-year-old building import in Ulster County, New York State,
>because only simple squares had been imported instead of the correct
>building outlines. Two years ago the import was featured
>
> 
>by *Worst of OSM*.
>
>
> On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:
>
> If they weren't hand traced, how were they made? I don't believe I've
> actually seen any documentation on this. Do we know how these buildings
> footprints were made? Just because we didn't trace them from imagery
> ourselves doesn't mean someone working for a city GIS department didn't do
> exactly the same thing some time ago.
>
> We're concerned with squaring because buildings generally have right
> angles. If the data don't have right angles too, then like you said it
> likely indicates poor quality data.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 2/2/19 10:48 AM, Danny McDonald wrote:
>
> On squaring buildings, no one has yet been explained why buildings should
> be square.  My understanding is that non-square buildings are a warning
> sign for mapathons with hand-traced buildings - the lack of squaring is
> often noticeable for hand-traced buildings, and indicative of generally
> poor building footprints. That doesn't apply here, since the buildings
> involved are not hand-traced (at least in Toronto).  In fact, the imported
> footprints are generally extremely accurate, much better than would (or
> could) be done by hand.
>
> It seems like the automated verification tool (of checking whether
> buildings are square or not) is being misapplied in this case.
>
> DannyMcD
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-02-03 Thread OSM Volunteer stevea

Pierre writes that he is "waiting for John's demonstration that the import data 
for Ottawa represents the outline of the buildings and is quality data."

In reality, anybody (not necessarily John) can offer this sort of 
characterization.

En réalité, n'importe qui (pas nécessairement John) peut offrir ce type de 
caractérisation.

SteveA

On Feb 3, 2019, at 11:42 AM, Pierre Béland via Talk-ca 
 wrote:
> De tes exemples sortis du chapeau ne font pas avancer la discussion. 
> 
> J'attends la démonstration de John que les données d'import pour Ottawa 
> représentent bien le contour des bâtiments et sont des données de qualité.
>  
> Pierre 


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

De tes exemples sortis du chapeau ne font pas avancer la discussion. 

J'attends la démonstration de John que les données d'import pour Ottawa 
représentent bien le contour des bâtiments et sont des données de qualité.
 
Pierre 
 

Le dimanche 3 février 2019 12 h 07 min 55 s HNE, john whelan 
 a écrit :  
 
 From OSMweekly 445 and I'm not sure if it is relevant or not.
Cheerio John


Imports
   
   - Frederik Ramm suggested reverting a four-year-old building import in 
Ulster County, New York State, because only simple squares had been imported 
instead of the correct building outlines. Two years ago the import was featured 
by Worst of OSM.

On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:

  
If they weren't hand traced, how were they made? I don't believe I've actually 
seen any documentation on this. Do we know how these buildings footprints were 
made? Just because we didn't trace them from imagery ourselves doesn't mean 
someone working for a city GIS department didn't do exactly the same thing some 
time ago. 
 
 
We're concerned with squaring because buildings generally have right angles. If 
the data don't have right angles too, then like you said it likely indicates 
poor quality data. 
 
 
Best,
 
 Nate Wessel
 Jack of all trades, Master of Geography, PhD candidate in Urban Planning
 NateWessel.com 
 
  On 2/2/19 10:48 AM, Danny McDonald wrote:
  
 On squaring buildings, no one has yet been explained why buildings should be 
square.  My understanding is that non-square buildings are a warning sign for 
mapathons with hand-traced buildings - the lack of squaring is often noticeable 
for hand-traced buildings, and indicative of generally poor building 
footprints. That doesn't apply here, since the buildings involved are not 
hand-traced (at least in Toronto).  In fact, the imported footprints are 
generally extremely accurate, much better than would (or could) be done by 
hand. 
  It seems like the automated verification tool (of checking whether buildings 
are square or not) is being misapplied in this case. 
  DannyMcD  
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
 
 ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

 Le «acid test» de John, avec une architecture aussi irrégulière, a abimé les 
«Bay Windows» et l'eau fuit de partout tout comme son analyse basée sur Orléans 
à l'extérieur de la zone étudiée ! Une analyse plus approfondie de la zone du 
centre-ville nous montre qu'il y a peu de telles architectures. Cette réponse 
ne tient pas la route et n'explique pas le ratio élevé de polygones avec formes 
irrégulières dans la base OSM.

Le feedback de Nate pour Toronto montre qu'il a a beaucoup de données à 
corriger pour orthognaliser. voir 
https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009080.html

Ce que je comprends bien aux réactions de John depuis le début, c'est laissons 
les données telles qu'elles.  Plusieurs évitent de se pronconcer. Cela ne me 
convainct pas de l'urgence pour un petit groupe de se hâter à importer les 
données sans tenir compte de problèmes de qualité importants.

J'ai révisé mon script qualité pour cerner davantage les formes régulières. Il 
tenait compte jusqu'ici des angles à 90 degrés et des autres formes régulières 
(hexagones, octogones, etc). Je l'ai révisé au cours des derniers jours 
acceptant une tolérance jusqu'à 5 degrés. Les angles à 45 degrés  (ie. 45, 135, 
225, 315) sont maintenant pris en compte. 

Ces modifications ont eu peu d'impact sur le nombre de bâtiments identifiés 
avec formes irrégulières. Cela confirme qu'il a a des polygones avec formes qui 
s'éloignent sensiblement de formes régulières.

Avec une tolérance de 3 à 5 degrés, on constate que 17% des bâtiments peuvent 
être orthogonalisés automatiquement à l’aide de scripts. Ou encore il serait 
possible de réviser tous les bâtiments avec tolérance de 1 à 5 degrés (ceux à 
moins de 1 degrés resteraient tels quels. Malgré tout, Il reste toujours 25% 
des bâtiments qui doivent être analysés manuellement et voir si des corrections 
sont nécessaires.

 Pierre 
 

Le jeudi 31 janvier 2019 20 h 48 min 03 s HNE, john whelan 
 a écrit :  
 
 I can't think of a way to pull in all the suspect buildings but if you have a 
look here:
https://www.openstreetmap.org/search?query=k4a%201m7%20canada#map=19/45.47095/-75.48696

556, 558, 560 are all examples that I think would fail your test.  However they 
are the shape of the buildings.
As far as I am aware we haven't had any outraged users complaining about the 
building shapes in Ottawa and that I think is the acid test.  The Ottawa 
building import has been useful certainly in gaining new mappers and adding 
tags to the outlines.
Your test originally was to pick out very badly mapped buildings that had been 
done in iD and I would agree with you that some were very bad.  Sometimes 3 or 
4 times the size of the building and some very odd shapes indeed.  From memory 
most were done on HOT tasks with the iD editor.
These I think we should definitely aim to avoid but where the representation of 
the building is reasonably accurate then I think they are acceptable.  We are 
using reasonably experienced mappers who would balk at importing some of the 
stuff we saw in Nepal etc and rightly so.  They'd almost certainly be very 
vocal about the quality of the data.
There is a case to be made that most residential buildings would be acceptable 
if they were mapped with the JOSM buildings_tool plugin and all the small blobs 
take up database size.  There is also a case that you get a better sense of the 
building with the small blobs, bay windows etc.  I don't have strong feelings 
either way but I strongly suspect there are examples of both already in OSM in 
Canada.
I note that both Google and Bing have most buildings these days and it has 
almost become a map user expectation.  Certainly there are apps that guide 
blind people that use the building outlines in OSM.  There is a case that says 
to keep up with the competitors we really ought to have buildings.
I think someone else has commented that parts of the Microsoft building outline 
from scanned images in the US is problematic.
So given the results in Ottawa are comparable to Ontario and in my opinion 
Ottawa is acceptable then I think the rest is also acceptable.  Certainly 
Kingston where not all building angles were right angles weren't noticeable to 
me by eye or perhaps my eyesight is just getting worse with age.
Cheerio John


On Thu, 31 Jan 2019 at 19:51, Pierre Béland  wrote:

Salut John,
Voici les résultats d'analyse de géométrie des bâtiments pour Ottawa 
centre-ville.bbox : 45.4224,-75.6994,45.4568,-75.6122
-  20,372 Bâtiments
-      173 Bâtiments avec superposition  (0.1%)
-   11,534 Bâtiments avec formes irrégulières  (56.6%)

Nous avons donc un résultat semblable aux imports en Ontario que j'ai analysé 
il y quelques jours. A mon avis, en haut de 5%, il faut regarder de plus près 
et expliquer pourquoi autant de formes irrégulières.

J'ai créé des Requêtes overpass pour extraire les bâtiments identifiés dans 
l'analyse. Télécharger les requêtes à partir des fichiers ci-joints. 

Pierre 
 

173

Re: [Talk-ca] Building Import update

>From OSMweekly 445 and I'm not sure if it is relevant or not.

Cheerio John

Imports

   - Frederik Ramm suggested
   
   reverting a four-year-old building import in Ulster County, New York State,
   because only simple squares had been imported instead of the correct
   building outlines. Two years ago the import was featured
   

   by *Worst of OSM*.


On Sat, 2 Feb 2019 at 10:57, Nate Wessel  wrote:

> If they weren't hand traced, how were they made? I don't believe I've
> actually seen any documentation on this. Do we know how these buildings
> footprints were made? Just because we didn't trace them from imagery
> ourselves doesn't mean someone working for a city GIS department didn't do
> exactly the same thing some time ago.
>
> We're concerned with squaring because buildings generally have right
> angles. If the data don't have right angles too, then like you said it
> likely indicates poor quality data.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 2/2/19 10:48 AM, Danny McDonald wrote:
>
> On squaring buildings, no one has yet been explained why buildings should
> be square.  My understanding is that non-square buildings are a warning
> sign for mapathons with hand-traced buildings - the lack of squaring is
> often noticeable for hand-traced buildings, and indicative of generally
> poor building footprints. That doesn't apply here, since the buildings
> involved are not hand-traced (at least in Toronto).  In fact, the imported
> footprints are generally extremely accurate, much better than would (or
> could) be done by hand.
>
> It seems like the automated verification tool (of checking whether
> buildings are square or not) is being misapplied in this case.
>
> DannyMcD
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-02-02 Thread Nate Wessel

If they weren't hand traced, how were they made? I don't believe I've 
actually seen any documentation on this. Do we know how these buildings 
footprints were made? Just because we didn't trace them from imagery 
ourselves doesn't mean someone working for a city GIS department didn't 
do exactly the same thing some time ago.


We're concerned with squaring because buildings generally have right 
angles. If the data don't have right angles too, then like you said it 
likely indicates poor quality data.


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 2/2/19 10:48 AM, Danny McDonald wrote:
On squaring buildings, no one has yet been explained why buildings 
should be square.  My understanding is that non-square buildings are a 
warning sign for mapathons with hand-traced buildings - the lack of 
squaring is often noticeable for hand-traced buildings, and indicative 
of generally poor building footprints. That doesn't apply here, since 
the buildings involved are not hand-traced (at least in Toronto). In 
fact, the imported footprints are generally extremely accurate, much 
better than would (or could) be done by hand.


It seems like the automated verification tool (of checking whether 
buildings are square or not) is being misapplied in this case.


DannyMcD

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-02-02 Thread Danny McDonald

On squaring buildings, no one has yet been explained why buildings should
be square.  My understanding is that non-square buildings are a warning
sign for mapathons with hand-traced buildings - the lack of squaring is
often noticeable for hand-traced buildings, and indicative of generally
poor building footprints. That doesn't apply here, since the buildings
involved are not hand-traced (at least in Toronto).  In fact, the imported
footprints are generally extremely accurate, much better than would (or
could) be done by hand.

It seems like the automated verification tool (of checking whether
buildings are square or not) is being misapplied in this case.

DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-02-01 Thread OSM Volunteer stevea

On Feb 1, 2019, at 1:13 PM, john whelan  wrote:
> So how would you tackle it?
> 
> Adding buildings with JOSM and the buildings_tool is possible, I think Julia 
> tried to whip up some interest with the 2020 project.  Unfortunately 
> mapathons using iD and new mappers for some reason don't work too well for 
> buildings. They do work fine for adding tags though.
> 
> I seem to recall March 2nd is some sort of student GIS day and we can expect 
> something to happen in GEO/GIS week whenever it is.  I'd prefer adding tags 
> to existing outlines rather than having to clean up buildings added with iD.

Adding tags to buildings by students at a "student GIS day" (whether with iD or 
not) is "one thing," and honestly shouldn't even be in this same thread 
("Building Import update." ) Conflating the two is either mistaken, 
disingenuous or both.

> If we go back in time to the Ottawa import and the licensing issues I seem to 
> recall a Toronto mapper submitting the Toronto Open Data License to the legal 
> working group which implies at least one Toronto OSM mapper was after the 
> Toronto Open Data.

While it can be valuable to "look in the rear view mirror" (to learn from past 
mistakes), I fail to see how this comment matters.  Doing my best to stay on 
point, my educated guess is there are MANY users who want to see "the five 
provincial building datasets" (what we TRULY attempt to discuss here) enter 
OSM.  However, there appear to be questions about the data quality, with some 
saying "skilled editors are able to do a decent job with these data, but not 
without substantial post-data publication (now) improvements before the data 
are uploaded."  (This would be downloading a "square" on the Task Manager and 
rather heavily improving the data, building by building.  Yaro and Danny, 
please chime in and agree or disagree.  Should that be true, only 
intermediate-to-advanced — i.e. rather skilled OSM editors with practice and 
experience should "do" the importation of these data).  Others say "these data 
need wholesale algorithmic changes before they are good enough to be uploaded." 
 (As I've said, maybe "squaring" or "simplification," yet I and this mail-list 
still do not know exactly where consensus lies there).  There are likely other 
opinions along and even outside of that spectrum, I simply do not know that.  
But GETTING to know the answers to those questions really must be "next."  We 
appear to be hashing that out here and now.  Much else (all else?) is, largely 
speaking, noise, distraction and what Nate said, "red herring."

> My feeling at the moment is there is a suggestion that "cleaning" the data up 
> then some sort of team approach in a particular area would be acceptable but 
> how you put it together I'm not sure.

No, you do not appear to be sure, John.  Yet, somehow, Canada will get there.  
Either in talk-ca, the Import wiki, the wiki's Discussion tab ("Talk page") the 
consensus of what to do with the data will EVENTUALLY emerge (fix 'em, scrap 
'em, leave 'em alone and import 'em with great care...), then they will 
(slowly, there are a LOT!) begin to be imported into OSM.  Or not.

It is a maxim of good project management which is often unstated, yet now is 
the time to say it:  "Lead, follow or get out of the way."

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-02-01 Thread john whelan

So how would you tackle it?

Adding buildings with JOSM and the buildings_tool is possible, I think
Julia tried to whip up some interest with the 2020 project.  Unfortunately
mapathons using iD and new mappers for some reason don't work too well for
buildings. They do work fine for adding tags though.

I seem to recall March 2nd is some sort of student GIS day and we can
expect something to happen in GEO/GIS week whenever it is.  I'd prefer
adding tags to existing outlines rather than having to clean up buildings
added with iD.

If we go back in time to the Ottawa import and the licensing issues I seem
to recall a Toronto mapper submitting the Toronto Open Data License to the
legal working group which implies at least one Toronto OSM mapper was after
the Toronto Open Data.

My feeling at the moment is there is a suggestion that "cleaning" the data
up then some sort of team approach in a particular area would be acceptable
but how you put it together I'm not sure.

Suggestions please

Thanks

Cheerio John

On Fri, 1 Feb 2019 at 15:52, Begin Daniel  wrote:

> +1
>
>
>
> *From:* Nate Wessel [mailto:bike...@gmail.com]
> *Sent:* Friday, February 01, 2019 08:54
> *To:* talk-ca@openstreetmap.org
> *Subject:* Re: [Talk-ca] Building Import update
>
>
>
> John,
>
> IMO, this is a red herring and I think you must recognize that to at least
> some degree. Just like no one suggested we do 3700 import plans, no on has
> suggested that we not add buildings to OSM. The question is how, and if
> that "how" in part is an import, then what data, at what speed, by who, etc?
>
> We're not debating between "import" and "nothing" here. There were tens of
> thousands of carefully hand-mapped buildings in Toronto before you and a
> couple others rode in and quietly changed everything in the course of a
> week.
>
> I'd like to point out to you the interesting case of Kenton County
> Kentucky:
> https://www.openstreetmap.org/relation/361564
>
> Go ahead and zoom in and take a good look at that data. Poke around the
> rest of Northern Kentucky too while you're at it. Notice how good not only
> the building data is, but landuses, named places, etc. The only substantial
> import this area has ever seen is the TIGER road import of about a decade
> ago. By the time we started our Hamilton County building import (just north
> of the river), there were more than 150,000 buildings added by hand in the
> region already.
>
> I'm not saying this is the way Toronto/Canada needs to develop, but don't
> imply that it's impossible - it isn't.
>
> Cheers,
>
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com <http://natewessel.com>
>
> On 2/1/19 7:35 AM, john whelan wrote:
>
>
> https://www.openstreetmap.org/search?query=arthur%20mark%20drive%20port%20hope%20ontario#map=17/43.96262/-78.27069
>
>
>
> https://www.google.ca/maps/@43.9631101,-78.2732195,17.25z
>
>
>
> https://www.bing.com/maps?FORM=Z9LH3
>
>
>
> Port Hope Ontario is relatively obscure yet both Bing and google have
> buildings and neither company would spend the money dropping them in unless
> they saw a demand.
>
>
>
> A small sample but I'm sure that others are quite capable of looking
> locally for themselves.
>
>
>
>
>
> I'm a shades of grey person so to me there is no absolute need to have
> buildings in OpenStreetMap and I think different end users have different
> expectations.  I seem to recall osmand has a street only map which takes up
> less room on the device.  It's perfectly adequate for some users.
>
>
>
> I can make a case for both having them and not having any.  On the not
> having any way up there would be the buildings added by inexperienced
> mappers using iD often in HOT projects.  There are duplicates, strange
> shapes that bare no relation to any imagery, and city blocks marked as a
> single building.  On the having them side would be where can I get a coffee
> and wifi?
>
>
>
> There are many users of the map who would like to see buildings or more
> importantly have building information available in an electronic form.
>
>
>
> For Ottawa I think I can safely say the local mappers are happy with the
> imported buildings.  In OpenStreetMap there will always be a range of
> points of view.
>
>
>
> As you say it is for the local mappers to decide what they would like to
> do.  In this case is it difficult to define the local mappers.
>
>
>
> Cheerio John
>
>
>
>
>
>
>
>
>
> ___
>
> Talk-ca mailing list
>
> Talk-ca@openstreetmap.org
>
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-02-01 Thread Begin Daniel

+1

From: Nate Wessel [mailto:bike...@gmail.com]
Sent: Friday, February 01, 2019 08:54
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import update

John,

IMO, this is a red herring and I think you must recognize that to at least some 
degree. Just like no one suggested we do 3700 import plans, no on has suggested 
that we not add buildings to OSM. The question is how, and if that "how" in 
part is an import, then what data, at what speed, by who, etc?

We're not debating between "import" and "nothing" here. There were tens of 
thousands of carefully hand-mapped buildings in Toronto before you and a couple 
others rode in and quietly changed everything in the course of a week.

I'd like to point out to you the interesting case of Kenton County Kentucky:
https://www.openstreetmap.org/relation/361564

Go ahead and zoom in and take a good look at that data. Poke around the rest of 
Northern Kentucky too while you're at it. Notice how good not only the building 
data is, but landuses, named places, etc. The only substantial import this area 
has ever seen is the TIGER road import of about a decade ago. By the time we 
started our Hamilton County building import (just north of the river), there 
were more than 150,000 buildings added by hand in the region already.

I'm not saying this is the way Toronto/Canada needs to develop, but don't imply 
that it's impossible - it isn't.

Cheers,
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com<http://natewessel.com>
On 2/1/19 7:35 AM, john whelan wrote:
https://www.openstreetmap.org/search?query=arthur%20mark%20drive%20port%20hope%20ontario#map=17/43.96262/-78.27069

https://www.google.ca/maps/@43.9631101,-78.2732195,17.25z

https://www.bing.com/maps?FORM=Z9LH3

Port Hope Ontario is relatively obscure yet both Bing and google have buildings 
and neither company would spend the money dropping them in unless they saw a 
demand.

A small sample but I'm sure that others are quite capable of looking locally 
for themselves.

I'm a shades of grey person so to me there is no absolute need to have 
buildings in OpenStreetMap and I think different end users have different 
expectations.  I seem to recall osmand has a street only map which takes up 
less room on the device.  It's perfectly adequate for some users.

I can make a case for both having them and not having any.  On the not having 
any way up there would be the buildings added by inexperienced mappers using iD 
often in HOT projects.  There are duplicates, strange shapes that bare no 
relation to any imagery, and city blocks marked as a single building.  On the 
having them side would be where can I get a coffee and wifi?

There are many users of the map who would like to see buildings or more 
importantly have building information available in an electronic form.

For Ottawa I think I can safely say the local mappers are happy with the 
imported buildings.  In OpenStreetMap there will always be a range of points of 
view.

As you say it is for the local mappers to decide what they would like to do.  
In this case is it difficult to define the local mappers.

Cheerio John

___

Talk-ca mailing list

Talk-ca@openstreetmap.org<mailto:Talk-ca@openstreetmap.org>

https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-02-01 Thread Nate Wessel


John,

IMO, this is a red herring and I think you must recognize that to at 
least some degree. Just like no one suggested we do 3700 import plans, 
no on has suggested that we not add buildings to OSM. The question is 
how, and if that "how" in part is an import, then what data, at what 
speed, by who, etc?


We're not debating between "import" and "nothing" here. There were tens 
of thousands of carefully hand-mapped buildings in Toronto before you 
and a couple others rode in and quietly changed everything in the course 
of a week.


I'd like to point out to you the interesting case of Kenton County Kentucky:
https://www.openstreetmap.org/relation/361564

Go ahead and zoom in and take a good look at that data. Poke around the 
rest of Northern Kentucky too while you're at it. Notice how good not 
only the building data is, but landuses, named places, etc. The only 
substantial import this area has ever seen is the TIGER road import of 
about a decade ago. By the time we started our Hamilton County building 
import (just north of the river), there were more than 150,000 buildings 
added by hand in the region already.


I'm not saying this is the way Toronto/Canada needs to develop, but 
don't imply that it's impossible - it isn't.


Cheers,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 2/1/19 7:35 AM, john whelan wrote:

https://www.openstreetmap.org/search?query=arthur%20mark%20drive%20port%20hope%20ontario#map=17/43.96262/-78.27069

https://www.google.ca/maps/@43.9631101,-78.2732195,17.25z

https://www.bing.com/maps?FORM=Z9LH3

Port Hope Ontario is relatively obscure yet both Bing and google have 
buildings and neither company would spend the money dropping them in 
unless they saw a demand.


A small sample but I'm sure that others are quite capable of looking 
locally for themselves.



I'm a shades of grey person so to me there is no absolute need to have 
buildings in OpenStreetMap and I think different end users have 
different expectations.  I seem to recall osmand has a street only map 
which takes up less room on the device.  It's perfectly adequate for 
some users.


I can make a case for both having them and not having any.  On the not 
having any way up there would be the buildings added by inexperienced 
mappers using iD often in HOT projects.  There are duplicates, strange 
shapes that bare no relation to any imagery, and city blocks marked as 
a single building.  On the having them side would be where can I get a 
coffee and wifi?


There are many users of the map who would like to see buildings or 
more importantly have building information available in an electronic 
form.


For Ottawa I think I can safely say the local mappers are happy with 
the imported buildings.  In OpenStreetMap there will always be a range 
of points of view.


As you say it is for the local mappers to decide what they would like 
to do.  In this case is it difficult to define the local mappers.


Cheerio John




___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-02-01 Thread john whelan

https://www.openstreetmap.org/search?query=arthur%20mark%20drive%20port%20hope%20ontario#map=17/43.96262/-78.27069

https://www.google.ca/maps/@43.9631101,-78.2732195,17.25z

https://www.bing.com/maps?FORM=Z9LH3

Port Hope Ontario is relatively obscure yet both Bing and google have
buildings and neither company would spend the money dropping them in unless
they saw a demand.

A small sample but I'm sure that others are quite capable of looking
locally for themselves.

I'm a shades of grey person so to me there is no absolute need to have
buildings in OpenStreetMap and I think different end users have different
expectations. I seem to recall osmand has a street only map which takes up
less room on the device. It's perfectly adequate for some users.

I can make a case for both having them and not having any. On the not
having any way up there would be the buildings added by inexperienced
mappers using iD often in HOT projects. There are duplicates, strange
shapes that bare no relation to any imagery, and city blocks marked as a
single building. On the having them side would be where can I get a coffee
and wifi?

There are many users of the map who would like to see buildings or more
importantly have building information available in an electronic form.

For Ottawa I think I can safely say the local mappers are happy with the
imported buildings. In OpenStreetMap there will always be a range of
points of view.

As you say it is for the local mappers to decide what they would like to
do. In this case is it difficult to define the local mappers.

Cheerio John
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-01-31 Thread OSM Volunteer stevea

On Jan 31, 2019, at 5:47 PM, john whelan  wrote:
> 
> I note that both Google and Bing have most buildings these days

That's a strong assertion, any cite you might make?  Or are you simply 
guessing?  Also, so what?  And, "most?"

> and it has almost become a map user expectation.

Do you have any sources to cite for this?  Bing users?  Google Maps users?  OSM 
users?  Who, exactly is "expecting" this and how do you know this?  What 
matters here and now is the OSM community's acceptance of the quality of these 
data.  Is Canada able to MAKE such a determination?  I think so.

> There is a case that says to keep up with the competitors we really ought to 
> have buildings.

John, I believe you are the first to ever assert "we ought to have buildings" 
I've ever seen in OSM.  What "case" are you talking about?

> I think someone else has commented that parts of the Microsoft building 
> outline from scanned images in the US is problematic.

Well, then say so.  Say who.  Say when.  Say where.  Say what you mean by 
"problematic."  Let us (the OSM community) reflect on these comments.  Let us 
(the OSM community) make our own determinations whether this is or isn't 
"problematic."  Those issues are a completely separate issue from OSM, although 
there might be overlap, I simply don't know, as you haven't given us any data, 
simply your opinion.  I'd like to know, but I can't, given what you have 
offered.

> So given the results in Ottawa are comparable to Ontario and in my opinion 
> Ottawa is acceptable then I think the rest is also acceptable.

OK:  one vote in the fog of consensus.  I have very little data to go on, and 
I'm not completely certain why, but it is an assertion of an OSM volunteer 
saying "then I think..." something.

> Certainly Kingston where not all building angles were right angles weren't 
> noticeable to me by eye or perhaps my eyesight is just getting worse with age.

Canada (and OSM) either agrees its building data for the five provincial 
datasets are OK, or Canada (and OSM) don't.  As I've heard many here (I don't 
need to cite them, these cite themselves) say "I don't" or "we don't" (think 
the datasets are OK), the next things to say are "Well, they seem fixable with 
some algorithmic/programatic massaging, so, how do we fix them?"  Or, "OK, 
here's how we're going to fix them."  (Simplify the nodes, make them have 90º 
angles, whatever).  This doesn't seem like it's an impossible finish line to 
cross, though I do see at least one person running in detours going nowhere.

In short:  "what's wrong with these data, how might they get fixed?"  (Then 
they might get imported).  It doesn't seem to me to be a whole lot more 
complicated a discussion than that.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-01-31 Thread john whelan

I can't think of a way to pull in all the suspect buildings but if you have
a look here:

https://www.openstreetmap.org/search?query=k4a%201m7%20canada#map=19/45.47095/-75.48696

556, 558, 560 are all examples that I think would fail your test.  However
they are the shape of the buildings.

As far as I am aware we haven't had any outraged users complaining about
the building shapes in Ottawa and that I think is the acid test.  The
Ottawa building import has been useful certainly in gaining new mappers and
adding tags to the outlines.

Your test originally was to pick out very badly mapped buildings that had
been done in iD and I would agree with you that some were very bad.
Sometimes 3 or 4 times the size of the building and some very odd shapes
indeed.  From memory most were done on HOT tasks with the iD editor.

These I think we should definitely aim to avoid but where the
representation of the building is reasonably accurate then I think they are
acceptable.  We are using reasonably experienced mappers who would balk at
importing some of the stuff we saw in Nepal etc and rightly so.  They'd
almost certainly be very vocal about the quality of the data.

There is a case to be made that most residential buildings would be
acceptable if they were mapped with the JOSM buildings_tool plugin and all
the small blobs take up database size.  There is also a case that you get a
better sense of the building with the small blobs, bay windows etc.  I
don't have strong feelings either way but I strongly suspect there are
examples of both already in OSM in Canada.

I note that both Google and Bing have most buildings these days and it has
almost become a map user expectation.  Certainly there are apps that guide
blind people that use the building outlines in OSM.  There is a case that
says to keep up with the competitors we really ought to have buildings.

I think someone else has commented that parts of the Microsoft building
outline from scanned images in the US is problematic.

So given the results in Ottawa are comparable to Ontario and in my opinion
Ottawa is acceptable then I think the rest is also acceptable.  Certainly
Kingston where not all building angles were right angles weren't
noticeable to me by eye or perhaps my eyesight is just getting worse with
age.

Cheerio John

On Thu, 31 Jan 2019 at 19:51, Pierre Béland  wrote:

> Salut John,
>
> Voici les résultats d'analyse de géométrie des bâtiments pour Ottawa
> centre-ville.
> bbox : 45.4224,-75.6994,45.4568,-75.6122
>
> -  20,372 Bâtiments
> -  173 Bâtiments avec superposition  (0.1%)
> -   11,534 Bâtiments avec formes irrégulières  (56.6%)
>
> Nous avons donc un résultat semblable aux imports en Ontario que j'ai
> analysé il y quelques jours. A mon avis, en haut de 5%, il faut regarder de
> plus près et expliquer pourquoi autant de formes irrégulières.
>
> J'ai créé des Requêtes overpass pour extraire les bâtiments identifiés
> dans l'analyse. Télécharger les requêtes à partir des fichiers ci-joints.
>
>
> Pierre
>
>
> 173 Batiments avec superposition
> Req Overpass voir
>
> https://www.dropbox.com/s/fp1cimouhhfbm9s/on_Ottawa_centre_2019-01-31_batiments_superposes_OSM_req_Overpass.txt?dl=0
>
>
> 11,534 Bâtiments avec formes irrégulières  (56.6%)
> Req Overpass voir
>
> https://www.dropbox.com/s/c68nb9dbudtp679/on_Ottawa_centre_2019-01-31_batiments_irreg_OSM_req_Overpass.txt?dl=0
>
>
>
>
>
>
>
> -
>
> Le lundi 28 janvier 2019 09 h 17 min 37 s HNE, john whelan <
> jwhelan0...@gmail.com> a écrit :
>
>
> Interesting, although I'm not sure what the best approach is.
>
> 31 Hamilton is interesting.  If you look at the buildings next to it they
> don't have house numbers.  Look at the history and you'll see it was first
> created in 2010 with potlatch and edited once more in 2011.
>
> At my first glance at Kingston the small deviations form 90 degrees did
> not stand out.
>
> I think we can reasonably expect Microsoft to create a Canadian buildings
> file and you seem to be comfortable that the ones it has in the US are of a
> reasonable standard.
>
> Part of my background is large databases and my personal view is the
> minimum data needed the faster the system runs and less data needs to get
> flipped round and backed up.
>
> Could you run the analysis over Ottawa?
>
> Looking closely at a few in Ottawa I note that there are some bay windows
> and other small features I might not have bothered with if mapping with
> JOSM with the buildings_tool. Because of a few 45 degree angles involved
> this isn't something that can be easily solved.
>
> Ottawa I think at some level can be considered a reasonable success.
> Certainly we added a lot of extra information to the building outlines.
>
> I think the trade off is using the municipal data gives us the buildings
> with perhaps more detail than I might like but many would like to see the
> buildings imported.
>
> Dunno (Do not

Re: [Talk-ca] Building Import update

2019-01-31 Thread Pierre Béland via Talk-ca

Salut John,
Voici les résultats d'analyse de géométrie des bâtiments pour Ottawa 
centre-ville.bbox : 45.4224,-75.6994,45.4568,-75.6122
-  20,372 Bâtiments
-      173 Bâtiments avec superposition  (0.1%)
-   11,534 Bâtiments avec formes irrégulières  (56.6%)

Nous avons donc un résultat semblable aux imports en Ontario que j'ai analysé 
il y quelques jours. A mon avis, en haut de 5%, il faut regarder de plus près 
et expliquer pourquoi autant de formes irrégulières.

J'ai créé des Requêtes overpass pour extraire les bâtiments identifiés dans 
l'analyse. Télécharger les requêtes à partir des fichiers ci-joints. 

Pierre 
 

173 Batiments avec superposition
Req Overpass 
voirhttps://www.dropbox.com/s/fp1cimouhhfbm9s/on_Ottawa_centre_2019-01-31_batiments_superposes_OSM_req_Overpass.txt?dl=0

11,534 Bâtiments avec formes irrégulières  (56.6%)
Req Overpass voir 
https://www.dropbox.com/s/c68nb9dbudtp679/on_Ottawa_centre_2019-01-31_batiments_irreg_OSM_req_Overpass.txt?dl=0





-

Le lundi 28 janvier 2019 09 h 17 min 37 s HNE, john whelan 
 a écrit :  
 
 Interesting, although I'm not sure what the best approach is.  
31 Hamilton is interesting.  If you look at the buildings next to it they don't 
have house numbers.  Look at the history and you'll see it was first created in 
2010 with potlatch and edited once more in 2011.
At my first glance at Kingston the small deviations form 90 degrees did not 
stand out. 
I think we can reasonably expect Microsoft to create a Canadian buildings file 
and you seem to be comfortable that the ones it has in the US are of a 
reasonable standard.
Part of my background is large databases and my personal view is the minimum 
data needed the faster the system runs and less data needs to get flipped round 
and backed up.
Could you run the analysis over Ottawa?
Looking closely at a few in Ottawa I note that there are some bay windows and 
other small features I might not have bothered with if mapping with JOSM with 
the buildings_tool. Because of a few 45 degree angles involved this isn't 
something that can be easily solved.
Ottawa I think at some level can be considered a reasonable success.  Certainly 
we added a lot of extra information to the building outlines.
I think the trade off is using the municipal data gives us the buildings with 
perhaps more detail than I might like but many would like to see the buildings 
imported.
Dunno (Do not know for translate tools.)
What is the ideal building outline in OpenStreetMap?
What is an acceptable building outline in OpenStreetMap?  

Suggestions
Thanks
Cheerio John

 
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-01-28 Thread Yaro Shkvorets

Hey Nate,
I've also looked into it and came across this paper:
https://www.josis.org/index.php/josis/article/view/276/166
Sounds like what we need.
IMO this is the kind of stuff that needs to be dealt with in JOSM on a
per-square basis rather than modifying original data. So you have control
over the result and can possibly tweak it in the process if there are any
issues. I've looked into plugins and found only "Building Generalization"
plugin (
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Building_Generalization)
that is supposed to be able to fix this kind of problem. However, after
running it on an area from Texas import with 90% of problematic buildings,
it turns out to be doing pretty bad job: https://i.imgur.com/P5mbjRf.jpg




On Mon, Jan 28, 2019 at 10:08 AM Nate Wessel  wrote:

> Hi all,
>
> I was reading about orthogonalization yesterday and came across this
> paper...
>
>
> https://icaci.org/files/documents/ICC_proceedings/ICC2009/html/refer/19_2.pdf
>
> ...which describes an algorithm that seems to quite effectively disregard
> angles that are not close to orthogonal while straightening those that are.
> I added a link to it in the wiki. This may not be implemented in JOSM, but
> there's no reason we couldn't pre-process the data in this way.
>
> From Pierre's analysis, it sounds to me like we really do need to consider
> orthogonalizing buildings where possible, which should be pretty much all
> buildings (I could see some buildings sharing nodes getting complicated).
> Once the angles are corrected, I imagine we should be able to simplify with
> a very small threshold and get good results.
>
> Given the number of buildings in this import, this is absolutely something
> worth doing. Four million buildings times one tiny problem equals one
> really huge problem. Let's fix it now while it's still relatively easy.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/28/19 9:17 AM, john whelan wrote:
>
> Interesting, although I'm not sure what the best approach is.
>
> 31 Hamilton is interesting.  If you look at the buildings next to it they
> don't have house numbers.  Look at the history and you'll see it was first
> created in 2010 with potlatch and edited once more in 2011.
>
> At my first glance at Kingston the small deviations form 90 degrees did
> not stand out.
>
> I think we can reasonably expect Microsoft to create a Canadian buildings
> file and you seem to be comfortable that the ones it has in the US are of a
> reasonable standard.
>
> Part of my background is large databases and my personal view is the
> minimum data needed the faster the system runs and less data needs to get
> flipped round and backed up.
>
> Could you run the analysis over Ottawa?
>
> Looking closely at a few in Ottawa I note that there are some bay windows
> and other small features I might not have bothered with if mapping with
> JOSM with the buildings_tool. Because of a few 45 degree angles involved
> this isn't something that can be easily solved.
>
> Ottawa I think at some level can be considered a reasonable success.
> Certainly we added a lot of extra information to the building outlines.
>
> I think the trade off is using the municipal data gives us the buildings
> with perhaps more detail than I might like but many would like to see the
> buildings imported.
>
> Dunno (Do not know for translate tools.)
>
> What is the ideal building outline in OpenStreetMap?
>
> What is an acceptable building outline in OpenStreetMap?
>
> Suggestions
>
> Thanks
>
> Cheerio John
>
> On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:
>
>> Bonjour John
>>
>> La géométrie des bâtiments est un sujet qui préoccupe plusieurs
>> contributeurs en particulier pour les imports de données. Dans un tel cas,
>> il est difficile de revenir en arrière et il est préférable de bien
>> planifier, analyser.  Comme on le voit avec l'import en Ontario, on observe
>> qu'il est possible de s'assurer que les données soient orthogonales et que
>> les noeuds inutiles soient éliminées.
>>
>> En comparaision les données  Microsoft importées à Arlington, au Texas
>> présentent des géométries plus standard.  À première vue, les ratios de
>> géométrie irrégulières semblent beaucoup plus bas.
>>
>> Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données
>> importées dans la zone Oshawa-Hamilton montre 62% sont des polygones avec
>> des formes irrégulières.
>>
>> A noter que pour déterminer les polygones réguliers, j'utilise un spectre
>> de degrés assez large
>> - lignes droites entre 178 et 182 degrés
>> - angles droits entre 88 et 92 degrés, entre 268 et 272
>> - autres types de polygones : variation de +-2.2% vs angle moyen pour le
>> polygone (octogones, hexagones, etc)
>>
>> Dans les analyses de géométrie, un grand nombre de polygones classés
>> FB_oo ont des géométries où on retrouve des batiments presque orthogonaux
>> mais avec un ou

Re: [Talk-ca] Building Import update

2019-01-28 Thread Pierre Béland via Talk-ca

Ok John,
je vais lancer le script pour Ottawa. Mais je dois régler petit soucis 
d'instabilité  windows avec java et osmosis.  Ne peut mettre a jour java. Et 
powershell refuse parfois de reconnaitre commandes exe.

Parmi tous les scripts de conversion de raster / vectoriel, il serait oui 
intéressant de trouver un script opensource qui corrige les problèmes 
d'orthogonalisation. 

Un défi supplémentaire, lorsque des batiments adjacents partagent des lignes de 
contour. Dans JOSM, lorsque je vois de telles situations, je traite si possible 
en bloc tous les batiments et réoriente ensuite si nécessaire pour mieux 
correspondre à l'imagerie.

 
Pierre 
 

Le lundi 28 janvier 2019 09 h 17 min 37 s HNE, john whelan 
 a écrit :  
 
 Interesting, although I'm not sure what the best approach is.  
31 Hamilton is interesting.  If you look at the buildings next to it they don't 
have house numbers.  Look at the history and you'll see it was first created in 
2010 with potlatch and edited once more in 2011.
At my first glance at Kingston the small deviations form 90 degrees did not 
stand out. 
I think we can reasonably expect Microsoft to create a Canadian buildings file 
and you seem to be comfortable that the ones it has in the US are of a 
reasonable standard.
Part of my background is large databases and my personal view is the minimum 
data needed the faster the system runs and less data needs to get flipped round 
and backed up.
Could you run the analysis over Ottawa?
Looking closely at a few in Ottawa I note that there are some bay windows and 
other small features I might not have bothered with if mapping with JOSM with 
the buildings_tool. Because of a few 45 degree angles involved this isn't 
something that can be easily solved.
Ottawa I think at some level can be considered a reasonable success.  Certainly 
we added a lot of extra information to the building outlines.
I think the trade off is using the municipal data gives us the buildings with 
perhaps more detail than I might like but many would like to see the buildings 
imported.
Dunno (Do not know for translate tools.)
What is the ideal building outline in OpenStreetMap?
What is an acceptable building outline in OpenStreetMap?  

Suggestions
Thanks
Cheerio John
On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:

Bonjour John
La géométrie des bâtiments est un sujet qui préoccupe plusieurs contributeurs 
en particulier pour les imports de données. Dans un tel cas, il est difficile 
de revenir en arrière et il est préférable de bien planifier, analyser.  Comme 
on le voit avec l'import en Ontario, on observe qu'il est possible de s'assurer 
que les données soient orthogonales et que les noeuds inutiles soient éliminées.
En comparaision les données  Microsoft importées à Arlington, au Texas 
présentent des géométries plus standard.  À première vue, les ratios de 
géométrie irrégulières semblent beaucoup plus bas. 

Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données importées 
dans la zone Oshawa-Hamilton montre 62% sont des polygones avec des formes 
irrégulières.
A noter que pour déterminer les polygones réguliers, j'utilise un spectre de 
degrés assez large 
- lignes droites entre 178 et 182 degrés
- angles droits entre 88 et 92 degrés, entre 268 et 272
- autres types de polygones : variation de +-2.2% vs angle moyen pour le 
polygone (octogones, hexagones, etc)
Dans les analyses de géométrie, un grand nombre de polygones classés FB_oo ont 
des géométries où on retrouve des batiments presque orthogonaux mais avec un ou 
des angles entre 86 et 94 degrés. Cela veut sans doute représenter des angles 
droits mais l'écart est assez grand. Dois-t-on se satisfaire de cela? 
En ce qui a trait aux normes de qualité, elle sont généralement implicites et 
guidées par les outils disponiibles. Avec JOSM, on s'attend généralement qu'un 
contributeur utilisera le greffon Building et saura tracer des batiments 
rectangulaires et si nécessaire superposer plusieurs formes rectangulaires 
légérement décalées et les joindre en un seul polygone.  Les contributeurs 
devraient normalement aussi maitriser les notions de perspective lorsque 
l'image est prise avec un certain angle par rapport à la verticale.  Les outils 
d'intelligence artificielle aussi ?

Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie des 
bâtiments ?
L'exemple de géométrie que tu as présenté, on le retrouve effectivement 
beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon 
fichier par ce que le contributeur n'était pas répertorié dans le projet 
http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les contributeurs qui 
y apparaissait.
Pour des exemples similaires contenus dans le fichier d'analyse, regardes près 
du 31 Hamilton 
street.https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
  
Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et des 
quasi 90 degrés (oo) et des angles

Re: [Talk-ca] Building Import update

2019-01-28 Thread Yaro Shkvorets

As far as I know Texas has been using 2 sources for their buildings
imports.

   1. Microsoft, (example:
   https://www.openstreetmap.org/#map=18/32.74517/-97.14334) Even in
   suburbs (that are supposed to be easy for their AI), buildings lack any
   details and sometimes are not even aligned with the roads.
   https://i.imgur.com/eWroYZB.png Some that are in the shades are even
   missing: https://i.imgur.com/8SF3sS4.jpg I can only imagine what it
   looks like downtown. Sure they don't get flagged with "almost square
   angles" but that's pretty much the only thing they have going for them.
   2. OrthoTexas. Much better details but the first place I look, vast
   majority buildings do not have square angles:
   https://www.openstreetmap.org/#map=19/32.97102/-96.78231 Probably even
   worse than in Ontario.

Compared to both of those sources, StatsCan data is much more detailed and
is better aligned with the imagery and surroundings.
If we are so determined to map for the Validator (which I'm not sure is the
right OSM approach) we should fix StatsCan data. I remember there was a
standard JOSM warning for "almost square angles" with autofix a year ago or
so. Does anyone know what happened to it?


On Mon, Jan 28, 2019 at 9:20 AM john whelan  wrote:

> Interesting, although I'm not sure what the best approach is.
>
> 31 Hamilton is interesting.  If you look at the buildings next to it they
> don't have house numbers.  Look at the history and you'll see it was first
> created in 2010 with potlatch and edited once more in 2011.
>
> At my first glance at Kingston the small deviations form 90 degrees did
> not stand out.
>
> I think we can reasonably expect Microsoft to create a Canadian buildings
> file and you seem to be comfortable that the ones it has in the US are of a
> reasonable standard.
>
> Part of my background is large databases and my personal view is the
> minimum data needed the faster the system runs and less data needs to get
> flipped round and backed up.
>
> Could you run the analysis over Ottawa?
>
> Looking closely at a few in Ottawa I note that there are some bay windows
> and other small features I might not have bothered with if mapping with
> JOSM with the buildings_tool. Because of a few 45 degree angles involved
> this isn't something that can be easily solved.
>
> Ottawa I think at some level can be considered a reasonable success.
> Certainly we added a lot of extra information to the building outlines.
>
> I think the trade off is using the municipal data gives us the buildings
> with perhaps more detail than I might like but many would like to see the
> buildings imported.
>
> Dunno (Do not know for translate tools.)
>
> What is the ideal building outline in OpenStreetMap?
>
> What is an acceptable building outline in OpenStreetMap?
>
> Suggestions
>
> Thanks
>
> Cheerio John
>
> On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:
>
>> Bonjour John
>>
>> La géométrie des bâtiments est un sujet qui préoccupe plusieurs
>> contributeurs en particulier pour les imports de données. Dans un tel cas,
>> il est difficile de revenir en arrière et il est préférable de bien
>> planifier, analyser.  Comme on le voit avec l'import en Ontario, on observe
>> qu'il est possible de s'assurer que les données soient orthogonales et que
>> les noeuds inutiles soient éliminées.
>>
>> En comparaision les données  Microsoft importées à Arlington, au Texas
>> présentent des géométries plus standard.  À première vue, les ratios de
>> géométrie irrégulières semblent beaucoup plus bas.
>>
>> Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données
>> importées dans la zone Oshawa-Hamilton montre 62% sont des polygones avec
>> des formes irrégulières.
>>
>> A noter que pour déterminer les polygones réguliers, j'utilise un spectre
>> de degrés assez large
>> - lignes droites entre 178 et 182 degrés
>> - angles droits entre 88 et 92 degrés, entre 268 et 272
>> - autres types de polygones : variation de +-2.2% vs angle moyen pour le
>> polygone (octogones, hexagones, etc)
>>
>> Dans les analyses de géométrie, un grand nombre de polygones classés
>> FB_oo ont des géométries où on retrouve des batiments presque orthogonaux
>> mais avec un ou des angles entre 86 et 94 degrés. Cela veut sans doute
>> représenter des angles droits mais l'écart est assez grand. Dois-t-on se
>> satisfaire de cela?
>>
>> En ce qui a trait aux normes de qualité, elle sont généralement
>> implicites et guidées par les outils disponiibles. Avec JOSM, on s'attend
>> généralement qu'un contributeur utilisera le greffon Building et saura
>> tracer des batiments rectangulaires et si nécessaire superposer plusieurs
>> formes rectangulaires légérement décalées et les joindre en un seul
>> polygone.  Les contributeurs devraient normalement aussi maitriser les
>> notions de perspective lorsque l'image est prise avec un certain angle par
>> rapport à la verticale.  Les outils d'intelligence artificielle aussi ?
>>
>> Selon toi,

Re: [Talk-ca] Building Import update

2019-01-28 Thread Nate Wessel


Hi all,

I was reading about orthogonalization yesterday and came across this 
paper...


https://icaci.org/files/documents/ICC_proceedings/ICC2009/html/refer/19_2.pdf

...which describes an algorithm that seems to quite effectively 
disregard angles that are not close to orthogonal while straightening 
those that are. I added a link to it in the wiki. This may not be 
implemented in JOSM, but there's no reason we couldn't pre-process the 
data in this way.


From Pierre's analysis, it sounds to me like we really do need to 
consider orthogonalizing buildings where possible, which should be 
pretty much all buildings (I could see some buildings sharing nodes 
getting complicated). Once the angles are corrected, I imagine we should 
be able to simplify with a very small threshold and get good results.


Given the number of buildings in this import, this is absolutely 
something worth doing. Four million buildings times one tiny problem 
equals one really huge problem. Let's fix it now while it's still 
relatively easy.


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/28/19 9:17 AM, john whelan wrote:

Interesting, although I'm not sure what the best approach is.

31 Hamilton is interesting.  If you look at the buildings next to it 
they don't have house numbers.  Look at the history and you'll see it 
was first created in 2010 with potlatch and edited once more in 2011.


At my first glance at Kingston the small deviations form 90 degrees 
did not stand out.


I think we can reasonably expect Microsoft to create a Canadian 
buildings file and you seem to be comfortable that the ones it has in 
the US are of a reasonable standard.


Part of my background is large databases and my personal view is the 
minimum data needed the faster the system runs and less data needs to 
get flipped round and backed up.


Could you run the analysis over Ottawa?

Looking closely at a few in Ottawa I note that there are some bay 
windows and other small features I might not have bothered with if 
mapping with JOSM with the buildings_tool. Because of a few 45 degree 
angles involved this isn't something that can be easily solved.


Ottawa I think at some level can be considered a reasonable success. 
Certainly we added a lot of extra information to the building outlines.


I think the trade off is using the municipal data gives us the 
buildings with perhaps more detail than I might like but many would 
like to see the buildings imported.


Dunno (Do not know for translate tools.)

What is the ideal building outline in OpenStreetMap?

What is an acceptable building outline in OpenStreetMap?

Suggestions

Thanks

Cheerio John

On Sun, 27 Jan 2019 at 23:28, Pierre Béland > wrote:


Bonjour John

La géométrie des bâtiments est un sujet qui préoccupe plusieurs
contributeurs en particulier pour les imports de données. Dans un
tel cas, il est difficile de revenir en arrière et il est
préférable de bien planifier, analyser.  Comme on le voit avec
l'import en Ontario, on observe qu'il est possible de s'assurer
que les données soient orthogonales et que les noeuds inutiles
soient éliminées.

En comparaision les données  Microsoft importées à Arlington, au
Texas présentent des géométries plus standard.  À première vue,
les ratios de géométrie irrégulières semblent beaucoup plus bas.

Une nouvelle analyse pour l'Ontario, cette fois-ci pour les
données importées dans la zone Oshawa-Hamilton montre 62% sont des
polygones avec des formes irrégulières.

A noter que pour déterminer les polygones réguliers, j'utilise un
spectre de degrés assez large
- lignes droites entre 178 et 182 degrés
- angles droits entre 88 et 92 degrés, entre 268 et 272
- autres types de polygones : variation de +-2.2% vs angle moyen
pour le polygone (octogones, hexagones, etc)

Dans les analyses de géométrie, un grand nombre de polygones
classés FB_oo ont des géométries où on retrouve des batiments
presque orthogonaux mais avec un ou des angles entre 86 et 94
degrés. Cela veut sans doute représenter des angles droits mais
l'écart est assez grand. Dois-t-on se satisfaire de cela?

En ce qui a trait aux normes de qualité, elle sont généralement
implicites et guidées par les outils disponiibles. Avec JOSM, on
s'attend généralement qu'un contributeur utilisera le greffon
Building et saura tracer des batiments rectangulaires et si
nécessaire superposer plusieurs formes rectangulaires légérement
décalées et les joindre en un seul polygone. Les contributeurs
devraient normalement aussi maitriser les notions de perspective
lorsque l'image est prise avec un certain angle par rapport à la
verticale.  Les outils d'intelligence artificielle aussi ?

Selon toi, quelles règles devrait-on appliquer pour évaluer la
géométrie

Re: [Talk-ca] Building Import update

2019-01-28 Thread john whelan

Interesting, although I'm not sure what the best approach is.

31 Hamilton is interesting.  If you look at the buildings next to it they
don't have house numbers.  Look at the history and you'll see it was first
created in 2010 with potlatch and edited once more in 2011.

At my first glance at Kingston the small deviations form 90 degrees did not
stand out.

I think we can reasonably expect Microsoft to create a Canadian buildings
file and you seem to be comfortable that the ones it has in the US are of a
reasonable standard.

Part of my background is large databases and my personal view is the
minimum data needed the faster the system runs and less data needs to get
flipped round and backed up.

Could you run the analysis over Ottawa?

Looking closely at a few in Ottawa I note that there are some bay windows
and other small features I might not have bothered with if mapping with
JOSM with the buildings_tool. Because of a few 45 degree angles involved
this isn't something that can be easily solved.

Ottawa I think at some level can be considered a reasonable success.
Certainly we added a lot of extra information to the building outlines.

I think the trade off is using the municipal data gives us the buildings
with perhaps more detail than I might like but many would like to see the
buildings imported.

Dunno (Do not know for translate tools.)

What is the ideal building outline in OpenStreetMap?

What is an acceptable building outline in OpenStreetMap?

Suggestions

Thanks

Cheerio John

On Sun, 27 Jan 2019 at 23:28, Pierre Béland  wrote:

> Bonjour John
>
> La géométrie des bâtiments est un sujet qui préoccupe plusieurs
> contributeurs en particulier pour les imports de données. Dans un tel cas,
> il est difficile de revenir en arrière et il est préférable de bien
> planifier, analyser.  Comme on le voit avec l'import en Ontario, on observe
> qu'il est possible de s'assurer que les données soient orthogonales et que
> les noeuds inutiles soient éliminées.
>
> En comparaision les données  Microsoft importées à Arlington, au Texas
> présentent des géométries plus standard.  À première vue, les ratios de
> géométrie irrégulières semblent beaucoup plus bas.
>
> Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données
> importées dans la zone Oshawa-Hamilton montre 62% sont des polygones avec
> des formes irrégulières.
>
> A noter que pour déterminer les polygones réguliers, j'utilise un spectre
> de degrés assez large
> - lignes droites entre 178 et 182 degrés
> - angles droits entre 88 et 92 degrés, entre 268 et 272
> - autres types de polygones : variation de +-2.2% vs angle moyen pour le
> polygone (octogones, hexagones, etc)
>
> Dans les analyses de géométrie, un grand nombre de polygones classés FB_oo
> ont des géométries où on retrouve des batiments presque orthogonaux mais
> avec un ou des angles entre 86 et 94 degrés. Cela veut sans doute
> représenter des angles droits mais l'écart est assez grand. Dois-t-on se
> satisfaire de cela?
>
> En ce qui a trait aux normes de qualité, elle sont généralement implicites
> et guidées par les outils disponiibles. Avec JOSM, on s'attend généralement
> qu'un contributeur utilisera le greffon Building et saura tracer des
> batiments rectangulaires et si nécessaire superposer plusieurs formes
> rectangulaires légérement décalées et les joindre en un seul polygone.  Les
> contributeurs devraient normalement aussi maitriser les notions de
> perspective lorsque l'image est prise avec un certain angle par rapport à
> la verticale.  Les outils d'intelligence artificielle aussi ?
>
> Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie
> des bâtiments ?
>
> L'exemple de géométrie que tu as présenté, on le retrouve effectivement
> beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon
> fichier par ce que le contributeur n'était pas répertorié dans le projet
> http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les
> contributeurs qui y apparaissait.
>
> Pour des exemples similaires contenus dans le fichier d'analyse, regardes
> près du 31 Hamilton street.
> https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
>
>
> Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et
> des quasi 90 degrés (oo) et des angles irréguliers tles 98,8, 94,3
> Est-ce un polygone irrégulier ou un effet de perspective? Comment le
> représenter?
> "59879471""22""FB_irreg"
>  "{o,o,o,o,ir,ir,ir,ir,oo,o,o,oo,oo,ir,oo,o,oo,rr,ir,ir,o,o}"
>  
> "{90.6,90.7,89.3,89.2,95.4,94.8,178,83.2,86.1,90.9,89.2,94,93.6,94.3,93.1,89.9,93.8,171.2,98.8,94.3,90.9,89.9}"
>
> Angle 177,6 presque droit, noeud inutile - normalement un simple rectangle
> "657790097""5""FB_irreg""{o,o,ir,o,o}"
>  "{90,91,177.6,91.4,90}"
>
>
> Un peu d'humour la-dessus. Un robot trace un rectangle parfait. Un premier
> contributeur le voit et dit cela ne semble pas normal et y ajoute un peu de
> distorsion. Un deuxième

Re: [Talk-ca] Building Import update

2019-01-27 Thread Pierre Béland via Talk-ca

Bonjour John
La géométrie des bâtiments est un sujet qui préoccupe plusieurs contributeurs 
en particulier pour les imports de données. Dans un tel cas, il est difficile 
de revenir en arrière et il est préférable de bien planifier, analyser.  Comme 
on le voit avec l'import en Ontario, on observe qu'il est possible de s'assurer 
que les données soient orthogonales et que les noeuds inutiles soient éliminées.
En comparaision les données  Microsoft importées à Arlington, au Texas 
présentent des géométries plus standard.  À première vue, les ratios de 
géométrie irrégulières semblent beaucoup plus bas. 

Une nouvelle analyse pour l'Ontario, cette fois-ci pour les données importées 
dans la zone Oshawa-Hamilton montre 62% sont des polygones avec des formes 
irrégulières.
A noter que pour déterminer les polygones réguliers, j'utilise un spectre de 
degrés assez large 
- lignes droites entre 178 et 182 degrés
- angles droits entre 88 et 92 degrés, entre 268 et 272
- autres types de polygones : variation de +-2.2% vs angle moyen pour le 
polygone (octogones, hexagones, etc)
Dans les analyses de géométrie, un grand nombre de polygones classés FB_oo ont 
des géométries où on retrouve des batiments presque orthogonaux mais avec un ou 
des angles entre 86 et 94 degrés. Cela veut sans doute représenter des angles 
droits mais l'écart est assez grand. Dois-t-on se satisfaire de cela? 
En ce qui a trait aux normes de qualité, elle sont généralement implicites et 
guidées par les outils disponiibles. Avec JOSM, on s'attend généralement qu'un 
contributeur utilisera le greffon Building et saura tracer des batiments 
rectangulaires et si nécessaire superposer plusieurs formes rectangulaires 
légérement décalées et les joindre en un seul polygone.  Les contributeurs 
devraient normalement aussi maitriser les notions de perspective lorsque 
l'image est prise avec un certain angle par rapport à la verticale.  Les outils 
d'intelligence artificielle aussi ?

Selon toi, quelles règles devrait-on appliquer pour évaluer la géométrie des 
bâtiments ?
L'exemple de géométrie que tu as présenté, on le retrouve effectivement 
beaucoup dans les imports pour l'Ontario. Ce bâtiment n'est pas dans mon 
fichier par ce que le contributeur n'était pas répertorié dans le projet 
http://tasks.osmcanada.ca/project/145. Je n'ai retenu que les contributeurs qui 
y apparaissait.
Pour des exemples similaires contenus dans le fichier d'analyse, regardes près 
du 31 Hamilton 
street.https://www.openstreetmap.org/#map=20/44.23749975223997/-76.49539748034509
  
Ce polygone contient 22 angles, des quasi lignes droites (symbole ir), et des 
quasi 90 degrés (oo) et des angles irréguliers tles 98,8, 94,3
Est-ce un polygone irrégulier ou un effet de perspective? Comment le 
représenter?
"59879471"    "22"    "FB_irreg"    
"{o,o,o,o,ir,ir,ir,ir,oo,o,o,oo,oo,ir,oo,o,oo,rr,ir,ir,o,o}"    
"{90.6,90.7,89.3,89.2,95.4,94.8,178,83.2,86.1,90.9,89.2,94,93.6,94.3,93.1,89.9,93.8,171.2,98.8,94.3,90.9,89.9}"

Angle 177,6 presque droit, noeud inutile - normalement un simple rectangle
"657790097"    "5"    "FB_irreg"    "{o,o,ir,o,o}"    "{90,91,177.6,91.4,90}" 
Un peu d'humour la-dessus. Un robot trace un rectangle parfait. Un premier 
contributeur le voit et dit cela ne semble pas normal et y ajoute un peu de 
distorsion. Un deuxième décide d'y ajouter un point et d'étirer le tout. Si on 
poursuit le dessin dans ce sens, cela finira par ressembler à un clown!


Pierre 
 

Le dimanche 27 janvier 2019 09 h 51 min 10 s HNE, john whelan 
 a écrit :  
 
 If you take a look at 942 Bridle Path Crescent for example whilst it isn't 
exactly square the deviations from 90 degrees to me are relatively minor.  I 
assume that this is the sort of thing you are talking about?

https://www.openstreetmap.org/search?query=942%20Bridle%20Path%20Crescent%20kingston#map=19/44.25311/-76.59308
Are we expecting too high a standard?
Cheerio John

  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-01-27 Thread john whelan

If you take a look at 942 Bridle Path Crescent for example whilst it isn't
exactly square the deviations from 90 degrees to me are relatively minor.
I assume that this is the sort of thing you are talking about?

https://www.openstreetmap.org/search?query=942%20Bridle%20Path%20Crescent%20kingston#map=19/44.25311/-76.59308

Are we expecting too high a standard?

Cheerio John

On Sat, 26 Jan 2019 at 21:54, Pierre Béland via Talk-ca <
talk-ca@openstreetmap.org> wrote:

> Nate je viens juste de publier les résultats pour Kingston. Un ratio de
> 66% de polygones avec formes irrégulières. A voir si la simplification
> éliminerait les noeuds qui ont pour effet de créer des formes irrégulières.
>
> Je n'ai pas encore regardé de près les résultats. Cependant, m on
> expérience en République démocratique du Congo depuis l'an dernier, Kisenso
> et récemment Butembo, a montré qu'a partir de ces diagostics, la validation
> / correction si nécessaire des polygones permettait de réduire fortement
> les ratios, et ce sous les 3% des bâtiments.
>
> Je pense aussi qu'il faut prendre le temps de corriger les données qui
> risque de ne pas être modifiées par la suite.
>
>
>
> Pierre
>
>
> Le samedi 26 janvier 2019 21 h 06 min 39 s HNE, Nate Wessel <
> bike...@gmail.com> a écrit :
>
>
> James,
>
> It does seem that someone will need to properly simplify the data since
> you don't seem willing to do the necessary work. I've already offered to
> help, but I can't do it today, or tomorrow for that matter. My suggestion,
> again, is that we slow down and take the time to do this right. Rushing
> ahead can only lead to hurt feelings, angry emails, and extra work for
> everyone. Given how much editing goes on in the areas I know, many of these
> imported buildings might not be touched again for another decade - can't we
> make them right the first time?
>
> I think Pierre is on the right track here with his thoughtful analysis of
> the buildings that have been imported so far - this is the kind of stuff
> that I'm talking about when I say we need some validation. Some questions
> that I'd like to see answered (Pierre, when you have some more time!): just
> how many buildings imported so far are not orthogonal, but seem like they
> should be? What percentage of buildings would benefit from simplification,
> and is the problem worse/better in some areas compared to others?
>
> I actually don't think the problem is technically difficult to solve - we
> just have to understand the nature and extent off the problem before we
> rush to solutions. That's the point of validation - understanding what the
> problems are.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-01-26 Thread Pierre Béland via Talk-ca

Nate je viens juste de publier les résultats pour Kingston. Un ratio de 66% de 
polygones avec formes irrégulières. A voir si la simplification éliminerait les 
noeuds qui ont pour effet de créer des formes irrégulières. 

Je n'ai pas encore regardé de près les résultats. Cependant, m on expérience en 
République démocratique du Congo depuis l'an dernier, Kisenso et récemment 
Butembo, a montré qu'a partir de ces diagostics, la validation / correction si 
nécessaire des polygones permettait de réduire fortement les ratios, et ce sous 
les 3% des bâtiments.
Je pense aussi qu'il faut prendre le temps de corriger les données qui risque 
de ne pas être modifiées par la suite. 


 
Pierre 
 

Le samedi 26 janvier 2019 21 h 06 min 39 s HNE, Nate Wessel 
 a écrit :  
 
  
James, 
 
 
It does seem that someone will need to properly simplify the data since you 
don't seem willing to do the necessary work. I've already offered to help, but 
I can't do it today, or tomorrow for that matter. My suggestion, again, is that 
we slow down and take the time to do this right. Rushing ahead can only lead to 
hurt feelings, angry emails, and extra work for everyone. Given how much 
editing goes on in the areas I know, many of these imported buildings might not 
be touched again for another decade - can't we make them right the first time?
 
 
I think Pierre is on the right track here with his thoughtful analysis of the 
buildings that have been imported so far - this is the kind of stuff that I'm 
talking about when I say we need some validation. Some questions that I'd like 
to see answered (Pierre, when you have some more time!): just how many 
buildings imported so far are not orthogonal, but seem like they should be? 
What percentage of buildings would benefit from simplification, and is the 
problem worse/better in some areas compared to others?
 
I actually don't think the problem is technically difficult to solve - we just 
have to understand the nature and extent off the problem before we rush to 
solutions. That's the point of validation - understanding what the problems are.
 
 
Best,
 
 Nate Wessel
 Jack of all trades, Master of Geography, PhD candidate in Urban Planning
 NateWessel.com 
 
 
  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-01-26 Thread Pierre Béland via Talk-ca

Voici mon analyse de la géométrie des bâtiments pour Kingston.  À partir des 
uid des contributeurs ayant participé à l'import, j'ai téléchargé pour Kingston 
5,261 batîments créés ou modifiés par eux depuis le 24 décembre. Le fichier 
résultat montre 5,253 batiments, quelques polygones en erreur éliminés.
Requête Overpass http://overpass-turbo.eu/s/FzI 
Fichier OSM et Résultats d'analyse  
https://www.dropbox.com/s/1dn76c7gmk996ql/on_kingston.import_2018_12_24.osm.zip?dl=0
L'analyse de la géométrie des bâtiments ci-haut révèle que 66% d'entre eux  
(3,475 / 5,261) ont des formes irrégulières.  Ce ratio de géométries 
irrégulières est très élevé, bien au delà de ce à quoi on devrait normalement 
s'attendre. 


méthodologie
À noter que l'analyse qualité avec JOSM permet de détecter de nombreux 
problèmes, incluant les doublons, superpositions.  Mais aucune analyse de la 
géométrie n'est effectuée.  

Mais il est possible malgré tout de d'analyser les géométries et développer des 
indicateurs qui permettent de lever un Drapeau Regarder de plus près au-dela 
d'un certain niveau. J'identifie les formes régulières comme ci-dessous et 
accepte une tolérance de 2.2% plus ou moins avant de signaler comme forme 
irrégulière.

Polygones avec formes régulières
- forme avec angles droits (90 degrés, 270 degrés)- forme avec angles constants 
(hexagone, octogone, etc)

C'est un domaine où on ne peut mesurer à partir d'une simple formule les 
géométries valides même si avec des formes irrégulières.Par contre, tout ratio 
supérieur à 5 % mérite à mon avis d'être analysé de plus près pour expliquer 
les écarts.

Mon script qualité tient compte de tous les noeuds sauf angle=180 degrés pour 
évaluation géométrie.  Vous pourrez comparer dans le fichier analyse les 
diagnostics individuels pour chaque polygone et pour chacun les angles 
correspondants.

ci-dessous, voici des exemples de résultas de l'analyse des 3,475 bâtiments 
avec formes irrégulières. 

 id nb_angles    forme   type angle angles

"56709982"    "5"    "FB_irreg"    "{o,ir,ir,o,o}"    
"{90,174.9,94.6,90.1,90.3}"
id ci-haut a un 5ième angle presque a 180 degrés. faire zoom-in pour voir.

"56997713"    "14"    "FB_oo"    "{oo,oo,o,o,o,o,o,o,o,o,o,o,o,o}"    
"{92.8,92.2,89.9,90.3,89.9,90.4,90,89.7,89.5,89.5,89.3,88.9,89.2,90.1}"id 
ci-haut, 14 angles, très pres de 90 degrés, mais imprécis
À noter que le script est en développement. Si vous trouvez des incohérences, 
me le signaler.
o et r :     formes régulièresFB_oo et FB_rr : formes presque 
régulièresFB_irreg    formes irrégulières

Pierre 

___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update


James,

It does seem that someone will need to properly simplify the data since 
you don't seem willing to do the necessary work. I've already offered to 
help, but I can't do it today, or tomorrow for that matter. My 
suggestion, again, is that we slow down and take the time to do this 
right. Rushing ahead can only lead to hurt feelings, angry emails, and 
extra work for everyone. Given how much editing goes on in the areas I 
know, many of these imported buildings might not be touched again for 
another decade - can't we make them right the first time?


I think Pierre is on the right track here with his thoughtful analysis 
of the buildings that have been imported so far - this is the kind of 
stuff that I'm talking about when I say we need some validation. Some 
questions that I'd like to see answered (Pierre, when you have some more 
time!): just how many buildings imported so far are not orthogonal, but 
seem like they should be? What percentage of buildings would benefit 
from simplification, and is the problem worse/better in some areas 
compared to others?


I actually don't think the problem is technically difficult to solve - 
we just have to understand the nature and extent off the problem before 
we rush to solutions. That's the point of validation - understanding 
what the problems are.


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/26/19 2:10 PM, James wrote:
I'm not installing postgesql for you to accept simplification, that 
YOU said was required because there were 2x as many points(which was 
proved wrong via the simplification) If you want to have fun with the 
file, go a head.


On Sat., Jan. 26, 2019, 2:00 p.m. Nate Wessel  wrote:


Building count doesn't really have anything to do with preserving
topology, and I'm not sure a visual inspection would cut it - Can
you look at the documentation for this tool and verify that it
preserves the topology of polygon layers?

This is a good illustration of the (potential) problem:
https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com 

On 1/26/19 12:31 PM, James wrote:

it does if you saw my analysis of building(polygon count) remains
the same also visually inspected a few and there was preservation
of them

On Sat., Jan. 26, 2019, 11:43 a.m. Nate Wessel mailto:bike...@gmail.com> wrote:

Does that preserve topology between buildings that share nodes?

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in
Urban Planning
NateWessel.com 

On 1/26/19 11:31 AM, James wrote:

no need for scripts, qgis does this fine via the  Vector
menu -> Geometry tools -> Simplify Geometries utility. I
simplified it to 20cm with the , but I think 40cm is too
aggressive.

I already have scripts to compile it into the dataformat
needed to be served.

On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel
mailto:bike...@gmail.com> wrote:

Hi all,

The wiki page is indeed looking a whole lot better right
now - my thanks and congrats to everyone who
contributed! There is a still a ways to go, but we seem
to be getting there quickly.

I'll echo John in saying that I would appreciate hearing
from some of the other people who chimed in to express
their doubts about the import. For my part, I'm not
satisfied yet - no surprise, I'm sure ;-). I'm thrilled
that we're talking and working together in the open, and
that addresses the biggest concern I had with the import.

These are the big issues I see remaining:

1. *Validation*: Ideally I'd like to see a good chunk
(more than half) of the data that has been imported
already validated by another user before we proceed with
importing more data. Validation is part of the import
plan, so the import isn't done until validation is done
anyway. My hope is that this will flag any issues that
we can fix before moving forward, and give people time
to chime in on the import plan who maybe haven't
already. I don't want to see everything imported and
only then do we start systematically checking the
quality of our work, if ever. If no one wants to do it
now, no one is going to want to do it later either, and
that doesn't bode well.

2. *Simplification*: James' analysis showed that
simplification could save several hundred megabytes (and
probably more) in

Re: [Talk-ca] Building Import update

2019-01-26 Thread James

I'm not installing postgesql for you to accept simplification, that YOU
said was required because there were 2x as many points(which was proved
wrong via the simplification) If you want to have fun with the file, go a
head.

On Sat., Jan. 26, 2019, 2:00 p.m. Nate Wessel  Building count doesn't really have anything to do with preserving
> topology, and I'm not sure a visual inspection would cut it - Can you look
> at the documentation for this tool and verify that it preserves the
> topology of polygon layers?
>
> This is a good illustration of the (potential) problem:
> https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/26/19 12:31 PM, James wrote:
>
> it does if you saw my analysis of building(polygon count) remains the same
> also visually inspected a few and there was preservation of them
>
> On Sat., Jan. 26, 2019, 11:43 a.m. Nate Wessel 
>> Does that preserve topology between buildings that share nodes?
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/26/19 11:31 AM, James wrote:
>>
>> no need for scripts, qgis does this fine via the  Vector menu -> Geometry
>> tools -> Simplify Geometries utility. I simplified it to 20cm with the ,
>> but I think 40cm is too aggressive.
>>
>> I already have scripts to compile it into the dataformat needed to be
>> served.
>>
>> On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel >
>>> Hi all,
>>>
>>> The wiki page is indeed looking a whole lot better right now - my thanks
>>> and congrats to everyone who contributed! There is a still a ways to go,
>>> but we seem to be getting there quickly.
>>>
>>> I'll echo John in saying that I would appreciate hearing from some of
>>> the other people who chimed in to express their doubts about the import.
>>> For my part, I'm not satisfied yet - no surprise, I'm sure ;-). I'm
>>> thrilled that we're talking and working together in the open, and that
>>> addresses the biggest concern I had with the import.
>>>
>>> These are the big issues I see remaining:
>>>
>>> 1. *Validation*: Ideally I'd like to see a good chunk (more than half)
>>> of the data that has been imported already validated by another user before
>>> we proceed with importing more data. Validation is part of the import plan,
>>> so the import isn't done until validation is done anyway. My hope is that
>>> this will flag any issues that we can fix before moving forward, and give
>>> people time to chime in on the import plan who maybe haven't already. I
>>> don't want to see everything imported and only then do we start
>>> systematically checking the quality of our work, if ever. If no one wants
>>> to do it now, no one is going to want to do it later either, and that
>>> doesn't bode well.
>>>
>>> 2. *Simplification*: James' analysis showed that simplification could
>>> save several hundred megabytes (and probably more) in Ontario alone. This
>>> is totally worth doing, but we have to document the process and be very
>>> careful not to lose valuable data. I believe there was also a concern
>>> raised about orthogonal buildings being not quite orthogonal - this is
>>> something that we should handle at the same time, again, very carefully. We
>>> certainly don't want to coerce every building into right angles. With
>>> respect to James, I'm not sure this is something that can be done with a
>>> few clicks in QGIS. I would be willing to develop a script to handle this,
>>> but it would take me about a week or two to find the time to do this
>>> properly. We would need to simultaneously A) simplify straight lines B)
>>> orthogonalize where possible and C) preserve topology between connected
>>> buildings. This is not impossible, it just takes time and care to do
>>> correctly.
>>>
>>> 3. *Speed and Size*: To John's point, it seems like people certainly
>>> are not sticking to the areas they know, unless they get around a whole
>>> hell of a lot more than I do, and yes this is a problem. The whole Toronto
>>> region was basically imported by two people: DannyMcD seems to have done
>>> the entire west side of the region (hundreds of square kilometers) while
>>> zzptichka imported the entire east side of the region (again a truly
>>> massive area), both in the matter of a week or two. They only stopped in
>>> the middle where there were more buildings already and things got a bit
>>> more difficult. The middle is where I live, and when I saw that wave of
>>> buildings coming, I sounded the alarms.
>>> This is way too fast - no one person should be able to import the GTA in
>>> a couple weeks. A big part of the problem, IMO is that the task squares are
>>> much too large, and allow/require a user to import huge areas at once. At
>>> the least, some of the task squares in central Toronto are impossibly
>>> large, including

Re: [Talk-ca] Building Import update

Building count doesn't really have anything to do with preserving 
topology, and I'm not sure a visual inspection would cut it - Can you 
look at the documentation for this tool and verify that it preserves the 
topology of polygon layers?


This is a good illustration of the (potential) problem:
https://trac.osgeo.org/postgis/wiki/UsersWikiSimplifyPreserveTopology

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/26/19 12:31 PM, James wrote:
it does if you saw my analysis of building(polygon count) remains the 
same also visually inspected a few and there was preservation of them


On Sat., Jan. 26, 2019, 11:43 a.m. Nate Wessel  wrote:


Does that preserve topology between buildings that share nodes?

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com 

On 1/26/19 11:31 AM, James wrote:

no need for scripts, qgis does this fine via the  Vector menu ->
Geometry tools -> Simplify Geometries utility. I simplified it to
20cm with the , but I think 40cm is too aggressive.

I already have scripts to compile it into the dataformat needed
to be served.

On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel mailto:bike...@gmail.com> wrote:

Hi all,

The wiki page is indeed looking a whole lot better right now
- my thanks and congrats to everyone who contributed! There
is a still a ways to go, but we seem to be getting there
quickly.

I'll echo John in saying that I would appreciate hearing from
some of the other people who chimed in to express their
doubts about the import. For my part, I'm not satisfied yet -
no surprise, I'm sure ;-). I'm thrilled that we're talking
and working together in the open, and that addresses the
biggest concern I had with the import.

These are the big issues I see remaining:

1. *Validation*: Ideally I'd like to see a good chunk (more
than half) of the data that has been imported already
validated by another user before we proceed with importing
more data. Validation is part of the import plan, so the
import isn't done until validation is done anyway. My hope is
that this will flag any issues that we can fix before moving
forward, and give people time to chime in on the import plan
who maybe haven't already. I don't want to see everything
imported and only then do we start systematically checking
the quality of our work, if ever. If no one wants to do it
now, no one is going to want to do it later either, and that
doesn't bode well.

2. *Simplification*: James' analysis showed that
simplification could save several hundred megabytes (and
probably more) in Ontario alone. This is totally worth doing,
but we have to document the process and be very careful not
to lose valuable data. I believe there was also a concern
raised about orthogonal buildings being not quite orthogonal
- this is something that we should handle at the same time,
again, very carefully. We certainly don't want to coerce
every building into right angles. With respect to James, I'm
not sure this is something that can be done with a few clicks
in QGIS. I would be willing to develop a script to handle
this, but it would take me about a week or two to find the
time to do this properly. We would need to simultaneously A)
simplify straight lines B) orthogonalize where possible and
C) preserve topology between connected buildings. This is not
impossible, it just takes time and care to do correctly.

3. *Speed and Size*: To John's point, it seems like people
certainly are not sticking to the areas they know, unless
they get around a whole hell of a lot more than I do, and yes
this is a problem. The whole Toronto region was basically
imported by two people: DannyMcD seems to have done the
entire west side of the region (hundreds of square
kilometers) while zzptichka imported the entire east side of
the region (again a truly massive area), both in the matter
of a week or two. They only stopped in the middle where there
were more buildings already and things got a bit more
difficult. The middle is where I live, and when I saw that
wave of buildings coming, I sounded the alarms.
This is way too fast - no one person should be able to import
the GTA in a couple weeks. A big part of the problem, IMO is
that the task squares are much too large, and allow/require a
user to import huge areas at once. At the least, some of the
task squares in central Toronto are

Re: [Talk-ca] Building Import update

2019-01-26 Thread OSM Volunteer stevea

On Jan 26, 2019, at 8:42 AM, Nate Wessel  wrote:
Four absolutely OUTSTANDING aspects of this project which can (seemingly must) 
be addressed before the Task Manager releases these (or improved/simplified) 
data.

A salute to you, Nate, for these thoughtful words and their potential to very 
positively drive forward this import.

SteveA
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-01-26 Thread James

it does if you saw my analysis of building(polygon count) remains the same
also visually inspected a few and there was preservation of them

On Sat., Jan. 26, 2019, 11:43 a.m. Nate Wessel  Does that preserve topology between buildings that share nodes?
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/26/19 11:31 AM, James wrote:
>
> no need for scripts, qgis does this fine via the  Vector menu -> Geometry
> tools -> Simplify Geometries utility. I simplified it to 20cm with the ,
> but I think 40cm is too aggressive.
>
> I already have scripts to compile it into the dataformat needed to be
> served.
>
> On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel 
>> Hi all,
>>
>> The wiki page is indeed looking a whole lot better right now - my thanks
>> and congrats to everyone who contributed! There is a still a ways to go,
>> but we seem to be getting there quickly.
>>
>> I'll echo John in saying that I would appreciate hearing from some of the
>> other people who chimed in to express their doubts about the import. For my
>> part, I'm not satisfied yet - no surprise, I'm sure ;-). I'm thrilled that
>> we're talking and working together in the open, and that addresses the
>> biggest concern I had with the import.
>>
>> These are the big issues I see remaining:
>>
>> 1. *Validation*: Ideally I'd like to see a good chunk (more than half)
>> of the data that has been imported already validated by another user before
>> we proceed with importing more data. Validation is part of the import plan,
>> so the import isn't done until validation is done anyway. My hope is that
>> this will flag any issues that we can fix before moving forward, and give
>> people time to chime in on the import plan who maybe haven't already. I
>> don't want to see everything imported and only then do we start
>> systematically checking the quality of our work, if ever. If no one wants
>> to do it now, no one is going to want to do it later either, and that
>> doesn't bode well.
>>
>> 2. *Simplification*: James' analysis showed that simplification could
>> save several hundred megabytes (and probably more) in Ontario alone. This
>> is totally worth doing, but we have to document the process and be very
>> careful not to lose valuable data. I believe there was also a concern
>> raised about orthogonal buildings being not quite orthogonal - this is
>> something that we should handle at the same time, again, very carefully. We
>> certainly don't want to coerce every building into right angles. With
>> respect to James, I'm not sure this is something that can be done with a
>> few clicks in QGIS. I would be willing to develop a script to handle this,
>> but it would take me about a week or two to find the time to do this
>> properly. We would need to simultaneously A) simplify straight lines B)
>> orthogonalize where possible and C) preserve topology between connected
>> buildings. This is not impossible, it just takes time and care to do
>> correctly.
>>
>> 3. *Speed and Size*: To John's point, it seems like people certainly are
>> not sticking to the areas they know, unless they get around a whole hell of
>> a lot more than I do, and yes this is a problem. The whole Toronto region
>> was basically imported by two people: DannyMcD seems to have done the
>> entire west side of the region (hundreds of square kilometers) while
>> zzptichka imported the entire east side of the region (again a truly
>> massive area), both in the matter of a week or two. They only stopped in
>> the middle where there were more buildings already and things got a bit
>> more difficult. The middle is where I live, and when I saw that wave of
>> buildings coming, I sounded the alarms.
>> This is way too fast - no one person should be able to import the GTA in
>> a couple weeks. A big part of the problem, IMO is that the task squares are
>> much too large, and allow/require a user to import huge areas at once. At
>> the least, some of the task squares in central Toronto are impossibly
>> large, including hundreds or thousands of buildings already mapped in OSM.
>> Conflation on these, if done properly would take the better part of a day,
>> and people are likely to get sloppy.
>> I would like to see the task squares dramatically reduced in size as a
>> way of slowing people down, helping them stick to areas they know well, and
>> keeping them focused on data quality over quantity. This would also make
>> the process much more accessible to local mappers who don't already have
>> tons of experience importing.
>>
>> 4. *Conflation*: I don't think the current conflation plan is
>> adequate(ly documented). In practice, what people are actually doing may be
>> fine, but I really want to see some better thought on how to handle
>> existing buildings. Right now the wiki says for example "*Before merging
>> buildings data switch to OSM layer and see if there are any clusters of
>> buildings

Re: [Talk-ca] Building Import update


Does that preserve topology between buildings that share nodes?

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/26/19 11:31 AM, James wrote:
no need for scripts, qgis does this fine via the Vector menu -> 
Geometry tools -> Simplify Geometries utility. I simplified it to 20cm 
with the , but I think 40cm is too aggressive.


I already have scripts to compile it into the dataformat needed to be 
served.


On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel  wrote:


Hi all,

The wiki page is indeed looking a whole lot better right now - my
thanks and congrats to everyone who contributed! There is a still
a ways to go, but we seem to be getting there quickly.

I'll echo John in saying that I would appreciate hearing from some
of the other people who chimed in to express their doubts about
the import. For my part, I'm not satisfied yet - no surprise, I'm
sure ;-). I'm thrilled that we're talking and working together in
the open, and that addresses the biggest concern I had with the
import.

These are the big issues I see remaining:

1. *Validation*: Ideally I'd like to see a good chunk (more than
half) of the data that has been imported already validated by
another user before we proceed with importing more data.
Validation is part of the import plan, so the import isn't done
until validation is done anyway. My hope is that this will flag
any issues that we can fix before moving forward, and give people
time to chime in on the import plan who maybe haven't already. I
don't want to see everything imported and only then do we start
systematically checking the quality of our work, if ever. If no
one wants to do it now, no one is going to want to do it later
either, and that doesn't bode well.

2. *Simplification*: James' analysis showed that simplification
could save several hundred megabytes (and probably more) in
Ontario alone. This is totally worth doing, but we have to
document the process and be very careful not to lose valuable
data. I believe there was also a concern raised about orthogonal
buildings being not quite orthogonal - this is something that we
should handle at the same time, again, very carefully. We
certainly don't want to coerce every building into right angles.
With respect to James, I'm not sure this is something that can be
done with a few clicks in QGIS. I would be willing to develop a
script to handle this, but it would take me about a week or two to
find the time to do this properly. We would need to simultaneously
A) simplify straight lines B) orthogonalize where possible and C)
preserve topology between connected buildings. This is not
impossible, it just takes time and care to do correctly.

3. *Speed and Size*: To John's point, it seems like people
certainly are not sticking to the areas they know, unless they get
around a whole hell of a lot more than I do, and yes this is a
problem. The whole Toronto region was basically imported by two
people: DannyMcD seems to have done the entire west side of the
region (hundreds of square kilometers) while zzptichka imported
the entire east side of the region (again a truly massive area),
both in the matter of a week or two. They only stopped in the
middle where there were more buildings already and things got a
bit more difficult. The middle is where I live, and when I saw
that wave of buildings coming, I sounded the alarms.
This is way too fast - no one person should be able to import the
GTA in a couple weeks. A big part of the problem, IMO is that the
task squares are much too large, and allow/require a user to
import huge areas at once. At the least, some of the task squares
in central Toronto are impossibly large, including hundreds or
thousands of buildings already mapped in OSM. Conflation on these,
if done properly would take the better part of a day, and people
are likely to get sloppy.
I would like to see the task squares dramatically reduced in size
as a way of slowing people down, helping them stick to areas they
know well, and keeping them focused on data quality over quantity.
This would also make the process much more accessible to local
mappers who don't already have tons of experience importing.

4. *Conflation*: I don't think the current conflation plan is
adequate(ly documented). In practice, what people are actually
doing may be fine, but I really want to see some better thought on
how to handle existing buildings. Right now the wiki says for
example "/Before merging buildings data switch to OSM layer and
see if there are any clusters of buildings without any meaningful
tags you can delete to save time when merging/."
With respect to whoever wrote

Re: [Talk-ca] Building Import update

2019-01-26 Thread James

no need for scripts, qgis does this fine via the  Vector menu -> Geometry
tools -> Simplify Geometries utility. I simplified it to 20cm with the ,
but I think 40cm is too aggressive.

I already have scripts to compile it into the dataformat needed to be
served.

On Sat., Jan. 26, 2019, 11:16 a.m. Nate Wessel  Hi all,
>
> The wiki page is indeed looking a whole lot better right now - my thanks
> and congrats to everyone who contributed! There is a still a ways to go,
> but we seem to be getting there quickly.
>
> I'll echo John in saying that I would appreciate hearing from some of the
> other people who chimed in to express their doubts about the import. For my
> part, I'm not satisfied yet - no surprise, I'm sure ;-). I'm thrilled that
> we're talking and working together in the open, and that addresses the
> biggest concern I had with the import.
>
> These are the big issues I see remaining:
>
> 1. *Validation*: Ideally I'd like to see a good chunk (more than half) of
> the data that has been imported already validated by another user before we
> proceed with importing more data. Validation is part of the import plan, so
> the import isn't done until validation is done anyway. My hope is that this
> will flag any issues that we can fix before moving forward, and give people
> time to chime in on the import plan who maybe haven't already. I don't want
> to see everything imported and only then do we start systematically
> checking the quality of our work, if ever. If no one wants to do it now, no
> one is going to want to do it later either, and that doesn't bode well.
>
> 2. *Simplification*: James' analysis showed that simplification could
> save several hundred megabytes (and probably more) in Ontario alone. This
> is totally worth doing, but we have to document the process and be very
> careful not to lose valuable data. I believe there was also a concern
> raised about orthogonal buildings being not quite orthogonal - this is
> something that we should handle at the same time, again, very carefully. We
> certainly don't want to coerce every building into right angles. With
> respect to James, I'm not sure this is something that can be done with a
> few clicks in QGIS. I would be willing to develop a script to handle this,
> but it would take me about a week or two to find the time to do this
> properly. We would need to simultaneously A) simplify straight lines B)
> orthogonalize where possible and C) preserve topology between connected
> buildings. This is not impossible, it just takes time and care to do
> correctly.
>
> 3. *Speed and Size*: To John's point, it seems like people certainly are
> not sticking to the areas they know, unless they get around a whole hell of
> a lot more than I do, and yes this is a problem. The whole Toronto region
> was basically imported by two people: DannyMcD seems to have done the
> entire west side of the region (hundreds of square kilometers) while
> zzptichka imported the entire east side of the region (again a truly
> massive area), both in the matter of a week or two. They only stopped in
> the middle where there were more buildings already and things got a bit
> more difficult. The middle is where I live, and when I saw that wave of
> buildings coming, I sounded the alarms.
> This is way too fast - no one person should be able to import the GTA in a
> couple weeks. A big part of the problem, IMO is that the task squares are
> much too large, and allow/require a user to import huge areas at once. At
> the least, some of the task squares in central Toronto are impossibly
> large, including hundreds or thousands of buildings already mapped in OSM.
> Conflation on these, if done properly would take the better part of a day,
> and people are likely to get sloppy.
> I would like to see the task squares dramatically reduced in size as a way
> of slowing people down, helping them stick to areas they know well, and
> keeping them focused on data quality over quantity. This would also make
> the process much more accessible to local mappers who don't already have
> tons of experience importing.
>
> 4. *Conflation*: I don't think the current conflation plan is adequate(ly
> documented). In practice, what people are actually doing may be fine, but I
> really want to see some better thought on how to handle existing buildings.
> Right now the wiki says for example "*Before merging buildings data
> switch to OSM layer and see if there are any clusters of buildings without
> any meaningful tags you can delete to save time when merging*."
> With respect to whoever wrote this, this approach seems to value time over
> data integrity and I just don't think that's how OSM should operate. We
> need to be more careful with the existing data, and we need to show that
> care with clear and acceptable guidelines for handling the data that
> countless people have already spent their time contributing. We don't do
> OSM any favours by carelessly deleting and replacing data. Help

Re: [Talk-ca] Building Import update