Errores en datos de perfiles

[angelini75]

Hola a todos,

Dado que estoy usando los datos de sisinta he ido encontrando algunos errores de carga que me parece conveniente reportar en issue específico. No se si debería ir al #33 ya que ahí se hace mención a criterios de carga. En este caso se trata de errores de tipeo de perfiles específicos, que para ser solucionados se requiere buscar las fichas originales y corregir los errores. Cuando los errores son evidentes los puedo corregir directamente yo en sisinta, por ejemplo pH=73,2 que debería ser 7,32 u horizontes repetidos.

Va el listado abajo:
http://sisinta.inta.gob.ar/perfiles/485 <- horizonte C140
http://sisinta.inta.gob.ar/perfiles/683/analiticos <- pH en KCl - Horizonte C

[dariorodriguez]

Hola Marcos: recién estoy de vuelta de las vacaciones. El lunes vuelvo a
Inta y reviso eso. Abrazo

2015-02-04 9:35 GMT-03:00 Marcos Angelini notifications@github.com:

Assigned #81 #81 to
@dariorodriguez https://github.com/dariorodriguez.

—
Reply to this email directly or view it on GitHub
#81 (comment).

Darío

[dariorodriguez]

Ya encontré los errores...Beatríz va a rastrear las fichas y lo corregimos. Si encontrás otros avisá.

[midraed]

Urge tener un esquema de validacion post entrada. Digo, hay algunos datos
que son faciles de validar en la entrada : pH 73,5 por ejemplo

2015-02-10 9:45 GMT-03:00 Dario Martin Rodriguez notifications@github.com:

Ya encontré los errores...Beatríz va a rastrear las fichas y lo corregimos

—
Reply to this email directly or view it on GitHub
#81 (comment).

[dariorodriguez]

Si...eso es bueno. Me voy a poner con eso en un "isu" y despues lo vamos
viendo

El 10 de febrero de 2015, 10:38, Guillermo Federico Olmedo <
notifications@github.com> escribió:

Urge tener un esquema de validacion post entrada. Digo, hay algunos datos
que son faciles de validar en la entrada : pH 73,5 por ejemplo

2015-02-10 9:45 GMT-03:00 Dario Martin Rodriguez <notifications@github.com

:

Ya encontré los errores...Beatríz va a rastrear las fichas y lo
corregimos

—
Reply to this email directly or view it on GitHub
<#81 (comment)
.

—
Reply to this email directly or view it on GitHub
#81 (comment).

Darío

[angelini75]

Si queres @dariorodriguez yo te puedo pasar un listado de los valores que aparecen en ciertos campos que deberían ser revisados o estandarizados. Por ejemplo, tipo de horizontes aparecen A, A1, A 1, Ap, AP, A *, A (oAB), etc. Yo hice para mi un script de R para limpiar esas cosas que en parte se podría usar para estandarizar. (fijate linea 40 a 73 https://github.com/angelini75/SEM2DSM/blob/master/calib_data/reshape_data.R)

[dariorodriguez]

Espectacular ! Igualmente yo soy de la idea que los datos hay que
guardarlos tal cual se generaron. Por ejemplo, la nomenclatura de
Horizontes sufrió algunas modificaciones desde que se relevaron los
primeros suelos (el A2 ahora es E, el B3 ahora es BC...etc) Pero aún hoy
existen diferencias de criterio entre nosotros mismos acerca de como
llamamos a los horizontes. Incluso, podría ser que distintas personas del
grupo de trabajo, llamen al mismo horizonte de 2 formas diferentes. Mas
ruido existe aún con los sufijos, y en la medida de que incorporemos a
otras provincias, nos llegarán datos con mas y diferentes criterios...
Por todo esto mi opinión es que el dato quede igual que aparece en la
ficha, independientemente de mas adelante, podamos por ejemplo añadir un
nuevo dato en cada Horizonte que sea "Nueva Nomenclatura de Horizontes"
Que opinan ?

El 10 de febrero de 2015, 12:10, Marcos Angelini notifications@github.com
escribió:

Si queres @dariorodriguez https://github.com/dariorodriguez yo te puedo
pasar un listado de los valores que aparecen en ciertos campos que deberían
ser revisados o estandarizados. Por ejemplo, tipo de horizontes aparecen A,
A1, A 1, Ap, AP, A *, A (oAB), etc. Yo hice para mi un script de R para
limpiar esas cosas que en parte se podría usar para estandarizar. (fijate
linea 40 a 73
https://github.com/angelini75/SEM2DSM/blob/master/calib_data/reshape_data.R
)

—
Reply to this email directly or view it on GitHub
#81 (comment).

Darío

[angelini75]

Coincido con vos @dariorodriguez. Quizás se podría tener una versión original y otra estandarizada de la base de datos. Así, si tenes que trabajar con muchos perfiles (como en mi caso) los datos ya estarían listos para ser analizados. Es posible de hacer eso @midraed ?

[dariorodriguez]

Claro...el sisinta debería tratar de salvar los datos tal cual hayan sido
relevados...incluso eso nos pondría a salvo de "interpretaciones" que se
hayan hecho despues y que muchas veces aparecen publicadas, sin ir mas
lejos en nuestra web. En el futuro, agregar nuevos campos no sería
inconveniente, pero siempre resguardando los datos originales

El 11 de febrero de 2015, 5:00, Marcos Angelini notifications@github.com
escribió:

Coincido con vos @dariorodriguez https://github.com/dariorodriguez.
Quizás se podría tener una versión original y otra estandarizada de la base
de datos. Así, si tenes que trabajar con muchos perfiles (como en mi caso)
los datos ya estarían listos para ser analizados. Es posible de hacer eso
@midraed https://github.com/midraed ?

—
Reply to this email directly or view it on GitHub
#81 (comment).

Darío

[midraed]

@angelini75 Creo que eso se puede hacer. Hay muchas formas de plantearlo. Pero tampoco es tan sencillo. Me parece que sisINTA y como dicen uds, tiene que tener lo datos, como fueron relevados. Y creo que los datos adaptado, o actualizados son subproductos... pero es complicado.. hay que pensarlo mas.

[dariorodriguez]

Lo bueno es que tengamos ese criterio común, que sisinta es como un archivo
histórico primero que nada. Contento por eso, vá

El 11 de febrero de 2015, 9:50, Guillermo Federico Olmedo <
notifications@github.com> escribió:

@angelini75 https://github.com/angelini75 Creo que eso se puede hacer.
Hay muchas formas de plantearlo. Pero tampoco es tan sencillo. Me parece
que sisINTA y como dicen uds, tiene que tener lo datos, como fueron
relevados. Y creo que los datos adaptado, o actualizados son
subproductos... pero es complicado.. hay que pensarlo mas.

—
Reply to this email directly or view it on GitHub
#81 (comment).

Darío

[dariorodriguez]

Volviendo a la consulta original de Marcos, eso ya está revisado y
corregido.

El 4 de febrero de 2015, 9:35, Marcos Angelini notifications@github.com
escribió:

Hola a todos,

Dado que estoy usando los datos de sisinta he ido encontrando algunos
errores de carga que me parece conveniente reportar en issue específico. No
se si debería ir al #33 #33
ya que ahí se hace mención a criterios de carga. En este caso se trata de
errores de tipeo de perfiles específicos, que para ser solucionado
requieren buscar las fichas originales y corregir los errores. Cuando los
errores son evidentes los puedo corregir directamente yo en sisinta, por
ejemplo pH=73,2 que debería ser 7,32 u horizontes repetidos.

Va el listado abajo:
http://sisinta.inta.gob.ar/perfiles/485 <- horizonte C140
http://sisinta.inta.gob.ar/perfiles/683/analiticos <- pH en KCl -
Horizonte C

—
Reply to this email directly or view it on GitHub
#81.

Darío

[midraed]

Entonces esto quedo resuelto.
Si se abren 2 nuevos "isus" (jajaj): el de valores posibles #82 y quedo en discusion sobre generar versiones actualizadas/adaptadas de la base de datos... que lo podemos dejar para mas adelante.