In che modo le proiezioni ESRI WKT differiscono dalle proiezioni OGC WKT?


9

Qualcuno conosce l'elenco preciso delle differenze tra le stringhe ESRI WKT e OGC WKT?

So che ci sono vari strumenti per aiutare a convertire da ESRI WKT a OGC WKT, tra cui utility GDAL e vari servizi di siti Web. Ma la mia domanda non è di tipo pratico, voglio semplicemente capire le differenze di formattazione / sintassi che utilizzano questi servizi. Le precedenti domande su Stackexchange hanno parlato solo della differenza in esempi specifici o degli strumenti e servizi disponibili.

Anche se conosci solo una differenza, sarebbe fantastico se tu potessi semplicemente postarla. Dalla mia esperienza, ci dovrebbero essere solo una manciata di differenze. Le differenze che conosco sono:

  • la maggior parte degli elementi di testo nella definizione di esri usa il trattino basso dove ogc usa lo spazio.
  • il testo che definisce il dato in esri wkt è uguale a ogc wkt tranne che inizia con "D_".
  • a volte gli identificatori di testo per alcuni PROJCS, PROJECTION, GEOGCS e DATUM predefiniti sono scritti in modo diverso (ad es. "NAD83" in uno essendo "North_American_1983"). Immagino che l'unico modo per sapere quali identificatori sono stati scritti in modo diverso sarebbe quello di avere un elenco o una tabella di ricerca, quindi si prega di nominare quelli che si sa siano diversi.
  • i vari valori del testo PARAMETER sono tutti uguali, tranne che per ogc ogni parola ha il titolo superiore mentre esri ha tutto in minuscolo. Tuttavia, ho visto casi in cui questa regola non è stata utilizzata, qualcuno sa se il titolo è effettivamente importante quando si tratta di software che tenta di caricarli?
  • il tipo di UNIT è scritto titlecase superiore in ogc e minuscolo in esri, ad esempio "Grado" vs "grado". In alcuni casi ho visto ogc scritto sia come "metro" che "m" per "Metro" e in altri casi con "metro" di ortografia francese. Qualcuno sa qual è la convenzione corretta per questi o qualsiasi altro tipo di unità per entrambi i formati?

Risposte:


6

2
Fondamentalmente l'ESRI lo compongono mentre vanno avanti :-)
Ian Turton

1
@iant Essendo stati i primi a implementare una libreria di codici attorno alle specifiche EPSG, non avevano praticamente scelta.
Vince il

2
Probabilmente eravamo secondi - dato che al momento erano disponibili anche le specifiche GeoTIFF. @iant ci sono diverse cose che farei diversamente se costruissimo un nuovo motore di proiezione Esri!
mkennedy,

va bene, quindi molto sembra essere ad hoc, gestione di casi speciali. infatti, a giudicare dai documenti collegati ci sono centinaia di righe di codice di casi speciali in differenze di nome e così via. tutto a causa di diverse implementazioni software e probabilmente mancanza di standard concordati alla volta: p
Karim Bahgat

Sarebbe di grande aiuto se ESRI e GoeoTiff aggiungessero sempre il numero di codice EPSG alla stringa di proiezione WKT. QGIS crea un file .qpj aggiuntivo per gli shapefile per salvare questa impostazione.
AndreJ,

9

Hai colto molte differenze. Esri non ha mai adottato i WKID per gli algoritmi di proiezione della mappa o i nomi dei parametri, quindi sono tutti diversi. Non siamo d'accordo con quanto accuratamente definite le definizioni dei parametri. I nostri sono più generalizzati.

Non supportiamo TOWGS84 né alcune delle parole chiave più recenti.

Quando confrontiamo stringhe (nomi), ignoriamo i caratteri di sottolineatura, GCS_ e D_ e case. Ciò potrebbe non essere vero in altri parser. Il nostro parser è rigoroso sui nomi, ma abbiamo aggiunto alcuni sinonimi e ora conserviamo elenchi di nomi di vari fornitori per i confronti.

Le specifiche originali del sistema di coordinate di OGC non sono diventate specifiche quando si trattava di nomi di oggetti. C'è una nuova specifica OGC / ISO, "Informazioni geografiche - Testo ben noto per lo standard dei sistemi di riferimento di coordinate", che si fa strada attraverso il processo verso la standardizzazione. È molto più specifico su come dovrebbero essere i nomi (abbina il registro EPSG!). Sarà molto eccitante implementare questo standard in futuro.

Divulgazione: lavoro a Esri, sono un membro del sottocomitato che gestisce il registro EPSG ed ero membro del progetto di comitato CRS WKT 2.0.


Wow, è davvero interessante, soprattutto ascoltare alcune delle informazioni interne da qualcuno che ha preso parte al processo decisionale. La nuova specifica OGC ISO sembra molto promettente, pensi sia probabile che molti dei principali fornitori GIS e formati di dati inizieranno a convergere verso l'utilizzo? Sfortunatamente sospetto che alcune delle vecchie differenze continueranno a persistere fino a quando i formati di dati più vecchi rimarranno popolari (es. Shapefile, geotiff).
Karim Bahgat,

Stai dicendo che non stai supportando TOWGS84, ma come possono funzionare le cose senza questo? Se il WKT utilizza nomi sconosciuti (ovvero una proiezione / origine definita dall'utente), il sistema di coordinate non può essere impostato correttamente quando lo spostamento dell'origine viene ignorato. Oppure mi sfugge qualcosa?
PMF,

La maggior parte delle migliori trasformazioni utilizza file grid non un metodo a 3 o 7 parametri. Un sacco di trasformazioni non usano neanche WGS84. È una soluzione molto limitata. Invece, associamo in ritardo ... selezioniamo / impostiamo una trasformazione al momento della trasformazione.
mkennedy,

Se non è noto al sistema, utilizzare lo strumento di trasformazione geografica personalizzata. Il nuovo CRS wkt copre anche le trasformazioni. Arrivare Arron a un software vicino a te!
mkennedy,

0

Come potenziale punto di partenza per un elenco di differenze, potrebbe essere utile vedere il mio nuovo pacchetto PyCRS , dove ho tentato di creare una classe per ogni elemento crs, parametro e nome datum / ellips / proj, insieme al loro ortografia esri_wkt vs ogc_wkt . Ho anche specificato come vedo le differenze di analisi in termini di struttura wkt nel suo insieme nella _from_wkt()funzione nel parser.pysottomodulo. Spero che con i contributi degli utenti queste differenze possano essere ulteriormente aggiunte e / o corrette.

https://github.com/karimbahgat/PyCRS


Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.