Comment modéliser un cimetière - un point par défunt ou un par tombe? [fermé]

Il s'agit d'une continuation de ma question précédente sur notre projet sur la façon de s'en sortir économiquement avec la mise en œuvre d'un cimetière dans un système SIG…

Au cimetière on peut trouver

• Tombes régulières: jusqu'à 2 personnes
• Tombes familiales: plus de 2, certaines jusqu'à 20 (sœurs d'une congrégation catholique…)
• Monument aux morts: environ 30 personnes
• Zone de dispersion des cendres: illimitée, à partir de 100 personnes
• Champs avec urnes funéraires: jusqu'à 2 par emplacement
• Murs avec urnes funéraires: jusqu'à 3 de hauteur

Alors, quelle est la meilleure façon de procéder, en définissant:

• chaque personne comme un objet POINT
• chaque tombe comme un objet POINT, les personnes font partie des attributs

Je choisirais pour chaque personne comme objet POINT:

• Un fichier CSV simple pour toutes les personnes.
• Les colonnes peuvent être par exemple: FirstName - FamilyName - YearDeceased
• Indépendant du nombre de personnes dans une tombe
• De cette façon, même la zone de diffusion des cendres peut aller dans le fichier
• Finalement, un code doit être écrit pour ajouter aux résultats d'une recherche les autres personnes enterrées dans la même tombe

Complications que je vois avec chaque tombe comme un objet POINT:

• Chaque emprise a besoin des colonnes pour le nombre maximum de personnes dans une tombe…
• Cela signifie que beaucoup de cellules seront vides en raison de quelques tombes avec beaucoup de gens
• Mais qu'en est-il de la zone de diffusion des cendres? 100 personnes ont besoin de toutes les colonnes supplémentaires du tableau…
• Il n'est pas raisonnable d'avoir toutes les données dans un seul fichier CSV, mais avoir plus de fichiers compliquera fortement le problème.

Les commentaires sont donc les bienvenus: personne ou tombe comme objet POINT? Ou rien de tout cela et dois-je le faire d'une autre manière?

Dans ma ville, il y a 3 ans, ils avaient un bureau fait des fichiers SHP pour eux. On m'a remis ces dossiers et j'ai remarqué que les tombes étaient dessinées comme des POLYGONS. Celui-ci est accompagné d'un fichier DBF pour les «données des tombes». Les tombes normales ont 4 ensembles de coordonnées, semble logique. Mais certaines choses me semblent absurdes:

• Il y a un «mur d'urne» avec des columbaria hexagonaux dessinés comme un ensemble de figures hexagonales… Cela signifie que chaque figure a 6 ensembles de coordonnées…
• Dans la «zone de diffusion des cendres», il y a un pilier avec de petites plaques signalétiques rectangulaires, ils ont dessiné un POLYGONE rectangulaire pour chaque plaque signalétique avec 4 jeux de coordonnées… Pour moi, l'utilisation de POLYGONS dans ces cas semble tellement exagéré dans la base de données.

En plus de cela, corrigez-moi si je me trompe, en utilisant:

• POLYGONS nécessite des fichiers DBF, donc un éditeur DBF (frais supplémentaires)
• POINTS ne nécessite que des fichiers CSV, donc EXCEL suffit (pas de frais supplémentaires)

Dans la plupart des villes, les données des personnes décédées sont enregistrées dans un fichier CSV:

• fait directement dans EXCEL ou
• exporté à partir d'un programme basé sur DOS, fait quand WIN95 était encore là…

Continuer à gérer les «données des personnes» dans un fichier CSV et EXCEL évite:

• achat d'un logiciel capable d'éditer des fichiers DBF
• s'inquiéter de l'importation des «données de personnes» dans le fichier DBF Il ne semble pas toujours facile d'importer, de modifier et d'enregistrer des données de CSV dans des fichiers DBF et de n'avoir AUCUNE corruption de vos données. J'ai lu que cela peut être le cas en particulier lorsque vous travaillez avec ArcGis (ESRI).

J'irais dans le sens compliqué: deux tables dans une relation 1: n

• une table avec l'emplacement ponctuel des tombes
• une autre table avec le Grave-ID et les données personnelles

Vous pouvez établir une relation entre les deux tables afin que la sélection d'une tombe sélectionne tous les enregistrements de personne dans la table de personne.

L'idée d'avoir des tables avec des champs comme Person1, Person2 ... est horrible et mauvais design.

Je créerais un polygone pour la tombe car la tombe elle-même est un terrain et a une relation un à plusieurs pour le peuple; une tombe peut avoir zéro (inoccupé, disponible ou à vendre?) ou plusieurs personnes. Vous pouvez également utiliser un point au lieu du polygone. Les polygones feraient de meilleures présentations pour les ventes et la maintenance.

Je prendrais la suggestion de DenaliHardtail d'utiliser des polygones pour représenter des tailles précises des parcelles. Cette couche peut avoir une table avec Grave_ID, Grave_Type, Grave_Capacity et Grave_Occupancy_Number. Ensuite, vous pourriez avoir une couche de points avec des points recouvrant les polygones graves correspondants. Les colonnes de la table des couches de points peuvent être ID de personne, First_Name, Family_Name, Birthdate, Deathdate, Graveowner et Grave_status (Sold, Unoccupied, etc.). Vous pouvez ensuite inclure l'ID de tombe correspondant pour chaque personne afin que vous puissiez faire correspondre la personne à la tombe et créer un tableau Excel unique plus tard avec toutes les informations sur la tombe et la personne individuelle.

La normalisation des données m'amène à quelques idées / points manquants. De plus, je pense qu'Excel peut faire tout ce que vous voulez pour la "base de données" que vous envisagez. Astuce: utilisez des feuilles ou plusieurs fichiers et utilisez des variantes des fonctions de recherche. Enregistrer dans le ou les fichiers utiles pour les importations / recherches à partir de QGIS

J'imagine ces tableaux discrets [ou feuilles Excel], pour commencer votre ensemble de données. Chaque feuille / fichier est facilement maintenu par les utilisateurs novices, tant que les colonnes sont clairement indiquées (et sont figées en ligne supérieure ...), et il est rappelé aux novices que les ID sont uniques et restent inchangés une fois attribués. Les feuilles et colonnes:

1. PlotDescription - les colonnes incluent: PlotID (liens au polygone), ownerID, plotTypeID (le type de parcelle: tombe, mur, crypte, etc.). Cette feuille est généralement statique, jusqu'à ce que l'on crée un nouveau tracé.
2. Owner - ownerID, colonnes avec description complète (nom / ContactAddress / etc), décédé (T / F). J'imagine que si vous avez plusieurs propriétaires, ils sont répertoriés dans leur intégralité dans le champ du nom, et vous n'auriez qu'une seule adresse de contact
3. Décédé - DeceasedID, PlotID, nom complet / etc / autres données d'identification, elevationCode. Le DeceasedID n'est pas trouvé ailleurs jusqu'à présent, mais une bonne forme crée un ID unique pour chaque défunt; pourrait être utile pour étendre les données - par exemple, une liste de parents vivant pour des événements ou du marketing.
4. ElevationCode - ElevationID puis une brève description ("inGround", "inCrypt", "first row", "second row", "ash tas", etc.). Cette feuille est généralement statique
5. PlotType - PlotTypeID et une brève description - crypte, tombe, etc. Ceci est une feuille statique

Pour l'état d'esprit du novice, je ne vous suggère pas de normaliser complètement les problèmes d'identité et leurs colonnes, dans la façon dont ils se chevauchent entre les propriétaires et les personnes décédées, et cela crée des tables auxiliaires inutiles à un seul nombre avec uniquement des identifiants divers. J'envisage un 1-à-1 entre l'intrigue et les tables propriétaires, comme un compromis pour la simplicité

Je pense que cette configuration généralisée résoudra des problèmes tels que: les tas de cendres, les cryptes murales, le suivi des propriétaires / mainteneurs, les décès multiples dans une parcelle, etc.

Enfin, n'oubliez pas de créer quelques lignes permanentes dans les deux tableaux / feuilles pour le propriétaire et le défunt: propriétaire inconnu; décédé inconnu; multiple inconnu décédé; appartenant au cimetière; n'appartenant pas; etc.