Bonjour,
Dans la région toulousaine, nous disposons d'une orthophoto de belle
facture (12cm de résolution) sous licence ODBL
Cette image est disponible et utilisable directement dans JOSM. c'est
parfait.
Maintenant si je me place plus d'un point de vue utilisateur, quand je
regarde une carte
Il y a si peu de vue aérienne sous licence libre, un tel overlay sur
une carte globale serait sûrement décevant.
Il est par contre facile de mettre en place une carte limitée dans
l'espace et proposant ce type d'overlay en utilisant par exemple
Leaflet: http://leafletjs.com/
C'est juste une page
Bonjour,
Pour Toulouse, on peut déjà passer d'une vue à l'autre (des orthophotos
2011 et 2007 aux quatre rendus standard et à celui en occitan de
PAULLA) sur :
http://wms.openstreetmap.fr/toulouse
(comme cela avait déjà été signalé sur cette liste).
Pour Tours, Cyrille avait rendu les images
Je crois que tu ne connais pas le sens du mot orthogonal. Car si c'était
réellement orthogonal, ce critère de niveau serait utilisable **seul**
comme critère de sélection sans avoir jamais à la lier à un autre critère,
pour obtenir une liste d'éléments homogène. Ce qui n'est évidemment pas le
cas,
Je viens de proposer une présentation autour de l'accessibilité
comprenant intitulée OSM and accessibility: beyond wheelchair=*
Le contenu que j'envisage (en vrac):
- rappel de l'existant (wheelmap)
- les différentes formes de handicap (utilisation de données OSM en
rapport avec d'autres sens que
Le pseudo département de L'Epte sur layers a disparu.
Le diagnostic était donc bon ;)
--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
Voilà la dernière évolution du rendu des réserves naturelles (les
tuiles sont en cours de régénération car ça impacte à partir du zoom
10):
http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F
--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM...
Le 09/06/2013 10:15, Christian Quest a écrit :
Le pseudo département de L'Epte sur layers a disparu.
Le diagnostic était donc bon ;)
Bien vu :-)
Bon dimanche orthogonal,
vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
Bravo pour avoir retenu mon idée. C'est superbe, très lisible, tous les
détails dans la réserve sont enfin visibles.
Le 9 juin 2013 10:31, Christian Quest cqu...@openstreetmap.fr a écrit :
Voilà la dernière évolution du rendu des réserves naturelles (les
tuiles sont en cours de régénération
apparemment cela ne marche qu'à partir du niveau 12, au niveau 10 ou 11
c'est encore l'ancien rendu
Le 9 juin 2013 10:31, Christian Quest cqu...@openstreetmap.fr a écrit :
Voilà la dernière évolution du rendu des réserves naturelles (les
tuiles sont en cours de régénération car ça impacte à
il y a un problème avec le Golfe du Morbihan (moitié est utilisant le
nouveau rendu, moitié ouest non, avec une limite verticale visible, au
niveau 11, mais pas au niveau 12)
Le 9 juin 2013 10:31, Christian Quest cqu...@openstreetmap.fr a écrit :
Voilà la dernière évolution du rendu des
Philippe:
(les tuiles sont *en cours de régénération* car ça impacte à partir
du zoom 10)
So, patience...
Yohan
On 06/09/2013 11:11 AM, Philippe Verdy wrote:
il y a un problème avec le Golfe du Morbihan (moitié est utilisant le
nouveau rendu, moitié ouest non, avec une limite verticale
Il faut lire aussi ce qui est entre parenthèses: les tuiles sont en
cours de régénération car ça impacte à partir du zoom
10
...en ce moment c'est le zoom 8 qui est en régénération sur les zooms 3 à 11...
Ca devrait être terminé pour le pousse café dominical ;)
J'attends encore de voir pour le parc marin de la Mer d'Iroise (car il
semble que l'intérieur et l'extérieur sont inversés (le parc marin n'inclue
pas les terres des îles elles mêmes, mais c'est ce qu'on voit sur les
premières tuiles générées.
Le 9 juin 2013 11:20, Christian Quest
Il y a une anomalie de géométrie des buffers calculés, qui débordent
quand ils partent d'un côté du polygone pour passer par dessus l'autre côté
du polygone. Effet visible au sud de l'île de Groix (en mer).
Aussi le vert utilisé pour les contours ombrés semble être trop
contrasté, il devrait je
Le 09/06/2013 10:31, Christian Quest a écrit :
Voilà la dernière évolution du rendu des réserves naturelles (les
tuiles sont en cours de régénération car ça impacte à partir du zoom
10):
http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F
J'aime beaucoup !
Merci !
Le 09/06/2013 11:42, Philippe Verdy a écrit :
Il y a une anomalie de géométrie des buffers calculés, qui débordent
quand ils partent d'un côté du polygone pour passer par dessus l'autre
côté du polygone. Effet visible au sud de l'île de Groix (en mer).
Une url, ça aide...
--
FrViPofm
Le 09/06/2013 10:13, Christian Quest a écrit :
Je viens de proposer une présentation autour de l'accessibilité
comprenant intitulée OSM and accessibility: beyond wheelchair=*
Le contenu que j'envisage (en vrac):
- rappel de l'existant (wheelmap)
- les différentes formes de handicap (utilisation
Le 09/06/2013 11:59, Vincent Pottier a écrit :
Le 09/06/2013 10:13, Christian Quest a écrit :
Je viens de proposer une présentation autour de l'accessibilité
comprenant intitulée OSM and accessibility: beyond wheelchair=*
Le contenu que j'envisage (en vrac):
- rappel de l'existant (wheelmap)
-
http://tile.openstreetmap.fr/?zoom=11lat=47.61458lon=-3.39151layers=B0F
Regarde bien le sud de l'île de Groix au zoom 11, et vois comment ça
déborde (côté mer c'est plus facile à voir) par rapport au rendu du zoom
12. Les débordements sont encore plus accentués au zoom 10.
Et ça explique
Pour le rendu FR je pense qu'un poster suffira, ou alors il faut axer
autrement, c'est à dire le côté non technique: comment garder la
paternité du rendu OSM tout en l'adaptant localement.
C'est un sujet de réflexion que j'ai entendu dans une présentation
hier soir à San Francisco, justement
Toujours mieux avec un permalien !
J'ai vu ces défauts sur les petits polygones.
C'est lié à la technique utilisée (sans buffers postgis).
Il va sûrement falloir changer l'épaisseur en fonction de la surface
du polygone ou un truc du genre...
Le 9 juin 2013 12:11, Philippe Verdy
En gros l'anomalie c'est qu'en calculant un polygone de buffer supposé à
l'intérieur du polygone de base, ce polygone calculé en partant d'un côté
peut sortir du polygone de base.
Pour l'éviter, il faut ensuite lui appliquer un clipping par le polygone de
base. Et c'est ce clipping qui manque et
Bonjour,
J'ai trouvé les problèmes suivants :
* Chantilly : quelqu'un a tagué ses chiens Fanfareau et Brillador. Du coup,
le château n'est même pas indiqué sur la carte. À supprimer !?
* Compiègne : le clos des roses apparaît plus gros que le nom de la ville
suivant le zoom. À corriger.
Pour
Même constat:
http://tile.openstreetmap.fr/?zoom=17lat=48.10082lon=-1.67405layers=B0F
Ici la prison des femmes à Rennes, visible avec les hachures rouges
miliaires au zoom 17+, mais rien de visible au niveau 16 ou moins, où on ne
voit que les bâtiments.
On voit aussi les icônes un peu
Je ne pense pas que changer les épaisseurs ne soient viable. Il me semble
que c'est lalgo qui fait un calcul appromximatif des buffers dans le
système de coordonnées en projection carto (pixels) qui est défaillant : on
ne doit pas se contenter de calculer un segment parallèle et le joindre au
Quelques pistes pour les algos de calculs de buffers de polygones:
http://stackoverflow.com/questions/1109536/an-algorithm-for-inflating-deflating-offsetting-buffering-polygons
Suivre les liens de cette discussion. La solution naïve que tu utilises
n'est pas correcte mais le problème est connu et
Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net a écrit
:
Et en toute logique, il faudrait si on l'applique, le propager aussi aux
boundary=administrative, à la place d'admin_level.
Certainement pas (ou à la limite seulement dans les relations
administratives (et qui ne
parfait pour l'adresse http://wms.openstreetmap.fr/toulouse
je ne connaissais pas, et ce n'est jamais ressorti au moement de mes
recherches dans l'historique de la liste.
2 questions :
imaginons que des communes adjacentes à Touliouse métropole veulent libérer
leur orthophoto à qui doit-on
Le 09/06/2013 13:08, Philippe Verdy a écrit :
Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net
mailto:v...@laposte.net a écrit :
Et en toute logique, il faudrait si on l'applique, le propager aussi
aux boundary=administrative, à la place d'admin_level.
Certainement
Le 09/06/2013 13:08, Philippe Verdy a écrit :
Le 8 juin 2013 16:05, Vincent de Château-Thierry v...@laposte.net
mailto:v...@laposte.net a écrit :
Et en toute logique, il faudrait si on l'applique, le propager
aussi aux boundary=administrative, à la place d'admin_level.
Tout à fait.
Le cas des relations ayant les mêmes membres s'est déjà posé, parce que
JOSM par exempel les signale comme des doublons, malgré leurs tags
différents. Certains ne voient pas cela comme étant juste un warning
destiné à vérifier qu'il n'y a pas doublon (ce qui cause aussi des
problèmes de rendu ou
Les clés dans les extractions vers Postgres peuvent être réduites même sans
réutiliser les tags dans OSM. Les requêtes faites dans les tables de
features Postgres n'ont strictement rien à voir, les modèles de données
sont complètement différents.
Très mauvais argument donc. C'est hors sujet et ne
Philippe,
Postgres n'a aucune obligation d'utiliser les mêmes clés OSM, il
utilise des tables séparées pour chaque feature, et avec des colonnes
dont les noms sont spécifiques à chaque table (le nom de la table
elle-même les isole, même s'ils sont homonymes, ils peuvent donc y
être
Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com a écrit :
Il faudrait réfléchir plus sérieusement.
Tout à fait. Tu peux t'y mettre.
Commence par te l'appliquer à toi-même. quand tu comprendras que la base
OSM pour l'instant n'est pas structurée du tout comme une base GIS et que
son
Le 09/06/2013 15:28, Philippe Verdy a écrit :
Le cas des relations ayant les mêmes membres s'est déjà posé, parce que
JOSM par exempel les signale comme des doublons, malgré leurs tags
différents. Certains ne voient pas cela comme étant juste un warning
destiné à vérifier qu'il n'y a pas
J'ai l'impression que j'aurai du mal à expliquer ça vu qu'apparemment tu ne
sais pas ce qu'est une base SQL, un modèle de données, et un schéma.
Ce que je peux dire c'est qu'OSM est structuré comme si tout était un seul
feature unique réunissant tous les features qu'une base GIS normale
utilise
Le 9 juin 2013 15:46, Vincent de Château-Thierry v...@laposte.net a écrit
:
Noter aussi que les relations ne sont pas les seuls moyens de
représenter une zone: s'il n'y a pas lieu de découper les frontières
parce qu'un élément de même type n'est pas présent à ses frontières, OSM
suppose
On 09/06/2013 11:18, Philippe Verdy wrote:
J'ai l'impression que j'aurai du mal à expliquer ça vu qu'apparemment
tu ne sais pas ce qu'est une base SQL, un modèle de données, et un schéma.
Oui tu as raison avec un doctorant en informatique, je ne sais pas ce
que je sais...
Je t'ai demandé
Le 09/06/2013 15:33, Philippe Verdy a écrit :
Les clés dans les extractions vers Postgres peuvent être réduites même
sans réutiliser les tags dans OSM. Les requêtes faites dans les tables
de features Postgres n'ont strictement rien à voir, les modèles de
données sont complètement différents.
Le 08/06/2013 20:13, François Lacombe a écrit :
Bonjour et merci pour cette liste de mises à jour :)
Le 8 juin 2013 15:26, Frédéric Rodrigo fred.rodr...@gmail.com
mailto:fred.rodr...@gmail.com a écrit :
* Type de ligne électrique en fonction du voltage (line/minor_line)
Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des
compétences en bases de données (c'est aussi mon boulot, me^me si ça ne
vous semble pas évident) ne feignez pas de rien comprendre.
OSM n'a dans sa table qu'une table unique (en fait 3 pour séparer seulement
noeuds, chemins
Le 09/06/2013 16:18, Philippe Verdy a écrit :
Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez
des compétences en bases de données (c'est aussi mon boulot, me^me si
ça ne vous semble pas évident) ne feignez pas de rien comprendre.
OSM n'a dans sa table qu'une table unique
Le 09/06/2013 15:41, Philippe Verdy a écrit :
Le 9 juin 2013 15:06, Vincent Pottier vpott...@gmail.com
mailto:vpott...@gmail.com a écrit :
Il faudrait réfléchir plus sérieusement.
Tout à fait. Tu peux t'y mettre.
Commence par te l'appliquer à toi-même.
Merci, c'est fait.
quand
Pour la troisième fois: je n'utilise aucun buffer mais un line-pattern.
C'est un petit PNG qui est dessiné par Mapnik sur le pourtour du
polygone et quand les angles sont trop aigus, ça bave un peu en
dérapant dans le virage.
___
Talk-fr mailing list
C'est dans la todo list de ybon... pouvoir indiquer un layer de son
choix en plus de ceux proposés par défaut.
A ce sujet, j'en ai ajouté 3:
- OSM Mapnik monochrome
- Open MapQuest US (légèrement différent du rendu Europe)
- Outdoors
Le 9 juin 2013 13:56, Laurent Combe laurent.co...@free.fr a
Mauvaise méthode donc.
Tu fais comment pour dessiner les routes ? Tu utilises bien des lignes en
précisant une épaisseur de trait et le moteur de rendu vectoriel calcule un
polygone à remplir (ce qui se fait dans le moteur graphique un buffer, non
?)
Tout moteur graphique vectoriel (par exemple
Le 9 juin 2013 10:31, Christian Quest cqu...@openstreetmap.fr a écrit :
Voilà la dernière évolution du rendu des réserves naturelles (les
tuiles sont en cours de régénération car ça impacte à partir du zoom
10):
http://tile.openstreetmap.fr/?zoom=13lat=47.29383lon=-2.44937layers=B0F
Justement oui, mais tu ne parles pas là du tout de la base OSM elle-même !
Ta base osm2psql n'a rien à voir, c'est le résultat d'un import avec un
script de conversion ecrit en C qui effectue des sous-selection compliquées
pour traduire le schéma OSM en features importés dans ta base.
Bref tu
Le 9 juin 2013 16:18, Philippe Verdy verd...@wanadoo.fr a écrit :
Vous le faites exprès ou quoi pour ne pas comprendre ? Si vous avez des
compétences en bases de données (c'est aussi mon boulot, me^me si ça ne vous
semble pas évident) ne feignez pas de rien comprendre.
OSM n'a dans sa table
Le 9 juin 2013 17:14, Philippe Verdy verd...@wanadoo.fr a écrit :
Mauvaise méthode donc.
Tu fais comment pour dessiner les routes ? Tu utilises bien des lignes en
précisant une épaisseur de trait et le moteur de rendu vectoriel calcule un
polygone à remplir (ce qui se fait dans le moteur
Bonjour,
Quelqu'un a-t-il une minuscule idée du pourquoi du comment le rocher de
tombelaine s'appelle rocher de tombelaine normalement et tout le temps,
sauf au zoom 15 où il s'appelle Rouen ??
http://osm.org/go/ermtshRW--
http://fr.wikipedia.org/wiki/Tombelaine
--
Les dérives de rue :
Le
Bonjour,
Je veux saisir un point d'eau agricole [1] mais tout ce que je trouve dans le
wiki c'est waterway=water_point [2] pour un point d'eau potable. Quelqu'un
aurait une idée comment tagguer ce genre d'installation?
Rainer
[1]
Enfin tu commences à comprendre !
Les tags dans OSM ne sont pas ce que tu utilises dans ta base issue d'un
export et d'une traduction avec osm2pgsql (ou autre chose) vers une base
GIS.
Toute la discussion portait sur les tables OSM qui n'ont pas de structure
(tu l'admets enfin), donc ont besoin
encore un effet de bord de la frontière religieuse (pseudo aministrative).
Il se trouve que le long d'une frontière peuvent apparaître les noms de
toutes les relations qui la référence : on voit donc le nom de l'objet
lui-même (si la ligne de côte est nommée), le nom de la commune, de
En plus cela dépend de quel moteur de rendu tu parles, même si c'est du
Mapnik on n'a pas la même chose entre le rendu d'osm.org, celui de 2u, ou
celui d'OSM.fr, ou ceux de Mapquest, uMap, etc.
Le 9 juin 2013 17:35, Ista Pouss ista...@gmail.com a écrit :
Bonjour,
Quelqu'un a-t-il une
Le 09/06/2013 17:47, Philippe Verdy a écrit :
Enfin tu commences à comprendre !
Toi, pas.
Les tags dans OSM ne sont pas ce que tu utilises dans ta base issue
d'un export et d'une traduction avec osm2pgsql (ou autre chose) vers
une base GIS.
Si, les tags dans OSM sont traduits dans ma base
Non je ne parlais pas du code source ce la bibliothèque que tu utilises,
mais TON code dans ton moteur de rendu.
A mon avis au lieu des LinePatternSymbolizer, cela marcherait mieux avec
PolyOffsetBuilder
dans
https://github.com/mapnik/mapnik/blob/master/deps/clipper/src/clipper.cpp
(Clipper
Le 9 juin 2013 17:47, Philippe Verdy verd...@wanadoo.fr a écrit :
Toute la discussion portait sur les tables OSM qui n'ont pas de structure
(tu l'admets enfin), donc ont besoin d'avoir des tags précis (sinon c'est
ton script de traduction osm2pgsql qui va se tromper...)
La notion de table OSM
Désolé mais on ne parle visiblement pas de la même chose.
Pas la peine d'accuser l'autre de ses lacunes puisque dès le départ vous
avez confondu (avec insistance en plus, ce qui est pourtant faux !) la base
OSM avec vos bases Pgsql traduites par un script spécifique (tuné en
fonction de Mapnik le
On a abordé ce sujet il y a peu sur la liste
Il y a un tag pour les abreuvoirs :
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwatering_place
La discussion sur les points d'eau hors de la ville et la relative
portabilité date d'une semaine il me semble tu devrais la retrouver
rapidement.
Le
Le 9 juin 2013 18:26, Philippe Verdy verd...@wanadoo.fr a écrit :
https://github.com/mapnik/mapnik/blob/master/deps/clipper/src/clipper.cpp
PolyOffsetBuilder, très bien , mais non exposé par mapnik. Essaies encore.
Sinon je propose l'utilisation des opérations de filtrages et composition
Et en pratique ce support est intégré dans le LineSymbolizer:
if (sym.clip())
{
double padding = (double)(query_extent_.width()/width_);
double half_stroke = stroke_.get_width()/2.0;
if (half_stroke 1)
padding *= half_stroke;
if
A noter que ce serait pas mal que Mapnik supporte directement dans ses
feuilles de style XML la possibilité de préciser le côté de l'épaisseur de
ligne qu'on veut afficher (par défaut il affiche les deux côtés,
moitié-moitié à cheval sur le ligne virtuelle), on devrait pouvoir indiquer
une option
Le 16/04/2013 10:53, Vincent de Chateau-Thierry a écrit :
Bonjour,
De : rldhont
Je serais au FROG puis au Code Sprint OSGEO-fr donc aux Rencontres
SIG-la-lettre! Je pense en fait passez plus de temps sur l'OpenData Bar
qu'au Code Sprint ;-)
Donc compte sur moi
René-Luc
P.S: j'essayerais
Donc...
Lundi (FROG): Fred, Marc, René-Luc, Christian (d'autres seront présents ?)
Mardi: Fred, Marc, René-Luc, Nicolas, Christian
Mercredi: Fred, Vincent, René-Luc, Nicolas, Christian
Jeudi: Fred, René-Luc, Nicolas, Christian
Le 9 juin 2013 22:30, Vincent de Château-Thierry v...@laposte.net a
Je serais demain à FROG jusqu'à 15h :-)
Envoyé depuis un mobileChristian Quest cqu...@openstreetmap.fr a écrit
:Donc...
Lundi (FROG): Fred, Marc, René-Luc, Christian (d'autres seront présents ?)
Mardi: Fred, Marc, René-Luc, Nicolas, Christian
Mercredi: Fred, Vincent, René-Luc, Nicolas,
Je me fais aussi la semaine complète,
Lundi, je viens avec des copains qui sont sur le projet gis-blog.fr
Le reste de la semaine, je ferai certaines conférences mais on pourra
voir ensemble pour tenir le stand.
Sinon, il y a une intéressante présentation de Alyssa Wright sur le SOTM
US en ce
Nouvelle mouture:
http://tile.openstreetmap.fr/?zoom=11lat=47.42028lon=-2.41356layers=B0F
(tuiles regénérées dans le coin à coup de /dirty)
C'est fait avec 4 lignes, décalées par line-offset et avec une opacité
qui décroit.
___
Talk-fr mailing
Bravo pour l'inspiration.
Je continue d'insister pour que d'ici là les entrées soient valorisées :
entrance=yes/main,exit,emergency...
cquest wrote
Pour le rendu FR je pense qu'un poster suffira, ou alors il faut axer
autrement, c'est à dire le côté non technique: comment garder la
paternité
Cette fois ça marche, plus d'aberrations géométriques avec ces
débordements. Je remarque que tu as réduit l'épaisseur notablement, l'effet
d'opacité décroissante est moins visible, et parfois le tracé disparaît
lorsque la réserve longe une route (la route recouvre tout le tracé).
Le 10 juin 2013
71 matches
Mail list logo
