Validate creates a huge number of MUST HAVE A RECORD warnings

[DrewDowling]

Validating work in the error inspector results in sometimes hundreds of errors that various lines and polygons MUST HAVE A RECORD.

We did not create records for a large part of our data when we migrated to the parcel fabric. Our lot, parcel and subdivision parcel types do have records but our preexisting line work and administrative polygons do not. There is no legal document that we can tie these feature too and that is the bases of the records we initially created.

The large number of MUST HAVE A RECORDS errors are distracting to the editors and they often miss other more important errors due to the long list.

Do other organizations have this issue? If so how have you dealt with it?

I am considering creating a sort of master parent record for all out millions of lines and another for each of our polygon parcel types that don't currently have records. Is this a valid approach?

Any suggestions greatly appreciated.

[anna_garrett]

if you have a way to break down the master parent record by something that makes sense, it would probably be better than having one giant one. like "master record for [xyz school district]" or other entity that spans your whole fabric - like in ours, every single parcel will have a school district entity code. 

as it stands, we migrated from the old parcel fabric so all of ours retained <map> as the parent plan if it was not assigned to a plan in the old fabric. it's not ideal and I don't like it, it doesn't tell me anything about the parcel. 

[jcarlson]

It's not as easy post-migration, but having some kind of placeholder record is a good way to do it. I would advise against making giant records relating to many features, though, as that will create a massive, complex geometry in the records table.

When we migrated, we put every parcel feature and its lines into per-parcel records with an "Import" record type on it so that we could easily filter them out.

But long-term, the goal is to do away with those entirely by "backdating" the fabric and assigning parcels and lines to their appropriate records. Not an immediately feasible solution, though!

Another option would just be to mark all those "must have a record" errors as exceptions for features created at the time of migration. Any remaining errors would be valid.

[DrewDowling]

Thank you both for your suggestions. I think we will take the approach of creating individual  "initial commit" records for each polygon. I also like the idea of adding a record type for these.

I will then work on assigning existing line-work to the initial records based on a spatial join.

[AmirBar-Maor]

You can create a Record called "Unknown" or "Unknown - Research Required" and then copy the GlobalID of that record to all the features (polygons and lines) that have the 'CreatedByRecord IS NULL' field.

This record will likely be associated with more than 2000 parcels, so it will not have any geometry created for it.

For those that migrated from ArcMap, you can also change the record called '<map>' to something more meaningful like 'Unknown'.

[DeanAnderson2]

We had similar issues and selected our published "TAXMAP" as our record.  Taxmaps are either section, quarter section or quarter/quarter section areas (approximately) and represent a published map.  We used these as our default record. It works pretty well.   The are an attribute of the taxlot polygons so it was easy to create records for them. 

Unfortunately, our pre-existing linework did not have a record.  I used to following to associate the converted lines with the record: 

1. Create a new temp feature class by intersecting the converted lines with the record polygons (only keep the featuerids)
2. Do a double join to join line work with the records 
3. Calc the creatdby record in linework to be equal to the record guiid. 

This seems to work pretty well.  Obviously the result makes sure every line has a record but  lines on the border are going to go one record or the other - but who cares.   (See attached code snippet)

[DrewDowling]

Thanks Amir and Dean. I've finally had time to start looking at this again and both you suggestions work for me in theory. The issue is since we are live and have many editors a huge bulk update is slow and will cause many conflicts.

@AmirBar-MaorI thought of an alternative approach and would appreciate your feedback. Could I alter the "MUST HAVE RECORD"  attribute rule to only check features that have been created after the initial load date? The create date of all of the original feature is either prior or equal to the day we loaded all our data into the fabric. Only features created after this date are going to genuine violations of this rule.

[AmirBar-Maor]

@DrewDowling 

Yes - you can modify any of the Attribute Rules that are shipped with the system. You can even delete them if they are not applicable for you.

The current expression for the rule MUST HAVE A RECORD is:

return !IsEmpty($feature.CreatedByRecord);

You can modify it to:

//Setting: If your data was migrated on June 18th 2019, you should add 2 days (June 20th) to avoid time rounding issue.
var MigrationDate = Date(2019,05,20); //Note: the month count starts at zero. year 2019, month of JUNE, 20th day. 
var CreationDate = Date($feature.Create_Date);
if (DateDiff(CreationDate, MigrationDate, 'days') > 0){
    return !IsEmpty($feature.CreatedByRecord);
}
return true;