mirror of
https://github.com/almet/notmyidea.git
synced 2025-04-28 19:42:37 +02:00
155 lines
6.4 KiB
ReStructuredText
155 lines
6.4 KiB
ReStructuredText
Carto-forms
|
|
###########
|
|
|
|
:slug: carto-forms
|
|
:date: 30-03-2012
|
|
:author: Alexis Métaireau, Mathieu Leplatre
|
|
:tags: GIS, forms
|
|
:lang: en
|
|
:status: draft
|
|
|
|
We have a plan. A "fucking good" one.
|
|
|
|
A bunch of friends asked me twice for quite the same thing: a webpage with a
|
|
form, tied to a map generation with some information filtering. They didn't
|
|
explicitely asked that but that's the grasp of it.
|
|
|
|
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 and to use them to gather information from different users.
|
|
|
|
In my opinion, Google forms is missing two important things: first, it's not
|
|
open-source, so it's not possible to hack it or even to run it on your own
|
|
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.
|
|
|
|
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.
|
|
|
|
Some use cases
|
|
==============
|
|
|
|
I can see some use cases for this. The first one is a collaborative map, with
|
|
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.
|
|
|
|
* Location: The location of the event. It could be provided by selecting a
|
|
point on a map or by typing an address.
|
|
|
|
* Date: the date of the event (a datepicker could do the trick)
|
|
|
|
Each field in the form has semantic information associated with it (yes/no,
|
|
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/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 so they
|
|
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. It's almost just a matter of some clicks for the users. If we also come
|
|
up with a nice Web API for this, we could do server-side validation and built
|
|
even phone applications easily.
|
|
|
|
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
|
|
---------------------------------------------
|
|
|
|
1. For a mapping party, we choose a specific topic to map and design the form
|
|
(list of fields (i.e. tags) to be filled + description + type of the
|
|
information)
|
|
2. In situ, users fill the form fields with what they see. Geo fields can be
|
|
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 Open Street
|
|
Map
|
|
|
|
Example uses for this include recycling spots, accessible spots (wheelchairs,
|
|
etc.), map advertisement boards (most cities do not track them!)…
|
|
|
|
Simple GIS storage backend
|
|
--------------------------
|
|
|
|
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 and the
|
|
same API allows you to CRUD and query your data. Thus, you only need to focus
|
|
on your application, not on how GIS data will be handled. Distinguish storage
|
|
from widgets.
|
|
|
|
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)
|
|
|
|
Visualization tool
|
|
------------------
|
|
|
|
I can explore my dataset content using filters related to each form field.
|
|
Faceting can be an idea in order to ease filtering. A map shows the resulting
|
|
features set, and raw data can be downloaded (geojson, xml) Ideally, I would
|
|
like to obtain a filtered dataset using a Web API.
|
|
|
|
What's out in the wild already?
|
|
===============================
|
|
|
|
Of course, there is google forms, which allows you to do this kind of things,
|
|
but it's closed and not exactly what we are describing here.
|
|
|
|
We've discovered the interesting https://webform.com/ which allows to create
|
|
forms with a nice drag-n-drop flow. I would love to reproduce something similar
|
|
for the user experience. However, the project doesn't handles APIs and
|
|
geolocation information.
|
|
|
|
So… Let's get it real!
|
|
======================
|
|
|
|
As you may have understood, this isn't a really complicated problem. We have
|
|
been chatting about that with `Mathieu`_ sometimes about what we would need and
|
|
how we could achieve this.
|
|
|
|
We probably can come with 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 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/
|