Matthias Basler wrote:
Jody wrote:
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...
I see. I thought this would already work with the current feature model.
I was referring to a user interface that could be used to review both
features, and the geometry in side the feature.
We lost some email context...
I actually never thought about "displaying" geometries in a table this way.
But now that you mention it ... why not.
Really? Sometimes all you query is a list of Geometry, and when you
Drill into a MultiLineString you see LineStrings...
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?
Yours. I don't have an own wiki. (Sorry for being so out of date. ;-) )
(But don't want to press you into drawing them if you have little time.)
Well if you don't mind a digital camera picture of a whiteboard it won't
take much time.
Anyway. My concern is always that for "normal" users of, lets say, uDig, any
such widget must be intuitive.
Take your first suggestion, for example: Splitting a large attribute table
in smaller pieces of, lets say, 100 features at a time is nice for lazy
loading and nice for the memory footprint - it is nice for the developer, no
question. But how about the user?
All these things are a tradeoff, I would only do that when the feature
source i was talking to did not support random access.
Note that with large data you always have this tradeoff.
With databases it is traditional to have two sliders, aka one for
"pages" and one to scroll through the page.
I have seen large databases in data mining applications with three
vertical sliders!
If I imagine being a user, I'd find it more intuitive to have the whole list
in one table, no explicit change of the subset required. And how about
selecting multiple features spread over different "parts" of the big table?
See above, data is big, users suffer. Plan ahead and just implement
something simple until a user complains.
So maybe give the user the choice how to view a large data set?
Or maybe have a table that just keeps the visible entries in memory ...
without the user noticing! (Using proxies...) As a user I wouldn't care
exactly how the developer reduces the memory footprint.
Is there already an API with
this inheritance to work against ... even if unstable?
[...]
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).
Now I'm confused. If it is not the GeoAPI pending branch, where is it then?
Just point me to the SVN, please.
You asked for a stable API- aka interfaces (Java 5).
-https://svn.sourceforge.net/svnroot/geoapi/trunk/pending/src/main/java/
-https://svn.sourceforge.net/svnroot/geoapi/trunk/pending/src/main/java/org/opengis/feature/
-https://svn.sourceforge.net/svnroot/geoapi/trunk/pending/src/main/java/org/opengis/filter/
We (well Justin and Gabriel) are also implementing against these
interfaces (Java 1.4):
- http://svn.geotools.org/geotools/branches/fm/
-
http://svn.geotools.org/geotools/branches/fm/module/main/src/org/geotools/feature/
-
http://svn.geotools.org/geotools/branches/fm/module/main/src/org/geotools/filter/
Justin did I get that right?
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
