[Talk-us] Brainstorming an Import Tool
filbertk at gmail.com
Tue Aug 17 18:34:47 BST 2010
On Tue, Aug 17, 2010 at 12:54 PM, 80n <80n80n at gmail.com> 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
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.
> 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?).
filbertk at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-us