-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Add 'gdal vector clip' and 'gdal vector pipeline read ... ! clip ... ! write ...' #11681
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
Conversation
@sgillies @jratike80 Thoughts ? Cf https://gdal--11681.org.readthedocs.build/en/11681/programs/gdal_vector_clip.html for the options. I've tried to be as much consistent as possible with the raster clip (https://gdal--11681.org.readthedocs.build/en/11681/programs/gdal_raster_clip.html) although the later only currently accepts raster 'like' datasets, whereas for this vector clip I accept both raster and vector. For raster, accepting a vector like could imply doing more than just rectangular clipping, and potentially something similar to gdalwarp -cutline |
I would add a couple of words somewhere and explain that clip often yields mixed geometry types. And add
Idea is OK, but polygon layers tend to be dirty with gaps and overlaps between individual polygon features. The clipped result may be surprising. Users should be warned.
Maybe also similar to gdal_rasterize -i for clipping holes. They would be nice options to have in the future. For the raster --like, maybe mention that bounds which are taken from the template image are rectangular, and bounds include nodata. |
Thanks @jratike80 for the feedback
Some words added (as well as improving the code). Currently we don't have any equivalent of -nlt with "gdal" utility. We probably need some "geom_op" step to "gdal vector pipeline" to do such thing, and other operations like buffering, densifying, etc. Or a distinct step per geometry operation... (although I'm a bit afraid of the doc and code overhead of having one step per type of geometry operation)
That's what we do already with ogr2ogr. Warning added |
What do you think about accepting |
Is there a strong reason for offering that alternative ? (we should try to avoid alternate syntaxes as much as possible) |
Unlike |
I'm not super convinced we need that, unless we have several concordant opinions that it is needed. |
That's fine, hence my question. I'm just scarred from recently writing some code for GEOS, where bounding boxes are constructed as xmin,xmax,ymin,ymax. |
No description provided.