Acts 27 recounts Paul’s shipwreck as he travels from Crete to Malta after Yom Kippur (September 24 in AD 60, approximately when this story is set). For the shipwreck portion of the voyage, his ship starts in Fair Havens on the southern of coast of Crete. They’re trying to make port in western Crete but are blown by a strong wind from the northeast. The sailors are concerned about being driven into sandbars in the gulf of Syrtis, so they let the ship be blown along and eventually end up in Malta.
On November 11, 2021, Storm Blas set up this wind pattern almost exactly, connecting Crete to Malta (the strong white line represents my interpretation of a possible path):
This wind pattern comes from the mesmerizing earth.nullschool.net, where you can also play around with an animated version. (It’s way more exciting than this static image). This image reflects a point in time, while Paul’s shipwreck narrative takes two weeks. So this wind pattern would change during the voyage; this image just happens to show the appropriate wind pattern for the whole voyage.
Arguably, the wind should blow them farther south, closer to Syrtis. Cyclone Zorbas from September 27, 2018, shows an even-more-intense flow that would take a ship nearer Syrtis. It doesn’t connect to Malta, but, again, the wind patterns would change over the course of several days.
Earlier in the story, Luke describes sailing from Sidon “under the lee of Cyprus, because the winds were against us.” Then they “sailed across the open sea along the coast of Cilicia and Pamphylia” on the way to Myra. Bible maps don’t entirely agree what “the lee of Cyprus” implies for the route (some take it to mean sailing along Cyprus’s southern coast, though that interpretation creates tension with “Cilicia and Pamphylia” to the north). This image from October 29, 2023, illustrates the lee along Cyprus’s eastern coast:
Finally, the trip from Myra to Cnidus (“with difficulty”) and then to Salmone on Crete (“the wind did not allow us to go farther”) could find an expression on October 13, 2024. In this image, the winds during the segment from Myra to Cnidus are coming from the west or northwest, against the direction of travel. The strong winds from the north through the Aegean make westward travel difficult, pushing the ship south. This wind pattern appears to be typical for this time of year.
Again, I’m not arguing that these images reflect the actual wind patterns involved in Paul’s shipwreck voyage; I’m just showing that it’s possible to find modern analogues to the winds described in the story.
Posted in Geo, Visualizations | Comments Off on Visualizing the Wind Patterns Leading to Paul’s Shipwreck
When Bob Pritchett asked me at the BibleTech 2019 conference what I was working on at the time, I answered that I’d returned to the idea that originally launched this site: Bible geography. When I told him that, I’d intended to present the results of this effort at a presumptive BibleTech 2021 conference. Since the global pandemic has put in-person conferences and travel on hold, however, here are 4,800 words about it instead of a presentation.
This project is a Bible atlas (technically, a gazetteer) that (1) comprehensively identifies the possible modern locations of every place mentioned in the Bible as precisely as possible, (2) expresses a data-backed confidence level in each identification, and (3) links to open data to fit into a broader data ecosystem. The goal is to provide a baseline for future Bible geography projects to use.
In my original design document for this project, I have the following guiding principles; I’ll discuss their implementation below:
Comprehensively reflect current scholarship.
Use linked data.
Be accurate and precise.
Quantify uncertainty.
Handle non-point data.
Include media.
Open the data.
Background
I started this site in 2007 with the idea of creating a place that embraced Google Earth as a way of exploring places mentioned in the Bible. I relied on freely available and older public-domain sources to disambiguate and identify modern locations of biblical places, and then I picked the location that looked likeliest to me. The 1899 Morrish Bible Dictionary proved especially helpful because it included latitude and longitude coordinates for many of its entries. Of course, it also reflects a late-nineteenth-century view of biblical and archaeological scholarship.
Over time, I became frustrated with the limited nature of the dataset; I wanted to incorporate modern scholarship, which meant one thing: I needed a budget.
Used Bible atlases are surprisingly cheap; you can find most of them on Amazon for around $10 each. Bible dictionaries and encyclopedias are surprisingly expensive: even digitally, they run $100 or more. Commentaries also add up because there are so many of them. Fortunately, I know people with commentary libraries that I could use, helping keep the cost down:
In the end, my content budget for this project ran about $1,000, and I consulted what I believe to be every significant Bible atlas, dictionary, and encyclopedia published since 1980 (and several before then).
Goal 1: Comprehensively reflect current scholarship
With this variety of sources—over seventy in all—it becomes possible to paint a full(ish) picture of where modern scholars believe biblical places may have been.
My basic method was simple:
Start with a place mentioned in the Bible.
Consult a dictionary/encyclopedia article, atlas/gazetteer entry, commentary note, or other reference work related to that place.
Record every suggestion of possible locations for the place, including the confidence of the suggestion.
Research coordinates for any modern locations mentioned.
Repeat steps 2-4 across 70 or so sources.
Repeat steps 1-5 across all 1,300 places mentioned in the Bible.
In this way, you end up with a set of “votes” from authors that, in principle, reflects the current consensus on where a place was. This approach also removes me from the position of deciding which identifications are more valid than others.
A typical Bible atlas makes around 500 identifications; a large dictionary or encyclopedia might suggest around 1,000. This project records over 3,200 identifications, tallying 23,000 votes across 1,340 ancient places tied to nearly 1,600 possible modern locations.
I use the word “identification” because a source might say that a particular place is another name for a different ancient place, or maybe not even a place at all, so not every vote is for a modern location. The ratio of modern-to-ancient suggestions generally runs around 2:1—in other words, there are usually around twice as many modern suggestions (identifying a specific modern location) as ancient suggestions (identifying a biblical place with another ancient place).
For the purposes of this project, authors have nineteen ways to propose an identification. I particularly want to highlight the different rhetorical strategies of “confidence” vs. “authority.” About 82% of the time, authors will express their own opinion that a certain identification is likely or unlikely. The rest of the time, they’ll appeal to the prevailing consensus, use the passive voice to avoid expressing their own view, or note that someone else has made an identification.
Here’s the schema I used to model this rhetoric.
Category
Keyword
Common words used
Confidence
Yes
is, undoubtedly, no doubt, confirmed, is to be identified with, convincingly identified, surely, corresponds to, has been fixed to, no good reason to question, almost universal agreement, is represented by, should be connected with
Likely
probably, likely, gazetteer entry without qualification, plausibly identified, evidently, fairly certain, quite possibly, popular, attractive, strongly suggest, suits well, serious candidate, seems to fit, presumably, may well be, strong evidence
Most likely
most likely, most probable, best fit, most suitable, strongest candidate, best current suggestion, least objectionable, best identified, best explained
Map
(coordinates unambiguously match on a map)
Possible
possibly, may, (gazetteer entry with qualification, e.g., “?”), tentatively, preliminarily, provisionally, some scholars, apparently, sought at
Unlikely
unlikely, much less likely, doubtful, tenuous, dubious, problematic
No
not, reject, little to commend it, rule out, abandon, unacceptable, out of the question, impossible, unthinkable
Identified
Is identified
is identified, is believed, is associated with, now identified, is identifiable
Has been identified
has been identified, has been inferred, has been linked with
Identified (as an adjective)
identified, suggest, associated with
Authority
Old
formerly, previously
Parallel
parallel passage
Preserved
name has been preserved, name is preserved, name survives
Scholar
(another scholar is cited by name)
Traditional
traditionally, historically, (if the tradition predates the nineteenth century)
Usually
generally, usually, most scholars, many scholars, most often, most, customarily, commonly, consensus, gained favor, is thought to be, prevailing identification
Variant
certain translations read
Unknown
Unknown
Unknown
Uncertain
Uncertain
Goal 2: Use Linked Data
A modern Bible atlas doesn’t exist in a data desert; it participates in a network of scholarship both focused on the Bible and also on general history. Linked Data is a way to map data between different datasets—a way to participate computationally in this network of scholarship. This project contains 6,536 Linked Data connections for the ancient places mentioned in the Bible (though, to be fair 1,228 of them are to the 2007 version of this dataset).
About half of the places mentioned in the Bible have a Wikidata entry; I also bring in other ontologies —notably the Bible-oriented Logos Factbook and TIPNR—and Pleiades, the broadly historically focused “community-built gazetteer and graph of ancient places.”
But linking ancient places reflects only half the story: modern locations also have identifiers, and usually coordinates associated with an identifier. Here again I draw on Wikidata but also on modern gazetteers like GeoNames and OpenStreetMap.
In all, 6,473 Linked Data connections support the coordinates for modern locations.
Most reference works, when they provide coordinates at all, use a 1 km (0.6 mile) resolution—in other words, they get you within 1 km of the actual coordinates of what you’re looking for. Often they just say that a modern location is “near” another one or provide a rough distance and (if you’re lucky) a direction from a larger city. Sometimes, if they’re drawing from nineteenth-century travelogues, a source might say that a location is a certain number of hours (by foot or horse) along a road between two other cities, or they just provide a name with no indication of where it is. The point is that they’re usually (but not always!) accurate—they provide a general sense of where a location is. Unfortunately, they’re not usually precise—telling you exactly where it is.
Fortunately, with modern, public data and gazetteers powered in part by local knowledge, we can do better. Digital sources often provide precise coordinates for ruins visible on the ground. In this dataset, 17% of locations have coordinates with 10 m, 57% within 100 m, 87% within 250 m (matching a modern settlement), and 97% within 1 km. All locations are as precise as I can find support for; some places in Jerusalem (e.g., the Millo) potentially have specific archaeological remains inside the city with exact coordinates.
Additionally, I’ve provided over 1,200 comments on how I came to decide on the coordinates for certain locations (the hard ones to find, or ones with seemingly contradictory sources) so that you have a starting point to validate my decisions beyond the Linked Data. Finding coordinates for modern locations represents the bulk of the time I spent on this project; many of these locations took hours of research to locate, and I cite over 400 different sources.
Goal 4: Quantify uncertainty
Even after this research, however, it wasn’t always possible to find exact coordinates for modern locations. Therefore, I also provide my estimate of how close the coordinates in this dataset are to the actual coordinates. Sometimes the best-available coordinates aren’t exactly where they should be because archaeological datasets predate GPS, or the datasets just don’t try to be more precise.
On the other hand, while modern locations have positional uncertainty, ancient places come with their own set of uncertainties.
About 150 ancient identifications are described as “near” somewhere else, which I attempt to quantify based on context (in some cases, “near” might mean 1 km, and in others it might mean 10 km or more).
But more significantly, scholars just aren’t sure where many biblical places are. Since a goal of this project is to document all the possibilities, the question then becomes how to decide which identifications are most likely. My solution, which has substantial room for improvement, involves looking at the change in confidence over time.
I assign a numerical score for each confidence level (e.g., a “Yes” vote from a source counts for 30 points, while a “Likely” vote counts for 24), sum the scores from each source, normalize the scores (where 1,000 represents near-certainty), and then group them together into decades. In theory, the resulting composite score reflects the confidence of scholarship for a particular identification during that decade. Then, if you draw a best-fit (linear regression) line across the decades, you can see where the scholarship is trending. The number I use for determining confidence levels reflects the value of this best-fit line in 2020.
When we look at a chart expressing the data for Gath of the Philistines below, for example, the trendlines largely reflect what you’d expect if you’re familiar with the controversies over its identification: around the 1950s, it was identified with Tel Erani, but later archaeological discoveries have shifted the identification definitively away from there and likely to Tell es-Safi. Other good examples of shifting confidences are Ai and Anaharath.
The main problem with this approach is that a line doesn’t necessarily model the data well, 77% of the time, the r-squared value is less than 0.5, meaning that confidence doesn’t get consistently higher or lower with time but rather jumps around. See Abel-keramim, for example.
There are other options for generating confidence. For example, I could sum the overall confidences over time so that the lines move higher as time goes on. However, because the number of sources varies by decade, the lines jump in ways that don’t necessarily reflect the underlying confidence levels. I decided that using line charts was the least-misleading way to approach the data, imperfect though it may be.
Goal 5: Handle non-point data
This vote-based approach to modeling uncertainty also extends to regional geographic data. Regions in the past didn’t necessarily have the sharp political boundaries we think of today, and they varied over time as their territory waxed and waned. Thus, while it’s nice to present tidy historical boundaries on a map, reality was messier. We can still try to quantify the messiness, however.
I chose to approach the problem of regions not from a historical or political perspective but from a cartographic one. Instead of answering the question, “What are the boundaries of this region?” I instead answer the question, “Where should I put a label for this region on the map?” And it turns out that this latter question is answerable using a methodology like the one I used for place identifications.
I took about 70 different Bible atlases and other reference works and recorded polygons roughly where the region labels or boundaries appeared. (This approach involved a lot of interpretive looseness on my part: I wanted to emphasize the commonalities among the different sources.) Here’s what the labels for the region of Ammon look like, for example:
Then I combined the polygons from the different sources to create a confidence heatmap: for example, “four sources suggest this point was in the region, but only three sources support this point over here.” The resulting concave-hull isobands (with each line indicating the number of sources supporting the position of the region, so inner isobands reflect a higher confidence) yields useful information about not only where to put a label but also the rough—very rough—extent of a region. The following isobands for Ammon, for example, draw from sixteen sources and show its core territory around Rabbah, as you’d expect. The outermost isoband reflects confidence levels from two sources, while the inner reflects confidence from ten or more. Thus, if you were looking to place a label on this map for “Ammon,” your best bet would be in the innermost polygon, but anywhere inside the isobands would reflect a consensus placement.
Ultimately, I created 3,545 polygons to generate 77 isobands files. Not every ancient region is controversial enough to justify isobands; this dataset contains 238 region files in total.
In addition to regions, there’s also path data, especially for rivers and wadis. The previous version of this dataset treated them as points, but OpenStreetMap already had paths for many of the relevant rivers, and when the OSM data didn’t already exist, I created it there. In total, about 120 paths have geometry in this dataset; I made 91 edits to OSM as part of this project.
For example, here are the paths of possible identifications for the Brook of Egypt (for display, I reduce all paths to around 100 segments, but the dataset also contains the full geometry from OSM):
Goal 6: Include media
The final major component of this dataset is the inclusion of an image to represent every modern location: there are about 1,650 512×512-pixel “thumbnail” images that are freely available to use. Just over 1,000 of them are drawn from Wikimedia Commons, while the remaining have a satellite image (with a resolution of 10 meters per pixel) illustrating the area surrounding the location. Honestly, Wikimedia Commons had more images than I was expecting: many of these locations are pretty obscure.
About 50 images illustrate an ancient region. (For example, the best thumbnail for the region of Gilead probably isn’t one of an archaeological site that happens to be in the region.)
Locations with Wikidata items often had images associated with them. In other cases, the WikiShootMe tool provided a way to find untagged images of the location (or sometimes an artifact associated with the location). Once I had a viable image, I cropped it into a square and potentially adjusted the colors or used Photoshop’s Content-Aware Fill tool to edit it for consistency and to be more legible at small sizes. The dataset also records license and attribution data as presented on the Wikimedia Commons page for each image.
To create the satellite images, I used Sentinel-2 composites from 2019. Sentinel-2 is a European satellite; its 10-meter-per-pixel resolution is just enough to illustrate the general character of a location (e.g., desert vs. wooded, hilly vs. flat). The resolution is lower than what you see on Google Maps but is freely reusable.
All images have descriptive alt text since accessibility is a modern application of Christian charity. The images themselves also have accessibility and license and attribution data embedded in them.
I struggled most with finding images to illustrate regions. Below, for example, is what I chose for the Sharon Plain; it shows that the region is coastal, flat, and agriculturally fertile, but depicting a whole region using a single image will necessarily be reductive.
Goal 7: Open the data
All the data is available in a GitHub repository with a 7,000-word readme describing the (unfortunately complex) data structure. My hope is for you to do something interesting with it. It’s under a CC-BY license, though the images are under a variety of Wikimedia-approved free licenses (as noted in the metadata), and the OpenStreetMap data is under a CC-BY-SA-style ODbL license. GitHub isn’t ideal for data projects like this (though it does have an integrated GeoJSON viewer), but I wanted a stable, long-term host that doesn’t make you jump through hoops to get the data.
The dataset currently contains files for (the totals may change over time):
Ancient places (1,342 entries).
Modern locations (1,596 entries).
Geometry (6,621 GeoJSON and KML files) and metadata (588 entries for non-point data) for both ancient places and modern locations.
Images (1,650 jpegs) and image metadata (2,424 entries—there’s metadata for images considered but not included, as well as pointers to some copyrighted images, especially Google Street View).
Sources consulted (442 entries).
JSON Schemas to validate the rest of the data (5 schemas).
Beyond the 175 MB of images, you’ll find 100 MB of geometry data and 16 MB of core data.
The only data omitted from the repository is the raw vote data (“Anchor Yale Bible Dictionary found this particular identification to be ‘likely’”) because I want to supplement—not replace—my sources; if you want to find out how Anchor Yale Bible Dictionary identified a place, the data shows you where you can look it up in your own copy. This project transforms and interprets raw data, bringing together different perspectives and uniting different datasets, both in print and online. To save you time in your research, I want to point you to scholarly sources where you can learn more about the arguments for various identifications.
Limitations
This dataset has a number of limitations:
It builds on the work I did in 2007 to disambiguate places mentioned in the Bible. While I reworked many of the places (e.g., I didn’t realize in 2007 that there’s more than oneRabbah), I didn’t revisit the disambiguations from scratch.
The disambiguations also showcase a limitation to the data model. If two places in the Bible share a name, but my sources disagree about which one a certain verse is referring to, then I created a third place with identifications pointing to the other two. There aren’t really three possible places; the third one exists only because the data model requires it. For example, Ibzan’s hometown of Bethlehem 3 is likely Bethlehem 2 or possibly Bethlehem 1, not a third Bethlehem somwhere.
Similarly, some sources may consider a place the same as another one, while other sources may mention the modern location associated with the other place but not make the ancient connection explicit. I recorded the identification as described in the sources, but it leads to situations where the same modern location appears in multiple identifications, as part of both “another name for an ancient place” and “at this modern location” identifications. For example, Timnah 3 has Khirbet et Tabbaneh both as a possible identification for Timnah 2 and as a separate, modern identification.
While I’m confident that the spelling of biblical place names correctly reflects the text of the translations they appear in, spellings of modern locations are less validated. They could easily contain typos (where the typos exist in a source, I note it). They also reflect a variety of transliteration approaches from the nineteenth century to today. The primary modern name depends on whether it’s unique in the dataset, not whether it reflects the dominant name used in the sources. (For example, Bethsaida could be at at-Tell while Ai could be at et-Tell, names that reflect different transliteration approaches from Arabic into English of the same underlying name.) Additionally, I don’t know Hebrew or Arabic, so the transliterated diacritics I preserved could be wrong. I focused on simpler transliterations and thus didn’t usually preserve some more scholarly aspects of transliterations like breathing marks.
River geometry is always a single path, even if the river has branches. This limitation is most apparent on large rivers like the Nile, whose geometry doesn’t reflect the delta as it approaches the Mediterranean.
The identifications depend on my reading comprehension, interpretation, and conversion of freeform text into structured data, not to mention my limited sources and research abilities. The identifications don’t have the kinds of checks and balances a more-formal research project would entail. My goal was 90% accuracy.
Originally, I’d hoped to provide a wiki-style interface to the data, where people could contribute. But the data is so interrelated—it relies on a 45-step build process from raw spreadsheet to final form—that such functionality went beyond the scope of what I could accomplish. The identifiers also rely on static data snapshots and don’t incorporate improvements to, say, Wikidata that have appeared since I first pulled the data from there. The result is less dynamic than I’d originally hoped.
Advancements over the current state of the world
This project attempts to advance the state of the art along the following dimensions:
Number of identifications. With 23,000 votes for the locations of ancient places, this project reflects a broad (if heavily evangelical) survey of current thinking. And with 3,259 distinct identifications, it has around six times as many identifications as the typical Bible atlas. However, Bible atlases provide context and interpretation that this project lacks; I’m not trying to replace a Bible atlas, only to provide supporting data.
Precision of coordinates. With 87% of coordinates identified to within 250 m, the precision in this project outshines the best-case 1 km precision (often just a prose description) found in most Bible reference works.
Number of Bible translations. Ten Bible translations reflect a variety of spellings and translation approaches, reducing reliance on the ESV (compared to the 2007 version of this dataset). The NLT, for example, likes to use place names in verses where other translations instead might say something like “there.” In total, 5,616 verses contain at least one place name, with 87,988 total name instances tracked across all ten translations.
Integration with external resources. Linking to existing databases like Wikidata creates an outward focus and enables future work, with 6,536 ancient connections and 6,473 modern connections.
Images. Every modern location has a thumbnail image, with 1,014 of the 1,650 photos being an on-the-ground, close aerial, or artifact photo, and the remainder being a medium-resolution satellite image.
Transparency of data. With sources cited and data available, you should have what you need to trace my conclusions if you have the relevant sources available to you. (I tried to include links to online sources where possible.) I provide 1,251 comments providing more information in difficult cases.
Benefits to you
If a place is mentioned in the Protestant Bible, it should be in this dataset. You can look it up in the interface by passage reference or name and quickly get a sense of where modern scholars think it could be, as well as how confident they are in the identification. Often the possibilities cluster tightly (Penuel, for example, is probably on one of two neighboring hills, even though one is more likely than the other); if you only need to know an approximate location (which, unless you’re doing in-depth study, is almost certainly all you need), then you’re set. But if you want to know more about the possible locations and how confident my sources are in their identifications, that data is also available to you. I want to encourage you to purchase print or digital books that you find helpful to deepen your study of Bible geography; the dataset includes links to Amazon and other sites like Best Commentaries, sites whose stable urls also provide a further kind of Linked Data.
Interface
The data went live on this site in January 2021, and an interface that showcases it went live in September 2021. Looking at how people use the site has led to some data changes. For example, when I first launched, I didn’t provide proposed locations of the Garden of Eden, just calling it “unknown.” But after seeing how often people look it up, I treated it like any other place and provided potential identifications.
The 2007 version of the interface emphasized downloading Google Earth KMLs for individual books and chapters. For this update, I want to encourage exploration of the data even if you don’t have Google Earth. Therefore, I’ve changed the interface to let you interact with the data in five ways:
1. Book/chapter view
This view lets you see a bunch of places at once so that you can get a sense of how geography fits into the narrative. It includes:
A map of all the places mentioned in the book or chapter.
A way to drill down into a single chapter if you’re looking at a whole book.
A clickable list of all the places (including verse references and potential modern identifications) to explore on another view or on the map on the same page.
2. Ancient place view
This view presents data about ancient places mentioned in the Bible. It includes:
A map of possible identifications, with placemark pushpins varying in opacity depending on the confidence of the identification.
Any alternate names found in Bible translations.
Geo data (KML and GeoJSON) for the identifications.
All the identifications and their corresponding confidence levels.
Bible verses where the place appears.
Linked Data identifiers.
Sources supporting the identifications.
A graph of confidence trends over time.
Links to similarly named places (especially since the numbering system I use—“Aphek 1,” “Apkeh 2,” etc.—is fairly opaque).
A thumbnail image when the identification is noncontroversial.
3. Modern location view
This view presents data about modern locations identified with ancient places. It includes:
A map showing geometry (point, path, polygon, or isobands), including polygon geometry of an archaeological site if it’s available (e.g., Colossae).
Alternate names (usually different transliterations but sometimes names in different languages, such as Hebrew or Arabic).
Latitude and longitude coordinates.
Palestine 1928 grid coordinates, where relevant; most Bible reference works use this coordinate system.
Coordinate precision (how close to the actual location the coordinates are).
Sources supporting the coordinates.
Accuracy and precision notes.
Biblical places associated with the location.
A thumbnail image.
4. Atlas view
This view is an alphabetical list of all the ancient places. It includes:
A thumbnail image of the most-likely modern location.
A list of possible identifications.
Bible verses where the place appears.
5. Photo view
This view is mostly for legacy compatibility. Previously, I used the Flickr and the now-defunct Panoramio APIs to pull in photos that are geographically near the coordinates, but the result was hit-or-miss. Now there’s a single photo for each modern location associated with an ancient place. I wouldn’t include this view except for historical reasons; I don’t consider it very useful.
Conclusion
It’s 2021. Bible reference works shouldn’t have to say that a ruin is, for example, “on the left side of the road from Salt to Amman, 1.5 hours [by horse] northwest of Amman.” And then you shouldn’t have to spend three hours figuring out exactly where that is, consulting the original 1822 travelogue that makes this claim, and then trying to determine exactly where the road ran in 1822 compared to modern roads. Instead, we should be able to say that that a ruin is at particular coordinates with a certain level of precision. And then we should be able to tie that ruin back to a biblical location with a quantifiable degree of confidence. This project lets us do that.
Environmental impact
Creating this data required about 800 kWh of electricity in computing power and local travel. All the electricity used was solar-generated; carbon emissions totaled about 40 kg. Book shipping generated an additional 103 kg of carbon emissions. The total carbon impact for this project is therefore approximately 143 kg; I don’t have tools at my disposal to be more precise than that. I include this statement just to note that data, even Bible data, has an environmental impact.
In previous posts, I talked about using a digital terrain model for high-resolution Bible maps and using AI to increase the resolution of satellite photos. In this post, I’ll talk about how you can use old black-and-white but high-resolution satellite photos to enhance lower-resolution modern satellite photos, converting this:
to this:
In 1995, President Clinton declassified images taken by Corona spy satellites from 1959 to 1972. These satellites operated at a resolution of up to six feet (around two meters) per pixel, a big improvement over the ten-meter imagery that the current free-and-highest-resolution Sentinel-2 program provides. However, the high-resolution Corona imagery is black-and-white, while the lower-resolution Sentinel imagery is in color. What if it were possible to combine the two?
Not only is it possible–it’s a common practice called pansharpening that you often see (unknowingly) in satellite imagery. The Landsat 8 satellite, for example, takes color pictures at a thirty-meter resolution and black-and-white pictures at a 15-meter resolution; when you combine them, you get a fifteen-meter output.
So if you take the ten-meter Sentinel imagery and pansharpen it with two-meter Corona imagery, you get something like the above image. I combined these images by hand using GDAL Pansharpen; merging them at scale is a more-complicated problem. But others have worked on it: the Corona Atlas and Referencing System run by the Center for Advanced Spatial Technologies (CAST) at the University of Arkansas actually uses Corona imagery to assist in Middle East archaeology. They run an atlas that lets you explore the high-resolution imagery as though it were Google Maps. The imagery’s age is actually an asset for this purpose; urban and agricultural development throughout the Middle East in the last fifty years obscures some archaeological sites in modern satellite imagery. CAST has georeferenced many Corona images and makes the data available for noncommercial use. The GAIA lab at UCSD also makes georeferenced imagery available as part of their Digital Archaeological Atlas of the Holy Land.
Posted in Geo | Comments Off on Using Declassified Spy Satellite Photos to Enhance the Resolution of Bible Maps
In a previous post, I discussed how 3D software could improve the resolution of Bible maps by fractally enhancing a digital elevation model and then synthetically creating landcover. In this post I’ll look at how machine learning can increase the resolution of freely available satellite images to generate realistic-looking historical maps.
Acquiring satellite imagery
The European Sentinel-2 satellites take daily photos of much of the earth at a ten-meter optical resolution (i.e., one pixel represents a ten-meter square on the ground). The U.S. operates a similar system, Landsat 8, with a fifteen-meter resolution. Commercial vendors offer much higher-resolution imagery, similar to what you find in Google Maps, at a prohibitive cost (thousands of dollars). By contrast, both Sentinel-2 and Landsat are government-operated and have freely available imagery. Here’s a comparison of thetwo, zoomed in to level 16 (1.3 meters per pixel), or well above their actual resolution:
The Sentinel-2 imagery looks sharper thanks to its higher resolution, though the processing to correct the color overexposes the light areas, in my opinion. Because I want to start with the sharpest imagery, for this post I’ll use Sentinel-2.
I use Sentinel Playground to find a scene that doesn’t have a lot of clouds and then download the L2A, or atmosphere- and color-corrected, imagery. If I were producing a large-scale map that involved stitching together multiple photos, I’d use something like Sen2Agri to create a mosaic of many images, or a “basemap” (as in Google Maps). (Doing so is complicated and beyond the scope of this post.)
I choose a fourteen-kilometer-wide scene from January 2018 showing a mix of developed and undeveloped land near the northwest corner of the Dead Sea at a resolution of ten meters per pixel. I lower the gamma to 0.5 so that the colors approximately match the colors in Google Maps to allow for easier comparisons.
Increasing resolution
“Enhance!” is a staple of crime dramas, where a technician magically increases the resolution of a photo to provide crucial evidence needed by the plot. Super-resolution doesn’t work as well in reality as it does in fiction, but machine learning algorithms have increased in their sophistication in the past two years, and I thought it would be worth seeing how they performed on satellite photos. Here’s a detail of the above image, as enlarged by four different algorithms, plus Google Maps as the “ground truth.”
Each algorithm increases the original resolution by four times, providing a theoretical resolution of 2.5 meters per pixel.
The first, “raw pixels,” is the simplest; each pixel in the original image now occupies sixteen pixels (4×4). It was instantaneous to produce.
The second, “Photoshop Preserve Details 2.0,” uses the machine-learning algorithm built into recent versions of Photoshop. This algorithm took a few seconds to run. Generated image (1 MB).
The third, ESRGAN as implemented in Runway, reflects a state-of-the-art super-resolution algorithm for photos, though it’s not optimized for satellite imagery. This algorithm took about a minute to run on a “cloud GPU.” Generated image (1 MB).
The fourth, Gigapixel, uses a proprietary algorithm to sharpen photos; it also isn’t optimized for satellite imagery. This algorithm took about an hour to run on a CPU. Generated image (6 MB).
The fifth, Google Maps, reflects actual high-resolution (my guess is around 3.7 meters per pixel) photography.
Discussion
To my eye, the Gigapixel enlargement looks sharpest; it plausibly adds detail, though I don’t think anyone would mistake it for an actual 2.5-meter resolution satellite photo.
The stock ESRGAN enlargement doesn’t look quite as good to me; however, in my opinion, ESRGAN offers a lot of potential if tweaked. The algorithm already shows promise in upscaling video-game textures–a use the algorithm’s creators didn’t envision–and I think that taking the existing model developed by the researchers and training it further on satellite photos could produce higher-quality images.
One problem with using satellite photos as the base for historical maps involves dealing with modern features: agriculture, cities, roads, etc., that weren’t around in the same form in the time period the historical map is depicting. Machine learning presents a solution for this problem, as well; Photoshop’s content-aware fill allows you to select an area of an image for Photoshop to plausibly fill in with similar content. For example, here’s the Gigapixel-enlarged image with human-created features removed by content-aware fill:
I made these edits by hand, but at scale you could use OpenStreetMap’s land-use data to mask candidate areas for content-aware replacement:
Conclusion
If you want to work with satellite imagery to produce a high-resolution basemap for historical or Bible maps, then using machine learning both to sharpen them and to remove modern features could be a viable, if time-consuming, process. The image in this post covers about 100 square kilometers; modern Israel is over 20,000 square kilometers. And this scene contains a mostly undeveloped area; large-scale cities are harder to erase with content-aware fill because there’s less surrounding wilderness for the algorithm to work with. But if you’re willing to put in the work, the result could be a free, plausibly realistic, reasonably detailed map over which you can overlay your own data.
The problem with using satellite photos for Bible (or other historical) maps lies in their photographic nature–they present the world as it is, with modern cities, agriculture, land use, and other infrastructure that didn’t exist in the ancient period that the maps are depicting. However, satellite maps are useful in showing “true-color” views and revealing features like transitions from deserts to wetlands.
If you’re not using satellite photos for the Bible maps you’re creating, you’re using other data, like elevation; indeed, with only elevation data, you can produce a variety of map styles. Shaded relief shows hills in a naturalistic way, approximating the look of satellite images. A hypsometric map, where the map color changes with elevation, also depicts this data, though I would argue that hypsometric maps can be misleading if they transition from green colors at low elevations to brown colors at higher elevations, since people have become used to satellite photos with these colors as depicting land cover.
The main problem with relying on elevation data (a digital elevation model, or DEM) is its relatively low resolution; until 2015, a 90-meter resolution (i.e., one pixel of elevation data corresponds to an approximate square 90 meters by 90 meters) was the highest resolution freely available worldwide (well, mostly worldwide). In 2015, the SRTM worldwide elevation data became available at a 30-meter resolution, or 9 times higher resolution than previously. Also in 2015, similar ALOS 30-meter data became available. If you’re willing to pay tens or hundreds of thousands of dollars, you can also find proprietary elevation data at resolutions of 5 meters. Most of us aren’t in a position to pay that kind of money, however, so I’m interested in free data.
Bible atlases produced before 2015 almost certainly use the coarser 90-meter resolution, while Bible atlases produced since (though as of late 2018 I’m not aware of any) would likely use the 30-meter resolution and can zoom in much further without becoming blurry.
However, 30 meters feels rough compared to the satellite imagery available in Google Maps, which is often at 30 centimeters. Even free imagery from the European Sentinel-2 project is available at 10 meters, or 9 times higher resolution than 30 meters.
DEM Enhancements
The question I have is whether it’s possible to enhance a 30-meter DEM to bring it closer to the high resolution that Google Maps is training us to expect on maps everywhere.
To answer that question, I turned to Terragen, 3D modeling software designed to render photorealistic landscapes. (I actually tried several different programs, but Terragen was the least confusing.) Terragen and similar programs procedurally improve resolution by adding fractal enhancement–in other words, they extrapolate from the available data to add plausible, if fake, detail. My process was the following:
Find a high-resolution DEM to use as a reference for the output of the process.
Downsample the DEM to 30-meter resolution to match the DEM available worldwide.
Enhance and style the DEM in Terragen to mimic a satellite photo.
Compare the output.
The U.S. Geological Survey has started making elevation data available at a 1-meter resolution for select parts of the United States. I picked a desert area near Dayton, Nevada, that roughly matches the terrain of ancient Israel (since Israel will probably be the subject of most Bible maps).
I converted the USGS .img file into a geotiff using gdal_translate and resampled it to 30-meter resolution using gdalwarp -tr 30 30 USGS_NED_one_meter_x27y436_NV_Reno_Carson_QL2_2017_IMG_2018.img nv-30.tif.
The result was two tiffs that I imported into Terragen. After that, I spent some time coloring and styling them, with the below results:
This image shows 1-meter shaded relief, 30-meter shaded relief with blurry bicubic resampling, 10-meter publicly available satellite photo that I slightly retouched, 1-meter colored and enhanced in Terragen, 30-meter colored and enhanced in Terragen, and the Google Maps view for this area.
I feel like the 30-meter Terragen view, which is what you could plausibly produce for Bible maps, looks pretty OK, actually–though a trained 3D artist would do better. The 1-meter data, while accurate, reproduces modern features like the road on the right side, which is unhelpful for Bible maps–mitigating modern features is the one of the main points of this exercise. While the 30-meter view doesn’t have all the detail of the 1-meter version, the rendering feels plausible to me.
Of course, “plausible” doesn’t mean “accurate,” and there’s the question of whether it’s ethical to enhance terrain in this way–you’re essentially inventing detail that doesn’t exist in the source data, which could mislead someone if they believe that the detail reflects reality. It depends how far you want to push the idea that all maps are in some way plausible fictions.
Scaling Up
What’s needed to implement this technique in production?
A base map to use for coloring (I’d use Natural Earth II–I tried it in the Nevada scene and think it could work–but you could also use satellite imagery or your own colors).
A way to export and reproject the finished product. My free version of Terragen can only export images 800 pixels wide; you’ll probably want to export them at over 10,000 pixels wide. And then you’ll need to stitch them together and reproject them to Web Mercator to display them in online mapping applications.
A way to layer the images with other data (such as bodies of water and labels).
A delivery mechanism (probably tiles over the Internet, as with Google Maps and most mapping applications).
Conclusion
This approach represents a plausible way to improve the resolution of Bible maps or other historical maps using only publicly available, free data. Although it creates some ethical problems, with proper disclosure it could potentially be a useful way to make Bible maps more compelling and zoomable.
Google yesterday announced that they’ve expanded their street view functionality throughout Israel, including a number of sites that you’d visit on any tour of the Holy Lands. Of particular note are the archaeological sites they walked around and photographed. Here, for example, is Megiddo:
Previously available were many places in Jerusalem, like the Via Dolorosa. But the new imagery covers much more area–I can imagine it being particularly useful in Sunday School and classroom settings, where a semi-immersive environment communicates more than static photographs.
The Pelagios Project has produced a lovely zoomable map of the Greco-Roman world. Below, for example, is a static view of Israel during the Roman period.
A blog post about the map discusses how they created it (plus bonus technical background). I’m most impressed by how attractive the maps are—a lot of online maps present you the data but don’t try to be beautiful; this map succeeds on both counts.
More generally, the Pelagios Project, which I admit I hadn’t heard of before today, incorporates linked data to help people study the ancient world. It encompasses a variety of efforts (need to search for an inscription from ancient Palestine? No problem)—it’s all fascinating.
(Note the “Mortuum Mare” instead of the “Dead Sea.”)
Stanford University recently unveiled ORBIS, a site that lets you calculate the time and cost required to travel by road or ship around the Roman world in A.D. 200. It takes into account a lot of factors—my favorite is that it models ancient sea routes based on historical sources and wave height.
The apostle Paul went on three missionary journeys from A.D. 46 to 57, traveling around much of Asia Minor and Greece. In 60, he was also taken to Rome. ORBIS allows us to calculate how long these journeys would have taken in pure travel time (excluding time spent at each destination) and how much they would have cost.
Journey
Distance (miles)
Travel Time (days)
Cost per Person (denarii)*
First
1,581
53
237
Second
3,050
100
314
Third
3,307
92
481
Rome
2,344
36
699
* Ship travel only. According to Wikipedia, the denarius from 200, used here, is roughly 22% weaker than a denarius from the mid-first-century.
I conclude a few things from this exercise:
The journeys get progressively costlier as more of each journey happens by ship. Sailing is fast but expensive—of course, Paul and his companions may not have had to pay the full fare.
Not much of the route of Paul’s journey is in doubt—Luke describes the trips pretty precisely in Acts. About the only question is whether Paul traveled from Berea to Athens by ship or by road. The above costs follow the ESV Study Bible and assume it was by ship.
Robert Rouse combines Bible geo data with Tableau to produce an interactive map that uses size to emphasize important places and allows you to filter the data by book:
Bible Places
He ‘s also written a blog post that goes into detail about the map. The blog is about technology and the Bible, so take a look at his other posts if those topics interest you.
Posted in Geo | Comments Off on Bible Geography in Tableau
The Google Static Maps API is a way to get all the nice imagery of Google Maps without incurring the interactive overhead. It’s useful in situations where, like an atlas, you just want to show a static image. Until yesterday, you could only get street maps in the Static Maps API.
This change benefits you—you always see up-to-date imagery—and it’s easier for me, since I don’t need to regenerate images if the locations change.