[GeolLLibre] Re: idées en vrac
- From: Pierre Chevalier Géologue <pierrechevaliergeol@xxxxxxx>
- To: geolllibre@xxxxxxxxxx
- Date: Mon, 18 Apr 2016 12:58:43 +0200
Salut,
Le 15/04/2016 10:47, Jean-François Moyen a écrit :
Bonjour à tous,
Suite à une longue discussion à bâtons rompus
Tu veux dire à troncs d'arbres défoncés, plutôt, non?
For the sake of everyone's comprehension in the list, I will reply in
English (French-readable, hopefully). Because we are now aiming towards
something much more global, and English is nowadays more fashionable
than (French or German or Spanish or Russian or ...), worldwide.
Si vous voulez, je pourrai faire en 2 langues, ça ne me dérange guère.
Mon clavier s'usera un peu plus vite, je m'en fiche et lui aussi.
hier avec Pierre, quelques idées à partager sur la liste, un peu
en vrac :
1) pour que geol-libre vive, il faut proposer des outils que les "vrais
gens" (les géologues) vont utiliser et apprécier. Un peu de même façon
que os-geo existe parce qu'ils ont un (plusieurs en fait) outils qui
marchent pour de bon, et qu'on peut utiliser en production.
Yes, I agree. But it is worth noting that these tools, usable by
"normal" people, have had a long way before being usable, especially the
end-user graphical interfaces. A long way means all steps of development.
What I mean is that the work must be done step-by-step: starting by the
GUI is a mistake: first, the idea, then implement the basic data bricks,
start with a small core, ensure that it actually works, and then comes
the interface. After come iterations with more implementations, bug
fixes, add features, GUI improvements, skins, plugins, etc.
Another idea that came to us the day before-before yesterday was that
developing and packaging and distributing a desktop application can be a
hassle, but developing a "web-based" application (which is fashionable,
but that's far to be the point) is much easier, at least in some ways.
It is easier in the sense that I (in the role of the server's
administrator) master absolutely everything: all packages, dependencies,
etc. If I go through, say, CGI scripts to implement an application, it
will never depend on the client (the non-geek geologist) side computer
setup, provided that he uses a reasonably recent web browser. I can use
any combination of language(s), any number of back servers (n-tiers or
not), use any kind of database or nothing at all (all-in-memory, and
keep on buying more RAM): the user will never know/notice.
Yes but... y'all tell me that geologists work in the field, without any
Internet connection very often. I know: this first step (web
application) would be a sort of first draft, a proof of concept to
validate a basic idea, for instance, and to get end users' opinions.
After that, once the concept is validated, a full-blown graphical user
interface can be developed aiming at the desktop (understand: autonomous
application, to be run on your laptop, in the middle of the
jungle/desert/tundra).
2) les "vrais gens", à 90%, ne sont pas des programmateurs ni des
informaticiens. Je veux dire par là que non seulement ils ne sont pas
capables de coder une application ou un plugin, fût-il minuscule, mais
aussi qu'ils n'ont pas la culture de "bidouille". Modifier un fichier de
config est la limite supérieure de ce que la majeure partie des
géologues peut accepter de faire.
It depends on the generation, also: geologists (from the real world,
real users) aged around 60 or 70 who dared to use computers have
intensely used command-line interfaces, and efficiently, in the past, on
a daily basis. And (to the surprise of some younger guys), it did work,
and a whole lot of work was actually done, quickly, automagically, on
extremely limited machines (if we compare them to today's computers).
So these fellows would not be afraid of typing command lines, pipelining
commands, scripting, etc.
We can observe this, not only among the geologists, but in the whole
population, in the Linux User Groups (LUGs): very often, the older
people are the fastest ones to adopt GNU/Linux.
But I agree, we should not aim *only* at old farts (sorry, no offense
intended, as you had guessed;))...
Par conséquent, dire qu'on a "implémenté" un format de BDD géologique
(postgeol, désolé Pierre) parce que les tables et les scripts existent
et que "yaka" les intégrer dans son propre serveur postgres ... ne
marche pas.
Well, yes, but if someone (from this geeky list) just tried once, and
asked a few questions, then we could well have advanced on this matter
(read: wake up guys!). I know, it is a little bit of a hassle, but on
the other hand, everything runs just fine on my setup, I have
implemented a couple of servers which ran/run smoothly in the real
world, and I cannot guess what will or will not work on such or such
platform and/or software combination.
I can setup a few VMs or containers to try some combinations, but,
frankly, I have many other things to do.
Another fellow here told me that he partly succeeded at implementing
postgeol (it was bdexplo, at the time) on a Raspberry Pi: the testimony
should be written right here, on this list (and if possible in English
please), so that we can be constructive, as a community.
Il faut offrir une solution qui permette à Mr Tout-le-monde
de déployer sur sa machine en trois clics, et qui donne accès aux
fonctions souhaitées de façon simple (GUI dans l'idéal, mais à la
rigueur c'est pas crucial; en tout cas une solution intégrée et pas un
truc où il faut utiliser un éditeur de texte, un fichier de config,
trois programmes externes et un serveur de BDD pour arriver à faire
quelque chose).
At the very moment, I think that what could be offered is a simple file
with the whole database system as an sqlite. But this will not be a
true postgeol instance, since sqlite does not offer all the features of
PostgreSQL (a bit like comparing a formula 1 with a bicycle: both do the
same job, but in a relatively different manner).
What could also be done would be a docker containing the postgeol, ready
to use, with all necessary dependencies and little tweaks, all bundled
into a single container. I'm not (yet) familiar with docker, so if
someone is able and willing to make such a thing, you're welcome!
Ca ne veut pas dire que ce n'est pas utile ou intéressant, mais c'est ce
qui se passe sous le capot et ce n'est pas ce que les gens veulent voir...
This counts among the reasons why I did this conference in Paris: I'm
opening geolllibre towards computer scientists, DBAs, programmers, etc.
To try to gather some energies and some biodiversity.
En fait c'est un peu le problème général de la communauté libre (*troll
detected*): à part quelques projets "flagship" comme QGis typiquement,
énormément d'outils ne sont pas directement utilisables par quelqu'un
qui n'est pas capable de les programmer (ou de comprendre le
fonctionnement interne pour le moins). Évidemment, le travail gratifiant
c'est de développer les fonctionnalités "core", pas de s'embêter à le
packager dans un installateur qui sera capable de s'adapter à tout les
cas de figure, depuis un macOs ancestral à un windows 7 d'entreprise
avec une politique de droits parano, à une debian huilée comme une
montre suisse...
Yes: non solum the core functionalities are more "noble" to code, as you
say, sed etiam *it can be a pain in the neck to do a graphical user
interface*, and it takes very often *much, much more efforts* than to
code a core function. Plus, it can induce a whole lot more bugs, for a
number of reasons.
[
Concerning this point, Red is offering astonishingly promising stuff. I
still must test that thoroughly, but I can see a bright light not so far
away, which will enlighten GUI development greatly.
(always remember that we are still in the stone age of computing...)
]
mais du point de vue de l'utilisateur naïf c'est la
différence entre un programme qu'on utilise (click, click, ok, accepter,
démarrer le programme, oh ! Ca marche !) et un qui ne fera qu'encombrer
le disque dur ("comment ça il faut aussi que j'installe postGreSQL, et
postGIS, et un outil qui me permette de taper des requêtes, c'est quoi ?
Access ? Ah oui mais il faut que je configure une source de données
machine, keskecé encore que ça ? Oh et puis zut, je retourne chez
Oasis/GoCad/Surfer/ce que vous voudrez....").
Yes, well, it is true in some platforms (big <troll> ahead) but in some
other ones, a simple "apt install package" or "yum install package" will
seamlessy install everything needed, without even clicking and accepting
this or that. Plus, it won't slow your machine down and/or leave some
unused .dlls behind, once you throw the application away.</troll>
Nowadays, I frequent less and less people who are in the windows
ecosystem, so I'm not objective on this matter.
Et à propos, la communauté des "vrais" utilisateurs utilise windows à
80%, mac à 15%, linux à 5% (chiffres (c) estimation au doigt mouillé,
2016).
Thanks for the BIG troll! ;o)
If you allow me, I will rebounce on it... later, trolls have already
been fed enough for today...
3) Vue la pénibilité du travail de diffusion/packaging/etc., le plus
raisonnable semble être de s'appuyer sur des outils qui existent déjà,
et de proposer des extensions. Typiquement des plugins QGIS ou (*gasp*)
des macros excel -- en tout cas des choses basées sur des outils
répandus, connus de tout le monde et suffisament matures pour qu'on
puisse leur faire confiance pour marcher dans (à peu près) toutes les
configurations.
Yes, agreed a thousand times at least (not so much on the maquereau, as
you may have guessed). QGIS plugin seems to be the way to go, in my
humble opinion; to start with, at least. Another thread needs to be
pulled out.
4) Les besoins des gens sont en fait très variables, et je pense que pas
deux personnes n'arriveront à se mettre d'accord sur ce que devrait
contenir un logiciel "pour géologue". Pierre, implicitement et en tant
que "explorateur", pense à des choses basées sur sondages/modélisation
3D/enveloppes minéralisées. Mais un géochimiste, un télédetectionniste,
sans parler des académiques aux centres d'intérêts exotiques, vont sans
doute penser à des outils différents et avoir des besoins différents. Si
je regarde par exemple ce qu'il y a sur ma machine (je suis un peu
éclectique dans mes centres d'intérêts :-) ) je trouve
- Excel (ben oui), postGreSQL, postGIS
- Un certain nombre de feuilles de calcul excel spécialisées (calculs
thermo-barométriques ou formules structurales)
- QGIS
- Un lot d'utilitaires tournant autour du SIG, par exemple pour gérer
les GPS, convertir des geotiffs en format lisible par mon Garmin (G-raster)
- Google Earth, GeoMapApp....
- R/GCDkit
- une série de scripts R maison et mal finis pour faire des krigeage et
des transfo de Fourier
- Deux ou trois trucs de stéréogrammes
- Surfer
- Oasis Montaj (le viewer)
- Un vieux bidule écrit pour des win préhistoriques qui fait des
analyses en transformée de Fourier (parce que je n'ai que le viewer !)
- Plusieurs logiciels de modélisation thermodynamique (thermocalc,
perple_x, theriak-domino) et des programmes associées (pyWerami)
- Des tas de scripts R pour faire des calculs de modèles pétro/géoch
plus ou moins compliqués
- Plusieurs programmes d'analyse numérique de données géochimiques
(C-space)
- Les programmes de Mark Jessel de modélisation gravi ou thermique
... et j'en oublie sûrement ! Plus important, d'autres personnes ont
probablement un mix très différent du mien (par exemple chez moi il n'y
a rien sur des sondages ou de la modélisation 3D).
La conclusion, c'est qu'un outil utile pour certaines personnes sera
totalement inintéressant pour d'autres.
Yes, this is true, but on the other hand, *all* these tools could be:
- rewritten (if they are proprietary softwares) or re-implemented
in a better way (open source, at least, and maybe better),
or
- adapted (if they are open-source softwares),
to match a common denominator, that is, a basic vocabulary that
all applications will share. In other words, a data model.
The target being: get an all-in-one tool, which would fit all geologists
(I'm dreaming big, I know, but I don't think it is that complicated,
indeed; it needs to start from simple, to then implement more
complicated/specialized things, NOT the other way).
4b) Il me semble aussi que vu le nombre d'outils spécialisés, l'effort
principal devrait peut être porter sur les données et leur stockage :
définir des formats communs, utilisables par tout ce beau monde.
Oh yes (big soupir). This was said on this list, a few times.
Dieu merci il y a OGR/GDAL.
Yes, and GeoSciML also exists, thank X.
5) Mais même comme ça, ce qu'on entend par "données" (et donc la façon
dont on va les stocker et les traiter, sans même parler des formats)
dépend énormément selon les gens. Dans la liste ci-dessus, on voit que
j'ai des données :
- spatiales ou spatialisées
-- des rasters/images (scan de carte geol ou topo)
-- des rasters/grilles (MNT, carte gravi, carte géochimique
interpolée [kriegeage ou analogue])
-- des polygons, polylignes (cartes géol) [d'ailleurs le format
pgone + pline n'est pas très approprié, des "coverage" avec frontières +
centroides marchent beaucoup mieux, c'est d'ailleurs le format GRASS :
très accessible depuis QGIS de nos jours mais pas du tout exportable...]
-- des données ponctuelles
- non spatiales, même si elles peuvent être connectées à un point (par
exemple une analyse chimique est connectée à un échantillon):
-- des photos
-- des mesures structurales
-- des analyses roches totales
- ... voire non spatiales, à une échelle encore plus petite : par
exemple si je fais des analyses micro-sonde sur une lame mince, je peux
avoir 200 points sur une lame (et aussi une carte chimique, qui est un
raster), le tout pas directement connecté à des vraies coordonnées
spatiales [au mieux l'échantillon est orienté et je sais à peu près d'où
il vient, à qq mètres ou centimètre près]. Ou pire encore si je broie
une roche pour en extraire et en dater des zircons, j'ai plein de
données qui ont perdu tout cadre spatial.
Well, concerning your last point (crushed sample): yes and no: you can
still bind these data to the place where you took your sample, can't
you? It would certainly be a point (grab/single sample), or a polyline
(channel sample) or a surface (chip sample). But maybe I missed something.
What I retain, after digesting your arguments a bit, is that we may also
have to limit ourselves to a reasonable space dimension. For instance,
in mapping, one meter seems to be reasonable; although the decimeter can
be useful for detailed face mapping. Centimeter is the reasonable best
accuracy needed along drill holes. Going under the millimetre seems to
be beyond all reason, in my humble opinion. Unless someone disagrees?
In the same way of thinking, I think that we should just address simple
use cases, to start with. Later, while things will grow, will come the
time to implement 3D mapping from oriented thin sections, or other
planets' geology. That's beyond the point, for now.
- Déconnectées de la réalité du terrain : un modèle thermo par exemple
va ressortir une grille de propriétés (composition des minéraux) dans
l'espace PT. Ou une donne expérimentale faite sur une roche synthétique.
Well, are synthetic rocks what a geologist deals with??? (dunno, I
never had...)
- Ou un enregistrement dans le temps (signal sismique, monitoring de
glissement, monitoring d'émissions de gaz d'un volcan.... ou encore du
signal mesuré sur un spectro !!).
Bref, c'est quoi une donnée géologique pour vous ?
Big Question!
I will *just begin* to try to answer this question, from a very basic
field geologist's point of view.
To me, a geological data is:
(I'm mapping)
- an observation that I do in the field (a point xyz with attributes),
which can be an outcrop or not;
- a picture (attached or not to an observation);
- a paper map that I scribble and colorize (to be scanned
and georeferenced);
- a contact that I follow in the field, or see in the landscape,
or guess from my nosemeter, or see from air photo interpretation:
this will be a polyline, with attributes like ('followed',
'landscape', 'guessed', 'teledection', etc.);
- an area that I colorize on my map: a polygon, bound by the
contact mentioned above, with a 'label', like in Arc/Info
for instance;
- a structural measurement, attached to an observation point;
- a sample taken from a place, usually an observation point
(can also be brought by a nice neighbor from a distant place)
- an analysis made on that sample (a whole report, a spreadsheet
with data, a set of data (json structure, for instance)
- a cross-section drawn in the field (the best ones!), to
be scanned and georeferenced in 3D;
- the idea of a big fault, or a contact, or... whatever geological
underground feature that I guess from chevrons and/or from many
guesses, that I express by using gestures: this is a 3D surface,
can be implemented as a mesh, or as a surface with control points
(as in the "Éditeur de Coupes", or Geomodeller, I think it is
called now);
(I'm doing some drill holes)
- the machine comes, I not the company's name, the driller's nickname
(they rarely have real names), the machine's characteristics,
- it begins drilling where I told it to do: that was the project
to do the hole. Unfortunately, the peg indicating the hole
location has been wrecked, and the real hole location differs.
All this is a record in a table which will contain all drill holes,
with all data like coordinates, starting time, etc.
I won't enter into any more details, as this would take too much
time
- I collect samples (record in a table)
- I describe cuttings and/or core (record in a table)
- I send samples to a lab, and get results back (geotechnical
data, chemical assays, thin sections, etc.) => cf. above
etc.
(I said that I would *only* start...)
As we also discussed the day before-before yesterday, many of these
questions have been asked, and answered, lately, or decades ago.
GDM had (has?) a quite elegant way to address almost all the issues that
you mentioned, with:
- .b2d files (equivalent of a spreadsheet: two-dimensional file)
=> to represent:
- point data (outcrop, village center), or a correlation
matrix between this and that, or
- ... anything that you
can stuff into a spreadsheet, basically. No formulas,
but you can apply calculations, columnwise.
- .hed .ind .bsd files are merely two .b2d files bound by an index
=> to represent:
- drill holes (.hed contains head (collar) data, .bsd contains
down-hole runs data (whatever: radiometry, imagery, samples,
descriptions...)
- polylines (.hed contains first points of every line, .bsd
contains the trace, with attributes which may vary along the
polyline (very interesting for mapping: this cannot be
addressed by using the standard GIS formats, unless you break
out the geometries into many spaghettis.
- polygons (same as polyline, the endpoint reaches the starting
point)
- .grd files store grid data: a starting point, steps (cell size)
in all desired coordinates (x, y, z), and attributes, where
you can stuff all you want/need.
All these data can be represented in 3D space, using an orthonormal xyz
coordinate system.
This set of basic tools can cover a surprisingly wide range of
geological objects, from hydrogeology to mining through geotechnics,
oil&gas, mapping, geochemistry. In some disciplines, it is much better
suited than others: for instance, in mapping, it has been outpaced by
the development of GIS tools (although some features are really
interesting and are lacking from usual GIS uses).
I think that the only thing which is not covered by the GDM data
filetypes is solids. But I could be wrong.
Sinon, je peux peut être m'arranger pour passer un jour au FOSS4G à
Paris au mois de Mai, pour rencontrer des gens, si il y a des choses qui
bougent ?
Hopefully yes!
À+
Pierre
--
____________________________________________________________________________
Pierre Chevalier
PChGEI: Pierre Chevalier Géologue Et Informaticien
Partenaire DALIBO
Mesté Duran
32100 Condom
Tél+fax : 09 75 27 45 62
06 37 80 33 64
Émail : pierrechevaliergeolCHEZfree.fr
icq# : 10432285
jabber: pierre.chevalier1967@xxxxxxxxx
http://pierremariechevalier.free.fr/pierre_chevalier_geologue
____________________________________________________________________________
Liste de diffusion geolllibre
Pour s'inscrire :
mailto:geolllibre-request@xxxxxxxxxx?subject=subscribe
Pour se desinscrire :
mailto:geolllibre-request@xxxxxxxxxx?subject=unsubscribe
Other related posts:
