[Proj] Amersfoort / RD New
sebastic at xs4all.nl
Thu Nov 3 03:44:51 EST 2016
On 2016-11-03 09:15, Roger Oberholtzer wrote:
> It could be that the old epsg file was still being used. The old
> (non-working) definition of 4258 was:
> <4258> +proj=longlat +ellps=GRS80 +no_defs <>
> and the new (working) is:
> <4258> +proj=longlat +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +no_defs
> I think the problem was the missing +towgs84=0,0,0,0,0,0,0. Without
> the grid shift file was not used. And probably other things as well.
Yes, the missing +towgs84 values are the cause, I experienced this too
with the epsg file from PROJ.4 4.7.0 which doesn't have the +towgs84
> The Ref values are the sample points. The Calc is what I now get from
> (yeah!). The Inv is what I get when I do an inverse projection of my
> projected point. It is rather close to the original Ref. Except the
> Altitude. I am using the shift file for that as well. Maybe it does not
> allow an inverse on the Altitude? It is probably not a big issue for
> More of a curiosity.
The documentation included along with the grid shift files documents the
1) The rdtrans2008 NTv2-grid can only give identical results to
RDNAPTRANS TM 2008 within 1
millimeter at ground level onshore and at mean seal level offshore.
The horizontal deviation is
approximately 1 millimeter per 50 meter height difference from
ground level or mean sea level.
2) An exception to 1) is the border of the RDNAPTRANS TM 2008
correction grid. Transformation
results within cells of the rdtrans2008 NTv2-grid that are
intersected by the border of the
RDNAPTRANS TM 2008 correction grid can result in deviations of up to
3) The naptrans2008 VDatum-grid cannot be used to determine deflections
of the vertical. For
this the NLGEO2004 geoid model has to be used.
4) The naptrans2008 VDatum-grid is referenced to the Bessel-1841
ellipsoid and cannot be used
stand-alone, it has to be used in combination with the rdtrans2008
> I am also curious about some additional sample points that came with
> grid shift data.
> All of these fail. Since I expect our data to be within the area of the
> grid shift file, I guess I do not need to worry about these. Out of
> curiosity, how do others deal with such points?
This also noted in the documentation for the grid shift files:
Points 07 - 10 are outside the region where interpolation between
either the NLGEO2004 geoid or the RD correction grid points is
possible. RD is defined only within the region enclosed by the
following points (in RD), outside this region RD coordinates can
be computed, but the output should be handled with care.
Corners of the validity region for RD:
│ x (m) │ y (m) │
│ 140000 │ 630000 │
│ 100000 │ 600000 │
│ 80000 │ 500000 │
│ -8000 │ 390000 │
│ -8000 │ 335000 │
│ 100000 │ 335000 │
│ 160000 │ 288000 │
│ 220000 │ 288000 │
│ 301000 │ 450000 │
│ 301000 │ 615000 │
│ 260000 │ 630000 │
With the huge values change in PROJ.4 4.9.2 some of these values could
be calculated correctly, but caused most other tests to fail, so that
was reverted. See the discussion I linked before:
In my test script I added an override to accept the '*' output from
cs2cs because these tests are expected to fail.
More information about the Proj