Remi Bosc Arethuse Geology claviota:
Dans la table collar ou est ce que tu met a quell systeme geographiquesrid, pour spatial reference identifier, qui se réfère au champ éponyme de la table spatial_ref_sys, qui appartient elle-même à l'extension spatiale postgis.
appaetienne les coordonnees.
Qui plus est certains projets on plusieurs systeme qui se superpose: jusqu a 3Mmoui. Pour ça, je serais plutôt pour faire une table séparée, avec ce genre d'exotiquités. Ce qu'il faut y implémenter, c'est un srid "maison", qui ne soit jamais référencé dans le spatial_ref_sys, et en y définissant les paramètres ad hoc. Réfléchissons. Il faudra, pour les coordonnées grille locale, le point d'origine, défini en vraies coordonnées avec un srid vrai, celui-là, et puis les paramètres habituels, comme on trouve chez GDM, un thêta et un phi, au besoin. Faudra bien se poser la question de la référence du nord: le nord géographique (étoile polaire)? ou le pseudo-nord du système de coordonnées?... Eh oui, le plus souvent, quand on utilise un système de coordonnées projeté (genre l'UTM, au hasard), ce n'est pas le même que le Nord géographique, et il y a des cas où ça a induit de belles bêtises...
ou 4, et en general exotique. et tu as beau faire le menage, tu herite des
situations passees. Il est bon de garder les cordonnees initiales dans lequel
le leve topo a ete fait.
Question table litho, il faut un syteme plus souple. Je ne code jamais les venues d'eau je les mets dans les commentaires de tete de sondages.Ah, là, pas d'accord: mettre ça sur un log ou une coupe, pour le coup, c'est archtement important. Quand tu vois tes teneurs qui grimpent à côté d'une venue d'eau, tu te poses des questions qui peuvent être utiles, pour considérer plus bas dans le sondage, en comparant avec l'humidité des échantillons... Un gros piègeàc qui se décèle ainsi. Et on parle pas des sondages pour des aménagements, ou c'est super-important. Et en hydrogéol... c'est carrément capital. Mais là, faudra creuser un peu plus loin, pour le coup.
En bref tyout le monde a des habitudes un peu differentes pour des bonneesAttention: si on fait dans l'idéal de suite, on va se planter la gueule bien-bien. Faut faire pragmatico-idéal. Un équilibre.
raisons
pour les codes et pour les mesures. Si c'est une base de donnees ideale,
elle doit etre un minimum flexible.Il y aurait une autre solution, qui serait à la fois flexible et pragmatique, est de nommer des champs code1, code2, code3, code4, en laissant l'end-user, au niveau de son schéma externe, s'en servir à sa guise. C'est une solution employée dans des bd canadiennes, entre autres.
Pourquoi pas une table empilee comme dans les analayses?Pour la simple et bonne raison que le modèle EAV (Entité-Attribut-Valeur) qu'on verra dans les analyses se prête bien aux analyses multiélémentaires multilaboratoires vu qu'on n'a jamais les mêmes analyses; ce modèle est très utilisé dans les bd quand on a des choses très hétérogènes. C'est la réponse au problème du tableau à trop de trous partout. Alors qu'en description géol, franchement, on n'est pas du tout dans cette problématique... Et en plus, ce modèle, pour une table de passes, se heurte à un problème de taille: on ne peut plus y vérifier les cohérences de profondeurs. N'oublions pas que côté analyses, on ne le fait pas (mais on anticipe un peu, là) sur les échantillons mais bien seulement sur les résultats analytiques. Et non, on va pas faire une table de descriptions attachée aux passes, non mais quand même, car sinon, on arrive très vite à des choses ingérables.