¿Cómo mostrar solo etiquetas para una selección arbitraria de elementos?

10

Tengo curiosidad por saber cómo otros resuelven este problema: ha creado un mapa para algo con una gran cantidad de características etiquetadas. El cliente / cliente le pide que solo muestre etiquetas para X, Y y Z, basándose en alguna decisión aparentemente arbitraria (por ejemplo, lo que consideran características importantes). ¿Cómo harías para hacer esto?

Algunas ideas:

  • Cree una nueva columna de cadena para esta etiqueta especial y solo complete un valor para las características que desean ver (podría dar como resultado información duplicada)
  • Cree una nueva columna booleana y marque las características que desean ver con verdadero, luego use el etiquetado condicional en QGIS 1.8 para mostrar solo la etiqueta cuando el booleano es verdadero
Brian Kelly
fuente
66
La segunda idea tiene muchas ventajas: (i) documenta claramente lo que debe etiquetarse, (ii) es tan permanente y portátil como el conjunto de datos subyacente, (iii) proporciona un mecanismo simple y directo para determinar qué etiquetas aparecerán ( que es incluso portátil para otro SIG o paquete de trazado), (iv) incluso es susceptible de análisis en caso de que haya alguna pregunta sobre las relaciones entre estas opciones de etiquetas y cualquier otra variable, y (v) codificando pausualmente la elección del cliente , no crea información duplicada.
whuber
2
@whuber, ¿puedes responder eso para que pueda votar? Porque esa es exactamente la forma en que lo haría.
Nathan W

Respuestas:

11

La segunda idea (crear un atributo booleano para la selección) tiene muchas ventajas :

(i) documenta claramente lo que debe etiquetarse,

(ii) es tan permanente y portátil como el conjunto de datos subyacente,

(iii) proporciona un mecanismo simple y directo para determinar qué etiquetas aparecerán (que es incluso portátil para otro SIG o paquete de trazado),

(iv) incluso es susceptible de análisis en caso de que alguna vez haya preguntas sobre las relaciones entre estas opciones de etiquetas y cualquier otra variable, y

(v) al codificar parsimoniosamente la elección del cliente, no crea información duplicada.

Aquí hay algunos principios generales de construcción y gestión de bases de datos en funcionamiento , como se sugiere sabiamente en la pregunta. Una de ellas es que cualquier información coherente debe estar representada de manera única en la base de datos si es posible. (La información utilizada como claves para implementar uniones y relaciones, por supuesto, debe aparecer en varios lugares en virtud de su función como identificación de los registros correspondientes en diferentes tablas). Existen excelentes razones para este principio, como cualquier persona que haya intentado mantener un sistema no normalizado. la base de datos relacional puede dar fe: si no recuerda constantemente actualizar, eliminar o agregar esta información a cada En la tabla en la que aparece, su base de datos pronto se vuelve internamente inconsistente: está dañada, a menudo irremediablemente.

Otro principio es que en un buen diseño de base de datos relacional, cada tabla debe representar una sola "entidad" conceptual : algo que los datos están modelando o una relación entre esas cosas. Cuando un cliente especifica una selección de características aparentemente arbitraria, está especificando efectivamente un subconjunto de filas en una tabla. Matemáticamente, por el axioma de separación, esto es lo mismo que marcarlos con un campo booleano. Por lo tanto, cualquier subconjunto de cosas "arbitrario" significativo en una base de datos puede ser representado por un campo booleano y, por el contrario, dicho campo es una buena manera de almacenar subconjuntos (o selecciones) arbitrarios.

Otro principio es que debe preferir utilizar las capacidades de gestión de datos subyacentes del SIG para almacenar información . La alternativa es alguna ad hocmétodo basado en la capacidad del SIG para almacenar información dentro de sus "archivos de proyecto" o de alguna otra forma independiente. Un ejemplo típico de esto es la práctica de elegir y colocar manualmente las etiquetas deseadas. A menudo es rápido y fácil hacer esto. Los problemas surgen cuando se necesita un cambio o el trabajo necesita ser reproducido; una u otra de estas situaciones es prácticamente inevitable. La colocación manual de las etiquetas equivale a almacenar información (es decir, qué subconjunto de características debe etiquetarse) fuera del RDBMS de una manera extremadamente elíptica. A saber, la selección especificada únicamente por qué etiquetas aparecen y cuáles no. Piense cómo resolvería estos problemas siguientes:

  • El cliente quiere que las mismas etiquetas aparezcan en un mapa relacionado pero diferente, parte de un proyecto diferente.

  • Surge una pregunta sobre si las etiquetas están asociadas con algún otro atributo.

  • Después de realizar varios cambios en las etiquetas a lo largo del tiempo, se le solicita que vuelva a la versión original.

En estos casos, el trabajo involucrado para resolver el problema puede ser enorme: debe rehacer el etiquetado nuevamente, o realizar verificaciones cruzadas manuales en las tablas de la base de datos, o buscar y restaurar un antiguo archivo de proyecto archivado. Si las etiquetas se representaran con un campo booleano en la base de datos, el trabajo sería casi trivial.

whuber
fuente
1
Recién estoy comenzando con GIS, pero tengo algunos conocimientos de bases de datos de desarrollo de software. Sospecho que pronto tendré una pregunta de seguimiento sobre la preservación del conjunto de datos original mediante la creación de una tabla separada específica para el cliente que se une de 1 a 1 con el conjunto de datos original y tal vez se proporcione como una vista PostgreSQL para transparencia.
Brian Kelly
Sí, esa también es una buena solución. Con su conocimiento de la base de datos, sabe que rara vez hay una respuesta perfecta; siempre hay compensaciones. Una tabla de búsqueda es elegante y perfecta para algunas situaciones. De hecho, a menudo solo necesita una nueva tabla que enumere los identificadores de las entidades a etiquetar: una unión a la tabla de atributos de capa crea un nuevo campo (externo) que es nulo para que las entidades no se etiqueten, y está bueno para ir. Pero ahora tiene una nueva tabla para administrar en la base de datos: existe la compensación.
whuber
8

Probablemente pueda establecer la regla en el nuevo etiquetado basado en expresiones. La regla funcionará como documentación de lo que ha estado haciendo para obtener las etiquetas resultantes.

La ventaja sobre el enfoque de "bandera booleana" es que es más flexible mientras se trabaja en la regla correcta. Es fácil cambiar y mejorar la regla sin alterar el conjunto de datos subyacente. Por otro lado, no es portátil para otros paquetes SIG.

Este es un ejemplo en el que solo etiqueto entidades con nombres de más de seis caracteres y con una clase determinada:

ingrese la descripción de la imagen aquí

bajo oscuro
fuente
1
Pero la regla en este caso es "Considero que estas características son importantes y las otras no importantes". No creo que haya una función para eso :-)
Brian Kelly
1
Además, esta pregunta se relaciona con "¿Cuándo debería alterar un conjunto de datos y cuándo debería copiarlo?" Sin embargo, sospecho que es una conversación mucho más amplia.
Brian Kelly el
Simplemente asumí que esas características importantes al menos tendrían una ID que puede usar como yo usé el atributo clazz. Hay ventajas para ambas soluciones.
oscuro