That is interesting, Jody. I am not opposed to formalising the role of
representatives, just observing that we have not done so thus far. It
might well be a good idea.
Perhaps we can broaden the language to representative (but this has
legal connotations), or even just person, together with
Proposal is up:
http://docs.codehaus.org/display/GEOTOOLS/Replace+Contribution+Agreement
I had a couple questions in the tasks section which may be worth discussion.
--
Jody Garnett
--
Everyone hates slow websites.
So let do this thing (if we take Andrea's feedback as a +1 you have enough
votes to move)
I am scheduled to release today (or at least this week). If we can move gt-grid
over to extension land I am happy to kick the geotools release out as soon as
you are ready.
--
Jody Garnett
On
Cool ! Should I do it as a pull request or is a direct commit OK ?
On 21 January 2013 09:19, Jody Garnett jody.garn...@gmail.com wrote:
So let do this thing (if we take Andrea's feedback as a +1 you have enough
votes to move)
I am scheduled to release today (or at least this week). If we can
Either works, just ping me when done and I can check locally. (Also if you are
very kind you can move the doc page to be under extensions).
--
Jody Garnett
On Monday, 21 January 2013 at 10:48 AM, Michael Bedward wrote:
Cool ! Should I do it as a pull request or is a direct commit OK ?
On 07/01/13 22:31, Niels Charlier wrote:
I think the reason might be that because of the existence of the
app-schema-test package in geoserver there has been traditionally less
test coverage in the gt-app-schema package itself, but now it becomes
clear that some basic complex feature classes
Looks pretty trivial at this point. Updated the proposal with my +1
On Wed, Jan 16, 2013 at 8:25 PM, Jody Garnett jody.garn...@gmail.comwrote:
So the work was done, as part of the feature collection clean up …
however our proposal is still sitting there with no votes (other than
mine).
Agreed, moved it under the 9.x column. Thank for the +1 anyways Justin.
--
Jody Garnett
On Thursday, 17 January 2013 at 10:21 PM, Justin Deoliveira wrote:
Looks pretty trivial at this point. Updated the proposal with my +1
On Wed, Jan 16, 2013 at 8:25 PM, Jody Garnett
On Thu, Jan 17, 2013 at 1:21 PM, Justin Deoliveira jdeol...@opengeo.orgwrote:
Looks pretty trivial at this point. Updated the proposal with my +1
Same here
Cheers
Andrea
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
Ing. Andrea Aime
+1 from me, updated the proposal
Zitat von Andrea Aime andrea.a...@geo-solutions.it:
On Thu, Jan 17, 2013 at 1:21 PM, Justin Deoliveira
jdeol...@opengeo.orgwrote:
Looks pretty trivial at this point. Updated the proposal with my +1
Same here
Cheers
Andrea
--
==
Our support, Your
So the work was done, as part of the feature collection clean up … however our
proposal is still sitting there with no votes (other than mine).
Can I invite PMC members to check the following
http://docs.codehaus.org/display/GEOTOOLS/Java+7+try-with-resource+compatibility
and see if anything
On Mon, Jan 7, 2013 at 3:31 PM, Niels Charlier ni...@scitus.be wrote:
The ones in xsd-core work only on SimpleFeatures. I never really
understood their use, why would you need an x-path on a simple feature
anyway? In any case, the complex x-path accessor should work on simple
features too as
On Tue, Jan 8, 2013 at 4:06 AM, Andrea Aime andrea.a...@geo-solutions.itwrote:
On Mon, Jan 7, 2013 at 3:31 PM, Niels Charlier ni...@scitus.be wrote:
The ones in xsd-core work only on SimpleFeatures. I never really
understood their use, why would you need an x-path on a simple feature
anyway?
On 12/28/2012 07:34 PM, Andrea Aime wrote:
Hi,
I did not see a review from Jody so far, so I've tried to make one myself
instead (and seen that Rini made a review for the app-schema part last
week).
I did not do a line by line review, but from what I see things are
looking good.
I do
On Wed, Dec 19, 2012 at 1:30 AM, Niels Charlier ni...@scitus.be wrote:
A pull request has been sent:
https://github.com/geotools/geotools/pull/88
I assigned Rini, I guess she will be reviewing it? I also need a review
for the changes in gt-main, I suppose Jody?
Hi,
I did not see a review
Hi Ben,
That is what I meant, proceed to the next step. I will of course let the
actual patch still be reviewed.
Kind Regards
Niels
On 12/18/2012 04:13 AM, Ben Caradoc-Davies wrote:
On 17/12/12 18:58, Niels Charlier wrote:
Cool, with no more objections and a +1 from the module maintainer and
On 12/18/2012 04:13 AM, Ben Caradoc-Davies wrote:
On 17/12/12 18:58, Niels Charlier wrote:
Cool, with no more objections and a +1 from the module maintainer and a
few others I guess I can proceed?
That depends what you mean by proceed: +1 is for the overarching API
change proposal (which
: Re: [Geotools-devel] proposal: Separate general complex feature
classes from gt-app-schema
On 12/18/2012 04:13 AM, Ben Caradoc-Davies wrote:
On 17/12/12 18:58, Niels Charlier wrote:
Cool, with no more objections and a +1 from the module maintainer and
a few others I guess I can proceed
Cool, with no more objections and a +1 from the module maintainer and a
few others I guess I can proceed?
Cheers
Niels
On 12/14/2012 02:37 PM, Andrea Aime wrote:
On Fri, Dec 14, 2012 at 12:13 PM, Niels Charlier ni...@scitus.be
mailto:ni...@scitus.be wrote:
Okay, I now changed the
On 17/12/12 18:58, Niels Charlier wrote:
Cool, with no more objections and a +1 from the module maintainer and a
few others I guess I can proceed?
That depends what you mean by proceed: +1 is for the overarching API
change proposal (which classes are in which modules). In my view, you
should
On Fri, Dec 14, 2012 at 4:02 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Niels, that is a very good point. Andrea, there is a bunch of XSD stuff
like substitution groups that are not represented in GeoAPI. It makes it
quite tricky to break this dependency. Niels knows because he
Okay, I now changed the proposal to move everything to main that can be
moved to main.
Please have a look at the updated version.
I hope we can get the needed +1's as soon as possible.
Cheers
Niels
On 12/14/2012 09:37 AM, Andrea Aime wrote:
On Fri, Dec 14, 2012 at 4:02 AM, Ben Caradoc-Davies
On Fri, Dec 14, 2012 at 12:13 PM, Niels Charlier ni...@scitus.be wrote:
Okay, I now changed the proposal to move everything to main that can be
moved to main.
Please have a look at the updated version.
I hope we can get the needed +1's as soon as possible.
Works for me, +1
Cheers
Andrea
The XPath processor takes XSD information out of the user data in order
to evaluate xml @attributes. That is why it is dependant on it.
On 12/13/2012 08:09 AM, Andrea Aime wrote:
On Wed, Dec 12, 2012 at 5:29 PM, Niels Charlier ni...@scitus.be
mailto:ni...@scitus.be wrote:
Well apart from
Okay I would suggest we could maybe all have an IRC meeting so that we
can come to a final consensus about what to do that everyone can be
happy with? we really need to move forward with this as next week this
project needs to be finished.
On 12/13/2012 04:15 AM, Ben Caradoc-Davies wrote:
It
Niels, that is a very good point. Andrea, there is a bunch of XSD stuff
like substitution groups that are not represented in GeoAPI. It makes it
quite tricky to break this dependency. Niels knows because he
implemented a lot of it.
As future work, we could look at refactoring the way XSD
On Tue, Dec 11, 2012 at 12:15 PM, Niels Charlier ni...@scitus.be wrote:
The Proposal:
http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema
Please vote, or provide criticism.
Scratch scratch, could you clarify what dependencies would one
[INFO] org.geotools:gt-complex:jar:9-SNAPSHOT
[INFO] +- org.geotools:gt-app-schema-resolver:jar:9-SNAPSHOT:compile
[INFO] | +- org.geotools.xsd:gt-xsd-core:jar:9-SNAPSHOT:compile
[INFO] | | +- org.geotools:gt-graph:jar:9-SNAPSHOT:compile
[INFO] | | | \-
On Wed, Dec 12, 2012 at 12:47 PM, Niels Charlier ni...@scitus.be wrote:
[INFO] org.geotools:gt-complex:jar:9-SNAPSHOT
[INFO] +- org.geotools:gt-app-schema-resolver:jar:9-SNAPSHOT:compile
[INFO] | +- org.geotools.xsd:gt-xsd-core:jar:9-SNAPSHOT:compile
[INFO] | | +-
I see. So what you'd suggest we move a bunch of that stuff in to gt-main.
I have to have a look at which part will still remain. Perhaps too
little to keep in a separate package. Maybe we should still move that
stuff into gt-appschema-resolver but keep the name?
On 12/12/2012 01:56 PM,
On Wed, Dec 12, 2012 at 2:45 PM, Niels Charlier ni...@scitus.be wrote:
I see. So what you'd suggest we move a bunch of that stuff in to gt-main.
I have to have a look at which part will still remain. Perhaps too little
to keep in a separate package. Maybe we should still move that stuff into
Well apart from the feature type parser, there is another important part
in the module that relies on xsd stuff, i.e. the xpath property
accessor. This I think is a very important part of complex features;
without this you can't have filters on complex features.
The only thing that really
It would be good if users could build and manipulate complex types and
features without ever touching XML or needing an XML dependency. For
example, they could build types and features programatically. Other
output formats include JSON; complex relationships can be represented in
JSON-LD.
On
On Wed, Dec 12, 2012 at 5:29 PM, Niels Charlier ni...@scitus.be wrote:
Well apart from the feature type parser, there is another important part
in the module that relies on xsd stuff, i.e. the xpath property accessor.
This I think is a very important part of complex features; without this you
The Proposal:
http://docs.codehaus.org/display/GEOTOOLS/Separate+general+complex+feature+classes+from+gt-app-schema
Please vote, or provide criticism.
Kind Regards
Niels Charlier
--
LogMeIn Rescue: Anywhere, Anytime
+1. This change is long overdue and much needed. I have asked Rini and
Adam to review the proposal. gt-app-schema changes should go for review
to Rini as component lead.
Kind regards,
Ben.
On 11/12/12 19:15, Niels Charlier wrote:
The Proposal:
Hi Andrea,
Thank you for your time!
On 08/12/2012 04:09 PM, Andrea Aime wrote:
There is a mix of things that confuse me a bit here:
* the method in the transformation is purely 2D anyways, you won't get
a 3D envelope out of it (it samples the 2D perimeter of the original
bounds
to make
On Wed, Aug 8, 2012 at 3:43 PM, Niels Charlier ni...@scitus.be wrote:
Okay,
The proposal has been updated and a new patch has been uploaded :)
Thanks Niels,
looked at the patch, seems like a solid improvement.
One part that still makes me wonder is this one:
diff --git
Okay,
The proposal has been updated and a new patch has been uploaded :)
Regards
Niels
On 08/07/2012 10:57 AM, Andrea Aime wrote:
On Mon, Aug 6, 2012 at 2:08 PM, Niels Charlier ni...@scitus.be wrote:
Update
Patch:
+ Implement
On Mon, Aug 6, 2012 at 1:06 PM, Niels Charlier ni...@scitus.be wrote:
On 08/06/2012 12:23 PM, Niels Charlier wrote:
Afaik this works the way I explained before, that is, the Z dimension is
left
unaltered during the reprojection.
Which is not true reprojection, but what we can afford given
On Mon, Aug 6, 2012 at 2:08 PM, Niels Charlier ni...@scitus.be wrote:
Update
Patch:
+ Implement
ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method
+ Implement better Transform method
+ Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return SRS
Hi,
I'm not saying that you have to do everything at once, can you answer
the simple question above though?
Restating it: How sure you are that you're going to implement proper
encoding of 3D bboxes at the very least for JDBC stores (and possibly
for shapefiles as well?)
I am sorry, I
Andrea,
I am trying to make an overview of all the changes that require me to do
to the patch and proposal to get them passed.
This is what I have so far:
Patch:
Implement
ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method
Implement better Transform method
Use
On Mon, Aug 6, 2012 at 10:45 AM, Niels Charlier ni...@scitus.be wrote:
The current patch and proposal does not include these features. However, I'd
understand that WFS post requests need to at least support the same features
as wfs get requests. Please let me know the minimum requirements with
Afaik this works the way I explained before, that is, the Z dimension is left
unaltered during the reprojection.
Which is not true reprojection, but what we can afford given that the vertical
transformation module is not working
I reprojected from WGS84 to WGS66 which only differ in their Z
On 08/06/2012 12:23 PM, Niels Charlier wrote:
Afaik this works the way I explained before, that is, the Z dimension is left
unaltered during the reprojection.
Which is not true reprojection, but what we can afford given that the
vertical
transformation module is not working
I reprojected
* for the trasform method imho a better, but simple implementation
would be to reproject the x,y and leave the Z
unaltered (but preserve it). This is what JTS.tarnsform(Geometry,
MathTransform) does today, so it would also preserve
consistency within the library
Actually, the
On 08/06/2012 01:56 PM, Niels Charlier wrote:
* for the trasform method imho a better, but simple implementation
would be to reproject the x,y and leave the Z
unaltered (but preserve it). This is what JTS.tarnsform(Geometry,
MathTransform) does today, so it would also preserve
Update
Patch:
+ Implement
ReferencedEnvelope3D.reference(org.opengis.geometry.Envelope) method
+ Implement better Transform method
+ Use CRS.toSRS( bounds.getCoordinateReferenceSystem() ) to return
SRS string in filter class
+ Remove filtervisitor hack and update
I support this proposal: +1
This proposal has now been significantly narrowed from a request for
relicensing of entire modules to a request for relicensing of individual
files on a case-by-case basis where contributors-in-agreement can be
identified. In my view, this compromise provides a good
On Fri, Aug 3, 2012 at 11:55 PM, Andrea Aime
andrea.a...@geo-solutions.itwrote:
Take also into consideration the data sources, that has implication as
well.
In PostGIS you can declare a 2D CRS and then specify the number of
dimensions
is 3 or 4, that's perfectly fine with the database, and I
On Mon, Jul 30, 2012 at 11:11 AM, Niels Charlier ni...@scitus.be wrote:
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters
Okay, so I decided to remove the Envelope3D class, and merge it with
ReferencedEvelope3D, and make
Hi Andrea,
Thank you for look at it ! Here are some answers to your questions and
concerns:
Looked at the proposal and the patch, a few questions:
* the proposal should tell how are you addressing the dicotomy between
CoordinateReferenceSystem and the SRS string which is required by the
On Fri, Aug 3, 2012 at 3:09 PM, Niels Charlier ni...@scitus.be wrote:
Hi Andrea,
Thank you for look at it ! Here are some answers to your questions and
concerns:
Looked at the proposal and the patch, a few questions:
* the proposal should tell how are you addressing the dicotomy between
On 08/03/2012 03:55 PM, Andrea Aime wrote:
On Fri, Aug 3, 2012 at 3:09 PM, Niels Charlier ni...@scitus.be
mailto:ni...@scitus.be wrote:
Hi Andrea,
Thank you for look at it ! Here are some answers to your questions
and concerns:
Looked at the proposal and the patch, a few
On Fri, Aug 3, 2012 at 9:11 PM, Niels Charlier ni...@scitus.be wrote:
That you need to implement that method, otherwise encoding filters in
CQL/XML will be impossible.
Okay, no problem, but is the above suggested solution good for you? This
is how it happens for ReferencedEnvelope3D's.
On Fri, Aug 3, 2012 at 9:11 PM, Niels Charlier ni...@scitus.be wrote:
I am actually currently working on 3D reprojection atm, but it is a
whole other feature. I am surprised you say this because I though a few
months ago somebody on the list said that 3D reprojection should already
work, and
proposal from previous email request:
- http://docs.codehaus.org/display/GEOTOOLS/Dual+License+Request
PMC : Your prompt feedback appreciated, the OSGeo board has a meeting monday
and I would like to know where we stand
Contributors: This is an unusual request, please make use of the community
On Tue, Jul 31, 2012 at 5:44 PM, Niels Charlier ni...@scitus.be wrote:
Oops it seems some new files are missing in the patch. My apologies,
will upload complete patch in a minute.
Looked at the proposal and the patch, a few questions:
* the proposal should tell how are you addressing the
Thanks Niels
+1 For me now, and yes I was slack as I was supposed to help you fix up the
proposal after voting -1 :(
--
Jody Garnett
On Monday, 30 July 2012 at 7:11 PM, Niels Charlier wrote:
+1 from me.
On 30/07/12 17:11, Niels Charlier wrote:
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters
Okay, so I decided to remove the Envelope3D class, and merge it with
ReferencedEvelope3D, and make ReferencedEvelope3D derived from
I still don't see the new BBOX3D interface... looking at the latest patch
here:
http://jira.codehaus.org/browse/GEOS-5148
But all i wanted to see was if it extends the existing BBOX one which you
confirmed. So I would say I am +1 on this.
On Mon, Jul 30, 2012 at 11:13 PM, Ben Caradoc-Davies
Oops it seems some new files are missing in the patch. My apologies,
will upload complete patch in a minute.
On 07/31/2012 04:38 PM, Justin Deoliveira wrote:
I still don't see the new BBOX3D interface... looking at the latest
patch here:
http://jira.codehaus.org/browse/GEOS-5148
But all i
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters
Okay, so I decided to remove the Envelope3D class, and merge it with
ReferencedEvelope3D, and make ReferencedEvelope3D derived from
ReferencedEnvelope.
I hope this addresses the previously
Looking much better Niels, i think this will slot in much cleaner.
Is BBOX3D a new interface? I was just looking through the patch and not
seeing it defined there although i do see the BBOX3DImpl class defined.
On Mon, Jul 30, 2012 at 2:11 AM, Niels Charlier ni...@scitus.be wrote:
Yeah it should definitely be in there. BBOX3D is the filter interface,
which extends BBOX.
On 07/30/2012 05:04 PM, Justin Deoliveira wrote:
Looking much better Niels, i think this will slot in much cleaner.
Is BBOX3D a new interface? I was just looking through the patch and
not seeing it
What about maintaining two separate envelope classes? I didn't look at the
patch but if there is any real hard work that goes on inside perhaps it
could be deleted out to a utility class.
On Wed, Jul 18, 2012 at 12:37 PM, Niels Charlier ni...@scitus.be wrote:
Okay, but this is impossible
On Thu, Jul 19, 2012 at 4:09 PM, Justin Deoliveira jdeol...@opengeo.orgwrote:
What about maintaining two separate envelope classes? I didn't look at the
patch but if there is any real hard work that goes on inside perhaps it
could be deleted out to a utility class.
The probem with two
On Thu, Jul 19, 2012 at 8:55 AM, Andrea Aime
andrea.a...@geo-solutions.itwrote:
On Thu, Jul 19, 2012 at 4:09 PM, Justin Deoliveira
jdeol...@opengeo.orgwrote:
What about maintaining two separate envelope classes? I didn't look at
the patch but if there is any real hard work that goes on
That means that referencedenvelope3d is not derived from en evelope3d any
longer, which is impossible unless I drop envelope3d all together and merge
them. Is that what you are suggesting? I will look in to this possibility.
Sent from Samsung Mobile
Justin Deoliveira jdeol...@opengeo.org
On Wed, Jul 18, 2012 at 9:30 AM, Niels ni...@scitus.be wrote:
That means that referencedenvelope3d is not derived from en evelope3d any
longer, which is impossible unless I drop envelope3d all together and merge
them. Is that what you are suggesting? I will look in to this possibility.
Yep,
Okay, but this is impossible because ReferencedEvelope3D cannot be
derived from both Envelope3D and ReferencedEnvelope at the same time.
Unless what you mean is that I drop Envelope3D all together and merge
the two classes? I can look in to that option.
Kind Regards
Niels Charlier
On
:* [Geotools-devel] *proposal*: Support for three-dimensional
envelopes and bounding box filters
Hi Everyone,
Please have a look at my proposal:
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters
Please review.
Kind Regards
Niels Charlier
The interface was just an idea I threw in there, because there were concerns
about ReferencedEnvelope3D not being a ReferencedEnvelope.
But the idea of not making separate classes and make the current ones support
3D, I think is quite tricky too.
The algorithms aren't necessarily the same
On Tue, Jul 17, 2012 at 10:15 AM, Jody Garnett jody.garn...@gmail.comwrote:
The interface was just an idea I threw in there, because there were
concerns about ReferencedEnvelope3D not being a ReferencedEnvelope.
But the idea of not making separate classes and make the current ones
support
That would work for me.
--
Jody Garnett
On 17/07/2012, at 7:38 PM, Andrea Aime andrea.a...@geo-solutions.it wrote:
On Tue, Jul 17, 2012 at 10:15 AM, Jody Garnett jody.garn...@gmail.comwrote:
The interface was just an idea I threw in there, because there were
concerns about
When I first read over the proposal this was my thought as well.
On Tue, Jul 17, 2012 at 5:47 AM, Jody Garnett jody.garn...@gmail.comwrote:
That would work for me.
--
Jody Garnett
On 17/07/2012, at 7:38 PM, Andrea Aime andrea.a...@geo-solutions.it
wrote:
On Tue, Jul 17, 2012 at 10:15
Hi Everyone,
Please have a look at my proposal:
http://docs.codehaus.org/display/GEOTOOLS/Support+for+three-dimensional+envelopes+and+bounding+box+filters
Please review.
Kind Regards
Niels Charlier
--
Live Security
message:
From: Niels Charlier ni...@scitus.be
To: geotools-devel@lists.sourceforge.net
Date: Tuesday, 17 July 2012 6:09:35 AM
Subject: [Geotools-devel] *proposal*: Support for three-dimensional envelopes
and bounding box filters
Hi Everyone,
Please have a look at my proposal:
http
)
To: geotools-devel@lists.sourceforge.net
(mailto:geotools-devel@lists.sourceforge.net)
Date: Tuesday, 17 July 2012 6:09:35 AM
Subject: [Geotools-devel] *proposal*: Support for three-dimensional
envelopes and bounding box filters
Hi Everyone,
Please have a look at my proposal
I'm not even going to vote as Jody is our API supremo and you will need
to address his concerns. Thanks, Jody, for providing suggestions to Niels.
My only comment is unrelated: I suggest a slight clarification to the
language describing BBOX, as discussed in GEOS-5148:
Original text: we receive
Did the proposal also want to remove (deprecate in this case) the collection
listeners?
Or was it just the discussion block in the jira?
The CollectionEvent support is replaced by FeatureEvent (i.e. feature source
level) as per another already approved proposal.
Indeed it was completing that
Sorry I did not look closely at the proposal, I only deprecated what it
described, and left the sort and subCollection methods in place (as it also
described). I will double check the remaining methods and update the
proposal page if you like. I am more focused on the patch right now.
On Sun, Jun 24, 2012 at 11:32 AM, Jody Garnett jody.garn...@gmail.comwrote:
I think getDescriptor() is simply missing.
Still don't get it. The need is either clear or it should be left out.
I don't get what you don't get :(
getSchema(): FeatureType (holds the type of the element of the
Okay I get where the confusion comes from …
This is not the descriptor of the feature collection (which you are correct
would be handled by whatever is containing it). This is instead only talking
about getting a better handle on the contents of our feature collection.
My impression this is
On Thu, Jun 21, 2012 at 9:36 AM, Jody Garnett jody.garn...@gmail.comwrote:
Ugh, implemented as you suggest it will affect performance of WPS chaining
a lot.
This is due to the removal of the subCollection methods, which are the
only way to have a streaming process
(one that returns a
On Thu, Jun 21, 2012 at 3:09 AM, Jody Garnett jody.garn...@gmail.comwrote:
A very old proposal removing the methods that assume an in memory model:
- http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+revolution
I have a small non-destructive patch providing the remaining
Ugh, implemented as you suggest it will affect performance of WPS chaining a
lot.
This is due to the removal of the subCollection methods, which are the only
way to have a streaming process
(one that returns a computing collection) compute less data if a downstream
process needs
A very old proposal removing the methods that assume an in memory model:
- http://docs.codehaus.org/display/GEOTOOLS/FeatureCollection+revolution
I have a small non-destructive patch providing the remaining deprecations
outlined in the proposal:
- https://jira.codehaus.org/browse/GEOT-4181
Can
In taking the patch for a spin, we've found some test failures in gt-xsd-fes.
testParseId fails because the xml snippet being parsed contains a
fes:ResourceId with no version attribute. As per spec, this is
acceptable, but the ResourceIdImpl requires a Version or date range.
I have no problem
You got it right. In that case we would use a featureid.
Let us relax that constraint so someone can make a SetResourceId.
--
Jody Garnett
On 26/10/2011, at 5:07 PM, Mark Leslie mrk.les...@gmail.com wrote:
In taking the patch for a spin, we've found some test failures in gt-xsd-fes.
I've attached a patch to jira that cleans up the remaining test
failures (thanks john). The solution to my problem was to create an
explicit ResourceIdImpl constructor that takes no version or dates and
create the default version. Then ResourceIdTypeBinding needs to look
to version to determine
: [Geotools-devel] Proposal: ResourceId
I've attached a patch to jira that cleans up the remaining test failures
(thanks john). The solution to my problem was to create an explicit
ResourceIdImpl constructor that takes no version or dates and create the
default version. Then ResourceIdTypeBinding
The code examples make things clearer :) I haven't managed to apply
the patch to my local and see what the damage would be to GeoGIT, but
that's still on my list. I expect nothing scary in that regard, but
will let you know when I get that done.
--
Mark Leslie
Geospatial Software Architect
Thanks for the review Mark.
I will check test cases again tomorrow (mostly in the xml bindings) and then I
am ready to commit.
I would kind of like feedback from Gabriel (I have already done everything he
indicated was required; but an extra pair of eyes would be good).
--
Jody Garnett
Hi lists,
first of all, sorry for cross posting.
We were thinking about aligning GT 2.7 to depend on ImageIO-Ext 1.1.x, as we
have already done for GT-Trunk.
With respect to older ImageIO-Ext 1.0.x series, 1.1.x provides improvements
like:
- Support for GDAL 1.7.3 (Currently ImageIO-Ext 1.0.8
I like it.
I don't expect it to be much of a trouble for GeoGit. What we'll need to
review is the usage on the wfs2 versioning branch.
As for GeoGit, the main addition is ability to mix attribute/spatial query
with dataset history, instead of just one or the other through ResourceId,
which is
Okay the Proposal is updated ... and more importantly an updated patch is
provided against the Jira.
http://docs.codehaus.org/display/GEOTOOLS/ResouceId
http://jira.codehaus.org/browse/GEOT-3921
This represents a good compromise; and has code examples of a few common
queries, diagrams etc...
I am going to have a run at making a patch on Monday; if I can manage it I
would like to go with FeatureId option. If not I will use your ResourceId
option as a fall back position.
(I am not crazy I am going to start with your ResourceId patch and then
refactor; deprecating the non used
I'm slowly coming round to the FeatureId option. I don't really like
the idea of carrying around the extra version information when 98% of
the time it's going to be placeholders, but it will keep client
efforts cleaner.
I should also clarify my confusion in comparing FeatureId to
ResourceId. I
201 - 300 of 583 matches
Mail list logo
