LocDB draft (Request for comments)

Maintenance Interface
The maintenance interface is provided either by an additional wiki or by an extra namespace, say LocDB:, on shared:. Each database entry (location) is mapped onto an article in this wiki. In contrary to ordinary articles, a location article consists almost completely of heavily formalized templates that internally connect to the actual database. The database is updated when the corresponding location article is saved.

Reading Interface
Using location database information in an article on some language version is provided via templates. This way, contributors are able to profit from centrally stored information with a minimum of learning. For example, a template like could display a climate table where the amount of rain is displayed in mm, the average sunshine time in hours (what else) and the average temperature in °C.

Location's names
We need to know:
 * Local name(s) for the location
 * Transliterations of the local name(s), if necessary.
 * Article name in every language version (even if there is no article yet)

Input interface
Parameters name and lang are obligatory and provide the originally spelled name in language lang. This applies even to non-latin languages.

Parameter trans is optional. If necessary, a Latin transliteration may be given.

The locflag indicates whether the given name is a local name or the article name on some language version wiki.

Examples:

Here, the 2nd line indicates the Greek name as a (rather historical) local name that has a Latin transliteration. In contrary, the 5th line indicates the article name in the Greek language version.

All parameters for loccode are optional.
 * tld
 * Code according the ISO 3166 list.


 * iso3166-2
 * Code according the ISO 3166-2 list.


 * un
 * Code according the UN/LOCODE list.


 * cia
 * Code used in the CIA factbook.


 * gns
 * Code used in the GNS database.

Output interface
A wiki article in a language version might use this code:

Alexandria ist die zweitgrößte Stadt ....

that yields

Alexandria (arab.: الإسكندرية / al-Iskandarīya; griech.: Αλεξάνδρεια / Alexandreia) ist die zweitgrößte Stadt ...

Location's place in a Hierarchy
A unified hierarchy for all language versions is one of the big goals. It saves a lot of redundant discussions.

Input interface
isin

Each location must use exactly one isin template, but it may use multiple altisin templates.

The location-type indicates the type of the location. Possible types are: continent, country, region, city, district, outlying area, ..., admin-1, admin-2, ..., river, lake, mountain, desert, ... Admin- indicates an administrative unit.

Output interface
None. The location database information is automatically used for breadcrumb navigation or is displayed in the sidebar. Locations that do not have a corresponding article in the language version are omitted in the hierarchy.

Input Interface
The input template accepts several usual way for providing geographical coordinates as latitude/longitude pair.

or

or others.

The third precision argument is optional and indicates the failure tolerance the number of valid decimal places.

Area and elevation are indicated by two simple templates:

If the unit is omitted, km² or m, respectively, are assumed. Capital is the capital's location name (in general different from the local name).

Output Interface
Usually, no explicit output command is needed since geographical coordinates, area and elevation automatically appear in the Quickbox or at some other place. If they should appear at some contributor defined place, appropriate templates can be used:

where the display-flag flags whether the coordinates should be displayed in decimal, DMS, +/- or N/S, E/W format.

with optional unit(s) argument. If omitted, km² or m, resp., are assumed. Multiple, comma separated units are possible.

Statistical and demographical Data
Parameter year is optional, if omitted, the year of the current date is inserted.

Templates religion, lang-official and lang-use may be used more than once, ordered by importance.

Input interface


Maybe better like this:

Input interface
US$

Not all templates make sense for every type of location.

Usually, government, currency, currencyvalue, postIndexCountry, phoneprefixCountry, electricity, inet-tld and timezone only makes sense for country locations or in rare exceptions, otherwise.

If a location is not a country, the above templates are only neccessary if they differ from the usual country wide standards. Locations that are not cities or towns do not need postIndex and phoneprefix.

Distance tables
For both templates, parameters unit and by are optional.

Parameter by indicates the transport way and might by car, bus, train, ship, bicycle, walk, etc.

For template distance, unit defaults to km. For template traveltime, unit defaults to hours.

Climate Data
Typically, a climate table shows some specific values through the 12 months of a year. This could be values for the max. temperature, daily avr. temperature, amount of rain, wind strength, sunshine hours/day and others.

Input interface
parameter type indicates what kind of climatic data is given.

parameter unit is optional, although encouraged. Every type has its specific default unit.

The 12 numbers in between are the actual data through the 12 months. Unavailable data can be omitted, but, of course, the delimiting pipe symbol must be written in any case.

Examples:

Here, tempMax and rain are reserved words indicating the kind of data.

Output interface
This template can be used in the article wherever contributors need it:

Unit(s) is optional. If set, square brackets are needed. More than one unit, separated by a comma, are possible. E.g., for temperatures in both units, °C and °F, say

A climate chart accepts one or two units. If two units are required, 2 vertical axes are displayed, one for each unit.

Visit Card Data
For many places and institutions, e.g. hotels, museums, restaurants, bars, tourist offices, shops, bus terminals, railway stations, cinemas, etc., visit card like informations may provide some useful information framework.

Input interface

 * keyname
 * Optional. Used as key to address this institution. If omitted, name is used as key.


 * types
 * Comma seperated list of : pairs. Major types indicate properties like: museum, restaurant, ..., minor types add some more detailed information like: ethnological, technical, nautical, ... or vegetarian, italian, ...


 * name
 * The most current name in local language. Used as identifying key if no keyname given.


 * address
 * Address in local writing


 * phone
 * Local phone number as you would dial from inside the location.


 * mobile
 * Complete mobile phone number.


 * fax
 * Local fax number as you would dial from inside the location.


 * fax-mobile
 * Complete mobile fax number.


 * email
 * Email address


 * url
 * URL to the homepage


 * opening
 * Opening hours in 24 hour format. Possible formats are:
 * 8:00-17:00
 * 8:30-12:00, 14:00-18:00
 * 8:30-12:00, 14:00-openend
 * 8:30-~12:00, ~14:00-20:00
 * Mon, Thu: 8:30-12:00, 14:00-18:00 + Tue: 8:30-12:00 + Wed: closed + Fri-Sun: 6:30-12:00, 14:00-2:30
 * Mon-Wed: ondemand + Thu: 10:00-12:00, ondemand
 * Mar-Sep:: Tue-Fri: 8:00-18:00 + Sat-Mo: 6:30-20:00 ; Oct - Dec 15th:: 9:00-17:00


 * price
 * hm, how to standardize a format for reductions for minors, students, groups, etc.?


 * pricecat
 * Price category from A(noble) - H(very cheap). The price category is with respect to the local price level.


 * credit-cards
 * Accepted credit cards.

Output interface
displays all visit card information for the institution locname stored in the location database.

Input interface
US$