[Dutch] RD/NAP naar ETRS89 met NTv2 en VDatum

[Sebastiaan Couwenberg]

On 10/17/2014 04:38 AM, Sebastiaan Couwenberg wrote:
> On 10/04/2014 08:33 PM, Huisman, Lennard wrote:
>> Verder in reactie op je eerdere mail: 
>> De getallen bij +towgs84 zou ik zeker aanpassen in de epsg-file, dit zijn de bronwaarden zoals wij ze publiceren (bijna dan, want de eenheden verschillen) en in de EPSG-database staan ze exact als in onze publicatie. Ik snap dus niet waarom in het epsg bestand van PROJ.4 de translatiewaarden afgerond zijn.
> 
> Ik vermoed dat PROJ.4 een conversie toepast op de EPSG dataset waarin
> precisie verloren gaat. De EPSG dataset word periodiek geupdate in
> PROJ.4, waardoor verouderde EPSG data mij onwaarschijnlijk lijkt.
> 
> In de Debian package voor proj 4.9.0RC2 zit een patch om de +towgs84
> waardes met de hogere precisie te gebruiken. Deze patch moet ik nog
> forwarded zodat het hopelijk ook in PROJ.4 zelf opgenomen kan worden.

Met de recente ontwikkelingen rond PROJ 4.9 [1] en de aankomen de 3.9.1
release, heb ik van de gelegenheid gebruik gemaakt om de patches in de
Debian package te forwarden.

Evan Rouault geeft in het betreffende ticket [2] aan dat de correctie
van de waardes voor EPSG:28992 in geotiff moet gebeuren omdat PROJ4,
GDAL & PostGIS hun waardes daar van afleiden.

In de psc.csv [3] file van libgeotiff, die uit de EPSG dataset is
overgenomen, zie ik deze definitie voor 28992:

"COORD_REF_SYS_CODE","COORD_REF_SYS_NAME","UOM_CODE","SOURCE_GEOGCRS_CODE","COORD_OP_CODE","COORD_OP_METHOD_CODE","SHOW_CRS","DEPRECATED","COORD_SYS_CODE","PARAMETER_CODE_1","PARAMETER_VALUE_1","PARAMETER_UOM_1","PARAMETER_CODE_2","PARAMETER_VALUE_2","PARAMETER_UOM_2","PARAMETER_CODE_3","PARAMETER_VALUE_3","PARAMETER_UOM_3","PARAMETER_CODE_4","PARAMETER_VALUE_4","PARAMETER_UOM_4","PARAMETER_CODE_5","PARAMETER_VALUE_5","PARAMETER_UOM_5","PARAMETER_CODE_6","PARAMETER_VALUE_6","PARAMETER_UOM_6","PARAMETER_CODE_7","PARAMETER_VALUE_7","PARAMETER_UOM_7"
28992,"Amersfoort / RD
New",9001,4289,19914,9809,1,0,4499,8801,52.0922178,9110,8802,5.23155,9110,8805,0.9999079,9201,8806,155000,9001,8807,463000,9001,,,,,,

De gebruikte EPSG database is 8.5. De NTv2 en VDatum grid transformaties
changes van 13-02-2015 [4] zitten daar uiteraard nog niet in.

Lennard, kan jij bevestigen dat deze waardes in libgeotiff overeenkomen
met de waardes zoals gepubliceerd door Kadaster?

Als dat het geval is, is een conversieslag de oorzaak van de afwijkingen
tussen de EPSG waardes en de uiteindelijke +towgs84 waardes in PROJ.

Het is mij nog niet duidelijk welke conversie waarschijnlijk de
schuldige is, noch hoe dit op te lossen.

Als de waardes in de CSV niet correct zijn is het toevoegen van de
juiste waardes voor 28992 in psc.override.csv een oplossing zoals
beschreven in de README [5]. En gaat er waarschijlijk iets fout in de
PostGIS -> CSV conversie.

Mvg,

Bas

[1] http://lists.maptools.org/pipermail/proj/2015-February/006991.html
[2] https://trac.osgeo.org/proj/ticket/260#comment:1
[3] http://trac.osgeo.org/geotiff/browser/trunk/libgeotiff/csv/pcs.csv
[4] http://lists.osgeo.org/pipermail/dutch/2015-February/001097.html
[5] http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/csv/README

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1