[Talk-us] A Friendly Guide to 'Bots and Imports

[James U]

I have to say that after importing a large amount of NHD data (most of NC 
and MN) that it is of varying quality, as was the preexisting water related 
data already on the server.  In general, I agree with Ian that it is higher 
quality (both resolution and accuracy) than the preexisting data that 
largely consisted of quickly drawn Yahoo traces.  I saw very little evidence 
of on the ground surveying of these features and don't think the import 
will hinder most people from participating in OSM writ large.

I have a fair bit of experience in converting data and would be happy to 
convert subbasins (these appear to be rougly 2500 square mile areas 
and are documented on the wiki) for people if they want to go through 
the process of double checking to make sure the data don't conflict with 
or overlap already existing data.

James

On Thursday, August 05, 2010 04:29:19 pm David Carmean wrote:
> On Thu, Aug 05, 2010 at 01:38:36PM -0500, Ian Dees wrote:
> > I think the NHD "import" is a good example of a well-intentioned 
importer
> > (me) gone wrong. I had initially planned to import the whole darn 
thing
> > in one swoop, but various technical and life challenges came up 
before I
> > could get it going. While I was working on those issues, people 
started
> > importing it themselves (sometimes marking so on the wiki, 
sometimes
> > not). Now that there are some areas imported, the import of the 
whole
> > dataset becomes infinitely harder because we have to match existing 
data
> > with new OSM-ified data.
> 
> And I'll add my own mea-culpa.  I created some wiki pages/features to
> help partition and coordinate NHD import efforts, and then also found
> that I didn't have the time to follow up.
> 
> I would agree that the partial imports will have increased the difficulty
> of a large-scale bulk import, but we already had hydrographic features
> from TIGER, did we not.  And hand-drawn features from aerial traces 
and
> actual boots-on-the-ground mapping.  Conflation in general is a tough
> problem, I gather.  There are tools, algorithms and heuristics in the
> GIS world but the OSM data model makes translation between the two 
models
> somewhat difficult.
> 
> For example, something that looks very interesting which I plan to 
examine
> is the Java Conflation Suite [1], which looks like it could be used over
> relatively small areas (probably about the size of the API limit... 0.25
> degrees square?).  But as a component of the JUMP[2] platform, it 
operates
> only on Shapefiles and GML out of the box.  (If we could get some Java
> expertise I think it would be very worthwhile working with the JUMP team
> to create an OSM driver.)
> 
> At any rate, while I think we could mitigate a number of problems
> given some development effort, I also agree that we might want to
> spend more time thinking about why we want to make the imports--and
> perhaps publically debate, if only in talking to yourself on the
> project wiki page, the pros and cons of a particular import.
> 
> 
> 
> [1] http://www.vividsolutions.com/JCS/
> [2] http://www.vividsolutions.com/jump/
> 
> 
> 
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us