: [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 ResourceIdTypeBi
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 w
You got it right. In that case we would use a featureid.
Let us relax that constraint so someone can make a Set.
--
Jody Garnett
On 26/10/2011, at 5:07 PM, Mark Leslie wrote:
> In taking the patch for a spin, we've found some test failures in gt-xsd-fes.
>
> testParseId fails because the xm
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 wit
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 much
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
On
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
LISA
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...
Hey check out my proposal for splitting FeatureId and ResourceId on
the other thread.
TIA,
Gabriel
On Wed, Oct 19, 2011 at 8:42 AM, Jody Garnett wrote:
> Matches is supposed to check that a
> feature matches. It is not used to compare identifiers.
>
> Thanks for the clarification however.
>
> I
Matches is supposed to check that a
feature matches. It is not used to compare identifiers.
Thanks for the clarification however.
I was going to have two implementations in order not to waste memory.
Jody
On 19/10/2011, at 6:40 PM, Mark Leslie wrote:
> I'm slowly coming round to the Fea
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 b
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 Recor
Thanks for putting the proposal together Jody. Tough to say which option is
the way to go.. I actually do like the option of just rolling all the
ResourceId stuff into feature id... seems a bit simpler and cleaner, and
definitely easy on client code to not have to do the instanceof check.
On Tue,
13 matches
Mail list logo
