From bo.guo at gisticinc.com  Thu Feb  5 04:52:41 2026
From: bo.guo at gisticinc.com (Bo Guo)
Date: Thu, 5 Feb 2026 05:52:41 -0700
Subject: Slowness in testing any crossing straight lines in a layer
Message-ID: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>

Hi There!

I have 100K straight lines in a layer - my_fishbone -  with GIST indexed.
However, the following SQL query did not finish within 20 minutes!  Could
you advise on any improvement ideas?

SELECT a.*, b.id
FROM my_fishbones a, my_fishbones b
WHERE a.geom && b.geom
  AND ST_Crosses(a.geom, b.geom)

Thanks in advance!

Bo Guo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260205/07cb348f/attachment.htm>

From Julien.MONTICOLO at strasbourg.eu  Thu Feb  5 05:00:54 2026
From: Julien.MONTICOLO at strasbourg.eu (MONTICOLO Julien)
Date: Thu, 5 Feb 2026 13:00:54 +0000
Subject: [ScanMail-Spam] Slowness in testing any crossing straight lines
 in a layer
In-Reply-To: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>
References: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>
Message-ID: <e20d42a20e9b494297a1892bff22426d@strasbourg.eu>

Hello,

When doing a cross join (my_fishbones a, my_fishbones b), you multiply a by b, so 100K by 100K.
If your table has 3 records : 1, 2, 3, the cross join outputs : 1|1, 1|2, 1|3, 2|1, 2|2, 2|3, 3|1, 3|2, 3|3.
There are unnecessary crosses.

Add a condition : a.id > b.id to traverse only the half of the matrix.

Kind regards

De : Bo Guo [mailto:bo.guo at gisticinc.com]
Envoy? : jeudi 5 f?vrier 2026 13:53
? : PostGIS Users Discussion <postgis-users at lists.osgeo.org>
Objet : [ScanMail-Spam] Slowness in testing any crossing straight lines in a layer

Hi There!

I have 100K straight lines in a layer - my_fishbone -  with GIST indexed. However, the following SQL query did not finish within 20 minutes!  Could you advise on any improvement ideas?

SELECT a.*, b.id<http://b.id>
FROM my_fishbones a, my_fishbones b
WHERE a.geom && b.geom
  AND ST_Crosses(a.geom, b.geom)

Thanks in advance!

Bo Guo
Ce message est ?tabli ? usage exclusif de son destinataire.
Toute utilisation ou diffusion, partielle ou totale, doit ?tre pr?alablement autoris?e.

Tout message ?lectronique est susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e.
L'exp?diteur d?cline toute responsabilit? au titre de ce message s'il a ?t? modifi? ou falsifi?.

Si vous n'?tes pas destinataire de ce message, merci de le d?truire et d'avertir l'exp?diteur.

Ville et Eurom?tropole de Strasbourg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260205/aaf03506/attachment.htm>

From bo.guo at gisticinc.com  Thu Feb  5 05:59:03 2026
From: bo.guo at gisticinc.com (Bo Guo)
Date: Thu, 5 Feb 2026 06:59:03 -0700
Subject: [ScanMail-Spam] Slowness in testing any crossing straight lines
 in a layer
In-Reply-To: <e20d42a20e9b494297a1892bff22426d@strasbourg.eu>
References: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>
 <e20d42a20e9b494297a1892bff22426d@strasbourg.eu>
Message-ID: <CADHFRcgigP6DW+6OxptBMccHwPxD1AnQPTaSmqZkU96xB5NqQA@mail.gmail.com>

Hi Julien,

That makes sense. I added a.id > b.id.  It still took 17 minutes, however.

Bo

On Thu, Feb 5, 2026 at 6:00?AM MONTICOLO Julien <
Julien.MONTICOLO at strasbourg.eu> wrote:

> Hello,
>
>
>
> When doing a cross join (my_fishbones a, my_fishbones b), you multiply a
> by b, so 100K by 100K.
>
> If your table has 3 records : 1, 2, 3, the cross join outputs : 1|1, 1|2,
> 1|3, 2|1, 2|2, 2|3, 3|1, 3|2, 3|3.
>
> There are unnecessary crosses.
>
>
>
> Add a condition : a.id > b.id to traverse only the half of the matrix.
>
>
>
> Kind regards
>
>
>
> *De :* Bo Guo [mailto:bo.guo at gisticinc.com]
> *Envoy? :* jeudi 5 f?vrier 2026 13:53
> *? :* PostGIS Users Discussion <postgis-users at lists.osgeo.org>
> *Objet :* [ScanMail-Spam] Slowness in testing any crossing straight lines
> in a layer
>
>
>
> Hi There!
>
>
>
> I have 100K straight lines in a layer - my_fishbone -  with GIST indexed.
> However, the following SQL query did not finish within 20 minutes!  Could
> you advise on any improvement ideas?
>
>
>
> SELECT a.*, b.id
> FROM my_fishbones a, my_fishbones b
> WHERE a.geom && b.geom
>   AND ST_Crosses(a.geom, b.geom)
>
>
>
> Thanks in advance!
>
>
>
> Bo Guo
>
>
> Ce message est ?tabli ? usage exclusif de son destinataire.
> Toute utilisation ou diffusion, partielle ou totale, doit ?tre
> pr?alablement autoris?e.
>
> Tout message ?lectronique est susceptible d'alt?ration et son int?grit? ne
> peut ?tre assur?e.
> L'exp?diteur d?cline toute responsabilit? au titre de ce message s'il a
> ?t? modifi? ou falsifi?.
>
> Si vous n'?tes pas destinataire de ce message, merci de le d?truire et
> d'avertir l'exp?diteur.
>
> Ville et Eurom?tropole de Strasbourg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260205/97119864/attachment.htm>

From pramsey at cleverelephant.ca  Thu Feb  5 07:00:48 2026
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Thu, 5 Feb 2026 07:00:48 -0800
Subject: [ScanMail-Spam] Slowness in testing any crossing straight lines
 in a layer
In-Reply-To: <CADHFRcgigP6DW+6OxptBMccHwPxD1AnQPTaSmqZkU96xB5NqQA@mail.gmail.com>
References: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>
 <e20d42a20e9b494297a1892bff22426d@strasbourg.eu>
 <CADHFRcgigP6DW+6OxptBMccHwPxD1AnQPTaSmqZkU96xB5NqQA@mail.gmail.com>
Message-ID: <016B7AB9-A0B6-466F-A5B7-CA0D87890446@cleverelephant.ca>

Depends on your data. If the && operator is not particularly selective in your case, you?re evaluating 100K * 100K = 10000000000 crossing tests.
P

> On Feb 5, 2026, at 5:59?AM, Bo Guo <bo.guo at gisticinc.com> wrote:
> 
> Hi Julien,
> 
> That makes sense. I added a.id <http://a.id/> > b.id <http://b.id/>.  It still took 17 minutes, however.
> 
> Bo
> 
> On Thu, Feb 5, 2026 at 6:00?AM MONTICOLO Julien <Julien.MONTICOLO at strasbourg.eu <mailto:Julien.MONTICOLO at strasbourg.eu>> wrote:
>> Hello,
>> 
>>  
>> 
>> When doing a cross join (my_fishbones a, my_fishbones b), you multiply a by b, so 100K by 100K.
>> 
>> If your table has 3 records : 1, 2, 3, the cross join outputs : 1|1, 1|2, 1|3, 2|1, 2|2, 2|3, 3|1, 3|2, 3|3.
>> 
>> There are unnecessary crosses.
>> 
>>  
>> 
>> Add a condition : a.id <http://a.id/> > b.id <http://b.id/> to traverse only the half of the matrix.
>> 
>>  
>> 
>> Kind regards
>> 
>>  
>> 
>> De : Bo Guo [mailto:bo.guo at gisticinc.com <mailto:bo.guo at gisticinc.com>] 
>> Envoy? : jeudi 5 f?vrier 2026 13:53
>> ? : PostGIS Users Discussion <postgis-users at lists.osgeo.org <mailto:postgis-users at lists.osgeo.org>>
>> Objet : [ScanMail-Spam] Slowness in testing any crossing straight lines in a layer
>> 
>>  
>> 
>> Hi There!
>> 
>>  
>> 
>> I have 100K straight lines in a layer - my_fishbone -  with GIST indexed. However, the following SQL query did not finish within 20 minutes!  Could you advise on any improvement ideas?
>> 
>>  
>> 
>> SELECT a.*, b.id <http://b.id/>
>> FROM my_fishbones a, my_fishbones b
>> WHERE a.geom && b.geom 
>>   AND ST_Crosses(a.geom, b.geom)
>> 
>>  
>> 
>> Thanks in advance!
>> 
>>  
>> 
>> Bo Guo
>> 
>> 
>> 
>> Ce message est ?tabli ? usage exclusif de son destinataire.
>> Toute utilisation ou diffusion, partielle ou totale, doit ?tre pr?alablement autoris?e.
>> 
>> Tout message ?lectronique est susceptible d'alt?ration et son int?grit? ne peut ?tre assur?e.
>> L'exp?diteur d?cline toute responsabilit? au titre de ce message s'il a ?t? modifi? ou falsifi?.
>> 
>> Si vous n'?tes pas destinataire de ce message, merci de le d?truire et d'avertir l'exp?diteur.
>> 
>> Ville et Eurom?tropole de Strasbourg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260205/c8923280/attachment.htm>

From lr at pcorp.us  Thu Feb  5 07:06:19 2026
From: lr at pcorp.us (Regina Obe)
Date: Thu, 5 Feb 2026 10:06:19 -0500
Subject: Slowness in testing any crossing straight lines in a layer
In-Reply-To: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>
References: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>
Message-ID: <003c01dc96b0$fc29ca80$f47d5f80$@pcorp.us>

How  many records do you have in  a / b

 

What does this query return and point counts also impact performance

 

SELECT  COUNT(*),  MAX(ST_NPoints(geom))

FROM my_fishbones

 

 

Also I?d think you?d want to leave out compare with a.id = b.id

 

I also think the && is redundant as crosses already has a built in index check

 

SELECT a.*, b.id <http://b.id> 
FROM my_fishbones a INNER JOIN  my_fishbones b ON (a.id <> b.id AND ST_Crosses(a.geom,b.geom) )



 

 

 

From: Bo Guo <bo.guo at gisticinc.com> 
Sent: Thursday, February 5, 2026 7:53 AM
To: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
Subject: Slowness in testing any crossing straight lines in a layer

 

Hi There!

 

I have 100K straight lines in a layer - my_fishbone -  with GIST indexed. However, the following SQL query did not finish within 20 minutes!  Could you advise on any improvement ideas?

 

SELECT a.*, b.id <http://b.id> 
FROM my_fishbones a, my_fishbones b
WHERE a.geom && b.geom 
  AND ST_Crosses(a.geom, b.geom)

 

Thanks in advance!

 

Bo Guo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260205/7b057789/attachment-0001.htm>

From bo.guo at gisticinc.com  Thu Feb  5 09:58:54 2026
From: bo.guo at gisticinc.com (Bo Guo)
Date: Thu, 5 Feb 2026 10:58:54 -0700
Subject: Slowness in testing any crossing straight lines in a layer
In-Reply-To: <003c01dc96b0$fc29ca80$f47d5f80$@pcorp.us>
References: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>
 <003c01dc96b0$fc29ca80$f47d5f80$@pcorp.us>
Message-ID: <CADHFRcjSQWpJCMuDR5Nv4oASyFptYMgAkAmYh5anM1U6rOy83Q@mail.gmail.com>

Hi Regina!

Your query returned "116002, 2".

I ran the three variations of the ST_Crosses query, and here are the
performance results.

SELECT a.*, b.gad_globalid
FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid <>
b.gad_globalid AND ST_Crosses(a.geom,b.geom) )
-- 33 minutes

SELECT a.*, b.gad_globalid
FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid <
b.gad_globalid AND ST_Crosses(a.geom,b.geom) )
-- 17 minutes

SELECT a.*, b.gad_globalid
FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid <
b.gad_globalid AND a.geom && b.geom AND ST_Crosses(a.geom,b.geom) )
-- 17 minutes

It seems that 17 mins is the best I can get?

Thanks!


On Thu, Feb 5, 2026 at 8:06?AM Regina Obe <lr at pcorp.us> wrote:

> How  many records do you have in  a / b
>
>
>
> What does this query return and point counts also impact performance
>
>
>
> SELECT  COUNT(*),  MAX(ST_NPoints(geom))
>
> FROM my_fishbones
>
>
>
>
>
> Also I?d think you?d want to leave out compare with a.id = b.id
>
>
>
> I also think the && is redundant as crosses already has a built in index
> check
>
>
>
> SELECT a.*, b.id
> FROM my_fishbones a INNER JOIN  my_fishbones b ON (a.id <> b.id AND
> ST_Crosses(a.geom,b.geom) )
>
>
>
>
>
>
>
> *From:* Bo Guo <bo.guo at gisticinc.com>
> *Sent:* Thursday, February 5, 2026 7:53 AM
> *To:* PostGIS Users Discussion <postgis-users at lists.osgeo.org>
> *Subject:* Slowness in testing any crossing straight lines in a layer
>
>
>
> Hi There!
>
>
>
> I have 100K straight lines in a layer - my_fishbone -  with GIST indexed.
> However, the following SQL query did not finish within 20 minutes!  Could
> you advise on any improvement ideas?
>
>
>
> SELECT a.*, b.id
> FROM my_fishbones a, my_fishbones b
> WHERE a.geom && b.geom
>   AND ST_Crosses(a.geom, b.geom)
>
>
>
> Thanks in advance!
>
>
>
> Bo Guo
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260205/496637cb/attachment.htm>

From lr at pcorp.us  Thu Feb  5 10:38:04 2026
From: lr at pcorp.us (Regina Obe)
Date: Thu, 5 Feb 2026 13:38:04 -0500
Subject: Slowness in testing any crossing straight lines in a layer
In-Reply-To: <CADHFRcjSQWpJCMuDR5Nv4oASyFptYMgAkAmYh5anM1U6rOy83Q@mail.gmail.com>
References: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>
 <003c01dc96b0$fc29ca80$f47d5f80$@pcorp.us>
 <CADHFRcjSQWpJCMuDR5Nv4oASyFptYMgAkAmYh5anM1U6rOy83Q@mail.gmail.com>
Message-ID: <007401dc96ce$918f0190$b4ad04b0$@pcorp.us>

What does 

 

SELECT postgis_full_version();

 

Return.  I suppose doing a cross join there does result in an order of  6,728,232,002 checks.

 

You definitely have a spatial index on your geometry column right?

 

 

What timing do you get with below, just want to rule out some performance issue with ST_Crosses

 

SELECT a.*, b.gad_globalid
FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid <  b.gad_globalid AND ST_Intersects(a.geom,b.geom) );

 

 

From: Bo Guo <bo.guo at gisticinc.com> 
Sent: Thursday, February 5, 2026 12:59 PM
To: Regina Obe <lr at pcorp.us>
Cc: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
Subject: Re: Slowness in testing any crossing straight lines in a layer

 

Hi Regina!  

 

Your query returned "116002, 2".

 

I ran the three variations of the ST_Crosses query, and here are the performance results.

 

SELECT a.*, b.gad_globalid
FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid <> b.gad_globalid AND ST_Crosses(a.geom,b.geom) )
-- 33 minutes

SELECT a.*, b.gad_globalid
FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid < b.gad_globalid AND ST_Crosses(a.geom,b.geom) )
-- 17 minutes

SELECT a.*, b.gad_globalid
FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid < b.gad_globalid AND a.geom && b.geom AND ST_Crosses(a.geom,b.geom) )
-- 17 minutes

 

It seems that 17 mins is the best I can get?

 

Thanks!

 

 

On Thu, Feb 5, 2026 at 8:06?AM Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

How  many records do you have in  a / b

 

What does this query return and point counts also impact performance

 

SELECT  COUNT(*),  MAX(ST_NPoints(geom))

FROM my_fishbones

 

 

Also I?d think you?d want to leave out compare with a.id <http://a.id>  = b.id <http://b.id> 

 

I also think the && is redundant as crosses already has a built in index check

 

SELECT a.*, b.id <http://b.id> 
FROM my_fishbones a INNER JOIN  my_fishbones b ON (a.id <http://a.id>  <> b.id <http://b.id>  AND ST_Crosses(a.geom,b.geom) )

 

 

 

From: Bo Guo <bo.guo at gisticinc.com <mailto:bo.guo at gisticinc.com> > 
Sent: Thursday, February 5, 2026 7:53 AM
To: PostGIS Users Discussion <postgis-users at lists.osgeo.org <mailto:postgis-users at lists.osgeo.org> >
Subject: Slowness in testing any crossing straight lines in a layer

 

Hi There!

 

I have 100K straight lines in a layer - my_fishbone -  with GIST indexed. However, the following SQL query did not finish within 20 minutes!  Could you advise on any improvement ideas?

 

SELECT a.*, b.id <http://b.id> 
FROM my_fishbones a, my_fishbones b
WHERE a.geom && b.geom 
  AND ST_Crosses(a.geom, b.geom)

 

Thanks in advance!

 

Bo Guo

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260205/dcf20802/attachment.htm>

From bo.guo at gisticinc.com  Thu Feb  5 15:03:56 2026
From: bo.guo at gisticinc.com (Bo Guo)
Date: Thu, 5 Feb 2026 16:03:56 -0700
Subject: Slowness in testing any crossing straight lines in a layer
In-Reply-To: <007401dc96ce$918f0190$b4ad04b0$@pcorp.us>
References: <CADHFRcggpMRkz5DEX=aEtobuLafSo2fjODvf8VhzcLxB=TCBxw@mail.gmail.com>
 <003c01dc96b0$fc29ca80$f47d5f80$@pcorp.us>
 <CADHFRcjSQWpJCMuDR5Nv4oASyFptYMgAkAmYh5anM1U6rOy83Q@mail.gmail.com>
 <007401dc96ce$918f0190$b4ad04b0$@pcorp.us>
Message-ID: <CADHFRch_rbdCDedibRiSRm2Er-G3T9P_bWo6+Mh9N4KmjVtY6Q@mail.gmail.com>

*Versions:  *POSTGIS="3.6.1 f533623" [EXTENSION] PGSQL="180"
GEOS="3.10.2-CAPI-1.16.0" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=
https://cdn.proj.org USER_WRITABLE_DIRECTORY=/tmp/proj
DATABASE_PATH=/usr/share/proj/proj.db" (compiled against PROJ 8.2.1)
LIBXML="2.9.13" LIBJSON="0.15" LIBPROTOBUF="1.3.3" WAGYU="0.5.0 (Internal)"
(core procs from "3.6.0 4c1967d" need upgrade) TOPOLOGY (topology procs
from "3.6.0 4c1967d" need upgrade)

Yes, this is the Explain Graphics:
[image: image.png]
The Intersects call - SELECT a.*, b.gad_globalid FROM _tmp_fishbone a INNER
JOIN  _tmp_fishbone b ON (a.gad_globalid <  b.gad_globalid AND
ST_Intersects(a.geom,b.geom) ); took over 15 minutes before pgAdmin session
terminated. I will try it again in a bit.


On Thu, Feb 5, 2026 at 11:38?AM Regina Obe <lr at pcorp.us> wrote:

> What does
>
>
>
> SELECT postgis_full_version();
>
>
>
> Return.  I suppose doing a cross join there does result in an order of  6,728,232,002
> checks.
>
>
>
> You definitely have a spatial index on your geometry column right?
>
>
>
>
>
> What timing do you get with below, just want to rule out some performance
> issue with ST_Crosses
>
>
>
> SELECT a.*, b.gad_globalid
> FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid <
>  b.gad_globalid AND ST_Intersects(a.geom,b.geom) );
>
>
>
>
>
> *From:* Bo Guo <bo.guo at gisticinc.com>
> *Sent:* Thursday, February 5, 2026 12:59 PM
> *To:* Regina Obe <lr at pcorp.us>
> *Cc:* PostGIS Users Discussion <postgis-users at lists.osgeo.org>
> *Subject:* Re: Slowness in testing any crossing straight lines in a layer
>
>
>
> Hi Regina!
>
>
>
> Your query returned "116002, 2".
>
>
>
> I ran the three variations of the ST_Crosses query, and here are the
> performance results.
>
>
>
> SELECT a.*, b.gad_globalid
> FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid <>
> b.gad_globalid AND ST_Crosses(a.geom,b.geom) )
> -- 33 minutes
>
> SELECT a.*, b.gad_globalid
> FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid <
> b.gad_globalid AND ST_Crosses(a.geom,b.geom) )
> -- 17 minutes
>
> SELECT a.*, b.gad_globalid
> FROM _tmp_fishbone a INNER JOIN  _tmp_fishbone b ON (a.gad_globalid <
> b.gad_globalid AND a.geom && b.geom AND ST_Crosses(a.geom,b.geom) )
> -- 17 minutes
>
>
>
> It seems that 17 mins is the best I can get?
>
>
>
> Thanks!
>
>
>
>
>
> On Thu, Feb 5, 2026 at 8:06?AM Regina Obe <lr at pcorp.us> wrote:
>
> How  many records do you have in  a / b
>
>
>
> What does this query return and point counts also impact performance
>
>
>
> SELECT  COUNT(*),  MAX(ST_NPoints(geom))
>
> FROM my_fishbones
>
>
>
>
>
> Also I?d think you?d want to leave out compare with a.id = b.id
>
>
>
> I also think the && is redundant as crosses already has a built in index
> check
>
>
>
> SELECT a.*, b.id
> FROM my_fishbones a INNER JOIN  my_fishbones b ON (a.id <> b.id AND
> ST_Crosses(a.geom,b.geom) )
>
>
>
>
>
>
>
> *From:* Bo Guo <bo.guo at gisticinc.com>
> *Sent:* Thursday, February 5, 2026 7:53 AM
> *To:* PostGIS Users Discussion <postgis-users at lists.osgeo.org>
> *Subject:* Slowness in testing any crossing straight lines in a layer
>
>
>
> Hi There!
>
>
>
> I have 100K straight lines in a layer - my_fishbone -  with GIST indexed.
> However, the following SQL query did not finish within 20 minutes!  Could
> you advise on any improvement ideas?
>
>
>
> SELECT a.*, b.id
> FROM my_fishbones a, my_fishbones b
> WHERE a.geom && b.geom
>   AND ST_Crosses(a.geom, b.geom)
>
>
>
> Thanks in advance!
>
>
>
> Bo Guo
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260205/855da0ce/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 18584 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260205/855da0ce/attachment.png>

From lr at pcorp.us  Mon Feb  9 18:27:23 2026
From: lr at pcorp.us (Regina Obe)
Date: Mon, 9 Feb 2026 21:27:23 -0500
Subject: PostGIS Patch releases for 3.0 - 3.6
Message-ID: <000001dc9a34$cb2ca5b0$6185f110$@pcorp.us>

The PostGIS development team is pleased to release patch releases for the
3.0 thru 3.6 PostGIS series.

3.6.2, 3.5.5, 3.4.5, 3.3.9, 3.2.9, 3.1.13, and 3.0.12

Note that this is the last patch release for the 3.0 and 3.1 series.

Refer to  https://postgis.net/2026/02/PostGIS-Patch-Releases/  for details.

If you run into any issues with these, please report on the mailing lists or
submit a ticket following these guidelines -
https://postgis.net/development/bug_reporting/

Happy Testing,
PostGIS Development Team 


From haynesd2 at gmail.com  Mon Feb  9 22:28:29 2026
From: haynesd2 at gmail.com (David Haynes)
Date: Tue, 10 Feb 2026 00:28:29 -0600
Subject: PG_Restore error
Message-ID: <CAM4C04pfAGexHTpetmx0vzyG66pki-+98Um9fBFpFZfqW7CqEQ@mail.gmail.com>

Hello,

I have an old PostgreSQL database dump file that uses the old PostGIS
extension. What I mean is that the database was created when the extension
used to be CREATE Extension PostGIS. Now there are at least 2 commands:
CREATE Extension postgis and  CREATE Extension postgis_raster; This
particular database has both vector and raster datasets. To complicate
matters, I unintentionally dumped it in a binary format.

I have been somewhat successful in getting the DB to load. I'm using a
pg_restore command using the following flags (--no-owner --create --clean).
However, I get a lot of errors because the database can not create raster
datasets as that datatype does not exist. Is there a command that I can
issue during this pg_restore process to initialize the postgis_raster
extension? If not, what are my next steps? Do I need to load the database
onto an older version of PostGIS?

Thanks for any feedback
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260210/76d69330/attachment.htm>

From lr at pcorp.us  Tue Feb 10 03:48:37 2026
From: lr at pcorp.us (Regina Obe)
Date: Tue, 10 Feb 2026 06:48:37 -0500
Subject: PG_Restore error
In-Reply-To: <CAM4C04pfAGexHTpetmx0vzyG66pki-+98Um9fBFpFZfqW7CqEQ@mail.gmail.com>
References: <CAM4C04pfAGexHTpetmx0vzyG66pki-+98Um9fBFpFZfqW7CqEQ@mail.gmail.com>
Message-ID: <000d01dc9a83$326782b0$97368810$@pcorp.us>

Not sure what you mean by unintentionally dumped as binary format.  That is the preferred way.

 

What you should do is the following:

 

Create a blank database.

 

Run 

 

CREATE EXTENSION postgis;

CREATE EXTENSION postgis_raster;

 

Then restore your database into the new one you created.

 

The only thing that should happen assuming you have an individual backup for your database, is that it will failing when doing CREATE EXTENSION postgis;  which is fine and expected.

 

But your raster data will find the datatype and functions it needs in postgis_raster so should do fine.

 

From: David Haynes <haynesd2 at gmail.com> 
Sent: Tuesday, February 10, 2026 1:28 AM
To: postgis-users at lists.osgeo.org
Subject: PG_Restore error

 

Hello,

 

I have an old PostgreSQL database dump file that uses the old PostGIS extension. What I mean is that the database was created when the extension used to be CREATE Extension PostGIS. Now there are at least 2 commands: CREATE Extension postgis and  CREATE Extension postgis_raster; This particular database has both vector and raster datasets. To complicate matters, I unintentionally dumped it in a binary format. 

I have been somewhat successful in getting the DB to load. I'm using a pg_restore command using the following flags (--no-owner --create --clean). However, I get a lot of errors because the database can not create raster datasets as that datatype does not exist. Is there a command that I can issue during this pg_restore process to initialize the postgis_raster extension? If not, what are my next steps? Do I need to load the database onto an older version of PostGIS?

 

Thanks for any feedback

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260210/4624ddb4/attachment.htm>

From haynesd2 at gmail.com  Wed Feb 11 08:02:26 2026
From: haynesd2 at gmail.com (David Haynes)
Date: Wed, 11 Feb 2026 10:02:26 -0600
Subject: PG_Restore error
In-Reply-To: <000d01dc9a83$326782b0$97368810$@pcorp.us>
References: <CAM4C04pfAGexHTpetmx0vzyG66pki-+98Um9fBFpFZfqW7CqEQ@mail.gmail.com>
 <000d01dc9a83$326782b0$97368810$@pcorp.us>
Message-ID: <CAM4C04pb2eXNnac-sPcF_J4Xyb6=Ju7yLxc6U1X7T3hxRtkNpg@mail.gmail.com>

Thanks for the help. Can you provide me with the flags I should use on
PG_Restore.

On Tue, Feb 10, 2026 at 5:48?AM Regina Obe <lr at pcorp.us> wrote:

> Not sure what you mean by unintentionally dumped as binary format.  That
> is the preferred way.
>
>
>
> What you should do is the following:
>
>
>
> Create a blank database.
>
>
>
> Run
>
>
>
> CREATE EXTENSION postgis;
>
> CREATE EXTENSION postgis_raster;
>
>
>
> Then restore your database into the new one you created.
>
>
>
> The only thing that should happen assuming you have an individual backup
> for your database, is that it will failing when doing CREATE EXTENSION
> postgis;  which is fine and expected.
>
>
>
> But your raster data will find the datatype and functions it needs in
> postgis_raster so should do fine.
>
>
>
> *From:* David Haynes <haynesd2 at gmail.com>
> *Sent:* Tuesday, February 10, 2026 1:28 AM
> *To:* postgis-users at lists.osgeo.org
> *Subject:* PG_Restore error
>
>
>
> Hello,
>
>
>
> I have an old PostgreSQL database dump file that uses the old PostGIS
> extension. What I mean is that the database was created when the extension
> used to be CREATE Extension PostGIS. Now there are at least 2 commands:
> CREATE Extension postgis and  CREATE Extension postgis_raster; This
> particular database has both vector and raster datasets. To complicate
> matters, I unintentionally dumped it in a binary format.
>
> I have been somewhat successful in getting the DB to load. I'm using a
> pg_restore command using the following flags (--no-owner --create --clean).
> However, I get a lot of errors because the database can not create raster
> datasets as that datatype does not exist. Is there a command that I can
> issue during this pg_restore process to initialize the postgis_raster
> extension? If not, what are my next steps? Do I need to load the database
> onto an older version of PostGIS?
>
>
>
> Thanks for any feedback
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260211/efff0d98/attachment.htm>

From richard.greenwood at gmail.com  Wed Feb 11 12:01:08 2026
From: richard.greenwood at gmail.com (Richard Greenwood)
Date: Wed, 11 Feb 2026 13:01:08 -0700
Subject: PG_Restore error
In-Reply-To: <CAM4C04pb2eXNnac-sPcF_J4Xyb6=Ju7yLxc6U1X7T3hxRtkNpg@mail.gmail.com>
References: <CAM4C04pfAGexHTpetmx0vzyG66pki-+98Um9fBFpFZfqW7CqEQ@mail.gmail.com>
 <000d01dc9a83$326782b0$97368810$@pcorp.us>
 <CAM4C04pb2eXNnac-sPcF_J4Xyb6=Ju7yLxc6U1X7T3hxRtkNpg@mail.gmail.com>
Message-ID: <CAHBySPbzoTZNWRgayaqDGDxhadjQ42F51dtMo5-w0nFac90qRA@mail.gmail.com>

You probably don't need any flags beyond specifying the target database
name. Follow Regina instructions: create a target database and add postgis
and postgis_raster extensions to it. The run pg_restore like:
     pg_restore   -d  target_database_name   your_pg_dump_file.backup
Postgres error messages are usually pretty clear so if that doesn't work it
will probably tell you why.

Rich


On Wed, Feb 11, 2026 at 9:41?AM David Haynes <haynesd2 at gmail.com> wrote:

> Thanks for the help. Can you provide me with the flags I should use on
> PG_Restore.
>
> On Tue, Feb 10, 2026 at 5:48?AM Regina Obe <lr at pcorp.us> wrote:
>
>> Not sure what you mean by unintentionally dumped as binary format.  That
>> is the preferred way.
>>
>>
>>
>> What you should do is the following:
>>
>>
>>
>> Create a blank database.
>>
>>
>>
>> Run
>>
>>
>>
>> CREATE EXTENSION postgis;
>>
>> CREATE EXTENSION postgis_raster;
>>
>>
>>
>> Then restore your database into the new one you created.
>>
>>
>>
>> The only thing that should happen assuming you have an individual backup
>> for your database, is that it will failing when doing CREATE EXTENSION
>> postgis;  which is fine and expected.
>>
>>
>>
>> But your raster data will find the datatype and functions it needs in
>> postgis_raster so should do fine.
>>
>>
>>
>> *From:* David Haynes <haynesd2 at gmail.com>
>> *Sent:* Tuesday, February 10, 2026 1:28 AM
>> *To:* postgis-users at lists.osgeo.org
>> *Subject:* PG_Restore error
>>
>>
>>
>> Hello,
>>
>>
>>
>> I have an old PostgreSQL database dump file that uses the old PostGIS
>> extension. What I mean is that the database was created when the extension
>> used to be CREATE Extension PostGIS. Now there are at least 2 commands:
>> CREATE Extension postgis and  CREATE Extension postgis_raster; This
>> particular database has both vector and raster datasets. To complicate
>> matters, I unintentionally dumped it in a binary format.
>>
>> I have been somewhat successful in getting the DB to load. I'm using a
>> pg_restore command using the following flags (--no-owner --create --clean).
>> However, I get a lot of errors because the database can not create raster
>> datasets as that datatype does not exist. Is there a command that I can
>> issue during this pg_restore process to initialize the postgis_raster
>> extension? If not, what are my next steps? Do I need to load the database
>> onto an older version of PostGIS?
>>
>>
>>
>> Thanks for any feedback
>>
>

-- 
Richard W. Greenwood
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260211/a7f0a90e/attachment.htm>

From anvalanz at gmail.com  Mon Feb 23 23:18:56 2026
From: anvalanz at gmail.com (Antonio Valanzano)
Date: Tue, 24 Feb 2026 08:18:56 +0100
Subject: Coordinate transformations with pipelines
Message-ID: <CANV1FQZKo8tH_cQTr=i1ZPWQzHDe86MguWsty4=hxGKKFoNQyg@mail.gmail.com>

I am usign PostGIS 3.5 with PostgreSQL 17.0

Here are the details for my installation:

"postgis_full_version"
"POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF
URL_ENDPOINT=https://cdn.proj.org
USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj

DATABASE_PATH=C:\Program
Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
against PROJ 8.2.1)
LIBXML=""2.12.5"" LIBJSON=""0.12"" LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0
(Internal)"" (core procs from ""3.5.2 3.5.2"" need upgrade)"


I have done the following coordinate transformation
from  ED50 / UTM zone 33N  (espg:23033)
to  ETRS89 / UTM zone 33N  (epsg:25833

SELECT
  ST_X(ST_Transform(ST_Point(541000,4516000,23033),25833)) as X,
  ST_Y(ST_Transform(ST_Point(541000,4516000,23033),25833)) as Y;

-- result
"x" "y"
540998.1383329581 4515921.565374701

I have read that the best way to utilize PROJ.6 capabilities is by allowing
the library to freely choose the best possible transformation paths
between the origin and the destination CRSes.

Does someone know how to find which specific transformation pipeline has
been chosen by the PROJ.6 library in this specific transformation ?

Antonio
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260224/bf9d30a3/attachment.htm>

From florian.nadler at cybertec.at  Thu Feb 26 01:29:28 2026
From: florian.nadler at cybertec.at (Florian Nadler)
Date: Thu, 26 Feb 2026 10:29:28 +0100
Subject: Coordinate transformations with pipelines
In-Reply-To: <CANV1FQZKo8tH_cQTr=i1ZPWQzHDe86MguWsty4=hxGKKFoNQyg@mail.gmail.com>
References: <CANV1FQZKo8tH_cQTr=i1ZPWQzHDe86MguWsty4=hxGKKFoNQyg@mail.gmail.com>
Message-ID: <bbd729f1-09b9-4bd5-b30b-89af554f25a4@cybertec.at>

Try projinfo (https://proj.org/en/stable/apps/projinfo.html#examples) 
from the commandline of your PostGIS host:

 ?projinfo -s EPSG:23033 -t EPSG:25833

Transformation can done via? commandline as follows:

cs2cs EPSG:23033 EPSG:25833 <<EOF
541000 4516000
EOF

Florian

Am 24.02.2026 um 08:18 schrieb Antonio Valanzano:
> I am usign PostGIS 3.5 with PostgreSQL 17.0
>
> Here are the details for my installation:
>
> "postgis_full_version"
> "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170"" 
> GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF
> URL_ENDPOINT=https://cdn.proj.org 
> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj 
>
> DATABASE_PATH=C:\Program 
> Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled 
> against PROJ 8.2.1)
> LIBXML=""2.12.5"" LIBJSON=""0.12"" LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0 
> (Internal)"" (core procs from ""3.5.2 3.5.2"" need upgrade)"
>
>
> I have done the following coordinate transformation
> from? ED50 / UTM zone 33N ?(espg:23033)
> to? ETRS89 / UTM zone 33N ?(epsg:25833
>
> SELECT
> ? ST_X(ST_Transform(ST_Point(541000,4516000,23033),25833)) as X,
> ? ST_Y(ST_Transform(ST_Point(541000,4516000,23033),25833)) as Y;
>
> -- result
> "x" "y"
> 540998.1383329581 4515921.565374701
>
> I have read that the best way to utilize PROJ.6 capabilities is by 
> allowing the library to freely choose the best possible transformation 
> paths
> between the origin and the destination CRSes.
>
> Does someone know how to find which specific transformation pipeline 
> has been chosen by the PROJ.6 library in this specific transformation ?
>
> Antonio
>
>
-- 
CYBERTEC PostgreSQL International GmbH
R?merstra?e 19, A-2752 W?llersdorf
Web: https://www.cybertec-postgresql.com


From anvalanz at gmail.com  Thu Feb 26 02:28:21 2026
From: anvalanz at gmail.com (Antonio Valanzano)
Date: Thu, 26 Feb 2026 11:28:21 +0100
Subject: Coordinate transformations with pipelines
In-Reply-To: <bbd729f1-09b9-4bd5-b30b-89af554f25a4@cybertec.at>
References: <CANV1FQZKo8tH_cQTr=i1ZPWQzHDe86MguWsty4=hxGKKFoNQyg@mail.gmail.com>
 <bbd729f1-09b9-4bd5-b30b-89af554f25a4@cybertec.at>
Message-ID: <CANV1FQayqwn37+wP18yjpFiZ_77ivQ+MetA+bfZX_w_YLitHBw@mail.gmail.com>

Dear Florian,
thanks for your answer.

I have already used projinfo and I have discovered that there 3
possible transformations as you can see from the following output

---------------------------------------------------------------------------------------------------
C:\>projinfo -s EPSG:23033 -t EPSG:25833 -o proj --spatial-test intersects
Candidate operations found: 3
-------------------------------------
Operation No. 1:

unknown id, Inverse of UTM zone 33N + ED50 to ETRS89 (1) + UTM zone 33N, 1
m, Norway - offshore north of 65?N. Also Svalbard.

PROJ string:
+proj=pipeline
  +step +inv +proj=utm +zone=33 +ellps=intl
  +step +proj=push +v_3
  +step +proj=cart +ellps=intl
  +step +proj=helmert +x=-116.641 +y=-56.931 +z=-110.559
+rx=0.892507816631186
        +ry=0.920766095087038 +rz=-0.916640798962096 +s=-3.52
        +convention=position_vector
  +step +inv +proj=cart +ellps=GRS80
  +step +proj=pop +v_3
  +step +proj=utm +zone=33 +ellps=GRS80

-------------------------------------
Operation No. 2:

unknown id, Inverse of UTM zone 33N + ED50 to ETRS89 (4) + UTM zone 33N, 1
m, Denmark - onshore.

PROJ string:
+proj=pipeline
  +step +inv +proj=utm +zone=33 +ellps=intl
  +step +proj=push +v_3
  +step +proj=cart +ellps=intl
  +step +proj=helmert +x=-81.1 +y=-89.4 +z=-115.8 +rx=0.485 +ry=0.024
+rz=0.413
        +s=-0.54 +convention=position_vector
  +step +inv +proj=cart +ellps=GRS80
  +step +proj=pop +v_3
  +step +proj=utm +zone=33 +ellps=GRS80

-------------------------------------
Operation No. 3:

unknown id, Inverse of UTM zone 33N + Ballpark geographic offset from ED50
to ETRS89 + UTM zone 33N, unknown accuracy, World, has ballpark
transformation

PROJ string:
+proj=pipeline
  +step +inv +proj=utm +zone=33 +ellps=intl
  +step +proj=utm +zone=33 +ellps=GRS80

C:\>
----------------------------------------------------------------------------------------------------
PostGIS in my case has used the last one (the less accurate transformation
- "ballpark transformation")
This is the default behaviour in this case as you can see also looking at
the output of cs2cs

C:\>cs2cs EPSG:23033 EPSG:25833
541000 4516000
540998.14       4515921.57 0.00

The result is coincident with the output of my sql script
540998.1383329581 4515921.565374701

My question was about the criteria used by the Proj.6 lib for choosing
between several possible transformations and also to know the
transformation pipeline code used.

Searching on the net I have found that the same results (the approximate
ones) can be obtained using the function ST_TransformPipeline ()  a variant
of ST_Transform and specifying the EPSG code the transformation

-- I have first transformed the cartografic coordinates  541000 4516000 from
EPSG:23033 to geographic coordinates with EPSG:4230

WITH coord_4258 AS
(
  SELECT
     ST_X(ST_TransformPipeline('SRID=4230;POINT(15.48596772786105
40.79326538046647)'::geometry,'urn:ogc:def:coordinateOperation:EPSG::1611'))
as x_4258,
     ST_Y(ST_TransformPipeline('SRID=4230;POINT(15.48596772786105
40.79326538046647)'::geometry,'urn:ogc:def:coordinateOperation:EPSG::1611'))
as y_4258
  )
SELECT
  ST_AsEWKT(ST_Transform(ST_Point(x_4258,y_4258, 4258), 25833))
FROM coord_4258;
---------------
"st_asewkt"
"SRID=25833;POINT(540998.1383329581 4515921.565374701)"
.

In order to obtain better results I have used a specific EPSG
transformation code (1588)

WITH coord_4258 AS
(
  SELECT
     ST_X(ST_TransformPipeline('SRID=4230;POINT(15.48596772786105
40.79326538046647)'::geometry,'urn:ogc:def:coordinateOperation:EPSG::1588'))
as x_4258,
     ST_Y(ST_TransformPipeline('SRID=4230;POINT(15.48596772786105
40.79326538046647)'::geometry,'urn:ogc:def:coordinateOperation:EPSG::1588'))
as y_4258
  )
SELECT
  ST_AsEWKT(ST_Transform(ST_Point(x_4258,y_4258, 4258), 25833))
FROM coord_4258;
----------------
"st_asewkt"
"SRID=25833;POINT(540931.3414974756 4515810.597825925)"

The most accurate results are those obtained using a NTv2 grid file
540932.206  4515807.111

and the results of the transformation with EPSG:1588 are better than those
of EPSG:1611 (used da PostGIS).

The questions are now:

1. why did Proj.6 lib  choose the transformation with EPSG code 1611 rather
than the one with EPSG code 1588 ?
2. why there is no evidence in the output of ST_Transform or cs2cs of the
transformation code chosen for doing the transformation ?

I hope this long mail will help clarify my initial question.

Antonio





Il giorno gio 26 feb 2026 alle ore 10:29 Florian Nadler <
florian.nadler at cybertec.at> ha scritto:

> Try projinfo (https://proj.org/en/stable/apps/projinfo.html#examples)
> from the commandline of your PostGIS host:
>
>   projinfo -s EPSG:23033 -t EPSG:25833
>
> Transformation can done via  commandline as follows:
>
> cs2cs EPSG:23033 EPSG:25833 <<EOF
> 541000 4516000
> EOF
>
> Florian
>
> Am 24.02.2026 um 08:18 schrieb Antonio Valanzano:
> > I am usign PostGIS 3.5 with PostgreSQL 17.0
> >
> > Here are the details for my installation:
> >
> > "postgis_full_version"
> > "POSTGIS=""3.5.3 3.5.3"" [EXTENSION] PGSQL=""170""
> > GEOS=""3.13.1-CAPI-1.19.2"" PROJ=""8.2.1 NETWORK_ENABLED=OFF
> > URL_ENDPOINT=https://cdn.proj.org
> >
> USER_WRITABLE_DIRECTORY=C:\Windows\ServiceProfiles\NetworkService\AppData\Local/proj
>
> >
> > DATABASE_PATH=C:\Program
> > Files\PostgreSQL\17\share\contrib\postgis-3.5\proj\proj.db"" (compiled
> > against PROJ 8.2.1)
> > LIBXML=""2.12.5"" LIBJSON=""0.12"" LIBPROTOBUF=""1.2.1"" WAGYU=""0.5.0
> > (Internal)"" (core procs from ""3.5.2 3.5.2"" need upgrade)"
> >
> >
> > I have done the following coordinate transformation
> > from  ED50 / UTM zone 33N  (espg:23033)
> > to  ETRS89 / UTM zone 33N  (epsg:25833
> >
> > SELECT
> >   ST_X(ST_Transform(ST_Point(541000,4516000,23033),25833)) as X,
> >   ST_Y(ST_Transform(ST_Point(541000,4516000,23033),25833)) as Y;
> >
> > -- result
> > "x" "y"
> > 540998.1383329581 4515921.565374701
> >
> > I have read that the best way to utilize PROJ.6 capabilities is by
> > allowing the library to freely choose the best possible transformation
> > paths
> > between the origin and the destination CRSes.
> >
> > Does someone know how to find which specific transformation pipeline
> > has been chosen by the PROJ.6 library in this specific transformation ?
> >
> > Antonio
> >
> >
> --
> CYBERTEC PostgreSQL International GmbH
> R?merstra?e 19, A-2752 W?llersdorf
> Web: https://www.cybertec-postgresql.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20260226/f0ed8955/attachment.htm>