Recipe #139: Geolocate Canvas Fragment to a Point #51
Comments
|
What is a client supposed to do with this information? I don't think there's enough description of the intent of the annotation for this to be implemented. |
|
I received similar feedback from the Cookbook team, but ultimately didn't go deep into the |
|
And how would mapping software render a region of a IIIF canvas? |
|
It isn't rendering the Canvas and never intends to, or at least this demo doesn't. It is rendering the coordinate annotations on the Canvas, and hopefully a label or description to go with it. You don't hand Leaflet an Image and expect that turns into a dot with a pop up. You hand it GeoJSON coordinates coupled with metadata (like the URL) about or from the Image, most often in Think about the map warping scenarios. Once you have the coordinates used to warp, the image of the map you are warping to fit in the MapUI could just as well be an image of Bart Simpson. The MapUI needs the coordinates, everything else is supplementary or meaningless. In IIIF, you build around the resource, and the viewers respect that and at their core ensure those resources are rendered, but sometimes supplementary information is dropped or processed differently between viewers (think about Mirador vs. UV). In MapUI's, you build around the coordinates and the viewers respect that and at their core ensure those coordinates are rendered, but sometimes supplementary information is dropped or processed differently (think about Leaflet vs Google Maps). http://geo.rerum.io/geolocate/leaflet-view.html |
|
Here it is with a Manifest as an example. |
|
In a more robust and complex example, those pop-ups could contain the Image or Image fragment from the Canvas, but I didn't want to complicate things too much and I don't have the demo that gets down to the Canvas level (in these examples every dot you see connects to a Manifest). Even getting the label to show wasn't free, that took custom script. No open source mapping tool will render (IIIF) resources outright. I had to grab the label and stick it into the GeoJSON.properties to get this mapping system to show it with the coordinate rendering, and that's what everyone has to do in these open source systems. This is why we presuppose by the time you are doing this, you already have script doing things for you to connect coordinates, resources, and metadata to a Map UI. What this shows is how to connect the coordinates these open mapping systems use to IIIF resources. The IIIF viewer that renders geoannotations as geographic shapes on a world map does not yet exist, and neither does the MapUI that consumes IIIF resources for their geographic assertions to draw as shapes on a world map. The pipelines to achieve these do exist, but it is going to take custom script no matter what. This is representative of the state of Mapping on the Web right now. |
|
What if we change the last line in the Use Case to something like "You want to create geocoordinates that clients can use for representing the Canvas/Fragment in world map based user interfaces, such as Leaflet or Google Maps." |
|
Changes requested in the TRC call:
|
|
We have worked on projects in which we have rendered IIIF resources on maps, using coordinate information. e.g. https://makingscience.royalsociety.org/s/rs/keywords/fst01405225 where the points on the map render a IIIF image associated with that lat/long via an annotation (in this case not using a standard geojson-ld data model), so the basic use case seems clear enough. |
|
I think the aforementioned changes make sense and help clear up some issues I otherwise had. We have also work on geo-mapping photographs in a research pilot and had to do a lot of metadata cleanup to make the geo location in the item metadata uniform enough to be used across large collections. This would help with that by creating a standard convention for doing it in the IIIF Manifest as Annotations. |
|
I think the recipe does need to go into a bit more of the "why". I also think there is a need to be explicit about what an IIIF client is expected to do (or, rather, not expected to do) and possibly mention of what a geo-aware environment might do. It should also be clearer in the notes that this use case is about a point so even though GeoJSON can describe "nearly anything" and "more than just a point", other recipes will cover things other than a point. I agree with the comments from the TRC call too. This is on a good track but I vote 👎 because I think there are enough changes that they should come round to TRC again (hopefully next call). This recipe will set the approach for future maps related recipes. |
|
I definitely understand the concerns here. In my mind, this construction is likely to be used like Collection. There is not a direct expectation to render the content of the Manifest or Canvas, but to provide a geolocation. As a Collection has a list of URIs, probably labels to display as a navigational/discovery aid the expectation of the consumer is that this data may make the resource available in a map interface, which is an increasingly common navigation component and filtering visualization. I would be more 😕 or 👎 if this was an argument over a point of the standard, but this doesn't change or impose anything but suggests a clear convention in a cookbook recipe. |
|
One additional point I raised in the call was that since GeoJSON can become quite verbose and sensibly affect the size of the manifest, and it is used for a very specific purpose that is out of the scope of the IIIF specs, it would be best to use a reference to an external GeoJSON document rather than embedding the JSON data in the manifest. Whether that is convenient or possible, I agree with other commenters that it is worth giving the recipe a second round of review. |
|
I agree with @zimeon that it is important to clarify what a IIIF client is expected to do or not do with the manifest; I understand what goal is, but this clarification is important for those who have not participated in or watched the recorded discussion. Since this change is not on the list proposed in the TRC call, I vote 👎 . |
|
I think the map example would be much clearer than annotating text. The example links given by @thehabes above no longer work. It would be good to fix them if possible. Finally - the Presentation API is to enable the presentation of the data in user interfaces by IIIF clients, based around image and other content. I do not believe it is in scope for the cookbook to discuss what non-IIIF clients should do, as that would open the door for arbitrary transformations and processing: an infinitely large door. So I would continue to be 👎 on use cases that do not clarify what a IIIF client could be expected to do with the data while rendering the Canvas it is associated with, and if all IIIF clients should ignore the data, then (IMO) it should not be a recipe. |
Issue 51 (Recipe #139: Geolocate Canvas Fragment to a Point)+1: 7 [awead cjnishioka cubap glenrobson hadro ksclarke mikeapp] Result: 7 / 17 = 0.41Issue is rejected |
Links
Background and Summary
This is the first recipe to come from the Maps community group and it is looking to set a precedent for using GeoJSON-LD within an annotation to link a word on an image to the Geographic place France. Although linking IIIF resources to geographic places has always been possible in IIIF it hasn't been part of the IIIF specifications so a recipe is a good way to encourage interoperability between different providers.
Voting and changes
We welcome comments on the recipe and as well as voting +1, confused face or -1 feel free to add comments to this issue. If this issue is approved then the author will take account of the comments before we merge the branch in to the master cookbook branch.
If the recipe is rejected by the TRC then we will make the changes requested and resubmit it to a future TRC meeting. If you feel that your comments are substantial enough that the recipe should be looked at again by the TRC after the changes have been made please vote -1 (thumbs down).
Changes to the recipe will only be made after the TRC voting process has concluded.
Note the recipe links to a number of related recipes that are yet to be written and these currently show in square brackets in the Related Recipe section.
The text was updated successfully, but these errors were encountered: