Geoserver OGC getCapabilities link incorrect for Tier 3 services published through GIN-stack

[ccaudill]

Upon harvesting from a GIN-stack (both parties up to date from newest rpm), none of the web services resources were harvested in, but produced errors: http://search.geothermaldata.org/harvest/geological-survey-of-alabama/job/last

In looking at the GIN-stack http://ginstack.gsa.state.al.us/dataset/well-header-observations/resource/3022f51e-b26d-43b0-8893-500d5fbb595e all the tier 3 resources seem to have been published correctly and preview.

The other thing I noticed is that in Alabama's GIN-stack, none of the published tier 3 resources will work in Geothermal Prospector. What is happening there?

[smrgeoinfo]

the URLs for the web services are odd:
http://216.109.20.7/geoserver/get-ogc-services?url=http%3A%2F%2F127.0.0.1%3A8080%2Fgeoserver%2FALWellLog%2Fwms%3FSERVICE%3DWMS%26amp%3B&workspace=ALWellLog
This request does return a capabilities document, but there is no 'request=GetCapabilities' in the URL--how does this work. Is it some GeoServer-specific thing?

and the same URL is given for all the request end points. I can't preview the WMS

[ccaudill]

http://216.109.20.7/geoserver/get-ogc-services?url=http%3A%2F%2F216.109.20.7%2Fgeoserver-srv%2FALWellheader%2Fows%3Fservice%3DWFS%26version%3D1.1.0%26request%3DGetCapabilities%26typeName%3DALWellheader%3AWellheader&workspace=ALWellheader

Looks like the request does have 'request=GetCapabilities' but something is going. Here are two URLs going to Prospector, the first from an ArcGIS-published service and the second is from a GIN-stack published service:

https://maps.nrel.gov/geothermal-prospector/#/?baselayer=6&zoomlevel=3&wmsHost=http%3A%2F%2Fservices.azgs.az.gov%2Farcgis%2Fservices%2Faasggeothermal%2FAKBoreholeTemperatures%2FMapServer%2FWmsServer%3F&wmsLayerName=BoreholeTemperature&wfsHost=http%3A%2F%2Fservices.azgs.az.gov%2Farcgis%2Fservices%2Faasggeothermal%2FAKBoreholeTemperatures%2FMapServer%2FWFSServer%3F&wfsFeatureTypeName=aasg:BoreholeTemperature

https://maps.nrel.gov/geothermal-prospector/#/?baselayer=6&zoomlevel=3&wmsHost=http%3A%2F%2F127.0.0.1%3A8080%2Fgeoserver%2FALWellheader%2Fwms%3FSERVICE%3DWMS%26&wmsLayerName=Wellheader&wfsHost=http%3A%2F%2F127.0.0.1%3A8080%2Fgeoserver%2FALWellheader%2Fwfs&wfsFeatureTypeName=ALWellheader:Wellheader

The FeatureTypeName is not correctly given in the GIN-stack published service, as specified in the schema.

[smrgeoinfo]

There are two problems--

1. the URLs from the Alabama service are not OGC requests-- they are geoserver requests with two parameters -- a URL and a workspace. That's why the prospector link doesn't work (note the wmsHost parameter is a 127.0.0.1 local host URL in the second prospector call above.

I sent an e-mail to Denise Hills and Christy about this problem.

[smrgeoinfo]

Second problem is that the ISO19139 xml doesn't follow the conventions we set up for CKAN to identify the csv file distribution link. See https://github.com/ngds/documents/blob/master/Tier3-csv-DistributionLink_inISO19139.docx . The necessary keyword is there, and the CSV online resource/linkage/url, but the CI_OnlineResource/name/CharacterString MUST contain 'NGDS Tier 3 Data, csv format'. If the code is following this convention as specified, and its not in any of the listed distributions, the upload should not happen. The metadata should still be harvested, but the NGDS services will not get deployed. Problem to fix first is the metadata content.

[ccaudill]

http://test.geothermaldata.org/geoserver/get-ogc-services?url=http%3A%2F%2Ftest.geothermaldata.org%2Fgeoserver-srv%2FALnone%2Fows%3Fservice%3DWMS%26version%3D1.1.1%26request%3DGetCapabilities%26typeName%3DALnone%3Anone&workspace=ALnone

Here is a test resource that we published on an in-house test GIN-stack installation. Note that this is still not a straight GetCapabilities request but is some sort of GeoServer http request which wraps a GetCapabilities request (thanks for explaining that one to me, Steve!). The services published through the GINstacks are not producing a correctly formed WMS and WFS GetCapabilities request.

However, it did not have the local host in the URL like the service published by the AL GIN-stack. How might they have kept this local host in the GeoServer URL? Does the user indicate this when installing, or is this more likely something specifically from AL's server?

[ccaudill]

For clarity, here's a correctly formed GetCapabilities request:

http://services.azgs.az.gov/ArcGIS/services/aasggeothermal/AKBoreholeTemperatures/MapServer/WMSServer?request=GetCapabilities&service=WMS
@dano-reisys

[ccaudill]

associated with https://github.com/ngds/ckanext-ngds/issues/596 ?

[smrgeoinfo]

google search for [geoserver "get-ogc-services"] gets a bunch of results pointing at our ngds ckanext, and to metadata calls to the REI test server uat-ngds.reisys.com, with the 'get-ogc-services' geoserver call in the distribution get-capabiltiies; the earliest of these is dated March 12. It shows up in Alabama ginstack results from as early as May 21.

In the long thread #596, the final posting closing the issur dated Ap 14 has a getCapabilities URL for geoserver using this geoserver function, not the standard OGC getCapabilities call. Somehow this problem was introduced when working on the automated deployment of harvested csv files, probably before or when the REI test server was deployed around March 12.

[smrgeoinfo]

the capabilities URL appears to be constructed in the create_geo_resources function in
ckanext-geoserver / ckanext / geoserver / model / Layer.py. This seems like a likely place to start debugging. @dano-reisys, what do you think?

[dano-reisys]

it looks like the geothermal prospector link is being generated correctly for ginstak datasets that have been published to OGC. The only problem is the url to points to the geoserver. It need to be modified here: /var/lib/tomcat6/webapps/geoserver/data/global.xml (right not its pointing to 127.0.0.1, obviously, geothermal prospector can't get to it).

[smrgeoinfo]

This was breaking the Geothermal Prospector integration, but now it seems to be working in prospector, so lower the priority