[Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Vr Sep 2 03:17:02 PDT 2016

Beste projectiespecialisten,

Er bestaat geen 'juiste' transformatie van RD naar WGS84, omdat die
transformatie met de tijd verandert vanwege de continentale drift.
Op 1 bepaald tijdstip kan er wel een 'juiste' benadering zijn, maar na
verloop van tijd moet die weer worden aangepast aan de nieuwe situatie.

Dit is de hoofdoorzaak dat je telkens veranderingen ziet in de
parameterbestanden, ook voor andere coördinaatsystemen (ETRS89 enz).

Door al die verwijzingen naar codes 4833, 7000, RDNAPTRANS, 15934,
gridshift enz. duurde het voor mij wel even voordat ik dit als simpele
projectiegebruiker begreep.

Heb ik het zo goed samengevat, of ging deze thread eigenlijk heel ergens
anders over?

Groet,

Anne

Op 22 augustus 2016 22:32 schreef Edward Mac Gillavry <
emacgillavry op hotmail.com>:

> Lennard,
>
>
> Dankjewel voor je toelichting! Met datum grid shift file lijkt inderdaad
> de meest zuivere oplossing. Pakt proj4 die file dan mee in. Maar misschien
> is de verwijzing "*28992,4833*" daarom praktischer, robuster? Benieuwd
> naar die wisselwerking tussen Libgeotiff en proj4 in dezen.
>
>
> Goed idee om de nuances eens op een breder podium te presenteren. GeoBuzz,
> een OSGeoNL-middag of Maptime?
>
>
> Groet,
>
>
> Edward
>
> ------------------------------
> *From:* Dutch <dutch-bounces op lists.osgeo.org> on behalf of Huisman,
> Lennard <Lennard.Huisman op kadaster.nl>
> *Sent:* Monday, August 22, 2016 6:20 PM
>
> *To:* dutch op lists.osgeo.org
> *Subject:* Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?
>
>
> Hallo,
>
>
>
> Het enige juiste is RDNAPTRANS, maar dat past niet in het formaat van
> datum_shift_pref.csv :-).
>
>
>
> 1)
>
> uit de mail van Edward:
>
> *1. ####################################################################*
>
> *2. #*
>
> *3. # RDNew preferred transformation*
>
> *4. #
> 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/>*
>
> *5. #*
>
> *6. 28992,15934*
>
>
>
> 15934 is achterhaald, zoals Frank terecht aangeeft en is inderdaad
> vervangen door 4833. (Overigens heeft deze verandering niets te maken met
> het feit dat RD aan ETRS89 aan ETRS89 is gekoppeld en iet aan WGS84).
>
>
>
> Het is goed om bij codes van EPSG ook de 'Remarks', 'Scope' en andere
> metadat uit de EPSG-database bij deze code goed te lezen, zoals bij 4833:
>
> ---
>
> *Remarks:*   Parameter values from Amersfoort to ETRS89 (5) (tfm code
> 4830) assuming that ETRS89 is equivalent to WGS 84 within the accuracy of
> the transformation. Replaces Amersfoort to WGS 84 (3) (code 15934).
>
> *Scope:*   Approximation at the +/- 1m level.
>
> ---
>
>
>
> Als je dit gebruikt gebruik je de 'benaderde transformatie' tussen RD en
> ETRS89 volgens de meest actuele parameters. Deze geeft verschillen met
> RDNAPTRANS2008 tot ca. 0.25 meter.
>
>
>
> Je krijgt dus voor datum_shift_pref.csv iets van:
>
> *1. ####################################################################*
>
> *2. #*
>
> *3. # Assuming WGS84 is equivalent to ETRS89*
>
> *4. # RD to ETRS89 approximate transformation *
>
> *5. #*
>
> *6. 28992,4833*
>
>
>
> 2)
>
> Interessant vind ik de vermelding voor NAD27 in https://trac.osgeo.org/
> geotiff/browser/trunk/libgeotiff/csv/datum_shift_pref.csv
>
>
>
> *38. #################################################################### *
>
> *39. # *
>
> *40. # We don't want to apply TOWGS84 values for NAD27 - we prefer to use *
>
> *41. # datum grid shift files. *
>
> *42. # *
>
> *43. 4267,-1 *
>
>
>
> Voor RD bestaat zo een 'datum grid shift file' ook. Dit grid is opgenomen
> in EPSG onder code 7000. Als je de transformatie uit code 7000 gebruikt ipv
> 4833 heb je de 'verbeterde benaderde transformatie', op maaiveldniveau is
> deze gelijk aan RDNAPTRANS (behalve rondom de contour van het
> geldigheidsgebied, bij hoogteverschillen t.o.v. maaiveld is er een
> afwijking van 1 mm per 50 meter hoogte verschil)
>
>
>
> Deze zou je kunnen vermelden als:
>
> *1. ####################################################################*
>
> *2. #*
>
> *3. # Assuming WGS84 is equivalent to ETRS89*
>
> *3. # RD to ETRS89 improved approximate transformation *
>
> *4. # Use datum grid shift file EPSG-7000 instead of TOWGS84 values*
>
> *6. #*
>
> *7. 28992,-1*
>
>
>
> 3) Wat betreft de relatie WGS84, ETRS89 en RD, misschien is er gelegenheid
> om deze relaties ergens een keer toe te lichten, samen met onze plannen
> voor herdefinitie van de transformatie? Het verschil tussen WGS84 en ETRS89
> zit momenteel tussen de 60 en 70 centimeter en neemt jaarlijks toe, maar is
> nog geen 5 meter.
>
>
>
> Gr,
>
> Lennard
>
>
>
>
>
>
>
> *Van:* Dutch [mailto:dutch-bounces op lists.osgeo.org] *Namens *Edward Mac
> Gillavry
> *Verzonden:* maandag 22 augustus 2016 15:20
> *Aan:* dutch op lists.osgeo.org
> *Onderwerp:* Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?
>
>
>
> Beste mensen,
>
>
>
> Deel jullie verbazing, dat dit steeds weer opduikt. Suggestie van Frank om
> een patch uit te voeren lijkt me goed! 4833 lijkt de meest recente.
> Dankjewel voor het meekijken!
>
>
>
> Groet,
>
>
>
> Edward
>
>
> ------------------------------
>
> *From:* Dutch <dutch-bounces op lists.osgeo.org> on behalf of Frank Steggink
> <frank op steggink.it>
> *Sent:* Monday, August 22, 2016 1:40 PM
> *To:* dutch op lists.osgeo.org
> *Subject:* Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?
>
>
>
> 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 op lists.osgeo.org
> >> http://lists.osgeo.org/mailman/listinfo/dutch
> >>
> >
> >
> >
> > _______________________________________________
> > Dutch mailing list
> > Dutch op 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 op steggink.it
> KVK: 63767066
>
>
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van
> het Kadaster
> is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan
> verzoeken wij u
> dit direct te melden aan de verzender en het bericht te vernietigen.
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
>
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee
> without the consent
> of the Kadaster is unlawful. If you have received this message, but are
> not the addressee,
> please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message.
>
> _______________________________________________
> Dutch mailing list
> Dutch op lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/dutch
>
------------- volgend deel ------------
Een HTML-bijlage is gescrubt...
URL: <http://lists.osgeo.org/pipermail/dutch/attachments/20160902/ba7e028a/attachment-0001.html>