[postgis-devel] Location Of LWAlgorithms
robe.dnd at cityofboston.gov
Wed Dec 24 06:47:41 PST 2008
That sort of works. Honestly I'm not quite as opinionated as I come
off sounding. I just like playing devil's advocate. If Paul wanted to
go the functional route I'd probably be sitting here coming up with
reasons why his thinking is flawed.
I guess the only issues I have with this is that
1) it takes too much brain power and context switching when my mind is
thinking about distance, buffer, translate, num dimensions etc which is
most of the time, I could F**** care what kind of geometry I'm dealing
with. I just want to
see X algorithm in one file so I don't have to flip thru 20 files. Of
course I guess that is taken care of by your proposal -- except what
exactly is a lower level function? I have a vague idea of what that is,
but it is not deterministic. And that bothers me. See 2.
2) Now I have to think -- "hmm is this a higher algorithm or lower
algorithm? to figure out where to look"
Take the case of ST_Multi - now I would think that is a lower algorithm
because clearly its the property of
a geometry type. (or do you consider it a Class function rather than an
instance function) and where do we put Class functions exactly - do we
lump it in with the accessors or constructors.
a) First you've got to open up the Multi stub function -- because hey
PostgreSQL needs one function to latch on to so we need stub functions
anyway. Or am I missing something here.
b) Then your stub does some sort of case to call the correct
lwgeom_is_has_multi or whatever. Okay now I have to follow those cases
into (hmm how many geometries do we have?) files to figure out what that
3) So not only is an object view (are rather should I say noun objects,
I'm all for verb objects - down with nouns) flawed as far as spatial
operations are concerned, it doesn't really fit well in the
PostgreSQL/C/PostGIS connectivity way since we have one geometry
PostgreSQL type to cover all our different geometry types.
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Mark
Sent: Wednesday, December 24, 2008 9:13 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] Location Of LWAlgorithms
Paul Ramsey wrote:
> I've started an lwalgorithm.c file. However, I see some functions are
> living with the types they work against. ptarray_substring, for
> example. By a similar token, area should move to lwpoly and lwmpoly
> implementations for area. Anyone have a problem with a general rule of
> locating methods with their objects, or should we keep the object
> files restricted to constructors/accessors and put all the
> calculations elsewhere?
For me, the common sense approach would be to think with an
object-oriented brain. So I would argue that direct properties of items,
e.g. length of linestrings, areas of polygons etc. should live in the
individual lwline.c/lwpoly.c files. For higher level algorithms, e.g.
calculating clipping/intersection points, the code should live in your
separate lwalgorithm.c file. Does that help at all?
Sirius Corporation - The Open Source Experts
T: +44 870 608 0063
postgis-devel mailing list
postgis-devel at postgis.refractions.net
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.
More information about the postgis-devel