Cette page contient les discussions autour de l’article Wikipédia:Atelier graphique qui ont eu lieu entre le 05/01/2013 et le 18/01/2014. Pour intervenir sur les discussions actuelles ou pour en lancer une nouvelle, allez sur la page Discussion Wikipédia:Atelier graphique.
Parce que je tombe trop souvent sur des fichiers pas du tout optimisé sur Commons, j’ai commencé quelques pages sur la Wikiversité : v:Optimiser un fichier SVG. Pour l’instant c’est encore complètement en chantier (y compris dans ma tête).
Du coup, si quelques wikigraphistes avait le temps d’y jetter un coup d’œil. Je suis preneur de toute proposition, critiques, commentaires, etc. (j’ai surement pas été clair sur pleins de points et je ne suis pas sur de savoir dans quel(s) direction(s) continuer donc n’hésitez pas à sortir tout ce qui vous passe par la tête).
Salut ! Quelle bonne idée ! Quel sera le plan de la leçon ? Personnellement, je vois plusieurs gradation d'optimisation du plus basique au plus complexe :
Suppression de ce qui est inutile (dégradés non utilisés,...),
Suppression de ce qui est invisible (points redondants, objets en dehors du cadre,...)
Simplification des groupes (diminuer le nombre de groupes enchâssés,...)
Simplification des objets (utiliser des vraies formes géométriques (l'ellipse, le rectangle,...) sans les transformer en chemin (idem pour le texte).)
Simplification des objets complexes (diminuer le nombre de points : point inutile au milieu d'une droite, segment caché,...)
Diminution du nombre d'objet (Combinaison de segments aux caractéristiques identiques en un même objet, utilisation de la duplication d'objets pour des objets parfaitement identiques,...)
Suppression du code inutile (tout le code rajouté par Inkscape par exemple).
Et j'en oublie certainement encore. Peut-être qu'un petit paragraphe sur les différents formats du SVG serait le bienvenu aussi (quand utiliser le format SimpleSVG ? à quoi sert le format Inkscape SVG ?...)
Pour le plan, voir ce qui existe déjà sur v:Optimiser un fichier SVG. Mais c’est carrément modifiable, vu que cela ne me semble pas optimal.
Ton organisation est intéressante (et je n’avais même pas pensé à ton 5e point).
Pour les différents formats du SVG, malheureusement je ne connais bien que le « vrai » SVG (celui qu’Inkscape appelle « simple ») qui possède une tonne de documentation ; la plupart des enrichissements Inkscape/Sodipode ne sont expliqués nulle part (ou alors je ne les ai pas trouvé). Je viens tout de même ajouter une section sur le sujet dans le premier chapitre « v:Optimiser_un_fichier_SVG/Généralités ».
Je viens d'apprendre que : « Si vous avez créé une forme avec une icône (par exemple, une étoile ou un polygone avec ), Inkscape crée un objet lourd. On peut alléger la forme en convertissant l’objet en chemin (Menu Chemin, Objet en chemin, raccourci clavier : Maj+Ctrl+C) »
Et la je tombe de haut, parce que je pensais justement que c'était l'inverse. À la lecture des fichiers XML d'un carré ou d'un carré transformé en chemin, ce n'est vraiment pas évident à déterminer. Es-tu sûr que pour des formes complexes (genre étoile à 9 branches), la forme initiale n'est pas plus simple que la forme transformée en chemin ? C'est vraiment contre-intuitif.
Je ne me souvenais même plus d’avoir écrit cette phrase. En fait, je crois que c’est toujours vrai pour l’icône . Pour les autres icônes/formes, c’est plus variable (et cela dépend notamment de l’humeur d’Inkscape pour décrire le chemin).
Défini « complexe » Plus sérieusement, tout ce que l’on peut faire en SVG Inkscape, on peut le rendre en SVG simple (par contre, la réédition peut être difficile). Donc je dirais non. Cdlt, Vigneron * discut.6 janvier 2013 à 19:30 (CET)
Merci pour l’information, je ne connaissais pas cet outil (j’ai entendu parler de Scour, je vais regarder de plus près). Il faudrait que je regarde de plus près. Après, le but c’est aussi que les graphistes dessinent directement de façon optimale (sans qu’il y ai besoin de faire faire un nettoyage ensuite). Cdlt, Vigneron * discut.25 février 2013 à 17:09 (CET)
Cela commence mal, impossible de l’installer sur mon ordinateur… (ni avec la logithèque d’Ubuntu ni avec un apt-get qui me crache tout un tas d’erreurs). Cdlt, Vigneron * discut.26 février 2013 à 17:28 (CET)
Quelqu'un pourrait-il m'aider ?
Je souhaite créer des cartes pour effectuer des géolocalisations, notamment dans des infobox. Mais j'avoue être plutôt perdu dans toutes les informations de l'atelier graphique et l'ensemble des didacticiels. Je pense sélectionner une carte sur OSM et faire ensuite un traitement avec je ne sais pas quel logiciel. Pourriez-vous m'aider ? --Berdea (d) 11 janvier 2013 à 01:51 (CET)
Il y a des feuilles de style qui permettent au logiciel QGIS d'appliquer d'un seul coup un ensemble de styles conventionnels wikipédiens aux données OSM (voir didacticiel dédié à QGIS). Attention, selon la région concernée, ces données OSM sont sous forme d'un fichier à télécharger qui est parfois très lourd à traiter par l'ordinateur : il faut donc, le cas échéant, une machine assez puissante. — Sinon une autre solution, plus facile mais très moche je trouve, est de faire une copie d'écran du site osm et basta ;-) Bourrichon11 janvier 2013 à 23:20 (CET)
Il y a plusieurs solutions selon ce que tu as besoin de faire. Si tu veux faire de la vrai cartographie, QGIS est probablement ce qu’il y a de mieux (je dis probablement parce que je n’ai jamais réussi à me dépatouillé correctement et facilement de ce logiciel). Sinon, tu peux plus simplement utiliser les logiciels Inkscape (en vectoriel, SVG) voire GIMP (en matriciel, PNG ; plus léger mais pas idéal) à partir d’export OSM (par contre, plutôt de faire une copie d’écran, autant utiliser la fonction exporter qui permet de sélectionner précisément : les coordonnées, le format SVG ou PNG, et l’échelle ; cela sera utile pour la géolocalisation ;) ).
Bref, pourrais-tu préciser ce dont tu as besoin précisément ? (éventuellement, cela pourra nous servir pour écrire un didacticiel .
Commençons par deux usages que je vois immédiatement :
1/ Je prends par exemple une île et je veux faire un article sur un village ou un édifice de l'île. J'utilise une infobox avec un paramètre de localisation (latitude et longitude) et veux pourvoir localiser le lieu sur la carte. Je peux choisir une carte sur OSM et l'exporter (en quel format ?). Comment ensuite la rendre utilisable pour la géolocalisation ?
2/ Autre exemple. Disons par exemple que je travaille sur un article sur la poche de Lorient. Je veux faire une carte de la zone et représenter la ligne de front. Je peux toujours récupérer un fond de carte sur OSM et représenter la ligne de front en la dessinant avec des outils permettant de le faire. Comment faire ? Gimp est-il l'outil Opensource idéal pour faire cela ?
Bonjour Berdea. 1/ J'ai fait un brouillon de didacticiel à ce sujet. N'hésite pas à m'en faire un retour.
2/ Gimp: tu obtiendras une image matricielle, ardue à modifier sans rien casser. Inkscape: tu obtiendras une image matricielle encapsulée dans un SVG, et tu pourras y superposer des infos vectorielles (donc modifiables aisément). --Flappiefh (d) 24 février 2013 à 20:37 (CET)
Merci pour ta réponse rapide. Ton didacticiel est fort intéressant quoiqu'un peu complexe. Je vais essayé et reviendrai vers toi. --Berdea (d) 26 février 2013 à 01:06 (CET)
Unification des différents projets Carto et Géolocalisation
Bonjour à tous. En souhaitant créer un didacticiel hyper-accessible pour que les demandeurs géolocalisent eux-même les images que nous leur confectionnons, je m'aperçois qu'il existe quatre sections qui se marchent plus ou moins sur les pieds :
Ainsi, si l'on veut demander de l'aide pour géolocaliser une image, on peut le faire ici ou là, ou encore par là. Et si l'on a besoin de conseils pour la carto, on peut discuter ici-même, ou là. Bref, pour le profane qui cherche à se renseigner, ou pour le wikigraphiste que je suis, ce n'est pas évident.
J'ai envie de simplifier tout ça, sans rien détruire, mais vu que ça concerne un paquet de projets, de pages et de wikipédiens, il faut de bonnes idées et un consensus.
Après un tel inventaire, je me suis demandé pendant quelques minutes dans quelle page de discussion j'allais annoncer mon intention. Je l'ai fait ici parce que c'est la page où, je crois, on croise le plus de monde. Toutefois, j'ai mis un lien vers cette discussion dans les autres pages de discussion susnommées.
J'ai cru comprendre d'où vient le problème : il manque un Atelier Géolocalisation pour contenir les demandes adressées ici et là. Voici une proposition :
Franchement tu n'aurais pas pu faire des flèches entièrement vertes ? À part ça bravo pour ton activité sur l'atelier. Pour la fusion, ne pourrait-on pas plus simplement avoir :
une page de discussion commune à tous les projets ;
Une page de discussion commune à tous les projets -> je suis d'accord, mais il semble que nos collègues géolocaliseurs ont une PDD bien à eux et une autre dédiée aux demandes.
Une page de demande par projet -> c'est pourquoi je propose la création d'un Atelier Géolocalisation. Sa PDD pourrait éventuellement renvoyer vers la PDD de l'Atelier Graphique.
(conflit d'édit) Je sais pas trop, j'ai du mal à me faire un avis... Pour moi, ce sont effectivement deux choses séparées ; d'ailleurs la géolocalisation ne m'intéresse pas, car je n'y comprends pas grand-chose — ou l'inverse. Donc plutôt d'accord avec la proposition d'Atelier Cartographique (autrement nommé Flappieh, mais vu qu'en ce moment y a que lui qui bosse... ) : créer un atelier géolocalisation.
Le seul problème, c'est que la géolocalisation est quand même très fortement liée aux cartes... Et souvent, le demandeur veut à la fois une carte et sa géolocalisation.
Concernant les projets, sont-ils actifs ? Pour moi, les seules pages vraiment actives sont celles de l'AG.
Par contre, à propos de la fusion des pages de discussions, je rappelle que celle de l'atelier carto a déjà fusionné avec celle des images à améliorer, et avec celle de l'AG où nous nous trouvons actuellement. Ça me paraît pas mal de garder ça. Mais je ne vois pas la pdd de l'atelier géolocalisation fusionner avec l'AG, car ce n'est pas un atelier graphique à proprement parler.
Je suis d'accord pour bien séparer la Géoloc de la Carto. Et je pense que la majorité des géolocaliseurs sont du même avis (hélas, ils ne se pressent pas pour en discuter ici). Pour ton inquiétude au sujet des demandeurs perdus, j'ai fait un brouillon du possible Atelier Géoloc avec un entête clair, et une redirection de PDD vers la PDD du Projet:Géolocalisation. Qu'en pensez-vous ? --Flappiefh (d) 21 janvier 2013 à 19:16 (CET)
J'en pense que c'est pas mal. Et de la même manière sur l'atelier carto, à côté du bouton « Créer ou améliorer une carte géographique », on pourra ajouter un bouton « Demander une géolocalisation ».
C'est pas mal ce brouillon ! Un formulaire adapté aux demandes de géolocalisation s'impose ! Et on peut aussi demander gentiment à Orlodrim (d · c · b) pour que son bot archive les demandes de la même manière que sur les ateliers graphiques. Par contre, créer un projet supplémentaire, cela ne risque-t-il pas de perdre encore un peu plus les demandeurs (à moins de fusionner les projets pré-existant). Cordialement. --M0tty[Plaidoyers et jérémiades]21 janvier 2013 à 21:54 (CET)
Oui, c'est ce que j'ai oublié d'écrire : au final, avoir deux ateliers car les travaux à faire sont différents, mais fusionner les projets en un seul, car les domaines sont suffisamment proches pour ça. Et ça réduirait le nombre de pages. Mais il serait bien aussi d'avoir l'avis de participants au projet Géolocalisation ! Sémhur (d) 21 janvier 2013 à 22:02 (CET)
C'est là le problème : à une époque, Géolocalisation était une sous-branche du Projet:Cartographie. Puis il y a eu scission. Voici un résumé d'après les historiques :
Projet:Cartographie (8 décembre 2004, Guil)
Aide:Géolocalisation (24 décembre 2006, STyx)
Projet:Cartographie/Géolocalisation et sa PDD qui tient lieu d'atelier n°1 (13 février 2007, STyx)
Discussion aide:Géolocalisation (Aide avancée) (6 mai 2010, STyx)
Projet:Géolocalisation et sa PDD qui tient lieu d'atelier n°2 (25 mai 2011, Ludo29)
Donc pour résumer : c'était pas simple mais à peu près uni avant mai 2011. Je vais demander à Ludo29 si il avait connaissance de Projet:Cartographie/Géolocalisation quand il a créé Projet:Géolocalisation. --Flappiefh (d) 21 janvier 2013 à 23:33 (CET)
En mai 2011, en créant le projet:géolocalisation, j'avais connaissance de l'existence du projet Cartographie. J'ai créé ce projet pour remplir un manque : trouver un endroit pour savoir ce qu'il y a à faire dans la localisation des articles. J'ai été pas mal catalyseur de main d'oeuvre pour ce projet à ces débuts, j'ai été occupé à autres choses ces derniers temps.
Sur le principe d'avoir créé ce projet alors que Projet:Cartographie/Géolocalisation existait et sur le principe de faire une fusion ; je n'en comprends même pas trop le sens. Nous avons deux projets dont la finalité est différente :
l'un créé des cartes (géolocalisable ou non) ;
l'autre géolocalise des articles avec ou sans cartes internes.
Nous avons là deux activités différentes. Pour ma part, je n'ai jamais vraiment eu le temps, l'envie et les compétences pour m'investir dans la cartographie. La géolocalisation me passionne beaucoup plus.
Bref, je ne comprends pas vraiment le sens d'une fusion. Avec cette logique, pourquoi ne pas tout fusionner dans projet:Infobox ? Certaines cartes vont dans les infobox, la géolocalisation est souvent concernée par les infoboxs. LudoBureau des réclamations22 janvier 2013 à 08:25 (CET)
Merci pour cet éclairage. Je crois que j'ai saisi : à la base, le Projet:Cartographie/Géolocalisation est sensé créer les modèles de géoloc, tandis que le projet:géolocalisation utilise ces modèles pour géolocaliser des articles sous la forme d'infobox. J'ai bon ? Le problème, c'est que le nom de ces deux projets sont très proches, donc les gens ne savent pas forcément où effectuer leurs demandes. Je me suis moi-même trompé plusieurs fois. Ton idée (ironique ?) de fusionner le Projet:Géolocalisation avec le Projet:Infobox n'est pas bête, mais votre projet consiste à paramétrer des infobox, pas à les créer. --Flappiefh (d) 22 janvier 2013 à 18:04 (CET)
Oui, il y avait une pointe d'ironie. .
Plus sérieusement, je me parfois heurté à des contributeurs qui - tout en voyant d'un oeil positif la localisation dans l'espace de leurs articles - étaient très opposés à ce que cela apparaisse sur une carte dans une infobox. De même tous les articles ne sont pas dotés d'infobox, il m'est arrivé de géolocaliser des articles sans infobox. Donc, géolocalisation ne signifie pas forcément modèle de géolocalisation dans infobox.
Selon ma perception, vous faites un travail utile et énorme en créant ces cartes géolocalisables pour les infobox. J'apprécie vraiment que certains le fassent, alors que je ne le fais pas. Mais il s'agit d'un travail différent de ce que le projet géolocalisation propose. Ce projet ; son idée de base est détecter les articles dépourvus d'information géographique alors qu'ils pourraient en avoir et de combler ce manque. Ainsi, la cartographie et la géolocalisation sont deux travaux complémentaires sans être identiques.
Oui, j'ai bien compris pour ma part. Comme je le résumais : les activités sont différentes, mais le nom des projets est similaire, d'où l'embrouillamini. Voici ce que je propose pour faire avancer le schmilblick :
EDIT : amélioré depuis et mis à jour, voir plus bas.
Ça ne résoudrait pas le problème d'homonymie, mais ça permettrait aux demandeurs de modèles de géoloc de ne pas se tromper. On pourrait aussi appeler le nouvel atelier "Atelier Modèle de géolocalisation" --Flappiefh (d) 22 janvier 2013 à 19:45 (CET)
J'aurais besoin d'une précision. On fait quoi avec le demandeur d'une géoloc pour un territoire qui n'est pas cartographié? On l'envoie d'abord à l'atelier carto pour une carte géolocalisable et quand elle sera prête, il fait une demande à l'atelier géoloc pour qu'on bidouille le code ou une seule demande règle toute l'affaire? — Bouchecl (dring) 22 janvier 2013 à 19:58 (CET)
Je comprends mieux, mais à mon avis ton schéma peut être simplifié. Il y a d'une part le projet Cartographie avec son atelier et sa page de discussion, et d'autre part le projet Géolocalisation avec son atelier (qui traite des demandes créations de modèles d'infobox, mais pas que) et sa page de discussion. Pas besoin d'un projet transverse.
@Bouchecl : oui, c'est comme ça que je le vois : s'il fait une demande de carte géolocalisable, on l'envoie d'abord à l'atelier cartographique pour la réalisation de la carte, puis il fait ensuite une demande de géoloc à l'atelier géolocalisation. Sémhur (d) 22 janvier 2013 à 21:39 (CET)
@Bouchecl : je suis d'accord avec Sémhur (voir mon brouillon, c'est expliqué clairement).
@Sémhur : tu évoques le status quo, ou la synthèse de Projet:Carto/géoloc et Projet:Géoloc ? EDIT : ah, ça y est, les fils se sont touchés ! Voici un nouveau schéma :
La confusion demeure si on utilise le même mot "géolocalisation". J'ai une meilleure idée : créer un Atelier cartes géolocalisées (ou géoréférencées ?). Avec l'entête que j'ai rédigé sur le brouillon, je pense que les demandeurs ne pourront pas se tromper entre cet atelier et l'Atelier Cartes. Ce donnerait ça :
550px|center
Est-ce que ça vous convient ? --Flappiefh (d) 23 janvier 2013 à 22:52 (CET)
Les cartographes de l'Atelier sont souvent sollicités pour réaliser les cartes administratives et topographiques des régions et départements de France. En effet, celles-ci sont loin d'être au complet. Il serait bon que nous les finissions à plusieurs en suivant une même méthode : nous gagnerions du temps, les cartes seraient homogènes, et nous pourrions ensuite nous consacrer aux demandes plus originales. Sémhur m'a déjà proposé son aide. Plus nombreux, nous serons plus efficaces.
Concernant la méthode à employer, je propose celle que Bourrichon et moi avons utilisé pour réaliser la carte du Vaucluse : SRTM3 (élévation) + SWBD (lacs et gros cours d'eau) + Vmap0 (rivières) + GEOFLA (délimitations) + Palette Couleurs_Topographiques_France_1.0.gpl. Pour la projection, je favorise "Géoportal" pour deux raisons : quand on représente la France entière en l'utilisant, elle ne semble pas déformée comme avec l'équirectangulaire, et d'autre part, elle existe dans Quantum GIS donc c'est bien pratique.
Perso je suis partant, mais toutes les régions sont réalisées il me semble bien que non harmonisées. Il reste 32 départements + harmonisation de certains départements faits à l'arrache (copies d'écran de Wikisoft* (d · c · b) par ex.). Proposition d'harmonisation : 1) Carte physique : aucune frontière interne au département, graticule, échelle ? 2) Carte admin. : limites des arrondissements (même épaisseur que département) + limites communes (geofla), échelle oui mais pas de graticule ? 3) Je crois qu'il n'y a pas la projection Geoportail dans Global mapper = tu fais donc tes ombrages avec QGIS ? (quelle méthode ?) 4) Remarque. Il y a un décalage nord-ouest/sud-est systématique agaçant des rivières Vmap0 par rapport aux limites Geofla (on peut voir ce décalage sur la limite nord de l'enclave de Valréas des cartes du Vaucluse réalisées par moi aussi bien que par Flappie). Bourrichon13 février 2013 à 16:13 (CET)
2) OK, sauf l'épaisseur des arrondissements : on risque d'avoir du mal à différencier un département d'un arrondissement si on conserve la même épaisseur pour les deux. Cet exemple de la Charente est clair : on distingue bien les arrondissements et on voit qu'ils composent un département.
3) Je fais les ombres sous 3DEM en utilisant ce didacticiel. J'étire donc ensuite la couche Ombres verticalement et horizontalement dans mon SVG, pour qu'elle corresponde au raster.
4) J'ai constaté ce défaut en faisant la carte du Vaucluse. J'ai d'abord soupçonné un problème de reprojection dans QGIS, mais tu confirmes que ça ne vient pas de là. --Flappiefh (d) 13 février 2013 à 16:46 (CET)
2) c'est à cause de la différenciation commune/arrondissements. Comme les limites du département sont de toute façon confirmées par les couleurs dès le premier regard, j'ai pensé épaissir les limites des arrondissements pour mieux voir les communes (résultat). Le problème est que du coup les arrondissements et les départements hors-sujets sont confondus. Alors que faire... 3) Je te croyais puriste ! 4) Je confirme, dans QGIS les étendues d'eau de Corine Land Cover se superposent parfaitement à Geofla donc le problème vient sûrement de Vmap0. Bourrichon13 février 2013 à 18:24 (CET)
2) J'oubliais : je suis pas trop pour mettre les communes sur la carte administratives. On pourrait faire 2 cartes admin : une sans les communes, et une avec (exemple : 1 et 2), mais peut-être seulement les communes du département concerné, comme dans l'exemple. 3) Je ne connais que la méthode 3DEM ! Alors je me débrouille avec comme je peux. Mais ça fonctionne, non ? --Flappiefh (d) 13 février 2013 à 19:19 (CET)
Je ne connaissais pas la projection Géoportail, mais en cherchant un peu sur le net je découvre qu'il s'agit d'une Projection cylindrique équidistante, qui n'est autre que la projection équirectangulaire ! Sauf qu'au lieu d'être centrée sur l'équateur (comme la Plate Carrée l'est, ce qui entraîne une forte déformation à nos latitudes), elle est centrée sur la France. À quelle latitude ? Je pencherai pour 45°, mais pas sûr. Il faudrait faire un essai. Et bien sûr, Global Mapper permet de spécifier cette projection et la latitude qu'on veut utiliser. Je continue mes recherches sur Internet ; j'ai trouvé pour l'instant cette page qui apporte quelques éléments, en particulier les codes EPSG qu'il me semble que Global Mapper connaît. Mais là encore, je dois vérifier. Sémhur (d) 13 février 2013 à 22:43 (CET)
Ok, j'ai trouvé. J'ai mis le code EPSG 310024802 pour la France métropolitaine (trouvé sur la page que j'ai indiquée en lien) dans Global Mapper (fenêtre Configuration => onglet Projection => cliquer sur "Init from EPSG"), et il a tout de suite trouvé la projection associée : c'est la « Google Maps » ! Il s'agit bien d'une projection cylindrique équidistante, centrée sur la latitude 46.5 pour la France. Il est donc possible d'utiliser Global Mapper pour faire ces cartes, ou en extraire l'ombrage du relief. À propos d'ombrage, je trouve ceux de la carte du Vaucluse de Flappieh un peu trop forts ; je les verrais bien un peu plus léger. Quel pourcentage d'opacité appliques-tu à ton relief ?
En tout cas, je veux profiter de l'occasion pour me mettre une bonne fois pour toute à QGis ; j'espère que je pourrais compter sur votre aide si je rencontre des difficultés ! Sémhur (d) 14 février 2013 à 22:30 (CET)
Mes ombres sur le Vaucluse sont à 40,5%. Normalement, c'est plus vers les 30% en effet : EDIT , j'ai tamisé l'ombrage. OK pour l'aide sur QGIS, pas de problème. Maintenant il nous faut nous mettre d'accord sur les éléments à mettre/omettre sur les cartes. --Flappiefh (d) 14 février 2013 à 23:33 (CET)
En effet je constate que les communes sont vraiment peu visibles et très embrouillées sur le rendu bitmap de la page des articles. Je propose un ordre de grandeur du genre : arrondissements 1,5 px, départements 3px, région 6 px, pays 12px (à adapter au cas par cas). Pour QGIS, l'ombrage est le gros point faible, sauf à utiliser la méthode "linux" (du didacticiel QGIS). Bourrichon15 février 2013 à 21:05 (CET)
pour mes brouillons du Vaucluse. Je suis d'accord, on distingue bien mieux les régions des départements ainsi. --Flappiefh (d) 16 février 2013 à 14:17 (CET)
Bonjour, c'est une bonne initiative que cette harmonisation des cartes. Franchement, j'aurai bien voulu participer à ce travail, j'ai de très bonnes bases avec le dessin SVG Inkscape. Par contre, pour la carto, je n'y connais absolument rien, malheureusement. Et tous ces noms étrangers à mon vocabulaire me font peur : QGIS, SRTM3, SWBD, GEOFLA, etc. La seule chose que je connais là-dedans, c'est le site geoportail.gouv.fr que je fréquente régulièrement pour mes recherches, mais je ne sais même pas si c'est de ça dont vous parlez quand vous parlez de « Géoportail » ? J'imagine qu'il y a quelques tutos de dispo. Je ne les ai pas regardé. Mais s'ils permettent de construire des cartes manquantes des départements français, je veux bien m'y pencher avec vous. J'aurai bien sûr des questions à vous poser, c'est évident. M'enfin ce n'est qu'un projet à l'heure actuelle, car comme je le dis, je n'y connais rien.
— Hawk-Eye (d) 18 février 2013 à 17:06 (CET)
Hawk-Eye, tu es très bienvenu sur ce projet et sur l'atelier cartographique, il y a toujours beaucoup de travail ! Pour te répondre brièvement :
SRTM3, SWBD, GEOFLA sont des sources de données, contenues dans de gros fichiers :
les SRTM contiennent une liste de points avec pour chacun sa longitude, sa latitude et son altitude.
les SWBD indiquent les tracés des côtes, des lacs et des principaux cours d'eau
les GEOFLA font la même chose avec des limites administratives
QGIS est un logiciel SIG libre : à partir de tous les fichiers précédents, il va pouvoir générer un fichier au format SVG, que l'on travaillera ensuite dans Inkscape.
Il existe bien sûr des didacticiels pour construire de telles cartes ; tu les trouveras ici : Wikipédia:Atelier graphique/Didacticiels cartographiques. C'est Création de carte avec QGIS, dans le niveau 2, qui servira pour les cartes des départements et régions. Il existe aussi une page où nous listons les sources de données ; tu y retrouveras tous tes amis sigles, et bien d'autres : Aide:Cartographie/Ressources cartographiques géoréférencées. Et tu peux compter sur l'aide des autres cartographistes expérimentés, en l’occurrence Bourrichon, Flappieh et moi-même, qui seront toujours là pour t'épauler en cas de problème ! Sémhur (d) 18 février 2013 à 20:01 (CET)
Données techniques
Projection : Géoportail (projection équirectangulaire à la latitude de référence 46.5° Nord)
Ombrage du relief : altitude 60km, azimut 315°, opacité 30%
Source des données
Altitude : SRTM3
Lacs et cours d'eau principaux : SWBD
Autres cours d'eau : DCE (Directive Cadre sur l'Eau)
Limites administratives : GEOFLA
Cartes topographiques
Palette de couleurs : Couleurs_Topographiques_France_1.0.gpl
Données à faire figurer : coordonnées, altitudes, relief, lacs et cours d'eau, limites administratives majeures (régions, départements)
Format : JPG
Cartes administratives
Palette de couleurs : CartoWikipedia_2.0.gp (les sept premières couleurs)
Données à faire figurer : altitudes, relief, lacs et cours d'eau, limites administratives sauf communes (régions, départements, arrondissements)
Taille des traits : arrondissements 1,5 px ; départements 3px ; région 6 px ; pays 12px
Format : SVG
Cartes administratives avec communes :
La même que précédemment, avec les communes en plus (taille de trait : 0,75px)
Pour ma part, je trouve dommage de faire la carte topographique en format JPG, plutôt que de faire le fond en JPG que l'on intégrerait dans un fichier SVG contenant les autres données à afficher. Bien sûr, ce fond pourrait être réutilisé, mais enfin les cartes que l'on fait pour Wikipédia, sous licence libre, sont faites pour ça. Et il est facile de les retrouver sur Internet, au cas où l'on voudrait se battre pour faire afficher le nom de l'auteur. Au besoin, on peut ajouter dans le fichier JPG embarqué son nom en commentaire.
J'avais commis à une époque cette carte, où je faisais figurer les limites de communes, les arrondissements, les départements et les régions, avec les mêmes valeurs de traits que dans la proposition. Par contre, les données pour ces limites provenaient d'OpenStreetMap, grâce à des fichiers .shp.tar.gz (l'emplacement à l'air d'avoir changé, mais ça doit pouvoir se retrouver facilement). Mais je ne connais pas la précision des limites données par Geofla ; si elle est suffisante, c'est ok.
Pour les topo en SVG, pourquoi pas, mais en taille réduite j'ai souvent des problème de rendu très mauvais ! (les caractères forment des pâtés noirs illisibles). Et ces cartes sont destinées à être affichées en tout petit la plupart du temps. --Flappiefh (d) 18 février 2013 à 20:24 (CET)
Pour les rivières, je n'ai pas trouvé mieux que les VMap0 (malgré le problème de déformation aux extrémités de la carte). Mais ça existe sûrement...
Oui le svg n'est pas joli sur le jpg, or c'est rapide d'exporter en bitmap avec Inkscape ou The Gimp, on n'a donc qu'à mettre le fichier svg (parfois bien utile à diverses récupérations) à disposition en plus du jpg qui sera utilisé dans les articles. Pour les rivières, je pense avoir trouvé quelque chose de bien : données eaufrance + avertissement sur les données eaufrance : description des droits hélas un peu floue mais à priori compatible avec cc-by-sa (alors que les données du SANDRE sont cc-by-NC-sa). Les cours d'eau de ce fichier shapefile, bien plus précis que Vmap0, ont un attribut "main = Yes" ou "main = No" qui permet de différencier (par exemple épaissir) les cours d'eau les plus importants avec un logiciel SIG (sinon il y a tellement de cours d'eau que cela risque d'être illisible). Bourrichon18 février 2013 à 22:59 (CET)
Je propose de laisser l'image raster dans le fichier SVG administratif (calque caché), ça nous évitera d'avoir 3 ou 4 versions d'un département. Nous pourrions indiquer clairement sur la page de description de la topo et de l'administrative que le fichier SVG admin contient les couches utilisées par les 2 images.
OK pour l'eau, je testerai tout ça. Il va falloir s'accorder sur la méthode (on supprime les "no main" ou on les dessine en très fin ?). --Flappiefh (d) 18 février 2013 à 23:26 (CET)
Il faut tester. Parce que la base est précise mais il n'y a pas non plus chaque petit ruisseau. Attention pour le calque caché, il y a la question du poids du svg qui du coup est peut-être un peu moins manipulable. Bourrichon19 février 2013 à 18:12 (CET) P.S. Je confirme la licence ouverte des données eaufrance.
Vmap0
DCE "eau France"
Voici un test comparatif. Il n'y a pas photo : les tracés de la DCE sont meilleurs car ils ne se déforment pas comme les Vmap0 et ils sont bien plus fournis. Par contre je ne comprends pas : pourquoi certains cours d'eau sont présents sur Vmap0 et pas sur DCE ?? On dirait que chacun recense des cours d'eau inconnus de l'autre ! Exemple flagrant : sud-ouest du Vaucluse, pas un cours d'eau sur DCE, au contraire de Vmap0... que fait-on à ce sujet ? --Flappiefh (d) 20 février 2013 à 19:42 (CET)
Oui, autres exemples du même type sur File:Sources GIS -fr.svg notamment eaufrance versus ECRINS, sans doute ces sources n'ont-elles pas la même définition de ce qu'est un cours d'eau ? (inclut-on les canaux ? les cours d'eau souterrains comme la Bièvre ? etc.). Pour Vmap0, c'est une source périmée sur d'autres sujets, alors j'ai des doutes sur ses cours d'eau... Bourrichon20 février 2013 à 19:54 (CET)
OK, je pense qu'on a réussi à se mettre d'accord sur pas mal de choses. Il reste un point de désaccord sur les ombres, et je n'ai pas encore testé la réalisation d'une carte des communes. J'essaye ça pour le Vaucluse. Bourrichon, puis-je remplacer tes cartes du Vaucluse pour le modèle de géolocalisation ? --Flappiefh (d) 22 février 2013 à 17:29 (CET)
Voici un essai de carte des communes. J'ai retiré les cours d'eau car je trouve que ça nuit à la lisibilité. J'ai utilisé une épaisseur de 1 px pour les communes. Nous pourrions aussi carrément supprimer les autres limites administratives, sauf peut-être les arrondissements ? --Flappiefh (d) 22 février 2013 à 20:14 (CET)
Je trouve ça bien, mais la carte serait plus utile si les communes étaient des polygones, ça pourrait donner lieu à diverses cartes dérivées (politiques entre autres)(=>fichier communes.shp et non limites_communes.shp). Sinon pourquoi ne pas mettre aussi les communes autour du département, quitte à rendre le gris des limites de ces communes-là un peu moins foncé ? Cela nous différencierai des cartes du type File:Blank Map of Vaucluse Department, France, with Communes.svg ? Enfin pour les cours d'eau je suis assez d'accord, notamment parce que les cours d'eau risquent d'être plus précis que les limites, ce qui donne un embrouillamini de traits gris et bleus. Bourrichon23 février 2013 à 14:20 (CET)
Relief (téléversé)
Administrative (téléversé)
Brouillon 1 pour les communes (pas d'eau, épaisseur communes = 1px) - qu'en pensez-vous ?
Les deux premiers, rivières et lacs, sont essentiels, les eaux côtières sont inutiles car pas très précises, et les eaux de transitions contiennent les rades, les golfes, etc. mais pas les marais, ce n'est pas très précis : on a mieux ailleurs. Bourrichon23 février 2013 à 13:29 (CET)
Par ailleurs, connaissez-vous un convertisseur pour les coordonnées décimales/sexagésimales vers les « mètres » IGN GEOPORTALFXX ? Moi, après plusieurs recherches, j'ai trouvé cela (fichier OpenOffice Calc ouvrable également avec Excel ; plus d'infos en bas de cette page) mais il y a une notion de « dalle » qui m'est inconnue. Je ne sais pas comment vous faites, vous, du coup, pour exporter les données de QGIS avec le composeur d'impression dans le système de coordonnées Géoportail avec des coordonnées exactes ? — Hawk-Eye (d) 23 février 2013 à 12:08 (CET)
1) Connaître les limites de l'emprise souhaitée : avec la gdex tu as téléchargé une zone "à la carte", donc tu connais les limites en degrés, sinon tu peux aussi zoomer dans QGIS sur le bord de ton raster pour voir les coordonnées sous le pointeur. Puis après projection, tu recommences le zoom. Exemple, limite Ouest pour ton raster des Hautes-Pyrénées : -0.44 degrés décimaux, soit -33716 mètres (et des poussières) dans la projection géoportail. (Évidemment dans d'autres projections, non équirectangulaires, c'est moins évident parce que les bords deviennent "courbes".) 2) exporter l'emprise voulue : voir le tuto dédié, ainsi que l'étape 2 de File:Tuto QGIS Composeur 2.svg. Bourrichon23 février 2013 à 13:01 (CET)
OK, donc on ne peut pas vraiment savoir exactement la conversion ? La seule solution est de zoomer dans QGis sur le bord et regarder quelle coordonnée indique le pointeur ? (Je sais bien qu'au final, on ne verrait pas la différence, mais c'est simplement que j'aime bien être précis ) Ensuite, pour l'export de l'emprise, j'ai déjà testé il y a 2 jours et ça ne m'avait pas posé de problème, donc ça devrait aller. — Hawk-Eye (d) 23 février 2013 à 13:39 (CET)
Je m'occupe du Gard , puisque je l'avais sur mon raster du Vaucluse. Je peux également refaire les Bouches du Rhône. --Flappiefh (d) 24 février 2013 à 10:45 (CET)
On va donc te laisser le Sud-Est . Je me propose de faire les départements délaissés du Massif central (j'ai un assemblage de rasters srtm3 de la France entière). On n'a pas de conventions pour la grille. 0,1 px ? Bourrichon24 février 2013 à 13:02 (CET)
Je vais tenter de finir les Pyrénées (Atl + Orientales), alors. Ça va m'entraîner avec les données bathymétriques en plus.
Sur cette carte, j'ai utilisé 0,2 px pour la grille. M'enfin, peut-être que ma carte n'est pas représentative car d'un format légèrement trop petit.
OK. Je pense qu'il faut qu'on se répartisse le boulot par régions. Ainsi, pour une région effectuée, le wikigraphiste n'a plus qu'à "découper" sa carte en départements. L'Île de France est assez demandée (le Val de Marne attend son tour dans l'Atelier Cartes, par exemple).
Pour la grille, je pense qu'il faut qu'elle soit la plus fine possible tout en restant visible. Pour te donner un ordre d'idée, Bourrichon, sur ma carte du Vaucluse, les cours d'eau font près d'1 px et la grille 0,3px. --Flappiefh (d) 24 février 2013 à 13:51 (CET)
Donc 0,2 ou 0,3. En fonction de la carte. Pour les cours d'eau, la carte de Hawk-Eye montre que le réseau ECRINS aussi bien que DCE (comparer DCE / ECRINS) est peut-être trop dense ? Pour le Vaucluse, comme le département est petit, il n'y a pas ce problème. Si besoin, QGIS peut trier les cours d'eau ECRINS par nombre de Strahler. (Au passage, Hawk-Eye, ta carte avance bien mais a un problème d'ombrage qui ne va pas jusqu'en bas.) Bourrichon24 février 2013 à 14:21 (CET)
Oui, la crainte du "trop d'eau" est justifiée. Mais je pense qu'en affinant les traits d'eau, on obtient une carte pleine d'informations et pas illisible (exemple avec le Gard : admin et topo). En tout cas, le filtre dont tu parles est intéressant. --Flappiefh (d) 24 février 2013 à 14:32 (CET)
Le pb d'ombrage sur la carte vient encore d'un beug du svg (avec MediaWiki certainement), qui n’apparaît pas dans Inkscape. Mais ce n'est pas grave car je l'exporterai en jpg ensuite, au moment de l'importation sur Commons. (D'ailleurs, comment obtenez-vous un jpg pour les cartes topographiques alors qu'Inkscape n'exporte qu'en png me semble-t-il ?)
Ce filtre, il fonctionne comment par contre ? C'est via la table d'attribut dans QGis ? (oui) J'ai réussi à selectionner ceux qui portent la valeur 10 du nombre de Strahler via la table d'attribut : mais comment les masquer/les supprimer ? Sinon, ce serait bien car je trouve aussi que trop de cours d'eau tue le cours d'eau… — Hawk-Eye (d) 24 février 2013 à 14:56 (CET)
@Flappie : Oui pour le Gard c'est très bien (magnifique même). Tu as mis combien de px ? @hawk-Eye : Pour le filtre QGIS, oui il y a une colonne "Strahler" dans la table d'attributs avec des nombres de 1 à 10. Pour la DCE, il y a une colonne "main stream" avec simplement Y ou N (ça diminue les possibilités). Pour trier, deux possibilités :
garder un seul fichier mais faire une requête pour faire apparaître ou non tel cours d'eau (Couche > clic droit > Requête puis taper STRAHLER LIKE '%10%' OR STRAHLER LIKE '%9%' pour ne faire apparaître que les types de cours d'eau 9 et 10). Ce type de méthode par "règles" a ma préférence car on pourrait aussi modifier l'épaisseur en fonction du nombre de Strahler. Suivre cette section avec des règles du type STRAHLER LIKE '%10%' et épaissir le trait bleu pour ce type de cours d'eau. Ajouter autant de règles que d'épaisseur. Pour l'anecdote, c'est ce que je fais pour les limites administratives : QGIS les exporte directement en gris et avec la bonne épaisseur. Bourrichon24 février 2013 à 15:35 (CET)
PS : attention ECRINS est un fichier SpatiaLite qui est certes vectoriel mais que je ne connais pas trop, en cas de difficulté l'exporter en fichier shapefile (couche > clic droit > sauvegarder sous), et là ça marche comme d'habitude. Bourrichon24 février 2013 à 15:39 (CET)
┌─────────────────────────────────────────────────┘
@Bourrichon : Tout a bien fonctionné, même en utilisant les données sous forme SpatiaLite. Thanks . J'ai supprimé 2 niveaux de ramifications selon la méthode décrite. On peut comparer les résultats : avant et après. Qu'en dites-vous ?
Le problème avec cette méthode, c'est que ça repose sur les ramifications. Donc c'est très bénéfique en haute-montagne, mais un peu dommage plus en plaine, je trouve. Non ? M'enfin c'est globalement plus satisfaisant qu'avant. — Hawk-Eye (d) 24 février 2013 à 16:17 (CET)
En effet, on n'est plus noyé sous l'information ! Je pense comme toi : cette pratique ne devrait pas être généralisée, mais utilisée dans des cas extrêmes, tel que celui que tu as rencontré pour cette carte. --Flappiefh (d) 24 février 2013 à 17:11 (CET)
@Bourrichon : voici les valeurs utilisées pour les cartes du Gard, en pixels. Region=6, département=3, arrondissement=1.5, cours d'eau=0.75, lacs et mer=1, grille=0.3 --Flappiefh (d) 24 février 2013 à 17:11 (CET)
On a donc des conventions sur à peu près tout et on a découvert des sources intéressantes (manquent les lacs ECRINS mais j'ai envoyé un mail à l'EEA). Restent deux questions pour moi : 1- pour toutes les cartes, pourquoi ne pas utiliser les fichiers polygonaux plutôt que les seules limites administratives ? 2- Pour les cartes de communes, pourquoi ne pas ajouter les communes hors-département (cela ajoute de l'information surtout pour les communes limitrophes) ? Bourrichon24 février 2013 à 19:41 (CET)
1- Fichiers polygonaux : plus lourds que les limites je pense (car doublons de limites). Mais si on en dispose, ce serait mieux, oui, lorsqu'on veut colorer une ou plusieurs communes. 2- Je n'ai pas trop d'arguments, mais visuellement, je préfère voir la limite départementale et la commune visée à côté des autres communes de ce département, sans rien d'autres. Je pense qu'on devrait ouvrir une nouvelle discussion pour nous mettre d'accord sur ces fameuses cartes communales... --Flappiefh (d) 24 février 2013 à 20:32 (CET)
C'est certainement dû à ma très faible expérience, mais on n'a pas défini dans nos conventions la source à utiliser pour les côtes ? (ça doit être une évidence pour vous, mais pas pour moi ). Et aussi, pour la barymétrie, on met la mer/l'océan d'une couleur uniforme (car globalement on s'éloigne peu des côtes pour les cartes de France métropolitaine) ? Ou bien on utilise une source spécifique ?
Pour les fichiers polygonaux : ça m'a étonné de voir que les fichiers .shapefile sont moins lourds sous forme des polygones que sous forme des limites (de peu, mais quand même). Après, ça ne veut sûrement pas forcément dire que cela se retranscrit sur le fichier .svg, je n'en sais rien…
Y a un effet « bizarre » si on laisse les communes avoisinantes : on a du mal à différencier le département en question je trouve. À voir ce que ça donnerait en changeant de couleur et/ou de transparence…
Après tout je ne sais pas, il faut tester. En regardant une carte je situe une commune par rapport aux communes avoisinantes, or pour les communes frontalières elles n'apparaissent pas. Mais ta carte actuelle du 65 est très bien.
Pour la mer, on a l'habitude de faire comme dans les cartes complétées (voir Projet:Cartographie/Cartes_standards/France) : SRTM3 pour les terres + ETOPO pour la mer (ma technique, qui consiste à rendre transparent dans QGIS les parties terrestres des ETOPO pour laisser apparaître les SRTM3, n'est pas forcément la plus simple, je ne sais pas comment font les autres).
Pour les côtes, les SWBD sont très bien, mais le trait est très fragmenté si je me souviens bien (il faut alors combiner les fragments dans Inkscape et les faire couper en morceau un polygone placé en arrière-plan). Openstreetmapdata possède un fichier à trait de côte continu permettant d'avoir directement une mer en polygone fermé. Bourrichon25 février 2013 à 00:42 (CET)
Je veux bien mettre à jour la carte du Gard avec les données ETOPO, mais je ne sais pas comment faire. Je vois qu'il y a en plus des ombres dans la mer... Quel didacticiel utilises-tu, Bourrichon ?
Je confirme les complications de SWBD. Comment extraire seulement les traits de côtes depuis OSMdata ? Sont-ils relativement aussi précis que les SWBD ? --Flappiefh (d) 25 février 2013 à 16:53 (CET)
Pourquoi ne pas faire Inkscape > objet > découpe, à l'aide du trait de côte, qui ainsi peut départager les deux bitmaps SRTM3 et ETOPO ? Pour le trait de côte alors, peu importe qu'il soit fragmenté, non ? Sinon OSMdata proposeproposait 3 fichiers : terres pleines, terres fragmentées, trait de côte fragmenté. Plus correct que les SWBD qui ont des traits non rectilignes dans les ports. Mais les SWBD montrent les lagunes et étangs côtiers, pas OSMdata (ceci dit les lagunes vous pouvez les avoir par ailleurs, avec Corine Land Cover par ex., presque aussi précis que les SWBD). Il y a aussi le trait de côte EUROSION sur le site de l'EEA (comme pour ECRINS) qui est de la même précision que OSMdata, mais avec quelques différences (complémentaires). Bourrichon25 février 2013 à 19:01 (CET)
Je me suis mal exprimé. Comment récupères-tu les données "ETOPO" ? Il y en a pas mal de variantes, et je cherche une méthode simple avec un lien, un logiciel, une méthode, et pouf ! Une image TIF sous QGIS. --Flappiefh (d) 26 février 2013 à 17:56 (CET)
GTOPO30 avec le site gdex (choix par zone, pratique) ? Il me semble que c'est la même chose que les ETOPO1 pour la mer. Quant aux terres comprises dans ces GTOPO30, il suffit de les supprimer d'une manière ou d'une autre. Bourrichon26 février 2013 à 18:44 (CET)
Je ne connais pas gdex. Comment exporte-t-on les fonds de carte ? Je ne vois pas de bouton Download ou Export... --Flappiefh (d) 26 février 2013 à 19:31 (CET)
Pour les communes des petits départements (92-93-94-95), je propose qu'on utilise les limites du cadastre, facilement utilisables via OSM, plutôt que GEOFLA, ce sera bien plus précis (image:Bourrichon5.png), en enlevant les quartiers intra-communaux et en ajoutant les quelques petits bouts de limites qui manquent. Bourrichon27 février 2013 à 14:45 (CET)
OK pour les communes des petits départements. J'avoue n'avoir pas reconnu le "Val de Marne GEOFLA" tout de suite, alors que j'y habite ! Tu es d'accord pour adopter OSM pour les petits départements, Hawk-Eye ? --Flappiefh (d) 28 février 2013 à 16:25 (CET)
Pas de problème, je vais modifier les cours d'eau et les limites communales en utilisant OSM. Je vais faire quelques tests. — Hawk-Eye (d) 28 février 2013 à 17:26 (CET)
Pour info, on m'a demandé le SVG du Vaucluse. Je l'ai téléversé, mais j'indique sur la page du fichier qu'il vaut mieux l'utiliser uniquement pour faire des modifications. Après, je n'en voudrais à personne si il supplante le SVG, mais pour le moment le rendu JPG est plus joli et précis. --Flappiefh (d) 4 mars 2013 à 19:49 (CET)
Carto, le nouveau
Bonjour. Je vous propose d'ouvrir une nouvelle page comme Utilisateur:Hawk-Eye/Aide:Cartographie que certains d'entre vous (comme Sémhur, Bourrichon et Flappiefh, par exemple, car cités ci-dessus ) pourraient suivre, et, s'ils ont le temps, répondre à mes complaintes pour mes débuts. En espérant pouvoir, à terme, travailler aussi bien que vous…
— Hawk-Eye (d) 18 février 2013 à 23:43 (CET)
Bonjour, j'ai créée la carte du parcours de Paris-Nice 2013 mais j'ai un problème d'affichage. J'ai demandé, on m'a dit de lire le didactiticiel, j'ai améliorer l'image (on voit le texte désormais), mais j'ai toujours un problème : le fond de carte ne s'affiche pas. Que faire ? I love the cyclisme (d) 23 février 2013 à 00:14 (CET)
Bonjour, j'ai fini par trouver l'image en question. Il eut été plus simple d'en mettre le lien. Je constate deux gros problèmes. 1/ Il manque la carte géographique. Pour l'afficher, au moment de l'ajouter dans Inkscape, il faut choisir "Incorporer". Donc supprimer d'abord l'image dans Inkscape, puis rajoute-la et choisis "Incorporer". 2/ Les rectangles noirs un peu partout. Je te renvoies à la FAQ SVG qui explique comment faire. --Flappiefh (d) 24 février 2013 à 20:43 (CET)
Ce dernier rectangle n’a pourtant pas été converti en texte (Briou). Si un deuxième « convertir en texte » ne fonctionne pas, alors il faut supprimer cet élément et refaire un nouveau bloc de texte.
Plutôt que de donner un nouveau à chaque fois à ce fichier, le mieux est d’importer les différentes versions sous le même nom : il y a même un lien « Importer une nouvelle version de ce fichier » qui est là pour cela.
L’un d’entre vous saurait comment fonctionnent (voire comment sont codées) les grilles dans Inkscape ? Comme d’habitude, Inkscape utilise sa propre tambouille de code SVG pour créer un truc qui n’existe pas nativement. Dans l’absolu c’est une très bonne chose mais malheureusement, ce n’est pas documenté donc il faut se débrouiller par soi-même si on veut le comprendre ; j’ai déjà été surpris de constater que l’origine de la grille n’est pas l’origine du document… et je ne comprends pas tout les paramètres de ces grilles. Quelqu’un aurait déjà exploré ce sujet ?
Bonjour. La grille semble toujours cadrée par défaut avec l'origine du document, et on peu la décaler par le menu grille. Si on aligne certains éléments d'un dessin sur la grille quand on le compose, ces éléments ne sont plus alignés sur la grille si l'on recadre le document à ses parties visibles (pour ne pas avoir un grand document avec un petit dessin dedans) quand on le sauve. Ce qui pose un problème quand on réédite le document pour le modifier, car il faut déplacer le dessin dans le document pour que certains éléments initialement alignés avec la grille le soient à nouveau. Ou essayer de modifier la position de la grille, ce qui est encore plus aléatoire. Et c'est très énervant. Il y a une parade, c'est de tracer un cadre aligné sur la grille avant de réduire le document à ses parties visibles. J'oublie toujours de le faire...C'est ça le problème que tu rencontres, ou autre chose ? Michel Barbetorte (d) 26 février 2013 à 11:59 (CET)
Bonjour,
Alors d’abord pour re-situer quel type de « wikigraphiste » je suis : je fais du SVG quasiment uniquement avec un éditeur de texte (Gedit en l’occurrence). Du coup, je fais du SVG standard (« SVG simple » comme l’appelle Inkscape), ce qui est est souvent mieux mais pas toujours. Vu que le format SVG standard souffre de − gros − manques, Inkscape a crée son propre format SVG (très proche du standard mais avec des différences parfois déconcertantes ; Sodipodi et Illustrator ont aussi leurs versions d’ailleurs, c’est un peu festival quand je regarde le code de certains fichiers sur Commons). Vu que l’édition du SVG avec du texte peut devenir rapidement compliquée (notamment quand il s’agit de fichiers lourds), j’utilise tout de même parfois Inkscape mais je le connais finalement assez mal.
Donc mon principal problème c’est surtout que je ne connais pas du tout le fonctionnement des grilles dans Inkscape (qui a changé à partir de la version 0.46 d’ailleurs) car elles n’existent pas en SVG standard. Je n’est quasiment pas trouver d’aide ni d’explication sur Internet (rien du tout sur inkscape.org…). Je découvre qu’il existe deux types de grilles et tout un tas de paramètres de réglages. Par contre, je ne comprends pas bien à quoi servent tout ces paramètres. La grille rectangulaire, j’ai compris en tâtonnant mais pour la grille axonométrique tâtonne encore (l’espacement Y se fait uniquement selon l’angle / sur l’axe et pas en projeté). Bref, tout ça c’est du tâtonnement, je n’arrive pas à maîtriser exactement comme je le voudrais. Par exemple et bizarrement, quand j’indique l’angle (en degrés uniquement ? Je ne suis pas bien sur non plus de comprendre quelles sont les unités utilisés) égal à 0, celui ci n’est pas horizontal… (pour faire des perspective cavalières par exemple).
Du coup, je n’ai pas eu le problème dont tu parles (forcément, en éditeur de texte, j’utilise directement les chiffres exactes dont peu me chaut les grilles, je les supprime en général quand je passe sur un fichier existant, c’est mal ?).
Sinon pour l’origine, j’ai − encore − confondu, j’avais − encore − oublié que l’interface d’Inkscape la plaçait en bas à gauche (alors qu’en SVG l’origine se trouve en haut à gauche ; encore une bizarrerie qui rend la gymnastique de passage de l’éditeur de texte à Inkscape difficile et mes explications incompréhensibles pour un utilisateur d’Inkscape ; c’est pour cela que j’essaye de me mettre à Inkscape d’ailleurs).
Donc je ne peux t'être d'aucune aide. Je trouve quand même plus simple de faire des dessins avec Inkscape, et j'évite au maximum d'y mettre du texte ! --Michel Barbetorte (d) 26 février 2013 à 17:11 (CET)
Dommage. N’arrivant pas à faire ce que je veux, j’ai testé des réseaux de guides ; c’est plus lourd comme méthode mais plus souple.
Inkscape possède de nombreux avantages (interfaces graphiques − pour du graphisme ça peut servir − et ajouts utiles en SVG non standard) mais il a aussi des inconvénients (morceaux de code inutiles et absence de documentation SVG non standard).
Bonjour Vigneron. J'ai bien compris que tu n'aimais pas Inkscape, mais tu as un besoin que tu ne peux satisfaire en codant 'à la main'. Quel est ce besoin ? Tu ne l'as pas formulé. --Flappiefh (d) 27 février 2013 à 13:27 (CET)
Attention, dans l’absolu et dans l’esprit, j’aime beaucoup Inkscape. Par contre, je suis déçu et désappointé quand il fait les choses en dépit du bon sens (si on entre un carré de 10px de côté avec l’interface, il va produire du code correspondant à un rectangle dont un côté fait 10.000001px et l’autre 9,9999999px et là j’avoue que je ne comprends juste pas pourquoi il fait ça !) ; le pire n’étant pas qu’il fasse des choses bizarres mais qu’il fasse ces choses sans prévenir et sans donner d’explication ou de documentation… (du coup, ces bizarreries sont peut-être en partie dues à mon inexpérience avec Inkscape mais sans documentation comment acquérir cette expérience ? heureusement, il y a cet atelier \o/). Sinon, je peux tout à fait satisfaire ces besoins « à la main » mais c’est dommage (vu que les grilles servent justement dans un contexte graphique que j’essaye d’apprivoiser).
Je n’ai pas de besoin en particulier mais j’ai des tas d’exemples en tête. Par exemple : quand on dessine un plan, on peut avoir besoin d’une grille pour les coordonnées (latitude, longitude) ; quand on dessine un objet en perspective/projection, on peut avoir besoin d’un grille selon cette perspective/projection ; etc. Donc mon besoin est plutôt global : savoir comment fonctionne les grilles dans Inkscape. Un besoin secondaire serait de pouvoir expliquer ce fonctionnement sur v:Optimiser un fichier SVG.
OK, alors je n'utilise pas du tout la grille, mais en fouillant un peu dans le soft, voilà ce que j'ai trouvé :
Il faut d'abord afficher la grille : Affichage > Grille. Ça crée un objet nommé grid#### et ça nous l'affiche.
Les paramètres de la grille sont maintenant accessibles via Fichier > Propriétés du document > Grille.
Ce menu nous indique que l'origine de la grille est par défaut le point (0,000x;0,000y). Donc j'affiche la grille, je crée un carré, je le sélectionne et modifie sa position pour (0,000x;0,000y). Je fais ça dans la barre de menu. Je constate que mon carré s'aligne avec le bas gauche de la page et qu'il coïncide parfaitement avec la grille, si on part du bas gauche (image jointe).
En revenant dans le menu Grille, Le bouton Nouvelle nous permet de créer une nouvelle grille. Celle-ci peut être Rectangulaire ou Axonométrique (3D). Nous pouvons alors personnaliser ses paramètres.
Bonjour. Pas satisfait de ma seconde approche de la carte de l'Ile du Prince Édouard, je recommence tout depuis le début ! Jusqu'ici tout va bien, même si j'ai du mal à identifier la projection que j'utilise (satané QGIS). On parlera de ce problème plus tard.
Pour le moment, je souhaite ne charger que le strict nécessaire pour ma carte. Comme vous pouvez le voir sur l'image, j'ai chargé des Shapefile des cours d'eau de la région, mais je ne souhaite pas les exporter ainsi dans Inkscape sinon il va irrémédiablement planter devant tant d'information.
Première piste : n'afficher que ce qui se trouve dans l'emprise du raster. Comment faire ?
Seconde piste : n'afficher que les principaux cours d'eau, mais les données ne comportent pas le champ 'Strahler'. J'ai 'Précision' (égal à 14 ou 25), 'Couvermeta' (1 ou 0), 'Définition' (égal à 6), 'Type texte' ("Cours d'eau", "Conduit", ...), 'BDTOPONYME' (BDTC ou rien), NOM1 (nom d'un cours d'eau ou rien)... Bref, comment filtrer efficacement ?
Pour la seconde piste la description des données n'est en effet pas très exploitable. Les données Vmap0 sont-elles trop pauvres ? Bourrichon2 mars 2013 à 14:06 (CET)
Je n'avais pas pensé à Vmap0. Je suis en train de télécharger la partie nord-américaine. Cependant, je crois avoir trouvé un filtre qui fonctionne avec GEOBASE : 'BDTOPONYME' = "BDTC" et 'NOM1' <> NULL donnent le même résultat : il ne reste que les cours d'eau les plus remarquables. Je vais voir si ça colle avec Vmap0. --Flappiefh (d) 2 mars 2013 à 14:24 (CET)
Verdict : Vmap0 est trop imprécis, et il y a toujours ce problème de déformation. Mais on voit que les cours d'eau requêtés de GEOBASE correspondent aux cours d'eau de Vmap0. Je pense donc conserver cette méthode pour filter GEOBASE. --Flappiefh (d) 2 mars 2013 à 15:07 (CET)
Ce que tu vois dans l'image, c'est une superposition des rivières et des rives de GEOBASE. Je vais supprimer les petits lacs, et les côtes maritimes que ça m'a apporté, et je ne conserverai que les bouts de rivières qui manquent car ils font partie du Shapefile des rives. C'est un travail de longue haleine, mais je pense que ça en vaut le coût quand on voit ce que ça aurait donné avec Vmap0... --Flappiefh (d) 2 mars 2013 à 18:20 (CET)
En te relisant, je me rends compte qu'on ne parle pas de la même chose. Je confirme qu'il doit s'agir de petits lacs (voire étangs, à ce stade). --Flappiefh (d) 3 mars 2013 à 12:46 (CET)
Vous faites tous les edits dans QGis ? J'ai exporté la carte d'un gros projet dans Inkscape et je me trouve comme un couillon maintenant :__; Yug(talk)26 mars 2013 à 11:54 (CET)
Fais tout ce que tu peux faire avec QGIS sous QGIS, c'est moins douloureux ainsi. Notamment la suppression des infos qui ne te serviront pas sur le SVG final. C'est ce que j'ai appris en bossant sur l'Île du Prince Édouard. --Flappiefh (d) 26 mars 2013 à 18:53 (CET)
Sud-Soudanisation ?
Bonsoir, concernant les cartes laissant apparaître l'Afrique, je constate bien trop souvant (notamment sur les répartitions géographiques des espèces) l'absence du pays nouvellement indépendants qui est le Soudan du Sud : il est peut-être temps de réactualiser tout ça (je préfére attendre vos avis). 77.201.135.168 (d) 04 mars 2013 à 20:46 (CET)
Bonjour, une catégorie a été créée sur Commons pour classer toutes les cartes qu'il faut modifier : commons:Category:Maps needing South Sudan political boundaries. Le chantier a été commencé depuis la naissance du Sud Soudan, mais il y a encore du boulot, en effet. Si vous repérez des cartes à modifier qui ne sont pas dans la liste, merci de les y ajouter en leur atribuant la catégorie sus-citée.--Flappiefh (d) 4 mars 2013 à 23:00 (CET)
Bonjour. Oui, le problème est que le robot qui a créé toutes ces cartes s'est basé sur le site de l'Insee. Et là on se dit : « C'est l'Insee, ça doit être fiable. »... et non ! Regardez cette page, et vous comprendrez.
Et donc, il faudrait mettre à jour ces cartes à la main, mais il est difficile de trouver des sources montrant les divisions de cantons au sein d'une commune, comme c'est le cas pour Épinal. Enfin, ça dépend des départements en fait. Si vous trouvez des sources, vous pouvez faire une demande à l'atelier cartographique pour qu'ils modifient ces cartes. Sémhur (d) 11 avril 2013 à 11:29 (CEST)
Image bitmap
Bonjour. J'ai voulu créer une carte de la Nouvelle-Écosse en 1632 en me basant sur le travail de Sémhur (d · c · b) pour les Provinces maritimes. Je me suis dit qu'avec ce genre de sujet c'était mieux d'avoir un fond de carte en bitmap, comme des contributeurs l'ont fait pour d'autres cartes. Le problème, c'est que la taille du fichier complété est de plus de 5 Mo. Est-ce que j'ai bien fait d'utiliser du bitmap? Comment réduire la taille du fichier? --Red Castle[parlure]15 avril 2013 à 20:43 (CEST)
Salut. La principale surcharge pondérale de ton fichier venait du fait que le fond de carte était au format PNG. C'est étrange, car je l'avais moi enregistré en JPG, qui est ici dix fois plus léger. Un autre problème venait de ce que tu avais oublié la carte issue de [1] dans un des calques. Je me suis permis de mettre la légende en bas à gauche ; en plein milieu ça faisait bizarre. Je te suggère aussi d'augmenter la taille des textes ; là ils sont un peu petits (ces deux derniers points sont des avis personnels, ne te sens pas obligé d'en tenir compte !) Sémhur (d) 15 avril 2013 à 21:51 (CEST)
Est-ce qu’il y a un endroit pour demander la récupération d’une image ?
Mon cas concret est le suivant : je viens de récupérer File:Caylus - Roche aux fées (1756).png via le site Internet Archive (pas de problème de droit d’auteur évidemment) mais la qualité du fichier est assez faible. Je pourrais en demander l’amélioration numérique mais le mieux serait encore de récupérer une meilleure version de base. Après coup, je me suis rendu compte que l’ouvrage d’où est tiré cette planche est aussi disponible via Gallica ici : [2]. Par contre, je ne sais pas comment récupérer ce fichier (en regardant le code, je ne trouve qu’une miniature [3], en modifiant/retirant les paramètres je pensais avoir la version originale mais je n’obtiens que des messages d’erreur…).
Au-delà de mon problème personnel, je me dis qu’une page spécifique dédiée à ce genre de demande pourrait être une bonne chose, qu’en pensez-vous ?
Commentaire liminaire : L'image que tu donnes en exemple sur le site de l'inha (p.554) est de piètre qualité, elle a été très fortement compressée et les artefacts jpg sont fort visibles. De plus, je n'arrive pas à obtenir une taille équivalente à la version présente sur Commons (excepté lors du zoom en flash).
Néanmoins, petite technique improvisée pour extraire une image de ce type :
Télécharger le PDF du fichier.
Ouvrir Inkscape, importer le PDF dans Inkscape en sélectionnant la page voulue
Merci pour ta proposition, au niveau des couleurs elle est netemment mieux par contre, la résolution est inférieure (539 × 796 au lieu de 1712 × 2444 via Internet Archive où j’avais utilisé la même technique que celle que tu as proposé).
Et sinon que penses-tu de mon idée plus générale d’avoir une page dédiée pour ce genre de demande ?
Ma demande me semblait suffisamment différente pour avoir sa propre page (on n’est pas du tout dans les exemples cités sur WP:AG) mais après tout effectivement la page habituel doit pouvoir convenir, j’y déplace donc ma demande. Cdlt, Vigneron * discut.21 avril 2013 à 12:26 (CEST)
Beaucoup s'endorment…
Bonjour.
Je me demandais s'il ne fallait pas réveiller certains utilisateurs et wikigraphistes sur des sujets et demandes en cours, notamment dans la section « Images à améliorer ». Des requêtes traînent et d'autres ne peuvent pas être réalisées, faute de main-d'œuvre et d'expériences de certains.
Oui bien sûr ! N'hésite pas à les relancer, au moins pour savoir s'ils ont l'intention de continuer le travail, ou s'il l'abandonne. Sémhur (d) 25 avril 2013 à 17:39 (CEST)
Je suis fier de la bonne volonté et du travail de chacun. Cependant, je pense que « nous manquons de troupes » ! La plupart des demandes de l'Atelier Graphique dans la section « Images à améliorer » sont des demandes de vectorisation d'images. Je fais partie de ceux qui ne sont pas capables de réaliser ces travaux. Une campagne de recrutement s'impose selon moi, car peu sont les Wikigraphistes encore actifs, pour réaliser et terminer les demandes datant déjà la fin de l'année 2012. Je pourrais le faire, par le biais du Wikimag dans le prochain numéro, après votre accord à tous.
Il y a 25 demandes non traitées en ce moment à l'atelier d'amélioration d'images, dont probablement 2 ou 3 qui sont terminées mais pas marquées comme telles (il faudrait relancer les demandeurs pour qu'ils valident le travail) et 3 demandes qui auraient dû aller à l'atelier cartographique. Du côté de ce dernier, il y a 17 demandes. Ça fait en gros vingt de chaque côté, c'est un bon chiffre ; on a connu bien pire !
Mais bien évidemment, c'est une bonne chose de lancer une campagne de recrutement. Toutes les bonnes volontés sont les bienvenues ! Personnellement, je suis pour que tu en parles dans le prochain wikimag. N'oublie pas de préciser que des didacticiels sont présents pour aider les nouveaux à débuter (et les moins nouveaux également) : didacticiels graphiques et didacticiels cartographiques. Sémhur (d) 30 avril 2013 à 11:51 (CEST)
Je me doute que l'Atelier graphique a pu connaître pire, mais les temps sont (ou ont été) durs sur Wikipédia… J'ai déjà relancé il y a 5 jours les demandes commencées.
Comme je suis absent dès samedi, je ne pourrais pas moi-même le publier dans l'éditorial du prochain numéro. Je compte sur mon gentil collègue pour cette mission . Voir discussion. Cordialement. Etiennekd (d) 1 mai 2013 à 17:12 (CEST)
Les couleurs de ce plan sont-elles visibles pour les personnes ayant des difficultés de perception de certaines couleurs ?
Bonjour,
Tout est dans le sujet de cette section.
Voici le plan, loin d'être finalisé. Avis et commentaires bienvenues.
À ce propos je ne comprends pas cette palette. J'ai lu la discussion associée (mais peut-être mal), que je n'avais pas suivie. Évidemment c'est sûrement une très bonne chose qu'une telle palette existe, mais par exemple que signifie la partie "existing wp conventions" ? On n'utilise pourtant pas uniquement ces 6 couleurs sur wp ? Désolé si ma question paraît naïve... et merci à qui voudra bien m'éclairer. Bourrichon2 mai 2013 à 22:43 (CEST)
Tu veux dire que si j'utilise les nuances de la palette, je suis dans la bon car ces couleurs sont vues par tous ? --H2o (d) 3 mai 2013 à 06:09 (CEST)
Je ne peux pas te garantir absolument que tout le monde distinguera bien toutes les couleurs, je ne suis pas expert, tout ce que je sais, c'est que cette palette a été spécialement étudiée pour permettre à un maximum de personne de pouvoir distinguer les couleurs. --M0tty[Plaidoyers et jérémiades]3 mai 2013 à 09:27 (CEST)
Et en plus, cette gamme de couleurs répond parfaitement à ce que j'ai besoin pour le type de plan ci-dessus. Je l'adopte. --H2o (d) 3 mai 2013 à 09:47 (CEST)
J'ai réalisé une nouvelle version (déjà plus complète) avec la palette Tango. Est-ce correcte ainsi ? --H2o (d) 3 mai 2013 à 21:50 (CEST)
Objets invisibles dans Inkscape
Bonjour, ce fichier contient 21 objets mystérieux (une dizaine de Ko, alors q'un fichier vide svg semble faire 4 Ko). Impossible de les faire apparaître, ils ne sont révélés que lorsqu'on fait ctrl+a. Quelqu'un a une idée de ce dont il s'agit ? (PS Ce type d'objets est systématiquement créé lors d'un export svg avec qgis et peuvent se révéler beaucoup plus lourds...). Bourrichon4 mai 2013 à 17:53 (CEST)
Salut Bourrichon, je ne parviens pas à sélectionner (et donc à deviner) les élements que tu évoques, mais je les vois bien dans le code source. Je pense que ce sont des placeholders pour l'emplacement du titre, de la légende et d'autres infos qu'on peut demander à ajouter au SVG lors de la composition d'impression. En effet, j'ai désactivé bon nombre de ces paramètres et j'obtiens un fichier deux fois plus léger que le tien lorsque je fais un export d'un document QGIS vide. --Flappiefh (d) 5 mai 2013 à 20:56 (CEST)
Bonjour à tous. Dans le but de refaire l'AdQ sur Rimogne que je trouve dépassé et incomplet, je cherche à faire un certain nombre de cartes. J'ai du mal à télécharger les fichiers Aster. Est-ce que quelqu'un pourrait m'aider en m'envoyant un fichier dont l'emprise serait centrée sur Rimogne et un autre avec une emprise un peu plus grande ? Merci par avance de votre aide. Tinodela [Tinodici]18 mai 2013 à 07:19 (CEST)
Bonjour, je peux le faire, mais pourquoi ne pas passer par http://gdex.cr.usgs.gov/gdex/ ? Une inscription ("log-in") et hop, il y a juste à entrer les coordonnées de l'emprise à l'aide du bouton "xy". Sinon indique-nous les coordonnées souhaitées, surtout pour l'emprise large. Bourrichon18 mai 2013 à 16:07 (CEST)
Bonjour Bourrichon. Merci de ton aide. Chaque fois que je veux entrer les coordonnées, il me dit que c'est en dehors des cartes (est-ce que je rentre les bonnes informations ?) et quand je parviens à avoir un bout de carte, mon ordi ne veut pas le télécharger... Alors pour Rimogne, les coordonnées sont 49° 50′ 29″ Nord et 4° 32′ 19″ Est. Pour l'emprise large, il me faudrait la partie des Ardennes qui couvre ma commune. Pour le point le plus au sud, ce serait par exemple 49.754654 Nord ,4.552803 Est, le point le plus au nord ce serait par exemple 50.047439 Nord ,4.707642 Est. Est-ce que ça te suffit comme informations ? Encore merci. Tinodela [Tinodici]18 mai 2013 à 17:20 (CEST)
SenseiAC a créé de nombreuses demandes sur l'Atelier Carto concernant des cartes de l'Europe (exemples : Cartes des procédures d'adhésion à l'UE, GDP PPP/capita Europe - carte à mettre à jour, NUTS). Il y demande systématiquement de dessiner l'ensemble des micro-états et autres exceptions (Monaco, Gibraltar, Vatican, Andorre, Monaco, Liechtenstein, Saint-Marin...), car ceux-ci ne sont pas toujours présents à l'image.
A mon avis, nous ne devrions pas accepter d'ajouter les micro-états car :
A la base, si ces micro-états n'apparaissent pas, c'est qu'ils sont trop petits, et que le rendu SVG les a "gommés".
Ces micro-états sont rarement directement concernés par le sujet des images à retravailler (UE, conflits).
Si nous commençons à reprendre toutes les cartes de l'Europe, nous ne finirons sans doute jamais.
Mettre des petits cercles pour qu'on les voit me paraît la meilleure solution. Tu le dis toi-même, "rarement" mais pas "jamais", par exemple ils ont l'euro mais ne sont pas dans l'UE, quoiqu'ils pourraient très bien y adhérer un jour (auquel il faudra bien les faire apparaître non ???), ce n'est donc àma pas très futé qu'ils apparaissent pour le premier mais pas pour le second. Je comprends qu'après il y a énormément de cartes qui ont ce problème, mais n'y a-t-il aucun moyen de faire en sorte que ce puisse être fait automatiquement ?
J'étudie Inkscape depuis quelques temps. J'ai réalisé quelques trucs (voir ci-contre) et c'est clair que je maîtrise pas.
Jusqu'à maintenant, j'avais un problème que je réglais de façon contestable : certains chemins débordant sur d'autres (comme je vais vous le montrer), je mettais les images sur GIMP, en PNG, pour faire un seul de tous les objets, pour ensuite ramener l'image sur Inkscape et la vectorialiser. Jusqu'à aujourd'hui, je m'en contentais. Mais aujourd'hui, cela ne me convient plus : la qualité du fichier est évidemment affectée et c'est de toute manière une sale façon de faire une image vectorielle.
Image en question.
Venons-en à ma question : comment, sans passer par la solution précédemment indiquée, faire que des chemins ne débordent pas sur d'autres, comme ici le texte sur le fond ? Le plus embêtant, c'est que quand j'ai créé l'image, comme toujours, elle était correcte et le débordement n'apparaissait pas.
J'essaierai de corriger le problème moi-même si possible, mais en attendant j'aurais besoin de connaître sa nature.
Bonjour Orikrin, oui c'est très dommage de ne pas avoir toute l'image en svg, notamment le texte (autant faire un png directement). Ce que je fais pour ce bug décrit dans la faq svg : je mets les textes en chemin dans Inkscape (chemin > objet en chemin), après avoir dans la mesure du possible créé un calque non visible contenant le duplicata des textes en textes (une sorte de sauvegarde des textes modifiables). Les textes en chemin alourdissent le fichier mais s'il y en a peu ce n'est pas grave. Une autre solution est de ménager assez de place autour du texte, en prévision du bug. Bourrichon26 juin 2013 à 11:21 (CEST) (PS Un fond opaque serait aussi pas mal pour éviter les petits carreaux du fond transparent ?)
Merci, mais, mon pauvre Bourrichon, je ne comprends rien à ce que tu me racontes.
J'ai la version en anglais, donc le chemin > objet en chemin devrait être path > object to path ? Que cela fait-il quand on clique ?
Je crois que la prochaine fois, je mettrai un espace, car ce n'est pas demain la veille que je serai expert en images vectorielles. Je vais demander une amélioration pour celle-ci (avec 3 ou 4 heures de boulot pour les deux versions, j'y ai déjà passé assez de temps).
Concernant le fond transparent, je pensais que c'était bien...Les carrés sont de toute manière fictifs.
Ne soit pas dépité, je me suis mal exprimé. Je l'ai fait (c'est une opération très rapide, 30 sec.). Regarde le résultat dans le fichier svg en l'ouvrant avec Inkscape. Procédure : 1) sauvegarde des textes pour pouvoir les traduire ou les modifier un jour : j'ai d'abord créé un calque nommé "calque contenant les textes en chemin" (maj+ctrl+n). C'est un calque de sauvegarde des textes. J'ai sélectionné les textes et les ai dupliqués (ctrl+d) et j'ai placé le duplicata dans ce claque de sauvegarde (ctrl+PgUp). Puis j'ai "éteint" ce calque (petit œil en bas à gauche). 2) object to path : dans le calque originel encore visible, sélectionner les textes et faire maj+ctrl+c ou bien effectivement path > object to path. Le problème est réglé. NB : à la place de chaque raccourcis il existe des boutons correspondants. Bourrichon26 juin 2013 à 15:02 (CEST)
Je ne maîtrise pas les calques, pour ne pas dire que je ne sais pas ce que c'est.
Bon, mon état d'esprit n'est pas le bon pour que je cherche objectivement et avec motivation comment ça marche. En revanche, je penserai à relire tes réponses si j'ai à nouveau le problème, et comme tu as spécifié que c'était simple et rapide, j'ai beaucoup moins de scrupules à te demander de « réparer » mon image. <span class="corruption">...S'il te plaît ? </span>
Je l'ai fait tout à l'heure. C'est étrange, je n'arrive pas à purger le cache, le bug apparaît toujours, pourtant ton fichier est bel et bien corrigé quand on le télécharge. Au pire la "réparation" apparaît correctement ici : Fichier:Bourrichon3.svg. Bourrichon26 juin 2013 à 18:23 (CEST)
Est-il possible d'inclure du code SVG directement dans une page wiki ? J'ai fait un test qui n'a pas l'air de fonctionner. --PAC2 (d) 3 juillet 2013 à 07:30 (CEST)
Bonjour. Non, on ne peut pas. D'ailleurs, les images SVG que l'on peut voir sur les articles ou sur Commons ne sont elles-même pas du SVG : elles sont transformées en PNG. C'est à cause de certains vieux navigateurs internet, qui ne savent pas afficher les SVG. Pour voir réellement le fichier SVG, il faut aller sur la page de l'image sur Commons, puis cliquer sur l'image elle-même. Ce qui s'affiche alors est bien le SVG (enfin, si votre navigateur n'est pas trop ancien). Sémhur (d) 3 juillet 2013 à 10:58 (CEST)
Merci pour la réponse.
En fait, je suis en train de donner un nouveau look au portail économie. J'ai fait une première esquisse. Actuellement, on peut cliquer sur les icônes dans le menu de gauche. J'aimerais qu'on puisse tout simplement cliquer sur les barres colorées pour accéder aux autres pages. Le modèle de départ pour les barres colorées utilise des balises <div>. J'ai cru comprendre en allant sur des forums qu'il n'était pas possible de mettre un hyperlien sur un div. Avez-vous une solution pour mettre un lien sur ces barres colorées ? --PAC2 (d) 3 juillet 2013 à 20:53 (CEST)
Sondage - Suppression des « 8 requêtes »
Bonjour.
Aujourd'hui, j'ai réalisé que la section « 8 requêtes » de l'Atelier graphique des images à améliorer était obsolète. Très peu utilisée ces derniers mois par les wikigraphistes et tous les autres utilisateurs, je ne vois pas l'utilité de ces demandes d'améliorations de pages, alors qu'une phrase indiquant un lien vers la catégorie Commons suffirait. La page est un doublon de la sus-page : en effet, si des utilisateurs veulent que nous, wikigraphistes, améliorons un fichier, il fait systématiquement sa demande sur la page WP:AG/I et pas sur celle-ci.
Contre. Pour les mêmes raisons que Flappiefh, qui a bien résumé la chose. Les ateliers graphiques anglo-saxons possèdent des systèmes similaires qui démontrent leur efficience. Ce qui fait que le système n'a pas l'air de fonctionner, c'est que les travaux choisis sont peut-être trop compliqués, et je m'en excuse, c'est moi qui ai longtemps effectué la sélection en fonction de la forte utilisation des images sur les autres projets, peut-être faudrait-il simplement y mettre images nécessitant des modifications plus simples. Cordialement. --M0tty[Plaidoyers et jérémiades]29 juillet 2013 à 19:53 (CEST)
Discussions
Bonjour, cette section a été ajoutée ces dernières années pour effectuer les travaux rébarbatifs tels que la suppression des watermarks, les recadrages, les vectorisations, l'ajout du Sud-Soudan, etc. On peut dire qu'elle a réellement servi puisque la liste dans laquelle elle puise 8 travaux au hasard s'est presque complètement vidée. Je pense que plutôt que de supprimer cette section, nous devrions renflouer la liste. Ceci afin d'éviter qu'on nous soumette un travail de masse en une demande. En effet, ce genre de demande est rarement terminé devant l'ampleur de la tache. Or l'avantage de la section « 8 requêtes » est de permettre un travail à plusieurs au fil de l'eau. Je suis donc contre la suppression. --Flappiefh (d) 29 juillet 2013 à 17:24 (CEST)
Certes, mais les utilisateurs cliquent sur le bouton « Créer ou améliorer une image ou une série d'images » quand ils arrivent sur la page, et ne font pas attention aux 8 requêtes. C'est donc les wikigraphistes qui s'occupent de faire la mise à jour des requêtes (je ne parle pas de l'archivage automatique par le bot, mais de la sélection des images dans la catégorie Commons). La page sert seulement de pense-bête, et c'est encore là où je remets en cause l'utilité de la sous-page. Bien cordialement. Etiennekd (d) 30 juillet 2013 à 00:14 (CEST)
Merci à toi de nous avoir réveillé au sujet de l'outil. Il faut que nous l'alimentions par de nouveaux travaux. Je vais faire un peu de ménage. M0tty, tu dis que tu alimentais l'outil manuellement ? Je croyais qu'il existait un automate pour le choix des images. --Flappiefh (d) 30 juillet 2013 à 17:18 (CEST)
La liste d'attente est maintenue manuellement par mes soins (et par tous ceux qui le souhaitent). Le renouvellement des 8 requêtes et leur archivage est géré par OrlodrimBot. Tout ce qu'on a donc à faire c'est de maintenir une liste d'attente suffisamment grande, attrayante, riche, et à jour (enlever les images traitées par d'autres entre temps, ça arrive souvent). Ce que je fais généralement, c'est de choisir une sous-catégorie de Image for cleanup sur Commons, et de la passer à la moulinette dans Glamorous pour en extraire les images les plus utilisées sur les projets, histoire de proposer d'améliorer des images qui sont utiles, c'est plus motivant. Je vous invite à faire de même, avec les catégories qui vous plaisent ! --M0tty[Plaidoyers et jérémiades]30 juillet 2013 à 23:37 (CEST)
Maroc <> Afrique ?
Bonjour, je suis actuellement en train d'ajouter le Sud-Soudan à toutes ces cartes. Le travail avance vite, mais je viens de remarquer que le Maroc n'est pas coloré comme les autres pays d'Afrique. Y a-t-il une explication logique que je ne m'explique pas ? (on aurait délocalisé le Maroc ?) Si vous partagez mon étonnement, je poserai la question à l'auteur des images. --Flappiefh (d) 1 août 2013 à 17:40 (CEST)
Bonsoir. Tangram, qui vient de rejoindre la communauté des wikigraphistes, me pose une question intéressante au sujet de la Category:Images with borders : doit-on ou non supprimer les bordures des gravures/tableaux ? Et plus généralement, quand peut-on se permettre de supprimer une partie de l'image ? Le débat est ouvert, merci de votre participation ! --Flappiefh (d) 19 août 2013 à 21:17 (CEST)
De façon générale, la règle est de supprimer les cadres et bordures superflues. Il y a en revanche quelques exceptions : Il n'est pas nécessaire d'enlever le cadre de cette peinture par exemple, car il fait partie intégrante de l’œuvre et est d'époque. Mais dans la plupart des cas, les peintures qu'on peut trouver dans les musées n'ont pas conservé leur cadre d'origine, ils sont donc à supprimer. --M0tty[Plaidoyers et jérémiades]19 août 2013 à 23:35 (CEST)
OK, ça a le mérite d'être clair. Et j'imagine que si on croppe par mégarde un cadre d'origine, une âme instruite effectuera un revert dans la semaine... ? --Flappiefh (d) 20 août 2013 à 22:45 (CEST)
Bah, c'est un wiki rien n'est définitivement perdu.
C'est dû au fait que les photographies viennent d'autres sites, et donc que le photographe n'est pas l'importateur du fichier sur Commons. Les cadres étant des objets en trois dimensions, le photographe a des droits d'auteurs sur la façon dont il a pris les cadres. Les supprimer permet d'éliminer ce problème de droits, puisque la Fondation considère qu'une photo d'un objet en deux dimensions (par exemple un tableau) ne crée pas de droit particulier. Sémhur (discuter) 21 août 2013 à 10:28 (CEST)
Bonsoir, je crois que World Gazetteer a perdu son nom de domaine. Du coup, les liens de WP qui y mènent vont ailleurs. Plus grave, j'ai l'impression que certains liens World Gazetteer mènent vers un popup "mettez votre Player à jour" qui fleure bon le phishing (attention de ne pas accepter si vous décidez d'aller voir). Suis-je parano ou faut-il faire quelque chose pour protéger les lecteurs de WP ? --Flappiefh (d) 21 août 2013 à 22:33 (CEST)
Je confirme : les sites de destination sont aléatoires, je viens de tomber sur un site de rencontre. Je propose de temporairement désactiver les liens World Gazetteer de WP, mais je ne sais pas comment faire. J'escalade au Bistro. --Flappiefh (d) 21 août 2013 à 22:42 (CEST)
Les liens vers World Gazetteer ont été temporairement supprimés sur tout WP-fr. Il n'y a plus qu'à attendre de savoir si World Gazetteer reviendra un jour (peut-être sous un autre nom). --Flappiefh (d) 23 août 2013 à 18:21 (CEST)
CropBot
Décidément, je suis bavard ces jours-ci. Je crois que CropBot ne fonctionne plus. Vous confirmez ou c'est juste chez moi ? Je fais tout comme il faut, et une fois validé, je reviens sur la page de Commons, mais ma modification n'apparait pas dans l'historique et l'image n'a pas été modifiée. --Flappiefh (d) 21 août 2013 à 23:10 (CEST)
Les outils du Toolserver vont commencer à fonctionner de moins en moins bien, et seront peut-être remplacés par des outils sur les labs wikimedia. C'est pourquoi beaucoup d'outils ne sont plus maintenus. --M0tty[Plaidoyers et jérémiades]24 août 2013 à 11:51 (CEST)
Est-ce du à une mise à jour progressive du moteur de Commons ? Sais-tu si un atelier de programmation permet de demander l'adaptation des outils ? --Flappiefh (d) 24 août 2013 à 12:42 (CEST)
publication base de données open data Étudiants/formations de l’enseignement supérieur
Cette base de données open data sur les effectifs d’étudiants inscrits dans les établissements et les formations de l’enseignement supérieur 2001-2002 à 2011-2012 (en open data, pourrait être utilisée pour faire divers schémas dans commons et wikipédia (pour article enseignements supérieurs ou certains article relatifs aux mots clé cités ci-dessous), publié par le Ministère de l'Enseignement supérieur et de la Recherche (Département des outils d'aide au pilotage) ; à tous les niveaux géographiques, de la commune jusqu'au national en préservant le secret statistique qui peut s'appliquer à certains croisements ; Niveaux géographiques : national, régions, académies, départements, unités urbaines, communes
mots-clé : ingénieur université éducation enseignement supérieur étudiant formation - effectifs supérieur - classe préparatoire aux grandes écoles - section de technicien supérieur - grand établissement - institut national polytechnique - université de technologie - institut universitaire de formation des maîtres - école normale supérieure - établissement d’enseignement universitaire privé - école de commerce gestion et comptabilité - école juridiques et administratives - école supérieures art et culture - école paramédicales et sociales - institut universitaire de technologie
(avec : descriptif du jeu de données et descriptions des modalités des variables). Si qq'un de compétent en base de données et représentation graphique a le temps de valoriser ca, il est le bienvenu --Lamiot (discuter) 3 septembre 2013 à 12:45 (CEST)
Remplacer une image par son équivalent SVG dans de nombreux articles à la fois
Bonjour,
Je me suis attelé à la vectorisation de cette image. J'ai donc uploadé le SVG résultant, ici sur Commons. Problème : l'image PNG de départ est utilisée des milliers de fois dans les articles, je ne peux donc pas remplacer ses occurrences à la main. Il existe probablement un bot qui sait faire ça mais je ne m'y connais pas assez, j'apprécierais beaucoup un peu d'aide ! Nonoxb (discuter) 1 octobre 2013 à 20:39 (CEST)
Bonjour !
Pour éviter de déclencher une guerre nucléaire, il est interdit de remplacer systématiquement les png par les SVG. Il faut laisser les choses se faire lentement (en signalant sur la page du fichier png qu'il existe une version vectorielle), et il faut laisser les différents sites choisir ce qu'ils préfèrent. C'est pourquoi il n’y a aucun système automatique de remplacement des png vers les svg. Cordialement. --M0tty[Plaidoyers et jérémiades]4 octobre 2013 à 21:57 (CEST)
Bonjour, depuis quelque temps je me bats avec les polices de texte dans Commons. J'ai lu que la police à utiliser par défaut est DejaVu mais j'ai des problèmes avec ça. En effet la transformation en PNG dans Commons ne marche pas très bien. Vous pouvez voir cela sur le modele. Le texte MASSIF MONTAGNEUX p.ex. est en DejaVu Serif mais il s'affiche sans-serif sur l'image PNG. En plus, quand je vérifie le SVG sur le SVG checker j'ai des messages d'erreur qui indiquent qu'une police de base doit être indiquée mais je ne peut pas faire cela avec Inkscape. Est-ce que quelqu'un a des observations sur cela? Est-ce que si je ne laisse que la police de base type serif/sans-serif est une bonne idée? Merci--Ikonact (discuter) 4 octobre 2013 à 21:17 (CEST)
Merci. Le modèle pour les cartes recommande la police DejaVu. Je peux utiliser Nimbus Sans L mais c'est une police "sans serif". Et pour les textes "serif" qu'est-ce que vous faites? --Ikonact (discuter) 4 octobre 2013 à 22:32 (CEST)
Petite précision, pour les cartes on recommande la DejaVu Sans Condensed (ou SejaVu Serif Condensed). Si tu prends celle qui n'est pas Condensed, le rendu n'est pas bon. Mais de toute façon, j'utilise aussi la Nimbus Sans L. Tu peux la trouver en lisant la FAQ SVG. Sémhur (discuter) 5 octobre 2013 à 20:12 (CEST)
Oui, justement, sur le modèle la police DejaVu Condensed ne marche pas bien. Regardez le texte Massif Montagneux. Il est DejaVu Serif Condensed mais sur le PNG le texte est sans-serif. --Ikonact (discuter) 7 octobre 2013 à 11:14 (CEST)
Demande de financement WMF pour système Wikimaps !
Bonjour la tribut, en:User:Planemad et moi même (meta:user:Yug) avons monté un projet pour coder un système qui génère des cartes administratives et topographiques pour l'ensemble des pays et provinces du monde (niveau GIS L0, L1, et peut-être L2). Planemad est un jeune indien et un dinosaure de la cartographie sur Wikipedia, c'est lui qui à créé la première boite à outils SVG pour le projet India, sur wiki-en, avec comme modèle les cartes de la CIA (World fact book). Abandonnant volontairement les couleurs de la CIA, STyx, puis Sting, Sémhur, Bourrichon, et moi-même avons créé la palette concurrente grise qui est aujourd'hui la norme. J'ai rencontré Planemad en Mai 2013 au Amsterdam Hackathon 2013, il est très visuel, ~26 ans, nous avons rapidement collaboré à la création d'une carte SVG multilingue connectée à wikidata (voir ici). Comme mon doctorat de chinois et e-learning me pousse vers la programmation web, j'ai consacré Aout à explorer la possibilité d'automatiser la génération de nos fonds de cartes administratifs et reliefs. Démos et objectifs: Ça devait me prendre 4 jours, ça ma pris un mois. J'ai désormais : une liste de "cadres géographiques" (WNES bounding box), 2 styles en démonstrations "fonctionnelles" (voir ici), une approche solide (makefile>gdal>geojson>Topojson>D3js>SVG), un projet bien définit, et une demande de financement sur Méta. Le projet est trop lourd pour du temps libre. On demande donc 10 500 US$ (~6800€) ce qui nous permettra de nous consacré à plein temps durant 3 mois à ACHEVER! ce système dont on rêve depuis des années.
Le système sera centralisé, ce qui permettra de mettre à jour TOUTES les cartes _location_map / relief_location_maps d'un coup (cf south sudan !), le fond (shapes) et le styles (convention) sera enfin centralisé et gérable.
Les SVG seront codés de manière stricte et régulière, ouvrant la voie à la création massive de cartes interactives.
Pour les entités historiques, les graphistes que nous sommes pourrons soumettre un titre de carte et des géocoordonnées WNES (West, North, East, South) pour obtenir en quelque minute le fond de carte _location_map / relief_location_map
Le code sera ouvert, et sera donc une base. Un hack d'un à 3 jours en fin de chaine de traitement devrait permettre la génération d'alternatives :
ajout de données GIS type aire d'occupation d'un animal, etc.
Astuces et philosophie: Je tiens à garder ce projet près des graphistes, près des ateliers, et près de nos pratiques réelles de création cartographique. C'est le design à la main des wikicartographes qui sert de modèle à ce projet. On crée un sytème centralisé, mais aussi avec des technologies accessibles afin que les cartographes que nous sommes puissions "bidouiller" le code avec succès pour créer des résultats alternatifs. Les SVG garderons en mémoire les géocordonnées de leur cadre géographique. Il serait donc possible de récupérer un SVG avec ses calques sémantiques, et de réinjecter ces calques dans un GIS type Sharemap / OSM en récupérant la géoloc. Coté finance, je suis désolé de demander des fonds, mais c'est le meilleur moyen pour que le projet soit vraiment réalisé, alors allons vers ce financement. Le projet est solide, ambitieux, faisable à court terme (mi-2014), souple et pourra s'adapter aux changements à venir. La WMF à les fonds pour soutenir le projet, allons y! Soutiens: Nous sommes en compétition avec d'autres projets, aussi, votre soutien est souhaitable dans la section #Endorsments. Les jurys cherchent en particulier à savoir si le projet va faciliter la vie aux autres wikipedédiens : les cartographes et graphistes d'abords, mais aussi les éditeurs d'articles (de qualités). Les cartes svg pourront également être réutilisées par des développeurs externes, de sites et d'Apps.
Vos questions et commentaires sont les bienvenues. Yug(talk) 11:42, 19 October 2013 (UTC)
locator_map: USA_location_map + focus and red on Hawaii (2009 guidelines)
location_map (2009 guidelines)
relief_location_map
_(orthographic_projection).svg
_location_map.svg (2009 guidelines)
_locator_map.svg : India_location_map + focus and red on Maharashtra (2009 scheme)
_relief_location_map
Note: Je fais ma rentrée en doctorat 2ème année, licence 2 et licence 3 d'informatique appliqué aux langues, d'où la notification tardive. La quinzaine a été très chargée. Toutes mes excuses. Les soutiens sur Meta sont acceptés jusqu'au 22 Octobre inclus. La discussion ici est ouverte sans limite de temps. Je suis en particulier à la recherche de commandes gdal permettant la génération de reliefs ombrés élégant. Yug(talk)19 octobre 2013 à 18:01 (CEST)
Commentaires allemands et limites du projet
Les allemands (NNW) sont plus secs avec le projet, ils ont raison ! Ce projet seul est partiel, il faudra d'autres modules, notament pour amélioré la qualité de nos sources GIS et de leur code. NaturalEarth#rivières et lakes c'est moyen ! Comment intégrer OSM par couche, etc. Si possible, soutenez également la demande de financement de http://Sharemap.org (meta:Grants:IEG/ShareMap#Endorsements:) Yug(talk)22 octobre 2013 à 22:53 (CEST)
Chuwma, de l'atelier Allemand, m'a fait suivre le lien de la discussion des cartographes allemands sur le projet. Ils balancent franchement sur les limitations du projet : la qualité imparfaite des GIS source implique nécessairement de nombreuses retouches (correction) et le réalignement des calques topographique / administratif. Je n'ai pas encore répondu, mais ce sont des soucis connus, des allemands, et de nous mêmes (cartographes FR et acteurs du projet). Chumwa réponds vers la fin que sans être parfait, l'outils simplifierait déjà l'accès à la coartographie GIS qui reste jusqu'à présent difficil d'entrée. La qualitédes SVG suivra ensuite, évidemment, celle des sources GIS qui va en s'améliorant.
En plus court: je suis contrarié, Planemad et moi allons nous prendre des critiques, mais c'est du connu, on fera au mieux pour maitriser ces difficulter et se baser sur un jeu de GIS cohérents. Yug(talk)10 novembre 2013 à 19:17 (CET)
Je ne vois pas où est le problème : on utilise déjà tous ces GIS imparfaits. L'aspect dynamique de l'outil voulu est justement ce qui permettrait d'améliorer toutes nos cartes d'un seul coup plutôt que carte après carte... non ? --Flappiefh (d) 12 novembre 2013 à 18:02 (CET)
Plus sérieusement, les points qu'ils soulèvent sont exacts, avec un focus sur les faiblesses du projet. Il faut bien comprendre que les Location_maps, c'est vraiment leur bébé, leur projet. NNW, TUBS, Uwe Dedering, Chumwa ont passé un temps fou sur ce projet, à améliorer nos conventions, accumuler un savoir faire, le transmettre, à dessiner les 200 pays du monde en corrigeant les sources GIS dans les SVG. Ils ont vraiment fait un travail impressionnant, et depuis peu s'attaquent aux provinces de différents pays. Le Wiki Atlas project à pour vocation de refaire en un tour de script tous ceci... en moins bien ! On va perdre toutes leurs nombreuses retouches.* Pour te reprendre : "L'aspect dynamique de l'outil est justement ce qui permettrait d'améliorer toutes nos cartes d'un seul coup plutôt que carte après carte..."si nos sources GIS sont meilleurs que leurs retouches SVG! Ce dont je doute. (*) Notre production sera par contre plus vaste —plus de provinces— et mieux codé —de manière systématique, cool pour wikidata et des cartes interactives—. Yug(talk)12 novembre 2013 à 23:09 (CET)
Merci pour ces précisions, mais de quelles corrections GIS parles-tu ? Est-ce que ça veut dire que toutes les cartes que j'ai réalisées depuis le début comportent un tas d'erreurs ? --Flappiefh (d) 12 novembre 2013 à 23:16 (CET)
Un premier cas est celui de zones type Pays-bas, en dessous du niveau de la mer, qu'un script simpliste considèrera comme une surface 50% maritime. Pour ceci on prévoit un match avec un calque administratif (gadm). Coté précision, Bourrichon à fait une image qui compare plusieurs resources topographiques GIS, on y voit bien les erreurs pour les cartes de petites zones. Les satelites font des mesures approximatives, et chaque mission rapporte des resultats légèrement différents. Il y a également des décallages fréquents entre couches, du coup, la frontière (GIS administratif, NaturalEarth) passe pas sur le pic du mont blanc (GIS relief, NASA). Il peut y avoir quelques dizaines de metres, ou un km de différence. Sur la carte de la France c'est invisible, mais sur une carte du département ça apparaitrait. Pareil pour les rivières, qui peuvent se retrouver décallées comparée à leurs lits. Tu as compris l'idée. C'est plein de petites erreurs du fait de l'imprecision des sources GIS, et de leur non-synchronie, ou du fait de l'action humaine : digue, immeubles. Plus on attaque des zones géographiques petites, plus il faut des sources GIS précises et synchronisées. Nos cartes ont, oui, des erreurs, mais généralement minimes étant donnée que l'on travail le plus souvent sur de grandes aires. Pour les zones plus petites (département ou inférieur), il est nécessaire soit de faire un verification finale (Inkscape) et syncrhoniser ce que l'on peut : vallées, rivières, frontières et crètes. Soit de pousser vers des sources plus précises, type OSM (mais les polygones y sont très fragmentés), où toutes les couches hydro, routières, admin, se base sur une image raster satelite de Bing.... qui peut elle même etre décallée . C'est pour ça que quand j'importe des rivières de OSM, ça colle pas avec mon relief ETOPO. Ce qu'est bien, c'est qu'en regardant ça, on se dit vraiment que la NASA, l'ESA, ont encore des progrès à faire, et qu'on est vraiment collé à leurs fesses ! La grande classe Yug(talk)13 novembre 2013 à 00:39 (CET)
L'idée est qu'avec un système semi-automatique, au moins, on évolura avec les sources, et on n'aura pas à tout refaire à la main à chaque fois. Yug(talk)13 novembre 2013 à 00:41 (CET)
Je pensais qu'il s'agissait d'erreurs plus flagrantes ! Mais effectivement, si on se contente d'utiliser les données GIS existantes pour automatiser nos cartes, on peut avoir des problèmes. Récemment, en faisant la carte de Tahiti et Moorea, j'ai rencontré ce souci : les sources GIS de la NASA donnent un trou à la place d'un mont. J'ai fini par dégotter des sources GIS corrigées. Mais si les données de la NASA posent problème, et que les allemands s'attachent à corriger tout ça, pourquoi ne pas partir sur nos propres GIS corrigés ? --Flappiefh (d) 14 novembre 2013 à 18:09 (CET)
Novembre 15: le commité a publié son évaluation, Wiki Atlas est un bon élève de cette session, avec un score global de 4.2/5. Sharemaps, avec 3.85/5, est un autre bon élève. La plupart des projets obtiennes entre 2.8 et 3.5/5.
Novembre 28: Siko Bouterse (WMF) a demandé aux membres du projet leurs disponibilités pour une interview Skype / Google hangout.
Je continue à vous tenir au courant sur les étapes histoire que ces projets IEG nous deviennent relativement connus. Ca pourrait être à nouveau utile en 2014-15 Yug(talk)28 novembre 2013 à 21:09 (CET)
ShareMap - Wikimedia grant - community feedback needed (sorry for writing in english)
Hi members of Atelier graphique,
ShareMap is a collaborative map creation tool and is currently applying for Wikimedia grant to continue project development.
There is aleready dozens of maps created with ShareMap, you can see them all here:
We will be very happy for endorsement, opinions or even criticism from all community members on Wikimedia grant project.
The ShareMap idead is perfectly coordinated with other project requesting for grant meta:Grants:IEG/Wikimaps_Atlas. All Wikimaps Atlas scripts and practices can be easile reused within data generated from ShareMap to generate pixel perfect map from user contributions.
Both the Wikimaps and Sharemaps grant requests are coordinated. Wikimaps are for short term, stand alone maps, which perfectly fit in current wikipedia cartographers' practices. Sharemap is actually a long term, but more powerful cloud approach, which is the future of in-wikipedia map making. Both initiatives may also eventually merge, thus recycling hundreds high quality SVG maps. Most importantly for now, both initiative need your support. Yug
N'étant pas Wikigraphiste, je poste ici la correction que je propose pour la requête concernant la carte de Montbéliard (demande d'éclaircissement). Si ça peut vous avancer, ça me fait réviser^^
Il n'y a pas de poste officiel de wikigraphiste ! Pour le devenir, il suffit de faire une proposition pour répondre à une demande, ce que tu viens de faire ici.
Bienvenue donc à toi dans l'atelier. J'y ai mis ta proposition ; la prochaine fois, n'hésite pas à l'y déposer toi-même.
Pour être clair, il y a un moment que j'avais envie de venir traîner mes guêtres dans le secteur. Le « truc », c'est que je commence seulement à appréhender le fonctionnement de l'atelier, alors je préfère faire attention avec mes gros sabots...
Bon, content de vous rejoindre. Je n'ai pas nécessairement beaucoup de temps de disponible, mais je serai content de venir prêter main forte.
Deux points importants :
je suis une quiche d'envergure internationale en imagerie vectorielle. Je me débrouille vaguement, mais c'est mon pote Adobe Illustrator qui fait 99% du boulot, je me devais de le préciser. (en gros, si je ne trouve pas la commande Fichier -> Faire pile-poil ce dont Heddryin a besoin, je panique)
je suis un utilisateur du système d'exploitation à fenêtres, pas la peine de me parler de Linux : même sous la torture, je pense que je n'y comprendrais rien.
j'utilise le grand frère d'Illustrator, Adobe Photoshop CS5.5, pour le reste de mes travaux d'imagerie.
je sais, on a dépassé les deux points importants, mais quand on aime, on ne compte pas^^
Bonjour Heddryin, L'atelier est conçu depuis le départ comme une école, ou comme un forum. Poster une retouche de carte/image en réponse à une requête c'est la montrer aux autres wikipediens graphistes pour obtenir des commentaires et astuces. Tu peux également exposer les problèmes auxquels tu fais face ou les astuces que tu as improvisées. On sera heureux de partager nos astuces et de donner un coup de pouce pour des étapes particulières. Yug(talk)28 novembre 2013 à 21:16 (CET)
Salut Yug,
Merci beaucoup pour ton explication Commentaires et astuces seront toujours les bienvenus : personne n'est parfait, moi pas plus que les autres^^ Et si quelqu'un a la bonne solution, je ne vois effectivement pas l'intérêt de réinventer la roue tous les deux jours^^
En fait, quand je dis que je suis une quiche en vectoriel, c'est avant tout parce que j'ai du mal à m'y intéresser. La flemme, je pense, de devoir apprendre plein de nouvelles choses^^
Je serai en tous les cas heureux ici, je pense : aider et être aidé, c'est pile ce que j'aime.
Il semble que ImageMagic et MediaWiki gèrent à présent la balise SVG switch. User:Verdy_p-l'Énergique semble avoir surveillé l'affaire. La fonction est cool ! cela permettrait enfin d'éviter la duplication des fonds de cartes. J'ai encore du mal à voir l'impact réel pour l'atelier, et comment gérer cette nouvelle fonction lors de la production de nos SVG, lors de leur intégration aux articles, et lors de leurs édition. Yug(talk)6 décembre 2013 à 22:09 (CET)
Waw ! ça veut dire une seule carte désormais pour toutes les langues ! voilà qui est vraiment révolutionnaire, ça va en faire des fusions de cartes à gérer sur Commons désormais ! --M0tty[Plaidoyers et jérémiades]6 décembre 2013 à 23:49 (CET)
SVGtranslate tool: Je me demande aussi les implications pour le modèle {translate}, qui nous aide (lorsqu'il fonctionne) à créer des SVG dérivés dans une langue cible.
Wikimaps Atlas: pareil, quelles implications pour Wikimaps Atlas. Note: le projet a été oralement approuvé, confirmation écrite/officielle à venir. Yug(talk)7 décembre 2013 à 15:22 (CET)
Il va falloir harmoniser tout ça et se mettre d'accord avec les autres ateliers (je pense particulièrement aux allemands et anglais qui sont très actifs). Autre chose auxquelles il faudra être attentif, la place des textes dans les schémas, comme dans l'exemple ci dessous, le black et le schwarz ne sont pas à la même place.
Autre problème, je n'arrive pas à afficher le texte allemand dans Inkscape, je pensais que c'était sur un autre calque, mais il n'en est rien. Il faut l'afficher dans un éditeur de texte, mais le code est imbuvable ! une idée ??? --M0tty[Plaidoyers et jérémiades]7 décembre 2013 à 18:37 (CET)
Police, Incskape et import sur commons
Bonjour, je vous contacte suite à une demande de A.BourgeoisP concernant une carte que j'avais fait l'an dernier sur les Houillières de Ronchamp. Il souhaiterait que je la passe en svg (et je souhaiterais au passage changer les symboles des puits, plus conformes à wiki).
Problème, lors de l'import sur Commons, les polices s'affichent très mal, on ne voit même plus le fond de carte représentant les concessions minières.
J'ai encore du mal avec l'export en svg. Sur une autre carte, c'est l'orientation des flèches qui par en vrille lors de l'import.
Enfin, voila quelques détails qui me bloquent dans mes travaux, alors que le SVG devient la norme sur wiki. --Boldair (discuter) 14 décembre 2013 à 17:44 (CET)
Effectivement, tu as besoin d'aide dans l'utilisation de Inkscape. N'y voit aucun reproche, j'ai également été débutant dans l'utilisation du logiciel. Vois si Aide:SVG et son paragraphe consacré à Inkscape t'es utile. Je ne vois aucun calque. Comment as-tu créer ton dessin ? --H2O(discuter)14 décembre 2013 à 18:01 (CET)
Bonjour, la FAQ SVG est faite pour toi ! En particulier les sections « Un carré noir est visible sur l'image » (pour résoudre le problème du fond qui a disparu), « La police de caractère n'est pas celle utilisée » (pour résoudre le problème des polices), et « Les flèches ne s'affichent pas correctement » (pour les flèches). Sémhur (discuter) 14 décembre 2013 à 18:28 (CET)
_(US50)_(-grid).svg)
.svg)
.svg)
.png){kind=link}
,_ceiling_fresco_in_the_Camera_dei_Papiri,_Vatican_Library,_1772_-_M0tty.jpg){kind=link}
2.png){kind=link}
