Citymaps is your personal map of places.
Citymaps was built by a small team with a big idea: to create a mapping platform that is social, personalized and designed for a mobile-first world. Based in New York City, Citymaps was founded on the belief that maps should be more than just a tool for navigation. More fun. More personal. More inspiring. Citymaps offers a visually rich map, built from the ground-up, with over 80 million places worldwide. Citymaps enables users to create collections of places, or personal maps, with easily searchable themes so that users never forget a place again, and always have their favorite spots with them on-the-go.
Citymaps’ Technology Stack
At Citymaps, we have designed our technology stack to balance speed and scalability with flexibility. We are pushing the boundaries of mapping technology, and moving to a future where we will serve up unique, personalized maps for every user.
The core of our technology efforts fall into three areas: our cross-platform vector map engine and its related mobile client applications, our business API services, and our location data processing technologies.
Vector Map Engine & Client Applications
At the core of our client applications is our proprietary vector map engine. Developed in C++, the map engine is platform-agnostic and runs on the iOS, Android, and Windows operating systems. It is responsible for taking binary-encoded vector map tile data from our OSM-based map servers and rapidly rendering map tiles on the mobile client (faster than 60fps on some devices). It is has been designed to take full advantage of multiprocessor architectures, and includes adjustable memory and file caching to allow for short and long term storage.
Some of our map engine components include: a label renderer and collision detection algorithm that intelligently displays labels for streets, POIs, neighborhoods, and cities; a POI display system that surfaces locations based on popularity and/or personal relevance to the user, and a marker system that supports arbitrary images, extends simple markers into more complex ones, and associates arbitrary labels with markers.
Our map tiles are delivered in a custom binary data format optimized to minimize size. They are generated by our map tile server, written in Scala and Java, and served up by Amazon’s CloudFront edge-caching service for high scalability and responsiveness.
Our map engine powers our applications on iOS, Android, and a Windows-based mobile display platform that runs in 7,000 NYC taxis. We are also currently developing a WebGL port of our engine.
The map engine is currently available as an SDK. This SDK allows developers to create complex maps in a few short steps. The SDK hides the complexities of our engine, exposing only those functions the developer needs to build their map. Our development partners can use our Style Editor to customize the look of our map.
We use geo data provided by the awesome members of the © OpenStreetMap project.
Business API Services
A map is only as good as the data it provides, and we provide lots of great data via our business API services. These services provide data on venues, users, and user maps, and personalize the results to each person’s specific needs and tastes. Our API services consist of our core service (data about our venues, users, and user maps), our search service, our notifications service (manages push and email notifications) and our on-boarding service (asynchronously loading data from partner sites so you can use our applications without waiting).
Our map services are written in Scala, and served up by the Play application servers proxied by an Nginx load-balancer. Search services are provided by Elasticsearch, and the data is stored in a Postgres database cluster.
Application and user images are stored on our Riak cluster, and also fronted by Cloudfront. Our business objects are “lazy-loaded” and stored on an in-memory Redis cluster running on Amazon’s Elasticache service.
All these services require lots of communication to coordinate efforts properly, so we use a messaging bus (RabbitMQ) to allow the API services to talk to each other.
We store information on over 20 million businesses in the US, and process data on more than 100 million businesses, deals, and social media data points monthly. All of this data requires a lot of software to organize properly. This is handled by our two data processing services, our Ingestion Engine (IE) and our Venue Publishing Service (VPS).
Our IE is responsible for taking data from our business partners (via SSH, API request, or flat file), processing it for use within our system, then sending the data to our VPS via RabbitMQ messages.
The VPS is responsible for taking locations and deals discovered by our IE, grouping and de-duping them, and using our proprietary business rules to decide which to publish. Each time a business is updated by one of our business partners, the DPS runs the full suite of publishing tools, sends it to our web service to be published, and sends a RabbitMQ message to the API services to invalidate any cached copies…all within a couple seconds or less. It does this for hundreds of thousands of businesses each day.
We’re pushing the boundaries on what is possible with mapping technologies. The technical challenges are unending, which keeps us motivated and excited. Want to join us? Email us at firstname.lastname@example.org