I don’t know if Brian remembers or not, but we (www.WeoGeo.com) were at Location Intelligence in San Francisco showing this exact solution. Adena Schutzberg at Directions Magazine mentioned it briefly here (http://www.directionsmag.com/article.php?article_id=2448&trv=1) and here (http://www.directionsmag.com/podcast.php?id=2469).

The geospatial market will change when skills and content are valued as highly as the infrastructure and sales channels. What Google doesn’t have is the millions of qualified mapping professionals who know their business. They (Google) want your content for free, so that they can sell advertising on top of it. It would be very hard to compete with Google in their sphere.

Another approach is the one we have built on Amazon Web Services (AWS). This (neo)mapping market directly connects content providers with content users, allowing the providers to set the price for their product. Consider it an “Ebay” for mapping skills and content. AWS gives us the reach and scalability to provide people like your reader the ability to do their jobs, be paid for their skills, and participate in this growing internet mapping community.

Looks like http://www.weogeo.com may be headed in that direction, and might even become a platform for others to do the same with http://weoceo.weogeo.com.

that being said, there is always another way to skin the cat and the Ec2/S3 combination is too good to ignore. GeoServices that expect resource addressable input (think REST) in common formats could be implemented on EC2 right now

cheers
brian

@James: As for The Timoney Group commercializing an open source stack on EC2, my marketing people tells me there’s little money to be made in “GIS”. However, perhaps if we market it as “stuff-you-can-overlay-in-Google-Earth”, the VC spigots would be wide open

@vector: The database bit is a known limitation of EC2 at this time, although there seems to be some very creative MySQL implementations as a workaround. So while it may not be appropriate right now as a persistent repository, it seems to be you could automate the data upload/data processing/download results routine and still have a time- and cost-effective solution.

BT

But his point is well taken. The old traditional method is dead and companies that don’t change are destined to fail.

Investing you time and effort on the Web ADF and big ass AGS servers is not the way forward. The google method of server farms is. Might as well embrace it.

Compete against google? Nope, but for any of us to not try and improve our own offerings is suicide. The Web ADF and ArcGIS is a dinosaur and shouldn’t be used.

Well put. How many people are actually going head to head with Google, i.e. making a point to point route server on commercial nationwide data?

“This may be an over simplification but I am relieved to pass the torch of supporting ubiquitous and generalized web mapping applications to the googles, yahoos, mapquests, and microsofts of the world so I can concentrate on the more complex and specialized solution requirements that the suite of commercial applications can’t address.”

I think that is how you “compete” with Google- do something they cannot do and give people an answer that Google cannot give them. You compete by making the topmost layer, not by reproducing the bottom background layer.

As for competing with Google… why fight? I find it curious how many GIS professionals view the new commercial GIS apps (Google Earth, Virtual Earth, et et) as a threat rather than an asset. Our network staff doesn’t “compete” with dell, ibm, sun, microsoft, linux, et et et. They assist business experts in leveraging their resources toward specific requirements rather than try to keep up with the vendor’s product lines and services. If Google Earth meets someone’s specified requirements more effectively and efficiently than ArcIMS; great. What’s important is their problem is solved. This may be an over simplification but I am relieved to pass the torch of supporting ubiquitous and generalized web mapping applications to the googles, yahoos, mapquests, and microsofts of the world so I can concentrate on the more complex and specialized solution requirements that the suite of commercial applications can’t address. The everyday web map has been commoditized… hallelujah.

“ESRI obviously couldn’t ignore the desktop – that was their legacy. Dependency on the desktop mandated a focus on the server – but the distribution model outside of the organizational desktop/server was not properly emphasized. I would stridently argue that high accuracy data creation and editing SHOULD be done at the ESRI desktop and with ESRI enterprise storage and delivery within the enterprise. However – mass delivery of my ESRI-maintained data better have an interface with Google Earth and Google Maps or else.”

This is so true

This is a new product for ESRI Desktops: High accuracy 3D stereoscopic data capture, something like Leica StereoAnalyst or the SOCET SET Extension but affordable nad end user oriented: Purview -> http://www.mypurview.com
ESRI Canada is already distributing it

This is the exact reason that I have been waiting so patiently for my acceptance into the EC2 beta. I was rewarded on Monday. I am in….

However ESRI still has some barriers. We as users/business could publish a public AMI of ArcGIS server if ESRI would publish a time bombed AGS install, much like Microsoft does for all its virtual machines. EC2 does still have some issues such as dynamic ip’s, and a lack of persistant storage at the EC2 instance level. You have to use S3 and some cool master/slave/warm backup setups of your database.

That brings me to another point, ESRI has defiantely followed the Gov. crowd into the .NET world. You can’t work a model like EC2 if you still have to license all those OS’s. I guess all those C# guys can give up visual studio, grab Eclipse or NetBeans and go for it with Java (it is so close already). Perhaps Mono will get some love..

I don’t think the .Net crowd has got the community to do it though. And as long as ESRI is putting most of its effort in that camp it doesn’t look good.

My 2 cents

It seems like the age old trap of letting the software drive the solution.

If your customer asks “What about Google Earth” or “Google Maps” – I hope your answer isn’t “…because it’s not ESRI or Autodesk”.

If the customers like “other services” – you better find a way to insert yourself in to that supply chain or you will lose customers.

[Insert random quote ref: "change is the only constant" or "failure to adapt = death" here]

I think what James was getting at (feel free to correct me) is that we (ESRI users) need to keep our customers from defecting to other services. It isn’t so much that we care if we are using ArcGIS or QGIS, but that we want to be those folks implementing it. One call to Google and we are out of a job. My little company can’t afford to make the investment in programmers to make such a jump so we need our partners (ESRI, AutoCad, Oracle, Microsoft) to do that for us.

Keep pushing James!

“If I were a betting man, I’d put my money on someone putting together a PostGIS/MapServer/GRASS stack on EC2 and selling tile making, interpolations, routing, etc. based on usage.”

So when are you going to release that Brian?

Per-seat (not to mention per-processor) licensing is too lucrative to give up until absolutely necessary. And getting fat on selling features the majority rarely use has worked out well enough. And if you need to offer specific tools to help customers “manage” their licenses–you’re probably a ripe target for a competitor’s software-as-service model.

When GIS people express frustration about their job, all too often what they’re really saying is “while I love the GIS part, I hate sys admin, I hate managing services, I hate diving into OOP for lightweight customization, and I hate combing through log files to figure out why things aren’t working. And I really, really hate when the suggested ‘fixes’ include fiddling with registry settings or obscure IIS parameters–more complexity and techie minutiae that shouldn’t be my problem.”

Which was the genius part of the Arc2Earth approach using S3–Internet mapping with no server management involved.

If I were a betting man, I’d put my money on someone putting together a PostGIS/MapServer/GRASS stack on EC2 and selling tile making, interpolations, routing, etc. based on usage.

And only when a big customer stops the annual licensing fees because this “faster/better/cheaper” approach actually works, will the entrenched give serious attention to an alternative model.

Brian

A: The same way you stop earthquakes, hold back hurricanes, or control tornadoes – you don’t.

I certainly don’t have an MBA but I wouldn’t think that ‘anti-Google’ is a good business model.

This is the price ESRI pays for not co-opting a proactive web delivery solution in the 1999-2002 time period. With no clear-cut market dominance from ESRI, Google saw opportunity and methodically revolutionized how GIS is delivered to the masses.

Think about it – while ESRI was finishing the touches on ArcIMS 4.x and grudgingly moving towards open-standards in IMS 9x – KeyHole and then Google brought GIS to the masses in a one-two-three type process that literally kicked down the doors of what had been a nearly closed-door society of distributed GIS solutions for those with big budgets.

There can be no denying that Google revolutionized how GIS is used around the world for decades to come (an extreme over-simplification ?). And I would doubt that they are done.

If one had to ascribe one or two reasons why ESRI let this happen – I would suggest that ESRI was focused on the desktop while Google never had any desktop baggage to maintain. The only time Google goes to your desktop is to add value to the Google brand.

I’m not anti-ESRI, I’ve just been extremely disappointed at their web-based solutions for a number of years.

ESRI obviously couldn’t ignore the desktop – that was their legacy. Dependency on the desktop mandated a focus on the server – but the distribution model outside of the organizational desktop/server was not properly emphasized. I would stridently argue that high accuracy data creation and editing SHOULD be done at the ESRI desktop and with ESRI enterprise storage and delivery within the enterprise. However – mass delivery of my ESRI-maintained data better have an interface with Google Earth and Google Maps or else.

Why fight Google? It’s a loosing proposition.

Is Amazon web services really going to compete with Google? It’s an alternative – probably a very good alternative…but I question the perspective of “instead of Google” vs “in addition to Google”.

I’ve seen mention of IBM considering ESRI as a possible acquisition – Perhaps a better question is when will Google buy ESRI ?

KoS