TL;DR

Allow support for 16-bit resolution import/export and arbitrary dimensions.

Use Standard image formats (PNG. TIFF or OpenEXR)

Consider RAW alongside JSON - as used in Unreal/Unity

Detailed thoughts

I've recently detailed a number of issues with the RAW file import format. These taken alongside other feature requests such as those for increased terrain mesh resolution combine to suggest that a revamp is perhaps the best solution.

A new format should allow at least two important future-looking steps. Resolution > 255x255 and higher precision and arguably higher overall height range.

Sticking to common image formats (whether 16-big grayscale, or 48-bit RGB) allows easy user editing/review, as well as simplified external tooling using image manipulation/read/write common to most scripting languages.

RAW format is still used in external systems but it is worth noting that both Unity and Unreal pair the raw format with a JSON file that carries the necessary metadata to properly manipulate these.

The present RAW import format allows a maximim of 255*(255/128) , just under 512m. This is achieved with a ~2m step between levels. The advantage of the combinatory model used is that the unit (step size) can be set per pixel allow for steep cliffs and shallow shelving beaches to be combined in close proximity.

A few options (many others can exist):

a) Fixed unit - 16-bit grayscale - Moving to a simple centimetric 16-bit import would allow ~655m of height at a preset 1cm stepping.

b) User specified uniform unit - Aligned with both Unity and Unreal, whose 16-bit imports are accompanied in the UI with a scale factor (see https://dev.epicgames.com/documentation/en-us/unreal-engine/landscape-technical-guide-in-unreal-engine and https://docs.unity3d.com/Manual/terrain-Heightmaps.html etc.). This allows the terrain base unit to be altered "stretching" each step by the scale factor similarly to how the G channel is used in today's SL RAW.

c) 16-bit R+G combination - Moving the existing 8bit RG RAW format used in SL to 16-bit.

The combinatory option in C offers great flexibility but also introduces other complications. The platform simply does not manage coordinates outside of a signed 16-bit coordinate space, whether at the region (position) level, or the mesh quantised detail level); so server-side validation should limit the coordinate spaces to the platform's current capability, which then still allows for future changes. In real-world terms, Earth spans roughly 20km from the Mariana trench to the tip of Mount Everest and even mapping Martian terrain, we need only a maximum total range of ~29km to span the entirety of Hellas Basin to Olympus Mons. To put some numbers to the potential detail/scale of option C (and how it far exceeds reasonable needs) here's a couple of examples that assume a divisior of 1000:

A 16-bit G value of 1000 is our Unit 1m, this allows for 1mm graduations in shallow shelving (setting G==1), height = R 1/1000 thus a height range of 0-~65m). Meanwhile, a G value of 65535 gives essentially 0-65,535*65535/1000 (>4 million metres). A ludicrous range outside the bounds of any reasonable future expectation.

The second change to consider is the resolution of the maps, currently limited to 255x255. If considered alongside https://feedback.secondlife.com/feature-requests/p/increased-terrain-mesh-resolution, we will need to enable higher resolution imports/exports to map to the mesh size of the terrain correctly. Additionally, with possible thoughts on moving to larger regions (>256m), an often-requested feature that is used extensively in OpenSim through the rather hacky but generally stable VarRegions implementation (http://opensimulator.org/wiki/Varregion), any reworking of terrain tools should allow for this possibility.

The proposal here is simple enough. A bitmap of arbitrary dimensions can be imported, but it will be scaled to the region's scale and resolution. Thus, a 512x512 bitmap used in a current generation Second Life region would be scaled to 256x256 and then applied. Should the terrain mesh density then be increased, the same imported terrain would be able to be used without scaling. Similarly, if regions were expanded and non-square regions, such as 768x512, were allowed, along with a 0.5m terrain resolution, we could deal with it without changes by scaling any imported bitmap to 1536x1024 before applying it. It would, of course, be up to the user to ensure that the aspect ratio was accounted for in their preparation.