feat: add HAE and DEM projections to SICD sensor model #12
Conversation
| def get_tile(self, tile_path: str) -> Tuple[Optional[Any], Optional[GDALAffineSensorModel]]: | ||
| def get_tile( | ||
| self, tile_path: str | ||
| ) -> Tuple[Optional[Any], Optional[GDALAffineSensorModel], Optional[ElevationRegionSummary]]: |
There was a problem hiding this comment.
Could this Optional[Any] but a Optional[List[Float/Int]] perhaps?
There was a problem hiding this comment.
It should either be a NumPy ndarray or an ArrayLike. This is a method from the abstract base class defined in digital_elevation_model.py. That file has a note to clean up some of the typing now that we've upgraded to NumPy > 1.20 (where typing was added).
This change added the ElevationRegionSummary to this call but didn't change that portion of the signature. I created a ticket on our internal backlog to make sure this tech debt item doesn't fall through the cracks but it isn't part of this feature.
| """ | ||
| Get a summary of the region near the provided world coordinate | ||
|
|
||
| :param world_coordinate: the coordinate at the center of the region of interest |
There was a problem hiding this comment.
Just a small comment but I am not sure we should have a convention about these comments where we don't use "the/a/ect." to start sentences. I have also been using capitalized convention elsewhere - but it doesn't matter at much.
There was a problem hiding this comment.
I don't think there is a standard convention for this. I likely just picked up the convention I use because it was in the examples I saw on the Sphinx website: https://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html#field-lists
The "the/a" convention is used by some projects (e.g. Flask: https://flask.palletsprojects.com/en/2.3.x/api/#flask.Flask.run) and not in others (e.g. NumPy: https://numpy.org/doc/stable/reference/generated/numpy.ndarray.html#numpy.ndarray).
If you feel super strongly about this feel free to make a case for something the team should conform to. Until then I'd rather see the team focus on the quality / content of the documentation rather than a specific sentence structure.
…ns (#19) This release extends OversightML Imagery Toolkit support to new sensor types and imagery formats. The sensor model factories will now produce SICD and RSM sensor models for images with appropriate metadata and the GDAL geo transform based models now correctly uses CRS information from GeoTIFFs. This update also includes new pixel output type and dynamic range adjustment options on the tile factory to produce tiles for visualization tools. --------- Pull Requests Merged: * feat: add SICD sensor model with planar projection (#10) * feat: add optional dynamic pixel range operations to tile factory (#9) * feat: add HAE and DEM projections to SICD sensor model (#12) * feat: fix documentation commands for github actions (#13) * docs: add developer guidance to CONTRIBUTING.md (#11) * fix: correct calculation of INCA R/Rdot projection (#14) * feat: update DRA to work with SICDs (#15) * feat: enable RSM sensor model by default (#16) * feat: gdal sensor model now supports non-wgs84 crs (#17) * docs: update readme for SAR features (#18) * build: bump version for v1.1.0 --------- Co-authored-by: Ranbir Aulakh <[email protected]> Co-authored-by: drduhe <[email protected]>
…ities (#32) This release extends OversightML Imagery Toolkit support to include additional image formats and processing utilities. Key changes include: * Support for SAR imagery including the SICD, and SIDD sensor models and ability to create georeferenced tiles. Also includes basic preprocessing utilities for converting complex data into 8-bit grayscales for display. * RSM sensor models are enabled by default for datasets created using load_gdal_dataset(). * Addition of an optional output_size parameter for the GDALTileFactory that can be used to produce reduced resolution tiles. * Addition of a new aws.osml.features module that contains utilities for working with GeoJSON features derived from imagery. These utilities include spatial indices for creating vector tiles and utilities for working with properties of features that have both geospatil and pixel coordinates. --------- Pull Requests Merged: * feat: add SICD sensor model with planar projection (#10) * feat: add optional dynamic pixel range operations to tile factory (#9) * feat: add HAE and DEM projections to SICD sensor model (#12) * feat: Fix documentation commands for github actions (#13) * docs: Updating CONTRIBUTING.md (#11) * fix: correct calculation of INCA R/Rdot projection (#14) * feat: update DRA to work with SICDs (#15) * feat: enable RSM sensor model by default (#16) * feat: gdal sensor model now supports non-wgs84 crs (#17) * docs: update readme for SAR features (#18) * feat: SAR examples and display processing (#21) * feat: add support for sidd imagery (#22) * feat: Update GitHub actions (#23) * build: Update Github Actions * fix: errors constructing RSMSectionedPolynomialSensorModel from TREs * feat: adds features module with 2D spatial index and basic property utils * feat: adds generic DEM tile set and geodetic coordinate formatting * fix: lint error in generic_dem_tile_set.py * feat: add ability to create scaled tiles and tiles from SIDD * docs: add examples to package level documentation * build: update library version to v1.2.0 --------- Co-authored-by: Ranbir Aulakh <[email protected]> Co-authored-by: drduhe <[email protected]>
These changes allow the SICD sensor models to make use of a Digital Elevation Model (DEM) when performing image to world coordinate conversions. These calculations are described in section 10 of the SICD specification. See: https://nsgreg.nga.mil/doc/view?i=5383
In addition to the SICD sensor model updates a new method was added to the elevation model abstraction that allows us to provide summary information about the area around a given world coordinate. This information is currently used by the SICD sensor model to make searching along a terrain surface more efficient but the summary information itself may eventually be useful to other consumers of the abstraction.
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.