Hi Niels,
On Tue, Oct 26, 2010 at 9:34 PM, Niels <[email protected]> wrote:
> 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?
>
Good point, and yeah that makes sense. Or we could turn it into a generic
geometry collection. I guess i prefer the latter if we can get away with it.
So I would be +1 on the change as long as it is (a) on trunk only and (b)
does not break wfs cite tests.
>
> I am also a bit confused as to why in the binding classes they are mapped
> to different types.
>
Sorry, I don't quite understand the question.
>
> 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]><[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
>
--
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
