Ticket #314 (closed enhancement: fixed)

Opened 3 years ago

Last modified 3 years ago

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: svn-trunk
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

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

Change History

Changed 3 years ago by atrofast

Exposes the methods listed

Changed 3 years ago by mloskot

  • milestone 3.3.0 deleted

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.

Changed 3 years ago by pramsey

  • milestone set to 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.

Changed 3 years ago by mloskot

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.

Changed 3 years ago by strk

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 :)

Changed 3 years ago by atrofast

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!

Changed 3 years ago by atrofast

With updated names

Changed 3 years ago by atrofast

I've attached a new patch with the updated names, if you have any questions, please let me know. Thanks!

Changed 3 years ago by warmerdam

  • status changed from new to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.