Documentations mistakes or code issues ? about geodesy HOT 12 CLOSED

Would it be worth getting rid of the documentation in the README and instead just linking directly to the JS Docs? That way you only have to maintain the JS Doc.

from geodesy.

@thorinisme About your strange results: in theory I would expect that assuming var p=(new LatLon(0, 0)).destinationPoint(100000, 90) then p.lat should be zero. Assuming var p=(new LatLon(0, 0)).destinationPoint(100000, 270) then p.lat should be zero too.

Now, with https://raw.githubusercontent.com/chrisveness/geodesy/v1.1.2/latlon-spherical.js we have that the absolute value of p.lat is less than 2e-16 degree; since LatLon(0, 0) is a point lying on the Equator that means that the destination point is not on the Equator (as expected) but it lies 22 picometers northern (or southern) of the Equator.

from geodesy.

i updated my post cause i noticed a strange behavior too

from geodesy.

@chrisveness could you take a look to this issue please ? I really would like to use your lib but geodesy seems unstable.

from geodesy.

@thorinisme just out of curiosity, what precision do you need? Meters? Millimeters? Thank you.

from geodesy.

@alessandro-gentilini

your message sounds like humour ^^

To answer you about my first point named distance unit,
I don't really care about unit the lib use. Making a conversion is pretty simple. I just need someone confirm it is meters or something else.

About second point named function parameters
Following my tests it seems the documentation of readme is not correct. documentation link seems the good one.

About third point named strange results
That point is my main concern. I can not use a library which doesn't work like expected.

from geodesy.

@thorinisme my apologies, I had no idea that (very!) old version of the documentation was lurking on my site; I have now deleted it. The correct version is www.movable-type.co.uk/scripts/geodesy/docs.

All surface distances are metres throughout the API; it is the responsibility of the user of the library to convert them to kilometres (or miles) if required (the kilometres default was a very early misjudgement).

@JamesMilnerUK I think the summary of functions in the README might be a useful quick reference, but I shall give some thought as to whether the full documentation is actually easier to use.

from geodesy.

@alessandro-gentilini
Thanks for your answer. I didn't notice the exponential notation.

@chrisveness Thanks too
I let you close the issue about readme.

from geodesy.

@thorinisme @chrisveness If I am not wrong, it seems to me that an error in the range of 1/100 and 1/1000 of degree is there: https://jsfiddle.net/9kmexoze/4/ but maybe it is expected.

Absolute delta: min=5.51e-17 median=0.00706 mean=0.0201 max=0.345

from geodesy.

@alessandro-gentilini i am not enough good to answer you ^^

from geodesy.

@alessandro-gentilini that looks like a really interesting analysis, I like the use of simplestatistics/chart.js – but I'm not sure I entirely understand what you're measuring.

It looks like you are using destinationPoint(), to which the arguments are distance and initial bearing. Except on meridians and the equator, the bearing will continuously change when travelling along a great circle (see e.g. http://www.movable-type.co.uk/scripts/latlong.html#bearing). When travelling on an initial bearing east/west, the destination latitude will always vary from the starting latitude (except on the equator). I should perhaps change the name of the destinationPoint() parameter to clarify this, rather than just mentioning it in the description.

So it appears to me you are measuring the variance of bearing when travelling along a great circle path, rather than an error. Am I correct, or have I missed something?

from geodesy.

@chrisveness You are correct and I am sorry if I added confusion to this thread.

I am not an expert in navigation and I was naïvely thinking that (new LatLon(lat, 0)).destinationPoint(100000, 90).lat-lat should always be zero for any value of lat; now I think that it is true only if the path is along a circle of latitude.

I see here that you have rhumbDestinationPoint and so I would say that instead of the function name destinationPoint I would prefer the name orthodromeDestinationPoint but that is only my personal taste.

Thank you for your help and for your library!

from geodesy.