Het Dataplatform van gemeente Amsterdam gaat het gebruik van een API key bij het gebruik van API's verplicht stellen. Hiermee wil het Dataplatform inzicht krijgen wie gebruik maakt van haar APIs, zodat het Dataplatform kan communiceren over updates en wijzigingen in de API's. Eventuele wijzigingen in de API's kunnen dan tijdig geïmplementeerd worden in uw systemen. Dit gaat gelden voor alle zogenaamde 'DSO API's' van het Dataplatform van gemeente Amsterdam.

Het gebruik van een API key bij de aanroep van een API van het Dataplatform van gemeente Amsterdam is vanaf half september optioneel. In overleg met de dataorganisatie wordt een deadline vastgesteld voor het moment vanaf wanneer de API keys verplicht worden. U kunt de API's van het Dataplatform dan niet meer gebruiken zonder een API key mee te geven.

Dit heeft gevolgen voor uw systemen!

Vraag tijdig een API key aan om uw systemen hierop aan te passen. U kunt met dit formulier een API key aanvragen.

Geometrie projecties

De geometrie velden worden standaard teruggegeven in de projectie van de originele bron. Dit is veelal de rijksdriehoekscoördinaten (Amersfoort / RD New). Met de Accept-Crs header kan opgegeven worden met welke transformatie alle geometriewaarden teruggegeven moet worden. Bijvoorbeeld:

curl -H "Accept-Crs: EPSG:28992" https://api.data.amsterdam.nl/v1/gebieden/buurten/

Veelgebruikte projecties zijn:

De andere notatievormen (zoals EPSG:4326 en www.opengis.net URI's) worden ook ondersteund.

De volgorde van coördinaten

Wanneer Nederlande rijksdriehoek coördinaten vertaald worden naar WGS 84, komt dit per ongeluk soms in de Arabische zee terecht.

Dat betekend dat latitude van ±52 en longitude van ±4 omgedraaid zijn. Dat heeft te maken met de assen-volgorde van de gekozen geometrieprojecties, en wijze waarop brondata en de gekozen toepassing ingesteld zijn.

Veel computersystemen werken altijd in x/y schermposities. De eerdere geo-standaarden deden dit ook. Dergelijke volgordes zijn echter niet universeel, en dat geeft veel verwarring en is niet consistent. Bijvoorbeeld:

• Vraag je iemand van de marine/luchtverkeersvaart om een coördinaat, dan zul je een latitude/longitude (noord/west) krijgen - voor programmeurs gezien als y/x-volgorde.
• In geodesie (o.a. landmeetkunde) worden latitude/longitude zelfs als x/y behandeld.
• Kijk je vanuit astromomie, dan is 'afstand/hoogtegraad/breedtegraad' een logische volgorde.
• In de dagelijke praktijk meten we verpakkingen in 'lengte x breedte x hoogte', maar een serverchassis eerder in 'hoogte x breedte x diepte'.
• Het meeste schrift is van links naar rechts, boven naar beneden opgesteld, maar ook dat is slechts een plaatselijke conventie.

Binnen de OGC standaarden is uiteindelijk gekozen om de assen-volgorde van de authoriteit van de CRS aan te houden. Een antwoord van een WFS 1.3 en 2.0 server zal deze volgorde aanhouden.

Uitzonderingen.

Voor web-gebaseerde clients is de authoriteit-volgorde niet handig, want dan moet iedere client een tabel met alle CRS'en bijhouden. Daarom werkt GeoJSON altijd in x/y van urn:ogc:def:crs:OGC::CRS84, ofwel longitude/latitude volgorde.

Ook is de SRID 4326 dubbelzinnig, en afhankelijk van de gekozen authoriteit. In urn:ogc:def:crs:EPSG::4326 levert dat y/x coordinaten op, en bij urn:ogc:def:crs:OGC::CRS84 (ook SRID 4326) een x/y coordinaten volgorde. Wie nadrukkelijk die volgorde wil, kan het beste urn:ogc:def:crs:OGC::CRS84 gebruiken.

Om legacy software te ondersteunen, wordt bij de notatiewijze EPSG:4326 (en alleen bij deze code) de coordinaten in longitude/latitude (x/y) teruggegeven.

De onderliggende GEOS-bibliotheek die PostgreSQL/PostGIS gebruikt heeft geen kennis van assenvolgorde. PostGIS slaat de gegevens daarom altijd in x/y op samen met de numerieke SRID. Wie met directe database toegang een SQL query uitvoert, zal dit bij SRID 4326 dus als longitude/latitude ontvangen.