Re: [Geotools-devel] Build failing in app-schema?

Ben Caradoc-Davies ha scritto: > On 25/05/10 21:52, Andrea Aime wrote: >> This is probably due to a version difference, in the repo we have: >> http://download.osgeo.org/webdav/geotools/net/opengis/schemas/sweCommon-1.0.1/1.0.1-1/ >> >> >> which apparently does not qualify to be resolved in the r

Re: [Geotools-devel] Tagging a 2.7.x version - fail!

Removing the tag as it does not build. Please advised when the build is fixed. We have a problem here in that imagemoasic is failing test cases; and taking the build down with it. As a result the rest of the library is building - and still using imagemoasic - but they are using a random version

[Geotools-devel] Tagging a 2.7.x version - fail!

After tagging and building we have the following failures: 1) org.geotools:gt-imagemosaic:jar:2.7-M0 Try downloading the file manually from the project website. 2) org.geotools:gt-imagepyramid:jar:2.7-M0 Try downloading the file manually from the project website. Both of these are commente

[Geotools-devel] [jira] Created: (GEOT-3109) Intermittent build failure in H2DataStoreFactoryTest.testTCP() cause by race condition

Intermittent build failure in H2DataStoreFactoryTest.testTCP() cause by race condition -- Key: GEOT-3109 URL: http://jira.codehaus.org/browse/GEOT-3109 Project: GeoTo

Re: [Geotools-devel] Tagging a 2.7.x version

On 25/05/10 22:36, Andrea Aime wrote: > Mind app-schema is out of the build due to build failuers. > Want to tag like that? I have restored app-schema. No one can reproduce Andrea's build failure (I will investigate further). Justin has made a big JDBC online testing commit. If the build succeed

Re: [Geotools-devel] The beginning of the end for FeatureCollection

How about a previous proposal: - http://docs.codehaus.org/display/GEOTOOLS/Focus+FeatureSource+around+FeatureReader+and+FeatureWriter Some of the substance of this proposal was done at the last moment by me prior to the release of GeoTools 2.5.x - the part protecting us from Java 5 Collections.

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

See -- ___ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/li

[Geotools-devel] Hudson build is back to normal: geotools-2.6.x #374

See -- ___ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lis

Re: [Geotools-devel] The beginning of the end for FeatureCollection

HI Jody, +1 for removing the useless listeners I don't think I understand the wider issues though. Can you point me to some previous posts that I should look at ? Michael --

Re: [Geotools-devel] [ExternalEmail] Going to revert Simone's imageio-ext changes to fix the build

I have reverted Simone's changes on trunk (r35590 and r35591) and 2.6.x (r35592) to fix the build. Developers, please wait until the build has run before you try to break it again. ;-) On 26/05/10 10:55, Ben Caradoc-Davies wrote: > Unless I get an objection before 11:30 AWST (03:30 UTC), I wil

[Geotools-devel] Going to revert Simone's imageio-ext changes to fix the build

Unless I get an objection before 11:30 AWST (03:30 UTC), I will revert Simone's changes to fix the build. (Then I'll be reverting Andrea's unnecessary[?] kicking of app-schema.) Crikey! -- Ben Caradoc-Davies Software Engineering Team Leader CSIRO Earth Science and Resource Engineering Austral

Re: [Geotools-devel] multithreaded rendering

Thanks very much Andrea and Milton for your interesting and clear explanations - much appreciated. They give me a good feel for the technical issues involved. I'm not trying to implement multi-threaded rendering myself (at least not yet), rather I wanted to understand things enough so that the des

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

See -- [...truncated 2403 lines...] org.geotools.util.NumericConverterFactory org.geotools.util.GeometryConverterFactory org.geotools.util.GeometryTypeConverterFactory org.geotools.util.Temp

Re: [Geotools-devel] Build failing in app-schema?

On 25/05/10 21:52, Andrea Aime wrote: > This is probably due to a version difference, in the repo we have: > http://download.osgeo.org/webdav/geotools/net/opengis/schemas/sweCommon-1.0.1/1.0.1-1/ > which apparently does not qualify to be resolved in the range [1.0.1,1.0.2) Andrea, this works fine

Re: [Geotools-devel] A plan for docs

Comments inline; but yes we all agree about the direction. Where we are stuck is on some of the details. On 26/05/2010, at 9:12 AM, Justin Deoliveira wrote: > doc/ > user/ > devel/ > web/ Agreed. trunk/web would be the current website trunk/devel would be the current developers guide 2.6

[Geotools-devel] A plan for docs

Hi all, Continuing with discussion from the "GeoTools 2.6.4 Released" side thread about documentation. So the consencus seems to be to have a top level doc module that would have three submodules: doc/ user/ devel/ web/ I agree that this is probably the easiest way forward. Having do

Re: [Geotools-devel] The beginning of the end for FeatureCollection

On 10-05-25 3:55 PM, Jody Garnett wrote: > > On 26/05/2010, at 7:15 AM, Justin Deoliveira wrote: > >> While I like the idea of removing the duplication I think the real >> problem is in all the FeatureCollection implemetations that lie around >> and do something different. I am fine with FeatureCol

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

See Changes: [simonegiannecchini] passing to imageio-ext 1.0.6 -- [...truncated 2407 lines...] org.geotools.util.GeometryTypeConverterFactory org.geotools.util.TemporalConverterFactory

[Geotools-devel] Build failed in Hudson: geotools-2.6.x #373

See Changes: [simonegiannecchini] passing to imageio-ext 1.0.6 -- [...truncated 2377 lines...] FINE: testAttr is a String [ testAttr = 5 ] -> WHERE testAttr = '5' Tests run: 9, Failures: 0,

Re: [Geotools-devel] The beginning of the end for FeatureCollection

On 26/05/2010, at 7:15 AM, Justin Deoliveira wrote: > While I like the idea of removing the duplication I think the real > problem is in all the FeatureCollection implemetations that lie around > and do something different. I am fine with FeatureCollection duplicating > FeatureSource api as lo

Re: [Geotools-devel] feature collection and rendering

> Correct, the *plan* does not account for a pure memory feature collection. > Although could this could possibly just be a ContentFeatureCollection wrapped > around a FeatureStore from a MemoryDataStore? ContentDataStore is in the data module; I need this in main. So I stole the interesting

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

See Changes: [simonegiannecchini] passing to imageio-ext 1.0.6 -- [...truncated 2490 lines...] FINE: testAttr is a String [ testAttr = 5 ] -> WHERE testAttr = '5' Tests run: 9, Failures: 0,

Re: [Geotools-devel] The beginning of the end for FeatureCollection

While I like the idea of removing the duplication I think the real problem is in all the FeatureCollection implemetations that lie around and do something different. I am fine with FeatureCollection duplicating FeatureSource api as long as it makes it more convenient for the user. But currently

Re: [Geotools-devel] feature collection and rendering

On 10-05-25 9:41 AM, Andrea Aime wrote: > Justin Deoliveira ha scritto: > >> To me a feature collection should just be a convenience wrapper. >> Having a custom one for the purposes of rendering is a different >> story, don't know much about that use case. > > Afaik Jody is after the "toy daset in

Re: [Geotools-devel] feature collection and rendering

Justin Deoliveira ha scritto: > To me a feature collection should just be a convenience wrapper. Having > a custom one for the purposes of rendering is a different story, don't > know much about that use case. Afaik Jody is after the "toy daset in memory" case that many users seem to be playing

Re: [Geotools-devel] feature collection and rendering

On 10-05-25 2:46 AM, Jody Garnett wrote: > On 25/05/2010, at 6:37 PM, Andrea Aime wrote: > >> Lost you there > > Implementation details - don't matter unless you review the code. >> >> Ah, so that you can pass down to a smarter collection the work of filtering. > > Actually I am constructing an in

Re: [Geotools-devel] Tagging a 2.7.x version

Jody Garnett ha scritto: > Hi Daniele: > > I don't see you on IRC to coordinate with; I actually want to tag and > release a 2.7-M0. > > I will go through the motions tomorrow if that is alright; if you cannot > wait (perhaps you are about to merge or something?) please go ahead and > make the

Re: [Geotools-devel] Tagging a 2.7.x version

Hi Daniele: I don't see you on IRC to coordinate with; I actually want to tag and release a 2.7-M0. I will go through the motions tomorrow if that is alright; if you cannot wait (perhaps you are about to merge or something?) please go ahead and make the 2.7-M0 tag. Jody On 25/05/2010, at 10:

[Geotools-devel] Build failing in app-schema?

Here is the failure log: [INFO] [INFO] Building Application schema resolver [INFO]task-segment: [clean, install] [INFO] [INFO] [clean:clean {execu

Re: [Geotools-devel] multithreaded rendering

Hello there Just a quick note from our experience: we also realized that blindly parallelizing the rendering would get us nowhere. But we did not get into Andrea's (quite nice) ideas of automatically dividing the map into zones according to the physical resource. What we did was to create a si

Re: [Geotools-devel] The beginning of the end for FeatureCollection

Jody Garnett ha scritto: > As andrea indicated in his last email there is certain amount of hate for the > duplication between FeatureSource / FeatureCollection :-) > I would like to start stripping abilities out of FeatureCollection in a > careful controlled manner. > > Today I have my first ca

Re: [Geotools-devel] Making SLD param substitution go down to the databases

Andrea Aime ha scritto: > Jody Garnett ha scritto: >> On 25/05/2010, at 8:12 PM, Andrea Aime wrote: >> >>> Jody Garnett ha scritto: Interesting. Could you add some kind of scoping? Something like ${feature.bounds} for the bounds of the current feature? >>> How has that anything to d

[Geotools-devel] [jira] Created: (GEOT-3108) Bad practices in code can cause permanent generation leaks in web applications

Bad practices in code can cause permanent generation leaks in web applications -- Key: GEOT-3108 URL: http://jira.codehaus.org/browse/GEOT-3108 Project: GeoTools Iss

Re: [Geotools-devel] Making SLD param substitution go down to the databases

Jody Garnett ha scritto: > On 25/05/2010, at 8:12 PM, Andrea Aime wrote: > >> Jody Garnett ha scritto: >>> Interesting. >>> Could you add some kind of scoping? Something like ${feature.bounds} for >>> the bounds of the current feature? >> How has that anything to do with the topic of this thread?

[Geotools-devel] Tagging a 2.7.x version

Hi list, we would like to tag a 2.7 version (something like a 2.7-M0). Today I have noticed Jody and Michael too are working on tagging a 2.7 version. To avoid duplicated work, how long tagging this would require for you? If you have long deadline, I can do a custom 2.7 Tag for internal uses. (as a

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

See -- ___ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/lis

Re: [Geotools-devel] Making SLD param substitution go down to the databases

Jody Garnett ha scritto: > On 25/05/2010, at 8:12 PM, Andrea Aime wrote: > >> Jody Garnett ha scritto: >>> Interesting. >>> Could you add some kind of scoping? Something like ${feature.bounds} for >>> the bounds of the current feature? >> How has that anything to do with the topic of this thread?

Re: [Geotools-devel] Making SLD param substitution go down to the databases

On 25/05/2010, at 8:12 PM, Andrea Aime wrote: > Jody Garnett ha scritto: >> Interesting. >> Could you add some kind of scoping? Something like ${feature.bounds} for the >> bounds of the current feature? > How has that anything to do with the topic of this thread? :-) You asked about a "dynamic"

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

See -- A SCM change trigger started this job Updating http://svn.osgeo.org/geotools/trunk ERROR: Failed to update http://svn.osgeo.org/geotools/trunk org.tmatesoft.svn.core.SVNException: svn: timed

Re: [Geotools-devel] Making SLD param substitution go down to the databases

Jody Garnett ha scritto: > Interesting. > > Could you add some kind of scoping? Something like ${feature.bounds} for the > bounds of the current feature? How has that anything to do with the topic of this thread? :-) The environment function has no feature scoping, the values are set using setL

Re: [Geotools-devel] Making SLD param substitution go down to the databases

Interesting. Could you add some kind of scoping? Something like ${feature.bounds} for the bounds of the current feature? Jody On 25/05/2010, at 7:57 PM, Andrea Aime wrote: > Hi, > I'm looking for a way to make EnvFunction used in filters > play nice with databases and stores in general. > > W

[Geotools-devel] Making SLD param substitution go down to the databases

Hi, I'm looking for a way to make EnvFunction used in filters play nice with databases and stores in general. What happens now is that the function is not recognized and thus forces that part of the filter to be evaluated in memory. It would be nice to perform the param value expansion into a lit

[Geotools-devel] Adding parameters in sql views

Hi, as you all probably know thanks to Michael work we recently got the ability to peform on parameter substitution in SLD and filters courtesy of the EnvFunction filter function. That is great and adds a great deal of flexibility to styling without significant risks, as the params are either eval

[Geotools-devel] The beginning of the end for FeatureCollection

As andrea indicated in his last email there is certain amount of hate for the duplication between FeatureSource / FeatureCollection :-) I would like to start stripping abilities out of FeatureCollection in a careful controlled manner. Today I have my first candidate for removal: - addListener(Co

Re: [Geotools-devel] feature collection and rendering

On 25/05/2010, at 6:37 PM, Andrea Aime wrote: > Lost you there Implementation details - don't matter unless you review the code. > > Ah, so that you can pass down to a smarter collection the work of filtering. Actually I am constructing an in memory feature source / feature collection combo.

Re: [Geotools-devel] feature collection and rendering

Jody Garnett ha scritto: > HI Andrea: > > I have been finally responding to a long standing wish/issue on the user list > a replacement for DefaultFeatureCollection. > > I have done two implements: > - TreeSetFeatureCollection (a straight up copy of DefaultFeatrueCollection so > we can pre

Re: [Geotools-devel] multithreaded rendering

Michael Bedward ha scritto: > Hi Andrea, Jody, > > I'm reworking the RenderingExecutor class in the swing module. At > present, RenderingExecutor is designed to work with one map pane, > running one rendering task at a time. In the new swing code > RenderingExecutor will offer multiple threads (f

Re: [Geotools-devel] Nominate Shane Bailie for GeoTools commit access

Ben Caradoc-Davies ha scritto: > I nominate my colleague Shane Bailie for GeoTools commit access. All the > usual rules apply (commits must be approved by module maintainers). > Shane has already fixed one bug in complex feature WFS encoding, and his > work has been reviewed by Rini and Justin.