GERS ID Structure

[jenningsanderson]

The Global Entity Reference System (GERS) depends on establishing a unique identifier for every entity in the world.

To date, the proposed GERS ID structure would be 128 bits, divided in the following way:

64 bits	n bits	64-n bits
h3 cell ID	theme + type	Unique identifier per theme + type per h3 cell

[ringsaturn]

What H3 resolution range will be used?

https://h3geo.org/docs/core-library/restable

[pwellner]

How is a GERS ID like/unlike a what@where Placekey, which also uses H3?

[ringsaturn]

From previous discussions we could know that GERS ID will store all 64 bits H3 Cell data, while PlaceKey only stores part of them.

#10 (reply in thread)

#10 (comment)

Still waiting more details from official.

[matt-walker0]

Curious to know if S2 was considered for the underlying grid structure?
Given the oddities that H3 contains: https://observablehq.com/@fil/h3-oddities
The only peculiarity that I'm aware in S2 is the 7 neighbouring cells exist at corners of base cells, rather than typical 8. Perhaps this could be a better fit for a consistent grid ID.

[thehoneymad]

I'm new here. So I'm probably about to write something without proper context.

S2 also has another benefit. And that is the hilbert curve series. A series of neighboring entities can be sorted through that for future cloud native storage options.

[jenningsanderson]

Sure thing, each of these approaches has their trade-offs. The GERS ID, however, is not supposed to offer any spatial indexing benefits. We recommend against trying to parse the cell from the ID.

We are indeed looking at better ways to order the features inside the parquet files based on location.

[derolf]

Is it correct that the second part of the ID is only unique per cell, but not globally?

[jenningsanderson]

The best way to think about a GERS ID is as a UUID. Extracting any value out of the GERS ID other than a consistent identifier may be inconsistent.

The structure of the GERS ID is to assist in generating the ID.

The h3 cell represented in the first half is of any resolution chosen by the data producer (i.e., buildings may use Resolution 11 while admins may use resolution 8. The id is prefixed with the h3 cell address simply to geographically segment the entire ID space.

To answer @derolf's questions: Depending on how a theme has chosen to create the second half of the ID, it might not be unique globally.

[derolf]

@jenningsanderson Thanks for clarifying? Is there a defined geometric relation between the Cell ID and the object? For example, is an object within the cell or might it stretch outside the cell?

[jenningsanderson]

It might look different for every theme, but with buildings, for example, the cell is calculated off the center of the bbox — so the bounds of the buildings might stretch beyond the cell's border if it is close to the edge.

Additionally, if the building moves slightly, but it's still the same building and the center of the new bbox is now in a neighboring cell, that is OK too. There is no guarantee that all (or any) parts of the feature exist in the cell. There's a good chance the feature won't move very far (because then it is likely a different entity).