1

I want to know whether it is possible to have more than one row of the dbf file that comes with a shapefile map linked to the same feature of such shapefile. The reason for that is simple: to have datasets in the long-format with the shapefiles.

In case, as I suppose, it is not possible, I will still give more details below so someone might suggest good alternatives.


Suppose you have individual shapefile maps of countries' administrative divisions (AD), i.e. one shp file per country. Now, you have information that you want to save per countries' AD for multiple years, given that information is available for different years depending on the country.

The first naïve temptation would be to organize the dbf of the shapefile map in the wide-dataset format, similarly to the following:

enter image description here

The problem with such an approach is that, as I mentioned, each country has INFO on different years. Thus, in case we later want or need to merge countries together in one single world-map, this will become a mess of many variables each covering just a few countries. In a trivial, non-spatial dataset, the solution would be to simply adopt a long-format for the dataset, like the following:

enter image description here

That would be the ideal solution, because then all the dbf of countries' shapefiles would have the exact same variables, with same names, so merging multiple countries would become easy and intuitive. However, for that one would need more than one row of the dbf pointing to the same map feature (in this case, to the same AD of countries).

That is why I ask:

1) is such a thing possible somehow, i.e. to create shapefile maps that have more than one row linked to the same feature of the same map?

If not at all possible:

2) are there any alternatives? I have considered geodatabases but want to avoid file formats that require proprietary format to be read.

My last resource would be to just have two dbfs per country, one with the variables "Country" and "AD" in example I give here, and another with "YR" and "INFO" in long-format, both linked with an ID of some sort. But I am looking for more elegant ways of doing so if any is available.

  • 2
    Your summary is correct. It is not possible with shapefiles. Everything you would have to do would not be standard compliant and therefore not usable for the available software without building the adjustments for any system. Your conclusion is correct as well, beside one point. Why you don´t use open source geodatabases? Like SpatiaLite that can do what you want (views, 1:n relations). Or GeoPackage which is a OGC standard. – Matte Mar 3 '17 at 7:00
  • 1
    I agree with everything @Matte says - also why not use a real database like postgis and create views. – Ian Turton Mar 3 '17 at 9:05
  • You can't bend a single twenty-something year old dsta format into something it isn't. Any database would let you create a pair of tables, but you can also model this with a join or relation on a dBase or flat file. – Vince Mar 3 '17 at 10:49
1

It looks like your 2nd option is really your only option. As @Matte said, what you are asking is not possible with a shapefile format. The format is based on a one to one match between spatial records and attribute data. If that is changed, the shapefile will be corrupt, and not readable in some GIS packages.
Your option #2 is really the best, though I wouldn't consider it an alternative format. Moving to a spatial database like the Geopackage if you need something portable, or PostgreSQL if you want something more robust, is actually moving more towards a current standard, than the shapefile is.
I think that while having all the data in one table, both spatial and attribute, you may find its utility limited when you try to use it for anything more than simple viewing and sorting. The situation you describe is actually when the 2 table solution is the most appropriate, and elegant, if you will. One of the key tenets of GIS is the elimination of duplication of data. If you have all the data in one table, you will be duplicating something, whether the same spatial data copied in each row, or some other attribute. Having a table for the spatial data, with an ID, and referencing that in an attribute table, as you mentioned, lets you have as many records as necessary linked to each feature, while still only having one copy of the spatial information. I encourage you to check out both of the database formats listed above. There is a lot of documentation about Postgres, and I would imagine a smaller, but growing amount about the GeoPackage, as it is a newer format.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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