stili incorporati in spatialite

[Stefano Salvador]

Ciao a tutti,

in questi giorni stavo sperimentando con gli stili incorporati in
spatialite ed ero un po' perplesso riguardo al supporto fornito dai vari
software cartografici.

Se non sbaglio ci sono due metodi per incorporare uno stile in file
spatialite:

1. Salvandolo con QGIS
2 Usando le apposite API di Spatialite

Purtroppo i due metodi sono incompatibili in quanto QGIS ha optato per un
proprio formato che ha qualche limite:

1. le risorse esterne (icone, ...) si possono inserire solo come percorso
assoluto
2. non è possibile includere nel db gli eventuali file delle simbologie
3. solo QGIS è in grado di leggerlo e gestirlo

il formato "nativo" invece è completo e ben fatto ma da quello che vedo
nessun software GIS lo supporta.

Il mio obiettivo sarebbe quello di impacchettare un file da distribuire che
sia un minimo interoperabile (mi starebbe anche bene usare solo QGIS ma con
i percorsi assoluti diventa difficile spostare il file da un PC ad un
altro).

Se guardiamo alle sole geometrie questo obiettivo è raggiunto (spatialite
viene letto anche da molti sw commerciali) ma per gli stili ancora ognuno
va per la sua strada sebbene un sottoinsieme di feature ormai è comune tra
tutti i software.

Qualcuno ha qualche esperienza a riguardo?

Ciao,

Stefano

_______________________________________________
[hidden email]
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

[a.furieri]

On Thu, 22 Sep 2016 17:08:21 +0200, Stefano Salvador wrote:

> Ciao a tutti,
>
> in questi giorni stavo sperimentando con gli stili incorporati in
> spatialite ed ero un po' perplesso riguardo al supporto fornito dai
> vari
> software cartografici.
>
> Se non sbaglio ci sono due metodi per incorporare uno stile in file
> spatialite:
>
> 1. Salvandolo con QGIS
> 2 Usando le apposite API di Spatialite
>

Ciao Stefano,

giusto per puntualizzare e per mettere in luce un punto fondamentale:
SpatiaLite e' semplicemente un'estensione di SQLite, e SQLite e' un
DBMS generico che consente di fare praticamente di tutto senza
alcuna restrizione funzionale.

Sarebbe quindi sempre opportuno fare un distinguo tra funzionalita'
supportate da SpatiaLite (nel senso che richiedono necessariamente
il caricamento del modulo di estensione mod_spatialite per funzionare
correttamente) e funzionalita' genericamente basate sul solo SQLite,
che quindi funzionano anche quando la libreria di estensione non
e' presente.

Capisco che dal punto di vista utente questa distinzione puo'
sembrare capziosa, ma nel caso specifico ci aiuta a capire che in
effetti SpatiaLite "vanilla" supporta un unico meccanismo per gli
stili SLD/SE, quello nativo.

La soluzione degli stili QGIS invece non ha nulla a che fare con
SpatiaLite, perche' si basa semplicemente sui generici meccanismi
base di SQLite.
Nulla vieta di inserire gli stili QGIS in un DB SQLite che contenga
geometrie SpatiaLite, ma almeno in linea di principio li potresti
tranquillamente inserire anche in qualunque altro DB SQLite non
predisposto per SpatiaLite.
Gli stili QGIS sono insomma un subset funzionale totalmente avulso
dal main-core SpatiaLite; possono tranquillamente coabitare nel
medesimo DB-file, ma si ignorano a vicenda.

> Purtroppo i due metodi sono incompatibili in quanto QGIS ha optato
> per un
> proprio formato che ha qualche limite:
>
> 1. le risorse esterne (icone, ...) si possono inserire solo come
> percorso
> assoluto
> 2. non è possibile includere nel db gli eventuali file delle
> simbologie
> 3. solo QGIS è in grado di leggerlo e gestirlo
>
> il formato "nativo" invece è completo e ben fatto ma da quello che
> vedo
> nessun software GIS lo supporta.
>

Stefano, mi piacerebbe tanto potere prendere questa tua affermazione
come un complimento per SpatiaLite, ma purtroppo devo respingere il
complimento al mittente.
l'implementazione "nativa" per gli stili non pretende di avere nessun
merito particolare cosi' come non pretende affatto di essere
innovativa;
e' semplicemente un'implementazione pedante e per nulla fantasiosa
dello
standard OGC per gli stili SLD/SE, basata sul rispetto stretto e
rigoroso
di tutti i vincoli imposti dagli schemi XSD "ufficiali" pubblicati da
OGC.

l'unica "variante fuori ordinanza" introdotta dal support SLD/SE di
SpatiaLite consiste in un'interpretazione estensiva del concetto di
URL (che dopo tutto significa letteralmente Uniform Resource Locator),
in modo tale da potere utilizzare queste pseudo-URL come classici
riferimenti relazionali Primary/Foreign Key, riuscendo cosi' a poter
caricare tutte le risorse grafiche (bitmaps, SVG) direttamente
all'interno di un singolo DB-file monolitico e sopprimendo alla
radice ogni necessita' di utilizzare risorse esterne ubicate sul
filesystem.

> Il mio obiettivo sarebbe quello di impacchettare un file da
> distribuire che
> sia un minimo interoperabile (mi starebbe anche bene usare solo QGIS
> ma con
> i percorsi assoluti diventa difficile spostare il file da un PC ad un
> altro).
>
> Se guardiamo alle sole geometrie questo obiettivo è raggiunto
> (spatialite
> viene letto anche da molti sw commerciali) ma per gli stili ancora
> ognuno
> va per la sua strada sebbene un sottoinsieme di feature ormai è
> comune tra
> tutti i software.
>
> Qualcuno ha qualche esperienza a riguardo?
>

per quanto a mia conoscenza personale, l'unico sw che e' attualmente
in grado di sfruttare pienamente lo styling SLD/SE "nativo" e'
rappresentato da RasterLite2 (purtroppo ancora in fase si sviluppo).

a suo tempo, quando nel 2013 SpatiaLite 4.1.0 introdusse il supporto
SLD/SE si apri' uno spazio potenzialmente interessante per integrare
le nuove funzionalita' direttamente in QGIS (lo sviluppo lato splite
precede storicamente di qualche mese lo sviluppo lato QGIS).

Purtroppo poi le cose hanno preso un corso differente e QGIS alla
fine ha preferito implementare un proprio meccanismo interno non
standard ed incompatibile col resto del mondo ... peccato, perche'
cosi' e' andata persa una buona occaione per provare a standardizzare
quella che e' la vera torre di babele che affligge tutte le
applicazioni GIS, cioe' le millemila implementazioni difformi e
reciprocamente incompatibili per lo styling.

ciao Sandro
_______________________________________________
[hidden email]
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

[pcav]

Salve,

Il 23/09/2016 09:38, [hidden email] ha scritto:
> Purtroppo poi le cose hanno preso un corso differente e QGIS alla
> fine ha preferito implementare un proprio meccanismo interno non
> standard ed incompatibile col resto del mondo ... peccato, perche'
> cosi' e' andata persa una buona occaione per provare a standardizzare
> quella che e' la vera torre di babele che affligge tutte le
> applicazioni GIS, cioe' le millemila implementazioni difformi e
> reciprocamente incompatibili per lo styling.

Concordo, un vero peccato. Purtroppo SLD si è rivelato semanticamente di
gran lunga troppo povero per ospitare le miriadi di stili di cui ormai
QGIS è pieno.
I formati sono un vero problema del software, forse uno dei più grandi.
Vedi ad es. quel che sta succedendo con shpefile, che nessuno vuole ma
che nei fatti non ha ancora trovato un sostituto davvero valido, e
quindi ognuno si arrabatta come può.
Fortunatamente il sw libero reagisce bene a questo stato di cose; vedi
ad es. l'ottimo lavoro fatto di recente da Andrea Aime per il supporto
SLD in QGIS.
Saluti.
--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
[hidden email]
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

[Luigi Pirelli-2]

tocchi un punto dolente Stefano.... Spatialite permette di supportare
rigorosamente SLD/SE semplicemetne perche' non renderizza nulla! Non
conosco nessun SW che non usi una sua implementazione o estenda SLD1.0
o SLD/SE (stessa cosa nel mondo della grafica... cambiano i dati ma il
problema e' identico)

l'interoperabilita' nel caso di qgis e' aggravata dal fatto che, pur
diventando nel tempo uno standard di fatto otre a quelli commerciali,
non ha (ancora) investito sulal sua standardizzazione/specificazione.
Non c'e' uno straccio di DTD, parallelamente ne traggono enormi
vantaggi le funzionalita' di rendering che vengono aggiunti a ogni
nuova release.

al di la del problema di interoperabilita'... non e' che mi sia tanto
chiaro il tuo caso d'uso, e dunque come debba/possa essere risolto.

Il lavoro di Aime dimostra:
1) la complessita' per armonizzare due mondi (a mio parere) non
aromonizzabili (QML/QSL con SLD+estensioni)
2) L'inutitlita' nel mondo cartografico di tale sforzo... cioe' va
bene per casi d'uso piuttosto consolidati, ma dimentichiamoci di
usarlo nel mondo giornalistico o per i dati che evolvono a meno di
avere visualizzazione buone per il secolo passato.
3) ho perso almeno un mese cercando di trovare una soluzione di
armonizzazione... io non ne ho trovate, spero sia solo un mio
limite.... Aime sta facendo bug fix, ma non tocca la radice del
problema di compatibilita tra qml e sld/se

a presto
Luigi Pirelli

**************************************************************************************************
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************


2016-09-22 17:08 GMT+02:00 Stefano Salvador <[hidden email]>:

> Ciao a tutti,
>
> in questi giorni stavo sperimentando con gli stili incorporati in
> spatialite ed ero un po' perplesso riguardo al supporto fornito dai vari
> software cartografici.
>
> Se non sbaglio ci sono due metodi per incorporare uno stile in file
> spatialite:
>
> 1. Salvandolo con QGIS
> 2 Usando le apposite API di Spatialite
>
> Purtroppo i due metodi sono incompatibili in quanto QGIS ha optato per un
> proprio formato che ha qualche limite:
>
> 1. le risorse esterne (icone, ...) si possono inserire solo come percorso
> assoluto
> 2. non è possibile includere nel db gli eventuali file delle simbologie
> 3. solo QGIS è in grado di leggerlo e gestirlo
>
> il formato "nativo" invece è completo e ben fatto ma da quello che vedo
> nessun software GIS lo supporta.
>
> Il mio obiettivo sarebbe quello di impacchettare un file da distribuire che
> sia un minimo interoperabile (mi starebbe anche bene usare solo QGIS ma con
> i percorsi assoluti diventa difficile spostare il file da un PC ad un
> altro).
>
> Se guardiamo alle sole geometrie questo obiettivo è raggiunto (spatialite
> viene letto anche da molti sw commerciali) ma per gli stili ancora ognuno
> va per la sua strada sebbene un sottoinsieme di feature ormai è comune tra
> tutti i software.
>
> Qualcuno ha qualche esperienza a riguardo?
>
> Ciao,
>
> Stefano
>
> _______________________________________________
> [hidden email]
> 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

_______________________________________________
[hidden email]
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

[pcav]

Salve,

Il 23/09/2016 10:34, Luigi Pirelli ha scritto:

> 2) L'inutitlita' nel mondo cartografico di tale sforzo... cioe' va
> bene per casi d'uso piuttosto consolidati, ma dimentichiamoci di
> usarlo nel mondo giornalistico o per i dati che evolvono a meno di
> avere visualizzazione buone per il secolo passato.

concordo appieno.
Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
[hidden email]
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

[Stefano Salvador]

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

_______________________________________________
[hidden email]
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

[Luigi Pirelli-2]

2016-09-23 11:14 GMT+02:00 Stefano Salvador <[hidden email]>:
> Grazie a tutti per le risposte davvero illuminanti.
> 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.

fin qui e' tutto un problema interno a qgis. In effetti la simbologia
svg viene trovata in base ai path definiti in configurazione (che mi
ricordi io)... non viaggiano legati allo stile.
Sinceramente non ho mai provato plugin come QConsolidate o altri che
impacchettano unprogetto qgis con relativi dati e stili per favorine
la trasferimento. Suppongo si sono posti il problema dei path assoluti
delle risorse.... una domanda hai verificato questi plugins? ce ne
sono piu' di uno.

> 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.

guarda uno dei problemi che io e colelghi ci siamo trovati ad
affrontare e' determinare cosa e' basico e cosa no, cioe' queli
rendering basici bisogna supportare affinche' creare progetti di test
per comparare e testare discrepanze nel rendering dopo le conversioni.
Questo rimane ancora un problama piuttosto grosso. Si e' capaci di
sistematizzare cosi' da creare convertitori di test? In Boundlessm
abbiamo del codice (e' aperto e libero per tutti) nel
geserver_explorer che adatta un qml a sld (sld+ cioe' sld piu'
estensioni di geoserver), e ogni volta viene patchato per supportare
una renderizzazione non supportata dalla conversione. Direi che una
alta percentuale di ticket riguarda proprio questo e continuamo a
inverstire risorse per cercare di armonizzare... ma e' un problema
risolvibile?

>
> Grazie a tutti per i chiarimenti,
>
> Stefano

sincerametne non voglio tarpare le ali... magari la soluzione e'
altrove e fuori dai tracciati di sld o qml o ysld o cartocss o qlr o
quel che sia... il problema e' strutturale percio' o arriva un Mike
Bostock che rivoluziona i principi rigirando la frittata della
renderizzazione, o continueremo a rigirarci in questo, a mio parere,
pantano.

Luigi Pirelli

**************************************************************************************************
* Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************
_______________________________________________
[hidden email]
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]

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
<[hidden email]> 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
>
> _______________________________________________
> [hidden email]
> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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]

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 <[hidden email]> 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
> <[hidden email]> 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
>>
>> _______________________________________________
>> [hidden email]
>> 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 àèìòù
-----------------
_______________________________________________
[hidden email]
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

[pcav]

Salve,

Il 23/09/2016 22:15, Andrea Peri ha scritto:

> 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.

Smentisco *ufficialmente* questa affermazione. QGIS non è una persona,
quindi non ha né amore né odio. Semplicemente, è un ambiente aperto, in
cui chiunque porti buon codice è ben accetto.
Il provider di QGIS per Spatialite, peraltro, è stato scritto da
Furieri, se non ricordo male proprio durante l'hackfest di Pisa.

> 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.

Il problema, come già sottolineato, è che standard efficaci per la
vestizione avanzata semplicemente non esistono. Altrimenti li avremmo
usati, ovviamente.
Credo che gli sviluppatori di QGIS siano persone sufficientemente
intelligenti per capire l'utilità degli standard.

> 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.

Purtroppo quelle vestizioni coprono una parte infinitesima delle
possibilità, sempre in espansione, di QGIS, che tutti apprezziamo.
Abbiamo fatto un'analisi piuttosto rigorosa, e la strada che proponi
semplicemente non è fattibile.

> 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).

Continui a disegnare "strategie" che semplicemente non esistono.
QGIS è frutto del lavoro di centinaia di persone, fra cui anche te e me,
e va nella direzione presa da queste.

> Per cui , la vedo bigia su questo fronte.

Fortunatamente, i fatti danno ragione agli ottimisti, ad es.
https://www.google.com/trends/explore?date=all&geo=IT&q=qgis,arcgis

> 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.

Beh, visto il lavoro di Andrea Aime, già citato, mi pare proprio che i
fatti ti diano, fortunatamente, torto.

Saluti.

--
Paolo Cavallini - www.faunalia.eu
QGIS & PostGIS courses: http://www.faunalia.eu/training.html
_______________________________________________
[hidden email]
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]

In qgis ci sono 3 modi di caricare i dati spatialite:

il provider di furieri, l'impiego di ogr e il db manager.

A seconda di quale si usa si hanno implicazioni diverse.


A.

Il 24/09/2016 06:40, Paolo Cavallini ha scritto:
> Smentisco*ufficialmente*  questa affermazione. QGIS non è una persona,
> quindi non ha né amore né odio. Semplicemente, è un ambiente aperto, in
> cui chiunque porti buon codice è ben accetto.


_______________________________________________
[hidden email]
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]

Non eì un problemadi standard "efficace".

Ma piuttosto un problema di fare le cose sempre nel solito modo.

Quello che lamenta salvador non e' di avere uno standard di vestizione
che ia comune a tanti GIS differenti,

m piutttosto che le vestizioni QML di qgis su spatialite quando qgi le
salva su spatialite non sa le api standard e cosi' facendo non sono
gestibili

da gli ambienti esterni a spatialite.


Questo non centra molto con luno standard di vestizione.

Il problema lo avreste pari pari anche se qgis fosse compatibile al 100%
con le sld di geoserver.
Il problema in altri termini e' che spatialite prevede di archviiare
files di vestizioni (qualunque esse siano e per qualsiasi programma gis
essi siano) in una cassetta tonda. QGIS invee le salva in una cassetta
quadrata.

Amen.
A.

Il 24/09/2016 06:40, Paolo Cavallini ha scritto:
> Il problema, come già sottolineato, è che standard efficaci per la
> vestizione avanzata semplicemente non esistono. Altrimenti li avremmo
> usati, ovviamente.
> Credo che gli sviluppatori di QGIS siano persone sufficientemente
> intelligenti per capire l'utilità degli standard.

_______________________________________________
[hidden email]
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]

Puo' darsi, ma non lo darei cosi' per scontato.

In realta' e'una cosa molto potente perche' ha un approcciocompletamente
differente.

Molte delle cose che qgis fa , li' sono implicite nella modalita'
descrittiva della vestizione.
Il fatto di descriverla per singola feature (singolo record) permette di
avere
una parcellizzazione assoluta.
Cosa che qgis non ha perche' al massimo lavora per categorie oppure
applica dei valori presi da un dataset.

Il rule-rendering di qgis , ad esempio

nella featurestyle E' IMPLICITO.

Sia per le vestizioni che per i testi. E non e' poco per niente.

Perche' semplicemente vestendo singolarmente ogni feature, potrei in
teoria sbizzarrirmi a vestire un milione di records ognuno  con uno
stile differente.

Cosa che con qgis non potrei mai fare.

QGIS propone il succedaneo della vestizione tramite campo dello
shapefile, ma appunto e' un succedaneo.

Perche' obbliga comunque ad avere uno stle comune tra tuttele feature e
permette di cambiare size, colori e testi.

Ma non passare da un stile di un certo tipo a uno di tipo completamente
differente.

Poi , come tutti gli standards, ovviamente dipende dallambiente di
implementazione, ovvero dal mapserver in questo caso, oppure l'ambiente
is che lo impiega.

Credo che sia roba supportata da Bentley.

Lo standard e' una cosa, l'implementazione e' una altra.


Poi ovviamente , vale lo stesso discorso che dicevi te una volta tanti
anni fa'.

Non si puo' confrontare un software commerciale che gode di
moltifinanziamenti con un gfoss che campa di 4 lire.

Vale lo stesso discorso qui.

L'idea della featurestyle e' geniale e gia' ora e' molto potente.

Per il resto confrontare una cosa che e' frutto della mente geniale di
una o di poche persone e un qgis che ormai e' quasi un framework che
raccoglie di tutto anche in maniera un po' disordinata non e' possibile.

Chi adotta qgis, lo accetta come e' e non deve poi stupirsi delle sue
"particolarita' ".

Magari su 10000 persone che usano qgis, solo 1 potrebbe essere
interessata alla featurestyle.
E' giusto che sappia che esiste.
Poi se preferisce usare qgis e'una sua libera scelta.
In fondo questa e' la liberta' del gfoss.
Permettere a chunque di usare quelo che meglio gli torna per il suo lavoro.

A.


Il 24/09/2016 06:40, Paolo Cavallini ha scritto:
> Purtroppo quelle vestizioni coprono una parte infinitesima delle
> possibilità, sempre in espansione, di QGIS, che tutti apprezziamo.
> Abbiamo fatto un'analisi piuttosto rigorosa, e la strada che proponi
> semplicemente non è fattibile.

_______________________________________________
[hidden email]
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]

Buon per oi.

Ma forse non e' stato ben compreso il lavoro di Andre Aime.

Molto importnate per chi vuole sare geosever.


Ancora piu' utile ora che a quando pare stanno ipotizzando che
qis-server debba diventare un prodotto distinto . Cosa che ovviamente
creera' ncompatibilit'a con gis desktop e fara' nascere tutta una serie
di problematiche che i iu' non saranno mai in grado di gestre.

A quel punto avere una via di fug razie al porting degli sld su geoserver.

orra'dire che si puo' usare qgis e pubblicare con geoserver.

Veramente una cosa utile.

Bravo Andrea.


A.

Il 24/09/2016 06:40, Paolo Cavallini ha scritto:
> Beh, visto il lavoro di Andrea Aime, già citato, mi pare proprio che i
> fatti ti diano, fortunatamente, torto.
>
> Saluti.

_______________________________________________
[hidden email]
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