Begin forwarded message:
From: Jesse Eichar <[EMAIL PROTECTED]>
Date: December 12, 2006 11:06:25 AM PST (CA)
To: Chris Holmes <[EMAIL PROTECTED]>
Subject: Re: [Geotools-devel] DataAccess conversation
I agree with you Chris we need some sort of process for making
changes to Geotools. Seems to me there keeps being issues where
someone sends an email out about some change, nobody is really
interested except for that person so everyone just ignores it...
Then the change committed and everyone freaks out because they
realize that it affect them. I've seen it happen a number of times
now.
One thing I've been doing in uDig is making blocker JIRA issues for
proposed changes so that they will be either voted down or somehow
addressed fairly quickly. It is much better than email in my
opinion because it provides a place to look for proposals and you
will treat them as proposals rather than just another of my million
emails for the day. I like using JIRA as a medium for certain
conversations because it is easily organized (easier than email),
you can associate issues with releases and categorize issues
nicely. Searching through issues is also nicely supported.
We can create a issue category that is forproposals, and
conversations can take place on those items. The one caveat is
that the comments are not sent to the list but if you are
interested in the report you can "Watch" and then you will get
email notification when the issue changes, such as a comment.
Jesse
On 12-Dec-06, at 10:41 AM, Chris Holmes wrote:
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
<cholmes.vcf>
-------------------------------------------------------------------------
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
