Provide mechanism in liblwgeom to iterate over all points in a geometry

[dbaston]

Currently, this capability is only available at the database level through ST_DumpPoints. A set of iterator functions was developed for the WIP fix for #2996, but could be applied independent of that ticket.

[strk]

+1

[robe]

+1 go for it.

[dbaston]

Only question then is what to call it….I had gone with LWITERATOR initially, but that's not terribly descriptive. LWPOINTITERATOR is hard to read. I was sticking with all-caps & no underscores to try and match the style of existing types. Any preferences on this?

[strk]

I've no problems with LWPOINTITERATOR. Would it need to be dimension-aware ? Ie: LWPOINT2DITERATOR, LWPOINT3DMITERATOR, …

[dbaston]

We only need one version of the iterator, but we could have multiple versions of these two functions:

int lwiterator_next(LWITERATOR* s, POINT4D* p);
int lwiterator_peek(LWITERATOR* s, POINT4D* p);

Or we could (as I've done so far) provide only 4D points, and let the user convert them as they wish.

[strk]

is mutating iteration supported ?

[dbaston]

No, I wasn't envisioning that.

[strk]

I've been feeling the need for that doing github.com/strk/fineltra (similar to what st_transform does)

[dbaston]

It looks like we could supply an updated POINT4D* to ptarray_set_point4d, which can pull out the correct components from it (as appropriate for the point type). The question then is how to provide the updated POINT4D* ?

What are your thoughts on something like this?

lwpointiterator_modify_next(LWPOINTITERATOR* s, POINT4D*);

I guess a client would use this in conjunction with the peek and has_next functions to mutate the geometry.

[strk]

lwpointiterator_modify_next(LWPOINTITERATOR* s, POINT4D*) sounds good to me.

[dbaston]

(In [14400]) add LWPOINTITERATOR (closes #3366)