Open fgalan opened 2 years ago
A new option for GET, eg.
?options=fullGeoJson
The following .test files (pay attention at commit hash) can be useful when implementing that:
(The correspond to a version of the code when we think that the "full GeoJSON mode" were what we need)
Documentation doc/manuals/user/ngsiv2_implementation_notes.md has a paragrah:
Note that actually Orion stores the full value used at
Feature
orFeatureCollection
creation/updating time. However, from the point of view of normalization with othergeo:json
types, it has been decided to return only thegeometry
part. In the future, maybe a flag to return the full content would be implemented (more detail in this issue).
That would need to be adapted upon fixing of this issue.
Implementation notes:
In ContextAttribute::toJson() this is the key part:
if (compoundValueP != NULL)
{
orion::CompoundValueNode* childToRenderP = compoundValueP;
if (type == GEO_JSON)
{
childToRenderP = getGeometry(compoundValueP);
}
// Some internal error conditions in getGeometryToRender() (e.g. out of band manipulation
// of DB entities) may lead to NULL, so the check is needed
if (childToRenderP != NULL)
{
jh.addRaw("value", childToRenderP->toJson());
}
}
The new flag has to be taken into account in if (type == GEO_JSON)
so getGeometry() doesn't get invoked if full GeoJSON is requested.
After some internal discussion, we have decided that the processing of Feature and FeatureCollection geo:json attributes (issue #4114) will involve a normalization in GET/notification stage. That is, CB will accept the Feature and FeatureCollection format in attribute creating/update but in attribute GET/notification only the geometry will be returned.
This involves a lost of information in the attribute being created/update (in particular, the
properties
field associate to the Feature). For current use case, that information is not needed, but maybe it is needed in the future. Thus:?options=fullGeoJson
"fullGeoJson": true|false