Closed fire-bot closed 4 years ago
It's certainly possible for a GetFeatureInfo request on a WMS to have this sort of output.
For example the following is GetFeatureInfo on a radon WMS, that links to reports:
The service endpoint for this to test in EGDi would be:
http://ogc.bgs.ac.uk/cgi-bin/BGS_BGS-HPA_Radon_Potential/wms?
Here's another example
for a request on a WMS of reports and map sheets like below (this is GetMap only output to illustrate WMS data):
Service endpoint to try with is:
So looking at the _testdata_point_TA-4_PA-Viennashort shapefile data, there is no attribute in the data to link to any report. For a GetFeatureInfo request to work there must be some link (exact report name) in the feature for which information is requested.
Considering the tabular nature of the mini reports though it's a pity that the information reported isn't also available as attribute in the WMS/WFS itself. That way the data would be more widely accessible and reusable.
Hi Edd, Mistaken me for Martin Hansen Cheers Martin
On 18.05.2020, at 12:22, KoalaGeo notifications@github.com wrote:
Assigned #253 to @schmar00.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe.
So this is what I did with the data:
I ignored the shapefile as there was no attribution, and the coordinates also didn't quite match the location specified in the reports.
I created a CSV in Excel of the information presented in the three PDFs, (I also grabbed the images held in the reports)
I loaded the CSV in QGIS as a text delimited file, using the latitude/longitude values specified in the reports as the point coordinates. I then exported as spatialite database.
Using the spatialite database as the data source I created a WMS and simple feature WFS using MapServer on a public development web server.
The end point for both services is: http://ogcdev.bgs.ac.uk/cgi-bin/MUSE/ows?
For the WMS I styled the points on the Shallow geothermal energy system attribution: Below image shows the WMS in QGIS with applied style.
A WMS GetFeatureInfo request on a point in the map gives an HTML response that looks like the PDF report, including images. It also links to the original report.
An example GetFeatureInfo request (HTML) is:
Note I've added debugging output so you can also see a related WFS query
The WFS gives multiple output formats including CSV, which takes us back (more or less) to the beginning:
This output CSV is not quite the same as the original input file as it also includes a WKT geometry column, and takes on the all lowercase attribute names of the spatialite database, but it gives an idea of the structure. It doesn't follow any data model.
The same WMS loaded in the EGDI platform
We have finished the discussion by email. We will sent a revised version of this dataset shortly for a final revision before we create the final dataset that will be uploaded to EGDI.
Thanks for all the help!!
Adding in the email conversation for completeness
-----Original Message----- From: David Garcia Sent: 20 May 2020 14:02 To: Passmore, James H.; Martin Hansen Cc: Steiner, Cornelia; Götzl, Gregor; Claus Becher Ditlefsen Subject: RE: Question from MUSE and first dataset for testing
Hi again James,
Thank you very much for this very comprehensive answer!! It helps a lot.
I will rework the file in the way you suggest and see with my partners from MUSE how we can improve this dataset following your recommendations. I'll send the revised version back to the support at geoera.eu as soon as we have it ready for a second revision before we start creating the final dataset.
Martin Hansen, please, let us know in the course of next week if you have any extra comment on this. Thanks!!
Regards,
David.
PS. I will paste this conversation in the GitHub to have a track of it in there. Cheers!
-----Original Message----- From: Passmore, James H. Sent: 20 May 2020 13:15 To: David Garcia ; Martin Hansen Cc: Steiner, Cornelia ; Götzl, Gregor ; Claus Becher Ditlefsen Subject: RE: Question from MUSE and first dataset for testing
Hi David,
I've invited you to the GitHub pages so you can participate directly.
I'm not sure I can answer all your questions, because to some extent I am also in the dark as to the process by which data that is uploaded or harvested will be stored, managed, and turned into a services that can be consumed in the EGDI portal and made available to a wider audience. In the issue raised by Ed from your original email I just tried to address the question as to whether your test data (shapefile and three pdfs) would allow a WMS to be setup (implicit because the question was about a GetFeatureInfo operation, which is an operation of a WMS), and allow a user to click on a map to get a report. The answer to that question is no, a non-attributed shapefile (or any other format) is no good.
I also too wanted to show that the principle of using a WMS and the GetFeatureInfo operation to get at reports was sound, so I created a CSV with the information gleaned out of the reports, and used that as my initial data input. The WMS (and also WFS) service is public and can be used in any client that supports those interface standards, so it works in EGDI and QGIS and the OneGeology portal etc. Also as EGDI are using MapServer as the OGC service software, and my test service also uses MapServer, you should expect that the service created by EGDI with your data should look and behave in a similar fashion.
So to your general understanding
(1) It's not a recommendation but a requirement; if you want to use a GetFeatureInfo request to link to a report you MUST have a reference to that report. I would recommend just the name of the report (not any path). The template that the GetFeatureInfo request uses to construct the response will be able to add or construct the correct URL.
(2) Yes, it's highly recommended to include all the tabular data from the reports, that way it can be accessed and queried through services. It may be a requirement for INSPIRE compliance, but let's park that for a moment.
To your exact questions (in reverse order).
(2) The WMS I created works in the EGDI portal. I am not in a position to test loading the data into the EGDI database. Anyone testing should be able to use one of the output formats from my created WFS to test in principle.
(1) INSPIRE compliance is more nuanced, for the dataset itself you will need the appropriate codelists and terms, however if the data doesn't fit exactly within an INSPIRE data model you won't be able to achieve full compliance. You will need to have metadata for your data, and also there will need to be metadata for the services (the latter is quite easy to configure with MapServer as in the below examples [A] WMS with INSPIRE extended capabilities and [B] auto-generated service metadata
[A] http://ogcdev.bgs.ac.uk/cgi-bin/MUSE/ows?SERVICE=WMS&VERSION=1.3.0&REQUEST=GetCapabilities
[B] http://ogcdev.bgs.ac.uk/cgi-bin/MUSE/ows?language=eng&request=GetMetadata&layer=MUSE_TEST_slite
To my mind the best input format for your data will be CSV. You can follow my CSV as an example, I would recommend have an explicit column for latitude, and another for Longitude, rather than a comma separated list (and also specify which CRS/datum is used). I guessed EPSG:4326 with your data. Column names should not have spaces, and avoiding square brackets would also be helpful (as they have a special meaning in MapServer templates). For INSPIRE (or any other code lists) the column name should be an exact match for the code list name, so if you were using the 'Aquifer Type` code list for values (https://inspire.ec.europa.eu/codelist/AquiferTypeValue https://inspire.ec.europa.eu/codelist/AquiferTypeValue ) the column name should be "AquiferTypeValue".
Hope that helps
James
-----Original Message-----
From: David Garcia
Sent: 20 May 2020 10:25
To: Passmore, James H.; Martin Hansen Cc: Steiner, Cornelia ; Götzl, Gregor ; Claus Becher Ditlefsen
Subject: RE: Question from MUSE and first dataset for testing
Hi James,
Thanks for your email!! I am not subscribed to GeoERA-GIP Project-Support-WP8 GitHub pages. How can I do that to receive notifications? Should I just inscribe myself?
Thank you very much for taking the time to test the data!! I appreciate your technical explanation and the examples. However, I am not sure that I understand what we (MUSE) should do in a practical way to improve this dataset so it complies with international standards and it is plot/shared correctly in EGDI. In addition, I am not sure that the solutions to link and plot the reports you show in your example are those that will be applied in EGDI. Please, be aware that our technical knowledge on these issues is limited. We do not need to know the specifics of how EGDI will deal with this. We just need to know what EGDI expects from us, so the datasets we sent follow EGDI regulations in terms of standards, etc., and so that the functionalities we require for them can be applied properly.
Here below, a summary of what I understood from your comments in GitHub. Please, correct me if I am wrong. Please, note that we will not create web services ourselves to share this dataset with EGDI. Instead, we will upload it directly into EGDI database as a GIS file (GeoPackage). It will be up to the GIP-P to process the data (e.g., create WFS, etc.) to plot it in the EGDI portal.
You recommend to include an attribute in the GIS file with the name of the report to hyperlink it to the URI of that report, which, I guess, will be generated by EGDI document repository.
You recommend to include the tabular information included in the report as attributes in the GIS file.
Here some specific questions:
If we include the information from the report in the attributes; how do we do that so the file is INSPIRE compliant? Should we take the CSV you created as a template? if you like, I can give it a try myself and send you a GIS file with the tabular data in the attributes, with the attributes compliant with INSPIRE codes hyperlinked to their respective INSPIRE URI, and those that are not INSPIRE compliant accompanied by definitions in a structured project vocabulary. Would that work?
Can we test it in EGDI database and document repository, so we see exactly how the functionality to plot and download the reports will work?
Thank you very much!!
Regards,
David.
-----Original Message-----
From: Passmore, James H. Sent: 19 May 2020 17:24
To: David Garcia Subject: Question from MUSE and first dataset for testing
David,
I'm not sure if you are subscribed to the GeoERA-GIP Project-Support-WP8 GitHub pages. Ed posted this below issue, and I've been merrily commenting, but not sure how this gets back to MUSE and yourself.
https://github.com/GeoEra-GIP/Project-Support-WP8/issues/253
James
Sent by David Garcia. Created by fire.
Dear Martin and GIP-P support team,
I am writing to you today as a MUSE partner. I have a request for you:
Martin Hansen: We sent you several months ago a test dataset (see in attachments) for testing the functionality "From getfeatureinfo creation of an automatic report querying a selection of layers" and see how that dataset will look in EGDI (see email below). However, we never got a feedback from you because the document repository was still under construction. During our recent bilateral meetings with other projects, I understood that the document repository is not finish, but we can already do some testing. Hence, I was wondering if you could give our request a try and provide a feedback. Is that possible? If so, how do you recommend to do that testing? E.g., should we upload the pdfs to the Doc Rep providing metadata, etc. and then you establish the link to the spatial data or you do everything yourself as a test?
support@geoera.eu: This dataset is in the final form that will be delivered. Hence, I was wondering if you could have a look and let us know if it is OK concerning data standardization, formats, etc. In principle, this is a simple file consisting of a GIS file (in this case a shapefile – we can also deliver it in GeoPackage format) containing points, which will go to EGDI database and which define the location of geothermal installations. Those points will be linked to PDFs (in attachments), which contain all the information we want to share from those locations. Hence, (at least the GIP-P recommend otherwise) the GIS file will not contain any attribute. The idea is that when an user clicks on a point, a window will pop-up showing the information contained in the PDF linked to that location. Could you, please, let us know your opinion? Is that OK concerning standards, etc.? Otherwise, could you, please, provide some advice on how we could improve this dataset to make it compatible with EGDI regulations?
Thank you in advance!
David.
From: David Garcia
Sent: 27 February 2020 17:09
To: Martin Hansen Cc: J�rgen Tulstrup; Steiner, Cornelia Subject: Question from MUSE and first dataset for testing functionality "From getfeatureinfo creation of an automatic report querying a selection of layers"
Dear Martin,
How are you? I have a question/requirement and a first dataset for testing from MUSE.
Question:
My colleagues from MUSE are wondering whether it would be possible to link the fact sheets they have generated from each pilot area (available at https://geoera.eu/projects/muse3/pilot-urban-areas-in-the-muse-project/) to the respective polygons defining each pilot area in the webGIS of GeoERA/MUSE (https://data.geus.dk/egdi/?mapname=egdi_geoera_muse#baslay=null&optlay=&extent=701260,973940,5537170,3851000&layers=muse_project_areas_region). Would that be possible?
Testing:
We (MUSE) have our first product (almost) ready, but before producing the final version, we would like to test one of the datasets to be sure that EGDI meets our expectations and vice versa. We were therefore wondering if you could upload the shapefile here attached and test the functionality "From getfeatureinfo creation of an automatic report querying a selection of layers" by linking each point included in the shapefile to its respective PDF factsheet (also in attachments). Could you do that and get back to us to see how that test goes?
Many thanks in advance!
David.
Attachments: