Release Candidate 1 (#176)

* readme updates for rc.1

* Delete .DS_Store

* more readme updates for rc.1

* removed trailing whitespace

* attempt 2 for trailing whitespace

* fixed geoarrow location

Co-authored-by: Tim Schaub <[email protected]>

* Update README.md

* Update README.md

Co-authored-by: Kyle Barron <[email protected]>

* Update README.md

Co-authored-by: Kyle Barron <[email protected]>

* Update README.md

Co-authored-by: Matthias Mohr <[email protected]>

---------

Co-authored-by: Tim Schaub <[email protected]>
Co-authored-by: Kyle Barron <[email protected]>
Co-authored-by: Matthias Mohr <[email protected]>

README.md

@@ -2,19 +2,19 @@
 
 ## About
 
-This repository defines a [specification](https://geoparquet.org/releases/v1.0.0-beta.1/) for how to store geospatial [vector data](https://gisgeography.com/spatial-data-types-vector-raster/) (point, lines, polygons) in [Apache Parquet](https://parquet.apache.org/), a popular columnar storage format for tabular data - see [this vendor explanation](https://databricks.com/glossary/what-is-parquet) for more on what that means. Our goal is to standardize how geospatial data is represented in Parquet to further geospatial interoperability among tools using Parquet today, and hopefully help push forward what's possible with 'cloud-native geospatial' workflows. Learn more at [geoparquet.org](https://geoparquet.org)
+This repository defines a [specification](https://geoparquet.org/releases/) for how to store geospatial [vector data](https://gisgeography.com/spatial-data-types-vector-raster/) (point, lines, polygons) in [Apache Parquet](https://parquet.apache.org/), a popular columnar storage format for tabular data - see [this vendor explanation](https://databricks.com/glossary/what-is-parquet) for more on what that means. Our goal is to standardize how geospatial data is represented in Parquet to further geospatial interoperability among tools using Parquet today, and hopefully help push forward what's possible with 'cloud-native geospatial' workflows. There are now more than 10 different tools and libraries in 6 different languages that support GeoParquet, you can learn more at [geoparquet.org](https://geoparquet.org).
 
-**Warning:** This specification is currently in 1.0 'beta' releases, which means we don't anticipate anything major will change, but still reserve the right to make changes in backwards incompatible ways. See the [versioning](#versioning) section below for more info. If you are excited about the potential please collaborate with us by building implementations, sounding in on the issues and contributing PR's! Note that the specification in this repository is in flux, we recommend using the [latest published release](https://geoparquet.org/releases/).
+**Note:** This specification is currently in 1.0 'release candidate' status, which means the community is proposing the current version to be 1.0.0, and if no blocking negative feedback is made until end of August 2023 then it will become 1.0.0. This means breaking changes are still possible, but quite unlikely - see the [versioning](#versioning) section below for more info.
 
 Early contributors include developers from GeoPandas, GeoTrellis, OpenLayers, Vis.gl, Voltron Data, Microsoft, Carto, Azavea, Planet & Unfolded.
-Anyone is welcome to join us, by building implementations, trying it out, giving feedback through issues and contributing to the spec via pull requests.
-Initial work started in the [geo-arrow-spec](https://github.com/geopandas/geo-arrow-spec/) GeoPandas repository, and that will continue on
-Arrow work in a compatible way, with this specification focused solely on Parquet.
+Anyone is welcome to join the project, by building implementations, trying it out, giving feedback through issues and contributing to the spec via pull requests.
+Initial work started in the [geo-arrow-spec](https://github.com/geoarrow/geoarrow) GeoPandas repository, and that will continue on
+Arrow work in a compatible way, with this specification focused solely on Parquet. We are in the process of becoming an [OGC](https://ogc.org) official
+[Standards Working Group](https://portal.ogc.org/files/103450) and are on the path to be a full OGC standard.
 
 - [**Specification**](format-specs/geoparquet.md)
 - [JSON Schema](format-specs/schema.json)
 - [Examples](examples/)
-- [Validator](validator/)
 
 ## Goals
 
@@ -32,7 +32,6 @@ There are a few core goals driving the initial development.
 
 And our broader goal is to innovate with 'cloud-native vector' providing a stable base to try out new ideas for cloud-native & streaming workflows.
 
-
 ## Features
 
 A quick overview of what GeoParquet supports (or at least plans to support).
@@ -54,7 +53,10 @@ will work much better if it is backing a system that is constantly updating the
 
 ## Roadmap
 
-Our aim is to get to a 1.0.0 in the next few months. The next steps are to push towards our 1.0.0 acceptance criteria, articulated in this [discussion post](https://github.com/opengeospatial/geoparquet/discussions/122), which mostly involves getting great validation tools, more software implementations, and more data providers. This should provide key feedback to feel confident in going to 1.0. The goal of 1.0.0 is to establish a baseline of interoperability for geospatial information in Parquet. We've got some exciting plans to go beyond that, which we'll articulate soon on the website.
+Our aim is to get to a 1.0.0 final by the end of August 2023. The goal of 1.0.0 is to establish a baseline of interoperability for geospatial information in Parquet. For 1.0.0
+the only geometry encoding option is Well Known Binary, but we made it an option to allow other encodings. The main goal of 1.1.0 will be to incorporate a more columnar-oriented
+geometry format, which is currently being worked on as part of the [GeoArrow spec](https://github.com/geoarrow/geoarrow). Once that gets finalized we will add the option to
+GeoParquet. In general 1.1.0 will further explore spatial optimization, spatial indices and spatial partitioning to improve GeoParquet's performance.
 
 ## Versioning