Location research service built with Meteor

announce
#1

Hi all,

Some of may be familiar with illustreets and its beginnings as a prototype web mapping app (built originally with Meteor 0.4x - sounds like prehistory!). illustreets has grown into a full-blown SaaS in recent years, happily running its front facing service on modern Meteor, and powering location intelligence projects on several continents.

Courtesy of Xploria, our data consultancy, we relaunched our free service for researching locations across the UK as Open Xploria. Has a lot of information on demographics, crime, green spaces, broadband, and much more. Give it a try, even if only to see what kind of stuff one can build with Meteor. The app has some interesting functionality for cross-filtering areas, changing themes, and estimating travel time, for instance, which you can quickly read about in the how to.

If you live in the UK, and planning to move house, or are just curious about your area, you might find it even more useful.

A huge thank you to Meteor and the Meteor community which have made our software possible!

image
image1100Ă—640 209 KB

13 Likes
#2

Hi, that’s impressive, congrats! I’m curious to learn more about the stack you are using, as we’re building a location-based app as well (although with a completely different use-case). In particular, I’d love to learn how you deal with server-side marker clustering. This is something we yet have to implement.

#3

@illustreets unfortunately I can’t open the links on my mobile, they are just blank. Can you check what this is about?

#4

Thanks @jkuester, what browser is it? There have bee reports of issues with Opera on Android, and Safari on iPhone 5S, so we’re looking into that.

#5

Thank you @waldgeist we can get into details in a private conversation about it, although the map rendering backend is quite specific to a web mapping business. Could be overkill if your buisness is not strictly web mapping.

One thing we used to great effect in the past, specifically for fast clustering of millions of points (I mean up o 10 ms fast) is… Elasticsearch. I actually don’t know a faster fixed grid clustering technique that is reasonably fast for large amounts of points. The approach we followed was based on geohashes. A similar approach is described very well here: Server-side clustering of geo-points on a map using Elasticsearch - Trifork Blog.

Also you might want to give Supercluster a go (server side, I’d say, beause you don’t wan all that data transferred to the client): https://blog.mapbox.com/clustering-millions-of-points-on-a-map-with-supercluster-272046ec5c97

3 Likes
#6

It’s Firefox on Android

#7

Erm, yeah, same issue as with Opera on Android. Will check that out. Thanks for reporting!

#8

Thanks for sharing your insights. Yes, I was thinking about going for supercluster as well.

#9

So the problem reported by @jkuester and by other users elsewhere regarding Firefox and Opera on Android, and older iPhone versions, came down to how we (did not) serve the legacy bundle.

Here’s an interesting lesson if anyone ever hits this in the future.

We chose to tune up our reverse proxy to avoid as much as possible serving static stuff from Node. So for the JS & CSS bundles our NGINX location directive looked something like this:

location ~* "^/[a-z0-9]{40}\.(css|js)$" {
    root /var/www/html/bundle/programs/web.browser;

    # ... the rest of the config goes here
}

This directive will obviously not serve from the web.browser.legacy folder, which is what the problem was. “Not found” errors for the legacy bundle.

The fix was to use a common root, and a try_files directive. Because the JS bundles have different hashes, when NGINX hits the first path and can’t find the file, will automatically try the second one (and only return 404 if it can’t find the file there either).

location ~* "^/[a-z0-9]{40}\.(css|js)$" {
    root /var/www/html/bundle/programs;
    try_files /web.browser$uri /web.browser.legacy$uri =404;

    # ... the rest of the config goes here
}
1 Like