vector_to_raster

[jdries]

vector_to_raster

Context

Users load a vectorcube (e.g. from geojson) they want to convert it to raster, to be able to combine it at pixel level.
The vecturcube has a numerical property that needs to be burned into the pixel values.

So for instance, the population of a country could be used as a value for the pixels. When multiple attributes are available, this could result into a band dimension?

Summary

Creates a raster cube as output based on a vector cube. The values in the output raster cube are based on numeric properties in the input vector cube.

Description

Creates a raster cube as output based on a vector cube. The values in the output raster cube are based on numeric properties in the input vector cube.

Parameters

bands

Optional: yes

Description

Array of strings containing the vector band labels to convert to raster bands. If not provided, all bands are converted to raster bands.

Data Type

array

target_datacube

Optional: yes, default: null

Description

A data cube that describes the spatial target resolution and projection. If not specified, resolution needs to be provided.

Data Type

raster datacube

resolution

Optional: yes

Description

target resolution of the raster, if not specified, target_datacube needs to be set

Data Type

float

crs

Optional: yes

Description

target coordinate reference system of the raster, specified as epsg code. If not specified, the crs from target_datacube is used or the crs from the vector data cube.

Data Type

int or string?

Return Value

Description

A raster datacube

Data Type

rasterdatacube

Categories (optional)

• vector

[m-mohr]

We shouldn't do these "either or" parameters anymore, they lead to a weird interface in some languages. Instead, two processes are better (see resample_cube_spatial and resample_spatial). Maybe we finally need a create_spatial_cube or so? Then we don't need to define all the parameters over and over again. See also #381

Converting properties to bands is weird. This should probably not be bands, but a general list of labels for a dimension (type: other).

PRs are welcome.

[clausmichele]

I don't think that converting properties to bands is weird. Anyway, I agree that it would be good to have create_spatial_cube, where we could provide a target resolution and projection, this would allow to define this vector_to_raster_cube process just using the target_datacube parameter and not others.

[jdries]

Another solution which we use with raster cubes is:
vector_to_raster(...).resample_spatial(...)
and
vector_to_raster(...).resample_cube_spatial(...)

So the resolution info would be derived from subsequent processes, avoiding the need for two variants as well.
The solution with create_data_cube is also interesting.

@JeroenVerstraelen please try implementing something like:
vectorcube.vector_to_raster(create_data_cube().resample_spatial(crs='32631',resolution=10)))

[JeroenVerstraelen]

The vector_to_raster process has now been implemented in the VITO backend.

Parameters

Bands

Optional: yes, default: all bands

Description
Array of strings containing the vector band labels to convert to raster bands. If not provided, all bands are converted to raster bands.

Data Type
array

Target_datacube

Optional: no

Description
A reference data cube that describes the target's extent, spatial resolution, and projection.

Data Type
raster datacube

Return Value

Description
A raster datacube with the provided extent, spatial resolution, and projection. The output cube contains bands where each pixel inside the provided polygons has the value related to that polygon in the vector cube and all pixels outside have NoData values.

Data Type
rasterdatacube

Notes

• The target_datacube now also provides the extent of the output raster datacube. We found that this makes more sense than using the bounding box of the vector cube.
• The current implementation only supports an output raster datacube with one band (so the bands parameter is unused). This will change in the future.

[m-mohr]

A PR would be welcome.