---
title: "What about ing"
author: "Michael Sumner"
date: "4/16/2020"
output: html_document
---

```{r setup, include=FALSE}
knitr::opts_chunk$set(echo = TRUE)
```
# What about simple features? 

Silicate is not about simple features, it's about transcending those limitations for day to day data problems. Unfortunately we inevitably have to couch this work in that context. 

Modern geospatial science needs normal-form data structures. 


Modern GIS standards generally represent spatial data as nested lists, whether
in accordance with the Simple Features (SF) standard of the Open Geospatial
Consortium, or in `geojson` format. Most commonly used geometric libraries are
based on one or both of these two standards. We argue that (1) the agreed
representations in modern GIS geometry effectively restrict ongoing development
of GIS as a whole, and (2) the enforced representation of geometry as nested
lists as a central form is inefficient.

## Simple Features

SF does not address what "non-simple" features are or might be, yet clearly these
include important application domains such as GPS data, transport networks,
point clouds, computer aided design, virtual and/or augmented reality, and 3D
games. Each of these significant arenas have their own standards which are
difficult to reconcile or unite without risking fragmentation and inefficiency.

SF and nested-list representations are limited because:

* Shapes are not represented as topological primitives and so internal boundaries are precluded.
* Shapes are represented as paths so only planar polygonal shapes are possible.
* Shapes may exist in XY[Z[M]] geometry, but this is not extensible, with no capacity to store data against component geometry elements. 
* Shapes have no persistent naming of features or their components.
* There is no capacity for internal topology of shapes or within collections (no vertex-, edge-, or path-sharing).

These limitations mean that SF cannot fully represent every-day data forms
from tracked objects, transport, Lidar, 3D models, statistical graphics,
topological spatial maps, TopoJSON, CAD drawings, meshes or triangulations.
Translations between geospatial forms and the grammars of data science can be
disjointed, relying on localized implementations that are lossy or inefficient,
require third party workflows, or involve unnecessary tasks.

GIS applications generally diverge from common standards in different ways but
none currently provide a normal-form model. There is no standard way to
normalize data by detecting and removing redundancy (topology), or to densify
data (a common necessity in planning domains). There is no standard way to
extend the types although complex forms are well established in other domains.
