A connector in charge of persisting context data sources into other third-party databases and storage systems, creating a historical view of the context
In some use cases, we need to define an attribute meaning location (although the CB doesn't pay attention to it, due to the actual location of the entity is in another attribute) and Cygnus to process that attribute as location.
For instance, we have an entity with two attributes: location (of type geo:json, the actual location of the entity) and areaServer (of type geo:json:extra, thus ignored by CB). Both attributes should be parsed as locations in Cygnus (as the corresponding column in the postgis table is of type location).
However, Cygnus only processes geo:json ~and geo:point at the present moment~. Thus, we should extend the functionality to take also into account geo:json:extra.
In some use cases, we need to define an attribute meaning location (although the CB doesn't pay attention to it, due to the actual location of the entity is in another attribute) and Cygnus to process that attribute as location.
For instance, we have an entity with two attributes: location (of type geo:json, the actual location of the entity) and areaServer (of type geo:json:extra, thus ignored by CB). Both attributes should be parsed as locations in Cygnus (as the corresponding column in the postgis table is of type location).
However, Cygnus only processes geo:json ~and geo:point at the present moment~. Thus, we should extend the functionality to take also into account geo:json:extra.
NOTE: geo:json:extra is just an example. Maybe there are better alternatives for this literal. The only requirement is that it must not conflit with the ones that Orion uses for geolocation (otherwise Orion will reject the entity, given it only allows one geolocation attribute, more detail: https://fiware-orion.readthedocs.io/en/master/user/ngsiv2_implementation_notes/index.html#limit-to-attributes-for-entity-location)