On Tue, Nov 17, 2009 at 8:23 AM, Andy Allan <[email protected]> wrote: > On Tue, Nov 17, 2009 at 1:16 PM, Anthony <[email protected]> wrote: > >> In any case, I don't think it would have worked for the TIGER road >> import, but an import procedure like that for the GPX traces would be >> a possibility for some imported data. Put the data in its own >> separate tables and let people import it manually by sending the >> server a bounding box. Potlatch would then import it as those red >> "locked" ways and people could check/fix the data manually before >> unlocking the way. Other editors could do something similar. >> >> The great part is, the editor support for this is mostly already >> written. It'd require some effort to create and implement the API to >> store and retrieve the data, but it seems doable. > > I think it doesn't necessarily need an API. If the editors can read > .osm files over http, then we just split the imports into chunks and > stick them on the dev server. Simplest possible thing that could work, > and all that.
How big are those chunks going to be? Seems like that would encourage a far too automated conversion process. If the imported ways aren't moved into position, they're useless - any geocoder/reverse-geocoder that wants the original TIGER data can just parse TIGER. _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
