[Talk-ca] Cleaning up after the GeoBase import

[Richard Degelder]

On Thu, Jun 11, 2009 at 12:18 AM, Michael Barabanov <
michael.barabanov at gmail.com> wrote:

> Another way of incorporating the updates (without using UUIDs) would
> be to re-run roadmatcher. Given that we'll like will want to do it
> anyway (geobase will have new roads), maybe preserving UUIDs isn't a
> big deal after all. Another reason we'd likely use another roadmatcher
> run for things like addresses is because existing osm ways don't
> replaced with geobase and so don't get UUIDs.
>
> Michael.
>
>
Although I agree that we would like to run RoadMatcher again with updates
from GeoBase and for adding additional data from GeoBase into OSM.  We would
first have to run a script that divides ways into the same format as
GeoBase, that is with seperate ways between junctions prior to doing so.  We
are going to have to run such a script regardless to account for work that
was contributed people who did not follow the GeoBase methology or where
people updated areas and combined ways after the local GeoBase import in
order to gibe these ways their GeoBase UUIDs.  But why combine ways now so
that we are going to have to divide them up again later?

Over time people are going to edit the areas that have been imported with
GeoBase data and we are going to lose some of the GeoBase UUIDs in the
process.  Some of thse edits will be because roads were closed or modified
but some are just going to be because the person editing the map never knew
the value of the GeoBase NID and so deleted it in some form.  This is going
to make the work of updating areas more difficult and slower because we are
going to have to import, again, the GeoBase NID for those segments, and
likely to break up ways into segments.  But why speed up the process by
deliberately combining ways and losing the GeoBase NIDs and knowingly
forcing any future updates to first resplit the ways into the original
segments and angainimporting the GeoBase NIDs?

Essentially if we start combining the ways we are going to make this a one
time import with any updating from GeoBase in the future becoming much more
difficult and time consuming than it will be worth.  We would be throwing
away the potential of adding the address data that we have, which already
exists but needs to be added with a new series of scripts, and any new
roadways that will appear in future GeoBase updates.  Although the mapis
significantly richer from this ongoing import from GeoBase we would be
limiting the potential of OSM in the future to what we are able to
personally map.  This country is far too vast with far too few mappers to be
able to say that GeoBase data is not going to be valuable in the future as
well.

Richard Degelder

>
>
> On 6/10/09, Richard Degelder <rtdegelder at gmail.com> wrote:
> > Simon,
> >
> > Combining the ways will defeat the possibilities of further use of the
> > GeoBase data for the area.  Unfortunately the GeoBase NID is unique for
> the
> > single segment only and combining multiple segments will make adding
> > additional data based on those unique NIDs, such as address data,
> impossible
> > as will further updates to the data in future GeoBase updates.
> >
> > The only practical method to deal with the data is, as Richard Weait
> > suggested, to use relationships for the data that is common for the ways.
> > This is unlike the American model for the TIGER import but it also allows
> us
> > to modify and update the data much better based on future GeoBase updates
> > and to later incorporate additional data that we did not use in the
> intitial
> > GeoBase import.  Of course this does not prevent individual mappers from
> > adding aditional details or even new ways onto the map at the same time
> or
> > for correcting the map where there are errors or changes prior to a
> GeoBase
> > update being rolled out over an area.
> >
> > Rchard Degelder
> >
>
> --
> Sent from my mobile device
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-ca/attachments/20090611/16573a14/attachment.html>