Re: [Talk-ca] Building Import

[OSM Volunteer stevea]

Ah, good dialog ensues.  Municipality by municipality, in conjunction with BOTH 
the StatsCan and Bing data, the right things are getting noticed, the right 
things are getting human-realized at what the next steps are to do.  It gets 
better.

Yay.  Stitch it together.  One municipality at a time.  One province at a time. 
 Pretty soon, after a few revisions of data and back-and-forths between 
municipalities and province-wide data checking, you've got something.  There, 
you go.

SteveA

> On Mar 27, 2019, at 8:23 PM, keith hartley  wrote:
> 
> The patchwork of municipalities is at least useful, before we didn't have a 
> framework for adding this data, but at least we do now thanks to the umbrella 
> license @ Stats Canada. We're a big country with very few, but very skilled 
> OSM mappers (IE gecho111 mapped all of regina's building footprints! ).
> 
> I like the concept of the Bing data, but they may have to do another few 
> tries, or maybe retain their Neural network. - Is there anywhere where the 
> Bing data looks nice? I found burbs in Winnipeg not bad, but there's some 
> really weird elements when the source data is too simple (buildings in the 
> middle of fields) or too complex (urban cores) 
> 
> On Wed, Mar 27, 2019 at 6:29 AM John Whelan  wrote:
> The Stats Canada data comes from the municipalities.  Unfortunately there are 
> over 3,000 in Canada so yes ideally each would be treated separately in 
> reality each municipality doesn't have a group of skilled OSM mappers who are 
> capable of setting up an import plan and doing the work although there is 
> nothing to stop them doing so.
> 
> Cheerio John


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

Re: [Talk-ca] Building Import

[keith hartley]

The patchwork of municipalities is at least useful, before we didn't have a
framework for adding this data, but at least we do now thanks to the
umbrella license @ Stats Canada. We're a big country with very few, but
very skilled OSM mappers (IE gecho111
 mapped all of regina's
building footprints! ).

I like the concept of the Bing data, but they may have to do another few
tries, or maybe retain their Neural network. - Is there anywhere where the
Bing data looks nice? I found burbs in Winnipeg not bad, but there's some
really weird elements when the source data is too simple (buildings in the
middle of fields) or too complex (urban cores)

On Wed, Mar 27, 2019 at 6:29 AM John Whelan  wrote:

> The Stats Canada data comes from the municipalities.  Unfortunately there
> are over 3,000 in Canada so yes ideally each would be treated separately in
> reality each municipality doesn't have a group of skilled OSM mappers who
> are capable of setting up an import plan and doing the work although there
> is nothing to stop them doing so.
>
> Cheerio John
>
> keith hartley wrote on 2019-03-27 12:00 AM:
>
> Hi All,
> I like the idea of imports, and think there's a lot of value of batch
> importing - however we need to run a QA/AC for each. For Manitoba I think
> the challenge is getting municipalities to sign on, and move their data to
> the canadian open data portal (that is, if they have data or any
> geo-spatial information to give ) some information is on the provincial
> level, but most of that has already been added to OSM (IE Brandon, Selkirk)
> or have been built.
>
> Reviewing some of the Microsoft data, I see a lot of quirks! - IF using it
> it's handy to identify buildings, but would REALLY have to watch and review
> if importing any of it to osm. I'm not sure about the rest of canada, but
> there's "swamp buildings" that some of my collegues have dubbed 1/3 mile
> polygons in a featureless field.  Some of the more complex downtown
> buildings seem pretty broken, but the data does seem to be decent at
> covering suburban areas.
>
> TL/DR version:
>
> I'd be comfortable importing muni stuff (dependent on quality) , but the
> Bing footprints would have to be reviewed, nearly on a building by building
> level.
>
> Keith
>
> On Tue, Mar 26, 2019 at 4:24 PM john whelan  wrote:
>
>> At least it is an indication of interest.
>>
>> Thanks John
>>
>> On Tue, Mar 26, 2019, 4:57 PM Darren Wiebe,  wrote:
>>
>>> I'm from rural Alberta close to Lloydminster.  The building import is
>>> something that interests me and would be useful in my area but I haven't
>>> been very actively mapping over the last year or two.  Hopefully there are
>>> Alberta mappers on here who are much more active than I have been.
>>>
>>> Darren Wiebe
>>>
>>> On Tue, Mar 26, 2019 at 2:04 PM John Whelan 
>>> wrote:
>>>
 I think my concerns are to do with the "black box" approach.  Knowing
 your background I trust your work but others might not.

 On a technical side I get the impression that cites with buildings that
 are close to each other are problematical.  I assume that small locations
 with a population of say under 125,000 this is an insignificant problem?

 The other issue is I'd like to either see buy in from Nate or at least
 some Toronto mappers to get an indication that something will happen at the
 end of the day as it is a fair chunk of Daniel's time to work out how do
 the preprocessing.

 I think some BC mappers expressed some doubts as well so perhaps they
 would like to think about if they are happy or would prefer BC to be
 outside of the import project and express their views.

 Out of interest if it does move ahead are we including the Microsoft
 data for areas where we do not have data from Stats Canada?  If so we will
 need to amend the project plan.

 My personal view is realistically I think having building information
 even if its a meter or two out is better than not having the building
 outlines.

 What would be nice is if we could have some indication from places such
 as Manitoba, Alberta, Saskatchewan, Quebec excluding Montreal, Ontario
 excluding Toronto and the other provinces and territories whether they are
 happy with importing the buildings either from Stats or Microsoft.

 I seem to recall Keith is in Manitoba, so any views other than it
 wasn't present in the first release from Stats?

 Note to Alessandro this is just background stuff.

 Thanks

 Cheerio John

 Begin Daniel wrote on 2019-03-26 3:29 PM:

 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 

Re: [Talk-ca] Building Import

[Tim Elrick]

D'accord. Attendons que Daniel ait fini de peaufiner le pré-traitement. 
Ensuite, nous pouvons voir comment nous pouvons réaliser cela en open 
source. Je connais pas mal de R et de plus en plus de PostGIS. Bien sûr, 
tout le monde sera le bienvenu.


Tim

On 2019-03-27 16:13, Begin Daniel wrote:
Tim pose une question réaliste...
Qu’est-ce qui se passe si un jour OSM ne m’intéresse plus ?

J’utilise FME parce que le développement se fait de façon 100 fois plus 
rapide pour tester des idées (je n’aime pas la programmation standard - 
je fais trop d’erreurs d’inattention dans les détails ;-)


Alors, une fois que le processus sera mis au point sur FME, ça me fera 
plaisir d’en décomposer chaque étape avec vous et de rendre le tout 
public. On pourra faire ça hors liste :-)


Daniel

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de]
Sent: Wednesday, March 27, 2019 10:33
To: Pierre Béland; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

Bonjour Pierre, Daniel, John et tous,

Je ne doute pas de l'expertise de Daniel. Il n'y a rien de mal à
utiliser des outils propriétaires lors de l'utilisation des données OSM.
Cependant, lors de la création des données OSM, nous devons viser le
processus le plus transparent possible (comme indiqué sur la question de
l'importation si souvent sur cette liste). D'après ce que j'ai vu,
l'outil et la chaîne de processus de Daniel fonctionnent très bien. Et
je suis heureux qu'il contribue son temps et ses idées sur l'importation
de bâtiments. Mais si Daniel n'est plus là ? Ou nous voulons importer ou
même nettoyer des données existantes qui ne l'intéressent pas ? Je me
souviens juste du sort des beaux outils d'histoire de l'OSM de Peter
(MazderMind) [1] créés il y a quelques années, mais qu'il ne pouvait
plus maintenir pour des raisons inconnues de moi. Dans son cas, ce n'est
pas mal car tout est documenté sur github.

Donc, je pense que ce serait bien si nous pouvions traduire les
algorithmes que Daniel utilise (avec les documents dans le wiki) en un
outil open source. Cela ne veut pas dire que Daniel doit arrêter ce
qu'il fait.

Daniel, ce serait bien si toi et moi (et Pierre?) pouvions faire un
exposé sur la façon d'y arriver - hors liste car je pense que le grain
de sable n'est pas d'intérêt pour la liste - bien sûr, nous le
documenterons plus tard dans le wiki.

Qu'est-ce que vous en pensez ?

Tim

[1]
https://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps

On 2019-03-26 23:08, Pierre Béland wrote:
Cette discussion sur gis.stackexchange donne le lien vers OpenCarto sur
Sourceforge et vers un document décrivant la méthode.
https://gis.stackexchange.com/questions/25263/is-there-any-open-source-building-squaring-tool

Avec les fonctions PostGIS, à voir comment ST_ShortestLine ou fonction
similaire permettrait de réviser les coordonnées de chaque point du
polygone.
http://postgis.net/docs/ST_ShortestLine.html

Pierre





Le mardi 26 mars 2019 21 h 49 min 17 s HAE, Pierre Béland via Talk-ca
 a écrit :


Bonjour Tim

Mon outil d'analyse Qualité dont les données sont publiées sur
OpenDataLabRDC est basé sur PostgreSQL-Postgis.   Je suis à nettoyer /
documenter le code et prévoit le publier sur github.  J'ai commencé à
regarder les outils possibles, mais peu de documentation disponible. On
parle par exemple de OpenCarto, mais l'info n'est plus disponible. A
voir si possible à l'aide de Grass.
https://gis.stackexchange.com/questions/15612/is-it-possible-to-simplify-orthogonal-polygons-with-opencarto-java-library


Pierre

___
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

[Begin Daniel]

Tim pose une question réaliste...
Qu’est-ce qui se passe si un jour OSM ne m’intéresse plus ?

J’utilise FME parce que le développement se fait de façon 100 fois plus rapide 
pour tester des idées (je n’aime pas la programmation standard - je fais trop 
d’erreurs d’inattention dans les détails ;-)

Alors, une fois que le processus sera mis au point sur FME, ça me fera plaisir 
d’en décomposer chaque étape avec vous et de rendre le tout public. On pourra 
faire ça hors liste :-)

Daniel

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de] 
Sent: Wednesday, March 27, 2019 10:33
To: Pierre Béland; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

Bonjour Pierre, Daniel, John et tous,

Je ne doute pas de l'expertise de Daniel. Il n'y a rien de mal à 
utiliser des outils propriétaires lors de l'utilisation des données OSM. 
Cependant, lors de la création des données OSM, nous devons viser le 
processus le plus transparent possible (comme indiqué sur la question de 
l'importation si souvent sur cette liste). D'après ce que j'ai vu, 
l'outil et la chaîne de processus de Daniel fonctionnent très bien. Et 
je suis heureux qu'il contribue son temps et ses idées sur l'importation 
de bâtiments. Mais si Daniel n'est plus là ? Ou nous voulons importer ou 
même nettoyer des données existantes qui ne l'intéressent pas ? Je me 
souviens juste du sort des beaux outils d'histoire de l'OSM de Peter 
(MazderMind) [1] créés il y a quelques années, mais qu'il ne pouvait 
plus maintenir pour des raisons inconnues de moi. Dans son cas, ce n'est 
pas mal car tout est documenté sur github.

Donc, je pense que ce serait bien si nous pouvions traduire les 
algorithmes que Daniel utilise (avec les documents dans le wiki) en un 
outil open source. Cela ne veut pas dire que Daniel doit arrêter ce 
qu'il fait.

Daniel, ce serait bien si toi et moi (et Pierre?) pouvions faire un 
exposé sur la façon d'y arriver - hors liste car je pense que le grain 
de sable n'est pas d'intérêt pour la liste - bien sûr, nous le 
documenterons plus tard dans le wiki.

Qu'est-ce que vous en pensez ?

Tim

[1] 
https://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps

On 2019-03-26 23:08, Pierre Béland wrote:
Cette discussion sur gis.stackexchange donne le lien vers OpenCarto sur
Sourceforge et vers un document décrivant la méthode.
https://gis.stackexchange.com/questions/25263/is-there-any-open-source-building-squaring-tool

Avec les fonctions PostGIS, à voir comment ST_ShortestLine ou fonction
similaire permettrait de réviser les coordonnées de chaque point du
polygone.
http://postgis.net/docs/ST_ShortestLine.html

Pierre





Le mardi 26 mars 2019 21 h 49 min 17 s HAE, Pierre Béland via Talk-ca
 a écrit :


Bonjour Tim

Mon outil d'analyse Qualité dont les données sont publiées sur
OpenDataLabRDC est basé sur PostgreSQL-Postgis.   Je suis à nettoyer /
documenter le code et prévoit le publier sur github.  J'ai commencé à
regarder les outils possibles, mais peu de documentation disponible. On
parle par exemple de OpenCarto, mais l'info n'est plus disponible. A
voir si possible à l'aide de Grass.
https://gis.stackexchange.com/questions/15612/is-it-possible-to-simplify-orthogonal-polygons-with-opencarto-java-library


Pierre

___
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

[Pierre Béland via Talk-ca]

Bonjour Tim
À partir de ce protoype développé par Daniel, il serait intéressant oui 
d'orienter le développement vers un outil OpenSource.  Il me ferait plaisir de 
participer avec toi, Daniel et d'autres si intéressés à développer un tel outil.

De mon côté, je ne suis pas un expert SIG ni en PostGIS mais maitrise bien la 
chaine de données Import Osmosis, et les traitements PostgreSQL/PostGIS. 
Pierre 
 

Le mercredi 27 mars 2019 10 h 33 min 09 s HAE, Tim Elrick  
a écrit :  
 
 Bonjour Pierre, Daniel, John et tous,

Je ne doute pas de l'expertise de Daniel. Il n'y a rien de mal à 
utiliser des outils propriétaires lors de l'utilisation des données OSM. 
Cependant, lors de la création des données OSM, nous devons viser le 
processus le plus transparent possible (comme indiqué sur la question de 
l'importation si souvent sur cette liste). D'après ce que j'ai vu, 
l'outil et la chaîne de processus de Daniel fonctionnent très bien. Et 
je suis heureux qu'il contribue son temps et ses idées sur l'importation 
de bâtiments. Mais si Daniel n'est plus là ? Ou nous voulons importer ou 
même nettoyer des données existantes qui ne l'intéressent pas ? Je me 
souviens juste du sort des beaux outils d'histoire de l'OSM de Peter 
(MazderMind) [1] créés il y a quelques années, mais qu'il ne pouvait 
plus maintenir pour des raisons inconnues de moi. Dans son cas, ce n'est 
pas mal car tout est documenté sur github.

Donc, je pense que ce serait bien si nous pouvions traduire les 
algorithmes que Daniel utilise (avec les documents dans le wiki) en un 
outil open source. Cela ne veut pas dire que Daniel doit arrêter ce 
qu'il fait.

Daniel, ce serait bien si toi et moi (et Pierre?) pouvions faire un 
exposé sur la façon d'y arriver - hors liste car je pense que le grain 
de sable n'est pas d'intérêt pour la liste - bien sûr, nous le 
documenterons plus tard dans le wiki.

Qu'est-ce que vous en pensez ?

Tim

[1] 
https://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps


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

Re: [Talk-ca] Building Import

[Tim Elrick]

Bonjour Pierre, Daniel, John et tous,

Je ne doute pas de l'expertise de Daniel. Il n'y a rien de mal à 
utiliser des outils propriétaires lors de l'utilisation des données OSM. 
Cependant, lors de la création des données OSM, nous devons viser le 
processus le plus transparent possible (comme indiqué sur la question de 
l'importation si souvent sur cette liste). D'après ce que j'ai vu, 
l'outil et la chaîne de processus de Daniel fonctionnent très bien. Et 
je suis heureux qu'il contribue son temps et ses idées sur l'importation 
de bâtiments. Mais si Daniel n'est plus là ? Ou nous voulons importer ou 
même nettoyer des données existantes qui ne l'intéressent pas ? Je me 
souviens juste du sort des beaux outils d'histoire de l'OSM de Peter 
(MazderMind) [1] créés il y a quelques années, mais qu'il ne pouvait 
plus maintenir pour des raisons inconnues de moi. Dans son cas, ce n'est 
pas mal car tout est documenté sur github.


Donc, je pense que ce serait bien si nous pouvions traduire les 
algorithmes que Daniel utilise (avec les documents dans le wiki) en un 
outil open source. Cela ne veut pas dire que Daniel doit arrêter ce 
qu'il fait.


Daniel, ce serait bien si toi et moi (et Pierre?) pouvions faire un 
exposé sur la façon d'y arriver - hors liste car je pense que le grain 
de sable n'est pas d'intérêt pour la liste - bien sûr, nous le 
documenterons plus tard dans le wiki.


Qu'est-ce que vous en pensez ?

Tim

[1] 
https://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps


On 2019-03-26 23:08, Pierre Béland wrote:
Cette discussion sur gis.stackexchange donne le lien vers OpenCarto sur
Sourceforge et vers un document décrivant la méthode.
https://gis.stackexchange.com/questions/25263/is-there-any-open-source-building-squaring-tool

Avec les fonctions PostGIS, à voir comment ST_ShortestLine ou fonction
similaire permettrait de réviser les coordonnées de chaque point du
polygone.
http://postgis.net/docs/ST_ShortestLine.html

Pierre





Le mardi 26 mars 2019 21 h 49 min 17 s HAE, Pierre Béland via Talk-ca
 a écrit :


Bonjour Tim

Mon outil d'analyse Qualité dont les données sont publiées sur
OpenDataLabRDC est basé sur PostgreSQL-Postgis.   Je suis à nettoyer /
documenter le code et prévoit le publier sur github.  J'ai commencé à
regarder les outils possibles, mais peu de documentation disponible. On
parle par exemple de OpenCarto, mais l'info n'est plus disponible. A
voir si possible à l'aide de Grass.
https://gis.stackexchange.com/questions/15612/is-it-possible-to-simplify-orthogonal-polygons-with-opencarto-java-library


Pierre

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

Re: [Talk-ca] Building Import

[John Whelan]

We have a history of using CANVEC data and importing that.  Daniel was 
very closely connected to the data.  In Ontario the ESRI tools are used 
in schools but they can be used with openstreetmap as the base map.   
From a practical point of view developing a set of tools or process in 
the open data world would allow others outside Canada to use them 
however Daniel knows his tools very well.


Cheerio John

Tim Elrick wrote on 2019-03-26 9:33 PM:
I sent Daniel a sample of Montreal (Outrement) from the Open Building 
Database and Daniel's algorithm performed really well. It could reduce 
the vertices count by 13% without loosing or even improving data 
quality (as it orthogonalized the buildings). Even difficult buildings 
were treated well [1].


As OSM is mainly built on open source tools, the OSMF tries to work 
with open source tools only and the process should be reproducible (if 
not for this import, then for the next one somewhere else in the OSM 
cosmos), I suggest, we try to resemble Daniel's pre-processing in open 
source software, e.g. PostGreSQL/PostGIS. I already found the code for 
collinearity; the orthogonalization seems to be a bit trickier, but it 
should be possible to built the process in PostGIS as well, if it was 
possible to built it in FME. What do you think?


Tim

[1] https://imgur.com/a/aCKMVb7

On 2019-03-26 13:45, Jarek Piórkowski wrote:
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


--
Sent from Postbox 

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