Re: [Geotools-devel] xmlcodegen geometry binding problem

[Justin D. <jde...@op...>]

Hi Ben,

My apologies for delayed response. Lots of stuff on the go right now.

As for your question. Those types that are bound to JTS types were 
changed after the fact manually. Tedious yes I know.

I believe the only place those bindings are used is in GeoServer. When 
it auto generates a schema from a feature type it uses those bindings to 
do the java class to xml type mapping.

Hope that helps. One thing I brought up some time ago on this list but 
never got any traction was the idea of a specific class called 
"TypeMapping" which would encapsulate java to xml type mapping. Not sure 
if it will help in this case or not.

-Justin

On 1/27/10 1:22 AM, Ben Caradoc-Davies wrote:
> Justin,
>
> I am still trying to find out how geometry types in gml3 GMLSchema end
> up bound to JTS Geometry.class (in and AttributeTypeImpl). When I run
> xmlcodegen to make GMLSchema they are instead bound to Collection.class
> (in a ComplexTypeImpl), and Bad Things Happen. Did I miss something?
>
> Sorry for pestering; I see you have been rather busy with the WCS
> bindings. :-)
>
> Kind regards,
> Ben.
>
>
> On 21/01/10 14:19, Ben Caradoc-Davies wrote:
>> Justin,
>>
>> I have been making a lot of progress using xmlcodegen to improve
>> gt-xsd-gml3 GMLSchema (GEOT-2505). I modified schema.javajet so its
>> output avoids the 64kB method limit. I also changed the output so that
>> the members of GMLSchema are static, as in earlier versions.
>>
>> One problem I have encountered is that the bindings for geometry
>> property types are now ComplexType, not AttributeType bound to JTS
>> Geometry. This is causing app-schema unit test failures.
>>
>> The trunk version of xmlcodegen produces (even before my modifications)
>> a gml3 GMLSchema:
>>
>> GEOMETRYPROPERTYTYPE_TYPE =
>> new ComplexTypeImpl(
>> new NameImpl("http://www.opengis.net/gml","GeometryPropertyType"),
>> GEOMETRYPROPERTYTYPE_TYPE_schema, false,
>> false,Collections.EMPTY_LIST,XSSchema.ANYTYPE_TYPE, null
>> );
>>
>> Note that the geometry property type is now a complex type (all of which
>> are bound to Collection.class).
>>
>> But the trunk version of gt-xsd-gml3 GMLSchema (r32244) contains:
>>
>> public static final AttributeType GEOMETRYPROPERTYTYPE_TYPE = new
>> AttributeTypeImpl(new NameImpl(
>> "http://www.opengis.net/gml", "GeometryPropertyType"), Geometry.class,
>> false,
>> false, Collections.EMPTY_LIST, XSSchema.ANYTYPE_TYPE, null);
>>
>> That is, a geometry property is treated as an ordinary simple attribute
>> bound to a JTS Geometry, so these can be treated as atomic simple
>> objects and passed through the feature model. The new xmlcodegen instead
>> exposes the full internal complexity of geometry property types, and in
>> effect disables the special handling of geometry objects.
>>
>> I can find no special treatment for geometries in schema.javajet (trunk
>> or previous versions). How is the special case for geometries applied?
>>
>> How can I use the latest xmlcodegen to create an XMLSchema with geometry
>> property types bound to JTS geometry types? This will be necessary to
>> allow JTS geometry objects to be passed from data sources through the
>> feature model to the encoder.
>>
>> Kind regards,
>>
>
>


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