search

ngds / ckanext-geoserver-bku03232018

5 stars 6 forks source link

WFS service endpoints for same feature type. #12

Open smrgeoinfo opened 9 years ago

smrgeoinfo commented 9 years ago

I uploaded well log data for Oklahoma and for New Jersey, but when I go to the wms preview or geothermal prospector, I see the Arkansas data.

THE PROBLEM: from the details pages for the three datasets: New Jersey WMS: http://uat-ngds.reisys.com/geoserver-srv/WellLog/ows?service=WMS&version=1.1.1&request=GetCapabilities&typeName=WellLog:WellLog Oklahoma WMS: http://uat-ngds.reisys.com/geoserver-srv/WellLog/ows?service=WMS&version=1.1.1&request=GetCapabilities&typeName=WellLog:WellLog Arkansas WMS: http://uat-ngds.reisys.com/geoserver-srv/WellLog/ows?service=WMS&version=1.1.1&request=GetCapabilities&typeName=WellLog:WellLog

When a node publishes more that one service on the same Tier 3 content model, the service endpoint URLs are the same, and the layer name is the same (or typeName in the WFS), so you always get the same data. Its not clear what is actually happening to the OK or NJ data in Geoserver. The solution is that the service enpoint for each dataset need to be different e.g. New Jersey WMS: uat-ngds.reisys.com/geoserver-srv/NJWellLog/ows? Oklahoma WMS: uat-ngds.reisys.com/geoserver-srv/OKWellLog/ows? Arkansas WMS: uat-ngds.reisys.com/geoserver-srv/AKWellLog/ows? If we can't engineer that endpoint naming convention, then the node should provide an alert if you try to deploy another dataset using a content model that already has a deployed datasets. Options should be 1. don't deploy service; 2. append data to same service; 3. replace existing service. 2. and 3. would have a side effect requirement to update metadata records for the affected datasets.

@ccaudill we discussed this in the past, what is the current approach to the problem?

JihadMotii-REISys commented 9 years ago

@smrazgs @jessica-azgs @ccaudill We can change the name of layers accordingly but I'm concern about the State (NJ, OK, AK...), because there is no input in creating dataset form that allows user to provide this info. is there another place that I can get the State from ? if not, I was thinking of creating layer in this format:

smrgeoinfo commented 9 years ago

is it possible/practical to check if a service for a given feature type is already offered and if so, ask user for a meaningful prefix for the service URL, suggesting that it be a state abbreviation or other 2 or 3 letter location abbreviation. This would be option 4. to add to the list in the opening of this comment

ccaudill commented 9 years ago

We discovered that a new workspace must be created for each layer created in GeoServer for a different and valid WFS/WMS URL. This is why the GINstack is not a good option for hubs! Only if you have multiple GeoServer instances with different URLs can you host the same tier 3 data from different states. Also, you cannot change the name of the layer or the web service WILL NOT validate against the schema. Making the workspace name different is the only option here I think.

JihadMotii-REISys commented 9 years ago

@ccaudill seems correct and that's why I already made this changing here https://github.com/REI-Systems/ckanext-geoserver/commit/3d7206f5ae8cda867a2f323c1b4e5107ae788f3a (Create a new workspace for each layer). @ccaudill @smrazgs Implementing option 4. seems great and changing name applies only to workspace not layer, right ?

JihadMotii-REISys commented 9 years ago

@smrazgs @ccaudill : I've done the changing which is adding prefix to workspace name but geoserver doesn't allow to create multiple workspaces using the same NamespaceURI which is the link to validate the layer. Also, I've managed to change the link by adding a (#name_workspace) at the end (which i believe it won't affect anything) just to be able to get the worksapce created by geoserver. After that I was able to create multiple workspaces using the same link, I tried publishing WMS/WFS resources for the same content model layer (e.g WellLog) for different states, these OGC (WFS/WMS) resources were successfully published and shown then I tried to validate WFS resource for each dataset and it seems it didn't go well because of the link has (#name_worskapce). So, As discussed with @smrazgs I'll create an action (API) in ckan that will communicate between ckan and geoserver in order to remove the (#name_workspace) before delivering the XML output to user instead of hitting geoserver directly.

JihadMotii-REISys commented 9 years ago

@ccaudill @smrazgs I've managed to make geoserver run as multiple instances instead of one by adding an action in CKAN that communicate with geoserver and get all XML from OGC Services then apply all changing necessary after that, we serve it to user. With this, now we can create different workspaces having the same layer and a unique Namespace URI which is (Unique URI in geoserver for Layer's Schema ) Please, test all WFS/WFS actions including WFS Validation:

I tested for WellLog and it everything works fine including WFS Validation for this one. But, when you validate Borehole dataset, Only WFS Validation doesn't get validated because of the empty fields and as discussed with @smrazgs, he will see why its not getting validated for borehole and it's getting validated for WellLog.

For Borehole: http://uat-ngds.reisys.com/dataset/indiana-borehole-temperatures-wfs-1-1-0

Fix: https://github.com/ngds/ckanext-ogcpreview/issues/3, https://github.com/ngds/ckanext-ngds/issues/596 Commits on other extensions: https://github.com/REI-Systems/ckanext-ogcpreview/commit/a67b66e33cf84ebb476e3708e4b4bdd5d2711d1c https://github.com/REI-Systems/ckanext-ngds/commit/0236561f0993ec3208bf47b6d79bf2db1d80b6bc