There seems to be a bug or at least inconsistency (that might be important is some cases) in geolatte-geom at least when used with Oracle JDBC.
We are doing some redesign/migration of geo data both on app and database side. Requirement of our client is to have exactly the same precision of geo data as before. Migration script creates thousands Points/MultiLines/Polygons using Hibernate Spatial as SDO_GEOMETRY in Oracle DB. We've found out that some values are different, that is:
if value being stored has up to 8 decimal places - value in db is exactly the same
if value being stored has more than 8 decimal places - value in db seems to be rounded to 8 decimal places
After some debugging rounding seems to be done in constructor oracle.sql.NUMBER(double v) called from OracleJDBCTypeFactory.
Our fix proposal is to use oracle.sql.NUMBER(BigDecimal v) rather than oracle.sql.NUMBER(double v).
Below you can find a draft of integration test that fail with geolatte-geom 1.6.0 (and works fine with provided pull request). Flushing and clearing entityManager before second geometry comparision is crucial, as compared geometry comes from database (not a cache or smth).
There seems to be a bug or at least inconsistency (that might be important is some cases) in geolatte-geom at least when used with Oracle JDBC.
We are doing some redesign/migration of geo data both on app and database side. Requirement of our client is to have exactly the same precision of geo data as before. Migration script creates thousands Points/MultiLines/Polygons using Hibernate Spatial as SDO_GEOMETRY in Oracle DB. We've found out that some values are different, that is:
After some debugging rounding seems to be done in constructor oracle.sql.NUMBER(double v) called from OracleJDBCTypeFactory. Our fix proposal is to use oracle.sql.NUMBER(BigDecimal v) rather than oracle.sql.NUMBER(double v).
Libraries used:
Below you can find a draft of integration test that fail with geolatte-geom 1.6.0 (and works fine with provided pull request). Flushing and clearing entityManager before second geometry comparision is crucial, as compared geometry comes from database (not a cache or smth).
shouldReturnSameCoordinatesForPointUseSDOPointToFalse
shouldReturnSameCoordinatesForMultiPoint