This is a continuation of my previous question about our project on how to economically get away with the implementaion of a graveyard in a GIS system…

On the graveyard we can find

  • Regular graves: up to 2 people
  • Family graves: more than 2, some up to 20 (sisters from a Catholic congregation…)
  • War Monument: about 30 people
  • Ash Scattering Area: unlimitted, starting with 100 people
  • Fields with Burial Urns: up to 2 per spot
  • Walls with Burial Urns: up to 3 in height

So what’s the best way to go, defining:

  • each person as a POINT object
  • each grave as a POINT object, the persons are part of the attributes

I would choose for each person as a POINT object:

  • One simple CSV file for all the persons.
  • Columns could be for example: FirstName – FamilyName – YearDeceased
  • Independent of the number of persons in a grave
  • That way even the ASH SCATTERING AREA can go into the file
  • Eventually some code has to be written to add to the results of a search the other persons burried in the same grave

Complications I see with each grave as a POINT object:

  • Each ROW needs the columns for the maximum number of persons in a grave…
  • That means that a lot of cells will be empty due to just a few graves with a lot of people
  • But what with the ASH SCATTERING AREA? 100 persons require all the additional columns in the table…
  • It is not reasonable to have all the data in one CSV file, but having more files will highly complicate the matter.

So, comments are welcome: person or grave as POINT object? Or none of this and do I need to do it another way?

In my town, 3 years ago, they had a bureau made SHP files for them. I was handed over those files and I noticed that the graves are drawn as POLYGONS. This comes with a DBF file for the ”data of the graves”. The normal graves have 4 sets of coordinates, seems logic. But a few things seem absurd to me:

  • There is an “urn wall” with hexagonal columbaria’s drawn as a set of hexagonal figures… That means that each figure has 6 sets of coordinates…
  • In the “ash scattering area”, there is a pillar with little rectangular nameplates, they have drawn a rectangular POLYGON for each nameplate with 4 sets of coordinates… To me, using POLYGONS in these cases seems so much overkill in the database.

Besides that, correct me if I’m wrong, using:

  • POLYGONS requires DBF files, so a DBF editor (extra costs)
  • POINTS only requires CSV files, so EXCEL is enough (no extra costs)

In most towns, the data of the deceased persons come in a CSV file:

  • made directly in EXCEL or
  • exported form a DOS based program, made when WIN95 was still around…

Continuing to manage the “data of the persons” in one CSV file and EXCEL avoids:

  • buying software that can edit DBF files
  • worrying about importing the “data of persons” into the DBF file It seems not always to be without a hassle to import, edit and save data from CSV into DBF files and have NO corruption of your data. I read that this can be the case especially when working with ArcGis (ESRI).
  • @DenaliHardtail - One plot can have multiple markers. Consider war veterans that have both a traditional headstone and a military plaque at the foot.
    – user51323
    Commented Apr 29, 2015 at 18:37
  • 2
    Answers are likely to be heavily opinion-based without more specific details about software and use (for example, if you go the related table route, does your web mapping software/server support such querying?). The root question, point per grave vs person is simple - person, no question. Point/grave with multiple people attributes is a bad idea, because it is poor database design for many reasons already mentioned. But to ask 'do it another way' makes it again too broad and opinion-based. I would do points and areas ideally, but just points if keeping it simple.
    – Chris W
    Commented Apr 29, 2015 at 19:32
  • 1
    Also, QGis can edit shapefiles (including .dbf), OpenOffice can edit .dbf, they're both free. Commented Apr 30, 2015 at 13:50
  • 1
    This question seems to be spiraling. Please remember GIS.SE is best as focused, one question per question that can be answered in at most a few paragraphs. As it stands, this whole Q&A is really better suited to a chat than a Q&A. Yes, some of the data organization you describe in the shapefiles given to you seems odd/overkill/poor design. Your understanding of points vs polygons and requiring a dbf is flawed (you may want to investigate the components of a shapefile), and at best your impression of csv issues with ArcGIS is skewed. CSVs aren't spreadsheets, spreadsheets aren't databases.
    – Chris W
    Commented Apr 30, 2015 at 20:38
  • 2
    (Continuing) Text files, spreadsheets, databases, and in particular spatial databases have different capabilities and ways of operating. It sounds like you need to decide if you want to use GIS at all, or just stick with web mapping based on text based files that contain point coordinates. QGIS is free, can do all the things you're wanting from a GIS perspective, and those things are relatively easy to learn. The web mapping component is another story.
    – Chris W
    Commented Apr 30, 2015 at 20:40

4 Answers 4


I would go the complicated way: Two Tables in a 1:n relation

  • one table with the point location of the graves
  • another table with the Grave-ID and person data

You can build a relation between the two tables so that selecting a grave will select all person records in the person-table.

The idea of having tables with fields like Person1, Person2... is horrible and bad design.

  • That's not complicated. That's properly modeling your data! +1 for good relational design.
    – jpmc26
    Commented Apr 29, 2015 at 23:03
  • That's also what I thought. But I'm not familiar with the "relation building", I'm not at all a GIS expert. Would have to examine/study that... Guess it is possible in QGIS... Commented Apr 30, 2015 at 9:45
  • @Patrick - Load your shapefile and a dBase file into QGIS, bring up the properties dialog of your shapefile, select Joins and build a join between you dBase and shape data. Try playing around a bit to get familiar with it.
    – tookarf
    Commented Apr 30, 2015 at 14:03

I would create a polygon for the grave since the grave itself is a plot of land and have a one to many relationship for the people; one grave can have zero (unoccupied, available, or for sale ?) or many people. You could also use a point instead of the polygon. Polygons would make better presentations for sales and maintenance.

  • 2
    I'm not in the graveyard business, but I like being as thorough as possible. I would include the plots/scattering fields/monuments as polygons as well as having points for grave stones.
    – JasonT
    Commented Apr 29, 2015 at 18:10
  • @JasonT that's a good point. Can a plot (the land) contain multiple grave stones / markers if multiple people are buried in the plot? I agree, each marker is it's own point. Commented Apr 29, 2015 at 18:14
  • 1
    A plot could have an owner without being occupied, if someone has made their burial arrangements in advance.
    – Random832
    Commented Apr 29, 2015 at 20:26

I would take DenaliHardtail's suggestion of using polygons to represent accurate sizes of the plots. This layer could have a table with Grave_ID, Grave_Type, Grave_Capacity, and Grave_Occupancy_Number. Then you could have a point layer with points overlying the corresponding grave polygons. Columns for the point layer table could be Person-ID, First_Name, Family_Name, Birthdate, Deathdate, Graveowner, and Grave_status (Sold, Unoccupied, etc.). You could then include the corresponding Grave-ID for each person so you could match person to grave and create a single excel table later on with all the grave and individual person info.


Normalizing the data leads me to some missing ideas/points. Also, I think Excel can do everything you want for the "database" you contemplate. Hint: Use sheets, or multiple files and use variations of Lookup functions. Save into the useful file(s) for imports/lookups from QGIS

I envision these discrete tables [or excel sheets], to start off your data set. Each Sheet/file is easily maintained by novice users, as long as the columns are clearly given (and are frozen as a top row...), and novice is reminded that the IDs are unique and remain unchanged once assigned. The sheets and columns:

  1. PlotDescription - columns include: PlotID (ties to polygon), ownerID, plotTypeID (the plot type: grave, wall, crypt, etc.). This sheet is generally static, until one creates a new plot.
  2. Owner -- ownerID, columns with full description (name/ContactAddress/etc), deceased (T/F). I envision that if you have multiple owners, they are listed in full in the name field, and you would have one contact address
  3. Deceased -- DeceasedID, PlotID, full name/etc/other identifying data, elevationCode. The DeceasedID isn't found elsewhere so far, but good form creates a unique ID for each deceased; could be useful in expansions to the data -- for example, a list of relatives living for events or marketing.
  4. ElevationCode -- ElevationID and then a short description ("inGround", "inCrypt", "first row", "second row", "ash pile", etc). This sheet is generally static
  5. PlotType -- PlotTypeID and a short description -- crypt, grave, etc. This is a static sheet

For the mindset of the Novice, I don't suggest you fully normalize the identity issues and their columns, in the way they overlap between owners and deceased, and it creates unnecessary 1-many ancillary tables with nothing but various IDs. I envision a 1-to-1 between plot and owner tables, as a compromise for simplicity

I think this generalized set up will address issues such as: ash piles, wall crypts, owner/maintainer tracking, multiple deceased in a plot, and more.

Finally, remember to create a few, permanent rows in the two tables/sheets for owner and deceased: unknown owner; unknown deceased; unknown multiple deceased; owned by cemetery; not owned; etc.

Not the answer you're looking for? Browse other questions tagged or ask your own question.