Replies: 3 comments 12 replies
-
|
@alturic 🤷 I can't help without a minimum reproductible example |
Beta Was this translation helpful? Give feedback.
-
|
@alturic by default the output projection is the same as the input projection WGS84 (epss:4326) https://github.com/cogeotiff/rio-tiler/blob/main/rio_tiler/io/rasterio.py#L372 |
Beta Was this translation helpful? Give feedback.
-
|
Vincent, I’m going to work on getting some code, but unless 0.7.0 doesn't use the same output logic for /crop as it does /tile, you would expect a geotiff that produces tiles perfect to also be projected correctly from the /crop endpoint, no? Would a reproducible example be “enough” to show you on the Google USGS Overlay example? That’s ultimately what I’m looking to do with the /crop endpoint… take a large cropped image and put it on the map. I know I’m definitely pulling in the correct lat/lng’s as it’s straight from Google Maps API, but even using their basic code it’s not coming out as expected. It seems like the /crop endpoint is “squishing” the real bounds which when projected on Google it’s being shifted north. Oddly enough the further you zoom in the less the shift is noticeable. Let me work on getting something to you. |
Beta Was this translation helpful? Give feedback.
-
|
Ok, here is what I came up with, I'm unsure if this is "enough". https://jsfiddle.net/m6pvLe0d/1/ Now, the cut-off on the left side of the United States is expected. This is the exact lat/lon I'm expecting the /crop image to be. It's 1903x854 resolution as that's my map div's resolution. The easiest way to tell something is wrong, is by looking at the Great Lakes in the US. You can clearly see the "definition" of them on the colored image, and then Toggle the image on/off and you can see they don't match up. As I said in my most recent reply, and again I'm fairly new to the mapping world, I kind've just assumed the same underlying image that's generated the below (and generates tiles perfectly), would just work when using /crop. And yes, this two above commands are used to generate the underlying geotiff you see in the fiddle, with tiles being correctly made/projected, but that cropped image not. |
Beta Was this translation helpful? Give feedback.
-
|
@vincentsarago Did you have any time to look at the fiddle? I also did a rio info on the source tiff (the one that's making tiles correctly, but cropping it incorrectly/shifting it north. |
Beta Was this translation helpful? Give feedback.
-
|
@alturic sorry I didn't had the time to check yet! |
Beta Was this translation helpful? Give feedback.
-
|
@vincentsarago I believe that in 0.7 the /crop endpoint doesn’t return the image (png in my case) georeferenced even if the originating GTiff is properly referenced, can you confirm of that is the case? By looking at the fiddle I am almost certain that is the issue. I would update to 0.10 but there is BC’s that I can’t easily fix being so new to Python so I just want to confirm the georeference issue first before I go breaking things while trying to fix those BCs. |
Beta Was this translation helpful? Give feedback.
-
|
@alturic I can't reproduce the issue
With GOES input file (in GEOS projection)
|
Beta Was this translation helpful? Give feedback.
-
|
So I fixed the problem. I don't know "what" it actually "is" as again I'm fresh with mapping and georeferencing images, but I'm on 0.7 TiTiler, and 3.1.6 riotiler, I ultimately did this in cogeo.py (which I know is not proper): And the output PNG matches up perfectly. What's interesting to me, regardless if I used 4326 or 3857 as the input COG, both produced the same unaligned output prior to doing that. |
Beta Was this translation helpful? Give feedback.
-
|
@alturic #564 (reply in thread) as I mentioned in ☝️ by default titiler/rio-tiler will assume the bounds CRS to be in EPSG:4326 and if The dataset CRS has no influence on the output CRS. |
Beta Was this translation helpful? Give feedback.
-
|
you can easily create TiTiler endpoints with dst_crs set to "epsg:3857" from typing import Optional
from titiler.core.dependencies import DefaultDependency
from dataclasses import dataclass
from fastapi import Query
@dataclass
class ImageParams(DefaultDependency):
"""Common Preview/Crop parameters."""
max_size: Optional[int] = Query(
1024, description="Maximum image size to read onto."
)
height: Optional[int] = Query(None, description="Force output image height.")
width: Optional[int] = Query(None, description="Force output image width.")
dst_crs: Optional[str] = Query("espg:3857", description="Output Image CRS.")
def __post_init__(self):
"""Post Init."""
if self.width and self.height:
self.max_size = None
cog = TileFactory(img_dependency=ImageParams) |
Beta Was this translation helpful? Give feedback.
-
Hi, we have been using TiTiler for XYZ tiles for a while now, and as we have an immense amount of tiles we are running into 20+ second wait times for all of the tiles to be retrieved as we are hitting the browser connection limits (even splitting the tiles across multiple domains) so we wanted to try using the /crop endpoints and it seemingly works extremely well with one small issue... the image is shifted North in relation to where it should actually be placed.
We are using existing code that worked flawlessly to display the proper sized single image PNG's so I'm struggling to find out where the problem actually lies, or whether /crop would actually allow us to do this, even though it definitely seems like it works as we're expecting with the exception fo the image being shifted just a tad, which is why I'm thinking it's a projection issue?
Beta Was this translation helpful? Give feedback.
All reactions