Hacker News Reader

Comment by sly010 | Hacker News Reader

As a sidenote, Australia moves about 7cm north annually [1], so any encoding of GPS location is not flexible enough in the long term.

Also only encoding lat/long makes it so you would not be able to address a single floor in a large building.

[1] http://www.bbc.com/news/technology-36912700

View on HN

Obviously we need to add the date the coordinates were encoded. The decoding will have to apply correction based on ample databases of tectonic data. A simple formula will not work, a major earthquake can move a rift by some 5-10 cm. And you need to know exactly what plate does the coordinate refer to, is not as simple as 'Australia moves 7cm a year', consider parts of California east vs. west of the fault. Well, that spiraled out of control fast... It makes the time issues like [0] seem trivial by comparison.

[0] http://stackoverflow.com/questions/6841333/why-is-subtractin...

> Obviously we need to add the date the coordinates were encoded. The decoding will have to apply correction based on ample databases of tectonic data. A simple formula will not work, a major earthquake can move a rift by some 5-10 cm. And you need to know exactly what plate does the coordinate refer to, is not as simple as 'Australia moves 7cm a year', consider parts of California east vs. west of the fault. Well, that spiraled out of control fast... It makes the time issues like [0] seem trivial by comparison.

I didn't think it was possible to come up with an idea worse than leap seconds but we did it guys!

> I didn't think it was possible to come up with an idea worse than leap seconds but we did it guys!

Leap seconds aren't the problem, its the fact that we're stuck on a Babylonian style of timekeeping. Measuring time with completely uncorrelated rotations of objects is a ... fun idea. Or maybe the problem is that time is very hard to determine "naturally".

Time is very easy to define naturally as long as it's always "local." Local noon is when the sun is at its highest. Local midnight is halfway between noons, come up with some subdivision, and you're done.

It breaks down once you need to synchronize distant events of course...

Given the spatial resolution of this project (10m) and the lifetime of humans (80 years), it should be alright :-)

Floor / apartment number / suite number could just be tacked onto the end.

Any position can be determined from x,y,z, you could just tack on the z coordinate - though you'd need to match that locally, accounting for sea level. If you are using latitude and longitude you should stick with the paradigm for height, since floors can be different heights.

But then knowing something is X feet in the air only gives me an approximate floor number- I'd have to guess at the storey height and divide.

No question, I considered that too. But for determining position in 3d space I think its more consistent than having floors. If you get to say the 10th floor with different floor heights the difference could be considerable. Its the problem with whats practicable in daily use and what makes sense from a system perspective.

This problem could be resolved within coordinate systems adaptations. I don't know if WGS84, the datum used in GPS, does it, but for example European official datum is ETRS89 which is very similar to WGS84, but adjusts coordinates to these tectonic movements, certain number of cm per year. The principle is to keep same coordinate numbers for same places, even through their global location has changed a bit, even over hundreds of years. In GPS world that does not matter really, but land survey deals with sub-cm accuracy and these things do matter.

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.

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.

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 :)

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?

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.

Needs more UUIDs so we can get Microsoft on board.

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.

>As a sidenote, Australia moves about 7cm north annually [1], so any encoding of GPS location is not flexible enough in the long term.

In a hundred years, this will be off by 7 meters. I highly doubt that makes a huge difference in addressing a physical building.

>Also only encoding lat/long makes it so you would not be able to address a single floor in a large building.

As is the case with regular physical addresses.

Reply on news.ycombinator.com