The Eicher GIS Blog

Assessing the GIS job market for someone just entering the market

Cory Eicher — Sun, 07 Jan 2007 11:13:00 +0000

I received an email before Christmas from someone just entering the GIS job market. He had a few brief questions for me. I thought I'd post my reply here as well.

--------------------------------------

Q - First, coming from an environmentally based school that's all I hear about in terms of GIS jobs, is that the only market for it or are there other uses?

A - Short answer no (but you probably already knew this).

I'll give my long answer by giving you my view of GIS careers:

First, most jobs involve working with commercial GIS software to solve problems. ESRI, Intergraph, MapInfo software, AutoDesk, and even Microsoft are players in then GIS software business. This work may involve making maps, building/editing geographic data etc. Some jobs are less technical (using GIS software, managing people that use GIS software), others are more technical (developing software applications that make GIS software do something special).

Yes there are other jobs out there, e.g. you could work at ESRI on the software development team that builds the commercial software. This is what I used to do, but this is more software development and less GIS.

So, some common GIS career positions -- after all you're looking for a career, not just a job, right.... great interview answer by the way ; )

1) GIS Technician - low end on pay and required education. perform routine technical tasks using GIS software.

2) GIS Analyst - technical, but higher pay and higher required education. most GIS jobs out there fall into this category... but no two analysts do the same thing, have same skills, make same money. quite a wide range out there.

3) GIS Manager - you manage people that do jobs 1, 2, and 4. To get such a position, you probably did job 1, 2, or 4 previously, or you have experience managing people in some other technical field. You make more money simply because you are a manager. You won't enter into this position right out of school most likely.

4) GIS Developer - like 2) but more technical. You develop in C# or VB.NET or Java for example. You have a background or skill in computer software development. You make more money generally because there are fewer of you out there (people that know both GIS and software development). You develop custom or homegrown applications that make GIS do something specific. As an example, a county government uses GIS to manage tax parcels. They have a custom GIS application that does this. Some GIS developers build and maintain this for them.

Application fields

GIS careers are not limited to the envionmental field at all. All of the positions I described above exist in scores of different fields. As a GIS career professional, (hey that has a nice ring to it)!, you or your company/department may specialize in one field, or you may work for a GIS consulting firm that does work in a number of fields.

Some fields off the top of my head:
-Environmental
-Oil and natural gas exploration - Right now, in some cities (e.g. Houston, Denver, Calgary) there are tons and tons of jobs in oil and gas GIS, and, as you know, these companies have money (business goes up and down with oil price) .
-Mineral exploration - another field where there is a lot of money and things go up and down a lot.
-Public utilities including electrical, gas, water - GIS is used to manage systems and sometimes design new parts of systems.
-Demographics/marketing - some overlap with advertising, also tons of GIS jobs working for US Census
-Defense - thousands of jobs in Washington DC and elsewhere working for government and defense contractors.
-Transportation - e.g. state department of transportation
-Emergency 911
-Cadastral (tax and property) mapping
-Advertising
-Facilities management
-IT - information technology. This is a broader field than GIS, but sometimes GIS is integrated with other business systems.
-Engineering - some overlap with CAD in this field, GIS is used to both design new infastructure and manage existing infastructure. Think also what is happening in Iraq.
-Health - epidemiology, pretty interesting field with lots of geographic data.
-Aviation and navigation - charts for planes and boat
-Agriculture and precision farming

Related technologies/careers

Some related technologies/fields where a GIS background may be useful include GPS and navigation systems. These are used on construction sites, in cars, in airplanes, in golf bags on the course to geolocate your position! Also, any skill/experience/education with computer software, hardware, web stuff can certainly be combined with GIS. Lots of GIS is "online" now.

Especially in the environmental and engineering fields, your GIS career may overlap quite a bit with a civil/environmental engineering career.

Where to search for jobs

"GIS" turns up a ton of jobs on Monster.com , and http://www.gjc.org/ is a great site with only GIS jobs. There may be others out there, It's been a few years since I've looked.

Q - And if you have any advice from your experiences as to how I should go about getting into the business, is there something that employers look for as far as skill base or qualifications?

A - I think I covered a lot of this already. I would advise getting real-world experience. Employers value real-world experience. It can be hard to get, but I would try and get your foot in the door wherever you can. Take an internship-type or even trial position if someone gives it to you.

Get technical experience. If you find software programming interesting, get more experience with .NET language (for desktop or web development) or Java (for web development).

Network. Definitely work through your university contacts, professors, fellow students, alums.

Keep up to date. There are some great GIS blogs out there. Read every day and you'll know what's going on.

Do some research on salaries. GIS is a young field. There is such a range of salaries. In general, GIS people still don't get paid equivalent to others in IT. I think that this will change, but like anything you have to prove you deserve it. Some fields (oil, gas) pay more than others (environmental).

If you are interested, think about taking a position that may involve field work, such as collecting data in the summertime via GPS. You may get to live in somewhere like Yellowstone for the summer, running around in the bushes, living in a cabin for 3 months... You won't get paid much of anything, but you'll have great fun and it is good experience for the resume.

Good luck with your job hunt!

Cartographic Data Modeling

Cory Eicher — Sun, 07 Jan 2007 10:55:00 +0000

It's been awhile since my last post.

I have been working on some interesting stuff including building data models for cartographic data at scales 1:300,000 and 1:25,000. This is for a project we are working on with the Federal Office of Topography (swisstopo). For this work I've been using Visio and the ESRI CASE Tools.

We are using ArcGIS 9.2 and taking advantage of the new cartographic representations, so on top of these data models we are also producing representation models for topographic maps (additinoal representation models could conceivably be added on top of the general data models).

It has been interesting to figure out how best to translate swisstopo's object data model and symbol signature into a geodatabase schema, making decisions about feature classes, subtypes, attributes, representations, representation rules, and override fields. A particular challenge has been finding a way to do the representation modeling, since reps (and also annotation) are not supported in the CASE tools. Currently I'm using some C# code to read the "representation schema" from an XML file.

-Cory

New Time Zone

Cory Eicher — Sat, 22 Jul 2006 11:06:00 +0000

Greetings from a new time zone, CET or Central European Time.

I've settled in to my new position with ESRI Switzerland. I'm working with their professional services group in Zurich. Business is good and the company has expanded to two small offices in Zurich.

Many things are different/new of course, but I find that the 'hand of Dangermond' reaches far afield, even to our little office here in Zurich. I actually saw a guy (nobody that I knew) jumping off a train last weekend who was wearing an ESRI t-shirt.

I'm currently working on a pretty exciting ArcGIS Desktop/ArcSDE implementation for the swiss national civilian mapping agency. Don't expect too many ArcObjects postings in the near future : ( (perhaps you will be happy for this?) as we are still in the system analysis phase for the project. But later, we'll be doing a lot of cool stuff with ArcGIS 9.2 including customizing the new cartographic representations functionality.

In the past month I've learned a bit about ESRI's PLTS Data Reviewer which is more or less completely revamped for 9.2. This is a very promising product component for centralizing data quality reviewing. Something interesting to look forward to in the final 9.2 release (or shortly thereafter as the PLTS release cycle typically trails ArcGIS by a little bit).

Talk to you soon,

-Cory

How to scale a dataset

Cory Eicher — Fri, 09 Jun 2006 13:59:00 +0000

Problem

A colleague of mine recently asked me how to scale a dataset. He had the requirement to make an entire line or polygon dataset a factor larger or smaller. e.g. scale the dataset by a factor of 5.

Mathematical Solution

I knew that matrix algebra might help us here. I did some web research and confirmed that you can scale a 2d point by taking a matrix that looks like this (x and y are the scale factors in the x and y dimensions)...

x 0 0
0 y 0
0 0 1

...and multiplying by your point, which looks like this...

x1
y1
1

Here are some good links on matrix algebra:

http://easyweb.easynet.co.uk/~mrmeanie/matrix/matrices.htm (background)

http://www.engineering.usu.edu/cee/faculty/gurro/Classes/Classes_Spring2002/VBGradClass/VBGradClass.htm (includes vb code sample to multiply two matrices)

Coding a Solution

I coded a solution in VBA to do this scaling on a shapefile. My goal was to mimic the 'dataset scaling' function described above, and that I'm also told that Manifold GIS provides. I didn't end up using the vb code mentioned above to multiply two matrices, but I did use matrix algebra indirectly.

A few important observations:

1) I found it necessary to first introduce a false origin at the lower left of the original dataset before performing the scaling. Easy way to do this, determine lower left coordinates and subtract from all point coordinates.

2) Scaling was straightforward. Just multiple all x coords by x scale factor and all y coords by y scale factor. In my case, the x and y scale factors were equal.

3) Now my dataset is larger, but where is it? Well, it's anchored to the lower left of the orginal dataset. The Manifold functionality centers the new dataset on the old. So, based on the x and y extents of the orig and scaled dataset, I calculated the distance that I needed to move my scaled dataset "down and to the left" (to use the a technical term ; ), then I achieved this using simple subraction on my x and y coordinates.

4) Finally, don't forget to "undo" the false origin set in step 1). Do this by adding back in the dataset lower left x and y coordinates that were subtracted in step 1).

There you have it, how to scale a dataset and recenter it on the original dataset.

VBA code is here.

News

I also have some professional news. I've accepted a position to work for ESRI Switzerland in Zurich. I'll be working on projects there mostly related to cartography and ArcGIS. I'm very excited about the position and the move. This means that I'll be getting out of the full-time independent consultant business, but I hope to continue with this blog from my new "position", pun intended.

Talk to you soon,

-Cory

Lessons learned from building an SDE data loader

Cory Eicher — Sat, 27 May 2006 17:30:00 +0000

It's been awhile since my last post. What can I say, I've been busy. Had some time today though, so I dug 'Pet Sounds' out of my cd collection and decided to write a post.

I do actually have some useful content (at least I think so), so another good reason for posting.

Lessons Learned - architecting a system

I recently wrapped up a project where I helped a client build an ArcSDE data loader. The basic goal was to take as input some 'feature data' (geometry and attributes). This data is stored in a database in a non-ESRI format. There was already code in place to take the data out of the database and put it into a proprietary dataset format. My code was to read data from this dataset, translate the geometry into ArcGIS geometry, handle coordinate reprojection and datum transformations, and load the data into ArcSDE feature classes.

At a high level, the solution I architected for this was: an SDE loader object to do the actual data loading, a coordine transformer object to handle projection/datum transformations, and a geometry converter object.

Conclusions:

The coordinate transformer object involved the most work. Part of the job of this object was to interpret coordinate information for the incoming data (call this the 'from coordinate system'). This was defined in a non-ESRI format. I needed it in an ESRI format to use ArcObjects to reproject coordinates from the 'from coord. system' to the 'to coord system desired for the output SDE feature classes. This was a lot of work.
The SDE loading logic wasn't to difficult. The trickiest thing here was to decide on the 'optimum' method to do things like: load data efficiently to a feature class, and delete data efficiently from a feature class. AO provides multiple ways to do things. See my previous post for more discussion about this part of the architecture.
The geometry translator object's job was simply to translate geometry from the non-esri format to the ESRI format. This was many many times more straightforward than the handling coordinate transformation. This makes sense I suppose. Even accounting for multipart geometries, polygons with holes, etc., the domain of what you need to handle for 2d geometry is just so much smaller than all of the potential projected coordinate systems, non-projected coordinate systems (aka geographic coordinate systems), and all of 'junk' beneath the gcs level. Also, anyone that's dug into coordinate system 'stuff' in AO knows that there are many ways to skin a cat there, and also to skin yourself! In the end, things in that part of the AO system are very logically put together, but still, as I said, because of the topic, that still makes things, well, 'non trivial' as a univ. professor of mine used to like to say.

Lessons Learned - exception handling

I understand exception/error handling, and I've employed various strategies over the years to employ it in my code... but, I had always been a bit frustrated/confused about how best to go about it. Should every sub handle errors? What should it do with an error? Message box? Bubble the error up to the calling sub? Some of you might be laughing a bit about this, but I think that people coming from the 'GIS programmer' mold might find this interesting and useful.

In the above project I was introduced to an exception handling design pattern that I really liked. It's logical, consistent, and does exactly what I want it to do. I was working in C#, but it could work just as easily in other languages.

There are two parts to this: 1) how a sub handles exceptions, and 2) how you call that sub.

It's pretty simple, and I ended up following this pattern with all of my methods.

First, how a sub handles exceptions:

bool mySub (out string statusMessage, out ILayer myOutLayer, int InParam1, string InParam2)
{

bool bStatus = true; // return
statusMessage = ""; // out
myOutLayer = null; // out

try
{
// do stuff
// set out param
}
catch (Exception E)
{
statusMessage = E.ToString();
bStatus = false;
}
finally
{
// clean up
}
return bStatus;
}

Second, how to call a method

if (! mySub(out statusMessage, out myOutLayer, 1, "brian wilson"))
throw new ApplicationException(statusMessage)

So, by following this pattern, every sub returns true if it runs succesfully, or fail if not. If it fails, the statusMessage tells us what the error is. We throw a new exception, which is caught by the current sub's exception handler, and the process continues. The end result is that the calling sub always gets a useful error message, and call stack if there's an error.

The statusMessage can also be used to return information about successes. For me, only my 'top level' subs returned non-empty successful string statusMessages. If you want to 'bubble up' successful statusMessages from lower level subs, you'll probably want to modify the above pattern, e.g. not automatically initializing statusMessage to "" at the beginning of every sub.

Talk to you soon,

-Cory

Tips for Importing Data into the Geodatabase

Cory Eicher — Tue, 18 Apr 2006 13:38:00 +0000

I spent some time recently writing some C# ArcObjects code to convert geographic data from a another system into the geodatabase. It's been an interesting project because I've had to handle the translation of a different geometry structure into ArcObjects geometry. Okay, it's still points/lines/polys, so it's not that different, but you know what I mean. I've also gotten 'way deep' into coordinate systems as part of this process, and learned a bit about best practices when loading/deleting geodatabase features.

Geometry

Ok, so I started with points and I still have lines and polys on my todo list. What this means is that I' m the type of person that likes to build from small successes...

Coordinate Systems

I was pretty familiar with how ArcObjects treats projections and coordinate systems. Every feature class has, or should have, a SpatialReference, which is in turn comprised of (at least this is how I think about it), a coordinate system with an XYZ domain. The coordinate system may be a ProjectedCoordinateSystem (e.g. Albers Equal Area, State Plane, UTM), or it may be a GeographicCoordinateSystem (e.g. WGS 84, or NAD 27).

Also, if a SpatialReference is a ProjectedCoordinateSystem, then the PCS has a GeographicCoordinateSystem (acces thru IProjectedCoordinateSystem::GeographicCoordinateSystem).

You can build up coordinate systems from scratch, but this can be, quite frankly, a pain in the azimuth (sorry).

It's much easier if you know the name of the PCS or GCS that you want to create, to use ISpatialReferenceFactory::CreateProjectedCoordinateSystem or ISpatialReferenceFactory::CreateGeographicCoordinateSystem. These methods take a long parameter that represents the factory code for the coordinate system. You can look up factory codes based on coordinate system names in the ArcObjects documentation.

For a GCS see the enums esriSRGeoCSType, esriSRGeoCS2Type, and esriSRGeoCS3Type
For a PCS see the enums esriSRProjCSType, esriSRProjCS2Type, and esriSRProjCS3Type

MOST convenient for me however, because I was being handed a factory code that could be either a GCS or a PCS, was to use ISpatialReferenceFactory2::CreateSpatialReference. This method lets creates either a GCS or a PCS depending on what factory code you give it.

You can read more about coordinate systems in the ArcObjects Geometry Library Overview.

Deleting Geodatabase Features

I needed to implement some functionality to delete features from an SDE geodatabase feature class. I looked through the online doc, and found, well, man ways to do this. But, I wanted to know the best way to do this, so I asked my colleague MC. at ESRI.

The conversation went something like this.

Cory - "Hey, can I delete features from a non-versioned feature class, or do I need to version it?"

MC - "You don't need to version your data"

C - "Coolness" (or something like that) "I'm doing my delete in the context of a workspace edit session, like this:

workspaceEdit = (IWorkspaceEdit) mySdeWs;
workspaceEdit.StartEditing (false);
workspaceEdit.StartEditOperation();

// do my delete

workspaceEdit.StopEditOperation();
workspaceEdit.StopEditing(true);

Do I need the workspace edit stuff? If so, why?"

MC - "I always put in the edit session code. That way, if the data does become versioned, my code will still work."

C - "Ok, thanks. Now, there appear to be seventy nine ways to delete a feature.

IFeature.Delete
IFeatureCursor.DeleteFeature
ITable.DeleteSearchedRows
IRowEdit.DeleteSet
...

Which should I use, given that: my features are simple, don't
participate in relationships, and they're not versioned. Also, I don't
need any 'rollback', and I may be deleting a lot of features?"

MC - "I would recommend using ITable.DeleteSearchedRows since this is the "simplest" call and should do the fastest thing. My second choice would be IFeatureCursor.DeleteFeature called on an update cursor because if you use buffering it can batch up features to delete to minimize database queries. IFeature.Delete is generally the slowest since it happens for each feature."

UPDATE: - After trying to implement MC's suggestion to use buffering in combination with IFeatureCursor.DeleteFeature, I had to ask him a follow up question: How exactly do you do this? I couldn't see a way to do this through the API. Well, it turns out that this is done behind the scenes for you. When you use IFeatureCursor.DeleteFeature, the cursor is flushed every 100 features or so...
-Cory (5/26/06)
C - "Great, thanks."

Talk to you soon,

-Cory

Comparing the Cartography of Google Maps and Ask.com Maps Part 2

Cory Eicher — Fri, 31 Mar 2006 13:10:00 +0000

It's been awhile since I've posted. What can I say, after the ESRI dev summit I took a bit of a vacation, managing to squeeze in 3 days of surfing while in Southern California. If anyone's wondering, yes the water was cold... Last week I was busy with work, so here I am, what, two weeks since my last post?

Today I'll return to my comparison of Google Maps and Ask.com maps.

Ramp-age
Some of you are probably already guessing that I'm about to 'go-off' on cased line road symbology. More specifically, I'll examine the traditionally tricky challenge of symbolizing freeways and freeway ramps at multi-level interchanges.

Look at these screen captures of the interchange of I-25 and US-6 in Denver. Google Maps flat out does a better job with the representation of this intersection than Ask.com Maps.

1. Accurate Levels

Looking at the satellite imagery for the interersection, the Google map very accurately depicts how the ramps and main routes intersect, or don't. Google is accurate right down to whether or not a ramp/route passes over or under another ramp/route. Seriously, compare the sat with the map, they've done a really good job! The Ask map, well, if you were to believe their representation of the interchange, you'd have cars, lunch trucks, and vespa scooters crashing into each other at each intersection. There's no "level" at all in the Ask maps.

2. Smooth Connections

Another win for Google. The I-25/US-6 interchange is a good example of how you also need to know how to 'blend' symbology when different types of roads intersect, and these roads have different cased symbology. In this case, we have ramps thin, light-colored ramps, intersecting with thicker, darker-colored routes. The Google map does a quite fantastic job, breaks between colors are always a clean edge of a route/ramp, and routes always take preference over ramps. We don't see any 'round ends' of one color poking into another color. The Ask map is quite messy in comparison. Look at this screen capture of the I-25 Zuni St. on/off ramps from Ask for an example of these 'round ends'. Granted, a lot of the messiness in the Ask map derives from their mis-management of levels. Fix this problem, and Ask could be on par with Google for how this aspect of their cartography.

As an aside, one gripe that some cartographers might have with both maps is how dead-end roads are symbolized. Both maps use round end caps, whereas squared-off caps may be preferred. Here's an example from Google.

3. Directional Arrows

One thing that Google has that Ask doesn't are the tiny blue arrows indicating the direction of ramps and route lanes (you'll also see this for one-way streets). To me this is a clear representation, and also 'clearly' useful for following Google's directions, or making your own way on a detailed view of a Google map.

Talk to you soon,

-Cory

P.S - What I'm listening to: www.kexp.org (not to steal someone else's byline)

Quick Hits From the ESRI Dev Summit Day 2

Cory Eicher — Sun, 19 Mar 2006 16:04:00 +0000

My NCAA tournament picks score has fallen into the D-range on Yahoo, 66th percentile, but I'm not sure that score is current, and things look promising for my score to rise in the later rounds.

The inaugural ESRI Dev Summit is over and done. I was able to interface with a lot of people and I learned a lot about ESRI technology, so it was a successful trip for me. The conference was was very well organized and, I'd say, things went surprisingly smooth considering that this was the first time around. Yes, some rooms were overflowing, but for the most part, the most popular sessions were given in the largest rooms, so there wasn't much more ESRI could have done on the planning end to alleviate this.

Some thoughts from yesterday, day two:

AM Plenary

Two different speaking styles were exhibited by the two guest keynote speakers from IBM and Microsoft. I have to say, I quickly tuned out from the IBM talk. I wasn't drawn into the speaker's speaking style, and the content to me was very high-level, business-y, and treated GIS/location based services as an add-on to a pre-canned presentation. Understandable, but not very compelling to me.
The Microsoft representative was a far more polished professional speaker and a true MS evangelist. I was very drawn in and much of the content for me was new, so I stayed tuned in. I have the same criticism of this talk though, GIS wasn't well integrated in the message. There always seems to be a very simple view of what GIS is when talked about in broader contexts.
I talked to someone that expected presentations of real world case collaborations between ESRI-IBM and ESRI-MS... Perhaps that was shown in the more focused afternoon technical sessions. I didn't attend these.

.NET Web Applications Tech Session

Truly standing room only in this one. You had to get to all the .NET sessions early or you were stuck standing or sitting on the floor.
One thing I always see a lot in web demos of ESRI technology... bad maps. Okay, I'm a cartographer, but in this session I saw fusing of multiple services on same map... Map was unprojected/geographic, and in Canada, rivers were shown, but the other layers were missing. When I was at ESRI we were careful to create attractive maps for demos (okay, were were demoing carto fucntionality) , but we were also careful to be inclusive of non-US audiences. I'm wondering how many cartographers or even geographers work on the web dev team at ESRI.
I have to be honest, I've heard about AJAX, but I never knew what it stood for: Asynchronous JavaScript And XML.
I was pretty impressed but the 'Site Builder' tools that ESRI is providing at 9.2. For someone like me that's new to web development, I'll be starting with these tools.
The 'Site Builder' and .NET web ADF seem very unifying at least w.r.t. ESRI services. Its simple to create sites based on all the ArcGIS services (AGS, IMS) and there's also support for OGC style services.... I did however hear a conversation at lunch, two gentlemen relatively new to ESRI technology, wonderiing what the difference is between AGS and IMS... So _that_ question is still around...
API yai yai.... I saw so many new APIs yesterday and the day before. I guess it's just the price of doing business as they say, but there's a Mobile ADF API, an ArcGIS Explorer API, and a .NET ADF API. I'd say that its a true challenge to develop and app that deploys in more than one of these environments.
Even within web development, there are multiple APIS that developers can work with. ESRI introduced a new general API that can be used, for example, to fuse multiple services and provide feature selection functionality across all services and then to draw the selection in a graphics layer above all of the fused service. It seemed like an interesting thing to demo, but it's also clear that selection/selection drawing is already implemented on the individual service types through their API (e.g. AGS).

ArcGIS Explorer Lunch Session

I'm not sure what this even was, because it wasn't on the conference schedule. I have to thank Richard Howell for telling me about it at lunch. A lot of other people didn't hear about it either because there were only 30-40 people filling the seats of a room that I think would've been out-the-door with people were this a first order session.
Learned that explorer will support 2D maps in addition to 3D globes.
You can customize explorer. Having worked a lot with Google Earth I was glad to hear this. It supports skins, some GUI/application components are configurable on startup, and you can also customize the app and provide custom tools by writing custom tasks.
Explorer supports adding local data: raster, KML, shp, file geodatbase. It doesn't support personal GDB or SDE.
With Explorer you get standard imagery for free from ESRI, same concept as Google Earth. We were told in the session that the free stuff would be 2-3m resolution for the USA. I'm not sure how that matches up to Google.
Explorer has a local cache that allows you to work offline, similar to GE.
I was curious about support for billboarding of text and other symbols for 3d symbology... I didn't ask, but I think this is supported in Explorer by consuming an ArcGlobe service that was authored with this symbology.
ESRI provides a bunch of default tasks including reverse geocode (click on map/globe and get address) and routing. That's pretty cool...
You can save Explorer 'maps' as NMF files with are basically XML.
Euan demo'd the basics of writing a custom task, but he didn't get into very much detail at all. As I understand it, developers just write some .NET components: a Task and a TaskUI. There's also a TaskContext (?) object that allows them to talk to each other. There's nothing fancy here, your objects consume the explorer API (yet another API to learn!), you tell explorer where you .dll is through some other file, and then you put the dll at that URL...
...explorer takes care of deployment of your task, downloading the dll from the server location to the client machine and registering it wih the .NET interop. What I took from all this is, that as a desktop/engine developer writing these custom tasks isn't going to be a big jump for me into having to know all sorts of stuff about web application development... we'll see.
I'm excited about the possibility of writing custom tasks not just to provide 'tool/command' like fucntionality, but to customize the explorer application (layer ordering/on-off, TOC simplification, etc.). This is hard to do in Google Earth.

Common Operating Picture Tech Session

Skipped out of the .NET track to see a session on pretty cool data integration application bringing in real-time from multiple location sources and viewing it. The app was an ESRI employee tracker, and it searched for last known locationn of employee based on flight info in the esri travel database, badge id swipe on esri campus, even vpn authentication activity linked to IP address. Cool stuff, but technical details from the ESRI Impl. Services presenter went way over my head.
Learned about a new ArcToolbox tool coming in 9.2 called 'Generate Map Server Cache'... Tool creates tiled raster maps from an .mxd, you choose tiling resolution and number of scale ranges. These get served up by ArcGIS Server. Pretty powerful, but I wondered about dynamic labeling, specifically duplicate labels and 'edge' effects. I talked with Brian about this and he wondered the same thing. I guess that there'll always be this challenge.

Cartograpy Objects Technical Session

Mike and Craig (former colleagues of mine) presented a really informative overview of the cartographic subsystems in ArcGIS. As Craig said, there's a lot in this area because cartography in ArcObjects-speak is inclusive of everything from layers, rendering, symbols, elements, maps, and pages, to displays and display transformations, to export and printing.
Michael pointed out that it helps to know about about Windows GDI if you're going to get deep into displays and drawing with ArcObjects.
I was happy to see the Multivariate Renderer sample that I wrote is still a useful learning tool for ArcObjects developers. I'd still like to see something like this be core ArcGIS functionality. Something to look forward to on the horizon I guess.

Talk to you soon,

-Cory

Quick Hits from the ESRI Dev Summit

Cory Eicher — Sat, 18 Mar 2006 14:40:00 +0000

It's early on day two of the ESRI Dev Summit in Palm Springs. First off, are your NCAA brackets looking? I'm sitting right at the 80th percentile in Yahoo, a solid B-...

A few quick notes from yesterday:

AM Keynote

Not an overwhelming success, but not a dud either. The start was a bit awkward, as if because it's the first year for this, ESRI themselves didn't know how to kick things off. I'm glad that they basically jumped right in.
Scott Morehouse talked about how ArcGIS is architected. He focused a lot on frameworks. I focused on the fact that as a former ESRI employee I used to get paid to hear Scott talk, but now as a conference attendee, I'm the one paying.
About a 1/2 hour into the session, I took a look around the room and thought to myself that there were a lot of people there. I don't know, 600-700 people perhaps?
ESRI announced that 9.2 will support a type of non-versioned, short transaction geodatabase editing model. This to meet the needs of a lot of users that can't embrace long transactions and versioning for a variety of reasons.
ESRI is the geodatabase. Really, this is the first fucntional area that Scott dove into detail on yesterday, and I've also noticed that it's the one area of the software that has something substantially new each release of ArcGIS.
About 1 hour into the session I took a look around the room and thought to myself that there were a lot of us males in the audience.
I noticed some new faces on the stage, and some new roles. Clint Brown talked about the geodatabase, and ESRI are now calling their product specialists 'product engineers'.
ESRI was definitely pushing geoprocessing. It was used as example of how to reuse components from different types of ArcGIS deployments (desktop, engine, server).
ESRI demo'd a lot of what's coming in 9.2. I noticed that the audience wasn't really applauding at all after the demos, up until when Ishmael demo'd ArcGIS Explorer. I think ESRI saved the best for last with this. I thought that his demos were pretty interesting, and with the crowd applauding, I think that they agreed with me.
I came away from the session wondering how many people 'get' all of the various deployment possibilities with ArcGIS. I know that I'm a little bit dizzied by all the options. I was also excited to see the PM session where they'd be demoing the new Flash stuff.

Technical Sessions

I attended Al LaFramboise's session on developing components that work in different ArcGIS products (desktop/engine/server). Things started kind of slowly for my taste, but as he got rolling, I think he did a really good job showing by example how you might develop components once and reused them across different types of ArcGIS deployments. As he said, even if you're only developing for desktop now, your app may move to the web at some point in the future, so you might want to accomodate for this in your architecture now.
At the lunchtime .NET SIG meeting, ESRI showed off their .NET IDE integration tools. These are built for VS 2005 and will be released at the same time as ArcGIS 9.2 (at least this is how I understand it). The tools looked pretty powerful. I'm running the express version of VS 2005 currently, and I might think about upgrading just to be able to run the ESRI integration tools... There was at least one comment from the back of the room wondering why ESRI can't officially support VS 2005 now, instead of waiting for ArcGIS 9.2 to do this...
Next, I saw Andrea and Mansour talked about ArcWeb Services. I came in not knowing much about this product, and really I was there to see the Flash/SVG support that ESRI is adding. I came away really interested the AWS product actually. It offers an easy way to build applications that use data and services (like routing, spatial selection, location) hosted by ESRI. Clients pay for it based on the number of hits they take. Mansour demo'd the new Flash (support?). I definitely gave him a A for enthusiasm and he was able to show some really cool stuff. I saw online Flash map apps writing using Java Script hitting AWS. he was even able to mash in content from other online sources. ......Very cool. I don't know that much about this technology, but I do know that Flash can be used to create maps and interactive web apps with very 'clean' looks. I find it compelling to be able to more easily create flash content out of a GIS database.
Lastly, I saw Mike Shaw, Fred Aubry, and Milosz give a really informative and entertaining presentatioon of the new .NET Mobile ADF. This is part of the ArcGIS Server product (thus also available to developers with an EDN subscription). Basically, they built a library that helps you build apps that work on smart clients like tablet pcs, pdas, and mobile phones that are only intermittently connected to a network. I got a lot out of this talk, and later in the evening I talked to E-911 application developer that was really interested in using this as part of his new product.

So, on to Day 2. Don't worry, I'll get back to my carto critique of Google and Ask.Com maps after the dev summit buzz settles a bit.

Talk to you soon,

-Cory

Comparing the Cartography of Google Maps and Ask.com Maps

Cory Eicher — Mon, 13 Mar 2006 04:11:00 +0000

Dude, Where's my Freeway?

Go ahead, fire up Google Maps and type in Denver, CO.

Something that jumps right out is that you can't quickly find Interstate 25, the major north-south highway/freeway/expressway in Denver. You see this obviously major route, snaking along the S. Plate, curling around downtown... but it's labeled as US Route 87. It takes some inside knowledge to infer that this is I-25. This is a pretty bad cartographic blunder in my opinion.

So, what's the cause of this problem? Well, the data come from NAVTEQ and many road
segments have multiple names. In this case, some roads are both I-25 and US 87. My opinion is that it's the job of the cartographer or the person that builds the mapping app to label this road as I-25. I'm not saying its easy to do this, but it should be this way.

Ask.com doesn't make this particular mistake. They label the interstate as both I-25 and US 87. In my opinion, this is more correct.

Interesting side note:

I've also thought there was something 'kinda cool' about how freeways in some cities have names. You'll hear these names on local traffic reports, and you may even see green sign along the start of a freeway stretch. But, you usually don't see these names on maps. Perhaps I find this interesting because there's more history in a freeway name than a number. Some examples: 'The Santa Monica Freeway' and 'The Pomona Freeway' in Los Angeles, and the 'Keeler St. Expressway' in Rochester, NY. I also think that named freeways are a weapon for locals to keep newcomers at bay.

Enough Already

Something you notice when looking at the Google and Ask.com maps of Denver is a lot of unecessary label repetition. What I mean is that the I-70 highway shield might appear 3, 4, or 5 times in a given map view. US 6 is another example.

The cause of this... data. Both online map apps use NAVTEQ data, and for smaller scale maps (maps covering larger geographic areas) routes are comprised of many short line features. It looks to me like the NAVTEQ data are just getting thrown straight into some automated labeling software...

...in my opinion, too many are being labeled. What should be done is to label the minimum number of times necessary to make it clear which road is which. So, basically, for these main routes, labeling once between major intersections is what you shoot for.

This is another tough thing (really tough) to nail in an automated system. Sometimes you can help yourself by pre-processing your data, dissolving roads by route number for example, before sending data to your automated labeling processes.

So, we've learned today that high quality labeling can be very difficult in an automated mapping system.

In my next post, I'll continue this cartographic critique of Google Maps and Ask.com Maps...

Talk to you soon,

-Cory

Oprah does GIS?

Cory Eicher — Thu, 02 Mar 2006 22:25:00 +0000

Spacing Out
I came across an interesting ESRI support document today: HowTo: Salvage a corrupt shapefile. The title cracks me up. It sounds like something you might see on an Oprah episode... Today's show: salvaging a corrupt shapefile, taming you unruly teenager, er, bloated personal geodatabase, and getting the most out of your relationship...classes...

I'm one that appreciates a bit of irony, and even this technical support document delivers. The document gives you about 15 things to try to fix a dusted shapefile, but it contains this disclaimer: "If the steps in this document do not salvage the shapefile, revert to the back up". Well, if nothing else, this document has inspired me to backup my laptop.

I was actually searching for an answer to this question: "Can a shapefile name contain spaces?". My research is inconclusive. Lots of people/places say that it should not, but ArcCatalog certainly lets you create a shapefile with a space in the name. Seems to me that it'd be bad practice.

Off on a Tangent
Something else, unrelated, that I came across recently. .NET has two Arctan functions. From the Microsoft doc:

Atan - Returns the angle whose tangent is the specified number.
Atan2 - Returns the angle whose tangent is the quotient of two specified numbers.

An interesting difference between the two, is that the return val for Atan is θ in radians where -π/2 ≤ θ ≤π/2 (-90 to +90 degrees). If you're working (like I was) with angles that represent directions in 360 degrees, and you use Atan, you'll probably need to do some extra work with the return val to get what you want... Whereas, with Atan2 the return val is θ in radians where -π ≤ θ ≤ π (-180 to 180 degrees). As far as I see it, this covers you for a full circle. Pass in your cartestian y and x (+ or - values possible) and with Atan2 you'll get the math angle you're looking for, at least I did...

Talk to you soon,

-Cory

Cartography in GIS: It's not just assigning symbols to geometry

Cory Eicher — Mon, 27 Feb 2006 03:05:00 +0000

I saw that James just posted about Cartography and ArcMap ... actually, before I even saw it, a few colleagues emailed me to tell me that they saw it. Helpful people that they are, they knew that I'm looking for ideas for my blog. So, for this entry, I'll piggy-back a bit on James' post.

Color Brewer
First, a great online resource for cartography that everyone should know about is Color Brewer (www.colorbrewer.org). This site was created by Dr. Cindy Brewer and Dr. Mark Harrower both cartographers, and this is the place to go online if you're not sure about what colors to use on your maps... and believe me, you're not sure about what colors to use on your maps! The site can basically be used as a "map colorer", telling you which colors/schemes to use for different types of maps and data.

Evolution of cartographic facilities in GIS Software
Yes, there's some exciting new functionality coming in 9.2 for cartography. Admittedly I'm a bit biased since I knew this stuff from inside ESRI, but perhaps I'll do some more convincing for your here.

9.2 cartographic representations allow you to edit feature symbology on a feature by feature basis. Pretty powerful as you can imagine for cartographers, but also as ESRI's Paul Hardy likes to say, for people that "just want a better map". Oh, and please don't forget the database! Symbology edits are stored in the geodatabase together with the feature data. Have you been waiting for ESRI to store .lyr/.mxd information in a database? Well, this is the first step...

Is 9.2 the beginning of better cartography from a GIS software package...? Of course not. Sticking with ESRI products, I'd say that a lot started with the ArcView 1x/2x/3x packages. In my opinion, GUI-based software can, and I emphasize _can_, produce better maps. Sure, people got by with ArcPlot, but GUI-based software a) makes "trial and error" easier (although I wouldn't recommend trial and error printing to large format printers when you're footing the paper/ink bill...), and b) GUI-sofware tends to be more WYSIWYG than say, creating maps from a command line app. 9.2 cartographic representations (call 'em reps for short) extend WYSIWYG capabilities in ArcMap by providing the ability to edit symbology.

9.2 cartographic representations aren't just editable symbology, they also employ better "automated routines"... (think better symbols). With reps, your maps can have better dashed lines, you'll have more control over the placement of symbols along lines, etc... Cartographers will eat this up, probably starting at the "top". What I mean by this is, organizations that have really strict cartographic requirements will be the first set of users attracted to this functionality. But, the usefullness of reps will have their use trickle down to many, many users...

A New Editing Paradigm?
Ah yes, paradigm, the word that I, the engineer, heard but wasn't quite sure how to spell during the first weeks of my graduate education in geography. 9.2 also provides new representation editings tools. Simplifying things greatly, these tools are "illustrator-like" allowing you do do things that just aren't very easy using the standard arcmap edit tools... such as modifying multiple features at once. Cartographers need to do this all the time (think offsetting several road line segments from a creek or river) and they don't want to think about topology when they do it, at least not in the sense that this is necessary in the pre 9.2 ArcMap editing experience.

Depending on how 9.2 reps are received by the public, in my opinion, their usability could spell big changes for the data-editing experience in ArcGIS... There are rumors of a huge change to the look/feel/architecture of arcgis at the next major release (10.0?). A big change to editing could be part of this.

Understanding Cartographic Representations
Are cartographic representations hard to understand? My answer is, yes, er.. possibly. James' UC blog post suggested that reps might be hard to "get", and I know that even big ESRI customers that use ArcGIS for cartography want more detailed information about how they can best use this new technology.

The Devil is in the Data
Like a lot of other things, when you need to do a lot of something with GIS, and do it often (such as produce a lot of maps, and produce frequent updates to these maps), it helps: a) to have your data in a database -- hopefully the ESRI geodatabase ; ), b) to have well modeled data, and c) to have well defined processes for creating and updating your data.

My experience with dealing with organizations that produce a lot of maps from GIS is that, well, most of their work isn't in the cartography, it's in dealing with the data... I'd postulate that this is pretty universal, whether you're producing maps, or performing watershed analyses, it helps to have a), b), and c) in pretty good order.

Design is Important
Design will always be important in cartography. It's no secret that most cartographers would like to see better maps than what we're currently seeing. Some of us (not me certainly) are like film critics: we'll tell you what we like and what we don't like, but we probably won't be able to (or won't want to?) tell you how to get there from the start.

The evolution of tools for cartography in ArcMap offers the promise for "better maps", but everybody knows that the ArcGIS 9.x Geoprocessing tools/environment didn't immediately start producing better glaciation models or better site selection analyses... I'd say that the same goes for new 9.2 cartography tools. There's potential for better maps, but resources (online, as James mentioned) and I'd add software documention and even software defaults, are needed to help end users benefit the most from new functionality...

... after all, anyone that's worked with the ArcView 3x technology has problably seen the, well, hideous jagged lines that appear by default in ArcView legends. Not to pick on anyone, but here's an example. The problem is that that this "toppled Z" symbol is the default legend pattern in the software, and not than many people change software defaults. One consequence of this is that you can still peg an ArcView 3x map simply by the appearance of lines in the legend.

Talk to you soon,

-Cory

1 if ByRef, 2 if ByVal...

Cory Eicher — Wed, 22 Feb 2006 16:28:00 +0000

ArcGIS Explorer

ESRI has posted an FAQ here: ArcGIS Explorer FAQ
If you have ArcGIS 9.2 beta (I don't), then you have ArcGIS Explorer. If not, you need to wait for the public beta (March?).
Are you registered to attend the upcoming AAG meeting in Chicago? If you are, be sure to see ESRI's David Maguire talk about ArcGIS Explorer (Thurs March 9th): David Maguire AAG Presentation Abstract
If you aren't registered for the conference, but you're in the area, you could always attire yourself as a starving graduate student, pop in around 2:45, and sit near the back of the room to hear what David has to say.

Copy/Paste Code Reuse

Ah yes, who hasn't copy pasted code to get a head start. Really there's no problem with this normally, but here's something that happened to me last week, pasting some of my own code no less..

I wrote a few subroutines in ArcMap VBA just to get going. After a bit I brought this code over to VB.NET.

I had a problem bringing one of my subs over, and I didn't figure out what was wrong for a long while. Can you guess what I did?

Well, the top of my sub looked something like this:

Private Sub CalcLineStartEndID(InLayer As IGeoFeatureLayer, _

ByVal LineID As String, _

StartID As Integer, _

EndID As Integer)
And then, towards the end of my sub I did something like this:

StartID = iMinSta

EndID = iMaxSta

So, StartID and EndID are ByRef parameters that I calculate during the sub. Okay, an OO purest would slap me on the wrist, but this is what I felt like doing that day..

Anyway...the problem is, (when you paste this blindly into VB.NET before having your morning cup of coffee or green tea), you get this:

Private CalcLineStartEndID(ByVal InLayer As IGeoFeatureLayer, _

ByVal LineID As String, _

ByVal StartID As Integer, _

ByVal EndID As Integer)

That's right, by default, in VB.NET params are ByVal...so, StartID and EndID become ByVal params, but everything 'pastes in' fine, compiles fine, etc... Just, when you run/test your code, well, things don't work quite the same... Lesson learned.

Talk to you soon,

-Cory

How to write a layer context menu command in C#

Cory Eicher — Tue, 14 Feb 2006 23:14:00 +0000

Another technical post today, but I promise that my next post will be lighter-fare...

So, yesterday I was researching how to do something with ArcObjects, and since I'm forcing myself to eat the healthy cereal that is C#, as opposed the sugary VB.NET that I'm used to, I did everything in C#.

I was trying to figure out how to add a custom command to a standard ArcMap layer context menu (doing all of this with code of course). In other words, I wanted my command to appear when a user right clicks on a layer in the ArcMap table of contents..

This is easy to do from VBA. If you've already compiled/registered your custom C# command, you can just write a little sub like this:

Sub AddCommandToLayerContextMenus()

' custom command
Dim pCommandUID As New UID
pCommandUID.Value = "MyNamespace.MyCustomCommand"
' or use GUID
'pCommandUID.Value = "{F9B2E774-29A0-4eaa-B8E2-D26DA1F21CB2}"

' add to feature layer context menu
Dim pCmdBar As ICommandBar
Set pCmdBar = ThisDocument.CommandBars.Find _
(arcid.FeatureLayerContext_Menu)
pCmdBar.Add pCommandUID

' add to group layer context menu
Set pCmdBar = ThisDocument.CommandBars.Find _
(arcid.GroupLayer_ContextMenu)
pCmdBar.Add pCommandUID

' add to raster layer context menu
Set pCmdBar = ThisDocument.CommandBars.Find _
(arcid.RasterLayer_ContextMenu)
pCmdBar.Add pCommandUID

End Sub

But, I wanted to manage all of this from my C# code. So, I wrote a custom extension that automatically adds my command to several ArcMap layer context menus on start up.

I've documented this here: How to Add a Custom ArcObjects C# Command to a Standard ArcMap Layer Context Menu

Talk to you soon,

-Cory

www.eicher-gis.com

Diving into C#

Cory Eicher — Sat, 11 Feb 2006 18:47:00 +0000

Outside, it's been a chilly few days here in Denver, which has given me the opportunity to ramp up some of my skills. I'm a VB guy, but recently I dove into building some ArcObjects components in C#. The experience reminded me of a long-ago, early-morning, Adirondack scout camp, "polar bear" swim. Standing before the icy black, I shivered at the thought of jumping in... but the experience was surprisingly painless, and it was over and done before I knew it.

I started by working through the ESRI C# Walkthrough: Creating a simple command for ArcMap

Since I'm using Visual Studio 2005 (.NET 2.0) and I'm also using the Visual C# Express Edition, I found a few differences from the ESRI documented steps. I figured I'd note those differences here:

Create a new class library

Steps worked fine

Reference the ESRI object libraries

I found it useful to also reference to ESRI.ArcGIS.Utility. I used this later for component category registration.

Create a zoom-in command

Steps worked fine

Add a using directive

To define my class, I modified the default .cls. By default, you'll get these directives:

using System;

using System.Collections.Generic;

using System.Text;

I found that I only need the first, and I also added this directive:

using ESRI.ArcGIS.Utility.CATIDs;

Implement the ICommand interface

ESRI Step 4 states "Right-click the ICommand interface, click Add, and then click Implement Interface"...I couldn't find this functionality. Perhaps its because I'm using the Express version...
So, I manually stubbed out my class...actually, I copy/pasted from another ESRI dev sample.

Adding code to the members of ICommand

IntPntr is defined in System, so you'll either need a directive (see above), or you'll have to fully qualify:

private System.IntPtr m_hBitmap;

Returning the ICommand::Bitmap property

Steps worked fine

Expose the ZoomIn class to COM

To reg. for COM interop, Goto Project > Properties > Build > Register for COM interop. Also, maybe this is obvious, but I had to add GuidGen.exe as an External Tool (again, I'm using the Express Version of Visual Studio). Location for me was: "C:\Program Files\Microsoft Visual Studio 8\Common7\Tools"

Adding COM category registration functions

I did this differently. Since we're using ESRI.ArcGIS.Utility.CATIDs, you can do this instead:

#region "Component Category Registration"

[ComRegisterFunction()]

static void Reg(string regKey)

{

MxCommands.Register(regKey);

}

[ComUnregisterFunction()]

static void Unreg(string regKey)

{

MxCommands.Unregister(regKey);

}

#endregion

Compiling the project, Use the command in ArcMap

In order to get a .tlb, I had to go to Project > Properties > Application > Assembly Info > and check 'Make Assembly COM-visible'

Stepping through the command with the debugger

I found that I wasn't able to do this with the Express Version of VS... but I was hungry for lunch and I didn't try to hard...

Talk to you soon,

-Cory