Valeurs d'attributs répétitives automatisées avec SQL

ThomasColson

<\/HEAD>

La plupart (en fait toutes) de mes données SIG ont ce que j'appelle l'exigence de valeur d'attribut "Mickey Mouse" : chaque classe d'entités possède quelques champs d'attributs contenant des informations ennuyeuses telles que les limites administratives (dans quel état, comté ce point se trouve). Par le passé, j'ai été très fier des domaines d'attributs élaborés que j'ai créés afin que les éditeurs de données puissent choisir dans quel (County, State, USGS Topo Quad) leur point de données se situe.<\/P>

<\/P>

Personne ne les utilise.<\/P>

<\/P>

La saisie des données a un coût en temps et en travail, et comme la plupart d'entre nous, nous devons nous concentrer sur ce qui est important (ce qui s'est passé à ce point) et n'avons pas beaucoup de temps pour la saisie administrative des données.<\/P>

<\/P>

Jusqu'à ce qu'un rapport soit dû et nécessite la partition des valeurs de données par (state, county ou watershed).<\/P>

<\/P>

Dans Using SQL to Auto-Populate XY Values<\/A>, j'ai décrit l'utilisation d'un Trigger pour automatiser la population des coordonnées GPS en utilisant le texte bien connu extrait de la colonne geography. Il n'y a aucune raison pour laquelle nous ne pouvons pas étendre cela à la gestion de quelques tâches supplémentaires de maintenance des données.<\/P>

<\/P>

Dans cet exemple, j'ai les classes d'entités polygones de limites administratives suivantes toutes configurées avec le type de stockage "Geography" et SRID 4629 dans la même base de données SDE.<\/P>

1. GRSM_COUNTIES : le nom du County est renseigné dans le champ County ;<\/LI>
2. GRSM_States : le nom de l'État est renseigné dans le champ State ;<\/LI>
3. GRSM_Sub_Ranger_Districts : le nom du Ranger District est renseigné dans le champ PARKDISTRICT ;<\/LI>
4. USGS_24K_TOPOMAP_BOUNDARIES : le nom du USGS Quad est renseigné dans le champ QuadName ;<\/LI>
5. WATERSHEDS : le nom du HUC 12 Watershed est renseigné dans le champ Watershed.<\/LI>
6. <\/LI><\/OL>

   Notre politique de données est que chaque nouveau point de données sera attribué avec la valeur "Name" de chacun des 5 polygones dans lesquels il se trouve. Imaginez l'enthousiasme des éditeurs de données lorsqu'on leur dit qu'ils doivent choisir une valeur parmi plusieurs listes déroulantes, 5 fois, pour chaque nouveau point qu'ils ajoutent ou modifient !<\/P>

   <\/P>

   En étendant

Using SQL to Auto-Populate XY Values<\/A>, nous pouvons "joindre" spatialement le point nouveau ou mis à jour avec chacun des 5 polygones dans lesquels il se trouve et récupérer la valeur requise du polygone pour l'écrire dans le champ d'attribut correct.<\/P>

<\/P>

ALTER TRIGGER [dbo].[TEST_GEOGRAPHY]
ON [dbo].[TEST]
\/****** déclenché lors des insertions et mises à jour  ******\/
\/****** désactiver le trigger lorsque la réplication SQL ou le mirroring est activé  ******\/
after INSERT,UPDATE NOT FOR REPLICATION
AS   
BEGIN     
  SET NOCOUNT ON;  

  UPDATE p SET  
\/****** hypothétiquement nous pourrions entrer la lat/lon en texte et créer un objet geography  ******\/
        SHAPE = CASE WHEN i.SHAPE IS NOT NULL   
          THEN p.SHAPE ELSE Geography::STPointFromText('POINT('  
            + CAST(p.LON AS VARCHAR(20)) + ' '  
            + CAST(p.LAT AS VARCHAR(20)) + ')', 4269) END,  
\/****** cas habituel où le point est créé avec ARC et convertit LAT/LON en texte  ******\/
\/****** à partir de l'objet geography  ******\/
        LON = CASE WHEN p.SHAPE IS NULL THEN p.LON ELSE p.SHAPE.Long END,  
        LAT = CASE WHEN p.SHAPE IS NULL THEN p.LAT ELSE p.SHAPE.Lat END,
          QuadName = COALESCE(b.name, p.QuadName),
          Watershed = COALESCE(c.HUC_12_Name, p.Watershed),
          County = COALESCE(d.Name, p.County), 
          State= COALESCE(e.Name, p.State),
          PARKDISTRICT = COALESCE(f.District, p.PARKDISTRICT)
    FROM  TEST
        AS p 
\/****** permettre la mise à jour de lat/lon lors d'une mise à jour ******\/
    INNER JOIN  
      inserted AS i 
      ON i.globalid = p.globalid 
    LEFT OUTER JOIN USGS_24K_TOPOMAP_BOUNDARIES AS b 
      ON b.Shape.STIntersects(i.Shape) = 1 
          LEFT OUTER JOIN WATERSHEDS AS c
      ON c.Shape.STIntersects(i.Shape) = 1 
              LEFT OUTER JOIN GRSM_COUNTIES AS d
      ON d.Shape.STIntersects(i.Shape) = 1 
              LEFT OUTER JOIN GRSM_States AS e
      ON e.Shape.STIntersects(i.Shape) = 1
    LEFT OUTER JOIN GRSM_SUB_RANGER_DISTRICTS AS f 
ON f.Shape.STIntersects(i.Shape) = 1 
   ; 
END
GO<\/PRE><\/P>Il n'y a pas de limite au nombre de jointures que vous pouvez utiliser pour automatiser les requêtes spatiales qui mettent à jour les valeurs d'attributs. Souvenez-vous simplement que les deux classes d'entités participant à la jointure doivent utiliser le même type de stockage.<\/P><\/P>Mais que faire si vous souhaitez appliquer cela aux données existantes ? Après avoir créé le trigger, vous pourriez appliquer une requête unique pour mettre à jour les valeurs existantes. Cet exemple utilise le type de stockage Geometry :<\/P><\/P><\/P>use GRSM
update GRSM_TRAILS
set CONG_DIST = CONGRESSIONALDISTRICTS.NAMELSAD
from GRSM_TRAILS
inner join CONGRESSIONALDISTRICTS
on grsm_trails.location_id = grsm_trails.location_id
where (CONGRESSIONALDISTRICTS.Shape.STIntersection(grsm_trails.Shape).STDimension() = 1);<\/PRE><\/P><\/P>Ceci est un blog personnel et ne recommande pas, n'endosse pas et ne soutient pas les méthodes décrites ci-dessus. La modification des données utilisant SQL en dehors de la pile logicielle ESRI n'est bien sûr pas prise en charge et ne doit pas être appliquée à une base de données en production sans une compréhension approfondie et un plan de reprise après sinistre.<\/EM><\/P><\/BODY><\/HTML>