search

ropensci-archive / wicket

:no_entry: ARCHIVED :no_entry: Utilities to Handle WKT Spatial Data
Other
9 stars 1 forks source link

wicket assumes cartesian coordinates #14

Closed edzer closed 7 years ago

edzer commented 7 years ago

a long/lat triangle centred around the pole gives

> wkt_centroid("POLYGON((0 85,120 85,240 85,0 85))")
  lat lng
1  85   0

The result suggests that wicket assumes long/lat data, but if this is the case, the answer is wrong (should be lat 90 lon 0 (or any other lon). Cartesian coordinates were hard coded here.

As a comparison, sf gives you the same centroid but at least with a warning:

st_centroid(st_as_sfc("POLYGON((0 85,120 85,240 85,0 85))", 4326))
Geometry set for 1 feature 
geometry type:  POINT
dimension:      XY
bbox:           xmin: 120 ymin: 85 xmax: 120 ymax: 85
epsg (SRID):    4326
proj4string:    +proj=longlat +datum=WGS84 +no_defs
POINT(120 85)
Warning message:
In st_centroid.sfc(st_as_sfc("POLYGON((0 85,120 85,240 85,0 85))",  :
  st_centroid does not give correct centroids for longitude/latitude data
Ironholds commented 7 years ago

Fair point; I'll switch to non-cartesian assumptions.

Ironholds commented 7 years ago

This is fixed for now, in the sense that it contains a caveat and note - in the long-term it'd be great to use spherical points and have it controllable by the user, but the actual boost centroid code seems to find spherical-point-based objects obnoxious. So, resolved as Good Enough but I'm gonna try and dig down into why Boost is complaining for funsies at some point.