Hi,
This is likely an issue with the support functions for PG12+ thinking
`find_srid('public', 'my_table', 'geometry')` is not constant, or not
enough. Can you open an issue on trac
(https://trac.osgeo.org/postgis/) please?
On Tue, Nov 24, 2020 at 11:23 AM Calvo Arias, Francisco wrote:
>
> Hi al
On Mon, Oct 5, 2020 at 5:27 PM Martin Davis wrote:
>
> PostGIS WKT output does overly-aggressive rounding, IMO.
Not anymore (changed in 3.1+):
template_postgis=# SELECT
ST_AsText(ST_GeomFromWKB('\x0101000ad7a3f0735727c13e0ad7a3ae0c30c1'));
st_astext
Hi all,
SRIDs over 999000 are reserved built in values as defined in [1]. They
reference different UTM grid zones.
As far as I know they are only generated by the _ST_BestSRID function,
which in turn is used to improve precision when doing operations over
geographies (buffer, intersections...).
Hi,
your issue is not with ST_SnapToGrid but with floating point precision.
There is no floating point number that represents 44.0588 exactly, instead
it might be represented by the binary 0x40460786c226809e, which, when
transformed into text, returns the exact result 44.0588005.
If you w
I don't remember the exact details, but restoring functions require
extension types to be fully qualified.
Can you try changing the definition of the _togeom function from
"geog::geometry" to "geog::public.geometry"?
On Thu, Jul 2, 2020 at 6:36 PM pham lan wrote:
>
> Hello all,
>
> I would lik
As Giuseppe mentioned, it only means that Postgis didn't find any
geometry (or all of them were NULL or empty) when gathering
information during the analyze call. It is not an issue, just beware
that Postgres won't have accurate data about that table in order to
better plan the queries.
Also, the
What proj releases are you using? `Select postgis_full_version()` will show it.
It is likely that your 3.0 is using PROJ6+ which has more precise
transformations.
On Thu, Apr 23, 2020 at 2:55 PM David McKelvie wrote:
>
>
> Hello;
>
> Ive noticed a difference between the results returned by st_tr
Hi,
It looks like you might be loading multiple versions of the same
library (likely GEOS) at the same time. Please make sure that both
Postgis and ogr_fdw are built against the exact same dependencies if
you are going to use both in a single SQL session.
On Fri, Mar 6, 2020 at 2:03 PM Zwettler
> If we can find it without ourselves to not have SQL comments anymore, we
can back out some of these weird dependencies.
For postgis (core) I count 287 comments and 694 functions, so less than
half of the functions have a comment associated with it. I'd be ok with
dropping them.
--
Raúl Marín R
On Mon, Feb 3, 2020 at 2:35 PM Christoph Berg wrote:
>
> Since people asked for it, I built 3.1.0alpha1 .deb packages on
> apt.postgresql.org, including packages for PostgreSQL 13devel.
>
Did you use the new configure option (--without-phony-revision) to
prevent `postgis_revision.h` being regene
On Thu, Jan 23, 2020 at 6:23 PM Shaozhong SHI wrote:
>
> I used pg_dump to dump a table with from. Then, I used psql to load it to
> another database, but it showed numerous errors.
>
> Why does that happen?
Hi,
You are not providing any information to debug the issue. The
following informatio
On Thu, Jan 23, 2020 at 5:43 PM Shaozhong SHI wrote:
>
> Numerous errors were found when loading tables with psql.exe. These tables
> were produced with pg_dump.exe.
What are those errors and what commands did you run to dump and to
restore the data?
Also, does the target database has the same
Hi,
On Tue, Jan 14, 2020 at 10:08 AM Michal Zimmermann <
michal.zimmerm...@gmtech.cz> wrote:
> Hi,
> I'm having an issue upgrading from postgresql 11 postgis 3 to postgresql
> 12 postgis 3 via pg_upgrade utility. That's because pg_constraint.consrc
> was removed in postgresql 12 [1]. Is it possib
Hi, it's fixed now, so it'll be part of the future minor releases
(2.5.3, 3.0.1...).
On Tue, Dec 10, 2019 at 11:32 AM wrote:
>
> Hi, this is a bug.
>
> I've created https://trac.osgeo.org/postgis/ticket/4599 to track it.
>
> --
> Raúl Marín Rodríguez
> carto.com
--
Raúl Marín Rodríguez
carto.
Hi, this is a bug.
I've created https://trac.osgeo.org/postgis/ticket/4599 to track it.
--
Raúl Marín Rodríguez
carto.com
___
postgis-users mailing list
postgis-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users
This is a bug in our update process, if you have access to the extension files
($sharedir/extension/postgis--ANY--2.5.2.sql, where sharedir is where postgresql
stores it's share objects, `pg_config --sharedir` should give it to
you) then you can
edit the file, and look for a block like this to dele
+1 to anything that makes it easier to contribute to any of the
current accepted methods
On Thu, Nov 21, 2019 at 8:44 PM Regina Obe wrote:
>
> So it would be
>
> Edit Github , Edit Gitlab then
>
> Seems we can't do Gitea.
>
> -Original Message-
> From: postgis-devel [mailto:postgis-devel
The are waiting for GDAL 3.0.2 to be out to package them together.
Source: https://twitter.com/DevrimGunduz/status/1189216750895882243
In any case, ST_Transform is slower because PROJ6 is slower, but it
shouldn't be that slow.
On Wed, Oct 30, 2019 at 2:54 PM Daryl Herzmann wrote:
>
> Greetings,
Hi,
This seems related to https://trac.osgeo.org/postgis/ticket/4075. What
version of GEOS are you using in each server?
I've tried with Postgis 3.0 and GEOS 3.8 and it hasn't finished after
~10 minutes.
Regards
--
Raúl Marín Rodríguez
carto.com
___
p
19 matches
Mail list logo
