[geos-devel] Question on CoordinateSequence getAt function

[chen zhen]

Hi,

I am trying to use geos for topology analysis. I noticed the comments in
the class CoordinateSequence(CoordinateSequence.h) :

> There are some cases in which you might want Geometries to store their
> points using something other than the GEOS Coordinate class. For example,
you
> may want to experiment with another implementation, such as an array of Xs
> and an array of Ys. or you might want to use your own coordinate class,
one
> that supports extra attributes like M-values.

> You can do this by implementing the CoordinateSequence and
> CoordinateSequenceFactory interfaces. You would then create a
> GeometryFactory parameterized by your CoordinateSequenceFactory, and use
> this GeometryFactory to create new Geometries. All of these new Geometries
> will use your CoordinateSequence implementation.

That means I can build my own CoordinateSequence class by implementing the
interfaces in CoordinateSequence class, and further for geometry storage.

In my case, the underlying of a CoordinateSequence is a array of Point:

> typedef struct {
>   double x;
>    double y;} Point;

and my class looks like :

> class GEOS_DLL MyCoordinateSequence : public CoordinateSequence {
>       private:
>           Point * _points;       /* points array */
>       ...

everything seems to be fine except the getAt function which need to return
a const reference to a Coordinate object. Because I do not have the
vector<Coordinate> member in my class, I am not sure how to convert a Point
to a  Coordinate object for returning.

And if I add a vector<Coordinate> member in the class, there is not
different with  class CoordinateArraySequence :-(

Also I wonder why then return value is a const reference object rather that
a pointer?  If it is a pointer, I can make my own Coordinate sub class
which
is a wrap of point.  Is there any design purpose on this ? Is it possible
to change the return type to a Coordinate pointer that shouble be a
abstract class.

comments are welcomed.

Regards,

zhen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20190723/916d3ac8/attachment.html>