Re: [gdal-dev] gdal_translate with -projwin possible bug
Hey Lauren, I can replicate this with my Win64 installation of 2.1 (the conda-forge build). Thanks for the heads up, i also do this all the time. Not having to calculate the exact extent was one of the benefits of using projwin. The current behavior could probably also be achieved with gdal_warp and nn-resampling for example, so at least for me its also an unwelcome change. The srcwin option probably still leaves the pixel placement untouched, but that would often require an additional conversion to pixel coordinates. I think this also impact's the 'clipper' in QGIS, since the latest (2.16) also ships with GDAL 2.1. Regards, Rutger -- View this message in context: http://osgeo-org.1560.x6.nabble.com/gdal-dev-gdal-translate-with-projwin-possible-bug-tp5278296p5278303.html Sent from the GDAL - Dev mailing list archive at Nabble.com. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal_translate with -projwin possible bug
Hello all, I've noticed what I think may be a bug with gdal_translate, just looking for further information before deciding whether to report it. In version 1.11.4 and earlier, using the -projwin tag to subset a raster produces an output whose cell alignment and content matches the source dataset - it just grabs any cells that intersect the box and writes them to the output. In v2.1.0 (at least in a Windows environment), this no longer occurs. The output raster is distorted to match the exact extent of the -projwin coordinates. No resampling is involved, but the cell origins shift, and the cell sizes are either shrunk or stretched slightly to conform to the projwin box. This is a substantial change in behaviour which doesn't appear to have been documented. >From my point of view, its an unwelcome change. I've been using gdal_translate with -projwin and vsicurl to clip out sections of large national datasets without having to download the whole file first, and without needing to know things like the source dataset origin, cellsize etc in order to ensure output aligns with input. I need each dataset I clip out to 'stack' properly, and to represent an unaltered subset of the source data. Please let me know if this is a true bug or just an undocumented change, and/or if there's a better alternative command to use. Regards, Lauren O'Brien ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Transforming rasters with the C API
Hello, I'm trying to transform a raster into a different projection using the public C functions exposed in gdal_alg.h I have some code that I have been testing using the functions GDALCreateGenImgProjTransformer() and GDALGenImgProjTransform(): https://gist.github.com/monkeybutter/8367132e9683a4eb823a0175586a25b1 Obviously I'm doing something wrong (the code segment faults), but I cannot find any example or tutorial that explains how this operations should be performed. Does anyone have a recommendation or example that shows this functionality? Thank you very much for your help, Kind regards, Pablo ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Time for a new GeoJSON driver?
On Mon, Jul 25, 2016 at 4:39 PM, Even Rouault wrote: > Hi Sean, > > > The GeoJSON WG's draft-ietf-geojson, > > https://datatracker.ietf.org/doc/draft-ietf-geojson/, is in the RFC > Editor > > queue and will be published soon. I'm considering whether adoption of the > > updated GeoJSON (registered media type: application/geo+json) and support > > for the older GeoJSON format (no registered media type) might be helped > by > > creating an entirely new driver. > > > > A separate driver would keep the existing driver from becoming even more > > complicated, yes? We would also have an opportunity to remove unnecessary > > configuration options and support for other JSON formats that aren't > really > > GeoJSON. > > I'm not completely sure we need a new driver just to support the revised > geo+json spec. It is still mostly compatible with the original spec, right > ? > > From what I can see, the differences / new specifications are : > - SRS fixed to CRS84 > - antimeridian cutting > - right hand rule of polygons > - bbox and the poles&antimeridian > - the media type > > Am I missing something ? > Two things (the full list of changes is at https://tools.ietf.org/html/draft-ietf-geojson-04#appendix-B.1): 1. GeoJSON objects MUST NOT contain the defining members of other types. For example, a GeoJSON Feature must not have a "features" member. I don't see this coming up when converting from other formats, but OGR's GeoJSON driver should filter these out of native data when writing GeoJSON. 2. Implementations SHOULD NOT extend position arrays beyond 3 elements. The OGR driver should not by default write anything other than X, Y, Z. If it currently writes X, Y, Z, and M, the M should be omitted. There's one informative change in https://tools.ietf.org/html/draft-ietf-geojson-04#appendix-B.2 that is relevant. When GeoJSON output is CRS84 only we can certainly reduce the default coordinate precision from 15 to 6 or 7. > > On the reading side, I think the existing driver requires little > modification > (extending "Accept: text/plain, application/json" to "Accept: text/plain, > application/json, application/geo+json" for http:// or https:// datasource > names) , so essentially the writing side would be affected. > > Regarding: > - the right hand rule of polygons, it could be a new behaviour in all > cases ( > the shapefile driver e.g. modifies the winding order to comply with the > shapefile > spec ) > - SRS fixed to CRS84, it is a matter of automatically reprojecting the > input > data to it if it is not CRS84, like done in the KML driver. That could be a > default behaviour, with an option to use the deprecated crs object if > really > needed. > - antimeridian cutting: can make sense as a default behaviour if the target > SRS is CRS84. With the difficulty in doing the cutting properly ( ogr2ogr - > wrapdateline heuristics can perhaps be improved ) > - bbox and antimerdian: if the geometry has been cut by the geojson > driver, it > is obvious to make the bbox conformant to the requirement. If it has been > cut > in a previous stage ( e.g in a geo+json->geo+json conversion), then you > need > to detect that the geometry has been cut ( its extent is -180 180) and then > detect the extent of its parts > - bbox and the poles : if the geometry is already in CRS84, then it looks > like > it should be just a matter of computing the bbox in the standard way from > the > geometry coordinates. If the geometry must be reprojected, then the issue > is > more the reprojection of the geometry itself : > https://lists.osgeo.org/pipermail/gdal-dev/2016-July/044776.htm > > None of that really seems to call for forking a new driver. > Automatic reprojection to CRS84 would break existing systems that counted on preservation of CRS. Addition of a configuration option like OGR_GEOJSON_2008=TRUE would help, but this would still be a breaking change, would it not? > In the new spec, elevations are explictly ellipsoidal heights. In the old > spec, it wasn't explicit. Although I'm not sure all elevations passed in a > (x,y,z) triplet with x,y being in CRS84 are really ellipsoidal heights in > practice, this is probably out of scope of the driver ( unless it would be > fed > with a SRS that would explictly specify the VERTCS and thus vertical datum > transformation could potentially be done ) > > > > > Does anyone feel that the existing driver code *would not* be a good > place > > to start and that we shouldn't arrive at a new driver by copying the > > existing GeoJSON driver and removing unneeded code? > > What could possibly justify a new driver to me is a driver that would > support > reading geojson files of arbitrary size without fully ingesting them into > memory. That would have probably quite a big impact on the existing code > base, > especially since GDAL 2.1 where the driver assumes in-memory ingestion to > be > able to provide the update support. > I do not know how OGR supports in-place update of GeoJSON, but I'll take y
Re: [gdal-dev] gdalwarp -rpc with RPC_DEM default behavior not as described
Patrick, Thanks for the report. It was indeed not working as documented. Fixed per https://trac.osgeo.org/gdal/ticket/6608 Even > Hi all, > > We've been making some orthos with gdalwarp (gdal version 2.1.1) and > encountering resampling errors in the output (gittery output in the lines > in certain spots). Long story short, explicitly setting the "-et" option > to "0" fixed it, but the docs for gdalwarp say the following (under the -et > flag description): > > "starting with GDAL 2.1, the RPC_DEM warping option is specified, in which > case, an exact transformer, i.e. err_threshold=0, will be used" > > Here's an example of the call we're making where we see the artifacts: > > gdalwarp -t_srs EPSG:3857 -rpc -to RPC_DEM=dem.tif in.tif out.tif > > and this guy fixes it: > > gdalwarp -et 0 -t_srs EPSG:3857 -rpc -to RPC_DEM=dem.tif in.tif out.tif > > I'm guessing the flag is not actually being set, but if anyone can point me > to the code where this default is supposed to be set when the dem is > specified, I might be able to provide a fix or figure out that I'm doing it > wrong! I didn't have much luck searching through the github archive. > > Thanks! > > -Patrick -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdalwarp -rpc with RPC_DEM default behavior not as described
Hi all, We've been making some orthos with gdalwarp (gdal version 2.1.1) and encountering resampling errors in the output (gittery output in the lines in certain spots). Long story short, explicitly setting the "-et" option to "0" fixed it, but the docs for gdalwarp say the following (under the -et flag description): "starting with GDAL 2.1, the RPC_DEM warping option is specified, in which case, an exact transformer, i.e. err_threshold=0, will be used" Here's an example of the call we're making where we see the artifacts: gdalwarp -t_srs EPSG:3857 -rpc -to RPC_DEM=dem.tif in.tif out.tif and this guy fixes it: gdalwarp -et 0 -t_srs EPSG:3857 -rpc -to RPC_DEM=dem.tif in.tif out.tif I'm guessing the flag is not actually being set, but if anyone can point me to the code where this default is supposed to be set when the dem is specified, I might be able to provide a fix or figure out that I'm doing it wrong! I didn't have much luck searching through the github archive. Thanks! -Patrick ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Motion: adopt RFC 63 : Sparse datasets improvements
On 2016-07-26 11:00 AM, Even Rouault wrote: Hi, I move to adopt RFC 63 : Sparse datasets improvements https://trac.osgeo.org/gdal/wiki/rfc63_sparse_datasets_improvements --- Starting with my +1 Even +1 on the overall idea and proposed solution. +0 on the implementation details as I'm not the most qualified to comment on those details. -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Tickets that mention e00
On 2016-07-26 9:17 AM, Even Rouault wrote: On Tuesday 26 July 2016 07:08:02 Jukka Rahkonen wrote: Hi, I wonder how likely it is that the tickets dealing with Arc/Info coverages http://www.gdal.org/drv_avce00.html will still receive some bug fixes. Would it be a big mistake to close them all as won't fix? Hi Jukka, unless a maintainer pops up, that sounds like an appropriate action. Even Agreed. BTW, if it helps we could move the upstream AVCBin/AVCE00 source to github so that Even and others GDAL devs can update them. Daniel -- Daniel Morissette http://www.mapgears.com/ T: +1 418-696-5056 #201 http://evouala.com/ - Location Intelligence Made Easy ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Motion: adopt RFC 63 : Sparse datasets improvements
Hi, I move to adopt RFC 63 : Sparse datasets improvements https://trac.osgeo.org/gdal/wiki/rfc63_sparse_datasets_improvements --- Starting with my +1 Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_edit with ECW, parameter woes, documentation is probematic
Yes, that looks good. But also adapting the pages that use -co NAME=VALUE - such as http://www.gdal.org/gdal_translate.html -co "NAME=VALUE": Passes a creation option to the output format driver. Multiple -co options may be listed. See format specific documentation for legal creation options for each format. -co "NAME=VALUE": Passes a creation option to the output format driver. Multiple -co options may be listed. See format specific documentation for legal creation options for each format. would also be good, leading the searcher swiftly to the needed page where they can select their needed format to look up the possible parameter combinations. Mark ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] (no subject)
On Tuesday 26 July 2016 16:37:14 Hema Yeedunuri wrote: > aded images which uses wms services. I tried opening with > gdalopen it is not working . the output format supported in geoserver is > png / geotiff . but for a single band data the no. of bands i am getting > are 3 . and null data is coming. Hema, You can change the number of bands returned by the WMS driver by setting the element. See http://gdal.org/frmt_wms.html Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] gdal_edit with ECW, parameter woes, documentation is probematic
Mark, I've tried to incorporate your feedback in this changeset: @@ -173,6 +173,16 @@ the PROJ, DATUM or UNITS with SetMetadataItem(), the later values will override the values built from the projection string. +All those can for example be modified with the -a_ullr, -a_srs or -mo switches +of the gdal_edit.py utility. + +For example: + +gdal_edit.py -mo DATUM=WGS84 -mo PROJ=GEODETIC -a_ullr 7 47 8 46 test.ecw + +gdal_edit.py -a_srs EPSG:3068 -a_ullr 20800 22000 24000 19600 test.ecw + + File Metadata Keys: @@ -190,7 +200,12 @@ COLORSPACE COMPRESSION_DATE COMPRESSION_RATE_ACTUAL -COMPRESSION_RATE_TARGET +COMPRESSION_RATE_TARGET. This is the percentage of the target compressed +file size divided by the uncompressed file size. This is equal to +100 / (100 - TARGET) where TARGET is the value of the TARGET +creation option used at file creation, so a COMPRESSION_RATE_TARGET=1 is +equivalent to a TARGET=0 (ie no compression), COMPRESSION_RATE_TARGET=5 is +equivalent to TARGET=80 (ie dividing uncompressed file size by 5), etc... VERSION Even > While writing this, I figured put most of the problems, so this note will > be more about suggestion in making the documentation more usable. > > I am going to receive an amount of ecw files that, for whatever reason, do > not contain the georeferenced information. > > For the first image received, gdalinfo shows the following: > > Driver: ECW/ERDAS Compressed Wavelets (SDK 3.x) > Files: 1989.423C_42348.5000.ecw > Size is 8001, 6001 > Coordinate System is `' > Metadata: > COLORSPACE=GREYSCALE > COMPRESSION_RATE_TARGET=5 > VERSION=2 > Corner Coordinates: > Upper Left (0.0,0.0) > Lower Left (0.0, 6001.0) > Upper Right ( 8001.0,0.0) > Lower Right ( 8001.0, 6001.0) > Center ( 4000.5, 3000.5) > Band 1 Block=256x256 Type=Byte, ColorInterp=Gray > Description = Grayscale > Overviews: 4000x3000, 2000x1500, 1000x750, 500x375, 250x187 > > Since I know the position, I did the following: > > 1) gdal_translate -of GTiff -a_nodata 135 -a_srs EPSG:3068 -a_ullr 20800 > 22000 24000 19600 1989.423C_42348.5000.ecw 1989.423C_42348.5000.3068.tif > > 2) gdal_translate -of ECW -co TARGET=0 -a_srs EPSG:3068 > 1989.423C_42348.5000.3068.tif 1989.423C_42348.5000.3068.tif.ecw > > gdalinfo now shows the projection information. > - but with 'COMPRESSION_RATE_TARGET=1' instead of 5 > -- no doubt due to the '-co TARGET=0' (which I have no idea what it means) > > gdal_translate has a note with the '-co' > 'See format specific documentation for legal creation options for each > format' > a: http://www.gdal.org/formats_list.html";>See format specific > documentation for legal creation options for each format > which then leads to http://www.gdal.org/frmt_ecw.html > - where TARGET is then explained (percentage) > -- but no explanation on what 'COMPRESSION_RATE_TARGET' is > ---> '-co TARGET=50' (percent) = 'COMPRESSION_RATE_TARGET=2' > ---> '-co TARGET=75' (percent) = 'COMPRESSION_RATE_TARGET=4' > ---> '-co TARGET=99.99' (percent) = 'COMPRESSION_RATE_TARGET=9997' > A comparison chart would be useful here > - comparing what gdalinfo shows to what gdal_translate needs > (I still do not know what TARGET setting is needed to get > COMPRESSION_RATE_TARGET=5) > > What I would like to know is: can gdal_edit.py be used to achieve the same > result? > - base on another found sample, I worked this out, since I have never used > the combination -a_srs/-a_ullr before > -- wasted a lot of time in the past creating a world-file for this task > > gdal_edit -a_srs EPSG:3068 -a_ullr 20800 22000 24000 19600 > 1989.423C_42348.5000.ecw > > So for both 'gdal_translate' and 'gdal_edit' a practical sample to set the > missing georeferenced information would be useful > - while searching I saw a lot of reports of people receiving ecw file 'raw' > and wondering how to get it in > > Once one knows it, it is easy > But it has be hours since I found this sample: > gdal_edit -mo DATUM=WGS84 -mo PROJ=GEODETIC -a_ullr 7 47 8 46 test.ecw > > and trying to adapt it to work with a non-wsg84 system. > > Mark Johnson, Berlin Germany -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Tickets that mention e00
On Tuesday 26 July 2016 07:08:02 Jukka Rahkonen wrote: > Hi, > > I wonder how likely it is that the tickets dealing with Arc/Info coverages > http://www.gdal.org/drv_avce00.html will still receive some bug fixes. Would > it be a big mistake to close them all as won't fix? Hi Jukka, unless a maintainer pops up, that sounds like an appropriate action. Even -- Spatialys - Geospatial professional services http://www.spatialys.com ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] gdal_edit with ECW, parameter woes, documentation is probematic
While writing this, I figured put most of the problems, so this note will be more about suggestion in making the documentation more usable. I am going to receive an amount of ecw files that, for whatever reason, do not contain the georeferenced information. For the first image received, gdalinfo shows the following: Driver: ECW/ERDAS Compressed Wavelets (SDK 3.x) Files: 1989.423C_42348.5000.ecw Size is 8001, 6001 Coordinate System is `' Metadata: COLORSPACE=GREYSCALE COMPRESSION_RATE_TARGET=5 VERSION=2 Corner Coordinates: Upper Left (0.0,0.0) Lower Left (0.0, 6001.0) Upper Right ( 8001.0,0.0) Lower Right ( 8001.0, 6001.0) Center ( 4000.5, 3000.5) Band 1 Block=256x256 Type=Byte, ColorInterp=Gray Description = Grayscale Overviews: 4000x3000, 2000x1500, 1000x750, 500x375, 250x187 Since I know the position, I did the following: 1) gdal_translate -of GTiff -a_nodata 135 -a_srs EPSG:3068 -a_ullr 20800 22000 24000 19600 1989.423C_42348.5000.ecw 1989.423C_42348.5000.3068.tif 2) gdal_translate -of ECW -co TARGET=0 -a_srs EPSG:3068 1989.423C_42348.5000.3068.tif 1989.423C_42348.5000.3068.tif.ecw gdalinfo now shows the projection information. - but with 'COMPRESSION_RATE_TARGET=1' instead of 5 -- no doubt due to the '-co TARGET=0' (which I have no idea what it means) gdal_translate has a note with the '-co' 'See format specific documentation for legal creation options for each format' a: http://www.gdal.org/formats_list.html";>See format specific documentation for legal creation options for each format which then leads to http://www.gdal.org/frmt_ecw.html - where TARGET is then explained (percentage) -- but no explanation on what 'COMPRESSION_RATE_TARGET' is ---> '-co TARGET=50' (percent) = 'COMPRESSION_RATE_TARGET=2' ---> '-co TARGET=75' (percent) = 'COMPRESSION_RATE_TARGET=4' ---> '-co TARGET=99.99' (percent) = 'COMPRESSION_RATE_TARGET=9997' A comparison chart would be useful here - comparing what gdalinfo shows to what gdal_translate needs (I still do not know what TARGET setting is needed to get COMPRESSION_RATE_TARGET=5) What I would like to know is: can gdal_edit.py be used to achieve the same result? - base on another found sample, I worked this out, since I have never used the combination -a_srs/-a_ullr before -- wasted a lot of time in the past creating a world-file for this task gdal_edit -a_srs EPSG:3068 -a_ullr 20800 22000 24000 19600 1989.423C_42348.5000.ecw So for both 'gdal_translate' and 'gdal_edit' a practical sample to set the missing georeferenced information would be useful - while searching I saw a lot of reports of people receiving ecw file 'raw' and wondering how to get it in Once one knows it, it is easy But it has be hours since I found this sample: gdal_edit -mo DATUM=WGS84 -mo PROJ=GEODETIC -a_ullr 7 47 8 46 test.ecw and trying to adapt it to work with a non-wsg84 system. Mark Johnson, Berlin Germany ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] (no subject)
hi all , I have build gdal-1.11.2 with libcurl support to read wms layers.it is build sucessfully how can i read wms layers .I have geoserver on my loalhost.I have loaded images which uses wms services. I tried opening with gdalopen it is not working . the output format supported in geoserver is png / geotiff . but for a single band data the no. of bands i am getting are 3 . and null data is coming. thanks, hema ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Tickets that mention e00
Hi, I wonder how likely it is that the tickets dealing with Arc/Info coverages http://www.gdal.org/drv_avce00.html will still receive some bug fixes. Would it be a big mistake to close them all as won't fix? -Jukka Rahkonen- ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
