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

Support spatial 'type':'envelope' in JSON harvest sources #5003

Open
1 task
tdlowden opened this issue Dec 5, 2024 · 3 comments
Open
1 task

Support spatial 'type':'envelope' in JSON harvest sources #5003

tdlowden opened this issue Dec 5, 2024 · 3 comments
Labels
bug Software defect or bug geospatial H2.0/Harvest-General General Harvesting 2.0 Issues

Comments

@tdlowden
Copy link
Member

tdlowden commented Dec 5, 2024

User Story

In order to abide by the documentation for DCAT-US 1.1, Charlotte data providers wants the harvester to support spatial 'type':'envelope' .

Acceptance Criteria

  • GIVEN a JSON source is harvested by the harvester
    AND the DCAT-US documentation states spatial needs to be in Geo Markup format
    WHEN a harvest source contains spatial 'type':'envelope',
    THEN the record should not error
    AND the dataset should be successfully harvested and added to the catalog

Background

https://data.charlottenc.gov/data.json contains records in the format of spatial 'type':'envelope', which currently error when harvests happen:

ERROR #3: 'spatial':{'coordinates': [[-81.0227, 35.0168], [-80.5986, 35.5124]], 'type': 'envelope'} is not valid under any of the given schemas.

The current harvester logic appears to only accept polygon type spatial fields:

https://github.com/ckan/ckanext-spatial/blob/master/ckanext/spatial/harvesters/base.py#L187

We need to update the logic to accept the envelope type

Security Considerations (required)

NA

Sketch

TBD

@tdlowden tdlowden added the bug Software defect or bug label Dec 5, 2024
@tdlowden tdlowden moved this to 📥 Queue in data.gov team board Dec 5, 2024
@tdlowden tdlowden added the H2.0/Harvest-General General Harvesting 2.0 Issues label Dec 5, 2024
@Bagesary
Copy link

Bagesary commented Dec 5, 2024

Saving this ticket to support envelope requirements in harvester 2.0

@jbrown-xentity
Copy link
Contributor

As an aside, the logic is actually here: https://github.com/GSA/ckanext-geodatagov/blob/main/ckanext/geodatagov/logic.py#L445-L515
We already munge the spatial field into what ckanext-spatial expects, so it would be adding this use case.
I think it's fine to wait for harvest2.0. Tagging @rshewitt for assessment, but similar logic might need to be built into H2.0 CKAN transformation. Most of that function could possibly be copied wholesale, and the specific additions mentioned in this ticket added.

@tdlowden
Copy link
Member Author

tdlowden commented Dec 9, 2024

So what you are saying, @jbrown-xentity, is that doing this logic work now would also be of service to the H2.0 logic and would not be work ultimately lost in transition? If so, I may advocate to re-prioritize this ticket because yet another org (wake county) attempting to have a valid harvest source has hundreds of these same errors.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Software defect or bug geospatial H2.0/Harvest-General General Harvesting 2.0 Issues
Projects
Status: 📥 Queue
Development

No branches or pull requests

4 participants