Open Frencil opened 9 years ago
Hi Frencil,
I just adding the eclipse path and shadow to Flowx, my Android weather app (I hope you have an Android). I found your path data and am using it - thanks very much.
I was just comparing the ellipse from your data to the recent NASA data and found they were very different, especially when the shadow hits Oregon. Is the difference between an ellipse and Besselian elements this big?
I'm going to compare my math using sun altitude to your code tonight but thought I'd get in touch first.
BTW, feel free to email (via the Google Play Flowx page or app) and I can send you an alpha version which has your data in it.
Cheers, Duane.
The difference between my approximated ellipse width and the actual shape of the umbral shadow can indeed be quite large... consider that at the ends of most tracks (where the eclipsed sun is rising or setting) the shadow isn't even an ellipse but more of a bell shape that bleeds into the night side of Earth.
To accurately draw the shape of the shadow the Besselian elements provide the raw numbers needed to construct a three dimensional model of the umbral and penumbral cones. One can then calculate arbitrarily many intersection points between those cones and the surface of the Earth to construct the exact shape of the shadow at any point during the event.
This is approach is very different from my current approach of scraping pre-generated values to construct paths. These tables (originally generated using Besselian elements) only provide north/south limits for the track along with a few other pieces of information, but nothing to inform the shape of the shadow at any given point. Using these tables that's entirely up to me to figure out.
You can see my (admittedly simplistic) approximation of the semi-major axis for the ellipse here. Basically I make it half the width of the path at that point. This makes the ellipse too skinny for big lengthy events like the one happening this August, but makes it just the right amount of skinny for events that get into high latitudes.
I have a lengthier write-up on this problem here. I still plan to build a proof-of-concept that translates Besselian elements into a useful 3D model that can then be translated into CZML for display on EclipseTracks, but that's a big project that likely won't see much attention before this August's eclipse.
Thanks Frencil.
I started scraping the path data too and then I found your czml files with the rotation, semi-major and semi-minor axes, which is what I wanted.
I did read your "lengthier write-up" but was surprised by the margin of error.
Thanks for the explanation of the simplistic approximation. It's good to know it's different to the approach I was pondering at 3 am this morning, and I'm still not sure if it's correct or it'll work. Given the center, north/south limits, the altitude (angle of the cutting plane on a cone) and the azimuth (rotation of the ellipse), I was going to calculate ellipse shape and scale it until it touched the north and south limits. Essentially, the scaling is changing the angle of the cone or the height of the cutting plane of a cone. If I have time after the release of the solution below, I'll try it out.
Last night I got the kml data from the super accurate NASA eclipse shadow shapes and fitted an ellipse to these. It did pretty well except for the extreme ends. So I'll try and add these ellipsis today. Happy to share the results if you wish.
Cheers, Duane.
@duanemalcolm could you share the source of NASA KML data? I'd be interested to see if they've generated it to the same degree for past and future eclipse events. If it's a better stand-in for ingest than the NASA eclipse tables I'm currently using that could be an easier approach (i.e. still scraping pre-generated values instead of building my own model from the base elements).
Otherwise, I do recall playing a bit with altitude/azimuth to try to get the semi-major axis but yeah, that same problem creeps back in where the shadow just isn't always an ellipse. However in lieu of full modeling it may be worth a second look at that. I'd be interested in seeing how you use those values to come up with your shadows, if you get a working prototype there.
Here is the gist
You can download the low-res KML files from here: https://svs.gsfc.nasa.gov/4518
I found a bug and now they fit quite well apart from the extremes.
Incidentally, changing "w_umbra17" to "umbra_17", because it shows the irregular shape.
I think the approach I suggest will be quick to test and add to your tracker.
I have a json file of the major/minor axes (in cartographic degrees) and rotations at 2m intervals. It's not super pretty but good enough. How is the best way to get a file to you. You'll need to convert the major/minor's into meters and convert to czml but it's pretty straightforward.
@duanemalcolm thanks for this... unfortunately I'm not sure it would be useful to convert the KML file for this upcoming eclipse event for this project. EclipseTracks is intended to show arbitrarily many past and future eclipses, and currently features just over 100 years worth of eclipse events. The KML available at the link you provided looks like it may make for a more accurate track for the 2017-08-21 event but that leaves all the other events unchanged.
The general solution I'm looking for is one that I can run against any eclipse event and generate a valid CZML file. This is where I end up always coming back to the Besselian elements... it's likely the KML linked above was originally generated using Besselian elements for the August 2107 event. From the NASA eclipse site I can get Besselian elements for any eclipse event dating back and forward for many centuries, so really I need to build the pipeline that can convert an arbitrary set of Besselian elements into a valid CZML track.
I may yet look to the work in the gist you provided, though, to at least generate better ellipse shadows for the current tracks in the current pipeline, seeing as I do get altitude and azimuth data from the track tables.
@Frencil The gist I sent only fits an ellipse to the KML data. I have the results of that as a easy to read json file. I agree it's not general for all events but it does improve the shape a lot and may be useful for just this event.
I agree that using the Besselian elements if the way to go but it indeed a big job.
Besselian elements are available on all NASA eclipse pages (example). Using these data (as opposed to surface-level derived track data) will allow for more accurate umbral shadow tracing, more accurate limit lines with arbitrarily many points, penumbral shadow modeling, etc.
This is a BIG task as modeling Besselian elements within a WGS-84 ellipsoid model of the earth is much more advanced Python and CesiumJS.