Jody Garnett ha scritto:
>>> Either approach would be an improvement on the present instanceof +
>>> try/catch antipattern, so I support this change.
>> Should I take this as a +1? ;-)
>>
> He had already updated the page;
Actually I did
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.o
>> Either approach would be an improvement on the present instanceof +
>> try/catch antipattern, so I support this change.
>
> Should I take this as a +1? ;-)
>
He had already updated the page;
Jody
--
_
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 p
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:
- shapefi
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 capabilit
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
You're a champion :-)
On 27 April 2010 14:53, Jody Garnett wrote:
> Well if that will kick it over the line I will try and add it tonight.
> Jody
>
--
___
Geotools-devel mailin
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 SimpleFe
+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
--
+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
https://lists
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
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 rathe
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) alt
+1 and thanks for updating the javadocs Jody
Michael
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotool
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. 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 new
+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:
> - http://jira.co
+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
Software Engineering Team Leader
CSI
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
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
Geotools-devel
Hi Andrea,
+1
This looks extremely useful and straightforward for users.
Michael
On 27 April 2010 03:34, Andrea Aime 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 in GeoTools
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
---
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
wrote:
> Hi Jody,
>
> Sounds great. Are you still using the drop box thing ?
>
> Michael
>
>
> On 27 April 2010 09:43, Jody G
Hi Jody,
Sounds great. Are you still using the drop box thing ?
Michael
On 27 April 2010 09:43, Jody Garnett 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 to update the wor
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.
--
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 kee
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
--
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
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
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 migh
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 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
Open
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
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 V
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
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
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 performanc
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 t
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--
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 w
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
Che
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 wrote:
>> I am going through other things on my clean up list ...
>> - make Query class, DefaultQuery can stil
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--
___
Geoto
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--
_
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 wrote:
> I am fine with you making the changes Daniele; in
Hi,
On Sat, Apr 24, 2010 at 12:43 AM, Jody Garnett wrote:
> I am fine with you making the changes Daniele; in general I rejected your
> patches because they did not have test cases.
>
> I only helped on 3041 to show you that the methods could be added without
> adding a dependency on commons-io
46 matches
Mail list logo
