Story #6319
closedFilter spatial data by centroid totally encompassed in the map viewport rather than bounding box encompassed in the map viewport
0%
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
Updated by ben leinfelder over 10 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"
Updated by Lauren Walker about 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/4691Updated by Lauren Walker about 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.
Updated by ben leinfelder about 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...