Certo, il progetto diventa sempre più laborioso. Ma non ci possiamo fare molto ...
La richiesta non viene accolta. Ma visto che ho 10 minuti spiego il perché.
Certo che era bello il sistema precedente. Si selezionava nell'ordine Regione, Provincia, Comune. Bello, intuitivo ma non funzionale. E' sufficiente che alcuni comuni (come è realmente capitato) vengano trasferiti dalle Marche all'Emilia Romagna per impallare il meccanismo (certo, noi potremmo modificare il database; ma perché dobbiamo essere noi a manutenere un archivio?). Il codice ISTAT è obbligatorio, è univoco e, soprattutto, è un codice. Informaticamente non c'è cosa più erotica di un codice. La tabella viene manutenuta da un Ente pubblico e quindi sicuramente conforme. Un semplice "lookup" sulla tabella restituisce Regione, Provincia e Comune. Troppo efficiente.
I gradi giorno possono essere calcolati automaticamente ma, dal momento che ancora non si sa che fare, il valore deve essere inserito manualmente prelevandolo dalla tabella del DPR 412. Perché non può farlo il software? Ma perché non possiamo fare una ricerca fra le descrizioni dei comuni attuale ed i comuni della tabella DPR 412. La tabella citata era scritta usando caratteri maiuscoli, gli accenti erano con l'apostrofo ed infine si tratta di una tabella del 1994 (quindi non aggiornata). I Comuni nei codici istat sono scritti in Camel Case (Alto Basso) e le accentate sono quelle della lingua corrente (à,è,ì,ò,ù). Non è possibile fare una ricerca in questo modo; ecco perché viene presentata la tabella a video per poter essere selezionata. Se poi mi dici: ma Modena e MODENA potrebbero essere facilmente essere trovati, è possibile. Con un discreto dispendio elaborativo (ovvero tempo ed un altro pulsante che avvisa l'utente che serve del tempo) si potrebbe fare. E questo coprirebbe forse il 90% dei comuni. Ma è lineare? Io non credo.
La latitudine e la longitudine sono dati decimali. L'unità di misura è il DD (Decimal Degree). Dal momento che sono campi decimali è ovvio che il campo richiede il separatore decimale del sistema. Non voglio dire un'eresia ma potrei affermare che zio Google sbaglia ad usare il punto come separatore decimale (o no?).
Per le altre tabelle non ne parliamo... Come evidenziato nella videata, ci sono tabelle a contenuto variabile e scritte maniera diversa. Come possiamo noi impotenti programmatori correlare questa tabelle? Certo mi si dirà: Modena è sempre Modena ... Ma "Reggio Emilia" e "Reggio nell'Emilia" sono due cose completamente diverse ...
I dati precedenti sono del 1994. Hanno avuto 22 anni di tempo per raccoglierli in maniera più omogenea ed il risultato è quello che è stato fatto? Si prevede la consultazione di tabelle non correlate fra di loro pur sapendo perfettamente che il tutto doveva essere elaborato da software. Hanno previsto un metodo prettamente "cartaceo" (anni 90-) ad utilizzo di software informatici. E la colpa per la perdita di 123 secondi in più per compilare la videata è solo nostra? Questa storia dei dati climatici emerge ogni tanto ma noi non è che ci possiamo fare poi molto. Questo è il materiale che è disponibile. Non siamo certo noi contro gli utenti 👍 .
Non lavoro più su questo software. Non inviatemi messaggi privati. Per assistenza sul software utilizzate la pagina contatti di questo sito. Grazie. Alberto.
