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.
------------------------------------------------------------------------------
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
