right either since it is
> assuming straight lines. One other option to confirm is to transform your
> data to a suitable space preserving California planar (meter or foot)
> spatial ref sys that covers your fload zone and confirm the answers are
> still the same.
>
>
>
> *Fr
: [postgis-users] ST_Intersects on geography in WHERE clause returns
wrong results
Dear PostGIS users,
I am running a simple point-in-polygon analysis on Orange County flood zone
polygons. I noticed that I'm getting some false positives when running
ST_Intersects on geography in the where c
Lucky me! Thanks for the confirmation. Emily
On 2022-02-11 2:19 p.m., Paul Ramsey wrote:
This issue has been confirmed on both GEOS and JTS. You have magic geometry
that breaks the consistency between prepared and standard results.
https://github.com/libgeos/geos/pull/566
P.
On Feb 10, 202
It seems to be predicate robustness failure week! The geometries in this
recent post show the same problem (in JTS, and probably GEOS too).
https://lists.osgeo.org/pipermail/postgis-users/2022-February/045255.html
A: LINESTRING (-29796.696826656284 138522.76848210802, -29804.3911369969
138519.35
This issue has been confirmed on both GEOS and JTS. You have magic geometry
that breaks the consistency between prepared and standard results.
https://github.com/libgeos/geos/pull/566
P.
> On Feb 10, 2022, at 6:43 PM, Emily Gouge wrote:
>
> Here you go. Thanks!
>
>
> SELECT ST_AsHEXEWKB (g
Here you go. Thanks!
SELECT ST_AsHEXEWKB (geometry) FROM test.eflowpath WHERE id =
'889105be-5782-43f1-b50c-5a5825c83875'
01022009120700642F25DC75A24CC0E4DE5740FCB34840A7CEFE9B72A24CC09DA85B2CFBB34840B5519D0E64A24CC091FAA188FBB34840FA449E245DA24CC054C2137AFDB34840F4ACFFCE51A24CC0
> On Feb 10, 2022, at 4:55 PM, Emily Gouge wrote:
>
> I have a linear dataset on which I was building a query to find edges that
> are “very close” but don’t touch. While working on this query I found some
> unexpected results with the st_intersects and st_disjoint functions. As
> outlined b
I have a linear dataset on which I was building a query to find edges
that are “very close” but don’t touch. While working on this query I
found some unexpected results with the st_intersects and st_disjoint
functions. As outlined below, the query returned true for both
st_instersects and st_di
209, 15.193315]}')::geography);
>
> Returns 1 as expected.
>
> This also works:
>
> SELECT id FROM whosonfirst WHERE ST_Intersects(geom::geometry,
> ST_GeomFromGeoJSON('{"type": "Point",
> "coordinates": [145.748209, 15.193315]}')
WHERE ST_Intersects(geom::geometry,
ST_GeomFromGeoJSON('{"type": "Point",
"coordinates": [145.748209, 15.193315]}')::geometry);
Returns 1
SELECT ST_NPoints(geom) from whosonfirst;
Returns:
36822
Hope that helps,
Regina
-----Original Message-
From: postgis-
Hi,
Apologies if this has been answered elsewhere already. If it has I've
not been able to find it.
We are using PGIS to do point-in-poly lookups and having trouble
involving certain very large records.
SELECT version();
version
---
Hello,
I need to be able to perform an ST_intersects with a geometry that could be a
GeometryCollection.
I understand this is not supported from the PostGis documentation so I have
written this query:
select t.geometry
from schema.table t
where (st_intersects(t.geometry, st_collectionextract(
Hi Giuseppe,
Thanks for your response. I've now tried with Explain Analyze - runtime was
16.5 minutes. Below is the output:
"Bitmap Heap Scan on polygon_active (cost=36754.62..2156740.85 rows=403481
width=358) (actual time=160971.128..991459.050 rows=920180 loops=1)"
" Recheck Cond: (geom &&
Hi Jonathan,
2017-03-17 13:18 GMT+01:00 Jonathan Moules :
> Hi List,
> I'm doing a simple ST_Intersects:
>
> select geom
> from TABLENAME
> where
> ST_Intersects(geom, ST_GeomFromText('POLYGON((26 655000, 26
> 66, 27 66, 27 655000, 26 655000))', 27700))
>
>
Hi List,
I'm doing a simple ST_Intersects:
select geom
from TABLENAME
where
ST_Intersects(geom, ST_GeomFromText('POLYGON((26 655000, 26 66,
27 66, 27 655000, 26 655000))', 27700))
TABLENAME does have a spatial index. But this query is still taking an
ST_Relate ignores all the Z coordinates. So if you want to see what the
reasoning is, just strip them away. Results for invalid inputs are not
guaranteed to have any meaning.
P.
On Mon, Dec 12, 2016 at 6:33 AM, Felix Kunde wrote:
> Hi everybody,
>
> I have a general question about the behaviour
Hi everybody,
I have a general question about the behaviour with 2D lines intersecting 3D
polygons. In my example I want to filter walls of a building which are crossed
by a shortest line between address point and street geometry. When regarded in
2D most 3D polygons are invalid, of course. Th
If your data model expects strict containment (all parcels must be in
only one zone) then the simplest thing is to proxy the parcel polygon
with a point, then you get a guaranteed 1:1 relationship between
parcel and zone. Using ST_PointOnSurface() is required since
ST_Centroid() is not guaranteed t
Hey, if you want to do it the robust way,
you can use a shared surface distance :
for instance, ST_area(ST_Intersection(A,B)) / ST_Area(A)
where A is you polygon, and B your zoning information.
If everything is snapped, you could also use topology.
Cheers,
Rémi-C
2016-05-25 3:45 GMT+02:00 Paul
On 5/24/2016 6:31 PM, Timothy Asquith wrote:
- I’m experimenting with ST_Snap and filtering out ST_Touches, but
it still returning the same 3 results
You may want to use the dimensionally extended 9 intersection model
(http://postgis.net/docs/manual-2.2/using_postgis_dbmanagement.html#DE-
Thanks Paul,
You’re absolutely right that the intersect query should always have returned
touching polygons. I’m not sure how we were ever getting the desired results.
That’s what I’m looking into now.
Interestingly, the critical difference seems to be the use of binary geometry.
The land parc
The question is not why ST_Intersects() is returning boundary touching
results, it's why your old version did not (at least, as far as you
observed). Because, ST_Intersects(A,B) is *supposed* to return true
for any object B that is not disjoint from A. So, either you were not
observing what you tho
I have a table of land parcels in my PostGIS database, and I'm doing a basic
spatial join against zoning polygons.
I'm having issues where a previously-correct query is now returning different
results.
Up until now, I've been using a Geoserver WFS, and making these queries using
CQL's INTERSEC
-boun...@lists.osgeo.org] On Behalf Of Mike Toews
Sent: Thursday, February 19, 2015 2:47 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users] ST_intersects query that crosses date line
boundaries
Hi Trang,
Geometry types work in Cartesian space, and don't know what happens when Y
coordinates
;
Sent: Friday, February 20, 2015 10:57 AM
Subject: [postgis-users] ST_intersects query that crosses date line boundaries
Hi,
I am using Postgres 9.3 and have a table with geometry columns: startloc
geometry(Point), endloc geometry(Point), When I run a query that crosses
the date
Hi Trang,
Geometry types work in Cartesian space, and don't know what happens
when Y coordinates cross the antimeridian at -180/+180. Try
experimenting with the geography type, which works with some, but not
all PostGIS functions. ST_Intersects should work on geography types
for your example, e.g.
Hi,
I am using Postgres 9.3 and have a table with geometry columns:
startloc geometry(Point),
endloc geometry(Point),
When I run a query that crosses the date line boundary, I'm getting incorrect
results. Example:
SELECT * from od1.trip_v1_partitioned where startts>=TIMESTAMP
'2015-02-16T20
On Wed, Feb 11, 2015 at 02:25:08PM -0500, Rhys A.D. Stewart wrote:
> Greetings all,
>
> I am working on a set of data where I have noded linestrings. All
> linestrings have just two points and the nodes were derived from the
> endpoints.
>
> I've found one instance where st_intersects and st_equa
Greetings all,
I am working on a set of data where I have noded linestrings. All
linestrings have just two points and the nodes were derived from the
endpoints.
I've found one instance where st_intersects and st_equals return the
incorrect value (AFAICT).
==
select
have any issues by omitting the SRID.
Regards,Joseph Spenner
From: Hugues François
To: joseph85...@yahoo.com; postgis-users@lists.osgeo.org
Sent: Thursday, January 8, 2015 8:35 AM
Subject: Re: [postgis-users] ST_Intersects ST_GeomFromGeoJSON syntax
Hi,
You're using different sri
.5) you can use st_transform:
ST_Intersects(ST_Transform(ST_GeomFromGeoJSON($var),),geom)
Where is the SRID you want to use.
Regards,
Hug
Original Message
From: Joseph Spenner
Sent: Thursday, January 8, 2015 04:06 PM
To: PostGIS Users Discussion
Subject: Re: [postgis-users
x27;t think that
is the problem. There's maybe something still wrong with the syntax.
Thanks again for your help. I think it is very close!
Regards,Joseph Spenner
From: Hugues François
To: Joseph Spenner ; PostGIS Users Discussion
Sent: Thursday, January 8, 2015 1:44 AM
Subject:
users-boun...@lists.osgeo.org] De la part de Joseph Spenner
Envoyé : mercredi 7 janvier 2015 17:30
À : PostGIS Users Discussion
Objet : Re: [postgis-users] ST_Intersects ST_GeomFromGeoJSON syntax
More info. Here are my 2 select statements.
This one works:
$sth = $dbh->prepare("select
explicit type casts. at ./alertPoly2.cgi line 103.
--
Any help would be great.
Thanks!
From: Hugues François
To: Joseph Spenner ; PostGIS Users Discussion
Sent: Wednesday, January 7, 2015 1:17 AM
Subject: Re: [postgis-users] ST_Intersects ST_GeomFromGeoJSON synta
ame thing, but use a GeoJSON string as the input
instead, and return all stored polys which intersect.
Is this possible?
Thanks!
Regards,Joseph Spenner
From: Hugues François
To: Joseph Spenner ; PostGIS Users Discussion
Sent: Wednesday, January 7, 2015 1:17 AM
Subject: Re: [postgis-
s.org/docs/ST_GeomFromGeoJSON.html.
HTH
Hugues.
Message d'origine
De: postgis-users-boun...@lists.osgeo.org de la part de Joseph Spenner
Date: mar. 06/01/2015 20:31
À: PostGIS Users Discussion
Objet : [postgis-users] ST_Intersects ST_GeomFromGeoJSON syntax
Hello,I currentl
Hello,I currently have a select which works correctly:
$sth = $dbh->prepare("select ST_Asgeojson( geom ) from polys where
ST_Intersects(ST_GeomFromText('POLYGON(($textPoly, $closingLon $closingLat))',
4269), geom)=TRUE");
I'm trying to do the same thing, using FromGeoJSON instead of Text. Belo
Bonjour,
(petite apparté : j'imagine que ce n'est pas ce que vous voulez entendre,
mais il est catastrophique de donner des noms génériques aux colonnes
(field1, field2), d'autant que vous suggérez qu'il y ait un ordre dans les
colonnes (pas le cas). Pourquoi ne pas les appeller X,Y,Z (ce que ça a
Bonjour,
Merci à vous pour vos conseils. Vous aviez raison. En utilisant le layer
départements la requete fut bien plus rapide. J'ai donc écrit cette requete
:
-
CREATE TABLE example_intersections_a_v2 AS
SELECT part_2.geom,field_1,field_2,field_3
FROM fra_adm2 AS part_1,france_merge_
Bonjour,
on aurait gagné du temps avec cette info dès le début.
Ne cherchez pas plus loin l'erreur est là.
D'abord la force d'une base de donnée réside dans les indexes, sinon pas
d'accélération
Si vous avez un seul polygone, l'index ne sert à rien. Pour qu'il soit
utile il vous faudrait par exemp
Bonjour,
Merci beaucoup pour votre réponse. Pour etre plus clair : J'ai un layer
polygonal représentant les limites admin nationales de la France. Il s'agit
d'une seule entité. Et mon autre donnée est en effet un fichier de points
LIDAR vraiment énorme (>re à 2 millions de points) distribués sur p
Oups j'ai oublié "augmenter la puissance de calcul"
Il s'agit tout simplement de mieux ocnfigurer ton serveur postgres pour lui
allouer plus de mémoire, car les réglages par défaut sont très très
économes :
Il s'agit du fichier postgres.conf
http://www.postgresql.org/docs/9.3/static/runtime-config-
Salut Laurent,
on peut imaginer plusieurs approches pour ton problème, en fonction de la
taille de tes données, de la précision voulue, etc.
En résumé tu as un fichier de polygons (combien?) qui représentent un
maillage de la France (département, IRIS, région?).
Et un fichier de point Lidar (2 mil
I imported my 2 layers into db thanks to postgis tools. An spatial index has
been created after the loading automatically.
Indeed, via my qgis DB manager, i can confirm the spatial index creation for
my two tables...
--
View this message in context:
http://postgis.17.x6.nabble.com/ST-inte
Maybe you can check that you have indexes on both geom column.
Cheers,
Rémi-C
2013/12/2 laurent
> Hello,
>
> Ok sorry for the mistake. So please read the correction :
>
> ---
> CREATE TABLE example_intersections_a AS (SELECT ST_Intersection
> (part_1.geom, part_2.geom)FROM
Hello,
Ok sorry for the mistake. So please read the correction :
---
CREATE TABLE example_intersections_a AS (SELECT ST_Intersection
(part_1.geom, part_2.geom)FROM fra_adm0 AS part_1,france_merge_pts1 AS
part_2 WHERE ST_Intersects(part_1.geom, part_2.geom));
ALTER TABLE examp
Hello,
In your from clause, your table is aliases as part_1 and not part1.
Hugues
laurent a écrit :
Hello,
I have 2 tables : one points and one surface. I would like intersects the
geometries. I write the query but i have an error message :
--
CREATE TABLE example_in
Hello,
I have 2 tables : one points and one surface. I would like intersects the
geometries. I write the query but i have an error message :
--
CREATE TABLE example_intersections_a AS (SELECT ST_Intersection (part1.geom,
part2.geom)FROM fra_adm0 AS part_1,france_merge_pts1
ers-boun...@lists.osgeo.org
[mailto:postgis-users-boun...@lists.osgeo.org] De la part de Ahmad Aburizaiza
Envoyé : dimanche 2 décembre 2012 17:44
À : PostGIS Users Discussion
Objet : [postgis-users] ST_Intersects Vs. ST_Intersection
Hello everyone,
I have quick questions please about ST_Intersects Vs. ST_Inte
Hello everyone,
I have quick questions please about ST_Intersects Vs. ST_Intersection:
1. Does the following SQL statement checks the intersection between each
geom in table1 Vs. each geom in table2?
SELECT ST_Intersection(table1.geom, table2.geom)
From table1, table2;
2. I have 3
50 matches
Mail list logo
