Validate Database tool issue (2.12.4): SymbolPoints and LabelPoints feature classes in CartographicElements feature dataset

[alwunder]

We have a number of databases converted from the old Esri coverage data model that had been structured with point classes to represent the locations of symbols (line decorations, etc.) and the locations of labels as they were placed on the printed map.

Even though some of these features may now be obsolete, I am not inclined to delete them, and in some cases they are still quite useful for re-creating the cartographic product from the database. For that reason, I have built classes in our TNGeMS schema to house these features within our CartographicElements feature dataset. They are GeMS-y with Symbol and Type attributes and all have class names that end in "SymbolPoints" and "LabelPoints". The problem I'm having is similar to the one I raised in Issue #67 with the CartographicPoints class where validation flags these classes as missing the following fields: Label, LocationConfidenceMeters, PlotAtScale, StationsID, MapUnit, and LocationSourceID.

Can the Validate Database tool be modified to ignore these classes (perhaps ignore the entire CartographicElements feature dataset) or report them as Warnings?

[tfelger]

I noticed a similar issue with a feature class MapUnitLabelPoints that we create and use only for building polygons. The validator used to flag it as a schema extension, but with recent versions of the tool it is now throwing errors about missing fields LCM, PlotAtScale, etc. It would be nice if it could also somehow be excluded from requiring those extra fields.

[ethoms-usgs]

I just made some changes and tested with a MapUnitLabelPoints feature class modeled after MapUnitPoints but then deleted LCM and PlotAtScale and there no errors.

What's happening, if you care: for the purposes of validation, all point feature classes that are not defined in Gems and whose names end in Points or Samples get tagged as the equivalent of either the GenericPoints or GenericSamples feature class and the fields for those were not defined as "optional" in GeMS_Definition.py. All fields are now optional but since the list of fields in a custom point feature class gets compared to a "Generic" equivalent, any custom field added to the table still gets logged as an extension.

Try it out by downloading from green Code button, not the Releases section. I will publish a new release if this looks good.

[alwunder]

Thanks, Evan. I appreciate the explanation because it helps me understand the logic and (hopefully) makes me a better tester of the script.

I have tested it with the database that was giving the errors I mentioned above. It works great! Passes Level 3 validation with no issues. I will also test it later with the larger schema and see how it does.

[tfelger]

I also appreciate the explanation! And I tested it, and it works great - thanks!