nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

ArcGIS Pro > Geoprocessing > Analysis Tools > Proximity > Near > Match Fields

RogerDunnGIS

In ArcGIS Pro > Geoprocessing > Analysis Tools > Proximity > Near, there is a section where you can specify input layer fields and near layer fields (Match Fields). If one of these fields is a GlobalID and the other is a GUID, ArcGIS Pro puts an error tag on the Match Fields parameter and says that the fields are not of the same type. Technically they are different types, but they can be treated like the same type.

Could the Near tool's code be modified to accept a GlobalID and a GUID field as Match Fields and treat them both as GUID fields, in order to suppress the error and proceed to run the tool? Thank you.

Finde mehr Beiträge mit dem Tag

Geoprocessing

Status: Öffnen

Kommentare

DavidSolari

This happens all over the place in ArcGIS, GUID/Integer fields are technically different from GlobalID/ObjectID fields even though they hold the same data types so many tools reject them, even in cases like this where compatibility makes perfect sense. A full sweep of the standard tools for cases like this to loosen up the data type matching would be appreciated.

Ayan Palit

The typical logic for Match Fields/Attribute Values would start at validating the same Data Type. This is done for data integrity purposes.

The common example is '123' can be stored as Number or Text. But the behavior of data operations like sort, calculate, join may differ based on the data type.

RogerDunnGIS

@AyanPalit: A comparison between '123' and a Number is not a worthy inclusion check because a string can be a value like 'Hello, World' which would throw an exception. I understand that. I think everyone agrees with you on that. But OBJECTIDs and Integers share the same domain/range of values, and GlobalIDs and GUIDs share the same domain/range of values. The only difference I can see between OBJECTIDs and Integers, and between GlobalIDs and GUIDs, is within the scope of the attribute table: OBJECTIDs and GlobalIDs are unique, whereas Integers and GUIDs could be duplicated. But as far as their types are concerned, they are the same. My idea/suggestion is that tools such as Near treat them as if they were the same during comparisons only. The equality operator between OBJECTID and Integer, and between GlobalID and GUID doesn't really change.

Nehmen Sie an der Diskussion teil

Melden Sie sich an, um zu posten, Inhalte zu folgen und mehr. Neu hier? Kostenlos registrieren.