ImageOverlay behaviour with WG84 rasters
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 35/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Stale
- Tech stack
- javascript, python
- Domain
- data-visualization, web-dev
Research direction
Start by reproducing the supplied TIFF example with rasterio and folium.ImageOverlay, then compare its EPSG:4326 handling with the EPSG:3857 QGIS result. Read the ImageOverlay projection and bounds behavior alongside Leaflet's image-overlay expectations; done means the discrepancy is explained and the issue's expected rendering or limitation is documented.
Written by the indexing model from the issue text.
Description
I have a non-expected result when using this code (the raster used is attached to this message):
raster_path = '2019-06-15.tiff'
with rasterio.open(raster_path) as src:
raster_data = src.read(1)
bounds = src.bounds
m = folium.Map(location=[(bounds.top + bounds.bottom) / 2, (bounds.left + bounds.right) / 2], zoom_start=10)
# Create an ImageOverlay
img_overlay = ImageOverlay(
image=raster_data,
bounds=[[bounds.bottom, bounds.left], [bounds.top, bounds.right]],
opacity=0.6,
interactive=False,
cross_origin=True,
zindex=1,
mercator_project=True
)
# Add the overlay to the map
img_overlay.add_to(m)
m.save('map.html')
Indeed, my result html map presents shapes that are not consistent with the same map I could have just by using QGIS.
For instance the result of this code gives this in a specific region:
while using QGIS in an EPSG:3857 projection system gives this:
My raster has natively an EPSG:4326 projection system. I suspect the issue comes from how ImageOverlay changes the projection system.
Can anyone reproduce this and explain how I could obtain the same result as in QGIS which is the correct reference for me?
Thanks,
Vivien
- Dominant language
- Python
- Stars
- 7.4k
- Forks
- 2.3k
- Avg merge
- 17h 22m
- Merged PRs (30d)
- 11
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from python-visualization/folium
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
python-visualization/folium#2092 · 5 comments ·
-
Difficulty 3/5 1-2 days Newbie friendliness 67/100
python-visualization/folium#2278 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 25/100
python-visualization/folium#2259 ·
-
Map output from OSM returns blocked tiles, due to defective request or not following referer-policy Open
Difficulty 3/5 1-2 days Newbie friendliness 55/100
python-visualization/folium#2236 · 5 comments · 1 reaction ·
-
Difficulty 5/5 Over a week Newbie friendliness 10/100
python-visualization/folium#2219 · 2 comments ·
All issues in python-visualization/folium
Similar issues
-
essnmx good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
[Feature] 奇物选择添加优先级 Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
syfoud/Simulated_Scepter#174 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Giskard-AI/giskard-oss#2840 · 1 comment ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Openarea: repo bug perceived difficulty: 2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
yeti-platform/yeti#1380 ·