Opened 11 years ago
Closed 11 years ago
#511 closed enhancement (fixed)
Use origin and offset vectors in Petascope for domain2cell conversion
Reported by: | Piero Campalani | Owned by: | Piero Campalani |
---|---|---|---|
Priority: | major | Milestone: | Future |
Component: | petascope | Version: | development |
Keywords: | Cc: | ||
Complexity: | Hard |
Description
When a coverage is read in Petascope, the geometric information which in the database is stored as origin + offset vectors (GML-like), is currently ported to the pre-existing min-max values architecture, with additional Y-axis special treatment (since origin in rasdaman is UL corner.)
This makes it awkward and not flexible, so ideally the origin and offset vectors should reflect the origin and orientation of rasdaman axes, and the conversion mechanism from WC*S to RasQL queries (petascope.wcps.server.core.Crs
) should use that information.
Example: currently a 2D latlong image in rasdaman is stored from UL corner, so that Y coordinates are decreasing while increasing their index. Metadata of the coverage instead moves the origin to the LL corner, and assigns adirectional resolutions, depending on the scale of a rasdaman cell: simple arithmetic proportion between min-max and subsets extents is used to translated lats and lons to indexes. If a Y axis is converted, a special conversion is used, for decreasing indexes.
Ideally instead, the origin in Petascope would be kept where the real origin [0,0] in rasdaman is — so UL — having a directional resolution, i.e. offset vectors, with negative sign for the Y axis, and thus having a unique formula for conversion to grid indexes.
Change History (5)
comment:1 by , 11 years ago
Component: | undecided → petascope |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:2 by , 11 years ago
comment:3 by , 11 years ago
Patch submitted: now the order of grid points describe in the gml:domainSet
of a grid coverage really follows the same order of grid values in the gml:rangeSet
. Indeed, rasdaman always starts grid indexes from "top" of an image, along the vertical axis.
j ^ | GO v0 100 + @---x---x .---> | | | | v1 | 60 + x---x---o P v | | | | 20 + x---x---x O----+---+---+-----> i 50 90 130 Grid Origin = GO := "CRS:1"(0,0) / "Index2D"(50,100) Offset Vectors = v0 := "CRS:1"(1,0) / "Index2D"(40,0) v1 := "CRS:1"(0,1) / "Index2D"(0,-40) Grid Point = P := "CRS:1"(2,1) / "Index2D"(50+2*40=130, 100+1*(-40)=60)
The conversion to grid indexes is not dependent on the sign of the associated offset vector, as it should be, avoiding ad-hoc behavior for "Y"-typed axis, as was done before.
Extend operations now follow the direction of the native CRS, as it should be: extending in the j
CRS axis in the example above 100 will result in negative grid indexes hence putting the additional white space on top of the image, not below.
comment:4 by , 11 years ago
Status: | assigned → accepted |
---|
comment:5 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | accepted → closed |
Partial fix in changeset:136a807 which fixes the GML encoding of a coverage, specifying for the first time exactly the origin is (upper-left corner for 2D, for instance).
The order of values listed in the range set now agrees with the order of domain set points.
Still the conversion to grid indexes uses (WCPS) domain elements with min and max values, but it now uses a flag which determines if the offset vector of the axis is positive forwards or not.
Closing the ticket.
See also m-list discussion here.