Add Geospatial Metadata Support to Hypercerts

[daviddao]

Describe the feature you'd like to request

Hypercerts would benefit from the ability to include standardized geospatial metadata to better represent the geographic scope and impact of projects. This enhancement would enable more precise tracking, filtering, and visualization of impact claims based on their geographic attributes.

Describe the solution you'd like

A proposal would be to implement a standard EAS schema for geospatial attestations that can be referenced by hypercerts through their existing metadata fields. An example schema for example could look like this:

struct GeospatialAttestation {
    // Primary location identifiers
    bytes32 locationHash;    // Hash of canonical location string
    string[] regionCodes;    // ISO-3166, NUTS, or other standard codes
    
    // Optional detailed geometry (GeoJSON as compressed string)
    string geometry;         // Compressed GeoJSON geometry
    
    // Metadata
    uint8 precisionLevel;    // Enum: COUNTRY=0, REGION=1, CITY=2, EXACT=3
    uint64 validFromTime;    // Unix timestamp
    uint64 validToTime;      // Unix timestamp
    
    // Reference fields
    address attestor;        // Address of the geographic data provider
    bytes32 sourceId;        // Reference to source of geographic claim
}

with a potential reference in hypercerts metadata through:

{
  "name": "Example Impact Claim",
  "description": "...",
  "external_url": "...",
  "properties": {
    "geospatial_attestations": [
      {
        "schema": "0x...",  // EAS schema ID for GeospatialAttestation
        "uid": "0x..."      // UID of the specific attestation
      }
    ]
  }

Describe alternatives you've considered

Alternatively one can simply store an IPFS cid directly into the metadata field.

[s-adamantine]

Referencing issue #3 , I think this can be better generalized by just slotting it under the "attestations" category. Creating an explicit geospatial_attestations property is probably unnecessary. By slotting it under a generic "attestation" category, the hypercerts standard becomes more "generic". The schema should definitely be generalized in EAS though.

{
  "name": "Example Impact Claim",
  "description": "...",
  "external_url": "...",
  "properties": {
    "attestations": [
      {
        "schema": "0x...",  // EAS schema ID for GeospatialAttestation
        "uid": "0x..."      // UID of the specific attestation
      }, ...
      // other impact claim attestations
    ]
  }

Also, instead of attesting the compressed geoJSON directly in the attestation, I prefer your alternative of storing the IPFS CID of the uploaded geoJSON file. More flexible, and has the possibility to store additional information.

[johnx25bd]

At Astral we've been designing a framework for creating location proofs, and implemented an EAS schema for v0.1 — we'd love to explore how that schema could be adapted to serve Hypercerts / Ecocerts. This is a beta implementation, and we're looking for early adopters (like you!) who can help us refine the data model, prioritize features, and put it all to the test.

We did our best to develop an unopinionated implementation that:

• can support any form of spatial data, including points, linestrings, polygons, polyhedrons, rasters / tensors, etc, in any spatial reference system — locationType, location + srs fields
• allows a wide range of "corroborative evidence" to be attached, to increase the credibility of a location proof — recipeType + recipePayload
• devs / users can attach additional media data to — any format, plus of course CIDs — meaning the proofs can be extended to include photos, additional form data, scientific measurements, etc — mediaType + mediaData.

All told, we've been working towards a versatile decentralized geospatial database with ways to assure that records submitted were actually created in the places they reference.

This one schema can support different users in the Hypercerts model, including representing Project boundaries and positions of Evaluators (plus evaluation data). You can read a bit about our philosophy on this here. We believe the strongest location proofs will be composite proofs that contain a diversity of different evidence types.

I'd like to learn more about your requirements. At a glance our schema would serve your purpose (pretty) well. @daviddao — we don't have an attribute that maps cleanly to every attribute in the schema you proposed above, but I have a few ideas about how we could make it work*.

We have a lot of plans for things to build around the Location Proof Protocol, including

• a library of proof-of-location strategies (down to the "recipes" for creating evidence to attach to a proof)
• software to create and verify all kinds of proofs
• an API with spatial and temporal querying capabilities (which most GraphQL endpoints for blockchain data don't offer)
• zero knowledge location proofs
• verifiable geocomputation systems like Spatial.sol or cryptographic proofs
• an OGC specification, to support adoption by bigger institutions

One value prop of collaborating is we can each focus on our respective infrastructure, and both benefit from improvements. I'd love feedback — let's see if we can work together 😄

• Some ideas — if need be we could design a locationType that contains sub-attributes that you need. Alternatively, we could attach more data in the mediaData field. And we can also add additional attributes in future versions — I really like your idea of including regionCodes (for easier indexing, if nothing else), as well as precision levels.