WMS_Filling the gaps for project()

[Bang Pham Huu]

When a WMS GetMap request uses a CRS (e.g: EPSG:4326) which is different from layer's nativeCRS (e.g: 23700). The output tile is reprojected() as a rotated rectangle and shows the gap between each tile.

Therefore, it needs to select bigger grid domains for the tile to fill the data for the gaps of tile and then, crop it to get the result as a rectangle with full data instead.

[Bang Pham Huu]

The problem of this ticket is it lacking of parameters from request BBox (e.g: in EPSG:4326) for GDAL GeoTransform to estimate the result of project() correctly.

A naive but correct solution is just request the whole coverage with project© in EPSG:4326 and apply EPSG:4326 bbox in the output (as coverage can provide enough information for GeoTransform then it can translate EPSG:4325 bbox to grid domains after project(). The grid domain after project() is always 0,0).

Example:

SELECT ENCODE( ( Extend( Scale( ( ( project(c0, 
"415142.866168, 4896.33877541, 943642.866168, 408646.338775", "EPSG:23700", "EPSG:4326")[2255:2446,409:599] ) ), 
[0:253, 0:255] ), [0:255, 0:255] ) ) , "png", "{  \"nodata\" : [ 0 ]}") FROM HU_SSAND as c0

It is not safe to transform BBox from source CRS to target CRS then transform it back to source CRS even with GDAL as it does not return same result (e.g: grid domains contain more pixels, different geo bounds and axes' resolutions).

[Dimitar Misev]

You can try this query which is hopefully equivalent to the above in comment:1:

Extend( 
  Scale( 
    project(
      c0[2255-50:2446+50,409-50:599+50],
      "826159.5020597367547452449798583984375, 214390.376716836006380617618560791015625, 905737.376701820758171379566192626953125, 342503.317234158166684210300445556640625",
      "EPSG:23700", "EPSG:4326")[50:192+50,50:191+50],
    [0:255, 0:255] 
  ), 
[0:255, 0:255] 
) 

[Bang Pham Huu]

Replying to dmisev:

You can try this query which is hopefully equivalent to the above in comment:1:

Extend( 
  Scale( 
    project(
      c0[2255-50:2446+50,409-50:599+50],
      "826159.5020597367547452449798583984375, 214390.376716836006380617618560791015625, 905737.376701820758171379566192626953125, 342503.317234158166684210300445556640625",
      "EPSG:23700", "EPSG:4326")[50:192+50,50:191+50],
    [0:255, 0:255] 
  ), 
[0:255, 0:255] 
) 

rasql -q 'SELECT ENCODE Extend(Scale(project(c0[2255-50:2446+50,409-50:599+50], 
"826159.5020597367547452449798583984375, 214390.376716836006380617618560791015625, 905737.376701820758171379566192626953125, 342503.317234158166684210300445556640625", 
"EPSG:23700", "EPSG:4326")[50:192+50,50:191+50], [0:255, 0:255]), [0:255, 0:255] ), "png", "{  \"nodata\" : [ 0 ]}") FROM HU_SSAND as c0'

This one returns empty PNG image.

ERROR 1: rasql_1.png, band 1: Failed to compute statistics, no valid pixels found in sampling.
  NoData Value=0

[Bang Pham Huu]

See ​http://rasdaman.org/ticket/1882#comment:6 for the reason why reprojecting UTM to 4326 will have gaps (nodata) at the corners.

[Dimitar Misev]

reprojecting UTM to 4326 will have gaps (nodata) at the corners

But that ticket was about a reprojection 4326 → UTM → 4326? Not about UTM → 4326

[Bang Pham Huu]

Replying to dmisev:

reprojecting UTM to 4326 will have gaps (nodata) at the corners

But that ticket was about a reprojection 4326 → UTM → 4326? Not about UTM → 4326

Ticket:1882 is not about bi-directional projections (it is UTM → 4326) and I wanted to compare the subset (created by gdaltransform) with the whole images.

[Dimitar Misev]

It's clear that reprojection from X to Y will likely warp X and introduce nodata, what that other ticket clarified to me is that bidirectional reprojection is lossy. But I don't think it brings any insights into the problem in this ticket.

[Bang Pham Huu]

Replying to dmisev:

It's clear that reprojection from X to Y will likely warp X and introduce nodata, what that other ticket clarified to me is that bidirectional reprojection is lossy. But I don't think it brings any insights into the problem in this ticket.

I added the reference to the other ticket to show a real results purpose only.

[Bang Pham Huu]

The patch was applied "ticket:1894 - enhance WMS filling gaps when projection needed" but still this ticket is available until it could produce smooth results as GeoServer.

[Dimitar Misev]

Ok, but let's reduce that blocker status.

[Dimitar Misev]

I'll open a new ticket for this task as it's more focused now.