On Mon, Jun 3, 2013 at 7:32 AM, Andrea Aime <andrea.a...@geo-solutions.it>wrote:
> On Thu, May 30, 2013 at 10:06 AM, Andrea Aime <
> andrea.a...@geo-solutions.it> wrote:
>
>> The GML2 model does not have any curved arc notion, so that's easy.
>> The GML3 model has a number instead:
>> * CircleByCenterPoint: this one we cannot represent as is with the work
>> I'm going to do, but it could be turned into
>> an equivalent circle
>> * Circle, which is represented by its 3 points, and which would have to
>> be represented by two arcs in spatial databases
>> * ArcString, whose interpolation attribute is fixed to circularArc3Points
>> * MultiCurve, which is made of either straight of curved elements
>> * Polygon, whose internal structure can be made of either LinearRing or
>> Ring objects, the latter allowing for curved elements
>>
>> So, trying to do a logical mapping:
>> 1) a circularstring made of just one arc is mapped to one ArcString
>> 2) a circularstring made of more elements is mapped to a MultiCurve made
>> solely of ArcString, or a Ring made solely of ArcString
>> if it's closed, or a Circle if the elements are actually only two and
>> representing a string
>> 4) a compoundcurve should map into a MultiCurve automatically (as an
>> instance of LineString)
>> 5) a polygon should automatically split into its elements, same as 4)
>>
>> I believe 1) and 2) are problematic with the design of the GML3 encoder?
>> If it was a TranslatorBase kind it would
>> trivial to implement that logic, but with the way bindings are processed
>> in gt-xsd I would honestly don't know
>> how to proceed, apparently it pretends a 1-1 matching between java class
>> and xml element?
>> It seems to me that given a general CircularString with more than one
>> element, we need to map it to a MultiLineString,
>> whose elements are Arc objects (a subclass of LineString) which is an arc
>> by 3 points, and then modify ArcBinding
>> to bind to those objects?
>> And for polygons I guess a Ring class would be needed, subclass of
>> LinearRing, that also linearizes automatically,
>> that would be used in RingBinding?
>>
>> The above is annoying, as the GML encoder limitations would percolate
>> down into the geometry representation, limiting it.
>>
>
> Am I missing something? Having a CircularString extends MultiLineString
> and Ring extends LinearRing is
> not going to be the end of the world, but I'd like to see if there are
> better options.
>
> I also thought about some sort of feature collection wrapper that
> dynamically turns the above JTS objects into
> custom GML objects to be used by the encoder alone, and we' have to wrap
> the collection every time it has
> to be encoded. But it seems like an ugly band aid, and one would have to
> know the wrapping is necessary
> (thinking about people using the geotools Encoder API directly here)
>
Sorry, trying to wrap my head around this one. I don't quite understand the
class structure being proposed here. Are we talking about classes that
extend from the JTS primitive geometry types? Or a separate hierarchy that
is completely isolated until we get to linearizing the geometry objects?
Or both?
That said the encoder does impose mappings between java and xml land but it
only relies on a 1-1 mapping when the context is ambiguous. And by
ambiguous i mean cases like geometry properties that reference abstract
types. There are some ways around this in the encoder like the notion of
binding priorities. We may also be able to just a single binding for a type
and then based on the object value delegate to the relevant binding.
I can't really comment on an approach until i have knowledge of the object
model. But I agree that we shouldn't have any limitations in the gml3
encoder influence the api design. I would suggest we propose an initial
object model that we think suites our needs for supporting curves in the
various formats that we know about, sql server, postgis, etc.... With that
i'll work on the gml mapping problem.
> 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.
------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with <2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
