Hi Paul,
It probably won't come to you as a surprise if I would say it is
acceptable, but to a certain degree. A map with no data is not a map. A
map with inconsistent data is still a map, but obviously something is
not right. A map with perfectly consistent data doesn't need to tell the
truth either. Remember the fantasy city someone added about a month ago?
Furthermore, a map can become outdated. This is also true for OSM.
Anyways, the reason I've been importing Canvec data is to provide more
coverage, so others can work with it. OSM is a community project, and I
think everyone has a share in it. This is one of the main reasons I
started with OSM, because I believe in the ideals and goals. To you it
might sound that importers like me are leaving a "big mess" behind for
others to deal with. To me, it was a choice. The alternative would be
either no data, or very sparse and incomplete data. It would take ages
to "complete" the map, since there are not nearly as much mappers in
Canada as there are in Germany. A map which is only half complete
doesn't have half the value of a complete map, but way less. That's also
the reason I imported forests in suburban areas. It can still be cleaned
up later. Leaving the forest out of it leaves an ugly gap, and fixing it
during the import is so time consuming the import would go on endlessly
(which it does already...).
Also, many or most people who are mapping with OSM do not have a mapping
or geospatial background. Let me be clear, I think it is wonderful that
they join OSM and step upon the learning curve to become a contributor.
On the other hand, in many cases the quality of their contributions are
not that great. I also don't like the fact that something is abandoned
half-way (like the Canvec import). So the choice I made was to provide
them and the rest of the community with some kind of baseline. With the
Canvec data imported, it makes it easier for people to add POI's and
other stuff. And while importing, I also fixed other errors which
existed in the maps. Of course not all of them, but what would be
reasonably possible from my armchair. Furthermore, the imports I've done
about half a year ago were aimed at filling gaps between existing
imports. It is a pretty daunting task, so it is no surprise many have
stopped, and I just wanted to get the job done.
However, time is limited, so I eventually decided to stop. The reasons
which motivated me doing imports are no longer enough to continue. It is
partially due to the criticism of you and others. If my contributions
are not accepted / acceptable, there is no reason to continue, so I can
better stop. I also think that OSM has caused a lot of awareness for
open data, and governments are opening up much more. For example, also
in the Netherlands a lot of datasets have become open data, like the
national road register, buildings, and topography. Of course, with the
availability of Canvec, this is also true in Canada. So for many
geospatial professionals there is not much reason to continue OSM,
except when you're interested in areas for which no other alternative
exists (cycling routes, historic buildings, etc.).
Frank
On 10-11-2012 12:37, 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
[email protected]
http://lists.openstreetmap.org/listinfo/talk-ca
_______________________________________________
Talk-ca mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/talk-ca
