Need absolute path names in Pro

[FredWatson]

ArcGIS Pro should have the option to use absolute path names. In ArcMap, we can choose between absolute and relative. We should have that same choice in Pro.

A key reason to allow absolute path names is to facilitate a use mode involving many projects accessing the same data. In turn, this may be motivated by preferring to have a very large and relatively stable geospatial data system that is independent of the projects that are using it (and/or independent of the users that are using it; and/or independent of the software that is using it). It may also be motivated by needing to work on so many (100-1000) projects that even a small amount of common data between projects would lead to large amounts of wasted storage space duplicating the same data.

Not everyone works this way. But enough of us do that it should be an option. I teach Arc to college students; I use it in research; I've probably created 300 MXDs in my preferred use mode, which relies on absolute path names.

It's fine if relative paths are the default. But they should not be the *only* option.

None of the existing workaround are wholly satisfactory. Using "Save As" and moving folder references from within Pro is cumbersome and only solves half the problem. Using separate drives for data and projects is too restrictive. Scripts to convert relative to absolute paths would be cumbersome.

[KoryKramer]

Fred Watson‌ and others who have up voted this, can you provide some examples of paths you're using in your projects - for folder connections, databases, etc?  Are you connecting to mapped network drives with drive letters, or UNC paths?  Are you and your students moving project files across different machines and/or different drives?

[FredWatson]

Sure, Kory Kramer. Here's a path to a file that I use in a lot of projects:

C:\f\_dat\nam\usa\ca\counties\monterey\NAIP\2018\ortho_1-1_hn_s_ca053_2018_1.sid

C:\f\dat\ is a ~1TB geospatial data collection organized in a geographic hierarchy.
The file I've indicated here is a 4 GB aerial photo mosaic.

The common use case that fails under relative paths is when moving projects between folders in a drive. This is a very common use case for us.

[RobertBorchert]

we use UNC path and it works very well.

[FredWatson]

Robert Borchert‌ - Can you use UNC paths to emulate the absolute-path example I posted above?

[AJR]

It's a hassle to have to worry about re-pathing everything just because the project file got moved on disk, absolute paths (or the option to use absolute/relative) would address this.

[PatIampietro]

The simple answer here is that newer, supposedly improved software applications to which we are being encouraged (read: forced) to migrate should be as or MORE functional than the older platforms they purport to replace.

ArcMap allowed the user to specify which was more appropriate in any given situation: absolute or relative paths.

ArcGIS Pro removed that choice and with that change reduced functionality.

It's not the only place that happened in Pro, just one of many examples.

[CoryLittle]

@PatIampietro  Totally agree with you.  If I had functionality in ArcMap that I can not emulate in Arc Pro without effecting major changes, it is difficult to call this progress.  As far as you know, have there been any updates on this subject?

[JoyDRoberts]

Agree that we need absolute path names. One example I can share is that people at my company map their fileshares inconsistently so one can't rely on the "Data" drive being the T drive, etc. 

[EmelineRenz]

TL;DR: It would be at the very least helpful to use Absolute Paths WHILE Performing a Save As on an ArcGIS Project File. Then, the project could revert back to Relative Paths. 

@KoryKramer - Here are two scenarios. 

Another instructor here with the same issue. When teaching a new concept, sometimes it is helpful to build off of previous assignments, so students can use a nice map to show the differences between multiple projections, for example. I also ask students to keep their data organized, to prepare them for Real World GIS (which tends to breed chaos between data and maps and all the things everywhere... I digress..)

In this case, I asked them to perform a Save As on the Project (from Lab 5), then store the new APRX in the LABS folder as "Lab6.aprx". The previous project was in the LABS/Lab5 folder, but when they APRX is saved in LABS, the Paths to the Layers, Table, Folder Connections, etc. are all BROKEN. [In hindsight, this is a Teachable Moment, so maybe I shouldn't complain!]

Here's another scenario: I'm asking the Graduate Assistant who has "GIS Experience" to perform some analysis or map some of my research data. I sure as heck don't want them EDITING the data or changing my previous project work, but I don't have Fancy Enterprise cause my Grant was small. So, I Save a Copy of the APRX into a folder they can Edit, but I want to keep the Project Data in a separate folder they can read, but not edit. When I send them a link to their folder, and they open the APRX, it should still point to my GDB, even using Relative Paths, but shouldn't show them Broken Layers. Instead, I have to fix all the layers before sending them the link. 

[BarryFradkin]

We have a toolbox with ModelBuilder models that is saved in a shared network folder, but gets copied into individual project folders to update some inputs for each project site. Some of the data used in the models is stored in a shared network folder, and I would like the models to be able to maintain the link to that location. Unfortunately, with the default set to maintain relative path names, it always adds the file path of the new project in front of the saved file path to the shared data - breaking the link. If we had an option to switch to absolute path names this wouldn't be an issue. @KoryKramer