GraphQL Error for each of the graphic options

visualize-admin / visualization-tool

The tool for visualizing Swiss Open Government Data. Project ownership: Federal Office for the Environment FOEN

https://visualize.admin.ch

BSD 3-Clause "New" or "Revised" License

32 stars 3 forks source link

GraphQL Error for each of the graphic options #1001

Closed tboeni closed 1 year ago

tboeni commented 1 year ago

When dispalying the Cube in Visualize. For each of the graphic options there will be an error message dispalyed as follows: graphql error There is no error or warnings in Cube Creator.

To reproduce, just follow the the Visualize link above. Happens in both Edge and Firefox browsers

sosiology commented 1 year ago

Hi @tboeni thank you for your note. The link you shared takes me to the data set overview page, could you specify the name of the data set you are referring to?

tboeni commented 1 year ago

@sosiology Hi, sure the Cube is called SwissPRTROnlyTruncated_PQ_1 in Cube Creator not sure if this link is more helpful, or do you need the csv file which has been used for integration?

sosiology commented 1 year ago

Hi @tboeni Thank you very much. I think I was able to find the data set you are referring to and reproduce the error (see image below) In future when taking screenshots, it is always helpful to include the data set in the screenshot (see image below), this helps us reproduce the error on our side. Thanks in advance!

FabianCretton commented 1 year ago

In the context of this possible "bug", Thomas Bettler suspects that Visualize can not handle a nominal dimension that is a string. Which is, in his opinion, ok for the Cube schema, but not ok for Visualize.

A clarification about this would be great, thanks @ptbrowne or anyone.

bprusinowski commented 1 year ago

Hi, it seems that the error is related to some of the dimensions having a langString type. We have an explicit warning in the code that in such case, filtering won't work – it seems that Visualize hasn't been able to handle such dimensions for a long time (the code is over two years old).

While I am not exactly sure why this is the case, I wonder if the string dimensions should be formatted in a different way, like having localized schema:name instead of using the data type of langString? At least I think that's the case in other cubes, @FabianCretton was this the way you structured your cubes when it comes to localized strings?

FabianCretton commented 1 year ago

A few questions to better understand: @tboeni What is this identifier ?? Are you sure all those fields are needed to identify one observation, and could the cause problems when generating a URL ?

@tboeni When I open the cube, The Cube Designer displays nothing and turns undefinitely: could this be an error because of my question here above ? Isn't it normal that Visualize can not load the data if the Cube Designer can not either ?

@bprusinowski I do not really understand your question about langString, I think we use strings with language tag very often (with schema:name but any other property), no ?

bprusinowski commented 1 year ago

Hi @FabianCretton, thanks for your answer! I think here the difference is that in other, working cubes, localised strings are inside a named node, like here:

however inside the cube of @tboeni, it seems to be done via langString literal directly, I think this is the case of Visualize crashing.

FabianCretton commented 1 year ago

@bprusinowski well, this is all perfectly fine RDF to me, so I do not understand why there should be a limitation here. Was it a decision with Zazuko, and, if so, is it documented somewhere (in the Cube ontology or the Cube Creator User Guide) ?

But on second thought, the Cube Creator allows to have a language tag when defining the CSV mapping, so I think it is rather a "wrong assumption" in visualize, no ?

FabianCretton commented 1 year ago

@bprusinowski and @tboeni I come back with some news, as I did create a copy of the cube, correcting what seemed strange to me.

My cube displays now fine in Visualize - cube name "Swissprtr Abfall TEST FAB". @bprusinowski I did not change anything about the langSring, so Visualize is fine with that, which is good new :-)

@tboeni, Here are the things I corrected in the cube, I think we can clairify this if it is not clear for you:

The cube's identifier was strange, with all fields. Which would lead to very long URLs, I do not eve know what can happen in this case. I understand why you did that (the redundant lines with only the 'Wert' that is different), but it is not a good way to solve that. For my test, I did simply add a IDFake column with a unique number for each line
In the Cube Designer, you defined 2 'Key dimensions', BetriebsID+Jahr, which are not creating a unique identifier
In the Cube Designer, some dimensions had no name, I do not know how visualize could handle that ? (@bprusinowski )

bprusinowski commented 1 year ago

Thanks a lot for your support @FabianCretton! 💯

At first glance it looked that there was something wrong with langStrings, but I am glad that it turned out to not be a problem. I am still not sure why we have such logic in the app, @ptbrowne does it ring a bell?