Showing posts with label import. Show all posts
Showing posts with label import. Show all posts

Thursday, July 20, 2017

HUB text/PAO une syntaxe pour différentes cibles input et output (backends, targets ou writers), de manière à obtenir du HTML du LaTeX, page de man: pandoc


hexadécimal

Au départ si on a que du texte sans mise en forme, on peut écrire en hexadécimal comme dans ma jeunesse des années 70 (en ASCII ou étendue pour les caractères français par exemple). Il suffisait de connaitre par coeur la table ASCII de 128 correspondances qui est une norme informatique de codage de caractères des années 60. Et tout cela avec un clavier de 0-9 et A-F soit 16 touches (même pas une touche carriage return  car c'est le code #D ni même une touche espace car c'est #20)!
http://ascii.cl/
Et pour l'histoire:
https://fr.wikipedia.org/wiki/American_Standard_Code_for_Information_Interchange

C'était clair, il y avait celui qui tapait ses idées au kilomètre puis celui qui mettait en forme.

que du text mis en forme (et un peu de "PAO") et comparaison des softs

Si on a que text (par exemple ASCII ou UTF-8) c'est assez simple.
Avec du balisage léger et des transcodeurs, on a du Hub-text.
voir une liste partielle des output formats:
https://en.wikipedia.org/wiki/Lightweight_markup_language

https://en.wikipedia.org/wiki/Comparison_of_document_markup_languages

https://en.wikipedia.org/wiki/Comparison_of_documentation_generators
(and  programming languages).
example: ROBODoc is a documentation tool similar to Javadoc and licensed under the GPL. It is used to extract API documentation from source code. It can be used with any language that supports comments and works by extracting specially formatted headers. These are then reformatted into HTML, DocBook, TROFF, ASCII, LaTeX, PDF, or RTF.
It can be used to document any programming artifact, such as: classes, functions, tests, makefile entries, etc.
ROBODoc works with C, C++, Fortran, Perl, shell scripts, Assembler, DCL, DB/C, Tcl/Tk, Forth, Lisp, COBOL, Occam, Basic, HTML, Clarion, and any other language that supports comments.
https://en.wikipedia.org/wiki/ROBODoc


Une analyse que je partage

Comparaison des langages de balisage (markup) léger (lightweight) : Txt2tags, Pandoc, Docutils, AsciiDoc, Deplate, Stx2any, AFT, Markdown et Textile:
http://fgallaire.flext.net/comparaison-langage-balisage-markup-lightweight-leger-txt2tags-pandoc-docutils-asciidoc-deplate-stx2any-aft-markdown-textile/

La bureautique est la principale utilisation de l’informatique depuis sa création. Pourtant, les outils majoritairement utilisés dans ce domaine, les logiciels de traitement de texte WYSIWYG comme LibreOffice ou MS word, laissent la majorité des informaticiens et des ergonomes totalement désespérés.
Ces logiciels ont en effet un nombre de défauts très important : ils font se concentrer sur la forme et non sur le fond, leur résultat final ne correspond souvent pas à ce qui est affiché, ils sont incompatibles entre eux, ce sont d’énormes usines à gaz, ils ne fonctionnent qu’en mode graphique, etc.

Il a donc fallu penser à une manière de donner ces instructions de mise en forme au sein du fichier texte lui-même, et c’est ainsi que sont apparus les langages de balisage (markup), dont les plus connus sont HTML (inventé en 1991 par Tim Berners-Lee) et LaTeX (créé en 1985, et basé sur TeX, inventé par le grand Donald Knuth en 1977), et dont la première grande figure fut Roff, un programme Unix historique développé à partir de 1961, et dont la version GNU, Groff, est installée par défaut sur toutes les distributions GNU/Linux, puisqu’on l’utilise encore pour les pages de man des logiciels.

Ces langages représentent une nette amélioration, mais ont tous un gros problème : ils sont gênants ! On ne retrouve plus aussi facilement son contenu au milieu de toutes ces balises supplémentaires, sans parler du fait que les syntaxes complexes ouvrent la voie à de nombreuses erreurs de compilation.

C’est en 1995 que l’on trouva la solution de ce problème, avec la création du premier langage Wiki, dont le but principal était de permettre l’édition facile de pages web par tout un chacun, et dont l’utilisateur actuel le plus célèbre est l’encyclopédie libre Wikipédia. S’il y a presque autant de syntaxes différentes que de logiciels Wiki, elles ont toutes la caractéristique d’utiliser des caractères textuels simples et intuitifs pour donner les indications de formatage du texte.
http://www.wikicreole.org/wiki/Reasoning

https://www.mediawiki.org/wiki/Help:Formatting
https://fr.wikipedia.org/wiki/Aide:Syntaxe_(wikicode)
https://fr.wikipedia.org/wiki/Aide:Ins%C3%A9rer_un_tableau_(wikicode,_avanc%C3%A9)
https://fr.wikipedia.org/wiki/Mod%C3%A8le:BUtilisateur
https://www.mediawiki.org/wiki/MediaWiki/fr

J'ai toujours aimé le principe du "folding editor".
le premier fut STET  'STructured Editing Tool' de 1977
https://en.wikipedia.org/wiki/STET_(text_editor)
A folding editor is a text editor which supports text folding or code folding, a mechanism allowing the user to hide and reveal blocks of text—usually named. Typically this is done to allow the user to better picture the overall structure of a document or program.
Folding is provided by many modern text editors, and syntax-based or semantics-based folding is now a component of many software development environments...
https://en.wikipedia.org/wiki/Folding_editor


Mais pourquoi limiter ces langages de balisage léger à la seule génération de HTML ? Pourquoi ne pas utiliser la même syntaxe pour différentes cibles (appelées backends, targets ou writers selon les logiciels), de manière à obtenir aussi bien une page web en HTML, qu’un document en LaTeX pour l’impression, ou qu’une page de man pour un logiciel ? Ce sont les logiciels qui poursuivent ce but qui m’intéressent, ils constituent pour moi l’avenir de la bureautique informatique, et j’ai été amené à les comparer pour en choisir un dans lequel m’investir comme développeur.

Trois d’entre eux, Docutils, Deplate et Pandoc, ont un design évolué, avec une machine à états finis pour laquelle on peut écrire de nouveaux readers et writers de manière parfaitement propre. Cependant, malgré leurs grandes qualités, Deplate est un projet trop confidentiel (ainsi il n’est incompréhensiblement pas présent parmi les pourtant si nombreux paquets Debian), et je ne me sentais pas à la hauteur pour m’investir dans un projet comme Pandoc, totalement écrit en Haskell, qui est un langage de programmation complexe que j’aimerais beaucoup utiliser.
Je détaillerai Pandoc ci-dessous.

Txt2tags

J’ai rajouté dans ce comparatif Markdown et Textile, puisqu’ils ont chacun une implémentation en Python, mais ne générant que du HTML, ils ne m’intéressaient pas vraiment. AsciiDoc et Txt2tags ont un peu la même architecture, avec un gros fichier principal faisant tout le travail, que l’on peut configurer, respectivement avec un fichier .conf et deux dictionnaires Python (un pour les Tags et l’autre pour les Rules), pour créer de nouvelles cibles. AsciiDoc et Txt2tags sont donc plus aisés à prendre en main et à modifier rapidement que Docutils, qui est une très belle et très bien architecturée machine à états objet, mais aussi plus difficile à appréhender.
De plus, comme je désapprouvais totalement la politique de licence domaine publique de Docutils, il ne me restait plus qu’à faire mon choix entre Txt2tags et AsciiDoc. C’est principalement l’orientation très DocBook (un format ne m’intéressant personnellement pas du tout) d’AsciiDoc, et d’autres détails, comme la localisation en de nombreuses langues de Txt2tags et sa plus grande simplicité, qui m’ont finalement fait choisir Txt2tags.

Ce choix est confirmé par une étude plus avancée des différentes syntaxes. Ainsi alors que la syntaxe reST de Docutils ne dispose que de :

*italique* et **gras**

Txt2tags est beaucoup plus riche :

//italique// **gras** __souligné__ et --barré--

Le codage visuel est bien meilleur, et le compréhension instantanée avec la syntaxe de Txt2tags, puisque les slashs donnent l’impression penchée de l’italique, les étoiles imitent la surcharge du gras, les underscores donnent l’impression de soulignement, et les moins apparaissent comme une barre. De plus, l’utilisation généralisée des caractères de balisage en doubles, permet de lever à peu de frais un maximum d’ambiguïtés syntaxiques.

insertion d'une image est beaucoup plus simple Txt2tags
[[picture.png] http://fgallaire.flext.net]

Leur implémentation en Python permet à Txt2tags, reST (par Docutils) et AsciiDoc d’être utilisables à la fois comme logiciels de bureautique multiplateforme (Linux, Mac OS X, Windows et *BSD) et pour le web côté serveur. Depuis 2012, une implémentation de txt2tags en PHP est disponible, développée par Petko Yotov (le mainteneur et principal développeur de PmWiki) et sponsorisée par Eric Forgeot. Grâce aux nombreux efforts de ce dernier, il existe maintenant plusieurs implémentations de la syntaxe Txt2tags en JavaScript, avec une démo parfaitement fonctionnelle des possibilités de rendu côté client en temps réel. Et Matthew Pickering a quant à lui écrit un reader Txt2tags pour Pandoc.
En face, Markdown est représenté par une armada d’implémentations dans tous les langages utilisés sur le web côté serveur, et aussi en JavaScript côté client pour des prévisualisations efficaces sans Ajax, mais seul Pandoc, qui n’est pas si facile à compiler sur toutes les plateformes, propose autre chose qu’un rendu en HTML.
Je vais bien sûr continuer à travailler sur le logiciel Txt2tags, mais une implémentation de la syntaxe Txt2tags dans un parser Docutils, pour toucher directement toute la communauté des développeurs Python qui documentent leurs projets, et pouvoir bénéficier ensuite du sublime Sphinx, est un projet qui me motive de plus en plus.
Enfin, je suis toujours un peu nostalgique devant ce screenshot, parce que c’est en le voyant, avec en haut à gauche le fichier avec les balises, et en bas à droite celui avec le résultat texte brut, que j’ai pris conscience que Txt2tags faisait bien ce que j’espérais, et que comme en plus il était en Python, ce serait probablement le logiciel auquel j’allais contribuer !

Pandoc

Pandoc is a command-line tool. There is no graphic user interface. 
Pandoc is a Haskell library for converting from one markup format to another, and a command-line tool that uses this library. It can read Markdown, CommonMark, PHP Markdown Extra, GitHub-Flavored Markdown, MultiMarkdown, and (subsets of) Textile, reStructuredText, HTML, LaTeX, MediaWiki markup, TWiki markup, Haddock markup, OPML, Emacs Org mode, DocBook, Muse, txt2tags, Vimwiki, EPUB, ODT, and Word docx; and it can write plain text, Markdown, CommonMark, PHP Markdown Extra, GitHub-Flavored Markdown, MultiMarkdown, reStructuredText, XHTML, HTML5, LaTeX (including beamer slide shows), ConTeXt, RTF, OPML, DocBook, OpenDocument, ODT, Word docx, GNU Texinfo, MediaWiki markup, DokuWiki markup, ZimWiki markup, Haddock markup, EPUB (v2 or v3), FictionBook2, Textile, groff man, [groff ms], Emacs Org mode, AsciiDoc, InDesign ICML, TEI Simple, Muse and Slidy, Slideous, DZSlides, reveal.js or S5 HTML slide shows. It can also produce PDF output on systems where LaTeX, ConTeXt, pdfroff, or wkhtmltopdf is installed.
Pandoc's enhanced version of Markdown includes syntax for footnotes, tables, flexible ordered lists, definition lists, fenced code blocks, superscripts and subscripts, strikeout, metadata blocks, automatic tables of contents, embedded LaTeX math, citations, and [Markdown inside HTML block elements][Extension: markdown_in_html_blocks]. (These enhancements, described further under Pandoc's Markdown, can be disabled using the markdown_strict input or output format.)
In contrast to most existing tools for converting Markdown to HTML, which use regex substitutions, pandoc has a modular design: it consists of a set of readers, which parse text in a given format and produce a native representation of the document, and a set of writers, which convert this native representation into a target format. Thus, adding an input or output format requires only adding a reader or writer.
Because pandoc's intermediate representation of a document is less expressive than many of the formats it converts between, one should not expect perfect conversions between every format and every other. Pandoc attempts to preserve the structural elements of a document, but not formatting details such as margin size. And some document elements, such as complex tables, may not fit into pandoc's simple document model. While conversions from pandoc's Markdown to all formats aspire to be perfect, conversions from formats more expressive than pandoc's Markdown can be expected to be lossy.
This document is for people who are unfamiliar with command line tools. Command-line experts can go straight to the User’s Guide or the pandoc man page:

Modules 

In contrast to most existing tools for converting Markdown to HTML, pandoc has a modular design: it consists of a set of readers, which parse text in a given format and produce a native representation of the document, and a set of writers, which convert this native representation into a target format. Thus, adding an input or output format requires only adding a reader or writer.

Ref.

Pandoc’s enhanced version of Markdown 

Pandoc’s enhanced version of Markdown includes syntax for footnotes, tables, flexible ordered lists, definition lists, fenced code blocks, superscripts and subscripts, strikeout, metadata blocks, automatic tables of contents, embedded LaTeX math, citations, and Markdown inside HTML block elements. (These enhancements, described further under Pandoc’s Markdown, can be disabled using the markdown_strict input or output format.)

Tricks

you have a long markdown file in GitHub and want to have a TOC, you can use 
pandoc -t markdown_github --toc -o example-with-toc.md example.md

Using Markdown Templates

Math in Pure Markdown


Posted by at No comments:
Labels: , , , , , , , , , , , , , , , , , , ,

Thursday, December 8, 2016

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:
http://geojson.org/geojson-spec.html
GeoJSON (2008) is a geospatial data interchange format based on JavaScript Object Notation (JSON).
http://www.macwright.org/2015/03/23/geojson-second-bite.html

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 :
https://fr.wikipedia.org/wiki/Greenwich_(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.
https://fr.wikipedia.org/wiki/WGS_84

GeoJSON (ici minimaliste) pour un point situé sur Fourvière à Lyon:
{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "properties": {},
      "geometry": {
        "type": "Point",
        "coordinates": [
          4.8264312744140625,
          45.76581655469703
        ]
      }
    }
  ]
}
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  http://www.macwright.org/lonlat/
Posted by at No comments:
Labels: , , , , , , , , , , ,

Friday, December 2, 2016

Liste des serveurs de baseMap (tiles, tuillage et layers). Changer de baseMap (et la personnaliser) pour odyssey.js: mapbox.

Les tuiles:
puis les zooms:


La base:

En français:
http://openstreetmap.fr/blogs/cquest/visite-guidee

https://switch2osm.org/fr/les-basiques/

Servir des tuiles:
https://switch2osm.org/fr/servir-des-tuiles/utilisation-dune-solution-tout-en-un/

les serveurs:
http://wiki.openstreetmap.org/wiki/Tile_servers

Le format principal (pour X/Y/Z) est une URL de ce type:
'http://{s}.somedomain.com/blabla/{z}/{x}/{y}.png'
{s} means one of the available subdomains (used sequentially to help with browser parallel requests per domain limitation; subdomain values are specified in options; a, b or c by default, can be omitted), {z} — zoom level, {x} and {y} — tile coordinates.

tile server capable of providing map tiles in vector (pbf) or raster (png) formats, as well as static map snapshots of any size for a given location.

Une liste de serveurs
The maps project aims to build cartography technologies for all Wikimedia projects, at a scale sufficient for their widespread usage. 
https://www.mediawiki.org/wiki/Maps
https://www.mediawiki.org/wiki/Maps#/map/0
On peut comparer: Bing Maps, Google Maps, OpenStreetMap,ACME Mapper,Apple Maps,HERE, MapQuest,Waze, Wikimapia, WikiMiniAtlas, Yandex.Maps.
http://tile.openstreetmap.fr/?q=yssingeaux
http://mapper.acme.com/?ll=45.142316,4.123694&z=10&t=M&marker0=45.142316,4.123694,Maps

Serveurs

On a de nombreux serveurs de baseMap:
http://wiki.openstreetmap.org/wiki/Tiles

Il faut comprendre qq différence avec "tileset":
A "tileset" typically includes enough tiles to form a very large image, if they were shown all at once, and also several zoom levels. Generally the idea is not to show them all at once, but to display a particular area of the map on a website. Normally this is done using a JavaScript map library to provide panning and zooming functionality, and request downloading of new tiles as necessary to show the user new areas of the map (a Slippy Map). (http://wiki.openstreetmap.org/wiki/Slippy_Map)

Changer de baseMap pour odyssey.js

On a de nombreux serveurs de baseMap:
http://wiki.openstreetmap.org/wiki/Tiles

On a 3 choix dans le sandbox d'odyssey: nokia est la moins mauvaise...
c'est l'ensemble des choix par défaut dans cartoDB editor free:
  • https://cartocdn_a.global.ssl.fastly.net/base-light/{z}/{x}/{y}.png
    qui est vraiment très light!! mais "unlimited use permitted" et en lien avec OpenStreetMap.
  • une autre du provider Stamen: http://{s}.tile.stamen.com/watercolor/{z}/{x}/{y}.jpg
    essayez (chargement lent):
    http://tile.stamen.com/terrain/{z}/{x}/{y}.jpg
    http://maps.stamen.com/#terrain/12/37.7706/-122.3782
  • une autre du provider ex-nokia, maintenant HERE ("nokia day"):
    https://2.maps.nlp.nokia.com/maptile/2.1/maptile/newest/normal.day/{z}/{x}/{y}/256/png8?lg=eng&token=A7tBPacePg9Mj_zghvKt9Q&app_id=KuYppsdXZznpffJsKT24
    (vendu en 2015): https://wego.here.com; https://fr.wikipedia.org/wiki/HERE_WeGo
    essayer le mode hybrid:
    "https://2.maps.nlp.nokia.com/maptile/2.1/maptile/newest/hybrid.day/{z}/{x}/{y}/256/png8?lg=eng&token=A7tBPacePg9Mj_zghvKt9Q&app_id=KuYppsdXZznpffJsKT24"
Rem:'http://{s}.somedomain.com/blabla/{z}/{x}/{y}.png'
{s} means one of the available subdomains (used sequentially to help with browser parallel requests per domain limitation; subdomain values are specified in options; a, b or c by default, can be omitted), {z} — zoom level, {x} and {y} — tile coordinates.
Ref: http://leafletjs.com/reference.html#popup

https://developer.here.com/rest-apis/documentation/enterprise-map-tile/
https://developer.here.com/rest-apis/documentation/enterprise-map-tile/topics/example-hybrid-map.html

vous pouvez aussi copier/coller celles-ci de cartoDB:
http://a.basemaps.cartocdn.com/light_all/{z}/{x}/{y}.png
http://a.basemaps.cartocdn.com/dark_all/{z}/{x}/{y}.png

le plus important est de bien choisir en fonction de ses besoins.
Personnellement je préfère openstreetmap car très complète:
http://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png
et aussi une carte "france" :  http://{s}.tile.openstreetmap.fr/osmfr/{z}/{x}/{y}.png
http://wiki.openstreetmap.org/wiki/FR:Servers/tile.openstreetmap.fr
voir les choix:
http://leaflet-extras.github.io/leaflet-providers/preview/

Il faut comprendre qq différence avec "tileset":
A "tileset" typically includes enough tiles to form a very large image, if they were shown all at once, and also several zoom levels. Generally the idea is not to show them all at once, but to display a particular area of the map on a website. Normally this is done using a JavaScript map library to provide panning and zooming functionality, and request downloading of new tiles as necessary to show the user new areas of the map (a Slippy Map). (http://wiki.openstreetmap.org/wiki/Slippy_Map)

Faire sa basemap personnalisée avec MapBox utilisable par odyssey.js

On peut utiliser le provider mapbox (https://www.mapbox.com) mais attention au mélange:
Mapbox is a service which lets you customize the design of a basemap with custom colors and elements. Insert your Mapbox URL and access token to add the basemap
Note: CARTO only supports Mapbox classic urls. If you enter a new Mapbox Studio url, an error appears.
En premier, avec odyssey.js, on peut utiliser les baseMaps styles de base de mapBox comme la "mapbox.streets":
https://api.mapbox.com/v4/mapbox.streets/{z}/{x}/{y}.png?access_token=your_token
voir: https://carto.com/location-data-services/basemaps/
https://carto.com/docs/carto-editor/maps/#basemaps

On a deux choix:

  • soit avec les superbes outils javascript de MapBox
  • soit avec MapBox Studio.

Je vais traiter du cas avec "MapBox Studio" (et en lien avec la doc/exemple javascript).
MapBox n'est pas facile à comprendre au début.
C'est un processus linéaire :
                                            datasets->tilesets->Styles
                                            en fait (GeoJSON data->layer vectorielle->carte multicouche).

  1. Il faut se créer un compte et on obtient une clé (token).
    Il faut savoir que c'est construit "on top of Leaflet" http://leafletjs.com/
    ->plus de renseignement: GitHub: https://github.com/mapbox/mapbox.js/
  2. importer un dataset (voir point 3). Juste une explication: c'est fondée sur les fonctions import/export liées au Leaflet-Omnivore plug-in
    https://api.mapbox.com/mapbox.js/plugins/leaflet-omnivore/v0.2.0/leaflet-omnivore.min.js. qq exemples:
  3. avec MapBox Studio, il suffit de faire "new datasets", soit on le créée soit on l'upload, avec ces deux choix (tester son fichier avec geojson.io, avant):
    • GeoJSON 
    •  CSV file
  4. on click sur datasets (à gauche) puis "edit", on peut voir son fichier sur une carte et aussi en un click sur un point (ou plusieurs points) l'ensemble des données associés.
    On peut ajouter une droite, un polygone, un point... Si on revient sur dataset, on peut sauvegarder en geoJSON son oeuvre modifiée.
  5. exporter vers "tilesets"
  6. dans tilesets, on peut voir la nature de cette "carte", par exemple: "This layer contains mostly Points". On a le numero "mapId" le format "pbf" vector et sa taille. C'est en fait une vector layer (générée à partir de l'ensemble des données GeoJSON). De plus on peut suivre les stats de visualisation de sa carte.
    Avec un compte gratuit: 50 000 map views/mois ou 50 000 mobile users/mois (en décembre 2016); 600 geocode requests/minute, 5 GB tileset storage, 250 MB dataset storage, 20 Mapbox Studio styles. Cet ensemble de limite est le principal défaut de l'hébergement/usage sur mapBox. Sinon on a accès à tout le reste  (Geocoding,  Satellite & street maps, full Mapbox Studio, Directions, les librairies javascripts).
    A map view is 
    • four map tiles when using Mapbox Studio styles, or 
    • 15 smaller map tiles when using Mapbox Studio Classic or Mapbox Editor Classic. 
    • One Static API request also counts as one map view.
  7. faire "add to style". Vous avez enfin votre solution où vous pouvez tout personnaliser.vous avez le lien vers ce style de type:
    https://www.mapbox.com/studio/styles/username/mapId/
    avec votre username et votre mapid.
    Si vous avez choisi la base: "Mapbox Streets V7 + Vector Terrain V2(Composite source)"
    vous aurez un très grand choix des layers (à afficher ou non). Pour l'instant allons dans le symbol "menu" juste à droite du bouton "edit" et sélectionner "share". 
  8. Les 4 choix du sharing/partage:
    1. faire un lien (URL) .html (la carte est déplaçable, zoomable et on a la rotation du plan)
      par contre on a un gros logo en haut à droite pas beau...
    2. "Develop with this style"
      1. mapbox: pour utiliser avec leur librairie javascript; voir exemple:
        https://www.mapbox.com/mapbox-gl-js/example/setstyle/
        Cet exemple permet aussi de comparer les styles de base de mapbox.
      2. leaflet:
        https://api.mapbox.com/styles/v1/stef4250/ciw6uszpd000e2pmkuzzzqlln/tiles/256/{z}/{x}/{y}?access_token=XXmyTokenXX
        C'est cette URL de tuiles qu'il faut utiliser pour odyssey.jspour avoir une carte personnalisée (et avec un import/export interopérable)
        http://leafletjs.com/reference.html#tilelayer
        Voir les nombreuse options...
        Used to load and display tile layers on the map, implements ILayer interface:
        L.tileLayer('http://{s}.tile.osm.org/{z}/{x}/{y}.png?{foo}', {foo: 'bar'}).addTo(map);
        dans odyssey.js:
        var baseurl = this.baseurl = 'http://{s}.api.cartocdn.com/base-light/{z}/{x}/{y}.png';
        var         basemap = this.basemap = L.tileLayer(baseurl, { attribution: 'data OSM - map CartoDB'}).addTo(map);
        Rem: C'est ici qu'est inséré    comme attribution le string  'data OSM - map CartoDB'
      3. on peut personnaliser ses "points"
        • Title                    Eglise
        • marker-color       #7e7e7e
        • marker-size         medium
        • marker-symbol  village

Add your map style as a layer in ArcGIS and QGIS with WMTS:
https://www.mapbox.com/help/mapbox-arcgis-qgis/

Outils

Faire son tuillage

On peut aussi faire son propre tiling:

outils de conversion entre le format X/Y/Z et TMS

Il existe des outils de conversion entre le format X/Y/Z et TMS:
The difference between XYZ and TMS tiles and how to convert between them

ajout de layers

Par exemple avec google fusion:

design a specific layer-basemap

Most web maps are made up of many small, square images called tiles. These tiles are typically 256×256 pixels and are placed side-by-side in order to create the illusion of a very large seamless image. There are several different tiling schemes, but among the most popular is the standard XYZ tile scheme, used by Google, OpenStreetMap, CARTO, Mapbox, and others. Tile images are are served through a REST API with a URL like http://.../Z/X/Y.png, where Z is the zoom level, and X and Y identify the tile.
Mapbox now supports directly accessing raster tile endpoints for Mapbox studio styles. This means you can design custom maps in Mapbox Studio and access them directly in Fulcrum!
From the Styles page in Mapbox Studio, click on either a Mapbox style or one of your own custom styles.
Scroll down the style page until you see the “Use style in GIS apps” section and click on the CARTO tab (Fulcrum uses the same scheme as CARTO).
Copy the Integration URL and proceed with adding the map layer to Fulcrum.


----------

Posted by at No comments:
Labels: , , , , , , , , , , , , , , , , ,

Friday, November 18, 2016

INTEROPERABILITE des STORY MAPS et odyssey.js (et Flickr)

INTEROPERABILITE des STORY MAPS

Lorsque l’on réalise une « narrative story map » une histoire/ballade cartographie narrative, le plus long consiste à écrire du texte de qualité et référencé. 
Il faut pouvoir sauvegarder ce texte (avec ou sans mise en forme) et sa story map narrative d’un bloc . 

J'ai réalisé plusieurs post sur les story maps (voir le tag "GPS" ou "map" de ce blog) y compris une synthèse des divers stratégies. Ici c'est mon choix actuel dans la perspective de l'interopérabilité de ce long travail d'écriture et de collecte des médias.

odyssey.js,

Avec odyssey.js, (https://cartodb.github.io/odyssey.js/) nous pouvons mettre en forme le fichier markdown avec un éditeur de texte comme notepad++ , textedit  BBEedit avec extension markdown (ou d’autres logiciels markdown, voir tag de ce blog « markdown »voir MS word ou google doc… On peut utiliser du HTML pour mettre en forme du texte de manière plus poussée. Voir aussi mes autres posts plus détaillés sur ce javascript et les web services associés (tag "GPS" ou "map" ou "markdown" de ce blog).
Je rappelle ici que markdown est un langage simple pour écrire du texte alors que HTM est un langage à balise plus compliqué (et plus lourd)  fait pour la visualisation.
Pour insérer les données Latitude,Longitude et les URL des images, il faut mettre en forme avant l’écriture du fichier markdown.
Plutôt que du copier/coller pour chaque URL image/video (son seul est un cas particulier) et chaque marqueur Lat,Long, il faut au préalable télécharger par batch des lots d’images qui gère le géo-taggage.
Pour cela plusieurs possibilités:

batch des lots d’images qui gère le géo-taggage

1/Créer un blogspot privé où vous incorporez/télécharger vos images. Puis dans l’HTML, récupérer la liste des URL et filtrez le fichier avec MS word excel ou google doc ou sheet par exemple (sauvegarder aussi en .CSV). 

Je pense que l’on peut aussi le faire avec Flickr qui permet de vérifier la géo-localisation via l’affichage d’une carte de ces photos…
Mais il ne peut le faire directement.
Il faut passer par la fonction API flickr.photosets.getPhotos de l’API Flickr:
on peut récupérer les "id" de toutes les photos d'un album (set en anglais)  (500 photos max dans un album) dans un fichier simple qui est de 4 types possibles:
  •  XML (XML-RPC; http://xmlrpc.scripting.com/  )
  •  JSONP  (JavaScript Object Notation, est un format simple d'échange de données assimilable par l'ordinateur, qui facilite l'élaboration d'applications en JavaScript avec l'API  json.org )
  •  JSON
  •  PHP Serial (fichier .mdlp)

https://www.flickr.com/services/api/flickr.photosets.getPhotos.html
un clic en bas sur Explorateur API : flickr.photosets.getPhotos
donne ceci:

Que la liste de toutes les Id des photos, de leur titre, ici en XML (à partir du propriétaire_id 144398584@N07: et du photoset_id 72157676525638806: 
<rsp stat="ok">
  <photoset id="72157676525638806" primary="25373090639" owner="144398584@N07" ownername="stef42530" page="1" per_page="500" perpage="500" pages="1" total="6" title="velay-test1">
    <photo id="25373090639" secret="xxxxx" server="5344" farm="6" title="yssingeaux" isprimary="1" ispublic="1" isfriend="0" isfamily="0" />
    <photo id="22808772578" secret="xxxx" server="5815" farm="6" title="fontaine" isprimary="0" ispublic="1" isfriend="0" isfamily="0" />
    <photo id="30973507366" secret="xxxx" server="5347" farm="6" title="statue Marie" isprimary="0" ispublic="1" isfriend="0" isfamily="0" />
    <photo id="30707294970" secret="xxx" server="5653" farm="6" title="la croix de mission" isprimary="0" ispublic="1" isfriend="0" isfamily="0" />
    <photo id="30870710272" secret="xx" server="5498" farm="6" title="communauté pays des sucs" isprimary="0" ispublic="1" isfriend="0" isfamily="0" />
    <photo id="30973523796" secret="xx" server="5483" farm="6" title="eglise de champclause-nonReduit" isprimary="0" ispublic="1" isfriend="0" isfamily="0" />
  </photoset>
</rsp>
On a bien les 6 photos.

Et les URL et les Lat,Long des photos d'un album?

A partir de cette liste des photo_id, avoir les URL c'est simple (voir ci-dessous  flickr.photos.getInfo).
www.flickr.com/photos/144398584@N07/25373090639/

Pour les données de Lat,Long et avec  flickr.photos.geo.getLocation ce n’est que par une seule photo:
https://www.flickr.com/services/api/explore/flickr.photos.geo.getLocation
photo par photo. Donne aussi les Place_id et woeid (nom ville, région, pays; voir ci-dessous):

https://www.flickr.com/services/api/explore/flickr.photos.getInfo
idem photo par photo via une Id de photo.
On a dans un même fichier les données géo et l'URL. 
On peut donc le traiter facilement pour le mettre dans un fichier excel.
Ce fichier text retourne Lat, Long et aussi URL complète avec aussi 
le nom de l' Id propriétaire (ici 144398584@N07) et Id photo (25373090639):

<url type="photopage">https://www.flickr.com/photos/144398584@N07/25373090639/</url>


pour les données géo:


<location latitude="45.142316" longitude="4.123694" accuracy="16" context="0" place_id="2357Wa9XUbm_ZCg" woeid="633062">
      <locality place_id="2357Wa9XUbm_ZCg" woeid="633062">Yssingeaux</locality>
      <county place_id=".z9.tGJQUL8BHZ7KeQ" woeid="12597130">Haute-Loire</county>
      <region place_id="6VHmZr5WU7.XrIHq" woeid="7153310">Auvergne</region>
      <country place_id="lbWye9tTUb6GOcp80w" woeid="23424819">France</country>
    </location>











Pour les données EXIF complètes hélas d’une seule photo, on peut utiliser:



https://www.flickr.com/services/api/explore/flickr.photos.getExif



Sinon pour une manipulation des URL flickr et affichage d'un album en défilement, voir mon petit code javascript:

http://jsdo.it/ex-ample.blogspot/uLfn/edit





voir aussi:

http://stephane-mottin.blogspot.fr/2016/11/flickr-api-geo-tag-javascript-and-github.html





Pour les données Lat,Long de nombreuses photos: on peut aussi utiliser des outils de conversion des données EXIF par lots: voir d’autres post de ce blog (tag EXIF ou GPS).







Les édtiteurs web



2/On peut utiliser ArcGis story journal (ou cascade) qui incorpore les images géo-taggées par lot via flickr  (ou google picasa (fonctionne pas bien en cette fin 2016) ou via un t-fichier tableur .CSV. Générez la story map sans mettre du texte un par un. Cette méthode permet de ne pas gérer directement les URL et les (Lat,Long), le builder s’en occupe.











Conclusion



Bref, avec cette solution odyssey.js, le plus important est que l’on peut sauvegarder directement son travail sous deux formes:



a/ le fichier markdown (.md et bien sur son transcodage .HTML avec par exemple un « Rich Text Editeur »)



b/ le site web (et son javascript) hébergé.







c) une troisième  si on utilise les builders d’ARcGIS online de story map.



Rem: votre fichier markdown peut aussi être traité pour extraire le texte de chaque image pour le mettre dans ce .CSV. Puis on peut refaire une nouvelle story map avec ces ArcGIS builders avec le texte via ce .CSV.



On a alors un troisième format «  site web » de votre story map sous cette forme de site intégré ArcGIS hébergé.



d) de plus vous aurez aussi un quatrième format de fichier de sauvegarde de votre story map en .CSV complet…





































































Posted by



at





No comments:
  


















Labels:
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,
,

















        

      









Subscribe to:
Posts (Atom)