<div class="gmail_quote">On Fri, Jun 19, 2009 at 1:48 PM, Ævar Arnfjörð Bjarmason <span dir="ltr"><<a href="mailto:avarab@gmail.com">avarab@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;">
On Wed, Jun 17, 2009 at 11:45 PM, Alan Millar<<a href="mailto:am12@bolis.com">am12@bolis.com</a>> wrote:<br>
>>> It should be sufficient to keep the canvec:UUID, source and attribution<br>
>>> tags, and maybe a few of the other canvec:* (CMAS?). I don't see why we<br>
>>> would need most of the others. If someone is really interested in them,<br>
>>> they<br>
>>> can look them up in Canvec using the UUID.<br>
><br>
> Right.  And anyone interested in the AND details can look them up<br>
> somewhere else.  And anyone interested in the TIGER details can look them<br>
> up somewhere else.  And anyone interested in the USGS Geonames details can<br>
> look them up somewhere else.  And so on, and so on, and so on for each<br>
> import, of which the number and scope continue to grow.<br>
<br>
+1<br>
<br>
Please import all the data. OSM should seek to become the canonical<br>
source for all free geodata, having free data split across multiple<br>
databases is the problem we're trying to solve, not introduce.<br>
<br>
Anyone using Canvec today should should be able to use OSM as a<br>
drop-in replacement.</blockquote><div><br>While I agree with what you're saying, I don't agree with the way it's being done: we should not store the definition of the Canvec data types on every single data point. if we want OSM to be a drop-in replacement for the data imports that we add (barring licensing, of course), then we need to put these data definitions somewhere else (the wiki, for example). Every other data import I've been involved with has done this, so I don't understand why we need to start for Canvec.<br>
</div></div><br>