Як моделювати кладовище - один бал на померлого або один на могилу? [зачинено]

Це продовження мого попереднього питання про наш проект про те, як економічно піти з впровадження кладовища в системі ГІС ...

На кладовищі ми можемо знайти

• Регулярні могили: до 2 осіб
• Сімейні могили: понад 2, десь до 20 (сестри з католицької громади…)
• Пам’ятник війни: близько 30 осіб
• Зола розсіювання золи: необмежена, починаючи з 100 чоловік
• Поля з поховальними урнами: до 2 на місце
• Стіни з поховальними урнами: до 3 у висоту

Отож, який найкращий шлях слід визначити:

• кожна людина як об’єкт POINT
• кожну могилу як об’єкт POINT, особи є частиною атрибутів

Я б вибрав для кожної людини об'єкт POINT:

• Один простий файл CSV для всіх осіб.
• Стовпці можуть бути, наприклад: FirstName - FamilyName - YearDeceased
• Незалежно від кількості людей в могилі
• Таким чином, навіть зола розсипання золи може перейти у файл
• Врешті-решт треба написати якийсь код, щоб додати до результатів обшуку інші особи, поховані в одній могилі

Ускладнення, які я бачу з кожною могилою як об'єкт POINT:

• Кожному ROW потрібні стовпчики для максимальної кількості людей в могилі…
• Це означає, що багато клітин буде порожньо через лише кілька могил з великою кількістю людей
• Але що з зоною розсипання золи? 100 осіб потребують усіх додаткових стовпців таблиці…
• Нерозумно мати всі дані в одному файлі CSV, але наявність більшої кількості файлів дуже ускладнить це питання.

Отже, коментарі вітаються: людина чи могила як об’єкт POINT? Або нічого з цього, і чи потрібно це робити іншим способом?

У моєму місті 3 роки тому у них було бюро, яке робило для них файли SHP. Мені передали ці файли, і я помітив, що могили намальовані як ПОЛІГОНИ. Сюди входить файл DBF для "даних могил". Нормальні могили мають 4 набори координат, здається логікою. Але деякі речі здаються мені абсурдними:

• Існує "стінка урни" з шестикутними коломбаріями, намальованими як набір шестикутних фігур ... Це означає, що кожна фігура має 6 наборів координат ...
• У «зоні розсіювання золи» стовп із маленькими прямокутними табличками, вони намалювали прямокутний ПОЛІГОН для кожної таблички з 4 наборами координат… Мені використання даних POLYGONS у цих випадках здається настільки надмірним у базі даних.

Окрім цього, виправте мене, якщо я помиляюся, використовуючи:

• POLYGONS вимагає файлів DBF, тому редактор DBF (додаткові витрати)
• POINTS вимагає лише файлів CSV, тому EXCEL достатньо (без зайвих витрат)

У більшості міст дані померлих входять у файл CSV:

• виготовлені безпосередньо в EXCEL або
• експортується з програми на базі DOS, зробленої, коли WIN95 ще не було ...

Продовжуючи керувати "даними про осіб" в одному файлі CSV, і EXCEL уникає:

• придбання програмного забезпечення, яке може редагувати файли DBF
• турбуєшся про імпорт "даних осіб" у файл DBF. Імпортувати, редагувати та зберігати дані з CSV у файли DBF, здається, не завжди буває без клопоту, а ваші дані НЕ мають пошкодження. Я читав, що це може бути особливо при роботі з ArcGis (ESRI).

Я б пішов складним шляхом: дві таблиці у відношенні 1: n

• одна таблиця з точковим розташуванням могил
• ще одна таблиця з даними Grave-ID та особами

Ви можете побудувати відношення між двома таблицями так, що, вибираючи могилу, вибиратимуться всі записи людей у ​​таблиці особи.

Ідея мати таблиці з такими полями, як Person1, Person2 ... - жахлива та погана конструкція.

Я створив би багатокутник для могили, оскільки сама могила є земельною ділянкою та має стосунки для багатьох; одна могила може мати нуль (незайнята, наявна або на продаж?) або багато людей. Ви також можете використовувати крапку замість багатокутника. Полігони зробили б кращі презентації для продажу та обслуговування.

Я б прийняв пропозицію DenaliHardtail використовувати багатокутники для зображення точних розмірів сюжетів. Цей шар може мати таблицю з Grave_ID, Grave_Type, Grave_Capacity та Grave_Occupancy_Number. Тоді ви могли б мати точковий шар з точками, що перекривають відповідні багатокутники. Стовпці для таблиці точкових шарів можуть бути "Ідентифікатор особи", "Перше ім'я", "Ім'я сім'ї", "Дата народження", "Дата смерті", "Гравеонер" та "Граве_стат" (продано, незайнято тощо). Потім ви можете включити відповідний ідентифікатор Grave для кожної людини, щоб ви могли зіставити людину з могилою та створити згодом єдину таблицю excel з усією інформацією про могилу та особу.

Нормалізація даних приводить мене до деяких відсутніх ідей / моментів. Крім того, я думаю, що Excel може зробити все, що завгодно, для тієї «бази даних», яку ви плануєте. Підказка: Використовуйте аркуші чи кілька файлів та використовуйте варіанти функцій пошуку. Збережіть у корисні файли (файли) для імпорту / пошуку з QGIS

Я передбачу ці дискретні таблиці [або відмінні листи], щоб почати ваш набір даних. Кожен аркуш / файл легко підтримується початківцями користувачами, доки чітко вказані стовпці (і заморожені як верхній рядок ...), а новачок нагадує, що ідентифікатори є унікальними та залишаються незмінними після призначення. Аркуші та стовпці:

1. PlotDescription - стовпці містять: PlotID (зв'язки з багатокутником), ownerID, plotTypeID (тип сюжету: могила, стіна, склеп тощо). Цей аркуш, як правило, статичний, доки не створюється новий сюжет.
2. Власник - ID власника, стовпці з повним описом (ім'я / контактна адреса / тощо), померлий (T / F). Я маю на увазі, що якщо у вас є кілька власників, вони будуть вказані повністю у полі імені, і ви матимете одну контактну адресу
3. Померлий - DeceasedID, PlotID, повне ім’я / тощо / інші ідентифікаційні дані, elevationCode. Померлого ID поки не знайдено в іншому місці, але хороша форма створює унікальний ідентифікатор для кожного померлого; може бути корисним для розширення даних - наприклад, списку родичів, які живуть для подій чи маркетингу.
4. ElevationCode - ElevationID, а потім короткий опис ("inGround", "inCrypt", "перший рядок", "другий рядок", "куча золи" тощо). Цей аркуш, як правило, статичний
5. PlotType - PlotTypeID та короткий опис - склеп, могила тощо. Це статичний аркуш

Зважаючи на умонастрій початківців, я не пропоную вам повністю нормалізувати проблеми ідентичності та їх стовпців, таким чином, як вони перетинаються між власниками та померлими, і це створює непотрібні 1-багато допоміжних таблиць, окрім різних ідентифікаторів. Я передбачаю 1-на-1 між таблицями сюжету та власника, як компроміс для простоти

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

Нарешті, не забудьте створити кілька постійних рядків у двох таблицях / аркушах для власника та померлого: невідомий власник; невідомий померлий; невідомий багаторазовий померлий; належить кладовищу; не належать; тощо.