geoJSON formated spatial attributes from REST dataset, are not displayed
agaldemas opened this issue · 12 comments
Describe the bug
A REST data set, retrieve NGSI entities, with spatial attribute formatted in geoJSON, (Points and LineStrings)
Even you define spatial attribute coordinates as JSON, like it's written in the documentation, in a MapWidget, the features are never displayed on the map...
To Reproduce
Steps to reproduce the behavior:
-
set a REST data set retrieving NGSI V2 entities, using location spatial attribute defined in geoJSON
"location": {
"type": "geo:json",
"value": {
"type": "Point",
"coordinates": [
,
] -
use the data set in a MapWidget, configure Coordinates Type to JSON
-
after saving, the features are not and never displayed
Expected behavior
geoJSON features should be displayed on the map, as specified in the documentation...
Additional context information
We want to use Knowage in an existing Fiware based smart city project for traffic analysis, so this issue is really problematic, since :
1/ all entities location spatial attributes are already defined in geoJSON (NGSI V2 conformance).
2/ we also need to display LineString features, to represent RoadSegments, and color it based on an attribute value
So for the moment we can't use the software as is, too fulfill our needs, and which is a shame for the Fiware BI Analytics GE.
I had a look at the javascript code (cockpitModule_mapServices.js), it shouldn't be complex to add some reformatting of the feature in NGSI location, before adding it to the geoJSON openLayers map layer, and to add the styling of the layer.
Thanks to consider those problems as critical for our project, and very important for the Fiware image.
Hi,
first of all I suggest you to use a more updated official documentation from this link:
https://knowage-suite.readthedocs.io/en/7.2/
At the moment the only geoJSON format available for the map widget is the "pure" geoJSON, without the NGSI wrappers.
We are considering the possibility to expand it and to add different style attributes, but it's not in the current proximity roadmap.
You are free to contribute with a pull-request if you want to add the required reformatting.
I take this opportunity to inform you that since a pair of months Knowage is no longer a Fiware Enabler but it's present in the Fiware Markeplace.
This means that the Knowage usage is subject to AGPL3 license usage.
https://www.knowage-suite.com/site/knowage-is-fiware-ready-software-enabler/
Hi,
Thanks, for your feedback, and your update about the status of Knowage towards Fiware.
I was already using the right documentation version,
and I don't use especially NGSI mapping, I just use json path ($.[*]) to grab attributes in the data set.
But I don't catch what you wrote :
When you write "the only geoJSON format available for the map widget is the "pure" geoJSON", what does it means exactly ?
- That the whole dataset should be in "pure" geoJSON, meaning with semantics attributes as "properties",
- or That only the spatial attribute have to be true geoJSON, with the minimum content as :
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [<lon>,<lat>]
}
}
I tested, the second solution, with a specific spatial attribute "coords", formatted like above, but no markers displayed in the map widget...
However, this feature formatting, works with OpenLayers geoJSON format, hence my question !
Thanks in advance for your kind answer.
PS : We consider seriously to contribute very soon to the project, just I need to understand how it works with geoJSON features, before hacking the code ;O)
Hello, by debugging in browser, I managed to find the problem and modified knowagecockpitengine/src/main/webapp/js/src/angular_1.4/cockpit/services/cockpitModule_mapServices.js
In fact the reason of the problem is that the content of the spatial attribute, is not json, when using a REST data set,
the json content is converted in the dataset (we can , ':' are replaced by '=', and no " (quotes) for strings....,
for example a geoJSON feature :
{"type":"Polygon","coordinates":[[[5.64209,47.18345],[5.64262,47.18389],[5.64209,47.18345]]]}
comes as :
{type=Polygon,coordinates=[[[5.64209,47.18345],[5.64262,47.18389],[5.64209,47.18345]]]}
in the spatial attribute !, (it's already in this format when you preview the data set)
That's why openLayers can't understand the feature...
then I added a function to get back a valid geoJSON, json, for the spatial attribute, and the features appear on the map widget ;O)
My function is ugly, since I did not found an existing function to convert back to json, can someone tell me if such function exists ?
if not, I'll improve the function with regex, before proposing a PR.
Or may be it is an issue with the REST data set, which convert the json inside attributes ?
I did not test with a data source and sql data set, to check if the issue is the same or not, (but it seems that it's an internal format), in any case the function check the json is invalid, before changing the content of spatial attribute, then it shouldn't have side effect if the content is valid json.
Thanks in advance for advice on my problem.
Hi,
My thought is that:
{type=Polygon,coordinates=[[[5.64209,47.18345],[5.64262,47.18389],[5.64209,47.18345]]]}
Is the result of a toString() call on a Java Map.
You're calling a REST service, isn't it? Could you give me a sample of the original output of the service? I want to recreate you case on my local machine.
Hi @kerny3d
Sorry for long silence...
geospatial attributes comes in each json object as :
"location": {
"type": "geo:json",
"value": {
"type": "Point",
"coordinates": [
7.253000539,
43.701089603
]
},
"metadata": {}
}
or
"location": {
"type": "geo:json",
"value": {
"type": "LineString",
"coordinates": [
[
7.213329811,
43.669308113
],
[
7.213861871,
43.669601782
],
[
7.214746299,
43.669936285
],
[
7.21484661,
43.669974223
],
[
7.214924029,
43.670001532
],
[
7.215330526,
43.670144915
],
[
7.215901635,
43.670346359
],
[
7.21657315,
43.670555994
],
[
7.217101378,
43.670748464
],
[
7.217738763,
43.671072349
],
[
7.217930185,
43.671182601
],
[
7.218259619,
43.671315695
],
[
7.218620233,
43.671354072
]
]
},
"metadata": {}
}it's coming out of a Fiware Context Broker, in NGSI V2.
the "value" attribute is true GeoJSON !
the transformation is done at the data set level, since we see the same format with "=" replacing the ":", in the data set preview, so the objects are already transformed early after reading !
So if you fix the problem in the server, It will be far more better than my ugly workaround ;O)
Hi, no news on this, I'm sorry. We are working hardly on the new release.
OK, I understand, since my ugly hack is working, it's not so urgent.
Nevertheless, I can see that the conversion is done on the REST GET response data, since the '=' instead of ':' appears even in the dataset preview, if you can give me clues on where to search in the code, I can try to help and fix the problem...
Hello, @kerny3d, any clue to give me for fixing the problem ?
I imagine it's somewhere in "Knowage-Server/knowageutils/src/main/java/it/eng/spagobi/tools/dataset/bo/ConfigurableDataSet.java"
and "Knowage-Server/knowageutils/src/main/java/it/eng/spagobi/tools/dataset/common/datawriter/JSONDataWriter.java
but it seems nothing is done to detect json content, in order to preserve its content !
this should be done in JSONDataWriter.java, but later serialization with a toString(), should wipe this effort to preserve json content...
may be the solution should be to restore json content before delivering it to document...
I understand solving this problem is not so simple...
And that, by the way, my hack in cockpitModule_mapServices.js is somehow a nice workaround for the moment !
if you want I can do a PR with my hacked version of cockpitModule_mapServices.js, feel free to merge it or not !
This issue is stale because it is related to an old version or it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.
This issue was closed because it has been stalled for 5 days with no activity.