[postgis-devel] Location Of LWAlgorithms

[Paul Ramsey]

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

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.

On Wed, Dec 24, 2008 at 7:36 AM, Obe, Regina <robe.dnd at cityofboston.gov> wrote:
>
> Oops I meant to say
>
> What walks? vs. What does a thing do?
> How do things walk? vs. How does a thing do actions?
>
> But then when you start getting into the interaction of two geometry
> types -- e.g. Distance are we in agreement that
> that that can't be neatly stuffed in with the geometry files?
>
> Though I can't see how you can completely extricate the What walks/How
> does a thing walk need given
> PostgreSQL's/PostGIS geometry reliance on that single entry stub. So the
> main benefit I could think of of an object-oriented approach would be
> the ease with which we can introduce new geometry types and remove them,
> which I just can't see easily happening anyway given our structure and
> given that we have a lot more functions than geometry types, seems more
> plausible we'd be doing more remove/shuffle function behavior than
> geometry type behavior.
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Obe,
> Regina
> Sent: Wednesday, December 24, 2008 10:08 AM
> To: PostGIS Development Discussion
> Subject: RE: [postgis-devel] Location Of LWAlgorithms
>
> Thought about this a little more
>
> I guess it boils down to
>
> Is it more important to know what walks? or if a thing walks?
>
> I'm on the what walks side.
>
>
> -----------------------------------------
> The substance of this message, including any attachments, may be
> confidential, legally privileged and/or exempt from disclosure
> pursuant to Massachusetts law. It is intended
> solely for the addressee. If you received this in error, please
> contact the sender and delete the material from any computer.
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>