Design Discussion and Comments on RINEX version 3 Support in the GPSTk

A new initiative is underway to, over the next year or so, add features to the GPSTk which relate to other GNSS systems. In order to accomplish this goal, new data structures will need to be added to the GPSTk and existing data structures modified. The first part of this task will be to implement RINEX 3 support.

With the addition of RINEX 3, the intention is to maintain support for previous versions of RINEX but reduce any problems that the community may have encountered with these previous version and to add any features the community would prefer. Here are some starter questions to discuss, please add to the list.

  • What problems/limitations of the RINEX 2 support should be avoided?
  • What, if any, are the requirements foreseen for RINEX version 3 support?
  • What new features would you like to see implemented?
  • What issues do you see arising as we incorporate other GNSS data into the GPSTk?

Additional comments on RINEX 3 are also more than welcome. This task will likely be moving forward soon, so a reasonably prompt reply would be greatly appreciated.

-- Contributors: EricHagen - 05 Jun 2008


Some requirements on continuity are appropriate. Specifically, unless there is widespread dissatisfaction with the design of the current FFStream tree, we should require that the v3 fit within that framework. that includes all the design principles that go with it such as having the parsing in a separate class from the representation, having unique classes for the nav, met, and obs data. We should also require that the interface be used (by the programmers) like the existing RINEX interface. Again, that assume that there isn't dissatisfaction with the current paradigm. (I for one, really like what we have).

Another design point is how we address backwards compatibility with v2 support. I believe it would be useful to be able to read a v3 stream and write a v2 stream and vice-versa. Also, if we have a class that represents a v3 stream, I believe it should it be able to transparently read a v2 stream. When doing so, the design should use the existing parsers and not re-implement them. As far as output goes, do we need a way for a v3 object/stream to output a v2 file? I'm not sure what I think on that issue.

As part of the design process we should list all of the target use cases. This would help us put a little rigor on the above discussion.

Code reuse: The parsing of v2 and v3 are going to be very similar so we should consider how they might share implementation.

Performance: The implementation should be efficient enough to support processing large RINEX files (>100MB?) with at least as much efficiency as the existing implementation.

Data organization: The map of maps concept that is used by the v2 support is functional. I don't really like it but haven't thought of anything better. Using that same approach for v3 would be the most direct route. But, if there are other approaches they probably should be discussed.

-- JonLittle - 19 Jun 2008

In general, I'm happy with the current RINEX interface.

Regarding data structures and RINEX 3, I believe that the current "GNSS Data Structures" (GDS) being developed in "procframe" are very well adapted to the upcoming v3.

Work has been done in the previous months to adapt (or at least prepare) several GDS classes to a GNSS-wide system of systems. Part of this work can be seen at the current state of "TypeID" class. There is still plenty of work to be done, though, pending the final implementation of Rinex 3 in the GPSTk.

On the other hand, I must confess that I find FFStream and related classes very powerful but rather obscure. It may be just me, but I really miss lots of comments and documentation in those classes in order to really know what is going on. When I adapted them to feed GDS's, I felt very insecure about the final outcome.

In this regard, I think the software receivers folks using the GPSTk will really appreciate a clear, clean and documented way to develop FFStream-related classes able to turn real-time data streams into Rinex-like data.

Also, along time I've found some errors in the algorithms handling Rinex validity checks. They were reported in the GPSTk developers list, but I believe some of them are still hanging there.

In summary, I agree with Jon: The current classes are fine. However, I really believe they need a general overhaul and clean up by the original coders before using them as the base for Rinex v3.

-- DagobertoSalazar - 27 Jun 2008
Topic revision: r4 - 27 Jun 2008, DagobertoSalazar

This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Foswiki? Send feedback