[osmosis-dev] preprocessing for turn-restrictions usins an osmosis-plugin

[Brett Henderson]

marcus.wolschon at googlemail.com wrote:
> On Thu, 19 Feb 2009 23:26:20 +1100, Brett Henderson <brett at bretth.com>
> 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