Was there a recent update that changed the POINT data type to WSG 84?
This happened for all POINT data types in our platform and I was curious if there was some warning beforehand or if this has happened before.
By default, Backendless has always used the WGS84 coordinate system.
In the US cluster this parameter was used implicitly, unlike the European cluster e.g.
On Monday, maintenance work was announced, which also affected the optimization of work with the databases.
But the main point is: your data remains unchanged, they are the same as before maintenance.
So, if you created/imported them in that or other type, that type you’ll see in web-console.
The optimization affected on how spatial data are stored. As a result from now you will receive more precise results for all spatial functions, and their behavior depends on the type of SRS (spatial reference system). At this point we support two: WGS84 and Cartesian, but may add more in a future.
1 Like
The issue we experienced was that we were either switched to WSG84 or the standard for it changed because our Cartesian coordinates stopped being saved and through and out of range exception.
Prior to the maintenance work, we had never had this issue and it’s been resolved now (created a new column and renamed to the original column name). But it’s fine for now; just wanted to update you on how the maintenance might have affected us.
Perhaps the error was occurring while the database of your app was being migrated. I apologize for the inconvenience this has caused. I am glad the issue is resolved now, the upgraded database should yield much better performance and more precise geospatial results.
Regards,
Mark
1 Like
Awesome!
Thanks Mark.
-Innocent.
Glad to know that your problem was solved.
But i wanted to shed the light on this case:
because our Cartesian coordinates stopped being saved and through and out of range exception.
We do not change data without the consent of our customers, so the data really left untouched. Before maintenance we have no inner db control over records for spatial types. So, despite the column type until now you had a possibility of inserting wrong data (with import operation e.g.) for specific record – either wrong SRS or wrong range for x,y. After more research, I’m leaning towards this option.
From now the control became more strict, because all spatial functions (as i mentioned above) take into account SRS. E.g. for you it means, that distance function for Cartesian will return the length of line on plane (dimensionless quantity), while for WGS84 it will be distance between two points on Geoid in meters (physical quantity).
Hope it will be helpful for you in deeper understanding how it works.
While I’m sure nothing was altered, I can only report what I experienced.
I’m sure you’d be just as confused if code you hadn’t changed just stopped working but that’s what happened in my case. The format of our coordinates never changed and I even attempted to set the coordinate property using already entered coordinates and it failed as well. Just glad it’s now resolved.
Innocent.