-
-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PostGIS Raster integration #112
Conversation
f2749e2
to
7f381f8
Compare
Some points that may be worth discussing:
|
|
Scripts used to make the graph:
|
docs/api.md
Outdated
|
||
|
||
## Discrete raster data | ||
Combining summary from multiple rasters into a single JSON object for each H3 index, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need a paragraph on why would you want this, and how you define a difference between Discrete/Continuous, and when to pick which.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some examples for types of data and sample output.
Combining summary from multiple rasters into a single JSON object for each H3 index, | ||
adding `fraction` value (fraction of H3 cell area for each value): | ||
``` | ||
WITH |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This query frightens me as documentation, likely because it lacks sample output to grasp what it does.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added sample output and a description.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interested and innocent bystander: It would be good to have an example of this but where the return value is simpler, e.g. just the value at the H3 cell centre, or the return value is the mode value, rather than these complex objects.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@alpha-beta-soup
Thank you, that's a good idea. I've added an example of getting the most frequent value in each cell.
The other example shows an intended use case, and I also tried to show how to calculate a total # of pixels in each cell, since it's not immediately obvious.
CREATE OR REPLACE FUNCTION __h3_raster_pixel_area(rast raster) | ||
RETURNS double precision | ||
AS $$ | ||
SELECT ST_Area(ST_Transform(ST_PixelAsPolygon(rast, 1, 1), 4326)::geography); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we do something like ST_Area(ST_ConvexHull(rast)) / (height*width)? Then sum of areas should add up to real area.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think so, but maybe we can instead use the area of a pixel at ST_Centroid(ST_MinConvexHull(rast))
?
The difference should be insignificant for a case where all pixels have data, but it would be a bit more precise in case when the pixels are clustered near the edge of the raster (e.g. all "build up" pixels are in the south).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Replaced with __h3_raster_polygon_pixel_area
, area of pixel at ST_Centroid(ST_MinConvexHull(rast))
.
resolution integer) | ||
RETURNS h3index | ||
AS $$ | ||
SELECT h3_lat_lng_to_cell(ST_Transform(ST_Centroid(poly), 4326), resolution); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is probably ok here but my paranoia says that ST_PointOnSurface provides better guarantees on pointing to the inside of the polygon if it has weird shape.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I also think that in deck.gl there is an optimization boundary that you can copy single hex within the tile if it does not contain a pentagon or there is no boundary between base cells in the tile.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here poly
is min. convex hull, so the center always lies within the polygon. But why would it be bad if the center was outside of weirdly shaped polygon? Assuming H3 cell area gradient is the same across the raster (not strictly true), the most representative cell would be near the center of mass of non-nodata pixels even if this cell is outside the polygon.
Can you please elaborate on how deck.gl optimization is relevant?
daa92ef
to
1d3a089
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Excellent work @mngr777! Are you ready to have this PR merged? |
@zachasme Yes, I think it's ready to be merged, thank you. |
I'll merge as soon as we get the conflicts resolved. Could I ask you to rebase on main? I tried to do it myself, but I think I'd need write access to your fork. |
… compatibility with Postgres 11
… and cells per raster
…are potentially inlinable
…r simpler result geometry
ddcd8a6
to
94c4dfc
Compare
This new functionality is intended to simplify projecting raster data onto H3 grid.
Two main methods of processing raster data are implemented:
ST_Clip
the raster by H3 cell boundary for each cell intersecting the raster, process each partial raster using ST_SummaryStats or ST_ValueCount.The second method becomes more efficient as number of pixels per cell increases. There are also fallback functions for cases when H3 cell is smaller than a pixel, but in practice it would porbably be better to increase raster resolution instead.
Continuous data example:
Discrete data example (produces one JSON object per H3 index):