Big project idea: Make a standard schema to describe address grids

[jidanni]

I'm here today to make a super big proposal.
You know https://gis.utah.gov/data/address/address-grids/ .
Well it's great that all this information has been stored about local address grids.
Let's see, so far you folks have stored a description of where the 0, 0 point of a town's grid is,
and even some polygons for the four sectors and extent.

Well I'm here today to propose that you folks go the "whole hog" and make a schema for describing

• all the features possible
• and in a standard way
• and not only for the Utah, or the US, but for any administrative entity, no matter how big or small,
  in any country.

I'm saying that Utah, being a leader in logical municipal address grids, should grasp the flag and lead the way for standardizing describing these address grids, even if some parts of the world currently don't even have even and odd numbers or numbers at all.

OK, how might this schema look? Well here's a slice. But please do not use that directly to expand from, but instead use some cleaner basis.

And what could be accomplished with such schemas?
Well ka-pow! Here I have whipped up example Hildale UT KMZ linking that town's address grid with the PLSS. Poof. Ka-zam.
But let's face it, not all towns' address grids are that tightly bound to the PLSS, nor does the whole world use the PLSS, so then your schema would perhaps need to have an azimuth parameter for one grid axis, and a second for the other grid axis as not all are 90 degrees apart. And then gosh, some cities are inconsistent, so you would need to have different sectors. And of course this azimuth needs to be anchored into some datum etc. which is all quickly getting over my head.
Note anchoring the address grid to the PLSS allows us to describe it succinctly for mile after mile, whereas any azimuth would quickly need to be realigned before long. And, with a simple PLSS anchor, we can even float gracefully over PLSS correction lines, never skipping a beat, as long as whatever e.g., county or state involved does the same. Cities on the other hand probably would have a hard time explaining a 3/4 mile jog in addresses to residents, so usually another "addressing sector file" would need to be established upon crossing a PLSS correction line.

Note for my usages which side of the road are odd or even don't matter. But they certainly would need to be recorded in your future schemas, just like they are in your current English descriptions.

Anyway, I am not the right person to establish schemas. I hardly can spell the word.

But before you get started, you don't want to call it "Utah standard addressing schema for describing addressing systems", otherwise like EPSG, when usage increases the original name gets stuck and begins to look dorky, but by then it's too late. So think ahead and expect worldwide usage. And, I assume there is no standard yet.

But wait, what is https://epsg.io/6249 "Cali urban grid"? Maybe the great EPSG repository also has address grids! Ah, phew! or alas!, that Cali example has nothing to do with house addresses.

Anyway, no need to overburden the EPSG system with address grids when a separate system could be established.

Yup, think of yourselves as the future "EPSG of house address / road name grids".

Sure, you might say

We are only responsible to the Utah taxpayers. And if you think we should start
describing grids for even e.g., nearby Colorado , well, describle them yourself.

No, I'm just saying "make sure your schema is Colorado-ready", so when people eventually use it to describe a Colorado town/county's address system.

Ah yes, and road names are often part of what needs to be described. E.g., here I am just describing the system of road naming, not house addresses.

OK, now back to Utah, and indeed SLC where one would expect the "highest quality grids", but for some reason I couldn't hitch the addresses to the PLSS in any convenient manor. In fact looking at the USGS topo maps section lines we see red dashes instead of solid lines, all of which do not run down the middle of streets, indicating that as many other places in Utah, apparently the street grid came first and then came the PLSS. So I just gave up and used some control points to extrapolate other addresses.

So then I tried Orem but still there wasn't a perfect fit with the PLSS there either. So then I tried Hildale and OK, that fit better. However in many other midwest and western states the PLSS got there first so is a perfect fit... by definition (i.e., the address grid bends with the PLSS.)

Anyways, even if the latest city planning says street grids are out and curvy roads are in, there still usually still is a rectangular address grid they are following. And even if new loxodromical or what ever address grids are invented, your new schema needs to be extendable to be able to describe it.

Okay there's another problem. Who's going to be filling out the details of each city, county, or state worldwide?

So they're probably needs to be a spot on like OSGEO wiki, a tree like structure with wiki sub pages, where everybody can fill in the details. Or maybe some kind of tree of repositories on GitHub. And I'm not sure if there needs to be some supervisor approves every single at it, or maybe just like on Openstreetmap where people just do the editing themselves.