Timeline for In Tokyo Datum to JGD2000, the grid shift doesn't work in my PostGIS Linux
Current License: CC BY-SA 4.0
9 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 12, 2023 at 2:44 | vote | accept | icegray | ||
Jun 27, 2023 at 11:05 | |||||
Jun 9, 2023 at 8:08 | answer | added | CL. | timeline score: 0 | |
Jun 8, 2023 at 6:18 | comment | added | icegray | 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. ... | |
Jun 7, 2023 at 11:46 | comment | added | icegray | 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... | |
Jun 6, 2023 at 16:50 | comment | added | mkennedy | 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. | |
Jun 6, 2023 at 11:05 | comment | added | Ian Turton | see gis.stackexchange.com/a/327456/79 - are you sure that it matters? | |
Jun 6, 2023 at 10:15 | history | edited | Kadir Şahbaz | CC BY-SA 4.0 |
added 13 characters in body
|
S Jun 6, 2023 at 9:08 | review | First questions | |||
Jun 6, 2023 at 10:15 | |||||
S Jun 6, 2023 at 9:08 | history | asked | icegray | CC BY-SA 4.0 |