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.
------------------------------------------------------------------------------
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
