Folks:
USGS, in their infinite wisdom, decided to embed what is effectively a
1-bit, 16-band byte-interleaved-by-pixel image into a 16-bit, single-band
geotiff for the Landsat quality mask. I could write some crazy translation
program that "reverse engineers" the data, but I was wondering if ther
GDALers:
I love the gdalbuildvrt -> gdal_translate trick for large mosaicks, but I
have a somewhat more complicated problem I was hoping I could get some help
on. Given a large set of overlapping images, I want to mosaic using the
following "rules": 1) all overlapping pixels should be averaged to
Folks:
Is there any trick to "stacking" multiple *multiband* files via
gdalbuildvrt for further use with e.g. gdal_translate? Basically, this
restriction using "separate":
"In that case, only the first band of each dataset will be placed into a
new band."
Is causing problems -- I want to have A
sizes,
etc.
J
On Tue, Dec 1, 2015, 1:40 PM Even Rouault
wrote:
> Le mardi 01 décembre 2015 20:34:10, Jonathan Greenberg a écrit :
> > GDAL Developers:
> >
> > How do I go about requesting a new driver? R's "raster" format is a
> pretty
> > straight
GDAL Developers:
How do I go about requesting a new driver? R's "raster" format is a pretty
straightforward flat binary/header format (very similar to ENVI's). The
specifications are laid out in:
https://cran.r-project.org/web/packages/raster/vignettes/rasterfile.pdf
I think this would be a ni
Will the "old way" be removed from future updates? Or will the binary
utilities be retained?
--j
On Fri, Oct 9, 2015 at 1:27 PM Even Rouault
wrote:
> Le vendredi 09 octobre 2015 19:43:28, Jonathan Greenberg a écrit :
> > Folks:
> >
> > I wanted to let you know
Folks:
I wanted to let you know I've pushed a major release of my gdalUtils
package to CRAN in the last week. This wraps all non-python GDAL/OGR
utilities as of GDAL 2.0.1 for use in R, and provides some value-added
functions as well.
install.packages("gdalUtils")
should work for all OSs, or if
Folks:
Is it possible to create a vrt comprised of other vrts? For a mosaicking
problem, say I want to first trim the margins of the individual tiles by a
certain number of pixels -- I can, of course, gdal_translate this but this
adds a bunch of new files/processing time -- can I use gdalbuildvrt
Folks:
I've got a weird one -- I'm trying to perform a mosaic of GeoTIFF tiles
that are somewhat overlapping. Here's the odd issue -- I need the mosaic
to basically set all values of 0 AND "NODATA" to be the srcnodata. How do
I do this? Will gdalbuildvrt automatically use "true" NODATA values t
GDALers:
Quick question: if I'm using the gdalbuildvrt -> gdal_translate trick to
mosaic images, where I have "holes" (missing tiles), how do I set the value
of the regions where there is no image? Is this done in gdalbuildvrt or
gdal_translate?
--j
__
GDALers:
We're trying to figure out a good algorithm for computing topographic slope
for Alaska, which is both huge and near the pole. Our DEM is currently in
geographic coordinates, but we need slope over a fixed distance (change in
elevation vs. horizontal meters). The issue is, there is no pr
stall), so the two conflict with one another. I'll install two
versions moving forward, unless someone has a better solution!
Reference: http://www.hdfgroup.org/HDF-FAQ.html#11share
--j
On Tue, Oct 14, 2014 at 1:12 PM, Jonathan Greenberg wrote:
> Gdallers:
>
> I'm having some is
Gdallers:
I'm having some issues with a source-built GDAL's support of HDF4 on a
Linux box. I've repeated this with both GDAL 1.10.1 and 1.11.1. The
HDF is a landsat HDF:
@server> gdalinfo "/pathro/lndsr.LT51950531990333ESA00.hdf"
ERROR 4: Failed to open HDF4 file
"/pathto/lndsr.LT5195053199033
Folks:
I'm running a gdalwarp on a sinusoidal MODIS class image to longlat,
using a modal resample (and cropping the output). The warp is
clipping off a circular region of North America and Australia. I am
using multithreaded mode, but I confirmed this error also occurs in
sequential mode. The
ies distribution models). This is a common enough task that
it would be nice to see this as a feature in e.g. gdalwarp, if it
isn't already.
--j
On Thu, Mar 27, 2014 at 5:27 PM, Tim Keitt wrote:
>
>
>
> On Thu, Mar 27, 2014 at 4:26 PM, Jonathan Greenberg
> wrote:
>>
>
GDALers:
What is the most efficient way, given a "reference raster", and an
arbitrary raster (we'll call it "unsynced") synced together to allow
them to be stacked: the output of this should be the unsynced raster
with the same number of rows, columns, pixel size, upper left
coordinates, and proje
GDALers:
I've not had this error before when compiling GDAL for Linux boxes, but I'm
getting some sqlite error. This is from:
./configure --prefix=/pathto/wherever --with=python
make
***
...
chmod a+x gdal-config
/bin/sh /projects/oa/shared/jgrn/code/src/gdal-1.10.1/libtool --mode=link
g++
I'm simply filling in some of the gaps in rgdal's capabilities.
--j
On Thu, Nov 14, 2013 at 7:59 AM, Nick Ves wrote:
> sounds really cool.
>
> One question though: Whats the difference between gdalUtils and rgdal?
>
> On Sat, Oct 19, 2013 at 4:13 AM, Jonathan Greenberg
>
GDALers:
I'm working with a colleague on a new set of R wrappers for GDAL, and
we are at the point where we are starting to document the functions.
Our R interface is designed to be VERY close to the GDAL command line
utilities (we use the same parameter names, for instance), so I was
wondering if
This is an old(ish) thread but I wanted to follow-up since I've been
dealing with SMB2 and GIS stuff recently and came across this in my
searches. Some of this is specific to reading files from a Samba
server (linux, typically), but modern Windows file servers have a
similar problem. A couple of
ity)?
--j
On Thu, May 30, 2013 at 3:50 PM, Etienne Tourigny
wrote:
>
>
> On Thu, May 30, 2013 at 4:46 PM, Jukka Rahkonen > wrote:
>
>> Jonathan Greenberg illinois.edu> writes:
>>
>> >
>> > Folks:
>> > I'm using a Windows install of GDAL
Folks:
I'm using a Windows install of GDAL 1.7.0 (FWTools) -- when I run:
gdal_translate -sds -of "GTiff" [some.hdf] "myoutput"
The output filenames do not have the .tif extension. If I set the output
file to "myoutput.tif", it appends the "layer numbers" to the end of the
file, e.g. myoutput.t
GDALers:
Is there a way to easily crop one image to the the extent of another image?
--j
--
Jonathan A. Greenberg, PhD
Assistant Professor
Global Environmental Analysis and Remote Sensing (GEARS) Laboratory
Department of Geography and Geographic Information Science
University of Illinois at Urba
I was recently looking into for some code I'm writing in R using rgdal, and
I wanted to see if we could generate some new effort on this. While the
way each file format specifies RS information may be different, there are
some standard pieces of info that could be read/stored in a meaningful way
w
GDALers:
Hope this isn't too much of a noobish question. Given two images, A
and B, I want to have B match A in terms of projection, extent, and
resolution such that A and B will stack perfectly. The tricky part
here, and one I'm not sure how to solve is that while they are both
global datasets
Thanks! This was really helpful! Cheers!
--j
On Thu, May 3, 2012 at 7:20 PM, Frank Warmerdam wrote:
> On Thu, May 3, 2012 at 8:35 AM, Jonathan Greenberg
> wrote:
> > Gdalers:
> >
> > I'm working on some parallel processing routines via rgdal and R, but
> &g
Gdalers:
I'm working on some parallel processing routines via rgdal and R, but
thought this question was better answered here. I'm trying to find out
which raster formats are simply a flat binary file an a header. ENVI is
the one that springs to mind. We're trying to work up which files can be
ALClose(11MAY05170702-P1BS-052548267010_01_P001.NTF, this=0x669450)
--j
On Thu, Apr 12, 2012 at 2:47 PM, Frank Warmerdam wrote:
> On Thu, Apr 12, 2012 at 12:40 PM, Jonathan Greenberg
> wrote:
>> GDALers:
>>
>> I've got some DigitalGlobe Worldview-2 files in NITF form
GDALers:
I've got some DigitalGlobe Worldview-2 files in NITF format, but I'm
not able to convert it from NITF to ENVI:
> gdal_translate -of ENVI 11MAY05170702-M1BS-052548267010_01_P001.NTF
> 11MAY05170702-M1BS-052548267010_01_P001.envi
[some time passes]
Input file size is 9216, 6144
0ERROR 4:
[Colleagues: Please forward this to any interested parties. Thanks!]
The Department of Geography in the School of Earth, Society and
Environment at the University of Illinois at Urbana-Champaign is
looking for a Lecturer to fill a key teaching position in our
Geographic Information Science curricu
GDALers:
I'm trying to get gdal2tiles to give me a zoom level that displays the
raw, full resolution, un-resampled pixels at a certain zoom level.
What zoom (-z) setting should I use? I am very confused what,
precisely, the zoom levels refer to in terms of pixels/unit area. My
input data is a 50
think you will have to modify the gdal_retile.py script[1] yourselves.
> Can you explain what you mean by the shapefile of the results?
>
> [1]:
> http://trac.osgeo.org/gdal/browser/trunk/gdal/swig/python/scripts/gdal_retile.py
>
> On Wed, Aug 24, 2011 at 2:17 AM, Jonathan Greenbe
GDALers:
I really like gdal.retile.py, but I'm now facing an issue where I want
to tile a file but have *overlap* between each tile. Is there a way
to do this using existing GDAL utilities? I want the outputs to be
geotiffs, and (ideally, but not required) I'd like a shapefile
generated of the r
t;
> gdal_translate -of gtiff output.vrt output.tif
>
>
>
> for more complicated scaling you may need to hand write a vrt
>
> http://www.gdal.org/gdal_vrttut.html
>
> Brian
>
> On Wed, 2011-06-08 at 19:31 -0700, Jonathan Greenberg wrote:
> > Nikos and GDALers:
separately)? Alternatively, how would I get
rgb2pct.py working on the above image correctly? Thanks!
--j
On Wed, Jun 8, 2011 at 4:10 PM, Nikolaos Hatzopoulos wrote:
> why you don't try rgb2pct http://www.gdal.org/rgb2pct.html?
>
> --Nikos Hatzopoulos
>
> On Wed, Jun
Folks:
I am using a piece of software which is relying on an older version of GDAL
that doesn't have the "fix" to deal with > 8 bit geotiffs (it is trying to
make a jpeg overlay but can't from a 16 bit image. I think this is the
issue: http://trac.osgeo.org/gdal/wiki/TIFF12BitJPEG), but when I do
GDALers:
Say I have two rasters, A and B with different projections, extents,
and resolution. I want to make B match A, such that the projection,
resolution, and extent (filling in with some arbitrary value where
there is no data) all match. Is there a quick way to do this using
command line gda
:"MCD15A2.
> A2002185.h12v05.005.2007172035551.hdf":MOD_Grid_MOD15A2:LaiStdDev_1km'
> test2.tif
> Input file size is 1200, 1200
> 0...10...20...30...40...50...60...70...80...90...100 - done.
>
> --Nikos Hatzopoulos
>
>
> On Mon, May 9, 2011 at 5:56 PM, Jonathan
Folks:
I did a Debian install of both the "unstable" and the "experimental"
versions of GDAL, and when running gdal_translate on a MODIS HDF4 file
I'm getting a segmentation fault. gdalinfo works fine tho. Thoughts?
$ gdal_translate -ot Float32 -of ENVI
HDF4_EOS:EOS_GRID:MCD15A2.A2002185.h35v10
Even:
Thanks: how would I "wildcard" this into a gdalbuildvrt? The files all
follow the pattern MCD15A2.A2002185.h14v10.005*
--j
On Sat, Apr 30, 2011 at 11:26 AM, Even Rouault wrote:
> Le samedi 30 avril 2011 17:34:28, Jonathan Greenberg a écrit :
> > GDALers:
> >
GDALers:
I have recently come across the mosaicking magic that is 1) build a vrt usin
gdalbuildvrt and then 2) gdal_translate the vrt to whatever format I want --
I'm noticing this is a crazy-fast way to do mosaicking compared to some
other techniques. My current issue is that I have a set of MOD
Sorry for the cross-posting. I was wondering if anyone has a unix (preferably)
or windows program that can spider a directory, recursively searching for
raster and vector data, and create bounding box polygons for each raster/vector
it finds, with attributes indicating the path-to-file.
--
J
R-geographers...
I'm trying to solve a problem to implement a line-by-line tiled
processing using RGDAL (read 1 line of an image, process the one line,
write one line of the image to a binary file). Everything except for
the final step I'm able to do using a combination of RGDAL and r-base
c
Nikos:
Have you checked out any of the new minirasterstrip features in
starspan yet? It takes vector data (any format that OGR supports),
extracts a window (user defined size) around the vector out of a set of
rasters (anything that GDAL supports), compiles it into a single image,
and ref
I want to back up Even's statement about trying to read a file
piece-by-piece. About 99% of raster processes are better handled with
"tiled" processing -- a nice balance between i/o, memory and sanity
would be to read the image one line at a time, perform your processing
on that line, write th
45 matches
Mail list logo
