Re: [OSM-talk-fr] Nous sommes champion du monde sur OSM ?!

[Gilles Bassière]

Le lundi 28 mai 2012 à 22:17 +0200, Christophe Merlet a écrit :
> Par contre son script est intéressant. 
> J'aimerais bien connaitre les stats de tuiles utiles (ayant au moins 1
> node) pour chaque niveau de zoom...

Le mail original annonce (pour le zoom level 16) :
- 67 millions de méta-tuiles au total
- seulement 20 millions qui ne sont pas dans la mer
- parmi ces dernières, 4.4 millions ont au moins un nœud

http://lists.openstreetmap.org/pipermail/talk/2012-May/063067.html

Cordialement
-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/



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

Re: [OSM-talk-fr] Nous sommes champion du monde sur OSM ?!

[Ab_fab]

Bonjour,

F. Ramm met le script à disposition, pour les intéressés :

"If anyone wants to do something interesting with it, the full file of
all 4.4 million metatiles and how many nodes on them is available on
request (or the rather primitive script that makes the list from a
planet file)."
->  frederik at remote.org

Cordialement

Le 29 mai 2012 09:04, Gilles Bassière  a écrit :
>
> Le lundi 28 mai 2012 à 22:17 +0200, Christophe Merlet a écrit :
> > Par contre son script est intéressant.
> > J'aimerais bien connaitre les stats de tuiles utiles (ayant au moins 1
> > node) pour chaque niveau de zoom...
>
> Le mail original annonce (pour le zoom level 16) :
> - 67 millions de méta-tuiles au total
> - seulement 20 millions qui ne sont pas dans la mer
> - parmi ces dernières, 4.4 millions ont au moins un nœud
>
> http://lists.openstreetmap.org/pipermail/talk/2012-May/063067.html
>
> Cordialement
> --
> Gilles Bassière - Web/GIS software engineer
> http://gbassiere.free.fr/
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr




--
ab_fab
"Il n'y a pas de pas perdus"

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

[forum-osm-fr]Quelqu'un peut corriger ma premi�re contribution ?

[forum]

Le message suivant de Kerion:
##
Bonjour,

Je viens d'ajouter un 
[url=http://www.openstreetmap.org/browse/changeset/11736007]premier tracé[/url] 
à partir de mon fichier gpx mais j'ai de nombreux doutes :



je ne l'ai pas fusionné car cette partie est plus étroite (j'ai indiqué lane = 
1) est-ce correct ?

s'il faut fusionner, j'ignore quelle est la toponymie exacte car le panneau 
indique "Chemin de Kerion" et l'intitulé dans osm est "Chemin de Quirion"

enfin mais c'est peut-être un détail inutile, les derniers mètres de la route 
sont en gravier et non asphaltés, dans ce cas comment l'indiquer ?



Quelqu'un pourrait-il corriger et m'indiquer les erreurs ?



Merci d'avance 

a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2
Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part
Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une 
concertation sur la liste avant de recopier 
la/les meilleurs réponses sur le forum.
Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre.
--
Les questions sur ce robot de transfert forum->liste
peuvent être posées à sylvainaletuffe.org

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

Re: [OSM-talk-fr] Nous sommes champion du monde sur OSM ?!

[Philippe Verdy]

Ce qui m'inquiète plutôt c'est l'absence de nombre de villes ailleurs
dans le monde. Si on cartographiait avec le même niveau de détail que
tous les bâtiments de Fort-de-France, ceux des Favelas de Rio de
Janeiro ou de Kolkatta, on aurait une grand nombre de tuiles tout
autour qui auraient la même densité de point, voire beaucoup plus.

Si Fort-de-France apparaît en tête alors que la tuile référencée
compte encore de larges espaces inoccupés, c'est à cause de la densité
dans certaines zones de toutes petites constructions issues des
anciens bidonvilles, plus ou moins bien convertis avec le temps en
constructions durables, autorisées et enregistrées dans le cadastre.
Dans ce cas, on pourrait voir aussi ce qui manque à Mayotte (où c'est
encore bien plus dense, mais encore mal cartographié car il y a de
nombreuses constructions non déclarées), ou à Saint-Denis (de la
Réunion).

Toutefois je me pose des questions sur le fait que le secteur
identifié à Fort-de-France ne contiendrait pas des tonnes de
constructions importées avec des nœuds et ways en double. Pour
l'instant je n'ai pas voulu m'occuper de télécharger les données mais
si quelqu'un a du temps et ne sait pas où travailler, il pourrait
regarder pour voir si ce n'est pas le cas.

Ce script calculé en densité de points ne sert sinon pas à grand chose
si on ne lui adjoint pas un contrôle des géométries et superpositions
de points. Malheureusement Les outils qu'on utilise en France
métropolitaine ou en Europe ne vont pas chercher les données en
outre-mer pour faire leur analyse.

Sauf "Layers.OpenStreetMap.FR" mais qui ne s'occupe que de regarder
les frontières administratives (ce qui lui permet de traiter le monde
entier avec un volume de données finalement assez réduit).

On peut noter que plus de 95% des nœuds dans la base de données
proviennent des imports de bâtiments, et pour la grande majorité
d'entre eux, sont en France (un signe que notre cadastre national est
finalement bien mieux renseigné que ceux de nombreux pays, pour ne pas
citer celui de la Grèce par exemple et qu'on cite souvent comme un
mauvais exemple dans l'actualité en ce moment), mais que des pays qui
ont pourtant l'habitude de mettre en fichiers énormément de choses
dans toutes sortes d'administrations (qui sont tenues de publier leurs
données par la loi, je parle ici des États-Unis) ont eux aussi des
grosses lacunes.

(peut-être parce que ces même administrations ont souvent des
difficultés financières, et des grosses difficultés à croiser de façon
cohérente leurs données publiques, ou parce qu'ils les ont
externalisées en en confiant la charge à des sociétés privées qui les
diffusent de manière restrictives, mais peut-être aussi parce que les
Américains tiennent absolument à leur vie privée : ce qui se passe
chez eux ne regarde pas pour eux les administrations : il y a une
culture pour tout ouvrir de ce qui est public, mais au contraire de
garder strictement privé ce qui est dans le domaine des propriétés
privées considérées réellement comme des 'sanctuaires" jalousement
gardés pour nombre d'Américains).

Ou bien c'est parce que des restrictions légales de droit d'auteur et
d'ncompatibilité de licences les empêche d'importer des données de
fichiers pourtant facilement accessibles (souvent librement mais sous
une licence différente, car ce n'est pas toujours le domaine public
légal américain, ou parce que ce domaine public américain n'est libre
et dans le domaine public QUE aux USA mais restreint ailleurs : OSM
légalement étant aux Royaume-Uni, de telles données ne seraient alors
pas facilement importables).

Ou alors parce que les données accesssibles sont dans des formats
disparâtres pour lesquels des outils de conversion spécifiques sont à
écrire. (Note: je ne m'étonne pas que peu de zones aux USA soient
listées, car le territoire immense est très peu densément construit
hormi les grandes métropoles, et même des agglomérations immenses
comme Los Angeles sont très peu denses, c'est même une raison majeure
de leur expansion territoriale immense : ils se sont étalés largement
sur des distances considérables).

Sinon je m'attendais à voir Moscou listé, de même qu'Ankara, et
quelques villes israéliennes (à défaut de celles de l'autorité
palestinienne qui sont parmi les plus densément peuplées au monde,
mais largement sous-équipées faute de moyens et d'administration
stable)...

Le 28 mai 2012 22:17, Christophe Merlet  a écrit :
> Le lundi 28 mai 2012 à 15:11 +0200, hamster a écrit :
>> Le 28/05/2012 14:35, Vladimir Vyskocil a écrit :
>> > De densité de nodes par tuile ! :-)
>> >
>> > http://fred.dev.openstreetmap.org/density/
>>
>> as tu bien vu que le premier est en bas de la liste et pas en haut ?
>> le champion est a fort de france, alors d'accord c'est dans un DOM/TOM
>> donc en france
>>
>> de plus je ne vois pas grenoble, qui a pourtant la reputation d'etre
>> tres bien cartographie, ca pose la question de la pertinence de cet
>> indicateur
>>
>> un import imbecile du cadastre,

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Vincent Calame]

Malgré ces "avantages" a fort zoom, OpenMapQuest a un gros inconvénient
a zoom moyen : on y voit fort peu de commune ce qui rend
l'interprétation de certaines cartes très difficile pour
l'utilisateur... Aujourd'hui je m'y penche un peu et je m'aperçois qua
priori dans mon coin en tout cas, MapQuest n'affiche que les place=town
pas les place=village (il ne semble pas tenir compte de la
population)...
[...]

Bon je reste zen et j'essaye un "feedback" a openmapquest (sans trop y
croire), mais bon c'est pas un bug, c'est juste un "problème" de
rendu...


Je suis d'accord avec toi, la sélection des étiquettes est le gros point 
noir des rendus actuels avec des tuiles complètement muettes à zoom 
moyen en milieu rural où tout est place=village. Le critère de 
population est un critère quantitatif insuffisant car les communes 
française sont petites et la population de la commune centre ne 
représente pas la population de l'agglomération et donc son importance 
réelle.



Il y a une sorte de tabou sur l'ajout d'un critère qualitatif pour les 
agglomérations qui permettraient aux moteurs de rendu ou à d'autres de 
faire un tri sur une base autre que le seule population.


Vincent



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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[sly (sylvain letuffe)]

> la sélection des étiquettes est le gros point 
> noir des rendus actuels avec des tuiles complètement muettes à zoom 
> moyen en milieu rural où tout est place=village. 
> Le critère de  
> population est un critère quantitatif insuffisant 

Je suis d'accord


> car les communes  
> française sont petites et la population de la commune centre 
> ne  représente pas la population de l'agglomération et donc son importance 
> réelle.

C'est quoi la "commune centre" ?

> Il y a une sorte de tabou sur l'ajout d'un critère qualitatif pour les 
> agglomérations qui permettraient aux moteurs de rendu ou à d'autres de 
> faire un tri sur une base autre que le seule population.

Un tabou je ne pense pas, plus un refus sans doute, car cette solution n'est 
pas forcément la meilleure car elle inclurait dans le tagging une notion bien 
subjective "d'importance". Alors qu'il existe peut être d'autre informations 
objectives (à définir) que l'on pourrait renseigner, qui permettrait 
peut-être ensuite d'avoir des rendus de meilleure qualité, ou, tout du moins, 
plus adaptés à ce que l'on veut en faire.

Perso en tout cas, je ne suis pas contre un débat sur cette question 
d'importance et discuter pour savoir si le problème ne serait pas ailleurs.

J'aurais tendance à penser que le tagging des noeuds "place=*" a tellement été 
fait, au fil des années, dans le but de faire un joli rendu de map...@osm.org 
qu'on en arrive à un point où si on touche à un paramètre de rendu de style 
(zzom, condition, nouvelle manière de concevoir le positionnement), le 
château de carte s'effondre.
Mon sentiment est en partie liée à une méthode de tagging pas/peu homogène à 
l'échelle du globe qui amène un rendu couvrant le monde à toujours merder 
quelque part.

ps: je n'ai pas dis que j'avais une solution

-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org

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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Philippe Verdy]

Justement le tag capital=* permettrait de cartographier en plus de
façon plus qualitative (mais basée tout de même sur un critère
objectif et facilement vérifiable et stable) bon nombre de chef-lieux
d'entités administratives plus petites.

Parce que ce tag peut se mettre directement un nœud (comme aussi le
tag place=*) dans devoir aller chercher dans quelle relation ce nœud
est mentionné comme "admin_centre" (OpenMapQuest ne semble pas en
tenir compte).

En ayant les deux tags au même endroit (place=* et capital=*) au
niveau du noeud central d'une ville, on a un second critère pour faire
apparaître plus de choses et savoir (en cas de multiplicité de choix
et d'impossibilité d'afficher tout le monde en même temps sans
superposition des libellés) quelle ville il vaut mieux conserver
affichée.

Comme je l'ai dit, ça marche très bien en Espagne ! Aussi bien pour
OpenMapquest que pour Mapnik d'ailleurs ! La France étant très
similaire à l'Espagne dans on organisation administrative, on pourrait
s'en inspirer car cela n'a pas nécessité en Espagne de réellement
"taguer pour le rendu", puisque ce qui est mis est quelquechose
d'objectif et utile, facile à sélectionner et trouver pour de nombreux
types de d'extractions et filtrages de données depuis la base de
données (nettement plus facile qu'une requête purement géométrique,
bien plus compliquée à réaliser à cause (1) du volume de données à
traiter et de nombreuses ambiguïtés d'interprétation et d'oublis soit
dans la base soit dans la requête, et (2) dont les résultats sont très
souvent instables, et hasardeux au gré des modifications et ajouts de
données successifs).

On peut noter aussi que des choix de dénormalisation ont été faits
déjà dans la base (qui consiste à multiplier des tags sur des niveaux
de représentation différents entre les briques géométriques de base,
nœuds et ways, et les relations) pour faciliter des traitements mais
aussi à cause de l'instabilité des données et de leur incomplétude
(qui n'est jamais garantie nulle part). On a donc différentes façons
d'utiliser les données, avec des axes de recherche différents.

Ajouter un petit tag "capital=*" sur les nœuds des communes chef-lieux
ne coûterait pas grand chose : c'est simple à faire, peu volumineux,
facile à vérifier, et cela renforce les possibilités de maintien de la
cohérence, et facilite énormément la restauration de ce qui aurait pu
être brisé par une modification ou un ajout incomplet (rappelons que
la base OSM ne sera jamais complète), ou d'une modification faite par
erreur quelquepart, sans avoir à fouiller dans des données pas
facilement géolocalisables (les nœuds centraux de communes n'ont pas
de matérialité sur le terrain, on ne sait donc pas réellement où les
trouver s'ils ne sont pas associés à un élément plus large, avec un
critère simple pour discriminer facilement parmi des milliers d’autres
nœuds dans la même zone).

Le 29 mai 2012 16:26, Vincent Calame  a écrit :
> Je suis d'accord avec toi, la sélection des étiquettes est le gros point
> noir des rendus actuels avec des tuiles complètement muettes à zoom moyen en
> milieu rural où tout est place=village. Le critère de population est un
> critère quantitatif insuffisant car les communes française sont petites et
> la population de la commune centre ne représente pas la population de
> l'agglomération et donc son importance réelle.
>
> Il y a une sorte de tabou sur l'ajout d'un critère qualitatif pour les
> agglomérations qui permettraient aux moteurs de rendu ou à d'autres de faire
> un tri sur une base autre que le seule population.

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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Nicolas Dumoulin]

Le mardi 29 mai 2012 16:55:23 Philippe Verdy a écrit :
> Justement le tag capital=* permettrait de cartographier en plus de
> façon plus qualitative (mais basée tout de même sur un critère
> objectif et facilement vérifiable et stable) bon nombre de chef-lieux
> d'entités administratives plus petites.

Bonjour,

Oui, effectivement, l'information objective du chef-lieu administratif serait 
pertinent pour trier les place=* à afficher.
Par contre, je ne crois pas que le capital=* soit nécessaire pour les 
communes, puisque nous avons déjà le rôle admin_centre sur les relations 
administratives.

Je comprends tout à fait qu'il peut apparaître plus pratique de retirer 
l'information sur un nœud sans avoir à prendre en compte d'autres objets de la 
base. Je comprends aussi que l'utilisation du tag capital ait un effet 
bénéfique 
dans d'autres contrées. Mais il apparaît évident que l'on parle là de modifier 
le « modèle » accepté par la communauté pour que les moteurs de rendu actuel 
ait un comportement désiré.

Pour un moteur de rendu manipulant la base de données complète, il ne 
m'apparaît pas très compliqué de rendre en priorité les chefs-lieux 
administratifs. Je fais d'ailleurs noter au passage, que « chef-lieu » 
s'accorde « chefs-lieux » au pluriel. En fait, j'aurai pu faire la même 
erreur, mais c'est en relisant la citation que j'ai eu un doute. Donc voilà, 
c'est fait.

Par ailleurs, quand je parle de chefs-lieux, je veux surtout parler des chefs-
lieux de communes et de département. Quoiqu'il serait probablement intéressant 
aussi d'intégrer le niveau cantonal, je pense que ces deux niveaux permettrait 
de régler bon nombre de désagréments visuels.

Maintenant, je ne connais pas tous les détails … doit-on modifier le script 
d'import des données OSM dans la base postgis pour faciliter l'accès à 
l'information admin_centre ? Pour mettre en priorité les nœuds portant cette 
information dans la feuille de style mapnik, j'imagine qu'il faille modifier 
les requêtes SQL des couches appropriées. Mais j'avoue ne pas y avoir regarder 
de plus près.

Au final, je ne sais pas si mon message est pertinent, mais je tenais à donner 
mon avis sur la question. Et il est vrai que ce soucis de rendu est un peu 
ennuyeux dans les zones rurales qui sont pourtant si importantes (et si 
étendues). On pourrait encore parler de la sous-évaluation des territoires 
ruraux par les populations urbaines, mais je dois y aller, on verra une autre 
fois.

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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Arnaud Vandecasteele]

Bonjour à tous,

C'est peut être aussi une des limites des méthodes collaboratives et
mondiales.
Comment en effet avoir un rendu pertinent pour des régions aussi disparates
?
Je prêche pour ma paroisse, mais une solution serait (peut être) de penser
à une modélisation logique des informations.
Cela permettrait de réduire les problèmes d'hétérogénéité sémantiques
rencontrés.
Un exemple serait la base geonames dont les informations peuvent être
obtenues sous une forme ontologique (RDF) :
http://www.geonames.org/

Arnaud



2012/5/29 Nicolas Dumoulin 

> Le mardi 29 mai 2012 16:55:23 Philippe Verdy a écrit :
> > Justement le tag capital=* permettrait de cartographier en plus de
> > façon plus qualitative (mais basée tout de même sur un critère
> > objectif et facilement vérifiable et stable) bon nombre de chef-lieux
> > d'entités administratives plus petites.
>
> Bonjour,
>
> Oui, effectivement, l'information objective du chef-lieu administratif
> serait
> pertinent pour trier les place=* à afficher.
> Par contre, je ne crois pas que le capital=* soit nécessaire pour les
> communes, puisque nous avons déjà le rôle admin_centre sur les relations
> administratives.
>
> Je comprends tout à fait qu'il peut apparaître plus pratique de retirer
> l'information sur un nœud sans avoir à prendre en compte d'autres objets
> de la
> base. Je comprends aussi que l'utilisation du tag capital ait un effet
> bénéfique
> dans d'autres contrées. Mais il apparaît évident que l'on parle là de
> modifier
> le « modèle » accepté par la communauté pour que les moteurs de rendu
> actuel
> ait un comportement désiré.
>
> Pour un moteur de rendu manipulant la base de données complète, il ne
> m'apparaît pas très compliqué de rendre en priorité les chefs-lieux
> administratifs. Je fais d'ailleurs noter au passage, que « chef-lieu »
> s'accorde « chefs-lieux » au pluriel. En fait, j'aurai pu faire la même
> erreur, mais c'est en relisant la citation que j'ai eu un doute. Donc
> voilà,
> c'est fait.
>
> Par ailleurs, quand je parle de chefs-lieux, je veux surtout parler des
> chefs-
> lieux de communes et de département. Quoiqu'il serait probablement
> intéressant
> aussi d'intégrer le niveau cantonal, je pense que ces deux niveaux
> permettrait
> de régler bon nombre de désagréments visuels.
>
> Maintenant, je ne connais pas tous les détails … doit-on modifier le script
> d'import des données OSM dans la base postgis pour faciliter l'accès à
> l'information admin_centre ? Pour mettre en priorité les nœuds portant
> cette
> information dans la feuille de style mapnik, j'imagine qu'il faille
> modifier
> les requêtes SQL des couches appropriées. Mais j'avoue ne pas y avoir
> regarder
> de plus près.
>
> Au final, je ne sais pas si mon message est pertinent, mais je tenais à
> donner
> mon avis sur la question. Et il est vrai que ce soucis de rendu est un peu
> ennuyeux dans les zones rurales qui sont pourtant si importantes (et si
> étendues). On pourrait encore parler de la sous-évaluation des territoires
> ruraux par les populations urbaines, mais je dois y aller, on verra une
> autre
> fois.
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

Arnaud Van De Casteele
Mines Paris Tech - CRC
Sophia-Antipolis
0698 24 25 29
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/
http://geotribu.net/
http://www.i2c.eu/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Christophe Merlet]

Le mardi 29 mai 2012 à 17:25 +0200, Nicolas Dumoulin a écrit :
> Le mardi 29 mai 2012 16:55:23 Philippe Verdy a écrit :
> > Justement le tag capital=* permettrait de cartographier en plus de
> > façon plus qualitative (mais basée tout de même sur un critère
> > objectif et facilement vérifiable et stable) bon nombre de chef-lieux
> > d'entités administratives plus petites.
> 
> Bonjour,
> 
> Oui, effectivement, l'information objective du chef-lieu administratif serait 
> pertinent pour trier les place=* à afficher.
> Par contre, je ne crois pas que le capital=* soit nécessaire pour les 
> communes, puisque nous avons déjà le rôle admin_centre sur les relations 
> administratives.
> 
> Je comprends tout à fait qu'il peut apparaître plus pratique de retirer 
> l'information sur un nœud sans avoir à prendre en compte d'autres objets de 
> la 
> base. Je comprends aussi que l'utilisation du tag capital ait un effet 
> bénéfique 
> dans d'autres contrées. Mais il apparaît évident que l'on parle là de 
> modifier 
> le « modèle » accepté par la communauté pour que les moteurs de rendu actuel 
> ait un comportement désiré.
> 
> Pour un moteur de rendu manipulant la base de données complète, il ne 
> m'apparaît pas très compliqué de rendre en priorité les chefs-lieux 
> administratifs. Je fais d'ailleurs noter au passage, que « chef-lieu » 
> s'accorde « chefs-lieux » au pluriel. En fait, j'aurai pu faire la même 
> erreur, mais c'est en relisant la citation que j'ai eu un doute. Donc voilà, 
> c'est fait.
> 
> Par ailleurs, quand je parle de chefs-lieux, je veux surtout parler des chefs-
> lieux de communes et de département. Quoiqu'il serait probablement 
> intéressant 
> aussi d'intégrer le niveau cantonal, je pense que ces deux niveaux 
> permettrait 
> de régler bon nombre de désagréments visuels.
> 
> Maintenant, je ne connais pas tous les détails … doit-on modifier le script 
> d'import des données OSM dans la base postgis pour faciliter l'accès à 
> l'information admin_centre ? Pour mettre en priorité les nœuds portant cette 
> information dans la feuille de style mapnik, j'imagine qu'il faille modifier 
> les requêtes SQL des couches appropriées. Mais j'avoue ne pas y avoir 
> regarder 
> de plus près.
> 
> Au final, je ne sais pas si mon message est pertinent, mais je tenais à 
> donner 
> mon avis sur la question. Et il est vrai que ce soucis de rendu est un peu 
> ennuyeux dans les zones rurales qui sont pourtant si importantes (et si 
> étendues). On pourrait encore parler de la sous-évaluation des territoires 
> ruraux par les populations urbaines, mais je dois y aller, on verra une autre 
> fois.


OMG, la logorrhée est contagieuse !
;o)


Librement,
-- 
Christophe Merlet (RedFox)


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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Emilie Laffray]

2012/5/29 Arnaud Vandecasteele 

> Bonjour à tous,
>
> C'est peut être aussi une des limites des méthodes collaboratives et
> mondiales.
> Comment en effet avoir un rendu pertinent pour des régions aussi
> disparates ?
> Je prêche pour ma paroisse, mais une solution serait (peut être) de penser
> à une modélisation logique des informations.
> Cela permettrait de réduire les problèmes d'hétérogénéité sémantiques
> rencontrés.
> Un exemple serait la base geonames dont les informations peuvent être
> obtenues sous une forme ontologique (RDF) :
> http://www.geonames.org/
>
> Arnaud
>
>
Si seulement Geonames etait vraiment utile avec un vrai schema qui ait un
sens :)

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Arnaud Vandecasteele]

Emilie,

Je comprends tout à fait le sens de ta remarque et je te rejoins pleinement.
Néanmoins, Geonames n'était là que pour donner un exemple d'application,
pas pour servir de modèle à appliquer.
Une modélisation doit être réalisée pour un objectif précis, elle n'a de
sens que dans un contexte donné.
C'est pourquoi Geonames peut sembler parfois un peu limité.
Néanmoins, le graphe conceptuelle d'OSM est aujourd'hui complexe voir même
parfois difficilement compréhensible.
J'espère avoir un jour le temps de me pencher sur l'intersection
potentielle entre ontologie et OpenStreetMap !

A.

2012/5/29 Emilie Laffray 

>
>
> 2012/5/29 Arnaud Vandecasteele 
>
>> Bonjour à tous,
>>
>> C'est peut être aussi une des limites des méthodes collaboratives et
>> mondiales.
>> Comment en effet avoir un rendu pertinent pour des régions aussi
>> disparates ?
>> Je prêche pour ma paroisse, mais une solution serait (peut être) de
>> penser à une modélisation logique des informations.
>> Cela permettrait de réduire les problèmes d'hétérogénéité sémantiques
>> rencontrés.
>> Un exemple serait la base geonames dont les informations peuvent être
>> obtenues sous une forme ontologique (RDF) :
>> http://www.geonames.org/
>>
>> Arnaud
>>
>>
> Si seulement Geonames etait vraiment utile avec un vrai schema qui ait un
> sens :)
>
> Emilie Laffray
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>


-- 

Arnaud Van De Casteele
Mines Paris Tech - CRC
Sophia-Antipolis
0698 24 25 29
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/
http://geotribu.net/
http://www.i2c.eu/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Philippe Verdy]

Le 29 mai 2012 17:25, Nicolas Dumoulin
 a écrit :
> Le mardi 29 mai 2012 16:55:23 Philippe Verdy a écrit :
>> Justement le tag capital=* permettrait de cartographier en plus de
>> façon plus qualitative (mais basée tout de même sur un critère
>> objectif et facilement vérifiable et stable) bon nombre de chef-lieux
>> d'entités administratives plus petites.
>
> Bonjour,
>
> Oui, effectivement, l'information objective du chef-lieu administratif serait
> pertinent pour trier les place=* à afficher.
> Par contre, je ne crois pas que le capital=* soit nécessaire pour les
> communes, puisque nous avons déjà le rôle admin_centre sur les relations
> administratives.

C'est aussi le cas en Espagne. Pourtant on voit bien que la redondance
(logique) ne nuit pas et donne un accès facile à l'information qui
facilite énormément les requêtes, en réduisant considérablement le
volume de données à demander au serveur et à traiter.

L'effet est très positif et déjà visible dans Mapnik comme dans
OpenMapQuest, qui s'en sortent nettement mieux avec cette information.

Cette dénormalisation est très peu coûteuse et stable :
- la règle est qu'on met en valeur de capital=* la plus petite valeur
d'admin_level parmi toutes les relations dont la ville est chef-lieu
ou capitale.
- elle ne demande qu'un chiffre en valeur
- cela permet d'éviter de rechercher et télécharger les membres de
toutes les relations dont le noeud est membre, pour savoir quel rôle
il a dans ces relations (ce n'est pas forcément le rôle
"admin_center"), et savoir si ces relations sont bien de type boundary
(avec "boundary=administrative" nécessaire, type=boundary recommandé
mais pas absolument nécessaire), et pour connaître la valeur donné à
"admin_level=*" dans cette relation.
- c'est rapide à renseigner dans la base de données là où cela manque,
cela ne surcharge que très peu les noeuds de villes où on le définit.

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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Vincent Calame]

C'est quoi la "commune centre" ?


Je voulais dire par là la commune dont le nom va être utilisé pour 
désigner (de manière officielle ou par habitude) l'agglomération.


Je prends un exemple de par chez moi : j'ai trois communes 
Argenton-sur-creuse (5 177 habitants), Le Pêchereau (2 010 habitants), 
Saint-Marcel (1 606 habitants). Sur place, s'il n'y avait pas les 
panneaux, on ne verrait pas que l'on passe d'une commune à une autre. 
C'est Argenton-sur-Creuse qui donne son nom à l'agglomération (c'est le 
chef-lieu, c'est le nom de la communauté de commune, de la gare SNCF et 
c'est là qu'est le centre-ville commerçant).


En nombre d'habitants, les trois réunis font 8 793 habitants, plus que 1 
000 et on pourra mettre place=town :-)


Vincent


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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Philippe Verdy]

Le 29 mai 2012 16:50, sly (sylvain letuffe)  a écrit :
>> la sélection des étiquettes est le gros point
>> noir des rendus actuels avec des tuiles complètement muettes à zoom
>> moyen en milieu rural où tout est place=village.
>> Le critère de
>> population est un critère quantitatif insuffisant
>
> Je suis d'accord
>
>
>> car les communes
>> française sont petites et la population de la commune centre
>> ne  représente pas la population de l'agglomération et donc son importance
>> réelle.
>
> C'est quoi la "commune centre" ?

Je pense qu'il voulait dire le village centre dans la même commune.
Toutefois cette notion de "village" devrait prendre en compte non pas
le côté urbain/agglomération, mais la classification administrative en
cas de découpage de la commune.

Par exemple en Belgique comme aussi en Espagne, la plupart des
municipalités sont découpées en subdivisions de niveau 9 (appelées
"sections communales" en Belgique et correspondant plus ou moins aux
tracés des anciennes communes qui sont aujourd'hui réunies dans la
même municipalité), voire au delà au niveau 10 (mais bien plus
rarement, seulement dans les agglomérations denses et assez peuplées
dans la zone sous-découpée administrativement).

Au delà de capital=*, qui se base sur le découpage des
boundary=admnistrative, on pourrait aussi envisager un autre tag basé
sur d'autres types de frontières
- par exemple les villes hôtes de tribunaux, sur la carte des
frontières judiciaires : les districts judiciaires existent en
Belgique et en Espagne, mais n'épousent pas parfaitement le découpage
administratif; c'est aussi le cas en France, et pour ces 3 pays on
pourrait avoir un nouveau type de relation "boundary=judiciary",avec
plusieurs niveaux selon qu'il s'agit de juridiction simples (découpage
le plus fin, a priori celui des tribunaux d'instance en France) ou de
juridictions d'appel (beaucoup moins nombreuses et regroupant
plusieurs juridictions simples). Cela impliquerait alors un
"judiciary_level=*" dans ces relations, contenant un seul chiffre pour
le niveau de découpage de la carte judiciaire ;
- au niveau du nœud de la ville, on pourrait alors voir aussi un tag
de rappel (dénormalisé), tel que "court=*", déterminé de façon
similaire.
- Le but étant là encore de fournir simplement certains critères
objectifs (et non "qualitatifs" donc subjectifs) permettant de savoir
quelle ville peut être affichée plutôt qu'une autre sur un rendu de
carte (ensuite à chaque moteur de rendu de choisir lesquel de ces
critères sont pertinents, puisque le seul "place=*" basé sur la
population totale de la commune, sans tenir compte de sa surface, est
très insuffisant), et sans avoir à parcourir un schéma compliqué
comprenant de multiples relations à tester avec la liste complète de
ses membres (une liste particulièrement longue et très coûteuse à
traiter pour les niveaux administratifs les plus petits !)

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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Emilie Laffray]

2012/5/29 Arnaud Vandecasteele 

> Emilie,
>
> Je comprends tout à fait le sens de ta remarque et je te rejoins
> pleinement.
> Néanmoins, Geonames n'était là que pour donner un exemple d'application,
> pas pour servir de modèle à appliquer.
> Une modélisation doit être réalisée pour un objectif précis, elle n'a de
> sens que dans un contexte donné.
> C'est pourquoi Geonames peut sembler parfois un peu limité.
> Néanmoins, le graphe conceptuelle d'OSM est aujourd'hui complexe voir même
> parfois difficilement compréhensible.
> J'espère avoir un jour le temps de me pencher sur l'intersection
> potentielle entre ontologie et OpenStreetMap !
>
> A.
>
>
Je te rejoins. Il y avait d'ailleurs recemment la meme discussion sur la
mailing liste indienne ou ils veulent utiliser la norme indienne (lire
gouvernementale) pour choisir ce qui est une ville, un village etc... Le
probleme c'est que le schema probablement ne sera pas compatible au niveau
international ce qui est dommage.
Concernant la structure, je pense qu'il faut relativiser au moins pour les
"villes" il faut relativiser. Je pense que la complexite apparait lie au
tentative de conciliation de la norme internationale vis a vis d'une norme
nationale.
Je pense que la solution est d'utiliser un double niveau de lecture:
- International: place=* + population=*
- National: place:fr etc

Je pense que cela permettrait un systeme plus simple au final. Maintenant,
je sais que ce que tu suggeres n'est pas juste sur les villes.

Emilie Laffray
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Philippe Verdy]

Le 29 mai 2012 18:37, Vincent Calame  a écrit :
> En nombre d'habitants, les trois réunis font 8 793 habitants, plus que 1 000
> et on pourra mettre place=town :-)

Ce critère reste subjectif car absolument pas généralisable.

Les place=* en France, quand ils sont utilisés comme admin_center
d'une commune, ne doivent pas compter plus (ni moins) d'habitants que
la commune elle-même.

Ce que tu voudrais c'est prendre en compte non pas le découpage
adminsitratif, mais le découpage urbain, qui n'a rien à voir (il est
totalement séparé par l'Insee,mais pris en compte partiellement pour
le découpage des cantons).

Peut-être vaut-il mieux alors prendre en compte le découpage cantonal
pour l'instant (boundary=political, political_division=canton) et
rapporter ensuite dans les relations définissant les cantons, le nœud
membre défini "admin_center" du chef-lieu de canton. Dans ce cas on
peut alors glisser en rappel, dans les propriétés de ce nœud un tag
dénormalisé ajoutant "political=canton".

Note: plusieurs cantons géographiquement séparés se partagent un même
nœud pour leur chef-lieu, qui dès lors n'est pas forcément dans la
zone géographique du canton. Ce n'est pas grave et n'empêche pas de
taguer le nœud commun de la commune chef-lieu de plusieurs cantons
avec un unique political=canton.

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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Philippe Verdy]

Pardon corrigez partout "admin_center" en "admin_centre". Vous avez
compris de toute façon, pas la peine de me le rappeler.

C'est une faute que je fais souvent dans les courriels, mais
**jamais** dans les tags de la base OSM, parce que je n'ai **jamais**
à le taper en entier dans JOSM où je ne tape que la première lettre
"a" (il complète tout seul correctement parce que la valeur est déjà
connue dans les autres données téléchargées).

Le 29 mai 2012 18:47, Philippe Verdy  a écrit :
> Le 29 mai 2012 18:37, Vincent Calame  a écrit :
>> En nombre d'habitants, les trois réunis font 8 793 habitants, plus que 1 000
>> et on pourra mettre place=town :-)
>
> Ce critère reste subjectif car absolument pas généralisable.
>
> Les place=* en France, quand ils sont utilisés comme admin_center
> d'une commune, ne doivent pas compter plus (ni moins) d'habitants que
> la commune elle-même.
>
> Ce que tu voudrais c'est prendre en compte non pas le découpage
> adminsitratif, mais le découpage urbain, qui n'a rien à voir (il est
> totalement séparé par l'Insee,mais pris en compte partiellement pour
> le découpage des cantons).
>
> Peut-être vaut-il mieux alors prendre en compte le découpage cantonal
> pour l'instant (boundary=political, political_division=canton) et
> rapporter ensuite dans les relations définissant les cantons, le nœud
> membre défini "admin_center" du chef-lieu de canton. Dans ce cas on
> peut alors glisser en rappel, dans les propriétés de ce nœud un tag
> dénormalisé ajoutant "political=canton".
>
> Note: plusieurs cantons géographiquement séparés se partagent un même
> nœud pour leur chef-lieu, qui dès lors n'est pas forcément dans la
> zone géographique du canton. Ce n'est pas grave et n'empêche pas de
> taguer le nœud commun de la commune chef-lieu de plusieurs cantons
> avec un unique political=canton.

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

Re: [OSM-talk-fr] *HS* /was : Osmose - Tag source illegal ou incomplet IGN/

[Philippe Verdy]

C'est encore plus hors-sujet quand tu postes sur la liste un truc
pareil sans mentionner de qui ou de quoi tu parles (rien de rien !
impossible même de le savoir en regardant la liste de ceux à qui tu as
envoyé le message éventuellement en copie, puisqu'on ne voit comme
destinataire QUE l'adresse de la liste).

Si ton message se voulait privé, à celui à qui tu adressais ce
reproche, il fallait retirer la liste de discussion des destinataires
!

Maintenant ton message apparaît alors comme une menace adressée à TOUS
les membres de la liste, ce qui est encore plus contraire à la
Netiquette que tu pourrais alors prendre en compte toi-même en évitant
de poster ça à tout le monde.

Le 29 mai 2012 07:30, Vincent-Xavier JUMEL
 a écrit :
> Hors-Sujet.
>
> Ce message pollue la liste. Je t'invite à relire la Nétiquette.

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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[Philippe Verdy]

Le 28 mai 2012 22:23, l...@worldonline.fr  a écrit :
> Le lundi 28 mai 2012 à 20:31 +0200, sly (sylvain letuffe) a écrit :
> Je te remercie pour cette proposition mais ce n'est pas un problème de
> serveur.
> Par contre si tu penses que ce fichier serait plus visible sur le site
> de l'association, il n'y a pas de problème.
>
>> sans lancer de troll p2p vs ddl (parfois appelé le bon vieux "web" qui
>> marche)
>
> En regardant l'image en pièce jointe (je ne sais pas si elle passe dans
> la liste), il y a au moins 6 personnes qui ont téléchargé ce fichier
> pendant le week-end.

Le P2P pour un fichier qui sera téléchargé par un nombre réduit de
personne ne marchera pas bien : rapidement ceux-là seront hors réseau
et plus accessible. Cela pose alors pour toi l'obligation de laisser
ton odfinateur allumé en permanence et accessible depuis Internet.

Dans un cas comme ça, mieux vaut le transférer vers une page web
perso, et fournir l'URL. Il y a des tonnes de services gratuits sur
Internet pour le faire, y compris celui proposé par ton FAI (tous les
FAIs te proposent un espace avec au moins 5 gigaoctets de stockage en
ligne). On peut citer aussi par exemple Google Docs si son format est
reconnu et tu utilises une extension de fichier standard et
compatible) sur lequel tu n'as plus qu'à rendre ton fichier public.

Une fois transféré, le fichier est accessible pour longtemps et
facilement pour tout le monde (via l'URL), et cela ne te coûte rien et
te supprime la contrainte d'ouvrir un accès à ton ordinateur (et aussi
vérifier que cet accès reste sécurisé)

Personnellement je ne mets jamais rien accessible depuis Internet sur
mes ordinateurs privés : tous les accès entrants sont bloqués (et je
le vérifie régulièrement via des sites web comme www.grc.com qui a un
outil bien fait pour identifier rapidement les trous de sécurité qui
auraient pu apparaître dans la config de son PC ou de ses parefeux
logiciels et matériels ou de son routeur).

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

Re: [OSM-talk-fr] Remise en place de taginfo.openstreetmap.fr

[Philippe Verdy]

Le 28 mai 2012 16:46, Guillaume Allegre  a écrit :
> Le lun. 28 mai 2012 à 16:29 +0200, sly (sylvain letuffe) a ecrit :
>> Le lundi 28 mai 2012 16:20:16, Guillaume Allegre a écrit :
>>
>> > Une question : quand on trouve une valeur aberrante de tag, par exemple,
>> > un FR:school (unique), comment localiser l'objet ?
>>
>> http://taginfo.openstreetmap.fr/keys/FR%3Aschool
>> En haut à droite, deux liens : XAPI et JOSM
>
> Merci, je n'avais pas vu ces deux boutons.

Puisque tu proposes déjà la génération de la liste en format OSM ou
XAPI, pourquoi ne pas non plus la mettre en format HTML, ou au minimum
sous forme d'une liste en texte simple non formatté (.TXT) :

Ça coûterait cher d'ajouter un ou deux boutons en plus de XAPI et JOSM
afin de pouvoir visualiser directement dans le navigateur sans
nécessairement télécharger et enregistrer vers un fichier local (le
fichier serait téléchargé de toute façon mais uniquement dans le cache
du navigateur, qui se nettoie tout seul) ?

Ou alors de mettre un bouton "XML" qui serait en fait le même fichier
que le fichier OSM, mais avec un media type "text/xml" que le
navigateur propose d'afficher directement (mais qu'on peut encore
enregistrer après depuis la page affichée).

Si tu mets une page HTML, il serait utile que ce soit une table
donnant le type d'objet (noeud/way/relation) son id, et son "name"
quand il est présent, et éventuellement quelques infos purement
statistiques (nombre de noeuds pour un way, nombre de membres pour une
relation), un peu de la façon dont les objets sont listés dans JOSM
(par exemple dans la liste des membres d'une relation, ou dans la
liste des objets sélectionnés, ou la liste des objets en conflits),
avec alors des liens à côté pour voir sur la carte Mapnik, ou éditer
sur JOSM et Potlatch2.

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

Re: [OSM-talk-fr] Bâtiments d'élevage

[Philippe Verdy]

Le 28 mai 2012 18:57, Damouns  a écrit :
> Salut !
>
> Je verrais plus un double système de tags :
>
> 1) D'abord le rôle général du bâtiment avec building=animal_raising ou
> building=farm, quelque chose comme ça ;
> 2) Ensuite le type d'êtres vivants élevés là : animal=chicken, ou bien
> animal=broiler comme tu le proposes, ou bien encore species=chicken ou
> species=Gallus gallus domesticus...

Préciser l'espèce scientifique n'a pas de sens : d'abord on ne le sait
pas réellement, c'est un secret commercial car ce sont souvent des
espèces hybrides, ça change sans prévenir personne même plusieurs fois
dans l'année selon les saisons ou les périodes d'abattage (à qui
l'agriculture a acheté ses poussins ?), et plusieurs espèces (ou
hybrides) peuvent cohabiter dans le bâtiment, à des stades différents
de leur maturation ou au même stade (intérêt pour l'agriculteur : en
cas de maladie, toutes les espèces ne sont pas touchées en même temps
ou avec le même degré de gravité, et il peut aussi gérer des
difficultés d'approvisionnement pour certains aliments spécifiques à
une espèce donnée, ou des besoins en eau ou en énergie de chauffage
différents).

Ce qui a un sens c'est le type générique d'animal pour lequel le
bâtiment a été construit et aménagé, et pour lequel il a demandé et
obtenu les autorisations.

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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[Jocelyn Jaubert]

Le 28 mai 2012, l...@worldonline.fr a écrit :
> Le lundi 28 mai 2012 à 20:31 +0200, sly (sylvain letuffe) a écrit :
> 
> > Si besoin, on peut aussi trouver une place sur un des serveurs de
> > l'asso 
> > osm-fr et je peux te fournir un accès pour être à coté de ce que
> > fais déjà 
> > frédéric :
> > http://garmin.openstreetmap.fr/ 
> 
> Je te remercie pour cette proposition mais ce n'est pas un problème de
> serveur. 
> Par contre si tu penses que ce fichier serait plus visible sur le site
> de l'association, il n'y a pas de problème.

Si tu penses qu'on peut automatiser la génération du fichier, on peut
aussi directement le générer sur une des machines d'OSM-FR, ce qui
éviterait de prendre sur ta bande passante. Ça permettrait aussi
d'avoir un fichier souvent à jour.


> Si ces 6 personnes avaient téléchargé par un torrent, les personnes
> suivantes auraient pu bénéficier de 6 connections réseaux ce qui
> aurait permis de le télécharger plus rapidement. 
> 
> Les fichiers font désormais plus de 1 Go et je pense réellement que la
> solution d'avenir est le p2p

Je pense que si on utilise des machines hébergés dans un site avec une
bonne bande passante, la solution http reste la meilleure pour le
moment. C'est évidement à revisiter si on a suffisamment de monde qui
télécharge le fichier au même moment.


Merci,
Jocelyn

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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Vincent Calame]

Le 29/05/2012 18:47, Philippe Verdy a écrit :

Ce critère reste subjectif car absolument pas généralisable.


Vive la subjectivité, vive le terrain, vive le réel.

Les frontières administratives sont certes les seules frontières « 
objectives » dont nous disposons mais elles sont loin de représenter la 
réalité géographique des territoires.


Plusieurs pays et non des moindres ont une capitale administrative 
différentes de la capitale économique. Quand on voit que sur le niveau 
de zoom par défaut (6) de la carte d'OpenMapQuest, pour la Côte 
d'Ivoire, il y a Yamoussoukro plus d'autres préfectures et pas Abdijan, 
on peut dire qu'il y a un problème.


Vincent




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

Re: [OSM-talk-fr] [Humeur] Ne pas tagger pour le rendu... et OpenMapQuest

[Philippe Verdy]

Le 29 mai 2012 19:44, Vincent Calame  a écrit :
> Le 29/05/2012 18:47, Philippe Verdy a écrit :
>> Ce critère reste subjectif car absolument pas généralisable.
> Vive la subjectivité, vive le terrain, vive le réel.

Contradiction dans la même phrase entre "subjectivité" et "le réel" !

> Les frontières administratives sont certes les seules frontières «
> objectives » dont nous disposons

Faux. Les frontières des EPCI ne sont pas administratives pourtant
elles sont objectives. De même les frontières judiciaires. La carte
scolaire et les académies (non administratives au sens où on l'entend
pour les collectivités territoriales). De même la carte électorale
(pas complètement liée aux frontières administratives, en témoignent
nos cantons pour les élections aux conseils généraux, ou les
circonscriptions européennes !)

Avant de parler de critères subjectifs, on peut déjà cartographier ce
qui est objectif et facilement vérifiable ! Et il n'y a pas que le
chiffre de la population totale communale qui compte (ce qui omet
aussi le paramètre de la densité de population).

Si on admet les critères réellement objectifs, alors il faut
cartographier le découpage urbain de l'INSEE ! Cela me semble plus
prioritaire que de bidouiller localement avec les critères subjectifs
avec lesquels il sera difficile de trouver un accord.

Laissons les place=* tels qu'ils sont : juste en fonction de la
population totale communale avec ses seuils prédéfinis. Car là au
moins c'est vérifiable et on a le moyen de se mettre d'accord et de
corriger (sans tenir compte de ce que font les moteurs de rendu avec).

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

Re: [OSM-talk-fr] Héritage et relation

[Philippe Verdy]

Le 25 mai 2012 16:53, sly (sylvain letuffe)  a écrit :
>
>> Côté wiki il ne me parait pas à jour.
>
> C'est souvent le cas, sur certaines pages soit il est en avance dans le sens
> où il propose de tagguer tel truc de tel manière alors que ça n'est pas
> encore utilisé dans la base.
>
> A l'inverse des pratiques existent qui ne sont pas ou mal documentées, et là,
> il est préférable de venir compléter le wiki (tout le monde le peux), et
> indiquer par des pages que "voilà ce qui se fait à tel endroit, pour tel et
> tel raison avec tel et tel avantage sur telle autre méthode qui lui
> ressemble" et en parler sur la liste anglaise tagging pour présenter son
> existence aux autres, en discuter et l'améliorer et espérer que son usage va
> se démocratiser pour qu'elle finisse par obtenir le "droit" de figurer dans
> la liste des "Established Relations" :
> http://wiki.openstreetmap.org/wiki/Types_of_relation

Le wiki mentionne une relation de type boundary=civil sans aucune
documentation (la page liée à cette valeur n'est qu'un "stub"
affichant le titre et rien d'autre. Certains ont tenté d'obetnir des
explications de celui qui a ajouté ça dans la page wiki, et dans les
sous-pages sur cette valeur, et c'est resté lettre morte.

Je ne suis pas loin de demander la suppression de ces pages puisque
leur auteur n'a pas répondu depuis longtemps.

On a vu récemment disparaître du wiki "boundary=electoral" puisque
cela a été réuni dans "boundary=political" (alors qu'il aurait plutôt
fallu faire l'inverse, la notion de frontière politique n'ayant aucun
sens au niveau électoral, sauf au niveau 2 des pays, tels que discutés
et reconnus à l'ONU, et dans les traités internationaux, et la
description du tag et l'usage qui en est fait est bien que ce sont des
frontières électorales !). Pourtant il reste encore des frontières
contenant "boundary=electoral"...

On aurait mieux fait de dire que les deux valeurs étaient synonymes,
décrire les deux dans la même page (par une redirection) en
recommandant une migration vers une autre valeur (qui aurait du être
"electoral") afin d'assurer une bonne compréhension par tout le monde
et une transition vers la valeur recommandée. Mais voilà : le retrait
du wiki n'a pas été discuté non plus, pas plus que les ajouts
n'avaient été correctement documentés par leur initiateur qui n'a pas
pris l'effort minimum d'expliquer aux autres ce qu'il entendait avec
une valeur différerente !

On se demande s'il existe réellement une communauté OSM au sens large
(mondial) si chacun fait selon ses préférences, et personne ne réponds
aux demandes d'explications, ni n'expose les limites raisonnables
d'utilisation de certains codes (par exemple une limite territoriale
où la valeur a un sens démontré, l'usage pour le reste du monde
restant à étudier).

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

[OSM-talk-fr] Chaussee separee

[Ista Pouss]

Bonjour

Sur ce plan http://osm.org/go/0ApJYzNEL-- (c'est à St Etienne) on voit que
une voie séparée en deux : le boulevard alexandre de fraissinette. Sur
google map c'est exactement le même système : http://goo.gl/maps/1nR7

Or, à cet endroit, la séparation est juste une sorte d'aménagement de
carrefour. J'ai fait deux photos, pour que vous puissiez voir la chose :
http://lightbox.com/photo/XauY9pQ et
http://lightbox.com/photo/RVxEOMVPratiquement sur toute sa longueur, à
chaque carrefour, le boulevard est
aménagé ainsi.

Je n'ai jamais imaginé qu'il y avait là deux chaussées ; c'est juste des
protections pour les piétons, ou des régulateurs de traffic comme on dit.

En plus, l'aménagement indiqué sur la carte est beaucoup plus long que la
réalité, à moins de considérer que une simple bande blanche serait une
séparation physique.

Qu'en pensez-vous ? Est-il juste d'indiquer ce genre d'aménagement sur une
carte ?

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

Re: [OSM-talk-fr] Chaussee separee

[Marc Sibert]

Le 29/05/2012 20:39, Ista Pouss a écrit :

Bonjour

Sur ce plan http://osm.org/go/0ApJYzNEL-- (c'est à St Etienne) on voit 
que une voie séparée en deux : le boulevard alexandre de fraissinette. 
Sur google map c'est exactement le même système : http://goo.gl/maps/1nR7


Or, à cet endroit, la séparation est juste une sorte d'aménagement de 
carrefour. J'ai fait deux photos, pour que vous puissiez voir la chose 
: http://lightbox.com/photo/XauY9pQ et 
http://lightbox.com/photo/RVxEOMV Pratiquement sur toute sa longueur, 
à chaque carrefour, le boulevard est aménagé ainsi.


Je n'ai jamais imaginé qu'il y avait là deux chaussées ; c'est juste 
des protections pour les piétons, ou des régulateurs de traffic comme 
on dit.


En plus, l'aménagement indiqué sur la carte est beaucoup plus long que 
la réalité, à moins de considérer que une simple bande blanche serait 
une séparation physique.


Qu'en pensez-vous ? Est-il juste d'indiquer ce genre d'aménagement sur 
une carte ?


Merci.


Bonjour,

Tout d'abord il faut rappeler que le modèle de données d'OSM, n'est... 
qu'un modèle et donc que les représentations peuvent changer tant que 
"l'esprit" est correctement rendu.
Par exemple, un carrefour peut être relativement détaillé : 
http://osm.org/go/0BOKApPup--, il m'arrive aussi d'ajouter les voies 
"tourne à gauche".


Dans le cas de tes photos, il est acceptable de doubler les voies car, 
au moins avant/après le carrefour, il y effectivement un séparateur qui 
ne permet physiquement pas le franchissement (enfin suivant le diamètre 
des roues, c'est discutable... Philippe a peut être une théorie 
là-dessus). Le modèle proposé n'est pas faux, au contraire, il permet 
toutes les combinaisons réellement réalisables (sauf indications 
contraires), tourne à gauche et à droite, demi-tour, traversé, etc.


Si l'aménagement est effectivement trop long (trop large entre les 
voies), il m'arrive de le réduire. En général, je place le dernier point 
commun sur la ligne blanche et les premier/dernier points au niveau du 
début du ciment.


Mes 0.02 €

A+

--
Marc Sibert
mailto:m...@sibert.fr


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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[l...@worldonline.fr]

Le mardi 29 mai 2012 à 19:10 +0200, Philippe Verdy a écrit :
> Dans un cas comme ça, mieux vaut le transférer vers une page web
> perso, et fournir l'URL 

Je le mets déjà à disposition sur mon site :
www.numeriquement.fr/randonnee/generation_fichier_openstreetmap.php

Mais comme je le faisais remarquer, je pensais qu'il y aurait eu plus de
personnes intéressées et de fait un torrent était la solution idéale.

Bonne soirée


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

Re: [OSM-talk-fr] Remise en place de taginfo.openstreetmap.fr

[Vincent Pottier]

Le 29/05/2012 19:20, Philippe Verdy a écrit :

Puisque tu proposes déjà la génération de la liste en format OSM ou
XAPI, pourquoi ne pas non plus la mettre en format HTML, ou au minimum
sous forme d'une liste en texte simple non formatté (.TXT) :

Ça coûterait cher d'ajouter un ou deux boutons en plus de XAPI et JOSM
afin de pouvoir visualiser directement dans le navigateur sans
nécessairement télécharger et enregistrer vers un fichier local (le
fichier serait téléchargé de toute façon mais uniquement dans le cache
du navigateur, qui se nettoie tout seul) ?

Ou alors de mettre un bouton "XML" qui serait en fait le même fichier
que le fichier OSM, mais avec un media type "text/xml" que le
navigateur propose d'afficher directement (mais qu'on peut encore
enregistrer après depuis la page affichée).

Si tu mets une page HTML, il serait utile que ce soit une table
donnant le type d'objet (noeud/way/relation) son id, et son "name"
quand il est présent, et éventuellement quelques infos purement
statistiques (nombre de noeuds pour un way, nombre de membres pour une
relation), un peu de la façon dont les objets sont listés dans JOSM
(par exemple dans la liste des membres d'une relation, ou dans la
liste des objets sélectionnés, ou la liste des objets en conflits),
avec alors des liens à côté pour voir sur la carte Mapnik, ou éditer
sur JOSM et Potlatch2.
L'idée est bonne. Et parfois j'en rêve... Voire même d'une slippymap à 
la Osmose visualisant les éléments, permettant des filtres, des 
combinaisons.


Mais je pressens qu'il y a deux limitations :

- Je suppose que Sly a mis le code de taginfo sans trop mettre les mains 
dans le cambouis (la panne nous a tout de même apporté une mise à jour 
du programme ! Merci la panne ! ) et qu'il a d’autres chats à fouetter 
(quoi qu'en pense la SPA)... Quand il sera à la retraite...


- Super quand il y a une poignée d'éléments, je crains le clic sur le 
bouton quand par derrière il y a 25000 points. Nos navigateurs ne sont 
pas de bons instruments pour afficher 25000 items bruts en xml, ou un 
tableau html de 25000 lignes. À moins de travailler une interface 
paginée, ce qui, du coup, est une autre paire de manche. S'il y a des 
volontaires...

--
FrViPofm

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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[l...@worldonline.fr]

Le mardi 29 mai 2012 à 19:29 +0200, Jocelyn Jaubert a écrit :
> Si tu penses qu'on peut automatiser la génération du fichier, on peut
> aussi directement le générer sur une des machines d'OSM-FR, ce qui
> éviterait de prendre sur ta bande passante. Ça permettrait aussi
> d'avoir un fichier souvent à jour.


Oui l'automatisation est déjà réalisée sur mon PC. Je peux refiler mon
script (sur Gnu/Linux évidemment) qui est sans doute perfectible. Mais
il faut quand même une machine assez puissante (au moins 4Go de RAM)

> 
> Je pense que si on utilise des machines hébergés dans un site avec une
> bonne bande passante, la solution http reste la meilleure pour le
> moment. C'est évidement à revisiter si on a suffisamment de monde qui
> télécharge le fichier au même moment. 

On est d'accord. Il faudrait tester la bande passante sortante et la
comparer avec ce que je propose.


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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[Vincent Pottier]

Le 28/05/2012 22:23, l...@worldonline.fr a écrit :

En regardant l'image en pièce jointe (je ne sais pas si elle passe dans
la liste), il y a au moins 6 personnes qui ont téléchargé ce fichier
pendant le week-end.
Si ces 6 personnes avaient téléchargé par un torrent, les personnes
suivantes auraient pu bénéficier de 6 connections réseaux ce qui aurait
permis de le télécharger plus rapidement.

Les fichiers font désormais plus de 1 Go et je pense réellement que la
solution d'avenir est le p2p

Les nouvelles idées sont les bienvenues.

Bonne soirée


Je fais partie des 6 :-)
J'avoue que ton fichier ne faisait pas partie de mon paysage.
J'utilisais celui de Frédéric (qui l'a d'ailleurs régénéré à ma demande 
il y a quelques temps et qui fut excellent lors d'une rando ! encore 
merci : c'est super de pouvoir emmener un groupe à l'inconnu sans carte 
topo )

Je n'avais pas repéré que le tien était mis à jour de façon hebdomadaire.

Donc je l'ai chargé et je compte bien le tester...
Au premier coup d'œil, je ne perçois pas encore les différences par 
rapport à celui de Frédéric.
Je suppose pourtant qu'il y en a : le poids zippé du tien fait 1.1 Go, 
celui de Frédéric, relief inclus : 825 Mo...

À voir...
Merci d'avance.
--
FrViPofm

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

Re: [OSM-talk-fr] Licence des fichiers img pour GPS Garmin

[Vincent Pottier]

Le 29/05/2012 08:52, Romain MEHUT a écrit :
Le 28 mai 2012 20:31, sly (sylvain letuffe) > a écrit :



Si besoin, on peut aussi trouver une place sur un des serveurs de
l'asso
osm-fr et je peux te fournir un accès pour être à coté de ce que
fais déjà
frédéric :
http://garmin.openstreetmap.fr/


+ 1 pour un accès depuis les serveurs d'osm-fr si le débit en download 
est plus important que celui de lann. Il m'a fallu en effet plusieurs 
heures pour télécharger le fichier.


Romain


+1,
On pourrait peur-être mutualiser les efforts (des autres ;-) ) et 
peut-être produire des cartes plus typées.
http://www.wanderreitkarte.de/garmin_de.php propose des cartes très 
orientées rando (et très lourdes, il me semble)
Frédéric propose deux cartes : avec ou sans courbes de niveaux. Mais les 
styles sont identiques... Il pourrait y avoir une carte plus route, une 
plus rando, une plus... poids-lourds (il parait que ça coûte une 
fortune), par exemple...

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

Re: [OSM-talk-fr] Remise en place de taginfo.openstreetmap.fr

[Frédéric Rodrigo]

Le 29/05/2012 21:41, Vincent Pottier a écrit :

L'idée est bonne. Et parfois j'en rêve... Voire même d'une slippymap à
la Osmose visualisant les éléments, permettant des filtres, des
combinaisons.

Mais je pressens qu'il y a deux limitations :

- Je suppose que Sly a mis le code de taginfo sans trop mettre les mains
dans le cambouis (la panne nous a tout de même apporté une mise à jour
du programme ! Merci la panne ! ) et qu'il a d’autres chats à fouetter
(quoi qu'en pense la SPA)... Quand il sera à la retraite...

- Super quand il y a une poignée d'éléments, je crains le clic sur le
bouton quand par derrière il y a 25000 points. Nos navigateurs ne sont
pas de bons instruments pour afficher 25000 items bruts en xml, ou un
tableau html de 25000 lignes. À moins de travailler une interface
paginée, ce qui, du coup, est une autre paire de manche. S'il y a des
volontaires...


Ce type d'outil existe déjà.

http://wiki.openstreetmap.org/wiki/Query-to-map
Le serveur est hébergé par la fondation wikimédia.

Frédéric

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

[OSM-talk-fr] Zone de stationnement sur la gauche

[Arnaud Vandecasteele]

Bonsoir à tous,

A côté de chez moi, il y a une rue dont le stationnement est uniquement
autorisé sur la gauche et interdit sur la droite (dans le sens de la
montée) [1].
J'aimerais savoir comment tagger cela.
Dois-je ajouter un linéaire parallèle à la rue, ce qui obligerait à
enregistrer deux géométries ou bien existe-t-il un moyen autre de le faire ?
J'imagine un tag spécifique qui permettrait de décrire ce cas.

Merci pour votre aide

Bonne soirée

Arnaud

[1] http://goo.gl/maps/JIqr - Contrairement à l'image, le stationnement est
interdit sur la droite.

-- 

Arnaud Van De Casteele
Mines Paris Tech - CRC
Sophia-Antipolis
0698 24 25 29
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/
http://geotribu.net/
http://www.i2c.eu/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Zone de stationnement sur la gauche

[Gilles Bassière]

Le mardi 29 mai 2012 à 22:47 +0200, Arnaud Vandecasteele a écrit :
> Bonsoir à tous,
> 
> A côté de chez moi, il y a une rue dont le stationnement est
> uniquement autorisé sur la gauche et interdit sur la droite (dans le
> sens de la montée) [1].
> J'aimerais savoir comment tagger cela.
> Dois-je ajouter un linéaire parallèle à la rue, ce qui obligerait à
> enregistrer deux géométries ou bien existe-t-il un moyen autre de le
> faire ?
> J'imagine un tag spécifique qui permettrait de décrire ce cas.
> 
> Merci pour votre aide
> 
> Bonne soirée
> 
> Arnaud


Bonsoir,

Il m'est arrivé d'utiliser parking:lane pour décrire le stationnement.
C'est un tag riche et souple. Je pense que c'est ce que tu cherches.

Les possibilités sont décrites sur le wiki :
http://wiki.openstreetmap.org/wiki/Key:parking:lane

En résumé :

parking:lane:left=parallel

(Attention : left/right est à définir par rapport à l'orientation du
chemin OSM)

Cordialement
-- 
Gilles Bassière - Web/GIS software engineer
http://gbassiere.free.fr/



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

Re: [OSM-talk-fr] Zone de stationnement sur la gauche

[Arnaud Vandecasteele]

Cool exactement ce que je cherchais.

Merci Gilles

@++


Arnaud

2012/5/29 Gilles Bassière 

> Le mardi 29 mai 2012 à 22:47 +0200, Arnaud Vandecasteele a écrit :
> > Bonsoir à tous,
> >
> > A côté de chez moi, il y a une rue dont le stationnement est
> > uniquement autorisé sur la gauche et interdit sur la droite (dans le
> > sens de la montée) [1].
> > J'aimerais savoir comment tagger cela.
> > Dois-je ajouter un linéaire parallèle à la rue, ce qui obligerait à
> > enregistrer deux géométries ou bien existe-t-il un moyen autre de le
> > faire ?
> > J'imagine un tag spécifique qui permettrait de décrire ce cas.
> >
> > Merci pour votre aide
> >
> > Bonne soirée
> >
> > Arnaud
>
>
> Bonsoir,
>
> Il m'est arrivé d'utiliser parking:lane pour décrire le stationnement.
> C'est un tag riche et souple. Je pense que c'est ce que tu cherches.
>
> Les possibilités sont décrites sur le wiki :
> http://wiki.openstreetmap.org/wiki/Key:parking:lane
>
> En résumé :
>
>parking:lane:left=parallel
>
> (Attention : left/right est à définir par rapport à l'orientation du
> chemin OSM)
>
> Cordialement
> --
> Gilles Bassière - Web/GIS software engineer
> http://gbassiere.free.fr/
>
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

Arnaud Van De Casteele
Mines Paris Tech - CRC
Sophia-Antipolis
0698 24 25 29
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/
http://geotribu.net/
http://www.i2c.eu/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Remise en place de taginfo.openstreetmap.fr

[sly (sylvain letuffe)]

> - Je suppose que Sly a mis le code de taginfo sans trop mettre les mains
> dans le cambouis 

Je précise que je n'y suis pour rien, le mérite en revient à... heu... un 
autre (jocelyn ?) !

En ce qui concerne les conversions, un courageux peut, s'il le souhaite, créer 
un nouveau convertisseur genre xapi/xml->txt si le plaisir lui en dit.


-- 
sly (sylvain letuffe)

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

[OSM-talk-fr] Presentation pour le SOTM 2012 acceptee

[Emilie Laffray]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
 
Bonsoir,

juste quelques lignes pour préciser que la présentation State Of France
a été acceptée pour le SOTM cette année a Tokyo.
On a encore le temps de faire mais on va pouvoir s'amuser a faire la
présentation dans la pure tradition Crowdsource :)

Emilie Laffray
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
 
iQEcBAEBAgAGBQJPxVUIAAoJEOm7A+8aiQ34y9QH/RRaEJeuPu7juH32dW/TwbCe
cWWV09qydHdnwOBhiqLDl+WJ7yUypDGlrWl88KOiO5hoXJ8crrOeL6ufLLB3BdUD
Gtob9biSw41CuBA71e0RTyCog4kncQbpA/j4gEE9RpDl0P30aaMzJwCDDUoGBU0W
vKc17QIERjY/XR9ZAmqDa/fUVhGchDxHQokO+i2DTN1DxdPymKuONkSax9GLkYcv
WUx1oeu5yxWV4ER+9Sgaua9W4sjYF7b3eKAlvvaHTqATKkLOHMz17k3+oC2r+9PV
E7sDEO7j6qdyWU9M6UyX8B+eNocJktC1NXLhIv/jG4DRinNFcftOxRS9UD5OADY=
=uBM0
-END PGP SIGNATURE-


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

[OSM-talk-fr] osmose - Repères géodésique hors commune ??

[Nicolas Croiset (Campus Grenoble 90,8)]

Bonjour,

ce jour est apparu une nouvelle erreur sur les points géodésique "Repère 
géodésique hors de sa commune" Celui-ci semble pourtant bien dans 
celle-ci, cf par exemple :

http://osmose.openstreetmap.fr/map/?zoom=16&lat=42.42518&lon=8.77391&item=6070

A+
--
++
| E-mail : nicolas.croi...@brume.org |
| Annuaire des radios AM/FM/DMB : http://www.annuradio.fr/   |
++

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

Re: [OSM-talk-fr] Presentation pour le SOTM 2012 acceptee

[Arnaud Vandecasteele]

Félicitations à toute l'équipe et bonne présentation !

Arnaud

On Wed, May 30, 2012 at 1:00 AM, Emilie Laffray wrote:

>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Bonsoir,
>
> juste quelques lignes pour préciser que la présentation State Of France
> a été acceptée pour le SOTM cette année a Tokyo.
> On a encore le temps de faire mais on va pouvoir s'amuser a faire la
> présentation dans la pure tradition Crowdsource :)
>
> Emilie Laffray
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.17 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPxVUIAAoJEOm7A+8aiQ34y9QH/RRaEJeuPu7juH32dW/TwbCe
> cWWV09qydHdnwOBhiqLDl+WJ7yUypDGlrWl88KOiO5hoXJ8crrOeL6ufLLB3BdUD
> Gtob9biSw41CuBA71e0RTyCog4kncQbpA/j4gEE9RpDl0P30aaMzJwCDDUoGBU0W
> vKc17QIERjY/XR9ZAmqDa/fUVhGchDxHQokO+i2DTN1DxdPymKuONkSax9GLkYcv
> WUx1oeu5yxWV4ER+9Sgaua9W4sjYF7b3eKAlvvaHTqATKkLOHMz17k3+oC2r+9PV
> E7sDEO7j6qdyWU9M6UyX8B+eNocJktC1NXLhIv/jG4DRinNFcftOxRS9UD5OADY=
> =uBM0
> -END PGP SIGNATURE-
>
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>



-- 

Arnaud Van De Casteele
Mines Paris Tech - CRC
Sophia-Antipolis
0698 24 25 29
SIG - WebMapping - Spatial Ontology - GeoCollaboration

Web Site
http://perso.crc.mines-paristech.fr/~arnaud.van_de_casteele/
http://geotribu.net/
http://www.i2c.eu/
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Chaussee separee

[Romain MEHUT]

Bonjour,

Si je peux me permettre, on voit sur tes photos qu'il y a une bande
cyclable or le boulevard en question ne comporte pas les attributs *ad hoc*...
jettes un œil ici http://wiki.openstreetmap.org/wiki/FR:Bicycle pour
choisir le bon cas de figure.

Romain

Le 29 mai 2012 20:39, Ista Pouss  a écrit :

> Bonjour
>
> Sur ce plan http://osm.org/go/0ApJYzNEL-- (c'est à St Etienne) on voit
> que une voie séparée en deux : le boulevard alexandre de fraissinette. Sur
> google map c'est exactement le même système : http://goo.gl/maps/1nR7
>
> Or, à cet endroit, la séparation est juste une sorte d'aménagement de
> carrefour. J'ai fait deux photos, pour que vous puissiez voir la chose :
> http://lightbox.com/photo/XauY9pQ et 
> http://lightbox.com/photo/RVxEOMVPratiquement sur toute sa longueur, à chaque 
> carrefour, le boulevard est
> aménagé ainsi.
>
> Je n'ai jamais imaginé qu'il y avait là deux chaussées ; c'est juste des
> protections pour les piétons, ou des régulateurs de traffic comme on dit.
>
> En plus, l'aménagement indiqué sur la carte est beaucoup plus long que la
> réalité, à moins de considérer que une simple bande blanche serait une
> séparation physique.
>
> Qu'en pensez-vous ? Est-il juste d'indiquer ce genre d'aménagement sur une
> carte ?
>
> Merci.
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-fr
>
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr