You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When pisces creates database tables, the type used for non-integer fields is real. For example, this is a table - Origin:
CREATE
TABLE IF NOT EXISTS origin
(
lat real,
lon real,
depth real,
...
The use of this data type causes problems with accuracy and with the search for events at given coordinates.
For example I have an event with coordinates lat: 41.0508 lon:79.5898. I am running a query:
SELECT * FROM origin WHERE lat=41.0508 AND lon=79.5898;
which returns nothing.
If I manually change the real data type to numeric, then I find the desired event.
Floating point variables are vulnerable to floating point errors. Therefore, if accuracy is important it's always recommended to use a numeric type.
The text was updated successfully, but these errors were encountered:
Thanks for all your feedback. This is helpful. I was trying to choose data types that were generic, but ultimately resolved the the ones used by my team. Your solution may be a better one; let me see how numeric works with our backend and I'll try to respond quickly.
When pisces creates database tables, the type used for non-integer fields is real. For example, this is a table - Origin:
The use of this data type causes problems with accuracy and with the search for events at given coordinates.
For example I have an event with coordinates lat: 41.0508 lon:79.5898. I am running a query:
SELECT * FROM origin WHERE lat=41.0508 AND lon=79.5898;
which returns nothing.
If I manually change the real data type to numeric, then I find the desired event.
Floating point variables are vulnerable to floating point errors. Therefore, if accuracy is important it's always recommended to use a numeric type.
The text was updated successfully, but these errors were encountered: