Geolocation Review

[mmccool]

Result of reviewing use cases to identify those where geolocation is relevant but the description needs updating or it needs to be mentioned. @mmccool and @cperey will work on this. We will use one "master" issue but with checkboxes for each subissue (review is WIP, so this is just a template at the moment).

• [ ] Greenhouse 2.1.1 - location of sensors is relevant, but not mentioned

[cperey]

Here are the preliminary results of review of use cases 2.6-2.11 and 3.10

• [ ] Health has two sets of use cases: public health and private health Pulbic Health Monitoring has location as one of the requirements, makes reference to localization use case, specifies in the "gaps" section that there is a need for Standard vocabulary for geolocation information
• [ ] Medical Devices makes no reference to location and does not need since all the medical devices in the use case are supposed to be in one hospital's ICU. If, however, the use case were expanded to include asset management, then the location of the asset (the medical device) would need to be included as part of its data
• [ ] Health Notifiers makes no reference to geolocation, however, if a healthcare provider is receiving information about a patient, they may need to be informed about geolocation in order to take or recommend an action.
• [ ] Smart Grid does not refer to geolocation, however, since location of sensors are important, it must be added because the location of any element/component of a smart grid may be valuable to managers and AI systems
• [ ] Transportation geolocation is important (highly relevant), and somewhat mentioned, however, could be improved
• [ ] Smart Car Configuration Management location of sensors is not highly relevant, and not mentioned
• [ ] Home WoT Devices Synchronize to TV Programs location of sensors is not highly relevant and not mentioned
• [ ] Education - Shared Devices location of sensors could be relevant if the use case were expanded, as is not relevant and not mentioned.

[mmccool]

As we discussed, I also did a review of the use cases not covered by @cperey - I will merge these with Christine's and add them to the description. The following are summaries of ALL the use cases I surveyed, but in some cases the conclusion was that geolocation was not a critical requirement. I will extract only the ones where additions or changes are needed into the description above.

• [ ] Greenhouse Horticulture (already mentioned in description). The current use case does mention that the location of the Greenhouse is used for weather predictions but it's not called out. Internal location of sensors is not mentioned but may be relevant (athough the use case seems to be about overall conditions as opposed to microclimates).
• [ ] Open-Field Agriculture - geolocation is relevant and mentioned, but more detail would be useful, for example, general location for weather forecasting, local location to high accuracy for controlled irrigation. Depth is mentioned as an additional important geolocation requirement. No geolocation standards cited.
• [ ] Irrigation in Outdoor Environment geolocation is not mentioned but may be relevant; there is some overlap with Open-Field Agriculture. However, the "plot"-based system with actuators and sensors co-located may also reduce or eliminate the need of knowing exact locations (each irrigator responds only to data from its local area).
• [ ] Smart City - Geolocation Obviously relevant. Cites many use cases including logistics and proposed use of reusable geolocation module (which could be a phone app) and surveys various location technologies. Mentions geofencing. Mentions timestamping. Cites numerous relevant geolocation standards (probably needs to be updated, i.e. to include GeoPose). Review of cited standards (looking for gaps - additional standards that should be cited) would be useful.
• [ ] Smart City - Dashboard Visualization of data in geographical context - integration of sensor data and GIS systems implied, but mapping and GIS integration is never mentioned.
• [ ] Smart City - Interactive Public Places Dynamic geolocation does not seem relevant, although a map is mentioned it is implied to be a you-are-here map where location is static and known in advance.
• [ ] Smart City - Meeting Room Event Assistance Geolocation is not mentioned but does not seem relevant. Note: this may be a Smart Building use case, not a Smart City one.
• [ ] Smart City - Cross-Domain Discovery in a Smart Campus Geolocation is not mentioned but may be relevant. In particular, part of the specification of a relevant sensor may be based on physical proximity, within a certain building, or other geospatial filters.
• [ ] Smart City - Cultural Spaces Geolocation is not explicitly mentioned but the scenario involves correlating the locations of sensor readings, actuators, visitors, and assets within a building. A building-centric geolocation approach may be relevant, including information such as room topology (if vistors are in room A, and room A is connected to B and C, it can be predicted that B and/or C may soon receive visitors). There are some standards related to building geolocation, e.g. BOT, that could be cited. Use case also overlaps with some later use cases about Smart Buildings (and perhaps belongs in that section).
• [ ] Building Technologies - Smart Building overlaps with Smart City - Cultural Spaces, same comments apply. Geolocation and/or correlation of location of sensors/actuators/assets/people is relevant but is not mentioned. No geolocation standards are cited.
• [ ] Building Technologies - Connected Building Energy Efficiency Climate data is mentioned, depends on (a relatively static) geolocation. Occupancy model described need correlation of sensors with location at least at a rough level (rooms). Does cite OGC's Sensor Things.
• [ ] Building Technologies - Automated Smart Building Management Geolocation relevant: notes that data often lacks context including location. Topology, zones, production/use relationships, and "semantic locations" are mentioned. Cites WoT Geolocation proposal and BOT; BOT is especially relevant and could be added to several of the overlapping use cases noted above esp when topology is mentioned.
• [ ] Building Technologies - Portable Building Applications geolocation is relevant - "spatial topology" is mentioned, but it is noted that the topology of systems (HVAC, electrical, water, etc) within the building, not just the occupied spaces, is relevant. BOT and SAREF4BLDG are cited.
• [ ] Manufacturing - Production Monitoring Geolocation is not mentioned and may not be relevant except indirectly (e.g. logistics of transportation between sites, but these can be modelled as static costs)
• [ ] Manufacturing - Cross-protocol Interaction in Industry 4.0 Scenarios Geolocation not directly relevant, may be indirectly relevant (e.g. static location -> weather -> logistics predictions). No geolocation standards cited; however, none needed.
• [ ] Retail This includes a set of related use case so I reviewed them together. In large retail operations in-building location may be relevant, e.g. to correlate person detection sensors with assets or other sensors/actuators. Therefore some of the requirements of Smart Buildings, topology, etc. as discuss above may be applicable. Logistics is also relevant along with indirect geolocation requirements (e.g. for weather forecast). Location of sensors (e.g. on a building map) important when trying to identify/locate an alarm or a faulty sensor, open door, etc. Orientations and locations of cameras as well as synchronized timestamps may be required. No geolocation standards cited, but if some are added, they would be of the "smart building" variety.