if you want to test it out any, i have forks of turf-union and turf-intersect that are setup with it
@morganherlocker I had one other question about mapbox open source (heh, for now). It might be different for you guys, depending on how pay / time works, but bosses here were wondering what approach to take to limit amount of time people spend actively maintaining working on open source stuff.
obviously, as you pointed out on twitter, build everything like it's going to be an open package, so that fits nicely into our workflow with no real impact on time, other than time spent making things more ready w/ docs and tests, but we want that anyway. The question more is, how much time is okay to be spending maintaining packages that we have published, on the clock. and how to we set expectations about that.
so I was curious if mapbox had any specific mechanism for that or if it's more.. you know what you should be working on, if working on this package more gets you there, then do it, if not, maintain off the clock
I guess if your pay is salaried that probably answers the question, mostly. We do hourly, so it's a question of how to we ensure that people are contributing things that are valuable to us when they're on the clock, while still maintaining the open source packages we build, I suppose... I'm not entirely sure how we want it to look. so I'm just trying to get ideas :P
it's not like we're trying to get free work out of people - we can't make people contribute OS packages, but for the people who love it (like me!) is there a good way to manage that so that I don't accidentally spend my whole day maintaining things that don't necessarily gain us anything. We talked over setting some kind of "hey, don't spend more than x amount of time during the workday maintaining packages"... but I'm not sure if that feels too restrictive
just trying to find a right balance
that's kind what I'm thinking
the bosses here are sorta interesting... they seem initially kinda traditionalist, but are convinceable
i sold them on the benefits of doing an open source initiative
but the knee jerk reaction is "how do we make sure people don't waste time with it?"
@tchannel i think i would look at open source more as an engineering implementation detail rather than some huge shift in how the business operates. you work on it as much as the project requires + whatever extra you want to throw in for good karma. open source does not really take any more time than a closed source implementation done properly would take. Either way, projects should have tests, basic security, modularity, etc.
another point here is that we started as a very small, inexperienced bunch, so we have only sort of recently started doing the "done properly" part of things, with our regular work. I'm looking at embracing open source as a way to help push that more, by saying "look, all those little things you might have just hacked together as one off solutions before, try and think about how you would make these a package that other people might use" and then we'll open it if we want to. I'm wanting that to help motivate more upfront thought, better documentation, etc
i would turn that objection upside down. issues and requests are actually the most valuable part of open source. its a giant community QA department that operates for free. you can always ignore or 'wontfix' and issue if it is totally unimportant to you, but who wouldn't want to know that their software had a critical security vulnerability or a tricky logic bomb waiting to be discovered?
i pointed to free fixes and advice as one of the big sells if you're looking at open source from a business perspective
lol so sounds like the answer is "make sure you have people on your team who have their head on straight about priorities"... which... makes perfect sense
only took.... a few hours.
mostly because of huge datasets, but also because it's kinda complicated
I'm not much of a node guy (most of my suff must works offline too), so I'm sure I miss lots of node related stuff in my commits. Sorry in advance!
I had a lot of 128 Git errors yesterday, so maybe the uploaded code is not my last version. I am using turf-polygon-reduce and turf-cut in production environment, so I can assure their reliability (turf-cut tolerance: 10^-9 meters, turf-buffer issue 23). Regarding node stuff... sorry. And documentation... I know, I know... I will expand and update these days.
My tasks queue has something like that: crossing two data sets with zillions of (complex) polygons each, to find overlappings and make some spatial operations using those overlappings. Searching the way that best fits our needs (not only peformance), we have already achieved this using DotSpatial and using a custom-made QGIS plugin, next try is TURF, just for the joy of it. Once done, will post performace results.
@giulioungaretti most of the processing I do is with large datasets. Turf does well provided you think about optimizations where necessary. For example, indexing data is going to have a dramatic increase in algorithm performance, just like it would in PostGIS or other GIS engines.
@giulioungaretti also, forgot to mention that you can also test the performance of any turf module. clone the module repo and run
node bench.js to see the number of operations per second for any function. https://dl.dropbox.com/s/16v5j5y5dpubzyv/Screenshot%202015-05-05%2012.09.55.png?dl=0
I'm working on an R client for turf.js https://github.com/ropensci/lawn http://cran.rstudio.com/web/packages/lawn/ - Is there a place in turf docs to list this so others know its available?
