orkutmuratyilmaz and I have started a conversation at https://www.drupal.org/project/overpass_api/issues/3618910 considering the merits of using the module that he maintains (overpass_api) as the API connection portion of this module.

This would require a refactor of this module (which admittedly, needs some modernization) to work on top of `overpass_api` but given that the data shape is largely the same, would not affect the data once in Drupal much.

He has proposed using Feeds to create entities from Overpass data, whereas this module ships with its own custom entities.

He has also proposed saving queries as config entities, which is very similar to what this module already does.

Using this issue as a discussion space because most of the changes will probably happen in this module to accommodate the structure of `overpass_api`

Comments

tbcs created an issue.

orkutmuratyilmaz’s picture

orkutmuratyilmaz
Primary language Turkish
Location İzmir
commented

@tbcs, #3614002: Add overpass_api_feeds submodule: Allow creating Feeds sources directly from Query Builder (overpass_api_ui) to import OSM data is fixed now. Thanks for everything:)

tbcs’s picture

tbcs commented

After overpass_api 1.0.0-rc1, two decisions for openstreetmap 2.0.x:

No Feeds submodule in openstreetmap. overpass_api_feeds now ships the fetcher, the Overpass API JSON parser and the OSM tag source. The parser already streams large responses and fails the fetch when Overpass returns a remark. Rather than add a second parser, the 2.0.x README will document overpass_api_feeds with the OSM node processor. Sync sources remain the supported way to keep osm_node records current, because a Feeds import bypasses the synchronizer (tag mappers, revisions, orphan handling).

Geometry stays in openstreetmap, and follows OsmGeometry. openstreetmap's sync engine still converts elements to WKT itself. Interpreting OSM data is openstreetmap's side of the split agreed in #3618910, and openstreetmap should not depend on a Feeds submodule to do it. That means two implementations: OsmGeometry in overpass_api_feeds and GeometryBuilder in openstreetmap. To keep an element's shape the same whichever way it was imported, GeometryBuilder follows OsmGeometry's rules at 1.0.0-rc1 exactly: the linear keys, the area=yes and area=no overrides, ring assembly and holes, and the fallbacks. Its tests port every OsmGeometryTest case.

@orkutmuratyilmaz, could those rules be treated as stable from 1.0.0, with any change to them noted here or in a linked openstreetmap issue, so both modules move together?

This comment was drafted by an LLM before it was reviewed by me.

orkutmuratyilmaz’s picture

orkutmuratyilmaz
Primary language Turkish
Location İzmir
commented

@tbcs, yes: the OsmGeometry rules are stable from 1.0.0, and any change will be noted here or in a linked openstreetmap issue.

One question before 1.0.0: OsmGeometry has no Feeds code, it only lives in overpass_api_feeds. If we move it to overpass_api (or a small Feeds-free submodule), openstreetmap could call it directly and skip the second implementation. That bends the split in #3618910: Expose Surface for use with OpenStreetmap Module et al. a little, so I'm fine either way. Which do you prefer?