So are we happy with Yaro's suggestions? Or perhaps I should rephrase that can we live with them?
On the task manager square size I take it these have been split and split again? Thanks John On Mon, 4 Feb 2019 at 18:08, Yaro Shkvorets <shkvor...@gmail.com> wrote: > 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 <jwhelan0...@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 <jwhelan0...@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 <pierz...@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 < >>>> 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 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 >> > > > -- > Best Regards, > Yaro Shkvorets >
_______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-ca
