momx / momacs Goto Github PK

Users often need to click on two points to define a scale that would be included as a scalar (euclidean distance between the two points) in the yaml

We really need to pass, from R, a list of files to digitize with Momacs.

Something like: list.files("data") %>% acquire() should trigger Momacs digitization on these files and thus bypass Load images / Load folder

This is a dummy example: usually we want some more complex subsets of files adn this would be really helpful in many other contexts.

Often, some information (eg a landmark) is absent (whether the object was broken, or just not here).

So we would need a "missing" button that would add a single missing point (or whatever) as NA in the yaml representation.

Not sure whether we should keep Load images/Load files as it is but I'm sure drag and dropping files would be useful. Apparently it is now natively available:

https://shiny.rstudio.com/gallery/file-upload-widget.html

For the first tests, users repeatedly insist that we need Bezier handles.

I have found this that seem to allow it on a <canvas>:

http://blogs.sitepointstatic.com/examples/tech/canvas-curves/bezier-curve.html

j'ai montré Momacs à une pro de tpsDig de mes collègues (future beta testeuse:o))
elle me dit que:

• tout est trop bien !
• qu'il faudrait prévoir l'affichage des landmarks (points) avec un petit numéro de référence d'ordre (1, 2, etc.)
• visiblement la configurabilité des points et autres en termes de symboles, tailles, couleurs est importante aussi !
• quantité d'autres choses à gérer mais ça sera un onglet supplémentaire pour manipuler les fichiers crées et je m'en chargerai

bientôt le bout du tunnel !

When trying to install from cran on my machine, I get

Warning in install.packages :
  package ‘momacs’ is not available (for R version 4.0.2)

Output of sessionInfo()

R version 4.0.2 (2020-06-22)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS  10.16

Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.0/Resources/lib/libRlapack.dylib

locale:
[1] en_NZ.UTF-8/en_NZ.UTF-8/en_NZ.UTF-8/C/en_NZ.UTF-8/en_NZ.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] compiler_4.0.2 tools_4.0.2    tinytex_0.28   xfun_0.20   

When digitizing it is helpful to have a target template, eg:

points: 12
curves: 2
scale: TRUE

Then when Momacs is loaded, it could look for it, parse it and:

• automatically skip to curves after the 12^th click here
• message if something was forgotten (eg defining scale)

Li'dée serait un formatage yml plus consistant et simple. Je liste plusieurs points pour avoir un fichier plus compact/parcimonieux.

Fondamentalement, toutes les données sont des arrays 2D non? Seul le type (curves2D, points2D, etc.) change la représentation côté Momacs et l'utilisation côté Momocs. En outre, certaines informations ne me semblent nécessaires que côté affichage et pas tellement pour ce qui a été effectivement digitalisé (par exemple les segments dans segments2D. J'imagine qu'avoir un fichier de sortie le plus minimaliste possible (même exemple : des points sans segments) implique de rajouter des couches côté Momacs. On peut toujours raboter ce fichier compact avant d'injecter dans Momocs ou autre mais ça me semble moins propret. Bon, reste le cas batard des curves (avec les ancres et les points samplés, on a besoin des deux je crois) qui fait pencher la balance vers une édition post Momacs/ pro Momocs sauf idée sortie des bois. Je liste plusieurs points sur lesquels je serais plutôt favorable si faisable(s) :

• gérer les partitions

• types actuels compliants avec GeoJson geometries:

  • points2D -> (Multi)Point
  • curves2D (open) -> LineString
  • curves2D (close) -> Polygon
    À part les points qui sont toujours ou presque multiples (et encore j'imagine que MultiPoint gère les Point), les lignes et polygones sont gérés par la table des partitions. A priori on aura ptet pas besoin des Multi* partout, mais je pense qu'il vaut mieux le prévoir (?). Je me demande aussi s'il faut gérer les partitions nichées (type courbes_A: courbe A1, courbe A2; courbes_B: courbe B1, etc.)

• arrays2D partout. Ptet que côté Momacs on a besoin des id, x, y mais côté Momocs déduit le tout (par l'ordre des points pour id, et l'ordre d'arrivée au sein d'un id pour x et y).

• la précision peut être diminuée à disons 3 chiffres sous le pixel par souci de lisibilité/taille de fichier ici aussi.

Les deux points précédents transforment une représentation de points (entres autres arrays) comme ça :

    points: [
      { "id":  21, "x": 75.0236968994141, "y": 166.120025634766},
      ...
      { "id":  33, "x": 64.6323165893555, "y": 36.2277755737305}
    ]

devient:

points: [
      {75.024, 166.120},
      ...
      {64.632, 36.228}
      ]

• côté Momocs (ou autres) on n'a donc pas besoin des choses suivantes :
  • segments dans segments2D
  • type dans curve2D puisque open devient LineString et close devient un Polygon (je sais que tu ne va guère kiffer ce point 😬

Ce qui précède touche à l'état actuel de l'affichage/édition/fichier de sortie mais pour être complet je mentionne deux autres points :

• faudrait prévoir la possibilité de gérer des scalaires (et leurs unités éventuelles) et de les éditer dans Momacs. Le cas le plus courant sera l'échelle mais il y a souvent des données associées, dans les fichiers morphométriques, et non pas seulement dans une table à côté...
• enfin, je crois que je n'en ai pas parlé avant (mea culpa) il y a souvent des données manquantes pour les landmarks notamment, donc faudrait prévoir un ou plusieurs NULL ou équivalent dans l'enchaînement des points cliqués.

la plupart des points me semblent souhaitables, pas obligatoires. On peut en rediscuter mais au moins ils sont là.

Forza ✌️

space is gold here, and we would really need to open Momacs in a full screen browser. Possibly folding whatever we dont need (eg when a template is used)

• Momacs is too confusing with Momocs(2)
• Also would be a wink at tpsDig the popular digitalization software

Inside any other project we have this:

> library(Momacs)
> acquire() # or Momacs::acquire()
 Error in shinyAppDir(x) : 
  No Shiny application exists at the path "inst/momacs_shiny/"