3
$\begingroup$

After importing a JSON file, Mathematica changed the order of the fields. For example, I downloaded a sample file from:

http://api.openweathermap.org/data/2.5/find?lat=55.5&lon=37.5&cnt=10

I pasted it in Notepad and saved is as a .sjon file

The first records of the JSON data looks like 

{"message":"accurate", "cod":"200", "count":10, "list":[...], ...}

After importing it to Mathematica, I get a list of rule in a different order:

{"message" -> "accurate", "cod" -> "200", "list" -> {...}, ..., "count" -> 10}

In the original file count is at the third position. After importing it to Mathematica, it has moved to the last position. I've seen the same issue with other JSON files.

Who understands this issue and has a solution?

Improve this question
$\endgroup$
1
  • $\begingroup$ In the future, please give more descriptive titles to posts when possible. $\endgroup$
    – Szabolcs
    Jun 18, 2015 at 13:27

2 Answers 2

Reset to default
4
$\begingroup$

refering to my answer your other question here is how you can get a table of e.g. coordinates and temperature from your example data (adopt to your needs):

url = "http://api.openweathermap.org/data/2.5/find?lat=55.5&lon=37.5&cnt=10";
data = Import[url,"JSON"] //. x : {__Rule} :> Association[x];
Map[
  (# @@@ {{"coord","lat"}, {"coord","lon"}, {"main","temp"}}) &,
  data["list"]
]

getting the value of "count" is of course almost trivial (and much more readable than getting that by position as well):

data["count"]
Improve this answer
$\endgroup$
1
  • $\begingroup$ Thanks, this was exactly my problem. $\endgroup$
    – Michiel van Mens
    Jun 19, 2015 at 7:34
6
$\begingroup$

JSON stands for JavaScript Object Notation. In JavaScript, and hence in JSON, the ordering of dictionary keys is not determined, and not meaningful. Thus Mathematica's behaviour is correct.

From the JavaScript language specification,

An Object is an unordered collection of properties. Each property consists of a name, a value and a set of attributes.

Values are meant to be extracted by key from a a dictionary, not by position. If you refer to "count" by its name, this won't be an issue. See here on how to do this in Mathematica

To sum up: never extract dictionary values by position index from JSON. Always use the key name.

See also here (and many others): https://stackoverflow.com/a/7198442/695132

Improve this answer
$\endgroup$
5
  • $\begingroup$ Thanks for your answer. I want to use the JSON file for analysis purpose. For example, textmining on twitter messages. For that reason it is necessary that the records has a fixed order of the fiels-values. Do you have a suggestion to solve this issue? $\endgroup$
    – Michiel van Mens
    Jun 18, 2015 at 14:05
  • $\begingroup$ @MichielvanMens: as Szabolcs has explained there is no ordering in the properties of a JavaScript object, so in the (very unlikely) case that someone puts any information into that ordering then that is an error in the data. Also from your vague description I don't see why you'd need field ordering to make correct use of that kind of data, could you show an example where this seems necessary? It certainly isn't necessary to work with the example data you gave in your question... $\endgroup$
    – Albert Retey
    Jun 18, 2015 at 14:30
  • $\begingroup$ @AlbertRetey: analyzing twittter messages I have to deal with nested associations. See my question mathematica.stackexchange.com/questions/86150/…. Kuba wrote a good answer which works for me: ass //. a_Association :> Values[a] // Flatten. The result is a table which I can use for analyse purpose. But it's necessary that al the fiels have the same order $\endgroup$
    – Michiel van Mens
    Jun 18, 2015 at 16:30
  • $\begingroup$ @MichielvanMens: I have seen that question and IMHO it confirms that you are doing things wrong. If you really need that data as a plain table you should not construct it with Kubas solution but rather extract with something like I have shown in an answer to that other question -- and voila: field order doesn't play a role anymore... $\endgroup$
    – Albert Retey
    Jun 18, 2015 at 17:10
  • $\begingroup$ @MichielvanMens: one more note. I think it would turn out that the code for your analysis could very well be simpler, easier to read and less error prone if you'd not convert the nested Associations into flat tables. Depending on what you are doing it might even make sense to convert the list of nested Associations into a Dataset and use the new Query functionality for your analysis, but it might need some extra learning to make good use of that... $\endgroup$
    – Albert Retey
    Jun 18, 2015 at 17:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.