You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Pygeoprocessing functions that take in a SRS parameter require it to be in WKT format. GDAL/OGR utilities also accept EPSG and ESRI codes, PROJ strings, and more. We usually define projections in terms of EPSG codes anyway, so it would be convenient to pass those directly to pygeoprocessing. It's also nice to be consistent with GDAL when possible.
anything supported by the OGRSpatialReference.SetFromUserInput() call, which includes EPSG Projected, Geographic or Compound CRS (i.e. EPSG:4296), a well known text (WKT) CRS definition, PROJ.4 declarations, or the name of a .prj file containing a WKT CRS definition.
From a quick search, functions that take WKT parameters are
align_and_resize_raster_stack
create_raster_from_bounding_box
reproject_vector
warp_raster
transform_bounding_box
shapely_geometry_to_vector
numpy_array_to_raster
The text was updated successfully, but these errors were encountered:
Pygeoprocessing functions that take in a SRS parameter require it to be in WKT format. GDAL/OGR utilities also accept EPSG and ESRI codes, PROJ strings, and more. We usually define projections in terms of EPSG codes anyway, so it would be convenient to pass those directly to pygeoprocessing. It's also nice to be consistent with GDAL when possible.
From the
ogr2ogr
docs,srs
parameters may beFrom a quick search, functions that take WKT parameters are
align_and_resize_raster_stack
create_raster_from_bounding_box
reproject_vector
warp_raster
transform_bounding_box
shapely_geometry_to_vector
numpy_array_to_raster
The text was updated successfully, but these errors were encountered: