On 09/06/11 12:53, Sandro Santilli wrote:
Every new release in the 3.x.x series is backward compatible at the C-API
level. PostGIS uses the C-API.
True. Plus new GEOS releases are invariably better (read as: more
robust) than their predecessors, so if you can go for this option I
would defin
On Thu, Jun 09, 2011 at 12:55:56PM +0200, Magnus Hagander wrote:
> On Thu, Jun 9, 2011 at 12:35, Sandro Santilli wrote:
> > The fix is in upgrading GEOS (3.3.0 is out).
> > If you can upgrade PostGIS you can also upgrade GEOS, right ?
>
> Uh, that sounds like a major version rather than a patch
On Thu, Jun 9, 2011 at 12:35, Sandro Santilli wrote:
> On Wed, Jun 8, 2011 at 8:58 PM, Magnus Hagander wrote:
>> On Tue, May 31, 2011 at 14:06, Magnus Hagander wrote:
>>> On Fri, May 27, 2011 at 21:07, Sandro Santilli wrote:
On Fri, May 27, 2011 at 09:28:57AM -0700, Paul Ramsey wrote:
On Wed, Jun 8, 2011 at 8:58 PM, Magnus Hagander wrote:
> On Tue, May 31, 2011 at 14:06, Magnus Hagander wrote:
>> On Fri, May 27, 2011 at 21:07, Sandro Santilli wrote:
>>> On Fri, May 27, 2011 at 09:28:57AM -0700, Paul Ramsey wrote:
I'm finding it difficult to have the regression test and a
On Tue, May 31, 2011 at 14:06, Magnus Hagander wrote:
> On Fri, May 27, 2011 at 21:07, Sandro Santilli wrote:
>> On Fri, May 27, 2011 at 09:28:57AM -0700, Paul Ramsey wrote:
>>> I'm finding it difficult to have the regression test and also the
>>> NOTICE in isvalid and also have the differential
On Fri, May 27, 2011 at 21:07, Sandro Santilli wrote:
> On Fri, May 27, 2011 at 09:28:57AM -0700, Paul Ramsey wrote:
>> I'm finding it difficult to have the regression test and also the
>> NOTICE in isvalid and also have the differential behaviour for
>> different versions of GEOS. One is going to
On Fri, May 27, 2011 at 09:28:57AM -0700, Paul Ramsey wrote:
> I'm finding it difficult to have the regression test and also the
> NOTICE in isvalid and also have the differential behaviour for
> different versions of GEOS. One is going to have to go. I can't
> ensure the "reason" I provide in my
On Thu, May 26, 2011 at 11:00 PM, Sandro Santilli wrote:
> On Thu, May 26, 2011 at 11:46:34AM -0700, Paul Ramsey wrote:
>> Like so?
>>
>> http://trac.osgeo.org/postgis/attachment/ticket/987/inf2.patch
>
> A few points:
>
> 1: GEOS-driven ST_IsValid raises a NOTICE containing the reason, home-made
http://trac.osgeo.org/postgis/attachment/ticket/987/inf3.patch
On Fri, May 27, 2011 at 9:28 AM, Paul Ramsey wrote:
> I'm finding it difficult to have the regression test and also the
> NOTICE in isvalid and also have the differential behaviour for
> different versions of GEOS. One is going to hav
I'm finding it difficult to have the regression test and also the
NOTICE in isvalid and also have the differential behaviour for
different versions of GEOS. One is going to have to go. I can't
ensure the "reason" I provide in my short circuit to match the reason
GEOS is going to give.
On Thu, May
On Thu, May 26, 2011 at 11:46:34AM -0700, Paul Ramsey wrote:
> Like so?
>
> http://trac.osgeo.org/postgis/attachment/ticket/987/inf2.patch
A few points:
1: GEOS-driven ST_IsValid raises a NOTICE containing the reason, home-made
version should do the same.
2: I see you're not handling nan, jus
Like so?
http://trac.osgeo.org/postgis/attachment/ticket/987/inf2.patch
On Thu, May 26, 2011 at 11:35 AM, Paul Ramsey wrote:
> I think I'd like to do option (b), leave in the deep check for Inf and
> put upper level checks for Inf in the IsValid* calls. I've put all the
> above code in checks fo
I think I'd like to do option (b), leave in the deep check for Inf and
put upper level checks for Inf in the IsValid* calls. I've put all the
above code in checks for GEOS_VERSION < 33 so that it'll go dark as we
move forward. Sound OK?
p.
On Thu, May 26, 2011 at 10:42 AM, Sandro Santilli wrote:
On Thu, May 26, 2011 at 07:26:25PM +0200, Sandro Santilli wrote:
> On Thu, May 26, 2011 at 09:51:12AM -0700, Paul Ramsey wrote:
> > On Thu, May 26, 2011 at 9:44 AM, Sandro Santilli wrote:
> > > On Thu, May 26, 2011 at 09:26:15AM -0700, Paul Ramsey wrote:
> > > > Erm, do old versions of IsValid sti
On Thu, May 26, 2011 at 09:51:12AM -0700, Paul Ramsey wrote:
> On Thu, May 26, 2011 at 9:44 AM, Sandro Santilli wrote:
> > On Thu, May 26, 2011 at 09:26:15AM -0700, Paul Ramsey wrote:
> > > Erm, do old versions of IsValid still catch Inf geometries safely?
> >
> > If you have an HEXWKB I can give
010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD4540737979F3DDCC2CC0F92154F9E7534540
On Thu, May 26, 2011 at 9:44 AM, Sandro Santilli wrote:
> On Thu, May 26, 2011 at 09:26:15AM -0700,
On Thu, May 26, 2011 at 09:26:15AM -0700, Paul Ramsey wrote:
> Erm, do old versions of IsValid still catch Inf geometries safely?
Not sure, worth testing.
If you have an HEXWKB I can give it a quick try against 3.1.0
--strk;
() Free GIS & Flash consultant/developer
/\ http://strk.keybit.
Erm, do old versions of IsValid still catch Inf geometries safely?
On Thu, May 26, 2011 at 9:05 AM, Sandro Santilli wrote:
> On Thu, May 26, 2011 at 08:12:19AM -0700, Paul Ramsey wrote:
>> OK then either
>> (a) we test for Inf boxes at the head of each GEOS function we care
>> about protecting (a
On Thu, May 26, 2011 at 08:12:19AM -0700, Paul Ramsey wrote:
> OK then either
> (a) we test for Inf boxes at the head of each GEOS function we care
> about protecting (and not IsValid* functions)
> (b) we put a pre-test in the IsValid* functions to check for Inf boxes
> Preferences?
I like (a) mor
With the disclaimer of not having looked at the code, I like (b). I
assume you mean that in the path of isvalid*, we pick up the same
check and return the proper thing. But we still keep the check you put
in with your patch, so that if we enter them some other way, or if the
test in isvalid* goes w
OK then either
(a) we test for Inf boxes at the head of each GEOS function we care
about protecting (and not IsValid* functions)
(b) we put a pre-test in the IsValid* functions to check for Inf boxes
Preferences?
P.
On Thu, May 26, 2011 at 7:21 AM, Magnus Hagander wrote:
> On Thu, May 26, 2011 at
On Thu, May 26, 2011 at 16:20, Sandro Santilli wrote:
> On Thu, May 26, 2011 at 04:16:59PM +0200, Magnus Hagander wrote:
>> On Thu, May 26, 2011 at 16:15, Sandro Santilli wrote:
>> > On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote:
>> >> Hi!
>> >>
>> >> Yup, it does appear to solv
On Thu, May 26, 2011 at 04:16:59PM +0200, Magnus Hagander wrote:
> On Thu, May 26, 2011 at 16:15, Sandro Santilli wrote:
> > On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote:
> >> Hi!
> >>
> >> Yup, it does appear to solve the problem for at least my limited test
> >> case. I now ge
On Thu, May 26, 2011 at 16:15, Sandro Santilli wrote:
> On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote:
>> Hi!
>>
>> Yup, it does appear to solve the problem for at least my limited test
>> case. I now get:
>> ERROR: Infinite coordinate value found in geometry.
>> CONTEXT: SQL f
On Thu, May 26, 2011 at 04:09:27PM +0200, Magnus Hagander wrote:
> Hi!
>
> Yup, it does appear to solve the problem for at least my limited test
> case. I now get:
> ERROR: Infinite coordinate value found in geometry.
> CONTEXT: SQL function "st_intersects" statement 1
>
> as expected.
>
> Gla
Hi!
Yup, it does appear to solve the problem for at least my limited test
case. I now get:
ERROR: Infinite coordinate value found in geometry.
CONTEXT: SQL function "st_intersects" statement 1
as expected.
Glad to see you found a better place :-)
//Magnus
On Wed, May 25, 2011 at 21:11, Paul
Magnus,
We've decided to go with Inf testing, but I've move the test lower
down into the GEOS handling code so it applies to all GEOS operations,
not just Intersects().
http://trac.osgeo.org/postgis/ticket/987
See if that still works for you, hopefully it should (just tested with
your test geomet
On Tue, Mar 8, 2011 at 10:16, Magnus Hagander wrote:
> On Mon, Feb 28, 2011 at 16:35, Mark Cave-Ayland
> wrote:
>> On 28/02/11 15:18, Magnus Hagander wrote:
>>
>>> Hi!
>>>
>>> Running the following query locks up postgis completely (in
>>> geos::algorithm::RobustDeterminant):
>>>
>>> SELECT st_in
On 10/03/11 15:13, Magnus Hagander wrote:
What was the discussion with the GEOS people like? Did they consider this to
be a bug in GEOS or a bug in PostGIS?
Ugh. Re-reading the thread, I realize I've misunderstood this. I
thought both issues were "in the same way", but I see now once was
geos
On Wed, Mar 9, 2011 at 16:46, Mark Cave-Ayland
wrote:
> On 08/03/11 09:16, Magnus Hagander wrote:
>
>> Since nobody appears to be too interested in producing a quick fix in
>> geos, attached is a patch that puts in an *ugly* workaround in
>> PostGIS, that simply rejects the infinite values higher
On 08/03/11 09:16, Magnus Hagander wrote:
Since nobody appears to be too interested in producing a quick fix in
geos, attached is a patch that puts in an *ugly* workaround in
PostGIS, that simply rejects the infinite values higher up in the
stack. I don't consider this a long-term fix, but it at
On Mon, Feb 28, 2011 at 16:35, Mark Cave-Ayland
wrote:
> On 28/02/11 15:18, Magnus Hagander wrote:
>
>> Hi!
>>
>> Running the following query locks up postgis completely (in
>> geos::algorithm::RobustDeterminant):
>>
>> SELECT st_intersects(somegeometry,
>>
>> '010320E6100100050073
On 28/02/11 15:18, Magnus Hagander wrote:
Hi!
Running the following query locks up postgis completely (in
geos::algorithm::RobustDeterminant):
SELECT st_intersects(somegeometry,
'010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C03
Hi!
Running the following query locks up postgis completely (in
geos::algorithm::RobustDeterminant):
SELECT st_intersects(somegeometry,
'010320E61001000500737979F3DDCC2CC0F92154F9E7534540F07FF07F8F806E993F7E55C0304B29FFEA8554400634E8D1DD424540B5FEE6A37FCD45
34 matches
Mail list logo
