Workflow de géotraitement pour les sous-types
Les classes d'entités et les tables de géodatabase stockent des objets du même type, à savoir des objets qui ont le même comportement et les mêmes attributs. Par exemple, une classe d'entités appelée WaterMains peut stocker des conduites d'eau pressurisées. Toutes les conduites d'eau ont le même comportement et ont les attributs ReferenceID, Profondeur, Matière, GroundSurfaceType, Taille et PressureRating.
Bien que tous les objets d'une classe d'entités ou d'une table doivent avoir le même comportement et les mêmes attributs, tous ne partagent pas les mêmes domaines attributaires. Par exemple, dans un réseau de distribution d'eau, il est possible que seules les conduites d'eau d'acheminement puissent avoir une pression comprise entre 40 et 100 psi, tandis que les conduites d'eau destinées à la distribution ont une pression comprise entre 50 et 75 psi. Vous pouvez utiliser un domaine attributaire pour mettre en application cette restriction. Pour implémenter ce genre de règle de validation, vous n'avez pas à créer de classes d'entités distinctes pour les conduites d'acheminement et de distribution, mais vous souhaitez peut-être distinguer ces types de conduites d'eau afin d'établir un ensemble séparé de domaines et de valeurs par défaut. Pour y parvenir, vous pouvez vous aider de sous-types.
Cas d'utilisation des sous-types
Un problème important se pose concernant la création de la géodatabase lorsque vous devez décider dans quels cas il est approprié de recourir à des sous-types et dans quels cas des classes d'entités sont requises. Lorsque vous tentez de distinguer des objets à l'aide des valeurs par défaut, domaines attributaires, règles de connectivité et règles de relation qui leur sont associés, il est conseillé de créer des sous-types distincts pour chaque classe d'entités ou chaque table.
Lorsque vous distinguez des objets selon leurs comportements, attributs et privilèges d'accès ou selon qu'ils sont multi-versionnés, vous devez créer plusieurs classes d'entités.
Workflow de sous-type
Les étapes suivantes permettent de créer des sous-types pour une table ou une classe d'entités :
- Définir le champ de sous-type : définit le champ dans la classe d'entités ou la table en entrée qui stocke les codes de sous-type.
- Ajouter un sous-type : ajoute un nouveau sous-type à l'ensemble des sous-types dans une classe d'entités ou une table.
- Définir un sous-type par défaut : définit la valeur par défaut unique d'un sous-type, également appelée code.
Dans l'exemple suivant, les sous-types sont créés pour représenter les différents types de conduits dans une classe d'entités des conduites d'eau.
La première étape consiste à définir le champ utilisé pour stocker les informations de sous-type :
import arcpy
arcpy.env.workspace = "C:/data/Montgomery.gdb"
arcpy.SetSubtypeField_management("Water/Fittings", "TYPECODE")
Une fois le champ de sous-type défini, les codes sont ajoutés à la liste des sous-types :
arcpy.AddSubtype_management ("Water/Fittings","0", "unknown")
arcpy.AddSubtype_management ("Water/Fittings", "1", "bend")
arcpy.AddSubtype_management ("Water/Fittings", "2", "cap")
arcpy.AddSubtype_management ("Water/Fittings", "3", "cross")
arcpy.AddSubtype_management ("Water/Fittings", "4", "coupling")
arcpy.AddSubtype_management ("Water/Fittings", "5", "expansion joint")
arcpy.AddSubtype_management ("Water/Fittings", "6", "offset")
arcpy.AddSubtype_management ("Water/Fittings", "7", "plug")
arcpy.AddSubtype_management ("Water/Fittings", "8", "reducer")
arcpy.AddSubtype_management ("Water/Fittings", "9", "saddle")
arcpy.AddSubtype_management ("Water/Fittings", "10", "sleeve")
arcpy.AddSubtype_management ("Water/Fittings", "11", "tap")
arcpy.AddSubtype_management ("Water/Fittings", "12", "tee")
arcpy.AddSubtype_management ("Water/Fittings", "13", "weld")
arcpy.AddSubtype_management ("Water/Fittings", "14", "riser")
La dernière étape consiste à définir le code de sous-type par défaut :
arcpy.SetDefaultSubtype_management ("Water/Fittings", "2")