Hola a todos, bueno antes de nada quiero decir que el mapa y el altitudigrama estan echos en un rato y sin control de exclusiones (datos de entrada válidos, dominios de las funciones, etc...) osea que es del todo imperfecto y no es para nada definitivo.
Tambien tengo que decir que tanto los sistemas sexagesimales, decimales, UTM, etc tienen facil solución para representación en el mapa, en principio no sería para nada un problema.
El mapa tiene una resolución respecto a las coordenadas aceptable pero no infalible, siempre exixte un error, pequeño pero error.
Por otro lado el sistema tiene unas ventajas a tener en cuenta,
1º al ser dinamica te olvidas de editar un mapa para las doscientas y pico especies de hormigas de la peninsula. Si el mapa se hace por géneros y el género dispone de muchas muestras y especies, para cada especie se necesita un tipo de simbolo -el mapa parece un colador enrevesado y difil de descifrar-. Con este método creo que se simplifica mucho la información, ya que se lee de una base de datos y se fabrica el mapa cada vez abre la página del explorador.
Respecto a la compatibilidad de mysql con otros sistemas de bases de datos existen drivers ODBC muy competentes que traducen información en ambos sentido, incluso a traves de servidores en Internet remotos a computadoras locales. En este sentido creo que seriamos los primeros en disponer de un sistema de estas características dentro de la cartografía de invertebrados.
Respecto a la veracidad de la información es un tema discutible ya que aparte de el control de excepciones (datos no válidos, por ejemplo) el sistema debería contar con un gestor de usuarios o de investigadores previamente validados, cada nuevo registro debería ser examinado por algun "experto" y dilucidar su veracidad, el foro juega un papel esencial en esta cuestión.
Lo que debemos discuir es si juntos construimos un sistema mayor para gestionar una base de datos de hormigas (reutilizable para otros campos) .
Saludos
Gis...
- XyVy
- Camponotus Velascotus
- Mensajes: 1933
- Registrado: 19 Ene 2003 21:30
- Ubicación: El Palmar - Murcia
Bigman te recuerdo que hay que tener unas cosas en cuenta, si se hace todo por web no hay problema, si se hace también con pequeños programas clientes que se tienen en casa, la comunicación no se puede hacer directamente con el SGBD pues generalmente todos ellos se encuentran detras del servidor web, luego hay que hacer consultas mediante HTTP o de algun otro modo, pero por supuesto hay muchas soluciones.
También te sugiero que si estás interesado en seguir con el tema, sigas posteando estos mensajes en la sección del subforo Actividades, dentro de Proyecto de BD de hormigas.
Así estará la info centralizada en un sitio concreto y con un tema concreto. Me alegro mucho que le des al fuerte al tema, ultimamente tengo el tiempo justo y no puedo dedicar mucho a estos temas, pero creeme que intentaré ayudar en lo que pueda.
Suerte y estoy a la expectativa.
ciao.
También te sugiero que si estás interesado en seguir con el tema, sigas posteando estos mensajes en la sección del subforo Actividades, dentro de Proyecto de BD de hormigas.
Así estará la info centralizada en un sitio concreto y con un tema concreto. Me alegro mucho que le des al fuerte al tema, ultimamente tengo el tiempo justo y no puedo dedicar mucho a estos temas, pero creeme que intentaré ayudar en lo que pueda.
Suerte y estoy a la expectativa.
ciao.
Un aficionado a las hormigas cuasi-retirado, deseando que los peques adopten la afición.
Hola de nuevo
A ver, que no me explico. Mis mapas no son dinamicos sencillamente porque soy demasiado paquete como para conseguir generarlos de forma dinámica. Ojalá supiera!
Creoq eu son dos cosas diferentes. Una es la técnica, y la otra la de contenidos. La técnica creo que en el foro hay gente de sobra para que te pueda echar una mano y tener una solución razonable. Sería precioso.
La chunga es el tema de las identificaciones. Pienso que no todo el mundo debería tener acceso a introducir datos, y quizá sólo una o dos personas deban poder validarlo. Sí que todo el mundo debería tener acceso a los contenidos y listados de citas, etc.
A mí el proyecto me parece apasionante (como que llevo cautro años trabajando en ello!!) y si se consigue una solucion tecnica para poder ofrecerlo en la web, yo estaría dispuesto a participar del proyecto.
K
A ver, que no me explico. Mis mapas no son dinamicos sencillamente porque soy demasiado paquete como para conseguir generarlos de forma dinámica. Ojalá supiera!
Creoq eu son dos cosas diferentes. Una es la técnica, y la otra la de contenidos. La técnica creo que en el foro hay gente de sobra para que te pueda echar una mano y tener una solución razonable. Sería precioso.
La chunga es el tema de las identificaciones. Pienso que no todo el mundo debería tener acceso a introducir datos, y quizá sólo una o dos personas deban poder validarlo. Sí que todo el mundo debería tener acceso a los contenidos y listados de citas, etc.
A mí el proyecto me parece apasionante (como que llevo cautro años trabajando en ello!!) y si se consigue una solucion tecnica para poder ofrecerlo en la web, yo estaría dispuesto a participar del proyecto.
K
No se trata de una marea negra, solo son pequeñas manchas de fuel (Ministro Rajoy)
Como informático a mí me encantaría participar en el proyecto.
Como dice XyVy, ya se intentó algo parecido y hay un tema en Actividades para ello. El problema principal y primero es, como siempre en una informatización, el análisis. Y para analizar algo primero hay que tener ese algo. Me explico, ¿qué es lo que se quiere?, Kiko tiene su idea, en la que está trabajando hace tiempo, tú Bigman, tendrás otra, etc. En fin, que primero y fundamental, es llegar a un acuerdo sobre el objetivo final y todas sus funcionalidades, como estudiosos de las hormigas, sin pensar en el aspecto técnico-informático.
Luego, como informáticos abordaríamos el análisis de ese objetivo y buscaríamos las soluciones técnicas para llevarlo a cabo.
Todo esto, ya que es un proyecto de cierta envergadura, supone un cierto grado de compromiso y una división de roles.
Mi puesto de trabajo se denomina "analista programador", y aunque tengo poca experiencia, la teoría la tengo bastante "chapada". En la jerga de este negocio el "cliente" es el que necesita el programa o solución informática, y (supuestamente) es el que sabe lo que quiere. El analista entonces lo entrevista para, con herramientas propias, ir diseñando la aplicación. Es ideal que los requerimientos de la aplicación no cambien sobre la marcha, es decir, que el cliente no pida nuevas cosas durante el diseño.
Resumiendo, un grupo debe tomar el rol de cliente, y lógicamente deberán ser los que conocen más de cerca la mirmecología como ciencia y saben qué es lo interesante y novedoso de esta idea. Por todo ello es muy importante que primero se pongan de acuerdo en lo que se quiere hacer antes de empezar el diseño informático.
Otros (o alguno de los mismos si saben programación) actuarían como analistas y programadores para hacer el diseño y llevarlo a la realidad siguiendo las especificaciones del cliente.
Y todo el proceso debe hacerse utilizando documentos escritos, de palabra se puede hablar, acordar y planificar mil cosas, pero al final hay que ir poniendo por escrito todo para tener algo sólido.
Bueno, es una propuesta. Y yo, que he visto lo que tiene Kiko, creo que el debe formar parte del grupo que actúe como cliente, ya que lo tiene bastante pensado y está en contacto con mirmecólogos profesionales. Por lo que veo Bigman puede actuar de coordinador general del proyecto y estar en ambos lados, como cliente y como programador.
Como dice XyVy, ya se intentó algo parecido y hay un tema en Actividades para ello. El problema principal y primero es, como siempre en una informatización, el análisis. Y para analizar algo primero hay que tener ese algo. Me explico, ¿qué es lo que se quiere?, Kiko tiene su idea, en la que está trabajando hace tiempo, tú Bigman, tendrás otra, etc. En fin, que primero y fundamental, es llegar a un acuerdo sobre el objetivo final y todas sus funcionalidades, como estudiosos de las hormigas, sin pensar en el aspecto técnico-informático.
Luego, como informáticos abordaríamos el análisis de ese objetivo y buscaríamos las soluciones técnicas para llevarlo a cabo.
Todo esto, ya que es un proyecto de cierta envergadura, supone un cierto grado de compromiso y una división de roles.
Mi puesto de trabajo se denomina "analista programador", y aunque tengo poca experiencia, la teoría la tengo bastante "chapada". En la jerga de este negocio el "cliente" es el que necesita el programa o solución informática, y (supuestamente) es el que sabe lo que quiere. El analista entonces lo entrevista para, con herramientas propias, ir diseñando la aplicación. Es ideal que los requerimientos de la aplicación no cambien sobre la marcha, es decir, que el cliente no pida nuevas cosas durante el diseño.
Resumiendo, un grupo debe tomar el rol de cliente, y lógicamente deberán ser los que conocen más de cerca la mirmecología como ciencia y saben qué es lo interesante y novedoso de esta idea. Por todo ello es muy importante que primero se pongan de acuerdo en lo que se quiere hacer antes de empezar el diseño informático.
Otros (o alguno de los mismos si saben programación) actuarían como analistas y programadores para hacer el diseño y llevarlo a la realidad siguiendo las especificaciones del cliente.
Y todo el proceso debe hacerse utilizando documentos escritos, de palabra se puede hablar, acordar y planificar mil cosas, pero al final hay que ir poniendo por escrito todo para tener algo sólido.
Bueno, es una propuesta. Y yo, que he visto lo que tiene Kiko, creo que el debe formar parte del grupo que actúe como cliente, ya que lo tiene bastante pensado y está en contacto con mirmecólogos profesionales. Por lo que veo Bigman puede actuar de coordinador general del proyecto y estar en ambos lados, como cliente y como programador.
Ojo por ojo... y el mundo quedará ciego. Mahatma Gandhi
- XyVy
- Camponotus Velascotus
- Mensajes: 1933
- Registrado: 19 Ene 2003 21:30
- Ubicación: El Palmar - Murcia
- Ingeniería del Software. Pressman. 5ª Edición. Lectura obligatoria de cualquier oposición o asignatura de carrera.
Un peazo libro, habla sobre métodos para realizar todo el proceso de desarrollo de un proyecto, allí aparecen las 3 P's. Proceso, Proyecto y Producto. jajajaja.
Ankxo tiene toda la razón, y por supuesto habría que ir recogiendo todo lo que cliente estime necesario, como muchos de nosotros también sabemos informática, debería haber algun cliente que también sea programador pero que dé apuntes de cliente, porque seguro que tiene más idea de cosas que se podrían hacer y se utilizarían como sugerencia desde el lado del cliente.
Yo sugeriría como modelo de trabajo uno basado en prototipos, en el que hay un ciclo constante en el que:
1.- Se escucha al cliente.
2.- Se construye y revisa la maqueta.
3.- El cliente aprueba la maqueta.
Este modelo favorece un diseño rápido, y entran en juego todo momento cliente y analista, ya que juntos se ponen de acuerdo en lo que se debe hacer. Como se puede ver lo que se hace es construir prototipos para entender mejor por un lado lo que el cliente quiere y por otro para ayudarle a saber realmente que quiere, estos prototipos sirven para generar realmente los modulos a diseñar.
La idea del modelo de prototipos es que sirva para definir los requisitos del cliente cuando este está algo desorientado de que es lo que quiere o como lo quiere, generalmente según se recomendaba en el libro, el prototipo va a la basura y lo que se hace es generar uno nuevo basado en la requisitos que el cliente ya ha visto sobre el prototipo.
En fín, un buen tema este, para los Ingenieros de software y me parece que se podría adoptar para el diseño de pantallas y demás una vez que tengamos claro un análisis global del sistema, con que debe hacer, que debe recoger, para quien estará destinado, etc, etc...
Bueno perdonad por el tema, hay gente que les aburre el tema de las métricas...
Ciao.
Un peazo libro, habla sobre métodos para realizar todo el proceso de desarrollo de un proyecto, allí aparecen las 3 P's. Proceso, Proyecto y Producto. jajajaja.
Ankxo tiene toda la razón, y por supuesto habría que ir recogiendo todo lo que cliente estime necesario, como muchos de nosotros también sabemos informática, debería haber algun cliente que también sea programador pero que dé apuntes de cliente, porque seguro que tiene más idea de cosas que se podrían hacer y se utilizarían como sugerencia desde el lado del cliente.
Yo sugeriría como modelo de trabajo uno basado en prototipos, en el que hay un ciclo constante en el que:
1.- Se escucha al cliente.
2.- Se construye y revisa la maqueta.
3.- El cliente aprueba la maqueta.
Este modelo favorece un diseño rápido, y entran en juego todo momento cliente y analista, ya que juntos se ponen de acuerdo en lo que se debe hacer. Como se puede ver lo que se hace es construir prototipos para entender mejor por un lado lo que el cliente quiere y por otro para ayudarle a saber realmente que quiere, estos prototipos sirven para generar realmente los modulos a diseñar.
La idea del modelo de prototipos es que sirva para definir los requisitos del cliente cuando este está algo desorientado de que es lo que quiere o como lo quiere, generalmente según se recomendaba en el libro, el prototipo va a la basura y lo que se hace es generar uno nuevo basado en la requisitos que el cliente ya ha visto sobre el prototipo.
En fín, un buen tema este, para los Ingenieros de software y me parece que se podría adoptar para el diseño de pantallas y demás una vez que tengamos claro un análisis global del sistema, con que debe hacer, que debe recoger, para quien estará destinado, etc, etc...
Bueno perdonad por el tema, hay gente que les aburre el tema de las métricas...
Ciao.
Un aficionado a las hormigas cuasi-retirado, deseando que los peques adopten la afición.