Verificatie van coordinaten als array bij NSGI

[marcvanandel]

Naar aanleiding van comment in issue #93 te rade gaan (intern Kadaster en) NSGI over coordinaten(systemen)

Misschien goed om het besluit nog even te toetsen bij de NSGI, de autoriteit voor coordinaten(systemen) in Nederland. Zij adviseren ook de diverse basisregistraties en geo-standaarden over de juiste keuze en formulering. https://www.nsgi.nl/

[Jochem-L]

Ik heb issue #93 vluchtig bekeken en ik zie in ieder geval al wat punten waar het het (wat betreft terminologie) beter kan:

• WGS84 is ongeschikt als nauwkeurig coördinatensysteem, omdat deze term en bijbehorende code EPSG:4326 meerduidig is en daardoor een onnauwkeurigheid van 2 meter heeft. Een specifieke realisatie van WGS84 gebruiken lost deze meerduidigheid op, maar dat heeft weer een ander bezwaar (zie volgende punt).
• WGS84 is eigenlijk sowieso ongeschikt voor een Nederlandse standaard, omdat het uitsluitend gebruikt wordt voor het GPS-systeem van de VS. Andere "GPS-systemen" (GNSS) zoals het Europese Galileo gebruiken andere coördinatensystemen. Het lijkt mij daarom beter om het officiële internationale coördinatensysteem ITRS (huidige realisatie ITRF2014, EPSG:7912) te gebruiken.
• Coördinaten met de letters x, y, z aanduiden is onjuist voor geografische coördinaten zoals van ITRS en WGS84. Voor geografische lengte en breedte (Engels: longitude en latitude) zijn de symbolen λ en φ (Griekse letters lambda en phi) gebruikelijk of de afkortingen lon en lat. In de presentatie naar eindgebruikers is het gebruikelijk eerst de breedte en dan de lengte te geven. Voor de bijbehorende ellipsoïdische hoogte wordt wordt de kleine letter h gebruikt. Voor RD-NAP-coördinaten is het netter om coördinaten met x, y en hoofdletter H aan te duiden of om de afkorting NAP te gebruiken voor de hoogte.

Voor vragen of overleg kun je mailen naar rd(a)kadaster.nl

PS: In veel gevallen is een wereldwijd coördinatensysteem zoals ITRS en WGS84 helemaal niet handig. Door het verschuiven van de continenten veranderen alle coördinaten namelijk continu. Het Europese geografische coördinatensysteem ETRS89 (aanbevolen realisatie ETRF2000, EPSG:7931) is voor veel toepassingen handiger omdat coordinaten daarin niet met 2,5 cm per jaar naar het noordoosten bewegen zoals in ITRS en WGS84.

Jochem Lesparre Rijksdriehoeksmeting Kadaster Nederlandse Samenwerking Geodetische Infrastructuur (NSGI)

[marcvanandel]

Super comments @Jochem-L !! 🎉 Heel hartelijk dank!

Begrijp het goed dat x,y,H (NAP) een (voldoende) juiste notatie zou kunnen zijn? Of heb je nog een betere suggestie?

Ik vraag me af:

• wat gemakkelijk, gebruikelijk is bij invoeren van gegevens?
• wat gemakkelijk, gebruikelijk is bij projectie op de kaart / begrip van 'de leek'? (daar val ik zeker onder 😁 )
• wat nodig is om projectie op een hoogtekaart mogelijk / toegankelijk / gemakkelijk te maken?

Heb je nog goede suggesties?

[Jochem-L]

Ik heb je gemaild op je Kadaster-emailadres.

[marcvanandel]

@Jochem-L , @celinejansen, @kad-griftj , kunnen wij binnenkort hier een overlegje over inplannen? Het is niet echt mijn terrein en ik kan het wel volgen ... maar ik durf daar niet zelf een beslissing in te maken 😉

[CelineJansen]

@marcvanandel, ja hoor wat mij betreft oké.

[Jochem-L]

Prima, stuur maar een vergaderverzoek naar mijn Kadaster-emailadres.

[marcvanandel]

OK. Vergaderverzoek ga ik maken.

[marcvanandel]

Wellicht moeten we meerdere opties ondersteunen voor de opslag omdat er verschillende niveaus van kwaliteit zijn. In de presentatie (aan de burger) kan (natuurlijk) slechts één coördinaten stelsel worden gepresenteerd.

Met dit issue willen we een slimme keuze maken over hoe we locatie gaan opslaan. Dat raakt ook wel visualisatie en publicatie ... maar laten we beginnen met wat we willen opslaan om dat later goed te kunnen visualiseren ...

[Jochem-L]

Volgens mij moet het juist andersom:

• Eén CRS voor opslag, dat kan RDNAP of ETRS89 zijn, maar twee CRS-en lijkt me erg onhandig (wel bijhouden in welk CRS data aangeleverd is en hoe het getransformeerd is voor het CRS van opslag);
• Presentatie van coördinaten aan burger en professionele klanten in zowel RD-NAP- als in ETRS89-coördinaten;
• Visualisatie uitsluitend in RD-projectie.
• Kwaliteitsniveau kan beter los van het CRS geregistreerd worden.

[jeroengrift]

Volgens Wim kan je alleen lon/lat opslaan in MongoDB (https://docs.mongodb.com/manual/reference/geojson/). Misschien dit nog even een keer checken. Als je RD (NAP) zou kunnen opslaan ben je denk ik van het hele probleem af. Momenteel worden de coördinaten zoals je die met een klik op de kaart binnenhaalt (Openlayers) geconverteerd met Proj4 van RD naar WGS84, bij het ophalen en tonen van de data gebeurd dit andersom.

[CelineJansen]

Het moet in elk geval duidelijk zijn in welk CRS gebruikers coördinaten kunnen aanleveren (dus nog een stap eerder dan opslaan). Nu kan dit alleen in [lat,lon,h] (vermoedelijk WGS84), maar dat staat er niet bij.

Het opvoeren in RD werkt niet, en als je opvoert in ETRS89 en dit wordt gewoon gelijk gesteld aan WGS84 zonder transformatie, dan kunnen er dacht ik toch ook tot op ongeveer een meter verschillen ontstaan (?)

Volgens mij spelen er dus de volgende vragen:

• In welk CRS kunnen gebruikers sensoren opvoeren?
• Staan we opvoer in verschillende CRSs toe? Zo ja: Hoe achterhalen we welk CRS de gebruiker gekozen heeft? (bijvoorbeeld door ze de EPSG code te laten vermelden in een bijkomstig attribuut). Voor de presentatie coördinaten transformeren en opslaan waar nodig. Zo nee (misschien makkelijker in de ontwikkeling): Maak dan duidelijk in de documentatie in welk CRS coördinaten moeten worden aangeleverd. Risico hierbij is dat je weinig beeld hebt bij de kwaliteit van mogelijk transformaties die gebruikers hebben moeten doen om tot het gewenste oplever CRS te komen en überhaupt wat de oorspronkelijke kwaliteit van de locatie was. Voor de toepassing binnen sensrnet hoeft de locatie misschien niet heel precies bekend te zijn, maar als coördinaten geleverd dienen te worden in RD, en deze eerst door de sensor zelf dmv GPS zijn vastgesteld, dan kan er alsnog best sprake zijn van afwijkingen die misschien groter zijn dan nodig.

[kad-bloemy]

@marcvanandel Wat is de status hiervan? Komt er nog een afspraak met Céline en Jochem?

[marcvanandel]

• Eerst breedtegraad en dan lengtegraad (is gebruikelijk; de volgorde is verschillend tussen GIS pakketten en de traditionele notatie)
• Hoogte zou vanaf maaiveld moeten zijn ... en eventueel omrekenen naar NAP?
• Hoogte zou wellicht optioneel moeten zijn (in het kader van niet opgeven wat je niet weet)
• Hoogte kunnen kiezen naar 'hoogte boven de grond (= maaiveld)' of 'hoogte NAP'
• In API dezelfde naamgeving van velden als in de frontend

RD is van alle basisregistraties en daarom het meest logisch is. Dit is in meters. Vanuit de basisregistraties het meest logisch ... maar GPS sensoren kennen dit systeem niet. Topografisch ingemeten objecten zijn in RD ingemeten. ETRS89 zou ook kunnen.

1. Klikken in de kaart -> RD op 1m nauwkeurig
2. Opvoeren coordinaten -> RD precies (optioneel datum van locatie meting meegeven?)
3. Opvoeren GPS coordinaten in WGS84 (eventueel optie voor ETRS89 voor nauwkeurigere GPS - is in opkomst ??)

Opslag in MongoDB moet 'heen en terug' op dezelfde manier hetzelfde zijn. De transformatie zou kunnen mbv de API van NSGI (NSGI.nl coordinaten transformaties; vote for WGS84 transformatie?). Transformatie zou in Proj6 moeten zijn, maar de frontend bevat nu Proj4.

Bekende EPSG codes zijn in 2D. Er zijn ook 3D EPSG codes ... maar die zijn erg onbekend.

WGS84 is gekoppeld aan het Amerikaanse GPS. ITRS is het Europese systeem.

Nauwkeurige metingen worden in RD of ETRS89 uitgedrukt omdat deze systemen de verschuivingen in de aardplaten juist meenemen (á 2.5 cm per jaar). RDNAP is 3D (nauwkeurig). ETRS98 kent een 2D en een 3D variant.

Hoogte in meters ... of in verdiepingen? En als administratief veld ... dan zou zelfs tekst ingevuld kunnen worden?

Vraag voor de pilots: Welk coordinaten systeem gebruiken jullie en hoe rekenen jullie dat om?

• [ ] coordinaten systeem transformatie uit de frontend halen
• [ ] opslag in EPSG codes
• [ ] WGS84 GPS coordinaten kunnen in 3 verschillende notaties opgegeven worden ... en daar zullen we de gebruikers goed in moeten meenemen (decimale graden, graden+minuten+seconden, ... ?)
• [ ] uitwerken wat in de frontend ingevoerd moet kunnen worden
• [ ] uitwerken wat in de API ingevoerd moet kunnen worden
• [ ] validatie in de API van coordinaten die binnen NL vallen (2-8 oostenlengte, 50-56 noorderbreedte)

[Jochem-L]

Prima samenvatting op een paar slordigheden/misverstanden na:

• Punt 2: Het opgeven van een datum van locatiemeting is voor RD niet echt nodig, wel voor WGS84. Dit dus verplaatsen naar punt 3?
• De nauwkeurige transformatie RDNAPTRANS2018 naar RD en NAP kan met alle PROJ-versies vanaf PROJ6 (de actuele versie is PROJ8).
• ITRS is niet een Europees systeem. ITRS is het officiële internationale coördinatensysteem waar WGS84 tegenwoordig nooit meer dan enkele centimeters van afwijkt. Het officiële Europese coördinatensysteem is ETRS89. Het Europese GNSS-systeem is Galileo.
• 3e checkbox: de 3 notaties voor geografische coördinaten zoals WGS84 zijn: decimale graden (bijv. 52,209583°NB) vooral gebruikt voor opslag in (GIS)software, gehele graden en decimale seconden (bijv. 52°12,575'NB) vooral gebruikt in consumenten GPS-ontvangers, en gehele graden, gehele minuten en decimale seconden (bijv. 52°12'34,5"NB) de traditionele notatie.

[marcvanandel]

OK. Eindelijk kom ik er aan toe (neem ik de tijd) om dit punt 's verder uit te werken ... 😄

In de API en events zou ik graag zoveel mogelijk vrijheid willen behouden én zou ik graag zoveel mogelijk de originele getallen willen vastleggen. Dat betekent wel dat het duidelijk moet zijn wat het is, wat er ingevoerd wordt. M.a.w. de API (en events) moeten zodanig gewijzigd worden dat geolocatie een coördinatensysteem is plus de bijbehorende getallen.

In de UI zullen we gebruikers moeten helpen om een juiste keuze te maken voor het coördinatensysteem behorend bij hun geolocatiegegevens. Kunnen we hiervoor een gecombineerd veld maken van waarde en EPSG systeem, waarbij het EPSG systeem een dropdown is waar je in kunt kiezen? En bestaat er een library die gegeven een bepaalde notatie een goede suggestie kan doen op gebruikte systeem? Dat zou wel cool zijn, niet? Bij het ontbreken van zo'n library stel ik voor om de dropdown voor dit moment te beperken tot 2 opties: RD (op 1m) of WGS84. Bij deze laatste behoort ook extra info over de datum van het bepalen van de coördinaten. Kunnen we dat kwijt in de geolocatie data (a.k.a. API + events)?

• [ ] backend API en events aanpassingen om EPSG systeem en datum te kunnen vastleggen
  • [ ] API aanpassen zodat EPSG code opgegeven moet worden bij de (getallen van de) geolocatie
  • [ ] events aanpassen zodat EPSG code opgegeven moet worden bij de (getallen van de) geolocatie
  • [ ] API aanpassen zodat datum van bepalen van de locatie optioneel opgeslagen kan worden (oa in geval van WGS84)
  • [ ] events aanpassen zodat datum van bepalen van de locatie optioneel opgeslagen kan worden (oa in geval van WGS84)
• [ ] frontend / UI geolocatie component aanpassen om EPSG systeem en datum te kunnen invoeren
  • [ ] JavaScript lib zoeken die op basis van notatie (format) van een geolocatie een suggestie kan doen voor gebruikte EPSG systeem
  • [ ] frontend / UI component voor locatie aanpassen naar de combinatie van EPSG systeem + coördinaten, waarbij het EPSG systeem een dropdown moet zijn en de coördinaten getallen, graden, leestekens en (hoofd)letters
  • [ ] frontend / UI component uitbreiden met validatie van notatie op basis van gekozen EPSG systeem?
  • [ ] frontend / UI component uitbreiden met 'tooltips' cq documentatie in het formulier over hoe in te vullen en te gebruiken. Extra tip zou kunnen zijn hoe je een graden karakter (°) kan invoeren (Alt 248)

Voorbeeld UI component:

(voorbeeld gemaakt mbv angular bootstrap input group (specifically: custom-select))

[Jochem-L]

Een EPSG-code suggereren op basis van notatie van coordinaten is ondoenlijk als je lokatie overal ter wereld kan zijn en het iedere EPSG-code zou kunnen zijn. Ik denk dus niet dat er een library hiervoor is.

Als je binnen een ruime rechthoek om Nederland moet achterhalen of iets WGS84 of RD is kan dat wel:

• voor WGS84 is de noorderbreedte tussen 50 en 56 graden.
• voor WGS84 is de oosterlengte tussen 2 en 8 graden.
• voor RD is de x-coordinaat tussen -90 000 en 345 000 m
• voor RD is de y-coordinaat tussen 225 000 en 900 000 m

Als je zeker weet niet op zee en binnen de landsgenzen te zitten, dan kan je nog strakker toetsen.

Ik zou afzonderlijke invoervelden maken voor NB en OL. Dat voorkomt dat de gebruiker het verkeerdom invult. Als je ook afzonderlijke invoervelden voor graden minuten en seconden maakt heb je ook geen problemen met graden tekens. Daarbij moeten bij decimale graden dan de minuten- en secondenvelden disabled worden.

[marcvanandel]

Scherpe toevoegingen! Dat maakt het inderdaad nog scherper! Dan wordt het een dropdown om een EPSG systeem te kiezen en vervolgens moeten de verschillende velden worden gepresenteerd om juist in te vullen. Dat moet wel kunnen ... al is dat niet direct eenvoudig 😝 #developerschallange 😉

Het is niet zeker dat er geen sensoren op zee worden geregistreerd. Sterker nog, er zitten nu al sensoren op de windmolens op zee! Ik zou daarom verwachten dat de kans dat een sensor op zee wordt geregistreerd eerder groot is dan klein 😄

[marcvanandel]

@marcvanandel issues aanmaken tbv realisatie

[marcvanandel]

https://docs.geostandaarden.nl/crs/crs/