Sometimes we care about data tied to both space and time: traffic, weather, or even where our friends are. Exploiting this information is tricky – it’s always changing and is usually only valuable for a short while. So, it’s interesting to see how the geospatial world is thinking about these problems.
A developing standard for traffic data – TomTom is trying to solve the problem of gathering and sharing live traffic data. Their OpenLR specification tackles one thorny part of the problem – how to efficiently exchange location information between devices with different maps. I find their approach novel and quite interesting; it finds intersections in common based on road properties, location, bearings, etc and then glues them together with offsets to form a path.
Tearing up the road once – Envista has a great idea: if cities and utility companies share their construction plans for the near future, perhaps they can piggyback projects together. Tearing up the road for new pipes in the same location where the telco will eventually run fibre-optic cable? Why not do it at the same time? It’s interesting to contrast this with other data sharing efforts (e.g. Spatial Data Infrastructures) which aim to make spatial data available more broadly, but don’t focus on fine-grained collaboration. I expect we’ll see more integration between collaboration and mapping tools in the future (a Google Maps / Wave integration, anyone?).
Disaster response – This is probably the most significant use case for real-time spatial data. It’s all about gathering timely data, visualizing it, and making good decisions, fast.
Social Networking – You can add location to your tweets, or use one of many tools to share your location with friends.
Targeted communication – Earlier, Don discussed a solution one city uses to send timely notices to interested citizens based on their location.
It’s great to see all this innovation into the intersection of where and when. What’s next?
The only truly 3d geospatial format, KML, has very substandard time functionality. That is hindering the progress of creation and distribution of this kind of information. Sadly Google has handed off KML to the Open Geospatial consortium which has done exactly nothing to improve the KML specification to date. Google made a big mistake and we are all paying for it.
What kind of time functionality are you looking for in geospatial formats and viewers? The OGC KML standard includes timestamps and time periods which can be attached to any feature, and Google Earth enables a time slider when these are present. Also, Google has taken advantage of extensibility built into KML (based on XML namespaces) to allow timestamps and periods to be added to camera views in Google Earth 5.