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.

[AlfredBaldenweck]

Not sure if I should make this a separate Idea or not, but I found out the hard way yesterday that MAPX and PAGX files also use relative paths, which is kind of weird because you'd assume that those files are meant to be shuffled around after creation. 

[NseaGIS]

wow, over 5 years later and no response from ESRI. Just one more reason to use QGIS... no ESRI support needed because their software actually WORKS

[Swish]

I create maps that have to be saved in the project folder (i.e. a folder named "Mathison Road Widening 2024" that will get all the project files saved into it, including reports, important emails, pictures, etc.) for a lot of different projects every year. The project folder is used by everyone else in my organization that is working on that project. Some projects get merged, split ("Mathison Widening North" and "Mathison Widening South"), renamed, etc. and quite often my first task with a new project is to copy a map from a previous project into the new project, then we'll add or subtract feature classes as necessary.

But with no one being able to find a way to store the absolute file path to shapefiles saved on the network drive (yes, we don't make shapefiles any more, we just have some legacy data that we haven't needed to convert yet) this has added 30 to 120 minutes of just repointing paths to the start of all new projects, plus another 10-45 for each other map we decide to add later on, and then it has to be done all over again when the project gets moved into the finished projects folder or the following year's active projects folder, etc.

The only featureclass paths that don't break are the paths to the ones stored on our SDE. Which I don' t have edit permissions for - probably only 10% of our GIS users have edit permission to that, just for data safety reasons. Surely the solution isn't for everyone, no matter how small a user, to purchase an ESRI Enterprise Server license... ?

[AlfredBaldenweck]

@Swish : If you're copying a literal map object from one APRX (Pro project) to another, your links shouldn't break. If you're copying the APRX directly, it will. Another solution might be to save a MAPX or PAGX file to a location that doesn't change (MAPX and PAGX also use relative paths, which is...interesting), then use those for each new project.

I still want absolute paths, but this is a potential workaround for you in the mean time.

There's another interesting wrinkle I'm waiting for a Support case to finish on before I write about it here.

[agjackson1]

Yikes. 5 years later, I'm finally migrating to Pro and this issue still isn't resolved?  Similar to what others have described, we are consultants and store any regional GIS data that we all need to access on a shared drive (G:/ North Carolina / Wake Co / Hydrology /, for example).  (Yes, we use online data too, but not everything belongs online.)  Data, maps, report figures, etc. specific to a project/contract go in that project's folder on our shared drive (F:/ 2024 / 2417 / Correspondence, GIS files, GPS data, Maps, etc.).  We are simply not going to duplicate every local aerial photo, parcels, streams, soils, rare species dataset, etc. that we use into every contract folder (where our .aprx's are stored) - that is insanity. Am I to understand that the only way for .aprx's to be able to be easily copied is to have ALL of its locally-saved layers in the same directory, under the .aprx?  With Desktop, when a new contract is near an older project, you just open the most recent .mxd ("Figure 1 - Project Location" for instance), save it to the new project/contract folder, add your new layers & move on with your life.  Why on earth is Pro not capable of that yet? So, in order to update my coworker's report figure for a new contract, I'm going to have to remap every single [local] layer, even though they have not moved and haven't been renamed? 

I'm assuming this is the reason why I absolutely can. not. navigate to some subfolders on our shared drive (even though the parent folders are "favorites").  I feel like the Computer tab in the Catalog pane should be a reflection of the actual, literal, current Windows file path on my computer... but it isn't!  I apparently originally copied this .aprx off of my laptop (I liked my symbology & had it all set up just right - I shouldn't have to defend that).  Now, on my office PC, when I try to navigate to and add a new file that is physically stored in this office, on the NAS across the hall (F:/ 2024 / 2417...), the "2417" folder isn't even there!  The list skips from 2416 to 2418.  I finally found my files in Catalog, listed under a different subfolder that ONLY EXISTS ON MY LAPTOP!  (Which is powered down, at my house.)  Apparently Catalog isn't showing us the actual file folder names, or we can unintentionally rename folders/directories within Pro... without also changing the folder name in Windows Explorer? It saved the original file path on my laptop as the... name... of the... path?  Why does a file path need a name?  When I right-click on the folder in Catalog and "show in File Explorer" (which is handy, by the way), it takes me to the correct folder with its correct name - Catalog just doesn't display that info (?).   

This is just bizarre.  Please, ESRI, just let us browse to our own files like grownups and save absolute file paths.  And play nice with Windows, if that's the problem?  I don't know the root issue, but this is absolutely maddening. Please give me an option to find my files myself - I know exactly where they are.  Thanks. 

[JoyDRoberts]

YES!!! To all of that. I thought it was our cyber settings causing the Catalog view to not show folders properly. Somehow I now have two folders named "ArcGIS Pro Projects" on my C drive and both have different content? NO WAY.
Esri, please, pretty please with organic, naturally-harvested-under-the-light-of-a-full-moon sugar on top, fix this.

[LindsayRaabe_FPCWA]

@agjackson1 ad @JoyDRoberts It sounds like your folders that say one thing but actually mean another are showing an inaccurate (potentially the original) alias instead of the current folder name after having moved an aprx? Maybe right-click and see if you can remove the Alias. 

Also, under Project > Options > Catalog Browsing you may want to change this setting to "Complete path" instead of "Folder name only". 

Before:

After: (note the missing drive letter names for network drives but not local drives - no idea whats going on there)

[LindsayRaabe_FPCWA]

I've just done a bit of testing myself on this relative vs absolute pathways thing and I'm even more confused now than I was before! It seems that data stored to a local drive (e.g. C) is updated when a project is Copy/Pasted but data on a Network Drive (e.g. G) is not. This isn't what I read above. UNC pathways also remained the same (as expected). 

I fully expected my Network data to be out of whack as well after moving the project. Really struggling to find the consistency!

[AlfredBaldenweck]

Time to break out the diagram haha. These screenshots have been getting a lot of use recently.

This is how folder connections are stored:

• Under the hood, each folder connection is stored as a relative path. This one is "Go up 5 levels". 
• Then, on opening Pro, it reads it and resolves out the path as the pathHint 
• The name is entire separate and based on what that relative path resolved to when the connection was made
• So, what ends up happening (real project of mine) is you open up Pro and it keeps the name that it already had. (That is, it says "WY", but is actually pointing to "GBP", the parent folder of "WY").
  

If the path is a direct parent of the APRX, it'll have this issue. 

Otherwise, it appears to resolve the relative path, see that it doesn't exist, then check the path hint and run with that, instead. I was testing something along these lines and noticing that a lot of folders are the same after moving because they're to the side of the APRX rather than above.

As an update to an earlier post, one thing that I noticed is that if you move a project (breaking its links), open it up, and save it, every broken link will resolve to an absolute path. This means that if you move the APRX back to the right spot, those links will still be broken because now they're hard-coded to point at something that doesn't exist. 

A request to change this behaviour has been logged as ENH-000173491