It is more that iterator order is not defined unless you are a list. So
while we could use Set (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 various
Andrea Aime wrote:
> Set getProperties gives up namespace support,
[...]
> List would give the best of both worlds it seems?
These are all interfaces. I thought iteration order was specified by the
implementation? Collection is iterable and allows implementers to
choose. See, for example, the us
Andrea Aime wrote:
> jgarnett++
I think you mean ++jgarnett, because you want to increment before use. :-)
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
--
List 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"
example
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
Gabriel Roldán wrote:
> On Thursday 26 February 2009 02:04:15 Jody Garnett wrote:
> > On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
> >
> > wrote:
> > > Justin Deoliveira wrote:
> > >> Changing the Query API will affect every DataStore. If this is done by
> > >>
> > >>> expanding Quer
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 g
On Thursday 26 February 2009 02:04:15 Jody Garnett wrote:
> On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
>
> 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 shoul
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 sl
Jody Garnett wrote:
>
>
> On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
> 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 shou
>
> 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
SimpleFeatureTypeB
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 i
On Thu, Feb 26, 2009 at 2:54 PM, Ben Caradoc-Davies
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 implementations untouc
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 t
>
> 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?
> Yes. We have the old one which I ported from community-schemas on the 2.4
> branch.
Okay that is cool.
> 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 Simp
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 w
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 h
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 singl
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 experie
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
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 simp
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 han
23 matches
Mail list logo
