Research for geojson based mapping database / visualization engine

abstract.md

GeoJSON-based Mapping Database + Visualization Engine

Research Sources

• GeoJSON Spec
• GeoJSON
• geojson.io
• Natural Earth
  • Natural Earth - GeoJSON
    • Land
    • Regions Poly
• USGS
  • Web Tools
• NGA
  • Products and Services
• CIA - World Factbook
  • CIA World Factbook API
• D3.js
  • Documentation
    • d3-geo
      • GitHub
    • d3-geo-projection
• MDN
  • Tree shaking
• Microsoft Docs
  • EF Core
    • Value Conversions
  • JSON Serialization
    • JsonIgnore
    • Json Serialization Converters
• Observable
  • d3-geo
  • observablehq-maps
• Jason Davies
  • Countries by Area

Abstract

An API that enables optimized geospatial data retrieval / integration of geospatial-adjacent data by organizing a hierarchy of features in a database. Hierarchy:

• Global
  • Region
    • Country
      • State / Province
        • County
          • City
            • District

By organizing features hierarchically like this, maps can be generated by starting at a hierarchical point, retrieving a specified level of sub-hierarchy data, and merging any specified metadata associated to the selected features (i.e. - landmarks, statistical data, etc.). This way, the payload of data is optimized similar to tree shaking JavaScript modules.

Data would be formatted in a strongly-typed GeoJSON-based schema and stored in a database. The core data would consist of all natural geospatial boundary data (land, water, boundaries), with the root of a feature being connected to all of its base data + property metadata.

Example EF Schema:

Note that Geometry.Coordinates would use a Value Conversion to convert between ICollection<GeoCoordinate> Coordinates and a 2D array of numbers represented by [GeoCoordinate.X, GeoCoordinate.Y].

JsonIgnore foreign key properties and any EF-related metadata that's not part of the GeoJSON spec.

JSON Serialization Converters can be used to massage data between the EF schema format and the GeoJSON spec format. For instance, DbSet<GeoFeature> GeoFeatures should serialize into:

{
  "type": "FeatureCollection",
  "features": /* each GeoFeature record as Feature */ 
}

public class GeoFeature
{
  [JsonIgnore]
  public int Id { get; set; }
  [JsonIgnore]
  public int GeometryId { get; set; }
  public string Type { get; set; }
  
  public Geometry Geometry { get; set; }
  
  public ICollection<GeoProperty> Properties { get; set; }
}

public class Geometry
{
  [JsonIgnore]
  public int Id { get; set; }
  public string Type { get; set; }
  
  public ICollection<GeoCoordinate> Coordinates { get; set; }
}

public class GeoCoordinate
{
  [JsonIgnore]
  public int Id { get; set; }
  [JsonIgnore]
  public int GeometryId { get; set; }
  public float X { get; set; }
  public float Y { get; set; }
  
  public Geometry Geometry { get; set; }
}

public class GeoProperty
{
  [JsonIgnore]
  public int Id { get; set; }
  [JsonIgnore]
  public int GeoFeatureId { get; set; }
  public string Key { get; set; }
  public string Value { get; set; }
}

NOTE: Remember to expand on the idea of the API returning an object vs. just raw GeoJSON. The idea being that a front-end library should exist that's built on top of d3-geo that simplifies rendering maps from this API. The shape of the object would consist of a data property that consists of the GeoJSON data, and a projection property that defines how to construct the map via a specified projection function in d3.

Data Migrations

In the ideal scenario, this resource would be maintained by an authoritative source keeping track of geological + boundary changes. Potentially USGS or NGA.