Future Paths for Geo on the Exchange Network

From Exchange Network Wiki

Jump to: navigation, search

Annotated Outline for Discussion

This annotated outline is intended to solicit discussion from the EN team towards the development of a short Future Paths document for the ENLC which answers the question:

“What should EN (governance) do to invest/position the EN for success around Geo?”


YOUR COMMENTS ARE ENCOURAGED. To learn how to edit this wiki page, please visit the Wiki Tutorial. Please add comments to the "Comments" area at the end of each section. 

Contents

Why is this important to the EN Now? What is the context?


  • Geo interfaces/applications are ONE important and growing endpoint for EN data.
    • Helping people build applications using the EN is critical, and geo is one element of that.
  • Geo tools and services are expanding fast, blurring the line that existed between old GIS and tabular data/DBMS. The geo world is rapidly expanding to also cover “attribute” data. The EN was born in the “tabular world” and needs to expand/link out.
  • OGC web services, warts and all represent the predominant way environmental data (tabular and spatial) is getting published. We need to position the EN with respect to these standards and their users.

    COMMENTS:

Following up on the question posed today about geo-enabling Nodes, are we aware of what we'd have to do to have our nodes respond predictably to a WFS request? This includes what our nodes would have to do with any back-end processing/databases.

Key Findings/Recommendations:

Supporting EN Geo Community


There is lots of activity and interest within the EN community (and its boarders) around Geo. Growing participation on the Geo Team calls indicates there is a strong base of interest.

Recommendation: EN should host a venue for sharing and spreading current know-how about EN/Geo linkages within the EN community:

  • Geo focus area on website/wiki – including a rundown of current grant activities doing geo. We should probably re-fresh this right now (Nov 2008)!
  • Regular rotation on the EN open calls
  • More detailed focus groups as need for topics

    COMMENTS:

GeoRSS Applications


We’ve taken the first step by establishing the Recommended Practices for GeoRSS in EN schema. We need to follow through on this.

Recommendations:

  • Post a summary up on the geo-section of the EN website, with a pointer to these materials.
  • Designate a point person to monitor, and then put together an evaluation of the application experiences of our GeoRSS early adopters.
  • Once we have some validation/refinement, shift into education/outreach mode on GeoRSS, highlight these applications and develop a short training video.
  • Appoint somebody as the official point of contact (perhaps through EPA’s existing relationships) to the OGC standards process. (see below

    COMMENTS:

Co-Evolution of OGC Standards and the EN (especially Query and Solicit)

  • Implementation of OGC standards continues to grow (much faster and broader than the EN). Per the discussion above, these standards are morphing more and more into providing the DATA itself not just its spatial attributes.
  • This presents both a dilemma and an opportunity. The opportunity is to stay engaged and figure out some way of using the growth of these standards to grow the EN. The dilemma is that many potential EN users on the boundary are going to ask (or even worse - not ask), “Why/when should I use EN and when should I use something like WFS or WCS?”
    • In the broader AQ community (e.g. NASA, NOAA, Universities) EN does not even come up, it’s all WCS.
  • So what is the right strategy for the EN/Geo path? And how do we explain this to our EN peers?
  1. Do nothing for now, other than track these standards?
  2. Conduct additional targeted pilots to fill out basic OGC/EN interaction patterns?
  3. Send some staff “deep” on this issue to come back with an answer? Leading to (d) or some alternative.
  4. Adopt/integrate some of these as “complementary” standards for the EN proper now.
    1. For example, a WFS which returns an EN schema.


Recommendation:  TBD


LS Note: I think this is a crucial issue for the future of the EN. But the question is, what do we do? We are just getting people ready to do Node 2.0, and they will freak if we throw a new standard at them. Yet, my bet is that across the server aisle in many Agencies, there are folks working now to take environmental attribute data and put it into WMS/WFSs.


COMMENTS:


Common Rich GeoData Models for Complex Objects/Features:


Is there interest/utility in developing common high level data models, for the spatial and attribute data, for specific environmental objects/areas of interest domains EN (like facility, hydrography, wells, landfills, habitat, etc)? The idea is that a common high level model could be used (and tailored) by environmental Agencies and then be used to produce common schema. It seems like we are going the other direction and harmonizing just the interchange schema, since Agencies have more or less settled on their models and there are always crucial differences. Would people use common interchange formats for rich spatial/attribute data, or by virtue of their richness will they always be unique? Is there anything for the EN (to offer) here?

Recommendation: TBD


COMMENTS:


P.S. See the GML section below for a great 10 minute introduction to GML:
https://www.e-education.psu.edu/geog585/

Retrieved from "http://www.exchangenetworkwiki.com/wiki/index.php/Future_Paths_for_Geo_on_the_Exchange_Network"
Personal tools