[email protected] wrote: > On Thu, 19 Feb 2009 23:26:20 +1100, Brett Henderson <[email protected]> > wrote: > >>> Maybe: >>> DatasetReader => Dataset or RandomAccessData or Map >>> Dataset => DatasetFactory or RandomAccessFactory or MapFactory >>> DatasetSink => DatasetClient or RandomAccessClient or MapAccessClient >>> as the task need not be a sink for data >>> comming from the Dataset but be a source for data going into it or >>> both. >>> with the tasks named: >>> --get-XYZ-dataset or --access-XYZ or --XYZ-map >>> >>> >> Okay, this might sound pedantic but I don't feel all that strongly about >> it. The Dataset interface is what is passed between tasks. >> > > Yes, it is passed. But it is not read. --read-dataset for me implies > that you read something and following modifications to affect only the > in-memory-copy but not the original. > A clear naming makes things intuitive, I don't care what name you > decide on in the end as long as the metapher fits. > Yep, I agree that read in the name isn't right.
I think we agree on the basic implementation, names can be changed easily later. > >> It >> represents a set of data to be read (and now modified). I'd rather not >> call it DatasetFactory because that would imply that it can be used to >> create datasets which is not the case, the data already exists (it may >> be empty but it exists). The issue I ran into when creating this is >> that multiple threads may access the Dataset concurrently (I initially >> created it to extract many bboxes concurrently). Where the data is >> backed by a database that means each thread requires its own >> connection. So each task must instantiate a connection when it starts >> processing, and close it when it is done. The DatasetReader provides >> the means to hold that connection specific context. The DatasetReader >> name is no longer appropriate but I thought something equivalent would >> be okay. Is it really that confusing? >> > > Actually..yes. "Dataset" implies a set of data to be accessed. > Returning it from a DatasetReaser implies that it is a temporary > construct reat from somewhere and to be written back at a later point > in time. > Yep, again reader isn't a good name. We'll figure something out. > >> As for the DatasetSink name, I merely named it that to align with the >> rest of the Sink Source model. I like the sound of DatasetClient. >> >> What does "Map" in some of the above names represent? Map as in >> OpenStreetMap, or Map as in HashMap? >> > > As in OpenStreetMap but you are right. I did not think about the > association with "to map A to B". > >> You can code it if you like :-) Do you have svn access? >> > > Nope, no SVN-access. > Where can I get access? (Have to look in the OSM-wiki, > it "should" be in there somewhere.) > I never know who's looking after what. I usually start with the Servers page but from what I can tell it's not always up to date. TomH has access to everything so should be able to help you out if nobody else can. > >> I haven't been doing much lately other than writing emails. I still >> haven't done the writeable entity stuff although that shouldn't take >> long once I get into it. I want to get that done first, then I might >> have time for this writeable Dataset stuff. If you want to make a start >> though it would be great. The days of me having time to do it all >> myself appear to be over. >> > > First it will take me a few days, maybe a week, to make my algorithm > with the turn-restrictions working. I want this to be in my version 1.0 . > Then I can help you with the changes to osmosis, so I can turn it into > an osmosis-task later. > Cool, we'll play it by ear. Brett _______________________________________________ osmosis-dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/osmosis-dev
