Frank Steggink november 13 2012 15h37
answering Paul Norman
> 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,
I came too late to OSM to see the mapping parties like the ones you were
participating in Sherbrooke. I think that we should come back to that spirit,
For OSM to be a success in Canada, we need stronger local communities, pursue
imports and improve over it. Lets compare us to France. Discussions on the
Osm-France list show a well organize community, a lot of projects, servers,
monitoring tools, blog, mapping parties even in schools, support of local
communities, contacts with municipalities and other organizations. They show a
very good dynamism. In comparison, I have to say that in Canada we not only
have a blank map, we also have a blank participation. I would also like to see
criticisms about imports accompanied with more suggestions to improve.
Otherwise, it is just killing the OSM project.
Pierre
>________________________________
> De : Frank Steggink <stegg...@steggink.org>
>À : talk-ca@openstreetmap.org
>Envoyé le : Mardi 13 novembre 2012 15h37
>Objet : Re: [Talk-ca] Internal CanVec conflicts
>
>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
>> 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
