Re: [gdal-dev] Enabling default compression for COG ?

I'd give LZW a go. I've got very good experience with that, in terms of performance on weaker or embedded systems. However, some people still think that the algorithm has a protection by patents. Am 30.09.2021 um 15:46 schrieb Even Rouault: should we enable a default compression scheme for the

Re: [gdal-dev] ZSTD compression level 17 smaller than 18+?

Am 15.03.2021 um 05:04 schrieb matt.wil...@yukon.ca: >> Here's my results: I'm also using zstd for lots of stuff. It's really performing very well. But it often behaves totally unpredictably. For example, I get a better compression ratio with SQL files in level 1 than with level 3. And level

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Am 25.11.2020 um 11:13 schrieb Pham Huu Bang: The tiff file you can download from https://files.fm/f/5ttjhyh9p The xyz file I already shared in the beginning: https://pastebin.com/40xSNqm4 Thanks. This really is EPSG:4647 and sho

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Am 25.11.2020 um 11:00 schrieb Pham Huu Bang: ERROR 1: No PROJ.4 translation for source SRS, coordinate transformation initialization has failed. Can you share your data? ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailm

Re: [gdal-dev] gdalwarp from EPSG:25832 to EPSG:4326 with error latitude or longitude exceeded limits?

Am 25.11.2020 um 10:17 schrieb Pham Huu Bang: Corner Coordinates: Upper Left  (32573000.000, 6019990.000) (174d17' 8.00"W,Invalid angle) Lower Left  (32573000.000, 6018990.000) (114d59' 0.99"W,Invalid angle) Upper Right (32574000.000, 6019990.000) (109d46'37.15"W,Invalid angle) Lower Right (32574

Re: [gdal-dev] Spherical Mercator Projection mismatching major/minor axis

Am 06.11.2020 um 12:07 schrieb jratike80: This does not really belong to my knowledge area but I'll have a try anyway. To add a bit of my knowledge, EPSG:3857 is the king/queen of unconformness (better unconform-mess): The geographic reference is based on geographic coordinates in WGS84 (el

Re: [gdal-dev] Calling ogr2ogr via proxy with ntlm authentication

I think you can use „--config GDAL_HTTP_PROXY your-ip“ here. -- Von einem iPhone gesendet und wird daher Fehler enthalten. > Am 11.08.2020 um 09:21 schrieb > : > >  > Dear GDAL-List, > > we’re trying to use an QGIS plugin called XPlanung which imports a gml-file > into a PostgreSQL/PostGI

Re: [gdal-dev] XLS file can't be opened with gdal 3

Hey, Am Fr, 10.01.2020, 10:58 schrieb Frédéric Trastour: > > It works fine with the older version but can't be read with the new new > one. XLS support is based on FreeXL Did you link it against it and installed the library? Best regards, Tobias ___

Re: [gdal-dev] Fwd: Gdal - multipolygon - geometry errors instead holes

Hi Marco, Am 30.10.2019 um 09:46 schrieb Marco: > > Indeed Buffer 0 won't do any good on self intersections. Thats just not > the way to repair them. But many users act like this: 1. Get a warning about invalid geometry, 2. run Buffer 0, 3. Warning about invalid geometry is gone. Again, this is

Re: [gdal-dev] Fwd: Gdal - multipolygon - geometry errors instead holes

Hi Marco, Am 29.10.2019 um 10:49 schrieb Marco: > Buffer 0 on INVALID geometries IMHO can lead to good results depending > on the nature of the invalidity. To my experience repeating points, > wrong coordinate ordering and holes touching outer shells in one point > are being repaired well without

Re: [gdal-dev] Fwd: Gdal - multipolygon - geometry errors instead holes

No! Please NEVER buffer with 0. There are tons of tests on the web that proof that this recommendation of 1980ies GIS experts is destroying data. There are modern feature, like „fix geometries“ in GEOS and others (pprepair). We really need the web to forget about this recommendation. — Von ei

Re: [gdal-dev] CURL error - SSL certificate problem

Am Mo, 9.09.2019, 18:37 schrieb Pedro Venâncio: > > Any hint about this issue? Please try to add "--config GDAL_HTTP_UNSAFESSL YES". ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Rename layers in GeoPDF

Am Do, 8.08.2019, 13:18 schrieb Casper Børgesen: > > I couldn't see anything in the documentation, but just wanted to be sure. MuPDF, QPDF etc. might be your friend? But beware: ghostscript based tools might mess with the layers and extra data. ___ gdal

Re: [gdal-dev] Motion: Promote GDAL 3.0.0 rc2 for release

+0.998 — Von einem iPhone gesendet und wird daher Fehler enthalten. > Am 07.05.2019 um 11:19 schrieb Even Rouault : > > Hi, > > Motion: GDAL/OGR 3.0.0 rc2 is promoted to be the official 3.0.0 final release. > > --- > > My vote: +1 > > Even > > -- > Spatialys - Geospatial professio

Re: [gdal-dev] GDAL Docker images

Am Do, 25.04.2019, 21:38 schrieb Even Rouault: > > I've prepared a set of Dockerfile for different configurations. I cannot find a like button so: THANKS :-) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gda

[gdal-dev] WCS: disk cache?

Hi there, right now, when using WCS, the image cache goes to /vsimem/wcs/, can I also write the files to disk? Sure, I could play with a local HTTPS proxy, but a native approach would be nice (like WMS). Best regards, Tobias ___ gdal-dev mailing list

Re: [gdal-dev] Mirror a WCS

Actually there IS a problem: the downloaded raster is off by 50 meters! I think, I have to report an issue on github. — Von einem iPhone gesendet und wird daher Fehler enthalten. > Am 26.03.2019 um 21:50 schrieb Tobias Wendorff > : > > Oh great... A second after this message got

Re: [gdal-dev] Mirror a WCS

Oh great... A second after this message got released on the ML, I was able to solve it. It just works as expected: gdal_translate -of GTiff -r near -tr 100 100 -projwin x x x x -projwin_srs EPSG:25832 --debug ON --config CPL_CURL_VERBOSE YES --config GDAL_HTTP_UNSAFESSL YES "WCS:https://x/cgi-bin

[gdal-dev] Mirror a WCS

Hi there, how do I correctly mirror a WCS using gdal_translate? A WMS is easy, I'm creating a XML file, modify it as needed and download it using gdal_translate. But I didn't find a similar workflow for WCS. Sure, I could batch download images with 1000 x 1000 to GeoTIFF and merge them afterward

Re: [gdal-dev] Extracting vector layers from Geospatial PDF

Am Sa, 9.02.2019, 20:47 schrieb Rajesvari Parasa: > > I didn't know that *ogrinfo takes config options*. This is quite > interesting because the document of ogrinfo doesn't mention this. It does. Please also check this: https://github.com/OSGeo/gdal/issues/1282 Did a huge test, since I'm also wor

[gdal-dev] PS/EPS support via PDF lib?

Hey there, shouldn‘t the PDF libs be able to interpret PS or EPS or aren’t they built against Ghostscript? I thought, Poppler could do PS at least (I think Inkscape uses this). Or didn’t you integrate PS support? It would save me a lossy transformation from PS to PDF to ogr :) Best regards, T

Re: [gdal-dev] Extracting vector layers from Geospatial PDF

Hi there, Am Mi, 6.02.2019, 17:58 schrieb Rajesvari Parasa: > to try: ogr2ogr -f sqlite out.sqlite in.pdf > But since ogr doesn't recognize my PDF, I can't use this. I had to use "--config OGR_PDF_READ_NON_STRUCTURED YES" to make it read my PDFs, but I think, this will destroy your Geospatial con

Re: [gdal-dev] Fwd: Re: [Tiff] Libtiff will be released soon

Am Sa, 10.11.2018, 16:13 schrieb Even Rouault: > I imagine we could come with a hack to still recognize the old values, > but I don't plan to go to that complication unless really needed. Not knowing the full topic: can't users with a problem just patch the magic byte in the header to port them to

Re: [gdal-dev] GeoTIFF: embedd JPEG without recompression

Am Fr, 2.11.2018, 18:40 schrieb Even Rouault: > > Yes, this is limited to a single JPEG file as a source (not a VRT of > several JPEG files for example), and if you use -co COMPRESS=JPEG > without an explicit -co QUALITY setting. -co TILED=YES is supported. Yeeks, it also gets "jpeg:sampling-facto

[gdal-dev] GeoTIFF: embedd JPEG without recompression

Hi there, can "gdal_translate" embedd a JPEG file in TIFF without recompression? Best regards, Tobias ___ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Removing layers from GeoSpatial PDF with ogr2ogr?

Am Mi, 25.04.2018, 21:02 schrieb Even Rouault: > > This is expected. When doing ogr2ogr you run into limitations > of the read side and write side of the PDF driver, and running > through OGR abstraction in the middle, so loss is expected in > the case of PDF. Even experienced PDF-orientated appli

Re: [gdal-dev] GDAL/OGR 2.2.4 is released

Am Mi, 21.03.2018, 15:50 schrieb Even Rouault: > > On behalf of the GDAL/OGR development team, I am pleased to announce the > release of the GDAL/OGR 2.2.4 bug fix version. Thanks a lot. Good work :D ___ gdal-dev mailing list gdal-dev@lists.osgeo.org ht

Re: [gdal-dev] limiting drivers that get registered

Am Do, 8.03.2018, 17:47 schrieb Kurt Schwehr: > I get a little more aggressive compared to what others suggested by > commenting out register calls in gdalallregister.cpp and > ogrregisterall.cpp > and removing the code for the drivers. > Share, share, share :) ___

Re: [gdal-dev] limiting drivers that get registered

I have created a config for minimal raster and vector. I can uploaded later when I am at home. -- Von einem iPhone gesendet und wird daher Fehler enthalten… Am 08.03.2018 um 13:23 schrieb Ben Elliston : > Is it possible to limit the number of drivers compiled into GDAL (I am > guessing not)?

Re: [gdal-dev] spatialite on Debian: neither lwgeom nor rttopo

Am Mo, 19.02.2018, 16:01 schrieb Bas Couwenberg: > Packages involved in the circular dependency cannot be updated because > the old versions are kept around. > > See: [snip] Thanks for your kind and detailed explanation. I will continue to build and use it in a chroot :)

Re: [gdal-dev] spatialite on Debian: neither lwgeom nor rttopo

Hi Sebastiaan, Am Mo, 19.02.2018, 07:40 schrieb Sebastiaan Couwenberg: > lwgeom support was disabled to untangle the circular dependency as > documented in the spatialite changelog: > > - Drop build dependency on liblwgeom-dev to untangle >spatialite->postgis->gdal->spatialite circular depend

[gdal-dev] spatialite on Debian: neither lwgeom nor rttopo

Hi there! Did anyone recognize that stable and unstable Debian neither builds lwgeom nor rttopo in libspatialite by default? This means: no ST-functions using SQLite dialect. For lwgeom it might be disabled due to licensing problems. spatialite's support for rttopo might be unstable, so this is

Re: [gdal-dev] GPKG: CREATE TABLE AS not working as expected

Am Do, 28.12.2017, 23:50 schrieb jratike80: > I would try with SQL that does not select the FID instead of "select *". > See preserve_fid in http://www.gdal.org/ogr2ogr.html. Not guaranteed > to work. The other way did it: adding "-unsetFid" seems to loosen up the order to FID and creates a new on

Re: [gdal-dev] GPKG: CREATE TABLE AS not working as expected

Thanks for your answer. Am Do, 28.12.2017, 18:41 schrieb Even Rouault: > > CREATE TABLE will bypass most driver-level logic that is needed for > a spatial table to be properly recognized as such. You could fix that > by manually registering the table in gpkg_contents and > gpkg_geometry_columns ta

[gdal-dev] GPKG: CREATE TABLE AS not working as expected

Hi there! I'm trying to do this on latest ogr2ogr build: ogrinfo -al -dialect sqlite -sql "CREATE TABLE sorted AS SELECT * FROM mytable ORDER BY ST_GeoHash(ST_Transform(ST_Envelope(geom), 4326), 10)" test.gpkg The command runs without a problem, but the final table doesn't contain any content in