[postgis-devel] Location Of LWAlgorithms
Mark Cave-Ayland
mark.cave-ayland at siriusit.co.uk
Fri Dec 26 01:57:01 PST 2008
Paul Ramsey wrote:
> At the risk of extending this further, one of the things I really like
> about the Mapserver code base is that the function naming convention
> directs one into the appropriate source file...
>
> so msLayerFree(layerObj *layer) is found in ... maplayer.c
> and msPostGISRetrievePK() is found in ... mappostgis.c
Yuck. I don't really think this would work for PostGIS - having function
names sensitive to location doesn't work if you have an external API.
Think how much code would be broken if the codebase needs a slight
refactoring/breaking down into different files, which would cause the
function name to change... :(
It is important to consider how easy it is to locate existing routines
within the code, although this could be considered a "lack of
documentation" issue.
> I was looking just now at the simplify routines, which are currently
> in lwgeom/ and comprise:
>
> void DP_findsplit2d(POINTARRAY *pts, int p1, int p2, int *split, double *dist);
> POINTARRAY *DP_simplify2d(POINTARRAY *inpts, double epsilon);
> LWLINE *simplify2d_lwline(const LWLINE *iline, double dist);
> LWPOLY *simplify2d_lwpoly(const LWPOLY *ipoly, double dist);
> LWCOLLECTION *simplify2d_collection(const LWCOLLECTION *igeom, double dist);
> LWGEOM *simplify2d_lwgeom(const LWGEOM *igeom, double dist);
>
> Moving them to liblwgeom, I can imagine ending up with
>
> void lwalgorithm_dp_findsplit2d(POINTARRAY *pts, int p1, int p2, int
> *split, double *dist);
> POINTARRAY *lwalgorithm_dp_simplify2d(POINTARRAY *inpts, double epsilon);
> LWLINE *lwline_simplify2d(const LWLINE *iline, double dist);
> LWPOLY *lwpoly_simplify2d(const LWPOLY *ipoly, double dist);
> LWCOLLECTION *lwcollection_simplify2d(const LWCOLLECTION *igeom, double dist);
> LWGEOM *lwgeom_simplify2d(const LWGEOM *igeom, double dist);
>
> Either spread out among the relevant files, or all concentrated in
> lwalgorithm. Spreading them out adds a level of indirection to
> figuring out "how does this work". But if the function names direct
> one to the right places to look, the indirection is less painful. Or
> just having them bunched up in lwalgorithm. I really don't know.
>
> P.
For this example, I would argue that simplification is NOT a direct
property of the geometry and should reside in its own separate file
(e.g. lwdpsimplify.c). I think it would also make it easier if someone
tried to add a different simplification algorithm in future.
ATB,
Mark.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
More information about the postgis-devel
mailing list