Difference between ol.proj.getPointResolution() and ol.sphere.getDistance() Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern) Announcing the arrival of Valued Associate #679: Cesar Manara Unicorn Meta Zoo #1: Why another podcast?WGS point to WGS line segment (great circle) distanceGenerate random location within specified distance of a given pointWhat is the precise distance from equator to pole according to WGS84?Hex grid on EPSG:4326 globe (for use in Leaflet)Difference between OpenLayers 2 and OpenLayers 3?Difference between planar and Euclidean distance?Is there any difference between gdal_proximity.py and ArcGIS Euclidean Distance?what is the difference between ol.Map and ol.PluggableMap in openlayersAlgorithm for Calculating Distance Between Two PointsDifference between Geodetic Distance and Great Circle Distance?

Should man-made satellites feature an intelligent inverted "cow catcher"?

Was the pager message from Nick Fury to Captain Marvel unnecessary?

Why are two-digit numbers in Jonathan Swift's "Gulliver's Travels" (1726) written in "German style"?

Baking rewards as operations

NIntegrate on a solution of a matrix ODE

Any stored/leased 737s that could substitute for grounded MAXs?

What criticisms of Wittgenstein's philosophy of language have been offered?

Determine whether an integer is a palindrome

Is this Kuo-toa homebrew race balanced?

Centre cell vertically in tabularx

What is the proper term for etching or digging of wall to hide conduit of cables

French equivalents of おしゃれは足元から (Every good outfit starts with the shoes)

How do you write "wild blueberries flavored"?

Random body shuffle every night—can we still function?

As a dual citizen, my US passport will expire one day after traveling to the US. Will this work?

Vertical ranges of Column Plots in 12

Why does BitLocker not use RSA?

Is there a spell that can create a permanent fire?

Derived column in a data extension

.bashrc alias for a command with fixed second parameter

Pointing to problems without suggesting solutions

Did John Wesley plagiarize Matthew Henry...?

Inverse square law not accurate for non-point masses?

By what mechanism was the 2017 UK General Election called?



Difference between ol.proj.getPointResolution() and ol.sphere.getDistance()



Planned maintenance scheduled April 23, 2019 at 23:30 UTC (7:30pm US/Eastern)
Announcing the arrival of Valued Associate #679: Cesar Manara
Unicorn Meta Zoo #1: Why another podcast?WGS point to WGS line segment (great circle) distanceGenerate random location within specified distance of a given pointWhat is the precise distance from equator to pole according to WGS84?Hex grid on EPSG:4326 globe (for use in Leaflet)Difference between OpenLayers 2 and OpenLayers 3?Difference between planar and Euclidean distance?Is there any difference between gdal_proximity.py and ArcGIS Euclidean Distance?what is the difference between ol.Map and ol.PluggableMap in openlayersAlgorithm for Calculating Distance Between Two PointsDifference between Geodetic Distance and Great Circle Distance?



.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;








1















Is there anyone who can explain the difference between ol.proj.getPointResolution() and ol.sphere.getDistance()?



I have tested it, and ol.sphere.getDistance() is a little bit shorter than ol.proj.getPointResolution().
In addition, I corrected the lengths by elevations with the Pythagoras.
Below an GPX example file.



Why is with "sphere" shortener? "sphere" calculate with a radius and not the direct distance, logical there must be greater. ???
The same difference exists everywhere on the map, also much further north, eg in Europe.



Only getLength(): 1322.334212854104



getLength() with pythagorean(): 1322.4583239930157



ol.proj.getPointResolution(): 1322.3120192140298



ol.proj.getPointResolution() with pythagorean(): 1322.436132435775



ol.sphere.getDistance(): 1320.834204523846



ol.sphere.getDistance() with pythagorean(): 1320.9584565960345



GPX Example (near equador) from brouter.de



<?xml version="1.0" encoding="UTF-8"?>
<!-- track-length = 1323 filtered ascend = 0 plain-ascend = -1 cost=4036 energy=.0kwh time=9.9m -->
<gpx
xmlns="http://www.topografix.com/GPX/1/1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"
creator="BRouter-1.4.11" version="1.1">
<trk>
<name>brouter_trekking_0</name>
<trkseg>
<trkpt lon="11.487967" lat="0.332443"><ele>319.0</ele></trkpt>
<trkpt lon="11.488969" lat="0.332369"><ele>318.0</ele></trkpt>
<trkpt lon="11.494446" lat="0.331905"><ele>309.0</ele></trkpt>
<trkpt lon="11.499806" lat="0.331473"><ele>317.0</ele></trkpt>
</trkseg>
</trk>
</gpx>


Example what i mean:



enter image description here



1) is simple length() between two coords. (longest).

2) the earth is round, but a direct distance is "through" the earth. (shortest).

3) the earth is round and the distance is on the earths surface. (best).



TEST:



Result (single-calculation sum, in meter):



Near Equator short distance (4 points), manually set elevation (350,100,0,300):



brouter (inside GPX file) = 1323



ol.proj.getPointResolution() = 1322.3120192140298

ol.proj.getPointResolution() + pythagorean() = 1563.4324417597672



ol.sphere.getDistance() = 1320.834204523846

ol.sphere.getDistance() + pythagorean() = 1562.1085409935195



distVincenty() = 1322.2532472090315

distVincenty() + pythagorean() = 1563.379164847775




Near Equator long distance, 440 meter elevation range (min,max):



brouter (inside GPX file) = 385356



ol.proj.getPointResolution() = 384026.1115163949

ol.proj.getPointResolution() + pythagorean() = 384353.99178101047



ol.sphere.getDistance() = 383596.9242847851

ol.sphere.getDistance() + pythagorean() = 383925.16964882094



distVincenty() = 383079.99691655475

distVincenty() + pythagorean() = 383408.65056785266




Europe near Pyrenees long distance, 430 meter elevation range (min,max):



brouter (inside GPX file) = 144047



ol.proj.getPointResolution() = 142398.39352352163

ol.proj.getPointResolution() + pythagorean() = 142514.5599121801



ol.sphere.getDistance() = 142239.2492071166

ol.sphere.getDistance() + pythagorean() = 142355.53984053037



distVincenty() = 142463.4265797505

distVincenty() + pythagorean() = 142579.5329685958




Fazit: The joke is, the first was i notice, that the ol.proj.getPointResolution() is shorter than brouter. Than i test ol.sphere.getDistance(), and this was more shorter. Last i test distVincenty(), and this was once shorter and some longer than the other (Equator shorter, Europe longer), but shorter as brouter. Logical would be for me, though the ol.proj.getPointResolution() was the shortest and the distVincenty() was the longest. Does anyone have an explanation for that?










share|improve this question






























    1















    Is there anyone who can explain the difference between ol.proj.getPointResolution() and ol.sphere.getDistance()?



    I have tested it, and ol.sphere.getDistance() is a little bit shorter than ol.proj.getPointResolution().
    In addition, I corrected the lengths by elevations with the Pythagoras.
    Below an GPX example file.



    Why is with "sphere" shortener? "sphere" calculate with a radius and not the direct distance, logical there must be greater. ???
    The same difference exists everywhere on the map, also much further north, eg in Europe.



    Only getLength(): 1322.334212854104



    getLength() with pythagorean(): 1322.4583239930157



    ol.proj.getPointResolution(): 1322.3120192140298



    ol.proj.getPointResolution() with pythagorean(): 1322.436132435775



    ol.sphere.getDistance(): 1320.834204523846



    ol.sphere.getDistance() with pythagorean(): 1320.9584565960345



    GPX Example (near equador) from brouter.de



    <?xml version="1.0" encoding="UTF-8"?>
    <!-- track-length = 1323 filtered ascend = 0 plain-ascend = -1 cost=4036 energy=.0kwh time=9.9m -->
    <gpx
    xmlns="http://www.topografix.com/GPX/1/1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"
    creator="BRouter-1.4.11" version="1.1">
    <trk>
    <name>brouter_trekking_0</name>
    <trkseg>
    <trkpt lon="11.487967" lat="0.332443"><ele>319.0</ele></trkpt>
    <trkpt lon="11.488969" lat="0.332369"><ele>318.0</ele></trkpt>
    <trkpt lon="11.494446" lat="0.331905"><ele>309.0</ele></trkpt>
    <trkpt lon="11.499806" lat="0.331473"><ele>317.0</ele></trkpt>
    </trkseg>
    </trk>
    </gpx>


    Example what i mean:



    enter image description here



    1) is simple length() between two coords. (longest).

    2) the earth is round, but a direct distance is "through" the earth. (shortest).

    3) the earth is round and the distance is on the earths surface. (best).



    TEST:



    Result (single-calculation sum, in meter):



    Near Equator short distance (4 points), manually set elevation (350,100,0,300):



    brouter (inside GPX file) = 1323



    ol.proj.getPointResolution() = 1322.3120192140298

    ol.proj.getPointResolution() + pythagorean() = 1563.4324417597672



    ol.sphere.getDistance() = 1320.834204523846

    ol.sphere.getDistance() + pythagorean() = 1562.1085409935195



    distVincenty() = 1322.2532472090315

    distVincenty() + pythagorean() = 1563.379164847775




    Near Equator long distance, 440 meter elevation range (min,max):



    brouter (inside GPX file) = 385356



    ol.proj.getPointResolution() = 384026.1115163949

    ol.proj.getPointResolution() + pythagorean() = 384353.99178101047



    ol.sphere.getDistance() = 383596.9242847851

    ol.sphere.getDistance() + pythagorean() = 383925.16964882094



    distVincenty() = 383079.99691655475

    distVincenty() + pythagorean() = 383408.65056785266




    Europe near Pyrenees long distance, 430 meter elevation range (min,max):



    brouter (inside GPX file) = 144047



    ol.proj.getPointResolution() = 142398.39352352163

    ol.proj.getPointResolution() + pythagorean() = 142514.5599121801



    ol.sphere.getDistance() = 142239.2492071166

    ol.sphere.getDistance() + pythagorean() = 142355.53984053037



    distVincenty() = 142463.4265797505

    distVincenty() + pythagorean() = 142579.5329685958




    Fazit: The joke is, the first was i notice, that the ol.proj.getPointResolution() is shorter than brouter. Than i test ol.sphere.getDistance(), and this was more shorter. Last i test distVincenty(), and this was once shorter and some longer than the other (Equator shorter, Europe longer), but shorter as brouter. Logical would be for me, though the ol.proj.getPointResolution() was the shortest and the distVincenty() was the longest. Does anyone have an explanation for that?










    share|improve this question


























      1












      1








      1








      Is there anyone who can explain the difference between ol.proj.getPointResolution() and ol.sphere.getDistance()?



      I have tested it, and ol.sphere.getDistance() is a little bit shorter than ol.proj.getPointResolution().
      In addition, I corrected the lengths by elevations with the Pythagoras.
      Below an GPX example file.



      Why is with "sphere" shortener? "sphere" calculate with a radius and not the direct distance, logical there must be greater. ???
      The same difference exists everywhere on the map, also much further north, eg in Europe.



      Only getLength(): 1322.334212854104



      getLength() with pythagorean(): 1322.4583239930157



      ol.proj.getPointResolution(): 1322.3120192140298



      ol.proj.getPointResolution() with pythagorean(): 1322.436132435775



      ol.sphere.getDistance(): 1320.834204523846



      ol.sphere.getDistance() with pythagorean(): 1320.9584565960345



      GPX Example (near equador) from brouter.de



      <?xml version="1.0" encoding="UTF-8"?>
      <!-- track-length = 1323 filtered ascend = 0 plain-ascend = -1 cost=4036 energy=.0kwh time=9.9m -->
      <gpx
      xmlns="http://www.topografix.com/GPX/1/1"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"
      creator="BRouter-1.4.11" version="1.1">
      <trk>
      <name>brouter_trekking_0</name>
      <trkseg>
      <trkpt lon="11.487967" lat="0.332443"><ele>319.0</ele></trkpt>
      <trkpt lon="11.488969" lat="0.332369"><ele>318.0</ele></trkpt>
      <trkpt lon="11.494446" lat="0.331905"><ele>309.0</ele></trkpt>
      <trkpt lon="11.499806" lat="0.331473"><ele>317.0</ele></trkpt>
      </trkseg>
      </trk>
      </gpx>


      Example what i mean:



      enter image description here



      1) is simple length() between two coords. (longest).

      2) the earth is round, but a direct distance is "through" the earth. (shortest).

      3) the earth is round and the distance is on the earths surface. (best).



      TEST:



      Result (single-calculation sum, in meter):



      Near Equator short distance (4 points), manually set elevation (350,100,0,300):



      brouter (inside GPX file) = 1323



      ol.proj.getPointResolution() = 1322.3120192140298

      ol.proj.getPointResolution() + pythagorean() = 1563.4324417597672



      ol.sphere.getDistance() = 1320.834204523846

      ol.sphere.getDistance() + pythagorean() = 1562.1085409935195



      distVincenty() = 1322.2532472090315

      distVincenty() + pythagorean() = 1563.379164847775




      Near Equator long distance, 440 meter elevation range (min,max):



      brouter (inside GPX file) = 385356



      ol.proj.getPointResolution() = 384026.1115163949

      ol.proj.getPointResolution() + pythagorean() = 384353.99178101047



      ol.sphere.getDistance() = 383596.9242847851

      ol.sphere.getDistance() + pythagorean() = 383925.16964882094



      distVincenty() = 383079.99691655475

      distVincenty() + pythagorean() = 383408.65056785266




      Europe near Pyrenees long distance, 430 meter elevation range (min,max):



      brouter (inside GPX file) = 144047



      ol.proj.getPointResolution() = 142398.39352352163

      ol.proj.getPointResolution() + pythagorean() = 142514.5599121801



      ol.sphere.getDistance() = 142239.2492071166

      ol.sphere.getDistance() + pythagorean() = 142355.53984053037



      distVincenty() = 142463.4265797505

      distVincenty() + pythagorean() = 142579.5329685958




      Fazit: The joke is, the first was i notice, that the ol.proj.getPointResolution() is shorter than brouter. Than i test ol.sphere.getDistance(), and this was more shorter. Last i test distVincenty(), and this was once shorter and some longer than the other (Equator shorter, Europe longer), but shorter as brouter. Logical would be for me, though the ol.proj.getPointResolution() was the shortest and the distVincenty() was the longest. Does anyone have an explanation for that?










      share|improve this question
















      Is there anyone who can explain the difference between ol.proj.getPointResolution() and ol.sphere.getDistance()?



      I have tested it, and ol.sphere.getDistance() is a little bit shorter than ol.proj.getPointResolution().
      In addition, I corrected the lengths by elevations with the Pythagoras.
      Below an GPX example file.



      Why is with "sphere" shortener? "sphere" calculate with a radius and not the direct distance, logical there must be greater. ???
      The same difference exists everywhere on the map, also much further north, eg in Europe.



      Only getLength(): 1322.334212854104



      getLength() with pythagorean(): 1322.4583239930157



      ol.proj.getPointResolution(): 1322.3120192140298



      ol.proj.getPointResolution() with pythagorean(): 1322.436132435775



      ol.sphere.getDistance(): 1320.834204523846



      ol.sphere.getDistance() with pythagorean(): 1320.9584565960345



      GPX Example (near equador) from brouter.de



      <?xml version="1.0" encoding="UTF-8"?>
      <!-- track-length = 1323 filtered ascend = 0 plain-ascend = -1 cost=4036 energy=.0kwh time=9.9m -->
      <gpx
      xmlns="http://www.topografix.com/GPX/1/1"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"
      creator="BRouter-1.4.11" version="1.1">
      <trk>
      <name>brouter_trekking_0</name>
      <trkseg>
      <trkpt lon="11.487967" lat="0.332443"><ele>319.0</ele></trkpt>
      <trkpt lon="11.488969" lat="0.332369"><ele>318.0</ele></trkpt>
      <trkpt lon="11.494446" lat="0.331905"><ele>309.0</ele></trkpt>
      <trkpt lon="11.499806" lat="0.331473"><ele>317.0</ele></trkpt>
      </trkseg>
      </trk>
      </gpx>


      Example what i mean:



      enter image description here



      1) is simple length() between two coords. (longest).

      2) the earth is round, but a direct distance is "through" the earth. (shortest).

      3) the earth is round and the distance is on the earths surface. (best).



      TEST:



      Result (single-calculation sum, in meter):



      Near Equator short distance (4 points), manually set elevation (350,100,0,300):



      brouter (inside GPX file) = 1323



      ol.proj.getPointResolution() = 1322.3120192140298

      ol.proj.getPointResolution() + pythagorean() = 1563.4324417597672



      ol.sphere.getDistance() = 1320.834204523846

      ol.sphere.getDistance() + pythagorean() = 1562.1085409935195



      distVincenty() = 1322.2532472090315

      distVincenty() + pythagorean() = 1563.379164847775




      Near Equator long distance, 440 meter elevation range (min,max):



      brouter (inside GPX file) = 385356



      ol.proj.getPointResolution() = 384026.1115163949

      ol.proj.getPointResolution() + pythagorean() = 384353.99178101047



      ol.sphere.getDistance() = 383596.9242847851

      ol.sphere.getDistance() + pythagorean() = 383925.16964882094



      distVincenty() = 383079.99691655475

      distVincenty() + pythagorean() = 383408.65056785266




      Europe near Pyrenees long distance, 430 meter elevation range (min,max):



      brouter (inside GPX file) = 144047



      ol.proj.getPointResolution() = 142398.39352352163

      ol.proj.getPointResolution() + pythagorean() = 142514.5599121801



      ol.sphere.getDistance() = 142239.2492071166

      ol.sphere.getDistance() + pythagorean() = 142355.53984053037



      distVincenty() = 142463.4265797505

      distVincenty() + pythagorean() = 142579.5329685958




      Fazit: The joke is, the first was i notice, that the ol.proj.getPointResolution() is shorter than brouter. Than i test ol.sphere.getDistance(), and this was more shorter. Last i test distVincenty(), and this was once shorter and some longer than the other (Equator shorter, Europe longer), but shorter as brouter. Logical would be for me, though the ol.proj.getPointResolution() was the shortest and the distVincenty() was the longest. Does anyone have an explanation for that?







      openlayers distance






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Apr 14 at 22:47







      Suka

















      asked Apr 12 at 22:06









      SukaSuka

      416




      416




















          1 Answer
          1






          active

          oldest

          votes


















          2














          Sphere gives the shortest distance on a spherical planet. What appears to be a straight line on a flat map isn't the shortest distance that an aircraft would fly, especially over long distances such as London to Tokyo



          enter image description here



          distVincenty = function(p1, p2) 
          var ct =
          a: 6378137,
          b: 6356752.3142,
          f: 1/298.257223563
          ;
          var a = ct.a, b = ct.b, f = ct.f;

          var L = (p2.lon - p1.lon) * Math.PI/180;
          var U1 = Math.atan((1-f) * Math.tan(p1.lat*Math.PI/180));
          var U2 = Math.atan((1-f) * Math.tan(p2.lat*Math.PI/180));
          var sinU1 = Math.sin(U1), cosU1 = Math.cos(U1);
          var sinU2 = Math.sin(U2), cosU2 = Math.cos(U2);
          var lambda = L, lambdaP = 2*Math.PI;
          var iterLimit = 20;
          while (Math.abs(lambda-lambdaP) > 1e-12 && --iterLimit>0)
          var sinLambda = Math.sin(lambda), cosLambda = Math.cos(lambda);
          var sinSigma = Math.sqrt((cosU2*sinLambda) * (cosU2*sinLambda) +
          (cosU1*sinU2-sinU1*cosU2*cosLambda) * (cosU1*sinU2-sinU1*cosU2*cosLambda));
          if (sinSigma==0)
          return 0; // co-incident points

          var cosSigma = sinU1*sinU2 + cosU1*cosU2*cosLambda;
          var sigma = Math.atan2(sinSigma, cosSigma);
          var alpha = Math.asin(cosU1 * cosU2 * sinLambda / sinSigma);
          var cosSqAlpha = Math.cos(alpha) * Math.cos(alpha);
          var cos2SigmaM = cosSigma - 2*sinU1*sinU2/cosSqAlpha;
          var C = f/16*cosSqAlpha*(4+f*(4-3*cosSqAlpha));
          lambdaP = lambda;
          lambda = L + (1-C) * f * Math.sin(alpha) *
          (sigma + C*sinSigma*(cos2SigmaM+C*cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)));

          if (iterLimit==0)
          return NaN; // formula failed to converge

          var uSq = cosSqAlpha * (a*a - b*b) / (b*b);
          var A = 1 + uSq/16384*(4096+uSq*(-768+uSq*(320-175*uSq)));
          var B = uSq/1024 * (256+uSq*(-128+uSq*(74-47*uSq)));
          var deltaSigma = B*sinSigma*(cos2SigmaM+B/4*(cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)-
          B/6*cos2SigmaM*(-3+4*sinSigma*sinSigma)*(-3+4*cos2SigmaM*cos2SigmaM)));
          var s = b*A*(sigma-deltaSigma);
          var d = s.toFixed(3)/1000; // round to 1mm precision
          return d;
          ;





          share|improve this answer

























          • Yes, that's logical. But, my example is very short and at the equator. How do you explain that? With longer routes, up to 150 km in Europe, it is just like that. I can not drive "through" the globe, but I have to drive on the earth's surface, thats a longer way.

            – Suka
            Apr 12 at 23:27











          • Is "sphere" only for longer distances and "PointRes" more for short distances?

            – Suka
            Apr 13 at 0:03











          • Flat projections are generally not suitable for long distances. EPSG:3857 is based on the Earth's equatorial radius of 6378137 meters. ol.sphere uses the Earth's average radius of 6371008.8 meters. So right on the equator EPSG:3857 would be more accurate than ol.sphere. A transverse mercator projection such as UTM would be good if your route closely folowed a meridian. If you need extra precise calculation you need the Vincenty ellipsoid method which uses both the equatorial and polar radii.

            – Mike
            Apr 13 at 10:03











          • Oh wow, what a function! i understand not realy what, but a little bit. I have added a example picture on my question above. Please read to understand what i mean, and than please answer me whether the functions result is point 3 (red).

            – Suka
            Apr 14 at 19:10











          Your Answer








          StackExchange.ready(function()
          var channelOptions =
          tags: "".split(" "),
          id: "79"
          ;
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function()
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled)
          StackExchange.using("snippets", function()
          createEditor();
          );

          else
          createEditor();

          );

          function createEditor()
          StackExchange.prepareEditor(
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: false,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: null,
          bindNavPrevention: true,
          postfix: "",
          imageUploader:
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          ,
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          );



          );













          draft saved

          draft discarded


















          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fgis.stackexchange.com%2fquestions%2f318658%2fdifference-between-ol-proj-getpointresolution-and-ol-sphere-getdistance%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          2














          Sphere gives the shortest distance on a spherical planet. What appears to be a straight line on a flat map isn't the shortest distance that an aircraft would fly, especially over long distances such as London to Tokyo



          enter image description here



          distVincenty = function(p1, p2) 
          var ct =
          a: 6378137,
          b: 6356752.3142,
          f: 1/298.257223563
          ;
          var a = ct.a, b = ct.b, f = ct.f;

          var L = (p2.lon - p1.lon) * Math.PI/180;
          var U1 = Math.atan((1-f) * Math.tan(p1.lat*Math.PI/180));
          var U2 = Math.atan((1-f) * Math.tan(p2.lat*Math.PI/180));
          var sinU1 = Math.sin(U1), cosU1 = Math.cos(U1);
          var sinU2 = Math.sin(U2), cosU2 = Math.cos(U2);
          var lambda = L, lambdaP = 2*Math.PI;
          var iterLimit = 20;
          while (Math.abs(lambda-lambdaP) > 1e-12 && --iterLimit>0)
          var sinLambda = Math.sin(lambda), cosLambda = Math.cos(lambda);
          var sinSigma = Math.sqrt((cosU2*sinLambda) * (cosU2*sinLambda) +
          (cosU1*sinU2-sinU1*cosU2*cosLambda) * (cosU1*sinU2-sinU1*cosU2*cosLambda));
          if (sinSigma==0)
          return 0; // co-incident points

          var cosSigma = sinU1*sinU2 + cosU1*cosU2*cosLambda;
          var sigma = Math.atan2(sinSigma, cosSigma);
          var alpha = Math.asin(cosU1 * cosU2 * sinLambda / sinSigma);
          var cosSqAlpha = Math.cos(alpha) * Math.cos(alpha);
          var cos2SigmaM = cosSigma - 2*sinU1*sinU2/cosSqAlpha;
          var C = f/16*cosSqAlpha*(4+f*(4-3*cosSqAlpha));
          lambdaP = lambda;
          lambda = L + (1-C) * f * Math.sin(alpha) *
          (sigma + C*sinSigma*(cos2SigmaM+C*cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)));

          if (iterLimit==0)
          return NaN; // formula failed to converge

          var uSq = cosSqAlpha * (a*a - b*b) / (b*b);
          var A = 1 + uSq/16384*(4096+uSq*(-768+uSq*(320-175*uSq)));
          var B = uSq/1024 * (256+uSq*(-128+uSq*(74-47*uSq)));
          var deltaSigma = B*sinSigma*(cos2SigmaM+B/4*(cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)-
          B/6*cos2SigmaM*(-3+4*sinSigma*sinSigma)*(-3+4*cos2SigmaM*cos2SigmaM)));
          var s = b*A*(sigma-deltaSigma);
          var d = s.toFixed(3)/1000; // round to 1mm precision
          return d;
          ;





          share|improve this answer

























          • Yes, that's logical. But, my example is very short and at the equator. How do you explain that? With longer routes, up to 150 km in Europe, it is just like that. I can not drive "through" the globe, but I have to drive on the earth's surface, thats a longer way.

            – Suka
            Apr 12 at 23:27











          • Is "sphere" only for longer distances and "PointRes" more for short distances?

            – Suka
            Apr 13 at 0:03











          • Flat projections are generally not suitable for long distances. EPSG:3857 is based on the Earth's equatorial radius of 6378137 meters. ol.sphere uses the Earth's average radius of 6371008.8 meters. So right on the equator EPSG:3857 would be more accurate than ol.sphere. A transverse mercator projection such as UTM would be good if your route closely folowed a meridian. If you need extra precise calculation you need the Vincenty ellipsoid method which uses both the equatorial and polar radii.

            – Mike
            Apr 13 at 10:03











          • Oh wow, what a function! i understand not realy what, but a little bit. I have added a example picture on my question above. Please read to understand what i mean, and than please answer me whether the functions result is point 3 (red).

            – Suka
            Apr 14 at 19:10















          2














          Sphere gives the shortest distance on a spherical planet. What appears to be a straight line on a flat map isn't the shortest distance that an aircraft would fly, especially over long distances such as London to Tokyo



          enter image description here



          distVincenty = function(p1, p2) 
          var ct =
          a: 6378137,
          b: 6356752.3142,
          f: 1/298.257223563
          ;
          var a = ct.a, b = ct.b, f = ct.f;

          var L = (p2.lon - p1.lon) * Math.PI/180;
          var U1 = Math.atan((1-f) * Math.tan(p1.lat*Math.PI/180));
          var U2 = Math.atan((1-f) * Math.tan(p2.lat*Math.PI/180));
          var sinU1 = Math.sin(U1), cosU1 = Math.cos(U1);
          var sinU2 = Math.sin(U2), cosU2 = Math.cos(U2);
          var lambda = L, lambdaP = 2*Math.PI;
          var iterLimit = 20;
          while (Math.abs(lambda-lambdaP) > 1e-12 && --iterLimit>0)
          var sinLambda = Math.sin(lambda), cosLambda = Math.cos(lambda);
          var sinSigma = Math.sqrt((cosU2*sinLambda) * (cosU2*sinLambda) +
          (cosU1*sinU2-sinU1*cosU2*cosLambda) * (cosU1*sinU2-sinU1*cosU2*cosLambda));
          if (sinSigma==0)
          return 0; // co-incident points

          var cosSigma = sinU1*sinU2 + cosU1*cosU2*cosLambda;
          var sigma = Math.atan2(sinSigma, cosSigma);
          var alpha = Math.asin(cosU1 * cosU2 * sinLambda / sinSigma);
          var cosSqAlpha = Math.cos(alpha) * Math.cos(alpha);
          var cos2SigmaM = cosSigma - 2*sinU1*sinU2/cosSqAlpha;
          var C = f/16*cosSqAlpha*(4+f*(4-3*cosSqAlpha));
          lambdaP = lambda;
          lambda = L + (1-C) * f * Math.sin(alpha) *
          (sigma + C*sinSigma*(cos2SigmaM+C*cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)));

          if (iterLimit==0)
          return NaN; // formula failed to converge

          var uSq = cosSqAlpha * (a*a - b*b) / (b*b);
          var A = 1 + uSq/16384*(4096+uSq*(-768+uSq*(320-175*uSq)));
          var B = uSq/1024 * (256+uSq*(-128+uSq*(74-47*uSq)));
          var deltaSigma = B*sinSigma*(cos2SigmaM+B/4*(cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)-
          B/6*cos2SigmaM*(-3+4*sinSigma*sinSigma)*(-3+4*cos2SigmaM*cos2SigmaM)));
          var s = b*A*(sigma-deltaSigma);
          var d = s.toFixed(3)/1000; // round to 1mm precision
          return d;
          ;





          share|improve this answer

























          • Yes, that's logical. But, my example is very short and at the equator. How do you explain that? With longer routes, up to 150 km in Europe, it is just like that. I can not drive "through" the globe, but I have to drive on the earth's surface, thats a longer way.

            – Suka
            Apr 12 at 23:27











          • Is "sphere" only for longer distances and "PointRes" more for short distances?

            – Suka
            Apr 13 at 0:03











          • Flat projections are generally not suitable for long distances. EPSG:3857 is based on the Earth's equatorial radius of 6378137 meters. ol.sphere uses the Earth's average radius of 6371008.8 meters. So right on the equator EPSG:3857 would be more accurate than ol.sphere. A transverse mercator projection such as UTM would be good if your route closely folowed a meridian. If you need extra precise calculation you need the Vincenty ellipsoid method which uses both the equatorial and polar radii.

            – Mike
            Apr 13 at 10:03











          • Oh wow, what a function! i understand not realy what, but a little bit. I have added a example picture on my question above. Please read to understand what i mean, and than please answer me whether the functions result is point 3 (red).

            – Suka
            Apr 14 at 19:10













          2












          2








          2







          Sphere gives the shortest distance on a spherical planet. What appears to be a straight line on a flat map isn't the shortest distance that an aircraft would fly, especially over long distances such as London to Tokyo



          enter image description here



          distVincenty = function(p1, p2) 
          var ct =
          a: 6378137,
          b: 6356752.3142,
          f: 1/298.257223563
          ;
          var a = ct.a, b = ct.b, f = ct.f;

          var L = (p2.lon - p1.lon) * Math.PI/180;
          var U1 = Math.atan((1-f) * Math.tan(p1.lat*Math.PI/180));
          var U2 = Math.atan((1-f) * Math.tan(p2.lat*Math.PI/180));
          var sinU1 = Math.sin(U1), cosU1 = Math.cos(U1);
          var sinU2 = Math.sin(U2), cosU2 = Math.cos(U2);
          var lambda = L, lambdaP = 2*Math.PI;
          var iterLimit = 20;
          while (Math.abs(lambda-lambdaP) > 1e-12 && --iterLimit>0)
          var sinLambda = Math.sin(lambda), cosLambda = Math.cos(lambda);
          var sinSigma = Math.sqrt((cosU2*sinLambda) * (cosU2*sinLambda) +
          (cosU1*sinU2-sinU1*cosU2*cosLambda) * (cosU1*sinU2-sinU1*cosU2*cosLambda));
          if (sinSigma==0)
          return 0; // co-incident points

          var cosSigma = sinU1*sinU2 + cosU1*cosU2*cosLambda;
          var sigma = Math.atan2(sinSigma, cosSigma);
          var alpha = Math.asin(cosU1 * cosU2 * sinLambda / sinSigma);
          var cosSqAlpha = Math.cos(alpha) * Math.cos(alpha);
          var cos2SigmaM = cosSigma - 2*sinU1*sinU2/cosSqAlpha;
          var C = f/16*cosSqAlpha*(4+f*(4-3*cosSqAlpha));
          lambdaP = lambda;
          lambda = L + (1-C) * f * Math.sin(alpha) *
          (sigma + C*sinSigma*(cos2SigmaM+C*cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)));

          if (iterLimit==0)
          return NaN; // formula failed to converge

          var uSq = cosSqAlpha * (a*a - b*b) / (b*b);
          var A = 1 + uSq/16384*(4096+uSq*(-768+uSq*(320-175*uSq)));
          var B = uSq/1024 * (256+uSq*(-128+uSq*(74-47*uSq)));
          var deltaSigma = B*sinSigma*(cos2SigmaM+B/4*(cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)-
          B/6*cos2SigmaM*(-3+4*sinSigma*sinSigma)*(-3+4*cos2SigmaM*cos2SigmaM)));
          var s = b*A*(sigma-deltaSigma);
          var d = s.toFixed(3)/1000; // round to 1mm precision
          return d;
          ;





          share|improve this answer















          Sphere gives the shortest distance on a spherical planet. What appears to be a straight line on a flat map isn't the shortest distance that an aircraft would fly, especially over long distances such as London to Tokyo



          enter image description here



          distVincenty = function(p1, p2) 
          var ct =
          a: 6378137,
          b: 6356752.3142,
          f: 1/298.257223563
          ;
          var a = ct.a, b = ct.b, f = ct.f;

          var L = (p2.lon - p1.lon) * Math.PI/180;
          var U1 = Math.atan((1-f) * Math.tan(p1.lat*Math.PI/180));
          var U2 = Math.atan((1-f) * Math.tan(p2.lat*Math.PI/180));
          var sinU1 = Math.sin(U1), cosU1 = Math.cos(U1);
          var sinU2 = Math.sin(U2), cosU2 = Math.cos(U2);
          var lambda = L, lambdaP = 2*Math.PI;
          var iterLimit = 20;
          while (Math.abs(lambda-lambdaP) > 1e-12 && --iterLimit>0)
          var sinLambda = Math.sin(lambda), cosLambda = Math.cos(lambda);
          var sinSigma = Math.sqrt((cosU2*sinLambda) * (cosU2*sinLambda) +
          (cosU1*sinU2-sinU1*cosU2*cosLambda) * (cosU1*sinU2-sinU1*cosU2*cosLambda));
          if (sinSigma==0)
          return 0; // co-incident points

          var cosSigma = sinU1*sinU2 + cosU1*cosU2*cosLambda;
          var sigma = Math.atan2(sinSigma, cosSigma);
          var alpha = Math.asin(cosU1 * cosU2 * sinLambda / sinSigma);
          var cosSqAlpha = Math.cos(alpha) * Math.cos(alpha);
          var cos2SigmaM = cosSigma - 2*sinU1*sinU2/cosSqAlpha;
          var C = f/16*cosSqAlpha*(4+f*(4-3*cosSqAlpha));
          lambdaP = lambda;
          lambda = L + (1-C) * f * Math.sin(alpha) *
          (sigma + C*sinSigma*(cos2SigmaM+C*cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)));

          if (iterLimit==0)
          return NaN; // formula failed to converge

          var uSq = cosSqAlpha * (a*a - b*b) / (b*b);
          var A = 1 + uSq/16384*(4096+uSq*(-768+uSq*(320-175*uSq)));
          var B = uSq/1024 * (256+uSq*(-128+uSq*(74-47*uSq)));
          var deltaSigma = B*sinSigma*(cos2SigmaM+B/4*(cosSigma*(-1+2*cos2SigmaM*cos2SigmaM)-
          B/6*cos2SigmaM*(-3+4*sinSigma*sinSigma)*(-3+4*cos2SigmaM*cos2SigmaM)));
          var s = b*A*(sigma-deltaSigma);
          var d = s.toFixed(3)/1000; // round to 1mm precision
          return d;
          ;






          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Apr 13 at 10:04

























          answered Apr 12 at 22:43









          MikeMike

          2,575139




          2,575139












          • Yes, that's logical. But, my example is very short and at the equator. How do you explain that? With longer routes, up to 150 km in Europe, it is just like that. I can not drive "through" the globe, but I have to drive on the earth's surface, thats a longer way.

            – Suka
            Apr 12 at 23:27











          • Is "sphere" only for longer distances and "PointRes" more for short distances?

            – Suka
            Apr 13 at 0:03











          • Flat projections are generally not suitable for long distances. EPSG:3857 is based on the Earth's equatorial radius of 6378137 meters. ol.sphere uses the Earth's average radius of 6371008.8 meters. So right on the equator EPSG:3857 would be more accurate than ol.sphere. A transverse mercator projection such as UTM would be good if your route closely folowed a meridian. If you need extra precise calculation you need the Vincenty ellipsoid method which uses both the equatorial and polar radii.

            – Mike
            Apr 13 at 10:03











          • Oh wow, what a function! i understand not realy what, but a little bit. I have added a example picture on my question above. Please read to understand what i mean, and than please answer me whether the functions result is point 3 (red).

            – Suka
            Apr 14 at 19:10

















          • Yes, that's logical. But, my example is very short and at the equator. How do you explain that? With longer routes, up to 150 km in Europe, it is just like that. I can not drive "through" the globe, but I have to drive on the earth's surface, thats a longer way.

            – Suka
            Apr 12 at 23:27











          • Is "sphere" only for longer distances and "PointRes" more for short distances?

            – Suka
            Apr 13 at 0:03











          • Flat projections are generally not suitable for long distances. EPSG:3857 is based on the Earth's equatorial radius of 6378137 meters. ol.sphere uses the Earth's average radius of 6371008.8 meters. So right on the equator EPSG:3857 would be more accurate than ol.sphere. A transverse mercator projection such as UTM would be good if your route closely folowed a meridian. If you need extra precise calculation you need the Vincenty ellipsoid method which uses both the equatorial and polar radii.

            – Mike
            Apr 13 at 10:03











          • Oh wow, what a function! i understand not realy what, but a little bit. I have added a example picture on my question above. Please read to understand what i mean, and than please answer me whether the functions result is point 3 (red).

            – Suka
            Apr 14 at 19:10
















          Yes, that's logical. But, my example is very short and at the equator. How do you explain that? With longer routes, up to 150 km in Europe, it is just like that. I can not drive "through" the globe, but I have to drive on the earth's surface, thats a longer way.

          – Suka
          Apr 12 at 23:27





          Yes, that's logical. But, my example is very short and at the equator. How do you explain that? With longer routes, up to 150 km in Europe, it is just like that. I can not drive "through" the globe, but I have to drive on the earth's surface, thats a longer way.

          – Suka
          Apr 12 at 23:27













          Is "sphere" only for longer distances and "PointRes" more for short distances?

          – Suka
          Apr 13 at 0:03





          Is "sphere" only for longer distances and "PointRes" more for short distances?

          – Suka
          Apr 13 at 0:03













          Flat projections are generally not suitable for long distances. EPSG:3857 is based on the Earth's equatorial radius of 6378137 meters. ol.sphere uses the Earth's average radius of 6371008.8 meters. So right on the equator EPSG:3857 would be more accurate than ol.sphere. A transverse mercator projection such as UTM would be good if your route closely folowed a meridian. If you need extra precise calculation you need the Vincenty ellipsoid method which uses both the equatorial and polar radii.

          – Mike
          Apr 13 at 10:03





          Flat projections are generally not suitable for long distances. EPSG:3857 is based on the Earth's equatorial radius of 6378137 meters. ol.sphere uses the Earth's average radius of 6371008.8 meters. So right on the equator EPSG:3857 would be more accurate than ol.sphere. A transverse mercator projection such as UTM would be good if your route closely folowed a meridian. If you need extra precise calculation you need the Vincenty ellipsoid method which uses both the equatorial and polar radii.

          – Mike
          Apr 13 at 10:03













          Oh wow, what a function! i understand not realy what, but a little bit. I have added a example picture on my question above. Please read to understand what i mean, and than please answer me whether the functions result is point 3 (red).

          – Suka
          Apr 14 at 19:10





          Oh wow, what a function! i understand not realy what, but a little bit. I have added a example picture on my question above. Please read to understand what i mean, and than please answer me whether the functions result is point 3 (red).

          – Suka
          Apr 14 at 19:10

















          draft saved

          draft discarded
















































          Thanks for contributing an answer to Geographic Information Systems Stack Exchange!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid


          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.

          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function ()
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fgis.stackexchange.com%2fquestions%2f318658%2fdifference-between-ol-proj-getpointresolution-and-ol-sphere-getdistance%23new-answer', 'question_page');

          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          រឿង រ៉ូមេអូ និង ហ្ស៊ុយលីយេ សង្ខេបរឿង តួអង្គ បញ្ជីណែនាំ

          Crop image to path created in TikZ? Announcing the arrival of Valued Associate #679: Cesar Manara Planned maintenance scheduled April 17/18, 2019 at 00:00UTC (8:00pm US/Eastern)Crop an inserted image?TikZ pictures does not appear in posterImage behind and beyond crop marks?Tikz picture as large as possible on A4 PageTransparency vs image compression dilemmaHow to crop background from image automatically?Image does not cropTikzexternal capturing crop marks when externalizing pgfplots?How to include image path that contains a dollar signCrop image with left size given

          Romeo and Juliet ContentsCharactersSynopsisSourcesDate and textThemes and motifsCriticism and interpretationLegacyScene by sceneSee alsoNotes and referencesSourcesExternal linksNavigation menu"Consumer Price Index (estimate) 1800–"10.2307/28710160037-3222287101610.1093/res/II.5.31910.2307/45967845967810.2307/2869925286992510.1525/jams.1982.35.3.03a00050"Dada Masilo: South African dancer who breaks the rules"10.1093/res/os-XV.57.1610.2307/28680942868094"Sweet Sorrow: Mann-Korman's Romeo and Juliet Closes Sept. 5 at MN's Ordway"the original10.2307/45957745957710.1017/CCOL0521570476.009"Ram Leela box office collections hit massive Rs 100 crore, pulverises prediction"Archived"Broadway Revival of Romeo and Juliet, Starring Orlando Bloom and Condola Rashad, Will Close Dec. 8"Archived10.1075/jhp.7.1.04hon"Wherefore art thou, Romeo? To make us laugh at Navy Pier"the original10.1093/gmo/9781561592630.article.O006772"Ram-leela Review Roundup: Critics Hail Film as Best Adaptation of Romeo and Juliet"Archived10.2307/31946310047-77293194631"Romeo and Juliet get Twitter treatment""Juliet's Nurse by Lois Leveen""Romeo and Juliet: Orlando Bloom's Broadway Debut Released in Theaters for Valentine's Day"Archived"Romeo and Juliet Has No Balcony"10.1093/gmo/9781561592630.article.O00778110.2307/2867423286742310.1076/enst.82.2.115.959510.1080/00138380601042675"A plague o' both your houses: error in GCSE exam paper forces apology""Juliet of the Five O'Clock Shadow, and Other Wonders"10.2307/33912430027-4321339124310.2307/28487440038-7134284874410.2307/29123140149-661129123144728341M"Weekender Guide: Shakespeare on The Drive""balcony"UK public library membership"romeo"UK public library membership10.1017/CCOL9780521844291"Post-Zionist Critique on Israel and the Palestinians Part III: Popular Culture"10.2307/25379071533-86140377-919X2537907"Capulets and Montagues: UK exam board admit mixing names up in Romeo and Juliet paper"Istoria Novellamente Ritrovata di Due Nobili Amanti2027/mdp.390150822329610820-750X"GCSE exam error: Board accidentally rewrites Shakespeare"10.2307/29176390149-66112917639"Exam board apologises after error in English GCSE paper which confused characters in Shakespeare's Romeo and Juliet""From Mariotto and Ganozza to Romeo and Guilietta: Metamorphoses of a Renaissance Tale"10.2307/37323537323510.2307/2867455286745510.2307/28678912867891"10 Questions for Taylor Swift"10.2307/28680922868092"Haymarket Theatre""The Zeffirelli Way: Revealing Talk by Florentine Director""Michael Smuin: 1938-2007 / Prolific dance director had showy career"The Life and Art of Edwin BoothRomeo and JulietRomeo and JulietRomeo and JulietRomeo and JulietEasy Read Romeo and JulietRomeo and Julieteeecb12003684p(data)4099369-3n8211610759dbe00d-a9e2-41a3-b2c1-977dd692899302814385X313670221313670221