FICHIER SAISIE RSS

[James]

Ce fil a pour but de discuter sur la saisie des RSS et donc de poursuivre sur le thème lancé sur Cormoclic.

Vous trouverez dans "ressources et documents" un fichier de saisie des RSS par espèce ou par code Euring (à vous de choisir); La carte IGN de la Commune ainsi que le département s'affiche automatiquement lors de la saisie de la commune. Le code GONm s'affiche aussi automatiquement lors de la saisie de l'espèce.
Ce fichier n'est pas une obligation, vous pouvez garder votre ancien, mais attention la codification des espèces a été modifiée, donc c'est ce qui est à prendre. Ce fichier est largement améliorable pour faciliter la saisie.
Ce fil permettra au Conseil Scientifique du GONm de tenir compte de vos doléances afin de faire évoluer la base de données.

James

[James]

Ce fichier de saisie est largement inspiré (et copié) du travail fait par Damien thiebault, Alain Chartier, et Bruno Lang. Je n'ai fait que mettre à jour certaines choses et ajouter quelques petits trucs ici et là.

La base de commune/IGN provient directement de la base du GONm, donc les communes sont celles qui circulent dans la base depuis 1972 et agencée par l'oeil vigilant de Bla.

James

[James]

Des remarques utiles de Damien suite à des question posées sur Cormoclic

comment reconnaît-on une vraie COMMUNE?
1. Pour Christian, savoir sur une carte IGN si c'est bien une commune ou pas n'est pas toujours évident. Je n'en ai pas sous les yeux, mais de mémoire il faut que le nom soit écrit en gras, qu'il y ait un C majuscule dans un carré à côté du nom ("Commune") et le nombre d'habitants à côté. Là tu es sûr d'avoir affaire à une commune. En tout cas, c'est certain, sur le terrain il ne faut jamais se fier aux panneaux indicateurs, c'est souvent faux.

2. En ce qui concerne la liste des communes issue du fichier RSS, il y a quelques erreurs. Je viens de comparer la liste des communes GONm avec le référentiel INSEE de janvier 2006 (le plus récent, référence officielle) et j'ai trouvé des communes qui étaient dans la base GONm et pas dans le référentiel INSEE et réciproquement. Voici la liste :

# 27 communes qui sont dans la base GONm et pas chez l'INSEE :
14 BARNEVILLE
14 BREVILLE
14 CESNY-AUX-VIGNES-OUEZY
14 MONTPINCON
27 HELLENVILLIERS
27 LERY-POSES
27 LES NOYERS
27 ROUGEMONTIER
27 SAINT-SULPICE-DE-GRAIMBOUVILLE
50 BEAUBIGNY
50 BEAUMONT
50 CHAUSEY
50 CHERBOURG
50 COUDEVILLE
50 OCTEVILLE
61 CERISI-BELLE-ETOILE
61 MARNEFER
61 MONCEAUX
61 TESSE-LA-MADELEINE
76 BLOSSEVILLE-SUR-MER
76 BOURG-DUN
76 CALLENGEVILLE-BOSC-GEFFROY
76 CAUVILLE-76
76 FRESQUIENNE
76 VAL-DE-SAANE-ANGLESQUEVILLE-SUR-
76 VATTEVILLE-76
76 VILLY-LE-BAS

# 25 communes qui sont dans la base INSEE et pas dans la base GONm :
14 BARNEVILLE-LA-BERTRAN
14 BREVILLE-LES-MONTS
14 CESNY-AUX-VIGNES
14 OUEZY
14 VIEUX-PONT-EN-AUGE
27 LERY
27 NOYERS
27 POSES
27 ROUGEMONTIERS
27 SAINT-SULPICE-DE-GRIMBOUVILLE
50 BAUBIGNY
50 BEAUMONT-HAGUE
50 CHERBOURG-OCTEVILLE
50 COUDEVILLE-SUR-MER
61 CERISY-BELLE-ETOILE
61 LA MESNIERE
61 MONCEAUX-AU-PERCHE
76 VAL-DE-SAANE
76 BLOSSEVILLE
76 CALLENGEVILLE
76 LE BOURG-DUN
76 CAUVILLE-SUR-MER
76 FRESQUIENNES
76 VATTEVILLE-LA-RUE
76 VILLY-SUR-YERES

En recoupant les deux, on voit qu'il s'agit souvent d'erreurs de syntaxe ou d'orthographe, à vous de jouer!

3. Dans le même esprit, il faut décider quel système de coordonnées on utilise. Actuellement, par défaut, elles sont en grades NTF méridien de paris. Ce n'est pas le plus pratique et le plus utilisé, il faudrait mieux passer en Lambert II carto. Il faut trancher cette question, car si on se retrouve dans le fichier RSS avec des coordonnées issues de différentes projections, ce sera inutilisable, et on ne pourra même pas les modifier/convertir car on ne saura même pas dans quel système l'observateur les a saisies. Pour entériner le choix du Lambert II carto, il faut que ce soit facile à trouver pour les observateurs qui comptent saisir les coordonnées des sites d'observation, en fonction de la "source" qu'ils utilisent : carte papier, géoportail, cartoexploreur, SIG... Et là je ne peux pas répondre. Comme ça, les observateurs pourront saisir dans leurs RSS les coordonnées des sites intéressants (espèces nicheuses rares, colonies...) et ce sera intégré dans la base. Et pour les données non géo-référencées par l'observateur, on pourra leur attribuer par défaut les coordonnées de la commune, quand le fichier sera bon!

Damien

[James]

Damien pose cette question :

Comme déjà dit, les coordonnées des communes issues de mon fichier créé il y a quelques années sont bonnes et correspondent à l'église/centre-ville de la commune. Les coordonnées dans le nouveau fichier de saisie ne correspondent ni à l'église, ni au barycentre et sont parfois en dehors de la commune. D'où ma précédente question : pourquoi, par qui, comment ont-elles été modifiées?? Car si on veut utiliser les coordonnées des communes dans le fichier RSS, il faut au moins qu'elles soient bonnes, et il faut régler ça vite fait bien fait!!

En effet je viens de constater cela, je suis parti de ton fichier initial, et je vois que certaines coordonnées ont été modifiée et donc cela ne correspond plus à rien (sans doute un tri malheureux, ou une formule à la con). Dans l'immédiat ce n'est pas grave puisque ces coordonnées ne sont pas liées au fichier, ni intégrées dans la base. Elles sont juste pour le moment inutiles (et inutilisables) comme dans ta version de saisie RSS (sauf que toi tu n'avais pas fait d'erreur).

Il faut donc que le Conseil Scientifique dise sur quel systéme géo on se cale (Lambert II est le plus utilisé a priori). Donc pour le moment sur ce point c'est au CS de décider, cela ne change en rien la saisie des RSS.

James

[James]

que faire si l'on a qu'une estimation des oiseaux, ou même aucune idée du nombre (migration d'oies de nuit).

Bruno a trancher dans la base : ce qui était noté en : quelques, plusieurs, colonie, cris, nid en construction, derniers, chante, nourrit
c'est effectif 0, reste toujours le commentaire pour dire de quoi il s'agit.
Cependant je pense qu'il faut mettre 1 (puisque il y en a au moins 1...)

Sachez que dans la base BSS, il existe une colonne "données négatives" que Bruno coche si vous n'avez pas contactez l'oiseau :
Ex : si vous faites de la repasse à la chevêche ou au râle, faites un RSS avec repasse négative, Bruno cochera la case "données négatives" et cette donnée n'est pas perdue.

[bruno.lang]

j'ai en effet laissé 0 qd la donnée était très peu précise et non pas 1 ; voici pourquoi :

si on met 1, il faudra aller voir ds le commentaire pour distinguer un vrai "1" d'une estimation complètement variable.

mais si on met 0, me direz vous, on peut croire qu'il n'y a aucun oiseau... conclusion trop hâtive, petite mouche (référence ciné de quartier) car il y a une rubrique "donnée négative" qui correspond réellement aux données où l'espèce n'a pas été vue. Il est donc simple de dépatouiller les "vraies" données ss oiseaux des données ss effectifs précis.

CQFD

[Christophe Girard]

Je suis en ce moment en train de rédiger le texte huppe pour l'atlas , pour l'estimation de la population je fouine dans les BSS, et il est regretable de constater qu'il y a beaucoup trop de cartes indicées dont je ne retrouve pas la trace dans le fichier. Il y a un minimum de 20 données qui n'apparaisse pas. Par conséquent une fourchette précise pour certaine carte au 1/50000 est impossible.Dommage.
Christophe Girard

[bruno.lang]

C'est en effet LE problème !

L'expérience monte qu'un observateur ne transmet une donnée que sous une seule forme : par exemple les fiches d'une enquête (atlas, tendances, stoc etc.) et alors il estime qu'il a fait son devoir (ce qui est tout à fait vrai).

Il faut donc prendre en compte cette réalité incontournable en amont ou en aval ; je m'explique :

en amont : au moment de la conception de la fiche à remplir pour une enquête, prévoir tous les paramètres qui permettront d'en faire, sans travail supplémentaire pour le compilateur des données de l'enquête, des RSS (en gros nécessité de la date et de la commune).

en aval : le promoteur de l'enquête transcrit les données récoltées ss forme RSS...

je ne vois guère d'autres solutions

[collette]

Juste deux remarques suite au dernier message de Bruno:
- que le responsable d'enquête transmette les données au fichier: oui si l'ordinateur sait le faire (en ayant prévu le coup au moment de la rédaction de la fiche), sinon c'est perdu d'avance: traiter les données dans le but de l'enquête, c'est déjà lourd, on ne peut pas alourdir les projets.
- je viens de traiter les données rouge-gorge du fichier pour mon texte atlas; c'est bien difficile à exploiter et encore, il n'y a que 1920 lignes! Il y a urgence à choisir ce qu'on met ou pas dans ce fichier, et en particulier, je ne suis pas sûr que toutes les données brutes d'enquête aient leur place dans ce fichier. Tel qu'il est , c'est déjà assez encombré comme ça avec des infos à la fois précises mais non connectables à d'autres. Exemple: (je choisis celui là parce qu'en plus le nom de l'auteur n'est pas saisi... Désolé pour celui qui se reconnaitra, ce choix n'a rien de personnel donc); "Q10 AUVILLARS 30/03/03 jardin michou: 1 " Mais il y a aussi beaucoup de données riches d'une information quantitative ou semi quantitative; par exemple 25 données absolues exprimées par rapport à la surface (dont quelques bijoux de l'atlas des villes en attente: si jamais cette synthèse ne sortait pas , au moins quelques chiffres sont disponibles); 102 lignes du fichier (5,3 %) expriment une donnée en fonction de la distance, mais seulement 74 indiquent le milieu, et encore parce que j'ai pris les 31 données d'Alain Barrier qui suit Valognes avec fidélité. 600 lignes (31 %) fournissent des données en fonction du temps, le plus souvent STOC transcrit par Bruno, mais parfois le milieu est ambigu. ou c'est seulement la localité qui est donnée sans le milieu. Et restent les données de Bruno cherchant un système de cotation en fonction du temps passé sur place (1 rouge-gorge chanteur en moins de 30 min au Reculey/14 le19/03/05). Nous en avons discuté, la faille importante est le rôle capital de l'horaire dans ce genre d'information. C'est pourquoi l'enquête Tendance "oblige" l'observateur a coller au plus près à l'horaire et à la date pécédents à chaque passage annuel.
A suivre! tout ça est bien intéressant...
J Co

[bruno.lang]

plutôt d'accord avec la dernière contribution de JCo ;

quelques bémols :

1920 lignes c'est dur à exploiter surtout avec papier et stabilos plutôt qu'avec un fichier électronique.

le truc de l'horaire, je vais essayer de m'y mettre car c'est vrai que ça joue sur chaque donnée (ex de Reculey/14) mais on peut espérer que, sur un grand nombre de données, les horaires s'équilibrent et donc perdent en importance.

je suis de plus en plus convaincu que la restriction ds l'envoi des données est le plus gros biais...