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
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:
At the present moment, CB stores in DB the attribute Feature/FeatureCollection value as it was created/updated
A new option flag will be developed to specify that the user want the full Feature or FeatureCollection representation. In particular:
A new option for GET, eg. ?options=fullGeoJson
A new boolean field for subscriptions, e.g. "fullGeoJson": true|false
The default mode will be as we have now (version 3.7.0), to ensure backward compatibility. That is, not returning full Geo JSON
The text was updated successfully, but these errors were encountered:
Documentation doc/manuals/user/ngsiv2_implementation_notes.md has a paragrah:
Note that actually Orion stores the full value used at Feature or FeatureCollection
creation/updating time. However, from the point of view of normalization with other geo:json types,
it has been decided to return only the geometry 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.
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
The text was updated successfully, but these errors were encountered: