<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px"> I think that we end up defining different symbols for different geometries anyway</span></blockquote><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">That's not completely true. The main color could be shared across all geometry types. The point style could be used by linestrings and polygons nodes. The linestring style could be used by the polygon edges. It's more or less how Leaflet does it, and it works fairly well.</span></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:12.8000001907349px">to me it sounds a bit like loading "varchar" and "float" in the same column</span></blockquote><div><br></div><div>That's exactly what it is not. Generic geometry is a valid and well defined type, and postgis functions behave very well with it. ST_Area for instance will return 0 for a point or a line, which is an accurate result and makes sense.</div><div>And while some functions are type-specific, most functions work and make sense on all types (spatial relations, buffer, bounding boxes, validity, transformation, simplification, conversion...).</div><div><br></div><div>If you split your data in different tables (or columns), you loose the ability to use any of those functions on all your records at once (without some complex query that won't be doable in QGIS UI), which IMO is really a pity...</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-04-07 13:21 GMT+02:00 Roy <span dir="ltr"><<a href="mailto:royroge@outlook.com" target="_blank">royroge@outlook.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br>
    <br>
    <div>Il 07/04/2015 11.55, Olivier Dalang ha
      scritto:<br>
    </div>
    <br>
    <blockquote type="cite">
      <div dir="ltr">
        <div>
          <div><u>Event data management</u></div>
          <div>I have a postgis table for historical events, which can
            be of any geometrical type.</div>
          <div>The events can have links to other events (using
            references like previous_event_id).</div>
          <div>Currently, I have to add the postgis table four times.
            Once for each geometry type, plus once as a no-geometry
            table so that I can have the full attribute table to be able
            to use the relations widget.</div>
          <div>At this point, every setting (filtering, labels, actions,
            symbols...) must be made four times,</div>
        </div>
      </div>
    </blockquote>
    <br></span>
    In general I think that we end up defining different symbols for
    different geometries anyway, i do not see how a point and an area
    can have the <br>
    same simbology; also there are specific postgis functions that make
    sense to use for specific geometry (i.e. ST_Area).<br>
    I do not want to say that i'm against the idea of mixing geometries,
    but to me it sounds a bit like loading "varchar" and "float" in the
    same column<br>
    and eventually ending introducing more complications than benefits,
    just my opinion,<br>
    <br>
    best, Roy.<br>
    <br>
  </div>

<br>_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br></blockquote></div><br></div>