morganherlocker

> For example, while Mapbox use open source (OSM) tiles, other services - e.g. their search API - aren't open, as Mapzen's is(/was).

The geocoding engine[1] powering the Mapbox Search API is open source, and has been since its inception in 2012. The same is true of the routing engine[2] powering the Mapbox Directions API (OSRM), and the engine used to create Vector Tiles[3] for the Mapbox Maps API, along with the engines powering most Mapbox APIs.

Non-open code at Mapbox is usually tightly coupled to our infrastructure or data processing pipelines, which would not be generally useful to the community at large. The useful bits of even this infrastructure code is also typically abstracted into generally useful libraries for community use, such as earcut[4], rasterio[5], tile-cover[6], and hundreds of other modules of all varieties.

  - [1] https://github.com/mapbox/carmen
  - [2] https://github.com/project-osrm/osrm-backend
  - [3] https://github.com/mapnik/mapnik
  - [4] https://github.com/mapbox/earcut
  - [5] https://github.com/mapbox/rasterio
  - [6] https://github.com/mapbox/tile-cover

> rock solid, lightning fast, and 100% accurate in all cases

This is like the CAP theorem[1], but for computational geometry libraries. You cannot have all 3 if your truly are aiming for accuracy, speed, or robustness. There is always another edge case (which turns out to be a common case for you), there is always another computational shortcut (cutting out seat belts for cases you know you won't encounter), and there is always a missing function (that you really need). CGAL is a terrific reference implementation for a remarkably diverse set of algorithms, and its commitment to precision in particular is astounding[2].

All that said, never trust the output of a geometry library function that has not been thoroughly fuzz tested. I guarantee that every one of these libraries will fail in surprising ways when subjected to a brutal fuzz tester. I say this as the author of one of the libraries, and as someone who is familiar with the quirks of all of them. In my experience, the best geometry libraries do one tiny task very fast (backed up by benchmarks) and very reliably (verified through unit and fuzz tests).

[1] https://en.wikipedia.org/wiki/CAP_theorem [2] http://www.cgal.org/exact.html

..or get the best of both worlds with a data mashup.

This reads a bit like early internet critics complaining about how there are too many voices online. "Why isn't the Times enough for everyone? Why do these bloggers need to be telling everyone what they think? Some of them don't even check their facts!"

> It is Torvald’s “Release early and often” without the community smashing the ego of anyone publishing sub-par code.

The relative lack of Torvalds-esque public shaming is exactly what I love about the Javascript community. There is an acknowledgment that we can all do things our own way, and that it's OK. We don't need a dictator shouting down people "doing it wrong".

Distance calculations account for this and geodesic buffer support is on the way. This is close to top of my priority list right now.

Wgs84 data is assumed for distance calculations. If you need to convert your data on the fly, I typically recommend proj4js.

Thanks for the heads up! Everything is back up now.

Here are some rough benchmarks[1]

Performance will vary widely depending on which functions you are calling and characteristics of the data. Some types of analysis will quickly process 500 MB, and others you will probably want to use some sort of indexing strategy.

For pure javascript indexers, check out rbush[2] (R-Tree indexes) and tile-cover[3] (map tile indexes), both of which are as fast or faster than the C++ indexers used in most mainstream spatial databases.

Expect these benchmarks to improve in the coming months as we push the limits with new, faster algorithms as well.

[1] https://gist.github.com/morganherlocker/a9041f2491c63b541cb2

[2] https://github.com/mourner/rbush

[3] https://github.com/mapbox/tile-cover

> Have you thought about porting it to Meteor's Atmosphere

We currently support npm, bower, and a CDN build on Mapbox. Additional package managers can be added if there is a community need.

> I'm curious if this supports Leaflet too?

Turf is not tied to any visualization framework. GeoJSON in - GeoJSON out; display it where you want (or don't display it at all).

For those interested in this topic in the DC area, a couple of these are currently on display at the Smithsonian National Museum of American History.

http://americanhistory.si.edu/press/releases/100-years-perso...

3 main reasons:

- Runs in browser, for client-side indexing.

- Based off of tiles, instead of s2's 6-faced-cube thing. This allows it to be used with a lot of well established tools and mathematical formulas. Also much easier to reason about IMHO.

- Indexes points about twice as fast at the moment.

I also use s2, and it really is terrific. There are many cases where s2 is the superior choice (mostly due to its hilburt curve indexing scheme).

Actually, PostGIS does not use s2. I believe it uses its own modified R-Tree index. The main downside to this is that the entire index must be kept in memory, which is one of the the primary motivations for libraries like s2. There are alternatives to s2 as well like tile-cover[1], a tile-based indexer that can run client-side. Most of the NoSQL DBs these days do use s2 though.

[1] https://github.com/mapbox/tile-cover

Your average node module is 50-300 lines of code. A readme is just fine to document the 2 or 3 functions that are usually exposed. Beyond that, reading the source is not that onerous. Compare that to your typical doxygen-generated mega-doc, and I think it's a feature, not a bug.

You can have both. Frameworks like turf (a geospatial analysis library that I authored) have one high level convenience module[1]. You can require('turf'), then run any function from a single object (ie: turf.buffer(), turf.smooth(), etc.).

Finer control is often required, however, for all sorts of reasons. For these cases, turf is made up of a collection of sub-modules [2][3], and these can be required individually.

I like this approach, since it provides a nice curated framework for users simply wanting to get stuff done quickly, but it also allows for more tuned usage in production environments. It has been a bit more work to maintain (~70 repos, instead of 1), but I have been pleased with the approach so far.

[1] https://github.com/Turfjs/turf [2] https://github.com/Turfjs/turf-buffer [3] https://github.com/Turfjs/turf-smooth

Limechat shows image links inline, which is good enough for me anyway. In some ways it is even preferable to tying things to one particular storage solution like s3.

> Diabetes, I think in some cases restricting carbs can be fatal as diabetics can suffer from ketoacidosis, where the blood turns acidic due to an uncontrollable amount of ketones present.

Ketoacidosis is extremely dangerous for diabetics, but it occurs in cases of extreme high blood sugar, not low blood sugar. These ketones can lead to serious kidney damage, or even kidney failure. Your point about hypoglycemia is dead on though.

As a type I diabetic myself, carbs are actually life saving during a low blood sugar episode (and low blood sugars actually occur more often for type I diabetics with tight control). As an aside, I find it perpetually frustrating how keto-fans like the OP conflate type I and type II diabetes as if there is no difference (because the answer to everything is "keto" \s).

The limit went up considerably with the introduction of 64-bit Excel. Also, there is a plugin called "Power Query" that allows the actual data to be stored in MSSQL. I have seen this work on tables with 100s of millions of records without a hitch.

OSM does have addresses, but coverage is far from perfect. Nominatum (the geocoder used by OSRM) will interpolate addresses if it does not have the exact parcel info, which is surprisingly accurate in many cases. Work is also being done to create full address coverage as well[1], which you should check out if you are interested.

[1] http://openaddresses.io/

Try out OSRM[1]. It is open source[2], so you can run it yourself, or you can use a public api for limited usage. The api has a JSON response with turn-by-turn[3], and it is remarkably fast.

[1] http://map.project-osrm.org/ [2] https://github.com/DennisOSRM/Project-OSRM [3] https://github.com/DennisOSRM/Project-OSRM/wiki/Server-api

You could try the JOSM editor[1], but iD is about as lightweight as it gets, so I am not sure if it would be much better. For what its worth, I use iD regularly without performance issues, but YMMV on older machines. Unfortunately, vector rendering and editing will tend to push browsers to their limit. This may be alleviated somewhat by the use of WebGL in coming years.

[1] https://josm.openstreetmap.de/

OSM prefers user created data. Mass imports often contain errors all over the place (many going back unnoticed for years). OSM holds a general mindset that data should only be included if someone is fairly certain the data is correct (which they would not be on a mass import). "When in doubt, leave it out." That said, it is more of a guideline than a rule, and there have been mass imports in the past.

Just about everyone writes tests first. You have some sort of script that you are running against the real code you are working on to see if it is doing what it should be doing. The only real difference between true "TDD" and everyone else, is that the TDD folks save this script to be run later.

I might be so far down the TDD trail that I have lost perspective, but do people really write huge swaths of code without writing scripts to run the code and see what it is doing? Those little scripts are tests, and with a tiny bit of formatting, they can be made to output something consistently useful like TAP[1], instead of inconsistent console logs. This whole debate seems like strawmen fighting strawmen.

[1] http://testanything.org/

Vector data has a much smaller footprint in most cases, but takes lots of processing to render, and even more if you need to be able to zoom around the map. Rendering the US down to z17 as raster tiles allows for efficient processing, but could easily get into 10s of GB (which makes sense, since it is creating thousands and thousands of png images). The size grows exponentially with each zoom level though, so if you only need something like z12, you might be able get it into the 10s of MB range.

I use Spectacle with alt+cmd+up mapped to 100% window, which I tend to prefer to actual "fullscreen" (OSX is weird with fullscreen on multiple monitors).

This was one of the things that made OSX horrible for me when switching from Windows and Linux. I have since learned the tricks to get around many of OSX's windowing quirks, but I do wonder how things like this have not been fixed.

I love my OSX setup now, but if I was a "non-power-user", I think it would be completely unusable. Watching a typical Windows user try to maximize a window in OSX is pure pain.

Hit the + button: window gets a bit bigger, but not full screen.

Drag the window to the top: nothing happens.

Try to get to the edge of the window, and drag it out: RSI inducing frustration.

Windows seems to dominate as far as basic user usability goes on the windowing front. I would still find it completely unusable without the help of a windowing app like spectacle[1] or slate[2].

[1] http://spectacleapp.com/

[2] https://github.com/jigish/slate

One biologist has attempted to create a test with dogs. The basic hypothesis is that dogs should be able to recognize their own urine if they can detect "self" through smell. The results so far have been inconclusive[1]

[1] http://en.wikipedia.org/wiki/Mirror_test#Animals_with_a_non-...

> into a document viewer?

DRM discussion aside, the browser has not been a simple "document viewer" for quite some time, despite its origins.

This is definitely an important question, but I do not have any data on it. If I had to guess, languages with package managers that are harder to use might have better quality. ie: npm is super easy to use, so there are tons of crappy node.js modules, while maven is harder, so the Java modules out there have more polish. Without data, however (how would you even measure it?) I cannot say for sure. Perhaps you could compare number of modules installed past some percentage threshold? If 90% of node modules never had more than 100 downloads, but Java had only 20%, that would be pretty telling to me and might lead to a reasonable weighting factor.

I do not see it much in the southeast US. .Net and Java dominate the programming language culture here, and you do not just jump in and learn all of .Net or Java in a year or two. For all of its many shortcomings, the south does seem to have a reverence for age and experience (which might contribute heavily to aforementioned shortcomings).

Even at startups, I would guess that the average programmer is over 30 in my area (Charleston, SC). An older programmer here can pretty much live like a king/queen on their salary with nearly limitless employment, assuming they keep somewhat up to date ("up to date" being more like "knows how to use OOP and a standard ORM", not "has a prolific Github profile and uses TDD"). In fact, many of the top programmers you see here are people who left SF or NYC for more stable employment in finance, cushy consulting, and better real estate prospects.

[Disclaimer: I am neither an older programmer nor a .Net/Java dev, but this has been my anecdotal experience]

In reference to #1, check out this summary of module counts for each package manager[1]. The TLDR is that Java, Ruby, and Node.js dominate in terms of module numbers.

[1] http://modulecounts.com/