Intro

[Francisco Tirado]

Saludos a Todos,

Primero que todo, quiero dar las gracias a quienes iniciaron este
proyecto; de inmediato entendimos la necesidad y el alcance que puede
tener para aplicaciones y el progreso de Puerto Rico.

No se si ya se han empezado conversaciones para definir la estructura
del databank pero tomando este Google group como espacio de
intercambio de ideas, nos reunimos Giovanni, José, Pablo y yo por
skype hace unos minutos para comenzar a pensar como se adquiriria la
data y que sería la data.

*Fuentes de información

Third Party API (Simple Geo, Oodle, Foursquare)
Acuerdos con third parties (Eyetour, ListMax, Caribbean Cinemas,
Policía de PR, Banco Popular)
Scrapers
Brigadas (Salimos un fin de semana con una meta)
End Users (celulares y browsers)

*Flujo de trabajo

Pablo y yo hemos buscado data para un proyecto que teniamos de WiFi en
el VSJ, en aquel momento lo que nos resultó mas facil fue tomar una
foto y el gps de un local y luego un operador, fuera del 'field',
entraba la información del local.

Giovanni propone que para la primera etapa pongamos en las manos del
operador en el 'field' la responsabilidad de entrar la data correcta
para eliminar pasos que no estamos seguros de primera instancia que
sean necesarios.

*App (Nativa o Web)

Aunque soy fanático de aplicaciones nativas, no sabemos cual es la
herramienta ideal para el 'field' por lo tanto mientras mas beta
testers tengamos en un prototipo, mejores flujos de trabajo podemos
anticipar. De ser nativa contamos con:
Windows Phone (Amarilys Mendez)
José y Giovanni (Nativas iOS)
'nativas' con Titanium para iOS y android (José y yo)

*Estructura de Objeto

Aunque en el momento no nos atrevemos a proponer una estructura,
tomamos en consideración algunas cualidades básicas: Localización
(gps), categoría, timestamp, tiempo de renovación (*), foto, tags.
Entendemos que probablemente deben haber sub-objetos en blobs para
poder entrar cualidades específicas como FB uid o links a otros APIs.

* con esto nos referimos a que una entrada se pone obsoleta en
diferentes tiempos, una playa siempre existe, un gobernador cambio
cada 4 años, un billboard semanal, la gasolina diaria etc.

*Ideas al aire

Escuelas en PR
ATH
Baños Limpios
Crimenes
Servicios Gubernamentales
Paradas y rutas de AMA

[Ricardo Alcocer (Tecnologialibre.com)]

Hola,

Me parece que ese Skype Call fue MUY productivo.  Han podido depurar el concepto muy eficientemente.

Entiendo que se podría empezar con una DB sencilla y un API para hacer "checkin" de lugares.  El usuario que contribuye debrería tener una cuenta para poder contabilizar sus contribuciones, más que todo para hacerlo un poco más "legítimo", mantener métrica, y si fuera posible/necesario, reconocerlos...algo así como lo que hacía Twitter con las personas que contribuyeron con las traducciones.

Quizás una DB básica (nombre del lugar, categoría, lat, lon), y algún mecanismo para agregar meta-data adicional, ya que no todos los lugares requieren el mismo tipo de datos o la misma cantidad.  Para consumir la data debería también existir registro y API KEY para poder monitorear uso, mal uso y sobre uso en el futuro (???).

También sería bueno seleccionar algunas categorías alante y concentrarse en esas, pero igual si alguien decide "taggear" todos los flamboyanes de Puerto Rico, el mismo usuario pueda crear la categoría y manejarla.  Creo que debemos tomar prestado mucho del módelo de Wikipedia.  Yo (Tecnologia Libre) habíamos empezado un proyecto para identificar todos los wifi gratis de Puerto Rico, pero eso fácilmente puede ser una categorías de este proyecto.

Lo importante es arrancar con algo....e intentar separar claramente en el cerebro el objetivo que es poblar data, sin contaminar en pensamiento con lo que será utilizar la data.

Quiero que la gente en Puerto Rico diga que la cantidad y diversidad es tan ridiculamente variada, que hubiese sido imposible hacerlo de manera cerrada.

R

2012/1/17 Francisco Tirado <torl...@gmail.com>

--
Ricardo Alcocer

[Roberto Rosario]

Saludos,

Concurro con la separación de entidades y geo data.  En cuanto al motor de DB les recomiendo usen uno que tenga extensiones GIS, de esta forma pueden hacer queries posicionales en SQL.  Con productos como ArcGIS + Oracle Spacial, se pueden obtener muy buenos resultados con un solo query sin tener que hacer cálculos en programación ni usar stored procedures.  Un ejemplo de un spatial query seria:

SELECT p.pueblo FROM geodata_entidades e, geodata_pueblos p WHERE e.nombre = 'carr 2' AND sdo_within_distance ( p.localizacion, e.geom, 'distance=15 unit=mile') = 'TRUE'; 

Esto me da los pueblos que están a 15 millas o menos de la carr #2 en un solo query.

El otro consejo que les puedo dar es que además de puntos, guarden polígonos en la base de datos.  Para lugares como Plaza la America es mas semanticamente correcto describirlos con un poligono que con un punto, en adicion a que abre la puerta a queries como por ejemplo: "Todo las tiendas de ropa dentro del polígono de Plaza la Americas" en un solo query.  Así es como se hacen las cosas en OGPe (ARPE) y JP, que la data prima no sirve eso es no por problemas técnicos y sino políticos :P

Y por ultimo una pregunta, ¿Bajo que licencia se piensan liberar los diferentes elementos (data, API, backend, frontend, apps)?  Para mi es importante porque así mismo empezaron IMDB y CDDB (http://en.wikipedia.org/wiki/CDDB) y cuando había suficiente data, los proyectos se cerraron, se vendieron y en el caso de CDDB todo termino finalmente incluso en manos de Sony, Inc.

Just my 2 + 1 cents.

[Ricardo Alcocer (Tecnologialibre.com)]

Roberto,

Sabía que traerías mucho valor a la conversación.

Con respecto a la licencia del backend y API, yo diría AGPL.  

Veo el proyecto como 1 sóla fase de sistemas de recopilación de data.  Abro la discusión para saber si habría que establecer una licencia por el consumo de data, en cuyo caso sería un MIT para que se puedan hacer productos propietarios.

Todo software app que consuma la data está "out of scope"....el propósito es crear la base de data necesaria para que developers hagan sus negocios.  

Los Apps (web o móvil) para poblar data deberían ser GPL de modo que si hay cambios en el backend, no dependa del desarrollador original para actualizar el app.

Este proyecto representa algo, a mi entender, nunca antes hecho en PR.  TODOS aprenderemos mucho durante este proceso.

R  

2012/1/17 Roberto Rosario <roberto.rosa...@gmail.com>

--
Ricardo Alcocer

[Roberto Rosario]

Gracias :)

Si, vi que no me supe explicar :) Cuando hable de los apps me refería a los relacionados directamente con el proyecto, los que son de 'data entry'.  También entiendo el proyecto puede/debe tener uno o mas apps comerciales oficiales que sirvan de ejemplo de lo que se puede lograr con la data, mas que proveerían incentivo económico a los envueltos.

En los 1990's Junta de Planificación junto con OGP empezó y trato de hacer algo similar, aun todavía aparecen esporádicamente las capas de parques de bombas, hospitales, escuelas, iglesias, pero eso se hizo en capas, en formatos viejos que ya no se apoyan y no en shape files individuales geocodificados lo cual las hace prácticamente inservibles.

Para discutir la licencia de la data, voy a abrir otro tópico para separar los 'threads' y sean mas fácil de seguir.

[Gabo]

Saludos a todos, no tengo idea como llegue hasta aquí pero creo que puedo aportar, almeno de data entry ;)

Hace un tiempo tenia planeado hacer otro web directory pero los compañeros se quitaron, de todos modos tengo una lista como de 75,000 negocios con direcciones teléfonos etcétera.

Creo que tengo las latitud/longitud de los mismos, tengo que verificar.