[Proj] Use of SQLite

[Kurt Schwehr]

Sorry I haven't chimed in sooner.  Going with SQLite is certainly fine for
my particular env.  Here is what I would like if at all possible:

* The option to have just one copy of the database per binary.  So shared
across PROJ through GDAL and PostGIS
* Be able to compile in the database within the binary and use if from
memory

My env is typically statically linked binaries with one binary per
container and no local disk.  I currently have an C data block with the
data that I write to vsimem and read from there.  My solution uses some
non-public code.  An SQLite in-memory database that the entire community
could use (if selected at build time) would be nicer.   I'm sure other
folks would appreciate the option to not need extra files.

A single copy means they are going to be consistent and have a bit smaller
memory footprint.

On Mon, May 21, 2018 at 9:11 AM, Martin Desruisseaux <
martin.desruisseaux at geomatys.com> wrote:

> Le 21/05/2018 à 17:49, Howard Butler a écrit :
>
> Sticky philosophical issues aside, from a practical standpoint, an
> industry that wants late-binding out of the GDAL/PROJ/Friends stack must
> recognize that the dictionaries are a critical piece of infrastructure to
> make it all work. EPSG's licensing approach seems to me like good
> intentions mixed with inexperience in open software licensing. It would be
> instructive to explicitly hear what EPSG was trying to prevent with its
> licensing approach rather than trying to legal wrangle their license
> without the context.
>
> This topic has been discussed (in a wider context - not specifically EPSG)
> in the Open Geospatial Consortium (OGC). They came with the definition of
> Open Standard, which is similar to Open Source Software but not identical.
> The OGC API white paper [1] defines an Open Standard as:
>
>    1. Freely and publicly available – They are available free of charge
>    and unencumbered by patents and other intellectual property.
>    2. Non discriminatory – They are available to anyone, any
>    organization, any time, anywhere with no restrictions.
>    3. No license fees - There are no charges at any time for their use.
>    4. Vendor neutral - They are vendor neutral in terms of their content
>    and implementation concept and do not favor any vendor over another.
>    5. Data neutral – The standards are independent of any data storage
>    model or format.
>    6. Defined, documented, and approved by a formal, member driven
>    consensus process. The consensus group remains in charge of changes and no
>    single entity controls the standard.
>
> Note that above definitions does not include the right to modify the
> standard; the changes are controlled by a standard body. The reason is that
> if anyone was allowed to change a standard, then it would not be a standard
> any more. Note that this definition of "Open Standard" has been done
> collaboratively with OSGeo [2].
>
> So I think that IOGP sees the EPSG dataset as something closer (but not
> fully compliant) to Open Standard than Open Source. I had a chance to
> discuss with Roger Lott (an EPSG maintainer) during various OGC meetings,
> and my understanding is that their main concern is to make sure that
> everyone interpret EPSG codes in the same way. I mean that coordinate
> operations performed between the same pairs of EPSG codes shall produce the
> same results (up to the accuracy allowed by the operation) with any
> standard-compliant software.
>
>     Martin
>
> [1] http://docs.opengeospatial.org/wp/16-019r4/16-019r4.html#_open_standards_and_apis
> [2] https://wiki.osgeo.org/wiki/Open_Source_and_Open_Standards#Open_Standards
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20180521/3cc9899d/attachment.htm