Feature #2477
closedAPI: Presentation view improvements
Description
With the feature #2450 there is a new endpoint specifically designed for presentation sites.
Since there will be need for improvement and feedback, feel free to add items to the list.
Change name(We can do this, when it moves away from the proposal state)- remove references (edition, bib, ext ref) from relations and make a special case for them ✅
add parameter to get not only one "hop" of linked events, actors or places but as many as there are (get linked entities recursive)(Good idea, but need to figure it out elsewhere first)- Remodel
geometriesto a valid GeoJSON ✅
- add the
viewClassproperty to the response ✅ - add the
IIIFManifestproperty to the entries of thefilesarray (if available) ✅ - add value types (ideally with
valueandunit) totypesarray ✅ - RelatedEntityModel: instead of
relationTypesModelthe response contains a property namedrelationTypes-> should be renamed in the OpenAPI definition ✅
Updated by Bernhard Koschiček-Krombholz 9 months ago
- Assignee deleted (
Bernhard Koschiček-Krombholz)
Updated by Bernhard Koschiček-Krombholz 9 months ago
- Status changed from Acknowledged to Assigned
- Assignee set to Bernhard Koschiček-Krombholz
Updated by Katharina Wünsche 8 months ago
Thanks Bernhard, the endpoint works really well! To fully replace the call to the /entity/ endpoint in the frontend, we'd need the following adjustments to /entity_presentation_view/ :
- add the
viewClassproperty to the response - add the
IIIFManifestproperty to the entries of thefilesarray (if available) - add value types (ideally with
valueandunit) totypesarray
- PresentationViewModel: the
typeproperty in thegeometriesobject is currently typed as string - would it be possible to make this an enum compatible with the GeoJSON types (Point, Polygon,...)? - RelatedEntityModel: add proper typing to the
geometriesproperty (according to the OpenAPI definition, it's currently an empty object) - RelatedEntityModel: instead of
relationTypesModelthe response contains a property namedrelationTypes-> should be renamed in the OpenAPI definition
Updated by Bernhard Koschiček-Krombholz 8 months ago
- Description updated (diff)
- add the
viewClassproperty to the response- add the
IIIFManifestproperty to the entries of thefilesarray (if available)- add value types (ideally with
valueandunit) totypesarray
These very already included, they were just marshalled away. My bad.
- RelatedEntityModel: instead of
relationTypesModelthe response contains a property namedrelationTypes-> should be renamed in the OpenAPI definition
Fixed.
- PresentationViewModel: the
typeproperty in thegeometriesobject is currently typed as string - would it be possible to make this an enum compatible with the GeoJSON types (Point, Polygon,...)?- RelatedEntityModel: add proper typing to the
geometriesproperty (according to the OpenAPI definition, it's currently an empty object)
I noticed, that I just dump the geometries, but that is not correct. I should include a standardized GeoJSON, so I have to remodel it.
Updated by Bernhard Koschiček-Krombholz 8 months ago
- Description updated (diff)
I corrected the geometries property in openapi as well as in the real output. It should be an absolute valid GeoJSON now.
Updated by Bernhard Koschiček-Krombholz 8 months ago
- Description updated (diff)
- Status changed from Assigned to Closed
Setting this on closed. If any other issues arise, please set it on assigned again and write your problems. Thank you!
Updated by Katharina Wünsche 8 months ago
- Status changed from Closed to Assigned
Thanks a lot for the fixes! Just a (hopefully) small issue in the openapi definition: The geometries property in the RelatedEntityModel seems to be lacking the reference to Geometries ("$ref":"#/components/schemas/Geometries"). It is currently typed as an empty object, but the actual response correctly contains a GeoJSON geometry.
Updated by Bernhard Koschiček-Krombholz 8 months ago
- Status changed from Assigned to Closed
fixed issues
Updated by Bernhard Koschiček-Krombholz 8 months ago
- Status changed from Closed to In Progress
There are no locations for Actors.
And there might be a problem, if an entity is connected to a location, each entity connected to that location will be added to that entity result, which is not what we want. So location only needs the connections to the administrative unit types.
Also look specifically into the geometry IDs, they maybe point to the location ID, not the place ID.
Updated by Bernhard Koschiček-Krombholz 8 months ago
- Related to Feature #2527: API: 0.4.8 added
Updated by Bernhard Koschiček-Krombholz 7 months ago
- Status changed from In Progress to Closed
Fixed issue. Added placeId to geometries.