Possible enhancement: TRANS option for EPSG code based conversion using proj

[megies]

We are usually using meter based coordinate systems for most of our very local to regional models. In custom applications, we simply use TRANS NONE and convert the output to WGS84 afterwards. I think it would be a great addition to be able to specify e.g. TRANS EPSG 31468 to let NonLinLoc know that the models/cubes are in that coordinate system and that output can be transformed using proj going from e.g. EPSG 31468 to EPSG 4326 (example in Python).

Sadly, I'm not doing much C coding and don't know the proj C bindings and whether there are pitfalls to be aware of, otherwise I might make a pull request for it.

CC @jwassermann

[alomax]

Hi Tobias The current transform support in NLL is xy->latlon and latlon->xy, mainly using C code from GMT. So there is not currently code infrastructure to convert between arbitrary projections. Maybe this could be done by xy(EPSG 31468)-> latlon then latlon->(EPSG 4326), but there is still not any existing procedures in NLL that use or support such multi-stage transformations.

If EPSG:4326 can be used identically as simple lat/lon I/O, then implementing xy->latlon and latlon->xy for other needed EPSG internal models/cubes grid coordinates should work. That is, I/O would be lat/lon, while model, travel-time and location grids would be some rectangular EPSG. Some input, such as station coordinates, could also be in the same EPSG, since NLL has an XY station coordinates format (but at this point, what you are doing now with TRANS NONE seems sufficient, except that direct NLL output is not in latlon).

[megies]

Hi Anthony,

I think my memory tricked me, I thought proj was already used as an optional dependency in compilation, but I checked in the code and saw no mention of proj library. So I guess, the main step would be to use proj library as an (optional?) dependency in compilation. The transformation code would be rather short, although proj C API has changed from v4 to v5 and v6 (https://proj.org/development/migration.html).

And yes, in most applications I am fine with having TRANS NONE and converting coordinates myself (did this for years), the main reason for this would be in integrated workflows where we can not interact as easily like in seiscomp.

[megies]

Hi Anthony,

I just noticed, there seems to be support for a transverse mercator transform in TRANS which is not in the documentation. That might even work for us with some modifications on our grid header files etc. This should allow for model grids in projected meter based coordinates and output in Latitude/Longitude WGS, correct?

[alomax]

@megies

Hi Anthony,

I just noticed, there seems to be support for a transverse mercator transform in TRANS which is not in the documentation. Yes, there is a TRANS_MERC which is mentioned in the doc here: http://alomax.free.fr/nlloc/soft7.00/control.html#generic_trans That might even work for us with some modifications on our grid header files etc. This should allow for model grids in projected meter based coordinates and output in Latitude/Longitude WGS, correct? Yes, this was the original purpose for adding this trans, to support a 3D model that was gridded on WGS-84 UTM33 One has to be careful with convention for the distance offsets in the E-W direction.

Anthony