Project

General

Profile

Actions

Story #6319

closed

Filter spatial data by centroid totally encompassed in the map viewport rather than bounding box encompassed in the map viewport

Added by Lauren Walker about 11 years ago. Updated over 10 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Target version:
Start date:
12/19/2013
Due date:
% Done:

0%

Estimated time:

Description

This issue will require a reworking of how the spatial search filters results - currently the filtering is all done by Solr since the bounding coordinates are indexed. Filtering by centroid may be faster if we have the centroid for each item indexed, otherwise we will have to return ALL results with spatial data, then filter those based on the centroid in JS. I have a feeling the latter will be slower.


Related issues

Blocked by Metacat - Story #6437: Upgrade to SOLR 4 or 5NewJing Tao

Actions
Actions #1

Updated by ben leinfelder almost 11 years ago

  • Target version changed from 1.5.0 to 1.6.0

This will require upgrading metacat-index to use SOLR v4 spatial features. There's a bit of experimentation to be done, but it looks promising.
https://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4
Has examples like:

fq=geo:"Intersects(-74.093 41.042 -69.347 44.558)"  
fq=geo:"IsWithin(POLYGON((-10 30, -40 40, -10 -20, 40 20, 0 0, -10 30))) distErrPct=0" 

Actions #2

Updated by Lauren Walker over 10 years ago

When the DataONE index is upgraded to include centroid values, MetacatUI can easily filter by centroid using this new field and the Google maps bounding box lat,lng values, which are already determined in the DataCatalogView.

DataONE ticket: https://redmine.dataone.org/issues/4691
Actions #3

Updated by Lauren Walker over 10 years ago

The filtering can actually be done by the geohash rather than the indexed centroid lat,long values. The finest geohash value acts as the centroid for that bounding box since that level of accuracy is good enough for this purpose.

Filtering will be done by finding the geohashes encompassed in the map viewport (using the geohash JS library) and then filtering results based on documents that have a geohash starting with or equal to one or more of the geohashes contained in the map viewport.

Actions #4

Updated by ben leinfelder over 10 years ago

On today's call, I thought Peter mentioned something about changing the SOLR type of the geohash fields from "text" to "string" because he didn't need partial matching. Are you planning on doing any "startsWith" kind of operations and will the index field type allow or preclude this intended usage? Just want to double check...

Actions #5

Updated by Lauren Walker over 10 years ago

  • Status changed from New to Resolved
Actions

Also available in: Atom PDF