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

geojsonio2 or re-write for v1.0? #165

Open
sckott opened this issue Feb 6, 2020 · 2 comments
Open

geojsonio2 or re-write for v1.0? #165

sckott opened this issue Feb 6, 2020 · 2 comments

Comments

@sckott
Copy link
Collaborator

sckott commented Feb 6, 2020

I often lose track/get confused about what different functions do (what they take as input and give as output), and since v0.1 in 2015 sf has come along and other changes in the spatial pkg landscape. Maybe it's worth considering a re-thinking of the package, its purpose, its role in the suite of spatial pkgs. An overall goal i think would be to simplify, probably drop the input/output options that aren't used very much

ideas

  • lists: do people use geojson lists? if not we could drop lists (eg1)
  • sp: is there still a need for handling sp classes? i imagine so for folks that still prefer sp
  • any functions we should drop?
  • what can we focus on that is not already done well by other pkgs

thoughts @ateucher ? anyone else?

@sckott sckott added the question label Feb 6, 2020
@ateucher
Copy link
Member

ateucher commented Feb 6, 2020

I've been having similar thoughts @sckott.

Quick thoughts on your ideas:

lists: do people use geojson lists? if not we could drop lists (eg1)

I'm not sure many people use geojson lists... I support them in rmapshaper, but I'd bet not many people go that route. I'd be happy to drop them - could remove them in a branch and run some revdep checks?

sp: is there still a need for handling sp classes? i imagine so for folks that still prefer sp

I think we should still support them, but perhaps we could just convert them to sf and then do the conversion to geojson. Possobly using geojsonsf instead of our own internal plumbing?

any functions we should drop?

Probably, but hard to say right now. There are some I don't even know what to do! And I too get confused/forget what functions do what...

what can we focus on that is not already done well by other pkgs

Two things come immediately to mind - sp classes, and topojson support

@sckott
Copy link
Collaborator Author

sckott commented Feb 8, 2020

  • lists: right, could remove them then run checks. and one can easily just get json then jsonlite to list if they want a list. would simplify the pkg - there is that eg1 i linked to above though
  • sp: good point, i imagine there's still A LOT of people still using sp
  • what can we focus on: agreed on sp and topojson

@mikemahoney218 mikemahoney218 added reprex needs a minimal reproducible example and removed question reprex needs a minimal reproducible example labels Sep 12, 2022
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

3 participants