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

Standardize recommended format for 'spatial coverage' #22

Open
rmseifried opened this issue Jun 3, 2021 · 3 comments
Open

Standardize recommended format for 'spatial coverage' #22

rmseifried opened this issue Jun 3, 2021 · 3 comments
Labels
documentation Improvements or additions to documentation

Comments

@rmseifried
Copy link
Member

Per discussion in the metadata interest group - it might be helpful to standardize the field dct_spatial_sm (Spatial Coverage). Current documentation recommends using GeoNames as a thesaurus and formatting as: "Philadelphia, Pennsylvania, United States."

These are other formats that are in use in the community:

For U.S. / Canada / Australia:

  • city, state/province
  • county, state/province
  • state/province

For non-U.S.:

  • city, country
  • region/province, country
  • country

Factors to consider:

  • Including "United States" can be too wordy and is often omitted for items within US unless they are truly nation-wide
  • Several institutions are using custom scripts to automate GeoNames extraction, but there are multiple levels (fcodes) which could be used to build this field and each institution is using different combinations. Example for GeoNames ID 5190404:
    • PPL = Franklinville
    • ADM3 = City of Philadelphia
    • ADM2 = Philadelphia County
    • ADM1 = Pennsylvania
    • PCLI = United States
  • The dct_spatial_sm field can take multiple values in order to reference these different scales as separate geographic entries, e.g.: "dct_spatial_sm": [ "Franklinville, PA", "City of Philadelphia, PA", "Philadelphia County, PA" ]
  • Using URIs instead of string text would provide consistency, disambiguate duplicated place names, and might allow referencing multiple sources (e.g. LC and GeoNames); the URIs could be used in faceting but a different label shown in the UI
@kgjenkins
Copy link
Collaborator

kgjenkins commented Jun 4, 2021

We should also consider the different ways that users will interact with this information:

  • search: text of a user query is used to find matching records
  • filter: users can view (and sort) a list of values and may select one or more values
  • item display: user will see the placename when viewing details for a single item, and (depending on the GBL configuration) may click a linkified value to search for matching records

@rmseifried rmseifried transferred this issue from OpenGeoMetadata/metadata-issues Sep 10, 2021
@rmseifried rmseifried transferred this issue from geoblacklight/geoblacklight Dec 2, 2021
@rmseifried rmseifried added the documentation Improvements or additions to documentation label Feb 14, 2022
@dl-maura
Copy link

"Using URIs instead of string text would provide consistency" this would be a new field

@karenmajewicz
Copy link
Collaborator

Note: BTAA adopted the FAST ID format, (Wisconsin--Madison)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
Status: To Do
Development

No branches or pull requests

4 participants