search

open-forest-observatory / geograypher

Multiview Semantic Reasoning with Geospatial Data
BSD 3-Clause "New" or "Revised" License
10 stars 4 forks source link

Add ability to subset from mesh coordinate system in `PhotogrammetryCameraSet.get_subset_ROI` #61

Closed russelldj closed 5 days ago

russelldj commented 5 months ago

The get_subset_ROI method only works when lat-lon information is provided about each camera. I'm in a situation where some of the cameras are missing this information. It would be nice to subset based on the mesh coordinate system instead, which is the value recorded in the camera transforms. This option could be added as a flag to this method.

Ruprabhu25 commented 2 months ago

More specifically, would we get this info from the cam_to_world_transform matrix? I recall we can get the position (x,y,z,0) from the right hand column of the matrix.

russelldj commented 2 months ago

This issue is a bit stale so things have changed a little. Yes, you're on the right track with how to parse the camera location. Since this issue was written, the default way to get the lat/lon for a MetashapeCameraSet was changed from using the image EXIF to using the camera location, transformed into lat/lon coords. You can see the parser code here.

However, a related issue still remains. We shouldn't require that the camera set can be represented in geospatial coordinates to allow this ROI operation to happen. For example, the concept_figures scene is entirely synthetic and has no notion of a coordinate reference system (CRS). It would be good to stop explicitly using lat/lon for the ROI and instead use a more general notion of "2D location". If the camera set doesn't have geospatial information, the 2D information would just be X,Y.

There would be a fair bit of logic here to ensure that the ROI input matches what's expected for the scene. For example, we should probably start supporting shapely.Polygon/MultiPolygon ROIs, since these would be a good choice for scenes without a CRS.

russelldj commented 2 months ago

Based on the discussion, I think what we want to do is start subsetting the camera set using the internal coordinate system of the camera set, which is not geospatial. In some cases we may have the additional information to compute the geospatial location from each camera in other cases we might not.

To support this, we should probably have a convenience method that gets returns the location of the camera in the internal coordinate system. This could be 2D or 3D or have an argument to switch between them.

Then, we'd want to support non-geospatial ROIs. As described, the shapely.Polygon/MultiPolygon would be a good choice for this. But you could also consider using geopandas objects that don't have a CRS. You'll have to do some digging to see if that exists. I think checking whether the ROI has geospatial information (a meaningful CRS) would be a good way to check if the ROI should be in geospatial or internal coordinates. But you could also have this be specified by the user.