Assessing the GIS job market for someone just entering the market

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

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

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

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

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:

1. 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.
2. 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.
3. 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

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

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)