PyGeoFetch 1.2.0__tar.gz → 1.3.0__tar.gz

{pygeofetch-1.2.0 → pygeofetch-1.3.0}/CHANGELOG.md

@@ -1,9 +1,9 @@
 # Changelog
 
 All notable changes to PyGeoFetch are documented here.
-Format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
+Format follows [Keep a Changelog](https://keepachangelog.com/en/1.3.0/).
 
-## [1.0.0] — 2026-07-12
+## [1.3.0] — 2026-07-12
 
 ### Added
 - Federated search across 22+ satellite data providers

{pygeofetch-1.2.0/pygeofetch.egg-info → pygeofetch-1.3.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: pygeofetch
-Version: 1.2.0
+Version: 1.3.0
 Summary: Universal satellite data pipeline + geospatial processing platform
 Author-email: pygeofetch Contributors <pygeofetch@example.com>
 License: MIT License
@@ -605,6 +605,25 @@ jupyter lab
 
 ---
 
+<p align="center">
+  <img src="https://raw.githubusercontent.com/EOCoreINT/pygeofetch/refs/heads/main/docs/images/trend_map.png?token=GHSAT0AAAAAAD4555HVK7XABUW65FV6B3N22S7TNMA" width="48%" />
+  <img src="https://raw.githubusercontent.com/EOCoreINT/pygeofetch/refs/heads/main/docs/images/trend_classification.png?token=GHSAT0AAAAAAD4555HVX7RLHLSCQSBSGCIY2S7TMFQ" width="48%" />
+</p>
+<p align="center"><em>NDVI trend (2018–2024) and severity classification for the Obuasi Municipal District, computed end-to-end with PyGeoFetch — real USGS Landsat data, boundary-clipped before processing.</em></p>
+
+32.0% of the Obuasi Municipal District shows measurable vegetation decline over 2018–2024 (9.2% strong decline + 22.8% moderate decline), against 57.5% stable and 10.5% showing an increasing trend.
+
+That headline number matters less than where it's concentrated. The decline isn't scattered randomly across the district — it forms a clear, spatially coherent cluster in the western portion of the AOI (roughly west of -1.70° longitude), visible as a dense, contiguous red-and-orange zone in both the trend map and the classification map. Real land degradation signals tend to look like this — clustered along mining concessions, roads, or river corridors — whereas sensor noise or processing artifacts tend to scatter more randomly across the whole scene. The fact that this pattern holds together spatially is a reasonable indicator that it reflects something real on the ground, not just pixel-level noise.
+
+That said, an NDVI trend map on its own can't distinguish why vegetation declined — illegal small-scale mining (galamsey), selective logging, agricultural land clearing, and urban expansion can all produce a similar signature. Given Obuasi's well-documented galamsey activity specifically concentrated in this district, the spatial pattern here is consistent with mining-driven clearance — but confirming that specific cause would need either higher-resolution imagery, ground verification, or cross-referencing against known concession boundaries, not this analysis alone.
+
+Two things worth flagging honestly rather than glossing over:
+
+The scattered dark-blue linear and blob features running through the map (most visibly the river-like feature crossing the upper-central area) are very likely water bodies, not vegetation gain. NDVI trend over open water isn't a meaningful signal — surface reflectance there is driven by turbidity and water level, not plant health — so those features should be excluded from the "increasing" interpretation, not read as reforestation.
+The small white gaps scattered through the trend map (several distinct circular patches) are nodata — pixels that didn't have enough valid, cloud-free observations across all six dates to fit a reliable trend. Worth being upfront that the 32%/57.5%/10.5% breakdown is computed over the valid pixels only, not the full district area including these gaps.
+
+The eastern two-thirds of the district, by contrast, is overwhelmingly stable (dominant green in the classification map), which is itself a useful negative result — it suggests the decline is genuinely localized to a specific area rather than reflecting a district-wide drought or seasonal artifact that would show up everywhere.
+
 ## 📋 Documentation
 
 Full documentation: **https://appiahkubis14.github.io/pygeofetch-docs/**

{pygeofetch-1.2.0 → pygeofetch-1.3.0}/README.md

@@ -470,6 +470,25 @@ jupyter lab
 
 ---
 
+<p align="center">
+  <img src="https://raw.githubusercontent.com/EOCoreINT/pygeofetch/refs/heads/main/docs/images/trend_map.png?token=GHSAT0AAAAAAD4555HVK7XABUW65FV6B3N22S7TNMA" width="48%" />
+  <img src="https://raw.githubusercontent.com/EOCoreINT/pygeofetch/refs/heads/main/docs/images/trend_classification.png?token=GHSAT0AAAAAAD4555HVX7RLHLSCQSBSGCIY2S7TMFQ" width="48%" />
+</p>
+<p align="center"><em>NDVI trend (2018–2024) and severity classification for the Obuasi Municipal District, computed end-to-end with PyGeoFetch — real USGS Landsat data, boundary-clipped before processing.</em></p>
+
+32.0% of the Obuasi Municipal District shows measurable vegetation decline over 2018–2024 (9.2% strong decline + 22.8% moderate decline), against 57.5% stable and 10.5% showing an increasing trend.
+
+That headline number matters less than where it's concentrated. The decline isn't scattered randomly across the district — it forms a clear, spatially coherent cluster in the western portion of the AOI (roughly west of -1.70° longitude), visible as a dense, contiguous red-and-orange zone in both the trend map and the classification map. Real land degradation signals tend to look like this — clustered along mining concessions, roads, or river corridors — whereas sensor noise or processing artifacts tend to scatter more randomly across the whole scene. The fact that this pattern holds together spatially is a reasonable indicator that it reflects something real on the ground, not just pixel-level noise.
+
+That said, an NDVI trend map on its own can't distinguish why vegetation declined — illegal small-scale mining (galamsey), selective logging, agricultural land clearing, and urban expansion can all produce a similar signature. Given Obuasi's well-documented galamsey activity specifically concentrated in this district, the spatial pattern here is consistent with mining-driven clearance — but confirming that specific cause would need either higher-resolution imagery, ground verification, or cross-referencing against known concession boundaries, not this analysis alone.
+
+Two things worth flagging honestly rather than glossing over:
+
+The scattered dark-blue linear and blob features running through the map (most visibly the river-like feature crossing the upper-central area) are very likely water bodies, not vegetation gain. NDVI trend over open water isn't a meaningful signal — surface reflectance there is driven by turbidity and water level, not plant health — so those features should be excluded from the "increasing" interpretation, not read as reforestation.
+The small white gaps scattered through the trend map (several distinct circular patches) are nodata — pixels that didn't have enough valid, cloud-free observations across all six dates to fit a reliable trend. Worth being upfront that the 32%/57.5%/10.5% breakdown is computed over the valid pixels only, not the full district area including these gaps.
+
+The eastern two-thirds of the district, by contrast, is overwhelmingly stable (dominant green in the classification map), which is itself a useful negative result — it suggests the decline is genuinely localized to a specific area rather than reflecting a district-wide drought or seasonal artifact that would show up everywhere.
+
 ## 📋 Documentation
 
 Full documentation: **https://appiahkubis14.github.io/pygeofetch-docs/**

{pygeofetch-1.2.0 → pygeofetch-1.3.0}/pygeofetch/__init__.py

@@ -30,7 +30,7 @@ CLI::
     pygeofetch doctor
 """
 
-__version__ = "1.0.0"
+__version__ = "1.3.0"
 __author__ = "PyGeoFetch Contributors"
 __license__ = "MIT"
 

{pygeofetch-1.2.0 → pygeofetch-1.3.0}/pygeofetch/cli/search_commands.py

@@ -53,6 +53,22 @@ def search() -> None:
     default=None,
     help="Comma-separated satellite names e.g. Sentinel-2,Landsat-8.",
 )
+@click.option(
+    "--product-type",
+    default=None,
+    help=(
+        "SAR product type e.g. GRD, SLC, GRD-COG. Currently only "
+        "meaningfully filters Copernicus (OData-based, not STAC) — "
+        "STAC providers like planetary_computer/element84 offer only "
+        "pre-processed Sentinel-1 RTC via their collection mapping, not "
+        "raw GRD/SLC, so this has no effect there regardless of value."
+    ),
+)
+@click.option(
+    "--polarisation",
+    default=None,
+    help='SAR polarisation e.g. VV, VH, HH, HV. Same Copernicus-only caveat as --product-type.',
+)
 @click.option("--max-results", "-n", default=100, show_default=True)
 @click.option(
     "--sort-by",
@@ -98,6 +114,8 @@ def search_run(
     processing_level,
     providers,
     satellites,
+    product_type,
+    polarisation,
     max_results,
     sort_by,
     sort_order,
@@ -196,7 +214,16 @@ def search_run(
 
     query = SearchQuery(
         bbox=bbox_obj,
-        geometry_geojson=geometry_geojson,
+        # Was "geometry_geojson=geometry_geojson" — a SEPARATE, unused
+        # field that nothing in the codebase actually reads. Every
+        # provider (and the model's own to_stac_params()/
+        # has_spatial_filter() methods) reads query.geometry, not
+        # query.geometry_geojson. This meant --geometry-file silently
+        # never applied real polygon-based spatial filtering at all —
+        # it fell back to the bbox approximation computed just above
+        # (still functional, but loses the actual polygon precision
+        # that geometry-based filtering exists to provide).
+        geometry=geometry_geojson,
         start_date=start_date,
         end_date=end_date,
         cloud_cover_min=cloud_min,
@@ -205,6 +232,8 @@ def search_run(
         resolution_max_m=res_max,
         processing_levels=pl_list,
         satellites=sat_list,
+        product_type=product_type,
+        polarisation=polarisation,
         max_results=max_results,
         providers=provider_list or [],
         sort_by=sort_by,

{pygeofetch-1.2.0 → pygeofetch-1.3.0}/pygeofetch/core/authenticator.py

@@ -492,4 +492,4 @@ class AuthManager:
                     "auth_type": creds.auth_type.value,
                     "username": creds.username,
                 }
-        return result
+        return result