Yup, this looks great to me.
On Wed, Jun 12, 2013 at 12:32 PM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Wed, Jun 12, 2013 at 4:29 PM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>> Its important to note that on the encoding side the type/element qname
>> declared by the binding is only used if there is type in the context which
>> is often not there for encoding (think encoding a straight feature
>> collection without specifying the feature schema), so it falls back to the
>> java class declared. If there is type information in the context then it
>> can choose explicitly the binding.
>>
>> So let's consider both LineStringTypeBinding and
>> CircleByCenterPointBinding both bound to LineString. If we have schema that
>> tells us that a property of a feature is one or the other, than its no
>> problem, the right one will get chosen. If we don't though, then we have a
>> problem. The easy way around this would be to have our data structure for
>> curves actually extend LineString. Then we have a unique type mapping.
>> Which I think is the way we are going correct?
>>
>> If we don't have a unique type mapping the other thing we can do is have
>> either binding check properties of the object to determine which to use.
>> For instance, if LineStringTypeBinding gets called but the LineString
>> object has some property that indicates the CircleByCenterPointBinding
>> should be used, it could delegate. And vice versa for
>> CircleByCenterPointBinding. A bit of a hack.
>>
>
> Ok, so, if I use a hierarchy like this one, then it should be good?
>
> LineString
> +---LinearRing
> +----Ring (composed of CircularArc and LineString that form a closed
> Ring)
> +----Circle (composed of two CircularArc of the same circle, closing
> on each other, again, this might not be needed)
> MultiLineString
> +---Curve (composed of CircularArc only, not sure if this class is
> actually necessary yet)
> +---CompoundCurve (composed of CircularArc and LineString internally, but
> only visible if you cast to Curve)
>
> There would not be a specific CurvePolygon class, I guess the code
> interested in circular stuff will have to check
> shell and holes to see if they are curved classes? GML wise at least the
> specific class does not seem to be needed.
>
> With the above we'd make specific bindings for those classes to the
> respective elements in GML and this is it?
>
> Cheers
> Andrea
>
> --
> ==
> Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
> information.
> ==
>
> Ing. Andrea Aime
> @geowolf
> Technical Lead
>
> GeoSolutions S.A.S.
> Via Poggio alle Viti 1187
> 55054 Massarosa (LU)
> Italy
> phone: +39 0584 962313
> fax: +39 0584 1660272
> mob: +39 339 8844549
>
> http://www.geo-solutions.it
> http://twitter.com/geosolutions_it
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
