<div class="gmail_quote">On Tue, Aug 17, 2010 at 12:54 PM, 80n <span dir="ltr"><<a href="mailto:80n80n@gmail.com">80n80n@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The lowest common denominator here is simple tracing.  Any useful map data will be renderable in some form or other and the community has tracing skills in spades.<br><br>I'd press for this as a starting point.  Render the data and make it available to trace.  The community can do the rest.<br>

<br>The technical obstacles for importing any data set are quite high and the issues diverse enough that automated methods are way beyond the skill set of most OSMers.  </blockquote><div><br>My 2 cents...<br><br>Totally agree that community consensus for importing a dataset is key.  <br>

<br>For logging permissions, some ticketing system might be good.  
Wikimedia uses OTRS, among other things, for logging permissions to use 
photographs and other materials. <br><br>
As there are many issues when working with varying datasets, one tool 
fits all approach is not appropriate.  At minimum, the tools need to be 
highly flexible and people can't be mandated to use them.  Instead 
giving people a toolbox (e.g. w/ JOSM, data converters, QGIS, ...) + 
documentation may be good.<br>
<br>In some cases, it has worked to use the shp-to-osm tool to go 
directly from shapefile to osm format (then to work with in JOSM),   In 
other cases, I have done more complex processing, using PostGIS + QGIS, 
before converting to OSM.  Then, I am checking things in JOSM and/or 
QGIS to compare with the existing OSM data, and with imagery (USGS WMS).<br>
<br>As for breaking up the work load, I am fairly satisfied with the 
CANVEC import process, making OSM format files available (with the 
dataset broken into tiles).  Breaking data up by watersheds for the NHD 
data is good too, or for DC GIS imports, I am breaking it up by census 
tract or census block.<br>
<br>Then people can "adopt" tiles, census blocks, etc. for their local areas or places they are familiar with and import them.  <br><br>If at all possible, building a working relationship between the local 
OSM mappers & GIS data providers is a very good thing.  Invite folks
 from the GIS / gov agency to mapping parties, and bring some into the 
community, and together with local mappers, be stewards of the data.<br><br>When
 imports are overly-automated, I have seen messes that the local mapper 
then needs to spend quite a lot of time & effort to cleanup.  That's
 discouraging and should be avoided, if at all possible.<br>
<br>-Katie<br><br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">But given a rendered map then crowdsourcing can do the rest and a community can grow around it at the same time.<br>

<br>Automated imports just short circuit the community forming process and lead to areas that are sterile.  (Does anyone have an activity heat map that can highlight sterile areas btw?).<br><font color="#888888"><br>80n</font><br clear="all">
</blockquote></div><br>-- <br>Katie Filbert<br><a href="mailto:filbertk@gmail.com">filbertk@gmail.com</a><br>@filbertkm<br>