A disruptive "moreover approach" suggests some reflection about the file
<vs> database approach.

I see several places where handling metadata in the database could provide
a better but possibly conflicting solution.
This happens for instance with styles stored on the database that may
easily be overwritten by opening a modified project (if you work alone it's
wonderful, but cooperating is a nightmare), but may happen also with any
other "intelligent" provision that uses XML and/or persistent storage.

I think this should not prevent a good solution about metadata. A map is
not made of several layers overlaid with their styles only, it's something
more and it's not completely satisfactory to reduce this to a project file
that helps a single user to keep working on it or store the printing styles
(sorry, I simplify too much, I know). Maybe QGD files are a starting point
to design a better solution because we are embracing a three level storage
system: files, light database (SQLite/Spatialite), DBMS (mainly
PostgreSQL/PostGIS, but even others). This solution could lead us to a
careful choice or to more flexibility (complexity?).

Maybe this further flexibility is needed. I raise a very peculiar case: we
work with historical maps and sometimes I georeference maps without being
certain about my sources, sometimes the source itself is made of parts that
ask two set of conflicting reference points for the same file. I'm forced
to make a symlink on the filesystem to have the same file georeferenced in
two ways. Why the different point sets cannot be stored on database? The
reference points are points on earth and frequently I need to reuse them
(what about adjacent tables? Maybe snapping on them could help), why not
storing them in the database?

QGIS Server is an amazing tool, but why using monolithic and completely
proprietary XML file while several other applications could benefit from
more generic metadata stored in the database? That is already done for
styles which store SLD values besides the Qt ones, but it could be extended
to other areas.

It's reasonable to blame my "moreover approach", but take what you think
QGIS could benefit of.

Carlo A. Bertelli
   Charta servizi e sistemi per il territorio e la storia ambientale srl
          Dipendenze del palazzo Doria,
          vc. alla Chiesa della Maddalena 9/2 16124      Genova (Italy)
          tel./fax +39(0)10 2475439  +39 0108566195  mobile:+39 393 1590711
   e-mail: berte...@chartasrl.eu      http://www.chartasrl.eu
QGIS-Developer mailing list
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

Reply via email to