RFC: Don't register a separate media type #129
Comments
|
Meeting 2024-05-27: This is a good point. Whether a separate media type is helpful or not depends on the use case. A separate media type helps in a content negotiation scenario where an API can provide GeoJSON (without JSON-FG extension), JSON-FG (with or without the GeoJSON compatibility mode). In the case of a weblink with the "type" attribute, a GeoJSON media type would be more helpful for a GeoJSON-aware software (which does not know JSON-FG). Since we cannot do both at the same time, the question which is which is the more important use case. This would be simpler, if the GeoJSON media type would support parameters to express extensions, but this is not the case. Additional input is welcome. |
|
If servers support JSON FG and GeoJSON, what would be a reason to not deliver JSON FG by default so that content negotiation would be required? |
|
Meeting 2024-08-19: We are leaning towards not registering a new media type. Clients can use to "conformsTo" member to determine that the content is JSON-FG. However, this would require that we also allow to include non-WGS84 coordinates in "geometry" to conform to OGC API Features Part 2 when the GeoJSON geometry is requested in a non-WGS84 CRS. We need to find a way that does not make the split between "geometry" and "place" even more complex/confusing. We should create a table that lists all the different cases and see, if we can provide guidance what to create when. Maybe this can be accommodated using additional API building blocks. Maybe we can use the "profile" query parameter, because all the variations are valid for the GeoJSON media type. |
- Share same media type with FG-JSON - NOTE: There is an on-going discussion for FG-JSON to potentially share media type with GeoJSON, so this is a first step in that potential direction. See opengeospatial/ogc-feat-geo-json#129 - New `geometry` parameter to distinguish FG-JSON from DGGS-FG-JSON instead of media type - Declare examples to conform to FG-JSON - Use `dggsPlace` instead of `place` for quantized geometry NOTE: The reason we choose this instead of defining new feature type is because it really is the referencing by coordinates which is replaced by referencing by DGGRS+parent-zoneId+sub-zone indices. Any feature type defined in FG-JSON or extensions is thus automatically supported by DGGS-FG-JSON as long as it uses a `coordinates` array. - geometry=quantized selects DGGS-FG-JSON (requirement for DGGS-FG-(UB)JSON) - Recommendations for GeoJSON and FG-JSON: - geometry=zone-centroid for selecting rasterized zone centroid Point geometry - geometry=zone-region for selecting rasterized zone region (Multi)Polygon or Polyhedron - geometry=vectorized for selecting (non-quantized) vectorized feature geometries - default is to return native representation
|
I think that we can and should use the
"rfc7946" should be the default since this is the current behavior, if "application/geo+json" is requested. Existing APIs may also continue to support the current draft media types for backwards compatibility. We should add a discussion about this in the clause on media types. In addition, JSON-FG should formally define the profiles and the values for the HTTP query parameter |
|
Meeting 2024-09-30: @cportele will implement this in the current pull request. |
JSON FG is meant to be an extension to GeoJSON, a primary goal seems to be that it's a drop-in replacement with added functionality.
The standard is mostly written in a way that a GeoJSON client can easily read JSON FG.
Unfortunately, this is not quite consistent when it comes to the planned new media type (and .jsonfg file extension).
Existing clients will have issues to identify GeoJSON if it's advertised as JSON FG.
The intended media type
application/fg+jsonis not compatible in any way with theapplication/geo+jsonhaving in mind that many implementations just check equality of media type strings.I'd like to propose to not register a separate media type for JSON FG and also remove the
.jsonfgfile extension.Instead as media type
application/geo+jsonorapplication/jsonshall be used and.jsonor.geojsonshould be used as file extensions.This would greatly improve the compatibility with existing clients.
For example, all existing STAC clients I've checked of would not support reading the GeoJSON part of JSON FG due to the new media type. That will likely be the same in other ecosystems.
The text was updated successfully, but these errors were encountered: