![\"\"](\"https://s3.us-central-1.wasabisys.com/oldinsurancemaps/uploaded/markdownx/43e36b6a-c349-4aba-9119-1ea04fde9931.png\")
\n\nThis feature was joint-funded by Wayne State University Libraries, the Leventhal Map & Education Center at the Boston Public Library, and the American Geographical Society Library, at UW Milwaukee. A big thank you to these orgs for funding improvements that make the site better for everyone!
\n
Over the latter part of the summer I was able to add a feature to OldInsuranceMaps.net that greatly enhances its mosaic-making capabilities, and is the logical continuation of the multimask interface.
\nUsers can now queue the creation of single-file mosaics for volumes after the masking is complete, making it much easier to produce the full complement of distribution formats and web services. Links to all these formats, and to trigger the mosaicking processes, are now in the Mosaic > Derivatives section of each map’s summary page.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/7b70e021d6.png\")
\nThe creation of these mosaics is managed through a new jobs system that allows us to queue mosaics for creation without having to manually trigger them from the backend (which is what I was doing before).
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/6dd94591ec.png\")
\nCheck out the documentation to jump straight into learning how to use it.
\nThe multimasking concept only gets you so far. You can make contiguous masks for all content in a volume, but then you are still left with 100 individual layers, like this example of Detroit, Mich., 1897, vol. 2,:
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/5a9f4775dc.png\")
\nIt’s actually much more useful to combine those layers into a single file, making it easier to display and distribute the mosaic in new formats—like a single tile service endpoint for the whole volume, or as downloadable file for use in desktop GIS software.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/8eb3a754ff.png\")
\nAnd while I had already scripted these functions, before this update I would just wait for someone to email saying they had finished masking the layers and it was time to make a mosaic. So with a trio of organizations interested in making a lot more mosaicked exports for use in their own web applications, it was a good time to try out something new.
\nCreating these files is not that complicated to do; a mask is applied to each layer via a virtual raster (VRT), and each of those is added to one final mosaic VRT and then exported to one big GeoTIFF. But, it can take many hours, and they can get pretty big; the one shown above is about 400mb but they could easily be 2-5 times that size, depending on the geographic extent of all the layers to be combined. So I made a fairly basic queuing system, using Celery, a package I was already using to handle background tasks like warping and cleaning up abandoned georeferencing sessions.
\nIt works like this:
\nqueued , running, completed , or errored.queued.main celery worker now checks, every minute, for queued jobs, and starts them in the order they were queued (first in, first out).mosaic celery worker is now dedicated to only running the actual mosaic processes, so when the main worker kicks the job off, its the mosaic worker that actually performs the task.\nI was dubious about the feasibility of kicking off tasks in one worker from another, but it works great, actually. Again, more detailed info is available in the docs.
\nAlso, because it is easy to swamp the server with multiple mosaic processes running at once, the current configuration will work through the queue uninterrupted but only allow two jobs to run concurrently.
\nThe appeal of setting this all up was not only to make it easier to generate mosaic COGs, but for the particular application we had in mind we also needed static XYZ tilesets that could be uploaded to an external storage bucket. So, once the job running framework was in place, I just slotted in a different function to build tilesets instead of COGs. In the future, we hope to add PMTiles output to the mix as well.
\nThere is actually a lot of variability from job to job, in terms of how long it will take and the size of the output file.
\nFor example, as I write this, one particular job has been running for 16 hours! This is not ideal, and it’s due only to the fact that this particular volume covers peripheral parts of a Oklahoma City, so the layers are spread out across a really wide geographic extent, and there is a huge amount of blank space in between.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/d2a9acef60.png\")
\nThis means that the process takes forever, and the resulting GeoTIFF will be really, really large, and mostly empty on top of that :/ So, there are surely better approaches for edge cases like this, and maybe down the road we’ll add better ways to handle them. (A static XYZ tileset, or PMTiles file, would be a more efficient way to store this layer.)
\nIt would be good to actually display the size of these files as well, so people would have a better idea of what they were about to generate, or, later, download.
\nFor now, there is a group of users with the ability to trigger mosaic jobs on any maps, but all users can do so on maps that they have “loaded”. So if you had requested maps of a city to work on, loaded it, have georeferenced everything (that you can figure out), and completed the multimask, you can go ahead and queue the creation of a mosaic for that volume.
\nLet us know how it goes! Join the OSM US Slack (introduce yourself in the #welcome channel!) and find us in the #oldinsurancemaps channel.
\n", "date_published": "2026-10-01T11:31:00-05:00", "url": "https://blog.oldinsurancemaps.net/2026/10/01/introducing-usertriggered-mosaic-generation/", "tags": ["tech"] }, { "id": "http://oldinsurancemaps.micro.blog/2026/08/25/joining-the-osm-us-charter/", "title": "Joining the OSM US Charter Project program", "content_html": "An exciting and important update: I’m very pleased to announce that OldInsuranceMaps.net is now officially a Charter Project of OpenStreetMap US! OSM US is a US-based non-profit that supports the community of mappers around OpenStreetMap, as well as numerous tools and websites related to open mapping efforts. As part of the Charter Project program, OldInsuranceMaps.net is now affiliated with OSM US’s 501(c)(3) status, which not only makes it possible for people and organizations to make tax-deductible donations, but will further open the door to more grant opportunities and partnerships down the road. Also, OSM US already includes two other fantastic community-focused history projects, OpenHistoricalMap and Yesterdays, so joining the network brings a multiplier effect to this whole digital public history stack.
\nAnother change I’m especially looking forward to is that as a Charter Project, we need to have an Advisory Board to guide the direction of our work going forward. While I’ve enjoyed being in charge of everything, mostly, the project and its community continues to grow and the landscape around it continues to change so it will really strengthen the whole effort to have a wider range of stakeholders involved with decision-making.
\nI’m happy to say that Riley Champine, Associate Director of the Digital Scholarship Lab at the University of Richmond has agreed to join the Advisory Board, so for now it will be the two of us, with plans to add another member within a year. Since the fall of 2023, Riley has led a massive effort using OIM, which, as part of an NIH-funded research project led by the University of Michigan’s Institute for Social Research, has had dozens of DSL students georeferencing tens of thousands of Sanborn maps. Riley is an enthusiastic mapper and cartographic storyteller and it will be wonderful to have him aboard. Welcome, Riley!
\nWell, stay tuned! We have some organizing to do and plenty of good tickets to work on for now… But this move to OSM US will cause no changes to how people can access and contribute to the platform.
\nIn the meantime, we would love to hear from you in the #oldinsurancemaps channel of the OpenStreetMap US Slack, on Bluesky or the Fediverse, or just write a good old-fashioned email: hello@oldinsurancemaps.net.
\nWhen I started this project in grad school, I didn’t set out to create something that would exist long-term. I wanted to try building a new approach to crowdsourced historical map georeferencing, and then test it out on a set of maps that I had long admired, old fire insurance maps. Since then, and especially over the past few years, the whole thing has turned into something that I now think does deserve a permanent home, due not so much to my own efforts as to the wide range of personal and institutional interest that the project has drawn from people around the country.
\nI have always seen OIM as an engine for open data, community engagement, and research, rather than a commercial endeavor, and likewise hoped that the next chapter of the project could retain these values. As I’ve gotten to know the OpenStreetMap community, through OpenHistoricalMap, Yesterdays, and all the people these projects have brought to OIM, I’ve found plenty of overlap in the OSM US ethos with what I had always envisioned for the project. Plus, as a national organization full of technical resources and smart, energetic people, I couldn’t be happier for OSM US to be the foundation for whatever comes next.
\nFinally, I’d like to acknowledge the many partnerships that have given this project life, especially the ISR / DSL teams for hosting and development funding, and the Midlo Center here in New Orleans whose collaboration has made it possible to get people together for georeference-a-thons and some good old fashioned local history fun. Many more of these to come!
\nAlso, the individuals (hopefully some are reading this) who have gotten in touch over the years to either donate a bit of money or just send encouraging words. Even the shortest emails like “as an amateur local history geek, I find this work amazing” meant a lot, especially early on when things were slow.
\nThis is all to say that if you have ever sent some money over, been part of an event, or even just said something positive about the project, in those moments you became part of it and helped make it better. So thank you! Forward!
\n![](\"https://cdn.uploads.micro.blog/280698/2026/2026-08-oim-blog-header.jpg\")
\n",
"date_published": "2026-08-25T15:07:11-05:00",
"url": "https://blog.oldinsurancemaps.net/2026/08/25/joining-the-osm-us-charter/",
"tags": ["news"]
},
{
"id": "http://oldinsurancemaps.micro.blog/2026/07/28/testing-the-waters-with-gcp/",
"title": "Testing the waters with 2 GCP georeferencing (Helmert!)",
"content_html": "In OldInsuranceMaps.net it is now possible to georeference maps with only two ground control points, instead of the previously required three. For the time being though, we’re keeping this capability hidden (more about that in this discussion and below), but I wanted to write a good summary here of how it works and why it is beneficial. Thanks to Dan VK for requesting this functionality in a Github ticket, and helping out along the way to streamline some of the code. I’d been wanting to try to figure this out at some point, so this was a good push in the right direction.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/5d407a3987.png\")
\nTo georeference a scanned historical map, you must create ground control points (GCPs) that link locations on the map with real-world coordinates. Then, these GCPs are fed through a transformation algorithm which results in a warped image. The QGIS documentation has a good summary of the most common algorithms, including those mentioned below.
\nWith three or more GCPs, OIM defaults to using the Polynomial (1st order) (a.k.a. “affine”) transformation, which rotates and skews the image to match the control points while still retaining the internal integrity of the original document. The example below shows this, with three good GCPs and one bad one (in blue) added to cause the image to skew for illustrative purposes.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/e537a449c8.png\")
\nOIM also supports the Thin Plate Spline transformation, which will mush the map every which way to make it fit any GCPs you give it. Consider how the same map and GCPs from above produce a very different and much more distorted warped output when you use Thin Plate Spline.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/ac4b9ad413.png\")
\nHowever, these two transformations require three or more GCPs, but now a third transformation, Helmert, can be performed with only two (this is the new thing!).
\nWell, it’s not always possible to create three GCPs that are well-distributed across a page, because some split map pieces are too small, or only have linear features, or are in areas that have changed too much since the map was drawn.
\nHere’s a good example in the form of a warehouse in Alexandria, La., from 1896:
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/e970342c56.png\")
\nThere are three intersections here, Casson with 5th, 6th, and 7th streets, but they are all in a row which is not helpful for Polynomial or Thin Plate Spline. But, using just two of these intersections with the Helmert transformation we can get a good fit:
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/blogimage.jpg\")
\nGoing further, we can combine Helmert with a reference layer of adjacent georeferenced layers to get some pretty impressive (if, perhaps, questionable??) stitching. To illustrate, in the following image the upper layer has already been georeferenced, and we are looking to georeference a new layer below it. But the area of the layer has no good GCP matches when looking at today’s aerial imagery or street map.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/49574d926b.png\")
\nHowever, as is fairly common with Sanborn maps, on the bottom edge of the upper layer there are buildings outlined that are also represented on the layer we are looking to georeference. We can make two GCPs based on these overlapping building corners.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/639f1a3fc9.png\")
\nEven though these are only two GCPs, tucked away in the top corner of the image, using Helmert they are enough to allow us to georeference the entire map as it lays out down the street.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/e4686ec23b.png\")
\nPretty cool! This would be especially helpful in places where there has been significant urban development, or on the edges of small towns where old sawmills have returned to being forests.
\nFor now, we are keeping Helmert somewhat hidden in the interface, and this is mainly because if you only use two GCPs, it’s easy to make something very quickly that may look good at first, but would actually be greatly improved by even one or two more GCPs and use of the Polynomial transformation. Also, it can be very finicky because, considering an example like that shown above, even very small adjustments on one of the points will cause big swings in the location of content on the far side of the page.
\nBut I think it’s worth exploring further and making more accessible, so, if you have thoughts about this or opinions on best practices for georeferencing, we’d love to hear them! Add to this Github discussion, or join us on the OpenStreetMap US Slack in the #oldinsurancemaps channel, where we’ve talked about this a bit already.
The rest of this post will go further into how it all works anyway.
\nImplementing the Helmert transformation was more challenging than I expected it to be. OIM uses GDAL’s Python bindings on the backend, which (essentially) take in GCPs and allow you to specify which order of polynomial to use, or alternatively to use thin plate spline. Then, a warped image is produced. Easy.
\nBut there is no switch to flip to tell GDAL to use Helmert, so I had to create a custom proj pipeline instead and pass that to the warping operation. That pipeline is where you provide Helmert its four parameters, so once the plumbing was set up to get the pipeline working, it was time to figure out how to calculate those parameters, based on two input GCPs.
\nEach GCP is a linked set of two coordinate pairs, one is the x, y pixel location on the original image in pixel space, and the other represents the latitude/longitude of a real-world location in coordinate space. More specifically, coordinate space is the projection you are using (in this case, Web Mercator), so another way to think of it is that there are two flat grids, one is the original image where each pixel is represented by an x,y coordinate, and the other is the target map projection.
\nBy comparing the values of the two GCPs, we need to come up with the following parameters, which the Helmert transformation will use to transform pixel space into coordinate space:
\nIf you understand that these parameters are all that Helmert needs, it’s not actually so hard to visualize exactly how the transformation takes place:
\nAt this point, we can imagine the image would be properly resized and rotated but without the final two parameters it will remain stuck at 0,0 in coordinate space. In the Web Mercator projection, 0,0 equates to latitude = 0, longitude = 0, or null island off the western coast of Africa. So…
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/4788acc799.png\")
\nOriginally, I calculated each of these parameters one by one with some math and trigonmetry that would have made my high school math teacher proud. But there were a couple of limitations with how I had set things up, and after I added some tests, Dan VK contributed work that simplified the logic significantly by using a single numpy function instead of all the individual calculations. Turns out this one function returns everything we need!
\nOverall, even beyond the immediate benefits that this particular transformation bring, this was a very worthwhile foray into some of the more nitty gritty aspects of georeferencing and transformations, and I look forward to working on more improvements like this in the future.
\n", "date_published": "2026-07-28T08:39:42-05:00", "url": "https://blog.oldinsurancemaps.net/2026/07/28/testing-the-waters-with-gcp/", "tags": ["news"] }, { "id": "http://oldinsurancemaps.micro.blog/2026/05/31/openstreetmap-account-authenication-added/", "title": "OpenStreetMap account authenication added", "content_html": "New feature on OldInsuranceMaps.net: authentication via OpenStreetMap! A special thank you to OpenHistoricalMap for helping to fund this development :).
\nAs a new user to OIM, you can connect through OpenStreetMap right when you first sign up, or, if you are already logged into your OIM account, you can easily make a connection to your OSM account. You can read more detailed instructions in the documentation.
\nAnd for more detailed information about the change to the code, checkout the pull request.
\nI know it’s a very common feature nowadays to be able to login through an external sites like Google or Facebook when creating new accounts, but I hadn’t yet waded into figuring it out on OIM… frankly all of those login through other accounts buttons have always confused me. On the other hand, creating a new password for every website you visit is really really annoying (and leads to a slippery use-the-same-password-everywhere slope), so I knew that 3rd-party authentication was something I would eventually need to add to the site.
\nAs the user base of OpenStreetMap, and more specifically, OpenHistoricalMap, has been increasingly overlapping with OldInsuranceMaps.net, I’m very happy to be able to add something that further eases user connections between the platforms. I’ll be doing a 5-minute lightning talk about this at State of the Map US (Friday afternoon) in under two weeks, so be sure to say hello if you are there!
\n", "date_published": "2026-05-31T18:54:39-05:00", "url": "https://blog.oldinsurancemaps.net/2026/05/31/openstreetmap-account-authenication-added/" }, { "id": "http://oldinsurancemaps.micro.blog/2026/05/18/recap-may-georeferenceathons-in-new/", "title": "Recap: May Georeference-a-thons in New Orleans", "content_html": "We had two successful and enjoyable georeferencing events earlier this month in New Orleans, thanks again to everyone who came out! About 20 people across the two Tuesday nights. Next time around, we’ll finally mix up the schedule a bit so more people can make it out.
\nBeyond georeferencing over 150 of pages of the Vol. 3, 1896 and Vol. 1, 1908 volumes (special shoutouts to Cacomixl, scanlan, and ngoddard!!) , we also had a few short presentations about research that folks have been working on recently. On the first night, Alice Blackwell talked about what she had learned about her block in St. Roch by looking at Sanborn maps, and Mike Godzinski showed architectural photos he’s been taking while walking the quiet residential streets of Uptown.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/pxl-20260513-010653290-crop.jpg\")
\nOn the second night, Alexander Trapps-Chabala presented the geneaological research he’s been diving into about his ancestry (with a dazzlingly comprehensive set of points in Google Earth!) and how it connects the Cane River area around Natchitoches with the 12th Ward neighborhood we had been georeferencing that evening.
\nA big thank you to everyone who shared their work with us! And to Elizabeth, HistoryForge, and the Midlo Center for making these connections happen.
\nHaving these short, informal presentations really elevates the events by not only giving us all something to listen to while we work on maps, but also starting conversations where people can get to know each other and learn more about the city we live in (and beyond).
\nThanks as always to Second Line Brewing for letting us use their side room!
\n", "date_published": "2026-05-18T12:30:00-05:00", "url": "https://blog.oldinsurancemaps.net/2026/05/18/recap-may-georeferenceathons-in-new/", "tags": ["news"] }, { "id": "http://oldinsurancemaps.micro.blog/2026/04/30/georeferenceathons-historyforge-new-orleans-umd/", "title": "Georeference-a-thons! HistoryForge (New Orleans), UMD, and UIUC", "content_html": "Here in New Orleans we are looking forward to two georeferencing events coming right up! For the next two Tuesdays (May 5th & 12th) we’ll be partnering with HistoryForge to host georeference-a-thons at Second Line Brewing, just like we’ve done in the past; these will be our 7th and 8th events here!
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/georeferenceathon2026-thisone-wlink.png\")
\nThese are fairly informal gatherings, with an intro and demo at 6:30, and then socializing and georeferencing to follow. We also hope to have a short presentation about areas we’ll be working on (8th Ward and 12th Ward), though are still ironing out those details.
\nIf you are in the area and would like to attend, please RSVP here: tiny.cc/georef looking forward to seeing some of you next week!
\nI’d also like to highlight a couple events that other groups have held recently.
\nAt University of Minnesota Duluth, Laure Charleux put together a public history workshop as part of the Twin Ports Festival of History. The event featured not only map georeferencing with OldInsuranceMaps.net, but also a historical photo tagging activity, which proved to be especially popular with attendees! Laure and her students are working on multiple digital history projects here: Duluth Historical GIS.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2026/c5b32e12c7.jpg\")
\nMembers of the Healthy Regions and Policies lab at University of Illinois, Urbana-Champaign put together a Friday evening map-a-thon as part of the Engineering Open House, 2026. Continuing to work on maps in their area, the group completed the Urbana 1909 atlas (almost 30 layers) as well as maps of some other small towns in the area. Thanks to Gabi, Anya, Marc, and especially Cat for putting this event together!
\nIf you or your organization would like to use OldInsuranceMaps.net to facilitate an event, don’t hesitate to get in touch! I’ve also drafted a page describing these events in general. A comprehensive list of all past events is still in the works though…
\n", "date_published": "2026-04-30T17:14:57-05:00", "url": "https://blog.oldinsurancemaps.net/2026/04/30/georeferenceathons-historyforge-new-orleans-umd/", "tags": ["news"] }, { "id": "http://oldinsurancemaps.micro.blog/2026/04/25/codelib-video-links-and-other/", "title": "Code4Lib 2026 - Video links and other notes", "content_html": "Early last month I attended Code4Lib 2026 in Philadelphia, and gave a presentation called Old Maps for New Apps: Making and Using Georeferenced Sanborn Maps at Scale. It was a short one, 10 minutes, and while at first I thought I would be too pressed for time to give a full overview of OldInsuranceMaps.net to a new audience, I changed things around from how I usually do them and I’m really happy with how it turned out. Per Code4Lib norms I’ve made my slides available on Zenodo.
\nI also facilitated an after-conference workshop, Running a Community Georeferencing Event, and five people came to learn about how OIM can be used for collaborative work at community events. We worked on Camden, N.J., 1885, and also a bit on Helena, MT, 1888 where one of the attendees was from. Shoutout to kcamanch1 for completing Camden even after we finished the workshop!
\nIt was my first time at Code4Lib and I really enjoyed it! As I don’t work in a library many of the talks were not especially relevant to my day-to-day endeavors, but I did like seeing topics discussed that I had learned about in grad school, like BibFrame and EAD, and of course the ever-present dilemma of how to handle all of these bot scrapers… I especially enjoyed Brandon Nightingale’s keynote about digitizing historical newspapers at the Black Press Archive (Howard University). “Digitizing is not passive work, it is architecture”, i.e. the structure of a digital archive determines how useful it can be in the future. This is an approach to the work that certainly resonates with me.
\n", "date_published": "2026-04-25T17:39:07-05:00", "url": "https://blog.oldinsurancemaps.net/2026/04/25/codelib-video-links-and-other/", "tags": ["presentations"] }, { "id": "http://oldinsurancemaps.micro.blog/2026/04/03/last-month-i-presented-at/", "content_html": "Last month I presented at #Code4Lib: www.youtube.com/live/6nBJ… While preparing the slides, 10 minutes was feeling really short (especially for a new audience) but I reworked some things and I think it’s actually the best introductory talk about the project I’ve given!
\n", "date_published": "2026-04-03T09:20:46-05:00", "url": "https://blog.oldinsurancemaps.net/2026/04/03/last-month-i-presented-at/" }, { "id": "http://oldinsurancemaps.micro.blog/2026/03/02/newsletter-winter-pt/", "title": "Newsletter: Winter (pt 2)", "content_html": "This email is (hopefully) finding you via my new setup on Micro.blog. So, so you’ll see a different “from” address. Most importantly, unlike before, you cannot reply directly to this newsletter to get in touch. Please write separately to hello@oldinsurancemaps.net.
At the very end of January I co-led a workshop during OpenStreetMap US’s virtual Mapping USA conference, Historical Mapping with OpenHistoricalMap, OldInsuranceMaps.net, and Yesterdays. These are three community-focused history projects that all swirl around the OpenStreetMap ecosystem, and
\nI’m in Philadelphia this week presenting at Code4Lib 2026. If you happen to be attending, make sure to say hello! If not, all the presentations will be streamed on YouTube (more info here), so you can tune in around 9:30 am Eastern Time on Tuesday (tomorrow) to see me. Really looking forward to this!
\nI’ll also be doing a workshop on Thursday about hosting georeference-a-thons, and this will ultimately yield more information on the main website about that topic, so stay tuned for that.
\nEarlier this month someone posted OldInsuranceMaps.net on HackerNews, which was exciting and just a bit stressful, 4,000 visitors in one day, about 100x the normal numbers! Overall it seems like the site held up pretty well, and it was fun to answer some questions in the ensuing discussion.
\nWe have a new code contributor, the first in many years! Josiah added some RSS feeds to the platform, so you can track activity on any maps within a given place. If you haven’t heard anyone mention RSS in the last 10 years, you aren’t alone. It is a protocol for publishing news feeds, but now we just get email notifications for everything. If you are interested in keeping track of what’s going on in OldInsuranceMaps.net without going to the website every morning, then find your place of interest here and click the RSS icon in the top right to get the feed URL. I expect we’ll be making updates to this over the next few months, so please reach out if you have any ideas or feedback.
\n", "date_published": "2026-03-02T08:49:38-05:00", "url": "https://blog.oldinsurancemaps.net/2026/03/02/newsletter-winter-pt/", "tags": ["newsletter"] }, { "id": "http://oldinsurancemaps.micro.blog/2026/01/27/upcoming-mapping-usa-and-codelib/", "title": "Upcoming: Mapping USA and Code4Lib", "content_html": "This coming Saturday at 1pm CST I’ll be co-presenting in a workshop at Mapping USA, a free virtual conference organized by OpenStreetMap US. The workshop, Historical Mapping with OpenHistoricalMap, OldInsuranceMaps.net, and Yesterdays will feature demos from me, Jeff of OpenHistoricalMap, and (particularly excitingly) Jacob and Mike from the new project Yesterdays. We’ll be showing how all of these crowdsourced applications are interrelated, for example, how georeferenced maps OldInsuranceMaps.net have been integrated directly into Yesterdays.
\nRegistration is free, so come join us online this Saturday afternoon!
\nI also have a presentation and workshop coming up at Code4Lib 2026 in Philadelphia. This will be my first time at this conference, so I’m especially looking forward to meeting new people in the library world.
\nThis workshop will be the first time I have designed and presented materials specifically about the “georeference-a-thons” that we here in New Orleans and folks at a number of other organizations have held over the last few years. Preparing for this workshop will yield more documentation and materials around that part of the website, so stay tuned for more updates.
\n", "date_published": "2026-01-27T13:16:21-05:00", "url": "https://blog.oldinsurancemaps.net/2026/01/27/upcoming-mapping-usa-and-codelib/", "tags": ["presentations"] }, { "id": "http://oldinsurancemaps.micro.blog/2025/12/27/blog-migration-completed-ive-consolidated/", "content_html": "Blog migration completed! I’ve consolidated all past blog posts and newsletters into this single feed on @micro.blog , and replaced the existing blog site at blog.oldinsurancemaps.net. Looks like some strangeness remains with dates on migrated past posts, but overall, success.
\n", "date_published": "2025-12-27T22:52:41-05:00", "url": "https://blog.oldinsurancemaps.net/2025/12/27/blog-migration-completed-ive-consolidated/" }, { "id": "http://oldinsurancemaps.micro.blog/2025/12/12/winter-newsletter/", "title": "Newsletter: Winter 2025", "content_html": "Herein: Updates on the future of OIM, some good ol' tech improvements, new blog post, and community notes. For new readers, welcome! And here are all past newsletters in case one isn’t enough.
\nIn mid-January, I will be leaving my position at the Healthy Regions & Policies Lab where I have been for the past 2½ years, leading or contributing to elements of meaningful efforts like the SDOH & Place Project, OEPS, and Chives). I’ve worked with wonderful people and learned a LOT, but plan now to return to freelance consulting for a bit through my own company Legion GIS, and figure out what comes next.
\nWith that in mind, I’m beginning to lay the groundwork for upgrades and enhancements to OldInsuranceMaps.net, and in the new year will be looking to 1) solicit one-off funding for specific efforts, and 2) create a new sponsorship model to provide more sustained support. As always, I am also open to larger institutional funding and collaborative opportunities.
\nRoadmap, a.k.a. wishlist:
\nIf you or your organization would like to help make one of these happen (or have other ideas), please get in touch! You can reply directly to this email.
\nThe home page now includes a new section, who uses this platform?. I encourage you to check it out, as the list was longer than I even thought (over a dozen orgs and many individuals) and it was gratifying to put together. There are a few other in-progress collaborations that I hope to add soon.
\n
I made a few small improvements to the interface that you can use to trim margins of adjacent georeferenced layers, which I call a “multimask” within the platform. Checkout this recent blog post (Re)Introducing the Multimask Interface to learn more about how this works (it has a bunch more animated gifs too!).
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/mm-add-mask.drvyhwq7-1sai7v.webp\")
\nEvery time we have a georeference-a-thon, some rogue georeferencer or especially competitive couple asks if there is a leaderboard. There kind of was, just a list of all users with numbers on the platform, but it was an old page and took forever to load. Moreover, it always ended up with Ibrahim or Nate or WallyKitty at the top which (while impressive!!) wasn’t very useful for events where new folks were working on one map all together.
\nSo now there is a Stats table scoped to each Map, which you can find within the Summary section. I’m sure this will evolve over time, but for now it is a fun, quick (and sortable) way to see who has been working on content. Also, that original profiles page is now a lot faster.
\n![\"\"](\"https://s3.us-central-1.wasabisys.com/oldinsurancemaps/uploaded/markdownx/aeefa228-7307-4816-8df0-029a6279df14.png\")
Since the beginning, I’ve deliberately not gamified this platform. I figured why not see how far we can get without all of that. That said, there is a side of seeing this information that tells the story of who has done the work, which is a core tenant here, so I do hope to add more elements like this in the future. Who knows, maybe we’ll have georeferencing capitáns at some point too.
\nI implemented TiTiler on AWS as a Lambda service, rather then running it in a Docker container on the main server. If any of that makes sense to you, you are probably just surprised it wasn’t already setup that way. Well, now it is!
\nThere are still more tweaks to make (thanks for the tips, Eliot!), but already you should notice that the mosaic previews with 100 layers will load those layers all at once, instead of incrementally which was one of the limitations that came with the previous setup, and kind of a drag.
\nIn mid-September, in collaboration with the Midlo Center for New Orleans Studies we held two back-to-back georeference-a-thons here in New Orleans, and our usual location of Second Line Brewing. Over the course of two evenings, about 30 people came, with only one person coming both nights (shoutout scanlan!). We worked on New Orleans, 1896, vol. 2, and vol. 4. The latter was especially fun because we split the tables into Carrollton, Gretna, Algiers, and 9th Ward.
\nA huge thanks to everyone for coming out! We focused on these volumes in particular because the UNO archaeology crew had just done work in Duncan Plaza, so Elizabeth shared some slides about the research and what they had found.
\n![\"\"](\"https://s3.us-central-1.wasabisys.com/oldinsurancemaps/uploaded/markdownx/a390427e-898f-4bda-a6a2-3aa4a32c722c.png\")
A small and mighty team, MapRVA is an OpenStreetMap group in Richmond, VA, and a few months ago they began developing a new community project called Yesterdays. It is a fantastic crowdsourcing application for geolocating historical photographs of Richmond. They have already placed 5,000 photos!
\n![\"\"](\"https://s3.us-central-1.wasabisys.com/oldinsurancemaps/uploaded/markdownx/473ebfdb-12d8-4ed9-b494-35da8c011130.png\")
I learned about Yesterdays when they incorporated mosaics of Sanborn maps made in OldInsuranceMaps.net directly into their interface, which has proved an essential point of reference for placing historical photos. They’ve done more georeferncing since to add more layers–John just georeferenced all of 1925, vol. 2 in a couple of days by himself!
\nThat’s all for now, thanks for reading!
\nYou can follow this project on Bluesky @oldinsurancemaps, or for folks on the OpenStreetMap US Slack, find the new #oldinsurancemaps channel.
\n", "summary": "Herein: Updates on the future of OIM, some good ol' tech improvements, new blog post, and community notes. For new readers, welcome! And here are all past newsletters in case one isn’t enough.", "date_published": "2025-12-12T13:55:00-05:00", "url": "https://blog.oldinsurancemaps.net/2025/12/12/winter-newsletter/", "tags": ["newsletter"] }, { "id": "http://oldinsurancemaps.micro.blog/2025/12/01/reintroducing-the-multimask-interface/", "title": "(Re)Introducing the MultiMask Interface", "content_html": "The “multimask” is a concept in OldInsuranceMaps.net that greatly eases the creation of seamless mosaics from many different georeferenced layers. I recently made some updates to the user interface for this tool, and decided to take the time to provide a better introduction to feature as a whole.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/pittsburgh-multimask.bz4jm5z7-356wq.webp\")
\nTo understand how the multimask idea came about, consider that if you georeference all pages in a historical atlas, you’ll get something like this:
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/no-1908-vol2-nomasks.evyq7fmv-1ggjcu.webp\")
\nThis is the historic French Quarter in New Orleans, as shown on 24 georeferenced pages from the Sanborn map, Vol. 2, 1908. As you can see, while each individual layer would look fine on its own, when they are all displayed together in a single web map the margins from each sheet overlap each other. This obscures information on adjacent sheets, and, generally speaking, looks very messy.
\nInstead, we want to see a seamless mosaic like this, so that we don’t lose information due overlapping pages, and as a single, clean layer, the mosaic becomes much easier to deal with.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/no-1908-vol2-masks2.b9byt-7f-z1hmj9g.webp\")
\nRemoving the edges is achieved by cropping or masking each layer, but creating these masks is typically very time-consuming and tedious work. OldInsuranceMaps.net uses a multimask to handle the task in a new way, and to understand why we’ll back up a couple of steps to how the overall workflow is put together (or you can just skip to the end of this post to see some nice animated GIFs I made last night).
\nIt’s common in georeferencing workflows to use a two-step process:
\nIf you are working with a single standalone map, as opposed to a map that is a single page of a multi-page atlas, then this is a sufficient approach. Set the mask in the beginning, and you’ll very likely have no reason to modify it later.
\nHowever, with multi-page atlases, careful and fine adjustments to a mask may be needed after the page has been georeferenced, once you see how it lines up with an adjacent layer. Depending on the details of how the mask is implemented, this crop ➞ georeference workflow may not lend itself well to making iterative adjustments.
\nAnother thing to consider is that it is fairly common to have multiple maps drawn on a single page, especially in these city-wide multi-page atlases. For example, Alexandria, La., 1892 is a Sanborn map with three sheets (shown below), each with a different number of distinct mapped areas: sheet one has four different regions, sheet two has two regions, and sheet three is one full-page map.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/preparation-examples3.cjrglbnq-1p5rlo.webp\")
\nIt would be nice to deal with these using a pair of digital scissors, cutting or splitting each page until each map region stands on its own. Then each one of these seven pieces can be georeferenced individually.
\nTo recap then, we have 1) a need to handle multiple map regions within a given page, and 2) a need to carefully mask layers after they have been georeferenced, to properly accommodate the edges and masks of adjacent layers. These considerations led to the creation of a three-step workflow:
\nInstead of crop ➞ georeference, where the first step both defines the region to georeference and determines the final mask, split ➞ georeference ➞ trim fully separates these concerns, as they are now handled on either side of the actual georeferencing operation. While technically adding a step, this granularity actually creates a simpler and more efficient workflow.
\nTo facilitate this final trim step, OldInsuranceMaps.net originally implemented a “create a mask” interface that operated on a per-layer basis. Once an item had been georeferenced, you could add a mask (stored as GeoJSON), which allowed you to trim the margins from layers in a manner that was easy to modify and didn’t affect the existing georeferencing work.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/2022-02-01-22-25.cqetjqxb-z4is46.webp\")
\nHowever, it didn’t take long to realize that on a layer-by-layer basis this approach was cumbersome and practically unworkable. Even though it was easy to alter masks at any point because they were simply laid on top of the layers (and didn’t alter any files), doing so in an isolated environment provided no useful context for how to position one layer’s mask with regard to that of its neighbor.
\nEventually it became clear that there must be a better way to handle this whole trimming thing, and the key came down to changing the conceptual level at which the task was approached (which, as I think about it, is a theme throughout a lot of the platform’s tooling). Instead of trimming each layer one at a time, let’s do them all at once!
\nIn practice, this looks like putting all layers on the map at once (see the messy image at the top of this post) and then selecting a layer, drawing a mask, then selecting the next layer, drawing a mask, and so on. This is more efficient simply because there is no moving between web pages to move on to the next layer, but with the design features shown below, things really start to look different.
\nOne of the main challenges with creating adjacent masks is making sure that they line up exactly with each other. OpenLayers, the web mapping library that OldInsuranceMaps.net uses throughout, has a very nice snapping capability, which is a key feature of the multimask interface.
\n\nIn the animation above, one sheet still needs to be masked, while all of its neighbors have already been handled. To create the mask for this final layer, you can just click, click, click, snapping to all adjacent vertices. Upon completion (double-click on the last point) a mask is created and applied to the layer immediately. This new mask shares exact vertices with all of its neighbors, guaranteeing seamless coverage and shared boundaries between layers.
\nMany great things happen when you can use snapping. Not only is it easy to create masks quickly, but once multiple masks share the same vertex, any alterations to that vertex affect each mask.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/mm-move-vertex.prpdqwt-z14cyxe.webp\")
\nFor example, if four masks share a corner, moving that corner vertex will change all of them at once.
\nFine-tuning the boundaries between different sheets is necessary when there are certain details at the edge of one layer that should be masked around to ensure that important information isn’t lost. Making small adjustments like this is very easy because adding a vertex to a shared boundary automatically applies it to both masks.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/mm-fine-tune.b9ikbwfm-zxhn6e.webp\")
\nIn some cases, two neighboring sheets may have the name of the same street in very close proximity to each after they have been georeferenced, so you’ll want to reveal that street name from on layer and hide it from the other.
\nUntil recently, all vertices were white within the multimask interface, but a couple months ago I added something I had had in mind for a while: color-coding. If a vertex stands on its own, it is white, but if it has been snapped to another vertex it is green. This is especially helpful for cleaning up internal vertices that should be snapped together but for some reason haven’t been.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/mm-fix-inner.rzibcl2h-z15ybkk.webp\")
\nThere are plenty of cases in which a vertex will legitimately stand on its own, like an exterior corner, or even internally where edges of sheets don’t actually overlap. But having this new visual cue makes comprehensive cleanup efforts much easier to do.
\nOver the next couple of weeks we’ll be holding two community georeferencing events at Second Line Brewing in New Orleans. If you are in the area, we hope you can make it!
\nAs we have in the past, we’re doing these events in collaboration with the Midlo Center and HistoryForge. We’ll be starting work on the 1895 Vol. 2 Sanborn Map (which covers the CBD and more), and, excitingly, Elizabeth from the Midlo Center will also talk about the archaeological work they have been doing this summer in Duncan Plaza. We hope you can join!
\nIn early October I’ll be doing a talk and activity for the wonderful Front-end Party software developer meetup here in New Orleans. Exact details TBD (they’ll be here eventually), but I’m really looking forward to getting some hack-a-thon action only weeks after all of these georeference-a-thons. Hopefully we’ll have some fun web maps to share by the end!
\nBut, one fun little detail, a couple weeks ago I added “duration” as a column to the Activity page. This is how long someone has the “split” or “georeferencing” interface open when they are performing one of those tasks. Fun to see, eventually I’ll aggregate these durations for average time per sheet, etc. Also, there are sorting and filtering options on that table and many others within the site. Progress, slowly…
\nUntil next time!
\nAdam
\n", "date_published": "2025-09-12T13:09:00-05:00", "url": "https://blog.oldinsurancemaps.net/2025/09/12/newsletter-fall-upcoming-events/", "tags": ["newsletter"] }, { "id": "http://oldinsurancemaps.micro.blog/2025/08/08/using-gdals-vrts-for-georeferencing/", "title": "Using GDAL's VRTs for Georeferencing, from \"A look inside OldInsuranceMaps.net\"", "content_html": "Recently I gave a presentation about OldInsuranceMaps.net for I-GUIDE’s Virtual Consulting Office speaker series and I was able to talk a bit more about the technical details of the platform than I have in the past, which was really fun and a great excuse to make some more diagrams. One element of the system I described is the way that the georeferencing process relies on GDAL’s “virtual raster” driver (i.e. file format), and how this is used for, among other things, the live preview feature of the georeferencing interface. Here’s a short summary of that part of the talk with a few relevant slides. For more, you can view the full recording, or find the slides here (note, I’ve updated some of them a bit since the recording).
\nThe basic georeferencing process, which turns a non-spatial image into a geospatial dataset, works by chaining two VRTs together and then writing out a GeoTIFF (specifically, a Cloud-Optimized GeoTIFF, or “COG”). The first VRT references the original image and embeds the user-submitted ground control points (GCPs). The second VRT references the first VRT, and embeds the warping information (which transformation to use). The final step is a GDAL translation process which turns the warped VRT into an actual COG.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/make-cog1.webp\")
\nImportantly, a VRT is just a small XML file, so creating one is nearly instantaneous and requires virtually no storage space. In OldInsuranceMaps, they are also disposable, as the actual database stores all of the information that gets embedded into them. They can be recreated on demand and then deleted after they are no longer needed.
\nWith this in mind, the live preview that is presented in the georeferencing interface is created by injecting user-generated information directly into the VRT linkage chain, and updating that information on GCP creation or modification using a feedback loop. Creating this preview is actually very simple, because TiTiler, and MapServer which I used in the original implementation of this feature, can read and tile data directly from a VRT–no need to actually generate a GeoTIFF.
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/cog-vrt-preview.webp\")
\nFinally, to create the mosaics that are the ultimate end goal of the entire system, even more VRTs are added. First, on top of the warped VRT a new one is created that incorporates the layer’s mask, drawn by users through a unified, “multimask” interface. Then, all of the cropped VRTs are wrapped up into a single mosaicked VRT (mosiacking is actually what VRTs are most commonly used for), and that final VRT is then translated into a single (sometimes quite large) COG.
\n\nThere is even more you can do with this concept of chaining VRTs together, for example enabling the support of custom projections during the georeferencing process. Sanborn Maps are all very large-scale, so warping to a non-Web Mercator projection isn’t necessary or useful. But I have implemented and tested this idea out with much smaller-scale maps that were drawn in a non-Mercator projection, and it works flawlessly. I described the concept in more detail in this old comment on GitHub, and hope to properly implement it on the platform someday.
\n", "date_published": "2025-08-08T18:00:00-05:00", "url": "https://blog.oldinsurancemaps.net/2025/08/08/using-gdals-vrts-for-georeferencing/", "tags": ["presentations","tech"] }, { "id": "http://oldinsurancemaps.micro.blog/2025/07/15/newsletter-summer/", "title": "Newsletter: Summer 2025", "content_html": "Hello all! Writing to tell you about a few things that have happened in the last few months, and some upcoming news.
\nFor new readers: Welcome! You can find all past newsletters in the archive. You can also respond directly to this email to say hello, and you’ll find an unsubscribe link below.
\nWednesday 7/16, 11am US Central Time – registration link
\nApologies for the late notice. Tomorrow I’ll be giving an online presentation as part of I-GUIDE’s Virtual Consulting Office showcase series. I’m really looking forward to this, as I’ll be able to get into some of the more technical details of the platform, and there should be plenty of time for Q&A as well. Registration is free and open to everyone! Big thank you to Alex Michels for organizing these talks.
\nAlso, next week I’ll be co-presenting in the same forum with my colleagues from the Healthy Regions & Policies Lab about our work on the SDOH & Place Data Discovery application. Come to that one too for something completely different!
\nThis past April, Rowan University’s Center for Digital Humanities Research hosted the largest georeferencing event that the site has facilitated to date. Over the course of an afternoon, 50 new people made accounts and georeferenced over 250 layers, covering a number of towns around Glassboro, New Jersey. It really had the server churning, slowed things down a bit for sure, but nothing broke. Read more about it in the Whit.
\nI’ve accumulated content about OldInsuranceMaps.net in a few different places, and web analytics show that no one really looks at it. So, a couple weeks ago I bribed my wife with pizza and we spent some time figuring out how to reorganize. I’ve done my best to see these changes through over the last couple of weekends, and they aren’t complete, but…
\nOldInsuranceMaps.net now stores all of its geotiffs in S3 object storage! In other words, there is a lot more space for new maps. This is a backend change that really opens the door for future work… Not a difference you would notice from looking at the website, but for more information you can checkout this blog post (on the new blog!).
\nThat’s all for now, hope to see some of you tomorrow morning,
\nAdam
\n", "date_published": "2025-07-15T07:38:00-05:00", "url": "https://blog.oldinsurancemaps.net/2025/07/15/newsletter-summer/", "tags": ["newsletter"] }, { "id": "http://oldinsurancemaps.micro.blog/2025/06/29/implementing-s-object-storage/", "title": "Implementing S3 Object Storage", "content_html": "S3 object storage is a protocol developed by Amazon Web Services for handling file storage outside of a normal server environment and “in the cloud” instead. In other words, it’s a simplified way of uploading, downloading, or directly accessing files that are stored in remote “buckets”. In these buckets, storage is (broadly speaking) very cheap and practically unlimited. Many other companies have since adopted the S3 API so their own cloud storage offerings are compatible with it.
\nTo this point, OldInsuranceMaps.net has functioned by downloading image files from the Library of Congress (or other sources, in certain contexts) and storing those files on the main server. Once the images are available locally, the splitting, georeferencing, and mosaicking operations are performed directly on those files, creating even more files (ultimately, Cloud Optimized GeoTIFFs) on the server. Really, the entire point the platform is to build tools and workflows around the creation and management of these files.
\nOne downside to this approach is that the server has limited storage space, let’s say about 500gb. This has been plenty for the last few years (especially as I’ve implemented better compression methods over time) but as available space inevitably diminishes, I decided it was finally time to progress to a new storage strategy.
\nTo implement S3 storage for all content in OIM, there were two general tasks:
\nUpdate the code base to work with remotely stored content instead of relying on files on disk
\nUpload all existing content to an S3 bucket
\nHow much existing content? Well, quite a lot. After a big server cleanup effort (this was the first time I had comprehensively dealt with all kinds of orphan files and remnants from past experiments) there were roughly 130,000 files using about 430gb of disk space.
\nThere were also a couple of important constraints to work around:
\nS3 storage needs to be optional, so that future installations of the code base can run just using local file storage
\nGotta keep the site running! There is a bit of operational inertia that must be respected on the platform, now that there is a lot of content on it and people using it everyday. Practically speaking, this means making slow, incremental steps.
\nOIM is built with the Django web framework, and there is a solid, standardized way for implementing S3 storage using django-storages. In theory then, the storages plugin could be installed, a switch could be flipped, and violá, Django will read and write to an S3 bucket instead of the local file system.
\nHowever, it wasn’t that simple. Due to the fact that a lot of splitting, georeferencing, and mosaicking operations had been built with the expectation of local file storage, some of them failed once S3 got involved. Luckily, GDAL (on which OIM has relied from the start) has a fantastic virtual file system that allows it to read directly from S3 urls, and combining that with another GDAL feature, virtual rasters or VRTs, offered plenty of flexibility to work with. Ultimately, the implementation required rewriting and improving some basic functions at the core of the app, but produced a better code base in the end. If you are interested, you can read all the gory details in this pull request.
\nWith the code updated, I had only to transfer all files to an S3 bucket and then point the application to it. I chose to use Wasabi, a very cheap S3 storage solution, but the beauty of this upgrade is that the code is provider agnostic–in the future switching to Amazon or Linode S3 Object Storage should be fairly painless.
\nIn the week before the final deployment, I configured aws cli to point to a new backup bucket in Wasabi, and used it to periodically sync the entire set of files from the production server to that bucket. About 100 new files get created everyday, so the sync operation (which only updates new or altered files) was crucial for seamlessly keeping everything up-to-date.
It went well! Since the switch on a Sunday afternoon, all new files have gone straight to S3, and all of the existing interfaces and viewers on the site now run from COGs in S3 instead of through nginx on the server.
One hiccup I encountered was that the setting AWS_QUERYSTRING_AUTH in Django was automatically set to True , causing the URLs that the backend returned to have embedded expiration dates in them. Everything would be fine when I re-generated the lookups (which include saved URLs for things like thumbnails) but then the next day these same URLs would be “unauthorized” and no longer work. Setting AWS_QUERYSTRING_AUTH=False fixed this issue.
Wasabi is very cheap, just $7/month per terabyte, meaning that the 440gb I have in the bucket (doubled if you include the backup bucket) falls within the lowest tier of usage. A very quick back-of-the-envelope calculation shows that if the entire LOC Sanborn Map collection (500,000 sheets resulting in at least 3x that many files) were georeferenced on OIM, storage would be under 7tb ($49/month) or double that with a backup. That seems like a pretty good deal.
\nI’ve talked about making this upgrade for a while, so it feels good to finally do it. Technically, I could delete all old content from the server and then downgrade it to reduce the monthly bill, but storage was just one of the elements in play, because the splitting and warping processes do benefit from a powerful server, not to mention I still run TiTiler directly on the server as well. All in good time…
\n", "date_published": "2025-06-28T19:00:00-05:00", "url": "https://blog.oldinsurancemaps.net/2025/06/28/implementing-s-object-storage/", "tags": ["tech"] }, { "id": "http://oldinsurancemaps.micro.blog/2025/02/21/in-review-new-features/", "title": "Newsletter: 2024 in Review + new features!", "content_html": "Hello and happy second month of the New Year! It is high Mardi Gras season here in New Orleans and I feel like everything is happening at the same time.
\nFor new readers: Welcome! You can find all past newsletters in the archive.
\nAlso, OldInsuranceMaps.net is now on Bluesky, come be our 2nd follower! I’ll post smaller more frequent updates there, and it will also be something people/orgs can tag when they use OIM for events or research. And, don’t forget the discussion forum a great way to connect with other people using OldInsuranceMaps.net.
\nOn NYE of 2023 I sent a newsletter with a nice chart of work performed over that year. For 2024, I don’t have anything that nice to offer, but here are some numbers from last year:
\nAs you can tell, 2024 far exceeds all work from past years, largely owed to the incredible work of students and staff at the University of Richmond Digital Scholarship Lab, who seem to be georeferencing 24/7. There have been substantial individual efforts as well though:
\nhayleox in Cincinnati, OH • mrileyowens in Cincinnati, OH (you two should talk!) • ekoparker in Chicago, IL •\\r\\nsanborn_again1 in Springfield, IL • mhowell in Noblesville, IN • tagifford in Schenectady/Scotia, NY • Gullimapozo in Gary, IN • lablakely in Waco, Austin, and Georgetown, TX • cliftonmr in Cleburne, TX • Pete_Zivkov in Bellingham, WA • and others!
\nPlus, of course, a handful of georeference-a-thons (more on those below).
\nOverall, very roughly, I would estimate we have georeferenced over 1/20th of the entire Library of Congress Sanborn map collection (500k documents in the collection, 38k on OldInsuranceMaps, definitely at least 25k of those processed). Wild!
\nMany of these since last newsletter in mid-November!
\nI’d like to highlight a few new/experimental features I’ve added in the last couple of months.
\nA big thank you to everyone who continues make this project possible. Especially my colleagues and lab PI Marynia Kolak at UIUC, as well as the team at the URichmond DSL and their partnership with the University of Michigan. Jeff and Minh continue to make OpenHistoricalMap an inviting place to map history (checkout hayleox’s work in Cincinnati, or Pete’s super detail of New Orleans' French Quarter in 1885), which in turn drives people to OldInsuranceMaps.net where they can create Sanborn base layers to digitize from. Finally, thank you for reading this whole thing!
\n– Adam
\n", "summary": "Hello and happy second month of the New Year! It is high Mardi Gras season here in New Orleans and I feel like everything is happening at the same time. For new readers: Welcome! You can find all past newsletters in the archive…", "date_published": "2025-02-21T09:30:00-05:00", "url": "https://blog.oldinsurancemaps.net/2025/02/21/in-review-new-features/", "tags": ["newsletter"] }, { "id": "http://oldinsurancemaps.micro.blog/2024/11/15/gis-day-events-nacis-data/", "title": "Newsletter: GIS Day Events | NACIS | Data Agreement", "content_html": "In case you didn’t know, GIS Day this year is next Wednesday, Nov. 20th, in the middle of Geography Awareness Week. GIS Day was started by the company ESRI (of ArcGIS reknown) many years ago, and I just learned that Ralph Nader was the inspiration behind the day. Of course, there is a lot to GIS beyond Esri, but as someone who learned about the field at the end of my undergrad and never looked back, I love that GIS Day exists and consider it a great “holiday” to promote. Also, what better time to hold historical map crowdsourcing events?
\nAlso, if you skip most of this newsletter, please at least read about the new Data Agreement at the bottom.
\nThrough my work at HeRoP, we will be putting on a georeference-a-thon in Champaign next Wednesday. You can learn much more about it through this Eventbrite link. The event will be in-person, but we have a Zoom option as well (find it at the bottom of the Eventbrite) and we plan to have a couple of short talks via Zoom by researchers who use historical maps. We will be working on Sanborn maps of Champaign and Urbana from 1915, and I’m looking forward to students getting to learn about what their university environs looked like in the past.
\nAfter our event at UIUC, the University of Chicago Library will also have a georeferencing event starting at 2pm in the afternoon. For more details about this event, stay tuned to OldInsuranceMaps.net Forum, an oft-overlooked-but-full-of-potential discussion space that we have. I’ll be posting all of this information there in the coming days.
\nIn collaboration with Dr. Lawrence Brown and the team at Morgan State, we’ll be doing a non-Sanborn map georeference-a-thon on Nov. 21st. We will instead be working with old FHA Loan maps from the 1930s, which Dr. Brown sought out and scanned at the National Archives in Maryland. We are extremely lucky to be able to support this work, and we’ll finally get to see the site with a different set of maps! You can learn more about this event, and join from afar, through this Eventbrite link.
\nAt the Ohio State University, Josh Sadvari and the team at the library will be putting on another GIS Day Georef-a-thon just like they did last year. This is an in-person event, and part of a full day of GIS talks, all of which look fascinating. Do check it out if you are in the Columbus area!
\nNot exactly present, but just a couple days ago the team at the URichmond Digital Scholarship Lab held a competitive georeference-a-thon (the first of its kind with OIM) and it sure looked like a good time! Riley set up a point system for georeferenced content, complete with the option to challenge the quality of another team’s work to reduce their score.
\n![\"\"](\"https://mradamcox.github.io/theme/img/1-crop.jpg\")
In addition to points for georeferencing, teams also had to do some scavenger-hunting across the 1905 Richmond map to answer questions like “Across N. 11th St. from City Hall is where you can find the ________ HOTEL” , or “Just _east of Shockoe Slip is where you can find _______ COFFEE CO.”
\n![\"\"](\"https://mradamcox.github.io/theme/img/3-crop.jpg\")
Congrats to the big winners (and some familiar names from the platform!!): ibrahimalkaser, samyoga, bakeunsu, and willguy.
\nFinally, we owe a big and belated thank you to everyone that showed up to the events we did with HistoryForge at Second Line Brewing in New Orleans, this past August. It was unexpectedly great to do two weeks in a row because it felt like we built some momentum, even though there were very few people who came both days.
\n![\"\"](\"https://mradamcox.github.io/theme/img/IMG_6231-crop.jpg\")
All together, we had about 25 people attend, made it through the entirety of New Orleans, 1908, Vol. 2, and much of Vol. 3 as well. Once these mosaics are completed and trimmed, we’ll be able to add them to the local HistoryForge project, to help with trascribing and mapping historical US Census documents.
\n\\r\\n
\n\\r\\n
\nLast month I traveled to the annual North American Cartographic Information Society meeting, this year in Tacoma, WA, and presented about OldInsuranceMaps.net. The video of the talk is now on YouTube: Handling Complex Content within Georeferenced Historical Atlases. You can also flip through the slides here: tiny.cc/nacis2024-ac. Even though it sounds pretty boring, this was extremely gratifying to put together and present, because it distills what I think is most unique about the platform.
\nAs a lucky bonus, Riley Champine from the URichmond DSL presented in the same session right after me, so I encourage you to watch his talk as well: Using Old Maps for New Insights on America’s Cities. He discusses updates to the lab’s Mapping Inequality project, and near the end has a fantastic demo of their new project Fires of Industry, that is based on the monumental georeferencing effort their students are carrying out using OldInsuranceMaps.net. I heard a few “wows” in the audience when he showed this.
\nAs I have written in this newsletter before, I have been working toward being more precise about what happens with user-contributed data on OldInsuranceMaps.net. I have now added a Data Agreement, that states the following (in summary—see linked page for more details):
\nTwo core goals of OldInsuranceMaps.net are:
\nTo that end, OldInsuranceMaps.net collects user-contributed georeferencing data, and insofar as any of this data is copyrightable, users agree that their copyright is waived and CC0 license is applied.
\nThe platform also records the georeferencing-related actions that a user takes while interacting with it, and uses Plausible Analytics to collect general statistics about visitors to the site. No private user information is collected.
\nI will reiterate as I have said before: If you have already created content on the site, but would not like to have it available under these conditions: Please get back to me and I will help you download it and will then remove it. No problem at all! The files should be very easy to self-host.
\nThanks, as always for reading, and hope to see some of you next week!
\nAdam
\n", "date_published": "2024-11-15T16:30:00-05:00", "url": "https://blog.oldinsurancemaps.net/2024/11/15/gis-day-events-nacis-data/", "tags": ["newsletter"] }, { "id": "http://oldinsurancemaps.micro.blog/2024/11/15/handling-complex-content-within-georeferenced/", "title": "\"Handling Complex Content within Georeferenced Historical Atlases\" ", "content_html": "Last month I traveled to the annual North American Cartographic Information Society meeting, this year in Tacoma, WA, and presented about OldInsuranceMaps.net. The video of the talk is now on YouTube: Handling Complex Content within Georeferenced Historical Atlases. You can also flip through the slides here: tiny.cc/nacis2024-ac. Even though it sounds pretty boring, this was extremely gratifying to put together and present, because it distills what I think is most unique about the platform.
\nAbstract:
\n\n\nWhile georeferencing a single map is an easy one-off process, applying the work across a whole atlas (or multi-volume set) is a challenging task–especially when pages have multiple insets and the atlas contains more than one category of maps. How do you structure this work, and create cohesive output? This presentation will describe the novel hierarchical approach within OldInsuranceMaps.net, a crowdsourced web georeferencing platform designed around the complexities of Sanborn fire insurance maps. Facilitating the creation of seamless mosaics from this collection has resulted in a robust, abstract workflow that could be applied to any other maps or collections as well.
\n
I made a bunch of diagrams for the presentation using d2, and here is my favorite one:
\n![\"\"](\"https://cdn.uploads.micro.blog/280698/2025/new-iberia-1885-full-workflow.skwkkw2n-2vyhnd.webp\")
\nAs a lucky bonus, Riley Champine from the URichmond DSL presented in the same session right after me, so I encourage you to watch his talk as well: Using Old Maps for New Insights on America’s Cities. He discusses updates to the lab’s Mapping Inequality project, and near the end has a fantastic demo of their new project Fires of Industry, that is based on the monumental georeferencing effort their students are carrying out using OldInsuranceMaps.net. I heard a few “wows” in the audience when he showed this.
\n", "date_published": "2024-11-14T19:00:00-05:00", "url": "https://blog.oldinsurancemaps.net/2024/11/14/handling-complex-content-within-georeferenced/", "tags": ["presentations"] }, { "id": "http://oldinsurancemaps.micro.blog/2024/09/13/newsletter-fall/", "title": "Newsletter: Fall 2024", "content_html": "Here in New Orleans we have two public Georeference-a-thons right around the corner! On the next two Tuesdays we will be gathering at Second Line Brewing (as before) from 6:30 to 8:30pm to georeference more New Orleans Sanborn maps for HistoryForge. We did this last summer, and the resulting work has been integrated directly into the HistoryForge platform (as you can see in the link, click the map icon). Having the Sanborn map layers is very helpful for tracking down old US Census records, and makes exploring the city’s history even more engaging. Hope to see you there!
\n![\"Flyer\"](\"https://mradamcox.github.io/theme/img/flyer.jpg\")
A big thank you to Elizabeth from HistoryForge for making the flyer!
\nLast winter, I wrote about my interest in applying a CC BY license to the work that people have completed on OldInsuranceMaps.net. Since then, I have done much more research on the topic by reaching out to people with experience in other crowdsourcing applications, as well as copyright experts within university libraries. Overall, I’ve found that CC0 will be a better fit for contributed content on the site, which would place individual contributions “as completely as possible in the public domain,” to borrow Creative Commons language. CC0 is the most permissive Creative Commons license, and will allow the use of map content for research, personal, or commercial use. CC BY would require that attribution be given whenever content is used elsewhere, which sounds good in theory but would bring a level of enforcement and legal burden that I am not able to meet in practice.
\n\\r\\n
\nMore importantly, however, I’ve learned that the data created through the georeferencing process is unlikely to be considered copyrightable in the first place, because the cut-lines, ground control points, and masks are effectively recordation of facts (“this is the boundary of an inset”, “this pixel coordinate corresponds to that lat/long”), and facts cannot be copyrighted. So the language I will be adopting soon will be along the lines of:
\n“To the extent that contributed content on OldInsuranceMaps.net can be considered copyrightable, a CC0 license is applied."
\nAs before: If you are not comfortable with the work you have contributed being available through such a license, please get in touch with me ASAP. I will happily help you download/save your work elsewhere and remove it from the site.
\nI have been working a lot in the past few weeks on a big re-modeling project within the database, which I hope to have fully implemented by next week. (But it has been a complex process so we’ll just see how it goes…) You can read these pull request notes for more details on the changes. Some of the outward improvements that this will make possible are:
\nThis is the topic I’ll be presenting about at NACIS next month in Tacoma, so if you are attending the meeting please say hello! Even better, Riley Champine from the University of Richmond’s Digital Scholarship Lab will be in the same session, talking about their work at the DSL, and in part their use of OldInsuranceMaps.net. I think these talks will be recorded, so I’ll be sure to pass links to them on eventually.
\nAll the best,
\nAdam
\n", "date_published": "2024-09-13T14:00:00-05:00", "url": "https://blog.oldinsurancemaps.net/2024/09/13/newsletter-fall/", "tags": ["newsletter"] }, { "id": "http://oldinsurancemaps.micro.blog/2024/06/24/newsletter-spring-and-midsummer-updates/", "title": "Newsletter: Spring and Mid-Summer Updates 2024", "content_html": "Hello! The last newsletter I sent out was over half a year ago, so a lot has happened in the meantime (including: I got married!). I’ll get to most of the updates here, but hopefully will be able to follow-up sooner than later with more. Before going further, I’d like to welcome the 50+ new folks who have registered since the year started. Looking forward to hearing and seeing what you work on! Which is a good segue to the next point…
\nJeff Meyer at OpenHistoricalMap suggested that we make a dedicated category for OldInsuranceMaps.net within the existing OHM forum. This provides a permanent, external location to have discussions and post about what people are working on. So, please don’t be shy, let us know what cities you are georeferencing (or have worked on in the past :)). Moreover, do you have a city in mind but haven’t been able to georeference it yourself? Use the forum to let us know, maybe someone else would like to work on it with you. All questions and comments welcome!
\nSo much of this content has been created by staff and students at the URichmond DSL lab. They are doing fantastic work! This must be the largest Sanborn map georeferencing effort that has been undertaken in a public platform, by far.
\nUntil next time,
\nAdam
\n", "summary": "Hello! The last newsletter I sent out was over half a year ago so a lot has happened in the meantime (including: I got married!). I’ll get to most of the updates here, but hopefully will be able to follow-up sooner than later with more. Before going further, I’d like to welcome the 50+ new folks who have registered since the year started. Looking forward to hearing and seeing what you work on! Which is a good segue to the next point…", "date_published": "2024-06-24T08:24:00-05:00", "url": "https://blog.oldinsurancemaps.net/2024/06/24/newsletter-spring-and-midsummer-updates/", "tags": ["newsletter"] }, { "id": "http://oldinsurancemaps.micro.blog/2024/06/23/piloting-a-sanborn-map-georefathon/", "title": "\"Piloting a Sanborn Map Georef-a-thon for GIS Day 2023\"", "content_html": "Last November, Josh Sadvari and Michelle Hooper hosted a Georef-a-thon at The Ohio State University Libraries using OldInsuranceMaps.net, and wrote this detailed piece about how they prepared for the event, how the platform worked for them, and what kind of engagement their participants got from the experience.
\nPiloting a Sanborn Map Georef-a-thon for GIS Day 2023, WAML Information Bulletin, Western Association of Map Libraries. 2024. Josh Sadvari and Michelle Hooper
\nSome nice quotes from the article, that illustrate how the event was able to expand knowledge and appreciation of historical maps:
\n\n\nVery few georef-a-thon participants indicated they had previously used or even heard of Sanborn maps when asked this question during the introduction, which reinforces how such an activity can help in creating awareness of the potential uses of this collection.
\n
\n\nThe OldInsuranceMaps.net platform provides a low barrier entry point for teaching spatial and data literacy concepts through georeferencing and engaging students in the “process” of geospatial data, illustrating a standalone educational value that was perhaps not envisioned as a specific outcome during the platform’s conceptualization and development but could be one nonetheless
\n
![](\"https://cdn.uploads.micro.blog/280698/2025/piloting-article-headline.webp\")
\n",
"date_published": "2024-06-23T18:00:00-05:00",
"url": "https://blog.oldinsurancemaps.net/2024/06/23/piloting-a-sanborn-map-georefathon/",
"tags": ["writing","collabs"]
},
{
"id": "http://oldinsurancemaps.micro.blog/2023/12/31/year-in-review/",
"title": "Newsletter: 2023 Year in Review",
"content_html": "Hello everyone and welcome to the final newsletter of 2023! It was last January that I made an announcement letting you all know we were back in business here, and since then a lot of wonderful things have come from the project. First, a couple of recent things I haven’t yet told you about…
\nAs always, you can reply with comments or questions directly to this email (it won’t be a “reply all”!), or view past newsletters here.
\nOver the course of the year I worked with Kiri Carini and Sanjay Bhangar at Development Seed to create a post about OldInsuranceMaps.net, and we finally released it on Dec. 1st: Open Source Spotlight: Old Insurance Maps. This year I completed a transition to using DevSeed’s open source software, TiTiler, to serve all raster layers and because it is typically used for tiling satellite imagery, they were excited to see my use of it for historical maps. The blog post is one of the more detailed things I’ve written about the tech side of the platform, I encourage you to check it out!
\nA few days after that, the Maps Mania blog (which I have followed for a while and I highly recommend to anyone who likes maps) also featured OldInsuranceMaps.net in a nice post, Historical Sanborn Maps of America. Very happy for this exposure, though there’s nothing to make you feel like you need to improve a home page like all of a sudden having a hundred new people look at it :/.
\nAs more institutions have started using the platform to georeference content, it’s time to formalize licensing for content that is created on the site. At its heart, this is a collaborative crowdsourcing platform that facilitates the transformation of, access to, and public engagement with historical map content. With this in mind, I plan to implement the CC BY 4.0 license for all georeferenced content that is created on OldInsuranceMaps.net. Creative Commons licenses offer a formal way to ensure that content is shareable, and the BY extension requires only that attribution be given when the content is used in other contexts. When I finalize this decision with a statement on the website, I’ll provide more info on how to give credit (probably something like “OldInsuranceMaps.net contributors”, a la OpenStreetMap).
\nOnce implemented, the CC BY 4.0 license would be applied to the following (existing and future) content on OldInsuranceMaps.net:
\nGenerally, this content is all free and downloadable already, so I see the CC BY 4.0 license as a way to formalize what has already been in place for almost 2 years now.
\nThat said: If you have georeferenced maps on OldInsuranceMaps.net and you do not want this license to be applied to your work, then I have absolutely no problem with helping you download everything you’ve created and then I will remove it from the site.
\nFinally: If you have experience with CC licenses and/or licensing for crowdsourced content, I would love to hear your thoughts on this! Just reply directly to this email.
\nNow that that is out of the way, back to the year-in-review with some stats and graphs. Over the last year, OldInsuranceMaps.net has received ~5,000 unique visitors. Most importantly, the trendline is clearly going up (spikes correspond to newsletters, georeferencing-events, etc.).
\n![\"\"](\"https://mradamcox.github.io/theme/img/plausible-2023.png\")
Visitorship is one thing, but what about the georeferencing?? Overall, 4,500 new layers have been georeferenced this year.
\n![\"\"](\"https://mradamcox.github.io/theme/img/2023-sessions.png\")
Of course, a huge proportion of that is the incredible effort by students and staff at the University of Richmond DSL starting in September (this work continues). We’ll have much more about this effort and what it is achieving in the future. For now, I’ll just shoutout Riley for managing this effort, and to the top-notch georeferencers involved:
\nwendyle, samyoga, nayers, 10varun17, jattys, JacksonSB, Shelby_m_richards, mekletb, amara017, mirandam, AYAH, and NyKyaSM (sorry if I missed anyone!).
\nBut there have also been a lot of great independent efforts over the last year that I’d like to highlight. For example:
\nI know there are a handful of other folks who have request maps be added but haven’t gotten a chance to work on them yet, so look out for much more in the coming year!
\nWe held two small events at Second Line Brewing in New Orleans this past summer, especially to support HistoryForge’s use of the site for their New Orleans project (more HistoryForge collaboration coming next year). We created a beautiful mosaic of a 1896 New Orleans volume (and had a few beers too).
\nThen, in November, Josh and Michelle at Ohio State University held a GIS Day event where they had 30 people participate and georeferenced almost 200 sheets of Columbus maps in 4 hours! I’ll be able to share a nice write-up in the next few months, and they already have another event planned for International Love Data Week.
\nFinally, a huge thank you to people this year that helped out, gave advice, or got involved some way or another, in addition to all of the contributors listed above… Jeff Meyers at OpenHistoricalMap; Eve Snyder and Elizabeth Williams at HistoryForge; Rob Nelson and Riley Champine at University of Richmond DSL; and Josh Sadvari at OSU Libraries… to name just a few. The project owes much to you all!
\nIt’s been a great year, and I have no doubt 2024 will see a huge expansion of the usership, engagement, and georeferencing capabilities on the platform.
\nHappy New Year!
\nAdam
\np.s. I’ve just run out of time and space to describe the tech updates that the past year has seen… if that interests you, see the DevSeed blog post linked above.
\n", "summary": "Hello everyone and welcome to the final newsletter of 2023! It was last January that I made an announcement letting you all know we were back in business here, and since then a lot of wonderful things have come from the project. First, a couple of recent things I haven’t yet told you about…", "date_published": "2023-12-31T14:39:00-05:00", "url": "https://blog.oldinsurancemaps.net/2023/12/31/year-in-review/", "tags": ["newsletter"] }, { "id": "http://oldinsurancemaps.micro.blog/2023/12/10/dev-seed-open-source-spotlight/", "title": "Dev Seed: Open Source Spotlight - Old Insurance Maps", "content_html": "Working with Kiri and Sanjay from Development Seed, we put together this post for Dev Seed’s blog: Open Source Spotlight - Old Insurance Maps. This came about because Kiri saw my presentation at FOSS4G Southeast in Nashville last year, where I described how I had reworked OldInsuranceMaps.net to use TiTiler (open source software that Dev Seed created and maintains) for dynamic raster tiling, replacing GeoServer which had been incorporated into the platform from the beginning.
\nIt was very satisfying to put this piece together, and get to talk more about the tech stack that makes OldInsuranceMaps work.
\n![](\"https://cdn.uploads.micro.blog/280698/2025/devseed-post-snippet.webp\")
\n",
"date_published": "2023-12-09T19:00:00-05:00",
"url": "https://blog.oldinsurancemaps.net/2023/12/09/dev-seed-open-source-spotlight/",
"tags": ["tech","writing"]
}
]
}