ropensci
geojsonio2 or re-write for v1.0?
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?
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
- 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
eg1i 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