<div dir="ltr"><div>So the plot thickens!  In focusing so intently on the problem of .shp file conversion, i've been a bit careless in my consideration of Projects and their related files, but -though some of these projects are history that we can afford to forget- some of them will need to be included in this system migration, in fact. </div><div><br></div><div>SO: I'll need to do some triage on these projects... And then if there be any "project packager plugin" that might facilitate the bundling and migration of those selected projects, i'd love to give such a try.  Any such plugin(s) that you could recommend?</div><div><br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Aug 11, 2020 at 2:26 PM Nicolas Cadieux <<a href="mailto:njacadieux.gitlab@gmail.com">njacadieux.gitlab@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Hi,<div><br><div>People are suggesting that ogr2ogr would work.  That will work with data but NOT with the QGIS projects.  QGIS projects calls various data files in various directories,  if you change the name of a file, the file type, the file directory structure, the project files will indicate that x number of files cannot be found...  The project file contains all the Published maps. </div><div><br></div><div>While most vector data file will be easy to find because of known formats, it will be harder to travers the hard drive for the raster data as formats are similar (like tiff, jpg...) If vector data is stored in .csv or .txt... you will have the same trouble identifying just the spatial data from the rest.</div><div><br></div><div>I hope your user had structure and method in his folders. (Method to the madness....)</div><div><br></div><div>One way could be to scan for the project file and see which ones are important and still open on the old machine.  Then, you could look for a project packager plugin that will save all the needed file in a single directory.  That will unfortunately take lots of manual work and lead to file duplications but at least, you will save the project files that contain a lot of work. I know of no other way to save the project file except to make an exact copy of the hard drive.  I usually, at the very least, make a copy of the hard drive as backup in case the user comes begging two years down the line for a very special project file he can’t find in the new system... </div><div><br></div><div>If all you want is the data, I agree that geopackage and tiff seems like a good options.</div><div><br></div><div>Good luck! </div><div><br><div dir="ltr">Nicolas Cadieux<div>Ça va bien aller!</div></div><div dir="ltr"><br><blockquote type="cite">Le 11 août 2020 à 06:24, Walt Ludwick <<a href="mailto:walt@valedalama.net" target="_blank">walt@valedalama.net</a>> a écrit :<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">I've inherited a legacy GIS, built up over some years in versions 2.x, that i'm now responsible to maintain.  Being an almost complete n00b (did take a short course in QGIS a good few years ago, but still..), i could really use some advice about migration.<br><br>i've created a new QGIS instance in version 3.14, into which i am trying to bring all useful content from our old system: oodles of shapefiles, essentially, plus all those other files (each .shp file appears to bring with it a set of.shx, .dbf, .prj, qpj  files, plus a .cpg file for each layer, it seems).  This is a significant dataset- 14gb, >1000 files -and that is just base data, not counting Projects built on this data or Layouts used for presenting these projects in various ways. Some of this is cruft that i can happily do without, but still:  i've got a lot of porting-over to do, without a clear idea of how best to do it. <br><br>The one thing i'm clear about is: i want it all in a non-proprietary database (i.e. no more mess of .shp and related files) that is above all quick & easy to navigate & manage. It is a single-user system at this point, but i do aim to open it up to colleagues (off-LAN, i.e. via Internet) as soon as i've developed simple apps for them to use.  No idea how long it'll take me to get there, so...<br><br>Big question at this point is: What should be the new storage format for all this data?  Having read a few related opinions on StackOverflow, i get the sense that GeoPackage will probably make for easiest migration (per <a href="https://medium.com/@GispoFinland/learn-spatial-sql-and-master-geopackage-with-qgis-3-16b1e17f0291" target="_blank">this encouraging article</a>, it's a simple matter of drag&drop -simple if you have just a few, i guess! [1]), and can easily support my needs in the short term, but then i wonder: How will i manage migration to PostGIS when i eventually put  this system online with different users/ roles enabled?<br><div><br></div><div>[1] Given that i need to pull in some hundreds of .shp files that are stored in a tree of many folders & subfolders, i also wonder: is there a simple way that i can ask QGIS to traverse a certain directory, pull in all the .shp files -each as its own .gpkg layer, i suppose?</div><div><br></div><div>Any advice about managing this migration would be much appreciated!</div></div>
<span>_______________________________________________</span><br><span>Qgis-user mailing list</span><br><span><a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a></span><br><span>List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a></span><br><span>Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a></span></div></blockquote></div></div></div></blockquote></div></div>