[Geoserver-devel] Getting nuts trying to encode custom made complex features

Hi,
as I said some time ago I'm trying to implement this complex features
data source
which is talking to some simple feature data store, doing some analysis on the
data received, and then building a complex feature out of it which
basically contains
a set of summary attributes in the main feature (the one that are the
results of the
calculations) and the list of simple features at the end

Now, the complex feature is not really that complex, it's a main
feature with plain
jane attribute and at the end it has an attribute which is a list of
other sub-features.

The schema looks a bit like:

<element name="MyComplexFeature" substitutionGroup="gml:_Feature"
type="xyz:MyComplexFeatureType">
    </element>
    <complexType name="MyComplexFeatureType">
        <complexContent>
            <extension base="gml:AbstractFeatureType">
                <sequence>
                    <element name="a" type="xsd:string"/>
                    <element name="b" type="xsd:string"/>
                    <element name="c" type="xsd:int"/>
                    <element name="d" type="xsd:long"/>
                    <element name="features"
type="xyz:MySubFeaturePropertyType" minOccurs="0"/>
                </sequence>
            </extension>
        </complexContent>
    </complexType>
    <complexType name="MySubFeaturePropertyType">
        <sequence minOccurs="0" maxOccurs="unbounded">
            <element ref="xyz:MySubFeature"/>
        </sequence>
        <attributeGroup ref="gml:AssociationAttributeGroup"/>
    </complexType>
    <complexType name="MySubFeatureType">
    <complexContent>
      <extension base="gml:AbstractFeatureType">
        <sequence>
          <element maxOccurs="1" minOccurs="0" name="e"
nillable="true" type="xsd:string"/>
          <element maxOccurs="1" minOccurs="0" name="f"
nillable="true" type="xsd:string"/>
          <element maxOccurs="1" minOccurs="0" name="e"
nillable="true" type="xsd:string"/>
         ...
       </sequence>
      </extension>

    </complexContent>
  </complexType>

  <element name="MySubFeature" substitutionGroup="gml:_Feature"
type="xyz:MySubFeatureType"/>

SubFeature is really a simple feature generated by a plain jane DataStore.

I've tried to build the feature type in code to mimic the structure of
the schema:

TypeBuilder builder = new TypeBuilder(new FeatureTypeFactoryImpl());
        builder.setNamespaceURI("http://www.xyz.com");

        // build the only one complex attribute
        builder.setMinOccurs(0);
        builder.setMaxOccurs(Integer.MAX_VALUE);
        builder.addAttribute("MySubFeature", finishedFeature);
        builder.setName("MySubFeaturePropertyType");
        ComplexType featuresType = builder.complex();

        attribute(builder, "a", String.class);
        attribute(builder, "b", String.class);
       ...
        builder.addAttribute("features", featuresType);
        builder.setName("MyComplexFeature");
        FeatureType schema = builder.feature();

where attribute is a helper method to avoid having to type everything twice:

private void attribute(TypeBuilder builder, String name, Class<?> binding) {
        TypeBuilder attBuilder = new TypeBuilder(builder.getTypeFactory());
        attBuilder.setNamespaceURI(builder.getNamespaceURI());
        builder.addAttribute(name,
attBuilder.name(name).bind(binding).attribute());
    }

and then tried to build a feature out of it:

        FeatureType schema = // see above code for building the feature type
        SimpleFeatureCollection features = ...;
        // do the math and build a/b/c and so on

        AttributeBuilder builder = new AttributeBuilder(new
LenientFeatureFactoryImpl());
        // build the attribute representing the list of sub-features
        builder.setType((AttributeType)
schema.getDescriptor("features").getType());
        builder.setType(schema);
        builder.setNamespaceURI(schema.getName().getNamespaceURI());
        Attribute featuresAttribute =
builder.createComplexAttribute(features, null, (AttributeDescriptor)
schema.getDescriptor("features"), "features");
        // build the top level complex feature
        builder.setType(schema);
        builder.setNamespaceURI(schema.getName().getNamespaceURI());
        builder.add(a, "a");
        builder.add(b, "b");
        builder.add(featuresAttribute.getValue(), "features");
        Feature result = (Feature) builder.build(id);

and then wrapping the feature in a collection (which I had to make
since there is no complex feature collection implementation around).
The schema has been placed in the feature type directory as schema.xsd
so that both DescribeFeatureType and encoding pick it up
automatically without having to publish it publically (something I
cannot do due to network layout issues and privacy requirements).

Now, as long as I leave the "features" attribute out of the gml3 gets
encoded nicely even if I'm not
using any simple feature. Nice, something is working.
But the moment I add it boom, ComplexSupportXSAnyTypeBinding tries to
encode the thing and breaks
trying to get the "simpleContent" property out of the collection.

I guess there is some mismatch between the xsd, the feature type built
in memory and the
actual feature data, but for the life of me I cannot see where it is,
it seems to me I've mirrored
in code the schema structure...

Does anybody have a clue? I can also try to write a stand alone
example, but of course that will mean
writing it from scratch so I'm first going to check if anyone sees
something obvious that I'm missing.

Cheers
Andrea

PS: I propose to rename ComplexFeatures to WorldOfPainFeatures...
would anyone disagree?
      Every time I get near to them it's a week of pain and suffering
to get the most basic things done...

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

On Wed, Mar 16, 2011 at 6:52 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

and then tried to build a feature out of it:

   FeatureType schema = // see above code for building the feature type
   SimpleFeatureCollection features = \.\.\.;

Ah, made a typo here, the feature collection is turned into a
List<SimpleFeature>,
which is the used as the value of the complex attribute

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

On 17/03/11 01:52, Andrea Aime wrote:

But the moment I add it boom, ComplexSupportXSAnyTypeBinding tries to
encode the thing and breaks
trying to get the "simpleContent" property out of the collection.

Do you have a stack trace?

simpleContent is a workaround for GeoAPI not supporting complex type with simple content. What is the XSD type of the property being encoded when encoding fails?

PS: I propose to rename ComplexFeatures to WorldOfPainFeatures...
would anyone disagree?
       Every time I get near to them it's a week of pain and suffering
to get the most basic things done...

Welcome to my life.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On Thu, Mar 17, 2011 at 9:48 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

On 17/03/11 01:52, Andrea Aime wrote:

But the moment I add it boom, ComplexSupportXSAnyTypeBinding tries to
encode the thing and breaks
trying to get the "simpleContent" property out of the collection.

Do you have a stack trace?

I have better than that now, a small self contained example that anybody can run
if they dare sharing my pain :slight_smile:

The attached project contains all you need to reproduce the problem.
If you are impatient and just want to try it, open it, build it with
maven/eclipse,
and run org.geotools.complex.ComplexGMLBuilder.

For those that do want a little introduction, here we go.

org.geotols.xsd package
----------------------------------------

This contains a modified rip off of a couple of classes stolen from GeoServer,
they are a XSD/Configuration couple that will make the encoder work against
a user provided schema with one other XSD dependency (either wfs or gml).
It's a simplified mock up that can be used without GeoServer, could be
done better
but it's probably enough for the purposes of the exercise.

org.geotools.simple package
----------------------------------------

This contains a few approaches to write out a feature collection starting from
simple features (I needed this to get my feet wet with the above
config classes).

SimpleGMLBuilder uses a straight encoder + GML3 configuration, work but will
fail to encode prefixes and namespace locations properly as the encoder has
to make up the target schema on the fly.

GMLFacadeBuilder uses Jody's GML facade class, works better but the encoder
still complains the schema has not been provided. Jody, that class can
be improved
by creating a custom XSD/Configuration that uses the schema building code you
already have in GML to build the target schema so that we don't have
further complaints.

SimpleApplSchemaGMLBuilder uses AppSchemaConfiguration/XSD to encode
everything with a targe schema known to the encoder, this one works fine and
provides me no errors (the target schema is in src/main/resources).

org.geotols.complex
-----------------------------

This one tries (and fails) to encode complex features by just taking a
list of bugsites,
create a main feature, SummaryFeature, that has a count of the number
of bugsites
as an attribute, and a "features" attribute that should contain the
lits of bugsites.

The package contains a few helper classes:
- AbstractComplexFeatureCollection (aka AbstractFeatureCollection without simple
  feature assumption) and ListComplexFeatureCollection (aka
ListFeatureCollection
  without simple feature assumption). I needed these to stick the
features into a collection
- TypeBuilder, Types, AttributeBuilder that come from app-schema, where they are
  used to build some testing types and features. Pretty painful to use
I may add,
  imho there should be a better way :wink:
- ComplexGMLBuilder that tries to build first a feature type and the a
feature mimicking
  the complex.xsd schema (see src/main/resources) and then tries to encode it...
  and that's were things are not working.
  The way features are built gives me heaaches, but I could not figure
out a better
  way (suggestions welcomed)

Soo... welcome to _my_ world. Now, anybody has a bright idea on how to make this
thing work?? :slight_smile:

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

(attachments)

complex-example.zip (36.3 KB)

On Thu, Mar 17, 2011 at 5:21 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

I have better than that now, a small self contained example that anybody can run
if they dare sharing my pain :slight_smile:

I eventually managed to solve the issue myself, though I went down a road that
seems to work more by accident than by design and it's a path that does not
seem to be taken by the app-schema store (which is what I was trying to mimick).

What I did eventually was to look into the bindings and found
FeatureArrayPropertyTypeBinding
that seemed to fit the bill, so I changed the featues property from a
complex one back
to a simple one (ugh?) that is bound to feature collection, then
changed the schema
to use a generic element of type gml:FeatureArrayPropertyType, with no
link whatsoever
to its actual contents, set the feature collection into the features
property as is,
and voilà, it worked.

However it seems wrong from various points of view:
- the features property is not a simple one, that baby is a complex,
it's a property that
  contains a list of elements, not a primitive value
- the schema is broken, it's not enforcing that the contents of the
features element has
  to be made of bugsites

I'll have to go down this road as I'm already way past my deadlines
but I'd still be grateful
if someone can provide a solution that does not require summing a set of wrongs
to just get a valid result...

I've attached the files modified compared to yesterday's zip

Cheers
An drea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

(attachments)

complex.xsd (1.64 KB)
ComplexGMLBuilder.java (4.41 KB)

Glad you found a working setup. I did spend some time over the weekend working with the extension you sent out but unfortunately did not get very far. I experimented with changing the structure of the schema and the built complex feature to try and find a combination that worked but no luck. There are some inherent assumptions that the encoding chain makes with regard to complex features that obviously are not being met. Unfortunately more time is needed to debug and figure out what they are.

On Fri, Mar 18, 2011 at 2:16 AM, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Thu, Mar 17, 2011 at 5:21 PM, Andrea Aime

<andrea.aime@anonymised.com> wrote:

I have better than that now, a small self contained example that anybody can run
if they dare sharing my pain :slight_smile:

I eventually managed to solve the issue myself, though I went down a road that
seems to work more by accident than by design and it’s a path that does not
seem to be taken by the app-schema store (which is what I was trying to mimick).

What I did eventually was to look into the bindings and found
FeatureArrayPropertyTypeBinding
that seemed to fit the bill, so I changed the featues property from a
complex one back
to a simple one (ugh?) that is bound to feature collection, then
changed the schema
to use a generic element of type gml:FeatureArrayPropertyType, with no
link whatsoever
to its actual contents, set the feature collection into the features
property as is,
and voilà, it worked.

However it seems wrong from various points of view:

  • the features property is not a simple one, that baby is a complex,
    it’s a property that
    contains a list of elements, not a primitive value
  • the schema is broken, it’s not enforcing that the contents of the
    features element has
    to be made of bugsites

I’ll have to go down this road as I’m already way past my deadlines
but I’d still be grateful
if someone can provide a solution that does not require summing a set of wrongs
to just get a valid result…

I’ve attached the files modified compared to yesterday’s zip

Cheers
An drea

Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf



Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.

On Mon, Mar 21, 2011 at 2:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Glad you found a working setup. I did spend some time over the weekend
working with the extension you sent out but unfortunately did not get very
far. I experimented with changing the structure of the schema and the built
complex feature to try and find a combination that worked but no luck. There
are some inherent assumptions that the encoding chain makes with regard to
complex features that obviously are not being met. Unfortunately more time
is needed to debug and figure out what they are.

Yep, that is the same conclusion I reached: complex feature encoding works only
in the very specific setup generated by the app-schema store.
I did look hard in that code trying to find the secret sauce to
mikick, but could not get it
to work in any way...

The overall impression I have is that the complex feature support is really the
app-schema store, either use it, or you don't get a usable way to build, encode
and manipulate complex features.

Unfortunately the assumption that a complex feature is just a joined,
renamed and reorganized set of simple feature did not reflect what I
needed so I could
not go down that road...

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

On Mon, 2011-03-21 at 15:03 +0100, Andrea Aime wrote:

On Mon, Mar 21, 2011 at 2:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
> Glad you found a working setup. I did spend some time over the weekend
> working with the extension you sent out but unfortunately did not get very
> far. I experimented with changing the structure of the schema and the built
> complex feature to try and find a combination that worked but no luck. There
> are some inherent assumptions that the encoding chain makes with regard to
> complex features that obviously are not being met. Unfortunately more time
> is needed to debug and figure out what they are.

Yep, that is the same conclusion I reached: complex feature encoding works only
in the very specific setup generated by the app-schema store.
I did look hard in that code trying to find the secret sauce to
mikick, but could not get it
to work in any way...

The overall impression I have is that the complex feature support is really the
app-schema store, either use it, or you don't get a usable way to build, encode
and manipulate complex features.

That shouldn't be the case encoding wise, though I can realize how
difficult it may be to keep it agnostic when the app-schema folks need
to get their specific use cases working.
Suggestion: submit a couple unit tests that set up a data structure as
you need. And ask the app-schema folks if that structure makes sense GML
"recommendations" wise (like I'm not sure how strict the property/Object
relationship is enforced, etc).

2c./
Gabriel

Unfortunately the assumption that a complex feature is just a joined,
renamed and reorganized set of simple feature did not reflect what I
needed so I could
not go down that road...

Cheers
Andrea

--
Gabriel Roldan
groldan@anonymised.com
Expert service straight from the developers

On Mon, Mar 21, 2011 at 3:49 PM, Gabriel Roldán <groldan@anonymised.com> wrote:

On Mon, 2011-03-21 at 15:03 +0100, Andrea Aime wrote:

On Mon, Mar 21, 2011 at 2:55 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:
> Glad you found a working setup. I did spend some time over the weekend
> working with the extension you sent out but unfortunately did not get very
> far. I experimented with changing the structure of the schema and the built
> complex feature to try and find a combination that worked but no luck. There
> are some inherent assumptions that the encoding chain makes with regard to
> complex features that obviously are not being met. Unfortunately more time
> is needed to debug and figure out what they are.

Yep, that is the same conclusion I reached: complex feature encoding works only
in the very specific setup generated by the app-schema store.
I did look hard in that code trying to find the secret sauce to
mikick, but could not get it
to work in any way...

The overall impression I have is that the complex feature support is really the
app-schema store, either use it, or you don't get a usable way to build, encode
and manipulate complex features.

That shouldn't be the case encoding wise, though I can realize how
difficult it may be to keep it agnostic when the app-schema folks need
to get their specific use cases working.
Suggestion: submit a couple unit tests that set up a data structure as
you need. And ask the app-schema folks if that structure makes sense GML
"recommendations" wise (like I'm not sure how strict the property/Object
relationship is enforced, etc).

That's why I sent a fully self contained example last week. It's not in the
form of a test but it's close enough

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Andrea,

I don't have any good solutions for you, just a couple of observations:

(1) app-schema never deals with feature arrays because delivers a stream of features that the existing encoder FeatureCollection infrastructure deals with. I'm suspect that any attempt to use feature arrays with app-schema may have problems because of the need to remove duplicate ids and convert to xlink:href. I have never seen app-schema used with arrays other than the top level, and we always deploy GeoServer to use featureMember not featureMembers.

(2) I see you used ApplicationSchemaXSD/ApplicationSchemaConfiguration; these are not from app-schema. We use custom AppSchemaXSD/AppSchemaConfiguration to hook into gt-app-schema-resolver and have better resource path handling behaviour for cross-package schema resolution. I don't think this makes any difference in your case.

Anyway, I feel that the ability to encode complex features is hanging by a thread, and it took us years to get to this point! It is very complicated, and nailed into place by a gigantic unit test infrastructure. I am not surprised that you have suffered getting this example to work.

You and Justin should buy each other a drink. You both need and deserve it.

Kind regards,
Ben.

On 18/03/11 16:16, Andrea Aime wrote:

On Thu, Mar 17, 2011 at 5:21 PM, Andrea Aime
<andrea.aime@anonymised.com> wrote:

I have better than that now, a small self contained example that anybody can run
if they dare sharing my pain :slight_smile:

I eventually managed to solve the issue myself, though I went down a road that
seems to work more by accident than by design and it's a path that does not
seem to be taken by the app-schema store (which is what I was trying to mimick).

What I did eventually was to look into the bindings and found
FeatureArrayPropertyTypeBinding
that seemed to fit the bill, so I changed the featues property from a
complex one back
to a simple one (ugh?) that is bound to feature collection, then
changed the schema
to use a generic element of type gml:FeatureArrayPropertyType, with no
link whatsoever
to its actual contents, set the feature collection into the features
property as is,
and voilà, it worked.

However it seems wrong from various points of view:
- the features property is not a simple one, that baby is a complex,
it's a property that
   contains a list of elements, not a primitive value
- the schema is broken, it's not enforcing that the contents of the
features element has
   to be made of bugsites

I'll have to go down this road as I'm already way past my deadlines
but I'd still be grateful
if someone can provide a solution that does not require summing a set of wrongs
to just get a valid result...

I've attached the files modified compared to yesterday's zip

Cheers
An drea

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre

On Thu, Mar 31, 2011 at 8:29 AM, Ben Caradoc-Davies
<Ben.Caradoc-Davies@anonymised.com> wrote:

Andrea,

I don't have any good solutions for you, just a couple of observations:

(1) app-schema never deals with feature arrays because delivers a stream of
features that the existing encoder FeatureCollection infrastructure deals
with. I'm suspect that any attempt to use feature arrays with app-schema may
have problems because of the need to remove duplicate ids and convert to
xlink:href. I have never seen app-schema used with arrays other than the top
level, and we always deploy GeoServer to use featureMember not
featureMembers.

The funny thing is, after days of banging my head on the desk, feature array
was the only thing that worked.

I asked how to set it up like app-schema (whatever that is, I could
not figure it out),
but got no answer.

(2) I see you used ApplicationSchemaXSD/ApplicationSchemaConfiguration;
these are not from app-schema. We use custom
AppSchemaXSD/AppSchemaConfiguration to hook into gt-app-schema-resolver and
have better resource path handling behaviour for cross-package schema
resolution. I don't think this makes any difference in your case.

Anyway, I feel that the ability to encode complex features is hanging by a
thread, and it took us years to get to this point! It is very complicated,
and nailed into place by a gigantic unit test infrastructure. I am not
surprised that you have suffered getting this example to work.

Yeah, that's the problem, app-schema was built without laying down the
foundations: there are no decent type builders, feature builders, the various
collection wrappers to retype, reproject, gml encoding works on the specific
case generated by app-schema but there is nothing telling what structure
might that be, and so on.

My conclusion working with complex features is that if app-schema store
fits the bill and the target schema follows the same rules as gml there is a
chance to put togheter somethin , otherwise one should
really assume complex features are not really there and plan accordingly.

Cheers
Andrea

--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy

phone: +39 0584 962313
fax: +39 0584 962313
mob: +39 333 8128928

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Andrea,

I agree with your conclusion. The existing GML 3 encoder, configuration, and bindings target GML application schemas. This is the only type of complex feature encoding that has any test coverage, and thus the only type that can be assumed to work. Nonetheless, I think your schema was a GML application schema, and I was surprised by the amount of pain you had. I guess we have been sheltered by our working DataAccess, and have not experienced the pain of those trying to build complex features by hand via a programmatic API.

I can see the value of builders and retrofitting these onto the existing code base, but the cost of this work is yet to be estimated and is not included in any project plan.

The early gt-sample-data-access tests (which do not depend on gt-app-schema) and their corresponding GeoServer tests still run.

Kind regards,
Ben.

On 31/03/11 14:56, Andrea Aime wrote:

My conclusion working with complex features is that if app-schema store
fits the bill and the target schema follows the same rules as gml there is a
chance to put togheter somethin , otherwise one should
really assume complex features are not really there and plan accordingly.

--
Ben Caradoc-Davies <Ben.Caradoc-Davies@anonymised.com>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre