I'll be following the Microsoft OneDrive conversation closely as it may yield some potential answers, but I wanted to ask a parallel question here without muddying the waters there.
DOTs will typically provide localization via custom workspaces with cells, levels, linetypes, etc., and those resources will typically be placed on the C. I'm based in Atlanta and have (thus far) set up GDOT and NCDOT to coexist (largely harmoniously) on my machine. But we do share work frequently across offices, states, etc., and I'm wondering if anyone's had experience with successfully locating DOT workspaces in a shared environment (read cloud here rather than a local network). The explicit advantage would be the maintenance of a single instance per jurisdiction (keeping current and complete one workspace for Georgia, one for Florida, etc.) and the explicit disadvantage being that the instructions for localization (if these first two are any indication of the norm) are plainly intended to be entirely contained within and exercised from a local drive.
The thought of having to instantiate a new workspace (and its attendant linkages to GEOPAK or InRoads or whatever until we're all sufficiently open-roaded to smile and sing together) each time I add a state (actually, this I don't mind so much, but the thought of everyone - and inevitably some for whom it'll be uphill and intimidating - having to do it every time) isn't particularly comforting, and that process is just particular enough not to be well served by global/remote IT support.
So, now that we've rambled a bit: can custom workspaces be resourced from non-local drives (step 1) and can multiple custom workspaces be organized on a non-local drive such that I could potentially pull up a Texas or Wyoming or Iowa DOT launch and be ready to go from the drop?
My guess is that there's an actual technical barrier to doing so, but my hope is that it's virtually impossible (and thus, by definition, possible if only remotely so) and that someone might have made a bit of progress in this direction already. We can't be the only ones for whom this would offer a huge benefit.
Thanks in advance, and happy Wednesday.
Michael Schultz
Kennesaw, Georgia
We don't do cloud but keep various client (most DOTs) workspaces on our local servers and replicate those workspaces to different offices that work on projects together. Our needs are that a user be able to switch between projects from different DOTs without doing anything on their local computer to switch projects. Additionally we should be able to sync the workspace between offices without needing to re-write any config and still have the user use the version from their local server.
One issue you'll run into if you have projects that last for awhile is that this: "The explicit advantage would be the maintenance of a single instance per jurisdiction" becomes impossible. Projects with a multi-year lifespan will refuse to upgrade to a DOT's newer workspace unless absolutely forced to by the client. Everybody becomes afraid of upgrading a workspace as is because they may screw up other projects using the same workspace.
With CONNECT we plan on moving to a scenario where the entire workspace for the client is part of each individual project. This kind of sucks for disk space (although that really isn't an issue for us anymore) and each project is in control of their entire workspace. Templates will let them setup a new project with the correct, latest version, of an client's workspace, while existing projects can upgrade or not as necessary and not worry about affecting other projects.
Honestly, if you are already planning on redoing a workspace in order to share work across offices I would recommend using ProjectWise with Managed Workspaces. It's a bit to learn but I think overall the effort is worth it.