There's probably more to it than that. With some knowledge of the ordering scheme, you can determine relative locations and route drivers without storing every

There's probably more to it than that. With some knowledge of the ordering scheme, you can determine relative locations and route drivers without storing every address on a street. I think it's very easy to imagine a cases where have "1/3" as your street number could cause problems (0.33333333... out of memory) or just dealing with floating point conversion and typing can lead to seemingly random bugs. Accepting non-integers should be fine, as long as there's no delimiter or reversions to numbers ( e.g.- 321A Main St.), but I could see it being a problem with delimiters. It greatly expands the solution space for recognition tasks. Is 321 N Main Street: 321 Main St. Unit N or 321 North Main St? Is 321/A Main St: 321 Main St Unit A, 321-A(ths) Main St, 32 Main St. Unit 1 or A, 3214 Main St (A/4 character recognition failure), 321 Main St (A is escaped by /), 321 AMAIN St., 32 Main St Unit VA. Where does it switch from a unit number to an address? 321A21B Main St could be read at least a dozen different ways, especially if we allow for recognition errors. Can't we at least agree that a physical building has an integer value and anything inside the building becomes a separate field (Unit, Suite, Floor, Cabana Room, etc)? No one's pumping money into post office modernization and we're not going to see Unicode or Emoji address support, so can't we simply agree on a few rules?