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 https://github.com/INTA-Suelos/SiSinta/issues/81 to @dariorodriguez https://github.com/dariorodriguez.

— Reply to this email directly or view it on GitHub https://github.com/INTA-Suelos/SiSinta/issues/81#event-229997612.

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 https://github.com/INTA-Suelos/SiSinta/issues/81#issuecomment-73693366.

[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 <https://github.com/INTA-Suelos/SiSinta/issues/81#issuecomment-73693366 .

— Reply to this email directly or view it on GitHub https://github.com/INTA-Suelos/SiSinta/issues/81#issuecomment-73699793.

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 https://github.com/INTA-Suelos/SiSinta/issues/81#issuecomment-73714829.

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 https://github.com/INTA-Suelos/SiSinta/issues/81#issuecomment-73844990.

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 https://github.com/INTA-Suelos/SiSinta/issues/81#issuecomment-73875889.

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 https://github.com/INTA-Suelos/SiSinta/issues/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 https://github.com/INTA-Suelos/SiSinta/issues/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.