JGD2024 Coordinate System Support in Point Cloud Tiler

Cesium ion
1

Hello Cesium Team,

We’re looking into JGD2024 coordinate system support for the point cloud tiler, and have a few questions:

  1. Is JGD2024 support planned for the future?
  2. Are there any upcoming updates to help with the JGD2011 to JGD2024 transition?

Thank you.

2

Hi @Sarah_Osay, I moved your question to the Cesium ion category, as think it’s more appropriate to your questions.

1 Like
5

Hello Gabby,

Thank you so much for moving this post to the correct category.

I also wanted to follow up on our previous questions. We would greatly appreciate it if someone from the Cesium team could verify the information or provide answers.

Thanks again!

6

Hi @Sarah_Osay,

Can you confirm for me if JPGEO2024 is the same as JDG2024?

7

Hello @adam_morris , my apologies for the delay and any confusion. Yes, the correct term is JPGEO2024.

8

Hi @Sarah_Osay,

Thanks for confirming this for us. Unfortunately, it’s too late to get this into our May release but we are planning on getting this rolled out in ion sometime mid-May, and to the CLI with the June release.

I do have one request for you: Do you happen to have any good test data for this coordinate system that you could refer me to? I’m unfortunately not a Japanese speaker and I’m struggling to find some good test data for us to use.

Thank you,

Adam Morris

image

9

Hello @adam_morris ,

I apologize for the delay in providing the test data. Due to the Golden Week holiday in Japan, many of my colleagues were on vacation. I have followed up with them, and they are currently searching for a shareable dataset for you. I’ll send it over to you as soon as I get my hands on it.

10

Hi @adam_morris,

The test dataset for the JPGEO2024 is now ready. You can download it from this Google Drive link: JPGEO2024 Test Data - Google Drive

Please let me know if this dataset works for your testing of the new coordinate system. Happy to help further if needed.

Thanks,
Sarah Osay

11

Hi @Sarah_Osay,

Thank you for sharing this. I’ve attached it to our internal ticket and will update you as soon as we’ve made progress. We should be on track for a June release.

Best regards,

Adam

image

1 Like
12

Hello again @Sarah_Osay,

The data you shared with us seems to still be using JDG2011. Below is partial output from lasinfo64 for the file titled Notowest2-xyz_shifted_JPGEO2024_P2.laz:

key 1026 tiff_tag_location 34737 count 51 value_offset 0 - GTCitationGeoKey: JGD2011 / Japan Plane Rectangular CS VII + unknown
key 2049 tiff_tag_location 34737 count 8 value_offset 51 - GeogCitationGeoKey: JGD2011

Is this expected? If not, would you mind sending some data using JPGEO2024? We’d like to test this out so we can move forward with releasing support for JPGEO2024 in June.

Best regards,

Adam

image

13

Hello @adam_morris ,

Sorry for the delayed reply. Regarding the test data I shared previously: since we don’t have updated data using JPGEO2024 yet, we used JGD2011 data and a coordinate translation software. We took a random XYZ coordinates from the JGD2011 data and used it as a sample to calculate the difference to JPGEO2024. While the metadata hasn’t been updated, the positioning should now follow JPGEO2024. I also updated the file in the link to match the coordinate that we used for the calculation.

1 Like
14

Hello @adam_morris ,

Just wanted to follow up on this post: Do you have an update regarding JPGEO2024 support? It would be great to get a status update or an estimate on its release.

Thanks,
Sarah

15

Hi @Sarah_Osay,

JPGEO2024 support shipped in the June 2025 release. Unfortunately, it was accidentally omitted from the release notes. Please let me know if it’s not working for you, and we can investigate further.

Best regards,

Adam

16

Hello @adam_morris ,

Thank you for the quick response and for confirming that JPGEO2024 support was included in the June release. We appreciate the clarification.

Following your message, we’ll begin internal testing using the cesium-ion-tiling Docker image, version 1.7.0, which we pulled last month (July 2025).

To proceed with our testing, we have one question:

  1. Is there an alternative identifier or method we should be using for JPGEO2024 support?

Thanks again for your help!

Sarah O.

17

Hi @Sarah_Osay,

The team investigated this further and found that it looks like the EPSG code hasn’t been added to the underlying library we use, Proj. While the grid is added, it looks like the only way to use it at the moment is using a special PROJ:EPSG_6667_TO_EPSG_6695_2024 conversion code.

We are still investigating options at the moment. @jaadelgren is the technical contact taking point on this.

Best regards,

Adam

18

Hi @adam_morris ,

Thanks for the update. We tested using the PROJ:EPSG_6667_TO_EPSG_6695_2024 conversion code, but unfortunately, it’s not working on our side. I’ve attached a snapshot of the error from our sample test.

image
image1214×837 38.2 KB

We’ll keep an eye out for further updates from you or @jaadelgren as the investigation continues. Please let us know if there are any other approaches we could try in the meantime.

Best regards,
Sarah

19

Hi @Sarah_Osay,

Thanks for your patience. Unfortunately the code PROJ:EPSG_6667_TO_EPSG_6695_2024 can’t be used directly in this way (it doesn’t seem to be possible at all to simply “swap in” this code for existing EPSG codes). And since there does not appear to be an EPSG code corresponding to height relative to the new JPGEO2024 geoid, there is no simple way to pass the desired information to proj.

I’ve been experimenting a bit and believe I’ve found a command that works:

./bin/pointclouds --input <path/to/laz-file> --output <path/to/output/> --input-crs 'COMPD_CS["JGD2011 / Japan Plane Rectangular CS VII + unknown",PROJCS["JGD2011 / Japan Plane Rectangular CS VII",GEOGCS["JGD2011",DATUM["Japanese_Geodetic_Datum_2011",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","1128"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","6668"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",36],PARAMETER["central_meridian",137.166666666667],PARAMETER["scale_factor",0.9999],PARAMETER["false_easting",0],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Northing",NORTH],AXIS["Easting",EAST],AUTHORITY["EPSG","6675"]],VERTCRS["JPGEO2024 Height",VDATUM["JPGEO2024"],CS[vertical,1],AXIS["gravity-related height (H)",up,LENGTHUNIT["metre",1]],GEOIDMODEL["PROJ jp_gsi_jpgeo2024.tif"],USAGE[SCOPE["Geodesy, engineering survey."],AREA["Japan - onshore mainland - Hokkaido, Honshu, Shikoku, Kyushu."],BBOX[30.94,129.3,45.54,145.87]],ID["EPSG",6695]]]'

Here’s a “before and after” comparison:

jp-height

I had to manually construct a WKT string (most of which I copied from the log output of pointclouds without the –input-crs argument) and explicitly specify the newer grid shift file–note the GEOIDMODEL portion in the string. I wish there were a simpler way to accomplish this, but I haven’t found a way. Please feel free to test this out and let me know how it works for you.

I realize this is probably not an optimal solution for general use. Our team will have to discuss options to make this simpler. In the meantime, we’ll wait for your feedback and iterate from there.