[Geotools-devel] [jira] Created: (GEOT-1703) Default Query against WFS returns no features

Default Query against WFS returns no features - Key: GEOT-1703 URL: http://jira.codehaus.org/browse/GEOT-1703 Project: GeoTools Issue Type: Bug Affects Versions: 2.4-RC0 Reporter: J

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

Sure but it is also nice to not have to think and just have a default right there. Jesse Le 7-Feb-08 à 2:38 PM, Justin Deoliveira a écrit : > This makes my point. The fact that you and I have different ideas > about what it should be. It should not be for the format driver to > decide. It

Re: [Geotools-devel] data access with generics example

Right, forgot about those. And as a special gift just for you i also added: FeatureSource.accept( FilterVisitor, ProgressListener ); FeatureSource.accept( Filter, FilterVisitor, ProgressListener ); :) Jody Garnett wrote: > Sweet! Great work Justin ... > > A couple of questions; what happened to

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

This makes my point. The fact that you and I have different ideas about what it should be. It should not be for the format driver to decide. It should be the decision of whoever is creating the ui. Jesse Eichar wrote: > I'd expect the icon to be a polygon for a polgyons, line for line, > etc...

Re: [Geotools-devel] data access with generics example

Justin Deoliveira wrote: > http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/org/geotools/data/FeatureCollection.java > Correction: http://svn.geotools.org/geotools/trunk/spike/jdeolive/api/src/main/java/org/geotools/feature/FeatureCollection.java > * The update path to Fe

Re: [Geotools-devel] data access with generics example

Sweet! Great work Justin ... A couple of questions; what happened to the use of Name? - DataAccess.getNames(): List - DataAccess.getSchema( Name ) Jody - This SF.net email is sponsored by: Microsoft Defy all challenges. Micr

Re: [Geotools-devel] What is missing for a 2.4.0 final release?

Looks like there are some patches waiting for a 2.4.x developer; jpfise1 was online asking about them ... - GEOT-386 (http://pastebin.org/18637) These patches involve the use filters with GeoServer 1.6.0-RC3. Requesting all content and getting nothing. Justin and Gabriel are talking to him now.

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

I'd expect the icon to be a polygon for a polgyons, line for line, etc... Would you expect a generic "shapefile" icon? Jesse Le 7-Feb-08 à 1:35 PM, Justin Deoliveira a écrit : > Jody Garnett wrote: >> Justin Deoliveira wrote: >>> I am still not getting the point of icon. Would it be some well

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

Jody Garnett wrote: > Justin Deoliveira wrote: >> I am still not getting the point of icon. Would it be some well known >> icon that we copy into the shapefile module? And just return it as >> need be? What if an app wants to use another icon? Does not seem to fit. > From the point of view of ma

[Geotools-devel] data access with generics example

Hi all, As per the data access irc breakout i have created a spike which employs the changes. The spike is available at: http://svn.geotools.org/geotools/trunk/spike/jdeolive Its a maven project so you can build it and load it into your ide if you wish. However you need to have a geotools trun

[Geotools-devel] GeoAPI 2.1.0 released

* Created GeoAPI 2.1.0 tag: https://geoapi.svn.sourceforge.net/svnroot/geoapi/tags/ * Deployed on Maven repositories: http://lists.refractions.net/m2/org/opengis/geoapi/2.1.0/ http://maven.geotools.fr/repository/org/opengis/geoapi/2.1.0/ * Updated on-line javadoc: http://geoapi.sourceforg

Re: [Geotools-devel] IRC breakout meeting for FeatureAccess proposal

Hey, I haven't fully absorbed all the issues, but I did skim over the irc logs, and thought I'd comment on one thing. I don't think it's worth doing backflips to maintain backwards compatibility at this point in time. We're already breaking the api with the SimpleFeature change. If we'd alre

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

Justin Deoliveira wrote: > I am still not getting the point of icon. Would it be some well known > icon that we copy into the shapefile module? And just return it as > need be? What if an app wants to use another icon? Does not seem to fit. From the point of view of making presentable user inter

Re: [Geotools-devel] What is missing for a 2.4.0 final release?

I can do the deploy step again if you need Andrea. Jody > Hi, > so it seems we're almost good for a 2.4.0 release. > What is missing? Can anybody provide a list of his own? > 1) We still depend on geoapi 2.1-rc1. Did any other change occurr > in that geoapi branch, of can rc1 be re-released as

Re: [Geotools-devel] What is missing for a 2.4.0 final release?

Andrea Aime wrote: > Hi, > so it seems we're almost good for a 2.4.0 release. > What is missing? Can anybody provide a list of his own? > 1) We still depend on geoapi 2.1-rc1. Did any other change occurr >in that geoapi branch, of can rc1 be re-released as 2.1 final? > geoapi 2.1.1 would als

Re: [Geotools-devel] Update on the easymock/junit4 stuff

Andrea can you add a really simple example to the developers guide for lame developers like me that would rather waste your time then read the docs ;-) Jody > Hi, > I've discovered that the easymock class extension (allowing to > mock up classes) works with junit3 as well, it just requires > juni

Re: [Geotools-devel] What is missing for a 2.4.0 final release?

Chris Holmes a écrit : > Sounds great, thanks a ton Martin for all the help with the referencing > stuff, it sounds like it's all fixed. So as soon as we get out GeoAPI > 2.1.0 we can release GeoServer 1.6.0. Let me know if there's anything > we can do to help out with the GeoAPI release. I also

Re: [Geotools-devel] FeatureAccess proposal ready

> > > As for the no interfaces/generify debate, my generics abilities > > are probably lower than yours. Can anyone come up with a counter > > proposal using the hybrid approach so that we can have a look > > at it instead of talking about vapourware? > > gonna try to figure it out in real code the

Re: [Geotools-devel] IRC breakout meeting for FeatureAccess proposal

Breakout meeting time, anyone that want to join please do at #geotools. Cheers, Gabriel On Wednesday 06 February 2008 06:57:19 pm Gabriel Roldán wrote: > Hi all, > > As stated in the previous message the proposal is ready for your > evaluation. > > I'm calling for a breakout IRC meeting to discus

Re: [Geotools-devel] What is missing for a 2.4.0 final release?

Sounds great, thanks a ton Martin for all the help with the referencing stuff, it sounds like it's all fixed. So as soon as we get out GeoAPI 2.1.0 we can release GeoServer 1.6.0. Let me know if there's anything we can do to help out with the GeoAPI release. best regards, Chris Martin Desr

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

Andrea Aime ha scritto: > Justin Deoliveira ha scritto: >> 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 collecti

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

Justin Deoliveira ha scritto: > 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.

Re: [Geotools-devel] [Geoserver-devel] What is missing for a 2.4.0 final release? (ready for gt 2.4.0 1.6.0 release people!)

Andrea Aime a écrit : > So it seems we're gold to release 2.4.0. If no body object I will wait a few hours (up to tonigh), release GeoAPI 2.1.0 final if nobody objected against it and change the dependency on GeoTools 2.4 branch from GeoAPI 2.1-RC1 to 2.1.0. I would like to do so before 2.4 is rel

Re: [Geotools-devel] What is missing for a 2.4.0 final release? (ready for gt 2.4.0 1.6.0 release people!)

Andrea Aime ha scritto: > Hi, > 3) We still need to re-run all of the cite test suites > in GeoServer to make sure that no other bugs popped up lately > (and this must be done before releasing 2.4.0) Done the following with the cite offline test engine: WFS 1.0: check (450 tests passed) W

Re: [Geotools-devel] FeatureAccess proposal ready

On Thursday 07 February 2008 03:35:11 pm Justin Deoliveira wrote: > > I see your point, we're on the same boat here. Ie just the place where > > our proposals join? > > So are you comfortable with org.geoapi.feature.FeatureCollection for the > > general case and org.geotools.feature.FeatureCollecti

Re: [Geotools-devel] FeatureAccess proposal ready

> I see your point, we're on the same boat here. Ie just the place where our > proposals join? > So are you comfortable with org.geoapi.feature.FeatureCollection for the > general case and org.geotools.feature.FeatureCollection for the simple > feature case? > once you're proposal goes ahead yo

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

Thanks for the feedback Gabriel. Some comments inline. Gabriel Roldán wrote: > 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 s

Re: [Geotools-devel] FeatureAccess proposal ready

Hi Justin, On Thursday 07 February 2008 03:11:56 pm Justin Deoliveira wrote: > I just thought i would chime in again with my thoughts on7 > FeatureCollection. I am indifferent to having a new FeatureCollection > interface. My main concern is with the implementation of > FeatureCollection. As long

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

Jody Garnett wrote: > Save the history for a subpage; limit the proposal page to what you want > to see done (same advice I gave Gabriel). Can do... its just so hard... :) > > The actual content seems fine, review gabriel's submission for admiting > that getReader and getWriter exist (it is list

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

> Yeah I get it; thinking so with that use case in mind publisher, > keywords, description and title would vanish? Or at least be optional > (reserved for a subclass?) > ... I am still stuck requiring icon and type (even though it causes > friction). It is tempting to think of icon and typ

Re: [Geotools-devel] FeatureAccess proposal ready

I just thought i would chime in again with my thoughts on FeatureCollection. I am indifferent to having a new FeatureCollection interface. My main concern is with the implementation of FeatureCollection. As long as it is implemented *once*, and in terms of FeatureSource i am happy. Past that w

Re: [Geotools-devel] FeatureAccess proposal ready

Gabriel Roldán ha scritto: >> Hi, >> here is my feedback. >> >> FeatureAccess name must be killed, it's too easy to mistake it as part >> of the FeatureSource, FeatureSource, FeatureLocking familiy. >> ComplexDataStore may not sound nice, but it's at least consistent >> with the other names you're

Re: [Geotools-devel] FeatureAccess proposal ready

> Hi, > here is my feedback. > > FeatureAccess name must be killed, it's too easy to mistake it as part > of the FeatureSource, FeatureSource, FeatureLocking familiy. > ComplexDataStore may not sound nice, but it's at least consistent > with the other names you're coming up with. right. A couple op

Re: [Geotools-devel] Update on the easymock/junit4 stuff

Andrea Aime a écrit : > Af for the upgrade to junit4 and surefire, I did test it and it > was working for me, not sure if to proceed on that road as well > or not? (given I have no real _need_ for it anymore) I'm still +1 for upgrating to JUnit 4 on trunk. Having it at hand will allows us to slowl

[Geotools-devel] Update on the easymock/junit4 stuff

Hi, I've discovered that the easymock class extension (allowing to mock up classes) works with junit3 as well, it just requires junit4 if you're tring to build it from sources. So for the moment I added the easymock and easymock-classextension to the poms and committed the tests (they are working

[Geotools-devel] Hudson build is back to normal: geotools-trunk #223

See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/223/changes - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/d

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

See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/222/changes -- [...truncated 5644 lines...] [INFO]task-segment: [clean, install] [INFO] [INFO] artifact org.cod

Re: [Geotools-devel] What is missing for a 2.4.0 final release?

Martin Desruisseaux a écrit : > So I suggest to do the release for the 2.1 branch. Typo: "*from* the 2.1 branch." Martin - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio

Re: [Geotools-devel] What is missing for a 2.4.0 final release?

Andrea Aime a écrit : > 1) We still depend on geoapi 2.1-rc1. Did any other change occurr > in that geoapi branch, of can rc1 be re-released as 2.1 final? Just posted an email on GeoAPI mailing list. I did a "svn diff" and the only change is synchronization lock in CodeList.valueOf(String) met

[Geotools-devel] What is missing for a 2.4.0 final release?

Hi, so it seems we're almost good for a 2.4.0 release. What is missing? Can anybody provide a list of his own? 1) We still depend on geoapi 2.1-rc1. Did any other change occurr in that geoapi branch, of can rc1 be re-released as 2.1 final? 2) Proposals that need to be closed? I know I still hav

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

See http://gridlock.openplans.org:8080/hudson/job/geotools-trunk/221/changes Changes: [aaime] GEOT-1702) Stack overflow error doing crs lookup,this time with unit tests -- [...truncated 5699 lines...] [INFO] --

Re: [Geotools-devel] FeatureAccess proposal ready

Gabriel Roldán ha scritto: > 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 >