[Talk-ca] Canvec.osm samples
Daniel Bégin
jfd553 at hotmail.com
Fri Apr 2 01:34:16 BST 2010
Hé Sam,
you have done a great job on that sample datasets
Daniel
_____
From: talk-ca-bounces at openstreetmap.org
[mailto:talk-ca-bounces at openstreetmap.org] On Behalf Of Bégin, Daniel
Sent: April 1, 2010 08:42
To: Sam Vekemans
Cc: Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Canvec.osm samples
Bonjour Sam,
Thanks for the coments! Now, how can I answer briefly to that email? !-)
I'll try in the text
Cheers,
Daniel
_____
From: samvekemans at gmail.com [mailto:samvekemans at gmail.com] On Behalf Of Sam
Vekemans
Sent: 1 avril 2010 01:25
To: Brent Fraser
Cc: Bégin, Daniel; Talk-CA OpenStreetMap
Subject: Re: [Talk-ca] Canvec.osm samples
Hi,
Its AWESOME to see that all of the features are available within the SAME
file. This was something that i attempted todo (last year), but couldn't
figure it out. This helps as it makes for easy copying over. .. when all
these features are in the same .osm file. Thanks.
Regarding natural=reef . ... or sub_sea=reef
what's better natural=reef
http://wiki.openstreetmap.org/wiki/Proposed_features/reef or sub_sea=reef?
http://wiki.openstreetmap.org/wiki/Tag:sub_sea%3Dreef
they are both in the proposed status. .. so im not sure which one is better.
Adding layer=-1 would indicate that it's below the surface. Also. I dont
think it needs to be a closed way. The way it's drawn on Toporama is just
like a natural=cliff (as a line with short angled lines on one side)
Actually, what you see in Toporama is Canvec data - the difference wtih .osm
file is just a questino of rendering. I'll check but may be natural=reef
should be replaced by its associated water feature using water=intermittent;
suface=rock tags .
Regarding water around the coastline. I would say that it's fine to add to
OSM. .. and just merge the nodes all the way along the coastline. .. .. or
remove it?
I would think the exception would be if the waterbody had a name, then it
should be kept. I thing that replacing coastline node with the ones
provided would be the best. By replacing I means move to /copy from /merge
with provided nodes because source=PGS coastline is usually less accurate.
And overall, the natural=wood works for me. On Vancouver Island, we used
landuse=wood. But natural=wood probably is more generic, as the actual
ownership of that area is not known. All we know is that "in this plot of
land there are trees", beyond that, you need to check other sources. Which
sounds reasonable.
.. and we cant say that it's "forest" as that would imply some kind of
protection. (which is unknown for this feature). the tag natural=land for
the nodes (where i once put 'place=island'), natural=land is better, as it
might not always be rocks that the map feature is showing. it's just
"something in the water sticking out permanently"
For waterway=steam. Yes, the geobase waterway=stream is higher quality,
[please, send me an example where GeoBase is of higher quality than CanVec
for the same area] so if people want to load that instead, there is nothing
stopping them. From the data it's hard to know if it's a 'creek' 'stream'
or 'river' so that needs to be physically verified. I would think that the
person loading the data is local, so the would know best. .. but that might
not be always the case. I dont think it's too much troubble to connect
these rivers around the edges. .. and they may not even need to be
connected. ... unless these rivers are for navigating? (i also like to add
the 'oneway=yes' by looking at the contours. Makes for good navigating.
IMO. But what canvec has is just great :)
..... ah ha! there is something. Some of the rivers dont have names, but
the name is available from Toporama. .. this can just be added in :-) When
corresponding GeoBase rivers have the name attached to it, CanVec data will.
For highway=turning_circle the fixme is 'Feature may not exist'. I would
say it's fine, because it would help people to know that they can still do a
3-point-turn. (and that the road probably does actually end.
ok the big ones
highway=tertiary is used for the 'orange' lines with toporama
highway=tertiary is also used for the 'reg' lines in toporama
and it looks like 'unpaved is orange' and 'red is paved'
Actually it is the contrary! Toporama is derived from CanVec - it shows
differences between paved and unpaved tertiary roads by using different
color :-).
There are no duplicate intersecting nodes! Way to go team! :-) Yes!
The 'red lines' that are visably fatter than the tertiary lines. as
'motorways' (for the ones that have more than 2 lanes) these would have a
number reference. (would be a provincial road) otherwise it's a
'secondary' They are supposed to. If some dont, let me know where they
are.
'primary_link' does exist, that's awesome! The CanVec "Ramp" processing is
cleaver.
What i dont see is a "source date" tag. I guess the assumption is that it
all still exists, unless it's known that it doesnt? by local knowledge which
would know better? The only thing that tag says is that the feature was
there at that time. Only local knowledge can confirm that it is still there
wich is the case 95%
...
Yup. From digging through the Quebec sample, i cant find anything wrong.
Can anyone else?
Cheers,
Sam
On Wed, Mar 31, 2010 at 9:02 AM, Brent Fraser <bfraser at geoanalytic.com>
wrote:
My personal favorite, Waterton Park (82H04)in Alberta, specifically the
townsite:
49.0 to 49.1
-113.9 to -114.0
Best Regards,
Brent Fraser
Bégin wrote:
> Bonjour!
>
> I'm ready to release some samples to get your feedback on the Canvec.osm
> product. I wont be able to release complete NTS datasets because tiling
> procedure is not completed yet.
>
> So, if you send me the bounding box of the area you wish to look at
> (max 0.1 X 0.1 degrees lat/lon - all include in the same map sheet), I
> should be able to create the sample an provide it to you and to the
> community. I will identify all created sample in the wiki (Canvec page)
> and they will be made available from NRCan ftp site.
>
> I might produce a dozen of datasets, so, first in - first out!
>
> Cheers,
>
> Daniel
>
>
>
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Talk-ca mailing list
> Talk-ca at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________
Talk-ca mailing list
Talk-ca at openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20100401/dd17a3f9/attachment.html>
More information about the Talk-ca
mailing list