Re: [Geotools-devel] About coverage interfaces in geoapi

Yes, it builds without problem on my local machine too now. Thanks for this cleanup Simone - a big improvement ! Michael On 11 January 2011 17:45, Simone Giannecchini wrote: > Ciao Michael, > forgotten commit. > Everything seems fine now. > > Simone. > --

Re: [Geotools-devel] About coverage interfaces in geoapi

Ciao Michael, forgotten commit. Everything seems fine now. Simone. --- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder Via Poggio alle Viti 1187 55054  Massarosa (LU) Italy phone: +39 0584962313 fax:      +39 0584962313 mob:    +39 333 812

Re: [Geotools-devel] Query and CommonFactory finder (ie beyond namespace 2)

A very good idea Gabriel, I mentioned this on the other email thread but I have an alternative to consider? I would like to collect all the factory finder stuff into the GeoTools class; resulting in more readable code. I think we can do this as the factory lookup code does not depend on any sp

Re: [Geotools-devel] Query and CommonFactory finder (ie beyond namespace 2)

On Tue, 2011-01-11 at 13:30 +1000, Jody Garnett wrote: > The namespace 2 discussion has been productive (introducing of gt-opengis, > creation of two proposals) but is now stuck... > > The Query interface would like to work with PropertyName to capture a list of > xpath expressions to be obtaine

Re: [Geotools-devel] Query and CommonFactory finder (ie beyond namespace 2)

Hmmm... ideally we could just move CommonFactoryFinder to api but it seems to drag along quite a few dependent classes also in main. Following the graph down I got to AbstractFeatureFactoryImpl which brings in a bunch of the feature implementation classes. I doubt moving back Query into main will b

Re: [Geotools-devel] 2.7-beta1 planning

On 11/01/11 11:31, Justin Deoliveira wrote: Hi all, I wanted to check in again about planning 2.7-beta1 for this week. At the moment there seems to be two things moving: 1. The namespace aware property name stuff being done by Niels 2. coverage api / opengis module stuff by Simone et al I wa

[Geotools-devel] 2.7-beta1 planning

Hi all, I wanted to check in again about planning 2.7-beta1 for this week. At the moment there seems to be two things moving: 1. The namespace aware property name stuff being done by Niels 2. coverage api / opengis module stuff by Simone et al I was hoping to get a feel from Niels and Simone whe

[Geotools-devel] Query and CommonFactory finder (ie beyond namespace 2)

The namespace 2 discussion has been productive (introducing of gt-opengis, creation of two proposals) but is now stuck... The Query interface would like to work with PropertyName to capture a list of xpath expressions to be obtained via the Query. To do a nice job of this it would be good to ha

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

See -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn

Re: [Geotools-devel] anyone aware of geotiff issue on linux only?

I am stepping through the code now; it gets back a normal GeoTiff reader and uses it with a GridCoverageReader as expected. So I am not seeing anything unusual on my end. I have managed to get one interesting stack trace (when checking the style): An internal error occurred during: "Update Hist

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

See Changes: [mbedward] Removed incorrect import of GridRange class -- [...truncated 10875 lines...] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.516 sec Running org.ge

Re: [Geotools-devel] About coverage interfaces in geoapi

The problem appeared to be just a left-over import statement. I've kicked the build server. Fingers crossed again... On 11 January 2011 12:19, Michael Bedward wrote: > Bummer - build fails in jpk2 module.  Checking that out now... > > On 11 January 2011 11:09, Simone Giannecchini > wrote: >> cro

Re: [Geotools-devel] About coverage interfaces in geoapi

Bummer - build fails in jpk2 module. Checking that out now... On 11 January 2011 11:09, Simone Giannecchini wrote: > crossing fingers, firing the commit! > > Simone. > --- > Ing. Simone Giannecchini > GeoSolutions S.A.S. > Founder > > Via Poggi

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

See Changes: [simonegiannecchini] GEOT-3375 [simonegiannecchini] GEOT-3375 [simonegiannecchini] GEOT-3375 -- [...truncated 7203 lines...] Running org.geotools.data.postgis.ps.PostgisDateT

Re: [Geotools-devel] About coverage interfaces in geoapi

crossing fingers, firing the commit! Simone. --- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder Via Poggio alle Viti 1187 55054  Massarosa (LU) Italy phone: +39 0584962313 fax:      +39 0584962313 mob:    +39 333 8128928 http://www.geo-

Re: [Geotools-devel] About coverage interfaces in geoapi

++1 Simone :) Michael On 11 January 2011 09:42, Simone Giannecchini wrote: > Ciao Jody, > thanks for checking the patches. > I would wait a bit in order to gather feedback from others, possibly michael > :) > > Simone. > --- > Ing. Simone Gian

Re: [Geotools-devel] About coverage interfaces in geoapi

Ciao Jody, thanks for checking the patches. I would wait a bit in order to gather feedback from others, possibly michael :) Simone. --- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder Via Poggio alle Viti 1187 55054  Massarosa (LU) Italy p

Re: [Geotools-devel] About coverage interfaces in geoapi

Sounds good on this end. Jody On 11/01/2011, at 1:34 AM, Simone Giannecchini wrote: > Ciao Jody, > I have worked on removing the unneeded interfaces from the opengis > coverage package and subpackages. > I have also remove all those thousand of deprecated methods we had in > coverage subclasses.

[Geotools-devel] [jira] Created: (GEOT-3375) Perform essential clean up on coverage interfaces

Perform essential clean up on coverage interfaces - Key: GEOT-3375 URL: http://jira.codehaus.org/browse/GEOT-3375 Project: GeoTools Issue Type: Improvement Components: core coverage

[Geotools-devel] [jira] Reopened: (GEOT-3221) When multithreading granules read is allowed, check for ThreadPoolExecutor instance provided through Hints

[ http://jira.codehaus.org/browse/GEOT-3221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniele Romagnoli reopened GEOT-3221: - Reopened for porting to 2.6.x > When multithreading granules read is allowed, check for ThreadPoolE

[Geotools-devel] [jira] Reopened: (GEOT-3220) Add a Hints to allow specifying a ThreadPoolExecutor instance

[ http://jira.codehaus.org/browse/GEOT-3220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniele Romagnoli reopened GEOT-3220: - Reopened for porting on 2.6.x > Add a Hints to allow specifying a ThreadPoolExecutor instance > ---

Re: [Geotools-devel] namespaces part 2

So this is often what happen; you start the proposal to get your thoughts in order; and then when creating the patch some other trouble comes up. If you can figure out a good way to sort things out (perhaps move CommonFactory finder to gt-api? It is part of how you use geotools after all) then yo

Re: [Geotools-devel] namespaces part 2

On 10/01/11 14:49, Jody Garnett wrote: Oh I see your point ... I cannot think of anything to do with out having the code in front of me. CommonFactoryFinder is probably part of gt-main or something. I have been wanting to move the common factory responsibilities to the GeoTools class for some