<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7653.38">
<TITLE>RE: [postgis-devel] Location Of LWAlgorithms</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<P><FONT SIZE=2>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.<BR>
<BR>
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.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: postgis-devel-bounces@postgis.refractions.net on behalf of Paul Ramsey<BR>
Sent: Wed 12/24/2008 2:34 PM<BR>
To: PostGIS Development Discussion<BR>
Subject: Re: [postgis-devel] Location Of LWAlgorithms<BR>
<BR>
At the risk of extending this further, one of the things I really like<BR>
about the Mapserver code base is that the function naming convention<BR>
directs one into the appropriate source file...<BR>
<BR>
so msLayerFree(layerObj *layer) is found in ... maplayer.c<BR>
and msPostGISRetrievePK() is found in ... mappostgis.c<BR>
<BR>
I was looking just now at the simplify routines, which are currently<BR>
in lwgeom/ and comprise:<BR>
<BR>
void DP_findsplit2d(POINTARRAY *pts, int p1, int p2, int *split, double *dist);<BR>
POINTARRAY *DP_simplify2d(POINTARRAY *inpts, double epsilon);<BR>
LWLINE *simplify2d_lwline(const LWLINE *iline, double dist);<BR>
LWPOLY *simplify2d_lwpoly(const LWPOLY *ipoly, double dist);<BR>
LWCOLLECTION *simplify2d_collection(const LWCOLLECTION *igeom, double dist);<BR>
LWGEOM *simplify2d_lwgeom(const LWGEOM *igeom, double dist);<BR>
<BR>
Moving them to liblwgeom, I can imagine ending up with<BR>
<BR>
void lwalgorithm_dp_findsplit2d(POINTARRAY *pts, int p1, int p2, int<BR>
*split, double *dist);<BR>
POINTARRAY *lwalgorithm_dp_simplify2d(POINTARRAY *inpts, double epsilon);<BR>
LWLINE *lwline_simplify2d(const LWLINE *iline, double dist);<BR>
LWPOLY *lwpoly_simplify2d(const LWPOLY *ipoly, double dist);<BR>
LWCOLLECTION *lwcollection_simplify2d(const LWCOLLECTION *igeom, double dist);<BR>
LWGEOM *lwgeom_simplify2d(const LWGEOM *igeom, double dist);<BR>
<BR>
Either spread out among the relevant files, or all concentrated in<BR>
lwalgorithm. Spreading them out adds a level of indirection to<BR>
figuring out "how does this work". But if the function names direct<BR>
one to the right places to look, the indirection is less painful. Or<BR>
just having them bunched up in lwalgorithm. I really don't know.<BR>
<BR>
P.<BR>
<BR>
On Wed, Dec 24, 2008 at 7:36 AM, Obe, Regina <robe.dnd@cityofboston.gov> wrote:<BR>
><BR>
> Oops I meant to say<BR>
><BR>
> What walks? vs. What does a thing do?<BR>
> How do things walk? vs. How does a thing do actions?<BR>
><BR>
> But then when you start getting into the interaction of two geometry<BR>
> types -- e.g. Distance are we in agreement that<BR>
> that that can't be neatly stuffed in with the geometry files?<BR>
><BR>
> Though I can't see how you can completely extricate the What walks/How<BR>
> does a thing walk need given<BR>
> PostgreSQL's/PostGIS geometry reliance on that single entry stub. So the<BR>
> main benefit I could think of of an object-oriented approach would be<BR>
> the ease with which we can introduce new geometry types and remove them,<BR>
> which I just can't see easily happening anyway given our structure and<BR>
> given that we have a lot more functions than geometry types, seems more<BR>
> plausible we'd be doing more remove/shuffle function behavior than<BR>
> geometry type behavior.<BR>
><BR>
> -----Original Message-----<BR>
> From: postgis-devel-bounces@postgis.refractions.net<BR>
> [<A HREF="mailto:postgis-devel-bounces@postgis.refractions.net">mailto:postgis-devel-bounces@postgis.refractions.net</A>] On Behalf Of Obe,<BR>
> Regina<BR>
> Sent: Wednesday, December 24, 2008 10:08 AM<BR>
> To: PostGIS Development Discussion<BR>
> Subject: RE: [postgis-devel] Location Of LWAlgorithms<BR>
><BR>
> Thought about this a little more<BR>
><BR>
> I guess it boils down to<BR>
><BR>
> Is it more important to know what walks? or if a thing walks?<BR>
><BR>
> I'm on the what walks side.<BR>
><BR>
><BR>
> -----------------------------------------<BR>
> The substance of this message, including any attachments, may be<BR>
> confidential, legally privileged and/or exempt from disclosure<BR>
> pursuant to Massachusetts law. It is intended<BR>
> solely for the addressee. If you received this in error, please<BR>
> contact the sender and delete the material from any computer.<BR>
> _______________________________________________<BR>
> postgis-devel mailing list<BR>
> postgis-devel@postgis.refractions.net<BR>
> <A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
><BR>
_______________________________________________<BR>
postgis-devel mailing list<BR>
postgis-devel@postgis.refractions.net<BR>
<A HREF="http://postgis.refractions.net/mailman/listinfo/postgis-devel">http://postgis.refractions.net/mailman/listinfo/postgis-devel</A><BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>
</BODY>
</HTML>
<HTML><BODY><P><hr size=1></P>
<P><STRONG>
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.
</STRONG></P></BODY></HTML>
<P><hr size=1></P>
<P><STRONG><font size="2" color="339900"> Help make the earth a greener place. If at all possible resist printing this email and join us in saving paper. </p> <p> </font></STRONG></P>