Hacker News Reader

Comment by tener | Hacker News Reader

Perhaps the address can be made relative to some landmark which moves in the same direction. This could add an additional word in front of it (for the landmark) but will resolve such issues.

View on HN

That's a great idea, maybe something like "church street" and a number that denotes a length on that street?

If that was the case we might run into naming collisions if there are multiple cities with the same street names. It would be best if we namespace it to the city as well. So we would have something like { "street": "Church Street", "length": "5", "city": "Church City" } all of course packaged in JSON.

That's a great idea and will help making addresses more solid. I would suggest we also add some more levels like the country the city is in?

Wonderful idea, and we could even go so far as standardizing how we write it so that we don't need to worry about putting it into JSON and makes it more memorable for humans. Something like:

Length Street

City

Country

To the extent that a single address might be home to more than one person, shouldn't we pre-pend the name of the specified person to the address?

This is getting too complicated.

We need some sort of code attached to each address that can represent an area, so addresses can be organized quickly.

I vote for a 5 digit code, at least in the U.S.

that might be insufficient for densely populated areas, perhaps an additional optional 4 digits?

I like it, but how about we add 2 more digits that don't get printed in human readable format on the mail but are used in barcodes to sort/deliver it?

Needs more UUIDs so we can get Microsoft on board.

Arguably, if it is just for sorting/delivery we could simply use the last two digits of the "length" portion of the address. That would enable any delivery service to sort the mail within the city block and still have a human readable equivalent in case the barcode becomes unreadable.

I should let this lie as an explained joke is never funny, but I just can't.

USPS - Delivery Point: (1) A single mailbox or other place to which mail is delivered. A street address does not necessarily represent a single delivery point because a street address such as one for an apartment building may have several delivery points. (2) A specific set of digits between 00 and 99 assigned to every address that is combined with the ZIP+4 code to provide a unique identifier for every delivery address. The DP is encoded within the POSTNET or Intelligent Mail barcode.

https://about.usps.com/publications/pub32/pub32_terms.htm

Interesting, the last/only time I had to write code to determine delivery points was very early in my career (IBM mainframe COBOL) when postnet barcodes were a new thing and it was always just the last two digits of the street address. I see in the current CASS technical guide that a record type H may have multiple delivery point. Learn something new every day. Thanks.

Edit. As an aside, I think current Microsoft word still calculates it that way when you "bookmark" and address and insert a barcode field. At least it doesn't seem to be sending a query out to the USPS.

Well-structured data like this is better encapsulated in XML:

    <?xml version="1.0" encoding="UTF-8"?>
        <address street="Church Street">
    	<specifiers>
    	    <key length=""/>
        	<value type="uint32" scale="nanolightseconds">5</value>
    		<city>
        	    <![CDATA[ 
            		<?xml version="1.0" encoding="ISO-8859-15"?>
                    <name>Church City</name> 
    	        ]]>
    	    </city>
    	</specifiers>
    </address>

Isn't that much more legible and understandable?

(I hate XML. So much. This shouldn't be a valid document in any language.)

Why not both?

https://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com...

Just think, there were even multiple versions of JSONx so someone somewhere had to be using it.

It's part of a bigger product (WebSphere), so hopefully it's just being dragged along and not still under development.

While I get your point, the XML document includes so much more information than the JSON example. Encoding, version, data types, 'scale', response length, etc.

Please try not to make any false equivalences :)

Nice! But what about areas where addresses haven't been proposed yet?

Handing out GPS coordinates is a bit unwieldy, what if we made an algorithm that converted those to words that are easily memorable and can be spoken over the phone?

I think we're onto something!

Most lat/long data isn't specified relative to the earth's core but to a reference, such as the North American tectonic plate, as in the NAD83 standard for exactly this reason. https://en.m.wikipedia.org/wiki/North_American_Datum

GPS coordinates change depending on continental drift (they are fixed in space). You need updateable parameters to transform to something like NAD83.

Reply on news.ycombinator.com