Jody Garnett wrote:
Justin Deoliveira wrote:
Ok fair enough, so a couple of things that come out of this. Mostly
just to ensure that I understand correctly.
1. When one of these things is created (an instance of FeatureType)
and passed a FeatureCollectionType that type should inheirit from
AbstractFeatureCollectionType, or something that defines the "bounds"
attribute.
2. There is no need to cache the bounds locally anymore since we will
actually have an attribute dedicated to storing the bounding box?
Well your programmers will still call that getBounds() method, so the
implementation may want to cache stuff.
- shapefile does not need to cache information in the hedaer
- oracle does not need to cache information in the metadata
- same thing with postgis
- hsql will want to cache, cause it does a table scan to figure it out
What i meant is that with this scheme bounds is modelled with an
explicit attribute (ie. the bounding box is stored in teh attribute
itself and is retrieved with Attribute.get()).
That is every "data" FeatureCollection is different, after being burned
with AbstractDataStore I am a bit scared to do to much for fear of
people making slow code.
So to answer your question, you need to think and do the right thing.
Another alternative:
- getBounds() calls getAttribute("bounds")
- cache happens at the attribute level, caching the result of the
aggregate function
I think this is what I meant above.
And the aggregate function gets optimized for JDBC datastores at least.
It is a rough world Justin, and hacking at AbstractDataStore is going to
hurt. Leave caching out of it, and force the subclass to think.
Jody
Sorry, i did not mean to phrase the initial question as one about
caching, just about how to model bounds in the feature collection.
-Justin
Jody Garnett wrote:
Justin Deoliveira wrote:
Thanks Jody, this makes sense now. Another question.
Should the derived attributes like bounds show up in a call to get()
when someone wants a collection of all the attributes defined for
the feature collection.
Of course, that is kind of the point :-)
It is one thing to make an java api allowing programmers access to
all these ideas. You also need to run a second API allowing those
working on your
"dynamic type system" access to all these ideas. The way to do that
is with attributes right now.
And next month (with Bryce's blessing) we will start to out some
operations. Incidentally I am having good luck with POJO Features
right now, rather then
just our in memory one. You may consider the "bounds" attribute as
the perfect case study of this issue, it is an attribute but we need
to map it to an accessors method
to calculate (or cache) its value.
Since you have EMF experience: the difference between generating some
java code that extends EClass and using EClass to manage in memory
data is what we
after.
Jody
-Justin
Jody Garnett wrote:
Well my code review is not going to well - Justin keeps asking,
good, questions.
For FeatureState implementation in 2.2.x I used the same horrible
code that was already there that let you access the feature members
as an attribtue called "features". This of course must die ... and
with a new feature model it finally can.
1. the javadocs for FeatureCollection.itterator() explicitly state
that the values are to be made available to XPath as
"featureMember" and "featureMembers" (for a GML featurecollection)
2. the attributes used by a feature are ment to be derrived - aka
the attribute "bounds" mapped to FeatureCollection.getBounds()
3. the attirbutes also include name, description, id - so the
general definition of a feature colleciton is out of sync with GML
... so we will need to let FeatureCollection carry its own
attributes - and to be pure we should not let the collection go
"empty". As an example of a useful attribute - "version" would be a
good candidate in a geowiki application
So here is a revised plan made with the help of Justin:
1. FeatureCollectionDelegate extends FeatureImpl (so Justin does
not have to cut and paste attribute code)
2. FeatureCollectionDelegate.getAttribute( string ) maps "bounds"
to the "wrapping" FeatureCollection.getBounds() method
4. FeatureCollectionDelegate can cache the answer of getBounds()
3. FeatureCollectionDelegate listens to its wrapper for events and
can clear its cache of derrived attributes
None of these changes will be made to 2.2.x as the FeatureModel is
not useful enough to describe a FeatureCollection with attributes...
Jody
Hi Guys,
I got online with Skype and talked with Justin one evening this
week, and learned about all the stuff he has not been sending to
email!
Here is the ground we covered (GeoTools only):
- a code review of the ResourceCollection, FeatureCollection,
FeatureState ideas in geotools 2.2.x (yeah a code review for me).
The result was Justin wants FeatureState to be a Feature (so he
does not have to cut and paste some code), I would rather it not
support the Feature interface (cause it is really a "mixin"
providing the attribute, getBounds, getType information for a
FeatureCollection. But I did not care enough to complain much.
The only problem is that the FeatureState.getType() explicitly
must return a FeatureCollectionType when mixed into a
FeatureCollection. Since this is API only used by those
implementing a FeatureCollection from the inside out I figure they
can read the javadocs.
--
Justin Deoliveira
[EMAIL PROTECTED]
The Open Planning Project
http://topp.openplans.org
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
