Ben Caradoc-Davies wrote:
> features. The intent is to get rid of the nasty adapters used in
> community-schemas-ds to smuggle ISO features in the old gt2 feature
> model, and use the clean opengis Feature API (GeoAPI). This requires
> consistent use of the opengis API throughout.
Sounds great :
Hi Ben,
So yes, at the moment there is no handling of any complex features so
the bindings all assume the flat feature model.
That being said, the parser itself is very flexible and allows you to
plug and override bindings as necessary. A possible path forward would
be this:
Create new bindin
Rob Atkinson ha scritto:
> GML3 handles decoding and encoding, so for community-schema-ds we need
> the encoder bindings to be sensible, right?
>
> so does this mean that GML3 can only read simple features, and encode
> simple features? Is this an arbitrary limitation (for some reason a
> delibera
Ben Caradoc-Davies ha scritto:
> As you are no doubt aware, I have been attempting to port GeoTools 2.4.x
> community-schemas-ds to trunk. The purpose of this port is to make use
> of GeoAPI 2.2 and its implementations in gt-main, so as to better
> support complex features. The intent is to get
GML3 handles decoding and encoding, so for community-schema-ds we need
the encoder bindings to be sensible, right?
so does this mean that GML3 can only read simple features, and encode
simple features? Is this an arbitrary limitation (for some reason a
deliberate choice of bindings based on famili
As you are no doubt aware, I have been attempting to port GeoTools 2.4.x
community-schemas-ds to trunk. The purpose of this port is to make use
of GeoAPI 2.2 and its implementations in gt-main, so as to better
support complex features. The intent is to get rid of the nasty adapters
used in comm
