Add illustrations to Spatial Fields page

[kgjenkins]

We should provide some guidance about what is an appropriate level of detail for the locn_geometry field.

The POLYGON and MULTIPOLYGON syntax that can now be used with the locn_geometry field opens the door to adding very detailed geometries that could result in very large geoblacklight.json files -- potentially 100MB instead of the typical 1-2KB size. In addition to requiring more storage space, complex geometries could also have negative impacts on Solr search performance.

What is a reasonable level of detail to allow?

[rmseifried]

@eliotjordan mentioned some documentation for another project that could be relevant?

[eliotjordan]

I can't find any documentation from IIIF about that at the moment. Maybe we just discussed the issue and didn't put it into the spec. A disclaimer like: "the geometry should be the minimum size to express the boundary of the underlying data". Emphasize that it should be kept as small as possible.

[kgjenkins]

When writing examples for the documentation, I was having trouble coming up with an example where a bounding box or two wouldn't suffice. Ended up using Bermuda Triangle: "POLYGON((-80 25, -65 18, -64 33, -80 25))".

It seems like the main advantage of the new field is being able to have multiple bounding boxes -- either to deal with antimeridian splits (like Alaska), or possibly cases like départements of France including areas in the Indian Ocean and the Caribbean.

How about something like:

locn_geometry values should be kept as short as possible, in this order of preference:

1. ENVELOPE syntax for a single bounding box
2. MULTIPOLYGON syntax for multiple bounding boxes (antimeridian, overseas territory examples)
3. POLYGON syntax for areas where a bounding box would include too much extraneous area (Bermuda Triangle example)
4. MULTIPOLYGON syntax for multiple non-rectangular areas

[karenmajewicz]

At this point, I don't know if I think bounding boxes are "preferred." Being able to add complex polygons is kind of a new era for GeoBlacklight. Wouldn't we want to encourage people to create them?

When we say smallest and shortest, do we mean the least amount of vertices needed? Maybe we can indicate something along the lines of:
"For best performance, we recommend the maximum number of coordinate points to not exceed [50?] points. Users may need to optimize their geometry values by generalizing the resource's shape for display purposes."

[kgjenkins]

Sorry, "order of preference" was poor wording. That order is really just "simplest to more complex", both in terms of the syntax as well as the effort it would take to create the values.

We won't really know about any performance issues unless someone does some testing. Maybe there are case studies online somewhere.

I'm planning to write up some details with illustrations, and when I do that, I'll try to address some of the polygon complexity tradeoffs.

[rmseifried]

@kgjenkins - revisiting this issue with fresh eyes, I think it could be cool to put additional information (including details with illustrations, as you suggest) at the bottom of the page, below the table (https://opengeometadata.org/docs/ogm-aardvark/geometry).

[kgjenkins]

Add the illustrations to this page:
https://opengeometadata.org/spatial-fields/