On Mon, Jun 3, 2013 at 8:23 AM, Andrea Aime <andrea.a...@geo-solutions.it>wrote:
> 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?
>
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 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
>
> 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.
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.
> 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
>
> -------------------------------------------------------
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
