ConsenSysMesh/real-estate-standards

geohash applicability and standard

Opened this issue · 2 comments

  • geohash in itself is not enough - need an array of geohashed points to form a polygon (i.e. s2-geometry-library).
  • Need to support multiple types of polygons - geohash doesn't handle this that well.
  • If geohash, then geohash-36, as it solves some idiosyncrasies with geohash-32 (e.g. "c216ne1" and "c216new" resolving to the same coordinates).
  • Suggest evaluating Open Location Code if we want to stick to this type of fromat.
  • Suggest hash of geojson + z-value for each point. This solves every use case I can think of (including tricky cases like partial air rights for a subsection of the area over a polygon).

Need to think of how to address nested geohash - e.g. identity A has a right to lease [geospatial identifier] X that's located within identity B's ownership right to [geospatial identifier] Y. A's right to [geospatial identifier] X is subject to (or subordinated to) B's right to [geospatial identifier] Y.

In general, should be a way to create a hierarchy that allows for various legal constructs (as they vary between jurisdictions). This also helps solves adverse possession problems.

Here's an idea for discussion... based on a sketch format used in many CAMA systems.

It is human readable and compact for defining both building boundaries and parcels; the origin, north reference, and direction of the traverse are independent of the point ordering of the source polygon.

Assume spatial reference is WGS84, North is True, distances are metric and always positive [meters, decimeters, centimeters, or millimeters], angles are always positive in degrees, altitude is in Floors??

  1. Define the UP axis as the longest segment that has a North component, with the more southerly point of the longest segment being the origin (In case of a tie, the more easterly origin wins).
  2. Compute the Geohash of the origin.
  3. Compute the angle from North to the UP axis - denoted in either e[ast]degrees or w[est]degrees where degrees is an integer between 0 and 89
  4. Choose an appropriate distance unit to capture the desired precision - 0 meters, 1 decimeters, 2 centimeters, 3 millimeters.
  5. Starting at the origin compute a Traverse of the area. use L[eft]R[ight]U[p]D[own] for movements parallel to the coordinate axis, and EWNS[for lack of a better set of identifiers. lrud would be more suitable but the lowercase L could be confused for a 1] for a diagonal movement.
    Arc segments are defined by a chord, prefixed by the Arc direction [F for left and G for right] and the Rise.
    Holes are handled inline (TBD) i.e. a cut from the exterior to the hole. Areas are always positive.
  6. The Altitude is measured from the ground - could be distance or floors (TBD)

Note - a WGS84 polygon can easily be generated from this representation.
Continental drift can be accounted for at the time of the polygon generation, by shifting the origin (and or rotating the North reference), without ever having to invalidate this encoding (as long as it was accurate at the block creation time).

A couple of examples:

  1. A Land Parcel that contains an arc segment
    spatialunit_traverse_landparcel

  2. A 22nd Floor Condo Unit
    spatialunit_traverse_condo