Opened 11 years ago
Closed 11 years ago
#440 closed defect (fixed)
usage of ps_domain table in petascope 8.x
Reported by: | damiano | Owned by: | Piero Campalani |
---|---|---|---|
Priority: | major | Milestone: | Future |
Component: | petascope | Version: | 8.5 |
Keywords: | strlo strhi uom ps_domain | Cc: | mantovani@… |
Complexity: | Medium |
Description (last modified by )
in ps_domain table:
- "strlo" and "strhi", if filled, cause errors in DescribeCoverage requests,
- "uom" is ignored
Change History (8)
comment:1 by , 11 years ago
Description: | modified (diff) |
---|---|
Summary: | usage of ps_range table in petascope 8.x → usage of ps_domain table in petascope 8.x |
comment:2 by , 11 years ago
Cc: | added |
---|
comment:3 by , 11 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:4 by , 11 years ago
I can see that Petascope does read the uom
associated to a domain element, but then they are not inserted in the GML: actually there is no room there for domain UoMs, only for @srsName
and @srsDimension
, I believe. So we could actually drop the ps_domain.uom
column.
comment:5 by , 11 years ago
regarding srtLo' and 'strHi', I am reporting from the schema update script (
./applications/petascope/src/main/db/petascope/update0.sql`):
-- If the type is not temporal, numLo and numHi must be the lowest and highest addressable points in geo coordinates, and strLo and strHi must be left null. -- If the type is temporal, numLo and numHi must be left null, and strLo and strHi must be timestamps, specifying the extent. -- Because the current implementation does not currently support temporal axes, you can use "other" as the type and specify dummy values for numLo and numHi.
comment:6 by , 11 years ago
Keywords: | strlo strhi uom ps_domain added |
---|---|
Milestone: | → Future |
comment:8 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Note:
See TracTickets
for help on using tickets.
Thanks for reporting Damiano,
I think this is expected in this version since only numeric values are supported by the domain. I'll forward that to Piero for further investigation.
Is the uom issue related to #441 ? In that case I think we need to have only one place where uom is specified, the other should be removed or marked as rightfully not used.