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