Re: [Talk-ca] BC2020i - Solving the licensing issues

[Tracey P. Lauriault]

Makes sense Stewart!

On Fri, Feb 9, 2018 at 5:37 PM, Stewart C. Russell  wrote:

> On 2018-02-08 08:39 PM, Tracey P. Lauriault wrote:
> >
> > OSM resembles ordnance survey as was part of the original raison
> > d'etre When it started in the UK, but that does not preclude the
> > possibility of incorporating administrative boundaries such as wards,
> > and less formal boundaries such as neighbourhoods, and potentially
> > even other cachtment are boundaries such as school boards, and police
> > districts and so on.
>
> The guiding principles of OSM are “How We Map”
> :
>
> > Contributions to OpenStreetMap should be:
> >
> > * Truthful - means that you cannot contribute something you have
> > invented.
> > * Legal - means that you don't copy copyrighted data without
> > permission.
> > * Verifiable - means that others can go there and see for themselves if
> > your data is correct.
> > * Relevant - means that you have to use tags that make clear to others
> > how to re-use the data.
> > When in doubt, also consider the "on the ground rule": map the world
> > as it can be observed by someone physically there.
>
> The difficulty with neighbourhoods, catchment areas and other soft
> boundaries is that they can't be verified on the ground. The only
> reference is the imported source file. Boundaries
>  are assigned a fairly
> limited set of tags, and administrative boundaries a very
> narrowly-defined set of values
> .
> Administrative boundaries tend to pile up in Nominatim's address
> resolution - I'm supposed to be living in "The Golden Mile, Scarborough,
> Toronto, Ontario" (neighbourhood, postal town, city, province), though
> no-one uses that level of detail. Also, the Federal neighbourhood points
> (imported years ago) don't match municipal neighbourhoods (according to
> the city, I'm in Kennedy Park).
>
> So while municipal boundaries have their place in OSM, a really good
> case (and a whole lot of convincing tagging mavens) would need to be
> made before those softer boundaries made it into OSM.
>
> cheers,
>  Stewart
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>



-- 
*Tracey P. Lauriault*

Assistant Professor
Critical Media Studies and Big Data
Communication Studies
School of Journalism and Communication
Suite 4110, River Building
Carleton University
1125 Colonel By Drive
Ottawa (ON) K1S 5B6

1-613-520-2600 x7443
tracey.lauria...@carleton.ca
@TraceyLauriault
Skype: Tracey.P.Lauriault
https://carleton.ca/sjc/people-archives/lauriault-tracey/
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] BC2020i - Solving the licensing issues

[Stewart C. Russell]

On 2018-02-08 08:39 PM, Tracey P. Lauriault wrote:
> 
> OSM resembles ordnance survey as was part of the original raison
> d'etre When it started in the UK, but that does not preclude the
> possibility of incorporating administrative boundaries such as wards,
> and less formal boundaries such as neighbourhoods, and potentially
> even other cachtment are boundaries such as school boards, and police
> districts and so on.

The guiding principles of OSM are “How We Map”
:

> Contributions to OpenStreetMap should be:
> 
> * Truthful - means that you cannot contribute something you have
> invented.
> * Legal - means that you don't copy copyrighted data without
> permission.
> * Verifiable - means that others can go there and see for themselves if
> your data is correct.
> * Relevant - means that you have to use tags that make clear to others
> how to re-use the data.
> When in doubt, also consider the "on the ground rule": map the world
> as it can be observed by someone physically there.

The difficulty with neighbourhoods, catchment areas and other soft
boundaries is that they can't be verified on the ground. The only
reference is the imported source file. Boundaries
 are assigned a fairly
limited set of tags, and administrative boundaries a very
narrowly-defined set of values
.
Administrative boundaries tend to pile up in Nominatim's address
resolution - I'm supposed to be living in "The Golden Mile, Scarborough,
Toronto, Ontario" (neighbourhood, postal town, city, province), though
no-one uses that level of detail. Also, the Federal neighbourhood points
(imported years ago) don't match municipal neighbourhoods (according to
the city, I'm in Kennedy Park).

So while municipal boundaries have their place in OSM, a really good
case (and a whole lot of convincing tagging mavens) would need to be
made before those softer boundaries made it into OSM.

cheers,
 Stewart

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

Re: [Talk-ca] BC2020i - Solving the licensing issues

[Tracey P. Lauriault]

This is great! And it reflects the recommendations provided at the first
consultation meetings with your management at Satistics Canada. I believe
there is merit in talking with the municipalities from whom you are
accessing the data, simply as a courtesy, but also as a way to enlist them
as part of the project, and potentially they may have a better and more up
to date dataset than what they share in their open data. And may even have
other data of use.

OSM resembles ordnance survey as was part of the original raison d'etre
When it started in the UK, but that does not preclude the possibility of
incorporating administrative boundaries such as wards, and less formal
boundaries such as neighbourhoods, and potentially even other cachtment are
boundaries such as school boards, and police districts and so on.

I am including James McKinney in this conversation because he did some work
in compiling quite a few municipal base files when he was the ed for Open
North.

And there most definitely will be variable quality, and ontologies! Vive la
difference!

Nice work and kudos to you and your team.
TRacey


On Wednesday, February 7, 2018, Alasia, Alessandro (STATCAN) <
alessandro.ala...@canada.ca> wrote:

> Dear all,
>
> It is fantastic to see all these exchanges about BC2020i! There are a lot
> of great ideas and improvements being made. I cannot follow up on each
> point, though I wanted to update you regarding one area of specific
> relevance: the attempt to find a solution to the licensing issue for
> building related datasets. I believe this is one area where my team can
> contribute to support the BC2020i.
>
> With my team, I am looking into the feasibility of compiling all available
> municipal open data files into one single file and then releasing this
> single file under one common license, specifically the open data licence of
> the Canadian federal government. This would, hopefully, solve the license
> compatibility issue. We are still exploring this possibility but are
> moderately optimistic.
>
> So far we started with the "easy" task: compiling all the known files – a
> special thanks to those who contributed to the tables on the BC2020i wiki
> page! With that and other OD sources, we compiled an
> "OpenAddressRepository" file of nearly 11 million records (georeferenced)
> and an "OpenBuildingRepository" file of nearly 3.2 million polygons (still
> in progress). Preliminary analysis suggests that the coverage and geocoding
> are very promising. More importantly, given that the files all originate
> from official municipal sources, there should be no reason to doubt the
> quality of the data.
>
> The next step, for us, is to look at the process required to release these
> files with a GoC open data license. We do not yet have a clear timeline for
> release, but if this idea is possible, we should almost certainly make it
> before the timelines that were discussed on Talk-ca for vetting each and
> all individual municipal open data licenses  - 2080s or 2030s if I recall
> correctly :-)
>
> We believe this solution/approach, if successful, puts an end to the issue
> of license compatibility (at least for the files found thus far) and
> greatly facilitates the use of these open data by the general public as
> well as the private and public sector. Furthermore, and more importantly
> for BC2020i, this solution paves the way for the many local OSM groups to
> import these open data as they see fit. As well, once the large national
> level files are released, we might be able to collaborate with local groups
> and provide more manageable partitions of the larger files.
>
> Of course, this approach will not necessarily solve the license
> compatibility issue for all types of municipal files. Thus, needless to
> say, anybody is obviously free to pursue submitting individual municipal OD
> licenses to the License Working Group of OSM.  Though, given that the
> Working Group resources are scarce, and assuming the approach outlined
> above works for building footprints, we would be happy to discuss the
> feasibility of compiling and re-releasing other municipal open data under
> the open data licence of the Canadian federal government.
>
> Finally, as I mentioned in other communications, my team is also exploring
> other activities that will hopefully contribute to the BC2020i. These
> activities touch on data analysis, data monitoring, and building footprint
> extraction from satellite imagery. For this work, we are primarily using
> open source tools and applications that can be integrated in open source
> environments (more updates on all of this hopefully soon!).
>
> More updates, feedback, and follow up on other interesting points of
> discussion later on.
>
> Regards to all,
>
> Alessandro and DEIL team
>
>
>


-- 
*Tracey P. Lauriault*

Assistant Professor
Critical Media Studies and Big Data
Communication Studies
School of Journalism and Communication
Suite 4110, River Building
Carleton University
1125 

Re: [Talk-ca] BC2020i - Solving the licensing issues

[Matthew Darwin]

Hi John,

I think this approach has merit.

Probably it would work if we take a similar approach to what 
BikeOttawa is doing with OSM data, they wanted a "Level Of Traffic 
Stress" map.  To that they defined the set of interesting tags, 
started collecting data, then draw a map.  Now people are looking at 
the map and pointing out errors in map data (which there are lots) or 
things that need improving in the algorithm (which probably there are 
also lots).  [The tagging scheme was previously discussed on this list]


So if someone had a building-related use case they were deriving from 
OSM data, then local mappers could check how the buildings in their 
area align to whatever is that goal.  Last week I started looking a 
building heights... I was using https://osmbuildings.org/ to look at 
the areas I know and then look for buildings that seem to be the wrong 
height then going out to count the windows (vertically) to get the 
number of levels. It will make the map look better. However, it would 
be better if there was a more defined project than just looking at the 
map.


References:
The buildings I changed: 
https://osmbuildings.org/?lat=45.31336=-75.91377=18.4=30
The Bike Ottawa test stress map: 
http://mobiletest.beyond2020.com/bikemap/ (give it a few seconds to 
load the overlay)


On 2018-02-07 11:44 AM, john whelan wrote:
Unfortunately having a valid license is not the whole story.  In 
Montreal we appear to have a valid license we can import from and 
they have building data on their open data portal.  Unfortunately 
technically the quality and ease of use appears to be lower than 
Ottawa's.


I suspect that we need to see how the NRC LiDAR data unfolds and my 
gossip says there is work being done there on deep learning that may 
well be useful.


I think what we need at the moment is something to keep the project 
moving forward and I suspect that will be adding tags to existing 
buildings.  On the schools front some background as to the value of 
the stats from tagging the buildings might be worth its weight in gold.


Cheerio John

On 7 February 2018 at 09:42, Alasia, Alessandro (STATCAN) 
> 
wrote:


Dear all,
It is fantastic to see all these exchanges about BC2020i! There
are a lot of great ideas and improvements being made. I cannot
follow up on each point, though I wanted to update you regarding
one area of specific relevance: the attempt to find a solution
to the licensing issue for building related datasets. I believe
this is one area where my team can contribute to support the
BC2020i.
With my team, I am looking into the feasibility of compiling all
available municipal open data files into one single file and
then releasing this single file under one common license,
specifically the open data licence of the Canadian federal
government. This would, hopefully, solve the license
compatibility issue. We are still exploring this possibility but
are moderately optimistic.
So far we started with the "easy" task: compiling all the known
files – a special thanks to those who contributed to the tables
on the BC2020i wiki page! With that and other OD sources, we
compiled an "OpenAddressRepository" file of nearly 11 million
records (georeferenced) and an "OpenBuildingRepository" file of
nearly 3.2 million polygons (still in progress). Preliminary
analysis suggests that the coverage and geocoding are very
promising. More importantly, given that the files all originate
from official municipal sources, there should be no reason to
doubt the quality of the data.
The next step, for us, is to look at the process required to
release these files with a GoC open data license. We do not yet
have a clear timeline for release, but if this idea is possible,
we should almost certainly make it before the timelines that
were discussed on Talk-ca for vetting each and all individual
municipal open data licenses  - 2080s or 2030s if I recall
correctly :-)
We believe this solution/approach, if successful, puts an end to
the issue of license compatibility (at least for the files found
thus far) and greatly facilitates the use of these open data by
the general public as well as the private and public sector.
Furthermore, and more importantly for BC2020i, this solution
paves the way for the many local OSM groups to import these open
data as they see fit. As well, once the large national level
files are released, we might be able to collaborate with local
groups and provide more manageable partitions of the larger files.
Of course, this approach will not necessarily solve the license
compatibility issue for all types of municipal files. Thus,
needless to say, anybody is obviously free to pursue submitting
individual municipal OD licenses to the License Working Group of
OSM. 

Re: [Talk-ca] BC2020i - Solving the licensing issues

[Matthew Darwin]

James,

Good point about the quality and attributes of the data will 
definitely not be consistent between municipalities. As long as the 
source is identifiable, then the face it is one "file" or many, would 
be an implementation detail.  IMO.


On 2018-02-07 09:46 AM, James wrote:
why does it have to be one file? Cant it be individual cities that 
contribute under a say repository under the federal goverment with 
the federal license? Evaluating the quality of the data is also part 
of the process and as we've found out there are some cities that do 
it better than others when it comes to data quality.


On Feb 7, 2018 9:42 AM, "Alasia, Alessandro (STATCAN)" 
> 
wrote:


Dear all,

It is fantastic to see all these exchanges about BC2020i! There
are a lot of great ideas and improvements being made. I cannot
follow up on each point, though I wanted to update you regarding
one area of specific relevance: the attempt to find a solution
to the licensing issue for building related datasets. I believe
this is one area where my team can contribute to support the
BC2020i.




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