nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

moving oriented Imagery points

SLouq

I have a point feature which represents the camera locations of a 360 Oriented Imagery Dataset taken with the Ricoh Theta X 360 camera. However, the images were taken inside a building and the location of the points is all over. Right now we don't have a connected tablet or iphone to pull location data into the camera inside the buildings.

I was wondering if it is possible to move the point features in ArcGIS Pro to the correct locations where they should go within the building.

I have the building blueprints.

Find more posts tagged with

Accepted answers

CameronRex1

Ah, that helps clarify, it sounds like your points may already be in the Oriented Imagery Dataset, which would explain the editing friction. The OID isn't a plain point feature class; it's a managed dataset, and that's likely why the normal move tools feel locked down and you're having to select each record through the table to reposition it.

Rather than fight the in-place editing, I'd take the points out and rebuild. Specifically:

Export the OID points to a regular point feature class.
Reposition them freely there with the standard editing tools against your georeferenced blueprint.
Update the location and location-dependent attributes—recalculate X/Y (and Z if you're using it) so the coordinates match the new spot, and revisit anything orientation-related like CameraOrientation. This is the part that's easy to miss: moving the point on screen doesn't update the attributes, and the OID reads location from X/Y, not just the displayed geometry. So the point can look moved while the attributes still point to where it used to be.
Run Add Images To Oriented Imagery Dataset to build a new OID, using your corrected point feature class as the input/source.

That way the new OID is constructed from clean, correctly-placed points from the start, instead of trying to repair the existing one in place. It's closer to what I'd originally pictured—staging everything in a plain feature class before ingestion—and it avoids the editing restrictions you're running into entirely.

CameronRex1

Good news...if you've already got a point feature class of the camera locations, you're most of the way there. You don't need location data in the images at all. The "Add Images To Oriented Imagery Dataset" tool can take a feature class (or CSV) built to the oriented imagery table schema as its input—so the locations live in the feature class, not the image metadata. The missing phone/GPS connection doesn't matter here.

So the path is roughly:

Georeference your blueprints in ArcGIS Pro so you've got an accurate backdrop to reposition against.
Create a point feature class with the oriented imagery table schema, and bring your existing points into it along with whatever attributes you already have.
Move the points to where they belong against the blueprint, matching them up by frame number / file name / capture order. Then recalculate X/Y from the corrected geometry and define Z (if multi-floor, set a Z per floor and add a Floor attribute so you can use a definition query to work one floor at a time).
Populate the schema fields and run Add Images To Oriented Imagery Dataset against that feature class.

On the fields—the only hard requirements are X, Y, and ImagePath. For a usable 360 dataset you'll also want OrientedImageryType set to 360, CameraHeading, CameraPitch, CameraRoll, CameraHeight, and Near/FarDistance, plus Name and AcquisitionDate for housekeeping. Anything that's constant across all your images (camera height, etc.) can be set once at the dataset-property level instead of per point. You can skip the photogrammetric fields (Matrix, Omega/Phi/Kappa, focal length, distortion) — those don't apply to consumer 360 spheres.

The one to watch is heading; with no phone/GPS connected, CameraHeading is probably unreliable. If you captured with a consistent "front" direction it's easy to populate; if not, you'll likely be setting it by eye against the blueprint. (For 360, heading sets the viewer's initial/north reference rather than what's visible, so it's about navigation feeling right.)

Happy to go deeper on any step.

All comments

CameronRex1

Rather than fight the in-place editing, I'd take the points out and rebuild. Specifically:

Export the OID points to a regular point feature class.
Reposition them freely there with the standard editing tools against your georeferenced blueprint.
Update the location and location-dependent attributes—recalculate X/Y (and Z if you're using it) so the coordinates match the new spot, and revisit anything orientation-related like CameraOrientation. This is the part that's easy to miss: moving the point on screen doesn't update the attributes, and the OID reads location from X/Y, not just the displayed geometry. So the point can look moved while the attributes still point to where it used to be.
Run Add Images To Oriented Imagery Dataset to build a new OID, using your corrected point feature class as the input/source.

SLouq

The points are not editable through the standard editing tab where you can easily just move the point to it's correct location. I have been experimenting with different ways of moving the points and so far the only way I have found is by going into the table and manually selecting each attribute in the table to select the point and then it will let me move it to where I want.

CameronRex1

One correction worth flagging on CameraHeading, because I undersold it earlier. For 360 it's not just navigation polish—it's the reference the viewer uses to decide which way to face inside the sphere when you click.

Here's the mechanism: when you click a location inside an image's footprint, the viewer measures the direction from the camera point to your click, then displays the sphere rotated by that direction relative to the CameraHeading. In other words, the displayed rotation is the click bearing minus the heading—the heading defines where the sphere's "zero" sits, and everything is shown relative to it.

A worked example. Take an image with heading 0; click directly opposite (180° around from the point) and the viewer shows the sphere rotated 180°; click 90° around and it rotates 90°. Now take an image with heading 90 and click that same opposite spot—the viewer computes 180 − 90 and shows the sphere rotated 90° clockwise. Same click, different result, purely because the heading moved the zero.

So if the heading is recorded wrong, every click is off by the size of that error—the rotation is being computed from a zero that's in the wrong place, and you end up looking the wrong way into an otherwise complete sphere.

This matters all the more in your case, where the camera isn't capturing heading automatically and it's manual entry. Every point's heading is something you're supplying yourself, so getting it right—and capturing with a consistent, known front—is what keeps the click-to-view behavior correct.

CameronRex1

So the path is roughly:

Georeference your blueprints in ArcGIS Pro so you've got an accurate backdrop to reposition against.
Create a point feature class with the oriented imagery table schema, and bring your existing points into it along with whatever attributes you already have.
Move the points to where they belong against the blueprint, matching them up by frame number / file name / capture order. Then recalculate X/Y from the corrected geometry and define Z (if multi-floor, set a Z per floor and add a Floor attribute so you can use a definition query to work one floor at a time).
Populate the schema fields and run Add Images To Oriented Imagery Dataset against that feature class.

Happy to go deeper on any step.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.