How to indicate that an SDR layer should not be in EarthWorks

[drh-stanford]

From Slack:

we are going to see more files like this (in SDR but not in EarthWorks), such as the aerial photo rasters that are components of index maps. I don't think we want thousands of aerial tiles indexed in EW. I mentioned this here: #387

so yeah, we are going to have to have a systematic way to identify these kinds of things.

---

Would the aerials be identified as content-type geo?

Kim Durante [2 hours ago]
they would be now according to our current workflows. and they are geospatial. but we haven't really discussed how to handle these.

Darren Hardy [9 minutes ago]
i think the embargo functionality in SDR2 might be the most explicit way to indicate that layers need to be made "dark". that said, the GIS robots don't support embargoes right now

Jack Reed [8 minutes ago]
Should they not get Purls or webservices too?

Darren Hardy [4 minutes ago]
@kimdurante? i'd assume not (those few do because we didn't embargo them -- i'd have to double-check the common-accessioning robots to see about the PURLs/stacks) -- here's the documentation on the embargo functionality -- https://consul.stanford.edu/display/chimera/Embargo+management+--+the+embargoMetadata+datastream

---

The gis-robot-suite does check the rightsMetadata to determine Public vs Restricted here -- https://github.com/sul-dlss/gis-robot-suite/blob/master/robots/gisDiscovery/generate-geoblacklight.rb#L106-L117 but it always uploads the layer to EarthWorks when gisDiscoveryWF is run.

[mejackreed]

This is a departure from our current understanding that everything geo is either public or Stanford restricted. This feels like new engineering work that needs to be accounted for in some way.

[drh-stanford]

Yes I agree, and there's bound to be subtleties in the SDR2 implementation. That is, we're going to need to think this through from the larger WF perspective, including common-accessioning, etc. The embargo and/or the release functionality are the only options in SDR2 that I'm aware of for controlling outbound publishing.

[thatbudakguy]

@kimdurante I don't have a ton of context for this, but it seems like these days this would just be solved by not releasing the item to Earthworks. maybe this is a problem that only existed back when we had the gisDiscoveryWF instead of just using the release workflow?

[jcoyne]

@thatbudakguy isn't this about file (layer) level controls? Release is an object level control.

[kimdurante]

Hi @thatbudakguy. yes, this request pre-dates the releaseWF. There are a few data collections where releasing all the objects to EW was undesireable. Such as when there are hundreds/thousands of raster tiles (aerial photography, digital orthquads, etc.) stored in geoserver which are better accessed through an index map. In those cases we did not want to index the objects individually in EW, since they contain minimal, identical metadata.
Now we can now use the releaseWF to remove these, if necessary.

[thatbudakguy]

isn't this about file (layer) level controls? Release is an object level control.

i think i could understand this better if i saw an object that contained many distinct layers...i haven't come across (so far) any cases where an SDR object needs to map to multiple distinct layers in EW. does that happen?

[kimdurante]

No, this does not happen for geospatial data in SDR. There is only one layer per object in all cases.