...
...
...
...
...
...
...
...
...
...
...
...
...
The purpose of having a standardized naming convention is to provide an organized framework for the datasets, ensuring interoperability between users and platforms. (See below for Naming Convention for Information Products)
Naming Convention for Datasets
...
The naming convention for datasets (which are used to generate information products but are not usually information products in and of themselves) is different from the naming convention for information products. This section describes the naming convention for datasets, including geodata and other datasets.
...
ISO3: The first part of the naming convention consists of the ISO3 code. For example: wrl, afg, alb, etc. Additional codes can be created for transnational datasets and are not limited to 3 characters. Example: hoa for horn of Africa. [OCHA taxonomy reference source]
Code + Data type: The feature code as defined in the Dataset Naming Code Table (See below) followed by the first letter of the data type where:
a = polygon
l = arc
p = point
t = text
r = raster (can be omitted for data where Code =
image)
Sub-Code (if applicable): The sub-ode (if applicable) as defined in Dataset Naming Code Table (See below). For example, for political boundaries sub-codes include: adm1, adm2, adm3, etc.
Scale (optional parameter, omitted for tabular data): The denominator for the scale of the dataset in the following form:
Example 1 – 1:1,000,000 = 1m
Example 2 – 1:250,000 = 250k
Example 3 – scale not known or of mixed scales (should be documented in metadata) = unk
Example 4 – scale not applicable for this dataset (such as utm zone boundaries or tabular data) = na (or omitted)
Example 5 – for raster data, this parameter is the nominal pixel size in kilometers, meters or cm = 30m, 130cm
Source: The acronym or short version of the source of the data.
Example 1 – United Nations Cartographic Section = uncs
Example 2 – Government of Guinea = govgin
Additional Description (optional parameter): This is a place holder for additional metadata that may make sense for a given type of dataset, such as:
a grid designator that may be used with datasets such as scanned toposheets or image datasets where the data is split into different files
a date stamp for data where the specific date of publication is critical (such as humanitarian profile or other frequently published datasets)
other metadata as needed
IMPORTANT NOTE: if the datasets are referenced by filename in other files (such as is common with MXD files) adding the date to the file name will often break the referring file when the date (and therefore the filename) is changed
Special Case 1: Two Datasets having the same naming convention
In the case where two datasets have the same name and there is insufficient time to clean the data to merge them to one dataset (see Data Cleaning in the Geodata Preparation Manual), numbers are used to differentiate between the two datasets and differences are specified in the metadata title and abstract until the data may be combined to one. The numbers run in descending order from the dataset at the lowest detail to the dataset at the highest detail. Consider the following:
Two sets of population data for a particular country, one has the population for major cities and the other population data for small towns. The data for major cities are labeled with a “1” and the data for small towns are labeled with a “2”.
Dataset 1: Major cities in Burundi from Government of Burundi at 1:1M scale
Dataset 2: Cities in Burundi from Government of Burundi at 1:M scale
Dataset Names (interim solution):
Dataset 1: bdi_pplp1_1m_gov
Dataset 2: bdi_pplp2_1m_gov
Feature Class Name (long term solution):
Combine the two feature classes to 1 using guidance from Verifying Geometry. The resulting label would be: bdi_pplp_1m_gov.
Special Case 2: Data do not span an entire country or region
In the case where the dataset only coverts part of a country, administrative names are used to differentiate between administrations and city names are used to differentiate between urban areas. See example below:
Datasets not covering an entire country:
Dataset 1: IDP Camps in Aceh, Indonesia
Dataset 2: IDP Camps Afgooye Cooridor, Somalia
Resulting Dataset Names:
Dataset 1: idn_aceh_cmpp_idp_1m_unhcr
Dataset 2: som_afgooye_cmpp_idp_1m_unhcr
File Naming Within Geodatabases
...
The naming of datasets (feature classes) within a Geodatabase is identical to the scheme defined above. A geodatabase feature class, shapefile, and KML representation of the same dataset would have the same name (exclusive of the file extension). However, for geodatabases, the file naming convention must also define the names of the geodatabase and feature datasets which contain the feature classes. An example geodatabase can be found in the folder structure.
Geodatabase name: The name of the geodatabase is from the International Organization for Standardization (ISO) country code, ISO3 code of the country/region of interest. For example: wrl, afg, alb, etc. [OCHA taxonomy reference source]
Feature dataset name: Feature datasets are objects that are used to group together related feature classes. There are two parts to the feature dataset name naming convention, each separated by an underscore (_). They are as follows:
...
Feature class name: As described above, the feature classes are named using the naming standard outlined above as if they were shapefiles.
Dataset Naming Codes Table
...
This table provides some of the codes and sub-codes to be used for naming datasets as described in the File Naming Convention. This list is not exhaustive and tries to address datasets commonly held by OCHA. Additional codes will almost certainly be needed by a country office to handle datasets particular to the local situation. If you would like advice on generating codes for other datasets, or if you have identified codes that you think will be useful for other offices, please Contact ISS in Geneva.
* Sub-codes denoted by an asterisk (*) should ideally be part of one more general dataset, where the features are differentiated in the attribute table and not through a separate feature dataset or feature class.
...
Naming Convention for Information Products
...
OCHA Field Map names are made of four parts separated by an underscore:
The catalog number, if in use (a good practice for catalog numbers is to have a three letter code for the country office and a sequential number)
A short map name (e.g. somalia_3w)
The paper size (A4, A3, A0, etc)
The date of publication in YYYYMMDD format.
Examples:
SUM001_aceh_reference_map_a4_20050128LBN001_Lebanon_reference_map_20081029template_sample_a4_20080917
Conventions relatives à l'attribution des noms de fichiers
L’objectif d’une convention d’appellation standardisée est de fournir un cadre organisé pour les ensembles de données, assurant l’interopérabilité des données entre les utilisateurs et les plateformes. (Voir ci-dessous pour la convention des produits d’information)
Convention relative à l'attribution des noms des ensembles de données
La convention des ensembles de données (qui servent à générer des produits d’information, mais qui ne sont pas des produits d’information en soi) est différente de la convention d’appellation des produits d’information. Cette section décrit la convention d’appellation des ensembles de données y compris les géodonnées et autres ensembles de données.
La convention d’appellation comporte 5 éléments, chacun étant séparé par un tiret du bas : _. Les éléments optionnels sont indiqués par des crochets : []. Comme ci-dessous
ISO3_Code+DataType_SubCode_[Echelle]_Source_[Description additionnelle]
Où :
ISO3 : La première partie de la convention d’appellation est constituée du code ISO3. Par exemple : wrl, afg, alb, etc. Pour les ensembles de données transnationaux, il est possible de créer des codes supplémentaires, ils ne sont pas limités à 3 caractères. Exemple : hoa pour horn of Africa (Corne de l’Afrique)
Code + Type de donnée : Le code de l’élément tel que défini dans le « Tableau des codes de désignation des ensembles de données » ci-dessous (Dataset Naming Code Table) est suivi de la première lettre du type de données :
a = polygone
l = arc
p = point
t = texte
r = raster - (peut être omis pour les données où Code =
image)
Sous-code (le cas échéant) : Le sous-code (le cas échéant), comme défini dans le « Tableau des codes de désignation des ensembles de données » (voir ci-dessous). Par exemple pour les limites politiques, les sous-codes incluent adm1, adm2, adm3, etc.
Echelle (paramètre facultatif, omis pour les données tabulaires) : Le dénominateur de l’échelle de donnée est sous la forme suivante :
Exemple 1 : 1:1 000 000 = 1m
Exemple 2 : 1:250 000 = 250k
Exemple 3 : échelle inconnue ou échelles mixtes (doivent être renseignées dans les métadonnées) = unk
Exemple 4 : échelle non applicable pour cet ensemble de données (comme les limites de la zone utm ou les données tabulaires) = na (ou omis)
Exemple 5 : pour les données raster, ce paramètre constitue et correspond à la taille nominale des pixels en kilomètres, mètres ou centimètres = 30 cm, 130cm
Source : Acronyme ou version abrégée de la source des données
Exemple 1 : Section de l’information géospatiale = uncs (United Nations Cartographic Section)
Exemple 2 : Gouvernement Guinéen = govgin
Description additionnelle (paramètre facultatif) : il s’agit d’un caractère de remplissage pour les métadonnées supplémentaires qui peuvent être utiles pour un autre type donné d’ensemble de données, par exemple :
Un indicatif de grille qui peut être utilisé avec des ensembles de données tels que des « toposheets » numérisés ou des ensembles de données d'images où les données sont divisées en différents fichiers
Une date-repère pour les données dont la date est fondamentale (comme par exemple pour le profil humanitaire ou d’autres ensembles de données fréquemment publiés
D’autres métadonnées si besoin
NOTE IMPORTANTE : si les ensembles de données sont référencés par nom de fichier dans d'autres fichiers (comme c’est souvent le cas avec les fichiers MXD), l'ajout de la date au nom du fichier entraînera souvent la rupture du lien de fichier de référence lorsque la date (et donc le nom du fichier) est modifiée.
Cas particulier 1 : Deux ensembles de données ayant la même convention d’appellation
Dans le cas où deux ensembles de données ont le même nom et que vous manquez de temps pour nettoyer les données afin de les fusionner en un seul ensemble de données (voir le nettoyage de données dans le Manuel de préparation des géodonnées), des numéros sont utilisés pour différencier les deux ensembles de données. Les différences sont spécifiées dans le titre et dans le résumé des métadonnées et ce, jusqu’à ce qu’ils puissent être combiné en un sel ensemble. Les numéros sont ordonnés par ordre décroissant de l'ensemble de données le moins détaillé à l'ensemble de données le plus détaillé. Considérez ce qui suit :
Deux ensembles de données démographiques pour un pays donné ; l’un contient la population des grandes villes et l’autre, les données démographiques des petites villes. Les données pour les grandes villes sont marquées d’un « 1 » et les données concernant les petites villes sont marquées d’un « 2 ».
Ensemble de données 1 : Principales villes du Burundi provenant du gouvernement du Burundi à l’échelle 1:M.
Ensemble de données 2 : Villes du Burundi provenant du gouvernement du Burundi à l’échelle 1:M.
Noms des ensembles de données (solution provisoire) :
Ensemble de données 1: bdi_pplp1_1m_gov
Ensemble de données 2: bdi_pplp2_1m_gov
Caractéristiques du nom de catégories (solution à long terme) :
Combinez les deux catégories en une, en utilisant les directives sur la Vérification de la géométrie (guidance from Verifying Geometry). Le nom qui en résulterait serait : bdi_pplp_1m_gov.
Cas particulier 2 : Les données ne couvrent pas l’ensemble du pays ou de la région.
Lorsque l’ensemble de données ne couvre qu’une partie d’un pays, des noms administratifs sont utilisés pour différencier les administrations, des noms de villes, des zones urbaines. Voir l’exemple ci-dessous :
Les ensembles de données ne couvrent pas la totalité d’un pays :
Ensemble de données 1: IDP Camps à Aceh, Indonésie
Ensemble de données 2: IDP Camps Afgooye Cooridor, Somalie
Noms des ensembles de données qui en résultent :
Ensemble de données 1: idn_aceh_cmpp_idp_1m_unhcr
Ensemble de données 2: som_afgooye_cmpp_idp_1m_unhcr
Convention relative à l'attribution des noms de bases de données géospatiales (Geodatabases)
Le nom des ensembles de données (bases de données de détails géographiques – feature classes) dans les bases de données géographiques suit la logique du schéma précédent, décrit ci-dessus. Une « feature class » de bases de données géospatiales, un fichier de forme (shape file) et une représentation KML du même ensemble de données porteraient le même nom (à part l'extension du fichier). Cependant, pour les bases de données géospatiales, la convention d’appellation doit également définir les noms des bases de données géospatiales et des bases de données de détails géographiques (feature datasets) qui contiennent les « feature classes ». Un exemple de base de données géospatiales est disponible sur la page Structure des dossiers/folder structure.
Nom des bases de données géospatiales (Geodatabases) : Le nom de la base de données géospatiale provient du code pays de l’Organisation Internationale de Normalisation (ISO) code pays. Soit, le code ISO3 du pays ou de la région concernée. Par exemple : wrl, afg, alb, etc.Nom des bases de données de détails géographiques (Feature dataset) : Les « feature datasets » sont des objets utilisés pour regrouper les classes de détails géographiques (feature classes) apparentées. La convention d’appellation des bases de données de détails géographiques « feature dataset » comporte deux parties, chacune séparée par un tiret du bas : (_). Elles se présentent de la manière suivante :
ISO3 Code – Comme pour le nom des bases de données géospatiales, la première partie du nom, selon la convention d’appellation est constituée du code ISO3 relative au pays ou à la région. Par exemple : wrl, afg, alb, etc.
Sujet : Le sujet correspond au dossier dans la structure de données où les données se trouvaient dans les formats de fichiers plats (flat file format) (fichier de forme (shapefile), kml, xls, etc.). Ces sujets peuvent être trouvés dans le tableau des codes d’appellation des ensembles de données ou sur la page Structure des dossiers/folder structure.
Nom des classes de détails géographiques (Feature class) : Comme décrit ci-dessus, les « feature class » sont nommées selon la norme d’appellation décrite ci-dessus, comme si elles étaient des fichiers de forme (shapefiles).
Tableau des codes d’appellation des ensembles de données
Comme décrit dans la convention d’appellation des fichiers, le tableau ci-dessous fournit certains codes et sous-codes à utiliser pour nommer les ensembles de données. Cette liste n’est pas exhaustive, cependant elle répertorie les ensembles de données les plus communément détenus par OCHA. Un bureau pays aura certainement besoin de codes supplémentaires pour traiter les ensembles de données propres à la situation locale. Si vous souhaitez obtenir des conseils pour générer des codes d’autres ensembles de données, ou si vous avez identifié des codes qui vous semblent utiles pour d’autres bureaux, s'il vous plaît, veuillez contacter ISS à Genève.
Les sous-codes marqués d’un astérisque (*) devraient idéalement faire partie d’un ensemble de données plus général, où les détails cartographique (features) sont différenciés dans la table attributaire des valeurs (attribute table) et non par un « feature dataset » ou un « feature class » distinct.
...
Convention relative à l'attribution des noms des produits d’information
Les noms des cartes de terrain produites par OCHA sont composés de quatre parties séparées par un tiret du bas :
Le numéro de catalogue, s’il est utilisé (une bonne pratique pour les numéros de catalogues : avoir un code à trois lettres pour le bureau de pays et un numéro séquentiel)
Un nom court (pour une carte) peut être par exemple : Somalia_3W
Le format papier (A4, A3, A0, etc.)
La date de publication au format AAAAMMJJ
Exemple :
SUM001_aceh_reference_map_a4_20050128LBN001_Lebanon_reference_map_20081029template_sample_a4_20080917