Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sanitizar datos existentes #33

Open
mauriciopasquier opened this issue Mar 4, 2014 · 5 comments
Open

Sanitizar datos existentes #33

mauriciopasquier opened this issue Mar 4, 2014 · 5 comments
Labels
Milestone

Comments

@mauriciopasquier
Copy link
Member

Ya que la forma de cargar los datos fue cambiando con el tiempo (las personas que los cargan también?) y hubo/hay confusiones sobre algunos campos, podríamos agregar en este issue todos los items que necesitemos arreglar. Lo planteo como algo que puedo arreglar yo y no los usuarios porque seguro es más simple hacerlo "programáticamente":

  • mosaicos cargados de diferente forma (ver Formato del campo Mosaico #31)
  • la misma serie cargada varias veces (pasó, pero creo que ya está arreglado)
  • series con nombres "raros" (para mí al menos):
    • Perfil 2: Argixerol cálcio - arídico
    • (Sin nombre) (hay perfiles que no tienen nombre, sólo numero de perfil)
    • (Sin nombre) Calicata
    • Serie Alto Verde (el "Serie" estaría de más)

Agreguen otras cosas que vean relacionadas con los datos ya cargados en este issue.

@mauriciopasquier
Copy link
Member Author

PD: no hacía falta que me editaran el post :P

@angelini75
Copy link
Member

Perdón!

@mauriciopasquier
Copy link
Member Author

He estado pensando sobre estos temas de estandarización que vienen surgiendo (#31, #34, #61, #55, #83) y especialmente la discusión sobre datos dudosos de #82. Creo que hay dos conceptos diferentes que ahora están mezclados:

  1. la representación fiel, histórica, a modo de archivo de la ficha
  2. los datos del perfil procesados para ser útiles, corregidos, sanitizados, estandarizados

Y que lo ideal sería separarlos. En algún momento hablamos de que 1 se podía representar con el escaneo, pero eso se sigue demorando y de todas maneras, por su cuenta no sería una representación tan útil (no se podrían hacer búsquedas). 1 y 2 estarían relacionados, de manera que se podría ver el perfil "corregido" de una ficha, y viceversa. Esto permitiría que el nuevo perfil (2) se convierta en o adopte un estándar que ustedes determinen (o que ya exista :P), y podemos garantizar que esos datos se mantengan correctos, ya que la carga manual se realizaría en 1 y permitiría una carga más "libre". Nos hemos topado con el problema de querer validar los datos pero saber que existen fichas en papel que no serían válidas. Podríamos tener un botón (por ejemplo) de "convertir/sanitizar ficha" y que se identifique visualmente qué es lo que está fallando, como en #82

Además, pensando en #80, si agregamos el campo nos desviamos cada vez más de las fichas (cosa que fue pasando de a poco). Pero es un campo usado, asique ¿por qué no dejar que SiSINTA se vaya convirtiendo en la imagen de las prácticas actuales de Suelos, en vez de mantenerlo atado a fichas y prácticas históricas?

¿Qué opinan? Sería una reestructuración grande, pero creo que le daría mucho más potencial al sistema.

@dariorodriguez
Copy link

Lo que dice Mauricio está muy bien. Hay que discutirlo bien.
Por ahora mi opinión es que la ficha preserve los datos cargados por la persona que hizo el pozo, que es lo que nos importa.

Una modificación necesaria sería poder incluir datos a profundidades de 10 m y no de 5 como hasta ahora (aunque no lo crean hay una calicata de Gómez muestreada hasta los 800 cm !!)

@mauriciopasquier
Copy link
Member Author

Una modificación necesaria sería poder incluir datos a profundidades de 10 m y no de 5 como hasta ahora (aunque no lo crean hay una calicata de Gómez muestreada hasta los 800 cm !!)

Resolví eso pero esta discusión está lejos de resolverse :P

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants