[ninux-dev] Fwd: [Nodeshot] Documentation (work in progress)

[Giuseppe De Marco]

All'inizio fà decisamente paura,
io pensa te, ho percorso anche strade compromettenti, tipo scrivere stored
procedures postgres in python (che consentono import shapely/geomet) e
altre vaccate - tutto per evitare il "catafalco" di postgis - ma il
discorso è semplice:

quanto più scali (uWSGI su N nodi, che distribuiscono il calcolo che
altrimenti farebbe solo il nodo DB - pergiunta immorale, date le sue
veci... ) o deleghi al client (javascript), quanto più risparmi ram e
sopratutto I/O disco (sopratutto I/O disco, benedetto postgres).
eppoi i backup e la gestione easy dello sviluppo non sottovalutiamolo:

"Ciao mamma - si, sono al mare, sì. Mi son portato nodeshot che lo sviluppo
mezza giornata.... No.. No...no... il setup è una sciocchezza..."

niente contro postGIS intendiamoci. Forse quache mesetto addietro vi avevo
parlato della possibilità di usare due DB (l'unica soluzione che uso con
PostGIS/Django) uno per il Web e un altro esclusivamente per la
cartografia, ma cartografia nodeshot non ne stora, pertanto... molla il
catafalco :)

buon proseguimento,
G

[1] http://it.wikipedia.org/wiki/Catafalco


Il giorno 28 novembre 2013 14:48, nemesis <nemesis at ninux.org> ha scritto:

> On Thu, 28 Nov 2013 12:39:18 +0100, Giuseppe De Marco <
> demarcog83 at gmail.com> wrote:
>
>> PostGIS è una ottima scelta, è un pò noioso da portare appresso,
>> come una moglie antipatica :)
>>
>> il beneficio sulle query spaziali è vero che ti è offerto dal
>> postgis ma puoi delegare questa peculiarità al client, si eviti il
>> carico sul server a parità di beneficio.
>> Se ogni nodo è un vettore con geometria di tipo punto, lato client,
>> sul webgis, l'utente decide un centroide (x/y o est/nord, su EPSG 4326
>> è x,y) - magari con un click . e sulla base dei km quadrati (o miles)
>> che decide di interrogare crea una geometria di tipo poligono.
>> Dopodichè, sempre tramite javascript, si adopera la funzione
>> intersect di OpenLayers.
>>
>> risultato:
>>
>> Hai evitato di mettere in produzione una basedati pesantuccia,
>> perchè pesantuccia ? perchè:
>>
>> 1. Ha estensioni che vanno compilate, ovvero dipendenze, ovvero
>> ridotta portabilità.
>> 2. Lo storage di Shape e Rasters non avviene nel DB, piuttosto gli
>> shapes (cugini dei kml) vengono salvati da geodjango (o solo da
>> django) come WKT. Data l'esiguità dei WKT di tipo POINT o LINESTRING
>> può andare più che bene anche un character varying ( piuttosto che
>> un campo TEXT )
>> 3. Un carico computazionale che può essere tranquillamente delegato
>> al client ( scalabilità occulta ? )
>>
>> con geomet/shapely, ad esempio, faccio conversioni e interrogazioni
>> spaziali.
>>  E' basato su Geos, il motore di PostGIS, ma è totalmente decoupled
>> pertanto nel futuro nodeshot, nell'eventualità di fare le query
>> staziali lato server, puoi usare queste e puoi anche disabilitarle
>> senza toccare le estensioni del DB.
>>
>
> Beh sono daccordo che Postgis è un bel mostro di software che non credo
> possa girare su sistemi con poche risorse.
>
> Magari se per qualche motivo avremo bisogno di una versione light con
> funzioni limitate da mettere su robe tipo cubieboard/raspberry/arduino-yun
> ci studiamo meglio questa soluzione! Però al momento è fantascienza :)
>
> Federico
>
> _______________________________________________
> ninux-dev mailing list
> ninux-dev at ml.ninux.org
> http://ml.ninux.org/mailman/listinfo/ninux-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ml.ninux.org/pipermail/ninux-dev/attachments/20131128/316553b4/attachment-0001.html>