Putting address grids back on the map

Dan Jacobson (https://www.jidanni.org/)

A prerecorded talk, under construction, for the State of the Map 2024 conference, Cartography Track.

Abstract

The signs say "Addison St. 3600N". But that 3600N is not in OpenStreetMap's database. Users still need a paper map.

3600N is an address, not on Addison St., but on cross streets, a North American concept.

We don't put 3600N into the database either. One tiny specification often is all renderers need to put entire states' addressing grid onto the map.

Such regional definitions would form an ESPG-like database, starting within OSM but soon becoming a world standard.

Unlike EPSG, our definitions are tied to the same cadastral survey the addresses themselves are, freeing us from the "heavy lifting" to longitude and latitude.

Full article: https://www.jidanni.org/geo/house_numbering/grids/define.html

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

  1. Description.

  2. Introduction

    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:

    [Image: Salt Lake City, Utah street map] OpenStreetMap.

    We didn't need to submit one longitude or latitude. We are thinking on the "astral plane", the local house addressing plane. Our brain is totally disconnected from longitude and latitude, state plane coordinates, UTM, GRS80, NAD83, WGS84, Plus Codes, Maidenhead locators, you name it. Did somebody say "think local?". Easy peasy grade school kid stuff GIS. Hey kids, try this at home!

    By the way, all those other grids are not "On the ground", but ours is: on every mailbox and house, hanging near the front door. We're even more "On the ground" than all those boundaries one sees on the map. Walk around the block. You'll see lots of house numbers, but the only place you'll see "City of Smellsville" is on the No Parking signs, at the bottom, in tiny print. (Well, OK, lately they like to print it bigger, with a logo, and on more types of signs. But there are still more houses than signs on our block.)

    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".

    (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.)

    But most of the time you do need helpful grid ticks

    But outside of Utah the map user still needs helpful hints added to the map, to be sure that the "map consumer" is "playing with a full deck". Otherwise they might as well be in a non-address gridded city.

  3. From paper maps...

    In fact that is the way it has always been with paper city maps. Here are address grid ticks, in red, on a store-bought Rand McNally map showing South St. Paul, Minnesota, USA:

    [Image: S. St. Paul, MN, USA address grid sample] 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. We can't exactly tell which side of the streets are odd and even though.

    Our very first OpenStreetMap address region description specification

    And thus begins our mighty task of filling in a schema describing a particular region's addressing grid.

    OK, now that we are through with our rigorous template describing this place's addressing system, let's take a break and just for fun we made an electronic version of that paper map above, with the markers placed in the exact same spots.

    Here is our KMZ, viewed in Viking, upon a Caltopo USGS Topographic map.

    [Image: S. St. Paul MN address grid sample: our rendition]

    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...

  4. So how is this supposed to look on OpenStreetMap?

    Q&A

    A couple years from now I browse www.openstreetmap.org, what will I notice being different?

    This proposal/concept/idea would add grid values to nearby most streets in central and western North America. Here is how OpenStreetMap will look different looking along a street in your home town.

    Before: Addison St.         Addison St.         Addi...
After : Addison St. (3600N) Addison St. (3600N) Addi...

    Nope, nope, nope. We almost made a big mistake. We should instead just use the wisdom of the paper map elders. Just use those same red ticks you see in the paper map samples in this article.

    And where to put those ticks?

    Well at different map zoom levels just have different densities of ticks.

    Distributed uniformly over the map?

    Yes! Just that simple.

    Would the spec include tick distribution tips? E.g., "This town's main roads are all in multiples of 400 east and west, starting with 200: 200W, 600W, 1000W..."

    It seems that would be crossing the line between a pure mathematical description needed to translate addresses into PLSS and then into lon/lat, and "rendering tips". So it seems it would be best "not to pollute our standard." Certainly an appropriate density per zoom level can be chosen by each rendering engine, for each type of map theme.

    Or who knows, maybe some people will think ticks are too polite, and go for the line style of that paper fire district map.

    We stay neutral and just provide the coordinate transformation specifications and how they end up being used is none of our concern.

    North America?

    That is where the address grids are. But don't feel left out. Even San Francisco doesn't qualify.

    Just specifying 800 numbers per mile is not good enough? What's "SD051280N0790W0"?

    That's an underlying Public Land Survey System corner, which we tie to, keeping our grids perfect mile after differently-sized mile. SD05... is South Dakota 5th Principal Meridian...

    Why are Chicago's numbers fair game, but not San Francisco's? You don't need many eyeballs in your head to tell that Chicago doesn't have auxillary numbers on their street signs, but San Francisco does. Doesn't that violate "Ground truth?"

    Here's a simple test: A sign "Snurf St. 900". Does 900 refer to Snurf Street addresses? (San Francisco, no grid involved), or does it refer to houses on cross streets? (And thus a grid.)

    Are you aware OpenStreetMap already has an addr:interpolation tag?

    Yes and I'm sure it is quite useful for most of the world. But using a one-dimensional tag where two dimensional grids are present is a pity. No, a crying shame. Let's take Chicago. While you painstakingly entering your thousands and thousands of addr:interpolation tags, I swoop in and get the same result with a simple definition of the entire North Side. And then I hope over to us/il/dupage/dupage_county/ using the same origin there too.

    In Utah "3600N" is all there is on street signs.

    Yup, but no need to remember to turn off the ticks when they would still be useful in blank areas.

    People can already guess that 136th St. is 13600S etc.

    You'd be surprised how often that relationship breaks. Anyway like we said. We intend to be blind about what else is on the map. We are only going to give renderers formulas to place their lines and / or ticks.

  5. Source code

    By the way, here is our entire project source code, and sitemap.

    And what about other parts of the world with non-PLSS / ad-hoc address / road grids? There are plenty of ways to deal with them too, as we will see. In fact we sometimes fly around in our spaceship, just looking for any grid pattern we can find. Then swoop down vulture-like. If we find they have a logical naming pattern for at least their roads, then we let them off the hook and simply "file a description". But if they haven't even managed to name their grid roads in any logical sequence, or even name them at all, then we can't resist drafting a complete road name and address proposal, based on all we have learned comparing system to systems, and presenting to their government for consideration... Saving the day just in time, before the "Plus Code" team gets there first! We're talking two teams of competing addressing system "missionaries"!

  6. Are we ready for the 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!:

    [Image: SE Highland Park, IL, USA] OpenStreetMap.

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

    [Image: NW corner of Highland Park IL USA] OpenStreetMap.

    There's a challenge for renderers: even though the ticks for these three communities never overlap, how are you going to distinguish them better? Show boundaries between the systems? Use the Four Color Theorem, etc.? Or just chalk it up as a rare occurrence.

  8. Same grid expressed with lines:

    [Image: Highland Park IL USA Fire District map]

    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. More examples:

  9. 800 numbers per mile, Northbrook, Illinois:

    [Image: Northbrook, Illinois, USA address grids]

    Here we have blown it.

  10. North Dakota state-wide Burkle road names:

    [Image: North Dakota, USA, 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.)

  11. Address grid ticks every mile, in the southwest corner of Du Page County, Illinois. Note house addresses proceed 31W998, 32W000, 32W002...:

    [Image: Du Page County, Illinois, USA address grids]

  12. Otero County, Colorado address and road names, ticks every mile. East-west roads use letters:

    [Image: (E) Otero County Colorado address and road name grid]

    North-south roads use numbers:

    [Image: (SE) Otero County Colorado address and road name grid]

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

    [Image: Las Animas County Colorado address and road name grid]

    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.

  14. 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:

    [Image: Louth area, St. Catharines, Ontario 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?

  15. Daan, Taichung, Taiwan. Let's combine the axes. 5th Street hits 5th Avenue at 五, 6th St. hits 6th Avenue at 六...:

    [Image: Daan, Taichung, Taiwan road name grid]

    No PLSS here. So what did we use? A proj pipeline!

    Again, our emphasis is not on good looking background maps or proper monitor resolutions, but that our points wind up close to those intersections.

  16. 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.

    Enough nonsense

    Then having enough of said nonsense, we decided to give the area a custom made system, i.e., some nonsense of our own, and even simpler than Utah's. Those three roads become 500, 600, 700. Let's see what's happening at Roads 900 through 1200. Ah, we see addresses

    6051 1100 Rd. (1100 路 6051 號)
    6158 1100 Rd. (1100 路 6158 號)
    1146 6000 Rd. (1146 路 6000 號)
    1043 6100 Rd. (6100 路 1043 號)

    [Image: Central Xinshe District, Taichung, Taiwan]

    (I should redo the image, adding 路 next to roads and 號 next to addresses.)

    (Note that we have temporarily left our project of "putting address grids back on the map", and now are making a map "to impress the government about how we think their roads and house should be better named and numbered.)

    Label placement

    Let's take a moment here to discuss where, using just points, we have labeled lines, shifting halfway between intersections (+50) to avoid ambiguity.

    x    y    label
1000 6250 1000
1100 6250 1100
1200 6250 1200
    Quiz time 小考
    Q: 請問， 先行疲勞之所謂209之3號，這麼一枚阿公阿嬤級的老舊門牌， 於光明之未來裡，能升等，成為幾路大概幾號呢？
    What would be the approximate sparkling new address of er... legacy "209之3號" (209-3) ? (Which by the way, makes the whole town look bad. Well, not bad, but like an antique shop. OK, fine. One day a tourist attraction.)

    答 A: 6300 路 1065 號 (1065 6300 Rd.)

    Q: 請問， 光明之未來裡充滿活力之 1000 路 6055 號， 這麼閃亮之新門牌， 其該有之位址， 很不幸， 現行仍被哪低功能門牌佔？
    What low productivity sad excuse for an address is begging for an upgrade at where 1000 路 6055 號 (6055 1000 Rd.) rightly belongs?

    答 A: "209之2號" (209-2).

    Q: Why in the map above do you use dots for both roads and houses? Didn't they teach you back in GIS school the proper symbology for points vs. lines?

    Er, I did it on purpose, just to prove that my system is so simple that no matter what bad things happen to it, it still is understandable, understand?

    While we're here, let's discuss

    1. Road vs. Streets vs. Avenues. Nope, no need to remember what the official suffix was. Just like in Utah, it doesn't matter.

    2. What about "north", "south", "east", "west" suffixes? What happened to them? Are you saying your system is even simpler than Utah's?

      Yes! Behind the scenes the lower numbered roads are all perpendicular to the higher numbered roads, allowing the public to go about their daily tasks "brain-free." The "baselines" are over the hills and far away, so the whole scheme keeps a "positive attitude".

    Q: Dear Astor Clement, How did they manage to live with such tired old addresses?

    A: Like animals. Like the old woman who lived in the shoe. And yes, the full address was 209-X So and so street, but trust me,you don't want to know the details.

    So as a side effect of our effort to "put address grids back on the map", we also found places that "ought to have address grids on the ground". So soon we shall share our ideas with the local fire department, Household affairs bureau, etc. I'll tell them they are sitting on a gold mine, a rare area in Taiwan that has a perfect grid, that could also enjoy a perfect on-the-ground reference system, instead of, or in addition to, the current haphazard addresses.

    Liberated from N, E, S and W

    And, as we are liberated from being locked into NSEW grids, we can even bend our grid 45° (anyway, every real street grid will still have an angle, however so small, from WGS84 (or future datums) etc.'s idea of true north.) So what did we learn today? Grids should work for the location, not the location working for the grid.

    Let's take the UTM grid for instance. Well it has nice round numbers every 10, 100, 1000 meters. But does so also the road pattern on the ground we are trying to assign (real metal) labels to? With no skew to grid north? And not at 2463, 3463, 4463 meters instead of 2000, 3000, 4000? We see the idea of making "UTM based road names and addresses" can be thrown securely in the trash can. We need a custom made grid!

  17. 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.

  18. And some places I need to take a 2nd attempt. E.g., Glencoe, IL: will I take some kind of hybrid PLSS / tilt approach?

  19. Evanston, IL has a grid tilt downtown that I need to approach differently...

    The city itself has great grid maps.

  20. 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.

  21. Looks interesting: Menomonee Falls, WI: W156 N8480.

  22. Chicago, origin at State and Madison...

  23. Manitoba neighbors' 12159, 13001 discontinuity arises from miles in the front, and (the last three digits) 2 decameters (/2 odd/even) in the back.

  24. 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.)

  25. 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.

  26. The plus and minuses of Plus Codes

    If Utah is such an addressing dreamworld, then why did they need Plus Codes?

    Plus Codes are wonderful. I'm 85% behind them. However there might be a few cases where they might be a minus rather than a plus.

    We see videos of Plus Codes saving the day for various rural / slum areas. One needs to be aware however that sometimes Plus Codes should not be the sole or even primary address: Imagine a city with a perfect rectangular street grid, and tilted 45 degrees from the north to boot. Here a traditional "418 34th St.", "1103 Avenue D" address is far superior than any Plus Code, at least in helping a resident get from A to B, without the help of electronic devices. "2141 East 6800 North" might be even more superior still. And how about just 2141 6800 Rd.?, Or No. 2141 6800 Rd.?

    Garbage dumps vs. beehives

    OK so maybe Plus Codes are a winner if you live in some kind of unorganized garbage dump. But not if you live in a beehive (Or the Beehive State!). A beehive, at least a single continuous sheet of which, has perfectly organized cells that deserve a custom fit naming. Even if they just happen to align north / south.

    Therefore the OLC/Plus Code FAQ needs to mention some cautions. Else let's say some local government goes hog wild with Plus Codes, with the final result being the entire Plus Code project unfairly gets a bad reputation!

    (Land) Parcel IDs

    Hmmm, what about land parcel id's. Why not use a Plus Code that is contained within it as an idea for the entire parcel id? Well, if parcel ids get tangled up with grid systems doesn't that detract on their independence? I mean, "I am a parcel id. Let me be free to describe irregularly shaped land just as well as regularly shaped land, with the same amount of digits. Thank you."

    Still fair scope

    But yes, Plus Codes are a grid, fair scope for out effort to "put grids back on the map," and indeed they already have one such implementation. But it looks more like a heavily overprinted military map, instead of our tidy paper map grid tick samples above. But I guess that's the price you pay when wanting to express both axes at the same time.

    Hey Mom, I split the Plus Codes

    In Xinshe I split Plus Codes into their EW and NS components, and used them to label roads on the map. You be the judge as to how wonderful these split Plus Codes would be as road names.

    And let's not get into what continental drift might do to Plus Codes over time, etc.

    So maybe Plus Codes are just a kind of "typeable barcode" with a geographic component. But wait, all barcodes are just encoding type in the first place...

  27. Algorithms used

    Mostly in utilities. Evolving.

    gdaltransform

    Evolving into heavy reliance on gdaltransform. E.g.,:

    Given the coordinates of three addresses in Chicago, find a fourth, and assign a fifth.

    cat gcps.txt
-gcp  1215  -9500 -87.594129 41.721961 # 1215 E  95th St.
-gcp -1416 -11900 -87.657268 41.677858 # 1416 W 119th St.
-gcp -1654 -10600 -87.663995 41.701344 # 1654 W 106th St.
#    -1135 -11200 -87.651048 41.690218 # 1135 W 112nd St.
#      -38 -10700 -87.624780 41.700052 #   38 W 107th St.
echo -1135 -11200 | gdaltransform -output_xy $(sed s/#.*// gcps.txt)
-87.6508214994363 41.6906034825254
echo -87.624780 41.700052 |\
   gdaltransform -output_xy $(sed s/#.*// gcps.txt) -i | perl -anwle \
  'printf "$_, i.e., %.0f %s %.0f St.$/", abs $F[0], $F[0]<0?"W":"E", abs $F[1]/100'
-62.9754010708788 -10692.6338759596, i.e., 63 W 107 St.

    (We could get even better results if we correct for north sides of streets being even, south odd, and 60 being the highest number in a block.)

  28. Proposals

    To various app authors:

    I propose that your app allow the user to have "quick" addressing grids for their local town. No need to create formal definition files. (But you could eventually access a central database of them like I describe in ....)

    OK, so the user I guess would first draw out a rectangle over which the grid would be valid. Then they would to enter at least three two ground control points (GCPs, like gdaltransform uses). So they pan to e.g., Avenue D and 11th St. And enter 400 W and 1100 S (never use negatives when entering of displaying addresses. Of course the program would use negatives internally.) Then they pan to Avenue Z and 44th St. and enter 2600 W and 4400 S.

    Actually at this point, assuming a perfectly rectangular square gridded town, the app has all the information it needs to display 1234 E 2345 N (do allow the user to customize this for this town, where the custom might be displaying 2345N 1234 (as all the towns addresses only lie in three of the four quadrants, so they never bother with E and W notation.) And the map could show labeled grid lines or "+" marks or a graticule along the map margins.

    One could imagine city managers using the app being able to tell in a jiffy what address to assign a new house.

    OK, so the town uses 1200 numbers per mile east-west, and only 800 north south? No problem. The user would just enter a fourth control point. And as we move farther the grid becomes more and more out of wack with respect to the streets on the map? No problem, the user just adds another GCP there. The user worries that they've painstakingly enters so many GCPs, what if one day their device gets run over by a Mack truck? No problem, they could export them (hmm, the GDAL documents mention several formats that can contain GCPs, but all raster, no vector? Well in the worst case export just lines...

    Don't complicate it

    No need yet to complicate things by having the app look for roads on the map, and then snap to the correct side and assign odd and even. Nor translate 630 W 1305 S to 629 W 1300 S or even 629 W 13th St, as we must be standing on the odd side of 1300 street (because the user checked the box that south and west sides of the street were odd.

    All that seems like it would be good for a dedicated address assigner app.

  29. (Conference submission Description section)

    Description

    We drive down the street in Sometown USA. On corner after corner we see the exact same "Addison St. 3600N" sign. Hundreds of them. Rather monotonous.

    But that monotonousness is the key: what we are actually looking at is a constant Y=+3600 in a vast uniform house addressing grid. With origin and axes we can derive the whole city!

    And what do you know? All that has been on paper maps for the last 100 years. But is nowhere to be found in OpenStreetMap's database. One notes in Europe, where OSM started, cities do not have address grids. Address grids are a North American phenomenon, with an extreme in Utah, where all there is on the signs is the "3600N", no "Addison St."

    San Francisco's streets form a grid, but there is no grid in terms of house addresses. Its suburbs might have spaghetti for a road pattern, but gridded addressing via municipal ordinances.

    We here at OpenStreetMap can no longer ignore the origin and axes, the tiny "DNA" specification that makes an entire city's addressing grid accessible to everybody. In fact in the Midwest even the most flimsy paper tourist map has had it from long before any of us were born: those 100, 200, 300... grid ticks.

    That one little line of specification, for the whole town, when thrown away is like tagging the butcher, baker, grocery store, and fine wine restaurant with just the same single indistinguishable place=food. Dumb data. Dumb map.

    OK, so what are we proposing that needs to be done here at OpenStreetMap?

    First, the origin and axes strings. Super easy to make, as they are PLSS / DLS based and not longitude and latitude. You need just one for e.g., all of rural North Dakota, but about three for Chicago.

    So how are we going to get mapping engines to "put the grids on the map?". Weasel in new "name=Addison Street (3600N)"? No. We fall back on the wisdom of elders. Just as in paper maps. The grids are independent of the roads. For a certain zoom level one could render ticks at at a certain density, that's all.

    Expect this database of origin and axes strings to grow. A sort of EPSG but for addressing grids. So a extendable schema is needed. Some towns, e.g., Highland Park, Illinois, have one axis firmly rooted in the PLSS, but the other axis oblique.

    But wait. Looking at real street grids, they often actually aren't very straight at all, even containing jogs. Well as long as they follow the PLSS then the nearby grid ticks would go with the flow, roll with the punches, always the same distance nearby.

    But then how does one convert PLSS into longitude and latitude? Well it so happens that the lon/lats of 3600, 3800 both N and E are Opendata. So there you go. Ground control points within a quarter mile. Just plug into gdaltransform.

    Our EPSG-like database: expect it to describe not only house addressing, but also road naming grids, which often tie into house numbering. Road ZZ is 16000N, AAA:17000N, BBB:18000N. All kinds of variations: even numbered roads N/S, odd E/W. (Some Eastern Colorado Counties. They are using a state highway numbering concept but for grid roads. We keep our opinions to ourselves and just write the functions describing it to our database.)

    We always record what side of the road is odd and even for a given region, allowing "intelligent" tweaking during geocoding: 1435W 1600N → 1435W 1607N → -87.12345,41.67890, and back. 1435W 1600N Nerblestown, Indiana is surely more palatable than a Google "Plus Code", both derived from longitude and latitude, with the difference being our little hometown touch. The miracles one can do with our origin and axes database!

    In our EPSG-like database we record even more "on the ground truths", like electric pole labels, the grid formed of which even finds its way onto bookstore shelf atlases in Taiwan, allowing rescuers to ask panicked reporters to simply read them the nearest electric pole label, and help is on the way, all with only voice and a pencil. One can imagine the HOT applications.

    So there you have it. Get yourself a paper map of most U.S. and Canadian cities. Compare it to OpenStreetMap and Google. The paper map is less information packed. Except for the curious red numbers marching up and down the map. Those are the addressing grids. Without access to them it's like tagging a barber shop, but not its opening hours. OpenStreetMap data users are simply not "playing with a full deck."

  30. Look Mom, no phone!

    Jack can grasp that 59th St. is 5900 North. But anything more complex and he still has to pull out his cellphone and look up.

    Jill on the other hand navigates with ease. Hands on the wheel. Eyes on the road. No cellphone in sight, nor anything stuck in her ears, nor maps reflecting on to the windshield giving her the secret answers.

    That's because just this morning, yes on her cellphone, Jill had a look at our new improved maps, and grasped the master plan, of how the addresses and road names in this town are laid out.

  31. Look Mom, no maps!

    Our story moves to eastern Colorado. Vicky is confused. She is surrounded by odd named roads 97, 99, 101 and cross roads YY, ZZ, AAA... The turn-by-turn voice navigation she was using to complete her delivery route has stopped.

    Good thing she still has some old screenshots of our new and improved map with the address grids on it. Before long everybody in town has chucked the navigation app, and even chucked our new and improved maps, because after grasping the local address grid master plan, who needs maps?

  32. Snippets

    These are jumbled promotional tidbits I am trying while trying to promote my essay. I will clean them up, and mainly send them to the recycling bin.

    1. Converting back, we would note that fire hydrants are usually 10 meters away from road centerlines. And...

      All the way down to which side of all the roads in this region is odd vs. even. Recording that enables us to pinpoint geocoding. For instance 41.11111,-87.22222 converts to PLSS IN02.. which converts to 1234 North 6607 West (Sometown, Indiana). Our map pin is now sitting on top of the fire hydrant. But it has never had a legal address, until today: without looking at the map we snap to the nearest road, 6600 West. Noting we had to snap eastward, we must have been on the west side of that road called 6600 West. We apply the "odd numbers on west side of road in this region" rule we find in the aforementioned EPSG-like international database we made, apply it, obtaining 1235 North 6600 West Road. Whereupon we finally open our eyes and look at the map and see 6600 West Road is called Nibbleston Blvd. finally obtaining "1235 N. Knibbleston Blvd."

      ...The proper way to tag them is not one by one, but with one single definition for the entire city, county, or state.

      Such definitions would be built not on longitude and latitude, but on the underlying survey system, and would become an ESPG-like database, critical for many addressing applications, not the least being simply to "put address grids back on the map".

      Alarmingly, in OpenStreetMap that 3600N is nowhere in the database, despite being an "On the ground truth", just as legitimate as the other words on the sign. It somehow never made never made the jump from paper maps. But hey, we don't intend to put it into the database either. Instead putting one formula for the entire town.

      (In Utah that 3600N is all there is on the sign, and thus finally gets tagged.)

      Now you might argue, "But on the signs that '3600N' is written smaller than 'Addison'". Indeed, not as tall as "Addison", but just as tall as "St.", and OpenStreetMap records "St." but not "3600N".

      So it is time to start recording 3600N. But not street by street. But instead by one handful of characters e.g., ND051460N0780W0_100100 800:800. A single "DNA" not only for 3600N, but for all xx00x's for hundreds of kilometers.

      By this time we have completely lost OSM UK mappers. They started OSM and have defended it from misguided attempts to put postcodes into the wrong tags. Ah, but that 3600N is not a postcode. Nor is it some street sign factory reorder number. It is a concept from an entirely new dimension (2nd dimension in fact), that UK mappers, having grown up in their sad one-dimensional street sign world just cannot fathom.

      In step the San Franciscan mappers. They point to the numbers on their city's signs. However careful inspection reveals that while our aforementioned street signs are all the same boring "Addison St. 3600N" block after block, the San Franciscan signs can't even manage to keep the same number from this block to the next: Wilbur 700, Wilbur 800... (Nor do they manage to even say "St." or "Ave.", but hey, maybe that's the hip new style.)

      We apologize to our San Franciscan friends, and anybody from Europe, and well, the entire Old World. You might as well festoon your signs with floral baskets but is not going to change the fact that they describe one-dimensional system, not two, like ours. Therefore we cannot establish a grid description for your town, so your addressing system will just have to continue being expressed using OpenStreetMap's current methods. In short, "Can't help you, man."

    2. This proposal/idea/concept, if accepted, would double the amount of street and road information visible on OpenStreetMap, in much of the United States and Canada. E.g., "Addison Street" would now be shown as "Addison Street" (3600N)" still be shown as "Addison Street", but nearby your eye would see a 3600N, probably in red. Just like on paper maps.

    3. Mappers from e.g., Europe would not be expected to support our proposal/idea/concept. No amount of explaining that "the 3600N the city government places on Addison St. refers to the addresses on cross streets, not Addison St." would increase their grasp of the significance, worthiness, usefulness, practicality, impact, etc. It is simply not something they grew up with.

      Mappers from San Francisco will walk out of our meetings, pointing to imagry of a perfectly gridded city, despite our explanations that a street grid is not the same as an address grid.

      (OSM Utah members on the other hand will just laugh at the all the rest of us. Their roads are just directly called 3600N in the first place, with no "Addison St."!)

    4. Google Maps etc. will soon follow OpenStreetMap's lead, adding 3600N to their maps too.

    5. In fact there used to be no escaping such "3600" when unfolding e.g., Rand McNally paper maps, for the last 100 years. All we want to do today is simply "put it back on the (electronic) map."

    6. Looking at the tags for Addison St. you will never find any trace of "3600", nor anywhere else. That's because we will need only two tags origin:plss:id=ND051460N0780W0_100100, and addresses_per:mi=1000:1000 to e.g., label all the rural roads in the entire state of North Dakota, and in fact also the blank spaces in between too. And OK, let's say Addison St. indeed is 3600N for three miles, and then 4000N for four. Well, because renderers' row of 3600N's just keeps marching in the same direction in a straight line across the map, Addison St. can twist and turn and we never have to know.

    7. In our scheme we never directly specify longitude and latitude, instead tying to the underlying e.g., PLSS grid, allowing us to zigzag lockstep with it.

    8. The most the general public uses to describe a grid is e.g., "Chicago, origin: corner of State and Madison; 800 numbers per mile. Odd numbers on the south and east sides of a street". However even if we make a rigid schema, we should be prepared to become the caretakers of an ESPG-style critical database of addressing grid definitions used by many organizations, companies, and software packages worldwide. So that schema had better be extendable, and maybe maintainership should be handed to a third party.

    9. The Utahans above might already have 3600N on their roads, but it is still useful to record a grid definition. With it anybody could convert a lon/lat into an address and back, consistent with the local system, instead resorting to e.g., Plus Codes.

      Thus e.g., forward and reverse geocoding, for most rural addresses in North Dakota, all anchored via the same ND051460N0780W0_100100 21 character long string.

      Also odd and even mentioned above, even though not relevant when "putting address grids back on the map", still need to be fully recorded, as indeed they will enable even more precise results when doing such geocoding.

    10. Addresses save lives. But in e.g., Taiwan power pole numbers (ref=) are grid based, so for the last 20 years there the grids are, on the margins of maps in bookstores, and as one of the grids you can choose for Taiwan in worldwide map apps.

      If the person calling in an emergency cannot say where they are, the responded ask them to read the label on a nearby electric pole.

      Take Open Infrastructure Map. It simply shows all the electrical infrastructure, all the telecommunications infrastructure, etc. available in OSM data. Well, those labels are right there "On the Ground" and thus fair scope for OSM. So the one line of logic, connecting together all those potentially millions of painstakingly typed in ref=s, certainly should be part of OSM too, and would enable rescuers, hikers, the HOT project, Open Infrastructure Map, and the general public to produce power pole gridded maps using purely OSM data.

    11. In fact we see that just as after entering "Addison", an OSM mapper's job is not done, until they also add "Street", they also need to record that 3600N, even if sometimes it is not on the street sign. But they won't need to in fact. Because we will have already defined the whole town's system with our one line of logic.

      At this point the San Franciscans barge back into our meeting saying, "Look, our street signs all have those little numbers on the edge!". Ah, but they are not grids. They fail the "cross streets" test mentioned above.

    12. What is 3600N, a postal code, some kind of route number? Let's just say that it is a concept beyond the imagination of e.g., European OSM mappers

      Remember paper maps? You unfolded them and there were these funny red numbers: a city's house numbering grid.

      Our task is to save a whole generation of illiterates. We've got to get those grids (ticks) back on electronic maps!

      ... first make a description of that place's address system.

  33. Even more

    Those address grid ticks are a familiar part of paper city maps. Oddly those maps' electronic versions lack them. Let's put them back on!

    And, many states and provinces have brilliant schemes for naming and numbering all their rural roads and houses. In the past, driving around the area or moving the map back allowed one slowly figure out the logic. Or one needed to attend Emergency Response Team training.

    The plan: enmesh the public in grids. No escaping.

    Nope, no more. We're going to be sure even little kids opening up our map for the first time get the big picture right in their face!

    Yes my job to do a better job

    But you know what happened? After examining grid after grid, day after day... we started developing opinions: "Nice job Edmonton, Alberta, but..." "Nice job Salt Lake City, Utah, but..." "Nice job Province of Manitoba, but..." And, while most grid roads already have names and house numbers in North America, there are a few elsewhere, that well, are just dying for us to swoop in and propose to the local governments that we have the utmost super duper system to name your grid roads and houses therein. And once adopted we get plaque to put on our wall and participate in ribbon cutting ceremonies, and sure enough, lives are saved as the ambulance can get there in time despite battling with their computer system.

    Meet the mayor

    So what started off as a humble "let's put the grids we found back on the map" passive effort, has branched off into "I bet I can make Xinshe's addresses about, oh, 500 times more efficient. Ho hum, another photo op with the mayor."

    I mean fine. Here we are on OpenStreetMap, recording other people's parking lots, other people's recycling bins, other people's port-a-potty stations. We're having more fun than the Recorder of Deeds. And then you (me, we, I) want us to record other people's not too perfectly designed addressing / road naming grids, without a thought to "how would I have designed that grid better if I were in charge?" (Use 1..99 for each block, not just 1..59, etc.) "Hey, that's just not me, man." Therefore I guess we will have to discuss that too. Oops. Sorry. Where was I? Back to our topic...

    tag=?

    Q: So how would this fit into OpenStreetMap's tagging scheme? Would the grid ticks be points? Some kind of two dimensional address range way?

    A: Definitely not points, as there is nothing on the ground there, and there could be infinite points depending on how many we want to show. And does one "tag" grids like longitude and latitude in the first place? If anything, they would be regions, often but not always contained within a political boundary.

    schema=?

    We're talking whole new schemas here. I hope you will join with me in my enthusiasm for trying to make the public more (address and road name) grid-aware. They never knew what they're missing, and how much it would help their daily travels. No, we don't all live in Utah!

    Not only North America

    No, this is not only a North American issue, as not only North America has address grids. Well, we'll find one elsewhere soon. In the meantime in Xinshe, Taiwan we found we could put (split) electric pole label grids on the map, as well as (split) Plus Codes. But we wound up with a split personality with a splitting headache, and ended all the nonsense with a Utah style custom grid that we are going to show to the local government. Who knows, maybe one day it will save a couple lives. (Shortening rescue time location confusion.)

    The secret underlying layer

    In our journey we will see that some places have grids that we can pin onto an underlying government survey system. (E.g., 2400 W 3600 N in Chicago, visible not only on house numbers, but even train platforms) is a PLSS section corner (invisible IL03.....) So we just query the BLM data and retrieve a often quite good lon,lat pair. )

    Whereas in other places all we can do is create a projected coordinate system, you know, like oblique Mercator, to describe their grid. No we haven't encountered curved grids yet. OK, let's make some, to fit e.g., Taichung, Taiwan!

    One dimensional "grids"

    And yes, in many places in the world each road "has their own (one dimensional) grid", with sometimes even each side of the road having their own "grid" (odd and even sides out of step with each other, and even growing at different rates, or all fours cast aside due to tetraphobia, etc.). Yes, such each-side-of-a-street address ranges we can already see on electronic maps, so needn't busy ourselves with here.

    Or perhaps in a given area there is not much logic at all in how the number of one house relates to the number of another house. Yes, electronic maps often do show individual house numbers, so again, we don't have to worry about that.

    Or houses might not even have numbers at all, or perhaps just Plus Codes....

Dan Jacobson

More addressing articles by me.

Last modified: 2024-04-28 09:18:59 UTC