[Talk-ca] "Opération Cowboy" à Québec

[Bruno Remy]

*Bonjour à tous,
Pour votre information, la communauté locale d'OpenStreetMap Capitale
Nationale* se joint à

 *OPÉRATION COWBOY* !

*Opération Cowboy
*est un
"mapathon" organisé la fin de semaine 23-25 Novembre par
OpenStreetMap à l'échelle mondiale, pour soutenir la communauté OSM aux
États-Unis (et corriger les données de TIGER!). Un peu partout en Europe et
ailleurs, des groupes OSM organiseront ces "mapathon" alors nous aussi, à
Québec le *samedi 24 novembre*, nous ferons notre part !

Différents aspects seront abordés:

   - Bonnes pratiques générales à respecter
   - Outils web de révision et de contrôle de qualité
   - Révision des cours d'eau, lacs, rivières et ponts
   - Révision des embranchements de route (maproulette)
   - Révision des erreurs (bugs)
   - Enrichissement d'une ville ou d'une université américaine.
   - Etc...

Voir les détails de notre évènement de Québec :

http://opcowboy2012qc.eventbrite.ca/


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

Re: [Talk-ca] Internal CanVec conflicts

[Harald Kliems]

I've already said what I have to say about the issue at hand in
earlier discussion. A more lighthearted remark: whenever I feel
depressed about some Canvec-related issue I load up JOSM, pick a
random location in the US, and spend half an hour fixing TIGER data.
It's a very effective therapeutic...

 Harald, who's currently spending a lot of time with this
http://lima.schaaltreinen.nl/remap/

On Sat, Nov 10, 2012 at 6:37 AM, Paul Norman  wrote:
> CanVec data comes from multiple sources and this can lead to internal
> inconsistencies. A common case is a new development where there used to be
> trees. The tree data in CanVec might be older and show an area as forested
> while there is newer road data indicating that the area has been developed.
> An example of this type is
> http://www.openstreetmap.org/?lat=45.695&lon=-73.905&zoom=17 although I have
> seen many other cases of it.
>
> Another common case is the trees in water problem frequently found in BC. A
> typical example is
> http://www.openstreetmap.org/?lat=58.648&lon=-123.911&zoom=17 where there is
> a conflict between the water data and the forest data. You need to view the
> data as it doesn't show up on the rendering.
>
> Is it the communities view that it is okay to import CanVec without
> reconciling the internal differences between the layers?
>
> My view is that importing data without resolving conflicts of this type
> where it conflicts with either existing data or internally is not an
> acceptable import and indicates the importer did not sufficiently review
> what they were uploading.
>
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-ca



-- 
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] Internal CanVec conflicts

[Daniel Begin]

Hi all, 

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

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

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

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

Daniel

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

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


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

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

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

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

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

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

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