Blog

Matt Perry wonders if command line is a dying art. He lists automation, repeatability, documentability, accessibility, and accuracy as factors to consider in using command line tools over their GUI counterparts.

All the factors Matt considered for command line over GUI can be addressed if you use diagramming software. ESRI’s Model Builder and Safe’s FME Workbench both can solve all those problems and even allow you to better visualize what you are trying to accomplish. As someone who cut his teeth on ArcInfo 5, I find the Model Builder and Workbench refreshing and make be a better analyst. Being able to redirect to the visualizer and see what my output will be before running my model allows me to be more productive, rather than have multiple versions of output sitting in a folder.

Update: Better title, was “Command line or diagramming software”

I’m sure this is just a coincidence, but ESRI actually posted a discussion of the REST API for ArcGIS Server. In addition they hit on the three Javascript APIs that they will also release with the REST API; ESRI Javascript API using Dojo, Extender Javascript Library for Google Maps and Extender Javascript Library for Virtual Earth. There isn’t too much depth here but at least we can get an idea where they are going with REST and ArcGIS Server 9.3.

Thanks Rachel

Bill Thorp’s great idea becomes a Microsoft Research Project. Bill notes:

Their demo makes one thing obvious, however. Douglas-Peucker just doesn’t cut it for topologies. This becomes a non-issue with a pixel-level of detail, but just looks bad in their demo. Their implementation doesn’t seem to preserve existing points between zooms; it’s probably just as efficient this way.

Read about it and then view the demo. When you think about the performance here of the polyline data set with 50,000 segments in it you really start to see why this is impressive. Vish has even more thoughts on the project.

So we all hate at least parts of the WebADF but complaining about it won’t do anything. Dave says it is time for us to do something about it. I agree, bitching about software is therapeutic, but it doesn’t help any of us get our work done. Dave, Doron and Matt have all blogged about where we should be thinking of going on this.

Dave thinks we can create our own REST API before ESRI gets around to releasing their own API (sorry Sean, I have to use API here given the context).

There’s not really a whole lot to it if it’s designed correctly. Heck if nothing else we can use what has been done on FeatureServer.org as a road map. Suppose we cook up a server object extension (SOE) that can do all the low-level stuff in raw ArcObjects. Then we write a httphandler that can take the requests, parse the Urls and make calls back to the SOE. If we but the JSON/GEORSS/KML/whatever conversion in the SOE, we’re very light-weight on the DCOM stuff, and can get away with little to no ADF. And if we run this all directly on the ArcGIS Server box, we’re good in terms of licensing.

I like the simplicity of this. Use existing work such as FeatureServer and add back into that community and grow our own ArcGIS Server community. Matt goes one step further and outlines what this RESTful interface would look like.

So what is the next step. We can wait until the DevSummit to see what ESRI has cooked up with their RESTful attempt but I know many people are so frustrated waiting at least this long for even a peak at it we might as we create our own. It backs into where I was talking about before, long lead times with ESRI Server software puts implementors in bad spots. Still I think we should wait the month and a half to see what they’ve come up with and it makes sense to have a meetup at the DevSummit to talk about what we want to do moving forward. We can also have an IRC channel running for those who want to take part in the discussion, but can’t make it to Palm Springs. I just want to develop ArcGIS Server applications using Javascript, don’t you?

Sound like a plan?

UPDATE : Matt says that I should know that ESRI will fail and we should forge ahead ourselves. Frankly I’ve not seen a thing about the ESRI REST API so I guess he is probably right. They can’t even give us a taste of the thing so as far as we should be concerned it doesn’t exist. He’s got no argument from me. Lets move forward on this then. Anyone game other than Dave, Matt, Doron and me want to step up?

The ArcGIS Explorer team has released the update to build 440 that addresses some of the issues that cropped up:

• Fixes problems on startup that have occurred with certain graphics cards and drivers.
• Fixes symbol display issues that have occurred with certain graphics cards and drivers.
• Resolves a problem with vector lines flickering when the globe is tilted.

The ArcGIS Explorer team has really been working hard and it shows. If you can do this with ArcGIS Explorer, why can’t you do it with ArcGIS Desktop? I think everyone would like smaller incremental releases.

What they heck is legacy anyway? Look if it ain’t running on VMS, it isn’t legacy in my opinion. Most people use “legacy GIS” when referring to ESRI, I get that because it is just another buzz word. Rather than tell me why I should use their product they just focus on the problems with ESRI ArcGIS, Oracle Spatial, Intergraph and not why their product is better.

So how the heck are you guys doing it? Google Maps and Virtual Earth have so much distortion up there (or down there as the case may be) that mapping is very difficult. Plus what happens when they navigate off the edge of the map? Anyway the closest thing I’ve found with decent polar projections is the ArcWeb SVG Map Viewer which allows you to dynamically change the projection, but I haven’t heard too much from ESRI on the SVG viewer so it might have been abandoned (I don’t see it anywhere on the ArcWeb Labs site).

What are people doing for mapping on the poles if you want to create a web based map product for a client who is working in the Arctic and Antarctic?

Update: I should say I’m looking for hosted web maps services. Using my own IMS server or relying on one that isn’t hosted in a good environment isn’t an option.

On another note, I like where the ArcWeb team has taken ArcWeb Explorer. The new (well new to me) ArcWeb Explorer 4.0 is slick. Might have to stop by the ArcWeb teams island at the DevSummit and see where they are taking this thing.

OK, so I’m going to use my own IMS server to handle the pole projection issue but that brings up a couple issues that I’ve got to figure out.

1. How to handle data that was not created in polar projections. Martin linked to a paper by Waldo Tobler that hits on some of the issues. Right now I’m only thinking points, but you know that the client will want polygons eventually.
2. What do I do with global datasets? Sure the Bipolar Oblique Conic Conformal works well for the poles, but what about the equator? Folks are used to Mercator so there has to be some sort of change between the two which adds complexity. I guess one could use a 3D globe such as VE3D, but I’d rather focus on the simplicity of a 2D map.

I’m paying my penance for making fun of polar projections all these years.

Freaking polar projections are making me bald

I have to congratulate both Paul and Aerials Express on this news.

How do you make a geospatial exchange a reality? You find great content providers to bring their wares to the market. Aerials Express (AEX) is one of those great content providers. With 420,000 square miles of high resolution aerial imagery over major metropolitan areas in the US (see map below), AEX brings base map content to ‘prime-the-pump’ in the derivative product marketplace.

One of the hardest things to do is host your own data. Letting companies such as WeoGeo do that for you frees you up to do what you are good at rather than trying to wear multiple hats. WeoGeo has the whole S3/EC2 thing figured out so scaling isn’t an issue. Just publish and forget about it works for both the seller of data and the buyer of data. Slow ArcIMS sites are no place to be searching for geodata.

Typing in geospatial searches in Google just doesn’t work (well I do get lucky sometimes). WeoGeo allows for these spatial searches and folks looking for aerial imagery in San Francisco (or anywhere else) will look for other data sets. This is more democratic than Google’s searches because it is spatial and not based on how many links there are to a dataset. Every dataset is available to everyone searching in an area (of course you can limit your search to types) so you won’t miss out on any available data just because the EPA or NOAA doesn’t link to it. For WeoGeo to grow they need these “premium” services such as Aerials Express, maybe they are on the cusp of something big.

Now if WeoGeo would only drop the Flash interface so it will work on my iPhone.

Doron Yaacoby writes that he’s absolutely frustrated with ESRI’s Web ADF.

As I’ve said before, this is one horrific development platform. I’ve started to seriously think about coding a replacement that will work against ArcObjects (at least something that will satisfy my team’s needs), but it would take a lot of time which we currently do not posses. One day, though, one day.

I think most of us have felt this way. He had earlier said this about the ADF:

…the API is riddled with bad design choices and bugs. Weird exceptions get thrown. You find out that there are 5 different classes that are called Converter in this API, in 5 different namespaces, which in some situations can definitely be used together. Documentation for most methods is something like: Map.GetFunctionalities – “Returns the functionalities of the map.” Oh really? Now I couldn’t guess that on my own. I should mention that since the initial release the documentation has improved a lot, but it is still no paradise. Recent documentation for this method (added since Service Pack 2, if I am not mistaken), explains that it returns a collection of IMapFunctionality. So why, why oh why, does this method has a return value of IEnumerable? This is a .net 2.0 only library, for pit’s sake, they can use generics. And they do, in many other places. Here, they don’t. This kind of API inconsistency can drive a man insane, I tell you.

The WebADF which was supposed to help ArcGIS Server developers ends up being more of a hindrance to them. We looked at the ADF early on for our products but my lead developer threw up his hands and said no more and I spent a whole week trying to write a WebTask and it was virtually impossible to figure out. Sure it works great for ESRI’s example but when you try and extend beyond what they’ve documented you might as well be coding with your eyes closed.

I haven’t tried coding with the WebADF with a bucket on my head yet

This brings up a bigger issue with ESRI products lately. With long lead times between versions, we get so much more added functionality in each release. So rather than small jumps where feedback can help grow the product we are left with frameworks being dumped on us and we have to figure it out because of poor documentation. Sure 9.3 is supposed to fix all this, but 9.2 has been out since November 2006 and if 9.3 is released to beta right before the Dev Summit how much do you want to bet that the final comes out near November 2008, almost 2 years later. So in the mean time, developers such as me get so damn frustrated working with ArcGIS Server WebADF that we toss it aside. And don’t get me started on ArcGIS Server 64bit.

As Doron says:

For the amount of money an ArcGIS Server license costs, a .NET developer like me could very well expect a decent .NET API to work with. The Web ADF is a .NET API, but it is hardly as powerful as ArcObjects are, nor is it any kind of decent.

Could all this be why so many ArcGIS Server developers I know are looking at SharpMap?