Edits on 0.2 release post #7
Conversation
| author: | ||
| - name: Dewey Dunnington | ||
| url: https://dewey.dunnington.ca/ | ||
| - name: Kyle Barron | ||
| url: https://kylebarron.dev/ | ||
| - name: Joris Van den Bossche | ||
| url: https://jorisvandenbossche.github.io/ |
There was a problem hiding this comment.
I think it makes sense to put our names on the post. Happy to switch to email instead of URL but I think useful to be able to hyperlink something
| [arrow-cpp]: https://arrow.apache.org/docs/cpp/index.html | ||
| [arrow-rs]: https://docs.rs/arrow/latest/arrow/ | ||
|
|
||
| - A set of [memory layouts](../format.html) to represent geometry |
There was a problem hiding this comment.
I think the memory layouts are the first thing someone thinks about when someone thinks about GeoArrow and so it makes sense to order this bullet point first
| ## Notable changes | ||
|
|
||
| In addition to some minor updates to improve clarity, GeoArrow 0.2 includes a few | ||
| notable changes. | ||
|
|
||
| First, the language defining the content of the `"crs"` key in the extension metadata | ||
| ### New array types |
There was a problem hiding this comment.
I'm a big fan of using headers to easily grep the highlights rather than relying on paragraphs starting with first, second, third, etc.
post/release-0-2.qmd
Outdated
|
|
||
| The GeoArrow 0.2 specification formalizes three new array types: | ||
|
|
||
| - The ["box" memory layout](../format.html#box) represents an array of axis-aligned bounding boxes, represented as an Arrow struct. |
There was a problem hiding this comment.
Added hyperlinks to the relevant sections of the format page
|
|
||
| - The ["box" memory layout](../format.html#box) represents an array of axis-aligned bounding boxes, represented as an Arrow struct. | ||
| - The ["geometry" memory layout](../format.html#geometry) allows arbitrary geometries to be | ||
| represented within a single array, even when the geometry type differs across rows. It's implemented as an [Arrow union][arrow-union-layout] of the other native encodings. |
There was a problem hiding this comment.
For some reason the hard wrapping of my editor wasn't working well with the quarto extension enabled. Feel free to edit my hard wrapping to your liking
| ```json | ||
| {"crs": "EPSG:32620"} | ||
| ``` |
There was a problem hiding this comment.
Took this out to have a full list of crs examples after the next paragraph
| the optional `"crs_type"` field was added and can take on the value `"authority_code"`, | ||
| `"srid"`, `"projjson"`, or `"wkt2:2019"`. Among other use cases, this enabled the | ||
| [C++ implementation of the Parquet GEOMETRY type](https://github.com/apache/arrow/pull/45459) | ||
| to losslessly pass on all the information stored in a Parquet logical type annotation | ||
| for GEOMETRY or GEOGRAPHY in a dependency-sensitive environment. | ||
|
|
||
| - PROJJSON example |
There was a problem hiding this comment.
Examples ordered from preferred to least preferred
|
|
||
| ```json | ||
| { | ||
| "crs": 'PROJCS["WGS 84 / UTM zone 20N",GEOGCS["WGS 84",DATUM["WGS_1984",SPHEROID["WGS 84",6378137,298.257223563,AUTHORITY["EPSG","7030"]],AUTHORITY["EPSG","6326"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4326"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-63],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","32620"]]', |
There was a problem hiding this comment.
Using ' quotes means that the internal " don't need to be escaped \". I think it's fine for this code section to be "json like" instead of literally json text
There was a problem hiding this comment.
Or maybe use an "opaque" example that doesn't involve embedded quotes (like auth:code?). I don't really mind either way (having the escaped quotes nicely highlights how ugly this is, which is why we don't love it!)
There was a problem hiding this comment.
I didn't want to use Auth:code because in that case they should be applying the relevant crs_type (except in the case when they don't know it's an auth:code, but I didn't want to get into all those details right here)
| and `geoarrow.geometrycollection` extension names allow arbitrary geometries to be | ||
| represented within a single feature and within a single array using a union of the other | ||
| native encodings. | ||
| ## Implementations |
There was a problem hiding this comment.
I'm kinda meh about having the implementation section here. Or at least I want to have it exist in a way that doesn't get quickly out of date.
I.e. hopefully we won't have another spec release for a while, but I don't want people a year or two from now to refer to this implementations section frozen in time.
Perhaps even we should have two separate blog posts? One to announce the new 0.2 spec release and another to promote implementations?
There was a problem hiding this comment.
I'm happy to move this to a post on my personal blog and share but thought it would be nice to have that traffic land on geoarrow.org instead. I'd rather only share + promote one link and the spec additions, while cool for low-level developers, are also very dry and have a very small audience.
There was a problem hiding this comment.
I'd rather only share + promote one link and the spec additions, while cool for low-level developers, are also very dry and have a very small audience
That's fair. Maybe we should just have a sentence when we get to the implementations section "this content is valid as of May 2025" and implementations may have progressed since then.
No description provided.