Alex Barnett of Bungee Labs took a look at 8 Trends in Software as a Service Platform which highlights some of the movement toward web services moving forward. This ties in nicely with what I was saying last week and what Paul Bissett also hit on.
The ProgrammableWeb blog also looked at all the mashups in their directory and came up with a pie chart listing their API of choice. Mapping APIs are quite popular (which I think must of us would have expected)
Now the ProgrammableWeb directory is by no means complete, but the sheer number of mapping APIs really shows that there is demand for geo web services.
Let me take a step back here and say this. I still don’t see desktop GIS being replaced by web services anytime soon. There is just too much lifting that needs to be done to even think about doing that and even many web mapping sites would be better served by rolling your own ArcGIS Server, MapServer, MapDotNet Server, GeoServer, etc than subscribing to ArcWeb, deCarta or GYM. But even those who go the whole 9 yards and throw up ArcGIS Server Advanced Enterprise are looking at using a web service to augment their own datasets. Heck even ESRI ArcGIS Desktop users are gearing up to integrate web services into their work flows.
17 Comments
what´s the % of Virtual Earth?
James:
A big part of the value is audience reach. Cheap, easily deployable web services that require minimum training to figure out and use are so much more valuable to an organization than the web-apps-for-everyday-GIS-users that lie about unused except by the already-initiated.
The transportation authority in Denver today rolled out their new mapping app (http://gis.rtd-denver.com). As a public facing app, a GMaps or VE solution would have been a) more usable (ESRI icons for everyone?), and b) considerably cheaper.
In short, we’ll all be better off when the user experience drives the back-end technology choices and not vice-versa.
BT
Well said Brian. My post from last week said to focus on the product first, then the technology second. There is a web service out there for you once you pick what you want to produce.
As for the RTD app, the “wait while map loads” front end is so archaic. I can’t believe this is still acceptable.
This is a good discussion. Compare the user experience from RTD site mentioned above with Google Transit Beta for Austin.
Kirk
That comparison is quite illuminating. Is that the vaunted ArcGIS Server at work in the RTD app?
Sean, you are looking at ArcGIS Server, the .NET Web ADF and ESRI’s ArcGIS Online road web service as the background.
Not a fare comparison (pun intended) since RTD site doesn’t seem to support trip planning (!)
Take a look at Dallas Trip planner, based on Trapeze Software, and compare it to Google Transit for Dallas.
Incidentally, Trapeze does provide an exporter, so maybe they’ve chosen not to try to compete with Google on this.
Load a complex polygon into Google maps and see how it performs. I’ve done it and it brings it to its knees. My point is that there is a degree of complexity that is absent from these conversations. It’s not as simple as Commercial vs. Legacy platforms. Just how easy is it to tap into decades worth of legacy spatial data and seamlessly pipe it into whatever earth and maintain dynamic updates? How does one address the conflicting requirements of the business backend and api (i.e. local projection/coordinate system vs global reference system). How do you reconcile the absence of a service level agreement with the commercial apps when it comes to critical applications?
All this isn’t to say that the advent of spatial technology that we are witnessing should be ignored, rather, how do we seriously leverage both the new and legacy resources beyond the hobby shop level? I think it’s safe to say that there is a lot of false confidence behind some of the comments being made. I’ve had many conversations with decision makers who are responsible for building business cases regarding this technology and the common thread between us all is the need to create a holistic strategy that leverages all resources, provides an acceptable return on investment and mitigates risk. We all agree it should be done, and can be done… let’s talk about HOW it’s done. Whatever whippersnapper cracks that nut stands to be a hero or make some money in consulting… or both.
I think Brian Timoney’s company is definately an example of a company that “gets it”. Let the job pick the best tools not the other way around.
On a totally different note: Why does Yahoo Maps get no love? They really have a very nice platform with a lot of options (maybe too many options). They were the first to use JSON and implemented GeoRSS almost the same day as GMap. The only real mashup I have ever seen using Yahoo is batchgeocode. Yahoo also has more frequently updated street data than the other providers. I live in a fairly rapidly developing area and several times I’ve had the odd experience of getting directions to a fairly new street in which the route path was correctly overlaid on the map & the base map showed nothing at all to drive on. GMap & VE both had no idea about the new streets. If I had to choose between GMap & YMap, I would tend to go with Yahoo’s offering unless something really special was driving me to Google.
Matt, could what you noted about Google vs. Yahoo have to do with differences in their TOUs? I’m in the middle of working on a fairly simple OpenLayers site for my county using some of our own GIS data served up as WMS and possibly one of the commerical APIs as a base. After reading Yahoo’s TOU several times, I’m not confident that my intended use is compliant. On the other hand, Google’s TOU is much more flexible and there should be no issue if I use Google. It’s too bad because I’d really like to use Yahoo.
timmy, I was commenting on usability. Bottom line: despite all the GIS power in its platform, that RTD site isn’t as usable as the Google Transit site.
@Roger I’ll agree that Yahoo’s TOU is about as clear as mud when it come to the nitty gritty details. However I don’t think that is the main reason for such little use. I think it is because there is nothing TRULY special about the Yahoo Maps APIs. Google gets all the buzz & attention because they are Google, so people naturally flock there. Virtual Earth has a number of unique things to offer that clearly separate it from GMap. The “bird’s eye views”, full support for complex polygons as first class objects, and the 3-d mode in the same application all make Virtual Earth pretty cool. The only thing special about YMaps is for flash developers. It has a Flash API available and if you’re into Flash you could do some pretty cool stuff there.
@timmy for commercial API’s I think VE is the best positioned to integrate with traditional GIS workflows. If one wanted to, they could make an online app with similar functionality to ArcView 3 with VE and a simple data translator/processor backend (ie GDAL/OGR). And I bet it would be a heck of a lot faster than ArcView 3.x was.
You might want to check out the trip planner at http://www.mbta.com. Here is an example of a “commercial” trip planning product (Trapeze ATIS) coupled (mashed?) with Google Maps.
Since this seems to be turning into a transit GIS thread, here’s an interesting writeup on MTA’s video heavy security system that’s way behind schedule. I wonder how much geospatial tech is involved. http://www.nydailynews.com/news/2008/01/15/2008-01-15_mtas_in_slowmo_on_hitech_cameras.html
Maybe they could publish video services and let clients like Google Earth consume it. http://code.google.com/apis/kml/documentation/kml_tags_beta1.html#samplevideo
It’s interesting to look at the Denver site with Firefox’ s Firebug add-in to see the Ajax calls. That might be valuable information when customizing or debugging an ADF app. Otherwise, it’s another app that’s nice enough, but doesn’t get me excited about the Web ADF, which I think is a shame for the cost of these ESRI products.
@timmy, Regarding your complex polygon issue in Google Maps, I would suggest you take a look at Virtual Earth. It handles large numbers of points much better than Google Maps. Of course, at a certain point it makes more sense to handle the polygons as image overlays instead of sending the actual geometries.
In response to your question, “Just how easy is it to tap into decades worth of legacy spatial data and seamlessly pipe it into whatever earth and maintain dynamic updates?” Maybe that’s a “tilting at windmills” ideal that shouldn’t be pursued. After all, many organizations have bought into the notion of data warehousing for analysis of historical data of sales data, for example. Why, then, should there be the expectation that an extraordinary amount of spatial data can be served with up-to-the-minute data updates?
Maybe a different type of webservice. But it is for sure one:
Framework 1: http://webgen.geo.unizh.ch/
Framework 2: https://incubator.52north.org/twiki/bin/view/Processing/52nWebProcessingService (based on OGC Web Processing Service)
Both are intended to work with Desktop GIS, thus will not replace them, but can be included in your browser application aas well. You can add the processing service you want – as far somebody does programm it. I would call it a true “GIS Web Service” although the outlined/shown concept is rather for Map Generalization/Map Data Processing.