I was there when DPOS was created. Javad had many great minds that would dream up features and implement them. In this case DPOS was very much Javad's own idea, of course developed by so many great minds, particularly @Alexey Razumovsky. But the idea, so far as I know, was Javad's.
We were sitting together in San Jose, CA, early in my time consulting for him (around 2014). I was talking about Mark Silver's use of OPUS. Now OPUS doesn't have developer access. Data must be uploaded through an entry form and is returned by email. Mark had figured out a utility that would bundle a raw data file and submit it to OPUS, filling out the entry form with a very minimal amount of user input. Mark put this utility together with some inexpensive static receivers that he marketed as the X-90 OPUS. The OPUS report would still come back by email. I suspect most OPUS users have a story of mishandling the result when entering the OPUS coordinates from the OPUS report into the data collector or their PC software, but I'd seen other developers at the time create software that could read an OPUS report and import the data without user input. I recommended that Javad should do something similar, as OPUS was the "gold standard" to quote Mark Silver for getting NAD83 coordinates from the CORS.
To be sure, OPUS might not be the best solution, but it does offer some gravitas simply for being a product of NGS. Having said that, OPUS has its limitations. I was incredulous (though I did not show it) when Javad asked rhetorically "Why should we use OPUS when we can make something much better?" Within a very short time of this conversation (perhaps a couple of weeks) the first DPOS version was ready for testing. At first it was just to process the base to the CORS. But even the first iteration offered several advantages over OPUS. Unlike OPUS, DPOS could process GPS and Glonass, it could process much shorter observation files than OPUS-S (static, requires 2 hour minimum) and was arguably more reliable than OPUS-RS (rapid static, which requires up to 9 CORS surrounding the point with good geometry around the point). J-Field could read the instrument height and height type directly from the raw file without user intervention (removing a potential error source), and J-Field could read the DPOS report negating the need for the user to transfer the results from the report to the software. Furthermore, since this was all being handled by the data collector instead of in the PC, it significantly reduced the likelihood that the PC version of coordinates and the DC version would not match. Simply process first, then download to the PC. The transformation was happening at the source instead of further down the chain.
It's been remarkably robust. Most OPUS users can point to times when OPUS would return a cryptic error message that obviously did not fit the actual situation, and at the time DPOS was created there was always a risk that a government shutdown would restrict access to OPUS.
One of the technical achievements I was most proud of in the early version of DPOS was its use of HTDP for transforming from ITRF coordinates to NAD83. In simple terms ITRF is the native coordinate system of the GPS constellation and as a result, the native coordinate system for the CORS network. In the US, the 3D difference between ITRF and NAD83 is about 2m. Horizontally it's about a meter and vertically it's about 1.5 meters. Most every software that performs the transformation from ITRF to NAD83, uses a 14 parameter transformation, which means that every position in the datum is transformed by the same parameters. But in fact, different places in the datum have different velocities. NGS modeled these variations in an application called Horizontal Time Dependent Transformations. It's a more refined approach to transforming a coordinate from ITRF to NAD83. Until quite recently none of the other processing software (at least that I'm aware of) incorporated HTDP into their software, opting for the more generalized 14 parameter transformation. In some places this can result in a few centimeters of difference between an OPUS result and the transformed results of another service, just because of the transformation.
Javad of course really showed off by putting HTDP in J-Field - which is the most technically correct way to deal with the difference in ITRF and NAD83 at present.
In those early days, I sent Javad multiple emails giving him ideas on what would make J-Field superior to other data collection software. One idea I sent was for an onboard post-processor for base-rover solutions. I thought perhaps this idea was permanently sidelined because he never really mentioned it. To be clear I'm not taking credit for the idea of post processing on a data collector. I can only imagine others had a similar idea years before I had. Even more, I don't have the technical knowledge to bring something like that to fruition, which was the case for all of my ideas that I shared with Javad. It's one thing to pop off about a concept. It's quite another thing to actually bring it to reality. But within a couple of years, Javad developed base-rover post processing for DPOS. This addition had so many positive attributes.
Base-rover processing allowed users to get precise results on rover points that exceeded the range of their base corrections. Need to tie in that FEMA benchmark 3 miles away with only a 1-watt base radio. No problem, collect now, process later. It also allowed users to check their RTK results. Because the processing techniques between RTK and Post Processing were so different, users could take no small degree of comfort when returning to the office and post processing their rover points and seeing good agreement between the two. Finally, there were times that post processing was simply more robust than the already robust RTK solution. Perhaps you could get a post processed solution on that point even though RTK would not quite resolve.
What a great utility DPOS has been and of course became the precursor for RTPK which has really revolutionized RTK, becoming the full realization of the onboard base-rover post processing I'd asked Javad for so many years ago. I don't know anyone who, after having DPOS and RTPK, would want to ever turn to a product that could not deliver the same features. Having come from a post processing background, the real magic of DPOS has always been that it delivers such great results (CORS-Base and Base-Rover) without any intervention from the user. No need to massage data to hopefully come to a correct result. DPOS plows through ridiculously difficult data, often with ridiculously short data sets and delivers reliable results.
It's a blessing to have been there so many times when Javad caught an idea and then made it into reality. While it might only have affected our small industry, I always had the sense that I was watching history unfold. Not too many people look at a Wild T-2 and marvel at the technology that made it possible or the incredible work that was done with such a sophisticated tool, but it doesn't make it any less remarkable. The same is certainly true for so many Javad products and services. Even now, nearly 10 years after DPOS was developed, it's stands as such an indispensable tool to those who have come to rely on it.
We were sitting together in San Jose, CA, early in my time consulting for him (around 2014). I was talking about Mark Silver's use of OPUS. Now OPUS doesn't have developer access. Data must be uploaded through an entry form and is returned by email. Mark had figured out a utility that would bundle a raw data file and submit it to OPUS, filling out the entry form with a very minimal amount of user input. Mark put this utility together with some inexpensive static receivers that he marketed as the X-90 OPUS. The OPUS report would still come back by email. I suspect most OPUS users have a story of mishandling the result when entering the OPUS coordinates from the OPUS report into the data collector or their PC software, but I'd seen other developers at the time create software that could read an OPUS report and import the data without user input. I recommended that Javad should do something similar, as OPUS was the "gold standard" to quote Mark Silver for getting NAD83 coordinates from the CORS.
To be sure, OPUS might not be the best solution, but it does offer some gravitas simply for being a product of NGS. Having said that, OPUS has its limitations. I was incredulous (though I did not show it) when Javad asked rhetorically "Why should we use OPUS when we can make something much better?" Within a very short time of this conversation (perhaps a couple of weeks) the first DPOS version was ready for testing. At first it was just to process the base to the CORS. But even the first iteration offered several advantages over OPUS. Unlike OPUS, DPOS could process GPS and Glonass, it could process much shorter observation files than OPUS-S (static, requires 2 hour minimum) and was arguably more reliable than OPUS-RS (rapid static, which requires up to 9 CORS surrounding the point with good geometry around the point). J-Field could read the instrument height and height type directly from the raw file without user intervention (removing a potential error source), and J-Field could read the DPOS report negating the need for the user to transfer the results from the report to the software. Furthermore, since this was all being handled by the data collector instead of in the PC, it significantly reduced the likelihood that the PC version of coordinates and the DC version would not match. Simply process first, then download to the PC. The transformation was happening at the source instead of further down the chain.
It's been remarkably robust. Most OPUS users can point to times when OPUS would return a cryptic error message that obviously did not fit the actual situation, and at the time DPOS was created there was always a risk that a government shutdown would restrict access to OPUS.
One of the technical achievements I was most proud of in the early version of DPOS was its use of HTDP for transforming from ITRF coordinates to NAD83. In simple terms ITRF is the native coordinate system of the GPS constellation and as a result, the native coordinate system for the CORS network. In the US, the 3D difference between ITRF and NAD83 is about 2m. Horizontally it's about a meter and vertically it's about 1.5 meters. Most every software that performs the transformation from ITRF to NAD83, uses a 14 parameter transformation, which means that every position in the datum is transformed by the same parameters. But in fact, different places in the datum have different velocities. NGS modeled these variations in an application called Horizontal Time Dependent Transformations. It's a more refined approach to transforming a coordinate from ITRF to NAD83. Until quite recently none of the other processing software (at least that I'm aware of) incorporated HTDP into their software, opting for the more generalized 14 parameter transformation. In some places this can result in a few centimeters of difference between an OPUS result and the transformed results of another service, just because of the transformation.
Javad of course really showed off by putting HTDP in J-Field - which is the most technically correct way to deal with the difference in ITRF and NAD83 at present.
In those early days, I sent Javad multiple emails giving him ideas on what would make J-Field superior to other data collection software. One idea I sent was for an onboard post-processor for base-rover solutions. I thought perhaps this idea was permanently sidelined because he never really mentioned it. To be clear I'm not taking credit for the idea of post processing on a data collector. I can only imagine others had a similar idea years before I had. Even more, I don't have the technical knowledge to bring something like that to fruition, which was the case for all of my ideas that I shared with Javad. It's one thing to pop off about a concept. It's quite another thing to actually bring it to reality. But within a couple of years, Javad developed base-rover post processing for DPOS. This addition had so many positive attributes.
Base-rover processing allowed users to get precise results on rover points that exceeded the range of their base corrections. Need to tie in that FEMA benchmark 3 miles away with only a 1-watt base radio. No problem, collect now, process later. It also allowed users to check their RTK results. Because the processing techniques between RTK and Post Processing were so different, users could take no small degree of comfort when returning to the office and post processing their rover points and seeing good agreement between the two. Finally, there were times that post processing was simply more robust than the already robust RTK solution. Perhaps you could get a post processed solution on that point even though RTK would not quite resolve.
What a great utility DPOS has been and of course became the precursor for RTPK which has really revolutionized RTK, becoming the full realization of the onboard base-rover post processing I'd asked Javad for so many years ago. I don't know anyone who, after having DPOS and RTPK, would want to ever turn to a product that could not deliver the same features. Having come from a post processing background, the real magic of DPOS has always been that it delivers such great results (CORS-Base and Base-Rover) without any intervention from the user. No need to massage data to hopefully come to a correct result. DPOS plows through ridiculously difficult data, often with ridiculously short data sets and delivers reliable results.
It's a blessing to have been there so many times when Javad caught an idea and then made it into reality. While it might only have affected our small industry, I always had the sense that I was watching history unfold. Not too many people look at a Wild T-2 and marvel at the technology that made it possible or the incredible work that was done with such a sophisticated tool, but it doesn't make it any less remarkable. The same is certainly true for so many Javad products and services. Even now, nearly 10 years after DPOS was developed, it's stands as such an indispensable tool to those who have come to rely on it.
