Skip to content
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

Question about usage #32

Closed
bytecorner-jan opened this issue Apr 13, 2020 · 2 comments
Closed

Question about usage #32

bytecorner-jan opened this issue Apr 13, 2020 · 2 comments

Comments

@bytecorner-jan
Copy link

Hello I'm just starting to learn about Geo spatial data processing, and I'm not quite sure about a certain usage of the extension.

I would like the calculate for each data point (GPS location) a H3index (high resolution e.g. 13/14). I'm now looking for a way to easily aggregate for zoom levels 1-11 to display on a map.

I came up with to possible solutions (both I don't like):

  1. Calculate all zoom levels as additional columns -> storage bad -> access time probably good
  2. Work with substrings of the h3index

I'm missing a function for such aggregations. If it is possible with some Postgis functionality please point me to, thanks.

Thanks for your help Jan

@zachasme
Copy link
Owner

Hi Jan

If you simply wish to calculate a H3Index for a given point -144.5, 49.7 at each resolution you can do

...
SELECT h3_geo_to_h3(POINT(-144.5, 49.7), 7);
SELECT h3_geo_to_h3(POINT(-144.5, 49.7), 8);
SELECT h3_geo_to_h3(POINT(-144.5, 49.7), 9);
...

But I'm assuming by aggregating on lower resolutions you mean finding all children below a given, coarser, H3Index, and then aggregating over their values.

For example: You have a table, data, with rows containing data at fine resolution 13. You wish to find the average of children of a given hexagon 831c02fffffffff at a coarser resolution 3.

Right now you would have to calculate the children at the given resolution like so:

SELECT AVG(x) FROM data WHERE hex IN (
    SELECT h3_to_children('801dfffffffffff', 13)
);

This, however, is going to be too slow (or run possibly run out of memory) when the resolution gap is too large. So you will probably be forced to precompute each aggregated resolution.

It is worth mentioning that we have been trying to implement GiST and GIN indexes (see #7) which would allow something like the following (which doesn't work yet)

SELECT AVG(x) FROM data WHERE h3index <@ '831c02fffffffff' AND h3_get_resolution(h3index) = 3;

But no work has been done on that since October.

@bytecorner-jan
Copy link
Author

HI zacharias,

thanks for your answer, you got me right in all the points.

I think GiST is what I was looking for.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants