Le organizzazioni che gestiscono i dati spaziali incontrano delle difficoltà nell’organizzare il proprio repertorio di dati mantenendo la compatibilità con gli altri standard Europei. Questo succede per la forte dipendenza esistente tra i sistemi proprietari di acquisizione e di mantenimento dei dati spaziali e le modalità di strutturazione e codifica dei dati in altre organizzazioni della stessa nazione. La soluzione prospettata è quella di costruire un servizio real-time di conversione compatibile con tutte le specifiche della Comunità evitando così i costi di nuove applicazioni «ad hoc» per la conversione o per il mantenimento di un database comune.

Il primo tentativo di stabilire l’interoperabilità tra sistemi di coordinate diverse risale al 2001 con il  OpenGIS^® Implementation Specification: Coordinate Transformation Services.
Il problema veniva affrontato con la scomposizione dell’interfaccia del servizio in 3 packages (Positioning,   Coordinate Systems,  Coordinate Trasformation) e con il richiamo alle infrastrutture COM, CORBA ed al linguaggio Java. Alcune entità geometriche venivano descritte con il WKT (Well Know Text) utilizzato anche da ESRI per i file di definizione del sistema di riferimento .prj .
Il documento non è stato più aggiornato.

Successivamente nel WCTS (dal documento OGC Web Coordinate Transformation Service Interface Engineering Report del 2007 ) vengono descritti alcuni casi studio di un certo interesse: ne riporto uno che descrive adeguatamente il problema.
Nella Repubblica Federale Tedesca esiste della cartografia nella quale
a) i confini (layer 1) sono in EPSG:31467
b) i fiumi (layer 2) sono nel EPSG:4230
c) le città (layer 3) sono in  EPSG:4326
Deve essere creata una mappa in EPSG:23032
Il processo dovrebbe funzionare così:
- L’applicazione definisce un nuovo layer in EPSG:23032
- L’applicazione riconosce che il layer 1 non si trova in EPSG:4326
- L’applicazione si connette al WCTS e richiede le sue capabilities
- L’applicazione valuta se se può trasformare EPSG:31467 in EPSG:4326 (con la 
   richiesta IsTransformable)
- L’applicazione invia i dati del layer 1 al WCTS richiedendo la trasformazione  
   in EPSG:4326
- Il WCTS restituisce i dati trasformati
Il processo prosegue con i layer 2 e 3. Al termine il WMS restituisce la mappa sul browser del client.

Successivamente nel WCTS (dal documento OGC Web Coordinate Transformation Service Interface Engineering Report del 2007 ) vengono descritti alcuni casi studio di un certo interesse: ne riporto uno che descrive adeguatamente il problema.
Nella Repubblica Federale Tedesca esiste della cartografia nella quale
a) i confini (layer 1) sono in EPSG:31467
b) i fiumi (layer 2) sono nel EPSG:4230
c) le città (layer 3) sono in  EPSG:4326
Deve essere creata una mappa in EPSG:23032
Il processo dovrebbe funzionare così:
- L’applicazione definisce un nuovo layer in EPSG:23032
- L’applicazione riconosce che il layer 1 non si trova in EPSG:4326
- L’applicazione si connette al WCTS e richiede le sue capabilities
- L’applicazione valuta se se può trasformare EPSG:31467 in EPSG:4326 (con la 
   richiesta IsTransformable)
- L’applicazione invia i dati del layer 1 al WCTS richiedendo la trasformazione  
   in EPSG:4326
- Il WCTS restituisce i dati trasformati
Il processo prosegue con i layer 2 e 3. Al termine il WMS restituisce la mappa sul browser del client.

In seguito l’approccio di INSPIRE nel Draft Technical Guidance for INSPIRE Coordinate Transformation Services del 2010 è quello di incorporare la fondamentale operazione Transform di WCTS e considerare l’operazione IsTransformable come un parametro opzionale. Tutte le altre operazioni restano escluse.
L’operazione Transform diventa una Application Profile (AP) della specifica WPS (descritta più avanti).
L’input del WCTS Transfer diventa l’input di Transform Coordinates.
L’AP viene definito come:
a) un OGC URN (Uniform Resource Name) che identifica il processo
b) un messaggio relativo alla request DescribeProcess
Inoltre l’AP utilizzato all’interno del WPS necessita dell’uso del SOAP (Simple Object Access Protocol, un protocollo leggero per lo scambio di messaggi tra componenti software) e di WSDL (Web Services Description Language, linguaggio formale in formato XML per la definizione di documenti nella descrizione di servizi web) nonchè di codici di exception non standard per relazionarsi con l’operazione IsTransformable.

Gli obiettivi del WPS ( OpenGIS® Web Processing Service OGC 2007) erano, quando il servizio è stato portato sul WCTS,  quelli di consentire ai clienti l’accesso a calcoli pre-programmati o a modelli computazionali relativi a dati spaziali acquisibili da un network o posizionati su un server. I dati possono essere espressi sia in forma di immagini che secondo il linguaggio GML (Geography Markup Language). L’uso di questi dati richiede Web Services che supportino operazioni spaziali «atomiche» e sofisticate capacità di modellazione.
Esistono 3 operazioni fondamentali nel WPS:
a) GetCapabilities (per ottenere nomi e descrizioni generali dai processi  offerti da una richiesta WPS)
b) DescribeProcess (per ottenere dettagli sul processo gestito dal servizio inclusi gli input, i formati, gli output relativi)

c) Execute (per mettere in moto il processo richiesto usando gli adeguati  parametri di input ed ottenendo le risposte attese)
WPS è un’interfaccia generica standardizzata al fine della interoperabilità: non identifica nessuno dei processi specifici per i quali è stata costruita oltre gli input e gli output.
Al fine di ottenere un’alta interoperabilità ogni processo può essere definito da un AP. Questo consiste in
1) un OGC URN nel quale le infrastrutture spaziali pongono una
    repositoria che contenga una gerarchia semantica dei processi noti
2) una risposta di riferimento alla richiesta DescribeProcess
3) documenti e descrizioni WSDL opzionali

c) Execute (per mettere in moto il processo richiesto usando gli adeguati  parametri di input ed ottenendo le risposte attese)
WPS è un’interfaccia generica standardizzata al fine della interoperabilità: non identifica nessuno dei processi specifici per i quali è stata costruita oltre gli input e gli output.
Al fine di ottenere un’alta interoperabilità ogni processo può essere definito da un AP. Questo consiste in
1) un OGC URN nel quale le infrastrutture spaziali pongono una
    repositoria che contenga una gerarchia semantica dei processi noti
2) una risposta di riferimento alla richiesta DescribeProcess
3) documenti e descrizioni WSDL opzionali

Un implementazione del CTS di INSPIRE è stata realizzata con successo da due studiosi (geodeti) finlandesi Kovanen e Lehto (INSPIRE Coordinate Transformation Service;the Specification and Experiences Gained from a Pilot Implementation). Nella sperimentazione(FGI Coordinate Transformation Service) hanno utilizzato per l’accesso al WPS Java 1.5. Il WPS legge i dati dell’operazione Execute con un XML encoded SOAP Envelope. Se l’operazione ha successo le coordinate espresse in GML vengono lette da un SAX parser che riproduce anche l’id del CRS.
La trasformazione avviene utilizzando il software OpenSource Geotools che consente la trasformazione tra dozzine di coordinate diverse. I dati in uscita son affetti da un errore di  0,1 mm (cioè i gradi sono espressi con 9 cifre decimali), errore tollerabile nelle applicazioni che fanno riferimento ad INSPIRE. Il parser SAX inoltre comunica durante il calcolo lo stato progressivo dell’operazione. Purtroppo attualmente il database dei CRS europei è incompleto: probabilmente comprenderà in breve tempo anche i sistemi di riferimento EVRF2007 ed ETRS89.