I am using gdal_rasterize and ogr2ogr with a goal to get a partial raster of .gpkg file.
With first command I want to clip a smaller area of a large map.
ogr2ogr -spat xmin ymin xmax ymax out.gpkg in.gpkg
This results in a file that with command ogrinfo out.gpkg gives expected output by listing the layers numbers and names.
Then trying to rasterize this new file with:
gdal_rasterize out.gpkg -burn 255 -ot Byte -ts 250 250 -l anylayer out.tif
results in: ERROR 1: Cannot get layer extent when tried with any of the layers names given by ogrinfo
Using the same command on the original in.gpkg doesnt give errors and results in expected .tiff file raster.
ogr2ogr --version GDAL 2.4.2, released 2019/06/28
gdal_rasterize --version GDAL 2.4.2, released 2019/06/28
This process should at the end be implemented with the gdal C++ API.
Are the commands given some how invalid this way, how?
Should the whole process be done differently, how?
What does the ERROR 1: Cannot get layer extent mean?
Related
I use gdalwarp to get a planisphere with the EPSG 4326 projection (equidistant cylindrical projection). Before with GDAL 2 I had no problem to use gdalwarp with this command :
gdalwarp -te lonMin latMin lonMax latMax -t_srs EPSG:4326 sphere.tiff planisphere.tiff
Example
gdalwarp -te -100 -10 -60 10 -t_srs EPSG:4326 sphere.tiff planisphere.tiff
But now with GDAL 3.0.4 it returns an error like if I made a mistake in coordinates.
Creating output file that is 0P x 0L. ERROR 1: Attempt to create 0x0 dataset is illegal,sizes must be larger than zero.
Do we need to install something else now? (maybe because now GDAL seems to use PROJ6).
If someone have the solution or an idea, I will be glad to hear it. Thanks !
Alright gdalwarp works well, this problem is due to gdal_translate.
Since GDAL 3, if you extract an image from netCDF file, it doesn't georeference automatically your tiff image. This is why gdalwarp wouldn't work because it was impossible to crop my image.
So if you have a non-georeferenced image, you have to georeference your image with gdal_translate.
I am trying to merge a number of geotiffs into one large geotiff with overviews, however the final merged geotiff shows a number of horizontal artifacts around the edges of the original merged geotiffs (see here for an example).
I create the merged file using the following code:
'''Produce Combined VRT'''
string ='gdalbuildvrt -srcnodata "0 0 0 0" -hidenodata -r bilinear %s -overwrite %s' %(tmp_vrt, GDal_merge_string)
os.system(string)
'''Convert VRT to Geotiff'''
string ='gdal_translate -b 1 -b 2 -b 3 -mask 4 --config GDAL_TIFF_INTERNAL_MASK YES -of GTiff %s %s' %(tmp_vrt,tmp_fname)
os.system(string)
I have a hunch that this might have to do with using gdal_translate on a vrt, as the erorrs occur on the edges of the original geotiffs, and in this case it might be related or similar to the issue found in this post.
This code is using VRTs to combine the geotiffs for speed purposes, but perhaps it might be better to just merge these with gdalwarp?
Edit: I have reduced the number of flags and left out the overviews in the code above, as suggested in the comment below by Benjamin. The error seems to be produced in the code above. I think the issue may lie in the masking process. I guess at some point in the process of stacking the bands, the inputs are distorted. Is it generally inadvisable to gdal_translate VRTs?
I have labelled .wav files to train a Convolutional Neural Network. These are for Bengali phones, for which no standard Dataset is available. I want to input these .wav files to Tensorflow for training my CNN model. I want to create Grayscale Spectrograms from these .wav files, which will be input for my model. I need help in how to do so. If there is more than one alternative, what are their strength and weakness?
Also, they are of variable time lengths, like some are 70ms, some are 160ms. Is there a way to divide them in 20ms segments?
I have done something similar in my research. I used the Linux utility SOX to do the audio wave file manipulation and creating spectrograms.
On the audio file length, you can use the "trim" option within SOX to split the file into 20ms segments. Something along the lines of the following:
sox myaudio.wav trim 0 0.02 : newfile : restart
Using the "spectrogram" option of SOX, you can then create the spectrogram.
sox myaudio.wav -n spectrogram -m -x 256 -y 256 -o myspectrogram.png
The command will create a monochrome spectrogram of size 256x256 and store it in the file "myspectrogram.png".
In my research, I did not split the file into smaller chunks. I found that using the whole wave file of the word was sufficient to get good recognition. But, it depends on what your long term goal is.
You can also look at the ffmpeg ops in TensorFlow for loading audio files, though we don't yet have a built-in spectrogram:
https://github.com/tensorflow/tensorflow/tree/master/tensorflow/contrib/ffmpeg
I'm using gdal to create different kinds of layers, such as color reliefs and hillshades, and Mapnik to combine them into a single image to use as texture for the 3D dem model obtained from a single .hgt file.
Premising that I'm new to gdal, I'm facing some problem with the hillshade layer.By using the gdal command:gdal_translate N44E007.hgt N44E007.tif
I get the N44E007.tif file, which in IrfanView looks like this
With the following gdal command:gdaldem hillshade -of PNG .\tif\N44E007.tif .\hillshade_png\N44E007_hillshade.png
The N44E007_hillshade.png file I get is the following
How can I prevent gdal from creating these artifacts in the hillshade .png?
I'm using Windows 7 and cmd.
Update 1
This is the image I get by replacing gdal_translate N44E007.hgt N44E007.tif with gdalwarp -t_srs EPSG:32632 -r bilinear N44E006.hgt N44E006.tif
The problem is that the reprojected image is slightly rotated and stretched. How can I get a squared and straight image to use as texture for a 3d plane?
The reason for the artefacts in the first attempt is because the raster horizontal distance units are in degrees, and the vertical are in meters. You can use a scale option to normalise horizontal and vertical distance units, e.g. try:
gdaldem hillshade -s 111120 -compute_edges -of PNG N44E007.hgt N44E007_hs.png
The second attempt (Update 1) reprojects to WGS84 UTM zone 32, which is a transverse Mercator projection centred on a meridian at 9°E, which is close to the SRTM raster, which is centred on 7.5°E. Since the two meridians are not the same, it is expected the raster to be rotated. And it is stretched since the true distance of degrees are not equal in N-S and E-W directions, except at the equator.
I try to import a raster file into my postgres database following this tutorial [http://www.postgis.org/documentation/manual-svn/using_raster.xml.html][1]
Environment: windows7, Postgres 8.4, postgis 2.0.
My command line are:
cd C:\Program Files (x86)\PostgreSQL\8.4\bin
raster2pgsql -s 4236 -I -G -M kiwi.jpg -F -t 100x100 public.gis > out.sql
psql -U postgres -d mydb2 -f out.sql
The picture named "kiwi" was in the "C:\Program Files (x86)\PostgreSQL\8.4\bin" folder.
The out.sql can be generated successfully. But after input "psql -U postgres -d mydb2 -f out.sql" , there is an error.
psql:out.sql:98: ERROR: syntax error at or near"Available"
LINE 1: Available GDAL raster formats:
Thank you!
This is the contents of the query:(I'm very new about postgis, so I can't figure out what's wrong here. Because I just follow the tutorial, it should work )
Available GDAL raster formats:
Virtual Raster
GeoTIFF
National Imagery Transmission Format
Raster Product Format TOC format
ECRG TOC format
Erdas Imagine Images (.img)
CEOS SAR Image
CEOS Image
JAXA PALSAR Product Reader (Level 1.1/1.5)
Ground-based SAR Applications Testbed File Format (.gff)
ELAS
Arc/Info Binary Grid
Arc/Info ASCII Grid
GRASS ASCII Grid
SDTS Raster
DTED Elevation Raster
Portable Network Graphics
JPEG JFIF
In Memory Raster
Japanese DEM (.mem)
Graphics Interchange Format (.gif)
Graphics Interchange Format (.gif)
Envisat Image Format
Maptech BSB Nautical Charts
X11 PixMap Format
MS Windows Device Independent Bitmap
SPOT DIMAP
AirSAR Polarimetric Image
RadarSat 2 XML Product
PCIDSK Database File
PCRaster Raster File
ILWIS Raster Map
SGI Image File Format 1.0
SRTMHGT File Format
Leveller heightfield
Terragen heightfield
USGS Astrogeology ISIS cube (Version 3)
USGS Astrogeology ISIS cube (Version 2)
NASA Planetary Data System
EarthWatch .TIL
ERMapper .ers Labelled
NOAA Polar Orbiter Level 1b Data Set
FIT Image
GRIdded Binary (.grb)
Raster Matrix Format
EUMETSAT Archive native (.nat)
Idrisi Raster A.1
Intergraph Raster
Golden Software ASCII Grid (.grd)
Golden Software Binary Grid (.grd)
Golden Software 7 Binary Grid (.grd)
COSAR Annotated Binary Matrix (TerraSAR-X)
TerraSAR-X Product
DRDC COASP SAR Processor Raster
R Object Data Store
Portable Pixmap Format (netpbm)
USGS DOQ (Old Style)
USGS DOQ (New Style)
ENVI .hdr Labelled
ESRI .hdr Labelled
Generic Binary (.hdr Labelled)
PCI .aux Labelled
Vexcel MFF Raster
Vexcel MFF2 (HKV) Raster
Fuji BAS Scanner Image
GSC Geogrid
EOSAT FAST Format
VTP .bt (Binary Terrain) 1.3 Format
Erdas .LAN/.GIS
Convair PolGASP
Image Data and Analysis
NLAPS Data Format
Erdas Imagine Raw
DIPEx
FARSITE v.4 Landscape File (.lcp)
NOAA Vertical Datum .GTX
NADCON .los/.las Datum Grid Shift
NTv2 Datum Grid Shift
ACE2
Snow Data Assimilation System
Swedish Grid RIK (.rik)
USGS Optional ASCII DEM (and CDED)
GeoSoft Grid Exchange Format
Northwood Numeric Grid Format .grd/.tab
Northwood Classified Grid Format .grc/.tab
ARC Digitized Raster Graphics
Standard Raster Product (ASRP/USRP)
Magellan topo (.blx)
SAGA GIS Binary Grid (.sdat)
Kml Super Overlay
ASCII Gridded XYZ
HF2/HFZ heightfield raster
OziExplorer Image File
USGS LULC Composite Theme Grid
Arc/Info Export E00 GRID
ZMap Plus Grid
NOAA NGS Geoid Height Grids
I have no idea about this error after searching a lot. I really appreciate that if you can give me some suggestions.
[1]: http://www.postgis.org/documentation/manual-svn/using_raster.xml.html
[2]: http://i.stack.imgur.com/YxjNJ.png
The psql utility in PostgreSQL is for processing SQL commands. The file you show doesn't contain SQL commands, it appears to contain information to help someone choose an option for the raster2pgsql program. A quick web search turned up documentation here:
http://www.postgis.org/documentation/manual-svn/using_raster.xml.html
Notice that the -G option is used to "Print the supported raster formats." The command line you used to run the program included that switch. If your goal is to produce SQL statements, that's not an option you should include. I don't know whether any other adjustments need to be made to your command, but you could start by dropping that and see what you get.