Name

[larsnaesbye]

Since the crate now supports RINEX, SINEX, and IONEX... is the name rinex not a little misleading and underwhelming?

[gwbres]

Hello @larsnaesbye,

I was thinking about asking your thoughts on this, but actually about SINEX and where we're going about it.

Regarding the current situation, IMO it is totally fine.
IONEX and Clock RINEX are exotic RINEX. File bodies differ but all the rest remains valid.
File bodies differences is already a standard RINEX requirement, so basically the crate in itself was ready for it.
We can reduce that to a couple of new header fields, a new body format while other header fields still apply.

Merging SINEX into RINEX is not a good idea. SINEX is another file format, so the natural
solution is to have a seperate parser / library. Also combining both parsers would make the final parser
once again more complex, which is probably not a good idea.

Now that I think about it, combing both worlds might take place, on the other hand, in the applications.
I think the path that the application is now following is the right one: keep it driven by real applications, end user needs and algorithms.
Currently i'm unlocking features based on what I find in litterature and what I think are end user needs.
We're at the point where we're crossing the bridge between my world (RF/GNSS) and the geodesics world, with interesting computations and data needs that we can already provide an answer to.

So, at some point, we might find interesting SINEX/RINEX combinations and operations. And the application would be the perfect answer to these special needs. At the expense of being able to combine the two worlds, but that would be fine: only the application gets more complex and both worlds lie in seperate libraries