For me, the most significant development at Esri’s 2012 Developer Summit was the pre-release of ArcGIS Runtime. ArcGIS Runtime represents a new direction for building lightweight, focused mapping applications with Esri technology. The resulting applications are responsive, trivial to deploy, cloud friendly, and optimized for their target platforms – be they mobile or desktop.
The first hints about Runtime came at the 2011 DevSummit, more was revealed at the 2011 UC (see especially the third slide for platform support), and this year’s Esri Federal GIS Conference brought a demo and technical overview.
I see Runtime as a natural extension of two larger trends: Esri’s focus on a web service architecture (e.g. the transition towards ArcGIS Server and ArcGIS Online), and the proliferation and success of small, focused applications on mobile devices.
What is ArcGIS Runtime?
ArcGIS Runtime is a framework for developing map-centric applications with functionality added via widgets (for editing, geoprocessing, introspection, etc.). The user experience and programming model is consistent across desktop and mobile devices — “Desktop is just another device” — but is optimized for each platform’s capabilities and programming model. This means great user and development experiences on any one platform, but no portability of Runtime applications between platforms — a wise trade in my view. Map data and geoprocessing functionality can be accessed over the web (via ArcGIS online or an ArcGIS Server) or locally in tile, map, and geoprocessing packages.
The programming model closely matches existing web service APIs and treats local and remote data identically — a trick that’s accomplished by spinning up a tiny embedded ArcGIS Server to manage local resources. This web-service-centric approach implies coarse-grained interfaces and is naturally parallelizable (think performance, responsiveness).
Highlights
I found the following aspects of Runtime most interesting:
- Performance. In the demos, application start-up, map pan/zooms, and graphic animation were all extremely fast. These are recent improvements — they talked about redoing the drawing code for a huge increase in performance — and were well received. Getting the best performance (especially for start-up time) requires taking control of when the embedded services are started and stopped, a minor additional effort over this otherwise automatic activity.
- Deployment. It’s as easy as copying a folder, and nothing is left on the target machine. The minimum configuration is 10 Mb, and you add only the additional packages you need.
- Embedded Server. As above, the benefits are a consistent interface to local and remote data and processing, and good alignment with ArcGIS Server and ArcGIS Online. As a developer, I also find the minimalistic embedded web server and common C++ core (leveraging process-level parallelism and shared memory) cool.
Licensing
The most commonly asked questions about Runtime were around licensing. Some of the responses were inconsistent (and all were subject to change), so take the following with a large grain of salt:
There is a free (i.e., no extra cost to deploy) version, and a non-free one, along with three optional extensions (Network Analyst, 3D Analyst, Spatial Analyst). Licenses are purchased in packs of 25 (or possibly 50) and follow an honor system. (You embed the license key into your app, and then pay Esri based on the number of times you distribute it.) The non-free license is expected to be similar to MapObjects and in the “low hundreds of dollars” per deployment. Maplex labelling is included. If the customer already has an ArcObjects license, nothing further is needed.
Coming Soon
Two major upcoming features in Runtime were announced: 3D viewing (right now you can do 2D viewing and 3D analysis), and improved support for offline or partially connected scenarios.
Future Thoughts
One of the questions I’m left with is, “What does it mean for a future ArcGIS Desktop to be based on Runtime?”. I missed the ending session where Scott Morehouse revealed this would be the case (but my colleagues didn’t; see also Dan Levine’s comments on the GISi blog). Perhaps it means we’ll see ArcGIS Desktop on Linux or Mac? Is it possible to build such a rich editing experience on top of the coarse-grained Runtime? All will be revealed in time.
We’re also thinking about how FME might leverage Runtime’s new capabilities. Could we use Runtime as another option for reading and writing File and SDE Geodatabases? For now, the answer is a tentative no (especially as there is no advantage over File Geodatabase API for the former). What about exposing the included Geoprocessing capabilities in FME Desktop? (Runtime is off-limits to FME Server which would have to use ArcGIS Server.) Again, the answer is a tentative no, as there isn’t a good alignment between that use case and how Geoprocessing works in Runtime. (You define geoprocessing packages with logic and data in ArcGIS Desktop, and then pass small amounts of data to/from the Geoprocessing Tasks in Runtime.)
Conclusion
ArcGIS Runtime is a significant leap forward for building and distributing focused, map-centric applications based on Esri technology. It’s well aligned with the overall Esri ecosystem (including the increasingly highlighted ArcGIS Online), and represents a deep commitment for the web services architecture – both locally and over the web. It will be very interesting to see how these technology bets pay off.
Are you planning on investigating ArcGIS Runtime? Can you see ways of us using the runtime in FME that I’ve missed? How do you think this successful mobile paradigm (many small focused applications) will affect desktop computing in future?
Photo and video have both been around for a long time. Recently we have seen interest in locating where photos were snapped, this is called Geotagging. There is a well developed standard for storing location in photos using Exif. As a result of this standard, all photos taken on cameras with a GPS can be uploaded to services such as Flickr and geolocated on a map without any intervention from the end-user.
While the geolocation technologies surrounding photos has matured, the same cannot be said for videos and this is what I want to focus on. Do we need a standard for geotagging videos? I think the answer is definite Yes!
Review
Videos are much more difficult to deal with compared to photos. Photos are a snapshot in time which one point represents well. Videos on the other hand span longer periods of time, a point represents where the video started or finished well but not the part in-between.
I have to admit I am no expert on the inner workings of video formats, but i do have a good idea on what capabilities I would like to see. Having done a bit of research there seems to be a number of ways that location is associated with video:
- Geotagging: Similar to photos, a point is used to locate the starting point of the video. I took a look at the Exif information for video produced by the iPhone, and it contains location information for the starting point of the video:
—- Composite —-
Avg Bitrate : 776 kbps GPS Altitude : 34 m GPS Altitude Ref : Above Sea Level GPS Latitude : 49 deg 15′ 38.52″ N GPS Longitude : 123 deg 4′ 24.60″ W GPS Position : 49 deg 15′ 38.52″ N, 123 deg 4′ 24.60″ W Image Size : 480×272 Rotation : 90 - GPX Syncing: Devices record a GPS track at the same time as recording a video. Applications then consume the GPS track and video, since the time matches on the GPS and video you can tie the two together.
- Native Storage: Contour have a helmet camera with a GPS built in which actually stores this information within the MOV file using the NMEA format rather than maintaining it in a separate GPX file.
Proposal
Contour is moving towards what I believe we need for video. A standard which allows us to very easily tie together individual frames with location. On a more technical level, I want to be able to programmatically extract the latitude and longitude for any frame in the video. If we had that then it would allow us to do some amazing things (thanks to Dave Campanas for these ideas):
- Spatial Queries: Ask questions like “Which videos are under 10km in length?” or “Which videos have a section shot within this bounding box?”. I think this is really important as one of the issues with video is the volume of data that is produced. If the whole video was spatially aware you could search and organise your videos much more efficiently. For example, people unfortunately decided to riot here in Vancouver last year after their beloved hockey team lost. In order to identify suspects the police encouraged people to send in photos/videos of incidents. With over 1 million submissions searching must have been a timely process. But with fully georeferenced videos they could have queried which videos fell within a certain location they were investigating.
- Geo clipping video by area of interest. You would now not only be able to clip a video by time, but by location or distance. Continuing on with an example above you could query all videos in the area you are investigating and then clip the video just to that area too. As a result you would have to review only spatially relevant video.
- Select/relating to other objects: Add a geographic buffer around a video and select objects that are within a proximity of where the footage was recorded. This could add huge value, allowing you to simply merge together your existing spatial data accurately with video. An example would be to select all organisations (so you can draw up a list of contact details) that were in proximity of videos containing vandalism.
- Extract individual frames: Extract closest frame/clip to a target point from multiple videos. An example would be if you know where an individual had committed an act of vandalism from a photo, extract the closest frames from the videos surrounding the incident.
Someone at OpenStreetMap has also seen the value in adding location to the entire length of video. The article walks through their attempt at video mapping using the Contour GPS. This is another great use case.
Conclusion
In my view the hardware is here, so let’s wrap a standard around it so we can start building awesome applications! It would be a missed opportunity if all of the different device manufacturers use their own methods to georeference video. Interoperability would be destroyed and will make it difficult for applications to spring up that wrap innovative solutions around what could be a powerful piece of technology.
The technology of data movement is getting a lot more fun and exciting. In the past the data connection latency between data producer and data consumer was measured in days at best and months or years at worst. In today’s fast-paced interconnected world this doesn’t cut it. To support the latest applications the latency is expected to be real-time; measured in seconds or less. Data consumers increasingly expect to be able to subscribe and then receive data notifications as things happen.
Delivering this performance requires systems with new event-driven architectures, as old batch-oriented systems aren’t able to meet the need. Another exciting aspect of this real-time connection is that the line between data consumer and data producer is blurring, with many systems’ users being both. This is a natural evolution to the ease with which data flows in these new systems.
The Benefits of Event-Driven Architecture Systems are Huge
Here’s just one example. Many police departments provide their officers with a morning report showing all the crimes that have happened within the past day or week. With the event-driven architecture, police departments can now relay reports to officers in the field as crimes happen – a massive improvement making it possible for officers in the field to be more operationally aware of what is going on around them. These new systems also make it easy for citizens to report crimes as they occur.
Other examples include:
- Citizen Reporting System for Local Government - Graffiti, potholes, crimes, traffic accidents
- Severe Weather Reporting - Floods, hurricanes, snowstorms, lightning, tornadoes
- Public Utilities – Damaged facilities, service outages, emergency client response
- Emergency Response – injuries, crimes in progress, fires, traffic accidents, Amber Alert, natural or man-made disasters
- Traffic – congestion reporting, traffic accidents, road closures, construction
The Challenges Switches from Supporting Formats to Protocols
Whereas in the old batch days of moving data the challenge was all about data formats, it’s now expanded to also be about protocols. These new subscription-based systems keep subscribers up to date by sending notifications through any number of protocols. Similarly, the more protocols that the data reporter is able to leverage the better.
For these new systems to flourish they must be able to plug into as many other systems as possible. From Twitter, to sensors, to cloud-based data stores such as Google Fusion Tables and DropBox, to other notification systems such as Pusher and Amazon SNS – the more the merrier. Sometimes the most interesting protocols are not those that are new or exciting, but older established protocols such as UDP or email. Above all else, a state-of-the-art notification system must support mobile devices.
Our Experiments with Subscriptions and Notifications
Our own experiments have found this new model to be both flexible and powerful. To test this we built a very simple event notification system using FME 2012 Server SP2. This system which is completely driven by workspaces (i.e. no backend code) enables events to be logged through a web page, via email, and via mobile devices. As part of this experiment we built two mobile apps: one for the subscriber and one for the reporter – not in the Apple Store, yet…
The biggest surprise was how useful email was as both a reporting and notification mechanism. Need to report data? No problem; simply take a picture and mail it to the system. Want to be notified of updates? We can do that too with email. Email it turns out is a very easy entry point into the system. Want to an email based data validation system? Trivial.
We will be showing some of the things that this new architecture can do for you and your organization (shipping with FME 2012 Server SP2) on our upcoming World Tour. You can also bet that I won’t be able to resist sharing some of the exciting details on Twitter as well (@donatsafe). Here’s an overview video and a video that shows how to try it for yourself.
Will You Accept the Challenge?
The future of data delivery is changing. The subscription/notification model and its event-driven architecture make data available as never before. With this new capability organizations are able to ensure that their users are making decisions with the most accurate and up to-date data.
What uses do you see for this exciting new architecture? How can your organization benefit from real-time data movement?
