french translaton + some tweaks

content/dev/carto-forms-fr.rst

@@ -0,0 +1,183 @@
+Carto-forms
+###########
+
+:slug: carto-forms
+:date: 30-03-2012
+:author: Alexis Métaireau, Mathieu Leplatre
+:tags: GIS, forms
+:lang: fr
+:status: draft
+
+On a un plan. Un "truc de ouf".
+
+À plusieur reprises, des amis m'ont demandé de leur coder la même chose, à
+quelques details près: une page web avec un formulaire qui permettrait de
+soumettre des informations géographiques, lié à une carte et des manières de
+filtrer l'information.
+
+L'idée fait son bout de chemin, et je commence à penser qu'on peut même avoir
+quelque chose de vraiment flexible et utile. J'ai nommé le projet "carto-forms"
+pour l'instant (mais c'est uniquement un nom de code).
+
+Pour résumer: et si on avait un moyen de construire des formulaires, un peu
+comme google forms, mais avec des informations géographiques en plus?
+
+Si vous ne connaissez pas google forms, il s'agit d'une interface simple
+d'utilisation pour générer des formulaires et récupérer des informations depuis
+ces derniers.
+
+Google forms est un super outil mais à mon avis manque deux choses importantes:
+premièrement, il s'agit d'un outil propriétaire (oui, on peut aussi dire
+privateur) et il n'est donc pas possible de le hacker un peu pour le faire
+devenir ce qu'on souhaite, ni l'installer sur notre propre serveur.
+Deuxièmement, il ne sait pas vraiment fonctionner avec des informations
+géographiques, et il n'y à pas d'autre moyen de filtrer les informations que
+l'utilisation de leur système de feuilles de calcul.
+
+Après avoir réfléchi un petit peu à ça, j'ai contacté `Mathieu`_ et les anciens
+collègues de chez `Makina Corpus`_, puisque les projets libres à base de carto
+sont à même de les intéresser. Et j'ai bien eu raison, j'ai récupéré pas mal de
+feedback, et nous sommes en train, avec Mathieu, de définir plus clairement les
+objectifs et autres détails.
+
+Quelques cas d'utilisation
+==========================
+
+J'arrive à imaginer differents cas d'utilisation pour cet outil. Le premier est
+celui que j'ai approximativement décrit plus haut: la génération de cartes de
+manière collaborative, avec du "facet filtering". Voici un flux d'utilisation:
+
+* Un "administrateur" se rends sur le site web et créé un nouveau formulaire
+  pour l'ensemble des évènements alternatifs. Il crée les champs suivants:
+  
+  * Nom: le champ qui contiens le nom de l'évènement.
+
+  * Categorie: la catégorie de l'évènement (marche, concert, manifestation…).
+    Il peut s'agir d'un champ à multiples occurances.
+
+  * Le lieu de l'évènement. Celui ci peut être donné soit par une adresse soit
+    en selectionnant un point sur une carte.
+
+  * Date: la date de l'évènement (un "date picker" peut permettre cela
+    facilement)
+
+  Chaque champ dans le formulaire à des informations sémentiques associées
+  (oui/non, multiple selection, date, heure, champ géocodé, selection carto,
+  etc.)
+
+* Une fois terminé, le formulaire est généré et une URL permet d'y acceder. 
+  (par exemple http://forms.notmyidea.org/alternatives).
+
+* Une API REST permet d'autres applications d'accéder aux informations et d'en
+  ajouter / modifier de nouvelles.
+
+* Il est maintenant possible de donner l'URL à qui voudra en faire bon usage.
+  Nimporte qui peut ajouter des informations. On peut également imaginer une
+  manière de modérer les modifications si besoin est.
+
+* Bien sur, la dernière phase est la plus interessante: il est possible de
+  filtrer les informations par lieu, catégorie ou date, le tout soit via une
+  API REST, soit via une jolie carte et quelques controles bien placés, dans le
+  navigateur.
+
+Vous avez du remarquer que le processus de création d'un formulaire est
+volontairement très simple. L'idée est que n'importe qui puisse créer des
+cartes facilement, en quelques clics. Si une API bien pensée suit, on peut
+imaginer faire de la validation coté serveur et même faire des applications
+pour téléphone assez simplement.
+
+Pour aller un peu plus loin, si on arrive à penser un format de description
+pour le formulaire, il sera possible de construire les formulaires de manière
+automatisée sur différentes plateformes et également sur des clients
+génériques.
+
+Voici quelques autres exemples d'ou ce projet pourrait être utile:
+
+Designer des formulaires spécialisés pour les applications mobiles OSM
+----------------------------------------------------------------------
+
+1. Dans une "mapping party", on choisit un sujet particulier à cartographier et
+   on design un formulaire (liste des champs (tags) a remplir + description +
+   le type d'information)
+2. Sur place, les utilisateurs remplissent les champs du formulaire avec ce
+   qu'ils voient. Les champs géolocalisé peuvent être remplis automatiquement
+   avec la geolocalisation du téléphone.
+3. À la fin de la journée, il est possible de voir une carte des contributions,
+   avec le formulaire choisi.
+4. Un script peut importer les resultats et les publier vers Open Street Map.
+
+Quelques exemples incluent le recensement des points de recyclage, des endroits
+accessibles (pour les fauteuils roulants par exemple), des points ou il y à de
+la publicité (la plupart des villes ne les recensent pas!) etc.
+
+Un backend SIG simple à utiliser
+--------------------------------
+
+Disons que vous êtes developeur mobile. vous ne voulez pas vous encombrer avec
+PostGIS ou écrire du code specifique pour récupérer et insérer des données SIG!
+Vous avez besoin de *Carto-Forms*! Une API simple vous aide à penser vos
+modèles et vos formulaires, et cette même API vous permet d'insérer et de
+récupérer des données. Vous pouvez vous concentrer sur votre application et non
+pas surla manière dont les données géographiques sont stockées et gérées.
+
+En d'autres termes, vous faites une distinciton entre le stockage des
+informations et leur affichage.
+
+Si vous êtes un developeur django, plomino, drupal etc. vous pouvez developer
+un module pour "plugger" votre interface utilisateur avec celle de
+*Carto-Forms*. De cette manière, il est possibnle d'exposer les formulaires aux
+utilisateurs de vos backoffices. De la même manière, il est possible d'écrire
+des widgets qui consomment des données et les affichent (en utilisant par
+exemple une bibliothèque javascript de webmapping).
+
+Un outil de visualisation
+-------------------------
+
+Il est possible d'explorer mon jeu de données en utilisant des filtres sur
+chacun de mes champs. Le faceting peut etre une idée pour faciliter ce
+filtrage. Une carte affiche le resultat et il est possible de télécharger les
+données brutes (geojson, xml). Idéalement, le mieux serait d'obtenir ces
+données filtrées directement depuis une API Web.
+
+Ça n'existe pas déjà tout ça ?
+===============================
+
+Bien sur, il y à google forms, wui vous permet de faire ce genre de choses,
+mais comme je l'ai précisé plus haut, il ne s'agit pas exactement de la même
+chose.
+
+Nous avons découvert https://webform.com qui permet de créer des formulaires
+avec un système de drag'n'drop. J'adorerais reproduire quelque chose de
+similaire pour l'interface utilisateur. Par contre ce projet ne gère pas les
+appels via API et les informations de géolocalisation …
+
+http://mapbox.com fait également un superbe travail autour de la cartographie,
+mais ne prends pas en compte le coté autogénération de formulaires…
+
+On est parti ?!
+===============
+
+Comme vous avez pu vous en rendre compte, il ne s'agit pas d'un problème
+outrageusement complexe. On à pas mal disucté avec Mathieu, à propos de ce
+qu'on souhaite faire et du comment. Il se trouve qu'on peut surement s'en
+sortir avec une solution élégante sans trop de problèmes. Mathieu est habitué à
+travailler autour des projets de SIG (ce qui est parfait parce que ce n'est pas
+mon cas) et connaît son sujet. Une bonne opportunité d'apprendre!
+
+On sera tous les deux à `Djangocong`_ le 14 et 15 Avril, et on prévoit une
+session de *tempête de cerveau* et un sprint sur ce projet. Si vous êtes dans
+le coin et que vous souhaitez discuter ou nous filer un coup de pate, n'hésitez
+pas!
+
+On ne sait pas encore si on utiliser django ou quelque chose d'autre. On à
+pensé un peu à CouchDB, son système de couchapps et geocouch, mais rien n'est
+encore gravé dans le roc! N'hésitez pas à proposer vos solutions ou
+suggestions.
+
+Voici le document etherpad sur lequel on à travaillé jusqu'à maintenant:
+http://framapad.org/carto-forms. N'hésitez pas à l'éditer et à ajouter vos
+commentaires, c'est son objectif!
+
+.. _Djangocong:  http://rencontres.django-fr.org
+.. _Mathieu: http://blog.mathieu-leplatre.info/
+.. _Makina Corpus: http://makina-corpus.com

content/dev/carto-forms.rst

@@ -1,40 +1,49 @@
 Carto-forms
 ###########
 
+:slug: carto-forms
 :date: 30-03-2012
 :author: Alexis Métaireau, Mathieu Leplatre
 :tags: GIS, forms
+:lang: en
 :status: draft
 
-The idea
+We  have a plan.
-========
 
-This idea is walking in my head since some time and I've been talking with a
+A bunch of friends asked me twice for quite the same thing: a webpage with a
-bunch of people about it in the last few months. to put it shortly: what if we
+form, tied to a map generation with some information filtering. They didn't
-had a way to build forms, ala google forms, but with geographic informations in
+explicitely asked that but that's the grasp of it.
-them?
+
+This idea is walking in my head since and I even think that we can come out
+with something a little bit more flexible and useful. I've named it
+*carto-forms* for now, but that's only the "codename".
+
+To put it shortly: what if we had a way to build forms, ala google forms, but
+with geographic informations in them?
 
 If you don't know google forms, it means having an user-friendly way to build
-forms, for the users. The form can then be used to submit data to a server,
+forms and to use them to gather information from different users.
-which will do something with it.
 
-Google forms is missing two important things: first, it's not open-source, so
+In my opinion, Google forms is missing two important things: first, it's not
-it's not possible to hack it, or even to run it on your server. Second, it
+open-source, so it's not possible to hack it or even to run it on your own
-doesn't *really* know how to deal with geographic data.
+server.  Second, it doesn't really know how to deal with geographic data, and
+there isn't any way to filter the information more than in a spreadshit.
 
-The use cases
+I knew that Mathieu would be interested in this, so I started a discussion with
-=============
+him on IRC and we refined the details of the project and its objectives.
 
-I can see many use cases for this. The first one is a collaborative map, with
+Some use cases
-facet filtering. Let's draw the user flow here:
+==============
 
-* An "administrator" goes to the website and create a form to list all the bear
+I can see some use cases for this. The first one is a collaborative map, with
-  hugging events in the world. He creates the following fields:
+facet filtering. Let's draw a potential user flow:
+
+* An "administrator" goes to the website and create a form to list all the
+  alternative-related events. He creates the following fields:
   
   * Name: a plain text field containing the name of the event.
 
-  * Category: the category of the event. Can be a finite list (only brown
+  * Category: the category of the event. Can be a finite list.
-    bears, polar bears, female bears)
 
   * Location: The location of the event. It could be provided by selecting a
     point on a map or by typing an address.
@@ -45,20 +54,28 @@ facet filtering. Let's draw the user flow here:
   multiple selection, date-time, geocoding carto, carto selection etc)
 
 * Once finished, the form is generated and the user gets an url (says
-  http://forms.notmyidea.org/bearhugging) for it.
+  http://forms.notmyidea.org/alternatives) for it.
 
 * REST APIs allow thrid parties to get the form description and to
   push/edit/get information from there.
 
-* He can communicate the address by the means he wants to his community and
+* He can communicate the address by the means he wants to his community so they
-  they can go to the page and fill it.
+  can go to the page and add information to it.
+
+* Then, it is possible to filter the results per location / date or category.
+  This can be done via API calls (useful for third parties) or via a nice
+  interface in the browser.
 
 So, as you may have notice, It would allow us to create interactive maps really
-easily, just a matter of some clicks for the users. and if we also think about
+easily. It's almost just a matter of some clicks for the users. If we also come
-a nice Web API for this, we could do server-side validation and built even
+up with a nice Web API for this, we could do server-side validation and built
-phone applications easily. To push the cursor a bit further, if we can come
+even phone applications easily.
-with a cool description format for the data, we could even build the forms
+
-dynamically on different platforms, with generic clients.
+To push the cursor a bit further, if we can come with a cool description format
+for the forms, we could even build the forms dynamically on different platforms,
+with generic clients.
+
+Here are some other examples of where *carto-forms* could be useful:
 
 Designing dedicated forms for OSM mobile apps
 ---------------------------------------------
@@ -70,48 +87,28 @@ Designing dedicated forms for OSM mobile apps
    prepopulated using device geolocation
 3. At the end of the day, we can see a map with all users contributions using
    this particular form. 
-4. A script can import the resulting dataset and publish/merge with OSM
+4. A script can import the resulting dataset and publish/merge with Open Street
+   Map
 
-Examples:
+Example uses for this include recycling spots, accessible spots (wheelchairs,
-~~~~~~~~~
+etc.), map advertisement boards (most cities do not track them!)…
-
-recycling spots, accessible spots (wheelchairs, etc.), map advertisement
-boards (most cities do not track them!)…
 
 Simple GIS storage backend
 --------------------------
 
-For example, you are a mobile developper, you don't want to bother with PostGIS
+Let's say you are a mobile developper, you don't want to bother with PostGIS
 nor writing custom and unsecure code to insert and retrieve your GIS data! You
-need carto-forms! A simple API helps you to design your models/forms. A simple
+need carto-forms! A simple API helps you to design your models/forms and the
-API allows you to CRUD and query your data. Thus, you only need to focus on
+same API allows you to CRUD and query your data. Thus, you only need to focus
-your application, not on how GIS data will be handled.  Distinguish storage
+on your application, not on how GIS data will be handled.  Distinguish storage
-from widgets
+from widgets.
 
-Besides, if you are a django/plomino/drupal/... maintainer : you
+Besides, if you are a django / plomino / drupal/... maintainer : you
 can develop a module to "plug" your UI to carto-forms! That's how you will
 expose carto forms to your backoffice users (ex: drupal admin UI, django
 adminsite). Likewise, you can write widgets that consume datasets in frontend
 views (using any webmapping js library)
 
-Examples:
-~~~~~~~~~
-
-- communities of users, consumers, ...
-- directory of places
-
-Integration with a template service
------------------------------------
-
-You could connect the output of a form service (fields => values) to the input
-of a template service (variables => values).  A "template service" could be
-some API where you post a dictionnary (keys and values) and obtain some
-generated content.  As examples, template services could be used to generate
-configuration files, email messages, HTML pages...  To build a web interface of
-a template service, you need to display a form where the user can assign values
-to variables.  Variable list, type, options, validation... a form service would
-be really useful.
-
 Visualization tool
 ------------------
 
@@ -134,20 +131,25 @@ geolocation information.
 So… Let's get it real!
 ======================
 
-As you may have understood, this isn't a really complicated problem. I've
+As you may have understood, this isn't a really complicated problem. We have
-started `an etherpad document <http://framapad.org/carto-forms>`_ and we've
+been chatting about that with `Mathieu`_ sometimes about what we would need and
-been chatting about that with `Mathieu`_ some times. I think we can come with
+how we could achieve this.
-an elegant solution without too much pain. Mathieu is used to work with GIS
-systems (which is really cool because I'm not at all) and knows his subject, so
-that's an opportunity to learn ;-)
 
-We will be at `Djangocong`_ on april 14 and 15 and we will probably have
+We probably can come with an elegant solution without too much pain. Mathieu is
-a brainstorming session and a sprint on this, so if you want to help us, or
+used to work with GIS systems (which is really cool because I'm not at all) and
-just to discuss, feel free to join!
+knows his subject, so that's an opportunity to learn ;-)
+
+We will be at `Djangocong`_ on April 14 and 15 and will probably have
+a brainstorming session and a sprint on this, so if you are around and want to
+help us, or just to discuss, feel free to join!
 
 We don't know yet if we will be using django for this or something else. We
 have been thinking about couchdb, couchapps and geocouch but nothing is written
 in stone yet. Comments and propositions are welcome!
 
+Here is the etherpad document we worked on so far:
+http://framapad.org/carto-forms. Don't hesitate to add your thoughts and edit
+it, that's what it's made for!
+
 .. _Djangocong:  http://rencontres.django-fr.org
 .. _Mathieu: http://blog.mathieu-leplatre.info/