GEO April 14, 2008 Call
From Exchange Network Wiki
Contents |
April 14, 2008 Geospatial Task Force Call
Underlined text is linked to call materials.
Draft Agenda:
- Geospatial Task Force objectives, context, products, and straw timeline for completion
- Quick review sequence diagrams and use cases from last call and WA’s Location Finder Sequence Diagram
- GML usage/adoption design options
- Business case, what/why of implementing GML in EN schema
- How EN services and other services complement each other
- Design consideration for implementing GML in EN schema
- Discussion of project for demonstration at the User’s Conference and its relationship to the Geospatial team objectives.
- Work planning towards the EN National Meeting
- Schema design options discussion
- Pilot
1. Geospatial Task Force: Phase I – Straw calendar
2. Quick review sequence diagrams and use cases from last call and WA’s Location Finder Sequence Diagram
3. GML usage/adoption design options
Discussion and questions
- Exchange Network offers standards and schema just as much to RSS and WMS, etc. as to Node and XML/WSDL
- The EN has a lot to offer the world as a forum where people could create common service definitions.
- The geo connection is broader than we have been thinking. It has to do with brokering services or creating translations and how to reach out to people and provide a uniform way to do these things.
- Ultimately, we’ll be working with a smart client that knows how to do these things.
- We don’t want to exclude people that aren’t using nodes. A key element is that the EN may have something to offer the world not using the node.
- We want to see how a node and WFS play nicely.
- What are good ways to get EN keys in return from WFS? How should they be wrapped?
- When populating a feature service with facility data, the diagram calls for second call for rich data.
- Why do they make a roundtrip through the node? Unless they’re going to get something else like county, etc. They will be going against the node.
- How do we go against the node?
- If assemblies are available, you don’t need to go back to the node.
- We’re conceptualizing the OGC services as wrappers around existing EN functionality and not separate.
- We’re an ESRI shop with extensive layers, but can’t get at it, because we haven’t enabled a mapping service or feature service. Only info with keys is from my database.
- We made runs at WFS with ESRI technology. We do an extra step to return the keys, then go back to get rich attributes. Keys you get are from your spatial database (same database). Soon they’ll all be the same database – because they’ll all be running.
EPA Watch/Discover/Report Demonstration Application
- Overall goal is to geo enable EN data for applications that need access to that data through flows, via services. The approach is to stand up a suite of services that bind to data. Operationally they would be deployed at the node level. WMS, WFS, CSW, at each data node. We believe we can maintain the richness profiling GML.
- For use case we’ve backed off real time component. It’s more: tell me if a new station or measurements are available from a station or facility and look at details of station or facility like watershed.
- The scenario is to pick a watershed and integrate Pacific Northwest (PNW) data through a couple services, through common discovery. The focus is water. Also want to demonstrate the use of Atom/RSS to provide a feed for permit issuance or for a new project that’s doing monitoring in a given area. Data would come from lots of different sources. The focus will be on architecture and also which watershed makes sense and what functionality is interesting and useful enough and will call the right questions.
- The client does not touch EN data, just OGC standards. That thinking could be wrong, but the counter argument is these are OGC standards, so if we can show that EN plays well with these services, the EN has the whole world to provide data to.
- Facility data would come through the node through WFS, and FRS feature chunks would be wrapped. PNW flow as currently mounted would come through WFS. Client wouldn’t have to worry about consuming EN node, even though it would come through WFS.
- Other possibility is to build top part with a stylesheet.
- The WFS limitation is not in the OGC spec itself; it’s a limitation of ESRI product line.
- This is all open source and we are using different toolkits to enable this. We don’t know the limitations, and need to figure out what would that schema would look like wrapped in WFS.
- We should wrap lessons learned, the real use case, and best practices into the demonstration.
- How do we partition data we’re sending through WFS and the node?
- WMS and WFS have to connect to something.
- We need to know what WFS support for rich data is, so we have an honest assessment, so we know how it stacks up against WFS.
- Need to stress that they’re independent, since we’re bringing out Node 2.0 and NAAS 3.0.
- One of the best things that can come out is the honest assessment re compatibility, technological limitations, etc.
- This deliberation will go beyond the course of the demonstration project.
- We’ll map the actual data elements that are proposed to go back and forth for the use case.
- If we need to go back to the EN node for the data, that can be built in.
- In this approach the big vendors are supporting this suite of OGC services.
- If we can’t achieve this vision, we can use this as an opportunity to address that issue.
- Anyone aware of WFS for water?
- There’s a WFS that returns 303d impaired water. 1:1 not 1: many relationships. There’s the GOMOOS thing in Maine.
- Some of what we’re talking about can be accomplished through simple stylesheet transformations.
- Recommendations for a watershed?
- We’re thinking PNW because we have a hand on water quality data. Lots of data sources to tap including Dwane’s (WQX) and others.
- Are there other simple business features that would be useful to be demonstrated to put pieces together?
- Glen C. and John T. will check for what they have available.
- NOAA just started to mount WFS and is making those available.
- WFS is served with ArcIMS and we haven’t been able to find a client that can consume it.
- Wouldn’t bank on WFS – ESRI ArcIMS service. We can query for an XML document, but can’t open layers, consume it. We tried various open source clients and none could open it.
- The ESRI implementation in ArcIMS is bad. We’re hoping 9.3 will be approved and available. Version 9.3 is critical to this.
- On next step get a stylesheet.
