freeNetGIS borrador

Actualización

Casi 1 año después de escribir esto, lo estoy haciendo :P

Hubo algunos cambios locos que después voy a documentar.

¿Que?

Acrónimo de Free Networks Geographical Information System, es (será) un sistema para facilitar la organización y comunicación de los miembros de redes comunitarias en el desarrollo de la red, inspirado en BALLS (Buenos Aires Libre Location System) pero no limitándose a nuestra red. Por ahora es una simple idea loca de ArielCamino quien escribe estas lineas.

¿Por qué?

Si bien está inspirado en BALLS la idea es desde su comienzo hacer una reescritura completa de código, diferenciándose en muchos aspectos que voy a ir ennumerando a continuación a medida que los recuerde:

1. Con respecto a la localización geográfica, la idea es no basarse en límites geográficos determinados, como sucede en BALLS (separado por zonas y partidos), dado que a fines prácticos solo representa una limitación en varios sentidos:

El sistema podría servirle a otras redes comunitarias (como MontevideoLibre o redes del centro del país) si no tuviera límites geográficos determinados, al utilizarlo y ver su potencial estas redes podrían colocarlo en su propio servidor y contribuir al desarrollo.
La coordinación de zonas no debería limitarse tampoco a límites geográficos, por ejemplo no tiene sentido que haya un solo coordinador de zona para todo Almirante Brown que es gigante, en cambio si estaría bueno definir coordinadores de zonas, localizarlos y que luego los usuarios puedan saber que existen coordinadores cerca de sus nodos, los cuales podrían mostrarse en base a la posición geográfica y no a límites geográficos que no nos interesan.
Esto cambiaría radicalmente la postura de estar catalogando nodos y usuarios, todo se basaría simplemente en cálculos de cercanía (distancias entre dos puntos).

2. En cuanto a los nodos y usuarios:

La relación entre un usuario que administra varios nodos (uno a muchos) no siempre se corresponde a la realidad. Hay casos en que los nodos son administrados por varios usuarios (nodos comunitarios). Creo que por regla general un nodo debería tener uno o más administradores, pero al menos uno, caso contrario estaría abandonado y no se sabría su estado.
Los usuarios deberían tener la posibilidad de cargar los equipos que tienen sus nodos y a quién pertenecen, facilitando el préstamo y donación de equipos y su ubicación y utilidad en todo momento, es decir si se están utilizando o están de adorno en algún lugar.
La autenticación de usuarios deberá ser vía LDAP para poder unificar el proceso de login con la galería y el wiki.

3. En cuanto a las conexiones entre nodos

No deberíamos limitarnos a conexiones inalámbricas, estaría bueno poder especificar conexiones UTP (especificando velocidad), inalámbricas (determinando la frecuencia, velocidad, etc), de fibra, etc. Es decir la conexión entre dos puntos no siempre debería significar un enlace inalámbrico. La elección de que tipo de conexión se puede hacer debería ser libre y estar gestionada por el backend de la aplicación.
Que las conexiones entre nodos no sean bidireccionales por defecto, que alguien quiera conectarse con otro no significa que el otro esté de acuerdo o al tanto, estaría bueno poder realizar conexiónes unidireccionales que podrían ser correspondidas o no por los administradores del nodo destino. Incluso a la hora de definir si un enlace es planeado o existe realmente los administradores de ambos nodos deberían estar de acuerdo.
El tipo de nodo (AP - AP Conectado - Nodo) podría ser generado automáticamente en base a las relaciones del mismo (es decir si se encuentra conectado a un nodo o a varios o a ninguno), en vez de ser cargado por el usuario.

4. En cuanto a la visualización del mapa:

Poder elegir entre utilizar la API de Google Maps o de Open Street Maps, para darle apoyo a este último proyecto que le vendría muy bien.
Definir perfiles, por ejemplo (planeado, real, etc) para poder elegir que mostrar y que no en un mapa, tanto en cuanto al estado de los nodos como en cuanto a sus conexiones, para tener una visión más limpia a la hora de planificar. El usuario debería poder elegir su propio perfil de visualización de acuerdo a sus preferencias o elegir uno predeterminado.
Si es factible, se podría armar un sistema para cargar que tipo de antenas tiene el nodo y hacia adonde apuntan, y qué angulo (apertura) tienen, y que se pueda visualizar sobre el mapa.

5. En cuanto a la comunicación entre usuarios:

Definir un sistema tipo QuéSeEstáHaciendo más dinámico, por ejemplo un módulo donde se puedan publicar determinados eventos o acciones localizadas geográficamente y que los demás usuarios del sistema puedan realizar comentarios y estar al tanto de lo que sucede.
Colocar un dashboard como página inicial que anime a los usuarios a estar conectados al sistema para estar al tanto de todo lo que está sucendiendo, haciendo incapié en el punto anterior, y colocando secciones como "últimos nodos agregados", "últimas conexiones confirmadas", etc.
Se podría colocar un chat minimalista que se conecte a #buenosaireslibre utilizando el usuario del sistema en forma automática, y que pueda ser accedido en todo momento sin necesitar estar abriendo otra ventana del navegador.

¿Cómo?

Mi idea es hacer una reescritura completa de código, desarrollando el sistema en PHP utilizando el framework Symfony y el ORM Doctrine, en un desarrollo completamente orientado a objetos. Que toda la vida del sistema desde su comienzo (definiendo casos de uso, modelos de datos, etc) esté documentada. Realizar pruebas unitarias y funcionales para generar código a prueba de errores (TDD). Trabajar con un sistema de control de versiones, mi preferencia es subversion que es lo único que conozco :P

¿Quién?

Se acepta la participación de cualquier persona que quiera hacer algo, en la documentación, en el maquetado (CSS & XHTML), en el desarrollo, en las pruebas, o para hacer cualquier sugerencia, etc.