[Gfoss] stili incorporati in spatialite

Ven 23 Set 2016 22:15:06 CEST

Aggiungo una ultima considerazione un po' amara.

Il primo punto per avere una costruzione comune, un modo di
renderizzare comune e' avere un moo comune di immagazzinare le
descrizioni delle vestizioni.

Come hai detto bene te,
QGIS , ha sempre avuto un rapporto di amore-odio ni confronti di spatialite.
Per cui, anziche' valorizzare il fatto di essere l'unico software in
grado di leggersi spatialite (o dovrei dire il primo), ha sempre
cercatodi affrancarsi da Spatialite ricreandosi in casa le api di
lettura/scrittura.
E lo stesso ha fatto con le API di gestione delle vestizioni, per cui
anziche'usare quelle standard di spatialite se ne ' fatta una sua
versione incompatibile.

Quelloche chi lavora su qgis non ha mai capito, e' che se si
supportavano le pi standard si poteva sperare in un allargamento della
base di supporto.
Per cui un doani, avrebbero potuto essere usate da mapserver, e forse
anche da altri softwares gis.
Ma il fatto che su qgis si siano scritte delle api sue interne e
incompatibili ha tarpato drammaticamente le possibilita' di vedere
ilmedesimo suppoto su altri software gis.

Del resto, QGIS non propone una libreria esterna come fa la esri con
la sua famosa mapobject, ma solo una api sua interna disponbile solo
da dentro qgis e per giunta variabile da versione a versione.
Che volevi supportare in atrli software gis ?
Non era possibile.

Se per assurdo qualcuno investisse nel memorizzare dentro spatialite
il formato featurestyle di gdal mediante delle api standard, avrebbe
subito a gratis il supporto di mapserver che e' gia' disponibile, noi
lo usiamo in un portale interno dove i dati provengono dal ondo dxf e
con questa feature ci ritroviamo da subito le vestizooni pronte a
riprodotte sul mapserver.

Ma chi si azzardasse a investire su qgis per farci mettere dentro un
supporto alla featurestyle sarebbe semplicemente un illuso,
perche' qgis andrebbe subito in una direzioni autarchica facendosi poi
una sua versione assolutamente incompatibile con la vera specifca
(esattamente come e' successo con le api di spatialite).

Per cui , la vedo bigia su questo fronte.

Chi cerca qualcosa di compatibile ad oggi, puo' solo guardare al modo
Geoserver con lae sld/se oppure al mondo autocad che grazie al gdal
che veicola lea feature style permette a chi lavora con autocad e vest
dxf di pubblicare fin da subito su un mapserver.

QGIS e' fuori dai giochi su questo.

A.

Il 23 settembre 2016 22:00, Andrea Peri <aperi2007 a gmail.com> ha scritto:
> Legog ora le tue problematiche.
>
> Probabilmente non e' l'ideale per te, ma se vuoi dedicarti a studiarlo
> un po', ti segnalo che:
>
> EEsiste una specifica neutra (una specie di linguaggio fanco) della vestizione,
> DIFFERENTE DALL'SLD e che ha introdotto gdal.
>
> http://www.gdal.org/ogr_feature_style.html
>
> Questa specifica E' SUPPORTATA AL 98% da mapserver.
> E dulcis in fundo:
>
> se te parti da un dxf (formato autocad 2004) che contiene al suo
> interno una vestizione (tratteggi, colori, spessori, etc..)
> a livello di singolo oggetto.
>
> Se con gdal/ogr lo converti in shapefile, ti ritrovi magicamente su un
> campo la definizione della featuretype e se lo sottoponi a mapserver
> te la capisce e la riproduce.
>
> Detto questo , mi ri-immergo nei miei casini webgissari.
>
> Saluti,
>
> A.
>
>
> Il 23 settembre 2016 11:14, Stefano Salvador
> <stefano.salvador a gmail.com> ha scritto:
>> Grazie a tutti per le risposte davvero illuminanti.
>>
>> Cerco di spiegare meglio il mio caso d'uso:
>>
>> ho creato un'applicazione webgis che tra le altre cose permette di
>> esportare quello che vedo a schermo in vari modi tra cui in bel db
>> spatialite. Gli stili usati non sono niente di complicato (bene o male
>> quelli supportati da OpenLayers) ma hanno un preciso significato per chi li
>> guarda. Ora questi file spatialite vengono utilizzati nei modi più diversi:
>>
>> 1. con un GIS desktop per fare una stampa personalizzata
>> 2. con un app mobile per portarsi dietro i dati durante i sopraluoghi
>> 3. come formato di interscambio verso altre applicazioni
>> 4. in più mi piacerebbe poterli usare in un server WMS/WFS
>>
>> fin qui Spatialite è fantastico e con qualche accortezza mi permette di
>> passare i dati con un'ottima interoperabilità fra diversi tipi di software
>> (anche commerciali) e con grande semplicità.
>>
>> Le note dolenti vengono con gli stili perché ogni volta devo creare e
>> tenere aggiornati un set di stili diverso per ogni applicazione che decido
>> di supportare, lavoro che non riesco in alcun modo a seguire.
>>
>> In questo scenario l'approccio nativo di Spatialite per me è fantastico in
>> quanto posso produrre programmaticamente gli stili, validarli e
>> impacchettare tutto in unico file. Se questi stili, per quanto limitati,
>> venissero riconosciuti da altri software avrei molti utenti felici.
>>
>> Anche volendo limitare l'interoperabilità al mondo QGIS non riesco a
>> risolvere il problema, innanzitutto perché produrre gli stili QML non è
>> banale e cambiano spesso, poi non riesco a risolvere il problema della
>> gestione delle risorse esterne che mi par di capire che richiede sempre il
>> path assoluto del file system.
>>
>> Quindi mi permetto di non essere daccordo con Luigi che afferma che
>> l'armonizzazione di almeno un sottoinsieme degli stili è un lavoro inutile.
>> Sono daccordo che è impossiible se voglio supportare i rendering più
>> professionali ma nell'ottica di "far girare" i dati tra vari strumenti
>> basta veramente un set di funzionalità molto più limitato.
>>
>> Grazie a tutti per i chiarimenti,
>>
>> Stefano
>>
>> _______________________________________________
>> Gfoss a lists.gfoss.it
>> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
>> Questa e' una lista di discussione pubblica aperta a tutti.
>> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
>> 807 iscritti al 31/03/2016
>
>
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------

-- 
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------