[Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Ma Aug 22 04:40:17 PDT 2016

Hoi,

Het is inderdaad vreemd dat deze discussie steeds weer de kop opsteekt. 
Aan de andere kant worden de projectieparameters met enige regelmaat 
geüpdate. Dit komt omdat officiëel gezien RD aan ETRS89, het Europese 
referentiesysteem is gekoppeld en niet aan WGS84. Het is dan niet zo gek 
dat de towgs84-parameters steeds bijgewerkt moeten worden.

Ik heb moeite met het patchrequest. De schaalfactor is sowieso niet 
goed, want de waarde is op de laatste decimaal afgerond. Zoek EPSG:28992 
op [1] (Retrieve by code) voor de juiste projectieparameters. De 
schaalfactor is 0.9999079.

De towgs84-parameters kan ik daar niet vinden, maar ik kan wel de 
waarden vinden voor de datumtransformatie van de Amersfoort-datum naar 
ETRS89 als ik de RDNapTrans-code download [2]. De parameters zijn (RD 
naar ETRS89):
Transformation parameters from RD(Bessel) to ETRS89
Pivot point: center of the ellipsoid
alfa    1,9342     *10^-6 rad
beta    -1,6677     *10^-6 rad
gamma    9,1019     *10^-6 rad
delta    4,0725     *10^-6
tx    565,4171     m
ty    50,3319     m
tz    465,5524     m

Dit komt overeen met de waarden in regel 561 (code 4833) in 
datum_shift.csv (zie mail Edward). De waarden voor alfa/beta/gamma zijn 
hier in miljoensten radialen genoemd, terwijl ze voor Proj.4 in 
boogseconden opgenomen moeten worden. Omrekenen d.m.v.: waarde * 180/pi 
* 3600:
alfa: 0.39896
beta: -0.34399
gamma: 1.8774
Klopt als een bus, met dien verstande dat ik 5 decimalen heb aangehouden 
(incl. voor de komma) en geen 6, omdat ook in de RDNAPTRANS-definitie 5 
decimalen worden aangehouden.

Als je de commentaren bij regels 559 t/m 562 leest, is dit de meest 
recente code. Ik zou wel een patchje willen indienen om de "(5)" (die de 
versie aanduidt) te wijzigen in "(4)" en de regels in chronologische 
volgorde te plaatsen. Mocht er een patch voor datum_shift_pref.csv nodig 
zijn, dan zou dit m.i. het volgende moeten bevatten:
28992,4833

Of je dit zomaar kunt gebruiken voor de transformatie naar WGS84, dat 
betwijfel ik ten zeerste. Ik heb ooit begrepen (weet helaas niet waar) 
dat de afwijking ca. 5 meter is en dat de transformatie naar WGS84 
jaarlijks of zelfs 2x per jaar wordt herzien. Ik zal kijken of ik dit 
terug kan vinden. Misschien kan iemand die goed in deze materie zit meer 
informatie verschaffen. In de RDNAPTRANS-zipfile wordt zelf niks gezegd 
over WGS84. Ik vraag me af hoe dit voor andere Europese systemen is 
opgelost. Worden hier ook de transformatieparameters naar ETRS89 
gebruikt, of zijn die omgerekend naar WGS84?

Wat de nauwkeurigheid van de berekening betreft, is nauwelijks sprake 
van een probleem V.w.b. het gebruik van RDNAPTRANS vs. een oblique 
stereographic projectie zoals door Proj.4, die afwijking zou hooguit 1mm 
moeten zijn. Zie het commentaar op epsg-registry.org als je zoekt naar 
de code 4289:

    Since 1 October 2000 Amersfoort geodetic datum has been redefined;
    it is derived from ETRS89 by application of the official
    transformation RDNAPTRANS(TM). Transformation Amersfoort to ETRS89
    (7) (code 7000) approximates RDNAPTRANS(TM) to 0.001 m.

Mits de projectieformules goed geïmplementeerd en de parameters juist 
zijn natuurlijk ;)

Het correctiegrid zou je in sommige gevallen wel moeten gebruiken. Ik 
heb ooit begrepen dat er afwijkingen tot 25 cm in verwerkt zitten. Voor 
normale GIS-toepassingen niet relevant, je zit dan echt wel in de 
landmeetkunde-sfeer. 25 cm komt overeen met iets meer dan 1 pixel op 
schaalniveau 19 in World Mercator of schaalniveau 14 in het RD 
tiling-schema.

Groeten,

Frank Steggink

[1]http://www.epsg-registry.org/
[2] 
https://www.kadaster.nl/web/formulier/Rijksdriehoeksmeting-formulieren/Aanvraag-download-RDNAPTRANS2008.htm

On 22-8-2016 12:21, Just van den Broecke wrote:
> Beste Mensen,
>
> Dit en gerelateerd issue kwam veel op rond 2007/2008 [0]. Nog tot paar 
> jaar terug moest ik iedere keer de epsg file en PostGIS srs tabel 
> handmatig editen, maar dacht dat dit ("juiste" EPSG:28992 parameters) 
> nu de wereld uit was. Zeker mooi onderwerp om hier en in Bonn over te 
> hebben.
>
> Ik denk dat iedere serieuze Geo-professional in NL op de hoogte zou 
> moeten zijn van het probleem en de oplossing(en) dus ook over 
> "RDNAP-Trans" en grid-correctie. Vooral ook wanneer dit laatste 
> wel/niet een rol speelt omdat de basisregs m.i. in RD, niet in 
> EPSG:28992 zijn ingemeten (m.i. met RDNAP-TRANS getransformeerd uit 
> ETRS89). Je ontkomt er niet aan (en staat goed op je CV), totdat we 
> massaal naar ETRS89 overgaan [5].
>
> Maar het blijft vreemd dat we steeds als ontwikkelaars/beheerders 
> onderling "aan het gissen en patchen zijn" over de "juiste" 
> parameters. Dat zou toch een instantie als Kadaster of Geonovum moeten 
> publiceren/bijhouden (en die weer naar EPSG.org/io)? Of mis ik iets? 
> Kan uitkomst discussie zijn.
>
> Onze Steven heeft op OSGeo.nl Dag 2012 in Velp mooi overzicht 
> probleemstelling [1] gegeven. [4] van Martijn v E uit 2008 heeft ook 
> goede refs.
>
> Twee experts die op dit onderwerp zijn Jan Hartmann (UvA) en Lennard 
> Huisman (Kadaster). Hen er ook bij betrekken. Er is ook al eerder op 
> deze lijst gediscussieerd [2] over EPSG parameters en grid correctie 
> [3]. Links onder.
>
> Hartelijke groet,
>
> --Just
>
> Links:
> [0] https://lists.osgeo.org/pipermail/gdal-dev/2008-February/016241.html
> [1] 
> http://io.osgeo.nl/sitecontent/osgeonl_dag/media/osgeonldag12/presentaties/steven-projecties.ppt
> [2] https://lists.osgeo.org/pipermail/dutch/2013-December/000806.html
> [3] https://lists.osgeo.org/pipermail/dutch/2014-October/000975.html
> [4] 
> https://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/
> [5] 
> http://www.geonovum.nl/onderwerpen/co%C3%B6rdinaatsystemen/nieuws/overstap-naar-etrs89-rapport-online
>
> On 21-08-16 21:22, Edward Mac Gillavry wrote:
>> Beste mensen,
>>
>>
>> Werd vandaag gewezen op https://github.com/OSGeo/proj.4/pull/403. Daarin
>> wordt voorgesteld om een patch voor
>> https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/datum_shift_pref.csv 
>>
>> te maken.
>>
>>
>> Als ik het goed heb, zou dat zoiets zijn als:
>>
>>
>> ####################################################################
>>
>> #
>>
>> # RDNew preferred transformation
>>
>> #
>> https://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/ 
>>
>>
>> #
>>
>> 28992,15934
>>
>> ####################################################################
>>
>>
>> 15934 is  de transformatie vasatgelegd in
>> https://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/datum_shift.csv. 
>>
>> Klopt dit of zie ik iets over het hoofd? Wellicht iets om tijdens de
>> bedrijven door in Bonn te bespreken deze week?
>>
>>
>> Groet,
>>
>>
>> Edward
>>
>> <https://github.com/OSGeo/proj.4/pull/403>
>>
>> The definition of EPSG:28992 is wrong. For some reason there has been…
>> by julien2512 · Pull Request #403 · OSGeo/proj.4
>> <https://github.com/OSGeo/proj.4/pull/403>
>> github.com
>> reported by @bbrala on proj4php See
>> https://oegeo.wordpress.com/2008/05/20/note-to-self-the-one-and-only-rd-projection-string/ 
>>
>> I am going to tell https://epsg.io/28992 too.
>>
>>
>>
>>
>>
>> _______________________________________________
>> Dutch mailing list
>> Dutch at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/dutch
>>
>
>
>
> _______________________________________________
> Dutch mailing list
> Dutch at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/dutch

-- 
Steggink Geo-ICT
Frank Steggink
Smaragdplein 61
3523 ED  Utrecht
The Netherlands
+31 6 53 10 13 66
www.steggink.it
frank at steggink.it
KVK: 63767066

-------------- next part --------------
A non-text attachment was scrubbed...
Name: frank.vcf
Type: text/x-vcard
Size: 226 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/dutch/attachments/20160822/ed1b0f30/attachment.vcf>