Job 1
Prep photos for photogrammetry
Geotags and orients the RS7 photos, ready for 3Dsurvey. Also Metashape, Pix4D and others.
User manual
rOrtho turns a folder that CoPre2 exported from your CHCNAV RS7 into files your other software opens: an orthophoto and a height map on real map coordinates, photos that know where they were taken, and the mesh (the 3D surface CoPre2 builds from the scan) as one file. It is one program with three jobs, runs on your computer and needs no internet.
Each job takes one folder from a CoPre2 export and writes one new folder beside it. This manual numbers the jobs as below. The window does not number them, and it lists Make an orthomosaic first.
Job 1
Geotags and orients the RS7 photos, ready for 3Dsurvey. Also Metashape, Pix4D and others.
Job 2
Renders a true orthophoto (every point seen from straight above, so walls and roof edges do not lean) and a height map (DSM) from the CoPre2 mesh, at the pixel size you choose, as GeoTIFFs in metres, US survey feet or international feet.
Job 3
CoPre2 writes the mesh in several pieces it calls tiles, each an OBJ file (the mesh format 3Dsurvey opens) with a material file (.mtl) and texture images. This job puts every tile into one .obj with one .mtl and the textures beside it, so 3Dsurvey opens the whole model in one drag.
Copy rOrtho.exe anywhere: the desktop, a USB stick or a shared drive. There is nothing to install and no second file to keep beside it.
Double-click it. The start window opens and asks What do you want to make?
The first time, a note explains that nothing is written until you press the big button on a job screen. Press Got it to dismiss it. Until a registration code is entered, the start window is locked and says so; see The small print.
Press Choose a CoPre2 folder... and pick a folder. rOrtho looks inside, works out which job the folder is for, and opens that job with the folder filled in. You can also drop the folder on the window, or drop its metadata.xml.
Each card also has its own Choose folder... button, which opens that job directly. The tree drawn on each card is what to match against Explorer.
Read the job screen top to bottom, then press the one blue button. Every job screen has the same three numbered sections on the left: 1. Folder in, 2. Folder out, 3. Options. The right side shows progress, the log and the result.
| Job | Folder in | Folder out |
|---|---|---|
| Make an orthomosaic | The Model folder: it has metadata.xml and an OBJ folder inside. Usually under AUTOSOLVE, sometimes named Model(1). |
rOrtho-ortho, holding ortho.tif, ortho_dsm.tif and their world and projection files. |
| Prep photos for photogrammetry | The AUTOSOLVE folder with Camera1, Camera2 and Scanner1 inside, under Results\Export\<project>. |
rOrtho-photos: the package, with the photos, a folder per piece of software, a README and a report. |
| Combine mesh tiles | The same Model folder, or the OBJ folder inside it. |
rOrtho-mesh, holding one .obj, one .mtl, every texture image and georef.txt. |
rOrtho chooses the folder out for you, beside the folder you gave the job: rOrtho-photos next to the export, rOrtho-ortho and rOrtho-mesh next to the Model folder. If that folder already exists and has files in it, rOrtho proposes rOrtho-ortho-2, then -3, so a second run never lands on the first.
Press Choose... and rOrtho keeps the folder you pick for as long as the folder in stays the same, whether you come back to the job from a Last time row, from the row that switches jobs, or by picking the same folder again. Give the job a different folder in and the folder out goes back to the default beside that one, because you have moved to another project. Clear the box by hand and rOrtho fills it again, so a run never starts with nowhere to write.
Picked one folder too high? rOrtho looks one level down. If exactly one folder inside is a job, it uses that one and tells you which. If several are, a job screen lists them with a Use this button each; the start window has no folder box to hang that list under, so it says the folder holds more than one thing and asks you to pick one in Explorer.
Photos and a mesh in one export. An AUTOSOLVE folder that also holds a Model folder is two jobs. Handed to the big button, it opens the orthomosaic on the newest Model folder and says so. Its note calls Prep photos one click away on the or choose a different job: row. That row carries the folder now in the box, which is the Model folder, so Prep photos opened from it says the folder looks like a mesh folder. To prep the photos, press Choose... on that screen and pick the AUTOSOLVE folder. Or press Change job and use the Prep photos card's Choose folder... button. If photos and a mesh sit at the same level, a small Which job? box asks.
rortho-gui.log in the folder out. Result shows what was made and what to do with it.Prep photos finishes the current step and leaves nothing half-written. The orthomosaic stops at once, so files being written may be incomplete. Combine mesh tiles deletes its half-written .obj. rOrtho will not close while a job is running; stop it or let it finish first.
The RS7 takes photos as it scans. CoPre2 exports them without positions. This job writes where each photo was taken and which way it was pointing into the photo, works out the coordinate system from the scan itself, and writes a folder of files for each piece of photogrammetry software you use.
Pick the export. The label reads The export folder with Camera1, Camera2 and Scanner1 inside. It is the AUTOSOLVE folder under Results\Export\<project>.
When it fits, the line under the box says looks right with the number of photos and whether a point cloud is there. If it says Camera1 is here but holds no photos directly, you picked the processing folder. Pick the export under Results\Export instead.
Check the folder out. It defaults to rOrtho-photos beside the export. Give it an empty or new folder. If the folder already has files in it, the line under the box turns amber and says rOrtho will refuse to write over them, and the run is refused before it starts. Nothing in that folder is touched until you pick another one; before this release the button started the run anyway, and it deleted any images folder already there, with everything in it, before it wrote the new photos.
Choose how the photos are handled.
Tag the export's own photos (recommended). No copies are made; the pixels are untouched.
Make tagged copies. The export is never written to. Uses twice the disk.
The first choice writes the position and heading into the metadata of each photo in the export and lists those photos in the package. The second leaves the export exactly as CoPre2 wrote it and puts tagged copies in the package.
Tick the software you will open the photos in. 3Dsurvey is ticked by default; the window spells it 3D Survey. Metashape, Pix4D, ContextCapture, OpenDroneMap, Global Mapper, Any GIS and OpenMVG are the others. Each ticked one gets its own small folder of files in the package, so ticking more than one costs nothing. All and None are there for speed.
Leave More options closed unless support asks. It holds the settings support may ask you to change: how the ground surface and the photo masks are made, the coordinate system and heights, the raw capture folder, how much of each photo is used, and the number of cores. The coordinate system is worked out from the scan itself. A code you type there is a candidate, checked against the scan's own coordinates and refused if it does not fit.
Press Make the package. Check only (writes nothing) runs every check and writes only the report, which is a good first run on a new export.
The progress block lists the eight steps in order: read the export, work out the coordinate system, build the ground surface from the point cloud, make the photo masks, write the files for your software, tag the photos, check everything that was written, write the report. The Checks tab lists each check with its value and threshold. The Files tab says how many files were written for each piece of software, and lists anything rOrtho declined to write with the reason.
The Result tab says DONE - your package is ready with the path and four buttons: Open output folder, Open README.txt, Open the report and Open run log. Under them a NEXT line says what to do with what was written:
NEXT: open README.txt. It lists, step by step, what to import into 3Dsurvey (and any other software you ticked). The photos are in the images folder and already carry their positions.
| In the package | What it is |
|---|---|
| images\ | The photos, tagged with position and heading. |
| packages\<software>\ | One folder per piece of software you ticked: the files it imports. |
| README.txt | Step-by-step import instructions for each piece of software. |
| rortho-report.html | The report: the coordinate system found, every check and its result. |
| rortho-manifest.json | The machine-readable record of the run. |
| rortho-gui.log | The run log. |
Under the headline, the Coordinate system block grades what was found: A - on the grid, B - on the grid, weak, or C - no map coordinates. The Photos block says in one sentence what happened to the photos, for example 1,413 photos tagged in place; no copies made.
STOPPED - a check failed, nothing was written. rOrtho checks the export against itself before writing anything. When a check fails, the report names the check and what to do about it, which is often to re-export from CoPre2 and try again.
CoPre2 has already built a textured mesh of the site. This job looks straight down at that mesh and renders a true orthophoto, in which every point is seen from directly above, and a height map at the pixel size you choose. Both come out as GeoTIFFs (images that know where they are on the ground) with a world file, and with a projection file whenever the run has a coordinate system to name, so they land in place in a GIS or CAD.
The label reads The mesh folder with metadata.xml and an OBJ folder inside. In Explorer it is the Model folder under AUTOSOLVE. Pick the Model folder itself; the line under the box then says how many tiles the mesh has.
The folder out defaults to rOrtho-ortho beside the Model folder, and follows the Model folder if you change it. Pick a folder yourself and rOrtho keeps it until you point the job at a different mesh; see Getting started for the whole rule. The file name defaults to ortho and makes ortho.tif and ortho_dsm.tif. Use letters, digits, - and _ only. A run into a folder that already has files replaces files with the same names.
This is the one choice a re-render cannot undo. All four choices are always shown, and the line under them says what rOrtho read off this scan. What you pick is the unit every coordinate in the products is measured in, including the heights in the height map.
| Choice | What you get |
|---|---|
| As scanned (no map coordinates) | The scan's own frame, untouched. A scan solved without GNSS is in metres from wherever the scanner was switched on and will not land on a map. An export that already carries coordinates keeps them, and its own unit, as CoPre2 wrote them. |
| On the ground, US survey feet | A map in the zone the scan was configured for, in US survey feet. |
| On the ground, metres | The same map, in metres. |
| On the ground, international feet | The same map, in international feet. That is a different unit from the US survey foot, two parts per million away from it. See which foot your job is in. |
When you pick the Model folder, rOrtho reads three things off the job: which coordinate system the scan was configured for, which unit the job was going to be delivered in, and where the job's raw GNSS log is. It then selects a ground choice in that unit and fills in the GNSS folder. If the coordinate system cannot be read, or the scan needs a log and none was found, it selects As scanned instead. Once you click a radio yourself, rOrtho stops changing it for the rest of the session.
The zone is matched against rOrtho's own table of State Plane, UTM and low-distortion grids by the numbers that define it, not by its name. Both shapes of State Plane zone are in that table: the tall north-south ones like New Mexico Central, and the wide east-west Lambert ones like Utah North. A grid that is not in the table is refused in a sentence naming its latitude of origin, central meridian, scale and false origin. Send that sentence to iGage.
The line under the radios names the system, the geoid model the job was processed with, and the code that publishes that system in the unit you chose:
This scan was configured for New Mexico Central and processed with GEOID18, which is published on NAD83(2011). In US survey feet that is EPSG:6529.
An EPSG code is the number a GIS uses to name a coordinate system. The geoid model is what decides the middle of that sentence. NAD83 has been re-surveyed since it was first published, and NGS ties each geoid model to one of those surveys: GEOID18 to NAD83(2011), GEOID09 to NAD83(NSRS2007), the older models to the survey of their day. A zone has a different code on each survey. The codes share every projection parameter and the surveys sit about a metre apart on the ground, so the code is the only thing in your deliverable that says which one you are on.
rOrtho takes this from what CoPre2's processing assumed. It has never seen your control. If your control is on another survey of the ground, type that code in the box below.
A scan solved without GNSS in CoPre2 has no coordinates of its own. The raw GNSS log is then the only absolute position anywhere in the job, and a ground run needs it. rOrtho reads the job's own files before it goes looking: the .result beside the export records the log CoPre2 solved from, and the job's .cpr records the raw project folder it lives under. Both were written on the machine CoPre2 ran on, so a job copied to another disk has a path that is no longer there beside a file name that is still right. When neither answers, rOrtho walks up to six folders up from the export and four down, looking for a file ending _T.gps. What it finds goes in the box for you to check, and a folder you pick inside the same job is kept.
An export that already declares its own coordinate system, because the job was processed with GNSS in CoPre2, needs no log at all. rOrtho places it from the coordinates it already has, so the box may stay empty, and a path left there from another job is kept and never read.
Such an export is delivered in the unit you chose, like any other. Nothing on the ground moves. The numbers are converted by the exact ratio between the two units, the .prj is rewritten to match, and the muted line under the radios warns you that the corner coordinates will not be the ones in the export.
How accurate is the placement? The window says it under the GNSS folder: the receiver's own uncorrected fixes place the scan on the map to about a metre. That is good enough for a basemap, and it is not a survey. For survey grade, re-solve the job in CoPre2 with GNSS enabled and export again. An export that already carries its own coordinates is as good as the solve CoPre2 made. rOrtho only converts the unit.
The US survey foot and the international foot are two units. They differ by two parts per million, which is over a metre at a northing in Arizona or Utah, and nothing in the image tells them apart. Six states - Arizona, Michigan, Montana, North Dakota, Oregon and South Carolina - legislate their State Plane zones in international feet, and Arizona Central has no US survey foot code at all, so international feet is a choice of its own rather than a variant of the other one.
The job's .cpr file is the only thing in a CoPre2 job that records which foot it was going to be delivered in, and rOrtho quotes it when you pick the other one. Choosing metres over a foot job gets no such line. Converting a unit is an ordinary thing to ask for, and the file records what CoPre2 was going to write rather than what this run has to be.
Leave Coordinate system code (EPSG) empty and the products carry the code the scan's own zone gives in the unit you chose. Type one only when your deliverable needs a different one. The usual reason is control on another survey of the ground. An As scanned run of a scan with no coordinates of its own gets no code from rOrtho, because the numbers are in no coordinate system and there is nothing to name. A code you type there is still written into the image, which is why the unit check below applies to that run as well.
A code that names the same zone over a different survey of the ground gets that amber line, and the run goes ahead with the code you typed. rOrtho cannot tell which survey your control is on, so it names both and leaves the choice with you. A code that names a different zone altogether says so in as many words, and is still written as you typed it. A code rOrtho's table does not hold is written unchecked, and the line says that too.
rOrtho refuses a code published in a unit this run does not deliver. EPSG:6528 and EPSG:6529 are the same map of the same ground on the same survey, one in metres and one in US survey feet. An image measured in feet under a code that says metres is placed 3.28 times too far from the zone's origin by every GIS that opens it, and nothing in the files records which was meant. The refusal names the code for the same system in the unit you are delivering, or tells you the system is not published in that unit and which choice to pick instead.
Heights are the mesh's own. No geoid model is applied and no conversion to NAVD88 is made. The height map's values are raw mesh heights, which differ from orthometric heights by tens of metres in the mountain west. Read them as heights within the model, not as elevations above sea level, unless your export already carries orthometric heights. The run log repeats the warning on every run.
Pixel size on the ground is in centimetres, and the window suggests 1 cm for an RS7 scan. The presets are 0.5, 1, 2 and 5. Half the pixel size means four times the file size and about four times the wait. On a job in US survey feet, 1 cm becomes 0.0328 ft per pixel in the output, and the Result tab shows that figure to its last digit.
Leave out everything above takes a height, and anything above it is not drawn. Use it when a roof or a ceiling would hide the floor you want to see. Leave it empty to draw everything.
The number is in the unit the products come out in, and the window names that unit beside the box whenever it can work it out. Choose On the ground, US survey feet and 29.5 means 29.5 US survey feet, on any export. Choose As scanned and it is the export's own unit: metres for a scan solved without GNSS, and whatever CoPre2 declared for one that carries its own coordinates.
The height is measured the same way as the heights in the height map (DSM) the run writes. Those are the mesh's own heights, which are not always elevations above sea level (see the warning above). To find a number, run once without a cut and open ortho_dsm.tif, which shows how high the roof or ceiling is. Type a height below the roof or ceiling and above everything you want to see.
More options holds a way to render only part of the site, a choice between smooth and sharp texture sampling, the number of cores, and a box for extra options that support may ask you to type. That box takes any option but one: the unit, which the Coordinates choice above decides. An option naming a unit there would leave the image measured in one unit and named for another, so rOrtho refuses it and says which control to use.
Press Make the orthomosaic. The status line follows the run: reading the mesh, preparing the grid, rendering tile by tile, writing the files. The six-tile site in the figures took 3.5 seconds at 1 cm; larger sites and finer pixels take longer, and the Result tab reports the time of each run. Stop stops at once and may leave incomplete files; run again before using anything in the folder.
A NEXT line under the headline says what to open and where:
NEXT: open ortho.tif in your GIS or CAD; it is a GeoTIFF with a world file, so it lands in the right place. ortho_dsm.tif is the height map (DSM): one height per pixel, same footprint.
| File | What it is |
|---|---|
| ortho.tif | The orthophoto: a colour GeoTIFF, black where there is no mesh. A ground run is north up; an As scanned run of a scan with no coordinates of its own draws it in the scan's own frame. The pixel size, the position and the unit are inside the file, and the EPSG code too when one is known. |
| ortho.tfw | The world file: pixel size and the position of the top-left pixel, for software that reads that instead. |
| ortho.prj | The coordinate system as text. Written whenever the run had a coordinate system to name. An As scanned run of a scan with no coordinates of its own writes none. |
| ortho_dsm.tif | The height map (DSM): one height per pixel, same grid and footprint as the orthophoto, marked as no data where there is no mesh. |
| ortho_dsm.tfw, ortho_dsm.prj | The same two sidecars for the height map. |
| ortho_stats.json | The record of the run: grid size, pixel size, unit, coverage, and how the placement was recovered. |
| rortho-gui.log | The run log. |
In a GIS, drag ortho.tif into QGIS, ArcGIS, Global Mapper or your CAD and it lands on the site in the coordinate system and unit you chose. ortho_dsm.tif opens as a raster with one value per pixel; colour it by value to read the heights. Both rasters share one grid, so a pixel in one is the same patch of ground in the other. The Result tab also reports how much of the image has mesh under it; the rest is black in the orthophoto and empty in the height map.
CoPre2 writes a mesh as several OBJ tiles, five or six on the exports rOrtho was tested on, each with its own material file and texture images. This job writes every tile into one .obj with one .mtl and every texture image beside it, so you load one file instead of five or six. The tiles go in as they are: nothing is joined, smoothed or removed, and the file holds exactly what the tiles held.
The label reads The mesh folder with metadata.xml and an OBJ folder inside (the OBJ folder works too). When it fits, the line says how many tiles will become one file, for example Model\OBJ: looks right: a mesh in 5 tiles, to become one .obj.
The folder out defaults to rOrtho-mesh beside the Model folder, and the .obj and .mtl take the folder's name. A folder name with a space is refused, because an .obj reads a space in a file name as two names. There is nothing to set in 3. Options.
Press Combine the tiles. A real five-tile job took 2.1 seconds. Stopping deletes the half-written .obj and keeps the textures already copied.
Its NEXT line says what to load and what to keep beside it:
NEXT: in 3Dsurvey, load the one .obj from this folder (Mesh > Load). Keep the .mtl and the .jpg textures beside it if you copy it anywhere. georef.txt says where the mesh sits: its coordinates are CoPre2's local ones, and adding the SRSOrigin in that file gives the real ones.
SRSOrigin is a line in georef.txt with three numbers, X, Y and Z: the map coordinates of the point the mesh's local coordinates count from. Add them to a point's X, Y and Z in the .obj to get its map coordinates.
| File | What it is |
|---|---|
| rOrtho-mesh.obj | Every tile in one mesh. Named after the folder out. |
| rOrtho-mesh.mtl | The one material file, naming every texture. |
| *.jpg | Every texture image, copied beside the mesh under its own name. Keep them with the .obj. |
| georef.txt | Where the mesh is: the coordinate system, the origin to add to every vertex, and the unit. The vertices themselves stay in CoPre2's local coordinates. |
| georef.prj | The coordinate system as text, when the export states one. |
3Dsurvey gets one file to load. The textures come with the .obj as long as the .mtl and the .jpg files stay in the same folder. One file also means the viewer decodes every texture image at once; the run log says how much memory that takes, about 2.8 GB for the nineteen images in the example. If a viewer runs out of memory on the merged file, that is why, and the tiles let it load one piece at a time.
Version 0.1.1's third job converted the OSGB copy of the mesh (the other 3D format CoPre2 writes, beside the OBJ tiles), and the window still remembers that folder. Combine mesh tiles works on the OBJ tiles, so the first time you open the job the line under the box says ...\Model\OSGB\Data is the OSGB copy of this mesh. Combining works on the OBJ tiles CoPre writes beside it: pick ...\Model\OBJ instead. Press Use Model\OBJ and carry on.
The light theme is a warm paper tone made for sun on the screen. The monitor button follows the Windows setting. One click changes it and the choice is remembered. If the text is too small, hold Ctrl and press +; Ctrl and - goes back.
Three files, all per user and none beside the executable, so moving or replacing rOrtho.exe costs nothing.
| File | What it holds |
|---|---|
| %APPDATA%\rOrtho\gui-settings.json | The folders and options last used for each job, and the theme. The Last time rows on the start window come from it. Delete it and rOrtho starts with empty boxes. |
| %LOCALAPPDATA%\rOrtho\license.json | The registration this computer holds. |
| %APPDATA%\rOrtho\rortho-gui.log | Every run, appended. Each run also writes its own rortho-gui.log in its folder out. |
Each job remembers its own folder in, its own folder out and its own options. The orthomosaic remembers whether the folder out is one you picked or one rOrtho worked out, so a folder you chose survives a restart and the default still follows the mesh. It also remembers the Coordinates choice and the GNSS folder, and both follow the export. Point the job at another one and rOrtho sets the choice again from what that export can be rendered as, until you click a radio yourself. It replaces the GNSS folder only with a log that belongs to the new export more closely than the one in the box does. A remembered folder that has gone is still shown. The row on the start window says folder not found, and the line under a folder box names the path.
There is nothing to install or migrate. The same settings file is read and every folder and option you had is still in the boxes. Three things behave differently.
Two things that were refused in 0.1.2 now run: an export that carries its own coordinates no longer asks for a GNSS log, and a scan in a Lambert zone such as Utah North can be placed on the ground. One thing is stricter: a zone rOrtho's table does not hold is refused outright rather than written as parameters with no code.
The three jobs need a registration code. Until one is entered, the start window shows a red box with this computer's ID, and its folder buttons are greyed out. Press Enter a registration code... in the red box, Registration in the bottom bar, or the version number in the header, to open the registration box.
A code is made for one computer's ID and works on that computer only. A trial code has an end date, and the registration box says how many days are left. A full code has no expiry. rOrtho never contacts the internet, for registration or anything else.
The registration box also shows the version and the paths of the licence and settings files, so a support call never has to guess where they are.
Every job writes into its folder out, which rOrtho puts beside your export. If you choose a folder out inside the folder in, the line under the box turns amber and every job refuses to start: each one reads the folder it was given while it writes, so pick a folder beside it before you press the button. The one thing rOrtho writes inside an export is the position tags of Job 1's recommended choice, Tag the export's own photos, which change the photos' metadata and not their pixels. Choose Make tagged copies to leave the export untouched.
iGage, igage.com. When something goes wrong, press Copy details for support in the bottom bar. It puts the version, the job, both folders, the command line, the result and the last forty log lines on the clipboard. Paste that into an email.
rOrtho refuses in a sentence under the thing it is about, or on the status line under the button. These are the sentences you are most likely to meet and what to do about each.
| What you see | Why, and what to do |
|---|---|
| rOrtho does not recognise <folder>. It looks for a folder with Camera1, Camera2 and Scanner1 (photos), or metadata.xml and OBJ (mesh). | The folder is neither an export nor a mesh folder, and nothing one level down is either. Open it in Explorer and pick the folder that matches the tree on one of the cards. |
| That folder is not there: <path>. Was the drive or network share disconnected? | A remembered folder has gone. Reconnect the drive, or pick the folder again. |
| Camera1 is here but holds no photos directly. Pick the export under Results\Export, not the processing folder. | Job 1 was pointed at CoPre2's processing tree. The export with the photos is under Results\Export\<project>\AUTOSOLVE. |
| the .PosC header declares its linear unit as "...", which rOrtho has never seen. ... The photo route knows the metre and the US survey foot; a job in international feet can still be rendered by the orthomosaic route, which delivers in all three | Prep photos reads the unit from one file, the .PosC header, and knows metres and US survey feet there. A job in international feet is refused by name rather than guessed at. Make the orthomosaic instead: that job delivers in all three units. |
| Ground coordinates need the job's raw GNSS folder: the GPS folder under the job's raw data, holding a file ending _T.gps. It is the only absolute position anywhere in a scan. Choose it, or switch back to As scanned. | The scan has no coordinates of its own, and the log that would place it was not named by the job's own files or found within six folders up and four down. Press Choose... under The job's raw GNSS folder and pick the folder holding the _T.gps file, often 1-Raw\<job>\GPS\Rover. Or choose As scanned for a picture without map coordinates. |
| <path>: no raw GNSS log (*_T.gps) here. It lives beside the job's raw data, usually 1-Raw/<job>/GPS/Rover/, not in the export. | The folder you picked for the GNSS log holds no _T.gps file. Pick the GPS folder from the job's raw data, not a folder in the export. |
| <path>: no .crd in the export, and none given. Without it nothing names the CRS the operator configured. | A .crd file is where the job records the coordinate system (CRS, coordinate reference system) that whoever set up the scan chose in the field. This export has none, so there is no zone to place it in. Use As scanned, or re-export from CoPre2 with the job's coordinate system set. |
| the export's WKT declares its linear unit as ..., which this tool does not know | WKT (well-known text) is the written-out coordinate system in the export's metadata.xml. Here it names a unit rOrtho does not recognise, and rOrtho refuses rather than guess, because a mesh in feet rendered as metres is 3.28 times wrong in files that look correct. There is no box to type the unit into: it decides the coordinate system code, so the Coordinates choice owns it. Press Copy details for support and send it to iGage. |
| <name> is not a zone rOrtho's table holds: latitude of origin ..., central meridian ..., scale ..., false origin ... | The scan was configured for a grid that is not in rOrtho's table of State Plane, UTM and low-distortion grids, most often a custom low-distortion grid. Use As scanned to get the picture, and send the sentence to iGage: the numbers in it are what a grid has to be added by. |
| EPSG <code> is ... - the same map as the scan's own EPSG:<code>, tied to a different survey of the ground. About a metre apart. rOrtho will write <code>. | Not a refusal. The run goes ahead with your code. Clear the box to keep the code the scan's own zone gives, or leave yours if your control is on that survey of the ground. |
| EPSG <code> is ... in metres, and this run delivers US survey feet. Use <code> for the same system in US survey feet, or choose On the ground, metres. | A refusal, before anything is written. The code you typed is published in a unit this run does not produce, and an image measured in one unit under a code that names another is put in the wrong place by every GIS that opens it. Type the code the sentence names, or change the Coordinates choice to the unit your code is in. |
| ...\Model\OSGB\Data is the OSGB copy of this mesh. Combining works on the OBJ tiles CoPre writes beside it: pick ...\Model\OBJ instead. | Job 3 was pointed at the OSGB copy of the mesh, most likely a folder remembered from version 0.1.1. Press Use Model\OBJ. |
| The .obj takes this folder's name, and rOrtho refuses a name with a space in it: an .obj reads a space in its texture file's name as two names. Pick a folder name without spaces. | Rename the folder out with a hyphen or an underscore instead of the space, for example AB-Framing-mesh. |
| This folder already has files in it. Pick an empty or new folder, or rOrtho will refuse to write over them. | Job 1's folder out is not empty. Despite the sentence, the button stays on. A run into this folder replaces files with the same names and deletes the images folder in it, with everything inside, before it writes its own. To keep what is there, press Choose... and pick an empty or new folder. After a finished run, rOrtho proposes rOrtho-photos-2 by itself. |
| The folder out is inside the folder in. Pick one beside it instead. | Combine mesh tiles will not run into this folder. Prep photos and Make an orthomosaic will, and write their files inside the export. Press Choose... under 2. Folder out and pick a folder beside it. |
| STOPPED - a check failed, nothing was written | One of Job 1's checks found a problem in the export. Press Open the report; it names the check and what to do about it. |
| DID NOT FINISH | The run stopped on an error, which is shown under the headline with the last lines of the log. Try once more. If it fails the same way, press Copy details for support and paste the text into an email to iGage. |
| rOrtho is not registered on this computer. or The rOrtho trial ended on <date>. | Send this computer's ID to iGage and enter the code you get back. See Registration and trial. |
| Stop or finish the current job before closing rOrtho. | A job is running. Press Stop or let it finish, then close the window. |