Re: [gdal-dev] Converting WFS to shapefile

[jratike80]

Hi,

Run ogrinfo WFS:https://geodata.nationaalgeoregister.nl/aan/wfs
and you'll see
1: aan:aan (title: aan) (Multi Surface)

Use the typeName as it appears. Works for me with

ogr2ogr -f "ESRI Shapefile" --debug ON  -s_srs "EPSG:4326" -t_srs
"EPSG:28992" "Perceel-aan.shp"
"WFS:https://geodata.nationaalgeoregister.nl/aan/wfs?service=WFS&request=GetFeature&version=2.0.0&typename=aan:aan&srsname=EPSG:4326&bbox=163049,467594,163256,468020,EPSG:28992";

-Jukka Rahkonen-





Paul Meems wrote
> Hi List,
> 
> I'm having trouble converting the result of a WFS request to a shapefile.
> I'm using two servers, one is working the other not.
> 
> My command for the working server:
> ogr2ogr -f "ESRI Shapefile" -s_srs "EPSG:4326" -t_srs "EPSG:28992"
> "Perceel-bbox.shp" "WFS:
> https://geodata.nationaalgeoregister.nl/kadastralekaart/wfs/v4_0?service=WFS&request=GetFeature&version=2.0.0&typename=kadastralekaartv4:perceel&srsname=EPSG:4326&outputFormat=application/json&bbox=163049,467594,163256,468020,EPSG:28992
> "
> 
> And the not working server:
> ogr2ogr -f "ESRI Shapefile" --debug ON  -s_srs "EPSG:4326" -t_srs
> "EPSG:28992" "Perceel-aan.shp" "WFS:
> https://geodata.nationaalgeoregister.nl/aan/wfs?service=WFS&request=GetFeature&version=2.0.0&typename=aan&srsname=EPSG:4326&outputFormat=application/json&bbox=163049,467594,163256,468020,EPSG:28992
> "
> 
> I don't get an error, the file is just not created.
> The debug messages:
> WFS:
> https://geodata.nationaalgeoregister.nl/aan/wfs?SERVICE=WFS&REQUEST=GetCapabilities&version=2.0.0&srsname=EPSG:4326&bbox=163049,467594,163256,468020,EPSG:28992
> HTTP: Fetch(
> https://geodata.nationaalgeoregister.nl/aan/wfs?SERVICE=WFS&REQUEST=GetCapabilities&version=2.0.0&srsname=EPSG:4326&bbox=163049,467594,163256,468020,EPSG:28992
> )
> HTTP: libcurl/7.74.0-DEV OpenSSL/1.1.1i zlib/1.2.11
> WFS: Paging support with page size 15000
> WFS: No transaction support
> GDAL: GDALOpen(WFS:
> https://geodata.nationaalgeoregister.nl/aan/wfs?service=WFS&request=GetFeature&version=2.0.0&typename=aan&srsname=EPSG:4326&outputFormat=application/json&bbox=163049,467594,163256,468020,EPSG:28992,
> this=018A6EA691F0) succeeds as WFS.
> GDAL: GDALDriver::Create(ESRI
> Shapefile,Perceel-aan.shp,0,0,0,Unknown,)
> GDAL: GDALClose(WFS:
> https://geodata.nationaalgeoregister.nl/aan/wfs?service=WFS&request=GetFeature&version=2.0.0&typename=aan&srsname=EPSG:4326&outputFormat=application/json&bbox=163049,467594,163256,468020,EPSG:28992,
> this=018A6EA691F0)
> GDAL: GDALClose(Perceel-aan.shp, this=018A70565430)
> GDAL: In GDALDestroy - unloading GDAL shared library.
> 
> When I open the URL in the browser, I do get back JSON data. When I copy
> this and paste it in QGis I get the expected polygons.
> 
> I'm not sure how I need to change my command to get this working for the
> second server as well.
> Please advice.
> 
> With regards,
> 
> Paul Meems
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] TypeError Wrong number or type of arguments for overloaded function 'CoordinateTransformation_TransformPoint'.

[jratike80]

Hi,

At least you must fix this error first
"ERROR 1: PROJ: proj_create_from_database:
C:\Users\Deployment\.conda\envs\sw_py37_cv45\Library\share\proj\proj.db
lacks DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR
metadata. It comes from another PROJ installation."

Your proj.db database must come from some older version than your current
Proj. Proj is reading the table "metadata" and the CREATE TABLE SQL for that
it currently https://github.com/OSGeo/PROJ/blob/master/data/sql/metadata.sql
and contains 

INSERT INTO "metadata" VALUES('DATABASE.LAYOUT.VERSION.MAJOR', 1);
INSERT INTO "metadata" VALUES('DATABASE.LAYOUT.VERSION.MINOR', 1);

Those fields were added 2020-11-30 by commit
https://github.com/OSGeo/PROJ/commit/eef73e3eca2959768563d2dbb95a591c68b1d807#diff-7efcaee17a3e41e5440dc2ff9e962f20ad448a3ce5d7fff45a839846a85f37f8


-Jukka Rahkonen-






zerovirus123 wrote
> I am trying to run some GDAL operations inside my Anaconda environment.
> However once I upgraded my gdal and other packages the program crashed.
> 
> Environment: Anaconda
> 
> Package   Version  Channel
> GDAL   3.3.0  pipwin
> fiona 1.8.20pipwin
> geopandas   0.9.0  pipwin
> shapely1.7.1  pipwin
> pyproj   2.6.1.post1py37hcfa1391_1
> 
> Here is the offending code.
> 
> crsGeo = osgeo.osr.SpatialReference()
> crsGeo.ImportFromEPSG(int(proj_type))
> t = osgeo.osr.CoordinateTransformation(crs, crsGeo)
> (lat, long, z) = t.TransformPoint(posX, posY)<---
> srs = osgeo.osr.SpatialReference(wkt=prj)  
> 
> And the raster's metadata.
> /proj:  GEOGCS["WGS 84",
> DATUM["WGS_1984",
> SPHEROID["WGS 84",6378137,298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich",0],
> UNIT["degree",0.0174532925199433,
> AUTHORITY["EPSG","9122"]],
> AXIS["Latitude",NORTH],
> AXIS["Longitude",EAST],
> AUTHORITY["EPSG","4326"]]
> proj type:  4326/
> 
> The code threw the following error.
> 
> *ERROR 1: PROJ: proj_create_from_database:
> C:\Users\Deployment\.conda\envs\sw_py37_cv45\Library\share\proj\proj.db
> lacks DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR
> metadata. It comes from another PROJ installation.
> ERROR 1: PROJ: proj_create_from_database:
> C:\Users\Deployment\.conda\envs\sw_py37_cv45\Library\share\proj\proj.db
> lacks DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR
> metadata. It comes from another PROJ installation.
> ERROR 1: PROJ: proj_create: unrecognized format / unknown name
> ERROR 6: Cannot find coordinate operations from `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]]'
> to `'
> Could not calculate crsGeo spatial reference.
> F:\Sliding_Windows\GeoTiff.py, line 402: TypeError Wrong number or type of
> arguments for overloaded function
> 'CoordinateTransformation_TransformPoint'.
>   Possible C/C++ prototypes are:
> OSRCoordinateTransformationShadow::TransformPoint(double [3])
> OSRCoordinateTransformationShadow::TransformPoint(double [4])
> OSRCoordinateTransformationShadow::TransformPoint(double
> [3],double,double,double)
> OSRCoordinateTransformationShadow::TransformPoint(double
> [4],double,double,double,double)*
> 
> Based on previous posts, it seems that proj.dll is missing from some PATH
> variable. My environment only has a proj_6_2.dll, and even with that added
> to my system's PATH, the error persists.
> 
> I have tried to put posX and posY inside tuples/list as well, but that did
> not help.
> 
> Is this a package mismatch issue? Missing dependencies issue? Or was there
> a
> change in how TransformPoint should be called?
> 
> 
> 
> 
> 
> 
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Renaming Sponsorships tiers to align with NumFOCUS ones

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> PSC,
> 
> We've had a request from NumFOCUS to align the titles of the GDAL 
> sponsorship tiers with the ones of NumFOCUS, to limit the risk of 
> confusion, which was one topic discussed during last meeting.
> 
> For reference, the ones of NumFOCUS are at 
> https://numfocus.org/sponsors/become-a-sponsor, so to get consistent, 
> our new levels would renamed as:
> 
> - Gold (previously Platinum): 50k
> 
> - Silver (previously Gold): 25k
> 
> - Bronze (previously Silver): 10k
> 
> This will help especially for actors that already have a relationship 
> with NumFOCUS and can be confused by the current non-alignment.
> 
> NumFOCUS confirmed that companies that offer a sponsorship designated to 
> GDAL will receive both GDAL's benefits and NumFOCUS ones under that tier 
> (if they don't already benefit from NumFOCUS sponsorship at a higher 
> level because already sponsoring other NumFOCUS projects)
> 
> I'm +1 for that change. I don't anticipate sponsors to mind about that 
> change. The different tiers and relative positioning with other actors 
> is probably what matters to them, more than the absolute title of the 
> tier. Anyway, we'll communicate that change to the current sponsors, and 
> adapt our own documentation.
> 
> Even
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 83: guidelines for the use of GDAL project sponsorship

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> Motion:
> 
> adopt RFC 83: guidelines for the use of GDAL project sponsorship ( 
> https://github.com/OSGeo/gdal/pull/3855 )
> 
> Starting with my +1
> 
> Even
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Renaming of GDAL Advisory Board

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> We just had a meeting with NumFOCUS staff, and they suggested we should 
> rename the GDAL Advisory Board to something else. The issue is with the 
> Board term which is a legal term and may implicate that it is a deciding 
> body, which it is not. They suggested Council, Committee, as potential 
> alternatives. As committee is already used for the PSC, I think "GDAL 
> Advisory Council" could be a good fit.
> 
> If there's no opposition to this, I'll change all references to it on 
> the GDAL website (RFC 80, sponsorship prospectus), and ask for the 
> related mailing list to be renamed/recreated.
> 
> Other news: the Fiscal Sponsorship Agreement document, which will make 
> us officialy a NumFOCUS sponsored project, is now in the signing loop.
> 
> Even
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL Reproject Run as a Batch under QGIS

[jratike80]

Hi,

This seems to be a wrong mailing list. Use qgis-users
https://lists.osgeo.org/mailman/listinfo/qgis-user instead or
gis.stackexcange site. Before you write a new mail or question please try to
improve your question a bit. What is not working? Do you know if
reprojecting a whole directory of files is supported or if you are rather
requesting a new feature?


-Jukka Rahkonen-



Mike Stanton wrote
> ''
> It is not working. I cannot put any reasonable information into the
> "Reproject" field of the batch job menu that makes it acceptable. What I
> would expect is to point at a folio containing Tiff Files for the input
> and a folio to receive the converted Tiff Files for receiving output that
> might be named the same as the input file. What it appears to expect is
> individual TIFF names. Does anyone have suggestions on how to correct
> this?
> 
> Mike
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] VRT layer definition question

[jratike80]

Hi,

Ogrinfo finds numbers from the .csv file with a little help:
ogrinfo csv.csv csv -al -oo autodetect_type=yes

Ogrinfo finds numbers from the .csv file automatically, probably because the
fields are mapped into real in the vrt file:
ogrinfo csv.vrt -al -so

But ogrmerge.py does have a problem:
ogrmerge f csv -o merged.csv csv.vrt
Warning 1: The 'lon' and/or 'lat' fields of the source layer are not
declared as numeric fields, so the spatial filter cannot be turned into an
attribute filter on them

Ogrmerge runs when I add a mapping file .csvt

csv.csvt
=
Real,Real,String

It seems to me that your vrt file is OK but there is some issue in the
ogrmerge.py script that does not get the data type of the field correctly
from vrt. Write the csvt file and you should be fine.

-Jukka Rahkonen-



Al Piszcz wrote
> Jukka:
> Thank you, interesting, lat,lon interpreted as string by gdalinfo.
> 
>  Request 1
> ogrinfo file1.csv -al -so
> INFO: Open of `file1.csv'
>   using driver `CSV' successful.
> 
> Layer name: file1
> Geometry: None
> Feature Count: 1000
> Layer SRS WKT:
> (unknown)
> lon: String (0.0)
> lat: String (0.0)
> id: String (0.0)
> field_4: String (0.0)
> 
> === Request 2
> ::: file1.csv
> lon,lat,id,
> 0.084362378404311,0.08587464990542,"0"
> 0.090601035370249,0.005574551382458,"1"
> 0.074081946277276,0.020574321282505,"2"
> 0.034318505618178,0.034922734033886,"3"
> 0.008330436091964,0.013543226571866,"4"
> 
> 
> 
> Message: 2
> Date: Mon, 31 May 2021 13:41:55 -0700 (MST)
> From: jratike80 <

> jukka.rahkonen@

> >
> To: 

> gdal-dev@.osgeo

> Subject: Re: [gdal-dev]
> Message-ID: <

> 1622493715145-0.post@.nabble

>>
> Content-Type: text/plain; charset=us-ascii
> 
> Hi,
> 
> Please add couple of rows from your CSV file. Maybe the lon and lat fields
> are otherwise OK but GDAL does not recognize them to contain numbers but
> perhaps text. You can also check what sort of attributes ogrinfo reports
> with
> 
> ogrinfo file1.csv -al -so
> 
> -Jukka Rahkonen-
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] VRT layer definition question

[jratike80]

Hi,

Please add couple of rows from your CSV file. Maybe the lon and lat fields
are otherwise OK but GDAL does not recognize them to contain numbers but
perhaps text. You can also check what sort of attributes ogrinfo reports
with

ogrinfo file1.csv -al -so

-Jukka Rahkonen-



Al Piszcz wrote
> I am having a challenge determining the right position or entry for the
> Field entry, the spatial filter error below indicates my VRT format is not
> correct. Is there a better approach? Thank you.
> 
>>ogrmerge.py -overwrite_ds -single -o __sdg\merge_02.csv __sdg\merge_01.vrt
> 
> *Warning 1: The 'lon' and/or 'lat' fields of the source layer are not
> declared as numeric fields, so the spatial filter cannot be turned into an
> attribute filter on them*
> 
> The VRT is defined as
> 
>   
> 
> 
> 
> lib/_data/sdg/data\file1.csv
> 
> 
> 
> file1
> 
>
> 
>
> 
>
> 
> POLYGON ((0.0 0.0, 0.0 0.1, 0.1 0.1, 0.1 0.0, 0.0
> 0.0))
> 
>
> 
> wkbPoint
> 
>
> 
> WGS84
> 
>
> 
> 
>   
> 
> 
> 
> lib/_data/sdg/data\file2.csv
> 
> 
> 
> file2
> 
>
> 
>
> 
>
> 
> POLYGON ((0.0 0.0, 0.0 0.1, 0.1 0.1, 0.1 0.0, 0.0
> 0.0))
> 
>
> 
> wkbPoint
> 
>
> 
> WGS84
> 
>
> 
> 
> 
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[jratike80]

Hi,

I guess that by "data" you mean datasets like GeoJSON file or GeoTIFF image. 
For individual coordinates folks in the Finnish Geospatial Institute (FGI)
do conversions like in this cs2cs example 

echo 2258573.56109 1010806.43899 5859099.49087 2021.26 | cs2cs -d 4 --area
finland EPSG:7789 EPSG:4936

where "2021.26" after the x, y, and z coordinates is the epoch and it gets
used with this operation:

projinfo -s EPSG:7789 -t EPSG:4936 -o PROJ --area Finland
-
Operation No. 1:
NKG:ITRF2014_TO_FI, ITRF2014 to ETRS89 (EUREF-FIN), 0.01 m, Finland -
onshore and offshore.
PROJ string:
+proj=pipeline
+step +proj=helmert +x=0 +y=0 +z=0 +rx=0 +ry=0 +rz=0 +s=0 +dx=0 +dy=0 +dz=0
+drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0 +t_epoch=1989
+convention=position_vector
+step +inv +proj=deformation +t_epoch=2000.0 +grids=eur_nkg_nkgrf17vel.tif
+step +proj=helmert +x=0.15651 +y=-0.10993 +z=-0.10935 +rx=-0.00312861
+ry=-0.00378935 +rz=0.00403512 +s=0.00529 +convention=position_vector +step
+proj=deformation +dt=-3 +grids=eur_nkg_nkgrf17vel.tif

The same thing with Python:

transformer = pyproj.Transformer.from_pipeline("""
+proj=pipeline
+step +proj=helmert +x=0 +y=0 +z=0 +rx=0 +ry=0 +rz=0 +s=0 +dx=0
+dy=0 +dz=0 +drx=8.5e-05 +dry=0.000531 +drz=-0.00077 +ds=0
+t_epoch=1989 +convention=position_vector
+step +inv +proj=deformation +t_epoch=2000.0
+grids=eur_nkg_nkgrf17vel.tif
+step +proj=helmert +x=0.15651 +y=-0.10993 +z=-0.10935
+rx=-0.00312861 +ry=-0.00378935 +rz=0.00403512 +s=0.00529
+convention=position_vector
+step +proj=deformation +dt=-3 +grids=eur_nkg_nkgrf17vel.tif""")
coord = transformer.transform(x_wgs84, y_wgs84, z_wgs84, year)

-Jukka Rahkonen-


Nyall Dawson wrote
> On Thu, 27 May 2021 at 23:40, Even Rouault <

> even.rouault@

> > wrote:
>>
>> Hi,
>>
>> - merging the underlying API without any format support is I believe of
>> little interest.
> 
> Well.. it would give users the command line tools to do static <->
> dynamic transformation of data with the epoch specified in the command
> line arguments. That's a quite compelling feature on its own, as it
> could be used to transform data if the user has knowledge of the epoch
> from other sources (e.g. in some pdf doc provided with the data, or if
> they collected it themselves and know the correct epoch). I'm unaware
> of any other tool (commercial or open source) which currently allows
> this type of transformation.
> 
> Nyall
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[jratike80]

Hi,

The group description of Features and Geometries JSON SWG
https://www.ogc.org/projects/groups/featgeojsonswg does not mention dynamic
coordinate systems but I can at least try to add the topic into the agenda
in the kick-off on next Tuesday (2021-06-01) even I am just on observer in
the group.

-Jukka Rahkonen-



Even Rouault-2 wrote
> That said, I'll probably drop the commit for KML as it is clearly a 
> hack, but I think support for GeoJSON, which is cleaner, could still be 
> useful at some point as it is widely used as an exchange format. But 
> I'll defer for GeoJSON until we see if the /OGC Features/ and 
> /Geometries JSON/ SWG comes with something regarding this.


Even Rouault-2 wrote
> Regarding KML and GeoJSON and OGC:CRS84 (or EPSG:4326 since they are the 
> same thing, except axis order), that's a good and hard question. 
> Actually that extends to *any* CRS built on top of them, like all the 
> EPSG:32[6|7][01-60] UTM CRS, and that's probably for those later than 
> things are the most problematic since there's no EPSG code for a UTM WGS 
> 84 (G1762) CRS. I guess people would potentially want to attach a 
> coordinate epoch to them, and have a (non-encoded-in-the-format) 
> convention that they actually mean WGS 84 (G1762) (or possibly an 
> earlier realization. The datum ensemble reality of WGS 84 is really due 
> to Transit which differs significantly from later realizations, which 
> are pretty consistent between them within a few centimers) . So I 
> wouldn't forbid such uses (I actually got private feedback that some 
> people would even want to store coordinate epoch for CRS that aren't 
> considered by EPSG as dynamic CRS, but which, for advanced uses, can 
> still have things like deformation models, like NAD83(2011) that is used 
> for most people as a static CRS, but is more a snapshot of a dynamic CRS 
> with a conventional reference epoch of 2010.0).
> 
> That said, I'll probably drop the commit for KML as it is clearly a 
> hack, but I think support for GeoJSON, which is cleaner, could still be 
> useful at some point as it is widely used as an exchange format. But 
> I'll defer for GeoJSON until we see if the /OGC Features/ and 
> /Geometries JSON/ SWG comes with something regarding this.
> 
> Even
> 
> Le 27/05/2021 à 19:24, Sean Gillies via gdal-dev a écrit :
>> Hi all,
>>
>> I've got a suggestion about limiting the number of formats.
>>
>> GeoJSON and KML don't need support for a coordinate epoch. Both of 
>> these are pretty cleared intended for low accuracy data (1-2 meters). 
>> KML and GeoJSON don't support any CRS other than OGC:CRS84, which uses 
>> (it has been pointed out many times) a datum ensemble that RFC 81 does 
>> not intend to address. Right, Even? So let's leave these formats the 
>> way they are.
>>
>> GML, GeoPackage, PostGIS, and the actively used raster formats like 
>> GeoTIFF seem like the important ones to me.
>>
>> On Thu, May 27, 2021 at 7:40 AM Even Rouault 
>> <

> even.rouault@

>   even.rouault@

> >> wrote:
>>
>> Hi,
>>
>> - merging the underlying API without any format support is I
>> believe of
>> little interest. So I'll wait for at least one format (likely
>> GeoPackage) to have merged in the master of their specification an
>> official way of storing the coordinate epoch. I've also prepared an
>> enhancement of the GeoTIFF spec regarding this
>> (https://github.com/opengeospatial/geotiff/pull/99
>> ;) that will
>> likely be
>> discussed at the next OGC GeoTIFF SWG meeting.
>>
>> - I've just chatted with Howard and a good compromise could be
>> that for
>> formats that will have an official way of storing the coordinate
>> epoch,
>> we store it by default (when it is set), and for formats that we
>> unilaterally extend (GML, KML, GeoJSON, etc.), we require an explicit
>> GDAL_ENABLE_COORD_EPOCH_STORAGE=YES configuration option to be set
>> (default would be NO). We might revisit in the future the default
>> value.
>>
>> - On the vector side of things, things will probably get more
>> complicated for some drivers, as it is likely that Spatialite (see
>> https://groups.google.com/g/spatialite-users/c/NtbuBpRzYBE
>> ;)
>> or
>> PostGIS
>> might have per-geometry coordinate epoch, not at the layer level.
>> But I
>> don't think that would invalidate having support for it at the layer
>> level (those database already support a per-geometry CRS, but GDAL
>> support for that is probably lacking a bit in those drivers), as a
>> OGRGeometry can potentially be associated with its own
>> OGRSpatialReference object.
>>
>> Even
>>
>> Le 27/05/2021 à 15:01, Howard Butler a écrit :
>> >
>> >> On May 26, 2021, at 8:33 PM, Nyall Dawson
>> <

> nyall.dawson@

>   nyall.dawson@

Re: [gdal-dev] "OGR_SQLITE_SYNCHRONOUS" and "OGR_SQLITE_CACHE" accessible through Python bindings?

[jratike80]

Hi,

By reading https://sqlite.org/asyncvfs.html you could try if setting the
journal mode into WAL with a PRAGMA command would help.

-Jukka Rahkonen-


Met Bas wrote
> Write speeds to GeoPackages appear to be going extremely slow in my use
> case.
> GPKG/SQLite journal files are being created at the sizes of 10-25 kb
> incrementally increasing the main geopackage file. This is saving on a
> drive
> where such small incremental cause larger slowdowns, so I would like to
> increase the size of these changes.
> 
> The configuration options "OGR_SQLITE_SYNCHRONOUS" and "OGR_SQLITE_CACHE"
> appear relevant to increasing speed.
> 
> Is there a way in which I can set these options (limited to the scope of
> the
> script being run) through Python?
> 
> Thank you,
> M.B
> 
> 
> 
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Removing trailing decimals from contour labels of shape files

[jratike80]

Hi,

You may ask help from mapserver-users for the Mapserver side. It is possible
to format the labels by expressions. See the example in
https://mapserver.org/mapfile/class.html#class 

"More advanced Expressions can be used to specify the labels. Since version
6.0, there are functions available for formatting numbers:

TEXT ("Area is: " + tostring([area],"%.2f"))"

-Jukka Rahkonen-





GDAL - Dev mailing list wrote
> I tried making shape files of pressure from netcdf files using the
> following commands using gdal:
> 
> gdal_contour -a pressure -i 4 -off 0 pressure.nc pressure.shp
> 
> I noticed that when displaying the graph in mapserver I get label values
> such as 1010. whereas I want the labels to be whole numbers. How
> do
> I tweak this code to get whole numbers for pressure contour labels in map
> server?
> 
> I have noticed that in the netcdf file pressure.nc that the pressure
> values
> have three trailing decimal points after them so a pressure value in the
> netcdf file will be 1010.000 instead of 1010. I also noticed that viewing
> the dbf file. Do I need to fix the netcdf file to display intergers? If so
> how do I do this?
> 
> Thank you for your time.
> 
> Jason Snyder
> -- 
> Jason Snyder PhD
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 81: support for coordinate epochs in geospatial formats

[jratike80]

+1

For me the RFC feels good. Existing data formats like GeoTIFF and GeoJSON
can deliver the 4D spatiotemporal coordinates correctly by using the epoch
attached as metadata when the whole dataset  is using the same epoch. None
of the formats dealt in the RFC should get broken. If some software does not
know what to do with the metadata it will discard the metadata and the
situation is the same than now. Those who use dynamic coordinate systems
probably know that without epoch the data are undefined and then they will
try to find the epoch by some other means.

Personally I like that data and metadata are kept in the same file. But if
it feels bad, could it be an option to use a sidecar file ".aux.xml" for the
single file / single layer formats like GeoJSON?

Obviously there is lot to do with dynamic reference systems
https://geophysica.fi/pdf/geophysica_2019_54_kierulf.pdf but this RFC could
be a good start.

-Jukka Rahkonen-



Even Rouault-2 wrote
> Hi,
> 
> Motion:
> 
> adopt RFC 81: support for coordinate epochs in geospatial formats ( 
> https://github.com/OSGeo/gdal/pull/3827 )
> 
> Starting with my +1
> 
> Even
> 
> -- 
> http://www.spatialys.com
> My software is free, but my time generally not.
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] About gdal RasterizeLayer

[jratike80]

Hi,

I tried if someone who don't know Python could do about the same with
gdal_rasterize https://gdal.org/programs/gdal_rasterize.html and I had some
success.


gdal_rasterize -dialect sqlite -sql "select st_buffer(geometry,0.01) from
states" -burn 100 -of GTIFF -ot byte -tr 0.1 0.1 -add states.shp
testburn.tif

I used byte type and burn value 100 for making quick visible result. The
default type is Float64 and it has room for much more overlapping geometries
than two.

-Jukka Rahkonen-


Frank Warmerdam wrote
> Miguel,
> 
> I can't seem to find this in the docs, but I think what you want is
> "MERGE_ALG" set to ADD instead of the default REPLACE.
> 
> https://github.com/OSGeo/gdal/blob/master/gdal/alg/gdalrasterize.cpp#L1165
> 
> This doesn't address the buffering (I guess you might still want to buffer
> the whole set), but it should take care of the additive step.
> 
> I actually implemented this as part of a programming test for my current
> job - to build heatmaps of satellite coverage.
> 
> Best regards,
> Frank
> 
> 
> On Tue, May 4, 2021 at 1:30 PM Miguel A. Manso <

> m.manso@

> > wrote:
> 
>> Dear all
>>
>> I have a multiline layer type (tracking) and I want to make a heat map
>> (densities) on a buffer of them, so that in those places where several
>> buffers overlap the density is added as many times as lines overlap.
>>
>> Now I'm doing it with a python script that reads from a shp the lines,
>> generates a buffer and rasterize the polygon filling it with a given
>> value with gda.RasterizeLayer(). I read the image as an array and with
>> numpy I add it to another array (accumulating). When I finish I convert
>> it to an image and save it in a geotiff.
>>
>> This procedure is relatively slow. Especially if you have to do it for
>> many lines.
>>
>> My question is along the lines of whether the RasterizeLayer function
>> itself could do this process in a more efficient way, making the burning
>> of the objects not an OR operation but an arithmetic sum...
>>
>> Any suggestions would be welcome.
>>
>> Regards
>> Miguel A. Manso
>>
>>
>> ___
>> gdal-dev mailing list
>> 

> gdal-dev@.osgeo

>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
> 
> 
> -- 
> ---+--
> I set the clouds in motion - turn up   | Frank Warmerdam,

> warmerdam@

> light and sound - activate the windows | +1 650-701-7823
> and watch the world go round - Rush| Geospatial Software Developer
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New JP2Grok Driver for JPEG 2000

[jratike80]

Hi,

gdal_translate -of gtiff -co compress=jpeg p4433h.tif -co
NUM_THREADS=ALL_CPUS comp.tif

Time: 4.7 seconds (with GDAL 3.3.0 gisinternals build)
Time: 11.5 seconds (with GDAL 3.1.4 OSGeo4W build)

-Jukka-



--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New JP2Grok Driver for JPEG 2000

[jratike80]

Hi Even,

You are right, Kakadu 8.x supports HTJ2K. I just had a try with the
kdu_compress demo utility from KDU805 demo apps.  The speed was good,
actually amazing. As a test image I used a 12000x12000 RGB image. The
kdu_compress command I took from this high qualite white-paper
https://htj2k.com/wp-content/uploads/white-paper.pdf.

kdu_compress -i p4433h.ppm -o tmp3.jph -rate 2 -tolerance 0 Qstep=0.001
-quiet -no_weights

As a reference I used

gdal_translate -of gtiff -co compress=jpeg p4433h.tif comp.tif

Results (total time disk-to-disk on Windows, SSD disk, laptop with Intel
core i7)

kdu_compress - JPH: 1.4 seconds (file size 36 MB, fixed size defined by
option -rate 2)
kdu_compress - JPH: 1.1 seconds (file size 90 MB, fixed size defined by
option -rate 5)
gdal_translate - TIFF: 13.1 seconds (file size 92 MB)

The Kakadu demo applications that can be acquired on request from the Kakadu
site are compiled without libtiff and therefore the input must be in ppm
format. Those who have access to Kakadu source code can compile the
applications with "KDU_INCLUDE_TIFF".

-Jukka Rahkonen-




Even Rouault-2 wrote
> I'm not sure which support of HTJ2K the ECW and MrSID SDKs have. I 
> believe there's such support Kakadu in recent releases, but might be 
> subject to extra fees (or perhaps for  faster support)





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> Not sure if anyone has given this a try, but anyway:
> 
> Motion:
> 
> Adopt GDAL 3.2.3 RC1 as final 3.2.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@.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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Convert GEOCS

[jratike80]

Hi,

There is a command, gdaltransform
https://gdal.org/programs/gdaltransform.html. However, it seems that both
coordinate systems mean the same for Proj library and no conversion in
coordinates happen. That you can test with projinfo that is a Proj utility.

projinfo -s epsg:4326 -t epsg:4674
Candidate operations found: 1
-
Operation No. 1:

INVERSE(EPSG):15894, Inverse of SIRGAS 2000 to WGS 84 (1), 1.0 m, Latin
America - SIRGAS 2000 by country

PROJ string:
+proj=noop

WKT2:2019 string:
COORDINATEOPERATION["Inverse of SIRGAS 2000 to WGS 84 (1)",
SOURCECRS[
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["geodetic latitude (Lat)",north,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433]],
AXIS["geodetic longitude (Lon)",east,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4326]]],
TARGETCRS[
GEOGCRS["SIRGAS 2000",
DATUM["Sistema de Referencia Geocentrico para las AmericaS
2000",
ELLIPSOID["GRS 1980",6378137,298.257222101,
LENGTHUNIT["metre",1]]],
PRIMEM["Greenwich",0,
ANGLEUNIT["degree",0.0174532925199433]],
CS[ellipsoidal,2],
AXIS["geodetic latitude (Lat)",north,
ORDER[1],
ANGLEUNIT["degree",0.0174532925199433]],
AXIS["geodetic longitude (Lon)",east,
ORDER[2],
ANGLEUNIT["degree",0.0174532925199433]],
ID["EPSG",4674]]],
METHOD["Geocentric translations (geog2D domain)",
ID["EPSG",9603]],
PARAMETER["X-axis translation",0,
LENGTHUNIT["metre",1],
ID["EPSG",8605]],
PARAMETER["Y-axis translation",0,
LENGTHUNIT["metre",1],
ID["EPSG",8606]],
PARAMETER["Z-axis translation",0,
LENGTHUNIT["metre",1],
ID["EPSG",8607]],
OPERATIONACCURACY[1.0],
USAGE[
SCOPE["Accuracy 1m."],
AREA["Latin America - SIRGAS 2000 by country"],
BBOX[-59.87,-122.19,32.72,-25.28]],
ID["INVERSE(EPSG)",15894]]


-Jukka Rahkonen-



Moises Silva wrote
> Hello everyone,
> 
> Is there any command in GDAL that is possible to convert the GEOCS?
>Source: GCS_SIRGAS_2000
>Target:  GCS_WGS_1984?
> 
> Thanks a lot,
> Moises
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> Having heard no issues being reported regarding RC1
> 
> Motion:
> 
> Adopt GDAL 3.3.0 RC1 as final 3.3.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@.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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL question

[jratike80]

Hi,

You can't update with ogr2ogr. Use ogrinfo instead. I believe that you will
find good examples from gis.stackexchange
https://gis.stackexchange.com/search?q=ogrinfo+update

-Jukka Rahkonen-


Peter P wrote
> It is works, Thanks
> 
> Now I trying update row.
> In SQL will be: /UPDATE "table1" SET "TestGeometry"= WHERE "Name" =
> 'testname'/
> How is this possible in ogr2ogr? I use -update, -append not work... 





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_retile JAVA bindings

[jratike80]

Hi,

The gdal_retile.py utility is a Python script and as far as I know nobody
has ported it into Java so far. Even the GeoServer documents advice to use
it as it stands
https://docs.geoserver.org/stable/en/user/tutorials/imagepyramid/imagepyramid.html.
It is about 1000 lines of Python code
https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/gdal-utils/osgeo_utils/gdal_retile.py
and I guess that it could be re-written if there is an ultimate need for
that. Workaround could be to call Python from Java but I do not know if it
makes sense.

-Jukka Rahkonen-



Lorenzo Di Giacomo wrote
> Hi, i can't find the gdal_retile porting on java, is there a class /
> method? If not, which is the best workaround?
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL question

[jratike80]

Hi,

Please check your GeoJSON before fighting with Python. "Name" placed into
here
 {"type": "FeatureCollection", "Name": "testName",

will probably be just skipped. If you used lower case "name"
{"type": "FeatureCollection", "name": "testName",

then "testName would be used as a name of the layer.

If your aim is to use Name as an attribute place it into feature properties:

{"type": "FeatureCollection", "name": "LayerName", "features":
[{"type": "Feature", 
"properties": {"Name":"testName"},
"geometry": {"type": "Polygon", "coordinates":
[[[26.54296875,64.73664139557683],[26.630859375,63.6267446447533],[29.091796875,63.97596090918338],[26.54296875,64.73664139557683]]]}}]}

Test with ogrinfo:

ogrinfo name.json -al
INFO: Open of `name.json'
  using driver `GeoJSON' successful.

Layer name: LayerName
Geometry: Polygon
Feature Count: 1
...
Name: String (0.0)
OGRFeature(LayerName):0
  Name (String) = testName
  POLYGON ((26.54296875 64.7366413955768,26.630859375
63.6267446447533,29.091796875 63.9759609091834,26.54296875
64.7366413955768))


-Jukka Rahkonen-




Peter P wrote
> PostgreSQL "table1" columns:
> Name Data Type
> Id integer
> Name text
> TestGeometry geometry
> 
> Example geojson - this will be one row in table:
> jsonVariable = {"type": "FeatureCollection", "Name": "testName",
> "features":
> [{"type": "Feature", "geometry": {"type": "Polygon", "coordinates":
> [[[26.54296875,64.73664139557683],[26.630859375,63.6267446447533],[29.091796875,63.97596090918338],[26.54296875,64.73664139557683]]]}}]}
> 
> Example python
> ogr2ogr.main(["", "-f", "PostgreSQL", "-s_srs", "+proj=longlat
> +datum=WGS84
> +no_defs", "-t_srs", "EPSG:3857", "PG:dbname='test' host='127.0.0.1'
> port='5432' user='user1' password='password1'", "-nln", "table1",
> "-append",
> json.dumps(jsonVariable)])





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal-dev Digest, Vol 203, Issue 38

[jratike80]

Hi,

The reason is that by the GetCapabilities and DescribeCoverage requests GDAL
is unable to create GetCoverage request that works. There may be a bug in
GDAL, or missing special handling that the combination of WCS 1.0.x or 1.1.x
+ MapServer would require. Different WCS versions are handled by different
code as you can see from the contents of
https://github.com/OSGeo/gdal/tree/master/gdal/frmts/wcs with version
specific "wcsdataset..." files.

Unfortunately it is not very easy to analyze what goes wrong. I myself have
not touched WCS versions 1.0.x and 1.1.x for some years. MapServer as a WCS
server is also rather uncommon and it is easy to configure it wrong with the
handwritten mapfiles. There seem to be some special rules for MapServer in
the wcs driver code but I know that the author who improved the driver a lot
was testing it more with GeoServer.

I suggest still to contact the service provider and ask if they could try to
correct the configuration of their MapServer for WCS 2.0.1. That is also the
version that can be used for INSPIRE download services.

-Jukka Rahkonen-



Elena Ruiz wrote
> Hello and thank you very much for your answer, I understand what you are
> telling me, but this happens with version 2.0.1, if you try with the
> version 1.0.0 and with the layer "Model% 20Digital% 20de% 20Elevaciones%
> 20 (MDE)% 20de% 20Andalucia% 2010% 20m" the server returns a response and
> in fact, if all the parameters are completed, it returns an image. Why
> doesn't gdal work with WCS version 1.0.0 either?
> 
> Example:
> http://www.juntadeandalucia.es/medioambiente/mapwms/REDIAM_WCS_mdt?SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&COVERAGE=Modelo%20Digital%20de%20Elevaciones%20(MDE)%20de%20Andalucia%2010%20m&CRS=EPSG:25830&FORMAT=GTiff&BBOX=531006.299122,4100120.659408,544263.630224,4112381.66471&WIDTH=1325&HEIGHT=1226&OUTPUTCRS=C:\Users\elena\AppData\Local\Temp\imagen.tif
> 
> Regards





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WCS server error. Coverage not found

[jratike80]

Hi Elena,

Check the service with direct http calls from the browser:
1) The capabilities
https://www.juntadeandalucia.es/medioambiente/mapwms/REDIAM_WCS_mdt?SERVICE=WCS&version=2.0.1&request=GetCapabilities
Result: OK

2) Describe one coverage
https://www.juntadeandalucia.es/medioambiente/mapwms/REDIAM_WCS_mdt?SERVICE=WCS&version=2.0.1&request=DescribeCoverage&coverageID=mdt_10
Result: OK

3) Try to get the coverage 
https://www.juntadeandalucia.es/medioambiente/mapwms/REDIAM_WCS_mdt?SERVICE=WCS&version=2.0.1&request=GetCoverage&coverageID=mdt_10

Result:

msWCSGetCoverage20(): WCS server error. COVERAGEID=mdt_10
not found, not in supported layer list. A layer might be disabled for this
request. Check wcs/ows_enable_request settings.


The server just does not send data with GetCoverage. Ask the service
provider if that is intentional.

The error message gives a hint. Service seems to be running on MapServer and
now it is not configured to support GetCoverage request. If service probider
wants to support it their should edit their mapfile where the
"wcs_enable_request" metadata item is set. Of course there are other ways to
misconfigure the server.


-Jukka Rahkonen-



Elena Ruiz wrote
> Hello I am testing the WCS service but I have a error that I don’t
> understand.
> 
> If I put in a web server this:
> 
> http://www.juntadeandalucia.es/medioambiente/mapwms/REDIAM_WCS_mdt?SERVICE=WCS&VERSION=1.0.0&REQUEST=GetCoverage&COVERAGE=
> Modelo%20Digital%20de%20Elevaciones%20(MDE)%20de%20Andalucia%2010%20m&CRS=EPSG:25830&FORMAT=GTiff&BBOX=531006.299122,4100120.659408,544263.630224,4112381.66471&WIDTH=1325&HEIGHT=1226&OUTPUTCRS=C:\Users\elena\AppData\Local\Temp\imagen.tif
> 
> this works ok and download a TIFF image.
> 
> But if I try to do this in gdal:
> 
>>gdal_translate -oo CACHE=wcs_cache -oo CLEAR_CACHE -oo INTERLEAVE=PIXEL
-projwin 531006.299122 4100120.659408 544263.630224 4112381.66471 -outsize
1325 1226
"WCS:http://www.juntadeandalucia.es/medioambiente/mapwms/REDIAM_WCS_mdt?VERSION=1.0.0&COVERAGE=Modelo%20Digital%20de%20Elevaciones%20(MDE)%20de%20Andalucia%2010%20m"
"C:\Users\elena\AppData\Local\Temp\imagen.tif"
> 
> The result is:
> 
> ERROR 1: msWCSGetCoverage(): WCS server error.
> COVERAGE=Modelo%20Digital%20de%20Elevaciones%20(MDE)%20de%20Andalucia%2010%20m
> not found, not in supported layer list. A layer might be disabled for this
> request. Check wcs/ows_enable_request settings.
> 
> I have tried with other version of service WCS, version 1.1.2 and 2.0.1,
> the difference is the name of layer, in this cases is “mdt_10”, but the
> result in gdal is the same.
> 
>>gdalinfo
"WCS:https://www.juntadeandalucia.es/medioambiente/mapwms/REDIAM_WCS_mdt?version=2.0.1";
> 
> Driver: WCS/OGC Web Coverage Service
> Files: C:\Users\elena\.gdal\wcs_cache\Zatax.aux.xml
> Size is 512, 512
> Origin = (0.000,0.000)
> Pixel Size = (1.000,1.000)
> Metadata:
>  
> WCS_GLOBAL#crsSupported=http://www.opengis.net/def/crs/EPSG/0/3042,EPSG:3042
>   WCS_GLOBAL#formatSupported=image/png,image/jpeg
>   WCS_GLOBAL#InterpolationSupported=NEAREST,AVERAGE,BILINEAR
>   WCS_GLOBAL#Keywords=WCS,MDT
>  
> WCS_GLOBAL#Profiles=WCS/2.0/conf/core,WCS_protocol-binding_get-kvp/1.0/conf/get-kvp,WCS_protocol-binding_post-xml/1.0/conf/post-xml,GMLCOV/1.0/conf/gml-coverage,GMLCOV/1.0/conf/multipart,GMLCOV/1.0/conf/special-format,GMLCOV_geotiff-coverages/1.0/conf/geotiff-coverage,WCS_service-extension_crs/1.0/conf/crs,WCS_service-extension_scaling/1.0/conf/scaling,WCS_service-extension_range-subsetting/1.0/conf/record-subsetting,WCS_service-extension_interpolation/1.0/conf/interpolation
>   WCS_GLOBAL#ServiceIdentification.Abstract=Nodo de la Red de Informacion
> Ambiental de Andalucia. Junta de Andalucia. Servicio WCS del Modelo
> Digital de Elevaciones (MDE) de Andalucia de 10 m de resolucion generado a
> partir de los vuelos realizados en 2010 (cuadrantes Sureste (SE) Suroeste
> (SW)) y 2011 (cuadrantes Noreste (NE) y Noroeste (NW)). Tambien se muestra
> el Modelo Digital de Elevaciones de Andalucia de 100 m generado a partir
> de MDE por cuadrantes (resolucion 10x10 y 5x5m) remuestreados procedentes
> de los proyectos de produccion de Ortofotos regionales de Andalucia y del
> PNOA. Integrado en la Infraestructura de Datos Espaciales de Andalucia,
> siguiendo las directrices del Sistema Cartografico de Andalucia.
>   WCS_GLOBAL#ServiceIdentification.AccessConstraints=Este servicio se
> puede usar de modo libre y gratuito siempre que se mencione a los autores
> y propietarios de la informacion
>   WCS_GLOBAL#ServiceIdentification.Fees=Gratuito
>   WCS_GLOBAL#ServiceIdentification.Title=REDIAM. WCS Modelo Digital de
> Elevaciones (MDE) de Andalucia
>   WCS_GLOBAL#ServiceProvider.ProviderName=Consejería de Agricultura,
> Ganadería, Pesca y Desarrollo Sostenible. Junta de Andalucía
>  
> WCS_GLOBAL#ServiceProvider.ProviderSite=https://www.juntadeandalucia.es/medioambiente/mapwms/REDIAM_WCS_mdt
>

Re: [gdal-dev] GDAL question

[jratike80]

Hi,

Ogr2ogr by default converts all the columns so you should not need to do
anything. Test first ogr2ogr from the command line without mixing Python
into the soup. If you still do not get your "name" attribute converted you
may have something special in your data, like a few first features in the
GeoJSON missing the name attribute.

Do you really mean "wkt_geometry" or is it possibly "wkb_geometry"?

If you will still have troubles please share some test data.

-Jukka Rahkonen- 



Peter P wrote
> Hello
> 
> I use GDAL(https://github.com/OSGeo/gdal) with python bindings. I am
> importing GeoJSON to PostgreSQL (PostGIS). I know how to import only
> geometry to the table. I dont know how to import geometry with others
> columns to one table. I need to import geometry to "wkt_geometry" column
> and his name to "name" column.
> Can you help me please?
> 
> Here is how I import only geometry column:
> * ogr2ogr.main(["", "-f", "PostgreSQL", "-s_srs", * *"+proj=longlat
> +datum=WGS84 +no_defs", "-t_srs", "EPSG:3857", "PG:dbname='test'
> host='127.0.0.1' port='5432' user='user1' password='password1'", "-nln",
> "table1"])*
> 
> Thanks
> 
> Best Regards
> Peter
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Registered Content-Type for VRT?

[jratike80]

Hi,

Do you count ArcMap or ArcGIS Pro as self standing software or rather as
applications that use GDAL? They read VRTs pretty well but for writing some
developer tools are required
https://pro.arcgis.com/en/pro-app/latest/help/data/imagery/supported-raster-dataset-file-formats.htm.

-Jukka Rahkonen-


GDAL - Dev mailing list wrote
> Maybe application/gdalvrt+xml? As far as I know, GDAL is the only software
> that plays VRTs, and probably the only software that ever can, considering
> the extensions and embedded Python stuff.
> 
> -- 
> Sean Gillies





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] "gdalbuildvrt does not support rotated geo transforms"

[jratike80]

Hi,

Try with gdalinfo, it should reveal the rotation. And with gdalwarp you can
convert the image into north-up.

-Jukka Rahkonen-


Lorenzo Di Giacomo wrote
> Hi, do you know why this happens when i try to merge tiles of a specific
> tiff?
> How can check if a tiff had a rotated geo transforms? And how can i fix it
> before merging it?





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Gdal Java

[jratike80]

Hi,

>From this resolved issue I can see that somebody has had success a couple of
years ago https://github.com/OSGeo/gdal/issues/1333. The bug report is
extraordinary good with build instructions and test program.

-Jukka Rahkonen-


paul.malm wrote
> Hi list,
> is there someone out there who has succeeded in installing Gdal
> Javabindings in Windows?
> I've tried for some weeks now :( and I can't find very much information
> how to do it I Windows.
> gdalalljni.dll is not found for starters (Gdal 3.2.0) but it is there, as
> installed by the installation process.
> I've been asking around on internet, but without any luck.
> If these is someone who knows how to do it in Windows with Eclipse, it
> would be much appreciated to get some info...
> It would be nice to have a bullet list (for dummies), from where to get
> the correct download files, installation, setting environment, what is
> needed to be set in Eclipse etc. I don't have any experience with
> javabindings or C++...
> 
> Kind regards,
> Paul
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Gdal Java

[jratike80]

Hi,

Perhaps you could ask from the Geotools/Geoserver teams how they manage to
get their GDAL plugin
https://docs.geotools.org/stable/userguide/library/coverage/imageio.html
https://docs.geoserver.org/stable/en/user/data/raster/gdal.html to work.

-Jukka Rahkonen-


paul.malm wrote
> Hi,
> further additional information.
> 
> I'm using
> Windows 11 64-bit with x64 based processor
> PROCESSOR_ARCHITECTURE=AMD64
> PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 158 Stepping 13, GenuineIntel
> PROCESSOR_LEVEL=6
> The Java I'm using is: OpenJDK's 8u262-b1, x86 64bit JRE.
> /Paul
> 
> 
> Från: Malm, Paul (Operations AIM)
> Skickat: den 31 mars 2021 10:50
> Till: 'Stefan Moebius' <

> Stefan.Moebius@

> >; '

> gdal-dev@.osgeo

> ' <

> gdal-dev@.osgeo

> >
> Ämne: SV: Gdal Java
> 
> Hi, additional information.
> All DLL-files in Dependency Walker under the tree of GDALALLJNI.dll that
> are placed in C:\program files\openjdk\jdk-8.0.262.10-hotspot\jre\bin\
> are marked with a red "frame" icon.
> /Paul
> 
> Från: Malm, Paul (Operations AIM)
> Skickat: den 31 mars 2021 10:00
> Till: 'Stefan Moebius' <

> Stefan.Moebius@

> >; '

> gdal-dev@.osgeo

> ' <

> gdal-dev@.osgeo

> >
> Ämne: SV: Gdal Java
> 
> Hi,
> I've installed dependency Walker 22_x64.
> I don't know how to use it, but when I load gdalalljni.dll I get the
> following errorcodes:
> Error: At least one required implicit or forwarded dependency was not
> found.
> Error: At least one module has an unresolved import due to a missing
> export function in an implicitly dependent module.
> Error: Modules with different CPU types were found.
> Error: A circular dependency was detected.
> Warning: At least one delay-load dependency module was not found.
> Warning: At least one module has an unresolved import due to a missing
> export function in a delay-load dependent module.
> 
> I can also see that a lot of DLL-files are not found e.g.
> EXT-MS-WINDOWSCORE-DEVICEINFO-L1-1-0.DLL...
> 
> In the module window of dependency walker I can see that there is 2
> different CPU types, the DLL-files with x86 are marked red while the x64
> are written in black (CPU-column).
> E.g. c:\program
> files\openjdk\jdk-8.0.262.10-hotspot\jre\bin\API-MS-WIN-CORE-DEBUG-L1-1-0.DLL
> are marked with red text x86 in the CPU column.
> 
> In the "tree" under GDALALLJNI.DLL some DLLs are marked with a red icon,
> e.g API-MS-WIN-CRT-HEAP-L1-1-0.DLL.
> When I search for that DLL-file in my computer it is found under several
> libraries
> e.g C:\Windows\System32\downlevel, C:\Program Files (x86)\Citrix\ICA
> Client\Receiver, C:\Program
> Files\OpenJDK\jdk-8.0.262.10-hotspot\jre\bin\bin
> and a lot of other places...
> 
> My JAVA_HOME points to C:\Program
> Files\OpenJDK\jdk-8.0.262.10-hotspot\jre\bin. It is a x64 Java version.
> My OS is windows10 with a x64 based processor.
> 
> Can this be any help finding the solution on my run time error:
> Native library load failed.
> java.lang.UnsatisfiedLinkError: C:\Program
> Files\OpenJDK\jdk-8.0.262.10-hotspot\jre\bin\gdalalljni.dll: The specified
> procedure cannot be found
> 
> Kind regards,
> Paul
> Från: gdal-dev <

> gdal-dev-bounces@.osgeo

> > För Stefan Moebius via gdal-dev
> Skickat: den 24 mars 2021 09:42
> Till: 

> gdal-dev@.osgeo

> Ämne: Re: [gdal-dev] Gdal Java
> 
> 
> Klicka bara på länkar och öppna bilagor om du litar på avsändaren och vet
> att innehållet är säkert.
> Hi Paul,
> I find the binaries provided at
> https://url11.mailanyone.net/v1/?m=1lOzCg-0001ww-4L&i=57e1b682&c=9fNL_OAF8vCIgrjZs9aaEB2UNNImM6gI8GCzoqAnKNimVVkylHGA07tBJv6IOWRHGmUKKXljttalb7-9fSKoJRXHVHgZZReNymWKG_G2PNsxEfzkrdsDLJ5OCUF6GOAknKU4asXym3XgQgeOGIjYq6tb5x-KYwQMeTZwonVcJUyaCE6P24h0b-tnGHxFOYo8tTg_FMbjprD8DaPQsY7871SA4Agmh43T_JQ3BjKFdtcr_ELXZdLivAPNafJvPSW6
> the easiest to use. If you click on one build, e.g.
> release-1928-x64-gdal-3-2-1-mapserver-7-6-2, you get a number of download
> options, including several installers. If you use the first one (Compiled
> binaries in a single .zip package), you get an archive which you need to
> extract, and which contains a folder bin\gdal\java. In there you find
> gdal.jar and gdalalljni.dll. Now in order to use this, you need to have
> 
>   *   Gdal.jar in your Java Classpath
>   *   The extracted bin\gdal\java and bin folders in your Path (in
> Eclipse: Run Configuration -> Environment -> Select -> Path, then edit the
> value, or set in the system)
> If that doesn't work, you'll need to provide some more detailed
> description of what issue you are facing.
> 
> --
> Stefan
> 
> From: gdal-dev <

> gdal-dev-bounces@.osgeo

> > On Behalf Of 

> paul.malm@

> Sent: Dienstag, 23. März 2021 08:26
> To: 

> gdal-dev@.osgeo

> Subject: [gdal-dev] Gdal Java
> 
> Hi list,
> is there someone out there who has succeeded in installing Gdal
> Javabindings in Windows?
> I've tried for some weeks now :( and I can't find very much information
> how to do it I Windows.
> gdalalljni.dll is not found for starters (Gdal 3.2.0) but it i

Re: [gdal-dev] Adding gcps to a raster using gdal_translate can result in data loss.

[jratike80]

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

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] interpreting gdalcompare results

[jratike80]

Hi,

There is some documentation in https://gdal.org/programs/gdalcompare.html:

Synopsis:
gdalcompare.py [-sds] golden_file new_file


The file that is considered correct, referred to as the golden file.


The file being compared to the golden file, referred to as the new file.

In your report the golden file (call is as the first file if it feels
better) has zero overview levels and the second file has 5 overview levels.

At pixel level there are no differences. The script does not inform about
similarities. You can also have a look at the comments in the script itself.
You can find it from your computer and from GitHub
https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/osgeo/utils/gdalcompare.py.

-Jukka Rahkonen-


mhw-at-yg wrote
> Hi,
> 
> How do I find out more info on what the differences are from gdalcompare?
> What does "New: n" mean?
> 
> $ gdalcompare source-image.tif  xxx-001.tif
> Files differ at the binary level.
> Band 1 overview count difference:
>   Golden: 0
>   New:5
> Band 2 overview count difference:
>   Golden: 0
>   New:5
> Band 3 overview count difference:
>   Golden: 0
>   New:5
> Differences Found: 4
> 
> 
> I've used raster math to subtract one image from the other and the result
> is zero in all pixels.
> 
> 
> Matt Wilkie
> Geomatics Analyst
> Environment | Technology, Innovation and Mapping
> T 867-667-8133 | Yukon.ca;
> Hours: 08:30-16:30, Tue-Wed: Office, Thu-Fri: Remote.
> 
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: RFC 78: gdal-utils package

[jratike80]

+0


I have a positive feeling but unfortunately I do not really understand the
topic well enough to say yes or no.

-Jukka Rahkonen-


Idan Miara wrote
> Hi all,
> 
> Having heard no further comments regarding RFC78
> ;.
> 
> Motion:
> 
> Adopt RFC 78: gdal-utils package
> ;
> (formatted
> version).
> 
> *A personal note*
> The points I've mentioned in the motivation section have affected me
> personally - Enough to spend a considerable time to write and
> implement this RFC.
> Other developers and users might be encountering the same issues and thus
> would benefit from this RFC.
> 
> I have contributed a fair amount of Python code to gdal in the past year.
> If you find my contributions to gdal
> ;
> valuable and want me to have more time to further contribute to gdal then
> please accept this RFC even if you don't personally appreciate the
> motinations I've mentioned.
> Otherwise I would need to continue maintaining this branch to workaround
> the issues I've mentioned (which is time consuming by itself because I
> need
> to keep rebasing it and resolve conflicts), thus having less time to
> actually contribute to gdal and improve the gdal-utils modules.
> 
> `gdal-utils` wheels that were built and uploaded by myself to address
> these
> issues are already available in pypi
> ;.
> If this PR is accepted, I will give complete control over this pypi
> package
> to the gdal project owners. Yanking "unofficial" gdal-utils packages is
> accepted if necessary once this motion is passed and the first official
> gdal-utils wheel is released on pypi.
> 
> Idan
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OSGeo.OGR.Geometry: Union the mutiple geometries at a time

[jratike80]

Hi,

I can't imagine any connection between Union and Convex/Concave hull. Union
of the points in the example image is a MultiPoint geometry. The hull is a
single geometry that encloses the input geometries, in this case it is a
polygon. There is no need to consider hulls when doing Union. Generally
hulls are useful things and I believe that GDAL supports convex hull through
GEOS. Convex hull is well defined and there is only one correct solution
when it is computed. It is also included in the OGC Simple Feature standard. 
Concave hulls are not as well defined and different implementations give
different results. If you need concave hull I would recommend PostGIS
https://postgis.net/docs/ST_ConcaveHull.html.

-Jukka Rahkonen- 

 


MRRAJESH wrote
> I am referring to the below image -
> 
> ;
>  
> 
> 
> 
> 
> 
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OSGeo.OGR.Geometry: Union the mutiple geometries at a time

[jratike80]

Hi,

Please explain what do you mean by "Concave Hull-based union geometry".
Union is union as it is defined in the OpenGIS Simple Features
Implementation Specification for SQL 1.1 standard. There is only one
possible correct result from union. The source code is available if you are
interested in how it is implemented. Also this blog post is good reading.
Unfortunately the images do not show directly on browser, probably because
the links use http instead of https.

-Jukka Rahkonen-


MRRAJESH wrote
> Thanks Even. 
> 
> Whether this algorithm internally use Convex Hull or Concave Hull?
> How to get Concave Hull-based union geometry using GDAL?
> 
> Are these functionalities (ogr.CreateGeometryFromWkt..) available with C#
> bindings?
> 
> Regards,
> Rajesh
> 
> 
> 
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_retile: output isn't georeferenced?

[jratike80]

Hi,

Expected behavior is documented in
https://gdal.org/programs/gdal_retile.html.

-s_srs 

Source spatial reference to use. The coordinate systems that can be
passed are anything supported by the OGRSpatialReference.SetFromUserInput()
call, which includes EPSG, PCS, and GCSes (i.e. EPSG:4296), PROJ.4
declarations (as above), or the name of a .prj file containing well known
text. If no srs_def is given, the srs_def of the source tiles is used (if
there is any). The srs_def will be propagated to created tiles (if possible)
and to the optional shape file(s)

-tileIndex 

The name of shape file containing the result tile(s) index

Thus if your infile.tif is reoreferenced the tif tiles should have the same
georeferencing. If they don't you may try to give some help with "-s_srs".
In any case the tiles are indirectly georeferenced by the shapefile index
where georeferenced polygons present the footprints of the tiles and
filename can be found from an attribute field.

-Jukka Rahkonen-




mhw-at-yg wrote
> Is it expected that `gdal_retile -of cog -ps 4096 4096 -t myoutdir
> infile.tif` creates files that are not georeferenced?
> 
> Using Gdal from QGIS 3.16 on Win10.





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] nearblack on multi GB images very slow

[jratike80]

Hi,

Are your multigigabyte originals tiled or striped tiffs?

-Jukka Rahkonen-



mhw-at-yg wrote
> I have a lot of multi GB images that are unfortunately jpeg-in-geotiff
> encoded before nodata was properly defined. As a result they all suffer
> from
> the jagged edges problem.
> ; 
> 
> I've defined a method for adding a nodata mask side-car file that works
> around this: 
> https://gis.stackexchange.com/questions/387877/add-a-nodata-mask-or-alpha-band-to-read-only-image/
> 
>  * Create a working copy de-collared image with a mask file
>  * Rename the mask file to match original
>  * Remove working copy
> 
> Windows command line syntax:
> 
> :::
> nearblack -o xxx.tif -setmask in_image.tif
> move xxx.tif.msk in_image.tif.msk
> del xxx.*
> :::
> 
> Unfortunately nearblack is unusable on large images. With a source image
> of
> 3.9 GB (126015 x 68149 pixels, 3 channels) it was only at 35% after 17
> hours. I forgot about the process and rebooted my machine so I don't know
> how long it would taken to complete, if it would have finished at all.
> 
> I used gdal_retile to break the source into 4096x4096 tiles and ran
> nearblack on those. It finished in under 2 hours for the entire set of 527
> files, but i can't use the result because the tiles aren't georeferenced
> (see other thread). That problem aside, the experiment demonstrates much
> optimization is possible. 
> 
> Any advice on how else I might solve this?
> 
> 
> 
> 
> 
> 
> 
> -
> -Matt
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Vector Tile size change in Ogr2Ogr

[jratike80]

Hi,

Bounds and other metadata are explained in
https://github.com/mapbox/mbtiles-spec/blob/master/1.3/spec.md.

"The metadata table SHOULD contain these four rows:

bounds (string of comma-separated numbers): The maximum extent of the
rendered map area. Bounds must define an area covered by all zoom levels.
The bounds are represented as WGS 84 latitude and longitude values, in the
OpenLayers Bounds format (left, bottom, right, top). For example, the bounds
of the full Earth, minus the poles, would be: -180.0,-85,180,85.

center (string of comma-separated numbers): The longitude, latitude, and
zoom level of the default view of the map. Example: -122.1906,37.7599,11

minzoom (number): The lowest zoom level for which the tileset provides
data"

maxzoom (number): The highest zoom level for which the tileset provides
data

Metadata helps the vector tile client to zoom to correct area, at reasonable
scale. There is no connection with EXTENT. Extent defines the precision of
the local coordinate system that is used within a vector tile. The same
z/x/y tile is always located in the same place on Earth and that location is
defined by the tiling schema. Geometries within a tile are encoded by using
integer numbers starting from (0 0) that is at top left corner. EXTENT
defines the lower right corner in local coordinates and by default it is
(4096 4096).

All this is well described in the vector tile specification
https://github.com/mapbox/vector-tile-spec/tree/master/2.1.

-Jukka Rahkonen-
   


MRRAJESH wrote
> Thank you Even.
> 
> Can you please explain the BOUNDS usage? How it is related to EXTENT?
> 
> Regards,
> Rajesh
> 
> 
> 
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Vector Tile size change in Ogr2Ogr

[jratike80]

--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> Having heard no issues being reported regarding RC1
> 
> Motion:
> 
> Adopt GDAL 3.2.2 RC1 as final 3.2.2 release
> 
> Starting with my +1
> 
> Even
> 
> -- 
> http://www.spatialys.com
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Wiki page with current maintainers per sub-system

[jratike80]

Hi,

I cannot maintain any driver myself but I could be listed as someone who is
willing to sponsor the maintenance work that is needed to keep the OpenJUMP
JML driver alive. Of course it depends on the price, if there are other
users to share the costs, if any service provider or individual is willing
to take the task, and if it is not against what is generally good for the
GDAL project.

-Jukka Rahkonen-



Even Rouault-2 wrote
> Hi,
> 
> following recent discussions about maintenance, I've initiated
> 
> https://github.com/OSGeo/gdal/wiki/Maintainers-per-sub-system
> 
> with "just" drivers and binding languages
> 
> You're invited to check (I've put a few names that I had in mind in 
> front of a few items) and update it.
> 
> Even
> 
> -- 
> http://www.spatialys.com
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GML duplicated FID

[jratike80]

Hi,

It would be interesting to know how you manage to generate duplicate fids
with Geoserver but perhaps it is better to discuss about that in
geoserver-users.

-Jukka Rahkonen-


Martin Landa wrote
> Hi all,
> 
> I have an issue with GML generated by GeoServer. There are features
> with duplicated FID:
> 
> ```
> OGRFeature(lucas_view):36
>   gml_id (String) = lucas_view.fid--269ff1b9_177af2abc34_-36e6
>   point_id (Integer) = 45502976
>   nuts0 (String) = CZ
>   POINT (455 2976000)
> OGRFeature(lucas_view):36
>   gml_id (String) = lucas_view.fid--269ff1b9_177af2abc34_-36e5
>   point_id (Integer) = 45542918
>   nuts0 (String) = CZ
>   POINT (4554000 2918000)
> ```
> 
> This is a reason why converting such data into GPKG (using
> CopyLayer()) fails with:
> 
> ```
> ERROR 1: failed to execute insert : UNIQUE constraint failed: layer.fid
> ```
> 
> Is there any way to force the GML driver to generate a unique FID
> instead of guessing from  gml_id?
> 
> Thanks in advance, Martin
> 
> -- 
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion (V2): remove and deprecate a few drivers

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> Updating my yesterday motion with the feedback received (only second 
> bullet updated with a more restricted set of drivers)
> 
> Motion:
> 
> - remove the vector drivers BNA, AeronavFAA, HTF, OpenAir, SEGUKOOA, 
> SEGY, SUA, XPlane and raster drivers BPG, E00GRID, EPSILON, 
> IGNFHeightASCIIGrid, NTv1. They have all been authored by myself and I'm 
> not aware of them having been much used or being still in use. 
> Implemented in https://github.com/OSGeo/gdal/pull/3373. They (driver 
> code, doc and tests) have been moved to the 
> https://github.com/OSGeo/gdal-extra-drivers
> 
> - deprecate the raster drivers DODS, JPEG2000 (superseded per 
> JP2OpenJPEG), JPEGLS, MG4LIDAR, FUJIBAS, IDA, INGR, ZMAP and vector 
> driver ARCGEN, ArcObjects, CLOUDANT, COUCHDB, DB2, DODS, FME, GEOMEDIA, 
> GTM, INGRES, MONGODB (superserded per MongoDBV3), REC, WALK . They will 
> now be disabled at runtime by default, with an explicit error message 
> when they are triggered, unless the 
> GDAL_ENABLE_DEPRECATED_DRIVER_{drivername}
> configuration option is set to YES, and will be removed in GDAL 3.5. 
> Implemented in https://github.com/OSGeo/gdal/pull/3505
> 
> Starting with my +1
> 
> Even
> 
> -- 
> http://www.spatialys.com
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Unexpected behavior on gdal2tiles.py

[jratike80]

Hi,

Tiles created by gdal2tiles are never georeferenced directly but only
through the tileset definition. I had a try with your coordinate system with
raster profile and by looking at the generated tilemapresource.xml it seems
to me that the tileset is correct and tiles georeferenced right. Client that
reads the tilemaprerource.xml or that is configured manually to use the same
tileset should show correct coordinate, including a knowledge that the tiles
are from Mars.



http://tms.osgeo.org/1.0.0";>
  mars.tif
  
 
GEOGCS["GCS_Mars_2000",DATUM["D_Mars_2000",SPHEROID["Mars_2000_IAU_IAG",3396190,169.894447223612]],PRIMEM["Reference_Meridian",0],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AXIS["Latitude",NORTH],AXIS["Longitude",EAST]]
  
  
  
  


  ...
  



-Jukka Rahkonen-


erentar2002 wrote
> If i use raster, the resulting tiles are not georeferenced, i.e the
> {x},{y},{z} coordinates are not correct. I require them to be
> georeferenced. Do you know of another tool that would let me render
> georeferenced tiles for mars?





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL SVG to BMP conversion

[jratike80]

Hi,

You can test it with any SVG file

ogrinfo matplotlib.svg --debug on
...
SVG: matplotlib.svg seems to be a SVG file, but not a Cloudmade vector one.
...

I recommend to use some other tools.

-Jukka Rahkonen-


Shaw, Theodore wrote
> I'm attempting to convert SVG files output by Gdspy to large BMPs, 
> approximately 50,000 x 50,000 pixels. This documentation page 
> https://gdal.org/drivers/vector/svg.html looks like it says that GDAL 
> only supports SVG files that are the output of Cloudmade Vector Stream 
> Server. Am I understanding correctly that I won't be able to use GDAL 
> for this task?
> 
> Thank you very much.
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Unexpected behavior on gdal2tiles.py

[jratike80]

Hi,

By looking at the messages the installation on Machine B has an error: "It
[means proj.db] comes from another PROJ installation." Because of that error
gdal2tiles "works". If you fix the installation on Machine B it will fail
for the same reason than Machine A: "Cannot find coordinate operations from
[something in Mars] to EPSG:4326 [that is in Tellus].

I believe that you must fool gdal2tiles somehow and make it to believe that
the source data are also from our planet. Unfortunately I don't know how.
But does it even make sense to project data from Mars into EPSG:4326?
Perhaps "-p raster" would create something usable.

-Jukka Rahkonen-



erentar2002 wrote
> Machine A:
> 
> user@machineA:~/mars$ gdal2tiles.py -z 6-8 -p geodetic -v debris.jp2
> Options: {'profile': 'geodetic', 'resampling': 'average', 's_srs': None,
> 'zoom': '6-8', 'resume': False, 'srcnodata': None, 'tmscompatible': None,
> 'xyz': None, 'verbose': True, 'exclude_transparent': None, 'quiet': None,
> 'nb_processes': None, 'tilesize': 256, 'kml': False, 'url': '',
> 'webviewer': 'all', 'title': 'debris.jp2', 'copyright': '', 'googlekey':
> 'INSERT_YOUR_KEY_HERE', 'bingkey': 'INSERT_YOUR_KEY_HERE',
> 'mapml_template': None, 'processes': 1}
> Input: debris.jp2
> Output: debris
> Cache: 1604.5949211120605 MB
> 
> Begin tiles details calc
> Input file: ( 29232P x 20669L - 4 bands)
> NODATA: []
> Preprocessed file: ( 29232P x 20669L - 4 bands)
> ERROR 1: PROJ: proj_create_operations: Source and target ellipsoid do not
> belong to the same celestial body
> ERROR 6: Cannot find coordinate operations from
> `GEOGCRS["GCS_Mars_2000",DATUM["D_Mars_2000",ELLIPSOID["Mars_2000_IAU_IAG",3396190,169.894447223612,LENGTHUNIT["metre",1,ID["EPSG",9001,PRIMEM["Reference_Meridian",0,ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9122]]],CS[ellipsoidal,2],AXIS["latitude",north,ORDER[1],ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9122]]],AXIS["longitude",east,ORDER[2],ANGLEUNIT["degree",0.0174532925199433,ID["EPSG",9122'
> to `EPSG:4326'
> Traceback (most recent call last):
>   File "/usr/bin/gdal2tiles.py", line 3242, in sys.exit(main(sys.argv))
> File "/usr/bin/gdal2tiles.py", line 3234, in
> main single_threaded_tiling(input_file, output_folder, options) File
> "/usr/bin/gdal2tiles.py", line 3154, in single_threaded_tiling conf,
> tile_details = worker_tile_details(input_file, output_folder, options)
> File "/usr/bin/gdal2tiles.py", line 3070, in worker_tile_details
> gdal2tiles.open_input() File "/usr/bin/gdal2tiles.py", line 1742, in
> open_input self.warped_input_dataset =
> update_alpha_value_for_non_alpha_inputs( File "/usr/bin/gdal2tiles.py",
> line 1061, in update_alpha_value_for_non_alpha_inputs if
> warped_vrt_dataset.RasterCount in [1, 3]: AttributeError: 'NoneType'
> object has no attribute 'RasterCount'
> 
> Machine B:
> 
> user@machineB:~/mars$ gdal2tiles.py -z 6-8 -p geodetic -v debris.jp2
> Options: {'profile': 'geodetic', 'resampling': 'average', 's_srs': None,
> 'zoom': '6-8', 'resume': False, 'srcnodata': None, 'tmscompatible': None,
> 'xyz': None, 'verbose': True, 'exclude_transparent': None, 'quiet': None,
> 'nb_processes': None, 'tilesize': 256, 'kml': False, 'url': '',
> 'webviewer': 'all', 'title': 'debris.jp2', 'copyright': '', 'googlekey':
> 'INSERT_YOUR_KEY_HERE', 'bingkey': 'INSERT_YOUR_KEY_HERE', 'processes': 1}
> Input: debris.jp2
> Output: debris
> Cache: 384.14570236206055 MB
> 
> Begin tiles details calc
> Input file: ( 29232P x 20669L - 4 bands)
> NODATA: []
> Preprocessed file: ( 29232P x 20669L - 4 bands)
> ERROR 1: PROJ: proj_create_from_database:
> /home/user/OTB-7.2.0-Linux64/share/proj/proj.db lacks
> DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It
> comes from another PROJ installation.
> Projected file: tiles.vrt ( 29232P x 20669L - 4 bands)
> ERROR 1: PROJ: proj_create_from_database:
> /home/user/OTB-7.2.0-Linux64/share/proj/proj.db lacks
> DATABASE.LAYOUT.VERSION.MAJOR / DATABASE.LAYOUT.VERSION.MINOR metadata. It
> comes from another PROJ installation.
> KML autotest OK!
> Bounds (output srs): 77.42551250577 18.429672337269487 77.47613730177316
> 18.465467490135833
> Bounds (latlong): 77.42551250577002 18.429672337269487 77.47613730177316
> 18.465467490135833
> Generating Base Tiles:
> 
> Tiles generated from the max zoom level:
> 
> 
> dataBandsCount:  3
> tilebands:  4
> 1 / 1 debris/8/183/77.png
>   Native Extent (querysize 76443 ):  (0, 0, 29232, 20669) (47211, 705631,
> 29232, 20669)
> Tiles details calc complete.
>   ReadRaster Extent:  (0, 0, 29232, 20669) (59, 889, 36, 26)
> Generating Overview Tiles:
> 01 / 2 debris/7/91/38.png
>   build from zoom 8  tiles: (182, 76) (183, 76) (182, 77) (183, 77)
> 2 / 2 debris/6/45/19.png
>   build from zoom 7  tiles: (90, 38) (91, 38) (90, 39) (91, 39)
> 
> Why does this succeed in machine B and fail in machine A with identical
> inputs?
> 
> both machines run fresh copies 

Re: [gdal-dev] New JPEG 2000 Driver

[jratike80]

Hi,

In my opinion it is GDAL's mandate to favor projects that use the same type
of license than GDAL itself. Both proprietary and more copy-left licenses
makes it a bit harder to handle the whole system. Individual developers may
have their own opinions about what licensing model is the best when it comes
to principles, but I would rather see GDAL as a project to be neutral "We
prefer BSD, but we respect also libraries with other licensing models. To
respect does not mean that we want all of them incorporated". 

If a project selects BSD it is clear from the beginning that anything that
is allowed by the license may happen. 

I don't agree that GDAL supports proprietary drivers more than copy-left
drivers. We have told you that it is quite OK to have a new JP2Grok even we
would prefer to see improvements in JP2OpenJPEG because it is BSD like the
rest of GDAL. And that we are a bit sad because of AGPL and there are users
who can't use Grok, but nothing harder than that. That we prefer BSD is
consistent to our message to the MapInfo team that suggested to add a new
proprietary driver https://github.com/OSGeo/gdal/pull/3447.

To suggest that we should remove all existing proprietary drivers if we are
not very eager in accepting one more JPEG2000 driver is obviously meant to
be a provocation but I do not know how to react.

GDAL project does not easily drop existing good drivers which have an
established user base. We may drop JP2KAK some day because it is not really
actively maintained but it is quite a good driver even it does not utilize
some improvements introduced in latest latest KDU SDK versions. So perhaps
it is kept as long as it is possible to compile. If Kakadu was open source
we would be in the situation that you described "If driver A is faster and
more feature rich than driver B, they will want driver A." Unfortunaly very
few users can afford to select driver A in this case.

We do remove old drivers https://github.com/OSGeo/gdal/pull/3505 and it
means goodbye to Jasper.

-Jukka Rahkonen-


boxerab wrote
> Hi Brad,
> 
> Definitely makes for an interesting discussion.
> 
> A few questions to ponder:
> 
> Is it GDAL's mandate to encourage projects with permissive licenses and
> to,
> shall we say,
> discourage those with copy-left licenses ? This is how Google and Apple
> operate,
> but they are for-profit corporations who clearly have a vested interest in
> permissive open source.
> GDAL is a non-profit, open source project. Also, most GDAL users are not
> GDAL developers,
> and many of these users have no strong feelings about licensing as long as
> they can get their work done.
> If driver A is faster and more feature rich than driver B, they will want
> driver A.
> 
> Is it legitimate to take OpenJPEG, close the source, improve the code and
> add features,
> and then sell the result without contributing these improvements back to
> OpenJPEG?
> Indeed, it is legitimate, permitted, and encouraged by the BSD license.
> And
> many have
> done so. Likewise with relicensing under a different FLOSS license, as
> long
> as BSD terms are
> respected.
> 
> If GDAL supports proprietary drivers but rejects open source drivers
> because they are copy-left,
> this doesn't seem consistent to me. Perhaps all proprietary drivers should
> be removed, if
> that is the desire of the project? Keeping JP2KAK and rejecting JP2Grok
> seems a bit hard
> to fathom to me.
> 
> As for proliferation of driver code, the Jasper driver seems to be on the
> way out, as Jasper
> code is dangerously insecure and filled with bugs. So, JP2Grok would
> simply
> take its place.
> 
> My two cents.
> 
> Aaron
> 
> 
> On Sun, Feb 28, 2021 at 8:15 PM Brad Hards <

> bradh@

> > wrote:
> 
>> I think this will be an interesting issue for the GDAL PMC.
>>
>> On one hand, AGPL is no worse than some proprietary (optional) dependency
>> libraries. On the other hand, supporting it in GDAL is
>> implicitly endorsing the fork, and adds to the proliferation of driver
>> code in the GDAL/OGR repository. I think this could
>> reasonably be decided either way.
>>
>> Brad
>>
>>
>> ___
>> gdal-dev mailing list
>> 

> gdal-dev@.osgeo

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

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] New JPEG 2000 Driver

[jratike80]

Greg Troxel-2 wrote
> Even Rouault <

> even.rouault@

> > writes:
> 
>> Can you transparently tell us why Grok is AGPL licensed ? Do you sell 
>> commercial licenses for people who couldn't comply with the AGPL license
>> ? 
> 
> Certainly a good question.  I have no idea in this case and my comments
> should not be taken to imply anything about this particular library

Hi,

I had a feeling that I have seen this discussion before. And indeed, I would
say it started in December, 2015 from this mail
https://lists.osgeo.org/pipermail/gdal-dev/2015-December/043296.html. There
are a few more threads to read in January, 2016, and the reason for AGPL was
announced in February 3rd 2016 in mail "Fork Yeah!"
https://lists.osgeo.org/pipermail/gdal-dev/2016-February/043649.html.

Aaron Boxer wrote:
"The code is licensed under the AGPL, to ensure that all code modifications
get contributed back to the community."

Later Aaron gave clear answers to some follow-up questions:

"> The use of AGPL means that your OpenJPEG fork will not be used for
> commercial projects and any enhancements you make will not make there way
> into OpenJPEG.
>
Correct.
>
> You may have a good reason for choosing this licence and as such it is
> your choice.
>
Yes.
>
> Either way good luck.
>
Thank you."


I do not know how much has changed during these five years. Grok is probably
better now but I think that JPEG2000 gives biggest benefits for medical
imaging and motion pictures which are both in a way volumetric, but codecs
compressing in 3D need to be even more sophisticated. With traditional GIS
imagery OpenJPEG is rather good nowadays if data producers play the same
game and do not create their images in the hardest possible way. But I
welcome the new driver if it will have a maintainer and if it does not mean
more pain for the main developers and users who do not need Grok.

-Jukka Rahkonen-






--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC79: Listing of Service Providers on GDAL website

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> I motion to adopt RFC79: Listing of Service Providers on GDAL website:
> https://github.com/OSGeo/gdal/pull/3473
> 
> Starting with my +1
> 
> Even
> 
> -- 
> http://www.spatialys.com
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

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


Even Rouault-2 wrote
> Hi,
> 
> I motion to adopt RFC79: Listing of Service Providers on GDAL website:
> https://github.com/OSGeo/gdal/pull/3473
> 
> Starting with my +1
> 
> Even
> 
> -- 
> http://www.spatialys.com
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] The proper way to call gdal "scripts" on Windows?

[jratike80]

Hi,

OSGeo4W creates .bat file for each Python script. As an example
gdal_calc.bat:

@echo off 
call "%OSGEO4W_ROOT%\bin\o4w_env.bat" 
python "%OSGEO4W_ROOT%\bin\gdal_calc.py" %* 

o4w_env.bat launches a bunch of other .bat files. Have a look and be
astonished! One of those sets Python:

SET PYTHONHOME=%OSGEO4W_ROOT%\apps\Python27
PATH %OSGEO4W_ROOT%\apps\Python27\Scripts;%PATH%


-Jukka Rahkonen-



Idan Miara wrote
> Richard - I'm not sure which batch files you were referring to, which gdal
> distribution created gdal_calc.bat files for you?





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
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 79: Listing of Service Providers on GDAL website

[jratike80]

GDAL - Dev mailing list wrote
> Hi Even,
> 
> On Tue, Feb 23, 2021 at 2:56 AM Even Rouault <

> even.rouault@

> >
> wrote:
> 
>> Hi,
>>
>> Please find https://github.com/OSGeo/gdal/pull/3473 which proposes to
>> list
>> service providers offering GDAL related services on the GDAL website. As
>> mentioned in the RFC, this is a straightfoward port of the equivalent
>> adopted
>> RFC of the Mapserver project.
>>
>> Even
>>
> 
> I'd like to hear more about the Mapserver project service provider list.
> Does it work? Is it kept up to date or does it get stale? Does the
> community find that it effectively steers $$ to consultants that fix bugs
> and maintain the project? With the difference in image/logo sizes, is the
> intent to make this look a bit like a conference sponsor page?
> 
> -- 
> Sean Gillies


Hi,

Maybe the number of new potential customers searching for consultants to do
Mapserver development is not so huge at the moment and the old ones know
their contacts already. However, I feel that the service provider list does
work for the Geoserver project. Probably mostly not so that users start by
browsing the list and pick a contractor. It is rather so that core Geoserver
developers know that often there is a minimal chance that some bug will be
fixed or some feature request will be implemented just because there is an
open ticket about that. Then they can inform the user about the reasonable
alternatives like in this example that I picked from a mailing list:
 
"That does not mean we cannot work around a deficiency in a rogue server,
but be prepared to issue your PR or fund development though commercial
services: http://geoserver.org/support/";

For my mind that is also fair for the users and gives more hope than the
comment on the OSSIM site, that is otherwise my absolute favorite:

"We encourage users to use the software as-is or become an active
contributor."

-Jukka Rahkonen-




--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] warp ARGB -> RGB gtiff-jpeg?

[jratike80]

Hi,

It is very cheap to use gdal_translate and VRT as intermediate format. As
far as I know it is not possible to drop alpha with gdalwarp even it is
possible to add alpha -dstalpha.

-Jukka Rahkonen-



Idan Miara wrote
> Hi All,
> 
> Is it possible to use gdal_warp for warping the RGB bands of an ARGB
> raster
> as gtiff with jpeg compression (i.e. to drop the Alpha channel and
> transform CRS). ?
> 
> gdal_transalte has translate_options["bandList"] = [1, 2, 3] for that, but
> I can't find the equivalent for warp.
> 
> I could do it in two steps - save as a lossless gtiff and then use
> gdal_transalte to make a jpeg-gtiff. Or use gdal_trasnlate to make a 3
> band
> lossless gtiff and then wrap it.
> 
> Can I do it in one step without an intermediate file?
> 
> Regards,
> Idan.
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Requesting a transparent image from a WMS server...

[jratike80]

Hi,

Try 

gdal_translate
"WMS:https://maps-public.geo.nyu.edu:443/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=sdr%3Anyu_2451_43745&SRS=EPSG:4326&BBOX=-119.265762329102,35.2621765136719,-118.825294494629,35.4424705505371&format=image/png&transparent=TRUE";
service.xml -of WMS

Notice the the format must be something that supports transparency so
image/jpeg does not work.

-Jukka Rahkonen-



Carl Godkin-2 wrote
> Hi,
> 
> I'm generating WMS service description files as described here:
> https://gdal.org/drivers/raster/wms.html#generation-of-wms-service-description-xml-file
> 
> This works well, but I wonder if there's a way to request the image from
> the WMS server to be transparent.
> 
> If I use gdal_translate to create the WMS service description file like
> this:
> 
> gdal_translate "WMS:
> https://maps-public.geo.nyu.edu:443/geoserver/wms?SERVICE=WMS&VERSION=1.1.1&REQUEST=GetMap&LAYERS=sdr%3Anyu_2451_43745&SRS=EPSG:4326&BBOX=-119.265762329102,35.2621765136719,-118.825294494629,35.4424705505371";
> service.xml -of WMS
> 
> then I get this:
> 
>   
> 
> 
> 
> 1.1.1
> 
> 
> 
> https://maps-public.geo.nyu.edu:443/geoserver/wms?SERVICE=WMS
> 
> 
> 
> sdr%3Anyu_2451_43745
> 
> 
> 
> EPSG:4326
> 
> 
> 
> image/jpeg
> 
> 
> 
> FALSE
> 
> 
> 
> xyXY
> 
>   
> 
>   
> 
> 
> 
> -119.265762329102
> 
> 
> 
> 35.4424705505371
> 
> 
> 
> -118.825294494629
> 
> 
> 
> 35.2621765136719
> 
> 
> 
> 1073741824
> 
> 
> 
> 439508252
> 
>   
> 
>   
> 
> 3
> 
>   
> 
> 1024
> 
>   
> 
> 1024
> 
>   
> 
> 20
> 
> 
> I have discovered that if I slightly edit three lines the service
> description like this:
> 
> 
> 
> image/geotiff
> 
> 
> 
> TRUE
> 
>  
> 
> 4
> 
> then my output image is transparent if I compare these two output files:
> 
> gdal_translate -outsize 512 512 -projwin -119.1 35.4 -119 35.3 service.xml
> bakersfield.tif
> gdal_translate -outsize 512 512 -projwin -119.1 35.4 -119 35.3
> service_trans.xml bakersfield_trans.tif
> 
> Are there some options I can use in the first gdal_translate command above
> to generate the WMS description file so that
> it retrieves transparent images if the server supports transparency?
> 
> (I am actually creating the service description file in C++ code using
> CreateCopy, but I believe it's easy to prototype with the CLI.)
> 
> Thanks very much,
> 
> carl
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] break a bounding box into smaller boxes

[jratike80]

Hi,

Ok, so obviously you are talking about WFS service, not WMS.

Why don't you use paging with COUNT and STARTINDEX
https://www.mapserver.org/ogc/wfs_server.html?

-Jukka Rahkonen-




MRRAJESH wrote
> We are expecting feature information from our own map server for a given
> BBOX. At present we are limited to 500 features is the max limit. But as
> per
> our requirement, we want to return a huge number of features from the
> server. So we are planning to split the BBOX into multiple boxes and hit
> the
> server and get the features. Any other approach better than this? In the
> case of BBox, how to split the bboxes into multiple. Any libraries?
> 
> 
> 
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] break a bounding box into smaller boxes

[jratike80]

Hi,

I would guess that Mapserver does not care about your BBOX but by the same
you create GetMap requests with &WIDTH= and &HEIGHT= that exceeds the limit
that is configured on the server with MAP-MAXSIZE
https://mapserver.org/mapfile/map.html.

So you must split your requests smaller by the requested pixels. For example
GDAL can do that automatically with the WMS driver
https://gdal.org/drivers/raster/wms.html. Have a look at
BlockSizeX/BlockSizeY.

-Jukka Rahkonen-



MRRAJESH wrote
> Hi,
> 
> We have large area bbox coordinates. When we hit with this BBOX, MapServer
> is not able to handle the bigger size bbox values. 
> 
> We are planning to split the bigger bbox into multiple bboxes and send
> them
> to the map server for features data. Any library or sample code to break a
> bounding box into smaller boxes (coordinates)?
> 
> Regards,
> Rajesh
> 
> 
> 
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Create cloud optimized geotiff without re-encoding?

[jratike80]

Hi,

I made a couple of simple tests by following
https://trac.osgeo.org/gdal/wiki/CloudOptimizedGeoTIFF, here are the
results:

Create a jpeg compressed GeoTIFF and couple of overviews

gdal_translate -of GTiff -co tiled=yes -co compress=jpeg p4433h.tif
p2-jpeg.tif
gdaladdo --config COMPRESS_OVERVIEW JPEG p2-jpeg.tif 2 4

Test how the main image and overviews behave

gdal_translate -co tiled=yes -co COPY_SRC_OVERVIEWS=YES p2-jpeg.tif
cog21.tif
gdal_translate -co tiled=yes -co compress=jpeg -co COPY_SRC_OVERVIEWS=YES
p2-jpeg.tif cog22.tif  

Check file sizes:

575 913 074 cog21.tif
131 203 903 cog22.tif

Both images have 2 overviews and obviously the full resolution data are not
copied. I believe that it means that the jpeg compressed tiles are
uncompressed and processed again that leads into quality loss just as you
feared.

What I do not understand is what gdalcompare reports.

gdalcompare p2-jpeg.tif cog21.tif
Files differ at the binary level.
Differences Found: 1

This is understandable, the main tiles are jpeg compresses vs. uncompressed
so they are not the same. However, pixels are the same because jpeg is
converted into uncompressed with no loss.  But then, this is the beginning
of the report about original and jpeg-compressed with overviews copied.

gdalcompare p2-jpeg.tif cog28.tif
Files differ at the binary level.
Band 1 checksum difference:
  Golden: 30664
  New:57443
  Pixels Differing: 62249009
  Maximum Pixel Difference: 13.0
Band 1 overview 0 checksum difference:
  Golden: 19959
  New:54816
  Pixels Differing: 28090066
  Maximum Pixel Difference: 39.0
Band 1 overview 1 checksum difference:
  Golden: 5318
  New:34525
  Pixels Differing: 8059334
  Maximum Pixel Difference: 75.0
... more bands ...


So not only the full resolution images differ but also the overviews even
they should be just copied.  I got similar results also when I used "cog" as
outputformat, and with GDAL versions 3.14 and 3.3.0. The cog driver creates
two overviews just as documented (the AUTO overview option) but gdalcompare
reports pretty large differences in pixel values.

Maybe you could just try to use your existing jpeg-in-geotiff images in
cloud. They may behave rather well even the reading application must read a
little bit more bytes from that GeoTIFF structure.

-Jukka Rahkonen-




mhw-at-yg wrote
> Hi Folks,
> 
> I have a lot of jpeg-in-geotiff imagery that I would like to convert to
> Cloud Optimized Geotiff. Is there any way to do that without re-encoding
> the
> pixel values?
> 
> I'm trying to avoid paying the price of:
> 
> * lossy + lossy compression that results from feeding a jpeg source to
> a
> jpeg output file, and
> * lossy + lossless that comes from feeding a jpeg source to lossless
> output file, which means x4+ storage requirements
> 
> -Matt
> 
> (x-posted to GIS Stack Exchange,
> https://gis.stackexchange.com/questions/387632)
> 
> 
> 
> -
> -Matt
> --
> Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] How I get a list of CRS supported for a WMS service with gdal?

[jratike80]

Hi,

GDAL is not made to build a CRS list. See
https://gdal.org/drivers/raster/wms.html
"[CRS] Image projection (optional, defaults to EPSG:4326, WMS version 1.3.0
or above only)"

You can get the full list from GetCapabilities that you fetch by other means
and write one of the supported codes into CRS element. Then GDAL will use
that CRS in the GetMaps that it is sending. I believe that then also the
DataWindow must be edited to have numbers that match with the selected CRS
but I am not sure about that. You are lucky because the server you are
playing with seems to advertise bounding boxes also for the other CRSs.

GDAL is using the configured CRS when it sends GetMaps and reprojects image
data if needed into other CRS. If you configure GDAL to use the same CRS
that you want for the output you will avoid reprojection and the quality is
probably better.

-Jukka Rahkonen-




Elena Ruiz wrote
> Hello, when I run the next command:
> gdalinfo
> "WMS:http://wms.mapa.es/wms/wms.aspx?service=WMS&request=GetCapabilities";
> 
> the request is:
> 
> Driver: WMS/OGC Web Map Service
> Files: none associated
> Size is 512, 512
> Subdatasets:
>  
> SUBDATASET_1_NAME=WMS:http://wms.mapama.gob.es/wms/wms.aspx?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYERS=ARBOLES&SRS=EPSG:4326&BBOX=-18.1705,27.6374,4.3169,43.7722
>   SUBDATASET_1_DESC=Arboles
>  
> SUBDATASET_2_NAME=WMS:http://wms.mapama.gob.es/wms/wms.aspx?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYERS=RECINTO&SRS=EPSG:4326&BBOX=-18.1705,27.6374,4.3169,43.7722
>   SUBDATASET_2_DESC=Recintos
>  
> SUBDATASET_3_NAME=WMS:http://wms.mapama.gob.es/wms/wms.aspx?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYERS=PARCELA&SRS=EPSG:4326&BBOX=-18.1705,27.6374,4.3169,43.7722
>   SUBDATASET_3_DESC=Parcelas
>  
> SUBDATASET_4_NAME=WMS:http://wms.mapama.gob.es/wms/wms.aspx?SERVICE=WMS&VERSION=1.1.0&REQUEST=GetMap&LAYERS=ORTOFOTOS&SRS=EPSG:4326&BBOX=-18.1705,27.6374,4.3169,43.7722&TRANSPARENT=FALSE
>   SUBDATASET_4_DESC=Ortofotos
> Corner Coordinates:
> Upper Left  (0.0,0.0)
> Lower Left  (0.0,  512.0)
> Upper Right (  512.0,0.0)
> Lower Right (  512.0,  512.0)
> Center  (  256.0,  256.0)
> 
> But if you put
> http://wms.mapa.es/wms/wms.aspx?service=WMS&request=GetCapabilities, in a
> explorer the request is:
> ...
> 
> Sigpac
> 
> 
> EPSG:4326
> 
> 
> EPSG:4258
> 
> 
> EPSG:32627
> 
> 
> EPSG:32628
> 
> 
> EPSG:32629
> 
> 
> EPSG:32630
> 
> 
> EPSG:32631
> 
> 
> EPSG:25827
> 
> 
> EPSG:25828
> 
> 
> EPSG:25829
> 
> 
> EPSG:25830
> 
> 
> EPSG:25831
> 
> 
> EPSG:3857
> 
> 
> 
> -22.729594
> 
> 
> 5.836872
> 
> 
> 25.912170
> 
> 
> 45.945160
> 
> 
>  maxy="43.7722"/>
>  maxy="45.2862"/>
>  maxy="500"/>
>  maxy="3258000"/>
>  maxx="849792.29" maxy="4847198.99"/>
>  maxx="841149.7" maxy="4836742.49"/>
>  maxx="692667.7" maxy="4747696.68"/>
>  maxy="500"/>
>  maxy="3258000"/>
>  maxx="849792.29" maxy="4847198.99"/>
>  maxx="841149.7" maxy="4836742.49"/>
>  maxx="692667.7" maxy="4747696.68"/>
>  maxy="560"/>
> ...
> Therefore, when I use GDAL only get the first CRS that this WMS service
> support, but in the web this service offers 13 differents CRS, How I get a
> list of the CRS of this service that really supports?
> 
> Thanks you, and regards
> 
> 
> 
> 
> [https://www.aplitop.com/descargas/firma1.jpg]
> 
> 
> Elena Ruiz
> Sofware Development & Technical Support
> Tel. +34 952 43 97 71

> eruiz@

> Sumatra, 9 - 29190 M?laga (Spain)
> www.aplitop.com
> 
> [cid:SocialLink_Facebook_32x32_a745adb8-c250-4372-8480-e77f503dad3d.png];
>   
> [cid:SocialLink_Twitter_32x32_858247f6-9d4a-4740-a6b3-9b5ebfd98a97.png]
> ;   
> [cid:SocialLink_Linkedin_32x32_154d63de-bf68-468f-9eb0-ffed102fac77.png]
> ;   
> [cid:SocialLink_Youtube_32x32_0dea15dd-3774-4086-be9d-f62560b70c86.png]
> ;
> 
> 
> In accordance with the provisions of the European Regulation of Data
> Protection 2016/679 (Reglamento Europeo de Protecci?n de Datos 2016/679),
> we inform you that the data and the information you provide us through
> this medium will be used by APLITOP, S.L., with C.I.F. B-92543396 and with
> address at C / Sumatra, 9, Malaga, 29190, in order to answer your
> questions and inform you about our products. The data provided will be
> kept as long as it does not request its cessation and will not be
> transferred to third parties except in cases where there is a legal
> obligation. You have the right to access your personal data, correct
> inaccurate data or request its deletion when the data is no longer
> necessary for the purposes that were collected, as well as any rights
> recognized in the RGPD 2016/679
> 
> ;
> 
> 
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

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

Re: [gdal-dev] WMTS services error

[jratike80]

Some more information into this issue.

The server at IGN is obviously a GeoServer. GDAL usually does not have any
trouble with GeoServers. Try for example

gdal_translate
"http://demo.geo-solutions.it/geoserver/gwc/service/wmts?REQUEST=GetCapabilities";
-of WMTS geoserver.xml

No errors with that URL. Conclusion: there must be some difference. By
comparing the GetCapabilities responses there seems to be one here:

GeoServer at Geosolutions:


  EPSG:4326
  urn:ogc:def:crs:EPSG::4326
  
EPSG:4326:0
2.795411320143589E8
90.0 -180.0

GeoServer at IGN:


 EPSG:4326
 EPSG:4326
 #commented out! --  crs="urn:ogc:def:crs:EPSG::4326"  -->
 
   EPSG:4326:0
   2.795411320143589E8
   90.0 -180.0

IGN has changed the SupportedCRS from urn:ogc:def:crs:EPSG::4326 (that works
with GDAL) into EPSG:4326 (that does not work with GDAL).

Travis did find this note from the OGC standard:

"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"

Ok, GeoServer seems to one of those implementers. Now there is a question
what was the alternative. In the standard the CRS used in "World CRS84 Quad
TileMatrixSet definition" is 

CRS: http://www.opengis.net/def/crs/OGC/1.3/CRS84, CRS84

Final conclusion:
OGC has defined http://www.opengis.net/def/crs/OGC/1.3/CRS84 for the
longitude-latitude order and http://www.opengis.net/def/crs/EPSG/0/4326 for
the latitude-longitude order. For some reason IGN wants to use a third
alternative EPSG:4326, also for latitude-longitude order. This is something
that is undefined in the standard. I would say that the bug is on the IGN
side and I would like to know what problem they have had with
http://www.opengis.net/def/crs/EPSG/0/4326.

What GDAL might do better is to have an option to flip the axes with the
WMTS XML definition file.

-Jukka Rahkonen-




jratike80 wrote
> 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&service=WMTS&version=1.0.0
> 
>   
> 
> OI.OrthoimageCoverage
> 
>   

>   
> 
> EPSG:4326
> 
>   
> 
> 
> 
> -180
> 
> 
> 
> 90
> 
> 
> 
> 180
> 
> 
> 
> -90
> 
>   
> 
>   
> 
> 3
> 
>   
> 
>   
> 
> true
> 
>   
> 
> 404
> 
>   
> 
> true
> 
> 
> -Jukka-
> 
> Lähettäjä: Travis Kirstine <

> traviskirstine@

> >
> Lähetetty: perjantai 12. helmikuuta 2021 20.43
> Vastaanottaja: Rahkonen Jukka (MML) <

> jukka.rahkonen@

> >
> Kopio: gdal dev <

> gdal-dev@.osgeo

> >
> 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&service=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 <

> jukka.rahkonen@

> <mailto:

> jukka.rahkonen@

> >> 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 cas

Re: [gdal-dev] WMTS services error

[jratike80]

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 *
>>
>>
>>
>> ;
>>
>> ;
>>
>>
>>
>>
>>
>> *De:* Travis Kirstine <

> traviskirstine@

> >
>> *Enviado el:* jueves, 11 de febrero de 2021 20:20
>> *Para:* Elena Ruiz <

> eruiz@

> >
>> *CC:* 

> 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&service=WMTS,layer=OI.OrthoimageCoverage,tilematrixset=EPSG:4326";
>> d://wmts_bm.xml -of WMTS
>>
>> ERROR 1: Invalid dataset dimensions : -135056383 x -167901439
>>
>>
>>
>> gdal_translate "WMTS:
>> http://www.ign.es/wmts/pnoa-ma?request=GetCapabilities&service=WMTS,layer=OI.OrthoimageCoverage,tilematrixset=EPSG:25830";
>> d://wmts_bm.xml -of WMTS
>>
>> Input file size is 20616192, 26817505
>>
>>
>>
>> In this server http://www.ign.es/wmts/pnoa-ma have available the next SRS
>> :
>>
>> SUBDATASET_1_NAME=WMTS:
>> http://www.ign.es/wmts/pnoa-ma?request=GetCapabilities&service=WMTS,layer=OI.OrthoimageCoverage,tilematrixset=InspireCRS84Quad
>>
>> SUBDATASET_2_NAME=WMTS:
>> http://www.ign.es/wmts/pnoa-ma?request=GetCapabilities&service=WMTS,layer=OI.OrthoimageCoverage,tilematrixset=EPSG:4326
>>
>> SUBDATASET_3_NAME=WMTS:
>> http://www.ign.es/wmts/pnoa-ma?request=GetCapabilities&service=WMTS,layer=OI.OrthoimageCoverage,tilematrixset=EPSG:4258
>>
>> SUBDATASET_4_NAME=WMTS:
>> http://www.ign.es/wmts/pnoa-ma?request=GetCapabilities&service=WMTS,layer=OI.OrthoimageCoverage,tilematrixset=EPSG:25830
>>
>> SUBDATASET_5_NAME=WMTS:
>> http://www.ign.es/wmts/pnoa-ma?request=GetCapabilities&service=WMTS,layer=OI.OrthoimageCoverage,tilematrixset=GoogleMapsCompatible
>>
>>
>>
>> But when I want Know the information or download a image in certain
>> coordinates  with EPSG:4326, it returns an error “ERROR 1: Invalid
>> dataset
>> dimensions : -135056383 x -167901439”, with EPSG:25830 works fine. I
>> don`t
>> understand this error, someone could help me?
>>
>>
>>
>> Thank you and regards
>> --
>>
>> *Elena Ruiz *
>> Sofware Development & Technical Support
>> Tel. +34 952 43 97 71
>> 

> eruiz@

>> Sumatra, 9 - 29190 Málaga (Spain)
>> *www.aplitop.com *
>>
>> ;  
>> ;
>> ;
>> ;
>>
>> In accordance with the provis

Re: [gdal-dev] GeoTiff writer refuses to set 42113 (NoData) from Python

[jratike80]

Hi,

There is a common belief that problems with images happen only with exactly
that confidential multigigabyte image that user is playing with. That is
uncommon and usually the problem can be repeated with any other image with
similar structure. 

If you have GDAL v. 3.2 you can use
https://gdal.org/programs/gdal_create.html for sharing test data. Usage
example:

gdal_create -outsize 500 500 -burn 255 -burn 0 -burn 0 -if p4433h.tif
create.tif

The command creates a 500x500 pixel sized image that has the same
projection, bit depth etc. than the original "p4433h.tif" but all the pixels
are filled with red (this was a RGB image). Now there is no secrets to be
seen in the image. If the location is secret, assign fake ullr coordinates.
If even SRS is sectet you can change even that.

It is also possible to do quite a lot with python and nobody can say by your
description what goes wrong. Add so much of Python that others can just
copy, paste, and run the code, and together with the test image it produces
the error. Just as with the image, do not show all your code. Simplify it
into minimum to show the error.

-Jukka Rahkonen-



Dustin Sims wrote
> Hey devs,
> 
> I have an issue where writing any GeoTiff from python results in
> 
> ERROR 1: TIFFSetField:Path/To/File: Unknown tag 42113
> 
> This happens regardless of warp or translate (the only two applicable
> tools for my use case)
> 
> However, running this through the CLI tools with the exact same inputs
> results in the NoDataValue being preserved, and no matching error output.
> While I can use subprocess tools to run the CLI tool through python, I
> would very much prefer to use gdal.Warp() and the like.
> 
> I am unable to provide sample data, due to it being confidential. If I use
> gdal.Warp() or gdal.BuildVRT() to convert the input file to VRT, the
> NoData is preserved. Translating that to a GeoTiff  results in the above
> error and NoData is lost. Seems really strange that I am unable to write
> tag 42113, as that is one of the GDAL specific tags. Anyone have any
> advice on what I could do to resolve this?
> 
> GDAL version 3.2.1
> GDAL-python 3.2.1
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] mosaicking files with partial overlap and binary mask

[jratike80]

Hi Daniele,

Test data, please.

-Jukka Rahkonen-



Daniele Romagnoli-3 wrote
> Thanks for the feedback, Patrick.
> I have downloaded the latest build from GisInternals and it worked as
> expected.
> I have another question.
> It looks like warping an input file containing a binary mask isn't
> preserving the binary mask on the output.
> Should I specify any flag for that?
> 
> Thanks for the help.
> Regards,
> Daniele
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Fwd: ogr2ogr crash attempting to drop table in filegdb

[jratike80]

Hi,

SQL in ogr2ogr is only for SELECT. For any other purpose use ogrinfo.
An example:

ogrinfo -sql "alter table point_p rename column test to foo" point.gpkg
-dialect sqlite

-Jukka Rahkonen-


janhec wrote
> Dear list,
> 
> About the filegdb driver
> Attempting:
> ogr2ogr -f FILEGDB test.gdb bag2101.gdb -update -sql "drop table
> standplaats"
> crashed ogr2ogr (obtained from gisinternals.com,
> gdal-302-1928-x64-core.msi
> etc) with a heap corruption. (VS: Unhandled exception at
> 0x7FFE1C6EF099
> (ntdll.dll) in ogr2ogr.exe: 0xC374: A heap has been corrupted
> (parameters: 0x7FFE1C7587F0).)
> The table does get dropped.
> 
> The table was inserted from a shapefile using:
> ogr2ogr --config shape_encoding "UTF-8" --config FGDB_BULK_LOAD YES
> -append
> -f "filegdb" bag2101.gdb sta.shp -nln standplaats -sql "select identifica
> as identificatie,hfdadresid as hoofdadresid,* from sta", and displays
> properly in Qgis.
> 
> So the filegdb driver appears to be properly installed.
> 
> Also,  I could not get column renaming to work. Using dialects filegdb and
> OGR SQL,
> ogr2ogr -f FILEGDB test.gdb test.gdb -update -sql "alter table vbo_actueel
> rename column oppervlakt to oppervlakte"  -dialect "FILEGDB"
> gives ERROR 1: Failed at executing 'alter table vbo_actueel rename column
> oppervlakt to oppervlakte' (An invalid SQL statement was used.);
> using -dialect SQLITE, I get
> ERROR 1: In ExecuteSQL(): sqlite3_prepare_v2(Alter table vbo_actueel
> rename
> column oppervlakt to oppervlakte): no such table: vbo_actueel
> whereas ogrinfo clearly states the table exists.
> 
> I am trying to clear my arcgis ties preferring Qgis and for reasons of
> cost, but sometimes I do need to provide data in filegdb format.
> 
> Thanks in advance for any advice,
> Jan
> 
> PS. I do not add the shapefile for reference, since that version of this
> mail got "rejected by the owner" for being about 1500 bytes in size.
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] no such function: ST_Line_Interpolate_Point when Spatialite and GDAL are installed and quite up-to-date

[jratike80]

Hi,

This is how you can test with ogrinfo if the function is available for you.
Use just any vector data source instead of "point.jml". Test data is
generated by the SQL but ogr2ogr requires some datasource (I have been
wondering if it could be dummy.dum or something like that for a dummy
format).

ogrinfo -dialect sqlite -sql "select
ST_Line_Interpolate_Point(ST_GeomFromText('LINESTRING (0 0,1 1)'), 0.1)"
point.jml
Had to open data source read-only.
INFO: Open of `point.jml'
  using driver `JML' successful.
  
Layer name: SELECT
Geometry: Unknown (any)
Feature Count: 1
Extent: (0.10, 0.10) - (0.10, 0.10)
Layer SRS WKT:
(unknown)
Geometry Column = ST_Line_Interpolate_Point(ST_GeomFromText('LINESTRING (0
0,1 1)'), 0.1)
OGRFeature(SELECT):0
  POINT (0.1 0.1)

Having high enough Spatialite version does not guarantee that
ST_Line_Interpolate_Point is available. As you can see from
http://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html that function is
based on GEOS. For getting GEOS based functions into use Spatialite must
have been compiled with GEOS, and that GEOS version must have the support.
Spatialite has functions for checking various things about GEOS. As an
example my GEOS version is

ogrinfo -dialect sqlite -sql "select geos_version()" point.jml
Had to open data source read-only.
INFO: Open of `point.jml'
  using driver `JML' successful.

Layer name: SELECT
Geometry: None
Feature Count: 1
Layer SRS WKT:
(unknown)
geos_version(): String (0.0)
OGRFeature(SELECT):0
  geos_version() (String) = 3.9.0-CAPI-1.14.1

-Jukka Rahkonen-



GDAL - Dev mailing list wrote
> Dear list members,
> I have been trying to use the GDAL tools from within QGIS, more
> specifically the "Points Along Lines" tool, to find the lines' midpoints
> in line shapefiles. However, regardless of which file I try, I keep
> getting this error:
> 
> 
> GDAL command output:ERROR 1: In ExecuteSQL(): sqlite3_prepare_v2(SELECT
> ST_Line_Interpolate_Point(geometry, 0.5) AS geometry,* FROM
> "myshapefile"):
> no such function: ST_Line_Interpolate_Point
> 
> 
> Searching online, the only reference to that problem is a 5 years old
> thread from this very
> list: https://lists.osgeo.org/pipermail/gdal-dev/2015-May/041800.html.
> Following it, the first obvious thing to suspect is that Spatialite is
> either missing or outdated. However, neither seem to be the case in my
> 64bits Ubuntu 18.04 system:
> 
>> sudo apt-get install -y spatialite-binReading package lists...
>> DoneBuilding dependency tree       Reading state information...
>> Donespatialite-bin is already the newest version (4.3.0-2build1).
> 
> For reference, it seems that GDAL version being used is 3.0.2 and PROJ
> version is 6.2.1:
> 
> QGIS version: 3.10.1-A CoruñaQGIS code revision: 1e6b1a3eQt version:
> 5.12.6GDAL version: 3.0.2GEOS version: 3.7.2-CAPI-1.11.2 b55d2125PROJ
> version: Rel. 6.2.1, November 1st, 2019
> 
> I am at a loss: if both GDAL and Spatialite are present in my system and
> up-to-date enough to contain "ST_Line_Interpolate_Point", how could I
> solve the mentioned issue?
> Thanks!
> Ann Tulliani
> 
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] JPEG/PNG 12 bits GDAL python

[jratike80]

Hi,

With my GDAL 3.1.4 from OSGeo4W converting a single band Float32 DEM file
into JPEG compressed TIFF and into plain JPEG succeeded with these commands:

gdal_translate L2431.tif -co COMPRESS=JPEG -ot uint16 -co NBITS=12 out.tif
gdal_translate L2431.tif -of JPEG -ot uint16 -co NBITS=12 out.jpg

I have never played with 12 bit JPEGs before. The documentation was not very
clear to me and I am not sure if it is essential to first define the data
type into uint16 and then limit the number of NBITS into 12.
But without using -ot uint16 I got messages like

Warning 6: Only NBITS=16 is supported for data type Float32
Warning 1: NBITS=32 is invalid for data type UInt16. Using NBITS=16
ERROR 1: JPEGSetupEncode:BitsPerSample 16 not allowed for JPEG

Warning 6: driver JPEG does not support creation option NBITS
0Warning 6: JPEG driver doesn't support data type Float32. Only eight and
twelve bit bands supported (Mk1 libjpeg).

I wonder if there is any way for the user to find out if their GDAL is
compiled with 12 bit JPEG support.

-Jukka Rahkonen-



GDAL - Dev mailing list wrote
> Hello and thank you in advance,
> 
>  
> 
> Im trying to generate png and jpeg 12 bits images from a GTiff single band
> file with no success. I know is there a way to generate 12 bits images in
> the GDAL command line as I have seen in some examples (“gdal_translate
> mandril_rgb.tif -co COMPRESS=JPEG -co PHOTOMETRIC=YCBCR -co NBITS=12
> out.tif”) but trying it with my singlebands tif files it only generates a
> black image (with PHOTOMETRIC set to MINISBLACK). Is it only a method for
> rgb files?
> 
> Searching in the python API I only can find gdalconst for 16, 32 and 64
> bits
> formats. Is there a way to do the same with 12 bits files?
> 
>  
> 
> Kind regards
> 
>  
> 
> 
>  ; 
> 
> 
> Jesús Maria Morán Rosado
> Project Engineer
> 
> Av. Cerro del Águila, 3, 28703 S.S. de los Reyes, Madrid
> 
> CONFIDENTIALITY: This e-mail and any attachments are confidential and may
> be
> privileged. If you are not a named recipient, please notify the sender
> immediately and do not disclose the contents to another person, use it for
> any purpose or store or copy the information in any medium.
> 
>  
> 
> 
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> 
> image001.gif (2K)
> ;





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] OGC KML compliance

[jratike80]

Done.

Even there should be no need to report the results again (all tests were OK)
I would recommend to try the TEAM Engine just for fun. It was a pleasant
experience for me.

-Jukka Rahkonen-



Even Rouault-2 wrote
> Hi,
> 
> if anyone cares about GDAL still being mentionned as a OGC KML reference 
> implementation, run autotest/kml_generate_test_files.py with GDAL 3.2,
> submit 
> the produced 4 files to the OGC KML 2.2 test harness
> (https://cite.opengeospatial.org/teamengine/viewSessions.jsp)
> and communicate to Angelos (CC'ed) your CITE user account and the session 
> numbers.
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL workshop for FOSSGIS 2021

[jratike80]

Hi,

I do not believe that anybody is jealous of you because of the workshop. And
if a rival candidate appears (unlikely) it is up to the organizer to select
the workshop that they consider as the best. We support fair play.

-Jukka Rahkonen-


Markus Metz-3 wrote
> Hi,
> 
> we from mundialis, mainly Markus Neteler and me, are thinking about giving
> a 90 minute GDAL workshop during the upcoming FOSSGIS conference in
> Switzerland. We are not part of the core GDAL team, but confident that we
> are able to give such a workshop for a German-speaking audience. Before we
> officially apply for the workshop, I want to ask if this would conflict
> with plans from the GDAL team or if you have any objections against us
> giving a GDAL workshop. In this case we will not submit a GDAL workshop
> for
> FOSSGIS 2021.
> 
> Markus
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_translate receiving "Warning 6: driver GTiff does not support creation option WEBP_LOSSLESS"

[jratike80]

Hi,

I would also have a try by actually using -co WEBP_LOSSLESS=True even by the
error message it is perhaps automatically applied.

-Jukka Rahkonen-


Marty J. Sullivan wrote
> Hello,
> 
> I am attempting to create a COG format GeoTIFF with WEBP_LOSSLESS
> compression using GDAL.
> 
> I have compiled GDAL 3.2.1 from source with libwebp 0.4.2 installed from
> Debian Buster repos (I’ve also tried with libwebp v1.1.0 installed from
> source, no difference). When I run the ./configure script before
> compiling, WEBP support is listed as “Yes”
> 
> When I try to create a COG with gdal_translate, and setting QUALITY=100,
> GDAL returns “Warning 6: driver GTiff does not support creation option
> WEBP_LOSSLESS”
> 
> I would expect that WEBP_LOSSLESS would work because the documentation for
> the GTiff driver states “WEBP_LOSSLESS=True/False: (GDAL >= 2.4.0 and
> libwebp >= 0.1.4): By default, lossy compression is used. If set to True,
> lossless compression will be used.”
> 
> Here is the command I am running, it works fine when running with another
> compression (or choosing QUALITY=99 for WEBP)
> 
> gdal_translate -of COG -co COMPRESS=WEBP -co QUALITY=100 -co
> NUM_THREADS=ALL_CPUS -co RESAMPLING=NEAREST -co
> OVERVIEW_RESAMPLING=NEAREST -co WARP_RESAMPLING=NEAREST -co OVERVIEWS=AUTO
> -co TILING_SCHEME=CUSTOM -co ZOOM_LEVEL_STRATEGY=UPPER input.tif
> output.tif
> 
> Thanks for any guidance on getting WEBP_LOSSLESS to work!
> 
> Marty Sullivan
> Cornell University
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Considering drivers removal ?

[jratike80]

Hi,

The joy of being a Windows user is that it is so easy to use old GDAL
versions if the binaries still happen to be on some dusty backup disk. Even
the FWTools including GDAL 1.7.0 from 2010 seemed to work fine and include
quite a many later removed drivers.

A few comments about the driver list:

- There are indeed questions about SVG in gis.stackexchange every now and
then.
- I used LAN a lot when FWTools was young and ERDAS wrote bad GeoTIFFs.
Things are probably changed since that. 
- GMT is an active project and some GMT developers appear on this list as
well. Maybe some of them happend to read this and say if GMT ASCII vectors
are still important for GMT. Or otherwise I can ask from the GMT forum.
- GPS Track Maker, as far as I know, is quite popular in Brazil. However,
when I used the software I just used GPX format for data transfer. Are there
any Brazilian GDAL user here to comment?

When it comes to Windows binaries, there is a very valuable archive in
https://gisinternals.com/archive.php. It would be pity if it would get lost
some day.

-Jukka Rahkonen-



Even Rouault-2 wrote
> Hi,
> 
> It's not spring yet, but I'm in a mood lately of axing useless things, and
> we 
> probably have tons of candidate for that in GDAL, especially in drivers.
> I was going to just axe the DB2 driver
> (https://github.com/OSGeo/gdal/pull/3366) but the issue is more general.
> 
> Any idea how we can know what is used and what isn't ? A "call-home" 
> functionality where we would track driver usage would only be acceptable
> if 
> people enable it and have network connectivity, so we won't probably get
> lots 
> of feedback. Having a spreadsheet with the driver list and asking people
> to 
> fill it would probably also receive little feedback. So the idea I had was
> to 
> do something like the following in the Open() method of a candidate for 
> removal:
> 
> GDALDataset* FooDriver::Open(  )
> {
>if( !Identify(poOpenInfo) )
>   return nullptr;
> 
>if( !CPLTestBool(CPLGetConfigOption("GDAL_ENABLE_DRIVER_FOO", "NO") )
>{
>CPLError(CE_Failure, CPLE_AppDefined,
> "Driver FOO is considered for removal in GDAL 3.5. You are invited "
> "to convert any dataset in that format to another more common one ."
> "If you need this driver in future GDAL versions, create a ticket at "
> "https://github.com/OSGeo/gdal (look first for an existing one first)
> to "
> "explain how critical it is for you (but the GDAL project may still "
> "remove it), and to enable it now, set the GDAL_ENABLE_DRIVER_FOO "
> "configuration option / environment variable to YES");
>return nullptr;
> }
> ...
> }
> 
> That is, when we detect a file to be handled by the driver, emit the above 
> error message and do not open the dataset, unless the user defines the 
> environment variable.
> Similarly in the Create()/CreateCopy() methods.
> If we ship this in 3.3, with a 3.5 milestone for removal, this would offer
> a 
> feedback period of one year / 2 feature versions.
> 
> Here's my own list of candidates for retirement (probably
> over-conservative). 
> Mostly based on gut feeling. None of them are particularly bad citizens,
> but I 
> have no indication that they are still used, which doesn't mean they
> aren't.
> 
> * Raster side:
> BPG
> DB2Raster
> DOQ1
> DOQ2
> E00GRID
> Epsilon
> FujiBAS
> GS7BG
> GSAG
> IDA
> JDEM
> JPEG2000 (Jasper): JP2OpenJPEG is a better replacement
> JPEGLS
> LAN
> MFF
> MG4Lidar ?
> NDF
> NTv1
> SDTS Raster
> SGI
> XPM
> ZMap
> 
> * Vector side:
> AERONAVFAA
> ESRI ArcObjects
> ARCGEN
> BNA
> Cloudant
> CouchDB
> DB2
> DODS
> FMEObjects Gateway
> Geomedia MDB
> GMT ASCII Vectors
> GTM
> HTF
> INGRES
> MongoDB (the old one, superseded by MongoDBv3)
> OpenAIR
> REC
> SDTS
> SUA
> SVG
> TIGER
> WALK
> 
> 
> Anything you'd add / remove ?
> 
> What is not obvious is what would be the criterion for keeping a driver:
> 1, 
> 10, 100 users asking for the driver to be kept ?
> If a GDAL developer contributing to the overall good of the project needs
> the 
> preservation of a driver to be able to justify its continued involvement,
> I'd 
> tend to think it to be enough to keep it.
> 
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] List all the (possible) errors of a single transaction

[jratike80]

Hi,

One workaround is to use -skipfailures and compare afterwards which IDs in
the source data are not present in the target table. Skipfailures is forcing
the transaction size into one row and it may be deadly slow if the output is
GeoPackage because initializing/committing a transaction in SQLite is slow.
With PostGIS as an outlut it is not as slow. A dry run into some some fast,
not transactual format like GeoJSON could be used as some sort of test but
that does not test the database constraints.

If you know your database and the contraints that you have you should be
able to make quite nice tests by running SQL against the source data. But
having a typeless SQLite as source can make it harder to write the SQL
tests. That may even be a reason for your problems (field reserved for
integers contains text etc.).

I wonder why even the database engines would go on after finding the first
error in the transaction. The whole transaction must be rollbacked in any
case so why not to quit sooner rather than later?



-Jukka Rahkonen-



ghtmtt wrote
> Hi all and happy new year!
> 
> as suggested some days ago [0] I've set up a vrt file that I use to 
> export many tables from a gpkg to a PG.
> 
> In the PG DB there are some constraints and with the vrt files all works 
> as expected: if an error (like a wrong value caught by the constraint) a 
> total rollback is made and nothing is written in the PG DB.
> 
> But what if I've more than one single error on the gpkg? It seems (to 
> me) that when ogr2ogr identifies the first error the process is stopped.
> 
> Is there a way to list ALL the (possible) errors of a single transaction 
> (like a dry run)?
> 
> Cheers and thanks for any hint
> 
> Matteo
> 
> 
> [0] https://lists.osgeo.org/pipermail/gdal-dev/2020-December/053209.html
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr from gpx to postgis - track_fid not maintained for track_points

[jratike80]

Hi,

For my mind the behavior is consistent. FID (in this case named as ogc_fid)
is a unique feature ID and tracks table contains tracks so it is natural
that FID is increasing when more tracks are added - and it must increase or
otherwise the FID is not unique. The track_points table contains points and
FID is unique for each point. If you add more track points the ogc_fid will
increase from the maximum existing ogc_fid value. The track id in the
track_points column in just a normal attribute and it is read directly from
the GPX data.

-Jukka Rahkonen-


Michael Saupe-2 wrote
> Hi Evan,
> 
> thank you for the explanation. That makes sense. However, in my opinion
> ogr2ogr behavior is not really consistent in this case: The column ogc_fid
> , which is in fact the track id, is incremented on each gpx file import (
> regardless if you use -update -append  or not ).
> 
> Michael
> 
> Am 02.01.2021 um 14:03 schrieb Even Rouault:
>> Michael,
>>
>> You have a single track in each file, so it is expected that track_fid
>> doesn't 
>> change and is set at 0 (as there's no attribute to uniquely identify a
>> track)
>> For what you want to do (that is have distinct track_fid for each file), 
>> you'll likely have to use an intermediate postgresql schema, where you
>> would 
>> correct the value of track_fid, before merging them together
>>
>> Even
>>
>>> clarification: second table of my points is 'track_points'.
>>>
>>> Also adding my 2 gpx files for reference:
>>>
>>> *file1.gpx:*
>>>
>>> 
>>> 
> http://www.topografix.com/GPX/1/1";>
>>>   
> 
>>>   
> 
>>>   
> 
>>> 
> 
>>>   
> 
>>> 
> 
> 1
> 
>>>   
> 
>>>   
> 
>>> 
> 
> 1
> 
>>>   
> 
>>>   
> 
>>> 
> 
> 1
> 
>>>   
> 
>>> 
> 
>>> 
> 
>>>   
> 
>>> 
> 
> 2
> 
>>>   
> 
>>>   
> 
>>> 
> 
> 2
> 
>>>   
> 
>>>   
> 
>>> 
> 
> 2
> 
>>>   
> 
>>> 
> 
>>>   
> 
>>> 
> 
>>>
>>> *file2.gpx:*
>>>
>>> 
>>> 
> http://www.topografix.com/GPX/1/1";>
>>>   
> 
>>>   
> 
>>>   
> 
>>> 
> 
>>>   
> 
>>> 
> 
> 3
> 
>>>   
> 
>>>   
> 
>>> 
> 
> 3
> 
>>>   
> 
>>>   
> 
>>> 
> 
> 3
> 
>>>   
> 
>>> 
> 
>>>   
> 
>>> 
> >
>>
>>> Am 01.01.2021 um 18:04 schrieb Michael Saupe:
 Hello folks,

 I am importing multiple gpx files into a postgis database. The tables
 'tracks' and 'track_points' are created / updated.

 The column track_fid in in the track_points table should be a reference
 to
 the track feature id as documented in
 https://gdal.org/drivers/vector/gpx.html, however it is always zero. 

 Is this a bug or am I missing something?

   Details

 I am creating an empty database, then create postgis extension with
 'CREATE EXTENSION POSTGIS'

 I have two simple gpx files ( see attachments )

   * file1.gpx - containing 2 track segments - each with 3 track points
   * file2.gpx - containing 1 track segment  with 3 track points

 I am using commands

 ogr2ogr -f PostgreSQL -update -append "PG:dbname=testdb host=localhost
 user=postgres password=xx port=5432" file1.gpx

 ogr2ogr -f PostgreSQL -update -append "PG:dbname=testdb host=localhost
 user=postgres password=xx port=5432" file2.gpx

 Resulting data in 'tracks'

 ogc_fidnamecmt descsrc link1_href  link1_text  
 link1_type
link2_href  link2_text  link2_type  number  type
 wkb_geometry 1  
>> NULL
NULLNULLNULLNULLNULLNULLNULLNULLNULL
 NULL
>> NULL ... 2
NULLNULLNULLNULLNULLNULLNULLNULLNULL
 NULL
>> NULL NULL
...
>>> Resulting data in 'track_points'
>>>
>>> ogc_fid track_fid   track_seg_idtrack_seg_point_id  ele 
>>> time 
>> other
>>> columns omitted ... 1   0   0   0   1   NULL
>>> 2   0   0   1   1   NULL
>>> 3   0   0   2   1   NULL
>>> 4   0   1   0   2   NULL
>>> 5   0   1   1   2   NULL
>>> 6   0   1   2   2   NULL
>>> 7   0   0   0   3   NULL
>>> 8   0   0   1   3   NULL
>>> 9   0   0   2   3   NULL
>>>
 Expected:

 ogc_fidtrack_fid   track_seg_idtrack_seg_point_id  ele 
 time
 other columns omitted ... 11

0   0   1   NULL

 2  1

0   1   1   NULL

 3  1

0   2   1   NULL

 4  1

1   0   2   NULL

 5  1

1   1   2   NULL

 6  1

1   2   2   NULL

 7  2

0   0   3   NULL

 8  2

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

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> Having heard no issues being reported regarding RC1
> 
> Motion:
> 
> Adopt GDAL 3.2.1 RC1 as final 3.2.1 release
> 
> Starting with my +1
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] exporting all tables from PG schema

[jratike80]

Hi,

I would have a try with open option LIST_ALL_TABLES=YES
https://gdal.org/drivers/vector/pg.html.
"LIST_ALL_TABLES=YES/NO: This may be “YES” to force all tables, including
non-spatial ones, to be listed." It is probably worth reading
https://gdal.org/drivers/vector/gpkg.html as well, about the layer creation
options and aspatial tables.


-Jukka Rahkonen-




ghtmtt wrote
> Hi all,
> 
> I'd like to export all the table of a PG schema to either GPKG or a 
> shapefiles.
> 
> In the schema I've a lot of non-spatial tables and with something like:
> 
> ogr2ogr -f GPKG output.gpkg "PG:dbname=mydb schemas=myschema user=myuser 
> password=mypws host=myhost" -progress
> 
> the output is generated but it only contains geometric tables. I 
> couldn't find a parameter to force the export of also non-spatial tables.
> 
> What I'd like to avoid is to loop on every single layer
> 
> Cheers and thanks
> 
> Matteo
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Doubts to Convert TopoJson to SHP File

[jratike80]

Hi,

Do you know in which coordinate system the topojson data are? If GDAL can't
recognize it automatically (check with ogrinfo) you can give it manually,
for example " -a_srs EPSG:4326". That should trigger the creation of the
.prj file.

-Jukka Rahkonen-


Moises Silva wrote
> Hi,
> 
>I am newbie to use the GDAL and passing the problem in convert TopoJSON
> to SHP FIle.
>I executed the command below and some files were created (.dbf, .shp,
> .shx) but the file .prj is not created.
> Is there any parameters that I need to pass to create this .prj file?
>   ogr2ogr -f "ESRI Shapefile"  countries110m  countries110m.json
> 
> Thanks,
> Mochi
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Duplicate pixels in VRT

[jratike80]

Hi,

Check what are the extents of two adjacert images reported by GDAL 2 and 3,
as well as the sizes in pixels, and if images are of type "pixel is area" or
"pixel is point". DEM kind of images are sometimes intentionally produced to
have overlap.

-Jukka Rahkonen-



Jon Morris wrote
> Hello all,
> 
> I've come across a weird edge case and I'm wondering if anyone has seen
> something similar.
> 
> I'm updating our application from GDAL v2.2 to v3.2 and have a failing
> test where there is a 1 pixel shift in the output. We're building a VRT
> from a DTM and a flood depth raster and when you call ds.ReadAsArray() on
> the VRT there is a duplicated column of pixels at GDAL 2, which is causing
> the apparent shift. It's not worth raising a ticket, as the GDAL 3 output
> is correct, but I can't explain why this shift has happened and I'm
> wondering if this has happened anywhere else.
> 
> If I open the two VRTs in QGIS, they look the same, so maybe it's an issue
> with ReadAsArray. There is slight difference in SRS precision, which might
> be causing a rounding error, but otherwise I've no idea what might be
> causing it.
> 
> GDAL 2
> 
> PROJCS["North_America_Albers_Equal_Area_Conic",
> GEOGCS["NAD83",DATUM["North_American_Datum_1983",
> SPHEROID["GRS
> 1980",6378137,298.2572221010042,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],
> PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433],AUTHORITY["EPSG","4269"]],
> PROJECTION["Albers_Conic_Equal_Area"],
> PARAMETER["standard_parallel_1",20],
> PARAMETER["standard_parallel_2",60],
> PARAMETER["latitude_of_center",40],
> PARAMETER["longitude_of_center",-96],
> PARAMETER["false_easting",0],
> PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]]]
> 
> GDAL 3
> 
> PROJCS["North_America_Albers_Equal_Area_Conic",
> GEOGCS["NAD83",DATUM["North_American_Datum_1983",
> SPHEROID["GRS
> 1980",6378137,298.257222101004,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],
> PRIMEM["Greenwich",0],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],
> PROJECTION["Albers_Conic_Equal_Area"],
> PARAMETER["latitude_of_center",40],
> PARAMETER["longitude_of_center",-96],
> PARAMETER["standard_parallel_1",20],
> PARAMETER["standard_parallel_2",60],
> PARAMETER["false_easting",0],
> PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH]]
> 
> Thanks,
> 
> Jon
> 
> 
> Jon Morris
> Software Developer
> 
> COVID-19. During the current outbreak JBA remains open for business and we
> continue to deliver our services. However, we have adopted flexible/remote
> working as required. I will be receiving and reading email as normal but I
> may not always be available on the office number.
> 
> 
> [JBA COVID-19
> statement];
> 
> T +44 (0) 1756 799919
> www.jbarisk.com;
> 
> [Visit our website];
> [http://www.jbagroup.co.uk/imgstore/JBA-Email-Sig-Icons-LINKEDIN.png]
> ;  [Follow us on
> Twitter] ;
> 
> Find out more about us here:
> www.jbarisk.com; and follow us on Twitter
> @JBARisk; and
> LinkedIn;
> 
> The JBA Group supports the JBA Trust.
> 
> All JBA Risk Management's email messages contain confidential information
> and are intended only for the individual(s) named. If you are not the
> named addressee you should not disseminate, distribute or copy this
> e-mail.
> Please notify the sender immediately by email if you have received this
> email by mistake and delete this email from your system.
> 
> 
> JBA Risk Management Limited is registered in England, company number
> 07732946, 1 Broughton Park, Old Lane North, Broughton, Skipton, North
> Yorkshire, BD23 3FD, Telephone: +441756799919
> 
> 
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Exporting triggers/constraints from PG to GPKG

[jratike80]

Hi,

You are right, ogr2ogr converts just the data from the table/view/query and
metadata that defines the coordinate system.  I believe it would be very
hard to handle the creation of triggers and constraints and insert data in
the right order into SQLite, Oracle, MSSQL etc.

-Jukka Rahkonen-


ghtmtt wrote
> Hi all (and sorry for the flood of these days),
> 
> the question is very simple: if I have triggers and/or constraint in a 
> PG database, is ogr2ogr exporting them to the GPKG?
> 
> At a first view it seems not (I looked in the exported GPKG and I cannot 
> find the triggers and constraints). I also couldn't find any option in 
> the documentation.
> 
> Cheers and thanks!
> 
> Matteo
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr question

[jratike80]

Hi,

No, -overwrite does not truncate but it drops the table. However, with the
PostgreSQL driver it is also possible to truncate the table by using this
documented method  https://gdal.org/drivers/vector/pg.html#vector-pg. Check
the configuration options

"OGR_TRUNCATE: If set to “YES”, the content of the table will be first
erased with the SQL TRUNCATE command before inserting the first feature.
This is an alternative to using the -overwrite flag of ogr2ogr, that avoids
views based on the table to be destroyed. Typical use case: “ogr2ogr -append
PG:dbname=foo abc.shp –config OGR_TRUNCATE YES”."

-Jukka Rahkonen-


ghtmtt wrote
> 
> Just for information: -overwrite is doing a "truncate table" before 
> adding the new features? Is this the reason that FK, CHECKS and other 
> customization will be lost?
> 
> Cheers and thanks
> 
> Matteo





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Geotransform for non-North-up images?

[jratike80]

Hi,

The geotransform parameters are the same than in the ESRI wordfile. I tried
once to understand how the parameters behave when the image is rotated and
wrote an OpenOffice spreadsheet about that. You can have a try and play with
the parameters. I hope I have understood it right. I was not so sure myself
and therefore there are some unnecessary cells with forward and backward
formulas just to verify the results. 

http://latuviitta.org/documents/rotated_worldfile.ods

-Jukka Rahkonen-


G Seiffert wrote
> Hi all from GDLA.
> 
> Thanks for the opportunity to as a question. It's regarding the 
> Geotransform 
> Tutorial(https://gdal.org/tutorials/geotransforms_tut.html). Tried to 
> get info in the web but since this seems a tricky one, my searches failed.
> 
> The tutorial only deals with the ideal case of 'North up' images, for 
> which GT(2) and GT(4) are zero. However, my images are 'East up' and 
> potentially 'any direction up' (underwater photomosaic surveys by ROV). 
> The rotation works with '90' for GT(2, 4). But the scaling seems 
> completely ignored. Any hint? If it would be easy, I assume your 
> tutorial would give an example for how to deal with "non-N-up' images, 
> but ...
> 
> My pics are 1920x1080, with pixel resolution of 0.0015 (yes, 0.15cm per 
> pixel, we're flying just 3m above the bottom).
> 
> In case I rotate the images prior to geotransform (in Photoshop), 
> geotransform works perfect, with GT(2, 4) = 0. Scaling spot on. I can 
> live with that for our last survey but I'm also looking for a solution 
> in case our survey heading cannot be 0, 90, 180, or 270, but has to be 
> something like 35° (due to bottom currents etc.).
> 
> Best regards, any hint qappreciated,
> Gerhard
> 
> 
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_translate -scale

[jratike80]

Hi,

If your output is 8 bit you can just use -scale without min/max values.
From https://gdal.org/programs/gdal_translate.html:

"Rescale the input pixels values from the range src_min to src_max to the
range dst_min to dst_max. If omitted the output range is 0 to 255. If
omitted the input range is automatically computed from the source data."

If your data is higher than 8 bit and you want to keep it so you are out of
luck with gdal_translate because it first omits the output range and sets it
into 0-255 before it can omit the input range and compute the range
automatically.

The current behavior is not optimal for certain use cases
(https://gis.stackexchange.com/questions/294129/min-max-stretch-using-gdal-translate-in-a-batch).
Some programmer learning GDAL could take this as a challenge and formulate
how to improve the automatic scaling support so that it would not break too
much. As a first aid a Python script for automatic min/max scaling would be
nice, and why not with an option to utilize the histogram and use for
example +/- 98% of the histogram. Or mean +/- (2 x RMS).

-Jukka Rahkonen-



jesus.moran wrote
> Hello GDAL team and thank you for welcome me.
> 
>  
> 
> I have an issue with the gdal_translate command. I would like to use the
> “STATISTICS_MIN” and “STATISTICS_MAX” metadata key values in the -scale
> parameter of the program, so I don’t need to specify it manually every
> time
> I want to scale the output. Is there any way to do this?
> 
>  
> 
> Thanks a lot in advance!
> 
>  
> 
> 
>  ; 
> 
> 
> Jesús Maria Morán Rosado
> Project Engineer
> 
> Av. Cerro del Águila, 3, 28703 S.S. de los Reyes, Madrid
> 
> CONFIDENTIALITY: This e-mail and any attachments are confidential and may
> be
> privileged. If you are not a named recipient, please notify the sender
> immediately and do not disclose the contents to another person, use it for
> any purpose or store or copy the information in any medium.
> 
>  
> 
> 
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> 
> image001.gif (2K)
> ;





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] promote_to_multi and python API

[jratike80]

Hi,

You do not need to call ogr2ogr because there is a python library equivalent
"gdal.VectorTranslate". You can find a PROMOTE_TO_MULTI example from the
autotests

https://github.com/OSGeo/gdal/blob/master/autotest/utilities/test_ogr2ogr_lib.py#L539

-Jukka Rahkonen-


Martin Landa wrote
> Hi,
> 
> is there a way to apply PROMOTE_TO_MULTI in Python API? I am trying to
> write a sample script for students in Python which converts SHP file
> to PostGIS layers. I am dealing with a well known problem "Geometry
> type (MultiXXX) does not match column type (XXX)".
> 
> How to solve it properly in order to avoid calling `ogr2ogr` from
> Python code? :-)
> 
> Thanks, Martin
> 
> -- 
> Martin Landa
> http://geo.fsv.cvut.cz/gwiki/Landa
> http://gismentors.cz/mentors/landa
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] MBTiles generation docs question

[jratike80]

Hi,

I am adding some related links:
- Open GDAL ticket (where you already added your comment)
https://github.com/OSGeo/gdal/issues/3126
- Question in gis.stackexchange
https://gis.stackexchange.com/questions/376827/gdaladdo-zoom-level-not-supported

The issue is that at the moment GDAL does not handle MBTiles with zoom
level>22. That corresponds roughly to pixel size of 11 millimeters. I
checked that your image is about 582 meters in height and with 68686 pixels
it makes a pixel size of  8-9 millimeters if I calculated it right.

BTW. I checked the distance in meters with ogrinfo trick
ogrinfo -dialect sqlite -sql "SELECT ST_Distance(ST_GeomFromText('POINT
(130.4572338 33.0115493)'),ST_GeomFromText('POINT (130.4572338
33.0063053)'),1)" foo.jml

where foo.jml can be any existing ogr source. 

-Jukka Rahkonen-



Evert Etienne (SITEMARK) wrote
> Hey,
> 
> Your zoom level explanation makes sense, thanks.
> 
> I should have included the gdalinfo in my previous mail, apologies.
> 
> ```
> Driver: GTiff/GeoTIFF
> Files: output.tif
> Size is 88543, 68686
> Coordinate System is:
> 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["geodetic latitude (Lat)",north,
> ORDER[1],
> ANGLEUNIT["degree",0.0174532925199433]],
> AXIS["geodetic longitude (Lon)",east,
> ORDER[2],
> ANGLEUNIT["degree",0.0174532925199433]],
> ID["EPSG",4326]]
> Data axis to CRS axis mapping: 2,1
> Origin = (130.457233786582947,33.011549334631184)
> Pixel Size = (0.00076347339,-0.00076347339)
> Metadata:
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   INTERLEAVE=PIXEL
> Corner Coordinates:
> Upper Left  ( 130.4572338,  33.0115493) (130d27'26.04"E, 33d 0'41.58"N)
> Lower Left  ( 130.4572338,  33.0063053) (130d27'26.04"E, 33d 0'22.70"N)
> Upper Right ( 130.4639938,  33.0115493) (130d27'50.38"E, 33d 0'41.58"N)
> Lower Right ( 130.4639938,  33.0063053) (130d27'50.38"E, 33d 0'22.70"N)
> Center  ( 130.4606138,  33.0089273) (130d27'38.21"E, 33d 0'32.14"N)
> Band 1 Block=88543x1 Type=Byte, ColorInterp=Red
>   Mask Flags: PER_DATASET ALPHA 
> Band 2 Block=88543x1 Type=Byte, ColorInterp=Green
>   Mask Flags: PER_DATASET ALPHA 
> Band 3 Block=88543x1 Type=Byte, ColorInterp=Blue
>   Mask Flags: PER_DATASET ALPHA 
> Band 4 Block=88543x1 Type=Byte, ColorInterp=Alpha
> ```
> causing the error mentioned previously
> ``gdal_translate output.tif output.mbtiles -of MBTILES
> Input file size is 88543, 68686
> ERROR 1: Could not find an approproate zoom level`
> 
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] MBTiles generation docs question

[jratike80]

Hi,

I would guess that the appropriate zoom level is the one with pixel size
closest to the pixel size of the source file after it has been warped into
EPSG:3857.

Please add gdalinfo report about the source image. 

-Jukka Rahkonen-


Evert Etienne (SITEMARK) wrote
> Dear,
> 
> I have a question about the following extract of the MBTiles driver docs
> (https://gdal.org/drivers/raster/mbtiles.html#raster-creation-issues)
> 
>> When using the CreateCopy() API (such as with gdal_translate), automatic
>> reprojection of the input dataset to EPSG:3857 (WebMercator) will be
>> done, with selection of the appropriate zoom level.
> 
> As far as I understand it, the input file (tif in my case) will be warped
> to 3857 before MBTiles generation. But I am unsure what the appropriate
> zoom level means in this case, could someone elaborate or point me in a
> next direction to investigate?
> 
> I was looking at these docs for the explanation of the following error I
> got, pointers much appreciated as well.
> 
> `gdal_translate output.tif output.mbtiles -of MBTILES
> Input file size is 88543, 68686
> ERROR 1: Could not find an approproate zoom level`
> 
> Many thanks
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_translate, exporting "Byte - Eight bit unsigned integer" single band tiff to gpkg using -ot Byte results in 4 bands raster with changed values

[jratike80]

It might be good to read also about the open options in
https://gdal.org/drivers/raster/gpkg.html

"BAND_COUNT=1/2/3/4: Number of bands of the dataset exposed after opening.
Some conversions will be done when possible and implemented, but this might
fail in some cases, depending on the BAND_COUNT value and the number of
bands of the tile. Defaults to 4 (which is the always safe value)."

-Jukka Rahkonen-


Even Rouault-2 wrote
> On mercredi 2 décembre 2020 15:16:44 CET Nicolas Cadieux wrote:
>> Hi,
>> 
>> This follows a discussion in the qgis-user mailing list.  We are using
>> gdal_translate (and QGIS "export as") on a 8bit unsigned single band
>> tiff to a .gpkg.  When using no -ot switch or when using -ot Byte, this
>> results in a 4 band .gpkg raster with the wrong values.  (Values in band
>> 1 to 3 are similar but off the mark). Band 4 is set at 255 as expected. 
>> Looks like some type of compression is going on in the band 1 to 3).
>> 
>> When saving using the -ot Int16 or Float32 switch, all is well and the
>> result has one band with the correct values.
>> 
>> ex: gdal_translate -ot Int16 -of GPKG "E:/Users/Nicolas/Google Drive
>> Nicolas/Partage_temporaire/qgis/int16.gpkg" "E:/Users/Nicolas/Google
>> Drive Nicolas/Partage_temporaire/qgis/int16.gpkg"
>> 
>> Is this a possible problem with the driver or is the problem sitting 18
>> inches in front of the screen? Problem similar on a Mac running QGIS
>> 3.10.1-A with GDAL 3.0.2 and QGIS3.16 on Windows running GDAL 3.1.4.
>> 
>> Test files are found here:
>> https://drive.google.com/drive/folders/1fMl9odowUFFRQFK61rTxgHeom_D8ymN6?usp
>> =sharing
>> 
> 
> The answer is there:
> https://gdal.org/drivers/raster/gpkg.html#tile-formats
> 
> For Byte input (that isn't recognized as to be used by the tiled gridded 
> coverage data), the default tile format will use JPEG lossy compression
> for 
> tiles with a fully opaque channel.
> 
> -co TILE_FORMAT=PNG will use lossless compression
> 
> GeoPackage raster aim was initially for visualisation purposes, hence this 
> default. The more analytic side was a later addition to the format, and 
> actually an extension
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] gdal_create: input file option

[jratike80]

Hi,

Great, allowing to override all automatically captured parameters is
probably a good feature. I believe that some users will find this new option
useful.

Next challenge could be to burn vertical and horizontal gridlines for
warping and resampling tests.

-Jukka-



Even Rouault-2 wrote
> On mardi 1 décembre 2020 13:23:58 CET Rahkonen Jukka (MML) wrote:
>> Hi,
>> 
>> Every now and then people would like to rasterize vectors into raster
>> that
>> matches exactly with some existing raster. There are a few possible ways
>> for creating an empty copy from a raster with GDAL tools
>> https://gis.stackexchange.com/questions/220753/how-do-i-create-blank-geotif
>> f-with-same-spatial-properties-as-existing-geotiff . The gdal_merge way
>> with
>> -createonly does the job and is fast, but who remembers that gdal_merge
>> exists and can be used for such purpose? How about to add an option like
>> "-if" (input file) into gdal_create program, with the same effect?
>> Options
>> -outsize, -a_srs, -a_ullr would have no effect if used together with
>> input
>> template file. Options -of, -bands, -ot, -a_nodata, -co could override if
>> given. Not sure about metadata, but probably it is never worth copying
>> from
>> the template file.
> 
> I've mostly followed your suggestion in
> https://github.com/OSGeo/gdal/pull/3255
> 
> Not sure if it will be useful, but to avoid too many exceptions, -outsize,
> -a-
> srs, -a_ullr can actually override the settings of the input file
> 
> Even
> 
> -- 
> Spatialys - Geospatial professional services
> http://www.spatialys.com
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr project/transform CRS in the same database table

[jratike80]

I would say that it is best to still use ogrinfo. You did not tell what is
your database so I can't tell the exact recipe for you but you will learn
it. You need to know that there are different SQL dialects for GDAL: OGR
SQL, SQLite, indirect_SQLite, and the native SQL for your database.  They
are all documented.  If your database does not have native ST_Transform
support then you take it from SQLite/Spatialite. For overriding the native
SQL of your database you may need to use -dialect indirect_SQLite.

Here is another example with a shapefile. A combination of OGR SQL and
SQLite dialects is needed.

Add a new column
ogrinfo -sql "alter table states add wkt_geom text" states.shp

There is space for only 254 charactes in a shapefile and that is not enough
for big polygons but we can do at least something with a little trick. 

ogrinfo -dialect sqlite -sql "update states set
wkt_geom=ST_AsText(ST_Transform(ST_Centroid(geometry),3857))" states.shp

Check what we got
ogrinfo states.shp -al
...
SERVICE (Real) = 637487.0
  MANUAL (Real) = 302635.0
  P_MALE (Real) = 0.49600
  P_FEMALE (Real) = 0.50400
  SAMP_POP (Real) = 736744.0
  wkt_geom (String) = POINT(-13405860.170799 6003812.424048)
  MULTIPOLYGON (((-122.400749 48.225395,-122.461586 48.228542,-122.453156
48.128674,-122.360077 48.06028,-122.513245 48.134155,-122.540802
48.21064,-122.507858 48.253971,-122.403137 48


-Jukka Rahkonen- 




hectormauer wrote
> Oh, I see. That's great.
> 
> But what if the Database does not have ST_Transform support? Could we
> still
> achieve a similar approach by means of ogr2ogr?
> 
> (I should have mentioned this in my first email).
> 
> Thanks again!
> Hector
> 
> On Tue, 1 Dec 2020 at 20:14, jratike80 <

> jukka.rahkonen@

> >
> wrote:
> 
>> Hi,
>>
>> No, unfortunately it is not possible with one ogr2ogr command.
>>
>> You need two commands and you must use ogrinfo. Here an example about
>> adding
>> another geometry column and populating it with EPSG:3857 version of
>> original
>> EPSG:4326 geometries.
>>
>> ogrinfo PG:"host=localhost port=5432 dbname=test user=user
>> password=password" -sql "alter table states add column geom2 geometry"
>>
>> ogrinfo PG:"host=localhost port=5432 dbname=test user=user
>> password=password" -sql "update states set
>> geom2=ST_Transform(wkb_geometry,3857)"
>>
>> You can do all that is possible with SQL also with ogrinfo.
>>
>>
>> -Jukka Rahkonen-
>>
>>
>>
>> hectormauer wrote
>> > Hi all,
>> >
>> > I was wondering if someone knew if it's possible to project or
>> transform
>> > within the same table in a database, using ogr2ogr.
>> >
>> > What I mean is, I have a table with fields: id, id2, geom_wkt_27700 and
>> I
>> > would like, using a single command to create an extra column
>> > "geom_wkt_4326" for instance. It does not have to be of type geometry,
>> but
>> > could be text for instance.
>> >
>> > I guess the other plausible solution would be to create a temporary
>> table
>> > with that transformation on it and reference it to the first one by id
>> for
>> > instance.
>> >
>> > Any help is appreciated!
>> >
>> > Thanks,
>> > Hector
>> >
>> > ___
>> > gdal-dev mailing list
>>
>> > 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@.osgeo

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

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr project/transform CRS in the same database table

[jratike80]

Hi,

No, unfortunately it is not possible with one ogr2ogr command.

You need two commands and you must use ogrinfo. Here an example about adding
another geometry column and populating it with EPSG:3857 version of original
EPSG:4326 geometries.

ogrinfo PG:"host=localhost port=5432 dbname=test user=user
password=password" -sql "alter table states add column geom2 geometry"

ogrinfo PG:"host=localhost port=5432 dbname=test user=user
password=password" -sql "update states set
geom2=ST_Transform(wkb_geometry,3857)"

You can do all that is possible with SQL also with ogrinfo.


-Jukka Rahkonen-



hectormauer wrote
> Hi all,
> 
> I was wondering if someone knew if it's possible to project or transform
> within the same table in a database, using ogr2ogr.
> 
> What I mean is, I have a table with fields: id, id2, geom_wkt_27700 and I
> would like, using a single command to create an extra column
> "geom_wkt_4326" for instance. It does not have to be of type geometry, but
> could be text for instance.
> 
> I guess the other plausible solution would be to create a temporary table
> with that transformation on it and reference it to the first one by id for
> instance.
> 
> Any help is appreciated!
> 
> Thanks,
> Hector
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] warp srs: xyz format point cloud

[jratike80]

Hi,

Because you are changing from the raster world into vector world I would it
somehow
- convert raster in native CRS into xyz
- write a vector VRT file for converting xyz data into points
- re-project the point dataset with ogr2ogr

Converting data into PostGIS raster could be more elegant and allows to live
between the two worlds in a flexible way.

-Jukka Rahkonen-



Idan Miara wrote
> Hi all,
> 
> I have a UTM raster that I want to warp translate to xyz format and
> transform the coordinates to EPSG:4326, I could use:
> `gdalwarp -of xyz -t_srs EPSG:4326 utm.tif 4326.xyz`
> 
> But surely I get a 4326 grid, so my data points were altered to fit the
> new
> grid.
> I could write a function that iterates over the pixels and translates each
> point, but is there a more elegant way to transform coordinates without
> forcing the target srs grid?
> 
> Kind regards,
> Idan
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[jratike80]

Hi again,

Sorry, I did not read properly what you did. That should work and it does
work for me with GDAL 3.2. I use a copy of your test.tif as "test_00.tif".


gdal_translate -a_srs epsg:4647 test_00.tif test_000.tif
Input file size is 100, 100
0...10...20...30...40...50...60...70...80...90...100 - done.

gdalwarp -t_srs epsg:4326 test_000.tif test_4326_2.tif
Creating output file that is 125P x 73L.
Processing test_000.tif [1/1] : 0Using internal nodata values (e.g. -)
for image test_000.tif.
Copying nodata values from source test_000.tif to destination
test_4326_2.tif.
...10...20...30...40...50...60...70...80...90...100 - done.


-Jukka-


jratike80 wrote
> Hi,
> 
> What you have wrong is the input coordinate system, not the output as you
> tested.





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[jratike80]

Hi,

What you have wrong is the input coordinate system, not the output as you
tested.
Compare https://epsg.org/crs/wkt/id/25832 with
https://epsg.org/crs/wkt/id/4647 and notice the difference in false easting.

Now run gdalwarp right

gdalwarp -s_srs epsg:4647 -t_srs epsg:4326 test_00.tif test_4326.tif
Creating output file that is 125P x 73L.
Processing test_00.tif [1/1] : 0Using internal nodata values (e.g. -)
for image test_00.tif.
Copying nodata values from source test_00.tif to destination test_4326.tif.
...10...20...30...40...50...60...70...80...90...100 - done.

-Jukka Rahkonen-


yuchan wrote
> The tiff file you can download from https://files.fm/f/5ttjhyh9p
> The xyz file I already shared in the beginning:
> https://pastebin.com/40xSNqm4
> 
> Thanks,
> 
> 
> On Wed, 25 Nov 2020 at 11:10, Tobias Wendorff <

> tobias.wendorff@

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

> gdal-dev@.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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr is not working for a geojson file

[jratike80]

Hi,

What is your GDAL version (current is 3.2)? Do you get the same error with
ogr2ogr command line without launching it from Java?

-Jukka Rahkonen-


Ravi Teja Krishna Wuyyuru wrote
> Hi, 
> 
> 
> 
>       I have tried converting the file in Centos and Macos but I am facing
> an error as said below. I have analyzed and found that the issue occurs
> only when there is no properties data in geojson file. I have generated
> jars and library files using the java bindings of gdal. Is there any
> dependency that i might have missed cause this issue occurs only for these
> type of files (i.e with no properties data). Can someone help me in
> solving this error.
> 
> 
> Thanks & Regards,
> 
> Ravi Teja
> 
> 
> 
> 
> 
> 
>  On Mon, 23 Nov 2020 14:02:24 +0530 Wuyyuru Ravi Teja Krishna <

> ravitejakrishna.w@

> > wrote 
> 
> 
> Hi team,
> 
>       I am using ogr2ogr with java bindings for conversion of a geojson
> file to a csv file, But I am getting an error as specified below.
> 
> ERROR 10: Pointer 'panMap' is NULL in 'OGR_F_SetFrom'.
> 
> 
> 
> Unable to translate feature 0 from layer map_sample
> 
> Terminating translation prematurely after failed
> 
> translation of layer map_sample (use -skipfailures to skip errors)
> 
> 
> 
> ogr2ogr is invoked as below
> 
> 
> 
> java -cp :gdal.jar -Djava.library.path=libs/ ogr2ogr "-s_srs" "CRS:84"
> "-t_srs" "CRS:84" "-f" "CSV" proplesscsv.csv map_sample.geojson  "-lco"
> "GEOMETRY=AS_WKT"
> 
> I have also attached the sample file I was working with this mail. Kindly
> help me in this conversion failure.
> 
> 
> Thanks & Regards,
> 
> Ravi Teja
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] ogr2ogr is not working for a geojson file

[jratike80]

Hi,

I don't know that Java stuff but at least there does not seem to be anything
wrong with your data nor  ogr2ogr. Your command runs without errors on
Windows and ogr2ogr binary (GDAL version 3.2).

-Jukka Rahkonen- 



Ravi Teja Krishna Wuyyuru wrote
> Hi team,
> 
>       I am using ogr2ogr with java bindings for conversion of a geojson
> file to a csv file, But I am getting an error as specified below.
> 
> ERROR 10: Pointer 'panMap' is NULL in 'OGR_F_SetFrom'.
> 
> 
> 
> Unable to translate feature 0 from layer map_sample
> 
> Terminating translation prematurely after failed
> 
> translation of layer map_sample (use -skipfailures to skip errors)
> 
> 
> 
> ogr2ogr is invoked as below
> 
> 
> 
> java -cp :gdal.jar -Djava.library.path=libs/ ogr2ogr "-s_srs" "CRS:84"
> "-t_srs" "CRS:84" "-f" "CSV" proplesscsv.csv map_sample.geojson  "-lco"
> "GEOMETRY=AS_WKT"
> 
> I have also attached the sample file I was working with this mail. Kindly
> help me in this conversion failure.
> 
> 
> Thanks & Regards,
> 
> Ravi Teja
> ___
> gdal-dev mailing list

> gdal-dev@.osgeo

> https://lists.osgeo.org/mailman/listinfo/gdal-dev
> 
> 
> map_sample.geojson (647 bytes)
> ;





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Motion: adopt RFC 77 Drop Python 2 support in favor of Python 3.6

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> given the positive feedback of the discussion phase, and since our CI is
> now 
> ready for it, I motion to adopt
> 
> RFC 77: Drop Python 2 support in favor of Python 3.6
> https://github.com/OSGeo/gdal/pull/3142
> 
> Starting with my +1
> 
> Even





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] GDAL_WCS Driver and gdal_translate

[jratike80]

Hi,

Just a note to remind that earlier in thread "gdal-dev Digest, Vol 198,
Issue 14" it was noticed that the GDAL WCS driver most probably has a bug
and certain WCS coverages from Geoserver do not work. It seems to be related
with the native CRS EPSG:4326. So if you test now with Geoserver, don't test
with nurc__Img_Sample or other coverages which are in EPSG:4326.

I know this does not answer your question, sorry.

-Jukka Rahkonen-


juliermeopensourcedeveloper wrote
> Dear all,
> 
> I would like to open this discussion here about creating a xml/ raster wcs
> ingest using gdal_translate.
> My 2 goals are:
> 1 - get a xml like in [1] by running command line similar do gdal_wmts
> driver in [2]
> 
> gdal_translate "WCS:
> http://demo.geo-solutions.it:80/geoserver/wcs?version=2.0.1&coverage=nurc__Img_Sample
> ;
> " wcs.xml -of WCS
> 
> *OR*
> 
> gdal_translate "WCS:
> http://demo.geo-solutions.it/geoserver/ows?service=WCS&request=getCapabilities,layer=nurc__Img_Sample
> " wcs.xml -of WCS
> 
> 
> 2 - get a xml / raster subset
> 
> gdal_translate "WCS:
> http://demo.geo-solutions.it:80/geoserver/wcs?version=2.0.1&coverage=nurc__Img_Sample
> ;
> " wcs.xml -projwin -100 40 -80 30 -of WCS
> 
> *OR*
> 
> gdal_translate "WCS:
> http://demo.geo-solutions.it/geoserver/ows?service=WCS&request=getCapabilities,layer=nurc__Img_Sample
> " wcs.xml -projwin -100 40 -80 30 -of WCS
> 
> If the solution I am trying to get can not be possible through
> gdal_translate, would someone have an xml sample like in [1] to share, but
> with raster subset ingest, instead the whole image content?
> 
> I appreciated your time in advance.
> 
> Kind regards
> 
> Julierme
> 
> [1] 
> 
>   
> 
> https://demo.geo-solutions.it/geoserver/wcs?version=2.0.1&
> ;
> 
>   
> 
> nurc:Img_Sample
> 
> 
> 
> &BoundingBox=-130.85168,20.7052,-62.0054,54.1141
> 
> 
> [2] gdal_translate "WMTS:
> http://maps.wien.gv.at/wmts/1.0.0/WMTSCapabilities.xml,layer=lb"; wmts.xml
> -
> of WMTS.
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Passing open options along dataset name in a string ?

[jratike80]

Hi,

I have done some helpdesk work within the GDAL community and I know well
that the open options and config options are confusing. I also know that
they exists for a reason but simplified and uniform way to use them would be
nice.

Some comments on comments:

>> gdalinfo my.tif -oo GEOREF_SOURCES=WORLDFILE,PAM
>>

> Ideally this would be baked into the format, but, yes, I think we've got a
> bead on dataset open options.

I don't know how it could be baked into the format. The option gives user an
option to override wrong GeoTIFF georeferencing with wordfile, for example.

>> gdalinfo BAG:"data/test_vr.bag":supergrid:0:1
>>

> DRIVER:"file":something

> Right. This will require some work because of multiple colons. Though I've
> never seen BAG driver data in the wild. Is this a real live format?

As far as I know BAG is the hdf of bathymetry and widely used in that
context.

>> gdalinfo data/test_vr.bag -oo MODE=RESAMPLED_GRID -oo SUPERGRIDS_MASK=YES
>> gdalinfo HDF5:"d:\foo.he5"://HDFEOS/SWATHS/foo/bar
>>

> HDF5 driver, filename using Windows drive, and UNC path within it. This is
> marginal, right?

The part beginning with // is not UNC path but the name of the subdataset
within hdf5 file https://gdal.org/drivers/raster/hdf5.html. Not more
marginal than HDF5 itself.

>> ogrinfo OCI:warmerda/password@.dreadfest

>Wat?

Text has just been formatted into email link because of the @ sign that
belongs to the Oracle connection string "username" / "password" @ "the name
of the Oracle database as it appears in the tnsnames.ora file". Let's see if
formatting happens again when I send this from Nabble:

OCI:warmerda/passw...@gdal800.dreadfest.com abc.shp

-Jukka Rahkonen-




Sean Gillies-3 wrote
> Hi Even,
> 
> On Wed, Nov 4, 2020 at 9:01 AM Even Rouault <

> even.rouault@

> >
> wrote:
> 
>> > > Another particularity we have in GDAL is that the dataset name might
>> be
>> > > almost
>> > > anything. Most of the time, it is a regular file path, or some /vsi
>> path.
>> > > But
>> > > sometimes, it can be JSON content (the GeoJSON driver accepts the
>> content
>> > > to
>> > > be directly provided as the dataset name), or XML (VRT, WMS drivers).
>> > > We have also the subdataset syntax "HDF5:foo.hdf:my_variable"
>> >
>> > Could VRT XML and JSON be exempted? We already have a way to embed open
>> > options in the XML.
>>
>> If the gdn: mechanism is a new possibility offered that doesn't exclude
>> existing ones (otherwise that would be a pretty big breaking change), we
>> could
>> possibly exempt the odd cases I mentioned (or have some quoting/escaping
>> rules
>> to enable that payload to be seen as a file), which generally don't need
>> a
>> "permanent" way of refering to the dataset like gdn: would offer, since
>> this
>> is content often generated programatically or retrieved dynamically.
>>
>> Covering subdataset would be a more important use case. Something that
>> would
>> have to be decided if the way we express subdatasets would be somehow
>> standardized or if it would be a black-box string for the gdn:
>> encapsulation.
>> For a black-box approach, we would have to define some escaping/quoting
>> rules
>> to avoid any potential issue with separators of the gdn syntax. If we
>> decide
>> that the subdataset syntax is part of what is standardized by GDN that
>> would
>> be a more challenging exercice, because the subdataset syntax varies from
>> driver to driver.
>>
> 
> The variation of subdataset syntax among drivers is a bug, let's try to
> fix
> this.
> 
> It seems to me that the internet way to address subdatasets would be to
> use
> a # URL fragment. But since most of our formats and the servers that serve
> files of these formats are not aware, we may have to come up with
> something
> different. We may need to consider making subdatasets a layer opening
> option?
> 
> pending on how we design things, that might impact between:
>> - just GDALOpen() generic code if GDALOpen() decodes the gdn: string to
>> decompose it into 'classic' dataset names and open options
>> - all drivers if the gdn: string would be passed to each
>> GDALDriver::pfnOpen()
>> implementation
>> - intermediate situation if we decide to drop (at least for future
>> drivers)
>> per-driver subdataset syntax (which has deficiencies has the quoting
>> rules
>> to
>> separate the filename from the non-filename component vary from driver to
>> driver, and are most of the time not defined) to come up with something
>> more
>> standardized
>>
>> To help brainstorming, a non-exhaustive overview of a few situations
>> mixing
>> driver prefixing, subdataset syntax and open options:
>>
>> gdalinfo my.tif
>>
> 
> Yes. We have to handle bare paths to local dataset files.
> 
> 
>> gdalinfo my.tif -oo GEOREF_SOURCES=WORLDFILE,PAM
>>
> 
> Ideally this would be baked into the format, but, yes, I think we've got a
> bead on dataset open options.
> 
> 
>> gdalinfo GTIFF_DIR:0:d:\my.tif
>>
> 
> WTF is this? :)
> 
> 
>> gdalinfo EEDAI:my/asset
>>

Re: [gdal-dev] gdal-dev Digest, Vol 198, Issue 14

[jratike80]

Hi Ari,

I fear that user cannot control this with the switches. This is the reason
for the error:

```
WCS: Requesting
http://demo.geo-solutions.it/geoserver/wcs?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=nurc__mosaic&SUBSET=Long(6.3953399152693953,6.3953399152693953)&SUBSET=Lat(46.541601968340089,46.541601968340089)&Format=image/tiff

```

Thus GDAL creates subsets with lower limit = upper limit which makes the
bbox into a point. That it probably not intentional. I think it is done with
the code that begins from
https://github.com/OSGeo/gdal/blob/master/gdal/frmts/wcs/wcsdataset.cpp#L562

If theory interests, there has been discussions within the OGC WCS group
about the validity of such request. It may be that the server should expand
the bbox and send tiff with one pixel as an output. If the subsets were
written for slicing
SUBSET=Long(6.3953399152693953)
&SUBSET=Lat(46.541601968340089)
then tiff as outputformat is not possible because image has always  two
dimensions but here 0 dimensionality (point) is requested. But this is a
sidepath because I believe that the WCS driver wants to read a small area
from WCS as a sample, not just one pixel.

-Jukka-


Ari Jolma-2 wrote
> 2) gdalinfo 
> "WCS:https://demo.geo-solutions.it/geoserver/wcs?version=2.0.1&coverage=nurc__Img_Sample";
> 
> .. takes again some time as it makes calls and then it stores new data 
> into the cache
> 
> - 
> cJLrY=https://demo.geo-solutions.it/geoserver/wcs?version=2.0.1&coverage=nurc__Img_Sample
> - three files: cJLrY.xml, cJLrY.xml.aux.xml, cJLrY.DC.xml, the first is 
> the WCS_GDAL XML
> 
> and prints
> 
> ERROR 1: HTTP error code : 404
> ERROR 1: InvalidSubsetting: Empty intersection after subsetting
> 
> so it probably needs some special switches, which are described in the 
> documentation.
> 
> Best,
> 
> Ari





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Location change on gdalwarp reprojection

[jratike80]

Hi,

The bounds do not mean exactly what you think. Re-projecting a rectangular
image from EPSG:27573 into EPSG:4326 rotates the image somewhat
counter-clockwise. This image is from another context
https://www.usgs.gov/media/images/landsat-1-8-landsatlook-image-examples but
you can get the idea. The new bounds report the min-max coordinates of the
envelope that contains that rotated image. The corners of the original image
are not at the corners of the warped image. That explains why WGS 84 bounds
in EPSG:3857 are different.

The difference when you warp to EPSG:27573  may mean that the coordinate
system of the original image is not EPSG:27573, at least not for the Proj
library. What happens with command:

gdalwarp -s_srs EPSG:27573 -t_srs EPSG:27573 orig.tif
from_27573_into_27573.tif

-Jukka Rahkonen-




Evert Etienne (SITEMARK) wrote
> It does not happen when just warping, but it does occur when warping to
> the same EPSG as can be seen in the follow logs
> ```
> orig.tif
> EPSG:27573
> bounds [828662.0710931281, 3203193.9700861075, 829595.8710931281,
> 3204344.6700861077]
> EPSG:27573 bounds [828662.0710931281, 3203193.9700861075,
> 829595.8710931281, 3204344.6700861077]
> EPSG:3857 bounds [578066.9358574335, 5479808.142856716, 579420.0775091586,
> 5481457.907968456]
> EPSG:4326 bounds [5.192863637248721, 44.09275933293886, 5.205019115521942,
> 44.103402376252255] <- OK
> gdalwarp orig.tif justwarp.tif
> justwarp.tif
> EPSG:27573
> bounds [828662.0710931281, 3203193.9700861075, 829595.8710931282,
> 3204344.6700861077]
> EPSG:27573 bounds [828662.0710931281, 3203193.9700861075,
> 829595.8710931282, 3204344.6700861077]
> EPSG:3857 bounds [578066.9358574335, 5479808.142856716, 579420.0775091586,
> 5481457.907968456]
> EPSG:4326 bounds [5.192863637248721, 44.09275933293886, 5.205019115521945,
> 44.103402376252255] <- SAME
> gdalwarp -t_srs EPSG:27573 orig.tif noreproj.tif
> noreproj.tif
> EPSG:27573
> bounds [829527.7905651039, 3748136.6066527413, 830468.8074871361,
> 3749294.6346238866]
> EPSG:27573 bounds [829527.7905651039, 3748136.6066527413,
> 830468.8074871361, 3749294.6346238866]
> EPSG:3857 bounds [608015.3560148155, 6272484.6841915725,
> 609507.2374494626, 6274297.96416575]
> EPSG:4326 bounds [5.461894872874811, 48.98599094207838, 5.475296671823179,
> 48.99667932763942] <- CHANGED
> ```
> 
> GDAL info of orig.tif:
> ```
> Driver: GTiff/GeoTIFF
> Files: orig.tif
> Size is 18676, 23014
> Coordinate System is:
> PROJCRS["NTF (Paris) / Lambert zone III",
> BASEGEOGCRS["NTF (Paris)",
> DATUM["Nouvelle Triangulation Francaise (Paris)",
> ELLIPSOID["Clarke 1880 (IGN)",6378249.2,293.466021293627,
> LENGTHUNIT["metre",1]]],
> PRIMEM["Paris",2.5969213,
> ANGLEUNIT["grad",0.0157079632679489]],
> ID["EPSG",4807]],
> CONVERSION["unnamed",
> METHOD["Lambert Conic Conformal (1SP)",
> ID["EPSG",9801]],
> PARAMETER["Latitude of natural origin",54.5,
> ANGLEUNIT["grad",0.0157079632679489],
> ID["EPSG",8801]],
> PARAMETER["Longitude of natural origin",0,
> ANGLEUNIT["grad",0.0157079632679489],
> ID["EPSG",8802]],
> PARAMETER["Scale factor at natural origin",0.999877499,
> SCALEUNIT["unity",1],
> ID["EPSG",8805]],
> PARAMETER["False easting",60,
> LENGTHUNIT["metre",1],
> ID["EPSG",8806]],
> PARAMETER["False northing",320,
> LENGTHUNIT["metre",1],
> ID["EPSG",8807]]],
> CS[Cartesian,2],
> AXIS["easting",east,
> ORDER[1],
> LENGTHUNIT["metre",1]],
> AXIS["northing",north,
> ORDER[2],
> LENGTHUNIT["metre",1]],
> ID["EPSG",27573]]
> Data axis to CRS axis mapping: 1,2
> Origin = (828662.071093128062785,3204344.670086107682437)
> Pixel Size = (0.052,-0.058)
> Metadata:
>   AREA_OR_POINT=Area
> Image Structure Metadata:
>   COMPRESSION=LZW
>   INTERLEAVE=PIXEL
> Corner Coordinates:
> Upper Left  (  828662.071, 3204344.670) (  3d 7'33.28"E, 48d59'48.23"N)
> Lower Left  (  828662.071, 3203193.970) (  3d 7'30.95"E, 48d59'11.01"N)
> Upper Right (  829595.871, 3204344.670) (  3d 8'19.19"E, 48d59'46.98"N)
> Lower Right (  829595.871, 3203193.970) (  3d 8'16.85"E, 48d59' 9.76"N)
> Center  (  829128.971, 3203769.320) (  3d 7'55.07"E, 48d59'28.99"N)
> Band 1 Block=256x256 Type=Byte, ColorInterp=Red
>   Overviews: 9338x11507, 4669x5754, 2335x2877, 1168x1439, 584x720,
> 292x360, 146x180
>   Mask Flags: PER_DATASET ALPHA 
>   Overviews of mask band: 9338x11507, 4669x5754, 2335x2877, 1168x1439,
> 584x720, 292x360, 146x180
>   Unit Type: metre
> Band 2 Block=256x256 Type=Byte, ColorInterp=Green
>   Overviews: 9338x11507, 4669x5754, 2335x2877, 1168x1439, 584x720,
> 292x360, 146x180
>   Mask Flags: PER_DATASET ALPHA 
>   Overviews of mask band: 9338x11507, 4669x

Re: [gdal-dev] Oracle Spatial Driver: Is it possible to append features to a table?

[jratike80]

Hi,

It should work. Write your two first ogr2ogr commands (the initial one and
first to append) as a whole but without OCI connection details. The -nln
parameter must appear in the append command if I remember right.

-Jukka Rahkonen-



Kreß, Marius wrote
> Dear GDAL developers and users,
> 
> I want to write contour polygons into an Oracle Spatial database. Because
> the area is quite large, I would like to calculate them in smaller boxes
> and write them into the table one after the other. But as far as I can
> see, it is not possible to append features to a table. You can only create
> a new one, overwrite or truncate it. Even if I first write it into a
> shapefile and then try to write it in the database with ogr2ogr, it
> ignores the -append and -update options.
> 
> Is it correct that it doesn't work or did I miss anything? Do you know a
> better solution?
> 
> Thanks for your help,
> 
> Marius Kress
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] WCS_GDAL Driver Image SubSet Request

[jratike80]

Hi,

Do you want to make is somehow impossible to request data beyound the
BoundingBox that you defined in the XML file? If you just want to get data
from the rectangle that you or your users define, gdal_translate with the
regular -spat option should work out-of-the-box.

-Jukka Rahkonen- 


juliermeopensourcedeveloper wrote
> Hi all,
> 
> Is it possible to define a bounding box in order to request a coverage
> subset using the GDAL WCS Driver?
> I have tried the code in [1]. I  am trying to get information only for the
> bbox_interest=( -58,-11,-57.75,-10.75) as shown below, however the subset
> image or bbox_interest request has not been delivered. The West Longitude
> reaches -50.17 and The Lower Latitude reaches -18.92 which are limits out
> of the bbox_interest.
> The image extent is:
> 
> &BoundingBox=-63.280290728152664,-13.794296142085976,-53.624004749255874,-5.636644661059637
> 
>  Any comment on this issue will be greatly appreciated.
> Thank you very much for your time in advance.
> *CODE [1]:*
> 
> 
> http://172.21.14.45:6060/geoserver/wcs?version=1.0.0&;
>  ServiceURL>
> 
> cbers_deter_amazonia:CBERS-4_AWFI_170_111_21052020
>  CoverageName>
> 
> &BoundingBox=-58,-11,-57.75,-10.75
> 
> 
> 
> Generated from GeoTIFF
> 
> 
> cbers_deter_amazonia:CBERS-4_AWFI_170_111_21052020
> 
> 
> CBERS-4_AWFI_170_111_21052020
> 
> 
> 
> -58 -11
> 
> 
> -57.75 -10.75
> 
> 
> 
> 
> WCS
> 
> 
> GeoTIFF
> 
> 
> 
> 
> 
> 
> -58 -11
> 
> 
> -57.75 -10.75
> 
> 
> 
> 
> 
> 
> 0 0
> 
> 
> 0 0
> 
> 
> 
> 
> x
> 
> 
> y
> 
> 
> 
> -58 -10.75
> 
> 
> 
> 0.005364603321609328 0.0
> 
> 
> 0.0 -0.004532028600570188
> 
> 
> 
> 
> 
> 
> 
> CBERS-4_AWFI_170_111_21052020
> 
> 
> CBERS-4_AWFI_170_111_21052020
> 
> 
> 
> 
> Band
> 
> 
> Band
> 
> 
> 
> 
> 1
> 
> 
> 4
> 
> 
> 
> 
> 
> 
> 
> 
> 
> EPSG:4326
> 
> 
> 
> 
> GeoTIFF
> 
> 
> GIF
> 
> 
> JPEG
> 
> 
> PNG
> 
> 
> TIFF
> 
> 
> 
> 
> nearest neighbor
> 
> 
> bilinear
> 
> 
> bicubic
> 
> 
> 
> 
> GeoTIFF
> 
> 
> 4
> 
> 
> Byte
> 
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[jratike80]

Hi,

This does not really belong to my knowledge area but I'll have a try anyway.

Check what you have after reading the proj string instead. Here with Python

>>> from osgeo import osr
>>> spatialRef = osr.SpatialReference()
>>> spatialRef.ImportFromProj4("+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0
>>> +lon_0=0.0 +x_0=0.0 +y_0=0 +k=1.0 +units=m +nadgrids=@null
>>> +towgs84=0,0,0,0,0,0,0 +wktext +no_defs")
>>> print(spatialRef)
PROJCS["WGS 84 / Pseudo-Mercator",
GEOGCS["WGS 84",
DATUM["WGS_1984",
SPHEROID["WGS 84",6378137,298.257223563,
AUTHORITY["EPSG","7030"]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG","6326"]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG","8901"]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG","9122"]],
AUTHORITY["EPSG","4326"]],
PROJECTION["Mercator_1SP"],
PARAMETER["central_meridian",0],
PARAMETER["scale_factor",1],
PARAMETER["false_easting",0],
PARAMETER["false_northing",0],
UNIT["metre",1,
AUTHORITY["EPSG","9001"]],
AXIS["Easting",EAST],
AXIS["Northing",NORTH],
EXTENSION["PROJ4","+proj=merc +a=6378137 +b=6378137 +lat_ts=0 +lon_0=0
+x_0=0 +y_0=0 +k=1 +units=m +nadgrids=@null +wktext +no_defs"]]


It means that GDAL makes a clever guess and considers that the Proj string
that you provided means EPSG:3857. You probably mean the same. And in the
EPSG database EPSG:3857 is based on WGS84 ellipsoid
https://epsg.org/crs/wkt/id/3857

 ELLIPSOID["WGS 84",6378137,298.257223563,

and that it behaves in spherical way is handled by a special conversion

CONVERSION["Popular Visualisation Pseudo-Mercator",

I am not sure what to do if you definitely want to keep the ball with
diameter of 6378137 meters but perhaps dropping +nadgrids=@null could do it.
If EPSG:3857 is what you really need then it takes less writing to import by
the EPSG code but your way gives the same result.

-Jukka Rahkonen-





Andreas Roth wrote
> Hi,
> 
> I call OSRImportFromProj4 with
> "+proj=merc +a=6378137 +b=6378137 +lat_ts=0.0 +lon_0=0.0 +x_0=0.0 +y_0=0
> +k=1.0 +units=m +nadgrids=@null +towgs84=0,0,0,0,0,0,0 +wktext +no_defs"
> 
> and with the returned handle i get the major and minor axis (
> OSRGetSemiMajor/OSRGetSemiMinor). I would expect the both axis to be
> equal,
> but they aren't.
> Instead i'm getting the following result:
> semi_major_axis=6378137
> semi_minor_axis=6356752.314
> 
> Build on Ubuntu 20.10 (groovy; amd64) with libgdal-dev,
> version 3.1.3+dfsg-1ubuntu2) and libproj-dev:amd64 with version 7.1.0-1
> 
> The full example application code:
> https://pastebin.com/xf8QpVhM
> 
> Regards,
> Andreas
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] Retrieving 3DEP data via GDAL's WCS driver...

[jratike80]

Hi,

By adding "-- debug on" into your command it is possible to get details
about what GDAL is doing. Here are the main parts from the log

gdal_translate
"WCS:https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?version=2.0.1&coverage=DEP3Elevation";
test.tif -projwin -107.03 37.28 -107 37.25 -projwin_srs EPSG:4326 -tr 100
100 --debug on

GDAL:
GDALOpen(WCS:https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?version=2.0.1&coverage=DEP3Elevation,
this=02944175BD50) succeeds as WCS.
GDAL: Using GTiff driver
Input file size is 40075015, 20498394
GDAL: Using GTiff driver
0GDAL: GDAL_CACHEMAX = 1632 MB
GDAL: GDALDatasetCopyWholeRaster(): 33*42 swaths, bInterleave=0
WCS: DirectRasterIO(8122982,14330794,3340,4196) -> (33,42) (1 bands)

WCS: Requesting
https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=DEP3Elevation&SUBSET=x%28-20037507.067213,-11911185.14836644%29&SUBSET=y%284474012.1150791775,4478208.115037268%29&SCALESIZE=x%2833%29,y%2842%29&Format=image/tiff
HTTP:
Fetch(https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=DEP3Elevation&SUBSET=x%28-20037507.067213,-11911185.14836644%29&SUBSET=y%284474012.1150791775,4478208.115037268%29&SCALESIZE=x%2833%29,y%2842%29&Format=image/tiff)
HTTP: libcurl/7.70.0-DEV OpenSSL/1.1.1g zlib/1.2.3
WCS: GDALOpenResult() on content-type: multipart/related; boundary="wcs";
start="GML-Part"; type="text/xml"
GDAL: GDALOpen(/vsimem/wcs/02944175BD50/wcsresult.dat,
this=029441C0D9A0) succeeds as GTiff.
GDAL: GDALClose(/vsimem/wcs/02944175BD50/wcsresult.dat,
this=029441C0D9A0)
...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.

Image test.tif looks somehow corrupted from the right side.
The only WCS request that GDAL sends can be found from the log. I removed
url-encoding for clarity

https://elevation.nationalmap.gov:443/arcgis/services/3DEPElevation/ImageServer/WCSServer?SERVICE=WCS&REQUEST=GetCoverage&VERSION=2.0.1&COVERAGEID=DEP3Elevation&SUBSET=x(-20037507.067213,-11911185.14836644)&SUBSET=y(4474012.1150791775,4478208.115037268)&SCALESIZE=x(33),y(42)&Format=image/tiff

Unfortunately the server returns the GeoTIFF within a multipart content with
some GML. I do not know how to extract the GeoTIFF from the multipart
package so I could compare the results obtained by using WCS service
directly with curl or a browser. But because GDAL does not do much for the
result, just extract the tiff part and write it into separate GeoTIFF, I
suppose that it is the WCS server that generates the corrupted output.
However, the request that GDAL sends feels odd to me. Compare the projwin in
gdal_translate command with subsets in the GetCoverage

 -projwin -107.03 37.28 -107 37.25
SUBSET=x(-20037507.067213,-11911185.14836644)
SUBSET=y(4474012.1150791775,4478208.115037268)

Subract the numbers and notice that subset x is 8126321.919 meters while
subset y is 4196 meters. 
I can see number 4196 also in this line of the log
WCS: DirectRasterIO(8122982,14330794,3340,4196) -> (33,42) (1 bands)

Perhaps the meaning is to create SUBSET=x() so that it is 3340 meters wide,
not 8126322? And maybe the ESRI WCS server creates a corrupted tiff when it
receives a somewhat lunatic request?

-Jukka Rahkonen-




  






--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

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

[jratike80]

+1

-Jukka Rahkonen-


Even Rouault-2 wrote
> Hi,
> 
> Having heard about no critical ([1]) issues regarding RC1
> 
> Motion:
> 
> Adopt GDAL 3.2.0 RC1 as final 3.2.0 release
> 
> Starting with my +1
> 
> Even
> 
> [1] The only regression I'm aware of currently is regarding the
> possibility to 
> open raw LERC1 files in the MRF driver that is broken. See
> https://github.com/OSGeo/gdal/pull/3109 . A possibility I was hardly aware
> of. 
> Can likely wait for 3.2.1 IMHO





--
Sent from: http://osgeo-org.1560.x6.nabble.com/GDAL-Dev-f3742093.html
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev

Re: [gdal-dev] https://stackoverflow.com/questions/61342237/gdal-translate-missing-spatial-reference-system

[jratike80]

Hi,

But you did not find out what is special in the spatial reference of your
source image and why GDAL 3.0.2 did not find it while 2.4.1 had no problem.
First step would be to run gdalinfo with 2.4.1 and 3.0.2 and compare the
reports.

-Jukka Rahkonen- 


Laurynas Gedminas wrote
> OK, so the issue was related on the GDAL 3.0.2  not able to read raster
> spatial reference,
> downgraded my installation to 2.4.1 GDAL and the the code:
> translateoptions = gdal.TranslateOptions(gdal.ParseCommandLine("-co
> TILED=YES -co COMPRESS=JPEG -co JPEG_QUALITY=100 -a_nodata none -co
> INTERLEAVE=BAND -scale -ot Byte"))
> gdal.Translate(out_img, in_ds, options=translateoptions)
> 
> Worked just fine,
> Thank you,
> Laurynas
> 
> On Thu, Oct 22, 2020 at 1:25 PM Laurynas Gedminas <

> laurynasgedminas@

>> wrote:
> 
>> Here are the correct posts links:
>>
>> I am using the Python GDAL 3.0.2,
>> facing the issue with the gdal.translate, posted question here as well:
>> https://stackoverflow.com/questions/64484225/gdal-translate-with-projection
>>
>> and this person seems to have the same issue:
>>
>> https://stackoverflow.com/questions/61342237/gdal-translate-missing-spatial-reference-system
>>
>> Thank you,
>> Laurynas
>>
>> On Thu, Oct 22, 2020 at 11:15 AM Laurynas Gedminas <
>> 

> laurynasgedminas@

>> wrote:
>>
>>> I am using the Python GDAL 3.0.2,
>>> facing the issue with the gdal.translate, posted question here as well:
>>>
>>> https://stackoverflow.com/questions/64484225/gdal-translate-with-projection
>>>
>>> and this person seems to have the same issue:
>>>
>>> https://stackoverflow.com/questions/64484225/gdal-translate-with-projection
>>>
>>> Thank you,
>>> Laurynas Gedminas
>>>
>>
> 
> ___
> gdal-dev mailing list

> 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
https://lists.osgeo.org/mailman/listinfo/gdal-dev