3 ms·
This reminds me a bit of my own giant techco bugbear: for the longest time, Google Maps mishandled my home address - literally across the street from their loca
by tomjakubowski 8y ago
This reminds me a bit of my own giant techco bugbear: for the longest time, Google Maps mishandled my home address - literally across the street from their local office - because it didn't recognize the 1/2 in the house number. It would direct users to 1 Fake St rather than N 1/2 Fake St.
- CamperBob2 8y agoTo be fair, I imagine a lot of systems don't handle noninteger house numbers very robustly. That "1/2" business just seems like asking for trouble. The best solution might be to convince your building landlord or management to rename the units as 1 Fake Street Unit A and Unit B, or something like that. Assuming they don't have to fight City Hall to make that happen, they might be willing to help.
- walrus01 8y agoYou would think, however, that the "1/2" works fine in the text field used for a standard North American address... At least with Amazon and 99% of ecommerce sites there's two separate freeform text entry fields for street address. It's not like these are fields that require a precise integer. This should enable the actual human making the delivery to see the same thing printed on the label, and visually match it to whatever is labeled "1/2" on the building.
- giancarlostoro 8y ago> It's not like these are fields that require a precise integer. If you are treating the street address as more than a string something is wrong. Its supposed to be a string by design unless you are trying to be efficient by storing ints as ints but then you shouldnt be evaluating them from user input and if you are... Treat it as a raw string.
- xbkingx 8y agoThere'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?
- ericd 8y agoIIRC Google Maps used to interpolate between points with known addresses on streets to estimate where other numeric addresses were along the street, when they didn't have exact points for them. So there's at least one legitimate example of not treating an address as a string.
- x0x0 8y agowhole cities have noninteger house numbers Eg a town I grew up in labeled houses N\d\+ W\d\+ [street name]