Saturday, December 10, 2016

Learn to code (javascript)

This chapter is going to introduce each programming concept with simple snippets of code, all written in JavaScript (obviously!).

It cannot be emphasized enough: while you go through this chapter -- and you may need to spend the time to go over it several times -- you should practice each of these concepts by typing the code yourself. The easiest way to do that is to open up the developer tools console in your nearest browser (Firefox, Chrome, IE, etc.).

Tip: Typically, you can launch the developer console with a keyboard shortcut or from a menu item. For more detailed information about launching and using the console in your favorite browser, see "Mastering The Developer Tools Console" ( To type multiple lines into the console at once, use <shift> + <enter> to move to the next new line. Once you hit <enter> by itself, the console will run everything you've just typed.

Let's get familiar with the process of running code in the console. First, I suggest opening up an empty tab in your browser. I prefer to do this by typing about:blank into the address bar. Then, make sure your developer console is open, as we just mentioned.

Now, type this code and see how it runs:

a = 21;b = a * 2;console.log( b );

Go on, try it. The best way to learn programming is to start coding!


In the previous code snippet, we used console.log(..). Briefly, let's look at what that line of code is all about.

You may have guessed, but that's exactly how we print text (aka output to the user) in the developer console. There are two characteristics of that statement that we should explain.

First, the log( b ) part is referred to as a function call (see "Functions"). What's happening is we're handing the b variable to that function, which asks it to take the value of b and print it to the console.

Second, the console. part is an object reference where the log(..) function is located. We cover objects and their properties.

Another way of creating output that you can see is to run an alert(..) statement. For example:
alert( b );
If you run that, you'll notice that instead of printing the output to the console, it shows a popup "OK" box with the contents of the b variable. However, using console.log(..) is generally going to make learning about coding and running your programs in the console easier than using alert(..), because you can output many values at once without interrupting the browser interface.

For this book, we'll use console.log(..) for output.

We help our campers build job-worthy portfolios of real apps used by real people, while helping nonprofits.

You start by working through our self-paced, browser-based full stack JavaScript curriculum.

By working through our curriculum, you can earn four certifications:

Liste of API (google and openAPI)

Directory of REST API specs in OpenAPI(fka Swagger) 2.0 format

Friday, December 9, 2016

mise en parallèle langage markdown d'odyssey.js et API odyssey/leaflet.js

markdown odyssey ou leaflet.js
- center: [37.7620, -122.4385]
- zoom: 9
Ici, au début ce sera du odyssey.js de la documentation
var map = new L.Map('map', {
  center: [37, -91],
  zoom: 6

map.actions.panTo([37.1, -92]);

L.marker([37.7620, -122.4385]).actions.addRemove(


L.marker([37.82, -122.0]).actions.addTo(

var map = new L.Map('map', {
  center: [37, -91],
  zoom: 6

    L.marker([37, -92]).actions.addTo(map)
L.marker([50.5, 30.5]).addTo(map);

L.marker<LatLnglatlng,<Marker optionsoptions? )

L.marker([44.7348, -67.5655],
iconSize: [22, 40], 
iconAnchor: [12, 39])})
cela permet de changer l'icone.

var marker = L.marker([0, 0])
    marker.actions.icon('enabled.png', 'disabled.png')

Creates an action that changes the icon of a marker. It receives two arguments (iconEnabled, iconDisabled).
var myIcon = L.icon({
    iconUrl: 'my-icon.png',
    iconRetinaUrl: 'my-icon@2x.png',
    iconSize: [38, 95],
    iconAnchor: [22, 94],
    popupAnchor: [-3, -76],
    shadowUrl: 'my-icon-shadow.png',
    shadowRetinaUrl: 'my-icon-shadow@2x.png',
    shadowSize: [68, 95],
    shadowAnchor: [22, 94]

L.marker([50.505, 30.57], {icon: myIcon}).addTo(map);

L.Icon.Default extends L.Icon and is the blue icon Leaflet uses for markers by default.

pour avoir des tooltips (hover) et popups, on peut faire dans le markdown:
L.marker([40.7348, -73.9970],{title:"I am a tooltip", opacity: 0.7}).bindPopup("<b>Hello world!</b><br>I am a popup.").actions.addRemove(

Si le media dépasse 340px de large,
 il faut passer à autre chose qu'un simple bindPopup
("<b>Hello world!</b><br>")
mais aller en plus dans les options du popup:
'<b>video with width=480 
and L.popup maxWidth:500 </b>
<mark>OK</mark><br><span style="color:blue">blue</span>...<br>
<iframe width="480" height="360" src=""></iframe>'

pour ouvrir une fenêtre "alert" avec un bouton "OK" et le texte indique :
 You clicked the map at LatLng(40.7348, -73.997)
L.marker([40.7348, -73.9970]).on("click", function(e){alert("You clicked the map at " + e.latlng);}).actions.addTo(

Unfortunately, if the image is not loaded yet in browser cache, the popup will open right away with default size (not if you set maxWidth "auto"), and adjust its size but sometimes not its position once the image is fully loaded and displayed. 
var map = new L.Map('map', {
  center: [37, -91],
  zoom: 6
var popup = L.popup().setLatLng(latlng).setContent('&lt;p&gt;popup for action1&lt;/p&gt;')

  .addState(O.Scroll().within($('#myelement'), popup.actions.openOn(map));
L.marker<LatLnglatlng,<Marker optionsoptions? )
option1: title (Text for the browser tooltip that appear on marker hover (no tooltip by default).)
option2: opacity (1=full opacity)
L.marker([40.7348, -73.9970],{title:"I am a tooltip", opacity: 0.7}).
le markdown utilise marker/events de Leaflet, la fct:
bindPopup( <String> html | <HTMLElement> el | <Popup> popup, <Popup options> options? )
Binds a popup with a particular HTML content to a click on this marker. You can also open the bound popup with the Marker openPopup method.

The leaflet documentation shows you can add a popup to a marker with
marker.bindPopup("<b>Hello world!</b><br>").openPopup();
ou créer un standalone popup
var popup = L.popup()
    .setLatLng([51.5, -0.09])
    .setContent("I am a standalone popup.")
On peut combiner les deux:
var popup = L.popup()
    .setContent("I am a standalone popup.");
On peut ajouter les options du popup

ou d'autres events-marker par exemple avec la fenêtre alert:
map.on('click', function(e) {alert(e.latlng);});

voir ICON ci-dessus L.marker( [
        ], {
            icon : L.icon( {
                iconUrl : '',
            } )
        } ).addTo( this );
à venir à venir

Map Marker Free Icon (static (pre-made) and builder)
look likes Google maps,
from 1 to 100[color][character].png

.... (...) (...)
9 colors: red, black, blue, green, grey, orange, purple, white, yellow
also with A-Z.
size 22x40px

Google's new marker icons look great, but they never bothered to provide us with matching PNG versions of them when we need custom colors and labels. I went ahead and created my own set using ImageMagick and my ImageMagick.vbs VBScript file. You can also link to the pre-generated images I created instead of creating your own.


builder (svg) save to png

icon  (old design)



"Placeholder Images" et des icones/photos aléatoires

C'est un site qui offre le web service suivant:
avec ces liens
ce service renvoie une photo au format désiré ici 400*200 de manière aléatoire sauf si on précise par exemple à la fin /1/

Dans la catégorie "nature" il y en a 20photos.
Il y a d'autres catégories.

Vous avez deux sliders pour sélectionner le format (max 1920x1920px)

Si vous voulez un autre format par exemple pour les markers leaflet 38x95pix,

cela fonctionne:
L.marker( [
        ], {
            icon : L.icon( {
                iconUrl : '',
            } )
        } ).addTo( this );

Avec Flickr

Thursday, December 8, 2016

timeMapper: timeline and story map from okfnlabs


examples (map empty)

one of my story map:


1. Create a Spreadsheet
Add your dates and places to a Google Spreadsheet.

2. Connect and Customize
Connect your spreadsheet with TimeMapper and customize the results.

3. Publish, Embed and Share
Publish your TimeMap at your own personal url, then share or embed on your site.

TimeMapper is an open-source project of Open Knowledge Foundation Labs. It is possible thanks to a set of awesome open-source components including TimelineJS, ReclineJS, Leaflet, Backbone and Bootstrap. You can find the full open-source source for TimeMapper on GitHub here:

The Spreadsheet

What structure must the spreadsheet have?

TimeMapper recognizes certain columns with specific names. The best overview of these columns is the template, which has rows of instructions and examples:

Not all fields are required. The only required fields are Title and Start fields, and even Start can be omitted if you just want a map. Note that you can add any number of other columns beyond those that TimeMapper uses.

How do I format dates?

The preferred date format is ISO 8601 (YYYY-MM-DD), but TimeMapper recognizes most types of date.

If a date's month and day are ambiguous (e.g. is 08-03-1798 UK notation for 8 March, or is it US notation for 3 August?), by default, the first number will be interpreted as the month. You can change this by clicking the edit button in the top right corner of your TimeMap's display and selecting between US- and non-US-style dates.

What kinds of geodata are supported?

The Location column accepts two types of geodata: latitude-longitude coordinates or GeoJSON objects.

Coordinates must be in the format lat, long (e.g. 37.5, -122). The spreadsheet template includes a formula which automatically looks up coordinates corresponding to human-readable place names in the Place column:
This formula is explained in a School of Data blog post:

Advanced users who want to go beyond simple coordinates can use GeoJSON feature objects. For an example, see this blog post on adding GeoJSON country boundaries to spreadsheets:

Dynamic Google Spreadsheet

If the owner select a wide sharing rule, you can do a narrative story map this many people.
Sharing options:


  • long time for upload your story map
    It's a dynamic process:
    1. it reads your Google Spreadsheet, 
    2. builds the interface...
  • For the first slide, don't put too much texte because on the first view the slider doesn't work. With http at the end with #0, it works.

  • zoom is fixed for all slides (you must zoom manually, no auto-zoom)
    if the zoom was on the center of this DOM, we could use zoom by touch ;)
  • user events: click allowed but you can only view the "Title" (but this Title is an HTML structure , then you can add audio, img...
  • user events: no hover events
  • Embed button is out...
  • audio is OK for chrome (v55) but with firefox not easy to stop if you put this in the "Title", and with Safari (sierra) many problems...

GitHub timeMappper

Data View info

Stored in datapackage.json following Data Package spec.
Key points:

  • name, title, licenses etc as per Data Package
  • info on google doc data source stored in first resources item in format compatible with Recline

resources: [{
  backend: 'gdocs',
  url: 'gdocs url ...'

GeoJSON, ce que vous ne pouvez faire GeoJSON et le problème de l'ordre latitude longitude des coordonnées sphériques

Le problème de l'ordre Longitude, Latitude ou Latitude, Longitude dans les données et les formats, est important.

Commençons par regarder le format GeoJSON. Comprendre ces concepts de format informatique/physique/mathématique/géomatique vous aidera à comprendre les données géospatiales en général: les concepts de base derrière GeoJSON ont été une partie de "geo" depuis le tout début.

La spécification GeoJSON elle-même est une spécification formelle d'un format assez lisible pour le javascript:
GeoJSON (2008) is a geospatial data interchange format based on JavaScript Object Notation (JSON).

Ce que vous ne pouvez faire GeoJSON 

La popularité de GeoJSON dérive de sa simplicité, ce qui le rend facile à mettre en œuvre, à lire et à partager. Mais comme tous les autres formats, il a ses limites:
  • GeoJSON n’a aucune construction de topologie, que ce soit pour la compression, tels que TopoJSON ou sémantique, comme OSM XML et certains formats propriétaires. Une couche topologique sur GeoJSON est possible mais elle est restées lettre morte. 
  • "GeoJSON caractéristiques" ont des propriétés (features) qui sont de JSON. Ces features peuvent utiliser tous les types de données JSON : nombres, chaînes, tableaux null, booléens, et des objets. JSON ne supporte tous les types de données : par exemple, les valeurs de date sont prises en charge par Shapefiles, mais pas dans JSON. 
  • GeoJSON n’est pas une construction de style caractéristiques ou en spécifiant le contenu popup. Il y a des conventions folkloriques pour le faire, mais ceux-ci ne sont pas et ne sera pas dans la spécification. La plupart des formats de geo n’ont pas style. 
  • GeoJSON n’est pas un type de géométrie du cercle, ou n’importe quel type de courbe. Seuls quelques formats, comme WKT prend en charge les courbes et des cercles plutôt que des géométries linéaire. Cercles et courbes sont relativement difficiles à mettre en œuvre, car un cercle sur une planète de géoïde sphéroïde est beaucoup plus complex qu’un cercle sur une feuille de papier ;)
  • Positions n’ont pas des attributs. Si vous avez une représentation de LineString d'une course/ballade, et votre GPS montre connecté avec 1 000 points différents le long du parcours avec des données comme votre fréquence cardiaque et de la durée, hélas il n’y a aucune réponse claire pour la représentation de ces données. Vous pouvez stocker des données supplémentaires dans des positions coordonnées de quatrième et cinquième, ou dans les propriétés sous forme de tableau avec la même longueur que le tableau de coordonnées, mais aucune de ces options est supporté par l’écosystème des outils. La spécification de fonctionnalités simples, qui a directement inspiré GeoJSON et la plupart des formats SIG, ne supporte pas cette notion d’attributs-à-poste (voir les deux formats - GPX et OSM XML).

Latitude et Longitude

Une incohérence frustrante dans les logiciels géospatiaux (notamment de type mappage) est l'ordre des coordonnées.
Les coordonnées sont souvent représentées sous forme de tableaux, comme [45.1, 4.1.], au lieu d'objets, comme {lng: 4.1, lat: 45.1}. Cela laisse au développeur de déterminer si 45.1 est la longitude ou la latitude. Un choix place un point sur Lyon, et l'autre un emplacement profond dans la Somalie.
La latitude de la ville de Lyon est proche de 45. Le pole nord c'est Lat=90 et l'équateur c'est une Lat= 0.
La longitude "0.00" est lié à Greenwich (Lat 51.48; Lng 0.00) un quartier de Londres :

Le système de référence de coordonnées (CRS) 

Le système de référence de coordonnées (CRS) d'un objet GeoJSON est déterminé par son membre 'crs'. Si un objet n'a pas de membre crs, son membre crs de l'objet parent ou grand-parent peut être acquis. Si aucun membre crs ne peut être ainsi acquis, le CRS par défaut s'appliquera à l'objet GeoJSON.
Le CRS par défaut est un système de référence de coordonnées géographiques, utilisant le datum WGS84, et avec des unités de longitude et de latitude de degrés décimaux.

GeoJSON (ici minimaliste) pour un point situé sur Fourvière à Lyon:
  "type": "FeatureCollection",
  "features": [
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Point",
        "coordinates": [
GeoJSON a un ordre = Longitude,Latitude

L'ordre latitude longitude ou l'inverse

Il ya un certain consensus croissant autour de l'ordre (longitude, latitude) pour les formats géospatiaux, mais hélas c'est toujours le chaos pour les bibliothèques et les logiciels. Il appartient au développeur d'être conscient de ce problème et de lire la documentation requise, surtout de déplacer les coordonnées si nécessaire pour traduire entre différents systèmes:

La tradition géographique favorise lat, lon mais les mathématiques et souvent les logiciels préfèrent l'ordre lon, lat...
L'utilisation des coordonnées sphériques différent suivant les domaines.
En physique c'est "(r, θ, φ)" avec la distance radiale, l'angle dans le plan équateur, puis l'angle azimuthal.
En mathématiques "(r, θ, φ)" avec la distance radiale, l'angle azimuthal puis l'angle dans le plan équateur.
En fait il existe un ISO standard 80000-2 :2009 pour l'ordre des angles (item 2-16.3 coordinate systems: spherical coordinates). La latitude est en premier.
Hélas cet angle "latitude" mathématique est égal à 0 au "pôle nord" (par rapport à l'axe zenith ou z axis en coordonnées euclidiennes). Il est noté :

L'angle entre l'axe et le plan équateur est dans la borne: [0,π].
L'angle dans le plan équateur (perpendiculaire à l'axe zenith) est dans la borne:  [0,2π[.

Qu'en est-il de GPX ou OSM XML? 

Les formats qui représentent lat et lon avec des attributs XML distincts et n'imposent aucun ordre de coordonnées, car les attributs XML ne sont pas ordonnés...

Ref: en anglais

Modéliser plus pour simuler moins

Frédéric Alexandre, vous êtes chercheur au Laboratoire bordelais de recherche en informatique (LaBRI1) et intervenant du colloque « Modélisation : succès et limites » du 6 décembre 2016.  Qu’entend-on au juste aujourd'hui par modélisation et simulation ?

F. A. : La dimension numérique s'est intensément développée dans tous les domaines où l'on sait représenter les phénomènes par des équations que l'on peut ensuite implanter informatiquement – on parle alors de modèles de connaissance. Ce phénomène s’est amplifié, surtout dernièrement avec la possibilité d'utiliser les données massives (big data) et l’apprentissage automatique (machine learning) pour faire des statistiques – on parle dans ce cas de modèles de représentation.
Mais construire une maquette et la mettre dans une soufflerie, c’est aussi modéliser et simuler. Construire un modèle est un processus particulier : il s'agit de choisir un cadre théorique, un formalisme pour décrire un objet d’étude, et que l'ensemble soit adapté à la question que l’on se pose sur cet objet. C’est aussi prévoir, dès sa conception, le moyen de valider ce modèle : il faut pouvoir montrer qu’il répond bien à la question posée. Le simuler, c’est le mettre en œuvre informatiquement, via des logiciels en adoptant notamment des schémas de calcul, et des matériels en utilisant une architecture adaptée aux calculs à réaliser, pouvant associer des processeurs spécifiques comme des processeurs graphiques, des grappes de machines homogènes (clusters) ou un ensemble de ressources hétérogènes et éventuellement délocalisées, la grille. Il faut également noter que gérer ces matériels nécessite de recourir à des logiciels dits intermédiaires (middleware). Le principe de cette simulation consiste à pouvoir, à ce stade, faire varier des paramètres pour voir comment le modèle évolue.

On nous annonce depuis longtemps la fin de la loi de Moore relative à l'accroissement régulier de la puissance des ordinateurs. Le débat pourrait effectivement porter sur le fait que cette étape commence effectivement à se faire sentir ou que le génie humain trouvera toujours des solutions de substitution. Mais je pense qu'il est plus important de savoir si l’on a intérêt à développer des modèles de plus en plus complexes lorsque cela se fait au détriment d'une réflexion sur la nature et la pertinence des modèles utilisés. Et puis, faire tourner des clusters de machines a aussi un coût économique et écologique !
Ensuite, et de façon peut-être plus profonde, faire tourner rapidement un modèle en dehors de ses limites de validité ne le rend pas plus valide !
Un modèle plus simple mais plus adapté est toujours préférable. Autant on peut justifier l'accroissement du recours aux simulations quand il s'agit de faire tourner un modèle plus longtemps, sur une plus grande extension spatiale, ou de tester plus de jeux de paramètres, autant il convient de rester prudent quand on change d’échelle ou quand, par exemple, on agrège plusieurs modèles.

Vaudrait-il mieux complexifier ou plutôt simplifier ces modèles et simulations pour s'approcher au mieux de la réalité ?
F. A. : Pour répondre à cette question difficile, il faut d’abord introduire un autre acteur. En plus des modèles théoriques associés aux simulations numériques, il y a maintenant le duo big data-machine learning : là, des corpus gigantesques sont analysés par des procédures d’apprentissage automatique s’appuyant sur des modèles statistiques. Par exemple, dans le domaine du traitement automatique du langage, plutôt que de travailler sur la mise au point de modèles de langage, il est aujourd’hui plus efficace d’analyser statistiquement des corpus de millions de phrases pour faire des systèmes de traduction automatique performants. Et l'on peut penser qu’il en sera bientôt de même pour la description d’objets physiques où le recours aux équations de la physique sous-jacente serait moins efficace que l’analyse d’un corpus d’exemples…
Sans remettre en cause les performances bien réelles et même impressionnantes de ces systèmes, on peut simplement remarquer qu’ils poussent au bout la logique de la puissance de calcul au détriment de l’analyse de l’objet d’étude. Analyse qui aurait pu parfois permettre de trouver une solution plus élégante et surtout plus porteuse de sens. De gros modèles très paramétrés peuvent coller à beaucoup de données sans en extraire la logique sous-jacente. Prédire n’est pas expliquer, rappelle René Thom.

Et surtout – pour répondre enfin à la question –, ces deux approches, tant statistiques que théoriques, couplées à une utilisation massive de la simulation oublient parfois le principal : quelle est la question posée et le modèle est-il bien conçu pour y répondre ? Ces approches massives sont bien adaptées et commencent aujourd’hui à être bien maîtrisées sur des questions relatives à des phénomènes relativement réguliers. Toutefois, dès lors que ces phénomènes impliquent des considérations humaines, sociales, politiques ou cognitives, bien formuler les questions que l’on se pose et définir un modèle plus simple est souvent plus pertinent qu’appuyer tout de suite sur le bouton rouge de la simulation.

Wednesday, December 7, 2016

jekyllrb : Transform your plain text into static websites and blogs. And GitHub Pages.

Jekyll is the engine behind GitHub Pages, which you can use to host sites right from your GitHub repositories.
Publishing a website or software documentation with GitHub Pages now requires far fewer steps — three to be exact:

  1. Create a repository (or navigate to an existing repository)
  2. Commit a Markdown file via the web interface, just like you would any other file
  3. Activate GitHub Pages via your repository's settings

And that's it — you now have a website. If you're already familiar with GitHub Pages, you may be interested to know that behind the scenes, we're now doing a few things to simplify the publishing experience and bring it more in line with what you may expect from authoring Markdown content elsewhere on GitHub:

All Markdown files are now rendered by GitHub Pages, saving you from needing to add YAML front matter (the metadata at the top of the file separated by ---s) to each file.

We'll use your README file as the site's index if you don't have an (or index.html), not dissimilar from when you browse to a repository on GitHub.

If you don't specify a theme in your site's config (or don't have a config file at all), we'll set a minimal, default theme that matches the look and feel of Markdown elsewhere on GitHub.

If a given file doesn't have a layout specified, we'll assign one based on its context. For example, pages will automatically get the page layout, or the default layout, if the page layout doesn't exist.

If your page doesn't have an explicit title, and the file begins with an H1, H2, or H3, we'll use that heading as the page's title, which appears in places like browser tabs.

These improvements should allow you to quickly and easily publish your first (or 100th) website with just a few clicks, or to document your software project by simply adding Markdown files to a /docs folder within your repository. Of course, you can continue to control the look and feel by opting in to additional customizations (such as overriding the default theme with your own layouts or styles).

While these changes shouldn't affect how most existing sites build, there are two potential gotchas for some more advanced Jekyll users:

If your site iterates through all pages (e.g., for page in site.pages), you may find that there are now additional pages (such as the README of a vendored dependency) in that list. You can explicitly exclude these files with your config file's exclude directive.

If you don't specify a page's layout or title, and expect either to be unset (e.g., if you need to serve unstyled content), you'll need to explicitly set those values as null.

And if for any reason you don't want these features, you can disable them by adding a .nojekyll file to your site's root directory.

So that the GitHub Pages build process can be as transparent and customizable as possible, all the above features are implemented as open source Jekyll plugins.

Transform your plain text into static websites and blogs.

No more databases, comment moderation, or pesky updates to install—just your content.

Markdown (or Textile), Liquid, HTML & CSS go in. Static sites come out ready for deployment.

Permalinks, categories, pages, posts, and custom layouts are all first-class citizens here.

Nouveau projet sur la bible numérique multi-niveaux par les créateurs de la Bible de Jérusalem


La Bible en ses Traditions est un projet de l’École Biblique et Archéologique Française de Jérusalem, les créateurs de la Bible de Jérusalem. Le projet « Bible en ses traditions » a été lancé en 2000 par l’École biblique et archéologique de Jérusalem (Ebaf). Fondateurs de cette prestigieuse école en 1890, les dominicains se sont illustrés tout au long du XXe siècle par leur travail méthodique sur le texte biblique et sa traduction, publiant la Bible de Jérusalem, l’une des traductions les plus connues du texte biblique.
En décembre 2016, le site atteint sa première maturité.
À l’occasion des dix ans du projet Best, un colloque international sur le thème « Mise(s) en œuvre(s) des Écritures » a été organisé les 5 et 6 décembre à l’université Sorbonne Nouvelle-Paris 3, à Paris.

Le but de ce projet

Nous avons l’intention de créer un ensemble de notes le plus étendu et le plus utile possible pour la bible tout entière, avec une information qui intéressera les spécialistes bibliques comme les lecteurs occasionnels.

Les particularités

La Bible en ses Traditions présentera les différences significatives entre différentes versions du texte biblique dans le texte lui-même, plutôt que dans les notes de bas de page. En outre, le texte sera accompagné de notes étendues réparties en différents sujets, tels que le vocabulaire, le milieu social et culturel, la tradition juive et chrétienne, notamment.

le site Internet du projet atteint aujourd’hui une première maturité avec la mise en ligne d’un « rouleau numérique ». Il permet de cliquer sur le texte biblique et de découvrir nombre d’éclairages, verset après verset. L’interface est austère, mais le contenu fascinant par sa profusion et sa richesse.
« Au lieu d’un seul texte biblique, le rouleau numérique de Best donne à voir une polyphonie, se réjouit Olivier-Thomas Venard, dominicain, vice-recteur de l’École biblique de Jérusalem et directeur de Best. Au fond, Internet permet de refermer la parenthèse de la traduction imprimée, qui n’a pas fait que du bien à la Bible en la présentant comme un texte figé. Avec le rouleau numérique, on sent un texte vivant, en effervescence, produit par et pour des communautés croyantes, avec tous les commentaires savants qu’il a suscités. »

Le site

Diverses versions

Le principe d’unité de toute l’Écriture a toujours déterminé une tendance à disposer d’un texte de référence, qui puisse être considéré comme autorisé et authentique.

  • Le judaïsme rabbinique reconnaît pour seule authentique la version du texte massorétique (TM ou M). Toutes les polyglottes que l’on connaît tendent à faire référence à la bible hébraïque comme instance critique.
  • L’Église grecque a retenu la Septante (LXX ou G)
  •  L’Église latine la Vulgate (V)
  • L'Église syriaque la Peshitta (S)

revue de press

Tuesday, December 6, 2016

Trending in open source See what the GitHub community is most excited about today.

Trending in open source

One of the best project:
Jekyll is a simple, blog-aware, static site generator perfect for personal, project, or organization sites. Think of it like a file-based CMS, without all the complexity. Jekyll is the engine behind GitHub Pages, which you can use to host sites right from your GitHub repositories.

Open Data Sandbox U.S. General Services Administration (GitHub)
U.S. General Services Administration's stack deployment

Hofstra tools: story map and Web based mapping tools for teaching and research

2 working demonstrations using mapping technology to navigate historical data or literature:

  • "Plague Year," which provides a timeline-based navigation tool to step through events recorded from Defoe's A Journal of the Plague Year.
  • Melville in Rome, which enables the exploration of possible routes taken by Melville in between events recorded in his journal of his time spent there.
use of :

a-frightful-number-plague is the name of a CSV file in the _data folder, for this project.
This Jekyll variable (events) is used in the body of this document to render the itinerary table.
The CSV file referenced above generates HTML in the body of this document as well as a JSON data file referenced by JavaScript code.

odyssey.js and Paper in 6th International Conference on Cartography and GIS 2016

Proceedings, 6th International Conference on Cartography and GIS, 13-17 June 2016, Albena, Bulgaria ISSN: 1314-0604, Eds: Bandrova T., Konecny M.
Teresa Iturrioz, Clara Rodríguez Fernández, José Pablo Gómez Barrón Sierra, Ramón Alcarria

export de votre story map réalisé avec odyssey.js et personnalisation par l'utilisateur

exporter / partager votre narrative story map 

Vous avez 5 possibilités pour exporter / partager votre narrative story map réalisée avec odyssey.js.

pour les dummies, avec les 3 fonctions intégrées (en bas à droite du sandbox):

  • une fichier html (compressé en .zip) pour une utilisation en local ou à mettre sur un serveur, 
  • avec l'hébergement via une iframe (pour votre blog par exemple) ou un lien URL
pour les plus expérimentés 
  • avec gitHub et ses services d'hébergement, Là vous pouvez même conserver le sandbox pour une utilisation en mode partagé.
  • votre fichier .md (markdown) en le copiant/collant. En outre ce fichier est présent à la fin de votre fichier .html... Vous pouvez ensuite le transcoder avec divers outils de conversion.

personnaliser votre story map pour une lecture adaptée

Outre le fait que l'on peut choisir sa basemap comme expliquer dans mon exemple (voir les post de ce blog avec les tags map, GPS).
On peut adapter la lecture.
Faite ouvrir un fichier dans votre navigateur et ouvrez votre .html de votre sauvegarde ou votre bl.ocks.
Faite un clic droit (ou crtl clic sur mac) sur le texte.
vous avez 
dans firefox "examiner l'élément"
dans chrome "inspecter".
Sélectionner "slides_container" (le nom de la structure qui contient votre texte et photos).
Dans firefox:
Dans chrome:

Dans safari, c'est pareil...

Vous voyez à droite "width" c'est la largeur de cette fenêtre.
Par défaut elle est à 320pixels.
Changer à 580px par exemple (vous voyez les changements en temps réel).
Vous pouvez aussi changer le left à 10pix...
Et top à 60pix sinon vous serez gêné par les boutons zoom de la carte.
Fermer cette fenêtre.
En outre il faut prévoir de mettre le centrage de la carte plus à droite lors de l'écriture de votre story map...

Hélas cette présentation/design est un fichier CSS stocké sur odyssey.js GitHub. Il faudra donc le faire à chaque fois!
Pour éviter de le faire à la main. Il faut télécharger le CSS d'odyssey.js et le modifier et l'insérer dans votre .html à la place de
dans ce fichier CSS: 
changer 320px à la valeur de 580px par exemple.
sauvegarder votre nouvel .html qui contient le CSS (en mode local).