Hi everyone,
Kudos to the Emlid Flow team, it is making our work very productive.
We are aware it is a work in progress so there is still room for improvement so here are my suggestions for more faster interaction on the field (taken from my experience, so some of them can be understood as preferences):
Better point selection when several points are close. When two points “almost” overlap at maximum zoom level (<1m), only one can be selected by clicking on it. It seems the other one is ignored.
The list of objects does not show the name of the object, just the code and datetime which makes it very difficult to find a specific entity. Also, search by name seems to ignore the “name” field.
Every point has exactly the same appearance (a white dot). Maybe different colors and shapes?
Imported objects cannot be edited, except for its name and description.
Code libraries cannot be deleted, renamed, edited… Same applies for individual codes.
Also, while staking points, the left and right buttons at the header seem to follow the order the points where imported, not the real world distance. My experience is once you have located one point on the field, most probably the next one will be the closest to it in a certain direction.
And a long standing issue, a bubble level using the gyro of the RS2 will be great.
Finally, when staking points, tag them as “processed” so they can be ignored and grayed out.
Regarding object editing the obvious one is the appearance of the object itself but it would be beneficial for example to change the code and have the ability to tag objects with multiple values (visited, done, pending… Or missing, in good state, need repair). Ideally, user defined values. We can do it now by changing the name of the object and add those strings… But it is not ideal as it breaks any workflows that rely on the names.
Also, a big win: staking a point and adding the reading of the elevation to the existing xy. Now it can be done by staking then adding a new object.
I think the app has had some great improvements. I like the 360 workflow, which makes processing data for specific tasks a lot easier. One improvement I would suggest is adding the scale factor and convergence for each point within the point info section. We need this info, so curently have partial processing in other software but I would much prefer to move to flow/ flow 360 for everything as the emlid interface is far superior to the other apps we use.
It may not be a feature for everyone it would seal the deal for my arguments to use emlid as an all round service. Fingers crossed.
Yeah no worries, it probably sounds like a strange request. Our workflow involves logging static baseline stations on the ground to assist in calibrating Gyroscopes and motion sensors for vessels and subsea structures before they get deployed. We then survey using this baseline and total stations to calculate what the sensors should read and give correction values to the vessel crews which are applied within their navigation and survey software for operations. These account for any mounting erros within the system, such as the gyrocompass being installed slightly off from the vessel centreline heading. A high level of accuracy is required, so the instruments read the correct value. These errors are projected through the system to the seabed so can create large errors for the client in deeper water.
The static files are currently processed using Auspos, Trimble RTX etc. We then have a further process to define local coordinates. We need the calculated point scale factor and convergence at this stage. Scale factor is applied to total station data and convergence is needed as the instruments used on the vessels all read true north, and not grid north. We also have to reprocess client data if they provide only geographicals or have mixed up which grid system they are using. For our purposes the central meridian scale factor and convergence are not acurate enough for the task, and we have found big changes in scale factor in smaller area systems, such as the UK. That is why having access to point scale and convergence is essential. Currently we use oil and gas specific software to do this. They are clunky, with bad interfaces and only do half the job. These also have a very poor selection of predefined projections and datum shifts. This is why I have been looking at alternatives and came across emlid from the drone projects I have been doing in my own business. The dream is to have a solid workflow which has fewer stages and works.
Our workflow is old, and was the best way to do things many years ago, so will now seem like it is not very good to people reading this. This is why we are researching new methods. I also have trials for using emlids to do the job of the total stations and use studio, flow360 to provide the PPK data for our calculation application. I would also like to use them to eliminate the long static logging sessions and use the kinematic/ stop and go functions in studio to provide the baseline points. Baby steps, but hopefully the old ways can be upgraded.
Thank you for having a look for me, much appreciated.
Scott
Thank you for such a detailed explanation! It’s indeed an unusual application, but it makes it even more exciting to look into how it works. And I totally understand the wish to improve old workflows that are not so convenient. Can’t promise anything now, but I’ve shared the details with the team so that we can think about it!
Thanks for having a look and passing it to the team. Always trying to get the workflow to have as few steps as possible. Fully appreciate this would probably be part of the full subscription which is fine. It is preferable to pay for one solution which makes our lives better than for a few which add to the base frustrations.
Thanks for the report! We reproduced it on our office mobile devices and passed the details to our devs for a closer look. I’ll keep you posted once there’s any news.
Would it be possible to have the shapefile export function use field names that don’t have spaces or other characters not allowed in most ESRI software? It might just be the “GlobalCS” project settings that are affected because the NAD1983 2011 project I exported did use the right naming convention. With the removal of the (.)s that were being used, I can actually open the tables and see the columns but the spaces are still causing strange behavior in the software. I know it also doesn’t like dashes or hyphens.
Also, and this would be huge, could they consider factoring in the 0.134m distance to the antenna phase center to the NMEA outputs so that we’re not left guessing whether or not we need to use 2m or 2.134m for the ESRI apps like Field Maps and Collector? We had been using 2.134m for the last couple of years and when the word got out that the Emlid app was now accounting for it, it sounded like we’d be able to use 2m for any 3rd party software that was getting a position from Reach. It doesn’t seem like that’s the case, though. Or, could they at least make it more clear in the instruction?
With the removal of the (.)s that were being used, I can actually open the tables and see the columns but the spaces are still causing strange behavior in the software. I know it also doesn’t like dashes or hyphens.
Can you tell me a bit more about the strange behavior caused by spaces? What do you see in ESRI software?
As for NMEA, outputting the position related to the antenna phase center is a standard. So, it should work well with 3rd-party software. To receive the position on the ground, you’ll need to subtract the height to the ARP + the antenna offset from the APC coordinate.
