County GIS must attach parcel APN identifiers for governance without treating them as render geometry. Where should that custom information live?
Select an answer to reveal the explanation.
Short Explanation
You’re right to keep APNs as governance labels, not normals, light intensity, or mesh bounds. Put them in customData on the relevant layer or prim so you can query them without affecting rendering.
Full Explanation
County GIS parcel APN identifiers are governance and cadastral labels, not render geometry. Store them in custom metadata/customData on the relevant layer or prim so inventory, permitting, and audit tools can query them without overloading rendering data. OpenUSD customData is intended for site-specific descriptive information that travels with an asset but does not drive shading or topology. Storing APNs only as face-varying normals corrupts shading and creates a cryptic encoding that standard tools do not understand. Putting an APN only in UsdLux intensity on a dome light ties parcel identity to lighting and fails when the light is omitted from a delivery. Encoding an APN only as the mesh extent maximum Y value conflates bounds with identity and can break when geometry changes. Exam caveat: customData is the targeted answer when the requirement is custom information that must not be treated as render geometry. Practical check: author APNs in customData on parcel prims, query them with a GIS reconciliation script, open the stage in a shaded viewer to confirm materials and normals are untouched, and verify that republishing preserves customData through the DCC round-trip.