Annexe 5: Exposé de quelques cas d'étude

Cas d'étude n° 1: Programme Guinee/Pechind
Cas d'étude n° 2: Programme Guinée/Artisanal/Recens
Cas d'étude n° 3: Programme Guinée/Artisanal/Pechart
Cas d'étude n° 4: Programme Sénégal/Artisanal/Pechart
Cas d'étude n° 5: Programme Maroc/Artisanal
Cas d'étude n° 6: Programme Maroc/Pêche Artisanale/Ma_Recens2
Cas d'étude n° 7: Programme Maroc/Pêche Artisanale/Ma_Pechart2

Remarque préliminaire: l'ordre de présentation des cas d'étude correspond à un apprentissage progressif de l'utilisation du modèle. Il est donc conseillé une lecture ordonnée des cas exposés.

Cas d'étude n° 1: Programme Guinee/Pechind

Table PROGRAM: le code est GN_PECHIND et se retrouve dans la plupart des fichiers. Le titre du programme est "Suivi statistique par observateurs embarqués de l'activité (captures, débarquement et effort) de la pêche industrielle et de la pêche artisanale avancée en Guinée"

Références Objets géogr. programme (Port et pays): table PRGGEO (voir description du remplissage au niveau de AGREMENT et TRIP);

Informations jeu de donnée: Table DATAINFO

Les données sont les données de base (donc échantillon) collectées par les observateurs embarqués à bord des bateaux. Le niveau de connaissance est l'unité d'observation de l'activité: le coup de chalut. Deux années d'observations vont être injectées dans le modèle, les dates début et fin du jeu de donnée sont 01/01/1994 à 31/12/95.

La couverture géographique (champ CSPLIBEL) est "Plateau continental de la ZEE Guinéenne"

Résolution temporelle registre: une liste annuelle des bateaux qui ont eu dans l'aimée une autorisation de pêche est dressée

Résolution temporelle licence: les autorisations sont trimestrielles

Résolution temporelle Armement: la liste des propriétaires de bateaux autorisés à pêcher est dressée chaque année

Résolution temporelle Excursion: une occurrence de la table excursion concerne une marée (code TRIP); c'est aussi une idée de la durée moyenne d'une marée du jeu de donnée qui pourrait être indiquée ici (en effet, le code TRIP est redondant avec le code ONEEXC utilisé dans le champ TRIPTYPE ci-dessous)

Résolution temporelle Unité d'Observation de l'Activité: une occurrence de la table UOACT concerne une opération de pêche (code STATION)

UETYPE: l'unité d'exploitation représente un bateau (code VESSEL)

TRIPTYPE: il s'agit d'une marée individuelle (code ONEEXC)

UOATYPE: station

Le temps de mer correspondant à la durée d'une marée est donné en jours, alors que le temps de pêche correspondant à la durée d'une opération de pêche est en heures (décimales).

Résolution temporelle: Table RESTEMP, RTUNIT, DATART

Deux saisons sont distinguées en Guinée: la saison des pluies et la saison sèche. Pour pouvoir utiliser cette résolution temporelle non-encore renseignée dans les fichiers de référence, on ajoute dans RESTEMP un code GN2SEAS, explicité dans RTUNIT avec les codes PLU (pour saison des pluies, allant du 1^er juin au 30 novembre) et SEC (pour saison sèche, allant du 1^er décembre au 31 mai).

Une résolution temporelle qui sera compatible avec le jeu de donnes est au minimum les saisons distinguées en Guinée. D'autres résolutions temporelles pourraient être décidées par les thématiciens, par exemple le mois si un des objectifs est de comparer la localisation de l'effort avec des donnés collectées pendant une campagne de chalutage. Les Res Temp qui ne seront pas déclarées compatibles avec le jeu de donnée ne seront pas utilisables lors des requêtes de création des groupements.

Engin de pêche

Il y a 8 types d'engins répertoriés par le jeu de donnée, codifiés par un numéro. Ces 8 types ont une correspondance exacte dans le fichier international de référence. Les types sont donc cochés sur le listing correspondant à ce fichier, ce qui permettra d'extraire ces enregistrements pour créer le fichier DTGEAR. L'analyse des listes d'engins déclarés par les armateurs montre qu'il est aussi nécessaire de définir 8 mixités d'engin composées d'au maximum 2 engins chacune (cf Table MPGEAR). Les huit occurrences correspondantes de la table DTGEAR seront reliées à l'enregistrement Mixité du fichier GEAR.

Niveau registre

La présence des bateaux étant conditionnelle du cadre légal, on considère d'abord celui-ci:

Accord de pêche (table AGREMENT): le cadre légal est rediscuté chaque année dans le cadre d'un plan de pêche. Le code Accord (AGRCODE) est donc PLAN94, ou PLAN95, et les dates de début et de fin de validité sont du 1^er janvier au 31 décembre de chaque année. Le type d'accord et la flotte cible ne sont que des informations à compléter si connues. Le code ZEE est "GN". Ce code sera repris dans la couverture ZJURID1 (champ ZEE) décrivant les contours de la ZEE. La table PRGGEO décrit où se trouve le plan cartographique ZJURID1, et quel attribut de ce plan il faut consulter pour faire le lien avec cette ZEE

Licences: Dans le cadre de chaque plan, on révise la définition des licences (6 licences sont définies dans le plan 94), incluant la zone autorisée par chaque licence. Chaque licence est définie par un code explicite à l'utilisateur (par exemple LICCODE = "PPEL" pour LICNAME = "pêche pélagique"). Le nom de la zone autorisée est ici ZAUTNAME = "au-delà de 80 miles". Il n'y a pas de variation intra-annuelle des contours d'une licence donnée, donc la résolution temporelle est PERIOD (RTUNIT n'ayant pas de sens est alors laissé en blanc). Le plan cartographique permettant de trouver les objets décrivant les contours de la zone autorisée par cette licence a pour adresse ARCCOV = "GN\JURID\ZAUTH2\PAT.DBF" (les zones autorisées pour 1995 sont dans le plan ZAUTH2), et tous les objets de ce plan ayant pour attribut "PPEL" dans le champ ZAUTH1 sont concernés par cette licence (il faut donc donner la valeur ZAUTH1 à ARCITEM, et la valeur "PPEL" à ZAUTCODE). Pour l'occurrence suivante de ce fichier concernant la licence démersale poissonnière, les champs seraient remplis de la manière suivante: LICNAME = "démersale poissonnière", LICCODE = "PDEM" ARCCOV ⁼ "GN\JURID\ZAUTH2\PAT.DBF", ARCITEM = "ZAUTH2", ZAUTCODE = "PDEM".

Dans le cadre de l'attribution de ces licences de pêche, un bateau doit fournir un certain nombre d'informations. Ces informations sont réparties selon 4 tables selon leur nature:

- informations spécifiques du bateau (table BOAT): identifiant du bateau (C4) donné lors de la première demande de licence, nom du bateau, puissance, TJB, année construction, longueur, largeur, capacité de stockage, numéro d'immatriculation, code radio. Dans ce fichier, tous les bateaux répertoriés sur toute la série temporelle apparaissent une seule fois. Si un bateau a changé de nom, on met dans LAST_REF son ancien code.

- informations communes à plusieurs bateaux (table EXPLUNIT): le codid de BOAT est répété dans UECODE. Les caractéristiques communes à plusieurs bateaux concernent le type d'exploitation (INDustriel), le mode de conservation. Les champs CLAS ne sont pas renseignés, car ils correspondent aux champs TJB POWER et DATCONST du fichier bateau. Ils seront remplis lors d'éventuelles requêtes groupements. Les autres champs MODCONS, PORTSENS, PORTORIG, FLAG_UE, STAFF_UE, AGRCODE et LICCODE ne sont pas à renseigner ici car ils ont des équivalents "donnée enregistrée" dans les tables MPBOAT, ARME et AUTHORIZ (incluant la dimension temporelle).

- existence actualisée du bateau et de ses moyens de production (Tables MPBOAT, MPGEAR....): la liste des bateaux concernés par les licences est revue annuellement. L'existence d'une unité d'exploitation comme moyen de production est donc renseignée dans ce fichier chaque année: pour chaque année concernée par le jeu de donnée et pour les unités d'exploitation existant dans la liste de cette année là, serait créée une occurrence de ce fichier composée des informations: codid de l'unité d'exploitation (donc du bateau), date début (1^er janvier de l'année), date fin (31 décembre de l'année), le mode de conservation (besoin de rajouter les codes nationaux eu évaluant leur existence préalable dans la table des codes), le statut du bateau (qui est par défaut considéré comme actif dans l'année, puisqu'il a acheté une licence, sauf si certaines enquêtes ont mis en évidence son inactivité) et le nombre d'unités d'exploitation = à 1 (un bateau par unité d'exploitation). Concernant les engins de pêche répertoriés au niveau registre (fichier MPGEAR), il est possible d'intégrer les engins déclarés dans le formulaire à remplir pour avoir une licence; l'armateur peut déclarer un à trois engins: il faut donc considérer toutes les combinaisons d'engin possibles, et affecter un code engin à chacune (il s'agit donc d'une mixité d'engin). Le nombre d'engins sera eu général égal à 1. Aucun attribut n'est disponible pour alimenter MPPROPEL et MPFSHMAN.

Propriété des navires: L'information sur les propriétaires existe: il s'agit dans tous les cas de compagnies (ou sociétés) dont on dispose du nom. Le code n'existe pas dans l'état actuel de l'information disponible, mais il peut être rapidement généré par exemple en index séquentiel.

Armement des navires: dans cette entité figurent des données dûment enregistrées: port d'attache (non encore saisi), statut juridique et nationalité. Ce dernier champ est considéré comme géographique et il sera possible de relier l'information nationalité à une carte des pays, à condition d'adopter comme code pour FLAG_REG le code pays international distribué avec la carte mondiale des pays. Pour chaque année et chaque bateau répertorié dans l'année pour avoir acquis une autorisation de pêche, il existe une occurrence dans le fichier ARME.

Autorisation de pêche: il existe un numéro de licence (séquentiel par trimestre et type de licence) délivré pour chaque bateau autorisé. Une occurrence du fichier AUTHORIZ comprendra donc le code licence acquis par le Codid bateau, la date début et fin du trimestre et le numéro de licence.

Niveau excursion:

Marée: Pour une marée en pêche industrielle, on a une occurrence du fichier TRIP spécifiant un nombre de marées égal à 1. La date de fin d'excursion correspond à un transbordement ou un débarquement. On connaît la date d'embarquement de l'observateur (à Conakry après l'entrée du bateau dans la ZEE et avant que le bateau ne parte en pêche, où à Dakar, voire Las Palmas par exemple, avant que le bateau ne parte en mer destination ZEE Guinée), et de débarquement. A défaut d'information certaine sur la date de débarquement, la date de débarquement de l'observateur est vraisemblablement la date de fin de marée et celle de son embarquement celle de début de marée. Le lieu de débarquement de l'observateur est parfois inscrit sur les fiches. Le pays de débarquement du poisson, voire le port, peuvent être aussi identifiés par connaissance experte. Si l'on décide donc de considérer l'attribut lieu de débarquement comme informé, il faudra créer si nécessaire un plan cartographique ARC INFO LSITE où seront référencés à la fois des objets Port, pays, rade et lieu inconnu, et affecter le code pays, port, rade, lieu inconnu dans le champ LPLCODE de TRIP. Une occurrence du fichier PRGGEO décrira alors l'adresse de ce plan cartographique LSITE, avec ARCCOV = "GN\PECHIND\LSITE\PAT.DBF", ARCITEM = "LSITE" (car c'est dans le champ LSITE de la table attributaire du plan cartographique LSITE que seront stockés les codes pays, port, rade, lieu inconnu). Le temps de mer (en jours) à date fin excursion moins date début excursion. Aucune information n'est disponible sur l'équipage (donc pas d'information sur le qualificatif culturel hé à la pratique de pêche). Si l'observateur dressait l'inventaire des engins à bord, on pourrait informer le champ GEARTRIP avec s'il le faut une mixité d'engin. Le poids total débarqué n'est connu que pour les glaciers débarquant à Conakry, et parfois pour les congélateurs débarquant hors Guinée. On a le choix de considérer l'attribut comme non informé (même si pour ne pas perdre de donnée, on laisse le champ et on y met les quelques informations disponibles), ou de considérer l'attribut comme informé, il faut alors mettre -1 pour toute donnée non disponible. Il n'y a aucune information relative aux ventes commerciales (TOTLWVAL, CURRENCY). Le champ valide est déclaré "N" si l'enregistrement marée est considéré comme non valide (par ex: si une analyse montre que les informations collectées par l'observateur sont systématiquement fausses). Tant qu'aucun, profil spécifique n'est attribué au débarquement, le code PRODPRFL n'est pas informé; si une analyse est menée par la suite, il faudra alors expliciter les différents codes profil spécifique dans le fichier des codes (en vérifiant que le code n'est pas déjà utilisé par un autre profil de production), et déclarer dans DATAINFO l'attribut PRODPRFL comme informé.

Production débarquée par espèce: pour chaque marée pour laquelle les quantités débarquées par espèce existent, on a autant d'occurrences dans PRODUCT qu'il y a de groupes d'espèces dont le poids débarqué est non nul. Les codes espèces et groupes sont référencés respectivement dans les fichiers SPECIE et GROUP, tandis que la composition des groupes en espèces est listée dans GRPDEF.

Unité d'observation de l'activité:

Opération de pêche: chaque occurrence de la table UOACT concerne les attributs d'une opération de pêche, le nombre d'opération est donc égal à 1 Une opération de pêche (trait de chalut par exemple) est représentée par un objet de type ARC limité par les coordonnées début et fin, et porte un numéro séquentiel démarrant chaque jour à 1. Ce numéro séquentiel est stocké dans OBJ_ID, tandis que UOA_ID stocke le numéro séquentiel du coup de chalut dans la table attributaire du plan cartographique FOPE. Dans ce fichier attributaire du plan cartographique FOPE, on retrouve au minimum tous les champs composant la clé de UOA, ainsi que d'autres informations comme la bathymétrie, la position médiane calculée pour l'opération de pêche. La longueur du trait de chalut peut être utilisée comme critère de validation minimum des positions (par ex à partir d'une étude statistique des longueurs): toutes les opérations de pêche douteuses peuvent être déclarées comme VALID = "N" dans le fichier UOACT jusqu'à correction des positions. On ne connaît pas l'engin utilisé, on a les références temporelles date, heure début, heure fin (qui permettent de calculer le temps de pêche, eu unités déclarées dans DATAINFO); on peut calculer le poids total nominal par opération à partir de la capture par catégorie statistique, on dispose du nombre de catégories statistiques capturées qui sont référencées dans le fichier CATCH, on a une information rejet total (mais pas d'information rejet spécifique). Comme pour le profil spécifique de débarquement, on pourrait renseigner le profil de capture par coup de chalut (après analyse ou décision experte).

Référence géographique opération de pêche (entité "Lieu de pêche"): l'information géographique représentée par est stockée par année dans les plans cartographiques FOPE94, FOPE95 (soit environ 10000 données pour 1994). L'occurrence du fichier UOA_GEO décrivant le plan cartographique FOPE94 aura donc pour information la date début (1^er janvier 1994), la date fin (30 septembre 1994 car le troisième trimestre n'existe pas), l'adresse du plan cartographique (GN\PECHIND\FOPE94\PAT.DBF) et le champ considéré pour la clé de lien avec UOACT (ARCITEM = FOPE94_ID).

Captures: ou met dans le fichier CATCH des captures par catégorie statistique après rejet pour chaque opération de pêche (il ne s'agit donc pas de captures nominales). (Faut il introduire une nouvelle statistique?). Pour une opération de pêche donnée, chaque occurrence du fichier CATCH concerne le poids d'une espèce ou d'un groupe d'espèce (en unités déclarées dans DATAINFO). Les codes espèce et groupes sont les mêmes pour les fichiers PRODUCT et CATCH.

Il n'y a pas d'information détaillée au niveau engin, et par conséquent pas de type d'effort à définir ni d'effort standard calculable.

Remarque: La pêche artisanale avancée (petits bateaux glaciers basés à Conakry faisant des marées d'une journée) est incluse dans ce programme PECHIND, mais ne fait jamais l'objet d'embarquement d'observateurs. Au niveau registre, ces bateaux suivent les mêmes règles d'enregistrement que les bateaux de la PI. L'activité de ces bateaux est suivie au niveau des débarquements par enquête au port; cependant, on ne référence pas dans ces enquêtes la localisation de l'activité en mer (donc pas d'info au niveau UOA). Ces différences imposent d'intégrer ces données relatives à la pêche artisanale avancée dans le cadre d'un autre champ jeu de donnée niveau EXC.

Cas d'étude n° 2: Programme Guinée/Artisanal/Recens

Table PROGRAM:

Le code programme est GN_RECENS: Recensement des moyens de production de la pêche artisanale sur le littoral guinéen. Il s'agit d'un programme de type recensement (donc PRGTYPE = SENSUS)

Références Objets géogr. programme (Port et pays): table PRGGEO (voir description du remplissage au niveau de EXPLUNIT)

Informations jeu de donnée: Table DATAINFO

Les données sont les données de base (donc échantillon) collectées par les enquêteurs. Le niveau de connaissance est limité au registre (REG). Le jeu de donnée injecté ne concerne qu'un recensement, celui de 1995, censé représenter une situation annuelle (Date début = 1^er janvier 95, date fin = 31 décembre 95). D'autres recensements constitueront d'autres jeux de données, sauf s'il est possible de considérer que les informations collectées d'un recensement à l'autre sont suffisamment homogènes, auquel cas un jeu de données peut concerner plusieurs recensements (dans ce cas, les dates début et fin du jeu de donnée encadrent la période pour laquelle on a plusieurs recensements, et les limites de validité des informations collectées pour chaque recensement sont indiquées au niveau des entités du niveau registre comportant les dates début et fin).

La couverture géographique (champ CSPLIBEL) est le "littoral Guinéen" (pour le recensement de 1988, on aurait mis "presqu'île de Conakry")

Résolution temporelle registre: la donnée recensement est considérée comme représenter une situation annuelle, donc reso temp. annuelle.

Résolution temporelle licence: les pirogues ont une autorisation implicite (de par le code de la pêche), ou considère donc que n'ayant pas à renouveler de licence, la résolution temporelle licence est PERIOD.

Résolution temporelle Armement: la liste des propriétaires est établie à chaque recensement, la résolution temporelle armement est donc annuelle.

Résolution temporelle Excursion: champ laissé à blanc, car le jeu ne concerne pas le niveau excursion.

Résolution temporelle Unité d'Observation de l'Activité: champ laissé à blanc, car le jeu ne concerne pas le niveau excursion.

UETYPE = VESSEL, car chaque pêcheur est interrogé, et donne des renseignements sur chacune de ses pirogues; le type d'unité d'exploitation est donc l'embarcation.

TRIPTYPE: champ laissé à blanc

UOATYPE: champ laissé à blanc.

Résolution temporelle: Table RESTEMP, RTUNIT, DATART

La résolution temporelle la plus fine compatible avec le jeu de donnée est l'année. Les autres Res Temp non compatibles avec le jeu de donnée ne seront pas utilisables lors des requêtes de création des groupements.

Engin de pêche

Il y a 13 types d'engins répertoriés par le jeu de donnée, codifiés par 7 caractères. Ces 13 types ont une correspondance exacte dans le fichier international de référence. On crée donc le fichier DTGEAR. Si certains engins ciblent une espèce ou un groupe d'espèces, il faut alimenter le champ TARGSPEC avec le code de l'espèce ou du groupe d'espèce figurant dans le fichier SPECIE ou GROUP. Par ailleurs, il est possible d'ajouter les informations techniques relatives à chaque type d'engin, en exploitant les données d'une typologie sur ces engins. Certains champs manquant éventuellement dans DTGEAR pourraient être ajoutés à l'occasion. Des mixités d'engin pourraient aussi alimenter ce fichier, si des problématiques liées à l'existence pour une pirogue donnée d'une combinaison d'engin étaient définies.

Niveau registre

La présence des bateaux étant conditionnelle du cadre légal, on considère d'abord celui-ci:

Accord de pêche (table AGREMENT): le cadre légal concerne l'ensemble des flottilles travaillant en ZEE Guinée. C'est donc celui déjà présenté pour le programme GN_PECHIND. Il faut cependant dupliquer l'enregistrement PLAN95 du fichier AGREMENT en changeant le PRGCODE. Il faut faire de même dans la table PRGGEO. Si un jeu de donnée correspondant au recensement 1992 est intégré dans la base, alors on a le choix d'informer la partie juridique ou non. Si on prend la décision de l'intégrer, il faut alimenter la base avec les cadres juridiques prévalent en 1992.

Licences: Les embarcations concernées par le recensement sont les pirogues, qui ont accès à l'ensemble de la ZEE. Il n'existe pas de licence pour la pêche artisanale. On va donc créer une licence virtuelle, autorisant par défaut aux pirogues l'accès à l'ensemble de la ZEE (par exemple LICCODE = "PART", LICNAME = "pêche artisanale", et ZAUTNAME ⁼ "toute la ZEE"). Mêmes remarques pour compléter ce fichier que pour GN_PECHIND.

L'information sur le parc de pirogues étant connue à travers les propriétaires, la description du jeu de données continue avec la table PROPERTY.

Propriété des navires: Il s'agit dans la majorité des cas d'individus dont on a les noms (champ PROPNAME), mais certains individus peuvent représenter des coopératives. En l'absence de certitude, on n'informera pas le champ type de propriétaire PROPTYPE. Pour chaque recensement, on a un numéro séquentiel unique de chaque pêcheur, mais d'un recensement à l'autre, on n'est pas capable de reconnaître le même propriétaire. On sera donc amené à créer une liste de propriétaires par recensement si l'on intègre plusieurs recensements. Il faut donc considérer les listes comme distinctes, et faire attention de générer un numéro séquentiel pour l'ensemble du programme (il n'y a pas de DTINDEX dans PROPERTY). Dans le recensement 95, il n'est pas demandé la nationalité, ni le lieu d'origine (ou siège social PROPHQ) du propriétaire. Dans le recensement 1992, ces données existaient mais n'ont pas été saisies. Il faut évaluer l'intérêt de saisir cette information. Une indication sur deux types d'activité possibles du propriétaire existe cependant: ces champs qui n'étaient pas prévus initialement dans le modèle ont été ajoutés; ces attributs pourront même être exploités dans le cadre de groupements d'exploitation moyennant quelques modifications mineures.

Les informations demandées au pêcheur concernant ses pirogues sont stockées dans BOAT, EXPLUNIT, MPBOAT et MPGEAR, en fonction de leur nature:

- informations spécifiques du bateau (table BOAT): une pirogue est avant tout connue et identifiée par le fait qu'elle appartient à un propriétaire ("ma pirogue n°1, n°2, etc..."); un code pirogue est donc créé en concaténant le code séquentiel propriétaire (C5) et le numéro séquentiel pirogue (-C2) (codid est par exemple "00098-01"). On obtient donc un code pirogue unique pour l'ensemble du programme, tous recensements (donc jeux de données) confondus. On dispose du nom de la pirogue, la puissance du moteur (hors bord) (POWER = 0 s'il n'y a pas de moteur). Pour le recensement 92 existe aussi l'année de construction de la barque.

- informations communes à plusieurs bateaux (table EXPLUNIT): le codid de BOAT est répété dans UECODE. Les caractéristiques communes aux pirogues concernent le type d'exploitation (toutes sont ARTisanal), le type de construction (par exemple Salan, Booti, Yoli ... - il faut aller compléter le fichier CODE.dbf avec les codes nationaux utilisés pour décrire les types de construction), le matériel de construction qui est systématiquement "bois" (que l'on peut donc choisir de renseigner ou non). La présence ou non d'une glacière est collectée sur les formulaires d'enquête (systématiquement?) et peut donc alimenter le champ "mode de conservation" du fichier EXPLUNIT (les pirogues de la base de donnée ayant une existence implicite d'une année, ce n'est pas la peine d'alimenter le champ MODCONS de MPBOAT puisque la période d'existence reportée dans ce dernier fichier n'ajoute aucune information sur un éventuel changement de mode de conservation). Le port de recensement est connu (le code port est un numérique qu'il faut transformer en caractère): il s'agit d'un objet géographique qu'il faut relier avec sa représentation sous ARC INFO: l'information nécessaire pour cela est stockée dans PRGGEO: l'occurrence de PRGGEO indiquera que pour la table EXPLUNIT, champ PORTSENS, il faut aller chercher le plan cartographique dans le répertoire ARCCOV = "GN\RECENS\LSITE\PAT.DBF", et le code figurant dans PORTSENS permet de faire le lien avec les objets géographiques grâce au même code figurant dans le champ ARCITEM = "PORT". Le champ PORTORIG pourrait éventuellement être renseigné pour indiquer le port d'origine de la pirogue (on peut supposer que toutes les pirogues d'un même propriétaire auquel on a posé la question de son lieu d'origine viennent de ce lieu). Il s'agit aussi d'un champ géographique à gérer de la même manière que PORTSENS. L'ethnie à laquelle appartient l'équipage de chaque pirogue est une information collectée auprès du propriétaire, et peut donc alimenter le champ STAFF_UE il faut renseigner sur les codes utilisés dans le fichier CODE.DBF). La nationalité n'est pas recensée (elle peut être déduite de l'ethnie). Les champs CLAS ne sont pas renseignés (le champ POWCLAS sera rempli lors d'éventuelles requêtes groupements. Les champs AGRCODE et LICCODE sont à renseigner avec le code indiqué dans les fichiers AGREMENT et LICENCE (voir commentaire au niveau de la table AUTHORIZ).

- existence actualisée du bateau et de ses moyens de production (Tables MPBOAT, MPGEAR...): l'existence entre les dates t et t+1 d'une unité d'exploitation pirogue répertoriée dans le recensement est renseignée dans le fichier MPBOAT: les dates t et t+1 concernent la durée de validité prêtée au recensement (datedeb = 01/01/95 et datefin = 31/12/95). Lors du recensement, le statut d'activité de chaque pirogue est établi (champ STATUT). Une unité d'exploitation représentant une pirogue, le nombre d'unités d'exploitation = à 1 (un bateau par unité d'exploitation). Concernant les engins de pêche (fichier MPGEAR), il est demandé au pêcheur la liste des engins qu'il embarque sur chaque pirogue: pour une unité d'exploitation donnée, on aura donc autant d'occurrences dans le fichier MPGEAR qu'il y a d'engins dans la liste fournie par le pêcheur pour cette pirogue; pour un engin déclaré, on indiquera sou code (GEARCODE), on précisera s'il s'agit d'un engin cible (TARGGEAR), on informera les dates début et fin (idem MPBOAT), et le nombre d'engin = à 1 par défaut. Aucun attribut n'est disponible pour alimenter MPFSHMAN: on pourrait cependant décider de renseigner MPFSHMAN avec un nombre probable de pêcheurs par type de pirogue, si des analyses ont déjà été menées (par exemple, il a été demandé dans le recensement 92 le nombre de pêcheurs embarqués par pirogue répertoriée). Enfin, on choisit de ne pas renseigner MPPROPEL car seule l'information puissance du moteur est collectée (s'il n'y a pas de moteur, on n'indique pas d'alternative - rame ou voile) et déjà stockée dans BOAT dans le champ POWER (si POWER = 0, alors il n'y a pas de moteur hors bord). En vue de l'alimentation du niveau 2, on pourrait aussi décider de renseigner cette table en indiquant pour chaque pirogue une des deux options suivantes: moteur hors bord, ou pas de moteur. Ce fichier pourrait aussi être utile pour renseigner l'existence de plusieurs moteurs par pirogue.

Armement des pirogues (fichier ARME): les dates début et fin concernent l'année du recensement. Une occurrence de ARME relie le code propriétaire au code d'une de ses pirogues. Les informations PORTREG et STAFREG sont déjà portées dans PORTORIG et STAF_UE du fichier EXPLUNIT, il n'y a donc pas lieu de les répéter . On choisira d'informer plutôt le fichier EXPLUNIT que le fichier ARME, ce dernier n'ayant pas grande signification lorsque l'information dans les fichiers PROPERTY, ARME et BOAT ont la même existence temporelle. On ne connaît pas le statut juridique liant le propriétaire à la pirogue.

Autorisation de pêche: la licence étant implicite, il n'existe pas de document attribuant un numéro de licence. Le fichier AUTHORIZ n'est donc pas alimenté. C'est le champ LICCODE de EXPLUNIT qui est renseigné.

Cas d'étude n° 3: Programme Guinée/Artisanal/Pechart

Introduction: le plan d'échantillonnage démarré en janvier 1995 est la troisième phase d'un programme d'enquête qui a commencé sur la presqu'île de Conakry en 1987, puis s'est étendu à partir de 1989 sur quelques débarcadères du littoral Guinéen, pour se généraliser enfin à l'ensemble du littoral eu 1995. Si les protocoles de collecte de ces trois phases sont trop différents, il faudrait créer trois jeux de données.

Nous ne considérerons dans ce cas d'étude que la phase qui a débuté en janvier 1995. Deux types de données (donc deux jeux de donnée) peuvent être intégrés dans la base, sans être à ce stade de développement du modèle reliés:

- données échantillon collectées par sortie de pirogue: les groupements d'exploitation permettront de suivre de suivre une activité par port et site de pêche, en gardant à l'esprit qu'il ne s'agit que d'une donnée échantillon;

- données compilées par mois, site de débarquement (puis préfecture à une échelle inférieure), et type d'engin; la localisation de cette activité en mer au niveau extrapolé n'est pas prévue dans le protocole d'extrapolation.

Le jeu de données échantillon parait le plus intéressant à intégrer dans la base à ce stade d'analyse et d'exploration du SIG.

Table PROGRAM:

Le code programme est GN_PECHART: "Suivi de l'activité (statistiques effort-captures) de la pêche artisanale sur le littoral guinéen". Il s'agit d'un programme de type enquête à terre (donc PRGTYPE = "GRNDSAMP")

Références Objets géogr. programme (Port et pays): table PRGGEO (voir description du remplissage au niveau de EXPLUNIT et UOACT)

Informations jeu de donnée: Table DATAINFO

Les données sont les données de base (donc échantillon) collectées par les enquêteurs sur les plages. Le niveau de connaissance est l'unité d'observation de l'activité (UOA) puisqu'on localise en mer l'activité de chaque sortie. Le jeu de donnée injecté concerne la période janvier à décembre 1995 (Date début = 1^er janvier 95, date fin = 31 décembre 95).

La couverture géographique (champ CSPLIBEL) est le "littoral et zone côtière accessible à la pêche artisanale en Guinée"

Résolution temporelle registre: l'information recensement sur laquelle est basée le plan d'échantillonnage et les paramètres d'extrapolation est mensuelle, donc reso temp. MONTH.

Résolution temporelle licence: les pirogues ont une autorisation implicite (de par le code de la pêche), on considère donc que n'ayant pas à renouveler de licence, la résolution temporelle licence est PERIOD.

Résolution temporelle Armement: idem registre.

Résolution temporelle Excursion: la donnée est collectée par sortie, donc Res. temp = Trip

Résolution temporelle Unité d'Observation de l'Activité: idem excursion, car le site de pêche fréquenté est connu par sortie

Le type d'unité d'exploitation est l'embarcation car la donnée est connu au niveau pirogue (UETYPE = VESSEL).

TRIPTYPE: la sortie (code TRIP)

UOATYPE: la donnée de capture ou d'effort est donnée par site de pêche, objet de type strate, donc UOATYPE = STRATE.

Temps de mer et temps de pêche sont en heures (HOUR)

Les poids sont fournis en kg (KG)

Résolution temporelle: Table RESTEMP, RTUNIT, DATART

La résolution temporelle la plus fine qui pourrait faire l'objet de requête est la quinzaine; on ajoutera aussi le mois, la saison guinéenne et l'année. Il faut donc créer 4 occurrences dans DATART composées du code programme, code jeu de donnée, et de l'un des quatre codes résolution temporelle. Les autres Res Temp non signalées dans DATART ne seront pas utilisables lors des requêtes de création des groupements.

Engin de pêche

Les engins signalés dans les formulaires d'enquête sont les mêmes que ceux du recensement. On duplique donc les 13 occurrences du fichier DTGEAR entrées pour GN_RECENS, en changeant le code programme. Cependant, pour les lignes et palangres, une information sur le type d'hameçon est précisée au niveau sortie enquêtée: il est donc nécessaire d'ajouter dans DTGEAR autant occurrences qu'il y a de sous types, en précisant pour chaque sous-type ses caractéristiques techniques, et eu lui donnant un code explicite.

Niveau registre

Problématique: En début de mois et dans chaque site enquêté, l'enquêteur dans fait un mini-recensement qui ne concerne que les barques actives. Ce recensement enregistre le nom propriétaire et le type d'activité qu'il a (permanent/temporaire), le nom pirogue (ou son numéro), le type de barque, la catégorie d'engin utilisée. Sur les N barques actives recensées, n barques sont tirées au sort pour faire l'objet d'un suivi systématique de leur activité pendant les 10 jours d'enquête. Seules les informations mini-recensement correspondant à ces n barques suivies systématiquement doivent être intégrées dans le jeu de donnée au niveau registre.

Cadre légal: Accord de pêche (table AGREMENT) et licence (table LICENCE): le cadre juridique n'a pas changé par rapport au programme GN_RECENS, donc on duplique les enregistrements de cette table en changeant le nom du programme.

Informations embarcations:

Fichiers PROPERTY, ARME, BOAT, EXPLUNIT, MPBOAT, MPGEAR: pour les n pirogues suivies, on informe les fichiers du niveau registre de la même manière qu'a été décrit ce niveau dans le programme GN_RECENS, avec pour toutes les dates début et fin les dates de début et fin du mois. Sont renseignés les champs:

- Table PROPERTY: nom propriétaire, type de pêche pratiqué par le propriétaire (STATUT = permanent ou temporaire);

- Table BOAT: nom (ou numéro) de la barque;

- EXPLUNIT: type de barque (champ ARCHTYPE), et port de recensement (PORTSENS = code du port où a lieu l'enquête), qui est un champ géographique (les références des objets port sont fournies dans PRGGEO de la même manière que pour GN_RECENS); les champs AGRCODE et LICCODE sont à renseigner avec le code indiqué dans les fichiers AGREMENT et LICENCE (comme pour GN_RECENS);

- catégorie d'engin à stocker dans MPGEAR, avec NomBre = 1; attention, à ce niveau, on ne se réfère pas aux sous-types signalés dans DTGEAR;

- STATUT = actif à stocker dans MPBOAT, avec NomBre = 1.

Les propriétaires et les pirogues n'étant pas suivis individuellement au-delà du mini-recensement, il faut créer un code qui identifie chaque propriétaire et chaque pirogue de manière unique d'un recensement à l'autre, et d'un jeu de données à l'autre. Il est proposé:

Pour le propriétaire: Mois(C2)+Port(C3)+n° séquentiel propriétaire (C3);

Pour l'unité d'exploitation: Mois(C2)+Port(C3)+n° séquentiel pirogue (C3); la table ARME permet de faire le lien entre le propriétaire et la pirogue.

Cas particulier de l'information Moteur et Moyen de conservation: ces renseignements ne sont pas fournis au niveau recensement, mais au niveau suivi de l'activité. Il est probable que sur une durée de 10 jours, il n'y ait pas de changement observé au niveau de la présence (ou absence) à chaque sortie du moteur et/ou glacière. Si tel est le cas (ou vrai à 99%), on peut renseigner les champs POWCLAS (pour moteur = oui ou non) et MODCONS (glacière = oui ou non) dans EXPLUNIT: ceci sous entend que ce sont des moyens de production recensés pour le mois puisqu'une unité d'exploitation a une durée de vie implicite d'un mois. Dans le cas contraire (nombre de changements observés d'une sortie à l'autre dans la période de 10 jours non négligeable), il faut utiliser les champs MODCONS de MPBOAT et PROPEL de MPPROPEL et jouer sur les dates début et fin en ajoutant autant d'occurrences que nécessaire pour prendre en compte les changements observés. Une option doit être choisie pour l'ensemble du jeu de données.

Remarque: si l'on souhaite intégrer dans ce modèle l'ensemble des informations du mini-recensement, il faut intégrer ces informations dans un jeu de données séparé selon les modalités décrites pour le programme GN_RECENS (avec la résolution temporelle mois). On peut aussi choisir une autre option: intégrer dans un même jeu de données l'ensemble des pirogues recensées dans le mini-recensement. On rencontre alors le problème suivant: les pirogues qui ne font pas l'objet d'un suivi de l'activité n'ont au niveau registre aucune information permettant d'alimenter les champs mode de conservation et propulsion. Il est possible de contourner le problème eu renseignant les champs correspondant avec une modalité "inconnu".

Niveau excursion:

L'ensemble des informations relevées par l'enquêteur au retour des pirogues sont compilées dans les tables du niveau excursion et du niveau unité de l'observation de l'activité.

Table TRIP:

Les champs de ce fichier sont renseignés de la manière suivante:

- Date fin excursion: date du retour de la sortie enquêtée

- Date début excursion: demandée lors de l'enquête

- Port de débarquement: lieu de l'enquête, à renseigner avec le code stocké dans la table attributaire du plan cartographique LSITE (ne pas oublier d'ajouter dans PRGGEO une occurrence décrivant où se trouve ce plan cartographique, et quel champ de la table attributaire renseigne sur ce code)

- NomBre sortie = 1 (champ NBTRIP);

- Temps de mer (TSS) calculé à partir de la date/heure début et fin

- Engin de pêche utilisé: à renseigner en utilisant les codes engins stockés dans DTGEAR (type pour les filets, et sous type pour les lignes);

- Engin cible: l'information TARGGEAR (oui/non) doit être cohérente avec l'information TARGSPEC (mentionnant le code espèce cible si oui, laissé à blanc sinon) entrée dans le fichier DTGEAR;

- Nombre de pêcheurs: entrer l'information enquêtée;

- Poids total débarqué: somme des poids spécifiques.

Il n'y a pas d'information relative au qualificatif culturel de l'équipage (par exemple ethnie), ni de données sur la valeur de la production.

Production par espèce: fichier PRODUCT

Pour un débarquement enquêté, chaque occurrence décrit une des espèces ou groupe d'espèce observé avec son poids (champ LW); les codes spécifiques utilisés ici sont décrits soit dans le fichier SPECIE, soit dans le fichier GROUP.

Niveau Unité d'observation de l'activité:

Ce fichier n'informe que sur la localisation en mer de la sortie. Pour chaque sortie enquêtée et correspondant dans le fichier TRIP à une occurrence, ou a aussi une occurrence au niveau UOACT qui reprend la clé du niveau TRIP (cad PRGCODE, DTINDEX, UECODE, DATEFIN), en y ajoutant les éléments clé caractéristiques du fichier UOACT:

- La date (on reprend la date de retour sortie, à moins qu'en cas de sortie de plusieurs jours, on puisse indiquer une date antérieure correspondant à la fréquentation du lieu de pêche)

- L'engin est laissé à blanc: l'information engin est déjà fournie au niveau TRIP. En cas d'utilisation de plusieurs engins pendant la sortie, et à condition d'être capable d'associer l'utilisation de chaque engin à chacun des sites répertoriés pendant la sortie, il serait plus judicieux de renseigner le champ engin du niveau UOA que celui du niveau TRIP.

- Le numéro d'opération par jour (ou de sortie): = 1.

Les autres champs renseignés sont:

- UOAID qui est l'identifiant de l'objet décrivant le lieu, ou la zone de pêche. S'agissant d'un champ géographique, il convient d'utiliser le code lieu de pêche stocké dans le champ FSITE de la table attributaire du plan cartographique FSITE. Les paramètres décrivant cette liaison avec le plan cartographique sont stockés dans PRGGEO.

- Nombre d'opérations = 1 a priori, sauf si l'on peut dénombrer le nombre de coups de filets tournants, par exemple.

- Temps de pêche (champ TSF) est calculé comme le temps de mer moins le temps de route;

- si jugé utile, heure début et fin de fréquentation du site de pêche pourraient être calculés par déduction de l'heure départ, arrivée et temps de route;

Poids total calculé. Nombre d'espèces. Poids total rejeté et profil de capture ne sont pas renseignés puisque déjà au niveau TRIP.

Remarque importante: certaines pirogues réalisent deux sorties par jour. Plusieurs options peuvent être choisies vis à vis de cette information:

1) on considère que l'on peut confondre les deux sorties: on somme alors les paramètres d'effort et de capture du niveau excursion (en particulier, NBTRIP = 2);

2) on juge important de conserver l'information correspondant à chaque sortie. Ceci est possible en décalant toute l'information captures, effort et engins utilisés au niveau UOA: la première sortie correspond à n° d'opération = 1, et la seconde à n° d'opération = 2. On crée pour chaque opération une occurrence dans le fichier CATCH décrivant les captures (les rejets n'existant pas en pêche artisanale, les débarquements peuvent aussi être considérés comme des captures nominales, ce qui rend sans objet la distinction formelle entre PRODUCT et CATCH).

Cas d'étude n° 4: Programme Sénégal/Artisanal/Pechart

Remarque préliminaire: ce cas est exposé de manière différente aux cas précédents. La problématique exposée met l'emphase sur le choix d'un jeu de donnée.

1) choix du jeu de données

L'outil développé doit permettre de faire n'importe quel type de regroupement compte tenu du jeu de données disponible. Cependant, dans le cadre de l'application, il nous parait indispensable de pouvoir localiser d'une manière ou d'une autre l'activité eu mer, que ce soit par le biais de sites de pêche, de strates [bathy] x [secteurs latitude] (informations entrées dès le niveau 1 du modèle), ou par des zones accessibles, d'activité ou d'exploitation (informations entrées au niveau 2). Pour valoriser le modèle dans le cadre de l'application, il faut en choisissant le jeu de données se poser les deux questions: 1) quelles sont mes géoréférences en mer et à quel niveau de regroupement puis-je les lier aux données attributaires ? 2) Parmi ces données géographiques, quelles sont celles qui sont ou seront numérisées à très court terme?

Cas a):

données sur les sorties journalières de pirogues: l'intérêt de travailler à ce niveau est que c'est apparemment le seul qui permette de valoriser la localisation des sites de pêche dans le but d'explorer les zones d'activité et d'exploitation (nb.: s'il n'y a pas de sites de pêche digitalisés, on peut les remplacer par les strates). L'analyse des statistiques d'effort par site peut ainsi permettre de décider qu'un ensemble de sites où l'effort est au-delà d'un seuil donné constitue une zone d'activité et/ou d'exploitation pour un groupement d'exploitation. On génère ensuite cette zone d'activité ou d'exploitation soit en contournant par un polygone l'ensemble des sites sélectionnés, soit en amalgamant cet ensemble de site en leur affectant un identifiant unique (par exemple identifiant du groupement "zone d'activité des ligneurs motorisés basés à Kayar"); ces zones pourront sans doute ensuite être utilisées à des fins d'extrapolation.

Cas b):

données compilées à la quinzaine par port, non extrapolées: il s'agit des données échantillonnées auprès des pirogues, extrapolées à la quinzaine connaissant l'effort journalier par type de pêche. Dans le cadre des programmes de routine développés par le CRODT, l'information site de pêche n'existe plus. Cependant, il est possible de développer un programme prenant en compte d'autres critères que le type de pêche dans l'extrapolation: on pourrait ainsi obtenir des données par quinzaine, par port, par type de pêche, espèce cible, et lieu de pêche. C'est l'option qui offre le meilleur compromis entre volume de données et possibilités d'investigations/calcul d'impacts.

Cas c):

données extrapolées et cumulées par quinzaine: ce niveau ne nous intéresse pas beaucoup dans le cadre présent, car il ne permet pas de géoréférencer en mer.

2) Description des deux jeux de données possibles

Cas a): le jeu de données choisi concerne des données collectées. Pour un tel jeu de donnée, une unité d'exploitation est une pirogue échantillonnée sur la plage, une excursion est une sortie de cette pirogue observée lors de son retour dans un port, et une unité d'observation de l'activité géoréférence en mer cette sortie. Une des caractéristiques de ce jeu de données est que les pirogues ne sont pas nommément identifiées donc chaque nouvelle enquête considère la pirogue échantillonnée comme une nouvelle unité d'exploitation. On décrit ci-dessous les trois niveaux nécessaires à l'organisation de la base de donnée:

au niveau unité d'exploitation:

- la "pirogue échantillonnée" est l'unité d'exploitation, qui doit pouvoir être identifiée par un code unique (on suggère par exemple un code composé de "date+identifiant port+n°pirogue échantillonnée dans date");

- cette unité d'exploitation a une existence reconnue entre la date de début de sortie et la date d'enquête. C'est le fichier MPBOAT qui permet de valider cette existence.

- il n'y a aucune information dans BOAT.dbf: en effet, les attributs de BOAT.dbf concernent essentiellement des caractéristiques propres à un bateau connu nommément.

- les fichiers ARME.dbf et PROPERTY.dbf ne sont pas à renseigner car aucune donnée ne correspond aux attributs de ces fichiers.

- les fichiers AGREMENT.dbf et LICENCE.dbf possèdent chacun une occurrence: AGREMENT permet de préciser le cadre juridique national spécifiant les conditions de l'activité des pirogues, LICENCE permet de créer une licence virtuelle donnant droit d'accès à l'ensemble de la ZEE.

- le fichier AUTHORIZE n'est pas à renseigner car BOAT.dbf n'existe pas. Le cadre juridique et la licence sont en fait directement des attributs de l'unité d'exploitation.

- les fichiers MPFSHMAN.dbf, MPGEAR.dbf et MPPROPEL.dbf ne sont pas à renseigner car aucune donnée ne peut venir les alimenter.

Exemple: voici ci dessous l'exemple concernant la 4^ème pirogue enquêtée au retour de pêche à Kayar le 9 janvier 1994: elle est sortie la veille, le 8 janvier, a pratiqué le type pêche = "glacière ligne".

fichier EXPLUNIT.DBF:

CODID ="0901943104" code composé de date (6 car.), n°port (2 car.), n°pirogue dans port (2 car.)
TYPEXPL = "ART"
ARCHTYPE = "PIROGUE"
TJBCLAS = "GRANDE (pirogue)" ou "PETITE (pirogue)"	(si distinction existe)
POWCLAS = "PAS de MOTEUR", ou ">0 - 5 CVX", ou ">5 - 10cvx", etc...
CONSMODE = "GLA"	(avec glacière)
FLAG_UE = "SN"	(pavillon Sénégalais)
AGRCODE = "NATJUR1"	(cadre national de juridiction)
LICCODE = "PECHE ARTISANALE"

fichier AGREMENT.DBF

PRGCODE = "SN_PECHART"
AGRCODE = "NATJUR1"	(cadre national de juridiction)
AGRNAME = "Cadre national de juridiction de la pêche maritime au Sénégal"
AGRTYPE ="FR_AGR"	(accord cadre)
AGRFLEET = "ALL_PL"
ZEECOD = "SN"
ZINTCOD =
AGRLIBEL = bla-bla-bla
AGRPARTN =
DATEDEB = 18/08/87	(date du décret)
DATEFIN = 31/12/94	(date fin du jeu de données)

fichier LICENCE.DBF

PRGCODE = "SN_PECHART"
AGRCODE = "NATJUR1"
LICCODE = "PART"
RTCODE
RTUNIT
LICNAME = "Pêche artisanale"
ZAUTHNAME = "ZEE Sénégal"
ARCCOV = "SN\JURID\ZAUTH.DBF"
ARCITEM = ZAUTH?
ZAUTCODE = "PART"
LICLIBEL = "licence virtuelle pêche artisanale Sénégal"

pour le fichier MPBOAT.dbf (une occurrence par unité d'exploitation):

CODID = "0901943104"
DATEDEB = "08/01/94"	(date début de sortie)
DATEFIN = "09/01/94"	(date fin de sortie: ici, date d'enquête)
NB = 1	(l'unité d'exploitation représente une pirogue)

Remarque 1: dans le cadre de ce jeu de donnée activité, on n'est pas intéressé par des requêtes sur les moyens de production (Ces requêtes sont à adresser à un jeu de données relatif au recensement). Ici, le niveau registre du modèle ne fait que renseigner sur certaines caractéristiques "registre" liées à l'unité d'exploitation, et sur la connaissance de son existence entre les dates début et fin. L'attribut NB de MPBOAT est égal à 1, mais cela n'a pas de sens d'utiliser cet attribut dans un calcul de moyens de production car le jeu de donnée est relatif à un échantillon. Afin d'interdire à l'utilisateur la possibilité de calculer ce type de statistique par groupement, on choisit de ne pas indiquer dans DTATTRIB.DBF que cet attribut fait partie du jeu de donnée.

Niveau excursion: on a les informations suivantes:

fichier TRIP:

CODID = "0901943104"
DATEFIN = "09/01/94"	(identifiant TRIP, date de l'enquête)
DATEDEB = "08/01/94"	(date début de sortie)
LPLCODE ="31"	("31" = code port de débarquement = "kayar")
LPLTYPE = "PORT"
LNDTYPE = "LANDING"
NBTRIP = 1	(la sortie enquêtée)
TSS = 18	(18 heures de mer)
GEARTRIP = "LIGNE"
TARGGEAR = "N"	(si on n'est pas capable de renseigner le champ espèce cible du fichier DTGEAR)
TOT_LW = 50	(50 kg débarqués au total)
etc ...

... ainsi que les informations sur la capture débarquée dans le fichier PRODUCT.dbf (voir les remarques concernant le cas d'étude de la Guinée pour décider s'il faut renseigner PRODUCT ou CATCH; le problème des doubles sorties journalières ne se pose pas dans les mêmes termes puisqu'on n'est pas capable d'identifier la pirogue d'une sortie à l'autre)

L'attribut nombre d'individus par espèce débarquée est collecté: il s'agit d'un attribut statistique des tables PRODUCT.dbf ou CATCH.dbf, à rajouter au modèle au niveau national. Si cet attribut ne sert qu'à des calculs de poids, ou poids moyen, il n'aura qu'un usage d'extrapolation ou interpolation et n'a donc pas à exister au niveau régional. S'il est utilisé au niveau national comme statistique intéressante à calculer par groupement, alors il est facilement possible d'éditer le fichier GPTSTAT.dbf pour permettre ce calcul.

Remarque 2: cas particulier du mode de conservation et du mode de propulsion: dans l'exemple exposé ci-dessus, on choisit d'identifier le mode de conservation au niveau registre, puisque CONSMODE est renseigné dans EXPLUNIT.dbf. Il faut donc limiter la définition des engins (dont les codes sont repris dans le champ GEARTRIP) à celle d'un engin au sens strict, et ne pas intégrer le mode de conservation dans la définition de l'engin: en d'autres termes, éviter de considérer "ligne" et "ligne glacière" comme deux engins différents; il n'y a qu'un engin "ligne" et un mode de conservation "glacière".

Une remarque équivalente pourrait être faite s'agissant de l'intégration du type de propulsion dans la définition de l'engin.

Remarque 3: Si ou n'est pas capable de définir d'espèce cible pour tous les engins du jeu de données, alors le champ TARGGEAR est considéré comme non utilisé par le jeu de données, et n'a donc pas à être renseigné. Au contraire, si au moins un engin peut être considéré comme cible, alors TARGGEAR doit être considéré comme renseigné au niveau jeu de donnée (donc déclaré comme attribut dans le fichier DTATTRIB), avec les valeurs "Y" ou "N" suivant l'engin figurant dans l'attribut GEARTRIP.

au niveau UOA. les informations du fichier UOACT.dbf:

CODID = "0901943104"	(identifiant unité d'exploitation)
DATEFIN = "09/01/94"	(identifiant TRIP, date de l'enquête)
DATE ="09/01/94"	(jour de fréquentation du lieu de pêche)
GEAR UOA = " "	(laissé à blanc, car déjà renseigné au niveau TRIP)
UOA_ID ="3111"	(identifiant du lieu de pêche)
OBJID ="3111"	(identifiant du polygone lieu de pêche)
NBOPER = 1	(ou n si on connaît par exemple le nombre de coups de senne)
TSF = 10	(10 heures de pêche: temps de sortie moins 2*temps de route)
etc...

Conclusion: ce jeu de données peut être complété d'un second jeu de données du programme SN_PECHART: celui relatif au dénombrement de l'effort journalier par type de pêche et par port. L'association de ces deux jeux de données et du jeu de données relatif au programme SN_RECENS permettrait de générer (à condition de développer les procédures correspondantes) le jeu de données décrit ci-dessous.

Cas b): le jeu de données choisi concerne des données extrapolées par quinzaine. Avec un tel jeu de données, l'unité d'exploitation est définie comme étant un ensemble de bateaux dont les caractéristiques relatives aux critères de regroupement sont les mêmes. Une excursion est définie comme l'ensemble des sorties réalisées par l'unité d'exploitation sur une quinzaine. Enfin, l'Unité d'Observation de l'Activité en mer est un des lieux (site ou strate) de pêche fréquenté par l'unité d'exploitation au cours de la quinzaine.

Pour alimenter les fichiers du modèle, il faut avoir au préalable décidé certains regroupements pour réaliser l'extrapolation. Le facteur d'extrapolation utilisé est (l'effort dénombré par jour et type de pêche)/(l'effort échantillonné pour le type de pêche & les autres critères considérés) (les autres critères pouvant être par exemple profil de capture, et site de pêche): un exemple de regroupement généré pour l'extrapolation pourrait être: pirogues à petite motorisation non glacières débarquant à Kayar ciblant les semi-démersaux avec un filet dormant maillant.

Les critères du regroupement cité ci-dessus en exemple sont situés à divers niveaux du modèle: dans cet exemple, '"type 1" regroupe au niveau registre les pirogues à mode de conservation "non glacière" et "petite motorisation", alors que les autres critères: port de débarquement, profil de capture et engin sont renseignés au niveau excursion. Enfin, les différents lieux de pêche fréquentés par ce regroupement sont renseignés au niveau UOA, le nombre d'opérations sur chaque lieu de pêche étant le résultat de l'extrapolation. Ce jeu de donnée sera stocké comme suit:

pour le fichier EXPLUNIT.dbf, on a:

CODID = "TYPE 1"
TYPEXPL = "ART"
ARCHTYPE = "PIROGUE"
POWCLAS = "0 - 5 CVX"	(petite motorisation)
CONSMODE = "NONGLA"
FLAG_UE = "SN"	(pavillon Sénégalais)
AGRCODE = "NATJUR1"	(cadre national de juridiction)
LICCODE = "PECHE ARTISANALE"

pour le fichier MPBOAT.dbf (il faut une occurrence pour chaque type d'unité d'exploitation et pour chaque période début/fin - cf. remarque ci-dessous)

CODID = "TYPE 1"
DATEDEB = "01/01/87"	(début période où on a considéré le type 1)
DATEFIN = "31/12/95"	(fin période où on a considéré le type 1: ici, date fin du jeu de donnée)

Remarque 5: les périodes début/fin correspondent soit aux bornes de la quinzaine, soit aux bornes du recensement, soit aux bornes temporelles limitant l'existence du type 1 en question. Choisir l'une ou l'autre des bornes est égal tant que le champ NB n'est pas renseigné (les deux derniers choix permettent de limiter le volume de la base de donnée). Si l'on choisit de renseigner le champ NB, la seule valeur possible est le nombre de pirogues de type 1 répertoriées. Dans MPBOAT, il faut donc créer pour chaque type une occurrence par recensement, chaque occurrence étant bornée dans le temps par les limites de validité du recensement.

au niveau TRIP, on a les informations:

CODID = "TYPE 1"
DATEFIN = "15/01/94"	(date de fin de quinzaine)
DATEDEB = "01/01/94"	(date début de quinzaine)
LPLCODE ="31"	("31" = code port de débarquement = "kayar")
LPLTYPE = "PORT"
LNDTYPE = "LANDING"
TRIPGEAR = "FMDV"
TARGGEAR = "N"
NBTRIP = 135	(nombre de sorties estimées pendant cette quinzaine après extrapolation tenant compte de l'ensemble des critères, tous lieux de pêche confondus)
etc ...
PRFLPROD = "semi-démersal"	(profil spécifique au débarquement)

au niveau UOA, on a les informations:

fichier UOACT.dbf

CODID = "TYPE 1"
DATEFIN = "15/01/94"	(idem TRIP: date de fin excursion)
DATE ="15/01/94"	(date de fin excursion)
GEAR_UOA = " "	(laissé à blanc, car déjà renseigné au niveau TRIP)
UOA_ID = "3111"	(identifiant du lieu de pêche)
OBJID = "3111"	(identifiant du polygone lieu de pêche)
NBOPER = 24	(nombre extrapolé de sorties ayant fréquenté le site "3111")
TSF = 250 heures	(nombre d'heures total extrapolé sur le lieu de pêche)

fichier CATCH, dbf:

CODID = "TYPE 1"
DATEFIN = "15/01/94"	(idem UOACT.dbf)
DATE = "15/01/94"	(idem UOACT.dbf)
GEAR_UOA = " "	(idem UOACT.dbf)
UOA_ID = "3111"	(idem UOACT.dbf)
SPECGRP = "SPACS01"	(catégorie statistique pageot)
DW = 2567	(capture pageot extrapolée sur le lieu de pêche pendant la quinzaine)

De cette façon, le modèle peut être renseigné au niveau le plus fin de regroupement par rapport à l'information disponible, l'interface se chargeant ensuite de réaliser des groupements d'exploitation plus agrégés (ainsi, l'utilisateur de l'interface pourra réaliser un groupement d'exploitation "FD" en amalgamant les filets maillants, les filets dormant à sole, et les autres filets dormant).

Cas d'étude n° 5: Programme Maroc/Artisanal

Les recensements de la Pêche artisanale au Maroc ne constituent pas un programme homogène. Plusieurs recensements ont eu lieu:

Echelle nationale

- En 1984-85, un programme de technologie des pêches a inventorié les engins par site de débarquement; le nombre de barques répertorié par site est une des données produites par cet inventaire.

- En 1988-89, on a dénombré les barques sur le littoral Méditerranéen et Atlantique de Tanger à Tarfaya. On a distingué deux types de barques (semi-pontées <8m, 10 à 45 cvx, et 5 à 6 m non pontées, 5 à 15 cvx; peut on les dénombrer dans le recensement?).

- De juin 89 à mai 90, 2 recensements pour la période d'été (1^er avril au 30 septembre) et un recensement pour la période d'hiver (1^er octobre au 31 mars) ont permis de dénombrer sans distinction de type les barques sur le littoral Atlantique de Tanger à Dakhla; la donnée est disponible sous forme de tableaux dans un rapport. Par ailleurs, l'activité a fait l'objet d'un suivi régulier: dans un certain nombre de sites d'importance, le nombre de sorties par métier a été estimé sur une base hebdomadaire, puis mensuelle. Des échantillonnages au débarquement faits une fois par semaine sur chaque site sélectionné permettent d'estimer par métier, mois et site des données de capture spécifique.

- Les Directions Régionales des Affaires Maritimes ont sur tout le littoral la responsabilité de l'enregistrement des barques: chaque propriétaire doit venir se faire enregistrer une fois par an et payer une redevance de 50 DH. Cet enregistrement lui donne droit à la vente aux halles et à la subvention de carburant. Il n'y a cependant pas de contrôle sur les plages de l'enregistrement effectif, et ce registre (disponible par quartier maritime) semble inadéquat en regard de la grande mobilité de la pêche artisanale.

Echelle régionale: Sud marocain

- De janvier à septembre 90, une mission ISPM a relevé les informations relatives à la petite pêche aux poulpiers, consignées dans les registres tenus par la Marine Royale sur les sites de Dakhla (et Porto Rico?), pour les mois de janvier, février et septembre: on dispose de l'activité de chacune des barques identifiées nommément: nombre de sorties, temps total de mer, nombre de pêcheurs embarqués, poids total débarqué, valeur totale débarquée, et d'une compilation mensuelle: nombre total de barques, nombre de sorties pour le mois, durée totale de l'ensemble des sorties, poids total débarqué et valeur totale de cette production. En appliquant un nombre de 400 poulpiers par barque, on dispose éventuellement du nombre total de poulpiers.

- En juillet 91, on a dénombré les barques pour les 7 sites existant dans la région, spécifiant leur niveau d'activité (active - non active) et leur métier (poulpe ou poisson). En appliquant le taux 600 poulpiers par barque, on a par règle de 3 le nombre d'engins par site.

- A partir de janvier 93, l'ISPM dispose d'une compilation des relevés journaliers de la Marine Royale sur les sites situés au Sud de Dakhla (Porto Rico, Chica, Cintra et Roc Chico). Cette compilation est basée sur les informations décrites ci-dessus (janvier à septembre 90): la base de donnée est composée d'un fichier par site, où sont stockés les champs "date", "nombre total de barques présentes", "nombre de sorties", "débarquement par espèce" (courbine, poulpe, poisson, calamar, langouste, pied de biche). Il n'y a pas de connaissance des engins utilisés (donc des métiers pratiqués).

- A partir de septembre 94 pour 3 sites au nord de Dakhla (Oued Krâ, Foum Gouira, Ntiref), l'ISPM dispose d'une compilation des relevés journaliers de la Marine Royale limitée à la connaissance des débarquements totaux par espèce et par jour (mêmes catégories que ci-dessus).

- En octobre 94, une enquête ISPM a dénombré les barques par site sur toute la région (10 sites), selon les critères "actif/non actif" et "poulpier-non poulpier". Un échantillon a permis de connaître pour octobre auprès des professionnels le nombre de sorties (/métier?), les rendements/zone/sortie/espèce cible pour la saison de forte activité, le nombre de poulpiers/barque et par site (une moyenne régionale du nb de poulpiers par barque est donnée = 600). Une production annuelle (oct. 93 - sept. 94) par site et catégorie spécifique (poisson, poulpe, langouste, calamar) a été estimée à partir de ces paramètres issus d'enquêtes pour les sites du Nord, et à partir des relevés marine royale pour les sites du Sud.

- En juin 95 (ISPM) et janvier 96(ISPM), des recensements du même type que ceux décrits pour juillet 91 et octobre 94 ont été réalisés par l'ISPM. Le nombre de site répertorié est passé à 13, certains de ces sites étant très saisonniers.

- En mai 96, le MPMMM a recensé sur l'ensemble de la région le nombre d'engins poulpiers, et le nombre de barque (selon les critères actif non actif ????).

Le site de R'Guiba (Dakhla) pose un problème particulier: l'ONP contrôle les ventes à la halle aux poissons, mais seuls les poissons débarqués transitent par cette halle. Le poulpe est vendu directement aux sociétés. Par ailleurs, les relevés de la Marine Royale sur l'activité journalière n'ont pas la crédibilité qu'ils ont sur les plages isolées car R'Guiba est un site aux limites mal définies.

Ou se propose d'organiser ces données selon quatre programmes inventaire:

- recensement niveau national:	MA_RECENS1
- activité niveau national:	MA_PECHART1
- recensement niveau régional (Sud Maroc):	MA_RECENS2
- activité niveau régional (Sud Maroc):	MA_PECHART2

Cas d'étude n° 6: Programme Maroc/Pêche Artisanale/Ma_Recens2

Table PROGRAM:

Le code programme est MA_RECENS2: "Recensement des moyens de production de la pêche artisanale du Sud marocain (province d'Oued Eddahab)". Il s'agit d'un programme de type recensement (donc PRGTYPE = "SENSUS")

Références Objets géogr. programme (Port et pays): table PRGGEO (voir description du remplissage au niveau de EXPLUNIT)

Informations jeu de donnée: Table DATAINFO

La série de recensements réalisés par l'ISPM entre juillet 1991 et mai 1996 (juillet 91, octobre 94, juin 95, janvier 96, mai 1996) semble constituer une série de données assez homogène, qui va donc constituer un jeu de données (index =1).

Les données injectées dans la base de données sont les données de base (donc de type échantillon) collectées par les enquêteurs. Le niveau de connaissance est limité au registre (REG). Les dates début et fin du jeu de donnée encadrent l'ensemble de la période incluant les différents recensements (ici date début = 01/07/91, date fin = 31/05/96), et les limites temporelles de validité des informations collectées pour chaque recensement sont stockées au niveau des entités Moyens de Production du niveau registre.

La couverture géographique (champ CSPLIBEL) est "la province d'Oued Eddahab". La liste des sites répertoriés évolue d'année en aimée du fait du développement de la pêche artisanale, mais c'est bien la province que les différents recensements du jeu de données se proposent de couvrir (les sites manquant à la date t sont des sites où le nombre de barques est nul)

Résolution temporelle registre: du fait d'une très grande mobilité des barques entre sites, la durée de validité allouée à un recensement de ce jeu de donnée est mensuelle, donc résolution temporelle = MONTH.

Résolution temporelle licence: les barques ont une autorisation annuelle de pratiquer la pêche, la résolution temporelle licence est donc YEAR.

Résolution temporelle Armement: champ laissé à blanc, car il n'y a pas d'information propriétaire dans ce jeu de données.

Résolution temporelle Excursion et Unité d'Observation de l'Activité: champs laissés à blanc, car le jeu ne concerne pas les niveaux excursion et UOA.

Le type d'unité d'exploitation est un ensemble de bateaux (UETYPE = VESGRP), car la donnée de base est relative à un dénombrement d'un groupe de bateaux par site.

TRIPTYPE et UOATYPE: champs laissés à blanc car le jeu de données ne concerne ni les niveaux excursion, ni les niveaux UOA.

Résolution temporelle: Table RESTEMP, RTUNIT, DATART

La résolution temporelle la plus fine compatible avec le jeu de donnée est le mois. Outre le mois, les résolutions temporelles qui pourront être utilisées pour ce jeu de données doivent être indiquées au niveau du fichier DATART (l'année, le semestre, une ou plusieurs saisonnalités climatique, ...). Les Résolutions Temporelles non signalées dans DATART ne seront pas utilisables lors des requêtes de création des groupements.

Engin de pêche:Table DTGEAR

- Il y a 3 "mixités d'engins" répertoriés par le jeu de donnée, (codifiés par 7 caractères?): le "poulpier et autres" (qui est en fait une mixité d'engins dont on sait seulement qu'elle inclut le poulpier), "autres - non poulpier" (il s'agit en fait d'une mixité d'engins (courbine, filet maillant, filet à langouste, et turlutte) dont on sait qu'elle n'inclut pas le pot à poulpe), et "inconnu" (il s'agit d'une mixité d'engin non déterminée comprenant un ou plusieurs des engins suivant: poulpier, filet à courbine, filet maillant, filet à langouste, et turlutte). Ces engins mixtes doivent être répertoriés et codifiés dans le fichier DTGEAR afin de pouvoir associer à toute unité d'exploitation un type de pêche.

- Il y a un engin "le poulpier" réellement répertorié: il a une correspondance dans le fichier international de référence: COD_GEAR = "FPO" (nasses casiers). Un code utilisateur doit être placé dans GEARCODE (par ex: "FPO1", ou un code national explicite, comme "POT"), l'espèce cible est le poulpe (donc TARGSPEC ⁼ "SQULO01"), et on peut associer la dimension nombre de pots par filière (DIMTYP1 = "Filiere", DIMVAL1 = 4, DIMTYP2 = "NTRAP", DIMVAL2 = "100"). Lors des derniers recensements, on a constaté que chaque barque emportait eu moyenne 6 filières de 100 pots, on peut donc créer un autre engin FPO2 avec ces nouvelles dimensions, eu vue de calculer un effort standard.

Niveau registre

Accord de pêche (table AGREMENT): le cadre légal au niveau de la pêche artisanale, est le même que celui existant au niveau de la pêche industrielle nationale (il oblige tout propriétaire d'embarcation à s'enregistrer annuellement au niveau du quartier maritime et à payer une redevance), avec cependant certains aspects spécifiques à la PA. Par exemple, au niveau de la province d'Oued Eddahab, ce cadre juridique réglemente l'exploitation dans la Baie de Dakhla depuis janvier 1991: aucune pêche n'est autorisée dans cette Baie, sauf la pêche au poulpier entre le 1^er octobre et le 31 janvier. On crée donc dans la table AGREMENT un code Cadre juridique spécifique à la PA dans le Sud par exemple ARTSUD1, avec un nouveau code (donc une nouvelle occurrence du fichier AGREMENT) pour chaque modification 'de la réglementation affectant un des critères juridiques de la base de données (par exemple, il est nécessaire de définir un nouveau cadre juridique, en stipulant ses dates de début et fin, si les mois d'interdiction de la pêche au poulpier dans la Baie de Dakhla changent).

Licences: Les embarcations concernées par le recensement sont les barques, qui ont accès à l'ensemble de la ZEE, sauf à la Baie de Dakhla. Une distinction est cependant réalisée au niveau de la pratique de pêche, puisque les poulpiers sont autorisés pendant 4 mois de l'année. On peut donc considérer qu'il existe deux licences virtuelles. 1) La licence "tous engins à l'exclusion du poulpier": cette licence autorise la pêche sur toute la ZEE de la province Sud sauf dans la Baie de Dakhla; 2) la licence relative au poulpier, autorisant l'accès à l'ensemble de la ZEE de la province Sud du 1^er octobre au 31 janvier, et limitant cet accès en interdisant la Baie de Dakhla pendant le reste de l'année. Le champ RTCODE informe sur cette saisonnalité, tandis que le champ RTUNIT informe sur la saison de validité de la zone autorisée (par exemple LICCODE = "POULPIE", LICNAME = "pêche artisanale poulpier", RTCODE = "MA_SUD1", RTUNIT - "HIVETE" et "AUTON", et ZAUTNAME = "toute la ZEE sauf baie de Dakhla").

Les bateaux ne faisant pas l'objet d'une identification individuelle, les fichiers BOAT.dbf PROPERTY.dbf, ARME.dbf, et AUTORIZE.dbf ne sont pas informés. Les informations collectées lors des recensements sont stockées dans EXPLUNIT, MPBOAT et MPGEAR, en fonction de leur nature.

L'unité d'exploitation est un ensemble de bateaux répondant à des critères identiques: la pêche artisanale étant composée de bateaux très homogènes dans toute la région, aucun type technique n'est utilisé pour différencier la flottille. Par contre, les critères site de recensement (10 sites), le statut d'activité (2 modalités: actif ou non actif), et le type d'engin répertorié (2 modalités: poulpier ou non poulpier) sont utilisés lors du dénombrement des barques. On peut donc générer autant d'unités d'exploitation qu'il existe de combinaisons site débarquement x statut d'activité par engin répertorié, soit 10 x 2 x 2 = 40.

- Unité d'exploitation (table EXPLUNIT):

On peut donc considérer une unité d'exploitation comme l'ensemble des barques dénombrées sur un site de débarquement, ayant un label d'activité et déclarant utiliser tel type d'engin (selon une classification poulpier/non poulpier). Un code identifiant unique pourrait donc être composé du code port, code statut et code engin répertorié. On peut aussi utiliser un code séquentiel de 1 à 40.

Parmi ces attributs définissant l'unité d'exploitation, seul le site de recensement (champ PORTSENS) est un attribut de EXPLUNIT: il s'agit d'un objet géographique qu'il faut relier avec sa représentation sous ARC INFO: l'information nécessaire pour cela est stockée dans PRGGEO: l'occurrence de PRGGEO indiquera que pour ce jeu de données, le plan cartographique stockant la représentation géographique de l'attribut PORTSENS de la table EXPLUNIT est la couverture ARC INFO "MA\RECENS\LSITE\PAT.DBF", le lieu entre l'attribut et sa représentation se faisant sur la valeur du champ ARCITEM = "PORT".

D'autres attributs du jeu de données doivent être signalés dans le fichier DTATTRIB: certains attributs de EXPLUNIT sont renseignés comme attributs d'information: type d'exploitation (toutes sont ARTisanal), le type de construction (barque non pontée), le matériel de construction qui est systématiquement "bois", mode de conservation = "frais". La nationalité est implicite (code "MA" pour FLAG_UE). Les champs AGRCODE et LICCODE sont à renseigner de manière adéquate avec les codes indiqués dans les fichiers AGREMENT et LICENCE.

Les champs CLAS peuvent aussi éventuellement être renseignés (le champ POWCLAS = 5-15 cvx, et le champ TJBCLAS = "1-2").

Aucune information ne permet de renseigner le champ port d'origine (PORTORIG), ni le champ qualifiant culturellement l'équipage (STAFF_UE).

- existence actualisée de l'unité d'exploitation (Tables MPBOAT): l'existence et l'importance numérique entre les dates t et t+1 d'une unité d'exploitation répertoriée dans le recensement est renseignée dans le fichier MPBOAT: les dates t et t+1 concernent la durée de validité attribuée à chaque recensement (datedeb = date début du mois de recensement, et datefin = date fin du mois de recensement). Le critère de statut est renseigné dans cette table, par la modalité "ACTIV", "INACT" ou "INCONU" Par exemple, l'occurrence correspondant au recensement de juillet 91 précisant le nombre de barques de l'unité d'exploitation "barques poulpier actives de Porto Rico" sera renseignée comme suit:

UECODE = "PRPPACT"	(code caractère composé d'un code - Porto Rico+Poul+Pier+ACTif )
DATEDEB = 01/07/91	(début validité allouée au recensement de juillet 91)
DATEFIN = 31/07/91	(fin validité allouée au recensement de juillet 91)
STATUS = "ACTIV"
NB = 45	(45 barques poulpiers actives recensées à Porto Rico)

- existence actualisée des engins de l'unité d'exploitation (table MPGEAR): le recensement distingue les trois mixités d'engin répertoriées dans DTGEAR, et évalue pour la mixité "poulpier et autres" le nombre de poulpiers. C'est la table "moyen de production engin" qui permet de qualifier chaque unité d'exploitation en fonction des engins qu'elle peut mettre eu oeuvre. Pour l'unité d'exploitation citée en exemple ci-dessus, qui dispose de 4280 poulpiers lors du recensement de juillet 91, on va créer dans MPGEAR les deux occurrences suivantes:

UECODE = "PRPPACT"	(idem ci-dessus)
DATEDEB = 01/07/91	(début validité allouée au recensement de Juillet 91)
DATEFIN =31/07/91	(fin validité allouée au recensement de juillet 91)
GEAR_REG = "MIXPP"	(mixité engin poulpier et autres)
TARGGEAR = "N"	("N", car une mixité ne peut être cible)
NB = -1	(-1 = pas d'évaluation du nombre d'engins)

UECODE = "PRPPACT"	(idem ci-dessus)
DATEDEB = 01/07/91	(début validité allouée au recensement de juillet 91)
DATEFIN = 31/07/91	(fin validité allouée au recensement de juillet 91)
GEAR_REG = "FPO1"	(engin pot à poulpe)
TARGGEAR = "Y"	("Y", c'est un engin cible)
NB = 4280	(nombre de poulpiers évalués sur le site)

Pour l'unité d'exploitation "autres non poulpier", on aura:

UECODE = "PRPSACT"	(code poissonnier)
DATEDEB = 01/07/91	(début validité allouée au recensement de Juillet 91)
DATEFIN = 31/07/91	(fin validité allouée au recensement de juillet 91)
GEAR_REG = "MIXNP"	(mixité d'engin autres non poulpier)
TARGGEAR = "Y"	("N", idem ci-dessus)
NB = -1	(-1 = pas d'évaluation du nombre d'engins)

- existence actualisée des pêcheurs de l'unité d'exploitation (table MPFSHMAN): on estime à 3 le nombre de pêcheurs par barque. Il est ainsi possible de spécifier le nombre total de pêcheurs pour chacune des unités d'exploitation.

Cas d'étude n° 7: Programme Maroc/Pêche Artisanale/Ma_Pechart2

Ce programme correspond aux données issues des registres tenus par la Marine Royale sur les sites de débarquement de la province d'Oued Eddahab. Les informations relatives aux sites du Sud Dakhla et du Nord Dakhla n'étant pas de la même nature, ni disponibles sur la même période, il parait plus adéquat de décrire deux jeux de données.

1 - Jeu de données relatif aux sites du SUD:

Table PROGRAM:

Le code programme est MA_PECHART2: "Suivi de l'activité (statistiques effort-captures) de la pêche artisanale de la province Oued Eddahab". Il s'agit d'un programme de type enquête à terre (donc PRGTYPE = "GRNDSAMP")

Références Objets géogr. programme (Port et pays): table PRGGEO (voir description du remplissage au niveau de EXPLUNIT)

Informations jeu de donnée: Table DATAINFO

Le titre du jeu de données est "Informations journalières Marine Royale dans les sites du SUD de Dakhla". Son index est =1.

Les données sont les données de base regroupées (donc DTTYPE = "SAMPGRP") à partir des registres d'activité individuelle journalière tenus par la Marine Royale sur les plages. Le niveau de connaissance est l'excursion puisqu'on suit l'activité eu mer et les débarquements, sans qu'il y ait géoréférence en mer de cette activité (donc pas de niveau de connaissance UOA). Le jeu de donnée injecté concerne la période janvier 1993 à décembre 1995 (Date début = 1^er janvier 93, date fin = 31 décembre 95).

La couverture géographique (champ CSPLIBEL) est "sites de débarquement de Porto Rico, Chica, Cintra et Roc Chico".

Résolution temporelle registre: l'information recensement liée au jeu de données est journalière, donc reso temp. DAY.

Résolution temporelle licence: YEAR (idem programme MA_RECENS2).

Résolution temporelle Armement: champ laissé à blanc, car pas d'information sur cette entité.

Résolution temporelle Excursion: la donnée est regroupée par jour, donc Res. temp = DAY.

Résolution temporelle Unité d'Observation de l'Activité: champ laissé à blanc.

Le type d'unité d'exploitation est un ensemble de barques puisque la donnée journalière est regroupée. (UETYPE = VESGRP).

TRIPTYPE: un ensemble de sorties (⁼ "EXCGRP")

UOATYPE: champ laissé à blanc
Temps de mer: en heures (HOUR)
Temps de pêche: pas d'unité, puisque pas renseigné
Les poids sont fournis en kg (KG)

Résolution temporelle: Table RESTEMP, RTUNIT, DATART

La résolution temporelle la plus fine qui pourrait faire l'objet de requête est le jour, qui apparaît cependant peu utilisable; on préférera utiliser la semaine ou la quinzaine (pour d'éventuels recoupements avec les données campagnes), le mois, diverses saisons (les saisons d'activité relatives aux différentes espèces cibles) et l'année. Il faut donc créer autant d'occurrences dans DATART qu'il existe finalement de Résolutions temporelles choisies. Pour chaque occurrence, on aura le code programme, code jeu de donnée, et le code résolution temporelle. Les Res Temp non signalées dans DATART ne seront pas utilisables lors des requêtes de création des groupements.

Engin de pêche

Les engins utilisés par la pêche artisanale dans la province d'Oued Eddahab sont décrits dans DTGEAR. Il s'agit du poulpier (déjà décrit dans MA_RECENS2), du filet à courbine, du filet dormant à poissons, et du filet à langouste. Chaque engin fait l'objet d'une occurrence dans le fichier DTGEAR, avec attribution d'un code explicite, d'un nom engin, et de dimensions si une typologie permet de les établir.

Niveau registre

Cadre légal: Accord de pêche (table AGREMENT) et licence (table LICENCE): même cadre juridique que décrit dans le programme MA_RECENS2, donc ou duplique les enregistrements de cette table en changeant le nom du programme.

Informations embarcations:

Les fichiers PROPERTY, ARME, BOAT, et AUTORIZE ne sont pas renseignés, puisque le jeu de données n'est pas relatif à des embarcations considérées individuellement.

Unité d'exploitation: c'est l'ensemble de barques répondant au seul critère d'appartenance à un même site (pas de distinction poulpier/non poulpier, actif/non actif). Il y a 4 sites suivis, donc 4 occurrences dans le fichier EXPLUNIT.dbf, avec un identifiant contenant par exemple le code PORT. Les autres attributs de EXPLUNIT.dbf sont renseignés exactement de la même manière que ceux du programme MA_RECENS2.

Existence actualisée des moyens de production de l'unité d'exploitation:

- table MPBOAT.dbf: la compilation du nombre total de barques présentes sur le site étant disponible sur une base journalière, on aura dans MPBOAT une occurrence par unité d'exploitation et par jour. Ainsi, l'unité d'exploitation "barques de Chica" comprenant un total de 76 barques le 25 janvier 1993 sera renseignée de la manière suivante:

UECODE = "CH"	(code caractère composé par exemple du code Port CHica)
DATEDEB = 25/01/93	(début validité du dénombrement)
DATEFIN = 25/01/93	(fin validité du dénombrement)
STATUS =	(champ non renseigné)
NB = 76	(76 barques dénombrées à Chica le 25/01/93)

- table MPGEAR.dbf: cette table peut être renseignée par une énumération des engins utilisés à la date t par l'unité d'exploitation. Pour chaque unité d'exploitation, et pour chaque jour, il y aura autant occurrences dans MPGEAR qu'il y a d'engins très probablement utilisés. Un engin a été très probablement utilisé lorsque la catégorie spécifique ciblée par cet engin n'est pas nulle un jour donné. Ainsi, si le 25 janvier 93, ou a enregistré à Chica un total débarqué de 1500 kg de poulpe, 450 kg de courbine et 1995 kg de poissons divers, ceci signifie que les engins poulpier, filet à courbine et poissons divers ont été mis eu oeuvre par l'unité d'exploitation "barques basées à Chica". Un poids nul pour la langouste verte signifie que le filet à langouste n'est pas mis en oeuvre ce jour là. Les trois occurrences du fichier MPGEAR seront alors:

1)

UECODE ="CH"	(code unité d'exploitation basée à Chica)
DATEDEB = 23/01/93	(début validité existence engin)
DATEFIN = 23/01/93	(fin validité existence engin)
GEAR_REG = "POT"	(engin poulpier)
TARGGEAR = "Y"	("Y", car le poulpier est un engin cible)
NB =	(champ non renseigné car nombre inconnu)

2)

UECODE = "CH"	(idem ci-dessus)
DATEDEB = 23/01/93	(idem ci-dessus)
DATEFIN = 23/01/93	(idem ci-dessus)
GEAR_REG = "FCOURB"	(engin filet à courbine)
TARGGEAR = "Y"	("Y", car le filet courbine est un engin cible)
NB =	(champ non renseigné car nombre inconnu)

3)

UECODE = "CH"	(idem ci-dessus)
DATEDEB = 23/01/93	(idem ci-dessus)
DATEFIN = 23/01/93	(idem ci-dessus)
GEAR_REG = "FPOISS"	(engin filet dormant à poissons)
TARGGEAR = "N"	("N", car le filet à poissons n'est pas engin cible)
NB =	(champ non renseigné car nombre inconnu)

- table MPFHSMAN: cette table peut être renseignée de la même manière que ci-dessus en appliquant un nombre de 3 pêcheurs présents sur le site par barque (FSHMTYPE = "CREW").

Niveau excursion:

L'excursion est ici relative à l'ensemble des sorties réalisées par l'unité d'exploitation au cours d'une journée. Un exemple d'occurrence des tables TRIP et PRODUCT est donné ci-dessous: cette occurrence correspond aux 56 sorties enregistrées à Chica le 25 janvier 1993, pour une capture totale de 1500 kg de poulpe, 450 kg de courbine, et 1995 kg de poissons divers.

Table TRIP: il faut pour chaque unité d'exploitation (c.a.d. pour chaque site) une occurrence par jour. Les champs de ce fichier sont renseignés de la manière suivante:

- Date fin excursion: 25/01/93	(date du jour pour laquelle la donnée est compilée)
- Date début excursion: 25/01/93	(l'excursion est compilée sur une journée)
- Port de débarquement: Chica	(heu de l'enquête, il s'agit d'un lieu géographique, donc même procédure à suivre que pour PORTSENS)
- NomBre sorties: 56
- Temps de mer (TSS): 305	(temps de mer total pour l'ensemble des 56 sorties)
- Engin de pêche utilisé:	(champ non renseigné, car pas de connaissance de l'engin utilisé par sortie)
- Engin cible:	(idem)
- Nombre de pêcheurs (CREWNB):	168 (56 sorties x 3 pêcheurs par sortie).
- Poids total débarqué: 3945
- Valeur totale débarquée: 40250

Production par catégorie spécifique: fichier PRODUCT.dbf Pour chaque excursion (c.a.d. les sorties d'une journée d'un ensemble de barques basées dans un même port), on a connaissance du poids débarqué par catégorie d'espèce. Pour chaque excursion, on a donc autant d'occurrences dans le fichier PRODUCT.dbf qu'il existe de catégories spécifiques à poids non nul. Pour l'exemple signalé ci-dessus:

1)

UECODE = "CH"
DATEFIN = 25/01/93
SPECGRP = "SQULO01"	code attribué au poulpe, décrit dans le fichier SPECIE.dbf

2)

UECODE = "CH"
DATEFIN = 25/01/93
SPECGRP = "POLPR02"	code attribué à la courbine, décrit dans le fichier SPECIE.dbf

3)

UECODE = "CH"
DATEFIN = 25/01/93
SPECGRP = "POICS01"	code attribué à la catégorie poissons divers, décrit dans les fichiers SPECIE.dbf, GROUP.dbf et dans le fichier GRPDEF.dbf en terme de composition spécifique

II - Jeu de données relatif aux sites du NORD:

Ce jeu de données index 2 est renseigné de la même façon que l'index 1, aux exceptions près suivantes:

Table DATAINFO:

Le titre du jeu de données est "Informations journalières Marine Royale dans les sites du NORD de Dakhla". Son index est = 2.

Le jeu de donnée injecté concerne la période septembre 94 à décembre 1995 (date début = 1^er septembre 94, date fin = 31 décembre 95).

La couverture géographique (champ CSPLIBEL) est "sites de débarquement de Oued Kra, Foum Guier et N'tiref".

Table MPBOAT.dbf: le champ nombre n'est pas renseigné.

Table MPFSHMAN.dbf: table non renseignée, puisqu'on n'a pas le nombre de bateaux par site.

Table TRIP.dbf: champ "temps total de mer" non renseigné.