On Tue, Aug 17, 2010 at 12:54 PM, 80n <[email protected]> wrote: > 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. > > I'd press for this as a starting point. Render the data and make it > available to trace. The community can do the rest. > > 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.
My 2 cents... Totally agree that community consensus for importing a dataset is key. For logging permissions, some ticketing system might be good. Wikimedia uses OTRS, among other things, for logging permissions to use photographs and other materials. 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. 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). 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. Then people can "adopt" tiles, census blocks, etc. for their local areas or places they are familiar with and import them. 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. 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. -Katie > But given a rendered map then crowdsourcing can do the rest and a community > can grow around it at the same time. > > 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?). > > 80n > -- Katie Filbert [email protected] @filbertkm
_______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-us
