As I said. Code reusability is a must among ninja developers, and we are. But it is also a must to repay your debts. Even if you use open sourced third party code (which is good, because there’s no point in reinventing the wheel when there are really good and proven libraries out there) you still have a debt. Not a monetary debt, but a moral debt.

During our regular developing process, which involves daily scrum meetings, unhealthy eating, working at insane hours and laughing our asses out several times a day, we also conduct the process of keep looking for the best tools for any given repetitive task.

Quoting my partner, Kammus:

…we noticed we had a lot of line breaks. After any sentence or semicolon, we had a line break. Our ENTER key was worn out, so we started looking for a third party library to break our lines for us.

Actually, I’m just joking. I hope Kammus won’t read this article. But what isn’t a joke is that we use tools such as GisConverter, and  when implementing instaGIS capability to parse and translate KML files, we noticed that GisConverter was missing a feature we needed (in this case: parsing KML metadata). We modified the original library to perform the task we needed, but that was an opportunity to repay our debts to open source software. After building the corresponding tests to pack and deliver our contribution, we made a pull request to the developers and, guess what, instaGIS KML inner logic made its way to GisConverter for anyone to use.

Not too long after that, we made new pull requests to be able to parse old KML Entities and even made an adapter for WKB geometry format.

When it comes to javascript, we rely heavily in the library Wicket, to which we have contributed adding support for PostGIS BBOX elements, Google Maps API Rectangle and Circle elements and, recently, with support for the whole google.maps.Data family of elements.

Other collaborations worth noting are our MultiPolygon support for Doctrine Spatial, and bugfixes to NodeDirectUploader,  OpcacheGUI and APCu.

Delivering your code enhancements back to the original project isn’t just about karma. I mean, there’s a lot of karma to it, but that’s not all. We also love to send our contributions back because when they’re accepted it means that our code meets the standards to be reused by others. For a coder, there no reward so sweet as peer recongision.

So that’s it. In too many ways, instaGIS escapes of any reasonable definition of “casual map editing”. Our customers demand from the tool the capability of handling impossible workloads, and several times we achieve that by refactoring existing tools: sometimes to  to work in batches, other times to do their stuff just more efficiently. There are some design bottlenecks in common libraries that only come to surface when you try to use them to parse gigabytes of information, so I guess we’re also making stress tests that no one thought about.

In short: we use trustworthy, proven open source third party tools. We build on top and alonside  those libraries, but sometimes, we also modify those libraries to handle increased workloads. If we can, we pack those enhancements into a pull request, and try to repay our debt to open source ecosystem by giving something back. We all should.

The idea behind this is to streamline and simplify whatever workflow fits to our users needs. In the past our users were sometimes confused with the multiple options. Should I upload or paste? What’s the difference?

Well, let’s forget about that. Now there’s only one screen to do it all, and it’s smart enough to detect when you need to upload a file or paste from your clipboard.

Since our release 14.06.00, we’ve added new custom maptypes, carefully taylored by expert designers to achieve a perfect balance of personality, attractiveness and atmosphere.

Google Maps includes several overlay types by default: polygons, polylines and markers are common tools and we’re sure that you’ll use them at their best. However, we know that there are other features that Google Maps is missing and one of our missions as instaGIS is to provide them with seamless integration.

There are several ways to get your content overlayed on top of your maps. We want to offer you only the most streamlined and inmediate ways, so that any operation in instaGIS is frustration free and fail proof.

In order to achieve an easy uploading experience we decided to supress any kind of uploading dialogs for this specific feature. Instead, you just drag and drop an image and we’ll decide how and where to store it.

The next step, if any, will be for you to drag, rotate and scale the image so that it fits the underlying terrain. This is for the special case in which you want to get a composition such as the map above. However, in many cases the overlayed image will be just referential and you don’t really need to perform any ulterior adjustments.

Feel free to play with this new feature. Image attachments will remain on the map where you drag them into. We are prepared to store your images without size or weight limits indefinitely.

Isochrones can be defined as those boundaries delimiting how far can you go from a given origin in a given timespan. In the example above, if you were standing at NY’s famous Time Square, how far could you walk in 5 minutes, 10 minutes and 15 minutes?

This kind of question is of vital importante to define, for example, the optimal spot to open your new cofeeshop, because perhaps you can’t affort to be exactly at Times Square, but as long as you are 5 minutes away from such an important point of interest, you will still catch a lot of visitors. On the opposite, if pick a place with a very low rent, but you are over 15 minutes away from any important landmark, chances are you’ll be serving coffee to tumbleweeds.

Usually, isochrone calculation requires you to hire a specialist, who in turn might even hire people to do the actual walkaround to determine the isochrone boundary. At instaGIS we’d like to automate this calculation to ease your desicion making process.

Isochrone calculation is available at 5, 10 and 15 minutes interval for walking and driving modes. Both of them use Google Directions  API, so we’re confident the timelapses and chosen routes are pretty accurate.

As we said last week, we took it seriously to optimize and get the most out of our pioneer twitter display feature. Did we mention that we are the one and only gis web tool capable of querying and displaying terms in real time from the Twitter API? We can’t get tired of bragging about that. Who wouldn’t?

However, In the next months we’re planning to add new visualizations to get the most out of twitter. What good would it be just to capture tweets if we were to display them as common markers? If we were to display their content without highlighting mentions and hashtags, what good would it be? We know. Of course we know. And today we added the long awaited twitter parsing logic. Enjoy!!!

What’s New

As you might have already noticed, we are all about social networks. We love social networks, not only because we are power users of almost any social network that crosses our paths, but also because they keep robust and well documented APIs that we developers love to play with. And, of course, because social stuff and geolocation tag along really well, so any social info we can append to our already feature rich maps will render them ever richer.

With release 13.2.0 comes a long expected feature that took several weeks to build. We are now capable of connecting to  Twitter’s Stream API to capture and print geolocated tweets. By default, asking the app to print latest tweets will bring the 500 most recent tweest for your viewport.

Most of our examples happen in San Francisco, see?

But we also know that your mileage might vary, so we added a few options to customize the outcome of your twitter capture: first, you are able to query for tweets in a given boundary, polygon or geofence. Your viewport shouldn’t always be the surface you want to monitor, right? Second, we added the feature to query the twitter firehose for a particular term or expression. For this matter, searching for #Giants is the same than searching for giants, meaning the search is case insensitive and searching for a hashtag will bring also tweets that mention the hashed term alone.

What’s Next

As I said, we spent several weeks brewing this new feature. We’re still tuning the engine to display faster, more relevant results, but we also had to wait until we had gathered enough information to display a meaningful collection of past tweets. See, anyone can query Twitter’s API for a given term, but Twitter will respond with a (very) limited amount of tweets, and you’re not free to search past tweets beyond a few days. To achieve that, we were on our own, so we had to design a system to store several million tweets (which eventually grew to billions, by the way) while keeping optimized indexes so you could search by place and term without having to wait for hours.

We are very proud to be the first gis web tool to add twitter search to its core features, but being the first and the best are no excuse to stop besting ourselves.

So that’s it, dear folks. Keep expecting the unexpected and of course go, login to your account (or create one right away!) and play with out twitter toys at will.

That’s why we keep tracking what’s the word about instaGIS in the press and in the startups and VC circuits. And guess what, they keep saying we’re sizzling hot!

This week, we were mentioned in FayerWayer, the most influential tech blog in Latin America.

FayerWayer.com Article. july 26th 2013

We’ll make sure to keep gathering any InstaGIS mention we find on the news.