Putting address grids back on the map

A lightning talk for the State of the Map 2024 conference.

Abstract

Paper maps had address grids. Well it's time electronic maps caught up!

Keywords: address grids, road name grids, grid ticks, Public Land Survey System (PLSS), Dominion Land Survey (DLS), ground control points (GCPs), coordinate projections, oblique Mercator

Preface

We're not going to talk about how to particularly display addressing grids on device screens. We're just going to establish that
- they were there, on paper maps,
- are still there "on the ground" (the magic force determining all house numbers and road names), and,
- need to be there, on electronic maps.
(One moment please. Some readers of this article have not grown up in North America, so from childhood were bereft of address grids. (The best they ever saw was "odd on one side, even on the other.") OK, please grow up in North America. We'll wait. All grown up? Good. Let's proceed.)

From paper maps...

Remember paper maps? Here are address grids on a store-bought Rand McNally map showing South St. Paul, Minnesota, USA:

OpenStreetMap.

Note the red numbers. Those are the addressing grid values. E.g., passing 9th Avenue we begin the 900 block. We notice here there are 800 numbers per mile north-south, 1600 east-west. 100N faces 100S. No 1-99 N, 1-99 S blocks. (True, we can't exactly tell which side of the streets are odd and even though.)
Oblique axes

Just as we were getting comfortable, along comes an oblique axis. How are we going to deal with it? One answer comes from the paper map elders, Rand McNally again. We observe they naturally tilt their ticks along with the axis:

Highland Park, Illinois. The axis for 0-700 is the south city limit, PLSS based. For 100, 300 it is the lake shore. One axis oblique to the other!:

OpenStreetMap.
Collisions

Highland Park's oblique 1600-2200 hits Lake Forest's 100-600, and Deerfield / Bannockburn's 1000-1400:

OpenStreetMap.

(Even though the ticks for these three communities never actually overlap, alas as the city limits seem to get adsorbed by the roads, it isn't too clear where one system ends and the next system starts.)
Lines instead of ticks

Same grid as above, expressed with lines:

Above we have seen address grids are a standard part of paper maps (at least for places that have such grids,) allowing the map user to understand the entire house address system at a glance. (Yes, even if address ranges or even each individual house number is also already present on the map.)
...to electronic maps

The general public interfaces with Google, Bing, and OpenStreetMap etc. every day but no longer is getting the entire picture. So let's put address grid ticks back on electronic maps.

Coordinated house and lane numbers from a proposal:
Data entry mock-ups

For Oak Park, IL, USA I made a template for automated grid generation, and a KMZ. Results:

Not too bad, for an absolute first iteration!

Note that such rough grids would be just for viewing in the, e.g., OSM iD editor, and not for final viewing as a finished map.

Perryton, Texas user grid entry mock-up.
Putting grids to work

Let's see all the wonderful things we can do when address grids are available. All we would need to specify is:

X Y Label

200 -200 200

300 -300 300

400 -400 400

to produce the following map:

OpenStreetMap.

Our brain is totally disconnected from longitude and latitude, state plane coordinates, UTM, GRS80, NAD83, WGS84, Plus Codes, Maidenhead locators, you name it. All our thinking is done in the local address coordinates.

Naturally under the hood is massive machinery to turn the local address grid into PLSS and then PLSS into longitude and latitude in order to make our little map of where abs(X) == abs(Y) right in the heart of Salt Lake City. "What did you do with the street names?" you ask. Nothing. No street names up my sleeve. In SLC the grid value is the street name. Kind of makes you want to spend your Golden Years there. They say it is "life changing".

In us/ut/washington/hildale you can see some PLSS templates I used.

(Actually Salt Lake City's streets are not quite as tightly bound to the PLSS as we would prefer, so we bailed out and just used a few nearby intersections as ground control points. Source code: us/ut/salt_lake/salt_lake_city.)
Swallowed addresses

How do we programmaticly deal with a "black hole" that swallows up addresses with absolute value below 100. (If you think that is weird, how about the place that swallows 4.)

So I made a function that you can see there in us/mn/dakota/s_st_paul that would take real addresses' 150S, 150N, 250N, and internally turn them into 50S, 50N, 150N for further processing.

So where was that black hole? Right on our very first map paper map above. So here's an electronic version, with markers placed in the exact same spots. Our KMZ, viewed in Viking, upon a Caltopo USGS Topographic map.

Just like on Salt Lake City above, we didn't tell it to place the marker "100 W" at ~~-93.034803,44.889808~~, but instead at "100 W, 150 S", and let our PLSS-based machinery do the rest.

Enough tinkering around. In reality there would be no manual placing of labels, it would all be automated...
So how is this supposed to look on OpenStreetMap?

Answer: none of my business. OSM is the data. How it is rendered is up to others. So how to define and store the data? Perhaps an addressing schema defined on the PLSS or oblique Mercator projection. Perhaps via storing ground control points.
Northbrook, Illinois, USA

For the rest of this presentation, let's just look at those pretty maps.

800 numbers per mile, Northbrook, Illinois:

Yes, Public Land Survey System (PLSS)-based. Rendered badly by me.
North Dakota state-wide Burkle road names:

(Nicety: We find our algorithm has made the 6 miles S and 18 miles N correction lines ticks refer to the township on their north.)
Address grid ticks every mile, in the southwest corner of Du Page County, Illinois. Note house addresses proceed 31W998, 32W000, 32W002...:
Otero County, Colorado address and road names, ticks every mile. East-west roads use letters:

North-south roads use numbers:
Las Animas County, Colorado address and road names, ticks every ½ mile. E-W roads even, N-S odd, half mile; trail:

Again, how to (better) display such data is up to the renderers. Our job in this paper is to ensure the functions / formulas / specifications to do so are available through our database.

The test of if all this will work is if renderers can just do foreach(@county_in_Colorado){add_grids_to_map()} and it will work, as we have already taken care of each counties' details in our EPSG-like database. And if that worked then one line should also be all that is needed to render tiles / vectors for the whole country.
Louth, St. Catharines, Ontario. No DLS here. Instead we just used a map projection and affine transformations. "4" is on 4th Avenue, "5" on 5th Street. A 416 × 1031 meter road name grid:

As an aside, I wonder if kids growing up in (the main part of, east of here ) St. Catharines, with no address grids, would later be as grid savvy as their Niagara Falls, Ont. neighbors?
Daan, Taichung, Taiwan. Let's combine the axes. 5th Street hits 5th Avenue at 五, 6th St. hits 6th Avenue at 六...:

No PLSS here. So what did we use? A proj pipeline!
Xinshe, Taichung, Taiwan

In Xinshe, Taichung, Taiwan, there are roads in a grid pattern, most without any good names, or even names at all. As they just happen to be N S E W oriented, indeed one can break apart the roadside Taipower electric pole grid labels into their EW and NS components, to give each road nicknames: 72G4, 73A3, 73C2 on our map.

So with our eagle eyes, as we travel east, we notice these X parts of the GXXYYXXYY pole labels are changing...

Then we did the same with Open Location Code / Plus Codes. Splitting them apart into their EW and NS components. Getting, for the same roads: QVJ, QW9, QX3.

Then we went completely hog wild and created an addressing system of our own.
~~Wilmette, Illinois~~ has too many irregularities in its address grid, so we gave up on it. Same with most of the eastern United States and Canada, and most of the rest of the world in fact: no regular grids to put on the map, thus beyond the scope of this article.
And some places I need to take a 2nd attempt. E.g., Glencoe, IL: will I take some kind of hybrid PLSS / tilt approach?
Evanston, IL has a grid tilt downtown that I need to approach differently...

The city itself has great grid maps.
And some places I have yet to try, e.g., Dunn Co, WI: 400 house numbers in every mile, 40 road numbers in every mile.
Looks interesting: Menomonee Falls, WI: W156 N8480.
Chicago, origin at State and Madison...
Illinois counties

In the general case of Illinois counties, we made much progress by just directly using the PLSS section centers. No further interpolation (i.e., no gdaltransform) done.

They usually have their origin in their southwest corner, 100 numbers per mile. Road names derived from grid position.

In Ford County, Illinois we even neatly jump from PLSS 2nd to 3rd principal meridian zones.

OpenStreetMap.

Sure, on OSM the road names already tell you the grid, but near boundaries it is total confusion...
Manitoba neighbors' 12159, 13001 discontinuity arises from miles in the front, and (the last three digits) 2 decameters (/2 odd/even) in the back.
Saskatchewan neighbors' 316580, 317002 discontinuity arises from int( 1609(m/mi) / 40 / 2(odd/even)) and there only being six miles width in a DLS township so we have jumped from R16W to R17W. ("3" stands for 3rd Principal Meridian.)
Utah

Utah is an addressing dreamworld: address grid values often directly used as names of streets. "Utah addresses are unique from other states because of a strong address grid system [which] enables us to make special assumptions and optimizations..."[1]

2024 State of the Map activity.

Schemas

Address schema initiative. You know, like EPSG codes.
gdaltransform

Then we just chuck our ground control points (section centers) into gdaltransform, which by the way is quite powerful. E.g.,:
Source code

Here is our entire project source code, and sitemap.