Points If you…
+1 Open publish scientific papers (accessible by all for free)
+2 Open publish data (with unrestricted access)
+2 Use JSON/Atom/RSS feeds for your data/products
+2 Extend feed with geo/activity streams
+3 Associate one or more GEOSS Societal Benefit Areas (SBA) with data product
+3 Identify source/quality/limitations of product for GEOSS user
+2 Use feed aggregator (Feed burner, Superfeedr…)
+3 Use OGC Standard Services for data access (WMS/WMTS/WCS/WPS…)
+2 Use Single sign-on using existing social networks (Google, Facebook, Twitter…)
+2 Allow data retrieval for specific user location at < 1km resolution and specified range/radius
+2 Allow user subscription for data in area of interest and automatic notifications
+3 Allow user discovery, access and visualization of data on mobile platform
+3 Allow user sharing of local data with friends or local Community of Interest
+5 Allow users to provide local data feedback
+10 Improve product based on local user feedback
For SensorWeb to be relevant, we believe that any of its data and assets can be no further away than two degress of separation from anyone in the world. This does assume that those users would be from trusted domains and would have been granted the proper permissions from their organizations. We are coining this our SWE "Bacon" number or Two. So, you are doing SWE? What is your Bacon number?
NASA support has been requested in for a state of emergency so we are all trying to help as we can. We have modified our GEOSS workflows to monitor the situation in the San Diego area. Fire threats are being detected based on MODIS data and EO-1 is being tasked twice a day to image the area.
RESTful workflows implemented using OpenWFERu are being used to process the imagery to deliver the data to the first responders. First thermal imagery processed onboard the satellite has been downlinked and is available on http://eo1.geobliki.com. Higher resolution data will be available as soon as possible.
As more than 500,000 people are being evacuated and many are loosing their homes, our prayers and thoughts are with you.
Our latest video on our GEOSS use-case finally made it to YouTube.
With Many thanks to Ingo Simonis!
Here is the plan for a demo:
A Web Feature Server (WFS) in its basic incantation is really a store of geospatial collections that can be accessed using RESTful services.
Building Web Services the REST way has been a very hot topic in the Rails Community.
Rails 1.2 can quickly allow you to build such services and return xml or html on-demand. JSON or [Geo]-rss/atom could be returned as easily in a similar manner.
Discovering the meta-data should be feasible using a meta-data feed and probing a specific url.
This would give us many services to access the various collections and the meta-data. The whole package could be described using a service document as proposed in the Atom Publishing Protocol (APP) that would describe all the available services. This document itself would be available at a specific url.
Searching the WFS would be done via OpenSearch-Geo which is another REST service returning atom or KML feeds.
The goal is to implement this for the upcoming ESTO/AIST Fire Management demo this summer and support the GEOSS Pilot effort this fall. This is also in line with our participation into the OWS-5 Agile Geography testbed.
A Few Links:
Older posts: 1 2