[Talk-ca] Building Import update

Mon Feb 4 23:08:38 UTC 2019

Briefly, here are my thoughts.
1) *Simplification*, i.e. removing nodes in the middle of a straight line.
We should be able to apply this fix to the original data. Looks like James
has done it a couple of weeks ago, so we can try take this data and go with
it if there are no objections.
2) *Almost square angles*. Simple squaring in JOSM (Q) is a non-starter as
it ruins geometries. Looks like we found a way to do it using JOSM
Validator (this thread:
https://lists.openstreetmap.org/pipermail/talk-ca/2019-February/009099.html).
I think it should work. I don't like preprocessing data for this step since
there would be no way to go back if the algorithm makes a mistake. Besides,
I don't think we were able to find a working script to do it to begin with.
3) Preserving *building history*. I agree we should absolutely try to
preserve the history whenever possible. "Replace geometry" (Ctrl-Shift-G)
is the way to go here. For the record, here's what I meant when I was
writing about possibility of deleting clusters of low quality generic
buildings (there exist far worse than that): https://i.imgur.com/CNfDjvw.png
If we want to preserve history for these buildings as well - fine by me.
4) *Import data quality vs existing OSM quality*. If there is any
difference it should be addressed on a case-by-case basis by a person doing
the import. Checking building history, imagery, etc. From my experience in
Toronto East, import data is almost always more recent and has better
details. IMO in the end we should try to replace geometries in most cases.
5) Secondary bulidings that are not in the dataset (*sheds, garages*). We
should leave those to local mappers. Import should only be about importing
data from the dataset.
6) *Square sizes*. I agree, in the high density Toronto core current
squares are indeed too big. However, creating new smaller project at this
point would make things quite complicated along the edges since we would
have to deal with already imported data. I would prefer to finish Ontario
project the way it is right now. If a square turns out to be too massive,
the person doing the import will need to tackle that square in several
changesets.

On Sun, Feb 3, 2019 at 7:06 PM john whelan <jwhelan0112 at gmail.com> wrote:

> 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 <jwhelan0112 at gmail.com> 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 <pierzenh at yahoo.fr> 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 <
>>> jwhelan0112 at 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 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 at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>

-- 
Best Regards,
          Yaro Shkvorets
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20190204/754a2091/attachment-0001.html>