extra decimals are introduced in GeoCoordinates (longitude)

[jmcanterafonseca]

Entity:

'id': 'urn:ngsi-ld:T_Query:EntityForQuery2345',
    'type': 'T_Query',
    'P100': {
      'type': 'Property',
      'value': 12,
      'observedAt': '2018-12-04T12:00:00',
      'P1_R1': {
        'type': 'Relationship',
        'object': 'urn:ngsi-ld:T2:6789'
      },
      'P1_P1': {
        'type': 'Property',
        'value': 0.79
      }
    },
    'R100': {
      'type': 'Relationship',
      'object': 'urn:ngsi-ld:T2:6789',
      'R1_R1': {
        'type': 'Relationship',
        'object': 'urn:ngsi-ld:T3:A2345'
      },
      'R1_P1': {
        'type': 'Property',
        'value': false
      }
    },
    'location': {
      'type': 'GeoProperty',
      'value': {
        'type': 'Point',
        'coordinates': [-30.01, 75.01]
      }
    }
  };

When retrieved, coordinates are

'value': {
'type': 'Point',
'coordinates': [-30.01, 75.010002]
}

[kzangeli]

Yeah, this is no good ...
Floats are like that, unfortunately. That's kind of how a computer works. It's not apt to treat floats, only integers. There are rounding errors.
The only way to really fix this problem is to store floats as strings and during serialization, render them also as strings but without quotes. This fixes that particular problem to 100%. But, another one is introduced. The 'q' and 'mq' filters would stop working, as the float is no longer a float but a string.
To fix also this problem, we'd need to store not one value but two, a string for rendering and a float for comparison ...

In short, this is a pretty complex problem and will need some thought before we decide how to fix it.

[jmcanterafonseca]

why the latitude does not suffer from that problem?

[kzangeli]

Well, these are rounding errors.
It all depends on how the value is stored inside its float.
Sometimes a value e.g. 13 gets stored as 13.00000000001.
Computers aren't made for floating numbers ...
Always preferable to use integers, like storing milliseconds instead of seconds etc.
That said, there is a possible fix, as I mentioned before - to store TWO values instead of one.

[kzangeli]

I will make a simple test and see how the value 75.01 is stored in mongo.
But, as I mentioned, there will always be rounding errors, not much we can do about it -
except for storing two different values, a string for rendering and a float for comparisons.

[kzangeli]

Said and done.
PR #59 tests the rounding problem both for what is stored in mongo and the response with GET.
In my Ubuntu laptop there is no rounding error.
However, this is no guarantee for that it will work also in other machines ...