We need to think about how compatible geojson with isoxml geometries and consider how we would integrate this representation better into our specification so that software that is already supporting RFC 7946 would benefit more from us relying on the same format.
For example one approach could be instead of including boundary into field like this:
|
boundary: |
|
$ref: '#/components/schemas/Geometry' |
|
description: A GeoJSON Polygon or MultiPolygon boundary. |
We could instead put it into separate subresource like:
/masterdata/.../field/<id>/boundary
In this case we can use application/geo+json media type, because entire body then would be geojson.
This would have negative consequences though, because implementers would need to deal with potentially somewhat more complexity from this split.
We need to think about how compatible geojson with isoxml geometries and consider how we would integrate this representation better into our specification so that software that is already supporting
RFC 7946would benefit more from us relying on the same format.For example one approach could be instead of including boundary into field like this:
masterdata-sync-working-group/openapi.yaml
Lines 578 to 580 in c1c9f4b
We could instead put it into separate subresource like:
In this case we can use
application/geo+jsonmedia type, because entire body then would be geojson.This would have negative consequences though, because implementers would need to deal with potentially somewhat more complexity from this split.