<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Grazie mille a tutti per le illuminanti
      delucidazioni. Mi chiedo solo perché alcune procedure ti chiedano
      "certe" precisioni che poi in uno shapefile definito "di consegna"
      non possono essere mantenute.....transeat!<br>
      <br>
      Saluti<br>
      <br>
      On 12/02/2014 15:04, Jody Marca wrote:<br>
    </div>
    <blockquote
cite="mid:%3CCAC=PJqnXx8AQs3RXGDpt3ZHAyJnjAww8Hkkce2A3P_EhPzy=1w@mail.gmail.com%3E"
      type="cite">
      <div dir="ltr">
        <div>
          <div>
            <div>
              <div>Solo una precisazione<br>
              </div>
              io NON sono favorevole ad una migrazione da double ad un
              datatype diverso, quello che ho detto era un modo per
              risolverle il problema perchè è causato dal formato di
              memorizzazione che non consente l'utilizzo di una griglia
              omogenea<br>
              Sono sfavorevole non tanto per motivi prestazionali, anche
              se condivido pienamente quanto scritto da Sandro, ma
              perchè si dovrebbero aggiornare tutti gli applicativi ed
              abbandonare gli shapefile cosa che ad oggi penso sia pura
              fantasia...<br>
            </div>
            Come ho già detto il mio consiglio, e approccio abituale, è
            quello di applicare un'arrotondamento omogeneo su tutto il
            dataset dei dati poichè il problema non è marginale. <br>
            --> Test: SELECT ST_equals(ST_GeomFromText('POINT(0 
            543523.124)'), ST_SnapToGrid(ST_GeomFromText('POINT(0 
            543523.124)'), 0.001)  );<br>
            Se uso l'operatore ST_Equals passando come primo parametro
            il punto POINT(0  543523.124) e come secondo parametro lo
            stesso punto dopo lo l'arrotondamento potrei ottenere false;
            lo stesso problema potrebbe quindi creare sliver polygon,
            reti non connesse, touch che diventano overlap o disjoint...<br>
          </div>
        </div>
        I sistemi commerciali solitamente aggirano il problema con la
        valutazione con tolleranza; resta perà da capire che cosa si
        intende per tolleranza poichè può essere implementata in n modi
        diversi (ma questa è un'altra storia e non vorrei aprire il vaso
        di pandora...)<br>
        <div>
          <div><br>
            Jody<br>
            <br>
          </div>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">2014-02-12 12:38 GMT+01:00 <span
            dir="ltr"><<a moz-do-not-send="true"
              href="mailto:a.furieri@lqt.it" target="_blank">a.furieri@lqt.it</a>></span>:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div class="">On Wed, 12 Feb 2014 12:11:06 +0100, Jody Marca
              wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                Come fare a risolvere questi problemi? Semplice non
                utilizzare il<br>
                double per la memorizzazione come del resto si fa in
                molti contesti<br>
                dove gli errori di rappresentazione non sono ammessi.
                Pur esistendoci<br>
                dei tipi di dato sostitutivi (es Bigdecimal.... ) non
                credo sia<br>
                pensabile risolvere definitivamente tale problema a
                breve poichè<br>
                questo implicherebbe abbandonare gli shapefile e
                soprattutto<br>
                aggiornare la maggior parte dei software commerciali e
                non.<br>
                <br>
              </blockquote>
              <br>
            </div>
            ... mi permetto di aggiungere una "piccola" nota a margine
            per<br>
            quanto riguarda l'efficienza di calcolo.<br>
            <br>
            moltissimi algoritmi di uso molto frequente in ambito
            GeoSpatial<br>
            (lunghezze ed aree, minima distanza, intersezioni etc)
            richiedono<br>
            montagne di calcoli trigonometrici in Floating Point.<br>
            <br>
            tutti i moderni microprocessori supportano direttamente in
            HW<br>
            questo tipo di operazioni, e sono in grado di macinare un<br>
            numero veramente impressionante di operazioni per secondo;<br>
            e tutte le librerie matematiche di base (su qualsiasi
            sistema<br>
            operativo) sono ottimizzate per spremere anche l'ultima<br>
            goccia della potenza di calcolo offerta dall'HW<br>
            <br>
            per gli ultimi Intel i7 multicore (un processore normalmente<br>
            usato per i PC di fascia alta) parliamo di circa 70/100
            GigaFLOPS,<br>
            cioe' quasi un centinaio di miliardi di operazioni al
            secondo.<br>
            eppure (notoriamente) molte operazioni di calcolo GIS sono
            pur<br>
            sempre di una lentezza mortale ;-)<br>
            <br>
            usare formati alternativi (Decimal, BigDeccimal)
            risolverebbe<br>
            certamente qualsiasi problema di precisione ed
            arrotondamento,<br>
            ma al prezzo di un rallentamento mortale della velocita' di<br>
            calcolo, visto che occorrerebbe rinunciare a sfruttare il<br>
            supporto HW floating point per usare piuttosto delle
            routines<br>
            completamente implementate via sw e capaci di preservare<br>
            inalterata una precisione di calcolo infinita.<br>
            <br>
            cioe' si tornerebbe sostanzialmente indietro nel tempo alla<br>
            situazione tipica degli anni '70 ed '80 quando le CPU non<br>
            offrivano nessun supporto HW per il floating point, che<br>
            veniva piuttosto implementato tramite emulazione sw; oppure<br>
            occorreva spendere un bel po' di soldini per acquistare a<br>
            parte un co-processore math in grado di offrire supporto hw<br>
            <br>
            se la memoria non mi inganna, la differenza nella velocita'<br>
            di calcolo tra "full HW" ed emulazione SW era di oltre cento<br>
            volte :-D<br>
            <br>
            siamo veramente sicuri che un miglioramento marginale della<br>
            precisione ultra-fine valga la pena di un siffatto handicap<br>
            prestazionale ?<br>
            <br>
            ... e mi astengo volutamente da qualsiasi considerazione<br>
            relativa agli spazi necessari per l'archiviazione dati, che<br>
            ovviamente "gonfierebbero" in modo impressionante.<br>
            <br>
            ciao Sandro
            <div class="HOEnZb">
              <div class="h5"><br>
                <br>
                <br>
                _______________________________________________<br>
                <a moz-do-not-send="true"
                  href="mailto:Gfoss@lists.gfoss.it" target="_blank">Gfoss@lists.gfoss.it</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss"
                  target="_blank">http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss</a><br>
                Questa e' una lista di discussione pubblica aperta a
                tutti.<br>
                I messaggi di questa lista non hanno relazione diretta
                con le posizioni dell'Associazione GFOSS.it.<br>
                666 iscritti al 22.7.2013</div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
    </blockquote>
    <br>
  </body>
</html>