Matthias Basler wrote:
Hi Jody,
many thanks for you suggestions. See comments inline.
Jody wrote:
You have rediscovered the C# environment!
Oh ...
So yes we could sling JDBC ResultSets around and set up components based
on that, indeed that is a *good* approach. It is just not a pure OO
approach. But this is one situation when being pure OO does not pay...
Cannot follow here. What does "pure object oriented" mean in this context
and why would it not be "pure OO"? Why should I care if it works??? ;-)
Pure object oriented would mean that all those things in your table were
objects. A Feature may as well be
an object from this standpoint (it has a Type). A pure result set just
kinda has metadata and you need to consider
it afresh each and every time.
You don't need to care, it is just a cultural thing. We could use
pointers as well ... Heck I do, I just call them "Handles"...
I would also report back on some commercial experience I have with this
stuff:
- a pure table does not work for complex content
- a tree (indicating a path or index) and a table (indicating the data
at the selected index) often works the best...
Agreed.
The point that I must stress here is that I myself are not interested in
"complex" features at all. All geographical data I have worked with so far
were "simple". Also I'd rather start with a table for simple content and, if
really needed, would extend it to deal with complex content later.
I beg to disagree, your Geometry stuff is "complex content", should be
able to "Drill Down" and look at the ordinates...
But yeah, start simple.
I think I have to read this two more times to get the full picture. The
first suggestion, i.e. sub tables (1..100) (101..200) is definitely a good
idea, especially when it comes to lazy loading. This is what the variables
view in the eclipse debugger does when showing the contents of a
collection.
I think we should skip the reading and just draw a picture or two ;-)
Your wiki page or mine?
Yes and that is what is happening, in the GeoAPI thing we finally have
some people (Bryce) who have access to the
strange ISO specifications where all this is written down. So Feature
extends Record and FeatureType extends RecordType and so on...
This sounds exactly like what I had in mind. Is there already an API with
this inheritance to work against ... even if unstable? The GeoAPI pending to
which you pointed me earlier doesn't show this inheritance (yet). I have
just checked out the pending branch from the CVS to be sure.
Yes there is, it is called pending and it is stablish (ie we are
implementing against it, but we can fix stuff if you find a problem).
So read through Bryce's pdf and get back to us?
I guess you mean the "ISO 19109 Primer". After a hunt throught the RnD pages
I have found it. :-)
I feel much more up to date now. Thanks again.
Yeah! Bryce's primer is a bit out of date - I addressed (most) of his
concerns.
Jody
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
