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. 

[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:

1. Georeference your blueprints in ArcGIS Pro so you've got an accurate backdrop to reposition against.
2. 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.
3. 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).
4. 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.

[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.