

# archeoviz

## bugs 

* bug dans la génération des svg pour les profils (les lignes qui délimitent la figure sont décalées)
* Densité 2D : erreurs occasionnelles lorsqu'impossibilité de générer les courbes de densité
* Cassenade : plot 3D, hull + refits : impossible de bouger la visuation 3D
* run.plots ne fonctionne pas pour maps
* test.do_refits_preprocessing.R  : fail in Github Action Ubunto :https://github.com/sebastien-plutniak/archeoviz/actions/runs/5180918673/jobs/9335737589

## simple enhancements

* bouton Lancer / Rafraîchir
* add test for: reverse.axis.values,  reverse.square.names, do_r_command, .do_square_list
* améliorer les labels pour les adapter lors de la représentation de grandes surfaces

## new features

* rendre possible le rearrangement des labels de carré : square_x, square_x_order, square_y, square_y_order
* permettre de plotter les surfaces (suggestion D Giusti) 
* calculer des surfaces d'interface entre couches
* étendre les paramètres possibles en URL : toute la listes des "params" + les shinyOptions.
  interfaçage / openarcheo ou nakala: faire qu'il soit possible de lancer avec une url une instance archeoviz mettant en evidence un objet.
	(idée : un convertisseur tranforme l'url et ses parametres en commande archeoviz() adaptée avec les paramètres)
  Solution: une grosse fonction qui teste la présence de chaque paramètre dans l'url:
    query <- shiny::parseQueryString(session$clientData$url_search)
    
    param_static <- names(query)[ names(query) %in% c("class_variable", "class_values", "default.group", "location", "planZ", "map.density", "map.refits", "plot3d.ratio", "cxhull", "surface", "plot3d.refits", "sectionXx", "sectionXy", "refits.sectionX", "sectionYx", "sectionYy", "refits.sectionY", "camera.center", "camera.eye") ]
    
    param_dynamic <- names(query)[ names(query) %in% c("objects.df", "refits.df", "timeline.df", "square.size", "reverse.axis.values", "reverse.square.names", "add.x.square.labels", "add.y.square.labels", "title", "home.text", "lang", "set.theme", "run.plots", "html.export") ]
    
  # param_static
    sapply(param_static,  function(param_name) eval(parse( shinyOptions(param_name = query[[param_name]]) )) )
    for(x in 1:length(param_static)){
		param.list[[ names(param_dynamic) == names(param_dynamic[x]) ]] <- param_dynamic[x]
		
		eval(parse( shinyOptions(param_static[x] = query[[ names(param_static[x]) ]]) )) 
	} 
    
  # param_dynamic
	param.list <- getshinyOptions("params")
	for(x in 1:length(param_dynamic)){
		param.list[[ names(param_dynamic) == names(param_dynamic[x]) ]] <- param_dynamic[x]
	} 
	shinyOptions("params" =  param.list)
                 
                 
* integrer 3 types d'enregistrement 
	* par carré, carroyage 
	* coordonnée absolues
	* coordonnées UTM

DONE:
* voir  package explor : pour export des parametres courant d'une appli shiny
*  récupérer l'état des paramètres
		https://stackoverflow.com/questions/32460475/export-all-user-inputs-in-a-shiny-app-to-file-and-load-them-later
	
	
# portal
* revoir la structure de l'arborescence sur le serveur huma-num, en utilisant le parametre path de load_all() pour n'avoir qu'une copie du package
* ajouter une rubrique “variables” (type et description), voir l'exemple de tDAR, récupérant les données dans le tableau metadata.csv
	soit 1 colonne par variable (contenant alors les 3 champs : name, type, description)
	soit 3 colonnes par variable (Column Name,	Data Type, description)
* indexation periodo + geonames pour les communes
* marquer le site sélectionné par une forme différente

* envisager la gestion d'intervalles de dates : 
	jouter une colonne contenant toutes les périodes couvertes et utiliser
	datatable(	options = list( columnDefs = list(list(visible=FALSE, targets=c(4))))  )
	pour masquer cette colonne tout en permettant qu'elle soit filtrable





## Méthode pour remontages

Deux cas de figure sont à distinguer dans les données produites par les archéologues :

1. les remontages physiques sont documentés explicitement (les relations de connexité entre fragments sont documentées par des paires d'identifiants de framents)
2. les remontages sont documentés par ensembles de fragments joins (sans préciser les relations de connexité entre fragments)

Deux variables sont à documenter dans le tableau metadata.csv
* n.refits : nombre de relations de remontage physiques (paires de fragments)
* n.remains.in.refitting.set : nombre de fragments étant inclus dans des ensembles de remontages

Parti pris : les fragments inclus dans des ensembles de remontage ne comprenant que 2 fragments sont considérés comme des "refits" (puisqu'il n'y a pas d'ambiguité à propos de la composition des paires de fragmentes remontables)


