You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I created 4 different versions of ISO metadata with link URLs to compare the portal behavior. Three of them are ISO 19115-2 and have the links either in distributorTransferOptions or transferOptions or both. In all cases, the portal is not displaying all the links.
For the one with links only in distributorTransferOptions (which is the original location as produced by a NOAA on-line metadata tool), a KML shows up as an "Open" link. This is a bit unexpected, because with a previous test of ISO 19115:2003 metadata, no links in distributorTransferOptions showed up.
For the one with links in transferOptions, (which is where links in ISO 19115:2003 metadata get pulled from), a single "Open" link shows up as well, but in this case it is a .zip file. The .zip file happens to be the first link in the list. Not sure if this is relevant or not.
With any luck, the work we did yesterday and today that was pushed to Dev this afternoon will have resolved all of the above issues.
@fishytodd has reharvested the SoundGIS WAF, and you should be able to go to the Dev server and confirm that everything is working how you expect.
I also resolved the CSV bug we were seeing yesterday, and tightened down how 'OPEN' is being applied. We should have a lot fewer false 'OPEN' links now.
Please test your records on Dev and let us know if you see any more weirdness...
Looking at these original test records again, I think I've confirmed that testable link types for data/services are correctly being detected and displayed.
The exception is the last example showing loss of links like .html and root URLs that should be displaying the OPEN label.
Given this, I would like to close this original issue, and focus the remainder of the problem on the correct detection of non-data non-service links and subsequent correct application of the OPEN label.
Issues relating to remaining OPEN problems are: #9, #42, #44
Sounds good @tchaddad. For the "record" it would be extremely to have some idea of what changes you applied to make these work. So, in the future, if others might be able to do similar things. Maybe a good tidbit for the knowledge base!
I created 4 different versions of ISO metadata with link URLs to compare the portal behavior. Three of them are ISO 19115-2 and have the links either in distributorTransferOptions or transferOptions or both. In all cases, the portal is not displaying all the links.
See: http://wcga-vm01.sdsc.edu/discover/#?s=Sound%20GIS%20Test&text=ISO%2019115
For the one with links only in distributorTransferOptions (which is the original location as produced by a NOAA on-line metadata tool), a KML shows up as an "Open" link. This is a bit unexpected, because with a previous test of ISO 19115:2003 metadata, no links in distributorTransferOptions showed up.
For the one with links in transferOptions, (which is where links in ISO 19115:2003 metadata get pulled from), a single "Open" link shows up as well, but in this case it is a .zip file. The .zip file happens to be the first link in the list. Not sure if this is relevant or not.
Using the ISO 19115:2003 metadata template from Tanya, more links show up, but not all of them. It captures the .zip file and the KML, but two URLs do not show up: http://sccoos-obs0.ucsd.edu/thredds/SASS/catalog.html and http://www.sccoos.org/query/
When I look at these records directly in Geoportal, they are exhibiting the same behavior.
This issue may be related to #23 and #31
The text was updated successfully, but these errors were encountered: