I have two segments: the first is defined as a starting point and an azimuth, and the second is two points. I work with the WGS84 datum. I need to find where the two lines intersect. My work area is fairly small so I know that my segments will probably be within a 25NM radius. So what I am doing now is extending each line geodesically by 25NM. The first segment I have a point, an azimuth, and a distance so I can create that line no problem. The second segment I can find the azimuth between the two points and then do the same thing, namely extend the line to 25NM. I am 99.9% guaranteed that these two lines will intersect. I can then use a spatial function to get me that intersection.
My question: do you think this approach (given my assumptions) is a less taxing method that the guessing algorithm you mentioned?
~AGP
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You don't give enough details of your proposed method for me to give a
sensible answer. I think you are proposing to do the intersection
calculation in some projected coordinate system. This has the issues:
the choice of projection will need to be tailored to your problem;
you'll need to account for meridian convergence in applying the azimuth;
you'd like some measure of the error.
These all levy some "tax" on you, the user. The method I propose uses a
special projection (ellipsoidal gnomonic) which can be applied anywhere
on the globe and where through iteration the error can be reduced to
round-off.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I already have two very densified geodesic lines that I drawn on my map. The map is displaying data in WGS84. The lines have a starting point, an initial azimuth, and are length 25NM. I chose 25NM since I am fairly sure that these lines will intersect once within that range.
I can clearly see where they intersect so what I am doing is using an ArcGIS function to determine that intersection point. This works only because my lines are geodesic densified. So my thought was that compared to your idea to get that exact intersection point by iteration I wonder if it has more or less overhead.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I assume by "overhead" you mean some measure of the computational cost.
Probably either approach will be blindingly fast; you should check this
yourself. However your approach entails a start up cost of producing
the densified geodesics and transforming them to a projected coordinate
system. So if you were actually computing millions of such
intersections, these costs would outweigh the approach using the
gnomonic projection.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for the info. I have maybe 2 or 3 of these intersections to do in one process so I dont think it will affect me much. I was just pondering about the difference in approaches. Many thanks. I have another similar question but will post in its own thread.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Doing a little research and came across this post https://sourceforge.net/p/geographiclib/discussion/1026621/thread/21aaff9f/. My problem is similar but wanted to get your opinion.
I have two segments: the first is defined as a starting point and an azimuth, and the second is two points. I work with the WGS84 datum. I need to find where the two lines intersect. My work area is fairly small so I know that my segments will probably be within a 25NM radius. So what I am doing now is extending each line geodesically by 25NM. The first segment I have a point, an azimuth, and a distance so I can create that line no problem. The second segment I can find the azimuth between the two points and then do the same thing, namely extend the line to 25NM. I am 99.9% guaranteed that these two lines will intersect. I can then use a spatial function to get me that intersection.
My question: do you think this approach (given my assumptions) is a less taxing method that the guessing algorithm you mentioned?
~AGP
You don't give enough details of your proposed method for me to give a
sensible answer. I think you are proposing to do the intersection
calculation in some projected coordinate system. This has the issues:
These all levy some "tax" on you, the user. The method I propose uses a
special projection (ellipsoidal gnomonic) which can be applied anywhere
on the globe and where through iteration the error can be reduced to
round-off.
I already have two very densified geodesic lines that I drawn on my map. The map is displaying data in WGS84. The lines have a starting point, an initial azimuth, and are length 25NM. I chose 25NM since I am fairly sure that these lines will intersect once within that range.
I can clearly see where they intersect so what I am doing is using an ArcGIS function to determine that intersection point. This works only because my lines are geodesic densified. So my thought was that compared to your idea to get that exact intersection point by iteration I wonder if it has more or less overhead.
I assume by "overhead" you mean some measure of the computational cost.
Probably either approach will be blindingly fast; you should check this
yourself. However your approach entails a start up cost of producing
the densified geodesics and transforming them to a projected coordinate
system. So if you were actually computing millions of such
intersections, these costs would outweigh the approach using the
gnomonic projection.
Thanks for the info. I have maybe 2 or 3 of these intersections to do in one process so I dont think it will affect me much. I was just pondering about the difference in approaches. Many thanks. I have another similar question but will post in its own thread.