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

Handle Spatial Data crossing meridian appropriately #5002

Open
jbrown-xentity opened this issue Dec 4, 2024 · 8 comments
Open

Handle Spatial Data crossing meridian appropriately #5002

jbrown-xentity opened this issue Dec 4, 2024 · 8 comments
Labels
bug Software defect or bug geospatial

Comments

@jbrown-xentity
Copy link
Contributor

Example dataset here: https://catalog.data.gov/dataset/species-of-greatest-conservation-need-national-database
The geospatial extent should go from just below the equator to 70 deg north, and from a little east of japan to just east of Maine. However, if you search anywhere in the northern hemisphere west of japan and east of the US, this dataset will show up. That is because it's treating the bounding box as wrapping all the way around the united states. If you search inside the united states, it won't show up. See example within the US and in Europe

How to reproduce

  1. Harvest a dataset that has a spatial component across the meridian, like this: https://catalog.data.gov/harvest/object/05e75461-5065-4cd5-8e84-73b55fa9b870
  2. Show in spatial search that it is wrapping around the world opposite

Expected behavior

Spatial search works as expected.

Actual behavior

Spatial search doesn't work as expected.

Sketch

This is actually called out in the ckanext-spatial extension here (search for antimeridian). We need to handle this use case by building the appropriate geojson object. This will require testing.

@jbrown-xentity jbrown-xentity added the bug Software defect or bug label Dec 4, 2024
@rshewitt
Copy link
Contributor

rshewitt commented Dec 4, 2024

the gray is how the polygon is drawn and used in the spatial query. the red is what we want. the purple line is the antimeridian (+-180° to the prime meridian). based on the gray polygon, it is expected that results are returned when searching in europe and not in the US. ckan wants us to split the red polygon according to the purple line so it follows the bounding rules. the result would either be a multi-polygon or 2 separate polygons.

Screenshot 2024-12-04 at 3 59 34 PM

@rshewitt
Copy link
Contributor

rshewitt commented Dec 5, 2024

here's a relevant tool: https://github.com/gadomski/antimeridian

not suggesting using it. just something to potentially help with the problem.

@tdlowden
Copy link
Member

tdlowden commented Dec 5, 2024

so CKAN spatial acknowledges the issue, but then basically ignored it?

@jbrown-xentity
Copy link
Contributor Author

Kind of. When you have 4 points on a sphere, technically you can go either direction. We just have to be explicit. The schema is specific, but we aren't specific when translating to CKAN's spatial extension.

@FuhuXia
Copy link
Member

FuhuXia commented Dec 16, 2024

This reminds me ckan/ckanext-spatial#90. I doubt splitting the box into two is a solution.

@tdlowden
Copy link
Member

tdlowden commented Dec 16, 2024

If that's not a viable solution, we should demonstrate it. It is what is recommended in the CKAN spatial docs:

image

https://docs.ckan.org/projects/ckanext-spatial/en/latest/spatial-search/

@tdlowden
Copy link
Member

Also, it's amazing you have had this issue open since 2014, @FuhuXia !

@FuhuXia
Copy link
Member

FuhuXia commented Dec 16, 2024

The issue opened in 2014 is dealing with sending spatial query across 180° longitude line. The current ticket is related but different. it is dealing with serving spatial query results that is across 180° longitude line.

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
Projects
Status: 🧊 Icebox
Development

No branches or pull requests

5 participants