¡Rasters, Pixels y Código, Oh Dios!<\/A> extendí un disparador de automatización para llenar un campo de atributo basado en su ubicación dentro de un píxel raster. Pero aún quiero más automatización de datos. ¡Lo quiero todo!<\/P>
No solo queremos conocer algunos atributos administrativos de nuevos puntos de datos (¿en qué condado, estado está?: Intersección Espacial), qué altura tiene, sino que en una era de puntos de datos no tan precisos, ¿qué es lo más cercano a este punto?<\/P>
<\/P>
En esta aplicación en particular, un conjunto de datos de monitoreo de calidad del agua, también quiero saber el nombre del arroyo en el que ocurre este punto, así como el orden del arroyo. Estoy usando NHD Stream Lines que han sido procesadas con Arc Hydro para agregar el Orden Strahler del Arroyo como un atributo.<\/P>
<\/P>
Usando una Consulta de Vecino Más Cercano puedo lograr eso, aunque con un poco más de complejidad porque ahora le estoy pidiendo a SQL que busque la característica "Nearest", y no una simple intersección de dos objetos geográficos. El bloque de código comienza en la línea 48.<\/P>
<\/P>
<\/P>
<\/P>
ALTER TRIGGER [dbo].[TEST_GEOGRAPHY]
ON [dbo].[TEST]
\/****** se activa en inserciones y actualizaciones ******\/
\/****** deshabilitar disparador cuando la replicación o espejado SQL está habilitado ******\/
after INSERT,UPDATE NOT FOR REPLICATION
AS
BEGIN
SET NOCOUNT ON;
UPDATE p SET
\/****** hipotéticamente podríamos ingresar latitud/longitud como texto y crear un objeto 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,
\/****** caso usual: el punto es creado con ARC y convierte LAT/LON a texto ******\/
\/****** desde el objeto 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),
ELEVATION = (SELECT
pdata.getValueByLoc(1,p.SHAPE.Long,p.SHAPE.Lat) FROM [dbo].[DEM10MP]),
StreamName = COALESCE(g.GNIS_Name, p.StreamName),
RiverOrder = COALESCE(h.RiverOrder, p.RiverOrder)
FROM TEST
AS p
\/****** permitir actualización de lat/lon en actualización ******\/
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
& nbsp; LEFT OUTER JOIN GRSM_States AS e
 .& nbsp;e.Shape.STIntersects(i.Shape) = 1
& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;}& nbsp;
CROSS APPLY (SELECT TOP 1 GNIS_Name, shape
FROM dbo.NHDFLOWLINE
\/****** forzar sugerencia de índice espacial ******\/
WITH(index ([S208_idx]))
WHERE NHDFLOWLINE.Shape.STDistance(i.Shape) IS NOT NULL
ORDER BY NHDFLOWLINE.Shape.STDistance(i.Shape) ASC) as g
CROSS APPLY (SELECT TOP 1 RiverOrder, shape
FROM dbo.NHDFLOWLINE
\/****** forzar sugerencia de índice espacial ******\/
WITH(index ([S208_idx]))
WHERE NHDFLOWLINE.Shape.STDistance(i.Shape) IS NOT NULL
ORDER BY NHDFLOWLINE.Shape.STDistance(i.Shape) ASC) as h
;
END
GO<\/PRE><\/P>Note el uso de una sugerencia de índice aquí. En SQL 2008 el uso del índice espacial no se respeta y, de hecho, no funciona sin muchos ajustes. Aquí le estamos diciendo que encuentre el nombre del arroyo más cercano y su orden, pero use el índice espacial de la clase de entidad NHD Flowline para optimizar la consulta. ¡Sin la sugerencia del índice esta consulta tarda una eternidad!<\/P><\/P>Si el nombre del arroyo es nulo (como muchos lo son), las sentencias crossapply y order by detienen la búsqueda en el arroyo más cercano en lugar de buscar el arroyo nombrado más cercano.<\/P><\/P>He encontrado que esto funciona mejor cuando aplico algunas reglas para la entrada de datos: agregar un nuevo punto solo usando snapping (al layer NHD en la interfaz del mapa). Existe el peligro de que alguien pueda agregar erróneamente un nuevo punto que esté "algo" entre dos arroyos, y se podría atribuir al punto el nombre y orden incorrectos.<\/P><\/P>En esta aplicación en particular, lo estamos usando junto con las herramientas USGS HEM, que manejan el snapping, asignación y población del reachcode al dato puntual, por lo que no nos preocupa mucho el escenario del punto equivocado en el lugar equivocado.<\/P><\/P>Este es un blog personal y no recomienda, respalda ni apoya los métodos descritos arriba. La alteración de datos usando SQL fuera del stack de software ESRI, por supuesto, no está soportada y no debe aplicarse a una base de datos en producción sin una comprensión completa y un plan de recuperación ante desastres.<\/EM><\/P><\/BODY><\/HTML>