ArcGIS Online WFS Lat/Long omgedraaid

Standaarden
#1

Ik heb in mijn ArcGIS Online omgeving een feature layer met puntgegevens. De projectie van de WFS is EPSG:28992. Nu maak ik gebruik van een webapp welke features laat zien van mijn WFS. Deze webapp werkt met EPSG:4326 en filters features met behulp van een bounding box. Wanneer ik een feature laad ziet dat er als volgt uit:

<wfs:member>
...
<Verlichting:Verlichting gml:id="Verlichting.1">
<Verlichting:Shape>
<gml:Point gml:id="Verlichting.1.pn.0" srsName="urn:ogc:def:crs:EPSG::28992">
<gml:pos>162802.07850000 577456.69870000</gml:pos>
</gml:Point>
</Verlichting:Shape>

Ik kan zelf gewoon een filteren met behulp van een bounding box, bijvoorbeeld: 172417.6715,578851.4432,172676.5002,579052.6692

Wanneer ik de features bekijk met EPSG:4326, dus met de srsName parameter in de naam krijg ik het volgende terug:

<wfs:member>
...
<Verlichting:Verlichting gml:id="Verlichting.1">
<Verlichting:Shape>
<gml:Point gml:id="Verlichting.1.pn.0" srsName="urn:ogc:def:crs:EPSG::4326">
<gml:pos>53.18372727 5.50391460</gml:pos>
</gml:Point>
</Verlichting:Shape>

Wanneer ik dan wil filteren met een bounding box dan moet ik Long/Lat omdraaien naar Lat/Long, handmatig kan ik dit wel maar de webapp vult dit zelf in. Het lijkt mij dat 53.18372727 5.50391460 andersom moet staan. Net zoals bij EPSG:28992 het lage getal eerst, gevolgd door het hoge getal.

Ik heb dit op de website van Esri gelezen dat je dit kan wijzigen, maar dit geldt alleen voor een enterprise installatie, over welke ik niet beschik. Ik heb een ArcGIS Online omgeving welke gehost wordt bij Esri zelf. Doe ik iets fout? Heeft iemand een tip of zelfs een betere oplossing?

#2

Ook in je webapp EPSG:28992 gebruiken?

#3

Niet mogelijk helaas. Ik beheer de app zelf niet. Het gaat er mij ook om hoe het kan dat ze omgedraaid zijn. Of dat normaal is of dat ik iets fout doe.

#4

Op WGS 84 - WGS84 - World Geodetic System 1984, used in GPS - EPSG:4326 kan je terug lezen dat de volgorde van de coordinaten voor WGS84 lat/lon is. Dus de respons van de WFS is volgens de standaard.

En op het epsg.org equivalent ook: WGS 84

Waar in dit geval precies dezelfde informatie over de volgorde van de coƶrdinaten staat, @Jochem

1 like
#5

In de nieuwere WFS standaards zijn ze gaan rommelen met de richting van de Y-as. misschien ook wel met de volgorde van x en y.

Je zou kunnen proberen om terug te gaan naar wfs 1.1.0. Met een beetje geluk gaat het dan wel goed.

MArco

#6

lat lon hoort naar mijn mening bij coordinaatsystemen in graden. dan gaat lat voor lon.

Bij geprojecteerde coordinaatstelsels hebben we het naar mijn mening over x en y. Dan gaat x voor y.

1 like
#7

Ik zie het inderdaad. Wat ik me dan afvraag, hieronder een voorbeeld van de gemeente Amsterdam waar ze wel ā€˜omgedraaidā€™ staan:

https://api.data.amsterdam.nl/v1/wfs/huishoudelijkafval/?SERVICE=WFS&REQUEST=GetFeature&VERSION=2.0.0&TYPENAMES=app:container&COUNT=1&srsName=EPSG:4326

Of is dat dan iets wat een instelling kan zijn.

#8

Het is inmiddels gelukt met wat parameters om de bounding box anders te krijgen. Rest mij nog een vraag, namelijk bij het transformeren dmv de srsName parameter naar EPSG:4326, kan het voorkomen dat er verschil zit in de positie op de kaart? Enkele centimeters of zelfs meters?

#11

De volgorde in het request is niet per se gelijk aan de volgorde in de response.

Enkele centimeters kun je altijd verwachten. enkele meters misschien ook nog wel, afhankelijk van de nauwkeurigheid van de uitgevoerde transformatie.

Oh ja, vergeet je niet te posten wat je precies hebt gedaan om het op te lossen?

Een volgende met hetzelfde probleem heeft er dan ook wat aan. Hoeven we hetzelfde probleem maar 1 x op te lossen.

#12

@RobinTopper, Zou je alsjeblieft nooit naar epsg.io willen verwijzen? Die website bevat verouderde gegevens en implementatiefouten. De officiƫle website is epsg.org

PS: Extra nadelen van epsg.io t.o.v. epsg.org voor specifiek deze EPSG-code:

  • Er wordt niet expliciet vermeld dat EPSG:4326 alleen voor 2D coƶrdinaten is.
  • Er wordt niet gelinkt naar de 3D code voor WGS84.
  • Er wordt niet vermeld dat EPSG:4326 o.b.v. een datum ensemble is.
  • De informatie over de onnauwkeurigheid van 2 meter van het datum ensemble ontbreekt daardoor.
  • Er wordt ook niet doorgelinkt naar de leden van het datum ensemble.
  • De informatie over de koppeling aan het officiĆ«le, wel nauwkeurige, ITRS ontbreekt daardoor.
  • En daardoor ontbreekt ook de informatie dat het dynamic (tijdsafhankelijke) coƶrdinaten betreft.
1 like
#13

EPSG:4326 heeft als datum ensemble een onnauwkeurigheid in de definitie van 2 meter. Als je nauwkeuriger wil moet je een andere EPSG-code voor een specifieke realisatie van WGS84 gebruiken en een epoche opgeven voor een tijdsafhankelijke transformatie die rekening houdt met het verschuiven van de continenten. De meeste software kan dat echter niet en stelt WGS84 gelijk aan ETRF2000. Dat is voor de meeste toepassingen ook het advies in de handreiking CRS. De transformatie tussen ETRF2000 en RD is bij gebruik van RDNAPTRANSā„¢2018 binnen 1 mm nauwkeurig. Of je software correct transformeert kun je controleren met deze Validatieservice.

#14

Bedankt voor je toelichting Jochem. Om even terug te komen op de oplossing. De webapp waarmee ik werk vult de parameters north, east, south en west in voor de bounding box. Het was een kwestie van het vinden van een volgorde waarin deze stonden waar het wel werkte.

#15