-
Notifications
You must be signed in to change notification settings - Fork 1.1k
GNIP 16 Remote Services
It is proposed to add functionality to GeoNode that allows users to configure external OGC services (WMS/WFS/WCS/CSW primarily) to be included in a GeoNode site. The various ways that an external service/layer could be configured has been discussed on the geonode list (see here https://groups.google.com/a/opengeo.org/group/geonode-dev/browse_thread/thread/7815b2b724ec4d94/cf33c41672230a36?lnk=gst&q=federation#cf33c41672230a36).
From the user perspective, a GeoNode user would be able to use a service URL, discover the advertised layers and be able to add these layers as a GeoNode layer. The layer should then be available as any "internal" layer.
Initial work under this proposal has been done by Jeffrey Johnson
https://github.com/jj0hns0n/geonode/tree/remote_services
https://github.com/jj0hns0n/geonode/tree/contrib-refactor/geonode/contrib/services
Some notes on preliminary experimentation with this branch by Matt Bertrand here:
https://docs.google.com/document/d/1hg2NMVC1uTnaOIehxcqW6_G71ISpKxiGfrUcgQZrzBU/edit?usp=sharing
Jeffrey Johnson
TBD
For Review and Comment
Currently it is possible to add an external WMS layer to a map in GeoNode by entering the URL to the service in the Add Layer Dialog in the Map Composer, but it is not possible to add an external service such that the external layers have their own GeoNode Layer pages and the features that come along with that. Many GeoNode users have asked about 'federation' functionality which would allow them to associate other GeoNodes with the site they are working on. Adding functionality for these types of external services is the first step toward accomplishing that goal.
It is proposed to add a new Service class to geonode.maps.models that will contain fields necessary to identify and store metadata for remote WMS, WFS, WCS and CSW services, and to develop the views necessary to allow these services to be configured. It is also likely that changes will be required in both gsconfig.py and also potentially in GeoServer to accommodate these features.
- A lot of issues.
- Requires modifications to the current Layer model (Foreign key to the Service model).
- Requires new Service model.
- Requires new page for "Registering" Services". Ideally, user should just enter a URL and app would somehow figure out what type of service it is.
- Needs a "New Layer Page" (vs Upload Layer Page),
- Typenames on the Layer object are unique, we need to ensure uniqueness for remote services.
- Supported external service endpoints have very different structures.
- Best way to handle URL’s for remote vs local - do it without if/else everywhere?
-
- Lots of functionality assumes layers are local and respond to WMS/WFS requests. Some remote services will not be WxS (ArcGIS Servers) , some may be WMS only.
-
- Example: layer attributes - uses WFS DescribeFeatureType to retrieve them
-
- CSW services - can’t use geonetwork/csw URL for layers, need to use originating service URL. Possible approach:
-
-
- Add parent_service field to Service model (FK to same table)?
-
- CSW service could have multiple child services
- Layers could be associated with child services and use their URL’s
- Need to guess what kind of service type child services are, assume WMS?
-
- Use separate models for service and supported service types? For example, Server 1 supports WMS & WFS, Server 2 supports WFS & WCS, Server 3 supports WMS & TMS, etc
- Encoding - Is it important to know which encoding remote layers are in? Let user choose during service registration?
- Remote services need to be added to proxy whitelist? Or can the proxy be avoided?
Extensive Integration tests will be required to validate this new set of features.
Do nothing. GeoNode does not currently provide this kind of functionality.
Discussion of this proposal on geonode-dev is here.
https://groups.google.com/a/opengeo.org/group/geonode-dev/browse_thread/thread/2cc69e0174eff2d0