Regulating Civil and Survey Software
Our recent discussion on regulating GPS reference systems caused quite a sensation, and it seems from the responses and emails I received that indeed there is some room for clarification by the manufacturers of these systems. Most are not certified by NGS (www.ngs.noaa.gov/CORS).
A consensus seems to exist that we want a licensed surveyor to have some stake in certifying these solutions, and it is very ambiguous as to who exactly is certifying these systems and their software they use. A thread of responses agreed that the surveyor is the one who takes full responsibility for the data, its resulting usage and accuracies. There is little argument about that. But that was never the question.
I never suggested that we blindly take the data and its post corrections and move it forward without question. The whole topic was that it is not a transparent process--and it should be!
If so, we could take that same mentality and apply it to other areas, such as civil and survey office software. Every license agreement that you sign or check prior to using an application says that the user is responsible for the outcome of the software’s usage. We all accept that condition.
The main difference between the two situations that I see is that software is well documented. The formulas being used in the algorithms are clearly documented in help menus and user manuals. Calculations are repeatable! Explanation is further augmented by qualified trainers with education in theory and math. With regard to the reference systems, we hit a chord on this aspect across the board. The typical user does not know how things are being computed, and the machinations of the calculations are hidden behind “intellectual property” and “proprietary to our company” references.
In fact, one of the concerns that arose was that if things are indeed as proprietary, as the manufacturers suggest, then maybe one provider has it implemented correctly and they don’t want the others to gain access to their research and programming. Well, that could mean that two others have poorly written software and 2/3 thirds of us are using those. And this is acceptable? We can’t answer yes or no to this because we don’t know.
I sat with a large government agency yesterday and discussed this topic. They agreed that something needs to be done. Many offers come to them to tout a vendor's network, and the agency is fully aware that some of these are cobbled together just to make a buck. They handle it by not referring vendors or equipment.
The answers to the question of what can be done ranges from certification of systems to simply being transparent and open about what the systems are doing and purport to accomplish. Nothing within this range of options is actually being done. Some government agencies that have requested to address this very question have been shot down. By whom and why is a topic requiring more research.
So no, I don’t foresee office software becoming regulated. A professional engineer likely has not certified the outputs and algorithms of these systems, and I don’t hear a calling to do so. But, their actions and outputs are relatively easy to reproduce, certify or check.
Not so with reference networks. I think everyone who responded to this blog wants something more than we are being given now. We want transparency, explanation, and a sense of openness. It would be great if each reference network illustrated its computations and provided test sites to calibrate and examine repeatable observations. There should be an option to switch between overlapping networks to test repeatability and cross check accuracies. Let’s demand it.
A consensus seems to exist that we want a licensed surveyor to have some stake in certifying these solutions, and it is very ambiguous as to who exactly is certifying these systems and their software they use. A thread of responses agreed that the surveyor is the one who takes full responsibility for the data, its resulting usage and accuracies. There is little argument about that. But that was never the question.
I never suggested that we blindly take the data and its post corrections and move it forward without question. The whole topic was that it is not a transparent process--and it should be!
If so, we could take that same mentality and apply it to other areas, such as civil and survey office software. Every license agreement that you sign or check prior to using an application says that the user is responsible for the outcome of the software’s usage. We all accept that condition.
The main difference between the two situations that I see is that software is well documented. The formulas being used in the algorithms are clearly documented in help menus and user manuals. Calculations are repeatable! Explanation is further augmented by qualified trainers with education in theory and math. With regard to the reference systems, we hit a chord on this aspect across the board. The typical user does not know how things are being computed, and the machinations of the calculations are hidden behind “intellectual property” and “proprietary to our company” references.
In fact, one of the concerns that arose was that if things are indeed as proprietary, as the manufacturers suggest, then maybe one provider has it implemented correctly and they don’t want the others to gain access to their research and programming. Well, that could mean that two others have poorly written software and 2/3 thirds of us are using those. And this is acceptable? We can’t answer yes or no to this because we don’t know.
I sat with a large government agency yesterday and discussed this topic. They agreed that something needs to be done. Many offers come to them to tout a vendor's network, and the agency is fully aware that some of these are cobbled together just to make a buck. They handle it by not referring vendors or equipment.
The answers to the question of what can be done ranges from certification of systems to simply being transparent and open about what the systems are doing and purport to accomplish. Nothing within this range of options is actually being done. Some government agencies that have requested to address this very question have been shot down. By whom and why is a topic requiring more research.
So no, I don’t foresee office software becoming regulated. A professional engineer likely has not certified the outputs and algorithms of these systems, and I don’t hear a calling to do so. But, their actions and outputs are relatively easy to reproduce, certify or check.
Not so with reference networks. I think everyone who responded to this blog wants something more than we are being given now. We want transparency, explanation, and a sense of openness. It would be great if each reference network illustrated its computations and provided test sites to calibrate and examine repeatable observations. There should be an option to switch between overlapping networks to test repeatability and cross check accuracies. Let’s demand it.
Comments
Date Posted: Jul 20, 2010 at 1:54 PM
Harry-
Thanks for your observations and to all those with commentary on this important subject of RTN accuracy. It seems like a good time to wade into the discussion and let folks know what NGS is thinking in support of precision GNSS positioning via these RTN. I probably would never be able to regurgitate all the reams of information or hours of discussion interchanged in this process to date, but this will be a start. There are probably over 200 RTN worldwide and over 80 RTN in the USA with around 37 of the 50 states' DOTs involved with planning or operating a RTN. Also, it clearly is a prime positioning vehicle in many applications beyond surveying and engineering - such as precision agriculture, machine guidance, and GIS infrastructure population. I think it was Deral and Loyal that noted NGS is developing RTN guidelines (hard for me to follow the blog comment lines sometimes), so I'd like to summarize some of our thoughts to date:
1. Of foremost importance, NGS will advocate that RTN be aligned to the National Spatial Reference System (NSRS) at a certain level of accuracy. Currently we are saying 2 cm horizontal and 4 cm vertical (ellipsoid) accuracy. This will allow state to state, region to region or RTN to RTN coordinate compatibility (assuming the use of/ translation to the same datums, adjustments and epochs) at acceptable national datum accuracy while allowing each RTN to adjust their network with ultra precision. Two ways to assure this would be “proof in the pudding” methods:
a. From the User End: Establish passive monuments of excellent stability (or as stable as possible) within a RTN at optimum spacing and sky visibility by static GNSS methods and geodetic leveling. These marks should be reobserved and releveled periodically (depending on local motion) to validate or revalue their coordinates and orthometric heights. These marks then constitute RTN fiducial stations at which users can actually see what coordinates the RTN is producing for their gear. Of course the question is who establishes and maintains the marks (show me the money)? This also validates or evaluates the geoid model against the leveling from accepted passive bench marks.
b. From the RTN Administrator End: Ensure that 3 or 10% (whichever is greater) of the RTN reference stations become national CORS. From this scenario, OPUS-S solutions could be produced with, say, 24 hours of data using the RTN stations that are CORS as the fixed stations in the solution. Because the stations are both in the national daily CORS computation (and we thus know the antenna reference point position) as well as in the RTN adjusted position solution, we can produce plots of the ARP and readily note any biases from the published position vis a vis the RTN position. The questions here are: can all the RTN afford to comply with the CORS site requirements for the number of stations required, and what is the result to the user in the field?
2. NGS wishes to promote the ability to use any major GNSS manufacturer’s gear in any RTN.
3. NGS will advocate the use of RTCM v 3.x as the data communication format for RTN positioning via NTRIP software. This open source, generic software is freely available via the BKG on the web for both servers and rovers. RTCM v 3.x is built for RTN use and most GNSS manufacturers include this format in their software/firmware. This also facilitates the ability to use any RTN with any gear.
4. NGS will develop guidelines for both administrators and users of RTN. The intent is not to produce a set of standards or specifications, but rather to promote the guidelines to show a RTN as being compliant. NGS will not mandate any methodology to achieve RTN functionality. The purpose is to bring an awareness of important areas of planning, designing, constructing, administrating and using a RTN.
Because RTN are the new HARN and will become the method of choice to access the NSRS, it is critical that they be consistent and homogeneous to our national datums. Hopefully, we will move beyond our current state of affairs which is like the wild, wild west!
Bill
Thanks for your observations and to all those with commentary on this important subject of RTN accuracy. It seems like a good time to wade into the discussion and let folks know what NGS is thinking in support of precision GNSS positioning via these RTN. I probably would never be able to regurgitate all the reams of information or hours of discussion interchanged in this process to date, but this will be a start. There are probably over 200 RTN worldwide and over 80 RTN in the USA with around 37 of the 50 states' DOTs involved with planning or operating a RTN. Also, it clearly is a prime positioning vehicle in many applications beyond surveying and engineering - such as precision agriculture, machine guidance, and GIS infrastructure population. I think it was Deral and Loyal that noted NGS is developing RTN guidelines (hard for me to follow the blog comment lines sometimes), so I'd like to summarize some of our thoughts to date:
1. Of foremost importance, NGS will advocate that RTN be aligned to the National Spatial Reference System (NSRS) at a certain level of accuracy. Currently we are saying 2 cm horizontal and 4 cm vertical (ellipsoid) accuracy. This will allow state to state, region to region or RTN to RTN coordinate compatibility (assuming the use of/ translation to the same datums, adjustments and epochs) at acceptable national datum accuracy while allowing each RTN to adjust their network with ultra precision. Two ways to assure this would be “proof in the pudding” methods:
a. From the User End: Establish passive monuments of excellent stability (or as stable as possible) within a RTN at optimum spacing and sky visibility by static GNSS methods and geodetic leveling. These marks should be reobserved and releveled periodically (depending on local motion) to validate or revalue their coordinates and orthometric heights. These marks then constitute RTN fiducial stations at which users can actually see what coordinates the RTN is producing for their gear. Of course the question is who establishes and maintains the marks (show me the money)? This also validates or evaluates the geoid model against the leveling from accepted passive bench marks.
b. From the RTN Administrator End: Ensure that 3 or 10% (whichever is greater) of the RTN reference stations become national CORS. From this scenario, OPUS-S solutions could be produced with, say, 24 hours of data using the RTN stations that are CORS as the fixed stations in the solution. Because the stations are both in the national daily CORS computation (and we thus know the antenna reference point position) as well as in the RTN adjusted position solution, we can produce plots of the ARP and readily note any biases from the published position vis a vis the RTN position. The questions here are: can all the RTN afford to comply with the CORS site requirements for the number of stations required, and what is the result to the user in the field?
2. NGS wishes to promote the ability to use any major GNSS manufacturer’s gear in any RTN.
3. NGS will advocate the use of RTCM v 3.x as the data communication format for RTN positioning via NTRIP software. This open source, generic software is freely available via the BKG on the web for both servers and rovers. RTCM v 3.x is built for RTN use and most GNSS manufacturers include this format in their software/firmware. This also facilitates the ability to use any RTN with any gear.
4. NGS will develop guidelines for both administrators and users of RTN. The intent is not to produce a set of standards or specifications, but rather to promote the guidelines to show a RTN as being compliant. NGS will not mandate any methodology to achieve RTN functionality. The purpose is to bring an awareness of important areas of planning, designing, constructing, administrating and using a RTN.
Because RTN are the new HARN and will become the method of choice to access the NSRS, it is critical that they be consistent and homogeneous to our national datums. Hopefully, we will move beyond our current state of affairs which is like the wild, wild west!
Bill
Date Posted: Jul 20, 2010 at 8:14 AM
Deral - I did see the chapter descriptions, but they dont seem to touch much on reference networks. It appears that good coverage is discussion occurs on GPS basics, setup, procedures as evidenced by the chapter titles: GPS Signals, Biases and Solutions, The Framework, Receivers and Methods, Coordinates, Planning a Survey, Observing, Post-Processing, RTK & DGPS.
From this discussion I am seeing that we really need two pieces of information: 1) a laymen's description of what is/should be happening to on observations and their post-corrections in a network and 2) a description of how each manufacturer implements the concepts...
From this discussion I am seeing that we really need two pieces of information: 1) a laymen's description of what is/should be happening to on observations and their post-corrections in a network and 2) a description of how each manufacturer implements the concepts...
