Re: [Talk-ca] Cycling map vs Standard map

[Daniel Begin]

M…

Les cartes proposées ne semblent pas mises-à-jour de façon quotidienne (des 
ajouts de tronçons cyclables que j’ai fait il y a plus d’une semaine n’y 
apparaissent encore).

 

Merci néanmoins pour ce lien très utile!

Daniel

 

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: November-04-15 02:15
To: john whelan; Pierre Boucher
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Cycling map vs Standard map

 

Bonjour Pierre

 

Cette carte est produite par Andy Allen. voir 
http://wiki.openstreetmap.org/wiki/OpenCycleMap On y indique que le rendu pour 
la carte cycliste est mis à jour moins fréquemment.  La carte Lonvia's Cycling 
Map   de Sarah Hoffman 
  
http://cycling.waymarkedtrails.org/fr/est mise-à-jour à chaque jour.  A voir si 
elle répond à tes besoins.

 

 
Pierre 



 

  _  

De : john whelan 
À : Pierre Boucher  
Cc : Talk-CA OpenStreetMap  
Envoyé le : Mardi 3 novembre 2015 18h01
Objet : Re: [Talk-ca] Cycling map vs Standard map

 

 

You can always download the area and render it locally with Maperitive or 
OSMAND.

Cheerio John

 

On 3 November 2015 at 11:06, Pierre Boucher  wrote:



 

Hi,
Can someone have and explanation (and a solution) to the fact that for the same 
specific area (small area a few square kilometers) the cycling map is not 
update  to the latest tags.  If you compare the Cycling Map to the Standard Map 
for this area you will see what I mean (I hope so) 

http://www.openstreetmap.org/#map=15/45.6271/-73.8443 
 &layers=C

Regards,


Pierre Boucher (Alias Boff 2  on OSM)


___
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

[Daniel Begin]

I think we are evolving to a consensus that makes sense. 

I have received some examples that are quite right in QC context. For those who 
know the area, Route 175 up to Saguenay is obviously a “type 1” trunk road 
while Route 138 northeast from Quebec City isn't.

 

However, I hope everyone concerned will give their “two cents” because the 
context in Manitoba or in Yukon may be (is) quite different, and I do not want 
an "Eastern centric solution" on the subject :-)

 

Best regards,

DanielI 

From: Daniel Begin [mailto:jfd...@hotmail.com] 
Sent: July-24-15 10:09
To: 'Adam Martin'; 'Tristan Anderson'
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Highway recoding

 

“… [TCH] is automatically a trunk route given that it is, at its most basic 
point, the central connection between major settlements …” 

 

Interesting… it is type 2 definition proposed by Tristan but without the 
concept of distance. IMHO, It highlights the fact that, depending on how you 
define central connection, major settlements, or distant population centres, 
you may ends up with the Britain situation – or even worst.  

 

Combining two very different objectives (types 1 and 2) in one definition leads 
to confusion. What about a rationale revolving around Type 1 definition but 
considering the TCH as a “special case” as suggested by Martin?

 

-  OSM road classes mostly aim toward Type 1 definition, so be it for 
trunks;

 

-  Since TCH could be consider as the only highway connecting most 
major population centres across the country, we could agree to tag it whether 
motorway or trunk depending on the infrastructure. There should then be no more 
confusion with this only one exception.

 

However, we could also manage all type 2 definitions, such as the ones 
described in document (a) with relation:route (b) but it is a bit more complex 
and less visual when looking at Mapnik. 

 

Other thoughts, comments?

 

Daniel

 

 

a) http://www.comt.ca/english/NHS-report-english.pdf

b) http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes

 

 

 

From: Adam Martin [mailto:s.adam.mar...@gmail.com] 
Sent: July-24-15 07:08
To: Tristan Anderson
Cc: Daniel Begin; Stewart C. Russell; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Highway recoding

 

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

Re: [Talk-ca] Highway recoding

[Daniel Begin]

“… [TCH] is automatically a trunk route given that it is, at its most basic 
point, the central connection between major settlements …” 

 

Interesting… it is type 2 definition proposed by Tristan but without the 
concept of distance. IMHO, It highlights the fact that, depending on how you 
define central connection, major settlements, or distant population centres, 
you may ends up with the Britain situation – or even worst.  

 

Combining two very different objectives (types 1 and 2) in one definition leads 
to confusion. What about a rationale revolving around Type 1 definition but 
considering the TCH as a “special case” as suggested by Martin?

 

-  OSM road classes mostly aim toward Type 1 definition, so be it for 
trunks;

 

-  Since TCH could be consider as the only highway connecting most 
major population centres across the country, we could agree to tag it whether 
motorway or trunk depending on the infrastructure. There should then be no more 
confusion with this only one exception.

 

However, we could also manage all type 2 definitions, such as the ones 
described in document (a) with relation:route (b) but it is a bit more complex 
and less visual when looking at Mapnik. 

 

Other thoughts, comments?

 

Daniel

 

 

a) http://www.comt.ca/english/NHS-report-english.pdf

b) http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes

 

 

 

From: Adam Martin [mailto:s.adam.mar...@gmail.com] 
Sent: July-24-15 07:08
To: Tristan Anderson
Cc: Daniel Begin; Stewart C. Russell; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Highway recoding

 

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

Re: [Talk-ca] Highway recoding

[Daniel Begin]

Any objections? Of course not!

Your overview of the situation worldwide is pretty exhaustive, and is in
line with most comments, consideration, that were expressed so far.

 

However, as I suggested in an earlier email, I would keep the topic alive
for a couple of weeks, just to make sure everyone that may feel concerned
about the subject have a chance to comment (since it is summer time).

 

Unless there are backlashes from some contributors, I propose to keep
everything as is until the end of august and then move forward to update
definitions and data. 

 

Does everyone comfortable with it?

 

Daniel

From: Tristan Anderson [mailto:andersontris...@hotmail.com] 
Sent: July-23-15 17:18
To: Daniel Begin; 'Stewart C. Russell'; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Highway recoding

 

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
> 
> 
> ___
&g

Re: [Talk-ca] Open Data Imports

[Daniel Begin]

Bonjour Andrew,

Good initiative!
And it will be perfect if you add all necessary links to good 
practices/warnings about imports!-)

I had a look at Canvec+ details (a). 
- The prepackaged files (250K tiles) are going to be quite large since, from 
what I understand, they have merged together all (16) underneath 50K. 
- Custom “areas of interest” might be difficult to manage for data import. 
- Proposed file formats are similar to what it used to be with standard Canvec, 
but it does not include OSM format :-(

About the script(s) used to convert Canvec to OSM, they were built using FME 
workbenches linked together with batch files (so, obviously not open source).

Best regards,
Daniel

a) http://geogratis.gc.ca/site/eng/whats-new/intro-canvec


-Original Message-
From: Andrew MacKinnon [mailto:andrew...@gmail.com] 
Sent: July-23-15 14:04
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Open Data Imports

I am starting to work on importing Open Data datasets. I am using pnorman's 
ogr2osm script with modified translation files (see 
https://github.com/andrewpmk/ogr2osm-translations). It will be some time before 
I actually import anything.

I would like to assemble a list of government open data portals in Canada which 
are compatible with the OSM license. Please add suitable open data sources to 
[https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Open_data]. If they 
have already been fully imported then you should put a note on that wiki page.

Also I am trying to figure out a way to import newer CanVec data. The CanVec 
files in OSM format at 
are out of date and appear to have been created in 2010. Is the script that was 
used to convert CanVec to OSM open source? It looks like there is a new version 
of CanVec called CanVec+, has anyone here used it yet? I am hoping to do 
something about the large amount of broken imported data in OSM in Canada and 
we need a better way of fixing broken CanVec data than copying from the Geobase 
WMS layer or cutting and pasting from outdated .osm files from 2010.

___
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

[Daniel Begin]

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
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Highway recoding

[Daniel Begin]

~~ Un résumé français suit ~~

 

Bonjour all,

 

The few comments we got so far show that most of us, but not all, are 
uncomfortable with the “strategic” approach causing inconsistent descriptions 
of actual road “object” within Canada and between CA/US borders.

 

Since it is summer, I will keep the discussion alive for a while to make sure 
all interested people made their point.  Join the conversation whenever you 
want :-)

 

We are waiting for more comments…

 

Daniel

 

Ps:  comments received off-list will stay off-list – Please join the actual 
conversation J

 

 



En résumé, je questionne la façon d’attribuer le tag ‘trunk’ aux routes 
principales tel que proposé dans un document gouvernemental (a) cité dans le 
wiki (c) et propose de clarifier la  documentation une fois un consensus obtenu.

Les commentaires reçu à date vont pour la plupart (mais pas tous) dans le sens 
qu’une définition de type ‘’stratégique’’ (une route est importante pour 
l’économie d’une région) produit des résultats inconsistants par rapport à la 
perception qu’offre la carte par rapport aux  ‘’infrastructures’’ qui  la 
supporte (les routes ‘’trunk’’ à Toronto, sur la Côte-Nord ou au Yukon sont 
très différentes les unes des autres alors que les autres classes de routes 
sont similaires à la grandeur du pays) – bref la description ‘’physique’’ 
serait plus appropriée.

 

Vos commentaires sont bienvenus

 

a) http://www.comt.ca/english/NHS-report-english.pdf

b) http://wiki.openstreetmap.org/wiki/Highway:International_equivalence

c) http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines

 

 

From: Daniel Begin [mailto:jfd...@hotmail.com] 
Sent: July-22-15 16:44
To: 'Paul Norman'; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Highway recoding

 

Bonjour Paul,

You actually highlight what makes me uncomfortable with the “strategic” 
approach applied in many part of Canada.  You are concerned about the road 
network in BC; I am concerned about the network in QC. Until few months ago, 
there were no trunk here; they are now everywhere.

 

IMO, OSM classification mostly aims at describing the road infrastructures, not 
the strategic/economic importance a local government says about them (almost 
quoted you!-). I understand that Tristan has similar concerns about the 
consequences of such approach in road classification; even if he suggested that 
the current definitions (using strategic approach) are good guidelines (but 
need not be followed religiously).  

 

Other comments on the subject

 

Daniel

 

From: Paul Norman [mailto:penor...@mac.com] 
Sent: July-22-15 15:59
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Highway recoding

 

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

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

More comments would be appreciated 

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

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

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

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

Because it has a lot of freight, it probably will become a NHS road at some 
point. Does its classification magically change when nothing has changed on the 
ground?

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

Re: [Talk-ca] Highway recoding

[Daniel Begin]

Bonjour Paul,

You actually highlight what makes me uncomfortable with the “strategic” 
approach applied in many part of Canada.  You are concerned about the road 
network in BC; I am concerned about the network in QC. Until few months ago, 
there were no trunk here; they are now everywhere.

 

IMO, OSM classification mostly aims at describing the road infrastructures, not 
the strategic/economic importance a local government says about them (almost 
quoted you!-). I understand that Tristan has similar concerns about the 
consequences of such approach in road classification; even if he suggested that 
the current definitions (using strategic approach) are good guidelines (but 
need not be followed religiously).  

 

Other comments on the subject

 

Daniel

 

From: Paul Norman [mailto:penor...@mac.com] 
Sent: July-22-15 15:59
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Highway recoding

 

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



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

More comments would be appreciated 

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

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

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

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

Because it has a lot of freight, it probably will become a NHS road at some 
point. Does its classification magically change when nothing has changed on the 
ground?

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

Re: [Talk-ca] Highway recoding

[Daniel Begin]

Thank Tristan for your suggestions concerning the documentation. 

 

I agree that "there's so much that needs to be added to the map that I don't
see tinkering with highway classifications as a priority". That is why
clarifying definition is necessary since some users are currently tinkering
with trunk/primary tagging. 

 

I am not comfortable with using the "strategic categories" approach for
trunk since it implies we will find very different road types when looking
at them around Toronto or in Yukon, while all lower classes will probably
look very similar wherever you are. Contrarily to JPK, I did not find any
strong relationship between UK "strategic" road classification (e) and OSM
(f). However, the important point is to agree on the definitions and have
them clearly state in the wiki. 

 

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

More comments would be appreciated 

 

Daniel

 

a) http://www.comt.ca/english/NHS-report-english.pdf

e)
https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/31
5783/road-classification-guidance.pdf

f) http://wiki.openstreetmap.org/wiki/Key:highway

 

 

From: Tristan Anderson [mailto:andersontris...@hotmail.com] 
Sent: July-22-15 13:17
To: Daniel Begin; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Highway recoding

 

As I've always understood it, highway=trunk is used for core routes in
document (a) that Daniel mentioned.  It ignores routes marked as feeder and
northern/remote.  highway=primary is for each province's network of primary
highways that aren't motorways or trunks.

 

I don't exactly agree with the above definitions but they were already in
place when I got here so I've been using them.  For one thing, document (a)
was published in 2005, and things change.  I'm also not entirely comfortable
with the fact that the most a city-maintained road could ever hope for is
secondary.  Toronto's Black Creek Drive should, in my mind at least, have a
higher classification than Highway 108 north of Elliot Lake.  In general,
OSM higways should be based on how important they are to the overall road
network, independent of any official classification.

 

On the other hand...  I kinda like the way Canadian cities look with their
simple networks of orange thoroughfares.  London, Paris and Washington are
an incomprehensible mess of roads with varying classifications which don't
seem to be of benefit to the end user.  The eight-level hierarchy of highway
classifications OSM gives us to work with is overkill.  At least Canada is
consistent, which is more than can be said for a lot of countries.  Plus
there's so much that needs to be added to the map that I don't see tinkering
with highway classifications as a priority.

 

So here's what I suggest: the definitions above are good guidelines but need
not be followed religiously.  If anyone thinks a specific road should be
promoted or demoted, let's discuss it here and make it happen.

 

As for the wiki pages.  In (b), Canada is listed twice.  I think the entire
lower row can be deleted and the upper row still stands.  Maybe a note could
be added saying there is some flexibility to the trunk/primary guidelines.

 

In (c), the section on trunk roads should be changed.  Trunk roads do not
need to be limited access.  Most of them are not.  I also don't think people
should be told to tag anything surface=paved/unpaved.  Instead surface
should be whatever it is (asphalt, concrete, gravel, etc).  The
"Sub-national and below" section needs to be rewritten or copied over from
(b).

 

And now you have my two cents too.  Comments?

 

  _  

From: jfd...@hotmail.com
To: talk-ca@openstreetmap.org
Date: Wed, 22 Jul 2015 09:39:28 -0400
Subject: [Talk-ca] Highway recoding

I would like to have community's point of view on this topic.

 

Recently I have seen most primary roads in my area being recoded as trunk by
at least two users.  They both refer to a governmental document (a) to
justify their edits but I disagree with their interpretation. I have asked
them to discuss their interpretation with the OSM community but they did
not; so let's do it

 

I thought there was an agreement on highway tagging scheme in which
provincial primary highway that does not meet freeway standards should be
identified as primary road, as described in Highway:International
equivalence (b). For instance provincial highways 2-14 in Ontario,
100-series highways in Quebec, Highway 95 in BC were initially tagged as
primary road.

 

Since then, the document (a) is used by some contributors to recode primary
roads to trunk because it is cited in the Canadian tagging guideline (c).
IMHO, the problem is that this document (a) defines 3 Route Categories
(Cor

[Talk-ca] Highway recoding

[Daniel Begin]

I would like to have community's point of view on this topic.

 

Recently I have seen most primary roads in my area being recoded as trunk by
at least two users.  They both refer to a governmental document (a) to
justify their edits but I disagree with their interpretation. I have asked
them to discuss their interpretation with the OSM community but they did
not; so let's do it

 

I thought there was an agreement on highway tagging scheme in which
provincial primary highway that does not meet freeway standards should be
identified as primary road, as described in Highway:International
equivalence (b). For instance provincial highways 2-14 in Ontario,
100-series highways in Quebec, Highway 95 in BC were initially tagged as
primary road.

 

Since then, the document (a) is used by some contributors to recode primary
roads to trunk because it is cited in the Canadian tagging guideline (c).
IMHO, the problem is that this document (a) defines 3 Route Categories
(Core, Feeder, Northern and Remote) that does not fit with OSM highway
definitions. 

 

I prefer looking at OSM highway as "infrastructure categories" -my
understanding of OSM definitions- rather than as "strategic categories" as
described in (a) and partially promoted in (c). However, both are of
interest as long they are applied consistently (d).

 

I would like to get a consensus from the Canadian community on trunk/primary
roads tagging scheme and eventually clarify available documentation (b, c)
accordingly.  I might also add Tristan Anderson definitions on forestry
roads (talk-ca 15-07-15).

 

Comments are obviously welcome J

 

Daniel

 

 

a) http://www.comt.ca/english/NHS-report-english.pdf

b) http://wiki.openstreetmap.org/wiki/Highway:International_equivalence

c) http://wiki.openstreetmap.org/wiki/Canadian_tagging_guidelines

d) The Canadian tagging guideline defines trunk as a roadway that has
limited access; while OSM Features (wiki) defines trunk as "high performance
roads that don't meet the requirement for motorway" which means there is
no/little access limitations!  

 

 

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

Re: [Talk-ca] Low quality unresolvable notes

[Daniel Begin]

I understand (and agree) from this thread that...
We only keep notes that can be used to fix something later and drop the rest.

It is the rule I will apply from now on.
Daniel

-Original Message-
From: Paul Norman [mailto:penor...@mac.com] 
Sent: July-06-15 20:33
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Low quality unresolvable notes

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

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

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

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

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


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

Re: [Talk-ca] Ref tags in Ontario

[Daniel Begin]

AFAIK, it has never been discussed at least on this forum. I consider it as
an error or even vandalism since it does not conform to acceptable rules (1)

 

A similar behavior has been seen a couple of months ago where
user:OntarioEditor added a prefix to ref tag for most primary/secondary
roads in Quebec. I contacted him but never had an answer. The question was
asked on this list by another user about such behavior. Unfortunately, I did
not see any specific answer and his/her edits are still all over the place.

 

Someone has more information? Comments?

 

Daniel  

 

 

(1) http://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct

 

From: James Mast [mailto:rickmastfa...@hotmail.com] 
Sent: June-25-15 23:56
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Ref tags in Ontario

 

I've been noticing that a user has been adding the prefix of 'ON' to the ref
tags on ways recently in Ontario.  Are you starting to do that now, or is
this user in error with the current tagging practices?

-James

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

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

[Daniel Begin]

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

Just recall that there are two issues with this one. ..
- Imports of addresses data have been done without importing corresponding 
roads (there are roads on the ground but not in OSM);
- Some addresses data are wrong - then there are no roads associated to them

Daniel

-Original Message-
From: Paul Norman [mailto:penor...@mac.com] 
Sent: June-18-15 17:15
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] OSM data quality in Canada

On 6/17/2015 1:12 PM, Martijn van Exel wrote:
> * What is the imports history, particularly in relation to road 
> network, POIs and addresses? (Beyond what’s in the import catalogue 
> page on the wiki, if anything)
CanVec, National Hydrographic Network (NHN), and National Road Network (NRN), 
all out of Natural Resources Canada (NRCan).

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

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

I'm not aware of anything really under consideration. Data released by the 
federal government under their OGL variant is okay license-wise, but the same 
is not always true for the provincial and municipal data.
> * Are there any Canada-specific mapping and tagging conventions?
Because roads are largely the responsibility of provinces, road classification 
varies province by province.
> * Are there any known big (national) issues in the Canadian OSM data? 
> (misguided imports / bots, major tagging disputes, that kind of thing)
CanVec has left parts of the country a colossal mess. I would say the 
forest/water data is the worst, often coming from different sources from the 
70s, and these sources often do not agree with each other. When faced with 40 
year old imported landcover data that doesn't resemble reality, the best option 
is often to just delete it.

There are some regional quirks with CanVec. These include

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

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

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

> * Which (other) companies / organizations / government agencies use OSM data 
> for Canada?
NRCan used to use CanVec and OSM matching to find locations missing in their 
dataset, but I'm not sure if they do this anymore.
> * Any suggestions for QA tools that would help the community, either existing 
> or new?
Beyond the standard international ones, I'm not sure. The incorrect surface, 
lanes, housenumbers, and extra spaces are probably all amenable to a mechanical 
edit rather than a QA tool. Some headway has been made with mechanical edits. 
The tag cruft will remove itself over time as people edit the objects.

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

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

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


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

Re: [Talk-ca] Offset à Laval

[Daniel Begin]

Bruno,

Il y a beaucoup de tracés GPS dans la région de Laval …  Je comparerais les 
images en questions avec les tracés disponibles, particulièrement près des 
autoroutes (là où il y aura une grande quantité de tracés). Comme la 
topographie est plane dans la région, le calage devrait être valide pour de 
grandes distances par rapport à la localisation des tracés…

 

Je cale toujours les images avec des tracés GPS, particulièrement s’il y en a 
plus d’un (compte-tenu des erreurs associées aux données GPS). 

 

Daniel

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: January-02-15 11:45
To: Daniel Begin
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Offset à Laval

 

Bonjour,

Voici un complément d'informations:

Voici toutes les données qui ont le même alignement:

- les  données des contributeurs locaux datant de +12 mois (parc, bâtiments, 
pistes cyclables...) qui étaient probablement alignées sur l'ancienne imagerie 
Bing de 2009/2010 approx.

- les interpolations CANVEC

- l'imagerie Mapbox

Exemple:


https://www.openstreetmap.org/#map=18/45.585185/-73.671649



Ce qui laisse à penser que, depuis longtemps, l'import CANVEC et l'ancienne 
imagerie Bing étaient corrects (hypothèse confirmée par le positionnement 
identique de la récente imagerie Mapbox), donc l'imageire Bing actuelle serait 
la seule a être décallée.

 

Ceci oriente pas mal la réponse à ma question.. mais quel est votre avis?

 

Le 1 janvier 2015 22:24, Daniel Begin  a écrit :

Salut Bruno,

J’ai travaillé à Laval il y a un bon moment. L’imagerie de l’époque était 
médiocre alors j’utilisais les tracés GPS disponibles pour caler les images. Il 
y a peut-être un peu de ça dans ce que tu constates?

 

Daniel

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: January-01-15 20:22
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Offset à Laval

 

Bonjour à tous,

Parmi les contributeurs qui éditent dans le coin de l'Ile de Laval (QC), il 
semble y avoir un offset de l'imagerie Bing. Travaillez-vous avec un décallage 
de l'imagerie satellite dans JOSM, pour l'aligner avec les données ?
Ou bien ce sont les données existantes qui ont une mauvaise géométrie et qui 
doivent être corrigées selon l'imagerie?

Merci d'avance!

 

-- 

Bruno Remy




-- 

Bruno Remy

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

Re: [Talk-ca] Offset à Laval

[Daniel Begin]

Salut Bruno,

J’ai travaillé à Laval il y a un bon moment. L’imagerie de l’époque était 
médiocre alors j’utilisais les tracés GPS disponibles pour caler les images. Il 
y a peut-être un peu de ça dans ce que tu constates?

 

Daniel

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: January-01-15 20:22
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Offset à Laval

 

Bonjour à tous,

Parmi les contributeurs qui éditent dans le coin de l'Ile de Laval (QC), il 
semble y avoir un offset de l'imagerie Bing. Travaillez-vous avec un décallage 
de l'imagerie satellite dans JOSM, pour l'aligner avec les données ?
Ou bien ce sont les données existantes qui ont une mauvaise géométrie et qui 
doivent être corrigées selon l'imagerie?

Merci d'avance!

 

-- 

Bruno Remy

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

Re: [Talk-ca] Riviere Des Prairies - Il y a une rivere qui se cache sous la riviere, sous la riviere ...

[Daniel Begin]

Merci Pierre pour ce ménage du temps des fêtes !-)

 

As-tu rejoint Alain512 concernant la situation?  Je remarque que ce 
contributeur est toujours actif et qu’il a essayé de corriger la situation il y 
a à peine 3 mois (Changeset: 25625517).

 

J’ai tenté de joindre Alain512 en Octobre 2011 pour le même genre de problème 
(mélange de coastline, riverbank et multipolygones sur le Lac St-Louis) sans 
jamais de réponses. Peut-être as/auras tu plus de chances …

 

Daniel

 

 

 

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: December-18-14 13:47
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Riviere Des Prairies - Il y a une rivere qui se cache 
sous la riviere, sous la riviere ...

 

Je vais faire du ménage cet après-midi, dépoussiérer les trois relations qui 
font doublon pour décrire l'ensemble de la rivière des Prairies et la Rivière 
des Milles-Iles.  Je vous demanderait de ne pas faire de modifcations à ces 
relations aujourd,hui, et à l'avenir, svp, consultez si vous avez des problèmes.





Au depart en septembre 2011, le contributeur Alain512 a créé trois relations 
Riviere des Prairies. Je ne sais quel était l'objectif de départ, mais 
maintenant toutes trois contiennent la riviere des Prairies, la rivière 
Mille-Iles, un bout de la rivière Mascouche, et un bout du fleuve à 
Pointe-aux-Trembles. À chacune il manque quelques îles. Beaucoup de 
modifications et confusion depuis 2011, des rôles révisés dans chacune, des 
chemins effacés et recréés semble-t-il.





Encore plusieurs personnes ont modifiés les relation riverbank sans bien 
connaitre ce type de relation.  Un waterway=riverbank a été remplacé depuis un 
bon bout de temps par place=island, Et les Iles semblent avoir navigué d'une 
relation à l'autre !!!



 

Au départ en septembre 2011, trois relations ont été créées par alain212. 
Depuis, les problèmes se multiplient, beaucoup de modifications de roles, de 
chemins effacés et recréés par divers contributeurs.





OpenStreetMap | Relation : ‪Riviere Des Prairies (‪1747225) 
  créée aussi le 9-9-2011

Il manque des iles et la portion à l'embouchure, à la jonction de la rivière 
des Milles-Iles. 

Cela Deviendra Rivière des Prairies, portion A.





OpenStreetMap | Relation : ‪Riviere Des Prairies (‪1747232) 
   
créée le 9-9-2011

Cela deviendra Rivière des Milles-Iles et la Rivière de Mascouche sera enlevée 
et traitée séparément. Et les Iles manquantes ajoutées.



 

OpenStreetMap | Relation : ‪RiviereDesPrairies.c (‪1769788) 
 

Cela deviendra Rivière des Prairies portion b, embouchure du fleuve. 

 

Si vous voyez des problèmes à ce schéma, svp commenter.

 

Pierre 



 

  _  

De : Pierre Béland <  pierz...@yahoo.fr>
À : Simon Poole <  si...@poole.ch>; " 
 talk-ca@openstreetmap.org" < 
 talk-ca@openstreetmap.org> 
Envoyé le : Jeudi 18 décembre 2014 8h20
Objet : Re: [Talk-ca] Riviere Des Prairies

 

Thanks Simon, we will take care of it.

 

Pierre 



 

  _  

De : Simon Poole <  si...@poole.ch>
À :   talk-ca@openstreetmap.org 
Envoyé le : Jeudi 18 décembre 2014 8h08
Objet : [Talk-ca] Riviere Des Prairies

 

 



I was reverting a changeset nearby and I noticed
http://www.openstreetmap.org/#map=15/45.6904/-73.6458

(there are a number of flooded islands outside of the obvious one).

This is likely to the multi-polygons for the Riviere Des Prairies being
a bit of a mess. I've found:


https://www.openstreetmap.org/relation/1747232  
 (broken geometry, no islands)

https://www.openstreetmap.org/relation/1747225  
 (broken geometry)


https://www.openstreetmap.org/relation/1769788  
 (overlaps the above,
island(s) missing, broken geometry)


https://www.openstreetmap.org/relation/1746332  
 (geometry ok, contains
islands)

There may be more.

I suspect that the likely working combination could be 1746332 and
1747225. But over to the local community.

Simon

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

[Daniel Begin]

J’approuve!

 

La donnée Canvec n’est pas un problème lorsque c’est la meilleure
disponible. Le problème est la mauvaise manipulation des données existantes
par certains contributeurs.  C’est là qu’un meilleur encadrement pourrait
faire une grande différence et limiter les frustrations – légitime – de ceux
qui voient leur travail détruit/altéré par des imports mal gérés.

 

Daniel 

 

From: Pierre Béland [mailto:bela...@yahoo.fr] 
Sent: November-18-14 10:22
To: Bruno Remy; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] RIP CanVec

 

 

Plusieurs articles parlent de l'entente entre OSM-France, l'IGN (cartes
topo) et la Poste française pour la constitution d'une base de données
nationale de données géoréférencées et ouvertes.

http://www.nextinpact.com/news/90933-l-etat-s-associe-a-societe-civile-pour-
elaborer-base-d-adresses-collaborative.htm

Ils ont aussi fait des imports et eu des problèmes. Et se sont donné les
moyens de former et encadrer les contributeurs, constituer des communautés.
C'est plus positif que de dire "marcher à pied avec son gps c'est mieux".

Ils se donnent plutôt les moyens de construire quelque chose. 

 

Sans compter leurs serveurs, des applications tels Osmose et des outils pour
coordonner l'import de données.

 

L'outil Osmose couvre le Québec. voir http://osmose.openstreetmap.fr
 

 

Est-ce que ce genre d'outil ou d'autres pourraient nous aider à travailler
colectivement à améliorer la carte?

 

 

Pierre 

  _  

De : Bruno Remy <  bremy.qc...@gmail.com>
À : Paul Norman <  penor...@mac.com> 
Cc :   talk-ca@openstreetmap.org 
Envoyé le : Mardi 18 novembre 2014 7h47
Objet : Re: [Talk-ca] RIP CanVec

 

Bonjour,

À mon humble avis, après que plusieurs avis pour et contre Canvec aient été
échangés (et j'appuie la majorité de ceux-ci), il serait von de recentrer le
débat:

Gardons tous en vue qu'OpenStreetMap est avant tout une carte citoyenne et
que c'est à chacun de nous d'enrichir les données, tant sur le plan
qualitatif que quantitatif.

Donc après avoir argumenté pour/contre Canvec, l'amélioration des boisés,
plans d'eau, interpolations etc est entre nos mains...
Se décourager devant l'ampleur du travail ou bien éditer un jour à la
fois c'est en fonction du dynamisme de nos communautés locales partout
au Canada, que nous obtiendrons un beau résultat.

Pour les Laurentides, la communauté de la Province du Québec tente de se
structurer et le noyau de contributeurs de Montréal et Québec autour de ce
projet pourrait vous venir en aide.

Bruno

 

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

Re: [Talk-ca] Bringing canvec to OSM back to life

[Daniel Begin]

Well, since we do not have received any response/insurance from NRCan that the 
ftp site will keep running, I would like to have a backup location, just in 
case the official ftp site stops to provide data. I would be very sad if the 
data eventually ends up being no longer available.

 

However, since I used to be the NRCan contact (now retired), I wish to make 
clear that my answer is from an OSM user’s point of view, not an NRCan answer 
(official or not !-)

 

Best

Daniel

 

From: Darren Wiebe [mailto:dar...@aleph-com.net] 
Sent: November-15-14 16:21
To: Daniel Begin
Cc: davis.christop...@gmail.com; Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Bringing canvec to OSM back to life

 

Would it be acceptable to mirror the Canvec data in the FTP site?  I'd gladly 
put up the resources to serve up the data.

 

Darren Wiebe

 

 

First, a short clarification – I do not know if Canvec will no longer (never 
again) be supplied in OSM format, I just know there are currently no resources 
allocated to work with the OSM community.

 

Second, about the Canvec conversion scripts …

-  They are owned by the crown – I would be surprised they could/would 
be released to the public;

-  They were all developed with FME – a powerful tool – but you usually 
need to pay to get the appropriate licences…

 

Third, concerning potential “diffs” files …

-  There are some references to diffs files in talk-ca archives (some 
were even available for few NTS through ftp site)

-  Maybe diffs files are available for Canvec? I do not know. 

 

Forth, my main concern is more about the sustained availability of the data in 
the ftp site L

 

Best,

Daniel

 

 

From: Chris Davis [mailto:davis.christop...@gmail.com] 
Sent: November-15-14 01:56
To: Darren Wiebe
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Bringing canvec to OSM back to life

 

I think it would be great to see newer CanVec data in OSM as well. BC's 
vegetation coverage from the last import in 2010 (tagged as "natural":"wood") 
is horribly patchy and quite ugly in the OSM basemap and other maps.

 

Chris

 

On 14 November 2014 18:25, Darren Wiebe  wrote:

I can only address point 4.  I'd love to see newer Canvec data. 

 

Darren Wiebe

 

On Fri, Nov 14, 2014 at 7:18 PM, Andrew  wrote:

Hello List:

Given Daniel's reply that Canvec will no longer be supplied in OSM
format, I'm curious about:

1:  I don't know what I don't know to begin with :-)
2:  Are the scripts / programs available to do the conversion still
available?
3:  Was there ever a program written to produce a "diffs" file?
4:  Is there a desire to have newer Canvec data converted to OSM?

Just throwing this out there.

Andrew
aka CanvecImports


___
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] Bringing canvec to OSM back to life

[Daniel Begin]

Bonjour OSM lovers!

 

First, a short clarification – I do not know if Canvec will no longer (never 
again) be supplied in OSM format, I just know there are currently no resources 
allocated to work with the OSM community.

 

Second, about the Canvec conversion scripts …

-  They are owned by the crown – I would be surprised they could/would 
be released to the public;

-  They were all developed with FME – a powerful tool – but you usually 
need to pay to get the appropriate licences…

 

Third, concerning potential “diffs” files …

-  There are some references to diffs files in talk-ca archives (some 
were even available for few NTS through ftp site)

-  Maybe diffs files are available for Canvec? I do not know. 

 

Forth, my main concern is more about the sustained availability of the data in 
the ftp site L

 

Best,

Daniel

 

 

From: Chris Davis [mailto:davis.christop...@gmail.com] 
Sent: November-15-14 01:56
To: Darren Wiebe
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Bringing canvec to OSM back to life

 

I think it would be great to see newer CanVec data in OSM as well. BC's 
vegetation coverage from the last import in 2010 (tagged as "natural":"wood") 
is horribly patchy and quite ugly in the OSM basemap and other maps.

 

Chris

 

On 14 November 2014 18:25, Darren Wiebe  wrote:

I can only address point 4.  I'd love to see newer Canvec data. 

 

Darren Wiebe

 

On Fri, Nov 14, 2014 at 7:18 PM, Andrew  wrote:

Hello List:

Given Daniel's reply that Canvec will no longer be supplied in OSM
format, I'm curious about:

1:  I don't know what I don't know to begin with :-)
2:  Are the scripts / programs available to do the conversion still
available?
3:  Was there ever a program written to produce a "diffs" file?
4:  Is there a desire to have newer Canvec data converted to OSM?

Just throwing this out there.

Andrew
aka CanvecImports


___
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] canvec release schedule

[Daniel Begin]

Well, as far as I know, NRCan have no more projects around OSM community since 
fall 2012 - no more Canvec in .osm format, no more participation to the talk-ca 
list.  Governmental priorities change and they could eventually get back to the 
community but, for the moment, I am even surprised the ftp site is running!

Hoping for the best 
Daniel 

-Original Message-
From: Andrew [mailto:andrew.alli...@teksavvy.com] 
Sent: November-08-14 15:28
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] canvec release schedule

Hello List:

I seem to remember that Canvec had a 6 month release schedule for OSM, 
but the data on the ftp site seams to be about a year and half old.

http://ftp2.cits.rncan.gc.ca/OSM/pub/042/F/

Now I do see some newer data in:

http://ftp2.cits.rncan.gc.ca/pub/canvec+/

Is the Canvec data no longer being converted / made available for OSM?
Any tidbit of wisdom? 

Andrew




___
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] Bing updated imagery in Windsor, Ontario

[Daniel Begin]

Merci pour l’information!

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: September-19-14 09:42
To: Pierre Béland
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Bing updated imagery in Windsor, Ontario

 

Bonjour Pierre,

C'est intégré dans JOSM (sans plug-in supplémentaire ... sauf erreur de ma 
part)

1-selectionner la couche "Bing Imagery" en premier plan
2-Juste à faire un clic-droit pour afficher le menu contextuel: une des options 
propose l'affichage des informations de la tuile en cours.

3-Le "timestamp" de chaque tuile apparait en sur-couche en rouge.


---

Il existe un outil d'information web, mais non fiable car ses données ne 
semblent pas être correctement mises à jour:
Bing Aerial Imagery Analyzer for OpenStreetMap
http://mvexel.dev.openstreetmap.org/bingimageanalyzer/?lat=49.3935298445362 

 &lon=10.976469421386724&zoom=11

Bruno

 

2014-09-19 9:28 GMT-04:00 Pierre Béland :

Bonjour Bruno,

 

quel outil pour vérifier date de production des images d'une zone?

 

Pierre 

  _  

De : Bruno Remy 
À : James Mast  
Cc : "talk-ca@openstreetmap.org"  
Envoyé le : Vendredi 19 septembre 2014 14h55
Objet : Re: [Talk-ca] Bing updated imagery in Windsor, Ontario

 

The same here arround Québec City (QC, CA) !!
According to JOSM, the imagery Bing is about 10 months.



 

2014-09-19 7:39 GMT-04:00 James Mast :

 

Just wanted to give you guys a heads up in anybody wanted to do a massive 
cleanup of the new 401 construction in that area.  According to JOSM, the 
imagery Bing now has is about 3 months old taken between 05/31/14 and 06/15/14.

So, if anybody feels like having some fun, have at it. ;)

-James


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




-- 
Bruno Remy 

 

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

 




-- 
Bruno Remy 

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

Re: [Talk-ca] Large polygons in JOSM

[Daniel Begin]

Oups, forgot your second point…

 

About motivation to clean the north, I think a specialized bot could remove 
duplicated water/wooded area geometries. About merging all these tiles, it 
would mean having a multipolygon covering about half of the country with 
hundreds of thousands of hole in it…   I am almost certain that merging all of 
them would not be a good idea.

 

Anyone could comment about the consequences of merging all these tiles?

 

Daniel

From: Daniel Begin [mailto:jfd...@hotmail.com] 
Sent: September-18-14 06:46
To: 'Stewart C. Russell'; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Large polygons in JOSM

 

Bonjour Stewart,

 

Basically, you need to identify the lake as being a hole in the wooded area. 
Since both the lake and the hole are provided with Canvec data, you need either 
to …

-  Delete the lake and tag the hole as natural=water, or 

-  Delete the hole and add the lake as an inner component of the 
multipolygon.

 

The same sometime applies with wetlands in cases wetlands create a hole in the 
wooded area (you need a good imagery to see it); however, I should confess I do 
it only when it is not too complex ;-) 

 

See an example here: http://www.openstreetmap.org/#map=16/45.8514/-71.1917

 

Best,

Daniel

 

From: Stewart C. Russell [mailto:scr...@gmail.com] 
Sent: September-17-14 20:46
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Large polygons in JOSM

 

On 14-09-15 05:41 PM, Daniel Begin wrote:

  

About Canvec, the product often duplicates water bodies and inner polygons of 
wooded areas; which is not necessary where both were imported. In order to keep 
only the necessary geometries, I usually transfer all the tags from a waterbody 
to the duplicated geometry of an inner polygon and then, I delete the original 
- now duplicated - waterbody.

 


Hi Daniel,

I have to confess I don't quite follow what you're doing here. Are you leaving 
the waterbody defined only as the inner polygon (aka, a hole) of a landuse 
multipolygon? Are there any example ways you can link to that do this? 

The difficulty with the huge 'tiled' areas of the North is that few people will 
find the motivation needed to clean up the imports into coherent polygons.

cheers,
 Stewart

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

Re: [Talk-ca] Large polygons in JOSM

[Daniel Begin]

Bonjour Stewart,

 

Basically, you need to identify the lake as being a hole in the wooded area. 
Since both the lake and the hole are provided with Canvec data, you need either 
to …

-  Delete the lake and tag the hole as natural=water, or 

-  Delete the hole and add the lake as an inner component of the 
multipolygon.

 

The same sometime applies with wetlands in cases wetlands create a hole in the 
wooded area (you need a good imagery to see it); however, I should confess I do 
it only when it is not too complex ;-) 

 

See an example here: http://www.openstreetmap.org/#map=16/45.8514/-71.1917

 

Best,

Daniel

 

From: Stewart C. Russell [mailto:scr...@gmail.com] 
Sent: September-17-14 20:46
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Large polygons in JOSM

 

On 14-09-15 05:41 PM, Daniel Begin wrote:

  

About Canvec, the product often duplicates water bodies and inner polygons of 
wooded areas; which is not necessary where both were imported. In order to keep 
only the necessary geometries, I usually transfer all the tags from a waterbody 
to the duplicated geometry of an inner polygon and then, I delete the original 
- now duplicated - waterbody.

 


Hi Daniel,

I have to confess I don't quite follow what you're doing here. Are you leaving 
the waterbody defined only as the inner polygon (aka, a hole) of a landuse 
multipolygon? Are there any example ways you can link to that do this? 

The difficulty with the huge 'tiled' areas of the North is that few people will 
find the motivation needed to clean up the imports into coherent polygons.

cheers,
 Stewart

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

Re: [Talk-ca] Large polygons in JOSM

[Daniel Begin]

+1

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: September-17-14 08:37
To: Daniel Begin
Cc: Sam Dyck; Tom Taylor; Talk-CA OpenStreetMap
Subject: RE: [Talk-ca] Large polygons in JOSM

 

Hello,

Well... i agree with you, Daniel, about use of inner/outer membership roles of 
multipolygons : regardless of rendering priorities, this is mandatory for an 
accurate outlines extraction for a specific feature: wood, water, etc...

However, in my opinion, such "raw" multipolygones from Canvec imports and 
splitted by square tiles needs to be tuned (splited or merged) mostly close to 
urban areas...

Bruno

Le 2014-09-15 17:41, "Daniel Begin"  a écrit :
>
> Bonjour,
>
>  
>
> Well, I understand that multipolygons are often not easy to work with. 
> However, from what I understand of OSM data model, they should be used 
> whenever appropriate.
>
>  
>
> In that sense, I do not agree with Bruno that 'inner' roles are useless for 
> lakes in the case of wooded areas. It might be OK for rendering (you see 
> lakes inside wooded areas because priorities have been used to create the 
> map) but, IMHO, it is not the case if you work only on wooded areas – or any 
> feature type!
>
>  
>
> About Canvec, the product often duplicates water bodies and inner polygons of 
> wooded areas; which is not necessary where both were imported. In order to 
> keep only the necessary geometries, I usually transfer all the tags from a 
> waterbody to the duplicated geometry of an inner polygon and then, I delete 
> the original - now duplicated - waterbody.
>
>  
>
> a humble two cents...
>
>  
>
> Daniel
>
> From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
> Sent: September-15-14 12:59
> To: Tom Taylor
> Cc: Sam Dyck; Talk-CA OpenStreetMap
> Subject: Re: [Talk-ca] Large polygons in JOSM
>
>  
>
> Tom's strategy seems to be appropriate for woods areas:
>
> Canvec 'giant monster' multipolygons represents a set of several polygons 
> quite closed but not adjascent ,  mostly separated by  meadow/scrub or fire 
> cut-lines or rivers, or roads 
>
> By the way: membership as 'inside' role of wood multipolygon is useless for a 
> lake
>
> So, you never need 'outside' or 'inside' role: just keep outlines of wood.
>
> Mapping this way avoid the use of multipoygons, and encourage the use of 
> simple polygons (prefered).
>
> (imo)
>
> Simplier is better ;)
>
> But  indeed.. i agree with Sam: is time consuming ! :(
>
> Perhaps a motivation to encourage membership of new OSM contributors, as we 
> celebrate the 10th of OpenStreetMap !! ;-)
>
> The more we are.. the less we do ;)
>
>  
>
> Bruno
>
>  
>
>  
>
> 2014-09-15 11:46 GMT-04:00 Tom Taylor :
>
> Might be dull, but I generally split multipolygons into reasonably-sized 
> adjacent chunks rather than giant monsters. In my case, it's usually when I'm 
> outlining a river.
>
> Tom Taylor
>
> On 14/09/2014 10:29 PM, Sam Dyck wrote:
>
> HI
>
> Currently I'm working on importing the Canvec tiles that make up Lac
> Seul in NW Ontario into OSM. Importing the data as it is, split into
> tiles and subtiles, is poor practice, and manually merging is time
> consuming and dull. So I began using JOSM's Join Overlapping Areas
> feature. This tool however requires that all ways be complete before
> merging. Resulting is a 100 000 node area that far exceeds JOSMs import
> limit and is time consuming to split up, and slows down JOSM. Is there
> an faster way to split this?
>
> Sam
>
>
> ___
> 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
>
>
>
>
> -- 
> Bruno Remy

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

Re: [Talk-ca] Large polygons in JOSM

[Daniel Begin]

Bonjour,

 

Well, I understand that multipolygons are often not easy to work with. However, 
from what I understand of OSM data model, they should be used whenever 
appropriate.

 

In that sense, I do not agree with Bruno that 'inner' roles are useless for 
lakes in the case of wooded areas. It might be OK for rendering (you see lakes 
inside wooded areas because priorities have been used to create the map) but, 
IMHO, it is not the case if you work only on wooded areas – or any feature type!

 

About Canvec, the product often duplicates water bodies and inner polygons of 
wooded areas; which is not necessary where both were imported. In order to keep 
only the necessary geometries, I usually transfer all the tags from a waterbody 
to the duplicated geometry of an inner polygon and then, I delete the original 
- now duplicated - waterbody.

 

a humble two cents...

 

Daniel

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: September-15-14 12:59
To: Tom Taylor
Cc: Sam Dyck; Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Large polygons in JOSM

 

Tom's strategy seems to be appropriate for woods areas:

Canvec 'giant monster' multipolygons represents a set of several polygons quite 
closed but not adjascent ,  mostly separated by  meadow/scrub or fire cut-lines 
or rivers, or roads 

By the way: membership as 'inside' role of wood multipolygon is useless for a 
lake

So, you never need 'outside' or 'inside' role: just keep outlines of wood.

Mapping this way avoid the use of multipoygons, and encourage the use of simple 
polygons (prefered).

(imo)

Simplier is better ;)

But  indeed.. i agree with Sam: is time consuming ! :(

Perhaps a motivation to encourage membership of new OSM contributors, as we 
celebrate the 10th of OpenStreetMap !! ;-)

The more we are.. the less we do ;)

 

Bruno

 

 

2014-09-15 11:46 GMT-04:00 Tom Taylor :

Might be dull, but I generally split multipolygons into reasonably-sized 
adjacent chunks rather than giant monsters. In my case, it's usually when I'm 
outlining a river.

Tom Taylor

On 14/09/2014 10:29 PM, Sam Dyck wrote:

HI

Currently I'm working on importing the Canvec tiles that make up Lac
Seul in NW Ontario into OSM. Importing the data as it is, split into
tiles and subtiles, is poor practice, and manually merging is time
consuming and dull. So I began using JOSM's Join Overlapping Areas
feature. This tool however requires that all ways be complete before
merging. Resulting is a 100 000 node area that far exceeds JOSMs import
limit and is time consuming to split up, and slows down JOSM. Is there
an faster way to split this?

Sam


___
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




-- 
Bruno Remy 

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

Re: [Talk-ca] Confusing CanVec import: Elliot Lake

[Daniel Begin]

I give a big +1 to James' comments

-Original Message-
From: James Ewen [mailto:ve6...@gmail.com] 

... existing data usually stays. Obviously a mistake was made. We're all human.
... whichever source has the best resolution should be the one that stays, or 
perhaps a merge of the best data from both...
... OSM is a living entity that changes.
... you've found an area of concern, and Andrew is responding. You can't get 
much better than this.
... should we take your Horne Lake closed polygon and simplify it down to 20 
points? [...] who defines sensible?

... And of course, thank you to both of you for all the work you guys ave done 
in adding to the OSM database. Everyone's contributions are appreciated, but 
occasionally we bump into each other. This forum gives us the perfect place to 
say "Oops, excuse me... sorry!"



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

Re: [Talk-ca] Confusing CanVec import: Elliot Lake

[Daniel Begin]

I would ask   CanvecImports to 
clean his mess…

Daniel

 

From: Stewart C. Russell [mailto:scr...@gmail.com] 
Sent: August-27-14 11:44
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Confusing CanVec import: Elliot Lake

 

Hi - back in Elliot Lake after a couple of years away, and my, has the map 
grown here. It looks like there has been multiple overlapping imports in some 
places, though. F'rinstance, this relation:

http://www.openstreetmap.org/relation/1176648

has multiple coastlines, an import square bisecting a lake, and forestry 
land-use sitting in the water. There are also some hand-surveyed details 
removed by an import. I know they weren't perfect, but neither's the import.

And I didn't even bring a GPS with me to start to fix the damage …

cheers,
 Stewart

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

Re: [Talk-ca] Coastline or not coastline

[Daniel Begin]

+1

Daniel

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: July-29-14 14:05
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Coastline or not coastline

 

Un premier contributeur a successivement modifié, effacé et recréé plusieurs
chemins. Ensuite plusieurs autres alertés par des outils tels Inspector sont
intervenus. Tous étaient de bonne volonté, et plusieurs expérimentés. Malgré
tout, personne n'avait une vue d'ensemble. 

 

Les éditions successives nous on fait perdre l'historique des éditions. Ces
éditions n'ont rien ajouté à ce qu'il y avait préalablement. Il ne semble
pas non plus que tout a été corrigé correctement. Il y a aussi risque que
les limites administratives environnantes ont été touchées.

 

J'ai rapporté ce problème au Data Working Group de la Fondation OSM et
demandé d'étudier la possibilité de faire un revert de ces éditions et
revenir à la situation initiale.  Cela me semble la meilleure solution pour
s'assurer de corriger correctement.

 

Il est aussi important lors de tels problèmes de venir en discuter sur la
liste avant toute intervention.  Les relations liées aux limites
administratives et et contours de rivieres, fleuves, océans, sont des
éléments plus complexes à maitriser. Si vous ne connaissez pas bien ces
éléments, il vaut mieux rapporter les problèmes à la liste que de tenter de
corriger vous-même.

 

Pierre 

  _  

De : Pierre Béland 
À : "talk-ca@openstreetmap.org"  
Envoyé le : Mardi 29 juillet 2014 9h01
Objet : Re: [Talk-ca] Coastline or not coastline

 

Je disais dans un courriel précédent que des contributeurs inexpérimentés
ont modifié les coastline autour de Montréal. De fait, même s'ils ont déja
fait beaucoup d'édition OSM, ils sont inexpérimentés avec les coastline. Ils
ne réalisent pas l'impact de l'édition de tels éléments et la difficulté à
corriger par la suite quand plusieurs contributeurs tentent les uns après
les autres de corriger par la suite.

 

Pour compliquer la situation, un premier contributeur, Boff II, a effacé et
recréé les chemins tracant les contours de rivières et fleuves. Procédant
ainsi, nous perdons l'historique des éditions, et cela rend encore plus
difficiles les corrections.

 

Svp, cessez de corriger. Il faut analyser la situation, identifier les
sessions d'édition concernées. Et je pense que le mieux sera de faire de
Revert de tout cela.

 

Pierre 

  _  

De : Pierre Béland 
À : Charles Basenga Kiyanda ;
"talk-ca@openstreetmap.org"  
Envoyé le : Lundi 28 juillet 2014 23h57
Objet : Re: [Talk-ca] Coastline or not coastline

 

 

J'avais deja passé passablement de temps l'an dernier pour corriger a
couvrir toute la zone jusqu'au lac St-Pierre.

 

A partir des relations, Overpass pourrait sûrement nous aider a identifier /
télécharger rapidement tous les chemins concernés. Puis je pense que le
mieux est de placer l'attribut natural=coastline dans les relations. De
cette façon, il y a moins de risque que des usagers inexpérimentés viennent
modifier l'attribut.

 

Pierre 

  _  

De : Charles Basenga Kiyanda 
À : talk-ca@openstreetmap.org 
Envoyé le : Lundi 28 juillet 2014 23h40
Objet : Re: [Talk-ca] Coastline or not coastline


Je suis bien d'accord que ces usagers (qui ne semblent pas savoir tout à
fait comment corriger le problème) devraient arrêter pour l'instant.
Ceci dit, le coastline doit effectivement être corrigé. Présentement,
les grands lacs canadiens sont taggés avec natural = coastline,
l'embouchure du St-Laurent jusqu'à quelque part entre montréal et
Trois-Rivières l'est aussi. Par contre, de la moitié de l'île Jésus/Île
de Montréal vers l'est, natural=coastline est absent. Les tags
présentement sont consistent (les coastlines sont fermées), mais le
Canada a un coastline intérieur qui n'est pas connecté avec le coastline
évident.

Selon moi, il faudrait rajouter natural=coastline dans la section
manquante pour reconnecter les grands lacs avec l'extérieur du
continent. Il y a un autre cas de grands lacs taggés avec
natural=coastline, il me semble en Afrique.

La situation est problématique vu le grand nombre d'îles dans cette
partie du St-Laurent. Je m'y suis attaqué moi aussi, mais je n'en savais
pas assez pour terminer la correction. (Par contre, j'en savais assez
pour abandonner mon changeset avant de causer un problème.)

Je ne sais pas s'il y a un moyen de régler le problème à plusieurs.
Seul, ça allait me prendre des semaines et je ne voulais pas créer des
problèmes dans la base de données sur une si longue période. Si on se
rencontrait tous dans un lieu commun avec un bon accès à internet (ou
sur un serveur mumble, etc, etc), on pourrait peut-être diviser le
travail en lot et le finir en un après-midi. Il y aurait plusieurs
changesets, mais comme les niveaux de zoom moins élevés sont générés
infréquemment, on pourrait passer entre 2 updates.


Cheers,

Charles

On 14-07-28 05:10 PM, Pierre Béland wrote:
> 
>  
> Pierre
> 
> Les usagers Rub21 et dmgroom_ct devraient cesser d'éditer l

[Talk-ca] New routing algorythm

[Daniel Begin]

Considering this nice summer time (at least in my area), this should be
implemented using OSM J

 

http://www.technologyreview.com/view/528836/forget-the-shortest-route-across
-a-city-new-algorithm-finds-the-most-beautiful/

 

Daniel

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

Re: [Talk-ca] Updating Street Centerlines in County of Grey, Ontario, Canada

[Daniel Begin]

Bonjour Soham, 

 

IMHO, importing a street network to improve the accuracy of an area that is
already covered is not a good idea and could be considered as vandalism -
mainly because it means deleting what have been done by previous
contributors.  However, if you have the time to compare both datasets,
aerial imagery, available GPS tracks, and adjust OSM data where it is way
out would be a better strategy . and I am assuming that the licence attached
to the data you propose is compatible with OSM licence, right?

 

Another strategy would be to make the data available under a public domain
licence and let the community do the job - if they are interested. By the
way, am I wrong if I say that the street network you are proposing to import
usually end up in the GeoBase product (through the provincial government)?

 

Best,

Daniel

 

From: Shah,Soham [mailto:soham.s...@grey.ca] 
Sent: July-03-14 11:28
To: talk-ca@openstreetmap.org; impo...@openstreetmap.org
Subject: [Talk-ca] Updating Street Centerlines in County of Grey, Ontario,
Canada

 

Hello,

 

The GIS department at the County of Grey, Ontario was interested in updating
the street centerline data with our Grey County Road Data, which we believe
is more precise, both in terms of centerline placement and road labelling.

 

I was thinking of using the JOSM Editor utility to bulk import the data. I
read on the 'Import process guidelines' wiki that street centerlines can be
very difficult to import. So, I am looking for some guidance and opinions of
the OSM community to know if this is a viable import project at the County
Scale.

 

Thanks.

 

Soham Shah
GIS Specialist
Grey County
595 9th Avenue East
Owen Sound, ON N4K 3E3
Phone: +1 519-372-0219 ext. 1535
Fax: +1 519-376-5640
  soham.s...@grey.ca
  http://www.grey.ca/it
  http://www.visitgrey.ca

  http://www.greyroots.com 

  Image removed by sender. Facebook
 Image removed by sender. Twitter
 Image removed by sender. LinkedIn

Image removed by sender. Grey County

 

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

[Daniel Begin]

BTW, the Canvec product has been updated about 10 years ago (with satellite
imagery) over Northern Canada. It is actually the most up-to-date part of
Canada!

 

Daniel

 

From: i...@gmx.com [mailto:i...@gmx.com] 
Sent: March-27-14 22:13
To: 'Adam Martin'
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Nunavut has a very pour data coverage. Why not
Integrate BNDT/CanVec dataset from Department of Natural Resources Canada?

 

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

[Daniel Begin]

Cool !, 

I'll not being asked anymore by my GPS to make a U-turn ASAP when I get in
an uncorrected motorway link, or worst.

Being asked to drive for more than 100 Km on secondary roads, up to the next
adequate link !

Thanks again.

 

From: Harald Kliems [mailto:kli...@gmail.com] 
Sent: January-16-14 17:30
To: Daniel Begin
Cc: Connors, Bernie (SNB); Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] GPS and Motorway links ...

 

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

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

SAG_Logo_2013

 

From: Harald Kliems [mailto: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  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: 

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

[Daniel Begin]

Many thanks Harald J

Daniel

 

From: Harald Kliems [mailto:kli...@gmail.com] 
Sent: January-12-14 18:04
To: Daniel Begin
Cc: Connors, Bernie (SNB); Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] GPS and Motorway links ...

 

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

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

SAG_Logo_2013

 

From: Harald Kliems [mailto: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  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 

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

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

[Daniel Begin]

Bonjour Richard, 

You wrote that Imports are harmful to OpenStreetMap and to the OpenStreetMap
community. I'm inclined not to agree with you. However I may have missed
something obvious.

Saying that data import is harmful to OpenStreetMap project and harmful to
its community sounds like sharing a belief. 
Please, provide us with concrete examples to make all of us understand why -
not only believe - that imports are harmful...
- To the project, specifically in Canada?
- To the community, specifically in Canada?

I agree with Pierre that we should bring a minimum of nuances in discussing
subjects like the imports - actually, discussing with the community should
be done with nuances, whatever the subject. 

Considering all what you have done for the OSM project so far, and the
nuances you usually show in your words, the facts that support your
statement about import must be very strong! Unfortunately, I am not aware of
these facts/arguments and maybe the community is not either...

So please, take the time to make your point; and if possible be specific to
the Canadian community. I guess most of us are reasonable people and we
should be able to understand something that seems so obvious for you :-)

Best,
Daniel

-Original Message-
From: Richard Weait [mailto:rich...@weait.com] 
Sent: January-06-14 12:49
To: Pierre Béland
Cc: diane.merc...@gmail.com; Talk- CA Open Street Map
Subject: 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  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

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

[Daniel Begin]

Provinces provide roads to NRCan that simply package it for GeoBase and
Canvec. I might be wrong but I am on the impression that some provinces (not
all) create vertices at intersections (2D) and do not consider the elevation
(3D). When converting to OSM, duplicated vertices (one on each road) are
merged in one node.

That might explain what you found
Same thing for double spaces in name

Daniel

-Original Message-
From: Richard Weait [mailto:rich...@weait.com] 
Sent: December-02-13 15:51
To: Connors, Bernie (SNB)
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Problem with overpasses in NB??

On Mon, Dec 2, 2013 at 1:24 PM, Connors, Bernie (SNB)
 wrote:
> Here is an example - http://osm.org/go/cgZ854R_8--
>
> The problem is that there is an intersection node 
> between McKinnon Road and Route 8 but there is an overpass bridge at this
location.

That does look like an error, I've fixed that one.  The history on the
involved objects is short, and suggests that it is an import.  Do you want
to contact the mapper and ask about the matter?

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

[Daniel Begin]

+1 - It worked for my test areas 

 

From: Harald Kliems [mailto:kli...@gmail.com] 
Sent: November-27-13 11:05
To: Daniel Begin
Cc: Connors, Bernie (SNB); Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] GPS and Motorway links ...

 

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

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

SAG_Logo_2013

 

From: Harald Kliems [mailto: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  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 

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

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

[Daniel Begin]

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

SAG_Logo_2013

 

From: Harald Kliems [mailto: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  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 

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

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

[Daniel Begin]

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.

SAG_Logo_2013

 

From: Harald Kliems [mailto: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  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.

 

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

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

[Daniel Begin]

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! 

 

At least everything imported via Canvec and possibly the same with GeoBase.
Actually, we might have to add oneway=no for all motorway_link that that do
not have the tag. However, it may exist some motorway_link that have been
captured using this rule.

 

Any idea about the best way to proceed to correct the problem?

 

Daniel

 

 

From: Harald Kliems [mailto:kli...@gmail.com] 
Sent: November-25-13 15:06
To: Daniel Begin
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] GPS and Motorway links ...

 

Daniel,

if you look at the motorway_link page in the wiki
(http://wiki.openstreetmap.org/wiki/Motorway_link) you'll see that by
default it implies oneway=yes. That would explain the behavior you
described. 

 

"Most motorway_link roads will be one way, and should be tagged
<http://wiki.openstreetmap.org/wiki/Key:oneway> oneway=
<http://wiki.openstreetmap.org/wiki/Tag:oneway%3Dyes> yes. Any unusual
motorway link road which is two-way should be explicitly tagged
<http://wiki.openstreetmap.org/wiki/Key:oneway> oneway=
<http://wiki.openstreetmap.org/wiki/Tag:oneway%3Dno> no. Note that this is
different to the way we treat other highway classifications, because
motorway link roads are so often one way. Explicit tagging (either way) can
be important, since some tools interpret motorway link roads as implicitly
oneway=yes unless tagged oneway=no."

 

I wonder if there would be a way to filter all those links that are reversed
with the Overpass API?

 

 Harald.

 

On Mon, Nov 25, 2013 at 2:40 PM, Daniel Begin  wrote:

Bonjour, 

 

I've just found out that I have routing troubles with OSM data in a Garmin
GPS when motorway_link are not tagged oneway=yes/no. Here is an example
where some segments of motorway_link can be driven both ways (2 lanes, one
each side)

 

http://www.openstreetmap.org/#map=16/46.0194/-72.3512

 

Everything works fine when tags are.

highway=motorway_link

oneway=no, or 

oneway=yes

 

But it doesn't work if there is no oneway tag. Actually, the way must have
been digitized in the direction I want ot go - as if it assumes that no
oneway tag means oneway=yes.  In the provided example, my GPS will find a
way out of the motorway but it will not find a way in! -  must be looked at
in an editor.

 

It could have been my usual OSM/Garmin provider (
http://www.osmmaps.com/maps/canada ) but when I saw the same behavior in
JOSM I wonder if there is a rule I'm not aware of? Should I change my
OSM/Garmin provider or tell him there is a problem with his conversion
program?

 

Comments or answers?

 

Daniel


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

[Daniel Begin]

Bonjour, 

 

I've just found out that I have routing troubles with OSM data in a Garmin
GPS when motorway_link are not tagged oneway=yes/no. Here is an example
where some segments of motorway_link can be driven both ways (2 lanes, one
each side)

 

http://www.openstreetmap.org/#map=16/46.0194/-72.3512

 

Everything works fine when tags are.

highway=motorway_link

oneway=no, or 

oneway=yes

 

But it doesn't work if there is no oneway tag. Actually, the way must have
been digitized in the direction I want ot go - as if it assumes that no
oneway tag means oneway=yes.  In the provided example, my GPS will find a
way out of the motorway but it will not find a way in! -  must be looked at
in an editor.

 

It could have been my usual OSM/Garmin provider (
http://www.osmmaps.com/maps/canada ) but when I saw the same behavior in
JOSM I wonder if there is a rule I'm not aware of? Should I change my
OSM/Garmin provider or tell him there is a problem with his conversion
program?

 

Comments or answers?

 

Daniel

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

[Talk-ca] OSM Cycle map

[Daniel Begin]

I have found something odd with the rendering of OSM Cycle map; right on the
boundary. Didn't know there was such a cliff in the area!

 

http://www.openstreetmap.org/#map=14/45.0011/-72.1567
 &layers=C

 

Daniel

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

Re: [Talk-ca] CanVec 10 Data

[Daniel Begin]

Thanks for having found the missing part Harald!-)

 

From: Harald Kliems [mailto:kli...@gmail.com] 
Sent: November-04-13 09:17
To: Daniel Begin
Cc: Steve Roy; Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] CanVec 10 Data

 

I think Daniel's email got cut off at the end :-)

 

On Mon, Nov 4, 2013 at 6:26 AM, Daniel Begin  wrote:

I'm not familiar with imports using Potlatch but importing it using JOSM is
quite easy - open the file, select the features, copy then in a new layer
and then upload the layer in OSM...

...after you've carefully checked if everything is plausible and you don't
mess up the work of other contributors who may already have added
housenumber data of better quality.

 Harald. 

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

Re: [Talk-ca] CanVec 10 Data

[Daniel Begin]

Bonjour Steve,
The "semi" street numbering is based on the Karlsruhe schema (1) that is a
standard interpolation mechanism (2) in OSM's Street addressing (3)
 
1- http://wiki.openstreetmap.org/wiki/Karlsruhe_schema
2- http://wiki.openstreetmap.org/wiki/Addresses#Using_interpolation
3- http://wiki.openstreetmap.org/wiki/Key:addr

So, I think it worth importing :-)

I'm not familiar with imports using Potlatch but importing it using JOSM is
quite easy - open the file, select the features, copy then in a new layer
and then upload the layer in OSM...

Daniel


-Original Message-
From: Steve Roy [mailto:st...@ssni.ca] 
Sent: November-03-13 23:37
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] CanVec 10 Data

I have been doing some CanVec 10 imports and noticed in the latest files
that it includes "semi" street numbering - like odd/even block numbers.
An example here:
http://www.openstreetmap.org/#map=18/49.74784/-123.11109

Is this worth importing?  If so is there an easy way to import just this via
JOSM?  I only use Potlatch currently.

Thanks
Steve

___
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] Where the streets have no name...

[Daniel Begin]

Bonjour,

Concernant les données Canvec, le site est accessible via la page Canvec
dans le wiki  ou via …  
http://ftp2.cits.rncan.gc.ca/OSM/pub 

 

Canvec data are available through Canvec’s wiki page or using the following
link

  http://ftp2.cits.rncan.gc.ca/OSM/pub

 

Daniel

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: October-31-13 11:47
To: Tom Taylor; Bruno Remy; Harald Kliems
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Where the streets have no name...

 

Hi Tom

Il y a eu une discussion en juillet relativement a l'impossibilité de se
connecter au serveur ftp

 http://ftp2.cits.rncan.gc.ca/osm/pub

Il reste la possibilité d'accéder via JOSM aux couches CANVEC et Geobase.
J'ai ajouté ces couches dans la liste des couches disponibles. Voir dans la
section CA.


There was discussion in july about ftp access problems to 

 http://ftp2.cits.rncan.gc.ca/osm/pub

This is still not possible to connect. An option is to use in JOSM the
Canvec and Geobase layers. I have added these to the WMS/TMS list of
available layers under the CA section.

 

 

Pierre 

  _  

De : Tom Taylor 
À : Bruno Remy ; Harald Kliems  
Cc : "talk-ca@openstreetmap.org"  
Envoyé le : Jeudi 31 octobre 2013 9h31
Objet : Re: [Talk-ca] Where the streets have no name...


I started to work on the smallest slice in Quebec West, i.e., St. 
Augustin. I have no experience doing Canvec imports, so I've just been 
poking around on the Geogratis web site looking for the right product. I 
always seem to end up with a display of the same map data, not updated 
since 2005 and showing less information than we already have in OSM. Can 
you point me to what I really need?

Tom Taylor
TomT5454

On 30/10/2013 10:45 PM, Bruno Remy wrote:
> Bonjour,
>
> J'ai le plaisir de vous annoncer la création des 2 cartes MapCraft pour
> les principales villes du Québec qui souffrent d'un manque flagrant de
> qualité de leur cartographie. Dans ces zones, des rues sont manquantes
> ou sans nom. Je vous invite donc à choisir une zone et la compléter à
> l'aide des données Canvec/Geobase déjà présentes et/ou des vues
> satellite. C'est assez convivial, mais si vous avez des questions,
> n'hésitez pas à les adresser sur cette liste.
> Je vous souhaite bien du plaisir!
>
>
> Hello,
>
> I'm pleased to announce the release of MapCraft Slices for main cities
> of province of Quebec (QC) with a lack of quality mapping.
> On these areas,  streets are not mapped, and/or street names are
> missing. Feel free to choose one of these slices and complete them using
> Canvec/Geobase data (if still available) and/or satellite imagery. Thats
> quite convivial, but if you have questions feel free to post on this list.
> Have fun!
>
>
>  Québec Ouest (Rues/Streets) 
>
>
>  Québec Est (Rues/Streets) 
>
>
> Bruno
>
>
>
> Le 29 octobre 2013 12:12, Bruno Remy  > a écrit :
>
>Hello Harald!
>
>Very good suggestion! I'll do that!
>
>Stay tuned, folks: I'll advise you when it will be available!
>
>Cheers!
>
>
>Le 29 octobre 2013 09:01, Harald Kliems > a écrit :
>
>Bruno,
>thanks for this list! Something to do for me on those cold and
>rainy fall days... Would it maybe make sense to make a cake with
>MapCraft to coordinate the effort and avoid conflicts?
>http://wiki.openstreetmap.org/wiki/MapCraft
 I've never set up a
>cake, only used ones baked by others, but maybe someone on the
>list could help.
>Cheers,
>  Harald.
>
>
>2013/10/28 Bruno Remy >
>
>Bonjour à tous
>
>Dans un tout autre ordre d'idée, suite à des discutions qui
>ont eu
>lieu avant et pendant la Cartopartie de dimanche, li y a des
>villes du
>Québec qui demanderaient un soin tout particulier:
>Ces villes n'ont pas de noms de rues ou ont des quartiers
>entiers sans
>noms de rues. Parfois même des nouveaux développements
>résidentiels ne
>sont pas cartographiés, et pourtant ils apparaissent dans
>l'image
>satelite ou via les données Canvec ou Geobase...
>Comme chanterait U2 'Where the streets have no name'  ;-)
>
>Vous m'avez demandé cette liste dimanche, alors la voici :
>Ces villes sont classées par ordre décroissant sur 2
>criteres : leur
>état actuel de données, et leur population:
>
>Drummondville
>Mascouche
>Saint-Georges
>Saint-Bruno-de-Montarville
>Thetford Mines
>Sept-Îles
>Granby
>Trois-Rivières

[Talk-ca] Mapping multiple characteristics using the same tag - How to?

[Daniel Begin]

Hi all, just resending the email to create another tread - because I think it 
is important …

 

Bonjour Blanca,

 

Si je crois qu’un seul tag est généralement souhaitable, je ne vois pas 
pourquoi restreindre l’intérêt et la participation d’un contributeur pour cette 
raison, dans la mesure où il se conforme aux règles de la communauté.  Alors 
voici ce que je comprends des règles de la communauté OSM …

 

Il est possible d’utiliser le ‘;’ pour distinguer plusieurs valeurs pour un 
même tag (ref=* par exemple). 

 

Ce n’est cependant pas une pratique souhaitable si je me fie à la documentation 
suivante…

 

 <http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator> 
http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

 

Dans la section ‘When NOT to use a semi-colon value separator’, la 
documentation décrit justement le cas des cafés. Il y a deux propositions, je 
cite celle qui répond à ton intérêt  …

 

Split the element: Separate things out into separate nodes/ways to allow them 
to be tagged separately with normal tags. This is a good option where things 
are located in separate spatial locations anyway. Example: You're mapping a 
library which has a cafe inside it. Place a node for the cafe, and then either 
represent the library (a larger building) as an area instead, or just as a 
separate node for the different centrepoint of the library. It is not a good 
idea to map it as amenity=library;café

 

Cette option est régulièrement utilisée dans les centres commerciaux. 

 

Pour pousser le concept plus loin, il serait possible de lier le tout via une 
relation et de mettre l’adressage au niveau de la relation. Ce n’est cependant 
pas une approche fréquemment utilisée, mais je crois que c’est celle qui permet 
la vue la plus cohérente de la réalité…

 

Daniel

 

Voir …

 <http://wiki.openstreetmap.org/wiki/Relation> 
http://wiki.openstreetmap.org/wiki/Relation 

 

Puis  building sous… 

http://wiki.openstreetmap.org/wiki/Relation:building 

http://taginfo.openstreetmap.org/relations

 

 

From: Blanca Mancilla [mailto:bluc...@gmail.com] 
Sent: October-29-13 21:00
To: Daniel Begin
Cc: Pierre Béland; Pascal Robichaud; Bruno Remy; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Cartopartie le dimanche 27 octobre 2013

 

Mon point de vue c'est le suivant:

Si je veux faire une carte du cartier avec les cafés, je veux tous les cafés 
même si ces commerces sont aussi des boulangeries et cette dernière est 
l'activité la plus connue. Ou le commerce a commencé comme une boulangerie. 

Si on a juste un tag par POI, ma carte (ou les données correspondantes) ne 
contiendront pas tous les cafés. À ce moment là, je considérerais que la carte 
es fausse. 

Des suggestions?

bm

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

Re: [Talk-ca] Cartopartie le dimanche 27 octobre 2013

[Daniel Begin]

Bonjour Blanca,

 

Si je crois qu’un seul tag est généralement souhaitable, je ne vois pas 
pourquoi restreindre l’intérêt et la participation d’un contributeur pour cette 
raison, dans la mesure où il se conforme aux règles de la communauté.  Alors 
voici ce que je comprends des règles de la communauté OSM …

 

Il est possible d’utiliser le ‘;’ pour distinguer plusieurs valeurs pour un 
même tag (ref=* par exemple). 

 

Ce n’est cependant pas une pratique souhaitable si je me fie à la documentation 
suivante…

 

 <http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator> 
http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

 

Dans la section ‘When NOT to use a semi-colon value separator’, la 
documentation décrit justement le cas des cafés. Il y a deux propositions, je 
cite celle qui répond à ton intérêt  …

 

Split the element: Separate things out into separate nodes/ways to allow them 
to be tagged separately with normal tags. This is a good option where things 
are located in separate spatial locations anyway. Example: You're mapping a 
library which has a cafe inside it. Place a node for the cafe, and then either 
represent the library (a larger building) as an area instead, or just as a 
separate node for the different centrepoint of the library. It is not a good 
idea to map it as amenity=library;café

 

Cette option est régulièrement utilisée dans les centres commerciaux. 

 

Pour pousser le concept plus loin, il serait possible de lier le tout via une 
relation et de mettre l’adressage au niveau de la relation. Ce n’est cependant 
pas une approche fréquemment utilisée, mais je crois que c’est celle qui permet 
la vue la plus cohérente de la réalité…

 

Daniel

 

Voir …

 <http://wiki.openstreetmap.org/wiki/Relation> 
http://wiki.openstreetmap.org/wiki/Relation 

 

Puis  building sous… 

http://wiki.openstreetmap.org/wiki/Relation:building 

http://taginfo.openstreetmap.org/relations

 

 

From: Blanca Mancilla [mailto:bluc...@gmail.com] 
Sent: October-29-13 21:00
To: Daniel Begin
Cc: Pierre Béland; Pascal Robichaud; Bruno Remy; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Cartopartie le dimanche 27 octobre 2013

 

Mon point de vue c'est le suivant:

Si je veux faire une carte du cartier avec les cafés, je veux tous les cafés 
même si ces commerces sont aussi des boulangeries et cette dernière est 
l'activité la plus connue. Ou le commerce a commencé comme une boulangerie. 

Si on a juste un tag par POI, ma carte (ou les données correspondantes) ne 
contiendront pas tous les cafés. À ce moment là, je considérerais que la carte 
es fausse. 

Des suggestions?

bm

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

Re: [Talk-ca] Cartopartie le dimanche 27 octobre 2013

[Daniel Begin]

Pierre

 

Je comprends ton point de vue, et je le partage (du moins en partie). 
Cependant, je dis que nous faisons partie d’une communauté et que l’on devrait 
valider notre position avec celle des autres sur la planète avant de décider 
sur les façons de faire, ou de ne pas faire ici au Québec – et au Canada J

Daniel

 

From: Pierre Béland [mailto:pierz...@yahoo.fr] 
Sent: October-28-13 20:54
To: Daniel Begin; 'Pascal Robichaud'; 'Bruno Remy'
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Cartopartie le dimanche 27 octobre 2013

 

A mon avis, on ne doit indiquer que l'activité principale. Sinon on 
multiplierais à l'infini,
c'est un restaurant qui a un bar, qui a un comptoir de traiteur, qui vend des 
produits, 
c'est un musée qui a un restaurant, qui vend des livres, des cadeaux ... 
Et la carte deviendrait vite incompréhensible. 

 

 

Pierre 

  _  

De : Daniel Begin 
À : 'Pascal Robichaud' ; 'Bruno Remy' 
 
Cc : talk-ca@openstreetmap.org 
Envoyé le : Lundi 28 octobre 2013 19h42
Objet : Re: [Talk-ca] Cartopartie le dimanche 27 octobre 2013

 

C’est ce que j’ai constaté à de nombreuses reprises à plusieurs endroits au 
Québec. Mais avant d’aller plus loin, qu’en disent les abonnées de cette liste?

 

 <https://lists.openstreetmap.org/listinfo/tagging> 
https://lists.openstreetmap.org/listinfo/tagging

 

Daniel

 

 

From: Pascal Robichaud [mailto:pascal.robichaud.do...@gmail.com] 
Sent: October-28-13 18:44
To: Bruno Remy
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Cartopartie le dimanche 27 octobre 2013

 

Et si on mettait deux POI???

 

Pascal

 

Le 28 octobre 2013 18:37, Bruno Remy  a écrit :

Bonjour Blanca,

Normalement, il serait logique qu'un commerce ne soit relié qu'à une catégorie.

Un autre exemple c'est aussi le cas du café Olivieri qui est aussi une 
bibliothèque.

À mon avis, il faudrait y aller au cas-par-cas et "trancher" en choisissant 
l'activité principale du commerce: il y a toujours une des 2 activités qui est 
mise en valeur.

Par exemple, à Cap rouge, j'ai indiqué comme "bakery" une boulangerie/café 
parceque c'est une boulangerie traditionnelle avec des produits artisanaux de 
qualité, et c'est la seule de la ville. La fonction "café" n'est qu'une offre 
supplémentaire de restauration sur-place,

La même chose pour "Pascal le Boulanger à Stoneham qui est dans la même bâtisse 
qu'un Subway et un Tim Hortons: c'est le métier de boulanger qui fait la 
différence avec la concurrence. Il faut voir les points fort du commerce, et 
les produits pour lesquels il a une + grande réputation dans le quartier.

Autre chose: je me suis aperçu que le parc que j'avais cartographié ne s'est 
pas uploadé : je vais le refaire! Et aussi une petite surprise pour le Collège 
Notre-Dame ;)

Bruno

 

 

 

Le 28 octobre 2013 09:25, Blanca Mancilla  a écrit :

Au plaisir Bruno, et j’espère avoir une autre rencontre à Montréal, à Québec ou 
à Trois-Rivières!

Basées sur les données ramassées hier, je remarque que  il y a des commerce qui 
pourrait avoir un double tag? Par exemple, un des commerce est une boulangerie 
et un café.  Peut-on ajouter deux ou plusieurs tags au même POI?

---

Based on the data collected yesterday at the mapping party, I noticed that 
there is a POI which is both a bakery and a cafe. Can we add both tags? Is this 
common practice? 

bm

 

2013/10/27 Bruno Remy 

Bonjour,

Merci à Guillaume pour l'organisation,merci a Bianca pour son accueuil
sympathique.

Ce fut un plaisir de rencontrer votre équipe de Montréal!
On garde le contact! ;)

Au plaisir!

Bruno,
Contributeur de Québec




Le 26/10/2013, Guillaume Pratte a écrit :

> Bonjour,
>
> Le groupe OpenStreetMap Montréal souhaite vous convier à une cartopartie qui
> aura lieu le dimanche 27 octobre 2013, de 13h30 à 17h30.
>
> À cette occasion, nous nous réunirons afin d’effectuer l’inventaire des
> commerces et des principaux points d’intérêts du chemin de la
> Côte-des-Neiges, dans le quartier du même nom.
>
> Le tout débutera par un atelier d’introduction à OpenStreetMap, et se
> terminera par un atelier sur l’édition de la carte, une fois de retour après
> avoir effectué le sondage sur le terrain.
>
> Pour des raisons d’organisation nous souhaiterions connaître le nombre de
> personnes intéressées par cette activité à l’avance, aussi nous vous
> demandons dans la mesure du possible de vous inscrire ci-contre:
>
> https://www.eventbrite.ca/event/8706618731
>
> L’adresse exacte du lieu de rendez-vous - une résidence - sera communiquée à
> toute personne s’inscrivant.
>
> Si vous ne souhaitez pas vous inscrire ou que vous vous décidez à la
> dernière minute, nous vous donnons rendez-vous devant la sortie Sud de la
> station de métro Côte-

Re: [Talk-ca] Cartopartie le dimanche 27 octobre 2013

[Daniel Begin]

C’est ce que j’ai constaté à de nombreuses reprises à plusieurs endroits au 
Québec. Mais avant d’aller plus loin, qu’en disent les abonnées de cette liste?

 

  
https://lists.openstreetmap.org/listinfo/tagging

 

Daniel

 

 

From: Pascal Robichaud [mailto:pascal.robichaud.do...@gmail.com] 
Sent: October-28-13 18:44
To: Bruno Remy
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Cartopartie le dimanche 27 octobre 2013

 

Et si on mettait deux POI???

 

Pascal

 

Le 28 octobre 2013 18:37, Bruno Remy  a écrit :

Bonjour Blanca,

Normalement, il serait logique qu'un commerce ne soit relié qu'à une catégorie.

Un autre exemple c'est aussi le cas du café Olivieri qui est aussi une 
bibliothèque.

À mon avis, il faudrait y aller au cas-par-cas et "trancher" en choisissant 
l'activité principale du commerce: il y a toujours une des 2 activités qui est 
mise en valeur.

Par exemple, à Cap rouge, j'ai indiqué comme "bakery" une boulangerie/café 
parceque c'est une boulangerie traditionnelle avec des produits artisanaux de 
qualité, et c'est la seule de la ville. La fonction "café" n'est qu'une offre 
supplémentaire de restauration sur-place,

La même chose pour "Pascal le Boulanger à Stoneham qui est dans la même bâtisse 
qu'un Subway et un Tim Hortons: c'est le métier de boulanger qui fait la 
différence avec la concurrence. Il faut voir les points fort du commerce, et 
les produits pour lesquels il a une + grande réputation dans le quartier.

Autre chose: je me suis aperçu que le parc que j'avais cartographié ne s'est 
pas uploadé : je vais le refaire! Et aussi une petite surprise pour le Collège 
Notre-Dame ;)

Bruno

 

 

 

Le 28 octobre 2013 09:25, Blanca Mancilla  a écrit :

Au plaisir Bruno, et j’espère avoir une autre rencontre à Montréal, à Québec ou 
à Trois-Rivières!

Basées sur les données ramassées hier, je remarque que  il y a des commerce qui 
pourrait avoir un double tag? Par exemple, un des commerce est une boulangerie 
et un café.  Peut-on ajouter deux ou plusieurs tags au même POI?

---

Based on the data collected yesterday at the mapping party, I noticed that 
there is a POI which is both a bakery and a cafe. Can we add both tags? Is this 
common practice? 

bm

 

2013/10/27 Bruno Remy 

Bonjour,

Merci à Guillaume pour l'organisation,merci a Bianca pour son accueuil
sympathique.

Ce fut un plaisir de rencontrer votre équipe de Montréal!
On garde le contact! ;)

Au plaisir!

Bruno,
Contributeur de Québec




Le 26/10/2013, Guillaume Pratte a écrit :

> Bonjour,
>
> Le groupe OpenStreetMap Montréal souhaite vous convier à une cartopartie qui
> aura lieu le dimanche 27 octobre 2013, de 13h30 à 17h30.
>
> À cette occasion, nous nous réunirons afin d’effectuer l’inventaire des
> commerces et des principaux points d’intérêts du chemin de la
> Côte-des-Neiges, dans le quartier du même nom.
>
> Le tout débutera par un atelier d’introduction à OpenStreetMap, et se
> terminera par un atelier sur l’édition de la carte, une fois de retour après
> avoir effectué le sondage sur le terrain.
>
> Pour des raisons d’organisation nous souhaiterions connaître le nombre de
> personnes intéressées par cette activité à l’avance, aussi nous vous
> demandons dans la mesure du possible de vous inscrire ci-contre:
>
> https://www.eventbrite.ca/event/8706618731
>
> L’adresse exacte du lieu de rendez-vous - une résidence - sera communiquée à
> toute personne s’inscrivant.
>
> Si vous ne souhaitez pas vous inscrire ou que vous vous décidez à la
> dernière minute, nous vous donnons rendez-vous devant la sortie Sud de la
> station de métro Côte-des-neiges à 13h15 précises. Note: il s’agit de la
> sortie près du café Starbuck:
>
> http://www.openstreetmap.org/?mlat=45.49634 
> 
>  &mlon=-73.62245#map=19/45.49634/-73.62245
>
> N’oubliez pas de vous vêtir en fonction de la température, car l’activité
> aura lieu beau temps, mauvais temps. Fort heureusement, la météo annonce du
> beau temps! En cas de forte pluie, nous tiendrons les ateliers prévus à
> l’intérieur.
>
> SI vous décidez de vous joindre à nous, voici le matériel que nous suggérons
> d'apporter. Considérez que tout item dans cette liste est facultatif:
>
> - ordinateur portatif afin d’entrer les données dans la carte, une fois le
> sondage terrain effectué (recommandé);
> - appareil photo pour aider à la prise de notes lors du sondage terrain
> (celui intégré à un téléphone intelligent est amplement suffisant);
> - téléphone intelligent ou tablette, pour aider à l’entrée de données en
> temps réel;
> - un calepin et un crayon pour prendre des notes (des cartes imprimées
> seront fournies);
> - parapluie, en cas de besoin.
>
>
> Au plaisir,
>
> Guillaume Pratte pour OpenStreetMap Montréal
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.ope

Re: [Talk-ca] Larder Lake, Ontario completely missing

[Daniel Begin]

Hi Steve,
You wrote that one of the hardest parts was to figure out what set to
download from Canvec ftp site...

There was a link in the Canvec Wiki page to find out what file to download
(using the NTS map number like 021E05) but it is broken now.  I found
another way to find it out. Go to...

http://atlas.nrcan.gc.ca/site/english/toporama/index.html#

Use the Toggle NTS Grid (grey icon next to the map scale) to make the NTS
grid visible
Zoom-in on your area of interest, the NTS map number displayed fits the file
available from the Canvec ftp site 
(NTS 21e5 is file 021E05.zip).

Daniel

-Original Message-
From: Steve Roy [mailto:st...@ssni.ca] 
Sent: October-02-13 10:35
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Larder Lake, Ontario completely missing

When I initially started adding to/editing OSM maps it was roads and trails
from my GPS data.  However in BC there are large areas where there is
nothing on the map - so after finding this:
http://wiki.openstreetmap.org/wiki/Canvec#Canvec_Product_-_Datasets
I managed to d/l some tile sets from CanVec, added some roads, lakes,
streams etc using Potlatch 2.  I kept notes on what tiles from each set I
had imported and make the edits as time allowed.

It's probably slower than using JOSM, but I found it easier to use.

One of the hardest parts (for me) is to figure out what set to d/l from
http://ftp2.cits.rncan.gc.ca/OSM/pub/

So my question is:  Using Potlatch 2, what is the best/easiest way to figure
out what set to d/l?  Using the original question of the Larder Lake area in
Ontario how would I get this info?
Or if someone was to give me a GPS coordinate how could i find the tile set
for that area?

Thanks
Steve

___
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] App for mapping running/cycling itineraries/routing

[Daniel Begin]

Bonjour Yves,
Il y a toujours moyen d'utiliser le tag "ele=*" (
http://wiki.openstreetmap.org/wiki/Key:ele ) sur chaque coordonnée d'intérêt
mais pour ce qui est de faire apparaître la valeur aux intersections, c'est
plus une question liée au programme de rendu (rendering)...

Daniel


-Original Message-
From: Yves Moisan [mailto:ymoi...@videotron.ca] 
Sent: August-18-13 17:18
To: Gregory
Cc: talk-ca
Subject: Re: [Talk-ca] App for mapping running/cycling itineraries/routing


>
>
> Z-data (or elevation data) isn't generally stored in OSM. It can kind 
> of work for points (especially peaks) but doesn't so much for ways.
> Map renderings (e.g. OpenCycleMap.org) or routing (e.g. 
> CycleStreets.net) tend to supplement OSM data with SRTM data for 
> elevation. There's a lot of information and help available on mixing 
> SRTM with OSM.
> http://wiki.openstreetmap.org/wiki/Srtm
Thanx Greg.  IIRC, SRTM is raster data with a pixel with at best 90 X 90 m.
Even if it were 30 X 30 m, it would still be quite coarse for a running
path.  Strava.com is overkill for my needs.  For the altitude, all I'm
interested in really is a way to tag altitudes to vertices of 
locations I know and have them show up as a cross section.   Thanx for 
your pointers.

Yves

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


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

Re: [Talk-ca] Canvec-OSM FTP Down?

[Daniel Begin]

The links in the wiki (Canvec) is now corrected…

Daniel

 

From: François Paquette [mailto:fpaque...@cooptel.qc.ca] 
Sent: July-20-13 18:18
To: 'Daniel Begin'; 'Adam Dunn'; 'talk-ca'
Subject: RE: [Talk-ca] Canvec-OSM FTP Down?

 

Try with

 

 <http://ftp2.cits.rncan.gc.ca/OSM/pub> http://ftp2.cits.rncan.gc.ca/OSM/pub

 

The FTP site is case sensitive

 

François

 

De : Daniel Begin [mailto:jfd...@hotmail.com] 
Envoyé : 20 juillet 2013 18:12
À : 'Adam Dunn'; 'talk-ca'
Objet : Re: [Talk-ca] Canvec-OSM FTP Down?

 

Bonjour Adam,

I tried to access the site about a week ago without success. I was hoping
the problem was temporary but I now worried…

 

Daniel

 

From: Adam Dunn [mailto:dunna...@gmail.com] 
Sent: July-20-13 15:46
To: talk-ca
Subject: [Talk-ca] Canvec-OSM FTP Down?

 

Just tried to download a tile from http://ftp2.cits.rncan.gc.ca/osm/pub and
the server is saying the directory doesn't exist. Hopefully just a temporary
thing, but does anybody know what's going on?

 

Adam

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

Re: [Talk-ca] Canvec-OSM FTP Down?

[Daniel Begin]

Bonjour Adam,

I tried to access the site about a week ago without success. I was hoping
the problem was temporary but I now worried.

 

Daniel

 

From: Adam Dunn [mailto:dunna...@gmail.com] 
Sent: July-20-13 15:46
To: talk-ca
Subject: [Talk-ca] Canvec-OSM FTP Down?

 

Just tried to download a tile from http://ftp2.cits.rncan.gc.ca/osm/pub and
the server is saying the directory doesn't exist. Hopefully just a temporary
thing, but does anybody know what's going on?

 

Adam

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

Re: [Talk-ca] Using OpenStreetMap on a daily basis

[Daniel Begin]

Completely agreed...
Daniel

-Original Message-
From: Matthew Buchanan [mailto:matthew.ian.bucha...@gmail.com] 
Sent: July-09-13 12:04
To: OSM Talk-ca
Subject: Re: [Talk-ca] Using OpenStreetMap on a daily basis

I have been using OSM for a couple years now (coming up on 1000
changesets!) and this is the first I've heard of the OSMR website.
Most new users will probably go to http://www.openstreetmap.org/ and not go
any farther. I think the default page  needs to be revamped and the default
renderer improved.

I agree with all of Guillaume's 4 points.

My biggest pet peeve is that trunk roads are green when they should be red,
primary roads should be dark orange.

-- Matthew Buchanan
-- Kamloops, BC



On Tue, Jul 9, 2013 at 8:55 AM, Harald Kliems  wrote:
> OpenStreetBrowser offers routing and clickable POIs. Higher zoom 
> levels were experimentally implemented on a server by the French OSM 
> community but I think it is no longer online. I can't remember the 
> URL, but you should be able to find the related discussion in the 
> archives of the general talk list (search for z19). Mapquest might also do
some of the things requested.
>
> With regards to what OSM and the OSM homepage are or aren't : Bernie 
> certainly has expressed one view that is widely held in the community. 
> But there are other positions as well, evidenced by the fact that 
> discussions like the one in this thread keep popping up.
>
> Harald (who is also sad that for his everyday geodata needs he often 
> ends up using Google)
>
>
> On Tuesday, July 9, 2013, Connors, Bernie (SNB) 
> 
> wrote:
>> Guillaume,
>>
>> IMHO all of your issues could be solved with applications of 
>> the OSM data.  The goal of OSM is to create an open data set that can 
>> be used by anybody to solve all of the issues in your list.  The goal 
>> of OSM is not to create a replacement for the Google Maps website but 
>> to create an alternative to the Google Maps data.  All of your issues 
>> could be addressed with OSM data and some programming.  I expect some 
>> or all of your issues have already been addressed.  For example the 
>> OSMR website is great for routing and driving directions - 
>> http://map.project-osrm.org/
>>
>> Let's hear from the rest of the OSM talk-ca community.  Who 
>> has suggestions for Guillaume's other issues?
>>
>> Bernie.
>>
>> -Original Message-
>> From: Guillaume Pratte [mailto:guilla...@guillaumepratte.net]
>> Sent: Tuesday, 2013-07-09 1:42 AM
>> To: talk-ca@openstreetmap.org OpenStreetMap
>> Subject: [Talk-ca] Using OpenStreetMap on a daily basis
>>
>> Hello,
>>
>> I have been a serious user of OpenStreetMap for less than six months, 
>> and I am proud to recently have achieved my one hundredth 
>> contribution to the project. I really love the OpenStreetMap project, 
>> and I would like to replace my daily usage of Google Maps with
OpenStreetMap.
>>
>> But it just seems I cannot. Anybody else feel the same issues?
>>
>> I'll give a few concrete examples why, humbly hoping that my words 
>> can encourage changes to the main website.
>>
>> First point: searching. I have OpenStreetMap zoomed in to some region 
>> of Montreal, Canada. I input "café", looking for a coffee shop. I get 
>> results from Nominatim, inviting me to visit a village in Brazil 
>> named "Café" or even the "Café point" in Antarctica. While these 
>> search results awaken my globetrotter's desire to explore the world, 
>> they frustrate me at the same time. Why couldn't Nominatim priorize 
>> results from the bounding box or surrounding? Why can't OpenStreetMap 
>> show me results on the map like the OverPass API does, performing a 
>> search on the tag amenity=cafe and showing the results on the map?
>>
>> Second point: accessing POI information. I cannot click on point of 
>> interests (POI) to get more info about them. Why do we input address, 
>> business hours and phone numbers on shops and restaurants if the map 
>> cannot easily display this information to the user? Why do I have to 
>> show the map's data in order to have information on a point of interest?
>>
>> Third point: maximum zoom level. Some area are densely populated, and 
>> OpenStreetMap's current zoom level is not enough to see all details 
>> of the map. This is really unfortunate. Example: 
>> http://osm.org/go/cIrNs6Qzp-- What are the restaurant surrounding the 
>> Hard Rock Café on this map? I have to use the editor to be able to zoom
and see all data.
>>
>> Fourth point: sharing a point of interest. There should be an easy 
>> way to do that. I have found a (complicated) way to do it, which is 
>> all but obvious to newcomers. Here is how:
>>
>> . Using the layer icon at the top right of the map, I select 
>> "Browse Map Data";
>> . I select the object I want to share (which is not always 
>> possible; sometimes it is "hidden" behind a residential area or similar);
>> . I click on "Details"
>> . On the resulting page,

Re: [Talk-ca] Importations Canvec

[Daniel Begin]

The last time I heard about NRCan it was the case. 
Daniel

-Original Message-
From: Tom Taylor [mailto:tom.taylor.s...@gmail.com] 
Sent: June-24-13 13:18
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importations Canvec

One point occurs to me. I seem to recall reading in the Canvec documentation
that if we find Canvec in error we should report back to them.

TomT5454
Tom Taylor

On 24/06/2013 10:57 AM, Daniel Begin wrote:
> Bonjour dega,
>
> Comme l'écrivait Pierre... "Les imports Canvec, tout comme les traces 
> GPS, ce sont des outils pour compléter la carte, mais il ne faut pas 
> les utiliser aveuglément".
>
> En 2009, Frank Steggink a écrit: "I think that 'Libérer le trésor' 
> (liberate the treasure) is an excellent slogan for the Canvec import". 
> Beau slogan pour un 24 Juin!
> http://lists.openstreetmap.org/pipermail/talk-ca/2009-December/001987.
> html
>
> Pour ce qui des tags qui accompagnent les données importées, il n'y a 
> pas de raisons pour les conserver comme le confirme Steve. 
> Personnellement, je ne conserve que le tag source lorsque l'imagerie 
> Bing ne me permet pas de confirmer la géométrie de l'objet.
>
> Daniel
>
>
...

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


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

Re: [Talk-ca] Importations Canvec

[Daniel Begin]

Bonjour dega,

Comme l'écrivait Pierre... "Les imports Canvec, tout comme les traces GPS,
ce sont des outils pour compléter la carte, mais il ne faut pas les utiliser
aveuglément". 

En 2009, Frank Steggink a écrit: "I think that 'Libérer le trésor' (liberate
the treasure) is an excellent slogan for the Canvec import". Beau slogan
pour un 24 Juin!
http://lists.openstreetmap.org/pipermail/talk-ca/2009-December/001987.html

Pour ce qui des tags qui accompagnent les données importées, il n'y a pas de
raisons pour les conserver comme le confirme Steve. Personnellement, je ne
conserve que le tag source lorsque l'imagerie Bing ne me permet pas de
confirmer la géométrie de l'objet.

Daniel



-Original Message-
From: Paul Norman [mailto:penor...@mac.com] 
Sent: June-23-13 20:47
To: 'Steve Singer'; 'dega'
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importations Canvec

> From: Steve Singer [mailto:st...@ssinger.info]
> Sent: Sunday, June 23, 2013 4:03 PM
> Cc: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Importations Canvec
> 
> (what I hope I am saying is) I think current practices say that it is 
> acceptable to remove the source, attribution and UUID tags when 
> modifying objects. Recent imports have been excluding this type of tag 
> from objects when discussed on impo...@openstreetmap.org

JOSM, P2 and iD should all remove UUID tags automatically when modifying an
object.

I normally remove NHN/NRN attribution tags because they duplicate the source
tag. For source, I try to consider if the source tag will be helpful to the
next mapper. If all I did was a topology fix or something small I'll
probably leave it, but if I was out there, verified the name and refined the
position, I'll probably remove the source tag as it's no longer accurate. It
depends if I feel that the source tag still accurately represents the
source. Note that this is not a legal distinction about derivative works,
there are no legal issues which prevent the removal of any tag, it is purely
what is useful to have tagged.


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


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

Re: [Talk-ca] Licence fédérale et Défi GéoHack de Mtl

[Daniel Begin]

Nicolas,

 

Pour être vraiment claire, l’utilisation de références (comme celles que tu
mentionnes) aurait certainement un apport considérable. L’utilisation de
pictogrammes est aussi d’un grand support.

 

Concernant les données de type BY produites par l’agence ‘A’, importées dans
OSM, puis récupérées par ‘A’ : À mon point de vue, l’intégration peut être
faite mais avec certaines restrictions.  Voici pourquoi…

 

La donnée ouverte de ‘A’ (BY) est importée dans OSM.

Une fois importée dans OSM la donnée devient  ODbL (BY-SA)

‘A’ récupère ‘ses’ données de la BD OSM

Les données récupérées sont cependant toujours ODbL (BY-SA)!

 

‘A’ peut donc les intégrer à son produit et rendre le produit disponible,
mais avec potentiellement deux licences! La raison? Le produit de ‘A’
contient des données de type BY, et des données de type BY-SA.

 

‘A’ doit donc distribuer ses données avec une licence spécifique à l’origine
de chaque objet (BY ou BY-SA);  ou ‘A’ tout distribuer  avec une licence de
type BY-SA. C’est le concept des licences virales (SA).

 

Autre niveau de complexité : Une entreprise ne pourra pas vendre une version
à valeur ajoutée des données de type BY-SA (obtenues de ‘A’) sans en rendre
une version disponible à la communauté sans frais (à confirmer?). Ceci
toujours en raison de la composante SA de la licence attachée aux données
récupérées de la BD OSM.

 

The devil is in the details!

 

Daniel

 

 

 

 

 

From: Nicolas Gignac [mailto:gignac...@gmail.com] 
Sent: June-20-13 23:05
To: Daniel Begin
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Licence fédérale et Défi GéoHack de Mtl

 

Merci Daniel, mais justement, le bout de la licence de la ville de Montréal
qui la lie à des licences mondiales bien connues du milieu ne devrait-il pas
faire partie du texte des licences ? Justement pour que les "communs des
mortels" puissent encore plus se référer à quelque chose de commun au lieu
de faire des suppositions ou interprétations ? La clarté complète me semble
une nécessité ici.

Autre chose, même si je ne veux pas un avis juridique, si l'attribution y
est inscrite (ex. aux contributeurs OSM) dans Canvec (ou toute autre données
ouvertes en BY d'une administration publique), cela peut être récupéré de
façon légale et être recontribué dans Canvec ? Ce qui fait que ces deux
licences seraient pleinement compatibles et qu'elles permettent la
collaboration complètes entre OSM et la récupération de ces données (avec la
condition de l'attribution) dans les portails de données ouvertes
d'administration publique par la suite ? Une autre nécessité de clarté ici,
mais peut-être que le projet Geothink.ca pourra y répondre, si on en es
incapable...

Clairement vôtre,


Nicolas

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

Re: [Talk-ca] Licence fédérale et Défi GéoHack de Mtl

[Daniel Begin]

Bonjour Nicolas,

 

La nouvelle licence me semble très similaire à la précédente (celle qui a
permis l’import des données Canvec) mais semble écrite pour être plus
lisible par le commun des mortels! Je comprends que c’est une licence de
type BY (attribution), tout comme la précédente.

 

Pour ce qui est de la récupération des mises à jour apportées aux données
Canvec dans OSM, cette utilisation est gérée par la licence ODbL
d’OpenStreetMap (de type BY-SA), pas par la nouvelle licence actuelle, ni
par la précédente de NRCan.

 

Je ne suis pas avocat, alors mes commentaires sont à prendre avec un grain
de sel!

 

Daniel

 

From: Nicolas Gignac [mailto:gignac...@gmail.com] 
Sent: June-20-13 19:47
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Licence fédérale et Défi GéoHack de Mtl

 

La nouvelle licence des données ouvertes du gouvernement fédéral est sortie
officiellement cette semaine :
http://donnees.gc.ca/fra/licence-du-gouvernement-ouvert-canada

Comme il y aura d'autres provinces et territoires qui devraient suivre son
adoption, est-elle compatible avec celle les données OSM ? 
Est-ce qu'avec cette licence le gouvernement fédéral peut réutiliser les
modifications de leur données mises dans OSM (ex. routes de GoBase) et
redistribuer (ces mêmes routes GeoBase modifiées par OSM) sous cette licence
? Manque-t-elle de clarté ? Celle de la ville de Montréal avec son ajout de
clarté : "Elle est similaire à une licence Creative Commons CC-BY. Par
exemple, elle est compatible avec les licences de type ODbl plus
restrictives telles que celle d’OpenStreetMap." ne devrait pas être un
standard au Canada ?

Autres informations complémentaires, un Défi GéoHack s'organise le 2 octobre
prochain à Montréal : http://defigeohackmtl.org/ Restez aux aguets, les
détails des inscriptions et l'appel aux contributeurs seront publiés
prochainement.

Au plaisir,

Nicolas Gignac
ca.linkedin.com/pub/nicolas-gignac/20/690/a42/

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

Re: [Talk-ca] Licence des données ouvertes de la Ville de Montréal

[Daniel Begin]

Bonjour à vous tous,

 

Seraient-ils ouverts à la solution utilisée pour NRCan, GeoBase, etc…? 

C'est-à-dire citer ces sources dans la page  
 
http://wiki.openstreetmap.org/wiki/Attribution ?

 

Daniel

 

From: Bruno Remy [mailto:bremy.qc...@gmail.com] 
Sent: June-14-13 16:56
To: Guillaume Pratte
Cc: talk-ca@openstreetmap.org OpenStreetMap
Subject: Re: [Talk-ca] Licence des données ouvertes de la Ville de Montréal

 

Bonjour Fabian, bonjour Guillaume, 

Quel est le fruit de vos discutions avec Montreal Ouvert?
Ici à Québec, nous avons, et à plusieurs reprises, tenté des approches avec 
Capitale Ouverte (les gens qui ont créé Quebwc Ouvert conjointement avec les 
représentants de Montreal Ouvert.
Malheureusement, on a frappé un mur: ils sont "fermés" sur leur position et 
nous ont fait savoir, de plusieurs manieres et à plusieurs reprises, que nous 
"devions citer nos sources" (sic) si jamais nous utilisions les données 
ouvertes de la ville. Alors que c'est justement contre cette obligation de 
citation que nous nous battons!
La situation est donc un "dialogue de sourds" et nous sommes en impasse...

Situation bien regrettable à mon humble avis...

Bruno Remy

Le 2013-06-13 21:54, "Guillaume Pratte"  a écrit 
:

(This email concerns the legal licence of the open data of the City of Montreal 
and as such, will be in French only.)

 

Bonjour,

 

Vous savez certainement que la Ville de Montréal offre un ensemble très 
intéressant de données ouvertes. Certains fichiers de données sont d'un intérêt 
particulier pour OpenStreetMap. Notons entres autres:

 

- Les jardins communautaires:

http://donnees.ville.montreal.qc.ca/fiche/jardins-communautaires/

- Les arbres:

http://donnees.ville.montreal.qc.ca/fiche/arbres/

- Les parcs:

http://donnees.ville.montreal.qc.ca/fiche/grands-parcs/

- Les cours d'eau:

http://donnees.ville.montreal.qc.ca/fiche/limites-cours-eau/

- L'accessibilité des bâtiments municipaux (pensez wheelmap.org):

http://donnees.ville.montreal.qc.ca/fiche/batiments/

 

Le problème, c'est que la licence ( 
http://donnees.ville.montreal.qc.ca/licence/licence-texte-complet/ ) sous 
laquelle ces données sont offertes (la version de février 2013) n'est pas 
compatible avec OpenStreetMap. 

 

J'avais écris à la Fondation OpenStreetMap à ce sujet. Voici ce qu'on m'a 
répondu:

 

You can combine 3rd party with ODbL if it is equally or less restrictive.

In general the license you refer to is an Attribution-only license and

therefore not more restrictive than ODbL. However, the attribution

requirements itself (Point 4) are more restrictive than those from

ODbL. You should there approach the data owners and seek the permission.

 

Je ne suis pas un expert légal, et je ne peux que conjecturer sur ce qu'il 
faudrait changer précisément dans la licence de la Ville pour la rendre 
compatible à OSM. 

 

À ma (faible) compréhension actuelle du dossier, la licence de la Ville exige 
d'écrire un texte d'environ 5 ligne sur tout "produit dérivé" des données 
offertes par la Ville (pont 4.2). À ma compréhension, les tuiles de la carte 
OSM constitueraient un "produit dérivé", et il est clair que le texte de 5 
lignes ne pourrait pas être inscrit sur le rendu de la carte OSM. Et ce n'est 
probablement pas la seule incompatibilité.

 

J'aimerais avoir votre avis, et aller au fond des choses. Y-a-t-il sur cette 
liste une personne qui aurait une vision claire de ce qu'il faudrait demander à 
la Ville afin de pouvoir importer ses données dans OpenStreetMap?

 

On peut prendre pour exemple les licences des villes canadiennes de Surrey, de 
Toronto, et de la région de Waterloo, qui sont plus simples que la licence de 
Montréal, et qui sont compatibles avec OpenStreetMap:

 

http://wiki.openstreetmap.org/wiki/Contributors#Canadian_Municipalities

 

- Les données de Surrey sont sous la PDDL: 
http://opendatacommons.org/licenses/pddl/

- Licence de Toronto: 
http://www1.toronto.ca/wps/portal/contentonly?vgnextoid=4a37e03bb8d1e310VgnVCM1071d60f89RCRD

- Licence de la Région de Waterloo: 
http://www.regionofwaterloo.ca/en/regionalGovernment/OpenDataLicence.asp

 

Mon objectif est de faire une demande de données ouvertes ( 
http://donnees.ville.montreal.qc.ca/ddo/ ) afin de faire modifier la licence, 
ou, en alternative, demander à ce que les jeux de données soit publiés en 
double licence Ville de Montréal et ODbL.

 

Qu'en pensez-vous?

 

Merci et au plaisir,

 

Guillaume Pratte


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

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

Re: [Talk-ca] Out of date or incomplete NRCan-CanVec-7.0 data

[Daniel Begin]

Bonjour Tony,

You are right about the fact that NRCan data is out of date. To have an idea
on how out-of-date it is, the latest version of Canvec has a text file that
gives these specific details for each map (metadata.txt). This file is
included within each Canvec .zip file. See.

 

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

http://wiki.openstreetmap.org/wiki/CanVec:_Metadata

 

You wrote: "Does it serve any useful purpose?   Is it safe to delete that
polygon or will it come back on some re-import in the future?"

 

There is no automatic import. Someone like you has decided to import the
data some time ago. You can remove it if you wish - but then deleting the
work done by someone else - or better: why don't you update the polygon to
reflect the actual residential area as it is today?

 

Best

Daniel

 

 

From: Tony Toews [mailto:t...@tonytoews.com] 
Sent: March-02-13 22:09
To: talk-ca
Subject: [Talk-ca] Out of date or incomplete NRCan-CanVec-7.0 data

 

Folks

I'm just a casual editor who cleans up things I know first hand in a few
small towns and a small city.So I went to Landmark, Manitoba and saw an
interesting, irregularly shaped out-of-date/incomplete polygon that was
added.  I don't recall seeing it when I last visited there several months
ago but who knows.

Residential Area - Source - NRCan-CanVec-7.0

This appears to display a shaded area on the user viewable map. 

The problem is that this is very much out of date or incomplete.
Furthermore, for that village/hamlet it's mostly nonsense.   Main street,
which is the highway running north/south through Landmark is the
commercial/industrial road through town although there are houses
interspersed among the retail and commercial buildings and feed mill.
Furthermore the residential area goes 1.5 blocks west and a few blocks east.
So it might as well not even exist.

Now judging on my memories of that village/hamlet it is probably at least
ten years out of date.

 Does it serve any useful purpose?   Is it safe to delete that polygon or
will it come back on some re-import in the future.   

Tony

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

Re: [Talk-ca] Sidewalks

[Daniel Begin]

Bonjour  all

To add my comments on this topic, I never add "ordinary" sidewalks except if
they are "physically" separated from the street (not adjacent to). If I had
to map them, I would use sidewalk:* tags.

I still think as Richard wrote: "I have roads and other things to map; I'll
worry about sidewalks later". However, having this sidewalk wonderings only
means is that the map is really getting detailed!

 

Cheers,

Daniel

 

From: Richard Weait [mailto:rich...@weait.com] 
Sent: February-02-13 06:15
To: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Sidewalks

 

On Fri, Feb 1, 2013 at 4:08 PM, nicholas ingalls
 wrote:

My personal preference is to enable the JOSM sidewalk style and then use the
sidewalk:right sidewalk:left, sidewalk:both, or sidewalk:none tags on the
actual street. The footpaths are just about useless (as in the example
above) as they are not related to the street in anyway. So the routing
engine couldn't say turn left onto Maple Street. It could only  say turn
left. If the tags are on the actual street and not separately mapped, it is
much easier for a routing engine.

 

I think Bernie has raised an interesting question with a complicated group
of replies.  I don't think that we will find One Universally True Answer.  

As a mapper, I don't always add "ordinary" sidewalks where I see them.
Initially, I thought, "I have roads and other things to map, I'll worry
about sidewalks later."  It was the early days of OSM.  Available aerial
imagery was much more limited and much lower resolution.  When higher
resolution aerial imagery became available to us, I had a bit of a "freak
out".  "Oh my!!! Look at all the PIXELS!!!  I can map sidewalks, and, and,
and, and, everything!!!"  And so I did.  I added sidewalks in some of the
places that already had roads and schools and parks and rivers, etc.  

Now, I'm not as consistent, I guess.  I'll add interesting walkways that
aren't simply parallel to a street.  I think adding a pedestrian path
between neighbourhoods, and adjacent, non-adjoining streets is worthwhile.
As a pedestrian, I use those paths to cut the walking distance to the store,
or school.  But I generally don't add the ordinary sidewalks.  Except when I
do add them.  

The points raised by Gordon and Harald, above, are important.  There are
routing services for pedestrians and cyclists and they can use
separately-drawn sidewalks in ways that they can not extract data from road
centerline parameters.  I make an effort to properly connect new objects
that I map with existing sidewalks, even if I'm not planning to map more
sidewalks immediately.  

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

Re: [Talk-ca] GPS inaccuracy

[Daniel Begin]

Tom wrote: " I'm getting the feeling that, short of a definitive survey, a 
good map is a matter of careful judgement."

I was involved in map business for almost 30 years and I met just a few
people that could have said that in such simple terms!

Thank you
Daniel

-Original Message-
From: Tom Taylor [mailto:tom.taylor.s...@gmail.com] 
Sent: November-20-12 22:42
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] GPS inaccuracy

I redid some of my survey yesterday following Pierre and Bernie's 
suggestions. The results are more reasonable. After averaging, some of 
my points were showing error of +/- 2 m or less.

In working on the new trace, I learned to shift the Bing images as 
necessary. Then I found that some buildings fit Bing while neighbours 
did not. I'm getting the feeling that, short of a definitive survey, a 
good map is a matter of careful judgement.

I suspect at this point I should be writing on the Newbies list rather 
than this one. Thanks for your tolerance to this point. Certainly I'll 
still be monitoring this list.

Tom taylor

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


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

Re: [Talk-ca] Primacy of GPS Traces (was Re: Internal CanVecconflicts)

[Daniel Begin]

Agreed about GPS behaviour,

 

and do not take for grant your 3m accuracy. I got 3m accuracy measurement on
my GPSmap 60CSX but a much larger differences looking at my traces, with the
same device, the same track, same day, but under different meteorological
condition.  Multiple tracks are always better.

 

Daniel

 

  _  

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: November-15-12 12:29
To: Tom Taylor; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Primacy of GPS Traces (was Re: Internal
CanVecconflicts)

 

Tom 

I have a Garmin Etrex HCX.  I had the opportunity to compare my results
while hiking with a  friend wich has a Garmin GPSMAP 62. The antennas seems
to make the difference, especially when there is a coverage in forests.  

Even with the same brand you may notice differences. When opening the GPS,
it is important to give it at least 5 minutes to finish is procedure of
initialization. And it is worse if you move to an other continent. It takes
more time to negociate with satellites and control precisely your position.
I had a nice experience this summer in south Africa. We had seven Etrex
arriving from Indonesia and Canada.  It took ten minutes to see all of them
coming to a three meters precision. And, they were not adjusting all at the
same speed.

I see that you already uploaded a trace. You simply use this as background
to trace in editor such as JOSM. If you trace from this trace, you simply
add source=GPS. This can be added to the Changeset instead of each object
you trace.

 

Pierre 

  _  

De : Tom Taylor 
À : Harald Kliems  
Cc : talk-ca@openstreetmap.org 
Envoyé le : Jeudi 15 novembre 2012 8h38
Objet : [Talk-ca] Primacy of GPS Traces (was Re: Internal CanVec conflicts)


As a geocacher, I'm unhappily aware that different brands of GPS give
different results, with differences in the order of 10 meters for an
individual point. I suppose a track should be better, since there is an
internal consistency check, though not if the difference is due to systemic
causes. As it happens, in this case I had my own GPS trace to work with, and
it aligned reasonably well with the Bing image of the path I was following.

One thing I'm not sure of: were my GPS traces uploaded with the edits, or
did I have to do something special to upload them?

On 15/11/2012 8:20 AM, Harald Kliems wrote:
> Hi Tom:
> welcome to OSM and congratulations on your first edits! Yes, it sounds
> like you did the right thing. One thing to look out for: Bing images
> are not always aligned 100% -- they can be offset by several meters.
> Usually this is not a problem but if there are any GPS traces
> available in your area you (most likely to be found along major roads)
> you can use those to make sure that the imagery is not off. In JOSM
> you get the GPS traces by checking the "Raw GPS data" box in the
> Download window.
> Happy editing,
>  Harald.
> 
...

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



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

Re: [Talk-ca] Internal CanVec conflicts

[Daniel Begin]

Hi all, 

just in case you forgot, there is a metadata.txt file included with each
Canvec .zip file. Usually, all layers having the same validity date range
are internally consistent with each others.

You should have a look if you are concerned by inconsistencies.

Au cas ou vous auriez oublié, il y a un fichier de métadonnées qui
accompagne chaque fichier .zip du produit Canvec. Normalement, toutes les
couches ayant les mêmes dates de validité sont cohérentes entre elles.

Vous devriez y jeter un coup d'œil si la cohérence des données vous
intéresse.

Daniel

-Original Message-
From: Dan Charrois [mailto:d...@syz.com] 
Sent: November-11-12 02:47
To: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Internal CanVec conflicts

> "Is it the communities view that it is okay to import CanVec without
> reconciling the internal differences between the layers?"
> 
> I believe it is.  The great thing about OSM data is it is not written in
> stone.  An import or edit can be changed in the future.  The data is
> inserted for use by anyone.  Just because I upload the CANVEC does not
mean
> it is required to stay there as is.I don't believe an import has to be
> perfect, especially in massively expansive areas natural areas which
remain
> in a constant state of flux.   This cannot be accurately determined via
Bing
> or ANY source we have.  Rivers change course each year, often several
times.
> They flood timber, often for short periods of time. Which raises another
> question...how do we determine what timber is?  Is it trees?  Brush?
Mixed
> wood?  A forester would say all of the above.  Muskeg?  Swamp? Bog?
Anyone
> here qualified to make that decision?   That island in your example?  It
has
> brush on it.  But it might not in the spring.  The whole island might not
be
> there in the spring.  But it's there right now.  


As a fellow Canvec importer, I wanted to weight in on this discussion with
my opinion as well.

I agree with Bryan's viewpoint.  In an ideal world, it would be great if we
could process an area of Canvec data and be able to say that it absolutely
and accurately reflects a current reflection of reality.  Perhaps if we were
in a (much) smaller country, or if we had a (much) larger community of OSM
mappers here, getting closer to this ideal would be easier.  But the truth
of the matter is that with ten million square kilometres of land to map, and
only a small handful of people doing it, the question naturally arises as to
whether it is better to have a very small area of Canada mapped extremely
well, or a larger area merely adequately.

This isn't as much an issue in the larger cities as it is in rural or remote
areas.  In larger cities, there is a larger community of OSM mappers out
there who keep them up to date, consistent, and accurate, and I think in
general those who have worked in those areas have done a wonderful job.
That's a great thing - our best maps in Canada are in locations where there
are the most people to take advantage of them.

I started contributing to OSM data via Canvec imports based on need - areas
I was interested in had a rather outdated road network, a very minimal
hydrological network, and no information on forested or wooded areas at all.
Canvec data, though not perfect or always internally consistent, at least
was much better than what was already there.

My first imports were sloppy, as any first attempts always are.  I didn't
know about joining features at edges of tiles, and in general placed a lot
more "authority" on Canvec data than it should have sometimes received.I
even discovered a bug in JOSM that caused me to accidentally delete some
roads that shouldn't have been (which was fortunately pointed out to me
fairly early so I didn't continue wrecking things as I went along trying to
improve them).  But I learned over time, and hopefully got better, in
learning where Canvec's strengths and weaknesses were.

Over time, I've come to realize how certain assumptions could be made in
Canvec data.  If roads for a new subdivision appear to be placed in a wooded
area, there is a pretty good chance that the wooded area is no longer there.
Similarly, for a road going through a small pond - the pond is likely based
on older data than the road and likely disappeared when the road was
constructed.  I usually assume that if a road already exists in OSM for an
area where Canvec has a road, the existing road could be very well based on
better data than Canvec (and on the other hand, if Canvec has data for a
road which doesn't exist in OSM, I usually add it under the assumption that
it had just not been mapped yet into OSM).  If Bing data exists to verify
this, great... but at least in the parts of the country I'm interested in,
it very rarely does.  And do I miss things and make mistakes?  Absolutely!
But I strive to add more value to OSM than I take away by failing to fix
inconsistencies like this.

Ultimately, as Bryan said, OSM data isn't written in stone, and a

Re: [Talk-ca] Internal CanVec conflicts

[Daniel Begin]

Paul, I understand Bryan's point of view. In a former life I had to ask map
users if they were preferring map consistency with old data or map
inconsistency with an updated road network. They mostly preferred the last
option
If we go on your proposal, one could upload an entire map sheet except where
there is some inconsistencies. These inconsistencies will usually be in
sub-urban area. It is easy to clean the data if good Bing imagery is
available but what if not? The rural area will be filled with data and
sub-urban area will be kept blank? I'm not sure I would like it...

What other contributors would like to see?


Paul, Je comprends le point de vue de Bryan. Dans une autre vie, J'ai eu à
demander à des usagers s'il préféraient une carte consistante mais périmée
ou inconsistante mais avec un réseau routier à jour. Ils ont préférés la
dernière option.
Si nous allons sur ta proposition, on pourraient charger une carte complète
sauf là ou il y a des inconsistances. Ces inconsistances seront généralement
en banlieue. C'est facile de corriger les données si les images Bing sont de
qualité mais que faire si elles ne le sont pas? Les secteurs ruraux seront
chargés (données complètes) mais les banlieues demeureront vides? Je ne suis
pas certain d'aimer ça...

Qu'est-ce que les autres contributeurs aimeraient voir?


Regards,
Daniel



-Original Message-
From: Paul Norman [mailto:penor...@mac.com] 
Sent: November-10-12 19:28
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Internal CanVec conflicts

> From: Bryan Crosby [mailto:azubr...@gmail.com]
> Sent: Saturday, November 10, 2012 8:33 AM
> To: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] Internal CanVec conflicts

> This will be my first and only response to this.  If the Canadian OSM
> community feels we need to check every stream, island, oxbow lake, piece
> of 'forest', esker, soil type, muskeg, swamp for accuracy, so be it.
> Keep in mind that in doing so, 80% of the country will receive no data,
> and the community will be down one mapper.

If you don't want to engage in a discussion that is of course up to you.

You appear to be mixing accuracy with consistency. My message was only about
consistency.

Accuracy is about if something is right. Consistency is about if something
makes sense.

Accuracy problems with CanVec are normally limited to old data and the
limits of resolution.

Consistency problems vary more. Generally they're caused because CanVec is
generated from multiple data sets gathered independently without reference
to each other. I had many examples locally of water data indicating a stream
with more recent data indicating the area had been built over. I've fixed
what I've found locally so I don't have any of those examples, but
http://www.openstreetmap.org/?lat=45.695&lon=-73.905&zoom=17 is a good
example from Quebec of the type of result. You don't need to look at Bing to
see that there's something odd there.


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


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

Re: [Talk-ca] Demande de vérification, question concernant name=

[Daniel Begin]

Bonjour,

I always tag names as name='name used locally'. If a French/English version
is used (I mean really used), Then I use name='name used locally',
name:fr='French name', name:en='English name. 

I use both name:en and name:fr because JOSM used to complain when the value
of name= was not duplicated in one of the name:*. May be it isn't the case
anymore...

Daniel

-Original Message-
From: Jonathan Crowe [mailto:jonathan.cr...@gmail.com] 
Sent: October-31-12 18:44
To: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca]Demande de vérification, question concernant name=

I've been doing a lot of work in western Quebec where there are a
number of majority-English communities, and have been doing my best to
come up with a reasonable approach to which language is used in the
name= tag.

I've generally been defaulting to name=frenchname name:en=englishname,
except in a few places with an overwhelming English majority. In those
cases, on the grounds that names should follow local usage, I've been
using name=englishname name:fr=frenchname, being careful to ensure
that the name:fr tag always exists.

For example, in Shawville (my current home town), 70 percent of the
local population is unilingual anglophone (which I agree is
unfortunate) and the road signs are bilingual; I've been using English
names there (name=Centre Street, name:fr=Rue Centre), because that's
what the locals would use. Whereas in surrounding Clarendon, whose
population is just as anglo, the road signs are in French, and I've
been using French names (name=Chemin de Calumet, name:en=Calumet Road)
for the most part.

I've also been tagging institutions with the appropriate language,
e.g., English institutions like schools always have English names, and
provincial facilities like government offices and hospitals are still
named in French even if they're in an English-majority community. I've
been tagging natural features (lakes and streams) and provincial
highways in French as well. Otherwise, it's on a case-by-case basis.

Generally, then, I've been tagging provincial-level features (however
vaguely defined) in French, and local-level features based on local
usage. When in doubt I choose French.


On Wed, Oct 31, 2012 at 4:28 PM, Bruno Remy  wrote:
> Despite the fact that both english and french are used langages in Canada,
> province of Quebec defines french as "most official langage"; So i think
we
> could set name=frenchname, name:en=englishname, and name:fr=frenchname.
> It could be quite tricky (or a nightmare ;-) ) to choose default langage
by
> a pondaration beetween french/english communities.
>
> In my opinion, OpenStreetMap has not the ability, role, mission to
arbitrary
> settle street names. This is probably most in the hands of the local
> administration (City, toponomy commision, and so on) .
> In other words: don't you think we should be the most transparent as we
can?
> :-)
>
> Concerning the "multi-langage signs", the best way to go should probably
be
> "tag as it appears on the road" or even "tag as it appears on the city's
> website" (if map is available, of course).
>
> Bruno Remy
>
> Le 2012-10-31 15:50, "Harald Kliems"  a écrit :
>
>> I've run into similar issues. Street signs vary a lot, sometimes on the
>> same street, a good (and maybe extreme) example is Bord-du-Lac/Lakeshore
on
>> the West Island. There are English-only signs: http://goo.gl/maps/Q4wQR ,
>> bilingual ones (that leave out the "Drive" in English)
>> http://goo.gl/maps/0goaN , French-only http://goo.gl/maps/3fcnX and maybe
>> even more variations. I don't know what official_name=* is for this
street,
>> and I'm also not sure what to put into name/name:en/name:fr in this case.
>>
>>  Harald.
>>
>>
>> 2012/10/31 Andrew MacKinnon 
>>>
>>> > Par exemple, un parc devrait-til être "name=Jarry Park" et
>>> > "name:fr=Parc
>>> > Jarry" ou simplement "name=Parc Jarry"? En utilisant OSMAnd~ sur
>>> > Android
>>> > j'ai pensé à ça car ce logiciel offre d'afficher les tags en anglais
ou
>>> > autres. Peut être avec un autre niveau d'impact, est-ce qu'on doit
>>> > utiliser "name=Park Avenue" et "name:fr=Avenue du Parc" pour des rues
>>> > aussi ou simplement "name=Avenue du Parc"? Avant d'en "corriger"
>>> > systématiquement lorsque j'en vois je voulais demander l'avis ici.
>>>
>>> Car on est au Québec le nom officiel serait en français, donc je
>>> mettrais name="nom en français", name:fr="nom en français",
>>> name:en="English name". Le nom en anglais est probablement
>>> non-officiel et n'est pas signé (peut-être il est signé dans les
>>> communautés anglophone tels que Westmount et l'Ouest de l'Île mais le
>>> gouverment PQ veut probablement l'éliminer). Si le nom anglais est
>>> signé je mettrais name="nom en français/English name" ou si c'est une
>>> rue "avenue du Parc Avenue", autrement je mettrais le nom en français
>>> seulement dans name=*.
>>>
>>> ___
>>> Talk-ca mailing list
>>> Talk-ca@openstreetmap.org

Re: [Talk-ca] Limites administratives, municipalités, MRC et régions du Québec

[Daniel Begin]

Bonjour Pierre, and all Osmers

 

Limites de StatCan ou GeoBase? Bonne Question!

 

Les limites de GeoBase sont ce qu'il y a de plus près des limites légales,
mais comme tu a remarqué, elle sont incomplètes pour certains niveaux
administratif (admin_level)

 

A ma connaissance, les limites de StatCan ...

a) Ne suivent pas toujours les limites légales, particulièrement si la
limite légale ne correspond pas a un objet physique comme une route, un
chemin de fer, ou une rivière;

 

b) Leur géométrie est différente des données GeoBase/Canvec. Autrement dit,
une limite légale qui repose sur une limite physique (route, un chemin de
fer, ou une rivière) ne correspondra pas nécessairement à la géométrie de
l'objet dans OSM, même si celui-ci a été obtenu de GeoBase ou de Canvec.

 

Gros travail d'intégration en perspective...

 

C'était du moins le cas il y a quelques années - Ce sera a vérifier avant de
prendre une décision.

 

Daniel

 

  _  

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: October-27-12 20:34
To: talk-ca
Subject: [Talk-ca] Limites administratives, municipalités, MRC et régions du
Québec

 


Au cours des dernières semaines, j'ai examiné les données pouvant être
importées pour définir les limites administratives des municipalités, MRC et
régions administratives du Québec.

J'ai déja indiqué dans un courriel précédent, les données importées par des
contributeurs à Saint-Jean-sur-Richelieu, Montréal, Labelle et Québec. 

De plus, des données importées pour Brossard et Laprairie sont mal définies
et devront être corrigées.

À mon avis, il faut éviter d'importer à la pièce les limites des villes,
sinon le travail de vérification / correction sera immense. Pour deux
municipalités ayant une frontière commune, si les limites sont différentes,
il y aura beaucoup de travail de réconciliation.

Sur le site des données ouvertes du gouvernement du Québec, j'ai fait une
demande pour obtenir les limites administratives du Québec avec licence
ODbl. Aucune nouvelle depuis quelques mois.

J'ai examiné les données de Geobase ajoutées récemment pour le Québec. Suite
à l'examen de cess données, je constate qu'il faut utiliser deux fichiers
différents :
1. limites de municipalités (source initiale, gouvernement du Québec).
2. limites des territoires autochtones.

J'ai constaté que certains territoires innus et tous les territoires
inniuits sont absents.  Les territoires non organisés, les MRC et les
régions ne sont pas décrits.

Comparativement, le fichier des limites de recensement de Statistique Canada
est complèt. Une subdivision de recensement est une municipalité ou un
territoire considéré comme étant équivalent à des fins statistiques (par
exemple une réserve indienne ou un territoire non organisé). 
voir
http://www5.statcan.gc.ca/bsolc/olc-cel/olc-cel?lang=fra&catno=92-162-XWF

 Les limites sont assez prêts de celles de Geobase. 
municipalités, territoires non organisés, territoires autochtones incluant
innus et innuits, MRC et régions administratives.

Je suggère donc que nous examinions la possibilité d'importer les données de
Statistique Canada pour définir les limites administratives des
municipalités,  MRC et régions administratives.
Je crois que le fichier le plus récent est à l'adresse suivante :
http://www.statcan.gc.ca/pub/92-196-x/2011001/spa-fra.htm

 

À mon avis, il vaudra mieux remplacer les limites déja saisies pour
faciliter le travail et assurer une cohérence de l'ensemble de données.

 

Est-ce que d'autres personnes veulent examiner ces données? Sinon,
acceptez-vous que je procède à l'import de ces donneés pour le Québec?
 

 

Pierre 

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

Re: [Talk-ca] Canvec import issues

[Daniel Begin]

Bonjour Pierre,

 

The Canvec Geometric Model is explained in the following OSM wiki page ...

http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model

 

The model was adopted after discussions with the community. The model was
designed to simplify the import of a selection of features by the
contributors, instead of imposing import the entire contents by them.

 

However, history now shows that the community usually imports the entire
content.

Compromises always bring pros and cons.!-)

 

Best regards,

Daniel

 

  _  

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: August-21-12 16:04
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues

 

 

I didn't do Canvec imports too much. Looking at various lakes in wooded
areas,  I now realize that Canvec imports are often (always?) duplicating
lakes. I do'nt know what was the reason to create these duplicate ways in
the Canvec import file.  Should we duplicate the lakes to apply a inner role
in the relation? Is this a reason for that? Or could we instead simply use
the existing lake with a inner role in the wooded area polygon relation?

 

Pierre 

  _  

De : Frank Steggink 
À : talk-ca@openstreetmap.org 
Envoyé le : Mardi 21 août 2012 13h32
Objet : [Talk-ca] Canvec import issues


Hi,

Today I was contacted by someone inquiring (with a somewhat hostile tone)
after the Canvec import I've done over the weekend northwest of Montréal. He
was not really happy with the way how the import has handled. The way the
Canvec data is currently provided, leaves some room for improvement. I'm not
sure if all his issues have been discussed in the past (since I haven't
followed all Canvec discussions, especially in the beginning), but I could
see some merit in some of the point.

Some examples he provided come from the Mt. Tremblant area [1]. Note that
the lakes (and most of the streams) were imported previously by someone
else, based on NHN data, but the same issue plays with the Canvec data
itself. (This left me to the task to leave the Canvec lakes out of the
upload, as well as most streams.)

On the left you see Lac Ouimet. He mentioned that a large part of the ways
are duplicated. The outer boundary of the wooded area is a separate polygon
from the lake itself.  However, Lac Gauthier on the right is a different
case. This lake has been "cut out" from the woods, and I left the inner
boundary intact. JOSM is not complaining about this. Since dealing with
multipolygons remains a sticky issue, I have not done that. I think it would
be better to take care of these issues with some tool. Although using a tool
is considered "dangerously" (and rightfully so!), dealing with multipolygons
is prone to errors as well.

Another issue is that some lakes do not have names, but contain a separate
node (not part of any of the ways) with natural=water and name=* tags. I can
only assume that this comes from the source data. In many cases it is hard
to determine the extent of the lake, since it can gradually taper into a
river. This was not mentioned directly by the user, but I thought he was
referring to this.

His issue turned out to be somewhat different. There is a place node near
Lac Gauthier, with the same name. I explained to this that this must be the
name of a hamlet. The non-official tag "place=locality" is probably due to
this confusion. This name is also visible on the original topo map [2].

Furthermore he noticed that I have duplicated his address nodes and ways.
This was an omission, so I have corrected this. I scan the existing data in
order not to duplicate existing features. Of course this is prone to errors
as well, especially in a large area which is void of address nodes and ways,
except for two ways around a lake...

I'm not asking anyone for "solutions". I can easily think about them as
well, but that doesn't make the problem go away. Thinking about the solution
is the easiest part, but working it out and implementing it is much more
difficult. It is more than simply typing in some code and then run it over
the data. Instead of doing that, I have tried to explain him something about
the hybrid data model OSM is using (not purely geographical, but also not
purely topological). And of course there is also the gap between idealists
and realists. I see the current state of OSM as the status quo, so I take it
for granted. I think that Canvec falls within that status quo situation as
well, otherwise the OSM data offered by NRCan would have looked differently,
after all those years of discussions and reviews.

I have invited this user to discuss the issues he found on talk-ca. I think
that would be much more constructive than having him directing all those
issues to me, since they occur far beyond his own backyard as well...

Regards,

Frank


[1] http://www.openstreetmap.org/?lat=46.1749

&lon=-74.5535&zoom=14&layers=M
[2]
ftp://ftp2.cits.rncan.gc.ca/p

[Talk-ca] Flooded (again) area in Montreal

[Daniel Begin]

Bonjour,

Quelqu'un peut vérifier ce qui se passe dans la région des Îles de
Boucherville?

Encore uns zone inondée par une mauvaise manipulation du coastline?

 

http://www.openstreetmap.org/?lat=45.6101&lon=-73.4411&zoom=13&layers=M

 

Daniel

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

[Talk-ca] GPS Tracks

[Daniel Begin]

Bonjour,

 

I just find out that there is no more "GPS Tracks" Tabs in Openstreetmap.org
site. Did I miss something, Can I upload my GPS tracks somewhere else?

 

Daniel

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

Re: [Talk-ca] Canadian imports: good or bad?

[Daniel Begin]

Bonjour,

I know that I'm not totally unbiased !-) but as it is an important question,
I'll add my two cents as OSM contributor...

Bulk import - Canvec for instance - is helpful to fill white areas on OSM
map. Not doing twice what is already available and focus on updating, or
adding features, that are not available from other sources. Using it as a
canvas to add upon.

I have fun updating hydrography, vegetation, parks, roads and land uses in
Sherbrooke, Sept-Îles and Rimouski. I would not have done the map from
scratch.

Best regards,
Daniel 


-Original Message-
From: Andrew Allison [mailto:andrew.alli...@teksavvy.com] 
Sent: April-15-12 12:19
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canadian imports: good or bad?

On Sun, 2012-04-15 at 11:09 -0400, Richard Weait wrote:
> Dear All,
> 
> Let's talk about it again.  How do we feel about the bulk copying of
> information from a permitted source into OpenStreetMap in Canada?
> 
> To be clear, I'm not suggesting that we discuss whether external data
> sources are good or not.  External data sources are good.  I'm
> suggesting that we review how we best make use of those external
> sources.
> 
> You go first.  :-)
> 
> Best regards,
> Richard
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca

>From what I see there are some conflicting arguments here.

1   Building a community of mappers to add features to the map. Ideally
local.

2   Canada is a huge country. I doubt that there are that many people
willing to commit to mapping every nook. I'm sure the amount of No
Trespassing signs itself would prevent it. 

3   OSM is promoting itself as a "competitor" to google.

4   I would suspect most mappers are not aware of the license change
coming and the resulting impact.

Given the size of Canada, and the few mappers we have. I my self
could
not and probably would not have never walked / driven on every road,
trail, river, lake forest etc without some else doing an import first
which I myself used a base to improve OSM.

I don't see any possible way to have a map without an import to use
as
a base.

To counter my own points, Yes, you will find some people who see a
great white spot as a challenge. But looking at the changes made locally
I would think most people would rather tweak an existing road or park.

Andrew


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

Re: [Talk-ca] coastline or water polygon

[Daniel Begin]

Agreed with Paul,

The new version of Canvec (release 10) is compatible with the osm coastline
definition but still configured as multipolygon where the product is unaware
it is the ocean . For the moment, only BC and Northern part of Nunavut is
geometrically and correctly tagged.

Daniel

-Original Message-
From: Paul Norman [mailto:penor...@mac.com] 
Sent: April-14-12 22:09
To: 'Andrew Allison'; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] coastline or water polygon

> From: Andrew Allison [mailto:andrew.alli...@teksavvy.com]
> Sent: Saturday, April 14, 2012 6:55 PM
> To: talk-ca@openstreetmap.org
> Subject: [Talk-ca] coastline or water polygon
> 
> Hello:
>   I'm removing red dots on the north coast of Nova Scotia at the
> moment with canvec data. The canvec data has a bunch of polygons for the
> coastline.
> 
>   Is there any strong arguments which is better either
> 
>   natural = coastline vs polygon of water?
> 
>   Coastline = updates slowly, but smaller ways
>   water = updates faster but larger and less intuitive .
> 
>   Andrew

The data in Nova Scotia in OSM is broken. Someone imported large
natural=water polygons on the coast over existing data. I fixed about half
of the imports and haven't had time to get back to the rest. The coastline
should *not* be mapped with natural=water.


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


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

Re: [Talk-ca] Canvec.osm Product - Running!

[Daniel Begin]

Forwarding an email that did not reach talk-ca list - 

 

  _  

From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] 
Sent: April 6, 2012 13:24
To: 'talk-ca@openstreetmap.org'
Cc: 'David Groom'
Subject: [Talk-ca] Canvec.osm Product - Running! 

Bonjour OSMers! 

Canvec.osm product conversion is still running. However, we have found some
problems in the database with the hydrographic network (at least in Ontario)
where there are nodes every meter!

 

We are working to circumscribe the problem and the concerned files will be
reprocessed. If you ever find some files having this problem, please do not
hesitate to contact me.

 

In the meantime...

I've been asked some questions about the coastline - Thanks to David Groom.
Digging further on the answers I provided, I've found that it is now
possible to differentiate between a coastline and a waterbody for BC and
most of the Nunavut. I've adjusted the process and will provide real Osm
coastline when available.

 

Furthermore...

Our database is ready to manage maxspeed and oneway information. As soon the
provinces provide the information, the Canvec.osm product will have it.

 

Let me know if you find unexpected problems in the data. 

Cheers, 
Daniel 

 

 

 

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

Re: [Talk-ca] Clean up progress and last push

[Daniel Begin]

Bonjour encore,

Pretty useful tool! It helps me identifying non-odbl coastline nodes/ways
between Sept-îles and Mingan really fast. I'm on the process of deleting
non-odbl objects and replace them with a brand new 200Km of coastline (69K
objects).

Well, I just hope everything will continue to upload properly :-)

Daniel

-Original Message-
From: Steve Singer [mailto:st...@ssinger.info] 
Sent: March-31-12 14:43
To: Pierre Béland
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Re : Re : Clean up progress and last push

On Sat, 31 Mar 2012, Pierre Béland wrote:

> Any instruction to add this layer in JOSM ?

In JOSM there is a 'LicenseChange ' plugin. Install that.

The icon for it is a set of traffic lights.

Download an area in OSM.  Make that area your active layer.  Make sure no 
objects (ways, nodes, etc...) are selected.  The click on the 'License 
check' button  in the 'relicensing problems' part of the window.  It should 
check all objects in the area that you have downloaded.  It will then create

a new layer that has the red/orange circles as I described.



> 
> Pierre
> 
>

> 
> In the JOSM license layer it shows each non-odbl clean node in red,
> (or oranage/yellow). I delete the way and any all non clean nodes for
> that way and remake it from the Geobase WMS layer.  I TRY not to join
> the way to nodes that are red from another intersecting way.  If the
> way I am working on crosses another non-odbl way I will either:
> 
> 
>


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

Re: [Talk-ca] Clean up progress and last push

[Daniel Begin]

Bonjour,

I'm working on coastline near Sept-Îles. Hopefully it will be repaired
before tonight!

Cheers
Daniel

-Original Message-
From: Frank Steggink [mailto:stegg...@steggink.org] 
Sent: March-31-12 08:50
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Clean up progress and last push

On 31-3-2012 8:16, Frank Steggink wrote:
>
> Working on Quebec. I've replaced about half of the affected roads with 
> Canvec. The stray non-ODBL nodes (which happen to be along main 
> streets) are due to nodes being reused for landuse. I'm not sure if 
> those can be cleaned up in time (as I expect to be busy with the rest 
> of the roads most of the day), but I'll try.
>
Roads in Quebec City are done [1] :) Landuse not so much, but imho 
that's not that important, since it can be added relatively quickly with 
Bing, etc.
I'll work on some roads in Charny / Ste-Hélène, and then probably the 
coastline near Sept-Îles (roughly: just to prevent an eventual flooding).

Frank

[1] http://www.openstreetmap.org/user/fsteggink/edits


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


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

Re: [Talk-ca] Re : Duplicated ways

[Daniel Begin]

Pierre,

 

je ne remet pas en question les "détails inhabituels" dont nous nous étions
parlés à l'époque.

Je remet en question la façon d'attribuer la relation avec des tags qui sont
spécifiques aux objets au sol. 

 

I understand that you deliberately kept ways duplicated to insure an
appropriate rendering? Afaik, "tagging for the renderer" is frowned upon as
James wrote. 

 

I also understand from OSM best practices (confirmed by Richard), that
treating the trail/route as distinct from the road where it shares the road
is usually incorrect (as shown the link to Streetview provided by James).

 

Si je respecte le consensus de la communauté dans le domaine, je comprend
que tu risques de perdre ton rendu. Y a-t-il une façon pour toi de conserver
ton rendu tout en respectant le consensus de la communauté?

 

Daniel

 

  _  

From: infosbelas-...@yahoo.fr [mailto:infosbelas-...@yahoo.fr] 
Sent: February-26-12 14:25
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Re : Duplicated ways

 

 

 

Pierre 

  _  

Daniel, 

Si tu te rappelles bien, nous avons échangé à plusieurs reprises toi et moi
en 2010 lorsque j'ai complété le tracé du Sentier de L'Estrie de près de
180km dont tu avais préalablement tracé certaines portions. Tu avais alors
indiqué ton désaccord  à indiquer les bornes kilométriques et auttres
repères du sentier de randonné. J'ai aussi examiné ce qui se faisait à
l'époque et fait des propositions sur la page wiki de Randonnée pédestre au
Québec que j'ai alors créée. Je n'ai cependant jamais eu de feedback depuis.
Peu de collaborateurs du Québec interviennent sur cette page de discussion.
J'invite donc ceux qui hésitent à intervenir et à y discuter en français
s'ils se sentent ainsi plus à l'aise. 
http://wiki.openstreetmap.org/wiki/Canada:Qu%C3%A9bec/Randonn%C3%A9e_P%C3%A9
destre

Je m'oppose évidemment à ce que tu effaces ces informations. Ceci aurait
pour effet de faire disparaitre complètement le sentier de randonnée des
cartes. Avant de modifier quoi que ce soit, il serait opportun de proposer
des solutions concrètes. La discussion est ouverte depuis 2010. Il faut
proposer autre chose que d'effacer les infos du sentier de randonnée.

Ton message soulève deux questions.

La première est relative à la descriptions de deux activités différentes sur
un même segment. Si ces activités sont indiquées sur le mêmc chemin, les
moteurs de rendu accorderont la priorité à une des deux activités. Et à ma
connaissance, c'est le vélo qui sera priorisé, et on ne verra rien du
sentier de randonnée. Comment régler ce problème? Le parc Orford est un
autre endroit où pistes cyclables et pistes de randonnée se partagent une
certaine portion de sentier. voir
http://www.openstreetmap.org/?lat=45.35107&lon=-72.22763&zoom=15&layers=C

La deuxième est relative à ton interrogation sur les "détails inhabituels".
Je suppose donc que tu veux rediscuter du fait d'ajouter des bornes
kilométriques, repères d'intersection de sentier et points de vue. Ces
informations sont importantes pour le suivi sur GPS. Sur mon GPS, les bornes
kilométriques et les divers repères me permettent de me situer rapidement, à
tout moment sur le sentier. Y-aurait-il une façon de conserver cette
information pour les GPS et mettre moins d'information sur les cartes?  

Pierre


De : Daniel Begin 
À : talk-ca@openstreetmap.org 
Envoyé le : Dimanche 26 février 2012 12h28
Objet : [Talk-ca] Duplicated ways





Bonjour,

 

I'm cleaning up my area for relicensing problems and I have found duplicated
ways that raise some questions - not related to relicensing problems. 

 

One is a bicycle track/route I created few years ago, the other is a hiking
trail/route imported later. Both merge near the "Chemin Keenan" bridge and
share the same tracks/roads for 3 km. The hiking trail was drawn few meters
offset even if it was not physically separated on the field.

 

http://www.openstreetmap.org/?lat=45.62953&lon=-72.1247&zoom=16&layers=M

 

I was about to remove the hiking trail ways and transfer the relation=route
to the existing tracks/roads when I saw the unusual number of tags attached
to it. The problem is that some of them are referring to the entire hiking
trail (name, operator, ...) while others are specific to ways used (access,
highway, surface, ...) .

 

For instance the relation (id=48112682) has the following tags...

access=permit, highway=trail, surface=dirt

 

While some shared segments have the following tags...

highway=tertiary, surface=paved, and there is no access restriction.

 

Best move to do ?

 

Daniel

 


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



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

[Talk-ca] Duplicated ways

[Daniel Begin]

Bonjour,

 

I'm cleaning up my area for relicensing problems and I have found duplicated
ways that raise some questions - not related to relicensing problems. 

 

One is a bicycle track/route I created few years ago, the other is a hiking
trail/route imported later. Both merge near the "Chemin Keenan" bridge and
share the same tracks/roads for 3 km. The hiking trail was drawn few meters
offset even if it was not physically separated on the field.

 

http://www.openstreetmap.org/?lat=45.62953&lon=-72.1247&zoom=16&layers=M

 

I was about to remove the hiking trail ways and transfer the relation=route
to the existing tracks/roads when I saw the unusual number of tags attached
to it. The problem is that some of them are referring to the entire hiking
trail (name, operator, ...) while others are specific to ways used (access,
highway, surface, ...) .

 

For instance the relation (id=48112682) has the following tags...

access=permit, highway=trail, surface=dirt

 

While some shared segments have the following tags...

highway=tertiary, surface=paved, and there is no access restriction.

 

Best move to do ?

 

Daniel

 

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

Re: [Talk-ca] Re : Closed Road Tagging

[Daniel Begin]

Interesting,

I guess I'll keep the access=no tag until it is confirmed that the road is
definitely closed. Then, I'll probably tag it as abandoned=yes (instead of
disused) as I suspect it won't be maintained as it is considered dangerous.

http://wiki.openstreetmap.org/wiki/Key:abandoned

Someone has an idea on the best list to contact about this rendering
problem?

Thanks
Daniel 


-Original Message-
From: Harald Kliems [mailto:kli...@gmail.com] 
Sent: February-25-12 20:46
To: Daniel Begin
Cc: infosbelas-...@yahoo.fr; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Re : Closed Road Tagging

Hi Daniel,

2012/2/25 Daniel Begin :
> Le problème est qu'il n'y a pas de construction sur la route. J'utilise ce
> tag seulement lorsqu'il s'agit d'un vrai chantier...

For this reason, I still think that  access=no is the cleanest
solution, no matter what mapnik renders. The only alternative I can
see is using the disused tag
(http://wiki.openstreetmap.org/wiki/Key:disused ). The wiki does not
mention highways, but if you look at the description I think it
matches quite nicely with the problem at hand. And tagwatch says that
there are some instances where people have used disused=* in
combination with highway=*. But this most certainly won't solve your
rendering issue and should probably be discussed on the tagging list.

Harald.
-- 
Please use encrypted communication whenever possible!
Key-ID: 0x199DC50F


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

Re: [Talk-ca] Re : Closed Road Tagging

[Daniel Begin]

Bonjour Pierre,

 

Le problème est qu'il n'y a pas de construction sur la route. J'utilise ce
tag seulement lorsqu'il s'agit d'un vrai chantier... 

The problem I see is that that there is no construction on the road. I use
it only on real construction site...

 

http://www.openstreetmap.org/?lat=45.37006&lon=-71.92713&zoom=15&layers=M

 

Ça ne me semble pas adéquat lorsqu'une route est fermée pour une autre
raison.

Daniel

 

  _  

From: infosbelas-...@yahoo.fr [mailto:infosbelas-...@yahoo.fr] 
Sent: February-25-12 18:04
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Re : Closed Road Tagging

 

Daniel

 

Regardes la route 35 en construction présentement.

voir http://www.openstreetmap.org/browse/way/86575482/

 

Le rendu me semble clair relativement à l'état de la route. Je te suggère
donc de mettre une note indiquant la situation et d'utiliser les balises
suivantes :

*   construction: primary
*   highway: construction

 

Pierre 

  _  

De : Daniel Begin 
À : talk-ca@openstreetmap.org 

Here is how it is tagged at the moment...

highway: primary

ref: 112

access: no

note: Closed - Landslide warning / Fermée - Risque de glissement de terrain

 

 

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

Re: [Talk-ca] Closed Road Tagging

[Daniel Begin]

Bonjour Paul

 

No construction activities. Actually, they are planning to move the road
somewhere else since it's the 2nd or the 3rd time they have to close it!
However no official proposition yet. 

 

Access=no is rendered at lower zooms but when you look at the map for a trip
planning, you don't zoom that much!

 

Regards,

Daniel

 

  _  

From: Paul Norman [mailto:penor...@mac.com] 
Sent: February-25-12 17:05
To: 'Daniel Begin'; talk-ca@openstreetmap.org
Subject: RE: [Talk-ca] Closed Road Tagging

 

If they were doing work on it I’d suggest highway=construction. If they’ve
just closed it indefinitely then I’d say access=no is the best way, but is
it really a primary if it’s closed until further notice?

 

Access=no should likely be rendered at lower zooms when on major road types

 

From: Daniel Begin [mailto:jfd...@hotmail.com] 
Sent: Saturday, February 25, 2012 1:33 PM
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Closed Road Tagging

 

Bonjour,

 

There is an primary road (ref=112) around here that have been closed for two
year - authorities detected cracks in the pavement that was suggesting that
the road was sliding toward a large mining pit. All traffic is divert toward
Vimy Ridge since then.

 

http://www.openstreetmap.org/?lat=46.0167
<http://www.openstreetmap.org/?lat=46.0167&lon=-71.3602&zoom=13&layers=M>
&lon=-71.3602&zoom=13&layers=M

 

I know that we don't map/tag for the renderer but it is not obvious that the
road can't be used looking at Mapnik, Osmarender or Transport Map.  Is there
something else I can use to make it more obvious?

 

Here is how it is tagged at the moment...

highway: primary

ref: 112

access: no

note: Closed - Landslide warning / Fermée - Risque de glissement de terrain

 

I also added barriers at the end of closed segment.

barrier: block

bicycle: no

foot: no

 

Waiting for your suggestions

 

Daniel

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

[Talk-ca] Closed Road Tagging

[Daniel Begin]

Bonjour,

 

There is an primary road (ref=112) around here that have been closed for two
year - authorities detected cracks in the pavement that was suggesting that
the road was sliding toward a large mining pit. All traffic is divert toward
Vimy Ridge since then.

 

http://www.openstreetmap.org/?lat=46.0167&lon=-71.3602&zoom=13&layers=M

 

I know that we don't map/tag for the renderer but it is not obvious that the
road can't be used looking at Mapnik, Osmarender or Transport Map.  Is there
something else I can use to make it more obvious?

 

Here is how it is tagged at the moment...

highway: primary

ref: 112

access: no

note: Closed - Landslide warning / Fermée - Risque de glissement de terrain

 

I also added barriers at the end of closed segment.

barrier: block

bicycle: no

foot: no

 

Waiting for your suggestions

 

Daniel

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

Re: [Talk-ca] Some french translation advice

[Daniel Begin]

Bonjour Tyler,

I don't know the best practices about naming roads when a road is not really
named like "Tyler Gunn Trunk Highway". I prefer not adding any name tag when
the name tag would actually be a combination of other tags and context as
you suggest...

Context: with few exceptions, all Canadian roads are provincial or municipal
tag highway=trunk
tag ref=99

then, a "name=Provincial Trunk Highway 99" tag seems a bit artificial for
me.

However, to answer your questions
- Provincial Trunk Highway XY: As there is no real translation for trunk in
this context, so I would suggest "route provinciale XY"
- Provincial Road XYX: I would suggest "route provinciale XYX"

Best regards
Daniel

-Original Message-
From: Tyler Gunn [mailto:ty...@egunn.com] 
Sent: January-11-12 10:53
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Some french translation advice

I'm working on a JOSM plugin to help rename/reclassify provincial
roads and provincial trunk highways in Manitoba in the Canvec data.
The goal is to enforce a common naming for PRs and PTHs in MB.

Generally, highways with ref=0-99 are considered "Provincial Trunk
Highways", and as such I've got the following names:
EN: Provincial Trunk Highway XY
FR: route provinciale à grande circulation XY

Generally, highways with ref>99 are considered "Provincial Roads", as
as such I've got the following names:
EN = Provincial Road XYX
FR = route provinciale secondaire XYZ

These are the french translations I could come up with, given my very
limited understanding of the French language.

Could someone proof these for me and let me know if I'm completely off base?

Thanks,
Tyler

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


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

Re: [Talk-ca] import complaints

[Daniel Begin]

Bonjour Richard and all,

I might not be totally unbiased !-) but I don't agree with Richard here.

Actually, since I've imported Canvec data for my neighbourhood, I have been
able to update/add/remove a lot of features/details that are not available
in any other map. Stop sign, lights, biking/pedestrian track and trail,
steps, the nice coffee shop near the bus stop were not there if instead I
had mapped feature that can be found everywhere (roads, water or railways).

I'm not on the impression that the community is disappearing, I'm on the
impression the community is changing. 

2-3 years ago, most of the traffic on talk-ca was about developing tools to
import data! Since Canvec data is available, that part of the traffic is not
there anymore (until this weekend !-) 

You are right suggesting that osm community have grown because of the white
spots on the map (SuperMapper). I would use the same example to argue that
the community can now grow faster because the map is not white anymore
because of the "syndrome de la page blanche" ("Writer's block") 

About resulting data quality, it can be lower if an import is done where
data already exists and the integration not done properly. However, I've
seen - and I'm pretty sure many of you have seen - areas where the quality
is poor even if there were no import.

I think there is a place for importing and that writing appropriate
procedure in the wiki - as suggested - would do the job to advise newbie
about the complexity of importing data.

Best regards,

Daniel

 
-Original Message-
From: Richard Weait [mailto:rich...@weait.com] 
Sent: December-02-11 16:07
To: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] import complaints

On Fri, Dec 2, 2011 at 3:27 PM, Connors, Bernie (SNB)
 wrote:
> Richard,
>
>        Do you have a link to Import Guidelines that are specific to Canvec
data?

Sure.

All imports should comply with the OSM import guidelines.  My
preference is that we do not import at all. We should treat outside
sources the way we treat aerial imagery.  This is a deliberately
provocative statement.  More below.

http://wiki.openstreetmap.org/wiki/Import_guidelines

The automated edit guidelines apply to imports, and to any mass / bulk edit.

http://wiki.openstreetmap.org/wiki/Automated_Edits/Code_of_Conduct

Now, on imports.  I'm very grateful that NRCan has been generous and
allowed us to include Canadian government data in OSM.  It's even
better that folks at NRCan participate in the OSM community.  This is
not about them, and they are not at fault.

It is my opinion that imports delay or end the growth of local OSM
communities at the expense of "some data is better than perfect data".
 How?  In the old days, a person might hear of OSM, look at the map
and see that their neighbourhood is a blank spot on the map.  That
motivated them to map their neighbourhood, and "boom" all of a sudden
that new mapper is $SuperMapper.  Pick one of the old-timers on the
talk@ list for a value for $SuperMapper.  Today, a new mapper might
look at rural Ontario, and think, "Ah, all the roads are there.  No
need for me to map."  And we have missed the opportunity to create a
new SuperMapper.

So this might be true of any place, where mappers have mapped from a
distance.  Why pick on imports?  Imports are too fast and too easy.
That leads to insufficient care being applied to each node and way.

When we map from aerial imagery we carefully consider each node placed
on each way, because we have to do them all one by one, based on what
we interpret from the imagery.  That's good.  With an import, we might
look at the 20 km**2 and check a few spots, but it is not possible to
give the same attention to each and every node that we would as we
draw them by hand.

So we get broken imports because we don't pay enough attention.  Our
tools have improved over the last seven years to reduce the gross
errors that we make with imports but that is no substitute for the
individual care and attention that we give to the nodes and ways we
create through hard(er) work.

So imports are worse than referring to an external source like tracing
aerial imagery.  The quality is lower.

And the result can prevent or dissuade new mappers from joining OSM.

In the alternative universe, where we did not import, new mappers
found their neighbourhoods as blank spots and started mapping.  In
that alternative universe talk-ca has 10X or 100X readers.  Every town
in Canada has one or more local mappers.  today, we might say every
city in Canada has one or more mappers.  In ten years we might have a
mapper in every town.  In that alternate universe, ten years from now,
perhaps there is a mapper in every Canadian village.

Is there a difference?  Yes.  We want a mapper on every block.
Imagine, if a coffee shop around the corner changes name, how long
would it take to update in OSM with a mapper on every block?  "Not
long" is the answer.  With only one or more mappers in the nearest
city, OSM will never know

[Talk-ca] Unexperience user?

[Daniel Begin]

Hi all,

 

A month ago I found a lot of "messy" multipolygons having natural=coastline
and/or waterway=riverbank mixed all together in Montreal area, resulting in
bad rendering ...
http://www.openstreetmap.org/?lat=45.295&lon=-73.005&zoom=9&layers=M 

 

All came from user - http://www.openstreetmap.org/user/Alain512. I contacted
him in mid-October but haven't received any answer yet.  Since, other users
and I have tried to correct the problems.

 

He is now working around l'Île d'Orleans near Québec city and I have found
the same kind of problem...
http://www.openstreetmap.org/?lat=46.977&lon=-70.9076&zoom=12&layers=M

 

Is someone else could try to contact him to make sure he understands what is
doing before continuing...

 

Regards,

 

Daniel

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

Re: [Talk-ca] [OSM Sherbrooke discussion] Big Baseball Project 2011 - OpenGeoData

[Daniel Begin]

Salut Yves, 

c'est relativement simple à cartographier et ça pourrait-être un thème lors
d'un prochain mapping party.

 

Lors du dernier mapping party qui s'est tenu à Sherbrooke en juin, l’accent
a été mis sur la cartographie du Campus de l'Université de Sherbrooke qui
comprend de nombreux terrains de sports, y compris le Baseball. Certains
terrains de sports étaient particulièrement complexes à représenter parce
qu'ils se superposent. Si vous avez des suggestions ou pouvez fournir des
références sur la façon de faire... 

 

http://www.openstreetmap.org/?lat=45.374933&lon=-71.932442&zoom=18&layers=M

 

Daniel

 

  _  

From: Yves Moisan [mailto:yves.moi...@boreal-is.com] 
Sent: October-13-11 13:38
To: osm-sherbrooke-discussion
Subject: [OSM Sherbrooke discussion] Big Baseball Project 2011 - OpenGeoData

 

Un beau petit défi : cartographier les terrains de baseball

http://opengeodata.org/big-baseball-project-2011?utm_source=feedburner

&utm_medium=feed&utm_campaign=Feed%3A+Opengeodata+%28OpenGeoData%29

Suivez les indications à You'll find "more
  guidance on
the wiki".  Je vais tenter de cartographier les terrains où mon juen a joué
cet été; ça fera ça de moins pour Sherbrooke 2013 ...

Yves



--
To unsubscribe send an email with subject "unsubscribe" to
osm-sherbrooke-discuss...@lists.coactivate.org. Please contact
osm-sherbrooke-discussion-mana...@lists.coactivate.org for questions.

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

[Talk-ca] FW: Canvec.osm Product -Completed!

[Daniel Begin]

Seems NRCan is considered a spammer for talk-ca list !-) so I forward the
message from my personnal account.


-Original Message-
From: Bégin, Daniel [mailto:daniel.be...@rncan-nrcan.gc.ca] 
Sent: 28 septembre 2011 08:16
To: 'talk-ca@openstreetmap.org'
Subject: [Talk-ca] Canvec.osm Product -Completed!

Bonjour OSMers!

Canvec.osm Product conversion is completed - except for 30 files in Manitoba
that should be reprocessed in next release this fall - see the list at the
end of this email.

What's new ... 
- Swapped amenity=school/prison tag values corrected.
- Misspelled tag value on highway=unclassified corrected. 
- Duplicated railway=rail features removed. 
- Single node natural=land created only if name tag is attached. 
- Multiple consecutive spaces in name tag are removed. 
- name:fr/name:en applied on all features when available. 
- Surfaces orientation respect right-hand rule. 
- Missing large polygons should have been corrected.

About missing polygons, I'd like to know if it has really been corrected. Do
not hesitate to contact me if you find one :-)

Cheers,
Daniel

Files not processed
052E04
062F14
062G02
062G07
062G09
062G10
062G13
062G16
062H03
062H06
062H07
062H09
062H10
062H11
062H13
062H14
062H15
062H16
062I02
062I04
062I09
062J09
062J13
062K01
062K14
062N06
062N16
063C03
063F14
063K02

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


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

Re: [Talk-ca] Using Canvec data to recreate or modify coastline features

[Daniel Begin]

Bonjour James, sorry for the delay.

About your example, I couldn't have shown it better!

The procedure I use ...
- All features having a natural=water tag are dissolved together before
creating a coastline feature.

- The features having natural=water and water=intermittent tags are copied
into another layer before being reintegrated after the creation of the
coastline feature. 

Daniel

-Original Message-
From: James A. Treacy [mailto:tre...@debian.org] 
Sent: September-08-11 13:59
To: Daniel Begin
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Using Canvec data to recreate or modify coastline
features

Daniel,
I'd like to make this more concrete with an example. If you have canvec data
that shows:
    this area is land
-i-i-i-i-i-i-i-iway which is natural=water;water=intermittent
    area with intermittent water
-w-i-w-i-w-i-w-iboundary with 2 ways. One is natural=water and
the other is natural=water;water=intermittent
    this area is water

is this what OSM should have?
    this area is land
-c-i-c-i-c-i-c-iboundary with 2 ways. One is natural=coastline and
the other is natural=water;water=intermittent
    area with intermittent water
-i-i-i-i-i-i-i-iway which is natural=water;water=intermittent
    this area is water

Obviously, the ways would be closed but I think this gives the idea.

On Mon, Sep 05, 2011 at 09:37:11PM -0400, Daniel Begin wrote:
> Hi all,
> 
> Earlier today I was looking at coastline features modified to fit Canvec
> data and I found a problem with the "conversion". I think all of those who
> are converting coastline using Canvec data should be aware of the Canvec
> water data model...
> 
> In Canvec data you will find two types of water polygons
(natural=water)...
> 
> One type defines permanent water - an area that is always covered by the
> water. 
> 
> - It is tagged natural=water
> 
> One type defines intermittent water - an area that is occasionally, but
not
> always covered with water.
> 
> - It has two tags. One is the standard natural=water tag, the other is
> water=intermittent tag(1).
> 
>  
> 
> The problem is that the coastline seems to be defined as the mean high
water
> level (MHWL) position(2). To create a coastline that meet the MHWL
position
> using Canvec, you must merge all natural=water polygon type before
> converting it to coastline.
> 
>  
> 
> JOSM provides a good tool to merge those polygons - join overlapping area
> (Shift-J)
> 
>  
> 
>  
> 
> Daniel
> 
>  
> 
>  
> 
>  
> 
> 1 - http://wiki.openstreetmap.org/wiki/Proposed_features/Water_cover
> 
> 2 - http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline and other
> wiki discussions
> 

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


-- 
James (Jay) Treacy
tre...@debian.org


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

[Talk-ca] Using Canvec data to recreate or modify coastline features

[Daniel Begin]

Hi all,

 

Earlier today I was looking at coastline features modified to fit Canvec
data and I found a problem with the "conversion". I think all of those who
are converting coastline using Canvec data should be aware of the Canvec
water data model...

 

In Canvec data you will find two types of water polygons (natural=water)...

 

One type defines permanent water - an area that is always covered by the
water. 

- It is tagged natural=water

 

One type defines intermittent water - an area that is occasionally, but not
always covered with water.

- It has two tags. One is the standard natural=water tag, the other is
water=intermittent tag(1).

 

The problem is that the coastline seems to be defined as the mean high water
level (MHWL) position(2). To create a coastline that meet the MHWL position
using Canvec, you must merge all natural=water polygon type before
converting it to coastline.

 

JOSM provides a good tool to merge those polygons - join overlapping area
(Shift-J)

 

 

Daniel

 

 

 

1 - http://wiki.openstreetmap.org/wiki/Proposed_features/Water_cover

2 - http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline and other
wiki discussions

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

Re: [Talk-ca] Update on updating the Lake Huron shoreline

[Daniel Begin]

Hi all,

I have been imported Canvec data around US-QC-ON border and I'm having a
similar question.  When should we use Canvec data as is (natural=water) and
when should we transform it into natural=coastline?

Using natural=coastline on US border (to match tagging with the US portion)
seems fine to me but when do we switch to the other representation?

Does someone have a proposition?

Daniel

-Original Message-
From: James A. Treacy [mailto:tre...@debian.org] 
Sent: August-09-11 14:32
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Update on updating the Lake Huron shoreline

Hello,
Another update on the conversion of the Great Lakes shoreline plus
one question.

After something like 10,000 islands, the conversion of the Canadian
shore of Lake Huron (including Georgian Bay) to use the canvec data
is completed! That is a LOT of islands. Given the magnitude of the
task, few changes were made to the land side of things. That's not
quite true as all the islands had all features added - including
Manitoulin Island.

For the areas that have been rendered it looks much better. It could
be a few weeks before the remainder of the shoreline is updated.

I have started moving down the St Clair River (connecting Lake Huron
and Lake Erie) and have a question:

Is there any preferred method to decide where to stop using coastline
and to start using natural=water? There are some channels that cut off
a large part of the mainland in NE Lake St. Clair which could easily
be used as the shoreline. That would be a huge change from the current
shoreline though. Additionally, the route of the current shoreline
would be time consuming to maintain as it would involve cutting up a
number of areas that canvec renders as water. I'd think the best route
would be to use the definition of the shoreline as defined by some
official governmental body, if such a thing exists.

Any suggestions? Even an answer of 'just do what is convenient' would
be helpful.

-- 
James (Jay) Treacy
tre...@debian.org

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


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

[Talk-ca] Missing street segments

[Daniel Begin]

Hi all,

 

I've found some street missing in Cornwall Ontario.  Seems deleted to me.
Someone is aware about that?

http://www.openstreetmap.org/?lat=45.01442&lon=-74.73045&zoom=16&layers=M

 

Daniel

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

Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec

[Daniel Begin]

Hi all,

an image interpretation of the flooded area of Haut-Richelieu has been
uploaded, replacing the first work done by Pierre (Thanks to Pierre) .It's
time to put our boots on the ground - in the water?!!

Daniel

 

  _  

From: Jean-Guilhem Cailton [mailto:j...@arkemie.com] 
Sent: May-28-11 07:07
To: Daniel Begin; Pierre Beland
Cc: 'HOT Openstreetmap'; 'talk-ca'
Subject: Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada
:Follow-up(Complement of information)

 

Hi,

Great find Daniel !

To use directly the GeoTiff images in JOSM, you could try the
ImportImagePlugin, but I haven't tried it.

I put the EO1-ALI images from Earth Observatory online, in WMS and TMS, with
the coordinates included in the GeoTiff files. 

Apparently, they were not georeferenced in relation to ground control
points, but with the imagery layer shift option included in Josm, it is not
too difficult to align them to existing data. For example, a shift of "197;
-514" quickly adjusted over Venise-en-Québec seems to give a reasonable
alignment in other areas of the images too.

We could try to improve the georeferencing of the original images with
ground control points, but for now it seems that having a try at mapping the
flood extent with the current setup has higher priority. Let me know if you
think more work on georeferencing would be useful.


URLs:

For the natural color image in TMS (recommended over WMS), use the following
link in Josm:
tms:http://osm.arkemie.org/cgi-bin/tiles/1.0.0/hautrichelieu_coulnat/{zoom}/
{x}/{y}.jpg

For the shortwave infrared image in TMS:
tms:http://osm.arkemie.org/cgi-bin/tiles/1.0.0/hautrichelieu_swir/{zoom}/{x}
/{y}.jpg


The base WMS URL is : 
http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map

Thus, for the natural color image in WMS, use the following link in Josm:
wms:http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map
<http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map&FORMA
T=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=hautrichelieu20
110508_natcol&>
&FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=hautriche
lieu20110508_natcol&

For the shortwave infrared image in WMS:
wms:http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map
<http://osm.arkemie.org/cgi-bin/osm_wms?map=/mapsite/hautrichelieu.map&FORMA
T=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=hautrichelieu20
110508_swir&>
&FORMAT=image/jpeg&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&Layers=hautriche
lieu20110508_swir&


Now on to OSM-style-collaborative-iterative flood extent mapping, without -
and probably then with - boots :)

Best wishes,

Jean-Guilhem


Le 28/05/2011 05:53, Daniel Begin a écrit : 

Hi all,

 

I've tried to "put my boots on the ground" without  going there !-).  I
found a pretty clear satellite image of the river at its max level (30-31m)
- which doesn't really changed since ...

 

http://earthobservatory.nasa.gov/NaturalHazards/view.php?id=50577

 

I made few geometric adjustments to the image and compare the result with
30m GeoBase and SRTM contours. Geobase contours gives better results between
St-Jean and L'Île aux Noix but from there to the US boundary, neither
GeoBase nor SRTM is right.

 

I'm trying to produce a flooded area from DEM data while I'm looking at an
image that contains what I'm looking for - the flooded area!  Why not
mapping from it? I understand the image can be used -
http://earthobservatory.nasa.gov/ImageUse/

 

Any idea on how I can use this GeoTiff image in JOSM?

 

Cheers,

Daniel

 

 

  _  

 






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

Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information)

[Daniel Begin]

Hi all,

 

I've tried to "put my boots on the ground" without  going there !-).  I
found a pretty clear satellite image of the river at its max level (30-31m)
- which doesn't really changed since ...

 

http://earthobservatory.nasa.gov/NaturalHazards/view.php?id=50577

 

I made few geometric adjustments to the image and compare the result with
30m GeoBase and SRTM contours. Geobase contours gives better results between
St-Jean and L'Île aux Noix but from there to the US boundary, neither
GeoBase nor SRTM is right.

 

I'm trying to produce a flooded area from DEM data while I'm looking at an
image that contains what I'm looking for - the flooded area!  Why not
mapping from it? I understand the image can be used -
http://earthobservatory.nasa.gov/ImageUse/

 

Any idea on how I can use this GeoTiff image in JOSM?

 

Cheers,

Daniel

 

 

  _  

From: Daniel Begin [mailto:jfd...@hotmail.com] 
Sent: May-27-11 15:18
To: 'Brent Fraser'
Cc: 'HOT Openstreetmap'; 'talk-ca'
Subject: Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec,Canada
:Follow-up(Complement of information)

 

Bonjour Brent,

Which one is better in this situation, SRTM or GeoBase?  I would prefer SRTM
for the following reasons...

 

SRTM has 90m cell size but the data in each cell are "real elevation" -
including roof tops and crop height !, 

Geobase has 30m cell size but the data in each cell is an interpolation
between adjacent contour interval from 50K map.

 

So, in flat/low hills areas, SRTM will give a much better idea of the height
than Geobase. For example, a 8m hill, standing between elevation 31m and 39m
won't be visible in Geobase data. Same reasoning for a steep cliff, and so
on...

 

Furthermore, I suspect that using the 30m contour from SRTM might be valid
for St-Jean-Sur-Richelieu area  but the 31m should probably be used near
Lake Champlain.

 

In this case I would quote James Ewen, You need to "Put your boots on the
ground" to decide which one is valid !-)

 

I'm also looking at converting this into .gpx format as proposed Richard

Cheers,

Daniel

 

  _  

From: Brent Fraser [mailto:bfra...@geoanalytic.com] 
Sent: May-27-11 14:19
To: Daniel Begin
Cc: 'Pierre Béland'; 'HOT Openstreetmap'; 'talk-ca'
Subject: Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada
:Follow-up(Complement of information)

 

Daniel,

  The SRTM data has 90m cell size, while the CDED (from the Geobase site)
has 30m cells (and 1m height resolution) which might rendered better
contours.

Best Regards,
Brent Fraser


On 5/27/2011 11:52 AM, Daniel Begin wrote: 

Bonjour tous le monde,

 

I have generated a 30m and 31m contour lines for Richelieu river and lake
Champlain (using SRTM data). It fits the 30m contour provided by
Jean-Guilhem but doesn't seem to fit pretty well the flooded wetland area
provided by Pierre.

 

Any idea if this data can be used (usgs licence point of view)?

And if it can be usefull?

 

Daniel

 

  _  

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: May-27-11 12:40
To: HOT Openstreetmap
Cc: talk-ca
Subject: Re: [HOT] [Talk-ca] Flooding in Richelieu River, Quebec,Canada
:Follow-up(Complement of information)

 

Jean-Guilhem Cailton  wrote on 2011-05-27


> According to the shapefile data, Lake Champlain, and hence
Venise-en-Québec are above the 30 m elevation.

> The shapefile contains punctual elevations of 31 m in this area (Plage
Missisquoi, for example).

> The next contour line would be the 40 m one, but it does not look like it
would be very useful for this.

This is exact. The 40 meter contour line is not usefull for us.

 

Thanks Jean-Guilhem.

 

Pierre Béland

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

Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information)

[Daniel Begin]

Bonjour Brent,

Which one is better in this situation, SRTM or GeoBase?  I would prefer SRTM
for the following reasons...

 

SRTM has 90m cell size but the data in each cell are "real elevation" -
including roof tops and crop height !, 

Geobase has 30m cell size but the data in each cell is an interpolation
between adjacent contour interval from 50K map.

 

So, in flat/low hills areas, SRTM will give a much better idea of the height
than Geobase. For example, a 8m hill, standing between elevation 31m and 39m
won't be visible in Geobase data. Same reasoning for a steep cliff, and so
on...

 

Furthermore, I suspect that using the 30m contour from SRTM might be valid
for St-Jean-Sur-Richelieu area  but the 31m should probably be used near
Lake Champlain.

 

In this case I would quote James Ewen, You need to "Put your boots on the
ground" to decide which one is valid !-)

 

I'm also looking at converting this into .gpx format as proposed Richard

Cheers,

Daniel

 

  _  

From: Brent Fraser [mailto:bfra...@geoanalytic.com] 
Sent: May-27-11 14:19
To: Daniel Begin
Cc: 'Pierre Béland'; 'HOT Openstreetmap'; 'talk-ca'
Subject: Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada
:Follow-up(Complement of information)

 

Daniel,

  The SRTM data has 90m cell size, while the CDED (from the Geobase site)
has 30m cells (and 1m height resolution) which might rendered better
contours.



Best Regards,
Brent Fraser


On 5/27/2011 11:52 AM, Daniel Begin wrote: 

Bonjour tous le monde,

 

I have generated a 30m and 31m contour lines for Richelieu river and lake
Champlain (using SRTM data). It fits the 30m contour provided by
Jean-Guilhem but doesn't seem to fit pretty well the flooded wetland area
provided by Pierre.

 

Any idea if this data can be used (usgs licence point of view)?

And if it can be usefull?

 

Daniel

 

  _  

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: May-27-11 12:40
To: HOT Openstreetmap
Cc: talk-ca
Subject: Re: [HOT] [Talk-ca] Flooding in Richelieu River, Quebec,Canada
:Follow-up(Complement of information)

 

Jean-Guilhem Cailton  wrote on 2011-05-27


> According to the shapefile data, Lake Champlain, and hence
Venise-en-Québec are above the 30 m elevation.

> The shapefile contains punctual elevations of 31 m in this area (Plage
Missisquoi, for example).

> The next contour line would be the 40 m one, but it does not look like it
would be very useful for this.

This is exact. The 40 meter contour line is not usefull for us.

 

Thanks Jean-Guilhem.

 

Pierre Béland

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

Re: [Talk-ca] [HOT] Flooding in Richelieu River, Quebec, Canada :Follow-up(Complement of information)

[Daniel Begin]

Bonjour tous le monde,

 

I have generated a 30m and 31m contour lines for Richelieu river and lake
Champlain (using SRTM data). It fits the 30m contour provided by
Jean-Guilhem but doesn't seem to fit pretty well the flooded wetland area
provided by Pierre.

 

Any idea if this data can be used (usgs licence point of view)?

And if it can be usefull?

 

Daniel

 

  _  

From: Pierre Béland [mailto:infosbelas-...@yahoo.fr] 
Sent: May-27-11 12:40
To: HOT Openstreetmap
Cc: talk-ca
Subject: Re: [HOT] [Talk-ca] Flooding in Richelieu River, Quebec,Canada
:Follow-up(Complement of information)

 

Jean-Guilhem Cailton  wrote on 2011-05-27


> According to the shapefile data, Lake Champlain, and hence
Venise-en-Québec are above the 30 m elevation.

> The shapefile contains punctual elevations of 31 m in this area (Plage
Missisquoi, for example).

> The next contour line would be the 40 m one, but it does not look like it
would be very useful for this.

This is exact. The 40 meter contour line is not usefull for us.

 

Thanks Jean-Guilhem.

 

Pierre Béland

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

Re: [Talk-ca] Geobase vs Canvec

[Daniel Begin]

Hi Nakor, and James

No easy answer! Both should be trusted for what they are ...
- Geobase/Canvec.6: Surface and lanes tag, ways, are 10 years old!
- Canvec.7: ways and name tag have 1 year old, surface/lanes are invalid

>From my own experience in Quebec, Canvec.7 highways have a better accuracy
but too much nodes! However, on some isolated area, you might get planed
road or pretty bad accuracy (I found 1.3 Km offset for some roads on
Anticosti island)

I would agree with James, better check on field - when possible!

Regards,
Daniel

-Original Message-
From: James Ewen [mailto:ve6...@gmail.com] 
Sent: May-24-11 21:18
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Geobase vs Canvec

On Tue, May 24, 2011 at 6:04 PM, Nakor Osm  wrote:

> I was looking at Canvec data vs Geobase data around Pointe-à-la-Croix, QC
> and Campbellton, NB. Geobase is already there but is missing street names.
> Canvec has street names but all ways are marked surface=unpaved and
lanes=-1
> which I guess is false. There are also some inconsistency in highway
> "levels". Which one is more to be trusted?

Put your boots on the ground. Gather local data and verify for
yourself. That's what this OSM project is all about. People getting
out there and gathering data that is available for everyone to use.
CanVec and GeoBase are shortcuts that we have permission to use, but
we should still do our due diligence and ensure the information that
we are importing is accurate by verifying the information with real
world boots on the ground verification.

James
VE6SRV

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


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

Re: [Talk-ca] more Canadian OSM extracts coming

[Daniel Begin]

H!

I didn't knew that extract and planet files were synonyms.  

I presented OSM -the community, the data and the infrastructure- to a
conference on Municipality and Open data last Tuesday.  I'm glad that nobody
asked a question about Extract!

Best regards,
Daniel

-Original Message-
From: Richard Weait [mailto:rich...@weait.com] 
Sent: May-06-11 18:52
To: Daniel Begin
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] more Canadian OSM extracts coming

On Fri, May 6, 2011 at 6:40 PM, Daniel Begin  wrote:
> Hi Richard,
> I'm a bit confuse about the announcement.  What is that for? What purpose
> does it deserved?  I should have miss something!
>
> Cheers,
> Daniel

Dear Daniel,

"Extract" and "planet" files are for people who wish to consume
OpenStreetMap data for some purpose, perhaps to operate their own tile
server. The "planet" file is published once per week and includes data
of the entire planet.  "Extract" files are created by several people,
but not by the OSMF directly, and include OpenStreetMap data for some
fraction of the planet, for people interested in a smaller portion of
the planet.  If their interest is limited geographically, they can use
an extract file, rather than a planet file, and will have smaller data
files to manipulate.  Some people find this advantageous.

An extract file for all of Canada has been available from CloudMade
for a few years.  Now, Geofabrik is offering extracts for selected
Canadian areas.  Currently, for Ontario and for Quebec.  I expect the
Geofabrik will publish new extracts each week.

Does this tell you if you have missed anything?  ;-)

Best regards,
Richard


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

Re: [Talk-ca] more Canadian OSM extracts coming

[Daniel Begin]

Hi Richard,
I'm a bit confuse about the announcement.  What is that for? What purpose
does it deserved?  I should have miss something!

Cheers,
Daniel

-Original Message-
From: Richard Weait [mailto:rich...@weait.com] 
Sent: May-06-11 11:55
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] more Canadian OSM extracts coming

Dear All,

Frederik announced that he will be providing more Canadian extracts of
OSM data in future.  They have already started here:
http://download.geofabrik.de/osm/north-america/canada/

with Ontario and Quebec.  Others will be added as well.  The geofabrik
extracts are in the new pbf format.

Thank you, Frederik!

Best regards,
Richard

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


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

[Talk-ca] FW: Great Lakes shoreline

[Daniel Begin]

Hi guys,  
I should also have send it to the list.  Now it is done!
Daniel

-Original Message-
From: Daniel Begin [mailto:jfd...@hotmail.com] 
Sent: May-04-11 20:07
To: 'James A. Treacy'
Subject: RE: [Talk-ca] Great Lakes shoreline

Hi James

About your question: having a way with natural=coastline and another
(identical) way which is natural=wood works. I don't think two natural tags
does.


Now a proposition to make it easier, because editing coastline is not easy!

1- Copy all Canvec natural=water into a new layer

2- Prepare the new coastline from Canvec data - excluding island
Merge as much natural=water with water=intermittent objects as possible
- JOSM shift-J option.  It might create a relation in the process.
At the end, Delete the corresponding relation if necessary
-  Use the trash icon in the relation window, it keeps the ways.
Clip the shore in the resulting outer untagged ways 
Delete unused outer segments
Tag the resulting shore as natural=coastline

3- Replace the original coastline with your new one
Copy your new coastline in the OSM layer
Join the original coastline to the end nodes of the new coastline
- JOSM j option (remember, there is two end nodes!-)
Clip the original coastline at end nodes of the new coastline
Delete the portion of the original coastline you just replaced
Reverse direction of the new coastline if the land is not on the left side

4- Prepare Islands new coastline from Canvec data
Islands should still be in the new layer you just created

Clip/Edit/Delete unnecessary ways
Tag the remaining untagged ways that are island as natural=coastline

5- Replace the original island with your new one (one at a time is easier)
Copy your new island in the OSM layer
Delete the previous island you just replaced
Reverse direction of the new island if the land is not on the left side

Use the validator before uploading anything!
Now cross your fingers until the display of the coastline is updated !-)

Cheers
Daniel


-Original Message-
From: James A. Treacy [mailto:tre...@debian.org] 
Sent: May-04-11 14:05
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Great Lakes shoreline

I am ready to start changing the Lake Huron coastline over to using
the canvec data. One question I have is about islands. What is the
proper way to have an island that is natural=wood? Is it legal to have
two natural tags or do I need one way which is natural=coastline and
another (identical) way which is natural=wood?

-- 
James (Jay) Treacy
tre...@debian.org

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


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

Re: [Talk-ca] [Talk-us] Proposed import of IBC data (was RE: NAD83-SCRS vs WGS84 Reference systems)

[Daniel Begin]

Hi all,

About turning point, one of the example I sent you is completely composed of
turning points.  

Remember few weeks ago I was writing about a border segment that was
initially based on a stream but the stream changed over years? here it is
http://www.internationalboundarycommission.org/coordinates/HallsStream.htm

About making differences between monument and turning points, We could use
ref=tp (with no space) or create a tag like survey_point=*. I would
prefer adding a prefix.

Cheers,

Daniel


-Original Message-
From: Paul Norman [mailto:penor...@mac.com] 
Sent: March-27-11 18:37
To: 'Richard Weait'; 'Daniel Begin'
Cc: impo...@openstreetmap.org; talk...@openstreetmap.org;
talk-ca@openstreetmap.org
Subject: RE: [Talk-us] Proposed import of IBC data (was RE: [Talk-ca]
NAD83-SCRS vs WGS84 Reference systems)

For the area here, they appear to all have monuments or the imagery is of
insufficient quality to determine. What's the difference between a survey
point and a turning point? Is it that one has a small change in direction
while the other has a large change in direction? 

For the 49th parallel, all of the monuments are of the form Mon xx or Mon.
xx

For the other regions, I see some are of the form TP xx.

I don't think survey_point=turning_point is what we should use.
http://taginfo.openstreetmap.de/keys/survey_point#values shows that it's
mainly used to indicate the physical form of the survey point. 

> -Original Message-
> From: Richard Weait [mailto:rich...@weait.com]
> Sent: Sunday, March 27, 2011 1:46 PM
> To: Daniel Begin
> Cc: impo...@openstreetmap.org; talk...@openstreetmap.org; Paul Norman;
> talk-ca@openstreetmap.org
> Subject: Re: [Talk-us] Proposed import of IBC data (was RE: [Talk-ca]
> NAD83-SCRS vs WGS84 Reference systems)
> 
> On Sun, Mar 27, 2011 at 4:40 PM, Daniel Begin 
> wrote:
> > Thank Paul, a really good idea to include others as they are concerned
> > :-)
> >
> > About tagging, I would agree with minor adjustments ...
> > man_made=survey_point - agreed
> >
> > ref= - agreed to reference a monument id However, I would add a
> > prefix for turning points, helping differentiate them from monuments.
> > I propose the prefix "tp ": ref=tp 123
> 
> I'd prefer to see values without spaces, for ease of consuming
> downstream.  Does the source distinguish between monuments and turning
> points?  If not, perhaps following their lead makes sense by using their
> ref=123, and adding something like survey_point=turning_point, or
> similar?
> 




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

Re: [Talk-ca] Proposed import of IBC data (was RE: NAD83-SCRS vs WGS84 Reference systems)

[Daniel Begin]

Thank Paul, a really good idea to include others as they are concerned :-)

About tagging, I would agree with minor adjustments ...
man_made=survey_point - agreed

ref= - agreed to reference a monument id
However, I would add a prefix for turning points, helping differentiate them
from monuments. I propose the prefix "tp ": ref=tp 123 

source=CA-US International Boundary Commission - Make sense but...
I think we could replace the source tag for the website tag. It would then
point directly to the file, and the source, from witch the coordinates were
retrieved...

Example:
website=http://www.internationalboundarycommission.org/coordinates/HallsStre
am.htm

website=http://www.internationalboundarycommission.org/coordinates/Highlands
.htm

Paul wrote: I don't think it's worth the effort to worry about any
NAD83-CSRS vs. WGS84 - agreed

What do you think about that?

Best regards,
Daniel


-Original Message-
From: Paul Norman [mailto:penor...@mac.com] 
Sent: March-27-11 14:07
To: 'Richard Weait'; 'Daniel Begin'
Cc: talk-ca@openstreetmap.org; talk...@openstreetmap.org;
impo...@openstreetmap.org
Subject: Proposed import of IBC data (was RE: [Talk-ca] NAD83-SCRS vs WGS84
Reference systems)

Adding talk-us@ and imports@ to the cc list since this touches the border.

The IBC data matches decently with the NAIP and Bing imagery on the border,
and very well with my 10cm Surrey imagery. The existing border data in OSM
is about 20m away in parts (near monument 32 for example)

The proposed tagging is
man_made=survey_point
ref=32
source=CA-US International Boundary Commission

I don't think it's worth the effort to worry about any NAD83-CSRS vs. WGS84
differences.

I've uploaded a sample at http://maps.paulnorman.ca/49th.osm


> -Original Message-
> From: Richard Weait [mailto:rich...@weait.com]
> Sent: Sunday, March 27, 2011 6:22 AM
> To: Daniel Begin
> Cc: talk-ca@openstreetmap.org
> Subject: Re: [Talk-ca] NAD83-SCRS vs WGS84 Reference systems
> 
> On Sat, Mar 26, 2011 at 3:55 PM, Daniel Begin 
> wrote:
> > Hi all,
> >
> > I need someone to confirm the following about reference system...
> >
> > Context: Paul and I are uploading US-Canada boundary monuments/turning
> > points to get a stable and verifiable information. The data is
> > available from their web site and I got the confirmation that the data
> > can be used without any restriction.  The data can be found here...
> > http://www.internationalboundarycommission.org/products.html
> >
> > and it is available for NAD27 and NAD83-SCRS reference system.
> >
> > Context: For what I understand, The difference between NAD83-SCRS and
> > WGS84 is 0-2 meters.  To get a rigorous transformation from NAD83-SCRS
> > to WGS84 we need to use shift grids describing the shift between NAD83
> and NAD83-SCRS.
> > These grids should be available through provincial agencies but I have
> > been told that not all provinces have them available.
> >
> > Question1: Do I understand it properly?
> >
> > Question2: Considering that provided coordinates value/reference
> > numbers can be read directly from their web site, it make sense for me
> > to use NAD83-SCRS directly even if there is a 0-2 meter offset.  Does
> > it make sense for everyone?
> 
> Bonjour Daniel!
> 
> We do have others on this list with experience in re-projection.  I hope
> they'll join in.
> 
> I've asked about the shift grids on #osm-dev.
> 
> If I remember correctly, the current Can-US border came from IBC data.
>  How does the current border line match the monument data that you are
> considering?  Should they be identical and are they?  Could we pop this
> data into a tile overlay layer so we can look at it on existing OSM data
> (without the import)?
> 
> Best regards,
> Richard
> 
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca



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

Re: [Talk-ca] NAD83-SCRS vs WGS84 Reference systems

[Daniel Begin]

Hi all

let me review what we received so far

Richard wrote:
"If I remember correctly, the current Can-US border came from IBC data.
How does the current border line match the monument data that you are
considering?  Should they be identical and are they?"

I have been told that IBC recomputed their coordinates 1-2 years ago (new
compensation). I don't know if the border was obtained after they published
the new coordinates. 

I've compared current border line with monument coordinates from IBC in
southern Quebec.  Even if for few coordinates the difference was up to 10
meter, the differences I found were usually within a meter.  That is why I
was considering keeping the CSRS coordinate as is.

Brendan wrote:
"I was musing on a similar topic just recently, which ... [reference]"
I've read the document and I understand that a simple sequence of
multiplication/addition on coordinate values will do the job. Cool!

However, if it is that simple, what are those grid shift they are talking
about (Google: grid shift wgs84 nad83 csrs)? A way to get more accurate
results?

"I assume you mean NAD83(CSRS) coordinates, by the way?"
You are right! I probably used SCRS(1) because, as French is my native
language, I've consulted French documents before going on the list :-)

So, should we convert the IBC nad83-csrs coordinates to wgs84?
yes: Real wgs84 coordinates - confusing info about nad83-csrs conversion
no: Inaccuracy of 0-2 meters in wgs84, direct coordinate values on web site.

Still don't know what the decision should be.

Next time I'll have a simpler question !-)
Cheers,

Daniel

(1) In French, SCRS stands for Système Canadien de Référence Spatiale

-Original Message-
From: Brendan Morley [mailto:morb@beagle.com.au] 
Sent: March-27-11 06:27
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] NAD83-SCRS vs WGS84 Reference systems

Daniel,

I was musing on a similar topic just recently, which I've cc'd to:

http://www.commonmap.org/blog/commonmaps-common-datum/2011-03-27

I assume you mean NAD83(CSRS) coordinates, by the way?

My understanding is the de facto datum of OSM is WGS84/ITRF with epoch 
varying with the age of each entered coordinate, and planimetric 
accuracy at best 10 metres (at 10m, WGS84=ITRF).

Given NAD83 and WGS84 are also within the 10m error, you could just 
argue that you can just upload the coordinates to OSM as is.  Leave a 
note in the changeset (maybe per boundary way?) noting where the 
rigorous values can transformation methods can be found.

However if you want to adjust the coordinates, you could try the 
NAD83->ITRF (WGS84) 7(+3 dynamic) parameter similarity (Helmert) 
conversion for areas without a better option.

This paper is the best I've found on the matter; see Section 4 of:
http://www.geod.nrcan.gc.ca/publications/papers/pdf/nad83csrs.pdf

Remember that the coordinates start drifting with 2-3cm/annum velocity 
as soon as you enter then into OSM!  Do you want to be this rigorous?


Brendan

On 27/03/2011 5:55 AM, Daniel Begin wrote:
> Hi all,
>
> I need someone to confirm the following about reference system...
>
> Context: Paul and I are uploading US-Canada boundary monuments/turning
> points to get a stable and verifiable information. The data is available
> from their web site and I got the confirmation that the data can be used
> without any restriction.  The data can be found here...
> http://www.internationalboundarycommission.org/products.html
>
> and it is available for NAD27 and NAD83-SCRS reference system.
>
> Context: For what I understand, The difference between NAD83-SCRS and
WGS84
> is 0-2 meters.  To get a rigorous transformation from NAD83-SCRS to WGS84
we
> need to use shift grids describing the shift between NAD83 and NAD83-SCRS.
> These grids should be available through provincial agencies but I have
been
> told that not all provinces have them available.
>
> Question1: Do I understand it properly?
>
> Question2: Considering that provided coordinates value/reference numbers
can
> be read directly from their web site, it make sense for me to use
NAD83-SCRS
> directly even if there is a 0-2 meter offset.  Does it make sense for
> everyone?
>
> Cheers,
>
> Daniel
>
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
>
>


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


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