<div class="gmail_quote">On Fri, May 16, 2008 at 3:14 PM, Andrew MacKinnon <<a href="mailto:andrewpmk@gmail.com" target="_blank">andrewpmk@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

On Fri, May 16, 2008 at 8:00 AM, Richard Fairhurst <<a href="mailto:richard@systemed.net" target="_blank">richard@systemed.net</a>> wrote:<br>
> Nic Roets wrote:<br>
><br>
>> If someone made the effort to physically survey it and properly tag<br>
>> it, I think it's OK.<br>
><br>
> Maintainability is probably a bigger issue than notability. Roads,<br>
> railways and canals don't move much, rivers hardly at all - we can<br>
> cope with maintaining that sort of database.<br>
><br>
> But where people have gone into vast amounts of detail on something<br>
> that changes rapidly, such as shops on a High Street, the data will<br>
> get out of date very quickly unless they're prepared to return and<br>
> resurvey frequently. Here's an example (fortunately not rendered by<br>
> any of the main renderers): <a href="http://www.openstreetmap.org/edit" target="_blank">http://www.openstreetmap.org/edit</a>?<br>
> lat=51.70619&lon=-0.61222&zoom=17<br>
<br>
I think this would be best done by implementing some sort of "layers"<br>
in OSM. Suppose that general-interest data is tagged without a prefix.<br>
Specialist data can be tagged with a prefix, e.g.<br>
"category:key=value". Then, editors, renderers and output plugins<br>
could filter out unwanted data using an API call (like the filters in<br>
osmxapi) so that they don't waste time downloading it. I see nothing<br>
wrong with putting specialized data in the main database as long as<br>
there is an easy way to filter it out if the user doesn't want it.<br>
Splitting data into multiple databases seems unnecessary.<br>
<br>
As for out-of-date data, OSM is a wiki, so it is the responsibility of<br>
the person who put in the data or subsequent passers-by to correct it.<br>
As long as the data doesn't change extremely frequently (like daily or<br>
weekly), I think it is OK to put it in the main database.<br>
</blockquote></div><br>I agree--some sort of system to elide data that's more special-interest is going to be necessary eventually, otherwise editing will be impossible. I've come across some parcel map shapefiles for a few counties here in the US (I'm sure a lot of counties have it available), but that data would really get in the way of editing roads, so I haven't pursued importing them.<br>
<br>Karl<br>