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.
--
Ben Caradoc-Davies
I think you've got far too many helpers Ben - it must be a managerial
burden. Perhaps I could assist by taking some of them off your
hands...
Michael
On 25 May 2010 16:04, Ben Caradoc-Davies ben.caradoc-dav...@csiro.au wrote:
I nominate my colleague Shane Bailie for GeoTools commit access. All
There are more to come!
We will not have all of them as full-time developers. Many will focus on
GeoServer deployments, and will fix GeoServer and GeoTools bugs on a
part-time basis.
On 25/05/10 14:26, Michael Bedward wrote:
I think you've got far too many helpers Ben - it must be a
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.
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 (from a
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 preserve
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.
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:
-
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
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
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.
What
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
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2727/
--
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
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 scope
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? :-)
You
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2728/
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
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
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? :-)
You
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
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 do with the topic of
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
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
Here is the failure log:
[INFO]
[INFO] Building Application schema resolver
[INFO]task-segment: [clean, install]
[INFO]
[INFO] [clean:clean
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
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 2.7-M0
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 memory
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
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 memory
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
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2731/changes
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,
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
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 long
See http://hudson.opengeo.org/hudson/job/geotools-2.6.x/373/changes
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,
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2732/changes
Changes:
[simonegiannecchini] passing to imageio-ext 1.0.6
--
[...truncated 2407 lines...]
org.geotools.util.GeometryTypeConverterFactory
org.geotools.util.TemporalConverterFactory
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 FeatureCollection
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
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
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
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2733/
--
[...truncated 2403 lines...]
org.geotools.util.NumericConverterFactory
org.geotools.util.GeometryConverterFactory
org.geotools.util.GeometryTypeConverterFactory
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
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 ben.caradoc-dav...@csiro.au
Software Engineering Team Leader
CSIRO Earth Science and
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
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
--
See http://hudson.opengeo.org/hudson/job/geotools-2.6.x/374/changes
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2734/changes
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
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
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
Intermittent build failure in H2DataStoreFactoryTest.testTCP() cause by race
condition
--
Key: GEOT-3109
URL: http://jira.codehaus.org/browse/GEOT-3109
Project:
48 matches
Mail list logo
