OK accepting what you say is there a way to identify where an old OSM road was so that some one can go back and clean up the new geobase added data?  Connect the roads and insert road sections that have been deleted?  I think Toronto organised something that recognised the quality of the data by marking it verified etc.

On the clean up side is there an easy way to copy the tags on one section of road onto another?  For example when I extend a geobase road up to the old OSM road I'd like to have the same tags as the other sections of the road.  At a quick glance I can see at least seven sections that need to be added back in within 600 meters.

My personal view is the amount of effort to clean up the data required is probably often
going to be greater than the amount of effort put into creating the OSM map in the first place.

On the tag issue, its not simply a matter of the quantity of tags means higher quality data but if the tag doesn't have a value then the information doesn't exist.  For example Merkley Drive geobase import has a tag saying 2 lanes.  Charlemange has four lanes but no tag giving that value in the potlatch input.  I've learnt over the years with databases that some idiot somewhere will invariably want to use a tag like this and not realise that some roads don't have a value.  It is unfortunate that the geobase tag data can't be dragged over and associated with the OSM roads.

Is there a geobase identifier on a road that could be added manually as a tag so that a script could drag in the rest of the tag values?   This would probably mean having a  pure geobase OSM map somewhere that could be used to pick out these values.

Thanks

Cheerio John

James Ewen wrote:
On Sun, Oct 25, 2009 at 10:43 AM, john whelan <jwhelan0...@gmail.com> wrote:

  
What appears to have happened is where the data has been merged roads
that are in the geobase database no longer connect to roads that have
been put in via potlatch.  I think the end point is dropped.
    

There is a discontinuity between the GeoBase data, and existing OSM
data. The script that was used to determine which Geobase data to
import was designed to stop short of the OSM data. Since the OSM data
does not match exactly to the GeoBase data, it was impossible to have
the two seamlessly merge. It is up to the OSM users to stitch the two
together. The GeoBase data allows the OSM community to leverage the
massive amount of data available in the GeoBase database.

  
 The older potlatch roads do not have the same depth of tags
as the geobase data.
    

This sounds like you believe that the quantity of tags associated with
a way some how infers higher quality data. One can not automatically
assume that the GeoBase data is of higher quality than the OSM data
simply because there are more tags associated. In some cases, the
positional accuracy of the GeoBase data is better than OSM data, but
in other instances, the OSM data positional accuracy is better than
GeoBase. It all depends upon the amount of effort expended during the
input process.

  
 Not only that but roads that run close to the old roads appear
to be deleted for the section close to the potlatch inputted roads.
    

That's the GeoBase input script trying to match GeoBase roads to
existing OSM roads. When they are close enough in geometry, the
GeoBase roads get dropped. Preference is given to OSM data over
GeoBase because the OSM data has been provided by the OSM community.
Real people have invested many hours of their time to input their
data. GeoBase data is being automatically input by a machine. We need
to respect the OSM community investment over the automated imports.

  
Oh and my WAAS enabled GPS thinks at least one Potlatch inputted road
is in the wrong place.
    

Yes, that can be very true. Some roads have been input by simply
tracing low resolution imagery, and the resultant roads can be fairly
crude. As an OSM participant, you can help improve the database by
converting your GPS traces to roads. You can also use the "real
intelligence" built into the human brain to make informed decisions
about how to merge the OSM and GeoBase data into the best map database
possible.

  
My personal view is that we should go with the geobase database and
see if we can layer on tags etc.  That way we can update the database
from time to time by replacing the entire geobase data layer.
    

Of course you are entitled to your opinion, but options were discussed
in this forum, and decisions made on how best to go about merging the
OSM and GeoBase data. From those decisions, the scripts were created,
and import activities started. I think you will find very little
support for keeping the GeoBase data as a pristine import layer that
can be changed out en masse. This would limit the amount of mapping
that the OSM community could do in Canada. We would be limited to only
adding data that is not maintained in the GeoBase database. There
would be no ability to correct or modify the GeoBase road database as
any changes made would be wiped out by the next en masse GeoBase layer
import.

The reason for the GeoBase import is to simply add a large amount of
fairly accurate road data to an area of low population density. in
Canada, we have a huge road network, and very few people to import
that data. By importing GeoBase data provided by the government, we
get a large amount of data, but we still have the capability of
modifying that data.

  
I think OSM can add value in Canada basically by tagging and enhancing
data already there, if a client can get geobase data elsewhere that
actually has connecting roads and complete roads they may prefer that
to OSM where the data quality isn't so consistent.
    

Here you are absolutely correct. OSM is all about providing the best
FREE map data for the world. Anyone is free to use the OSM data, or
they can go elsewhere to find the data they require. However, it is
not possible to upload changes, corrections and additions to the
GeoBase data as an end user. It is possible to do these things as an
OSM end user.

The GeoBase import was simply a shortcut implemented to get a large
quantity of data into the database, and now it is up to the OSM
community to manipulate that data as they see fit.


James
VE6SRV

_______________________________________________
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

Reply via email to