Jody Garnett wrote:
>> 1) a good structure to hold multiple, labelled, selections on the
>> registry: e.g. an op gets to work against all the features of layer
>> one with height > 30 and all the features of layer two within some
>> bbox. I may be doing something "simple" like a buffer but want to
>> return a marked version of that
>>
I think Eclesia just wants the data passed in (no references). Using
your example the operation would take two FetaureSource instances and a
couple of filters.
>> 2) a good strategy to enable process monitoring and control
>> (suspend/resume/cancel/cleanup). This would include explaining how
>> often a thread needs to poll the isInterrupted().
>>
That should all be defined as part of the ProcessListener interrface; it
has some guidelines already - if we need more than the changes can go in
the javadocs their.
>> Unknown macro: {sensu. unix SIGHUP}
>> and how much work should happen between polls.
>>
Unknown macro?
>> 3) a good strategy for passing a 'hint' like parameter set to the
>> operation. This should be something like a
>> SACRIFICE_ALL_FOR_SPEED which would be an extensible list of elements
>> so adriansNewMixupOperation could pass the code_list a
>> add(SACRIFICE_ALL_FOR_SPEED, "<round_corners_are_square>")
>> by which anyone calling my op with the SACRIFICE_ALL_FOR_SPEED would
>> pass me back the parameter that makes sense to me, namely
>> <round_corners_are_square>.
>>
I think this would just be an additional parameter? No need to go all
consistent and formal until we have some experience.
>> Yeah, so this last one is probably hard/confusing. It's only slowly
>> emerging as I think about ISO geometry. There's still a long way to go
>> before we can design anything above Feature that makes good sense for
>> those working below. uDig certainly did a good start. I suspect
>> getting a solid selection system will require a good repository which
>> is non trivial.
>>
Okay I am starting to understand; something closer to the IOp interface
where we have defined up front what
content the operation can run on. Please consider Eclesia's proposal to
be much more simple (and thus much
more likely to succeed). My goal here is to start java developer
creating "process" implementations; we can
wrap it up in something connected to a "registery" later... after all if
something takes a FeatureSource (ie the end
result of a reference) or a FeatureCollection (the end result of a
selection) why does the Process have to care
how these parameters were produced by the user?
Just so we are on the same page Adrian: you see that the process results
in an Object? Is the existing method
to determine the resulting Object type going to set up ETL style chains
of Process implementations?
Jody
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
