Opened 11 years ago

Closed 10 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 Dimitar Misev, 11 years ago

Component: undecidedpetascope
Owner: changed from Dimitar Misev to Piero Campalani
Status: newassigned

comment:2 by Piero Campalani, 10 years ago

See also m-list discussion here.

comment:3 by Piero Campalani, 10 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 Piero Campalani, 10 years ago

Status: assignedaccepted

comment:5 by Piero Campalani, 10 years ago

Resolution: fixed
Status: acceptedclosed

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.

Note: See TracTickets for help on using tickets.