This makes a lot of sense.
But just about every time we've tried to design something in GeoTools
that we didn't have a concrete use case for we've failed. So I'd like
to see these interfaces actually be super classes for GridCoverage and
FeatureSource. And maybe from there figure out metadata and pojo's as
well. If we're designing this great unifying architecture without
actually having the API's implement it then it hints of architecture
astronauts - http://www.joelonsoftware.com/articles/fog0000000018.html
Maybe it's a dream that I should just give up on, but I had really
thought 2.4 was going to be the start of a new, glorious, stable
GeoTools revolution. That there would be *shock* _no_ api changes, and
that the only thing on the horizon was the new feature model.
Throwing this new api in the mix is just very confusing to anyone coming
in new to GeoTools. It's not clear what it's for since gridcoverage and
featuresource don't extend it. But it's smack dab at the top level in
'api'. I think it's an interface worth experimenting with, but I really
don't think it should start out in the core API module. Maybe as a
sub-package called 'experimental'? Perhaps we need an 'unsupported' api
or some such? If we don't feel these are the 'ideal' interfaces then we
shouldn't start with them in the API.
I don't see a huge loss if we _don't_ have a common interface between
coverages and features. I think it's a goal to aim for, but if we're
serious about a stable API we should do it for GeoTools 3.0. I think
users would appreciate something that is stable that they can rely upon
rather than an api constantly shifting to abstraction 'greatness'.
If we're serious about stability of the API then it seems like we need a
clearer process to _change_ the API. Perhaps something like a
geoserver GSIP for any api change?
best regards,
Chris
Jesse Eichar wrote:
As I understand it at least part of the motivation for these
interfaces is to provide interfaces for the common parts of all GIS
APIs. Consider the similarities between GridCoverage, Feature and
Topology models.
These interfaces provide a way of obtaining the common information
between them. It will also help make the design of future APIs
similar since they can all derive from these common interfaces.
So from these interfaces you know how to obtain information such as
bounds, name, data type etc... Sure there isn't a generic way to
access the information but if you consider Feature and
GridCoverage... well there is very little commonality when it comes
to accessing and processing the data. So this is a higher level I
suppose.
That's my interpretation. I'm not saying that these are the ideal
interfaces necessarily but that is why you see methods like:
content( String query, Query language) and content(filter). Both of
those are content independent. But the Geotools Query is content
dependent.
Does this make sense?
Jesse
On 12-Dec-06, at 9:59 AM, Jody Garnett wrote:
Andrea Aime wrote:
Nope, when you're rendering you're using just the "flat", simple part
of it, or you would not be able to use it, no?
no.
You can actually choose to render your content based on attributes of
things they are related to etc...
Andrea GeoServer (and generating GML) is not my only concern here; I
would like to open the door to rich content beyond our feature
model.
Since we have failed to produce one (and something like EMF seems to
be taking over) it seems best to sit on the sidelines.
If we cannot "reflect", "inspect" at least the simple properties out
of that Source thing, then I'm against having it around.
It just adds confusion and provides little value imho.
Of course it's a matter that the PMC should discuss, so if mine it's
the only -1 with two vote sessions you can get away anyways.
You are correct Andrea, and it is important to have this conversation
right now (rather then a vote). It is too late to change things for
the
milestone release; but when we get around to planning we can try
and get
a handle on the problem.
These interfaces are only the start of the conversation; the next
stage
is to set things up so everyone is happy :-)
IMHO we will not be able to make everyone happy this time around
(because to do so would be to ask too much - ie FM, update datastores,
complex feature branch salvaged etc...), I would rather ensure we
removed as many obstacles to the FM rollout as possible.
Jody
----------------------------------------------------------------------
---
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to
share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?
page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
!DSPAM:1003,457ef489326951665516417!
--
Chris Holmes
The Open Planning Project
http://topp.openplans.org
begin:vcard
fn:Chris Holmes
n:Holmes;Chris
org:The Open Planning Project
adr:;;377 Broadway, 11th Floor;New York;NY;10013;USA
email;internet:[EMAIL PROTECTED]
title:VP, Strategic Development
x-mozilla-html:FALSE
url:http://topp.openplans.org
version:2.1
end:vcard
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
