I just gave Steve’s post about how ESRI’s fleeting movement towards community based, open communication seems to have been quashed by a segment of the organization who are wed to 90’s communication paradigms – slick marketing, throw sheets, and a tall shiny enterprise facade with nary a human in sight.

It is an interesting post, and although I’ve never been on the “inside”, the people I know at ESRI are all fantastic and very dedicated to building great software and systems. This is what makes ESRI more than the sum of it’s software. Yet this is sorely lacking in their communication strategy. So, being on the outside, the thing that comes to my mind is that there must be some layer in ESRI which is just not “getting” the whole open discussion = better control of the message. Since Jack seems to have

As Steve notes, open communications can also head off heated threads…

There was not one official word from ESRI anywhere clarifying this new stance on licensing. There was a heated thread going on and we all know that the ESRI folks read blog threads. We never see them officially answer anything there but from my logs and discussions with others, I know they read those kind of threads. Even if they dont respond on the thread there should be somewhere they can address this issue in a formal manner. There was enough heat there to deserve a little bit of light.

While it’s a small step, David Maguire’s blog is just too “happy+shiny” to be taken as much more than repackaged marketing. For more on what it takes to have a good “CEO” blog (or any blog for that matter), check Seth Godin’s free e-book ‘Who’s There?’ 

Anyhow – to the point of the post – in the comments on Steve’s post, Sean Gilles noted that someone posted to the OpenLayers mailing list re: an ArcGIS Server connector. A little digging on at OpenLayers.org, and here’s the posting…

I’m working toward creating a layer class for the ArcGIS Server 9.1
MapServer Object web service.  So far I’ve created the AGS layer class by
extending OpenLayers.Layer.Grid and it seemed that I also needed to create
an AGS tile class by extending OpenLayers.Tile.Image. [continues...]

– Brian Hatchl on OpenLayers “Dev” Mailing List Nov 29,2006
 

A Call to Action!
If everyone who does not like the ADF licensing model simply contributed 8 hours to this effort, we could have a free, robust, open, alternative that would address the needs of many many organizations. I mean – if I want to edit versioned vector data in a browser, then sure, I’ll pay for the ADF because that’s the powerful part of it’s power. But if I just want to server up a simple map, with simple functions, then OpenLayers would be just fine. Just look at how many mashups were created wit GoogleMaps – clearly pushpins and seamless panning can cover a lot of use cases!  

Anyhow – looks like it’s time to signup for the OpenLayers ”Dev” list and dust off my Javascript! 

This week I’m attending the ESRI’s System Architecture Design Strategies class, taught by Dave Peters. Last summer I posted about working with Dave at one of our client sites, and the class is a real transfer of his knowledge and experience in a very accessible form. If you are in charge of planning your GIS system design, be sure to get to this class.

Some interesting items from todays class:

I had never found the System Integration group’s section of the ESRI web site, and they have a whole mess of performance test reports there – all kinds of intersting stuff like ArcGIS Server/ArcIMS performance on 64bit Windows Server, ArcIMS perfomance on Dual Core CPUs and a bunch of papers on high-availability solutions. Very cool if you are thinking about your technology platform.

We also discussed the 9.2 Server licensing situation.

First ArcSDE…
At 9.2 they have put a lot of work into addressing the “chatty” nature of the direct connect, so it’s now supposed to be pretty close in performance to running ArcSDE on the server (giomgr.exe processes). So, that’s nice. The upside of using direct connect is that you don’t have to pay for an ArcSDE license for each socket on your DBMS box. So, this should be a cost savings since there is less load on your DBMS box (no giomgr.exe processes) – which means the same hardware can serve more users. And when you do scale up, there is no licensing hit to ESRI.

The downside is that for direct connect, everything must match in terms of version – so, your 9.2 clients must attach to a 9.2 database. Not bad, but service packs may also be linked – so if you patch the server, you’ll need to patch all clients before they can connect again. So – while cheaper out of the gate, the admin complexity may make you think twice.

Which leads to a third option – running the ArcSDE service & giomgr.exe on a totally separate machine. [UPDATE 11/29: Apparently this has been an option for quite some time] Apparently this is a new option with 9.2, and although you have to pay for the sockets, it may be a better mix between SDE on the DBMS, or direct connect.

The ADF…
We also talked about the ADF, and as I noted, the current stance on the ADF is that the server it is deployed on must be licensed for all sockets.

I can’t quote anyone on this, but apparently that there is quite a bit of room to negotiate with ESRI in regard to using the ADF to upgrade existing (particularly ArcIMS) applications.

That’s it for today – tomorrow we’re going to be talking about security & firewalls. This should be very interesting, as it will hilight some of the issues I see with having to have the web controls on the SOM/SOC box (or pay double)

The ArcGIS Server 9.2 help is online at http://webhelp.esri.com/arcgisserver/9.2/dotNet/

Check out the “ArcGIS Server Editions” for the rundown on what’s in each version, and at the bottom of that page, it lists the number of sockets the workgroup and enterprise editions support.

No mention that the ADF web controls can not be pushed to a remote web server, but this looks like end-user documentation, and not the developer help.

[Update: Once James Fee linked to this blog, the comments started to pile up over at his site. Here's a link to them.]

[DISCLAIMER: I do not work for ESRI, not do I represent any official stance on licensing. This is how I understand things from talking with ESRI. I'm fully willing to ammend this posting if ESRI has substantially changed their policy from what is described here.]

Ok – I’m not the first one to post the “reported” price for ArcGIS Server – someone else did in comments on James Fee’s blog. Anyhow, I’ve been looking around the ESRI ArcGIS Server pages for the list pricing, and have not found anything. So, for this post, lets use $XX,XXX instead of specifics. The actual dollar price is not my point here. Suffice to say that ArcGIS Server is not cheap, but the devil is in the details.

The other thing I’ve been looking for on-line is the actual licensing breakdown for the ArcGIS Server components. Since the server has multiple components (SDE, SOC, SOM and ADF), I want to know how those pieces are licensed, and how I should expect to configure a system.

In particular I want to know how the pricing changes if you run ArcSDE on a separate machine, and the ADF on a separate web server. I’m not sure about how you do things, but typically when I’m building a web application, I assume it’s going to be running on a web server. The geodatabase will be on a separate DBMS box, and (for server) the SOM/SOC is on a dedicated server. This is what we’ve been instructed to do in the past, so I’d assume this is the model to move forward with.

First, ArcSDE. The deal is that while you “get” ArcSDE with ArcGIS Server, if you want to run the ArcSDE “service”, the DBMS and the service must be on the ArcGIS Server box. If it’s not on that server, then you must pay full per-socket pricing for the DBMS server. Ok – this is pretty much how the ArcSDE pricing model went. If you choose to use ‘direct connect’ then you leave the “licenses” on the ArcGIS Server machine, and simply connect to the DBMS server – at no additional cost.

Conclusion: Direct connect is gonna get a whole lot more common.

Next up – the Web ADF. Since the Web ADF has all kinds of cool functionality, I was really interested to see if there was a licensing fee for deploying it. At ArcGIS Server 9.1, you had the ADF Runtime that you could install on the target webserver – there was no separate licinsing for this component. So, I had high hopes. But, what I’ve come to learn (by talking with ESRI because it’s not published anywhere I can find) is that the ADF is licensed at 9.2. And it’s not just a little run-time cost. It’s the full per-socket price of the server. That’s right – if you want to run your web site on a different system from your SOC’s, you need to fully licence that machine – at the same level as the SOC’s it talks to.

Here are my concerns:
Security. Assuming you got with the all-on-one box model – where are you going put it? On the LAN? Then you need to open ports from the internet onto your LAN – not exacly something your security admin will like doing. If not the LAN, then in the DMZ? How many security admins are gonna let you put your enterprise dbms in the DMZ?? Thus, it would seem to me that for anything other than intranet apps, you’re looking at a 2x price bump simply because you need to put the ADF on a separate web server.

In my discussions with ESRI on this, they said that because the ADF now handles the tile cache, it actually off-loads much of the map making work from the SOCs, which means it should carry the same licensing. While it’s true that a tile cache saves a lot of work, is true it’s not exactly a compelling argument. Creating a tile cache is not magic that can only be done by ESRI. Brian Flood has implemented this in the next version of Arc2Earth (pro edition costs $299). Slap OpenLayers (free) in front of that, and you’ve got the same thing running for a tiny fraction of the cost. So telling me that I should pony up twice the money for server because of a tile cache is not compelling at all.

So – where are we. If you want to design a system the way you have it running today – you’re looking a 3 times the base pricing for server – this will get you ArcSDE running as a service on a separate DBMS (assuming 2 sockets) and the web ADF running on it’s own server (also 2 sockets).

Anyhow, I just wanted to post the details as I understand them since ESRI (at this point) has not posted anything related to this, and I know there are a lot of people who are excited about the web ADF, and this is going to come as a big suprise.

Just got the notice from ESRI that it’s time to register for the Developer Summit!

Last year it was a great event – good technical info in the sessions and a chance to talk to the developmen teams, other bloggers and other developers. I’m planning on going, and brining my project leads along as well.

Last year there were “Birds of a Feather” talks which were informal meetings, setup by attendees, on various topics. Last year I informally led a session on unit testing with ArcObjects, which drew a much larger crowd than I anticipated. (see below – I expected nobody to show up!)

(photo credit: Brian Goldin)

Assuming anyone is interested (and that they have these slots available again), I’ll try to get another one setup for unit testing and a second one about code generation and the concept of an object based data access layer for the geodatabase, and using databinding with that.

If this sounds like a good idea (or if it sounds painfully boring) let me know in the comments.

Also – I think I’ve got the IE problems solved on this site, if I don’t please let me know (or use FireFox!)

See you in Palm Springs!

I’ve been spending my “free” time re-skinning my main site, and adding more content into it. It’s not fully cooked at this point, but at least I’ve got the fluid layout working in both FireFox and IE (I think). During my testing, I also found that there are still IE issues on this site are not exactly fixed, so I’m going to look into that as well (sorry if you use IE!).

Here’s a shot of the new site – not suprisingly it looks like the blog skin.

It does use the ASP.NET site map to generate the navigation links.
Since the out of the box ASP.NET menu control emits tables (yikes!),
I’m also using the “CSS Friendly Control Adapters”
which enable various controls to emit different markup. Specifically,
the menu contol can emit ul / li tags which significantly simplify CSS styling. Once this is done, you can just drop by DynamicDrive’s CSS Menu page and pick out the base menu you like, swap out some colors, and you are on your way. Nice and easy.

On a GIS note – I’m also going to be adding more content into the site, including some OpenLayers examples in the Sandbox, and a “white paper” on Code Generation + Geodatabase + ArcDAL.

For the last few weeks I’ve been working on three elements of an enterprise system – high-level functional requirements, the system architecture and the geodatabase design. I’m working from a mass of information collected from weeks of on-site meetings and a mountain of documentation supplied by the client. And, for the most part, things are going pretty well. Except for the actual geodatabase design experience.

The Present
The standard practice for creating a geodatabase model is to use Visio or Rational Rose to cookup the model in UML. Ok, I can see where this started – UML is handy for designing class model diagrams, and the various elements in the geodatabase are classes. But there is a lot more in the geodatabase than can not easily be managed in UML – projections, topologies, rasters. And the whole use of tagged values is truly painful. Overall, the entire process is horribly inefficient.

One issue is that there are several hundred possible “types” for a field…

While this makes sense for a Uml model, it’s a pain for geodatabase design, as there are only 12 valid attribute types (plus the Domains in the model). Yet I still have to jump through this list for every single attribute on every single class.

Once you’ve finally created your model, and gotten it to validate, you then need to load it into a geodatabase. This is pretty smooth, but you need to manually define the projection for every featureclass (or dataset) in the model. And then you need to setup the topologies. Manually. If you need to do this iteratively – like most design processes – then you need to repeat this process several dozen times.

Don’t get me wrong here – this is a million times better than trying to manually bake a geodatabase via the ArcCatalog interface, so thanks to ESRI for giving us this option. But, if we’re wishing for 9.3 goodies, this would be a nice thing to fix.

The Future
What I’d like to see (either from ESRI, or anyone else who’s got some time, and wants to make some money) is a tool which can handle all aspects of the geodatabase. I want to define my topologies and projections in the design, not later. If I’ve got rasters, let me have them in the model. Networks? Yep. The question is: How?

Lets start at the end – How can we get a geodatabase design into a geodatabase? The current method is to use the CASE Tools in ArcCatalog to load the Visio or Rational produced Xmi file. The other option is to use an Xml Workspace document. They store all aspects of the geodatabase, so it’s an idea option. Typically these are used to transfer schemas (or data) between geodatabase instances – usually ArcSDE instances, but there is no reason that they could not be co-opted as a model storage format. Ok, that part is solved.

What we really need is a nice front end. The key here is to keep the interface simple. Designing a geodatabase is not rocket science, and should be really easy. Have some simple design surface, but I don’t see a big need to show all the fields. Just the class name, it’s type and the relationships it particpates in.

Have another design surface to show the topologies. The editor UI for the classes should be very easy to use – instead of crytpic tagged values for the geometry type – how about a pull-down? For relationships, just connect two classes with a line, and present a simple dialog for picking PK/FK, notification. Simple, focused, and all about the geodatabase. And if you offer it for $300, I think you’ll sell a ton of them. Heck – maybe ESRI buys it from you and ships it with ArcCatalog, and all our lives are just a little bit better.

For now though, it’s back to Visio for me. joy.

UPDATE: This post got caught up in the tidal wave of blogger spam on PlanetGeospatial,
so I am re-posting it with todays date. I’m really interested in
hearing what other people think about this. However, in re-posting, dasBlog
seems to have misplaced the post – and along with it a comment – doh! For
those who subscribe directly to by RSS feed, sorry about the
repetition. — Dave

Rather I’d like to see some real live
examples that people can play with. You would not buy a car without test driving
it, so I’m not sure why we would expect any less from our software vendor.

Here are some ideas…

ArcGIS Server: Web ADF

Let’s see a real application with large,
complex data model – maybe based on the Local
Government data model. Show us an editing environment customized for non-GIS
pros who don’t know or care about versioning. Throw in some imagery from Image
Server and make sure access is managed via ASP.NET security. Sounds like a tall
order, but consider that Local Governments are a prime target market, and it’s
not that unreasonable.

From a developer perspective, I’d love
to read about how it was built, the best practices which lead to clean,
maintainable, testable code. And a glimpse behind the scenes at the hardware
that’s powering it. This does not need to be totally public – make people login
with their ESRI Global Account, or limit it further to EDN subscribers. Whatever
- but let’s see the beast in action so we know what we can expect.

ArcGIS Server: Geoprocessing

Although the “GP Solves all
Problems” rehetoric of last years DevSummit has somewhat died down, it would be
cool to see a real GP model – doing more that a trivial buffer operation or a
hill shade on a limited area, running in ArcGIS Server, accessible for EDN
developers. Get really daring and have it do some raster processing. 

Make the model itself downloadable so we
can see how you’ve built it, talk about how you have optimized it, what hardware
it’s running on, and what it’s really doing.

ArcGIS Server: OGC Services

Fire up some WMS/WFS services that have
real data volumes behind them (say the state of California).  Then let the
community hit it with whatever client they want to use and report requests per
second, data volumes and CPU utilization. If that level of access is a little
broad, show us how to limit access via a and restrict it to EDN subscribers.

ArcGIS Server: KML

If you’ve got the OGC Services up, add
on the KML service. Let people see what can be expected with this service. Of
course it’s not going to be as fast as Google, but be transparent about the
hardware, and load, and I think that the user base will follow along.

ArcGIS Explorer “Tasks”

With the launch of ArcGIS Explorer, it
would be nice to see some real “tasks” that do something a little heavier than
reverse geocoding or returning the Zip+4 for a point. How about a site analysis
within an AOI? Or a network trace? Something that’s actually using the
analytical power of ArcGIS. Something burly because that’s what people are going
to expect/want when they drop cash for the backend ArcGIS Server software that
will support it.

 
Overall, I’d really like to see
demos that set realistic expectations. To date, the ArcGIS Server 9.2 hype has
been reaching snake-oil levels:

• Publish maps by merely thinking about it!
• Shed pounds by sleeping!
• Code? Nah - use geoprocessing for everything!
• Cures hemhroids & rhumatism!
• Run ArcGIS Server, ArcSDE and your web site all on one box!

Some reality will help everyone manage
expectations.

Since I’ve become a total FireFox junky, I did not exactly do any really serious testing of my new blog skin with IE6. Turns out that there was a CSS issue where the left menu got stuck at the bottom of the page below all the posts.

It’s this sort of thing which makes me really glad that I’m not a web designer.

It also hilights why the whole “browser war” is lame, and wastest coutless dollars of web design time. Since there is no way all the vendors/developers will build browsers which consistenly render html/css, the whole idea of having two (or more) browsers with serious market share is actually detrimental to designers. Of course you can get on your high horse, and say the Mozilla/FireFox renders it all “correctly”, but the point is moot because sooo many people still use IE that you simply must handle that browser  – regardless of how “broken” it is.

One True browser
What is needed is “one true browser”, and in some ways Flash fills this need. A Flash app will run/look the same on a Mac, PC, IE, Opera, FireFox, Linux – whatever. And that’s the key to rapid development -ain’t nothing rapid about messing around with the idiosyncracies of a whole bunch of browsers.

Anyhow, a little bit of cursing, and some love from the CSS section over at DynamicDrive, and all is well for the IE crowd.