Justin,
I would have to look in to this overriding the GML3Configuration thing,
it's definitely not being done at this time.
The main issue isn't with the CurvePropertyTypeBinding, but with
MultiCurvePropertyTypeBinding.
Because the type MultiLineString[] isn't a Geometry (as it is an array).
I would imagine that causing issues outside of app-schema too, cause as
far as I can see GeometryAttributes are everywhere assumed to contain a
Geometry object and GeometryAttributeDescriptors are assumed to be
describing a Geometry object. Take for example this code from
org.geotools.data.DataUtilities in the main package:
|if (Geometry.class.isAssignableFrom(clazz)) {
GeometryType at = new GeometryTypeImpl(new
NameImpl(name), clazz, crs, false,
false, Collections.EMPTY_LIST, null, null);
return new GeometryDescriptorImpl(at, new
NameImpl(name), 0, 1, nillable, null);
} else {
AttributeType at = new AttributeTypeImpl(new
NameImpl(name), clazz, false, false,
Collections.EMPTY_LIST, null, null);
return new AttributeDescriptorImpl(at, new
NameImpl(name), 0, 1, nillable, null);
}|
I would assume for consistency it is important to keep Geometry
attributes mapped to objects that are assignable to a Geometry object.
I reckon the most logical thing to do is to create a
'MultiMultiLineString' class (or something) that inherits from
GeometryCollection (and thus from Geometry) and describes a collection
of MultiLineStrings ?? Does that make sense?
I am also a bit confused as to why in the binding classes they are
mapped to different types.
Niels
On 26/10/10 21:59, Justin Deoliveira wrote:
Hi Niels,
This was actually done intentionally, and in support of wfs cite
tests. Since the jts geometry model obviously does not curves there
are some hacks in place to support them since in gml3 curves and
surfaces are the default and linestring and polygon are deprecated.
So, because a curve has multiple segments a single LineString did not
really do it, hence it being mapped to MultiLineString. And then
MultiCurve obviously being multiple curves is mapped to an array of
MultiLineString. It was the best mapping we had available.
Also I know of people that are actually using the gml3 bindings to
parse cuves into the multi line string structure, so this change
would undoubtedly break that code.
All that said, i agree the change makes sense. Can we create new
bindings for cuve mapping them to LineString and have them be specific
to app-schema leaving the current case as it is. Does app-schema have
the ability to override the bindings of the regular GML3Configuration?
-Justin
On Tue, Oct 26, 2010 at 2:31 AM, Niels <[email protected]> wrote:
Hi, (In particular @Justin)
While testing my changes for enabling xlink properties in
geometries, I have encountered something strange in the GMLSchema
class. In GMLSchema (for v3 and v3.2), MultiCurvePropertyType is
bound to the class MultiLineString[] (note the array brackets) and
CurvePropertyTypeBinding is bound to MultiLineString, while in the
Binding classes they are bound to MultiLineString and LineString
respectively (which means the encoder will enventually try to
convert them to the latter classes). I think the binding classes
in GMLSchema are an error, but I am wondering if it was done for a
reason.
In my tests I have been testing all kinds of Geometry
PropertyTypes, and discovered that MultiCurvePropertyType is not
being not encoded at all, while all the others are. I found that
the reason is the binding to MultiLineString[] in GMLSchema.
Because this class is not a geometry class (but an array), the
att.descriptor for the multicurve property is not initialised as a
geometryattributedescriptor, but just a normal
attributedescriptor. Therefore at a later stage the whole thing
cannot be handled and is thrown away.
I have changed the class in GMLSchema from MultiLineString[] to
MultiLineString (which I think it should be), and everything works
fine now. Is this correct, and should CurvePropertyTypeBinding be
changed to LineString?
With Regards,
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
--
*Niels Charlier*
Software Engineer
CSIRO Earth Science and Resource Engineering
Phone: +61 8 6436 8914
Australian Resources Research Centre
26 Dick Perry Avenue, Kensington WA 6151
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
