Search by extent broken

[frafra]

I get zero results from API if I search by extent. no matter how much I zoom out on the layers search page.

Current master, spc.

[t-book]

@frafra anything in logs. It´s working here: http://master.demo.geonode.org/layers/ If I remember correctly @giohappy once said this instance is a bit outdated. if it´s a regression it should be introduced after installing the demo.

what happens when you call the api directly with some extent?

[frafra]

No errors,on the server, no warning, nothing useful.

Example for the whole world: https://geodata.nina.no/api/layers/?extent=-180,-90,180,90

[t-book]

In case it´s a regression than it´s docker specific (which seams unlikely). This is an manual instance just installed just now: http://93.90.201.139/layers/ from master branch. Here it´s working.

(Have I already told you that I really like the color scheme of geodata.nina.no :))

[frafra]

Thank you for the information. It could be something Docker specific then.

The color scheme mimic the one used by the company, but the homepage needs to be improved quite a lot. Technical issues have the priority at the moment :-)

[frafra]

Ok, every layer has this value as region: "Global , Africa , Central Africa , West Africa , Pacific , Kiribati"

As Norway is not located in Africa nor in the middle of the Pacific ocean, I would say that there is an issue with determining the extent of the layers, which it could affect the search. Some layers are correctly tagged, but none of them appear using the extent filter.

[t-book]

well spotted!

[afabiani]

This is a very old issue, still there from the beginning of GeoNode... basically the search by extent works only if the native bbox is 4326, since it assumes the coordinates are lat/lon and does an fancy bbox check on the filter.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[afabiani]

up

[indeOWS]

I just installed a new instance of GeoNode@2.10.1. I have noticed the same problem. I uploaded a shapefile, but I am unable to see any layer extent over OSM BaseMap, even with Zoom IN.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[DingDingFan0207]

The issue is being TypeError: 'map' object is not subscriptable

[srtonz]

@afabiani as it stands the GeoNode front-end suggests that one can filter datasets by a map extent, which seems to be broken for the reasons you explained above. I vote to re-open this issue and either:

a) Entirely remove the "filter by extent" functionality from the frontend, or b) Figure out a usable solution

I think the most elegant solution would be to store any layer metadata in a PostGIS-enabled database, rather than a plain Postgres store. Layer bounding boxes can then be stored natively as Geometries with associated SRIDs, which would allow for lookups such as Layer.objects.filter(geom__intersects=<query bounding box>).

Benefits here would be that we can delegate the bbox lookup to the database and remove the rather complex Q() based filtering done currently, and of course that this will work with all layers regardless of their bbox projection. One can even start indexing the bbox field to make things faster.

Seeing that GeoNode already requires a secondary PostGIS database to be present and all GeoDjango dependencies, this wouldn't introduce any further dependencies for the project, other than installing PostGIS into the main datastore. I'm keen to hear what people think - and also happy to post this on the devel mailing list.

[t-book]

@GeoTob My ++1 one for

b) Figure out a usable solution

In my opinion search by extent is a great and expected feature for a SDI. Further your outlined implementation sounds good to me.

[srtonz]

We have one of the team available to tackle this in the next few weeks. The plan is something like this:

1. Set the default datastore to use PostGIS and update documentation to ensure PostGIS extensions are installed into both stores.
2. Add a "bbox" PolygonField to base.SpatialRepresentationType
3. Create a data migration to convert any existing bbox_x0...bbox_y1 & srid entries to a Polygon
4. Migrate all existing code to use the new "bbox" field instead of existing fields
5. Update any pre-existing test cases
6. Fix search by extent to use an __intersects lookup on the bbox
7. Create a migration to drop the four bbox_ Decimal fields

[srtonz]

We have a working PoC at https://github.com/GeoTob/geonode/pull/15, but still wrangling a few test issues.

[srtonz]

@mtnorthcott has been testing and improving this and will finalise this issue:)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.