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)

linestring_point.diff (15.6 KB ) - added by atrofast 14 years ago.
Exposes the methods listed
linestring_point-v2.diff (15.8 KB ) - added by atrofast 14 years ago.
With updated names

Download all attachments as: .zip

Change History (9)

by atrofast, 14 years ago

Attachment: linestring_point.diff added

Exposes the methods listed

comment:1 by mloskot, 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 pramsey, 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 mloskot, 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 strk, 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 atrofast, 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!

by atrofast, 14 years ago

Attachment: linestring_point-v2.diff added

With updated names

comment:6 by atrofast, 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 warmerdam, 14 years ago

Resolution: fixed
Status: newclosed

I have applied the second patch in trunk as there were no further issues raised (r2992).

Note: See TracTickets for help on using tickets.