Re: [Geotools-devel] data store / feature collection cleanup proposal

On Thursday 07 February 2008 01:18:35 am Justin Deoliveira wrote: > I have been giving a bit of rough feedback to others for their proposals > so here is a chance for people to get back at me. no need to, I don't see this as personal ;) > I finally got around > to writing up my ideas on how to c

Re: [Geotools-devel] Minimal set of Info considered

Justin Deoliveira wrote: > Ok, we seem to be coming from this at different angles. My point is > that a shapefile and a database is not a "Service", so why try to > attach metadata to it, and why try to ask it questions which it cannot > answer. > > imho this is the job of servers like GeoServer

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: > Good sum up of the tradeoffs Gabriel. I think you are right in that a > hybrid type hierarchy - parameterization might be the best way to go. > It can potentially save us some method overloading and additional > interfaces which is really my problem with it. I agree ab

Re: [Geotools-devel] data store / feature collection cleanup proposal

Save the history for a subpage; limit the proposal page to what you want to see done (same advice I gave Gabriel). The actual content seems fine, review gabriel's submission for admiting that getReader and getWriter exist (it is listed as a design goal). The fine details: - create a jira to tra

Re: [Geotools-devel] FeatureAccess proposal ready

Good sum up of the tradeoffs Gabriel. I think you are right in that a hybrid type hierarchy - parameterization might be the best way to go. It can potentially save us some method overloading and additional interfaces which is really my problem with it. > 1) Introducing generics and the required

Re: [Geotools-devel] FeatureAccess proposal ready

Thanks Gabriel - that is a great post. > 3)Introducing a type hierarchy with parametrized types for method parameters > may well worth a try, as it would cover all the use cases with no > overloading. > I have not tried writing this one up yet; should we try and see if the result is Okay? > F

Re: [Geotools-devel] Minimal set of Info considered

Ok, we seem to be coming from this at different angles. My point is that a shapefile and a database is not a "Service", so why try to attach metadata to it, and why try to ask it questions which it cannot answer. imho this is the job of servers like GeoServer and MapServer to store and manage t

Re: [Geotools-devel] FeatureAccess proposal ready

Sorry I am under the assumtion here that CommonSuperClassThing is the templated DataStore ... - and that DataStore is a subclass with all the blanks filled in so that SimpleFeature / SimpleFeatureType client code does not break - ComplexDataStore is a similar thing with the blanks filled in for

Re: [Geotools-devel] FeatureAccess proposal ready

On Thursday 07 February 2008 01:15:52 am Justin Deoliveira wrote: > > When I introduce generics to this picture I end up with more classes? We > > best get specific... > > - CommonSuperClassThing > > - ComplexDataStore extends CommonSuperClassThing > > - DataStore extends CommonSuperClassThing > >

[Geotools-devel] Build failed in Hudson: geotools-trunk #220

See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/220/changes Changes: [aaime] Fix for GEOT-1702, Stack overflow error doing crs lookup -- [...truncated 5671 lines...] [INFO] -

Re: [Geotools-devel] Info

Justin Deoliveira wrote: >> So we have the same approach; my question is how can we avoid >> spending months defining a minimal set? > Easy, take the plan of "only use that which applies to all datastores" > and validate it against the only *concrete* use case we have which is > johanns widget s

[Geotools-devel] Minimal set of Info considered

Justin Deoliveira wrote: > Starting a new thread for this one. > > Sure its useful but in most cases it just does not apply. I mean > consider the three types data stores we have: > > * file based (shapefile) > * database (postgis) > * services (wfs) > > And consider the following metadata: My pri

[Geotools-devel] data store / feature collection cleanup proposal

I have been giving a bit of rough feedback to others for their proposals so here is a chance for people to get back at me. I finally got around to writing up my ideas on how to cleanup data access with regard to feature collection. http://docs.codehaus.org/display/GEOTOOLS/DataStore+Cleanup -J

Re: [Geotools-devel] FeatureAccess proposal ready

> When I introduce generics to this picture I end up with more classes? We > best get specific... > - CommonSuperClassThing > - ComplexDataStore extends CommonSuperClassThing > - DataStore extends CommonSuperClassThing Why do we have to add new classes? The only reason I would see is for conveni

Re: [Geotools-devel] FeatureAccess proposal ready

> > When I introduce generics to this picture I end up with more classes? We > best get specific... > - CommonSuperClassThing > - ComplexDataStore extends CommonSuperClassThing > - DataStore extends CommonSuperClassThing The real problem with that approach is there's a fundamental story we cannot

Re: [Geotools-devel] Info

Apparently each of us needs to start a new thread on this one.. > So we have the same approach; my question is how can we avoid spending > months defining a minimal set? Easy, take the plan of "only use that which applies to all datastores" and validate it against the only *concrete* use case we

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: >> There were two hesitations: >> - when Gabriel started generics were not needed; where he ended up it >> looks like they may be required > I dont understand what this means. It means he was only focused on: FeatureAccess.getSchema(): FeatureType DataStore.getSchema(): Si

[Geotools-devel] Info

Justin Deoliveira wrote: > Ok, we are misunderstanding each other. Here is some code to be clear. > This is what i want the interfaces to look like: > > DataStoreInfo { > > String getURI(); > > } > > DublinCoreInfo extends DataStoreInfo { > > String getTitle(); > > String getPublsiher(); > >

Re: [Geotools-devel] FeatureAccess proposal ready

>> > Sorry, but a deadline is no excuse to crap all over the api. I would > rather if people have these sorts of deadlines they hack outside of > public api. And for deadlines I assume you mean gabriel and the wfs > datastore for the fgdc project. One of the main reasons topp applied for > fun

[Geotools-devel] getInfo on datastore

Starting a new thread for this one. Sure its useful but in most cases it just does not apply. I mean consider the three types data stores we have: * file based (shapefile) * database (postgis) * services (wfs) And consider the following metadata: * title * keywords * description * publisher *

[Geotools-devel] getInfo() post-proposal discussion

Guys, get your own thread to discuss getInfo() ;) Gabriel On Thursday 07 February 2008 12:12:47 am Jesse Eichar wrote: > My problem with idea is that getURI doesn't do much. An extra couple > methods are too hard to implement... So I think it gives some decent > metadata with out too much cost.

[Geotools-devel] Build failed in Hudson: geotools-trunk #219

See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/219/changes Changes: [desruisseaux] Re-inserted lines that was not intented to be removed since they are not a bug. Commented-out (for now) the one that discard the factory and added a comment saying that this line needs to be unc

Re: [Geotools-devel] FeatureAccess proposal ready

My problem with idea is that getURI doesn't do much. An extra couple methods are too hard to implement... So I think it gives some decent metadata with out too much cost. Otherwise all we'll ever get it the URI and that's one step from useless. Keywords, etc... are quite handy if you:

Re: [Geotools-devel] FeatureAccess proposal ready

Jody Garnett wrote: > Justin Deoliveira wrote: > Nope it was my responsibility and I carefully updated the javadocs; if > that was not good enough I need to hear about it. You were correct that > the interfaces were not clear; please review what is there now (rather > than the way things were ye

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: >> You did not vote; hence the +0. > Because I gave negative feedback expecting the proposal to be > reworked. Apparently i dont understand the process. It is the > responsibility of the person who gives feedback to update the > proposal? That does not work for me. Nope

Re: [Geotools-devel] FeatureAccess proposal ready

Jody Garnett wrote: > Justin Deoliveira wrote: >> Here is my feedback: >> >> * getInfo() >> > Already done. It was ServiceInfo and ResourceInfo. Proposal page > explains we are not talking about catalog here. Yeah, but you took the catalog interfaces and put them on the datastore api. Just bec

Re: [Geotools-devel] jaxb vs xml binding

Justin Deoliveira a écrit : > I get the impression with jaxb though all you do is throw some > annotations on some objects and your parsing/serializing is done. Yes, it work like that. Additional work are required if we want to works with GeoAPI interfaces, not only the annotated implementations

Re: [Geotools-devel] FeatureAccess proposal ready

Bad idea for you Gabriel just remove the word Complex - FeatureReader extends Reader - DataStore extends Data - FeatureSource extends Source - FeatureStore extends Store - FeatureLocking extends Locking You are correct that naming is the hardest part. > Indeed that was my first intention but go

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: >> hmmm.. I'm not even pmc, but as it got 3 positives and no negatives I guess >> that's why it went forward... still, feel free to ask who you need to ask >> about that, I was told what I've been doing with WFS client code where >> duplicating that proposal work (that i

Re: [Geotools-devel] FeatureAccess proposal ready

Justin Deoliveira wrote: > Here is my feedback: > > * getInfo() > Already done. It was ServiceInfo and ResourceInfo. Proposal page explains we are not talking about catalog here. > I dont know why my vote says +0... i remember having serious > reservations on this one. Perhaps it is because i

Re: [Geotools-devel] FeatureAccess proposal ready

> * FeatureAccess > > I dont know how I feel about a new interface. I think we may want to > consider a different solution with generics. Not that I love generics > but in this case they may better apply. I assume gabriel has thought > about this route? Indeed that was my first intention but got s

Re: [Geotools-devel] FeatureAccess proposal ready

> > hmmm.. I'm not even pmc, but as it got 3 positives and no negatives I guess > that's why it went forward... still, feel free to ask who you need to ask > about that, I was told what I've been doing with WFS client code where > duplicating that proposal work (that is, providing information t

Re: [Geotools-devel] FeatureAccess proposal ready

On Wednesday 06 February 2008 08:18:41 pm Justin Deoliveira wrote: > Gabriel Roldán wrote: > > Thanks for the feedback, > > > > though I'm not sure why you're complaining about getInfo() as it has > > nothing to do with this proposal? > > like it is a past proposal you can make your voice sound for

Re: [Geotools-devel] FeatureAccess proposal ready

Gabriel Roldán wrote: > Thanks for the feedback, > > though I'm not sure why you're complaining about getInfo() as it has nothing > to do with this proposal? > like it is a past proposal you can make your voice sound for that one.. > See the before/after pictures, getInfo() is in the before bec

Re: [Geotools-devel] FeatureAccess proposal ready

Thanks for the feedback, though I'm not sure why you're complaining about getInfo() as it has nothing to do with this proposal? like it is a past proposal you can make your voice sound for that one.. See the before/after pictures, getInfo() is in the before becuase it is in the api before the in

Re: [Geotools-devel] FeatureAccess proposal ready

Here is my feedback: * getInfo() I guess this is a little off topic of this proposal and related to the last. But I was surprised when i saw it go through today. I remember having voiced feedback about those interfaces not being fine tuned enough. All those attributes: schema, publisher, title

[Geotools-devel] Test failure on gt-trunk?

I'm getting a test failure in org.geotools.xs.bindings.XSQNameBindingTest.java as of today (didn't happen yesterday) Anyone else seeing it? I poked around in the test a bit, but didn't see anything obvious. --saul - This S

[Geotools-devel] IRC breakout meeting for FeatureAccess proposal

Hi all, As stated in the previous message the proposal is ready for your evaluation. I'm calling for a breakout IRC meeting to discuss it, as agreed at yesterdays geoserver irc meeting. The proposed date and time is Feb. 7th, 2007: 17:00 UTC

[Geotools-devel] FeatureAccess proposal ready

Hi all, the proposal to extend the geotools data access interfaces to allow working with GeoAPI Feature and FeatureType as a superset of the current API based on SimpleFeature and SimpleFeatureType is ready for your evaluation. The URL is

[Geotools-devel] [jira] Created: (GEOT-1701) FeatureAcess superclass for DataStore proposal follow up

FeatureAcess superclass for DataStore proposal follow up Key: GEOT-1701 URL: http://jira.codehaus.org/browse/GEOT-1701 Project: GeoTools Issue Type: Task Components: core fea

Re: [Geotools-devel] [Geoserver-devel] confluence slows down to death

Same for me, tried to ask at #codehaus but got no answer On Wednesday 06 February 2008 02:43:23 pm Andrea Aime wrote: > Justin Deoliveira ha scritto: > > But you are correct, codehaus has been unacceptable lately. Has anyone > > talked to the codehaus people to figure out what is going on? > > Trie

Re: [Geotools-devel] [Geoserver-devel] confluence slows down to death

Justin Deoliveira ha scritto: > But you are correct, codehaus has been unacceptable lately. Has anyone > talked to the codehaus people to figure out what is going on? Tried to reach them on IRC (on the #codehaus channel at irc.codehaus.org), no luck, nobody answers. I could not find a mailing li

Re: [Geotools-devel] [Geoserver-devel] confluence slows down to death

We could get ourself a confluence license and host it at topp. My worry is that we will spend more time babysitting it than actually using it. The udig guys have their own confluence instance running do they not? I seem to remember it being a pig and a bit of a nightmare to maintain? But you ar

[Geotools-devel] confluence slows down to death

Hi all, those of you that were trying to edit on confluence over the last days may share my pain. It's being so slow and timing out that its frustrating. At least from here I found it acceptable over late at night, and I mean _late_. What are the options again? will we be switching to another ho

Re: [Geotools-devel] GeoTools and internationalization

On Feb 6, 2008 11:41 AM, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > Simone Giannecchini a écrit : > > I have created the utf resource file in my dir which is called > > a.b.c.i18n, now from my code if I do > > System.out.println(Errors.format(ErrorKeys.TEST)); > > where ErrorKeys was defined

Re: [Geotools-devel] GeoTools and internationalization

Simone Giannecchini a écrit : > I have created the utf resource file in my dir which is called > a.b.c.i18n, now from my code if I do > System.out.println(Errors.format(ErrorKeys.TEST)); > where ErrorKeys was defined by me in a.b.c.i18n, I get the error > message which is instead located into the E

Re: [Geotools-devel] GeoTools and internationalization

On Feb 6, 2008 11:24 AM, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > Simone Giannecchini a écrit : > > The class Errors hardcodes the Class object it uses to load the > > resource bundle hence from wherever you call it it look into > > org.geotools.resources.i18n subdir. Am I right? > > Yes. >

Re: [Geotools-devel] GeoTools and internationalization

Simone Giannecchini a écrit : > The class Errors hardcodes the Class object it uses to load the > resource bundle hence from wherever you call it it look into > org.geotools.resources.i18n subdir. Am I right? Yes. > My goal is to be able to load Errors from wherever I am... Yes it should work...

Re: [Geotools-devel] GeoTools and internationalization

On Feb 6, 2008 10:44 AM, Martin Desruisseaux <[EMAIL PROTECTED]> wrote: > Simone Giannecchini a écrit : > > it is the same approach that I quickly tried but what was not clear to > > me, is if I have to run this myself or if the class is run by the mvn > > build process. In case I run it myself as

Re: [Geotools-devel] GeoTools and internationalization

Simone Giannecchini a écrit : > it is the same approach that I quickly tried but what was not clear to > me, is if I have to run this myself or if the class is run by the mvn > build process. In case I run it myself as it stands I get the > following error "render\src\main not found or is not a dir

Re: [Geotools-devel] GeoTools and internationalization

Thx Martin, it is the same approach that I quickly tried but what was not clear to me, is if I have to run this myself or if the class is run by the mvn build process. In case I run it myself as it stands I get the following error "render\src\main not found or is not a directory.". Hoping on some