[ 
https://issues.apache.org/jira/browse/SDAP-110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frank Greguska updated SDAP-110:
--------------------------------
    Description: 
Nexus needs to intelligently handle tiles that are wider than 180 degrees. 
Currently if a tile is ingested that is wider than 180 degrees the indexed 
shape is interpreted incorrectly resulting in missed searches.

For example, if you create a Solr document that spans the longitude range:

{\{curl -X POST }}
 \{{ 
'http://127.0.0.1:8983/solr/nexustiles/update?_=1528823301125&boost=1.0&commitWithin=1000&overwrite=true&wt=json'
 }}
 \{{ -H 'Cache-Control: no-cache' }}
 \{{ -H 'Content-Type: application/json' }}
 \{{ -d '[{}}
 \{{ "table_s":"sea_surface_temp",}}
 \{{ "geo":"POLYGON((-179.000 -82.000, 179.000 -82.000, 179.000 -63.000, 
-179.000 -63.000, -179.000 -82.000))",}}
 \{{ "id":"7c9d9bd1-d96a-399e-a0b4-7071172ab1d4",}}
 \{{ 
"solr_id_s":"ICE_SHELF_DH_V1_1x1Monthly!7c9d9bd1-d96a-399e-a0b4-7071172ab1d4",}}
 \{{ "sectionSpec_s":"time:0:1,lat:0:20,lon:0:360",}}
 \{{ "dataset_s":"ICE_SHELF_DH_V1_1x1Monthly",}}
 \{{ "granule_s":"1x1regrid-ice_shelf_dh_v1.nc",}}
 \{{ "tile_var_name_s":"height_filt",}}
 \{{ "tile_min_lon":-179.0,}}
 \{{ "tile_max_lon":179.0,}}
 \{{ "tile_min_lat":-82.0,}}
 \{{ "tile_max_lat":-63.0,}}
 \{{ "tile_min_time_dt":"1994-01-14T23:59:59Z",}}
 \{{ "tile_max_time_dt":"1994-01-14T23:59:59Z",}}
 \{{ "tile_min_val_d":0.0,}}
 \{{ "tile_max_val_d":0.0,}}
 \{{ "tile_avg_val_d":0.0,}}
 \{{ "tile_count_i":494}}
 {{}]'}}

 

And then try to query using a box that should be within the bounds:

 

{{curl -X GET \}}
{{ 
'http://127.0.0.1:8983/solr/nexustiles/select?indent=on&q=dataset_s:ICE_SHELF_DH_V1_1x1Monthly&shard.keys=ICE_SHELF_DH_V1_1x1Monthly%21&fl=%2A&fq=\{%21frange+l%3D0+u%3D0}ms%28tile_min_time_dt,tile_max_time_dt%29,tile_count_i:[1+TO+%2A],geo:[-78.000,-14.000%20TO%20-74.000,15.000]&rows=1&wt=json&debug=query'
 \}}
{{ -H 'Cache-Control: no-cache' }}

 

You will get 0 results.

  was:
Nexus needs to intelligently handle tiles that are wider than 180 degrees. 
Currently if a tile is ingested that is wider than 180 degrees the indexed 
shape is interpreted incorrectly resulting in missed searches.

For example, if you create a Solr document that spans the longitude range:

{{curl -X POST \}}
{{ 
'http://127.0.0.1:8983/solr/nexustiles/update?_=1528823301125&boost=1.0&commitWithin=1000&overwrite=true&wt=json'
 \}}
{{ -H 'Cache-Control: no-cache' \}}
{{ -H 'Content-Type: application/json' \}}
{{ -d '[{}}
{{ "table_s":"sea_surface_temp",}}
{{ "geo":"POLYGON((-179.000 -82.000, 179.000 -82.000, 179.000 -63.000, -179.000 
-63.000, -179.000 -82.000))",}}
{{ "id":"7c9d9bd1-d96a-399e-a0b4-7071172ab1d4",}}
{{ 
"solr_id_s":"ICE_SHELF_DH_V1_1x1Monthly!7c9d9bd1-d96a-399e-a0b4-7071172ab1d4",}}
{{ "sectionSpec_s":"time:0:1,lat:0:20,lon:0:360",}}
{{ "dataset_s":"ICE_SHELF_DH_V1_1x1Monthly",}}
{{ "granule_s":"1x1regrid-ice_shelf_dh_v1.nc",}}
{{ "tile_var_name_s":"height_filt",}}
{{ "tile_min_lon":-179.0,}}
{{ "tile_max_lon":179.0,}}
{{ "tile_min_lat":-82.0,}}
{{ "tile_max_lat":-63.0,}}
{{ "tile_min_time_dt":"1994-01-14T23:59:59Z",}}
{{ "tile_max_time_dt":"1994-01-14T23:59:59Z",}}
{{ "tile_min_val_d":0.0,}}
{{ "tile_max_val_d":0.0,}}
{{ "tile_avg_val_d":0.0,}}
{{ "tile_count_i":494}}
{{}]'}}

 

And then try to query using a box that should be within the bounds:

 

{{curl -X GET \}}
{{ 
'http://127.0.0.1:8983/solr/nexustiles/select?indent=on&q=dataset_s:ICE_SHELF_DH_V1_1x1Monthly&shard.keys=ICE_SHELF_DH_V1_1x1Monthly%21&fl=%2A&fq=\{%21frange+l%3D0+u%3D0}ms%28tile_min_time_dt,tile_max_time_dt%29,tile_count_i:[1+TO+%2A],geo:[-78.000,-14.000%20TO%20-74.000,15.000]&rows=1&wt=json&debug=query'
 \}}
{{ -H 'Cache-Control: no-cache'}}

 

You will get 0 results.


> Need to handle tiles wider than 180 degrees
> -------------------------------------------
>
>                 Key: SDAP-110
>                 URL: https://issues.apache.org/jira/browse/SDAP-110
>             Project: Apache Science Data Analytics Platform
>          Issue Type: Improvement
>            Reporter: Frank Greguska
>            Priority: Major
>
> Nexus needs to intelligently handle tiles that are wider than 180 degrees. 
> Currently if a tile is ingested that is wider than 180 degrees the indexed 
> shape is interpreted incorrectly resulting in missed searches.
> For example, if you create a Solr document that spans the longitude range:
> {\{curl -X POST }}
>  \{{ 
> 'http://127.0.0.1:8983/solr/nexustiles/update?_=1528823301125&boost=1.0&commitWithin=1000&overwrite=true&wt=json'
>  }}
>  \{{ -H 'Cache-Control: no-cache' }}
>  \{{ -H 'Content-Type: application/json' }}
>  \{{ -d '[{}}
>  \{{ "table_s":"sea_surface_temp",}}
>  \{{ "geo":"POLYGON((-179.000 -82.000, 179.000 -82.000, 179.000 -63.000, 
> -179.000 -63.000, -179.000 -82.000))",}}
>  \{{ "id":"7c9d9bd1-d96a-399e-a0b4-7071172ab1d4",}}
>  \{{ 
> "solr_id_s":"ICE_SHELF_DH_V1_1x1Monthly!7c9d9bd1-d96a-399e-a0b4-7071172ab1d4",}}
>  \{{ "sectionSpec_s":"time:0:1,lat:0:20,lon:0:360",}}
>  \{{ "dataset_s":"ICE_SHELF_DH_V1_1x1Monthly",}}
>  \{{ "granule_s":"1x1regrid-ice_shelf_dh_v1.nc",}}
>  \{{ "tile_var_name_s":"height_filt",}}
>  \{{ "tile_min_lon":-179.0,}}
>  \{{ "tile_max_lon":179.0,}}
>  \{{ "tile_min_lat":-82.0,}}
>  \{{ "tile_max_lat":-63.0,}}
>  \{{ "tile_min_time_dt":"1994-01-14T23:59:59Z",}}
>  \{{ "tile_max_time_dt":"1994-01-14T23:59:59Z",}}
>  \{{ "tile_min_val_d":0.0,}}
>  \{{ "tile_max_val_d":0.0,}}
>  \{{ "tile_avg_val_d":0.0,}}
>  \{{ "tile_count_i":494}}
>  {{}]'}}
>  
> And then try to query using a box that should be within the bounds:
>  
> {{curl -X GET \}}
> {{ 
> 'http://127.0.0.1:8983/solr/nexustiles/select?indent=on&q=dataset_s:ICE_SHELF_DH_V1_1x1Monthly&shard.keys=ICE_SHELF_DH_V1_1x1Monthly%21&fl=%2A&fq=\{%21frange+l%3D0+u%3D0}ms%28tile_min_time_dt,tile_max_time_dt%29,tile_count_i:[1+TO+%2A],geo:[-78.000,-14.000%20TO%20-74.000,15.000]&rows=1&wt=json&debug=query'
>  \}}
> {{ -H 'Cache-Control: no-cache' }}
>  
> You will get 0 results.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to