Notifications
Clear all

Anyone try NGS Beta Leveling Tool (LOCUS)?

8 Posts
5 Users
0 Reactions
7 Views
(@geeoddmike)
Posts: 1556
Registered
Topic starter
 

Howdy,

Those registered to get NGS notices have seen that they are developing an on-line leveling adjustment tool. The site address is: http://beta.ngs.noaa.gov/CORS-Proxy/locus/adjust.jsp

I have copied the first few paragraphs of the tool's description below. Be advised that they have also provided a sample input file so that you can see how it works and its output.

Unfortunately, there is no standard format for leveling data (like RINEX for GPS). Field observations must be put into FGCS compliant formats. Another file, containing NGS format descriptions must also be created.

While the tool will be most likely used for contractors and state agencies planning to submit data to the NGS database, users wanting a rigourous adjustment of their data might find it of use.

Some on this board might find the description of how NGS adjusts level data to be of interest. Note that analysis tools are not yet developed for fully constrained adjustments. I hope more details will be developed to describe the tools and processes used.

Enjoy,

DMM

About LOCUS

The Leveling Online Calculations User Service (LOCUS) is a Web utility developed by the National Geodetic Survey (NGS). The purpose of LOCUS is to simplify the office processing and adjustment of geodetic leveling, including, as a long-term goal, the submission of leveling projects to NGS for publication. LOCUS runs the same programs that NGS uses in-house to process and adjust submitted projects.
LOCUS version 1.0 will be limited to:
1. Correction of observations for systematic errors, and
2. A minimally constrained [free] least-squares adjustment. The option for a fully constrained adjustment exists but will not be supported by analysis tools and documentation until later versions.
There is an option to select one of several datums; NAVD 88 is the default.
A correctly formatted NGS Bluebook vertical observation (*.hgz) file must be submitted (the vertical observation format is described in Chapter 6 of the NGS Bluebook). The *.hgz file must first be checked to be error-free by the NGS program Translev (v4.16.07 or later). The NGS program WinDesc must also be used to provide positions of all marks and the Permanent Identifiers (PIDs) of published bench marks into the Translev program.
If more than one published bench mark is included in the *.hgz file, users will see the list of all PIDs available to constrain, and they may choose to do a partially or fully constrained adjustment. However, the tools to analyze the results of a constrained adjustment will not be implemented in the first version of LOCUS. Naturally, the adjusted orthometric heights of new marks will vary according to which constraints are held. Thus, results obtained using LOCUS and adjusted with user-supplied constraints may differ somewhat from results adjusted using constraints determined by NGS for publication.

 
Posted : January 2, 2012 7:33 pm
(@loyal)
Posts: 3735
Registered
 

Hi Mike,

I've been watching for LOCUS for some time now, and noticed on the NGS Main Web-Page a day or so ago. I have read the general blurbs, and downloaded some of the requisite file format data to play with. Sounds like "they" are getting it together, and I look forward to taking it for a spin around the block as soon as time permits (which might not be all that soon unfortunately).

Loyal

 
Posted : January 2, 2012 7:51 pm
(@geeoddmike)
Posts: 1556
Registered
Topic starter
 

Howdy Loyal,

I would have preferred that NGS and other FGCS members would have considered the development of a level observation file format like RINEX rather than developing a tool requiring the creation of an *.hgz file.

Anyone performing geodetic leveling for submission to NGS recognizes the great improvement to the process due to the development of TRANSLEV and Windesc. These programs take FGCS-compliant observations and manipulate them into the *.hgz format.

Given the limited resources of federal agencies for the development and maintenance of software, why not create a file format specification allowing anyone to write a compliant file. Rather than the "Blue Book" format (developed in the 1970's) why not make it more verbose (therefore easier to understand, search and debug) using perhaps XML?

At Texas A&M University-Corpus Christi an attempt was made to create a tool to guide users performing leveling observations to FGCS specifications. After entering order and class of the survey the program (on a data collector) monitored observations for compliance with specifications. The program also queried the on-data collector GPS for instrument station positions. The program also prompted for the meteorological information needed for refraction corrections. This should provide all the information needed to create a file ready for the application of corrections, creation of a network of observations from sections of levels and finally the adjustment of the observations.

Beyond the issue of file formats, a leveling adjustment (with the current NAVD 88 monumented network) will never be a hands off automated process like OPUS. Unlike CORS and other continuously monitored networks, monuments are infrequently visited and even less frequently validated with quality observations. Including a number of benchmarks in an adjustment and expecting all to aqree at an acceptable level is unrealistic even in areas where no geophysical issues like subsidence are suspected. Also unlike GPS there is not much redundancy in leveling observations.

Well enough complaints.

Cheers,

DMM

 
Posted : January 2, 2012 8:50 pm
(@john-hamilton)
Posts: 3347
Registered
 

I have been using LOCUS for a couple of years, most recently on three projects I submitted last month. I didn't look to see if anything has changed from what I was using.

Anyway, it works very well in my opinion. As was said above, leveling adjustments are a different animal than GPS adjustment. Not necessarily more difficult, just different.

However, I just tried to run it with an .hgz file I recently submitted. It said that the file hadn't been checked with the latest version of translev. I downloaded from the link, and it was the same version I have.

But, translev gives an error message that is not correct.

Here is the network:

This is for second order class II. A two BM check is required. There are three existing BM's (1, 2, and 4), and two new BM's (3 and 5). BM 1 is disturbed, even though it is in a rock outcrop. It has settled about 8 cm. The leveling between 2 and 4 checks the published values. Specs say that the leveling line between existing BM's can be single run, but the leveling to new points must be double run.

So, there is double run from 4 (BM) to 3 (new) to 5 (new). Also double run from 1 to 2 (to verify the misclosure). Single run only from 3 to 2. This is to satisfy the two mark tie.

I believe this network meets the criteria for check BM's and single run/double run. I also believe Translev has a problem with the algorithm it is using to check the network.

I would appreciate any comments as to why it wouldn't be correct?

 
Posted : January 3, 2012 6:15 am
(@nate-the-surveyor)
Posts: 10522
Registered
 

Are we talking about Ashtech's LOCUS receivers, or are we talking about something else?

Thanks!

N

 
Posted : January 3, 2012 6:17 am
(@moe-shetty)
Posts: 1426
Registered
 

hi nate,

it is a new ngs product; About LOCUS
The Leveling Online Calculations User Service (LOCUS) is a Web utility developed by the National Geodetic Survey (NGS).
see the original post, above

 
Posted : January 3, 2012 7:24 am
(@geeoddmike)
Posts: 1556
Registered
Topic starter
 

Howdy John,

Looks to me as if you only did a single run between BM 2 and new BM 3. All newly established monuments must be connected by double runs (with forward and backward runs agreeing within specifications for work). You might have connected new BM 3 to published BM 4 with a single run as the difference between your determination and the published value would be the check (in place of a forward and backward run check). My opinion of course.

It is interesting that you identified the BM in bedrock as "bad". I know a number of folks who would hold it over anything else. This of course is the problem with leveling: you can go broke trying to solve problems with inconsistent heights for published BMs. I have seen agencies add observations to additional BMs seeking to solve this problem only to have the situation become more muddled.

For those interested in the specifications see:

http://www.ngs.noaa.gov/FGCS/tech_pub/Fgcsvert.v41.specs.pdf

Good luck,

DMM

 
Posted : January 3, 2012 7:29 am
(@john-hamilton)
Posts: 3347
Registered
 

we thought the BM in the outcrop would be the best. The one directly across the river is in an old rr bridge abutment (bridge gone), so that is stable as well. The other mark, 4, is a concrete post. I wasn't even going to include it until we didn't get a check between 1 and 2 (-0.084 m). BM 4 is flush, so it doesn't look like it is disturbed, but I always mistrust these types of marks. The misclosure from 2 to 4 was -0.002 m versus published.

 
Posted : January 3, 2012 8:52 am