It needs a place to start. Commonly the unadjusted field points come in with the data and serve that purpose. But if you assigned 5000/5000/100 to pt 101 and 6000/6000/100 to 102, floated (* * *) , it would run and adjust to your held points 103/104 and brg 103-104.
Norman Oklahoma, post: 343239, member: 9981 wrote: It needs a place to start. Commonly the unadjusted field points come in with the data and serve that purpose. But if you assigned 5000/5000/100 to pt 101 and 6000/6000/100 to 102, floated (* * *) , it would run and adjust to your held points 103/104 and brg 103-104.
i know internally least squares adjustment programs need approximate coordinates to start from. However, I don't see why a programmer could not have the program run an initial assumed reduction of the data that could be translated and rotated to generate its own approximate coordinates based on the users control input. SurvNET must do this because it does not require the user to enter approximate coordinates.
Did you get access to the Microsurvey converters with the program demo? If so, did it bring rw5's directly in? Including HI's and HT's?
rfc, post: 343284, member: 8882 wrote: Did you get access to the Microsurvey converters with the program demo? If so, did it bring rw5's directly in? Including HI's and HT's?
On the first Carlson RW5 file it hung up of which I have not gotten a resolution, but the second RW5 came in clean without a problem with HIs and HTs.
Yes, I understand; but did you do it with the converter? I thought they did not come with the demo (which wouldn't really make much sense). I might have been mistaken.
rfc, post: 343289, member: 8882 wrote: Yes, I understand; but did you do it with the converter? I thought they did not come with the demo (which wouldn't really make much sense). I might have been mistaken.
I used their Carlson converter to do the conversion to the STAR*NET DAT file format. So, it appears that it does work with the demo. So far I am 1 success and 1 failure on it so far though.
RCliffWilkie, post: 343217, member: 10285 wrote: Have used Starnet and Geolab and several others for many years. Have heard a lot of good things about Columbus but have not used it. Both Starnet and Geolab are great packages and Columbus sounds very good also. But they all work fine. I like something with an ASCII input capability, but maybe that's just me.
To me, ASCII input is CRITICAL. I like to write my own translators, mainly to get reduced data from my databases out to an adjustment program. I would not use a program that does not have documented ASCII record formats. I have written translators for Geolab and Star*Net, for both conventional data and GNSS data, also for OPUS.
I have been using Geolab consistently since 1986. I did use Trimnet some in the early 90's. I recently (last year) purchased Star*Net and have not yet had much time to use it, but I think it is a good program. I also tried MOVE, but could not get the trial key (a dongle) to work on my computer. Now that I have changed to an SSD on my PC (and reloaded all software), I may try that again, hoping that it (the dongle) will work.
About Geolab...I believe it is the "best" in the sense of most rigorous. It does the adjustments in the ECEF 3-D system, I believe. I have nearly 30 years using it, since it was a dos program. The last real update I got was 2001. Then they kept bugging me to pay a subscription fee, which I was not going to do since there were never any updates. I did pay one or two years. They kept promising new releases, but nothing ever came until a year or two ago. I paid the subscription, got the update, and DO NOT LIKE it. It seems to me to be the same program with a different interface. I don't see any improvements or enhancements to the basic functionality or results, in fact in my opinion it is now harder to use. The only problem I have ever had with it was the network plot, it would often crash the program if I tried to plot on the screen. I told them about that, the response was "must be your graphics card", even though I had the same problem on my laptop and desktop. But that was no big deal to me.
When I changed to a solid state drive on my PC a month or two ago, I forgot to take the geolab license off of the PC. Easy to do, you just run a program and copy a file over to another computer. I contacted microsearch and told them what happened. They said I could not get a new license because I am not currently on the "maintenance subscription" plan. Nice way to treat a 30 year user who has always given strong recommendations about the program. Fortunately I had the license also on my laptop, so now I am back to where I was years ago, having to transfer it out to the laptop if needed. I do use it every day, and have a lot of programs I have written that create input files, read the output, etc.
I willingly pay subscriptions on software when I believe it is worth it (Trimble, etc). Geolab went about 13 years with no updates AT ALL, yet expected people to pay.
So, based on all of the above I would still tell anyone that Geolab is the best LS software, but I would not recommend it due to their policies.
The converter should make a text file with the reason for the failure in it.
I received an RW5 from my coworker that failed to convert. The text file contained the line number and the contents of the offensive line in it. It turns out he started to do a setup but aborted it and started over. The converter didn't like the partial setup so I commented out two lines in the RW5 (-- in front of the line) and it was happy after that.
Dave Karoly, post: 343309, member: 94 wrote: The converter should make a text file with the reason for the failure in it.
I received an RW5 from my coworker that failed to convert. The text file contained the line number and the contents of the offensive line in it. It turns out he started to do a setup but aborted it and started over. The converter didn't like the partial setup so I commented out two lines in the RW5 (-- in front of the line) and it was happy after that.
I had to take out the first two angle sets before it would convert. So, I added them back into the DAT file manually. Not sure what the problem was with those first 2 sets.
What usually happens to me is a set of readings gets aborted in the field in mid set, and the data set is incomplete. The convertor errors out and tells you where it did so - at which line of data. Go into the raw file and remark that incomplete set out (Notepad++ is a handy tool for counting off lines). Your data file will probably run after that.
I don't see it as a problem. It's just a thing. It isn't like that on every job anyway.
John Hamilton, post: 343300, member: 640 wrote: To me, ASCII input is CRITICAL. I have written translators for Geolab and Star*Net, for both conventional data and GNSS data, also for OPUS.
Does the translator you wrote convert an .rw5 right out of SurvCE? or can it convert an ASCII file created out of SurvCE? If so, is it something you'd consider sharing, (or selling)?
I think I've discovered the problem I have with the demo. It's full featured for 10 days, with all the features (including converters) available. After that it "shuts off", and allows a demo mode with no more than 10 points (which is fine for my learning purposes right now); but the converters aren't included in that as far as I can tell.
I'm cobbing together a path into Star*net via TraversePC, but it's pretty clunky and it doesn't include all the data.
No, my translators take data from my database. I have other programs that read the data from the data collector files in to the database. But they are setup to read trimble and zeiss formats.
It turned out to be some missing occupation (OC) records. Apparently SurvNET doesn't mind them being missing, but STAR*NET needs them for the conversion to be correct.