<div>Hi Matthias</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 29, 2012 at 3:32 PM, Matthias Kuhn <span dir="ltr"><<a href="mailto:matthias.kuhn@gmx.ch" target="_blank">matthias.kuhn@gmx.ch</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think rendering one at a time is enough (as in my first mail: one as the default to display), with time one could include fun stuff like LOD, subitems in the layer legend, or whatever somebody might come up with ( intersection etc).<br>

<br>
More interesting for me is the possibility to access additional geometry columns from a plugin, and therefore having the dataProvider ready for this.<br>
<br>
The idea of having multiple layers, pointing to the same table sounds interesting as well. This would probably mean separating the pretty strong linkage between layer (as representation) <=> table (as data), we've got now.</blockquote>
<div><br></div><div>So right now we have QgsFeature that contains ID, attributes and a geometry. I think we should keep that as-is because this is what is usually expected from a layer.</div><div><br></div><div>In order to support multiple geometries per feature, we could possibly allow QgsGeometry class as another attribute type (next to int, double and QString). So providers like postgis that support multiple geometry columns could return additional geometries wrapped as attributes in QVariant. Would that work for you?</div>
<div><br></div><div>Martin</div><div><br></div></div></div>