Sorry for the barrage of questions lately! But suddenly PostGIS is
becoming extremely useful to my day-to-day activities. So congrats on
a fantastic product that is letting me (thus far) skip on purchasing
any ESRI software.
Questions:
1) Given N polygons in a table called A, and another table of
Yes, I absolutely agree - SPLIT BY should take "Inverse Aggregate"
functions, which can be provided for *any* complex object. The example
they give in the Manifold doc is classic - split a string into "chunks"
at given characters (or regexes...). It's funny that they give that
example - but i
You called it.
Obe, Regina wrote:
...
Looking at Kevin's results I am beginning to think the bottleneck may be
in the GeomN type functions and maybe he is right that its doing a copy
call for each or something silly like that or a memory leak (I wasn't
looking is it linear or quadratic as the n
I remember looking at Manifold's SPLIT BY function and thinking -
"that's what I'm missing in my life - a inverse GROUP BY."
I was disappointed to find out that there SPLIT BY only supports 3
split functions which makes it much more limiting than the
generate_series approach. It makes nice synt
Obe, Regina wrote:
Not sure the answer to your questions since I don't know much about
the internals of PostgreSQL. I always assumed by ref for large objects.
We could try to force it to calculate the numpoints call only once and
see if it makes a difference in timings
Something of the for
This is an interesting problem. I think the general pattern can be
stated as something like: "Split a complex column value across multiple
rows, along with other columns from the original record". (A nice way
of thinking of this is that it's the inverse of GROUP BY).
This is surprisingly awk
Not sure the answer to your questions since I don't know much about the
internals of PostgreSQL. I always assumed by ref for large objects.
We could try to force it to calculate the numpoints call only once and see if
it makes a difference in timings
Something of the form
SELECT pointn(t
Hi Regina,
Unfortunately, I don't think your solution works. I performed some
tests extracting points from a linestring (instead of a geometry from a
collection - generate_series has the same performance problems).
I took three linestrings, with ~5000, ~1, and ~2 points and
tried to
Not to mention transform support. Last I tried you can't transform
circular strings.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bruce Rindahl
Sent: Friday, April 18, 2008 11:50 AM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] Three
Paul
Do we have any documentation on this? I checked latest but there is
limited info there.
This is a great post but I don't think anyone answered it.
http://postgis.refractions.net/pipermail/postgis-devel/2007-September/002778.html
I would love to add this to the asSVG since SVG handles cir
Use the CIRCULARSTRING type, and the ST_CurveToLine(geometry) function
to convert it to a linestring.
CREATE TABLE test ( GEOM geometry );
INSERT INTO test VALUES ('CIRCULARSTRING(0 0, 1 1, 2 0)');
SELECT ST_AsText(ST_CurveToLine(geom)) FROM test;
P
On Fri, Apr 18, 2008 at 7:53 AM, JohanNL <[EM
Hi All,
I have a question. I need to store an Arc into a postgis database. As far as
I know, Postgis doens't support arcs. Is there another way to convert a
Three Point Arc to a MultiLineString?
Best regards,
Johan.
--
View this message in context:
http://www.nabble.com/Three-point-ARC-to-MUL
Can you re-build GEOS and run "make test"? The problem seems to be a
symbol that GEOS can't find rather than one lwpostgis can't find.
P
On Fri, Apr 18, 2008 at 3:09 AM, Ronald Woita <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I have a problem loading the lwpostgis.sql into a database.
> (plpgsql
I know there has been some discussion in the past about how
generate_series doesn't scale well when you are dealing with large
numbers of geometries. My suspicion was that it was because
generate_series has to materialize the result before outputting it and
that the result key is not indexed.
Unf
Hi list,
I have a problem loading the lwpostgis.sql into a database.
(plpgsql is already loaded)
this is the message from Postgres-Serverlog :
-->
NOTICE: type "histogram2d" is not yet defined
DETAIL: Creating a shell type definition.
ERROR: could not load library "/usr/local/pgsql/lib/liblwg
wow, that sounds pretty funky!
doesn't the unioning etc kill your performance advantage?
have you done any benchmarking to quantify the performance of this solution?
do you have lots of user behavior rules?
the system that we are building on will be managed pretty de-centralized, so
if everyone ha
16 matches
Mail list logo
