That was an email I got last night from a reader. They like all of us were amazed at what she was seeing. The solution is not that hard to imagine though. Most of the problem we run into is processing power and bandwidth. None of us can afford the server farms and the racks and racks of servers that Google can deploy. But that isn’t a problem. If I were ESRI, I’d be looking at allowing their customers/clients to use Amazon Amazon Simple Storage Service (S3) and Amazon Elastic Compute Cloud (EC2) for hosting and processing. The cost of such services is amazingly low and you can take advantage of Amazon’s infrastructure to offload some of the processing on it. Sure it won’t be “Google Fast”, but it will get you as close as you can get without being at Google.
The day I can spend an hour fighting Google Maps to get a route that covers all lower 48 states is the day I’m finally a Google Maps convert. Typing in city name is for wimps. Dragging that blue line all over the country, now that is GIS baby!
Sure it isn’t efficient, but the Google servers are slow and I gotta get back to work.
Now all they need is save to KML.
OK, well maybe not on the Simpsons… But if I was, this is how I’d look.
Love the Simpsons Movie Avatar Generator….
I got an email from someone who likes Planet Geospatial, but wants to know when and what feeds I add so they can update their feed reader. I used to have a change log, but that got a little behind so I figure I’ll just blog when I add feeds. The
5 6 latest feeds I’ve added to Planet Geospatial are:
There is somewhat of an announcement on the ArcGIS Explorer Blog about the next release of ArcGIS Explorer.
In the Showcase and at the sessions we were using both the currently available public download (Build 380) and also showing one of the more recent software builds (Build 392) to highlight some of the new features that you can look forward to in the next release. This upcoming release of Explorer will continue to evolve for a few more weeks and will be delivered sometime in July.
Not much there, but I assume some better KML support (2.0/2.1?) and maybe some increase in speed. I’d love to roll out some AGX applications internally at my company, but I’m sticking with the .NET Web ADF for now.
** Mechagodzilla is better than old AGX Godzilla **
OK, so most of us have their inetpub directories at “c:inetpub”, but not all. I’m one of those people. For reasons I cannot recall, my inetpub directory is on my “d:” drive. But that isn’t a problem is it? Well if you try and install either ArcGIS Server or ArcIMS 9.2 you’ll notice that ESRI assumes that everyone has their inetpub directory at “c:”. I figured this out after a couple minutes of a blank ArcGIS Server Manager page. I went into IIS Manager and noticed that Manager was pointing to “d:InetpubwwwrootArcGISManager” which of course didn’t exist. The post install was nice enough to create “c:InetpubwwwrootArcGISManager” but that isn’t where my inetpub directory is located.
So I went back into the GIS Server Post Install just to double check and make sure that I didn’t miss something.
And the Install Summary doesn’t reveal much.
GIS Server Post Install Summary
Input config file: C:Documents and SettingsFeeMy Documentsagspostinstall.xml
Configure as server object manager.
Configure as server object container.
ArcGIS SOM account: ArcGISSOM
ArcGIS SOC account: ArcGISSOC
ArcGIS WebServices account: ArcGISWebServices
Output directory: c:arcgisserverarcgisoutput
Cache directory: c:arcgisserverarcgiscache
Jobs directory: c:arcgisserverarcgisjobs
Output virtual directory: http://localhost/arcgisoutput
Cache virtual directory: http://localhost/arcgiscache
Jobs virtual directory: http://localhost/arcgisjobs
And heaven forbid if you try and install to a computer that doesn’t have a “c:” drive. Anyway, this probably needs to be address at some point. So if this happens to you, just copy the “c:InetpubwwwrootArcGIS” folder to your IIS drive.
**Update: **JT points out a KB article that explains the why and how to fix the issue. Yea, its a huge PITA.
**Update 2: **Word from ESRI is that this will be fixed at the next release.
OK, you have to just laugh at this blog. It seems like its been around for about a day, but I’m hoping we’ll see some more.
So what was the story on the Thursday night party being in a parking lot? I’m looking at some uploaded photos in Flickr and it looks bizzare compared to previous years. Did the “American Road Trip” theme result in putting the party in a parking lot or did the theme come about because it was in a parking lot.
Anyone see a link to where ESRI provides support for ArcGIS for AutoCad? I can’t tell if this is actually supported by ESRI or not as it isn’t in the support site.
Since I wasn’t at the UC and those blogging seem to not care about bugs, we haven’t really heard what Nick Frunzi presented at the plenary in regards to user support. The ESRI UC blog has a little bit on what to expect though:
Tentatively named “Bugs Online”, this new Support Center feature is planned to go live in late Summer 2007, and will be integrated into the existing Support Center search. Here’s a few more details (as usual, all is subject to change).
It looks like the first release will be a public “beta” during which you’ll be able to access Bugs Online, albeit with somewhat reduced functionality and content. During the the beta, you should still be able to access most of the metadata for most of the bugs, including:
- Synopsis: A concise description of the problem and the circumstances under which it occurs.
- Submitted: The date the bug report was filed.
- Severity: Indicates how heavily the problem impacts those who encounter it.
- Version Found: The ESRI software version where the problem was first seen.
- Status: A short text description of where the bug currently is in our handling processes.
Later on this year we’ll be working on additional functionality, including an option to allow you to “subscribe” to specific bugs and receive an email when the status of the bug changes.
Email is fine, but don’t forget RSS.
Update: – Podcast of Nick’s talk is here.