Rijksdriehoekcoordinaten

Gertjan_Idema · 2010-09-04T21:51:53.000Z

Wie heeft er ervaring met RD coordinaten?
Ik ben er een beetje mee aan het spelen en loop tegen rare dingen aan.
Om te beginnen heb ik geprobeerd wat RD data (Rijksmonumentenlijst) om te zetten naar een osm bestand. Ging op zich prima, maar bij laden in Josm bleek alles ruim 100 meter naar het noordnoordoosten terecht te komen.
Om te vergelijken keek ik naar de nederlandse openstreetmap, die immers ook RD coordinaten heeft, maar zag hier een vergelijkbare afwijking. Kijk maar eens naar de onze lieve vrouwen toren in Amersfoort. Deze zou per definitie op 155000, 463000 moeten staan, maar staat daar 33 meter west en 114 meter zuid van.
Het rare is dat als ik de zelfde formules gebruik om een Rijksdriehoeksprojectie aan Josm toe te voegen, opeens geen correctie nodig lijkt te zijn. Dan staat de toren nog maar een paar meter er naast, wat mij een acceptabele afwijking lijkt.
Iemand enig idee welke correcties (of geen) ik moet gebruiken?

Stefan_de_Konink · 2010-09-04T21:53:03.000Z

Hey, ik ben sinds vandaag heel ervaren

Welke projectie string gebruik je nu. Dat is namelijk de meest voorkomende oorzaak van problemen

fsteggink · 2010-09-04T21:59:05.000Z

Dit zou kunnen in het geval er geen datumcorrectie plaatsvindt op osm.nl. De Amersfoort-datum is niet gelijk aan WGS84. Dit kan afwijkingen tot enkele honderden meters veroorzaken.

Ldp · 2010-09-04T22:02:21.000Z

We hebben in OL te maken met proj4js, en die voeren we de juist RD-string zoals die hier beschreven is. Dat heeft de afwijking helaas niet opgelost.

Als je jouw coordinaten omzet met proj4, moet je ook zorgen dat je lokale epsg-bestand deze juiste string heeft voor EPSG:28992, of deze string expliciet op de cmdline opgeven als source srs.

fsteggink · 2010-09-04T22:12:43.000Z

Feit is dat de weergave van de coordinaten op www.openstreetmap.nl niet goed is. De OLV toren ligt per definitie op (155000,463000). Dit is de oorsprong van het RD stelsel, met dien verstande dat de false easting en northing op 155000m resp. 463000m gezet is.

Dat het met (het ontbreken van) de datumshift te maken heeft, is met dank aan de afbeeldingen op de link wel te zien. Het Paleis op de Dam heeft ongeveer dezelfde afwijking in de eerste twee screenshots.

Ldp · 2010-09-04T22:17:31.000Z

Als iemand weet hoe we dit in OL wel goed kunnen krijgen, roep het dan vooral! We zijn er vorig jaar eens mee bezig geweest, maar niet verder gekomen. O.a. ikzelf had het toen gerapporteerd, toen ik posities van enkele grenspalen in RD/Lambert72 had en dit omrekende naar WGS84, en beide eens bekeek op onze kaart. De op de kaart weergegeven RD-coordinaten lagen er voor mij net zover naast als hierboven genoemd.

robth · 2010-09-05T22:21:22.000Z

Weet niet of het wat help ik heb ditzelfde probleem meegemaakt met MapServer alles werd net een paar meter verkeerd geprojecteerd.

Dit hebben we opgelost door de definitie van RD-NEW 28992 in de epsg file aan te passen

dit was:
#<28992> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +no_defs <>

en veranderd naar:
<28992> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812 +no_defs <>

Waarschijnlijk is dit al bij jullie bekend maar dacht post het voor zekerheid toch maar even.

ZMWandelaar · 2010-09-06T07:34:32.000Z

Is dit ook iets waar we bv JOSM of onze GPS op aan moeten/kunnen passen?

Gertjan_Idema · 2010-09-06T08:37:12.000Z

Bedankt voor de informatie. Ik ga eerst eens wat met proj4 spelen. Daar heb ik nog geen ervaring mee. Wel gebruik ik dezelfde parameters al in het berichtje van robth.

Gertjan_Idema · 2010-09-06T16:22:15.000Z

Inmiddels ben ik wat verder. Ik heb proj.4 op mijn computer gezet en daar zit ook het programmatje cs2cs bij.
Met dit laatste programmatje, in combinatie met +towgs84 parameters valt alles op zijn plek. Zonder de +towgs84 geeft cs2cs dezelfde (foutieve) resultaten als proj (met of zonder +towgs84 parameters).
Mijn conclusie is dat er een fout zit in proj.4, of de manier waarop we het gebruiken. Met Googelen werd ik niet veel wijzer op dit vlak.
Ik denk dat ik maar eens in de source duik om te kijken of ik daar wijzer van word.

Gertjan

Stefan_de_Konink · 2010-09-06T16:23:45.000Z

Fout zit meestal in het epsg bestand

fsteggink · 2010-09-06T16:29:55.000Z

Ik vermoed dat het in de proj4js library (Javascript “port” van Proj.4) zit, en niet in Proj.4 zelf. Dit moet nog uitgezocht worden.

Btw, de parameter +k=0.999908 moet +k=0.9999079 zijn. Dit is de waarde die in de EPSG database voorkomt.

fsteggink · 2010-09-06T16:32:51.000Z

Stefan de Konink:

Fout zit meestal in het epsg bestand

Yep, als Proj.4 zelf wordt gebruikt. Voor de JS hebben we nog geen verklaring. Wat ik al wel heb gezien is dat als je niet EPSG:28992 definieert, dan gaat proj4js de parameters van spatialreference.org afhalen. Daar zit niet de towgs84 parameter bij. Maar ergens in de JS op openstreetmap.nl worden wel definities gegeven voor EPSG:28992. Misschien worden die niet tijdig gelezen, of proj4js bevat her en der bugs.

Gertjan_Idema · 2010-09-06T20:22:06.000Z

Stefan de Konink:

Fout zit meestal in het epsg bestand

Meestal, maar hier niet ben ik bang.

Als ik test in proj.4 (puur vanaf de command line) geef ik zelf de parameters mee (de zelfde al in een kloppend epsg bestand) en nergens een verwijzing naar een epsg bestand.
Zie hier onder:

proj +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079
+x_0=155000 +y_0=463000 +ellps=WGS84 +units=m +towgs84=565.2369,50.0087,465.658,-0.406857330322398,
0.350732676542563,-1.8703473836068,4.0812 +no_defs
5.387198 52.155177
154969.83    462890.57

Bovenste getallen: de door mij ingegeven wsg84 coordinaten van de olv toren
Onderste: de berekende RD coordinaten.

cs2cs geeft dit:

cs2cs +proj=latlong +datum=WGS84 +to +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
+k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.2369,50.0087,465.658,-0.406857330322398,
0.350732676542563,-1.8703473836068,4.0812 +units=m +no_defs
5.387198 52.155177
154999.62    463000.52 -43.36

Wat mij betreft dicht genoeg bij 155000 463000

Ook op de openstreetmap.nl site worden de conversieparameters expliciet meegegeven:

Proj4js.defs["EPSG:28992"] = "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889
+k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +towgs84=565.2369,50.0087,465.658,-0.406857330322398
,0.350732676542563,-1.8703473836068,4.0812 +no_defs <>";

Hier staat weliswaar de code EPSG:28992 in, maar er veranderd niets als je dat wijzigd in iets anders. Ik heb getest met EPSG:RD

Ik houd het er vooralsnog op dat in proj.4 en proj4js precies hetzelfde mis gaat.

fsteggink · 2010-09-07T06:45:16.000Z

Gertjan Idema:

Als ik test in proj.4 (puur vanaf de command line) geef ik zelf de parameters mee (de zelfde al in een kloppend epsg bestand) en nergens een verwijzing naar een epsg bestand.
Zie hier onder:
proj +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.9999079
+x_0=155000 +y_0=463000 +ellps=WGS84 +units=m +towgs84=565.2369,50.0087,465.658,-0.406857330322398,
0.350732676542563,-1.8703473836068,4.0812 +no_defs
5.387198 52.155177
154969.83    462890.57
Bovenste getallen: de door mij ingegeven wsg84 coordinaten van de olv toren
Onderste: de berekende RD coordinaten.

Hier geef je nergens op dat de input-coordinaten in WGS84 zijn. Hoe weet Proj.4 dan nu waar ze liggen? Ik denk dat Proj.4 ervan uitgaan dat ze dezelfde datum hebben als de projectie die je opgeeft. Als je dezelfde coordinaten opgeeft als in de lon_0 en lat_0 parameters, zou je een heel stuk dichter in de buurt komen. Aangezien de ellps parameter in je definitie ook niet goed is, verwacht ik sowieso geen correct resultaat.

cs2cs geeft dit:

cs2cs +proj=latlong +datum=WGS84 +to +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
+k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +towgs84=565.2369,50.0087,465.658,-0.406857330322398,
0.350732676542563,-1.8703473836068,4.0812 +units=m +no_defs
5.387198 52.155177
154999.62    463000.52 -43.36

Wat mij betreft dicht genoeg bij 155000 463000

Inderdaad. Hier is de ellps parameter ook goed. Die gekke hoogte moet je voor het gemak maar even negeren. Dat komt omdat de ellipsoides niet goed op elkaar aansluiten.

Ook op de openstreetmap.nl site worden de conversieparameters expliciet meegegeven:
Proj4js.defs["EPSG:28992"] = "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889
+k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m +towgs84=565.2369,50.0087,465.658,-0.406857330322398
,0.350732676542563,-1.8703473836068,4.0812 +no_defs <>";
Hier staat weliswaar de code EPSG:28992 in, maar er veranderd niets als je dat wijzigd in iets anders. Ik heb getest met EPSG:RD

Ik houd het er vooralsnog op dat in proj.4 en proj4js precies hetzelfde mis gaat.

Ik vind het nog te vroeg voor deze conclusie (zie 1e comment), alhoewel ik zelf Proj.4 niet goed ken, en je tests nog niet heb uitgevoerd.

Wilko_Quak · 2010-09-10T09:40:55.000Z

Gertjan Idema:

Wie heeft er ervaring met RD coordinaten?
Ik ben er een beetje mee aan het spelen en loop tegen rare dingen aan.
Om te beginnen heb ik geprobeerd wat RD data (Rijksmonumentenlijst) om te zetten naar een osm bestand. Ging op zich prima, maar bij laden in Josm bleek alles ruim 100 meter naar het noordnoordoosten terecht te komen.
Om te vergelijken keek ik naar de nederlandse openstreetmap, die immers ook RD coordinaten heeft, maar zag hier een vergelijkbare afwijking. Kijk maar eens naar de onze lieve vrouwen toren in Amersfoort. Deze zou per definitie op 155000, 463000 moeten staan, maar staat daar 33 meter west en 114 meter zuid van.
Het rare is dat als ik de zelfde formules gebruik om een Rijksdriehoeksprojectie aan Josm toe te voegen, opeens geen correctie nodig lijkt te zijn. Dan staat de toren nog maar een paar meter er naast, wat mij een acceptabele afwijking lijkt.
Iemand enig idee welke correcties (of geen) ik moet gebruiken?

Tsja, die coordinaattransformaties blijft lastige materie en vooral met RD coordinaten. Zelf gebruik ik de transformatie zoals beschreven in het volgende artikeltje: http://www.dekoepel.nl/pdf/Transformatieformules.pdf . Volgens de summary zit je er met deze formule maximaal enkele decimeters naast.

Van WGS–>RD heb ik nog wel ergens uitgeprogrammeerd (in java) liggen (niet zelf gedaan overigens) de andere kant op kan ik niet vinden.

Wilko Quak

paulb · 2010-09-17T20:03:20.000Z

Ik vind het feit dat er verkeerde Rd-coordinataten op de NL tileserver erg irritant. Als je het niet goed kunt krijgen, doe het dan niet.

Zelf gebruik ik een perl program (RDgpx.pl) om gpx-tracklogs om te zetten naar RD:


#!/usr/bin/perl -w
# usage: ./RDgpx.pl wgs84file.gpx > RDfile.gpx
use strict;

use Geo::Coordinates::RDNAP qw/to_rd/;
# from http://search.cpan.org/~pijll/Geo-Coordinates-RDNAP-0.11

# in gpx files we are looking for rows like these:
#<bounds minlat="53.22195" minlon="6.50688" maxlat="53.27026" maxlon="6.56861"/>
#<trkpt lat="53.237783333" lon="6.553150000">

my ($x, $y, $x2, $y2);

while (<>) { 
  chomp;
  if (/<trkpt lat="(\d+\.\d+)" lon="(\d+\.\d+)">/) {
        ($y, $x) = to_rd($1, $2);
    print '<trkpt lat="',$x,'" lon="',$y,'">',"\n";
  }
  elsif (/<bounds minlat="(\d+\.\d+)" minlon="(\d+\.\d+)" maxlat="(\d+\.\d+)" maxlon="(\d+\.\d+)"/) {
        ($y, $x) = to_rd($1, $2);
        ($y2, $x2) = to_rd($3, $4);
    print '<bounds minlat="',$x,'" minlon ="',$y,'" maxlat="',$x2,
    '" maxlon="',$y2,'" />',"\n";
  }
  else { print $_,"\n"; }
}

Gertjan_Idema · 2010-09-17T21:58:05.000Z

Het is gelukt!
Allen bedankt voor het meedenken.

Wat is gelukt?

Mijn conversieprogrammaatje leest de RCE KICH Rijksmonumenten Dataset om in een .osm bestand dat kan worden ingelezen in Josm. De ArcView data wordt omgezet in xml en de RD coordinaten worden omgezet in WGS84 coordinaten. Het resultaat is ronduit goed. Alle monumenten die ik bekeken heb (zie later) vallen binnen de contouren van de OpenStreetmap gebouwen en over het algemeen in het midden daarvan.
Ik heb een RD projectie toegevoegd aan Josm, waarmee het mogelijk is RD coordinaten binnen Josm te gebruiken.

Hoe heb ik dit gedaan?
Ik heb de Java versie van Proj4 (Proj4J) bijgewerkt. Hier heb ik de Double stereographic projection (sterea) aan toegevoegd, en een bug uit de verwerking van datum parameters (towgs) gehaald. Daardoor geeft Proj4j (Java) dezelfde (juiste) resultaten als Proj4js (Javascript) en Proj4 (C). Bij de laatste krijg ik overigens alleen goeie resultaten met het commando cs2cs en niet met het commando proj.
Toen de Java versie van Proj4 eenmaal goed werkte heb ik deze gebruikt voor de RD projectie in Josm en voor mijn conversieprogrammaatje.

En www.openstreetmap.nl?
Dit blijft voor mij een raadsel. Als ik de JavaScript versie van Proj4 stand-alone test gaat de conversie prima, maar op de site lijkt hij de datum parameters (towgs) te vergeten. Ik wil hier nog wel een in duiken. Misschien een bugje in OpenLayers?

Hoe nu verder?
-Ik ga mijn wijzigingen in Proj4J doorgeven in de hoop dat deze worden opgenomen.
-Ik ga kijken of ik de RD projectie als Plugin kan toevoegen aan Josm
-Ik ga kijken of ik mijn ArcView conversie programmaatje als plugin kan toevoegen aan Josm.

Mail me even als je geinteresseerd bent in:
-Mijn versie van Proj4J
-Mijn RD projectie voor Josm
-Mijn conversieprogrammaatje voor ArcView data
-De geconverteerde Rijksmonumenten data
Houd er wel rekening mee dat alles nog experimenteel is

Meer informatie:
Voorlopige rijksmonumentenkaart
Proj4 Java

Gecontroleerde monumenten:
Onzelievevrouwetoren, Amersfoort
Domtoren, Utrecht
Martinitoren, Groningen
St. Servaasbrug Maastricht
Brandaris, Terschelling

Gertjan

fsteggink · 2010-09-22T20:02:56.000Z

Het bleek dat er op www.openstreetmap.nl nog een oude versie van proj4js-compressed.js werd gebruikt. Na dit te hebben vervangen door de laatste versie (versie 1.0.1) zijn de coördinaten wel goed. Punt (155000,463000) is nu net ten noordoosten van de OLV toren in OSM. De afstand valt nog binnen de nauwkeurigheid die we van OSM mogen verwachten. Ook laat tile.openstreetmap.nl de goede RD coordinaten zien.

P.S. ~~De coördinaten zijn wel iets verschillend op beide servers. Dit komt doordat verschillende definities zijn gebruikt.~~ Hmm, toch niet, moet ik dus nog uitzoeken wat dit veroorzaakt…

Rubke · 2010-09-22T20:04:58.000Z

krijgen we nou een ijkzegel op de site