[geos-devel] Question about JTS porting process

[strk at refractions.net]

CoordinateSequenceFactory::create()

is  a virtual function. The idea is to support an arbitrary
number of dimensions past X/Y.

CoordinateArraySequenceFactory only supports 3d, curently dimension
is *always* forced to 3d.

In order to support higher (or slimmer) CoordinateSequences
developers can derive from the Factory and from CorodinateSequence.

It's pretty new stuff added to the interface.

--strk;


On Thu, Mar 02, 2006 at 03:38:18PM +0100, Mateusz Å?oskot wrote:
> Hi,
> 
> AFAIK GEOS is a kind of direct port of JTS.
> Am I right?
> So, I have some observation and I'd like to ask for explanation.
> It seems some of bugs/typos/inconsistencies are ported
> together with features ;-)
> Also, obviously there are some things in-progress/not finished yet
> in JTS code. So, such incomplete stuff seems also to be ported.
> Am I right?
> 
> Here is small example of such class in GEOS where such incomplete stuff 
> comes straight from JTS:
> 
> ///////////////////////////////////////////////////////////////////////
> // GEOS version of class
> class CoordinateArraySequenceFactory : public CoordinateSequenceFactory
> {
> public:
> 
>   // ...
> 
>   CoordinateSequence *create(vector<Coordinate> *coords, int dims) const
>   {
>     return new CoordinateArraySequence(coords);
>   }
> 
>   CoordinateSequence *create(unsigned int size,
>     unsigned int dimension=3) const
>   {
>     return new CoordinateArraySequence(size);
>   }
> 
>   // ...
> };
> 
> ///////////////////////////////////////////////////////////////////////
> // JTS version of class
> DefaultCoordinateSequenceFactory
> 
> 
> and sample method:
> 
> public CoordinateSequence create(int size, int dimension) {
>    return new DefaultCoordinateSequence(size);
> }
> 
> 
> My question is why those parameters like dims or dimension are not used
> in GEOS as well as in JTS?
> There are many similar places.
> 
> Does it mean that JTS developers are going to extend implementation of 
> create method(s) and they will use those (currently unused) parameters?
> This would imply the same in GEOS.
> 
> But if those unused things won't be used in future then it could be 
> better to clean them up during GEOS refactoring.
> 
> I'd be thankful if anyone could expain me the idea.
> 
> Cheers
> -- 
> Mateusz Łoskot
> http://mateusz.loskot.net
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel

-- 
----------------------------------------------------------------------
State-collected Geographic Data is public property !
Reject the INSPIRE directive.
Sign the petition: http://petition.publicgeodata.org