Thank you Iván for the added advice!  So one thing you mentioned that Serge didn't is that once data is imported it should be maintained?  I am just wondering because if one goes through extensive preparation to import the data then why is it that it would need to be maintained?  I understand if that user is contacted for something that might have went wrong or might have changed, but for the most part isn't the data that is imported to OSM in it's final stage and should be considered complete?  If you could explain to me what qualifies as maintaining data that has already been imported, that would be great!  I am trying to have a heads up on all these different scenarios before I go head-first into OSM.<br>
<br>Thank you for your time and kind advice :),<br><br>elshae<br><br><div class="gmail_quote">2011/1/18 Iván Sánchez Ortega <span dir="ltr"><<a href="mailto:ivan@sanchezortega.es">ivan@sanchezortega.es</a>></span><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">On Tuesday 18 January 2011 17:16:42 Serge Wroclawski wrote:<br>
<br>
> [...] generally the community doesn't like [imports], and usually it has to<br>
<div class="im">> do with poor execution, and overlapping data.<br>
<br>
</div>That answer is spot-on. I do like imports, but only when it is certain that<br>
there will be no overlapping data, and that the imported data will be<br>
maintained in the future. Otherwise, an import may look like a good thing in<br>
the short term, but it will have long-term complications.<br>
<br>
Unfortunately, the OSM technology stack lacks proper conflation and tracking<br>
scripts. Plus, every set of imported data is different. So, be very very sure<br>
of what you're trying to do. Don't rush the import. Build your own tools if<br>
needed. Contact people in areas where there might be overlapping data for<br>
their opinions.<br>
<div class="im"><br>
> 4. Technology<br>
><br>
> If your data is in PostGIS now, it shouldn't be too hard to write a<br>
> script that extracts the features and makes it available in the OSM<br>
> XML format, ready to be consumed by the API.<br>
<br>
</div>ogr2osm should be capable to do that, with a few tweaks - right now it doesn't<br>
know how to open a PostGIS dataset, but it should be feasible if you know a<br>
bit of python and GDAL.<br>
<br>
Usually the data is loaded into JOSM to check its consistency, and fix the<br>
importing scripts if needed. If everything goes well and there's no need for<br>
conflation, only then that data shall be uploaded with the bulk uploading<br>
tools.<br>
<br>
<br>
Best,<br>
<font color="#888888">--<br>
----------------------------------<br>
Iván Sánchez Ortega <<a href="mailto:ivan@sanchezortega.es">ivan@sanchezortega.es</a>> <<a href="mailto:ivan@geonerd.org">ivan@geonerd.org</a>><br>
<br>
Buscad lo suficiente, buscad lo que basta. Y no querais más. Lo que pasa<br>
de ahi, es agobio, no alivio; apesadumbra en vez de levantar.<br>
                -- San Agustín. (354-439) Obispo, filósofo y Padre de la<br>
                Iglesia Latina.<br>
</font></blockquote></div><br>