<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;background-color:#FFFFFF;font-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Beste mensen,</p>
<p><br>
</p>
<p>Deel jullie verbazing, dat dit steeds weer opduikt. Suggestie van Frank om een patch uit te voeren lijkt me goed!
<span>4833</span> lijkt de meest recente. Dankjewel voor het meekijken!</p>
<p><br>
</p>
<p>Groet,</p>
<p><br>
</p>
<p>Edward<br>
</p>
<br>
<div style="color: rgb(0, 0, 0);">
<div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Dutch <dutch-bounces@lists.osgeo.org> on behalf of Frank Steggink <frank@steggink.it><br>
<b>Sent:</b> Monday, August 22, 2016 1:40 PM<br>
<b>To:</b> dutch@lists.osgeo.org<br>
<b>Subject:</b> Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?</font>
<div> </div>
</div>
</div>
<font size="2"><span style="font-size:10pt;">
<div class="PlainText">Hoi,<br>
<br>
Het is inderdaad vreemd dat deze discussie steeds weer de kop opsteekt. <br>
Aan de andere kant worden de projectieparameters met enige regelmaat <br>
geüpdate. Dit komt omdat officiëel gezien RD aan ETRS89, het Europese <br>
referentiesysteem is gekoppeld en niet aan WGS84. Het is dan niet zo gek <br>
dat de towgs84-parameters steeds bijgewerkt moeten worden.<br>
<br>
Ik heb moeite met het patchrequest. De schaalfactor is sowieso niet <br>
goed, want de waarde is op de laatste decimaal afgerond. Zoek EPSG:28992 <br>
op [1] (Retrieve by code) voor de juiste projectieparameters. De <br>
schaalfactor is 0.9999079.<br>
<br>
De towgs84-parameters kan ik daar niet vinden, maar ik kan wel de <br>
waarden vinden voor de datumtransformatie van de Amersfoort-datum naar <br>
ETRS89 als ik de RDNapTrans-code download [2]. De parameters zijn (RD <br>
naar ETRS89):<br>
Transformation parameters from RD(Bessel) to ETRS89<br>
Pivot point: center of the ellipsoid<br>
alfa 1,9342 *10^-6 rad<br>
beta -1,6677 *10^-6 rad<br>
gamma 9,1019 *10^-6 rad<br>
delta 4,0725 *10^-6<br>
tx 565,4171 m<br>
ty 50,3319 m<br>
tz 465,5524 m<br>
<br>
Dit komt overeen met de waarden in regel 561 (code 4833) in <br>
datum_shift.csv (zie mail Edward). De waarden voor alfa/beta/gamma zijn <br>
hier in miljoensten radialen genoemd, terwijl ze voor Proj.4 in <br>
boogseconden opgenomen moeten worden. Omrekenen d.m.v.: waarde * 180/pi <br>
* 3600:<br>
alfa: 0.39896<br>
beta: -0.34399<br>
gamma: 1.8774<br>
Klopt als een bus, met dien verstande dat ik 5 decimalen heb aangehouden <br>
(incl. voor de komma) en geen 6, omdat ook in de RDNAPTRANS-definitie 5 <br>
decimalen worden aangehouden.<br>
<br>
Als je de commentaren bij regels 559 t/m 562 leest, is dit de meest <br>
recente code. Ik zou wel een patchje willen indienen om de "(5)" (die de <br>
versie aanduidt) te wijzigen in "(4)" en de regels in chronologische <br>
volgorde te plaatsen. Mocht er een patch voor datum_shift_pref.csv nodig <br>
zijn, dan zou dit m.i. het volgende moeten bevatten:<br>
28992,4833<br>
<br>
Of je dit zomaar kunt gebruiken voor de transformatie naar WGS84, dat <br>
betwijfel ik ten zeerste. Ik heb ooit begrepen (weet helaas niet waar) <br>
dat de afwijking ca. 5 meter is en dat de transformatie naar WGS84 <br>
jaarlijks of zelfs 2x per jaar wordt herzien. Ik zal kijken of ik dit <br>
terug kan vinden. Misschien kan iemand die goed in deze materie zit meer <br>
informatie verschaffen. In de RDNAPTRANS-zipfile wordt zelf niks gezegd <br>
over WGS84. Ik vraag me af hoe dit voor andere Europese systemen is <br>
opgelost. Worden hier ook de transformatieparameters naar ETRS89 <br>
gebruikt, of zijn die omgerekend naar WGS84?<br>
<br>
Wat de nauwkeurigheid van de berekening betreft, is nauwelijks sprake <br>
van een probleem V.w.b. het gebruik van RDNAPTRANS vs. een oblique <br>
stereographic projectie zoals door Proj.4, die afwijking zou hooguit 1mm <br>
moeten zijn. Zie het commentaar op epsg-registry.org als je zoekt naar <br>
de code 4289:<br>
<br>
Since 1 October 2000 Amersfoort geodetic datum has been redefined;<br>
it is derived from ETRS89 by application of the official<br>
transformation RDNAPTRANS(TM). Transformation Amersfoort to ETRS89<br>
(7) (code 7000) approximates RDNAPTRANS(TM) to 0.001 m.<br>
<br>
Mits de projectieformules goed geïmplementeerd en de parameters juist <br>
zijn natuurlijk ;)<br>
<br>
Het correctiegrid zou je in sommige gevallen wel moeten gebruiken. Ik <br>
heb ooit begrepen dat er afwijkingen tot 25 cm in verwerkt zitten. Voor <br>
normale GIS-toepassingen niet relevant, je zit dan echt wel in de <br>
landmeetkunde-sfeer. 25 cm komt overeen met iets meer dan 1 pixel op <br>
schaalniveau 19 in World Mercator of schaalniveau 14 in het RD <br>
tiling-schema.<br>
<br>
Groeten,<br>
<br>
Frank Steggink<br>
<br>
<br>
[1]http://www.epsg-registry.org/<br>
[2] <br>
<a id="LPlnk408731" href="https://www.kadaster.nl/web/formulier/Rijksdriehoeksmeting-formulieren/Aanvraag-download-RDNAPTRANS2008.htm">https://www.kadaster.nl/web/formulier/Rijksdriehoeksmeting-formulieren/Aanvraag-download-RDNAPTRANS2008.htm</a><br>
<br>
On 22-8-2016 12:21, Just van den Broecke wrote:<br>
> Beste Mensen,<br>
><br>
> Dit en gerelateerd issue kwam veel op rond 2007/2008 [0]. Nog tot paar <br>
> jaar terug moest ik iedere keer de epsg file en PostGIS srs tabel <br>
> handmatig editen, maar dacht dat dit ("juiste" EPSG:28992 parameters) <br>
> nu de wereld uit was. Zeker mooi onderwerp om hier en in Bonn over te <br>
> hebben.<br>
><br>
> Ik denk dat iedere serieuze Geo-professional in NL op de hoogte zou <br>
> moeten zijn van het probleem en de oplossing(en) dus ook over <br>
> "RDNAP-Trans" en grid-correctie. Vooral ook wanneer dit laatste <br>
> wel/niet een rol speelt omdat de basisregs m.i. in RD, niet in <br>
> EPSG:28992 zijn ingemeten (m.i. met RDNAP-TRANS getransformeerd uit <br>
> ETRS89). Je ontkomt er niet aan (en staat goed op je CV), totdat we <br>
> massaal naar ETRS89 overgaan [5].<br>
><br>
> Maar het blijft vreemd dat we steeds als ontwikkelaars/beheerders <br>
> onderling "aan het gissen en patchen zijn" over de "juiste" <br>
> parameters. Dat zou toch een instantie als Kadaster of Geonovum moeten <br>
> publiceren/bijhouden (en die weer naar EPSG.org/io)? Of mis ik iets? <br>
> Kan uitkomst discussie zijn.<br>
><br>
> Onze Steven heeft op OSGeo.nl Dag 2012 in Velp mooi overzicht <br>
> probleemstelling [1] gegeven. [4] van Martijn v E uit 2008 heeft ook <br>
> goede refs.<br>
><br>
> Twee experts die op dit onderwerp zijn Jan Hartmann (UvA) en Lennard <br>
> Huisman (Kadaster). Hen er ook bij betrekken. Er is ook al eerder op <br>
> deze lijst gediscussieerd [2] over EPSG parameters en grid correctie <br>
> [3]. Links onder.<br>
><br>
> Hartelijke groet,<br>
><br>
> --Just<br>
><br>
> Links:<br>
> [0] <a href="https://lists.osgeo.org/pipermail/gdal-dev/2008-February/016241.html">
https://lists.osgeo.org/pipermail/gdal-dev/2008-February/016241.html</a><br>
> [1] <br>
> <a href="http://io.osgeo.nl/sitecontent/osgeonl_dag/media/osgeonldag12/presentaties/steven-projecties.ppt">
http://io.osgeo.nl/sitecontent/osgeonl_dag/media/osgeonldag12/presentaties/steven-projecties.ppt</a><br>
> [2] <a href="https://lists.osgeo.org/pipermail/dutch/2013-December/000806.html">
https://lists.osgeo.org/pipermail/dutch/2013-December/000806.html</a><br>
> [3] <a href="https://lists.osgeo.org/pipermail/dutch/2014-October/000975.html">
https://lists.osgeo.org/pipermail/dutch/2014-October/000975.html</a><br>
> [4] <br>
> <a href="https://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/">
https://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/</a><br>
> [5] <br>
> <a href="http://www.geonovum.nl/onderwerpen/co%C3%B6rdinaatsystemen/nieuws/overstap-naar-etrs89-rapport-online">
http://www.geonovum.nl/onderwerpen/co%C3%B6rdinaatsystemen/nieuws/overstap-naar-etrs89-rapport-online</a><br>
><br>
> On 21-08-16 21:22, Edward Mac Gillavry wrote:<br>
>> Beste mensen,<br>
>><br>
>><br>
>> Werd vandaag gewezen op <a href="https://github.com/OSGeo/proj.4/pull/403">https://github.com/OSGeo/proj.4/pull/403</a>. Daarin<br>
>> wordt voorgesteld om een patch voor<br>
>> <a href="https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/datum_shift_pref.csv">
https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/datum_shift_pref.csv</a>
<br>
>><br>
>> te maken.<br>
>><br>
>><br>
>> Als ik het goed heb, zou dat zoiets zijn als:<br>
>><br>
>><br>
>> ####################################################################<br>
>><br>
>> #<br>
>><br>
>> # RDNew preferred transformation<br>
>><br>
>> #<br>
>> <a href="https://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/">
https://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/</a>
<br>
>><br>
>><br>
>> #<br>
>><br>
>> 28992,15934<br>
>><br>
>> ####################################################################<br>
>><br>
>><br>
>> 15934 is de transformatie vasatgelegd in<br>
>> <a href="https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/datum_shift.csv">
https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/datum_shift.csv</a>. <br>
>><br>
>> Klopt dit of zie ik iets over het hoofd? Wellicht iets om tijdens de<br>
>> bedrijven door in Bonn te bespreken deze week?<br>
>><br>
>><br>
>> Groet,<br>
>><br>
>><br>
>> Edward<br>
>><br>
>> <<a href="https://github.com/OSGeo/proj.4/pull/403">https://github.com/OSGeo/proj.4/pull/403</a>><br>
>><br>
>> The definition of EPSG:28992 is wrong. For some reason there has been…<br>
>> by julien2512 · Pull Request #403 · OSGeo/proj.4<br>
>> <<a href="https://github.com/OSGeo/proj.4/pull/403">https://github.com/OSGeo/proj.4/pull/403</a>><br>
>> github.com<br>
>> reported by @bbrala on proj4php See<br>
>> <a href="https://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/">
https://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/</a>
<br>
>><br>
>> I am going to tell <a href="https://epsg.io/28992">https://epsg.io/28992</a> too.<br>
>><br>
>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Dutch mailing list<br>
>> Dutch@lists.osgeo.org<br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/dutch">http://lists.osgeo.org/mailman/listinfo/dutch</a><br>
>><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Dutch mailing list<br>
> Dutch@lists.osgeo.org<br>
> <a href="http://lists.osgeo.org/mailman/listinfo/dutch">http://lists.osgeo.org/mailman/listinfo/dutch</a><br>
<br>
<br>
-- <br>
Steggink Geo-ICT<br>
Frank Steggink<br>
Smaragdplein 61<br>
3523 ED Utrecht<br>
The Netherlands<br>
+31 6 53 10 13 66<br>
<a href="http://www.steggink.it">www.steggink.it</a><br>
frank@steggink.it<br>
KVK: 63767066<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>