Make Xaddress state-independent

[Venca24]

For encoding the coordinates into Xaddress you have to currently use tables based on territory of states. This system has some disadvantages:

• it's unclear which table use for disputed or occupied territories like Crimea or Kosovo (requiring use of e.g. Serbian table for Kosovo could also make the adoption of Xaddress hard there),
• when there is new independent state, you have to update the whole system to include it (including independent implementations),
• it cannot be used for encoding something being outside of jurisdiction of any state (like high seas).

Possible solution (but you can came up with your own):

• to use instead the "territory" of natural time zones (or US military time zones) - 24 regions marked e.g. with name of a greek letter (Alpha, Beta, Gamma,... starting from UTC+1)
• The P2 numbers can start on (-90, -8) as 0000 and continue by (-90, -7) as 0001, (-89, -8) as 0017 until (90, 7) as 2700 for UTC+0 (or Zulu/Omega). Positions in other time zones would be recalculated to UTC+0 and marked with their name in the final address. This could be calculated by an algorithm both by hand and by machine.

This could encode everything what can be encoded now, but it wouldn't require change because of occupation or establishment of a new state. It could additionally encode any position on Earth (including those on high seas) and theoretically also positions on another planets and moons (introducing regions by 15° of longitude).

What do you think or do you have another idea how to solve the issue?

[spidergears]

Seems interesting and more functional. Let's get some more reviews and feedback.

[roberdam]

Hi! @Venca24 ,
Thanks for your well thought contribution, answering your comments:

it's unclear which table use for disputed or occupied territories like Crimea or Kosovo (requiring use of e.g. Serbian table for Kosovo could also make the adoption of Xaddress hard there),

There is no problem with overlapping zones, you can have both states and they will resolve to the same location.

when there is new independent state, you have to update the whole system to include it (including independent implementations),

Yes, in regard to the long Xaddress that will be true, and indeed an inconvenience.

I had the same concerns, the main thing is the balance between a intuitive address that looks , feels and tell you about a location ( with the state included) and the exact foolproof technical solution.

The best answer so far that I came up was to include both Xaddress as a part of the service, the long address included with the state, and the short address, that deals with the other issues you mention.

Short addresses are state independent, can be used outside of jurisdiction of any state (like high seas) as you mention.

Let me know what you think about it

[Venca24]

@roberdam
The intuitive addresses you can still use, but you don't need table for each region or state to generate the address, you can use just one (bigger) table or just one algorithm.

You could still use address like 8529 OUR PIANISTS, Ile-de-France, France instead of (or in addition to) 8529 OUR PIANISTS, OMEGA and map each region or state to its respective time zone. (It's just example of the format, I didn't do the recalculation of the exact address.) In such a case you will never have to recalculate the main address (especially P2) regardless what happens on the ground.

I see the advantage in Xaddress and in similar concepts to also enable quick communication of position over the phone or generally by speech as it is quicker as transmit the usual geographic coordinates the same way. This can be used e.g. in emergency calls, or for delivery of anything in rural areas. For this the short addresses doesn't seem to be suitable.

By the way: where is described the algorithm to generate the short addresses?

[roberdam]

I do not see any reason why that would not work, do you have any specific implementation in mind?.

The short address encode is in https://github.com/roberdam/Xaddress/blob/master/encode_func.rb
line 641 def short_encode(xlatitude,xlongitude), and the short decode is https://github.com/roberdam/Xaddress/blob/master/decode_func.rb line 517 def short_decode(codigo), is very simple to understand even if you dont program in Ruby.

[Venca24]

I've got currently just this one implementation in mind:

• the N and P1 numbers are the same as now
• the globe is divided into areas identical with the 24 US military time zones marked by names of greek letters
  • these names are present also in non-european languages like arabic, chinesse, japanesse, hindu or farsi
  • these names should be omitted from the wordlist
  • starting with Alpha as UTC+1, Beta as UTC+2 until Psi as UTC-1 and Omega as UTC+0
• the P2 could be then calculated as ([longitude degrees] - [utc offset] + 8) + 15 * (90 + [latitude degrees])
  • utc offset is the longitude of the middle of the respective time zone (0 for UTC+0, 15 for UTC+1, 30 for UTC+2 asf.)
• then the address could be written the same way as now
  • with time zone code name as global address
  • without time zone code name to refer position in context of some known time zone
  • with city/region/country name if it is easy to map this to it's respective time zone

The address of the main square of my city (Brno) should then be:

• Extrasolar Retainer 1960, Alpha
• Extrasolar Retainer 1960, Czech Republic
• (5182 2094 1960)

When I speak about time zones, I always mean the US military time zones, not the legal time zones as the second ones can be even wider than 15 degrees (e.g. the People's Republic of China).