Closed rsignell-usgs closed 7 years ago
@rsignell-usgs the FGDC example dataset "Idaho dataset" provided above is correct, if metadata is provided in the similar format it should get displayed in data.gov with WMS map link
The data provider of this dataset: http://catalog.data.gov/dataset/agroclimate-zones-for-idaho has reenabled the WMS and WCS services for this dataset and now when I click the WMS link, I get a map that is clearly not the agro climate zones for idaho:
Going to the "Advanced Viewer" link, we can see the problem: the "Koppen Climate Classification" layer is selected rather than the "Agroclimate Zones" layer:
If we select the "Agroclimate Zones" layer, we indeed get an image of the data that this dataset represents:
So the question is: how should we specify the WMS layer name in FGDC metadata so that the correct layer will be displayed in the data.gov map viewer?
@kvuppala, any ideas here?
If we know the answer to this, we can fix a LOT of datasets....
@amilan17, have you got any great ideas here? Is there an ISO example of specifying a WMS layer name (or multiple layer names) so that the WMS services could be matched to the data in the dataset?
There are actually two issues here. Where does data.gov look for data access points. Usually in metadata, the digital data access is listed in the digform section as shown above. in my experience, however, data.gov is only looking for data access in the on-line resources section. I have been putting it in both places to cover my bases..
As far as how to list access to data services, i lean toward pointing directly to the data using the GetMap call instead of the GetCapabilities. If done correctly the call can be used to generate a graphic that can be useful in the search, whereas a service description (depending on what is in your service) is not able to focus on the data your looking for. Some argue that WMS services should have separate metadata. I disagree. if someone finds a metadata record for data they are looking for, all points of access should be listed in that record (and not have to search elsewhere to see if there is WMS access to the data). An online resource I have used to 'figure out' is at https://www.geoplatform.gov/sites/default/files/document_library/MetadataPractices07-2013_Linked_0.pdf
@gmiller-usgs, awesome. Let me try to summarize your suggestions:
getMap
request instead of a getCapabilities
request, which will by necessity include the layer name@gmiller-usgs @rsignell-usgs Data.gov looks for resource links in on-line resources section and I also know that digform section networka links are also added as part of the resources, could provide an example metadata record of the two places / sample links you are referring to , we can make sure to add all the necessary links if they are not happening already.
CC @philipashlock @rebeccawilliams
Unfortunately, I no longer have access to the harvest results, so I have a hard time figuring out what is getting pulled in or not. The only way I have to get the info in, is to use the shotgun approach and hope something sticks. I will see if I can find one that isn't 'fixed' yet..
@gmiller-usgs , how about this one? http://cmgds.marine.usgs.gov/metadata/8406.xml
@gmiller-usgs, in the dataset at http://cmgds.marine.usgs.gov/metadata/8406.xml, we find:
<digform>
<digtinfo>
<formname>Interactive Mapping Application</formname>
<formcont>Online application available to view map services</formcont>
</digtinfo>
<digtopt>
<onlinopt>
<computer>
<networka>
<networkr>http://cmgds.marine.usgs.gov/geoserver/bathy/wms?service=WMS&version=1.1.0&request=GetMap&layers=bathy:2008-1288_bathy&styles=&bbox=366025.999733,4573362.199733,373517.999563,4578707.626581&srs=EPSG:4326</networkr>
</networka>
</computer>
<accinstr>Use this URI to view the map service using an online interactive mapping application</accinstr>
</onlinopt>
</digtopt>
</digform>
And if I add &WIDTH=256&HEIGHT=256&FORMAT=image%2Fpng
onto the end of that URL, I get this URL:
http://cmgds.marine.usgs.gov/geoserver/bathy/wms?service=WMS&version=1.1.0&request=GetMap&layers=bathy:2008-1288_bathy&styles=&bbox=366025.999733,4573362.199733,373517.999563,4578707.626581&srs=EPSG:4326&WIDTH=256&HEIGHT=256&FORMAT=image%2Fpng
which produces the following image:
I couldn't find one that would successfully harvest all the way, so I took one that was harvested successfully and added the link. We will have to wait until ScienceBase harvests it and it gets propagated up to data.gov..
On Apr 15, 2015, at 3:48 PM, Rich Signell notifications@github.com wrote:
@gmiller-usgs , how about this one? http://cmgds.marine.usgs.gov/metadata/8406.xml
— Reply to this email directly or view it on GitHub.
@gmiller-usgs any update?
@gmiller-usgs after the harvesting this morning... it's now there on data.gov!
I searched on "WMS format" and "mvco".
The only slight marring of my excitement was that the WMS image preview doesn't work. But I think maybe there could be a fix...
The WMS URL is listed as: http://cmgds.marine.usgs.gov/geoserver/bathy/wms?service=WMS&version=1.1.0&request=GetMap&layers=bathy:2008-1288_bathy&styles=&bbox=366025.999733,4573362.199733,373517.999563,4578707.626581&srs=EPSG:4326
And when I drop that into a browser, I get back: http://cmgds.marine.usgs.gov/geoserver/bathy/wms?service=WMS&version=1.1.0&request=GetMap&layers=bathy:2008-1288_bathy&styles=&bbox=366025.999733,4573362.199733,373517.999563,4578707.626581&srs=EPSG:4326&WIDTH=256&HEIGHT=256&FORMAT=image/
where you can see that <&WIDTH=256&HEIGHT=256&FORMAT=image/> got appended to the URL. I gather these are defaults supplied by the CMG MapServer?
Unfortunately that is not a valid get map request, but if we change
then we get have a valid WMS request and get an image back.
So would data.gov display the WMS image correctly, what if we changed the URL in the metadata from this partial WMS getMap request:
to this fully-valid WMS getMap request :
It seems this would be better, because the valid URL would return an image in a browser, and yet a client like the data.gov viewer could still just strip off the WIDTH, HEIGHT and FORMAT (and whatever else it wanted to) from the URL and request something different.
@lzolly-usgs, thanks for the help on this!
I have updated the metadata record with the new WMS link. Lets see how it does on the next harvest
@lzolly-usgs, can you please force a reharvest so we can test this out?
Okay, the dataset has been reharvested and the WMS endpoint contains a valid map request.
We now get different behavior now when we click the "View Map" button.
But we don't get a map. We get just "loading map", which after 5 minutes is still spinning.
We will ask the GMU map viewer folks for help, once we find out from @kvuppala who to contact.
@chilukey, on this dataset, we are still getting just "loading map" Are you looking into this issue?
@chilukey, I checked again today, and this problem remains. If you go to this link:
http://catalog.data.gov/dataset/bathy-2m-asc-asc-bathymetric-data-collected-by-the-u-s-geological-survey-off-the-southern-shore
and click the view map
icon, the map never loads.
Hi Rich,
I am looking into it. In addition, I am uploading the viewer code to use a small database to enable loading big service quickly.
On Tue, May 5, 2015 at 9:08 AM, Rich Signell notifications@github.com wrote:
@chilukey https://github.com/chilukey, I checked again today, and this problem remains. If you go to this link:
http://catalog.data.gov/dataset/bathy-2m-asc-asc-bathymetric-data-collected-by-the-u-s-geological-survey-off-the-southern-shore and click the view map icon, the map never loads.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99073521.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
@chilukey, excellent. Thanks.
Hi Rich,
This WMS should be able to loaded now. When you click to view map, it zoom to the default layer automatically, and wait for some seconds, the layer will appear
On Tue, May 5, 2015 at 10:41 AM, Rich Signell notifications@github.com wrote:
@chilukey https://github.com/chilukey, excellent. Thanks.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99099985.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
@chilukey, whoa, what's doing on here? When I click the WMS link, I do indeed get a map, but it's not the right dataset!? How can that possibly be? Here's what I get:
but if you click the WMS URL above the map, you get what it actually should be, which is this:
Hmmm... All I get is timed out.
@gmiller-usgs , did you try chrome or firefox? Chrome timed out for me, while firefox returned wrong image. Bizarre!
Hi Rich,
Oh, I see. You only need that layer. I thought to load the entire WMS.
I will update to load that layer only.
On Wed, May 6, 2015 at 3:11 PM, Rich Signell notifications@github.com wrote:
@chilukey https://github.com/chilukey, whoa, what's doing on here? When I click the WMS link, I do indeed get a map, but it's not the right dataset!? How can that possibly be? Here's what I get: [image: 5-6-2015 3-08-41 pm] https://cloud.githubusercontent.com/assets/1872600/7501447/ff8aa40e-f401-11e4-93e5-fe6a70d15720.png
but if you click the WMS URL above the map, you get what it actually should be, which is this: [image: bathy-2008-1288_bathy] https://cloud.githubusercontent.com/assets/1872600/7168410/412779fa-e38b-11e4-8c3f-cd9d1a5ed131.png
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99577584.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
@chilukey , ah, okay, well at least we understand the problem now. Yes, the reason we supplied a getMap request instead of getCaps is because we want to display this specific dataset. The advanced viewer could load the entire WMS.
Rich and gmiller-usgs, Could you please clear the cache? then it should work. Since it maybe still use the cached javascript file so shows timeout.
Rich,
Thanks for the explain and I understand it now. I will update accordingly.
On Wed, May 6, 2015 at 3:22 PM, Rich Signell notifications@github.com wrote:
@chilukey https://github.com/chilukey , ah, okay, well at least we understand the problem now. Yes, the reason we supplied a getMap request instead of getCaps is because we want to display this specific dataset. The advanced viewer could load the entire WMS.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99579582.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
@chilukey , yes, clearing the cache (and cookies, just for good measure) in Chrome worked. It does not time out and shows the same result as Firefox.
Yes, it is the same for me with all my browsers; the wrong image comes up.
On Wed, May 6, 2015 at 3:29 PM, Rich Signell notifications@github.com wrote:
@chilukey https://github.com/chilukey , yes, clearing the cache (and cookies, just for good measure) in Chrome worked. It does not time out and shows the same result as Firefox.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99580970.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
Hi Greg,
The wrong image is the other layer in the same WMS since I loaded the entire WMS instead of the request layer. I am changing to load only the request layer.
On Wed, May 6, 2015 at 3:41 PM, Greg Miller notifications@github.com wrote:
Yes, it is the same for me with all my browsers; the wrong image comes up.
On Wed, May 6, 2015 at 3:29 PM, Rich Signell notifications@github.com wrote:
@chilukey https://github.com/chilukey , yes, clearing the cache (and cookies, just for good measure) in Chrome worked. It does not time out and shows the same result as Firefox.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99580970.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99583519.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
Hi Rich and Greg,
The viewer can now load the getMap layer, e.g,
However, in the required layer of the following link, the srs is 'EPSG:4326', but the bbox is using 'meter' rather than the longitude and latitude. The bbox shifts a lot from the EPSG:4326 boundingbox (-180,-90,180,90) so it can not be loaded correctly. Do you have any idea?
On Wed, May 6, 2015 at 3:43 PM, Kai Liu kliu.gis@gmail.com wrote:
Hi Greg,
The wrong image is the other layer in the same WMS since I loaded the entire WMS instead of the request layer. I am changing to load only the request layer.
On Wed, May 6, 2015 at 3:41 PM, Greg Miller notifications@github.com wrote:
Yes, it is the same for me with all my browsers; the wrong image comes up.
On Wed, May 6, 2015 at 3:29 PM, Rich Signell notifications@github.com wrote:
@chilukey https://github.com/chilukey , yes, clearing the cache (and cookies, just for good measure) in Chrome worked. It does not time out and shows the same result as Firefox.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99580970.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99583519.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
The error is in my URL. The bounds are in UTM and I'm saying geographic. Give me a few minutes to sort it out
On Thu, May 7, 2015 at 9:25 AM, Kai Liu notifications@github.com wrote:
Hi Rich and Greg,
The viewer can now load the getMap layer, e.g,
However, in the required layer of the following link, the srs is 'EPSG:4326', but the bbox is using 'meter' rather than the longitude and latitude. The bbox shifts a lot from the EPSG:4326 boundingbox (-180,-90,180,90) so it can not be loaded correctly. Do you have any idea?
On Wed, May 6, 2015 at 3:43 PM, Kai Liu kliu.gis@gmail.com wrote:
Hi Greg,
The wrong image is the other layer in the same WMS since I loaded the entire WMS instead of the request layer. I am changing to load only the request layer.
On Wed, May 6, 2015 at 3:41 PM, Greg Miller notifications@github.com wrote:
Yes, it is the same for me with all my browsers; the wrong image comes up.
On Wed, May 6, 2015 at 3:29 PM, Rich Signell notifications@github.com wrote:
@chilukey https://github.com/chilukey , yes, clearing the cache (and cookies, just for good measure) in Chrome worked. It does not time out and shows the same result as Firefox.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99580970.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99583519.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99863355.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
I hadn't realized that this layer was UTM. The above URL should translate it as best it can to geographic. I will edit the metadata record for the new URL.
Greg
On Thu, May 7, 2015 at 9:39 AM, Miller, Gregory gmiller@usgs.gov wrote:
The error is in my URL. The bounds are in UTM and I'm saying geographic. Give me a few minutes to sort it out
On Thu, May 7, 2015 at 9:25 AM, Kai Liu notifications@github.com wrote:
Hi Rich and Greg,
The viewer can now load the getMap layer, e.g,
However, in the required layer of the following link, the srs is 'EPSG:4326', but the bbox is using 'meter' rather than the longitude and latitude. The bbox shifts a lot from the EPSG:4326 boundingbox (-180,-90,180,90) so it can not be loaded correctly. Do you have any idea?
On Wed, May 6, 2015 at 3:43 PM, Kai Liu kliu.gis@gmail.com wrote:
Hi Greg,
The wrong image is the other layer in the same WMS since I loaded the entire WMS instead of the request layer. I am changing to load only the request layer.
On Wed, May 6, 2015 at 3:41 PM, Greg Miller notifications@github.com wrote:
Yes, it is the same for me with all my browsers; the wrong image comes up.
On Wed, May 6, 2015 at 3:29 PM, Rich Signell <notifications@github.com
wrote:
@chilukey https://github.com/chilukey , yes, clearing the cache (and cookies, just for good measure) in Chrome worked. It does not time out and shows the same result as Firefox.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99580970.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99583519.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99863355.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
On Thu, May 7, 2015 at 9:59 AM, Miller, Gregory gmiller@usgs.gov wrote:
I hadn't realized that this layer was UTM. The above URL should translate it as best it can to geographic. I will edit the metadata record for the new URL.
Greg
On Thu, May 7, 2015 at 9:39 AM, Miller, Gregory gmiller@usgs.gov wrote:
The error is in my URL. The bounds are in UTM and I'm saying geographic. Give me a few minutes to sort it out
On Thu, May 7, 2015 at 9:25 AM, Kai Liu notifications@github.com wrote:
Hi Rich and Greg,
The viewer can now load the getMap layer, e.g,
However, in the required layer of the following link, the srs is 'EPSG:4326', but the bbox is using 'meter' rather than the longitude and latitude. The bbox shifts a lot from the EPSG:4326 boundingbox (-180,-90,180,90) so it can not be loaded correctly. Do you have any idea?
On Wed, May 6, 2015 at 3:43 PM, Kai Liu kliu.gis@gmail.com wrote:
Hi Greg,
The wrong image is the other layer in the same WMS since I loaded the entire WMS instead of the request layer. I am changing to load only the request layer.
On Wed, May 6, 2015 at 3:41 PM, Greg Miller notifications@github.com wrote:
Yes, it is the same for me with all my browsers; the wrong image comes up.
On Wed, May 6, 2015 at 3:29 PM, Rich Signell < notifications@github.com> wrote:
@chilukey https://github.com/chilukey , yes, clearing the cache (and cookies, just for good measure) in Chrome worked. It does not time out and shows the same result as Firefox.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99580970.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99583519.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99863355.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
Greg,
Thanks very much. I confirm the link you sent works.
It seems the baselayer I used for EPSG:4326 doesn't response now. Probably I need to change another EPSG4326 baselayer.
On Thu, May 7, 2015 at 10:01 AM, Greg Miller notifications@github.com wrote:
Sorry, it should be
On Thu, May 7, 2015 at 9:59 AM, Miller, Gregory gmiller@usgs.gov wrote:
OK the correct URL should be
I hadn't realized that this layer was UTM. The above URL should translate it as best it can to geographic. I will edit the metadata record for the new URL.
Greg
On Thu, May 7, 2015 at 9:39 AM, Miller, Gregory gmiller@usgs.gov wrote:
The error is in my URL. The bounds are in UTM and I'm saying geographic. Give me a few minutes to sort it out
On Thu, May 7, 2015 at 9:25 AM, Kai Liu notifications@github.com wrote:
Hi Rich and Greg,
The viewer can now load the getMap layer, e.g,
However, in the required layer of the following link, the srs is 'EPSG:4326', but the bbox is using 'meter' rather than the longitude and latitude. The bbox shifts a lot from the EPSG:4326 boundingbox (-180,-90,180,90) so it can not be loaded correctly. Do you have any idea?
On Wed, May 6, 2015 at 3:43 PM, Kai Liu kliu.gis@gmail.com wrote:
Hi Greg,
The wrong image is the other layer in the same WMS since I loaded the entire WMS instead of the request layer. I am changing to load only the request layer.
On Wed, May 6, 2015 at 3:41 PM, Greg Miller < notifications@github.com> wrote:
Yes, it is the same for me with all my browsers; the wrong image comes up.
On Wed, May 6, 2015 at 3:29 PM, Rich Signell < notifications@github.com> wrote:
@chilukey https://github.com/chilukey , yes, clearing the cache (and cookies, just for good measure) in Chrome worked. It does not time out and shows the same result as Firefox.
— Reply to this email directly or view it on GitHub <https://github.com/GSA/data.gov/issues/613#issuecomment-99580970 .
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99583519.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99863355.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-99877979.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
But getting closer..... :smile_cat:
@lzolly-usgs, can you push through a reharvest?
Yes, please do a reharvest.
Now I change to use EPSG:3857 to reporject the layer, and the baselayer is openstreet map. If you do a reharvest, the map view in data.gov should work.
On Fri, May 8, 2015 at 11:04 AM, Rich Signell notifications@github.com wrote:
@lzolly-usgs https://github.com/lzolly-usgs, can you push through a reharvest?
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-100264237.
Kai Liu Ph.D. student Department of Geography and GeoInformation Science George Mason University
Success! We have a map! @gmiller-usgs or @lzolly-usgs, did something improve in the data.gov harvest process that finally allowed this to work?
Unfortunately, through the years there has been varying interpretations on how best to fill out a metadata record. I am currently going through the metadata I have and editing each record to bring them into compliance with the current thinking and making sure each record passes the current version of mp for validation.
@gmiller-usgs, the FGDC metadata for this dataset used to live here: http://cmgds.marine.usgs.gov/metadata/8406.xml but this link no longer works. Where does it live now? It would be useful to show use this as a working FGDC example of how to get the right WMS layer displayed in data.gov.
It is now at http://cmgds.marine.usgs.gov/metadata/139.xml It was changed to ensure that it got harvested.
On Thu, Jun 18, 2015 at 10:56 AM, Rich Signell notifications@github.com wrote:
@gmiller-usgs https://github.com/gmiller-usgs, the FGDC metadata for this dataset used to live here: http://cmgds.marine.usgs.gov/metadata/8406.xml but this link no longer works. Where does it live now? It would be useful to show use this as a working FGDC example of how to get the right WMS layer displayed in data.gov.
— Reply to this email directly or view it on GitHub https://github.com/GSA/data.gov/issues/613#issuecomment-113184136.
Greg Miller Coastal Marine Geology US Geological Survey
508 287-7610 gmiller@usgs.gov
@hkdctol @JJediny Closing this, seems to be resolved
Where should the WMS endpoint go in FGDC metadata to properly appear in data.gov?
There are quite a few datasets in data.gov from our USGS seafloor mapping group here in Woods Hole that don't have WMS endpoints, and we would like to get them in there.
An example is this CABATH5M - 5 meter ArcRaster Bathymetric grid that only has
zip
andhtml
links. This is understandable, since the original FGDC metadata doesn't have any WMS links!We would like to populate the appropriately specify the WMS endpoint in the FGDC metadata so that it gets converted correctly to ISO, a WMS button appears in data.gov, and when you click on it, you get a map like the one produced by this North Dakota DEM dataset, which looks great:
Unfortunately the North Dakota dataset doesn't have an FGDC record we could use to see how to specify the WMS endpoint.
We looked for a dataset with an original FGDC record that does have a WMS link, and found this Idaho dataset, where the WMS link appears in a
<digform>
tag:So is this the proper place for the WMS endpoint to go in the FGDC metadata?
Thanks, Rich
P.S. If we click the WMS link, we get
Cannot load map
, but I think that's just because the it looks like they didn't enable the WMS services after an ESRI upgrade or something. There is no WMS service listed here anymore: http://cloud.insideidaho.org/arcgis/rest/services/climatologyMeteorologyAtmosphere/climatologyMeteorologyAtmosphere/MapServer