[Talk-it] progetti

[Giovanni Mascellani]

Sono d'accordo con praticamente tutte le critiche che muovi a T at H, ma
IMHO la migliore soluzione non è scrivere un sistema nuovo, ma
migliorare quello che esiste. Ossia, T at H non è sbagliato, solo ancora
in sviluppo. Poi sarebbe anche una bella cosa appoggiarsi ad un
framework già comprovato come BOINC o non so quale altro, ma non mi
sembra una priorità impellente (inoltre immagino che integrarsi con un
framework implicherebbe prima il risolvere molte delle critiche di cui
stiamo discutendo).

All'incirca Tue, 05 Feb 2008 07:58:22 +0100,  niubii
<f.pelullo at libero.it> sembrerebbe aver scritto:

> Giovanni Mascellani ha scritto:
> > Ma Tiles at Home è già un progetto di rendering distribuito, perché ne
> > serve uno nuovo? 
> >   
> Perche' T at H e' un render che viene lanciato ad hoc (?) e usa il 100%
> delle risorse della macchina (!).

A livello di CPU non è vero, perché i processi di renderizzazione sono
lanciati con nice 10 (ossia in bassa priorità). A livello di RAM è
vero, e spero alla grande che la cosa sia risolvibile. E questo è
sicuramente uno dei problemi di T at H, ma non è integrandolo con un
framework o creando un nuovo sistema che viene risolto!

> E' concepito per una macchina dedicata, il classico computer connesso
> ad internet, con una distro linux.
> Il problema e' che se tu hai un computer connesso a internet con una
> distro linux :-) molto probabilmente e' un server, che hai dedicato ad
> un altro compito, chesso' farci girare un server http o il firewall
> aziendale. Non mi sognerei mai di caricare T at H sul nostro firewall
> aziendale.

Francamente neanche io, se avessi o amministrassi un firewall
aziendale, ma non mi sognerei mai neanche di caricarci BOINC o
qualsiasi altro programma non strettamente necessario al funzionamento
del server! Sia per una questione di sicurezza che di prestazioni,
perché non esiste un sistema di calcolo distribuito che non ti degrada
almeno un pochino le prestazioni del sistema.

> Probabilmente io non so di che cosa sto parlando :-), ma IMHO se
> quelli del progetto SETI riescono a sondare lo spazio profondo
> utilizzando migliaia di personal computer, ciascuno dotato di
> hardware "standard", che lavorano assieme,  invece di usare pochi
> server con processori e RAM spaventose... forse hanno visto che e'
> meglio cosi'!  :-)
> 
> Io vorrei che la base a cui si rivolge openstreetmap fosse molto piu'
> ampia.
> Per parafrasare: OSM everywhere! (TM)
> 
> Intendo suggerire una soluzione simile a T at H, ma (in quanto eseguita
> su piu' pc) in grado di elaborare le code in minor tempo per riuscire
> a visualizzare le modifiche "in tempo reale".

Mi sembra che i difetti che tu individui siano principalmente due:
ottimizzare il sistema di rendering in modo che non ciucci troppe
risorse (e mi sembra che il problema sia soprattutto sulla RAM, perché
lavorare in bassa priorità è facile) in modo che sia utilizzabile anche
su computer "normali" e rendere più facile l'installazione del client
distribuito.

Se volevi dire questo, sono perfettamente d'accordo, ma, personalmente,
non credo sia necessario creare un sistema ex-novo. Basta migliorare
quello che c'è. E se la tua proposta era questa, la approvo pienamente!

> > Perché la struttura dati di
> > OSM è inconsistente e a cosa porta questo?
> >   
> Perche' mancano tutte le regole topologiche che invece sono presenti
> nei GIS.
> Anche potendo fare delle query sul database (non puoi, puoi consultare
> soltanto la parte grafica ma non le tabelle degli attributi, a meno
> che non ti tiri giu' planet.osm), non riusciresti ad esempio a sapere
> quanti km di strade si trovano nel territorio comunale di un certo
> paese, o in una determinata regione, oppure qual e' l'insieme dei
> segmenti stradali che distano meno di una distanza x da un ospedale
> etc.

In realtà si possono fare query direttamente al database (anche senza
essere registrati se sono in sola lettura, credo), chiedendo tutti gli
oggetti che stanno in un determinato rettangolo, purché non sia troppo
grande. Del resto, questo è ciò che fa JOSM quando chiedi di
scaricare una regione!

Sulla mancanza di regole topologiche del tipo inclusione ed adiacenza
capisco quello che intendi, e direi che sono d'accordo, anche se non
sono esperto di GIS.

> Allo stato attuale, IMHO openstreetmap e' soltanto un "bel
> disegno". :-) (prima di mandarmi al rogo, rifletti su questa
> affermazione) :-)

Non ti mando assolutamente al rogo! Però non sarei neanche troppo
restrittivo: la struttura dati di OSM è senza dubbio mancante per
alcuni aspetti, ma per altri mi sembra molto buona. In ogni caso relego
questa affermazione al rango di opinione personale, non avendo
esperienza in questo ambito.

> La mia e' solo un'opinione, sarei lieto di scoprire che mi sbaglio.
> Non voglio mancare di rispetto a quanti stanno sgobbando sul progetto.

Questo vale indubbiamente anche per me!

Buon mapping a tutti!
Giovanni.
-- 
Giovanni Mascellani <g.mascellani at gmail.com>
Pisa, Italy

Web: http://giomasce.altervista.org
SIP: g.mascellani at ekiga.net
Jabber: g.mascellani at jabber.org / giovanni at elabor.homelinux.org
GPG: 0x5F1FBF70 (FP: 1EB6 3D43 E201 4DDF 67BD  003F FCB0 BB5C 5F1F BF70)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 307 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk-it/attachments/20080205/e544e78f/attachment.pgp>