lvdbrink
commented
1 year ago Punt 16 besproken 11/4: we nemen de opmerking over geojson over. Linda maakt een issue aan bij de handreiking CRS en de handreiking geometrie om deze informatie volledig (over geojson, html en gml) op te nemen.
Paragraaf 2.1: Voeg bij CRS84 de identificatie (OGC:CRS84) toe. Dit is consequent met het gebruik van de conventie (Authority:CRS) zoals die in het document ook wordt gebruikt voor EPSG-coded, bv (EPSG:28992).
Paragraaf 2.2: Een operator zoals intersects of within geeft grote fouten als de geografische coördinaten als rechthoekig beschouwd worden: verwijs naar langelijnenadvies. Bij RD-coördinaten is de fout veel kleiner en meestal verwaarloosbaar gezien de precisie van de data. Maar ook dan kan het onwenselijk zijn als hierdoor requests voor identieke geometrieën in RD en ETRS89 inconsistente responses geven.
Inleiding hoofdstuk 3: De zin The default CRS for GeoJSON and for OGC API Features is WGS 84 with coordinate order longitude-latitude, also referred to as "CRS84" is niet correct, het is andersom. Suggestie: The default CRS for GeoJSON and for OGC API Features is CRS84 (OGC:CRS84), this is WGS 84 with coordinate order longitude-latitude.
Inleiding hoofdstuk 3: Een voorbeeld van een ensemble en een member zou hier verhelderend zijn.
Paragraaf 3.2 eerste alinea: “Due to the datum and the tectonic displacements it is not accurate enough for local coordinate reference systems …”. Dit is niet correct, CRS84 is onnauwkeurig doordat de definitie niet eenduidig is én het niet nauwkeurig gerealiseerd kan worden, dat staat los van platentektoniek. Suggestie “For accurate applications the use of the CRS84 ensemble is not suitable…”.
Paragraaf 3.2 eerste alinea: Niet handig om hier de ensemblecode van ETRS89 te noemen.
Paragraaf 3.2 eerste note: Het lijkt me handig hier te vermelden dat de 2D en 3D varianten van een CRS eigen identifiers hebben.
Paragraaf 3.2: De tekst is niet consequent en gebruikt zowel RD-NAP als RD/NAP.
Paragraaf 3.2: In het Engels is het null transformation met dubbel L en een spatie.
Paragraaf 3.2: Een van onze eerdere aanbevelingen ontbreekt: Dat als een null transformation gebruikt wordt tussen twee CRS, bijvoorbeeld voor ETRS89 - WGS 84, dat dan de API beide CRS-en moet ondersteunen, bijvoorbeeld naast WGS84 ook ETRS89.
AP_GEO-9: Geef hier de namen ETRS89 en ETRF2000 ipv EPSG-codes.
Paragraaf 3.2 laatste tabel: ETRF2000 XYZ weglaten of XYZ bij ook bij ETRS89, ITRF2014 en WGS84 toevoegen.
Paragraaf 3.2 laatste tabel: Notatie van 3D geografische coördinaten is inconsequent: geen toevoeging, LatLonEHt en longitude-latitude-height. Officiële namen zijn zonder de toevoegingen.
Paragraaf 3.2 laatste tabel: Opmerking toevoegen dat er steeds nieuwe realisaties van ITRF gebruikt worden en ITRF2020 al beschikbaar is. En dat dit bij ETRF (nog) niet zo is.
Paragraaf 3.3: RDNAPTRANS is geen software maar een procedure. Suggestie: Laatste zin weglaten.
Volgorde van coördinaten OGC API uitwisselingsformaat afhankelijk Het lijkt me goed om duidelijk te maken wat de afspraken zijn voor de volgorde van coördinaten in specifieke formaten afhankelijk is, zoals daar ook aandacht voor is in de OGC API – Features _ Part 2: https://docs.ogc.org/is/18-058/18-058.html#_output_format_considerations . Dit kan in deze extensie, de handreiking CRS óf de handreiking Geometrie in uitwisselingsformaten (https://geonovum.github.io/geox/).
Concreet betekent dit: GeoJson: Uitwisseling conform https://www.rfc-editor.org/rfc/rfc7946#section-3.1.1, longitude, latitude voor geografische systemen en easting, northing voor geprojecteerde systemen (en niet gespecificeerd voor geocentrische systemen dus X,Y, Z?).
HTML: Blijkbaar wordt in HTML enkel WGS 84 in de volgorde latitude / longitude toegestaan.
GML: In GML wordt de volgorde van de assen van het CRS gehanteerd zoals gespecificeerd in de NTS. (maar dan is het voorbeeld hier onjuist? https://geonovum.github.io/geox/#gml-polygoon , omdat EPSG:4326 als volgorde lat-lon heeft en niet lon-lat, bedoeld wordt waarschijnlijk OGC::CRS84 ipv EPSG::4326 in dat voorbeeld)