Kyle Barron

> For 2D-types, I can use geo-types' structs, but there are nothing for 3D. In geoarrow, I use types defined in `wkt` for anything more than 2d: https://docs.rs/wkt/latest/wkt/types/index.html I agree...

Maybe we could behind a feature flag?

I suppose we could make this user-configurable. Have an option like `PointBuilder::with_coordinate_policy` or something like that, to allow customizing the behavior for alternate-dimension data. ```rs enum CoordBuilderPolicy { FillValue(f64), Error...

I think this is an upstream issue. I downloaded all the files to local storage with: ```py import asyncio from pathlib import Path from obstore.auth.planetary_computer import PlanetaryComputerCredentialProvider from obstore.store import...

Scratch work for terrain layer visualization: ```py import lonboard from imageio import imread from pydelatin.util import decode_ele path = "/Users/kyle/github/kylebarron/pymartini/test/data/fuji.png" fuji = imread(path) terrain = decode_ele(fuji, "mapbox") # OverflowError: Python...

> Dumb jokes aside, you mean something like this, right? > > ``` > let y = (x * 10.pow(n)).round() / 10.pow(n); > format!("{}", y); > ``` Yeah. That's how...

@frewsxcv that's what I'm doing here: https://github.com/georust/geozero/pull/200/files#diff-553c2186acf21c8c360979841037ea9343c11e4e2937438cb9eca2c20d0d08cdR107-R109 But we'd still need a way for the user to pass down the precision desired

Are you specifically thinking about **writing** here? As you might've seen in https://github.com/kylebarron/arro3/pull/313 I'm prototyping expanded APIs for **reading** Parquet. By exposing the full `parquet` crate API, and in particular...

Maybe before spending the time on a fleshed out PR, can you more specifically describe the functionality you want?

Maybe let's start with just those two exposed here?