Analyse de la possibilité d'ajouter dans QGIS la capacité d'écrire
directement dans les fichier au format MapInfo TAB

Trois options ont été envisagées pour ajouter la possibilité d'écrire
directement dans les fichiers au format .TAB de MapInfo :

1. ajout de l'édition directement au sein du driver mitab ;
2. passage par une memory layer OGR de façon transparente pour
   l'utilisateur ;
3. passage explicite par un format supportant les modifications.

Ajout de l'édition directement au sein du driver mitab

Cette option nécessite d'implémenter le remplacement d'une feature par
une autre dans les fichiers TAB. Cela peut être implémenté de deux
façons :

1. Implémentation
   de l'écriture en random access dans les fichiers TAB (seul le mode
   "append" est supporté pour le moment) ;
2. Duplicata de la couche en excluant la
   feature concernée par le changement, ajout de cette feature à la fin
   puis écrasement de la couche d'origine par la couche modifiée. Cette
   solution est relativement simple à implémenter mais coûteuse en
   ressources à l'utilisation. Suivant la taille du fichier cela peut
   devenir problématique.

La solution a) implique :

• Retrouver toutes les informations relatives à une feature dans les
  différents fichiers associés au fichier TAB ouvert (2 jours) ;

• Mettre à jour ces informations (4 jours) :

  • Écraser les données existantes si les modifications ne changent pas
    la taille des blocs de données correspondant à la feature;
  • Implémenter un algorithme permettant d'écrire les données modifiées
    (écriture à la fin après déplacement des autres features ou alors
    déplacement des autres features pour faire la place) dans le cas où
    les nouvelles données sont d'une taille différentes (ajout de
    points, d'attributs).

Cette solution contient une certaine incertitude étant donné le
caractère fermé du format binaire .TAB et du fait que les différents
fichiers se référencent entre eux.

La solution b) implique :

• Dupliquer une couche mitab en excluant la feature passée en paramètre
  comme étant modifiée (3 jours) ;
• Ajouter la feature modifiée à la couche dupliquée (0.5 jours) ;
• Écraser la couche existante avec la couche dupliquée (0.5 jours).

Memory layer transparente pour l'utilisateur

Cette option pourrait se réaliser en proposant automatiquement la
conversion d'une couche non-éditable vers une memory layer ou shapefile
lorsque l'utilisateur demande le passage en mode édition. La conversion
inverse se ferait automatiquement au commit des modifications (sortie du
mode édition ou sauvegarde explicite des modifications).

Cette option comprend :

• Création d'un dialogue offrant la possibilité d'exporter la couche
  non-éditable vers un format éditable (0.5 jours) ;
• Exporter la couche vers un format éditable (shapefile ou memory layer)
  sur acceptation du dialogue (2 jours) ;
• Maintenir à jour l'information de correspondance entre la couche
  d'origine et la couche éditable (1 jour) ;
• Re-convertir la couche éditable au format d'origine et écraser la
  couche d'origine avec le résultat de cette conversion lors d'un
  "commit" (sauvegarde explicite des modifications ou sortie du mode
  édition) (1.5 jour) ;
• Nettoyer la couche éditable en sortie du mode édition.

Passage explicite par un format supportant les modifications

Cette option revient à ajouter dans QGIS une fonction de conversion de
couche vers un format supportant les modifications. En ouvrant une
couche au format TAB, en la convertissant en memory layer ou autre
format, en l'éditant puis en la ré-exportant au format d'origine, on
obtient le comportement désiré.

Cela se réaliserait en séquençant l'export puis le chargement de la
couche.

Cette option inclut :sont risqu

• Ajout d'une action de conversion d'un format vers un autre avec les
  mêmes paramètres que la couche d'origine (2.5 jours);
• Ajouter une boite de dialogue similaire à celle de l'export mais
  simplifiée (0.5 jour).