Re: Proj4text is still working

On Wed, Apr 24, 2024 at 6:46 AM José Carlos Martínez via postgis-users wrote: > I am making some changes in proj4text of the spatial_ref_sys table, to apply > a transformation between datums (+towgs84). Don't make changes to existing, defined entries, make yourself a new entry. > It appears

Re: Segmentation fault restoring data to Azure VM

Maybe do a search for library dupes / mismatches in your system for the postgis deps find / -name “postgis*so” find / -name “*libgeos*" find / -name “*libgdal*” find / -name “*libproj*” > On Apr 23, 2024, at 10:20 AM, Jeffrey Durrence > wrote: > > Regina, > > Thank you so much for your

Re: ST_OrientedEnvelope returning parallelogram

ote: > > Riccardo's original data is in EPSG:4326 (I assume) but Riccardo's screenshot > is in EPSG:3857 (geosjon.io <http://geosjon.io/>'s default). Could this be > the reason? > > On Fri, 8 Mar 2024 at 22:39, Paul Ramsey <mailto:pram...@cleverelephant.ca>> wrote: &g

Re: ST_OrientedEnvelope returning parallelogram

I’m seeing the same thing as Martin, the output is rectangular. I see it using the JTS test builder. I see it using QGIS. This is the output, same as you get: POLYGON((-71.25975582815524 42.470679599674035,-71.25956768540266 42.47056830210077,-71.25960032476851

Re: ST_OrientedEnvelope returning parallelogram

cl/fi/xoi87e06mtfsnc1qzw3wu/oriented_2.png?rlkey=37ajuo6lwdnynk9gi8hpmoolq=0 >> > <https://www.dropbox.com/scl/fi/xoi87e06mtfsnc1qzw3wu/oriented_2.png?rlkey=37ajuo6lwdnynk9gi8hpmoolq=0> >> > >> > Any help is appreciated, thanks! >> >> What is your Post

Re: PostGIS Patch Releases

Sorry, this reply didn't hit my main inbox. On Fri, Feb 9, 2024 at 5:50 AM Greg Troxel wrote: > > > Of particular interest to those distributing PostGIS on RHEL variants, > > these fixes include a patch to allow XML parsing to work with the > > latest libxml2 updates being pushed to RHEL. > > I

PostGIS Patch Releases

The PostGIS development team is pleased to provide bug fix releases 3.4.2, 3.3.6, 3.2.7, 3.1.11, 3.0.11, 2.5.10. Please refer to the links below for more information about the issues resolved by these releases. https://git.osgeo.org/gitea/postgis/postgis/raw/tag/3.4.1/NEWS

Re: Postgres segfaults on raster query

This seems… odd to me? In what context is putting postgis into the preload a requirement? P > On Jan 18, 2024, at 8:20 PM, Scott wrote: > > Bam! > > That was it. Thanks Regina, you rock! > > On 1/18/24 20:16, Regina Obe wrote: >> ALTER SYSTEM SET shared_preload_libraries = 'postgis-3';

Re: Postgres segfaults on raster query

You aren’t even hitting the raster subsystem… your target list is rid and your filter is rid… so…? I’d guess you have a seriously borked install, somehow. P > On Jan 18, 2024, at 5:02 PM, Scott wrote: > > Here's what's happening: > > psql -d mydb > > select rid from rastertable where rid =

Re: [postgis-users] What is dbt really is? Can it incorporate PostGIS's geospatial capabilities?

DBT (Data Build Tool) is an open-source command-line tool that enables data analysts and engineers to transform data in their warehouse more effectively. It does this by allowing users to write modular SQL queries, which it then runs in the correct order with the appropriate dependencies. The

Re: [postgis-users] Finding all polygons crossing a large polygons boundary

Sort of ugly but… CREATE TEMPORARY TABLE p_edges AS SELECT p.id , st_subdivide((st_dumprings((st_dump(geom)).geom)).geom) as geom FROM p; CREATE INDEX p_edges_geom_x ON p_edges USING GIST (geom); SELECT a.id , p.id FROM a JOIN p_edges ON

Re: [postgis-users] ST_DWithin slow if query is joined to another table, but fast if ST_DWithin cast to an integer

> On Nov 8, 2023, at 10:10 AM, Regina Obe via postgis-users > wrote: > > First of all is that really your join clause? You seem to be missing an ON > > from building b > join customer c That error neatly explains the performance issue, since it results in a complete cross join of all the

Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

Brent Wood > > Principal Technician, Fisheries > NIWA > DDI: +64 (4) 3860529 > From: postgis-users on behalf of Paul > Ramsey via postgis-users > Sent: Wednesday, November 8, 2023 08:39 > To: Marco Boeringa > Cc: Paul Ramsey ; PostGIS Users Discussion > > Subje

Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

t; Op 7-11-2023 om 20:31 schreef Paul Ramsey: >> All that said… >> >> It would be possible to “fix” this, but it’s a scary black box. >> We already nudge geodetics back into place when casting from geometry to >> geography (interesting workaround, take your

Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

are in fact out of bounds by a very small amount. P. > On Nov 7, 2023, at 11:22 AM, Paul Ramsey wrote: > > Nope. > > It can be quite reasonably argued that the answer is correct, and the problem > is treating EPSG:4326 (a geodetic coordinate system with angular units) as if

Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

with this kind of globe spanning data, but it works for most cases and I > already cast to geography a lot to do stuff where geography is really needed. > > Marco > > Op 7-11-2023 om 19:02 schreef Paul Ramsey: >> >> >>> On Nov 6, 2023, at 3:39 PM, Paul Rams

Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

> On Nov 6, 2023, at 3:39 PM, Paul Ramsey wrote: > > > >> On Nov 6, 2023, at 3:33 PM, Marco Boeringa wrote: >> >> Well, yes indeed that is what is happening, 180 came out of the reprojection >> steps as -180. Full output geometry below. Is there

Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

> On Nov 6, 2023, at 3:33 PM, Marco Boeringa wrote: > > Well, yes indeed that is what is happening, 180 came out of the reprojection > steps as -180. Full output geometry below. Is there any way to prevent this > behavior? > > Marco > Not really… Either snap to grid or reduce precision

Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

--- POINT(-180.14 -79.61138332505551) > On Nov 6, 2023, at 3:26 PM, Paul Ramsey wrote: > > Compare the input and output lists of coordinates, see if there are any big > jumps. The fact that your coordinate inputs include things like > (18

Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

gAdmin, and QGIS. > > If I save the reproducible case to a table, all of them display the > reprojected polygon wrong. > > Marco > > Op 6-11-2023 om 23:58 schreef Paul Ramsey: >> No, it’s more likely a problem with whatever you’re using to visualize the >> data

Re: [postgis-users] Failing ST_Transform with Ross Ice Shelf polygon

No, it’s more likely a problem with whatever you’re using to visualize the data. Proj doesn’t look at the structure of the data (line, poly) it just transforms everything, point by point. So your process (A to B to A) should really just be a null-trip. You can dump the points and see where it

Re: [postgis-users] Postgis on RHEL8

> On Oct 12, 2023, at 10:51 AM, Scott Pasnikowski via postgis-users > wrote: > > > I am starting to think the path to stability if I need to use postgis is to > just build the whole damn thing myself... > Thoughts? Or if your client values your time highly enough, for them to subscribe to

[postgis-users] PostGIS Day 2023, CFP Ending!

Hello all friendly users of PostGIS! I just wanted to remind you all that the Call for Papers for PostGIS Day (coming up on Nov 16) is ending today, and we really really would love to hear your story of PostGIS. What your application is and how it leverages PostGIS? Clever SQL you’ve found for

[postgis-users] PostGIS Day, November 16, 2023 - Come Speak!

Hey all, PostGIS day is on again, as always, the day after GIS Day. https://www.crunchydata.com/community/events/postgis-day-2023 Really hoping to hear from lots of different PostGIS users on what they are up to! P ___ postgis-users mailing list

Re: [postgis-users] strange behavior in ST_SnaptoGrid

One thing to always ask is “why exactly am I doing this snapping operation?” If the answer is “so my numbers look nicer in my UI” then using the second parameter of the ST_AsText() function will give you nice, perfectly rounded-looking outputs just like you want them. ATB, P > On Sep 3, 2023,

Re: [postgis-users] PostGIS crash on ST_ConcaveHull

Thanks, yes a crash is a bug. I have confirmed it exists in GEOS, and filed an issue https://github.com/libgeos/geos/issues/946 P > On Aug 18, 2023, at 6:03 AM, 耳辰 wrote: > > > Hi guys, > > I met a postgis crash when tried to use ST_ConvaveHull function with a > multipoint, in postgis

Re: [postgis-users] [postgis-devel] Problem compiling postgis

and Pankaj. > > Thanks, > Regina > > >> -Original Message- >> From: postgis-devel [mailto:postgis-devel-boun...@lists.osgeo.org] On Behalf >> Of Paul Ramsey >> Sent: Friday, June 2, 2023 3:05 PM >> To: PostGIS Development Discussion >> Cc: Björn Harrtell

Re: [postgis-users] GML ver 3 id duplicated error

Bug or shortcoming, I don’t think we ever had this behaviour, and probably never encountered a validator that checked it. If you can nail down the specific GML version it applies to, that would be helpful in applying a fix. For deeply nested multi-geometries, I can see this being quite…

Re: [postgis-users] Free Online or Cloud PostGreSQL and PostGIS

> On Apr 2, 2023, at 9:44 AM, Martin Davis wrote: > > > On Sun, Apr 2, 2023 at 7:23 AM Tahir Tamba > wrote: >> think CrunchyData is the reference for PostGIS implementation. However, I >> don't know if it is possible to store personal data in it??? >> Brent, I

Re: [postgis-users] Unexpected behaviour in ST_Buffer

This is a know issue, and goes all the way up into JTS https://github.com/locationtech/jts/issues/876 P > On Mar 16, 2023, at 1:04 PM, Regina Obe wrote: > >> Hello, there is a behaviour that I didn't expect with ST_Buffer. > >> Using ST_Buffer on any LINESTRING with a start point the same as

Re: [postgis-users] Points and Row Count Estimates

> On Mar 1, 2023, at 7:23 AM, Gareth Bell wrote: > > Hi postgis-users, > > Please may I have some guidance. I have been looking in to bad row count > estimates for a simple query, similar to the following: >SELECT area_id FROM area WHERE ST_INTERSECTS(area.polygon, ST_MakePoint(x, > y))

Re: [postgis-users] ST_Transform Z heights between ODN and WSG [solved]

Put a whole write-up here http://blog.cleverelephant.ca/2023/02/proj-network.html On Thu, Feb 2, 2023 at 8:00 AM Paul Ramsey wrote: > > > > > On Feb 2, 2023, at 1:58 AM, James Howe wrote: > > > > Thanks for the help to look in the right direction. > > I

Re: [postgis-users] Spaces in numeric fields output by shp2pgsql

You’re going to want to create a ticket and attach the shape file in a zip. You’ve just got some extra funky data. P > On Feb 19, 2023, at 1:51 PM, Brian Panulla wrote: > > I'm trying to load some shapefiles to a PostgreSQL 12/PostGIS 3.1 > database server. The shapefiles in question have a

Re: [postgis-users] Building Heirarchical Topology

> On Feb 8, 2023, at 11:44 AM, Regina Obe wrote: > > TopoElementArray_Agg(elm) Since I have you here: why a "topoelementarray" and not just a topoelement[] (a normal PgSLQ array of topoelement?) If topoelements are no good for building the inputs of topogeoms, what are they good for?

[postgis-users] Building Heirarchical Topology

Hello users, a question! But first all the setup. Starting from a base set of data, census blocks, which come with a nice heirarchical key, so it's easy to create contiguous collections just by struncating the key and grouping. Here's an example key (the column is called geoid20): 530019501001

Re: [postgis-users] ST_Transform Z heights between ODN and WSG [solved]

> On Feb 2, 2023, at 1:58 AM, James Howe wrote: > > Thanks for the help to look in the right direction. > I downloaded the missing data files and it works now. > > # projsync --system-directory --source-id uk_os > > postgres=# SELECT st_asewkt(ST_Transform('SRID=7405;POINT(545068 258591 >

Re: [postgis-users] ST_Transform Z heights between ODN and WSG

cause GBs of grid shift files to be downloaded into the DB instance container. P > On Feb 1, 2023, at 8:51 AM, Paul Ramsey wrote: > > Before then, if there's a proj wizard around, a command-line call that > replicates the desired transform would be nice, to take proj out of &g

Re: [postgis-users] ST_Transform Z heights between ODN and WSG

Before then, if there's a proj wizard around, a command-line call that replicates the desired transform would be nice, to take proj out of the equation as a source of the problem. On Wed, Feb 1, 2023 at 8:48 AM Paul Ramsey wrote: > > I'm seeing something similar in my environment, even

Re: [postgis-users] ST_Transform Z heights between ODN and WSG

I'm seeing something similar in my environment, even going between two systems with explicit vertical datums. pramsey=# SELECT ST_AsTexT(ST_Transform('SRID=7405;POINT(545068 258591 8.51)'::geometry, 3901)); st_astext -

Re: [postgis-users] Whats wrong with this geometry?

303 0.0 85552.172 444962.119 0.0 85552.377 444961.625 0.0 85553.85 444958.064 0.0 85554.257 444957.082 0.0 85554.339 444956.884 0.0 85554.941 444955.428 0.0 85553.17 444954.729 0.0 '); > On Jan 17, 2023, at 2:42 PM, Paul Ramsey wrote: > > It's the higher dimensionality, seems l

Re: [postgis-users] Whats wrong with this geometry?

It's the higher dimensionality, seems like we don't like that. 2D works. select ST_GeomFromGML(' http://www.opengis.net/gml/3.2;> 85553.17 444954.729 85553.307 444954.394 8.891 444948.14 85560.257 444937.574 85561.733 444934.001 85566.998 444936.176 85569.692 444937.289

Re: [postgis-users] Help with ST_Within query issue...

The error on pg10 is interesting and worrying, but at a first approximation your pg14 problem is that you have reversed the coordinate order in your polygon. The order should be longitude/latitude and yours is latitude/longitude. Try ST_GeomFromText('POLYGON((-119.53618 34.67010 , -116.02055

Re: [postgis-users] Row estimations

On Thu, Dec 15, 2022 at 1:03 AM Sandro Santilli wrote: > > On Tue, Dec 13, 2022 at 11:31:05AM -0800, Paul Ramsey wrote: > > Just to put a nail in this one: the last time our selectivity estimates for > > Contains/Within were good was version 2.1, which used the && op

Re: [postgis-users] Row estimations

Just to put a nail in this one: the last time our selectivity estimates for Contains/Within were good was version 2.1, which used the && operator instead of hte ~/@ operators in the SQL wrapper functions. > On Dec 13, 2022, at 9:04 AM, Paul Ramsey wrote: > > On Mon, Dec 12

Re: [postgis-users] Row estimations

is might just be a very very very old bug. P. > > > > -Original Message- > > From: postgis-users [mailto:postgis-users-boun...@lists.osgeo.org] On > Behalf > > Of Paul Ramsey > > Sent: Monday, December 12, 2022 5:57 PM > > To: PostGIS Users Discussion

Re: [postgis-users] Row estimations

n has existed. (Forever?) P. On Fri, Dec 9, 2022 at 10:14 AM Paul Ramsey wrote: > > > > > On Dec 9, 2022, at 10:11 AM, Igor ALBUQUERQUE SILVA > > wrote: > > > > In this example ST_Contains estimates 785 rows, while ST_Intersect > > estimates 61

Re: [postgis-users] Row estimations

> On Dec 9, 2022, at 10:11 AM, Igor ALBUQUERQUE SILVA > wrote: > > In this example ST_Contains estimates 785 rows, while ST_Intersect estimates > 615469 which is closer to the real 621571 rows. Using the bounding box > operation I also obtain good estimations, and I also obtain good

Re: [postgis-users] Row estimations

Experiments are here if you would like to try them. https://github.com/postgis/postgis/pull/713 On Wed, Dec 7, 2022 at 2:22 PM Paul Ramsey wrote: > > So, this is rather hard to explain without pictures, but you have to first of > all recognize that the selectivity estimator is an &

Re: [postgis-users] Row estimations

So, this is rather hard to explain without pictures, but you have to first of all recognize that the selectivity estimator is an "estimator", so you cannot construct synthetic situations and expect things to match exactly. You can just expect them to be worse or better. In particular, things

[postgis-users] PostGIS Day is Thursday! 2022-11-17

If you haven't signed up for PostGIS day, and you're planning to dip in to see this once-a-year online festival of PostGIS, now would be a good time to sign up! We have over 20 great speakers, and a non-stop dawn to dusk agenda, so we hope you can make it!

Re: [postgis-users] Issue with ST_Intersection seems related to lines crossing themself

I'd be interested in a list of Timescale (and mobilitydb) functions that would be useful inside postgis to power up the trajectory functionality. P > On Oct 28, 2022, at 2:22 AM, Rory Meyer wrote: > > Hi Juergen, > > I wrote a quick blog post about how I grouped up AIS points into lines, but

Re: [postgis-users] Queries slow after PostGIS upgrade

On Wed, Oct 26, 2022 at 3:03 PM Christopher Swingley wrote: > Can you do EXPLAIN ANALYZE on both systems for a query that's slower on the > AWS side to see what's consuming more time? Importantly, "EXPLAIN ANALYZE" will give you the database-side execution time of a given query, and won't be

Re: [postgis-users] ogr-fdw for Postgres 15 Ubuntu 22.04

Moral of the story being: always run your extension against pre-release regularly. Oh well! P. > On Oct 20, 2022, at 8:50 AM, Richard Greenwood > wrote: > > I received the reply below from the pgsql-pkg-deb...@lists.postgresql.org > list and install postgresql-15-ogr-fdw is now available in

Re: [postgis-users] ogr-fdw for Postgres 15 Ubuntu 22.04

Best to note to the packagers. I haven't heard any word about it being deliberately dropped, but...? On Mon, Oct 17, 2022 at 5:54 AM Richard Greenwood wrote: > > I use the pgdg apt repo http://apt.postgresql.org/pub/repos/apt but it > doesn't have postgresql-15-ogr-fdw. Is this a deliberate

Re: [postgis-users] DE-9IM pattern for gaps

No. In DE9IM a gap is no different from a chasm. > On Jul 6, 2022, at 8:48 AM, Shaozhong SHI wrote: > > Is there a DE-9IM pattern for gaps? > Regards, > David > ___ > postgis-users mailing list > postgis-users@lists.osgeo.org >

[postgis-users] GEOS 3.11.0 Released

previous implementation, for those kinds of inputs. For "normal" inputs, the results should look very much like the old implementation. As usual, numerous bugs have been fixed, and a few performance improvements discovered and implemented. - New things: - OffsetCurve (GH-530, Paul

Re: [postgis-users] ST_OffsetCurve

equest will be key. > Simon > > 39 Cliff View Drive > Allens Rivulet Tas 7150 > (W) 0418 396 391 > On 6 May 2022, at 04:44, Paul Ramsey wrote: > Hi Simon, > This is going to be one of those annoying "you should upgrade!" answers. You > should upgrade! > In

Re: [postgis-users] ST_OffsetCurve

Hi Simon, This is going to be one of those annoying "you should upgrade!" answers. You should upgrade! In particular, the new offset curve in the latest GEOS (3.10+) does not have this behaviour. ATB, P > On May 4, 2022, at 11:32 PM, Simon Greener wrote: > > I have a simple linestring that

Re: [postgis-users] best and simple way to downgrade PostGIS from 13.6 to 13.5

> On Apr 25, 2022, at 8:30 AM, Shaozhong SHI wrote: > > What the simplest and best way to downgrade PostGIS from 13.6 to 13.5? > > Can we do anything like the following? > > Step 1. Move the old database to one side Step 1, stop the database > 2 delete the old 13.6 binaries > 3

Re: [postgis-users] PostGis introduction doc code block seems wrong....

Well now that you mention it, it does seem funky, and I have no idea what the expected behavour is... create table foo (old text, new text); insert into foo (old) values ('1234'); update foo set old = left(old, 2), new = old where old = '1234'; select * from foo; I'm going to go out on a

Re: [postgis-users] A table of DE-9IE patterns and types of topological relations

https://postgis.net/workshops/postgis-intro/de9im.html > On Apr 14, 2022, at 4:35 PM, Shaozhong SHI wrote: > > The use of ST_Relate appears very attractive. However, there appears not yet > a table detailing DE_9IE patterns and types of topological relations. > > There also appears that not

Re: [postgis-users] postgis type size

Geometry is a variable sized type (aka "varlena") like strings so there is not a fixed size. You can see the storage size of any given geometry with st_memsize(). Geometry is 8-byte aligned and internally packed already so there's nothing further to be gained by juggling its position in the

Re: [postgis-users] Long running processes and commit writing to disk

Build your loop in plpgsql with an exception handler to write out broken cases to a side table, and your good results to an output table. > On Apr 8, 2022, at 9:38 AM, Shaozhong SHI wrote: > > When long running processes got disrupted, one may not see any expected > result. > > How to make

Re: [postgis-users] ST_Transform weirdness in 3.1.5

(Internal)" > (1 row) > > Could this be something with the proj configuration? Does calling > ST_Transform using an SRID use some sort of internal proj > configuration that may be weird or does it pull the proj4text from the > spatial_ref_sys table? There are other differences

Re: [postgis-users] ST_Transform weirdness in 3.1.5

Not super obvious as I'm not seeing a reproduction here on a more recent proj. Anyone with proj6 able to reproduce? P > On Apr 4, 2022, at 9:18 AM, Jeff Hoffmann wrote: > > I am running PostgreSQL via Amazon RDS. Here is the version > information for the instance that exhibits the problem: >

Re: [postgis-users] Function question

> On Mar 14, 2022, at 11:40 PM, Simon SPDBA Greener wrote: > > Fellow PostGISers, > > I have two environments. > > select Version() >"PostgreSQL 10.9 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.5 > 20150623 (Red Hat 4.8.5-36), 64-bit" > select PostGIS_Full_Version() >

Re: [postgis-users] Is there any function for calculating angle between 2 line segments in 3D?

Nothing built it. Fire up your plpgsql chops and calculate the arccos() of the dot product of your segment of interest. On Sun, Feb 27, 2022 at 2:39 AM Shaozhong SHI wrote: > > Regards, > > David > ___ > postgis-users mailing list >

Re: [postgis-users] Non-linear time cost; please suggest a better way to structure the query

You may need to materialize the trajectories so you can spatially index them On Wed, Feb 23, 2022 at 6:14 AM Rory Meyer wrote: > Afternoon all, > > I've got a database full of GPS points (along with associated data like > speed, bearing, time, GPS_ID, class etc) and I'm trying to do complex >

Re: [postgis-users] Are there script examples for determine where vertices run clockwise or anti-clockwise?

Without closure it is not possible to say what orientation a linestring has. ST_IsPolygonCW(ST_MakePolygon(ST_AddPoint(linestring, ST_StartPoint(linestring P > On Feb 16, 2022, at 11:31 PM, Shaozhong SHI wrote: > > How about each line gets split into segments. . Each segment is

Re: [postgis-users] PSC Vote: Drop PostgreSQL 9.6 and PostgreSQL 10 in PostGIS 3.3

+1 paul On Sat, Feb 12, 2022 at 9:22 PM Regina Obe wrote: > PostgreSQL 9.6 has reached EOL so I don't think there is any point in > supporting it in PostGIS 3.3. > > https://www.postgresql.org/support/versioning/ > > > PostgreSQL 10 will be EOL'd before or very close to our planned 3.3 release

Re: [postgis-users] st_intersects and st_disjoint inconsistent results

44840CCAF8B474EA24CC02CCCE78134B44840D7158E7B4EA24CC01D7C17A53AB44840ACFA01B452A24CC02688BA0F40B44840DB508C8752A24CC006CDF80846B44840A1F31ABB44A24CC0C891730756B44840009AF7EE45A24CC06B7649415CB448408C2ECAC749A24CC0CE57248161B44840A74302A150A24CC07DD00E1368B44840 > > On 2022-02-10 5:57 p.m., Paul Ramsey wrote: >>> 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 >

Re: [postgis-users] st_intersects and st_disjoint inconsistent results

> 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

Re: [postgis-users] Help shaping the future: how do your use of spatial_ref_sys ?

> On Feb 10, 2022, at 7:10 AM, Jim Klassen wrote: > > On 2/9/22 03:31, Sandro Santilli wrote: >> Would you be disappointed/surprised by a PostGIS upgrade >> replacing your custom entries above 20 with some new >> "official" entry ? What strategy did you set in place to >> prevent this ? >

Re: [postgis-users] Trouble with ST_ShortestLine: the returned line DOES NOT start in g1 and end in g2

If the shortest line runs vertext-to-vertext I would expect it to touch both lines. If on the other hand it runs vertex-to-midsegment I would expect it is possible it would not touch. Check the distance of the shortest line to the two parent lines. It should be zero or very very very small.

Re: [postgis-users] Help shaping the future: how do your use of spatial_ref_sys ?

On Fri, Feb 4, 2022 at 2:23 PM Jim Klassen wrote: > We've been starting at 20 and using EPSG (misusing the "EPSG" auth kept > Proj 4/GDAL/MapServer happier, this likely isn't necessary with Proj 8). We > maintain matching record(s) in our proj4 epsg database file (again this will >

Re: [postgis-users] Bugreport

For what it's worth there's no segfault on a modern GEOS (3.9+). > On Feb 2, 2022, at 2:47 AM, Paul van der Linden > wrote: > > Tried to find a place where I could post a bug-report, but got a bit lost in > old pages, creating accounts etc, so I'll post it here. > > Versions used: >

Re: [postgis-users] Determine Postgis Raster Usage

Other than turning on statement logging and parsing for use of raster functions, I do not think so. > On Feb 1, 2022, at 8:00 AM, Nikhil Shetty wrote: > > Hi Team, > > Is there a way to confirm if raster is being used by the application team? > PostGIS version - 2.5.4 > > From PostGIS

Re: [postgis-users] hard upgrade from 1.5

> On Jan 11, 2022, at 9:45 AM, Nathan Wagner wrote: > > On Tue, Jan 11, 2022 at 01:18:27AM +0100, Sandro Santilli wrote: >> On Mon, Jan 10, 2022 at 10:18:34AM -0800, Paul Ramsey wrote: >>>> On Jan 10, 2022, at 10:01 AM, Nathan Wagner wrote: >>> >>&

Re: [postgis-users] hard upgrade from 1.5

> On Jan 10, 2022, at 10:01 AM, Nathan Wagner wrote: > > I am working on an upgrade from postgis 1.5 on postgresql 9.0 to postgis > 2.5 on postgresql 11. > > The docs say that a hard upgrade is needed. Is that still true if we're > migrating the data from one database to another? Our

Re: [postgis-users] shp2pgsql not present

It's in a separate package. Do an 'apt-cache search' for postgis and see if you can see a client or util package, something like that. P > On Jan 10, 2022, at 8:44 AM, Alain Benard wrote: > > Hi, > I recently migrate from Centos 8 / Postgres 12 / Postgis 3.x to Ubundut LTS > 20.04, postgres

Re: [postgis-users] Getting data from table with interval

sian space). Trust the geography result. P > On Jan 7, 2022, at 12:26 PM, Luca Bertoncello wrote: > > Am 07.01.2022 um 21:20 schrieb Paul Ramsey: >> Yep, I cut'n'pasted the wrong example. >> >> >> EXPLAIN ANALYZE >> SELECT *, >> latlng <->

Re: [postgis-users] Getting data from table with interval

Yep, I cut'n'pasted the wrong example. EXPLAIN ANALYZE SELECT *, latlng <-> '010120E610E17A14AE47412C40BC74931804A64940' AS dist FROM elevation2x2 ORDER BY dist LIMIT 5; > On Jan 7, 2022, at 12:19 PM, Luca Bertoncello wrote: > > Am 07.01.2022 um 20:53 schrieb Paul

Re: [postgis-users] Getting data from table with interval

> > Well, this was a very hard job... > I got the EU-DEM data from > https://land.copernicus.eu/imagery-in-situ/eu-dem/eu-dem-v1.1?tab=download > Then I converted the 38GB TIFFs in an SQL database. First of all, I > reduced the precision, since 25 meter is for flying too much precision. > One or

Re: [postgis-users] Getting data from table with interval

You have an index on the geography, but you cast to geometry in your distance calc, so the index helps you not at all. Do this SELECT *, ST_Distance(latlng, '010120E610E17A14AE47412C40BC74931804A64940') AS dist FROM elevation ORDER BY dist LIMIT 5; > On Jan 7, 2022, at 11:18 AM, Luca

Re: [postgis-users] Getting data from table with interval

Use the nearest neighbor operator https://www.postgis.net/workshops/postgis-intro/knn.html Do you have a link to your source data? The table of elevations? > On Jan 7, 2022, at 11:18 AM, Luca Bertoncello wrote: > > Am 07.01.2022 um 20:01 schrieb Luca Bertoncello: > > Hi again > >> I get 33

Re: [postgis-users] CVE reported on log4j - is PostGIS affected?

PostGIS and PostgreSQL are in no way vulnerable to the log4j2 vulnerability. It strictly affects Java-based applications. ATB, P > On Dec 14, 2021, at 12:40 AM, Ulrich Selgert wrote: > > Hello, > > does anybody know if PostGIS is vulnerable to the CVE that has been reported > on the logging

[postgis-users] PostGIS Day 2021 - November 18

Hey all, just a reminder that there will be a virtual PostGIS Day event again this year! https://info.crunchydata.com/en/postgis-day-2021 If you are running a PostGIS day event in your own locality, please drop a note into this thread! P. ___

Re: [postgis-users] ST_CurveToLine and ST_LineToCurve problems

> On Nov 10, 2021, at 7:24 AM, Marcin Mionskowski > wrote: > > So... Are what I have described bugs or is it supposed to work this way? Mostly things are supposed to work this way. Remember you are "cheating", you see the original input run it through linetocurve/curvetoline, whereas the

[postgis-users] GEOS 3.10.0 Released

: - CAPI: GEOSDistanceWithin, GEOSPreparedDistanceWithin (#1124, Sandro Santilli) - Output WKT using positional precision with the ryu library (#868, Paul Ramsey) - geosop CLI for GEOS (Martin Davis) - Full doxygen of the C-API (Paul Ramsey) - GeometryFixer class for validity enforcement (Ma

Re: [postgis-users] PostgreSQL 13, PostGIS 3.1 import - could not form projection

There's something very particular about your environment and I don't know what it is. Try upgrading your proj version, and jimmying with other version combinations. There's nothing special about the SRID numbers, they work fine for me locally. I can't invest the time in setting up a mirror

Re: [postgis-users] PostgreSQL 13, PostGIS 3.1 import - could not form projection

srid entries have to exist in spatial_ref_sys table, do they? select srtext from spatial_ref_sys where srid in (2263, 4326); > On Oct 15, 2021, at 11:11 AM, karsten wrote: > > Hi All, > > on new server with Ubuntu 20.04 , PostgreSQL 13, PostGIS 3.1 I am trying to > import a plain sql dump .

[postgis-users] PostGIS Day - Call for Talks

Hi PostGIS'ers! Just a reminder, that PostGIS Day this year is at the usual time (day after GIS day, Nov 18) and we are again doing a global virtual event, so everyone can join in. https://info.crunchydata.com/en/postgis-day-2021 We really want to tell a lot of different PostGIS stories, so

Re: [postgis-users] PostGIS 3.1.4 and 3.0.4 released

gt; > > > Sent from my Galaxy > > > ---- Original message > From: Paul Ramsey > Date: 04/09/2021 19:20 (GMT+01:00) > To: PostGIS Users Discussion > Subject: Re: [postgis-users] PostGIS 3.1.4 and 3.0.4 released > > The fix is applied back to the

Re: [postgis-users] PostGIS 3.1.4 and 3.0.4 released

The fix is applied back to the 3.0 branch > On Sep 4, 2021, at 12:41 AM, david.stenwall wrote: > > Does this fix #4949? It says milestone 3.1.3 but that's the version with the > error. > > https://trac.osgeo.org/postgis/ticket/4949 > > > Sent from my Galaxy > > > Original

Re: [postgis-users] Newest PostGIS code with old PostgreSQL major versions

Jeremy, Thanks for writing! > On Aug 19, 2021, at 5:40 PM, Jeremy Schneider wrote: > > Hello, > > I would like to learn more about how the PostGIS development community thinks > about old major versions of PostgreSQL. > > Specifically, I'm curious to hear a little more elaboration on this

Re: [postgis-users] Installing pgdg Postgis 3.1 on CentOS/Rhel7 breaks sqlite3 cli

RPM build issues should be filed with the pdgd redmine https://redmine.postgresql.org/projects/pgrpms/ I'm not sure there's a good fix for the problem though... replacing/removing the old version is not allowed for the new package because the new package is not system-wide, it's part of the

Re: [postgis-users] Finding all 'adjacent' points in a point set

> On Jul 30, 2021, at 10:44 AM, Martin Davis wrote: > > Good to know! Thanks for fessing up... ;) > > On Fri, Jul 30, 2021 at 10:27 AM Bruce Rindahl > wrote: > My mistake. The CTE and inner join methods show no measurable difference in > performance. I added a spatial index to get the

Re: [postgis-users] Finding all 'adjacent' points in a point set

Why are you materializing the tables in a CTE? Do a direct self-join SELECT p1.id as src, p2.id as dest, st_makeline(p1.geom,p2.geom) as geom, FROM points p1, points p2 WHERE p1.id != p2.id -- don't link a point to itself and ST_DWithin (p1.geom,p2.geom, 16 * 1.74 ) -- only link to nearest 6

[postgis-users] Gdalwarp + Usan Clang?

I feel like these failures are correlated to the update of our CI docker images? We got some new images and then things started going boom? Maybe? https://github.com/postgis/postgis/runs/3184490245?check_suite_focus=true P ___ postgis-users mailing

Re: [postgis-users] New algorithms on the spheroid: intersecting lines and minimum distance point-line. Current software error assesment.

This is very interesting, but from a practical point of view the problems around doing intersections on the spheroid are not to do with the difficulty of calculating spheroidal intersection points, but the difficulty in programming things that are relatively simple in cartesian (R2) space in

  1   2   3   4   >