[Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Edward Mac Gillavry

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

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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/dutch
Reply | Threaded
Open this post in threaded view
|

Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Just van den Broecke
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
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/dutch
>



_______________________________________________
Dutch mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/dutch
Reply | Threaded
Open this post in threaded view
|

Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Sebastiaan Couwenberg
Wat betreft libgeotiff & proj, hiervan zijn recent release candidates
voor de aankomende nieuwe releases uitgebracht waarbij de EPSG data is
geupdate naar v8.9. De EPSG dataset is de bron voor de open source geo
software, en idealiter worden issues direct in die bron gecorrigeerd.
Omdat het even kan duren voordat die wijzigingen hun weg naar de
software vinden, heeft libgeotiff overrides om EPSG data in de tussen
tijd te corrigeren.

Mvg,

Bas

--
  GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1
_______________________________________________
Dutch mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/dutch
Reply | Threaded
Open this post in threaded view
|

Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Frank Steggink-2
In reply to this post by Just van den Broecke
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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/dutch
>>
>
>
>
> _______________________________________________
> Dutch mailing list
> [hidden email]
> 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
[hidden email]
KVK: 63767066


_______________________________________________
Dutch mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/dutch

frank.vcf (237 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Edward Mac Gillavry

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 <[hidden email]> on behalf of Frank Steggink <[hidden email]>
Sent: Monday, August 22, 2016 1:40 PM
To: [hidden email]
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
>> [hidden email]
>> http://lists.osgeo.org/mailman/listinfo/dutch
>>
>
>
>
> _______________________________________________
> Dutch mailing list
> [hidden email]
> 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
[hidden email]
KVK: 63767066


_______________________________________________
Dutch mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/dutch
Reply | Threaded
Open this post in threaded view
|

Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Huisman, Lennard

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/

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:[hidden email]] Namens Edward Mac Gillavry
Verzonden: maandag 22 augustus 2016 15:20
Aan: [hidden email]
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 <[hidden email]> on behalf of Frank Steggink <[hidden email]>
Sent: Monday, August 22, 2016 1:40 PM
To:
[hidden email]
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
>>
[hidden email]
>>
http://lists.osgeo.org/mailman/listinfo/dutch
>>
>
>
>
> _______________________________________________
> Dutch mailing list
>
[hidden email]
>
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
[hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/dutch
Reply | Threaded
Open this post in threaded view
|

Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Edward Mac Gillavry

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 <[hidden email]> on behalf of Huisman, Lennard <[hidden email]>
Sent: Monday, August 22, 2016 6:20 PM
To: [hidden email]
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/

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:[hidden email]] Namens Edward Mac Gillavry
Verzonden: maandag 22 augustus 2016 15:20
Aan: [hidden email]
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 <[hidden email]> on behalf of Frank Steggink <[hidden email]>
Sent: Monday, August 22, 2016 1:40 PM
To:
[hidden email]
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
>>
[hidden email]
>>
http://lists.osgeo.org/mailman/listinfo/dutch
>>
>
>
>
> _______________________________________________
> Dutch mailing list
>
[hidden email]
>
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
[hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/dutch
Reply | Threaded
Open this post in threaded view
|

Re: [Dutch] Juiste definitie EPSG:28992 in Libgeotiff ?

Anne Blankert
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 <[hidden email]>:

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 <[hidden email]> on behalf of Huisman, Lennard <[hidden email]>
Sent: Monday, August 22, 2016 6:20 PM

To: [hidden email]
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/

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:[hidden email]] Namens Edward Mac Gillavry
Verzonden: maandag 22 augustus 2016 15:20
Aan: [hidden email]
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 <[hidden email]> on behalf of Frank Steggink <[hidden email]>
Sent: Monday, August 22, 2016 1:40 PM
To:
[hidden email]
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
>>
[hidden email]
>>
http://lists.osgeo.org/mailman/listinfo/dutch
>>
>
>
>
> _______________________________________________
> Dutch mailing list
>
[hidden email]
>
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
[hidden email]
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
[hidden email]
http://lists.osgeo.org/mailman/listinfo/dutch


_______________________________________________
Dutch mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/dutch