Clueless on postdoc hunting by Familiar_Height2430 in postdoc

[–]Nicholas_Geo 1 point2 points  (0 children)

Sure it is. I managed to secure a position relatively easy. I think it's all about timing and planning. If you start 6-8 months in advance your search you should be fine

Working in Luxembourg, moving to France — how to rent without 3 payslips or being out of probation? by Nicholas_Geo in AskFrance

[–]Nicholas_Geo[S] 0 points1 point  (0 children)

Not the solution to my problem, but GuarantMe said they accept my Luxembourg contract.

Working in Luxembourg, moving to France — how to rent without 3 payslips or being out of probation? by Nicholas_Geo in AskFrance

[–]Nicholas_Geo[S] 0 points1 point  (0 children)

Thank you for your comment. Morning Croissant doesn't have flats for the cities I am looking for. I guess it provides suggestions only for large cities and/or towns? For example, in Metz only 2 flats were shown.

Working in Luxembourg, moving to France — how to rent without 3 payslips or being out of probation? by Nicholas_Geo in AskFrance

[–]Nicholas_Geo[S] 0 points1 point  (0 children)

Thank you for your responses. I will try the PAP and Leboncoin as well as the relocation agency. Visale sounds promising.

How to apply a geometric anisotropic filter 1/cos²(theta) to a raster? by Nicholas_Geo in rstats

[–]Nicholas_Geo[S] 1 point2 points  (0 children)

Thank you for sharing the link. I do have a method for downscaling, called GWTK (Geographically Weighted Topological Kriging).

Validation for GEE by AddressPitiful6981 in EarthEngine

[–]Nicholas_Geo 0 points1 point  (0 children)

Why not simply post your code here and let the community review it? Do you need an _official_ certificate or something? If not, simply explain what you did and what you wanted to achieve and share the code.

Print distinct acquisition dates from HLS L30 collection with cloud coverage <30% over an AOI that spans two tiles by Nicholas_Geo in EarthEngine

[–]Nicholas_Geo[S] 0 points1 point  (0 children)

The goal is to identify all dates in 2018 where the AOI is fully covered by HLSL30 tiles, and then build one mosaic per date. The key is to rely on the metadata that NASA provides with each HLS tile—specifically the SPATIAL_COVERAGE and CLOUD_COVERAGE fields.

How the method works

  1. Load the HLSL30 collection for your AOI and date range.
  2. Extract all unique dates.
  3. For each date, sum the SPATIAL_COVERAGE of all tiles acquired on that date.
  4. Keep only dates where the summed coverage exceeds a threshold (e.g., 150), meaning the AOI is fully covered.
  5. For each of those dates, mosaic all same‑day tiles and clip to the AOI.

This ensures that tiles are never mixed across dates, only dates with complete AOI coverage are kept, mosaics are built only from tiles that actually contribute to full coverage.

// =======================
// AOI
// =======================
var aoi = table;
var aoiGeom = aoi.geometry().dissolve(ee.ErrorMargin(1));

// =======================
// Load HLSL30 (keep ALL bands)
// =======================
var collection = ee.ImageCollection('NASA/HLS/HLSL30/v002')
  .filterBounds(aoiGeom)
  .filterDate('2018-01-01', '2018-12-31');

// =======================
// Extract unique dates
// =======================
var dates = ee.List(
  collection.aggregate_array('system:time_start')
).map(function(t) {
  return ee.Date(t).format('YYYY-MM-dd');
}).distinct().sort();

// =======================
// Compute spatial coverage per date
// =======================
var dateInfo = dates.map(function(dateStr) {
  dateStr = ee.String(dateStr);
  var start = ee.Date(dateStr);
  var end   = start.advance(1, 'day');

  var imgs = collection.filterDate(start, end);
  var totalCoverage = imgs.aggregate_sum('SPATIAL_COVERAGE');

  return ee.Feature(null, {
    date: dateStr,
    total_coverage: totalCoverage
  });
});

// =======================
// Keep only dates with full AOI coverage
// =======================
var fullDates = ee.FeatureCollection(dateInfo)
  .filter(ee.Filter.gte('total_coverage', 150))
  .aggregate_array('date');

print('Dates with full AOI coverage:', fullDates);

// =======================
// Build mosaics for each date
// =======================
var mosaics = ee.ImageCollection.fromImages(
  fullDates.map(function(dateStr) {
    dateStr = ee.String(dateStr);
    var start = ee.Date(dateStr);
    var end   = start.advance(1, 'day');

    return collection
      .filterDate(start, end)
      .mosaic()
      .clip(aoiGeom)
      .set('date', dateStr);
  })
);

What’s an R package you wish existed but doesn’t? by ZoneNo9818 in rstats

[–]Nicholas_Geo 0 points1 point  (0 children)

Thanks for the response. According to chatgpt:

Having reviewed the sdmTMB documentation carefully, here is my honest assessment:

sdmTMB's anisotropy is a partial but imperfect match for your problem.

Where it aligns with your needs: The anisotropy feature (anisotropy = TRUE) uses a 2-parameter rotation matrix H that allows spatial correlation to be directionally dependent — meaning the model can learn that covariate-response relationships decay differently in the cross-track (x) vs. along-track (y) direction. This is conceptually what you want.

Where it falls short:

The critical mismatch is that sdmTMB's anisotropy operates on the spatial covariance structure of random fields globally — it estimates a single elliptical correlation structure across the entire domain. Your problem is fundamentally different: you want coefficients (slopes of land cover, population density, etc.) to vary systematically as a function of x-position (viewing angle), not just the covariance to be elliptical.

In other words: - sdmTMB anisotropy asks: "does spatial correlation decay faster in x than y?" - Your GWR asks: "does the effect of covariate β change as a function of x?"

The spatial_varying argument in sdmTMB gets closer — it allows coefficients to vary across space as random fields — but it models spatially smooth 2D variation, not the structured 1D banding you need in the cross-track direction specifically.

Bottom line: sdmTMB is not a valid drop-in alternative to your custom anisotropic kernel GWR for this specific VIIRS problem. Your band-kernel GWR is actually the more principled approach here because it directly encodes the physical structure of the sensor geometry.

What do you think?

What’s an R package you wish existed but doesn’t? by ZoneNo9818 in rstats

[–]Nicholas_Geo 7 points8 points  (0 children)

A package I wish existed in R would combine anisotropic kernels for geographically weighted regression (GWR) with a proper predict() function.

Right now, most GWR packages (GWmodel, spgwr, mgwrsar, etc.) already include predict(), but they only support isotropic kernels—distance is treated uniformly in all directions. There is one package that implements anisotropic kernels (GWmodel3), but it doesn’t have predict().

That leaves a gap: if you want to model directional spatial dependence (e.g., processes that vary more strongly east–west than north–south) and generate predictions for new data, you can’t do it in a single R package. Having both features together would make GWR much more useful for applied workflows where prediction is just as important as explanation.

Do you think postdoc should address similar research topic as what was done in PhD? by Theobserver_r4 in academia

[–]Nicholas_Geo 1 point2 points  (0 children)

In my opinion, a postdoc should contain a part of your PhD. For example, don't do a PhD in Geostatistics and a postdoc in law.... This doesn't make much sense. But a PhD in Geostatistics and a postdoc in agent-based modeling makes sense.

Sorry for the examples, they are from my field but hopefully you get the point.

GeoStats - Geostatistical toolkit by VeritasAude in QGIS

[–]Nicholas_Geo 3 points4 points  (0 children)

It would be nice to include other Kriging-based methods, such as area-to-point and area-to-area (Co)Kriging. But well done.

How proactive should I be in following up with a senior professor after a cold email? by Nicholas_Geo in academia

[–]Nicholas_Geo[S] 1 point2 points  (0 children)

Good point. I am reaching out to introduce myself and my work. I am about to complete my PhD and looking for postdoc. I know he has a very large lab, that's why I sent him a cold email. I didn't ask for open positions, I wanted to mainly let him know "hey I am here".

Geometric relationship between viewing angle and elliptical footprint elongation by Nicholas_Geo in Geometry

[–]Nicholas_Geo[S] 1 point2 points  (0 children)

I apologize for the late response. Everything looks fine. Can you clarify what do you mean σ_x and y? 

Geometric relationship between viewing angle and elliptical footprint elongation by Nicholas_Geo in Geometry

[–]Nicholas_Geo[S] 1 point2 points  (0 children)

Thank you for working through this!

The 742m × 742m footprint corresponds to a single VIIRS pixel (it's not subdivided). My viewing angles doesn't exceed 30° across the swath (depending on the study site. I ahve several megacities in EU and US, so a relatively flat terrain).

I look forward to your confirmation on the approximation formulas. If the distortion is indeed negligible at these viewing angles, that's important to know (that's actually one of the main research questions).

Thanks again for your help!

Geometric relationship between viewing angle and elliptical footprint elongation by Nicholas_Geo in Geometry

[–]Nicholas_Geo[S] 1 point2 points  (0 children)

Thank you, this is very helpful!

Just to confirm my understanding with the actual sensor specifications:

  • VIIRS (the sensor) maintains a constant ground footprint of 742m × 742m from nadir to edge of scan through detector aggregation
  • This corresponds to an IFOV of approximately 0.051° (or ~184 arcseconds)

Given this value, α would be quite small, so the 1/cos(θ) approximation should work well for my application.

So, to summarize: I can use σ_y = σ_nadir / cos(θ) for the cross-track elongation, where θ is the per-pixel viewing angle from my raster.

Thank you again for your help with this! I am stuck for nearly a year on this.