<< Back to WG5 Geo-AI       Next to Part II : DevOps and Scaling >>



UN Open GIS - GeoAI Blog

Building a GeoAI Tool

Part I: Introduction

By Tomaz Logar, Big Data Engineer, UN Global Pulse

June 10th, 2020

GeoAI WG

In 2020 the UN Open GIS initiative has established a new working group - GeoAI. As the name suggests, this working group will promote the use of artificial intelligence in geospatial information systems within the United Nations. Since we are UN Open GIS, all this will be done within the open source paradigm.


As a way of marking the establishment of the GeoAI working group we’ve decided to publish a series of blog articles. This series will write about the development process - past, current and future - of a Geographical Information Systems AI tool we’re creating in the United Nations. It will be written from a rather technical perspective.

The upcoming blog articles will cover these topics (but may change depending on future tool development events):

  • Introduction and Architecting
  • DevOps and Scaling
  • Model Adaptation
  • User Models and Framework Isolation
  • Multi-user and Highly Interactive User Interface
  • Front End
  • Parallel Processing
  • Feature History and Future Roadmap

PulseSatellite

The tool in focus will be PulseSatellite - a product of collaboration between UN Global Pulse and UNOSAT that has been publicly presented for the first time in February 2020.

The main aim of PulseSatellite is to enable or simplify the use of artificial intelligence models with geographical imagery. It is being built with scaling in mind, gives an option of more than one person working on the same map at the same time, and can be extended with proof-of-concept user models.

Architecting for Flexible Scaling

An important requirement for our tool is the ability to scale imagery processing. At the United Nations it’s rather easy to come across projects that will overwhelm small size setups. On the other hand we can’t afford to have a large amount of hardware being on standby for those large spikes.



Thankfully there is cloud computing. It’s awesome that we have the ability to provision infrastructure in minutes with a few remote commands. And even better that we can turn it off and stop paying the bill once we don’t need it anymore!

We are currently building for deployment in Amazon Web Services. We’re keeping an eye on not vendor-locking our tool to it, though. A bit of vendor-specific code is acceptable, but let’s not go nuts with depending on juicy services... We will be using some proprietary services to accelerate the development, however every such service must have an open source alternative - we’ll just implement it down the line.

PulseSatellite is a rather complex tool that has a lot of growth possibilities. We must be careful not to create it as a monolith or else it will become unmanageable rather quickly.

That’s why we’ll do our best to separate our concerns and break our tool down to interacting microservices.

Need imagery tiling done? That’s a microservice. Need public satellite imagery download functionality? That’s another microservice. Need to run PyTorch models? Another microservice. Don’t like PyThorch, want TensorFlow? Good - another microservice. And so on.

OK, perhaps not every service will be all that “micro” but we’ll squint our eyes a bit and let it slide.

We’ll also need a couple of ways for these microservices to work together. We’ll use a publish/subscribe message bus for internal backend and an HTTP API implementation with pub/sub messaging overlaid for backend-frontend communication.

Microservice-oriented architecture is one pillar of our development. Microservices give us development flexibility and increased reliability. However, we will not be running one single cluster to implement our tool. We will also need deployment scalability. We’ll need many clusters in different parts of the world. And the solution for that is infrastructure as code.

There is one final note on flexible architecture, especially important to operating in the United Nations... We are a global organization. There are many parts of the globe where internet connectivity is not good or is completely nonexistent.

Such locations might benefit from an offline version of our tool. We will keep in mind that our architecture should make a small deployment possible - running on a laptop. A strong one, but still a laptop.

Building Block Implementations

Our tool is an internet browser based application and its logical building blocks are currently:

  • Web server,
  • User interface,
  • Imagery tilers and
  • Model runners.


All backend services are running on Ubuntu 18 LTE operating systems.

Web server is a Node.js service. We chose Node.js because a sizable chunk of code is being written to be run in a web browser. Making both front and back end use the same language seemed the wiser choice.

On the other hand, imagery tilers and model runners are written in Python because most data science and AI code is written in that language.


There are three mechanisms of data persistence:

  • Database: Postgres with PostGIS extension
  • Distributed file system: AWS’s Elastic File System
  • Caching: Memcached and Redis


And three data interchange mechanisms:

  • Postgres notify/listen messaging
  • HTTP
  • Websockets


Postgres is a natural choice for a database in applications that work with spatial data - PostGIS extension makes it a leading contender in the open source landscape.

Our services need a common file repository in order to collaborate. We are currently using Elastic File System (EFS) in AWS for that.



Common downside of distributed file systems is that files are eventually consistent, meaning that it takes some time for a written file to become visible to all nodes. That’s the first reason we add cluster caching to the mix. For file writes and reads we first hit Memcached in order to get rid of 404 for the few seconds of cluster file inconsistency.


There are three routes of programmatic communication going on in PulseSatellite - between backend services, from front to back end and the other way around.


Backend services use a publish/subscribe messaging to coordinate their work. Since it’s already there, we’re making use of Postgres’ notify/listen system for initial development.


Communication from front to back end is the most vanilla part of the mix. It’s just HTTP API calls to the web server.


The other way around is a bit more complicated, though. We want users to get a constantly updated view of backend events, especially when they run long-lasting processing. That’s a job for Socket.IO - a websocket based publish/subscribe messaging library.

Implementation Alternatives

We know that some of our implementation choices have a down side or two. That’s why we always keep our eyes on better options. However, those usually come with higher effort or cost requirements, so it’s important to choose what makes sense at that particular time.

Different Database

Like I wrote earlier, Postgres+PostGIS is currently optimal for our case. However it is a relational database after all and might get sluggish if it gets big. In that case we might consider sticking with Postgres, just switching to a columnar storage engine or upgrade to Postgres-XL.

Different File System

AWS’s Elastic File System is a great service to have. However, it’s not hard to imagine real-life scenarios where we would have to deploy our tool outside of AWS. Now, if we move to another cloud provider, they will probably have a similar alternative. But if we want to remain completely vendor-agnostic we could switch to some open-source option such as Lustre. Or, if we steer away from cloud deployment, go for a hardware solution and connect a Network Attached Storage device.

Different Publish/Subscribe Bus

We are currently using the simplest and cheapest implementation of a pub/sub bus. It will most likely not last through some mildly challenging scaling. A Kafka cluster would be a good replacement in this case.

Different Caching

We’re currently using Memcached for our caching needs. However, we’ve already come to a situation where a library we needed only supported Redis and not Memcached. So it would seem that just going for Redis altogether will be the optimal solution in the future.

Different Cloud Provider


Although current deployments are spun up in the Amazon Web Services, we didn’t make our tool dependent on this vendor. It would take some work to switch over, but not that much.

You will be able to read more on this topic in one of the upcoming blog articles in this series.

Conclusion

So taking all these bits and putting them all together we end up with something like this:

Up next: DevOps and Scaling.

Image attribution:


<< Back to WG5 Geo-AI