GML Coordinaatrererentiesysteem WGS 84 / EPSG 4326 niet correct opgepakt door GraphDB ?

[MarinusVonhof]

Tijdens de proef met datastory "Rioleringsgebieden": GraphDB met optie GeoSPARQL verwacht in de GML-syntax de volgorde long/lat (conform WKT-syntax), volgens het GML-schema is de volgorde echter lat/long

[reinvantveer]

Klopt, maar niemand houdt zich aan de standaard. Alle gis clients, inclusief die van epsg.io werken met lon/lat asvolgorde. Zie ook in QGIS de asvolgorde in WGS 84, die volgt ook altijd x/y oftewel lon/lat (of formeler: lambda/phi)

[MarinusVonhof]

Ok Rein, maar mijn probleem was dat QGIS lat/lon verwachtte en GeoSPARQL lon/lat . Blijkbaar werkt het toch iets anders, daardoor was de GML-notatie niet bruikbaar. Maar goed, met de WKT notatie is zo wie zo opgelost.
NB: In GML verwees ik naar de "europese" srs EPSG:4258 omdat ik jouw module "rdnaptrans" heb gebruikt.

[reinvantveer]

Ja, er is nogal een dingetje aan de hand met WGS84 en ETRS89. De formele definitie is in lat/lon maar niemand past het op die manier toe: iedereen verwacht en gebruikt een asvolgorden in x/y resp. lon/lat...

[FransKnibbe]

Op termijn is wellicht een oplossing om een versie van ETRS89 (http://www.opengis.net/def/crs/EPSG/0/4258) te hebben waarbij de assen zijn omgedraaid, net als bij CRS84 (http://www.opengis.net/def/crs/OGC/1.3/CRS84). Het Kadaster kan in principe een alternatieve definitie van ETRS89 in GML voorleggen aan het OGC, zodat het OGC, na controle, die definitie met een persistente URI kan publiceren. Die URI kan dan vervolgens gebruikt worden om het gebruikte coördinaatsysteem aan te duiden in datapublicaties.

[reinvantveer]

Er zijn geen problemen meer in de huidige data story t.a.v. dit issue, dus ik sluit deze.