I have a geotiff raster image that has a coordinate system with longtitudes from 0 to 360.
The horizontal center of the image is 180 longtitude. See image below:

I want to transform it to EPSG:4326 SRS with -180 180 longtitude range.
And I want the center of the image to be at Greenwich meridian (0). I guess this srs is very widely used. I expect the result look like this:

So I use a gdalwarp command to reproject:

gdalwarp -s_srs '+proj=latlong +datum=WGS84 +pm=180dW' -t_srs EPSG:4326 test_col.tif test_4326.tif

But I only get a tiff with bigger dimensions (more pixels) and EPSG:4326 metadata. The image itself looks the same, as the initial one. But I expect it to swap the hemispheres.

The question is – how do I gdalwarp an image to be strictly -180 180 EPSG:4326 with the center in 0 longtitude?

This is gdalinfo of my initial file:

Origin = (-0.102272598067084,89.946211604095552)
Pixel Size = (0.204545196134167,-0.204423208191126)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  -0.1022726,  89.9462116) (  0d 6' 8.18"W, 89d56'46.36"N)
Lower Left  (  -0.1022726, -89.9462116) (  0d 6' 8.18"W, 89d56'46.36"S)
Upper Right (     359.897,      89.946) (359d53'50.18"E, 89d56'46.36"N)
Lower Right (     359.897,     -89.946) (359d53'50.18"E, 89d56'46.36"S)
Center      ( 179.8975000,  -0.0000000) (179d53'51.00"E,  0d 0' 0.00"S)

This is gdalinfo after gdalwarp

Origin = (-180.102727401932952,89.946211604095552)
Pixel Size = (0.091397622896436,-0.091420837939082)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=PIXEL
Corner Coordinates:
Upper Left  (-180.1027274,  89.9462116) (180d 6' 9.82"W, 89d56'46.36"N)
Lower Left  (-180.1027274, -89.9699975) (180d 6' 9.82"W, 89d58'11.99"S)
Upper Right ( 179.8211116,  89.9462116) (179d49'16.00"E, 89d56'46.36"N)
Lower Right ( 179.8211116, -89.9699975) (179d49'16.00"E, 89d58'11.99"S)
Center      (  -0.1408079,  -0.0118929) (  0d 8'26.91"W,  0d 0'42.81"S)

This is an additional exploration of the problem described at Reprojecting MODIS Ice Sea Temperature products with gdalwarp which was never answered in a satisfying way (I apologise for the length of the post).

I want to reproject Antarctic MODIS Sea Ice Extent and IST Daily L3 Global 4km EASE-Grid Day data to Antarctic Polar Stereographic using GDAL. I am interested in both AQUA (product MYD29E1D) and TERRA (product MOD29E1D) and I am interested in the full time series available.

Processing of version 6 is currently ongoing and should be completed by the end of 2015 according to https://nsidc.org/data/MYD29E1D and http://nsidc.org/data/MOD29E1D. Therefore I try to use version 5 that is made available via FTP from ftp://n5eil01u.ecs.nsidc.org/SAN/MOSA/MYD29E1D.005/ and ftp://n5eil01u.ecs.nsidc.org/SAN/MOST/MOD29E1D.005/.

These MODIS products use the rather esoteric EASE-Grid projection which exists in several versions described here: http://nsidc.org/data/ease/versions.html. Apparently there is an orignal version of EASE-Grid that was released in 1992 and a version 2.0 released in 2011. The website sited above states that six EPSG codes are available to handle EASE-Grid. For each of the two version there exist three EPSG codes relating to “North”, “South” and “Global”.

Original
North: 3408, South: 3409, Global 3410

V2.0 North: 6931, South: 6932, Global: 6933

Which adds to the complexity is that there are two deprecated EASE-GRID EPSG codes

Deprecated North: 3973, South: 3974, Global: 3975

The question that I had now were:

1. Which EPSG-code should I use in the first place?
2. If there are two versions of EASE-GRID, does that mean I have to use a different EPSG-code/CRS for data created pre-2011?

GDALSRSINFO applied to the fourth band (south pole IST) results in the following definition, regardless if it is applied to a 2009 or 2014 dataset (2009 and 2014 being chosen because these data are well before and after the transition to EASE-Grid 2.0):

gdalsrsinfo 'HDF4_EOS:EOS_GRID:"MOD29E1D.A2009345.005.2009346083234.hdf":MOD_Grid_Seaice_4km_South:Ice_Surface_Temperature_SP'

PROJ.4 : '+proj=laea +lat_0=-5156620156.177409 +lon_0=0 +x_0=0 +y_0=0 +ellps=clrk66 +units=m +no_defs '

OGC WKT :
PROJCS["unnamed",
    GEOGCS["Unknown datum based upon the Clarke 1866 ellipsoid",
        DATUM["Not specified (based on Clarke 1866 spheroid)",
            SPHEROID["Clarke 1866",6378206.4,294.9786982139006,
                AUTHORITY["EPSG","7008"]]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Azimuthal_Equal_Area"],
    PARAMETER["latitude_of_center",-5156620156.177409],
    PARAMETER["longitude_of_center",0],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["Meter",1]]

As I could not find any conclusive documentation, I tried to convert a dataset from 2009 and a dataset from 2014 using all available “Global” and “South” codes (3409, 3410, 6932, 6933, 3974, 3975). The two datasets I used are ftp://n5eil01u.ecs.nsidc.org/SAN/MOST/MOD29E1D.005/2009.12.11/ and ftp://n5eil01u.ecs.nsidc.org/SAN/MOST/MOD29E1D.005/2014.12.11/.

Regarding the software versions I use:

gdalinfo --version
GDAL 1.11.2, released 2015/02/10

proj
Rel. 4.9.0, 27 October 2013

I first extract the relevant band (MODIS product) and then convert it to Antarctic Polar Stereographic e.g.

gdal_translate -unscale -srcwin 500 500 3500 3500 -a_srs epsg:3409 HDF4_EOS:EOS_GRID:"MOD29E1D.A2009345.005.2009346083234.hdf":MOD_Grid_Seaice_4km_South:Ice_Surface_Temperature_SP MOD29E1D.A2009345.005.2009346083234_tmp.tif

(The -srcwin is necessary to get rid of reprojection errors resulting from values outside the projection area)

followed by e.g.

gdalwarp -overwrite -s_srs EPSG:3409 -t_srs EPSG:3031 MOD29E1D.A2009345.005.2009346083234_tmp.tif MOD29E1D.A2009345.005.2009346083234_3409.tif

(Side remark: if I use the two commands without specifying the source CRS, the results are unusable)

The first problem that I encountered is that 6932 and 6933 are not EPSG-codes supported by the GDAL/PROJ version that I use. The errors that I get are:

ERROR 6: EPSG PCS/GCS code 6932 not found in EPSG support files.  Is this a valid EPSG coordinate system?
ERROR 6: EPSG PCS/GCS code 6933 not found in EPSG support files.  Is this a valid EPSG coordinate system?

I then checked if the proj I use knows about EPSG:6932/6933 by using (here using the newest stable version of proj – just to make sure).

cs2cs -v +init=epsg:6932
Using from definition: init=epsg:6932 
Rel. 4.9.1, 04 March 2015
<cs2cs>: 
projection initialization failure
cause: no options found in 'init' file
program abnormally terminated

cs2cs -v +init=epsg:6933
Using from definition: init=epsg:6933 
Rel. 4.9.1, 04 March 2015
<cs2cs>: 
projection initialization failure
cause: no options found in 'init' file
program abnormally terminated

Proj4 apparently does not know about these two EPSG codes. I hoped for a proj or WKT definition that I could use, but http://epsg.io/6932 does not give either of those. The coordinate reference systems 6932 and 6933 are therefore not usable.

I therefore applied transformations to the four remaining coordinate reference systems (3409, 3410, 3974, 3975) to the two example files. Of he eight resulting files, only one created an output with a reasonable fit: the “old” EPSG:3409 or the deprecated EPSG:3974 when applied to the 2014 dataset.

So to summarise:

1. I could not find any way to reproject pre-2011 MODIS IST data
2. I was not able to use the recommended CRS EPSG:6932/EPSG:6933 for post-2011 MODIS IST data

I’ve encountered issues with projections in .geojson files created by rgdal, but I never thought it would destroy my data, until I tried this (reproducible example):

downloader::download("http://census.edina.ac.uk/ukborders/easy_download/prebuilt/shape/England_lad_2011_gen_clipped.tar.gz", destfile = "cuas.zip")
untar("cuas.zip")
cuas_shp <- raster::shapefile("England_lad_2011_gen_clipped.shp")
tmap::qtm(cuas_shp)
rgdal::writeOGR(cuas_shp, "cuas-ogr", "OGRGeoJSON", "GeoJSON")
cuas_ogr <- rgdal::readOGR("cuas-ogr", "OGRGeoJSON")
tmap::qtm(cuas_ogr ) # fails - something wrong with the data
library(sp) # plot using normal methods
plot(cuas_shp)
plot(cuas_ogr)

There are more examples I can show. It seems the geojsonio package does not solve these issues either. Ask if you’d like more reproducible examples – want to check I’m not missing anything obvious first though.

(Also not the projection seems to be missing in the geojson example.)

Im a geomatics student;

Currently, I try to geo-referencing a tif image with the QGIS GUI, and then I load and save the Gdal script. With the QGIS GUI, I managed to get a decent picture, then I exports it in Geotif.

I would like to use the gdal executable store in the qgis file (bin file) for the same operation.
So, I try to do the same operation with a DOS command with gdal_translate and gdalwarp. But it doesn’t work. The operation with the DOS command gives me a black image. With the same gdal script, under QGIS, the image is correct. I only make a copy paste under the DOS command. The first part, the gdal_translate seems to work, and I think it is the gdalwarp the problem.

These are my command lines :

gdal_translate -of GTiff -gcp 18.4111 34.3009 *(... a lot of GCP ...)* "S:/image/geotiff/TrueMarble.tif" "C:/Users/userme/AppData/Local/Temp/TrueMarble.tif"
gdalwarp -r cubicspline -order 3 -co COMPRESS=NONE -dstalpha "C:/Users/userme/AppData/Local/Temp/TrueMarble.tif"
 "S:/image/geotiff/Poly3"

Any help would be greatly appreciated

I am trying to downsample a 1 square km raster dataset to a much larger (.5 degree x .66 degree) dataset by summing all of the pixel values within this large grid cell.

gdal_warp does not contain a summation resampling method so I’m wondering if anyone has figured this out before.

Thank you!

My Objective: I would like to use GDAL to convert a GeoPDF. I want the vector layers as shp files and the raster layers as tif files. I want to do this in a programmatic way.

Edit: In reality, I want to do this with many geospatial PDFs. I’m prototyping the workflow using Python, but it will probably end up being C++. (End Edit)

The Problem: Naturally, the command to convert a vector layer differs from a raster layer. And I don’t know (again in a programmatic way) which layers are vector and which are raster.

What I’ve Tried: First, here is my sample data https://www.terragotech.com/images/pdf/webmap_urbansample.pdf.

gdalinfo webmap_urbansample.pdf -mdd LAYERS

gives the layer names:

...
Metadata (LAYERS):                           
  LAYER_00_NAME=Layers                       
  LAYER_01_NAME=Layers.BPS_-_Water_Sources   
  LAYER_02_NAME=Layers.BPS_-_Facilities      
  LAYER_03_NAME=Layers.BPS_-_Buildings       
  LAYER_04_NAME=Layers.Sewerage_Man_Holes    
  LAYER_05_NAME=Layers.Sewerage_Pump_Stations
  LAYER_06_NAME=Layers.Water_Points          
  LAYER_07_NAME=Layers.Roads                 
  LAYER_08_NAME=Layers.Sewerage_Jump-Ups     
  LAYER_09_NAME=Layers.Sewerage_Lines        
  LAYER_10_NAME=Layers.Water_Lines           
  LAYER_11_NAME=Layers.Cadastral_Boundaries  
  LAYER_12_NAME=Layers.Raster_Images         
...

I know to look at the data which are vector and which are raster, but I don’t know how to parse this information to know whether to use ogr2ogr or gdal_translate to do the conversion.

Then I thought I could use ogrinfo and just diff all the layers to deduce which ones are raster, but ogrinfo gives me:

...
1: Cadastral Boundaries (Polygon)
2: Water Lines (Line String)
3: Sewerage Lines (Line String)
4: Sewerage Jump-Ups (Line String)
5: Roads
6: Water Points (Point)
7: Sewerage Pump Stations (Point)
8: Sewerage Man Holes (Point)
9: BPS - Buildings (Polygon)
10: BPS - Facilities (Polygon)
11: BPS - Water Sources (Point)

So there’s not a one-to-one correspondence with the way these are output.

So my question is: Does anyone know how to have gdal print the GeoPDF layers and indicate which are raster vs. vector? Or is there another way to infer this?

Thanks!

I’ve been reading several posts to do so and one option would be to use gdalwarp -cutline, but I would need to keep what it is NOT inside the polygon area. GDAL or any command-line tool does that?

Thanks for any pointers,

I have experienced that gdal shifts rasters. The outputs of gdal_warp are often skewed, have different pixel sizes and so forth. A known error which has also been discussed here.

But now, I had to realize, that gdal_merge also shifts rasters! Well it is only some mm of whole MODIS tiles (pixel size 250m), but I can’t imagine what is the reason for it, all layers have the same extent, the same coordinate system and so forth. Why should gdal_merge shift inputlayers and not simply merge or stack them?

Thanks for any insights, ideas and enlightments on this issue.

[code example:

gdal_merge -separate -of GTiff -o D:/MODIS_TIF_NDVI_RECTCLIP_YEARLY_STACK/2005_PARAMETERS_NDVI_STACK.tif D:/MODIS_TIF_NDVI_RECTCLIP_SEASONAL_PARAMETERS/2005_SOS_s1 .....]

A while back I went through the installation process for GDAL by installing the core components and then the Python/GDAL bindings. Everything was fine when I would type in from osgeo import gdal. However, I had to uninstall and reinstall everything due to a problem I was having. Now when I type in from osgeo import gdal, Python crashes and I get the message that it has stopped working. When I click on “Close the Program” Python restarts.

I’ve looked to see if there was anything left over from the previous install, but couldn’t find anything.

Any ideas on something I could try?

Im a geomatics student.

For the treatment I would like to make, I use the gdal executable in QGIS file, with a DOS command.

I have a csv file like this (test.csv) :

  X       Y
-5.48   42.81
-4.78   42.52
-5.06   42.02

This coordinates are GCP. I would like to convert my csv file in a VRT. On the internet, I found example like :

<OGRVRTDataSource>
    <OGRVRTLayer name="test">
        <SrcDataSource>test.csv</SrcDataSource>
        <GeometryType>wkbPolygon</GeometryType>
        <LayerSRS>WGS84</LayerSRS>
        <Field name="id" src="id" />
        <GeometryField encoding="WKT" field="geo" />
    </OGRVRTLayer>
</OGRVRTDataSource>

Simply, I don’t know where to put this line. Should I put them in a DOS command in my QGIS file ?

Any help would be greatly appreciated

I need dtm format that store only heights and scaling and left up position for saving storage

I glad to know if any stadard save heights that way

I’ve got some elevation data represented in ascii gridded xyz-files which I want to convert to a conventional raster format. What’s a bit special is that the elevation values have sub-meter accuracy, as they have one decimal (for example: ’101.7′)

As a rule I prefer to use open source software and stick to conventional, open, widely supported formats.

So the first thing I tried was to convert the data using gdal to geotiff, but specifying the data-type as Float32/64 distorted the elevation values somewhat. When I check the pixel-value in qgis it reports it as 101.70001220703125.

The command I use to convert an ascii file into raster is:

gdal_translate -ot Float32 -a_srs "EPSG:32633" -co "TILED=YES" -co "COMPRESS=LZW" -co "PREDICTOR=2"  -co "ZLEVEL=9" file.txt file.tif

Questions:
What would be suitable raster formats for sub-meter elevation data?
Is there any other software I should consider using instead of gdal?
Is this distortion of decimal precision perhaps inherently unavoidable? (Some doubts have been raised in the comments below though).

Edit:
Some more information about the original text format:
I cannot disseminate this data and provide a real example, but the original format is rather trivial. The text files contain UTM coordinates for a specific zone, 33N for example. The spacing between the points are regular, with a spacing of 5 meters between them. Just as an example two adjacent XYZ values would be:
680000 5420000 101.7
680005 5420000 101.3

Actually, it should be possible to use just the above two lines and invoke gdal_translate as described above, it should be sufficient to discern how gdal handles the numerical precision.

I’m trying to convert official boundaries of administrative regions of Poland from official governmental site (codgik.gov.pl). I want to use those data because they are official ones, and set contains additional levels of borders of that I cannot find in other data sets (such as Natural Earth).

I use approach similar to How to create a GeoJSON that works with D3?.
However when I’m trying to use conversion ogr2ogr and plot the results using d3.js I fail. Data seems to be incorrectly translated giving essentially gibberish.

The same approach worked just fine w Natural Earth shapefiles.

By playing around with SVG (deleting paths) I can see that path overlaps and hugely and result in just black square.

Java GeoTools [quickstart tutorial] shows this shapefile without any problem, so I’m guessing mine conversions are off.

Shapefile set is available here (5.5MB)

JavaScript code:

d3.json("wojeowdztwa.json", function(error, map) {
  if (error) return console.error(error);

var projection = d3.geo.mercator()
//    .center([171677, 133223])
//    .scale(69)
    .translate([width / 2, height / 2]);

  var path = d3.geo.path()
    .projection(projection);

svg.append("g").attr("id", "polska")
    .selectAll("path")
      .data(map.features)
      .enter()
        .append("path")
        .attr("id", function(d) { return d.id; })
          .attr("d", path)
          .attr("class", "wojewodztwo");

Content of .PRJ file:

PROJCS["ETRS89 / Poland CS92", 
  GEOGCS["ETRS89", 
    DATUM["European Terrestrial Reference System 1989", 
      SPHEROID["GRS 1980", 6378137.0, 298.257222101], 
      TOWGS84[0,0,0]
    ], 
    PRIMEM["Greenwich", 0.0], 
    UNIT["Decimal Degree", 0.017453292519943295]
  ], 
  PROJECTION["Transverse_Mercator"], 
  PARAMETER["latitude_of_origin", 0.0], 
  PARAMETER["central_meridian", 18.999999999999982], 
  PARAMETER["scale_factor", 0.9993], 
  PARAMETER["false_easting", 500000.0], 
  PARAMETER["false_northing", -5300000.0], 
  UNIT["Meter", 1.0], 
  AUTHORITY["EPSG", 2180]
]

I’m very new to this whole cartography stuff. So I would be very happy to get some advice.

Thanks very much!

I need to get hieght by lat long position using gdal utilities

I am trying to use GDAL 1.10 with a vector virtual source which is nothing more than the example union of two shapefile layers. from the commandline, ogrinfo works fine on the source. But the C# binding version of ogrinfo cannot open either shapefile.

Is this a known issue?

Ive been looking for a solution to my problem for some time now.
I’m using gdal2tiles-leaflet to create tiles for my Leaflet application.
The images i use are GeoTiff’s with the embedded projection WGS84, they are in flight photos taken by a drone.

So I tried gdal2tiles-leaflet. I successfully created a map where i can navigate the image. It works great. But the image is not working properly when i use it as a overlay layer on a normal map, with other base layers. Such as open street map.
The image is then super large, so i have to zoom out really much. And the image covers almost the whole earth. So it’s basically not georeferenced. In the way i’d like it to be.

Here’s some of the commands that i’ve been using:

gdal2tiles-multiprocess.py -l -p raster -z 0-9 test.tif tiles
gdal2tiles-multiprocess.py -l -p raster -z 0-7 -s src.prj -w all test.tif tiles
gdal2tiles-multiprocess.py -l -p raster -z 0-7 -s src.prj -t "+proj=longlat +ellps=WGS84" -w all test.tif tiles
gdal2tiles-multiprocess.py -l -p geodetic -z 14-15 test.vrt

I’ve tried different zoom levels, raster, geodetic and so on. But I cant seem to get the result im looking for.

I know that MapTiler has the functionality to get this to work, i’ve tried it on a smaller image. But the application does not really fit in to my workflow on the server everything is hosted on.
So I would like to be able to use gdal2tiles-leaflet.

I pretty certain im just missing some small thing, so please, can someone help me out?

Thanks!

I’m trying to use GDAL polygonize to run a batch convert but I cannot for the life of my figure out a way to get it to read a text file as input that contains all of the commands. Do any of you know the correct command to run this conversion in one step so I don’t have to do it many times over?

Here’s an example of a single line of my input txt file:

gdal_polygonize X:Source-ImagerySatelliteWaterMaskCollection_52000ALLMOD44W_Water_2000_ML1920.tifMOD44W_Water_2000_ML1920.tif -f "ESRI Shapefile" X:Source-ImagerySatelliteWaterMaskCollection_52000ALLMOD44W_Water_2000_ML1920.tifMOD44W_Water_2000_ML1920.shp 

The txt file contains 176 lines to convert.

Thanks in advance!
-Matt

I have been using gdal wms layers to view various basemaps in QGIS. I am using this technique rather than open layers because this I can reproject gdal WMS layers as needed.

When I get close to the max zoom on my google layer my images become discolored (sometimes all in blues, other times yellows). I have checked my layer settings to ensure that my color band settings are correct.

I only have this problem when using a google maps layer, I have not seen any problems with other gdal wms layers.

I have checked for this problem in both the 32bit and 64 bit versions of qgis on multiple windows 7 computers. I only observed this problem on the 32 bit version.

Also is there any way to make qgis log my tile requests?

The layer xml is below.

      <GDAL_WMS>
  <Service name="TMS">

    <ServerUrl>http://mt.google.com/vt/lyrs=y&amp;x=${x}&amp;y=${y}&amp;z=${z}</ServerUrl>
  </Service>
  <DataWindow>
      <UpperLeftX>-20037508.34</UpperLeftX>
    <UpperLeftY>20037508.34</UpperLeftY>
    <LowerRightX>20037508.34</LowerRightX>
    <LowerRightY>-20037508.34</LowerRightY>
    <TileLevel>19</TileLevel>
    <TileCountX>1</TileCountX>
    <TileCountY>1</TileCountY>
    <YOrigin>top</YOrigin>
  </DataWindow>
  <Projection>EPSG:3857</Projection>
  <BlockSizeX>256</BlockSizeX>
  <BlockSizeY>256</BlockSizeY>
  <BandsCount>3</BandsCount>
 <Cache> 

<Depth>2</Depth>    
<Extension>.jpg</Extension>
</Cache>
</GDAL_WMS>

When I use:

gdal_rasterize -b 1 -b 2 -b 3 -burn 255 -burn 255 -burn 255 polygon.shp tiff.tiff

I get a new tiff with a white hole in it with the shape of the polygon shp. However, when I use the reverse process:

gdal_rasterize -i -b 1 -b 2 -b 3 -burn 255 -burn 255 -burn 255 polygon.shp tiff.tiff

I get a blank tiff. I expect the old tiff shaped by the polygon (ie. raster values inside the polygon), instead.

Any ideas why this happens? is it possible to clip a raster with a shapefile in this way?

How can Planet Labs’ mosaic Tile Map Service (TMS) be used with GDAL like in the Open Layers example? The API requires authentication and other specific settings.