GEOSS Future Products & GeoSocial API

Editor's Notes

• #2: Due to time constraints, this presentation does not contain technical details. Please check out the various slide decks on slideshare.
• #3: For GEOSS users, the current OGC standards are to difficult to use, to learn and develop. GEOSS users are defined as non professional software developers that need access to imagery to respond to a disaster or use the data for GIS applications. They would be willing to spend 30mn to learn an API if needed but their software skills are limited.
• #4: This is unfortunate because we have the data (big data, open data) and we do have many APIs. But the gap is enormous. In most cases, the data is not readily accessible and used as needed by those neo-geographers.
• #5: OGC API’s originated in 1995 to respond to community needs. The second generation evolved based on serving the needs of the engineering community, DOD, NASA, ESA with very high skill levels and need for very strict interfaces. Although we are seeing a recent move towards a resource-oriented architecture (or RESTful services), it is becoming very obvious that even those services are too low level and still difficult to use. They are simply at the wrong level for the GEOSS community.
• #6: To generate a simple flood map, GEOSS users such as McCloud in Namibia need to master 60+ standards with API’s from 400+ organizations at different revision levels and binding types (RPC, SOA, ROA). Security is also another difficult hurdle that adds to the complexity of the system. Finding the right data, assets to task or imagery to process is simply too difficult.
• #7: We are not advocating yet another API to add to the mix but rather a client layer that could be used to help the user find a way to generate relevant products. This layer would be integrated as part of a user-agent on the local desktop, table or smart phone.
• #8: This new layer is required because the GEOSS users have different needs and concerns. They do not relate to our existing services or data models. They do not care about big data they do not understand or can relate to.
• #9: They care about relevant products for a particular situation in a specific area of the world. They want to generate products that may involve satellite tasking, image processing and data distribution without having to master the specifics of the various interfaces.
• #10: We need API designed for people to tame the inherent complexity of the various operations. It starts with a goal that can be translated into a set of activities to be performed upon the world.
• #11: As services, we need to publish the goals that are possible and the activity sequences provided as behaviors to follow to access the “big” data and transform it into relevant products to can be turned into actionable information.
• #12: We are talking about generation an action map or behavior. This can be encapsulated as code-on-demand downloaded from the servers. That code would contain various links to follow based on some decision gates that may require user input. This runs on the client side on behalf of the user.
• #13: In our case, it becomes easy to imagine our user requesting a flood map for Haiti or Rundu, Namibia. Behaviors may come back from various services handling radarsat-2, EO-1, MODIS, Landsat-8, models and many others. These behaviors would run on the client side and eventually generate the desired products.
• #14: Discovering potential products can be done within the existing social environment of the users. In that case, discovery is simply done via story-telling: the most natural way for humans to convey information. African drums used to tell stories in the jungle, alerting of arriving foreigners at more than 100 miles per hour. Leveraging the social networks, stories can become viral quickly. Within an existing community of interest, users will tend to do what others did successfully. Activity streams and active links can help point users to the original activity sequence and generate a similar product
• #15: Activities get published in user timeline and news feed. They contain a picture of the generated product and links back to original product page.
• #16: Various activities can be published. Feasibilities, tasking and image processing. This increases the chance of discovery from friends. OpenGraph queries are of course possible at any time.
• #17: This describes the various layers of the next generation GeoSocial API. Bottom layer has the traditional data and service APIs. We are adding an activity layer and a behavior layer to enable users to generate published products or goals.