Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Allow DEMs with projections that are not north-up #544

Open
nwagenbrenner opened this issue Jan 17, 2025 · 0 comments
Open

Allow DEMs with projections that are not north-up #544

nwagenbrenner opened this issue Jan 17, 2025 · 0 comments
Assignees
@nwagenbrenner @latwood
Labels
enhancement priority:high
Milestone
3.12.0

Comments

@nwagenbrenner
Copy link
Member

To do this, one idea is:

  1. Read in the DEM in it's native projection.
  2. Grab the DEM center point and reproject that point to EPSG 4326 (lat/lon).
  3. Make another lat/lon point some short distance straight north of the lat/lon point generated in 2.
  4. Reproject those two lat/lon points back to the projection of the DEM.
  5. Now you have two sets of points, one in lat/lon coordinates which forms a straight line aligned with north and another set in the DEM projection coordinates which forms a line that is some angle off of north.
  6. Compute the angle between those two lines and this is the angle by which the input wind direction needs to be adjusted.
  7. Adjust the input wind direction by the angle calculated in 6 and proceed with the simulation.

We think this is all that would need to be done, but this work should be double checked during implementation.
@nwagenbrenner nwagenbrenner added this to the 3.12.0 milestone Jan 17, 2025
nwagenbrenner added a commit that referenced this issue Jan 18, 2025
@nwagenbrenner
initial work for #544
5b39c6d
latwood added a commit that referenced this issue Feb 11, 2025
@latwood
correct angleFromNorth calculation formula, for issue #544
398a9d8
latwood added a commit that referenced this issue Feb 11, 2025
@latwood
enable angleFromNorth calculation for momentum solver domain average …
8240174 
…runs. Also caught a spot in the original mass solver domain average run implementation that seemed to need corrected

seems like we will need to take extra care to check each instance of input.inputDirection in the code, to determine whether angleFromNorth needs to be added or not, or setup a second direction variable to be differentiated from the input.inputDirection value

for issue #544
latwood added a commit that referenced this issue Feb 11, 2025
@latwood
extended the old ascii2png kml bounds fix to vector kml output
357ab5e 
the original fix was to deal with png layers not quite extending to the right spots/bounds in the domain. The fix was necessary this time because negative input min and max bounds would result in vectors not being drawn in google earth. The locations of the vectors and values would pop up, but no arrows would be drawn.

The problem this time turned out to be because the bounds in the overall LatLonAltBox of the kmz would get reversed. The fix worked because it keeps track of all four points of the bounding box, rather than just two. I suspect that the fix will also be more robust for when we allow more types of projections in WindNinja, as the bounding box can take on varying orientations during reprojections.

The original fix is described in e765438 and 395c93e. This fix should come in real handy for issue #544
latwood added a commit that referenced this issue Feb 26, 2025
@latwood
made the angleFromNortha signed value, for issue #544
8a26e76 
This was required to get the angle correction done right for utm projections going from east to west, the original calculation turned out to be good for utm projections going from west to east. Basically, when reprojecting, the angle corrector needed to be added for datasets that rotate counter-clockwise, and subtracted for datasets that rotate clockwise.
latwood added a commit that referenced this issue Mar 3, 2025
@latwood
added config option to override the angleFromNorth calculation, for d…
5d1910f 
…ebugging purposes, as normal runs are now also affected/altered. For issue #544
latwood added a commit that referenced this issue Mar 3, 2025
@latwood
added angleFromNorth calculation to wxModelInitialization and gridded…
b51965f 
…Initialization

Tested and should be correct, though I had to take extra care to not just adjust the initialization grids set by setInitializationGrids() or the equivalent interpolateWxGridsToNinjaGrids(), but I also had to watch out for use of the initialization grids in setting the input.inputDirection value in each and every ninjaFoamInitializeFields() function.

For issue #544
latwood added a commit that referenced this issue Mar 4, 2025
@latwood
added/updated angleFromNorth calculation for pointInitialization runs
385c48a 
tested and should be correct, the idea is to update the raw loop values once before all the looping, then they just adjust as normal as needed

for issue #544
latwood added a commit that referenced this issue Mar 4, 2025
@latwood
added wrap around between 0 and 360 functionality to each angleFromNo…
f1eadf2 
…rth calculation. For issue #544
latwood added a commit that referenced this issue Mar 6, 2025
@latwood
added TODO for wxModelInitialization, add projection rotation from no…
d77f18a 
…rth for 3d data. For issue #544
latwood added a commit that referenced this issue Mar 6, 2025
@latwood
final cleanup of angleFromNorth calculation code, for issue #544
e095501
latwood added a commit that referenced this issue Mar 7, 2025
@latwood
fixed error in angleFromNorth adjustment for output kmz. For issue #544
b4526a8 
looks like kmz was the only output that needed such an adjustment. The raw values printed to the kmz needed adjusted back by angleFromNorth, the vector drawing was still good.

though it should be noted, that this does mean a slight difference of 2 degrees in drawn vectors compared to the original, as we weren't accounting for angleFromNorth for all our past utm cases. A second check to show that this ~2 degree angleFromNorth of utm vs lat/lon adjustment is correct, is to plot the vectors in lat/lon using the lat/lon angle, those plotted vectors come out the same as our current plotted vectors in direction and angle, where our current method is to plot the vectors in utm using the utm angle and projecting the vectors to lat/lon.
latwood added a commit that referenced this issue Mar 7, 2025
@latwood
changing CPLConfigOption OVERRIDE_ANGLE_FROM_NORTH_CALCULATION to be …
e3b0aea 
…DISABLE_ANGLE_FROM_NORTH_CALCULATION for clarity, for issue #544
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@nwagenbrenner nwagenbrenner

@latwood latwood

Labels
enhancement priority:high
Projects
None yet
Milestone
3.12.0
Development

No branches or pull requests
2 participants
@nwagenbrenner @latwood