[postgis-devel] Location Of LWAlgorithms

[Obe, Regina]

I really like the naming convention idea but as far as bunching up I'm almost thinking GASP - a separate file for each public function, a file for shared functions that are reused across but not public.  like an lwsimplify.c kind of like we have lwgeom_kml.c, lwgeom_transform.c, in the lwgeom folder.   But I guess that could  become silly given the number of functions we have.

I guess my thinking is in mapserver there is a natural workflow. Everything is working to make a map and every element in the mapserver hierarchy plays a fairly unique well-defined role where as in PostGIS, there is no defined workflow to my knowledge and each geometry plays the same role - to be stuffed in a meat grinder device of sorts.


-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net on behalf of Paul Ramsey
Sent: Wed 12/24/2008 2:34 PM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Location Of LWAlgorithms
 
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
>
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel







-----------------------------------------
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20081224/dce8f1bf/attachment.html>