You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@tomkralidis has already advocated for a resolution parameter for time but I think we should review the current set of core properties and see if a resolution parameter applies to any other core queryables. For example, a very common query would be querying data based on scale 1:10000 or 1:100000, etc.
The text was updated successfully, but these errors were encountered:
@tomkralidis I think adding "resolution", "scale" etc will be a really slippery slope. I did a quick Google search on scale, resolution, etc. Every definition was slightly different - some even equated scale and resolution. Others said resolution was only applicable to raster data. Oh boy. So, if Records has a resolution queryable, the first step would be to provide a clear and concise definition that the OGC membership agrees to. I the ISO glossary of terms. No luck. So this group would need to define a term and get OGC member agreement. Just sayin :-)
We tried this also in STAC and had a hard time, we are still not set yet. So I'd also recommend avoiding it in core. I also think for Records it's not necessarily core and could better be an extension.
@tomkralidis has already advocated for a resolution parameter for time but I think we should review the current set of core properties and see if a resolution parameter applies to any other core queryables. For example, a very common query would be querying data based on scale 1:10000 or 1:100000, etc.
The text was updated successfully, but these errors were encountered: