Hi everyone, working on the weekend and trying to collect my thoughts. You
have all kindly put up with my ramblings about Feature Model these last weeks.
This email is not about that....
I am going to try a different approach this week. Normally I have these
separate conversations concerning something I am trying to pull together for
the "big picture".
If you are listed by name below you are part of this bigger picture I am
trying to pull together. If you did not know you were working together,
welcome to open-source development, please feel free to introduce yourself to
anyone you don't know.
Summary:
Filter - Chris Dillard, Gabriel
Random Access & Selection - Justin, Jesse, user list
Feature Versioning - Adrian and Dave Blasby
Factory Use & Injection - Justin & Martin
2.2 Release - Martin
For those not explicitly mentioned, please feel free to jump in ... this is
open-development :-) That especially goes for James and Justin -- let me know
what I am missing. Justin may have escaped but I still need to talk these
design ideas around, perhaps moving it into an open forum will help.
Chris Holmes - you can call my kettle black after this email,
Jody
PS. You may notice that this contains information about both GeoAPI and
GeoTools. If you are on only one of these lists kindly do not skip this
message. I intend for us to work together, not every issue is for both camps -
but the solution should be. (I promise this is not about Geometry, or Feature
Model)
Filter
======
Chris Dillard (probably the most startled to get this email) - I am still
waiting for ideas on how you would like to go forward on GeoAPI Filter
interfaces. As mentioned previously I would like an answer on how Filter 1.0
and Filter 1.1 can both be supported. (This is something I can do, but if you
had existing plans, or would like to minimize breakage, then I would like some
input).
What is on the table? Go general and and construct specific ...
- Making the set of "general" Filter interfaces matching the capabilities of
GeoTools (I cannot ask people to accept less).
- Marking down the set of Filter 1.0 filters, as per GeoAPI right now.
- Marking down an additional set of Filter 1.1 filters (there will be overlap)
- Produce two factories (one for each specification), each factory limited to
creating the scope of Filter expression supported by that standard.
This is preventing geotools from moving in the direction of GeoAPI, I have
mentioned it as a concern previously. At the very least this should be brought
up in the next OGC meeting as an issue worth looking at (how GeoAPI should be
future proofed).
There is an alternative (that I don't like) to the above idea - that is
considering all Filter 1.x specifications as "roughly the same" and breaking
out a getVersion() method and a mess of javadocs. This is much worse in that
client-code cannot explicitly indicate its limitations at the class-level. We
would be left with a mess of "optionality" which is the death of way more
standards then even the OGC produces...
Gabriel - as promissed I am looking into the XPath side of things (as a sanity
check on the Feature Model) this weekend. I saw that you planed to generalize
Filter to work against Attribute? I am working through the possible advantage
to that. Near as I can tell having an explicit Class for JXPath to bind
against would be the main benifit?
My only heistation is one of focus. I am 'happy' with the Feature Model
maintaining a level of indirection (it has to as it is a meta model). But I
had wanted Filter / Expression to be more hands on. Hands on should be read as
Object.
I have mentioned this in conversation repeatly, but I will explicitly lay
these cards down. I am interested in setting up the following concerns, and
making sure they are orthogonol.
Data language
- Feature
- Other: Metadata, Record
- Descriptor
Query language:
- Query
- Filter
- Expression
Client code:
- Portrayal (example)
Thus I dont't want to repeat a few past mistakes (like Feature being used as a
parameter by geotools FilterFactory.
Random Access and Selection (not Filter)
===========================
Justin - you have been working on Shapefile and optimizing for Attribtues for
rendering ...
User List - disgust was voiced about the Filter API not being what was
expected (someone had implemented a Filter and was unable to get processed)
...
Jesse - you have me down to make you a Random Access API by November. For
those that are not Jesse, if you need background please review the Confluence
site for these plans.
When I first started I did not *want* Filter - I wanted a Selection. The
difference is Filter is a rule used to define a sub set. A selection *is* the
subdivided Set. Admittedly there is no useful difference between Selection
and a FidFilter ...
One of the things that Filter 1.1 is going to kick us hard with is the need
for Order. Dave Blasby can remember the days of Cause & Effect (previous job)
where there was a separation between Content, Order and Selection.
I am thinking of representing these concerns as First class objects. Be it
FeatureList (defined by an Order), or Selection (made against a specific
FeatureCollection).
Justin about the consequences of this idea - each index can basically be
viewed as an "Order" of the origional content (arranged according to the the
attribute under discussion). You can start in on these ideas for shapefile
even before we figure out a way to out the idea as an interface. I am pretty
sure you never got around to telling the email list about your experimenets
with building attribtue indexes last week. This idea would dovetail nicely and
you could store the content in a easier to parse format, in the nodes of the
index (even just to speed up the process of index navigation).
Note - the process of making a Selection out of a Filter would be similar to
some of the workflows you see in ArcView. Note the AttributeIndex with
preparsed content would also be the correct mechaism to immplement the
traditional simple Join of temporary content to a shapefile seen in arcview.
Feature Versioning
==================
Adrian and Dave Blasby, one of the things that occured last week (in an IRC
session posted to the UDig site so you may have missed it) was that Adrian was
sending us right back to the origional OGC Feature Model. That is before it
was cleaned up a limited in scope for things like "Simple Feature Model", or
GML2 (or GML3).
James has given me a target of GML3 (at least the Level 0 Profile part), this
is also the target of Gabriel.
Adrian and Dave - you have a different problem in mind. I would like to
confirm that we are not painting you into a corner. Dave I am under the
impression that you would like to build Feature Versioning "on top" of a data
store infrastructure as a separate concern. Is this still your plan ... it
would be great if you could talk to Adrian who has similar concerns.
Adriand you were worried about Feature extending Attribute. Part of the fun is
that you have a slightly different impression of what Attributes are then that
OGC document I pointed you towards. I am waiting to hear back from you on your
revised understanding.... The word "properties" is also provided (of which
"attribtues" is a specific kind of property holding data). I admit that our
Feature Model is a *data model* and does not allow Object-oriented methods/
opperations at this time. The OGC is struggling with associatations linking
data to opperations as we speak as part of their Catalog Publish/Find/Bind
infrastrure. I cannot consider this as leadership - or a strong movement
towards object orientation.
Dave, Adrian is in a world where not only the attribute values change over
time. The schema changes over time. While the origional OGC Feature Model can
deal with this (for them a Feature is a bag of stuff with a fixed ID, the
stuff is captured as attribtues wach with a unique timestamp/value/etc...
different Application Schema are constructed (like views in a database)
offering a perspective on the content.
I can think of ways for you two to work together - serve up the "Feature"
based on timestamp, complete with the Schema for the content at that point in
time. Justin will call me out if I don't point out that "Extensible Interface"
idea of allowing you to query for the content in the shape needed for the task
at hand.
If that idea makes sense (to both of you), or if you think something else may
be better - perhaps you can take it up with Justin?
Factory Use & Injection
=======================
Justin & Martin. In geotools last year we ran into the limits of our Factory
system. We have achived independence of interface but the current state of
things is ill specified from a customizaton point of view. If you return back
to those orthogonal concerns at the top of the email you will see the things
that we need to be able to tweak.
Justin has experience with the different kinds of injection although has not
emailed about it. Martin I would like to see us take a step back from the
ImageIO plugin system. And I would like to see GeoAPI follow suite.
We can use setter injection to document dependencies that is required for
customization at the factory level. This also serves as the needed hooks for
any and all Container based system. It is also clear and explict for those
implementing geotools applications with normal java code.
I also would like to ask if GeoAPI can swtich to abstract classes for the data
only objects such as TransactionRequest? I don't see any advantage to using
interfaces in such cases, and an Abstract class can be customized with a
Factory just as easily as an interfaces. The advantage being that any
extention of the abstract class will not break client code. This doubles back
to my concerns for the Filter 1.0 / Filter 1.1 troubles.
James had some backstorey on why geoapo/geotools is so aggressivly pro
Factory/Interface. I liked the comment on the user list that such
understanding should not be required to use these libraries.
To help I am tempted to promote the following used of nested interfaces:
public interface Thing {
public interface Factory {
public Thing create();
public Thing create( int number );
public void setPreferences( Preferences preferences );
}
public int getNumnber();
public void setNumber( int number );
}
This technique is also compatible with the interface only approach used by
GeoAPI and offers a level of explictness that prevents GeoAPI factories from
being used in a production enviorment (where these concerns matter).
Note: the above includes an example of Setter injection, Preferences would be
created by a PreferencesFactory, allowing application code a way to supply a
default number for Thing creation, and probably a way for the Factory to
externalize any customization for use across geotools applications.
Aside: I would be happier with constructor based injection, but I imagine it
is a hard sell for GeoAPI with little benefit? For geotools code I will
endevour to make a constructor that matches the dependencies listed by the
setters.
2.2 Release
===========
Martin - thanks for taking on the next 2.2 release, the moment you are done we
will kick in the aggregate changes (well we are going to do this on the 24th)
and thus another milestone release.
As I recall you are stuck on javadocs ... just turn them off. This is only a
milestone release, for those following along at home and not using svn. It is
more important that we do this to reflect the accurate state of svn (and
progress).
The release notes say to give module maintainers 3 days after an email, lets
consider javadocs as of having its three days. Report a bug in Jira for James
or Justin and lets get this email out the door.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
