Problem

The definition of geometries for stages is inconsistent. Sometimes we take in wkt (which also transparently takes in GeoJSON but this isn't widely advertised), on some stages it is calledpolygon, on others geometry, and sometimes we support an ogr definition (like in readers.ept and readers.copc). It is all a bit messy and arbitrary.

OGR Definition

The ogr definition is the most powerful approach, and it offloads the work of dealing with geometries to OGR. The following example shows how to select a geometry and do some reprojection to create a buffered geometry:

    "ogr": {
        "datasource": "../desired.geojson",
        "sql": "SELECT ST_Transform(ST_Union(ST_Buffer(ST_Transform(geometry, 3857), 300)), 4326) as geometry  from desired where HUC8 in ('02050304')",
        "options": {
            "dialect": "SQLITE"
        }
    }

Desire

It should be possible to pass in an ogr definition to PDAL stages for any option that would otherwise take in a geometry in WKT or GeeJSON. In almost all instances, this is what you want – figuring out how to manually transform a geometry into WKT or GeoJSON, maybe through some CLI operation, is fraught and annoying. Our current behavior also makes that activity happen outside of the context of a PDAL pipeline operation. It is much easier to point to some data, define a selection with OGR SQL, manipulate and transform it as shown above, and let PDAL consume the geometry for its operations.

Proposal

• Centralize the implementation of the ogr option
• Allow any wkt or polygon or geometry option to also take an ogr definition for geometries in addition to simple WKT or GeoJSON
• Enhance the ogr definition with any missing capabilities