Consider adding a feature for logging

[Maximkaaa]

Currently when coordinate transformation fails log warnings are written for every such point. While is is very useful for console applications and debugging, it can be quite annoying for different kinds of applications. For example, I use your library to render maps in different projections. And then I allow the user to query the objects by the mouse pointer. And when the user moves the mouse outside the projections scope, I get 1 million log warnings:

[2024-01-16T19:25:43Z WARN  geodesy::inner_op::laea] LAEA: (17613175.607089374, 7290876.352930736) outside domain
[2024-01-16T19:25:43Z WARN  geodesy::inner_op::laea] LAEA: (17585327.302897472, 7250347.963004524) outside domain
[2024-01-16T19:25:43Z WARN  geodesy::inner_op::laea] LAEA: (17582293.47894309, 7228565.651940692) outside domain
...

It would be nice if I could opt out from logging, since I handle all transformation failures by my code.

[busstoptaktik]

@Maximkaaa: The logging goes through the log logging facade, which should not do anything unless an external logger is initialized. It is this logger which determines which logging-levels are passed through to the end user.

So the opt-out is a task for the application code: The library will talk into empty space if no logger is initialized. So it is much a case-by-case thing as to "how to opt out".

But basically you opt out by not configuring a logger - or configuring it to only relay sufficiently high logging levels to make the noise level tolerable.

Another thing, however, would be to consider the logging level for out-of-domain messages: Given that it is a basic assumption for Geodesy that "operations may fail for any given coordinate", perhaps a warm! is a too high level log message. Perhaps it should be info!, debug! or trace!?

Any thoughts on this would be most welcome!

[Maximkaaa]

Yes, I could filter out warnings by the namespace with some advanced logging crate, but that seems like unnecessary hustle. In my case, this messages are only useful as debugging information for I expect transformation failures in normal app operation. So if log level would be Debug, that would fit my usecase.

[busstoptaktik]

So if log level would be Debug, that would fit my usecase.

@Maximkaaa I suppose (from my limited knowledge of your use case) that we're talking Wasm, and that your platform is web based. My knowledge about that subject is embarrasingly limited, but I would really like to ensure that Geodesy is as useful as possible for web integration.

And if you get millions of warnings, without having initialized a logger, the web platform must function in a very different way than posixy platforms, and something really must be done to make things work better in your use case.

So can you (and perhaps other Wasm'ers like @Rennzie and @kylebarron) share a few words of advice for avoiding obvious footguns in the work towards better support?

One solution, I could think of, would be to funnel log messages from the the inner-op-tree through the Context, and (either by conditional compilation or by a particularly Wasmic Context implementation) making logging from Geodesy opt-in.

But simply lowering the logging to the debug! level would be simpler and easier - if that would really suffice, a PR would be highly appreciated!

[Maximkaaa]

I think you misunderstood me a little. I do initialize logging since I want my application to write logs. I use both wasm and native builds. I need my application to write logs, but I don't want these warnings to be in there except for debugging. If you think it's ok for other use cases, I'll make a PR to change the log level.

[busstoptaktik]

Resolved by #97