Re: [Talk-ca] NRCan lakes

[Adam Martin]

As mentioned by Daniel, this is due to the nature of the CANVEC data
import.  CANVEC shapefile data is based on tiles and these will chop
practically anything into pieces - lakes are just ones of the more
noticeable.  I have corrected some of these myself as I've come across
them.  Just be careful in cases where the lake pieces are part of different
relations in the area - you will need to adjust those to make sure nothing
breaks.

Adam

On Tue, Jul 7, 2020 at 2:33 AM Hannes Röst  wrote:

> Hello
>
> I am a contributor from Toronto and I have a question regarding how to
> treat some of the CanVec 6.0 - NRCan imports, specifically for lakes.
> I came across this lake here:
>
> https://www.openstreetmap.org/way/69275451
> https://www.openstreetmap.org/way/69277932
> https://www.openstreetmap.org/way/69745752
>
> Which is strangely split up into 3 parts and I wonder how to proceed:
> should we fix this and create a single way out of these 3 parts or is
> it beneficial (for comparison to future NRCan database entries) to
> keep them that way and create a relation out of the three? Also, does
> somebody know why the NRCan dataset does this, is this an import
> artefact (splitting into tiles?) and should be corrected when encountered
> or is it part of the original dataset?
>
> Best
>
> Hannes Rost
>
> ___
> 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] Coastline Question

[Adam Martin]

Hello all,

I have been moving about the Island of Newfoundland addressing Keep Right!
issues and adding missing features.  While doing so, I encountered an area
of coastline along the Burin Peninsula that appears odd to me.
Specifically, the Garnish River here:

https://www.openstreetmap.org/#map=16/47.2322/-55.3473

On the regular map, it looks fine.  In the iD Editor, however, the banks of
the river are designated as the coastline.  Now, I know that this is
reasonable in some circumstances (generally, where the ocean water is
directly present in the waterway).  But if you look at it in the editor,
the coastline doesn't stop in that area.  In fact, the coastline extends
deep into the interior of the peninsula, tracing along the riverway all the
way to just north of Clam Pond.  Again, I know this can be reasonable in
cases where, if I recall correctly, the water itself is at ocean level or
similar.  I recall there being wrangling over the St. Lawrence regarding
the coastline designation, but this is nowhere near as big as that river.

But I am from this Province and have lived on that peninsula - the entire
place is a quagmire of hills and gullies.  I do not believe that this river
is level with the ocean, at least not to this extent.  The data source for
it is NRCAN CANVEC 8.0.  I reviewed the Natural Resources Canada "Toporama"
map for the area to check the altitude of the river as it extends
eastward.  The river passes to the south of "Morgans Pond" and, as it does
so, crosses a 50ft topographical line there.  So, in my mind, that means
that it must be descending as it moves to the west and can't be considered
ocean at this point, at least.

With that in mind, I am just looking for some input from the group here.  I
don't want to change something like that only to find I was wrong for one
reason or another.

Thanks,

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

Re: [Talk-ca] Importing buildings in Canada

[Adam Martin]

Hi all,

Looking at the wiki page, a large volume of the buildings are of low
quality requiring processing.  The trade off here is between not having
buildings and having buildings that are out of place and of poor quality.
I can see people being reluctant to have it imported in an area, especially
where buildings have been drawn by hand.  If this is to be imported, I
think many would be more amenable to the idea if the data already present
was given precedence.

As a Newfoundlander, the lack of any such data for this province could be a
blessing or a curse, depending on how you see the mass importation of
buildings.

Happy holidays!

Adam

On Tue., Dec. 24, 2019, 7:36 p.m. Daniel @jfd553, 
wrote:

> Have a look at the wiki page I referred to. Further discussions will be
> more easy and focused
>
> Sent from Galaxy S7
>
> --
> *From:* John Whelan 
> *Sent:* Tuesday, December 24, 2019 2:50:29 PM
> *To:* James 
> *Cc:* Daniel @jfd553 ; Talk-CA OpenStreetMap <
> talk-ca@openstreetmap.org>
> *Subject:* Re: [Talk-ca] Importing buildings in Canada
>
> I think the first problem to be addressed is the presence or absence of a
> local community.
>
> In the north we have few mappers but lots of interested agencies and
> people in seeing the buildings imported.
>
> Montreal I think is under control.  Toronto is in the process of sorting
> itself out but I'm unclear how much territory the Toronto local group
> covers.
>
> Vancouver should be big enough to support a local group.  As should
> Calgary and Edmonton.
>
> Ottawa is complete as is Gatineau.
>
> It's the smaller cities and regions that would be my concern.  Often it
> will be by chance that two or more mappers meet occasionally.
>
> So step one can we list the local groups?
>
> I also have a problem with what happens if two people agree but haven't
> done any mapping are they a local group?
>
> Step two to me would be a consensus on how to tackle those areas without a
> local group and I think Daniel's suggestion would be a way forward in this
> area.
>
> Cheerio John
>
>
>
> James wrote on 2019-12-24 1:28 PM:
>
> wasn't there talk about this before and someone blocked it because of
> non-square buildings and the resulting discussion was that each community
> was going to decide if they want to import or not?
>
> On Tue., Dec. 24, 2019, 1:26 p.m. Daniel @jfd553, 
> wrote:
>
> Hi Group!
>
> I am currently working on a proposal which, I hope, will bring consensus
> among the community and relaunch the import of ODB footprints (StatCan).
> The proposal should be ready in a few weeks, or sooner.
>
>
>
> In the meantime, I suggest to all those who are interested to take note of
> the observations I made regarding these data. This information can be found
> in the OSM wiki (1). According to OSM import guideline requirements, it
> describes the data to import. At the same time, I updated the
> Canada-federal section of the Data Potential wiki page (2).
>
>
>
> I will be offline in the next few days, so if you have any
> questions/comments, please be patient :-)
>
>
>
> Daniel
>
>
>
> 1 - https://wiki.openstreetmap.org/wiki/The_Open_Database_of_Buildings
>
> 2 -
> https://wiki.openstreetmap.org/wiki/Potential_Datasources#Federal_.28Open_Government.29
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-ca
>
>
> --
> Sent from Postbox 
> ___
> 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] using image recognition to create building foot prints.

[Adam Martin]

Can't speak for the rest of the country as such, but I do know that the
imagery quality in Newfoundland is rather poor. Recognizing building shapes
would technically work, but the result would be poorly aligned boxes, not
accurate house shapes. We also do not have a local working group as far as
I am aware so any importation would need to be brought to the whole list or
such a group created.

On Jan 29, 2018 4:47 PM, "john whelan"  wrote:

> ·
>
>
> *NRCan is working on a methodology to extract building footprints,
> including topographic elevation and height attributes, from LiDAR*
>
>
> *Traditionally OSM has not been happy with this sort of thing.  The
> accuracy can be poor.*
>
>
> *We probably need to think about this since the BC2020i project had this
> mentioned and Stats Can has given it a mention also.  I'm not promoting it
> nor saying its bad but it will almost certainly be raised shortly.*
>
>
> *First if an import was done using this data who would be the local group
> to approve it?  I suspect because it covers the entire country it would be
> the talk-ca group.  The date would come through the TB portal so licensing
> is not an issue.  Or it could be split into regions with regional local
> groups making decisions.*
>
>
> *The other very big question is to do with data quality.  So far nothing
> that is machine learnt from imagery has consistently met the expectations
> of OpenStreetMap.*
>
>
> *Note to Pierre I'm not sure if you are on the talk-ca mailing list but
> any feedback you might have on the data quality side would be welcome and
> will be shared amongst the group.*
>
>
> *Thoughts?*
>
> *Thanks John*
>
> ___
> 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] Forests/Land Use, was: Canvec reverts

[Adam Martin]

That is the key here. Deleting information without replacing it with
something more accurate is inherently destructive. There must be some
thought as to what will be put back or one is essentially ripping the map
up simply because you don't like how something looks or how it closely it
follows a given rule. That would be like finding parking aisles tagged as
drive throughs and deleting them as incorrect, instead of simply correcting
the tags.

On Sep 1, 2016 3:30 PM, "john whelan"  wrote:

> And as someone who has deleted quite a few things in OSM I would agree
> with that statement.  When I didn't have a better replacement available
> then I prefer not to delete unless I have done a ground level inspection
> and there really isn't anything there.
>
> I think my favourite was a mapper who was demonstrating 3D software with
> OSM.  They dropped in a group of multiple level buildings into an area I
> was mapping in Africa.  They didn't consider what they did was wrong, it
> was only Africa.
>
> Cheerio John
>
> On 1 Sep 2016 1:26 pm, "Begin Daniel"  wrote:
>
>> *P: OSM is very much an "add only" project, since the social consequences
>> of incorrectly deleting things seem so high.*
>>
>>
>>
>> What I do perceive in the current thread is that deleting something not
>> perfect without replacing it with something better hurts, not that it is
>> not acceptable to delete something.
>>
>>
>>
>> Daniel
>>
>>
>>
>> *From:* Paul Ramsey [mailto:pram...@cleverelephant.ca]
>> *Sent:* Thursday, 1 September, 2016 13:05
>> *To:* Begin Daniel
>> *Cc:* Talk-CA OpenStreetMap
>> *Subject:* Re: [Talk-ca] Forests/Land Use, was: Canvec reverts
>>
>>
>>
>>
>>
>> On Thu, Sep 1, 2016 at 8:49 AM, Begin Daniel  wrote:
>>
>> What is very cool with OSM is that you can edit the data. Urban polygon
>> is wrong? Modify it! The definition is obscure in the Wiki? Change it! But
>> yes, the learning curve is often steep, and you may need to discuss with
>> someone else…
>>
>>
>>
>> "Just fix it" is not quite the answer. The point the original poster
>> made, which I concur with, is that the very existence of these shapes makes
>> working with the "important" data difficult. In terms of forest and land
>> use polygons, every vertex I move there is a vertex I'm not going to move
>> on something "important".  (And the vertex density of the forests/land use
>> are another reason that working around/with them is painful and
>> energy-sapping.)
>>
>>
>>
>> As discussed in the other thread, the shear volume of Canada means I'm
>> never in 1M years going to "fix" the forests. As it stands, I mostly ignore
>> them. Too many vertexes to move, for too little net benefit, so there's
>> forests running through the new subdivisions of Prince George. At least the
>> roads are there and hopefully correctly named now.
>>
>>
>>
>>  (I would, however, love to just delete the urban "land use" polygons,
>> but who know if that's "allowed" or not. Absent a strong personality like
>> the person who caused this thread, it seems like OSM is very much an "add
>> only" project, since the social consequences of incorrectly deleting things
>> seem so high. Nobody wants to be "that guy".)
>>
>>
>>
>> ATB,
>>
>>
>> P
>>
>>
>>
>>
>>
>>
>>
>> *From:* Paul Ramsey [mailto:pram...@cleverelephant.ca]
>> *Sent:* Thursday, 1 September, 2016 11:17
>> *To:* Talk-CA OpenStreetMap
>> *Subject:* [Talk-ca] Forests/Land Use, was: Canvec reverts
>>
>>
>>
>> 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).
>>
>>
>>
>> Unlike buildings and roads and water, land use is pretty sloppy: where
>> does the "urban area" end? Is this a "forest" or just a bunch of trees?
>> Since anyone making a real multi-scale map will fine some other source of
>> land-use (like classified landsat) and since people trying to map at
>> high-res are finding the forests add little value and much impedance, why
>> don't we ... burn down all the forests (and the urban areas too)?
>>
>>
>>
>> P
>>
>>
>>
>> On Thu, Sep 1, 2016 at 6:54 AM, Loïc Haméon  wrote:
>>
>>
>> On a final note, though, I certainly would approve of any effort to
>> reduce the size of the upload chunks and the assorted polygons. For new
>> mappers like me, those create daunting challenges when trying to make
>> incremental improvements to an area. Shortly after joining the OSM
>> community I was back in my home town of Saint-Félicien, in a fairly remote
>> region that hasn't had tons 

Re: [Talk-ca] Qualiuty of OSM data

[Adam Martin]

I would also like to take a read through that document. Sounds interesting.

CANVEC has been good for the Canadian mapping efforts, but it is stale data
and not highly accurate. Yet it provides us a base to work from and has the
benefit of filling the map with ... something. A giant blank gap for Canada
would not be very good for the map in general and us specifically.

On Aug 31, 2016 7:38 PM, "James"  wrote:

> I've read it in the past, I do agree cavec is not 100% accurate, but  in
> areas with absolutely nothing, it is better than a blank map: which is
> useless.
>
> On Aug 31, 2016 6:02 PM, "dega"  wrote:
>
> Hi everybody!
> On 2016-08-31 Stewart C. Russell wrote:
> > A paper published in the last couple of years (by Anita Graser, maybe?)
> > showed that CanVec imports were the largest source of spurious precision
> > in the entire OSM database.
>
> If somebody has a link to that document, I would like to get it.
>
> Thanks!
>
> dega
>
> ___
> 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] broken forests in eastern Canada

[Adam Martin]

I've contacted him as well. Here's what I sent:

Good day, Nakaner

I am a resident of Canada and a contributor to OSM here. Looking over your
profile, you have over 5,500 edits across the OSM project, making you a
skilled mapper. It has come to the attention of the Canadian OSM community
recently that you have been performing work here and we appreciate that.
However, it has also come to our attention that much of the work you are
doing involves reverting the CANVEC data imports that we use here without
consultation with the local OSM group.

As you know, mapping is an involved process, especially in a country as
large geographically as Canada. Our population is relatively low, which
results in large expanses of land being effectively free of human
involvement. Since mapping effort tend to centre around human activity,
this means that large parts of Canada can go unmapped for a long time. To
combat this, we have made use of the CANVEC data graciously made available
by the Federal Government through the Department of Natural Resources. This
information covers most of the country in its surveys. It is known to be
somewhat inaccurate, but in the absence of information in a given area, it
is definitely welcome.

Most of the imports that you are flagging for revision have been in place
for years; in some cases, even before the policy for importation was in
place. I'm sure that they didn't always meet the guidelines that are now in
place within the larger OSM community, but the fact remains that the
information that they represent is invaluable to the Canadian portion of
the map and the mappers here.

If you wish to have that data become higher in quality, you are on the same
side as the Canadian mapping community. We know the limitations of CANVEC
and are working to allieviate them. Come join our OSM talk list and discuss
your concerns with us. We are very welcoming to any points of view on the
map. This allows all of us to come to a mutual understanding and solution
to the problems with the imported data that you highlight.

Our list is talk-ca@openstreetmap.org

Thanks,

Adam

On Tue, Aug 30, 2016 at 8:09 PM, john whelan <jwhelan0...@gmail.com> wrote:

> But Daniel's comments make sense, I'm not sure we should go for this type
> of approach.
>
> Still I concur with them.  On the forests there is an issue but its not
> open to a simplistic approach and hence difficult to resolve.
>
> John
>
> On 30 August 2016 at 18:28, James <james2...@gmail.com> wrote:
>
>> I'm totally in agreement with Daniel, especially that it creates a
>> hostile community
>>
>> On Aug 30, 2016 6:05 PM, "Pierre Béland" <pierz...@yahoo.fr> wrote:
>>
>>> +1
>>>
>>> J'invite les autres contributeurs canadiens à indiquer leur accord avec
>>> le message de Daniel. :)
>>>
>>> I invite other canadian OSM contributors to express their agreement with
>>> Daniel message. :)
>>>
>>>
>>> Pierre
>>>
>>>
>>> --
>>> *De :* Begin Daniel <jfd...@hotmail.com>
>>> *À :* James <james2...@gmail.com>; Adam Martin <s.adam.mar...@gmail.com>
>>>
>>> *Cc :* Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>
>>> *Envoyé le :* mardi 30 août 2016 17h35
>>> *Objet :* Re: [Talk-ca] broken forests in eastern Canada
>>>
>>> I have contacted the user that is about/has deleted some changesets
>>> imported from Canvec. I may agree on some of his comments but totally
>>> disagree on the method he is using to make his point.
>>>
>>> I do not know what the DWG will do about this guy but here is the
>>> message I sent him...
>>> Bonjour Nakaner, I understand that you wish the data in OSM being
>>> accurate, well-structured and made according to the rules developed by the
>>> OSM community. However, I would strongly suggest that you discuss your
>>> point with the Canadian community before deleting any changesets.
>>>
>>> Canvec imports are running for more than 6 years and the structure of
>>> the data was discussed with the Canadian OSM community, including OSMF
>>> members, for more than a year. The result is a compromise that used to suit
>>> most members. The rules you are mentioning in the comments you leave where
>>> not even written at that time.
>>>
>>> Most Canadian importers simply keep doing what they used to do years
>>> ago. If you consider they should not, have a discussion with the whole
>>> Canadian community. You will then be able to make your point, make everyone
>>> aware of these rules and understand your concerns.
>>>
>>> You wi

Re: [Talk-ca] broken forests in eastern Canada

[Adam Martin]

That's a pretty harsh thing to deal with. Imports are difficult and the
time needed to get them right is not a small investment. To have someone
review this work is a valuable service, but I don't think just blanket
reverting due to the violation of one rule is the solution, especially in
context of the lack of data in some of those areas. The CANVEC stuff will
do until surveys or satellite data catches up with those areas.

On Tue, Aug 30, 2016 at 10:35 AM, John Marshall  wrote:

> Andrew, I hear you! I have been trying to add data around unmapped
> Northern Communities around James Bay and Nunavut. But after someone revert
> some of my work I'm stopping:(
>
> John
>
> On Tue, Aug 30, 2016 at 8:49 AM, Andrew 
> wrote:
>
>> On Mon, 2016-08-29 at 23:47 -0400, Gordon Dewis wrote:
>>
>>
>> On Aug 29, 2016, at 11:12 PM, Antoine Beaupré 
>> wrote:
>>
>> On 2016-08-25 10:13:25, Gordon Dewis wrote:
>>
>> Alan is right. I've brought in a few tiles worth of forests from Canvec in
>> the area you're talking about, but they were non-trivial to deal with
>> compared to most other features. I kept running into limits in the tools I
>> was using at the time and I haven't returned to them since.
>>
>>
>> Yeah, that's what I figured I hope my comment didn't come across as
>> criticizing the work that was done importing that data into OSM - I know
>> how challenging and frustrating that work can be.
>>
>> But I must admit it seems a little rough to have those patches up
>> there. I don't mind the "seams" between the CANVEC imported blocks,
>> which don't seem to show up on the main map anymore anyways. But
>> the *missing* blocks are really problematic and confusing. And they show
>> up not only all the way up north and in weird places, but in critical
>> areas. for example, here's a blank spot right north of Canada's capital:
>>
>> http://osm.org/go/cIhYCSU-?m=
>>
>> It seems a whole area was just not imported up there... oops! This shows
>> up here and there in seemingly random places.
>>
>>
>> Whoever was working on it was probably struggling with the tiles and
>> subtitles in Canvec and threw in the towel. I was working on the forests
>> around Golden Lake, for example, and ran into problems and limitations with
>> the tools I was using at the time. I would love to import more, but it’s a
>> daunting task.
>>
>> Another problem I noticed is when trying to merge “new” forests with
>> existing forests was the existing forests would disappear because the
>> topology changed, similar to problems you can see with lakes and islands.
>> That alone was enough to make me back off and undo the inadvertent damage.
>>
>> I wonder if it wouldn't be better to remove parts of the CANVEC import
>> until we can figure out how to better import them in the future, if, of
>> course, we have a documented way of restoring the state of affairs we
>> have now... As was mentionned elsewhere, it seems to me that the data
>> that is there now somewhat makes it more difficult to go forward and
>> hides more important data (like park boundaries).
>>
>>
>> Unless the parts of Canvec are going to be replaced with more
>> comprehensive coverage, I think that removing the existing forests would
>> not be a Good Thing.
>>
>> I believe it would be more important to map out park boundaries than
>> actual forest limits which, quite unfortunately, change in pretty
>> dramatic ways in Québec, due to massive logging that has been happening
>> for decades.
>>
>>
>> Park boundaries are mostly in already, aren’t they? They are fairly easy
>> features to import compared to forests.
>>
>>
>> Tell you what, I do what I can to import the data, and fill in the gaps.
>>
>> I stopped importing data about a year ago, my skin just wasn't thick
>> enough.
>>
>>
>> ___
>> 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] broken forests in eastern Canada

[Adam Martin]

Both of your instincts on the matter are correct - these polygons are the
result of CANVEC data imports and has to do with how that data is packaged
for distribution by Natural Resources. If you go to the CANVEC site, click
on the map, and zoom to an address, you eventually get to the level where
the data is divided into discreet blocks. This is partially to manage the
size of the shape files that make up this data (they can be quite large).

This isn't an issue for items like roads or features that fit within one of
these areas. But if a feature crosses a boundary, then it is split by the
shape files. These forest polygons are divided exactly along these shape
dividers.

These polygons do not have a high level of percision, but I don't believe
they were ever really meant to. There is only so much detail that the
CANVEC files can have. These shape are also, in some cases, quite old. Some
surveys by Natural Resources are more that thirty years old with no need to
really update them.

As to why they haven't been fixed? It's not that we've ignored these blocks
or their accuracy. Rather, it's more a matter of priority. Most mappers are
busy with major settlements and other human inhabited areas. Most of these
blocks are in areas with little human activity. As making efforts progress,
these blocks will probably get addressed, but as you can imagine, it's a
big task. The polygons will need to be either merged or redrawn to conform
with the underlying land use.

Adam

On Aug 25, 2016 2:50 AM, "Alan Richards"  wrote:

> I believe these are the result of importing Canvec landuse data for some
> areas and not for others. Because the data is in square chunks, you end up
> with these unnatural looking squares on the map. Really it's just a case of
> the other areas don't have detail yet.
>
> Across the border it looks like the US just has parks and national
> forests, etc. mapped, and not the general natural=forest that you see
> across Canada.
>
> Alan (alarobric)
>
> On Tue, Aug 16, 2016 at 2:04 PM, Antoine Beaupré 
> wrote:
>
>> hi everyone (allo tout le monde!!)
>>
>> one of the most frustrating experiences I have with Openstreetmap in
>> Canada is this ugly forest display:
>>
>> http://www.openstreetmap.org/#map=8/45.227/-73.916
>>
>> Just compare how the forests and parks are mapped between the US and
>> Canada. On our side of the border, you got huge chunks of square forests
>> that definitely do not reflect the current reality, whereas down south
>> you clearly see national parks, forests and no weird square things.
>>
>> I don't really understand how this happened, but it's been there a long
>> time. I feel it's some Canvec import that went wrong, but it's been
>> there for so long that it seems people just forgot about it or moved on.
>>
>> I looked around in the .qc and .ca wiki pages and couldn't find anything
>> about it, so I figured I would bring that up here (again?).
>>
>> Are there any plans to fix this? How would one go around fixing this
>> anyways?
>>
>> In particular, I'm curious to hear if people would know how to import
>> *all* the park limits in Québec. It seems those are better mapped in
>> Ontario, and I can't imagine those wore drawn by hand..
>>
>> Thanks for any feedback (and please CC me, I'm not on the list).
>>
>> A.
>>
>> --
>> We will create a civilization of the Mind in Cyberspace. May it be more
>> humane and fair than the world your governments have made before.
>> - John Perry Barlow, 1996
>> A Declaration of Independence of Cyberspace
>>
>> ___
>> 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] OpenStreetMap at the Crossroads – The Map Room

[Adam Martin]

Wait! You mean a robot ... Made a mistake!!?? Say it ain't so!

Sarcasm aside, it's not surprising. The article speaks so highly of the
robots and the crisis peeps over the crafters and the arm chair people. But
it has been my experience that unless the importer is skilled and regularly
consults the locals, the result is invariably bad for the map.

The demotion of craft mappers and arm chair mappers to, effectively, bottom
feeders does a disservice to the map. I map my local area and arm chair
locations far away. I do not think those contributions are damaging or
niche. My local work is for things only a local could know. And my remote
stuff is, while based on the satellite, things that need refinement (better
shaping) or things that are missing that seems beneath some mappers (such
as service roads). No one seems to want to survey this type of thing or to
make sure a road flows correctly. This is especially true for some of the
robot work. Things are imported and left that way with no regard for
confirming that the new data appears reasonable. One place I went over had
imported streets that were not connected together, so I fixed it from my
position thousands of kilometers away. As long as one is conscious of the
need to defer to the locals and preserve information already in place,
there is nothing wrong with remote mapping.

On Aug 19, 2016 1:02 PM, "Stewart C. Russell"  wrote:

> This week's weeklyOSM has a bit about an over-zealous robot from Facebook:
>
> Imports
>
>- The Data Working Group (DWG) has reverted
>
>Facebook’s undiscussed import of poor quality autorecognized streets in
>Egypt. See also the discussion
> on one of the
>reverted changesets.
>
> cheers,
>  Stewart
>
> ___
> 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] Crowdsourcing buildings with Statistics Canada

[Adam Martin]

That would be fine, I'd figure, as you didn't use Canada Post to acquire
the address. The business website is designed, in principle, to allow the
free use of the information as it wants customers to find them and use
their services.

This is much like adding your own address. Can't be any argument with that
- or with adding ones from people you know. Again, you didn't use Canada
Post's database to get this information.

On Aug 10, 2016 5:00 PM, "john whelan" <jwhelan0...@gmail.com> wrote:

> > So it is perfectly fine to add the street number and name, just not the
> postal code from an official source.
>
> I assume if the address has a web site associated with it that has the
> postcode on it then that is an acceptable source?
>
> Cheerio John
>
> On 10 August 2016 at 11:03, Kevin Farrugia <kevinfarru...@gmail.com>
> wrote:
>
>> For clarification - Canada Post only owns the postal code, the address
>> itself (123 Main St.) is created and approved by the municipality, so it's
>> their data and they can release that data if they wish to.
>>
>> So it is perfectly fine to add the street number and name, just not the
>> postal code from an official source.
>>
>> On Aug 10, 2016 11:00 AM, "Adam Martin" <s.adam.mar...@gmail.com> wrote:
>>
>>> Hey Bjenk,
>>>
>>> On the Address data, the Talk-CA group has had several discussions about
>>> it. The problem boils down to Canada Post, which treats the information as
>>> proprietary - they provide any individual going to their site the right to
>>> lookup an address in order to utilize their service to mail items. The
>>> actual database is theirs and even the postal code on my home is theirs,
>>> I'm just allowed to use it. This all likely has more to do with the fact
>>> that they have a service that links the addresses to mapped locations that
>>> is, of course, available only for those willing to pay for it. If they
>>> allowed OSM to integrate this information, they would lose that revenue
>>> stream.
>>>
>>> Suffice it to say that, apart from an individual adding their address
>>> manually to the map, Canada Post is not about to allow any party to use
>>> that information freely.
>>>
>>> On Wed, Aug 10, 2016 at 11:41 AM, Ellefsen, Bjenk (STATCAN) <
>>> bjenk.ellef...@canada.ca> wrote:
>>>
>>>> The postal code subject is interesting for many reasons. I read that
>>>> France has released a National address database, publically and free.
>>>>
>>>>
>>>>
>>>> There must be a way we can follow that example.
>>>>
>>>>
>>>>
>>>> I am still catching up, haha!
>>>>
>>>>
>>>>
>>>> Bjenk
>>>>
>>>>
>>>>
>>>> *From:* john whelan [mailto:jwhelan0...@gmail.com]
>>>> *Sent:* August-06-16 7:23 PM
>>>> *To:* Laura O'Grady <la...@lauraogrady.ca>
>>>> *Cc:* Talk-CA OpenStreetMap <talk-ca@openstreetmap.org>; Ellefsen,
>>>> Bjenk (STATCAN) <bjenk.ellef...@canada.ca>; Stewart C. Russell <
>>>> scr...@gmail.com>
>>>> *Subject:* Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada
>>>>
>>>>
>>>>
>>>> The postcode battle is being fought on the Open Data side.   There is
>>>> an open data mailing list whose name escapes me where they have been
>>>> playing for years to get the postcode data including access to information
>>>> requests.
>>>>
>>>> Tracy at Carleton University is well connected on the Open Data side
>>>> and the postcode saga.  There is some hope now that the UK post office has
>>>> made the UK ones available.
>>>>
>>>> For the moment many commercial companies do list their postcode on
>>>> their web sites and the the commercial buildings that are the ones of
>>>> interest to Stats Canada.
>>>>
>>>> I suspect Bjenk will have fun when he checks his email on Monday
>>>> morning when he arrives in the office.  We've been quite chatty over the
>>>> weekend.
>>>>
>>>> Cheerio John
>>>>
>>>>
>>>>
>>>> On 6 Aug 2016 7:02 pm, "Laura O'Grady" <la...@lauraogrady.ca> wrote:
>>>>
>>>> There's a form [1] requesting this data set. Not sure if posting a
>>>> request will help as we know this has been going on for year

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

[Adam Martin]

Hey Bjenk,

On the Address data, the Talk-CA group has had several discussions about
it. The problem boils down to Canada Post, which treats the information as
proprietary - they provide any individual going to their site the right to
lookup an address in order to utilize their service to mail items. The
actual database is theirs and even the postal code on my home is theirs,
I'm just allowed to use it. This all likely has more to do with the fact
that they have a service that links the addresses to mapped locations that
is, of course, available only for those willing to pay for it. If they
allowed OSM to integrate this information, they would lose that revenue
stream.

Suffice it to say that, apart from an individual adding their address
manually to the map, Canada Post is not about to allow any party to use
that information freely.

On Wed, Aug 10, 2016 at 11:41 AM, Ellefsen, Bjenk (STATCAN) <
bjenk.ellef...@canada.ca> wrote:

> The postal code subject is interesting for many reasons. I read that
> France has released a National address database, publically and free.
>
>
>
> There must be a way we can follow that example.
>
>
>
> I am still catching up, haha!
>
>
>
> Bjenk
>
>
>
> *From:* john whelan [mailto:jwhelan0...@gmail.com]
> *Sent:* August-06-16 7:23 PM
> *To:* Laura O'Grady 
> *Cc:* Talk-CA OpenStreetMap ; Ellefsen, Bjenk
> (STATCAN) ; Stewart C. Russell  >
> *Subject:* Re: [Talk-ca] Crowdsourcing buildings with Statistics Canada
>
>
>
> The postcode battle is being fought on the Open Data side.   There is an
> open data mailing list whose name escapes me where they have been playing
> for years to get the postcode data including access to information requests.
>
> Tracy at Carleton University is well connected on the Open Data side and
> the postcode saga.  There is some hope now that the UK post office has made
> the UK ones available.
>
> For the moment many commercial companies do list their postcode on their
> web sites and the the commercial buildings that are the ones of interest to
> Stats Canada.
>
> I suspect Bjenk will have fun when he checks his email on Monday morning
> when he arrives in the office.  We've been quite chatty over the weekend.
>
> Cheerio John
>
>
>
> On 6 Aug 2016 7:02 pm, "Laura O'Grady"  wrote:
>
> There's a form [1] requesting this data set. Not sure if posting a request
> will help as we know this has been going on for years.
>
>
>
> You can get the Forward Sortation Areas in a boundary file [2], which can
> be exported from the db. I noticed the disclaimer, "This data includes
> information copied with permission from Canada Post Corporation". But of
> course this is incomplete. I wonder if it's the latter 3 characters,
> the Local Delivery Unit, which can pinpoint to individual households is
> being suppressed for privacy reasons.
>
>
>
> As an academic we battled Stats Can for years for access to data that was
> paid for by taxpayer dollars. Eventually we won. So there's a precedent of
> sorts.
>
>
>
> Has anyone tried filing a freedom of information request for the postal
> codes?
>
>
>
> Laura
>
>
>
> -
>
> Laura O'Grady
>
> la...@lauraogrady.ca
>
>
>
>
>
> [1] http://open.canada.ca/en/suggested-datasets/postal-code-database
>
> [2] https://www12.statcan.gc.ca/census-recensement/2011/
> geo/bound-limit/bound-limit-2011-eng.cfm
>
>
> On Aug 6, 2016, at 2:12 PM, john whelan  wrote:
>
> ​I understand the current intent is data.gc.ca
>
> There is actually a lot of postcode data in Ottawa adhresses as it stands
> especially for commercial buildings.  Don't hold your breath for Canada
> Post and postcodes.
>
> Some attributes they would like at the moment I can't see how a mapper
> would map them from physically looking at the building.
>
> If nothing else it should clean up the map.  For that reason it would be
> nice to be able to pull chunks into JOSM and go over it looking for obvious
> errors and spelling mistakes in tags.  Maperitive has the ability to
> extract the tags and export them in spreadsheet format which is good for
> this sort of thing but you need a source to feed it.​
>
>
>
>
>
> Cheerio John
>
>
>
> On 6 August 2016 at 12:38, Stewart C. Russell  wrote:
>
> Hi John - some great points here.
>
> > My understanding is currently he’s looking getting hold of the City of
> > Ottawa building outline data and making it available to OpenStreetMap
> > without the current license restriction.
>
> This would be wonderful. It would be ideal if the data could be placed
> on data.gc.ca and use the OGL-CA v2 licence. OSM can't use any data
> under the City of Ottawa Open Data - Terms of use
> . I
> also have my doubts about the acceptability of the Statistics Canada
> Open Licence Agreement 

Re: [Talk-ca] New project update

[Adam Martin]

Hi Bjenk,

I think what Paul meant was more along the lines of what specifically you
wanted to do. You state that you want to define a project, but other than
stating that you want to collect certain information about non-residential
buildings, we have little else to go on.

>From the sound of it, you want to use OSM to collect and map specific
information about these non-residential buildings. Are we talking about the
number of windows in the building or employees? The number of floors or the
specific businesses / activities carried out in them?

Just give us something more to go on and we can discuss it from there :)

Adam

On Thu, Apr 21, 2016 at 2:11 PM, Ellefsen, Bjenk (STATCAN) <
bjenk.ellef...@canada.ca> wrote:

> Paul,
>
> All this is open for discussion at this point. We are looking at all the
> options.
> By defining a project its more like stating what information we wish to
> focus on.
> We hope to work with the OSM community and we are looking at different
> ways of doing that.
> We also have different data sources that we will be evaluating to
> potentially link to these buildings.
>
> Thanks for your feedback!
>
> Bjenk
>
> -Original Message-
> From: Paul Ramsey [mailto:pram...@cleverelephant.ca]
> Sent: April-21-16 12:26 PM
> To: Ellefsen, Bjenk (STATCAN) 
> Cc: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] New project update
>
> Hey Bjenk,
> When you say "define a project" are you talking about
>
> (a) describing a scope of work that StatsCan intends to resource and
> complete?
> (b) describing a scope of work that StatsCan hopes the OSM community
> will complete on your behalf?
>
> You've used the passive voice in describing the actual collection in
> your description below, so it's not completely clear who you think
> will be collecting the information.
>
> ATB,
>
> P
>
>
> On Thu, Apr 21, 2016 at 8:35 AM, Ellefsen, Bjenk (STATCAN)
>  wrote:
> > Hello everyone,
> >
> > Basically, what we would like to do is define a project for OSM to
> collect
> > information about non-residential buildings.
> > We would like to popose a list of what would be collected. We were
> thinking
> > of identifying specific areas to start with.
> >
> > Cheers,
> >
> > Bjenk Ellefsen, PhD
> >
> > Center for Special Business Projects | Centre des Projets Spéciaux sur
> les
> > entreprises
> > Statistics Canada | Statistiques Canada
> >
> >
> >
> >
> > ___
> > 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] New Project

[Adam Martin]

OSM is community driven so you've basically come to the right place to
propose projects for Canada. If the project proposes some sort of change to
the structure of OSM itself, it would need to be brought before the Board
of the Foundation (see http://wiki.openstreetmap.org/wiki/Foundation for
more information on that).

I assume that, being that this is Statistics Canada, changes to the
structure are not the goal, just some sort of improvement on the map data
in Canada. If that is the case, give us the summary of what you wish to do
and we will certainly try to help where possible.

Adam

On Wed, Apr 20, 2016 at 12:26 PM, Ellefsen, Bjenk (STATCAN) <
bjenk.ellef...@canada.ca> wrote:

> Hello everyone,
>
> My name is Bjenk Ellefsen, I work at Statistics Canada.
> We are interested in knowing more about putting together a potential
> project with openstreetmap.
> I have a couple of questions: who should we talk to? Is there a board or
> admins we should be talking to?
> How do we submit a project we would like to invite contributors to
> participate in?
> Also, could we define the data model for the collection?
>
> Any insights would be welcomed!
>
> Bjenk Ellefsen
>
>
> ___
> 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

[Adam Martin]

That is a significant issue. If the original user *brousseaumat* was the
one that made the import and he / she has ... only 8 edits to their name,
all within Ontario, then reversing his work may be enough.

On Mon, Feb 29, 2016 at 2:32 PM, James  wrote:

> There's also the problem: how do you know that the bus stop was from an
> import vs user created.
> On Feb 28, 2016 8:48 PM, "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.
>>
>> Is anyone going to take the responsibility on for removing the data?
>>
>> Thanks
>>
>> Cheerio John
>>
>> On 28 February 2016 at 20:37, Stewart C. Russell 
>> wrote:
>>
>>> Hi John, and all —
>>>
>>> If this is the GTFS data for Ottawa:
>>>
>>> http://data.ottawa.ca/dataset/oc-transpo-schedules
>>>
>>> then it's published under the City of Ottawa Open Data - Terms of use:
>>>
>>>
>>> http://ottawa.ca/en/mobile-apps-and-open-data/open-data-terms-use
>>>
>>> This licence is incompatible with the ODbL used by OSM:
>>>
>>> http://clipol.org/licences/16?tab=licence_compatibility
>>>
>>> and therefore these data, and any others derived from Ottawa municipal
>>> data sets, should be removed from the map.
>>>
>>> I know that there may be commuting apps that rely on these data points,
>>> but it's Ottawa's silly fault for using a licence that's only compatible
>>> with itself.
>>>
>>> cheers,
>>>  Stewart
>>>
>>> ___
>>> 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

[Adam Martin]

This is often the trouble that long-term mappers might have with
hit-and-run mappers, especially with regards to "living" information that
is added to the map. Static information, like large buildings in a mature
location or major thoroughfares, can be added by these quick mappers and
remain relatively "safe" in terms of display on the map. The more living
that information might be, such as bus stops in a metropolis or the
individual businesses in a strip mall, the more prone it is to becoming
stale-dated. Mappers in the area would be better suited to updating these
points.

On Sun, Feb 28, 2016 at 5:37 PM, James  wrote:

> Most of the STO bus stations were manually added by myself, not sure if
> there were any added/changed after the fact
> On Feb 28, 2016 4:02 PM, "john whelan"  wrote:
>
>> So it sounds like essentially we are saying the import wasn't discussed
>> at least as far as what the tags were to be used, I note that the STO stops
>> on Wellington have a different set of tags.  Nor was any thought given to
>> preserving bus shelter information nor to keeping the information up to
>> date nor to removing any bus stops already mapped.
>>
>> Oh well such is life.
>>
>> Cheerio John
>>
>> On 28 February 2016 at 15:19, Andrew MacKinnon 
>> wrote:
>>
>>>
>>> On Feb 28, 2016 3:05 PM, "john whelan"  wrote:
>>> >
>>> > It appears in august 2013 user andrewpmk imported the OC transpo bus
>>> stops, which is fine I don't have a problem with imports but I understand
>>> OC transpo issue a new updated GTFS file every year.  Are there plans to
>>> reimport all the bus stops or will they simply become unreliable?  ie most
>>> will be there and some will be missed.
>>> > These bus stops have been imported since the POI information includes
>>> information which is not visible at the bus stop but is available form the
>>> GTFS file.
>>> >
>>> > I have three concerns, one is the GTFS file does not include bus
>>> shelters and some existing bus stops have been mapped with shelter
>>> information.  Are we to lose bus shelter information?  The second is
>>> locally andrewpmk mapped bus stops in 2011 without the GTFS POI information
>>> and they are still there.  So some locations have two bus stops mapped
>>> where there should be only one.  The third one is how reliable is the data?
>>> Were all the bus stops in Ottawa imported and how do we communicate to
>>> users this bus stop was mapped in Aug 2013 if they aren't using JOSM?
>>>
>>> The bus stops were imported by brousseaumat. I just added the operator
>>> OC Transpo to them.
>>>
>>> ___
>>> 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] Islands with coastlines not showing up in OSM

[Adam Martin]

Hey Denis,

Changes to the coastline takes time to pass through the tile rendering. If
I recall correctly, the coastal tiles may take several weeks to update and
require manual intervention. Looking at the Wiki, I see this (
http://wiki.openstreetmap.org/wiki/Coastline): "*Coastline rendering in
Standard tile layer
 may update later
than other rendering changes. To avoid major disruptions of map rendering
due to data errors the coastline is not automatically updated if there are
larger changes in the geometry compared to the last time it was
successfully processed. For example any addition or removal of a lake with
coastline tag will require manual intervention.*"

The same page also notes that "*At low zoom levels (used for z0-9), up to
and including zoom level 9, Mapnik
 renders all the sea as a solid
fill of blue, generated from the shapefile
simplified-land-polygons-complete-3857.zip
,
which has a relatively low resolution. At higher zoom levels the coast
polygons used are generated from a larger shapefile
(land-polygons-split-3857.zip
) which are
automatically generated almost daily from planet dumps + diffs (note: if
you edit the coastline then you have to be patient for the result of the
changes to render at the higher zoom levels).*" If your changes are very
recent, it may not be showing up as the tiles have not been rendered. If
they are older, check to make sure that the polygons are closed loops so
that the renderer knows what to do with them.

Adam

On Wed, Feb 24, 2016 at 2:27 PM, Denis Carriere 
wrote:

> Quick question for anyone on this mailing list.
>
> We are having issues displaying islands up in northern Canada, some
> islands are showing up correctly and some do not.
>
> We seem to have all the tagging correct and the correct geometry
> (validated with JOSM the coastline so it's not reversed).
>
> Any reason why it's not showing up properly in OSM? Is there a delay of
> 24+ hours for any features that are related to the coastline?
>
> Here is one of many features that are not getting rendered:
>
> *Thomas Work Island, Nunavut (Not showing up)*
> https://www.openstreetmap.org/way/398936588
>
> *OSM Tags*
> name=Thomas Work Island
> natural=coastline
> place=island
> source=NRCan-CanVec-10.0
>
>
> Any ideas anyone?
>
>
>
> *~~*
> *Denis Carriere*
> *GIS Project Manager*
>
> *Twitter: @DenisCarriere *
> *OSM: DenisCarriere *
> GitHub: DenisCarriere 
> Email: carriere.de...@gmail.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

Re: [Talk-ca] Grand Lacs / Great Lakes

[Adam Martin]

Hello Sebastien,

I remember seeing a discussion of this issue - not on the talk.ca mailing
list, but on the subreddit for Openstreetmap (
https://www.reddit.com/r/openstreetmap/comments/3z7w9d/where_are_the_great_lakes/).
In it, the OP notes that the Great Lakes have disappeared off the map at
higher zoom levels. The reason was traced to the acts of one user whom
seemingly decided to unilaterally changed all the tags on the Lakes from
Coastline to Natural=Water, thus killing the rendering of the Lakes at
those zoom levels. But this rendering is only a problem for the default
renderer - many others will display it correctly.

Haven't heard of a consensus on the matter. Technically, the coastline tag
is incorrect as these are Lakes, not Oceans / Seas. So this change is
technically for the better as it is more accurate. But the rendering has
been coastline for sometime.

Adam

2016-01-24 14:38 GMT-03:30 Sebastien Duthil :

> English version follows.
>
> Bonjour à tous,
>
> j'ai remarqué que, sur le zoom 5 du rendu standard OSM [1], seul le lac
> Huron apparaît. S'en suivent plusieurs questions:
>
> - Est-ce normal?
> - Le wiki OSM [2][3] fait état que les Grands Lacs font partie des rares
> lacs qui soient taggés natural=coastline et de ce fait, ils devaient
> toujours être visibles.
> - En regardant de plus près les relations de ces lacs, je n'ai pas vu le
> tag natural=coastline. J'ai trouvé les changesets suivants, qui
> suppriment le tag natural=coastline:
>
>   - Lac Supérieur: 15 janvier 2016 [4]
>   - Lac Michigan: 15 janvier 2016 [5]
>   - Lac Huron: 08 janvier 2016 [6]
>   - Lac Ontario: 02 mars 2015 [7]
>   - Lac Erie: 25 décembre 2015 [8]
>
> - La dernière discussion que j'aie vu sur talk-us/talk-ca à ce propos
> date du 26 avril 2015 [9], où le tag natural=coastline a été conservé,
> sauf pour le lac Ontario, qui ne l'avait déjà plus. Avez-vous
> connaissance d'une autre discussion plus récente à ce sujet sur d'autres
> listes qui pourrait justifier cette modification?
> - Devrions-nous remettre le tag natural=coastline? Mon avis est que oui,
> s'il n'y a pas eu discussion antérieure. Sa disparition doit être
> discutée en amont.
> - Étant donné que plus aucun Grand Lac n'a natural=coastline, pourquoi
> seul le lac Huron est-il visible?
>
> --
>
> Hello everyone,
>
> I see that the standard rendering of OSM on zoom 5 [1] only shows Lake
> Huron, but not the other Great Lakes. Here are my questions:
>
> - Is this normal?
> - The OSM wiki [2] [3] says that the Great Lake are the few exceptions
> of lakes being tagged as natural=coastline, which should make them
> visible at any zoom level.
> - By looking at the different lakes' relations, I did not see any
> natural=coastline tag. Here are the changesets removing natural=coastline:
>
>   - Lake Superior: January 15th 2016 [4]
>   - Lake Michigan: January 15th 2016 [5]
>   - Lake Huron: January 8th 2016 [6]
>   - Lake Ontario: March 2nd 2015 [7]
>   - Lake Erie: December 25th 2015 [8]
>
> - The latest discussion I've seen on this topic on talk-us/talk-ca was
> on April 26th 2015 [9], where the decision was to restore
> natural=coastline instead of natural=water (except on Lake Ontario,
> which already had natural=water). Do you know of any more recent
> discussion about this on other lists, that would support this change?
> - Should we restore natural=coastline on the Great Lakes? My opinion is
> yes, if there were no prior discussions. Then if someone wants to change
> it, he should discuss it first.
> - Since no Great Lake has natural=coastline anymore, why is Lake Huron
> the only one to show on the standard rendering?
>
> --
>
> [1] http://www.openstreetmap.org/#map=5/43.866/-85.034
> [2] https://wiki.openstreetmap.org/wiki/Great_Lakes
> [3]
>
> https://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline#What_about_lakes.3F
> [4] http://www.openstreetmap.org/changeset/36589478
> [5] http://www.openstreetmap.org/changeset/36589361
> [6] https://www.openstreetmap.org/changeset/36454539
> [7] https://www.openstreetmap.org/changeset/29200524
> [8] https://www.openstreetmap.org/changeset/36168843
> [9]
> https://lists.openstreetmap.org/pipermail/talk-us/2015-April/014812.html
>
> --
> Sébastien Duthil
>
> ___
> 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] Metrolinx: OSM Golden Horseshoe Address Data

[Adam Martin]

Taking a look around the data in OSM for Toronto, it would appear that the
address interpolations have been added via import from CanVec already,
Pierre. Which prompts the question as to what, exactly, did the people from
Metrolinx mean when they expressed concern about "getting better address
ranges than individual points". The current data is in address range
format. So are these inadequate (either that they don't cover the correct
spaces, are incomplete or missing) or are they looking for addresses to be
attached to specific buildings?

Adam

On Tue, Jan 12, 2016 at 1:55 PM, Pierre Choffet  wrote:

> Hello,
>
> I'm not sure this message will help, but just in case: here in Montreal,
> we have imported the address layer from CanVec data which includes the
> interpolations. Import is never trivial, but given your needs and the
> improvement of the service for all users it's probably a good idea to
> evaluate this dataset first.
>
> Cheers
>
> Pierre
>
> Le 12/01/2016 08:52, Stewart C. Russell a écrit :
>
> Hey,
>
> We had a couple of folks from Metrolinx (the GTHA/Golden Horseshoe transit
> agency) at the Toronto Mappy Hour last night. Their Triplinx route planner
> — http://www.triplinx.ca/ — consumes OSM data for addresses. They want to
> find ways to work with the community to improve addressing in their service
> area. They're mostly concerned about getting better address ranges than
> individual points.
>
> I don't know what their next steps are, but they seem to be approaching
> the community in a different and slightly better way than most agencies.
>
> cheers,
>  Stewart
>
>
> ___
> Talk-ca mailing 
> listTalk-ca@openstreetmap.orghttps://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] CanVec+

[Adam Martin]

Hi all!



Thanks for the heads up, James. I was not personally aware of this change
until now. Reading the news release for the CanVec+ from the Geogratis site
(http://geogratis.gc.ca/site/eng/whats-new/intro-canvec). I think one of
the key statements on the website is that the Department of Natural
Resources is *transitioning* to an improved data model with the goal of
providing seamless information. New vector products will be available under
this model *eventually*. That’s all good.



However, CanVec+ *is not* that new product. It is, instead, “an interim
product for the transition”. CanVec+ is just a new way for the Department
to publish the same data. They mention that it is a model that is supposed
to allow them to frequently update the data at the best resolution. This is
good, but is not likely to be of great benefit to OSM since the areas that
would get frequent update would, most likely speaking and from a logical
standpoint, be areas of high human concentration - AKA areas that OSM user
mapping efforts are concentrated. For other areas, in James’ words, the
shapefiles would need to be manually converted.



Personally, I see little point in adopting this information in any
widespread or meaningful way. CanVec+ is essentially the same data that we
currently have. The possibility of updates to the dataset would be
relatively meaningless. Until the new data format is released, I would
recommend sitting on this matter, if my reading of that news release is
correct (I could be wrong). If a new data format is coming, that might be
useful, though caution would need to be taken to ensure that user changes
were not overridden with it.



Adam

On Wed, Oct 7, 2015 at 3:09 PM, James  wrote:

> I was just wondering if anyone knew that CanVec data is being phased out
> and replaced by CanVec+. I spoke with Marc LeMaire from NRCan and he said
> that they will not be offering .osm conversions of CanVec+ data, which
> means that we will have to convert the shapefiles ourselves. My question is
> has anyone begun coding/documenting CanVec+ data for conversion yet? Marc
> said that they are ending CanVec by the end of the year.
>
> ___
> 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] Fwd: Ottawa, Canada import

[Adam Martin]

I would think it's the parts that give them the power to revoke the license
to use the data at any time. For it to be used in OSM, it has to be
essentially surrendered to the map. When I joined two years ago, one of the
stipulations was to specifically accept the licensing agreement of OSM
which effectively had me surrender any and all edits to OSM. It would
reserve the right to maintain, modify, delete and otherwise use any
information that I inputted as their own. Which makes complete sense, else
if I were to become vindictive, I could try to revoke my license and they
would have to remove my edits, which is difficult and potentially damaging.

Specifically, as Steward mentioned, Ottawa has the reserved the right of
cancellation of access to the data:

*The City may, in its sole discretion, cancel or suspend your access to the
datasets without notice and for any reason, including anything which the
City, in its sole discretion, believes is a breach of these Terms of Use or
is otherwise unlawful or harmful to others. In the event of cancellation or
suspension, you will no longer be authorized to use or reproduce these
datasets, and the City may use any means possible to enforce its decision.
Such cancellation or suspension will not affect any person who has received
the datasets from you and who is otherwise in compliance with these Terms
of Use.*

Basically, they can revoke the access and OSM will be forced to comply,
removing the data and, as a result, any edits made that were based off that
data. The other problem is the Liability clause. If they feel the use was a
breach, then they may sue, indemnifying OSM and making it open to
litigation. We, as users, don't have the right to do that.
On Aug 20, 2015 4:59 PM, James james2...@gmail.com wrote:

 I got an email back from the guy handling the Licensing.

 Hi James, thank-you for the email.  I’m not sure I understand the
 compatibility grid.   Is there a particular issue you are concerned about?



 Note: we have plans to adapt the Open Government License Canada but have
 not been able to do that quite yet; however, there are few differences
 between the two, so if there’s a specific item you are concerned about it I
 might be able to shed some light on how we treat it.




 Thank-you,


 Robert Giggey
 ---

 What would be the specifics of our license (ODbL) incompatible with
 Ottawa-TOU?

 On Wed, Aug 19, 2015 at 10:14 AM, James james2...@gmail.com wrote:

 Email I got after I said I will be unable to use the data due to
 incompatible licensing:


 James,

 I’m going to forward this inquiry on to Robert Giggey. He is in charge of
 the Open Data program at the City. I must say, I am a little surprised that
 this interpretation is so restrictive. I personally was not aware of this.
 I will also follow-up with Robert in this regard.


 *-Stephen*

 Maybe, they just needed some education? P.s. thank you Stewart for the
 comparison tool!

 On Wed, Aug 19, 2015 at 9:23 AM, Stewart C. Russell scr...@gmail.com
 wrote:

 Hi James —

  What should I tell Stephen, to change the license for just OSM or in
 whole?

 For simplicity, they'd need to change the licence for everyone. A
 special carve-out for OSM alone would be fraught with problems.

 Ideally, they'd chose a licence that isunencumbered, like CC0 or PDDL.
 Any attempt to roll your own licence adds compatibility problems, and
 municipalities do love to keep those little clauses in that allow them
 to recall data.

 If you want to show Stephen how compatible and open the city's licence
 isn't, show him this:

  http://clipol.org/licences/16?tab=licence_compatibility

 It shows how Canadian municipalities all shared and tweaked licences,
 and inadvertently made them incompatible with everything. And they
 complain about why no-one uses their data.

 If they do want to change (great!), I know there are some folks on this
 list just itching for a roadtrip to the NCR to do some municipal
 education …

 cheers,
  Stewart


 ___
 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] Highway recoding

[Adam Martin]

Reviewing the types that you suggest here, the result seems reasonable.
Major Canadian Highways are generally a blend of the two, I find. Type 1
trunks rely on restricted access and the main highways in cities are
generally limited in this manner. Likewise, these restrictions lift, in a
sense, outside the city where they switch to connecting major settlements
together (Type 2).

That said, I think that most would agree that the TransCanada Highway is
automatically a trunk route given that it is, at it's most basic point, the
central connection between major settlements, especially across provincial
borders. I assume that the routes that leave the TCH to go to other major
settlements would need to be at the same class as the TCH, if they are
multi-lane highways used to connect settlements. Or are we to designate
them down a classification and leave Trunk for the TCH alone?

On Thu, Jul 23, 2015 at 6:48 PM, Tristan Anderson 
andersontris...@hotmail.com wrote:

  So it seems like we're coming to some agreement.  The current Canadian
 definition based on that 2005 document should be replaced with something
 else that is consistent with the rest of the world.  Once we find this new
 definition, the appropriate wiki pages should be updated.

 I took a look around the world and finally saw some consistency in how
 trunk tags are used.  Stewart's guidelines are basically correct, but I
 think I can hammer out a more specific description.  There are two types of
 roads with are both usually tagged highway=trunk:

 (1) Limited access highways.  This is a physical description for a road
 that has some of the characteristics of a motorway.  They are often dual
 carriageways of fairly high speed.

 (2) Highways connecting distant population centres.  This is a functional
 description for a road where used by cars and heavy trucks travelling long
 distances or between major cities.  Although usually two lanes, in more
 remote areas these roads may have very light traffic, be unpaved, or be
 slow.

 In some parts of the world, like Germany, France and the eastern United
 States, all trunk roads are type (1) because long-distance travel is
 generally done on their dense networks of motorways.

 Conversely, in large swathes of Australia and Canada, as well as in much
 of the developing world, all trunk roads are type (2) because type (1)
 doesn't exist.

 The only country I noticed that doesn't follow the above scheme is Britain
 (actually just England and Wales), ironically the birthplace of the trunk.
 The designation there is used quite liberally, including even short roads
 connecting small towns and quite a few of of London's city streets.  Just
 look at England at zoom level 5 and observe how unusually green it is.

 I suggest using the international model, with types (1) and (2) above
 being tagged as trunks in Canada.  This won't change much as it largely
 coincides with how roads are already tagged.  The wiki pages can be updated
 accordingly then we can look at specific roads in BC and Québec!

 Any objections?



  From: jfd...@hotmail.com
  To: scr...@gmail.com; talk-ca@openstreetmap.org
  Date: Thu, 23 Jul 2015 10:08:44 -0400
  Subject: Re: [Talk-ca] Highway recoding
 
  Thank Russel,
  Your description is pretty close of the one I had in mind (about trunks)
 before I found the Canadian definition was referring to the mentioned
 document.
 
  Cheers,
 
  Daniel
 
  -Original Message-
  From: Stewart C. Russell [mailto:scr...@gmail.com]
  Sent: July-23-15 08:44
  To: talk-ca@openstreetmap.org
  Subject: Re: [Talk-ca] Highway recoding
 
  The definition of ‘trunk’ is a difficult one, if based on the UK
 understanding. Like its unwritten constitution, trunk roads in the UK are
 more on a know it when I see it basis.
 
  Pretty much the only definitions I can think of that would be generally
 applicable are:
 
  * a trunk road goes from one city/town to another.
 
  * no parking at the side of the road.
 
  * something above the urban speed limit applies (though there are often
 nasty brief exceptions, like a roughly 200m stretch of 30 mph that used to
 adorn the A80, dammit).
 
  A trunk road isn't always dual carriageway. It can have traffic lights,
 roundabouts or (rare, in the UK) stop signs. Depending on its age, it may
 bypass towns and villages. Older trunk roads may also have all the usual
 roads entering it, while newer ones are likely to have on-ramps.
 
  In summary, the UK definition is so riddled with unwritten exceptions
 that trying to apply it rigorously in even one province in Canada will be
 frustrating. And no matter what you do, you'll always get some rogue user
 that comes along and adds their own tagging. It's a sair fecht …
 
  cheers,
  Stewart
 
  ___
  Talk-ca mailing list
  Talk-ca@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-ca
 
 
  ___
  Talk-ca mailing list
  

Re: [Talk-ca] Data import

[Adam Martin]

Good point - there is lots of good, free data being compiled out there that
could make excellent additions to the map. But importing is a very complex
business - especially in any area where other survey and contributor data
already exists. Extreme caution should be taken to ensure that imported
data does not replace or destroy their hard work. Survey the current data
in the area slated for having new data imported and ensure that there are
no conflicts (likely that there might be some conflict with CANVEC in any
area, but that should be fine). I suggest contacting one of the OSM
contributors that have imported large amounts of data before to get the 411
on possible problems and such.

Adam

On Tue, Jun 23, 2015 at 9:41 PM, Iain Ingram i...@monkeyface.ca wrote:

 Thanks Jim,

 I have read a bit about JOSM and the plugins.

 I do agree that imports should be used sparingly. That said there is a lot
 of open data being produced by various groups that would help the map

 Iain
  On Jun 23, 2015, at 8:49 AM, Jim McAndrew j...@loc8.us wrote:
 
  I'm not sure about a tutorial, but there is a nice wiki page on it
 here:  http://wiki.openstreetmap.org/wiki/Import/Shapefile
 
  I use the Open Data plugin for JOSM (
 http://wiki.openstreetmap.org/wiki/JOSM/Plugins/OpenData) when I import
 shapefiles. Imports are mostly frowned upon in the community, so make sure
 to read the wiki carefully and be ready to defend your edits.
 
  On Tue, Jun 23, 2015 at 6:47 AM, Iain Ingram i...@monkeyface.ca wrote:
  Hello all,
 
  I was wondering if anyone has a tutorial on importing data sets from
 shape files. There is a few data sets on Calgary open data for small towns
 around Calgary that include address information as well as building
 outlines.
 
  Thanks
  Iain
 
  www.calgaryregionopendata.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] Adding Buildings + Leisure + Corrections To Ottawa Map Over Holiday Season

[Adam Martin]

Hey Russell / all,

I performed a rudimentary test of an address in the map without a postal
code and later used the Nominatim to search for it to see what it produced.
The address was 27 Cairo Street in St. John's, NL - I used this because it
is an old address of mine and I know the postal code there without
reference to Canada Post or the like. The result from Nominatim is A1B 3X9.
The actual postal address is A1C 4X2 - a significant difference. I don't
believe that the postal data in Geocoder is particularly accurate.

Adam

On Tue, Dec 23, 2014 at 6:11 PM, Stewart C. Russell scr...@gmail.com
wrote:

 On 2014-12-23 12:27 PM, Richard Burcher wrote:
  - I've removed the mention of postcode collection. I'm not sure of the
  legal aspect of collection as raised in an earlier thread.
 

 I've found that if you add an address without a postal code, then query
 Nominatim later, it returns the postal code. I suspect geocoder.ca data
 is involved somewhere along the way.

 cheers
  Stewart


 ___
 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] Postal Codes

[Adam Martin]

Hey all,

I was reading over the previous discussions held here regarding the issue
of obtaining postal codes for use with civic addresses in Canada. I
understand that, unless specific permission is obtained, there is no way to
utilize the information stored in the Canada Post database, even if that
information is manually acquired from the database during a lookup. The use
is restricted to a very limited personal or business application - ie, I
want to send a package and I use the database to get the postal code of the
address.

It initially appears odd that Canada Post would be very restrictive with
the code data. I understand that they maintain consumer names with the
address data, but the OSM project would not be seeking that connective
data, just the bare address to attach to a civic or business address.
Looking about their site, I eventually encountered this little gem ---
https://www.canadapost.ca/cpo/mc/business/productsservices/mailing/pcdp.jsf

It would appear that Canada Post sells a data product that is, effectively,
the postal code data attached to a map. It is provided to businesses for
the purposes of datamining, allowing them to hone their mailings or
identify exploitable market areas. The cynic in me figures that this is the
real reason that they won't give OSM the permission to use the data. Not
for protection of the consumer or for privacy, but to make money. Fair
enough - it is technically a business.

Anyway, it would appear that obtaining the information from Canada Post is,
basically, a dead end. Might I suggest an alternative? Why not a volunteer
effort? I can't look up a code and reproduce it on the map, but I can
surely put my own postal code and those of my previous addresses into the
map. That knowledge has nothing to do with looking it up on their website.
I also know the code for my small hometown in Newfoundland as I lived there
for years and the entire town uses the same code. Perhaps there is a way to
gather the information voluntarily from Canadian citizens and businesses.
Basically go around them? For example, a survey on the Reddit forum for
Canada could be asked or something like that. The more we can get without
using the post office, the better. Business websites are easily some of the
best sources - they offer their mail address without any restriction so
that is fair use too.

Just a thought!

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

[Talk-ca] Road designations

[Adam Martin]

I have a question for the group regarding the designation of various roads
within city regions. Specifically, with reference to primary, secondary,
and tertiary roads. What exactly is the criteria being used to designate a
road as one or the other? I know that the wiki provides guidance, but it
does not appear that the guidance is always followed.

For example, this is an area inside Montreal:

​As you can see, there are two secondary one-way roads here (orange) and a
yellow tertiary road connecting them together in the lower right. I cannot
fathom why that roadway would be tertiary - it's just a simple connection
between the roads and should likely not be considered tertiary. Especially
given the guidance on the wiki *The highway
http://wiki.openstreetmap.org/wiki/Key:highway=tertiary tag is used for
roads connecting smaller settlements, and within large settlements for
roads connecting local centres. In terms of the transportation network,
OpenStreetMap tertiary roads commonly also connect minor streets to more
major roads.*

Here is another example along the same roadway in Montreal:

​Here we see a similar connection as before, but this one is designated as
a residential road. But we also get to see a very interesting thing occur -
the two one-way secondary roads suddenly transform into two tertiary
one-way roads. The problem here is that there does not seem to be a reason
for that changeover in the road type; the road continues as two one-way
roads through the Parc industriel d'Anjou area. The position of the change
also appears to be random or arbitrary.

I'm seeking a bit of clarification. I like to be cautious with changing
road types in regions just in case there is a reason I am not aware of for
them to be designated in this way.

Thanks,

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

Re: [Talk-ca] Discussion: zones boisées

[Adam Martin]

Hello Dega / all,

With regard to a path that cuts through a forest, the initial thought might
be to map the path as dirt or something similar. However, this would not be
efficient nor required. A line that denotes a path is, in itself,
technically a type of land tag as the any such pathway must meet some basic
criteria to be a path (deliberate connection, open land area, clearly
defined, etc).

For example, a regular residential road that cuts through a residential
area. Do we designate the entire area, including the land that the roads
are on as residential or do we segregate the land that the road occupies as
something separate from the residential land use? The first one allows for
large, uninterrupted polygons denoting a residential area while the second
makes for dozens of small polygons separated by roadways. It all depends on
what you think the line that makes up the road itself on the map
represents. If it represents a type of land use tag, then the first case
makes sense as the land is residential in general, except for any area
marked with a route as that route would mark the land as used for a road
within the residential area. If roads do not tag the ground beneath it,
then we need to specifically set what the ground underneath is to be tagged
as, requiring multiple smaller polygons to map.

Adam

2014-11-21 9:16 GMT-03:30 Bruno Remy bremy.qc...@gmail.com:

 Bonjour Dega,

 En effet toutes les clairières devraient être taguées en consequence par
 un polygone. Un tag approprié pour cela pourrait être meadow ou scrub.

 Quand à la présence ou non d'un sentier... difficile à dire par la vue
 satelite: il faut vraiment un reperage terrain par des contributeurs locaux.
 D'où la complémentarité entre une communauté locale vivante et des données
 Canvec qui ne fournissent qu'un matériel brut

 Bruno
 Le 2014-11-20 10:30, Ga Delap gade...@gmail.com a écrit :

 Bonjour Bruno
  Je suis d'accord avec la logique de Frank : redécouper les polygones de
  CanVec selon les lignes de frontiéres naturelles (rivières, lacs...) et
  artificielles (routes, lignes électriques, lignes coupe-feu...etc..).
 J'ai regardé tes exemples. C'est un compromis intéressant. La zone fôret
 est
 séparée en parcelles délimitées par toute entité linéaire (route, ligne
 électrique, voie ferrée, etc) ou surface (lac, bâtiment, clairière, etc).
 Je
 n'ai vu aucun trou.
 Mais il ne faut pas oublier de définir l'entité qui se trouve entre 2
 parcelles
 car l'absence de forêt n'est pas, en soi, une entité.
 Par exemple, il y a surement un objet physique qui sépare les chemins
 302348523 et 302349825. Je ne connais pas le territoire mais ce semble
 être un
 chemin forestier qu'il faudrait définir. Et, à la limite, ce chemin
 linéaire
 devrait être défini à l'intérieur d'une surface 2D de type clairière.
 Ce qui m'améne à poser de nouveau une question de l'article qui a initié
 cette
 discussion:
 Est-ce correct d'utiliser l'absence de définition (undefined) pour
 représenter
 les clairières? Est-ce que toutes les zones blanches de la carte OSM sont
 des
 clairières?

 Bonne journée

 dega

 ___
 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] Fwd: RIP CanVec

[Adam Martin]

Oops, meant to reply to the list, not an individual. :)


-- Forwarded message --
From: Adam Martin s.adam.mar...@gmail.com
Date: Mon, Nov 17, 2014 at 7:43 PM
Subject: Re: [Talk-ca] RIP CanVec
To: Alan Trick alantr...@gmail.com


I have had some experience regarding the use of Canvec data. I have not
tried to import this data myself nor would I try - it is complex enough
that I think it is better that I keep my fingers out of it. My experience
with Canvec has been limited to correcting the data in areas that I am
editing in.

I echo the statements of Ga Delep in part - the data, in some areas, has
been haphazardly imported with features out of alignment and possible
destruction of user contributed data. But on the balance, I think it has
been a good information source in the hands of experienced importers. Land
features, such as local hills, groves, open landscapes, reefs ... these are
excellent pieces of information for the map. It has it's issues - the tiled
nature of the data is one problem. Another is the enormous multipolygon
relations that result from imports of these areas - they are difficult to
modify and correct because of the large size. They might be inaccurate when
one compares them to the fine details, but they serve the purpose when
there is no other data available. Honestly, I destroy these polygons when I
encounter them AND I am in the process of correcting the data where they
exist

Ensuring the data remains available to these handful of skilled individuals
is a good idea, as is ensuring that the community is consulted with the
data is being imported.

On Mon, Nov 17, 2014 at 7:27 PM, Alan Trick alantr...@gmail.com wrote:

 I don't think the two of you are actually disagreeing at all. Ga Delap
 just said that the past importers of CanVec data were too haphazard and
 that there was not enough community consulting. It seems like the quality
 of the data in Quebec might have been worse than in other places too.

 (Désolé, je ne parle pas francais bien.) Je ne pense pas que vous
 differez. Ga Delap a dit seulment que les ancients importateurs de donne
 CanVec etiez trop négligé est ils n'agissent pas avec la communauté. Il me
 semble aussi que la qualite de donne quebequois est pire que les autres.

 On Mon, Nov 17, 2014 at 2:00 PM, Dan Charrois d...@syz.com wrote:


  On 2014-Nov-17, at 1:53 PM, Ga Delap gade...@gmail.com wrote:
 
  Il y a actuellement un peu de bruit sur talk.ca pour faire renaître les
  importations CanVec.
  Il ne faut pas.
 

 Unfortunately, though I can read French, I can only speak or write
 English properly, but wanted to weigh in on this discussion.

 As someone who has imported a fair bit of Canvec data, I wanted to weigh
 in on this.

 Though Canvec data has some issues involved in importing into OSM that
 people should be aware of, I think that it does far more good than harm if
 treated properly.  All data from Canvec (or any source for that matter)
 should be inspected carefully before importing into OSM - using satellite
 imagery for verification, for instance.  And in particular, any data from
 Canvec that is replacing existing data in OSM should be considered very
 carefully and with a high degree of suspicion, as in most cases (though not
 all), our existing OSM data is superior.

 But with that said, there are a lot of pieces of data from Canvec that we
 don't have in OSM and should be added - more streets, addresses, and forest
 areas, as you mentioned - especially if they're verified by overlaying
 satellite imagery.  I'd add to that list hydrography.  In particular,
 smaller streams and lakes in my part of Canada tend not to exist at all in
 OSM, and adding them from Canvec adds data where there otherwise was none.
 It's usually best to leave the larger lakes and rivers that already exist
 alone, though perhaps adding a bit more detail to their shorelines.

 In my experience, probably about 90% of the data in Canvec (particularly
 non man-made features) that is not already in OSM may be worth importing.
 And similarly, about 90% of the data that is common between the two is best
 left alone.

 Some areas of the map in more remote areas don't have any data at all in
 OSM - in those cases, importing Canvec data particularly adds a huge amount
 of value.  In places like downtown Toronto, probably not so much.  I think
 Canvec data is very valuable for OSM and very strongly support its
 continued importation, under the condition that whomever is doing it knows
 some of the issues as you pointed out to ensure they are always making
 things better instead of worse.

 Dan
 ---
 Dan Charrois
 President, Syzygy Research  Technology
 Phone: 780-961-2213


 ___
 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

[Talk-ca] Question on CANVEC

[Adam Martin]

Hey all,

I have a quick question on data that has been imported from CANVEC. I have
been doing some work on the North-West side of Thunder Bay in Ontario. Part
of that has been attempting to revamp the land use designations there. At
the moment, the use has been entered via CANVEC import, but a review
comparing that data to the actual land underneath from the Satellite shows
fairly large variances. As well, the Wood polygon itself is oddly shaped,
with squared lines denoting where it two CANVEC products were imported side
by side.

Large multi-polygon areas like these are impossible to edit in ID and still
difficult in JOSM. So my question is this - if I am editing the area, what
is the perception on deleting the main Wood polygon altogether and
re-creating it? My intent would be to increase the accuracy of the map in
the area based on the satellite data provided by Bing and this would be
easier if the land use were cleared and re-built. I would leave the
features that CANVEC imported - only the land use would be re-constructed
in that case. The other components would simply be moved and edited as
needed.

Thanks,

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

Re: [Talk-ca] Question on CANVEC

[Adam Martin]

I agree, Harald. There are lots of things that the CANVEC adds that's
perfectly fine, if somewhat off position. Easier to edit those into
position than to try to create them whole-cloth.


On Tue, Jul 22, 2014 at 2:27 PM, Harald Kliems kli...@gmail.com wrote:

 Just to clarify, I was only talking specifically about the landuse data.
 Much of Canvec is great!

 Harald.
 On Jul 22, 2014 10:21 AM, Andrew andrew.alli...@teksavvy.com wrote:

 I agree, that the large polygons, are a pain. I would second the
 idea
 of deleting and recreating the wooded areas from imagery. I don't think
 I would go so far to say all of the canvec imported data is bad. i.e.
 Lakes, rivers, roads, address data, train tracks, etc.

 I must from the camp where the goal is to improve the quality of
 the
 map even if it is from an incremental point. (i.e. no data to some data)
 or I guess (no data to PIA data? :-)


 Andrew
 aka CanvecImports.
 aka I guess, one of the offenders :-)


 On Tue, 2014-07-22 at 09:25 -0500, Harald Kliems wrote:
  Just delete and recreate. There have been several discussions on this
  list about the data quality of the landuse data and if it should've
  been imported in the first place (no data vs. bad data). Working with
  gigantic multipolygons is indeed a pain and I don't think there is any
  value to preserving the import data.
 
 
  Just my two cents,
   Harald.
 
 
  On Tue, Jul 22, 2014 at 8:36 AM, Adam Martin s.adam.mar...@gmail.com
  wrote:
  Hey all,
 
 
  I have a quick question on data that has been imported from
  CANVEC. I have been doing some work on the North-West side of
  Thunder Bay in Ontario. Part of that has been attempting to
  revamp the land use designations there. At the moment, the use
  has been entered via CANVEC import, but a review comparing
  that data to the actual land underneath from the Satellite
  shows fairly large variances. As well, the Wood polygon
  itself is oddly shaped, with squared lines denoting where it
  two CANVEC products were imported side by side.
 
 
  Large multi-polygon areas like these are impossible to edit in
  ID and still difficult in JOSM. So my question is this - if I
  am editing the area, what is the perception on deleting the
  main Wood polygon altogether and re-creating it? My intent
  would be to increase the accuracy of the map in the area based
  on the satellite data provided by Bing and this would be
  easier if the land use were cleared and re-built. I would
  leave the features that CANVEC imported - only the land use
  would be re-constructed in that case. The other components
  would simply be moved and edited as needed.
 
 
  Thanks,
 
 
  Adam
 
 
  ___
  Talk-ca mailing list
  Talk-ca@openstreetmap.org
  https://lists.openstreetmap.org/listinfo/talk-ca
 
 
 
 
 
  --
  Please use encrypted communication whenever possible!
  Key-ID: 0x34cb93972f186565
  ___
  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] coastline between Montreal and Sorel, Quebec

[Adam Martin]

Charles,

I took a look at the area that you describe and I see what you mean - the
coastline designation disappears around Sorel and reappears just past
Montreal. Looking in the area of the gap, the use of Coastline appears to
suddenly switch to Water and Riverbank. The source of the information
also switches, from the NRCAN database to Bing.

I am not aware of a discussion that flagged this area to be left as-is on
the map. I am also not sure why someone would be protecting the area from
corrections / changes.

However, I believe I can see where the confusion came from (at least
partially). For reference, this is the St. Lawrence River, an enormous
waterway that drains the Great Lakes into the North Atlantic. A river of
this size generally cannot be described accurately with a single line in
the centre of the waterway as it eliminates a vital level of detail of the
surrounding area. So the St. Lawrence needs to be detailed as a water
polygon in order to preserve the shoreline. The problem here is that there
seems to be some confusion as to what sort of shoreline this represents -
coastline or riverbank. The answer to that is rather complex - where
exactly does the St. Lawrence River stop being a river and become part of
the eastern coast of Canada? The switch between descriptions here appears
to be part of someones attempt to correct the designation of the
shoreline in the river for an area that they consider to be part of the
River that is the St. Lawrence (as opposed to the coastline that the
river drains into).

I think the question here is the same - where does the St. Lawrence stop
being a river and start being a part of the coastline?

Adam


On Wed, Apr 2, 2014 at 10:10 PM, Charles Basenga Kiyanda 
perso...@charleskiyanda.com wrote:

 Anybody know why the coastline stops about midway along the Montreal
 Island (and also Ile Jésus) and then starts again around Sorel? I got one
 report from someone who tried to fix this and was quickly reverted. Should
 it be fixed at some point and it's just such a large undertaking that
 nobody is willing to do it yet or was there a discussion and subsequent
 consensus to adopt the current state of the coastline?

 Thanks,

 Charles

 ___
 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] coastline between Montreal and Sorel, Quebec

[Adam Martin]

Agreed. The fact of the matter is that, whatever the best means to map the
area is, the current situation is not the best and whomever is reverting
attempts at correcting it needs to be contacted.

Adam


On Thu, Apr 3, 2014 at 12:26 PM, Andrew Lester a-les...@shaw.ca wrote:

 Why not tag it as both? The surrounding ways are already tagged with both.
 ...or tag the ways as coastline and make one or more relations to mark the
 riverbank area. Whatever happens, having the coastline end for this short
 stretch does seem wrong, and if someone is reverting changes there, someone
 needs to contact them and find out their reasons.

 Andrew
 alester
 Victoria, BC

 Sent from my iPhone

 On Apr 3, 2014, at 7:40 AM, Adam Martin s.adam.mar...@gmail.com wrote:

 Charles,

 I took a look at the area that you describe and I see what you mean - the
 coastline designation disappears around Sorel and reappears just past
 Montreal. Looking in the area of the gap, the use of Coastline appears to
 suddenly switch to Water and Riverbank. The source of the information
 also switches, from the NRCAN database to Bing.

 I am not aware of a discussion that flagged this area to be left as-is
 on the map. I am also not sure why someone would be protecting the area
 from corrections / changes.

 However, I believe I can see where the confusion came from (at least
 partially). For reference, this is the St. Lawrence River, an enormous
 waterway that drains the Great Lakes into the North Atlantic. A river of
 this size generally cannot be described accurately with a single line in
 the centre of the waterway as it eliminates a vital level of detail of the
 surrounding area. So the St. Lawrence needs to be detailed as a water
 polygon in order to preserve the shoreline. The problem here is that there
 seems to be some confusion as to what sort of shoreline this represents -
 coastline or riverbank. The answer to that is rather complex - where
 exactly does the St. Lawrence River stop being a river and become part of
 the eastern coast of Canada? The switch between descriptions here appears
 to be part of someones attempt to correct the designation of the
 shoreline in the river for an area that they consider to be part of the
 River that is the St. Lawrence (as opposed to the coastline that the
 river drains into).

 I think the question here is the same - where does the St. Lawrence stop
 being a river and start being a part of the coastline?

 Adam


 On Wed, Apr 2, 2014 at 10:10 PM, Charles Basenga Kiyanda 
 perso...@charleskiyanda.com wrote:

 Anybody know why the coastline stops about midway along the Montreal
 Island (and also Ile Jésus) and then starts again around Sorel? I got one
 report from someone who tried to fix this and was quickly reverted. Should
 it be fixed at some point and it's just such a large undertaking that
 nobody is willing to do it yet or was there a discussion and subsequent
 consensus to adopt the current state of the coastline?

 Thanks,

 Charles

 ___
 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] Nunavut has a very pour data coverage. Why not Integrate BNDT/CanVec dataset from Department of Natural Resources Canada?

[Adam Martin]

The CanVec data comes in layers, so it is definitely possible to import
only particular sections of the data, such as the roads.

CanVec makes a good base to work off of. One of the seasoned importers can
do the work and us regular users can adjust it for the underlying satellite
data. I'd help with that part myself - always willing to lend a hand.

Adam
On Mar 27, 2014 11:42 PM, i...@gmx.com wrote:

 Would it be possible to only import the tundra parts? There are no wood
 areas. Or just Ellesmere island? There are just lakes and tundra.



 Ivolino







 *Von:* Adam Martin [mailto:s.adam.mar...@gmail.com]
 *Gesendet:* Freitag, 28. März 2014 01:28
 *An:* i...@gmx.com
 *Cc:* talk-ca@openstreetmap.org
 *Betreff:* Re: [Talk-ca] Nunavut has a very pour data coverage. Why not
 Integrate BNDT/CanVec dataset from Department of Natural Resources Canada?



 I can see the point here - better to have something than nothing. Still,
 my tendency would be to opt for a mapping project like the ones performed
 on other areas rather than a mass import. Imported data needs to be treated
 with kid gloves as it is easy to end up with faulty information. Wood areas
 tend to come in in a very haphazard way, for example.

 Put out the call - I know there must be several willing to help out up
 there.

 Adam

 Hi all.



 Nunavut has a very pour data coverage, almost nothing. Why not integrate
 the BNDT (or NTDB) dataset from Department of Natural Resources Canada?



 ftp://ftp2.cits.rncan.gc.ca/pub/bndt/



 I use the map data with the Ibycus Topo Canada v4 map for Garmin and they
 are very good. I think the data are now proceed from CanVec should be
 available for import in OSM.



 http://wiki.openstreetmap.org/wiki/Canvec



 I would be very happy to have the topography maps from Nunavut but I am
 afraid I am not experienced enough to import the data. Because there is
 almost nothing so far you can't do too much wrongJ.



 Greetings ivolino




 ___
 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] Nunavut has a very pour data coverage. Why not Integrate BNDT/CanVec dataset from Department of Natural Resources Canada?

[Adam Martin]

I can see the point here - better to have something than nothing. Still, my
tendency would be to opt for a mapping project like the ones performed on
other areas rather than a mass import. Imported data needs to be treated
with kid gloves as it is easy to end up with faulty information. Wood areas
tend to come in in a very haphazard way, for example.

Put out the call - I know there must be several willing to help out up
there.

Adam

Hi all.



Nunavut has a very pour data coverage, almost nothing. Why not integrate
the BNDT (or NTDB) dataset from Department of Natural Resources Canada?



ftp://ftp2.cits.rncan.gc.ca/pub/bndt/



I use the map data with the Ibycus Topo Canada v4 map for Garmin and they
are very good. I think the data are now proceed from CanVec should be
available for import in OSM.



http://wiki.openstreetmap.org/wiki/Canvec



I would be very happy to have the topography maps from Nunavut but I am
afraid I am not experienced enough to import the data. Because there is
almost nothing so far you can't do too much wrongJ.



Greetings ivolino



___
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] Telecommunications Buildings

[Adam Martin]

Hey all,

Quick question regarding tagging buildings. I've come across several that
are owned and maintained by a local telecom company. These are buildings,
usually located in residential areas, look somewhat like houses, but are
there to provide switching and distribution of communications equipment
(telephone, Internet, etc). What should these be tagged as? My assumption
would be building = yes and a Works = tag. Thoughts?

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

Re: [Talk-ca] GNS tag cleanup

[Adam Martin]

Hey all,

Figured I look, for the codes mentioned on the GNS site and save others the
trouble.

ADM 1 Codes
First-order administrative division. An administrative area directly
subordinate to the pertinent governing authority.

CC1
Country code. CA being Canada.

DSG
Feature designation code. Comprised of two to six character code to
identify what type of feature this is. In this case, PPL means Populated
Place.

FC
Feature Classification. Designed to allow similar features in GNS to be
grouped together and searched for.

JOG
Joint Operations Graphic Reference. This is a specification determined by
the US Department if Defense to ensure that graphical representations of
the feature (maps) treat the item in the same manner.

MGRS
An alpha-numeric system of expressing UTM/UPS coordinates.

UFI
Unique Feature Identifier

UNI
Unique Name Identifier

RC
Region Font Code. FOr determining the equivalent characters used in GNS
sorts rendered in Roman Script. 1 means Americas and Western Europe.

n:xx:NT=N
NT is the Name Type and N means Approved.

The rest mentioned are self-explanatory. Very few of these codes appear to
hold any meaning for the OSM database as it sorts the data based on it's
own tagging references. As such, they should probably all or almost all be
removed from OSM.

Oops. Meant to send this to everyone.

Adam


On Fri, Feb 14, 2014 at 6:09 AM, stegg...@steggink.org wrote:

 Hi Paul,

 gns:jog refers to the sheet number of the Joint Operations Graphics map
 series.
 gns:mgrs refers to the Military Grid Reference System, which is nothing
 more than an alternate representation of the coordinate system

 IMO both these values can be safely removed.

 I don't know about the other ones. Perhaps you can find more information
 here: http://earth-info.nga.mil/gns/html/

 Regards,

 Frank


 Quoting Paul Norman penor...@mac.com:

  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




 ___
 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] GPS and Motorway links ...

[Adam Martin]

Thanks Harald. Especially for the corrections in Newfoundland - we don't
have many of them but they're there.
On Jan 16, 2014 7:00 PM, Harald Kliems kli...@gmail.com wrote:

 I am happy to report that all of Canada should now be free of this issue!
 I just fixed the last one all the way west in Saint John's. Yay!

  Harald.


 On Sun, Jan 12, 2014 at 6:03 PM, Harald Kliems kli...@gmail.com wrote:

 Some updates on this issue:

 I contacted Martijn a while ago with the suggestion of running this as a
 Maproulette. He liked the idea but I haven't heard back in a while. He also
 asked me how many cases we're talking about and based on the Overpass query
 mentioned upthread I came to the conclusion that the number is actually not
 that high (maybe 400 cases in all of Canada at the most). Therefore I've
 started fixing the issue manually and already cleaned up all of Quebec. It
 took me several hours, but that's partly because you always discover other
 issues to take care of as you go along (e.g. missing motorway_junction,
 name vs. exit_to on those junctions etc.).

 I'll continue working on this in Ontario now and I encourage others to go
 ahead in the other provinces, too. Just run
 http://overpass-turbo.eu/s/1CI on the appropriate bounding box and then
 go through each of the spots that come up. If there is hi-res Bing imagery
 available the fix will be obvious; and if not common sense should still
 tell you if a segment is oneway=yes or oneway=no. I have added a oneway tag
 to every motorway_link segment, both to avoid any misunderstanding with the
 default and to allow me to track the progress on the Overpass map.

 Cheers,
  Harald.


 On Wed, Nov 27, 2013 at 11:04 AM, Harald Kliems kli...@gmail.com wrote:

 So before contacting Martijn I want to be sure that we can properly
 identify the potentially problematic ways. What we are looking for are ways
 that match the following query:

 (highway=motorway_link) AND (NOT oneway=*) AND (lanes!=1)

 Or in natural language: ways that are motorway links but don't have the
 oneway tag nor are tagged as having one lane. If you want to test this
 query, go to this link http://overpass-turbo.eu/s/1CI and adjust the
 bounding box coordinates for the desired area.

 Comments?

  Harald.


 On Tue, Nov 26, 2013 at 10:25 AM, Daniel Begin jfd...@hotmail.comwrote:

 The example I provided yesterday was not fixed.  Most the exits having
 a similar look along the trans-Canada Highway in Quebec are the same. I
 have also found examples in Alberta and In BC.



 Daniel



 *From:* Harald Kliems [mailto:kli...@gmail.com]
 *Sent:* November-26-13 10:04
 *To:* Daniel Begin
 *Cc:* Connors, Bernie (SNB); Talk-CA OpenStreetMap

 *Subject:* Re: [Talk-ca] GPS and Motorway links ...



 I can write an email to Martijn with a proposal. Does anyone have a
 link to an exit that has not been fixed yet to use as an example?



  Harald.



 On Tue, Nov 26, 2013 at 9:53 AM, Daniel Begin jfd...@hotmail.com
 wrote:

 It seems to me it is the only safe solution. I go for maproulette.org

 Daniel



 *From:* Connors, Bernie (SNB) [mailto:bernie.conn...@snb.ca]
 *Sent:* November-26-13 08:19
 *To:* 'Harald Kliems'; Daniel Begin
 *Cc:* Talk-CA OpenStreetMap
 *Subject:* RE: [Talk-ca] GPS and Motorway links ...



 +1 for the Maproulette.org solution.



 Bernie.

 --

 Bernie Connors, P.Eng

 Tel: 506-444-2077

 bernie.conn...@snb.ca

 *SNB – We make it happen…*

 [image: SAG_Logo_2013]



 *From:* Harald Kliems [mailto:kli...@gmail.com kli...@gmail.com]
 *Sent:* Monday, 2013-11-25 5:05 PM
 *To:* Daniel Begin
 *Cc:* Talk-CA OpenStreetMap
 *Subject:* Re: [Talk-ca] GPS and Motorway links ...







 On Mon, Nov 25, 2013 at 3:35 PM, Daniel Begin jfd...@hotmail.com
 wrote:

 Hooo, I see, and I also see there was not a large consensus on that
 point (Discussion) since all other ways are having a different behavior…



 About all motorway_link in Canada are having the same problem!

 I don't know, I rarely encounter this issue in practice. Adding
 oneway=no to all motorway_link seems rather dangerous and
 counterproductive. The best solution would probably be to create a query
 that will find all imported motorway_link that have not been touched since
 the import and then check them. Depending on how big the task is we could
 ask Martijn to set it up as a Maproulette (http://maproulette.org/).
 Or we set up a wiki page to coordinate people going through all the
 motorways/exits and make sure everything is okay by hand. There are only 33
 Autoroutes in Quebec after all :-)



  Harald.







 --
 Please use encrypted communication whenever possible!
 Key-ID: 0x34cb93972f186565




 --
 Please use encrypted communication whenever possible!
 Key-ID: 0x34cb93972f186565




 --
 Please use encrypted communication whenever possible!
 Key-ID: 0x34cb93972f186565




 --
 Please use encrypted communication whenever possible!
 Key-ID: 0x34cb93972f186565

 ___
 Talk-ca 

[Talk-ca] Maritime Boundary

[Adam Martin]

Hello!

I have a question regarding the maritime boundary of Canada, specifically
Newfoundland and Labrador. National maritime boundaries generally use the
12 nautical mile limit, unless otherwise specified. I see the boundary for
the province (http://www.openstreetmap.org/#map=7/48.283/-53.196) which is
auto-generated by a bot. That seems fine, but there is another maritime
boundary for the Province. However, this one does not appear to be correct.
Take a look at this example -
http://www.openstreetmap.org/#map=14/47.7920/-52.7985. As you can see, the
dashed line represents the boundary - in ID, it is noted as the maritime
boundary. But that does not make sense - the line crosses the landmass, for
one thing. It is also very poorly shaped.

Is this supposed to be the actual maritime boundary? I don't think it is -
the parts of the line appears to be for the Provincial boundary. If it is
the Provincial boundary, shouldn't it follow the coastal boundary?

If I am mistaken, let me know.

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

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

[Adam Martin]

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

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

[Adam Martin]

Good point. I've seen the discussion relating to the use of the forest
landuse tag and the wood natural tag. It does just boil down to the mappers
preference. My answer was based on my use ... there are no wrong answers,
of course.
On Jan 10, 2014 8:26 PM, Paul Norman penor...@mac.com wrote:

 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

Re: [Talk-ca] Pourquoi les imports doivent être régis

[Adam Martin]

Darren,

I'd also like to hear what the consensus is on this point. Generally, a GPS
trace is optimal, but not always possible. Personally, I find that tracing
the satellite imagery tends to provide a good result. I've performed some
localized tests to ensure that these traced roads are comparable to GPS
data and the results have been positive.

More on the topic of whether to use the Canvec data or not - I live in
Paradise in Newfoundland (
http://www.openstreetmap.org/#map=13/47.5340/-52.8825) and have been
contributing to the map as a hobby. Other users imported the Canvec data
for the area which has provided a good stepping stone for my work. I've
adjusted the shape of the roads to align them to the surroundings and added
the land use designations in the area. The user(s) that imported the data
wisely chose to exclude the land designations and take only the network,
lakes, rivers and special features (names of bays or mounts). Buildings
were not imported nor any other fine detail like that.

In my opinion, it's worked well in that way. The importer seemed to know
what they were doing and picked the through the Canvec data carefully.
Looking in some other areas, I noticed errors in the Canvec data - even
with the simple Wood areas. The polygons are inaccurate and oddly shaped,
with sharp borders resulting from the use of the Canvec Tiles. Some areas
have road networks composed of dozens of isolated segments as was mentioned
- one of these I painstakingly corrected by deleting and redrawing the
roads in that area (Meadow Lake in Saskatchewan for those interested -
http://www.openstreetmap.org/#map=14/54.1255/-108.4490).

In all, use of importation for the data should be allowed, but controlled.
Those that do it need to be skilled at the process and mindful of the
errors in the data. Above all else, they should respect the work of the
other mappers in that area. I'd hate to have the work I've done so far to
be haphazardly erased because someone wanted to import (and then abandon) a
pile of data over those areas. Maybe we just need to be more involved in
the imports. This is a community so why not make such importation a
community decision. No lone guns as it were - if you want to import, you
pass it by the rest of us. No objections = go ahead. Do it without
mentioning it to the group and the change is considered unintentional
vandalism and erased.

Just a thought.

Adam


2014/1/7 Darren Wiebe dar...@aleph-com.net

 I'd like the communities input.  I work in Lloydminster, AB (
 http://www.openstreetmap.org/#map=9/53.4594/-109.4980) and we're using
 OpenStreetMap in my job to provide mapping to our service trucks and
 provide customer locations, etc.  Over the last year and a half I've been
 working on expanding the OpenStreetMap coverage in my area.  Some of this
 has come from roads I've personally driven on but much of it in
 Saskatchewan has come from Canvec.  I'm picking away at keepright in the
 area as well.  I don't want to load a lot of junk into the map but the
 canvec roads are very close and with roads the map is of no use.

 Should I be importing just the roads or is there a better data source?  Or
 what other option am I missing?

 Darren Wiebe



 2014/1/7 Pierre Béland pierz...@yahoo.fr

 OpenStreetMap est un projet collaboratif. Il y a un côté social qui peut
 vraiment ajouter au plaisir de cartographier.  Par contre, si chacun
 travaille de son côté sans coordination, si les nouveaux ne sont pas
 minimalement encadrés, nous devons nous attendre à toutes sortes de
 problèmes.

 Pour progresser et développer une meilleure carte, nous devons avoir
 réussir à constituer une communauté davantage organisée, qui identifie les
 problèmes de façon plus systématique, qui trouve des outils pour les
 régler, qui assure un minimum de suivi des contributeurs.  Il faut avoir du
 plaisir à travailler ensemble.  Regardez comment nous réussissons à
 stimuler les contributeurs et réaliser des projets tels que pour le typhon
 Haiyan aux Philippines.  Il serait intéressant de faire de même pour la
 communauté du Québec, de se donner des objectifs et travailler tous
 ensemble à les réaliser.

 La communauté OSM-france a développé des procédures pour l'import de
 données et fait un suivi beaucoup plus systématique que nous. Ils ont aussi
 développé l'outil Osmose pour la validation / correction des erreurs. Nous
 avons obtenu que le Québec soit couvert par cet outil. Il faudrait
 davantage s'en servir. Les polygones en double y sont notamment couverts.

 L'exemple suivant montre un polygone de lac importé en 2009 à partir de
 Canvec. Le même contributeur a créé un doublon en 2011. Dans ce cas-ci ce
 n'est pas l'import canvec qui est à blamer et c'est le même contributeur
 réussit à créer un tel doublon et sans y ajouter d'attributs.
 voir
 http://osmose.openstreetmap.fr/fr/map/?zoom=16lat=46.65962lon=-76.09482layers=B00FFTitem=level=1,2,3

 L'outil Osmose permet également à un 

Re: [Talk-ca] OSM New-York - Import de contours de batiments et adresses

[Adam Martin]

The effort behind OSM in terms of the map is to obtain, enter and maintain
accurate and up-to-date data. Any effort to create a community is ours as
the Canadian users of the editing tools.

As such, the assertion that importing should be discouraged is one for the
benefit of the map and not the community. Since the map is our primary
concern, it seems reasonable to seek to limit this activity to those that
have been proven to be skilled in the process. New users could be
encouraged to use the sandbox to gain these skills.

Adam
On Jan 6, 2014 2:45 PM, Pierre Béland pierz...@yahoo.fr wrote:

 Richard

 we are trying to build a community, to work with various governments to
 provide some data.

 At the same time, we should bring a minimum of nuances in discussing in
 subjects like the imports.

 Yes there are mappers that make errors, and yes we should help them to do
 better, we should take care to have good guidelines, good follow-up.

 And this not only for imports. The same with field surveys and Aerial
 imagery.  If you use a GPS to locate a store, there is good chance that you
 will not place a commerce at the right place and even place it on the wrong
 side of the street.  And if you trace from Imagery in sandy areas dozens of
 paths going in all directions, this is not meaningful.

 It is very difficult to discuss, when somebody comes with such a radical
 position as you present every time we discuss of imports.

 Let's hope that we can have  more constructive ways to discuss on this
 list in 2014.


 Pierre

   --
  *De :* Richard Weait rich...@weait.com
 *À :* Pierre Béland pierz...@yahoo.fr
 *Cc :* Talk- CA Open Street Map talk-ca@openstreetmap.org; 
 diane.merc...@gmail.com diane.merc...@gmail.com
 *Envoyé le :* Lundi 6 janvier 2014 12h49
 *Objet :* Re: [Talk-ca] OSM New-York - Import de contours de batiments et
 adresses

 On Mon, Jan 6, 2014 at 8:58 AM, Pierre Béland pierz...@yahoo.fr wrote:
  Richard
 
  I dont think that we should advocate against import.

 Then we differ.

 I've been advocating for better imports with every import I've seen
 since 2006.  While the tools have improved, the results for the most
 part, just haven't.

   Let's try in 2014 to
  be more positive with that and suggest ways to do it better.

 You might continue to believe that imports are just fine, I do not.
 Imports are harmfull to OpenStreetMap and to the OpenStreetMap
 community in all except extremely limited circumstances.

 Invariably, when I add that except in extremely limited
 circumstances, the listener will presume that they are in fact the
 exception.

 Invariably, they aren't the exception.

 They are well intentioned.  They are in love with data.  They want a
 better OpenStreetMap.  And then they make an import of some sort and
 cause harm to the data base and community that they then never clean
 up because it is too much work.

 The linked thread regarding the NYC building import discusses ways to

 do it better.


 The after action report on any decent effort at an import has
 discussed ways to do better in the future.  Technically, essentially
 every import has been better than the one before.  To date,
 overwhelmingly, better is still just not good enough.

 My recommendation is never to import.  Import should be a very dirty
 word in OpenStreetMap.

 By comparison, I think we should focus on doing the best mapping that
 we can with our surveys, and with external resources that we have
 permission to use.  Use external resources* by comparing each item
 with all of the other existing resources, including imagery, existing
 OpenStreetMap data, your survey, local knowledge, and curate the
 external source before placing it into OpenStreetMap.

 But never import.**

 Yes. It's way slower.  Yes, it takes more time, and a more-experienced
 mapper.  But it is what you owe to the project, the community and to
 your reputation as a mapper.

 To be clear, I love that external resources are becoming available to
 OpenStreetMap in greater numbers.  I have every bit as much data
 love for a new data set as the next mapper.  Dumping huge amounts of
 un-curated data into the OpenStreetMap data base at one time is not
 the way to use that data, or OpenStreetMap to best effect.

 * Only the ones for which we have explicit permission to use.
 ** except in those extremely limited circumstances which don't apply here.


 ___
 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] Floating Island Error

[Adam Martin]

Based on an earlier discussion on the OSM Canada board, I've been trying to
figure out what is the best way of correcting the floating island error
that has been plaguing the Province of Newfoundland and Labrador.

Specifically, the error occurs from two directions. The first is localized
on the Cape Breton island area of Nova Scotia (for example,
http://keepright.ipax.at/report_map.php?schema=104error=25004109) and the
other is located along the northern coast of Quebec (for example,
http://keepright.ipax.at/report_map.php?schema=20error=5357196).

From the prior discussion, I decided to wait a couple of weeks in order to
ensure that the floating island errors were real and not some sort of
processing error. The problem has proved to be persistent. From reviewing
the areas in ID and Potlach 2, they seem to relate somehow to the
importation of CanVec v6.0 data into the map. In each case, the line
separating the connected from the disconnected is an arbitrary one
represented by a polygon area designated as wood.

Interestingly, the error is ignored in the navigation application I tried.
Inverness routes south to Port Hawkesbury without any problems. This points
to the issue being on Keeprights side and not the actual map. If that is
the case, then there is little problem, other than that keepright cannot be
relied upon to identify floating island within Newfoundland, Labrador, part
of Quebec and part of Nova Scotia. I'm not sure if potentially rolling back
the imports would make a difference. In that case, I would ask a more
seasoned mapper with experience with reversions and imports to actually
perform such a thing.

Let me know what you think.

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

[Talk-ca] Keep Right Error

[Adam Martin]

Hello all,

This is my first to this list and I have a question regarding a particular
keep right error I keep seeing for the island portion of Newfoundland and
Labrador. All roads within the Province are flagged as being Floating
Islands, indicating that there is some sort of gap or break in the
connection to the mainland. I traced the roads backwards across the
province and it did not seem to be sourced on the Island itself. So I
travelled the length of the ferry line to Nova Scotia and checked the Cape
Breton Island area. Apparently, the error begins there, which causes the
entire island of Newfoundland to show as being unconnected.

However, I am having trouble localizing the error on Cape Breton. There are
several places that it seems to trace to, but none that I have investigated
so far appear to actually have disconnections occurring. These roads are
all imports of the CANVEC data which is known to have some inaccuracies,
but that is different from this error. I think it might be that the import
failed in some manner and caused an error
 in the connections that keep right has a problem with. Anyone else here
have any knowledge of what might have happened?

Thanks,

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

Re: [Talk-ca] Keep Right Error

[Adam Martin]

Pierre,

I scanned the entire length of the ferry route itself and the connections
at both sides. Everything seems to be fine.

Adam
On 2013-11-25 3:28 PM, Pierre Béland pierz...@yahoo.fr wrote:

 Look if connecting the ferry roads to the mainland and newfoundland roads
 will fix this.


 Pierre

   --
  *De :* Adam Martin s.adam.mar...@gmail.com
 *À :* talk-ca@openstreetmap.org
 *Envoyé le :* Lundi 25 novembre 2013 18h48
 *Objet :* [Talk-ca] Keep Right Error

 Hello all,

 This is my first to this list and I have a question regarding a particular
 keep right error I keep seeing for the island portion of Newfoundland and
 Labrador. All roads within the Province are flagged as being Floating
 Islands, indicating that there is some sort of gap or break in the
 connection to the mainland. I traced the roads backwards across the
 province and it did not seem to be sourced on the Island itself. So I
 travelled the length of the ferry line to Nova Scotia and checked the Cape
 Breton Island area. Apparently, the error begins there, which causes the
 entire island of Newfoundland to show as being unconnected.

 However, I am having trouble localizing the error on Cape Breton. There
 are several places that it seems to trace to, but none that I have
 investigated so far appear to actually have disconnections occurring. These
 roads are all imports of the CANVEC data which is known to have some
 inaccuracies, but that is different from this error. I think it might be
 that the import failed in some manner and caused an error
  in the connections that keep right has a problem with. Anyone else here
 have any knowledge of what might have happened?

 Thanks,

 Adam

 ___
 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