aux.xml sidecar files with some geotiffs, leading to downstream issues and
confusion.
Would be great to hear any other thoughts on best practices and options using
current and future versions of GDAL/PROJ/GeoTIFF.
--
David Shean
Civil and Environmental Engineering
Universi
Hi Even,
Thanks for the pointer to this resource, and for working to support this
important functionality.
Would it make sense to add the -a_coord_epoch option to gdal_edit.py, so users
can directly update the GeoTiff header for a dataset with known epoch?
-David
--
David Shean
Civil and
Hi Even and Javier,
For the special case of a DEM, would it make more sense to specify the units
with a vertical CRS? This approach would define the LENGTHUNIT and the
associated vertical datum.
Example for EPSG:4979:
AXIS["ellipsoidal height (h)",up,
ORDER[3],
Hi Even,
This seems like a good idea, as there are many academic users who will cite.
Not volunteering to take this on, but setting up a DOI is relatively easy with
Zenodo and Github integration:
https://docs.github.com/en/repositories/archiving-a-github-repository/referencing-and-citing-content
Hi Even,
Many thanks for looking into this and pushing a fix so quickly. Some follow up
responses inline.
D
> On Dec 5, 2018, at 10:08 AM, Even Rouault wrote:
>
> David,
>
> Ah, shouldn't have looked at this, as with all sub-pixel issues, it took me
> hours to figure it out, but the good new
Hi list,
I am seeing some sub-pixel inter-tile offsets in the output of warped vrt
products. I am a big fan of vrt and use regularly, but this is the first time
that I’ve noticed this issue. I am hoping that there is a simple workaround.
I’ve isolated a simple test case from a larger project.
Hi all,
This is also possible with the dem_mosaic tool, part of the NASA Ames Stereo
Pipeline toolkit. The utility is multithreaded and meant to handle an
arbitrary number of large rasters efficiently. You want the ‘—max’ command
line option.
Unfortunately, the official NASA ASP site is curre
, first, last, stddev, count,
etc.). I recommend that you start with the default weighted average option.
Documentation, binaries (Linux and OSX), and source code are available here:
https://ti.arc.nasa.gov/tech/asr/intelligent-robotics/ngt/stereo/.
-David
---
David Shean
Polar Science
Even,
I encountered the issue you mention back in May:
http://osgeo-org.1560.x6.nabble.com/gdal-dev-ReprojectImage-and-nodata-td5057270.html
The current ReprojectImage nodata handling is a bit confusing. Do you see a
relatively simple fix to mirror the behavior of gdalwarp?
Thanks.
-David
that gdal_translate puts them in a single
>> file...
>>
>> I would advise you convert them all to netcdf using gdal_translate and then
>> use python-netcdf4 (not the one from numpy/scipy) to stack them in the
>> temporal dimension.
>>
>>
>> On Mon, Sep 2,
Hi list,
I'm trying to package a timeseries of GTiff rasters with identical
projection/extent/resolution as a single NetCDF file for distribution. I've
spent the past hour consulting the online doc and playing with gdal_translate,
gdalbuildvrt and gdalwarp without any success.
Is there an ea
Hi list,
I'm having some issues with the Python ReprojectImage function not respecting
nodata.
My input dataset has nodata value -32767. I am using ReprojectImage to
resample and warp the src_ds in memory to match the resolution and srs of a
second dataset. The output of ReprojectImage has no
Frank and Andreas,
I've experienced similar issues for years when using EPSG codes for polar
stereographic projections (e.g., EPSG:3031, EPSG:3413). Thanks for reporting
Andreas.
My workaround for this issue is to provide the full proj4 string to gdalwarp
instead of the EPSG code. This strin
Hi Etienne and Jan,
For what it's worth, I would also use a gdalwarp gauss interpolation method.
I've found that the gdaladdo gauss interpolation provides the best anti-aliased
downsampling, especially for rasters that contain many small nodata holes
surrounded by valid data. Cubic and lanczos
Even,
This sounds great. I'm guessing RPC in this context stands for "Remote
Procedure Call." It seems like this could potentially lead to some confusion
with existing GDAL functionality (e.g., gdal_rpc.cpp) and options (e.g.
RPC_DEM) where RPC stands for "Rational Polynomial Coefficients" use
While the topic of gdaladdo resampling methods is active...
I get bus errors when I use gdaladdo's gauss resampling method for large,
float32, LZW-compressed GTiff. This is repeatable.
Using a different gdaladdo resampling method (e.g., average) on the same
LZW-compressed GTiff works.
When I de
Michael,
Scott is right. Not sure if this is the preferred approach, but I accomplished
this for large datasets by specifying buffer sizes for ReadAsArray. The doc I
consulted is here:
http://gdal.org/python/osgeo.gdal_array-module.html#BandReadAsArray.
I used masked arrays to exclude nodata
e fix. Lesson learned -
always consult the source code before asking for help.
-David
On Sep 12, 2011, at 5:24 PM, David Shean wrote:
> Hi all,
> I'm having some trouble with artifacts in the output from gdalwarp when using
> RPCs and a DEM for orthorectification. The artifact
f desired. On the whole, the image appears
properly orthorectified, which is fantastic, but these artifacts are
problematic for my application. Thanks for any advice/assistance.
-David
---
David Shean
Polar Science Center
Applied Physics Lab
University of Washington
__
t I'm not reinventing a slower, clunkier wheel.
Thanks.
-David
---
David Shean
Polar Science Center
Applied Physics Lab
University of Washington
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
20 matches
Mail list logo
