Grdtrack vertical profile along track

I have a track between points A and B (black line) surrounded by a corridor 5 NM right & left of said track (reddish box).

What I need to extract is a vertical profile of the highest terrain in the corridor between A and B (crude representation in lower graphic) with an 100m increment.


I’m pretty sure this can be accomplished with grdtrack but my experimentation led nowhere so far.

Do you have a pointer for me where to start my research?

  1. New grdclip lets you clip the grid of all rectangle outside nodes.

  2. find the maximum and it’s coordinates with grdinfo

  3. find new A & B that pass trough the point found in 2.

Hi @Joaquim, thank you for chiming in. I’m not sure I understand your approach. Would you mind elaborating it a bit further?

My mental picture is to compress the reddish area onto the black line keeping the highest values. For example the red circled peaks which are higher than the terrain under the black track will be the values reported for the mid-section of the track.

While it was not designed for this specific case, see if grdtrack -F with -C selecting a dense set of cross profile of width 5 nm will return the max value per crossection and that would be your max hight profile.

Down the road, allowing -S instead of -F and pass a flag that says collapse the found values onto the profile might be a useful option and would do what you want as well.

Now I’m not sure I understand what you want. Is it a profile parallel to AB but that passes through the highest point (my, non-obvious-to-implement recipe). Or a profile along AB but made off the highest point across the AB line and inside the red region?

Good morning @pwessel, I’ll read into grdtrack (haven’t used it yet) and give it a try. I assume a spacing smaller than the DEM resolution will be necessary?

I tried to reply but eventually removed the post because I don’t have the scripts anymore, but a long time ago, in a far far galaxy, I did something like this (which is I guess what you want) :

It involved two external scripts :

  • one to create the box (from UTM to geo)
  • one to create multiple tracks within the rectangle
  • the plottings

Sorry to not help more, but if it can better illustrate your point :slight_smile:
(and I now realize that the transparency is hideous, you’re supposed to see light grey tracks)

Hi @Joaquim your second option is what I’m after. My apologies for my not explaining it clearly enough.

My use case is a departure corridor from an airport. As aircraft and mountains don’t mix very well there is an assessment wether a certain routing is safe to fly. You assume an aircraft has to maintain a certain climb gradient from the runway end. Lets say 3.9%. As you need some allowance in horizontal navigation accuracy it is assumed that the 3.9% gradient is the lower limit of a 10 NM wide corridor. I’m trying to figure out how close the terrain actually gets to that corridor.

When you said it was option 2, I guessed the rest. I guess also that grdtrack -C in a simple Julia script would do the job.

(… nearly a month later …).

So my old code involved C and fortran.
I ended up needing it today. Surely enough, like Joaquim suggested, I did it with Matlab + TRACK :

  1. I generated a set of coordinates with Matlab :
 writematrix([x(:) yfit(:)+linspace(-std(yfit),std(yfit),100)],'tracks.txt')

First column contains the x-coordinates
All others are Ys shifted from -1std to +1std around a mean state defined by yfit
(Thus, the file is 101 columns wide)

  1. I generated tracks with a loop :
    for col in {1..100};
    do 
    gmt grdtrack tracks.txt -i0,${col} -Ggridded_file.nc  > profile_${col}.txt -Vq
    done

This give me 100 individual tracks (1 per text-file), represented by the rectangles (upper panel) … which I later average to give the plot in the bottom panel (in your case this panel would show only the UPPER of each track) :

Ah, neat example @PlanetGus! Thank you for sharing. I ran into a problem with tracks containing turns:

How do I catch the red segments? No clever idea so far.

If the overlap (concave side) doesn’t bother you, why not extending the rectangle length to cover the convexe side too?

Edit : if you’re not too keen to get what lies beyond the red triangle, you can “mask” the region of interest beforehand.

Edit2: maybe the -E option with “radius” parameter can help instead for the turns if you know their coordinates …

Wouldn’t the extension depend on the degree of track change between two points?

I can live with the overlap on the concave side. Ideally the bisecting angle (yellow line in image below) would control the segments.

For clarification: An extension from the first segment up to the bisecting angle and the second segment back to the bisection angle would cover the red segment for the price of a larger overlap. This would be a more conservative approach but acceptable.

But still no idea how to do this in GMT :thinking:

I still think this involves an enhancement to grdtrack’s -F option such as another modifier that returns max or min height in the swath.

Good morning @pwessel the enhanced grdtrack -F option surely would be the deluxe solution. I tried to get to my goal without incurring even more workload on you and your fellow devs. I feel a bit bad for all my feature requests.