Encore quelques réponses en vrac, j'évite ce qui me semble hors-sujet :
- Vectoriel : Maperitive permet de sortir des fichiers vectoriels. Ce
que j'essayais de dire, c'est que ce n'est pas forcément une solution
facile pour le post-traitement des images.
- Maperitive/Mapnik : l'intérêt de Mapnik n'est pas dans la qualité de
l'export vectoriel. C'est plus sur la richesse de la chaine de travail,
notamment avec la puissance de PostGis. Mais avec un peu de scriptage,
on peut rattraper une partie du retard, voir ce que j'ai sorti
dernièrement sur l'orientation des barrières, cascades et autres.
- Maperitive/Mapnik bis : Maperitive permet comme Mapnik de sortir des
résolutions élevées (jusqu'à une certaine limite de gestion du fichier
image par .NET, que je n'ai jamais atteinte).
- Résolution et taille des textes et des icônes : c'est un grand
hors-sujet : on parle de résolution de sortie, et non d'échelle. À
grande résolution, un caractère fait 10 pixels à la place de 5, mais
fait toujours 5mm de hauteur. (Par contre, les icônes que j'utilise et
que j'ai pour la plupart créées moi-même n'ont pas forcément une
résolution phénoménale… à voir s'il faut les retravailler.)
- Post-traitement du SVG, pré-traitement des données ou… gestion
manuelle des éléments : ma (petite) expérience, c'est que sur une zone
définie, pour un résultat très propre, tout ne pourra pas être géré
automatiquement pour la position de textes, icône, ou autres. La
solution de post-traitement de l'image est possible, mais je pense
qu'une gestion intermédiaire d'adaptation de la feuille de style « à la
main » est une bonne solution. On gagne la propreté, on perd
l'automatisation.
Après, il faut entrer dans le concret pour en dire plus.
JB.
Le 01/05/2016 à 16:06, Christian Quest a écrit :
Il est possible de positionner ce qu'on veut là où l'on veut... tout
dépend du pré-processing qu'on fait sur les données.
Par défaut le placement est relativement basique, le moteur de rendu
n'a pas connaissance que le polygone gris est en fait un bâtiment et
qu'on voudrait que le texte aille par là un peu plus tard quand on
arrivera à cette couche du rendu.
On peut faire des trucs dingues en pré-processant, mais c'est pas
"plug and play".
Le 1 mai 2016 à 15:12, Valentin Surrel <openstreet...@surrel.org
<mailto:openstreet...@surrel.org>> a écrit :
Inkscape c'était plus pour le post-processing (éventuellement
déplacer 2-3 éléments de carto et ajouter les données propres à
l'office du tourisme). Il y a peut-être des logiciels plus adaptés
mais je ne connais pas trop cette partie.
J'essayerai éventuellement Mapnik en high-res mais en fait y'a pas
de stylesheet qui correspondent à mon besoin vu que Opencyclemap &
cie ont tout gardé fermé...
Par ailleurs j'ai une question, j'ai pas encore creusé mais
peut-être sais tu d'ores et déjà la réponse : est-il possible avec
Maperitive de positionner les nom de manière plus intelligente ?
(ie. pas juste au dessus du point, mais par exemple en bordure de
90% du bâti)
Le 2016-05-01 12:51, JB a écrit :
- Point vectoriel : les retours que j'ai de mapnik indiquent des
fichiers très difficilement utilisables. Maperitive semble
faire un
peu mieux. De mon coté, le petit imprimeur avec qui j'avais
bossé une
petite fois me disait qu'au-dessus de 300-400dpi (natif au
format), il
n'avait pas forcément d'intérêt à passer au vectoriel (par
contre, il
a des clients qui récupèrent une image sur internet et la
modifient
pour arriver à 300dpi… et arrivent avec un fichier qui fait 3 ou 4
centimètres de coté). Du coup, je t'encourage de regarder ce
que ça
peut donner sous Inkscape, je suis intéressé par tes retours.
(Et au
fait, quels travail vas-tu faire sous Inkscape ?)
- Malgré la libération de .NET par Microsoft, les bibliothèques
graphiques n'avaient pas encore été intégrées par Mono. Je ne
sais pas
si ça a évolué, mais les exports sous Linux étaient d'assez
mauvaise
qualité sur les rendus de couleurs et de transparences (voir
notamment
les éléments rouges touristiques).
- Quelqu'un avait abordé l'idée de passer R25 en CSS, je lui
avais dit
que j'étais curieux du boulot que ça donnerait mais le projet
semble
avoir été abandonné depuis longtemps. R25, c'est actuellement
plus de
5000 lignes, sous une syntaxe très différente du CSS… donc du
boulot,
du boulot. L'idée avait été évoquée de monter un petit serveur
pour
produire des cartes à la demande, mais comme je n'ai pas les
compétences et qu'on n'avait pas monté d'équipe, c'est resté
au stade
de l'idée. (Et de mon coté, je ne coderai pas le style en
carto-CSS
pour diverses raisons).
JB.
Le 01/05/2016 à 09:49, Valentin Surrel a écrit :
Bonjour,
Mes réponses suite à vos 2 mails et avoir joué une petite
heure avec Maperitive/R25.
- je tiens au rendu vectoriel, on va travailler avec un
imprimeur et par expérience (certe minuscule mais
expérience quand même) ils préfèrent largement le
vectoriel pour un bon rendu, surtout en A2.
- J'ai réussi un "export-svg" avec Maperitive, çela semble
donc bon. Pourquoi JB tu ne parles que de l'export haute
résolution ? Je n'ai pas encore joué avec ce SVG sous
Inkscape toutefois.
- Pourquoi c'est mieux sous Windows ? C'est connu que le
rendu Maperitive est meilleur sous Windows ? Car dans
l'idée ma chaîne de production serait sur des serveurs
sous Linux complètement automatisé. Et accessoirement je
n'ai aucun Windows... Mais bon si ca devient un pré-requis
je partirai la dessus quand même, vu que le thème R25
semble correspondre parfaitement à mes besoins.
Et question d'ordre plus général, vu la qualité du thème
R25, pourquoi personne n'a jamais été intéressé pour le
mettre en thème Mapnik ou CartoCSS ou autre ?
Bonne journée,
Valentin
Le 2016-05-01 00:24, Philippe Verdy a écrit :
L'export à forte résolution peut marcher, mais il faut
que le rendu
utilise des tailles de police adaptées (et pas
calculées pour un
affichage à l'écran: la réduction d'échelle une fois
imprimé
rendra ce texte illisible).
C'est faisable mais ça demande des tailles de bitmap
très élevées,
et il faut connaitre la résolution effective
d'impression (qui varie
selon le dispositif). De plus les techniques de jet
d'encre ont des
méthodes spécifiques de placement des pixels et de
redistribution
des gouttes (qui sont en fait de taille variable pour
couvrir plus ou
moins les "pixels" théorique au centre des desquels on les
gouttelettes sont projetées. Mais avec une impression
d'image en
résolution élevée, l'algo de placement optimal pour le
texte ne
marche plus, c'est l'algo "photographique qui est
utilisé et on
obtient un texte diffiocilement lisible.
Bref pour imprimer corectement il vaut mieux un rendu
vectoriel (à
partir duquel les "masques" de positionnement (et de
recouvrement
éventuel) des encres pourront être plus idéalement
placés (une
imprimante couleur ne fonctionne pas du tout avec une
matrice fixe
comme un écran, surtout en jet d'encre, les
"sous-pixels" de l'écran
sont beaucoup plus simples, et surtout ils ont une
gamme plus étendue
en colorimétrie alors que les encres sont de couleur
fixe et on ne
peut jouer que sur la taille des gouttelettes).
En rendu sur laser c'est plus délicat d'avoir de
belles couleurs, les
particules sont de taille à peu près constante (mlais
ne peuvent pas
se recouvrir partiellement come avec l'encre. On a
donc des matrices
similaires à l'écran, mais les sous-pixels doivent
être extrêment
fins pour compenser la gamme plus réduite, et alors se
pose le
problème de cette résolution élevée sur des surfaces
très grandes
: les tailles de bitmap sont considérablement plus
grandes.
Là encore le rendu vectoriel par par le dispositif
d'impression sera
bien meilleur (et nettement plus performant).
Je connais peu d'imprimantes qui soient capable d'imprimer
correctement du texte rendu avec des tailles de
polices réduites à
partir d'une bitmap sans rendre ce texte souvent illisible
(l'intelligence du pilote d'impression peut cependant
compenser en
partie cette adaptation, mais le pilote se débrouille
beaucoup mieux
avec une source vectorielle).
Le 30 avril 2016 à 23:50, JB <jb...@mailoo.org
<mailto:jb...@mailoo.org>> a écrit :
Salut Valentin,
Quelques questions :
- est-ce qu'un export à forte résolution est
envisageable à la
place d'une sortie vectorielle ? (même s'il la
plupart des retours
sont que les sorties vectorielles sont souvent
plus foireuses que ce
qu'on voudrait croire…)
- est-ce que l'emploi d'un logiciel gratuit non
libre est
envisageable (en plus, qui tourne mieux sous
Windows…) ?
- est-ce qu'il faut une solution prête à l'emploi,
ou est-ce
qu'un peu de bidouille est prévue ?
Selon tes réponses, R25 est éventuellement une
solution parmi
d'autres. Tu peux jeter un coup d'œil là :
http://jb.isonoe.net/CR/demo/Volcans_2016.pdf, là :
http://jb.isonoe.net/temp/Chemin_des_Arts.png ou
encore là :
http://jb.isonoe.net/temp/Samoens_ent.png. En Avec
légende, par
exemple ici :
http://jb.isonoe.net/temp/Base_affiche_osm_paysage_A0_300_Moselle_V2.png.
(Pas forcément tous à jour, mais ça peut te donner
une idée.)
Voilà voilà,
JB.
Le 30/04/2016 à 22:01, Valentin Surrel a écrit :
Bonsoir la liste,
Je reviens sur la liste après plusieurs années
d'absence, non
pas par manque d'intérêt pour le projet mais
par faute de temps.
Je suis de nouveau un peu plus libre
professionnellement, je me
relance donc un peu plus dans le projet OSM...
en constatant que
beaucoup de choses ont évolué depuis !!
J'ai donc pour projet d'aider une communauté
de communes de
moyenne montagne d'éditer des cartes (papier)
de sentiers de
rando du coin pour chacune des communes. A ce
jour, seule une
feuille A4 recto-verso 100% textuelle (en
Comic Sans MS qui plus
est) est à disposition des touristes pour les
guider sur ces
sentiers, à moitié à l'aveugle donc.
Je veux donc leur proposer un .pdf vectoriel à
imprimer qui
comprend un fond de carte OSM avec en overlay
les N sentiers de
rando, avec sur les bords de la carte une
légende et un petit
topo de chaque rando.
Je me suis fixé les contraintes suivantes :
- fond de carte facilement updatable, et
surtout le plus
simplement possible (ie. un script bash qui
télécharge un
export, le traite, et update le fichier
précédent (que celui-ci
servent d'input mapnik, de layer QGIS ou autre)
- 100% vectoriel (pour une belle impression
sur A3 voire A2 plié)
- ajouter un overlay propre à la commune (les
N sentiers de
chacune des communes qu'ont tracé les offices
de tourisme). Les
sentiers sont présents sur OSM ou seront
rajoutés, mais les
circuits seront tracés par dessus en fonction
des envies des
offices de tourisme.
- rendu "sympa" avec courbes de niveau (style
francetopo,
opencyclemap, mapquest ouverte...)
- échelle proche 1:25000
J'essaye de dresser l'éventail de solutions
techniques possibles.
Celles ci ont bien évoluées ces années, et
j'ai peur de louper
des "nouveautés", j'en ai isolé que 2 crédibles :
- Mapnik avec export SVG, pour inclure ça dans
Inkscape pour
ajouter les overlay spécifique. Surement la
solution la plus
simple pour utiliser un thème existant (encore
que j'ai
l'impression que francetopo, opencyclemap et
compagnie ne publient
pas leurs themes...)
- QGIS avec l'export OSM (en ESRI) et partir
sur un theme existant
(ex :
https://github.com/charleyglynn/OSM-Shapefile-QGIS-stylesheets).
Par contre j'ai l'impression que le bâti ne
fait pas parti des
exports ESRI geofabrik...
(maposmatik même si c'est un truc que j'adore
ne répond pas trop
aux contraintes)
Je suis dans une démarche ouverte (ie. tout
dispo sur github),
l'idée est de pouvoir avec un minimum de
travail pouvoir itérer
le projet dans d'autres syndicats
d'initiative, cela permet
d'afficher le projet OSM indirectement à un
maximum de monde.
Qu'en pensez vous ? Certains ont ils déjà mené
des projets
similaires ? avez-vous des idées autres
(logiciel/thèmes/...)
que je puisse creuser ? avez-vous des bonnes
adresses de thèmes
ouverts ?
Merci à tous !
Valentin
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
<mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org <mailto:Talk-fr@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/talk-fr
--
Christian Quest - OpenStreetMap France
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
_______________________________________________
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr
