Balancing Scan Time with Postprocessing
-
- I have made <0 posts
- Posts: 2
- Joined: Mon Oct 25, 2021 3:43 pm
- 2
- Full Name: Mike Lovejoy
- Company Details: Helix Energy Partners LLC
- Company Position Title: Helix Energy Partners LLC
- Country: United States
- Skype Name: coverjoy
- Linkedin Profile: Yes
Balancing Scan Time with Postprocessing
Anyone have any input regarding onsite scan time versus the time spent processing the results?
I scan buildings for systems engineering purposes (ie. ductwork, equipment, piping, floorplans, etc.) I am not a professional scanner. I rent the revo-rt or horizon three to four times per year to do some scans. On average, I would say that the scans are quite fast. The buildings are generally less that 100,000 square feet and total time setting up and scanning onsite is only 2-4 hours. I am careful to follow best practices and normally I do not need fine grained detail so the accuracy of the SLAM scanners is just fine for me.
However, when I get back to the office, about 10% of the scans have errors. I then spend another couple days to a week trying to reprocess the SLAM to eliminate these errors. Sometimes, there is nothing I can do and I end up having to go back to the site and scan again and cross my fingers.
In short, I have found that the total time spent processing the data, and merging to something usable for Revit is 13-14x what it took to actually do the scan.
At this point, I am thinking there are really no savings using a SLAM scanner versus a stationary scanner?
I scan buildings for systems engineering purposes (ie. ductwork, equipment, piping, floorplans, etc.) I am not a professional scanner. I rent the revo-rt or horizon three to four times per year to do some scans. On average, I would say that the scans are quite fast. The buildings are generally less that 100,000 square feet and total time setting up and scanning onsite is only 2-4 hours. I am careful to follow best practices and normally I do not need fine grained detail so the accuracy of the SLAM scanners is just fine for me.
However, when I get back to the office, about 10% of the scans have errors. I then spend another couple days to a week trying to reprocess the SLAM to eliminate these errors. Sometimes, there is nothing I can do and I end up having to go back to the site and scan again and cross my fingers.
In short, I have found that the total time spent processing the data, and merging to something usable for Revit is 13-14x what it took to actually do the scan.
At this point, I am thinking there are really no savings using a SLAM scanner versus a stationary scanner?
-
- V.I.P Member
- Posts: 544
- Joined: Fri Feb 24, 2017 10:47 am
- 7
- Full Name: Martin Graner
- Company Details: PointCab GmbH
- Company Position Title: Research and Development
- Country: Germany
- Linkedin Profile: No
- Has thanked: 160 times
- Been thanked: 175 times
- Contact:
Re: Balancing Scan Time with Postprocessing
I don't think that you would be faster with a stationary scanner.SkI67dOO wrote: ↑Mon Oct 25, 2021 6:56 pm Anyone have any input regarding onsite scan time versus the time spent processing the results?
I scan buildings for systems engineering purposes (ie. ductwork, equipment, piping, floorplans, etc.) I am not a professional scanner. I rent the revo-rt or horizon three to four times per year to do some scans. On average, I would say that the scans are quite fast. The buildings are generally less that 100,000 square feet and total time setting up and scanning onsite is only 2-4 hours. I am careful to follow best practices and normally I do not need fine grained detail so the accuracy of the SLAM scanners is just fine for me.
However, when I get back to the office, about 10% of the scans have errors. I then spend another couple days to a week trying to reprocess the SLAM to eliminate these errors. Sometimes, there is nothing I can do and I end up having to go back to the site and scan again and cross my fingers.
In short, I have found that the total time spent processing the data, and merging to something usable for Revit is 13-14x what it took to actually do the scan.
At this point, I am thinking there are really no savings using a SLAM scanner versus a stationary scanner?
If you need 2-4 hours to scan a building with mobile mapping you are going to need around 3 days (+/-) to scan it with a stationary scanner. Then afterwards you need to do the registration, which is a manual task, where the scan positions relation is calculated. Sure, if you are lucky, this are some clicks, like: Import, Find features, find relations, calculate adjustment.
But: If any connection fails, you need to do it manually.
Depending on the number of stations the probability to do this rises a lot, I'd think every 20 - 30 is an average.
The way I would continue if I were in your shoes: If feasable send the scans to GeoSLAM directly, they can reprocess them with different filters, so you don't need to do that yourself + you might not need to go back to rescan the location.
What exactly is failing? Is it one certain scan loop, or is it the merging process?
Because the merging can be done in other software packages as well.
-
- V.I.P Member
- Posts: 916
- Joined: Tue May 11, 2021 5:36 pm
- 2
- Full Name: Adam Berta
- Company Details: InnoScan 3D Hungary Kft
- Company Position Title: unknown
- Country: Hungary
- Linkedin Profile: No
- Has thanked: 52 times
- Been thanked: 297 times
- Contact:
Re: Balancing Scan Time with Postprocessing
With TLS scanners, you need around 1 day registration/cleaning per scanning day, and you still have some spare time... so, if you think that 3-4 day is enough to scan that area then it will be faster overall, and way cleaner looking, but of course you will have so much more data (storage considerations/etc, a good registration software, like cyclone reg360, register (not recap))VXGrid wrote: ↑Tue Oct 26, 2021 8:31 amI don't think that you would be faster with a stationary scanner.SkI67dOO wrote: ↑Mon Oct 25, 2021 6:56 pm Anyone have any input regarding onsite scan time versus the time spent processing the results?
I scan buildings for systems engineering purposes (ie. ductwork, equipment, piping, floorplans, etc.) I am not a professional scanner. I rent the revo-rt or horizon three to four times per year to do some scans. On average, I would say that the scans are quite fast. The buildings are generally less that 100,000 square feet and total time setting up and scanning onsite is only 2-4 hours. I am careful to follow best practices and normally I do not need fine grained detail so the accuracy of the SLAM scanners is just fine for me.
However, when I get back to the office, about 10% of the scans have errors. I then spend another couple days to a week trying to reprocess the SLAM to eliminate these errors. Sometimes, there is nothing I can do and I end up having to go back to the site and scan again and cross my fingers.
In short, I have found that the total time spent processing the data, and merging to something usable for Revit is 13-14x what it took to actually do the scan.
At this point, I am thinking there are really no savings using a SLAM scanner versus a stationary scanner?
If you need 2-4 hours to scan a building with mobile mapping you are going to need around 3 days (+/-) to scan it with a stationary scanner. Then afterwards you need to do the registration, which is a manual task, where the scan positions relation is calculated. Sure, if you are lucky, this are some clicks, like: Import, Find features, find relations, calculate adjustment.
But: If any connection fails, you need to do it manually.
Depending on the number of stations the probability to do this rises a lot, I'd think every 20 - 30 is an average.
The way I would continue if I were in your shoes: If feasable send the scans to GeoSLAM directly, they can reprocess them with different filters, so you don't need to do that yourself + you might not need to go back to rescan the location.
What exactly is failing? Is it one certain scan loop, or is it the merging process?
Because the merging can be done in other software packages as well.
We usually do scan and registration side by side, and after the field ended it takes like 1 or 2 day to finalize the whole building. so it will not take much longer.
And there won't be issues wich is cannot be solved by office work, unless you missed a room or something like that.
I don't have experience with slam devices, but i'm not a huge fan of them.
- smacl
- Global Moderator
- Posts: 1409
- Joined: Tue Jan 25, 2011 5:12 pm
- 13
- Full Name: Shane MacLaughlin
- Company Details: Atlas Computers Ltd
- Company Position Title: Managing Director
- Country: Ireland
- Linkedin Profile: Yes
- Location: Ireland
- Has thanked: 627 times
- Been thanked: 657 times
- Contact:
Re: Balancing Scan Time with Postprocessing
I'd suggest sending a scan that doesn't work to the guys at GeoSLAM and asking them why that it is failing and what, specifically, you can do in the scanning process going forward to avoid that happening in future. There are a number reasons why a SLAM scan might fail (weak loops, broken loops, interference factors such as mirrors etc..) and it is a matter of figuring out which one(s) you're running into and knowing how to recognise and avoid them going forward.SkI67dOO wrote: ↑Mon Oct 25, 2021 6:56 pm Anyone have any input regarding onsite scan time versus the time spent processing the results?
I scan buildings for systems engineering purposes (ie. ductwork, equipment, piping, floorplans, etc.) I am not a professional scanner. I rent the revo-rt or horizon three to four times per year to do some scans. On average, I would say that the scans are quite fast. The buildings are generally less that 100,000 square feet and total time setting up and scanning onsite is only 2-4 hours. I am careful to follow best practices and normally I do not need fine grained detail so the accuracy of the SLAM scanners is just fine for me.
However, when I get back to the office, about 10% of the scans have errors. I then spend another couple days to a week trying to reprocess the SLAM to eliminate these errors. Sometimes, there is nothing I can do and I end up having to go back to the site and scan again and cross my fingers.
In short, I have found that the total time spent processing the data, and merging to something usable for Revit is 13-14x what it took to actually do the scan.
At this point, I am thinking there are really no savings using a SLAM scanner versus a stationary scanner?
One problem with a lot of scanning equipment, SLAM in particular, is that it is sold to some extent as a black box technology that just works and doesn't demand any expertise to use. This isn't always the case, some would reasonably argue that it is rarely the case.
-
- V.I.P Member
- Posts: 643
- Joined: Mon Aug 11, 2008 4:13 pm
- 15
- Full Name: James Rye
- Company Details: Merrett Survey Partnership
- Company Position Title: Spatial Analyst
- Has thanked: 28 times
- Been thanked: 69 times
Re: Balancing Scan Time with Postprocessing
I've used the REVO on past projects. It's OK for coarse building surveys - though as a surveyor, we always have independent control points (spheres) shot in with a total station so that we can measure and correct for drift. And it does drift. Plan your route, keep the scan times short and work in closed loops wherever possible.
The GEOSLAM software is also a bit funky, reprocessing with different settings can vastly improve results.
I used the Zeb Horizon just after the first lockdown here in the UK - I found it to be a lot better than the REVO. Cleaner and tighter registration.
Using a stationary scanner is much slower, but the quality is much higher. As for registration time - this depends on the software/hardware used and experience.We recently used a Trimble X7 and it was a revelation in terms of registering the data. 3 Days on site and less than 1 day in the office.
The GEOSLAM software is also a bit funky, reprocessing with different settings can vastly improve results.
I used the Zeb Horizon just after the first lockdown here in the UK - I found it to be a lot better than the REVO. Cleaner and tighter registration.
Using a stationary scanner is much slower, but the quality is much higher. As for registration time - this depends on the software/hardware used and experience.We recently used a Trimble X7 and it was a revelation in terms of registering the data. 3 Days on site and less than 1 day in the office.
-
- V.I.P Member
- Posts: 544
- Joined: Fri Feb 24, 2017 10:47 am
- 7
- Full Name: Martin Graner
- Company Details: PointCab GmbH
- Company Position Title: Research and Development
- Country: Germany
- Linkedin Profile: No
- Has thanked: 160 times
- Been thanked: 175 times
- Contact:
Re: Balancing Scan Time with Postprocessing
But now you are already mentioning more time and money things:badam wrote: ↑Tue Oct 26, 2021 8:48 amWith TLS scanners, you need around 1 day registration/cleaning per scanning day, and you still have some spare time... so, if you think that 3-4 day is enough to scan that area then it will be faster overall, and way cleaner looking, but of course you will have so much more data (storage considerations/etc, a good registration software, like cyclone reg360, register (not recap))
We usually do scan and registration side by side, and after the field ended it takes like 1 or 2 day to finalize the whole building. so it will not take much longer.
And there won't be issues wich is cannot be solved by office work, unless you missed a room or something like that.
I don't have experience with slam devices, but i'm not a huge fan of them.
- A complete new software
- Training for the software (you will spend a day working with it for every day scanning)
- So much more data shuffeling (complete geoslam project around 1-2 gbyte, you have that with 5-10 scan positions - depending on resolution)
- Learning how to scan with static scanners - thinking about configuration - connections - clusters
If you go into static scanning you'll have a steep learning curve. It's not rocket science, but it is not as easy as it might sound.
@SkI67dOO, if you are like scanning 4 times a year and the results are good enough for you, don't go that road.
For the giggles: Get a quote from a surveyer how much it would cost you to get it scanned with a stationary scanner and compare it to your own costs with a Revo or a Horizon.
- joshhillgeoslam
- I have made 20-30 posts
- Posts: 27
- Joined: Tue Aug 03, 2021 10:20 am
- 2
- Full Name: Josh Hill
- Company Details: GeoSLAM
- Company Position Title: Product Marketing Specialist
- Country: UK
- Linkedin Profile: Yes
- Has thanked: 4 times
- Been thanked: 7 times
Re: Balancing Scan Time with Postprocessing
As people have mentioned, SLAM devices are a lot simpler to use than terrestrial scanners, predominantly due to the fact that a lot of training is required in order to use a terrestrial scanner effectively. Whereas SLAM scanners are easier to understand and can collect the same amount of data in a much shorter time. As long as the best practices highlighted by GeoSLAM are followed (e.g. scans no longer than 20 minutes, closed loops throughout the scan, captured at walking pace etc.), then errors in the resulting point clouds should be minimised. More information on this can be found on our website:
Best Practices - https://geoslam.com/academy/prepare/
What is SLAM - https://geoslam.com/what-is-slam/
If you do find errors in your point clouds, please get in touch with our support team. You can send them the raw data file as well as a brief description of the errors you notice and they will be able to assist with fixing your data and make it look cleaner.
@SkI67dOO I have also spoken to some of my US-based colleagues who will be in touch with you about getting you a trial licence of GeoSLAM Connect as this should further improve the processing of your data.
Best Practices - https://geoslam.com/academy/prepare/
What is SLAM - https://geoslam.com/what-is-slam/
If you do find errors in your point clouds, please get in touch with our support team. You can send them the raw data file as well as a brief description of the errors you notice and they will be able to assist with fixing your data and make it look cleaner.
@SkI67dOO I have also spoken to some of my US-based colleagues who will be in touch with you about getting you a trial licence of GeoSLAM Connect as this should further improve the processing of your data.
- NimaKarkhaneh
- I have made <0 posts
- Posts: 4
- Joined: Fri Jun 01, 2018 10:00 am
- 5
- Full Name: Nima Karkhaneh
- Company Details: Bennett + Bennett
- Company Position Title: Senior Spatial Surveyor
- Country: Australia
- Linkedin Profile: Yes
- Location: Brisbane
- Has thanked: 1 time
- Been thanked: 3 times
Re: Balancing Scan Time with Postprocessing
I want to share my last job experience and I believe it is related to this topic,
We had a real job and It was a simple one, the goal was extraction the internal wall as a 2D map, the target was a 3 story building, (1200 sq.m in total). Arbitrary coordinate system and grayscale scans.
I scanned whole the job in 12 hrs and I registered in 3 hours in Register 360.
We recently got a BLK2GO and we decided to check it in a real job so I scanned the same job in 4 hrs with BLK2GO (I covered outside of the building and also all scans come as a colourful scan by default), I registered the job in an hour. and we compared the data. and below are the result.
Field time: 3x faster
Office time (for rego): 4x faster
BLK2GO coverage is far better than the stationary scanners and it makes our extraction much easier.
If we need a colour full scan, BLK2GO is 4 or 5 times faster than RTC360.
Note:
1- One of our walks with BLK2GO was not good enough but it related to outside scanning and it was not part of the project, so we were fine.
2- Quality of that data for our purpose was just amazing, so we will replace BLK2GO as a handheld solution for a similar job in feature for sure.
3- You need redundant data with handheld scanners to make sure you have enough data in the office to finish the job, as at the moment there is no way to make sure your scans come back 100% OK until you import the data.
We had a real job and It was a simple one, the goal was extraction the internal wall as a 2D map, the target was a 3 story building, (1200 sq.m in total). Arbitrary coordinate system and grayscale scans.
I scanned whole the job in 12 hrs and I registered in 3 hours in Register 360.
We recently got a BLK2GO and we decided to check it in a real job so I scanned the same job in 4 hrs with BLK2GO (I covered outside of the building and also all scans come as a colourful scan by default), I registered the job in an hour. and we compared the data. and below are the result.
Field time: 3x faster
Office time (for rego): 4x faster
BLK2GO coverage is far better than the stationary scanners and it makes our extraction much easier.
If we need a colour full scan, BLK2GO is 4 or 5 times faster than RTC360.
Note:
1- One of our walks with BLK2GO was not good enough but it related to outside scanning and it was not part of the project, so we were fine.
2- Quality of that data for our purpose was just amazing, so we will replace BLK2GO as a handheld solution for a similar job in feature for sure.
3- You need redundant data with handheld scanners to make sure you have enough data in the office to finish the job, as at the moment there is no way to make sure your scans come back 100% OK until you import the data.
- smacl
- Global Moderator
- Posts: 1409
- Joined: Tue Jan 25, 2011 5:12 pm
- 13
- Full Name: Shane MacLaughlin
- Company Details: Atlas Computers Ltd
- Company Position Title: Managing Director
- Country: Ireland
- Linkedin Profile: Yes
- Location: Ireland
- Has thanked: 627 times
- Been thanked: 657 times
- Contact:
Re: Balancing Scan Time with Postprocessing
I think this is a very important point that many people miss. Redundant data adds a small amount of time to data collection but provides the possibility of recovering from errors as well as tightening up registration and improving on QA. Well worth doing with any SLAM based survey.NimaKarkhaneh wrote: ↑Wed Oct 27, 2021 4:53 am3- You need redundant data with handheld scanners to make sure you have enough data in the office to finish the job, as at the moment there is no way to make sure your scans come back 100% OK until you import the data.
-
- V.I.P Member
- Posts: 846
- Joined: Tue Feb 26, 2013 9:32 pm
- 11
- Full Name: Massimo De Marchi
- Company Details: Massimo De Marchi
- Company Position Title: freelancer
- Country: Italy
- Skype Name: massimo_de_marchi
- Has thanked: 15 times
- Been thanked: 53 times
- Contact:
Re: Balancing Scan Time with Postprocessing
I recently purchased the Horizon.
As usual with new tools using it improves the workflow, and I'm still in the learning curve.
Up to now I only had one scan where the alignment failed. It was a combination of featureless, narrow, and everything else should be avoided. It would have been a nightmare with TLS too. Support helped fixing it by the way..
Anyway I often cross check my scans for different reasons (facades are sharper with a TLS and they are scanned with both, or another surveyor have doubts about the quality of the results, and independently shoots some points with total station, or I create a net of control points with GPS/Total Station), and I always had a excellent correspondence between control points and geoslam.
I post process TLS (Faro) data with Scantra, and it's very fast and easy, but in many situations Horizon is so much faster overall (scan time and post processing) that there is no match.
Could you share an example of your area of interest to understand where there could be issues?
Thanks,
Massimo
As usual with new tools using it improves the workflow, and I'm still in the learning curve.
Up to now I only had one scan where the alignment failed. It was a combination of featureless, narrow, and everything else should be avoided. It would have been a nightmare with TLS too. Support helped fixing it by the way..
Anyway I often cross check my scans for different reasons (facades are sharper with a TLS and they are scanned with both, or another surveyor have doubts about the quality of the results, and independently shoots some points with total station, or I create a net of control points with GPS/Total Station), and I always had a excellent correspondence between control points and geoslam.
I post process TLS (Faro) data with Scantra, and it's very fast and easy, but in many situations Horizon is so much faster overall (scan time and post processing) that there is no match.
Could you share an example of your area of interest to understand where there could be issues?
Thanks,
Massimo
ing. Massimo De Marchi - +39 347 32 17 049 - www.studiodemarchi.net