From andrew.hardy at sabstt.com  Mon Jul  1 08:37:37 2024
From: andrew.hardy at sabstt.com (Andrew Hardy)
Date: Mon, 1 Jul 2024 16:37:37 +0100
Subject: Update postgis in a replicated PostgreSQL 12 database now with
 postgis-3
In-Reply-To: <Znps7rKYC0en7Kkv@c19>
References: <CAKxhU8h1+xREKVfzVXmEqEsO3oO9413+3zKO77_KDm_7ipdCbg@mail.gmail.com>
 <Znps7rKYC0en7Kkv@c19>
Message-ID: <CAKxhU8hD0MMBOwOoP==O5yPw9QX_Rerhc9PBotUB47wQyd_KYQ@mail.gmail.com>

Thank you so much for your response, I appreciate it.

I omitted to mention that before I messaged I had tried to resolve this in
the  pg_proc table and ran the following query:

UPDATE pg_proc SET probin = '$libdir/postgis-3' WHERE probin =
'$libdir/rtpostgis-2.5';

This was probably a mistake (not least that postgis-3 is not the raster
library) and I am wondering if this is resolvable.

I have only just discovered the following documentation:

https://postgis.net/documentation/tips/tip-upgrading-raster-from-2-3/

Q1: And I am wondering if the postgis_extensions_upgrade()  mentioned in
the upgrade instructions assumes one is starting from a particular state
and I need to get back there from my mistake above or if this upgrade
function will resolve things whatever the state.

Q2: Should I still run postgis_full_version() - is this function a
benign query, unlike postgis_extensions_upgrade()  ?

Thanks,

Andrew



On Tue, 25 Jun 2024 at 08:08, Sandro Santilli <strk at kbt.io> wrote:

> Hi Andrew, replies inline
>
> On Mon, Jun 24, 2024 at 05:38:50PM +0100, Andrew Hardy wrote:
>
> > We noticed some odd failures executing a SELECT on a table with a point
> > type column.  The error was: 'could not access file
> "$libdir/postgis-2.5":
> > No such file or directory' .
>
> This means you have some left-over old PostGIS functions in your
> database, so the upgrade was not complete. What does the following
> query return ?
>
>   SELECT postgis_full_version()
>
> --strk;
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20240701/8bb11044/attachment.htm>

From nikhil.dba04 at gmail.com  Wed Jul  3 23:03:17 2024
From: nikhil.dba04 at gmail.com (Nikhil Shetty)
Date: Thu, 4 Jul 2024 11:33:17 +0530
Subject: GDAL dependencies during PostGIS upgrade
In-Reply-To: <8dd913824c21a444654158f0f421b0a96dcfbab4.camel@gunduz.org>
References: <CAFpL5VxL0e4HRtCDpnw7W0Nemv6onMUaT1_kecHSbJoH_DaVGQ@mail.gmail.com>
 <000b01da6098$5444c720$fcce5560$@pcorp.us>
 <CAFpL5VwMd8nPp8m-eif4a18aEfoUsQYW38wrKOVVGBKTQQM5jQ@mail.gmail.com>
 <CAFpL5Vym8XhDUL7ggR4Oy=UkWYTmrS9r1r9Od4QZ+2+3qOqWBQ@mail.gmail.com>
 <8dd913824c21a444654158f0f421b0a96dcfbab4.camel@gunduz.org>
Message-ID: <CAFpL5VxjZzcBB_ZbCJi7U+En+th3kCdLUTke=Q_mYrOO6=iBAQ@mail.gmail.com>

Hi Devrim,

(RPM packager speaking) From packaging point of view this means
> raster2pgsql has the same build id between 13 and 15, so that's why you
> are seeing this error.  Let me see if I can do something there. Until
> then please remove postgis33_13 client package  as it does not have
> anything to do with the update. After you are done, you can install
> postgis33_15.


Just wanted to check if the dependency due to the same build id is resolved
?

On Wed, Feb 21, 2024 at 3:51?PM Devrim G?nd?z <devrim at gunduz.org> wrote:

> Hi,
>
> On Tue, 2024-02-20 at 22:37 +0530, Nikhil Shetty wrote:
> > I upgraded the existing PostGIS 3.1.2 to 3.3.5 on PG13 but now when I
> > am trying to install PostGIS 3.3.5 for PG15 , I am getting below error
> >
> > Error: Transaction test error:
> >
> >   file /usr/lib/.build-id/b6/89201f4430759c8544cd168dc6ba3e24f7d912
> > from install of postgis33_15-client-3.3.5-1PGDG.rhel8.x86_64 conflicts
> > with file from package postgis33_13-client-3.3.5-1PGDG.rhel8.x86_64
>
> (RPM packager speaking) From packaging point of view this means
> raster2pgsql has the same build id between 13 and 15, so that's why you
> are seeing this error.  Let me see if I can do something there. Until
> then please remove postgis33_13 client package  as it does not have
> anything to do with the update. After you are done, you can install
> postgis33_15.
>
> Regards,
> --
> Devrim G?nd?z
> Open Source Solution Architect, PostgreSQL Major Contributor
> Twitter: @DevrimGunduz , @DevrimGunduzTR
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20240704/15335aef/attachment.htm>

From lr at pcorp.us  Thu Jul  4 22:03:03 2024
From: lr at pcorp.us (Regina Obe)
Date: Fri, 5 Jul 2024 01:03:03 -0400
Subject: PostGIS 3.5.0alpha1 released supports PG17
Message-ID: <000701dace98$9e12bd30$da383790$@pcorp.us>

I've pushed out PostGIS 3.5.0alpha1 release.  This is the first release to
work with PostgreSQL 17.

This version requires PostgreSQL 12 - 17, GEOS 3.8 or higher, and Proj 6.1+.
To take advantage of all features, GEOS 3.12+ is needed. To take advantage
of all SFCGAL features, SFCGAL 1.5.0+ is needed.

Details here:

https://postgis.net/2024/07/PostGIS-3.5.0alpha1/

NEWS: https://git.osgeo.org/gitea/postgis/postgis/raw/tag/3.5.0alpha1/NEWS
Source: https://download.osgeo.org/postgis/source/postgis-3.5.0alpha1.tar.gz

Please report on our ticket tracker if you run into issues

https://trac.osgeo.org/postgis

Thanks,
PostGIS Development Team


From lr at pcorp.us  Sat Jul  6 12:15:55 2024
From: lr at pcorp.us (Regina Obe)
Date: Sat, 6 Jul 2024 15:15:55 -0400
Subject: PostGIS 3.5.0alpha2 released supports PG17
Message-ID: <000001dacfd8$ed859090$c890b1b0$@pcorp.us>

PostGIS 3.5.0alpha2 is released.  This version fixes an issue with the tar
ball that made it fail because of test failures
discovered by Bas Couwenberg

https://trac.osgeo.org/postgis/ticket/5759

This version requires PostgreSQL 12 - 17, GEOS 3.8 or higher, and Proj 6.1+.
To take advantage of all features, GEOS 3.12+ is needed. 
To enable postgis_sfcgal support SFCGAL 1.4-1.5 is required.
To take advantage of all SFCGAL features, SFCGAL 1.5 is needed.

Details here:

https://postgis.net/2024/07/PostGIS-3.5.0alpha2/

NEWS: https://git.osgeo.org/gitea/postgis/postgis/raw/tag/3.5.0alpha2/NEWS
Source: https://download.osgeo.org/postgis/source/postgis-3.5.0alpha2.tar.gz

Please report on our ticket tracker if you run into issues

https://trac.osgeo.org/postgis

Thanks,
PostGIS Development Team


From devrim at gunduz.org  Mon Jul  8 01:08:40 2024
From: devrim at gunduz.org (Devrim =?ISO-8859-1?Q?G=FCnd=FCz?=)
Date: Mon, 08 Jul 2024 11:08:40 +0300
Subject: GDAL dependencies during PostGIS upgrade
In-Reply-To: <CAFpL5VxjZzcBB_ZbCJi7U+En+th3kCdLUTke=Q_mYrOO6=iBAQ@mail.gmail.com>
References: <CAFpL5VxL0e4HRtCDpnw7W0Nemv6onMUaT1_kecHSbJoH_DaVGQ@mail.gmail.com>
 <000b01da6098$5444c720$fcce5560$@pcorp.us>
 <CAFpL5VwMd8nPp8m-eif4a18aEfoUsQYW38wrKOVVGBKTQQM5jQ@mail.gmail.com>
 <CAFpL5Vym8XhDUL7ggR4Oy=UkWYTmrS9r1r9Od4QZ+2+3qOqWBQ@mail.gmail.com>
 <8dd913824c21a444654158f0f421b0a96dcfbab4.camel@gunduz.org>
 <CAFpL5VxjZzcBB_ZbCJi7U+En+th3kCdLUTke=Q_mYrOO6=iBAQ@mail.gmail.com>
Message-ID: <5e66e6fefc6a30ec80fb084eff34ad01ef27db43.camel@gunduz.org>

Hi,

On Thu, 2024-07-04 at 11:33 +0530, Nikhil Shetty wrote:
> Just wanted to check if the dependency due to the same build id is
> resolved ?

Did you check before emailing?

Cheers,
-- 
Devrim G?nd?z
Open Source Solution Architect, PostgreSQL Major Contributor
Twitter: @DevrimGunduz , @DevrimGunduzTR
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 858 bytes
Desc: This is a digitally signed message part
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20240708/3867f38f/attachment.sig>

From julien.pilet at invision.ai  Mon Jul  8 07:12:19 2024
From: julien.pilet at invision.ai (Julien Pilet)
Date: Mon, 8 Jul 2024 16:12:19 +0200
Subject: ST_LocateBetween and M values
Message-ID: <5742aa20-f000-49b1-8b7d-4b6c1132b5d4@invision.ai>

Hi,


There is some strange behavior with ST_LocateBetween: if used with a 0 
offset, it will preserve M values. Otherwise, it will drop them.

Example:


select ST_AsText(ST_LocateBetween(ST_AddMeasure('LINESTRING (20 180, 50 
20, 100 120, 180 20)', 0, 10), 2,5,0 /* no offset */));

returns

MULTILINESTRING M ((34.84090646030401 100.8484988783786 2,50 20 
4.042879736523244,67.23509268015012 54.47018536030024 5))


but

select ST_AsText(ST_LocateBetween(ST_AddMeasure('LINESTRING (20 180, 50 
20, 100 120, 180 20)', 0, 10), 2,5,1 /* non-zero offset */));

returns

MULTILINESTRING((35.823778647238335 101.03278741342879,50.43502803016365 
23.106124037827087,66.3406654891502 54.9173989558002))


The correct behavior is to keep M values. Is that a bug?

What about changing the documentation example on 
https://postgis.net/docs/ST_LocateBetween.html to drop the offset?


Regards,

Julien Pilet



From pramsey at cleverelephant.ca  Mon Jul  8 07:35:59 2024
From: pramsey at cleverelephant.ca (Paul Ramsey)
Date: Mon, 8 Jul 2024 07:35:59 -0700
Subject: ST_LocateBetween and M values
In-Reply-To: <5742aa20-f000-49b1-8b7d-4b6c1132b5d4@invision.ai>
References: <5742aa20-f000-49b1-8b7d-4b6c1132b5d4@invision.ai>
Message-ID: <38209CC6-1EA0-42A1-BCEB-504FC4762ABF@cleverelephant.ca>

Confirmed 
https://trac.osgeo.org/postgis/ticket/5762#ticket

> On Jul 8, 2024, at 7:12?AM, Julien Pilet <julien.pilet at invision.ai> wrote:
> 
> Hi,
> 
> 
> There is some strange behavior with ST_LocateBetween: if used with a 0 offset, it will preserve M values. Otherwise, it will drop them.
> 
> Example:
> 
> 
> select ST_AsText(ST_LocateBetween(ST_AddMeasure('LINESTRING (20 180, 50 20, 100 120, 180 20)', 0, 10), 2,5,0 /* no offset */));
> 
> returns
> 
> MULTILINESTRING M ((34.84090646030401 100.8484988783786 2,50 20 4.042879736523244,67.23509268015012 54.47018536030024 5))
> 
> 
> but
> 
> select ST_AsText(ST_LocateBetween(ST_AddMeasure('LINESTRING (20 180, 50 20, 100 120, 180 20)', 0, 10), 2,5,1 /* non-zero offset */));
> 
> returns
> 
> MULTILINESTRING((35.823778647238335 101.03278741342879,50.43502803016365 23.106124037827087,66.3406654891502 54.9173989558002))
> 
> 
> The correct behavior is to keep M values. Is that a bug?
> 
> What about changing the documentation example on https://postgis.net/docs/ST_LocateBetween.html to drop the offset?
> 
> 
> Regards,
> 
> Julien Pilet
> 
> 


From shishaozhong at gmail.com  Tue Jul  9 02:29:35 2024
From: shishaozhong at gmail.com (Shaozhong SHI)
Date: Tue, 9 Jul 2024 10:29:35 +0100
Subject: uploading geopackage file onto to postgis
Message-ID: <CA+i5JwYYRbaLNaAumfcyfiCLwKtttCrHeRKH7r-DAge=q22GLA@mail.gmail.com>

I cannot upload geopackage file onto postgis.  The error message says
unable to open datasource 'xxxxxxx.pgkg' with the following drivers.

Regards,

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

From nikhil.dba04 at gmail.com  Tue Jul  9 04:02:57 2024
From: nikhil.dba04 at gmail.com (Nikhil Shetty)
Date: Tue, 9 Jul 2024 16:32:57 +0530
Subject: GDAL dependencies during PostGIS upgrade
In-Reply-To: <5e66e6fefc6a30ec80fb084eff34ad01ef27db43.camel@gunduz.org>
References: <CAFpL5VxL0e4HRtCDpnw7W0Nemv6onMUaT1_kecHSbJoH_DaVGQ@mail.gmail.com>
 <000b01da6098$5444c720$fcce5560$@pcorp.us>
 <CAFpL5VwMd8nPp8m-eif4a18aEfoUsQYW38wrKOVVGBKTQQM5jQ@mail.gmail.com>
 <CAFpL5Vym8XhDUL7ggR4Oy=UkWYTmrS9r1r9Od4QZ+2+3qOqWBQ@mail.gmail.com>
 <8dd913824c21a444654158f0f421b0a96dcfbab4.camel@gunduz.org>
 <CAFpL5VxjZzcBB_ZbCJi7U+En+th3kCdLUTke=Q_mYrOO6=iBAQ@mail.gmail.com>
 <5e66e6fefc6a30ec80fb084eff34ad01ef27db43.camel@gunduz.org>
Message-ID: <CAFpL5VxWJpzsX+uXQBSHOHPPE=T2WCpUcnA5842Jaepv5=O1-w@mail.gmail.com>

Hi,

Yes, I still see this error

Error: Transaction test error:

  file /usr/lib/.build-id/b6/89201f4430759c8544cd168dc6ba3e24f7d912 from
install of postgis33_15-client-3.3.5-1PGDG.rhel8.x86_64 conflicts with file
from package postgis33_13-client-3.3.5-1PGDG.rhel8.x86_64


Thanks,

Nikhil


On Mon, Jul 8, 2024 at 1:38?PM Devrim G?nd?z <devrim at gunduz.org> wrote:

> Hi,
>
> On Thu, 2024-07-04 at 11:33 +0530, Nikhil Shetty wrote:
> > Just wanted to check if the dependency due to the same build id is
> > resolved ?
>
> Did you check before emailing?
>
> Cheers,
> --
> Devrim G?nd?z
> Open Source Solution Architect, PostgreSQL Major Contributor
> Twitter: @DevrimGunduz , @DevrimGunduzTR
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20240709/f5d1a02e/attachment.htm>

From senhor.neto at gmail.com  Tue Jul  9 23:51:05 2024
From: senhor.neto at gmail.com (Alexandre Neto)
Date: Wed, 10 Jul 2024 06:51:05 +0000
Subject: uploading geopackage file onto to postgis
In-Reply-To: <CA+i5JwYYRbaLNaAumfcyfiCLwKtttCrHeRKH7r-DAge=q22GLA@mail.gmail.com>
References: <CA+i5JwYYRbaLNaAumfcyfiCLwKtttCrHeRKH7r-DAge=q22GLA@mail.gmail.com>
Message-ID: <ea9e1d08-ca28-4cdf-aa58-2918040fc355@mail.shortwave.com>

Hi David,

Can you provide more details about the issue you're encountering? Specifically:
- The exact error message you're seeing.
- The version of PostGIS and PostgreSQL you are using.
- The steps you followed to upload the geopackage file.
- Any relevant configuration settings or logs.

This information will help us diagnose the problem more effectively.

Thanks,
Alexandre

Sent with Shortwave <https://www.shortwave.com?utm_medium=email&utm_content=signature&utm_source=c2VuaG9yLm5ldG9AZ21haWwuY29t>

On Tue Jul 9, 2024, 09:29 AM GMT, Shaozhong SHI <mailto:shishaozhong at gmail.com> wrote:
> I cannot upload geopackage file onto postgis. The error message says unable to open datasource 'xxxxxxx.pgkg' with the following drivers.
>
> Regards,
>
> David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20240710/9f2ebd47/attachment.htm>

From shishaozhong at gmail.com  Wed Jul 10 02:10:49 2024
From: shishaozhong at gmail.com (Shaozhong SHI)
Date: Wed, 10 Jul 2024 10:10:49 +0100
Subject: uploading geopackage file onto to postgis
In-Reply-To: <6b9d515c-d9b8-427a-b5a3-49c22a05ef7a@gwdg.de>
References: <CA+i5JwYYRbaLNaAumfcyfiCLwKtttCrHeRKH7r-DAge=q22GLA@mail.gmail.com>
 <6b9d515c-d9b8-427a-b5a3-49c22a05ef7a@gwdg.de>
Message-ID: <CA+i5JwZFdOGhSnvCN7RkRGS3jdEipH72ptV0YnzGOxMTO3Mr9Q@mail.gmail.com>

Thank you very much.  It was mis-typing problem.

By the way, how to install FileGDB driver in Linux environment?

Regards,

*David*

On Wed, 10 Jul 2024 at 10:05, Rainer Hurling <rhurlin at gwdg.de> wrote:

> Am 09.07.24 um 11:29 schrieb Shaozhong SHI:
> > I cannot upload geopackage file onto postgis.  The error message says
> > unable to open datasource 'xxxxxxx.pgkg' with the following drivers.
> >
> > Regards,
> >
> > David
>
> Maybe it is only a typo? Try 'xxxxxxx.gpkg' instead of 'xxxxxxx.pgkg'?
>                                        ^^^^
>
> HTH,
> Rainer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20240710/e9601681/attachment.htm>

From rhurlin at gwdg.de  Wed Jul 10 02:05:18 2024
From: rhurlin at gwdg.de (Rainer Hurling)
Date: Wed, 10 Jul 2024 11:05:18 +0200
Subject: uploading geopackage file onto to postgis
In-Reply-To: <CA+i5JwYYRbaLNaAumfcyfiCLwKtttCrHeRKH7r-DAge=q22GLA@mail.gmail.com>
References: <CA+i5JwYYRbaLNaAumfcyfiCLwKtttCrHeRKH7r-DAge=q22GLA@mail.gmail.com>
Message-ID: <6b9d515c-d9b8-427a-b5a3-49c22a05ef7a@gwdg.de>

Am 09.07.24 um 11:29 schrieb Shaozhong SHI:
> I cannot upload geopackage file onto postgis.? The error message says 
> unable to open datasource 'xxxxxxx.pgkg' with the following drivers.
> 
> Regards,
> 
> David

Maybe it is only a typo? Try 'xxxxxxx.gpkg' instead of 'xxxxxxx.pgkg'?
                                       ^^^^

HTH,
Rainer


From di at nmfay.com  Sun Jul 14 14:04:03 2024
From: di at nmfay.com (Dian Fay)
Date: Sun, 14 Jul 2024 17:04:03 -0400
Subject: ST_Clip, subpixel polygons, and related curiosities
Message-ID: <D2PKEQXBO9HK.1ERP4UVL3MOBW@nmfay.com>

When I went digging I found a TODO note "test polygon smaller than
pixel" in the ST_Clip source, so that goes a long way toward explaining
my initial issues. I started with 3.4 and upgraded to 3.5-dev (commit
2860cdd1, built from source) when I saw ST_Clip got the `touched`
argument. The new function signature was available immediately but
returned the same results until I came back after restarting Postgres
this morning, at which point it did exactly what I hoped for. There are
some other interesting things going on that I thought would be worth
writing up.

Here's a script that clips an all-999 raster to three numbered,
successively smaller triangles:

```
with r as (
  select st_addband(
    st_makeemptyraster(300, 251, 97.4999889, 52.716667838, .008333333, -.00833333, 0, 0, 4326),
    1, '16BSI', 999, -32768
  ) as rast
), g as (
  select 1 as rn, st_setsrid(st_geomfromtext('POLYGON((98 52,98 52.1,98.01 52,98 52))'), 4326) as geom
  union
  select 2 as rn, st_setsrid(st_geomfromtext('POLYGON((98 52,98 52.1,98.005 52,98 52))'), 4326) as geom
  union
  select 3 as rn, st_setsrid(st_geomfromtext('POLYGON((98 52,98 52.1,98.004 52,98 52))'), 4326) as geom
), c as (
  select rast, geom, rn, st_clip(rast, 1, geom, -32768) as clipped
  -- try using the `touched` arg in 3.5.0; if just upgrading from 3.4,
  -- results are the same until the server restarts
  -- select rast, geom, rn, st_clip(rast, 1, geom, -32768, true, true) as clipped
  from r, g
)
select
  rn,
  st_summary(clipped) as clipped_summary,
  (st_summarystats(clipped)).*,
  st_value(clipped, st_centroid(geom)) as clipped_centroid_value
from c
order by rn;
```

Things I understand about the results:

- All clipped rasters have the same dimensions. The minimum width is 2px
  whether the clip triangle's x-length is the high bound of 1/100? or
  the low bound 1/250?.
- Somewhere between 1/200? and 1/250?, the length is too short for
  ST_Clip with `touched=false` to populate even one pixel's value --
  there is a point (if you will) at which it rounds down to nothingness,
  indicated by ST_SummaryStats' `count` reaching 0.
- `clipped_centroid_value` becomes null _before_ ST_SummaryStats reaches
  zero-count. My guess is that the data pixels are aligned vertically
  (stacked) since the triangles are taller than they are long, and so
  the centroid of triangle 2 falls just barely in the second column
  which is all NODATA.

Something I don't yet understand: ST_SummaryStats prints the "All pixels
of band have the NODATA value" NOTICE message one time per row six
times, once for each attribute of the `summarystats` type. If you select
`st_summarystats(clipped)` as a tuple without the parentheses-asterisk
decomposition, it prints once. I found the message in
rt_band_get_summary_stats, but I'm not sure why that would execute
multiple times in the one case.

And I found a really odd behavior change while working on a fallback
strategy before I found the new `touched` arg. Add the following lines
to the final select list with ST_Clip `touched=false`:

```
  -- st_astext((st_intersection(clipped, geom)).geom) as tile_intersection,
  -- (st_valuecount(clipped)).*,
```

Uncomment ST_ValueCount. There's a new NOTICE, "Cannot count the values
for the band at index 1", and row 3 -- where the clipped raster is fully
NODATA -- is gone, with only two records returned.

Now uncomment the ST_Intersection. It still prints "Cannot count", _but_
it returns the third row! Both `value` and `count` are null as might be
expected. Intersecting the original raster also preserves the third row.
Is ST_ValueCount silently dropping all-NODATA rows? And why does an
unrelated invocation of ST_Intersection bring them back?

From Peter.Foley at lexisnexisrisk.com  Mon Jul 15 07:02:12 2024
From: Peter.Foley at lexisnexisrisk.com (Foley, Peter (RIS-DBN))
Date: Mon, 15 Jul 2024 14:02:12 +0000
Subject: calculating distances using geographies
Message-ID: <DS0PR08MB9185C9A2DB4294EA071EAFBE95A12@DS0PR08MB9185.namprd08.prod.outlook.com>

Hi,

Following a recent upgrade from postgresql 10 / postgis 2.5.3 to posgresql 15.0 / postgis 3.4.2, we  have noticed that distances calculated using geography types appear to return incorrect results in the new version. postgresql 10 / postgis 2.5.3 returns the correct results.

For example, the following wgs84 polygons are 1.65m apart but st_distance and st_dwithin report them as 0m apart when casting them to geographies

select st_distance(st_geometryfromtext('POLYGON ((-1.7485534738529238 52.477989324720184, -1.7485528426344397 52.47797089391474, -1.748563887653701 52.47797046786393, -1.7485727216213993 52.47797048661752, -1.7485733502887397 52.47798936691661, -1.7485739840754728 52.478007348228196, -1.748563677771212 52.47800732634904, -1.7485541076315525 52.47800730603188, -1.7485534738529238 52.477989324720184))',4326)::geography,st_geometryfromtext('POLYGON ((-1.748665164272404 52.47789651546308, -1.748705653223533 52.477896601376905, -1.7487057222918938 52.47788446504611, -1.7487307518185344 52.47788451814952, -1.7487299491521497 52.47789620342481, -1.7487660211267058 52.477896279947124, -1.748767153309673 52.477956065736684, -1.7486648265496951 52.477955848635304, -1.7485639721184771 52.477955634571074, -1.7484653236191374 52.47795587460495, -1.748465659049668 52.47789699092737, -1.7485017310241382 52.477897067530265, -1.7485018001486063 52.47788493119968, -1.7485297717654242 52.47788544009214, -1.7485297103282949 52.477896227941585, -1.748562835091827 52.47789674776739, -1.7485996432291142 52.47789682590328, -1.7485997123266428 52.47788468957258, -1.7486276865033974 52.47788474894817, -1.748627619972449 52.477896435785155, -1.748665164272404 52.47789651546308))',4326)::geography,true)

st_distancespheroid using the geometries returns the correct distance:

select st_distancespheroid(st_geometryfromtext('POLYGON ((-1.7485534738529238 52.477989324720184, -1.7485528426344397 52.47797089391474, -1.748563887653701 52.47797046786393, -1.7485727216213993 52.47797048661752, -1.7485733502887397 52.47798936691661, -1.7485739840754728 52.478007348228196, -1.748563677771212 52.47800732634904, -1.7485541076315525 52.47800730603188, -1.7485534738529238 52.477989324720184))',4326),st_geometryfromtext('POLYGON ((-1.748665164272404 52.47789651546308, -1.748705653223533 52.477896601376905, -1.7487057222918938 52.47788446504611, -1.7487307518185344 52.47788451814952, -1.7487299491521497 52.47789620342481, -1.7487660211267058 52.477896279947124, -1.748767153309673 52.477956065736684, -1.7486648265496951 52.477955848635304, -1.7485639721184771 52.477955634571074, -1.7484653236191374 52.47795587460495, -1.748465659049668 52.47789699092737, -1.7485017310241382 52.477897067530265, -1.7485018001486063 52.47788493119968, -1.7485297717654242 52.47788544009214, -1.7485297103282949 52.477896227941585, -1.748562835091827 52.47789674776739, -1.7485996432291142 52.47789682590328, -1.7485997123266428 52.47788468957258, -1.7486276865033974 52.47788474894817, -1.748627619972449 52.477896435785155, -1.748665164272404 52.47789651546308))',4326))

Has anyone noticed this issue before? It occurs to me that there may be a configuration option that we need to set when installing postgis.

Many thanks,


Peter Foley

Senior Data Scientist II

++353 1 247 1527 Direct

peter.foley at lexisnexisrisk.com<mailto:peter.foley at lexisnexisrisk.com>

[cid:764600d2-550f-41fa-a0df-f611a45270f2]<https://risk.lexisnexis.com/>



________________________________
The information contained in this e-mail message is intended only for the personal and confidential use of the recipient(s) named above. This message may be an attorney-client communication and/or work product and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this document in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20240715/1eaba756/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Outlook-eotep3pw.png
Type: image/png
Size: 28867 bytes
Desc: Outlook-eotep3pw.png
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20240715/1eaba756/attachment.png>

From mwtoews at gmail.com  Fri Jul 19 03:08:55 2024
From: mwtoews at gmail.com (Mike Taves)
Date: Fri, 19 Jul 2024 22:08:55 +1200
Subject: calculating distances using geographies
In-Reply-To: <DS0PR08MB9185C9A2DB4294EA071EAFBE95A12@DS0PR08MB9185.namprd08.prod.outlook.com>
References: <DS0PR08MB9185C9A2DB4294EA071EAFBE95A12@DS0PR08MB9185.namprd08.prod.outlook.com>
Message-ID: <CAM2FmMphN2eXC6v7AwNxCdB_Q03oUiGbWi0CtkpBDkP=MQ2UPg@mail.gmail.com>

On Tue, 16 Jul 2024 at 02:10, Foley, Peter (RIS-DBN) via postgis-users
<postgis-users at lists.osgeo.org> wrote:
> Following a recent upgrade from postgresql 10 / postgis 2.5.3 to posgresql 15.0 / postgis 3.4.2, we  have noticed that distances calculated using geography types appear to return incorrect results in the new version. postgresql 10 / postgis 2.5.3 returns the correct results.

See ticket https://trac.osgeo.org/postgis/ticket/5765