Thanks for the quick answers!
Yes, I see the problem there Rémi-C, but my data set stretches from ~60 000 to
600 000 in east (x-) coordinate, so that would be more useful for north (y-)
coordinate. Tried a few different values, but in those cases the computation
crashes some where else. Or am I
That's really quite disturbing, since it would seem to indicate that
even the core algorithms are messed up. And yet you say 2.0 was fine?
Because _ST_DistanceUncached is functionally "I want 2.0" (brute force
algorithm all the time).
In other news, do try the 2.1 SVN branch, it contains a fix for
Paul,
Unfortunately, when we use the _ST_DistanceUncached via the _st_distance()
stored procedure change, we start to see failures in other places. As I
said, I am trying to isolate them, but the failures that we start to see
are fairly random: the initial issue is fixed, but we start to receive
Jerry,
Pretty important to isolate them, as that function's at the bottom of
the cached tree algorithm, so even if I fix the gap in the cache logic
I think I have found, you'll still run into other issues later.
_ST_DistanceUncached uses brute force (aka 2.0) methods, and should
work without chan
Pretty sure I have this one tracked, will update shortly.
On Mon, Feb 3, 2014 at 12:55 PM, Jerry Sievert
wrote:
> The workaround as provided exposes multiple other issues for us. I can try
> to isolate them, but essentially it causes random looking test failures in
> our app.
>
> On Feb 1, 2014,
The workaround as provided exposes multiple other issues for us. I can try to
isolate them, but essentially it causes random looking test failures in our app.
> On Feb 1, 2014, at 6:55 PM, "Paragon Corporation" wrote:
>
> Jerry,
> We know it's a PostGIS bug. The bug I think came in 2.1.0. It
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi list,
I'm running two database cluster with PostGIS 1.5 and PostgreSQL 9.1
on FreeBSD 9.2-RELEASE-p3 and apparently my PostGIS is a little bit
outdated.
Now the plan is to upgrade both PostGIS to 2.1 and PostgreSQL to 9.3,
which are the latest vers
On Mon, Feb 03, 2014 at 11:29:13AM +0100, Rémi Cura wrote:
> By the way Sandro,
>
> don't you think that Geos should automatically translate the whole input
> using a pivot point ?
> It would of course be difficult when getting data pieces by pieces (like in
> aggregates),
> but when the whole dat
By the way Sandro,
don't you think that Geos should automatically translate the whole input
using a pivot point ?
It would of course be difficult when getting data pieces by pieces (like in
aggregates),
but when the whole data is available, why not?
It would considerably help toward reducing the
On Mon, Feb 03, 2014 at 10:54:13AM +0100, Rémi Cura wrote:
> Hey,
> you use far too big coordinates.
> Please consider using st translate on your data, then curve offset, then
> inverse translate.
Speaking of which, this treatment is one of those performed on catching
an exception in binary operat
Oups I put a -15 translation in above example, it also works for -16 of
course like required.
Cheers,
Rémi-C
2014-02-03 Rémi Cura :
> Hey,
> you use far too big coordinates.
> Please consider using st translate on your data, then curve offset, then
> inverse translate.
> This is mandatory (when
Hey,
you use far too big coordinates.
Please consider using st translate on your data, then curve offset, then
inverse translate.
This is mandatory (when using so many digits, you artificially increase the
need for precision in numeric computing, which is problematic).
It is true for all computati
On Mon, Feb 03, 2014 at 11:43:37AM +0300, jakob ventin wrote:
> Hello all,
> I am using ST_OffsetCurve function to calculate offsets for lines and
> polygons. I have a quit large amount of data, several tens of thousands of
> features which I have to do these calculations for in an automated proc
Hello all,
I am using ST_OffsetCurve function to calculate offsets for lines and polygons.
I have a quit large amount of data, several tens of thousands of features which
I have to do these calculations for in an automated processs. Now I have run
into a problem: St_OffsetCurve crashes for some
Hi,
QGis should not deal with Postgre SQl explicit primary keys.
It is postgreSQL to manage the explicit primary key.
With Qgis 1.7.4, copy/paste with explicit primary keys where ok
If QGis 1.7.4 sends a unique primary key, PostgreSQL accept it, if the
explicit key is not unique, it reject it.
15 matches
Mail list logo
