[GIS] Changing the origin of a raster

arcgis-desktopgdalogrraster

I have a raster file that is projected not detailed enough. Every pixel in the raster should be replaced, just a bit.
With ArcGIS I calculated the offset per pixel. I couldn't find a way to do this offsetting in ArcGIS, so I switched to python. I found out that I can get the current envelope with ogr with :

env = geom.GetEnvelope()
print "minX: %d, minY: %d, maxX: %d, maxY: %d" %(env[0],env[2],env[1],env[3])

And now I have to change these to the (already calculated) new origin.

Here is some sample code:

    ## From gdal info page     
wkt = "LINESTRING (1181866.263593049 615654.4222507705, 1205917.1207499576 623979.7189589312, 1227192.8790041457 643405.4112779726, 1224880.2965852122 665143.6860159477)"
geom = ogr.CreateGeometryFromWkt(wkt)
env = geom.GetEnvelope()

I have to say that I don't entirely understand the envelope function. Is this a function that returns the minX etc from the projection? Or does it just calculates this all from the geometry?

Does anybody now how to change this or knows another workaround?

Best Answer

If all you need to do is move the origin of your raster slightly, i.e shift the pixels, you can use the Shift tool in ArcGIS

Summary
Moves (slides) the raster to a new geographic location, based on x and y shift values. This tool is helpful if your raster dataset needs to be shifted to align with another data file.

Illustration

Related Solutions

[GIS] Extract Raster from Raster using Polygon shapefile in R

The extract function is behaving exactly as it should. You can force the crop function to use the extent of the polygon and then mask the object to return the exact raster representing the polygon area. If you continue to receive the error it means that your data, in fact, does not overlap.

Please keep in mind that R does not perform "on the fly" projection so, check your projections. You can check if your extents overlap using the "extent()" function.

Here is an example of cropping using the polygon extent then masking the resulting raster using the "rasterized" polygon.

# Add required packages
require(raster)
require(rgeos)
require(sp)

# Create some data using meuse 
data(meuse)
  coordinates(meuse) <- ~x+y
    proj4string(meuse) <- CRS("+init=epsg:28992")
data(meuse.grid)
  coordinates(meuse.grid) = ~x+y
    proj4string(meuse.grid) <- CRS("+init=epsg:28992")
      gridded(meuse.grid) = TRUE    
        r <- raster(meuse.grid) 
          r[] <- runif(ncell(r))

# Create a polygon
f <- gBuffer(meuse[10,], byid=FALSE, id=NULL, width=250, 
                         joinStyle="ROUND", quadsegs=10)   

# Plot full raster and polygon                       
plot(r)
  plot(f,add=T)

# Crop using extent, rasterize polygon and finally, create poly-raster
#          **** This is the code that you are after ****  
cr <- crop(r, extent(f), snap="out")                    
  fr <- rasterize(f, cr)   
    lr <- mask(x=cr, mask=fr)

# Plot results
plot(lr)
  plot(f,add=T)

[GIS] ny efficient way to create a raster with pixel value representing a unique id calculated based on pixel lat/lon

There are many ways to assign unique identifiers to raster cells. Some are listed below. Please note that although unique identifiers can be efficiently generated, any algorithm that requires unique identifiers for cells in large rasters (with many millions of more of cells) is itself going to be inefficient; in many cases it likely could be replaced by an algorithm not requiring every cell to have an identifier. Note, too, there is a natural limit to the size of such a grid, because even 32-bit grids can support at most 2^32-1 (about four billion) unique values. Methods to overcome that limit (without resorting to 64-bit grids) are given at the end.

Using a grid of column identifiers I (with values running from 0 up to one less than the number of columns, m) and a similar grid of row identifiers J (with values from 0 through n-1), compute
```
n * "I" + "J"
```
A convenient alternative is to round n up to the next power of ten equal to or exceeding n. The row and column coordinates can then be read directly off the point identifiers. For instance, with n = 12796 and m = 8092, use the formula 100000 * I + J. (Because the largest possible value of 809112795 will not overflow a signed 32-bit integer, this will work.) For instance, if a point has the identifier 49160008 it must have (row, column) coordinates (491, 60008) found by splitting the identifier into its last five digits and the remaining prefix thereof.

Column and row identifier grids can be computed (in one single calculation each) using the methods described at How do I calculate a weighted centroid with respect to a raster, e.g. population weighted centroid.
For smallish grids, simply use Combine("I", "J"). This operation will create internal unique pixel identifiers.
For very small grids (with fewer than 2^16 cells or so), generate a grid of uniformly distributed integers between 0 and the largest value possible (2^31-1 usually). Query the attribute table for counts larger than 1. If they exist, just generate a new random grid, repeating until all values are unique.
Don't even bother. If you ever need to identify a pixel, extract the values from the two grids I and J. Now there is no practical limit to the size of the grid--it need only have fewer than four billion rows and four billion columns.
The roles played by I and J can be replaced by grids of X and Y coordinates, respectively, but (a) the calculation in (1) is more delicate because it will be difficult to avoid potential collisions of IDs and (2) when the cellsize is very small (such as a few meters or less) single-precision floats usually won't distinguish all neighboring cells, so double precision will be necessary.
X and Y coordinate grids can themselves be replaced by other grids. Good ones are (signed) distances from appropriate curves: often two such distances suffice to uniquely identify every point close to the intersection of those curves. This provides a way to use non-Cartesian coordinate systems (such as polar or hyperbolic coordinates).

Best Answer

Related Solutions

[GIS] Extract Raster from Raster using Polygon shapefile in R

[GIS] ny efficient way to create a raster with pixel value representing a unique id calculated based on pixel lat/lon

Related Question