tlohde

six months in a can

tlohde — Wed, 05 Aug 2026 01:43:00 GMT

Like many projects, this one was abandonned for a while.

But it’s (mostly) done now.

solarigraphy

Solarigraphy is the photographic practice of using a pinhole camera^[1] to capture an image of the sun’s path over days-weeks-months-years. Typically it uses regular B&W photo paper^[2] for capturing the image. And processing is gloriously simple: scan the image, invert it left-to-right, and invert the colours. No red-light or chemistry required.

I’ve had a handful of successful attempts, and just as many unsuccessful ones.^[3] The unsuccessful, along with my impatience at waiting six months, motivated me to write some wobbly code to simulate these.

To model a solarigraph we need (a) coordinates and (b) dates. From those we can generate the sun’s path; get hold of some whether data; determine what the horizon looks like. Then cobble them together into a single plot.

Onwards.

the sun’s path

Every day the sun draws a smooth curve across the sky that a well-placed solarigraph is primed to capture. First, a brief refresher on what the sun does…

In the northern hemisphere, at some point in March and at another point in September, the sun rises in the East, and gradually climbs to its zenith^[4] while moving round towards the South, after which it descends and moves to the West, before then falling behind horizon at sunset (Fig 0).

Fig 0: Solar paths for the summer (dot-dash) and winter (dotted) solstices, along with the spring (and autumn, though it's not been labelled as such) equinox (solid), as seen in Edinburgh, UK (55.96°N 3.12°W)

In summer:

sunrise is north of east
the zenith is a bit higher in the sky
sunset is north of west
this takes longer, and so the days are longer

In winter:

sunrise is south of east
the zenith is lower, i.e. the sun never gets too far above the horizon
sunset is south of west
this shorter path doesn’t take so long, and the days are short and miserable

Just how high, and how north of west, very much depends on one’s latitude.

Another thing that depends on one’s latitude and longitude, is what the horizon looks like…

the horizon

At sea, or in the Netherlands, the horizon appears to be a straight line. In the heart of the Dolomites or in a dense urban area, the horizon - that line where the sky stops and land and buildings and trees start - is not straight (Fig 1).

Fig 1: Horizons in London (top); Isortuarsuup Sermia, Greenland (middle) and Tarawa, Kiribati (bottom). All plots to same scale. Elevation data: for Greenland and Kiribati - Copernicus WorldDEM-90 © DLR e.V. 2010-2014 and © Airbus Defence and Space GmbH 2014-2018 provided under COPERNICUS by the European Union and ESA; London - LIDAR Composite Digital Surface Model (DSM) - 2m by the Environment Agency. Contains public sector information licensed under the Open Government Licence v3.0.

Sometimes, as I’m sure you’ve seen, the sun is very much above the horizon in the sense that it is daytime, but you also can’t see it, it is below your own personal horizon. Or in the case of a distant mountain, the sun is above the nautical horizon, but below the topographic horizon.

Again, a well placed solarigraph can handle this. And so must a simulated one.

Another thing that influences whether or not one can see the sun…is the weather.

the weather

Because this is a realistic^[5] simulation, it relies on weather observations not forecasts. Open-Meteo provide a historical weather API,^[6] which can provide hourly measurements of total cloud cover (as a fraction between 0 and 1) from 1940-yesterday over a 0.25° grid. And, in the spirit of choosing-the-path-of-least-resistance, we’ll use the cloud cover fraction to vary the opacity of the sun paths (Fig 2).

Fig 2: Cloud cover (top) and the sun's path (bottom) over Longyearbyen, Svalbard on on 21st April 2026. Dots in the bottom panel are spaced at 30 minute intervals, cloud cover observations (top panel) are hourly. The opacity/transparency of the sun path markers are linearly interpolated from the nearest (in time) cloud cover observations. Also, note how at this latitude and time of year, the sun does not set. Weather data by Open-Meteo.com CC-BY 4.0

projecting

The above figures have all plotted both solar elevation, $\theta$ , and solar azimuth, $\phi$ , in degrees on a linear scale, from North all the way back round to North. But, what goes on inside a, cylindrical with radius $R$ ,^[7] pinhole camera isn’t linear. So we need to map solar azimuth and elevation to paper-inside-the-camera coordinates.^[8]

Left-to-right is reasonably straightforward, although this took me longer than I care to admit to wrap my head around.

$x = 2 R (\phi - 180^{\circ})$

This is a linear relationship.

For a pinhole camera facing due south (180°, $\pi$ ) only light originating from the east (90°, $\frac{\pi}{2}$ ) round to the west (270°, $\frac{3\pi}{2}$ ) are theoretically capable of entering the camera. The length of paper inside the camera is $2 \pi R$ .

The above equations maps east to $-\pi$ , and west to $\pi$ , for a total span of $2 \pi R$ . In reality, however, a field of view of ~150° is more reasonable. Additionally, a bit of modular arithmetic allows us to point the pinhole in whatever direction, $\gamma$ , we fancy

$\phi_{shift} = (\phi - \gamma + 180^{\circ}) \text{ mod } 360^{\circ}$

Up-and-down is a bit more involved, since the horizontal component, $y_h$ , of the distance from the pinhole to the paper depends on the azimuth

$y_h = 2 R \cos(180^{\circ} - \phi_{shift})$

and the resulting vertical distance from the pinhole, $y$ , is a function of both elevation and azimuth

$\begin{aligned} y &= y_h \tan(\theta)\\ &= 2 R \cos(180^{\circ} - \phi_{shift}) \tan(\theta) \end{aligned}$

This projection process gives rise to a few, let’s call them, features (Fig 3). Irrespective of how far beyond the camera’s azimuth range sunrise/set actually is, the projected image gives the impression of a sunrise/set at the edges of this range. This is because at these extremes $y_{h} = 0$ , and so, regardless of the solar elevation, $\theta$ , the $y$ in paper-coordinates goes to zero. This gives the apperance of solar paths at different times of year converging to a point.

Another quirk, is that terrain is more subdued — less dramatic, especially away from the centre. In Fig 3 this can be seen in the two peaks in the south-west that are at approximately the same elevation angle (the more western one is slightly lower) in the unprojected image, but once projected the more western one is markedly lower, and less peak-y.

This is a problem with $\tan$ . And it is particularly evident at tropical latitudes where solar elevations can sneak up to 90°,^[9] and $\tan (90^{\circ})$ is kind of undefined. So, in these simulated solarigraphs there is a need to clip the elevations to something sensible, like 76°, or $\arctan(4)$ .^[10]

Fig 3: An unprojected (left) solarigraph showing solar paths over Semisopochnoi Island (51.95 N°, 179.62 E°) on the summer solstice, autumn equinox and winter solstice in 2025, and how it apperas once projected (right). Note the reduced field-of-view (90°–270°) in the projected scene, which corresponds to the unshaded area on the left.

styling

Firstly, move the azimuth axis and the cardinal^[11] points the top. Secondly, borrow the colours for land, sky and sun from the small handful of real solarigraphs that I’ve made.^[12] And tah-dah, you can now pick your theme and see the output in Fig 4.

bluepink midnight brown

Fig 4: A styled solarigraph looking south-ish (195°) over Sandvinvatnet from Odda, Norway winter 2025-26. The peak to the SW is Jordalsnuten (1043 m), from this vantage we can't quite see the summit. And it looks like it was pretty cloudy in February. Weather data by Open-Meteo.com CC-BY 4.0; Elevation data from Copernicus WorldDEM-90 © DLR e.V. 2010-2014 and © Airbus Defence and Space GmbH 2014-2018 provided under COPERNICUS by the European Union and ESA

Oh, and, add some credits for the data sources and me^[13], and perhaps a title with the coordinates and time range being shown.

bundling

cli

At first I thought I’d bundle my code up in such a way that someone could use pipx to install the a little cli. I used typer for this. And well, that is a thing that can be done…

installation

ensure python3.14 or greater is installed. See python installation instructions
check pipx is installed: Pipx installation guide
to install solarigraph: pipx install --python python3.14 git+https://codeberg.org/tlohde/solarigraphy.git

solarigraph is now installed.

usage

Run with the following command: solarigraph make. See solarigraph make --help for a full list of arguments and options. Do not be scared of all the parameters, I have tried to give most of them sensible defaults. For example…

solarigraph make 63.83034 -50.06830 2026-04-01 2026-05-30 --facing 90

will output a file named something like sgraph_63.83-50.06.png which should give you a glimpse into early spring at Isortuarsuup Sermia.

api

Now we’re cooking. It was reasonably straightforward to set up a fastAPI, and so if you don’t feel like downloading it yourself — no bother.

The fiddly thing, for me at least, was the requisite javascript for the below.

Will this work in every instance? Probably not. Norwegian fjords tend to look pretty good. I think there are some bugs in the tropics. Something to do with how I choose the axes limits. Sometimes the bottom edge of the horizon is a bit not quite right too.

There is some validation here:

latitude and longitude should be, valid, y’know.
start date must be after 1st Jan 1940
start date should be before the end date
end date should be after the start date, but not more than 365 days
end date should be yesterday or before^[14]
facing should be a number. Between 0 and 360.
radius shouldn’t really be bigger than 50.

Click a point on the map; select some dates,^[15] and which way you’re looking^[16]; and how far you want to search for the horizon^[17]

Right click. Save image as. Bingo.

conclusion?

It’s worth saying that, as usual Darling Reader, this exercise was more^[18] for me. If you enjoyed some of it—any of it—I am thrilled. Truly. But it was mainly for me to play and learn some stuff.

And I played and I learnt some stuff.

Is it perfect. Nope. Are there a bucket-load of edge-cases that bork the whole enterprise. Yep.

And post.

footnotes

a drinks can is a popular choice ↩︎
the sort used to make B&W prints in a dark room ↩︎
for reasons unknown, or some busy-body taking it off the lamppost-or-whatever I lashed it to ↩︎
it’s highest point in the sky on a given day ↩︎
whatever that means ↩︎
using ERA5 reanalysis data ↩︎
let $R=1$ for convenience, y’know ↩︎
and start working in radians ↩︎
there’s a cool name for it: Lāhainā Noon ↩︎
no reason other than I tried a few values, and across a few latitudes and this seemed good enough ↩︎
and intercardinal ↩︎
and, I should probably make a few more palettes ↩︎
because ~~i’m fabulous~~ I made the damn thing ↩︎
we’re not in the prediction business ↩︎
maybe from one solstice to the next ↩︎
0: North; 90: East; 180: South; 270 West. And everything in between ↩︎
don’t bother going over 50 ↩︎
wholly ↩︎

streaming

tlohde — Wed, 20 May 2026 18:44:00 GMT

Not always, but sometimes when I need^[1] to concentrate™, I put some music/noise on. Either through headphones or the speaker. FIP often fills silence satisfactorily. Brown noise also works.

Sometimes I turn to youtube for long background tracks like the ten-hour long White Noise Sounds of Frozen Arctic Ocean with Polar Icebreaker Idling. Or, clichéd as it may be, I do also quite like the lofi girl streams, specifically the “lofi hip hop radio beats to relax/study to”.

the problem

It’s not really a problem, but it bugs me to have to have a browser window with youtube open.

the solution

Some fragile python code, a bash script, a function and an alias in my .bashrc file, which altogether mean I can type streamurl in my terminal, and the music/noise just plays.

VLC’s GUI doesn’t even open because we used cvlc instead of just vanilla vlc. There are a few more lines of python that mean if I don’t pass pass a url, it’ll deafult to “lofi hip hop beats to relax/study to”.

To stop it I tiptap: streamstop.^[2]

(some of) the python

import yt_dlp

def play_stream(url):
    ydl_opts = {
        'quiet': True,
        'no_warnings': True,
        'extract_flat': False,
        'format': 'best',
        'skip_download': True
        }
    
    # get the streaming url
    with yt_dlp.YoutubeDL(ydl_opts) as ydl:
        info = ydl.extract_info(url, download=False)
        if 'url' in info:
            stream_url = info['url']

            # run vlc
            vlc_cmd = [
                "cvlc",
                stream_url,
                "--no-video",
                "--quiet"
            ]

            # make it quiet, and make pid accessible
            process = subprocess.Popen(
                vlc_cmd,
                stdout=subprocess.DEVNULL,
                stderr=subprocess.DEVNULL
            )

            # get pid and store pid
            pid = process.pid
            with open("/tmp/streaming.pid", "w") as f:
                f.write(str(pid))
            print(f"pid ({pid}) written to /tmp/streaming.pid")

the bash script

#! usr/bin/env bash
source /home/myUserName/micromamba/etc/profile.d/mamba.sh
micromamba activate yt
python3.14 /home/myUserName/Documents/projects/streamyt/play_url.py $1

the bash function

streamurl() {
    "bash" "/home/myUserName/Documents/projects/streamyt/play_url.sh" "$1"
}

the alias

alias streamstop="pkill -f vlc"

footnoes

or want ↩︎
I’d intended on using the pid that a wrote to a file to kill the process, but found filtering for vlc with -f works just as well ↩︎

euclidean cities

tlohde — Thu, 14 May 2026 01:25:00 GMT

I am currently reading Mapmatics: How We Navigate the World Through Numbers by Paulina Rowińska.^[1]

Chapter 4 — Distanced — starts by discussing homeomorphic representations that distort distances but preserve connections, such as Harry Beck’s map of the London Underground. This leads into a brief section critiquing the isochrones on the maps dotted across London that aim to depict where you can walk to in 5 or 15 minutes, but actually show where a crow could fly to, because they don’t pay any attention to the street network.

In some silly little corner of my silly little head, a silly little seed was planted.

By the time I’d finished reading the next section where euclidean distance and manhattan distance were introduced, that seed had taken root and grown into a fully formed silly little question.

what’s the most euclidean city?

Buildings and railways and rivers and churches and other people’s homes all have a habit of getting in the way. From where I am currently sitting, it is a mere ~400 metres to a bakery that’ll bankrupt you as fast as you can say “two cinnamon buns please”, but to get there I have to walk ~800 m. That’s a ratio of 2.

From the train station to the climbing gym I used to frequent it’s a short 2.15 km walk. But that’s still 1.5 times further than the straight line distance of 1.44 km.

The aquarium is only…you get the idea.

A city that had straight roads from everywhere to everywhere else would be perfectly euclidean (and weird) (Fig 0d). I don’t think such a city has been constructed, so where’s the next best place? Which city on average has the lowest ratio of network distance to euclidean distance? Or, to twist and frame this question in a way that makes it sound slightly more useful, which city is most accommodating to the reluctant and lazy pedestrian or tired cycle courier?

Fig 0: Ljubljana, Slovenia: 250 m radius. Left to right, top to bottom: (a) all nodes in street network (n_nodes=184); (b) the street network as it is (n_edges=448); (c) the network as it would be if all streets were straight; (d) the perfect network where one would never have to travel further than neccessary (n_edges=16,836 ((n_nodes * n_nodes-1) / 2 )).

literature review

I’m saving the reading until after I’ve done this, because I don’t want to discover that someone else has already done this, and in the way that is better than I am possibly capable of. That would be demoralising, and also rob me of the joy of mucking about with: (a) an idea; (b) some data; and © a new-to-me plotting library.

This may become a future post.

method

data

Representative points for each european capital were taken from OpenStreetMap, and for each city, a 3 km buffer was drawn and the street network within this buffer extracted using the python library osmnx. The networks were reprojected into the local UTM zone and some network summary statistics calculated with osmnx.stats.basic_stats.

show the code

basic_stats = []
for capital in tqdm(capitals.itertuples()):
    name = '_'.join(capital.name.split(' '))

    digraph = ox.graph_from_point(
        center_point=(capital.geometry.y, capital.geometry.x),
        dist=3_000,
        network_type='walk',
        simplify=True,
    )

    proj_graph = ox.projection.project_graph(digraph)

    ox.io.save_graphml(
        proj_graph,
        f"graphs/{name}.graphml"
        )
    basic_stats.append(
      {capital.name: ox.stats.basic_stats(proj_graph)}
    )

stats_df = pd.concat([pd.DataFrame.from_dict(s) for s in basic_stats], axis=1).T
stats_df.to_json('basic_stats.json')

sampling & routing

To estimate the network’s average ratio of network distance to euclidean distance, pairs of nodes were drawn at random (without replacement) from an area within 1500 m of each city centre point, and both the shortest network path (osmnx.routing.shortest_path) and the straight line distance between them calculated. The motivation behind sampling nodes from a smaller area was to (a) mitigate the shortest route being via a node outside of the 3 km zone originally selected; and (b) keep it to an area that I assumed^[2] would be where rates of pedestrianism are greatest. In the spirit of not letting my laptop get too hot and bothered^[3], only 10% of the nodes were sampled from each city. This proportional sampling means that the number of nodes sampled, and subsequently the number of ratios calculated, varied for each city (table 0).

show the code

def sample_network(capital, bufferdist=1500, samplefrac=0.05):

    name = '_'.join(capital.name.split(' '))

    graph = ox.io.load_graphml(f"graphs/{name}.graphml")
    all_nodes, all_edges = ox.convert.graph_to_gdfs(graph)
    crs = all_nodes.crs

    # select and sample from nodes within `bufferdist` of capital point
    inner_buffer = (
        capitals.loc[capitals['name']==capital.name]
        .to_crs(crs)
        .buffer(bufferdist)
        .iloc[0]
    )

    inner_nodes = all_nodes[
        ~all_nodes.intersection(inner_buffer).is_empty
    ].index.tolist()

    n_samples = int(len(inner_nodes) * samplefrac)

    linestrings = []
    for _ in range(n_samples):
        # pop used nodes
        orig = inner_nodes.pop(random.randrange(len(inner_nodes)))
        dest = inner_nodes.pop(random.randrange(len(inner_nodes)))

        # but allow routing across whole graph - so route can leave
        # the inner_buffer if needed
        route = ox.routing.shortest_path(
            graph,
            orig,
            dest,
            weight='length'
        )

        route_gdf = ox.routing.route_to_gdf(
            graph,
            route,
            weight='length'
        )

        # merge route edges to single linestring
        ls = line_merge(MultiLineString(route_gdf['geometry'].tolist()))
        linestrings.append(ls)

    # make some stats, return reprojcted
    gdf = gpd.GeoDataFrame(geometry=linestrings, crs=crs)
    gdf['network'] = gdf.length
    gdf['euclidean'] = gdf.boundary.apply(
      lambda mp: mp.geoms[0].distance(mp.geoms[1])
      )
    gdf['ratio'] = gdf['network'] / gdf['euclidean']
    gdf['city'] = capital.name
    gdf['utm_crs'] = crs.to_epsg()

    return gdf.to_crs(4326)

And I think that’s ok^[4].

Table 0: number of node pairs sampled per city

show the table

city	n
Ankara	72
Valletta	76
Vaduz	76
City of San Marino	82
Andorra la Vella	87
Bucharest	136
Podgorica	149
Nicosia	154
Skopje	155
Monaco	157
Amsterdam	164
Sarajevo	167
Budapest	169
Lisbon	171
Pristina	171
Luxembourg	200
Chișinău	201
Stockholm	207
Belgrade	208
Reykjavik	231
Vatican City	243
Athens	247
Copenhagen	261
Sofia	264
Madrid	266
Zagreb	268
Dublin	275
Kyiv	276
Prague	278
Rome	284
Vilnius	293
Riga	294
Bern	299
Ljubljana	318
Vienna	330
Oslo	339
Brussels	343
Tallinn	345
Tirana	347
Minsk	360
London	375
Berlin	375
Bratislava	381
Paris	400
Moscow	490
Warsaw	517
Helsinki	848

statistics

To ascertain whether or not any differences between two given cities’ street network euclidean-ness is statistically significant some statistics were done…

This involves comparing the distribution of network:euclidean ratios for a given city (e.g. Fig 1). ANOVA, or analysis of variance is the tool for the job. However it requires few assumptions to be met:

independence
normality
homoscedasticity^[5]

if you can read this, the figure hasn't loaded. sorry

Fig 1: Distribution of network:euclidean distance ratios across Ljubljana.

Independence is a safe assumption. These are different cities, separated by some distance, in different geographical and geological settings. Sure some urban planning practices, designs and themes might have been copied here and there, but, whatever. Check.

Normality was tested with scipy.stats.normaltest and they all came back as normal enough.^[6] Check.

Homoscedasticity. Fail. scipy.stats.bartlett suggested that these samples are unlikely to have equal variances.

So, no ANOVA today. Kruskal-Wallis, however, can be used as a substitute as it operates on the ranks of the data, rather than the data itself.

Kruskal-Wallis will only tell you if there is a difference between groups, but it won’t tell you which cities are different. For that you need a bit of post-hoc analysis.^[7] Pairwise comparisons were carried out using Conover’s test as implemented in scikit_posthocs with step-down Bonferroni adjustments to account for there being multiple comparisons.

results

the headline

Madrid is the most euclidean; Valletta the least.

the detail

They are different (Fig 2). Well, some of them are at least. It is a spectrum. You could even say there is spatial heterogeneity.^[8]

Madrid, Brussels, Paris, and Oslo are the most euclidean, apparently, with median ratios of 1.195, 1.216, 1.222, and 1.228, respectively, and if Conover’s test is to be believed, they are not significantly different from one another (p-value > whatever threshold you fancy, 0.05, 0.001) (Fig 2). At the other extreme: Valetta (2.440), Vaduz (1.397), and Budapest (1.375) were the least euclidean, and can all be considered similarly inefficient.

if you can read this, the figure hasn't loaded. sorry

Fig 2: Heatmap of post-hoc pairwise comparisons using Conover's test. Small p-values allow us to reject the null hypothesis, and conclude that there is a difference between any given pair of cities, i.e., differences can be found in the purples around the edge of the figure. note: the colour scale is logarithmic.

Cities with larger average ratios also had greater variance^[9] (Fig 3). Even within the most spaghetti-like city, some routes from will still be relatively direct, for example, in Stockholm you could get from the junction of Odengatan and Birger Jarlsgatan to the center of Svensksundsparken on Skeppsholmen traveling only 9.7% further than a bird (euclidean: 2683 m, network: 2942 m; ratio: 1.097). It is worth noting that this is largely independent of distance, i.e. it is not just a few long and wiggly routes that drive the greater variance. There are long direct routes, and short circuitous ones. For each city the ratio was hastily regressed against euclidean distance, and no consistent pattern emerged, with r-squared values typically around ~0.09.

if you can read this, the figure hasn't loaded. sorry

Fig 3: boxplot of network : euclidean distance ratios for each city, sorted by median. Note the logarithmic x-scale. Hover over a box for maximum, minimum, median and IQR values (given to too many decimal places for no good reason)

A quick comparision with all the statistics generated by osmnx.stats.basic_stats shows, mercifully, that I didn’t re-invent the wheel here.^[10] Average street circuity is the metric with the greatest similarlity to the ratio calculated here, and whilst they are correlated (r=0.33), they are different. ish. Andorra, with its hairpins tops the circuity charts, whereas Budapest is amongst the least. The circuity average is the result of averaging the circuity^[11] for each edge, whereas the ratio calculated here is for a route across the network, involving multiple edges. It is understandable that these are different, since the angle at which streets intersect is not being accounted for in the former, whereas it is implicity included in the latter.^[12]

why are the cities different?

To understand the differences in network : euclidean distance ratios between cities, it is neccessary to view them in situ, in context (Fig 4).

if you can read this, the figure hasn't loaded. sorry

Fig 4: Map showing routes between random nodes (solid lines) and the associated straight line paths (dashed). Hover over a route to see more details (note: out of respect for your internet speed, only 20% of samples are shown for each city)

The shortest, simplest, answer to explain away any differences is: water.

Valletta, the least euclidean in this cough “study”, straddles two harbours^[13]; the Danube cuts Budapest in two, and it’s wide (~350 m ish), and the (two) bridges (that fall within my little study area) are a kilometre apart. Whereas Paris, which is admirably euclidean, despite being centred on Île de la Cité in the Seine, manages to squeeze in 10 bridges in ~ 3km. Stockholm’s numerous islands and the-opposite-of-numerous bridges, means it has a relatively high median ratio (1.31), and a long tail.

A slightly longer, slightly more nuanced, answer is: water and hills. Vaduz illustrates this most clearly, with its hairpins on Fürst-Franz-Josef-Strasse. Andorra la Vella also has it’s fair share of wiggles. But they’re both tiny, and that will be discussed shortly.

Brussels, Madrid, Sofia and Oslo have the tightest inter-quartile ranges, and Athens, Madrid, Ankara and Rome have the highest average of streets per node. With no obvious relationship to be found here.

The qualities that can best tease apart the subtle and not-so differences, are perhaps those that can’t readily be described by a quantity^[14]: design and history. This is where I would like to talk about Haussmann’s renovation of Paris, or how apt it is that Berlin and Helsinki are adjacent to one another in Fig 3 since it was Carl Ludvig Engel, who was trained as a surveyor at the former before becoming the architect charged with reconstructing the latter. But I shalln’t because I’m not remotely qualified to, and I respect you more than to just regurgitate wikipedia at you. Mwah.

but

No self-respecting^[15] cough “study” would be complete^[16] without a limitations and caveats section. This is that.

sensitive

In version 1^[17] of this analysis, the sampling strategy differed in two key ways: firstly a, larger, 5 km radius was used instead of 3 km; and secondly nodes were sampled from anywhere within that 5 km, as opposed to the inner 1.5 km done here. Those results looked different. Stockholm was the least euclidean, Paris the most (with a median ratio of 1.14, 0.05 less than Madrid scored in this version). Budapest was somewhere in the middle, as was Vienna.

The motivation behind shrinking the area, in addition to the reasons in the method, was to allow for smaller capitals (Andorra la Vella, Vaduz), to stand a fighting chance of being treated fairly. An option that was considered was to take the whole area of the capital, but for London would that mean taking all of Greater London, which feels wrong, and would include Biggin Hill, or just the City of London, which also feels wrong. Applying a blanket radius was simpler than selecting the areas individually, manually.

So, treat these “results” accordingly.

perhaps wrong

When having a look at some of these results, Belgrade’s anomalously long tail stood out. The Sava can be crossed as a pedestrian on both the Brankov and Gazela bridges, and OpenStreetMap shows that to be the case. However it seems that the network is either (a) being incorrectly extracted from OpenStreetMap in the first instance; or (b) the bridges are lost during simplification process. As such, many routes that cross the Sava are being heavily penalised as they detour South to the Ada Bridge.

So, treat these “results” accordingly.

likely incomplete

The search space isn’t so large that an option would be to skip the sampling altogether, and do either every pair, or pick a single node at the center and calculate network distances from that node to every other node (networkX has a function for just that).

conclusion

You’re probably walking ~1.3x further than a crow is flying. On average. ish.

footnotes

minor grumble: the UK edition has the least interesting cover-art. the german and italian covers are great. ↩︎
not very science-y of me, sorry ↩︎
coupled with some impatience, and not wanting to have to think too hard about writing efficient code ↩︎
as does the friend who i asked ↩︎
this is where i could have included a definition, but chose not to. sorry, you’re on your own ↩︎
(ed.) the same cannot be said of the author ↩︎
while being mindful that at some point false positives are going to pop-up ↩︎
small grievance: studies that state this like it is surprising. what would be surprising if everything was the same everywhere ↩︎
i.e. a bigger coefficient of variation ↩︎
i sort of did. but that’s ok. wheels are great ↩︎
well, duh ↩︎
fighting the urge to scratch the what-angle-do-streets-typically-meet-at itch ↩︎
and efficiently highlights a shortcoming of this cough “study”: there are ferries ↩︎
unfortunately ↩︎
not that i, or this study are capable of that ↩︎
this also isn’t ↩︎
yes, believe it or not this is the improved version 2 ↩︎