Re: [Talk-ca] Some feedback on import quality in Toronto

[OSM Volunteer stevea]

It is an honor to participate in this good growth.  May good 
(province-at-a-time building) data enter OSM at the hands of skilled OSM 
editors who have good instructions on "how" (the Import Plan can go that 
distance, please finish it) as their skills of good editing OSM data push the 
import ahead.  Speaking for myself, I like what I see here:  a community 
speaking amongst itself/ourselves.

Should "tall enough to ride the ride" volunteers "step right up" I think the 
current red flags can go to yellow, then green.  Nate, Yaro, Pierre, Blake, 
Nate, John, Danny, so many others here unnamed have shown leadership.  Many 
Canadians seem on the road to "how" and "talk amongst yourselves."  Good is not 
the enemy.  Good are good enough as they are included with "how."  Thumbs up 
from here ahead.  I keep trying to be outta here.

Et, voilá.

SteveA
> 


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

Re: [Talk-ca] Some feedback on import quality in Toronto

[Danny McDonald]

I largely agree with Yaro, but will say
1) It is possible to square almost square angles with JOSM - it has an
informational warning in validation, and automatically squares the angle by
slightly moving the offending node.  This fix doesn't ruin the geometry of
the building, as pressing Q so often does.  Unfortunately, it also leads to
other angles in the building not being square.
3) I'm fine with importing smaller buildings as well (they don't seem to be
in the source data in Toronto, they are for some of the other data sets).
I believe they were excluded because of their relatively low
importance/permanence.

I would also like to know how the Toronto building footprints were
produced.  Does anyone know?
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[john whelan]

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] Some feedback on import quality in Toronto

[Yaro Shkvorets]

Having reviewed the changeset, here are my 2 cents. OsmCha link for
reference: https://osmcha.mapbox.com/changesets/66881357/

1) IMO squaring is not needed in most of those cases.
- You can see difference between square and non-square ONLY at high zoom
level. And even then, it's not visible to the naked eye. We are talking
about inches here.
- Sometimes squaring is plain wrong to be applied here. Even though you
paid very close attention you managed to square a couple of non-square
buildings. Like this facade is not supposed to be square for example:
https://i.imgur.com/H10360K.png I might be OK with squaring almost-square
angles if there is a simple plugin for that. The way you propose to do it,
by going building-by-building and pressing Q is completely unsustainable
and sometimes makes things bad.
- Another thing, this particular neighbourhood is pretty dense and mature
and therefore has mostly square buildings. I can only imagine how bad it
would become if you ask people to square things in newer developments where
buildings often come in irregular shapes.
- Like mentioned above, many successful import didn't require squaring. In
this Texas one, 100% of buildings are not perfectly square:
https://www.openstreetmap.org/#map=19/32.97102/-96.78231


2) Simplification is good to have, sure. Obviously standard Shift-Y in JOSM
is a no-starter. If we can find a good way to simplify ways without losing
original geometry and causing overlapping issues we should do it. But even
then, reducing 500MB province extract to 499MB should not be a hill to die
on.

3) Manually mapping all the sheds and garages is completely unsustainable.
Having seen over the last couple of years how much real interest there is
in doing actual work importing buildings in Canada (almost zero) adding
this requirement will undoubtedly kill the project. Sure you will
meticulously map your own neighbourhood, but who will map thousands of
other places with the same attention to details? Also, you did rather poor
job at classifying buildings you add, tagging them all with building=yes.
Properly classifying secondary buildings like sheds and garages in a
project like this is pretty important IMO. I agree with John, we should
leave sheds to local mappers to trace manually.

To sum up, yes we can do better. But this is the perfect example when
"better" is the enemy of "good".

On Sun, Feb 3, 2019 at 12:34 PM Nate Wessel  wrote:

> Hi all,
>
> I had a chance this morning to work on cleaning up some of the
> already-imported data in Toronto. I wanted to be a little methodical about
> this, so I picked a single typical block near where I live. All the
> building data on this block came from the import and I did everything in
> one changeset: https://www.openstreetmap.org/changeset/66881357
>
> What I found was that:
>
> 1) Every single building needed squaring
>
> 2) Most buildings needed at least some simplification.
>
> 3) 42 buildings were missing.
>
> I knew going in that the first two would be an issue, but what really
> surprised me was just how many sheds had not been imported. There are only
> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
> quite large, and none of which had been mapped.
>
> I haven't seen the quality of the outbuildings in the source data, and
> maybe I would change my mind if I did, but I think if we're going to do
> this import properly, we're going to have to bring in the other half of the
> data. I had seen in the original import instructions that small buildings
> were being excluded - was there a reason for this?
>
> I also want to say: given how long it took me to clean up and properly
> remap this one block, I'll say again that the size of the import tasks is
> way, way, way too large. There is absolutely no way that someone could have
> carefully looked at and verified this data as it was going in. I just spent
> a half hour fixing up probably about one-hundredth of a task square.
>
> We can do better than this!
> --
> 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
>


-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

[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

[john whelan]

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

[Pierre Béland via Talk-ca]

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

[john whelan]

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

[Pierre Béland via Talk-ca]

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

[john whelan]

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

[john whelan]

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

[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

[Pierre Béland via Talk-ca]

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] Some feedback on import quality in Toronto

[OSM Volunteer stevea]

Mmm, careful with your language, John.  The data "have a license which is 
compatible with OSM's ODbL" (is an accurate way to say it).  I believe that 
took about eight years and was a difficult slog, a lot of hard work by many, 
lessons learned from Ottawa, a determination by OSM's LWG, but it is done.  (I 
am grateful for that, it is an important milestone).

A different issue is whether the data and their concomitant quality "are 
acceptable" to the OSM community.  The license being ODbL compatible is not 
that; these are different issues.  We now discuss data quality (and what to do 
to improve them, if anything) here in talk-ca and in the mildly-being-updated 
Import Plan, with experiences of what Yaro, Danny and Nate have done in Toronto.

It is not the case, as John says, that "the data (are) licensed to be 
acceptable to (OSM)."  The concept of "acceptability" is not related to the 
data being licensed compatible with ODbL.

What often/usually happens is an Import Plan gets wide vetting and acceptance 
by the OSM community before data become imported, including 
suitability/acceptability of the quality of the data.  What happened here is 
the Import Plan was attempted to be widely vetted, but this seems to have been 
largely ignored or little-paid-attention-to.  While the Plan's initial 
shortcomings were pointed out, yet not remedied, the Import began, then the 
community began to react (with some complaint and some "what Yaro does seems 
OK").  Yaro (and Nate, I believe) then updated the Import Plan with Yaro's 
specific technical steps.

Still, complaints and/or disagreements about simplification, squaring and 
potentially other issues continue.  (As two asides, I'll say that MANY 
buildings are not necessarily "square" — like buildings with bay windows — and 
that truly square/rectangular buildings should express this with a tagged 
way/closed polygon made up of exactly four nodes).

As these discussions continue, eventually what will emerge is "how do we 
(algorithmically, manually...) change the data, whether pre-import or 
during-import, so that they achieve wide acceptance as to their quality by the 
community."  We're getting closer, it seems to me, but I don't think we're 
there yet.

Nobody seems to be arguing there is or isn't a "desire to bring in the 
buildings by many" or to "use them for many purposes."  That point seems 
"decided."  The questions remain:  "how, with the existing data?"  Once those 
are determined (and documented in the Import Plan), over time, the data will 
(or will not) be imported.  I wish to offer encouragement to this process, it 
does appear to continue here and can likely bear fruit in the near future.  
Keep going!  Consensus is ahead!

SteveA

On Feb 3, 2019, at 10:55 AM, john whelan  wrote:
> So I suggest that you name yourself as the coordinator on the wiki page for 
> Toronto that allows the local mappers in Toronto to import at the rate and to 
> the standard you suggest.
> 
> For the rest of the country the data is licensed to be acceptable to 
> OpenStreetMap thus anyone can set up their own import plan and import it even 
> if this import is abandoned.  I'd like to see this voiced as the general 
> desire though on talk-ca before it happens as it was a talk-ca decision to 
> proceed.
> 
> My reading of the posts on talk-ca is that there is a desire to bring in the 
> buildings by many.  There is also a desire by many to use them for many 
> purposes.
> 
> Cheerio John
> 
> On Sun, Feb 3, 2019, 1:42 PM Nate Wessel  John, 
> You seem to be mostly addressing topics which have been brought up elsewhere. 
> My email was meant to address specific data quality issues in Toronto, so I'm 
> not sure how to respond to all of this. 
> To your broader question though, my position is that we *do* have the 
> volunteers and skills necessary to make this a good import. Supposing that we 
> didn't though, then I would have to say that the import should wait until we 
> have the right people working on it. A bad import is worse than no import.
> 
> Cheers,
> 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

[Pierre Béland via Talk-ca]

 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] Some feedback on import quality in Toronto

[john whelan]

So I suggest that you name yourself as the coordinator on the wiki page for
Toronto that allows the local mappers in Toronto to import at the rate and
to the standard you suggest.

For the rest of the country the data is licensed to be acceptable to
OpenStreetMap thus anyone can set up their own import plan and import it
even if this import is abandoned.  I'd like to see this voiced as the
general desire though on talk-ca before it happens as it was a talk-ca
decision to proceed.

My reading of the posts on talk-ca is that there is a desire to bring in
the buildings by many.  There is also a desire by many to use them for many
purposes.

Cheerio John

On Sun, Feb 3, 2019, 1:42 PM Nate Wessel  John,
>
> You seem to be mostly addressing topics which have been brought up
> elsewhere. My email was meant to address specific data quality issues in
> Toronto, so I'm not sure how to respond to all of this.
>
> To your broader question though, my position is that we *do* have the
> volunteers and skills necessary to make this a good import. Supposing that
> we didn't though, then I would have to say that the import should wait
> until we have the right people working on it. A bad import is worse than no
> import.
>
> Cheers,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 2/3/19 1:14 PM, john whelan wrote:
>
> My expectation was that the import would be based on the city's records of
> foundations for the buildings.
>
> I would not expect to see sheds etc.and I'd be quite happy to only get
> most of the buildings. The rest can be added by local mappers at a later
> date.
>
> My expectation is they will be consistent and not some mapped from Bing,
> others from ESRI etc.
>
> There are estimated to be in excess of 11,000,000 buildings in Canada.  I
> don't think we have enough skilled mappers to map them all from imagery.
>
> My expectation is the import would give us a reasonable number of fairly
> accurate building outlines at relatively low cost in mapper time.  Missing
> building imports from city open data are now fairly common in many parts of
> the world.
>
> My expectation is that the building outlines would have additional tags
> added and that this would draw in less skilled mappers.  At the same time
> corrections could be made to the outlines if deemed necessary.
>
> It would avoid too many badly mapped buildings.
>
> Before the import started it was raised in talk-ca and there was some
> discussion.  I understand you were not a member at that time or took part
> in that discussion but that doesn't change the fact that the issue was
> discussed.
>
> The idea of a single import plan came from talk-ca and that is why there
> is a single import plan covering the entire country and there was
> discussion on talk-ca on the point.
>
> The original plan on the wiki mentioned having some coordination in an
> area.  I don't think this happened but it was an attempt to give a louder
> local voice as it was recognised it would be better if local mappers took
> the lead.
>
> Different mappers have different ideas of what is acceptable.  I think
> your standards are fairly high thus more demanding in resources and do we
> have enough resources?  I don't think we do to import to the standard at
> which you are asking.
>
> Could you clarify what you are saying?
>
> I assume that for other parts of the country if they wish to continue and
> find the building outlines acceptable they may do so?
>
> Thanks John
>
> Thanks John
>
>
>
> On Sun, 3 Feb 2019 at 12:34, Nate Wessel  wrote:
>
>> Hi all,
>>
>> I had a chance this morning to work on cleaning up some of the
>> already-imported data in Toronto. I wanted to be a little methodical about
>> this, so I picked a single typical block near where I live. All the
>> building data on this block came from the import and I did everything in
>> one changeset: https://www.openstreetmap.org/changeset/66881357
>>
>> What I found was that:
>>
>> 1) Every single building needed squaring
>>
>> 2) Most buildings needed at least some simplification.
>>
>> 3) 42 buildings were missing.
>>
>> I knew going in that the first two would be an issue, but what really
>> surprised me was just how many sheds had not been imported. There are only
>> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
>> quite large, and none of which had been mapped.
>>
>> I haven't seen the quality of the outbuildings in the source data, and
>> maybe I would change my mind if I did, but I think if we're going to do
>> this import properly, we're going to have to bring in the other half of the
>> data. I had seen in the original import instructions that small buildings
>> were being excluded - was there a reason for this?
>>
>> I also want to say: given how long it took me to clean up and properly
>> remap this one block, I'll say again that the size of the import tasks is
>> way, way, way too large. There 

Re: [Talk-ca] Some feedback on import quality in Toronto

[Nate Wessel]

John,

You seem to be mostly addressing topics which have been brought up 
elsewhere. My email was meant to address specific data quality issues in 
Toronto, so I'm not sure how to respond to all of this.


To your broader question though, my position is that we *do* have the 
volunteers and skills necessary to make this a good import. Supposing 
that we didn't though, then I would have to say that the import should 
wait until we have the right people working on it. A bad import is worse 
than no import.


Cheers,

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

On 2/3/19 1:14 PM, john whelan wrote:
My expectation was that the import would be based on the city's 
records of foundations for the buildings.


I would not expect to see sheds etc.and I'd be quite happy to only get 
most of the buildings. The rest can be added by local mappers at a 
later date.


My expectation is they will be consistent and not some mapped from 
Bing, others from ESRI etc.


There are estimated to be in excess of 11,000,000 buildings in 
Canada.  I don't think we have enough skilled mappers to map them all 
from imagery.


My expectation is the import would give us a reasonable number of 
fairly accurate building outlines at relatively low cost in mapper 
time.  Missing building imports from city open data are now fairly 
common in many parts of the world.


My expectation is that the building outlines would have additional 
tags added and that this would draw in less skilled mappers.  At the 
same time corrections could be made to the outlines if deemed necessary.


It would avoid too many badly mapped buildings.

Before the import started it was raised in talk-ca and there was some 
discussion.  I understand you were not a member at that time or took 
part in that discussion but that doesn't change the fact that the 
issue was discussed.


The idea of a single import plan came from talk-ca and that is why 
there is a single import plan covering the entire country and there 
was discussion on talk-ca on the point.


The original plan on the wiki mentioned having some coordination in an 
area.  I don't think this happened but it was an attempt to give a 
louder local voice as it was recognised it would be better if local 
mappers took the lead.


Different mappers have different ideas of what is acceptable.  I think 
your standards are fairly high thus more demanding in resources and do 
we have enough resources?  I don't think we do to import to the 
standard at which you are asking.


Could you clarify what you are saying?

I assume that for other parts of the country if they wish to continue 
and find the building outlines acceptable they may do so?


Thanks John

Thanks John



On Sun, 3 Feb 2019 at 12:34, Nate Wessel > wrote:


Hi all,

I had a chance this morning to work on cleaning up some of the
already-imported data in Toronto. I wanted to be a little
methodical about this, so I picked a single typical block near
where I live. All the building data on this block came from the
import and I did everything in one changeset:
https://www.openstreetmap.org/changeset/66881357

What I found was that:

1) Every single building needed squaring

2) Most buildings needed at least some simplification.

3) 42 buildings were missing.

I knew going in that the first two would be an issue, but what
really surprised me was just how many sheds had not been imported.
There are only 53 houses on the block, but 42
sheds/garages/outbuildings, some of them quite large, and none of
which had been mapped.

I haven't seen the quality of the outbuildings in the source data,
and maybe I would change my mind if I did, but I think if we're
going to do this import properly, we're going to have to bring in
the other half of the data. I had seen in the original import
instructions that small buildings were being excluded - was there
a reason for this?

I also want to say: given how long it took me to clean up and
properly remap this one block, I'll say again that the size of the
import tasks is way, way, way too large. There is absolutely no
way that someone could have carefully looked at and verified this
data as it was going in. I just spent a half hour fixing up
probably about one-hundredth of a task square.

We can do better than this!

-- 
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] Some feedback on import quality in Toronto

[john whelan]

My expectation was that the import would be based on the city's records of
foundations for the buildings.

I would not expect to see sheds etc.and I'd be quite happy to only get most
of the buildings. The rest can be added by local mappers at a later date.

My expectation is they will be consistent and not some mapped from Bing,
others from ESRI etc.

There are estimated to be in excess of 11,000,000 buildings in Canada.  I
don't think we have enough skilled mappers to map them all from imagery.

My expectation is the import would give us a reasonable number of fairly
accurate building outlines at relatively low cost in mapper time.  Missing
building imports from city open data are now fairly common in many parts of
the world.

My expectation is that the building outlines would have additional tags
added and that this would draw in less skilled mappers.  At the same time
corrections could be made to the outlines if deemed necessary.

It would avoid too many badly mapped buildings.

Before the import started it was raised in talk-ca and there was some
discussion.  I understand you were not a member at that time or took part
in that discussion but that doesn't change the fact that the issue was
discussed.

The idea of a single import plan came from talk-ca and that is why there is
a single import plan covering the entire country and there was discussion
on talk-ca on the point.

The original plan on the wiki mentioned having some coordination in an
area.  I don't think this happened but it was an attempt to give a louder
local voice as it was recognised it would be better if local mappers took
the lead.

Different mappers have different ideas of what is acceptable.  I think your
standards are fairly high thus more demanding in resources and do we have
enough resources?  I don't think we do to import to the standard at which
you are asking.

Could you clarify what you are saying?

I assume that for other parts of the country if they wish to continue and
find the building outlines acceptable they may do so?

Thanks John

Thanks John



On Sun, 3 Feb 2019 at 12:34, Nate Wessel  wrote:

> Hi all,
>
> I had a chance this morning to work on cleaning up some of the
> already-imported data in Toronto. I wanted to be a little methodical about
> this, so I picked a single typical block near where I live. All the
> building data on this block came from the import and I did everything in
> one changeset: https://www.openstreetmap.org/changeset/66881357
>
> What I found was that:
>
> 1) Every single building needed squaring
>
> 2) Most buildings needed at least some simplification.
>
> 3) 42 buildings were missing.
>
> I knew going in that the first two would be an issue, but what really
> surprised me was just how many sheds had not been imported. There are only
> 53 houses on the block, but 42 sheds/garages/outbuildings, some of them
> quite large, and none of which had been mapped.
>
> I haven't seen the quality of the outbuildings in the source data, and
> maybe I would change my mind if I did, but I think if we're going to do
> this import properly, we're going to have to bring in the other half of the
> data. I had seen in the original import instructions that small buildings
> were being excluded - was there a reason for this?
>
> I also want to say: given how long it took me to clean up and properly
> remap this one block, I'll say again that the size of the import tasks is
> way, way, way too large. There is absolutely no way that someone could have
> carefully looked at and verified this data as it was going in. I just spent
> a half hour fixing up probably about one-hundredth of a task square.
>
> We can do better than this!
> --
> 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

[Talk-ca] Some feedback on import quality in Toronto

[Nate Wessel]

Hi all,

I had a chance this morning to work on cleaning up some of the 
already-imported data in Toronto. I wanted to be a little methodical 
about this, so I picked a single typical block near where I live. All 
the building data on this block came from the import and I did 
everything in one changeset: 
https://www.openstreetmap.org/changeset/66881357


What I found was that:

1) Every single building needed squaring

2) Most buildings needed at least some simplification.

3) 42 buildings were missing.

I knew going in that the first two would be an issue, but what really 
surprised me was just how many sheds had not been imported. There are 
only 53 houses on the block, but 42 sheds/garages/outbuildings, some of 
them quite large, and none of which had been mapped.


I haven't seen the quality of the outbuildings in the source data, and 
maybe I would change my mind if I did, but I think if we're going to do 
this import properly, we're going to have to bring in the other half of 
the data. I had seen in the original import instructions that small 
buildings were being excluded - was there a reason for this?


I also want to say: given how long it took me to clean up and properly 
remap this one block, I'll say again that the size of the import tasks 
is way, way, way too large. There is absolutely no way that someone 
could have carefully looked at and verified this data as it was going 
in. I just spent a half hour fixing up probably about one-hundredth of a 
task square.


We can do better than this!

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

[john whelan]

>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] hebdoOSM Nº 445 2019-01-22-2019-01-28

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 445 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/11447/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] weeklyOSM #445 2019-01-22-2019-01-28

[weeklyteam]

The weekly round-up of OSM news, issue # 445,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/11447/

Enjoy!

weeklyOSM? 
who: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca