Як показати мітки лише для довільного вибору предметів?

Мені цікаво, як інші вирішують цю проблему: Ви створили карту для чогось із великою кількістю функцій, які позначені міткою. Клієнт / клієнт просить, щоб ви показували лише мітки для X, Y і Z, спираючись на якесь, здавалося б, довільне рішення (наприклад, те, що вони вважають важливими ознаками). Як би ти зробив це зробити?

Деякі ідеї:

• Створіть новий стовпчик рядка для цієї спеціальної мітки та заповніть лише значення для функцій, які вони хочуть бачити (це може призвести до повторної інформації)
• Створіть новий булевий стовпець і позначте функції, які вони хочуть бачити з істинними, а потім використовуйте умовне маркування у QGIS 1.8, щоб відображати мітку лише тоді, коли булева правда

Друга ідея (створити бульний атрибут для вибору) має багато переваг :

(i) він чітко документує, що потрібно маркувати,

(ii) він такий же постійний і портативний, як базовий набір даних,

(iii) він пропонує простий і прямий механізм визначення того, які мітки будуть відображатися (який навіть переноситься на інший ГІС або графічний пакет),

(iv) це навіть піддається аналізу, якщо виникають питання щодо взаємозв'язку між цими виборами міток та будь-якими іншими змінними, і

(v) парсимонічно кодуючи вибір клієнта, він не створює дублюючої інформації.

Тут працюють деякі загальні принципи побудови та управління базами даних , як це мудро запропоновано в питанні. Один з них полягає в тому, що будь-яка узгоджена інформація повинна бути унікально представлена ​​в базі даних, якщо це можливо. (Інформація, яка використовується як ключі для здійснення з'єднань, і, звичайно, повинна з'являтися в декількох місцях в силу її функції визначення ідентифікацій відповідних записів у різних таблицях.) Для цього принципу є чудові причини, як і кожен, хто намагався підтримувати ненормовану норму. реляційна база даних може засвідчити: якщо ви не послідовно пам'ятаєте оновлювати чи видаляти або додавати цю інформацію до кожного таблиці, в якій вона описується, ваша база даних незабаром стає внутрішньо непослідовною: вона пошкоджена, часто безповоротно.

Інший принцип полягає в тому, що при гарному дизайні реляційних баз даних кожна таблиця повинна представляти єдину концептуальну "сутність" : те, що дані моделюють, або взаємозв'язок між цими речами. Коли клієнт визначає, здавалося б, довільний вибір функцій, вони ефективно вказують підмножину рядків у таблиці. Математично за аксіомою поділу це те саме, що позначати їх булевим полем. Таким чином, будь-яке значуще "довільне" набір речей у базі даних може бути представлене булевим полем і, навпаки, таке поле є хорошим способом зберігання довільних підмножин (або виділень).

Ще один принцип полягає в тому, що вам слід віддавати перевагу використанню базових можливостей управління даними ГІС для зберігання інформації . Альтернатива - деяка спеціальна роботаметод, заснований на здатності ГІС зберігати інформацію в межах своїх «файлів проектів» або іншим незалежним способом. Типовим прикладом цього є практика ручного вибору та розміщення потрібних міток. Часто це зробити швидко і просто. Проблеми виникають щоразу, коли потрібна будь-яка зміна або робота має бути відтворена; та чи інша з цих ситуацій практично неминуча. Розміщення міток вручну є рівнозначним для зберігання інформації (а саме того, який підмножина функцій слід маркувати) поза RDBMS надзвичайно еліптично. А саме, вибрано лише те, за допомогою яких міток з’являються, а які - ні. Подумайте, як би ви вирішили ці подальші проблеми:

• Клієнт хоче, щоб ті самі мітки відображалися на пов'язаній, але різній карті, частині іншого проекту.

• Виникає питання, чи пов’язані мітки з якимось іншим атрибутом.

• Після впровадження декількох змін на етикетках, вас попросять повернути до початкової версії.

У цих випадках робота над вирішенням проблеми може бути величезною: вам доведеться повторно маркувати етикетки або виконувати вручну перехресні перевірки таблиць баз даних, або знайти та відновити старий архівований файл проекту. Якби замість міток було представлено булеве поле в базі даних, робота натомість була б майже тривіальною.

Можливо, ви можете просто встановити правило в новій маркування на основі виразів. Правило буде працювати як документація того, що ви робили, щоб отримати отримані мітки.

Перевага перед підходом до "булевого прапора" полягає в тому, що це більш гнучко під час роботи над правильним правилом. Змінити та вдосконалити правило легко, не змінюючи базовий набір даних. З іншого боку, він не переноситься для інших пакетів GIS.

Це приклад, коли я маркую лише функції з іменами довше шести символів та з певним класом: