Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support specifying precision for geo.io write functions #73

Open
kirahowe opened this issue Nov 17, 2021 · 1 comment
Open

Support specifying precision for geo.io write functions #73

kirahowe opened this issue Nov 17, 2021 · 1 comment

Comments

@kirahowe
Copy link

kirahowe commented Nov 17, 2021

Hi there, thanks for this cool and useful library. I was just wondering what you all think of the idea of being able to specify a number of decimal places for coordinates for the various to-<format> functions. I find using this library so much nicer than working e.g. geotools or other java libraries in my clojure projects, but one thing I miss is being able to sneak in rounding coordinates whilst converting between formats, e.g. using geotools libs I used to do:

(->> wkt-literal
     (.read (WKTReader2.))
     (.toString (GeometryJSON. 6)))

(where that 6 is the number of decimals to use when encoding the numbers)

I find this much nicer with this library (e.g. (-> wkt-literal geoio/read-wkt geoio/to-geojson)), but to get identical results I need to add an extra transformation step to round all the coordinates. This isn't really a big deal, but I wanted too see what you think of adding a second arity to the to-<format> functions in this library to support this. I could possibly help out with a PR for that if it's something you think is reasonable. I also totally understand if there are reasons why this is a bad idea and you don't want it in.

@worace
Copy link
Contributor

worace commented Nov 17, 2021

Seems like an interesting idea, thanks for bringing the suggestion. Certainly seems reasonable to me. The main question I see would be how this is going to affect the API for the current (and probably more common) case where people don't care about rounding. As long as it's not going to make that significantly more onerous, I don't see any reason not to do that.

It might be that we'd need to add a separate set of functions, like geoio/to-geojson-precision-n or something like that, in order to accommodate those additional args.

Did you have any thoughts about how it might work from an API perspective? Where the args would go and whatnot?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants