Re: [Talk-ca] Building Import update

[john whelan]

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

Re: [Talk-ca] Building Import update

[Yaro Shkvorets]

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

Re: [Talk-ca] Building Import update

[Begin Daniel]

La discussion en cours va dans la bonne direction, il est nécessaire de 
prétraiter correctement les données avant de les mettre à la disposition du 
gestionnaire de tâches OSM. Nous devons (simplement !-) nous entendre sur ce 
qui doit être fait.
La partie qui m’inquiète est la seconde étape du processus d’importation.
Premièrement, la discussion actuelle semble parfois supposer que les données à 
importer sont plus actuelles/meilleures que la couche OSM. Dans une version 
précédente du wiki (processus d’importation), il était même suggéré de 
supprimer les grappes d’anciens bâtiments (building=yes) et de les remplacer 
par les nouvelles données pour accélérer le processus, sans vérifier si les 
données sont valides?
Ce qui m’amène à ma deuxième préoccupation. Je trouve irrespectueux de 
supprimer le travail des contributeurs précédents simplement pour importer plus 
rapidement de nouvelles données. Procéder de cette façon risque de décourager 
tous ceux qui verront leurs contributions ‘imparfaites’ détruites et remplacées 
par cet import. OSM est aussi une communauté.

Daniel

PS. Google translate makes a good translation of this text.

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Sunday, February 03, 2019 19:05
To: Pierre Béland
Cc: Talk-CA OpenStreetMap
Subject: Re: [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 
mailto: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 
mailto: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 

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

[Pierre Béland via Talk-ca]

J'ai constaté la même chose a tester CATools. Décevant.

Et merci à Dany, cette fonctionnalité est intéressante.La requête Overpass 
ci-dessous extrait de grands immeubles à Ottawa, certains avec des formes 
rectangulaires, d'autres avec des formes plus complexes, moitié rectangulaire, 
plus divers angles.http://overpass-turbo.eu/s/FNY

Ce qui manque pour corriger de telles géométrie, c'est un outil qui permettrait 
de redresser partiellement, de mettre en parallèle certains cotes, ou redresser 
un angle à 90 degrés, voire 60, 45 a un certain point.  

Pour les demi-cercles, on sélectionne  3 points et outil / Arc de cercle.
 
Pierre 
 

Le lundi 4 février 2019 10 h 50 min 02 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Thanks, it works. Need to run it a few times it looks like. On a random 
Markham block went from 88 warnings down to 4 without ruining geometries, which 
is acceptable IMO. May need to look into its parameters 
(validator.RightAngleBuilding.maximumDelta and 
validator.RightAngleBuilding.minimumDelta) to tweak it for our data.
I've looked into CADTools and BuildingGeneralization plugins but unfortunately 
they don't work properly destroying geometries and rotating polygons.
-- 
Best Regards,
          Yaro Shkvorets  ___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] New MapRoulette challenge to address highway class flip-flops

[Martijn van Exel]

Harald — you can go into your User profile and change the Default Editor 
setting to ‘Edit just features in JOSM’. This will load just the ‘abnormal’ 
highway. You can then load more data around if if needed. If you don’t want to 
change the setting globally you can use keyboard shortcut ‘y’ to trigger this 
type of loading in JOSM on a task by task basis.

Hope this helps, 
Martijn

> On Feb 4, 2019, at 9:44 AM, Harald Kliems  wrote:
> 
> Hi Martijn:
> I just tried the challenge, and all of the first four tasks that came up 
> produce an "area too big" error in JOSM (long highways in very rural areas). 
> Is there any way to fix this? Or maybe warn people to not use JOSM for this 
> challenge?
>  Harald.
> 
> On Mon, Feb 4, 2019 at 10:37 AM Martijn van Exel  > wrote:
> Hi all, 
> 
> Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette 
> challenge for ‘highway class flip-flops’. What does this mean? Consecutive 
> ways that have a suspicious change from one highway= value to another and 
> then back to the former. This happens sometimes when mappers change the 
> highway= value for some way but miss a bridge somewhere. An example is 
> https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 
>  where 
> the bridge is marked as residential but the two adjoining ways are marked as 
> unclassified.
> 
> You can find the challenge at https://maproulette.org/mr3/challenge/3588 
>  and your feedback is very 
> welcome.There are ~300 tasks.
> 
> If you have other ideas for challenges to clean up / review existing data let 
> me know and we can discuss.
> 
> Martijn
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-ca 
> 
> 
> 
> -- 
> Please use encrypted communication whenever possible!
> Key-ID: 0x34cb93972f186565

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

Re: [Talk-ca] New MapRoulette challenge to address highway class flip-flops

[Harald Kliems]

Hi Martijn:
I just tried the challenge, and all of the first four tasks that came up
produce an "area too big" error in JOSM (long highways in very rural
areas). Is there any way to fix this? Or maybe warn people to not use JOSM
for this challenge?
 Harald.

On Mon, Feb 4, 2019 at 10:37 AM Martijn van Exel  wrote:

> Hi all,
>
> Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette
> challenge for ‘highway class flip-flops’. What does this mean? Consecutive
> ways that have a suspicious change from one highway= value to another and
> then back to the former. This happens sometimes when mappers change the
> highway= value for some way but miss a bridge somewhere. An example is
> https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 where
> the bridge is marked as residential but the two adjoining ways are marked
> as unclassified.
>
> You can find the challenge at https://maproulette.org/mr3/challenge/3588 and
> your feedback is very welcome.There are ~300 tasks.
>
> If you have other ideas for challenges to clean up / review existing data
> let me know and we can discuss.
>
> Martijn
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>


-- 
Please use encrypted communication whenever possible!
Key-ID: 0x34cb93972f186565
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] New MapRoulette challenge to address highway class flip-flops

[Martijn van Exel]

Just as an addendum, you may find false positives like this one 
https://maproulette.org/mr3/challenge/3588/task/11055949 
 where a service road 
connects to residential roads in a perfectly valid way. You should mark these 
as ’not an issue’ in MapRoulette.

Martijn

> On Feb 4, 2019, at 9:36 AM, Martijn van Exel  wrote:
> 
> Hi all, 
> 
> Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette 
> challenge for ‘highway class flip-flops’. What does this mean? Consecutive 
> ways that have a suspicious change from one highway= value to another and 
> then back to the former. This happens sometimes when mappers change the 
> highway= value for some way but miss a bridge somewhere. An example is 
> https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 
>  where 
> the bridge is marked as residential but the two adjoining ways are marked as 
> unclassified.
> 
> You can find the challenge at https://maproulette.org/mr3/challenge/3588 
>  and your feedback is very 
> welcome.There are ~300 tasks.
> 
> If you have other ideas for challenges to clean up / review existing data let 
> me know and we can discuss.
> 
> Martijn
> ___
> 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] New MapRoulette challenge to address highway class flip-flops

[Martijn van Exel]

Hi all, 

Per Matthew Darwin’s request on Twitter, my team prepared a MapRoulette 
challenge for ‘highway class flip-flops’. What does this mean? Consecutive ways 
that have a suspicious change from one highway= value to another and then back 
to the former. This happens sometimes when mappers change the highway= value 
for some way but miss a bridge somewhere. An example is 
https://www.openstreetmap.org/way/53514358#map=19/51.23309/-116.65373 
 where 
the bridge is marked as residential but the two adjoining ways are marked as 
unclassified.

You can find the challenge at https://maproulette.org/mr3/challenge/3588 
 and your feedback is very 
welcome.There are ~300 tasks.

If you have other ideas for challenges to clean up / review existing data let 
me know and we can discuss.

Martijn___
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

[Yaro Shkvorets]

Thanks, it works. Need to run it a few times it looks like. On a random
Markham block went from 88 warnings down to 4 without ruining geometries,
which is acceptable IMO. May need to look into its parameters
(validator.RightAngleBuilding.maximumDelta
and validator.RightAngleBuilding.minimumDelta) to tweak it for our data.

I've looked into CADTools and BuildingGeneralization plugins but
unfortunately they don't work properly destroying geometries and rotating
polygons.

On Mon, Feb 4, 2019 at 10:31 AM Danny McDonald  wrote:

> In JOSM, open the preferences dialog (F12), go to the data validator tab,
> and click the "show informational level" checkbox (it is third from the
> top).  Any validation done will then check for "Building with an almost
> square angle", which will appear under the Other tab.  "Building with an
> almost square angle" used to cause a Warning, but it was downgraded to
> Other due to complaints - see https://josm.openstreetmap.de/ticket/16280.
> Danny
>
> On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:
>
>> Danny,
>> Do you mind sharing how to fix almost square angles in JOSM? I remember
>> seeing such warning a year or two ago but for some reason I don't see it
>> anymore and can't find it in the Validator settings.
>> Did they remove it from the latest version of JOSM or you need to add
>> this rule manually?
>> If there is an easy way to do it then we should do it I guess.
>>
>> On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald 
>> wrote:
>>
>>> 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
>>>
>>
>>
>> --
>> Best Regards,
>>   Yaro Shkvorets
>>
>

-- 
Best Regards,
  Yaro Shkvorets
___
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]

In JOSM, open the preferences dialog (F12), go to the data validator tab,
and click the "show informational level" checkbox (it is third from the
top).  Any validation done will then check for "Building with an almost
square angle", which will appear under the Other tab.  "Building with an
almost square angle" used to cause a Warning, but it was downgraded to
Other due to complaints - see https://josm.openstreetmap.de/ticket/16280.
Danny

On Mon, Feb 4, 2019 at 9:45 AM Yaro Shkvorets  wrote:

> Danny,
> Do you mind sharing how to fix almost square angles in JOSM? I remember
> seeing such warning a year or two ago but for some reason I don't see it
> anymore and can't find it in the Validator settings.
> Did they remove it from the latest version of JOSM or you need to add this
> rule manually?
> If there is an easy way to do it then we should do it I guess.
>
> On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald  wrote:
>
>> 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
>>
>
>
> --
> Best Regards,
>   Yaro Shkvorets
>
___
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

[Pierre Béland via Talk-ca]

En faisant une recherche josm + orthogonal, je trouve ce greffon qui semble 
intéressanthttps://wiki.openstreetmap.org/wiki/JOSM/Plugins/CADTools Il 
contient différentes fonctions pour corriger les polygones. Je vois que l'on 
utilise une tolérance 85-95 pour les angles droits. Il est aussi possible de 
modifier les paramètres.


Pierre 
 

Le lundi 4 février 2019 09 h 46 min 17 s HNE, Yaro Shkvorets 
 a écrit :  
 
 Danny,Do you mind sharing how to fix almost square angles in JOSM? I remember 
seeing such warning a year or two ago but for some reason I don't see it 
anymore and can't find it in the Validator settings. Did they remove it from 
the latest version of JOSM or you need to add this rule manually?If there is an 
easy way to do it then we should do it I guess.
  ___
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

[Yaro Shkvorets]

Danny,
Do you mind sharing how to fix almost square angles in JOSM? I remember
seeing such warning a year or two ago but for some reason I don't see it
anymore and can't find it in the Validator settings.
Did they remove it from the latest version of JOSM or you need to add this
rule manually?
If there is an easy way to do it then we should do it I guess.

On Sun, Feb 3, 2019 at 7:51 PM Danny McDonald  wrote:

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


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