Clean up typos for 0.1.0 release! (#48)

Co-authored-by: Kyle Barron <kylebarron2@gmail.com>
Co-authored-by: Joris Van den Bossche <jorisvandenbossche@gmail.com>

README.md

@@ -1,53 +1,56 @@
-# GeoArrow - geospatial data with Apache Arrow
 
-Specifications for storing geospatial data in Apache Arrow.
+# GeoArrow Specification
+
+This repository contains a specification for storing geospatial data in Apache Arrow
+and Arrow-compatible data structures and formats.
 
 The [Apache Arrow](https://arrow.apache.org/) project specifies a standardized
 language-independent columnar memory format. It enables shared computational libraries,
-zero-copy shared memory and streaming messaging, interprocess communication, etc and is
+zero-copy shared memory and streaming messaging, interprocess communication, and is
 supported by many programming languages and data libraries.
 
 Spatial information can be represented as a collection of discrete objects using points,
 lines and polygons (i.e., vector data). The
 [Simple Feature Access](https://www.ogc.org/standards/sfa) standard provides a widely
 used abstraction, defining a set of geometries: Point, LineString, Polygon, MultiPoint,
-MultiLineString, MultiPolygon, GeometryCollection. Next to a geometry, simple features
+MultiLineString, MultiPolygon, and GeometryCollection. Next to a geometry, simple features
 can also have non-spatial attributes that describe the feature.
 
 Geospatial data often comes in tabular format, with one or more columns with
 feature geometries and additional columns with feature attributes. The Arrow columnar
-memory model is therefore perfectly suited to store such data, both vector features and
+memory model is well-suited to store both vector features and
 their attribute data. The GeoArrow specification defines how the vector features
 (geometries) can be stored in Arrow (and Arrow-compatible) data structures.
 
 This repository contains the specifications for:
 
-- The memory layout for storing geometries in an Arrow field ([format.md](./format.md))
-- The Arrow extension type definitions ([extension-types.md](./extension-types.md))
+- The memory layout for storing geometries in an Arrow array ([format.md](./format.md))
+- The Arrow extension type definitions that ensure type-level metadata (e.g., CRS) is
+  propagated when used in Arrow implementations ([extension-types.md](./extension-types.md))
 
 Defining a standard and efficient way to store geospatial data in the Arrow memory
-layout helps interoperability between different tools and ensures geospatial tools can
+layout enables interoperability between different tools and ensures geospatial tools can
 leverage the growing Apache Arrow ecosystem:
 
 - Efficient, columnar file formats. Leveraging the performant and compact storage of
   Apache Parquet as a vector data format in geospatial tools using
-  [GeoParquet](https://github.com/opengeospatial/geoparquet/).
+  [GeoParquet](https://github.com/opengeospatial/geoparquet/)
 - Accelerated between-process geospatial data exchange using Apache Arrow IPC message
   format and Apache Arrow Flight
 - Zero-copy in-process geospatial data transport using the Apache Arrow C Data Interface
   (e.g., GDAL)
 - Shared libraries for geospatial data type representation and computation for query
-  engines that support columnar data formats (e.g., Velox, DuckDB, Acero)
-
-The goal of this repository is to discuss and move towards specifications
-on metadata and memory layout for storing geospatial data in the Arrow memory
-layout or related formats.
+  engines that support columnar data formats (e.g., Velox, DuckDB, and Acero)
 
-### Relationship with GeoParquet
+## Relationship with GeoParquet
 
 The GeoParquet specification originally started in this repo, but was moved out into its
 own repo (https://github.com/opengeospatial/geoparquet), leaving this repo to focus on
-the Arrow-specific specifications (Arrow layout and extension type metadata).
+the Arrow-specific specifications (Arrow layout and extension type metadata). Whereas
+GeoParquet is a file-level metadata specification, GeoArrow is a field-level metadata
+and memory layout specification that applies in-memory (e.g., an Arrow array), on disk (e.g., using
+Parquet readers/writers provided by an Arrow implementation), and over the wire (e.g.,
+using the Arrow IPC format).
 
 ## Implementations
 
@@ -56,3 +59,8 @@ the Arrow-specific specifications (Arrow layout and extension type metadata).
 * [geoarrow-rs](https://github.com/geoarrow/geoarrow-rs/): Rust implementation of the
   GeoArrow specification and bindings to GeoRust algorithms for efficient spatial
   operations on GeoArrow memory. Includes JavaScript (WebAssembly) bindings.
+* [geoarrow-python](https://github.com/geoarrow/geoarrow-python): Python bindings to geoarrow-c
+  and geoarrow-rs that provide integrations with libraries like pyarrow, pandas, and
+  geopandas.
+* [geoarrow-wasm](https://github.com/geoarrow/geoarrow-rs/blob/main/js/README.md):
+  WebAssembly module based on geoarrow-rs

extension-types.md

@@ -1,5 +1,5 @@
 
-# Arrow Extension Type definitions
+# GeoArrow Extension Type Definitions
 
 The memory layout specification provides an encoding for geometry types
 using the Arrow Columnar format; however, it does not provide a route by

format.md

@@ -1,7 +1,8 @@
-# GeoArrow: an Arrow-native storage format for vector geometries
+
+# GeoArrow Memory Layout Specification
 
 Spatial information can be represented as a collection of discrete objects
-using points, lines and polygons, i.e. vector data. The
+using points, lines, and polygons (i.e., vector data). The
 [Simple Feature Access](https://www.ogc.org/standards/sfa) standard provides
 a widely used abstraction, defining a set of geometries: Point, LineString,
 Polygon, MultiPoint, MultiLineString, MultiPolygon, GeometryCollection. Next
@@ -13,7 +14,7 @@ standardized language-independent columnar memory format. It enables shared
 computational libraries, zero-copy shared memory and streaming messaging,
 interprocess communication, etc and is supported by many programming
 languages. The Arrow columnar memory model is suited to store both vector
-features and its attribute data. This document specifies how such vector
+features and their attribute data. This document specifies how such vector
 features can be stored in Arrow (and Arrow-compatible) data structures.
 
 The terminology for array types in this document is based on the
@@ -23,33 +24,35 @@ The terminology for array types in this document is based on the
 
 ### Motivation
 
-Standard ways to represent or serialize vector geometries include WKT (e.g.
+Standard ways to represent or serialize vector geometries include WKT (e.g.,
 "POINT (0 0)"), WKB and GeoJSON. Each of those representations have a
 considerable (de)serialization cost, neither do they have a compute-friendly
 memory layout.
 
 The goal of this specification is to store geometries in an Arrow-compatible
-format that has 1) low (de)serialization overhead and 2) once in memory is
-cheap to convert to geospatial libraries (e.g. GEOS or JTS) or easy to
-directly operate on (e.g. directly working with the coordinate values).
+format that:
+
+- Has low (de)serialization overhead, and
+- Once in memory is cheap to convert to geospatial libraries (e.g., GEOS or JTS)
+  or easy to directly operate on (e.g., directly working with the coordinate values).
 
-Benefits of using the proposed Arrow-native format:
+Benefits of using the proposed Arrow-native format include:
 
-- Cheap access to the raw coordinate values for all geometries.
-- Columnar data layout.
+- Cheap access to the raw coordinate values for all geometries,
+- Columnar data layout, and
 - Full data type system of Arrow is available for attribute data.
 
-More specifically, the Arrow geometry specification stores the raw coordinates
-values in contiguous arrays with enough metadata (offsets) to reconstruct or
-interpret as actual geometries.
+More specifically, the Arrow geometry specification stores the raw coordinate
+values in contiguous buffers with enough metadata (offsets) to reconstruct or
+interpret them as actual geometries.
 
 [FlatGeoBuf](https://flatgeobuf.org/) is similar on various aspects, but is
-record-oriented, while Arrow is column-oriented.
+record-oriented, whereas Arrow is column-oriented.
 
 ### Memory layouts
 
 GeoArrow proposes a packed columnar data format for the fundamental geometry
-types, using packed coordinate and offset arrays to define geometry objects.
+types using packed coordinate and offset arrays to define geometry objects.
 
 The inner level is always an array of coordinates. For any geometry type except
 Point, this inner level is nested in one or multiple