[Qgis-user] [PROPOSAL] From srs.db to file-based CRS storage

[David Fawcett]

I am definitely not advocating for a switch to a different CRS database.

I would guess that the SQLite solution performs better than proj.4 as
well.  On recommendation for improving performance in applications
like MapServer that use proj.4 is to delete out the SRS definitions
that you will never use...

David.

On Mon, Jan 30, 2012 at 3:07 PM, Andreas Neumann <a.neumann at carto.net> wrote:
> Well - in my opinion, if one really wants to edit CRS it would be best
> to document the process well in the manual and leave the CRS storage  as is.
>
> 1. - one doesn't need to edit the definitions very often
> 2. - one needs to do it very carefully. CRS definitions are far more
> complex than SQL in my opinion. You really need to know what you do or
> your data will end up corrupted.
> 3. - SQLite databases are very accessible. Even QGIS can be used to open
> and edit the tables. SQLiteMan comes with every Linux distribution and
> also as a firefox plugin.
> 4. - with SQLite, the data is at least structure. With text-based
> formats you need to parse the format and you open doors for mistakes and
> unstructured data.
> 5. - if definitions are missing, people should contribute them to the
> project so others can use them as well.
>
> Just my two cents.
>
> Andreas
>
> On 01/30/2012 09:31 PM, Alexander Bruy wrote:
>> Hi Andreas,
>>
>> 2012/1/30 Andreas Neumann <a.neumann at carto.net>:
>>> srs.db is file-based already. You can easily edit and update it with any
>>> sqlite compatible db application, such as sqliteman, openoffice, qgis,
>>> firefox, etc.
>>
>> Working with sqlite requires SQL knowledge and database manager/editor,
>> while moving and editing flat text files is much easier for ordinal users.
>>
>
> _______________________________________________
> Qgis-user mailing list
> Qgis-user at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-user