Problem/Motivation

Spatial Tools only has 6.x and 7.x releases. There is no branch that runs on any modern Drupal version, so sites that relied on the 7.x shapefile and KML processing have no upgrade path.

The 7.x-1.x branch provides:

  • Spatial File: an API for spatial file processing and a Geofield widget
  • Spatial Shapefile: a plugin for ESRI shapefiles
  • Spatial KML: a plugin for KML files

The 7.x branch depends on the ogr2ogr module.

This was requested earlier in #2924446, which never got a branch or code.

Proposed resolution

Create a new 2.0.x branch with core_version_requirement: ^11 || ^12 and port the 7.x-1.x functionality:

  • Turn the Spatial File API into a service plus a plugin type for file parsers, so Shapefile and KML become parser plugins in their submodules.
  • Port the Geofield upload widget to a FieldWidget plugin for the Geofield module.
  • Decide how GDAL/OGR is reached: keep the ogr2ogr module dependency if it has a compatible release, or call the ogr2ogr binary directly through Symfony Process with a configurable path.
  • Move settings to config with a schema, and declare dependencies in composer.json.
  • Add kernel tests for the Shapefile and KML parsers with small fixture files, and enable the drupal.org GitLab CI template (phpcs, phpstan, phpunit) against both 11.x and 12.x.

The 6.x-only submodules (Spatial Import, Spatial Widget, Spatial Table) depend on Feeds, Table Wizard, Geo and OpenLayers 6.x integrations and are out of scope here.

Remaining tasks

  • Agree on the branch name and scope with the maintainers.
  • Create the 2.0.x branch.
  • Port Spatial File, Spatial Shapefile and Spatial KML.
  • Port the Geofield widget.
  • Add tests and GitLab CI.
  • Review and tag a first alpha release.

User interface changes

The Geofield upload widget becomes available on Drupal 11 and 12 field forms.

API changes

The procedural 7.x API (for example spatial_file_get_wkt_features()) is replaced by a service and a parser plugin type.

Data model changes

None beyond new config entities/schema. No upgrade path from 7.x data is planned in this issue.

Issue fork spatial-2924446

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

About issue forks

Comments

SocialNicheGuru created an issue. See original summary.

agentjay’s picture

agentjay commented

How much would it cost to port this to Drupal 8?
I might be interested in paying for Development time...

socialnicheguru’s picture

socialnicheguru commented
Title: Drupal 8 version? » Drupal 9 version?
orkutmuratyilmaz’s picture

orkutmuratyilmaz
Primary language Turkish
Location İzmir
commented
Title: Drupal 9 version? » Port Spatial Tools to Drupal 11 and Drupal 12
Issue summary: View changes

orkutmuratyilmaz opened merge request !1

orkutmuratyilmaz’s picture

orkutmuratyilmaz
Primary language Turkish
Location İzmir
commented

I opened MR !1 with a port to Drupal 11.2+ and Drupal 12. It needs review.

The approach in short:

  • The Drupal 7 code and the per-format submodules are gone. Format support now comes from GDAL drivers: zipped shapefiles, KML, GeoJSON, GeoPackage and any other vector format GDAL reads.
  • Reading goes through a new SpatialReader plugin type. The only backend for now runs the GDAL command line tools (ogr2ogr, ogrinfo, GDAL 3.6+) and streams features without loading the whole file into memory.
  • A backend that talks to libgdal through PHP FFI can later be added as one new plugin class, either in this project or in a separate module, without changing the public API. An abstract kernel test (SpatialReaderContractTestBase) defines the contract every backend has to pass.
  • The new spatial_geofield submodule replaces spatial_file. It provides a "Spatial file upload" widget for Geofield that previews the file's content right after upload and stores one value per feature or a single GEOMETRYCOLLECTION.

Target branch: the MR currently targets master, but it is meant for a new 2.0.x branch. Could a maintainer create 2.0.x from 7.x-1.x so the MR can be retargeted?

To try it:

  1. Install the GDAL command line tools on the web server (on Debian/Ubuntu: apt-get install gdal-bin; on DDEV: webimage_extra_packages: [gdal-bin]).
  2. Enable spatial and check the status report, or the settings at /admin/config/system/spatial.
  3. Enable spatial_geofield, add a Geofield field, set its widget to "Spatial file upload" and upload a file. The fixtures in tests/fixtures work for this.

Tested: 63 tests (unit, kernel and functional) pass locally on Drupal 11.4.10, PHP 8.4, PostgreSQL 18 and GDAL 3.13.2. phpcs and phpstan (level 6) report no errors. GitLab CI is configured to install GDAL so the backend tests run there too.

Not verified yet: Drupal 12 (Geofield does not declare ^12 yet), a real GDAL 3.6 installation, MySQL/SQLite, and the JavaScript upload path of the widget.

Feedback on the plugin API and the reader contract is especially welcome, since a future FFI backend will depend on them.

orkutmuratyilmaz’s picture

orkutmuratyilmaz
Primary language Turkish
Location İzmir
commented

Pipeline fixes are pushed: a PHP 8.3 serialization issue (readonly properties in a form, the widget and the CLI plugin) and a cspell dictionary.

On databases: the module does no spatial work in the database. GDAL reads the files and Geofield stores WKT, so the database is only regular Drupal storage. I ran the tests locally on PostgreSQL (PostGIS is installed but not used), and GitLab CI runs them on MySQL. I have not tried SQLite or MariaDB yet. If anyone needs those covered, I am happy to look into it.

orkutmuratyilmaz’s picture

orkutmuratyilmaz
Primary language Turkish
Location İzmir
commented

The pipeline now passes with warnings. I pushed fixes for a PHP 8.3 serialization issue (readonly properties in a form, the widget and the CLI plugin) and added a cspell dictionary, and CI now also runs the tests against the next major of Drupal core automatically. All jobs for current Drupal 11 pass. The only warning comes from the PHPUnit job for Drupal 12, which is allowed to fail; see below.

On databases: the module does no spatial work in the database. GDAL reads the files and Geofield stores WKT, so the database is only regular Drupal storage. GitLab CI runs the tests on MySQL, and I ran them locally on PostgreSQL (PostGIS is installed but not used). I have not tried SQLite or MariaDB yet; if anyone needs those covered, I am happy to look into it.

On Drupal 12: all tests of the main spatial module pass. The 15 errors are all in the spatial_geofield tests and come from Geofield itself, which is not Drupal 12 compatible yet (annotation-only discovery in GeofieldBackendManager, and a GeoConstraintValidator::validate() signature that newer Symfony rejects). They should pass once Geofield supports Drupal 12.

orkutmuratyilmaz’s picture

orkutmuratyilmaz
Primary language Turkish
Location İzmir
commented
Status: Active » Needs review

I'm updating the status of the issue as "Needs review" now.