# Tag Info

0

From http://www.gdal.org/frmt_ecw.html For those still using the ECW 3.3 SDK, images less than 500MB may be compressed for free, while larger images require licensing from ERDAS. See the licensing agreement and the LARGE_OK option. So you are out of luck with the 5.1 SDK without a valid license. Depending on your OS, you might still catch a copy of the ...

0

I think the utility you are looking for is gdal2tiles: gdal2tiles.py input_file output_dir

0

I use this on 14.04, what have you tried? apt-get install libhdf4-dev apt-get install proj-bin apt-get install libproj-dev apt-get install libgdal-dev apt-get install gdal-bin This is a broad simplification, but: GDAL is geared to use what you have in your system. If I have libhdf4-dev installed and then I install GDAL, my GDAL 'comes with HDF4 ...

0

I was able to get around this problem by using ReadRaster: from osgeo import gdal,ogr ds = gdal.Open( 'C:/Data/TestFiles/DtedFile.DT1' ) rb=ds.GetRasterBand(1) import struct xsize = rb.XSize ysize = rb.YSize datatype = rb.DataType #Reading the raster values values = rb.ReadRaster( 0, 0, xsize, ysize, xsize, ysize, datatype ) #Conversion between GDAL ...

1

If the dataset should cover the whole African continent, the CRS information is wrong, and WGS84 should be right. If it is really a local CRS, covering 71m eastwards and 73.5m northwards, you have to set up a local CRS on the point of (0;0), which you have to collect with GPS or offical surveying information: +proj=tmerc +lat_0=.... +lon_0=.... +k=0.9999 ...

0

gdal_calc.py as stated in documentation: http://www.gdal.org/gdal_calc.html uses numpy array functions, in this case numpy.maximum, which is specified here: http://docs.scipy.org/doc/numpy/reference/generated/numpy.maximum.html It says you can use only 2 parameters. So your calculation expression for three grids must look like this: ...

0

Try to go to spatial reference To find specific proj4 definition

0

This same error threw me off, too. Adding NODATA transparency value parameter to the call fixed it for me, so instead of dal2tiles.py -z 1-10 ~/hfp_wgs/hdr.adf hpf-tiles I called dal2tiles.py -z 1-10 -a 0,0,0 ~/hfp_wgs/hdr.adf hpf-tiles and it started working. Note that the value had to be three numbers, one for each of RGB channels.

0

She will need the GDAL package, which comes with the gdal_polygonize.py script when python support is enabled at compile time. It sounds like she already has the python bindings installed, so she likely already has GDAL. If she can locate the GDAL install directory, try looking under its /bin subdirectory--it should be there. If she finds it, just add ...

0

After a bit of tinkering with my program I've managed to pull the Layer name and its elements/variables! See code below on how to do it :) void main() { // Register your drivers OGRRegisterAll(); // Get your wfs here - (M_DATASOURCE IN HEADER) m_datasource = OGRSFDriverRegistrar::Open(m_ui->m_line_wfs_name->text().toStdString().c_str(), ...

0

Thanks a lot for you Answer, but I think so the problem ..... look at this!!! david@XXXX:/media/fuse/dat3/modis/mod10a1/raw/monthly/regular/stack/dayly/2013_06$./crea_comandos_py.sh map: MCD10A1_2013152.tif map: MCD10A1_2013153.tif map: MCD10A1_2013154.tif map: MCD10A1_2013155.tif map: MCD10A1_2013156.tif map: MCD10A1_2013157.tif map: MCD10A1_2013158.tif ... 1 Fiona doesn't support updating existing layers by design. You'll need to read your existing data in, make the changes you need, and write to a new file. 0 Because this array (input raster) includes 31 values: array=(A B C D E F G H I J K L M N O P Q R S T U V W X Y Z a b c d e) and this one (output raster) only includes 29; where raster "L" and raster "e" are missing: (A+B+C+D+E+F+G+H+I+J+K+M+N+O+P+Q+R+S+T+U+V+W+X+Y+Z+a+b+c+d)/30 However, the script would be (you have to repeat the letters): ... 2 With gdal_calc.py is, for example, --type Float32 (my answer based in your link). The next command worked for me when I used to calculate at-satellite brightness temperature: gdal_calc.py -A b6.rad.tif --calc "1260.56/log((607.76/A)+1)" --type Float32 --outfile bright_temp.tif I hope that helps. 2 Edit based on the comments below: Assigning the gdal_array.SaveArray(a, "test.tif") call to a variable returns an osgeo.gdal.Dataset object that can be managed as a per the below gotchas. Using the above example this should work: a = np.arange(300).reshape((3, 10, 10)) ds = gdal_array.SaveArray(a, "test.tif") ds = None ... 0 In general, you may simply enable the GDAL-internal geotiff: ./configure \ --with-geotiff=internal --with-libtiff=internal ... Rationale: Citation from the manual page: "When built with internal libtiff or with libtiff >= 4.0, GDAL also supports reading and writing BigTIFF files (evolution of the TIFF format to support files larger than 4 GB)." 3 I would recommend you using Python OGR API for creating workflows. Here is a link to a good tutorial how to install GDAL/Python etc on Windows. You will find tons of workflow examples in the internet. 2 You are only inspecting osm_id field. It seems you didn't inspect your multipolygons table. On a local use case, I do : ogrinfo -so france.simple.spatialite multipolygons It returns FID Column = OGC_FID Geometry Column = GEOMETRY osm_id: String (0.0) osm_way_id: String (0.0) name: String (0.0) type: String (0.0) ... So the identifiers are not only ... 1 I've had similar issues with gdalwarp producing black strips around image edges. Usually these happen around the international dateline, but your edges appear to be around the central meridian instead so it's no wonder you wind up with an empty strip in the middle of the output GeoTIFF. Try playing around with the -wo SOURCE_EXTRA=XXX argument. Depending ... 2 As of a week or so ago, the Anaconda packaging of GDAL now includes all of the projection files. The install command for the Anaconda packaging of GDAL is % conda install gdal The projection files are stored under$ANACONDA/gdal/share\$ so settingGDAL_DATA` to this path is all that is needed to avoid the problems I was having above. % export ...

0

There is not any issue in the data. However, it is very important the metada file in: http://pubs.usgs.gov/of/2000/of00-444/of00-444.met. There, you can observe the projection (EPSG: 4326) of the shapefiles (one is sf-qpys.shp; polygon type) and all classes (58) in, for example, PTYPE field. With this code in the field calculator of QGIS: CASE WHEN ...

0

I am not sure if GDAL is recognizing that the projection is just EPSG:3857 by the code but I suppose that the projection info it finds is correct. Make the same test with ogrinfo. If you can't get the same info with C# then there may be something wrong in the bindings or in your code. ogr2ogr -f "ESRI Shapefile" -s_srs epsg:4326 -t_srs epsg:3857 ...

1

A tool that can do this (among others) is the Sky-View Factor Based Visualization (http://iaps.zrc-sazu.si/en/svf#v). Calculate several parameters of a terrain. Is damn good.

0

This might be adaptable for your needs. If you don't mind calling the command line from python, you could do something like gdalwarp -cutline clip.shp -cl clip -crop_to_cutline input_raster output_raster_clipped.tif. -cwhere and -csql might be more appropriate gdalwarp options for selecting one of the four polygons for clipping.

0

If you're most interested in maintaining distances, you could use a customized azimuthal equidistant with the center/origin at the center of your area of interest. Distances from the center point only would be correct. Depending on the shape of your 100 (square?) mile area, you might be able to use another projection that maintains a different trait like ...

1

You can access raster statistics using the Python GDAL/OGR API. from osgeo import gdal # open raster and choose band to find min, max raster = r'C:\path\to\your\geotiff.tif' gtif = gdal.Open(raster) srcband = gtif.GetRasterBand(1) # Get raster statistics stats = srcband.GetStatistics(True, True) # Print the min, max, mean, stdev based on stats index ...

0

Use the option -eco from gdal_translate manual. I throw a non-blocking error. -epo: (Error when Partially Outside) (GDAL >= 1.10) If this option is set, -srcwin or -projwin values that falls partially outside the source raster extent will be considered as an error. The default behaviour starting with GDAL 1.10 is to accept such requests, when they were ...

1

Tom Hengl told me this: Set the 'check.module.exists = FALSE' and 'warn=FALSE' -> this usually does the trick (http://www.rdocumentation.org/packages/RSAGA/functions/rsaga.geoprocessor). And Alexander Brenning told me that: did you notice the warning message, Warning message: In rsaga.geoprocessor(lib, module, param = list(h = ""), env = env, : This ...

0

A straight 'clip' using gdalwarp should work (I know this is a hella-old question: 18 months IRL is like a geological epoch in internet years). I have a 70Gb aerial (ECW, 94000x81000 pixel at 10cm/px), and GDAL can arbitrarily clip it with a shapefile using gdalwarp -cutline [clipfile] -crop_to_cutline [infile] [outfile] at the Windows command-line. (I ...

0

The code number 102988 is not an EPSG one, but defined by ESRI. If you run gdalsrsinfo on the projection file, it reports: +proj=tmerc +lat_0=31 +lon_0=-111.9166666666667 +k=0.9999 +x_0=213360 +y_0=0 +ellps=GRS80 +units=m +no_defs You have to create a custom CRS with these parameters to work with the dataset. GDAL comes with a similar CRS named ...

1

gdal + convert based workflow There is a gdal + convert solution which gives good visual results. The trouble with this solution is that convert destroys geographic informations which you then have to restore. It increase the number of action to run. # Basic crop gdal_translate -projwin 67 35.92 99 5 ../data/noaa/ETOPO1_Ice_g_geotiff.tif crop_xl.tmp.tif # ...

0

The problem was the missing -inodata flag of my gdal_contour command

0

For my case (hillshade and my computer), I had to use --calc="(A/3+B/3+C/3)" to get a correct average results. (A+B+C)/3 fails because gdal_calc limit the equation to a [0-255] range. (A+B+C)/3 will first calculate A+B+C modulo 256, then divide this value (in range [0-255]) by 3, giving a low value and dark output. For more on gdal_calc operators, see ...

0

Gdal_calc's numpy seems to have more operators : + addition - subtraction / division * multiplication = equals to < less than > larger than ! not equal to ? if clause M maximum of two values m minimum of two values B bit level operator I haven't found clear and proper examples for how the exotic operators should be used. If you have ...

0

So I found a way around this issue, in case anyone else runs into the same thing. To get the colors interpreted properly, I did a gdal_translate -ot Byte on the files, and that allowed the colors to be interpreted properly. Apparently gdal2tiles interprets files with 3 byte type bands as rgb, which is what I wanted. However, when I did this, I still had ...

-1

Why use gdalwarp? Use for example the SAGA/Grid-Tools: resampling. This works fine.

0

This is 'fixed' in gdal-bin/python-gdal version 1.11.2. The behaviour in linux using this version is the same as using oSGeo4W 1.9.2. - i.e. the tiles use the projection origin as their x=0/y=0. Nothing I can see about it in the release notes, but clearly been resolved.

9

The linked source mention "change its fusion mode to < Multiply >", so the operation to do is not a simple average of input hillshades (for this, see also How to average gdal_hillshades?). It's something else. Yet, let's create the 3 different-sunlight-directions hillshades : gdaldem hillshade input.tif hillshades_A.tmp.tif -s 111120 -z 5 -az 315 -alt 60 ...

1

Line widths are determined at the rasterization step Other than lines in a vector image (e.g. SVG), lines in vector data do not have an inherent width. They are lines in a mathematical, not in a graphical sense. I assume that this is also the case for contours.shp, the output of the contour finding step with gdal_contour. Thus line width is determined by ...

2

The units of the extent will inherit from the units of the projection of the data, so to convert the extent to lat/long, you would need to reproject your data to a geographic projection (usually WGS1984) that uses degrees as units. Your data appears to have been projected to NAD27 / UTM zone 11N, which has units of meters. The extent refers to the x and y ...

0

I'm not sure, but this might be caused by the version conflict of the linked C runtime dlls between gdal111.dll and python bindings. Dependency Walker shows that gdal111.dll is linked to msvcr100.dll, but _gdal.pyd is linked to msvcr90.dll. Opening a ticket in OSGeo4W bug tracker is a good idea.

0

For part 1 of your question: The gdal_rasterize function is the one you want - you can specify the field to burn in using the -a option or the -3d option depending on how your file is structured. And, the -te, -ts and -tr options allow you to specify the grid extent and resolution (just pull these values directly from your original grid to keep ...

4

In addition to Micha's list, here is how you can nibble with GRASS 1) mask your image with r.mapcalc 2) with the resulting image, interpolate to the nearest neighbour using r.surf.nnbathy For combine, I would use r.cross but you can also do it using r.mapcalc with this algorithm For mosaic, I would use gdalbuildvrt: it is often not necessary to create a ...

0

Edit: Just read that this option was suggested in the comments already. Anyway, for completeness sake. Maybe someone can merge the answers? Of course it also possible to use python's subprocess, e.g. import subprocess def merge(first, second, out_file): """ This utility will automatically mosaic a set of images. All the images must be in the ...

3

The Clipper tool makes an uncompressed image by default. Read the GDAL manual of your format and add manually the compression options into the gdal_translate command that is shown in the lowest pane. For example for GeoTIFF read http://gdal.org/frmt_gtiff.html and use for example-co COMPRESS=DEFLATE -co PREDICTOR=2 which gives a well compressed, lossless ...

1

QGIS uses gdal_translate to clip the raster and the standard output is an uncompressed geo-tiff. Tiff file, however can be compressed using, commonly, one of a couple standard compression algorithms. The first is LZW and the second is JPEG. To set compression in QGIS's clipper module, click the yellow pencil to enable editting of the commandline at the ...

0

make sure that the gdalTools plugin is installed go to "Raster Menu -> Conversion -> Translate" you will see a tick box for "creation option", this will allow you to select a compression. This link shows a comparison the supported lossless compression algorithm, but the performance may depend on the image. If you want to do this at once in the clipper, ...

0

When specifying the profile with the -p flag the only option that creates the google viewer (googlemaps.html) is the mercator option. The image below illustrates the resulting files and folders after running gdal2tiles 3 times on a small test image (image_4326.tif) by specifing -p mercator, -p geodetic and -p raster options respectively. As in: python ...

0

i'm not sure what the default resolution is for gdal_translate if none is given, but you might try specifying some resolution based on the zoom level you desire per the docs - -tr xres yres : (GDAL >= 1.8.0) Set target resolution. The values must be expressed in georeferenced units. Both must be positive values

6

Here are some options Lookup: (not sure) Zonal stats: The GRASS module r.statistics Focal stats: GRASS r.neighbors Nibble: (don't know) Iterate through VAT: I think that the concept of a VAT is specific to Arc*, but r.describe might get close. Combine: Just use GRASS r.mapcalc Mosaic: GRASS - r.patch or gdal_merge

Top 50 recent answers are included