Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[CHANGE REQUEST] Allow MultiPolygon types in the /operators/region endpoint #559

Open
jordibeen opened this issue Dec 2, 2024 · 2 comments
Milestone

Comments

@jordibeen
Copy link
Contributor

API Version

1.5.0

Summary

The /operator/regions endpoint only supports returning a GeoJSON representation of a Polygon. Ideally, it should allow for MultiPolygon types too, as these are also part of the official GeoJSON spec.

Expected Behavior

We expect the /operator/regions endpoint (wiki) to work with a GeoJSON representation of a MultiPolygon without any issues.

Current Behavior

The current behavior is that the serviceArea field in the /operators/region endpoint only works for a singular Polygon, not a MultiPolygon.

Possible Solution

Modifying the existing endpoint to allow for MultiPolygon types to be returned too.

Steps to Reproduce

  1. Try to return a GeoJSON representation of a MultiPolygon in the /operator/regions endpoint.
  2. The endpoint won't process the MultiPolygon correctly.

Context (Environment)

We've started returning MultiPolygons to our TOMP integration, but the specification does not allow for it. This limitation is causing us to implement custom workarounds to handle MultiPolygon types.

@jordibeen jordibeen changed the title [BUG] or [CHANGE REQUEST] [CHANGE REQUEST] Allow MultiPolygon types in the /operators/region endpoint Dec 2, 2024
@jurgenvo
Copy link

jurgenvo commented Dec 6, 2024

This would indeed be a very welcome improvement! I think it goes broader than just the /operators/region endpoint though. It would be great if this can also be supported in the conditionReturnArea for instance. Ideally, all properties that currently use a specific geometry type, should be changed to the geojsonGeometry type. This is already done for the stationInformation.stationArea.

@edwinvandenbelt
Copy link
Collaborator

Hello Jordi & Jurgen, your request is partly honoured in v2.0. We're going to be OGC Feature compliant, that means in our case we're going to deliver geoJSON as default. The bad news is that we're going to drop the 'operator information' module... and thereby also the regions. We're going to rely no external specified data (in any format), so the regions itself could be specified in the GBFS's regions or zones (https://github.com/MobilityData/gbfs/blob/v3.0/gbfs.md#system_regionsjson or https://github.com/MobilityData/gbfs/blob/v3.0/gbfs.md#geofencing_zonesjson).

In v2.0, the conditions will remain and the conditionReturnArea will contain a list of geojsonGeometry.

@edwinvandenbelt edwinvandenbelt added this to the 2.0 milestone Dec 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants