[Gfoss] Nel metadato di un servizio wms: Come interpretare il campo "coupled resource"

Andrea Peri aperi2007 a gmail.com
Gio 18 Giu 2015 09:32:02 CEST


Ciao, grazie per la risposta.

Premesso che probabilmente hai ragione te,
perche' anche io in partenza pensavo che si dovesse mettere la url che
puntava al metadato del dataset usato nel layer.
Inoltre, guardando a giro sul portale inspire (esempio l' inghilterra)
avevo trovato casistiche in cui li' era puntato ilmetadato del
dataset).

Devo anche dire, che quando sono andato ad aplicare
questainterpretazione sui nostri wms, mi sono trovato di fronte a
delle casisitche che rendevano questa interpretazione inapplicabile.

Cerco di spiegare il mio ragionamento:

La spiegazione del mio ragionamento e' legata al fatto che in un layer
di un wms puo' non esserci semplicemente un dataset derivato da un
singolo shapefile.
Ad esempio, potrebbe essere un layer di tipo named-group che produce
una mappa a partire dal contributo di piu' dataset (piu' shapfile).
In tal caso sul wms non si vedrebbero i singoli layer riferiti ai
singoli dataset (shapefile), ma bensi' il solo layer cuomulato che
raggruppa tutti quanti.
Questa pratica di impiego e' abbastanza diffusa.

In questo caso non si avrebbe un metadato che descrive il dataset,
perche' fisicamente tale dataset non esiste essendo piuttosto la
cumulazione di piu' dataset.

Oppure, un altro caso, potrebbe essere quello i cui su un layer non
viene mostrato un intero dataset, ma una sua porzione, come ad esempio
nel nostro wms dell'uso-suolo.

In cui a fronte di un dataset fisico che contiene tutto l'uso-suolo di
RT, sul wms anziche' metterci 1 solo layer con una vestizione di100
domini, abbiamo preferito proporre 10 layer ognuno con la vestizione
di 1 solo dominio.
Cosa questa che permetteva un uso piu' profcuo da parte di un utente,
il qale avrebbe potuto selezionarsi i singoli layers del wms di suo
interesse.

Ovvio anche in questo caso che puntare al metadato del dataset globale
e' fuorviante.
Anche se in questo caso si potrebbe magari chiudere un occhio visto
che nel piu' ci sta' il meno.

Pero', il primo caso che ho descritto, quello del layer derivato da un
named-group, e' comunque il caso che assolutamente non e'
rappresentabile con una scheda di metadato che e' riferita ai dati
fisici sottostanti.

Ed e' per questo che mi ero convinto a riportare sul campo
"coupled-resource" la url di un getmap.
Unica cosa che permette di prendere visione esattamente di cio' che
produce tale layer su quello specifico wms.

Sono molto interessato a sapere come altre realta' hanno affrontato il
riempimento del campo "coupled-resource" in presenza di un layer che
cumula piu' datasets.

Grazie,
A.


Il 17 giugno 2015 11:45, Matteo De Stefano <matteo_destefano a yahoo.it>
ha scritto:
> Buongiorno,
>
> da come la interpreto io,
> mi sembra più un link a una URL che localizza un Record o un documento di
> metadati, secondo la direttiva ISO 19139, almeno da quello che leggo in
> http://inspire.ec.europa.eu/documents/Network_Services/TechnicalGuidance_ViewServices_v3.1.pdf
> paragrafo 4.2.3.3.1.5 COUPLED RESOURCE. L'elemento <MetadataURL> punta al
> Record del layer o al documento di metadati del dataset, usando quindi lo
> standard CSW, che a sua volta contiene la URL del servizio WMS con cui viene
> servito. Ma non ho mai lavorato con INSPIRE, e potrei sbagliarmi.
>
> Saluti,
>
> Matteo
>
>
>
>
> ________________________________
> Da: Andrea Peri <aperi2007 a gmail.com>
> A: "gfoss a lists.gfoss.it" <gfoss a lists.gfoss.it>
> Inviato: Martedì 16 Giugno 2015 21:30
> Oggetto: [Gfoss] Nel metadato di un servizio wms: Come interpretare il campo
> "coupled resource"
>
> Salve,
> sto cercando di complare la metainformazione a specifiche Inspire di
> un servizio WMS.
>
> Nel farlo faccio ovviamente uso dell'editor che meglio di chiunque
> altro si avvicina alle specifiche inspire, ovvero il metadata editor
> del portale Inspire.
>
> I metaati di un servizio wms sono un po' differenti da quelli di un dataset
> .
> In particolare nella sezione "identification" compare un misterioso campo
> "coupled resource" con molteplicita' 1-N.
>
> Visto che questo campo e' per me una novita' vorrei condividere le
> interpretazioni che gli ho dato anche per capire se sono sulla giusta
> strada.
>
> Questo e' il testo dell' help fornito dall' editor inspire , e a cui
> ho fatto riferimento per la mia interpretazione:
>
>>Coupled resource
>>
>>If the resource is a spatial data service, this metadata element
>> identifies, where
>>relevant, the target spatial data set(s) of the service through their
>> unique
>>resource identifiers (URI).
>>
>>The value domain of this metadata element is a mandatory character string
>>code, generally assigned by the data owner, and a character string
>> namespace
>>uniquely identifying the context of the identifier code (for example, the
>> data
>>owner).
>
> Prima cosa da chiarire e' cosa esattamente sia una URI, da non
> confondere con una URL.
> Una URI e' una stringa che identifica univocamente una risorsa la "i"
> sta per identification)
> Per intendersi un nome con cognome "Andrea Peri" potrebbe essere una
> URI se identifica univocamente. Ma siccome ci possono essere omonimie
> non e' una URI.
> Invece "Andrea Peri via vattelappesca 99" potrebbe esserlo perche'
> identifica univocamente.
>
> Siccome la URI identifica  (la " i " sigifica identification) cosa e' la URL
> ?
> La URL si capisce subito cosa sia se si considera che la " L" sta per
> localization.
>
> Quindi localizza la risorsa.
> Va anche detto che una URL e' a tutti gli effetti una URI. Perche'
> localizzando la risorsa contribuisce anche a identificarla.
> Quindi:
>
> "Andrea Peri" puo' essere una URI a meno di omonimie, ma non localizza
> la risorsa perche' non dice dove si trova .
> Mentre "Andrea Peri, via vattelapsca" e' una URL perche' la identifica
> la anche dice dove si trova.
>
> Qualche purista potrebbe dirmi che "Andrea Peri" e' una URN dove "N"
> sta per named, ma lasciamo stare.
>
> QUindi tornando rapido alla coupled resource richiesta nel metadato:
> dovendoci scrivere una URI di una risorsa che e' un servizio, per me
> li' ci va' scritto la URI di un layer accessibile da un sefvizio WMS.
>
> Nel mio caso il servizio da metdatare e' il sevizio del WMS della
> carta tecnica regionale, e quindi io li ci scriverei:
>
> L?indetificazione del layer, ma per identificar eun layer di un
> servizio wms in maniera univoca, non basta metterci il suo titolo, ma
> serve una URIche garantisca una sua univocita'nell'universo degli
> indirizzi internet.
> Per cui, a parer mio li' ci va qualcoa di questo genere:
>
> http://www502.regione.toscana.it/wmsraster/com.rt.wms.RTmap/wms?map=wmsctr&SERVICE=WMS&VERSION=1.3.0&REQUEST=GetMap&BBOX=543700.5660000294446945,4667876.0815514046698809,787054.3719934058608487,4933661.3955681109800935&CRS=EPSG:25832&WIDTH=307&HEIGHT=335&STYLES=&FORMAT=image/png&TRANSPARENT=TRUE&LAYERS=rt_ctr.10k
>
> In cui la prima parte e' una URL che localizza il servizio wms in cui
> e' sito il layer, della parte restante, ci va sicuramente il codice
> identificativo del layer che nel nostro caso e':
> rt_ctr.idpgeodet.10k.rt
> Tutto il rimanente, non  altro che il completamente diuna chiamata
> GetMAP verso lo specifico server wms per permettere di recuperare una
> mappa di tale layer.
> Questo perche' la mia interpretazione e' che dovendo dare una URI che
> identifichi il layer, ho ritenuto preferibile metterci qualcosa che
> fosse anche URL.
> Visto che la URL e' un caso particolare di URI.
> Ma la URL deve essere un link funzionante altrimentinon e' vero che
> localizza e quindi ho dovuto completare la stringa con tutti i
> parametri per fare funzionare il link.
>
> Questo per spiegare il senso di come avrei interpretato tale campo.
>
> Non è finita qui.
> Infatti se la coupled-resource e' la enunciazione di tutti i dataset
> raggiungibili in quel servizio, e poiche' essa puo' avere molteplicita
> N.
>
> Nel caso specifico del servizio WMS che sto descrivendo, e come spesso
> succede nei servizi WMS non ci sta mai un unico layer WMS; ma spesso
> ce ne sono svariati.
> E quindi queste url ce ne andrebbero non una solamente ma parecchine.
> Una per ogni layers servito da un servizio WMS.
>
> Questa e' la mia interpretazione di tale campo.
> Ancora ho qualche dubbio in merito, anche perche' questa
> interpretazione farebbe crescere a dismisura la scheda di metadato, in
> alcuni servizi wms dotati di molti layers.
> Per cui forse mi sfugge qualche dettaglio e mi farebbe comodo avere
> dei pareri in merito.
>
> Ad esempio:
> Una altra ipotesi poteva essere di inserire  anziche' la URL nei modi
> che ho spiegato, metterci il titolo del layers:
>
> Per cui al posto di tale url , ci potrei mettere il titolo del layer:
> "CTR10K continuum territoriale"
> e lo stesso per gli altri strati.
>
> Oppure ci si poteva mettere il codice identificativo del layer nel wms:
> "rt_ctr.10k"
>
> Oppure qualcos'altro.
> Dipende da cosa si intende per URI e per URL.
> Certo nessuna di queste ultime citate puo' essere considerata una URI
> di livello Universale, l'unica con tali caratteristiche e' la prima
> che ho citato, lo stringone lungo 4 righe.
>
> Graditi pareri in merito e anche esperienze di chi ha gia' dovuto
> compilare schede di metadati di servizi wms.
>
> Grazie dell' attenzione.
>
> --
> -----------------
> Andrea Peri
> . . . . . . . . .
> qwerty àèìòù
> -----------------
> _______________________________________________
> 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.
> 750 iscritti al 18.3.2015
>



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


Maggiori informazioni sulla lista Gfoss