Grad School- worth it?

Before I started my *real* job, I got a MA (UMD) & did some PhD coursework (UMN), as well as work in various university teaching/research/admin positions. I also was privileged enough to teach undergraduate courses this past year at UMD (programming & cartography), primarily because the full-time faculty were dedicated to the MPS in GIS program. I value the university's role in providing a base of GIS knowledge and skills. Still, the NY Times has a nice discussion on the value of grad school, and I think it's appropriate to view the MS/GIS programs in this light.

My personal thoughts echo the respondents. I'm in the DC/Baltimore area. They're local programs at UMD (~40-50 students/yr), UMBC (a guess at ~40/yr) and Salisbury University (a guess at ~20-30/yr), plus the GIS-oriented graduates of GMU, Towson, Penn State, just to name a few places with a local impact. I feel that the DC market is probably *the* biggest for GIS in the US (thank you, feds + sophisticated locals), but can we really readily absorb the production of bachelor's (conservatively, let's say 200) *and* 80+ MAs specializing in GIS (not to mention the people with GIS skills but not an explicit degree in it). If we can absorb that many MS students, is the payoff differential between a BS + 2-3 yrs experience and a MS anywhere near 7K/yr yet (that just might make the MA cost-efficient over 4 years, if you get funding)? I don't think so- from talking around, I've heard the usual horror stories of students being hired post-MA to do basic technician-level tasks; also, it takes some planning on an organization's part to integrate the combination of advanced skills and shallow experience that a former graduate student probably has.

The above being said, I think that a professional MA (or graduate certificate) has a major role in GIS- there simply isn't enough time or courses in an undergraduate curriculum to provide the breadth or depth of skills necessary to adequately grok certain topics (programming from a non-CS background, for example). Some of these topics are better learned either in a class or class/work setting (programming being very much the latter).

I just don't want potential students to go into debt and find that it takes more than 5 years to recoup a $50,000 MS (in-state full-time and bare-bones living)- it's hard on the beginning side of a degree to fairly estimate the expected payoff.

Wake Up

Okay, it's time to try to reactivate this. I'm presenting @ UC (http://events.esri.com/uc/2009/infoWeb/OnlineAgenda/?fa=ofg_details_form&ScheduleID=227), after all :)

Stuck with a view of the Pacific

Not yet home- I've been bumped twice (Easter, snow in O'Hare), so I'm spending the afternoon in SF- the tragedy of it all :) .

Anyway, my final dev summit opinions

One big benefit of the Dev Summit is that the session have all been recorded with screenshots; by all means, listen to any session you have the slightest interest in- it will be worth your while.

Building a 3-D City

9.3 is supporting 3-D in a big way. An "Import 3-D Model" tool was shown, with both Sketchup & COLLADA types, among others listed. The geometries supported by multi-patch (rings and triangle networks) were described, and enough relevant examples were presented to show when you'd want a ring (flat surface) or one of the two triangle sets (accommodate a continuous surface in 3-D). There's programmatic access to multi-patch, so a quick color/texture scheme can be easily applied.
Aside from that, ESRI is focusing on storing and managing 3-D models- not necessarily bulk creation- that's partner-space (though tools for individual buildings will be deployed, though it may be more sensible to use Sketchup or another 3-D design tool).
The Question & Answer was interesting. Among other things, it confirmed the role of ESRI's business partners in bulk (programmatic) 3-D creation, as well as some idea of what they're thinking about for 9.4- perhaps an architectural style symbol library and other ease of using existing 3-D data. ArcScene & ArcGlobe will continue in the foreseeable future.

Some tips that should have been obvious from the star (i.e., obvious to me but not):

• Use Scale dependencies! The presenters recommended at most 5-6 different layers for use in a 3-D environment, with more complex models (kml, sketchup, multi-patch) being limited to the closest features. Use extrusion for slightly farther away, and footprints for even farther.


• Use multiple footprints for a building to extrude properly. Most skyscrapers (or even mid-rise blocks) have differing elevations. Instead of making one solid building footprint, create a series of rings that complete the footprint and specify elevation information for each ring (separate the footprint component ID from the building ID).

Designing Map Caches

This was a session that I had planned to listen to after the conference, but decided to sit in. Aside from the ArcGIS Server guys, they also had a representative from ArcWeb Services (i.e., the guys who have done the most caches to date).
A lot of good take-away tips on building caches, including what image type to use (JPG for backgrounds, PNG8 for vector overlays) and what datasources to use (use a local GDB for tile creation; we can always repoint the data to an SDE afterwards).
The 9.3 interface for cache creation & maintenance looks pretty good; it'll be a lot more flexible (we're not hit too badly by it- our base background is generated in 8-20 hours, depending on image format).
This session also drove home to me the ESRI philosophy on map services: cache EVERYTHING that doesn't need to be more current than the time in which you can recache it (up to the hour or day can be cached, depending on your hardware). I'll bet this is going to result in a number of setups where a second(ary) server will be brought online to do constant caching, with maybe some excess capacity for hosting additional web serving SOC clients.

Effective Geodatabase Programming

Another session where the slide deck will become a great reference. I don't do too much programming against our database; however, the information at the session was pitched just low enough that I understood the concepts & reasons for their recommendations. I'll at least be able to be conversant with people I work with who do this stuff to convey the issues raised. One of the nice things about the Dev Summit is there was ample time in the schedule to take a session or two in topics that weren't my area of expertise- I honestly like cross-training in other areas.

Closing session

Basically, a good forum for feedback. A lot of hand-voting for what worked and what didn't (the intro sessions seemed to have helped, sit-down vs. boxed lunches was a draw). Some future directions were talked about; at this point, ESRI has nearly backed themselves into a corner to release a functional SDK for the File Geodatabase. Anything less then full access to it (without a ESRI DLL to be deployed in addition) was met with tepid response. Two other takeaways from the Q & A:

• VB6 is moribund (if not dead), get over it


• IMS is moribund (if not dead), get over it

Dev Summit Wednesday Sessions

Architecting ArcGIS Server Solutions for Performance and Scalability

A series of tidbits, a few of which were useful (depended on your experience with serving map services). I wish they would have spent more time on computer/network architecture for hosting web services & apps- for me, the computers are the relatively scarce resource (especially when licensing per computer comes in), so we need to be able to figure out the best use of our computers.

Flex API Preview

Due to demand, this got moved over to a conference room, as opposed to a demo theater. I stayed a little while, but got enough of a gist: it looks to be pretty much a Flex wrapper for the REST API (I'm willing to be corrected if they showed stuff beyond the standard REST capabilities; I was in the session for all of 10 minutes because it was during a sit-down lunch.

This session re-enforced the big takeaway from the conference- Clients are whatever platform you want them to be with ArcGIS Server 9.3. By now, I'm sure there's some interface for ALGOL that can take advantage of the REST API (there better be, since it's http-based). The challenge for a development shop is to identify the 2-4 platforms (depending on the size of the shop) that they'll use to develop and actively keep the others out-of-bounds; otherwise, you can't adequately develop depth of programming to do good apps.

Building .NET Applications Using the ArcGIS Server Web ADF and ASP.NET AJAX

I was really excited to go to this session (I haven;t been to previous incarnations). Picking up from Dave Bouwman's comments, it really felt like REST let the air out of the room on this. The .NET Web ADF still allows pretty good access out of the box to heftier web services, but it's just about obvious that a lot of the energy is going to be over in the Javascript side of the camp. Still, the improvements in 9.3, which uses the Microsoft AJAX framework are pretty significant and much appreciated.

Building and Extending Tasks for ArcGIS Server .NET Web Applications

This session left me feeling more positive about the .Net Platform. I haven't developed any tasks yet, so the walkthroughs provided were extremely helpful. It also showed how the .Net ADF can continue- it provides a nice near-WYSIWIG interface for organizations with no programmers to continue to create & support (with outside code help) web mapping applications. Also, at 9.3, creating a task on a one-off basis becomes a lot easier by creating a web control & loading it as a tool, which will lesson the onus of developing a tool & Visual Studio configuration & web configuration interfaces.

Other

I had a good talk with ESRI Staff on geocoding; since I work for a local government, we're interested in maintaining our own, very particular address locators and had some problems tweaking them. I also got a good amount of time with the ArcPad team- I already love ArcPad as a mobile client (our people can be out in the field with no telecom access easily available), and it's only going to get better with 7.2.

Dev Summit Wednesday Keynote

Apparently a Cooper nowadays designs the UI to programs, not barrels. Alan Cooper's talk was informative, especially to people who are (or want to) manage geeks. Talking points:

• Making money moving atoms vs. making money moving bits- a little bit tired at this point to people who are used to computers; the key to remember with this point is that there are still many people who don't understand the difference.


• Things like finance are now commodities/utilitarian in nature- having it (or having good implementations) don't help; not having hurts. Rejoinder: if that's the case, why do so many public companies still have bad financial practices?


• Software isn't a commodity; it's a craft. My response: It isn't, yet. One of the big things Dev Summit has shown is that the bar for making really good online mapping applications with custom data is going to be lowered, quick. With other projects allowing for easy creation of mini-apps (Yahoo Pipes) and the mapping projects only being a part of software development), the bottom of the programming market is going to drop even faster as every high school sophomore is going to make their own app 'cause they can


• The distinction between interface engineers, design engineers and production engineers is important. Controlling the UI (both software & human side), sketching out the functionality and finally making the code so it doesn't break are three separate tasks; I certainly can't do them equally well.


• Finally: an Eisenhower quote: "In preparing for battle I have always found that plans are useless, but planning is indispensable."

A good keynote speaker, but probably not what every attendee was looking for (aside from reassurance that they're a special class of worker, for now).

Developing Geoprocessing on Server

Or, how to do geoprocessing & make it work.

Despite being good with creating analysis processes, I'm still not completely comfortable with the Model Builder environment- it's not a complete scripting solution, and getting a model to run in a server environment has generally had problems. This session (admittedly partially given before over the web) was pretty much a best practices for developing to server (or developing a model in general) with an eye to what additional functionality is coming along in 9.3 (like layer transparency, to begin with). The slide deck (hopefully up soon) will definitely be a great reference.

Mentioned throughout the presentations today is the fact that pretty much any client, be it ArcMap, ArcExplorer, a Web ADF site, or even a mashup or python (or ruby, php, and pretty much any other language) program will be able to utilize a geoprocessing task- that really puts the onus on getting the task designed correctly in the first place.

REST & Mashups

REST

It was packed, and naturally people more vocal than me have already posted (the first link, James Fee's, is especially good at explaining the technology).

Some notes:

• The structure to access layers is well-defined, but a little human-unreadable (admittedly, it's a programming interface). It'd be nice to address a layer by an alias (and possibly not have to worry about a reordering of the map document breaking everyone's programs)


• One of the things I'm interested in is a possible replacement for the IMS Metadata Service. I haven't taken a look at the metadata delivered, but I'll bet any replacement simply leverages the information published through the REST service.


• The 9.3 release will be read-only, with writing probably(?) in 9.4


• True curves (i.e. arcs) are densified (changed to line segments) when served out. While I wasn't completely clear on it, it sounded like that was standard across the ADF (or I'm being wishful; it currently causes a small failure).

Mashups

Another good session. Dave Bouwman has another good review up. I'd say it's even simpler than what Dave makes it out to be, but then again, I started off programming for money as a webmaster in grad school. I will need to dive into Dojo some more- I haven't done complex sites very recently. Dave's point about simple sites is right- and the biggest message I'm hearing from my clients- we need specialty apps that get the data across clearly.

A lot of the Q & A was taken up trying to nail home the fact that javascript is a client-side language! Once the data is transferred to the user, the server doesn't touch it unless it's uploaded back (which isn't completely out-of-the box).