date:20131006

Les passages piétons sont bien rendus...
http://tile.openstreetmap.fr/?zoom=20lat=45.42992lon=4.39491
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-10-06 Par sujet Ista Pouss

Le 5 octobre 2013 21:09, Pieren pier...@gmail.com a écrit :

 Il ne faut pas attacher trop d'importance au rendu. Même si on sait
 bien que ça reste le premier outil de validation pour les nouveaux
 contributeurs (et aussi la première forme de récompense), il y a aussi
 des tas de choses dans OSM qui ne sont pas affichées sur la carte
 principale. Ou des choses qui sont affichées alors qu'elles sont mal
 cartographiées. Donc, toujours examiner les données pour se faire un
 avis critique.


Je ne partage pas l'avis de la communauté sur ces histoires de rendu /
données, mais c'est un autre débat.  Au moins, je comprends ta position.



  de surface, mais, apparemment, c'est compliqué les surfaces.

 Les surfaces, c'est pas compliqué. Mais il y a surface et surface.
 Celle qu'on indique avec highway=unclassified + area=yes a une
 signification très claire : c'est une place ouverte où les véhicules
 peuvent circuler dans toutes les directions. Ca n'était pas le cas de
 cet exemple à Saint-Etienne.
 Il y a aussi la possibilité d'indiquer la surface occupée par une
 route normale (qui conserve son filaire central) avec un tag qui est
 resté au stade de la proposition : area:highway ([1]). Il n'est pas
 rendu par mapnik et n'est pas très populaire (1 exemplaires par
 460 contributeurs quand même dans la base).


S'il y a surface et surface, la surface dont je te parle est visible de
visu.

Mais bon je renonce à chipoter, et j'admets que l'idée de concentrer les
routes sur un point est pas mauvaise les choses étant ce qu'elles sont. La
modélisation reste compatible avec le terrain, à part le problème des feux,
voir plus loin.

D'ailleurs il me semble qu'on pourrait encore simplifier ton modèle, tout
en restant compatible terrain : si la rue des armuriers arrive directement
au point central, ça marche encore bien, non ?

Le carrefour serait modélisé par deux points : un point de rencontre rues
pélissier / valbenoite / armuriers / mulatière, et un valbenoite / jean
baptiste david / micro rue en sens unique vers armuriers. Le carrefour
serait l'ensemble de ces deux points reliés par une rue, rue inexistante,
mais... c'est un modèle.



  D'ailleurs, les chemins piétons sont bons dans
  l'ensemble, mais DIeu seul sait s'ils sont routables ?

 Ca n'était pas le problème posé au début de ce fil de discussion.
 Suivant les retours qu'on voit sur un autre fil, il est probable qu'il
 ne soit pas routable pour la plupart des logiciels qui le font pour
 les piétons avec les données OSM. Mais les zones piétonnes sont dans
 leur immense majorité tagguées de cette manière, sans footway ajouté
 pour les rendre routable par certains logiciels. C'est aux logiciels
 de s'adapter aux données et non l'inverse.
 Pour revenir aux trottoirs, on voit que ceux qui commencent à
 cartographier ça ne vont jamais jusqu'au bout et s'arrêtent au bout de
 quelques rues. Du coup, on a un résultat très moche sur la carte (toi
 qui donne beaucoup d'importance au rendu pourrait y être sensible).
 C'est pourquoi personnellement, je ne cartographie pas les trottoirs.
 De plus, cela alourdit considérablement le filaire dans la zone et
 rend difficile toutes les contributions futures. Au mieux, il existe
 la possibilité d'ajouter un attribut au highway principal pour dire
 si un trottoir se trouve à gauche, à droite ou des deux côtés. Je
 préfererais nettement cette option si j'avais à choisir.


Oui, mais le principe ceux qui commence à cartographier ne vont jamais
jusqu'au bout est consécutif aux principes collaboratifs, et au principe
mappez ce qu'il y a en bas de chez vous, non ?

Du coup il faut une transition cohérente entre ce qui est mappé et ce qui
ne l'est pas.  Mais pour les trottoirs, ce n'est pas facile.



  - du fait qu'il n'y a pas de surface, de nombreuses relations entre
 objets
  sont incohérentes avec le terrain : la sorte de point central n'existe
 pas,
  et ça décale toutes les distances entre le bord de la place et les objets
  qui l'entourent.

 Je ne comprend pas bien cette remarque (quelle relations entre
 objets). Si tu veux faire figurer la surface de la partie routière,
 qui est très large dans ce cas particulier, utilise un polygone taggué
 area:highway déjà cité plus haut. La modélisation sera complète mais
 tu ne verras pas cette surface sur la carte principale. Si tu veux à
 tout prix voir cette surface, tu seras obligé d'utiliser le
 highway=unclassified + area=yes qui entrera en contradiction avec
 le filaire des voies (et c'est tagguer pour le rendu puisque tu
 sous-entends avec ces tags que l'espace est ouvert dans toutes les
 directions, ce qui n'est pas le cas).


Je ne sais pas trop pourquoi tu affirmes que l'espace n'est pas ouvert dans
toutes les directions... Il y a un obstacle magnétique ?

Je me demande ce que pense Christian Quest, le Maître es rendu es datas,
de ces histoires de area qui sont inutilisées et non rendues ?... C'est une
méga connerie de la communauté, non ?...



 Il n'y a donc pas à

Re: [OSM-talk-fr] Explosion d'un carrefour

Pour le rendu surfacique, il y a un sacré boulot à faire sur la feuille de
style déjà que parfois avec du filaire on s'arrache les cheveux !

Comme souvent, peu de monde s'y est mis côté rendu car il y a peu de
données, donc le jeu n'en vaut pas la chandelle, mais nous savons tous
aussi que la visibilité dans le rendu poussera à mapper le surfacique.

Les questions que je me pose:
- est-ce souhaitable de démarrer le surfacique de voirie alors qu'il manque
encore tant de filaire ?
- comment gère-t-on le mélange surfacique/filaire, surtout lorsqu'on l'on
repasse d'une zone en filaire+surfacique à une zone seulement en filaire ?

J'avais tenté de rendre la largeur des routes en basant le rendu sur
width=* et lanes=*. Le gros problème était les raccords entre un lanes=2 et
un lanes=3... c'était très moche.



Pour les feux, je partage l'avis de Pieren.

Un tag unique pour signaler qu'une intersection a sa circulation gérée par
un feu, puis des tags spécifiques pour indiquer chaque feu, chaque passage
piéton, feu cycliste, etc et le tout mis si besoin dans une relation. Cela
permet d'avoir une info globale (qui aide pour les rendus à moyenne
échelle), et en détail (utile pour le routage ou le rendu à très grande
échelle).

Le problème c'est la modélisation des carrefours complexes avec un ilot
central où toutes les voies ne se croisent pas sur un unique nœud. Dans ce
cas, où mettre le tag feu principal ?

Ca me rappelle la proposition de relations pour les carrefours, c'est peut
être là qu'il faudrait indiquer que le carrefour est géré par un feu...

-- 
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-10-06 Par sujet Philippe Verdy

Vous oubliez encore que tous les feux d'un même carrefour ne sont pas
nécessairement synchronisés entre eux. Et aussi le cas des feux
supplémentaires en SORTIE de carrefour (il y en a un bon nombre à Paris),
devant un passage piéton qui traverse la rue où on veut s'engager. Bref un
véhicule doit s'arrêter à 2 feux successifs, avant l'entrée et avant la
sortie.

Un seul tag sur un noeud unique central cela ne correspond à rien du tout
sur le terrain. On n'est pas aux Etats-Unis avec les feux suspendus sur un
câble au milieu du carrefour (je ne pense pas avoir vu ça en France).

Pourquoi voulez-vous attacher tous les feux d'un carrefour ensemble ? Par
le fait qu'ils seraient synchronisés? Ce n'est pas pertinent car le
conducteur ou le piéton n'est concerné que par le bon feu dans sa direction
et pas par les autres. Et aussi parce qu'on ne tague pas des données
temporelles décrivant les divers cycles et modes du feu, les durées de
chaque mode, d'autant plus que bon nombre de feux sont maintenant contrôlés
par télécommande à distance par un centre de régulation de trafic, avec des
caméras et détecteurs de présence à radar ou détecteurs de franchissement
et de comptage sous la chaussée).

Chaque feu est attaché à une direction précise -- parfois aussi un feu peut
avoir une face miroir indiquant au conducteur venant du carrefour que
dans la voie où il veut aller les véhicules contrôlés par ce feu peuvent
démarrer et entrer dans le carrefour, voire tourner à gauche en coupant la
route à ceux qui ne sont pas encore sortis du carrefour (même si le code de
la route demande qu'on n'entre pas au feu vert dans un carrefour si on n'a
pas l'assurance de pouvoir en sortir)..

De plus il y a des feux à plusieurs niveaux dans des carrefours complexes,
selon la voie (par exemple la voie pour tourner à droite a un feu avancé
qui donne accès à une voie séparée physiquement. Ce feu n'a pas le même
synchronisme et peut même rester au rouge deux fois plus longtemps que le
feu pour aller tout droit, ou au contraire rester vert presque en
permanence (sauf si un piéton a demandé qu'il passe au rouge en appuyant
sur un bouton) alors que le feu pour aller tout droit alterne toutes les 2
minutes.

La position précise du feu est importante si on veut qu'un routage puisse
indiquer à quel endroit on peut tourner ou changer de voie.


Le 6 octobre 2013 10:09, Christian Quest cqu...@openstreetmap.fr a écrit :

 Pour le rendu surfacique, il y a un sacré boulot à faire sur la feuille de
 style déjà que parfois avec du filaire on s'arrache les cheveux !

 Comme souvent, peu de monde s'y est mis côté rendu car il y a peu de
 données, donc le jeu n'en vaut pas la chandelle, mais nous savons tous
 aussi que la visibilité dans le rendu poussera à mapper le surfacique.

 Les questions que je me pose:
 - est-ce souhaitable de démarrer le surfacique de voirie alors qu'il
 manque encore tant de filaire ?
 - comment gère-t-on le mélange surfacique/filaire, surtout lorsqu'on l'on
 repasse d'une zone en filaire+surfacique à une zone seulement en filaire ?

 J'avais tenté de rendre la largeur des routes en basant le rendu sur
 width=* et lanes=*. Le gros problème était les raccords entre un lanes=2 et
 un lanes=3... c'était très moche.



 Pour les feux, je partage l'avis de Pieren.

 Un tag unique pour signaler qu'une intersection a sa circulation gérée par
 un feu, puis des tags spécifiques pour indiquer chaque feu, chaque passage
 piéton, feu cycliste, etc et le tout mis si besoin dans une relation. Cela
 permet d'avoir une info globale (qui aide pour les rendus à moyenne
 échelle), et en détail (utile pour le routage ou le rendu à très grande
 échelle).

 Le problème c'est la modélisation des carrefours complexes avec un ilot
 central où toutes les voies ne se croisent pas sur un unique nœud. Dans ce
 cas, où mettre le tag feu principal ?

 Ca me rappelle la proposition de relations pour les carrefours, c'est peut
 être là qu'il faudrait indiquer que le carrefour est géré par un feu...

 --
 Christian Quest - OpenStreetMap France
 Un nouveau serveur pour OSM... http://donate.osm.org/server2013/

 ___
 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

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-10-06 Par sujet hamster

Le 04/10/2013 07:00, Ista Pouss a écrit :
 Et je reste quand même étonné que l'on présente ce qui de mon avis
 ressemble à une surface routière par du filaire...

Je trouve moi aussi denue de sens de representer une place (c'est a dire
une entité surfacique par essence) par un enchevetrement de filaire.

La place Edmond Maurat (ou n'importe quelle autre place) c'est un espace
qui contiens de la voirie, des trottoirs, des pelouses, des barrieres et
autre. Vu que c'est un espace, soit on mappe a la serpe et on le
represente par un point, soit on fait du micro-mapping et on le
represente par une surface. Ici on a dans cette place le detail des
diverses voies de circulation, les bouts de verdure, les feux, les
barrieres, mais on a pas la place elle meme. La difficulte a trouver ou
mettre le tag name=place Edmond Maurat montre bien ce probleme. C'est
comme si pour un batiment on avait dessine les pieces, les couloirs, les
murs, les ascenseurs, mais sans faire un polygone building qui englobe
le tout.

Il nous manque un tag surfacique pour dire cette zone est une place.
Ce tag engloberait tout ce qui est dans la place. De la meme maniere que
landuse=residential sert a dire cette zone est une agglomeration et
englobe tout ce qui est dans l'agglomeration. Ce tag place ne devrait
pas etre dans la clef highway. Peut etre dans la clef landuse ?

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour


Bonjour,

Le 06/10/2013 11:24, hamster a écrit :


Il nous manque un tag surfacique pour dire cette zone est une place.
Ce tag engloberait tout ce qui est dans la place. De la meme maniere que
landuse=residential sert a dire cette zone est une agglomeration et
englobe tout ce qui est dans l'agglomeration. Ce tag place ne devrait
pas etre dans la clef highway. Peut etre dans la clef landuse ?


Voilà qui résume bien la situation.

On trouve une centaine d'objets taggués avec landuse=plaza :
http://taginfo.openstreetmap.org/tags/landuse=plaza
essentiellement en France et en Allemagne.

par exemple :
http://www.openstreetmap.org/browse/way/17478063
http://www.openstreetmap.org/browse/way/218869335
http://www.openstreetmap.org/browse/way/220429765
etc.

Ça n'est pas documenté, mais vue la définition :
http://en.wikipedia.org/wiki/Plaza
ça semble cohérent.

yapluka ?

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-10-06 Par sujet Christophe Merlet


Le 06/10/2013 12:41, Vincent de Château-Thierry a écrit :

Bonjour,

Le 06/10/2013 11:24, hamster a écrit :


Il nous manque un tag surfacique pour dire cette zone est une place.
Ce tag engloberait tout ce qui est dans la place. De la meme maniere que
landuse=residential sert a dire cette zone est une agglomeration et
englobe tout ce qui est dans l'agglomeration. Ce tag place ne devrait
pas etre dans la clef highway. Peut etre dans la clef landuse ?


Voilà qui résume bien la situation.

On trouve une centaine d'objets taggués avec landuse=plaza :
http://taginfo.openstreetmap.org/tags/landuse=plaza
essentiellement en France et en Allemagne.

par exemple :
http://www.openstreetmap.org/browse/way/17478063
http://www.openstreetmap.org/browse/way/218869335
http://www.openstreetmap.org/browse/way/220429765
etc.

Ça n'est pas documenté, mais vue la définition :
http://en.wikipedia.org/wiki/Plaza
ça semble cohérent.

yapluka ?


Heuuu, les photos illustrant cette balise montre vraiment quelque chose 
qui n'a rien a voir avec le carrefour de Saint-Étienne qui est juste un 
croisement un peu large de multiples voies.


Sur ce croisement de Saint-Étienne le flux des véhicules est canalisé et 
les piétons n'ont pas a circuler en plein milieu.


Une représentation surfacique n'apporte aucune informations utiles.


Librement,
--
Christophe Merlet (RedFox)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour



Le 06/10/2013 12:56, Christophe Merlet a écrit :

Le 06/10/2013 12:41, Vincent de Château-Thierry a écrit :

Bonjour,

Le 06/10/2013 11:24, hamster a écrit :


Il nous manque un tag surfacique pour dire cette zone est une place.
Ce tag engloberait tout ce qui est dans la place. De la meme maniere que
landuse=residential sert a dire cette zone est une agglomeration et
englobe tout ce qui est dans l'agglomeration. Ce tag place ne devrait
pas etre dans la clef highway. Peut etre dans la clef landuse ?


Voilà qui résume bien la situation.

On trouve une centaine d'objets taggués avec landuse=plaza :
http://taginfo.openstreetmap.org/tags/landuse=plaza
essentiellement en France et en Allemagne.

par exemple :
http://www.openstreetmap.org/browse/way/17478063
http://www.openstreetmap.org/browse/way/218869335
http://www.openstreetmap.org/browse/way/220429765
etc.

Ça n'est pas documenté, mais vue la définition :
http://en.wikipedia.org/wiki/Plaza
ça semble cohérent.

yapluka ?


Heuuu, les photos illustrant cette balise montre vraiment quelque chose
qui n'a rien a voir avec le carrefour de Saint-Étienne qui est juste un
croisement un peu large de multiples voies.

Sur ce croisement de Saint-Étienne le flux des véhicules est canalisé et
les piétons n'ont pas a circuler en plein milieu.

Une représentation surfacique n'apporte aucune informations utiles.


Si.
Une représentation surfacique permet de s'affranchir des filaires 
taggués en highway=* pour attribuer le nom de la place. En dessinant 
explicitement une surface et en la nommant, on évite les acrobaties 
actuelles de micro découpage de highways dont le but est avant tout de 
pouvoir répondre à Nominatim, sans forcément décrire le terrain. Je ne 
vois par exemple pas l'intérêt d'un nom là-dessus :

http://www.openstreetmap.org/browse/way/240567745

Et pour élargir, mon propos était surtout de rebondir au constat, plus 
général, de hamster sur l'absence de convention pour tagguer le contour 
extérieur d'une place (avec plein de guillemets) indépendamment du 
détail qu'on apporte à ses constituants. Je n'ai pas d'actions dans la 
balise landuse=plaza, mais je trouve l'idée intéressante. Après, faute 
de description sur le wiki, chacun y met pour l'instant la signification 
qui l'arrange.


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Cartographie d'un sommet double

2013-10-06 Par sujet Balaitous

Bonjour,

Le pic de Rulhe est comporte 2 sommets principaux, distants d'une petite
cinquantaine de mètres.

Le point actuellement présent dans OSM correspond au col séparant les 2
sommets.

Comment faire pour le cartographier correctement (i.e. indiquer la
position des deux sommets) ?

J'ai ajouté les voies d'accès aux deux sommets. L'extrémité des sentiers
correspond aux deux sommets.

Voir http://www.openstreetmap.org/#map=18/42.62709/1.73941

D'après mon relevé GPS, le sommet ouest a pour altitude 2780m, le sommet
est à 2782m.
http://ubuntuone.com/4t1GVDs5v8faveLOlK8lEL

Balaitous



___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

Si le problème est de positionner le nom, il y a peut-être junction=yes +
name=* qui pourrait servir au moins pour le rendu.
Je l'avais ajouté sur le rendu FR car au Japon c'est très courant.

On peut voir l'effet un peu moins loin comme dans la forêt de
Fontainebleau...
http://tile.openstreetmap.fr/?zoom=16lat=48.3588lon=2.70855

Par contre, il ne semble pas que Nominatim en tienne compte :(

Le 6 octobre 2013 15:22, Vincent de Château-Thierry v...@laposte.net a
écrit :

Le 06/10/2013 12:56, Christophe Merlet a écrit :

Le 06/10/2013 12:41, Vincent de Château-Thierry a écrit :

Bonjour,

Le 06/10/2013 11:24, hamster a écrit :

Il nous manque un tag surfacique pour dire cette zone est une place.
Ce tag engloberait tout ce qui est dans la place. De la meme maniere que
landuse=residential sert a dire cette zone est une agglomeration et
englobe tout ce qui est dans l'agglomeration. Ce tag place ne devrait
pas etre dans la clef highway. Peut etre dans la clef landuse ?

Voilà qui résume bien la situation.

On trouve une centaine d'objets taggués avec landuse=plaza :
http://taginfo.openstreetmap.**org/tags/landuse=plazahttp://taginfo.openstreetmap.org/tags/landuse=plaza
essentiellement en France et en Allemagne.

par exemple :
http://www.openstreetmap.org/**browse/way/17478063http://www.openstreetmap.org/browse/way/17478063
http://www.openstreetmap.org/**browse/way/218869335http://www.openstreetmap.org/browse/way/218869335
http://www.openstreetmap.org/**browse/way/220429765http://www.openstreetmap.org/browse/way/220429765
etc.

Ça n'est pas documenté, mais vue la définition :
http://en.wikipedia.org/wiki/**Plazahttp://en.wikipedia.org/wiki/Plaza
ça semble cohérent.

yapluka ?

Heuuu, les photos illustrant cette balise montre vraiment quelque chose
qui n'a rien a voir avec le carrefour de Saint-Étienne qui est juste un
croisement un peu large de multiples voies.

Sur ce croisement de Saint-Étienne le flux des véhicules est canalisé et
les piétons n'ont pas a circuler en plein milieu.

Une représentation surfacique n'apporte aucune informations utiles.

Si.
Une représentation surfacique permet de s'affranchir des filaires taggués
en highway=* pour attribuer le nom de la place. En dessinant explicitement
une surface et en la nommant, on évite les acrobaties actuelles de micro
découpage de highways dont le but est avant tout de pouvoir répondre à
Nominatim, sans forcément décrire le terrain. Je ne vois par exemple pas
l'intérêt d'un nom là-dessus :
http://www.openstreetmap.org/**browse/way/240567745http://www.openstreetmap.org/browse/way/240567745

Et pour élargir, mon propos était surtout de rebondir au constat, plus
général, de hamster sur l'absence de convention pour tagguer le contour
extérieur d'une place (avec plein de guillemets) indépendamment du détail
qu'on apporte à ses constituants. Je n'ai pas d'actions dans la balise
landuse=plaza, mais je trouve l'idée intéressante. Après, faute de
description sur le wiki, chacun y met pour l'instant la signification qui
l'arrange.

vincent

__**_
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.**org/listinfo/talk-frhttps://lists.openstreetmap.org/listinfo/talk-fr

--
Christian Quest - OpenStreetMap France
Un nouveau serveur pour OSM... http://donate.osm.org/server2013/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-10-06 Par sujet Christophe Merlet


Le 06/10/2013 15:22, Vincent de Château-Thierry a écrit :


Une représentation surfacique n'apporte aucune informations utiles.


Si.
Une représentation surfacique permet de s'affranchir des filaires
taggués en highway=* pour attribuer le nom de la place. En dessinant
explicitement une surface et en la nommant, on évite les acrobaties
actuelles de micro découpage de highways dont le but est avant tout de
pouvoir répondre à Nominatim, sans forcément décrire le terrain. Je ne
vois par exemple pas l'intérêt d'un nom là-dessus :
http://www.openstreetmap.org/browse/way/240567745


Il n'y a rien d'acrobatique a donner à une voie le nom d'une place. 
C'est la pratique usuelle.


Le découpage des highway est ici indispensable pour représenter 
convenablement les sens uniques et ça décrit très bien le terrain.


4 voies constitutives de cette place porte le nom Place Edmond 
Maurat. Et sur ces 4 voies, ce n'est pas le segment que tu pointes qui 
est le plus critiquable !



Et pour élargir, mon propos était surtout de rebondir au constat, plus
général, de hamster sur l'absence de convention pour tagguer le contour
extérieur d'une place (avec plein de guillemets) indépendamment du
détail qu'on apporte à ses constituants. Je n'ai pas d'actions dans la
balise landuse=plaza, mais je trouve l'idée intéressante. Après, faute
de description sur le wiki, chacun y met pour l'instant la signification
qui l'arrange.


Mais ici, ce n'est pas, à mon avis, une place qui nécessite une 
représentation surfacique.



Librement,
--
Christophe Merlet (RedFox)

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-10-06 Par sujet JB

 

Le 06.10.2013 10:09, Christian Quest a écrit : 

 J'avais tenté de rendre la largeur des routes en basant le rendu sur width=* 
 et lanes=*. Le gros problème était les raccords entre un lanes=2 et un 
 lanes=3... c'était très moche.

Tu as essayé en finissant les ways par un triangle ? Je ne maitrise pas
trop mapnik, mais dans maperitive, tu as un truc qui s'appelle
line-start-cap et line-end-cap, où tu mets souvent round, pour que les
voies découpées en tronçons se recouvrent bien. Avec une finition en
triangle, tu devrais pouvoir faire le lien entre des tronçons de
largeurs différentes ? Après, comme d'habitude, le diable est dans les
détails… 

JB. 
 ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-10-06 Par sujet Ista Pouss

Le 6 octobre 2013 10:09, Christian Quest cqu...@openstreetmap.fr a écrit :

 Pour le rendu surfacique, il y a un sacré boulot à faire sur la feuille de
 style déjà que parfois avec du filaire on s'arrache les cheveux !

 Comme souvent, peu de monde s'y est mis côté rendu car il y a peu de
 données, donc le jeu n'en vaut pas la chandelle, mais nous savons tous
 aussi que la visibilité dans le rendu poussera à mapper le surfacique.


OK je comprends mieux les difficultés actuelles !



 Les questions que je me pose:
 - est-ce souhaitable de démarrer le surfacique de voirie alors qu'il
 manque encore tant de filaire ?


Je pense que oui, car :

- ça simplifierait certains rendus - et très probablement datas -
filaires indémerdables, tel la Place de la Concorde à Paris :
http://tile.openstreetmap.fr/?zoom=20lat=48.86619lon=2.32118layers=B00(de
mes lointains souvenirs de cette place, ce rendu est complètement
faux,
non ?... ou alors elle a bien changé ! )

(notez que je fais l'effort de ne pas citer la place E... M... à S...
E) (allez les verts ! )

(et j'ai résisté à l'envie d'aller voir la place de la concorde sur google
street pour ne pas pénaliser gravement le projet OSM ! )

- de plus la réflexion sur ce qu'est une surface et ce qu'est un filaire me
parait gravement perturbé chez de nombreux contributeurs... Je n'en dirais
pas plus, je n'en pense pas moins. Que le surfacique soit RENDU ça aiderait
sans doute pas mal à le modéliser dans les DATAS. Point.



http://drivrsdu.fr/profession-emotion/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Tracer une place (était : Explosion d'un carrefour)



Le 06/10/2013 16:43, Christophe Merlet a écrit :


Il n'y a rien d'acrobatique a donner à une voie le nom d'une place.
C'est la pratique usuelle.


Je suis bien d'accord, mais c'est loin d'être toujours satisfaisant. 
Décrire une surface par une surface plutôt que par des axes qui la 
traversent, qui plus est si le nom diffère, ça peut aussi avoir du sens.



Et pour élargir, mon propos était surtout de rebondir au constat, plus
général, de hamster sur l'absence de convention pour tagguer le contour
extérieur d'une place (avec plein de guillemets) indépendamment du
détail qu'on apporte à ses constituants. Je n'ai pas d'actions dans la
balise landuse=plaza, mais je trouve l'idée intéressante. Après, faute
de description sur le wiki, chacun y met pour l'instant la signification
qui l'arrange.


Mais ici, ce n'est pas, à mon avis, une place qui nécessite une
représentation surfacique.


C'est subjectif, mais si on profitait de ce fil pour esquisser une 
manière de tracer les places sous l'angle landuse (l'enveloppe de la 
place, quand highway=*+area=yes n'est pas opportun), on aurait gagné 
quelque chose. Junction=yes pointé par Christian est pratique, mais 
cantonné à un noeud. C'est bien l'extension de l'idée à une surface qui 
m'intéresse ici (d'où le changement de nom du fil, au passage).


L'exemple de la place de la Concorde à Paris est très bon à ce titre 
(c'est pas moi qui a commencé, là :-) ). Plus de 25 ways portent le nom 
de la place, mais aucun ne décrit l'emprise de la place (ni aucun 
multipolygon). Bref on doit pouvoir faire mieux, avec une surface.


vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Ne garder que les noeuds qui sont résultat de requête dans un xml OSM

Bonjour,

Je pense que je suis ni le premier ni le dernier à rencontrer ce problème.

Certaines requêtes (API ou overpass) peuvent cibler des objets représentés
soit par des nœuds soit par des chemins.
Pour que les chemins aient un sens, on récupère également les nœuds qui les
constituent.

On a ainsi dans le résultat de la requête, des nœuds qui correspondent
directement à ce qu'on cherche et des nœuds qui servent de support à nos
chemins (qui eux correspondent aussi à ce qu'on cherche).

Pour extraire de l'information de tout ça (principalement une liste, pas
forcément un résultat graphique), il ne faut travailler que sur les nœuds
qui correspondent à ce qu'on cherche dans un premier temps, donc user
d'XPath par exemple.

Le problème est que certaines requêtes overpass (typiquement celles qui
ciblent plusieurs types de primitives comme celle-ci dessous) sont très
difficilement transposables en xpath pour filtrer le document OSM.

Je souhaite néanmoins ne réaliser qu'une seule requête à l'overpass (on
pourrait séparer nodes, ways, links mais je ne cèderai pas à la facilité).
J'espère ne pas me fourvoyer dans les hypothèses données ci-dessus, ce qui
est encore possible.


Quelqu'un aurait-il une piste pour sortir de ce genre d'embuches ?


La requête sur laquelle je travaille actuellement (sur oapi-fr)
(node
  [power~sub_station|substation]
  [operator=ERDF]
  [ref:ERDF:gdo];
way
  [power~sub_station|substation]
  [operator=ERDF]
  [ref:ERDF:gdo]
);
(._;;);
out body;


Merci par avance.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Question de rendu

Bonjour,

Je souhaiterais avoir l'avis de la liste à propos de la validité d'un
raisonnement qui est actuellement en cours d'élaboration pour les lignes
électriques.

Il peut concerner toutes les features de la même forme, peut-être
d'ailleurs que cette question a déjà été tranchée par le passé.

Actuellement ma proposition prévoit de ne documenter que les files de
pylones sans rentrer dans le détail des chemins empruntés par l'énergie
(circuits, ternes,...). Chaque file de pylône est représentée par une way
power=line comme peuvent l’être les autoroutes vis à vis d'un itinéraire
européen.
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#Power_lines

Dans un second temps on s'occupera de ces circuits avec des relations
power=circuit (exemple) dont les ways seront membre.
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal

Ainsi le nombre d'information qui concerne vraiment une file de pylône est
réduit, tout ce qui est tensions, nombre de conducteur, configuration des
conducteur se rapporte au circuit et donc sera mis sur la relation.

Tout ça dans le but de limiter le nombre de tag et d'incohérences dans les
données.
Il serait en effet peu efficace et prudent d'inciter tout le monde à
copier/coller les mêmes infos (les fréquences ou le nombre de conducteurs
par circuit) sur plusieurs objets alors qu'une relation peut mettre de
l'ordre d'un coup.

Parallèlement, on m'oppose qu'il sera très difficile de faire un rendu
comme celui-ci avec le schéma donné ci-dessus.
http://wiki.openstreetmap.org/wiki/File:Maperitive-power-sample.jpg dont le
contenu est donné ici
wiki.openstreetmap.org/wiki/User:Polderrunner/Maperitive_rules/Power_rules
En effet le moteur devra aller chercher les ways pour connaitre le
cheminement, puis ensuite mettre autant de traits que nécessaire suivant le
nombre de relations circuit dont la way est membre.

Êtes-vous aussi de cet avis ?

Merci par avance pour l'éclairage et les remarques constructives.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question de rendu

2013-10-06 Par sujet JB

 

Salut, 

Je ne crois pas dire de bêtise en indiquant que Maperitive va chercher
les informations dans les relations « comme un grand ». La problématique
est la même que pour tracer les sentiers de grande randonnée (non, non,
je vous en prie, pas de débat sur les GR…). Essaye la feuille de style
indiquée dans ton mél sur un fichier avec les informations dans la
relation, il me semble qu'elle devrait marcher. 

Sinon, essaye de remplacer : 

primary volt750: @isMatch (voltage,^115|^765000|^75|^735000)
AND power=line

et les suivantes par 

primary volt750: relation[@isMatch
(voltage,^115|^765000|^75|^735000) AND power=line]

Si tu n'es pas trop pressé, je peux essayer, mais seulement lundi ou
mercredi soir… 

Pour ce qui est de Mapnik, je ne me prononce pas. 

JB. 

Le 06.10.2013 19:13, François Lacombe a écrit : 

 Bonjour,
 
 Je souhaiterais avoir l'avis de la liste à propos de la validité d'un 
 raisonnement qui est actuellement en cours d'élaboration pour les lignes 
 électriques.
 
 Il peut concerner toutes les features de la même forme, peut-être d'ailleurs 
 que cette question a déjà été tranchée par le passé. Actuellement ma 
 proposition prévoit de ne documenter que les files de pylones sans rentrer 
 dans le détail des chemins empruntés par l'énergie (circuits, ternes,...). 
 Chaque file de pylône est représentée par une way power=line comme peuvent 
 l'être les autoroutes vis à vis d'un itinéraire européen.
 http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#Power_lines
  [2]
 
 Dans un second temps on s'occupera de ces circuits avec des relations 
 power=circuit (exemple) dont les ways seront membre.
 http://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal 
 [3]
 
 Ainsi le nombre d'information qui concerne vraiment une file de pylône est 
 réduit, tout ce qui est tensions, nombre de conducteur, configuration des 
 conducteur se rapporte au circuit et donc sera mis sur la relation.
 
 Tout ça dans le but de limiter le nombre de tag et d'incohérences dans les 
 données. 
 Il serait en effet peu efficace et prudent d'inciter tout le monde à 
 copier/coller les mêmes infos (les fréquences ou le nombre de conducteurs par 
 circuit) sur plusieurs objets alors qu'une relation peut mettre de l'ordre 
 d'un coup. 
 
 Parallèlement, on m'oppose qu'il sera très difficile de faire un rendu comme 
 celui-ci avec le schéma donné ci-dessus.
 http://wiki.openstreetmap.org/wiki/File:Maperitive-power-sample.jpg [4] dont 
 le contenu est donné ici 
 wiki.openstreetmap.org/wiki/User:Polderrunner/Maperitive_rules/Power_rules 
 [5] 
 En effet le moteur devra aller chercher les ways pour connaitre le 
 cheminement, puis ensuite mettre autant de traits que nécessaire suivant le 
 nombre de relations circuit dont la way est membre.
 
 Êtes-vous aussi de cet avis ? 
 
 Merci par avance pour l'éclairage et les remarques constructives.
 
 FRANÇOIS LACOMBE
 
 francois dot lacombe At telecom-bretagne dot eu
 http://www.infos-reseaux.com [6] 
 
 ___
 Talk-fr mailing list
 Talk-fr@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/talk-fr [1]

 

Links:
--
[1] https://lists.openstreetmap.org/listinfo/talk-fr
[2]
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#Power_lines
[3]
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal
[4] http://wiki.openstreetmap.org/wiki/File:Maperitive-power-sample.jpg
[5]
http://wiki.openstreetmap.org/wiki/User:Polderrunner/Maperitive_rules/Power_rules
[6] http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question de rendu

Bonsoir JB, merci pour ce retour.

Actuellement, seule la way power=line est établie, on sait à peu près à
quoi vont ressembler ses attributs.
Pour ce qui est de la relation circuit, la proposition qui la concerne
est encore à l'état de Draft et est loin d'être complète. On peut tester,
mais il faudra faire attention.

Par ailleurs, où peut-on tester des règles maperitive / mapnik ? Je n'ai
pas l'infra perso pour le faire, si tu peux regarder c'est très volontiers.

Pour ce qui est de

primary volt750: relation[@isMatch
(voltage,^115|^765000|^75|^735000) AND power=line]

power=line se réfère-t-il à la relation où à une way membre selon cette
règle ?

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com

Le 6 octobre 2013 19:44, JB jb...@mailoo.org a écrit :

Salut,

Je ne crois pas dire de bêtise en indiquant que Maperitive va chercher les
informations dans les relations « comme un grand ». La problématique est la
même que pour tracer les sentiers de grande randonnée (non, non, je vous
en prie, pas de débat sur les GR…). Essaye la feuille de style indiquée
dans ton mél sur un fichier avec les informations dans la relation, il me
semble qu'elle devrait marcher.

Sinon, essaye de remplacer :

primary volt750: @isMatch (voltage,^115|^765000|^75|^735000) AND
power=line

et les suivantes par

primary volt750: relation[@isMatch
(voltage,^115|^765000|^75|^735000) AND power=line]

Si tu n'es pas trop pressé, je peux essayer, mais seulement lundi ou
mercredi soir…

Pour ce qui est de Mapnik, je ne me prononce pas.

JB.

Le 06.10.2013 19:13, François Lacombe a écrit :

Bonjour,

Je souhaiterais avoir l'avis de la liste à propos de la validité d'un
raisonnement qui est actuellement en cours d'élaboration pour les lignes
électriques.

Il peut concerner toutes les features de la même forme, peut-être
d'ailleurs que cette question a déjà été tranchée par le passé.
Actuellement ma proposition prévoit de ne documenter que les files de
pylones sans rentrer dans le détail des chemins empruntés par l'énergie
(circuits, ternes,...). Chaque file de pylône est représentée par une way
power=line comme peuvent l’être les autoroutes vis à vis d'un itinéraire
européen.

http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#Power_lines

Dans un second temps on s'occupera de ces circuits avec des relations
power=circuit (exemple) dont les ways seront membre.
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal

Ainsi le nombre d'information qui concerne vraiment une file de pylône est
réduit, tout ce qui est tensions, nombre de conducteur, configuration des
conducteur se rapporte au circuit et donc sera mis sur la relation.

Tout ça dans le but de limiter le nombre de tag et d'incohérences dans les
données.
Il serait en effet peu efficace et prudent d'inciter tout le monde à
copier/coller les mêmes infos (les fréquences ou le nombre de conducteurs
par circuit) sur plusieurs objets alors qu'une relation peut mettre de
l'ordre d'un coup.

Parallèlement, on m'oppose qu'il sera très difficile de faire un rendu
comme celui-ci avec le schéma donné ci-dessus.
http://wiki.openstreetmap.org/wiki/File:Maperitive-power-sample.jpg dont
le contenu est donné ici
wiki.openstreetmap.org/wiki/User:Polderrunner/Maperitive_rules/Power_rules
En effet le moteur devra aller chercher les ways pour connaitre le
cheminement, puis ensuite mettre autant de traits que nécessaire suivant le
nombre de relations circuit dont la way est membre.

Êtes-vous aussi de cet avis ?

Merci par avance pour l'éclairage et les remarques constructives.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com

___
Talk-fr mailing
listTalk-fr@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-fr

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question de rendu

2013-10-06 Par sujet JB

 

 Par ailleurs, où peut-on tester des règles maperitive / mapnik ? Je n'ai pas 
 l'infra perso pour le faire, si tu peux regarder c'est très volontiers.

J'essayerai ça cette semaine avec Maperitive (y'a pas besoin de grand
chose… c'est juste limité en taille de données en entrée, mais avec un
osmfilter ou un truc du genre, tu dois t'en sortir en gardant juste les
données énergie sur la France…). Pour Mapnik, mon regard se tourne
plutôt vers Christian, Frédéric ou d'autres… Le jour où un atelier
présentera comment importer sa base Postgré (pour les nuls), j'arriverai
peut-être à m'y mettre. 

 Pour ce qui est de 
 
 primary volt750: relation[@isMatch 
 (voltage,^115|^765000|^75|^735000) AND power=line]
 
 power=line se réfère-t-il à la relation où à une way membre selon cette règle 
 ?
 Bonne question, peut-être bien qu'il faut le supprimer… 
JB. 
 ___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question de rendu

Le 06/10/2013 19:13, François Lacombe a écrit :

Bonjour,

Je souhaiterais avoir l'avis de la liste à propos de la validité d'un
raisonnement qui est actuellement en cours d'élaboration pour les lignes
électriques.

Il peut concerner toutes les features de la même forme, peut-être
d'ailleurs que cette question a déjà été tranchée par le passé.

Actuellement ma proposition prévoit de ne documenter que les files de
pylones sans rentrer dans le détail des chemins empruntés par l'énergie
(circuits, ternes,...). Chaque file de pylône est représentée par une
way power=line comme peuvent l’être les autoroutes vis à vis d'un
itinéraire européen.
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement#Power_lines

Dans un second temps on s'occupera de ces circuits avec des relations
power=circuit (exemple) dont les ways seront membre.
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal

Ainsi le nombre d'information qui concerne vraiment une file de pylône
est réduit, tout ce qui est tensions, nombre de conducteur,
configuration des conducteur se rapporte au circuit et donc sera mis sur
la relation.

Tout ça dans le but de limiter le nombre de tag et d'incohérences dans
les données.
Il serait en effet peu efficace et prudent d'inciter tout le monde à
copier/coller les mêmes infos (les fréquences ou le nombre de
conducteurs par circuit) sur plusieurs objets alors qu'une relation peut
mettre de l'ordre d'un coup.

Parallèlement, on m'oppose qu'il sera très difficile de faire un rendu
comme celui-ci avec le schéma donné ci-dessus.
http://wiki.openstreetmap.org/wiki/File:Maperitive-power-sample.jpg dont
le contenu est donné ici
wiki.openstreetmap.org/wiki/User:Polderrunner/Maperitive_rules/Power_rules
http://wiki.openstreetmap.org/wiki/User:Polderrunner/Maperitive_rules/Power_rules
En effet le moteur devra aller chercher les ways pour connaitre le
cheminement, puis ensuite mettre autant de traits que nécessaire suivant
le nombre de relations circuit dont la way est membre.

Êtes-vous aussi de cet avis ?

Tu cherches à modéliser les circuits par des relations, en t'appuyant
sur la description physique du réseau, faite de ways et nodes. Autant de
circuits, autant de relations, mais pas de duplication des ways et nodes
(sauf erreur d'interprétation de ma part). Si c'est bien ce principe,
alors il y a au moins le précédent de la modélisation des réseaux de
transport, notamment de type bus. Dans la base, en gros, les lignes de
bus sont des relations qui agrègent des ways de type highway=*. Le même
highway sera inclus dans autant de relations qu'on a de parcours de bus
qui l'empruntent.

Si l'analogie est correcte, si on t'oppose que ça rend le rendu pas
facile avec Maperitive, c'est vraiment se tromper de débat. Ta
modélisation est carrée, sans redondance. Aux logiciels de s'adapter.
Sachant qu'une carte de réseaux multiples s'appuyant sur la même
infrastructure physique, c'est quoi qu'il arrive une prise de tête.

Est-ce que tes contradicteurs proposent une autre manière de faire ?

vincent

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question de rendu

Bonsoir Vincent,

Le 6 octobre 2013 22:37, Vincent de Château-Thierry v...@laposte.net a
écrit :

 Tu cherches à modéliser les circuits par des relations, en t'appuyant sur
 la description physique du réseau, faite de ways et nodes. Autant de
 circuits, autant de relations, mais pas de duplication des ways et nodes
 (sauf erreur d'interprétation de ma part). Si c'est bien ce principe, alors
 il y a au moins le précédent de la modélisation des réseaux de transport,
 notamment de type bus. Dans la base, en gros, les lignes de bus sont des
 relations qui agrègent des ways de type highway=*. Le même highway sera
 inclus dans autant de relations qu'on a de parcours de bus qui l'empruntent.


Je suis tout à fait d'accord, c'est ce que je prévois de mettre en place.


 Est-ce que tes contradicteurs proposent une autre manière de faire ?


Non c'est vrai, la discussion s'est terminée par trouve autre chose.
Je reste comme toi convaincu par l'aspect sexy de la modélisation sans
redondance.

Après je vois deux choses :
- Ce genre de carte est limite incontournable pour ce genre de réseaux.
Ne pas pouvoir la réaliser n'est pas forcément une bonne chose. Reste à
savoir si Maperitive/Mapnik pourra s'adapter.
- Je suis pour une modélisation correcte avant de regarder les possibilité
de rendu. Les utilisateurs que j'ai en face de moi font souvent l'inverse
(ou se focalisent sur un point précis sans voir le problème global) et
refusent les proposition lors des phases de vote :(

François.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Question de rendu



Le 06/10/2013 22:55, François Lacombe a écrit :


Après je vois deux choses :
- Ce genre de carte est limite incontournable pour ce genre de
réseaux. Ne pas pouvoir la réaliser n'est pas forcément une bonne chose.
Reste à savoir si Maperitive/Mapnik pourra s'adapter.
- Je suis pour une modélisation correcte avant de regarder les
possibilité de rendu. Les utilisateurs que j'ai en face de moi font
souvent l'inverse (ou se focalisent sur un point précis sans voir le
problème global) et refusent les proposition lors des phases de vote :(


Il ne s'agit pas d'empêcher la réalisation de cartes... mais pas non 
plus de devoir se plier aux contraintes des moteurs de rendu live, 
qui, plus contraints que les autres, devraient censurer une modélisation 
correcte afin de permettre une mise à jour minute par minute. Si la 
donnée est complexe parce que modélisée correctement (à coup de 
relations, et oui), elle est peut-être difficile à manipuler en temps 
réel. Mais dans ce cas, aux moteurs d'adopter d'autres stratégies, par 
exemple à coup de pré-calcul.


vincent

ps. Christian, si ça te rappelle une histoire de tag population=* sur 
les nodes, c'est normal ;-)


___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Explosion d'un carrefour

2013-10-06 Par sujet hamster

Le 06/10/2013 16:43, Christophe Merlet a écrit :
 Il n'y a rien d'acrobatique a donner à une voie le nom d'une place.
 C'est la pratique usuelle.

Mais dans les pratiques usuelles il y en a aussi qui sont mauvaises et
qu'il faut changer.

Presentement c'est une mauvaise pratique parce qu'elle n'est pas logique.

 Mais ici, ce n'est pas, à mon avis, une place qui nécessite une
 représentation surfacique.

Alors que les bouts de verdure qui sont dedans meritent une
representation surfacique ? Ou bien est-ce que tu prefererais qu'on les
remplace par un point ? Ou bien qu'on les mette pas du tout (et dans ce
cas ca veut dire que tu est oppose a toutes formes de micro mapping) ?

Je m'abstiens de juger si telle ou telle place merite ou pas une
representation surfacique, je constate quelques trucs :
- On a un outil pour les cas qui ne meritent pas une representation
surfacique : on met name=place machin sur un node au milieu.
- On n'a pas d'outil pour les cas qui meritent une representation
surfacique, il faut donc en creer un.
- On a plus ou moins pris l'habitude de bidouiller pour essayer de
decrire des surfaces avec du filaire, ce qui est du mauvais bricolage.
- Si on fait le choix de decrire le detail de ce qui est dans la place,
alors la place elle meme est plus importante et merite donc d'etre
representee correctement. Avoir du micro mapping (y compris surfacique
pour la verdure) dans une place qu'on trouve ne pas meriter d'etre
representee en surfacique est hubuesque.

Si on trouve que cette place ne merite pas d'etre representee par une
surface, alors la solution est simplissime : on fait se rejoindre toutes
les rues qui arrivent sur la place en un point, sur lequel on met le nom
de la place et les feux. Et on abandonne la volonte de dessiner les
differents bouts de voie, les sens uniques qui y correspondent, les
passages cloutes, les barrieres au bord des trottoirs, les bouts de
verdure, etc.

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Ne garder que les noeuds qui sont résultat de requête dans un xml OSM