. it does no file I/O).
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dane
Springmeyer
Sent: Monday, August 18, 2008 3:22 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] PostGIS 1.3.3 on Windows XP Unstable
Regina,
To use the
2208.7465780092134
Length 0.013284095041776186 733.3902842391406 8.213194606088345
2250.4153220682065
Signed,
Very confused Regina
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
] On Behalf Of Bresnahan, Mike
Sent: Monday, August 18, 2008 10:12 AM
To: PostGIS Users Discussion
Subject: RE: [postgis-us
till have a
lot of inefficiencies I'm missing.
Thanks,
Regina
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bresnahan, Mike
Sent: Thursday, August 14, 2008 7:45 PM
To: PostGIS Users Discussion
Subject: RE: [postgis-users] PostGIS 1.3.3 on Windows XP
6186733.3902842391406
8.213194606088345 2250.4153220682065
Signed,
Very confused Regina
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bresnahan, Mike
Sent: Monday, August 18, 2008 10:12 AM
To: PostGIS Users Discussion
Subject: RE: [postgi
: [postgis-users] PostGIS 1.3.3 on Windows XP Unstable
Isn't a Union supposed to merge all polygons in one? The only thing I
get to do this in ArcView is the "Merge" and that's also the
functionality I get from ST_Union.
Btw, for ST_Union'ing many complex polygons I
Isn't a Union supposed to merge all polygons in one? The only thing I get to
do this in ArcView is the "Merge" and that's also the functionality I get
from ST_Union.
Btw, for ST_Union'ing many complex polygons I'm using CascadedUnion as
written here:
http://postgis.refractions.net/pipermail/postgi
> How the hell do you get it to do a real union?
Heh. Intuitive ArcMap is not. It took me forever to figure it out as well. You
can do a union a couple different ways. The way that seemed to work the best
for this is to:
1) Run ArcMap
2) Add the shapefile to your map
3) Open the edit toolbar.
Of Martin
Davis
Sent: Thursday, August 14, 2008 8:12 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] PostGIS 1.3.3 on Windows XP Unstable
You're right about how the current PostGIS union works.
The CascadedUnion algorithm in JTS uses spatial indexing and some other
heuristics to o
You're right about how the current PostGIS union works.
The CascadedUnion algorithm in JTS uses spatial indexing and some other
heuristics to obtain very fast performance.
The Java2D approach that you give is similar to the buffer(0) trick that
was the recommended way to do fast unioning prio
Quite possibly... at the moment Java's memory mngmt is beating out the
memory handling in GEOS.
Bresnahan, Mike wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
The original code for ST_SimplifyPreserveTopology comes from JTS. You
can either use the library directly, or try JEQL fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> The original code for ST_SimplifyPreserveTopology comes from JTS. You
> can either use the library directly, or try JEQL for a command-line
> interface to it. You can find both at http://tsusiatsoftware.net/
Ah ha, I see that now. Do you think t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> FWIW: The unioning operations currently in PostGIS are very
inefficient.
Do I guess right that PostGIS iterates over each geometry and unions it
with the result of all previous geometries, something like this:
java.awt.geom.Area area
Mike ,
I just tested this layer with a draft version of our new unioning approach.
- it completes in 10 seconds. Not great but better than the current
ST_Union approach.
In OpenJump by the way which is using a not quite as sophisticated algorithm
as Martin's cascaded union, the below completes i
Yes, Java2D was able to perform a union on the geometries produced by
ST_SimplifyPreserveTopology() and it does the union relatively fast.
The only thing I have found that beats Java2D is ArcGIS. In one test I
did I performed a union of the USGS state boundaries
(http://www.census.gov/geo/cob
The bottleneck in my application now looks to be
ST_SimplifyPreserveTopology(). I'm finding that it's often best to do
computation outside the database. However, one thing that Java2D is
missing is a polygon simplification function. I might look to see if
Geotools has one.
The original code
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> It's your bad luck to have geometries that make PostGIS fail... 8^)
>
> If there's geometries which cause problems with certain operations,
the
> most helpful thing to do is to post them along with a description of
the
> problem. That gives a f
ssion
Subject: Re: [postgis-users] PostGIS 1.3.3 on Windows XP Unstable
It's your bad luck to have geometries that make PostGIS fail... 8^)
If there's geometries which cause problems with certain operations, the most
helpful thing to do is to post them along with a description of the proble
It's your bad luck to have geometries that make PostGIS fail... 8^)
If there's geometries which cause problems with certain operations, the
most helpful thing to do is to post them along with a description of the
problem. That gives a fighting chance to fix them when further
development is
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Welp, I think I have given up on trying to do the union inside PostGIS
because I can't make it fast and reliable. Instead I have decided to use
Java2D to perform the union. I ended up doing the same thing with
Oracle. Both Oracle and PostGIS have bee
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> Union will have the desired effect, but it isn't the most efficient
way
> of dealing with the problem. The most efficient way is to iterate
over
> all the polygons in the MultiPolygon, and drop any which are contained
> in another one in the set.
Union will have the desired effect, but it isn't the most efficient way
of dealing with the problem. The most efficient way is to iterate over
all the polygons in the MultiPolygon, and drop any which are contained
in another one in the set.
Bresnahan, Mike wrote:
-BEGIN PGP SIGNED MESSA
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> Martin Davis wrote:
> That's what it means, alright. It is invalid to have one polygon
inside
> another one in the same MultiPolygon. (If you post the invalid
geometry
> I can confirm that this is what is happening).
>
> Bottom line is that you
Bresnahan, Mike wrote:
I'm almost there. The function works beautifully except on a few
geometries. These geometries produce messages like the following when I
call ST_IsValid:
NOTICE: Nested shells at or near point -76.554 38.8815
I'm not sure what "nested shell" means. At first thought it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> Would probably be more efficiently done with
>
> SELECT gid, ST_Collect(ScrubPolygon(geom)) As scrubbedgeom
> FROM
> (SELECT gid, (ST_Dump(the_geom)).geom
> FROM tabletoscrub) As foo
> GROUP By gid ;
>
> The reason be
are done.
Hope that helps,
Regina
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Bresnahan, Mike
Sent: Tuesday, August 12, 2008 8:42 PM
To: PostGIS Users Discussion
Subject: RE: [postgis-users] PostGIS 1.3.3 on Windows XP Unstable
-BEGIN PGP SIGNED
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Martin Davis said at Monday, August 11, 2008 6:07 PM:
> This is a known design flaw in the SimplifyTP algorithm. The problem
is
> that with large tolerance values small holes and shells can wind up on
> the "wrong side" of a containing geometry.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> For any and all geometries, or do you have cases? (we love cases...)
I appended a test case to http://trac.osgeo.org/geos/ticket/187.
-BEGIN PGP SIGNATURE-
Version: PGP Universal 2.8.3
Charset: us-ascii
wsBVAwUBSKDI8x6WPRoYuvd0AQgPdAf9H
well,... hm. Could you put this into trac so we don't lose it? Best
would be in the GEOS trac, actually (http://trac.osgeo.org/geos) Once
you get into really large tolerances, preserving topology starts to
get problematic, for hopefully obvious reasons... I'm not sure how
robust Martin's routin
OK, that's interesting, as Buffer is usually pretty tolerant of
invalidity... but not completely tolerant. Perhaps you can extract
just one case for us, since if it's happening on all your cases it's
probably the same issue every time.
P.
On Mon, Aug 11, 2008 at 1:46 PM, Bresnahan, Mike
<[EMAIL P
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> For any and all geometries, or do you have cases? (we love cases...)
I can try to put together some test cases, however I have to be
sensitive to the proprietary nature of the data. The problem has
occurred with every geometry I have tried that is
On Mon, Aug 11, 2008 at 1:25 PM, Bresnahan, Mike
<[EMAIL PROTECTED]> wrote:
> 1) When I call buffer() with a value other than zero, postgres.exe
> consumes RAM progressively until my machine begins to thrash and I am
> forced to power cycle it. My machine has 3G of RAM.
For any and all geometries
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Thanks for the responses.
> Which version of Geos are you running?
"POSTGIS="1.3.3" GEOS="3.0.0-CAPI-1.4.1" PROJ="Rel. 4.6.0, 21 Dec 2007"
USE_STATS"
I've run into 2 more problems.
1) When I call buffer() with a value other than zero, postgres.e
Mike,
If it was in general unstable, we would be hearing a lot more noise on
the list. I think you've just lucked into a couple bad/difficult
geometry cases. Your buffer case sounds like the one here:
http://trac.osgeo.org/geos/ticket/188 so hopefully it'll be patched up
in the next release. Your
Mike,
PostGIS 1.3.3 has been pretty stable for me on Windows XP, Windows 2003 and Red
Hat EL Linux.
Though I can't say I have ever tried using disjoint since there are much more
efficient ways of checking for disjointedness than using disjoint. Buffer(..0)
I have used a fair amount though and
34 matches
Mail list logo
