[Geoserver-devel] GML 3.2 bindings

GeoServer GeoServer Developer
1

Hi Justin,

I did an experiment and hacked xsd-gml3 to use a gml3.2 test case, and
it looks like the bindings for gml 3.1.1 are basically re-usable for
gml3.2 support. I know we'll need a new binding (gml:identifier,
basically a gml:name)

it seems that its the tests which are most heavily bound to gml3.1.1 flavour

I'd like your advice as how best to proceed...

do we create a gml3-common - make gml3 extend it and have a gml3_2
extend it. Most of the tests would be in the gml3-common, with the
config set ups and mock data in the specific flavours?

I suppose I could just clone gml3 to gml3_2 and we can refactor later
- but I hate creating such an obvious mess of redundant code. Maybe
GML3.1.1 will die on the vine and it wont be such a big deal.

Or do you have a better idea?

Rob

2

Hi Rob,

Do we have a list of types between 3.1.1 and 3.2 which are different? Instead of creating a new module i think it might be best if we kept the new 3.2 binding in the same module, perhaps just a different package. W e can then create a new GMLConfiguration class for the new bindings. I think will suffice with a minimum amount of "clutter".

So the question is how do we proceed with implementing the new bindings. You said alot of the 3.1 bindings can be reused, which is great. Are there any that can't be reused?

-Justin

Rob Atkinson wrote:

Hi Justin,

I did an experiment and hacked xsd-gml3 to use a gml3.2 test case, and
it looks like the bindings for gml 3.1.1 are basically re-usable for
gml3.2 support. I know we'll need a new binding (gml:identifier,
basically a gml:name)

it seems that its the tests which are most heavily bound to gml3.1.1 flavour

I'd like your advice as how best to proceed...

do we create a gml3-common - make gml3 extend it and have a gml3_2
extend it. Most of the tests would be in the gml3-common, with the
config set ups and mock data in the specific flavours?

I suppose I could just clone gml3 to gml3_2 and we can refactor later
- but I hate creating such an obvious mess of redundant code. Maybe
GML3.1.1 will die on the vine and it wont be such a big deal.

Or do you have a better idea?

Rob

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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.

3

There is a list of changes at doc OGC 07-061

first, the theory...

"Note that since the target is backwards compatibility of the
instances and not the application schemas, outdated types (and
abstract elements) have been removed and not deprecated whenever
possible."

Moist changes seem to be deprecations and removal of previous
deprecations. There are a couple of changes, but I suspect they are
largely in stuff not implemented yet anyway:

A few highlights:

The default styling schema components have been made informative.

The "_" (underscore) in element names to indicate abstractness has
been replaced by "Abstract" as used in type names.

gml:EnvelopeWithTimePeriodType has been changed to match
gml:EnvelopeType. The two "timePosition"s have been replaced by
"beginPosition" and "endPosition".

gml:_MetaData and gml:metaDataProperty have been deprecated and have
been replaced by an abstract property type with an empty sequence plus
the gml:OwnershipAttributeGroup

All "*Name" elements in the coordinate reference system schema
components have been replaced by gml:name and as a result use
gml:CodeType as their type. The type gml:SimpleNameType has been
deleted.

gml:Envelope is not a geometry and the schema and document have been
updated accordingly.
• gml:CircleByCenterPointType should have been derived from
ArcByCenterPointType by restriction (removing the startAngle and
endAngle properties) rather than by vacuous extension. This has been
corrected.

in essence, we need to decide if we care about supporting deprecated
or removed stuff (an overly lax gml3.2), if so, what mechanism could
we use to catch such exceptions.

There is a lot unimplemented in both GML 3.1 and therefore GML3.2, and
IMHO we need to look at published schemas in a systematic way to catch
the things we need, and the INSPIRE GML3.2 schemas is a very good
place to start - make sure we can support all these and we'll catch
stuff in both GML 3.1 and 3.2 I suspect.

Can you explain how you'd propose organise the codebase? Bindings seem
good, nice handling of namespaces etc, but tests extend a GML3.1.1
bound setup for. I'm happy to do the work, but want to be working to
a plan you are comfortable with, and I didnt see an obvious way of
extending the current implementation.

Rob

On Wed, Nov 19, 2008 at 12:51 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Hi Rob,

Do we have a list of types between 3.1.1 and 3.2 which are different?
Instead of creating a new module i think it might be best if we kept the new
3.2 binding in the same module, perhaps just a different package. W e can
then create a new GMLConfiguration class for the new bindings. I think will
suffice with a minimum amount of "clutter".

So the question is how do we proceed with implementing the new bindings. You
said alot of the 3.1 bindings can be reused, which is great. Are there any
that can't be reused?

-Justin

Rob Atkinson wrote:

Hi Justin,

I did an experiment and hacked xsd-gml3 to use a gml3.2 test case, and
it looks like the bindings for gml 3.1.1 are basically re-usable for
gml3.2 support. I know we'll need a new binding (gml:identifier,
basically a gml:name)

it seems that its the tests which are most heavily bound to gml3.1.1
flavour

I'd like your advice as how best to proceed...

do we create a gml3-common - make gml3 extend it and have a gml3_2
extend it. Most of the tests would be in the gml3-common, with the
config set ups and mock data in the specific flavours?

I suppose I could just clone gml3 to gml3_2 and we can refactor later
- but I hate creating such an obvious mess of redundant code. Maybe
GML3.1.1 will die on the vine and it wont be such a big deal.

Or do you have a better idea?

Rob

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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.

4

Hi Rob,

<snip>

in essence, we need to decide if we care about supporting deprecated
or removed stuff (an overly lax gml3.2), if so, what mechanism could
we use to catch such exceptions.

Without knowing a lot about the specifics, i would say yes. My rationale being things like gml:MultiPolygon and gml:MultiLineString being deprecated. I have not seen a lot of GML that has made the jump to MultiSurface and MultiCurve. And GeoServer only outputs them when in strict "cite compliance" mode.

There is a lot unimplemented in both GML 3.1 and therefore GML3.2, and
IMHO we need to look at published schemas in a systematic way to catch
the things we need, and the INSPIRE GML3.2 schemas is a very good
place to start - make sure we can support all these and we'll catch
stuff in both GML 3.1 and 3.2 I suspect.

Agreed, we should look at the schemas and figure out what bindings we have, and what we don't. And what sort of java objects each binding would correspond to.

Can you explain how you'd propose organise the codebase? Bindings seem
good, nice handling of namespaces etc, but tests extend a GML3.1.1
bound setup for. I'm happy to do the work, but want to be working to
a plan you are comfortable with, and I didnt see an obvious way of
extending the current implementation.

So I would say we create a new package in the gml3 module called "org.geootools.gml3.v3_2". Inside this directory there will be:

   * a new GMLConfiguration class which sets up the bindings custom to GML 3.2
   * a new GML class which contains all the type and elements names for GML3, and also a reference to the actual gml.xsd file for 3.2. This class can be generated with the code generator.

Then create another subpackage called "org.geotools.gml3.v3_2.bindings" where all the 3.2 specific bindings can live.

-Justin

Rob

On Wed, Nov 19, 2008 at 12:51 AM, Justin Deoliveira
<jdeolive@anonymised.com> wrote:

Hi Rob,

Do we have a list of types between 3.1.1 and 3.2 which are different?
Instead of creating a new module i think it might be best if we kept the new
3.2 binding in the same module, perhaps just a different package. W e can
then create a new GMLConfiguration class for the new bindings. I think will
suffice with a minimum amount of "clutter".

So the question is how do we proceed with implementing the new bindings. You
said alot of the 3.1 bindings can be reused, which is great. Are there any
that can't be reused?

-Justin

Rob Atkinson wrote:

Hi Justin,

I did an experiment and hacked xsd-gml3 to use a gml3.2 test case, and
it looks like the bindings for gml 3.1.1 are basically re-usable for
gml3.2 support. I know we'll need a new binding (gml:identifier,
basically a gml:name)

it seems that its the tests which are most heavily bound to gml3.1.1
flavour

I'd like your advice as how best to proceed...

do we create a gml3-common - make gml3 extend it and have a gml3_2
extend it. Most of the tests would be in the gml3-common, with the
config set ups and mock data in the specific flavours?

I suppose I could just clone gml3 to gml3_2 and we can refactor later
- but I hate creating such an obvious mess of redundant code. Maybe
GML3.1.1 will die on the vine and it wont be such a big deal.

Or do you have a better idea?

Rob

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win great
prizes
Grand prize is a trip for two to an Open Source event anywhere in the
world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
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.

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