-
Notifications
You must be signed in to change notification settings - Fork 13
Geothermal prospector support in NGDS CKAN v2 #580
Comments
…API (break to exit loop)
Testing http://uat-ngds.reisys.com/dataset/indiana-borehole-temperatures-wms-wfs-2 (as specified in https://github.com/ngds/ckanext-metadata/issues/14) and it looked like it worked as should. WMS was drawn and features could be queried. Though testing a few other services may have crashed the server hosting the Geothermal Prospector - or it was coincidental that the Geothermal Prospector stopped working at the same time. |
I've done a changing, here https://github.com/ngds/ckanext-metadata/issues/14#issuecomment-68073532. it could be a fix for this (if it wasn't from Geothermal Prospector server) |
@JihadMotii-REISys I don't see Geothermal Prospector button in new build |
is the new build UAT ? otherwise, can you send me the link to the new build ? |
Sorry, it's our internal servers, updated to the latest rpm. |
I created a dataset in UAT that is up to date with all new code/ configuration, this is the link: In order to make geothermal button working, your internal servers has to have access to external and also geoserver needs to be set up. (if you're behind reverse proxy) ... |
I don't understand why this opens in GP with the data that it does, and not well log data that is specified. Perhaps that doesn't matter for this test. Also, the button just vanished recently, so there shouldn't be any work with getting it configured again. You say that external servers need to be accessed and GeoServer needs to be set up, but that's already done in any installation, so I'm confused about why you mention that. The button is there, I'm just not completely sure that it's working properly. |
Hey @ccaudill Just want to make sure you followed below steps to set up geoserver after initial installation
Also make sure internal servers can access https://maps-stage.nrel.gov/ url. And as far as I understand Geothermal Prospector application at https://maps-stage.nrel.gov/ contacts back to CKAN node to get the data to be displayed on map. And that is why we suspect Geothermal Prospector is not able to display data from internal server. Also I'm little confused about button visibility ... Are you saying button now shows up but when clicked shows up wrong map? |
You're saying that after running the update rpm at https://github.com/ngds/install-and-run#updating-ngds there's other things that need to be done? |
No ... not after update only after initial installation. If you did after initial installation then don't worry about it. |
I suspect its because server not accessible from outside. Like I said above.. |
We followed the instructions here to install: https://github.com/ngds/install-and-run#installation |
The server is open to the internet. You should be able to hit it. |
@ccaudill Can you please email be below 2 files or give me SSH access to the server?
|
@ccaudill in production.ini ckan.hostname was incorrect (It was default 127.0.0.1) So changed it to correct IP address. But there is something wrong with datapusher / datastore. I am not able to push the CSV data to datastore at all. @FuhuXia any idea? |
@ykhadilkar-rei You can only publish services through this CKAN UI (GeoServer) using a CSV. However, harvested tier 3 data and services will still be perfectly valid, though published through a different process (usually with ArcMap) which does not require a CSV file. |
Can we get an update on what happened to the Geothermal Prospector button?? This is CRITICAL and should take precedence over other things. |
@ccaudill We are looking into it, you should hear from us soon. |
@ccaudill @smrazgs I was able to add the well log csv file to the datastore: Seems like there is some kind of NAT problem going on between the local ip address and public ip address @159.87.39.5 Was this instance set up in Amazon? |
That was a bad example ... that link did not work. But this one does, no button: |
same problem i think... but the link is valid, i'll have to take a look at it. |
Should be fixed in instance: http://uat-ngds.reisys.com/dataset/test-wms/resource/5fc4c88d-4a12-4407-bbdf-0c3a029caa45 it will require a code push |
What fix are we looking at there @dan-olaru-reisys ? |
@ccaudill The WMS preview should work now, looking into why the geo-prospector button isn't showing up atm |
@ccaudill I was able to get the geo-prospector button to show up for the other datasets, but i am getting a WFS error on maps-stage.nrel.gov (looks like the WFS has no wfsFeatureTypeName... or am I missing something?) here is the link to the dataset on uat-ngds: http://uat-ngds.reisys.com/dataset/alaska-thermal-springs2 the equivalent of: On the other hand, the tire 3 dataset does provide wfsFeatureTypeName for WFS) |
Perhaps that layer for DEWellLogs you created does open in GeoProsp without error, but you still can't access the WFS features "Data for this layer is not available for download." and the WMS isn't showing on the map in GeosProsp either. I think programmatically, you will have to add the wfsFeatureTypeName to the URL that NGDS CKAN is providing to NREL. It will not come like that in the harvested data for any resource. As indicated in the the first comment of this issue, the URL must be constructed to include "wfsFeatureTypeName: the name of the wfs feature type exactly as it needs to be specified in the TypeName WFS parameter". |
The WMS is working as it should; Since there's no parameters for the WFS in the prospector URL, it gives that alert message about can't query the data. See list of parameters for prospector URL call, https://github.com/ngds/ckanext-ngds/issues/404#issue-29764334. need to include wfsHost and wfsFeatureTypeName. Need to see if there is a WFS and WMS distribution
wfsHost: a string (URL escaped) containing the endpoint URL for a WFS that provides feature access to the data displayed by the WMS. The string argument is the part of the URL that precedes the WFS parameters, basically a WFS request with no parameters part (leave out the question mark). OPTIONAL wfsFeatureTypeName: the name of the wfs feature type exactly as it needs to be specified in the TypeName WFS parameter; the namespace qualifier might or might not be required, I think that might depend on the service implementation. OPTIONAL see bug fix at |
NOTE ngds/metadata-issues#47. Our metadata isn't following the profile correctly (the issues never end), so to detect if there is a WMS or WFS distribution, probably have to look for 'service=WMS' or 'service=WFS' in the gmd:linkage/gmd:URL:
|
@smrazgs Geothermal prospector button url: @ccaudill wrote:
*2.
@smrazgs wrote:
Are you saying that this dataset should not have a geothermal prospector button? |
Neither of those things. You just need to look here in the metadata for the wfsTypeName: And make that wfsTypeName be added programmatically to the URL that CKAN NGDS provides to GeoProsp. |
@ccaudill what about issue "1." from above? any ideas? |
@ccaudill @smrazgs this appears to be the valid geothermal prospector link for the dataset at this url: http://uat-ngds.reisys.com/dataset/alaska-thermal-springs2 the wfs issue is still there...
|
From that link, the AK WMS is showing up exactly as it should in GeosProsp. |
prospector link seems to be working perfectly at this point. The data are actually for Arkansas, not Delaware. The Metadata for this record is correct, it includes the correct gmd:protocol values in the metadata. I don't know for sure that prospector is supposed to enable download of data from a WFS... the metadata for the Alaska service |
FYI - |
That should be the normal behavior. The fix is in the code, which is not in the v307 rpm |
can we get it in the rpm soon? |
@smrazgs We'll are planning on building a new rpm on 03/31 @FuhuXia |
@smrazgs @ccaudill questions:
From looking at the code it seems like there only one wms per dataset, but there might be multiple wfs resources because its trying to loop over a list of wfs resources |
@dan-olaru-reisys -- looks like the problem is that action.py geothermal_prospector_url is not finding the WFS connection information in the CKAN package resource. Lets try and focus the issues on specific problems, and close them when we resolve the problem. I'm closing this thread and starting a new more specific thread. If there are other unresolved issues in this thread, please start a new, specific thread. |
see #404, #459
Function works in NGDS CKAN v1. the Button should show up with the WMS distribution links for search results that have WMS distributions
@ccaudill
here's some notes from Dan Getman e-mail:
From: Getman, Dan Dan.Getman@nrel.gov
Sent: Tuesday, August 19, 2014 1:52 PM
To: Adrian Sonnenschein;
...
wmsHost: a string (URL escaped) containing the endpoint URL for a WMS; this is the part of the URL that precedes the WMS parameters, basically a WMS request with no parameters part (leave out the question mark). REQUIRED
wmsLayerName: the name of a layer in the WMS to display. ONLY one layer name allowed. REQUIRED
wfsHost: a string (URL escaped) containing the endpoint URL for a WFS that provides feature access to the data displayed by the WMS. The string argument is the part of the URL that precedes the WFS parameters, basically a WFS request with no parameters part (leave out the question mark). OPTIONAL
wfsFeatureTypeName: the name of the wfs feature type exactly as it needs to be specified in the TypeName WFS parameter; the namespace qualifier might or might not be required, I think that might depend on the service implementation. OPTIONAL
You can also use:
zoomlevel: an integer to set the desired zoom level
mapcenter: a string (URL escaped) containing the coordinates for the center of the map "lon,lat"
overlaylayer: Setting this to 0 will turn all layers off by default.
Setting this to anything else may be unpredictable.
It is important to note that the layer ids for baselayer parameter have indeed changed and will likely change in the future as well. This parameter has been inadvertently included in some of our example URLs (cutting and pasting error in emailing unfortunately) but was not intended to be used to call GTP from NGDS. This parameter, and many others that you may see loaded into the URL by GTP, are for our use in allowing users to send other users URLs.
First, setting the baselayer to a now invalid ID is causing no base layer to be loaded. This should explain the gray base map that you observed.
Second, the layer that you are referencing only shows up at zoom level 7 and you have zoom level 1 specified. The result is that the layer actually loads, but is not visible.
You can specify a zoom level of 7 and it will work:
https://maps-stage.nrel.gov/geothermal-prospector/#/?zoomlevel=7&wmsHost=ht
tp://www.geocommunicator.gov/arcgis/services/PLSS/MapServer/WMSServer&wmsLa
yerName=11
Third, the map service that you sent is reporting a non-working legend URL. I'm not sure what the issue is with this, but it will prevent the layer from displaying a legend.
Next Steps:
On my end, we will make sure that the baselayer parameter is handled such that any layer id that is not valid will result in a default base layer being loaded, which should prevent the gray base map issue that you observed.
Also, to address your main concern, I believe it unlikely that the URL parameters which are specified here and in our original emails providing the descriptions will change. If that does occur, we will notify you beforehand to make sure that it will not create a problem on your end.
The text was updated successfully, but these errors were encountered: