<html><head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

</head><body style="font-family: Verdana; font-size: 12pt;" 

bgcolor="#FFFFFF" text="#000000"><div style="font-size: 

12pt;font-family: Verdana;">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.<br><br>Cheerio John<br><br><span>Tim Elrick wrote on 2019-03-26 

9:33 PM:</span><br><blockquote type="cite" 

cite="mid:6e73d556-a8c2-e235-7374-e577542a1236@elrick.de">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].

<br>

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

<br>

<br>Tim

<br>

<br>[1] <a class="moz-txt-link-freetext" href="https://imgur.com/a/aCKMVb7">https://imgur.com/a/aCKMVb7</a>

<br>

<br>On 2019-03-26 13:45, Jarek Piórkowski wrote:

<br>On Tue, 26 Mar 2019 at 13:10, Begin Daniel 

<a class="moz-txt-link-rfc2396E" href="mailto:jfd553@hotmail.com"><jfd553@hotmail.com></a> wrote:

<br><blockquote type="cite">There is actually no standard “code” 

available since I use FME (<a class="moz-txt-link-abbreviated" href="http://www.safe.com">www.safe.com</a>). It is a proprietary ETL 

application and all operations are done using “transformers” 

(<a class="moz-txt-link-freetext" href="https://www.safe.com/transformers/">https://www.safe.com/transformers/</a>). 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.

<br>

<br>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 ;-)

<br></blockquote>

Thanks Daniel. Let me know how it looks then!

<br>

<br>Coming from an open-source background, the process is unusual to me,

<br>and I have questions about scalability - will you be able to process

<br>and provide updated data files for all of Canada then? - but if 

others

are comfortable with it then I won't object.

<br>

<br>Some general thoughts regarding tooling as raised upthread:

<br>

<br>I was initially excited to see building footprints data as they help

<br>two quite distinct purposes:

<br>

<br>1. they provide a mostly-automatic source of geometries for the

<br>millions of single-family houses that wouldn't be mapped in the next

<br>decade otherwise

<br>

<br>2. they might provide a corrected and fairly accurate source of

<br>geometries in heavily-built-up areas, where GPS signal is not that

<br>reliable and it can be really difficult to get sufficiently accurate

<br>geometries from imagery, whether because it's not sufficiently

<br>high-resolution, two sets of imagery with conflicting offsets (Bing

<br>and Esri are the two best sets in Toronto, and they're off by about

<br>1-2 m on north-south axis from each other - that's not something I 

can

<br>check with a consumer-grade GPS so I'm left guessing as to which is

<br>true), or non-vertical imagery (I can count the floors on supposedly

top-down imagery in some cases).

<br>

<br> From what I saw, imports in the GTHA initially focused on the first

<br>case, and I think the Tasking Manager setup was mostly sufficient 

for

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

<br>

<br>However, as raised by others, I would really want the working 

squares

<br>in Old Toronto for example to be no more than 500 m x 500 m, or no

<br>more than 1 km x 1 km in St. Catharines. I would _love_ to have the

<br>geometries to manually compare and adjust the 3D buildings already

existing in the area, but it will be much slower.

<br>

<br>--Jarek

<br>

<br>_______________________________________________

<br>Talk-ca mailing list

<br><a class="moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org">Talk-ca@openstreetmap.org</a>

<br><a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-ca">https://lists.openstreetmap.org/listinfo/talk-ca</a>

<br>

<br>

<br>

<br>_______________________________________________

<br>Talk-ca mailing list

<br><a class="moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org">Talk-ca@openstreetmap.org</a>

<br><a class="moz-txt-link-freetext" href="https://lists.openstreetmap.org/listinfo/talk-ca">https://lists.openstreetmap.org/listinfo/talk-ca</a>

<br></blockquote><br><div class="moz-signature">-- <br>

<div>Sent from <a 

href="https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach"><span

 style="color: rgb(0, 157, 247);">Postbox</span></a></div></div></div></body></html>