Waarom wordt WGS84 gebruikt in GIS- geostandaarden?

Standaarden
#1

Telkens weer verbaas me ik me over de hardnekkighied waarin het gebruik van WGS84 als default CRS/ellipsoide in GIS en geostandaarden terugkomt voor het uitwisselen van data. Ook deze keer bevat mijn weekelijkse Geoforum samnevatting email weer zo een onderwerp:

En er zijn nog meer voorbeelden te vinden op dit forum via: Zoekresultaten voor 'WGS84' - Geoforum

ITRS of ETRS89 (met bijbehorende GRS80 ellipsoide) zijn meer geschikt voor datauitwisseling dan WGS84, het belangrijkste argument voor ITRS of ETRS89 is dat deze systemen en hun relaties preciezer zijn gedefinieerd en de systemen toegangkelijker zijn voor precieze dataintwinning dan WGS84.

Sterker, alle argumenten die beweren dat WGS84 meer geschikt is dan ETRS89 gelden voor zover ik weet ook voor ITRS. De argumenten die beweren dat ETRS89 meer geschikt is dan WGS84 gelden meestal ook voor ITRS. Kortom als WGS84 geschikt is, dan is ITRS ook geschikt. In veel gevallen geldt dat als ETRS89 geschikt is, ITRS ook geschikt is. Interessant is nog wel om de situaties waarin ITRS niet voldoet en ETRS89 wel voldoet verder te analyseren.

Ik zou graag van het ongeschikte WGS84 af willen als de default. Toch bekruipt mij in (het lezen van) discussies altijd het gevoel dat ik iets mis. Er moet een reden zijn dat WGS84 telkens oppopt als de default, ondanks dat specialisten dit afraden. Blijkbaar voorziet het gebruik van WGS84 als default in een behoefte die ik niet snap.

Daarom de vraag: Waarom wordt WGS84 gebruikt in GIS en geostandaarden als het default CRS?

Ik ben benieuwd naar nieuwe inzichten naar aanleiding van de reacties.

2 likes
28 oktober 10:00-12:30: Denk mee! Vorming Praktijkrichtlijn Vector Tiles (aanmelden mogelijk)
#2

Mee eens, voor het uitwisselen van data (zeker in NL, EU) lijkt mij WGS84 zeker niet de meeste geschikte kandidaat. Denk wel dat het goed is om onderscheid te maken tussen uitwisselen en gebruik.

Bij PDOK zien we dit met het gebruik van WGS84 (dit is enigszins een aanname) dat dit vaak vanuit applicaties als maps.google.com /android/iOS/enz… komt. Gebruikers/ontwikkelaars van deze applicaties hebben dan vaak als eerste CRS/PROJ ervaring WGS84. Wat dan als de ‘default’ wordt aangenomen en dan als gevolg heeft dat men alles in WGS84 willen consumeren. Daarnaast denk ik ook dat een spec als GeoJSON dit beeld ‘versterkt’ waarin het gebruik van andere CRS uit de spec is gehaald.

Ik vermoed dat (zeker) niet Geo/GIS developers eerder in ‘aanraking’ komen met WGS84 dan RD en/of ETRS89.

#3

Sowieso specificeert de WMS standaard dat alle WMS-services WGS84 moeten ondersteunen. Ook als zij dit niet adverteren in het capabilities document.

Vanwege backwards-compatibiliteit lijkt het me goed dat dit steeds voor evt nieuwe versies van die standaard vasthouden.
Iets vergelijkbaars geldt voor standaarden voor bestandsformaten als GeoJSON, gpx en kml.

Wellicht een historisch artefact, maar daar komen we niet zomaar meer vanaf.

Groet, MArco

#4

Ik neig er naar om een label “WGS84” zonder vermelding van de realisatie en epoche te interpreteren als geografische coördinaten in onbekend CRS. Dat lijkt me een zeer onwenselijk label dat uitgefaseerd zou moeten worden voor data met submeter-precisie.

#5

Dit gaat trouwens ook op voor de nieuw OGC API standaarden, zoals OGC API Featues (OAF) waarin de Core van de spec men uitgaat van WGS84 (dat lees ik als: minimal requirements). De vraag daarbij is dan laten implementaties daarvan (bijv: Geoserver, pygeoapi, enz… ) het toe om voor een bepaalde dataset/layers/features dan überhaupt geen WGS84 als optie uit te serveren/aan te bieden.

Ook het W3C refereert naar WGS84 als: “One CRS to rule them all?”

Of daar dan mee (nu nog) de juiste keuze is gemaakt is een tweede…

#6

De EPSG registry (de facto standaard) voor CRS-definities en transformaties interpreteert “WGS84” eigenlijk zoals ik: als geografische coördinaten zonder nauwkeurige transformatie. Kijk maar eens naar de volgende twee voorbeelden.

Als je op basis van de EPSG registy:

  • WGS84 (crs-code 4326) naar ETRS89 (crs-code 4258) transformeert, dan wordt er een nul-transformatie toegepast (transfm.-code 1149) met een nauwkeurigheid van 1 meter.
  • WGS84-G1762 (crs-code 7665) naar ETRF2000 (crs-code 7931) transformeert, dan wordt er een tijdsafhankelijke transformatie toegepast via ITRF2008 (transfm.-codes 7666 en 7951) met een nauwkeurigheid van 1 centimeter.
#7

Meer nauwkeurigheid dan 1 meter is voor veel (web)toepassingen niet nodig. En ETRS89 is natuurlijk niet voor de hele wereld geschikt. Zie ook Spatial Data on the Web Best Practices en Spatial Data on the Web Best Practices.

2 likes
#8

Bedankt voor de reacties tot nu toe, het is een productief weekend zo.

Ik realiseer me dat ik ook niet goed begrijp waneer gebruik van WGS84 in een standaard of uitwisselingsformaat is vastgelegd en wat het verschil daartussen is, maar dat terzijde.

Mijn voorlopige conclusie is dat het antwoord op mijn vraag Waarom wordt WGS84 gebruikt in GIS en geostandaarden als het default CRS? is.

WGS84 wordt gebruikt in diverse geostandaarden en uitwisselingsformaten, omdat het een wereldwijd referentiesysteem is dat wordt ondersteund door veel applicaties en voldoende nauwkeurig is voor veel toepassingen.
Het laatse, voldoende nauwkeurig voor veel toepassingen, behoeft wel toelichting. De aanduiding WGS84 is namelijk niet eenduidig. Data waarvan de bron niet in WGS84 is maar wel wordt aangeleverd met WGS84 als coordinatensysteem, zijn voor Europees Nederland niet geschikt voor toepassingen met een nauwkeurigheid van beter dan 1 meter. Wereldwijd kan dit oplopen tot veel grotere waarden, maar is in veel gevallen beperkt tot enkele meters.

Op basis van de reacties en de links naar de wiki van de Spatial Data on the Web Working Group geldt volgens mij ook:

Bij het kiezen of formuleren van een standaard/formaat voor het uitwisselen van data is het belangrijk het beoogd gebruik duidelijk te hebben. Indien een nauwkeurigheid van beter dan 1 meter is gewenst, moet de aanbieder een standaard/formaat kiezen die gebruik van andere systemen dan WGS84 toestaat. De gebruiker moet in dat geval ook de data opvragen in een ander systeem dan WGS84.

De oplossing die als voorbeeld wordt gegeven vor de BAG in Spatial Data on the Web Best Practices voldoet dan, OGC CRS84 voor niet nauwkeurige toepassingen en RD voor gebruik met de nauwkeurigheid van de bron.

Tot slot lijkt het me ook dat gebruik van formaten waarin WGS84 verplicht (bijvoorbeeld als minimale vereiste) niet gewenst is voor praktijkrichtlijnen, omdat niet alle datasets bedoeld/geschikt zijn voor toepassingen met een nauwkeurigheid van 1 meter of slechter.

1 like
#9

Wat voor data wordt er in (web)toepassing getoond? Luchtfoto’s, BGT, BRT, BRK hebben allemaal betere precisie dan 1 meter nodig als je wil kunnen inzoomen zonder dat die datasets verschoven weergegeven worden.

Ook voor data buiten Europa is WGS84 (van de Amerikaanse defensie) zonder vermelding van realisatie en epoche niet geschikt. ITRS (van de International Association of Geodesy), is dan een beter alternatief.
ITRS is dan ook door de VN aangewezen als Global Geodetic Reference Frame en de VN Urges Member States to implement […] standards and conventions […] to contribute to the Global Geodetic Reference Frame and regional densifications [like ETRS89] […] in coordination with the International Association of Geodesy.

Persoonlijk ben ik wel voor het gebruik van ITRS in Nederland, maar de meeste gebruikers vinden het niet fijn om met coördinaten die 2,5 cm per jaar veranderen te moeten werken. In Nederland en omstreken is ETRS89 dan toch handiger.

#10

ITRS is ook (inter)nationaal vastgelegd in (NEN-)ISO 19161-1:2020