I was not sure David,
I documented what was needed on my plugin's wiki page:
- http://docs.codehaus.org/display/GEOTOOLS/EPSG-Oracle+Plugin
When you figure it out I will try and follow suite,
Jody
David Adler wrote:
> I'm working on making the DB2 tests consistent with the recommended
> online t
Create 'Online' testcases
-
Key: GEOT-1417
URL: http://jira.codehaus.org/browse/GEOT-1417
Project: GeoTools
Issue Type: Improvement
Components: data db2
Affects Versions: 2.5.0
Environment: All
+1
On Jul 31, 2007, at 12:59 PM, Andrea Aime wrote:
> Andrea Aime ha scritto:
>> Hi people,
>> discussion seem to have calmed down.
>> Please vote if you feel like to. 2.4.0-rc0 is not far away.
>
> I updated the page with the last outcomes from the Geoserver
> meeting, and added my vote and Jody
> Our recent experience is that using Java Collections for these kind of
> ideas is a bad move. It has lulled our user community into some really
> bad mistakes; hense the motivation for this proposal.
Really? It seems so innocent. What happened?
(Wait a minnit: I was talking about writing new
Andrea Aime ha scritto:
> Hi people,
> discussion seem to have calmed down.
> Please vote if you feel like to. 2.4.0-rc0 is not far away.
I updated the page with the last outcomes from the Geoserver
meeting, and added my vote and Jody's one. I think we need
two more for the proposal to pass. Anyon
Guys KISS Lets keep this simple. What Andrea has now is simple.
Reporting back which hints were actually used is feature creep... and
correct if i am wrong is not something Andrea needs to acomplish his goal.
Andrea and I had a discussion that we could possibly add
Query.setHonoredHints
And this is why we like Bryce, cutting through layers of madness yet again.
> some new class. Repeat--"FeatureCollection" is not part of a programming
> specification. Data transport only. No mojo. :)
>
Add another point to your list Justin; removing FeatureCollection from
GeoApi as a crazy
[EMAIL PROTECTED] wrote on 07/31/2007 11:34:02
AM:
> >> I do happen to think ISO19107 FeatureColletion will be valuable - but
> >> if we do not have resources/mandate/will to implement this right now
> >> (or ever) then I would like us to do exactly that ... not implement
> >> geoapi FeatureColl
You could also have a method on FeatureSource to report back the hints
that were used by the last getFeaures() request.
The motivation here is this; the major driver for this to use a
FeatureFactory.
Cheers,
Jody
> Jody Garnett ha scritto:
>> I see, you are expecting an implementation to be passe
Jody Garnett ha scritto:
> I see, you are expecting an implementation to be passed in.
>
> Sometimes (I am thinking referencing here) the implementation provided
> really is just a hint; depending on the data it may not be suitable ...
> at which point factory finder madness kicks in and they se
I see, you are expecting an implementation to be passed in.
Sometimes (I am thinking referencing here) the implementation provided
really is just a hint; depending on the data it may not be suitable ...
at which point factory finder madness kicks in and they search for a
"good" implementation.
Jody Garnett ha scritto:
> It is going to be pretty tricky to arrive at a Set; it may be open ended
> depending on what factories you are passing in ...When you declare a
> specific GeometryFactory for example it may need a additional CRSFactory
> etc...
Sorry, I don't follow you. That has noth
It is going to be pretty tricky to arrive at a Set; it may be open ended
depending on what factories you are passing in ...When you declare a
specific GeometryFactory for example it may need a additional CRSFactory
etc...
Do we care?
Jody
> Andrea Aime ha scritto:
>> Jody Garnett ha scritto:
>>
Hi people,
discussion seem to have calmed down.
Please vote if you feel like to. 2.4.0-rc0 is not far away.
Cheers
Andrea
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? St
Andrea Aime ha scritto:
> Jody Garnett ha scritto:
>> If we follow suite; getImplementationHints would return a
>> Map of the configuration that was actually
>> used. Ie *everything* (it may be from the global hints, or defaults used
>> by the implementation or whatever...). The fact that some o
Jody Garnett ha scritto:
> If we follow suite; getImplementationHints would return a
> Map of the configuration that was actually
> used. Ie *everything* (it may be from the global hints, or defaults used
> by the implementation or whatever...). The fact that some of this
> configuration stuff
If we follow suite; getImplementationHints would return a
Map of the configuration that was actually
used. Ie *everything* (it may be from the global hints, or defaults used
by the implementation or whatever...). The fact that some of this
configuration stuff comes from a "per query" setHints()
Jody Garnett wrote:
> And thus the parts start to come back together ...
>> I think you have communicated your intention just fine... its just
>> that from my point of view while this seems like a very noble and
>> lofty goal i dont think its very practical. Anyways... my two cents.
> I am in agr
Thanks Justin; I will update the proposal. And indeed it is a "day"
(although it felt like a week).
No rush on this one I presume? You are not going to be back into the
thick of things until your GeoServer release goes out; and Andrea has a
date with Query hints (more of a showdown at dawn, gun
Sure; my major problem is with us getting halfway there and leaving
users stranded.
If we can double back to the proposal for a moment ... we had the
concept of a collection() method that would return an instance of
Collection.
There are two ways to do integration with the large geoapi model
Jody Garnett ha scritto:
> And thus the parts start to come back together ...
>> I think you have communicated your intention just fine... its just
>> that from my point of view while this seems like a very noble and
>> lofty goal i dont think its very practical. Anyways... my two cents.
> I am i
I would go with FeatureSource as the "data access side" of the equation.
I am also liking the code examples that are produced when you add it to
FeatureCollection - but golly that class servers too many purposes as it
is :-)
Andrea I am happy either way; want to write up a code example and choo
Hi,
I updated the page with the latest discussion suggestions.
What's still unclear is if we should put the method to
get the honored hints in FeatureCollection, and what the
name should be (if it's there, getImplementationHints
sound like misplaced, because what hint was supported
may be dependent
And thus the parts start to come back together ...
> I think you have communicated your intention just fine... its just
> that from my point of view while this seems like a very noble and
> lofty goal i dont think its very practical. Anyways... my two cents.
I am in agreement with you; and if tha
Justin Deoliveira ha scritto:
> I think I agree with Jody in that you should probably use Hints straight
> up... not because I love the hints api but for reasons of consistency.
Ok, I managed to understand my error, and you are both right. Will
fix the proposal.
> AS for where to put hte honored
It'd be pretty easy for us to set up a geotools blog on our same
geoserver infrastructure, if there's interest and a volunteer to style
it a wee bit.
Chris
Andrea Aime wrote:
Jody Garnett ha scritto:
Or news feed already acts as a blog; it is open for anyone to publish up
articles etc
Jody Garnett wrote:
> Andrea Aime wrote:
>>> Nope. Flip it the other way around; have your FeatureSource return
>>> several things if your want (FeatureReader, Collection,
>>> whatever ...), but having FeatureCollection as a distinct idea is
>>> something we gotta have.
>> Sigh. Can we have this
Justin Deoliveira ha scritto:
> Andrea Aime wrote:
>> Justin Deoliveira ha scritto:
>>> I think I agree with Jody in that you should probably use Hints
>>> straight up... not because I love the hints api but for reasons of
>>> consistency.
>>>
>>> AS for where to put hte honored hints... not too
Andrea Aime wrote:
>> Nope. Flip it the other way around; have your FeatureSource return
>> several things if your want (FeatureReader, Collection,
>> whatever ...), but having FeatureCollection as a distinct idea is
>> something we gotta have.
> Sigh. Can we have this layered in two classes the
Small correction Andrea:
> Hints looks fine, seems to be easily bent to current needs, yet those
> hints are general, and do not seem to fit well will the pluggable
> nature of data stores (and, as a consequence, the variable nature of
> hints), since the class does accept only ClassKey instance
Andrea Aime wrote:
> Justin Deoliveira ha scritto:
>> I think I agree with Jody in that you should probably use Hints
>> straight up... not because I love the hints api but for reasons of
>> consistency.
>>
>> AS for where to put hte honored hints... not too sure about that one
>> either. What a
Jesse Eichar ha scritto:
> I like the idea and have wanted this for a while now. But the concern I
> have with this proposal as well as other is getting enough momentum
> behind it to make sure it become real (not just implemented for a single
> datastore and forgotten in a few months).
> My s
Andrea Aime wrote:
> Hi,
> some quick comments on the two pages making up
> the Collection proposal.
>
> http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+Clean+up+Motivation
>
>
>
> About the "working with invalid data", we have to deal with it both
> iteration and visiting wise. So
Justin Deoliveira ha scritto:
> I think I agree with Jody in that you should probably use Hints straight
> up... not because I love the hints api but for reasons of consistency.
>
> AS for where to put hte honored hints... not too sure about that one
> either. What about throwing another method
I like the idea and have wanted this for a while now. But the
concern I have with this proposal as well as other is getting enough
momentum behind it to make sure it become real (not just implemented
for a single datastore and forgotten in a few months).
My second concern is what is the sta
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> Hi,
>> some quick comments on the two pages making up
>> the Collection proposal.
>>
>> http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+Clean+up+Motivation
>>
>>
>>
>> About the "working with invalid data", we have to deal with it both
I think I agree with Jody in that you should probably use Hints straight
up... not because I love the hints api but for reasons of consistency.
AS for where to put hte honored hints... not too sure about that one
either. What about throwing another method on DataStoreFactory for it
called "getQ
Jody Garnett wrote:
> Reminds me I need to add "events" as something I am willing to give up
> (although Jesse will kill me). I put in a method for
> featureCollection.collection() - is that suitable?
>
One more thing I am willing to give up (if we have to), is using
FeatureCollection as the
Here is the link:
- http://gtirc.blogspot.com/2004_09_01_gtirc_archive.html
You can find other old IRC logs on this page:
- http://docs.codehaus.org/display/GEOTOOLS/IRC+Logs
Jody
Andrea Aime wrote:
> Jody Garnett ha scritto:
>> Or news feed already acts as a blog; it is open for anyone to publ
Andrea Aime wrote:
>> Then you can perform any number of queries against your FeatureSource.
>> What do you think?
> Dangerous? What if I share the same FeatureSource for some topological
> analisys and some rendering, they do need different hints, and would
> end up stepping on each other toes.
Yo
Jody Garnett ha scritto:
> One alternative idea for you Andrea.
>
> featureSource.setHints( hints );
> Map used featureSource.getImplementationHints();
>
> Then you can perform any number of queries against your FeatureSource.
> What do you think?
Dangerous? What if I share the same FeatureSourc
Jody Garnett ha scritto:
> Or news feed already acts as a blog; it is open for anyone to publish up
> articles etc
Hmm... I see. Did not think about it. Eventual blogs would be swamped
in between the irc logs thought. Look at GeoServer infrastructure,
things we want to tell users are not mixe
One alternative idea for you Andrea.
featureSource.setHints( hints );
Map used featureSource.getImplementationHints();
Then you can perform any number of queries against your FeatureSource.
What do you think?
Jody
Andrea Aime wrote:
> Hi,
> turned out I already wrote a Query hint proposal some t
Hi Cory welcome back.
Jody
Cory Horner wrote:
> still being blocked?
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems? Stop.
> Now Search log events and configuration
Two things Andrea - create a Jira report (or another page) and put all
the background story and rejected ideas there. Leave the proposal to
stand on its own so people can see the result of all your hard work.
We are also going to need Jesse's review on this one as he is deeply
involved in hacki
Or news feed already acts as a blog; it is open for anyone to publish up
articles etc I use it every couple of months or so. I would also
like to see the SoC students use it. GeoTools does have a blog account;
James added it back when we first lost all our IRC history.
Jody
Andrea Aime wro
Andrea Aime wrote:
> Hi,
> some quick comments on the two pages making up
> the Collection proposal.
>
> http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+Clean+up+Motivation
>
>
>
> About the "working with invalid data", we have to deal with it both
> iteration and visiting wise. So, i
still being blocked?
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of
On 31-Jul-07, at 4:00 AM, David Adler wrote:
> I'm working on making the DB2 tests consistent with the recommended
> online test process.
>
> Is the fixture file supposed to go into
> db2\src\test\resources\org\geotools\data\db2 and then get copied
> manually to
> c:\documents and settings\dadler
On 7/31/07, Andrea Aime <[EMAIL PROTECTED]> wrote:
> Hi all,
> thinking about feature collection and speaking back to users,
> what do people think of having a gt2 developers blog?
> It could be a way to have more public discussion on what's going
> on without the need to hit the users mailing list
Hi,
turned out I already wrote a Query hint proposal some time ago,
and then forgot about it. Today I beefed it up with some extra content,
and it's ready for your commenting pleasure:
http://docs.codehaus.org/display/GEOTOOLS/Add+hints+support+to+Query+object
I think the crux is where to put the
Hi all,
thinking about feature collection and speaking back to users,
what do people think of having a gt2 developers blog?
It could be a way to have more public discussion on what's going
on without the need to hit the users mailing list, which is
swamped by help requests already anyways.
Cheers
Hi,
some quick comments on the two pages making up
the Collection proposal.
http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+Clean+up+Motivation
About the "working with invalid data", we have to deal with it both
iteration and visiting wise. So, it seems to me we should handle this
at
53 matches
Mail list logo
