[Proj] Use of SQLite

Greg Troxel gdt at lexort.com
Mon May 21 09:13:14 EST 2018

A few comments:

  proj needs to be portable, and that precludes shipping a sqlite3
  binary file.  Presumably the source code will contain either some text
  file that is loaded as part of the build process, and binary packages
  will have binary sqlite3 files?  Or something else?

  (Assuming source file at build time) It's unclear if you mean the
  source file to be a sqlite3 db dump, and if that will be in the VCS,
  or something else?   There seems to be merit in having a simple csv
  format in the source tree.   But perhaps sqlite3 dump is the new
  lingua franca.

  (not entirely related) My impression is that the EPSG database is
  non-Free, and I wonder if the "modified version" becomes free, or if
  this is still an issue to resolve.

  Have you thought about the minimum version?  I am unclear how many
  systems include sqlite in the base system, and at which versions.  So
  if proj were able to work with fairly old sqlite (even if you would
  recommend that people have newer), that would be good.   Basically,
  from a packaging viewpoint, while newer is usually better, it's
  preferred to have as few forcing functions in the dependency graph as

  I don't entirely follow the notion of using some other db.  The nice
  thing about sqlite is that it's linked in and you don't need to
  configure a db username and have a process running.  Once you do that,
  things are much harder and more fragile, and there are security issues
  if the db doesn't default to listening only on localhost.   But I can
  see the idea that some might want this.   One Option might be for postgis
  to read the proj db at build time, and essentially shadow it, which
  would involve  a way to read out the db -- which would be nice to not
  be in sqlite dump language.

More information about the Proj mailing list