<div dir="ltr">A disruptive "moreover approach" suggests some reflection about the file <vs> database approach.<div><br><div>I see several places where handling metadata in the database could provide a better but possibly conflicting solution.</div><div>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.</div><div><br></div><div>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?).</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>It's reasonable to blame my "moreover approach", but take what you think QGIS could benefit of.</div><div>c</div><div><br></div><div><div class="gmail_extra">-- <br><div class="gmail_signature" data-smartmail="gmail_signature">--------------------------------------------------------------------------<br>Carlo A. Bertelli<br> Charta servizi e sistemi per il territorio e la storia ambientale srl <br> Dipendenze del palazzo Doria, <br> vc. alla Chiesa della Maddalena 9/2 16124 Genova (Italy)<br> tel./fax +39(0)10 2475439 +39 0108566195 mobile:+39 393 1590711<br> e-mail: <a href="mailto:bertelli@chartasrl.eu" target="_blank">bertelli@chartasrl.eu</a> <a href="http://www.chartasrl.eu" target="_blank">http://www.chartasrl.eu</a><br>--------------------------------------------------------------------------<br><br><br><br></div>
</div></div></div></div>