Human Readable 'Created By Record' / 'Retired By Record' Field

[anna_garrett]

Exactly what it says in the title. Right now, the field Created By Record/Retired By Record has a string of characters that Pro uses but I can't search by it or otherwise identify which record did what outside of whatever the active record is. 

Please consider changing this field to reflect the Name field. 

[jcarlson]

The created/retired field is a GUID, which relates into the GlobalID of the record, and GlobalId → GUID is the most reliable way to relate features. If a relationship class were based on the name field, which is editable, then updating the name in the parent record would break the relationship, and you'd end up with orphaned parcels.

It's been suggested elsewhere that users who want human-friendly record attributes visible on the parcel features should do using Attribute Rules. This method is okay, but in the event that a record's attributes are themselves edited, attribute rules on the parcel features won't fire, and you will have outdated attributes until the parcels themselves receive some kind of edit, or the rules are run in batch.

It's possible to use Arcade to show the record values in the popup, or as a label.

var fs = FeatureSetByName(
    $datastore,
    'yourFabricName_Records',
    ['name', 'globalid'],
    false
)

// I tried FeatureSetByRelationShipName, but Pro didn't like it.

var rec = First(Filter(fs, `globalid = '${$feature.CreatedByRecord}'`))

return DefaultValue(rec['name'], '')

But you still can't search by that value, except in the records layer.

Another alternative is to add a Join between your layers based on the GUID / GlobalID fields:

The major downside to this approach is that you've got to add the join for every single parcel and line layer in the fabric to get at the attributes, and do it twice if you want the same attributes for the retiring record.

Changing the relationship field probably isn't the way to fix this, but it would be really nice if Parcel layers had some kind of popup, label, and/or virtual join in place by default when parcel fabrics are added to the map.

[anna_garrett]

well that's something I could try out when I have another slow day. 

What prompted this was trying to figure out what the deed was that created a parcel that was being further divided by a newer deed without having to go into our separate appraisal database and dig. I thought, oh I could search by the GUID in the Created By Record field but nothing came up. 

I also thought records couldn't have their attributes edited after it had parcels associated with it? Maybe that's old info and I just haven't tried to add data to a record recently

[jcarlson]

At least in Pro, you can edit all the record's details (even the geometry, not that you'd want to) any time you like. Great for when you make typos. But the globalID cannot be changed once created, which makes it the ideal choice for a relationship class.

[anna_garrett]

oh yeah, I get how a GUID works. It's the same as OIDs. 

Side note, looks like I had Records unchecked in the List by Editing window. That's why I haven't been able to edit them. Whoooops.

I might be able to cobble something together in Arcade to show me what I want to see, especially with huge parent parcels that get subdivided into smaller parent parcels over time. 

[Kevin_Priestley]

This is a really great convo and I just wanted to add one quick caveat to the geometry edit idea from @jcarlson above: you can absolutely edit the geometry of records features, but using the Build tool (either Active or Extent) will reconstruct the geometry of record features from associated parcel features. 

This is particularly useful during alignment and adjustment workflows to help ensure that your records features always line up with their associated poly and line features: https://pro.arcgis.com/en/pro-app/latest/help/data/parcel-editing/buildparcelsfrompolygons.htm#ESRI_... 

[jcarlson]

Yes, it's basically an OID, but unique across your datastore (Globally Unique ID), do your record's globalID will never be repeated in any feature in any layer of your database.

@anna_garrett  Are you working strictly with a published service, or do you have direct access to the database? There's a lot you can do with query layers for reshaping/merging data through an SQL query. For a time, we had a query layer that essentially put together the parcel lineage into a report-ready table.

[anna_garrett]

@jcarlson ah yeah that's the difference. I honestly do appreciate that functionality as much as I'm complaining about it.

I have direct access to the database, is there any way you could share that query? Not going to use it directly, it won't work on my end and I know it, I would just really love to see an example of something that worked at one point. My SQL is rusty lol

[jcarlson]

It's been a while since I used this. Our RDBMS moved during our last upgrade, and direct queries aren't as convenient as before, plus we found we didn't use the functionality enough to justify doing it this way. Querying a branch versioned table is a bit more complex than normal, since you have to keep track of the branch, the gdb_archive_oid, and whether or not the record has been deleted. Here's an example of parcels joined to records, bringing in the created/retired attributes:

with

p as (
	select distinct on(globalid)
		globalid,
		name as parcel_number,
		retiredbyrecord,
		createdbyrecord
		shape,
		gdb_is_delete
	from ownershipparcels 
	where gdb_branch_id = 0 
	order by objectid, gdb_archive_oid desc
),

r AS (
	SELECT DISTINCT ON(globalid)
		globalid,
		name AS record_name,
		recordeddate,
		recordtype,
		gdb_is_delete
	FROM pf_records
  	WHERE gdb_branch_id = 0
  	ORDER BY objectid, gdb_archive_oid DESC
)
  
SELECT DISTINCT ON(p.globalid)
	p.globalid,
    parcel_number,
    r1.name AS created_doc,
    r1.recordeddate AS created_date,
    r2.name AS retired_doc,
    r2.recordeddate AS retired_date,
    p.shape
FROM p
LEFT JOIN r as r1 ON p.createdbyrecord = r.globalid
LEFT JOIN r as r2 on p.retiredbyrecord = r.globalid
WHERE p.gdb_is_delete = 0 AND r1.gdb_is_delete = 0 and r2.gdb_is_delete = 0

Adding spatial elements to these queries gets complex fast, and often perform pretty poorly for large datasets, but you can do it. I can't find my old "lineage" query, but it used other CTEs of parcels with buffering and matching created/retired attributes to identify things like "direct descendant parcels" and "direct parent parcels".

PS - We use PostgreSQL / PostGIS, so certain things may not translate over to another RDBMS.

[AmirBar-Maor]

I have created this post to show different methods of seeing the records records' name.

https://community.esri.com/t5/arcgis-parcel-fabric-videos/see-the-record-name-as-part-of-the-parcel/...

I hope you like it.

Amir