UPDATE: You can now download this blog post. 
My apologies for the super-long post; I was originally going to break
this up into multiple posts, but my week at the conference filled up very
quickly and I couldn't find time to write out all my thoughts and experiences
and post them daily. To try and facilitate reading of this post, I have,
however, broken it up by day and by technical workshop. And at the end of the
post I have written about some miscellaneous tidbits that I discovered over the
course of the week. I expect that in the coming weeks I'll be writing more
in-depth about many of the topics that I am able to cover only briefly below, as
many of the developments have major ramifications for anyone who works with ESRI
software.
Judging by a recent post from an austere colleague, I guess that being a
participant at the ESRI User Conference (from here on referred to as the
UC) puts me (and many others - you know who you are) in a position that brings
an inherent level of responsibility. I'll be honest, though, I wasn't aware of
these overarching responsibilities when I signed up; my apologies for not
reporting the juicy details sooner. Fortunately, though, my
colleagues seem to have adequately filled the void that I unknowingly
contributed to over this past week.
That said, I walk out of San Diego a week older and with a number of news
items, tidbits, and rumors - enough, at least, to get me pretty excited. I'm not
sure that there were any monumental announcements or "WOW!" moments this year (a
lot of the big announcements were spoiled by Jack's answers to the Questions and
Answers that were released the week before the UC), but ESRI and some of their
partners talked about coming developments that will definitely push GIS in a new
direction over the upcoming year, for good or for worse.
Following are my own personal highlights from this year's UC. Please note
that I am a .NET developer and self-proclaimed technologist, and am, therefore,
totally geeky and focused on topics that are of interest to me. I didn't get
much out of the "Everyone Loves/Needs/Uses GIS" sessions, the plenary talks, or
the desktop productivity sessions, although overall it was nice, as a colleague
of mine said, to hear others talking about GIS when having dinner at a random
restaurant in the Gas Lamp District. I did, however, get a lot out of
interacting with ESRI developers and the various vendors, and these are the
moments that I want to pass on in this write-up.
Monday, June 18th
Plenary
A good portion of the plenary fit into the "Everyone Loves/Needs/Uses GIS"
category mentioned above. I'm glad to know how GIS is being used around the
world, but as a GIS professional I don't have to be sold on the idea of GIS as
an invaluable tool. The demonstrations and announcements at the end of the
session caught most of the news, although unfortunately a lot of them fit into
enhancements that should have either been included with ESRI's 9.2 releases (or
8.3, 9.0, or 9.1 in some cases) or addressed in service packs - that is, now
that ESRI is actually releasing new features, not just bug fixes, in its
patches.
Like I said, most of the highlights were covered in Jack's response to the UC
Questions and Answers that was released last week, but here are a couple
of developments that really caught my eye (note that I cover most of these,
in-depth, in the commentary below and also that there are many more developments
that didn't make it into the plenary that I cover in-depth below):
- More Transparency Within ESRI's Support System
- Release of ArcGIS Server JavaScript and REST APIs
- Enhancements to ArcGIS Server's Tile Generation Capabilities
- New Permissions Management Capabilities Added to ArcGIS Server
- Better Print Support for ArcGIS Server
- New Mobile Client for ArcGIS Server
- Support for PostgreSQL in ArcSDE 9.3
Tuesday, June 19th
ArcPad 7.1 - An Introduction
I've been working with the 7.1 beta for a couple of months now, and, because
of this, was excited to hear a bit more from the ArcPad team about the upcoming
release. First of all, I'll say that ArcPad is improving dramatically. The
project was pretty stale for awhile, but seems to be picking up development
momentum (which it really needs). The good news for ESRI is that there isn't
(and hasn't been) much real competition out there in the GPS software arena, so
they haven't lost much ground. Actually, it seems like they are - amazingly
enough - still in front of the small group of GPS software vendors. Sure, many
users love Terrasync and its easy-to-create forms, but most major organizations
that use GIS are ESRI shops and need: 1) something that will fit into their
overall GIS infrastructure (read: enterprise) strategy and 2) software that is
released and supported by a company that they know will not go under in a year's
time.
ArcPad 7.1 introduces a new extension for ArcGIS Desktop. They're calling it
"ArcPad Data Manager" and, unlike ArcPad 6.x's desktop extension, it is
installed (and, thankfully, un-installed) with ArcPad (so it is
not installed when ArcGIS Desktop is installed). This
new tool adds quite a bit of functionality to the check-out/check-in process,
which is a process that, although it always seems to work well for me in 7.01,
is always the most difficult part of working with ArcPad for users who don't
have a lot of technical experience. I can't tell you how much time I've spent
walking users through the check-out/check-in process (literally over and over),
even after developing comprehensive step-by-step documentation that shows them
exactly how to do it. I'm thinking, though, that this new data manager extension
will solve many of these problems, as the status of checked out data are no
longer stored locally on a computer. They are, rather, stored within the
checked-out data themselves, which means that a user can check data out from one
computer and then check it back in using another computer and it doesn't have to
live in the same exact directory location to be successfully checked back in. On
top of this, check-in can now be initiated from within ArcMap, allowing a user
to browse to the data that need to be checked-in rather than having to make sure
that the data that need to be checked-in live in the exact same place in the
directory as the data that were checked-out. Although this may not sound
earth-shattering, it is a very welcome enhancement
that will likely save me hours of troubleshooting by telephone.
To describe the new ArcMap extension more fully: When the "ArcPad Data
Manager" extension checks data out of a geodatabase, the data are now placed in
a single xml file, with an .axf extension. This allows for all of the data to
remain in a single file. The .axf format uses SQL Server Compact Edition to
store its data, which allows for much more to be done with the data in ArcPad.
The biggest enhancement that this new format allows is the support of related
data within ArcPad. We were shown a demonstration of creating a single geometry
feature in ArcPad and then collecting attributes that lived in related tables.
This is obviously a huge development for ArcPad, and is an issue that the
ArcMobile team doesn't seem to have a clear solution for (more on this in the
ArcGIS Mobile - The Road Ahead and Developing
Applications with ArcGIS Server Mobile SDK sections below). The
important thing to get across here is that these relationships are supported in
the data (the .axf file), not in the forms. This should allow for easier
transition in and out of a geodatabase without having to custom-design
applications. Another important development is that the check-out and check-in
tools will now be available in ArcToolbox, allowing for easy scripting of the
check-out/check-in process with Python. I'm personally hoping that I'll be able
to make the whole check-out/check-in process completely invisible to our
organization's mobile users, as - like I mentioned before - this is the biggest
problem that they run into when working with ArcPad today.
A couple of miscellaneous other enhancements that were discussed in the
session, in no particular order:
- On check-out, you can now name the .apm that is created whatever you want.
- Data that are checked out can now be optionally encrypted and
password-protected.
- Forms will no longer be overwritten on check-out, unless specified by the
user. This means that customized forms can be built to support data collection
and used without the user having to manually move and overwrite the form that is
generated on check-out out of the geodatabase.
- If the geodatabase enforces unique identifiers, this will be supported in
ArcPad, as well. As a sidenote, it should be easy to generate GUIDs with the
.NET Compact Framework and SQL Server Compact Edition, so if you use GUIDs a
lot, it should be simple to implement in the new ArcPad.
- New editing features introduced.
- Better GPS height support.
- The ability to capture features using a traverse method.
- Better support for cameras.
- Better search capabilities within ArcPad:
- The ability to pre-configure query forms within ArcPad Application Builder
Studio is now included.
- A more intuitive search interface, including support for basic
SQL.
- Support for read-only features.
- Enhancements to label tools.
- The ability to set a snapping tolerance, per layer, within ArcPad.
Another question that kept on coming up, over and over, at the UC centered on
the seeming overlap between the ArcGIS Mobile and ArcPad products. Here's how it
was described to me: ArcMobile is meant to serve as an easy-to-use client for
ArcGIS Server. It can connect to servers in real-time and has some GPS
functionality integrated. It does not, however, support many of the advanced
features that ArcPad does, including support for connected devices
(rangefinders, etc.) and will never have as much GPS support and as many
advanced features as ArcPad. The ArcMobile team is really looking to appeal to a
specific market, those who use ArcGIS Server and have a need to collect some
basic data while in the field. To me, ArcPad really shines when there is a need
to collect complex data into a geodatabase without having to custom design an
application. ArcMobile seems to be better suited in cases where a very-targeted
application that communicates with ArcGIS Server is needed and more flexibility
is desired for developing on the client-side.
For me, I'm interested in both technologies. I love to have choices when
hashing out the requirements of an application and deciding on a solution, and I
truly think that my organization will be using both ArcMobile and ArcPad,
depending on the needs of each specific project.
ArcGIS Server - The Road Ahead
There were tons of upcoming enhancements to ArcGIS Server 9.3 announced at
the UC. Most of these, however, for me fall into the "should've been there at
9.2" category. I don't want to always be negative, especially when I think that
ArcGIS Server is a great product that has improved dramatically over the last
two service packs (even with some of the workarounds that are still required,
yet-to-be-fixed bugs, and lack of cohesive and comprehensive documentation).
ESRI needs to realize, though, that they can't continue to release beta products
as runtime.
One glaring example of this is the documentation for ArcGIS Server 9.2; it
basically didn't exist when 9.2 was first released and still lacks some critical
pieces. What's the solution (other than trying to catch up on the documentation
as soon as possible)? I've got a couple of ideas:
- Loosen the release cycle, opening it up so that the different product teams
can release when their product is actually ready. They've done this with ArcGIS
Explorer (which is another product that should've held off on its initial
release), and, because of this, the team is on a very aggressive release
schedule and is able to quickly respond to bugs and feature requests.
- Open up the beta program to a larger audience. There are obviously problems
with ESRI's beta process when their initial releases don't perform as
advertised. Opening up the beta to more real users could dramatically increase
the amount of feedback coming back to ESRI, allowing them to truly test their
product before initial release.
Anyway, I'm not going to solve all of the world's problems today, so enough
about that and back to the topic at hand: upcoming developments in the ArcGIS
Server product.
First of all, ESRI announced in the UC Q&A that they realized that ArcGIS
Server 9.2 shipped without proper documentation (see my rant in the first
paragraph of this section above), especially for developers. In this session -
and at a few other times during the UC - they mentioned this again and made it
clear that they are working hard to improve their online help and documentation.
This is, of course, very welcome.
Another very welcome development is ESRI's decision to release JavaScript and
REST APIs for ArcGIS Server at 9.3. This is another development that was first
announced the week before the UC, and then again at the plenary, and then
mentioned/discussed several times during the course of the conference. But I
never got sick of hearing about it. Here are some more details:
- The REST API will be completely securable, just like any other service that
is served by ArcGIS Server.
- The REST API supports querying, geocoding, and geoprocessing.
- The JavaScript API(s) will allow for easy development and deployment of
lightweight web applications that consume both ArcGIS Server services and third
party data services, like data consumed from ESRI ArcWeb Services, Google Maps,
Mapquest, Microsoft Virtual Earth, and Yahoo! Maps.
- A token-based authentication system for JavaScript clients is also being
released.
Further enhancements that are coming to ArcGIS Server 9.3 follow, in no
particular order:
- Enhanced AJAX Support
- Microsoft's ASP.NET 2.0 AJAX 1.0 extensions will be fully supported in the
9.3 release of ArcGIS Server. This includes support for Update Panels. With this
addition, developers now have a choice as to which callback model they use. It
will still be possible to use the current ASP.NET 2.0 callback implementation
that is used in 9.2, but I am recommending that all of our applications migrate
fully to ASP.NET AJAX, as it is a powerful, clean, and easy-to-use
implementation. As an aside, as many probably already know, it is currently
possible to use ASP.NET AJAX, but there are a lot of workarounds to get some of
the ArcGIS Server controls (especially the map control) to work correctly when
wrapped in an Update Panel.
- Partial page rendering model supported (comes with ASP.NET 2.0 AJAX
1.0).
- New security management module will be included in ArcGIS Server Manager.
This will allow administrators to set up access permissions for both services
and applications using groups and users. I don't think that roles are supported,
although I'm not positive about this. Of course, this is all currently doable in
9.2, but you have to manually configure NTFS permissions - if using Windows
Integrated or Active Directory forms authentication - and manually make changes
to the web.config. See the "Miscellaneous Questions/Answers and Other Tips
that I Picked Up" section below for a little tidbit of helpful info that I
picked up when speaking with the ArcGIS Server development team about
configuring a web application and associated services to use Windows Integrated
Authentication.
- Ability to manage users per application and/or per service.
- Can ensure that all communication with ArcGIS Server is encrypted (again,
already doable in 9.2 but supposedly easier in 9.3).
- As mentioned above, new token based authentication system for JavaScript
clients.
- Can work with Windows authentication or use forms authentication and store
user information in SQL Server database.
- A big development in the open standards arena is that ESRI, with ArcGIS
Server 9.3, will introduce support for GML, WCS (1.0 and 1.1), and WFS and
improve its implementation of WMS.
Unfortunately, though, for ArcGIS Desktop
users the Data Interoperability Extension is required to access WFS services. To access WFS in ArcGIS Desktop, you must *install the Data Interoperability Extension (it doesn't have to be licensed/activated).
- At 9.3, Image Server will become an extension of ArcGIS Server. From what I
was able to gather, this does not, however, move Image Server from Category B to
Category A, so licensing for enterprise partners is not necessarily going to
change with this release. That said, from talking with several ESRI employees,
it does seem like they are considering eventually moving Image Server to
Category A. An image service:
- Can deliver data or pictures.
- Is, from what they are saying, very efficient at serving WCS and
WMS.
- Major enhancements to ArcGIS Server tile caches are coming at 9.3. As you
can tell from earlier posts and comments that I've made on this subject, this is
an absolute must for my organization. We have had major problems developing tile
cache for many of our projects that cover large areas and need cache at large
scales (e.g. half of the world at many scales, the largest being 1:1250).
Actually, we haven't been successful in generating this particular cache, even
using several servers for weeks at a time. Well, ESRI says that they've fixed
many of the tile cache generation problems at 9.3. Here are some of the
enhancements that will be coming out:
- Ability to generate tiles that match the tile format for ArcWeb Services,
Google Maps, and Microsoft Virtual Earth.
- On-demand tile generation: This enhancement, if it works as advertised, will
likely fix many of our problems, although it's not the perfect solution for our
organization. This basically allows you to generate tile cache up front only for
areas that you foresee users actually zooming into. For areas that may not get
used as much (or at all), you don't have to generate tiles, but if a user zooms
into them tiles are generated on-the-fly and then added to the existing cache
for future users. This is a decent solution, although it's not always easy for
us to predict where a user's interests lie, and I'm afraid that generation of
tiles on the fly is going to be horrendously slow.
- Generate tile cache based on extent of a feature: This is another *very
welcome enhancement, as it should, theoretically, allow us to more effectively
partition out and track our tile generation. One of the major problems that we
currently have is that when cache generation fails for a large cache build
operation, it is often difficult to discover exactly where it failed and then
reinitiate the build from that point.
- Some user interface enhancements (for applications built using the wizard in
ArcGIS Server Manager) coming at 9.3 include:
- Zoom previous, zoom next buttons with another tool for toggling an overview
map.
- Map tips will be able to contain static text, images, links, and JavaScript.
- A new print task will be available in ArcGIS Server Manager and will include
the ability to work with map elements.
- Enhancements to the Web ADF will allow developers to take advantage of
session state.
Some very exciting news above! I look forward to getting my hands on the new
release.
Deploying and Using ArcGIS Explorer
This technical workshop with Bernie Szukalski presenting ArcGIS Explorer was
one of the best of the conference for me, if only because it's always nice to
hear from someone who is excited about the topic that they're presenting. I've
played around quite a bit with ArcGIS Explorer and have been encouraging our
organization's GIS users to use and deploy it since the last build (380) was
released, but it was still great to see some of the tweaks and operations
(tasks) that the interface supports. It was also good to hear a bit about the
development environment surrounding ArcGIS Explorer and get some of my questions
answered by those who work on the project.
The ArcGIS Explorer development team is not constricted to the standard ESRI
release cycle, so they've already had four releases since the initial release
with the overall 9.2 release and they plan on releasing a new build (with
feature enhancements, feature additions, and bug fixes) every two months. The
next release is expected within the next couple of weeks.
As this was more a "show me your product" type of session, I didn't get much
in the way of technical news from it. I did, however, get more in the
Extending ArcGIS Explorer Using the ArcGIS Explorer SDK
session, which is covered below.
Wednesday, June 20th
How to Develop Rich, Web 2.0 Style Flash Mapping Applications Using ArcWeb
Services
I wasn't expecting to get too much out of this technical workshop, as, I'll
be honest, I haven't paid much attention to ArcWeb Services as it has really
come of age over the last year or so. Well, I'll tell you sheepishly now that I
was very pleasantly surprised. ArcWeb Services seems to be another valuable tool
in the expanding web map industry, and I'll be experimenting with it more
shortly.
One of the main reasons that I want to spend some time working with ArcWeb
Services, other than the product itself, is that it was mentioned in this
session that ArcWeb Services and ArcGIS Server will likely be merged at some
point. There are many similarities between the two, including, with the upcoming
9.3 release of ArcGIS Server, the support of JavaScript and REST, and the merge
seems pretty logical to me. It seems that most of what ESRI is releasing (ArcGIS
Explorer, ArcGIS Online, ArcMobile, ArcGIS Web Services, etc.) and spending most
of their money on are technologies that either currently fit into ArcGIS Server
or will likely fit into ArcGIS Server in the near future. Is this bad news for
ArcIMS? Well, ESRI says that they're going to continue to support it, but why
would you want to stick with a product that wasn't being actively developed?
ArcWeb Services 2.0 is currently in beta 1 and can be accessed via the Flex
or JavaScript APIs. Beta 2 is expected to be released at the end of July, and
will include some major feature additions, including support for consumption of
ArcGIS Server services, ArcIMS services, and GeoRSS. In the near future, ArcWeb
Services will also support WFS, WMS, and more formats and the use of
geoprocessing tasks.
Some benefits that I can definitely see to using ArcWeb Services and its
APIs:
- Support for 13 projections, all available client-side.
- Access to loads of data for thematic mapping.
- The ability to upload your own data to ESRI servers and then consume them in
an ArcWeb Services application.
- Support for vector printing - this is a biggie that ArcGIS Server doesn't
seem to get.
To test drive ArcWeb Services yourself, go to the ArcWeb
Services site and sign in with your ESRI global login. You will then be able
to apply for a free 90 day trial which will give you access to the APIs and
underlying data and services. After the 90-day trial, cost is calculated based
on a per transaction model (somewhere around $1250 for 100,000 credits).
Here are some other resources that may be helpful in your evaluation:
Designing, Deploying, and Using Cached Map Services
I sneaked in on the last part of this technical workshop, as when I showed up
initially there was a sign on the door that told me the session was full. Looks
like others are having difficulty building cache too, huh (note that you can see
some of my specific gripes about building tile cache in the ArcGIS Server -
The Road Ahead section above)? We've had to learn most of the lessons the
hard way, so I was hoping that this session would help us avoid further costly
mistakes.
From what I was able to catch, it seemed like a pretty productive session,
with lots of tips and insights coming from the ArcGIS Server team. I couldn't
help but think, though, how much time, energy, and money ESRI could save their
customers by getting these tips out in the form of online help or blog posts.
Seriously, though, if ESRI is committed to helping their customers build and
maintain an enterprise GIS, shouldn't they make their knowledge on how to make
their software work correctly publicly and readily available?
Here are the tips that I caught in the short time that I was in the session:
- ArcGIS Online uses multiple tile servers, all of which have local .mxds that
are accessing local data (stored in file geodatabases).
- Once you build a cache, you can get rid of your original data, as it's no
longer needed or used by a service.
- If using the "generate cache" command, zoom into the extent that you want to
generate cache for, set the max scale, and then start the cache build.
- There is a new blog post with a Python script to help in building cache
coming out on the ArcGIS Server team blog this coming week.
- Enhancements to tile cache generation at 9.3 will not "break" existing
caches, they will, however, allow you to build cache more efficiently.
Extending ArcGIS Explorer Using the ArcGIS Explorer SDK
This session had some pretty good demonstrations on creating custom tasks for
ArcGIS Explorer included, although it was really more valuable as just a deeper
introduction into what ArcGIS Explorer is meant to do and how it works. The
session started out introducing the basics of an .nmf file, which is an xml file
that ArcGIS Explorer uses to store everything. Being
xml, .nmf files can easily be programmatically created and edited, and can
contain everything from layers (including symbology, etc.) to ArcGIS Explorer
tasks. They can basically contain as little or as much information as you want,
and, since they are just xml, editing .nmf files is an easy way for users to
create "custom" ArcGIS Explorer applications without any programming at all.
If you want to further extend an ArcGIS Explorer application, though, you are
going to have to develop custom tasks. Tasks are designed to be very
lightweight. They serve as a client-side interface to gather input from users,
present this information back to them, and interact with other tasks, if needed.
The bulk of a task's processing work gets done on the server.
To help developers design custom tasks, ESRI has released an API that allows
developers to interact with ArcGIS Explorer. Note that the SDK is .NET only.
Here are some tips for those of you who are developing tasks for ArcGIS
Explorer:
- As drawing lots of results takes time, set visible to "False" to begin. This
dramatically improves the overall user experience.
- Currently, the polygon property does not have area. This is because of
difficulties with WGS84 and 3D.
- ArcGIS Explorer returns hidden layers, so make sure that you check for these
when iterating through layers.
- You can override "OnIdle" to bring real time updates of data. There are
currently no events exposed in the API to do this, but it is possible.
- Result::Description does honor HTML tags, which means that you can use CSS,
JavaScript, etc. in the description.
One more development that is coming with the next build of ArcGIS Explorer is
exposure of OpenGL, which should allow for lots of exciting things to
come.
Thursday, June 21st
ArcGIS Mobile - The Road Ahead
I wasn't able to make it to the 2007 ESRI Developer Summit, so I missed quite
a bit of news on the ArcGIS Mobile front. Because of this, I was especially
excited to hear more information about ESRI's plans for the SDK. Most of the
session's time, however, was spent on the new ArcGIS Mobile client (it looks
like they're calling it "ArcGIS Mobile Editor", although don't quote me on
that). I was a little disappointed by this, but it was interesting to see some
of the demo apps that they put together for the new client, as most of the
functionality that was demonstrated is available now with the existing 9.2 SDK.
After the session, I was told that there should not be any major changes to the
SDK (other than additions) from 9.2 to 9.3, so there shouldn't be much work
involved when migrating to 9.3.
As for the SDK, there are some enhancements coming at 9.3:
- Support for more base layers, including large, non-edit vector datasets and
tiled ArcGIS Server map services.
- More street routing and navigation functionality exposed.
- An updated geometry and sketch model, including making it easier to create
features with GPS (this can be done with the 9.2 SDK, but it is difficult).
- Better standalone and related tables integration. It was not clear how they
are going to deal with related data, although I did ask.
- Support for Windows Mobile 6.0 and Linux Mobile Data Web Service.
Like I mentioned, the majority of the session was spent on the upcoming
ArcGIS Mobile Editor. Here are some miscellaneous features that were discussed
and demonstrated:
- Target release date: January 2008, along with the rest of the 9.3 release.
- The client is targeting Windows Mobile devices.
- Disconnected, occasionally connected, and always connected use cases will be
supported.
- Will not support related tables in initial release.
- The team has really focused on usability and the user interface shows this.
It is very simplistic, without any icons at all (it uses text in place of
icons). It was interesting that they mentioned looking to the iPod
for inspiration when building the user interface.
- Allows users to both collect and update features.
- Has full GPS editing capabilities.
- Can synchronize directly with ArcGIS Server with virtually any kind of
connection - including a satellite phone connection, WiFi, CDMA/GSM, and wired
connection - which allows for real-time tracking of either a GPS device (via the
tracklog) or field work completed.
- Feature search functionality and ability to connect to web service to
search, as well.
- Release of a new module for ArcGIS Server Manager which allows for
development and deployment of ArcGIS Mobile services and applications.
- When a mobile service is accessed by ArcGIS Mobile Editor, geodatabase
subtypes and domains are automatically brought with it onto the device.
- Uses local caching for "non-operational" data (data that are not being
edited). These should not be sent over wireless, but, rather, loaded onto the
device.
- Compressed vector layers are supported for static viewing.
- ArcGIS Online will soon have services specifically designed for consumption
by ArcMobile applications, including: StreetMap, satellite imagery, and
topopgraphic data.
- Wireless synchronization can be tweaked to fit specific cases (e.g.
synchronize when a connection is available, synchronize when a WiFi hotspot is
available, or automatic synchronization in real-time).
Managing Distributed Data with Geodatabase Replication
This session, although it covered quite a bit of material that was review for
me, did help quite a bit. At my organization, we had a couple of problems early
on with replication that have now been solved. Overall, from my experience
geodatabase replication seems to work fairly well, and it sounds like there are
quite a few improvements coming in 9.3 that will make it even more solid.
Again, I'm just going to list a few of the highlights from this session, as a
lot of the session was just reviewing the fundamentals of using geodatabase
replication:
- No version is needed on a simple child replica. Having a version will only
decrease performance of the geodatabase and the replica.
- With the current implementation of geodatabase replication, metadata are
copied over when the first replica operation is run. After that, metadata
changes are not reflected in the replica. This may change in future releases,
although the enhancement is not currently slated for the 9.3 release.
- There are tools that allow you to apply most kinds of schema changes across
replicas. Applying schema changes is a two step process:
- Compare replica geodatabases directly in a connected environment.
- Export XML and then import to apply changes to geodatabase that needs the
schema changes.
- Geodatabase replication can be integrated into larger application through
APIs. There are two APIs, one for coarse-grained control (GeoDataServer object
model), the other for more fine-grained control (Pre-ArcGIS 9.2 object model
that works only on geodatabases that live on the Local Area Network).
- Enhancements coming at 9.3:
- Replication will be extended to allow one way replication to file and
personal geodatabases.
- Better support for synchronization of large (greater than 1 GB) delta files.
- Improved logging for easier troubleshooting of issues.
Lastly, at the end of the session it was announced that a whitepaper, titled
"Managing Distributed Data" will be available on the ESRI Support site soon.
Developing Applications with ArcGIS Server Mobile SDK
This was another session that I didn't get a lot out of. Maybe I was just
getting tired? Here are a few random notes:
Overview of building mobile applications for accessing ArcGIS Server
services:
- Build your geodatabase.
- Author a mobile map.
- Publish your map as a mobile service.
- Design mobile application.
- Deploy mobile solution.
- Synchronize mobile solution.
Tips for developing mobile applications for accessing ArcGIS Server services:
- Use MapCache Generator tool on desktop to generate mobile map cache.
- Use Request_Completed event to monitor synchronization requests.
- Use the State and Notifications Broker API and be smart about how connected
you are (Microsoft.WindowsMobile.Status).
Miscellaneous Questions/Answers and Other Tips that I Picked Up
So, as all of you who have been to the UC know, a lot of what you learn comes
outside of the official workshops and technical sessions. The vendor area holds
a plethora of resources in the form of technical expertise - especially for
developers - that are available to help troubleshoot specific issues and field
questions, and you can always learn something when talking to colleagues. Here
are some miscellaneous anecdotes that I discovered during my time here in San
Diego. Where appropriate, I've given credit to the originator of the
information:
ArcGIS Explorer
- Can an .nmf be placed on a file server and not be downloaded/cached
locally when a user opens it from his/her workstation?
- It depends on the browser behavior. ESRI hasn't really looked into this, but
they are going to and will come out with some guidance/recommendations on how to
make various browsers handle .nmf files in this way. If your organization uses
Internet Explorer, this can likely be set by group policy.
- Have any formal tests been done to help gauge the bandwidth cost of using
ArcGIS Explorer on a corporate network?
- No formal tests have been done, but because of the way that ArcGIS Explorer
separates data into layers (which is a good thing, right?), it probably consumes
more bandwidth than Google Earth. ArcGIS Explorer is designed to be a broadband
application and will, therefore, not run with less than 100 kb/s bandwidth. For
a good experience, there should be at least 200 kb/s of available bandwidth per
user.
ArcGIS Server Performance
- Generating Tile Cache
- Just a tidbit of information: to generate tile cache for the globes that are
served through ArcGIS Online, ESRI used three quad CPU servers to build each of
the caches. It took them two weeks to build each cache.
- When generating tile cache for use in ArcGIS Explorer, it is possible (and
recommended) to generate 2D cache and then associate it with a globe. Draping
will happen on the fly, and this allows for cache to be generated much faster
and with much less overall processing.
- Using Multiple DNS Entries to Serve ArcGIS Server Tile Cache
- Lately, I've been working hard on improving performance of some of our web
applications. One tried and true method that web developers live by is
registering multiple DNS entries to serve out resources (CSS, Images,
JavaScript, etc.), as this helps in getting around HTTP 1.1's two connections
per-browser limit. I haven't been able to make this work for our tile cache yet,
so I posed the question to one of ArcGIS Server's developers. His idea was to
specify the names of the servers in the code and then use JavaScript to cycle
through them on each image request. We then went over to discuss it with the
product lead who told me that a blog post will be out in the next couple of
weeks that will detail how to set this up.
ArcGIS Server Security
- At 9.2, it isn't possible to use Windows Integrated pass-through
authentication from an ASP.NET ArcGIS Server application to a database server
to, for example, limit edit access to a service based on an Active Directory
logon. There are ways, however, to work around this and basically get the same
thing. Note that what follows isn't pretty:
- You have to place the service in a directory that has NTFS permissions set
on it and make some modifications to the web.config. If a user that is not
allowed access to the service goes to the web application, they will not see the
service.
- In this way, you can 1) create two different services that access the same
SDE data (one for editing, one for viewing) and 2) restrict access to the
services using NTFS permissions and modifications to the web.config. After doing
this, the user will see only the service that they have access to in the
application.
- However, in addition to this you have to programmatically hide the "Edit"
task that displays in the web application if a user does not have edit access to
any services (and, if you want to make it even more complicated, you have to
create and programmatically hide or display custom edit tasks per Active
Directory group if you have multiple services that are editable by different
groups of users).
Web Map Optimization (thanks Roland!)
- Cartographic representations of data draw faster in web maps than
explicitly-defined symbology representations.
- It is good practice to convert .bmp to .emf before publishing maps. There is
a style set, titled "ESRI Optimized Style File" that is available for use. This
set contains styles that have been designed specifically for display on the web.
- Where possible, it is good practice to simplify your geometries before
serving them through a web map application. For example, the "Simplify Polygon"
command honors topologies while generalizing the geometry of a polygon feature
class.
- When building a map that is going to be served through ArcGIS Server, define
your scales initially and then group data that display at specific scales
(scale-specific rendering) into group layers. ESRI has defined its standard
scales, and loads their "StandardScales.txt" into each of their .mxd projects
before doing anything else.