James Fee GIS Blog

I suppose it makes sense.  Print media is dead everyone says.  How do you stay relevant if your primary product is a print magazine with pictures (that probably costs a ton to produce)?  

Launch a games division.

I can’t wait until ArcMap X comes out on Wii.

Pulling off a wicked intersection on Wii ArcGIS.

Back when ESRI had just released PC ARC/INFO (for the cutting edge DOS) and way before Google was a research project, the United States Congress passed a joint resolution signed by Ronald Reagan proclaiming that Geography Awareness Week would be held in November.  

The Great Communicator signs Geography Awareness Week into law

Remember, it isn’t about the Google or ESRI (I suppose GIS Day is for them).  It is about the Geography!

How do you convince Scrooge McDuck to part with money to pay API licensing costs to Google or Microsoft?

The other problem is that if I’ve got to spend that kind of money, I’m going to be developing larger internal applications than I would externally. You can’t do a simple internal mashup if you have to pay large enterprise licensing costs. I was told by one potential client who wanted a Virtual Earth application that “For that price we might as well buy another ArcGIS Server license”. For someone to say that it is cheaper to roll out ArcGIS Server for a simple mashup really puts it all into perspective and if you are going to develop with ArcGIS Server, you’ll probably have a larger application than a “simple” Virtual Earth map.

So I’m pleading with Microsoft and Google to revisit their map API licensing and move toward more of an Amazon AWS type service that will help get their mapping tools into more places than today. Everyone wants a Google or Microsoft map on their intranet website, but the current licensing is killing projects before they can start.

The GeoMonkey is a huge supporter of Amazon Web Services

Homer tries to make sense of mapping

Dan Catt at geobloggers blogged over a week ago about Flickr about how they were using WOE ID to generate polygons of places that people have tagged in Flickr.  A couple people have emailed me on how worthless this exercise is and how arbitrary it is.  The Flickr Developer Blog goes into some more detail about the how and why Flickr is doing this and I think that should give everyone who doesn’t understand why this is important some better context.  Personally I find it extremely interesting to see how people understand what place they are taking a photo at.  A lot of this can all be tied back into Neogeography and what makes an expert.  I’d wager people are more careful to geotag their photos in areas they are familiar with and less so when they are traveling.  I don’t have enough photos tagged in Flickr, but I’d love to see maps from some larger Flickr users to see how they geotag the world.

What Flickr has is a way to visualize how people are geotagging their photos and they appear to be learning about to improve the process.  I think this is a great application of technology to help better understand how humans perceive location.

As I’m sure many have seen, ArcGIS Service Pack 1 is available on ESRI’s servers.  I’m interested to see how the new error reporting has improved the first Service Pack over previous Service Packs.  ESRI is still going to release a Service Pack a quarter so don’t worry about the future.  The links below go to the download page which also has info about the what fixes were included.

• ArcGIS 9.3 Service Pack 1
• ArcSDE 9.3 Service Pack 1 (They just can’t drop that ArcSDE name can they?)
• ArcIMS 9.3 Service Pack 1
• ArcGIS Image Server 9.3 Service Pack 1 (Still not part of the ArcGIS Server package)
• ArcSDE 9.3 Service Pack 1 geodatabase direct connect for 9.2 clients setup (For those still on 9.2 and want to connect to 9.3)

Nothing about the Service Pack 1 update on the ESRI Support Blog but that blog has been spotty so I’m not surprised. 

Brady has just posted the news on the Geowanking list.  Full text after the jump.

[Read more →]

There are really good reasons to use the File Geodatabase in the ESRI world over the shapefile and Personal Geodatabase, but it doesn’t mean it is easy to share.  Sean Gorman knows that the more file formats he supports, the more likely people (especially GIS pros) will be using GeoCommons.  I suppose the simple answer for Sean is to buy a license of FME Server and support everything and anything people upload.  The cost of that solution might not make business sense just yet for him so I suppose is the lack of ESRI Geodatabase support (or any other format) limiting you when you want to share data?  I like the idea of uploading a Geodatabase full of datasets at one time, but sharing a folder/file based dataset is difficult enough on a LAN, let along the internet.  Is converting to shapefiles too much to ask for people who want to share data on services such as GeoCommons?  

WeoGeo partnered with Safe Software to bring this kind of datasharing (among other features of FME Server) to the cloud web so there might be solutions that are cheaper than outright licensing FME Server to bring translate capability to Web 2.0 services.  If that can be coupled with Amazon Web Services pricing (pay for what you use rather than a traditional license) there could be something that many people take advantage of.

And of course you could export out any layer in GeoCommons Finder! to any of the 200+ FME supported formats.

I’ve been hearing much about stacks these last few weeks.

“We want an all ESRI stack”

“We want to break out of the ESRI stack”

“I want an all OSGeo stack”

“Bill Gates’ stack is the work of the devil”

“I want to avoid the [INSERT LEAST FAVORITE SOFTWARE COMPANY HERE] stack at all costs”

Why concern yourself with branding stacks?  OK, maybe if your corporate IT department dictates that you must go a route you have to worry about it, but otherwise concerning yourself with an overarching stack just distracts you on matching your needs with the best hardware/software.  Stack away, but focus on the individual parts, not the whole suite.  Leave the marketing terms such as LAMP/WAMP/XXXX to others and pick what works.

Be careful with stacks

I was out last week in New Orleans and of course had no time to block so I’m going to try and catch up this week.
  Alexander Karnstedt shares his thoughts on Dave Bouwman’s presentation at the Texas GIS Forum.

“I strongly agree with Dave Bouwman’s assumption that this is the result of a long lasting strategy of trying to cram desktop GIS into the browser with GIS manufacturers concentrating on developing utterly generic “out-of-the-box” WebGIS products. So this wants us GIS developers make to believe that we are able to produce WebGIS applications in a jif. But the simple fact is that 99% of so called WebGIS apps have a quite narrow purpose, thus need pretty focused functions and user interfaces instead of bloated generic UI’s.”

It is clear GIS developers understand what hasn’t worked in the past and what needs to be done in the future.  The trick is to enable complex GIS analysis in a way end users can take advantage of it.  If it was easy, everyone would already be doing it.

  More baseball geography; Five Migrations in Baseball History.  Lets see, statistics, geography, beer, dispair.  Is there nothing baseball can’t teach us?

  Yes, ArcGIS Server Flex API 1.0 was released last week.  Cue the “Where is Silverlight?” questions.  Might be a great topic to discuss at the 2009 Developer Summit.

  Google Earth for the iPhone has been released. After playing with it for a week a couple things come to the surface.

1. First it is very well done and visually impressive.  Fingers can navigate 3D globes.
2. The Edge network is too slow.
3. I almost got run over by a streetcar navigating the globe. Could that be worse than texting with your head down?
4. The tilt function is confusing when you are walking.  I want to hold the unit in front of my face, not look strait down (see #3).

I can’t wait to see the next version and start using the iPhone to interact with network KML.

  whit has more iPhone/OpenLayers goodness on his blog.

I was just talking to someone today about web applications for ArcGIS Server 9.3 and they were surprised that I was using the Web ADF to create an application after my post earlier this week on the JavaScript API.  I feel like I need to clarify some things about that post.  It wasn’t so much a desertion of the Web ADF, but point that one should be looking toward the JavaScript API (and I suppose the Flex API) for most mapping situation and use the Web ADF (Java and .NET) when it best makes sense.  I’m using the Web ADF on this project because the requirements of the end user is best met with the Web ADF.  The great thing about the JavaScript API, the Flex API, the .NET Web ADF, the Java Web ADF and even the JavaScript extenders for the JavaScript API is that they all can be called on if needed.  Of course the Web ADF does have licensing issues that ESRI needs to address that limit its appeal even when it is the best choice for the solution. 

ESRI has given their developers choices that we aren’t accustom to and in turn ESRI developers should be looking at the choices when making a decision of what SDK to use.  Also just because you use the JavaScript API or the Flex API doesn’t mean you’ll end up with a great application.  So much more goes into it and there isn’t any reason why the Java Web ADF can’t give you a great application anymore than the Flex API can. 

Et tu, James?

whit has written a blog post on what he’s been working on getting OpenLayers to work with Mobile Safari on the iPhone (and iTouch).

A major part of my recent investigations for mobile and opengeo have focused on getting OpenLayers to do a basic version of it’s thing on the iphone.   I’ve had limited success, but maybe these demos will help someone else get a little further or perhaps help crystallize a more effective approach than mine, since I’m pretty green with OL.

He’s also created a couple demos for the iPhone/iTouch using some of the touch controls.  The bottom line is that moving from mouse control to finger touch is as hard as you’d expect.  I think it is great to see OpenLayers take on this effort because being able to move mapping to mobile devices will be key with the iPhone and Android taking off here in the next year.

OpenLayers iPhone Support

I see that MapQuest now has an optimized iPhone site (HT APB) for all those people who still use MapQuest (though I’d guess most iPhone users would just assume use the built in Google Maps app). Since MapQuest is not using the iPhone App SDK I wonder if there is an API available for developers to create iPhone mapping applications using the MapQuest API for the iPhone? MapQuest’s API has been hit hard by Google and Microsoft and I would think a smartphone API (Android and iPhone both use WebKit) would help them get out of their niche.

Damn! We're in a tight spot!

OK, I’ll come clean.  While Flex is a great tool, I can’t see how you’d not use the JavaScript API instead.  Flex is still not available on every platform (I’m an iPhone elitist) and isn’t easily picked up by everyone.  But more than one person said in last weeks thread on the JavaScript API that Flex was the way they are going.  I’m curious is there a rising groundswell in Flex or are ESRI developers just an outlier to the overarching movement toward JavaScript?  FlexBuilder 3 is at least $250 (Pro is almost $700) and I just can’t see people bothering to buy an

What part of the Flex API makes you choose it over the JavaScript API?  If people are willing to block Flash, don’t you limit your marketplace by going that route over JavaScript?

Flex.....Savior of the Universe

If you were like me today and were working hard at getting your abstract in this is probably not too much of a big deal to you, but if you were unable to get your submission done, you’ll have some extra time to get those ducks in a row for your 2009 abstract submission.

Professionals across industries and with all levels of GIS experience are encouraged to submit an abstract for possible presentation at the 2009 gathering. The deadline for submissions has been extended to November 14, 2008.

You still have time to get that submission in!

I find it interesting that most work I’m seeing these days is with the JavaScript API that ESRI released at ArcGIS 9.3. I assumed a couple months ago that people would really be looking at moving off of the WebADF (.NET or Java) for the JavaScript API and it appears that this trend is beginning to happen. Now before you think that I’m really sticking a fork in the WebADF, think again. The WebADF will continue to grow and be used where it makes sense, but probably not as the “default” mapping front end for ESRI web servers. The simplicity of the JavaScript API and the way it works, makes the classic WebADF and HTML viewers obsolete for most users (I’m still waiting to see what ESRI does with Silverlight, but that discussion is for another day).

Also, coupled with the JavaScript Extenders for Google Maps and Virtual Earth, there is probably very good reasons to be looking this way instead of deploying the WebADF. I’ve also seen people abandoning third party “helpers” for the WebADF such as Geocortex Essentials (I guess we’ll see JavaScript API tools from these companies soon, eh?) to move back to simpler JavaScript front ends. There are times and places for .NET or Java server solutions, but what the JavaScript API has done is allow ESRI customers and implementors to go with a more lightweight solution and in turn brings them to more cutting edge RESTful and JavaScript technologies that can be leveraged outside of the ESRI silo.

I’ve really started to try and point my clients (and anyone else who asks) away from the Java and .NET WebADF and toward the lightweight ESRI JavaScript API. Everyone who has moved in that direction has really been satisfied and given the 9.2 release of ArcGIS Server, that is really turning things around.

James seems to be pushing ArcGIS Server again

I’m heading down into the basement for a week.  Enjoy the greatness that is David Hasselhoff, Gary Coleman and of course KITT.

What a moment of zen...

Well kudos for FortiusOne for getting the word out on Maker! especially since the launch was delayed from the original PR blitz.  As with most GeoBloggers, I’ve had access to Maker! since last week and have really been impress with its output.  Sean has been teasing us for months it seems with the cartographic output of Maker! in his blog posts, so I was glad to finally get my  hands on Maker!. (side note, do you put a period after a product name that ends in a punctuation mark?)

Maker! is the map production portion of GeoCommons and Finder! is the search engine for geospatial data.  Together they allow users to create web maps that can be shared with the world.  So to get information in Maker!, you first upload your data to Finder! and then add it to your map.  The byproduct of this workflow is more data gets added to Finder! and in turn more data is available to the community at large.  Freely sharing data is one the core components of GeoCommons (compared to WeoGeo which is more of a marketplace).

Stefan Geens does a good job of showing how the map is created and how you set what we usually refer to the symbology of layers.  What I like about this approach is you can bring to light the data in ways that before Maker!, required custom programming to achieve good looking results (if even possible).  FortiusOne, according to Sean, worked with cartographic professionals to create the rich (I’m sorry) map production tools.  These tools are so good in fact that I’ve heard a couple GIS professionals lament that they’ll be out of a job soon (of course we all know that Maker! will only increase our workloads to produce data for public consumption).  What we have here are two really simple tools that allow anyone to upload geospatial content, combine that information with other datasets and then create a wonderful looking map that visually tells a story.

You can argue all day and night about what the GeoWeb is or isn’t, but I think we have an excellent example of what the GeoWeb should be right here.  Finder! has discoverable web services of data (with metadata to boot) and Maker! allows you to leverage those services together to create derivative value content to share with the world.  Moving forward, the data of GeoCommons should support more OGC services (beyond KML) for those who need that support and the maps created with Maker! should be more easily shared beyond just an web map.  But the groundwork is there for sharing data with the world.

Despite the lack of monkey maps, the GeoMonkey approves of Maker!

The Amazon Web Services Blog says that Amazon will be bringing Microsoft Windows to EC2 this fall.

The 32 and 64 bit versions of Windows Server will be available and will be able to use all existing EC2 features such as Elastic IP Addresses, Availability Zones, and the Elastic Block Store. You’ll be able to call any of the other Amazon Web Services from your application. You will, for example, be able to use the Amazon Simple Queue Service to glue cross-platform applications together.

This is on the heels of the Oracle/Amazon EC2 release from a couple weeks ago.  Now that the tools are here, we’ll have to see how well they are adopted by corporate IT administrators who aren’t always open to giving up control of their servers to others.

Mr. Gates saw the value of the cloud early on

I was thinking the past week about a project that we will start working on soon. Simply put, it is updating a MapObjects IMS application we deployed almost 10 years ago, that is still working. When I saw that it was not only still running, but it was still a critical part of their business workflow, it started me thinking about why such an application was so successful. It obviously wasn’t the technology. Sure the back end runs on Oracle, but even the most ardent MOIMS supporter can’t claim that the Visual Basic application was cutting edge even back then. So that must mean there was something else going on that kept it running when most MOIMS sites are long gone.

Won't someone please think of the users?

History of GIS applications tells us one story that repeats itself again and again.  There is a horrible habit of pushing over-engineered applications that are not used by the target audience because no one has time to figure out complicated tools.  GIS vendors have not discouraged such habits and in some cases encourage them.  The GIS world is really good at writing GIS applications for GIS professionals.  I think this used to work before GIS and mapping became important in our everyday lives, but now that everyone everywhere is looking at deploying spatial applications focus needs to be put on what the end users are going to be doing with the application.

So back to that old MapObjects application, it did a really good job of doing what it was supposed to do.  Display information in a context that the users were comfortable working (the interface was familiar to them) with and meet their requirements (which were obviously well developed), fit within their websites, scaled well (even Visual Basic does that apparently) and wasn’t an obstacle to their workflows.  With MOIMS depreciated and the need to connect to more modern ESRI servers and Oracle databases the application needs to be updated, but not because it restricts their business practices and workflows.

Foisting this application on users of a bus system was poorly thought out, but the Google Transit version released a few weeks ago hits the target users right on.  The heavy GIS website might meet needs of users in the organizations internally, but externally it really highlights missed opportunities and wasted resources.  I’m personally really excited to see if we can replicate the success of the earlier MOIMS application with JavaScript APIs, KML downloads and other new technology and still keep is simple.  The key is listen to what the client really wants and be agile enough to deliver simple, focused, and fast products.