Andrea Aime wrote:
jgarnett++
I think you mean ++jgarnett, because you want to increment before use. :-)
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
Andrea Aime wrote:
SetNames getProperties gives up namespace support,
[...]
ListNames would give the best of both worlds it seems?
These are all interfaces. I thought iteration order was specified by the
implementation? CollectionName is iterable and allows implementers to
choose. See, for
It is more that iterator order is not defined unless you are a list. So
while we could use SetName (presumably to indicate that we are not going
to have duplicate names) it would fail to capture the idea of an order.
SortedSet would capture the idea of an order (but is otherwise crazy since
the
ListName is the way to go; we need some control over attribute order in
the result (at least to be able to match XML schemas where such a thing has
been defined using a sequence. I actually wonder if this is an area where we
could simplify our model some - I am still waiting for an unordered
Jody Garnett wrote:
On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Justin Deoliveira wrote:
Changing the Query API will affect every DataStore. If this
is done by expanding Query and DefaultQuery as you
Ben Caradoc-Davies wrote:
I can either:
(1) Fix SimpleFeatureTypeBuilder.
(2) Implement a new WFSConfiguration that does not use
GML{2,3}EncoderUtils, and figure out how to get GeoServer to use it.
Just to add my usual performance perspective to the mix, the gt-xsd
encoder is 2-4 times
On Thursday 26 February 2009 02:04:15 Jody Garnett wrote:
On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Justin Deoliveira wrote:
Changing the Query API will affect every DataStore. If this is done by
expanding Query and DefaultQuery as you
Andrea Aime wrote:
Ben Caradoc-Davies wrote:
I can either:
(1) Fix SimpleFeatureTypeBuilder.
(2) Implement a new WFSConfiguration that does not use
GML{2,3}EncoderUtils, and figure out how to get GeoServer to use it.
Just to add my usual performance perspective to the mix, the gt-xsd
Attribute order is in fact important. ISO have specified a
implementation hint - aka a UML tag - for attribute order. Simon Cox
tells me is a technically mandatory part of the meta-model for
features - I'll chase dow the reference if anyone cares that much :-)
.
Rob
On Sat, Feb 28, 2009 at 3:15
Jody and Justin,
I have been investigating the changes needed allow the existing GML
bindings to be used to encode complex features. While I am pleased with
how far I have been able to get with some hacked-up prototypes, there
are significant problems that remain, and many involve namespace
Ben Caradoc-Davies wrote:
It appears that SimpleFeatureTypeBuilder
accepts only String property names,
Aren't features using multiple namespaces in the same feature type
already falling in the complex feature case?
What's simple is actually not very clear in my mind. For example, in
OGR
Ben Caradoc-Davies wrote:
Jody and Justin,
I have been investigating the changes needed allow the existing GML
bindings to be used to encode complex features. While I am pleased with
how far I have been able to get with some hacked-up prototypes, there
are significant problems that
Justin Deoliveira wrote:
It seems to me that GeoTools requires wide-ranging
backwards-incompatible changes to better support namespaces. This may
cause inconvenience to those who have code based on GeoTools.
(1) Does the community want to see such a change?
Yes, but my experience with
Andrea Aime wrote:
Aren't features using multiple namespaces in the same feature type
already falling in the complex feature case?
What's simple is actually not very clear in my mind. For example, in
OGR simple means no namespace, no associations, no multi valued
attributes, and one single
A quick reply while I have time :-D
(1) Does the community want to see such a change?
Yes; and you are indentifying scope as you go. Gabriel has also identified
some scope earlier; as have I. I suspect we are all aware of little bits of
the work.
For thinks like Query; we know we are going to
Jody Garnett wrote:
But do you not need the creation of a FeatureBuilder (rather than just a
SimpleFeatureBuilder?) in order to meet your needs.
Yes. We have the old one which I ported from community-schemas on the
2.4 branch. The reason I want to change SimpleFeatureTypeBuilder is that
I
Changing the Query API will affect every DataStore. If this is done by
expanding Query and DefaultQuery as you indicated, it should be possible
to leave the existing DataStore implementations untouched.
Can we modify the Query interface in a way we don;t have to modify all
datastores?
Justin Deoliveira wrote:
Changing the Query API will affect every DataStore. If this is done by
expanding Query and DefaultQuery as you indicated, it should be possible
to leave the existing DataStore implementations untouched.
Can we modify the Query interface in a way we don;t have to
On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Justin Deoliveira wrote:
Changing the Query API will affect every DataStore. If this is done by
expanding Query and DefaultQuery as you indicated, it should be possible to
leave the existing DataStore
Jody Garnett wrote:
The reason I want to change SimpleFeatureTypeBuilder is that I want to
change GML2EncoderUtils to add support for complex feature encoding.
To clarify; I do not want you to change SimpleFeatureTypeBuilder - I want us
to create a new one. SimpleFeatureTypeBuilder is only
We keep on going in circles. I want to fix SimpleFeatureTypeBuilder so I
can fix GML2EncoderUtils so I can use it to encode complex features. I have
no interest in SimpleFeatureTypeBuilder other than not breaking it.
Hi Ben; that is what I am not understanding - how is
21 matches
Mail list logo
