Geo-preneur

The OGC is Stuck in 1999

Thu, 09 May 2013 14:09:31 -0700

All these new OGC standards are sadly designed like it is still 1999.

If you don’t like ramblings, then here is the TL;DR for you:

TL;DR OGC Standards should be written for the future, not the present nor the past

I have to get something out of my chest. Yes, it is triggered by the current discussions about accepting GeoServices REST API as an OGC standard.

The current focus of the discussion, at the core, is around the issue that the GeoServices REST API is perceived as a set of competing standards (i.e redundant to the WFS/WMS/WCS/etc specs) that don’t have an open (read open source) reference implementation that any organization can refer to when trying to implement the standard.

To me, this discussion is more about politics (which I do agree is a valid topic to discuss) than about the reality of the standards that do come out of the OGC lately.

Reading any of the documents from the OGC make me feel like I am listening to Prince (before!) 1999.

Seriously.

Standards should be written for the future – not the present

I remember several years back when HTML5 was the hot new thing. The standards were being worked on a lot, but most of the browsers did not support any of the features from HTML5. The table at caniuse.com (a place where you could go to see what HTML5 features were implemented by what browsers) were mostly red (i.e. not implemented).

Fast forward four years into the future, most of it is green. That is because those standards became adopted and the functionality that it brought to life makes everyone’s life better.

Designed in the past, adopted in the future. The way it should be.

Contrast this with the current set of standards that we have “up for comment” from the OGC right now…

Before you think that I am against the OGC, let me tell you that you could not be further from the truth. In most presentations that I have given in the last 6 years (at several conferences, some keynotes, and even my own GeoMeetups ) I have always dedicated slides and time to convince/teach people about the OGC and the importance of standards.

Yet, although I have several friends that do work in these standard bodies (I love you guys – you know who you are!), it still feels that there is an unnecessary amount of bureaucracy at the OGC that is truly killing innovation.

OGC is making “standards” that are outdated, unnecessarily overly-complicated, reference implementations that cannot be used as a reference (read below!), and a whole bunch of protocols that resemble what a protocol would have looked like in 1999. They completely ignore what we have learned in the last decade.

Let me give you some real examples.

- WFS, XML Datastores and queries:

XML Datastores were all the academic hype back in the day. Yet they never took off (with reason). The query language used by OGC (which is another OGC standard) assumes the underlying data store is XML. For those of you not familiar with what this actually means, it is more than a representation of something as text. It assumes you have an XML Infoset.

At the core, the OGC spec for Filters is just an attempt to represent SQL as something equivalent to an XPath expression to be used on the web (?!?).

Anybody that has ever tried implementing WFS will understand what this means. Basically, several months of development, to create a parser that grabs an xml document and turns it back into SQL. But to do it correctly, you don’t have to generate one SQL statement, but several ones. Why? Because the query language is so expressive, than in reality you should be able to create expressions that span multiple underlying tables (it assumes it is an XML Datastore after all) which basically makes you just really sad and go home depressed because it is unnecessarily complex.

I have an idea, why, instead of writing a client application that transforms my query into OGC filter speak, goes through a middleware that grabs the OGC filter speak and turns it back into SQL which then goes to my underlying database - instead - do I just not have one method (ExecuteSQL) and be done with it. Use SQL. Let’s just not reinvent a SQL. The CartoDB guys seem to have this right in their API . One tiny little api, you pass a string… it does a lot! You know how long it takes to implement something like this? Hours, not months. And you actually have more power than what is expressed by the OGC equivalent. Problem solved.

- XML/GML as a transport mechanism:

This is the mechanism of transport of choice for OGC standards. I have a two year old post about why I think this is far from ideal. Although there are some updates to be made to that answer, at the core, it still remains valid. If somebody tells you that the answer is to ‘gzip’ GML, then, they are wrong (a topic for a future post).

I am still baffled as to why do none of the standards, yet, refer to things like Protobuffers, MessagePack, Thrift, Avro - gosh - anything that we have learned to do better in the past decade!

Switching to any of these, or including them as serialization options would make all the implementations of these standards better/faster.

- “Reference Implementations” that cannot be referenced It is true that a “reference implementation” should be able to be, well, referenced. I cannot currently look at how the GeoServices REST reference implementation (I guess ArcGIS Server) is implemented internally, thus, the specification fails at having a valid reference implementation.

Does that mean that for a reference implementation to be useful it needs to be Open Source?

Maybe that is not enough.

Some people would argue that the reference implementations for the OGC GeoPackage spec, Spatialite, is arguably also not a good choice.

Why?

Because you cannot copy/paste or even create “derivative work” from it without also having to GPL/LGPL your work. Is looking at a reference implementation, seeing the internals, and copying how it works considered derivative work? Those are the type of questions that no developer wants to deal with, so IMHO, the OGC has the responsibility to pick reference implementation that in unencumbered by these issues. By picking Spatialite and a proprietary server (ArcGIS Server) as reference implementations to their respective specs, the OGC is showing that they are either 1) really clueless about these type of issues, or 2) don’t care. Either way, this is horrible.

- Websockets?

I wish! Where are the implementations that take advantage of full duplex communications? Server side push? Seriously, are we still assuming users are going to poll all the time and transfer state in every request? This is exactly why most real-time tracking implementations are done incorrectly. Why are we still stuck in a stateless architecture design? We can do server push now without Flash or Java (or Silverlight yikes!). Websockets exist. USE THEM.

I touched superficially around this topic in the last PyCon. The video is up if you are interested.

- Https, Authentication/authorization, security

I don’t even want to touch on authentication/authorization around all the OGC specs. OAuthv2, or even the first version of that are far better than what is expected of the current implementations of security. Most people rely on passing USERNAME/PASSWORD in the request. This is horrible.

But wait, I guess if I use https that means I am secure right? Hell no!

Look at this video from last year’s Blackhat (quite awesome actually) and then come back with a straight face and tell me this is fine.

** - SPDY** If you do not what SPDY is, then, you will definitely be surprised to tell you that all your https traffic to Google , Facebook and Twitter is not going over “traditional” SSL.

Yes, they use a special protocol called SPDY.

It is faster than traditional http (even though it is going over an encrypted channel!). Think about this for a sec.

Does the OGC use SPDY? Of course not. Does it make a difference? Check out this video of last year’s Google I/O about SPDY and you be the judge.

- Non-blocking servers.

The Mapbox guys get it. They use node.js for serving their tiles. Do you want to understand why this is a good thing? Check out this presentation by Ryan Dahl 3 years ago which gives an overview of why this is the case.

Anyway.

I can go on and ramble forever, but I want this to be more constructive.

**The discussion around OGC specs should be about what GIS is going to be like in 5 years in the future. **

Why did the OGC not work with the W3C to push WebSQL through (now stalled)? Imagine spatial extensions in every browser on the client side?
Why don’t we have a good spec about spatial replication, spatial changetsets, optimistic/pessimistic/long-transaction versioning, etc?
Why don’t we have specs that take advantage of web stateful connections?
Why don’t we have a spec for highly compressed geometries?
Why don’t we have a spec that defines better editing capabilities? (hint: WFS-T is not enough for several editing workflows)
Why don’t we have a spec that defines how to truly take advantage time-based datasets?

The list goes on.

Instead, the community as a whole is having long discussions analogous to the one about whether 3857, 3785 or 900913 was a better number for the Web Mercator definition.

Listen OGC, want to see a good standard definition? Check out MBTiles. Easy to implement, and to the point.

Want to change? Design/Define for the future - not for the present nor the past.

UbuntuGIS - GIS on Linux

Wed, 08 May 2013 17:50:00 -0700

I sometimes get surprised to find out that some people don’t know how easy is to get GIS packages on Ubuntu. UbuntuGIS is really one of the easiest ways to get up and running. You will notice that there are two repos.

UbuntuGIS “Stable” which has really old packages. You most likely don’t want that.

UbuntuGIS “Unstable” which is really not unstable at all. It just has newer packages. You do want that!

To get it working in your Ubuntu system add the ubuntugis-unstable repo:

sudo add-apt-repository ppa:ubuntugis/ubuntugis-unstable -y sudo apt-get update sudo apt-get upgrade

Now you can install all kinds of cool packages.

sudo apt-get install postgis gdal qgis

Is an example of how to get gdal, postgis and qgis ready to go.

Enjoy.

360 Streetview-like views from Perú

Tue, 02 Apr 2013 17:29:35 -0700

I took these a couple of months ago. Man, I miss Perú. The 360 views came out a lot nicer than what I expected

https://plus.google.com/photos/100825893460454450520/albums/5862409760288820561

My PyCon talk video is up in the PyCon video site. Realtime...

Thu, 21 Mar 2013 07:38:00 -0700

My PyCon talk video is up in the PyCon video site.

Realtime Tracking and Mapping of Geographic Objects using Python.

Knight News Challenge

Mon, 11 Mar 2013 14:44:26 -0700

Running a two person startup is not easy. Regardless, every time there is an opportunity to make true impact while working on your startup at the same time, it is truly an exciting opportunity. If you got a sec, we could use some votes in the Knight News Challenge. All we need is come clicks on the “Applause” button.

Sometimes bugs are beautiful

Tue, 12 Feb 2013 16:32:29 -0800

Sometimes bugs are beautiful

SQLite Homebrew Errors with Virtualenv

Mon, 11 Feb 2013 15:15:19 -0800

If, like me, you have recently experienced some sqlite errors after having updated Homebrew, it may probably be related to the fact that sqlite just got changed to being a “keg-only” formula.

The issue is that the python virtualenv environment correctly links to the Homebrew-installed sqlite version, but when trying to run it, it doesn’t find it. This is likely to happen if you use virtualenv.

A quick workaround until that bug is fixed is to force the creation of the sqlite lib soft links in /usr/local/lib. You can do this with:

brew link --force sqlite

GDAL/OGR plugin for ArcGIS v0.6.1

Tue, 29 Jan 2013 17:15:00 -0800

I updated the installer. It has GDAL trunk with support for 55 formats.

Enjoy - and please submit bugs!

Blob post about AmigoCloud's GDAL/OGR plugin for ArcGIS

Mon, 28 Jan 2013 12:09:36 -0800

Bill Dollin’s has a nice blog entry about using the GDAL/OGR plugin for ArcGIS in his GeoMusings blog.

Want to integrate ArcGIS and various Open Source formats? This is certainly a way to do it.

What is an ESRI GeoDatabase?

Tue, 15 Jan 2013 09:01:32 -0800

For those of us dabbling in geo work, It is not uncommon to hear the term GeoDatabase. Sadly, it is also not uncommon to hear the term GeoDatabase used incorrectly. Sometimes people use it to refer to ArcSDE, sometimes they use it to refer to that “Access mdb file”, sometimes it is just that “FileGDB thing”.

Somebody asked “What is a GeoDatabase?” last year in my favorite GIS Q/A site - and here is the answer from yours truly.

Improving Performance in PostgreSQL

Thu, 10 Jan 2013 14:08:01 -0800

Craig Kerstiens has two articles that are worth reading for those trying to improve query performance in PostgreSQL

- Understanding Postgres Performance - More on Postgres Performance

That should help you in understanding how to tweak SQL queries / indexes.

Nevertheless, I would hope you at least have an idea what some of the different postgresql.conf settings are for - especially since there are amazing resources out there to help you with this.

One of my favorite tools to see how tweaking affects my Postgres database is to use pgbench. If you have not use it, try it out.

Mapping Rookie Mistakes (#1): Always Geocoding on-the-fly

Wed, 02 Jan 2013 09:03:00 -0800

If you are hitting Google’s (or Bing’s) geocoding limit, you are probably doing something very wrong.

If your first reaction is to look for a workaround, then please STOP.

There is a reason for hitting that limit and you should be caching your results in your db instead.

You have been warned.

Update: Paul Ramsey and others kindly point out to look at 10.1.3(b) for currently allowed caching use cases.

Mapping Rookie Mistakes

Wed, 02 Jan 2013 09:01:18 -0800

There are a set of common Mapping Rookie Mistakes (tm) that happen very often. I am hoping I can refer to some of those so that somebody looking for an answer will stumble upon these.

For those experienced with GIS, these are blatantly obvious. Nevertheless, for the uninitiated in geo, these may not be so evident.

These will not be in any particular order, so the numbers only represent the order in which I wrote them - not order of importance.

Let’s start with geocoding on the fly

Your LGPL license is completely destroying iOS adoption

Tue, 18 Dec 2012 10:13:00 -0800

tl;dr If you have LGPL licensed code, please be clear if you want it to be used alongside proprietary libraries in iOS.

I hesitated about writing this because it will surely put some people up in arms (many of them good friends). So please let me clarify before throwing grenades.

This is not FUD. For the uninitiated in Open Source licensing discussions, “FUD” usually refers to when somebody (usually with a hidden agenda to support a particular proprietary technology) starts throwing rocks at Open Source in general. The idea is that this person will create enough confusion, that the proprietary option will be chosen instead.

I don’t have any hidden agenda.

I actually admire Richard Stallman (the GNU father) a lot. It is impossible to argue that without his full-blown activism, sacrifice, and energy dedicated to the Open Source movement, we would not be where we are today. We have Open Source libraries for practically anything. Yes, RMS can do extremely odd things while discussing complex issues, but nobody can take away that he is really the crazy genius that changed the world for the better. Truth is, I think we need people like RMS to create a sort of equilibrium.

In the GIS space, we have several key projects that are LGPL‘d. The main one that comes to mind is GEOS a port of the wonderful JTS library - and this is where the iOS problem begins (JTS is LGPL and thus GEOS has to be LGPL because it is derivative work).

GEOS is really at the heart most Open Source GIS projects; it provides the core geometry object model defined by a standards organization and it also has an amazing list of algorithms/functionality. Very popular key GIS projects like PostGIS, QGIS, GeoDjango, Spatialite (sqlite with spatial extensions) and others rely on GEOS for all the geometry needs.

Without GEOS, a lot of this applications become extremely crippled. Thus, why you will (sadly) not see strong adoption of spatialite on iOS.

OK, good. So why is this a problem for iOS devices?

Without getting into all the details of the obligations/freedoms/restrictions/whatever-you-want-to-call-it that come with all the different versions of LGPL, the LGPL license requires you to release all the source code of any library you link statically to. Let me emphasize the word static linking here.

So fine you say, use a shared library instead.

I can’t. iOS does not allow shared libraries!

Why?

They are afraid your app will download a new version of the shared library at runtime and change the behavior and thus circumvent the whole Apple App Store Review process.

Beefing up my anti-DDoS system. Why? Because this is the part where both camps start fighting like their life depends on it.

One side will say that Apple’s App Store is Censorship and that the LGPL clause is actually protecting your freedom. The discussion turns into a philosophical and ethical one. I can actually see how those argument are very valid.

The other side will say that the App Review process makes it more difficult for rogue code (notice difficult - not impossible). Having a review process reduces the possibility that your code will crash on devices after the first install because of something you did not test. It also reduces “duplication or redundant” apps - with Apple being the sole Ruler in choosing what goes in and out. Big brother I guess. But I also see how the App Store supporter’s point is a valid point.

Note that this problem does not exist in Android because it allows shared libraries to be compiled. Nevertheless, my customers use iOS a lot which means I cannot just “switch” to Android and “ignore iOS”. I need to use some proprietary libraries like Flurry and ESRI’s iOS SDK and many others for reasons outside the scope of this post.

Sigh.

Some people will argue that it is possible to do static linking of LGPL’d code and still be able to abide by the legal terms by providing the necessary binaries to be re-linked. This has no legal precedent and is still a very fuzzy argument. I would rather not bet my company on something so shaky as this.

So of course, some people may think: “Well then, you want to use other people’s hard work to profit in your [insert best insulting word here] startup. Sorry buddy, use something else! This was licensed as philosophical/political statement.”

And that is where they are right… and where they are also wrong.

OK, I should have added sometimes. For certain OS projects, like GCC, this is very true. Nevertheless, from personal experience, I’ve found many times when I am talking to leads/creators of some OS projects, that they are completely unaware that the default LGPL creates this complications in iOS.

The solution?

Some authors choose to add a static linking exception, others choose to re-license completely (think cocos2d that started as LGPL and switched to MIT). I am aware that for some projects with tons of contributors (think ffmpeg) it is impossible.

But if you have an awesome new project that could be extremely useful on iOS - and you have no philosophical or ethical issues with it - please please please please add a clarification to your licensing that covers this use-case. Even the Free Software Foundation doesn’t want you to use LGPL. So, please, pick sides, but don’t leave it in limbo state. If you don’t clarify, you are just completely destroying iOS adoption.

Hey, if you want me to release the changes / updates I make to your LGPL library, I have no problem with that whatsoever. I do it all the time.

What I refuse to do entirely is to completely ignore the licensing obligations altogether and just start using the library. Sadly, there are examples of Spatialite-with-GEOS/ffmpeg/put-your-favorite-lgpl-library-here code in the Apple App Store with developers who do not care one bit that they are violating those terms.

**Update (1/8/13): ** Corrected link to the current JTS site.

Topology and Routing Graphs in GIS

Thu, 13 Dec 2012 11:28:00 -0800

I realize that from a theoretical, formal, standpoint I tend to be a bit relaxed with my terminology. You could argue, I am practically asking to feel the ire of (in this case) somebody classically trained in Mathematics!

Nevertheless, during grad school in Computer Science, an amazingly smart professor explained to me the distinction about Theorists and Practitioners in such a clear way that I could finally make sense of the horrendous chunks of code that I have seen from people that I would otherwise think of as brilliant.

At some point of doing geo-work (hopefully) you will face a problem that has to be solved by creating graphs. User andytilia at GIS-StackExchange asked this very question..

In my answer, I tried to explain how creating a graph from GIS data is more than splitting your features in edges and nodes. It is about creating a graph that is optimized for your particular problem.

You are an amazing engineer, but you are a terrible fit for our startup. Apply to a later-stage startup instead!

Mon, 03 Dec 2012 12:19:54 -0800

Update (based on some comments I received): I am not recruiting at this point for either my current or previous startup.

A year ago, after the last startup I founded had closed $1.8 million+ in Series A financing, I interviewed a guy (call him James) that was considered one of the best engineers in his area which I am sure Apple/Google/Facebook would fight to the death to hire.

Nevertheless, I kept thinking to myself:

“James, you are an amazing engineer, but you are a terrible fit for our startup. Apply to a later stage startup instead! Adding you to the team would just really harm the startup.”

Honestly, I was surprised at the amount of other engineers I spoke to who “wanted to work at a startup”, but had no sense whatsoever about the different stages that a startup (hopefully) goes through, just like this guy.

Even though we had more than couple of million dollars in the bank, we were still working on our process for finding a good sustainable and scalable business model.

We were in an early stage back then.

But most engineers I spoke to did not get that. “We should be talking about a higher equity stake, not a higher salary”, I kept thinking to myself.

They heard “million dollars” and automatically assumed you would pay them $135K /year. What a waste of my time and his/her time that was! Those people should have been filtered out from the beginning.

Now, before you get all up in arms about this, let me elaborate a bit more.

I get it. As an engineer myself, every week I get frustrating moments when I question if I am nuts for not taking that cushy $150,000/year job that I get offered so often. Not having to deal with the legal implications of running a startup (e.g is the Privacy wording correct in our current Terms of Service?) or following up on missing payments for those short side-consulting contracts that I took to bootstrap the startup. It is nuts!

And then I remember what it was like when I worked at big corporations. I stopped learning and growing as an engineer. My co-workers were incredibly smart people, but the more I stayed, the more I felt like the theme song for Weeds.

If you are applying to an early stage startup, you should want to have skin in the game and you should enjoy being a jack of all trades (e.g. there will be no “QA” or “Build” department - we should incorporate it to our process).

For those people applying to startups in the Bay Area, like James, please consider these things before joining a startup:

1.- Early stage startups are mainly about taking more risk rather than getting paid more.

I realize you (like me) live in the Bay Area where $300/month for a parking spot is too common. Of course you have to make enough money to not have to worry about paying for things, but the stage you enter should be aligned with those considerations.

Want more equity? Take less money. For a startup in their seed / Series A / Series B rounds this is the best choice.

Want more money? Take less equity. For a startup that is in their Series B / Series C / about to go IPO, this is the best choice.

The Cash and Equity are actually inversely proportional to each other.

At the early stage I will offer you more equity. A fair amount actually. And just like me, you will have a one year cliff on a 4 year vest schedule.

2.- Let’s not even talk about job-security

You live in the Bay Area. Just like my startup, there are several other startups trying to recruit you, too. If my startup tanks (and most startups do), you will have a job right away. In Silicon Valley, good engineers are the real currency. As an engineer, you are part of the group of lucky people that are isolated from the current economic woes. So why even bother having this conversation?

3.- Your health is important

Maintaining a work-life balance is important (nothing more detrimental to productivity than burnout). You have to get out and do other things, and whatever startup you apply to should understand that. The personal time of your co-workers should be respected. In addition, your health plan should have been part of the budget and should be a good one.

4.- You have to be willing to learn because you will do several things outside your comfort zone##.

It is a given. You cannot just want to be the “Javascript expert” and not touch server code. Sorry. For an early stage startup you will touch Server code, Client code, deployment scripts and tests. This is huge plus for some people, because they becomes amazing engineers. For others, who just want to be experts at one thing, they are a much better fit for a later stage company.

Back to James

James did not ask me once about health insurance and did not really care when I told him about the plan. He claim he worked crazy hours, loved to do it, and expected everyone else to do the same.

He had never worked at a startup, but did want to try the “startup thing”, so he thought he wanted a big equity package alongside a big salary . He refused to acknowledge how those things were inversely proportional and took the two offers we gave them (big salary/small equity and small salary/big equity) and created a custom big salary / big equity + bonus counter offer that was laughable at best.

Of course, James wanted to continue doing just that one thing he was good at, [X]. Nevertheless, he did not want to touch anything else.

James kept asking about job security, and in his case, it was seriously irrelevant (did I mention Google/Facebook/Apple/Microsoft would kill for this guy?).

Truth is that James should not have been looking at a startup in the first place. Although he was one of the most brilliant (and nicest!) engineers I ever spoke to, it was a huge waste of time for everyone involved.

Automating your Build, Code Quality Metrics and Testing using a Continuos Integration Server

Wed, 28 Nov 2012 08:00:00 -0800

The truth is that having good code takes work.

Nevertheless, you have several tools that can help you with this problem. Jenkins is one of those tools. If you have heard of Hudson and this confuses you, you are not alone. Jenkins is a fork of Hudson that spurred after some drama that ensued shortly after the Oracle acquisition of Sun.

Jenkins has its quirks - no doubt about it. But setting it up is worth it. If you have Ubuntu, getting a standard installation is easy..

   wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add -
   sudo sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
   sudo apt-get update
   sudo apt-get install jenkins

This works fine and dandy as long as you run your server internally. If you are exposing your server to the Internet, then there are several things you will have to do to secure it. I would recommend you look at least at two things:

Use SSL with Jenkins (one way is with a proxy)
Consider using the GitHub oauth plugin. That way you can authenticate using your GitHub credentials (and also manage access to the Jenkins jobs through it).

So what is so great about Jenkins besides being a web-based build system? Well, it has a plethora of plugins.

A few examples of cool plugins:

Violations plugin

Shows results of code quality tools.

Trends between builds

Where they occur

What the violation is

Valgrind plugin

In case you want to know where you code is leaking.

Android Lint plugin

You do want to know that your Android code is sketchy right?

XCode Plugin

For building your iOS projects

Cool huh?

Cross-platform (iOS/Android) Mobile App development using C++

Tue, 20 Nov 2012 14:53:00 -0800

At AmigoCloud, we use tons of C++ & OpenGL for our Mapping applications.

Funny enough, when I talk to tech-people about our startup and tell them that we have a cross-platform framework, the first words that come out of their mouth is “HTML5”. Although we do use HTML5 for some of our components (a topic for another day), they always end up looking surprised when I tell them that 90% of the code is C++ (the other 10% being platform specific GUI + glue code).

Yes. Actually, it gets better.

The truth is that the same core client C++ code runs completely fine on OSX, Android, iOS, Windows, Linux, FreeBSD and possibly other platforms that we have not bothered to attempt.

C++ is an awesome versatile language with tons of libraries that, when carefully chosen, will make your life easier because they work completely fine on different platforms.

Need to do threading? Use pthreads or Boost Threads.
Local storage? How about sqlite.
UTF16 support? Know about ICU (we use something different, but I had to mention it).
Network Access? How about cURL. Yeah, I know, the cURL API might not be the most beautiful thing. But writing a simple beautiful wrapper is honestly trivial.
JSON? simple json parsers, elaborate json parsers, make-your-own-json-parsers

You can have it all (mostly).

By now you may be asking yourself, “I know how to write C++ and use those libraries, but how do I consume them in, say, Android and iOS?”.

For iOS, you need to be aware that there is such thing as Objective C++ and this makes consuming C++ from Objective C trivial. There are several excellent articles in the net that describe how to do this.

For Android, you need to be aware that there is such thing as a native sdk (aka android ndk). Again, there are several good tutorials online that explain the process.

In our case, the GUI code is (intentionally) platform-specific because we want to get the native control feel for each phone that we target. We also have a small set of wrappers for phone specific things like access to the phone sensors (a topic for another post).

Is it all as awesome as it sounds?

Sadly - no.

IMHO, there is a huge downside to it all: the build completely sucks.

Think about how many targets you have. Just in iOS, you can have x86, armv6, armv7 depending if you are running this on the emulator, or different iPhones. Every single dependency that you add will need to be compiled for that target. Then think about debug + release. Yuck!

So what to do about this?

At AmigoCloud, we use a custom build system for this. Nevertheless, when I was looking into this some months back, I stumbled upon several great scripts to take care of this process.

CMOSS itself is simple and works. Perhaps, if there is enough interest, I’ll write a small “Hello World” app that uses CMOSS to build both iOS and Android apps.

Getting QGIS working on Homebrew

Mon, 19 Nov 2012 11:52:56 -0800

Sometimes installing QGIS on Homebrew doesn’t succeed. If you are running into issues with it, most likely, it is related to PyQt not being found. To install QGIS, try this Homebrew magic incantation:

brew remove pyqt
brew install pyqt #verify everything works fine
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH
brew tap homebrew/science
brew install qgis --with-grass --with-postgis

Done. As @mweisman points out, If you installed FileGDB previously, you will even get that driver picked up by your fresh QGIS build.

I have been playing more and more with the IOIO which is an...

Thu, 15 Nov 2012 10:00:40 -0800

I have been playing more and more with the IOIO which is an awesome alternative to Arduino. You can easily take your Android phone and control any custom hardware you build. Here is my Trollbot - a couple of servos I hooked up to the IOIO board and a bluetooth chip.