<div dir="ltr"><div>Hi there,</div><div><br></div><div>I have some questions about the role of primary keys when importing / exporting between PostGIS and GRASS. I've been making some tests regarding this process and what follows are my impressions, so they may be wrong in some points.<br></div><div><br></div><div> I fully understand that, given the disparity of data models, simplifications needs to be taken regarding the very complex primary key arrangements (multi column keys, for example) a Relational Database can do, and that going through the GDAL pipeline with an integer autonumber ogc_fid key is the sensible way to go, this is something that can be easily managed.</div><div><br></div><div>However, my workflow implies quite a lot of PostGIS ingested data that goes to GRASS to perform topology cleaning and some other operations and back to PostGIS. In this process, I've notice the following:</div><div><br></div><div>- GDAL ignores the primary key of the database, substituting it with an ogc_fid, when importing into GRASS;</div><div><br></div><div>- when going back to PostGIS, another key comes from GRASS. I'm aware of the FID option to rename the key.<br></div><div><br></div><div>My problem with this is that I lose in the process the original PostGIS table PK. I'm workarounding this by making a physical copy of the PK into another column, so when data is back, I can link original / GRASS processed data. <br></div><div><br></div><div>Then, my question is: is there a way to keep the PK field at PostGIS into the GDAL pipeline as a normal column, so I don't have to duplicate the original PK as I'm doing right now?</div><div><br></div><div>Thank you so much, best regards,<br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr">







<p>---</p><p><span>Juan Pedro Pérez Alcántara</span></p>
<p><span><a href="mailto:jp.perez.alcantara@gmail.com" target="_blank">jp.perez.alcantara@gmail.com</a></span></p></div></div></div></div></div></div></div>