On Tue, Jun 11, 2013 at 2:46 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Tue, Jun 4, 2013 at 3:30 PM, Justin Deoliveira <jdeol...@opengeo.org>wrote:
>
>> I see, so a generic binding for LineString that would then do some
>> typechecks and delegate to the proper
>>
>>> subclasses? My worry is, at that point, isn't the element used for
>>> encoding pretty much cast in stone?
>>>
>>
>> Yeah, the binding has to choose what class it binds to unless the schema
>> gives enough information to trigger the binding explicitly, which it
>> probably wont. Not sure what you mean by cast in stone? Yes the binding
>> will be bound to the type of the object, but it can change along with it.
>> Not sure I understand.
>>
>
> I mean, the bindings report to work against a certain element and class.
> If I'm running a binding for LineString, the binding is
> targetting GML.LineStringType, it has no way to decide to target something
> else, e.g., CircleByCenterPoint, especially because getTargetType() does
> not receive the element being encoded as a parameter.
> That's why I'm having difficulties seeing how one can delegate to another
> binding, it's not just a matter of extracting the right properties out of
> the object, but also to indicate the right type of target element.
>
Ok, now I understand. Yes you are correct for the most part. We had this
problem in gml 3.1 with the deprecated MultiPolygon type, and the addition
of MultiSurface. Unfortunately there is no great solution to this. A
binding can actually implement comparable and indicate whether it should
take precedence over another.
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.
>
>> Cool. So given this class hierarchy I think a single MultiCurve binding
>> acting accordingly based on the concrete curve type makes most sense. The
>> binding can bind to MultiLineString which indeed will conflict with the
>> existing binding, but we can easily get around this by having the type
>> check dance fall back to MultiLineString binding if the geometry passed in
>> doesn't match any of the known curve types.
>>
>
> How is the fallback going to work, code wise?
>
Given the object is there a way to determine if its actually a curve and
not a "normal" multi line string? If not then this won't work.
>
>
>>
>> Making it cleaner would be to have all the curve subtypes extend from
>> some sort of special interface or abstract class. Which api wise might not
>> be a bad idea for code that has to do checks on geometry type.
>>
>
> I can go for marker interfaces, but how would those work?
>
By marker interfaces i mean that the curve classes extend from the JTS
geometry classes and form a one-to-one relationship with the gml types.
>
> Cheers
> Andrea
>
>
> --
> ==
> GeoServer training in Milan, 6th & 7th June 2013! Visit
> http://geoserver.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
