A reliable source at ESRI indicated at 9.3 MOLE symbols will implement ISymbol and IPersistStream, becoming more like all the other symbols in ArcGIS.  This will result in allow geodetic geometry for tactical graphics.   This is very good news.

ESRI also asked for input, so here goes ...

I really would like to see an enhancement (or fix) to the current display pipeline so that if I call IScreenDisplay.Invalidate on a cacheIndex for a layer that has its own cache (ILayer.Cached == true) then I would not cause a refresh of the overlying caches.  Last I checked, if labels are turned on then the cache for esriViewGraphics gets refreshed.  Regenerating labels is expensive.  I need a way to refresh only my layer's cache without refreshing the other caches.  IDynamicLayer is overkill when  refreshing only a few times per second.

Speaking of IDynamicLayer, there was interest expressed in having dynamic featurelayers.  An ESRI programmer indicated this is difficult because the underlying data structure is unknown.  I mentioned that the underlying datastructure could be an in-memory featureclass based on a plugin datasource so beefing up the FeatureLayer  to implement IDynamicLayer would be useful.

I guess the hard part would be juggling between IDynamicGlyphs and ISymbols, but seems possible.  Seems like a DynamicRenderer concept would be helpful.

Maybe just use .NET inheritance to inherit from FeatureLayerClass, then also implement IDynamicLayer.  Was told by a helpful user of a way to implement IPluginCursorHelper.NextRecord() without needing to throw a COMException to let the framework know there are no more records.   To me this seems like a bug - why should ESRI even bother calling  NextRecord() when they know there are no more records?  After all, I can see that they just called IsFinished and I returned true.

Another option I will explore is dumping the Plugin altogether and replace it with an in-memory featureclass based on the InMemoryWorkspaceFactory.  But then I'll need to synch this featureclass with my model instead of just wrapping my model. (speaking in MVC terms).

I also mentioned it would be useful to support transparency at the Symbol level, perhaps something like ISymbol2.Transparency property.  The renderer would also need to be beefed up, to support something similar to IRotationRenderer, maybe call it ITransparencyRenderer, with a TransparencyField property.  That way I could go into arcmap and specify a transparency field for a a particular layer.

My only concern about this is the way they are using the term "workflow" in context of Geoprocessing. They defined workflow as a models containing GPTools. What I worry about is that it will confuse people when they talk about workflows in context of SOA. Yesterday's plenary showed a cool Websphere demo dragging and dropping activities to create a workflow. Hopefully some day we will be able to drag and drop GIS based activities too, along with non-GIS activities. I don't think ESRI wants to position modelbuilder to compete with WebSphere or Microsofts WF extensions for Visual Studio - even though the IDEs share similar look and feel.

By the same token, IBM doesn't make life any easier by naming one of its tools Map Designer. The mapping it does is non-spatial.

Workflow is very important to a lot of GIS based activities. Think about all the permit approval processes for building infrastructure. The approval process will be determined based on what jurisdictions you fall within, or what watersheds, or proximity to schools. Cities want to streamline this process so that a real estate developer can quickly check on the status of a building permit he's applied for. Or perhaps would like to see what the approval process would be to build a particular type of building at a particular location. These workflows span multiple applications. Let's call them Enterprise Workflows. ModelBuilder workflows, on the other hand do not span multiple applications as far as I can tell.

Maybe somehow geoprocessing will be made to plug into Enterprise workflow? Attachments to the enterprise workflow would include spatial datasets, e.g. a subdivision CAD parcel drawning. Different activities would use spatial processing, overlay the subdivision with watershed boundaries, or existing infrastructure. But there would be a lot of non-spatial activities too, e.g. inspections. I really would like to see how to wrap GIS activities appropriately so they could be dropped into an enterprise workflow.

I've sat through more powerpoint presentations than I care to remember stating (with no references) that 80% of all business information has some sort of geographic aspect. Then they follow up with some geocentric diagram with GIS is in the middle and surrounded by smaller applications orbiting around it, in synch with Copernicus rolling over in his grave. That didn't happen this morning.

Instead, reps from IBM presented a new view based on a graphic similar to this, except with the Enterprise Service Bus as the integration platform.  Diagrams similar to this came up several times, almost as if this is becoming a mandala.

This new way of thinking revolves around a workflow, as enabled by the Enterprise Service Bus. Realization: it's the workflow, stupid! [Reminds me of the old joke "Census Poller: 'How many people work here?' Respondent: 'About half'"] Geography still matters - but only to the extent that it helps organize workflows, not as an end unto itself.

Julio Olimpio quite forcefully made the point that ESRI is committed to IBM, citing numerous multimillion $ projects they've collaborated on. Also mentioned 2 days of IBM's profits == 1 year of ESRI's profit. Profits matter. Given IBM's embrace of opensource, I wonder how they view their relationship with ESRI compared to opensource GIS.

WebSphere looks cool. I've been dabbling with the freely downloadable Windows WF extensions. I hope to soon test some workflows with GIS-based activities. I don't see any place to freely download something from WebSphere (if anyone does, please let me know). This redpaper seems to go into details of what they presented. I wish they would have gone into more detail about what differentiates them from Windows WF. Maybe they realized they'd be perceived as biased so they don't bother. I look forward to tomorrow's presentation by Mark Driver of Gartner group, I hope he'll go into this. I wonder if he'll talk about open source, as he has in the past.

Plenary Session

Attendance: 1600 (some said 2000) twice what it was in 2006.

Estimated Percent Male: 95%

Estimated Median Age: 40

The mandala for the Framework had 3 circles: Desktop, Server, and ArcOnline - unlike the mandala here, that has 5.

Others have blogged about what was said, so I figure I'll blog a bit about what was not being said:

COM

Very little mention. It's still there and its not going away. The web ADF is growing faster than the COM libraries. Service Packs will now contain new functionality. Was implied a lot of the new functionality will be in the web ADF. Interestingly, lots of code was shown, but no OMD's or any UML that I can recall.

Cost

In the past there was a lot of whining about price. Didn't hear any of that today. Maybe people realize ease of deployment justify license costs.

Custom Features

I guess Class Extensions are now the recommended approach. Larry Young did a good job presenting Class Extension demo. What ESRI really needs is a new class extension called ClassExtensionContainer. This would follow the composite pattern. Let's say I wanted to implement the classextension Larry showed us, only to find my featureclass already used the timestamper class extension. Well, if we had something like the ClassExtensionContainer, we could add both as subclass extensions. We would also need a new optional interface with something to establish what order the classextensions are notified for events. Maybe something analogous to IComPropertyPage.Priority.

Moving ArcObjects Code to ArcGIS Server from ArcGIS Desktop

Hosted by Jian Huang and Allan Laframboise. This was excellent. By the afternoon I was so saturated with new material from earlier sessions, it was comforting to see familiar desktop concepts along with a migration path into ArcGIS Server. A lot of good performance statistics for alternative approaches were presented. I look forward to seeing these posted as samples. Would have been nice to hear about debugging Server Object Extensions (SOE's). I haven't found a way to step through execution of an SOE using the debugger. I'm wondering if it might be a good practice to develop a class that implements both IServerObjectExtension as well as IExtension so that I can debug it using Arcmap as a test harness.

Anyway, currently I am in the main hall attending the track- "Increasing Developer Prodcutivity" by Erik Doernenburg. For more details log on to http://www.developersummit.com.

I didn't attend anything on the Java ADF or the Flex API. Neither of those are things I'll be using anytime soon so I didn't check them out but Fantom Planet did attend the Flex API session and seemed duly impressed. So, if you want details on that, you should probably nag him. ;)

I sat in on a session about the .Net Web ADF. I've already read Dave's post on the same session and his notes read almost exactly like the ones I have in my notebook so, rather than retype my notes (which would essentially duplicate Dave's post), I'll refer you there. BTW, congrats Dave!

The .Net Web ADF definitely seems to have a lot of improvements. The things I'm most excited about are a) all of the web controls being scriptable, b) the client-side JavaScript now being exposed, documented and supported, c) the re-engineering to use ASP.NET AJAX and d) resource-level tiling. ESRI put a lot of focus on reducing the number of server round-trips and reducing the need to execute the full page life-cycle. This will speed things up a lot. All of the items I just listed will have direct, immediate benefits on our Server projects. Oh yeah, using JSON to serialize their objects is cool as well. Additionally, the ADF is designed to use .Net 3.5 but you can toggle back to 2.0 if you need to. I see SilverLight in my future.

I've already talked a little about the REST API. I think that one is going to be huge. It really expands the scope of potential clients for ArcGIS Server services to just about anything. As I said, they even hit services from Ruby and Python during the session. "Everything is a URL" was the big take-away from that session. So, pretty much anything that can call a URL and understand the response can be a client. A lot of my clients have standardized on SOAP web services (didn't get to anything about the SOAP API but I'll catch up on that during the beta) but I plan on leveraging the REST API as much as I can outside of those areas.

The JavaScript API looks pretty good too. Using this, developers will be able to integrate ArcGIS Server services into Virtual Earth and Google Maps and other mashups. Mandown has an good summary of the session. Most of my customers will not be able to take advantage of ESRI hosting the API but that shouldn't be a huge issue. However, it (along with the SOAP and REST APIs) fit in well with the mobile code policies we have to adhere to.

When I went to the FedUC, Jack articulated a vision of ArcGIS providing advanced GIS analysis to whatever client you wanted to use. The Dev Summit really brought that home in a way that you could see it. The various APIs give lots of options that should fit into any environment.

Lastly, I attended the session on securing .Net web applications. The security model is essentially an extension of what we did at 9.2 but a whole lot easier to administer. They generally follow the ASP.NET model (OS security, Forms, custom provider). That'll make it easier to to get systems accredited. However, with regard to AGS web services, they've made one significant change for the better (IMHO). Security for web services is now managed by the SOM rather than being defined in the web.config. This has one huge advantage in that security is now applied consistently to web services regardless of which API you are using to access the services. This means that whether you use the Java ADF, .NET ADF, REST API, JavaScript API, SOAP API or whatever, web service security will be the same. I'll need to educate some of the security types I deal with on the SOM (and they'll want to red-team it, I'm sure) but I think it'll end up being an easy sell.

So, this'll be an exciting release for developers. I think it could be as significant as when we were all introduced to ArcObjects at 8.0. Now, I've just got to get into the office and set up the beta....

UPDATE: James raises a good point about the demos. They do make it look like you can do really cool stuff with just a little bit of code. It's important to remember that calling the service from the API is just one part. You'll still need to implement your complex logic in the service. Also, more sophisticated behaviors on the client will require more code there. It's important not to get caught up in the sales hype. 9.3 will offer some powerful options but it's important to keep the total level of effort in mind. The new APIs give you more options for developing your applications, but they don't obviate the need to actually write the code.

To sum up the REST API in one word: impressive. ESRI is definitely on the right track here. I think this API could end up overshadowing the others over time. After sitting through the session, I have my doubts about whether the API holds up to the strictest definition of REST but I came away unconcerned by that. The simplicity and the power of this API cannot be understated.

All resources (requests, layers, services, etc.) are represented as URLs. This provides the ability to very simply call powerful geoprocessing and analysis services running in ArcGIS Server. The API also supports a myraid of output formats. They demonstrated using Google Earth, Google Maps and Virtual Earth as clients. Also shown was the use of Python and Ruby scripts to call AGS services through the REST API as well as Yahoo Pipes. The output formats specifically discussed were HTML (default), (geo)JSON, KML/KMZ, image, layer (for use by ArcMap clients), NMF (for AGX), Google Maps and Virtual Earth. There's enough there to pretty much do what you need.

Before anyone asks, no they did not specifically mention OpenLayers nor was it shown but there were numerous examples of GeoJSON output. Based on what I saw, I think it would trivial to integrate with OpenLayers.

The REST API makes diligent use of caching in order to optimize performance. One aspect I was interested in was security. During the plenary, it was mentioned that AGS security can be managed using industry standards such as LDAP and others. While this is not specific to the REST API, it is worth noting that, once security settings are defined, they automatically apply across all of AGS's supported web interfaces. This will be a huge thing for many of my customers. In addition, security is role-based and can be applied to folders or individual services.

From a developer standpoint, 9.3 could end up being the most important release of ArcGIS in a long time. The JavaScript, SOAP and REST APIs will open up development to a lot of new developers. I think that these APIs will be critical to achieving the goal for ArcGIS articulated at the FedUC for AGS to be the geospatial analysis engine that can feed the visualization client of your choice.

A couple of other minor notes: AGS 9.3 introduces a geometry service that's not bound to any specific data but exposes geometric opertations to clients. Currently, the REST API only supports simple geometries so parametric types such as arcs and circles are converted to densified lines or polygons.

This was an impressive session. It looks like ESRI is putting a lot of effort into getting the REST API as right as they can this first time out. This session made me eager to get home and get the 9.3 beta running.

Some of us got to hear a great story from Don Cooke of TeleAtlas about the first ESRI UC. Fantomplanet has mentioned this story on his blog. I won't go into any details here (it's not my story to tell) but it was one for the ages.

Afterward, a group of us set out to grab a bite to eat and learned exactly how early restaurants close in Palm Springs. Chris and Dave bailed after the fourth place we tried was closed. About an hour later, I was thinking that they may have been the smartest ones among us.

Anyway, the meetup was a great time. It was good to meet those whose blogs I also read but it was also nice to get feedback from folks who have us in their aggregators. It's still sometimes a little surprising to learn that others may find some value in the things I type here.

Thanks to James and Dave for taking the lead on setting this up. There were rumblings of one in San Diego as well. If so, I'll be there since we're doing a booth this year.

I'm finally getting a chance to blog about this now. Steve, I, and nearly 2 dozen other attendees got totally screwed by the storms in Phoenix. However, at least we didn't have to sit on the tarmack for nearly 3 hours like the other group waiting at the same gate. Though, by the time I got home 25 hours after leaveing the conference, sleeping in the Phoenix airport and eating only pretzals and snack mix; that wait seemed pretty trivial. I hope everyone else also eventually got home safely.

General Thoughts

This was a short day. Only 2 sessions and then the lunch & closing session. It seemed that about 25-30% of the folks had already left and a number of the ESRI devs had left as well. The sessions seemed a bit less technical that those on Wensday.

Sessions Attended

Building & Using ArcGIS Server Map Caches (Best Practices)

The MapCache is a tile cache created by rasterization & tile cutting of the data you have presented in your MXD. The main take home points of this talk were:

• Understand what a tiling schema is 1st
• Design your tiling schema BEFORE trying to build on for production use
• Design a SINGLE schema that will serve the entire organization and all your data layers. In other words: Level 10 = the same scale for regardless of which layer you are building from; Tile sizes should be equal across various data sources; Use same origin point for all caches.
• Client can rapidly reproject data to any projection system so use one that makes the most sense for both your data and web services methods (ideally, Geographic).
• DO NOT use png24. PNG8 best if you need transparency, JPG best if you don't need transparencey.
• Smaller tile sizes (128x128) do not neccessarily result in faster performance over the web, while they take 5 times as long to produce & take up significantly more storage space than large ones (512x512). Test to make sure performance improvement is worth the extra effort. Use the largeest tiel size you can.
• Fuse as many layers together as possible to create your base map caches. Therefore instead of Intermitten Streams, Permanent Streams, Rivers, & Lakes all being separate caches, they would be a single Hydrography cache that would appear as a single layer in the map service.
• Each zoom level should be cartographically distinct
• Forcing an ExportMapImage call from a web service can be a big performance hit. Understand what would make a client do that and avoid it as much as possible.
• Building large many leveled caches can be VERY time consuming (days-weeks for worldwide layers). Pick a small area, TEST-TEST-TEST and then TEST before doing the full export, instead of having to do it over & over.
• Cache will build over the extent of your MXD if the layer(s) you are building a cache for don't have data in the full extent, background color tiles will be created. A waste of CPU time & storage space.
• Dynamic cache building (a la TileCache) is planned for future releases.

Creating Windows & Web Apps with WPF

This was not at all about GIS. It was strictly on WPF.

WPF is very powerful & can provide you with a lot of UI design patterns.

Security & Permissions can be tightly controlled. Each app runs in a security sandbox. App origin, app settings, and client settings all interact to chose the most restrictive security level for the app.

You can do stuff with this technology TODAY. But, it's real power won't be realized until Visual Studio ORCAS is released and Vista or .Net 3 runtimes are more widely accepted. The 1 code for web & desktop paradigm is only for IE6+ with .Net 3 runtime right now. Must use WPF/E for other browser support.

Closing Session

Open Q&A after lunch. No really hard questions were asked, but Steve & other continued to point out that the extra cost of putting the ADF on a separate server is just not reasonable, and that the overall cost of ArcGIS Server is too high.

I was really hanging this morning, for someone who has a beer or glass of wine only occasionally, going beer for beer with professional buisness travelers is never a good idea. But it was free and pretty decent beer so I can't complain too much.

General Thoughts

I got a whole lot more out of today's sessions and meetings than the 1st day. The talks I attended went into more depth, the .Net SIG was good, and I took Brian & James's advice and spent more time talking with devs in the Community center.

A few interesting things I learned in these informal conversations

• ArcGIS Explorer (AGX) will NOT have a custom skining option. You can mess around with some config files and the AGX document to change color themes, but that is about it. So a custom branded AGX that looked completely like your product but was actually AGX under the art, won't be easily done.
• AGX has no inherent editing capabilities, no area measurement tool and no way to discover any attributes about data sources other than local vector sources. You have to capture mouse events and do that work yourself.
• AGX has no way of directly interperting ArcGIS geometeries, you must provide a map/globe service that is spitting out rasterized data or convert that geometery to E2 geometery yourself.
• ArcWeb Services can add an ArcIMS service & soon an ArcGIS Server service to maps, but GeoRSS feeds, PostGIS, WMS, OGC, local/server stored vectors (shapefiles,PGDB, GDB, SDE, etc) all have to be progamatically adding in by transforming and adding the geometery to the map yourself. The only other way to get those alternate sources in is to intergrate them with ArcIMS or ArcGIS Server. If you do have a WMS you could but it through the OGC/ArcIMS translator servlet and leverage it that way.
• A large number of people have compalined about the highly fragmented documentation, poor indexing, incomplete docs, and lack of community comments on EDN & other ESRI help sites. It may just be conference talk but it looks like at least a few people at ESRI are begining to listen. Time will tell.

Sessions Attended

• Programing Custom Tasks for ArcGIS Explorer
• The task framework is not direct & intuitive. RTFM on that or you will really be lost. Not directly supported formats such as GeoRSS are not terribly difficult to transform into E2 geometeries and create content from a vast array of data sources. Just don't expect AGX to do that for you. Deploying custom tasks is SUPER easy. Deploying a malicous task is also possible so watch what you download. They are looking for ways to patch that which won't create Admin required installs. AGX2 is in the works and the more feedback you give them on the forums and directly, the better it will be.
• Special Interest Group: .Net
• A brief marketing talk about MS Visual Studio Team Foundation Server was followed up by Dave Bouwman's great talk about wrapping feature classes, SDE, & GDB in .Net abstractions using well known code gen techinques from non-spatial DB. It pulled together some of his posts on the subject and made it all look like such a better way to code. I've actually used the same techinques on shapefiles using RapTier and either the Jet OleDb or the ESRI OleDb drivers. Shapefiles are not as ammenable to being edited in this manner as PGDB or other real database storage formats are. I can read the data very well and databind on it but updating the gives rather unpredictable results.
• I would strongly recommend visiting Dave's blog and checking out his talk and an resources it is an exicting concept. It also makes you wonder, why they don't just offer Dave a position or short-term contract at ESRI to incorporate all they modern coding techniques in at least ArcGIS 10 if not 9.3. When you see simple object property assignments rather than the AO way of doing it and the self policing code it creates, you wonder why in the world would you want to do it the old way.
• James Fee hit on the craziness that is the 9.2 server licensing & the unreasonable expectation to pay 1/2 of the 1st license cost (of ~20k at retail) to put the Web ADF on another machine. He was told, "We know people don't like it, but that is the business model for today. We may be changing it in future releases but don't hold your breath" (paraphrasing, not a direct quote).
• Building & Deploying Enterprise Solutions with ArcGIS Server
• Not a lot of good tech meat here, just an eye opening talk about all the hoops & roadblocks that deploying ESRI server products in lerge organizations that don't conform to ESRI's way of doing things can cause.
• Developing Custom Web Tasks using the .NET Web ADF
• A lot of technical meat in this session. It went a long way to demonstrate that doing interesting things using this framework is not going to be so easy. You really have to jump through a lot of hoops to make cool things happen, and you have to jump through too many hoops to make super simple things happen. They covered a lot of techniques, tips, & tricks for working with this and I highly recomend veiwing this session on the post-conference web site if available. Especially the code that way demonstrated at the last 3rd of the talk.
• ArcGIS Mobile SDK
• A super energetic talk was presented by Jeff & Mike. They have really worked hard to abstract all the underlying native C++ code into a 1st class .NET SDK. They have built a really nice toolkit for VisStudio & using it and the Mobile 5 libaries, you can get some nice applictions working with a very minimal amount of code. It relies heavily on MapCaches produced by ArcGIS Server and they didn't go into creating those or pushing them out but I'm hoping to get that info in a later session. This was my favorite talk by ESRI thus far.

Due to airline maintance problems, I didn't get to the Summit until after the Plenary session was over. So I can't comment on that although several others can.

Rob Elkins - 1, 2, 4, 5
Dave Bouwman
The Steve0

General Thoughts

I was deeply disapointed with the 1st day of Tech Sessions that I attended. I figured that the Best Practices sessions would be general overviews, but the Deep Dives I attended weren't very deep. This was probably made worse by the fact that they couldn't get internet connections to work during the presentations. I should have followed James & Brian's advice to just hang out in the Community Center and listen to Tech Talks and speak with the ESRI Devs themselves. The highlight of that day was getting to meet somany of the other geo bloggers and members of the ESRI team whose names I knew but had never seen or spoken to before.

Sessions Attended

Leveraging ArcWeb Services in GIS (Best Practices)

This was a nearly utter waste of time. They basically just walked through the docs, info & help from ArcWeb Services home page. This site is in fact far more informative than the talk was. The only truly interesting bit of info from this is that AWX v2 will be coming out later in the year. It is currently in alpha right now. This will allow direct connection to ArcGIS Server and possibly OGC web services.

Building AJAX-Based Web Apps with Server & .Net (Deep Dive)

Slight snorkel would have been appropiate. Again, you could learn as much and more from the SDK docs. The main take home message from this was that the out-of-the-box toolkit and base classes have ICallbackEvent handlers pre-cooked into them. Thus you don't have to directly handle implementing the request & response callback functions in JavaScript. You just pass and recieve delimited text serializations. They delimited text was 30-40% faster than XML. JSON adds another 12-15% and will be directly supported soon (probably 9.3).

Deploying & Tuning ArcGIS Server / Leveraging GeoProces Framework in ArcGIS Engine .Net

The Server deployment was well attended and was also the subject of several very in depth Tech Talks. Grumblings about the licensing model and its pricing structure that actually discourges implementing the best practices models continue.

I caught the last half of the GP in Engine talk. That was rather interesting. Some compliants have been made about sending big tasks off to the GP only to have them fail or crash the coputer with no ryhme or reason. Appearently you can implement a listner that will talk to you about the status of your job as it is processing. That technique is not easily discoered through help docs.

COMMENTS CLOSED DUE TO COMMENT SPAM