1

I have a question about how to use grid shift(gsb) in linux PostGIS. I want to transform from Tokyo Datum to JGD2000, but the grid shift doesn't work in my PostGIS Linux version...

Detail: I'm using PostGIS to toransform the coordinate system about Japan points. for example, I want to convert coordinates in EPSG:30170 (Tokyo / Japan Plane Rectangular CS X) to EPSG:4612 (JGD2000). This conversion requires the grid shift parameter by TKY2JGD.gsb, which I downloaded it from the following site: https://github.com/tohka/JapanGridShift I have copied it to the proj folder in my PostGIS.

Here is my sample SQL:

select ST_AsText(ST_Transform(ST_SetSRID(ST_MakePoint(59970, -191522), 30170), 4612));

I have tried the SQL in both the Windows and Linux versions of PostGIS.

The Windows version works correctly with the grid shift.

Result:  POINT(141.515303472659, 38.2754870757)      <== Correct

However, the Linux version doesn't apply the grid shift, and the result is incorrect:

Result:  POINT(141.51530352063338, 38.275491208146946)    <== Incorrect

Why does the grid shift not work in the Linux version of PostGIS? How to use TKY2JGD.gsb in Linux version of PostGIS? If possible, Please let me know some advices...

My environment:
Windows 10 / Postgres 14.8 / PostGIS 3.3
Proj folder: C:\pg\14\share\contrib\postgis-3.3\proj

Rocky 8.5 / Postgres 14.8 / PostGIS 3.3
Proj folder: /usr/proj90/share/proj /usr/proj82/share/proj

Improve this question
4
  • see gis.stackexchange.com/a/327456/79 - are you sure that it matters?
    – Ian Turton
    Commented Jun 6, 2023 at 11:05
  • Some sort of grid shift is occurring. If you just unproject the original coordinates to Tokyo GCS latitude-longitude, you get: 141.5188010 38.27249734 so quite a bit different than the output. You are correct that the windows and linux implementations should give the same results. Maybe first check whether the unprojection results match (use 4301) to confirm that it's the ntv2-based tfm that's different.
    – mkennedy
    Commented Jun 6, 2023 at 16:50
  • Hi Ian, Thank you for your comment. Actually the tky2jgd grid-shift are quite a little (around 1-20m), but it's official grid-shift from Japan government. So it's important for Japanese GIS...
    – icegray
    Commented Jun 7, 2023 at 11:46
  • 1
    Hi @mkennedy, I tested the transform to 4301 as your suggestion. Both results are same (Win10/Linux). 141.5188010 38.27249734. Next, I tested the transform from 4301 to 4612 (This transform requires a grid shift). There are a difference. Win10:41.5153035,38.2754871 <--correct / Linux:141.5153035,38.2754912 <-- Incorrect. Then, I removed the TKY2JGD.gsb file from Windows, for test. In this case the Win result changed to same as Linux (Incorrect value). So I guess, the Win PostGIS has used TKY2JGD correctly but the Linux doesn't use it. ...
    – icegray
    Commented Jun 8, 2023 at 6:18

1 Answer 1

Reset to default
0

The file name referenced from proj.db is tky2jgd.gsb, and Linux uses a case-sensitive file system.

After renaming the file from TKY2JGD.gsb to tky2jgd.gsb, the transformation works for me.

Improve this answer
1
  • Hi CL. Thank you for your suitable information. That's right. I can transform JGD2000 on linux exactly! In next time, I'll check proj.db carefully.
    – icegray
    Commented Jun 12, 2023 at 2:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.