[OSGeo-Discuss] Opensource Geospatial Job Tracking Software

[Ragi Y. Burhum]

Job Tracking for ArcGIS was initially created to manage the GIS data
acquisition and data assurance contracts within ESRI. As such, the "spatial
aspect" is in the center of all of this and is a key element of the product.
It leverages GeoDatabase Versioning and was really the inspiration of
GeoDatabase History.

An example of a common problem is to have a person that is responsible for
an area (let's call it the manager), who in turn manages multiple editors
(these could be a combination of multiple subcontractors as well as editors
within the organization). Each of these resources get assigned an area.

How do they get assigned areas? Well the manager starts up the tool and uses
it to mark certain areas, sets up the jobs area and assigns it to
resources.

The "regular" editors only have to login to the Job Tracking Manager where
they get a list of the jobs they need, and they indicate the work they are
going to do. For them, ArcMap gets started, the layers they need to edit get
added to the map, the right editing toolbars are up and ready and ArcMap
even zooms in to the area of interest so they can start their job.

It could have been that the area they were assigned was exclusive to them.
They may only be allowed to edits features within their area of work in
order to avoid conflicts with someone else. Regardless, they use the tool to
submit changes to be approved by the manager and move to the next task
(maybe do quality assurance or correct some data in another area as
specified in another job).

What if the job was for an offsite sub contractor? Well, a version gets
created and the data gets "checked out" (i.e extracted with a checkpoint to
keep track of what the data looked like at that point) ready to be ingested
into whatever GIS system the subcontractor uses. When they are done, they
check it back in (maybe many months later).

The manager, knows who is doing what using the system. He/she *may* be the
responsible one for reconciling (i.e merging) the versions. Or perhaps it is
done automatically or a mix. Regardless, if there is a conflict (more than
one person editing the same feature at different points), he/she can check
the history and see who made the change, when and as part of what job.

Reconciling geographic data is made *****much****** easier, when it can be
seen in reference to other layers. The manager has access to something like
this:

http://blogs.esri.com/Dev/photos/eapblogs/images/1202/original.aspx

Which basically shows the state of the database at four different times.

1.- The last time that the features were the same. (aka Common Ancestor).
2.- The feature as it looks like by edits from editor 1
3.- The feature as it looks like by edits from editor 2
4.- The feature as it looks like in the *now* state.

These allows the manager to see which edits make sense in reference to the
rest of the geospatial data right from the tool.

You can reassign jobs to an user to fix their version if you think they made
a mistake, etc etc.

This manager may be a resource for someone else, and so on and so forth.

Yes, most (if not all) the pieces that we need to build something like this
are out there, but AFAIK, nobody has put then together yet.

My 2 cents.

- Ragi Burhum


From: discuss-bounces at lists.osgeo.org [mailto:
> discuss-bounces at lists.osgeo.org] On Behalf Of Robert Hollingsworth
> Sent: Wednesday, January 06, 2010 12:42 PM
> To: OSGeo Discussions
> Subject: Re: [OSGeo-Discuss] Opensource Geospatial Job Tracking Software
>
> I also wondered if the original question is much broader than the
> utility/telco cases I mentioned.  Your question is probably the most
> important to answer here:
>
> "Is there really a spatial aspect in the requirements to track GIS related
> jobs ?"
>
> My preference is that the answer be, largely, "NO."  I'm not well versed in
> business process state management software; my instincts tell me that
> in basic spatial data migration, the spatial aspect does not really
> introduce any wrinkles that cannot be handled.  Hopefully, in more
> complex scenarios where the answer might appear to be "Yes," one
> could data-model the exception case out of existence.
>
> An exploration of the referenced ESRI job-tracker might be instructive
> here.
>
> I'll see if I can come up with any cases where proper process state
> management is truly dependent on geometry.  Any one else?
>
> Robert
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/discuss/attachments/20100106/527e7acf/attachment-0002.html>