[Unicode]   Common Locale Data Repository : Bug Tracking Home | Site Map | Search
 
Modify

CLDR Ticket #10996(new unknown)

Opened 4 months ago

Last modified 2 months ago

Add Open Location Codes to -u- extension

Reported by: mark Owned by: anybody
Component: unknown Data Locale:
Phase: dsub Review:
Weeks: Data Xpath:
Xref:

Description

The subdivision codes (en-u-sd-xx) provide a certain level of granularity, but don't exist for all countries, and are not granular enough for some purposes.

A finer grained approach could use the Open Location Codes (aka pluscodes), which allow for successive degrees of refinement where necessary, such as when distinguishing usage variants that are characteristic of a part of a country or subdivision. It would also not some of the issues with countries/subdivisions: code stability, lack of subdivisions for a country, or changing boundaries.

Example:


Should we decide to do this, the codes would need only minor modification to work with BCP47.

I'd suggest:

  • If a code is smaller than 3 sig. alphanums, use one piece.
  • If a code is greater than 8 sig. alphanums, break into multiple pieces, with the initial ones being 8 in length.
  • Drop trailing zeros from each piece.
  • Pad any pieces of 2 or fewer alphanum with 0 to bring them up to length 3.

Thus

  • 6P000000+ => en-SG-u-pc-6P0
  • 6PH57VP3+PQ9 => en-SG-u-pc-6PH57VP3-PQ9

In the future, if we really wanted to signify usage that is also characteristic of usage as of a particular date, or date range, that could be easily done.


See
https://en.wikipedia.org/wiki/Open_Location_Code
https://github.com/google/open-location-code/blob/master/docs/olc_definition.adoc

Attachments

Change History

comment:1 Changed 3 months ago by srl

discuss interaction with existing locode (timezone)

comment:2 Changed 3 months ago by mark

This is independent of the locodes, which cover a very very small fraction of what the Open Location Codes can cover.

comment:3 Changed 2 months ago by doug@…

Open Location Codes are defined by a free and open specification, but appear thus far to have been implemented only by Google. Despite the technical merits of the system over similar latitude/longitude encodings, it may be prudent to avoid the appearance of using CLDR to promote what is essentially a Google invention.

The benefits of specifying locale data for an area smaller than 275 × 275 meters, necessitating multiple pieces, are also unclear. Concrete examples of usage that may differ between central Singapore and Woodlands, say, or between Chicago and Evanston, might be helpful.

View

Add a comment

Modify Ticket

Action
as new
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.