This is being compiled on ubuntu on a Oracle VirtualBox VM on an intel mac.

The first step is to download a DSM tool chain as described here. https://help.synology.com/developer-guide/compile\_applications/manual.html

As suggested, I untarred it into /usr/local. I have a DS220j which I used to figure out what toolchain was required.

Then, I downloaded ncdu version 1.20. ncdu comes with a configure script and you have to call it pointing to the cross-compile environment, that is with the -host option set to “aarch64-unknown=linux-gnua”. The DSM tool chain adds some compilation tools to /usr/local/aarch64-unknown-linux-gnu/bin/, so configure will need pointers to these tools. CC should be set to the compiler from this directory (aarch64-unknown-linux-gnu-gcc) and LD to the loader (aarch64-unknown-linux-gnu-ld).

The resulting ./configure failed, as the ncurses library was not present in the synology sde. Looking at the NAS itself, we see ncurses libraries present but we don't see the ncurses header files. The ncurses library is present on the NAS and can be used as long as you compile it.

We don't off-hand know the version of the package on the NAS. One option is to write a ncurses application that prints out the version, but instead, I took a short cut to assume that both ncdu and ncurses don't make fundamental changes often, so basically the latest version is fine. I eventually added a –disable-dependency-tracking option to configure due to this shortcut.

On my linux build machine, I installed the libncurses-dev package in the standard locations so I had access to the required header files. However, they need to be in the cross-compilation environment for the compile to work.for, here /usr/local/aarch64-unknown-linux-gnu/sysroot. It's straightforward to copy the header files in the ncurses-dev package from /usr/include to /usr/local/aarch64-unknown-linux-gnu/sysroot/usr/include. For the headers, I just copied them from the nas itself to /usr/local/aarch64-unknown-linux-gnu/sysroot//lib.

Rather than copy one file at a time, I copied everything the package added to the system into the proper directories, headers from the linux system itself and library .so files from the NAS.

At this point, configure and make creates a ncdu executable, which can be transferred to the NAS and used.

My last post was about how observed daylight doesn’t work on a purported flat earth map, as the day and night make unusual shapes which cannot be explained. The way the light really works is explained here.

On the earth, the sun lights up slightly over ½ of the world at one time, leaving slightly less than ½ in darkness. Since light bends in the atmosphere, the light refracts over into the half of the world that is not directly lit by the sun, leaving somewhat more of the planet lit up than in than dark.

One could demonstrate this by determining a position that the sun was directly overhead (the noon point). Then, figure out the positions where at that time the sun was rising or setting. We’d expect that the radius between the noon point and the sunrise/sunset positions would form a circle. Furthermore, there would be an antipode of the noon point and the sunrise/sunset points would also form a circle around those points. You could show this by calculating distances between the points.

If the results show two circles, the earth could not be a flat plane. On a flat plane, the arc that circles around the noon point could not also circle the antipode of that point. Thus, we are trying to generate noon points, the antipode of that point, sunrise and sunset points and distances between them.

This isn’t really about the shape of the earth, but about generating this data with python using two packages, astral to calculate solar positions and geopy to calculate distance. Note that both of these packages rely on the earth being a globe, so it would be no surprise that they behave as expected, but the use here is to give observations about day, night and distances on the earth. If the observations the program makes match reality, the earth must be round. For the earth to be flat, some observations must be disproved.

The python script I wrote for this is in https://github.com/jamesdogrady/sunGleason, called daylightDistance.py.

To find the circles we need to calculate the point at which the sun is most over head on the earth. From there, we can determine the antipode of this point, which would be the center of darkness. The edges of the circles can be calculated by finding sunrise and sunset at various latitudes. Most of the time, some portions of the planet have 24 hour darkness or daylight, so the circle edges must account for this as well.

I’m mis-using astral here rather than a package that calculates the edges directly, so we have to find the points we require by using the astral package for a set of latitude and longitudes. This requires searching for the proper points which makes the program less direct. This will lead to errors as we may not calculate the edges of the circle with absolute precision. This make the exercise less about showing the earth is a globe and more about using astral to make observations to support a globe.

First, we have to find the noon point. We can tell where it is solar noon currently by looking on the equator and getting the time for solar noon, and calculating from that the longitude at which it’s currently noon. This looks like this.

obs_lat=0
obs_long=0
obs=Observer(obs_lat,obs_long);
noon_tm=noon(obs,tm,tzinfo=utc);
dps=15/(60*60)
# calculate the longitude where it is noon currently.
# noon has either passed or is coming, so we can tell where it is.
if ( noon_tm > tm ) :
    # noon is coming.
    noon_time=(noon_tm - tm).seconds
    noon_long=obs_long + noon_time *dps
else :
    noon_time=(tm - noon_tm).seconds
    noon_long=obs_long - noon_time * dps

The noon latitude is between the Tropic of Cancer and the Tropic of Capricorn, and we search within this range to find it.

eq_obs=Observer(0,noon_long);
eq_zenith=zenith(eq_obs,tm);
north_obs= Observer(tropic_cancer,noon_long);
south_obs= Observer(tropic_capricorn,noon_long);
north_zen=zenith(north_obs,tm);
south_zen=zenith(south_obs,tm);

done=False
first=True
north_lat=tropic_cancer
south_lat = tropic_capricorn
while not done :
    # if the zenith is the same at both endpoints the correct value is in the middle.
    if north_zen == south_zen :
        noon_lat = (north_lat + south_lat) /2
        done=True

    # are we close enough to stop?
    diff = abs(abs(north_lat) - abs(south_lat))

    if (not first and diff < precision ) :
        noon_lat = north_lat
        done=True
    first=False;
    if ( north_zen < south_zen ) :
        # between center and south.
        south_lat = ( north_lat + south_lat)/2
        south_obs= Observer(south_lat,noon_long);
        south_zen=zenith(south_obs,tm)
    else :
        north_lat = ( north_lat + south_lat)/2
        north_obs= Observer(north_lat,noon_long);
        north_zen=zenith(north_obs,tm);

We are looking for the lowest zenith and thus the point where the sun is highest in the sky. The point on the opposite side of the earth from this noon point have the opposite latitude. For longitude, we add 180 to western (negative) values and subtract 180 from eastern (positive) values.

To calculate the edges of daylight and night, we write a function to search for the points.

def find_true_value(low,high ,val,tm,fcn) :
    done=False
    while not done :
        ret_bool = False;
        t=abs(high - low)
        # for longitude, if you are more than 180 apart, you are going the long way around.  
        if t > 180 :
            t=360-t
        diff = t/2
        if ( diff < precision  ) :
            return low
        mid = low+diff
        # this could be a latitude but it won't be that big
        if mid > 180 or mid < -180 :
            mid=conv_long(mid);
        (res,v) = fcn(mid,val,tm);
        if v != None and v :
            ret_bool=True
        if res :
            high=mid
        else :
            low=mid

The point we are searching for is between low and high. fcn is a helper function for the search. If it returns True, the point we are looking for is between low and mid. if it returns False, the point we are looking for is between mid and high. This function works for both latitude and longitude searches. If low/high are latitudes, val must be a longitude and fcn must understand which value is being passed in and vice versa.

The helper function that finds the 24 hour sun is shown below.

def twenty_4_hour(lat, long,tm) :
        obs= Observer(lat,long)
        noRise=False
        light=False;
        try :
            rise=sunrise(obs,tm);
            noRise=False
        except ValueError as e :
            noRise=True
            found_24_hour=True
            if "above" in e.args[0] :
                light=True;
            else:
                light=False;
        if ( lat < 0) :
            return( not noRise,light);
        return(noRise,light);

For each trial, we see if there is a 24 hour sun at the given latitude. If there is, we know the latitude we are looking for is south of us in the northern hemisphere and north of us in the southern hemisphere, so we return a different value. For example, the southern light point is found by starting from -90 and going to just north of the antarctic circle (-65)

(south_lat)=find_true_value(-90,-65,noon_long,tm,twenty_4_hour);

We have similar helper functions for sunrise and sunset for latitudes at which the sun does rise and set to find the points where this occurs. Note that while the sun travels at 15 degrees per hour, you cannot calculate sunrise/sunset longitudes because while the earth is rotating on it’s axis, it’s also revolving around the sun, so the longitude of sunset/sunrises varies slightly due to the tilt of the earth. Unless you. account for this, the positions of sunrise/sunset are wrong.

Once we’ve calculated the points where the sun is rising or setting, we can calculate distances. geopy has a geodesic function to calculate distances using great circles accounting for the oblate spheroid shape of the earth. The program also calculates distances assuming a sphere. geodesic takes two points, so we do calculations like this

     radius =geodesic((noon_lat,noon_long),(lat,sunrise_long)).kilometers

In order to confirm the observations, there are check functions to be sure than sunrise, sunset and noon are close to where the program calculates they are. Here is check_sunset

def check_sunset(lat,long,tm) :
    s=" sun is up"
    if debug :
        print("check_sunset",lat,long);
    lat_obs = Observer(lat,long)
    set_time = sunset(lat_obs,tm) 
    if ( set_time > tm) :
        diff = set_time - tm
    else:
        s="sun has already set"
        diff = tm - set_time
    if debug :
        print("check_sunset(",lat,",",long,") ",diff.seconds," different");
    if ( diff.seconds < assert_seconds ) :
        return True;
    return False

assert_seconds and precision define how accurate the search is.

To handle 24 hour sun/darkness, we need to find where the edge is of darkness or light. If there is 24 hour daylight at say 85 ° N and the noon longitude is 120 degrees E, it will be light at the 120 E latitude up to the north pole. It won’t be dark until you get to 85 degrees N at the opposite longitude. We’ve calculated this longitude before, it’s the longitude of the antipode of the noon point. So that’s the edge of the daylight/night circles in the arctic regions.

We calculate all the radius’s for daylight and nighttime and put them in pandas data frame so we can do analysis on the results.

daylightDistance.py -g -s

Time is 09-09-2025 16:47

Noon Point is (5.05,-72.70)

Anti Noon Point is (-5.05,107.30)

value average range std dev

---------------------------- --------- ------- ---------

daylight radius (sphere) 10095.59 59.85 8.56

darkness radius (sphere) 9919.52 59.85 8.56

circumference (great circle) 40030.23 0.00 0.00

daylight_radius (actual) 10099.64 71.37 11.27

darkness radius (actual) 9923.83 71.37 11.71

Here, we see that as expected, there is a rough circle around both the noon point and the anti-noon point. While not all radius’s are the same as measured, they are within a fairly narrow range, 59.85 km of around 40075 km earth circumference . The standard deviation of these errors is also low. Note that the calculated circumference in a great circle model is based on the observed radius and not on the actual circumference so it differs from the accepted value of the circumference. On the oblate spheroid earth, we would expect less circular shapes as the flattening introduces distortion on the circles and we do see this.

With this program, there is an option to show the points which we think of the edges of the circle. We’ll show this at the 2025 winter solstice. (the -l option shows points every 20° ).

python3.13 daylightDistance.py -l 20 -g -t "12-21-2025 9:03" -v

Time is 12-21-2025 15:03

Noon Point is (-23.05,-46.19)

Anti Noon Point is (23.05,133.81)

value average range std dev

------------------------ --------- ------- ---------

daylight_radius (actual) 10108.20 131.56 40.25

darkness radius (actual) 9914.09 131.56 41.25

Radius Data Oblate Spheroid

point distance from noon (km) distance from anti-noon (km)

---------------- ------------------------- ------------------------------

(-40, 66.33) 10141.58 9876.64

(-40, -158.76) 10145.79 9872.42

(-20, 53.79) 10123.83 9904.50

(-20, -146.22) 10129.73 9898.59

(0, 44.64) 10100.77 9931.62

(0, -137.07) 10107.14 9925.24

(20, 35.63) 10074.72 9953.85

(20, -128.06) 10080.26 9948.32

(-65.78, 133.81) 10154.87 9849.06

(67.34, -46.19) 10023.31 9980.63

Note that the program does worse calculating the distances as we move closer to winter. This is because more of the sunlight and darkness is over the somewhat flattened polar regions.

Two options control the accuracy of the calculations. -p specifies how close to a point we need to look. This defaults to .05 and is in degrees. -a will cause the program to delete points for which the difference between sunrise/sunset and the current time is greater than the specified value. The default is 30. Playing with these values doesn’t really impact the results that much. You see a more consistent radius, but not by that much.

The results match our expectations. We see the circles we expect to see. While of course a point opposite the noon point has no meaning on a flat plane, the fact that we can identify a point where darkness forms a curve indicates that this point would be real and have significance. The noon point, sunrise and sunset are all observations that can be made on the earth.

I took a look at the values calculated for the circle around the antipode of the noon point for various times over the course of year. As you might expect, the calculations for a oblate spheroid are within a narrow range, but not that even.

The results for spherical model are quite narrowly defined. Here, outliers are excluded from the histogram, but the counts are not significant in this range.

It might perhaps be possible for daylight on a flat earth to form a circle around an overhead sun at the noon point. It would not be possible for the night to form a circle at the same time as we see here. The edge between daylight and night curves between two points on the earth at the same time, all the while moving over the course of a day and year. The geometry that support this is a globe earth.

The only way out would be to claim that the distances calculated here are not accurate. The problem this creates is that the same calculations are used regularly to measure distances on the planet accurately, for instance, for airline flights. There is not a way to resolve this problem. An attempt to claim distances are different than calculated will inevitably bump up against known distances on the planet.

Here are daylight pictures at the start of each season in 2025.

It’s important to note in those places on earth where there is not 24 hours of day or night, the sun is experienced that same way in all places. It rises in the east, sets towards the west and is the same size throughout the day and throughout the year. In the north during the winter, you see the same sort of sun you see during the summer just farther south in the sky.

Given that all people experience the sun in the same way, the question is why the sun casts a different pattern of light and darkness when it is overhead at different spots in the earth. The point at which the sun is overhead will change from the Tropic of Cancer, to the Tropic of Capricorn over the course of the change of seasons but the daylight pattern changes dramatically from season to season for no physical reason.

Lets take for example the Spring and Fall, when the sun is overhead at the equator. We’d expect the pattern to be similar and it is. We see the light here making basically a straight line through the north pole and illuminating the entire planet below that line. Spring and Fall on this drawing does show one important observation that matches reality. At any point in time, roughly ½ of the surface of the planet is in daylight and ½ is in darkness. Spring and fall are the only time that that’s true on this map.

As the sun moves north from Spring to Summer, towards the Tropic of Cancer, the northern edge becomes a curve instead of a straight line. There’s nothing that can account for this change. if the daylight edge is straight when it is over the equator, how can it be less straight as the sun moves north? Also, the sun becomes less able to light up the south as it goes north. When the sun is overhead at the equator, it can light up half the planet 90 degrees south of the equator. When the sun is overhead at 23.5 degrees N, only part of the planet 90 degrees south of that can be illuminated. For some reason, the summer sun is much less effective at lighting the surface of the planet than it is at other times of the year.

In winter, the situation changes. Suddenly the sun can illuminate virtually the entire surface of the earth, leaving only a small portion in night at any given time. Once again, to accept this map, one would have to explain this property of light.

Of course, the reason for the pseudo-conundrum is that this map is just a projection of the globe earth. At the equinoxes, when the pattern of daylight forms a more or less straight line though a longitude, the projection shows half the earth illuminated with the straight line being that line of longitude, just the edge of where daylight reaches on the globe earth.

For summer and fall, the pattern is explained by distortions on the map. The parts of the earth above the equator occupy less space on the map than in reality and the parts below the equator occupy much more of the space than on the real earth. If you were to measure the length of the 10 degree north lattitude line, the equator and the 10 degrees south latitude line, the 10 degree north and south lines will be roughly equal while the equator will be longer. On the map, the length of each latitude line increases as you go south all the way to end. The deviation from reality increases the farther south you go so the edge of the earth has a circumference that is well above anything measured on an actually existing earth.

The result of this is that shapes shown in the north are too small and shapes drawn in the south are far too large. This creates an illusion that the December solstice sun covers large portions of the earth leaving a modest oval of night, and the June solstice daylight forms an oval shape.

The project allows you to change the projection and we can change it for a point where the sun is roughly overhead at the December solstice, 23.4 S, 45.93 W. (these are estimates based on points examined by the program). The result looks like what you’d expect.

While the shapes of the continents are distorted, you see that daylight forms a circle over the noon point. Daylight forms a circle on the earth. This is expected on a globe and required on a flat earth with an overhead sun. Since this Gleason map doesn’t show daylight as a circle, it cannot be an accurate earth map.

Sometimes, I’ll click on YouTube videos that debunk the flat earth theory. One common map used in this theory is the so called Gleason map, from the late 1800s which looks like this.

The map has many problems, but its youtube plausible since you can travel west or east around the map without falling off the edge, unlike other maps. To fall off the edge, you have to travel to interior Antartica which is more possible now, but was out of reach when the map was published. Sometimes, when showing this map, someone will show how the sunlight works on this map with a flashlight and in fact, it doesn’t. I wanted to show that and cartopy in python lets you do that, which is what the project is about.

This map is a Azimuthal Equidistant projection of the globe with the center at the north pole. This is one of the projections offered by cartopy.crs, so we can show a similar map very easily.

import matplotlib.pyplot as plt
import cartopy.crs as ccrs
import cartopy.feature as cfeature

proj=ccrs.AzimuthalEquidistant(central_latitude=90, central_longitude=-90);
ax = plt.axes(projection=proj)
ax.set_global()
ax.coastlines()
ax.gridlines(draw_labels=True, linewidth=0.5, color='gray', alpha=0.5)
ax.add_feature(cfeature.BORDERS, linewidth=0.5)
ax.add_feature(cfeature.LAND, facecolor='lightgray')
ax.add_feature(cfeature.OCEAN, facecolor='lightblue')

# Chicago IL
lat=41.8781
long=-87.6298
ax.plot(long,lat,'o',markersize=10,transform=ccrs.PlateCarree(),color='red');
plt.show()

Central latitude is 90 for the North Pole. We use the central longitude of 90 W to replicate the engraving. Western longitudes and southern latitudes are negative. The location of Chicago is plotted on the map with too large of a circle (The ‘o’ in ax.plot). The result looks like this.

To show the daylight, we’ll use the astral package for python. This package allows you to calculate sunrise and sunset based on latitude and longitude. We’ll mark each point with a different color depending on whether it’s day or night. There are two approaches here. I chose to use astral to calculate whether it’s day or night in individual locations. It’s probably better to calculate the lines that separate day and night and draw polygons to show this. I think using sunrise/sunset is more verifiable since the times are widely available, for instance in local newspapers.

Note that north of the Arctic Circle and south of the Antarctic Circle, 24 hour night and day is possible. This causes the astral.sun.sunrise and astral.sun.sunset to throw an exception. The text of the exception tells you whether it’s night or day. Essentially, the code for the daylight check looks like this.

import pytz
utc= pytz.UTC
from astral import Observer
from astral.sun import sunrise,sunset
from astral.sun import zenith
from shapely.geometry import Point 
# p is a Point, date is the date
def is_day(p,date) :
    obs = Observer(p.y,p.x)
    try :
        rise_time = sunrise(obs,date).replace(tzinfo=utc)
        set_time = sunset(obs,date).replace(tzinfo=utc)
    except  ValueError as e:
        # 24 hour sun
        if "above" in e.text() :
            return True
        else :
            # 24 hour night.
            return False    
    if ( rise_time > set_time ) :
        # the period of light crosses a day boundary.  the sun will be up between midnight
        # and set_time, down between set_time and rise_time and up after rise_time.
        if ( date < set_time ) :
            return True
        if ( date >= rise_time ) :
            return True;
        return False
    # here, rise_time < set_time
    if ( date >= rise_time and date < set_time) :
        return True;
    else :
        return False;

What remains now is just to plot points. Here, we are using circles ( parameter “o”). The size of the circle is marker_size and it’s transparency is alpha which is point_alpha. These are configurable in the actually application.

if ( is_day(p,date ) :
    color="yellow"
else :
    color="black"
ax.plot(p.x,p.y,'o', markersize=marker_size, transform=ccrs.PlateCarree(),color=color,alpha=point_alpha)

You can add a title to the plot using

ax.set_title(date.strftime("%m/%d/%Y %H:%M" + " UTC"));

We may want to add text to the bottom of the plot as well, but the coordinates make this tricky in this projection system. This puts text off to the side on the button away from the labels. This isn’t in the github.

lon_min, lon_max, lat_min, lat_max = ax.get_extent()
ax.text( (lat_max-lat_min)/2,lon_min-30, "some text, ha='left', fontsize=12,transform=self.proj)

The defaults here are an alpha of .01, a markersize of 1 and plotting points every degree. For the summer solstice, June 20, 2025 at 9:41 PM CDT, you get a picture like this.

The Orange dot here is the point with the lowest zenith amount the points looked at. This is roughly where the sun is overhead.

To check the visualization, you can look at other web visualizations, for instance, that of timeanddate.com for the same time which looks like this:

If one looks at the github, there’s more going on that what’s described here. The whole application is a Python QT application. I don’t cover that because it’s just how you’d wrap matplotlib into a python qt application which others cover already and what I want to cover is integrating daylight into a Gleason map. Also, some of the glue here is from ChatGPT which to be fair also pointed me toward cartopy when I had started with geopandas.

There is a preferences dialog also, which is also basically also from ChatGPT. You can specify the size and transparency of how the day or night markers are shown. You can also update the latitude and longitude the project is centered on. As you do this, you move off of the Gleason map, but visualizing the projection centered on where the sun is overhead is useful. I also allow you to specify a distance between latitudes and longitudes that are plotted. This allows you to draw pictures much more quickly, but the visualization isn’t as good. The defaults don’t show the individual points but spreading out the interval makes the points show up, e..g.

uses 5 degrees apart and plot much fewer points more quickly, but the points show up and more of the underlying plot is exposed between the points and it’s harder to see the shape daylight or nighttime make on the map..

This is not a fully fleshed out application. Much more could be done, but this has a pretty limited utility. The earth is not flat, so this is not a map of the earth and the drawings the application makes of daylight are not real so it’s unclear beyond what it already does how much more time is useful to spend on this.

In a connected world, of course, you can publish what you write. This doesn’t seem to be a necessary step for writing. The value of publishing seems limited as well. The world is unlikely to need another discussion of what variables are in programming languages and I’m unlikely to be the person that could fill that need anyway. On the other hand, maybe there is something I could contribute and with search engines, maybe people can find it. On the off-chance you read this, as long as we both limit our expectations, we should be ok.

This is likely to be annoying because I’m at the point after a long software engineering career where what I want to learn about is eclectic and not necessarily systematic.

I’m interested in AI, machine learning and data, even though up to now, that hasn’t been any particular focus of my career, so maybe that will show up here more than other stuff, but we’ll find out.

Generative AI is hot right now, but perhaps is better and more sarcastically described as imitative AI. That leads to the title of this blog.

Once in my career, I decided to write some data gathering scripts I needed in Python, a language I did not know. I watched a youtube video and decided to get to it. Previously, I learned languages by reading books, which results in a pretty good end-to-end view of the language, but this time, I decided to just use google. Because of this, I was asking a lot of dumb Python questions, which normally resulted in going to stackoverflow.com and getting both the answer and comments about reading the manual before you ask trivial questions.

Now, since search engines like to preempt you actually going to a website with the answer, it summarizes the answer for you. It does this without judgement, so you can ask as silly a question as you like and it’s unlikely to say that’s silly. It will also give you a code segment on the concept. This is great for putting together scripts, but perhaps something gets lost if you abstract key ideas out of the concept. You no longer have to put up with being shamed for asking dumb questions, but maybe the shame encouraged a deeper dive. I guess we’ll find out.