Posts Tagged ‘WeoGeo’

Spatial Is Special – There’s a (M)App for That

Thursday, November 12th, 2009

Part 2 – A New Hope

There have been some interesting conversations across the blogosphere on Google’s entrance into the basemap and navigation business. From an interested spectator point-of-view, I am a bit of a fan of the sheer audacity of Google’s mapping effort; creating a US basemap from scratch, building a navigation application, and rolling out a real-time sensor network (with 76 million devices) disguised as a mobile phone, all in the space of a couple of years. Well, that’s just crazy.  However, as much as I am a fan, this event is just one more example of the impacts of rapidly changing technology in our field (Part 1), making previous niches obsolete and forcing individuals (James Fee) and companies (e.g. Cloudmade) to adjust business models to just survive.

sadfa

Geo-powered apps are changing the game for developers

There were a couple of themes from these conversations that I found interesting. The first was represented by Peter Batty (and links therein), which could be broadly interpreted as “Content Matters”. That is, the cost (or lack there of) of the navigation application was less than important than the base content within it. The second theme was summarized by a podcast at Directions Magazine, which posited that the data didn’t matter. Adena and Joe’s point of view was that the application was going to overshadow the importance of the content. They felt that the application cost, functionality, and ease of use would generate more relative value than the content. I personally believe that both these points are two sides of the same business coin, and to be successful in this space you will have to have both great content, and a great marketing and delivery application.

Let’s start with the Batty et al.’s assertion that “Content is King”. In a frictionless marketplace of ideas and data, where the process of disintermediation has reached its peak, the lines of competition will be drawn around product price, branding (think Crest versus Colgate) and quality (think GM versus Lexus). This suggests that our market will continue to separate between the aggregation of (free) commodity data (10 meter USGS Digital Elevation Maps) and premium data (nationwide parcel data). I have been a proponent of premium content for a couple of years and I see it as a bright spot for geospatial professionals because good content tends to be localized providing niche geo-opportunities locally, across the globe.

An example of “premium-content-is-winning” may be found in the newspaper industry

Wall Street Journals Premium Content Drives Growth

Wall Street Journal's premium content drives growth

The Wall Street Journal has maintained its subscription-based revenue model all through the “content-should-be-free” era of the internet. It is now the only major newspaper in the US with a growing circulation, and is the nation’s largest newspaper by circulation. They demonstrate that the quality of content matters, and will continue to matter moving forward. Looking more closely at the difference in content provided by the #1 Wall Street Journal and the #2 USA Today, the Wall Street Journal might be considered a “premium” niche player, compared to the generic “consumer” news offer by the USA Today. Generic news may be found in a lot of places (for free). In the spatial industry, we might compare this to the “free” generic DEMS offered by the USGS and the “premium” high-resolution LiDAR surveys by companies such as Merrick. Clearly, quality content has value and people are willing to pay for it.

But Adena and Joe have a point. We consume digital content differently than other commodities such as toothpaste. Even if today’s premium navigation data becomes a commodity by virtue of the “less-the-free” data offered by Google, the data must still be delivered via a service and application that people wish to use. The consumption of content, and the value-added services built on top of the content, will depend directly on the quality of the application that delivers that content. In this case, the application will matter as much as the content. If either fails to deliver, the whole effort will fail.

While we may currently consider ourselves either data providers or application developers/integrators, I think our industry will move towards a Data-as-a-Service (DaaS) industry, where the data and applications are inextricably tied. I believe this will be the case for all platforms, including web, mobile, and desktop. And in this new DaaS era, the geospatial integrators may have an edge because they are used to thinking about data and applications simultaneously.

In addition, the economic process that is currently squeezing the revenues of integrators and GIS professionals may be turned to work in their favor, as the many sources of free, low cost, or open source software becomes their application supply chain. In the past, these integrators thought about their customer’s data and its integration within a proprietary mapping software stack. In the future, they have an opportunity to become vendors of DaaS, either for their customers, or for themselves. The combination of accessible data (low-cost or free) with low-cost applications and hosting will enable these professional to create premium DaaS niches, recouping the profit margins lost to the commodization of their IT skill set.

This is one path towards a new, hopeful future where the geospatial professional controls the fate of their destiny, rather than trying to survive on the leavings of giants.


A new hope for Geo-Jedi’s

Productivity and Cloning in the Spatial Data Industry

Wednesday, October 21st, 2009

Last week there was a brief twitter thread in the geo-community about cloning Adam Estrada. It started innocuously, but as such things often do amongst our chatter class of geospatial professionals, it degenerated rapidly. One could only imagine what the world would be like with multiple copies of a rabid Georgia Bulldog fan.

The technology for cloning GeoNerds has been developed.

This thread was followed by some great follow-up discussions from last week’s post on the new parcels in Google Maps (and see a better article here). It seems that our way of life in the professional mapping industry is going to change as a result of new data and technology that will be available at increasingly lower costs. That means that the players in the industry will have to change or die. Or put a little less morbidly, we will need to become increasingly more productive in order to stay ahead of the “free stuff” curve.

Yet, how do we become more productive with our time, e.g. make more money with less effort? Productivity varies across industries, and sectors within industries. Our industry can be basically broken down into three groups – software vendors, data vendors, and professional service vendors. In Adam’s case, he is in the professional service sector, working for Zekiah Technologies, and is in a similar position to many in the geospatial industry wrestling with the problem of being more productive.

The productivity problem with the professional service sector is that it is a consulting business. Revenues are generated as a function of billable hours, e.g. how many hours it will it take you to install an ESRI ArcGIS Server or build a map of Maryland. Therefore, to make more revenues, one has to generate more billable hours. Yet, the billable hours per person has an upper limit, say 40 hours per week (unless of course you are a lawyer, in which case it is greater than the 168 hours available to us mere mortals). And therein lies the conundrum, the professional services industry does not scale beyond the bodies you can hire. This means in the good times your upside is limited to the amount of dollars per hour you can charge times your total workable hours. And in the bad times, you have the fixed overhead of salary support for someone who isn’t fully billed out. Large downside risk, limited upside potential. Not the best of business combinations.

Given this combination, it is easy to see why Adam might wish to clone himself. If he could scale the number of hours he could work to the available billable hours he could sell, and not incur the additional overhead and risk, Adam would be less stressed, and would make more money. Of course he may have to share his Bulldog tickets with his clones, but there are disadvantages to bulldog cloning that I’ll leave for your imagination.

The geo-data industry sector is different. A lot of effort goes into developing the data product, but once developed this product may be sold multiple times. This make-once, sell-many product model is a great example of a scalable business. Like the software business, the cost of development is incurred upfront, after which the only marginal expenses are sales and marketing. In essence, instead of cloning yourself to garner more revenues, you clone your product (which is a bit easier than cloning yourself with today’s technology).

The problem with the data business model is the upfront costs, as well as the sales and marketing expenses once the data product has been produced. These costs can be significant and there is always the risk of, “if you build it, they won’t come.” So while it scales well, the risks are high. Given this risk and expense, many geo-professionals choose to continue along the path of lower risk, but lower upside, consulting business; and like Adam they dream of cloning themselves while working late in the evenings, instead of watching their favorite college football team.

Is there another path? I would like to think so, but it requires a blending of the data and professional services business model. In this new path, people like Adam, who create content (or advanced data transformers and geospatial analysis tools) on a daily basis for others, would retain an explicit stake in their days work at creating valuable content. Much like songwriters, who retain residuals on the songs that they write, GIS professionals who create products for others could retain royalties and derivative rights on their products. These royalties and rights would allow them to resell their works in a manner that would generate new revenues, which would scale far better than the original hours required to produce the original work.

There would need to be some trade-offs for the original purchasers, e.g perhaps they get a lower price for the job if Adam was able to retain the derivative rights to his works. In this case, Adam could bet a little of his current revenue in the hopes of generating a better scalable revenue stream. This would be a win-win for both parties, as the original purchasers would be getting a product a lower cost (and thereby increasing their overall productivity); and Adam would be able to generate more revenue with less effort, which could possibly create a new business model for greater success in our industry.

Why the Platform Is Important

Thursday, September 17th, 2009

Sometimes we can miss how large marketplaces can be, and their importance to development new ecosystems and technologies. The iPhone app market gives a glimpse as to why a SaaS-based application platform is so important for future geospatial business growth.

While the iPhone article describes a consumer based platform (mobile phones) for applications, the concept for a geospatial application platform is similar. By providing a platform on which developers can “write their own visions” of products, more products are developed, tested, purchased, and discarded at a much higher frequency than previous enterprise development cycles. This increase in the velocity of the product development cycle will provide opportunities in the future beyond those previously seen in the traditional software business. It will also increase the risk of marginalization of current software packages.

Our mission has been to develop a means to bring platform technologies to the geospatial industry. We focused on content first, because most of the current value of geo-knowledge is “stored” in the content produced under professional services and consulting contracts. The geospatial content are also larger and has proprietary file issues that are not necessarily seen in the consumer web space, which add to the difficulties in providing a true application platform to the Spatial Data Infrastructure (SDI).

However, it became clear to us about 2 years ago that cracking the content index, search, customization, and delivery process required developing an application platform along with the content management platform. So we began the process of creating an application platform that is accessible through APIs, which we then used to build our content management platform. Furthermore,we sought a partnership with a vendor who could supply additional transforms and ETL functions (Safe Software), which we could expose via our SaaS offerings, to allow others to build their own applications. We have thus created a geospatial application platform that will allow others to rapidly create their own small, but very targeted applications. By providing this application platform at the same time as providing the content management and financial services, all on a scalable SaaS-based architecture, we are poised to create an ecosystem around developer-driven applications and content.

This application/content (de-)evolution from the traditional software vending models is happening all around us. It will come to the SDI, probably a little later than other consumer driven niches, but it is coming. We strive to be that platform that others use to make money, and in that process help change our world.

Businesses Bucking Cloud Computing

Wednesday, September 9th, 2009

I just returned from holidays with my family and am spending hours catching up on my blog reading. The advantages to reading so much, so quickly, is that articles separated by time and distance take on new meaning when compared together. This happened when I read about the Gmail failure and this article on a survey of Small and Medium Business (SMB) use of cloud-based services.

The survey begs the question, “Why are SMBs not rushing to use cloud-based services?”   This got me to thinking about our own experience at WeoGeo with cloud-based content management services, as well as our discussions with hundreds of SMB customers. I think I can break this down into 3 key points.

  1. Compartmentalization – The top cloud-services used in the survey are conceptually simple to understand and compartmentalize from an IT and business perspective. These web-hosting (#1 in the survey), email (#2), and data archival (#3) services can be broken apart from the daily operations of any business unit and provided back to that business unit as a service, either internally by an in-house IT operation, or externally from a service provider, i.e. Google Mail. The workflow within a business unit is not impacted by the internal or external delivery of these services.
  2. Uptime and bandwidth – These services require a high degree of availability, whose functionality can be felt by every single person in the organization. Ask an IT manager what makes their cell phone ring more – the downtime of a processing computer, or the downtime of the email server. In addition, the internal IT solution downtime can be measured and compared easily against the performance metrics of external “cloud” vendors. Prior to the GMail failure of 100 minutes this past week, Google was apparently averaging 10-15 minutes per month. That is better than most in-house operations.
  3. Cost can be measured and is favorable for the use case – When we switched from our own Microsoft Exchange Mail Server to Google Mail Premium, the cost savings was enormous. We estimated our all-in costs on the Exchange Server at ~$30,000 per year for 15 employees, including IT staff, outside contractors, data center charges, storage and archival expenses, and spam filters. $2,000 per employee per year. Google Mail Premium is $50 per email box per year. The math is pretty simple.

What about the other Infrastructure-, Platform-, and Software-as-a-Service products? My own thoughts are that outside of the tech industry, these other services do not appear to be as easily compartmentalized within an organization. Most business applications seem to run on workstations or internal services quite fine, and the downtime of those processing units just don’t seem to resonant with the IT and business leaders of an organization. In addition, the “simple math” of extreme costs savings (a la Google Mail) of moving more complicated operations to cloud services has yet to be definitely proven.

There are other concerns like the security and integrity of production or sensitive data that also have slowed the uptake of these services within the SMB community. However, I think that providing compelling solutions to business problems that can be (1) compartmentalized and (2) provide a high degree of availability at (3) a dramatically lower total cost of ownership will help allay those concerns. Make this case, and the greater adoption of cloud services by SMBs will be assured.

WebMapSocial Meetup in Mountain View, CA

Monday, July 20th, 2009

I will be speaking at the WebMapSocial Meetup tomorrow, hosted by Google at their Mountain View facility. I will be following presentations by NASA WorldWind and BrightKite.

If you are in the Bay area and want some free dinner with other geo-types, come by for some fun.

The WebMapSocial Meetup is organized by Catherine Burton of Endpoint Environmental LLC.

WebMapSocial

Scaling FME Engines on WeoGeo

Friday, June 19th, 2009

I presented the movie below as part of a presentation at the Safe Software FME User Conference. We had a great time and the Safe crew put on a marvelous show.

The movie shows WeoGeo scaling up to 64 Safe Software distributed FME Engines in the production of tile caches from a world-wide elevation database. The FME Workspace script was created by Dmitri Bagh, and processed on WeoGeo’s FME Constellation built on Amazon Web Services.

The scaling occurred automatically, spinning up FME Engine AMIs, and then shutting them down when the job queue was completed. This is one of our first examples of bringing scalable processing to difficult geospatial tasks.

Examples of the tiles created by Dmitri’s script for Virtual Earth (Bing Maps for Enterprise) and Google Earth can be found here.

Panel 1 (upper left hand corner) refers to the total number of engines in the constellation processing job.

Panel 2 (upper right hand corner) refers to the total constellation utilization percentage. The constellation is polled and when the utilization exceeds the pre-set threshold (50% in this example), it increases (doubles here) the number of engines until it reaches the pre-set maximum number of engines (64 here). The downward spikes occur when each new set of engines are added.

Panel 3 (lower left hand corner) is the average job processing time. There is an increase in velocity when the number of engines exceeds 16, which may be a function of increased overhead costs on the FME Core or bandwidth to the database.

Panel 4 (lower right hand corner) is the total number of jobs completed. 2000 jobs were submitted for this test. The job completion rate accelerates until the maximum number of engines are brought on-line.

A TerraColor Example

Friday, February 6th, 2009

We have a client (TerraColor) that was looking for better ways to market their content on the WeoGeo Market. So we created an iFrame and KML link with their full content listing to have some different ways to find and purchase Terracolor content on the Market.

He took the iFrame and embedded it on his site to directly brand and market the maps to his customers. He now has a fully functioning hosting and eCommerce site for a fraction of the cost and time of doing it himself.

With the release of our APIs, the Market experience can be further customized to a unique customer desired solution, generating many different ways to store, host, search, and deliver geo-enabled content. This is just one example of how we are trying to move towards platform-level services for our customers.

earthstar_geographics_sml

WhereCampPDX

Thursday, October 16th, 2008

We’re headed to WhereCampPDX on Saturday. It is an event that everyone in the office has been looking forward to attending. This is exactly the type of event that prompted our move across country.

We hope to lead a couple of sessions. The first is by Scott Becker entitled, “Intro to Open Layers, a Free Open Source JavaScript Mapping API”. Open Layers is a powerful JavaScript API for web-based mapping that provides a multitude of tools for the geo hacker, including support for many tile formats, vector data, a drawing API, as well as support for various open data standards like GeoRSS, GeoJSON, GML, KML and more. This session will attempt to introduce the participants to these capabilities and spark ideas for what they might be able to create using them. To view Open Layers in action, check out our WeoGeo Marketplace (www.WeoGeo.com), which has recently undergone an upgrade from KaMap to Open Layers.

Our other session will be led by me: “Illuminating the Dark GeoWeb”. Valuable geocontent is stored in databases, network storage drives, and desktops. These are not accessible to search engines spidering the web making the geocontent undiscoverable. This session will be an open-ended discussion on how to develop tools to index these data, as well as how to motivate the owners of the content to make these data available for discovery and sharing.

Looking forward to seeing everyone there.

Safe Software and WeoGeo Partnership

Friday, July 18th, 2008

The facts of this partnership are well covered by the press release and Directions Magazine’s coverage (see Adena Schutzberg’s article and podcast). I thought I would give a bit more of the why.

1) ETL is fundamental to the needs of our customer base.
2) Safe is the best at spatial ETL.
3) People trust Safe for ETL.
4) If you use CAD or GIS software, there is a good chance you use Safe Software.

For a marketplace to be successful, its players have to trust their interactions and delivery mechanisms. Safe operates on over 200 different file formats across multiple platforms. Bringing this type of technology to our users is critical to our success; bringing Safe to our customers is just good sense.

What does Safe get out of this? We give them the cloud for FME Server and provide their users with the path to the future of web infrastructure.

Together, we get to focus on our strengths and bring new tools to bear on our respective businesses.

I am excited about our opportunities and the impacts I believe we will have on the spatial industry.

Some Thoughts on Mechanical Turk and Geo-Processing

Wednesday, July 16th, 2008

We use Amazon Web Services (AWS) quite a bit. Mostly we use the EC2 and S3, but recently we have been using a limited bit of Mechanical Turk (MTurk) for some testing of the web site.

For those of you who don’t know what MTurk is, from the web site -

…The Mechanical Turk web service enables companies to programmatically access this marketplace and a diverse, on-demand workforce. Developers can leverage this service to build human intelligence directly into their applications.

Our use has been somewhat limited to testing of the web site only. However, there has been some image processing uses of MTurk, including the SAR efforts to find Jim Gray and Steve Fossett.

I wear two hats these days. We are still actively involved in the development of HyperSpectral Imaging (HSI) sensors and algorithms (see the Florida Environmental Research Institute). It was from these efforts that we developed the cataloging, discovery, and distribution systems that we spun out into WeoGeo.

The holy grail of imaging techniques is the automatic extraction of features and classification of materials within the raster data. It is something we have been trying to develop for over a decade. There are others who have been working at it longer.

After all these years, there are some problems that are still difficult to solve in processing imagery. They frequently require just looking at the images frame by frame to resolve features and classify stuff that just defies algorithmic development. It strikes me that there may be some parts of this processing that may not be easily solved using computer algorithms. Things like finding seam lines in overlapping aerial photographs.

Several major imaging vendors send a chunk of their current image processing to low cost countries like China and India to complete their large-scale projects. It seems that there might be a better way to accomplish such geo-processing tasks that still require eyes then to incur the time and expense of sending these tasks overseas. Perhaps Mturk and some smart programming might offer a different approach.

I also wonder what other sort of QC/QA tasks in geo-processing might be solved by MTurk. I might try to kick it around a bit at GeoWeb. Find me if you got some thoughts.

(Ford assembly line, 1913)