<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;">If CC-BY 4.0 works great.  I'd go for any 

addresses etc and any bus stops you can get hold of as well.<br><br>Just

 be aware that we had a fairly large number of questions asked about the

 license etc when we did Ottawa and one of the people questioning 

referred the license to the LWG.  Even the basis of CANVEC licensing 

came into question at the time.<br><br>Many of the questions came from 

German and other European mappers.<br><br>I understand the City of 

Toronto's Open Data license was referred as well but that was about two 

years ago and I note that the LWG web site has no mention of it so it is

 probably still in the queue.<br><br>Good Luck<br><br>Cheerio John<br><br><span>Tim

 Elrick wrote on 2019-02-16 12:22 PM:</span><br><blockquote type="cite" 

cite="mid:ff6d6bd3-bf99-a81b-9084-b6f87018803f@elrick.de">Hi John,

<br>

<br>Thanks for pointing me to the license website. The open data of the 

City 

of Montreal is licensed CC-BY 4.0 and the City has explicitly granted 

OSM the right to use the data on top of that. See: 

<a class="moz-txt-link-freetext" href="http://donnees.ville.montreal.qc.ca/portail/licence/">http://donnees.ville.montreal.qc.ca/portail/licence/</a>

<br>

<br>StatsCan's Open Building Database uses exactly the same data source,

however, as I pointed out in my last e-mail, it did not split the 

building blocks into actual buildings. The open data of the City of 

Montreal, furthermore, includes building heights which are lost in the 

OBD. These are the reasons why we would like to import the original open

data.

<br>

<br>Cheers,

<br>Tim

<br>

<br>On 2019-02-16 11:21, john whelan wrote:

<br>When you look at importing Montreal you might like to look at the

following first.

<br>

<br><a class="moz-txt-link-freetext" href="https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants">https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants</a>

<br>

<br>Note if the Montreal data in available through Stats Can and the 

federal

<br>government open data license it might be better to use that data 

source

from a licensing perspective.

<br>

<br>Although data can be given to OpenStreetMap I don't think there in a

<br>foolproof method of recording the fact.  If one person has the paper

<br>record fine but if they are no longer part of the community then 

there

maybe a problem if the license is challenged.

<br>

<br>Cheerio John

<br>

<br>On Sun, 10 Feb 2019 at 00:04, Tim Elrick <<a class="moz-txt-link-abbreviated" href="mailto:osm@elrick.de">osm@elrick.de</a>

<br><a class="moz-txt-link-rfc2396E" href="mailto:osm@elrick.de"><mailto:osm@elrick.de></a>> wrote:

<br>

<br>    Hi all,

<br>

<br>    After following the building import discussion for a while now, I

wanted to chime in as well.

<br>

<br>    After moving to Montréal from Germany recently, I got more 

engaged

<br>    with the local mappers here in MTL (beforehand, I was more 

analysing

OSM data scientifically).

<br>

<br>    I took part in the initial meeting of the Building Canada 2020

<br>    initiative, in which great interest in the project was expressed

 by

<br>    many institutions, organizations and businesses. However, apart 

from

<br>    Statistics Canada, municipalities and OSMappers no one seemed to

 be

<br>    willing to invest into the effort to support the initiative with

<br>    manpower or funding (to my knowledge). Therefore, I found it 

quite

<br>    impressive what StatCan has achieved with the Open Building 

Database

<br>    and do not share the view of some on this list that the 

initiative

<br>    got off on the wrong foot; but that all water under the bridge 

now.

<br>

<br>    So, yes, there seems to be some interest to use the data from 

the

<br>    Open Building Database in OSM easily. However, I am also 

hesitant,

that one massive import can be the answer.

<br>

<br>    I'm generally hesitant with imports as such, maybe because I was

<br>    acculturated in OSM in Germany where OSMappers value original

<br>    entries much more than secondary data. Further, I'm skeptical, 

that

<br>    secondary data is necessary better than original data (even from

<br>    mapathons). I initiated two mapathons with university students 

in

<br>    the context of Building Canada 2020. Both mapathons resulted in

<br>    mostly nice buildings, I would say - and, when there is the odd

<br>    not-so-nice building, there is still the validation step as we

<br>    always used the tasking manager [1]. By the way, both mapathons 

used

<br>    the ID editor; and, of course, you can square buildings in ID as

<br>    well; so, I don't really understand the ID editor bashing that

<br>    appears on this list here now and then. That said, of course, I

<br>    prefer JOSM over ID as it is the more versatile tool, but to

<br>    introduce interested persons to editing in OSM, ID is really 

nice.

<br>

<br>    I'm even more skeptical about imports after Yaro pointed us to 

the

<br>    Texas import [2]. I wonder why there was no outcry there (or 

maybe

<br>    there was and I did not hear about it) - the imported data is

<br>    terrible: no parallel to street buildings, no right angles,

<br>    sometimes even not the right size of building parts. Fact is 

that

<br>    secondary data buildings footprints can be from many different 

data

<br>    sources - from AutoCAD, handdrawn by a municipal GIS experts to

<br>    photogrammetric and satellite machine learning sources; all 

those

<br>    sources have their peculiarities, which I think, you cannot 

satisfy

<br>    in one import plan fits all - especially, as the Open Building

<br>    Database in Canada is stitched together from those very 

different

<br>    sources.

<br>

<br>    In Montreal, e.g., the source for the Open Building Database is 

the

<br>    données ouvertes des batiments. This is photogrammetric imagery

<br>    probably turned into AutoCAD files, which then were exported to a

<br>    shapefile and geojson. The building outlines are impressively

<br>    precise, however, the open data files contain building blocks 

not

<br>    single buildings [3], however, offer building dividers in a 

separate

<br>    shapefile (I assume due to the export from AutoCAD, see second 

image

<br>    in [3]). Unfortunately, the Open Building Database only included

<br>    those building blocks in their data set, making it not very easy

 to

import into OSM (as they do not include the building dividers).

<br>    Hence, a bit of non-trivial pre-processing of the original 

données

<br>    ouvertes des batiments would be necessary to import them into 

OSM

<br>    (as the building divider file does also include roof extensions 

and

<br>    roof shapes). The local OSM group is discussing this 

pre-processing

<br>    for a while now at their local meetings (we started discussing 

this

<br>    even before the Building Canada 2020 initiative started). As the

<br>    City of Montreal has granted OSM the explicit use of their open 

data

<br>    file, the way forward, we think, is to pre-process the original

<br>    files. Further, there is extensive overlap of existing buildings

<br>    with the open data file. Therefore, the imports in Montreal 

would

<br>    have to happen in very small batches to not destroy the work of

<br>    other OSMappers.

<br>

<br>    I am also pretty skeptical about the simplification of the 

secondary

<br>    data before importing that was suggested on the list here. As 

the

<br>    data sources of the Open Building Database are very diverse, one

<br>    simplification method cannot fit all data sources and can lead 

to

<br>    harming the ground-truth principle. This even happened when Nate

<br>    tried to simplify buildings by hand in Toronto [4], as pointed 

out

<br>    by Yaro. There might be the odd case, where secondary data has 

too

<br>    many nodes in a straight line, but, usually, I would assume, 

that

<br>    most data sources stem from GIS experts or machine learning

<br>    algorithms; neither would include more nodes than necessary for a

<br>    building outline. And honestly, I don't buy the argument of 'too

<br>    much data clutters our planet dump'. Storage space and 

processing

<br>    power is no longer an issue, and I would like to see the world 

as

<br>    precisely represented as possible in OSM; in many parts of the 

OSM

<br>    world you now find single trees, mailboxes and lamp posts in 

OSM;

<br>    isn't that great? As for buildings, I would like to see all the 

bay

windows, nooks and crannies - even in Canada.

<br>

<br>    How to proceed? For Montréal: After we looked more into the

<br>    challenges of pre-processing the Montreal open dataset, I guess,

 we

<br>    will propose a separate import plan. If anyone would like to 

join us

<br>    in discussing the pre-processing, please contact me and we can

<br>    continue on the Montréal OSM list. Oh, and by the way, while we 

all

<br>    were discussing the import since December almost 3,000 buildings

were mapped by hand in the Greater Montreal region [5].

<br>

<br>    That all being said, I do not want to stop anyone of you from

<br>    importing buildings. I just think, that we have to do this more 

bit

<br>    by bit to cater for all the peculiarities of the heterogeneous 

data

sources of the Open Building Database.

<br>

<br>    Happy mapping to everyone,

<br>    Tim

<br>

<br>    [1] see e.g. <a class="moz-txt-link-freetext" href="http://tasks.osmcanada.ca/project/91">http://tasks.osmcanada.ca/project/91</a>

<br>    [2] <a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/#map=19/32.97102/-96.78231">https://www.openstreetmap.org/#map=19/32.97102/-96.78231</a>

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

<br>    [4] <a class="moz-txt-link-freetext" href="https://i.imgur.com/H10360K.png">https://i.imgur.com/H10360K.png</a>

<br>    [5] <a class="moz-txt-link-freetext" href="http://overpass-turbo.eu/s/FWH">http://overpass-turbo.eu/s/FWH</a>

<br>

<br>    On 2019-02-03 18:35, Yaro Shkvorets wrote:

<br>    Having reviewed the changeset, here are my 2 cents. OsmCha link 

for

<br>    reference: <a class="moz-txt-link-freetext" href="https://osmcha.mapbox.com/changesets/66881357/">https://osmcha.mapbox.com/changesets/66881357/</a>

<br>

1) IMO squaring is not needed in most of those cases.

<br>    - You can see difference between square and non-square ONLY at 

high

<br>    zoom level. And even then, it's not visible to the naked eye. We

 are

talking about inches here.

<br>    - Sometimes squaring is plain wrong to be applied here. Even 

though

<br>    you paid very close attention you managed to square a couple of

<br>    non-square buildings. Like this facade is not supposed to be 

square

<br>    for example: <a class="moz-txt-link-freetext" href="https://i.imgur.com/H10360K.png">https://i.imgur.com/H10360K.png</a> I might be OK with

<br>    squaring almost-square angles if there is a simple plugin for 

that.

<br>    The way you propose to do it, by going building-by-building and

<br>    pressing Q is completely unsustainable and sometimes makes 

things bad.

<br>    - Another thing, this particular neighbourhood is pretty dense 

and

<br>    mature and therefore has mostly square buildings. I can only 

imagine

<br>    how bad it would become if you ask people to square things in 

newer

developments where buildings often come in irregular shapes.

<br>    - Like mentioned above, many successful import didn't require

<br>    squaring. In this Texas one, 100% of buildings are not perfectly

<br>    square: <a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/#map=19/32.97102/-96.78231">https://www.openstreetmap.org/#map=19/32.97102/-96.78231</a>

<br>

<br>

<br>    2) Simplification is good to have, sure. Obviously standard 

Shift-Y

<br>    in JOSM is a no-starter. If we can find a good way to simplify 

ways

<br>    without losing original geometry and causing overlapping issues 

we

<br>    should do it. But even then, reducing 500MB province extract to

499MB should not be a hill to die on.

<br>

<br>    3) Manually mapping all the sheds and garages is completely

<br>    unsustainable. Having seen over the last couple of years how 

much

<br>    real interest there is in doing actual work importing buildings 

in

<br>    Canada (almost zero) adding this requirement will undoubtedly 

kill

<br>    the project. Sure you will meticulously map your own 

neighbourhood,

<br>    but who will map thousands of other places with the same 

attention

<br>    to details? Also, you did rather poor job at classifying 

buildings

<br>    you add, tagging them all with building=yes. Properly 

classifying

<br>    secondary buildings like sheds and garages in a project like 

this is

<br>    pretty important IMO. I agree with John, we should leave sheds 

to

local mappers to trace manually.

<br>

<br>    To sum up, yes we can do better. But this is the perfect example

when "better" is the enemy of "good".

<br>

<br>    On Sun, Feb 3, 2019 at 12:34 PM Nate Wessel 

<<a class="moz-txt-link-abbreviated" href="mailto:bike756@gmail.com">bike756@gmail.com</a>

<br>    <a class="moz-txt-link-rfc2396E" href="mailto:bike756@gmail.com"><mailto:bike756@gmail.com></a>> wrote:

<br>

<br>        Hi all,

<br>

<br>        I had a chance this morning to work on cleaning up some of 

the

<br>        already-imported data in Toronto. I wanted to be a little

<br>        methodical about this, so I picked a single typical block 

near

<br>        where I live. All the building data on this block came from 

the

<br>        import and I did everything in one changeset:

<br>        <a class="moz-txt-link-freetext" href="https://www.openstreetmap.org/changeset/66881357">https://www.openstreetmap.org/changeset/66881357</a>

<br>

<br>        What I found was that:

<br>

<br>        1) Every single building needed squaring

<br>

2) Most buildings needed at least some simplification.

<br>

<br>        3) 42 buildings were missing.

<br>

<br>        I knew going in that the first two would be an issue, but 

what

<br>        really surprised me was just how many sheds had not been

<br>        imported. There are only 53 houses on the block, but 42

<br>        sheds/garages/outbuildings, some of them quite large, and 

none

of which had been mapped.

<br>

<br>        I haven't seen the quality of the outbuildings in the source

<br>        data, and maybe I would change my mind if I did, but I think

 if

<br>        we're going to do this import properly, we're going to have 

to

<br>        bring in the other half of the data. I had seen in the 

original

<br>        import instructions that small buildings were being excluded

 -

was there a reason for this?

<br>

<br>        I also want to say: given how long it took me to clean up 

and

<br>        properly remap this one block, I'll say again that the size 

of

<br>        the import tasks is way, way, way too large. There is 

absolutely

<br>        no way that someone could have carefully looked at and 

verified

<br>        this data as it was going in. I just spent a half hour 

fixing up

probably about one-hundredth of a task square.

<br>

We can do better than this!

<br>

<br>        --

<br>        Nate Wessel

<br>        Jack of all trades, Master of Geography, PhD candidate in 

Urban

<br>        Planning

<br>        NateWessel.com <a class="moz-txt-link-rfc2396E" href="http://natewessel.com"><http://natewessel.com></a>

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

<a class="moz-txt-link-rfc2396E" href="mailto:Talk-ca@openstreetmap.org"><mailto: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>    Best Regards,

<br>               Yaro Shkvorets

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

<a class="moz-txt-link-rfc2396E" href="mailto:Talk-ca@openstreetmap.org"><mailto: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>    Talk-ca mailing list

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

<a class="moz-txt-link-rfc2396E" href="mailto:Talk-ca@openstreetmap.org"><mailto: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></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>