[mapserver-dev] Fwd: Common SQLite-based dictionaries

[Jeff McKenna]

Forwarding to MapServer-dev...


-------- Forwarded Message --------
Subject: [Proj] Fwd: [MetaCRS] Common SQLite-based dictionaries
Date: Sun, 02 Aug 2015 17:14:54 +0200
From: Even Rouault <even.rouault at spatialys.com>
Reply-To: PROJ.4 and general Projections Discussions 
<proj at lists.maptools.org>
Organization: Spatialys
To: gdal-dev at lists.osgeo.org, qgis-developer 
<qgis-developer at lists.osgeo.org>, GRASS-dev <grass-dev at lists.osgeo.org>, 
proj at lists.maptools.org, geotiff at lists.maptools.org

Forwarding to a few lists that might be interested in the below proposal as
metacrs is perhaps not widely followed. But please keep the discussion to
metacrs to avoid cross postings.

----------  Forwarded Message  ----------

Subject: [MetaCRS] Common SQLite-based dictionaries
Date: Sunday 02 August 2015, 08:15:12
From: Howard Butler <howard at hobu.co>
To: metacrs at lists.osgeo.org

All,

libgeotiff and GDAL all use a system of bespoke CSV files for their 
coordinate
system dictionaries. proj.4 uses derived dictionaries made from GDAL's. 
Each
is a slightly different subset and/or mix of the EPSG db along with other
catalogs, customizations, and overrides. The situation is messy, 
fragile, and
incomplete, especially for folks like me, who are interested in support of
ever more complex systems of horizontal and vertical datums, time epochs
associated with them, and direct transformation.

There have been multiple attempts to build a C tribe API that handles the
coordinate system description problem, but all have failed for various
reasons.The one true library to rule them all is probably a pipe dream, but
maybe it is possible to collaborate in a slightly messier way -- at the
dictionary level.

One significant technology that was not widely available when GDAL, 
proj.4, and
libgeotiff all originated is SQLite. The idea of a single file, sql'able
database is a standard assumption in today's software, especially in things
like HTML5 (wars between WebSQL and IndexedDB), just about every 
significant
phone application, and your favorite OGC super format [1].

I'd like to propose an attempt to standardize the GDAL, proj.4, and 
libgeotiff
SRS coordinate system handling dictionaries on a SQLite database that 
starts
with EPSG, with each project adding its own auxiliary tables as 
necessary. I
am writing this message to MetaCRS to see if there is support for such an
effort, and to determine if there are other related projects who would 
like to
collaborate at this level.

For the GDAL stack, the benefits of this approach are significant. Multiply-
defined, potentially conflicting definitions no longer need to be 
resolved. The
dictionaries could release on their own schedule, rather than with each
individual project. Powerful new functionality would be much closer to
software developers instead of hidden behind a rather opaque and fragile 
CSV
dictionary generating process. Mundane but important details like
multithreaded access get handed off to a library and project who do that 
stuff
all the time instead of one-off implementations inside of each individual
project.

Database views/queries could be standardized for common lookups across.
Lookups would be faster due to indexed query access. Transformation
validation, based on EPSG or other databases, could be provided across all
three projects. More complex topics, like those described above, could be
developed in a way that have impact across all three projects without 
tedious
implementation.

Consider this email a mix of

1) is this a good idea? What other benefits do you see this approach 
providing?
2) Does your project want to collaborate on this?
3) Does this belong in MetaCRS?
4) What are the pitfalls that make this untenable?

windmill-tilting'ly yours,

Howard

[1] http://www.geopackage.org/