Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Additional Link Display Issues - ISO metadata #37

Closed
cybersea opened this issue Feb 12, 2015 · 3 comments
Closed

Additional Link Display Issues - ISO metadata #37

cybersea opened this issue Feb 12, 2015 · 3 comments
Assignees

Comments

@cybersea
Copy link

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

@tchaddad
Copy link

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...

@tchaddad
Copy link

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

@cybersea
Copy link
Author

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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants