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.

[StevenDel_Favero]

Another failure by Esri to understand how their software is actually used. ArcPro is poorly designed to function as collaborative enterprise software, where. In the real world people share data and tools. ArcPro projects are geared toward siloed individuals.

[PaulLohr]

So this is an improvement over ArcMap, that we cannot switch between relative and absolute paths? 

This "idea" was posted 3.5 years ago. It would sound like we are stuck without the ability to switch.

Have the people who designed this product never worked in a corporate environment?

[RyanSlevin]

Yes also very concerning seeing a 3-year-old thread...

@KoryKramer any update if this is being considered?

[LyonMNGIS]

@KoryKramer 

Please add back the ability to store absolute vs relative paths!  It would be even better if ArcGIS Pro could silently try to connect to an absolute path first and then fail over to connect to data using a relative path.

https://community.esri.com/t5/arcgis-pro-ideas/need-absolute-path-names-in-pro/idi-p/938348

I am not sure what the options could be but I imagine one of these could work:

• Connect to data using an absolute path.  If the data is not found than try connecting to data using a relative path (default)
• Connect to data using a relative path if the data source is in a subdirectory of the project.
• Always connect to data using absolute paths
• Always connect to data using relative paths

[LyonMNGIS]

ArcMAP allowed us to save relative or absolute pathnames to our data source.  Could we bring that back in ArcGIS Pro.  This would be a great help so we can move around projects without needing to select "Save As"

Thanks!

[AlfredBaldenweck]

So, this has recently (in the last two days) bitten me VERY hard.

As a whole, we're moving our files from a network drive to Microsoft Azure. Part of this process is to completely reorganize our folders to fit a national standard.

Old structure:

• State
  • District
    • Local Office
      • gisdata
        • Folder 1
          • Folder 1A
      • projects
        • project home folder

New Structure:

• State
  • Local Office
    • reference_data
      • Folder 1
        • Folder 1A
    • projects
      • project home folder

The majority of offices are choosing to re-organize after the move. This has proven to be a poor choice.

The reason for this is because Pro stores all layer data sources as relative paths:

    "dataConnection": {
      "type": "CIMFeatureDatasetDataConnection",
      "featureDataset": "ROAD_FEATURE_CLASSES",
      "workspaceConnectionString": "DATABASE=..\\..\\..\\..\\reference_data\\transportation\\roads\\2011\\RFO_TRANSPORTATION.gdb",
      "workspaceFactory": "FileGDB",
      "dataset": "RFO_ROADS",
      "datasetType": "esriDTFeatureClass"
}

 Taken from the JSON file describing this layer in the APRX

In short, this layer's data source is 4 levels up from the APRX's directory, then in reference_data\...\RFO_TRANSPORTATION.gdb

So, what happened when we moved is that the APRX still kept those same instructions for finding the data. The most immediate problem is that it's looking for folders that don't exist. That's honestly fine, we expected the links to break with the move.

The bigger problem is that the way we structured our code to repair a given project's broken links was to read a CSV containing the start folder and the end folder, then do a find/replace on the datasource. 

This does not work at all in the new structure, since, while the Excel file is looking for:

\\State\District\Local_Office\gisdata\Folder1\Folder1A\example.shp

Pro stores the layer's path as:

..\gisdata\Folder1\Folder1A\example.shp

which translates to the following when Pro launches the APRX:

\\State\Local_Office\gisdata\Folder1\Folder1A\example.shp

which is 1) not in my spreadsheet and 2) absolutely impossible for me to predict programmatically since it's relative to every. single. project.

This has ROYALLY messed up our plans and made what was already not a super fun task monumentally harder. Like, it'd probably be pretty fine if we were either just reorganizing or just moving, but the combo of the two is deadly without absolute paths.

I'd also like to mention that we can use Absolute paths in LYRXs, so why not APRX?

Please, give us the option to use Absolute paths.

[PatIampietro]

Five years on and despite 72 kudos and multiple posts offering the very use cases and examples that @KoryKramer requested, there has been no progress on this, or even an admission on Esri's part that it is a valid request.

Why remove the option for absolute paths? Both methods (relative and absolute paths) have their uses. Sometimes one is better than the other, and sometimes it really doesn't matter and either will do just fine. But don't force us to use only relative. Doing so makes ArcGIS Pro LESS powerful.

[RTPL_AU]

@KoryKramer Would it be feasible for you to clearly explain the logic and thinking behind this regression?  Maybe your team found a better way of doing things and due to bad documentation we just don't realise the potential for a relative path only workflow?  
I still have to find a way to overcome this limitation in my typical environment  - other than messing around with templates and 'just fix it after the fact' every time - which you can agree is not productive.

[PaulLohr]

At what point should we give up on such a reasonable request? How long should we wait on this and numerous other issues which are still unresolved? This request was submitted 4.5 years ago.

If something as basic as file pathing does not work correctly, how can this product be relied on for daily work? And I am supposed to have our organization switch over to this product?