mirror of
https://github.com/almet/notmyidea.git
synced 2025-04-28 19:42:37 +02:00
Alexis Métaireau
9df3b183b6
- Added the ability to display book cover for the category "Lectures" if ISBN cover is available. - Moved author's name into a small tag for better hierarchy and readability. - Implemented a feature to indicate link sizes depending on the number of articles associated with a given tag. - Implemented a mini footer element displaying an RSS feed icon. - Improved category display using description dictionary. - Added a new plugin "isbn_downloader" to fetch ISBN information when needed. - Included the count of articles for each category. - Implemented changes for better layout and readability of tags and categories. - Adjusted the layout of the webpage, improving the overall look of the page. - Included "requests" in the requirements.txt for supplanting dependencies required by the new plugin and/or features.
190 lines
8.3 KiB
Markdown
190 lines
8.3 KiB
Markdown
# Thoughts about a form generation service, GIS enabled
|
|
|
|
*Written by Alexis Métaireau & Mathieu Leplatre*
|
|
|
|
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 explicitly ask that but that's the gist of it.
|
|
|
|
This idea has been stuck in my head since then 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 information 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 is no way to filter the information more than
|
|
in a spreadsheet.
|
|
|
|
I knew that [Mathieu](http://blog.mathieu-leplatre.info/) and some folks
|
|
at [Makina Corpus](http://makina-corpus.com) 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.
|
|
|
|
Imagine the following:
|
|
|
|
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 pre-populated using device geolocation ;
|
|
3. At the end of the day, we can see a map with all user contributions
|
|
seized through this particular form ;
|
|
4. If relevant, a script could eventually import the resulting dataset
|
|
and publish/merge with OpenStreetMap.
|
|
|
|
## 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 creates 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 (say
|
|
<http://forms.notmyidea.org/alternatives>) for it.
|
|
|
|
- REST APIs allow third parties to get the form description and to
|
|
push/edit/get information from there.
|
|
|
|
- He can communicate the address in any way 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 noticed, this would allow us to create interactive
|
|
maps really easily. It's almost just a matter of some clicks to the
|
|
users. If we also come up with a nice Web API for this, we could do
|
|
server-side validation and build 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.
|
|
|
|
As mentioned before, the idea of a simple tool to support collaborative
|
|
mapping fullfils a recurring necessity \!
|
|
|
|
We envision a lot of example uses for this : recycling spots, accessible
|
|
spots (wheelchairs, etc.), trees identification, mushrooms picking
|
|
areas, tracking of endangered species (e.g. Bonelli's Eagle is currently
|
|
tracked by sharing a spreadsheet), spotting of dangerous species (e.g.
|
|
asian predatory wasps), map advertisement boards (most cities do not
|
|
track them\!), citizen reporting (e.g. graffiti, potholes, garbage,
|
|
lightning like <http://fixmystreet.ca>), geocaching, trajectories (e.g
|
|
hiking, runners, cyclists)...
|
|
|
|
Here are some other examples of where *carto-forms* could be useful:
|
|
|
|
### Simple GIS storage backend
|
|
|
|
Let's say you are a mobile developer, you don't want to bother with
|
|
PostGIS nor write a custom and insecure code to insert and retrieve your
|
|
GIS data\! You need carto-forms\! A simple API helps you 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.
|
|
|
|
We make a distinction between storage and widgets.
|
|
|
|
Besides, if you are a django / drupal / plomino... maintainer : you can
|
|
develop a module to "plug" your models (content types) and UI to
|
|
carto-forms\! Carto forms are then exposed to your backoffice users (ex:
|
|
drupal admin UI, django adminsite), and likewise you can write your own
|
|
HTML widgets that consume datasets in frontend views (facets in
|
|
JSON/XML, and map data in GeoJSON).
|
|
|
|
### Visualization tool
|
|
|
|
Since data submission can be done programmatically using the API, you
|
|
could use Carto-forms results page as a visualization tool.
|
|
|
|
You can explore your dataset content using filters related to each form
|
|
field. Facets filtering is a great advantage, and a map shows the
|
|
resulting features set. You feel like you're in front of a decision
|
|
support system\!
|
|
|
|
Of course, filtered raw data can be downloaded (GeoJSON, XML) and a
|
|
permalink allows to share the page with the state of the filters and the
|
|
zoom/location of the map.
|
|
|
|
### Generic forms service
|
|
|
|
If you want to generate a configuration file (or whatever, email
|
|
messages, ...), you will need a form and a template to inlay user
|
|
submitted values and get the result.
|
|
|
|
A form service would be really useful to create forms programmatically
|
|
and retrieve cleaned and validated input values.
|
|
|
|
You could run a dedicated template service based on *carto-forms*\!
|
|
Parsing a template content, this external service could create a form
|
|
dynamically and bind them together. The output of the form service
|
|
(fields =\> values) would be bound to the input of a template engine
|
|
(variables =\> final result).
|
|
|
|
Note that for this use-case, there is no specific need of GIS data nor
|
|
storage of records for further retrieval.
|
|
|
|
## What's out in the wild already?
|
|
|
|
Of course, there is Google forms, which allows you to do these 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 one
|
|
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
|
|
handle APIs and geolocation information.
|
|
|
|
The idea of <http://thoth.io> is very attractive : an extremely simple
|
|
web API to store and retrieve data. In addition, *carto-forms* would do
|
|
datatype validation and have basic GIS fields (point, line, polygon).
|
|
|
|
<http://mapbox.com> also did an awesome work on cartography, but didn't
|
|
take into account the form aspect we're leveraging here.
|
|
|
|
## So… Let's get it real\!
|
|
|
|
As you may have understood, this isn't a really complicated problem. We
|
|
have been sometimes chatting about that with Mathieu about what we would
|
|
need and how we could achieve this.
|
|
|
|
We can probably 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](http://rencontres.django-fr.org) 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 proposals 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\!
|
|
|
|
Thanks to [Arnaud](http://sneakernet.fr/) and
|
|
[Fuzzmz](http://qwerty.fuzz.me.uk/) for proof-reading and typo fixing.
|