Geometry length mismatched between Java/Javascript

[DenisCarriere]

Geometry length mismatched between Java/Javascript

Geometry length calculations are mismatched (~35cm off between Javascript/Java implementation), currently using Haversine Formula for the length of the geometry. I could calculate the length using the rhumb distance, maybe it will match.

Used this geometry to calculate the ~35cm offset between both libraries.

const line = [[-74.006449, 40.739405000000005], [-74.00790070000001, 40.7393884], [-74.00805100000001, 40.7393804]];

sharedstreets.distanceToNextRef(line) //=> 13501
// => Java Implementation => 13536

To-Do

• [ ] Looking into Rhumb line distance calculations for length of Geometry. Currently using @turf/length (uses harversine formula)
• [ ] Look into Base Segments are calculated (Java implementation)

[kpwebb]

This might be an argument in favor of reducing the precision of the lat/lons used in hashes. If we went to five decimals we'd be +/- 1.1m at worst. Need to keep six decimal precision in the actual stored lat/lon value though.

[DenisCarriere]

👍 five decimals works & stored as 6 decimals.

• 40.739405 => 40.739410

Kinda odd... but 6 decimals is a bit too intense for matching up custom data with OSM.

We could always add an optional parameter options.precision to change the decimal precision (default=6) in the JS library.

That way in the CLI conflator we can pass --precision 5 if one needs to lower the precision for better matching.

[kpwebb]

That's ok! I was never expecting the hashes to allow direct matching between different data sets (that happens with fuzzy matching using the full reference) but we need to be able to reliably calculate data from the lat/lons within a data set across implementations. If the precision is too great to allow that, then let's dial it back...

[DenisCarriere]

data set across implementations.

Even NodeJS has different Math precisions at each major release, Javascript code running on Node 6 will be slightly different then Node 9. In TurfJS we try to at least Truncate to 6 decimals, but sometimes we need to go down to 5 decimals to get the same results across all Node versions. I'm sure another language would be even greater.

If the precision is too great to allow that, then let's dial it back...

👍 Sure thing, we just need to make sure that the Java Builder syns up with the Javascript library.

So is the SharedStreets Message going to be at 5 decimals?

Ex: Intersection 110.12345 70.54321

Need to keep six decimal precision in the actual stored lat/lon value though.

Agreed, the Geometry coordinates will need to be stored at 6 decimals

[kpwebb]

ok! let's stage this for a future release (i'll regenerate the global tileset ids at 5 decimals later this week), but keep as is for the moment.

[DenisCarriere]

👍 Ok, no rush, it can be a lot later until we get things stable first.

5 decimals on the back burner 👍

[kpwebb]

closed in #20