Talk:Contenido

Disculpe aquel al que esta observación le resulte inoportuna:

Creo que el actual índice deja de lado unas cuantas cuesiones a raiz de la definición primera de sig.

Por el poco conocimiento que tengo en el tema existen dos vertientes:

-La que entiende que cualquier software de manejo de información geográfica es un sig en si mismo.

-La que entiende que un sig es algo mas amplio, del cual el software es un componente pero que consta, además, de recursos humanos, procedimientos de relevamiento, cargado y relevamiento de información, distribución de las tareas, intercambio de ideas entre quienes producen la información y quienes la analizan, filtrado de distintos niveles de abstracción de la información, etc.

Eh ampliado un poco mas la segunda postura porque es la que por lo general se deja de lado a la hora de hablar de sig´s.

En fin, me gustaría saber cual es su opinión al respecto. ¿Creen que sería oportuno ampliar el marco de análisis a todas las formas del sig? o ¿sería más criterioso enfocar un espectro más acotado dejando todo lo demas para otras publicaciones?

--Mario Fèvre 21:16, 15 March 2007 (CET)

Hola Mario,

Yo no estoy muy metido en el desarrollo del libro, pero imagino que no se va a definir los SIG simplemente como un software, sino como un sistema más complejo formado por muchos elementos, de entre los cuáles el software sólo es uno de ellos. Además, si observas la sección que habla de Definición y conceptos básicos, verás que se habla de otras cosas además del software. De esto puede desprenderse, quizá, que el título del capítulo (La herramienta) quizá no sea el más adecuado, puesto que hablando en esos términos generales y según la definición que se da después, un SIG no sólo es la herramienta.

Para continuar con el debate yo tengo algún otro comentario sobre la estructura del libro, en especial sobre el capítulo de datos. La estructura de este capítulo me dejó un poco perdido, ya que hay varias secciones que me pareció presentan un cierto solapamiento conceptual.

Por ejemplo, en Tipos de datos. Modelos de representación espacial ... estamos hablando de los modelos raster y vectorial? si es así, quizá sea un poco confuso hablar de eso, luego pasar a hablar de Bases de datos espaciales y luego pasar otra vez a hablar de los modelos.

¿No sería quizá más comprensible estructurarlo de modo que hablamos primero del modelo conceptual de datos (raster y vector) y luego hablar de cómo esos modelos se implementan físicamente en un ordenador? O incluso ofrecer una visión cronológica de cómo se ha ido realizando la traducción de la realidad en un modelo acotado dentro del ordenador, puesto que en realidad esos modelos raster y vector son más fruto de la necesidad de crear un modelo simplificado de la realidad en un ordenador que no fruto de la necesidad en sí de generar un modelo conceptual de datos.

Algo que yo uso al enseñar el papel de las bases de datos en los SIG es la siguiente estructura (siempre en relación a cómo almacenan éstos los datos, tanto alfanuméricos como geométricos, y por supuesto entorno al papel de las BBDD en los SIG):

A. Software SIG de primera generación (sin SGBDR)

A1. Sin tablas de atributos (léase ráster)

A2. Ficheros planos (léase tipo ArcView 3.2)

B. Software SIG de segunda generación (con SGBDR)

B1. Sistemas duales (sistemas que almacenan geometría por un lado y hacen uso de un SGBDR para los alfanuméricos)

B2. Sistemas integrados (sistemas que hacen uso de un SGBDR para almacenar tanto los alfanuméricos como los geométricos)

C. Software SIG de tercera generación

C1. SGBDR Extendido (sistemas que usan un SGBD relacional-orientado a objetos para almacenar tanto alfanuméricos como geométricos)

C2. Orientado a Objetos (usan una base de datos puramente Orientada a Objetos)

Lógicamente, previo a este tema se debería explicar esa dualidad de los datos espaciales (alfanuméricos+geometría). No sé qué os parece. Quizá no queramos entrar en este detalle.

Saludos,

Marc Compte

Me parece muy interesante tu propuesta, Marc. Buen comentario, sin duda. ¿Por qué no modificas el índice para incorporar esa clasificación de las tres generaciones de sigs? (que a mí me ha parecido muy correcta y clarificadora)

--Volaya 21:23, 16 March 2007 (CET)

The Free GIS Book
El homólogo al proyecto en el mundo anglosajón hereda de un proyecto de EOGEO que está siendo migrado (al parecer) a OSGeo.

De momento parece que el único que está aportando al libro es el representante de Open Jump, conocido como The Sunburned Surveyor (el topógrafo bronceado, en traducción libre :P).

La categoría es Category:Free_GIS_Book y la página principal esta.

¿Es interesante el formato de capítulo que proponen?

¿Es interesante traducir lo que interese y se adapte a nuestro índice?

Sería conveniente al menos ponerse en contacto con las personas que estén al frente del proyecto para que nos cuenten sus planes, problemas y tal vez colaborar de alguna forma con traducciones, etc.

Me parece algo interesante de mirar.

La estructura general del libro en cuestión me parece que aborda la operación de los sig de una forma un tanto violenta. Parece muy orientado a lectores que ya saben que es un sig y demás. Me resulta más interesante una propuesta qu analice el problema desde la base.

El caso presentado parece mas un manual de uso que un texto teórico (no se muy bien lo que estamos tratndo de hacer aqui pero reitero mi preferencia por la actual estructura)

Si me gustó como está armado todo el capítulo de la recoleccion de datos, creo que eso se podría implementar bien en el libro que estamos escribiendo.

Desde el capítulo 8 (libro citado) en adelante puede incluirse en nuestro capítulo sobre "los procedimientos"

--Mario Fèvre 23:29, 22 March 2007 (CET)

Inconsistencia
Esto de la escrtura de libros sin duda no es mi fuerte pero hay algo en la actual estructura del índice que no me convence:

Dentro de "Los Elementos"\"Definicion y conceptos básicos. Componentes" encontramos "Los datos" y "Procedimientos" que son a su vez las atcuales partes II y III. ¿A fin de lograr una estructura mas clara no sería bueno que todos los capitulos se presenten aqui, o que todo lo aqui presentado se desarrolle en forma de "parte"?

No quiero ser insistente (resultar pesado) pero creo que "el factor organizativo" bien se puede desrrollar como "parte". A demás diría que los puntos 5 a 7 de la "PARTE I" bien pueden conformar una parte en si misma llamada "Tecnología"

No me gustaría hacer este cambio sin algo de consenso previo

--Mario Fèvre 23:54, 22 March 2007 (CET)

Nueva estructura
Por mi parte me parece correcta la idea que propone Mario. Los puntos "Tecnología" y "Factor organizativo" pueden tener su parte correspondiente. Yo no lo había puesto así en principio, porque el factor organizativo no estaba incluido, y porque el apartado de tecnología lo incluía en la parte 1, aunque quizás es menos confuso como Mario propone. No te cortes en hacer cambios, tú modifica, que si no gusta siempre hay tiempo de volver atrás o de deshacer tus modificaciones, es lo bueno del wiki. No hace falta que consultes, creo yo, pero si quieres saber mi opinión, estoy totalmente de acuerdo con ese cambio.

Para la parte de "tecnología", yo movería los puntos sobre panorama de las aplicaciones sig, y similares. Para la parte de factor organizativo, si de verdad tiene suficiente entidad el tema como para dedicarle una parte, habrá que añadir a ésta sus correspondientes capítulos. Yo en ese tema reconozco que ando flojo, así que espero que alguien mas adecuado rellene ese vacío.

--Volaya 08:24, 23 March 2007 (CET)

Reestructuración
El apartado "Arquitecturas SIG de almacenamiento de datos" lo he movido como capítulo aparte. Por un lado, no cuadraba con el capítulo "tipos de datos", así que es mas coherente de este modo (las arquitecturas de almacenamiento son para todo tipo de datos espaciales, no uno concreto). Por otro, las subsecciones realmente tenían mucha profundidad en el árbol de contenidos. Marc, el contenido del capítulo es aportación tuya. ¿te parece bien esta modificación?

--Volaya 19:52, 23 March 2007 (CET)

A mi me parece perfecto :) En cuanto a la profundidad de las subsecciones, no sé si es necesario hacerlo explícito en el índice. Yo lo puse, inicialmente, porque pensé que así comunicaba mejor al resto de involucrados qué contenido pensaba que debería ir dentro de esa sección, pero como siempre, cualquier modificación será bienvenida.

--Marc Compte 13:17, 04 April 2007 (CET)