New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Viable approach to ST_LineSubString? #16
Comments
I pointed you here because the PostGIS function with that name (most likely) uses this. It should be fairly trivial to incorporate that into lwgeom, which interfaces this library. |
Cool! I'll test this out soon. |
Dang. Nice. That was quick!! Somebody else can create an apply-like function where I wrote a dumb loop, but this works pretty good as far as I can tell.
|
For the record, then I'll leave this, I did implement a wrapper function that works against a whole table of LINESTRING features using the lwgeom function. It is at the bottom of the gist linked above. |
I worked up a decent approach (in that it seems quite fast working with >70k river features) to the same geometric function as ST_LineSubString over here: https://gist.github.com/dblodgett-usgs/cf87392c02d73f1b7d16153d2b66a8f3 It is written to orchestrate over an sf LINESTRING dataframe though. Some work would be required to boil it down to the basic function.
@edzer you told me to raise this here, but since it doesn't use lwgeom, (it's dplyr / sf) is it really appropriate?
This function is pretty GIS - swiss army knife, but it would be good to have a ST_LineSubString function some place... fine to move on if this doesn't fit, but wanted to offer it up if it seems applicable.
The text was updated successfully, but these errors were encountered: