Useful linestring getLength method added to ol.proj

New method parameters enable the generation of useful LineString length results from
geometries in any projection. Calculation method can be specified, with
a suitable default being selected. Projection must always be specified (a breaking change).
New tests have been added for ol.Sphere (RhumbLineDistance) and ol.geom.LineString (getLength method). The Measure example is corrected.
I anticipate a new PR for fixing the getArea method of ol.geom.LinearRing and ol.geom.Polygon. This method also needs a mandatory projection parameter and should have an optional calculation method - Cartesian or Spherical.
When there is API access to the GreatCircle generator in ol.geom.flat.geodesic then a new example plotting the Rhumb Line and Great Circle between New York and Tokyo and showing their lengths, would make sense.

you need to rebase this on the latest master. 'examples_src' for example is now called 'examples'

I will need step by step instructions on how to do such a rebase.
On 22 Apr 2015 09:31, "Peter Robins"<EMAIL_ADDRESS>wrote:

you need to rebase this on the latest master. 'examples_src' for example
is now called 'examples'
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#issuecomment-95075185.

git pull --rebase upstream master should do the trick, assuming that upstream points to your git://github.com/openlayers/ol3.git remote.

Thanks.  I will give that a go tonight.
On 22 Apr 2015 10:51, "Andreas Hocevar"<EMAIL_ADDRESS>wrote:

git pull --rebase upstream master should do the trick, assuming that
upstream points to your git://github.com/openlayers/ol3.git remote.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#issuecomment-95104249.

The line.getLength() method is marked as stable.  So this change would require a new major release.
The current getLength method returns the Cartesian 2D length of a linestring.  This is consistent with other libraries that deal with "unreferenced" geometries (e.g. GEOS, JTS, PostGIS's ST_Length).
I'd suggest a new method or optional arguments.  A new method would allow people to more easily build profiles of the library without the extra sphere and ellipsoid code.  An alternative to adding dependencies and more code to the geometry classes would be to add functions to ol.sphere or ol.ellipsoid.  I think some discussion is warranted before we decide what is the most appropriate.

I share your concerns.
I had earlier proposed a new method that always returned an answer in
metres whatever the projection.
I am not sure that you want ol.sphere and ol.ellipsoid having a method with
an ol.geom.LineString parameter. Rather, methods therein would have to take
a simple array of coordinates.
On 22 Apr 2015 16:02, "Tim Schaub"<EMAIL_ADDRESS>wrote:

The line.getLength() method
http://openlayers.org/en/master/apidoc/ol.geom.LineString.html#getLength
is marked as stable. So this change would require a new major release.
The current getLength method returns the Cartesian 2D length of a
linestring. This is consistent with other libraries that deal with
"unreferenced" geometries (e.g. GEOS
http://geos.osgeo.org/doxygen/classgeos_1_1geom_1_1LineString.html#a72998f51df9ab2fdee425345ead6068f,
JTS
http://www.vividsolutions.com/jts/javadoc/com/vividsolutions/jts/geom/LineString.html#getLength(),
PostGIS's ST_Length http://postgis.net/docs/ST_Length.html).
I'd suggest a new method or optional arguments. A new method would allow
people to more easily build profiles of the library without the extra
sphere and ellipsoid code. An alternative to adding dependencies and more
code to the geometry classes would be to add functions to ol.sphere or
ol.ellipsoid. I think some discussion is warranted before we decide what
is the most appropriate.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#issuecomment-95223315.

My motivation in all this is to avoid pitfalls for users such as that reported in
https://github.com/openlayers/ol3/issues/3533
The existing ol3 measure example at
http://openlayers.org/en/v3.4.0/examples/measure.html
is IMHO misleading. The significant change in results (displayed with the same units) when enabling its misnamed 'geodesic' option is due to the latitude of the EPSG:3857 points, not the change from a cartesian to great-circle calculation method.
Folk coming from say Google Maps will be used to using
https://developers.google.com/maps/documentation/javascript/reference#spherical
with 4326 coords only.
There is no getLength method on a GMaps Polyline
https://developers.google.com/maps/documentation/javascript/reference#Polyline
Perhaps the ol.geom.LineString.getLength method (and polygon/linearring getArea) should be deprecated for now and removed from the API at a future date once alternatives returning useful answers are available. I suggest that for now, the documentation of the existing getLength and getArea methods are updated with a 4326/3857 health warning and the user pointed to the more useful calculation methods in ol.Sphere and ol.Ellipsoid.
Some debate is required as to where such a getLength method as I have proposed would best fit in the existing structure of OL3 - ol.proj perhaps ? (perhaps without a Vincenty method which requires ol.ellipsoid).
Are there any plans for the geodesic rendering of geometries, as per the geodesic option for a polyline/polygon on GMaps? On 3857, the straight lines currently rendered for geometries are of course Rhumb lines. A geodesic rendering is virtually essential for plotting aircraft routes of significant length.
Please could you let me know which, if any, of the bits of the work in my PR should be persued now. I suggest:

The rhumbLineDistance method in ol.Sphere

New 'health warnings' for the ol.geom getLength and getArea methods with a steer to ol.Sphere and ol.Ellipsoid

Fixing of the Measure Example.

I have reworked this change thus - I guess the PR really needs a revised title or else migrating to a new PR with a new title.
A getLength method is added to ol.proj for computing the length of a line string.
The new method gives a result in metres for the global EPSG:4326 and
EPSG:3857 projections, a result in projection units for non-global projections
and a result in pixels for projections with units of Pixels.
Cartesian, Haversine and Rhumb Line length calculation methods are offered.
A projection must be specified (I don't think a default of EPSG:3857 is appropriate).
A new Rhumb Line distance method is added to ol.Sphere.
New tests for the new ol.proj.getLength method and ol.Sphere.rhumbLineDistance method.
Several comments enhanced. A warning comment is added to the ol.geom.LineString.getLength
documentation.
The Measure example is updated to use the new ol.proj.getLength method and so give a linestring length in metres at any latitude. The example's area calulation is now always done on the sphere, again to give the same results at all latitudes.
The only new coupling is that ol.proj now 'requires' ol.Sphere.WGS84.
ol.proj already used ol.Sphere.NORMAL but that is not suited for length calculations on
EPSG:4326 and EPSG:3857. It may be appropriate for ol.proj to drop the use of ol.Sphere.NORMAL
and use ol.Sphere.WGS84 throughout.
I am not quite sure why ol3 has ol.Sphere.NORMAL which uses the authalic (equal area) Earth Radius of the North American 1927 datum (Clarke 1866 ellipsoid).

I have omitted Vincenty as a calculation method to save coupling ol.proj to ol.Ellipsoid. If folk know enough GIS to think they need Vincenty for the calculation of WGS84 ellipsoidal lengths then they should also be able to write code to use it. Also, ol.Ellipsoid is not in the API yet.

Changing the radius in ol.Sphere.NORMAL to be the same as that in ol.Sphere.WGS84 causes just one ol.proj test to fail, that for meters per unit for EPSG:4326.

ol.proj ol.proj.Projection.prototype.getMetersPerUnit() returns value in meters:
Error: expected<PHONE_NUMBER>9327358 to sort of equal<PHONE_NUMBER>8468118

I actually think that the meters per unit for EPSG:4326 might better be defined in terms of the Earth radius derived from the international standard for a Nautical Mile - http://en.wikipedia.org/wiki/Nautical_mile

A bit more feedback on this would be good. Is there a way of re-triggering Travis without doing a new commit ?
Is it worth noting, in epsg3857projection.js, as a comment for developers, that the 'units' of EPSG:3857 are only whole metres on the equator ?

Is there a way of re-triggering Travis without doing a new commit ?

You can for example amend your last commit and force-push to the remote branch:
git commit --amend --no-edit
git push --force origin projection

Good discussion here, but closing due to lack of activity. @bill-chadwick if you want to continue working on this, please create new tickets that suggest one improvement at a time to make this whole enchilada easier to digest.

I am having another go at this in a simpler fashion though adding a
'constantScale' attribute to a projection. Ol.proj.getLength will use
phythagoras for constantScale and pixel projections, else Haversine.
ConstantScale is only nominal but would be used for UTM and BNG etc where
scale changes by less than 0.05% over the projection's extent (and a custom
getPointResolution function returning an unchanged resolution is used.)
It would make sense to me to do getArea at the same time - it would return
an answer in square metres for 3857 and 4326 projections using the
ol.sphere methods.
I would also like then to rework the measure example.
Would you prefer that as one PR or three?
Bill
On 8 Oct 2015 15:33, "Andreas Hocevar"<EMAIL_ADDRESS>wrote:

Closed #3609 https://github.com/openlayers/ol3/pull/3609.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#event-430378328.

The constantScale attribute of a projection can replace the custom
getPointResolution method
On Wed, Oct 21, 2015 at 4:18 PM, Bill Chadwick <
<EMAIL_ADDRESS>wrote:

I am having another go at this in a simpler fashion though adding a
'constantScale' attribute to a projection. Ol.proj.getLength will use
phythagoras for constantScale and pixel projections, else Haversine.
ConstantScale is only nominal but would be used for UTM and BNG etc where
scale changes by less than 0.05% over the projection's extent (and a custom
getPointResolution function returning an unchanged resolution is used.)
It would make sense to me to do getArea at the same time - it would return
an answer in square metres for 3857 and 4326 projections using the
ol.sphere methods.
I would also like then to rework the measure example.
Would you prefer that as one PR or three?
Bill
On 8 Oct 2015 15:33, "Andreas Hocevar"<EMAIL_ADDRESS>wrote:

Closed #3609 https://github.com/openlayers/ol3/pull/3609.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#event-430378328.

This sounds like a decent plan. It's always good when things can be simplified. I'd call the proposed constantScale option constantPointResolution instead. And I like the idea of removing the getPointResolution option from olx.ProjectionOptions. You can create a single pull request (or reuse this one) for the changes to getLength, getArea and the measure example.

Thanks Andreas,
Your message and my new post to the ol3 google group crossed in the ether.
I will change constantScale to constantPointResolution
Observe that constantPointResolution will be automatically set true for
projections with units of Pixels, which are I think, not properly handled
by getPointResolution currently
Bill.
On Wed, Oct 21, 2015 at 9:37 PM, Andreas Hocevar<EMAIL_ADDRESS>wrote:

Reopened #3609 https://github.com/openlayers/ol3/pull/3609.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#event-441966707.

I think that projections with units of degrees should always have
constantPointResolution. Rather than special case those in
getPointResolution the new getLength should make a special case for
projections with units  of degrees.
Bill
On 21 Oct 2015 22:02, "Bill Chadwick"<EMAIL_ADDRESS>wrote:

Thanks Andreas,
Your message and my new post to the ol3 google group crossed in the ether.
I will change constantScale to constantPointResolution
Observe that constantPointResolution will be automatically set true for
projections with units of Pixels, which are I think, not properly handled
by getPointResolution currently
Bill.
On Wed, Oct 21, 2015 at 9:37 PM, Andreas Hocevar<EMAIL_ADDRESS>
wrote:

Reopened #3609 https://github.com/openlayers/ol3/pull/3609.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#event-441966707.

Rather than special case those in getPointResolution the new getLength should make a special case for projections with units  of degrees.

If projections with degrees as units have constantPointResolution set to true as well, then the special case is the same as for pixel units and can be handled in getLength. However, make sure that getPointResolution returns the correct value also for constantPointResolution projections in general.

Andreas,
Out of curiosity, do you know where the value of earth radius in
ol.sphere.normal had come from? Its a bit different to the nornally used
value for the WGS84 authalic radius.
Bill
Rather than special case those in getPointResolution the new getLength
should make a special case for projections with units of degrees.
If projections with degrees as units have constantPointResolution set to
true as well, then the special case is the same as for pixel units and can
be handled in getLength. However, make sure that getPointResolution returns
the correct value also for constantPointResolution projections in general.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#issuecomment-150139433.

Out of curiosity, do you know where the value of earth radius in ol.sphere.normal had come from? Its a bit different to the nornally used value for the WGS84 authalic radius.

It comes from the Normal Sphere as defined in the MetaCRS projects. I think the reason why that is used for the Haversine distance calculcations instead of the WGS84 Sphere is because the latter uses the radius at the equator, and we want a good approximation anywhere on the planet, instead of an accurate calculation for the equator only.

Thats my point. I think we should be using the WGS84 authalic (not
equatorial) radius which is just 10 metres more than the value in
ol.sphere.normal.
Bill
On 23 Oct 2015 13:10, "Andreas Hocevar"<EMAIL_ADDRESS>wrote:

Out of curiosity, do you know where the value of earth radius in
ol.sphere.normal had come from? Its a bit different to the nornally used
value for the WGS84 authalic radius.
It comes from the Normal Sphere as defined in the MetaCRS projects. I
think the reason why that is used for the Haversine distance calculcations
instead of the WGS84 Sphere is because the latter uses the radius at the
equator, and we want a good approximation anywhere on the planet, instead
of an accurate calculation for the equator only.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#issuecomment-150555985.

I will check the value used by some other web apis. It would be good to use
the same value.
On 23 Oct 2015 13:28, "Bill Chadwick"<EMAIL_ADDRESS>wrote:

Thats my point. I think we should be using the WGS84 authalic (not
equatorial) radius which is just 10 metres more than the value in
ol.sphere.normal.
Bill
On 23 Oct 2015 13:10, "Andreas Hocevar"<EMAIL_ADDRESS>wrote:

Out of curiosity, do you know where the value of earth radius in
ol.sphere.normal had come from? Its a bit different to the nornally used
value for the WGS84 authalic radius.
It comes from the Normal Sphere as defined in the MetaCRS projects. I
think the reason why that is used for the Haversine distance calculcations
instead of the WGS84 Sphere is because the latter uses the radius at the
equator, and we want a good approximation anywhere on the planet, instead
of an accurate calculation for the equator only.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#issuecomment-150555985.

Leaflet looks to be using 6378137, which is the WGS84 equatorial radius,
for its Haversine length calculation.
Google do the same, defaulting to 6378137 see here
https://developers.google.com/maps/documentation/javascript/reference#spherical
I am not sure that 6378137 is the best choice.
https://en.wikipedia.org/wiki/Great-circle_distance suggests using a mean
WGS84 radius of
6371008. The WGS84 authalic radius is 6371007.
*Chris Veness at *http://www.movable-type.co.uk/scripts/latlong.html
defaults to 6371000
The current value in ol.sphere.NORMAL is 6370997
I have added an optional radius parameter to the new ol.proj.getLength and
getArea methods, defaulting to ol.sphere.NORMAL if a radius is not provided.
Bill
On Fri, Oct 23, 2015 at 1:31 PM, Bill Chadwick <
<EMAIL_ADDRESS>wrote:

I will check the value used by some other web apis. It would be good to
use the same value.
On 23 Oct 2015 13:28, "Bill Chadwick"<EMAIL_ADDRESS>wrote:

Thats my point. I think we should be using the WGS84 authalic (not
equatorial) radius which is just 10 metres more than the value in
ol.sphere.normal.
Bill
On 23 Oct 2015 13:10, "Andreas Hocevar"<EMAIL_ADDRESS>wrote:

Out of curiosity, do you know where the value of earth radius in
ol.sphere.normal had come from? Its a bit different to the nornally used
value for the WGS84 authalic radius.
It comes from the Normal Sphere as defined in the MetaCRS projects. I
think the reason why that is used for the Haversine distance calculcations
instead of the WGS84 Sphere is because the latter uses the radius at the
equator, and we want a good approximation anywhere on the planet, instead
of an accurate calculation for the equator only.
—
Reply to this email directly or view it on GitHub
https://github.com/openlayers/ol3/pull/3609#issuecomment-150555985.

We now have getLength() in the ol/sphere module.  If there are improvements or fixes that need to be made, they should be made there.
Thanks.


parse lock/unlock tables

Fixes #32.

Coverage increased (+0.02%) to 88.435% when pulling c225f6d6a36b223006ebca1c7a1d1e0d634596ad on dt:lock into da747e0c62c4e145ebd7484cf69f92c0dd192305 on xwb1989:master.

Sorry for the delay...
These changes look good, but would you send this pull request to the upstream project https://github.com/vitessio/vitess/tree/master/go/vt/sqlparser   Once that's done I'll pull them down to this fork.

Thanks, yeah, I'll send these upstream