<div class="gmail_quote"><div>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.</div>
<div><br></div><div>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. </div>
<div><br></div><div>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. </div><div><br></div><div>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. </div>
<div><br></div><div>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).</div>
<div><br></div><div>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).</div>
<div><br></div><div>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. </div>
<div><br></div><div>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:</div><div><br></div><div><a href="http://blogs.esri.com/Dev/photos/eapblogs/images/1202/original.aspx">http://blogs.esri.com/Dev/photos/eapblogs/images/1202/original.aspx</a> </div>
<div><br></div><div>Which basically shows the state of the database at four different times. </div><div><br></div><div>1.- The last time that the features were the same. (aka Common Ancestor).</div><div>2.- The feature as it looks like by edits from editor 1</div>
<div>3.- The feature as it looks like by edits from editor 2</div><div>4.- The feature as it looks like in the *now* state.</div><div><br></div><div>These allows the manager to see which edits make sense in reference to the rest of the geospatial data right from the tool.</div>
<div><br></div><div>You can reassign jobs to an user to fix their version if you think they made a mistake, etc etc.</div><div><br></div><div>This manager may be a resource for someone else, and so on and so forth.</div><div>
<br></div><div>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.</div><div><br></div><div>My 2 cents.</div><div><br></div><div>- Ragi Burhum</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
From: <a href="mailto:discuss-bounces@lists.osgeo.org">discuss-bounces@lists.osgeo.org</a> [mailto:<a href="mailto:discuss-bounces@lists.osgeo.org">discuss-bounces@lists.osgeo.org</a>] On Behalf Of Robert Hollingsworth<br>
Sent: Wednesday, January 06, 2010 12:42 PM<br>
To: OSGeo Discussions<br>
Subject: Re: [OSGeo-Discuss] Opensource Geospatial Job Tracking Software<br>
<br>
I also wondered if the original question is much broader than the<br>
utility/telco cases I mentioned. Your question is probably the most<br>
important to answer here:<br>
<br>
"Is there really a spatial aspect in the requirements to track GIS related jobs ?"<br>
<br>
My preference is that the answer be, largely, "NO." I'm not well versed in<br>
business process state management software; my instincts tell me that<br>
in basic spatial data migration, the spatial aspect does not really<br>
introduce any wrinkles that cannot be handled. Hopefully, in more<br>
complex scenarios where the answer might appear to be "Yes," one<br>
could data-model the exception case out of existence.<br>
<br>
An exploration of the referenced ESRI job-tracker might be instructive here.<br>
<br>
I'll see if I can come up with any cases where proper process state<br>
management is truly dependent on geometry. Any one else?<br>
<br>
Robert<br>
<br><br></blockquote></div>