Merge get_Length (OGRLineString::get_Length()) and Length (ogr.i)

[Ari Jolma]

There is now Length in swig bindings that is similar to get_Length of LineString. A unified solution should be found.

see also: ​http://lists.osgeo.org/pipermail/gdal-dev/2010-February/023577.html and the thread

hm, I see my last reply with some additional thoughts went just to Frank:

Yes, I think it would be a good thing to keep the APIs as APIs and a single code base. In this case exposing Length to the API rises some thoughts. There is now get_Length method in OGRLineString, i.e., not for all geometry classes. OGRLinearString inherits the method. In C API there is only OGRGeometry, which is reflected in swig as only one geometry class.

The C API function would be

double CPL_DLL OGR_G_Length ( OGRGeometryH );

Do we return an error for points for example? Length should be also defined (according to OGC) for MultiCurves. Thus, it seems to me that we may need to stab also the C++ part - at least the code in C API is not just a binding.

...

Does "The length of this Curve in its associated spatial reference." (OGC SF specification) really mean that computations are made without any consideration to the projection or lack of it? I believe there are some projections where 2D euclidean distance does not make any sense because of the distortion - however, I'm not a cartographer. I'm not geodesist either, but "linear degrees" sounds like it would be different close to the pole than close to the equator.

[Even Rouault]

Implemented in r20546