feat: add preliminary map tile creation #44
Conversation
| from .sar_complex_imageop import histogram_stretch, quarter_power_image | ||
|
|
||
| __all__ = ["GDALTileFactory", "histogram_stretch", "quarter_power_image"] | ||
| __all__ = [ |
There was a problem hiding this comment.
Should we go back and standardize all our inits to use this all pattern?
There was a problem hiding this comment.
The __all__ list in an init.py defines the set of module names that are imported when someone imports *. The imagery toolkit modules are already making use of this as a way to explicitly define what is part of the public library API and what is not.
In this PR if a consumer writes from aws.osml.image_processing import * then they will get the names listed here which deliberately excludes the WebMercatorQuadTileSet implementation of MapTileSet. The idea is that users should create these well known tile sets using the factory / enumerated IDs in WellKnownMapTileSet and never need to import or instantiate the concrete implementations directly.
| :param tile_matrix_set_id: the tile set id | ||
| :return: the TileSet or None if not available | ||
| """ | ||
| if tile_matrix_set_id == WellKnownMapTileSet.WEB_MERCATOR_QUAD.value: |
There was a problem hiding this comment.
Should the tile size me an initialization argument perhaps? Might that change?
There was a problem hiding this comment.
No; the tile size is specified by the tile set. In this specific instance the "WebMercatorQuad" tile set specifies 256x256 tiles and "WebMercatorQuadx2" is almost identical except each tile is 512x512. In the WebMercatorQuadMapTileSet implementation I made tile size an argument so the same code can work for either but here at the factory when an end user is asking for a specific tile set by ID then the tile size is implied.
edparris
force-pushed
the
feature/basic-map-tiles
branch
from
3849ab2 to
251ab25
Compare
|
|
||
| # If the image has multiple bands then we can stack the results with the band being the 3rd dimension | ||
| # in the array. This aligns to how OpenCV wants to work with imagery. If the image doesn't have multiple | ||
| # bands then |
There was a problem hiding this comment.
Seems like this comment is incomplete?
| src_x = (src_x - src_bbox[0]) / 2**r_level | ||
| src_y = (src_y - src_bbox[1]) / 2**r_level | ||
|
|
||
| # Create 2D linear interpoloators that map the pixels in the map tile to x and y values in the source image. |
There was a problem hiding this comment.
interpoloators -> interpolators
edparris
force-pushed
the
feature/basic-map-tiles
branch
from
251ab25 to
8f21a4c
Compare
This PR gives the tile server the ability to create orthorectified tiles from imagery. New classes have been added to define the common WebMercatorQuad tile set and a new function on the GDALTileFactory can be used to create those tiles directly from an image. This processing uses the sensor model and NumPy to calculate the relationships between the original image and the desired tile then the OpenCV remap function does the heavy lifting of manipulating the pixels. Preliminary performance tests were run by integrating this function into the osml-tile-server and running a load test to exercise the map API. The response time was similar to the the regular tile cutting routines so no unusual performance impacts are expected.
Notes
Checklist
Before you submit a pull request, please make sure you have the following:
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.