<br><br><div class="gmail_quote">On Thu, Jun 11, 2009 at 12:18 AM, Michael Barabanov <span dir="ltr"><<a href="mailto:michael.barabanov@gmail.com">michael.barabanov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Another way of incorporating the updates (without using UUIDs) would<br>
be to re-run roadmatcher. Given that we'll like will want to do it<br>
anyway (geobase will have new roads), maybe preserving UUIDs isn't a<br>
big deal after all. Another reason we'd likely use another roadmatcher<br>
run for things like addresses is because existing osm ways don't<br>
replaced with geobase and so don't get UUIDs.<br>
<br>
Michael.<br>
<div><div></div><div class="h5"><br>
</div></div></blockquote><div><br>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?<br>
<br>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?<br>
<br>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.<br>
<br>Richard Degelder<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="h5"><br>
<br>
On 6/10/09, Richard Degelder <<a href="mailto:rtdegelder@gmail.com">rtdegelder@gmail.com</a>> wrote:<br>
> Simon,<br>
><br>
> Combining the ways will defeat the possibilities of further use of the<br>
> GeoBase data for the area.  Unfortunately the GeoBase NID is unique for the<br>
> single segment only and combining multiple segments will make adding<br>
> additional data based on those unique NIDs, such as address data, impossible<br>
> as will further updates to the data in future GeoBase updates.<br>
><br>
> The only practical method to deal with the data is, as Richard Weait<br>
> suggested, to use relationships for the data that is common for the ways.<br>
> This is unlike the American model for the TIGER import but it also allows us<br>
> to modify and update the data much better based on future GeoBase updates<br>
> and to later incorporate additional data that we did not use in the intitial<br>
> GeoBase import.  Of course this does not prevent individual mappers from<br>
> adding aditional details or even new ways onto the map at the same time or<br>
> for correcting the map where there are errors or changes prior to a GeoBase<br>
> update being rolled out over an area.<br>
><br>
> Rchard Degelder<br>
><br>
<br>
</div></div><font color="#888888">--<br>
Sent from my mobile device<br>
</font></blockquote></div><br>