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: 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: 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: References: Message-ID: 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 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: 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: References: Message-ID: 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 > *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: 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: References: 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 wrote: > > 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 > 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 > >> 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: 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: References: 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 FROM my_fishbones a INNER JOIN my_fishbones b ON (a.id <> b.id AND ST_Crosses(a.geom,b.geom) ) From: Bo Guo Sent: Thursday, February 5, 2026 7:53 AM To: PostGIS Users Discussion 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: 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: <003c01dc96b0$fc29ca80$f47d5f80$@pcorp.us> Message-ID: 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 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 > *Sent:* Thursday, February 5, 2026 7:53 AM > *To:* PostGIS Users Discussion > *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: 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: References: <003c01dc96b0$fc29ca80$f47d5f80$@pcorp.us> 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 Sent: Thursday, February 5, 2026 12:59 PM To: Regina Obe Cc: PostGIS Users Discussion 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 > 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 > Sent: Thursday, February 5, 2026 7:53 AM To: PostGIS Users Discussion > 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: 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: <003c01dc96b0$fc29ca80$f47d5f80$@pcorp.us> <007401dc96ce$918f0190$b4ad04b0$@pcorp.us> Message-ID: *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 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 > *Sent:* Thursday, February 5, 2026 12:59 PM > *To:* Regina Obe > *Cc:* PostGIS Users Discussion > *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 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 > *Sent:* Thursday, February 5, 2026 7:53 AM > *To:* PostGIS Users Discussion > *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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image.png Type: image/png Size: 18584 bytes Desc: not available URL: 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: 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: 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: References: 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 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: 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: <000d01dc9a83$326782b0$97368810$@pcorp.us> Message-ID: 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 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 > *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: 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: References: <000d01dc9a83$326782b0$97368810$@pcorp.us> Message-ID: 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 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 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 >> *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: 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: 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: