Opened 14 years ago
Closed 14 years ago
#314 closed enhancement (fixed)
Expose getX, getY, getPointN, getStartPoint, getEndPoint, isClosed, getLength and getNumPoints
Reported by: | atrofast | Owned by: | pramsey |
---|---|---|---|
Priority: | major | Milestone: | 3.3.0 |
Component: | C API | Version: | main |
Severity: | Feature Request | Keywords: | |
Cc: |
Description
I've attached a patch that exposes these C++ class methods as CAPI functions:
LineString::getPointN -> GEOSGetPointN
LineString::getStartPoint -> GEOSGetStartPoint
LineString::getEndPoint -> GEOSGetEndPoint
LineString::isClosed -> GEOSisClosed
LineString::getLength -> GEOSGetLength
LineString::getNumPoints -> GEOSGetNumPoints
Point::getX -> GEOSGetX
Point::getY -> GEOSGetY
Additionally I wrote a small test case for the new functions.
Attachments (2)
Change History (9)
by , 14 years ago
Attachment: | linestring_point.diff added |
---|
comment:1 by , 14 years ago
Milestone: | 3.3.0 |
---|
Alex, thanks for the patch. The patch technically looks good to me.
However, I have removed the milestone as it is likely unspecified when it will be applied. I suppose Paul or Sandro will have to decide about it becasue it's not a trivial change. I do not maintain C API myself. Let's see.
comment:2 by , 14 years ago
Milestone: | → 3.3.0 |
---|
Is it possible you'll be adding other accessors? I've set the milestone to 3.3, since we promised not to change the API during minor revisions.
comment:3 by , 14 years ago
Paul,
Sure, I can do technical steps: patch, test and commit. I just need you or Sandro to make decision what goes to C API and when.
comment:4 by , 14 years ago
My 2c:
I see the new functions are called something like: GEOSGetPointN But they take a GEOSGeometry.
My concern is that since we already expose a GEOSCoordSequence, and in future could also expose a GEOSCoordinate, assigning those symbols to implicitly work on Geometry will represent a problem.
How about renaming them to be explicit about taking Geometry ? We're not in C++ land here, no overloads possible :)
comment:5 by , 14 years ago
strk:
I don't think that's a problem, so should the new list be:
- GEOSGeomGetPointN
- GEOSGeomGetX
- GEOSGeomGetY
- GEOSGeomGetStartPoint
- GEOSGeomGetEndPoint
- GEOSGeomGetNumPoints
- GEOSisClosed (isSimple and isEmpty are defined as such)
Thanks for the feedback, very much appreciated!
comment:6 by , 14 years ago
I've attached a new patch with the updated names, if you have any questions, please let me know. Thanks!
comment:7 by , 14 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
I have applied the second patch in trunk as there were no further issues raised (r2992).
Exposes the methods listed