On Tue, May 28, 2013 at 8:00 AM, Andrea Aime
<andrea.a...@geo-solutions.it>wrote:
> On Mon, May 27, 2013 at 9:17 PM, Justin Deoliveira
> <jdeol...@opengeo.org>wrote:
>
>> Sounds like a good approach to me. So to clarify, are you planning on
>> taking the Circle/Arc code from the gml3 module and putting that in the api
>> module?
>>
>
> Yes, and wrap it in a CircularString class that hides the circular nature
> to the unprepared observer.
> However, Jody's comments in yesterday's meeting about paying attention to
> linearization prompted me to
> look into the linearization code in WKTReader2, in particular
> the circularSegmentize methods.
>
> They do work using a different approach as Circle, in particular Circle
> guarantees a fixed distance
> between linearized and original geometry, whilst WKTReader2 is based on
> the "segments per quadrant"
> approach, which is the same approach postgis uses.
> Jody was warning about linearizing valid geometries, and ending up with
> invalid ones, which I believe
> can happen having two concentric arcs, starting and ending at different
> angles, and having a radius
> that's very close to each other.
> My understanding is that to avoid topologic issues the sampling points
> should be chosen at the
> same angles in both arcs, something that the "max distance" approach does
> not necessarily guarantees,
> yet, the code in WKTReader2 does not guarantee that either.
>
> I guess a mix of the two would be needed, pick a starting number of
> quadrants, double them until the max distance
> is lower than the expected one, and then perform a sampling that follows
> fixed angles set starting from zero
> instead of the arc start (obviously, still respecting the start and end
> points, which would happen to be at less
> than the chosen sampling angle from the first fixed sampling point.
>
> If I go this way I guess I'll have to write my own linearization code, not
> the end of the world I guess, but I won't
> need the Circle/Arc classes from GML anymore.
>
> Do you see a chance to consolidate? It would be nice to use a single set
of curve classes located in api or main and have the gml encoding work off
of them. It isn't clear to me if the GML model is compatible with the one
you are proposing.
> 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.
------------------------------------------------------------------------------
Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
Get 100% visibility into your production application - at no cost.
Code-level diagnostics for performance bottlenecks with <2% overhead
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap1
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
