Marcus Wolschon wrote: > On 2/18/09, Brett Henderson <[email protected]> wrote: > >>> http://wiki.openstreetmap.org/wiki/Osmosis/DetailedUsage#--induce-ways-for-turnrestrcitions_.28-iwtt.29 >>> http://sourceforge.net/tracker2/?func=detail&aid=2612536&group_id=203597&atid=986234 >>> >>> >> I haven't read the links (currently offline), so I may have missed >> something. >> >> As I understand it, you want to be able to process an entity stream and >> update a database. As far as osmosis is concerned, wouldn't your task >> only implement the Sink interface? >> Ah, okay. Now I understand. So you want to be able to write your task independently of the database implementation. That should be do-able. I've always assumed these types of things would be database specific but there's no reason why that must be the case.
I created the Dataset interface to allow tasks to query data in a database independent way. It sounds like that needs to be extended to support write support as well. The idea of making a database writeable in a generic way like this never really occurred to me :-) It probably won't be useful for bulk data tasks such as an import but should work fine for changesets and other randomly distributed updates that are smaller in size. I'd suggest that we extends the existing Dataset support to expose write methods. The other option is that we leave the existing one as it is and provide a new one that extends the current one to provide write access (allowing some implementations to support read-only access only) but it's probably just creating extra work for not much benefit. If an implementation doesn't support updates it can throw a meaningful error message saying write access isn't supported. Existing tasks such as --read-pgsql which don't actually read but just expose a read-only database handle (the Dataset) to downstream tasks would need to be renamed. Perhaps --get-pgsql-dataset? The existing Dataset interface exposes the method "DatasetReader createReader();" and the DatasetReader provides a bunch of methods for reading from the db. This might have to be re-factored somewhat. The DatasetReader interface might be more appropriately called DatasetConnection. The Dataset.createReader method might be more appropriately called createConnection. Alternative name could be DatasetContext and createContext which is more generic than using the word "Connection" which implies an external database but I'm not too fussy. Your task could then implement both the DatasetSink and Sink interfaces allowing it to receive an incoming entity stream, and a handle to a database. The command line would look something like: osmosis --read-xml myfile.osm --get-pgsql-dataset dbAuthFile=authFile.txt --induce-ways-for-turn-restrictions. What do you think? Brett _______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
