[geos-devel] Second beta for ffi-geos extension now available

[Sandro Santilli]

On Thu, May 12, 2011 at 09:42:20AM -0600, Sean Gillies wrote:
> On Thu, May 12, 2011 at 9:28 AM, Sandro Santilli <strk at keybit.net> wrote:
> > On Thu, May 12, 2011 at 11:16:19AM -0400, J Smith wrote:
> >> On Thu, May 12, 2011 at 2:19 AM, Sandro Santilli <strk at keybit.net> wrote:
> >> > Right. In the PHP binding I've made a single function taking an associative
> >> > array for all the parameters (building a GEOSBufferParameter object).
> >> >
> >>
> >> Yeah, I noticed that and decided to follow suit. I'd like the two to
> >> be reasonably close together in terms of their APIs and conventions
> >> aside from the usual language quirks and conventions.
> >
> > Speaking of which... how did you deal with prepared geoms ?
> > I didnt' make any use of those from the PHP binding. Dunno if I want
> > them to be transparent or explicit.
> >
> 
> FWIW, Shapely has a prep() function that prepares a geometry. The
> result has a subset of the normal geometric object methods.
> 
> http://gispython.org/shapely/docs/1.2/manual.html#prepared-geometry-operations

So both Python and Ruby made the "PreparedGeometry" type explicit.

I was thinking more of a .prep() function returning void and internally
holding a prepared version to transparently use in all prepared-aware
methods. This would kind of follow PostGIS use, where you actually don't
even explicitly call the "prepare" which happens based on an heuristic
(the second time you run a predicate on a geometry that geometry gets
prepared). The advantage of transparency would be there's no API change
but automatic performance improvement.

--strk;

  ()   Free GIS & Flash consultant/developer
  /\   http://strk.keybit.net/services.html