<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 2014/03/02 19:13, Tim Sutton wrote:<br>
</div>
<blockquote
cite="mid:CALCNqkYYJaKUTx9+u1rvU6HwWUR_-4Rs0TfMN94Fef+9p1S6=g@mail.gmail.com"
type="cite">
<div dir="ltr">Hey Zoltan</div>
</blockquote>
Hi Tim,<br>
Long time no chat......<br>
<blockquote
cite="mid:CALCNqkYYJaKUTx9+u1rvU6HwWUR_-4Rs0TfMN94Fef+9p1S6=g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sun, Mar 2, 2014 at 4:59 PM,
Zoltan Szecsei <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:zoltans@geograph.co.za" target="_blank">zoltans@geograph.co.za</a>></span>
wrote:<br>
<div><br>
</div>
<div>8<---------------------snip---------------------------------</div>
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
Please consider this methodolgy:<br>
Currently, when QGIS loads a map layer, certain default
things happen: Styles get assigned, etc etc.<br>
As a maplayer is loaded (or perhaps only when the user
changes something (like style)), QGIS should dump a
[maplayername].qgis file, text format, perhaps
keyword-value layout, into the directory that the map is
stored. This file will then contain all the internal
QGIS defaults, and of course updates to the current
(style ) status, as the user changes them.<br>
The benefits of using this implementation scheme could
be vast:<br>
<ul>
<li>For deployment purposes, users could create/edit
this file outside of QGIS</li>
<li>QGIS Dev could implement a methodology whereby
user scripts could read and write to this maplayer
specific file - for example: map production
information whilst capture staff are creating
features.</li>
<li>This file could even be designed to live at the
project level, and at the user level - this way
departmental level defaults could be set (deployed),
and for those users who need it, these could be
over-ridden by having that filename als local to the
user, but with user specific values.<br>
</li>
<li>Should any of these filenames only have some of
the default keyword-values, QGIS could look for the
other defaults at higher filename level (ie project
level if user-level does not exist), or as
currently, at the internally stored default actions.</li>
</ul>
<p><br>
</p>
</div>
</blockquote>
<div>And the downsides could be (if I understand your
proposal correctly):</div>
<div><br>
</div>
<div>* Working on a shared file store you are going to wreak
all kinds of havoc with user experience as different users
overwrite the same file concurrently</div>
</div>
</div>
</div>
</blockquote>
Too true. But that's the same as if two users tried to edit the same
map layer on a central server, from two different clients, so it
would have to be implemented with the same locking or shared update
mechanism that the map layer itself is enjoying.<br>
<blockquote
cite="mid:CALCNqkYYJaKUTx9+u1rvU6HwWUR_-4Rs0TfMN94Fef+9p1S6=g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>* Working with a read only directory it obviously wont
work</div>
</div>
</div>
</div>
</blockquote>
duh... :-)<br>
<blockquote
cite="mid:CALCNqkYYJaKUTx9+u1rvU6HwWUR_-4Rs0TfMN94Fef+9p1S6=g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div>* Working with remote datasources (PostGIS etc.) it
won't work</div>
</div>
</div>
</div>
</blockquote>
Yes, there will always be situations where this won't work, but then
QGIS could fall back to it's current methodology.<br>
<br>
<blockquote
cite="mid:CALCNqkYYJaKUTx9+u1rvU6HwWUR_-4Rs0TfMN94Fef+9p1S6=g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> The above implementation strategy would not need a
special "export" menu as the information would then
always be stored in a user useable file.<br>
If this file becomes corrupt or nonsensical, QGIS
actions could revert to the default internal actions.<br>
</p>
<p>As time goes by, I reckon QGIS developers would find
many more uses for this map-layer specific file
mechanism, should it be available.<br>
</p>
<p>Hope I'm making sense.<br>
</p>
</div>
</blockquote>
<div><br>
</div>
<div>Not completely for me :-)</div>
</div>
</div>
</div>
</blockquote>
True - my fault. I work with simplistic file types (mainly
shape-files), as my clients dictate what I have to capture and
deliver in. This mechanism would work well for Shape files, because
they don't support concurrent editing, and thus the .qgis file I am
thinking of, would also not have to worry about concurrent updates.<br>
Incidentally, I implemented exactly this sort of status tracking
with scripts in my proprietary GIS package, and it worked really
well, so, truth be told, I am missing this facility when using QGIS.<br>
Cheers for now,<br>
Z<br>
<blockquote
cite="mid:CALCNqkYYJaKUTx9+u1rvU6HwWUR_-4Rs0TfMN94Fef+9p1S6=g@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Regards</div>
<div><br>
</div>
<div>Tim</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF">
<p> </p>
<p>Kind regards,<br>
Zoltan<br>
</p>
<div class=""> <br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<pre cols="72">--
===========================================
Zoltan Szecsei PrGISc [PGP0031]
Geograph (Pty) Ltd.
GIS and Photogrammetric Service
P.O. Box 7, Muizenberg 7950, South Africa.
Mobile: <a moz-do-not-send="true" href="tel:%2B27-83-6004028" value="+27836004028" target="_blank">+27-83-6004028</a>
Fax: <a moz-do-not-send="true" href="tel:%2B27-86-6115323" value="+27866115323" target="_blank">+27-86-6115323</a> <a moz-do-not-send="true" href="http://www.geograph.co.za" target="_blank">www.geograph.co.za</a>
===========================================</pre>
</div>
</div>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a moz-do-not-send="true"
href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
<div dir="ltr">Tim Sutton - QGIS Project Steering Committee
Member<br>
==============================================<br>
Please do not email me off-list with technical<br>
support questions. Using the lists will gain<br>
more exposure for your issues and the knowledge<br>
surrounding your issue will be shared with all.<br>
<br>
Irc: timlinux on #qgis at <a moz-do-not-send="true"
href="http://freenode.net" target="_blank">freenode.net</a><br>
==============================================</div>
</div>
</div>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">--
===========================================
Zoltan Szecsei PrGISc [PGP0031]
Geograph (Pty) Ltd.
GIS and Photogrammetric Service
P.O. Box 7, Muizenberg 7950, South Africa.
Mobile: +27-83-6004028
Fax: +27-86-6115323 <a class="moz-txt-link-abbreviated" href="http://www.geograph.co.za">www.geograph.co.za</a>
===========================================</pre>
</body>
</html>