Re: [Geotools-devel] Namespace support
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 implementations expect the objects to be compariable etc...) So my money is on List and we can document that duplicate names are a mistake. Jody On Tue, Mar 3, 2009 at 1:12 PM, Ben Caradoc-Davies wrote: > 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 use of Collection in GeoAPI. > > -- > Ben Caradoc-Davies > Software Engineer, CSIRO Exploration and Mining > Australian Resources Research Centre > 26 Dick Perry Ave, Kensington WA 6151, Australia > > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 use of Collection in GeoAPI. -- Ben Caradoc-Davies Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 to appear in the real world. So we have three things on the table here: 1. Query needs to be extended to have List - that is cool lets do it 2. SimpleFeatureTypeBuilder is not suitable; Ben can feel free to start making his own builder - or to just use the factory methods directly if that is easier for him to start out - I would like to put off defining a builder until we have some experience? and then just use the refactor "inline method" to help define the builder. - I expect the FeatureBuilder will not provide as much help in defining attributes; since it will more strictly expect add( Name, AttributeDescriptor ) 3. Encoding / (and parsing if we expect Transaction to work) - my preference would be to go with the binding framework and use that as an excuse to increase performance. Although this is a low priority since we need to focus on capability first. Andrea can we make the decision what system to use based on if SimpleFeatureType is used? That way we can avoid taking the performance hit for the vast majority of cases - and buy more time to work on performance. On Sat, Feb 28, 2009 at 9:32 AM, Rob Atkinson wrote: > 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 AM, Andrea Aime wrote: > > 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 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? What I mean is is keep String[] getPropertyNames() in > >> tact, > >> > >> but add a Name[] getProperties() or something. Internally we can > store > >> > >> the qualified names. > >> > > > >> > > Yes, exactly. Jody suggested extending the API with a List, but I > was > >> > > thinking: > >> > > Collection getProperties() > >> > > >> > I think we still need a List in order to allow people to specify the > >> order > >> > of the resulting properties? > >> which by the way does not make much sense after all. I mean, in the > >> feature model there's no such a thing as the order of the properties. We > >> always used to do that with simple features, somewhat mirroring a flat > >> table query in a database, but I guess the question is do we want to > >> keep forcing that behaviour or would Query.getProperties():Set > >> make more sense? > > > > I see an issue here: > > String[] getPropertyNames gives up namespace support (which Ben says is > > part of the simple feature spec) but gives you control over the order > > of the property as returned by the query. > > > > Set getProperties gives up namespace support, but won't allow > > control over the order of the returned properties. I know that xml > > wise we cannot break the feature type specified order, but I'm pretty > > use there is code that would break if we don't allow order control > > (I for one never use getAttribute(String) if possible to avoid the > > extra hashmap lookup). > > > > List would give the best of both worlds it seems? > > > > Cheers > > Andrea > > > > > -- > > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > > -Strategies to boost innovation and cut costs with open source > participation > > -Receive a $600 discount off the registration fee with the source code: > SFAD > > http://p.sf.net/sfu/XcvMzF8H > > ___ > > Geotools-devel mailing list > > Geotools-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, > CA > -OSBC tackles the biggest issue in open source: Open Sourcing the > Enterprise > -Strategies to boost innovation and cut costs with open source > participation > -Receive a $600 discount off the registration fee with the source code: > SFAD > http://p.sf.net/sfu/XcvMzF8H >
Re: [Geotools-devel] Namespace support
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 AM, Andrea Aime wrote: > 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 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? What I mean is is keep String[] getPropertyNames() in >> tact, >> > >> but add a Name[] getProperties() or something. Internally we can store >> > >> the qualified names. >> > > >> > > Yes, exactly. Jody suggested extending the API with a List, but I was >> > > thinking: >> > > Collection getProperties() >> > >> > I think we still need a List in order to allow people to specify the >> order >> > of the resulting properties? >> which by the way does not make much sense after all. I mean, in the >> feature model there's no such a thing as the order of the properties. We >> always used to do that with simple features, somewhat mirroring a flat >> table query in a database, but I guess the question is do we want to >> keep forcing that behaviour or would Query.getProperties():Set >> make more sense? > > I see an issue here: > String[] getPropertyNames gives up namespace support (which Ben says is > part of the simple feature spec) but gives you control over the order > of the property as returned by the query. > > Set getProperties gives up namespace support, but won't allow > control over the order of the returned properties. I know that xml > wise we cannot break the feature type specified order, but I'm pretty > use there is code that would break if we don't allow order control > (I for one never use getAttribute(String) if possible to avoid the > extra hashmap lookup). > > List would give the best of both worlds it seems? > > Cheers > Andrea > > -- > Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA > -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise > -Strategies to boost innovation and cut costs with open source participation > -Receive a $600 discount off the registration fee with the source code: SFAD > http://p.sf.net/sfu/XcvMzF8H > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 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? What I mean is is keep String[] getPropertyNames() in > tact, > > >> but add a Name[] getProperties() or something. Internally we can store > > >> the qualified names. > > > > > > Yes, exactly. Jody suggested extending the API with a List, but I was > > > thinking: > > > Collection getProperties() > > > > I think we still need a List in order to allow people to specify the > order > > of the resulting properties? > which by the way does not make much sense after all. I mean, in the > feature model there's no such a thing as the order of the properties. We > always used to do that with simple features, somewhat mirroring a flat > table query in a database, but I guess the question is do we want to > keep forcing that behaviour or would Query.getProperties():Set > make more sense? I see an issue here: String[] getPropertyNames gives up namespace support (which Ben says is part of the simple feature spec) but gives you control over the order of the property as returned by the query. Set getProperties gives up namespace support, but won't allow control over the order of the returned properties. I know that xml wise we cannot break the feature type specified order, but I'm pretty use there is code that would break if we don't allow order control (I for one never use getAttribute(String) if possible to avoid the extra hashmap lookup). List would give the best of both worlds it seems? Cheers Andrea -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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
> encoder is 2-4 times slower than the old GML2 one, so I would like to
> avoid it in the "main path", which today is, WFS 1.0/GML2/old style
> simple features.
>
> We'd need to allocate some time to bring the new encoder up to snuff,
> or at least somewhat close, to the old encoder, or else just give
> up and roll out a new custom GML3 encoder that uses a lighter weight
> architecture (and thus, a faster one).
> Justin, thoughts on this direction? I'd like to help but I cannot
> really put my hands on the new encoder in a productive way.
Well I would love to make the encoder faster, and have a few thoughts on
how to do so. I just need the time to try to implement some of them. As
for coming up with a new lighter weight encoder, don't take that task
lightly. A new simpler/faster xml encoder would probably curtail some of
the complex feature efforts too.
>
> Cheers
> Andrea
>
>
>
> --
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 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? What I mean is is keep String[] getPropertyNames() in tact, > >> but add a Name[] getProperties() or something. Internally we can store > >> the qualified names. > > > > Yes, exactly. Jody suggested extending the API with a List, but I was > > thinking: > > Collection getProperties() > > I think we still need a List in order to allow people to specify the order > of the resulting properties? which by the way does not make much sense after all. I mean, in the feature model there's no such a thing as the order of the properties. We always used to do that with simple features, somewhat mirroring a flat table query in a database, but I guess the question is do we want to keep forcing that behaviour or would Query.getProperties():Set make more sense? Gabriel > Jody -- Gabriel Roldan http://www.opengeo.org -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 slower than the old GML2 one, so I would like to
avoid it in the "main path", which today is, WFS 1.0/GML2/old style
simple features.
We'd need to allocate some time to bring the new encoder up to snuff,
or at least somewhat close, to the old encoder, or else just give
up and roll out a new custom GML3 encoder that uses a lighter weight
architecture (and thus, a faster one).
Justin, thoughts on this direction? I'd like to help but I cannot
really put my hands on the new encoder in a productive way.
Cheers
Andrea
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 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? What I mean is is keep String[] > getPropertyNames() in tact, but add a Name[] getProperties() or > something. Internally we can store the qualified names. > > > Yes, exactly. Jody suggested extending the API with a List, but I > was thinking: > Collection getProperties() > > > I think we still need a List in order to allow people to specify the > order of the resulting properties? jgarnett++ Cheers Andrea -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
>
> 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
SimpleFeatureTypeBuilder even on your radar? Is it because GML2EncoderUtils
is using it? If so GML2EncoderUtils is not suitable for your work ...
perhaps we need a breakout IRC session to go over this story.
In short - I understand what you want to do - and I think we need to do
something different mid term (am I to understand that fixing a mistake in
SimpleFeatureTypeBuilder would allow you to work short term?).
I also do not think SimpleFeature and SimpleFeatureTypeBuilder are focused
on the simple feature profile for SQL - they are focused on a much more
specific problem and I was not aware of namespace support being considered
here.
> While making these changes, I discovered the unwritten contract:
>>> SimpleFeatureTypeBuilder discards namespaces, and GML2EncoderUtils
>>> fabricates them. I don't fancy my chances of getting changes to
>>> GML2EncoderUtils accepted if they break SimpleFeatureTypeBuilder.
>>>
>>
>> That may be a mistake; what do you mean by discards namespaces?
>>
>
> SimpleFeatureTypeBuilder.add(String, ...) builds types with properties with
> no namespaces. For example, see in GML3ParserUtils the use of
> SimpleFeatureTypeBuilder.add() with a name obtained from
> XDSElementDeclaration.getName(), that is, the local (unqualified) name of an
> element that has a namespace. Users of SimpleFeatureTypeBuilder.add() thus
> discard namespaces when creating simple types.
We are going to have to talk to Justin about this one; SimpleFeatureType
builder was really focused on enabling the existing code to run while making
room for the new feature model. I really did not expect you to make any use
of it in your work.
Does the SimpleFeatureTypeBuilder allow the use of namespaces? My impression
is it would only be used in defining the type name; and not used in creating
the attributes? The creation of attributes is a bit of a drastic shortcut; I
have often found myself breaking out an attributetypebuilder (or using the
factory directly) and adding the resulting attributetype into the mix.
>
> I am not familiar with GML2EncoderUtils - I would hope that for the rich
>> feature model work we are using the GML bindings?
>>
>
> GeoServer GMLOutputFormat uses WFSConfiguration to encode features, using
> the binding AbstractFeatureTypeBinding, which gets properties using
> GML3EncoderUtils, which is mainly implemented in GML2EncoderUtils. The
> bindings are specified in WFSConfiguration, and bind to GML3.
>
> GML{2,3}EncoderUtils can be persuaded, with minor tweaks, to encode complex
> features (mostly, I am working on it). However, these minor tweaks break
> SimpleFeatureTypeBuilder.
>
> 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.
Okay thanks for the background information (it describes a bit what I was
missing). I think we are going to need to tag team justin in on this one. It
will be a good test of if breakout IRC meetings + change process can
actually replace the use of weekly meetings.
Cheers,
Jody
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 to help assist building
> SimpleFeatureType
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.
>> While making these changes, I discovered the unwritten contract:
>> SimpleFeatureTypeBuilder discards namespaces, and GML2EncoderUtils
>> fabricates them. I don't fancy my chances of getting changes to
>> GML2EncoderUtils accepted if they break SimpleFeatureTypeBuilder.
>
> That may be a mistake; what do you mean by discards namespaces?
SimpleFeatureTypeBuilder.add(String, ...) builds types with properties
with no namespaces. For example, see in GML3ParserUtils the use of
SimpleFeatureTypeBuilder.add() with a name obtained from
XDSElementDeclaration.getName(), that is, the local (unqualified) name
of an element that has a namespace. Users of
SimpleFeatureTypeBuilder.add() thus discard namespaces when creating
simple types.
> I am not familiar with GML2EncoderUtils - I would hope that for the rich
> feature model work we are using the GML bindings?
GeoServer GMLOutputFormat uses WFSConfiguration to encode features,
using the binding AbstractFeatureTypeBinding, which gets properties
using GML3EncoderUtils, which is mainly implemented in GML2EncoderUtils.
The bindings are specified in WFSConfiguration, and bind to GML3.
GML{2,3}EncoderUtils can be persuaded, with minor tweaks, to encode
complex features (mostly, I am working on it). However, these minor
tweaks break SimpleFeatureTypeBuilder.
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.
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 untouched. >>> >> Can we modify the Query interface in a way we don;t have to modify all >> datastores? What I mean is is keep String[] getPropertyNames() in tact, but >> add a Name[] getProperties() or something. Internally we can store the >> qualified names. >> > > Yes, exactly. Jody suggested extending the API with a List, but I was > thinking: > Collection getProperties() I think we still need a List in order to allow people to specify the order of the resulting properties? Jody -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 modify all > datastores? What I mean is is keep String[] getPropertyNames() in tact, > but add a Name[] getProperties() or something. Internally we can store > the qualified names. Yes, exactly. Jody suggested extending the API with a List, but I was thinking: Collection getProperties() The old getPropertyNames() becomes a view of the internal Name list. Regards, -- Ben Caradoc-Davies Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
> > 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? What I mean is is keep String[] getPropertyNames() in tact, but add a Name[] getProperties() or something. Internally we can store the qualified names. > > Kind regards, > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
> 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 SimpleFeatureTypeBuilder - I want us to create a new one. SimpleFeatureTypeBuilder is only to help assist building SimpleFeatureType > While making these changes, I discovered the unwritten contract: > SimpleFeatureTypeBuilder discards namespaces, and GML2EncoderUtils > fabricates them. I don't fancy my chances of getting changes to > GML2EncoderUtils accepted if they break SimpleFeatureTypeBuilder. That may be a mistake; what do you mean by discards namespaces? I am not familiar with GML2EncoderUtils - I would hope that for the rich feature model work we are using the GML bindings? Much of this discussion can move over to the geotools list. > We are here already. :-) Doh! > > > My understanding is the existing datastores (being simple feature based) >> are not going to be that effected by your findings. >> > > 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. It should not be that bad; the String[] of xpath expressions to select can either be strictly taken as XPath expressions; or we can make them a "view" of an origional data structure which is a List (the view being the result of calling name .getLocalName() on each entry in the list). Cheers, Jody -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 want to change GML2EncoderUtils to add support for complex feature encoding. While making these changes, I discovered the unwritten contract: SimpleFeatureTypeBuilder discards namespaces, and GML2EncoderUtils fabricates them. I don't fancy my chances of getting changes to GML2EncoderUtils accepted if they break SimpleFeatureTypeBuilder. > Much of this discussion can move over to the geotools list. We are here already. :-) > My understanding is the existing datastores (being simple feature based) are > not going to be that effected by your findings. 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. Kind regards, -- Ben Caradoc-Davies Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 have to accept a List (and treat the existing string array as a convience method for those working with simple features). SimpleFeatureBuilder and AttributeTypeBuilder (being builders) are intended to be easy to use; that should result in them having plenty of assumptions and maintaining plenty of state in order to help people write minimal code. When I last looked at it - it was very careful to reduce things to a series of Names before construction. But do you not need the creation of a FeatureBuilder (rather than just a SimpleFeatureBuilder?) in order to meet your needs. Much of this discussion can move over to the geotools list. > > (2) How should it be done? (I am looking for suggestions of where to start, > and other areas that will need work.) As you run into each issue / limitation you should send an email; and we should have a quick discussion to see if Justin, Gabriel or myself has thought of a way forward. Changes required in this regard are proceeding as part of the change to the geoapi feature model proposal; if you are identifying new limitations they are still in the scope of this proposal. Also pease be aware that the geoapi feature model is open to correction if you find we have missed a method or detail. (3) Who is able to help? I think everyone is available to help; I am mostly focused on the API requirements (as a geoapi committer I can help refine and clarify methods and javadocs as needed). As module maintainer for the first "rich feature" data store you are going to have to tell us how well we are doing. My understanding is the existing datastores (being simple feature based) are not going to be that effected by your findings. Jody -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 geometry. The OGC Simple Features spec permits multiple namespaces, even for compliance level 0 (SF0). See the example on pages 22-23 of OGC 06-049r1, in which the feature type contains both gml:boundedBy and myns:geomProperty. The limited implementation in GeoTools is already causing problems. User complaints about not being able to have a NAME column in view may be related; GeoTools cannot handle both gml:name and myns:name, and relies on the encoder to hack together a presentable document. As another example, GML3EncodingTest http://svn.osgeo.org/geotools/trunk/modules/extension/xsd/xsd-gml3/src/test/java/org/geotools/gml3/GML3EncodingTest.java parses this document which has namespace-qualified properties: http://svn.osgeo.org/geotools/trunk/modules/extension/xsd/xsd-gml3/src/test/resources/org/geotools/gml3/bindings/test.xml The namespace is discarded from the properties. At encoding time, GML2EncodingUtils responds to requests for namespace-scoped properties by stripping the namespace off the property name and querying the feature for the local name. These complementary kludges allow GeoTools to maintain the pretence of supporting namespaces, but it doesn't. It would be really good if GeoTools and GeoServer could support OGC Simple Features. Even SF0 would be great. At the moment, it is a very limited subset. (Don't get me started on CodeType and MeasureType, which are mandatory for SF0.) >> SimpleFeatureTypeBuilder and its best friend AttributeTypeBuilder are >> most kindly described as bloated and crufty. > > Please clarify where the bloat and the cruft are. Too many methods? They are huge and mutable, making them hard to maintain and test, because of the importance of order in method calls. What is the cyclomatic complexity of using one of these builders with N stateful method calls before you build the type? Got to be something like factorial(N). They are also concrete, so their behaviour cannot be changed (only a FeatureTypeFactory can be injected). SimpleFeatureTypeBuilder: almost 1000 lines, 13 mutable members, 49 public methods. AttributeTypeBuilder: over 600 lines, 20 mutable members, 37 public methods. I understand their purpose: to facilitate building types. To do this, they act as a facade over the complexity of building contained types, descriptors, and CRSs. The consequence of this approach is that all the business logic is concealed in these concrete classes. It is not any simpler, just hidden. It is easier to test, because it is localised, and at least it is reused, but is still rather nasty. > Yup. Name usage has been introduced api wise but nothing in the codebase > uses it. Nothing at all afaik. Thanks for confirming that. I have been approaching this conclusion the hard way. >> (1) Does the community want to see such a change? > Well, if that's what we need to support community schema and complex > features fully, I don't see many alternatives. The main issue I see is > that this change is going to turn the codebased inside-out like a glove. > At GeoServer we are re-starting to work on trunk so a GeoServer 2.0 > release is probably on the radar within 6 months or less. > If this change is going to happen, it's better to have it happen fast, > so that we have some time to recover from the consequences (no chance > it's going to be painless bug-wise). OK, I will keep this in mind and keep changes as small a possible, to preserve stability. Kind regards, -- Ben Caradoc-Davies Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 changing apis over to Name is that much of
> it can be done in an additive way. The only pain is occurs when a class
> returns a list or array of String, and now we need name.
Indeed. In the case of Query:
public interface Query {
String[] getPropertyNames();
>> (2) How should it be done? (I am looking for suggestions of where to
>> start, and other areas that will need work.)
> Query seems to be a logical place to start perhaps. I would say add the
> methods necessary to keep in tact the qualified property names and types
> names passed into the query.
If I can avoid changing Query, I will for now; non-simple DataAccess can
just return all properties. When we change Query, it will require a
proposal, because it is a public API.
>> (3) Who is able to help?
> I am happy to review any patches. As with the geoserver changes, I would
> like to see a patch representing a "spike". Apply it so i can review and
> provide additional feedback.
Thanks! I'll see how far I can get.
--
Ben Caradoc-Davies
Software Engineer, CSIRO Exploration and Mining
Australian Resources Research Centre
26 Dick Perry Ave, Kensington WA 6151, Australia
--
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 remain, and many involve namespace handling. > > I would like your advice, and the advice of the rest of the community, > on how to proceed. > > The namespace problems are rooted in the assumption that every data > source has a single namespace, and that all features and properties > derived from it exist within this namespace. This simplification does > not apply for XML in general. Gabriel hinted at this history when I > implemented GSIP 31 (GeoServer migration to DataAccess API). I am now > beginning to realise the implications. Principally, the consequence is > the wide-ranging use of String to identify properties, with the > assumption that a non-scoped name is sufficient as a unique identifier. > The existence and spreading use of Name makes it clear to me that the > problem is recognised; all that remains is to migrate all APIs to use > Name rather than String to identify properties. I agree, there are are many places where the assumption of a non-qualified name is assumed. While in the simple case this is a reasonable assumption, having the simple case work with Name is not a huge hassle, so probably doable. > > Presumably, the community would rather like it if GeoTools continued to > work with simple features, so I have attempted to make changes in a > backwards-compatible manner. > > One of the things I am trying to do is to make changes that improve the > existing codebase, rather than forking or adding new code to work around > problems. To this end, I have been looking at the existing GML encoding > support. For example, I have found that there is an undocumented > contract between GML2EncodingUtils and the users of > SimpleFeatureTypeBuilder. It appears that SimpleFeatureTypeBuilder > accepts only String property names, so clients discard namespaces, and > no-namespace properties are created, while GML2EncodingUtils gets > properties ignoring their namespaces at encoding time. These two > complementary fudges cancel out for common use cases, but fixing > GML2EncodingUtils to respect namespaces (required to support complex > features) causes many uses of SimpleFeatureTypeBuilder to fail. > > SimpleFeatureTypeBuilder and its best friend AttributeTypeBuilder are > most kindly described as bloated and crufty. > Ha, you should have seen things before they were around. The "bloat" and "cruftyness" are a result of maintaining 10 years of backward compatibility. Unfortunately its hard to keep that pretty. > Even after hacking SimpleFeatureTypeBuilder to be Name-based with > backwards-compatible support for String names, I still run into > problems. For example, the Query API forces all property names to be > Strings, losing namespace support, and breaking unit tests. I do not > think that this can be fixed without breaking backwards compatibility of > the Query API. > > It is a big mess. > > 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 changing apis over to Name is that much of it can be done in an additive way. The only pain is occurs when a class returns a list or array of String, and now we need name. > (2) How should it be done? (I am looking for suggestions of where to > start, and other areas that will need work.) Query seems to be a logical place to start perhaps. I would say add the methods necessary to keep in tact the qualified property names and types names passed into the query. > > (3) Who is able to help? I am happy to review any patches. As with the geoserver changes, I would like to see a patch representing a "spike". Apply it so i can review and provide additional feedback. > > Kind regards, > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Namespace support
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 simple means no namespace, no associations, no multi valued attributes, and one single geometry. In GeoTools right now it means no namespaces, no associatinos, no multi valued attributes, but we support multiple geometries. > SimpleFeatureTypeBuilder and its best friend AttributeTypeBuilder are > most kindly described as bloated and crufty. Please clarify where the bloat and the cruft are. Too many methods? > Even after hacking SimpleFeatureTypeBuilder to be Name-based with > backwards-compatible support for String names, I still run into > problems. For example, the Query API forces all property names to be > Strings, losing namespace support, and breaking unit tests. I do not > think that this can be fixed without breaking backwards compatibility of > the Query API. > > It is a big mess. Yup. Name usage has been introduced api wise but nothing in the codebase uses it. Nothing at all afaik. > 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? Well, if that's what we need to support community schema and complex features fully, I don't see many alternatives. The main issue I see is that this change is going to turn the codebased inside-out like a glove. At GeoServer we are re-starting to work on trunk so a GeoServer 2.0 release is probably on the radar within 6 months or less. If this change is going to happen, it's better to have it happen fast, so that we have some time to recover from the consequences (no chance it's going to be painless bug-wise). > (2) How should it be done? (I am looking for suggestions of where to > start, and other areas that will need work.) I don't have a perception of specific areas that need more work than others. A change like this is going to affect the whole codebase... > (3) Who is able to help? Still working on the filter cleanup, something I would like to get done by Geotools 2.6. That basically absorbs all of my spare time already. Work wise I think we made it clear that OpenGeo would have provided support for this work in terms or review, but no actual coding? Here you're asking us to expand our commitment to this work. Cheers Andrea -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Namespace support
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 handling. I would like your advice, and the advice of the rest of the community, on how to proceed. The namespace problems are rooted in the assumption that every data source has a single namespace, and that all features and properties derived from it exist within this namespace. This simplification does not apply for XML in general. Gabriel hinted at this history when I implemented GSIP 31 (GeoServer migration to DataAccess API). I am now beginning to realise the implications. Principally, the consequence is the wide-ranging use of String to identify properties, with the assumption that a non-scoped name is sufficient as a unique identifier. The existence and spreading use of Name makes it clear to me that the problem is recognised; all that remains is to migrate all APIs to use Name rather than String to identify properties. Presumably, the community would rather like it if GeoTools continued to work with simple features, so I have attempted to make changes in a backwards-compatible manner. One of the things I am trying to do is to make changes that improve the existing codebase, rather than forking or adding new code to work around problems. To this end, I have been looking at the existing GML encoding support. For example, I have found that there is an undocumented contract between GML2EncodingUtils and the users of SimpleFeatureTypeBuilder. It appears that SimpleFeatureTypeBuilder accepts only String property names, so clients discard namespaces, and no-namespace properties are created, while GML2EncodingUtils gets properties ignoring their namespaces at encoding time. These two complementary fudges cancel out for common use cases, but fixing GML2EncodingUtils to respect namespaces (required to support complex features) causes many uses of SimpleFeatureTypeBuilder to fail. SimpleFeatureTypeBuilder and its best friend AttributeTypeBuilder are most kindly described as bloated and crufty. Even after hacking SimpleFeatureTypeBuilder to be Name-based with backwards-compatible support for String names, I still run into problems. For example, the Query API forces all property names to be Strings, losing namespace support, and breaking unit tests. I do not think that this can be fixed without breaking backwards compatibility of the Query API. It is a big mess. 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? (2) How should it be done? (I am looking for suggestions of where to start, and other areas that will need work.) (3) Who is able to help? Kind regards, -- Ben Caradoc-Davies Software Engineer, CSIRO Exploration and Mining Australian Resources Research Centre 26 Dick Perry Ave, Kensington WA 6151, Australia -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
