You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issues comes from #1004 where we started skipping over items with non-numeric lon and/or lat coordinates.
Post #1519 (comment), I'm having second thoughts about skipping non-numeric items in the calc step though mapbox/calc.js appears to get this right. Ignoring non-numeric items early makes sense for 🐎 as we save a few isNumeric call in hot code paths (e.g. in <>/plot.js), but it does lead to some headaches elsewhere in the code (e.g. those placeholder flags) 😕
The text was updated successfully, but these errors were encountered:
etpinard
changed the title
scattergeo does not datum position in arrayOk attributes
scattergeo does not respect datum position in arrayOk attributes
Mar 29, 2017
if isNumeric is a concern (I'm not sure it is compared to everything else that needs to happen in <>/plot.js, but it wouldn't hurt to optimize this) we should be able to ensure <>/calc.js replaces all non-numeric points with BADNUM and just use !== BADNUM which is about as fast as can be imagined.
Right now scatter uses false for non-numerics but that was an ancient decision... if we standardize on something it should be BADNUM.
For example
yields
see http://codepen.io/etpinard/pen/QpJGeq
This issues comes from #1004 where we started skipping over items with non-numeric
lon
and/orlat
coordinates.Post #1519 (comment), I'm having second thoughts about skipping non-numeric items in the calc step though
mapbox/calc.js
appears to get this right. Ignoring non-numeric items early makes sense for 🐎 as we save a fewisNumeric
call in hot code paths (e.g. in<>/plot.js
), but it does lead to some headaches elsewhere in the code (e.g. thoseplaceholder
flags) 😕The text was updated successfully, but these errors were encountered: