<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font face="Verdana">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. <br>
<br>
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.<br>
<br>
My personal view is the amount of effort to clean up the data required
is probably often </font><font face="Verdana">going to </font><font
 face="Verdana">be greater than the amount of effort put into creating
the OSM map in the first place.<br>
</font><br>
<font face="Verdana">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 </font><font face="Verdana">in the
potlatch input</font><font face="Verdana">.  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.<br>
<br>
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.<br>
<br>
Thanks<br>
</font><br>
<font face="Verdana">Cheerio John</font><br>
<br>
James Ewen wrote:
<blockquote
 cite="mid:fe2e5b210910251146o77b5ea2r5d99c43f95e4ae0b@mail.gmail.com"
 type="cite">
  <pre wrap="">On Sun, Oct 25, 2009 at 10:43 AM, john whelan <a class="moz-txt-link-rfc2396E" href="mailto:jwhelan0112@gmail.com"><jwhelan0112@gmail.com></a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

  </pre>
  <blockquote type="cite">
    <pre wrap=""> The older potlatch roads do not have the same depth of tags
as the geobase data.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

  </pre>
  <blockquote type="cite">
    <pre wrap=""> 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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

  </pre>
  <blockquote type="cite">
    <pre wrap="">Oh and my WAAS enabled GPS thinks at least one Potlatch inputted road
is in the wrong place.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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.

  </pre>
  <blockquote type="cite">
    <pre wrap="">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.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
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
<a class="moz-txt-link-abbreviated" href="mailto:Talk-ca@openstreetmap.org">Talk-ca@openstreetmap.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstreetmap.org/listinfo/talk-ca">http://lists.openstreetmap.org/listinfo/talk-ca</a>
  </pre>
</blockquote>
</body>
</html>