Centroids and Extract Nodes in gdal vector

[MayureshPadalkar]

Feature description

Hi, do you have plans to add the following in gdal vector?

1. Centroids (points) from polygons.
2. Add points (extract nodes) at vertices along a polyline.

Additional context

No response

[rouault]

1. Centroids (points) from polygons.

you can do it with (SQLite Spatialite) SQL with ST_Centroid: https://www.gaia-gis.it/gaia-sins/spatialite-sql-5.1.0.html

Perhaps a "gdal vector centroid" command could make sense indeed

2. Add points (extract nodes) at vertices along a polyline.

Can you be more specific ?

[jratike80]

1. Use the SQLite SQL dialect https://gdal.org/en/stable/user/sql_sqlite_dialect.html and you can utilize all SpatiaLite functions https://www.gaia-gis.it/gaia-sins/spatialite-sql-5.1.0.html
   Use either ST_Centroid or perhaps ST_PointOnSurface that is placing the point always inside the polygon.

2. ST_DissolvePoints will create a MultiPoint that has a Point member for each vertex.

[PostholerCom]

I know keeping libgdal at a reasonable size is important. But, I wonder how much of an impact it would be baking spatialite in by default?

Personally, if you're working with vector, I couldn't imagine having a build without spatialite. It doesn't have all of the functions of PostGIS, but it has many that PostGIS doesn't have.

With spatialite you have the ability to do routing right in the GDAL pipeline and anything else you can think of.

GDAL CLI features like set-geom-type --multi go away, as you can use the --sql "select st_multi(geom)" instead. Adding spatialite would prevent re-inventing the wheel for CLI features that may be forth-coming.

Imagine a CLI feature like this with spatialite, creating custom CLI features:

gdal vector alias --alias-name pointOnSurface --alias "st_transform(st_pointOnSurface(geom), 4326)" -o myAliases.json
...
gdal vector pointOnSurface -i polys.shp -o points.gpkg --aliases myAliases.json

Ok, ok, too much caffiene....

[rouault]

I know keeping libgdal at a reasonable size is important. But, I wonder how much of an impact it would be baking spatialite in by default?

Most typical GDAL builds link to libspatialite. Was your suggestion to embed its code within the GDAL tree ? If so, even if that was deemed to be desirable, we couldn't for license reasons since libspatialite is MPL/LGPL which has stronger requirements than MIT

[dbaston]

Perhaps a "gdal vector centroid" command could make sense indeed

Thoughts on gdal vector centroid vs gdal vector as-point --method [centroid/interior] ?

[rouault]

gdal vector as-point --method [centroid/interior] ?

maybe that one. Could open the door to maybe a 3rd method "explode" / "extract" to create one feature per vertex of the input geometry (I guess that's what was meant per 'Add points (extract nodes) at vertices along a polyline.') ?

[dbaston]

Could open the door to maybe a 3rd method "explode" / "extract" to create one feature per vertex of the input geometry (I guess that's what was meant per 'Add points (extract nodes) at vertices along a polyline.') ?

I think there's a use for dimension reduction functions (polygon -> points/lines, line ->points), but I'm not sure I'd include them in the same command as centroid/interior point, which are more like centrality measures.

[rouault]

I think there's a use for dimension reduction functions (polygon -> points/lines, line ->points), but I'm not sure I'd include them in the same command as centroid/interior point, which are more like centrality measures.

I don't have a strong opinion on that. Restricting as-point to centroid/interior is fine to me

[jratike80]

gdal vector as-point --method [centroid/interior]

Does "interior" mean PointOnSurface/InteriorPoint https://lin-ear-th-inking.blogspot.com/2019/02/betterfaster-stpointonsurface-for.htm?

[PostholerCom]

The following seem redundant and re-inventing the wheel:

gdal vector buffer
gdal vector make-point
gdal vector make-valid
etc..

Adding:
gdal vector as-point

continues that redundancy.

Imagine if gdal vector had access to an internal lib like CGAL/SFCGAL/PostGIS or Spatialite (licensing issues as Even pointed out). With that, you could have access to all vector features:

gdal vector modify
--how=centroid
--how=buffer
--how=pointonsurface
--how=makevalid
--how=optimalalphashape
--how=dump
--how=union
etc...

If you're running gdal against PG/PostGIS or Spatialite you already have access to it all via 'gdal vector sql'

[jratike80]

What is the advantage? For example "buffer" and "make-valid" use and require GEOS (LGPL licensed) https://gdal.org/en/stable/programs/gdal_vector_buffer.html
In which way the latter would be less redundant?

gdal vector buffer
gdal vector modify --how=buffer

[rouault]

The following seem redundant and re-inventing the wheel:

There's definitely truth in that such dedicated commands are a bit of wheel reinvention. Clearly you can do almost what you can dream of using SQLite SQL + Spatialite. I believe dedicated utilities for common tasks may have value because they are easier to use. Like you don't need to know the name of the geometry column, or the layer to select from, or remembering to do tricks like "SELECT ST_foo(geom) as geom, * FROM bla", in that order, so you do get the modified geometry column and not the original one.