Currently, the OCS portal only exposes Stream Names when creating Metadata Rules, but the API exposes the Stream ID as well. It would be beneficial to create a Metadata Rule based on the Stream ID from the portal.

Stream IDs are often more formulaic than names, and therefore can be better suited for parsing out data. PI to OCS streams are a common use case where the Stream ID contains useful metadata (data archive name, point ID) not found in the Stream Name.

If OCS is missing units of measure that you use and need for your data, please vote for this idea AND add a comment to this idea specifying what the missing UOMs are.

Ability to store images as time bound data into OCS, and retrieve the images for viewing or modeling/analysis.

Example scenario: a thermal camera takes a picture of a furnace and the image is used to extract data and performance KPIs about the furnace (stored back into OCS).

Ability to define Units of Measure on a Field in an SDS Type using the OCS Portal UI. Currently, the field type, name, and description can be edited, and fields can be marked as indexed. It is not possible in the UI to add UOM to a Field.

The ability to define custom units of measure (UOMs) within OCS.

When creating a type using the OCS Portal, the SDS field "Type" dropdown is a flat list including dozens of options, half of which are array types. This could be better organized to make common types (e.g. Double, Int32, DateTime, and String) easier to find in the list.

Ability to save a type with multiple indices using the OCS Portal UI. Currently, it is possible to select multiple fields as "Indexed," but saving the type then results in an error as the index order is not defined.

Within OCS, make it easier to edit the unit of measure (UOM) for streams.

Stream Types are not editable in OCS SDS by design but it's painful to have to recreate a new type and do your work all over again when you need to make a change or forgot something.

Please capture related scenarios you have around making changes to Stream Types here.

Ability to capture Batch Tracking data into OCS and visualize it.

The data could be coming from an existing PI System with using Event Frames.

Ability to segregate and view information (Data Ingress, Streams, Assets, etc.) from multiple customers/clients within a Namespace SO THAT it's very clear what data and system artifacts are related to each customer and SO THAT information doesn't accidentally get mixed up and exposed to the wrong customer.

Ability to manage security from ingress to egress via the same mechanism.

Some customers need to store (retain) some, but not all, data for extended periods of time. For example, there can be a need to store any data used in regulatory reports for 5-7 years. Going forward, could OCS be an option for collecting/aggregating/storing these data?

As a remote operations monitoring user, I would like to store locations and track movements of assets in a native GeoJSON data type / format for both querying as part of OCS and integration with peer cloud services that take advantage of geospatial positioning data.

Be able to handle the storage, context, and retrieval / visualization of spectral data.

As someone who collaborates on PMU Data or wants to do Wide Area Surveillance would it be possible to load and test data from LBNL PMU Data set. This will allow researchers to create sample solutions on top of OCS. In this area. More informtona and the data set can be found here: http://powerdata.lbl.gov/

As a Data Scientist or Data Steward, I would like a local, zero configuration, in-memory ordered, columnar data storage instance that can take a subset of data from a Cloud Services Data Sharing Publication and persist it for local computing resource tasks SO THAT repetitive updates and changes to my data queries perform well, and also, give me a safe space to test several scenarios prior to publishing data back to Cloud Services.

The ability to store video files in OCS and relate the video to process data by timestamp.