Cool - so if you would like to create a test case for your other two patches I
would be pleased to see them accepted.
Jody
On 26/04/2010, at 5:07 PM, Daniele Romagnoli wrote:
Hi,
On Sat, Apr 24, 2010 at 12:43 AM, Jody Garnett jody.garn...@gmail.com wrote:
I am fine with you making the
Proposal ready:
- http://docs.codehaus.org/display/GEOTOOLS/FeatureStore+modifyFeature+by+Name
Patch supplied for associated bug report:
- http://jira.codehaus.org/browse/GEOT-2376
Jody--
Proposal ready:
- http://docs.codehaus.org/display/GEOTOOLS/Query+as+Class
Patch supplied for associated bug report:
- http://jira.codehaus.org/browse/GEOT-3055
Jody--
___
Hi Michael,
Sorry I fell off the list - taking the discussion back there now:
Comments inline:
On 26/04/2010, at 3:03 PM, Michael Bedward wrote:
On 25 April 2010 23:31, Jody Garnett jody.garn...@gmail.com wrote:
I am going through other things on my clean up list ...
- make Query class,
Jody Garnett ha scritto:
Proposal ready:
- http://docs.codehaus.org/display/GEOTOOLS/Query+as+Class
Patch supplied for associated bug report:
- http://jira.codehaus.org/browse/GEOT-3055
Looks like good idea to me. Never seen an actual implementation
of Query other than DefaultQuery
Cheers
Jody Garnett ha scritto:
Proposal ready:
- http://docs.codehaus.org/display/GEOTOOLS/FeatureStore+modifyFeature+by+Name
Patch supplied for associated bug report:
- http://jira.codehaus.org/browse/GEOT-2376
I've been cursing the need to use AttributeDescriptor just recently in
the GSS work
I have updated the proposal in a few spots as per questions on IRC:
- http://docs.codehaus.org/display/GEOTOOLS/Clean+up+Generics+from+DataStore
Discussion has already started (see SimpleFeatureSource proposal ready email).
Jody Garnett ha scritto:
I have updated the proposal in a few spots as per questions on IRC:
- http://docs.codehaus.org/display/GEOTOOLS/Clean+up+Generics+from+DataStore
This hits another thing I've been hating quite a bit working on GSS,
having to either sprinkle generics all around turning
One of the interesting things Andrea contributed to this conversation was
benchmarks.
The conversation goes outside of the SimpleFeatureCollection proposal and
should involve Ben and anyone interested in rendering a generic
FeatureCollection.
Andrea since it is clear that there is a
On 26/04/2010, at 7:11 PM, Andrea Aime wrote:
This hits another thing I've been hating quite a bit working on GSS,
having to either sprinkle generics all around turning the code into
an unreadable soup or bear up with Eclipse
complaints about the code not having the generics.
I have been
Restore geotools FilterFactory
--
Key: GEOT-3056
URL: http://jira.codehaus.org/browse/GEOT-3056
Project: GeoTools
Issue Type: Improvement
Affects Versions: 2.7-M0
Reporter: Jody Garnett
Layer getBoundingBoxes returns just ancestor boxes
--
Key: GEOT-3057
URL: http://jira.codehaus.org/browse/GEOT-3057
Project: GeoTools
Issue Type: Bug
Components: ext wms
Affects
Jody Garnett ha scritto:
As stated before I like the direction this is going, just worried a
bit about the timing and the fact this would make porting patches
over from 2.6.x to trunk (or vice versa) harder for a few months
(until we release 2.7.0)
So is that worry enough for a +0? Or
Hi PMC,
since this is proposal day let me provide you with another one
that sums up part of the discussion of the last week about a
capabilities API in GeoTools:
http://docs.codehaus.org/display/GEOTOOLS/Datastore+capabilities+API
Opinions and votes welcomed
Cheers
Andrea
--
Andrea Aime
Hi,
and here is the proposal to add the remove schema API to trunk:
http://docs.codehaus.org/display/GEOTOOLS/Add+ability+to+remove+feature+types
Votes and opinions are welcomed!
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
Hi all,
I would like permission to add a geojson module into unsupported.
The module in question would be a simple geojson parser and encoder
based on json-simple [1], a fast and streaming capable json parser and
encoder.
The first cut would be the parser and encoder.
Future developments
Justin Deoliveira ha scritto:
Hi all,
I would like permission to add a geojson module into unsupported.
The module in question would be a simple geojson parser and encoder
based on json-simple [1], a fast and streaming capable json parser and
encoder.
fast, streaming... I like it!
+1
Thanks! I am in the processing of doing some benchmarking and initial
results are coming back well!! I will post some numbers soon.
On 4/26/10 1:28 PM, Andrea Aime wrote:
Justin Deoliveira ha scritto:
Hi all,
I would like permission to add a geojson module into unsupported.
The module in
Morning Michael:
I did not expect it but I have another person to go over the geotools workbooks
(yes we can update sphinx later).
As such I am going to update the workbooks to simplefeaturecollection in order
to get some real world feedback on the change away from generics.
Jody
So we went from no proposals to many in a couple of days. The question andrea
raised was timing; and I am not sure how we should answer that.
I would like to get the Clean up Generics from DataStore proposal in and done
so I can work on foss4g materials; also the patch exists now and I am not
looks clean, seems a change that is not very intrusive.
I would say I am +1, but of course I will wait to see welcome from
people more involved into the vector side of the geotools world.
Questions, are there any plans with regards to Shapefiles?
Simone.
Hi Jody,
Sounds great. Are you still using the drop box thing ?
Michael
On 27 April 2010 09:43, Jody Garnett jody.garn...@gmail.com wrote:
Morning Michael:
I did not expect it but I have another person to go over the geotools
workbooks (yes we can update sphinx later).
As such I am going
Yes; Walter is going to test the instructions at some point today (he
is building the branch now in order to do so).
Jody
On Tue, Apr 27, 2010 at 11:25 AM, Michael Bedward
michael.bedw...@gmail.com wrote:
Hi Jody,
Sounds great. Are you still using the drop box thing ?
Michael
On 27 April
On 26 April 2010 11:37, Jody Garnett wrote:
Another patch for trunk: http://jira.codehaus.org/browse/GEOT-3055
I also had a run at cleaning up javadocs for Query which should help.
Jody
This is great Jody - thanks.
Michael
Hi Andrea,
+1
This looks extremely useful and straightforward for users.
Michael
On 27 April 2010 03:34, Andrea Aime aa...@opengeo.org wrote:
Hi PMC,
since this is proposal day let me provide you with another one
that sums up part of the discussion of the last week about a
capabilities API
Hi Andrea,
Sorry if this is a dumb question... This will only be supported by the
JDBC data stores - is that correct ?
Michael
--
___
Geotools-devel mailing list
On 27/04/10 01:05, Andrea Aime wrote:
Jody Garnett ha scritto:
As stated before I like the direction this is going, just worried a
bit about the timing and the fact this would make porting patches
over from 2.6.x to trunk (or vice versa) harder for a few months
(until we release 2.7.0)
So
+1. Good call.
On 26/04/10 15:43, Jody Garnett wrote:
Proposal ready:
- http://docs.codehaus.org/display/GEOTOOLS/Query+as+Class
Patch supplied for associated bug report:
- http://jira.codehaus.org/browse/GEOT-3055
Jody
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software
+1. I agree that the name should be the only significant identifier when
performing an update.
On 26/04/10 15:38, Jody Garnett wrote:
Proposal ready:
- http://docs.codehaus.org/display/GEOTOOLS/FeatureStore+modifyFeature+by+Name
Patch supplied for associated bug report:
-
+1. This make sense, and will allow more flexible use of this class.
There is one slight implementation complication: app-schema allows
multiple definition of feature types, to allow nested (feature chained)
types to used in different ways for different properties. Our
interpretation of the
Andrea,
have you considered other patterns for capabilities, such as a property
container, like Hints, or the GeoAPI UserData map? This would make it
easier for users to add new capabilities without changing the Java API.
In effect, this would be a more dynamically typed approach, which would
+1 and thanks for updating the javadocs Jody
Michael
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
On 27 April 2010 13:22, Ben Caradoc-Davies wrote:
have you considered other patterns for capabilities, such as a property
container, like Hints, or the GeoAPI UserData map?
I'm not a fan of Hints. They tend to be secret knowledge (at least to
new users and long-term neophytes such as me)
I suggested that already (indeed it was where the conversation started).
On the grounds we could sort out what keys are useful before making methods
available.
Andrea would not have any of it :-) I also agree that I am getting sick of
random maps
You will notice that this is a class rather
On 27/04/10 11:48, Jody Garnett wrote:
I suggested that already (indeed it was where the conversation started).
On the grounds we could sort out what keys are useful before making methods
available.
Andrea would not have any of it :-) I also agree that I am getting sick of
random maps
+0
The proposal makes good sense but I lack sufficient knowledge of the code base.
Michael
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
+1
I've tested the code on the simple-features branch and had no problems
so far (osx, java 5)
As per another thread, it would be great to also have SimpleFeatureIterator.
Michael
--
Well if that will kick it over the line I will try and add it tonight.
Jody
On 27/04/2010, at 2:32 PM, Michael Bedward wrote:
+1
I've tested the code on the simple-features branch and had no problems
so far (osx, java 5)
As per another thread, it would be great to also have
You're a champion :-)
On 27 April 2010 14:53, Jody Garnett jody.garn...@gmail.com wrote:
Well if that will kick it over the line I will try and add it tonight.
Jody
--
___
Simone Giannecchini ha scritto:
looks clean, seems a change that is not very intrusive.
I would say I am +1, but of course I will wait to see welcome from
people more involved into the vector side of the geotools world.
Questions, are there any plans with regards to Shapefiles?
I won't
Ben Caradoc-Davies ha scritto:
Andrea,
have you considered other patterns for capabilities, such as a property
container, like Hints, or the GeoAPI UserData map? This would make it
easier for users to add new capabilities without changing the Java API.
That's why I made the capabilities
Michael Bedward ha scritto:
Hi Andrea,
Sorry if this is a dumb question... This will only be supported by the
JDBC data stores - is that correct ?
I plan to initially implement it only for JDBC data stores.
Other stores might go and implement it as well in the future. Examples:
- shapefile
Ben Caradoc-Davies ha scritto:
+1. This make sense, and will allow more flexible use of this class.
There is one slight implementation complication: app-schema allows
multiple definition of feature types, to allow nested (feature chained)
types to used in different ways for different
43 matches
Mail list logo
