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

Jarek, 
The area you proposed in quite interesting and will force me to look further at 
buildings with sharing edges, a concern Pierre also had. I'll be back soon with 
your area processed.
Daniel

-Original Message-
From: Begin Daniel [mailto:jfd...@hotmail.com] 
Sent: Tuesday, March 26, 2019 14:34
To: Jarek Piórkowski; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

Jarek, 
Since it is a one-time process, I expect to be able to process the files if the 
community feels comfortable with it. In the meantime, people are welcome to 
send me the bounding box of an area they would like to examine.

Daniel

-Original Message-
From: Jarek Piórkowski [mailto:ja...@piorkowski.ca] 
Sent: Tuesday, March 26, 2019 13:46
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:
> There is actually no standard “code” available since I use FME 
> (www.safe.com). It is a proprietary ETL application and all operations are 
> done using “transformers” (https://www.safe.com/transformers/). I can provide 
> you with the workbench I developed (a bunch of linked transformers) but you 
> need a license to run it. This is why I tried to describe the operations I 
> run on the data in the wiki.
>
> As you did, people may send me coordinates (bounding box) of an area they 
> know well. I’ll process the area and send the results back in OSM format. 
> Please, be reasonable on the amount of data to process ;-)

Thanks Daniel. Let me know how it looks then!

Coming from an open-source background, the process is unusual to me,
and I have questions about scalability - will you be able to process
and provide updated data files for all of Canada then? - but if others
are comfortable with it then I won't object.

Some general thoughts regarding tooling as raised upthread:

I was initially excited to see building footprints data as they help
two quite distinct purposes:

1. they provide a mostly-automatic source of geometries for the
millions of single-family houses that wouldn't be mapped in the next
decade otherwise

2. they might provide a corrected and fairly accurate source of
geometries in heavily-built-up areas, where GPS signal is not that
reliable and it can be really difficult to get sufficiently accurate
geometries from imagery, whether because it's not sufficiently
high-resolution, two sets of imagery with conflicting offsets (Bing
and Esri are the two best sets in Toronto, and they're off by about
1-2 m on north-south axis from each other - that's not something I can
check with a consumer-grade GPS so I'm left guessing as to which is
true), or non-vertical imagery (I can count the floors on supposedly
top-down imagery in some cases).

From what I saw, imports in the GTHA initially focused on the first
case, and I think the Tasking Manager setup was mostly sufficient for
those - where there is nothing currently on the map, or a few simple
2D geometries, a 4 sq km area can feasibly be done in under an hour.

However, as raised by others, I would really want the working squares
in Old Toronto for example to be no more than 500 m x 500 m, or no
more than 1 km x 1 km in St. Catharines. I would _love_ to have the
geometries to manually compare and adjust the 3D buildings already
existing in the area, but it will be much slower.

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

Jarek, 
Since it is a one-time process, I expect to be able to process the files if the 
community feels comfortable with it. In the meantime, people are welcome to 
send me the bounding box of an area they would like to examine.

Daniel

-Original Message-
From: Jarek Piórkowski [mailto:ja...@piorkowski.ca] 
Sent: Tuesday, March 26, 2019 13:46
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:
> There is actually no standard “code” available since I use FME 
> (www.safe.com). It is a proprietary ETL application and all operations are 
> done using “transformers” (https://www.safe.com/transformers/). I can provide 
> you with the workbench I developed (a bunch of linked transformers) but you 
> need a license to run it. This is why I tried to describe the operations I 
> run on the data in the wiki.
>
> As you did, people may send me coordinates (bounding box) of an area they 
> know well. I’ll process the area and send the results back in OSM format. 
> Please, be reasonable on the amount of data to process ;-)

Thanks Daniel. Let me know how it looks then!

Coming from an open-source background, the process is unusual to me,
and I have questions about scalability - will you be able to process
and provide updated data files for all of Canada then? - but if others
are comfortable with it then I won't object.

Some general thoughts regarding tooling as raised upthread:

I was initially excited to see building footprints data as they help
two quite distinct purposes:

1. they provide a mostly-automatic source of geometries for the
millions of single-family houses that wouldn't be mapped in the next
decade otherwise

2. they might provide a corrected and fairly accurate source of
geometries in heavily-built-up areas, where GPS signal is not that
reliable and it can be really difficult to get sufficiently accurate
geometries from imagery, whether because it's not sufficiently
high-resolution, two sets of imagery with conflicting offsets (Bing
and Esri are the two best sets in Toronto, and they're off by about
1-2 m on north-south axis from each other - that's not something I can
check with a consumer-grade GPS so I'm left guessing as to which is
true), or non-vertical imagery (I can count the floors on supposedly
top-down imagery in some cases).

From what I saw, imports in the GTHA initially focused on the first
case, and I think the Tasking Manager setup was mostly sufficient for
those - where there is nothing currently on the map, or a few simple
2D geometries, a 4 sq km area can feasibly be done in under an hour.

However, as raised by others, I would really want the working squares
in Old Toronto for example to be no more than 500 m x 500 m, or no
more than 1 km x 1 km in St. Catharines. I would _love_ to have the
geometries to manually compare and adjust the 3D buildings already
existing in the area, but it will be much slower.

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

Re: [Talk-ca] Building Import

2019-03-26 Thread Jarek Piórkowski

On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:
> There is actually no standard “code” available since I use FME 
> (www.safe.com). It is a proprietary ETL application and all operations are 
> done using “transformers” (https://www.safe.com/transformers/). I can provide 
> you with the workbench I developed (a bunch of linked transformers) but you 
> need a license to run it. This is why I tried to describe the operations I 
> run on the data in the wiki.
>
> As you did, people may send me coordinates (bounding box) of an area they 
> know well. I’ll process the area and send the results back in OSM format. 
> Please, be reasonable on the amount of data to process ;-)

Thanks Daniel. Let me know how it looks then!

Coming from an open-source background, the process is unusual to me,
and I have questions about scalability - will you be able to process
and provide updated data files for all of Canada then? - but if others
are comfortable with it then I won't object.

Some general thoughts regarding tooling as raised upthread:

I was initially excited to see building footprints data as they help
two quite distinct purposes:

1. they provide a mostly-automatic source of geometries for the
millions of single-family houses that wouldn't be mapped in the next
decade otherwise

2. they might provide a corrected and fairly accurate source of
geometries in heavily-built-up areas, where GPS signal is not that
reliable and it can be really difficult to get sufficiently accurate
geometries from imagery, whether because it's not sufficiently
high-resolution, two sets of imagery with conflicting offsets (Bing
and Esri are the two best sets in Toronto, and they're off by about
1-2 m on north-south axis from each other - that's not something I can
check with a consumer-grade GPS so I'm left guessing as to which is
true), or non-vertical imagery (I can count the floors on supposedly
top-down imagery in some cases).

From what I saw, imports in the GTHA initially focused on the first
case, and I think the Tasking Manager setup was mostly sufficient for
those - where there is nothing currently on the map, or a few simple
2D geometries, a 4 sq km area can feasibly be done in under an hour.

However, as raised by others, I would really want the working squares
in Old Toronto for example to be no more than 500 m x 500 m, or no
more than 1 km x 1 km in St. Catharines. I would _love_ to have the
geometries to manually compare and adjust the 3D buildings already
existing in the area, but it will be much slower.

--Jarek

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

Re: [Talk-ca] Building Import

2019-03-26 Thread James

If you could share the workbench it would be greatly appreciated.

Thanks

On Tue., Mar. 26, 2019, 1:11 p.m. Begin Daniel,  wrote:

> Hi Jarek,
> There is actually no standard “code” available since I use FME (
> www.safe.com). It is a proprietary ETL application and all operations are
> done using “transformers” (https://www.safe.com/transformers/). I can
> provide you with the workbench I developed (a bunch of linked transformers)
> but you need a license to run it. This is why I tried to describe the
> operations I run on the data in the wiki.
>
> As you did, people may send me coordinates (bounding box) of an area they
> know well. I’ll process the area and send the results back in OSM format.
> Please, be reasonable on the amount of data to process ;-)
>
> Cheers,
> Daniel
>
> -Original Message-
> From: Jarek Piórkowski [mailto:ja...@piorkowski.ca]
> Sent: Tuesday, March 26, 2019 12:15
> To: Begin Daniel; talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Building Import
>
> On Tue, 26 Mar 2019 at 11:58, Begin Daniel  wrote:
> > a first version of the cleaning tool is now functional.
> >
> > At this point, the tool is built to remove extra vertices, orthogonalize
> building footprints (when possible) and identify overlapped geometries.
> Details about the application are found in Canada Building Import
> discussion page …
> >
> >
> https://wiki.openstreetmap.org/wiki/Talk:Canada_Building_Import#Quality_Assurance_details
> >
> > So far, Tim has looked at the result for Montréal (Import data) and
> Pierre for Toronto (OSM data). I understand from their comments that the
> tool generally does its job well. However, both whish to see more
> functionality added to the application (editing automation).
> >
> > Before going further, I would like to know if the community is at ease
> with the Pierre and Tim assessment, and is ready to go further in the
> import process discussion. I ask that because going further with editing
> automation will definitely be more complex, without any guarantee about the
> results.
>
> Hi Daniel,
>
> Thank you for your work on this.
>
> Are you able to share the application or code in any way? I did not
> see any links in the talk page. It is really not possible to say much
> without looking at what the code does with some of the buildings with
> geometries I'm familiar with.
>
> Alternatively shall we send you over an area we're familiar with and
> you could send over the results of the tool? But I am concerned that
> would scale really poorly.
>
> To give a concrete example, I would be curious about the output of the
> tool for area 43.6450,-79.4071,43.6358,-79.4289 - I know that the
> geometries already in OSM for the area are partially inaccurate or
> overly simplified, so I'm curious how the processed import data looks.
>
> Thanks again,
> --Jarek
> ___
> 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

Hi Jarek, 
There is actually no standard “code” available since I use FME (www.safe.com). 
It is a proprietary ETL application and all operations are done using 
“transformers” (https://www.safe.com/transformers/). I can provide you with the 
workbench I developed (a bunch of linked transformers) but you need a license 
to run it. This is why I tried to describe the operations I run on the data in 
the wiki. 

As you did, people may send me coordinates (bounding box) of an area they know 
well. I’ll process the area and send the results back in OSM format. Please, be 
reasonable on the amount of data to process ;-)

Cheers,
Daniel

-Original Message-
From: Jarek Piórkowski [mailto:ja...@piorkowski.ca] 
Sent: Tuesday, March 26, 2019 12:15
To: Begin Daniel; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

On Tue, 26 Mar 2019 at 11:58, Begin Daniel  wrote:
> a first version of the cleaning tool is now functional.
>
> At this point, the tool is built to remove extra vertices, orthogonalize 
> building footprints (when possible) and identify overlapped geometries. 
> Details about the application are found in Canada Building Import discussion 
> page …
>
> https://wiki.openstreetmap.org/wiki/Talk:Canada_Building_Import#Quality_Assurance_details
>
> So far, Tim has looked at the result for Montréal (Import data) and Pierre 
> for Toronto (OSM data). I understand from their comments that the tool 
> generally does its job well. However, both whish to see more functionality 
> added to the application (editing automation).
>
> Before going further, I would like to know if the community is at ease with 
> the Pierre and Tim assessment, and is ready to go further in the import 
> process discussion. I ask that because going further with editing automation 
> will definitely be more complex, without any guarantee about the results.

Hi Daniel,

Thank you for your work on this.

Are you able to share the application or code in any way? I did not
see any links in the talk page. It is really not possible to say much
without looking at what the code does with some of the buildings with
geometries I'm familiar with.

Alternatively shall we send you over an area we're familiar with and
you could send over the results of the tool? But I am concerned that
would scale really poorly.

To give a concrete example, I would be curious about the output of the
tool for area 43.6450,-79.4071,43.6358,-79.4289 - I know that the
geometries already in OSM for the area are partially inaccurate or
overly simplified, so I'm curious how the processed import data looks.

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

Re: [Talk-ca] Building Import

2019-03-26 Thread Jarek Piórkowski

On Tue, 26 Mar 2019 at 11:58, Begin Daniel  wrote:
> a first version of the cleaning tool is now functional.
>
> At this point, the tool is built to remove extra vertices, orthogonalize 
> building footprints (when possible) and identify overlapped geometries. 
> Details about the application are found in Canada Building Import discussion 
> page …
>
> https://wiki.openstreetmap.org/wiki/Talk:Canada_Building_Import#Quality_Assurance_details
>
> So far, Tim has looked at the result for Montréal (Import data) and Pierre 
> for Toronto (OSM data). I understand from their comments that the tool 
> generally does its job well. However, both whish to see more functionality 
> added to the application (editing automation).
>
> Before going further, I would like to know if the community is at ease with 
> the Pierre and Tim assessment, and is ready to go further in the import 
> process discussion. I ask that because going further with editing automation 
> will definitely be more complex, without any guarantee about the results.

Hi Daniel,

Thank you for your work on this.

Are you able to share the application or code in any way? I did not
see any links in the talk page. It is really not possible to say much
without looking at what the code does with some of the buildings with
geometries I'm familiar with.

Alternatively shall we send you over an area we're familiar with and
you could send over the results of the tool? But I am concerned that
would scale really poorly.

To give a concrete example, I would be curious about the output of the
tool for area 43.6450,-79.4071,43.6358,-79.4289 - I know that the
geometries already in OSM for the area are partially inaccurate or
overly simplified, so I'm curious how the processed import data looks.

Thanks again,
--Jarek

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

Re: [Talk-ca] Building Import

Hi all,
a first version of the cleaning tool is now functional.
At this point, the tool is built to remove extra vertices, orthogonalize 
building footprints (when possible) and identify overlapped geometries. Details 
about the application are found in Canada Building Import discussion page ...
https://wiki.openstreetmap.org/wiki/Talk:Canada_Building_Import#Quality_Assurance_details
So far, Tim has looked at the result for Montréal (Import data) and Pierre for 
Toronto (OSM data). I understand from their comments that the tool generally 
does its job well. However, both whish to see more functionality added to the 
application (editing automation).
Before going further, I would like to know if the community is at ease with the 
Pierre and Tim assessment, and is ready to go further in the import process 
discussion. I ask that because going further with editing automation will 
definitely be more complex, without any guarantee about the results.
If we agree to go further, I can try to improve the application but at least 
the data could be pre-processed.

Daniel

From: Nate Wessel [mailto:bike...@gmail.com]
Sent: Thursday, March 21, 2019 13:49
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import


Daniel,

This is exciting news! After much talk on this list, it seems we may have some 
actual progress toward fixing the various data quality issues. Would you mind 
sharing some of your code, or a description of your workflow here or on GitHub 
or the like so we can take a look?

One thing you didn't mention which I think will be really critical, especially 
in central Toronto: We need to remove buildings from the import dataset that 
may already be mapped in OSM. That is, buildings that overlap with existing 
buildings. For this import to make any sense in Central Toronto, we need 
conflation to move slowly, and in smaller, more manageable steps. Buildings 
that are already mapped should be checked manually at a later time in batches 
that a skilled human can manage in less than an hour. The tasking manager as 
it's currently set up would have all of downtown conflated by hand in one task 
by a single mapper - a recipe for disaster I'm sure, given how detailed the map 
is in that area.

Cheers,
Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com<http://natewessel.com>
On 3/19/19 12:58 PM, Begin Daniel wrote:
Hi all,
As mentioned a few weeks ago, I have almost completed the development of a 
clean-up tool for the data to be imported.
So far, it removes nonessential vertices, orthogonalizes building corners when 
reasonable and ensures walls' alignment within given tolerances. Building 
footprints that can't be processed completely are flagged accordingly, so they 
could be examined thoroughly at import time.
Eventually, It should be easy to remove overlapping buildings (potentially 
generated from a 3d mapping), but I doubt that splitting terrace into 
individual buildings can be done automatically.
The tool uses some parameters that need to be adjusted. I would like that those 
who are interested in this aspect of the import send me benchmark data that 
could be problematic. I will process them to adjust parameters and/or the tool, 
and I will send back the results to the sender for a thorough examination.
I should soon document the process in the "Canada Building Import" wiki page 
(in a pre-processing section).

Thought? Comments?

Daniel




___

Talk-ca mailing list

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

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

Re: [Talk-ca] Building Import

2019-03-21 Thread John Whelan

Nate are you requesting something specific on the Canadian task manager 
for Toronto at this time or would you prefer to look through Daniel's 
work first?


Thanks

Cheerio John

Nate Wessel wrote on 2019-03-21 1:49 PM:


Daniel,

This is exciting news! After much talk on this list, it seems we may 
have some actual progress toward fixing the various data quality 
issues. Would you mind sharing some of your code, or a description of 
your workflow here or on GitHub or the like so we can take a look?


One thing you didn't mention which I think will be really critical, 
especially in central Toronto: We need to remove buildings from the 
import dataset that may already be mapped in OSM. That is, buildings 
that overlap with existing buildings. For this import to make any 
sense in Central Toronto, we need conflation to move slowly, and in 
smaller, more manageable steps. Buildings that are already mapped 
should be checked manually at a later time in batches that a skilled 
human can manage in less than an hour. The tasking manager as it's 
currently set up would have all of downtown conflated by hand in one 
task by a single mapper - a recipe for disaster I'm sure, given how 
detailed the map is in that area.


Cheers,

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

On 3/19/19 12:58 PM, Begin Daniel wrote:


Hi all,

As mentioned a few weeks ago, I have almost completed the development 
of a clean-up tool for the data to be imported.


So far, it removes nonessential vertices, orthogonalizes building 
corners when reasonable and ensures walls’ alignment within given 
tolerances. Building footprints that can’t be processed completely 
are flagged accordingly, so they could be examined thoroughly at 
import time.


Eventually, It should be easy to remove overlapping buildings 
(potentially generated from a 3d mapping), but I doubt that splitting 
terrace into individual buildings can be done automatically.


The tool uses some parameters that need to be adjusted. I would like 
that those who are interested in this aspect of the import send me 
benchmark data that could be problematic. I will process them to 
adjust parameters and/or the tool, and I will send back the results 
to the sender for a thorough examination.


I should soon document the process in the “Canada Building Import” 
wiki page (in a pre-processing section).


Thought? Comments?

Daniel


___
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


--
Sent from Postbox 

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

Re: [Talk-ca] Building Import

2019-03-19 Thread John Whelan


Bonne chance

John

Begin Daniel wrote on 2019-03-19 2:14 PM:


I expect Pierre, Tim and others to send me any data they believe would 
be problematic. If I send them my own test dataset, it may not cover 
the cases they are interested in. J


Daniel

*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Tuesday, March 19, 2019 13:32
*To:* Begin Daniel
*Cc:* talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] Building Import

It would make logical sense to preprocess all the data but then you 
end up with two sources.  The Open Data original and the preprocessed 
data source.


From a logical point of view it would make sense to use the Microsoft 
data to fill in the gaps.  So add it into the preprocessed data.


Then you get to reality.  To make it work across Canada you need to 
get agreement and that I think will be the most difficult part.


Step one I think is ask Pierre nicely to review a sample and see if it 
meets his "quality" expectations.


Step two would be check with Tim in Montreal for his thoughts.

If they are both in agreement that it is acceptable then we see if we 
can get some sort of acceptance across the country possibly blacking 
out certain areas.


If we can we'll need to go back to the import mailing list and say we 
wish to combine two sources and amend the plan accordingly.


Otherwise it is up to whoever sorts out an import plan / import for a 
particular area to consider its use.


Cheerio John

On Tue, 19 Mar 2019 at 12:59, Begin Daniel <mailto:jfd...@hotmail.com>> wrote:


Hi all,

As mentioned a few weeks ago, I have almost completed the
development of a clean-up tool for the data to be imported.

So far, it removes nonessential vertices, orthogonalizes building
corners when reasonable and ensures walls’ alignment within given
tolerances. Building footprints that can’t be processed completely
are flagged accordingly, so they could be examined thoroughly at
import time.

Eventually, It should be easy to remove overlapping buildings
(potentially generated from a 3d mapping), but I doubt that
splitting terrace into individual buildings can be done
automatically.

The tool uses some parameters that need to be adjusted. I would
like that those who are interested in this aspect of the import
send me benchmark data that could be problematic. I will process
them to adjust parameters and/or the tool, and I will send back
the results to the sender for a thorough examination.

I should soon document the process in the “Canada Building Import”
wiki page (in a pre-processing section).

Thought? Comments?

Daniel

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



--
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

2019-03-19 Thread Begin Daniel

I expect Pierre, Tim and others to send me any data they believe would be 
problematic. If I send them my own test dataset, it may not cover the cases 
they are interested in. ☺

Daniel

From: john whelan [mailto:jwhelan0...@gmail.com]
Sent: Tuesday, March 19, 2019 13:32
To: Begin Daniel
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

It would make logical sense to preprocess all the data but then you end up with 
two sources.  The Open Data original and the preprocessed data source.

From a logical point of view it would make sense to use the Microsoft data to 
fill in the gaps.  So add it into the preprocessed data.

Then you get to reality.  To make it work across Canada you need to get 
agreement and that I think will be the most difficult part.

Step one I think is ask Pierre nicely to review a sample and see if it meets 
his "quality" expectations.

Step two would be check with Tim in Montreal for his thoughts.

If they are both in agreement that it is acceptable then we see if we can get 
some sort of acceptance across the country possibly blacking out certain areas.

If we can we'll need to go back to the import mailing list and say we wish to 
combine two sources and amend the plan accordingly.

Otherwise it is up to whoever sorts out an import plan / import for a 
particular area to consider its use.

Cheerio John

On Tue, 19 Mar 2019 at 12:59, Begin Daniel 
mailto:jfd...@hotmail.com>> wrote:
Hi all,
As mentioned a few weeks ago, I have almost completed the development of a 
clean-up tool for the data to be imported.
So far, it removes nonessential vertices, orthogonalizes building corners when 
reasonable and ensures walls’ alignment within given tolerances. Building 
footprints that can’t be processed completely are flagged accordingly, so they 
could be examined thoroughly at import time.
Eventually, It should be easy to remove overlapping buildings (potentially 
generated from a 3d mapping), but I doubt that splitting terrace into 
individual buildings can be done automatically.
The tool uses some parameters that need to be adjusted. I would like that those 
who are interested in this aspect of the import send me benchmark data that 
could be problematic. I will process them to adjust parameters and/or the tool, 
and I will send back the results to the sender for a thorough examination.
I should soon document the process in the “Canada Building Import” wiki page 
(in a pre-processing section).

Thought? Comments?

Daniel

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

Re: [Talk-ca] Building Import

2019-03-19 Thread john whelan

It would make logical sense to preprocess all the data but then you end up
with two sources.  The Open Data original and the preprocessed data source.

>From a logical point of view it would make sense to use the Microsoft data
to fill in the gaps.  So add it into the preprocessed data.

Then you get to reality.  To make it work across Canada you need to get
agreement and that I think will be the most difficult part.

Step one I think is ask Pierre nicely to review a sample and see if it
meets his "quality" expectations.

Step two would be check with Tim in Montreal for his thoughts.

If they are both in agreement that it is acceptable then we see if we can
get some sort of acceptance across the country possibly blacking out
certain areas.

If we can we'll need to go back to the import mailing list and say we wish
to combine two sources and amend the plan accordingly.

Otherwise it is up to whoever sorts out an import plan / import for a
particular area to consider its use.

Cheerio John

On Tue, 19 Mar 2019 at 12:59, Begin Daniel  wrote:

> Hi all,
>
> As mentioned a few weeks ago, I have almost completed the development of a
> clean-up tool for the data to be imported.
>
> So far, it removes nonessential vertices, orthogonalizes building corners
> when reasonable and ensures walls’ alignment within given tolerances.
> Building footprints that can’t be processed completely are flagged
> accordingly, so they could be examined thoroughly at import time.
>
> Eventually, It should be easy to remove overlapping buildings (potentially
> generated from a 3d mapping), but I doubt that splitting terrace into
> individual buildings can be done automatically.
>
> The tool uses some parameters that need to be adjusted. I would like that
> those who are interested in this aspect of the import send me benchmark
> data that could be problematic. I will process them to adjust parameters
> and/or the tool, and I will send back the results to the sender for a
> thorough examination.
>
> I should soon document the process in the “Canada Building Import” wiki
> page (in a pre-processing section).
>
>
>
> Thought? Comments?
>
>
>
> Daniel
>
>
> ___
> 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

2019-03-16 Thread Danny McDonald

After further consideration, I have decided to unsubscribe to this mailing
list, at least for the near future.  I will not be participating in further
discussion, but I don't plan to import any more buildings until you all
reach a consensus.

I have two reasons for this decision:
- I don't enjoy discussion, I don't think I make my points very well, and I
don't think I add to the tone of the discussion.  I'm on OSM to map, not to
discuss and argue about mapping.  @Rps333 (an Ottawa mapper) has it right
with his tagline "Map, Not Words".
- I have been deeply offended by the behaviour of Nate, who has refused to
apologize for a personal insult he made in a private email.  I don't feel
comfortable engaging in a discussion with him in it.

DannyMcD

P.S. Please do not send any emails to this account
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

2019-03-15 Thread john whelan

I think at this point in time we need to try to get some sort of agreement
on how to proceed.  My first thought would be to ban the youngsters so
anyone under 65 shouldn't be involved.  That way it would slow the process
down unfortunately it isn't really practical.

I think we need time to digest and review what has been done so far.  I
think it would be sensible for a different mapper to go over the imported
areas using the task manager and verify the buildings against Bing or other
imagery to ensure we haven't introduced an imaginary town etc.

I do think we need to break the import up into more manageable chunks.
Whether these need to be at municipal level or not needs thought.  The case
for is that would allow the data from different sources to be carefully
checked over. The case against is there are a lot of municipalities and in
places like Manitoba there are very few mappers on the ground.

Basically from a population point of view Canada is a collection of around
half a dozen cities and these have a local OSM community.  Montreal,
Ottawa, Vancouver, Toronto for example.  Once you take these out then you
have much smaller numbers.  I'm not certain about Calgary and Edmonton
whether they have a local community or not.

Quebec with its own mailing list is self contained and I think will sort
itself out in time.  Montreal is working together to sort something out.

Terraced houses in Ottawa we just have the outline with a tag of terrace.
This was the way they were mapped even before the City of Ottawa import.
Units may have an individual address node.

At the moment I favour breaking the country up into provinces and for each
province depending on the number of buildings I might split it up again.
So Ontario would be something like Ontario rural and Toronto but I'm not
quite sure of where Toronto begins and ends.

Thoughts and bear in mind that Microsoft has released buildings for Canada
as well.  I haven't noticed an import plan but it would be fairly easy for
someone to bring in some buildings so to retain some sort of control a plan
might well be useful.

Thanks John

On Fri, 15 Mar 2019 at 15:34, Tim Elrick  wrote:

> I think, Montreal's OSMappers would appreciate to discuss the import of
> the buildings there first on the local list. By the way, John, I have never
> said I would be taking the lead for the entirety of Québec (at least, at
> the moment). However, I feel that the import should be discussed on the
> liste OSM de Québec first.
>
> Danny, I disagree with you on the import of building blocks. I find it
> much more tedious to discern them later, then splitting them into single
> buildings first before importing, because, I think, you need to know your
> neighbourhood very well to find unsplit buildings in the OSM database.
> Doing this for a whole town or even city (like Montreal) would take much
> longer than pre-processing.
>
> As for the rest, I have some understanding for the impatience of OSMappers
> about the moratorium on the import - as quite some time has passed and the
> discussion hasn't really moved on nor has the development of the
> countrywide import plan [1] - last change there was beginning of February.
>
> Having looked at the Microsoft data and compared quality to the Open
> Building Database in two places (Montréal, QC and Williams Lake, BC), I
> would suggest to refrain from using it as a source for importing, unless
> you verify them for small areas (but then you can almost draw them by
> hand). In dense areas like downtown Montréal the building footprints are in
> many cases plainly wrong (see my contribution to this list on 2019-03-02,
> 19h57 EST), in more scattered areas and suburban landscapes buildings are
> randomly aligned and quite some buildings are missing (my unverified
> estimate is about 5-10%).
>
> As for the Open Building database, it is important to discern the data by
> the sources as each municipality that contributed data might have used
> different methods and has different mapping standards. Now add the
> disagreement on this list about orthogonalization and building details. I
> think, this suggests breaking up the import plan in smaller batches; for
> the start it can be cloned from the original one, but the pre-processing
> and import process might differ due to how data sources might need to be
> treated as well as how local OSM communities would like to go forward.
>
> What do you reckon?
>
> Tim
>
> [1] https://wiki.openstreetmap.org/wiki/Canada_Building_Import
>
>
> On 2019-03-15 14:01, John Whelan wrote:
> Which I think comes back to defining the local mappers.
>
> There has been discussion on Montreal as well and not all Ontario thinks
> the same way.  Ottawa local mappers for example have different opinions to
> Pierre and Nate on what is acceptable and I'm under the impression that not
> everyone in Toronto agrees with Nate's position.
>
> We seem to be blocking out parts of the country such as Montreal is this a
> reasonable

Re: [Talk-ca] Building Import

2019-03-15 Thread Tim Elrick

I think, Montreal's OSMappers would appreciate to discuss the import of 
the buildings there first on the local list. By the way, John, I have 
never said I would be taking the lead for the entirety of Québec (at 
least, at the moment). However, I feel that the import should be 
discussed on the liste OSM de Québec first.


Danny, I disagree with you on the import of building blocks. I find it 
much more tedious to discern them later, then splitting them into single 
buildings first before importing, because, I think, you need to know 
your neighbourhood very well to find unsplit buildings in the OSM 
database. Doing this for a whole town or even city (like Montreal) would 
take much longer than pre-processing.


As for the rest, I have some understanding for the impatience of 
OSMappers about the moratorium on the import - as quite some time has 
passed and the discussion hasn't really moved on nor has the development 
of the countrywide import plan [1] - last change there was beginning of 
February.


Having looked at the Microsoft data and compared quality to the Open 
Building Database in two places (Montréal, QC and Williams Lake, BC), I 
would suggest to refrain from using it as a source for importing, unless 
you verify them for small areas (but then you can almost draw them by 
hand). In dense areas like downtown Montréal the building footprints are 
in many cases plainly wrong (see my contribution to this list on 
2019-03-02, 19h57 EST), in more scattered areas and suburban landscapes 
buildings are randomly aligned and quite some buildings are missing (my 
unverified estimate is about 5-10%).


As for the Open Building database, it is important to discern the data 
by the sources as each municipality that contributed data might have 
used different methods and has different mapping standards. Now add the 
disagreement on this list about orthogonalization and building details. 
I think, this suggests breaking up the import plan in smaller batches; 
for the start it can be cloned from the original one, but the 
pre-processing and import process might differ due to how data sources 
might need to be treated as well as how local OSM communities would like 
to go forward.


What do you reckon?

Tim

[1] https://wiki.openstreetmap.org/wiki/Canada_Building_Import


On 2019-03-15 14:01, John Whelan wrote:
Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks 
the same way.  Ottawa local mappers for example have different opinions 
to Pierre and Nate on what is acceptable and I'm under the impression 
that not everyone in Toronto agrees with Nate's position.


We seem to be blocking out parts of the country such as Montreal is this 
a reasonable approach?


Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?


For example one small Ontario city has to my knowledge one OpenStreetMap 
mapper who maps very occasionally.  My understanding is they would be 
quite happy to see an import happen but many of the buildings have 
already been mapped although not to the accuracy that the Stats Can data 
offers. How do you deal with these smaller cities and townships?


Thanks

Cheerio John

Paul Norman via Talk-ca wrote on 2019-03-15 1:45 PM:

On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disa gree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



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


--
Sent from Postbox 



___
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

2019-03-15 Thread Pierre Béland via Talk-ca

John, 

les contributeurs de Ottawa, vous semblez en général d'accord pour poursuivre 
les imports et avez la capacité technique de faire des imports rapides, ce que 
vous avez démontré.  Il ne manque qu'un petit pas à franchir et discuter de la 
qualité des données et accepter de tenir compte des communautés en général.
Essaies tu de dire que les 6 contributeurs qui ont fait des imports se sont 
limités à des territoires locaux, voire leur province et ont discuté avec les 
communautés locales sur la méthodologie satisfaisante pour corriger les données 
avant l'import ?   Pour le Québec, je peux te dire que non.

Je constate plutot un refus de discuter et une volonté de poursuivre malgré les 
opinions divergentes. Et la qualité ?  J'ai clairement démontré il me semble 
que les tracés imprécis étaient clairement visibles.  Et si je comprends bien, 
nous avons maintenant un million de nouveaux bâtiments que l'on pourrait 
«blanchir» si n'importe qui met un tampon approuv dessus.  Je dois dire que 
l'argument est difficile à avaler.
 
Pierre 
 

Le vendredi 15 mars 2019 14 h 02 min 23 s HAE, John Whelan 
 a écrit :  
 
 Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks the 
same way.  Ottawa local mappers for example have different opinions to Pierre 
and Nate on what is acceptable and I'm under the impression that not everyone 
in Toronto agrees with Nate's position.

We seem to be blocking out parts of the country such as Montreal is this a 
reasonable approach?

Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?

For example one small Ontario city has to my knowledge one OpenStreetMap mapper 
who maps very occasionally.  My understanding is they would be quite happy to 
see an import happen but many of the buildings have already been mapped 
although not to the accuracy that the Stats Can data offers.  How do you deal 
with these smaller cities and townships?

Thanks

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

Re: [Talk-ca] Building Import


Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks 
the same way.  Ottawa local mappers for example have different opinions 
to Pierre and Nate on what is acceptable and I'm under the impression 
that not everyone in Toronto agrees with Nate's position.


We seem to be blocking out parts of the country such as Montreal is this 
a reasonable approach?


Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?


For example one small Ontario city has to my knowledge one OpenStreetMap 
mapper who maps very occasionally.  My understanding is they would be 
quite happy to see an import happen but many of the buildings have 
already been mapped although not to the accuracy that the Stats Can data 
offers.  How do you deal with these smaller cities and townships?


Thanks

Cheerio John

Paul Norman via Talk-ca wrote on 2019-03-15 1:45 PM:

On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disagree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



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


--
Sent from Postbox 

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

Re: [Talk-ca] Building Import

2019-03-15 Thread Paul Norman via Talk-ca


On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disagree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



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

Re: [Talk-ca] Building Import

I think there are two issues here the first is I accept having a large 
number of anything by one mapper has the potential for a systematic error.


If the import is verified by a second mapper independently I assume this 
would be acceptable?


The second is more to do with discussion within the community and is I 
feel more complex.


Cheerio John

Frederik Ramm wrote on 2019-03-15 12:06 PM:

Hi,

On 15.03.19 16:23, Danny McDonald wrote:

I think many people on this list fundamentally misunderstand the way OSM
operates.  Most OSM contributions are made by individuals who see a
gap/mistake in the data and fix it.

True!


It is not a "community process"
where contributions are made by a group of "local mappers" (although
this sometimes happens).

True!

As long as we're talking normal, everyday, "manual" mapping. Like, 100
edits a day, or maybe 1000 edits on a good day.

For things that go beyond a little mapping by the individual, we tend to
have processes, e.g. for imports, for automated edits, for organised edits.

The general idea behind the discuss-these-things-first rules is not that
one mapper is better than another, but quite the opposite: One mapper
alone can actually make stupid mistakes or suffer from bad judgement,
something that the larger community can help against.

Bye
Frederik



--
Sent from Postbox 

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

Re: [Talk-ca] Building Import

2019-03-15 Thread Andrew Lester

I disagree. Silence won't solve anything. 

I'm speaking here as a local BC mapper, and I strongly disagree with these 
recent imports. I thought we had a general consensus that we'd discuss this as 
a community and figure things out before restarting the import, but it seems 
that some mappers don't like having to wait or deal with other people. 
Considering that Danny seems to consider orthogonal buildings to be outright 
wrong (a position that I strongly disagree with and I think some others do 
too), there's clearly still some discussion required before imports can be 
started again. Sure, you could go ahead and import anyway contrary to other 
community members' wishes, but that sure won't make you any friends and you run 
the risk of having your changesets reverted if the data quality is too poor or 
violates the import guidelines. 

Please, please, please, let's hammer things out first before we import any of 
this data. The buildings aren't going anywhere, so there's no need to rush poor 
data into the database. If you're itching to map some things, go for a walk and 
map some addresses and businesses near you. 

Andrew 
Victoria, BC, Canada 



From: "Danny McDonald"  
To: "talk-ca"  
Sent: Friday, March 15, 2019 8:48:55 AM 
Subject: Re: [Talk-ca] Building Import 

OK, so this discussion has gone a bit off the rails. In terms of the DWG, this 
has all happened so fast - the referral to the DWG was less than 2 hours after 
the initial message, and was not in response to any actual edits I made after 
receiving Pierre's stop message. 
I suggest that we all stop emailing this list for the rest of the day, given 
the high level of tension on both sides. I will not be importing anything for 
the next week (at the very least), and I don't think anyone else will either. 
DannyMcD 

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

Re: [Talk-ca] Building Import

2019-03-15 Thread Frederik Ramm

Hi,

On 15.03.19 16:23, Danny McDonald wrote:
> I think many people on this list fundamentally misunderstand the way OSM
> operates.  Most OSM contributions are made by individuals who see a
> gap/mistake in the data and fix it. 

True!

> It is not a "community process"
> where contributions are made by a group of "local mappers" (although
> this sometimes happens).  

True!

As long as we're talking normal, everyday, "manual" mapping. Like, 100
edits a day, or maybe 1000 edits on a good day.

For things that go beyond a little mapping by the individual, we tend to
have processes, e.g. for imports, for automated edits, for organised edits.

The general idea behind the discuss-these-things-first rules is not that
one mapper is better than another, but quite the opposite: One mapper
alone can actually make stupid mistakes or suffer from bad judgement,
something that the larger community can help against.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [Talk-ca] Building import in BC and Quebec

At the end of the day one would hope we are a community.  We are a large 
group with divergent opinions and to be honest there is a great deal of 
interest in non-mappers in this sort of data.


For example building data is being used in Tanzania to work out the 
optimal areas for group solar panels.  It can be used for many other 
things which may not be immediately apparent to a traditional paper 
based mapper.


With both the Stats Can released data and the Microsoft released data 
floating around some data is going to creep in anyway.


At the moment we have Tim taking responsibility for Montreal.

There seems to be a number of divergent views in Toronto so I think they 
should sit down and see if they can come to some sort of agreement.


We have Pierre and Nate who would appear to have different standards of 
what is acceptable to other mappers.  We have at least half a dozen 
mappers who support the import, shown by their imports. I can probably 
find a few more mappers who support the import if it comes to a simple vote.


I would suggest we try to best manage the process.  If that means the 
imported data is verified by another mapper I think that can be arranged.


Cheerio John

Yaro Shkvorets wrote on 2019-03-15 11:22 AM:
As an experienced local Ontario and Quebec mapper I don't see any 
major problems with Stats Can building quality. It's detailed and 
recent, it's the best dataset we could ever possibly get and it's far 
superior to Microsoft quality. Having many buildings with "almost 
square angles" in this dataset is not an issue as vast majority of 
such deviations cannot be seen with a naked eye. Unfortunately any 
orthogonalization algorithms will do more harm than good in such 
cases. Mapping for the Validator, just like mapping for the Renderer 
is a wrong way to map.
Issues were raised, issues were addressed in the import plan. If there 
are any problems with some mappers violating any specific import plan 
rules such issues need to be pointed out so they can adjust their 
workflow.

My 2 cents.

On Fri, Mar 15, 2019 at 10:55 AM Nate Wessel > wrote:


I just reported this to the data working group, in case you
haven't already. Hopefully they will step in!

Cheers,

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

On 3/15/19 10:30 AM, Pierre Béland wrote:

Réponse immédiate avec refus de discussion de la part de
DannyMcD_imports. Celui-ci indique qu'il prévoit continuer l'import.
voir https://www.openstreetmap.org/changeset/67686901

There was a discussion, issues were raised, the problems (to the
extent that they existed at all) have been addressed. I plan to
continue importing, unless a *specific* valid issue is raised.
Please do not contact me again unless you have such an issue.


La prochaine étape est je pense de contacter le Data Working Group.


Pierre



___
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


--
Sent from Postbox 

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

Re: [Talk-ca] Building Import

2019-03-15 Thread Danny McDonald

OK, so this discussion has gone a bit off the rails.  In terms of the DWG,
this has all happened so fast - the referral to the DWG was less than 2
hours after the initial message, and was not in response to any actual
edits I made after receiving Pierre's stop message.

I suggest that we all stop emailing this list for the rest of the day,
given the high level of tension on both sides.  I will not be importing
anything for the next week (at the very least), and I don't think anyone
else will either.
DannyMcD
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

2019-03-15 Thread Martin Chalifoux via Talk-ca

I certainly agree with that statement ! Importing should be much more rigorous 
and careful, as mistakes or poor execution is costly. 

> On Mar 15, 2019, at 11:29, Nate Wessel  wrote:
> 
> There is a massive difference between making edits without review and 
> importing millions of buildings without review. 
> 
> 

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

Re: [Talk-ca] Building Import

2019-03-15 Thread Nate Wessel


Seriously Danny?

Pierre was the first to suggest the DWG after you replied to him that 
wouldn't engage in further discussion. You only joined this conversation 
after I reported you.


There is a massive difference between making edits without review and 
importing millions of buildings without review.


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

On 3/15/19 11:23 AM, Danny McDonald wrote:
By the way, I strongly object to the way Nate immediately went to the 
DWG, instead of attempting to engage in discussion.


I think many people on this list fundamentally misunderstand the way 
OSM operates.  Most OSM contributions are made by individuals who see 
a gap/mistake in the data and fix it.  It is not a "community process" 
where contributions are made by a group of "local mappers" (although 
this sometimes happens).


The great strength of OSM (relative to Google Maps), is that you can 
make edits immediately without going through a peer review process.  
Some people on this list seem to want to impose a peer review process 
on OSM (at least for imports, for now), because they think they know 
better, and should be given power because of it.


DannyMcD

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

Re: [Talk-ca] Building import in BC and Quebec

2019-03-15 Thread Yaro Shkvorets

As an experienced local Ontario and Quebec mapper I don't see any major
problems with Stats Can building quality. It's detailed and recent, it's
the best dataset we could ever possibly get and it's far superior to
Microsoft quality. Having many buildings with "almost square angles" in
this dataset is not an issue as vast majority of such deviations cannot be
seen with a naked eye. Unfortunately any orthogonalization algorithms will
do more harm than good in such cases. Mapping for the Validator, just like
mapping for the Renderer is a wrong way to map.
Issues were raised, issues were addressed in the import plan. If there are
any problems with some mappers violating any specific import plan rules
such issues need to be pointed out so they can adjust their workflow.
My 2 cents.

On Fri, Mar 15, 2019 at 10:55 AM Nate Wessel  wrote:

> I just reported this to the data working group, in case you haven't
> already. Hopefully they will step in!
>
> Cheers,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 3/15/19 10:30 AM, Pierre Béland wrote:
>
> Réponse immédiate avec refus de discussion de la part de DannyMcD_imports.
> Celui-ci indique qu'il prévoit continuer l'import.
> voir https://www.openstreetmap.org/changeset/67686901
>
> There was a discussion, issues were raised, the problems (to the extent
> that they existed at all) have been addressed. I plan to continue
> importing, unless a *specific* valid issue is raised. Please do not contact
> me again unless you have such an issue.
>
> La prochaine étape est je pense de contacter le Data Working Group.
>
>
> Pierre
>
>
> ___
> 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 in BC and Quebec

2019-03-15 Thread Nate Wessel

I just reported this to the data working group, in case you haven't 
already. Hopefully they will step in!


Cheers,

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

On 3/15/19 10:30 AM, Pierre Béland wrote:
Réponse immédiate avec refus de discussion de la part de 
DannyMcD_imports. Celui-ci indique qu'il prévoit continuer l'import.

voir https://www.openstreetmap.org/changeset/67686901

There was a discussion, issues were raised, the problems (to the 
extent that they existed at all) have been addressed. I plan to 
continue importing, unless a *specific* valid issue is raised. Please 
do not contact me again unless you have such an issue.



La prochaine étape est je pense de contacter le Data Working Group.


Pierre


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

Re: [Talk-ca] Building import in BC and Quebec

2019-03-15 Thread Nate Wessel

Given the scale of this illicit import (thanks Pierre for the stats!), I 
would, yes, stick my neck out and say that I oppose this action as a 
Canadian mapper. Contributors who are clearly violating community norms 
about discussion and consensus do not constitute an implicit consensus 
of some local community. In the absence of a healthy local discussion 
about this, I think it's up to us to say that this needs to stop.


The tasking manager for this project should be taken down immediately. 
Whether they strictly need it to continue or not, they are (ab)using it 
and it's clearly helping them continue with an import that is being 
actively disputed.


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

On 3/15/19 8:28 AM, Jarek Piórkowski wrote:

IMO the huron/hamptonavemapper import is quite clearly in active
disagreement with the import suspension - while I could believe that
one user could overlook clicking on the wiki link in their changeset
messages just once and seeing the bold "on hold", setting up a brand
new similarly named account on February 15, 2019 and immediately
starting to import suggests they know what they're doing. And it's not
like one ultimately _needs_ the tasking manager to insert the data.

The question is what are we going to do about it? Are you going to
speak for Alberta and BC in opposing this import, Nate? That's
defensible but also debatable.

--Jarek

On Thu, 14 Mar 2019 at 21:12, Nate Wessel  wrote:

I would suggest, again, that the tasking manager for this import be locked or 
taken down if that is not possible. One good way to stop people from importing 
when we don't have consensus is to not make it so easy for them. Indeed, I 
would find it plausible if these people said they didn't even know the import 
was paused - their evidence: that the tasking manager is still active!

Best,

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

On 3/14/19 7:42 PM, Jarek Piórkowski wrote:

The changeset comment messages link to the Stats Canada import plan on
the OSM wiki.

I missed it but there were also some edits in Alberta. Quebec edits I
saw were only a couple, outside of Quebec.

http://tasks.osmcanada.ca/project/148 has also been updated, and the
Alberta tasks.

It does raise the point that with a country this large, with editor
community this sparse, there are very few ways to enforce or police a
countrywide consensus, or even arrive at one. Maybe BC mappers like
the import, square angles or no? (Does anyone go to the Metrotown
Meetup?)

--Jarek

On Thu, 14 Mar 2019 at 19:36, john whelan  wrote:

Wicked lad importing without an import plan?

Ask him nicely where the import plan for their imports is.

Looks like a new mapper so may not know the rules.

I think currently there are two sets of data that are licensed for import, the 
Stats Can stuff and the Microsoft stuff.  I haven't seen any import plan for 
the Microsoft stuff but unfortunately it's probably fairly easy to import on 
the Stats Can side my feeling is we need to work out who the locals are to get 
buy in since Canada wide there is no consensus on what is acceptable.  After a 
request from a local group then I think that particular area can proceed.

Quebec I think is being organised by Tim.

Thanks John

On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:

Are people aware that there are buildings being imported by
https://www.openstreetmap.org/user/huronavemapper (most recent 12
hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
(most recent 5 days ago)?

I notice the wiki still says the import is on hold.

Thanks,
--Jarek

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

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

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

Re: [Talk-ca] Building import in BC and Quebec

2019-03-15 Thread Pierre Béland via Talk-ca

Réponse immédiate avec refus de discussion de la part de DannyMcD_imports. 
Celui-ci indique qu'il prévoit continuer l'import.voir 
https://www.openstreetmap.org/changeset/67686901
| 
There was a discussion, issues were raised, the problems (to the extent that 
they existed at all) have been addressed. I plan to continue importing, unless 
a *specific* valid issue is raised. Please do not contact me again unless you 
have such an issue.
 |


La prochaine étape est je pense de contacter le Data Working Group.
 
Pierre 
 

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

Re: [Talk-ca] Building import in BC and Quebec

2019-03-15 Thread Pierre Béland via Talk-ca

Bonjour Jarek
Ce n'est malheureusement pas le seul contributeur qui agit ainsi.  J'estime en 
divisant (Objets/5) que depuis le 1er février, 6 contributeurs ont importé près 
de 1 million de bâtiments. Selon les commentaires, 5 provinces ont été 
couvertes. Cette information est parfois inexacte. Un fichier json des bbox de 
chaque changeset nous fournirait une information plus précise.Voir par exemple 
https://www.openstreetmap.org/changeset/67725913 
J'ai joint ci-dessous un tableau sommaire et la liste des changesets par 
contributeur.

Nous faisons face à un import massif. Ce ne sont pas des débutants qui font ces 
imports et ces contributeurs doivent justifier leurs actions depuis le début 
février et expliquer la méthode suivie pour corriger les données. 
Je viens juste d'aviser chacun de ces contributeurs de cesser les imports et 
venir en discuter sur la liste.
https://www.openstreetmap.org/changeset/67725913
https://www.openstreetmap.org/changeset/68043362
https://www.openstreetmap.org/changeset/68112880
https://www.openstreetmap.org/changeset/67956418
https://www.openstreetmap.org/changeset/67686901
https://www.openstreetmap.org/changeset/68131003

    Imports Statcan depuis le 1er février - Nombre d'objets par 
province

| 
 | OSM Uiid | 
 | 
 | 
 | 
 | 
 | 
 |
| Province | 215433 | 1919010 | 5214232 | 5323321 | 9266764 | 9444677 | Total |
| Alberta | 152 033 | 
 | 
 | 474 276 | 
 | 586 403 | 1 212 712 |
| BC | 44 115 | 
 | 
 | 1 833 617 | 
 | 506 552 | 2 384 284 |
| New Brunswick | 389 750 | 
 | 
 | 
 | 
 | 
 | 389 750 |
| Ontario | 
 | 2 758 | 
 | 
 | 470 608 | 
 | 473 366 |
| Québec | 297 444 | 
 | 110 484 | 753 | 
 | 
 | 408 681 |
| Total | 883 342 | 2 758 | 110 484 | 2 308 646 | 470 608 | 1 092 955 | 4 868 
793 |


Liste des changesets par contributeurUid 215433 Alberta 67665215, 67665288, 
67665341, 67665453, 67665483, 67665545, 67665602, 67665808, 67665875, 67666001, 
67666180, 67669204, 67669252, 67669308, 67669354, 67669452, 67669522, 67669613, 
67670220, 67670247, 67670273, 67670311, 67670349, 67670387, 67670421, 67670458, 
67670536, 67670908, 67670939BC 67508204, 67508256, 67508291, 67508458, 
67508490, 67508513, 67508622, 67508649, 67508697New Brunswick 67507944, 
67508112, 67508134, 67530245, 67530288, 67530337, 67530387, 67530430, 67530474, 
67530523, 67530791, 67530835, 67531044, 67531220, 67531330, 67531597, 67531938, 
67532009, 67532116, 67532730, 67532743, 67569125, 67569223, 67569803, 67569881, 
67569899, 67569919, 67569960, 67602916, 67603189, 67603261, 67603269, 67603307, 
67603335, 67603367, 67603432, 67603554, 67603678, 67603804, 67604023, 67604270, 
67604320, 6779, 67700103, 67700186, 67700343, 67701266, 67701566, 67704840, 
67704865, 67704907, 67705047, 67705069, 67705120, 67705156, 67705204, 67705284, 
67705553, 67705562, 67705602, 67705662, 67705703, 67705762, 67705815, 67705920, 
67705931, 67706273, 67706329, 67706346, 67706464, 67706503, 67706521, 67719310, 
67719682, 67720148, 67720387, 67720605, 67720722, 67720888, 67720980, 67721152, 
67721270, 67723337, 67724221, 67724317, 67724413, 67724441, 67724618, 67724667, 
67724722, 67724746, 67724785, 67724876, 67724959, 67725077, 67725194, 67725830, 
67725849, 67725878, 67725913, 67725961, 67787993Québec 67498534, 67498609, 
67498689, 67498757, 67498912, 67505394, 67505479, 67505545, 67505558, 67505578, 
67505614, 67505972, 67506005, 67506059, 67506089, 67506346, 67506485, 67506686, 
67506719, 67506875, 67506907, 67506934, 67506947, 67506976, 67507006, 67507027, 
67507041, 67507049, 67507068, 67507105, 67507117, 67507136, 67507160, 67507175, 
67507185, 67507195, 67507202, 67507216, 67507260, 67507285, 67507297, 67507312, 
67507320, 67507331, 67507344, 67507355, 67507356, 67507363, 67520439, 67520589, 
67521376, 67521445, 67521517, 67522086, 67522182, 67523774, 67523861, 67523987, 
67524091, 67524121, 67524132, 67524260, 67524661, 67524728, 67524805, 67525070, 
67525203, 67525335, 67525528, 67526340, 67526436, 67526514, 67526916, 67527123, 
67527293, 67527489, 67527970, 67528040, 67528316, 67528511, 67528581, 67528645, 
67528686, 67528728, 67528787, 67528860, 67528901, 67528967, 67529024, 67529042, 
67529077, 67529173, 67529225, 67529262, 67529307, 67529347, 67529374, 67529413
Uid 1919010 Ontario 68042707, 68042895, 68043362, 68043390, 68043779, 68043921, 
68044088
Uid 5214232 Québec 67957273, 67957348, 67957729, 67958923, 67959011, 67986700, 
67986777, 68069537, 68069649, 68078450, 68078523, 68112014, 68112112, 
68112880Uid 5323321 Alberta 66858409, 66858508, 66858697, 66931104, 66931208, 
66931808, 66932459, 66937105, 66944951, 66945388, 66945814, 66945894, 66946017, 
66946173, 66946358, 66960875, 66961117, 66961283, 66961447, 66962026, 66962184, 
66963495, 66963589, 67022393, 67033345, 67033434, 67033507, 67037604, 67037672, 
67037926, 67038133, 67046475, 67046558, 67046687, 67047191, 67047267, 67047343, 
67047419, 67048115, 67048188, 67048931, 67048997, 67049058, 67049627, 67050230, 
67050277,

Re: [Talk-ca] Building import in BC and Quebec

If the local mappers in Alberta or BC feel the data quality is not good 
enough then I think it is up to them to take action but I think it 
really is up to the local mapping community and defining them is 
difficult sometimes.  Also remember agreements within the local 
community are not always electronic in nature.


This is not as simple and clear cut as one might like.

Cheerio John

Jarek Piórkowski wrote on 2019-03-15 8:28 AM:

IMO the huron/hamptonavemapper import is quite clearly in active
disagreement with the import suspension - while I could believe that
one user could overlook clicking on the wiki link in their changeset
messages just once and seeing the bold "on hold", setting up a brand
new similarly named account on February 15, 2019 and immediately
starting to import suggests they know what they're doing. And it's not
like one ultimately _needs_ the tasking manager to insert the data.

The question is what are we going to do about it? Are you going to
speak for Alberta and BC in opposing this import, Nate? That's
defensible but also debatable.

--Jarek

On Thu, 14 Mar 2019 at 21:12, Nate Wessel  wrote:

I would suggest, again, that the tasking manager for this import be locked or 
taken down if that is not possible. One good way to stop people from importing 
when we don't have consensus is to not make it so easy for them. Indeed, I 
would find it plausible if these people said they didn't even know the import 
was paused - their evidence: that the tasking manager is still active!

Best,

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

On 3/14/19 7:42 PM, Jarek Piórkowski wrote:

The changeset comment messages link to the Stats Canada import plan on
the OSM wiki.

I missed it but there were also some edits in Alberta. Quebec edits I
saw were only a couple, outside of Quebec.

http://tasks.osmcanada.ca/project/148 has also been updated, and the
Alberta tasks.

It does raise the point that with a country this large, with editor
community this sparse, there are very few ways to enforce or police a
countrywide consensus, or even arrive at one. Maybe BC mappers like
the import, square angles or no? (Does anyone go to the Metrotown
Meetup?)

--Jarek

On Thu, 14 Mar 2019 at 19:36, john whelan  wrote:

Wicked lad importing without an import plan?

Ask him nicely where the import plan for their imports is.

Looks like a new mapper so may not know the rules.

I think currently there are two sets of data that are licensed for import, the 
Stats Can stuff and the Microsoft stuff.  I haven't seen any import plan for 
the Microsoft stuff but unfortunately it's probably fairly easy to import on 
the Stats Can side my feeling is we need to work out who the locals are to get 
buy in since Canada wide there is no consensus on what is acceptable.  After a 
request from a local group then I think that particular area can proceed.

Quebec I think is being organised by Tim.

Thanks John

On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:

Are people aware that there are buildings being imported by
https://www.openstreetmap.org/user/huronavemapper (most recent 12
hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
(most recent 5 days ago)?

I notice the wiki still says the import is on hold.

Thanks,
--Jarek

___
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


--
Sent from Postbox 

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

Re: [Talk-ca] Building import in BC and Quebec

2019-03-15 Thread Jarek Piórkowski

IMO the huron/hamptonavemapper import is quite clearly in active
disagreement with the import suspension - while I could believe that
one user could overlook clicking on the wiki link in their changeset
messages just once and seeing the bold "on hold", setting up a brand
new similarly named account on February 15, 2019 and immediately
starting to import suggests they know what they're doing. And it's not
like one ultimately _needs_ the tasking manager to insert the data.

The question is what are we going to do about it? Are you going to
speak for Alberta and BC in opposing this import, Nate? That's
defensible but also debatable.

--Jarek

On Thu, 14 Mar 2019 at 21:12, Nate Wessel  wrote:
>
> I would suggest, again, that the tasking manager for this import be locked or 
> taken down if that is not possible. One good way to stop people from 
> importing when we don't have consensus is to not make it so easy for them. 
> Indeed, I would find it plausible if these people said they didn't even know 
> the import was paused - their evidence: that the tasking manager is still 
> active!
>
> Best,
>
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com
>
> On 3/14/19 7:42 PM, Jarek Piórkowski wrote:
>
> The changeset comment messages link to the Stats Canada import plan on
> the OSM wiki.
>
> I missed it but there were also some edits in Alberta. Quebec edits I
> saw were only a couple, outside of Quebec.
>
> http://tasks.osmcanada.ca/project/148 has also been updated, and the
> Alberta tasks.
>
> It does raise the point that with a country this large, with editor
> community this sparse, there are very few ways to enforce or police a
> countrywide consensus, or even arrive at one. Maybe BC mappers like
> the import, square angles or no? (Does anyone go to the Metrotown
> Meetup?)
>
> --Jarek
>
> On Thu, 14 Mar 2019 at 19:36, john whelan  wrote:
>
> Wicked lad importing without an import plan?
>
> Ask him nicely where the import plan for their imports is.
>
> Looks like a new mapper so may not know the rules.
>
> I think currently there are two sets of data that are licensed for import, 
> the Stats Can stuff and the Microsoft stuff.  I haven't seen any import plan 
> for the Microsoft stuff but unfortunately it's probably fairly easy to import 
> on the Stats Can side my feeling is we need to work out who the locals are to 
> get buy in since Canada wide there is no consensus on what is acceptable.  
> After a request from a local group then I think that particular area can 
> proceed.
>
> Quebec I think is being organised by Tim.
>
> Thanks John
>
> On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:
>
> Are people aware that there are buildings being imported by
> https://www.openstreetmap.org/user/huronavemapper (most recent 12
> hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
> (most recent 5 days ago)?
>
> I notice the wiki still says the import is on hold.
>
> Thanks,
> --Jarek
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca

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

Re: [Talk-ca] Building import in BC and Quebec

2019-03-14 Thread Nate Wessel

I would suggest, again, that the tasking manager for this import be 
locked or taken down if that is not possible. One good way to stop 
people from importing when we don't have consensus is to not make it so 
easy for them. Indeed, I would find it plausible if these people said 
they didn't even know the import was paused - their evidence: that the 
tasking manager is still active!


Best,

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

On 3/14/19 7:42 PM, Jarek Piórkowski wrote:

The changeset comment messages link to the Stats Canada import plan on
the OSM wiki.

I missed it but there were also some edits in Alberta. Quebec edits I
saw were only a couple, outside of Quebec.

http://tasks.osmcanada.ca/project/148 has also been updated, and the
Alberta tasks.

It does raise the point that with a country this large, with editor
community this sparse, there are very few ways to enforce or police a
countrywide consensus, or even arrive at one. Maybe BC mappers like
the import, square angles or no? (Does anyone go to the Metrotown
Meetup?)

--Jarek

On Thu, 14 Mar 2019 at 19:36, john whelan  wrote:

Wicked lad importing without an import plan?

Ask him nicely where the import plan for their imports is.

Looks like a new mapper so may not know the rules.

I think currently there are two sets of data that are licensed for import, the 
Stats Can stuff and the Microsoft stuff.  I haven't seen any import plan for 
the Microsoft stuff but unfortunately it's probably fairly easy to import on 
the Stats Can side my feeling is we need to work out who the locals are to get 
buy in since Canada wide there is no consensus on what is acceptable.  After a 
request from a local group then I think that particular area can proceed.

Quebec I think is being organised by Tim.

Thanks John

On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:

Are people aware that there are buildings being imported by
https://www.openstreetmap.org/user/huronavemapper (most recent 12
hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
(most recent 5 days ago)?

I notice the wiki still says the import is on hold.

Thanks,
--Jarek

___
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 in BC and Quebec

2019-03-14 Thread Jarek Piórkowski

The changeset comment messages link to the Stats Canada import plan on
the OSM wiki.

I missed it but there were also some edits in Alberta. Quebec edits I
saw were only a couple, outside of Quebec.

http://tasks.osmcanada.ca/project/148 has also been updated, and the
Alberta tasks.

It does raise the point that with a country this large, with editor
community this sparse, there are very few ways to enforce or police a
countrywide consensus, or even arrive at one. Maybe BC mappers like
the import, square angles or no? (Does anyone go to the Metrotown
Meetup?)

--Jarek

On Thu, 14 Mar 2019 at 19:36, john whelan  wrote:
>
> Wicked lad importing without an import plan?
>
> Ask him nicely where the import plan for their imports is.
>
> Looks like a new mapper so may not know the rules.
>
> I think currently there are two sets of data that are licensed for import, 
> the Stats Can stuff and the Microsoft stuff.  I haven't seen any import plan 
> for the Microsoft stuff but unfortunately it's probably fairly easy to import 
> on the Stats Can side my feeling is we need to work out who the locals are to 
> get buy in since Canada wide there is no consensus on what is acceptable.  
> After a request from a local group then I think that particular area can 
> proceed.
>
> Quebec I think is being organised by Tim.
>
> Thanks John
>
> On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:
>>
>> Are people aware that there are buildings being imported by
>> https://www.openstreetmap.org/user/huronavemapper (most recent 12
>> hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
>> (most recent 5 days ago)?
>>
>> I notice the wiki still says the import is on hold.
>>
>> Thanks,
>> --Jarek
>>
>> ___
>> 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 in BC and Quebec

2019-03-14 Thread john whelan

Wicked lad importing without an import plan?

Ask him nicely where the import plan for their imports is.

Looks like a new mapper so may not know the rules.

I think currently there are two sets of data that are licensed for import,
the Stats Can stuff and the Microsoft stuff.  I haven't seen any import
plan for the Microsoft stuff but unfortunately it's probably fairly easy to
import on the Stats Can side my feeling is we need to work out who the
locals are to get buy in since Canada wide there is no consensus on what is
acceptable.  After a request from a local group then I think that
particular area can proceed.

Quebec I think is being organised by Tim.

Thanks John

On Thu, 14 Mar 2019 at 18:56, Jarek Piórkowski  wrote:

> Are people aware that there are buildings being imported by
> https://www.openstreetmap.org/user/huronavemapper (most recent 12
> hours ago) and https://www.openstreetmap.org/user/hamptonavemapper
> (most recent 5 days ago)?
>
> I notice the wiki still says the import is on hold.
>
> Thanks,
> --Jarek
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import update

2019-02-04 Thread 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

2019-02-04 Thread 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

2019-02-04 Thread 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 / 
corrig

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

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

Re: [Talk-ca] Building Import update

2019-02-03 Thread OSM Volunteer stevea

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

SteveA

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

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

Re: [Talk-ca] Building Import update

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

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

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

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

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

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

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

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

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

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

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

Am I missing something apart from my sanity?

Thanks John

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

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

Re: [Talk-ca] Building Import update

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

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

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

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

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

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

Thanks John
  


  

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

Re: [Talk-ca] Building Import update

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

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

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

Thanks John

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

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

Re: [Talk-ca] Building Import update

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

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

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

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

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


 


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

Re: [Talk-ca] Building Import update

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

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

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

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

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

Cheerio John

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

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

Re: [Talk-ca] Building Import update

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

Cheerio John

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

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

Re: [Talk-ca] Building Import update

2019-02-03 Thread OSM Volunteer stevea

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

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

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

SteveA

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


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

Re: [Talk-ca] Building Import update

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

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

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


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

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

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

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

Re: [Talk-ca] Building Import update

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

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

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

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

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

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

 Pierre 
 

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

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


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

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

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

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

Pierre 
 

173

Re: [Talk-ca] Building Import update

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

Cheerio John

Imports

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

   by *Worst of OSM*.


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

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

Re: [Talk-ca] Building Import update

2019-02-02 Thread Nate Wessel

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


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


Best,

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

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


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


DannyMcD

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

Re: [Talk-ca] Building Import update

2019-02-02 Thread Danny McDonald

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

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

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

Re: [Talk-ca] Building Import update

2019-02-01 Thread OSM Volunteer stevea

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

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

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

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

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

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

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

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

Re: [Talk-ca] Building Import update

2019-02-01 Thread john whelan

So how would you tackle it?

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

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

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

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

Suggestions please

Thanks

Cheerio John

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

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

Re: [Talk-ca] Building Import update

2019-02-01 Thread Begin Daniel

+1

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

John,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheerio John

___

Talk-ca mailing list

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

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

Re: [Talk-ca] Building Import update

2019-02-01 Thread Nate Wessel


John,

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


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


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

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


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


Cheers,

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

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

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

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

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

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


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



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


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


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


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


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


Cheerio John




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

Re: [Talk-ca] Building Import update

2019-02-01 Thread john whelan

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

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

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

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

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

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

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

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

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

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

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

Re: [Talk-ca] Building Import update

2019-01-31 Thread OSM Volunteer stevea

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

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

> and it has almost become a map user expectation.

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

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

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

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

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

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

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

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

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

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

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

Re: [Talk-ca] Building Import update

2019-01-31 Thread john whelan

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

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

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

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

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

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

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

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

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

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

Cheerio John

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

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

Re: [Talk-ca] Building Import update

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

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

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

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

Pierre 
 

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

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





-

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

Suggestions
Thanks
Cheerio John

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

Re: [Talk-ca] Building Import update

2019-01-28 Thread Yaro Shkvorets

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




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

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

Re: [Talk-ca] Building Import update

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

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

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

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

 
Pierre 
 

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

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

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

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

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

Re: [Talk-ca] Building Import update

2019-01-28 Thread Yaro Shkvorets

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

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

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


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

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

Re: [Talk-ca] Building Import update

2019-01-28 Thread Nate Wessel


Hi all,

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


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

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


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


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


Best,

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

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

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

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


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


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


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


Could you run the analysis over Ottawa?

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


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


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


Dunno (Do not know for translate tools.)

What is the ideal building outline in OpenStreetMap?

What is an acceptable building outline in OpenStreetMap?

Suggestions

Thanks

Cheerio John

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


Bonjour John

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

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

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

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

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

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

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

Re: [Talk-ca] Building Import update

2019-01-28 Thread john whelan

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

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

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

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

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

Could you run the analysis over Ottawa?

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

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

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

Dunno (Do not know for translate tools.)

What is the ideal building outline in OpenStreetMap?

What is an acceptable building outline in OpenStreetMap?

Suggestions

Thanks

Cheerio John

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

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

Re: [Talk-ca] Building Import update

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

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

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

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

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


Pierre 
 

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

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

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

Re: [Talk-ca] Building Import update

2019-01-27 Thread john whelan

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

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

Are we expecting too high a standard?

Cheerio John

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

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

Re: [Talk-ca] Building Import update

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

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

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


 
Pierre 
 

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

Re: [Talk-ca] Building Import update

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

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


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

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

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

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

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

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

 id nb_angles    forme   type angle angles

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

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

Pierre 

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

Re: [Talk-ca] Building Import update


James,

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


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


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


Best,

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

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


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


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

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

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

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

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

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

Does that preserve topology between buildings that share nodes?

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

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

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

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

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

Hi all,

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

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

These are the big issues I see remaining:

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

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

Re: [Talk-ca] Building Import update

2019-01-26 Thread James

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

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

Re: [Talk-ca] Building Import update

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


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

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

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


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


Does that preserve topology between buildings that share nodes?

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

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

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

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

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

Hi all,

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

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

These are the big issues I see remaining:

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

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

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

Re: [Talk-ca] Building Import update

2019-01-26 Thread OSM Volunteer stevea

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

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

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

Re: [Talk-ca] Building Import update

2019-01-26 Thread James

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

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

Re: [Talk-ca] Building Import update


Does that preserve topology between buildings that share nodes?

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

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


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


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


Hi all,

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

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

These are the big issues I see remaining:

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

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

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

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

Re: [Talk-ca] Building Import update

2019-01-26 Thread James

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

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

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

Re: [Talk-ca] Building Import update