Problem/Motivation

The routing actions proposed in #3592668 expect an edge table and a vertex table to already exist in the database. Building such a network is a separate task that usually requires external tools (for example osm2pgrouting) and command line access to the database server, which many site builders do not have.

OpenStreetMap is the most common source for road networks, and the Overpass API module already provides a way to query OSM data from Drupal. Combining the two would let site builders create and refresh a routing network for an area directly from an ECA model.

This should not be part of eca_geofield_pgrouting itself: networks built with other tools or from existing road data must keep working without a dependency on overpass_api.

Steps to reproduce

  1. Enable eca_geofield_pgrouting on a database with PostGIS and pgRouting.
  2. Try to create a routing network for an area from within Drupal.
  3. No way to do this is available; the network has to be built outside Drupal.

Proposed resolution

Add a new submodule, eca_geofield_pgrouting_osm, that depends on eca_geofield_pgrouting and overpass_api, and provides one action, "Geofield: build routing network from OpenStreetMap", with the following configuration:

  • Area: a geofield holding a polygon (entity via ECA token), used as the Overpass query area.
  • The highway tag values to include (for example all roads, or only roads usable by cars).
  • Edge table and vertex table names to write to.
  • Whether to replace the existing contents of the tables or to add to them.

Behaviour:

  • The OSM ways inside the area are fetched through the overpass_api service (using its configured endpoint), including their node lists, geometries and tags.
  • Ways are split at every node shared with another way, so each edge runs between two intersections or end points. OSM node IDs are used as vertex IDs for source and target.
  • The cost of each edge is its length in metres. One-way roads (oneway=yes, oneway=-1, and roundabouts) get a negative reverse_cost in the blocked direction.
  • The edge and vertex tables are created with the structure expected by eca_geofield_pgrouting if they do not exist. Table names are validated and quoted as identifiers, never inserted into SQL as given.
  • All writes happen in a single transaction, so a failed Overpass request or import leaves the existing network untouched. Failures are logged.

The action runs synchronously, so it is meant for moderately sized areas; large areas are limited by the Overpass endpoint and PHP execution time. This is documented, together with the ODbL attribution requirement for networks built from OpenStreetMap data.

Travel time based costs (from maxspeed or per road class defaults) are out of scope for this issue and can be handled in a follow-up.

Remaining tasks

  • Create the eca_geofield_pgrouting_osm submodule and the action.
  • Write kernel tests with a mocked overpass_api service returning a fixture response, covering way splitting, one-way handling, replace and add modes, and a failed request.
  • Check that a network built by the action works with the shortest path action from #3592668.
  • Document the submodule in the README.

User interface changes

A new action, "Geofield: build routing network from OpenStreetMap", becomes available in the ECA modeller when the submodule is enabled.

API changes

A new submodule with a new action plugin. No changes to the main module or to eca_geofield_pgrouting.

Data model changes

No Drupal entity or field changes. The action creates and writes the edge and vertex tables named in its configuration, outside of Drupal's entity storage.

Comments

orkutmuratyilmaz created an issue.