Re: [Talk-ca] Importing buildings in Canada

[Paul Norman via Talk-ca]

The sources of the data are different in different regions, as well as the existing communities. A Canada-wide process won't work when each import is going to vary.On Apr 27, 2019 1:40 PM, john whelan  wrote:We now have three sources of data with the correct licensing.I'm proposing that I amend both the import plan and the import mailing list to include the three alternative sources.I'm tempted by the idea of splitting the country up into regions of some sort.We have a couple of groups currently who I think would like to import what is available in Alberta and Manitoba.  Are we asking them to hold off until Pierre and company have come up with a cleansing routine?Thoughts ladies and gentlemen please.Thanks John
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Building Import

[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

[Talk-ca] Terminating British Columbia Mosaic imagery

[Paul Norman]

I will be shutting down the "British Columbia Mosaic" imagery in the 
near or medium future. I set this up in about 2011, and the system has 
been running without many updates since then.


When I started hosting it, we had access to Bing and Yahoo. Between the 
two of them, we had acceptable for the time imagery in Vancouver, and 
poor imagery in Burnaby and east. Living in New West, this was a problem 
for me, so I put together the layer. My main sources were 10cm 2009 
imagery covering Vancouver, 2009 20cm imagery for Burnaby, 2011-2012 
10cm and 40cm for Surrey, and a few other minor sources.


The accuracy and colour range of the Surrey imagery was exceptional for 
the time, and remains exceptional by today's standards. The accuracy of 
other sources was also good, but colours weren't the best. This allowed 
an imagery layer that could be assumed to have accurate positions 
without checking GPS traces everywhere, and its accuracy was ahead of 
the data in OSM at the time, as well as being recent enough.


Times have changed, and we have more imagery hosts. In particular, we 
normally have commercial imagery hosts who will host the open imagery 
that is available, and handle any legal matters about its usage. I 
remember trying to get Bing, Mapbox, or anyone to use the Surrey imagery 
in Surrey, which was better than what they were using in every way and 
free, and having no luck. The data in OSM is frequently more recent than 
the imagery.


Before deciding to shut it down, I reviewed the available imagery in a 
few areas, and recommend defaulting to ESRI imagery in all of the Lower 
Mainland, with the exception of some cloudy parts of Ladner.* In Ladner, 
and if slightly more recent imagery is needed elsewhere, I recommend 
DigitalGlobe Standard Imagery as a lower quality but more recent source. 
Both have excellent alignment. I would not recommend Mapbox Satellite or 
Bing anywhere in the region.


Instead of shutting down, why am I not moving it to a different server? 
Time, mostly. With all of the sources I had used out of date, I'd have 
to find new ones. This would take a lot of time to find and process 
sources, and a lot of time to sort out the legal mess that is open data 
in Canada. I would also probably take a different approach, with 
multiple independent layers that the editor software picks between.


I believe there is still a place for user-hosted imagery, but at least 
here, it will never offer such an increase in quality again, because the 
commercial hosts are offering a much better "baseline".


* Alignment in Hope was possibly worse, but I haven't done extensive 
research into the accuracy of BC Mosaic in that region. I couldn't find 
any good objects to compare with in Whistler, I kept finding stuff had 
changed on the ground, which is a good reason in itself to avoid BC Mosaic.



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

[Talk-ca] Vancouver mappy hour

[Paul Norman]

Starting this year, we're aiming to have monthly mappy hours in 
Vancouver, on the 4th Friday of each month. The next one is Friday March 
24th, near Metrotown at 6:30 PM at the Firefighters' Public House. This 
is convenient to transit


Full details are at 
https://www.meetup.com/OpenStreetMap-Vancouver/events/237996240/, and 
the events are also on the calendar on the wiki.




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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/21/2017 3:11 PM, Paul Norman wrote:

On 1/20/2017 5:33 PM, john whelan wrote:
Did you include permission for the bus stops as well? They are from 
the same source and the same licence.  I think I might have included 
one pitch sport soccer.  The pitch was mapped but the sport soccer 
was I must confess taken from their open data source.


I kept it generic, not specifying a particular dataset. That way we'll 
have a final answer one way or the other and won't have to go back to 
them all the time. 


The initial answer was that the license would impose obligations on top 
of the ODbL, our distribution license. This would make the data 
incompatible.


I have gotten back to them with some additional questions which might 
offer a way forwards and clarify the problems. If I can't get anywhere 
we'll have to decide what to do, but it will probably mean we can write 
off the City of Ottawa as a potential data source.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/22/2017 9:06 AM, James wrote:
So if I understand correctly Paul, CC0 or any other license would 
require permission as a bypass to the license, even though it would be 
considered compatible with ODBL.


No. CC0 is compatible with the ODbL, so you can just go ahead and use 
the data*, subject to any conditions the community has developed around 
imports.


* There could be exceptional circumstances in some cases.

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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/22/2017 9:48 AM, James wrote:
So why is this not considered the exact same as OGL-CA, which is 
considered compatible with ODBL?




As mentioned previously, the OGL-CA is compatible because the Federal 
government has said so for their data. The Federal government's 
statement only applies to their data under their license.


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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/22/2017 7:07 AM, John Marshall wrote:

Paul,

So once we get a letter from the City of Ottawa, are we good to add 
the buildings as per the wiki?


It depends what they say in their reply. If they say no, then we can't 
use their data. If we have a suitable reply, then we are able to legally 
use their data.


There are of course other requirements that the community has developed 
like documenting the import, etc, and the letter has nothing to do with 
these.


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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/21/2017 4:34 PM, john whelan wrote:
What you have is an interpretation of the Federal Government license.  
From my background in the civil service my understanding is for a 
statement it would have to be over a minister's signature or by act of 
parliament.  No one else has the authority unless it is delegated.


If that's true and we can't rely on a statement from a government 
employee to interpret their license, then we can no longer use OGL-CA data.


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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/21/2017 3:48 PM, James wrote:
It is, the thing they changed was federal references to municipal 
ones. Which is why i'm confused the license is "not compatible"




We have a statement from the Federal government for their data under 
their license. The Federal government cannot make a statement about City 
of Ottawa data under the City of Ottawa license.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/20/2017 5:33 PM, john whelan wrote:
Did you include permission for the bus stops as well? They are from 
the same source and the same licence.  I think I might have included 
one pitch sport soccer.  The pitch was mapped but the sport soccer was 
I must confess taken from their open data source.


I kept it generic, not specifying a particular dataset. That way we'll 
have a final answer one way or the other and won't have to go back to 
them all the time.


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

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/20/2017 3:22 PM, James wrote:

Old link to an old wiki. Please see:
https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Plan#Permission

That says Ottawa gave some data to Stats Canada in 2016, not that their 
data can be reused under the ODbL. I've sent an email to them asking for 
permission. We need this because we're getting the data directly from them.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada

[Paul Norman]

On 1/20/2017 12:40 PM, Ellefsen, Bjenk (STATCAN) wrote:


Hello everyone,

Big news, the City of Ottawa has released the footprint of over 
325,000 buildings on their open data portal in support to the project 
with Statistics Canada and the OSM community.


We are very grateful for the amazing collaboration with the City of 
Ottawa on this pilot project and are very pleased for this amazing 
contribution.


Link:

http://data.ottawa.ca/en/dataset/urban-buildings



Is there a statement anywhere from Ottawa saying that their license is 
compatible with the ODbL? All I can find is 
https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Permission 
which seems to be about their previous license.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [Talk-us] destination:street

[Paul Norman]

On 1/19/2017 5:00 PM, Martijn van Exel wrote:
Looking at a random one, http://www.openstreetmap.org/way/34154734 / 
http://openstreetcam.org/details/10767/4194 — I think in the US we 
would just map this as destination=Carman Road;Iriquois and 
destination:ref=1


That is how it would be typically mapped in Canada in my experience, 
although it might have a prefix to the ref.


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

Re: [Talk-ca] Community Conduct

[Paul Norman]

On 12/22/2016 3:21 PM, James wrote:
As pnorman has said in the past( 
https://lists.openstreetmap.org/pipermail/talk-ca/2016-September/007260.html):


/ Uploaded in small enough parts that the changesets make sense. This 
means never uploading more than 50k objects at once, and typically 
fewer than 10k./



I try to keep my changes under 10k, but with buildings, nodes multiply 
quickly as there are minimum 4 per building(rare usually average 6-10 
depending on complexity)


The numbers quoted are in the context of an *import *where the concerns 
are the ability to revert, working with the changeset in other tools, 
not leaving stray nodes in the database, not splitting one upload over 
multiple changesets, and not having a broken upload. I wouldn't 
recommend exceeding them for any work, but a non-import is out of the 
scope of the CanVec post linked.


Personally, I'd get worried about conflicts, lost work, and want to 
upload well before 1k changes, let alone 10k. Those often aren't a 
problem with an import, or if they are they can be easier to solve, but 
with normal mapping solving them often requires more thought.


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

Re: [Talk-ca] Road route relations: network tag

[Paul Norman]

On 10/27/2016 3:04 PM, Martijn van Exel wrote:


My mapping colleagues (not me, I only map in my spare time :)) noted 
that there are some irregular network tags on highways in Canada. The 
usual hierarchical notation[1] is in place in many relations, but we 
encountered deviations from that where instead of the colon separator 
an underscore is used, so for example instead of CA:ON we see ca_on, 
and some variations on that.


ca_... has been the long-standing standard. When I last looked at it, 
the US was the main user of colons. It's possible this has changed, but 
ca_on_county is still one of the most frequent network tag values 
(http://taginfo.openstreetmap.org/tags/network=ca_on_county), and there 
may be consumers who expect this.


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

Re: [Talk-ca] Canvec attributes (roads)

[Paul Norman]

On 9/9/2016 2:34 PM, Martijn van Exel wrote:

The conflation engine takes OSM PBF as input, so the Canvec shapefiles
would need to be translated (using ogr2osm).


The CanVec we've used in the past has been supplied in OSM XML format. 
No one has proposed a new import with a different format, so I doubt 
there are any ogr2osm translations available.


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

Re: [Talk-ca] Forests/Land Use, was: Canvec reverts

[Paul Norman]

On 9/1/2016 1:22 PM, Paul Ramsey wrote:
I'm not sure I agree. "Better than nothing" I guess is the principle, 
but when what is there (not nothing) gets in the way of improving 
other features, then it's not better than nothing. And what if what's 
there is, from an information point of view, basically nothing?


Like the forests polygons that basically do nothing to delineate where 
forests actually are (or residential polygons with same issue?) "Go 
map all forests" is not actionable. Hell, even "clean up all forests 
in just the area you care about" isn't. There's too much. So instead, 
I leave demonstrably wrong "forests" in place.


In your example there I would have no issues with deleting that 
"forest". Its boundaries do not agree with the boundaries of the real 
forest, and the only reason there happens to really be forest in most of 
it is because it's in a part of BC where that is true *everywhere*.


I've cleaned up bad CanVec data like that, and my first step would be to 
delete it and start from scratch, so it's not like you are causing any 
additional effort if someone decides to come along and map it properly.


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

Re: [Talk-ca] Forests/Land Use, was: Canvec reverts

[Paul Norman]

On 9/1/2016 8:17 AM, Paul Ramsey wrote:
I'm "glad" to see someone else w/ this issue. It's glancingly related 
to the canvec import issue, since the land use polygons are a source 
of some of the issues the reverter is complaining about (malformed 
multipolygons / boundary overlaps).


In my own work in my old home town of Prince George, I've constantly 
wanted to just plain delete the "urban area" land use polygon (which 
doesn't seem to correspond in any way to the actual urban area of the 
present) and the forest polygons (which have the same problem).


I get frequent complaints about CanVec forest data in OSM from people 
who would like to use OSM data but don't. It is only usable as a low 
resolution landcover layer (z4-z10 or so) and if someone wanted that, 
there are better data sources they can use.


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

Re: [Talk-ca] CanVec Reverts

[Paul Norman]

Hello,

Multiple people have referred this issue and changeset 39517002 to the
OpenStreetMap Foundation Data Working Group about this issue. The Data
Working Group has responsibility for the resolution of disputes beyond
the normal means of the community, as well as some responsibilities
concerning imports. I am replying here rather than the changeset as it
should reach everyone involved.

CanVec Quality
==

The CanVec import is one that was started long ago so parts of the
documentation are lacking and some aspects are unclear.[1] CanVec, like
any other import, has certain hard requirements, including the use of a
dedicated user account.

In particular it is expected that imported CanVec data is

- Integrated with existing data, particularly at NTS/CanVec tile edges

- Valid

- Internally consistent with both the newly imported CanVec and existing
  OSM data, particularly to avoid overlapping landuse like forest and
  water, forest and residential, or wetlands in what is obviously a
  residential subdivision.

- Uploaded in small enough parts that the changesets make sense. This
  means never uploading more than 50k objects at once, and typically
  fewer than 10k.

- Not duplicating existing OSM data. Evaluating what data is better
  generally requires experience with both CanVec and OSM data in the
  *region being mapped*

It is not required that CanVec data is compared an external source like
Bing imagery, but this is helpful, particularly when resolving problems.

We encourage the Canadian community to develop better documentation for
people importing CanVec to achieve this and to remove outdated
documentation.[2]

Reverting
=

Advance permission is not required for reverts, nor for normal mapping
activities. At the same time, users are expected to be responsible,
particularly when using tools for reverting which allow large-scale
changes where other users may disagree with them.

Where there are problems with an import reverting is an option, but
just one of many, and often not the appropriate first action. Unless
there are legal problems[3] or fatal problems with the import it is
preferable if the original importer can fix the problems in a timely
manner. There was every indication this was going to happen in this case.

The revert of 39517002 was inappropriate and counter-productive. New
actions like this revert may lead to further Data Working Group
involvement and potentially blocks. If the Canadian community needs help
reverting 41749133 and 41756737, the Data Working Group can revert those
changesets.

While not going into depth on the changeset discussion at this time, I
want to remind everyone involved that OpenStreetMap is a crowd-sourcing
project, which inherently involves working with other people. This
requires good communication, which was absent here.

Paul Norman

For the OpenStreetMap Foundation Data Working Group

[1]: Except for the CanVec license, which is ODbL and possibly CC BY-SA

[2]: Much of the CanVec documentation is outdated, which makes it
 difficult to know what is relevant. A good start would be removing
 outdated documentation.

[3]: Please refer cases of large-scale infringement to 
d...@osmfoundation.org

 so we can "redact" the content to remove it from publicly viewable
 history.


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

Re: [Talk-ca] OpenStreetMap at the Crossroads – The Map Room

[Paul Norman]

On 8/17/2016 3:44 PM, Laura O'Grady wrote:

I recently exchanged messages via OSM with a "robot mapper" who did a bunch of 
imports in my areas. I asked this person some questions about their edits, pointed out 
some errors and invited them to present their work at a local OSM meeting. After a few 
exchanges I received no further response.

I don't know what recourse there is for this (imports gone astray


The first step is reaching out to them by changeset comments or other 
means, which you've tried. If this fails and they are non-responsive or 
you can't resolve the issue you can escalate it to the Data Working 
Group by emailing d...@osmfoundation.org. We have some additional tools 
we can use.


Paul Norman
For the Data Working Group

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

Re: [Talk-ca] Mapping exit numbers and destinations in Canada

[Paul Norman]

On 8/11/2016 5:53 AM, Kevin Farrugia wrote:
Yes - recently bootprint, andrewpmk, and I have been changing and 
correcting the name tags to destination in Ontario along the 
400-Series highways. If you see a ramp/link that is named, it's fine 
to change it over to destination or correct a problem you find with it.


Destination tags are based on what the signs say. The name tags tend to 
come from CanVec and are sometimes unrelated to signage, so make sure 
you check the signs before adding a destination tag.


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

Re: [Talk-ca] Stat Can and buildings

[Paul Norman]

On 6/15/2016 3:08 PM, john whelan wrote:


Thank you Paul I think that sums up the issue nicely, someone at Stats 
Canada is going to have fun working out which tags are relevant to 
them especially when some may be a different way to express the same 
thing.


Plus of course we have amenity=library etc which might not be tagged 
as a building at all.


Fun times, I'm glad I'm retired from Stats Canada these days.



Well, the problem is that the question you asked isn't really what they 
want to know. I'm not quite sure what they do want to know, but they're 
asking the wrong question here and getting a useless answer.


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

Re: [Talk-ca] Stat Can and buildings

[Paul Norman]

On 6/15/2016 8:01 AM, john whelan wrote:


As a first step Stats would like to know the tags used when mapping 
buildings in Canada and the number of times used.  This is to get an 
idea of what is already mapped and to see which values should be used 
when new tags are added.  I looked at a small sample from Ottawa and 
noted 127 different tags on buildings including address tags.


The other part of this is what is available under other tags than 
building.  For example amenity=school etc.  I suspect school, college 
and universities are fairly well mapped.




Taginfo can tell you this information. No one is currently running a 
Canada-specific taginfo instance, but you can get an idea of numbers 
from http://taginfo.openstreetmap.org/keys/building#combinations.


There are about 800 keys used more than 1000 times on objects with 
building=*.


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

Re: [Talk-ca] Fort McMurray forest fires

[Paul Norman]

On 5/9/2016 11:17 PM, Heather Leson wrote:

Hi Folks

Planet Labs opened up their imagery with an OSM friendly license

https://www.planet.com/pulse/fort-mcmurray-wildfire/



The license on there (CC BY-SA) is not suitable for deriving data for 
use in OSM with - do we have a special permission from them documented 
somewhere? Without it we can't use the imagery.


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

Re: [Talk-ca] Fort McMurray forest fires

[Paul Norman]

On 5/9/2016 12:43 PM, Kunce, Dale wrote:

Bernie,
I do see that the building footprints are in the esri basemap 
unfortunately this doesn’t actually help. The esri basemap data is 
just an tiled image and does not provide us with the vector data that 
we need to complete our work. I’m happy to take the lead and 
coordinate the mapping. The existing Bing imagery is good enough for 
our needs for tracing.




Any hope of getting post-event imagery, which will allow us to avoid 
mapping buildings which no longer exist and shouldn't be in OSM?


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

[Talk-ca] Fwd: Re: Fort McMurray forest fires

[Paul Norman]

Fort McMurray is the 5th largest city in the province of Alberta and has 
been evacuated in the face of wildfires which have burned thousands of 
structures. Satellites have been tasked to gather imagery, but it 
probably won't be very useful imagery for OSM until the smoke has cleared.


My guess is there won't be a HOTUS activation associated with this 
disaster. The HOT work people have been doing so far is mainly improving 
the state of the area in OSM with pre-disaster sources.


If anyone gets openly licensed imagery for the area, I can host tiles 
from it.


 Forwarded Message 
Subject:Re: [Talk-ca] Fort McMurray forest fires
Date:   Thu, 05 May 2016 11:45:49 -0400
From:   James 
To: John Marshall 
CC: Talk-CA OpenStreetMap 



I've created a task on my tasking manager for buildings in Fort 
McMurray. Tracing buildings can help us flag buildings affected by the fire


http://tasks.osmcanada.ca/project/22

On Thu, May 5, 2016 at 11:43 AM, John Marshall > wrote:


   I will check with my contacts in my day job if they will release
   thier imagery.

   I know DigitalGlobe are tasking thier satellites over Fort Mac.

   John Marshall

   On May 5, 2016 11:39, "James" > wrote:

   I think we'll have to wait until the fire is put out before we
   get satelite imagery.
   What I can do is create a task on tasks.osmcanada.ca
    for Fort McMurray and we can trace
   buildings as they are not all there

   On Thu, May 5, 2016 at 11:28 AM, Andrew MacKinnon
   > wrote:

   As you are probably aware by now, a large portion of Fort
   McMurray,
   Alberta has been destroyed by forest fires.

   Is any freely licensed aerial imagery of the affected area
   available
   yet? Will the Humanitarian OpenStreetMap team be creating a
   project
   for Fort McMurray?

   ___
   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] Bus stops in Ottawa

[Paul Norman]

On 2016-03-02 7:14 PM, Stewart C. Russell wrote:

On 2016-03-01 06:42 PM, Tristan Anderson wrote:

>Let's not be too hasty in removing large amounts of data, … simply
>because it may or may not be compatible with a future OSM license.

That's not the issue. It's not compatible with the current licence, for
reasons including:

[...]

Legal risks aside, the import broke most of the Import Guidelines
, so it should be
removed and discussed before import again.
Yes, there's no question the license is incompatible with the ODbL or 
*any* open license.


The two changesets are 17206904 and 17206923. Normally I'd try to 
contact the user, but a changeset dicussion was already started which 
had the same effect and the user has not been active in over a year.


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

Re: [Talk-ca] Bus stops in Ottawa

[Paul Norman]

On 2016-02-29 2:46 AM, john whelan wrote:
I think with the clause in the uploading terms that OSM can change the 
license its very difficult to import anything as it is difficult to 
say to City of Ottawa etc we'd like your data but we don't know what 
license it may have in OSM in the future.

Data needs to be compatible with our license, which is the ODbL.[1]

Is anyone going to take the responsibility on for removing the data?
Copyright incompatible data needs to be redacted, not just deleted. I'd 
normally be the one doing this, but I'm traveling today.


http://wiki.osmfoundation.org/wiki/License#Can_third-party_ODbL-licensed_data_be_imported.3F
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Highway recoding

[Paul Norman]

On 1/28/2016 10:31 AM, Ken Wuschke wrote:
So a suggestion to a definition for trunk routes in Canada could be a 
simple as:


*A highway=trunk is a roadway that is a part of the National
Highway System as defined by the Council of Ministers
Responsible for Transportation and Highway Safety and is found
in annually updated document called **Canada’s National
Highway System Annual Report.*



I don't see that we should be depending on a government definition 
within OSM. Additionally, this would lead to unexpected results if you 
look at the feeder routes in the lower mainland.



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

Re: [Talk-ca] Highway recoding

[Paul Norman]

On 1/26/2016 11:34 AM, Chandler Vancouver wrote:


To begin with I am relatively new to OSM but I am trying to figure the 
Canadian definition for trunk status and find the current definition 
as described on 
http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Trunk 
as academic and not functional. And please forgive me if I covering 
previously discussed material. Also, my context might from British 
Columbia focus as well.


This conversation comes up from a discussion I have had with another 
OSM contributor, so I'm posting below my response to the definition as 
found at 
http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines#Trunk


http://wiki.openstreetmap.org/wiki/Canada:British_Columbia#Highways_and_provincial_roads 
is a better description of how things are actually tagged in BC in OSM.


At least within the lower mainland and Fraser valley, the NHS is not 
used for tagging. My preferred examples of this are the new Highway 17, 
which didn't exist when the document was compiled, and some of the 
relatively small roads linking highways to ports.


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

Re: [Talk-ca] Map rendering errors

[Paul Norman]

On 11/1/2015 5:27 AM, Bruno Remy wrote:


By the evidence, this is a database problem in osm2pgsql 
 
schema , witch is used by Mapnik's rendering process.
The most probable hypothesis is : some old nodes and old ways still 
exists in 'OldNode' and 'OldWay' tables, with the "visible" status as 
'true' instead of 'false'.

See the shema for reference:
http://wiki.openstreetmap.org/w/images/c/cd/RailsPortModels.png

My suggested solution:
Create a brand new collection of nodes with the position of "all 
fantom nodes", and sending'them to the Tech tem of OSM. They'll be 
able to run a query into the
'OldNode' and 'OldWay' tables and switch the "visible" status from 
'true' to 'false'.


Don't do this. The rendering database doesn't have OldNode or OldWay 
tables or a visible status. For that matter, the master apidb database 
doesn't have those tables either, it has ways and currentways tables.


This is normally where I'd give a solution, but I don't have one. It's 
an osm2pgsql bug, not a DB bug, but without a reproducible testcase and 
verification that the bug happens on recent versions, it becomes a 
significant effort to get anywhere.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Federal licence : Confusion

[Paul Norman]

On 10/12/2015 4:44 PM, Stewart C. Russell wrote:
Much of the data is tagged with CANVEC import etc viewable in JOSM 
but in the Ottawa area in particular many of this attr / source tags 
have been removed.


The tags don't matter; attribution is in the *© OpenStreetMap 
Contributors* link. Aren't we supposed to remove the NRCan tags if we 
modify data on the ground, or add in our own additional data?


From a legal perspective, any tag can be removed at any time. This 
doesn't mean they *should* be removed. The question you want to ask is, 
what is more helpful to other mappers? If you've changed enough to make 
it misleading to say "This is NRCan data", you should change the source tag.


I always remove the attribution tag, as it duplicates the information in 
the source tag. There's other tags left-over from the import that I 
normally removed after a minimal inspection, because they're generally 
wrong, misleading, or useless.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Federal licence : Confusion

[Paul Norman]

On 10/12/2015 5:38 AM, Stewart C. Russell wrote:
Many other national contributors 
 use an OGL licence, 
such as in the UK 
. 
These contain very similar attribution terms as the OGL-CA licence. I 
noticed our Canada section of the (now vast) contributors' page was 
missing language that the OGL-CA licence requires, so I added it: 
‘/Contains information licensed under the Open Government Licence – 
Canada ./’ I 
may have put it in the wrong place; discuss.


No one has proposed an import of OGL-CA licenced data, so there 
shouldn't be any in OSM. If someone wanted to import that data, it'd 
have to be discussed with the community, and the license would be part 
of it.


The various different Canadian adaptations of the OGL are not the same 
as the OGL, which was written in the UK and is explicitly compatible 
with CC BY and the ODbL. Some of the Canadian versions do not even 
qualify as open licenses.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Fwd: Ottawa, Canada import

[Paul Norman]

On 8/17/2015 8:20 PM, Stewart C. Russell wrote:

Hi James,
but I did receive approval from the city that we could import data 
from data.ottawa.ca/dataset http://data.ottawa.ca/dataset. Which I 
documented here:

https://wiki.openstreetmap.org/wiki/Canada:Ontario:Ottawa/Import/Permission


I'm not a legal expert, but I think that OSM would have trouble with 
some of the licence terms, such as 
http://ottawa.ca/en/mobile-apps-and-open-data/terms-use#terms


Yes, the Ottawa terms are pretty clearly incompatible with 
OpenStreetMap, and do not meet the Open Definition. Giving us permission 
is fine, but we need to be certain that the city realizes what it is 
granting permission for, and we should also make sure that they realize 
the license they currently have is non-open and a problem.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Open Data Imports

[Paul Norman]

On 7/23/2015 8:54 PM, Andrew MacKinnon wrote:

Does anyone know which of these (and others) are compatible with the
OSM license?
Very likely most of them are not released under open licenses. 
Unfortunately, non-open data gets listed in OpenAddresses and there's no 
assurance that you can combine data from one source in OpenAddresses 
with data from another source in it.


OpenAddresses is a good fallback source for a geocoder, but I don't know 
that there are any geocoders that do that yet.


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

Re: [Talk-ca] Highway recoding

[Paul Norman]

On 7/22/2015 11:43 AM, Daniel Begin wrote:


So far, I understand we have 2.5 votes for tagging trunk/motorway all 
roads identified as “core route” in document (a); 0.5 against (I am 
still torn between the two approaches!-)


More comments would be appreciated

Such an approach would be inconsistent with how highways are tagged in 
BC and expectations of locals. It would also make BC quite different 
than across the boarder in Washington.


I can think of several motorways and trunk roads which are not on the 
list in the PDF, and many of the roads on the list are primary, or in at 
least one case, secondary. Some of the roads not on the list are more 
important in the transportation network than ones on it.


The criteria being proposed are also inherently unverifiable. We map the 
world, not what a government database says.


What about new roads? There's a new route that's opened up, and it's a 
mix of trunk and motorway, but it's not listed in the NHS report. To tag 
it primary when less significant roads constructed to a lower standard 
are tagged as trunk and motorway would be absurd.


Because it has a lot of freight, it probably will become a NHS road at 
some point. Does its classification magically change when nothing has 
changed on the ground?
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Mapping Commercial Drive event in Vancouver

[Paul Norman]

The Vancouver OSM group will be meeting on Saturday at 11 AM on 
Commercial Drive


We'll be mapping locations on Commercial Drive and enjoying the nice 
summer weather outside. Use your favorite OpenStreetMap tool to do the 
mapping, be it an app, notebook, GPS, or field papers.


People from all skill levels (beginner to advanced) and backgrounds are 
welcome to attend this meet-up.


More info at http://www.meetup.com/OpenStreetMap-Vancouver/events/223667163/

Dress for the weather, which could be anything from boiling hot to rain.

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

Re: [Talk-ca] GeoBase Import

[Paul Norman]

On 7/8/2015 2:40 AM, James wrote:

Has anyone else had issues with the conversion script from GML to osm?

I've been looking at the wiki here:
http://wiki.openstreetmap.org/wiki/Geobase/Import_How-To

and when I try to convert the data python gives me the :
UnicodeDecodeError: 'ascii' codec can't decode byte 0xae in position 2: ordinal 
not in range(128)
Which i'm pretty sure is the é character

Sounds like an encoding problem - the code probably needs fixing. The 
LANG environment variable might be relevant.


The scripts are mainly a historical curiosity at this point. If someone 
wanted to import the data, they'd need to propose a new import, and it'd 
probably be easier to write new scripts based on more modern tools than 
to use the old ones.


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

Re: [Talk-ca] Low quality unresolvable notes

[Paul Norman]

On 7/6/2015 6:42 PM, Andrew MacKinnon wrote:
Some of these notes are POIs that are visible on Mapillary but I 
couldn't figure out exactly where they are (for instance, the sign on 
a strip plaza shows there is a shop but I can't see exactly where it 
is). You should probably keep these.
If you didn't have enough information to add directly to the database, 
then these only indicate a survey is needed, which is not useful 
information here.


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

[Talk-ca] Low quality unresolvable notes

[Paul Norman]

I've been catching up on local notes, and have come across a few I'm not 
sure how to resolve. There are a number which are equivalent to There 
is a some name of shop somewhere in this block. While probably 
correct, they're not very useful.


The notes aren't bug reports, the original intent of 
notes/OpenStreetBugs. They're not precise enough to resolve, so 
basically all the information they contain is that there are shops here 
which could be added if a site survey was done. A site survey would be 
nice, but there's plenty of areas where that is so - if someone opened 
up notes everywhere they were needed in the area, they'd make other 
notes less valuable and probably end up closed.


I'm leaning towards closing them as not reporting a bug nor providing 
specific enough information to add something to the map, but wanted to 
get the thoughts of others.


I might also bring this up at our next local meetup, see what other 
locals think.


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

Re: [Talk-ca] OSM data quality in Canada

[Paul Norman]

On 6/17/2015 1:12 PM, Martijn van Exel wrote:

* What is the imports history, particularly in relation to road network, POIs 
and addresses? (Beyond what’s in the import catalogue page on the wiki, if 
anything)
CanVec, National Hydrographic Network (NHN), and National Road Network 
(NRN), all out of Natural Resources Canada (NRCan).


CanVec is a product supplied in .osm format composed of multiple 
government datasources, including the NHN and NRN. The sources used vary 
by region, so what is true somewhere may not be true elsewhere.



* What external (government and otherwise) open geospatial data sources are out 
there that have been or may be considered for improving OSM?
There is probably an equivalent to TIGER address ranges that should be 
used by a geocoder as a fallback in the same manner.


I'm not aware of anything really under consideration. Data released by 
the federal government under their OGL variant is okay license-wise, but 
the same is not always true for the provincial and municipal data.

* Are there any Canada-specific mapping and tagging conventions?
Because roads are largely the responsibility of provinces, road 
classification varies province by province.

* Are there any known big (national) issues in the Canadian OSM data? 
(misguided imports / bots, major tagging disputes, that kind of thing)
CanVec has left parts of the country a colossal mess. I would say the 
forest/water data is the worst, often coming from different sources from 
the 70s, and these sources often do not agree with each other. When 
faced with 40 year old imported landcover data that doesn't resemble 
reality, the best option is often to just delete it.


There are some regional quirks with CanVec. These include

- Poor alignment of water or trees with each other
- Forests on what are now residential areas
- Incorrect surface or lanes values
- Invalid housenumbers (-1)
- Interpolation used for what should be a single number
- Interpolation where there aren't roads in the data
- Extra spaces in some road names
- Unclassified roads tagged as residential

NRN and NHN were less wildly imported. Not having landcover, they don't 
have those problems, but do have some of their own


- Incorrect surface or lanes values (NRN)
- Lots of tag cruft (Both)
- Badly overnoded streams (NHN)
- Streams with oneway (NHN)
- Non-standard tagging (NHN)


* Which (other) companies / organizations / government agencies use OSM data 
for Canada?
NRCan used to use CanVec and OSM matching to find locations missing in 
their dataset, but I'm not sure if they do this anymore.

* Any suggestions for QA tools that would help the community, either existing 
or new?
Beyond the standard international ones, I'm not sure. The incorrect 
surface, lanes, housenumbers, and extra spaces are probably all amenable 
to a mechanical edit rather than a QA tool. Some headway has been made 
with mechanical edits. The tag cruft will remove itself over time as 
people edit the objects.


Overlapping water/trees from CanVec are so easy to find, and I'm not 
sure a QA tool is the best choice where the time to fix hugely outweighs 
the time to find.


Address interpolation indicating roads where there are no roads is an 
interesting one, and might be suitable to a QA tool.


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

Re: [Talk-ca] duplicate address data

[Paul Norman]

On Mar 26, 2015, at 11:55 AM, Gerd Petermann gpetermann_muenc...@hotmail.com 
wrote:

Example: The ways 
http://www.openstreetmap.org/way/99649911 
and
http://www.openstreetmap.org/way/83504524 


One has source=NRCan-CanVec-7.0, the other source=CanVec 6.0 - NRCan
Is there a good reason for this redundancy?
If not, what is the best way to remove these duplicates?
I can think of different ways:
1) keep only the eldest entry
2) keep only the youngest entry
3) keep the older and add a note that the data is confirmed by NRCan-CanVec-7.0 
 
This is a case where someone imported CanVec improperly without resolving 
conflicts with existing data.

If both interpolation ways are the same, it doesn't matter which is deleted. 
You could investigate the changeset the more recent one came from and see if 
the entire thing needs reverting.

If they differ, look to see if one has been edited and keep that one. If 
neither have been edited, I'd presume CanVec 7 to be more accurate than CanVec 
6 in absence of any other information.___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] March Vancouver meetup

[Paul Norman]

There's going to be a Vancouver meetup near Metrotown on March 17. In 
the great Saint Patrick's Day tradition, the theme is green locations, 
but anything is welcome.


Bring your own device - laptop recommended.

More info and RSVP at 
http://www.meetup.com/OpenStreetMap-Vancouver/events/220964194/


Please RSVP. It really helps organizers to know that people will be coming.

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

Re: [Talk-ca] ON prefix on Ontario highways

[Paul Norman]

On 2/28/2015 9:45 AM, Richard Weait wrote:

Don't use prefixes or adulterate the ref with extra characters.  Use
the network tag for that information.

http://taginfo.osm.org/search?q=network%3Dca_on_county
Although the lack of prefixes may be true for Ontario routes, it's worth 
remembering that in most of the world letters form an integral part of 
the route reference and should be included.


Regardless, the network tag is only for relations, not ways.

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

Re: [Talk-ca] RIP CanVec

[Paul Norman]

On 11/17/2014 5:50 PM, Stewart C. Russell wrote:

Is there any way to de-tile the data? I realise that most of Canada is
one giant water relation, but is there a data processing pipeline that
can recognize and join up split entities?
I looked at this, but it's better to go back to the original sources, 
particularly now that CanVec is no longer being updated.


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

Re: [Talk-ca] Municipal data source attribution

[Paul Norman]

On 11/9/2014 8:48 AM, Steve Singer wrote:


What is the current procedure for meeting the attribution requirement 
of a municipal data-source released under the 'Open Government Licence ? 
Unfortunately each Open Government License is different, and when I've 
asked about license compatibility I've received different answers from 
different licensors, so you'll have to ask the municipality about ODbL 
compatibility. I suggest asking about CC BY compatibility at the same time.


I have gotten affirmative answers from the Federal government and BC. I 
have gotten a negative answer from the City of Vancouver. I've got 
queries out with some other BC cities, but nothing final from them.


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

[Talk-ca] Inaugural Vancouver Meetup - Tuesday October 28

[Paul Norman]

On Tuesday October 28th, there will be an OpenStreetMap meetup held in 
Vancouver.


http://www.meetup.com/OpenStreetMap-Vancouver/events/214167332/

We'll be holding it in the Bread Garden in Metrotown 
(http://www.openstreetmap.org/way/257886760), with convenient access to 
transit and nearby parking.


Please RSVP on the Meetup page so we have an idea of numbers to let the 
restaurant know.


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

Re: [Talk-ca] Winnipeg Open Data portal

[Paul Norman]

On 8/1/2014 10:16 AM, Michael Zajac wrote:

Does this look compatible with OSM?
No one has yet evaluated the various OGL variants for compatibility with 
other licenses. I've gotten explicit statements of compatibility from 
some sources.


For that matter, the various variants aren't listed as meeting the Open 
Definition[1].


If the data provider is unwilling to go with a standard license, they 
really need to explicitly indicate compatibility with other standard 
licenses.


[1]: http://opendefinition.org/licenses/

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

[Talk-ca] Mapillary coverage in Vancouver

[Paul Norman]

For some time I have been taking pictures to map from, and now that 
Mapillary is out, I finally have a way to share them.


Mapillary is a company that is making a service similar to the old 
OpenStreetView, where they collect pictures of roads. The difference is 
that they currently offer the pictures under an open license, CC BY-SA, 
and they have given explicit permission to derive information for 
OpenStreetMap.


They have a clever app, but what matters for me is that I can upload the 
pictures from my car-mounted camera after geotagging them. As I drive a 
reasonable distance and I've designed my setup for capturing images for 
mapping from, this means that the Mapillary coverage is building up in 
Greater Vancouver with excellent images for OSM use.


The only problem is I have been unable to keep up with the rate I've 
been taking pictures. This means there's a lot of information in 
Mapillary pictures that can be entered into OSM.


You can see the coverage at 
http://www.mapillary.com/map/im/12/49.2076/-122.8266. Note: The long 
straight lines are a bug in the Mapillary display.


Because I have the raw images and GPX files, I haven't bothered to 
figure out a good workflow for using the Mapillary images in JOSM, and 
end up having a browser window open on one screen and JOSM on the other 
if I do need to use images from someone else.


So, when mapping in Vancouver, consider Mapillary as a source.

Technical:
Images are captured at a settable interval, generally 2 seconds from a 
dash-mounted camera. Post-processing is then done for sharpness and 
contrast, time corrections applied, and the results correlated with GPX 
files from my GPS unit.


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

[Talk-ca] Central Park meetup: lot full

[Paul Norman]

The parking lot at swangard stadium is full for an event. Parking lot off of 
boundary nearest, marked for pool/stadium. Call 604 7792432 if needed. Wearing 
high vis osm vest


Sent from my iPhone

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

[Talk-ca] Canadian OSM POI quality

[Paul Norman]

I was curious how complete OpenStreetMap shop data was, so decided to
do an analysis for some Canadian chains.

The results were mixed. Starting with a Canada extract, I processed the
data into PostGIS and ran queries against name, brand and franchise for
objects where amenity, office or shop was null. Brands which have recently
changed names (e.g. Zellers/Target) were avoided.

OSM completeness varied from 7% to 81%, with no overwhelming trends. The
four major fast food and restaurants chains considered ranged from 33%
to 51%. Shops opening and closing change the accuracy of these results,
and the accuracy of the external sources for number of shops may be
variable.

Method
==

The geofabrik extract for Canada was imported with osm2pgsql with a
custom .style file containing name, operator, brand, franchise, amenity,
building, office and shop columns. The last four columns caused an object
to be placed in the polygon table. After import, the tables were filtered
to remove rows where there was not an amenity, office, or shop tag.
Appropriate indexes were added. A view was created combining the two
tables and giving lower-case versions of the name, operator, brand and
franchise tags.

Queries of the following form were run
  SELECT COUNT(*) FROM shops
WHERE lname LIKE :'name' OR lbrand LIKE :'name'
  OR lfranchise LIKE :'name';

:'name' was substituted in by psql for what I was searching for. For
example, 'mcdonald%' for McDonald's. The queries used were intended to
catch all possible shops even if it resulted in false positives. Brand
selection was not done in any systematic manner.

Public sources were used for the true number of shops of a particular
chain, generally Wikipedia or public data aggregators.

Results
===
   OSM   True   Completenmess
Tim Horton's  1480   4304   34%
Subway 849   2563   33%
McDonalds  722   1417   51%
Starbucks  592   1363   43%
Both OSM and Google use both Starbucks and Starbucks Coffee
A  W  292800   37%
Domino's67383   17%
Wendy's224369   61%
Burger King150281   53%
East Side Mario's   46 85   54%
Milestones  32 44   73%
Chili's 10 16   63%

Sears  105   15707%
Rona   122500   24%
The Bay 50421   12%
Walmart265382   69%
Home Depot  95180   53%

Canadian Tire  400491   81%
May be double-counting automative centers.
Chapters47233   20%
Sleep Country   22179   12%
London Drugs54 78   69%
May be double-counting some stores with a pharmacy inside

Remarks
===

It took significantly longer to find the true number of stores than
to get results from the OSM data. Part of this is my increased familiarity
with OSM tools, but a large part is that it is not necessary to track
down many different sources to get store counts.

Although no urban/rural analysis was performed, it is generally expected
that OSM is more complete in populated urban areas than low-density rural
areas, and completeness in these urban areas are often more important
for many uses.

No proprietary data sources were available for comparison, but it should
not be assumed that they are any more complete, nor that their name or
similar tagging is any more consistent. As an example, Google's data was
observed to use both Starbucks and Starbucks Coffee for the coffee
chain, sometimes having both for what was really the same location.

The tools used to generate counts could easily be used to extract the
shop data to work with.

Improving the data
==
Inconsistent tagging was observed with some shops, such as variability
between amenity=restaurant and amenity=fast_food. This should reflect
differences between locations but may not. Inconsistent names were also
observed, such as Walmart, Wal-mart, and Wal Mart. These issues
are not as significant as the large percentage of missing shops.

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

Re: [Talk-ca] Local Vancouver meeting

[Paul Norman]

Yes - change of date. June 14th, noon. I completely forgot about 
Father's day, which also causes difficulties for me.


On 2014-06-04 8:35 PM, B P Chin wrote:

Hi Paul,

June 15 is Father's Day. Any chance that you could this to another 
date? I would love to take part in this.


Peter

 From: talk-ca-requ...@openstreetmap.org
 Subject: Talk-ca Digest, Vol 76, Issue 2
 To: talk-ca@openstreetmap.org
 Date: Wed, 4 Jun 2014 12:00:02 +

 Send Talk-ca mailing list submissions to
 talk-ca@openstreetmap.org

 To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.openstreetmap.org/listinfo/talk-ca
 or, via email, send a message with subject or body 'help' to
 talk-ca-requ...@openstreetmap.org

 You can reach the person managing the list at
 talk-ca-ow...@openstreetmap.org

 When replying, please edit your Subject line so it is more specific
 than Re: Contents of Talk-ca digest...


 Today's Topics:

 1. Re: Local Vancouver meeting: Map Central Park (Clifford Snow)


 --

 Message: 1
 Date: Tue, 3 Jun 2014 09:53:03 -0700
 From: Clifford Snow cliff...@snowandsnow.us
 To: Paul Norman penor...@mac.com
 Cc: talk-ca talk-ca@openstreetmap.org
 Subject: Re: [Talk-ca] Local Vancouver meeting: Map Central Park
 Message-ID:
 cadaoplpofv6u2-zsq2n_i0pplrvngcdjstckfa6zuw6wzpb...@mail.gmail.com
 Content-Type: text/plain; charset=utf-8

 Paul,
 Thanks for scheduling the mapping party. I plan to attend along with one
 guest. I'll bring my GPS along with my Android phone with OSMTracker.

 Clifford


 On Tue, Jun 3, 2014 at 2:36 AM, Paul Norman penor...@mac.com wrote:

  I am planning on hosting a mapping event in Central Park (
  http://osm.org/way/23165846), in Burnaby, BC.
 
  My tentative date is Sunday, June 15th at around noon, but if 
people want

  a different time I could shift it.
 
  The park is a major park in the region, but under-mapped, with 
potentially

  not all of the trails.
 
  Some of the things I'd like to get mapped are
 
  - More appropriate tags for the trails. highway=track is probably not
  accurate
  - The surface of trails
  - Locations of fitness equipment in the park
  - Bathrooms
  - Picnic areas
  - Other park infrastructure
  - Anything missing or interesting
 
  At this time of year, it should be nice sunny weather, and the 
shade from

  the trees should be welcome.
 
  I intend to bring my mapping kit (camera, GPS, etc), as well as field
  papers type printouts on larger paper for us to mark up. I'm not 
planning

  on bringing a laptop, or if I do, it's staying in the trunk.
 
  After mapping, we can go somewhere nearby for food. I'd also like to
  discuss holding regular events.
 
  If you're interested, please let me know so that I know other 
people will
  be coming and to attend on time myself! I also need to have 
printouts made

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



 --
 @osm_seattle
 osm_seattle.snowandsnow.us
 OpenStreetMap: Maps with a human touch
 -- next part --
 An HTML attachment was scrubbed...
 URL: 
http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20140603/1c3e6e04/attachment-0001.html


 --

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


 End of Talk-ca Digest, Vol 76, Issue 2
 **


___
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] Local Vancouver meeting: Map Central Park

[Paul Norman]

I am planning on hosting a mapping event in Central Park 
(http://osm.org/way/23165846), in Burnaby, BC.


My tentative date is Sunday, June 15th at around noon, but if people 
want a different time I could shift it.


The park is a major park in the region, but under-mapped, with 
potentially not all of the trails.


Some of the things I'd like to get mapped are

- More appropriate tags for the trails. highway=track is probably not 
accurate

- The surface of trails
- Locations of fitness equipment in the park
- Bathrooms
- Picnic areas
- Other park infrastructure
- Anything missing or interesting

At this time of year, it should be nice sunny weather, and the shade 
from the trees should be welcome.


I intend to bring my mapping kit (camera, GPS, etc), as well as field 
papers type printouts on larger paper for us to mark up. I'm not 
planning on bringing a laptop, or if I do, it's staying in the trunk.


After mapping, we can go somewhere nearby for food. I'd also like to 
discuss holding regular events.


If you're interested, please let me know so that I know other people 
will be coming and to attend on time myself! I also need to have 
printouts made in advance.


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

Re: [Talk-ca] Adding a trail to OSM that is also a road

[Paul Norman]

You’re best off tagging the road (highway=track probably, maybe 
highway=unclassified) and indicating that it’s part of the Trans Canada Trail 
with a relation.

 

From: Brian Lang [mailto:bril...@gmail.com] 
Sent: Sunday, April 20, 2014 9:15 PM
To: Richard Weait
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Adding a trail to OSM that is also a road

 

In this case, the road is a Forest Service Road - often meaning low quality 
road, infrequent maintenance, lots of potholes and creeks running over the 
road. 4x4 recommended but in this particular case not required. I have both 
hiked and driven this section of road. The Trans Canada Trail IS the road. 

 

I was thinking it might be best to put a parallel set of lines for the Trans 
Canada Trail due to the fact that the road is not always open to vehicles. But 
as I'm new to using OSM, I figured I'd ask first.

 

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

Re: [Talk-ca] coastline between Montreal and Sorel, Quebec

[Paul Norman]

 From: perso...@charleskiyanda.com [mailto:perso...@charleskiyanda.com]
 Sent: Thursday, April 03, 2014 9:27 AM
 To: Harald Kliems
 Cc: talk-ca@openstreetmap.org
 Subject: Re: [Talk-ca] coastline between Montreal and Sorel, Quebec
 
 The question of where does the coastline end and riverbank start is a
 question that was probably debated at length 4-5 years ago with no
 clear resolution. The page does mention the great lakes as an example
 of lakes wrongly tagged with coastline, but that will probably stay
 like that in the near future. Personally, I think the great lakes
 should stay as coastline not just because it'd be hard to change. It
 might be worth coming to a consensus here first before we try to fix
 the coastline between Montréal and Sorel. Clearly, the current
 situation is suboptimal.

Last time the Great Lakes were discussed, the consensus was that they, 
along with a few substantial water bodies, should be tagged with 
natural=coastline. This isn't a question of rendering, it's a question 
of data modelling.  


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

Re: [Talk-ca] Fwd: workflow for elevation data

[Paul Norman]

 From: Richard Weait rich...@weait.com
 Date: Sun, Feb 23, 2014 at 4:40 PM
 Subject: Re: [Talk-ca] workflow for elevation data
 To: Charles Basenga Kiyanda perso...@charleskiyanda.com
 
 There was a service, run by long time OpenStreetMap user lambertus,
 that displayed an elevation profile graph of a selected way.  That
 specific source is gone or moved now, but this wiki page shows some of
 the similar details from a related summer of code project.
 
 http://wiki.openstreetmap.org/wiki/Route_altitude_profiles_SRTM
 
 It also appears that the routing engine YOURS can interpret elevation
 data to apply variable costing when evaluating or planning routes.
 
 http://wiki.openstreetmap.org/wiki/YOURS

OSRM can also use elevation data when planning routes. For an example
of this, including elevation profiles try http://cycle.travel/map,
generate a route, and click on the mountain icon to get a profile.

Unfortunately cycle.travel is UK only.


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

Re: [Talk-ca] Updating Langley and use of alt_name?

[Paul Norman]

 From: William Rieck [mailto:bi...@thinkers.org] 
 Sent: Friday, February 21, 2014 9:10 AM
 Subject: Re: [Talk-ca] Updating Langley and use of alt_name?
 
 Hi Paul, I was following your message until this statement, where 
 I got confused. Are you saying the city of Langley is not a city? 
 What do you mean by in British English?
  
  That's all fairly simple, but the place node is more complicated. 
  Langley is not a city in British English, but a town.

British English, as opposed to Canadian English or American English. OSM 
uses British English

Using a simpler example, Burnaby does not meet the British English 
definition of a city, but Vancouver does. Burnaby is a town. An 
incorporated area is not necessarily a city.

http://www.dict.org/bin/Dict?Form=Dict2Database=wnQuery=city includes
two definitions of city: 

n 1: a large and densely populated urban area; may include
   several independent administrative districts; Ancient Troy
   was a great city [syn: city, metropolis, urban
   center]
  2: an incorporated administrative district established by state
 charter; the city raised the tax rate

OSM is closer to the first definition. Historically a city was the see of 
a bishop, but that no longer holds.


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

Re: [Talk-ca] Updating Langley and use of alt_name?

[Paul Norman]

I’ve added the place node to both relations after discussions with Nominatim
experts. It’s a bit strange, but so is the situation. It seems to fix the
queries you gave.

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: Friday, February 21, 2014 7:52 PM
To: Pierre Béland; William Rieck; Paul Norman
Cc: talk-ca
Subject: Re: [Talk-ca] Updating Langley and use of alt_name?

 

Oups I was wrong in identifiying the polygons in JOSM. 

These are  two adjacent polygons, the city being surrounded by the township.
The difference in spelling comes from the alt_name=Langley. 

I should have mapped for the Night of the living map instead. Or maybe not!

 

Pierre 

  _  

De : Pierre Béland pierz...@yahoo.fr
À : William Rieck bi...@thinkers.org; Paul Norman penor...@mac.com 
Cc : talk-ca talk-ca@openstreetmap.org 
Envoyé le : Vendredi 21 février 2014 21h53
Objet : Re: [Talk-ca] Updating Langley and use of alt_name?

 

Looking at the Township and City of Langley, I see that these relations are
duplicate polygons that share the exact same nodes. Then why two relations?
Instead, would it be better to simply use alt_name for the city, added to
the Township of Langley.  Such Classification where you have two
admin_level=8 for the same area is a nonsense to my point of view. 

To show the inconsistencies that this creates, let's have a look at the
Nominatim links below. You will see how the Locality, Suburb, Residential
highways etc. are shared between the two. And most of the item are
classified under the Township. Some other elements under the City. But
searching Nominatims, you will see places classified either und the
Township, the City of simply Langley.

For example, if you search in Nominatim for 

*   Livingstone, Langley. Canada, this will be reported as Livingstone,
Township of Langley, Greater Vancouver Regional District, British-Columbia,
Canada
*   10 Avenue, Township of Langley, Greater Vancouver Regional District,
Colombie-Britannique, Canada
*   Brookswood, Township of Langley, Greater Vancouver Regional
District, Colombie-Britannique, Canada
*   201A Street, Brookswood, Langley, Greater Vancouver Regional
District, Colombie-Britannique, Canada


The best seems to make a choice for which locality title will be showed to
describe Langley and use an alt_name tag to describe the second appellation




*   City Boundary Township of Langley, Greater Vancouver Regional
District, Colombie-Britannique, Canada
http://www.openstreetmap.org/relation/2031947 
http://www.openstreetmap.org/relation/2031947
http://nominatim.openstreetmap.org/details.php?place_id=9164399767



*   City Boundary City of Langley, Greater Vancouver Regional District,
Colombie-Britannique, Canada http://www.openstreetmap.org/relation/2031946

http://www.openstreetmap.org/relation/2031946
http://nominatim.openstreetmap.org/details.php?place_id=98083231


 

 

Pierre 



  _  

De : William Rieck bi...@thinkers.org
À : Paul Norman penor...@mac.com 
Cc : talk-ca talk-ca@openstreetmap.org 
Envoyé le : Vendredi 21 février 2014 12h09
Objet : Re: [Talk-ca] Updating Langley and use of alt_name?

 

Hi Paul, I was following your message until this statement, where I got
confused. Are you saying the city of Langley is not a city? What do you mean
by in British English?

 


That's all fairly simple, but the place node is more complicated. Langley is
not a city in British English, but a town.

 

___
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] [OSM-legal-talk] Nouvelle licence de données ouvertes au Québec

[Paul Norman]

CC BY 3.0 and earlier had onerous attribution requirements for data. I believe 
4.0 fixes this. I don't think anyone has suggested contacting a data provider 
who's licensed under CC 4.0 licenses to clarify attribution.

The issue with 3.0 attribution are not purely theoretical, there have been 
providers who have objected to how we have attribution and we've been unable to 
use their data.

Sent from my iPad

 On Feb 21, 2014, at 1:58 PM, Mike Linksvayer m...@gondwanaland.com wrote:
 
 Asking for a clarification that provided attribution is OK seems over the top 
 too, at least for CC-BY, especially CC-BY-4.0, given You may satisfy the 
 [attribution conditions] in any reasonable manner based on the medium, means, 
 and context in which You Share the Licensed Material. If every attribution 
 needs to be clarified with the licensor to determine if it is OK, then 
 attribution licenses truly are a fail. But that practice is certainly not the 
 intent of such licenses.
 
 IMO, IANAL, etc etc.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Updating Langley and use of alt_name?

[Paul Norman]

 From: Daniel Friesen [mailto:dan...@nadir-seen-fire.com]
 Sent: Wednesday, February 19, 2014 3:10 AM
 To: talk-ca@openstreetmap.org
 Subject: [Talk-ca] Updating Langley and use of alt_name?
 
 I'm a little new to OSM, recently I found that neither of the city
 boundaries for the Langley area showed up in searches for Langley.
 The issue was that neither had any type of name entry with just
 Langley
 
 I added an alt_name=Langley to both of the boundaries myself:
 http://www.openstreetmap.org/relation/2031946 (City of Langley)
 http://www.openstreetmap.org/relation/2031947 (Township of Langley)

I think it's reasonable. Langley could refer to either, but it's 
not the official name of either, or the less formal name they commonly
use. alt_name sounds suitable.

For those who aren't local

- Both the City and Township are incorporated municipalities
  in local terms, which maps to admin_level=8
- They are adjacent, but do not intersect, nor are they within each other.
- The Township is much larger, and has open data. The City is smaller, and
  has GIS department consisting of one person.
- There is often no distinction between the two, and their addresses are on
  a grid layout 

That's all fairly simple, but the place node is more complicated. Langley is
not a city in British English, but a town. However, I'm not sure that 
its place=town node can be tied solely to the admin relation for one or the 
other. I'm not sure what to do, but one suggestion was to put it as the
label
of both.

Label is a bit of a misnomer really - the only current function of it is to 
Indicate that the place node and admin boundary somewhat refer to the same 
thing. It is not used by the standard stylesheet for rendering of
administrative 
boundary labels, nor are there plans for it to be 
(https://github.com/gravitystorm/openstreetmap-carto/issues/105)


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

Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec

[Paul Norman]

No one has raised the issue on legal-talk@ since CC 4 was released.

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: Thursday, February 20, 2014 8:43 AM
To: diane.merc...@gmail.com; Talk-ca (OSM)
Subject: Re: [Talk-ca] Nouvelle licence de données ouvertes au Québec

 

Merci Diane pour ces infos. 

Ce sont là de bonnes nouvelles pour la communauté OSM du Québec.

Espérons que nous aurons rapidement des nouvelles de la part du comité légal de 
OSM là-dessus.

 

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

[Talk-ca] CanVec updates without a version bump

[Paul Norman]

I was having a look at New Westminster in tile 092G02.1.1, and 
I noticed that there are differences between CanVec 10.0 which 
I downloaded when it came out and what I just downloaded from 
the CanVec webpage, which is also labeled CanVec 10.0

Addresses have been added, and with them, errors introduced.
Although I'm not opposed to adding addresses, adding a new feature
like this obviously needs discussion and review, and I checked imports@
and it doesn't look like this happened.

Who's our contact at NRCan these days? We need to make sure that the scope
of what's getting imported is clear and that additions get properly
discussed.




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

[Talk-ca] GNS tag cleanup

[Paul Norman]

About 6 years ago, a set of data was imported from GNS, consisting of place
names, mainly of place=town.

As an example, see http://www.openstreetmap.org/node/52556192/history

Thy have a few tags, many of which can probably be safely automatically
eliminated by editor software.

Using the example node, I think the following should be added to the
automatic removal list in editors


gns:dms_lat=490200
gns:dms_long=-1224900
gns:lat=49.03
gns:long=-122.816667
gns:n:xx:full_name=White Rock
gns:n:xx:full_name_nd=White Rock
gns:n:xx:modify_date=1993-12-14
gns:n:xx:sort_name=WHITEROCK
gns:cc1=CA

I'm not sure on the following. Anyone know their history, and if they're of
any use to OSM?

gns:adm1=02
gns:dsg=PPL
gns:fc=P
gns:jog=NM10-08
gns:mgrs=10UEV1340031177
gns:n:xx:nt=N
gns:rc=1
gns:ufi=-575923
gns:uni=-812858


Any comments?


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

Re: [Talk-ca] Parc Summit Montréal

[Paul Norman]

Both landuse=forest and natural=wood may be used to indicate an area with
trees. There are differing views about what the tags mean, so it is possible
for one person to sensibly use landuse=forest to map something while a
different person would use natural=wood to map that exact same thing.

 

From: Adam Martin [mailto:s.adam.mar...@gmail.com] 
Sent: Friday, January 10, 2014 11:19 AM
To: Simon Mercier
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Parc Summit Montréal

 

Bonjour Simon!

Forgive my lack of ability in writing french - hopefully it won't make a
difference. Took a look at the area that you are referring to. The area that
is designated as the park is a Forest while the other overlapping area is
designated as Wood. From looking over the maps provided by the City of
Montreal (http://www.lemontroyal.qc.ca/carte/en/index.sn), it would appear
that the overlap is incidental - the park area includes much of the green
space boxed in by the road and administrative boundary, but not all of it.
In fact, the park is separated from the administrative boundary by a small
gap. It appears that it should actually be connected to that boundary.

The use of Forest is odd - this is a designated park and would likely be
better suited to be noted as amenity=park. It is arguable that Forest is
not the predominate use for the area as that tag tends to be used for areas
that are managed by humans for the purposes of harvesting. Is having the
landuse here actually necessary? Using the amenity tag for a park appears to
override the Forest tag with the actual use of the land (for recreational
purposes).

Hope that helps.

 

Adam

 

2014/1/10 Simon Mercier smerc...@mapgears.com


Bonjour

Je me demande s'il s'agit d'une erreur ou simplement circonstanciel?
Est-ce qu'il s'agit pour un d'une limite administrative de parc (20187021)
et l'autre de la forêt(189610345)?Ça me semble tout de même ambigu!

http://www.openstreetmap.org/way/189610345
http://www.openstreetmap.org/way/20187021

merci



-- 
simon mercier
co-fondateur solutions mapgears
2383 che ste-Foy bur 202 québec, qc
canada G1V1T1

t_418_476_7139#101
m_418_559_7139
simonmercier.net / mapgears.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

[Talk-ca] Nanaimo OGL license

[Paul Norman]

Previously[1] I looked at the OGL - Canada 2.0. The federal government 
opinion is that the license is compatible with the ODbL and CC BY. The 
OKFN regards the OGL - Canada 2.0 as meeting the Open Definition. 

The OGL - British Columbia and OGL - Nanaimo are different licenses. 
Aside from formatting, branding and jurisdictional differences, the two 
significant changes are the addition of an exemption, and defining 
Information to include Records[2]. The exception is to not license 
Information or Records not accessible under the Freedom of Information 
and Protection of Privacy Act (B.C.) [(FIPPA)] 

Although it has not come up for a vote, the view on the Open Definition 
mailing lists[3] is that this exemption makes the license non-open 
because it is impossible or impractical for a user to know if the 
license is applied to a particular work, or if it falls under one of the 
exemptions. The vagueness comes from two sources: difficulty in 
interpreting what is meant in the license, and difficulty evaluating if 
a particular work falls under a FIPPA exemption. I have more information 
about the possible interpretations of this phrase and different types of 
FIPPA exemptions, but see no need to go into that at this time. 

If it were not for this exemption, I do not see anything that would 
cause its ODbL compatibility to differ from the OGL - Canada 2.0. 

Fortunately, there is a way around the vagueness of the exemption: to 
find out the FOI status explicitly. I asked the City of Nanaimo about 
the orthophotos, addressing and roads data and their FOI officer 
informed me that I may treat those datasets as released 'in accordance 
with the Provincial Freedom of Information and Protection of Privacy 
Act'. 

This does NOT apply to all Nanaimo datasets, nor to other datasets 
released by other cities under similar licenses. I would *expect* all 
datasets on data catalogue sites in BC to be released in accordance with 
FIPPA, but I believe it is necessary to verify this. 

I have no import-related plans at this time for the addressing or roads 
data, but I've had multiple requests to make the orthophotos available 
as a background for editing, as they are significantly better than Bing. 
I may do an overlay with the roads data, similar to the TIGER 2013 
overlay, or what I did for Kelowna[4]. Kelowna's data is under the PDDL, 
which made it legally much easier to work with.

The effort involved in verifying that a license used only by one city is 
usable shows how custom licenses significantly increase the work for 
data consumers (e.g. OpenStreetMap), particularly if multiple data 
sources are involved. It would be significantly easier if the data was 
released following best practices and used an established license such 
as, in order of preference: CC0, PDDL, CC BY 4.0, or ODC-BY.

[1]:
https://lists.openstreetmap.org/pipermail/legal-talk/2013-November/007668.ht
ml
[2]: https://gist.github.com/pnorman/7716944
[3]: https://lists.okfn.org/pipermail/od-discuss/2013-October/000633.html
[4]: http://tile.paulnorman.ca/demo/kelowna.html


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

Re: [Talk-ca] Problem with overpasses in NB??

[Paul Norman]

 From: Daniel Begin [mailto:jfd...@hotmail.com]
 Sent: Monday, December 02, 2013 1:34 PM
 To: 'Richard Weait'; 'Connors, Bernie (SNB)'
 Cc: 'Talk-CA OpenStreetMap'
 Subject: Re: [Talk-ca] Problem with overpasses in NB??
 
 Provinces provide roads to NRCan that simply package it for GeoBase and
 Canvec. I might be wrong but I am on the impression that some provinces
 (not all) create vertices at intersections (2D) and do not consider the
 elevation (3D). When converting to OSM, duplicated vertices (one on each
 road) are merged in one node.

The problem is often one of formats. Shapefiles are often used to 
interchange this data, but shapefiles do not have topology. A common 
toolchain used for getting data from an ESRI-based server to shapefiles
results in files that say that wherever two features cross they join. 

This is the type of mistake that someone doing an import needs to catch
and fix before uploading. The fastest fix I've found in JOSM is to merge the

two bridge ways, merge the two under-bridge ways, and delete the node where
they intersect.


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

[Talk-ca] Making use of Kelowna open data

[Paul Norman]

I've been setting up a new server and setting up new imagery and other 
resources for the OSM community. 

One that's basically finished is some stuff making use of the City of 
Kelowna data, published under the PDDL. 

I've put up a page demoing what I've done at 
http://tile.paulnorman.ca/kelowna.html. I have an overlay generated from 
the city road and lanes data and imagery also from the city. A close-up 
example is http://tile.paulnorman.ca/kelowna.html#20/49.8873/-119.4972.

You can switch to an OpenStreetMap background, although this only goes 
to zoom 19. The road names are in caps because that's how the data comes.

I'll be adding these layers to the editors soon, once I make certain 
everything is stable and make a few setup tweaks. Along those lines, 
don't be too surprised if there are intermittent issues while I get 
everything setup! I'm also thinking of asking Firefishy to point 
tile.openstreetmap.ca at the host because I plan on putting a number of 
Canadian layers there. 

I know there is some desire for the City of Nanaimo imagery and other 
imagery licensed under OGL variants, but until we figure out if their 
licenses are compatible with the ODbL I'm holding off because we can't 
use them with OpenStreetMap yet. 

Technical details: 

The imagery is an ECW file, served and cached with mapproxy in front of 
mapserver. The overlay data is downloaded and imported into postgresql 
with a script, cleaned up in postgres, and then served and cached with 
mapproxy and rendered with mapnik. 

The relevant scripts are at https://github.com/osm-ca/road-overlay-scripts 
and https://github.com/osm-ca/mapproxy-config-faramir. 



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

Re: [Talk-ca] [OSM-legal-talk] Open Government License - Canada

[Paul Norman]

I got word back indicating that the OGL - Canada 2.0 is ODbL and 
CC BY compatible. This makes it easy for us to use.

I want to offer my profound thanks to the federal government and the 
people I talked to in it for being willing to answer questions about 
licensing.


 -Original Message-
 From: Paul Norman [mailto:penor...@mac.com]
 Sent: Sunday, November 03, 2013 8:29 PM
 To: 'Licensing and other legal discussions.'
 Cc: 'Levene, Mark'; 'David E. Nelson'; talk-ca@openstreetmap.org
 Subject: [OSM-legal-talk] Open Government License - Canada
 
 cc'ing to a few people who I have talked about this with in the past.
 
 Some governments in Canada have released data under the Open Government
 Licence - Canada, version 2.0. This is yet another new license. Some
 people have asked if we can use datasets available under this license.
 
 http://data.gc.ca/eng/open-government-licence-canada contains the full
 text of the version the Federal government is using. It is an
 attribution license and in a perfect world would be ODbL compatible. Of
 course we've seen plenty of attribution licenses screw something or
 other up.
 
 What is not obvious is that they expect other levels to modify the
 license to localize it with the information of their attribution
 statement and local laws, but let's start with the Federal one first.
 Once that's done we can look at BC, AB, Nanaimo, Vancouver... etc.
 
 One of the statements in the consultation on this license was The
 change of the attribution statement from OGL v1.0 to be one specific to
 the federal government reduces the ability to reuse this license by
 other jurisdictions (e.g. provinces) and will increase the number of
 licenses that have to be analysed.
 
 The origin of this license is the OGL 1.0, a UK license.
 
 The principle difference between UK and Canadian law is that database
 right does not exist in Canada.
 
 http://opendefinition.org/licenses/ lists OGL Canada 2.0 as an Open
 Definition conformant license.
 
 The question that matters for OSM is, can OGL Canada 2.0 datasets be
 released under the ODbL.
 
 One issue raised as problematic in some versions of the license is
 Personal Information
 
 For OSM, I do not see this as an issue. Personal Information is
 information about an identifiable individual, but datasets we would be
 interested in are information about places, not individuals.
 
 Third-party rights are a rights-clearing issue and something we'll need
 to check before using any source.
 
 Names, crests, etc and other IP rights would not be found in datasets of
 interest to OSM.
 
 Attribution is an odd one because they refer to information providers in
 the plural, but define it in a way so that it is only singular, so it's
 not clear which part of the attribution requirements applies. The ODbL
 requires that any copyright notices be kept intact for derivative
 databases. Produced works require a notice reasonably calculated to make
 any Person [...] aware that the content was obtained from [the
 database]. Attribution looks ODbL compatible, provided we figure out
 what statement to use.
 
 I'm not really sure where to take it from here in terms of an analysis.
 
 
 ___
 legal-talk mailing list
 legal-t...@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/legal-talk


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

Re: [Talk-ca] CanVec 10 Data

[Paul Norman]

I don't believe CanVec has any addressing info in metro Vancouver, so no
conflict there. 

I'd also hope that if people regard addresses as important they've been
collecting them in surveys when out mapping, so there are address already
there that should *not* generally be replaced by CanVec data.

 From: Steve Roy [mailto:st...@ssni.ca]
 Subject: Re: [Talk-ca] CanVec 10 Data
 
 Agreed.  I see that Paul Norman imported some of the City of Surrey GIS
 data a couple of years ago and that included house numbers.
 
 Cheers
 Steve
 
 On 04/11/2013 6:16 AM, Harald Kliems wrote:
  I think Daniel's email got cut off at the end :-)
 
  On Mon, Nov 4, 2013 at 6:26 AM, Daniel Begin jfd...@hotmail.com
  mailto:jfd...@hotmail.com wrote:
 
  I'm not familiar with imports using Potlatch but importing it
 using
  JOSM is
  quite easy - open the file, select the features, copy then in a
 new
  layer
  and then upload the layer in OSM...
 
  ...after you've carefully checked if everything is plausible and you
  don't mess up the work of other contributors who may already have
  added housenumber data of better quality.



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

[Talk-ca] Open Government License - Canada

[Paul Norman]

cc'ing to a few people who I have talked about this with in the past.

Some governments in Canada have released data under the Open Government 
Licence - Canada, version 2.0. This is yet another new license. Some 
people have asked if we can use datasets available under this license. 

http://data.gc.ca/eng/open-government-licence-canada contains the full 
text of the version the Federal government is using. It is an 
attribution license and in a perfect world would be ODbL compatible. Of 
course we've seen plenty of attribution licenses screw something or 
other up. 

What is not obvious is that they expect other levels to modify the 
license to localize it with the information of their attribution 
statement and local laws, but let's start with the Federal one first.
Once that's done we can look at BC, AB, Nanaimo, Vancouver... etc.

One of the statements in the consultation on this license was The 
change of the attribution statement from OGL v1.0 to be one specific to 
the federal government reduces the ability to reuse this license by 
other jurisdictions (e.g. provinces) and will increase the number of 
licenses that have to be analysed. 

The origin of this license is the OGL 1.0, a UK license. 

The principle difference between UK and Canadian law is that database 
right does not exist in Canada. 

http://opendefinition.org/licenses/ lists OGL Canada 2.0 as an Open 
Definition conformant license. 

The question that matters for OSM is, can OGL Canada 2.0 datasets be 
released under the ODbL. 

One issue raised as problematic in some versions of the license is 
Personal Information 

For OSM, I do not see this as an issue. Personal Information is 
information about an identifiable individual, but datasets we would be 
interested in are information about places, not individuals. 

Third-party rights are a rights-clearing issue and something we'll need 
to check before using any source. 

Names, crests, etc and other IP rights would not be found in datasets of 
interest to OSM. 

Attribution is an odd one because they refer to information providers in 
the plural, but define it in a way so that it is only singular, so it's 
not clear which part of the attribution requirements applies. The ODbL 
requires that any copyright notices be kept intact for derivative 
databases. Produced works require a notice reasonably calculated to make 
any Person [...] aware that the content was obtained from [the 
database]. Attribution looks ODbL compatible, provided we figure out 
what statement to use. 

I'm not really sure where to take it from here in terms of an analysis.


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

Re: [Talk-ca] Do we tag addresses on buildings or on separate nodes?

[Paul Norman]

Interpolations are generally regarded as approximations until we can get 
individual addresses mapped. The post in case was about if was more common to 
map a building with an address as one way with a building tag and address tags 
or as one way with a building tag and a node with address tags. It is more 
common to use a way with both a building tag and address tags by at least 10:3.

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: Thursday, October 24, 2013 7:34 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Do we tag addresses on buildings or on separate nodes?

 

Hi,

What do you think of this blog?  Adress nodes versus interpolations?
That's quite confusing :-/

What is the OpenStreetMap convention? Do we tag addresses on buildings or on 
separate nodes? http://t.co/tjRiwYSXLF 

Bruno

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

Re: [Talk-ca] Aerial imagery for Nanaimo, BC

[Paul Norman]

License issues seem to expand to fill my available time.

 

Nanaimo’s license is different than the OGL (a UK license) in a few ways. I
don’t think anyone has analyzed it for ODbL compatibility. One minor mistake
that was made was defining an Information Provider solely as The City of
Nanaimo, unlike the original OGL which defined it as the person or
organization. That’s the biggest issue I’m aware of with it, but I believe
when publishing open data under a self-developed license the onus should be
on the on the publisher to consider compatibility with other licenses. After
all – what good is open data if you can’t combine it with existing data
sets. 

 

There are one or two datasets I would love to use immediately and a few more
I would like to use when I get the time to sit down and do some work, but
both are on hold because I’m not certain if their license is ODbL
compatible.

 

It would be helpful if the publisher of the data or the license (The City of
Nanaimo) made a statement on the compatibility of their license with the
OGL. It’d also be useful to know about CC BY/CC BY-SA compatibility, but
that isn’t necessary for use with OSM.

 

From: Tim Whitehead [mailto:spero.shirope...@gmail.com] 
Sent: Sunday, October 20, 2013 4:55 PM
To: 'David E. Nelson'
Cc: 'Paul Norman'; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Aerial imagery for Nanaimo, BC

 

I am no legal person by any means, and Nanaimo has adopted v2 of the OGL
since I last looked at it. Paul Norman mentioned he was going to look into
it when there was a moment to do so.

The way I read v2 of the license is that it is available to use so long as
you acknowledge the source with the defined attribution statement of the
region.

 

“Contains information licensed under the Open Government Licence - Nanaimo.”

 

If multiple sources were used or multiple attributions are not practical,
one would use

 

“Contains information licensed under the Open Government License – British
Columbia.”

 

http://www.nanaimo.ca/EN/main/departments/106/DataCatalogue/Licence.html

http://www.data.gov.bc.ca/local/dbc/docs/license/OGL-vbc2.0.pdf

 

Though it looks like they missed updating the last paragraph under
Versioning.

 

 

To answer your actual question though, nope I am not aware of another WMS
source J

 

Cheers,

Tim 

 

From: David E. Nelson [mailto:denelso...@yahoo.ca] 
Sent: October 20, 2013 4:12 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Aerial imagery for Nanaimo, BC

 

Does anyone know of an OSM-compatible free WMS source we can use for aerial
imagery for all of Nanaimo?  Bing does not have street-level imagery for
Nanaimo north of 49.14°N and east of 123.94°W

 

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

Re: [Talk-ca] Aerial imagery for Nanaimo, BC

[Paul Norman]

We seem to be jumping ahead a bit quickly. We haven’t solved the legal
issues about using any of their data, so it seems premature to be worried
about the technical details.

 

Once the legal issues get cleared up I can easily take the Nanaimo imagery
and host an imagery layer which can be added to the defaults of the editors,
making it available for all.

 

From: Tim Whitehead [mailto:spero.shirope...@gmail.com] 
Sent: Sunday, October 20, 2013 6:58 PM
To: 'David E. Nelson'
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Aerial imagery for Nanaimo, BC

 

There is also an Opendata plugin that can be added for some of the formats

 

I am not familiar with all the formats available – Shape (SHP), Keyhole
(KML) can be opened directly in the achieve they are downloaded in– I would
create a new layer first, and it’ll prompt you for what you want to open
(I,e, road centre lines, sidewalks, etc).

http://wiki.openstreetmap.org/wiki/Import/Shapefile

http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData

 

If you wanted to use the tiff file… I do not believe they supply a world
file in the achieve so you would need something like the Piclayer plugin (I
believe) 

 

 

From: David E. Nelson [mailto:denelso...@yahoo.ca] 
Sent: October 20, 2013 6:08 PM
To: Tim Whitehead; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Aerial imagery for Nanaimo, BC

 

 Could get that from their data source?

 
http://www.nanaimo.ca/EN/main/departments/Engineering-Public-Works/GIS/Digi
 
http://www.nanaimo.ca/EN/main/departments/Engineering-Public-Works/GIS/Digit
alData.html

 http://data.nanaimo.ca/  http://data.nanaimo.ca/

 http://www.nanaimo.ca/ortho/  http://www.nanaimo.ca/ortho/ (553A)



 Building/Properties/Road ways are available and can be overlayed in JOSM.

And how do I do that?  How do I import that data, both ways and photos, into
JOSM?

 

- David E. Nelson

attachment: winmail.dat___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-ca] Lake Erie shores

[Paul Norman]

I happened across http://www.openstreetmap.org/browse/relation/1205150, a
relation with name=Lake Erie.

My recollection is that last time this came up we decided that as the Great
Lakes are large lakes by any reasonable standard they are best represented
as natural=coastline. Thousand-member MPs simply do not work. Right now they
are both a natural=water MP and natural=coastline ways. 

Unless anyone recalls differently I'll go ahead and verify that the
coastline is building correctly then clean up the MPs. I'm pretty sure the
coastline is building as if it weren't we wouldn't see the great lakes at
low zooms

I'll also clean up stuff like 1205139. See
http://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories


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

Re: [Talk-ca] Open Government Licence

[Paul Norman]

 From: Steve Singer [mailto:st...@ssinger.info]
 Cc: 'Matthew Buchanan'; talk-ca@openstreetmap.org
 Subject: Re: [Talk-ca] Open Government Licence
 
 Wouldn't the  multiple Information Providers kick is as soon as you
 combined data from Vancouver with any other source such as the existing
 OSM database?

No. OpenStreetMap is not The City of Vancouver and therefore not an 
Information Provider as defined in the license.


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

[Talk-ca] Kelowna Open Data

[Paul Norman]

I don't know how this slipped under my radar, but Kelowna BC has open data,
licensed under the PDDL. I see that they have 2012 aerial photos, which I'll
work on hosting, although I might need to upgrade my server first.

What's more interesting is they have some address data. If there is a local
desire I could look at doing something with this.


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

Re: [Talk-ca] Open Government Licence - Canada

[Paul Norman]

 From: Stewart C. Russell [mailto:scr...@gmail.com]
 Subject: [Talk-ca] Open Government Licence - Canada
 
 [I guess Bernie's original subject of ‘G8 leaders sign open data charter
 of principles’ might've made this important announcement sink without
 trace.]
 
 Bernie Connors wrote:
 
  Is there an official OSM opinion on the compatibility of the Open
  Government Licence and OpenStreetMap?  Here is a link to the licence
  on the data.gc.ca website –
 
  http://www.data.gc.ca/eng/open-government-licence-canada
 
 It would be very helpful if it were deemed acceptable. The somewhat damp
 few who made it out to the Toronto Mappy Hour last night discussed it,
 but couldn't come up with anything official.

The good: It's very similar to the OGL, which is compatible. This should 
minimize the analysis.

The bad: It's only somewhat similar, leading to yet another regional license to 
analyze.

The ugly: They put terms specific to the federal government in the license and 
expect every city and province to modify the license. This is going to not work 
well.


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

Re: [Talk-ca] Advice on Addressing

[Paul Norman]

Individual addresses are always preferable to interpolation lines,
interpolation lines are just an approximation so if you have all the
addresses in a block you shouldn't also have interpolation lines as the
latter duplicates the former.

 

As for how to tag the addresses, if they're buildings with only one address
I prefer put the addresses on the buildings. For more complicated situations
with multiple addresses per building you'll often end up with points for
addresses, and these points often also have shop information.

 

 

From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca] 
Sent: Monday, May 27, 2013 6:48 AM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Advice on Addressing

 

Hello,

 

With respect to Nominatim and OSM routing applications is
there are better way to add address data to OSM?  I have started adding some
address data in my neighborhood but I am wondering if tagging buildings with
an address is better or worse than digitizing address interpolation lines?

 

http://www.openstreetmap.org/?lat=45.90249493718147
http://www.openstreetmap.org/?lat=45.90249493718147lon=-66.69308423995972;
zoom=18 lon=-66.69308423995972zoom=18

 

Thanks,

Bernie

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

Re: [Talk-ca] New OpenStreetMap web editing option now available, call for funding

[Paul Norman]

Chances are good that this is a bug with HTTPS anywhere and Firefox. If you
are using that extension with Firefox, disable the OpenStreetMap Wiki
ruleset.

 

See https://trac.torproject.org/projects/tor/ticket/8841 for the
corresponding HTTPS anywhere ruleset bug.

 

From: Stewart Russell [mailto:scr...@gmail.com] 
Sent: Wednesday, May 08, 2013 5:30 AM
To: talk-ca
Subject: Re: [Talk-ca] New OpenStreetMap web editing option now available,
call for funding

 

On Tue, May 7, 2013 at 3:48 PM, Fabian Rodriguez magic...@member.fsf.org
wrote:

http://blog.openstreetmap.org/2013/05/07/openstreetmap-launches-all-new-easy
-map-editor-and-announces-funding-appeal/

 

All I get is a blank white screen with iD on Firefox 20.0.1 (aka current
release). That might be a bit of a hurdle for new editors ...

 Stewart

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

Re: [Talk-ca] Question?

[Paul Norman]

This is not correct – there are no mandatory tags, and there is no legal reason 
why a source tag can’t be removed. Incidentally, source tags are perhaps the 
ones most frequently removed as osm2pgsql drops them by default.

 

If you’re looking at doing an import 
http://wiki.openstreetmap.org/wiki/Import/Guidelines is what you need to read. 
It’s important to note the requirement to consult with both the talk-ca@ and 
the imports@ mailing lists. This is important because it means if you missed 
something else someone else might spot it.

 

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: Monday, April 22, 2013 6:55 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Question?

 

*   It is mandatory to  mention origin and milesim of Opendata, within a 
tag, for instance Direction générale des finances publiques - année 2008. 

Source = 
http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Conditions_d%27utilisation

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

Re: [Talk-ca] openstreetmap.ca

[Paul Norman]

 From: Darryl Shpak [mailto:dar...@shpak.ca]
 Subject: [Talk-ca] openstreetmap.ca
 
 Good morning everyone,
 
 So: I am just about to renew this domain for another year. I would like
 to pass control of the domain over to the Canadian mapping community, to
 someone who will do something -- anything! -- with it that will be
 beneficial to Canadian users and/or mappers.

I'm running some imagery that I'd of liked to put on openstreetmap.ca. Of
course the URLs are all out there now under my personal domain name.

I could also host www.openstreetmap.ca, and if we got resources (+someone
with cartographic design skills) I could manage a Canadian tile layer.


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

Re: [Talk-ca] Copyright in data

[Paul Norman]

Thanks for the link.

 

It's good to see a court decision reminding parties that (in Canada) there
is no copyright in data.

 

From the court decision: However, there is no principle of property law
that would preclude anyone from making use of information displayed in a
publicly available paper nautical chart, even if the information originated
with the Crown or is maintained by the Crown.

 

It looks like with the summary motion dismissed and the matter going to
trial will be what the Crown granted exclusive license to one of the parties
in the case. My reading is that if the Crown only licensed the information
(one reading of the contract) then the case cannot succeed because the party
who initiated the case would of not had exclusive rights as the data does
not have any exclusive rights (or any rights) that could be licensed.

 

On the other hand, an alternate reading of the contract is that the Crown
licensed the data and CHS Works (paper charts), in which case that party
would have had some exclusive rights. Of course this leaves open the
question of if those rights were infringed, which gets to an interesting
question for OSM because it boils down to distinguishing between data which
is not protected by copyright and a map, which may be.

 

From: Begin Daniel [mailto:jfd...@hotmail.com] 
Sent: Friday, March 22, 2013 4:00 AM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Copyright in data

 

Bonjour all,

here is a link here that might be interesting for those of you that are
interested in legal matter concerning data

http://www.teresascassa.ca/index.php?option=com_k2
http://www.teresascassa.ca/index.php?option=com_k2view=itemid=124:federal
-court-of-appeal-reminds-government-there-is-no-copyright-in-data
view=itemid=124:federal-court-of-appeal-reminds-government-there-is-no-cop
yright-in-data

 

Daniel

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

Re: [Talk-ca] New Bing imagery in Montreal

[Paul Norman]

With the new Montreal open data, perhaps they have aerial photography they
can release? Or perhaps they already have, but I couldn't find any. If
someone can get it, I can host it.

 

From: nicholas ingalls [mailto:nicholas.inga...@gmail.com] 
Sent: Sunday, March 03, 2013 11:18 AM
To: Harald Kliems; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] New Bing imagery in Montreal

 

You are lucky then. Just the other day Saint John  area got updated with
stuff from late 2012. its great that they are getting around to updating it
but the imagery is more oblique than vertical making it very difficult to
trace. As well they are really low quality compared to their predecessors.
The new ones are faded out where the old ones were sharp and colourful.
These look like an instagrammer got at them!

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

Re: [Talk-ca] Licence de données ouvertes, Montréal

[Paul Norman]

 From: Harald Kliems [mailto:kli...@gmail.com]
 Sent: Sunday, March 03, 2013 7:28 AM
 Subject: Re: [Talk-ca] Licence de données ouvertes, Montréal
 
 On Sat, Mar 2, 2013 at 3:58 PM, Paul Norman penor...@mac.com wrote:
 
  Lastly, cadastral data is probably the least exciting type of data for
 OSM.
  Other data like roads, addresses and even buildings is more useful.
 Oh, I thought cadastral data would include building outlines? At least
 that's the case with the somewhat controversial French cadastre imports.
 Did I get excited prematurely?

The exact definition varies, but the generally accepted definition in North
America is the zoning, tax or property lot information. It does not include
buildings, roads, waterways, sewer infrastructure, etc. 

It does not generally contain addresses because there is not a one to one
relationship between cadastral areas and addresses.

I was talking with several people last week about an integrated cadastral
fabric for BC. 

Cadastral information is actually fairly useful as open data, but most
people who would want to use it would be forced to get it from the city
anyways. There can be some information useful to OSM in it, but generally
most of the information is not relevant to us. I tried extracting useful
information from Surrey's cadastral layer and found it a lot of work.

I did a presentation on open data and OSM to an audience with many open data
publishers and I ranked the most useful data as orthophotos, addresses and
roads. Orthos because good ones are hard or expensive to get and cities
often have excellent ones. Addresses because they're useful for geocoding,
annoying to collect manually, and well suited to conflating with existing
data. Roads because the road network is generally considered to be one of
the most important parts of OSM, so even if the roads are only marginally
better than CanVec they can still be useful.


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

Re: [Talk-ca] Licence de données ouvertes, Montréal

[Paul Norman]

It’s good to see more municipalities opening up their data and open data 
catching on. Seeing more municipalities writing their own licenses isn’t so 
good.

 

Now, on to the more practical questions needed to use the data.

 

Could you provide a translation of 4.1 and 4.2 of their license? Are these 
identical to CC BY?

 

One of the problems with CC BY is the vagueness of the attribution. Some cities 
regard our attribution as not meeting the CC BY attribution requirements, 
although I guess that isn’t an issue here because they’ve explicitly said it’s 
compatible with ODbL, so I have to assume that meeting the ODbL attribution 
requirements (met by listing on 
http://wiki.openstreetmap.org/wiki/Contributors) is sufficient for them.

 

What’s the Import Workgroup you refer to?

 

Lastly, cadastral data is probably the least exciting type of data for OSM. 
Other data like roads, addresses and even buildings is more useful.

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: Saturday, March 02, 2013 9:05 AM
To: talk-ca
Subject: [Talk-ca] Licence de données ouvertes, Montréal


After consultation with the community, the city of Montreal changed its 
OpenData license the 28 February 2013. It is clearly stated on the page of the 
license:

It is similar to a Creative Commons license CC-BY. For example, it is 
compatible with the more restrictive type ODbL licenses such as OpenStreetMap.

See http://donnees.ville.montreal.qc.ca/licence/

On the Open Data day, Saturday, February 23, representatives of the city have 
also offered to provide cadastre data. This would greatly contribute to enrich 
the map of Montreal. If people are interested in contributing to this issue, 
please contact me. 

This is a good news for the community of free data, developers and all those 
who believe in a greater participation of citizens. The city of Montreal, by 
amending its license, contributes to develop an eco-system where OpenData 
creators OpenSource developpers, governments and citizens collectively 
contribute to enrich the information and dialogue.

We should of course assure with the Import Workgroup that this license is 
compatible with OSM. 

We hope that this example will be followed by others, including the Government 
of Quebec and Quebec City.

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

Re: [Talk-ca] GeoBase tags

[Paul Norman]

 From: Andrew Allison [mailto:andrew.alli...@teksavvy.com]
 Subject: [Talk-ca] GeoBase tags
 
 Hello:
 
   Are the Geobase attribution tags relevant, should I leave them in
 or strip them out?

There's no legal reason why you can't remove the attribution=* tags (or any 
tag, for that matter).

My practice is to remove them when the source=* tag indicates that the source 
is geobase and I'm editing the way anyways. There may be other import cruft 
that you want to strip out at the same time.


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

[Talk-ca] Fwd: [OSM-talk] (sans objet)

[Paul Norman]

I see that there is an event in Vancouver and some people from the city will be 
there. I'd like to compile a list of issues with the Vancouver license 
beforehand. I know rweait had some as blog posts but I think they're offline.

Sent from my iPad

Begin forwarded message:

 From: Pierre Béland infosbelas-...@yahoo.fr
 Date: 9 January, 2013 8:26:10 PM EST
 To: talk t...@openstreetmap.org
 Subject: [OSM-talk] (sans objet)
 Reply-To: Pierre Béland infosbelas-...@yahoo.fr
 
 I propose to have discussions that are more fun for all of us than the ones 
 in the last few days.
 
 The International Open Data Hackathon on Feb 23 is an opportunity for OSM 
 developpers and mappers to work together and have fun. We could let people 
 better know OSM and licensing problems we face with so called governments, 
 municipalities OpenData not so open. 
 
 This event is already scheduled in many cities and they ask to propose 
 projects.  An OSM project could be proposed for adding data to OSM, exporting 
 from OSM, adapting APIs, etc.
 
 see http://wiki.opendataday.org/Main_Page
  
 Pierre
 ___
 talk mailing list
 t...@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] [OpenDataBC] Call for Speakers @ Open Data BC Summit on Feb 19, 2013 Vancouver

[Paul Norman]

Resenting to the right address...

Sent from my iPad

On 2013-01-03, at 12:09 PM, Paul Norman penor...@mac.com wrote:

 I'm considering going to this conference and presenting on OSM use of open 
 data. I figure it might be of interest to a few people as data used by us 
 will be used by Wikipedia, wolfram alpha, MQ open, assorted phone apps, etc...
 
 I'm open to other ideas, particularly as I'm on vacation until 2 days before 
 the call for presentations ends. Also if anyone else is interested it makes 
 sense to coordinate.
 
 Sent from my iPad
 
 Begin forwarded message:
 
 From: Nelson Lah nla...@shaw.ca
 Date: 3 January, 2013 1:26:02 AM EST
 To: nla...@shaw.ca
 Subject: [OpenDataBC] Call for Speakers @ Open Data BC Summit on Feb 19, 
 2013 Vancouver
 Reply-To: opendat...@googlegroups.com
 
 Hi Folks,
 
 Now that we have all survived the End of the World, Christmas and New Year, 
 this will be easy...
 
 The Open Data Society of BC is hosting the BC Open Data Summit on February 
 19, 2013 in downtown Vancouver at SFU Segal Graduate School of Business at 
 500 Granville Street.  We are inviting you to be part of this conversation.
 
 We're especially proud of what the BC open data community has accomplished 
 over the past three years since we first started growing our community.  At 
 the beginning, the thought of accessing data on a government web site was 
 tricky business (imagine wanting access to government data!).  We had to 
 sort out challenges around licensing, formats, methods of access...the 
 works.  Through many great conversations and threads here and elsewhere, we 
 have thankfully sorted out much of the WHAT of open data.
 
 Now that we have some open data accessible to us, we thought it would be 
 helpful to focus on the value that it can bring.  We want to explore how it 
 is being used in academia, in evidence-based decision making, in fighting 
 corruption, in uncovering new opportunities, and in creating economic value, 
 businesses and jobs.
 
 That's why we're inviting you to join us at the BC Open Data Summit in 
 February.  
 
 We are calling you to come out and make a short presentation.  Share your 
 ideas, and what you or your organization has done with open data to create 
 value.  Proposals are due by January 13.  
 
 More information is available here: 
 http://www.opendatabc.ca/bc-open-data-summit-2013-call-for-speakers.html
 
 Many thanks.
 
 Nelson Lah
 Summit Chair
 on behalf of Open Data Society of BC
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Osmose, Outil de qualité, maintenant disponible pour le Québec

[Paul Norman]

I’ve been looking at a bot to fix the double-space issue with
CanVec/Geobase, but no idea when I’ll have the time for it so don’t let that
stop anyone else interested from developing one, consulting, etc. Serge’s
work in the US with TIGER name expansions might be helpful.

 

Also, just a reminder, if using a tool like osmose, don’t blindly accept its
suggestions, make sure to review them first.

 

 

 

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 




---

Osmose is an error detection tool similar to Keepright. It can detect errors
and inconsistencies in OSM data in the form of a map OSM with tooltips. On
the left side, we select from the list of problems detected. On the map, the
select a tooltip and click to edit directly in JOSM.

Starting today, the Osmose tool covers Québec for all error analysis. The
rest of Canada is partially covered for some errors but developers of
OSM-France tell me that there would be opportunity to include all of Canada.
The list of errors is updated daily.
see http://osmose.openstreetmap.fr/map/?zoom=10
http://osmose.openstreetmap.fr/map/?zoom=10lat=46.49412lon=-72.81377laye
rs=BFFFTitem=level=1,2,3
lat=46.49412lon=-72.81377layers=BFFFTitem=level
=1,2,3
Errors list http://wiki.openstreetmap.org/wiki/Osmose/erreurs

For some errors detected by Osmose, such as abbreviations or Too many
spaces, you will notice when importing in JOSM that the proposed correction
is already done in the Name Tag. When you have completed the correction in
JOSM you click on the Corrected link of the Osmose tooltip to confirm the
correction.

Thanks very much to the developers OSM-France for their excellent work.

The Statistics section allows us to better coordinate, and see if some
adjustments could be corrected automatically by a bot rather than manually.

see error table for Québec
http://beta.osmose.openstreetmap.fr/errors/?country=canada_quebec

As already discussed on the Talk-Ca list, there are a large number of errors
that have appeared consistently in previous Canvec imports. We do not find
these errors in the recent imports. However, we still need to fix the base
OSM for the previous errors.

We find in particular:
lanes = -1
Names abbreviations and with too many spaces

This is an opportunity to make a list of corrections that could be made via
a bot. Are there any developers who have the expertise to run a bot and are
willing to cooperate?

 

Pierre 

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

[Talk-ca] Toronto-area events in early January

[Paul Norman]

I'm going to be in Toronto in the new year and was wondering if any OSM or
GIS events, meetings or mappy hours would be taking place. I'll be arriving
on the 2nd and leaving on the 7th for Penetang but might be free after that.

I'll mainly be spending time with the relatives, but the dates for that are
flexible. I'll of course be bringing my GPS + mapping equipment


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

Re: [Talk-ca] Validating existing data in Ottawa area

[Paul Norman]

Do you know when you’ll be proposing this import to the various lists?

 

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: Monday, December 03, 2012 7:55 AM
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Validating existing data in Ottawa area

 

Tom

For the Québec municipalities administrative boundaries there were
discussions on this list about a month ago. We plan to import at once using
data from government of Québec.  I communicated with the government Données
libres site and wait for their approval.

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

Re: [Talk-ca] Alaska / BC border

[Paul Norman]

 From: Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca]
 Sent: Thursday, November 22, 2012 7:20 PM
 To: Bruno Remy; talk-ca@openstreetmap.org
 Subject: Re: [Talk-ca] Alaska / BC border
 
 You can get the boundary coordinates from the IBC - International
 Boundary Commission.

I also checked with the IBC some time ago and the data is legally okay to
use.

Me and someone else were working on fixing up the Canada/US border but
neither of us was looking at Alaska.

I'll post more details on the relevant diary entry
(http://www.openstreetmap.org/user/alexz/diary/18102)


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

Re: [Talk-ca] Internal CanVec conflicts

[Paul Norman]

 From: Dan Charrois [mailto:d...@syz.com]
 Subject: Re: [Talk-ca] Internal CanVec conflicts
 
 Usually, in remote areas of the north that I've dealt with, there is
 often little else already there than the Landsat lakes.  And usually, in
 a given tile, there is usually just a handful of lakes.
 
 In pretty much every case I've dealt with so far, I've replaced the
 Landsat lakes with Canvec data.  Landsat lake outlines have a much lower
 resolution, and being derived by an automatic process themselves, are
 subject to the errors associated with that.  But I wouldn't necessary
 erase all the Landsat data from a tile without checking first to make
 sure that there will be Canvec data replacing it (I always work with my
 Canvec data in a separate layer and merge things in one feature at a
 time as it's checked).  Using Bing imagery may be a good idea to check
 any issues where Landsat data may exist and Canvec doesn't - even low
 resolution Bing imagery is usually sufficient for the Landsat lakes.  I
 have yet to encounter a place where there is a Landsat lake and not a
 corresponding Canvec one of roughly the same shape, but it could happen.
 
 I have yet to find a situation where the Landsat lake data is better
 than the Canvec data.

The coastlines in BC were similar and what you have to watch out for is
areas where someone has refined the traces but hasn't touched the source
tag. I ended up using JOSM to search for nodes that were part of the
coastline and were not version 1 nodes from the person who imported the
coastline.

Even though not all of this stuff was imported from a dedicated account
(most of it was done many years ago) it's not too hard to find it with
search strings because the importer didn't do anything in the area except
for import.


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

Re: [Talk-ca] Internal CanVec conflicts

[Paul Norman]

 From: Tom Taylor [mailto:tom.taylor.s...@gmail.com]
 Subject: Re: [Talk-ca] Internal CanVec conflicts
 
 I've just performed my first edits, in our neighbourhood. One thing I
 noticed was that some of the buildings are duplicates. I assume this is
 part of what you are talking about when you mention internal CanVec
 conflicts. In the case of a local public school, I deleted one of the
 copies and dragged the other to match the Bing image. Was that the right
 thing to do?

The internal conflicts are within CanVec itself and of a different type. For
example, CanVec might say that the public school is both a school and a
forest at the same time.

It's hard to say without having seen the area, but what you saw sounds like
it's a case of someone not correctly merging CanVec with existing OSM data.
When someone imports CanVec they need to make sure it's properly integrated
with existing data and not duplicating it. They also need to not blindly
replace existing data with imported data.


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

Re: [Talk-ca] Import Canvec : micro-tâches / Canvec imports micro-tasking

[Paul Norman]

I have wondered about setting up a snapshot-server and loading CanVec on it
then setting up a P2 deployment pointing at it.

 

The problem with splitting by layers is that OSM data is not divided by
layers (including planet files). In general if you have interdependent
layers and you want to use them with OSM the first step is to merge the
layers into one. Now although CanVec appears as multiple independent layers
(one .osm file) the underlying data comes from multiple sources (NRN, NHN,
etc) so some layer splitting would be possible.

 

If I get time I’ll merge together some subtiles to a NTS tile and throw them
on my hetzner server. It’s not ideal since it’s in Europe and doesn’t have
the disks I’d want, but it’s good enough to serve as a proof of concept.

 

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: Tuesday, November 13, 2012 12:02 PM
To: talk-ca@openstreetmap.org
Cc: Paul Norman; Nicolas Gariépy
Subject: Import Canvec : micro-tâches / Canvec imports micro-tasking

 

Data import is essential to cover all of Canada, But it is complex to import
Canvec files in areas were data already exist. Both unexperienced and
experienced people may make errors.  Import process is often too complex and
too long to realize. 

Micro-tasking presently consist of dividing a a NTS grid area in smaller
zones. If this micro-tasking was based on layers, I think that this would
reduce the complexity of Canvec imports, reduce errors and encourage more
people to import. But if necessary because of size, some NTS grids could be
subdivided by smaller zones.

 

The OSM import files would be divided by layers like it is done for planet
files. There could be layers such as roads, poi, landuse, water, forest,
coastlines, administrative boundaries, other...). This way, the individual
import tasks would be less complex to realize, easier to compare with what
already exist. Also, the task would be realized more rapidly.

 

When certain type of data such as forests seems less appropriate for a
specific area, it would be easy for the mapper to skip this layer. Also, the
administrative boundaries and coastlines should be reserved to more
experienced people. They could be grouped in a distinct directory and cover
larger zones.


I think that we need more than the Google doc to monitor the mapping.

The New Zealand linz2osm tool seems too complex to me. But it can give us
some clue about how to develop such a tool.


See linz2osm New Zealand project.
http://linz2osm.openstreetmap.org.nz/

 

See Glen Barnes discussion on Import list.

http://web.archiveorange.com/archive/v/2u2n5O1bELI3yg2ULjry

 

Pierre 

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

[Talk-ca] BC Resource Roads

[Paul Norman]

I was importing some CanVec in northern BC and came across a resource road
on bing, which I also added, but I realized I wasn't positive on the best
tagging.

A typical example is
http://www.openstreetmap.org/?lat=59.395lon=-122.074zoom=16

These roads exist for forestry and oil and gas use. In this particular
region they're primarily built for accessing oil and gas leases and have
trucks running to/from the wells. They aren't generally used for through
traffic.

They are almost always unpaved but maintained to some minimum standard.

There seem to be to be three obvious tagging choices (aside from
highway=road which is never wrong)

highway=track
tracktype=grade1

highway=service
surface=unpaved

highway=unclassified
surface=unpaved

I am in favour of the first (track with tracktype) but would like to get
some thoughts from others.

As an aside, these roads are not in Google, CanVec or any other sources I
quickly checked.


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

Re: [Talk-ca] New Subdivisions

[Paul Norman]

 From: Steve Roy [mailto:st...@ssni.ca]
 Sent: Monday, November 12, 2012 2:58 PM
 To: talk-ca@openstreetmap.org
 Subject: [Talk-ca] New Subdivisions
 
 What is the best was of adding a new subdivision like this one east of
 Kelowna?  I've only used Potlatch.
 
 http://www.openstreetmap.org/?lat=49.873809814453125lon=-
 119.35237884521484zoom=15

There's a few ways of going about doing this. Because you have aerial
imagery (2011 provincial imagery) for the area it makes it easier. Generally
the first step is to get the roads in.

You could trace them from the imagery or in this case they are also in
CanVec. If it was a really new subdivision you'd have to use a GPS. It looks
like there might be some even newer construction not in CanVec or the
imagery.

Just for reference, the CanVec data is 082E14.0.2.

The Wiki has more docs on CanVec, but basically in this case you'd only want
to bring through the road data. The other data is rather useless. You can do
this with JOSM or P2.

Once the roads are in I'd suggest going to the subdivision and walking the
roads, checking names and noting POIs. Getting the location of any retail
locations is also useful.


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

[Talk-ca] CanVec bug - splitting of long riverbank ways?

[Paul Norman]

I appear to of found a CanVec 10 bug in 094P13.0.osm

There is a waterway=riverbank way (Dilly Creek) that is split in two at
59.7728641, -121.9806992. One way is 2k nodes, the other is 457 nodes.

Ideally this would be split in two to form two separate areas. An alternate
solution would be to not split them and have one way over 2k nodes. This
will force the importer to fix it before uploading as opposed to right now
where if someone doesn't notice they will upload broken data.


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

Re: [Talk-ca] Suivi OSM / OSM Monitoring

[Paul Norman]

 From: James Ewen [mailto:ve6...@gmail.com]
 Sent: Monday, October 29, 2012 5:22 PM
 To: talk-ca
 Subject: Re: [Talk-ca] Suivi OSM / OSM Monitoring
 
 I see that Canada is pretty good at the admin2 (Country) level, and the
 admin4 level (Regions) except for a few islands in the Hudson and James
 Bay areas. It looks like BC has had the admin6 (Departments) level
 imported 

Yes - although they're honestly not particularly valuable data. The
admin_level=6 entities are of much less practical importance than the
admin_level=8 cities.




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