Proposal: gdal vector geom_op

[rouault]

to extend our set of tools for the new "gdal" (https://gdal.org/en/latest/programs/index.html#gdal-application), there are a number of operations that are supported by ogr2ogr and aren't ported yet

I'm considering a "geom_op" subcommand of "gdal vector", that could also be used as a stage of "gdal vector pipeline". geom_op itself would just be the frontend for several different subsubcommands

gdal vector geom_op set_type
       [--layer-type-only | --geom-only]
       [--multi | --single] [--linear]
       [--xy | --xyz | --xym | --xyzm] 
      <INPUT> <OUTPUT>
      [any|point|linestring|polygon|multipoint|multilinestring|multipolygon|geometrycollection|compoundcurve|curvepolygon|multicurve|multisurface|polyhedralsurface|tin] 
     
gdal vector geom_op segmentize  <INPUT> <OUTPUT> <max_dist>
gdal vector geom_op simplify [--preserve-topo]   <INPUT> <OUTPUT> <tolerance>
gdal vector geom_op buffer
       [--endcap-style=round|flat|square] [--join-style=round|mitre|bevel]
       [--quadrant-segments=<num>] [--single-sided|--no-single-sided]
       <INPUT> <OUTPUT> <dist>
gdal vector geom_op make_valid   <INPUT> <OUTPUT>

gdal vector geom_op intersection --with=<WKT_or_geojson>   <INPUT> <OUTPUT>
gdal vector geom_op union --with=<WKT_or_geojson>   <INPUT> <OUTPUT>
gdal vector geom_op difference --with=<WKT_or_geojson>   <INPUT> <OUTPUT>
gdal vector geom_op sym_difference --with=<WKT_or_geojson>   <INPUT> <OUTPUT>
gdal vector geom_op boundary   <INPUT> <OUTPUT>

gdal vector geom_op distance --with=<WKT_or_geojson> --into=<field_name>   <INPUT> <OUTPUT>
gdal vector geom_op area [--geodesic] --into=<field_name>   <INPUT> <OUTPUT>
gdal vector geom_op length [--geodesic] --into=<field_name>   <INPUT> <OUTPUT>

gdal vector geom_op swap_xy   <INPUT> <OUTPUT>

All above would support a [--fields=...] to restrict the operation to be applied to one or several geometry fields if there are multiple ones (others would be let unmodifiied)

Does that look good ?
I was wondering about the use of underscore: do we want geomop, geom_op, geom-op ? (knowing that we use dash in option names like --input-format, etc.)

One totally different alternative would be to go through SQL, using Spatialite functions, but that's perhaps less obvious to use (although we'll definitely need a gdal vector pipeline read ... | sql [--dialect=<name>] <statement> | write .... for advanced use cases) . The advantage with the above solution is that it can be more easily documented and can benefit from the auto-completion logic

CC @dbaston @sgillies @jratike80 @elpaso

[jratike80]

I would read geomop as geo mop and it would fit fine for makevalid but maybe not for some other operations. So rather geom_op of geom-op, I think.

I like the "geom_op" syntax for the most needed operations, but is is clear what they are, and which operations will be available only with SQL? The geom_ops would probably work similarly for all datasources and that would help with documenting them. For example geometries can be made valid now with Spatialite by using SQL functions MakeValid/ST_MakeValid and GeosMakeValid, but the GEOS option lacks the linework/structure options which are supported in PostGIS https://postgis.net/docs/[ST_MakeValid](https://postgis.net/docs/ST_MakeValid.html).html.

[rouault]

I like the "geom_op" syntax for the most needed operations, but is is clear what they are

they will have to be documented in our gdal.org doc of course. They correspond to OGR_G_xxxxx() functions and for most of them map to GEOS operations.

but the GEOS option lacks the linework/structure options which are supported in PostGIS

we do have a METHOD=LINEWORK/STRUCTURE and KEEP_COLLAPSED=YES/NO as options of OGRGeometry::MakeValid(). That can be added as switches to "gdal vector geom_op make_valid"

[elpaso]

LGTM

I prefer geom-op for easier typing (on an Italian keybord at least no shift is required).

The SQL alternative looks too complicated to me, probably mostly useful for experienced users.

[dbaston]

Maybe gdal vector transform since we are talking about applying a transformation that replaces the input geometry? And gdal vector calc (or something) for the operations that calculate a derived field. Though I don't especially like calc as it sets a false parallel with gdal raster calc. Just thinking out load here.

[rouault]

Maybe gdal vector transform since we are talking about applying a transformation

transform might potentially be confused with ST_Transform() which is "gdal vector reproject"
One could argue that reprojection is a geometry operation and should be handled under this framework. One advantage though of having "gdal vector reproject" is the similarity with "gdal raster reproject"

that replaces the input geometry?

distance/area/length sub operations wouldn't, but they might belong to something else, or users just have to use Spatialite SQL.

For completness I did look at fiona map but I'm not convinced by the Snuggs syntax which is I believe something totally custom, in-between this proposal and full SQL.