At every conference I go to I try to identify one thing we could do that could really make a difference. While this may seem easy, it is difficult to walk away with one thing that really stands out. At the Esri conference the observation hit me square in the face – the importance of making things easy! (not hard)
A common mistake many software companies make is focusing on increasing complex tasks at the expense of focusing on making common tasks easier. For example, Jack Dangermond talked about ArcGIS 10.0 and “getting back to the map” – putting the map at the center of the user experience. The point here is to make it easier for users to do the most common tasks.
Easy vs Hard
When it comes to moving data there are many hard problems to focus on. The hard problem is seductive. It is after all interesting, challenging and mentally stimulating making it easy for smart people at technology companies to focus on these tasks and ignore the easy ones.
Reflecting on what we have done, our users most appreciated the small things that made ordinary tasks easier (the quick add feature and pink dot connector come to mind when thinking about our software).
I am not suggesting organizations start ignoring hard problems, but rather work to find the balance. When they do work on hard problems they will often find that the road to solving hard problems is paved with solutions for many smaller and easier problems. They should not ignore these small successes as it could be that some small easier problem you solve may have a much wider appeal than the hard problem!
The EasyTranslator
To demonstrate how something easy can be useful, we have written an fmepedia article that highlights a very simple and easy solution that is the by-product of us solving hard problems.
This fmepedia article; written by Ken Bragg, describes a little known service called EasyTranslator, which has been on www.fmeserver.com for over a year.
This service relies on a trivial workspace to convert data from any format to any other format that FME supports (hundreds of output formats are possible, but to make this service easy to use, we’ve selected an initial set of 12 of the most popular output formats). Of course to do this a lot of hard stuff is being automatically leveraged, as the EasyTranslator workspace exploits Generic, Dynamic, and Merge Feature Types technologies.
Now thanks to Ken Bragg (for the article) and Stewart Harper (for the new user interface), anyone can try the EasyTranslator on their own data.
This might seem like déjà vu to some of you. If you take the WayBackMachine back to 1996, you will find that we had another simple sample web service on our website. This “Live Demo” or web service ran for many years on our website. Of course back then it was restricted to 1 input format and 4 output formats. Technology has indeed changed a lot in the last 14 years.
I invite you to go ahead and give the EasyTranslator a try with your 3D and vector data. Converting data from one format to another has never been easier! Give it a try or read more about it.
And if you do try it out, please comment back and let me know about your experiences and what you would like to see from the EasyTranslator!
Back in the days when Google Maps was new (according to Wikipedia it is barely 5 years old), there was a movement to try to put custom data on top of the base map. In the early days there were no APIs for web developers or Google Maps based smartphone libraries. Instead people like Adrian Holovaty had to actually hack the javascript that powered the Google Maps front end to add their own data and embed the maps on their own webpages for early mashups such as the now-defunt Chicago Crime or Housing Maps.
These days, APIs, such as those mentioned above, make it very simple to create your own mashups with Google Maps tiles and your own data. For example, entering the link to a workspace that returns KML on a public facing FME Server into the Google Maps search box is all you need to do to show your data on Google Maps.
Mashups, of course, can get much more powerful than a simple KML file displayed on Google Maps. While GIS professionals may feel at home in powerful GIS tools or web interfaces, they are far too complex for the general public to use. Organizations are now beginning to understand this and are creating mashups that can be easily viewed in an environment that people are already familiar with – i.e. Google Maps or Bing Maps. One company at the forefront is Energy Australia.
Mashups for External Use
Energy Australia is creating mashups with Google Maps to show outages to the media and to the general public. Courtesy of our friends at Communica, here are two samples of how they are sharing their power outage information. (At home, BC Hydro is doing something very similar with Bing Maps.)
Outage affected area on Google Earth Backdrop
Simple outage mashup in Sydney for media briefing
Mashups for Internal Use
Energy Australia is also creating mashups for internal use to inform employees who are not used to GIS applications. These two samples detail pertinent customer and outage information (credits again to Communica).
Mashing up customer data, network and Google map
Outage modelling on a sub-station. Affected customers
So if you’re interested in making your data easier for everyone to use (not just your fellow geonerds), why not consider making a mashup?
[We have some examples on our website using FME Server with Google Maps, Bing Maps, and ArcGIS Server. If you need a bit more power of customization of your maps, you might also want to consider Open Layers.]
It’s said that most data has a spatial component (location matters) and that asking “where” questions can lead to useful insight. Sometimes there can be more than one aspect or way to frame something’s location, size, or shape – and different approaches have been taken to capture these relationships.
In particular, I’d like to highlight the different path GIS and spatial databases have taken in response to this challenge. I’ll then outline some considerations you might face when working with data that spans systems which have taken different approaches.
Examples of Data Spatially Represented in Multiple Ways
- The outline of a geographic area could be stored with different levels of detail based on the scale of interest (e.g. as a polygon with many vertices, a polygon with few vertices, or as a single point).
- Similarly, you might have a number of alternative representations, (e.g. choosing to represent some lakes as areas, some as points, but none as both).
- A road might be represented by both its center line, and by lines representing its edges.
- In some cases, you might want to redundantly store the same geometry in different coordinate systems or storage representations.
(This discussion is restricted to vector data, but in the broader sense you could have vector, raster, 3D models, LiDAR, etc. for the same entity or area.)
The Evolution of GIS and Spatial Databases
The traditional GIS model is that each individual entity (called a feature) consists of a single geometry and a set of attributes. These are organized into layers by common themes (e.g. roads, administrative areas), which are often constrained to a single geometric type (e.g. all points, lines, or areas). In this model, the scenarios above might be handled by multiple layers linked together by a common id.
Some of the first approaches to storing spatial data in relational databases followed the same idea, using primitive types to model layers of features, each with a single geometry and a set of attributes. This strategy remains in common use with database systems that don’t otherwise support spatial data, typically as standardized via the first option in OGC’s Simple Feature SQL specification.
Over time, many relational databases have introduced first-class spatial types. This means they treat geometry just like strings, numbers, or dates, which has made it much easier to work with and analyse spatial data in these systems. Another implication is that their tables may contain more than one spatial column – just like they might contain more than one numeric column – and that presents an alternative way to model the four scenarios discussed above.
The idea of modeling features as having more than one spatial representation isn’t unique to spatial databases. For example, the GE Smallworld GIS uses this concept, as does the GML interchange format.
Practical Implications
There are a few things to consider when integrating or converting data from/between formats or systems using these different approaches:
- If the same entity is represented in different layers, how are these different representations tied together? If this isn’t managed well, data can become inconsistent and lose value.
- In the database, what does it mean for one of the spatial columns to be null (missing), and what is the equivalent representation in the other format or system?
When modeling spatial data which may be usefully represented in different ways, consider how your chosen software best handles this case, and determine if the added value is worth the extra complexity. When using and integrating this data, it is important to keep the different representations and relationships in mind so that you make the most of your investment.
