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

12

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).
Patrick Van Den Noortgaete
la source
@DenaliHardtail - Un tracé peut avoir plusieurs marqueurs. Considérez les anciens combattants qui ont à la fois une pierre tombale traditionnelle et une plaque militaire au pied.
2
Les réponses sont susceptibles d'être fortement basées sur des opinions sans détails plus précis sur le logiciel et son utilisation (par exemple, si vous suivez la route de table associée, votre logiciel / serveur de cartographie Web prend-il en charge de telles requêtes?). La question fondamentale, point par tombe vs personne est simple - personne, pas de question. Point / tombe avec plusieurs attributs de personnes est une mauvaise idée, car il s'agit d'une mauvaise conception de la base de données pour de nombreuses raisons déjà mentionnées. Mais demander «faites-le autrement» le rend encore trop large et fondé sur l'opinion. Je ferais des points et des zones idéalement, mais juste des points si je garde les choses simples.
Chris W
1
En outre, QGis peut modifier des fichiers de formes (y compris .dbf), OpenOffice peut modifier .dbf, ils sont tous deux gratuits.
RemcoGerlich
1
Cette question semble s'aggraver. N'oubliez pas que GIS.SE est le mieux ciblé, une question par question à laquelle vous pouvez répondre en au plus quelques paragraphes. Dans l'état actuel des choses, l'ensemble de ces questions-réponses est vraiment mieux adapté à un chat qu'à des questions-réponses. Oui, une partie de l'organisation des données que vous décrivez dans les fichiers de formes qui vous sont donnés semble étrange / exagérée / mauvaise conception. Votre compréhension des points par rapport aux polygones et nécessitant un dbf est erronée (vous voudrez peut-être étudier les composants d'un fichier de formes), et au mieux votre impression des problèmes de csv avec ArcGIS est biaisée. Les CSV ne sont pas des feuilles de calcul, les feuilles de calcul ne sont pas des bases de données.
Chris W
2
(Continue) Les fichiers texte, les feuilles de calcul, les bases de données, et en particulier les bases de données spatiales, ont des capacités et des modes de fonctionnement différents. Il semble que vous ayez besoin de décider si vous souhaitez utiliser SIG, ou simplement vous en tenir à la cartographie Web basée sur des fichiers texte contenant des coordonnées de points. QGIS est gratuit, peut faire tout ce que vous voulez d'un point de vue SIG, et ces choses sont relativement faciles à apprendre. Le composant de cartographie Web est une autre histoire.
Chris W

Réponses:

21

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.

takearf
la source
Ce n'est pas compliqué. C'est bien modéliser vos données! +1 pour une bonne conception relationnelle.
jpmc26
C'est aussi ce que je pensais. Mais je ne suis pas familier avec le "renforcement des relations", je ne suis pas du tout un expert SIG. Devrait examiner / étudier que ... Je suppose que c'est possible dans QGIS ...
Patrick Van Den Noortgaete
@Patrick - Chargez votre fichier de formes et un fichier dBase dans QGIS, affichez la boîte de dialogue des propriétés de votre fichier de formes, sélectionnez Jointures et créez une jointure entre vous dBase et les données de forme. Essayez de jouer un peu pour vous familiariser avec.
takearf
5

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.

DenaliHardtail
la source
2
Je ne suis pas dans le cimetière, mais j'aime être aussi complet que possible. J'inclurais les parcelles / champs de diffusion / monuments sous forme de polygones ainsi que des points pour les pierres tombales.
JasonT
@JasonT c'est un bon point. Un terrain (le terrain) peut-il contenir plusieurs pierres tombales / marqueurs si plusieurs personnes sont enterrées dans le terrain? Je suis d'accord, chaque marqueur est son propre point.
DenaliHardtail
1
Une parcelle pourrait avoir un propriétaire sans être occupée, si quelqu'un avait pris ses dispositions pour l'inhumation à l'avance.
Random832
4

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.

altwitt
la source
3

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.

John
la source