from:"Rahkonen Jukka \(MML\)"

Re: [gdal-dev] Motion: adopt GDAL 3.4.3 RC2

2022-05-02 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: sunnuntai 1. toukokuuta 2022 23.46
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: adopt GDAL 3.4.3 RC2

Hi,

Motion:

Adopt GDAL 3.4.3 RC2 as final 3.4.3 release

Starting with my +1

Even

-- 
https://eur06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.spatialys.com%2Fdata=05%7C01%7Cjukka.rahkonen%40maanmittauslaitos.fi%7C9411504abdf94af7354408da2bb3a9e7%7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C1%7C637870347908360125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7Csdata=E1Zl2gSVYKoC%2F4ZaXz6KxEh6niuh1lcNrUeb6QlOmTE%3Dreserved=0
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fgdal-devdata=05%7C01%7Cjukka.rahkonen%40maanmittauslaitos.fi%7C9411504abdf94af7354408da2bb3a9e7%7Cc4f8a63255804a1c92371d5a571b71fa%7C0%7C1%7C637870347908360125%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7Csdata=zfTisF68UV8xFQylaKmuX5kN5dn0KQ5d2Jo3DjGv4F4%3Dreserved=0
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Why gdal2tiles creates png.aux.xml files

2022-04-28 Thread Rahkonen Jukka (MML)

Hi,

I noticed this question in gis.stacexchange 
https://gis.stackexchange.com/questions/429896/how-to-not-generate-png-aux-xml-files-when-using-gdal2tiles.
 The current gdal2tiles.py really seems to write the aux.xml files except for 
the base tiles. I wonder if it is necessary and if there is another way to 
prevent it than setting GDAL_PAM_ENABLED=NO as suggested in the answer.

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Create COG jpeg tiles with JFIF APPn markers

2022-04-05 Thread Rahkonen Jukka (MML)

Hi,

I would like to inform that you did write mail to the right place even you have 
not received any answers yet. Unfortunately your question is too specific for 
most GDAL users and capable developers are very busy as you can see from the 
GitHub activity. Let's still hope that somebody reacts.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Jose Calvo
Lähetetty: tiistai 29. maaliskuuta 2022 9.59
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Create COG jpeg tiles with JFIF APPn markers

Hi.

Currently my c++ app creates COG files from GeoTiff tiled files.


GeoTiff files are created using JPEG compression with YCBCR photometric using 
following creation options:

  *   PROFILE=GeoTIFF
  *   TILED=YES
  *   BLOCKXSIZE=xxx
  *   BLOCKYSIZE=xxx
  *   COMPRESS=JPEG
  *   PHOTOMETRIC=YCBCR
  *   JPEG_QUALITY=xx
  *   JPEGTABLESMODE=0
>From this Geotiff files, app creates COG tiled files using following options:

  *   BLOCKSIZE=xxx
  *   OVERVIEWS=FORCE_USE_EXISTING
  *   COMPRESS=JPEG
  *   QUALITY=xx
Those tiles contain normal JPEG markers (SOI, SOF0, DQT) but no JFIF marker 
(APPn) is added. How can I ensure adding this JFIF marker?

I'm using gdal 3.1.0.7 in a ubuntu 20.10 using both strategies:

  *   internal jpeg and tiff code: --with-jpeg=internal --with-libtiff=internal
  *   external jpeg and tiff libraries: libjpeg.so.8.2.2 libtiff.so.5.5.0
Thanks in advance.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL 3.4.2: gdalbuildvrt band selection bug

2022-03-30 Thread Rahkonen Jukka (MML)

Hi,

I can confirm with GDAL 3.5.0dev from gisinternals and with a normal RGB 
ortoimage.

gdalbuildvrt test.vrt p4433h.tif -b 2
0...10...20...30...40...50...60...70...80...90...100 - done.
ERROR 5: p4433h.tif: GDALDataset::GetRasterBand(2) - Illegal band #

With -b 1 -b 2 the command runs fine.

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Pete Bunting 
via gdal-dev
Lähetetty: keskiviikko 30. maaliskuuta 2022 13.59
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] GDAL 3.4.2: gdalbuildvrt band selection bug

Hi, 

With the release of gdal 3.4.2, gdalbuildvrt seems to have a bug when selecting 
image bands. It works OK when band 1 is specified but if other band(s) in the 
image are used without band 1 then it seg faults. I noticed there were some 
changes around checking bands in the release notes "change logic to check 
homogenous number of bands” and I had a quick look at the commits but cannot 
see where this is occurring. 

# Works:
gdalbuildvrt test.vrt sen2_20210527_aber_subset.kea -b 1

# Seg Faults:
gdalbuildvrt test.vrt sen2_20210527_aber_subset.kea -b 2

ERROR 5: sen2_20210527_aber_subset.kea: GDALDataset::GetRasterBand(2) - Illegal 
band # Segmentation fault (core dumped)


# Works:
gdalbuildvrt test.vrt sen2_20210527_aber_subset.kea -b 1 -b 2 -b 3

# Seg Faults:
gdalbuildvrt test.vrt sen2_20210527_aber_subset.kea -b 2 -b 3 -b 4

ERROR 5: sen2_20210527_aber_subset.kea: GDALDataset::GetRasterBand(4) - Illegal 
band # Segmentation fault (core dumped)

Note, the input image I was using has 10 bands and these commands work with 
3.4.1. I get the same seg fault on Mac, Linux and Windows ("Windows fatal 
exception: access violation"). 

Many thanks, 

Pete
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Is PAM always used before GeoTIFF tags?

2022-03-22 Thread Rahkonen Jukka (MML)

Hi,

See this question 
https://gis.stackexchange.com/questions/426418/create-rectified-geotiff-given-aux-xml-produced-from-arcgis?

The GeoTIFF driver documentation 
https://gdal.org/drivers/raster/gtiff.html#georeferencing says about the order 
in which the georeferencing is searched "By default, information is fetched in 
following order (first listed is the most prioritary): PAM (Persistent 
Auxiliary metadata) .aux.xml sidecar file, INTERNAL (GeoTIFF keys and tags), 
TABFILE (.tab), WORLDFILE (.tfw, .tifw/.tiffw or .wld)."
However, in this case it seems that GeoTIFF tags are used instead of PAM if not 
especially asked with --config GDAL_GEOREF_SOURCES PAM

I am also curious to know how the SourceGCP values in this PAM file gets 
converted into pixel rows and columns. For example these values

3.3670799903498199
14.344873843184562
seem to turn into (1010.12399710495,3376.53784704463). How does it happen and 
where is it documented? I think there must happen some scaling and offsetting 
but is this something ESRI specific? I found this ESRI document but there the 
columns and rows appear unscaled in the aux.xml file 
https://doc.arcgis.com/en/imagery/workflows/browse-imagery/workflow/workflow-appendices.htm.

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Why does ogrinfo use backtics in the output?

2022-03-21 Thread Rahkonen Jukka (MML)

Hi,

I have been wondering for a long time why orginfo is using backtics/backquotes 
in the output. In this example before "foo" and "ESRI"

ogrinfo foo.shp
INFO: Open of `foo.shp'
  using driver `ESRI Shapefile' successful.

Not so big problem but in markup the backtick means the beginning/end of a code 
block and copy-pasting ogrinfo report may require some hand editing. Would it 
make any harm to use single quotes at both ends?

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: promote GDAL 3.4.2 RC2

2022-03-10 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: torstai 10. maaliskuuta 2022 9.42
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: promote GDAL 3.4.2 RC2

Hi,

Motion:

Adopt GDAL 3.4.2 RC2 as final 3.4.2 release

Starting with my +1

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Implications of "Multi-column primary key in [table] to supported" warning

2022-03-03 Thread Rahkonen Jukka (MML)

Hi,

If you have a table with multi-column primary key (composite key) then the 
target table in Spatialite obviously will not have the same PK. I would guess 
that none of the columns in the composite is unique and usable as PK so the 
only possibility is to create a new unique column for the PK. Therefore the 
tables that you will have are not identical with the source tables by their 
schemas. The foreign key constraints between the tables are dropped any way, 
ogr2ogr does not try to transfer them ever.

I think you can answer your question yourself by making a test with your own 
data. If all of the tables that have a composite PK get a new PK field in 
Spatialite (I guess it will of type "integer autoincrement") and if the row 
counts in source and target tables match I believe that the data has been 
transferred right. When it comes to question "is it safe to assume that db 
relations won't get mixed up" you do not have any constrained relations left in 
Spatialite. The data integrity is OK immediately after the conversion but at 
that stage there is nothing in Spatialite that prevents you from making edits 
that you should't do. But you can add similar constraints that you have in 
PostGIS afterward into SQLite https://sqlite.org/foreignkeys.html. I am not 
sure that all type of constraints that you can have in PostGIS are supported in 
SQLite but foreign key should behave in the same way.

SQLite driver https://gdal.org/drivers/vector/sqlite.html supports 
prelude_statements but if you want to re-create constraints you would need 
something like postlude_statements. It means that ogr2ogr cannot do the whole 
job but you must run the required SQL statements with ogrinfo or some SQLite 
client.

-Jukka Rahkonen-



-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta DUTRIEUX Loic
Lähetetty: torstai 3. maaliskuuta 2022 13.56
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Implications of "Multi-column primary key in [table] to 
supported" warning

Hi everyone,

Quick question, I'm using ogr2ogr to clone a postGIS database to a spatialite 
file database (by the way, very convenient that ogr2ogr handles the transfer of 
non-spatial tables too). The database contains many-to-many relations and as a 
consequence association tables with multiple primary keys. When I run ogr2ogr I 
get a warning saying that Multi-column primary key are not supported.
Should I be worried of that warning for my use case or is it safe to assume 
that db relations won't get mixed up.

Thanks and kind regards,
Loïc
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] version 2.4.4

2022-02-27 Thread Rahkonen Jukka (MML)

Hi,

There is nobody who can take the responsibility to say that it is OK to use an 
unmaintained version of GDAL. Of course it was the best version with least bugs 
ever when it was released but it was 4 years ago. You can browse through the 
release notes of all the subsequent GDAL 3.x versions 
https://github.com/OSGeo/gdal/releases and evaluate if they are important for 
you or not. Patching 2.4.4 with cherry picked changes from 3.x series does not 
feel reasonable or at least not any easier than to prepare to upgrade into 
supported 3.x.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta ni hao
Lähetetty: sunnuntai 27. helmikuuta 2022 0.10
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] version 2.4.4

Hi list,

I want to keep using GDAL2 because GDAL3 changes a lot and I can't afford the 
effort to upgrade PROJ and other libs.
My question: is version 2.4.4 ok to use? I was told that its NUMPY has 'null 
pointer' issues.
Are there necessary revisions need to be applied?

Thank you!

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] HDF4Image stuck on translate

2022-02-22 Thread Rahkonen Jukka (MML)

Hi,

It was sluggish last week and still is, I guess that especially with multi-band 
images https://lists.osgeo.org/pipermail/gdal-dev/2022-February/055474.html. 
Run the command with “ -- debug on” and you have more to follow when you see 
how Flushing dirty blocks is slowly progressing.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Lorenzo Di 
Giacomo
Lähetetty: tiistai 22. helmikuuta 2022 18.10
Vastaanottaja: 'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) 

Aihe: [gdal-dev] HDF4Image stuck on translate

Hi, i'm doing some "conversion" test, from one format to another (mainly from 
TIFF to ALL).
I found in HDF4Image driver that on some images, it get stuck.


gdal_translate -of HDF4Image source.tiff dest.hdf

Input file size is 2861, 3635

0...10...20...30...40...50...60...70...80...90...100 - done.

And remain in this state. For image as big as this above, i let it for about 1 
hour and still blocked.
Is it normal that required all this time ? Thanks

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Gdal_translate into HDF4 fails

2022-02-18 Thread Rahkonen Jukka (MML)

Hi,

That HDF5 driver is read-only is documented in 
https://gdal.org/drivers/raster/hdf5.html so that the driver capabilities are 
missing Supports CreateCopy() and Supports Create()

Same metadata is available with gdalinfo --format [format_name].

(But metadata is wrong for HDF4 and capabilities are missing, I wonder how to 
fix that)
gdalinfo --format hdf4
Format Details:
  Short Name: HDF4
  Long Name: Hierarchical Data Format Release 4
  Supports: Raster
  Supports: Multidimensional raster
  Extension: hdf
  Help Topic: drivers/raster/hdf4.html
  Supports: Raster subdatasets
  Supports: Open() - Open existing dataset.

-Jukka Rahkonen-

Lähettäjä: Lorenzo Di Giacomo 
Lähetetty: perjantai 18. helmikuuta 2022 16.24
Vastaanottaja: Even Rouault 
Kopio: Rahkonen Jukka (MML) ; 
'gdal-dev@lists.osgeo.org' (gdal-dev@lists.osgeo.org) 
Aihe: Re: [gdal-dev] Gdal_translate into HDF4 fails

Hi guys, i was reading the question and i was wondering if it's possibile do 
the same translate operation with HDF5, like:
gdal_translate -of HDF5Image 3band.tif out.h5, i tried but doesn't work and 
says "

HDF5 driver has no creation capabilities."

Thanks
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Gdal_translate into HDF4 fails

2022-02-18 Thread Rahkonen Jukka (MML)

More information, probably it does not fail but it is extremely slow. After 15 
minutes I am now at this stage

gdal_translate -of HDF4Image 3band.tif out.h4 --debug on
GDAL: GDALOpen(3band.tif, this=0215A20D36A0) succeeds as GTiff.
Input file size is 12000, 12000
GDAL: QuietDelete(out.h4) invoking Delete()
GDAL: GDALOpen(out.h4, this=0215A20BF880) succeeds as HDF4.
GDALPamDataset: In destructor with dirty metadata.
GDAL: GDALClose(out.h4, this=0215A20BF880)
GTiff: ScanDirectories()
GDAL: GDALDefaultOverviews::OverviewScan()
GDAL: Using default GDALDriver::CreateCopy implementation.
0GDAL: GDALDriver::Create(HDF4Image,out.h4,12000,12000,3,Byte,)
GDAL: GDAL_CACHEMAX = 1632 MB
GDAL: GDALDatasetCopyWholeRaster(): 12000*83 swaths, bInterleave=1
...10...20...30...40...50...60...70...80...90...100 - done.
GDAL: Flushing dirty blocks: 
0...10...20...30...40...50...60...70...80...90...100 - done.
GDAL: Flushing dirty blocks: 0...10...20...30.


-Jukka-


Lähettäjä: Rahkonen Jukka (MML)
Lähetetty: perjantai 18. helmikuuta 2022 14.09
Vastaanottaja: 'gdal-dev@lists.osgeo.org' 
Aihe: Gdal_translate into HDF4 fails

Hi,

There is a question about HDF4 in 
https://gis.stackexchange.com/questions/424204/convert-geotiff-to-hdf-using-gdal.
I tried the same with GDAL 3.4.0. With a single band image conversion from 
GeoTIFF into HDF4Image succeeds but with a 3 band image not. I am not sure if 
it is even supposed to work and the driver test in 
https://github.com/OSGeo/gdal/blob/master/autotest/gcore/hdf4_write.py is 
rather simplistic.
So, should "gdal_translate -of HDF4Image 3band.tif out3band.h4" work?

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Gdal_translate into HDF4 fails

2022-02-18 Thread Rahkonen Jukka (MML)

Hi,

There is a question about HDF4 in 
https://gis.stackexchange.com/questions/424204/convert-geotiff-to-hdf-using-gdal.
I tried the same with GDAL 3.4.0. With a single band image conversion from 
GeoTIFF into HDF4Image succeeds but with a 3 band image not. I am not sure if 
it is even supposed to work and the driver test in 
https://github.com/OSGeo/gdal/blob/master/autotest/gcore/hdf4_write.py is 
rather simplistic.
So, should "gdal_translate -of HDF4Image 3band.tif out3band.h4" work?

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GEOS Maintenance Grant

2022-02-17 Thread Rahkonen Jukka (MML)

Hi,

I can see that I sent my +1 only to GDAL PSC members, not to the lists.

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Howard Butler
Lähetetty: torstai 17. helmikuuta 2022 18.13
Vastaanottaja: gdal dev 
Kopio: GEOS Development List 
Aihe: Re: [gdal-dev] GEOS Maintenance Grant

Declaring this motion passed with +1's from

DanielM, EvenR, NormanB, TamasS, HowardB, MateuszL, FrankW, KurtS, and SeanG

The GDAL PSC is fully delegating these resources to the GEOS PSC to use as it 
sees fit. Paul Ramsey has agreed to be the administrative contact for the GEOS 
PSC, and will coordinate the effort in regards to payment sign-off, work task 
development, rate negotiation, and reporting to the GDAL PSC. 

Howard

PS: As a member of both PSCs, I will abstain from any funding or resource 
direction votes in the GEOS PSC to avoid any potential conflict.

> On Feb 15, 2022, at 9:37 AM, Howard Butler  wrote:
> 
> GDAL PSC,
> 
> When we wrote the GDAL RFCs on sponsorship, we provided an escape clause to 
> allow us to direct resources to other projects upon which GDAL depends. Our 
> sponsorship numbers are still increasing, which provides us an opportunity to 
> directly support some of those projects, and one of them is obviously GEOS. 
> GEOS provides all of the geometry algebra support for GDAL/OGR and many other 
> open source geospatial softwares including Shapely, PostGIS, GeoPandas, 
> MapServer, and more. 
> 
> Dan Baston of the GEOS PSC has been identified as the developer with capacity 
> and interest in the next year to take on GEOS development on APIs and 
> performance, which he has a long history of doing for the project. This 
> support should allow him to work longer, multi-release upgrades that will 
> provide strong performance and convenience benefits for the project.
> 
> I motion to provide the GEOS PSC with a $50,000 USD grant to address 
> performance, API, and other work that does not attract directed funding in 
> GEOS. The GEOS PSC will be responsible for coordinating work tasks, rates, 
> and development timelines. Howard Butler or Even Rouault of the GDAL NumFocus 
> liaison team will coordinate dispersement as directed by the GEOS PSC and 
> NumFocus rules.
> 
> Thank you again to the GDAL Sponsors https://gdal.org/sponsors/index.html who 
> have made this kind of grant possible. A better GEOS makes for a better GDAL.
> 
> Howard
> 

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Can't open postgrest service with ogr2ogr (via QGIS)

2022-02-14 Thread Rahkonen Jukka (MML)

Hi,

I wonder if there could be something in the Accept headers that orginfo is 
using.  Ogrinfo seems to set headers “Accept: text/plain, application/json” but 
GeoJSON is now officially “application/geo+json”. I do not know the hierarchy 
of the MIME types and if “json” should include also the subtype “geo+json”.

I made a test with ogrinfo and  --config GDAL_HTTP_HEADER_FILE my_headers.txt. 
After this I could see from the logs this

Accept: application/geo+json
Accept: text/plain, application/json

By https://datatracker.ietf.org/doc/html/rfc2616/ I suppose this is correct and 
http server should concatenate Accept headers. However, the test was not 
successful so maybe there is something else going wrong.

-Jukka Rahkonen-


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Error InvalidTile when download a WMS

2022-02-14 Thread Rahkonen Jukka (MML)

Hi,

Have you tried to use the URL without =TRUE?  That vendor option is meant 
for clients like OpenLayers so that they can get cacheable tiles from standard 
GeoServer WMS 
https://geoserver-pdf.readthedocs.io/en/latest/services/wms/vendor.html

That such tiling and metatiling can work the requests must have a certain width 
and height. For regular WMS clients it is better not to use =TRUE.

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Elena Ruiz
Lähetetty: maanantai 14. helmikuuta 2022 17.42
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Error InvalidTile when download a WMS

Hello, I'm trying to download a WMS image using gdla_translate from a server in 
Sweden: 
http://kartor.stockholm.se/bios/wms/app/baggis/web/WMS_STHLM_ORTOFOTO_2020, 
with EPSG:3011 (attached xml ) , but it returns me this error, I've searched 
the internet, but I can't find any entry that refers to it, could someone tell 
me what this error means and how I could solve it, thanks

>gdal_translate -of JPEG "C:\Users\elena\AppData\Local\Temp\tmpnuevo.xml" 
>"C:\Users\elena\AppData\Local\Temp\prueba.jpg"
Input file size is 766, 577
0ERROR 1: GDALWMS: The server returned exception code 'InvalidTile': Width(254) 
differs from tile width(256) ERROR 1: 
C:\Users\elena\AppData\Local\Temp\tmpnuevo.xml, band 1: IReadBlock failed at X 
offset 0, Y offset 0: GDALWMS: The server returned exception code 
'InvalidTile': Width(254) differs from tile width(256)

Regards,

-Mensaje original-
De: gdal-dev  En nombre de 
gdal-dev-requ...@lists.osgeo.org Enviado el: domingo, 12 de septiembre de 2021 
18:24
Para: gdal-dev@lists.osgeo.org
Asunto: gdal-dev Digest, Vol 208, Issue 17

Send gdal-dev mailing list submissions to
gdal-dev@lists.osgeo.org

To subscribe or unsubscribe via the World Wide Web, visit
https://lists.osgeo.org/mailman/listinfo/gdal-dev
or, via email, send a message with subject or body 'help' to
gdal-dev-requ...@lists.osgeo.org

You can reach the person managing the list at
gdal-dev-ow...@lists.osgeo.org

When replying, please edit your Subject line so it is more specific than "Re: 
Contents of gdal-dev digest..."


Today's Topics:

   1. Get error handler user data when removing CPL Error Handler
  (Rajsekar Manokaran)
   2. Re: Get error handler user data when removing CPL Error
  Handler (Even Rouault)
   3. Re: Get error handler user data when removing CPL Error
  Handler (Rajsekar Manokaran)
   4. Re: Get error handler user data when removing CPL Error
  Handler (Sean Gillies)


--

Message: 1
Date: Sun, 12 Sep 2021 19:33:10 +0530
From: Rajsekar Manokaran 
To: gdal-dev@lists.osgeo.org
Subject: [gdal-dev] Get error handler user data when removing CPL
Error Handler
Message-ID:

Content-Type: text/plain; charset="utf-8"

Hi,

In the gdal rust bindings (https://github.com/georust/gdal), we're trying to 
facilitate the use of CPLSetErrorHandlerEx and related APIs.  While setting a 
handler, we may pass a heap allocated data pointer to the second argument, 
which is then read via the CPLGetErrorHandlerUserData in the handler and passed 
to the user.

However, while removing or setting another handler, we're unable to find a 
race-free method to get the associated user data of the previous handler.
This is needed to properly deallocate the memory.

Is there an atomic way to get both the previous handler (as returned by 
CPLSetErrorHandler), along with the associated user data?  The issue with 
making two calls, is that another thread might make changes in between the two 
calls.

We could synchronize in our API, but it still has the same issue if the user 
parallely used the C APIs directly or via a different interface.

Relevant PR in rust gdal bindings: https://github.com/georust/gdal/pull/215

-
Regards
-- next part --
An HTML attachment was scrubbed...
URL: 


--

Message: 2
Date: Sun, 12 Sep 2021 16:12:19 +0200
From: Even Rouault 
To: Rajsekar Manokaran , gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Get error handler user data when removing CPL
Error Handler
Message-ID: <0637288e-2945-443c-5f02-39f318003...@spatialys.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Hi,

no there's no thread safe API to do what you want. You'd need a new function

CPLErrorHandler CPLSetErrorHandlerEx2( CPLErrorHandler pfnErrorHandlerNew, 
void* pUserData, void** ppOldUserData )

to do that.

But as you mention threads that might compete to set an error handler, using 
CPLSetErrorHandlerEx() is probably not the best strategy. You'd be better with 
CPLPushErrorHandler() / CPLPopErrorHandler() that only affects the current 
thread.

Even

Le 12/09/2021 ? 16:03, Rajsekar Manokaran a ?crit?:
> Hi,
>
> In

Re: [gdal-dev] Can't open postgrest service with ogr2ogr (via QGIS)

2022-02-14 Thread Rahkonen Jukka (MML)

Hi,

Does http://mydomain:3000/rpc/wod_geojson.json return data if you send it with 
browser?  Re-run the ogrinfo command with “--debug on” and see if you can 
capture the http requests that ogrinfo sends.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta SIGéal
Lähetetty: maanantai 14. helmikuuta 2022 20.54
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Can't open postgrest service with ogr2ogr (via QGIS)

Hi list,

I have a PostgreSql stored procedure which returns a geojson feature collection 
created with json_build_object function. This web service opens fine in 
OpenLayers, however, when I try to open it in QGIS, with data source manager -> 
vector -> protocol -> geojson.

A similar REST service served with pg_featureserv, works well...
Here are tests realised with curl and ogrinfo for failing postgrest service and 
working pg_featureserv services :
PostGrest
curl answer :

StatusCode: 200

StatusDescription : OK

Content   : {123, 34, 116, 121...}

RawContent: HTTP/1.1 200 OK

Transfer-Encoding: chunked

Content-Range: 0-0/*

Vary: Accept-Encoding

Content-Type: application/geo+json

Date: Sun, 13 Feb 2022 07:35:55 GMT

Server: postgrest/9.0.0



{"type" : ...

Headers   : {[Transfer-Encoding, chunked], [Content-Range, 0-0/*], 
[Vary, Accept-Encoding], [Content-Type,

application/geo+json]...}

RawContentLength  : 430979

ogrinfo answer :

ERROR 1: HTTP error code : 404

ERROR 1: HTTP error code : 404

FAILURE:

Unable to open datasource `http://mydomain:3000/rpc/wod_geojson.json' with the 
following drivers...

pg_featureserv
curl answer :

StatusCode: 200

StatusDescription : OK

Content   : {123, 34, 116, 121...}

RawContent: HTTP/1.1 200 OK

Transfer-Encoding: chunked

Content-Type: application/geo+json

Date: Sun, 13 Feb 2022 07:33:51 GMT




{"type":"FeatureCollection","features":[{"type":"Feature","geometry":{"type":"Po...

Headers   : {[Transfer-Encoding, chunked], [Content-Type, 
application/geo+json], [Date, Sun, 13 Feb 2022

07:33:51 GMT]}

RawContentLength  : 4474

ogrinfo answer :

INFO: Open of `http://mydomain:9000/functions/webmapod_mdarret/items.json'

  using driver `GeoJSON' successful.

1: items (Point)

What could explain that 404 error for posgrest geojson web service ?

Thanks for any hint,

--

Christophe Damour
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Corrupted geopackage

2022-02-14 Thread Rahkonen Jukka (MML)

Hi,

Maybe you can drop the rtree tables if you first drop the rtree_xxx triggers
that belong to the data table. There are probably 6 of them. I don’t know if it
helps, though. rtreecheck() https://sqlite.org/rtree.html is probably useless
because you know already that the index is corrupted.

-Jukka-

Lähettäjä: Isabel Kiefer
Lähetetty: maanantai 14. helmikuuta 2022 13.08
Vastaanottaja: Rahkonen Jukka (MML) ;
gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] Corrupted geopackage

Hi Jukka,

Yes, exactly, there are only 78 entries in a dump to text file.

In the original .gpkg-file, the rtree_XX_geom table is completely empty (no
columns, no entries) - this must be where the problem comes from..

On Mon, Feb 14, 2022 at 11:59 AM Rahkonen Jukka (MML)
mailto:jukka.rahko...@maanmittauslaitos.fi>>
wrote:
Hi,

And when you .dump https://www.sqlitetutorial.net/sqlite-dump/ the damaged
table into a text file, do you only get 78 insert entries into it?

-Jukka-

Lähettäjä: Isabel Kiefer mailto:isa...@opengis.ch>>
Lähetetty: maanantai 14. helmikuuta 2022 12.53
Vastaanottaja: Rahkonen Jukka (MML)
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Kopio: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: Re: [gdal-dev] Corrupted geopackage

Thanks for your suggestion, Jukka! I tried all the advice from stackoverflow. I
can do ".recover", but get only the features that have been visible all along.
In the original .gpkg, I cannot DROP the affected RTree-Index. It gives me the
same disk malformed error. But that would also have been my initial idea...

On Mon, Feb 14, 2022 at 9:26 AM Rahkonen Jukka (MML)
mailto:jukka.rahko...@maanmittauslaitos.fi>>
wrote:
Hi,

Without being able to see your database it is hard to give more advice that
https://stackoverflow.com/questions/18259692/how-to-recover-a-corrupt-sqlite3-database/18260642
gives. Did you try all of them? Because the problem has something to do with
the spatial index I would have a try be dropping it and repeating the suggested
tricks.

-Jukka Rahkonen-

Lähettäjä: gdal-dev
mailto:gdal-dev-boun...@lists.osgeo.org>>
Puolesta Isabel Kiefer
Lähetetty: maanantai 14. helmikuuta 2022 10.17
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] Corrupted geopackage

Hi everyone,

I've a problem with a corrupted geopackage.
It should contain a table with 694 entries, but only 78 are visible when
opening the file with DB Browser for SQLite or QGIS. The table
gpkg_ogr_contents says 694 though. When opening the .gpkg with a Notepad or
similar, I can see that there are more than 78 entries.

The error message in DB Browser is "database disk image is malformed in "PRAGMA
"main".TABLE_INFO("rtree_XXX");" So it seems that there is a problem with the
index of the concerned table.

Does anyone know how to fix this? I tried
https://stackoverflow.com/questions/18259692/how-to-recover-a-corrupt-sqlite3-database/18260642
but without success.

Thanks in advance for your help!
Isabel

--
Isabel Kiefer
OPENGIS.ch

isa...@opengis.ch<mailto:isa...@opengis.ch>

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Corrupted geopackage

2022-02-14 Thread Rahkonen Jukka (MML)

Hi,

And when you .dump https://www.sqlitetutorial.net/sqlite-dump/ the damaged
table into a text file, do you only get 78 insert entries into it?

-Jukka-

Lähettäjä: Isabel Kiefer
Lähetetty: maanantai 14. helmikuuta 2022 12.53
Vastaanottaja: Rahkonen Jukka (MML)
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] Corrupted geopackage

On Mon, Feb 14, 2022 at 9:26 AM Rahkonen Jukka (MML)
mailto:jukka.rahko...@maanmittauslaitos.fi>>
wrote:
Hi,

-Jukka Rahkonen-

Hi everyone,

The error message in DB Browser is "database disk image is malformed in "PRAGMA
"main".TABLE_INFO("rtree_XXX");" So it seems that there is a problem with the
index of the concerned table.

Does anyone know how to fix this? I tried
https://stackoverflow.com/questions/18259692/how-to-recover-a-corrupt-sqlite3-database/18260642
but without success.

Thanks in advance for your help!
Isabel

--
Isabel Kiefer
OPENGIS.ch

isa...@opengis.ch<mailto:isa...@opengis.ch>

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Corrupted geopackage

2022-02-14 Thread Rahkonen Jukka (MML)

Hi,

Without being able to see your database it is hard to give more advice that 
https://stackoverflow.com/questions/18259692/how-to-recover-a-corrupt-sqlite3-database/18260642
 gives. Did you try all of them? Because the problem has something to do with 
the spatial index I would have a try be dropping it and repeating the suggested 
tricks.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Isabel Kiefer
Lähetetty: maanantai 14. helmikuuta 2022 10.17
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Corrupted geopackage

Hi everyone,

I've a problem with a corrupted geopackage.
It should contain a table with 694 entries, but only 78 are visible when 
opening the file with DB Browser for SQLite or QGIS. The table 
gpkg_ogr_contents says 694 though. When opening the .gpkg with a Notepad or 
similar, I can see that there are more than 78 entries.

The error message in DB Browser is "database disk image is malformed in "PRAGMA 
"main".TABLE_INFO("rtree_XXX");" So it seems that there is a problem with the 
index of the concerned table.

Does anyone know how to fix this? I tried  
https://stackoverflow.com/questions/18259692/how-to-recover-a-corrupt-sqlite3-database/18260642
 but without success.

Thanks in advance for your help!
Isabel

--
Isabel Kiefer
OPENGIS.ch

isa...@opengis.ch

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] netCDF with virtual file system (/vsicurl/) not working

2022-02-02 Thread Rahkonen Jukka (MML)

Hi,

What is your GDAL version? Check with "gdalinfo --version"

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Stefan 
Blumentrath
Lähetetty: keskiviikko 2. helmikuuta 2022 10.36
Vastaanottaja: gdal-dev 
Aihe: [gdal-dev] netCDF with virtual file system (/vsicurl/) not working

Hi,

I have been using GDAL to access online data sources in netCDF successfully.
With Ubuntu 20.04, this unfortunately no longer works with the netCDF driver.

Here is a reproducible example:
gdalinfo -if netCDF 
/vsicurl/https://nbstds.met.no/thredds/fileServer/NBS/S2A/2021/02/28/S2A_MSIL1C_20210228T103021_N0202_R108_T35WPU_20210228T201033_DTERRENGDATA.nc

The original error message (before working around the HDF5 driver) has been 
that permissions for the userfaultfd system call were denied. But if I specify 
the netCDF driver, the format is not recognized. Downloading the dataset and 
opening It locally works.

I saw some possibly relevant changes:
https://github.com/OSGeo/gdal/pull/4508
https://github.com/OSGeo/gdal/issues/2412

Any hint on how to get that functionality back would be very much appreciated!

Cheers
Stefan
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: grant github commit rights to Nyall Dawson

2022-01-25 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: keskiviikko 26. tammikuuta 2022 1.34
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: grant github commit rights to Nyall Dawson

Hi,

I'd like to motion to grant github commit rights to Nyall. We don't have much 
people currently doing reviews of pull requests and pressing the "Merge" 
button, and Nyall is definitely in a capacity of fulfilling this 
responsibility, at least in the areas where he fills comfortable. His own pull 
requests are of excellent quality and he's one of the few to review my work.

Starting with my +1

Even

--
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 85: Policy regarding substantial code additions

2022-01-21 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: perjantai 21. tammikuuta 2022 12.18
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: adopt RFC 85: Policy regarding substantial code 
additions

Hi,

As the discussion seems to have calmed down, I move to adopt RFC 85: 
Policy regarding substantial code additions: 
https://github.com/OSGeo/gdal/pull/5128

Starting with my +1

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Call for discussion on RFC 85: Policy regarding substantial code additions

2022-01-18 Thread Rahkonen Jukka (MML)

Hi,

Greg Troxel wrote:

> If that is meant to apply mainly to drivers with proprietary SDKs, it
> looks fine.   It's a little hard to tell which things apply to drivers
> that don't have proprietary dependencies.
I think that even drivers with no proprietary dependencies require a thorough 
understanding about what they do and how they work and for example what 
standards they try to implement. It could mean hours or days for a generic GDAL 
maintainer to make the first bug fix.

> For example:
> Drivers require a designated responsible contact.
> seems perhaps a bit much, perhaps not, for something that is actually Free 
> Software.
The intention of the RFC, as I understand it, is to clarify that no new drivers 
will be accepted without a named maintainer. For a Free Software there is room 
to live also outside GDAL. 

> Besides proprietary SDKs being a problem because the users can't read them 
> and fix bugs, they are also non-portable.
I belong to those users who can't read and fix even Free Software but depend on 
maintainers.

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [Question] PROJ4String to WKT2 Transformations

2022-01-10 Thread Rahkonen Jukka (MML)

Hi,

The more or less same question seems to be asked some time ago in 
gis.stackexchange 
https://gis.stackexchange.com/questions/420378/can-we-construct-wkt2-from-proj4string-correctly.

-Jukka Rahkonen-


Lähettäjä: gdal-dev  Puolesta Felipe Matas 
via gdal-dev
Lähetetty: maanantai 10. tammikuuta 2022 22.07
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] [Question] PROJ4String to WKT2 Transformations

Hi hi, I was looking for someplace to ask about this, and I was in doubt is was 
here or in PROJ, but lets do a try.

Actually, probably I'm not the only one, I have some questions about how WKT2 
and PROJ4Strings are transformed.

From what I read, a PROJ4String don't have enough info to construct a precise 
WKT2, so, actually how PROJ4String is deprecated my main question is how to 
construct the right WKT2, there is a lot o data stored in the old format, there 
is usually no more information, and even the software/hardware that get the 
data in some way save all of it with all the errors.

Actually, we can transform a old CRS to a WKT2:


> st_crs("+type=crs +proj=utm +zone=19 +south +datum=WGS84 +units=m +no_defs 
> +ellps=WGS84 +towgs84=0,0,0"

+ )

Coordinate Reference System:

  User input: +type=crs +proj=utm +zone=19 +south +datum=WGS84 +units=m 
+no_defs +ellps=WGS84 +towgs84=0,0,0

  wkt:

BOUNDCRS[

SOURCECRS[

PROJCRS["unknown",

BASEGEOGCRS["unknown",

DATUM["World Geodetic System 1984",

ELLIPSOID["WGS 84",6378137,298.257223563,

LENGTHUNIT["metre",1]],

ID["EPSG",6326]],

PRIMEM["Greenwich",0,

ANGLEUNIT["degree",0.0174532925199433],

ID["EPSG",8901]]],

CONVERSION["UTM zone 19S",

METHOD["Transverse Mercator",

ID["EPSG",9807]],

PARAMETER["Latitude of natural origin",0,

ANGLEUNIT["degree",0.0174532925199433],

ID["EPSG",8801]],

PARAMETER["Longitude of natural origin",-69,

ANGLEUNIT["degree",0.0174532925199433],

ID["EPSG",8802]],

PARAMETER["Scale factor at natural origin",0.9996,

SCALEUNIT["unity",1],

ID["EPSG",8805]],

PARAMETER["False easting",50,

LENGTHUNIT["metre",1],

ID["EPSG",8806]],

PARAMETER["False northing",1000,

LENGTHUNIT["metre",1],

ID["EPSG",8807]],

ID["EPSG",17019]],

CS[Cartesian,2],

AXIS["(E)",east,

ORDER[1],

LENGTHUNIT["metre",1,

ID["EPSG",9001]]],

AXIS["(N)",north,

ORDER[2],

LENGTHUNIT["metre",1,

ID["EPSG",9001],

TARGETCRS[

GEOGCRS["WGS 84",

DATUM["World Geodetic System 1984",

ELLIPSOID["WGS 84",6378137,298.257223563,

LENGTHUNIT["metre",1]]],

PRIMEM["Greenwich",0,

ANGLEUNIT["degree",0.0174532925199433]],

CS[ellipsoidal,2],

AXIS["latitude",north,

ORDER[1],

ANGLEUNIT["degree",0.0174532925199433]],

AXIS["longitude",east,

ORDER[2],

ANGLEUNIT["degree",0.0174532925199433]],

ID["EPSG",4326]]],

ABRIDGEDTRANSFORMATION["Transformation from unknown to WGS84",

METHOD["Geocentric translations (geog2D domain)",

ID["EPSG",9603]],

PARAMETER["X-axis translation",0,

ID["EPSG",8605]],

PARAMETER["Y-axis translation",0,

ID["EPSG",8606]],

PARAMETER["Z-axis translation",0,

ID["EPSG",8607

So, in some way, GDAL is able to cover this "breach" of information betwen 
PROJ4String and WKT2, but is not like the breach does not exist, it was just 
handled in some way, so, the lack of info, also means, there can be othe 
aproximations to that CRS.

Maybe I'm just confused, and mixing things the things I read, I'm just trying 
to figure it out, what and how would be the right transformation from 
proj4string to wkt2.

Thx.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Bug in OGR library

2022-01-10 Thread Rahkonen Jukka (MML)

Hi,

I asked you to create a GML with SQL query from one feature in a hope that the 
huuuge value from your database would be generated as a FID and appear in GML. 
Did you try what happens?

So if missing primary key is the main problem why not to add a primary key into 
your table? Or did you already try to run ogr2ogr with -unsetFid?

-Jukka Rahkonen-

Lähettäjä: Kopszak Marta - Partner Hurt 
Lähetetty: maanantai 10. tammikuuta 2022 16.09
Vastaanottaja: Rahkonen Jukka (MML) ; Even 
Rouault ; gdal-dev@lists.osgeo.org
Aihe: RE: [gdal-dev] Bug in OGR library

I think a single record wouldn't help you. If I would copy only one record to 
another empty database it could be exported to .xlsx. We have a postgres 
database and a table without any primary key, so QGIS uses a tid. The overall 
size of the database is huuuge (billions of records), so the tid reaches high 
values and apparently overflows int4.

Export to CSV goes fine, so it seems OGR’s CSV driver uses int8, but when 
exporting to XLSX or ODS you get that error. Maybe it’s just as simple as 
change id datatypes in affected drivers?

From: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Sent: Monday, January 10, 2022 2:24 PM
To: Kopszak Marta - Partner Hurt 
mailto:marta.kops...@orange.com>>; Even Rouault 
mailto:even.roua...@spatialys.com>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Bug in OGR library

Hi,

Now it starts to make sense. Could you paste the contents of a single row that 
you can’t write into xlsx format? You can capture it with ogrinfo “ogrinto 
[database connection] -sql "select * from my_table limit 1". Or maybe better to 
convert that row into GML format and attach that to your mail.

-Jukka Rahkonen-

Lähettäjä: Kopszak Marta - Partner Hurt 
mailto:marta.kops...@orange.com>>
Lähetetty: maanantai 10. tammikuuta 2022 15.07
Vastaanottaja: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>;
 Even Rouault mailto:even.roua...@spatialys.com>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: RE: [gdal-dev] Bug in OGR library

I have 2 bilions of rows in the  whole database and I try to export only one 
table which has 56 columns and 423 thousands of rows so it’s not the issue with 
Microsoft Excel limitation. I can’t write even a single row (error Feature 
creation error (OGR error: negative FID are not supported) occurs immediately),
Marta Kopszak

Hi,

Could you clarify a bit? You have billion rows in the database table but xlsx 
and ods can support at maximum a bit more than one million rows (1,048,576). 
You can’t imagine to have success with converting the whole table. Or is your 
problem that you can’t write even a single row from the source table because 
the value of the ID key is too big for xlsx/ods formats?

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Kopszak Marta - Partner Hurt
Lähetetty: maanantai 10. tammikuuta 2022 14.34
Vastaanottaja: Even Rouault 
mailto:even.roua...@spatialys.com>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: Re: [gdal-dev] Bug in OGR library

Hi Even,
Thanks for your replay. More info about the problem:

Error:
Save error:
Export to vector file failed.
Error: Feature write errors:
Feature creation error (OGR error: negative FID are not supported)

The database has more than 2 bilons of records (record – I mean record in the 
database table). The error occurs when I export a single table witout the 
primary key to .xlsx.

I suppose that when the table doesn’t have the primary key it use tid – the 
tuple identifier, and the size of tid may exceed the size of a 32-bit integer. 
It cause the problem to export this table to .xlsx format by OGR library.

Regards,
Marta Kopszak

From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Even Rouault
Sent: Monday, January 10, 2022 11:42 AM
To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Bug in OGR library


Marta,

What is the bug exactly ?

"2 billion records" : by record, you mean cells, like a sheet with 2048 columns 
and 1048576 rows ? By quickly looking at the code I can't see an obvious 
limitation, but that doesn't mean anything. Closer investigation would be 
needed. Please file an issue at https://github.com/OSGeo/gdal/issues/new with 
exact details how to reproduce (number of rows/features, and columns/fields in 
particular).

But even if the writer side would work, the OGR reader side would probably have 
issues as the whole spreadsheet will be loaded into RAM and for 2 billion 
cells, I would expect at least 32 or more GB of RAM to be needed. Perhaps 
spreadsheet software are able to cope with that in a smarter way.

Even
Le 10/01/2022 à 11:27, Kopszak Marta - Partner Hurt a écrit :
Dear Sirs,
I ran into an error when exporting data throug

Re: [gdal-dev] Bug in OGR library

2022-01-10 Thread Rahkonen Jukka (MML)

Hi,

Now it starts to make sense. Could you paste the contents of a single row that 
you can’t write into xlsx format? You can capture it with ogrinfo “ogrinto 
[database connection] -sql "select * from my_table limit 1". Or maybe better to 
convert that row into GML format and attach that to your mail.

-Jukka Rahkonen-

Lähettäjä: Kopszak Marta - Partner Hurt 
Lähetetty: maanantai 10. tammikuuta 2022 15.07
Vastaanottaja: Rahkonen Jukka (MML) ; Even 
Rouault ; gdal-dev@lists.osgeo.org
Aihe: RE: [gdal-dev] Bug in OGR library

I have 2 bilions of rows in the  whole database and I try to export only one 
table which has 56 columns and 423 thousands of rows so it’s not the issue with 
Microsoft Excel limitation. I can’t write even a single row (error Feature 
creation error (OGR error: negative FID are not supported) occurs immediately),
Marta Kopszak

Hi,

Could you clarify a bit? You have billion rows in the database table but xlsx 
and ods can support at maximum a bit more than one million rows (1,048,576). 
You can’t imagine to have success with converting the whole table. Or is your 
problem that you can’t write even a single row from the source table because 
the value of the ID key is too big for xlsx/ods formats?

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Kopszak Marta - Partner Hurt
Lähetetty: maanantai 10. tammikuuta 2022 14.34
Vastaanottaja: Even Rouault 
mailto:even.roua...@spatialys.com>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: Re: [gdal-dev] Bug in OGR library

Hi Even,
Thanks for your replay. More info about the problem:

Error:
Save error:
Export to vector file failed.
Error: Feature write errors:
Feature creation error (OGR error: negative FID are not supported)

The database has more than 2 bilons of records (record – I mean record in the 
database table). The error occurs when I export a single table witout the 
primary key to .xlsx.

I suppose that when the table doesn’t have the primary key it use tid – the 
tuple identifier, and the size of tid may exceed the size of a 32-bit integer. 
It cause the problem to export this table to .xlsx format by OGR library.

Regards,
Marta Kopszak

From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Even Rouault
Sent: Monday, January 10, 2022 11:42 AM
To: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Subject: Re: [gdal-dev] Bug in OGR library


Marta,

What is the bug exactly ?

"2 billion records" : by record, you mean cells, like a sheet with 2048 columns 
and 1048576 rows ? By quickly looking at the code I can't see an obvious 
limitation, but that doesn't mean anything. Closer investigation would be 
needed. Please file an issue at https://github.com/OSGeo/gdal/issues/new with 
exact details how to reproduce (number of rows/features, and columns/fields in 
particular).

But even if the writer side would work, the OGR reader side would probably have 
issues as the whole spreadsheet will be loaded into RAM and for 2 billion 
cells, I would expect at least 32 or more GB of RAM to be needed. Perhaps 
spreadsheet software are able to cope with that in a smarter way.

Even
Le 10/01/2022 à 11:27, Kopszak Marta - Partner Hurt a écrit :
Dear Sirs,
I ran into an error when exporting data through the OGR library to the .xlsx 
and .ods format. The bug occurs when there are more than 2 billion records in 
the database. I know the problem was solved for other formats, e.g. csv. Will 
the problem be solved also for other formats (e.g. xlsx, .ods)? If this is not 
the correct e-mail, please forward this e-mail to the appropriate person.

Kind regards,
Marta Kopszak

Marta Kopszak
Współpracownik<https://www.orange.pl/>

Rozwój Sieci Stacjonarnej, Wydział Rozwoju Planowania
Orange Polska, gen. Romualda Traugutta 55, 50-416 Wrocław | RODO - informacja o 
danych <https://www.orange.pl/>

 <https://www.orange.pl/>

<https://www.orange.pl/>

___<https://www.orange.pl/>

gdal-dev mailing list<https://www.orange.pl/>

gdal-dev@lists.osgeo.org<https://www.orange.pl/>

https://lists.osgeo.org/mailman/listinfo/gdal-dev<https://www.orange.pl/>

-- <https://www.orange.pl/>

http://www.spatialys.com<https://www.orange.pl/>

My software is free, but my time generally not.<https://www.orange.pl/>
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Bug in OGR library

2022-01-10 Thread Rahkonen Jukka (MML)

Hi,

Could you clarify a bit? You have billion rows in the database table but xlsx 
and ods can support at maximum a bit more than one million rows (1,048,576). 
You can’t imagine to have success with converting the whole table. Or is your 
problem that you can’t write even a single row from the source table because 
the value of the ID key is too big for xlsx/ods formats?

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Kopszak Marta - 
Partner Hurt
Lähetetty: maanantai 10. tammikuuta 2022 14.34
Vastaanottaja: Even Rouault ; 
gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] Bug in OGR library

Hi Even,
Thanks for your replay. More info about the problem:

Error:
Save error:
Export to vector file failed.
Error: Feature write errors:
Feature creation error (OGR error: negative FID are not supported)

The database has more than 2 bilons of records (record – I mean record in the 
database table). The error occurs when I export a single table witout the 
primary key to .xlsx.

I suppose that when the table doesn’t have the primary key it use tid – the 
tuple identifier, and the size of tid may exceed the size of a 32-bit integer. 
It cause the problem to export this table to .xlsx format by OGR library.

Regards,
Marta Kopszak

From: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> On 
Behalf Of Even Rouault
Sent: Monday, January 10, 2022 11:42 AM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] Bug in OGR library


Marta,

What is the bug exactly ?

"2 billion records" : by record, you mean cells, like a sheet with 2048 columns 
and 1048576 rows ? By quickly looking at the code I can't see an obvious 
limitation, but that doesn't mean anything. Closer investigation would be 
needed. Please file an issue at https://github.com/OSGeo/gdal/issues/new with 
exact details how to reproduce (number of rows/features, and columns/fields in 
particular).

But even if the writer side would work, the OGR reader side would probably have 
issues as the whole spreadsheet will be loaded into RAM and for 2 billion 
cells, I would expect at least 32 or more GB of RAM to be needed. Perhaps 
spreadsheet software are able to cope with that in a smarter way.

Even
Le 10/01/2022 à 11:27, Kopszak Marta - Partner Hurt a écrit :
Dear Sirs,
I ran into an error when exporting data through the OGR library to the .xlsx 
and .ods format. The bug occurs when there are more than 2 billion records in 
the database. I know the problem was solved for other formats, e.g. csv. Will 
the problem be solved also for other formats (e.g. xlsx, .ods)? If this is not 
the correct e-mail, please forward this e-mail to the appropriate person.

Kind regards,
Marta Kopszak

Marta Kopszak
Współpracownik

Rozwój Sieci Stacjonarnej, Wydział Rozwoju Planowania
Orange Polska, gen. Romualda Traugutta 55, 50-416 Wrocław | RODO - informacja o 
danych 

 



___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev

-- 

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Bug in OGR library

2022-01-10 Thread Rahkonen Jukka (MML)

Hi,

Excel xlsx format supports at maximum 1,048,576 rows by 16,384 columns 
https://support.microsoft.com/en-us/office/excel-specifications-and-limits-1672b34d-7043-467e-8e27-269d656771c3.
 Do your data fit within these limits?

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Kopszak Marta - 
Partner Hurt
Lähetetty: maanantai 10. tammikuuta 2022 12.28
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Bug in OGR library

Dear Sirs,
I ran into an error when exporting data through the OGR library to the .xlsx 
and .ods format. The bug occurs when there are more than 2 billion records in 
the database. I know the problem was solved for other formats, e.g. csv. Will 
the problem be solved also for other formats (e.g. xlsx, .ods)? If this is not 
the correct e-mail, please forward this e-mail to the appropriate person.

Kind regards,
Marta Kopszak
[Lähettäjä poisti kuvan. Logo Orange]

Marta Kopszak
Współpracownik

Rozwój Sieci Stacjonarnej, Wydział Rozwoju Planowania
Orange Polska, gen. Romualda Traugutta 55, 50-416 Wrocław | RODO - informacja o 
danych


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: promote GDAL 3.4.1 RC1

2021-12-30 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: torstai 30. joulukuuta 2021 11.30
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: promote GDAL 3.4.1 RC1

Hi,

Having heard no issues being reported regarding RC1

Motion:

Adopt GDAL 3.4.1 RC1 as final 3.4.1 release

Starting with my +1

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogrinfo XML (AIXM)

2021-12-09 Thread Rahkonen Jukka (MML)

Hi,

Please try the unsubscribe link at the bottom of the mailing list info page 
https://lists.osgeo.org/mailman/listinfo/gdal-dev.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Baker (US), 
Anthony W
Lähetetty: torstai 9. joulukuuta 2021 14.02
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] ogrinfo XML (AIXM)

Please remove me from this email distribution.

Thank you

From: gdal-dev [mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of 
paul.m...@lfv.se
Sent: Thursday, December 09, 2021 3:52 AM
To: even.roua...@spatialys.com; 
gdal-dev@lists.osgeo.org
Subject: [EXTERNAL] Re: [gdal-dev] ogrinfo XML (AIXM)


EXT email: be mindful of links/attachments.




Is this the correct syntax:
C:\>ogrinfo GMLAS:c:\Temp\data\Mydata.GML

I get the error:
ERROR 3: Cannot resolve http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd
FAILURE:
Unable to open datasource `GMLAS:c:\Temp\eaddata\EADdata.GML' with the 
following drivers.
  -> BAG
  -> JP2ECW
  -> FITS
  -> netCDF
  -> PDF
  -> AmigoCloud
  -> FileGDB
  -> ESRIC
  -> PCIDSK
  -> PDS4
  -> VICAR
  -> JP2OpenJPEG
  -> MBTiles
  -> EEDA
  -> OGCAPI
  -> DB2ODBC
  -> ESRI Shapefile
  -> MapInfo File
  -> UK .NTF
  -> LVBAG
  -> OGR_SDTS
  -> S57
  -> DGN
  -> OGR_VRT
  -> REC
  -> Memory
  -> BNA
  -> CSV
  -> NAS
  -> GML
  -> GPX
  -> LIBKML
  -> KML
  -> GeoJSON
  -> GeoJSONSeq
  -> ESRIJSON
  -> TopoJSON
  -> Interlis 1
  -> Interlis 2
  -> OGR_GMT
  -> GPKG
  -> SQLite
  -> ODBC
  -> WAsP
  -> PGeo
  -> MSSQLSpatial
  -> OGR_OGDI
  -> PostgreSQL
  -> MySQL
  -> OpenFileGDB
  -> XPlane
  -> DXF
  -> CAD
  -> FlatGeobuf
  -> Geoconcept
  -> GeoRSS
  -> GPSTrackMaker
  -> VFK
  -> PGDUMP
  -> OSM
  -> GPSBabel
  -> SUA
  -> OpenAir
  -> OGR_PDS
  -> WFS
  -> OAPIF
  -> HTF
  -> AeronavFAA
  -> Geomedia
  -> EDIGEO
  -> SVG
  -> CouchDB
  -> Cloudant
  -> Idrisi
  -> ARCGEN
  -> SEGUKOOA
  -> SEGY
  -> ODS
  -> XLSX
  -> Elasticsearch
  -> Walk
  -> Carto
  -> SXF
  -> Selafin
  -> JML
  -> PLSCENES
  -> CSW
  -> VDV
  -> GMLAS
  -> MVT
  -> NGW
  -> MapML
  -> TIGER
  -> AVCBin
  -> AVCE00
  -> HTTP

Kind regards,
Paul

Från: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> För 
Even Rouault
Skickat: den 8 december 2021 14:17
Till: gdal-dev@lists.osgeo.org
Ämne: Re: [gdal-dev] ogrinfo XML (AIXM)


Klicka bara på länkar och öppna bilagor om du litar på avsändaren och vet att 
innehållet är säkert.

Paul,

the GML driver can open some formulation of AIXM, but probably not all.

You may also try the generic GMLAS driver: 
https://gdal.org/drivers/vector/gmlas.html

Even
Le 08/12/2021 à 14:06, paul.m...@lfv.se a écrit :
Hi,
I'm trying to read a XML (AIXM) file. But ogrinfo says it can't be read with 
either  KML, KMZ or GML installed drivers (among other formats).
Is there anything I must do, the GML, KML, KMZ drivers are there. I'm working 
in Windows 10.
Kind Regards,
Paul


[1_LFV_svensk_96]
  Paul Malm

  Operations / AIM Flyginfo SE



  Direkt  08-797 70 23  Mobil 070-860 11 15
  paul.m...@lfv.se
   Besöks- och postadress
   LFV Flyginfo SE
   Af Pontins väg 6
   115 21 STOCKHOLM







   Tänk på miljön innan du skriver ut detta e-postmeddelande.







___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogrinfo XML (AIXM)

2021-12-09 Thread Rahkonen Jukka (MML)

Hi,

Re-sending to the list without old discussion because the mail body grew too 
large and was rejected.

I do not have not much experience about GMLAS but I made a test with this file 
https://github.com/aixm/donlon/blob/master/EA_EADD_OBS_DS_AREA_2_3_4_FULL_20191205.xml

and GDAL GMLAS found 1655 layers with "ogrinfo GMLAS:aixtest.xml" without 
editing the file so it seems that GDAL can follow http redirections and there 
is some other problem with your XML. Try the test files from GitHub and try to 
find out what is different in your GML.

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogrinfo XML (AIXM)

2021-12-09 Thread Rahkonen Jukka (MML)

Hi,

Perhaps GDAL does not follow redirections automatically:

curl http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd


301 Moved Permanently

Moved Permanently
The document has moved https://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd>here.


Did you already edit your GML by changing http into https?

-Jukka Rahkonen-

Lähettäjä: paul.m...@lfv.se 
Lähetetty: torstai 9. joulukuuta 2021 11.19
Vastaanottaja: Rahkonen Jukka (MML) ; 
even.roua...@spatialys.com; gdal-dev@lists.osgeo.org
Aihe: SV: [gdal-dev] ogrinfo XML (AIXM)

Hi,
I turnd off the proxy and added -debug on.
This is the result:
ogrinfo GMLAS:c:\Temp\data\mydata.GML --debug on
GDAL: Auto register C:\Program Files\Gdal_321\bin\gdal\plugins\gdal_BAG.dll 
using GDALRegister_BAG.
GDAL: Auto register C:\Program 
Files\Gdal_321\bin\gdal\plugins\gdal_ECW_JP2ECW.dll using 
GDALRegister_ECW_JP2ECW.
GDAL: Auto register C:\Program Files\Gdal_321\bin\gdal\plugins\gdal_FITS.dll 
using GDALRegister_FITS.
GDAL: Auto register C:\Program Files\Gdal_321\bin\gdal\plugins\gdal_GMT.dll 
using GDALRegister_GMT.
GDAL: Auto register C:\Program Files\Gdal_321\bin\gdal\plugins\gdal_HDF4.dll 
using GDALRegister_HDF4.
GDAL: Auto register C:\Program 
Files\Gdal_321\bin\gdal\plugins\gdal_HDF4Image.dll using GDALRegister_HDF4Image.
GDAL: Auto register C:\Program Files\Gdal_321\bin\gdal\plugins\gdal_HDF5.dll 
using GDALRegister_HDF5.
GDAL: Auto register C:\Program 
Files\Gdal_321\bin\gdal\plugins\gdal_HDF5Image.dll using GDALRegister_HDF5Image.
GDAL: Auto register C:\Program Files\Gdal_321\bin\gdal\plugins\gdal_KEA.dll 
using GDALRegister_KEA.
GDAL: Auto register C:\Program 
Files\Gdal_321\bin\gdal\plugins\gdal_MG4Lidar.dll using GDALRegister_MG4Lidar.
GDAL: Auto register C:\Program Files\Gdal_321\bin\gdal\plugins\gdal_MrSID.dll 
using GDALRegister_MrSID.
GDAL: Auto register C:\Program Files\Gdal_321\bin\gdal\plugins\gdal_netCDF.dll 
using GDALRegister_netCDF.
GDAL: Auto register C:\Program Files\Gdal_321\bin\gdal\plugins\gdal_PDF.dll 
using GDALRegister_PDF.
GDAL: Auto register C:\Program 
Files\Gdal_321\bin\gdal\plugins\ogr_AmigoCloud.dll using RegisterOGRAmigoCloud.
GDAL: Auto register C:\Program 
Files\Gdal_321\bin\gdal\plugins-external\ogr_FileGDB.dll using 
RegisterOGRFileGDB.
OGR: XMLPlatformUtils::Initialize()
GMLAS: XSD cache directory: C:\Users\anpaumal\.gdal\gmlas_xsd_cache
GMLAS: 
noNamespaceSchemaLocation=http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd
GMLAS: Resolving http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd () to 
/vsicurl_streaming/http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd
VSICURL: Start download for http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd
HTTP: libcurl/7.74.0-DEV OpenSSL/1.1.1i zlib/1.2.11
VSICURL: Stop download for http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd
ERROR 3: Cannot resolve http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd
OGR: XMLPlatformUtils::Terminate()
FAILURE:
Unable to open datasource `GMLAS:c:\Temp\data\mydata.GML' with the following 
drivers.
  -> BAG
  -> JP2ECW
  -> FITS
  -> netCDF
  -> PDF
  -> AmigoCloud
  -> FileGDB
  -> ESRIC
  -> PCIDSK
  -> PDS4
  -> VICAR
  -> JP2OpenJPEG
  -> MBTiles
  -> EEDA
  -> OGCAPI
  -> DB2ODBC
  -> ESRI Shapefile
  -> MapInfo File
  -> UK .NTF
  -> LVBAG
  -> OGR_SDTS
  -> S57
  -> DGN
  -> OGR_VRT
  -> REC
  -> Memory
  -> BNA
  -> CSV
  -> NAS
  -> GML
  -> GPX
  -> LIBKML
  -> KML
  -> GeoJSON
  -> GeoJSONSeq
  -> ESRIJSON
  -> TopoJSON
  -> Interlis 1
  -> Interlis 2
  -> OGR_GMT
  -> GPKG
  -> SQLite
  -> ODBC
  -> WAsP
  -> PGeo
  -> MSSQLSpatial
  -> OGR_OGDI
  -> PostgreSQL
  -> MySQL
  -> OpenFileGDB
  -> XPlane
  -> DXF
  -> CAD
  -> FlatGeobuf
  -> Geoconcept
  -> GeoRSS
  -> GPSTrackMaker
  -> VFK
  -> PGDUMP
  -> OSM
  -> GPSBabel
  -> SUA
  -> OpenAir
  -> OGR_PDS
  -> WFS
  -> OAPIF
  -> HTF
  -> AeronavFAA
  -> Geomedia
  -> EDIGEO
  -> SVG
  -> CouchDB
  -> Cloudant
  -> Idrisi
  -> ARCGEN
  -> SEGUKOOA
  -> SEGY
  -> ODS
  -> XLSX
  -> Elasticsearch
  -> Walk
  -> Carto
  -> SXF
  -> Selafin
  -> JML
  -> PLSCENES
  -> CSW
  -> VDV
  -> GMLAS
  -> MVT
  -> NGW
  -> MapML
  -> TIGER
  -> AVCBin
  -> AVCE00
  -> HTTP
GDAL: In GDALDestroy - unloading GDAL shared library.

Från: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Skickat: den 9 december 2021 10:11
Till: Malm, Paul (Operations AIM) mailto:paul.m...@lfv.se>>; 
even.roua...@spatialys.com<mailto:even.roua...@spatialys.com>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Ämne: Re: [gdal-dev] ogrinfo XML (AIXM)


Klicka bara på länkar och öppna bilagor om du litar på avsändaren och vet att 
innehållet är säkert.
Hi,

The syntax is c

Re: [gdal-dev] ogrinfo XML (AIXM)

2021-12-09 Thread Rahkonen Jukka (MML)

Hi,

The syntax is correct but "ogrinfo GMLAS:c:\Temp\data\Mydata.GML --debug on" 
would print much more info. Now something fails here: ERROR 3: Cannot resolve 
http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd

The schema file seems to be moved to https, I would have a try by editing that 
in your GML file. If you are behind a proxy server set http_proxy and 
https_proxy environment variables so that GDAL can access the schemas.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta paul.m...@lfv.se
Lähetetty: torstai 9. joulukuuta 2021 10.52
Vastaanottaja: even.roua...@spatialys.com; gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] ogrinfo XML (AIXM)

Is this the correct syntax:
C:\>ogrinfo GMLAS:c:\Temp\data\Mydata.GML

I get the error:
ERROR 3: Cannot resolve http://www.aixm.aero/schema/4.5/AIXM-Snapshot.xsd
FAILURE:
Unable to open datasource `GMLAS:c:\Temp\eaddata\EADdata.GML' with the 
following drivers.
  -> BAG
  -> JP2ECW
  -> FITS
  -> netCDF
  -> PDF
  -> AmigoCloud
  -> FileGDB
  -> ESRIC
  -> PCIDSK
  -> PDS4
  -> VICAR
  -> JP2OpenJPEG
  -> MBTiles
  -> EEDA
  -> OGCAPI
  -> DB2ODBC
  -> ESRI Shapefile
  -> MapInfo File
  -> UK .NTF
  -> LVBAG
  -> OGR_SDTS
  -> S57
  -> DGN
  -> OGR_VRT
  -> REC
  -> Memory
  -> BNA
  -> CSV
  -> NAS
  -> GML
  -> GPX
  -> LIBKML
  -> KML
  -> GeoJSON
  -> GeoJSONSeq
  -> ESRIJSON
  -> TopoJSON
  -> Interlis 1
  -> Interlis 2
  -> OGR_GMT
  -> GPKG
  -> SQLite
  -> ODBC
  -> WAsP
  -> PGeo
  -> MSSQLSpatial
  -> OGR_OGDI
  -> PostgreSQL
  -> MySQL
  -> OpenFileGDB
  -> XPlane
  -> DXF
  -> CAD
  -> FlatGeobuf
  -> Geoconcept
  -> GeoRSS
  -> GPSTrackMaker
  -> VFK
  -> PGDUMP
  -> OSM
  -> GPSBabel
  -> SUA
  -> OpenAir
  -> OGR_PDS
  -> WFS
  -> OAPIF
  -> HTF
  -> AeronavFAA
  -> Geomedia
  -> EDIGEO
  -> SVG
  -> CouchDB
  -> Cloudant
  -> Idrisi
  -> ARCGEN
  -> SEGUKOOA
  -> SEGY
  -> ODS
  -> XLSX
  -> Elasticsearch
  -> Walk
  -> Carto
  -> SXF
  -> Selafin
  -> JML
  -> PLSCENES
  -> CSW
  -> VDV
  -> GMLAS
  -> MVT
  -> NGW
  -> MapML
  -> TIGER
  -> AVCBin
  -> AVCE00
  -> HTTP

Kind regards,
Paul

Från: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> För 
Even Rouault
Skickat: den 8 december 2021 14:17
Till: gdal-dev@lists.osgeo.org
Ämne: Re: [gdal-dev] ogrinfo XML (AIXM)


Klicka bara på länkar och öppna bilagor om du litar på avsändaren och vet att 
innehållet är säkert.

Paul,

the GML driver can open some formulation of AIXM, but probably not all.

You may also try the generic GMLAS driver: 
https://gdal.org/drivers/vector/gmlas.html

Even
Le 08/12/2021 à 14:06, paul.m...@lfv.se a écrit :
Hi,
I'm trying to read a XML (AIXM) file. But ogrinfo says it can't be read with 
either  KML, KMZ or GML installed drivers (among other formats).
Is there anything I must do, the GML, KML, KMZ drivers are there. I'm working 
in Windows 10.
Kind Regards,
Paul


[1_LFV_svensk_96]
  Paul Malm

  Operations / AIM Flyginfo SE



  Direkt  08-797 70 23  Mobil 070-860 11 15
  paul.m...@lfv.se
   Besöks- och postadress
   LFV Flyginfo SE
   Af Pontins väg 6
   115 21 STOCKHOLM







   Tänk på miljön innan du skriver ut detta e-postmeddelande.







___

gdal-dev mailing list

gdal-dev@lists.osgeo.org

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] sqlite3_prepare_v2 no such function: envelope

2021-12-03 Thread Rahkonen Jukka (MML)

Hi,

Check the spatialite version:
ogrinfo -dialect sqlite -sql "select spatialite_version()" parks.shp

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Richard 
Greenwood
Lähetetty: perjantai 3. joulukuuta 2021 21.22
Vastaanottaja: GDAL List 
Aihe: [gdal-dev] sqlite3_prepare_v2 no such function: envelope

I have an ogr2ogr statement that works in OGR 3.3.3 but not 3.4.0. The 
statement is:
   ogr2ogr out parks.shp -dialect sqlite -sql "select envelope(geometry) from 
parks"
And the error in 3.4.0 is
   ERROR 1: In ExecuteSQL(): sqlite3_prepare_v2 no such function: envelope
Is this expected? I'm on two different Linux computers with gdal built from 
source so maybe I've got something else going on but I have no idea what.

Thanks
--
Richard W. Greenwood
www.greenwoodmap.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] PGCLIENTENCODING in ogr2ogr (and QGIS)

2021-11-30 Thread Rahkonen Jukka (MML)

Hi,

Would you mind to include your whole ogr2ogr command (no passwords etc.) and if 
possible, link to some small shapefile? And confirm that your aim is to save 
shapefiles with Latin1 encoding into PostGIS database that is using UTF-8 
encoding.

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: matteo  
Lähetetty: tiistai 30. marraskuuta 2021 13.05
Vastaanottaja: Even Rouault ; Rahkonen Jukka (MML) 
; gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] PGCLIENTENCODING in ogr2ogr (and QGIS)

Hi Rahkonen and Even,

thanks for the answers. If I add -oo PRELUDE_STATEMENTS="SET client_encoding TO 
LATIN1" the I get this error:

Warning 6: driver ESRI Shapefile does not support open option PRELUDE_STATEMENTS

and I think it that makes sense because I want to put in a UTF8 DB some
LATIN1 shapefiles.

BTW: the shapefiles have been created with ogr2ogr from within QGIS (on a Linux 
computer), opened and edited on QGIS on Windows machines.

Other ideas are more than welcome!

Cheers!

Matteo
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Should we make also GTiff to use TILED=YES as default?

2021-11-30 Thread Rahkonen Jukka (MML)

Hi,

On the other hand those QGIS users pay the price every time when they zoom 
close to the same image because then QGIS must read many super wide rows of 
data instead of just the tiles that intersect the view. Not even overviews 
which are created on top of striped image do not help when user hit the native 
resolution. But perhaps it is not so important what is the default, experienced 
users maybe know what they want.

-Jukka Rahkonen-

Lähettäjä: Javier Jimenez Shaw 
Lähetetty: tiistai 30. marraskuuta 2021 11.09
Vastaanottaja: Rahkonen Jukka (MML) 
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] Should we make also GTiff to use TILED=YES as default?

Hi Jukka

I don't think it is a good option.
TL;DR: tiled without overviews is extremely slow for a global view.

If you have a (big) image with TILED=YES but without overviews, it is really 
really slow in QGIS (from seconds to many minutes).
The reason (I guess) is that QGIS is by default sub-sampling the image using 
nearest neighbor. If the image is not tiled, then it has to read only every nth 
line. However, when tiled, at the end has to read the full image from file.
The bigger the zoom level, the faster it goes. But waiting 5 minutes to see the 
global view of your image to know where to zoom in... you close QGIS and blame 
somebody.

That changes dramatically if there are (proper) overviews available, of course.

Cheers
.___ ._ ..._ .. . ._.  .___ .. __ . _. . __..  ...  ._ .__
Entre dos pensamientos racionales
hay infinitos pensamientos irracionales.


On Tue, 30 Nov 2021 at 08:04, Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

There are loads of questions in the stack.exchange site where users have 
problems with performance when they do something with reading and writing very 
large image files. Big files have obviously become much more common now due to 
clouds. Users try to solve the problem by increasing GDAL_CACHEMAX and using 
multithreading etc. but they use the default GeoTIFF settings and keep on 
writing huge striped TIFFs. I wonder if we should make tiling the default also 
for the GTiff driver like it is in the COG driver.

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr and WFS 2

2021-11-29 Thread Rahkonen Jukka (MML)

Hi,

There is something about WFS 2 and paging in
https://gdal.org/drivers/vector/wfs.html

“Paging with WFS 2.0
The WFS driver will automatically detect if server supports paging, when
requesting a WFS 2.0 server. The page size (number of features fetched in a
single request) is limited to 100 by default when not declared by the server.
It can be changed by setting the OGR_WFS_PAGE_SIZE configuration option, or by
specifying COUNT as a query parameter in the URL of the connection string.

If only the N first features must be downloaded and paging through the whole
layer is not desirable, the OGR_WFS_PAGING_ALLOWED configuration option should
be set to OFF.”

So by default normally GDAL goes to paging mode that makes it possible to read
the whole featuretype, possibly restricted with BBOX or other filters but it
should be possible to disable paging with --config OGR_WFS_PAGING_ALLOWED OFF.
I would try that.

-Jukka Rahkonen-

Lähettäjä: gdal-dev Puolesta Hernán De
Angelis
Lähetetty: maanantai 29. marraskuuta 2021 12.43
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] ogr2ogr and WFS 2

Dear all

I seem to have problems understanding how ogr2ogr interacts with WFS and hope
someone would be able to clarify.

I have this WFS:

https://stationsregister.miljodatasamverkan.se/geoserver/stationsregistret/wfs?

The capabilities document states that it supports WFS 1.0.0, 1.1.0 and 2.0.0.

If I do:

ogr2ogr -f GPKG test.gpkg
"WFS:https://stationsregister.miljodatasamverkan.se/geoserver/stationsregistret/wfs?SERVICE=WFS=1.0.0=GetFeature=stationsregistret:active_site=100;

I get a small and nice GPKG file very fast.

But if I do:

ogr2ogr -f GPKG test.gpkg
"WFS:https://stationsregister.miljodatasamverkan.se/geoserver/stationsregistret/wfs?SERVICE=WFS=2.0.0=GetFeature=stationsregistret:active_site=100;

It downloads the whole layer.

This behaviour can be seriously impractical for services exposing a large
number of features.

Pay attention that if I do:

curl
"https://stationsregister.miljodatasamverkan.se/geoserver/stationsregistret/wfs?SERVICE=WFS=2.0.0=GetFeature=stationsregistret:active_site=100;

it retrieves a short document fast with just 100 features. The same of course
if I invoke the service using WFS 1.0.0 or 1.1.0.

What is going on here? Is it me that I misunderstood something about how
ogr2ogr is supposed to interact with WFS services?

Using GDAL 3.4.0, released 2021/11/04. But the same behaviour was observed in
3.3.2.

Thanks in advance for any clarification

Hernán

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Should we make also GTiff to use TILED=YES as default?

2021-11-29 Thread Rahkonen Jukka (MML)

Hi,

There are loads of questions in the stack.exchange site where users have 
problems with performance when they do something with reading and writing very 
large image files. Big files have obviously become much more common now due to 
clouds. Users try to solve the problem by increasing GDAL_CACHEMAX and using 
multithreading etc. but they use the default GeoTIFF settings and keep on 
writing huge striped TIFFs. I wonder if we should make tiling the default also 
for the GTiff driver like it is in the COG driver.

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] PGCLIENTENCODING in ogr2ogr (and QGIS)

2021-11-29 Thread Rahkonen Jukka (MML)

Hi,

There is some text about client encoding in 
https://gdal.org/drivers/vector/pg.html

" By default it is assumed that text being sent to Postgres is in the UTF-8 
encoding. This is fine for plain ASCII, but can result in errors for extended 
characters (ASCII 155+, LATIN1, etc). While OGR provides no direct control over 
this, you can set the PGCLIENTENCODING environment variable to indicate the 
format being provided. For instance, if your text is LATIN1 you could set the 
environment variable to LATIN1 before using OGR and input would be assumed to 
be LATIN1 instead of UTF-8. An alternate way of setting the client encoding is 
to issue the following SQL command with ExecuteSQL() : "SET client_encoding TO 
encoding_name" where encoding_name is LATIN1, etc. Errors can be caught by 
enclosing this command with a CPLPushErrorHandler()/CPLPopErrorHandler() pair."

I would try with that environmental variable first.

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta matteo
Lähetetty: maanantai 29. marraskuuta 2021 18.52
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] PGCLIENTENCODING in ogr2ogr (and QGIS)

Hi all,

I'm trying to run a command with the GdalUtils.runGdal utility of QGIS but I 
get some troubles because of the encoding.

Basically I need to set the encoding to PGCLIENTENCODING=LATIN1. If I call it 
in a console, no problem at all (of course :) ). Wondering if I can set the 
encoding also within QGIS (that is basically via the ogr2ogr command).

I know that this is a more QGIS question, but QGIS is calling ogr2ogr, so I 
think if there is a ogr2ogr way to do that then also within QGIS should be 
possible.

Cheers and thanks for any ideas!

Matteo
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL COG - Problem with Overviews

2021-11-25 Thread Rahkonen Jukka (MML)

Hi,

Please use “reply to all” for including the list as a recipient.
More details would lead to less guessing. Please add gdalinfo about the source 
and result (georeferencing is not important), tell how did you get the image of 
the original (which bands were selected, was any color enhancement applied). 
QGIS and a look at Layer properties – Symbology is good for that. Test with 
gdal_translate before going to Python and send us the command if you face the 
same trouble. If you cannot solve the problem yourself send a link to test 
image. It does not need to be your real image, any technically similar image is 
good and usually even better if you cut it smaller. A 200x200 pixel sized piece 
of the original image without georeferencing is one alternative that probably 
would not reveal secrets.

-Jukka Rahkonen-

Lähettäjä: Nicole Kamp 
Lähetetty: torstai 25. marraskuuta 2021 15.22
Vastaanottaja: Rahkonen Jukka (MML) 
Aihe: Re: [gdal-dev] GDAL COG - Problem with Overviews

Hello!
Thanks. I tried it with 0,1,2 - it did not work.


On Thu, Nov 25, 2021 at 1:49 PM Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

Maybe the band list be zero based? Try [0,1,2].

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Nicole Kamp
Lähetetty: torstai 25. marraskuuta 2021 14.44
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] GDAL COG - Problem with Overviews

Dear GDAL Developers,
I have an overview problem with my Cloud Optimized GeoTIFF.
I tried to translate a 16 bit, 4 bands ortho image to a COG 8bit, 3 bands image 
with JPEG compression.

That is the original image.<https://pasteboard.co/CLur6VdD0CwQ.jpg>
That is the result.<https://pasteboard.co/MJv3lOjlI8iM.jpg>

It works fine with LZW compression, but I need the JPEG compression. What am I 
doing wrong?

Thanks,
Niki


Here is my code.
for raster in glob.glob(str(parameters[self.INPUT_Pfad])+'/*.tif'):
fileInfo = QFileInfo(raster)
baseName = fileInfo.baseName()
file_name = str(parameters[self.INPUT_Pfad])+'/'+baseName+'.tif'
feedback.pushInfo(file_name)
output_file1 = str(parameters[self.OUTPUT_Pfad])+'/'+baseName+'.tif'
output_file2 = 
str(parameters[self.OUTPUT_Pfad])+'/'+baseName+'_cog.tif'

# Create COG
x_size = 6250
y_size = 5000
num_bands = 4

src_ds = gdal.Open(file_name)
format = "GTiff"
driver = gdal.GetDriverByName(format)

# Translate
translate_options = gdal.TranslateOptions(format = 'COG', 
outputType = gdal.GDT_Byte, bandList =  
   [1,2,3],  scaleParams=[''],
  creationOptions = 
['TILED=YES','COMPRESS=JPEG','BIGTIFF=IF_NEEDED',   
   'BLOCKXSIZE=512', 'BLOCKYSIZE=512', 
'RESAMPLING=NEAREST',   
 'OVERVIEWS=IGNORE_EXISTING', 'INTERLEAVE=PIXEL']
  )
gdal.Translate(output_file1, src_ds, options=translate_options)

translate_options = None
src_ds = None
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL COG - Problem with Overviews

2021-11-25 Thread Rahkonen Jukka (MML)

Hi,

Maybe the band list be zero based? Try [0,1,2].

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Nicole Kamp
Lähetetty: torstai 25. marraskuuta 2021 14.44
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] GDAL COG - Problem with Overviews

Dear GDAL Developers,
I have an overview problem with my Cloud Optimized GeoTIFF.
I tried to translate a 16 bit, 4 bands ortho image to a COG 8bit, 3 bands image 
with JPEG compression.

That is the original image.
That is the result.

It works fine with LZW compression, but I need the JPEG compression. What am I 
doing wrong?

Thanks,
Niki


Here is my code.
for raster in glob.glob(str(parameters[self.INPUT_Pfad])+'/*.tif'):
fileInfo = QFileInfo(raster)
baseName = fileInfo.baseName()
file_name = str(parameters[self.INPUT_Pfad])+'/'+baseName+'.tif'
feedback.pushInfo(file_name)
output_file1 = str(parameters[self.OUTPUT_Pfad])+'/'+baseName+'.tif'
output_file2 = 
str(parameters[self.OUTPUT_Pfad])+'/'+baseName+'_cog.tif'

# Create COG
x_size = 6250
y_size = 5000
num_bands = 4

src_ds = gdal.Open(file_name)
format = "GTiff"
driver = gdal.GetDriverByName(format)

# Translate
translate_options = gdal.TranslateOptions(format = 'COG', 
outputType = gdal.GDT_Byte, bandList =  
   [1,2,3],  scaleParams=[''],
  creationOptions = 
['TILED=YES','COMPRESS=JPEG','BIGTIFF=IF_NEEDED',   
   'BLOCKXSIZE=512', 'BLOCKYSIZE=512', 
'RESAMPLING=NEAREST',   
 'OVERVIEWS=IGNORE_EXISTING', 'INTERLEAVE=PIXEL']
  )
gdal.Translate(output_file1, src_ds, options=translate_options)

translate_options = None
src_ds = None
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Gdal_edit and -gcp as read-only

2021-11-22 Thread Rahkonen Jukka (MML)

Hi,

I tried to add ground control points into a TIFF file with gdal_edit. I do not 
want to touch the TIFF so I used the read-only option and supposed that gcp 
would be written into .aux.xml file but that did not happen. Instead I got a 
message

gdal_edit -ro -gcp 1 1 20 30 test.tif
ERROR 6: test.tif: SetGCPs() is only supported on newly created GeoTIFF files.

Without -ro gdal_edit adds ground control points into the TIFF without errors. 
What might be the meaning of the message about "newly created GeoTIFF" and is 
there some way to make gdal_edit to write ground control points into PAM file? 
I know that I can use gdal_translate and VRT as a workaround but PAM .aux.xml 
could be a bit better for my whole workflow.

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDALWMS - error: TCP connection reset by peer

2021-11-19 Thread Rahkonen Jukka (MML)

Hi,

Large MaxConnections value leads to more concurrent requests and it may cause 
problems if the WMS server is very busy. Reducing MaxConnections may help if 
you are the only user of that WMS but if there are thousands of other users as 
well the service may still run at 100% and drop request either because they 
reach the server side timeout or because load balancer denies requests. If the 
overload is temporary then retry after a while could help but I do not believe 
that GDAL WMS driver can be configured that way  
https://gdal.org/drivers/raster/wms.html.  Special tile cache programs like 
GeoWebCache are better prepared for failing requests 
https://www.geowebcache.org/docs/current/production/index.html#seed-failure-tolerance

The GDAL WMS configuration options are documented only by example 
https://gdal.org/drivers/raster/wms.html. I wonder where I could find 
information about the meaning of options that I can't guess by the name, like 
"CleanTimeout".

 -Jukka Rahkonen-

Lähettäjä: Roman Breitfuss-Schiffer 
Lähetetty: perjantai 19. marraskuuta 2021 10.18
Vastaanottaja: Rahkonen Jukka (MML) ; 
gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] GDALWMS - error: TCP connection reset by peer


Dear Jukka!

Thanks for your answer! I think I'm gonna follow that road you suggested.

We have been thinking a lot and I was just wondering if there could be some 
GDAL configuration which could cause that behaviour? For example the value for 
 in the WMS XML file? Or if more applications are accessing the 
same WMS XML at the same time which is theoretically possible in our case.

Best regards
Roman
Am 18.11.2021 um 12:12 schrieb Rahkonen Jukka (MML):
Hi,

It seems that the WMS server is closing the door and there is nothing else to 
do on the GDAL side except to try again later. Contact the WMS service 
maintainer and report your troubles. They may be able to provide you a more 
reliable service especially if you are ready to pay for it.

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
<mailto:gdal-dev-boun...@lists.osgeo.org> 
Puolesta Roman Breitfuss-Schiffer
Lähetetty: torstai 18. marraskuuta 2021 11.59
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] GDALWMS - error: TCP connection reset by peer


Dear all!

We are running a Python application an a linux distribution (RedHat) which 
creates clips in MBTILES format from a WMS. We are using the Python-API and are 
basically doing something like this:

src_ds = gdal.Warp(
tmp_file,
ds_in,
format='GTiff',
outputBounds=[bbox[0], bbox[2], bbox[1], bbox[3]],
dstSRS=output_srs,
)
ds_out = gdal.Translate(
out_filepath,
src_ds,
format='MBTILES',
creationOptions=creation_options,
)

The application throughs an error from time to time since a few days. We 
couldn't figure out a pattern yet and therefore we are also not able to 
reproduce the error. The error is the following:

Mon Nov 15 13:48:13 2021: CPLError: GDALWMS: Unable to download block 2765, 602.
URL: TCP connection reset by peer
  HTTP status code: 0, error: TCP connection reset by peer.
Add the HTTP status code to  to ignore this error (see 
http://www.gdal.org/frmt_wms.html).
Mon Nov 15 13:48:13 2021: CPLError: /wms_xml/wms_config.xml, band 1: IReadBlock 
failed at X offset 2764, Y offset 601
Mon Nov 15 13:48:13 2021: CPLError: GetBlockRef failed at X block offset 2764, 
Y block offset 601

The exact same data gets processed successfully in one run and not successfully 
in another run. We didn't change the code nor the Python or GDAL version. 
Hence, we are kind of puzzled as the error comes and goes seemingly at random.

Does anyone of you have any hints?

Thanks & best regards!
Roman

___

Dipl.-Ing. Roman Breitfuss-Schiffer, MSc. (GIS)

--

___

Dipl.-Ing. Roman Breitfuss-Schiffer, MSc. (GIS)

Veronikagasse 38/20, 1170 Wien

+43 664 5547678
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

2021-11-18 Thread Rahkonen Jukka (MML)

Hi,

I have no experience on 32 bit images but play with gdaladdo and compression 
options and report what you find. External overviews (-ro) are handy for 
testing because you can simply rename or delete the .ovr file and make new run 
with other options. External overviews take some more space than it takes to 
add internal overviews into TIFF but best option as external should be best as 
internal too.

-Jukka Rahkonen-

Lähettäjä: Duarte Carreira 
Lähetetty: torstai 18. marraskuuta 2021 18.30
Vastaanottaja: Rahkonen Jukka (MML) 
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with 
LERC_DEFLATE

Well, it didn't even occur to me to compress the overviews with translate...
I was expecting a bit more compressing from lerc...

About tif 32bit, what compression do you think would yield better ratios?

Thanks.

Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 escreveu no dia quinta, 18/11/2021 à(s) 12:41:
Hi,

I made some tests with an 8 bit RGB image.
First observation was that gdaladdo supports lerc_deflate (even it is not 
documented), but it does not support “MAX_Z_ERROR”. This yields same sized ovr 
file with or without max_z_error.
gdaladdo -ro lerc_def2.tif --config compress_overview lerc_deflate --config 
MAX_Z_ERROR 10

Another observation was that this option would really save some disk space. I 
compressed the lossless ovr file with gdal_translate by using -co 
max_z_error=10 and file sizes were:

source tiff: 432 072 372 bytes
lecr_deflate cog without overviews: 311 258 085 bytes

lossless lerc_deflate overviews: 118 954 009 bytes
lerc_deflare overviews with z_error=10: 52 400 583 bytes

For comparison even not relevant to original question about 32 bit data
jpeg-ycbcr overviews with default quality: 14 481 967 bytes

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Duarte Carreira
Lähetetty: torstai 18. marraskuuta 2021 13.45
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

Hi there.

I am looking into compressing overviews for a DEM, with LERC_DEFLATE and it 
works. But I'm trying to set the precision loss and get better compression, 
since for overviews I don't really care that much.
Ok, so the question is how to set the MAX_Z_ERROR for overviews compressed with 
LERC_DEFLATE?

More context:
My reasoning is to compress losslessly the dem with deflate predictor 3, and 
then compress "lossly"  the overviews with lerc_deflate.
Since this is 32bit dataset, I can't use jpeg on the overviews.

Thanks in advance.
Duarte

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr, perform queries to obtain values from the database

2021-11-18 Thread Rahkonen Jukka (MML)

Hi,

I would suggest to consider other options first.


  *   Use OGR foreign data wrapper https://github.com/pramsey/pgsql-ogr-fdw and 
make the shapefile to appear as a PostGIS table. The you can make the JOIN in 
your PostGIS.
  *   Add both the shapefile and the classification table from PostgreSQL into 
GeoPackage or SpatiaLite database as separate tables and update the coded 
values into definition string with SQL locally.


If you really want to join shapefile and PostgreSQL tables directly with GDAL 
and ogr2ogr I believe the only way is to write a vector VRT file 
https://gdal.org/drivers/vector/vrt.html#vector-vrt  that makes those two to 
appear as two layers in one datasource. The result is actually logically rather 
similar than by using foreign data wrappers on the PostgreSQL side.

If I would need to do the task just once I would take the GeoPackage road but I 
have done that before and my view is therefore certainly biased.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Andrés Nadal
Lähetetty: torstai 18. marraskuuta 2021 16.50
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] ogr2ogr, perform queries to obtain values from the database

Hello.

Excuse me my English, it's not my native language.

I need to convert the names (string) of classes, in some fields of a Shapefile, 
to the respective numerical values of the database.

In some cases, the fields have up to 3 different classes, for different rows.

CLASS A = 1
CLASS B = 2
CLASS B = 3

The destination table, this already exists, and contains many other fields, 
this using ogr2ogr.exe, from Windows CMD.

How to indicate to ogr2ogr.exe, which performs a query first, to obtain the 
numerical value of the ' CLASS B', from PostGIS.

In this way insert the value 2 in the table.

Thank you
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

2021-11-18 Thread Rahkonen Jukka (MML)

Hi,

I made some tests with an 8 bit RGB image.
First observation was that gdaladdo supports lerc_deflate (even it is not 
documented), but it does not support “MAX_Z_ERROR”. This yields same sized ovr 
file with or without max_z_error.
gdaladdo -ro lerc_def2.tif --config compress_overview lerc_deflate --config 
MAX_Z_ERROR 10

Another observation was that this option would really save some disk space. I 
compressed the lossless ovr file with gdal_translate by using -co 
max_z_error=10 and file sizes were:

source tiff: 432 072 372 bytes
lecr_deflate cog without overviews: 311 258 085 bytes

lossless lerc_deflate overviews: 118 954 009 bytes
lerc_deflare overviews with z_error=10: 52 400 583 bytes

For comparison even not relevant to original question about 32 bit data
jpeg-ycbcr overviews with default quality: 14 481 967 bytes

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Duarte Carreira
Lähetetty: torstai 18. marraskuuta 2021 13.45
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] setting MAX_Z_ERROR on overviews compressed with LERC_DEFLATE

Hi there.

I am looking into compressing overviews for a DEM, with LERC_DEFLATE and it 
works. But I'm trying to set the precision loss and get better compression, 
since for overviews I don't really care that much.
Ok, so the question is how to set the MAX_Z_ERROR for overviews compressed with 
LERC_DEFLATE?

More context:
My reasoning is to compress losslessly the dem with deflate predictor 3, and 
then compress "lossly"  the overviews with lerc_deflate.
Since this is 32bit dataset, I can't use jpeg on the overviews.

Thanks in advance.
Duarte

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDALWMS - error: TCP connection reset by peer

2021-11-18 Thread Rahkonen Jukka (MML)

Hi,

It seems that the WMS server is closing the door and there is nothing else to 
do on the GDAL side except to try again later. Contact the WMS service 
maintainer and report your troubles. They may be able to provide you a more 
reliable service especially if you are ready to pay for it.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Roman 
Breitfuss-Schiffer
Lähetetty: torstai 18. marraskuuta 2021 11.59
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] GDALWMS - error: TCP connection reset by peer


Dear all!

We are running a Python application an a linux distribution (RedHat) which 
creates clips in MBTILES format from a WMS. We are using the Python-API and are 
basically doing something like this:

src_ds = gdal.Warp(
tmp_file,
ds_in,
format='GTiff',
outputBounds=[bbox[0], bbox[2], bbox[1], bbox[3]],
dstSRS=output_srs,
)
ds_out = gdal.Translate(
out_filepath,
src_ds,
format='MBTILES',
creationOptions=creation_options,
)

The application throughs an error from time to time since a few days. We 
couldn't figure out a pattern yet and therefore we are also not able to 
reproduce the error. The error is the following:

Mon Nov 15 13:48:13 2021: CPLError: GDALWMS: Unable to download block 2765, 602.
URL: TCP connection reset by peer
  HTTP status code: 0, error: TCP connection reset by peer.
Add the HTTP status code to  to ignore this error (see 
http://www.gdal.org/frmt_wms.html).
Mon Nov 15 13:48:13 2021: CPLError: /wms_xml/wms_config.xml, band 1: IReadBlock 
failed at X offset 2764, Y offset 601
Mon Nov 15 13:48:13 2021: CPLError: GetBlockRef failed at X block offset 2764, 
Y block offset 601

The exact same data gets processed successfully in one run and not successfully 
in another run. We didn't change the code nor the Python or GDAL version. 
Hence, we are kind of puzzled as the error comes and goes seemingly at random.

Does anyone of you have any hints?

Thanks & best regards!
Roman

___

Dipl.-Ing. Roman Breitfuss-Schiffer, MSc. (GIS)
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal2tiles EPSG:3857 Out of Memory

2021-11-15 Thread Rahkonen Jukka (MML)

Hi,

GDAL version 2.4.0 is not supported any more. I had a try with 3857.pdf with 
GDAL 3.1.7 and Python 3.7 by running
gdal2tiles -r average -z 12-18 3857.pdf

Process took 15 seconds with my Windows laptop. I guessed you meant -r average 
because -t antialias does not exist to my knowledge.

-Jukka Rahkonen-


Lähettäjä: gdal-dev  Puolesta 
pepijn.sze...@tractebel.engie.com
Lähetetty: maanantai 15. marraskuuta 2021 10.44
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] gdal2tiles EPSG:3857 Out of Memory

Dear all,

I assume this belongs to this mailing list instead of the GitHub Issues.
Find attached 2 pdf (plots from QGIS) of the same area, but plotted in 
EPSG:3857 and EPSG: 31370. (if attachments are not allowed: there is nothing 
special about what is on the pdf: it's simply 1 styled vector line and 1 
labelled vector point).
The pdf were checked with gdalinfo. Except for the CRS, I don't notice anything 
peculiar.

Notice this is still gdal 2.4.0. Due to company restrictions gdal 3 tiling runs 
awfully slow. Maybe the problem is however known to any of you.

Windows 10, python 2.7

Task:

  *   Running gdal2tiles on the pdf, with parameters:
 *   -r antialias
 *   -z 12-18
 *   -processes=30

Problem:

  *   EPSG 31370 runs fine, but due to reprojection labels are slightly rotated
  *   EPSG 3857 plot would fix the above, but for some reason gdal2tiles will 
not run on this. It barely starts. After waiting long enough error codes start 
showing in the CMD. The errors contain easily hundreds of line.
See below a small excerpt:

Out of memory
Out of memory
0Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
ERROR 2: Cannot allocate result buffer
ERROR 2: memdataset.cpp, 1541: cannot allocate 1x1048576 bytes
Out of memory
Out of memory
Out of memory
ERROR 1: Bitmap decoded size (1x1) doesn't match raster size (1024x1024)
ERROR 1: 
C:\Users\MyUser\AppData\Local\Temp\tmpj7_ghurm\e4a8f99b-98d8-4425-b6d1-6540ff951385.vrt,
 band 2: IReadBlock failed at X offset 5, Y offset 2: Bitmap decoded size (1x1) 
doesn't match raster size (1024x1024)
.Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
ERROR 1: 
C:\Users\MyUser\AppData\Local\Temp\tmpj7_ghurm\e4a8f99b-98d8-4425-b6d1-6540ff951385.vrt,
 band 1: IReadBlock failed at X offset 1, Y offset 4
10Out of memory
Out of memory
Out of memory
Out of memory
Out of memory
Out of memory



Any pointers?
Met vriendelijke groeten,
Pepijn SZEKÉR
Engineer - Transport Infrastructure
pepijn.sze...@tractebel.engie.com
M +32 499 61 25 58

[cid:image001.png@01D7DA16.53955430]



tractebel-engie.com

TRACTEBEL ENGINEERING S.A.
Ilgatlaan 23
3500 Hasselt - BELGIUM

VAT BE 0412 639 681 RPR/RPM Brussels
Please consider the environment before printing this document.

[cid:image003.png@01D7DA16.53955430]
  [cid:image004.png@01D7DA16.53955430]    
[cid:image005.png@01D7DA16.53955430] 
   
[cid:image006.png@01D7DA16.53955430] 



TRACTEBEL Privacy Statement: https://tractebel-engie.com/en/data-privacy

ENGIE Mail Disclaimer: http://www.engie.com/disclaimer/
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Raster supported raster conversions

2021-11-12 Thread Rahkonen Jukka (MML)

Hi,

Having one of these in driver capabilities is enough:

Supports: Create() - Create writable dataset.
  Supports: CreateCopy() - Create dataset by copying another.

There may be some special cases like WMS driver that according to that table 
supports Copy but obviously you cannot convert GeoTIFF into WMS service with 
GDAL but that must mean something else.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Lorenzo Di 
Giacomo
Lähetetty: perjantai 12. marraskuuta 2021 18.14
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Raster supported raster conversions

Hi i have a question about format conversion:
How is it possibile to know the possible conversions between formats (using 
gdal_translate)?
I found https://gdal.org/drivers/raster/index.html, so i guess is possible to 
convert from format X to format Y iff the GDAL driver of format Y has the 
"Creation" field to "yes" ?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Gdal2tiles, Python 3.9 and multiprocessing

2021-11-09 Thread Rahkonen Jukka (MML)

Hi,

Have a look at this gis.stackexchange question 
https://gis.stackexchange.com/questions/415925/error-in-gdal2tiles-with-processes.
Question is about using gdal2tiles with QGIS but the issue is reproduced also 
with OSGeo4w. Is there something changed in multiprocessing between Python 
versions 3.7 and 3.9, or is something else failing with errors:

RuntimeError:
An attempt has been made to start a new process before the
current process has finished its bootstrapping phase.

This probably means that you are not using fork to start your
child processes and you have forgotten to use the proper idiom
in the main module:

if __name__ == '__main__':
freeze_support()
...

The "freeze_support()" line can be omitted if the program
is not going to be frozen to produce an executable.
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\multiprocessing\spawn.py", 
line 116, in spawn_main
exitcode = _main(fd, parent_sentinel)
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\multiprocessing\spawn.py", 
line 125, in _main
prepare(preparation_data)
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\multiprocessing\spawn.py", 
line 236, in prepare
_fixup_main_from_path(data['init_main_from_path'])
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\multiprocessing\spawn.py", 
line 287, in _fixup_main_from_path
main_content = runpy.run_path(main_path,
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\runpy.py", line 268, in 
run_path
return _run_module_code(code, init_globals, run_name,
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\runpy.py", line 97, in 
_run_module_code
_run_code(code, mod_globals, init_globals,
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\runpy.py", line 87, in 
_run_code
exec(code, run_globals)
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\Scripts\gdal2tiles.py", line 11, 
in 
sys.exit(main(sys.argv))
  File 
"C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\site-packages\osgeo_utils\gdal2tiles.py",
 line 3257, in main
multi_threaded_tiling(input_file, output_folder, options)
  File 
"C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\site-packages\osgeo_utils\gdal2tiles.py",
 line 3206, in multi_threaded_tiling
pool = Pool(processes=nb_processes)
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\multiprocessing\context.py", 
line 119, in Pool
return Pool(processes, initializer, initargs, maxtasksperchild,
  File "C:\PROGRA~1\QGIS32~1.0\apps\Python39\lib\multiprocessing\pool.py", line 
212, in __init__
self._repopulate_pool()

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Strange behavior opening CSVs

2021-11-08 Thread Rahkonen Jukka (MML)

Hi,

The trial with gdalinfo makes GDAL to try XYZ
https://gdal.org/drivers/raster/xyz.html?highlight=xyz. It is not a bad guess
at all. Ogrinfo tries CSV and finds the x, y, and val fields. I can’t say
anything about the second part.

-Jukka Rahkonen-

Lähettäjä: gdal-dev Puolesta Simon Eves
Lähetetty: tiistai 9. marraskuuta 2021 2.21
Vastaanottaja: gdal dev
Aihe: [gdal-dev] Strange behavior opening CSVs

I am currently implementing a better file identifier, and during the course of
development, I unintentionally let GDAL try to GDALOpenEx() the attached
trivial CSV file.

First, it reported "Ungridded dataset: At line 3, change of Y direction" (as a
warning to the registered error-handler) and the returned OGRDataSource* was
null.

When I tried again, it then claimed that I was trying to open the same file
recursively. implying that it had, in fact, opened it, even though it never
returned a valid handle, so I wouldn't have been able to close it again even if
I'd wanted to.

I can reproduce the first part with gdalinfo.

This is with GDAL 3.2.2 on Ubuntu 20.04 with GCC 9.

I'll poke at the GDAL code myself when I have a bit more time.

--
[http://www2.omnisci.com/l/298412/2018-09-18/3sqpg/298412/61753/OmniSci_Email_Header2.png]

Simon Eves

Senior Graphics Engineer, Rendering Group
100 Montgomery St (5th Floor), San Francisco, CA 94104, USA

Email: simon.e...@omnisci.com | Cell:

+1 (415) 902-1996

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

2021-11-05 Thread Rahkonen Jukka (MML)

Hi,

I think it is not bad luck but something weird in GDAL 3.3. I tried again with 
version 3.3.1 from OSGeo4W and just like you I got also less pixels into output:

gdalwarp -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" caribbean_4326_2.tif
Copying color table from Caribbean 2 VFR Chart.tif to new file.
Creating output file that is 18714P x 10830L.

But this warped image is not at all the same than the one produced with GDAL 
3.4. The image lacks all the legends etc. but not only those. I wonder is the 
TIFF file has been written in some special way on several pages or something.


-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Carl Godkin
Lähetetty: perjantai 5. marraskuuta 2021 17.36
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] GeoTIFF gdalwarp puzzle

...And it works fine for me in 3.4.0 as well.  Guess I just got unlucky with 
the GDAL 3.3.x series!

Thanks,
carl

On Fri, Nov 5, 2021 at 8:09 AM Carl Godkin 
mailto:cgod...@gmail.com>> wrote:
Partially answering myself:

I just tried again with GDAL 2.4.4 (2020/01/08) that I have on my system as 
part of MS4W and it works!

I have a way forward now.  I'm still going to build GDAL 3.4.0 and try it there.

Thanks a lot,

carl

On Fri, Nov 5, 2021 at 8:02 AM Carl Godkin 
mailto:cgod...@gmail.com>> wrote:
Thanks for checking, Jukka.

I am using GDAL 3.3.3 and get a smaller range:

d:\gdal-3.3.3\bin64\gdalwarp.exe  -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" 
caribbean_4326.tif
Copying color table from Caribbean 2 VFR Chart.tif to new file.
Creating output file that is 18714P x 10830L.
Processing Caribbean 2 VFR Chart.tif [1/1] : 
0...10...20...30...40...50...60...70...80...90...100 - done.

Is there a bug fix between 3.3.3 and 3.4.0 that could account for this?

Meanwhile, I'll try to get GDAL 3.4.0 going here.  Thanks,

carl

On Fri, Nov 5, 2021 at 7:51 AM Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

Works for me on Windows with GDAL 3.4.0dev and Oct 07 2021 version of the file.

gdalwarp -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" caribbean_4326.tif
Copying color table from Caribbean 2 VFR Chart.tif to new file.
Creating output file that is 18583P x 12118L.
Processing Caribbean 2 VFR Chart.tif [1/1] : 
0...10...20...30...40...50...60...70...80...90...100 - done.

The map in caribbean_4326.tif is complete.

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Carl Godkin
Lähetetty: perjantai 5. marraskuuta 2021 16.25
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] GeoTIFF gdalwarp puzzle

Hi,

I'm working with some aviation charts and found one that behaves in a puzzling 
manner.
This page 
https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
has two Caribbean VFR charts in GeoTIFF format.

I have been trying to run gdalwarp on "Caribbean 2 VFR Chart.tif" but I only 
ever get a small area out of the map instead of the whole extent.  Specifically 
this command gives me just a smaller area output GeoTIFF:

gdalwarp -t_srs EPSG:4326 "Caribbean 2 VFR Chart.tif" out.tif --debug ON

I don't see anything from the debug output that explains this.

The other chart, "Caribbean 1 VFR Chart.tif," does not behave this way, though 
the debug output from the same gdalwarp operation is much longer.

I can't see anything wrong.

I dragged both files into ArcGIS desktop explorer and both are displayed in the 
proper location and in their entirety.

(I actually have a more elaborate workflow that works fine with chart #1 but 
this is the simplest operation I can think of that shows the problem with chart 
#2.)

Thank you very much,
carl


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GeoTIFF gdalwarp puzzle

2021-11-05 Thread Rahkonen Jukka (MML)

Hi,

Works for me on Windows with GDAL 3.4.0dev and Oct 07 2021 version of the file.

gdalwarp -t_srs epsg:4326 "Caribbean 2 VFR Chart.tif" caribbean_4326.tif
Copying color table from Caribbean 2 VFR Chart.tif to new file.
Creating output file that is 18583P x 12118L.
Processing Caribbean 2 VFR Chart.tif [1/1] : 
0...10...20...30...40...50...60...70...80...90...100 - done.

The map in caribbean_4326.tif is complete.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Carl Godkin
Lähetetty: perjantai 5. marraskuuta 2021 16.25
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] GeoTIFF gdalwarp puzzle

Hi,

I'm working with some aviation charts and found one that behaves in a puzzling 
manner.
This page 
https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/vfr/
has two Caribbean VFR charts in GeoTIFF format.

I have been trying to run gdalwarp on "Caribbean 2 VFR Chart.tif" but I only 
ever get a small area out of the map instead of the whole extent.  Specifically 
this command gives me just a smaller area output GeoTIFF:

gdalwarp -t_srs EPSG:4326 "Caribbean 2 VFR Chart.tif" out.tif --debug ON

I don't see anything from the debug output that explains this.

The other chart, "Caribbean 1 VFR Chart.tif," does not behave this way, though 
the debug output from the same gdalwarp operation is much longer.

I can't see anything wrong.

I dragged both files into ArcGIS desktop explorer and both are displayed in the 
proper location and in their entirety.

(I actually have a more elaborate workflow that works fine with chart #1 but 
this is the simplest operation I can think of that shows the problem with chart 
#2.)

Thank you very much,
carl


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: promote GDAL 3.4.0RC3 as final issue

2021-11-04 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: torstai 4. marraskuuta 2021 14.33
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: promote GDAL 3.4.0RC3 as final issue

Hi,

RC3 should be the last iteration needed to allow 3.4.0 to be released.

Motion:

Adopt GDAL 3.4.0 RC3 as final 3.4.0 release

Starting with my +1

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] [EXTERNAL] Re: ogr2ogr does not convert OSM polygons

2021-11-02 Thread Rahkonen Jukka (MML)

Hi,

Please take care to send mail also to the list.

The error that you get means probably that the Proj coordinate transformation 
library finds an older version of the proj.db file. With the gisinternals 
installation that file is in [gdal_installation_directory]\bin\proj7\share. 
Environmental variable PROJ_LIB should point into there. How did you launch 
ogr2ogr after installation? If you installed from the zip file you must run 
first the batch file "sdkshell.bat" for setting the paths and environment 
variables. If you used installer then you should launch GDAL command window 
from the shortcuts. In both cases when settings are OK you can run ogr2ogr 
simply as "ogr2ogr".

Other_relations contain geometries which are of geometry type 
"GeometryCollection". Unfortunately QGIS has very little support for 
GeometryCollections. You can see the attributes but not the geometries. If you 
are interested in the relations you must use some workarounds with QGIS or use 
other programs. For example OpenJUMP can do pretty well with relations but it 
is not so well documented.

-Jukka Rahkonen-

Lähettäjä: Clay, Bruce 
Lähetetty: tiistai 2. marraskuuta 2021 20.35
Vastaanottaja: Rahkonen Jukka (MML) 
Aihe: Re: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons

Jukka:
  I upgraded to 3.4.0 from sysinternals.  All tables appear to be going in ok 
but I do get an error message for each table (shown below).  QGIS shows the 
SRID is 4326.  "other_relations" has a geometry column and it loads in QGIS but 
the geometry does not show.  It appears I can get what I need for my task, just 
annoying messages.

Should "other_relations" show in QGIS?

Thanks for you help.

Bruce

Z:\OpenStreetMap\release-1916-x64-gdal-mapserver\bin\ogr2ogr -f PostgreSQL 
PG:"dbname='open_street_map' host='hostname' port='5432' user='postgres' 
password='pwd'" -lco schema=algeria algeria-latest.osm.pbf  --config 
OSM_MAX_TMPFILE_SIZE 1024
0...10...20...30...40.ERROR 1: PROJ: proj_create_from_database: cannot build 
geodeticCRS 4326: SQLite error on SELECT extent.description, extent.south_lat, 
extent.north_lat, extent.west_lon, extent.east_lon, scope.scope, (CASE WHEN 
scope.scope LIKE '%large scale%' THEN 0 ELSE 1 END) AS score FROM usage JOIN 
extent ON usage.extent_auth_name = extent.auth_name AND usage.extent_code = 
extent.code JOIN scope ON usage.scope_auth_name = scope.auth_name AND 
usage.scope_code = scope.code WHERE object_table_name = ? AND object_auth_name 
= ? AND object_code = ? ORDER BY score, usage.auth_name, usage.code: no such 
table: usage
..50...60...70...80...90...100 - done.

From: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Sent: Tuesday, November 2, 2021 12:32 PM
To: Clay, Bruce mailto:bc...@infoscitex.com>>
Subject: VS: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons


Actually, it was GDAL 3.3.1 from OSGeo4W installer.



-Jukka-



Lähettäjä: Clay, Bruce mailto:bc...@infoscitex.com>>
Lähetetty: tiistai 2. marraskuuta 2021 18.19
Vastaanottaja: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Aihe: Re: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons



Jukka:

  Thanks for your reply.



I was in the progress of loading all OSM so I started with Africa and saw the 
same thing for all pbf files.  You can pick a small one such as 
algeria-latest.osm.pbf.  In my post I  just replaced the country name with the 
word "country" to be generic.  All of the files came from the website you 
mentioned.



I am using the OSGeo shell on Windows 10.  gdalinfo show version is 3.0.4

I did not change the osmconf.ini file.



After looking deeper into the table osm2pgsql created I noticed roads are not 
actually put in the osm roads layer.  administrative boundaries or other lines 
were in there. More lines are in the table created by osm2pgsql than the table 
created by ogr2ogr.



it looks like ogr2ogr would produce a similar approach if it would generate the 
polygon table.



Bruce







From: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Sent: Tuesday, November 2, 2021 11:11 AM
To: Clay, Bruce mailto:bc...@infoscitex.com>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> 
mailto:gdal-dev@lists.osgeo.org>>
Subject: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons



Hi,



What layers does "ogrinfo country_pbf" list? Can you reproduce the error with 
some small OSM country file from 
http://download.geofabrik.de/<https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fdownload.geofabrik.de%2F=04%7C01%7Cbclay%40infoscitex.com%7Cf969c27fe7114268415508d99e1e4f3c%7C3430c5de5e6f4f9d9d9690e985038b58%7C0%7C0%7C637714675287814046%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=dO7y8hY%2BQcMN4U9ZZLq

Re: [gdal-dev] [EXTERNAL] Re: ogr2ogr does not convert OSM polygons

2021-11-02 Thread Rahkonen Jukka (MML)

Hi,

I made a couple of quick tests with algeria-latest

ogrinfo algeria-latest.osm.pbf
INFO: Open of `algeria-latest.osm.pbf'
  using driver `OSM' successful.
1: points (Point)
2: lines (Line String)
3: multilinestrings (Multi Line String)
4: multipolygons (Multi Polygon)
5: other_relations (Geometry Collection)

ogr2ogr -f GPKG algeria.gpkg algeria-latest.osm.pbf
0...10...20...30...40...50...60...70...80...90...100 - done.

ogrinfo algeria.gpkg multipolygons -so
INFO: Open of `algeria.gpkg'
  using driver `GPKG' successful.

Layer name: multipolygons
Geometry: Multi Polygon
Feature Count: 725379

There are multipolygons in the data and ogr2ogr can convert them into 
"multipolygons" when the target is GeoPackage. Repeat the test. If you get the 
same result the issue must have a connection to PostGIS. If you get a different 
result then there is something else.  By GDAL is from gisinternals.com, version 
3.4.0dev.

-Jukka Rahkonen-

Lähettäjä: Clay, Bruce 
Lähetetty: tiistai 2. marraskuuta 2021 18.19
Vastaanottaja: Rahkonen Jukka (MML) 
Aihe: Re: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons

Jukka:
  Thanks for your reply.

I was in the progress of loading all OSM so I started with Africa and saw the 
same thing for all pbf files.  You can pick a small one such as 
algeria-latest.osm.pbf.  In my post I  just replaced the country name with the 
word "country" to be generic.  All of the files came from the website you 
mentioned.

I am using the OSGeo shell on Windows 10.  gdalinfo show version is 3.0.4
I did not change the osmconf.ini file.

After looking deeper into the table osm2pgsql created I noticed roads are not 
actually put in the osm roads layer.  administrative boundaries or other lines 
were in there. More lines are in the table created by osm2pgsql than the table 
created by ogr2ogr.

it looks like ogr2ogr would produce a similar approach if it would generate the 
polygon table.

Bruce


____
From: Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
Sent: Tuesday, November 2, 2021 11:11 AM
To: Clay, Bruce mailto:bc...@infoscitex.com>>; 
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org> 
mailto:gdal-dev@lists.osgeo.org>>
Subject: [EXTERNAL] Re: ogr2ogr does not convert OSM polygons


Hi,



What layers does "ogrinfo country_pbf" list? Can you reproduce the error with 
some small OSM country file from 
http://download.geofabrik.de/<https://usg02.safelinks.protection.office365.us/?url=http%3A%2F%2Fdownload.geofabrik.de%2F=04%7C01%7Cbclay%40infoscitex.com%7Cd3072cf4fd6944d85eba08d99e131143%7C3430c5de5e6f4f9d9d9690e985038b58%7C0%7C0%7C637714627010157244%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=W1Mn6rR62o9fuXMpTnvNafi5zTgtUG89%2F5XQMJNw2R0%3D=0>?

What is your operating system and GDAL version? Do you use the default 
osmconf.ini file? GDAL OSM driver and osm2pgsql are creating quite different 
database schemas so they are not very comparable.



-Jukka Rahkonen-



Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Clay, Bruce
Lähetetty: tiistai 2. marraskuuta 2021 16.22
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] ogr2ogr does not convert OSM polygons



When I convert a OSM pbf file to postgres using the following script it does 
not create a multipolygon table



ogr2ogr -f PostgreSQL PG:"dbname='open_street_map' host='db-host' port='5432' 
user='postgres' password='pwd'" -lco schema=country country_pbf  --config 
OSM_MAX_TMPFILE_SIZE 1024



When I do the same thing using osm2pgsql (shown below) it creates the polygon 
table but not the other_relations table



osm2pgsql -H hostname -U postgres -d open_street_map 
--output-pgsql-schema=country --create --latlong -G --hstore 
--tag-transform-script 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.lua -C 2500 
--number-processes 5 -S 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.style 
country-latest.osm.pbf.



I did not see this problem when I Googled.



Is this a known issue and is there a work around?



Bruce
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr does not convert OSM polygons

2021-11-02 Thread Rahkonen Jukka (MML)

Hi,

What layers does "ogrinfo country_pbf" list? Can you reproduce the error with 
some small OSM country file from http://download.geofabrik.de/?
What is your operating system and GDAL version? Do you use the default 
osmconf.ini file? GDAL OSM driver and osm2pgsql are creating quite different 
database schemas so they are not very comparable.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Clay, Bruce
Lähetetty: tiistai 2. marraskuuta 2021 16.22
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] ogr2ogr does not convert OSM polygons

When I convert a OSM pbf file to postgres using the following script it does 
not create a multipolygon table

ogr2ogr -f PostgreSQL PG:"dbname='open_street_map' host='db-host' port='5432' 
user='postgres' password='pwd'" -lco schema=country country_pbf  --config 
OSM_MAX_TMPFILE_SIZE 1024

When I do the same thing using osm2pgsql (shown below) it creates the polygon 
table but not the other_relations table

osm2pgsql -H hostname -U postgres -d open_street_map 
--output-pgsql-schema=country --create --latlong -G --hstore 
--tag-transform-script 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.lua -C 2500 
--number-processes 5 -S 
/OpenStreetMap/openstreetmap-carto-master/openstreetmap-carto.style 
country-latest.osm.pbf.

I did not see this problem when I Googled.

Is this a known issue and is there a work around?

Bruce
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Hi: Bug report gdal_translate

2021-11-02 Thread Rahkonen Jukka (MML)

Hi,

I believe that you have found a bug in the Surfer documentation. You can see
value 1.70141e+38, that is the maximum single precision float, used in for
example
https://support.goldensoftware.com/hc/en-us/articles/226806408-How-do-I-make-all-Z-values-above-or-below-a-certain-threshold-value-transparent-in-Surfer-?mobile_site=false

The GDAL AAIGRID driver does not seem to have a default value for nodata
https://gdal.org/drivers/raster/aaigrid.html. The driver copies the nodata from
the source dataset if it exists
https://github.com/OSGeo/gdal/blob/master/frmts/aaigrid/aaigriddataset.cpp#L1275.
There is some nodata handling in the code:
// Cast to float and back for make sure the NoData value matches
// that expressed by a float value. Clamps to the range of a float
// if the value is too large. Preserves +/-inf and NaN.

Maybe there should be a default nodata value, -
https://www.loc.gov/preservation/digital/formats/fdd/fdd000421.shtml
"Cells without actual values can be assigned a NoData value. The default value
for NoData is - but a different value can be specified in the header as
shown in example below."

I read the comment "NoData values appear as 1.71041e38" from
http://surferhelp.goldensoftware.com/topics/ascii_grid_file_format.htm so that
it is the value how nodata appears in Surfer. You can test it by creating some
ASCII grid files with different nodata values and opening them with Surfer.
Commands would look like this "gdal_translate -of AAIGRID -a_nodata -99".

There may be a bug in theAAIGRID driver if the nodata in your source data and
the nodata transferrer into ASCII grid files are different. Check the nodata
values with gdalinfo. If nodata remains the same there is no bug. If you have
1.71041E+38 as nodata in your source data, what it the format and bit depth of
the data?

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev Puolesta Dr. Felix
Tritschler
Lähetetty: tiistai 2. marraskuuta 2021 8.32
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Bug report gdal_translate

Hello,

I stumbled across what appears to me as an typo in the gdal_translate function
implemented in QGIS 3.18.2.
I performed a translation from a geotiff to a surfer (non-binary) .grd file
without a specification of a NODATA-Value.

In the resulting .grd-file the NODATA value was 1.70141E+38.
But according to
http://surferhelp.goldensoftware.com/topics/ascii_grid_file_format.htm
the correct NODATA value for this filetype has to be 1.71041E+38.

I don't feel skilled enough to fix this bug on my own (even don't know if I
could do this =o), so please feel free to check and fix if necessary.

Cheers
Felix

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: promote GDAL 3.3.3 RC1

2021-10-27 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: keskiviikko 27. lokakuuta 2021 14.43
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: promote GDAL 3.3.3 RC1

Hi,

Having heard no issues being reported regarding RC1

Motion:

Adopt GDAL 3.3.3 RC1 as final 3.3.3 release

Starting with my +1

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Python error in me or in gisinternals.com packages?

2021-10-26 Thread Rahkonen Jukka (MML)

Hi,

I can use GDAL Python bindings from OSGeo4W installation but folks in 
gis.stackexchange have problems with the gistinternals.com binaries so I had a 
try too. I installed

  *   python-3.7.9-amd64
  *   gdal-303-1928-x64-core MIS installer from gisinternals
  *   GDAL-3.3.2.win-amd64-py3.7 MSI installer from gisinternals

Now I have all from above and I have adjusted paths a bit and I can get this 
far:

  *   Python 3.7.9 starts
  *   I can load osr with "from osgeo import osr"
But if I try "from osgeo import ogr" I get:

Traceback (most recent call last):
  File "", line 1, in 
  File "c:/Program Files\Python37\lib\site-packages\osgeo\ogr.py", line 245, in 

import osr
ModuleNotFoundError: No module named 'osr'

Same thing with "from osgeo import gdal" but this time the error in on line 
1931 in gdal.py and missing module is 'ogr'.

Do the errors mean that the Python stuff is using deprecated "import osr" and 
"import ogr" while they should have it as "import osgeo.osr" and "import 
osgeo.ogr" as they seem to stand in the working OSGeo4W installation? I do not 
have rights to edit the files, and they have also this warning in the beginning:
# This file was automatically generated by SWIG (http://www.swig.org).
# Version 4.0.2
#
# Do not make changes to this file unless you know what you are doing--modify
# the SWIG interface file instead.

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] WCS: Unable to export GeoTIFF files with zero bands

2021-10-25 Thread Rahkonen Jukka (MML)

Hi,

I do not understand what could be wrong with this WCS. With direct WCS 2.0.1 
requests everything works fine.

GetCapabilities:
https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS=2.0.1=GetCapabilities
DescribeCoverage:
https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS=2.0.1=DescribeCoverage=ortokuva__ortokuva
This is listing DataRecord with three fields: red band, green band, and blue 
band.
GetCoverage:
https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?service=WCS=2.0.1=GetCoverage=ortokuva__ortokuva=E(393450,393650)=N(7495450,7495650)=image/tiff
This sends a tiff file.


With GDAL:
gdalinfo -oo CLEAR_CACHE 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?;
I get the subdatasets.

gdalinfo 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=ortokuva__ortokuva;
Looks good but I am not sure what I should expect to see.

gdal_translate -projwin 393450 7495650 393650 7495450   
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=ortokuva__ortokuva;
 wcs.tif
This gives an error:
Input file size is 1348357, 2316500
ERROR 1: wcs.tif: Unable to export GeoTIFF files with zero bands.

I can indeed see at the end of the automatically generated XML file that the 
band count is interpreted to be zero:
...
E,N
  61254.6580619824,6623749.72946716
  735433.573091962,7782000.0
  i,j
  ,,
  0
  image/tiff
...
I tried to edit the band count into 3 by hand, but GDAL is changing it back to 
zero.

The example from the WCS driver page https://gdal.org/drivers/raster/wcs.html 
that  is using the very same server and coverage does save an image even there 
is no fundamental difference in the command.
gdal_translate -oo CACHE=wcs_cache -oo CLEAR_CACHE -oo INTERLEAVE=PIXEL 
-projwin 377418 6683393.87938218 377717.879386966 6683094  -oo 
Subset="time(1985-01-01T00:00:00.000Z)" -outsize 60 0 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=ortokuva__ortokuva;
 scaled.tiff

I am using GDAL version is 3.4.0dev from yesterday.

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdallocationinfo + WCS question...

2021-10-25 Thread Rahkonen Jukka (MML)

Hi,

Thanks for testing and sending the results back for the community.

-Jukka Rahkonen-

Lähettäjä: gdal-dev Puolesta Carl Godkin
Lähetetty: maanantai 25. lokakuuta 2021 18.37
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] gdallocationinfo + WCS question...

Hi,

I just built GDAL 3.3.3 RC1 here on Windows with VS2019 and PROJ 8.1.1 and it
built easily.

I retried the gdallocationinfo queries that I was having trouble with
beforehand (with 3.3.1) and both the USGS National Map and my local WCS server
queries now return the expected values. I know others had tested the fix Even
mentioned but I wanted to try it myself.

Thanks again for the explanation and the fix,
carl

On Thu, Oct 21, 2021 at 2:00 PM Carl Godkin
mailto:cgod...@gmail.com>> wrote:
Thanks, Even.

That makes sense. (Finally!) I can wait a little bit to come back to this so
I'll either build 3.3 HEAD on my own or await the next release.

It's great that this isn't a random server load thing or something!

The weird result on my own WCS server also seemed to be caused by a bad "xmin"
value which is how I started down this road.

Thanks again,

carl

On Thu, Oct 21, 2021 at 1:49 PM Even Rouault
mailto:even.roua...@spatialys.com>> wrote:

Le 21/10/2021 à 22:32, Rahkonen Jukka (MML) a écrit :
Hi Even,

You are right, re-running the request -oo clear_cache gives me the same error
about 3 bands. Obviously our server was configured right when I used it with
GDAL last time. Now gdallocationinfo does not work even for me because I wiped
the working configuration from my cache. We will fix the service metadata when
we go from beta to official soon.

The nationalmap.gov<http://nationalmap.gov> service does not still work for me.
I cleared the cache but I still get a 404 error from the server. Subsets in the
reques are these
SUBSET=x(-20037507.067213,-13590403.131594259)=y(5303978.1067894027,5304490.1067842878)

The xmin value in the request you get is obviously wrong. The subset I get with
GDAL master and head of 3.3 branch is:

SUBSET=x%(-13591427.131584032,-13590403.131594259)=y(5303978.1067894027,5304490.1067842878)

I suspect you might use a GDAL release version, that hasn't yet received the
following recent fix that is likely related to that issue and will be in 3.3.3
and 3.4.0:

https://github.com/OSGeo/gdal/commit/8af67b64371c275a3770e75da1bd0d4bb7329295

(I get the same error as you with the 3.2 branch, so I strongly suspect the
above is indeed the fix for that)

Even

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdallocationinfo + WCS question...

2021-10-21 Thread Rahkonen Jukka (MML)

Hi Even,

You are right, re-running the request -oo clear_cache gives me the same error 
about 3 bands. Obviously our server was configured right when I used it with 
GDAL last time. Now gdallocationinfo does not work even for me because I wiped 
the working configuration from my cache. We will fix the service metadata when 
we go from beta to official soon.

The nationalmap.gov service does not still work for me. I cleared the cache but 
I still get a 404 error from the server. Subsets in the reques are these
SUBSET=x(-20037507.067213,-13590403.131594259)=y(5303978.1067894027,5304490.1067842878)
and gdallocationinfo error is this:

Report:
  Location: (6446955P,13504941L)
  Band 1:
ERROR 1: HTTP error code : 404
ERROR 1: Failed to get coverage data:
ERROR 1: C:\Users\JRAHKONEN\.gdal\wcs_cache\QpYSX.xml, band 1: IReadBlock 
failed at X offset 6295, Y offset 26376: Failed to get coverage data:

-Jukka-

Lähettäjä: Even Rouault 
Lähetetty: torstai 21. lokakuuta 2021 22.50
Vastaanottaja: Rahkonen Jukka (MML) ; Carl 
Godkin ; gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] gdallocationinfo + WCS question...


Jukka,

I don't understand how you get a non-error on the below request on your WCS 
service:

https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?SERVICE=WCS=DescribeCoverage=2.0.1=korkeusmalli__korkeusmalli=text/xml
 advertizes 3 bands

but the GeoTIFF returned by

https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?SERVICE=WCS=GetCoverage=2.0.1=korkeusmalli__korkeusmalli=E%28498656,500704%29=N%287542384,7543408%29=image/tiff

has just one band.

Or maybe you have in your ~/gdal/wcs_cache a previous version of the 
DescribeCoverage response that advertizes just one band ?



And for what is worth,

gdallocationinfo 
"WCS:https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?version=2.0.1=DEP3Elevation;
 -wgs84 -122.086 42.948 --debug ON

returns 1882.00549316406 for me

The multipart answer doesn't seem to be an issue.


Le 21/10/2021 à 20:16, Rahkonen Jukka (MML) a écrit :
Hi,

At least it seems to work with our WCS service

gdallocationinfo 
WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=korkeusmalli__korkeusmalli
 -wgs84 27 68
Report:
  Location: (228000P,119567L)
  Band 1:
Value: 303.463989257812

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
<mailto:gdal-dev-boun...@lists.osgeo.org> 
Puolesta Carl Godkin
Lähetetty: torstai 21. lokakuuta 2021 18.47
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] gdallocationinfo + WCS question...

Hi,

I am trying to use gdallocationinfo to query point locations from a WCS server 
and not having any luck. I don't see anything in the docs that says this is 
unsupported but I can't make it work.

First of all, is there a better way to get an elevation from a given lat,lon 
using WCS?

Here's an example query using the USGS National Map server:

gdallocationinfo 
"WCS:https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?version=2.0.1=DEP3Elevation;
 -wgs84 -122.086 42.948 --debug ON

This is a point in the middle of Crater Lake which I picked since it's flat and 
I know what to expect.

Anyway, looking at the debug output it appears that the program is querying for 
a GeoTIFF of a VERY large area and that's failing.

I actually want to do this with my own WCS server but thought it might be 
mis-configured somehow so I tried the USGS server.  With my own server, 
gdallocationinfo seems to be requesting a strange shape from the server (as I 
can see through the debug output).

Thanks for any help,

carl




___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdallocationinfo + WCS question...

2021-10-21 Thread Rahkonen Jukka (MML)

Hi,
Try to run first
gdalinfo 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1;

and repeat the test then. If it works Ari may be able to tell why.

-Jukka-


Ari may be able to explain

Lähettäjä: Carl Godkin 
Lähetetty: torstai 21. lokakuuta 2021 22.25
Vastaanottaja: Rahkonen Jukka (MML) ; 
gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] gdallocationinfo + WCS question...

Hi Jukka,

Strangely, the command you pasted doesn't work for me, at with GDAL 3.3.1 on 
Windows (with quotes added appropriately):

gdallocationinfo 
"WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=korkeusmalli__korkeusmalli;
 -wgs84 27 68
ERROR 1: PROJ: proj_uom_get_info_from_database: unit of measure not found
Report:
  Location: (228000P,119567L)
  Band 1:
ERROR 1: Returned tile does not match expected band configuration.
Response has 1 bands while this dataset has 3 bands.

ERROR 1: C:\Users\carl\.gdal\wcs_cache\nhXWS.xml, band 1: IReadBlock failed at 
X offset 222, Y offset 233: Returned tile does not match expected band 
configuration.
Response has 1 bands while this dataset has 3 bands.

  Band 2:
ERROR 1: Returned tile does not match expected band configuration.
Response has 1 bands while this dataset has 3 bands.

ERROR 1: C:\Users\carl\.gdal\wcs_cache\nhXWS.xml, band 2: IReadBlock failed at 
X offset 222, Y offset 233: Returned tile does not match expected band 
configuration.
Response has 1 bands while this dataset has 3 bands.

  Band 3:
ERROR 1: Returned tile does not match expected band configuration.
Response has 1 bands while this dataset has 3 bands.

ERROR 1: C:\Users\carl\.gdal\wcs_cache\nhXWS.xml, band 3: IReadBlock failed at 
X offset 222, Y offset 233: Returned tile does not match expected band 
configuration.
Response has 1 bands while this dataset has 3 bands.

I find that somewhat reassuring since I get a similar error when querying my 
own WCS server (that you helped me set up over the past couple of days):

gdallocationinfo 
"WCS:http://localhost:8080/wcs?service=WCS=2.0.1=SRTM_3_arc-second_grid;
 -wgs84 -122.086 42.948
Report:
  Location: (3498P,8465L)
  Band 1:
ERROR 1: Returned tile does not match expected configuration.
Got 4094x512 instead of 1024x512.
ERROR 1: C:\Users\carl\.gdal\wcs_cache\hcoMu.xml, band 1: IReadBlock failed at 
X offset 3, Y offset 16: Returned tile does not match expected configuration.
Got 4094x512 instead of 1024x512.

Or, with --debug ON:

gdallocationinfo 
"WCS:http://localhost:8080/wcs?service=WCS=2.0.1=SRTM_3_arc-second_grid;
 -wgs84 -122.086 42.948 --debug ON
GDAL: 
GDALOpen(WCS:http://localhost:8080/wcs?service=WCS=2.0.1=SRTM_3_arc-second_grid,
 this=0228A4B2B970) succeeds as WCS.
Report:
  Location: (3498P,8465L)
  Band 1:
GDAL: GDAL_CACHEMAX = 6535 MB
WCS: Requesting 
http://localhost:8080/wcs?service=WCS=GetCoverage=2.0.1=SRTM_3_arc-second_grid=long%28-125,-121.5880315%29=lat%2842.74956749998,43.17606349998%29=image/tiff
HTTP: 
Fetch(http://localhost:8080/wcs?service=WCS=GetCoverage=2.0.1=SRTM_3_arc-second_grid=long%28-125,-121.5880315%29=lat%2842.74956749998,43.17606349998%29=image/tiff)
HTTP: libcurl/7.78.0 Schannel zlib/1.2.11 libssh2/1.9.0
HTTP: GDAL was built against curl 7.77.0, but is running against 7.78.0.
WCS: GDALOpenResult() on content-type: image/tiff
GDAL: GDALOpen(/vsimem/wcs/0228A4B2B970/wcsresult.dat, 
this=0228A4CEEC40) succeeds as GTiff.
ERROR 1: Returned tile does not match expected configuration.
Got 4094x512 instead of 1024x512.
GDAL: GDALClose(/vsimem/wcs/0228A4B2B970/wcsresult.dat, 
this=0228A4CEEC40)
ERROR 1: C:\Users\carl\.gdal\wcs_cache\hcoMu.xml, band 1: IReadBlock failed at 
X offset 3, Y offset 16: Returned tile does not match expected configuration.
Got 4094x512 instead of 1024x512.
GDAL: GDALClose(C:\Users\carl\.gdal\wcs_cache\hcoMu.xml, this=0228A4B2B970)

Any suggestions?  If I break the above debug output down and use "curl" to 
download the GeoTIFF and then use gdallocationinfo on the downloaded file, I 
get a reasonable result.
I guess I could do that.  But what I find very strange is that gdallocationinfo 
seems to request a rather odd-shaped patch (-125 to -121.5 in longitude, but 
only 42.75 to 43.18 in latitude) which cases trouble.

Thanks a lot,

carl




On Thu, Oct 21, 2021 at 11:16 AM Rahkonen Jukka (MML) 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

At least it seems to work with our WCS service

gdallocationinfo 
WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=korkeusmalli__korkeusmalli
 -wgs84 27 68
Report:
  Location: (228000P,119567L)
  Band 1:
Value: 303.463989257812

-Jukka Rahkonen-

Lähettäjä: gdal-dev 
mailto:gdal-dev-boun...@lists.osgeo.org>> 
Puolesta Carl Godkin
Lähetetty: torstai 21. lokakuuta 2021 18.47
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] gdallocatio

Re: [gdal-dev] gdallocationinfo + WCS question...

2021-10-21 Thread Rahkonen Jukka (MML)

Hi,

My first test was:
gdallocationinfo  
"WCS:https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?version=2.0.1=DEP3Elevation;
 -wgs84 10 20 --debug on

Generated request was:
WCS: Requesting 
https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?SERVICE=WCS=GetCoverage=2.0.1=DEP3Elevation=x%281112188.7215549201,1113212.7215446942%29=y%282272938.1370637044,2273450.1370585896%29=image/tiff

Gdallocationfo showed:
Value: 0

Maybe it is a right value, I do not know. I got zero value also with -wgs84 27 
68. Now I tried with the coordinates that you used -wgs84 -122.086 42.948 but 
it leads into server error after GDAL sent this request with quite a large 
subsets:
WCS: Requesting 
https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?SERVICE=WCS=GetCoverage=2.0.1=DEP3Elevation=x%28-20037507.067213,-13590403.131594259%29=y%285303978.1067894027,5304490.1067842878%29=image/tiff

-Jukka-





Lähettäjä: gdal-dev  Puolesta Ari Jolma
Lähetetty: torstai 21. lokakuuta 2021 22.09
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] gdallocationinfo + WCS question...


I don't understand the problem :)

Maybe it's because I ran gdalinfo on the WCS first.

For the gdallocationinfo I get

gdallocationinfo 
"WCS:https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?version=2.0.1=DEP3Elevation;
 -wgs84 -122.086 42.948
Report:
  Location: (6446955P,13504941L)
  Band 1:
Value: 1882.00549316406

Ari
Rahkonen Jukka (MML) kirjoitti 21.10.2021 klo 21.56:
Hi,

I wonder if the problem is in the multipart response that the nationalmap.gov 
server is sending. The result is not too big tiff (1023x511 pixels as revealed 
by 1023 511) but perhaps GDAL does not know how to extract 
it from the multipart envelope. I do not know either. I thought that multipart 
was only an issue with WCS 1.1.x but obviously it can be used also with WCS 
2.0. I do understand how brilliant idea multipart response is in theory but 
unfortunately it is a pain for the users.

This is the beginning of the response:

--wcs
Content-Type: text/xml
Content-ID: GML-Part
  
http://www.opengis.net/def/crs/EPSG/0/3857 
axisLabels="x y" uomLabels=" " srsDimension="2">
  3005564.702644 10446506.055425
  3006588.702633 10447018.055420

  
  

  

  0 0
  1023 511

  
  band_1
  
http://www.opengis.net/def/crs/EPSG/0/3857>
  3005564.702644 10446506.055425

  
  http://www.opengis.net/def/crs/EPSG/0/3857>XOFFSET1.00XOFFSET 0 

  http://www.opengis.net/def/crs/EPSG/0/3857>0 
YOFFSET1.00YOFFSET 

  
  

  http://www.opengis.net/spec/WCS_coverageencoding_geotiff/1.0/ 
xlink:arcrole="fileReference"/>
  
cid:Coverage1.tif>
  
  image/tiff

  
  

  

  band_1
  
  

  3.4E-38 3.4E+38

  

  

  

--wcs
Content-Type: image/tiff
Content-Description: coverage data
Content-Transfer-Encoding: binary
Content-ID: 1.tif
…

-Jukka Rahkonen-


Lähettäjä: gdal-dev 
<mailto:gdal-dev-boun...@lists.osgeo.org> 
Puolesta Carl Godkin
Lähetetty: torstai 21. lokakuuta 2021 18.47
Vastaanottaja: gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
Aihe: [gdal-dev] gdallocationinfo + WCS question...

Hi,

I am trying to use gdallocationinfo to query point locations from a WCS server 
and not having any luck. I don't see anything in the docs that says this is 
unsupported but I can't make it work.

First of all, is there a better way to get an elevation from a given lat,lon 
using WCS?

Here's an example query using the USGS National Map server:

gdallocationinfo 
"WCS:https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?version=2.0.1=DEP3Elevation;
 -wgs84 -122.086 42.948 --debug ON

This is a point in the middle of Crater Lake which I picked since it's flat and 
I know what to expect.

Anyway, looking at the debug output it appears that the program is querying for 
a GeoTIFF of a VERY large area and that's failing.

I actually want to do this with my own WCS server but thought it might be 
mis-configured somehow so I tried the USGS server.  With my own server, 
gdallocationinfo seems to be requesting a strange shape from the server (as I 
can see through the debug output).

Thanks for any help,

carl




___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdallocationinfo + WCS question...

2021-10-21 Thread Rahkonen Jukka (MML)

Hi,

I wonder if the problem is in the multipart response that the nationalmap.gov 
server is sending. The result is not too big tiff (1023x511 pixels as revealed 
by 1023 511) but perhaps GDAL does not know how to extract 
it from the multipart envelope. I do not know either. I thought that multipart 
was only an issue with WCS 1.1.x but obviously it can be used also with WCS 
2.0. I do understand how brilliant idea multipart response is in theory but 
unfortunately it is a pain for the users.

This is the beginning of the response:

--wcs
Content-Type: text/xml
Content-ID: GML-Part
  
http://www.opengis.net/def/crs/EPSG/0/3857 
axisLabels="x y" uomLabels=" " srsDimension="2">
  3005564.702644 10446506.055425
  3006588.702633 10447018.055420

  
  

  

  0 0
  1023 511

  
  band_1
  
http://www.opengis.net/def/crs/EPSG/0/3857>
  3005564.702644 10446506.055425

  
  http://www.opengis.net/def/crs/EPSG/0/3857>XOFFSET1.00XOFFSET 0 

  http://www.opengis.net/def/crs/EPSG/0/3857>0 
YOFFSET1.00YOFFSET 

  
  

  http://www.opengis.net/spec/WCS_coverageencoding_geotiff/1.0/ 
xlink:arcrole="fileReference"/>
  
cid:Coverage1.tif>
  
  image/tiff

  
  

  

  band_1
  
  

  3.4E-38 3.4E+38

  

  

  

--wcs
Content-Type: image/tiff
Content-Description: coverage data
Content-Transfer-Encoding: binary
Content-ID: 1.tif
…

-Jukka Rahkonen-


Lähettäjä: gdal-dev  Puolesta Carl Godkin
Lähetetty: torstai 21. lokakuuta 2021 18.47
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] gdallocationinfo + WCS question...

Hi,

I am trying to use gdallocationinfo to query point locations from a WCS server 
and not having any luck. I don't see anything in the docs that says this is 
unsupported but I can't make it work.

First of all, is there a better way to get an elevation from a given lat,lon 
using WCS?

Here's an example query using the USGS National Map server:

gdallocationinfo 
"WCS:https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?version=2.0.1=DEP3Elevation;
 -wgs84 -122.086 42.948 --debug ON

This is a point in the middle of Crater Lake which I picked since it's flat and 
I know what to expect.

Anyway, looking at the debug output it appears that the program is querying for 
a GeoTIFF of a VERY large area and that's failing.

I actually want to do this with my own WCS server but thought it might be 
mis-configured somehow so I tried the USGS server.  With my own server, 
gdallocationinfo seems to be requesting a strange shape from the server (as I 
can see through the debug output).

Thanks for any help,

carl

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdallocationinfo + WCS question...

2021-10-21 Thread Rahkonen Jukka (MML)

Hi,

At least it seems to work with our WCS service

gdallocationinfo 
WCS:https://beta-karttakuva.maanmittauslaitos.fi/wcs/service/ows?version=2.0.1=korkeusmalli__korkeusmalli
 -wgs84 27 68
Report:
  Location: (228000P,119567L)
  Band 1:
Value: 303.463989257812

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Carl Godkin
Lähetetty: torstai 21. lokakuuta 2021 18.47
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] gdallocationinfo + WCS question...

Hi,

I am trying to use gdallocationinfo to query point locations from a WCS server 
and not having any luck. I don't see anything in the docs that says this is 
unsupported but I can't make it work.

First of all, is there a better way to get an elevation from a given lat,lon 
using WCS?

Here's an example query using the USGS National Map server:

gdallocationinfo 
"WCS:https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?version=2.0.1=DEP3Elevation;
 -wgs84 -122.086 42.948 --debug ON

This is a point in the middle of Crater Lake which I picked since it's flat and 
I know what to expect.

Anyway, looking at the debug output it appears that the program is querying for 
a GeoTIFF of a VERY large area and that's failing.

I actually want to do this with my own WCS server but thought it might be 
mis-configured somehow so I tried the USGS server.  With my own server, 
gdallocationinfo seems to be requesting a strange shape from the server (as I 
can see through the debug output).

Thanks for any help,

carl

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL does not find geometries from KML

2021-10-19 Thread Rahkonen Jukka (MML)

Hi,

I found what is the problem. The service is sending old style KML, the current 
specification has this note:

Note: The  tag has been deprecated. Use  
instead.

Search-replace made GDAL to find the missing  geometries.

-Jukka Rahkonen-

Lähettäjä: Rahkonen Jukka (MML)
Lähetetty: tiistai 19. lokakuuta 2021 15.53
Vastaanottaja: 'gdal-dev@lists.osgeo.org' 
Aihe: GDAL does not find geometries from KML

Hi,

I tried to convert geometries from a KML file captured with URL 
https://www.sedecatastro.gob.es/cartografia/fxcc/fxcc_kml.aspx?refcat=0717611VK4701F

Ogrinfo finds layers
INFO: Open of `0717611VK4701F.kml'
  using driver `LIBKML' successful.
1: 0717611VK4701F
2: PLANTA GENERAL
3: PLANTA BAJA 00

Ogrinfo finds also a POINT Z geometry from layer 0717611VK4701F. By looking at 
the KML file with a text editor layers PLANTA GENERAL and PLANTA BAJA 00 both 
contain one GeometryCollection which is made out of one or several POLYGON Z 
geometries. However, ogrinfo does not find those geometries. The KML file opens 
with Google Earth and shows a 3D model of a building. Is there perhaps 
something special in the structure of this KML?

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] GDAL does not find geometries from KML

2021-10-19 Thread Rahkonen Jukka (MML)

Hi,

I tried to convert geometries from a KML file captured with URL 
https://www.sedecatastro.gob.es/cartografia/fxcc/fxcc_kml.aspx?refcat=0717611VK4701F

Ogrinfo finds layers
INFO: Open of `0717611VK4701F.kml'
  using driver `LIBKML' successful.
1: 0717611VK4701F
2: PLANTA GENERAL
3: PLANTA BAJA 00

Ogrinfo finds also a POINT Z geometry from layer 0717611VK4701F. By looking at 
the KML file with a text editor layers PLANTA GENERAL and PLANTA BAJA 00 both 
contain one GeometryCollection which is made out of one or several POLYGON Z 
geometries. However, ogrinfo does not find those geometries. The KML file opens 
with Google Earth and shows a 3D model of a building. Is there perhaps 
something special in the structure of this KML?

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: RFC 84: Migrating build systems to CMake

2021-10-11 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Howard Butler
Lähetetty: maanantai 11. lokakuuta 2021 17.14
Vastaanottaja: gdal dev 
Aihe: [gdal-dev] Motion: RFC 84: Migrating build systems to CMake

All,

Discussion on this topic has died down, and it appears there are no major 
objections, so I would like to put forward a motion to approve RFC 84. With a 
conservative timeline, the final outcome of this effort is GDAL will be 
CMake-only in May 2023.

You can view the proposal at 
https://github.com/OSGeo/gdal/blob/1d3c283d40f4d2145c11dfca4b537fb357f53600/gdal/doc/source/development/rfc/rfc84_cmake.rst

+1 Howard


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] FEATURE_SERVER_PAGING open option doesn't work for ESRI FeatureServer

2021-10-11 Thread Rahkonen Jukka (MML)

Hi,

Do you know if that sampleserver3.arcgisonline.com supports paging? I thought 
that this query would return one feature but it returns more

http://sampleserver3.arcgisonline.com/ArcGIS/rest/services/Hydrography/Watershed173811/FeatureServer/0/query?where=objectid+%3D+objectid=*=json=1

The page http://sampleserver3.arcgisonline.com/ArcGIS/rest/services/ suggests 
that the server version is 10.05 and 
https://gdal.org/drivers/vector/esrijson.html says that paging is supported for 
ArcGIS servers >= 10.3.

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Next Stop
Lähetetty: maanantai 11. lokakuuta 2021 15.03
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] FEATURE_SERVER_PAGING open option doesn't work for ESRI 
FeatureServer

Hi, list!

Setting FEATURE_SERVER_PAGING open option to YES doesn’t help to retrieve all 
features from ESRI FeatureServer source.

Check this out:

ogrinfo -ro -so -oo FEATURE_SERVER_PAGING=YES 
"http://sampleserver3.arcgisonline.com/ArcGIS/rest/services/Hydrography/Watershed173811/FeatureServer/0/query?where=objectid+%3D+objectid=*=json”
 ESRIJSON

You’ll still get only first 1000 records.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr changes field length

2021-10-08 Thread Rahkonen Jukka (MML)

Hi,

GDAL has the internal default of 80 characters. GDAL users do not really need 
other options because fields are automatically expanded when longer strings are 
appended afterwards but if the shapefile is used in some other software it does 
happen that it is impossible to insert long strings because there is no room 
for that in the table. I suppose that you also know that by using the field 
width of 254 you are also maximizing the size of the .dbf file because it 
reserves the same fixed amount of disk space for each cell.

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: matteo  
Lähetetty: perjantai 8. lokakuuta 2021 12.29
Vastaanottaja: Rahkonen Jukka (MML) ; Even 
Rouault ; gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] ogr2ogr changes field length

Hi Jukka,

works perfectly, thanks!

so no default options to impose the field length but it is alterable after

Cheers!

Matteo
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr changes field length

2021-10-08 Thread Rahkonen Jukka (MML)

Hi,

The best I can suggest to do by using just GDAL utilities is to run this kind 
of ogrinfo command for each text field that you have in the shapefile schema:

ogrinfo my_shape.shp -sql "alter table my_shape alter column STRING_1 TYPE 
character(254)"

(right, the max length is 254).

-Jukka Rahkonen-
 
-Alkuperäinen viesti-
Lähettäjä: matteo  
Lähetetty: perjantai 8. lokakuuta 2021 11.20
Vastaanottaja: Rahkonen Jukka (MML) ; Even 
Rouault ; gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] ogr2ogr changes field length

Hi Jukka,

> The strings fields are created by default with width 80. If there are longer 
> strings in the data the width is automatically extended up till 255 
> characters that is the maximum that dBase format supports. If strings are 
> shorter than 80 charaters it is possible to use RESIZE and shrink the width 
> to match the longest string used in that field.
> 
> If you need better control on field widths I suppose you must create an empty 
> shapefile for ogr2ogr to append by your own code.
> 
> # Add a new field.
>  field_defn = ogr.FieldDefn('NEWFLD', ogr.OFTString)
>  field_defn.SetWidth(12)
> 
> Do you have some concrete problem with field widths that you want to resolve?

I'm "dumping" empty tables of a schema to shapefile and actually yes, I need 
that the fields with unlimited text set up in PG should be the maximum (so 254) 
in the final shapefiles.

All the tables are empty so I guess this is the "problem" I have

Cheers and thanks

Matteo
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr changes field length

2021-10-08 Thread Rahkonen Jukka (MML)

Hi,

The strings fields are created by default with width 80. If there are longer 
strings in the data the width is automatically extended up till 255 characters 
that is the maximum that dBase format supports. If strings are shorter than 80 
charaters it is possible to use RESIZE and shrink the width to match the 
longest string used in that field.

If you need better control on field widths I suppose you must create an empty 
shapefile for ogr2ogr to append by your own code.

# Add a new field.
field_defn = ogr.FieldDefn('NEWFLD', ogr.OFTString)
field_defn.SetWidth(12)

Do you have some concrete problem with field widths that you want to resolve?

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta matteo
Lähetetty: perjantai 8. lokakuuta 2021 9.11
Vastaanottaja: Even Rouault ; 
gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] ogr2ogr changes field length

Hi Even,

> If you add -lco RESIZE=YES fields will be resized to their minimum size. 
> See 
> https://gdal.org/drivers/vector/shapefile.html#layer-creation-options

yep I see. I also read

* String fields without an assigned width are treated as 80 characters

does it mean that if a field is set as TEXT in PG (without length
definition) the conversion to shapefile is automatically set to 80 and what we 
can do is to resize the field length only to have less characters?

Cheers!

Matteo
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WFS driver

2021-10-07 Thread Rahkonen Jukka (MML)

Hi,

If you are asking the same question in gis.stackexchange please wait some 
minutes if somebody happens to answer you before sending mail to gdal-dev. Or 
vise versa. Crossposting in the long run will not help you to get answers 
faster.

-Jukka Rahkonen-

Lähettäjä: gdal-dev  Puolesta Mohammed 
Aljezawi
Lähetetty: torstai 7. lokakuuta 2021 13.22
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] WFS driver

Hi,
I am using gdal to convert from WFS to geopackge, everything is working fine 
but I need to change the name of each table before or after converting to 
GeoPackage, because the layer name has a special charachart that in my 
application it's not working.

Thank you
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Not able to use gdal_translate and a TMS source

2021-10-05 Thread Rahkonen Jukka (MML)

Hi,

There is not so much wrong, you should just read 
https://gdal.org/drivers/raster/wms.html more carefully and write server URL 
this way:

  
https://tiles.wmflabs.org/osm-no-labels/${z}/${x}/${y}.png

-Jukka Rahkonen-




Lähettäjä: gdal-dev  Puolesta andy
Lähetetty: tiistai 5. lokakuuta 2021 16.42
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Not able to use gdal_translate and a TMS source

Hi,
in QGIS I have set this XYZ source: 
https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png
QGIS renders it properly.

I have created this GDAL source




https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png


-20037508.34
20037508.34
20037508.34
-20037508.34
18
1
1
top

EPSG:900913
256
256
3

204,404


But if run

gdal_translate --debug ON -of PNG -projwin 5203413 2847209 5221042 2829459 
-outsize 512 512 osm-no-labels.xml openstreetmap.png

I have a black PNG.

The debug shows me a wrong HTTP call (the below one), but I do not know how to 
modify my xml source to be able to run right requests.

HTTP: Request [1] 
https://tiles.wmflabs.org/osm-no-labels/{z}/{x}/{y}.png/1.0.0//12/2580/1758.jpg

What's wrong in my settings?

Thank you

--
___

Andrea Borruso
website: https://medium.com/tantotanto
38° 7' 48" N, 13° 21' 9" E, EPSG:4326
___

"cercare e saper riconoscere chi e cosa,
 in mezzo all’inferno, non è inferno,
e farlo durare, e dargli spazio"

Italo Calvino
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Does OAPIF paging work as supposed?

2021-09-28 Thread Rahkonen Jukka (MML)

Hi,

Even Rouault wrote:

> One option to avoid both issues would be for the service to publish
> DescribedBy links at the collection level that would point to a XML
> schema (using a GML Simple Feature schema profile, such as the one
> understood by the GML driver) or a JSON schema (not "too" complicated too).
> Both are handled by the driver.

We added JSON schema and ogrinfo seems to read it, but it still wants to read 
one page of data:

ogrinfo 
OAPIF:http://some.internal.service/features/collections/PalstanSijaintitiedot/ 
-al -so -oo PAGE_SIZE=1 -nocount -noextent -nogeomtype --debug on

HTTP: Fetch(http:// some.internal.service 
/features/collections/PalstanSijaintitiedot/schema)
HTTP: These HTTP headers were set: Accept: application/schema+json
OAPIF: Using JSON schema
HTTP: Fetch(http:// some.internal.service 
/features/collections/PalstanSijaintitiedot/items?f=json=1)

I wonder if there is still something in ogrinfo that I cannot turn off and what 
triggers the need to read some features, perhaps the coordinate system.


-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Does OAPIF paging work as supposed?

2021-09-27 Thread Rahkonen Jukka (MML)

Hi,

At least in this case having INITIAL_REQUEST_PAGE_SIZE=number option would
resolve the practical problem. We have collections with millions of features
and therefore large page size is essential when downloading the whole
collection. On the other hand we have complicated geometries like lake polygons
and reading 1 large geometries for resolving the schema is pretty heavy.
And we have 126 collections in the service that makes 126 x 1 features read
for resolving the schemas if the aim is to clip a small area from all
collections into GeoPackage.

-Jukka Rahkonen-

Lähettäjä: Even Rouault
Lähetetty: maanantai 27. syyskuuta 2021 16.47
Vastaanottaja: Rahkonen Jukka (MML) ;
'gdal-dev@lists.osgeo.org'
Aihe: Re: [gdal-dev] Does OAPIF paging work as supposed?

Jukka,

your analysis is completely correct. Whether this is expected or not probably
depends on situations. Should we have a INITIAL_REQUEST_PAGE_SIZE=number open
option to overload the number of features to retrieve specifically in the first
request... ??

Regarding the spatial filter, it is passed through the OGR API generally after
having queried the schema, and for most OGR datasources it wouldn't influence
the schema, so there isn't much that can be done here, except maybe adding a
BBOX=west,south,east,north open option.

One option to avoid both issues would be for the service to publish DescribedBy
links at the collection level that would point to a XML schema (using a GML
Simple Feature schema profile, such as the one understood by the GML driver) or
a JSON schema (not "too" complicated too). Both are handled by the driver.

Even
Le 27/09/2021 à 15:21, Rahkonen Jukka (MML) a écrit :
Hi,

I tried to read a relatively small BBOX from an OAPIF server but the process
feels rather slow and I do not quite understand what I am seeing in the log.

ogr2ogr -f GPKG test.gpkg
OAPIF:https://avoin-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/?api-key=
-spat 25 65 25.1 65.1 -oo PAGE_SIZE=1 --debug on --config cpl_curl_verbose
yes

Excerpts from the log:

HTTP:
Fetch(https://avoin-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/collections/osoitepiste/items?api-key==json=1)
HTTP: These HTTP headers were set: Accept: application/geo+json,
application/json
...
> GET
> /maastotiedot/features/v1/collections/osoitepiste/items?api-key==json=1
> HTTP/1.1
Host: avoin-paikkatieto.maanmittauslaitos.fi
Accept-Encoding: gzip
Accept: application/geo+json, application/json

* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
...
GeoJSON: First pass: 56.54 %
GeoJSON: First pass: 100.00 %
HTTP:
Fetch(https://avoin-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/collections/osoitepiste/items?api-key==json=1=25,65,25.1014,65.0943)
...
> GET
> /maastotiedot/features/v1/collections/osoitepiste/items?api-key==json=1=25,65,25.1014,65.0943
> HTTP/1.1
...
< Content-Length: 309
GDALVectorTranslate: 0 features written in layer 'osoitepiste'

Do I read right that GDAL is first reading one page, in this time 1
features without BBOX, perhaps for resolving the schema, and then makes a new
query with BBOX? In this case the BBOX query finds nothing. Reading 1
features on the first round and then discarding everything feels too expensive.
Could it be enough to read for example 10 features that is the default page
size on the first round instead of the full page?

-Jukka Rahkonen-

___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Does OAPIF paging work as supposed?

2021-09-27 Thread Rahkonen Jukka (MML)

Hi,

I tried to read a relatively small BBOX from an OAPIF server but the process 
feels rather slow and I do not quite understand what I am seeing in the log.

ogr2ogr -f GPKG test.gpkg 
OAPIF:https://avoin-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/?api-key=
 -spat 25 65 25.1 65.1 -oo PAGE_SIZE=1 --debug on --config cpl_curl_verbose 
yes

Excerpts from the log:

HTTP: 
Fetch(https://avoin-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/collections/osoitepiste/items?api-key==json=1)
HTTP: These HTTP headers were set: Accept: application/geo+json, 
application/json
...
> GET 
> /maastotiedot/features/v1/collections/osoitepiste/items?api-key==json=1
>  HTTP/1.1
Host: avoin-paikkatieto.maanmittauslaitos.fi
Accept-Encoding: gzip
Accept: application/geo+json, application/json

* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
...
GeoJSON: First pass: 56.54 %
GeoJSON: First pass: 100.00 %
HTTP: 
Fetch(https://avoin-paikkatieto.maanmittauslaitos.fi/maastotiedot/features/v1/collections/osoitepiste/items?api-key==json=1=25,65,25.1014,65.0943)
...
> GET 
> /maastotiedot/features/v1/collections/osoitepiste/items?api-key==json=1=25,65,25.1014,65.0943
>  HTTP/1.1
...
< Content-Length: 309
GDALVectorTranslate: 0 features written in layer 'osoitepiste'

Do I read right that GDAL is first reading one page, in this time 1 
features without BBOX, perhaps for resolving the schema, and then makes a new 
query with BBOX? In this case the BBOX query finds nothing. Reading 1 
features on the first round and then discarding everything feels too expensive. 
Could it be enough to read for example 10 features that is the default page 
size on the first round instead of the full page?

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] TIF + TFW to GeoTIFF without decompression/recompression

2021-09-20 Thread Rahkonen Jukka (MML)

Hi,

Sorry for not reading your mail till the end after the signature.

I was wondering now if gdal_merge.py with the -createonly option could be 
useful for a user like me who can't program can use workarounds. However, for 
some reason the final step with geotifcp fails.

I first checked that combining baseline.tif and baseline.tfw succeeds and it 
did.
geotifcp  -e baseline.tfw baseline.tif baseline_plus_geo.tif

Creating an empty geotif with gdal_merge is fast
gdal_merge -o mergetest.tif -createonly geotiff.tif

Copying GeoTIFF tags with the -g option fails always. I tried also non-empty 
GeoTIFFs as the source for the metadata.
geotifcp  -g mergetest.tif baseline.tif baseline_plus_merge.tif
mode=w
geo_print.c DefaultRead failed to read anything.
Failure in GTIFImport

-Jukka Rahkonen-




-Alkuperäinen viesti-
Lähettäjä: Rahkonen Jukka (MML) 
Lähetetty: maanantai 20. syyskuuta 2021 12.24
Vastaanottaja: 'Andrea Giudiceandrea' 
Kopio: 'gdal-dev@lists.osgeo.org' 
Aihe: Re: [gdal-dev] TIF + TFW to GeoTIFF without decompression/recompression

Hi,

Have you considered to use https://gdal.org/programs/gdal_edit.html?

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Andrea 
Giudiceandrea via gdal-dev
Lähetetty: maanantai 20. syyskuuta 2021 12.11
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] TIF + TFW to GeoTIFF without decompression/recompression

Hi devs,
gdal_transalte has an "hidden" feature (not mentioned in the docs [1]), 
introduced since GDAL 1.10 [2], which allows to convert .JPG + .JPW raster 
layer to GeoTIFF without decompressing and recompressing the raster image (a so 
called "lossless conversion of JPEG into JPEG-in-TIFF" [3]).

It seem to me the same is not possible if the source is a .TIF (e.g. a
JPEG-in-TIFF) + .TFW raster layer. In this case the image is always 
decompressed and then recompressed if a compression method is specified, thus 
adding another unnecessary lossy step.

I think the decompression / recompression cycle should obviously not be needed 
converting a TIFF file to a GeoTIFF file (unless image manipulation options are 
specified) and gdal_transalte should just copy the source TIF file and add the 
proper GeoTIFF metadata tags taken from the TFW file and from the -a_srs 
parameter.

Maybe is there any other "hidden" feature I haven't been able to find yet?

Best regards.

Andrea Giudiceandrea


[1] https://github.com/OSGeo/gdal/issues/4510
[2]
https://github.com/OSGeo/gdal/commit/a77c726484d508f12b9f5a9a869313092687
[3]
https://erouault.blogspot.com/2014/04/advanced-jpeg-in-tiff-uses-in-gdal.html


Side notes:

I know gdal_edit could also be used, but it cannot automatically take the 
georeferencing parameters from the TFW file.

It could also be possible to use the geotifcp cli tool from libgeotiff, but it 
seems it (the one shipped by OSGeo4W) has some issues handling JPEG-in-TIFF 
files (while it works well with other compression formats): 
the "Warning, fractional scanline discarded." and "JPEGLib: Application 
transferred too few scanlines." errors are reported unsuccessfully trying to 
convert a JPEG-in-TIFF + TFW to a GeoTIFF.

Instead, the very old and almost nowhere to be found GeoTiffExamin gui tool can 
just add the proper GeoTIFF metadata tags, taken from the TFW file, to a TIFF 
file without modifying the raster image. Anyway the gui tool cannot be used for 
batch conversion.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] TIF + TFW to GeoTIFF without decompression/recompression

2021-09-20 Thread Rahkonen Jukka (MML)

Hi,

Have you considered to use https://gdal.org/programs/gdal_edit.html?

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Andrea 
Giudiceandrea via gdal-dev
Lähetetty: maanantai 20. syyskuuta 2021 12.11
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] TIF + TFW to GeoTIFF without decompression/recompression

Hi devs,
gdal_transalte has an "hidden" feature (not mentioned in the docs [1]), 
introduced since GDAL 1.10 [2], which allows to convert .JPG + .JPW raster 
layer to GeoTIFF without decompressing and recompressing the raster image (a so 
called "lossless conversion of JPEG into JPEG-in-TIFF" [3]).

It seem to me the same is not possible if the source is a .TIF (e.g. a
JPEG-in-TIFF) + .TFW raster layer. In this case the image is always 
decompressed and then recompressed if a compression method is specified, thus 
adding another unnecessary lossy step.

I think the decompression / recompression cycle should obviously not be needed 
converting a TIFF file to a GeoTIFF file (unless image manipulation options are 
specified) and gdal_transalte should just copy the source TIF file and add the 
proper GeoTIFF metadata tags taken from the TFW file and from the -a_srs 
parameter.

Maybe is there any other "hidden" feature I haven't been able to find yet?

Best regards.

Andrea Giudiceandrea


[1] https://github.com/OSGeo/gdal/issues/4510
[2]
https://github.com/OSGeo/gdal/commit/a77c726484d508f12b9f5a9a869313092687
[3]
https://erouault.blogspot.com/2014/04/advanced-jpeg-in-tiff-uses-in-gdal.html


Side notes:

I know gdal_edit could also be used, but it cannot automatically take the 
georeferencing parameters from the TFW file.

It could also be possible to use the geotifcp cli tool from libgeotiff, but it 
seems it (the one shipped by OSGeo4W) has some issues handling JPEG-in-TIFF 
files (while it works well with other compression formats): 
the "Warning, fractional scanline discarded." and "JPEGLib: Application 
transferred too few scanlines." errors are reported unsuccessfully trying to 
convert a JPEG-in-TIFF + TFW to a GeoTIFF.

Instead, the very old and almost nowhere to be found GeoTiffExamin gui tool can 
just add the proper GeoTIFF metadata tags, taken from the TFW file, to a TIFF 
file without modifying the raster image. Anyway the gui tool cannot be used for 
batch conversion.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Geoserver 2.20.RC generating high CPU load

2021-09-17 Thread Rahkonen Jukka (MML)

Hi,

I installed and started GS 2.20 yesterday on Windows and now the corresponding 
OpenJDK 11 process shows constant high CPU usage (12-17%). Service is started 
at localhost:8080 and I do not generate any requests for the service. I do not 
understand what happens and how to investigate the situation. Any suggestions?

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Approve Nyall Dawson as a contracted GDAL maintainer

2021-09-14 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Howard Butler
Lähetetty: tiistai 14. syyskuuta 2021 17.59
Vastaanottaja: gdal dev 
Aihe: [gdal-dev] Motion: Approve Nyall Dawson as a contracted GDAL maintainer

Dear PSC,

As a result of our fundraising activity and development of NumFOCUS as a 
financial conduit, it is my pleasure to put forward a motion to approve Nyall 
Dawson as a contracted GDAL maintainer for the year 2021-2022 beginning on 
October 1st, 2021 and ending September 30th, 2022.

Details of the maintenance tasking and duties can be found at the previously 
approved RFC 83 
https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html

The terms of the contract are for a maximum of 500 hours at 90 €/hr.

Howard

PS I will coordinating the contracting activity in my role as the GDAL NumFOCUS 
contracting liaison, with Frank Warmerdam acting as the secondary. Please 
contact us directly with any comments or concerns.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Re Motion: promote GDAL 3.3.2 RC3

2021-09-02 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: gdal-dev  Puolesta Even Rouault
Lähetetty: torstai 2. syyskuuta 2021 9.54
Vastaanottaja: gdal-dev@lists.osgeo.org
Aihe: [gdal-dev] Motion: promote GDAL 3.3.2 RC3

Hi,

Having heard no issues being reported regarding RC3

Motion:

Adopt GDAL 3.3.2 RC3 as final 3.3.2 release

Starting with my +1

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: Approve Even Rouault as a contracted GDAL maintainer

2021-08-22 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

Howard Butler wrote:

> Dear PSC,

> As a result of our fundraising activity and development of NumFOCUS as a 
> financial conduit, it is my pleasure to put forward a motion to approve Even 
> Rouault as a contracted GDAL maintainer for the year 2021-2022 beginning on 
> August 1st, 2021 and ending July 31st, 2022. 

Details of the maintenance tasking and duties can be found at the previously 
approved RFC 83 
https://gdal.org/development/rfc/rfc83_use_of_project_sponsorship.html

> The terms of the contract are for 833 hours at $120/hr USD.

> Howard
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Setting roles in PostGIS connection

2021-07-02 Thread Rahkonen Jukka (MML)

Hi again,

GDAL is using the standand libpg-connect 
https://www.postgresql.org/docs/12/libpq-connect.html and that does not have 
support for defining roles during connect.

Do I understand right that your user "Joe" does not have direct CREATEDB 
privileges but gets them through the admins role? And because CREATEDB has a 
special handling https://www.postgresql.org/docs/current/role-membership.html 
there is no other way to let Joe to create db that through SET ROLE ADMINS.

Making GDAL to support 
"-doo "PRELUDE_STATEMENTS=SET ROLE admins"
feels like a good idea but I have no idea about how difficult it would be to 
implement.

-Jukka Rahkonen-

-Alkuperäinen viesti-
Lähettäjä: Rahkonen Jukka (MML) 
Lähetetty: perjantai 2. heinäkuuta 2021 14.40
Vastaanottaja: 'gdal-dev@lists.osgeo.org' 
Aihe: Re: Setting roles in PostGIS connection

Hi,

I wonder if writing the output into pgdump 
https://gdal.org/drivers/vector/pgdump.html and editing the SQL a bit could be 
used as a workaround. 

-Jukka Rahkonen-

Pekka Sarkola wrote:

> Hi!

> We have a PostGIS database with login roles and group roles (like 
> "admins", "editors" and "viewers"). We have defined that only "admins" 
> can create new schemas and tables (among other privileges). My problem 
> is that I'd like to use ogr2ogr to bulk load some data to a PostGIS 
> database using ogr2ogr with a certain login role with "admins" role.

> It seems that it is not possible to define roles in PostgreSQL 
> connection parameters (my first try) or in PostgreSQL driver options.

> I tried to use PREDUDE_STATEMENTS like: "-doo "PRELUDE_STATEMENTS=SET 
> ROLE admins", but got warning "Warning 1: -doo ignored when creating 
> the output datasource."

> Any solutions or suggestions?

> There is also similar case in QGIS: Supporting "set role" when 
> connecting to a postgres database - 
> https://github.com/qgis/QGIS/issues/42763

> Versions: GDAL 3.0.4, released 2020/01/28, PostgreSQL 12.7, PostGIS 
> 3.1

> Rgs,

> Pekka
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Setting roles in PostGIS connection

2021-07-02 Thread Rahkonen Jukka (MML)

Hi,

I wonder if writing the output into pgdump 
https://gdal.org/drivers/vector/pgdump.html and editing the SQL a bit could be 
used as a workaround. 

-Jukka Rahkonen-

Pekka Sarkola wrote:

> Hi!

> We have a PostGIS database with login roles and group roles (like "admins",
> "editors" and "viewers"). We have defined that only "admins" can create new
> schemas and tables (among other privileges). My problem is that I'd like to
> use ogr2ogr to bulk load some data to a PostGIS database using ogr2ogr
> with a certain login role with "admins" role.

> It seems that it is not possible to define roles in PostgreSQL connection
> parameters (my first try) or in PostgreSQL driver options.

> I tried to use PREDUDE_STATEMENTS like: "-doo "PRELUDE_STATEMENTS=SET ROLE
> admins", but got warning "Warning 1: -doo ignored when creating the output
> datasource."

> Any solutions or suggestions?

> There is also similar case in QGIS: Supporting "set role" when connecting
> to a postgres database - https://github.com/qgis/QGIS/issues/42763

> Versions: GDAL 3.0.4, released 2020/01/28, PostgreSQL 12.7, PostGIS 3.1

> Rgs,

> Pekka
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WMS using a Proxy

2021-06-30 Thread Rahkonen Jukka (MML)

Hi,

Our proxy does not require user/password but these options work for the 
server/port part:

1) Set environmental variable and run gdalinfo
SET https_proxy=our_proxy.fi:
gdalinfo 
"WMS:https://www.idee.es/wms/PNOA/PNOA?service=wms=getcapabilities;

2) Set proxy with config option

gdalinfo 
"WMS:https://www.idee.es/wms/PNOA/PNOA?service=wms=getcapabilities; 
--config gdal_http_proxy our_proxy.fi:

Config option gdal_http_proxy seems to work also with https. Environmental 
variables must be set explicitly for http_proxy and https_proxy. And --config 
can be repeated. Which method to use depends on your work environment. I 
believe that technically the options are identical but if you use both internal 
and external services which require different proxy settings it might be more 
clear to define the proxy with config option.

-Jukka Rahkonen-

Elena Ruiz wrote:

> Hello, I need to access the information from a WMS server through a proxy. I 
> would need to 
> know exactly the syntax to use the proxy, I have tried the following:

>   gdalinfo 
> "WMS:https://www.idee.es/wms/PNOA/PNOA?service=wms=getcapabilities; 
> -config GDAL_HTTP_PROXY xx.xxx.x.xx:3128 -config GDAL_HTTP_PROXYUSERPWD 
> user:password -config GDAL_HTTP_AUTH NTLM

> Would it be okay with the previous syntax? Can you repeat the word --config? 
> Do you need 
> quotes or brackets for the IP: port or user: password? in the case of 
> GDAL_HTTP_AUTH, 
> how to know whether to put NTLM or BASIC? and finally, is it better to put 
> the parameters 
> after gdalinfo or in the system variables?

> I'm waiting for your answer, regards
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problem with OAPIF and numeric id in the data

2021-06-21 Thread Rahkonen Jukka (MML)

Even Rouault   wrote:

>> However, QGIS seems to drop the native fids and generate new ones but that's 
>> another problem to learn to circumvent.
> Hum, I'm afraid it will not be easy. The QGIS WFS / OAPIF provider stores 
> internally the feature id in the 
> internal feature cache but doesn't expose it. The QGIS feature id you get 
> from such layer is a purely 
> synthetical one, and that may change between sessions. Trying to remember 
> about that design choice,
> there are several reasons:
* if the WFS layer is a result of a join operation, there is no unique id
* if we exposed the gml:id (or JSON id) as a regular field, that could cause 
issues for transactional WFS support where you don't want users to modify that 
value

In that case I think we must publish the id two times in the OAPIF service, 
once as the id member and another time as  "landmark_id" or something in the 
feature properties because the id is meaningful for the users. They must be 
able to search by landmark_id and show them on the map.

> That could probably be changed pending some work.

-Jukka-

> Even
-- 
http://www.spatialys.com
My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Problem with OAPIF and numeric id in the data

2021-06-21 Thread Rahkonen Jukka (MML)

Thanks,

I can get a copy of the native OAPIF FID into a normal attribute with

ogrinfo 
OAPIF:https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/
 -dialect sqlite -sql "select rowid, * from RajamerkinSijaintitiedot limit 10" 
--debug on

OGRFeature(SELECT):9
  rowid (Integer) = 12425588

A bit strange message at the end of the debug info but I guess that for some 
reason the features are read twice:
SQLite: 20 features read on layer 'SELECT'.
OGR: Unloading VirtualOGR module

I know now well enough how I can get and store the native fids from OAPIF 
service with GDAL command line tools. However, QGIS seems to drop the native 
fids and generate new ones but that's another problem to learn to circumvent.

-Jukka-

Lähettäjä: Even Rouault 
Lähetetty: maanantai 21. kesäkuuta 2021 17.50
Vastaanottaja: Rahkonen Jukka (MML) ; 
'gdal-dev@lists.osgeo.org' 
Aihe: Re: [gdal-dev] Problem with OAPIF and numeric id in the data


Jukka,

https://github.com/OSGeo/gdal/commit/36aa932aba3775f1e6ec825ba39c633442ffa640 
should help

Even
Le 21/06/2021 à 16:01, Rahkonen Jukka (MML) a écrit :
Hi,

With this request

ogrinfo 
OAPIF:https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/
 -dialect sqlite -sql "select * from RajamerkinSijaintitiedot limit 10" --debug 
on

ogrinfo does not use the "id" member as feature id nor does is report it as an 
attribute. Id exists in the data in this format
{"type":"FeatureCollection","features":[{"type":"Feature","id":12425552,"properties":{
as can be checked with 
https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/collections/RajamerkinSijaintitiedot/items?f=json=10

The service that is used as reference in 
https://gdal.org/drivers/vector/oapif.html is having the id as string
"type" : "Feature","id" : "DENW42AL1000NscuFL",

and in this case ogrinfo does not use "id" ad fid either but at least reads it 
as a normal attribute
ogrinfo -al OAPIF:https://www.ldproxy.nrw.de/rest/services/kataster flurstueck 
--debug on
...
OGRFeature(flurstueck):110
  id (String) = DENW42AL1000NtLGFL


I managed to get the "id" used as fid when converting data from the service at 
maanmittauslaitos.fi into geopackage by using -preserve_fid but for some reason 
today even that does not work for me.

-Jukka Rahkonen-




___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Converting fid from GeoJSON into GeoPackage

2021-06-21 Thread Rahkonen Jukka (MML)

Thanks,

I believe this resolves my previous problem by the same. The indirect_sqlite 
dialect is not so handy in this case because it wants do download the whole 
collection from OAPIF.

So because OAPIF is sending data as GeoJSON there is no name for the FID column 
and it is obligatory to use ogr2ogr with "-preserve_fid" if the aim is to 
preserve FID.  I will see if there is something to improve with this in the 
documentation. I had some trouble with joining  edited data with the original 
because 15 million feature ids changed into counting numbers.

-Jukka-

Lähettäjä: Even Rouault 
Lähetetty: maanantai 21. kesäkuuta 2021 18.09
Vastaanottaja: Rahkonen Jukka (MML) ; 
'gdal-dev@lists.osgeo.org' 
Aihe: Re: [gdal-dev] Converting fid from GeoJSON into GeoPackage


Jukka,

Automatic FID preservation requires that the source layer reports a non-empty 
column name for the FID column, which isn't the case of the GeoJSON driver. 
Mostly only SQL-based drivers will report a non-empty FID column name.

Even
Le 21/06/2021 à 17:04, Rahkonen Jukka (MML) a écrit :
Hi,

Take this GeoJSON

{
"type": "FeatureCollection",
"features": [{
"type": "Feature",
"id":12425552,
"properties":
{
},
"geometry": {
"type": "Point",
"coordinates": [26.30578223, 60.26170791]
}
}]
}

Ogrinfo knows the fid
OGRFeature(one_feature):12425552

Convert into a new GeoPackage and the native fid is lost
ogr2ogr -f gpkg one_feature.gpkg one_feature.json
OGRFeature(one_feature):1

Running the command with "-preserve_fid" keeps the native fid but according to 
ogr2ogr documentation https://gdal.org/programs/ogr2ogr.html that should not be 
needed:

"Use the FID of the source features instead of letting the output driver 
automatically assign a new one (for formats that require a FID). If not in 
append mode, this behavior is the default if the output driver has a FID layer 
creation option, in which case the name of the source FID column will be used 
and source feature IDs will be attempted to be preserved."

Is the error in the documentation or in the GeoJSON-GeoPackage conversion?

-Jukka Rahkonen-






___

gdal-dev mailing list

gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>

https://lists.osgeo.org/mailman/listinfo/gdal-dev

--

http://www.spatialys.com

My software is free, but my time generally not.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Converting fid from GeoJSON into GeoPackage

2021-06-21 Thread Rahkonen Jukka (MML)

Hi,

Take this GeoJSON

{
"type": "FeatureCollection",
"features": [{
"type": "Feature",
"id":12425552,
"properties":
{
},
"geometry": {
"type": "Point",
"coordinates": [26.30578223, 60.26170791]
}
}]
}

Ogrinfo knows the fid
OGRFeature(one_feature):12425552

Convert into a new GeoPackage and the native fid is lost
ogr2ogr -f gpkg one_feature.gpkg one_feature.json
OGRFeature(one_feature):1

Running the command with "-preserve_fid" keeps the native fid but according to 
ogr2ogr documentation https://gdal.org/programs/ogr2ogr.html that should not be 
needed:

"Use the FID of the source features instead of letting the output driver 
automatically assign a new one (for formats that require a FID). If not in 
append mode, this behavior is the default if the output driver has a FID layer 
creation option, in which case the name of the source FID column will be used 
and source feature IDs will be attempted to be preserved."

Is the error in the documentation or in the GeoJSON-GeoPackage conversion?

-Jukka Rahkonen-


___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] Problem with OAPIF and numeric id in the data

2021-06-21 Thread Rahkonen Jukka (MML)

Hi,

With this request

ogrinfo 
OAPIF:https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/
 -dialect sqlite -sql "select * from RajamerkinSijaintitiedot limit 10" --debug 
on

ogrinfo does not use the "id" member as feature id nor does is report it as an 
attribute. Id exists in the data in this format
{"type":"FeatureCollection","features":[{"type":"Feature","id":12425552,"properties":{
as can be checked with 
https://beta-paikkatieto.maanmittauslaitos.fi/kiinteisto-avoin/features/v1/collections/RajamerkinSijaintitiedot/items?f=json=10

The service that is used as reference in 
https://gdal.org/drivers/vector/oapif.html is having the id as string
"type" : "Feature","id" : "DENW42AL1000NscuFL",

and in this case ogrinfo does not use "id" ad fid either but at least reads it 
as a normal attribute
ogrinfo -al OAPIF:https://www.ldproxy.nrw.de/rest/services/kataster flurstueck 
--debug on
...
OGRFeature(flurstueck):110
  id (String) = DENW42AL1000NtLGFL


I managed to get the "id" used as fid when converting data from the service at 
maanmittauslaitos.fi into geopackage by using -preserve_fid but for some reason 
today even that does not work for me.

-Jukka Rahkonen-

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] vsicurl and an issue with http 302 redirect in the middle of the file

2021-05-05 Thread Rahkonen Jukka (MML)

Hi,

Have a look at 
https://gis.stackexchange.com/questions/395867/opening-a-grib-from-the-web-with-gdal-in-python-using-vsicurl-throws-error-on-m.
 There gdalinfo fails with /vsicurl/ somewhere in the middle of the grib2 file 
when the server sends http 302 as a response for a range request. The file is 
OK as was tested by downloading it first totally with curl. Could it be that 
the http "moved permanently" at that stage makes /vsicurl/ to fail?

I made also a few tests and it seems that the error may happen in another http 
range, but it is always similar:
VSICURL: Got response_code=302
GRIB: ERROR: Ran out of file in Section 7

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC80

2021-04-16 Thread Rahkonen Jukka (MML)

+1

-Jukka Rahkonen-

> Hi,

> I hereby motion to adopt RFC 80:
> https://github.com/OSGeo/gdal/pull/3682
> This also implies adopting the "GDAL Sponsorship Prospectus"  at
> https://docs.google.com/document/d/1yhMWeI_LgEXPUkngqOitqcKfp7ov6WsS41v5ulz-kd0/edit?ts=60777468
>  
> whose a PDF version will be uploaded on the website  
> >(https://github.com/OSGeo/gdal/pull/3681 to be updated)
> and the proposed answers to the NumFOCUS application form are at:
> https://docs.google.com/document/d/1bc5jdpCe1axdyBHxbJnun7e0DTyDoZI_eFYgJYnOhB8/edit
> which will be submitted consequently.

> Starting with my +1

> Even

___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result in data loss.

2021-03-30 Thread Rahkonen Jukka (MML)

Hi,

I did not have a close look into your ground control points but perhaps they 
are not very well distributed and therefore the default warping algorithm eats 
one corner of the image. Have a try with thin plate splin (-tps) instead.  
There may be some bug, it does not feel right that some source data are lost 
with default algorithm.

-Jukka Rahkonen-

Lähettäjä: Hays Barrett 
Lähetetty: tiistai 30. maaliskuuta 2021 19.32
Vastaanottaja: Rahkonen Jukka (MML) 
Kopio: gdal-dev@lists.osgeo.org
Aihe: Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result in 
data loss.

I put together a page that better explains the issue and used one of the actual 
images from our project.
https://haysbarrett.com/gdal_translate/
Thanks for looking into this for me.
-Hays

On Fri, Mar 26, 2021 at 2:59 PM jratike80 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

Please give an exact example. Preferably with a raster that can be created
from command line with gdal_create followed by other required commands. Or
alternatively Python code that re-produces the issue.

-Jukka Rahkonen-

Hays Barrett wrote
> If the gcps stretch the image beyond the dimensions of the original raster
> it appears to clip the data that sits outside of the original raster
> dimensions rather than increase the raster dimensions to fit the stretched
> data .
> Is this the expected behavior?
> If so is there a way to increase the dimensions of a raster so there is no
> data loss?
> Thanks,
> -Hays
>
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo<mailto:gdal-dev@.osgeo>

> https://lists.osgeo.org/mailman/listinfo/gdal-dev

--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org<mailto:gdal-dev@lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[gdal-dev] OAPIF with Accept-encoding: gzip

2021-03-23 Thread Rahkonen Jukka (MML)

Hi,

Is it possible to ask the OAPIF server to send response as gzipped, and if it 
succeeds, would GDAL know what to do with the response? I made a try by saving 
a line "Accept-Encoding: gzip" as a test file and then making this request:

ogrinfo 
OAPIF:"https://beta-paikkatieto.maanmittauslaitos.fi/inspire-buildings/features/v1/collections/building/;
 --config GDAL_HTTP_HEADER_FILE headers.txt --debug on --config cpl_debug on

Unfortunately it seems that Accept-Encoding header was not added:
HTTP: These HTTP headers were set: Accept: application/geo+json, 
application/json

Is there some trick to make this to work or would it require changes into the 
OAPIF driver?

-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WMTS services error

2021-02-12 Thread Rahkonen Jukka (MML)

Hi,

That’s not the main issue because hand written XML gives the same error. I 
guess that GDAL is reading the EPSG:4326 tile matrix set from GetCapabilities 
and does not like it. This is what I used for testing:


  
http://www.ign.es/wmts/pnoa-ma?request=GetCapabilities=WMTS=1.0.0
  OI.OrthoimageCoverage
  default
  EPSG:4326
  
-180
90
180
-90
  
  3
  
  true
  404
  true


-Jukka-

Lähettäjä: Travis Kirstine 
Lähetetty: perjantai 12. helmikuuta 2021 20.43
Vastaanottaja: Rahkonen Jukka (MML) 
Kopio: gdal dev 
Aihe: Re: [gdal-dev] WMTS services error

Jukka,

I think the main issue is that the gdal_translate command throws an error when 
generating the WMTS XML config file, so there is nothing to edit.

gdal_translate 
"WMTS:http://www.ign.es/wmts/pnoa-ma?request=GetCapabilities=WMTS,layer=OI.OrthoimageCoverage,tilematrixset=EPSG:4326;
 wmts_bm.xml -of WMTS
ERROR 1: Invalid dataset dimensions : -135056383 x -167901439

On Fri, 12 Feb 2021 at 10:32, jratike80 
mailto:jukka.rahko...@maanmittauslaitos.fi>>
 wrote:
Hi,

By reading the documentation https://gdal.org/drivers/raster/wmts.html it
could be possible to edit the automatically created XML service definition
file or write it by hand from a scratch.

-Jukka Rahkonen-


Travis Kirstine wrote
> Elena
>
> This appears to be a bug in wmts driver in gdal, I would suggest filing a
> issue
>
> The below is from the OGC Two Dimensional Tile Matrix Set specs, section
> d2
> http://docs.opengeospatial.org/is/17-083r2/17-083r2.html
>
> "NOTE4: Some implementers prefer to define this TileMatrixSet using the
> CRS
> http://www.opengis.net/def/crs/EPSG/0/4326. The definition is the same
> except that CRS coordinates are expressed in latitude, longitude order,
> affecting the TopLeftCorner and the BBox encoding only".
>
>
> On Fri, 12 Feb 2021 at 08:05, Elena Ruiz 

> eruiz@

>  wrote:
>
>> Hello, my goal is to obtain images of both WMS and WMTS web services
>> using
>> GDAL, with the CRS that each service provides, in the case of the
>> example,
>> how can I do then to obtain images in EPSG: 4326 or any other CRS that
>> have
>> changed axes? Should a parameter be added to the gdal_translate call?
>> What
>> would be the correct way to obtain this type of images using gdal
>> applications like gadlinfo and gdaltranslate?
>>
>> I have found very little information about this on the web, many thanks
>> and best regards
>>
>>
>>
>>
>>
>> --
>>
>> *Elena Ruiz*
>>
>>
>> Sofware Development & Technical Support
>> Tel.: +34 952 43 97 71
>>

> eruiz@

>> *www.aplitop.com<http://www.aplitop.com> http://www.aplitop.com*
>>
>>
>>
>> http://www.aplitop.com/Product/es/6/5/tcptunnel;
>>
>> http://www.aplitop.com/New/es/281/mdt-75-a-la-venta;
>>
>>
>>
>>
>>
>> *De:* Travis Kirstine 

> traviskirstine@

> 
>> *Enviado el:* jueves, 11 de febrero de 2021 20:20
>> *Para:* Elena Ruiz 

> eruiz@

> 
>> *CC:*

> gdal-dev@.osgeo<mailto:gdal-dev@.osgeo>

>> *Asunto:* Re: [gdal-dev] WMTS services error
>>
>>
>>
>> Elena,
>>
>>
>>
>> I'm not exactly sure what is causing the issue but if you look at the
>> capabilities of the 4326 tilematrixset compared to the InspireCRS84Quad
>> the
>> topleftcorner coordinates are reversed.  My guess gdal is expecting a X Y
>> order.
>>
>>
>>
>>
> 
>>
> 
> InspireCRS84Quad
> 
>>
> 
> http://www.opengis.net/def/crs/OGC/1.3/CRS84
>>
> 
>>
> 
>>
> 
> 0
> 
>>
> 
> 2.79541132014358E8
> 
>>
> 
> -180.0 90.0
> 
>>
> 
> 256
> 
>>
> 
> 256
> 
>>
> 
> 2
> 
>>
> 
> 1
> 
>>
> 
>>
>>
>>
>>
> 
>>
> 
> EPSG:4326
> 
>>
> 
> EPSG:4326
> 
>>

>>
> 
>>
> 
> EPSG:4326:0
> 
>>
> 
> 2.795411320143589E8
> 
>>
> 
> 90.0 -180.0
> 
>>
> 
> 256
> 
>>
> 
> 256
> 
>>
> 
> 2
> 
>>
> 
> 1
> 
>>
> 
>>
>>
>>
>>
>>
>> On Thu, 11 Feb 2021 at 11:51, Elena Ruiz 

> eruiz@

>  wrote:
>>
>> Hello, I´m trying call web services (WMTS and WMS) using GDAL 3.0.2, but
>> I
>> have a problem with this example:
>>
>>
>>
>> gdal_translate "WMTS:
>> http://www.ign.es/wmts/pnoa-ma?request=GetCapabilities=WMTS,layer=OI.OrthoimageCoverage,tilematrixset=EPSG:

Re: [gdal-dev] Problems with ArcGIS image server and WMS minidriver

2021-02-05 Thread Rahkonen Jukka (MML)

Hi,

Got it by having a look at 
https://github.com/OSGeo/gdal/blob/master/gdal/frmts/wms/minidriver_arcgis_server.cpp
// Assume map service if exportImage is not explicitly requested.

I just had to edit the server url in my XML file into this
https://image.discomap.eea.europa.eu/arcgis/rest/services/GioLand/HRIM_HR_TrueColour_2018/ImageServer/exportImage?

-Jukka-


Lähettäjä: Rahkonen Jukka (MML)
Lähetetty: perjantai 5. helmikuuta 2021 17.04
Vastaanottaja: 'gdal-dev@lists.osgeo.org' 
Aihe: Problems with ArcGIS image server and WMS minidriver

Hi,

I almost managed to read data from this URL but not quite
https://image.discomap.eea.europa.eu/arcgis/rest/services/GioLand/HRIM_HR_TrueColour_2018/ImageServer/exportImage?f=image=-3493783.68885884%2C3191895.64564654%2C5001886.25692533%2C11496874.31511627=512%2C512=3857=3857=png8==false=

The service capabilities are coming from the server
https://image.discomap.eea.europa.eu/arcgis/rest/services/GioLand/HRIM_HR_TrueColour_2018/ImageServer?f=json=true

However, GDAL requests do not work for me

gdalinfo 
"https://image.discomap.eea.europa.eu/arcgis/rest/services/GioLand/HRIM_HR_TrueColour_2018/ImageServer?f=json=true;
or
gdal_translate 
"https://image.discomap.eea.europa.eu/arcgis/rest/services/GioLand/HRIM_HR_TrueColour_2018/ImageServer?f=json=true;
 out.xml -of WMS

The error is
ERROR 4: `C:\TEMP\file.dat' not recognized as a supported file format.
For me it seems that file.dat was never written.
BTW, how on earth I can select the temporary folder? c:\temp is not good at all 
for my work computer.

Then I wrote the XML file by hand by using 
https://github.com/OSGeo/gdal/blob/master/gdal/frmts/wms/frmt_ags_arcgisonline.xml
 as an example. What fails now it that GDAL is generating request as

https://image.discomap.eea.europa.eu/arcgis/rest/services/GioLand/HRIM_HR_TrueColour_2018/ImageServer/export?f=image=-3493783.68885884%2C3191895.64564654%2C5001886.25692533%2C11496874.31511627=512%2C512=3857=3857=png8==false=

However, that server delivers data from /exportImage? , not from /export?.

Can anybody suggest a simple workaround for changing those urls to point into 
exportImage?


-Jukka Rahkonen-
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

1 2 3 4 >

1 - 100 of 316 matches

Mail list logo