With #263 and #264, geoflow will allow to get various geoflow_data objects associated to a geoflow_entity. The use of #263 will even allow to mix different geoflow_data spatial representation types (vector, grid). This is the main driver of doing #264, but this also requires to define strategies for entity enrichment:
for srid: a unique srid should be used among data associated. In case of there is a mix of SRIDs in geoflow_data features/coverages, this will necessarily be ignored with a warning, and entity$srid will be remain the same
for spatial bounding box: at least 2 strategies could used: first (default) where the first data object is used for getting spatial bounding box (easy); or union (as union of spatial bounding boxes. In this case a new function should be designed to get the overall union bounding box given the possible mix of spatial representation types (sf objects for vector data, terra object for grid data).
With #263 and #264, geoflow will allow to get various
geoflow_dataobjects associated to ageoflow_entity. The use of #263 will even allow to mix differentgeoflow_dataspatial representation types (vector, grid). This is the main driver of doing #264, but this also requires to define strategies for entity enrichment:srid: a unique srid should be used among data associated. In case of there is a mix of SRIDs ingeoflow_datafeatures/coverages, this will necessarily be ignored with a warning, andentity$sridwill be remain the samefirst(default) where the first data object is used for getting spatial bounding box (easy); orunion(as union of spatial bounding boxes. In this case a new function should be designed to get the overall union bounding box given the possible mix of spatial representation types (sf objects for vector data, terra object for grid data).