I'm trying to import shapefile data into a geospatial PDF using OGR and Python.

My shapefiles are structured as follow: shapefile1.shp: {stratt1: string1, intatt1: 1, ...} and shapefile2.shp: {stratt2: string2, intatt2: 2, ...}

Shapefile1 and Shapefile2

From the documentation and other answers in SO I found the OGR_DISPLAY_FIELD=name command, but it only works for one shapefile. Thus, if I import several shapefiles at once, I get only feature1, feature2, feature3 and so on at the feature tree, as it can be seen in the following image:

enter image description here

This is odd, because with OGR_DISPLAY_LAYER_NAMES=names I'm able to change the layer name of several shapefiles at once like OGR_DISPLAY_LAYER_NAMES= "points1, points2", but I had no luck finding a way to do the same for the features. Any ideas?

Because I'm doing it with Python, my code looks like this:

co = ["OGR_DATASOURCE=" + vrt, "OGR_DISPLAY_FIELD=" + "sat1, sat2"]
gdal.Translate(outpath, imagery, format="PDF", outputSRS="EPSG:4326", creationOptions=co)

(Again, the part failing is the "OGR_DISPLAY_FIELD=" + "sat1, sat2" one)

My VRT file (called vrt above):

    <OGRVRTLayer name="points1">
        <SrcDataSource relativeToVRT="1">shapefile1.shp</SrcDataSource>
        <SrcSQL>SELECT stratt1 AS sat1, intatt1 as inat1 FROM shapefile1</SrcSQL>
    <OGRVRTLayer name="points2">
        <SrcDataSource relativeToVRT="1">shapefile2.shp</SrcDataSource>
        <SrcSQL>SELECT stratt2 AS sat2, intatt2 as inat2 FROM shapefile2</SrcSQL>

Any ideas how could I achieve my goal with only one gdal.Translate() call?


In the screenshot of the PDF you can see that every feature in points1 is displayed as string1, the attribute from the column stratt1 in shapefile1. This is correct.

In the screenshot of the PDF you also can see that every feature in points2 is displayed as feature1, feature2, feature3... and so on. This is NOT correct. It should be called string2 following the same principle as above.

I can´t do "OGR_DISPLAY_FIELD=" + "sat1, sat2" because OGR_DISPLAY_FIELD=name doesn´t take lists, nor it is possible to call it two times in the creationOptions of gdal.Translate()

Edit to @cm1's answer

enter image description here

  • If you are most interested in the end result it should be enough to edit the OGRVRTLayer names in the VRT file. – user30184 Apr 20 '18 at 6:43
  • Right, I can use <OGRVRTLayer name="shapefile1" in the VRT file instead of OGR_DISPLAY_LAYER_NAMES = shapefile1 in the creationOptions of gdal.Translate. This doesn´t solve the main problem though, as in the PDF tree the attributes keep appearing as feature1, feature2 and so on. For one shapefile I could use OGR_DISPLAY_FIELD=strattribute1 and it would work perfectly, but if I have more than one in my VRT file I can´t figure out how to get the attribute names right – Iridium Apr 20 '18 at 10:59
  • You seem to have in data strattribute_1 but in code you use strattribute1. Is that typo in your question? And when you have done SELECT *, strattribute_1 AS at1 you have a layer with name "at1". Check the layer names with ogrinfo my.vrt. I wonder if the tutorial that is referred in gdal.org/frmt_pdf.html is still valid but if could be worth a look. – user30184 Apr 20 '18 at 11:11
  • That was a typo in my question. I edited my question overall, I hope it´s more understandable now. The layer in SELECT *, strattribute_1 AS at1, after the edit now SELECT stratt1 AS sat1, is used in "OGR_DISPLAY_FIELD=" + "sat1" and works properly. But I just can´t figure out how to do the same for "OGR_DISPLAY_FIELD=" + "sat2" at the same time – Iridium Apr 20 '18 at 13:14
  • Try to add double quotes like this: co = ["OGR_DATASOURCE=" + vrtFixed, "OGR_DISPLAY_FIELD=" + "\"strattribute_1, strattribute_2\"", "OGR_DISPLAY_LAYER_NAMES=" + "\"streets, points\""] – Kadir Şahbaz Apr 20 '18 at 13:14

More of a comment here (I wanted to include an image). What about trying the following approach? Note casting the columns to a unique alias (i.e. stratt1 and stratt2 to 'sat', etc.):

ogr.vrt changes


|improve this answer|||||
  • That actually works! I´m giving you an upvote for your answer, because that trick might help others with the same question. I edited my question adding a picture of the output implementing your solution. Unfortunately this approach implies some beforehand preprocessing with GDAL which could be tricky to implement if someone has to achieve a standarized output (like in my case), but as long as the devs don't implement a better support for OGR_DISPLAY_FIELD this is definetly the way to go! Thanks! P.D: I´m going to need some time thorougly testing this approach, will keep updating! – Iridium Apr 23 '18 at 8:40

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.