On Mon, Jun 3, 2013 at 4:16 PM, Justin Deoliveira <jdeol...@opengeo.org>wrote:
>
> 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?
>
The former. In order to avoid a landslide amount of changes in GeoTools I
would like the new geometries
to be subclasses of existing ones, that do linearize on the fly if they are
getting treated as their superclasses,
and would reveal their circular nature only to those callers that know how
to recognize and cast to them.
>
> 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 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?
>
> 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.
>
Ok, so to summarize the model would be as follows:
CircularString extends MultiLineString
CompoundCurve extends MultiLineString (and its made of CircularString and
LineString elements inside)
Ring extends LinearRing (internal representation is just like CompoundCurve)
I believe CircularString would map in GML to MultiCurve, and would encode
as a list of arc by 3 points
CompoundCurve would also map to MultiCurve, but it would map to a list of
plain linestrings and arcs by 3 points
Ring would be the same as above, although for true circles (two arcs of the
same cicle closing on each other)
it would be probably interesting to encode the baby as a MultCurve made of
a single CircleByCenterPoint
What do you think?
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
-------------------------------------------------------
------------------------------------------------------------------------------
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
