Opened 14 years ago
Closed 14 years ago
#3472 closed task (fixed)
Merge get_Length (OGRLineString::get_Length()) and Length (ogr.i)
Reported by: | Ari Jolma | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | 1.8.0 |
Component: | OGR_SF | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: |
Description
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.
Change History (1)
comment:1 by , 14 years ago
Milestone: | → 1.8.0 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Implemented in r20546