Hello list!
I work on a project that has been using the GEOS Ruby bindings for
years and and we've been adding a bunch of extensions and
modifications to it throughout that time. We've gotten to the point
now where we'd like to release this code into the wild world of free
software and open source
Hey Charlie.
Just to start off with, as I believe you were the original author of
the SWIG bindings: thanks for the Ruby library! When we first
discovered it we were ecstatic, 'cause the Ruby-based solutions we
were looking at at the time were prohibitively slow. Nothing beats
native libraries (us
Alright, all, that wasn't too bad...
Using the output from geos.i, I removed the version number constants
that get sorted out when geos.i is generated and which in turn is used
to generate geos_wrap.cxx. Instead of hard coding the constants at
build time, we can just use rb_eval_string during the
On Wed, Dec 1, 2010 at 5:16 AM, strk wrote:
>
> Why not LGPL ?
>
> As per "usual", freshmeat finds 276 projects written in Ruby,
> with their licenses:
>
> GPL: 90
> MIT/X: 43
> BSD Revised: 33
> LGPL: 28
> GPLv3: 18
> .
>
> http://freshmeat.net/search?page=1&q=
On Wed, Dec 1, 2010 at 12:21 AM, Paul Ramsey wrote:
> My only thought is, "my, I know nothing about Ruby!". So, do tell me
> what needs to be in the main GEOS repo and who is going to need access
> to commit it. :)
>
> Best,
>
> P.
>
Hi Paul.
At the moment the number of files is minimal:
- a Ra
On Wed, Dec 1, 2010 at 11:38 AM, Paul Ramsey wrote:
> If there's no integration *required* to make the Ruby stuff work well,
> then (a) you should keep them and (b) we should strip out the old
> ones and replace them with a readme.txt pointing to the location of
> the maintained ones.
>
> P.
>
T
That's a possibility, perhaps using ruby's ffi bindings, assuming it doesn't
hurt performance and keeps the existing API. It sure could make things nicer
for adding functionality and could open the code up potentially to a new
audience who aren't familiar with hacking at ruby at the C level. I h
Howdy folks.
Well, Charlie Savage planted the idea in my mind, so I'm currently in
the process of re-writing the GEOS bindings for Ruby in Ruby using
FFI.
After a hack-fest last night, I've gotten the basics down, and am
writing a unit test suite that can be used to compare against the
current SW
On Fri, Dec 3, 2010 at 12:50 AM, Charlie Savage wrote:
>>
>> Well, Charlie Savage planted the idea in my mind, so I'm currently in
>> the process of re-writing the GEOS bindings for Ruby in Ruby using
>> FFI.
>
> Very cool - but I think Sean deserves the credit...
>
Well, it was certainly a team
On Fri, Dec 3, 2010 at 4:58 AM, strk wrote:
>
> Make sure to use the reentrant interface, worth, for new projects.
> We may add support for precision models and things like that with its
> use (contextual settings).
>
You mean use the *_r(handle, ...) functions and whatnot? Yeah, I
switched over
Howdy y'all.
I just finished pushing an implementation of the FFI-based GEOS Ruby
bindings to github. The new repository is available here:
https://github.com/dark-panda/ffi-geos
Included in the code:
- the code is built on the current svn trunk and definitely bombs out
using GEOS 3.2.2 at the
Howdy list.
I've run into a problem with the Ruby FFI bindings[1] and was
wondering if anyone has hit onto this problem before or has any
advice.
The basic gist of it goes something like this: as far as I can tell,
it seems that the error/notice handling code in GEOS is giving Ruby
and/or FFI a c
On Thu, Dec 9, 2010 at 12:09 AM, Charlie Savage wrote:
>> I believe that the crux of the problem may be due to GEOS's error
>> handlers using varargs, which libffi cannot handle in callbacks
>> according to its documentation.
>
> Just did a quick read of https://github.com/ffi/ffi/wiki/examples an
On Thu, Dec 9, 2010 at 12:32 PM, Sean Gillies wrote:
> FWIW, here's the GeoDjango approach:
>
> http://code.djangoproject.com/browser/django/trunk/django/contrib/gis/geos/libgeos.py#L53
>
> and the Shapely approach:
>
> https://github.com/sgillies/shapely/blob/master/shapely/geos.py#L148
>
> Sha
Alright, I think it's all good. I posted to the ruby-ffi list and got
back a response already and the prognosis is good! See
http://groups.google.com/group/ruby-ffi/browse_thread/thread/836d6c772d8088dc
, wherein I picked up the science that Mr. Wayne Meissner laid down.
Apparently the garbage col
On Wed, Dec 15, 2010 at 2:38 AM, Charlie Savage wrote:
> Just noticed this, RGeo:
>
> http://www.daniel-azuma.com/blog/archives/28
>
> J - worth pinging them?
>
Yeah, I noticed that last night when I saw that someone else added
themselves to the github watch list on ffi-geos. I just dropped a lin
G'day list!
A couple of months ago I had posted[1] about some extensions to the
Ruby GEOS bindings that we at Zoocasa were interested in releasing as
free software. Well, I finally got a bit of time to finish up a
release, and the code and the gems have all been pushed to github and
rubygems.
Wit
On Wed, Apr 13, 2011 at 3:28 AM, Sandro Santilli wrote:
> Given PostGIS 2.0 is planned for June 15, I think it's worth having
> GEOS-3.3.0 out in time for it.
>
> See the NEWS file [1] for changes so far.
> [1] http://trac.osgeo.org/geos/browser/trunk/NEWS?rev=3265
>
> I've provisionally set miles
On Wed, Apr 13, 2011 at 11:21 AM, Charlie Savage wrote:
> Hi J,
>
> Once you're ready, we can do some testing (within our app) on Windows,
> Fedora, CentOS and OSX also.
>
> Is it worth creating a RubyGeo group on github and put the geos and proj4
> bindings - either the new ffi one I think you ha
G'day list.
I just wrapped up a (very) beta ruby gem for the ffi-geos library and
it is now available on rubygems.org for anyone curious to see how the
current state of affairs is stacking up. This is a very beta release
that weighs in at a staggering version 0.0.1.beta1, and features:
- a prefer
On Sun, Apr 17, 2011 at 4:57 PM, Charlie Savage wrote:
>
> So I haven't done this myself, but if I go to github and click "Switch
> Context" on the right then there is a choice to manage organizations. From
> there you can create a new one. What I'm not quite sure about is how to
> then migrate y
G'day list.
To mark the occasion of the GEOS 3.3.0 release candidate, I've pushed
a new version of the ffi-geos gem to github and rubygems. Changes from
the first beta release include:
- a few new methods like Geos::LineString#offset_curve and the latest
relationship methods on Geos::PreparedGeom
On Thu, May 12, 2011 at 2:19 AM, Sandro Santilli 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
On Thu, May 12, 2011 at 11:28 AM, Sandro Santilli wrote:
>
> 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.
>
I implemented a to_prepared method on Geos::Geometry which produc
On Thu, May 12, 2011 at 11:42 AM, Sean Gillies wrote:
>
> 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
>
Now that you mention it, I
On Thu, May 12, 2011 at 11:50 AM, Sandro Santilli wrote:
>
> 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
On Thu, May 12, 2011 at 12:48 PM, Sandro Santilli wrote:
> On Thu, May 12, 2011 at 09:46:00AM -0700, Daniel Azuma wrote:
>> Just a little opinion on this, as I'm actually starting to use ffi-geos. If
>> it is to be the de facto ruby binding for GEOS, it should expose the same
>> flexibility that
Hey list.
I finally got around to a "stable" release for ffi-geos on Ruby.
Featuring the staggering version number of 0.0.1, this release appears
to be pretty stable and "Good To Go". We've been using the extension
in production for a while now at work and things look pretty good, so
I figured tha
On Thu, Nov 24, 2011 at 1:08 PM, strk wrote:
> Can any Ruby/GEOS developer take a look at this ?
>
Perhaps it's getting time to start thinking of sunsetting the SWIG
extension for Ruby and let ffi-geos start to fill the void. We've been
using the ffi-geos extension in production for months now an
G'day geos-devel.
I'm working on a PHP project that requires the use of the GEOS PHP
extension. The GEOS PHP extension is rather tightly coupled with the
GEOS build system itself, and it makes it a bit cumbersome to use on
systems where there's already a GEOS package available but no separate
pack
e, but there might be some
grumbling from PECL potentially.
If that all sounds sane, I think this would be do-able. A longer-term
goal might be to do similar extractions for the Python and Ruby SWIG
wrappers, but I'll leave that for another day.
Cheers
On Wed, Jan 20, 2016 at 4:48 AM, Sa
On Wed, Jan 20, 2016 at 3:40 PM, Sandro Santilli wrote:
> On Wed, Jan 20, 2016 at 10:31:54AM -0500, J Smith wrote:
>
>> - "We strongly encourage contributors to choose the PHP License 3.01
>> for their extensions, in order to avoid possible troubles for
>> end-users
Quick update on the PHP extraction folks...
I've pushed a first pass to
https://github.com/libgeos/php-geos/tree/phpize . This branch contains
the following:
- build files that work with the phpize command.
- PECL/PEAR-style packaging files.
- geos.c has been updated to use #ifdefs to work with
ings sound familiar.
>
> I guess next stop would be having a "make check" in place,
> and then enabling build bots on github/gitlab (and possibly
> also jenkins, if Regina wants to help there).
>
> --strk;
>
> On Mon, Jan 25, 2016 at 06:24:00PM -0500, J Smith wrote:
&
t; On Thu, Jan 28, 2016 at 10:05:51AM -0500, J Smith wrote:
>> The standard PHP build for extensions comes with a `make test` target,
>> I'll have to check on `make check`. Would `make test` itself work? I
>> think some work could be done to make the tests a bit more
>> P
On Mon, Mar 7, 2016 at 4:45 AM, Sandro Santilli wrote:
> On Sun, Mar 06, 2016 at 07:50:20PM -0500, J Smith wrote:
>> G'day list. Just a quick update on the PHP GEOS extension.
>
> I've pulled your changes from the github master branch and
> tried building/checking b
On Mon, Mar 7, 2016 at 11:10 AM, Sandro Santilli wrote:
> On Mon, Mar 07, 2016 at 09:57:22AM -0500, J Smith wrote:
>> Hm, interesting, the tests all pass for me. Was there any output at
>> all?
>
> I sent you the whole output.
> Find a copy here: http://strk.keybit.net/t
On Tue, Mar 8, 2016 at 12:48 PM, Sandro Santilli wrote:
>>
>> Yeah, figured it out this morning -- I had forgotten to add the
>> TestHelper.php file to the repo. .gitignore was ignoring tests/*.php,
>> which the test runner produces during test runs, and so it was
>> ignoring TestHelper.php as wel
On Thu, Mar 10, 2016 at 5:02 PM, Sandro Santilli wrote:
>
> Also, the "make check" run ends with prompting me, which is really
> annoying. The prompt asks if I want to send the report to the PHP QA
> team. Really ? Should we send successful test run reports for a single
> package to "the PHP QA te
which the abstractions will
come in.
Cheers, list.
On Mon, Mar 21, 2016 at 5:15 AM, Sandro Santilli wrote:
> On Sun, Mar 20, 2016 at 07:48:46PM -0400, J Smith wrote:
>> On Thu, Mar 10, 2016 at 5:02 PM, Sandro Santilli wrote:
>> >
>> > Also, the "make check"
On Tue, Jul 19, 2016 at 2:35 PM, Sandro Santilli wrote:
> The official home of PHP bindings source code is now
> the Experiemental OSGeo Git Service:
>
> https://git.osgeo.org/gogs/geos/php-geos
>
> Previous GIT remote ( git://git.osgeo.org/php-geos )
> still works for backward compatibility but
On Fri, Jul 22, 2016 at 4:05 AM, Sandro Santilli wrote:
> On Thu, Jul 21, 2016 at 07:42:20PM -0300, J Smith wrote:
>
>> The current work is available at
>> https://github.com/dark-panda/php-geos-native/tree/php7 and I can push
>> it up to the new repo once I've been
On Wed, Jul 27, 2016 at 3:03 PM, Sandro Santilli wrote:
> On Tue, Jul 26, 2016 at 05:12:10PM -0300, J Smith wrote:
>
>> *
>> https://git.osgeo.org/gogs/geos/php-geos/commit/eb2341878f73a6bd042322d8e00ac47c322ab5bb
>> appears to break on my system, as configure doesn
G'day list.
I was taking a look at implementing Geos::STRTree#nearest in ffi-geos
today and noticed that there's no implementation in the CAPI for
GEOSSTRtree_nearest_r. Did this get lost in the shuffle somewhere?
Cheers
___
geos-devel mailing list
geos
On Thu, Nov 10, 2016 at 2:11 AM, Sandro Santilli wrote:
> On Thu, Nov 10, 2016 at 08:11:16AM +0100, Sandro Santilli wrote:
>> On Wed, Nov 09, 2016 at 05:15:04PM -0500, J Smith wrote:
>> > G'day list.
>> >
>> > I was taking a look at implementing Geos::S
On Thu, Dec 15, 2016 at 2:49 PM, Sandro Santilli wrote:
> Version 1.0.0rc2 of php-geos is available for download and test
> from https://git.osgeo.org/gogs/geos/php-geos/releases
>
> This new RC version brings in:
> - Support for PHP-5.4
> - Support for building against GEOS installed in non-cus
46 matches
Mail list logo
