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 
 =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 andersontris...@hotmail.com 
wrote:

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

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


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

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

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

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

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

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 andersontris...@hotmail.com 
wrote:

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

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


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

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

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

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

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

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

Any objections?




 From: jfd...@hotmail.com
 To: scr...@gmail.com; talk-ca@openstreetmap.org
 Date: Thu, 23 Jul 2015 10:08:44 -0400
 Subject: Re: [Talk-ca] Highway recoding
 
 Thank Russel,
 Your description is pretty close of the one I had in mind (about trunks) 
 before I found the Canadian definition was referring to the mentioned

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

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] 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 http://ftp2.cits.rncan.gc.ca/OSM/pub/
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 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
(Core, Feeder, Northern and Remote) that does not fit with OSM highway
definitions. 

 

I prefer looking at OSM highway as infrastructure categories -my

[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] 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] 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 some 
name of shop somewhere in this block. While probably correct, they're not 
very useful.

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

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

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

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


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

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) 
http://www.openstreetmap.org/relation/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) 
https://www.openstreetmap.org/relation/1747232#map=12/45.6634/-73.5294   
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) 
https://www.openstreetmap.org/relation/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  mailto:pierz...@yahoo.fr pierz...@yahoo.fr
À : Simon Poole  mailto:si...@poole.ch si...@poole.ch;  
mailto:talk-ca@openstreetmap.org talk-ca@openstreetmap.org  
mailto: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  mailto:si...@poole.ch si...@poole.ch
À :  mailto:talk-ca@openstreetmap.org 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  
https://www.openstreetmap.org/relation/1747232 (broken geometry, no islands)

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


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


https://www.openstreetmap.org/relation/1746332  
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
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  mailto:bremy.qc...@gmail.com bremy.qc...@gmail.com
À : Paul Norman  mailto:penor...@mac.com penor...@mac.com 
Cc :  mailto:talk-ca@openstreetmap.org 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]

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 dar...@aleph-com.net 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 andrew.alli...@teksavvy.com 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]

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 dar...@aleph-com.net 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 andrew.alli...@teksavvy.com 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 
http://mvexel.dev.openstreetmap.org/bingimageanalyzer/?lat=49.3935298445362lon=10.976469421386724zoom=11
 lon=10.976469421386724zoom=11

Bruno

 

2014-09-19 9:28 GMT-04:00 Pierre Béland pierz...@yahoo.fr:

Bonjour Bruno,

 

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

 

Pierre 

  _  

De : Bruno Remy bremy.qc...@gmail.com
À : James Mast rickmastfa...@hotmail.com 
Cc : talk-ca@openstreetmap.org 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 rickmastfa...@hotmail.com:

 

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]

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 jfd...@hotmail.com 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 tom.taylor.s...@gmail.com:

 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  http://www.openstreetmap.org/user/CanvecImports 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 pierz...@yahoo.fr
À : talk-ca@openstreetmap.org 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 pierz...@yahoo.fr
À : Charles Basenga Kiyanda perso...@charleskiyanda.com;
talk-ca@openstreetmap.org 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 perso...@charleskiyanda.com
À : 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.

[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
 mailto:soham.s...@grey.ca soham.s...@grey.ca
 http://www.grey.ca/it http://www.grey.ca/it
 http://www.visitgrey.ca/ http://www.visitgrey.ca

 http://www.greyroots.com http://www.greyroots.com 

 https://facebook.com/CountyOfGrey Image removed by sender. Facebook
https://twitter.com/GreyCounty Image removed by sender. Twitter
http://www.linkedin.com/company/505390 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]

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 kli...@gmail.com wrote:

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

 

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

 

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

 

Comments?

 

 Harald.

 

On Tue, Nov 26, 2013 at 10:25 AM, Daniel Begin jfd...@hotmail.com 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 jfd...@hotmail.com wrote:

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

Daniel

 

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

 

+1 for the Maproulette.org solution.

 

Bernie.

--

Bernie Connors, P.Eng

Tel: 506-444-2077 

bernie.conn...@snb.ca

SNB - We make it happen.

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 jfd...@hotmail.com wrote:

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

 

About all motorway_link in Canada are having the same problem!

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

 

 Harald.

 





 

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





 

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





 

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

image001.jpg___
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 pierz...@yahoo.fr wrote:
 Richard

 I dont think that we should advocate against import.

Then we differ.

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

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

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

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

Invariably, they aren't the exception.

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

The linked thread regarding the NYC building import discusses ways to do it
better.

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

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

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

But never import.**

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

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

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

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


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

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)
bernie.conn...@snb.ca 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 jfd...@hotmail.com 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 jfd...@hotmail.com wrote:

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

Daniel

 

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

 

+1 for the Maproulette.org solution.

 

Bernie.

--

Bernie Connors, P.Eng

Tel: 506-444-2077 

bernie.conn...@snb.ca

SNB - We make it happen.

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 jfd...@hotmail.com wrote:

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

 

About all motorway_link in Canada are having the same problem!

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

 

 Harald.

 





 

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





 

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

image001.jpg___
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 jfd...@hotmail.com wrote:

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

 

About all motorway_link in Canada are having the same problem!

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

 

 Harald.

 

image001.jpg___
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 jfd...@hotmail.com wrote:

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

Daniel

 

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

 

+1 for the Maproulette.org solution.

 

Bernie.

--

Bernie Connors, P.Eng

Tel: 506-444-2077 

bernie.conn...@snb.ca

SNB - We make it happen.

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 jfd...@hotmail.com wrote:

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

 

About all motorway_link in Canada are having the same problem!

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

 

 Harald.

 





 

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

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

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 jfd...@hotmail.com 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] 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
http://www.openstreetmap.org/#map=14/45.0011/-72.1567layers=C 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 jfd...@hotmail.com wrote:

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

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

 Harald. 

___
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

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

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 bremy.qc...@gmail.com 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 bluc...@gmail.com 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 bremy.qc...@gmail.com

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 Pratteguilla...@guillaumepratte.net 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 
 http://www.openstreetmap.org/?mlat=45.49634mlon=-73.62245#map=19/45.49634/-73.62245
  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

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 jfd...@hotmail.com
À : 'Pascal Robichaud' pascal.robichaud.do...@gmail.com; 'Bruno Remy' 
bremy.qc...@gmail.com 
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 bremy.qc...@gmail.com 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 bluc...@gmail.com 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 bremy.qc...@gmail.com

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 Pratteguilla...@guillaumepratte.net 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

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 kli...@gmail.com 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) 
 bernie.conn...@snb.ca
 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, I click on View way on larger map
 . I get an URL similar to this that I can share:
 

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] 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
nicholas.inga...@gmail.com 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 tom.taylor.s...@gmail.com
À : Harald Kliems kli...@gmail.com 
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 anyone
finding an 

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.695lon=-73.905zoom=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 bremy.qc...@gmail.com 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 kli...@gmail.com 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 andrew...@gmail.com

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




 --
 Please use encrypted communication whenever 

[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.6101lon=-73.4411zoom=13layers=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] 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.35107lon=-72.22763zoom=15layers=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 jfd...@hotmail.com
À : 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.62953lon=-72.1247zoom=16layers=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] 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.0167lon=-71.3602zoom=13layers=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] 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.0167lon=-71.3602zoom=13layers=M
lon=-71.3602zoom=13layers=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] 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 jfd...@hotmail.com:
 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] 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 ref99 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)
bernie.conn...@snb.ca 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 

[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.295lon=-73.005zoom=9layers=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.977lon=-70.9076zoom=12layers=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.374933lon=-71.932442zoom=18layers=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
http://opengeodata.org/big-baseball-project-2011?utm_source=feedburnerutm_
medium=feedutm_campaign=Feed%3A+Opengeodata+%28OpenGeoData%29
utm_medium=feedutm_campaign=Feed%3A+Opengeodata+%28OpenGeoData%29

Suivez les indications à You'll find more
http://wiki.openstreetmap.org/wiki/Big_baseball_project_2011  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] 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.01442lon=-74.73045zoom=16layers=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.mapFORMA
T=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautrichelieu20
110508_natcol
FORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=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.mapFORMA
T=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=hautrichelieu20
110508_swir
FORMAT=image/jpegVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLayers=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]

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

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 jfd...@hotmail.com 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

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

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 jfd...@hotmail.com
 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] [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 jfd...@hotmail.com
 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

[Talk-ca] NAD83-SCRS vs WGS84 Reference systems

[Daniel Begin]

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

Re: [Talk-ca] Batch transformation from rcn_ref=1 to Route

[Daniel Begin]

Hi John

 

I understand that alouette995 is trying to find/get all object in Quebec
with rcn_ref=1 tag.  Is there a way to do such a request?

 

By the way, I might be interested in your VB program :-)

 

Daniel

 

  _  

From: john whelan [mailto:jwhelan0...@gmail.com] 
Sent: March-10-11 16:57
To: alouette...@gmail.com
Cc: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Batch transformation from rcn_ref=1 to Route

 

One technique is simply to use JOSM, select the ways you want to modify then
add the tag to all the ways in the selection.  You can also delete tags in
this way as well.

Just be aware that standardization seems to be a word that OSM is not always
comfortable with.

The other technique if you are happy in VB is to get a local .osm file of
Quebec then have a program run down the file to create changes to be
uploaded by JOSM.  I suggest you test it on a small area first.

I can email you a basic VB program that does something similar if that would
be of use.  Be aware that bots and software such as this can create havoc.

Je suis capable de lire le français but as you can see fairly hopeless at
writing it.

Cheerio John

On 10 March 2011 16:33, alouette...@gmail.com wrote:

Hi,

 

I am new in OSM world ... my project is to develop and improve the
OpenCycleMap for the province of Quebec.

 

I recently acquired the skills to edit tags for Cycleways and I am now
confortable.

 

Now for my problem...

 

I realise that a lot of contributors have develop the Regional Cycling
Network for “La route verte” (the provincial cycling route) but with lack of
uniformity. Some have use tags(rcn=yes and rcn_ref=x) for each way and other
have use the “add to a route” feature to update a global route. Route seem
to be a better idea..

 

What I want to do is transform all tracks to the “add to route” technique.
Is there a tool to make batchs modification to a lot of object on OSM? What
I think about is:

 

1- Find all object in Quebec only (rcn_ref=1 could exist elsewhere in the
world) that have the tag rcn_ref=1

2- Create the relation for this object with “La route verte 1” (same as if
we have use add to a route feature)

3- Delete tags rcn=yes and rcn_ref=1 from theses objects because it became
obsolete

 

Doing that to each route will standardize almost all the network in one
operation but doing this by hand can take months.

 

Is there a tool or some readings that can help me with this project?

 

Or is there OSM meeting near Montreal where I can have that kind of
discussions.

 

Thanks,

 

As you can read english is not my mother tongue ... please forgive errors
but I am sure that you known what I am searching for.


___
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] Boundary and updates

[Daniel Begin]

Hi all,

 

First, the routing apps we are being using for two days is pretty useful,
I've been able to make many corrections to the road network I uploaded in
the area for connection/one way errors.

 

However, I need advises on another topic...

 

I'm uploading Canvec around Canada/US boundary and I try to get a clean
result both side. The area I'm working on have the US-Canadian boundary
defined by a small river.  The river has changed his course over the years
and neither the Canvec boundary nor the OSM boundary fit with the river
anymore.

 

Updating the river raises many questions.

I worked a lot of time updating the river that was mapped as an area.  The
job is not finished  yet and I wonder if replacing it with a simple way
tagged waterway=river would be acceptable ? - The potential replacing way is
already uploaded.

 

What do we do with the boundary?  Keep the OSM untouched? Displace the
boundary over the river? Any comments or suggestions

 

Have a look 

http://www.openstreetmap.org/?lat=45.0371lon=-71.4813zoom=14layers=M

 

Daniel

 

 

 

 

 

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

Re: [Talk-ca] Mapping cut blocks in wooded areas

[Daniel Begin]

Hi Samuel,

 

About tagging forested areas, I would use landuse=forest only if it is
obvious on the field that the area is managed/harvested, as for
landuse=orchard or landuse=vineyard. We have a lot of Christmas tree
plantations in the area and I map them as landuse=forest because it is
obvious on the imagery and on the field.  

 

If it is difficult to determine if an area is under timber lease or not,
because it looks the same, I would keep it natural=wood...

 

About Cut blocks, I would map the hole they create that wooded area.  If the
area is replanted, then some OSM contributor will remove the hole you map in
10-20 years from now! 

 

Mapping the reality is the best we can do and because the reality changes
over time, we can keep mapping !-)

 

Daniel

 

  _  

From: Samuel Longiaru [mailto:longi...@shaw.ca] 
Sent: March-04-11 21:45
To: talk-ca
Subject: [Talk-ca] Mapping cut blocks in wooded areas

 

Hi Everybody,

I've been importing CanVec mostly south of Kamloops for the past several
weeks and am going to take some time now to go back and bring stuff up to
date.  One question I have though is in regards to how to treat cut blocks
in the wooded areas.

I see according to the map features wiki, that the CanVec imported tag of
natural=wood is technically not correct, at least for here, as wood is to be
reserved only for completely reserved/unmanaged areas.  I guess most of what
I have should really be mapped as landuse=forest but I have not made the
change because what is under timber lease and what is not would be difficult
to determine.  In one sense it's all managed to some degree or other.  But
my point is rather what should be done with the cut blocks, which in some
areas constitute up to 50% or more of the forested area.
http://osm.org/go/WJ1cj_R is a typical area.  It seems improper to keep them
as wooded when they are clearly not, and yet most are replanted and will be
wooded again someday... or at least that's what they keep telling us.

I started mapping them as it truly gives a more accurate representation of
the current state of affairs on the ground... but thought I'd better get
some guidance before proceeding too far.  

Thanks,

Sam L.
Kamloops 

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

[Talk-ca] FW: About OSM communication channels

[Daniel Begin]

This message was intended to the whole community

-Original Message-
From: Richard Weait [mailto:rich...@weait.com] 
Sent: January-28-11 12:49
To: Daniel Begin
Subject: Re: [Talk-ca] About OSM communication channels

On Fri, Jan 28, 2011 at 12:25 PM, Daniel Begin jfd...@hotmail.com wrote:
 Bonjour Richard,

My dear friend,

You replied directly to me, perhaps you meant to send this to the list
as well?  I get caught by that reply setting as well from time to
time.

 actually, every things seem fine except that the number of exchanges is
 pretty low. I remember that the list was busier when we were trying to
 convert NRCan data.  Now that it is available maybe we are all to busy
 uploading/updating data?

Perhaps.  I wonder if some people find starting a topic too scary?

 About improving the list, I find it difficult to talk about local topics
on
 a national list.  Or express myself in French, not because I feel exclude
 from the list (:-) but because I want to be understand by what seems to me
 the vast majority of contributors. However, the talk-ca list does the job
 when needed.

Ah, but talk-ca@ is a local list in the context of the global
OpenStreetMap project!  You should feel free to express yourself in
either official language of Canada. Canadians are also welcome to
participate on the talk-fr@ list, in French, with other francophones
from France, Belgium, Canada and other countries.

 About other OSM communication channels, a mailing list seems the best for
me
 considering my agenda (don't have time for IRC). However, may be an other
 communication channel would help me to discuss more local topic in French.

Perhaps you would like to add a local indication to the Subject for
very-local topics.  I sometimes remember to do this when  I announce
local meetings.  That reminds me; time to announce another local
meeting. ;-)

Best regards,
Richard


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

Re: [Talk-ca] CanVec Import

[Daniel Begin]

I agree with Olivier,

It certainly needs more effort but the result is there.  Blind import never
helps.  It just mess-up with others work. 

Blind Canvec import could have been done by NRCan, messing-up all the work
done by each OSM contributor. It doesn't help the project to have the
impression that our work is not respected because a bunch of data is dump
over what we have already map...

Cheers,
Daniel

-Original Message-
From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Olivier Hill
Sent: December-31-10 11:50
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] CanVec Import

Hello all,

I would like to remind everyone not to blindly import CanVec tiles on OSM.

I have recently seen tiles uploaded blindly, duplicating nodes and
duplicating features that were already imported (like wooded areas,
lakes, rivers, etc.)

I know it is tempting to see more data on OSM, but dirty data has no
value. Uploading tiles in batch is not crowd sourcing either as it can
be easily done with software.

Personally, I prefer less data but with better quality than having to
validate everything that has been imported again and again. This can
of course be discussed here, others might have different opinions.

Now, private messages have been sent to specific authors. If no
answers provided, we will have to make the choice to revert the
changesets or not.

Thank you for your understanding (and inputs).

Best regards,
Olivier

-- 
http://www.olivierhill.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

Re: [Talk-ca] [OpenStreetMap] Water

[Daniel Begin]

Salut Frank,

September-12-10 03:30 Frank Steggink wrote:

... am focused on land use data import in the Netherlands. This is a huge
effort as well. The large block of land use coverage was imported by myself:

http://osm.org/go/0GQJNa. Although the Netherlands is much smaller than 
Canada, this data is very detailed. You should zoom in and have a look :)

- Incredible, we are not there yet! However, as I consider that mapping
Canada is like eating a whale with a spoon, we might eventually get there
!-)

... If you happen to import data north of Quebec City, you can also remove
the forests I've previously imported, since they are divided into 5x5 tiles
per Canvec sheet.

- I wont, It is just nice like that. Because the Canvec geometric model
enable us to import selected layers, we can jus import what is missing. It
was a great job!

Regards,

Daniel


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

Re: [Talk-ca] Merging CanVec data, updating status

[Daniel Begin]

Hi Michael and all

 

I have set up a  Canvec Import - Work in progress section in the wiki...

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

 

It aims at keeping track of what is going on with Canvec Import.  It doesn't
aim at keeping an history of what have been done, neither to manage what
have not been done yet.   Just keeping track of area people are actually
importing.

 

And it may be easier to maintain than the Google chart !-)

 

If you wish to import Canvec to a white space in OSM, just look at the
wiki...

 

- If it is listed as Work in progress, choose an other area;

- If not, register the tile (NTS number) in the wiki and start to import;

- When finished, just remove the tile name from the wiki.

 

Of course, everyone is free to use it or not :-)

Cheers,

 

Daniel

  _  

From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Steve Singer
Sent: July-30-10 21:56
To: mi...@carterfamily.ca; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Merging CanVec data, updating status

 



 
 I was wondering is there anyone else editing in Ontario. If everyone 
 keeps putting the CanVec tile code they processed in the comments 
 section of the changeset, I don't mind updating this spreadsheet. Just 
 need to know who's working on CanVec tiles.

I'm hoping to give at the 031E6 tiles a shot.

When I try to look at that tab in the spreadsheet  I get the current window
is too small... and I'm unable to get it to scroll 
the screen past the first few rows.

 
 Michael
 
 
 ___
 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] Merging CanVec data, updating status

[Daniel Begin]

Hi all,

Why don't we register only Work in progress in the wiki?
- What have been done is obvious on the map!
- What have to be done is also obvious on the map!

If you wish to import Canvec to a white space in OSM,
just look at the wiki...

- If it is listed as Work in progress, choose an other area;  
- If not, register the tile (NTS number) in the wiki and start to import;
- When finished, just remove the tile name from the wiki.

Seems simple to me, without all number of rows limitations.

Daniel

-Original Message-
From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans
Sent: July-30-10 10:52
To: G. Michael Carter; Talk-CA OpenStreetMap; Andrew MacKinnon
Subject: Re: [Talk-ca] Merging CanVec data, updating status

yes, i heard it way over on the west coast.


ok, here's the storey.

1 - we need to shorten the length (number of rows) on the main big
google docs spreadsheet.
so that all of the distant, easy stuff is marked as a series.  ie.
034-9 area - available
then i can just remove that whole section of rows.
so then the areas that are being worked on is clear.


there are currently about 10 people editing the main chart, and only
andrew and yourself on the secondary chart that you started.


what i can do is make a copy of the main chart, then start merging the
rows, and adding in rows for the quad-tree tiling.

the google  docs chart has a maximum number of rows that are allowed,
and it's been reached.


ideally, if everyone is on irc chat while working, this helps. but
it's hard to get everyone on the same page :-/


this way, we can merge the tabs to a greater range, i think this will help
too,
so after 4 tiles ofthe quadtree area is done, it only needs to take up
1 row in the spreadsheet.

On 7/30/10, G. Michael Carter mi...@carterfamily.ca wrote:
 Did anyone hear that loud bang last night...?  That was my head
 repeatedly hitting the table while I repeated the words look before you
 leap! :-)

 I spent 1 hour updating and processing a CanVec tile.  When I was
 finished I ran the verification step and fixed duplicates.   Then when I
 started to go through the duplicates, I noticed +12,000 duplicate nodes
 and over 5,000 duplicate ways (or something like that).   Upon further
 investigation, andrewpmk had already processed and uploaded the grid.
 *grin*   That's what I get for taking a short cut and downloading the
 current data into the CanVec layer and processing it all at once.
 (which I do in the barren areas which no real city data yet)

 Needless to say I've gone through andrewpmk's edits list and updated

https://spreadsheets.google.com/ccc?key=0Ati4aAtBXfTVdERaUWZPNWhxTDJFOTF4STF
La25HbVEhl=en


 I was wondering is there anyone else editing in Ontario.  If everyone
 keeps putting the CanVec tile code they processed in the comments
 section of the changeset, I don't mind updating this spreadsheet.  Just
 need to know who's working on CanVec tiles.

 Michael


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



-- 
Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room)
@Acrosscanadatrails

___
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] 001k - coastline

[Daniel Begin]

Hi all,

When you say 'ocean water polygons', I guess you are talking about modifying
natural=coastline ways (PGS or others) that define oceans among other things
using/for Canvec data?

I usually prefer to keep the original data and make it fits on the (assumed
better) reference data.  Furthermore, playing with natural=coastline feature
might be tricky - because it does not tolerate gap in it. 

So, except for 'river mouth', I would consider to alter the original
coastline by fitting it on Canvec features that define high water level.  

For intermittent water (reef, sand or other) I use the water cover proposed
feature http://wiki.openstreetmap.org/wiki/Proposed_features/Water_cover

- Read http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Water_cover
Unified proposition.

However, sometime it does not make sense because it is too complex/tedious!
We are doing that fun! aren't we?  

In such case - if the procedure above seems more complex than the following:

   
- Replace the coastline by the corresponding segment of the water polygon;
- Replace natural=water tag by natural=coastline;
- Make sure all coastline ways are linked/snapped together;
- Clean up the mess!

For river mouth - because the coastline should stop somewhere ...
I would clip the shoreline (and join the two segment together) before
replacing the river's shoreline with water polygon.

et bla,bla,bla ...

Cheers,
Daniel



-Original Message-
From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans
Sent: July-09-10 01:22
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] 001k - coastline

Hi all,
Thanks Daniel,
On the #osm-ca IRC we were trying to figure out the best solution for
'ocean water polygons'.

Its basically this, if the body of water is a 'bay' or 'river mouth'
or has 'reefs' or 'no flow coastal water', then we use the
natural=water polygon, and just smooth out the jagged edges.
Daniel did this on a more conservative way so its even better.

Its up for debate, and one of those things that we will notice after
the map is more complete.
Another option, is to streatch out the water, just as far as where the
'deep ocean' starts. We have a WMS layer which shows this.
This allows for the naming of these water areas.

Cheers,
Sam


-- 
Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
IRC: irc://irc.oftc.net #osm-ca Canadian OSM channel (an open chat room)
@Acrosscanadatrails

___
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] Newbie to the Canadian mapping scene looking forexamples of well mapped areas

[Daniel Begin]

Hi Tyler and all!

 

I would consider Sherbrooke as a well mapped area!-)

http://www.openstreetmap.org/?lat=45.3788lon=-71.8948zoom=14layers=B000FT
F

 

Actually there are plenty of good examples around the country, each of them
having their own color.

 

Welcome

 

Daniel

 

  _  

From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans
Sent: April 13, 2010 22:26
To: john whelan
Cc: Kevin Michael Smith; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Newbie to the Canadian mapping scene looking
forexamples of well mapped areas

 

Hi Tyler, 
Welcome.

Yup, thats alot of houses.  Great work!

A couple things.

1 - You can use Toporama from Natural Resources Canada, and set it up as a
WMS layer in JOSM

http://wms.ess-ws.nrcan.gc.ca/wms/toporama_en?LAYERS=limits,vegetation,built
up_areas,designated_areas,hydrography,hypsography,water_saturated_soils,land
forms,constructions,water_features,road_network,railway,populated_places,str
uctures,power_network,feature_names
http://wms.ess-ws.nrcan.gc.ca/wms/toporama_en?LAYERS=limits,vegetation,buil
tup_areas,designated_areas,hydrography,hypsography,water_saturated_soils,lan
dforms,constructions,water_features,road_network,railway,populated_places,st
ructures,power_network,feature_namesSERVICE=WMSVERSION=1.1.1REQUEST=GetMa
pSTYLES=EXCEPTIONS=application/vnd.ogc.se_inimageFORMAT=image/png
SERVICE=WMSVERSION=1.1.1REQUEST=GetMapSTYLES=EXCEPTIONS=application/vnd
.ogc.se_inimageFORMAT=image/png

You can trace all you want  as much detail as you like.  Toporama is
derived from the exact same source as CanVec  GeoBase, and it's the same
level of detail.  (you might have seen that on the Canada wiki page)

There is a TONNE of information, so i'd recommend just mapping what you
like.  Others will join in once they see your area so well detailed  let
the competition begin!   (Quality in a small area, beats quantity over a big
area IMO)

2 - The Town of Duncan, BC On Vancouver Island is perhaps the best  mapped
place in Canada. 
Although we did get some help from  (Local Mappers / Landsat / Yahoo imagery
/ CanVec/Toporama/GeoBaseNRN/ GeoBaseNHN/Cowichan Valley Regional District /
Atlas of Canada / NRCan geogratis ).   Great work Kevin Smith! (who is the
top contributor)   This is a wonderful example of a combination of efforts
from multiple sources.

http://www.openstreetmap.org/?lat=48.77478
http://www.openstreetmap.org/?lat=48.77478lon=-123.69681zoom=16layers=B0
00FTF lon=-123.69681zoom=16layers=B000FTF

3 - 

On Tue, Apr 13, 2010 at 6:28 PM, john whelan jwhelan0...@gmail.com wrote:

A purely personal point of view.  I like the footpaths, Google doesn't have
these.  I'm not so sure about the houses as a block.  I'd be more inclined
to drop in street numbers in post code blocks using addr:interpolation
http://wiki.openstreetmap.org/wiki/Key:addr:interpolation . 


for example http://www.openstreetmap.org/?lat=45.47761
http://www.openstreetmap.org/?lat=45.47761lon=-75.484175zoom=18layers=B0
00FTF lon=-75.484175zoom=18layers=B000FTF

The reason for this is to cram in as much useful information as possible
whilst minimising the number of points in the GIS database.  Each house has
a min of four points as a block, using interpolation two points can
represent a block of ten houses.  Be aware though that I worked as an
assembler language programmer forty years ago when computer resources were
much more expensive than they are today but I still like to consider them so
I'm bias.


Yup, and how you already have houses drawn in.  It will make the map look
even better.

Cheers,
Sam
 


Postcode searches don't exactly work as they should in Canada at the moment
but being able to look up an address helps routing software etc.

Any buses run in the area?  Bus stops can be useful to people trying to find
their way by public transport.

Any businesses or stores around?  Supermarkets perhaps that are open 24
hours?  Tag them with their web site, phone number, type of business etc.
Especially decent coffee shops, you never know I might want to visit
sometime.

OSM is electronic so add tags in JOSM perhaps to POIs.  Once the data is in
the database different rendering solutions can pull or present different
images based on what the user would like to see.

Cheerio John






On 13 April 2010 20:25, Tyler Gunn ty...@egunn.com wrote:

I discovered OSM a few weeks ago and have been hooked since.  I've been
refining the existing map data for my subdivision, adding new roads,
cleaning up existing ones, and adding POIs.

I've also traced all the houses in my subdivision and am planning to head
out with a stack of WalkingPapers and gather POIs and address mappings:
http://www.openstreetmap.org/?lat=49.78226
http://www.openstreetmap.org/?lat=49.78226lon=-97.16557zoom=16layers=B00
0FTF lon=-97.16557zoom=16layers=B000FTF

Can anyone out there recommend good examples of well mapped areas in Canada?
I'm just looking to get a feel for what 

Re: [Talk-ca] Canvec tile splitter 999x33 a to y 5x5 and/or put on adedicated API?

[Daniel Begin]

Hi Sam and all 

I'm wondering if the best tiling is a fixed number of tiles (5X5) or if it
should be defined as a maximum size of some type for a tile.  

Using JOSM/Canvec files, I worked in high density urban areas where a 4X8
tiling was almost insufficient.  For some rural areas, a 2X2 tiling was just
fine. A 5X5 tiling for Canvec is just an averaging of needed tiling value! 

Knowing an optimal size value for default JOSM configuration, we could tile
any type of data using a Quadtree algorithm

http://en.wikipedia.org/wiki/Quadtree

Let suppose the optimal tile size is 2M (the initial tile is the file)

For each tile:
  Is processed tile size  2M?
  Yes: then there is no need for sub-tiling - stop processing the tile
  No : Split the processed tile 2X2 then repeat the process

You would end up with 1, 4, 12, 16 ... tiles having a file size  2M with
some of the tiles covering 1/48, other 1/4 of the processed area!  Using
Canvec data, I would be surprised that tiling needs to go deeper than 8
levels (1/48) for some of the tile.

What would be this optimal size for JOSM? Kilobytes, nodes, feature? I don't
know!  Even the number of members in Relation seems to affect JOSM.

If we can find some hard facts to define it, this could be implemented as
the tiling algorithm.

Cheers,
 
Daniel


 (-Xmx256M) 
-Original Message-
From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans
Sent: March 28, 2010 12:26
To: impo...@openstreetmap.org; Talk-CA OpenStreetMap
Subject: [Talk-ca] Canvec tile splitter 999x33 a to y 5x5 and/or put on
adedicated API?

Hi all,
We are getting more progress on Vancouver Island, thanks to (haitelk)
who has just added in more wooded area. And the new CVRD data is in
the planning, discussing  sorting data phase. :-)

What we still need todo is make a tool that will automatically slice
the NTS tiles (canvec .osm files) into 25 pieces, so then a local area
mapper can easly take 1 square at a time  work with it, choosing the
data that they need to add in.


I think that OSmosis has this ability, has anyone varified this?
This will be of great help to everyone, as we are also using the
Toporama WMS layer to be tracing  using it for reference.

Otherwise, if we dont have the 1/25th tile area, its harder to ensure
that no 'bulk_implopping' happens where the user gets lazy and doesnt
bother to check the area 1st.

Since the 1/25th tile size is a standard JOSM working space, we would
(just about all of the time), have only 1 mapper is working at a time.
(even in the big cities, this size is managable).

Oh, this whole CanVec dataset would be great to host on a different
API, (like i talked about on my last message for OpenImportsMap does
anyone know if perhaps the devAPI would be a good place for it? Or
should we make a new one that is dedicated to wholesale imports?

Thanks,
Sam
-- 
Twitter: @Acrosscanada
Blogs: http://acrosscanadatrails.posterous.com/
http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
Skype: samvekemans
OpenStreetMap IRC: http://irc.openstreetmap.org
@Acrosscanadatrails

___
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] OSM - Haiti disaster

[Daniel Begin]

You don't know what to do this weekend.

 

http://wiki.openstreetmap.org/wiki/WikiProject_Haiti#2010_Earthquake_Respons
e

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

[Talk-ca] OSM - Haiti desaster

[Daniel Begin]

Amazing!

 

Have a look at the following link.  It gives a idea about what we can do as
osm mapper.

 

http://brainoff.com/weblog/2010/01/14/1518

 

Daniel

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

[Talk-ca] OSM - Haiti disaster

[Daniel Begin]

Amazing!

 

Have a look at the following links.  It gives a idea about what we can do as
osm mapper.

 

http://brainoff.com/weblog/2010/01/14/1518

http://www.gisuser.com/content/view/15767/28/

 

 

Daniel

 

 

 

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

[Talk-ca] FW: Canvec import in Montréal with ? names

[Daniel Begin]

Hi all, I'm guilty!

Actually, I'm importing the Canvec road network in Laval (north of Montreal)
because I've done a lot GPS mapping in this area.  Last week I used
canvec-to-osm to convert the rest of the road network.  So, if the tags are
not appropriate, something should be modified in the application.  

Curiously, I used the same application few weeks ago near Sherbrooke area
and did not have that problem?!!  Someone can explain it to me?

However, I am in the process of correcting the data I imported. It has not
only odd tags but a problem using JOSM creates a lot of duplicate ways.

Which tags do you suggest I keep/remove? Pierre-Luc suggested me to remove
tags with ? values, any other suggestions? I can easily removed odd tags
at the same time I'm correcting my ways.

Cheers,

Daniel

-Original Message-
From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Pierre-Luc Beaudoin
Sent: December 10, 2009 23:18
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] Canvec import in Montréal with ? names

Hi,

I've been a little disconnected about the whole import process. Tonight
I've seen CanVec streets appear in my neighboorhood with odd tags such
as:

http://www.openstreetmap.org/?lat=45.509963468565353lon=-73.561728000640869
zoom=18
name = ?
name2= ?
address:street:leftside=?
address:street:rightside=?
is_in=?

I believe such approach is unproductive as it takes quite a lot of work
to clean up the tags afterwards or even to print a nice map without ?
everywhere.

Tags should not be set to FIXME or ?.  They should not be set. Then
they'll show up on the no name layer. Please someone fix that import
script. :)

Pierre-Luc


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

Re: [Talk-ca] GeobaseNHN-to-osm.bat

[Daniel Begin]

Hi guys,

Actually, I've found it difficult to understand where to get all the data
available (until last weekend!).  I was disappointed when I got my hand on
the Canvec .osm file and found out that there were neither roads nor
hydrography. 

So, I would prefer having all the hydrography - and roads - in the Canvec
version (instead of having to get the roads somewhere, hydrography somewhere
else, and the rest of it in the Canvec file!).  

I would find it much easier to get one zip file with a complete coherent
mapping content (and I guess I'm not alone in that case...)

Cheers,

Daniel

Ps:  Another concern... Some of the Geobase NHN watersheds are so huge that
I have serious doubt about common system's capacity to work with those
files.


-Original Message-
From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans
Sent: November 2, 2009 21:25
To: Frank Steggink; Yan Morin; Talk-CA OpenStreetMap
Subject: [Talk-ca] GeobaseNHN-to-osm.bat

Hi all,
re: geobase -linear_network_flow  canvec's single line watercourse

I think that (the water direction arrow) is the only feature that isnt
available in CanVec, so i think that it will be fine to simply run the
geobaseNHN-to-osm script where it only converts that 1 file.
(its useful for whitewater maps)


Re: waterbody

I know that Yan already loaded the area in Quebec, which is great.
So im wondering if it should be omited from the canvec version, and a
python script be used to convert ALL geobaseNHN (as well as LNflow (or
SLW)?
Or should we use the canvec version of it?

An idea is to just have the canvec script include it, and prefix the
file name with EXTRA_

Thoughts?
Sam


-- 
Twitter: @Acrosscanada
Blog:  http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
OpenStreetMap IRC: http://irc.openstreetmap.org
@Acrosscanadatrails

___
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-to-osm v0.9.5 now cooler than before

[Daniel Begin]

Bonjour Sam, bonjour tout le monde!

I was almost certain and yesterday I got confirmation from NRCan that Canvec
has Geobase inside - Canvec Road and Hydro network are a COPY of Geobase
NRN-NHN.

It says that everything added in Geobase since the last Canvec release is
included in the new release. It also says that Canvec contains street name
(attached to the way) if they are available from Geobase, the same for lake
and river names!  Someone can confirm/object to that statement?

I started a few weeks ago to use JSOM to import Canvec features and I was
disappointed there were no roads or hydrography in converted files.

Considering it seems to have no differences between Geobase and Canvec, why
don't we keep Canvec roads and or hydrography in the datasets? 

It would be much easier - and stimulating - to get all the content in the
zip file and start to upload the area, starting with roads, then the
hydrography, railroads, and so on!

Sam, if the community agree with me that there is no raison (but six month)
to use the full Canvec content - including roads and hydrography - could
CanVec-to-osm be modified and do the job?

I love the idea of having some people converting NRCan data and let the
others (like me) uploading the .osm result in Openstreetmap. Can we make it
easier by packaging one zip file with all the content?

Hope so!

Daniel


-Original Message-
From: talk-ca-boun...@openstreetmap.org
[mailto:talk-ca-boun...@openstreetmap.org] On Behalf Of Sam Vekemans
Sent: October 21, 2009 01:52
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] CanVec-to-osm v0.9.5 now cooler than before

Hi all,
i'm processing select areas on request, the script now basically
downloads/unzips/converts/adds source details/zips 16 canvec tiles in
1 key stroke :)

The biggest thing to note is that these files will be in constant
upgrade  revision mode, as the source files change every 6 months.
But fortunately, its at the point now that you can copy in what ever
features you want. (future changes will be 'relatevely' minor)
I'll just make suggestions on what additional things need to be done
(outlined in the readme.txt file) ... Which still needs some fixing up
:)


geobaseNHN-to-osm v0.3.4.0 updates:

-River Names, because this might be added to canvec later on, its
still best to use geobaseNHN data
-for the ISLANDS polygons, you'll need to reverse the direction of the
ways, to counter-clockwise, alternatively, we could simply omit the
natural=coastline tag and just have place=island.
Because the 'wooded_area' file often is on those islands, it would
still be rendered.
-extra nodes the JOSM validator plugin would help, as it would
spot where thesea extra nodes are lurking, and be zapped. :)
-the 'extra' folder, i think it needs to be fixed up a little more, as
some features should be available as a full file.

Although, like all features, as long as the physical geometry is in
place, a 'CanBot' can be made to run over the country and make
changes. As we see the need. ... so it isn't really THAT necessary to
be too picky about the 'correct' tags.  (BTW, argh!  thats why i keep
the canvec:CODE tag,  so it can be found-replaced) :-)

Anyway, i already know who the main people are for areas... so this
week im converting those areas and trying to get feedback :)

thats all for now,
Cheers,
Sam
-- 
Twitter: @Acrosscanada
Blog:  http://Acrosscanadatrails.blogspot.com
Facebook: http://www.facebook.com/sam.vekemans
OpenStreetMap IRC: http://irc.openstreetmap.org
@Acrosscanadatrails

___
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