I used to use the "Data Owner" centric model. It does a few things (not just budgetary):
- It gathers information from the point of creation. (They put the pipes in the ground - they know where they are [outside of GIS].)
- It completes the (important GIS) cycle: collection, user viewing, correction/maintenance.
- It allows ownership in the data quality/data confidence (extremely important).
BTW: in my situation I found "helper" positions who could devote some time each week and trained them. In my case it was a shop organizer and program manager. It could also be the "old" guy who did it all and will retire soon.
Kinda get his knowledge into the system approach.
My suggetions is that real world should be the first representation.
Then if there are exceptions to that (as per your example) you can utilize shematics or catrtographic representations.
I have this problem constantly in my current job with more that one line in a ditch.
If they are of the same type and size that is one thing.
But it rarely is.
@cwb - from your comment I would sort of turn my answer around.
For data that I could identify a capable/willing gis participant I used the data-owner model.
In my case code enforcement had one person. Building/editing data was out of the question for that person.
I handled all GIS editing maintenance, aquisition, ownership for most of the data our municipality owned.
I think that goes with the territory.
Again (with the cup half full) I turned it into a positive when I could.
I would aggregate GIS data maintenance to the department level and hit them up for project help with
and always include these groups in GIS day seminar/training sessions.
I would be interested to know more of what you mean by "I would aggregate GIS data maintenance to the department level and hit them up for project help with
For instance I was responsible for filling data requests by the public and builders for the planning dept.
I made a document outlining all requirements for the aquisition,
then a document (for me or my predessesor) outlining the data extraction process,
and finally a document for the order itself.
I also estimated the time for each request (my first document defined the scope available for each request).
At year end I was able to create a document showing time spent (estimated), material cost (dvd/cd, shipping, etc), and re-imbursment as-per our privacy/access policy
(which I also created to set amounts to be charged for data requests under the freedom of information act, with a smattering of privacy, and a good dose of homeland security for appropriate data).
The permitting/enforcement section of the planning dept used me as a resource also.
So I would use job codes for those.
I woud then aggregate all costs for the planning dept not to hit them in the head but to inform them of what they were getting "for free".
We didn't charge departments for plooting, scanning, or any other GIS function. So it was helpful to let them know before they went to budget meetings
(with the mayor and council cutting funding)
why and where they needed to stand up for my department/section.
I then called them when I planned a city-wide aerial photo project and added them to the budgetary planning, specification review process, and ultimately the contract review/award process.
I would also do my best to track time, resources, software, and support for other depatrments.
By having a plot/data//map request form it was fairly simple to keep time records (which I had to do anyway for payroll (numeric) and my dept head (project descriptions).
When or if a data request was not completly singed off within a reasonable time,
I would pull it and go to the dept head and discuss options.
Such as help with data creation, project redesign, etc.
keep hitting the comment button. And I will fill in more details as I have time for.