Re: [OSM-talk-fr] Nouvelle analyses Osmose sur la France : numéro de téléphone et intégration des restrictions de hauteur

[JB]

Le 11/10/2017 à 11:27, Julien Lepiller a écrit :
J'ai trouvé quelques bizarreries comme des numéros à 11 ou 12 chiffres 
(par exemple https://www.osm.org/node/4883765418
Pour celui-là en tous cas, une petite recherche indique une faute de 
frappe avec le premier 3 en trop.


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

Re: [OSM-talk-fr] JOSM : Plugin scripting

[JB]

Salut Jo,
Merci pour le tuyau ! C'est donc normal que la plupart des scripts 
disponibles ne fonctionnent pas ! Ça m'a bien débloqué, j'explore petit 
à petit.
J'avais aussi remarqué la difficulté de débogguer (surtout quand on ne 
connait pas les commandes à utiliser), j'utilisais un fichier texte 
ouvert/fermé pendant le script. Par contre, sous Windows (bouh !), je 
n'arrive pas à faire passer le jython dans la ligne de commande. Mais en 
fait, même sans lui, les erreurs et le prints remontent dans la fenêtre 
de commande…
Encore une question, je n'ai pas trouvé la réponse sur les exemples 
disponibles ni en tâtonnant : tu connais la commande pour ajouter un tag 
(clef=valeur) à un élément ? remove() permet d'en supprimer, mais ni 
add() ni set() ne semblent fonctionner dans l'autre sens (ou avec les 
arguments organisés autrement que comme j'ai essayé).

Voilà voilà pour ce soir,
JB.

Le 09/10/2017 à 17:19, Jo a écrit :

Salut JB,

J'ai adapté 2 scripts sur cette page:
https://josm.openstreetmap.de/wiki/Help/Plugin/Scripting/Python 
<https://josm.openstreetmap.de/wiki/Help/Plugin/Scripting/Python>


Il ne faut plus définir un mapView depuis l'été de 2016.

Les 2 scripts les plus courts ont été adaptés pour réfléter ce 
changement dans le core de JOSM.


Pour info, je démarre JOSM comme ceci à partir d'un terminal:


java -Xmx3950M -classpath 
"/home/jo/Desktop/josm-latest.jar:/home/jo/.josm/plugins/scripting/jython-standalone-2.7.0.jar" 
org.openstreetmap.josm.gui.MainApplication


Ça a comme avantage que l'on peut voir les messages d'erreur. Sans 
cela il est TRÈS dur de déboguer les scripts.


Polyglot

2017-10-09 15:22 GMT+02:00 JB <jb...@mailoo.org 
<mailto:jb...@mailoo.org>>:


Bonjour,

J'essaye pour la première fois d'utiliser le plugin scripting de
JOSM pour accélérer des tâches répétitives. J'utilise le langage
python. J'avais dans le temps utilisé le qat_script (qui date de
2013 et plante maintenant lorsqu'il y a des erreurs osmose, mais
pas moyen d'en télécharger une version plus récente, le lien wiki
est mort).
J'essaye de construire mon script python en utilisant les exemples
du wiki
(https://josm.openstreetmap.de/wiki/Help/Plugin/Scripting/Python
<https://josm.openstreetmap.de/wiki/Help/Plugin/Scripting/Python>).
Pour l'instant, à partir du moment où j'essaye d'utiliser
getSelectedNodes(), l'exécution plante.

Du coup, ma question principale : est-ce que quelqu'un a une
expérience de scripts python maisons récents à faire tourner pour
voir si le problème est lié à mon ordinateur/mon JOSM ? Un petit
script qui fonctionne chez vous est bienvenu !

Merci,
JB.

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




___
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

[OSM-talk-fr] JOSM : Plugin scripting

[JB]

Bonjour,

J'essaye pour la première fois d'utiliser le plugin scripting de JOSM 
pour accélérer des tâches répétitives. J'utilise le langage python. 
J'avais dans le temps utilisé le qat_script (qui date de 2013 et plante 
maintenant lorsqu'il y a des erreurs osmose, mais pas moyen d'en 
télécharger une version plus récente, le lien wiki est mort).
J'essaye de construire mon script python en utilisant les exemples du 
wiki (https://josm.openstreetmap.de/wiki/Help/Plugin/Scripting/Python). 
Pour l'instant, à partir du moment où j'essaye d'utiliser 
getSelectedNodes(), l'exécution plante.


Du coup, ma question principale : est-ce que quelqu'un a une expérience 
de scripts python maisons récents à faire tourner pour voir si le 
problème est lié à mon ordinateur/mon JOSM ? Un petit script qui 
fonctionne chez vous est bienvenu !


Merci,
JB.

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

Re: [OSM-talk-fr] subway (et railway=station)

[JB]

Bonsoir,
J'ai suivi un peu la discussion (peut-être moins assidument que les 
spécialistes transport), et les deux derniers messages proviennent d'un 
Roland Olbricht assez énervé disant que les « clarifications » d'Ilya 
modifient certaines pratiques bien établies, suivi d'un message de 
Frederik Ramm récapitulant que la proposition d'Ilya n'était peut-être 
pas si bienveillante que précédemment indiqué.
Du coup, à vérifier si les erreurs listées sont réellement des erreurs, 
ou des « trucs » que le système de traitement mis en place n'aime juste pas.

JB.

Le 07/10/2017 à 19:52, Jérôme Amagat a écrit :
Il y a une discussion sur talk en anglais sur les réseau de métro dans 
le monde.
Il y a quelqu'un qui donne ici : http://osmz.ru/subways/ des erreurs 
sur ces réseaux


Déjà je veux dire que j'ai pas vraiment suivie la discussion (mon 
anglais est mauvais et j'ai la flemme :) )


Il y a pas mal d'erreur en France en rapport avec le tag 
railway=station. Soit il est en double pour une station de métro, soit 
il n'est pas là, soit il n'est pas un node.

En fait je sais pas trop comment on doit l'utiliser?
ce que je comprends c'est qu'il faut qu'il soit sur un node tout seul 
au milieu de la station de métro.
Il y a des problème a Lyon, paris, rennes, Marseille (des way au lieu 
de node)


Il y a aussi un problème à Lyon avec une ligne de "light rail". Je 
sais pas trop ce que c'est :) , ce que j'ai compris c'est que c'est 
entre le train et le tramway. A Lyon c'est utilisé pour la ligne de 
Rhônexpress qui va de Lyon centre jusqu’à l’aéroport, les "vehicules" 
ressemble beaucoup aux tram, cette ligne utilise les voies de tramway 
sur les 3/4 du chemin puis des rails qui ne servent qu'a cette ligne 
jusqu' a l’aéroport. les arrêts sont peu nombreux sur cette ligne (2 
sur la dizaine de la ligne de tram) alors voila je ne sais pas si 
c'est un "light rail", un train ou un tram ?



___
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] Champs phone : futur projet du mois ?

[JB]

Oui, mais la contribution c'est des humains qui la font. Et 
personnellement, je n'ai jamais indiqué mon numéro comme étant zéro 
soixante dix-sept million deux cent quarante huit mille et des 
brouettes. Ni lu de cette manière-là. OSM, c'est un projet humain, pas 
un projet de machines pour machines.

JB.


Le 20/09/2017 à 09:06, Dominique Rousseau a écrit :

Ca me semble etrange de se poser la question de mettre des espaces ou
non dans les numeros de telephones stockes dans la base.
La facon de les afficher, c'est - encore une fois - une question de
rendu (des espaces, des tirets, whatever).
Et vu qu'il y a un format indiqué dans le wiki OSM, il suffit de s'y
conformer, si on veut "normaliser" les numéros deja presents.



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

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[JB]

Je ne suis pas persuadé qu'on fera évoluer les idées des uns ou des 
autres. Mais…


Ce qui m'ennuie régulièrement dans le projet OSM, c'est la hausse 
constante de la barrière à l'entrée à la contribution. À chaque couche 
de complexité qu'on ajoute, je pense qu'on perd des nouveaux contributeurs.

« Alors, comment j'ajoute le nom du rond-point ?
 - Facile, tu le sélectionnes, puis tu ajoutes le tag name=*.
 - Heu, pourquoi quand je clique dessus, il n'y a qu'un morceau qui 
vient ? »


Un autre souci, c'est la maintenabilité des éléments. Je n'ai pas de 
stats, mais qui a déjà trouvé une ligne de bus dont tous les éléments 
sont connectés dans la relation ? Combien de temps le sont-ils restés ?


Bon, maintenant les arguments moins élégants, avec une touche de 
mauvaise foi :
 - Découper des rond-point c'est tellement élégant, et tellement 
attrayant du point de vue intellectuel. Un peu comme le public_transport 
V2, quoi…
 - PT_Assistant, c'est cool, mais quel pourcentage de contributeurs 
l'utilise ?
 - La contribution PT deviendra-t-elle réservée aux plus acharnés de la 
thématique ?


JB.


Le 07/09/2017 à 14:08, Jo a écrit :
J'en ai découpé une bonne partie les dernières semaines ... 3 
mois.L'année dernière j'ai surtout testé PT_Assistant sur un réseau 
'clean', celui que j'avais cartographié en bonne partie moi-même en 
Belgique. Cette année-ci je me suis concentré de le tester un peu 
partout dans le monde pour être confident que le plugin en soi ne 
cause pas de dégâts imprévus et qu'il avertit en cas de 'vrais problèmes'.


Ma préférence est de découper les giratoires, donc je l'ai fait, mais 
bien sûr, avant d'envoyer vers le serveur, le plugin m'avertissait 
d'éventuelles ruptures. dans toutes les lignes affectées. Je suis donc 
certain que toutes les relations ont été verifiées.


Jo



2017-09-07 12:52 GMT+02:00 lenny.libre <lenny.li...@orange.fr 
<mailto:lenny.li...@orange.fr>>:




Le 07/09/2017 à 09:44, Vincent Pottier a écrit :

Le 07/09/2017 à 08:54, JB a écrit :

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le
repérage et la saisie des données au plus simple, et que
les tâches ingrates comme le découpage des rond-point
devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un
rendu transport, je me demande presque si les trajets ne
devraient pas être carrément recalculés intégralement par
un routeur pour aboutir à quelque chose de cohérent. Pour
exemple sur les réseaux tram (donc avec vraiment des voies
en propres et un réseau évoluant peu), j'ai été désespéré
dans certains cas par les relations existantes. Alors
quand j'imagine ce que ça pourrait donner pour les bus…
    JB.

Il me semblait que la question avait été traitée, discutée et
résolue il y a quelques années. De mémoire, voici la synthèse
des résultats de discussions.

Comme le disait Philippe, les ronds-points sont à considérer
comme points un peu gros, sauf cas particuliers de
constitution (genre : https://osm.org/go/0CUlN2EHd?m=
<https://osm.org/go/0CUlN2EHd?m=> ).

C'est au logiciel de navigation (ou de rendu) de calculer la
portion empruntée (ce que savent bien faire les logiciels de
navigation), portion changeante qu'on soit à pied, à cheval ou
en voiture.

Donc, non, on ne les fractionne pas, sauf cas particuliers,
qui ne sont pas de l'ordre du routage.

Ces discussions ont changé ma pratique. Et maintenant, je
fusionne les ronds-points fractionnés pour raisons de routage
(trajets de bus ou itinéraires pédestres).

FrViPofm

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

Peut-être faut-il poser des question simples, les réponses ne
concernant que ce que j'ai vu, ce sont mes statistiques.

Qui découpe les giratoires ?
- le contributeur qui décrit des différence entre les différents
tronçons : c'est la même logique que la découpe de tronçons de
voirie avec des différences (type de voie, vitesse ...)
- le contributeur de lignes de transport public qui veut voir le
routage exact.

Quelles applications ont besoin de giratoires découpés ?
- aucune : les applis de routage savent fonctionner avec ou sans
découpage

Quel est l'impact du découpage/fusion ?
- lorsque je consultais certaines lignes de transport public qui
me tenaient à cœur, je trouvais qu'elles n'avaient plus de
continuité parce qu'un contributeur avait découpé un giratoire
pour voir aff

Re: [OSM-talk-fr] Trajets de bus et ronds--points

[JB]

Bof.
Je pense que la valeur ajoutée du mappeur est plus dans le repérage et 
la saisie des données au plus simple, et que les tâches ingrates comme 
le découpage des rond-point devraient être sous-traitées aux outils.
Personnellement, après avoir commencé à trifouiller un rendu transport, 
je me demande presque si les trajets ne devraient pas être carrément 
recalculés intégralement par un routeur pour aboutir à quelque chose de 
cohérent. Pour exemple sur les réseaux tram (donc avec vraiment des 
voies en propres et un réseau évoluant peu), j'ai été désespéré dans 
certains cas par les relations existantes. Alors quand j'imagine ce que 
ça pourrait donner pour les bus…

JB.

Le 07/09/2017 à 06:35, Jo a écrit :
Depuis quelques mois nous avons enfin une façon de taguer les bus_bay. 
Pour les ajouter le chemin est également découpé deux fois. S'il se 
trouve sur le rond-point c'est une autre raison pour le découper.


Dire que c'est au rendu de dessiner les lignes de bus en partiel sur 
les rond-points, c'est facile. Néanmoins, ce n'est pas quelque chose 
qui sera implémenté dans un futur proche. Probablement jamais. Diviser 
les rond-points, c'est quelque chose qu'un mappeur peut faire 
facilement et ça ne heurte personne. Ça décrit très précisement les 
trajets des bus, surtout quand la même ligne emprunte le rond-point 
plusieurs fois, ou s'il n'emprunte pas certaines parties, parce qu'il 
y a des 'fourches' en oneway avant ou derrière.


Polyglot

2017-09-07 1:52 GMT+02:00 Philippe Verdy <verd...@wanadoo.fr 
<mailto:verd...@wanadoo.fr>>:


Je le pense aussi. Un giratoire sur le tracé d'un ligne est très
aisément détectable même et surtout si c'est un way fermé. Si le
dessin du cercle est "gênant" en zoom avant, il suffit de le
considérer comme si ce n'était pas une ligne mais un disque,
assimilable à un point un peu plis gros en son centre. De plus un
bus peut encore être amené à faire plus que 1 tour s'il est gêné
pour sortir, cela ne remet pas en cause le trajet de la ligne.

C'est pareil pour les itinéraires routiers pour automobiles,
camions ou cyclistes, et même pour les piétons (s'il y a peur eux
un chemin permettant de passer par le centre d'un grand giratoire
en passant par des passages protégés, ce chemin sera marqué de
même que les connexions aux rues arrivant au rond point, et dans
ce cas le piéton n'utilisera pas le tracé circulaire du giratoire.

Dans tous les cas, on sait par où on y entre et par où en en sort.
Briser les giratoires ne sert pas à grand chose.

Je n'ai vus que quelques seul cas où ça peut être utile
- : si le giratoire passe emprunte des ponts au dessus d'autres
voies routières/ferrée/cyclistes ou un avec cours d'eau passant
dessous et évitant le giratoire. Le but étant alors de mettre des
attributs différents sur des sections du giratoire, notamment les
barrières de sécurité (mais on peut aussi représenter ces
barrières sur des chemins parallèles.) mais surtout les
l'attributs "layer" et "bridge=yes" (dont on peut pourtant se
passer en mettant le layer sur les voies qui traversent en dessous.
- Si le giratoire passe sous d'autres ponts il n'est jamais
nécessaire de le couper (ce sont ces ponts qu'on va découper
éventuellement)
- Si le giratoire passe dans des sections en tunnel (exemple en
Andorre) voire sous un bâtiment un "layer=-n" sera éventuellement
nécessaire mais on pourrait être gêné par le fait que ce layer
passe alors aussi en dessous des "landuse" environnants s'ils
englobent la surface du giratoire

Certains veulent découper les giratoires à ponts pour uniquement
le rendu (qui détoure les voies des ponts par un filet noir : à
mon avis ça se règle par une correction dans le moteur de rendu,
pour que ce filet ne vienne pas en surimpression des voies
connectées (comme si ce filet noir était des barrières barrant les
accès). On peut faire autrement en évitant "bridge=yes" sur ces
sections de giratoire, et mettant plutôt tunnel pour les voies en
dessous, et en ajoutant les barrières de sécurité de chaque côté
du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
giratoire".

Pour les assistants de navigation GPS, ils disent "entrez dans le
giratoire/rond-point, prenez la deuxième sortie" et ça suffit car
il n'y a pas d'autres chemins possibles et si celui qui ne connait
pas bien le coin rate la bonne sortie, il sait qu'il va devoir
faire le tour complet pour la retrouver et n'a pas besoin de
toucher à son GPS!

Il reste les rares cas de giratoires avec des feux temporaires
(fonctionnant en giratoire la plupart du temps quand les feux sont
éteints mais en carrefour avec des voies plus prioritaires qui les
traversent quand les feux sont allumés

Re: [OSM-talk-fr] Fwd: Re: Tagguer des abris pour tente au sommet d'un pic

[JB]

amenity=shelter + roof=no ?
On est pas sur la piste du mémorable amenity=drinking_water + 
drinking_water=no ?


Le 06/09/2017 à 19:51, Antoine Riche a écrit :


Oops, pardon : plutôt roof=no que wall=no




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

Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

[JB]

Le 04/09/2017 à 22:55, Philippe Verdy a écrit :
Dernière note: 

Apparemment pas !

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

Re: [OSM-talk-fr] harmonisation tag network "Arc en ciel" dans le département du Nord région Hauts-de-France

[JB]

Quelques notes suite à ton message :
Il y a 600 abonnés à talk-fr. Des statistiques sur 5 personnes n'ont pas 
de sens.
Le nombre de messages quotidien est déjà bien trop important, 
heureusement que 600 personnes n'ont pas donné leur avis par retour de 
mail.
La liste existe depuis de nombreuses années, et les plus anciens avec le 
plus de recul sont rarement ceux qui interviennent le plus et avec le 
plus d'insistance (probablement avec le réflexe : « est-ce que ce mail 
vaut le coup d'être envoyé ? »).
Ce genre de discussion a déjà été abordé moultes fois, avec toujours la 
même issue : on taggue ce qu'il y a sur le terrain.

JB.
PS : ce message n'appelle pas forcément de réponse. Sauf si elle vaut la 
peine d'être lue par 600 personnes.


Le 01/09/2017 à 17:00, marc marc a écrit :

Résultat après une semaine de vote :
Point 1 : changer le nom du réseau pour lui ajouter un suffixe
afin de le rendre humainement clair & unique
Vincent pour
Noémie contre
djakk contre
Jean-Yvon contre
Marc pour
Le non l'emporte, on est très loin d'un consensus.
Pas de consensus non plus sur la signification du tag : "humainement
parlant" <> "ne pas changer que le nord" <> "ne pas être différent
de l'officiel"

Point 2 : harmoniser avec la valeur locale la plus courante
"Arc en ciel" qui est aussi celle du site web
Vincent pour
Noémie pour
Jean-Yvon pour
Marc pour
premier gagnant : l'abstention :)
vu l'unanimité, j'ai fait l’opération

je suis content, on a progressé, même si c'est un pas minuscule :)

Le 25. 08. 17 à 01:38, Marc M. a écrit :

Bonsoir,

Je me propose de résoudre ce "doublon" "Arc en ciel"
D'abord merci à Lenny qui a fait déjà fait la moitié du travail :-)

Nom proposé pour le réseau : "Arc en Ciel (Nord)"

La typographie (la majuscule et les espaces) vient de la valeur
actuellement la plus présente.
Le suffixe "Nord" vient de leur site et la page wikipedia
qui indique qu'aujourd'hui (août 2017), c'est le département du Nord
qui s'occupe du réseau.

Critère de sélection :
tag network ayant les 3 mots "arc en ciel" sans faire de différence
entre les majuscules et minuscules.
étendue de la sélection : la région Hauts-de-France

Récurrence : possible si de nouveaux objets apparaissent
avec la mauvaise valeur.
J'essayerai bien évidement dans la mesure du possible
de prévenir au préalable le contributeur.

Raison du choix : essayer de contenter tout le monde
C'est à la fois un nom pour humain (l'utilisateur sait
facilement à quoi cela se rapporte) et c'est aussi
un nom unique à ce jour et qui pourrait le rester.

Il y a quelques valeurs qui renseignent le chiffre 2 parce
que leur réseau est divisé en 4 secteurs (de 1 à 4).
Si quelqu'un a une idée d'un sous-tag où mettre cette info,
Je la migrerai dans un sous-tag.
Si pas d'idée ou une majorité contre ou pas d'intérêt, je garderai
cette info dans le tag network comme c'est le cas actuellement.

Coïncidence, ce réseau changera au 1er septembre de couverture
pour s'étendre à la région (source : leur site web).
S'il y a une majorité avant cette date, je le renommerai avec "Nord"
avant le 1er septembre puis en "Arc en Ciel (Hauts-de-France)"
à partir du 1er septembre.
Cela ne me dérange pas et cela m'arrange même histoire à la fois
de ne pas attendre jusqu'au 1er septembre et à la fois d'avoir
une opération réelle de modification de nom de réseau à documenter.
Si la discussion traîne au delà du 1er septembre, je modifierai
évidement le nom directement en "Arc en Ciel (Hauts-de-France)"

L'opération ne concerne volontairement PAS :
- quoi faire le jour où ce réseau s'étend hors de la région.
- le réseau "Arc-en-ciel (Haute-Garonne)", par respect pour son travail,
je verrai cela séparément avec Lenny.
- regrouper tout dans une relation network <> des tag network
Je sélectionne les objets avec le tag. je ne modifie ni à la hausse
ni à la baisse le nombre ni de tag ni de relation (c'est un AUTRE sujet)
- le tag operator (c'est une AUTRE sujet)
- migrer des tags du mobilier vers stop_area (c'est une AUTRE sujet)
- un tag avec une ref osm (autre discussion en cours)
- wikidata ou pas, j'ignore même s'il y a un wikidata pour ce réseau.
Si quelqu'un a envie de chercher/créer/mettre à jour, ce serrait
bien venu. Ou attendre le 1er septembre pour pas changer 2 fois.
Moi cela m'est égal. Mais je veux bien l'ajouter dans la foulée.
- quelqu'un sait s'il y a des pages wiki où il faudrait mettre à jour
le tag network de ce réseau ? un contributeur non présent ici
à prévenir ? sinon je chercherai.

N'ayant aucune connaissance de terrain des objets modifiés,
ceux-ci seront uniquement sélectionnés par requête et vu
le nombre, je modifierai l'ensemble des valeurs avec
la fonction chercher de JOSM.
Cette opération est donc un "changement mécanique" au sens de :

https://wiki.openstreetmap.org/wiki/FR:Code_de_conduite_des

Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

[JB]

Le 30/08/2017 à 11:36, Francois Gouget a écrit :

On Tue, 29 Aug 2017, marc marc wrote:
Le 29. 08. 17 à 04:31, Francois Gouget a écrit :

je ne connais pas trop le format des numéros de téĺéphone
dans les autres pays.

le format est international:)

Je voulais dire que je ne sais pas s'il faut enlever le 0 pour les
autres pays. Apparemment il ne faut pas pour l'Italie.
Euh, juste pour me rassurer : Si vous faites une modification 
automatique, vous vous limitez à la France, hein ?
Déjà chez nous on n'est pas sûr d'être d'accord, mais si en plus on va 
mettre le bordel chez les voisins…

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

Re: [OSM-talk-fr] Comment tagger des abris fermés en montagne

[JB]

Tiens, j'ai l'impression de me répéter ce matin.
Si l'abri est fermé à clef, est-ce vraiment un « amenity » (service) ? 
S'il est privé, non accessible, c'est un bien batiment mais probablement 
pas un service, donc pas de clef amenity, non ?

JB.

Le 16/08/2017 à 12:22, emeric Prouteau a écrit :

Bonjour,

Lors de mes randonnées de ce weekend j'ai relevé de nombreux Orris 
(Abris en pierre de berger en Ariège). Pour les caractériser je 
souhaite utiliser les tags suivants :


  * Lorsqu'il est assez gros, faire une surface avec building=yes
  * Lorsqu'il vraiment petit et difficile d'en faire le contour faire
un noeud simple avec les infos ci-dessous

Ensuite pour les deux cas je souhaite ajouter :

  * amenity=shelter
  * shelter_type=basic_hut

Par contre certains de ces abris sont fermés car utilisés par des 
bergers l'été. Du coup quel tag utiliser pour ajouter cette 
information afin que les randonneurs puisse faire la différence avec 
un abri ouvert.


Bonne journée
--
*Emeric PROUTEAU*
*/Ingénieur en géomatique/
emeric.prout...@gmail.com <mailto:emeric.prout...@gmail.com>

/Avant d'imprimer. Pensons à l'environnement.
Save paper. Do you really need to print this e-mail?/*


___
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] Point d'eau potable hors service

[JB]

S'il n'y a pas d'eau qui coule, je ne le note pas avec 
amenity=drinking_water (ben non, il n'y a pas d'eau). Ceux qui cherchent 
un point d'eau ne filtreront pas les tags supplémentaires, donc 
l'information qu'il est cassé doit être dans le tag principal. 
disused:amenity=drinking_water avec un note ou description=* est le plus 
adapté.

JB.

Le 16/08/2017 à 06:45, Jean-Christophe Becquet a écrit :

Bonjour,

J'ai contribué un point d'eau potable avec le greffon Contribuer à OSM
d'Osmand~ :
https://www.openstreetmap.org/node/5037241738
amenity=drinking_water


Quel est le meilleur moyen d'indiquer que le robinet ne fonctionne pas ?

disused=yes
http://wiki.openstreetmap.org/wiki/FR:Tag:disused%3Dyes

stateofrepair=needs_repair
comme proposé sur
http://wiki.openstreetmap.org/wiki/Proposed_features/Drinking_water_attributes

operational_status=out_of_order
https://taginfo.openstreetmap.org/tags/operational_status=out_of_order

L'idée ensuite : une requête Overpass qui viendrait alimenter une carte
Umap à destination des services techniques de la ville ?

De toutes façons, il me semble utile de prévenir les éventuels usagers
de la base OSM que le point d'eau est HS.

Merci

Bonne journée

JC



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

Re: [OSM-talk-fr] Ancien chemin plus utilisable : suppression ou tag ?

[JB]

J'opte pour le "disused:highway=*". Si le chemin est rouvert un jour, il 
n'y a qu'un tag à changer. Sur les rendus classiques, il n'est pas présent.
Et quand j'essaye d'y passer, j'ai souvent un sécateur. Au bout de 
quelques fois, il repasse en highway=path…

JB.

Le 02/08/2017 à 10:46, pepilepi...@ovh.fr a écrit :

Le 01/08/2017 à 22:18, Jean-Claude Repetto a écrit :

Le 01/08/2017 à 21:38, marc marc a écrit :

Je la passerais en tracktype grade5 qui correspond à ce que tu décris
: le chemin existe en mode théorique et devinette sur le terrain


Non, ce serait plutôt le tag trail_visibility qu'il faudrait utiliser.
Par exemple:
trail_visibility=horrible

Jean-Claude

Non, c'est bien pire que ça ! Le deuxième on ne PEUT PAS y passer, sauf
à se promener avec une machette ou une débroussailleuse.

JP


___
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



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

Re: [OSM-talk-fr] Autoriser les ways mal fichus sous JOSM

[JB]

Alors,
Juste pour remettre les choses dans le bon sens : Non, ce n'est pas une 
bonne idée d'utiliser ces ways mal fichus dans OSM. Oui, il en existe 
dans la base. Non, avec la dernière (et avant-dernière) version de JOSM, 
je n'arrive plus à les tracer (le chemin se déconnecte automatiquement 
dès qu'un node est utilisé deux fois). Oui, c'est probablement une bonne 
chose.


Par contre, pour un usage de création de géométries de test, ça devient 
galère d'aller modifier le fichier .osm en mode texte à la place 
d'utiliser directement JOSM.
D'où la question initiale : est-ce qu'il existe un réglage très bien 
caché qui désactive cette sécurité ? Je n'ai rien trouvé dans les 
réglages avancés.


Bonne soirée,
JB.

Le 12/07/2017 à 21:27, Philippe Verdy a écrit :
Le 5 juillet 2017 à 16:39, JB <jb...@mailoo.org 
<mailto:jb...@mailoo.org>> a écrit :


Bonjour,
Je découvre que JOSM ne permet plus de tracer des ways qui
repassent par les mêmes nodes. Peut-être que pour la contribution,
c'est conseillé (je n'y ai pas réfléchi de trop près), mais
j'utilise aussi JOSM pour bidouiller des fichiers .osm, et c'était
vraiment pratique.
Je n'ai pas trouvé dans les options avancées si c'était possible
de désactiver cette fonction. Est-ce que quelqu'un de vous en
saurait plus ?


JOSM n'empêche pas du tout de le faire, mais il a des règles incluses 
dans les options de son "validateur", qui est activé par défaut avant 
d'envoyer et signales les anomalies (en fonction des tags utilisés car 
une géométrie peut être valide pour certains tags et invalide pour 
d'autres).


Les règles activées par défaut sont celles conseillées car reconnues 
par les usages les plus fréquents. On peut toujours passer outre et 
envoyer, mais JOSM nous a prévenu que des outils utilisateurs de ces 
données pourraient ne pas aimer et avoir un comportement inattendu ou 
ne pas pouvoir lever des ambiguïtés d'interprétation (et produire 
alors des anomalies de rendu par exemple, ou des difficultés sérieuses 
pour les moteurs de calcul d'itinéraires ou les moteurs de recherche, 
ou pour le géotagging par exemple avec Nominatim)


D'ailleurs il n'y a pas que JOSM, car iD effectue lui aussi des 
validations et donne des avertissements avant la validation (le 
comportement d'iD en revanche est bloquant: on ne peut pas toujours 
passer outre certains types d'avertissements, tels que l'oubli des 
tags sur des noeuds ou ways ou même des relations, ou encore les 
autointersections d'un way avec lui même sur des longueurs de segments 
non nulles)



___
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] Autoriser les ways mal fichus sous JOSM

[JB]

Bonjour,
J'aurais dû dire chemin qui passe par les mêmes tronçons, comme celui-là 
(un seul way sélectionné, le tronçon horizontal est utilisé dans les 
deux sens) :


C'est utile pour tester des cas extrêmes (et pas tout-à-fait impossibles 
à avoir dans OSM).

JB.

Le 12/07/2017 à 09:48, lenny.libre a écrit :

Le 05/07/2017 à 16:39, JB a écrit :

Bonjour,
Je découvre que JOSM ne permet plus de tracer des ways qui repassent 
par les mêmes nodes. Peut-être que pour la contribution, c'est 
conseillé (je n'y ai pas réfléchi de trop près), mais j'utilise aussi 
JOSM pour bidouiller des fichiers .osm, et c'était vraiment pratique.
Je n'ai pas trouvé dans les options avancées si c'était possible de 
désactiver cette fonction. Est-ce que quelqu'un de vous en saurait 
plus ?

JB.

Bonjour.
Je ne comprends pas, pourrais-tu préciser ?
Je n'ai pas de soucis par exemple : j'ai créé des ways  - 1 et 2 qui 
forment tous les deux le même quadrilatère et le 3 qui emprunte 3 
nodes communs



___
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] Questions de tagging pour des objets en lien avec les services de secours

[JB]

Oups. Il y a des vendredis soir où je ferais mieux d'aller dormir au 
lieu d'écrire…


Le 07/07/2017 à 20:19, Eric Brosselin - Osm a écrit :

Le 07/07/2017 à 19:58, JB a écrit :
Avec un peu de retard à l'allumage, j'aurais quand même voulu 
signaler man_made=monitoring_station + monitoring:water_level, qui me 
semble beaucoup plus adapté que le historic=high_water_mark qui est 
plus orienté historic/tourism.

https://wiki.openstreetmap.org/wiki/Key:monitoring:water_level


Ah non je ne pense pas ce n'est pas la même chose qu'un repère de crue.

Les *monitoring stations* (bien regarder la clé générale >>> 
https://wiki.openstreetmap.org/wiki/FR:Tag:man_made%3Dmonitoring_station 
) sont des stations de mesure qui affichent (critère "display") et / 
ou enregistrent (critère "recording") des informations  dans 
différents secteurs de surveillance.
_Exemples_ :  niveau des eaux, activité sismique, météo, trafic 
routier, niveau des radiations,  et même activité météoritique !


La demande originelle portait sur les repères (marqueurs) de crues 
avec les hauteurs d'eau.
Donc oui c'est «historique» à partir du moment où on a un "souvenir" 
de la crue qui prend la forme d'une plaque  (désormais officielle) 
avec une hauteur et une date.





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

Re: [OSM-talk-fr] Questions de tagging pour des objets en lien avec les services de secours

[JB]

Avec un peu de retard à l'allumage, j'aurais quand même voulu signaler 
man_made=monitoring_station + monitoring:water_level, qui me semble 
beaucoup plus adapté que le historic=high_water_mark qui est plus 
orienté historic/tourism.

https://wiki.openstreetmap.org/wiki/Key:monitoring:water_level
Ensuite, je plussoie tout-à-fait Nicolas sur le fait qu'on peut 
difficilement demander un filtrage fin pour une première utilisation. En 
première utilisation, on va filtrer amenity=fire_station, sans regarder 
les autres tag (seasonal et autres). Pour cette raison, je pense aussi 
que réutiliser amenity=fire_station sur ce qui n'en est pas vraiment une 
(à ce que j'ai compris) n'est pas une bonne idée.
(Est-ce qu'on taggue amenity=restaurant sur une cantine scolaire ? Si 
oui, est-ce vraiment une bonne idée ?).

JB.

Le 07/07/2017 à 19:26, Eric Brosselin - Osm a écrit :

Bonjour,


Quelques exemples d'utilisation ici :
<https://www.openstreetmap.org/node/4547027386>https://www.openstreetmap.org/node/4547027386
<https://www.openstreetmap.org/node/4547027386>



Merci de me citer


_Pour information_ :
J'ai un jour (je ne sais plus comment) récupéré sur le site de la 
DREAL une partie des marqueurs de crues de la Loire (depuis Tours  je 
crois)
En les chargeant dans JOSM je me suis aperçu que la géolocalisation 
n'était pas super précise
Il y avait environ 4 à 6m de décalage avec la position réelle. C'est 
un facteur auquel il faut penser.




Le 06/07/2017 à 10:57, Thibaud B a écrit :
Concernant les repère de crues il y a déjà un tag documenté dans le 
wiki ça peut être une bonne base :


https://wiki.openstreetmap.org/wiki/FR:Tag:historic%3Dhighwater_mark



Il y a également quelqu'un qui a crée ce tag  "Flood mark" >>> 
http://wiki.openstreetmap.org/wiki/Key:flood_mark

Les utilisations (261) sont uniquement en Pologne
et apparemment c'est la suite de ce tag "High water mark" >>> 
http://wiki.openstreetmap.org/wiki/Key:high_water_mark

20 utilisations seulement !

Il suggère aussi de mettre des tags «connexes» comme historic=memorial 
, ...



Certains SDIS posent maintenant des plaques officielles et 
normalisées qu'il serait à mon avis intéressant d'ajouter

dans OSM.
Il y a une base officielle à laquelle on peut contribuer >>> 
https://www.reperesdecrues.developpement-durable.gouv.fr

Ils utilisent OpenStreetMap comme fond de carte




___
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

[OSM-talk-fr] Autoriser les ways mal fichus sous JOSM

[JB]

Bonjour,
Je découvre que JOSM ne permet plus de tracer des ways qui repassent par 
les mêmes nodes. Peut-être que pour la contribution, c'est conseillé (je 
n'y ai pas réfléchi de trop près), mais j'utilise aussi JOSM pour 
bidouiller des fichiers .osm, et c'était vraiment pratique.
Je n'ai pas trouvé dans les options avancées si c'était possible de 
désactiver cette fonction. Est-ce que quelqu'un de vous en saurait plus ?

JB.

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

Re: [OSM-talk-fr] Moulinette pour ajouter tag à plusieurs objets?

[JB]

Euh, je parle à Shohreh, évidemment… Mes excuses si ce n'était pas 
tout-à-fait clair…


Le 27/06/2017 à 15:46, JB a écrit :

Le 27/06/2017 à 14:43, Vincent de Château-Thierry a écrit :
Sinon une remarque en passant : shop=bicycle pour un Decathlon ou un 
Go Sport est très réducteur. On est dans l'archétype de shop=sports 
avec ces enseignes.

Et que tu as dis toi-même dans le premier message :

des/les magasins Décathlon

Du coup, je doute vraiment de l'intérêt d'une telle modification.
Et que vu les fils de discussion successifs, ton problème est plus du 
coté de la feuille de style de CycleMap que du coté des données.

JB.


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

Re: [OSM-talk-fr] Moulinette pour ajouter tag à plusieurs objets?

[JB]

Le 27/06/2017 à 14:43, Vincent de Château-Thierry a écrit :

Sinon une remarque en passant : shop=bicycle pour un Decathlon ou un Go Sport 
est très réducteur. On est dans l'archétype de shop=sports avec ces enseignes.

Et que tu as dis toi-même dans le premier message :

des/les magasins Décathlon

Du coup, je doute vraiment de l'intérêt d'une telle modification.
Et que vu les fils de discussion successifs, ton problème est plus du 
coté de la feuille de style de CycleMap que du coté des données.

JB.


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

Re: [OSM-talk-fr] Présentation

[JB]

Bonsoir bonsoir,
Après réflexion, j'ai quand même envie de mettre mon grain de sel dans 
la discussion avec une question principale : « Pourquoi QGis ? »
C'est une question sérieuse. Est-ce après comparaison d'alternatives, ou 
juste parce que c'est l'outil auquel on est habitué ?
En fait, la carte papier a été évoquée plusieurs fois à Avignon, avec à 
chaque fois cette observation : c'est plus compliqué que ce qu'on 
pourrait penser. Et à chaque fois, il a été observé qu'il ne semblait 
pas réaliste d'automatiser intégralement la chaine de production. Que 
pour une qualité correcte, un humain devait intervenir quelque part. 
Pour la carte de Digne-les-Bains par exemple, la plus grosse partie de 
placement d'étiquettes a été fait dans Illustrator (j'espère ne pas 
déformer l'information, c'est ce que j'en ai compris). Dans la 
présentation de carte de randonnée, les replacements d'étiquettes 
étaient réalisés dans la feuille de style. Thomas indiquait que si QGis 
pouvait replacer des étiquettes, une intervention humaine pouvait 
également être possible ou nécessaire. Charles indiquait qu'il avait 
également passé un bout de temps à placer des étiquettes pour la carte 
de Clermont-Ferrand l'année dernière.
Du coup, avec le recul, entre l'importation des données et le coté 
relativement laborieux du travail dans QGis, la galère de la chaine 
d'utilisation Mapnik, les défauts de Maperitive, je me dis qu'il doit 
encore manquer un outil quelque part.
Mais quand même : quand on a l'habitude de travailler avec les tags OSM, 
la feuille de style Maperitive, c'est top.

Voilà voilà,
JB.

Le 20/06/2017 à 14:53, Carto SIG a écrit :

Bonjour Emeric,

Bienvenue. Cela me fait penser que de manière très malpolie, je ne me suis pas 
présenté en arrivant sur la liste et dans OSM il y a un peu moins de 2 ans. Je 
travaille pour le SIG d'une collectivité (Pays de Redon - Bretagne Sud) et on 
utilise OSM dans le cadre professionnel avec différents objectifs notamment 
produire des plans papiers (plan de ville, fond de plan 1/10e, plan de 
localisation) et faire des relevés sur l'accessibilité de la ville de Redon 
avec OSM et Mapcontrib (projet cartomobilité). En complément, on contribue 
aussi à Mapillary. Je ferme la parenthèse.

Emeric, tu es peut être déjà tombé sur les tutos d'Anita Graser (mais les 
styles de Charles sont de l'excellent travail bien évidemment, on va 
probablement basculer à l'occasion ;) ):
https://anitagraser.com/2014/05/31/a-guide-to-googlemaps-like-maps-with-osm-in-qgis/

La méthode utilisée pour le plan de ville de Digne-les-Bains tombe également 
bien dans le cadre de ce que tu veux faire (usage de Qgis avec les styles de 
Charles), elle a été présentée au dernier SOTM, j'espère qu'on peut la 
retrouver en ligne.

JB avait aussi présenté un beau rendu que tu retrouveras dans la liste de 
discussion mais il utilisait Maperitive alors cela sort un peu de ton cadre (et 
du mien).

Bref, n'hésite pas à partager le résultat de ton travail, cela m'intéresse (et 
plein d'autres certainement). On a notamment un office de tourisme qui sera 
forcément ravi qu'on puisse lui réaliser plus facilement des plans des sentiers 
de randonnée. D'ailleurs, est-ce que quelqu'un connait d'autres fichiers de 
styles pour Qgis prévus pour les données OSM (en dehors de ceux déjà cités de 
Charles, d'Anita Graser et de Charley Glynn : 
https://github.com/charleyglynn/OSM-Shapefile-QGIS-stylesheets) ? Ce serait 
sympa d'avoir une bibliothèque de styles OSM pour Qgis.

Bonne journée à tous,
Etienne Chauchaix
s...@pays-redon.fr

--

Message: 1
Date: Mon, 19 Jun 2017 14:55:05 +0200
From: Charles MILLET <charlesmil...@free.fr>
To: talk-fr@openstreetmap.org
Subject: Re: [OSM-talk-fr] Présentation
Message-ID: <86f2bb50-2d90-17d4-dcdc-23a3ad0fd...@free.fr>
Content-Type: text/plain; charset="utf-8"; Format="flowed"

Bonjour Émeric,

Bienvenu sur la liste.

On partage quelques centres d'intérêt : je pousse depuis quelques temps des 
méthodes de production de cartes sous QGIS à partir de données OSM, n'hésite 
pas à regarder le tuto que j'ai rédigé et les styles attachés 
(http://cartocite.fr/tutoriels-openstreetmap/).

Sinon pour la randonnées tu connais déjà OsmAnd et BRouter peut-être ?

Charles MILLET
charlesmil...@free.fr

Le 19/06/2017 à 09:31, emeric Prouteau a écrit :

Bonjour,

Contributeur OSM depuis 2009 avec des périodes plus ou moins actives,
je me suis remis dedans de manière active depuis 1 an.

J'utilise essentiellement OSM dans le cadre de mon activité favorite
la randonnée.

Egalement responsable du service SIG d'une collectivité mon métier me
rend très sensible à la qualité de la données et notamment sa bonne
qualification.

Mon projet du moment est la réalisation de cartes de randonnée via
l'utilisation des données OSM et du logiciel Qgis sans avoir recourt à
du code en automatisant au maximum la chaîne 

Re: [OSM-talk-fr] Test rendu carte

[JB]

Bonjour,
Pour conclure sur la carte de Samoëns, voici une version finale ici : 
http://randocarto.fr/demo/Samoens_A1_400dpi.png. Quelques bidouilles en 
plus (et un bug en moins) de la version 7. Florian a déjà partagé 
l'édition Bambiche.
À Avignon, j'ai rapidement présenté la démarche, la présentation est 
disponible ici : 
https://nextcloud.openstreetmap.fr/index.php/s/TpM5DnYe9C5mCWV/download?path=%2F=SotMFR2017_JB_Carte_Papier.pdf. 
Depuis, la partie suggérée en conclusion a été codée, elle est là : 
https://github.com/JBacc1/compare_osm. Christian avait proposé une autre 
évolution, celle-là n'est pas encore codée mais ça viendra surement. Je 
la testerai probablement sur une autre zone test… peut-être dans les 
Vosges ?

Voilà voilà,
Merci encore pour tous vos retours, merci à Romuald71 pour ses 
contributions dans la zone.

JB.

Le 06/06/2017 à 11:57, Florian LAINEZ a écrit :
Merci JB pour la version Bambiche ! Dispo en plusieurs résolutions à 
l'adresse http://panneauxbiche.com/Samoens/
SotM c'est quand même top pour avancer sur les vrais sujets qui 
comptent ;)



Le 24 avril 2017 à 23:26, <osm.sanspourr...@spamgourmet.com 
<mailto:osm.sanspourr...@spamgourmet.com>> a écrit :


Le 07/04/2017 à 05:40, JB - jb...@mailoo.org
<mailto:jb...@mailoo.org> a écrit :


Le 3 avril 2017 à 21:44, Philippe Verdy <verd...@wanadoo.fr
<mailto:verd...@wanadoo.fr>> a écrit :

Joli, mais peut-être que la mention en rouge de "Chap." pour
chapelle est redondante avec le symbole déjà affiché pour
une chapelle, et n'apporte rien de plus (pas de nom consacré
de chapelle)

+1

Autant, sur d'autres éléments, je valide, autant, vu l'importance
touristique mise sur les chapelles dans le coin, j'avais plutôt
envie de les mettre vraiment en avant.

C'est avec un beau picto et non avec un hideux Chap. que tu les
mettras en avant.
À quoi ça sert de faire une si belle carte ?


Autres détails :

-Les ruisseaux sont bien mieux rendus : super


Je maintiens qu'un fil de contour (plus fin que celui des routes)
bleu foncé vaudrait le coup d'être essayé.

Cols : plutôt que de mettre un chiffre entre parenthèses, ajouter
un espace insécable puis m après ce chiffre. Plus léger et plus
explicite.

Quand les derniers picto seront en vectoriel, ce sera vraiment une
très belle carte.

Jean-Yvon

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




--

*Florian Lainez*

@overflorian <http://twitter.com/overflorian>


___
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] limite de bureau de vote

[JB]

Les ways boundary=polling_station ne semblent pas être pris en charge
par Overpass ? Les problèmes arrivent à chaque endroit où la relation
utilise un way avec pour seul tag boundary=polling_station. Du coté de
http://api.openstreetmap.fr/analyse/cgi-bin/index.py, ça passe bien.
Après coté technique,c'est peut-être directement chez eux qu'il faudra
aller demander…
JB.

Le 11.05.2017 09:36, Nicolas Dumoulin a écrit :

> Salut,
> 
> J'ai commencé à saisir les limites de bureau de vote de
> Clermont-Ferrand, et j'ai un petit soucis quand je les regarde avec
> overpass-turbo :
> http://overpass-turbo.eu/?q=LyoKVGhpcyBoYcSGYmVlbiBnxI1lcmF0ZWQgYnkgdGhlIG92xJJwxIlzLXR1cmJvIHdpemFyZC7EgsSdxJ9yaWdpbmFsIHNlxLBjaMSsxIk6CsOiwoDCnMSqdW5kxLB5PXBvbGzEumdfc3TElGlvxI7EuiBDbMSSbcWddC1GxJLEk8WNxYjCnQoqLwpbb3V0OmpzxZ1dW3RpbWXFs8W1MjVdOwovLyBmZXTFgiDEsMWAIMWIwpzFocWjxaXFp8WpYcWrwoDCncSbxKvEv8WBxYPEugp7e8SQb2NvZGVBcsWAOsaUcsWkbsWmxahyxapkfX0tPi7Gn3LFgsasxYDGhcaHxI_ElMSdciDGrXN1bHRzCigKICDHhHF1xJLEmsSjcnTGiW9yOsaRxYnFi8WNxY_FkcWTxZVuxZfFmcWbxZ3FrMeSIG7GqWVbIsejxY5yeSI9IsWSxZTFlsWYxZrFvMWdIl0oxo9hxr3FgMa_aMeBYSnGhceTd2F5x7THtsWPx7rHvMenx7_Hq8iCbsiEyIbGrciIxr7HgMihyI_Hr8atbMesbsiVxbPHpMe4yJjHvceox6rIgcWcyJ7IhciHyInGoMiNyKbIpseEcMS3xrPHiWXHi8eNx4_GgMSYxql5xoU-xoXJh3NrZcS9cXQ7=BK8NBlHnRN
> 
> Aux alentours de la place de Jaude, chez moi, un polygone part un
> peu en vrille.
> En vérifiant les relations dans josm et sur
> ra.osmsurround.org/analyzeRelation ça semble OK.
> Dites-moi si vous voyez quelque-chose de bizarre.
> 
> Merci___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Test rendu carte

[JB]

Bonjour,

Et voilà la version 7 de la carte de randonnée autour de Samoëns qui 
arrive : http://randocarto.fr/temp/Samoens_v7_A1_400dpi.png

Alors, depuis la V4, il s'est passé quelques bricoles.
Je suis passé chez l'imprimeur avec la v6. Je ne suis pas persuadé que 
l'étalonnage des couleurs y soit vérifié de temps en temps, je lui 
poserai la question une prochaine fois. Pour les curieux, ça m'a couté 
7€ sur papier basique (peut-être un peu moins si imprimé par deux côte à 
côte). Le prix des impressions grand format est vraiment à la baisse !
Globalement, il y a quelques différences entre la v6 et cette v7. La 
version imprimée m'a encouragé discrètement modifier quelques points de 
la feuille de style, notamment pour essayer d'améliorer la lisibilité de 
certains textes. J'ai aussi déplacé quelques étiquettes trop masquantes. 
Je n'ai pas encore repassé cette version à l'impression pour voir 
l'évolution. Il y aura peut-être une v8 à venir, on verra.


Pour ceux que ça intéresse, la proposition de présentation au SotM-FR à 
Avignon a été retenue. Si ça ne bouge pas, elle semble prévue le samedi 
après-midi et j'essayerai d'y présenter la démarche et les outils 
utilisés. Il faut encore que je mette tout ça en forme d'ici-là…


Sinon, pour Denis et les sac_scale : oui, je comprends toujours… et je 
ne pense pas que je changerai. Mais la liberté apportée par les feuilles 
de style, c'est que chacun peut modifier à son goût et adapter à l'usage 
ou l'usager.
Pour JY : tu t'approches du troll sur certains points. Sinon, pour les 
rivières, un filet bleu ferait double-emploi avec les riverbanks quand 
ils sont présents. Pour les altitudes, à voir, ça se défend mais pas 
convaincu.


Voilà voilà,
JB.

Le 17/04/2017 à 19:21, JB a écrit :
J'ai trainé un peu pour la version 4, une carte pour un jeu de Pâques 
m'a retardé…

Alors, la V4 : http://randocarto.fr/temp/Samoens_v4_A1_400dpi.png
Le nombre de modifications diminue… Voici les retours à vos remarques 
précédentes.


Même question pour les spots d'escalade, dont celui-ci fait
partie http://www.openstreetmap.org/way/357090500
<http://www.openstreetmap.org/way/357090500>


Idem : sport=climbing. Dans le cas que tu indiques, il y avait 4
spots à proximité, j'en ai gardé un au milieu.

bien noté. par contre je ne vois toujours pas l’icône à cet endroit là
Ben, comme je disais, c'est celle du rocher juste à coté qui est 
rendu… Si on mettait les 4 icônes, elles se superposeraient.


-dans le cimetière de Samoëns, les chemins recouvrent
complétement le symbole qui permet de le distinguer


J'en ai viré certains, mais le cimetière est trop petit pour
vraiment bien les voir.

je suggère de ne pas rendre du tout les chemins pour faciliter la 
lisibilité
L'essai semble vaguement concluant… pas tout à fait convaincu ni par 
une solution ni par l'autre.


-je ne parviens pas du tout à distinguer les réserves
naturelles. Exemple :
http://www.openstreetmap.org/relation/1023742
<http://www.openstreetmap.org/relation/1023742>


Un multipolygone incomplet, je n'avais pas fait attention. Il est
de retour.

je suggère d'accentuer encore la ligne de démarcation et surtout de 
rajouter un gros label

Ça me semble déjà bien visible !
les deux petits lacs "les laouchets" méritent peut-être un seul label 
au lieu de deux

Effectivement, c'est mieux comme ça.

1. Il y a un truc bizarre avec les courbes de niveaux à l'ouest de la 
Pointe-Rousse. Je sais pas à quoi ressemble le coin en vrai, mais là … bizarre.
C'est lié aux limites du MNT, ici le SRTM1, avec des relief d'à-pic 
(on voit bien l'échantillonnage, du coup). Je n'ai pas approfondi pour 
utiliser d'autres sources, mais ce serait un (très) gros morceau, et 
créerait probablement également des problèmes d'interprétation.

2. Quelqu'un a parlé des ruisseaux, moi je trouve la couleur un peu trop pâle, 
et est difficilement discernable à certains endroits mais c'est peut-être mon 
écran
À voir à l'impression, mais il me semble que lors d'essais précédents, 
ça passait bien.

3. Certains textes pourraient être remplacés par des pictos comme "gend." ou "pomp.". 
Mais bon apparemment comme tu tiens aux "chap." en plus du picto … c'est un style.
À multiplier les pictos, on perd en compréhension immédiate. C'est 
pour ça qu'ils sont rassemblés en sous-types. (D'ailleurs, il va 
falloir que je me mette à modifier la série des ronds bleus, un peu 
longue à mon goût actuel).

4. Le patrimoine naturel et culturel (chap.) c'est chouette, mais quelques 
troquets et auberges ce serait sympa aussi
Oui, mais ça reste une carte « rando » au sens large… Comme toutes les 
cartes, il faut prioriser et choisir où s'arrêter dans les éléments 
rendus.
Ben oui, c'est vrai, mais ça me choque quand même, ce n'est pas tout 
à fait le même usage. J'aimerai bien que les itinéraire alpins soient 
identifiés par d'autres symboles que ceux des

Re: [OSM-talk-fr] Supprimer un landuse Corine étendu

[JB]

Mes condoléances. J'ai déjà fait de la découpe de gros MP sur quelques 
zones, ça reste assez galère.

Deux options d'après mes tests :
 - grignoter petit à petit : comme le MP a plusieurs « cols » (espaces 
fins) le long d'éléments linéaires (routes), tu peux le grignoter 
petit-à-petit, par exemple là où il croise la N12. Avec le plugin « 
Boite d'outils relations », ça se laisse faire pour réarranger les 
inners dans les bons morceaux.
 - pour supprimer complètement, et perdre toutes les informations de 
landuse liées : télécharger la grande zone dans JOSM avec overpass-API 
(je vais peut-être me faire taper dessus, là, mais c'est pour la bonne 
cause…), et supprimer la relation. Voir s'il reste des objets sans tag 
(autre que source) et ne faisant partie d'aucune relation et les virer 
ensuite.
Voilà voilà, dans les deux cas, il faut se poser et ne pas essayer 
d'aller trop vite…

JB.

Le 26/04/2017 à 16:32, PanierAvide a écrit :

Bonjour à tous,

Je souhaite supprimer le multi-polygone Corine suivant [1], qui a 
tendance à être assez galère à rogner à chaque précision de 
l'occupation des sols sur une commune de la zone. J'ai bien une idée 
de comment le supprimer (à l'aide de Level0), mais avant je souhaite 
savoir s'il y a une "bonne méthode" pour le supprimer proprement, sans 
casser d'autres objets qui pourraient éventuellement dépendre de 
certains ways de la relation. Si ce n'est pas souhaitable de le 
supprimer, existe t'il une manière un peu automatisée de le redécouper 
en plusieurs plus petites relations, plus simples à gérer ?


Cordialement,

Adrien.

[1] http://www.openstreetmap.org/relation/279458


___
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] Test rendu carte − retours bienvenus

[JB]

J'ai trainé un peu pour la version 4, une carte pour un jeu de Pâques 
m'a retardé…

Alors, la V4 : http://randocarto.fr/temp/Samoens_v4_A1_400dpi.png
Le nombre de modifications diminue… Voici les retours à vos remarques 
précédentes.


Même question pour les spots d'escalade, dont celui-ci fait
partie http://www.openstreetmap.org/way/357090500
<http://www.openstreetmap.org/way/357090500>


Idem : sport=climbing. Dans le cas que tu indiques, il y avait 4
spots à proximité, j'en ai gardé un au milieu.

bien noté. par contre je ne vois toujours pas l’icône à cet endroit là
Ben, comme je disais, c'est celle du rocher juste à coté qui est rendu… 
Si on mettait les 4 icônes, elles se superposeraient.


-dans le cimetière de Samoëns, les chemins recouvrent
complétement le symbole qui permet de le distinguer


J'en ai viré certains, mais le cimetière est trop petit pour
vraiment bien les voir.

je suggère de ne pas rendre du tout les chemins pour faciliter la 
lisibilité
L'essai semble vaguement concluant… pas tout à fait convaincu ni par une 
solution ni par l'autre.


-je ne parviens pas du tout à distinguer les réserves naturelles.
Exemple : http://www.openstreetmap.org/relation/1023742
<http://www.openstreetmap.org/relation/1023742>


Un multipolygone incomplet, je n'avais pas fait attention. Il est
de retour.

je suggère d'accentuer encore la ligne de démarcation et surtout de 
rajouter un gros label

Ça me semble déjà bien visible !
les deux petits lacs "les laouchets" méritent peut-être un seul label 
au lieu de deux

Effectivement, c'est mieux comme ça.

1. Il y a un truc bizarre avec les courbes de niveaux à l'ouest de la 
Pointe-Rousse. Je sais pas à quoi ressemble le coin en vrai, mais là … bizarre.
C'est lié aux limites du MNT, ici le SRTM1, avec des relief d'à-pic (on 
voit bien l'échantillonnage, du coup). Je n'ai pas approfondi pour 
utiliser d'autres sources, mais ce serait un (très) gros morceau, et 
créerait probablement également des problèmes d'interprétation.

2. Quelqu'un a parlé des ruisseaux, moi je trouve la couleur un peu trop pâle, 
et est difficilement discernable à certains endroits mais c'est peut-être mon 
écran
À voir à l'impression, mais il me semble que lors d'essais précédents, 
ça passait bien.

3. Certains textes pourraient être remplacés par des pictos comme "gend." ou "pomp.". 
Mais bon apparemment comme tu tiens aux "chap." en plus du picto … c'est un style.
À multiplier les pictos, on perd en compréhension immédiate. C'est pour 
ça qu'ils sont rassemblés en sous-types. (D'ailleurs, il va falloir que 
je me mette à modifier la série des ronds bleus, un peu longue à mon 
goût actuel).

4. Le patrimoine naturel et culturel (chap.) c'est chouette, mais quelques 
troquets et auberges ce serait sympa aussi
Oui, mais ça reste une carte « rando » au sens large… Comme toutes les 
cartes, il faut prioriser et choisir où s'arrêter dans les éléments rendus.
Ben oui, c'est vrai, mais ça me choque quand même, ce n'est pas tout à 
fait le même usage. J'aimerai bien que les itinéraire alpins soient 
identifiés par d'autres symboles que ceux des sentiers, par exemple 
par pointillés rouges, comme sur les cartes Didier-Richard.
Je comprends. Mais ça me semble être un usage plus spécialisé. Par 
exemple, j'apprécie beaucoup les cartes de course d'orientation, mais je 
ne pense pas qu'une carte avec les prairies en jaune et les forêts en 
blanc (entre autres) soit facilement appréhendée par le « grand public ».

2. Quelqu'un a parlé des ruisseaux
Moi, et je proposais d'ajouter un filet, bleu nuit par exemple pour mieux 
détourer.
Ça donne un bon rendu pour les routes et ça donne une idée de limite entre deux 
milieux.
La technique du filet implique une largeur trop importante pour être 
adaptée aux petits cours d'eau (et foireuse quand les riverbank sont 
cartographiés). Comme dit, il me semble qu'à l'impression, ça sortait 
pas trop mal.


D'ailleurs, une des étapes prochaines sera le passage chez un imprimeur 
voir ce que ça donne « en vrai », une fois sorti de l'écran pour aller 
sur le papier.
Si vous voyez toujours des choses étranges, n'hésitez pas. Sinon, je 
sortirai une version sans l'annotation « document de travail » et avec 
la date d'extraction des données.

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

Re: [OSM-talk-fr] Bureaux de vote

[JB]

Pas convaincu par name=Bureau de vote n°##.
Pour moi, ça décrit juste amenity=polling_station + ref=##, et ça aurait 
plus sa place dans description=*…

Mais bon, je suis toujours un peu ronchon de ce coté là…
JB.

Le 14/04/2017 à 15:24, David Crochet a écrit :

Bonjour


Le 14/04/2017 à 15:08, Christian Quest a écrit :

Pour info: http://www.openstreetmap.org/relation/6669934

Ce sont les limites des bureaux de vote sur ma commune. Pour le 
bureau lui même je n'avais pas identifié ce tag 
amenity=polling_station, mais j'ai déjà le polling_station:ref=*


J'aurais donné des noms plus explicite aux relations :
voici ce que cela donne sur Caen : http://overpass-turbo.eu/s/omT

Cordialement

David Crochet


___
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] Test rendu carte − retours bienvenus

[JB]

C'est ça, et pour Maperitive, c'est du SRTM à 1° (ici) ou 3° (par défaut).
JB.

Le 08/04/2017 à 09:47, Nicolas Bétheuil a écrit :

J'ai pas cherché avant de poser la question, j'ai trouvé SRTM & ASTER.

merci

Le 8 avril 2017 à 09:43, Nicolas Bétheuil <nbethe...@free.fr 
<mailto:nbethe...@free.fr>> a écrit :


Hello,

Pour ma culture, d'où vienne les courbes de niveau ? Ça me parait
un travail titanesque pour un contributeur humain. merci

Le 8 avril 2017 à 08:27, <osm.sanspourr...@spamgourmet.com
<mailto:osm.sanspourr...@spamgourmet.com>> a écrit :

>
> 2. Quelqu'un a parlé des ruisseaux
Moi, et je proposais d'ajouter un filet, bleu nuit par exemple
pour mieux détourer.
Ça donne un bon rendu pour les routes et ça donne une idée de
limite entre deux milieux.
> 3. Certains textes
+1
>
> 4
+1 mais il faut peut-être deux styles, un pour ceux qui vont à
la messe et un pour ceux qui vont au bistrot 


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





___
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] Test rendu carte − retours bienvenus

[JB]

ctuellement encore des bitmaps, et
les nuages de points nécessaires devraient être plus denses dans
les zones de forte pente pour avoir une dérivation correcte
(alternative: faire des interpolations avec des splines
quadratiques ou cubiques, pour faire des triangulations en
facettes 3D; améliorer la précision et la stabilité des dérivées
successives avec des facettes non plus planes mais en splines
surfaciques). J'ai conscience que cela demande un travail énorme
comparable à un rendu 3D avec des quantités énormes de facettes à
traiter, donc beaucoup de mémoire si on veut couvrir même une
seule montagne ou un seul plateau sur une zone carrée d'environ 20
km de côté où peuvent s'imbriquer déjà pas loin de 1000 niveaux
d'isohypses à 1 mètre et parfois plusieurs centaines sur les
petites surfaces où justement on cherche les falaises et crêtes.
Il y a sans doute des heurisitques pour éliminer rapidement des
zones mais elles risquent d'éliminer des endroit où une ligne de
falaise forme une pointe ou une petite avancée qu'elle contourne


Le 3 avril 2017 à 21:44, Philippe Verdy <verd...@wanadoo.fr
<mailto:verd...@wanadoo.fr>> a écrit :

Joli, mais peut-être que la mention en rouge de "Chap." pour
chapelle est redondante avec le symbole déjà affiché pour une
chapelle, et n'apporte rien de plus (pas de nom consacré de
    chapelle)

Le 3 avril 2017 à 20:34, JB <jb...@mailoo.org
<mailto:jb...@mailoo.org>> a écrit :

Bonjour,
Je tente d'améliorer le rendu de cartes à partir de
données OSM. Le but est de voir jusqu'à quel niveau de
qualité on peut espérer arriver à partir des données
brutes, en croisant une feuille de style (R25) et un petit
peu de code. Ça reste plutôt expérimental. Sur conseil de
Florian qui a déjà fait une belle première salve de
critiques, je fais suivre l'information ici.
La carte, c'est ici :
http://randocarto.fr/temp/Samoens_v2_A1_400dpi.png
<http://randocarto.fr/temp/Samoens_v2_A1_400dpi.png>. Le
fichier est un peu lourd, 143mo. J'en suis à la version 2
de la carte, je ne sais pas combien de passes seront
nécessaires pour arriver aux limites des outils.
Du coup, je suis preneur de toutes les critiques sur la
carte elle-même. Si vous vous ennuyez, il est aussi
possible de contribuer dans la zone, par exemple sur les
landuses qui restent assez rustiques par endroits.
Voilà voilà, dès qu'on arrive à une version correcte, vous
pourrez aller randonner dans le coin avec OSM en version
papier.
JB.



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

Re: [OSM-talk-fr] villes avec vitesse limitée à 30km/h

[JB]

Le 06/04/2017 à 06:43, Florian LAINEZ a écrit :

Hello,
Je découvre une liste des communes dont la vitesse max autorisée aux 
véhicules est de 30km/h : https://ville30.org/les-villes-30/


En plus de mettre cette information dans la relation de la commune, 
pensez-vous qu'il faille taguer chaque way individuellement ? Pas sûr 
que les moteurs de calcul de vitesse aillent chercher l'info dans la 
relation...
Je suis même à peu près sûr que non. Et d'ailleurs, ce serait 
probablement faux : je vois que Grenoble est dans la liste, or seules 
certaines voies sont à 30, une bonne partie des axes principaux sont 
toujours à 50, il me semble.

JB.

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

[OSM-talk-fr] Test rendu carte − retours bienvenus

[JB]

Bonjour,
Je tente d'améliorer le rendu de cartes à partir de données OSM. Le but 
est de voir jusqu'à quel niveau de qualité on peut espérer arriver à 
partir des données brutes, en croisant une feuille de style (R25) et un 
petit peu de code. Ça reste plutôt expérimental. Sur conseil de Florian 
qui a déjà fait une belle première salve de critiques, je fais suivre 
l'information ici.
La carte, c'est ici : 
http://randocarto.fr/temp/Samoens_v2_A1_400dpi.png. Le fichier est un 
peu lourd, 143mo. J'en suis à la version 2 de la carte, je ne sais pas 
combien de passes seront nécessaires pour arriver aux limites des outils.
Du coup, je suis preneur de toutes les critiques sur la carte elle-même. 
Si vous vous ennuyez, il est aussi possible de contribuer dans la zone, 
par exemple sur les landuses qui restent assez rustiques par endroits.
Voilà voilà, dès qu'on arrive à une version correcte, vous pourrez aller 
randonner dans le coin avec OSM en version papier.

JB.

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

Re: [OSM-talk-fr] Référence pour une ancienne voie de chemin de fer

[JB]

Le 03/04/2017 à 19:34, osm.sanspourr...@spamgourmet.com a écrit :

Le 03/04/2017 à 09:03, JB - jb...@mailoo.org a écrit :

Le 02/04/2017 à 20:50, osm.sanspourr...@spamgourmet.com a écrit :


plutôt que old_ref et old_name (qui ne sont pas faux en soit), si tu 
as des dates tu peux préciser :


name:-1960-05-24=Ligne de La Possonnière à Niort

ref:-1960-05-24= 523000
(et si tu sais depuis quand c'est une voie verte, tu en fais de même 
mais avec une date de début pour le nom de la voie verte.


Sauf qu'il me semble que c'est très fortement déconseillé : pas 
d'élément variable dans la clé. Donc pas de date dans la clé.

JB.

Que nenni, c'est possible pour les dates.
À mettre en plus de name et de ref, old_name et old_ref afin que les 
application qui ne l'exploitent pas marchent normalement.

https://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts#Date_namespace_suffix_as_.22keyname:DATESPEC.3D...22
Absolument, et comme le dit la page de détail : "This is a proposal (and 
should be treated as such)" : 
https://wiki.openstreetmap.org/wiki/Proposed_features/Date_namespace et 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Date_namespace#This_is_a_proposal


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

Re: [OSM-talk-fr] Référence pour une ancienne voie de chemin de fer

[JB]

Le 02/04/2017 à 20:50, osm.sanspourr...@spamgourmet.com a écrit :


plutôt que old_ref et old_name (qui ne sont pas faux en soit), si tu 
as des dates tu peux préciser :


name:-1960-05-24=Ligne de La Possonnière à Niort

ref:-1960-05-24= 523000
(et si tu sais depuis quand c'est une voie verte, tu en fais de même 
mais avec une date de début pour le nom de la voie verte.


Sauf qu'il me semble que c'est très fortement déconseillé : pas 
d'élément variable dans la clé. Donc pas de date dans la clé.

JB.


Extrait du lien que tu nous as passé :

  * Section de Breuil-Barret à Puy-de-Serre (PK 118,810 à, 127,814) :
24 mai 1960^6

<https://fr.wikipedia.org/wiki/Ligne_de_La_Possonni%C3%A8re_%C3%A0_Niort#cite_note-6>
.
  * Section de Puy-de-Serre à Benet (PK 127,814 à 151,800) : 24
juillet 1973^7

<https://fr.wikipedia.org/wiki/Ligne_de_La_Possonni%C3%A8re_%C3%A0_Niort#cite_note-7>
.
  * Section de Nueil-les-Aubiers à Bressuire (PK73,520 à 88,900) : 17
octobre 1994^8

<https://fr.wikipedia.org/wiki/Ligne_de_La_Possonni%C3%A8re_%C3%A0_Niort#cite_note-8>
.
  * Section de Bressuire à Breuil-Barret (PK 88,900 à 118,810) : 12
février 2001^9

<https://fr.wikipedia.org/wiki/Ligne_de_La_Possonni%C3%A8re_%C3%A0_Niort#cite_note-9>
.

Le 02/04/2017 à 15:42, Christian Quest - cqu...@openstreetmap.fr a écrit :

old_ref semble adapté, pas que pour faire plaisir à osmose.

Le 2 avril 2017 à 13:10, Francois Gouget <fgou...@free.fr 
<mailto:fgou...@free.fr>> a écrit :



Il s'agit de la ligne de La Possonnière à Niort qui d'après mes
sources
a la référence 523000 :

https://fr.wikipedia.org/wiki/Ligne_de_La_Possonni%C3%A8re_%C3%A0_Niort
<https://fr.wikipedia.org/wiki/Ligne_de_La_Possonni%C3%A8re_%C3%A0_Niort>



--
Christian Quest - OpenStreetMap France


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




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


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

Re: [OSM-talk-fr] Cartographie des églises

[JB]

Salut,
Je crois que personne ne l'a encore fait remarquer, mais bravo pour le 
boulot et l'acharnement ! J'adhère complètement !

JB.
PS : des fois, j'ai un petit remord de n'avoir rien fait pour tenter de 
faire survivre le sujet/projet du mois


Le 12/03/2017 à 15:30, Gaël Simon a écrit :
Allez, maintenant 51315 lieux de culte. La Normandie devrait 
maintenant disposer d'au moins un lieu de culte par commune (pour 
celles en ayant). A noter une contribution active récemment dans les 
Vosges ;-)



Gaël

Le 8 févr. 2017 à 08:39, Gaël SIMON <gael.simon...@gmail.com 
<mailto:gael.simon...@gmail.com>> a écrit :


Bonjour à tous,
désormais 49858 lieux de culte en France !
Après la Bretagne, les Pays-de-la-Loire, la Corse et 
Auvergne-Rhône-Alpes, la Nouvelle-Aquitaine rejoint le club des 
régions dont la majorité des communes possèdent désormais au moins un 
lieu de culte.
Je m'attaque maintenant à l'Île-de-France, déjà bien fournie, avant un 
séjour, potentiellement prolongé, dans les Hauts-de-France (où 413 
communes sont à traiter).


Le suivi global : https://framapic.org/Zxkwbm9piZ9I/ZkzKoMeuG9NI.PNG
Les noms en Nouvelle-Aquitaine : 
https://framapic.org/94LDs8srkkiX/3rp2ZSUY9f4d.PNG


Le 20 janvier 2017 à 15:39, Gaël SIMON <gael.simon...@gmail.com 
<mailto:gael.simon...@gmail.com>> a écrit :



Bonjour,
voici quelques copies d'écran de mon outil de suivi
(malheureusement non partageable simplement).
Page d'accueil synthétique du tableau de bord :
https://framapic.org/SlOcpLo3mVZN/j2xztpK2RQCC.PNG
<https://framapic.org/SlOcpLo3mVZN/j2xztpK2RQCC.PNG>
Détails de localisation, avec les noms / sans nom :
https://framapic.org/U0OFac5IZEwK/ohKlsTSfUoJe.PNG
<https://framapic.org/U0OFac5IZEwK/ohKlsTSfUoJe.PNG>
Répartition des noms dans département :
https://framapic.org/f90tlVcSq8Mk/BbcJlclR3bPb.PNG
<https://framapic.org/f90tlVcSq8Mk/BbcJlclR3bPb.PNG>




___
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] HebdoOSM

[JB]

Bon ben comme ça, on a un non-lecteur non-traducteur qui n'est pas 
d'accord avec les autres. Il serait non-au-courant, ça arrangerait juste 
tout le monde.

C'était mon mauvais esprit du soir, bon week-end,
JB.

Le 18/02/2017 à 21:10, Philippe Verdy a écrit :



Le 18 février 2017 à 15:47, Julien Coupey <jul...@coupey.fr 
<mailto:jul...@coupey.fr>> a écrit :


Comme ça a été dit, il vaut mieux une version française limitée
que pas de version du tout.


Pas d'accord quand ça consiste juste à copier-coller directement le 
contenu d'une traduction automatique SANS la relire et la comprendre. 
N'improte qui fait ça directement avec son navigateur web et les 
outils divers (avec en plus la possibilité de choisir le robot 
traducteur, ce qu'on perd totalement ici).


Bref que ceux qui veulent traduire le fassent, mais il faut au minimum 
comprendre ce qu'on lit dans la langue source (l'anglais au minimum, 
parfois comparer à la cible des liens qui ne sont pas toujours en 
anglais et pour lesquels il n'y a pas toujours de traduction anglaise 
disponible non plus) ET comprendre ce qui est écrit en français (pour 
corriger les contre-sens complets).


C'est la même chose sur la traduction de tous les wikis (OSM ou 
Wikimedia) ou sur tous les projets de traduction (même s'ils incluent 
une mémoire de traduction et eux aussi proposent des robots 
traducteurs): l'utilisation automatique de robots (Google translate) 
pour insérer ces traductions automatique sans les relire est bannie. 
La relecture intelligente est une étape indispensable. Je ne vois pas 
pourquoi ce ne serait pas non plus le cas pour WeeklyOSM, que ces 
fausses traductions déservent plus le projet qu'elles ne le servent : 
quand un lecteur utilise *lui-même* un robot dans son navigateur il 
sait à quoi s'attendre et sait que la traduction automatique peut être 
erronée et à ne pas prendre au pied de la lettre.


Et c'est encore plus vrai pour WeeklyOSM quand la source originale 
n'est en fait même pas l'anglais (souvent l'allemand, l'espagnol ou le 
russe), et où la version anglais proposée comme source est en fait une 
traduction approchante qui peut déjà contenir des tas de fautes de 
sens ou de grammaire non corrigées (surtout celles venant en fait du 
russe et de l'espagnol dont les locuteurs maîtrisent souvent plus mal 
l'anglais que les germanophones...) ce qui "perd" encore plus les 
traducteurs automatiques partant de cette traduction anglaise 
approximative.


D'ailleur WeeklyOSM se base encore en proposant toujours l'anglais 
comme source, sans nécessairement montrer les autres langues 
originales (qui peuvent pourtant servir à lever des ambiguités, utiles 
quand un détecte des non-sens pour savoir ce quu voulait être 
rélelement dit et que les robots parviennent encore moins à "comprendre")


Un bon outil de traductions doit permettre de voir les autres langues 
et pas seulement la source proposée par défaut, et contenir un espace 
de discussion/questions pour interroger les auteurs sur les ambiguités 
ou difficultés de traduction ou compréhension de leur texte. On a ça 
dans le moteur de traduction de MediaWiki, mais rarement dans plein 
d'autres outils qu'on trouve sur le web, qui en plus ne disposent pas 
non plus de mémoire de traduction (qui aide à maintenir un lexique 
homogène, mais qui n'est pas infaillible non plus surtout s'il ne 
propose qu'une seule version et pas d'autres adaptées aux autres 
usages réels).


Les moteurs de traduction (pour produire et publier ces traductions, 
ou en ligne intégrés dans le navigateur du client) proposent divers 
outils, c'est dommage d'en priver les lecteurs en ne leur offrant plus 
qu'une version pseudo-traduite automatiquement et non relue, juste 
parce que quelqu'un a fait quelques clics rapides dans le moteur pour 
faire croire qu'il a produit très vite 100% d'une traduction. Quand on 
ne comprend pas ce qu'on lit, on ne traduit pas à la place des autres.



___
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] Éjecté du forum

[JB]

Le 06/02/2017 à 22:33, Jocelyn Jaubert a écrit :
Maintenant, c'est configuré correctement, et le bannissement devrait 
marcher correctement.


Désolé,
Jocelyn

Pas de souci, merci pour le boulot !
JB.

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

[OSM-talk-fr] Éjecté du forum

[JB]

Hello,
Je suis le seul à avoir été éjecté du forum, avec pour message d'erreur ?
Vous avez été *définitivement* banni de ce forum.
Pour plus d’informations, veuillez contacter l’administrateur du forum 
<http://forum.openstreetmap.fr/memberlist.php?mode=contactadmin>.

Raison du bannissement : *spam*
/Votre adresse IP a été bannie./
J'ai rien fait de particulier, j'héberge pas de hacker à la maison, j'ai 
juste un fournisseur d'accès qui s'appelle OVH…

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

Re: [OSM-talk-fr] Cartographie des églises

[JB]

Quelques lignes de codes de plus, et un nuage d'églises vient compléter 
le nuage de mots : 
https://twitter.com/RandoCarto/status/822506562010877955 ou 
http://jb.isonoe.net/demo/MetM.png
J'y décompte 723 lieux de cultes chrétiens sous la forme way/relation, 
avec building=* et religion=christian. Ça peut coller ?

JB.

Le 18/01/2017 à 01:31, Donat ROBAUX a écrit :

Bonjour à tous,

Je suis plutôt assez fier de vous dire que le chantier des églises de 
Meurthe-et-Moselle est achevé.


Le département correspond au diocèse de Nancy-Toul.
L'objectif initial était d'avoir au moins une église par commune (au 
sens de code INSEE), moins les 8 communes qui n'en ont pas (0.88%).


Chaque église a les tags qui vont bien: /place_of_worship/, 
/religion/, /denomination/, /building/. Dans l'idéal il faudrait 
vérifier par commune et par/admin_level 9 .../



Église qui au-delà de son aspect cultuel est un point de repère 
évident pour tous (randonneurs, automobilistes,...) aussi bien dans le 
réel que sur les cartes. Ca permet aussi de ne pas perdre la mémoire 
des noms. Le site clochers.org <http://clochers.org> qui autorise la 
réutilisation des données à condition de citer est d'une grande aide. 
Il renseigne les lieux de culte (chrétiens) par code INSEE commune et 
indique souvent quand il s'agit d'anciennes communes fusionnées, ce 
qui est pratique. On a même les photos pour nous aider à différencier 
les formes de clocher ;)


J'en ai profité pour m'amuser de faire un nuage de mot des dédicaces 
(nom) des églises. J'en ai conclu que c'est souvent St-Martin qui 
détrône tout le monde avec 10% du total à lui tout seul. 
https://twitter.com/drobaux/status/821499898130534400 
<https://twitter.com/drobaux/status/821499898130534400>



Merci à Pierre-Yves qui m'a aidé à faire la requête pour vérifier 
l'exhaustivité de ma cartographie.



L'objectif à terme étant d'industrialiser ca via Mapcontrib ou autre:

 1. repérer les communes sans église (on les repère assez bien même
sans cadastre, notamment grâce aux clochers, aux noms de rue genre
rue l'église, ou encore aux bornes géodésiques)
 2. compléter les infos, notamment /name /(dédicace), /building/,
/denomination /et si on a la foi (c'est presque le cas de le dire)
les liens Wikipedia, Wikidata ou encore MHS pour faciliter le
tourisme.

Donat



___
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] Rendu FR, bientôt en version 2017 !

[JB]

Salut Christian,
Sacré boulot que tu fais là !
Par contre, en zone rurale (mon dada), le rendu international a bien 
avancé, mais pas repris sur le rendu FR. Notamment l'avancée principale 
: la réorganisation des tirets selon le tracktype serait très bienvenue, 
la progression actuelle étant incohérente pour le tracktype=grade4. 
(Sinon, le boulot fait sur les path/footway est intéressant aussi)
Voilà voilà, n'hésite pas à différencier encore un peu plus les locality 
des autres lieu-dits (j'aurais mis un coup de font-stretch ou son 
équivalent s'il existe sur mapnik sur les locality, par exemple).

JB.

Le 21/12/2016 à 19:45, Christian Quest a écrit :

Je profite des congés pour avancer sur le rendu FR...

La liste des commit s'allonge et donne une idée des changements: 
https://github.com/cquest/osmfr-cartocss/commits/master


Après avoir passé pas mal de temps sur les optimisations pour accélrer 
le rendu là où c'était le plus urgent, je suis de retour sur le côté 
graphique.


Une grosse nouveauté: l'estompage des objets "indoor" qui devrait 
alléger les abords de certaines gares ;) Pour ça, le rendu considère 
tout objet avec un level=* négatif comme indoor.


Les "shield" sur les routes sont mieux répartis. Pour cela, la requête 
SQL regroupe les différents tronçons ayant le même highway+ref car vu 
qu'on tronçonne de plus en plus il faut en passer par là !


Résultat visible sur 
http://umap.openstreetmap.fr/fr/map/test-rendu-osmfr_99740#6/47.376/2.186


Le pré-calcul des tuiles est en cours donc tout n'est pas encore dispo 
et peut nécessiter un délais de génération...



--
Christian Quest - OpenStreetMap France


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


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

Re: [OSM-talk-fr] Ancienne modélisation des multipolygones

[JB]

Salut Vincent,
J'avais vu ces outils passer, par contre je n'avais pas trouvé de 
manière facile pour les exploiter : en gros, quels sont les MP 
problématiques près de chez moi. Est-ce que j'ai raté une information, 
ou ils n'existent pas ? Par exemple, OSMInspector vers qui le site 
renvoie ne semble pas avoir de couche correspondante.

JB.

Le 12/12/2016 à 23:34, Vincent de Château-Thierry a écrit :

Bonsoir,
en echo à la discussion de ces jours-ci sur les parcelles forestières, 
voici une ressources dédiée au sujet des Multipolygons. On y voit 
l'influence du schema de tagging, notamment lorsque les attributs du 
polygone sont portés par les ways constituants. C'est transparent tant 
que les ways ont un jeu d'attributs homogène, ça devient beaucoup plus 
casse-tête dès que des valeurs divergent voire se contredisent.


Plusieurs facettes d'un même projet pour mettre en évidence ces 
"vieux" multipolygones :


la carte : http://area.jochentopf.com/map/index.html#16/48.8519/2.3124
les données en téléchargement : http://area.jochentopf.com/
les explications : 
https://github.com/osmlab/fixing-polygons-in-osm/blob/master/README.md


La carte permet de visualiser où se situent les multipolygones taggués 
à l'ancienne. Sur la partie droite, ils sont masqués.


À vos explorations...

vincent

___
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] Problème de représentation avec des parcelles forestières

[JB]

Oui, les multipolygones, c'est élégant d'un point de vue intellectuel et 
parfois, c'est absolument impraticable dans la réalité. Et impossible à 
maintenir. Pour 3 nœuds et trois ways, pourquoi inventer un MP plutôt 
qu'utiliser un chemin fermé simple ?
Sinon, je pense (à confirmer) que le rendu brun avec le nom de rue au 
milieu, c'est Mapnik qui considère que le MP représente un chemin 
(highway=*) : comme il ne reconnait pas le type de multipolygone utilisé 
(forest=section + ref), il prend le premier way, voit un highway=*, et 
considère que la surface est un highway avec un multipolygone mal 
conditionné. Et hop. Foireux pour foireux, tant qu'à faire…

JB.

Le 03/12/2016 à 18:29, LeTopographeFou a écrit :


Bonjour,

Suite à mon sujet sur les intersections en forêt j'ai essayé de savoir 
pourquoi certaines parcelles et chemins en forêt de Saint-Arnoult 
(mais pas que...) génèrent des soucis de dessin alors qu'elles 
paraissent toutes homogènes en terme de tags et qu'elles sont toutes 
fermées. Marron, gris, blanc, transparent... ce n'est pas homogène !


A noter que je suppose que les parcelles ne sont à priori pas 
dessinées (sinon on verrait son numéro, il n'y aurait pas de statut 
"proposition", et le rendu serait plus homogène que cela).


Voici mes constatations :

  * Rendu http://www.openstreetmap.org/#map=14/48.5553/1.9502
  o /Route de Madame/ et /Route de la Lieue/ ne sont pas écrits le
long du chemin mais au milieu de parcelles à l'horizontal (à
partir du niveau de zoom 15). En consultant les ways en
question, rien à signaler. Une idée ?
  o Il y a des zones marrons qui correspondent bizarrement aux
délimitations de certaines parcelles. Sauf que ces parcelles
n'ont rien de bizarre quand on regarde les tags (elles sont
bien fermées et toutes ne sont pas rendues de la même manière
alors qu'elles ont des tags identiques). Exemple :
http://www.openstreetmap.org/relation/1866710 Une idée ?
  o Là on a carrément une parcelle grise :
http://www.openstreetmap.org/relation/1853819
  * Rendu http://tile.openstreetmap.fr (je n'ai pas trouvé comment
récupérer un lien vers la zone consultée...)
  o Beaucoup plus de chemins sont tracés avec les noms au milieu
des parcelles et non le long du chemin. En fait c'est comme ci
le rendu dessinait les parcelles et prenait le nom du dernier
élément de la relation pour lui donner un nom de relation. Une
idée ?
  o Il y a moins de parcelles bizarrement dessinées mais il y en a
qu'en même (et on notera que ce ne sont pas les mêmes que sur
OSM.org). Exemple avec celle sous "Route de la jumelle" qui
apparait plus claire

Résultat : c'est moche et ca fait penser zone en construction... Je me 
demande si la manière avec laquelle les parcelles ont été 
cartographiées ne perturbe pas le moteur de rendu. Ou alors c'est un 
bug dans le moteur de rendu ?


A vous lire,

Cordialement,
--
LeTopographeFou


___
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] Rendu FR... un peu de neuf

[JB]

J'en profite aussi : en milieu rural, la gradation des tracktypes sur 
highway=track est maintenant beaucoup plus cohérent sur osm.org que sur 
l'ancienne version que tu as utilisée comme base.

JB.

Le 02/11/2016 à 16:38, Stéphane Péneau a écrit :

Hello Christian,

Je rebondis sur ton message 
https://lists.openstreetmap.org/pipermail/talk-fr/2016-November/082467.html


A l'OPL de Montreuil, il était question de rendre le nom des communes 
nouvelles sans avoir besoin de node place. Tu as ajouté ce rendu ?


A+

Stéphane

___
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] bétonnage à grande échelle

[JB]

Probablement lié à ça ?
https://twitter.com/Anonymaps/status/793756922767900672
JB.

Le 02/11/2016 à 10:14, Charles MILLET a écrit :


C'est le même phénomène qu'à Rennes comme vient de le faire remarquer 
PanierAvide.


Charles MILLET
charlesmil...@free.fr
Le 02/11/2016 à 09:47, Pierre-Yves Berrard a écrit :

Bonjour,

Est-ce que vous constatez comme moi un "grisage" de la carte, comme 
si une grande étendue avait été taguée comme "building" ?


http://www.openstreetmap.org/#map=15/48.9509/2.1376

Je n'arrive pas à identifier la source du problème Peut-être la 
correction est déjà faite et les tuiles se mettent à jour petit à 
petit...


PY


___
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


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

Re: [OSM-talk-fr] Résidences HLM

[JB]

Pour ma part, je n'aime pas.
Je pense que je mettrais place=neighbourhood + name=*. C'est un nom de 
petit quartier qu'on décrit.

JB.

Le 28/09/2016 à 20:51, Ralf Treinen a écrit :

On Wed, Sep 28, 2016 at 06:19:01PM +0200, JB wrote:

Le 28/09/2016 à 15:49, Tony Emery a écrit :

C'est pour ça que je met ce tag dans une
emprise de type landuse=residential.

Bof, une emprise landuse=residential empilée dans le landuse=résidential de
la ville ? Ou extrudée en multipolygone ? Pas convaincu ni par l'un ni par
l'autre, et vue la spécificité du sujet, peut-être du taggage spécifique est
à réfléchir (ou pas dans OSM, comme je le lis, je connais trop mal le sujet
pour avoir un avis pour l'instant).

N'est-ce pas ce qu'on fait déjà pour les résidences, je veux dire des
ensembles d'immeubles souvent entourés d'une cloture ? Indépendement de
la question si c'est du bas loyer ou pas.

Dans ce cas je met un landuse=residential et un name=* sur le terrain.
Faut-il le tagger différement ?

-Ralf.

___
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] Résidences HLM

[JB]

Le 28/09/2016 à 15:49, Tony Emery a écrit :

C'est pour ça que je met ce tag dans une
emprise de type landuse=residential.
Bof, une emprise landuse=residential empilée dans le landuse=résidential 
de la ville ? Ou extrudée en multipolygone ? Pas convaincu ni par l'un 
ni par l'autre, et vue la spécificité du sujet, peut-être du taggage 
spécifique est à réfléchir (ou pas dans OSM, comme je le lis, je connais 
trop mal le sujet pour avoir un avis pour l'instant).

JB.

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

Re: [OSM-talk-fr] PR points routiers et adresse

[JB]

Le 21/09/2016 à 19:49, osm.sanspourr...@spamgourmet.com a écrit :

On est alors plus dans un modèle style associatedStreet.
Ourk… surtout pas ! (Pour élaborer un peu plus : surtout pas de 
relations inutiles, surtout à cette échelle !)
Mais oui, ça fait bizarre de voir tout le monde intégrer ça à « grande » 
échelle avec chacun sa modélisation.
Et tant que j'y suis, ça me fait aussi bizarre de voir comme argument : 
« ce modèle ne va pas, Nominatim ne l'exploite pas »… En plus qu'on ne 
taggue pas pour le géocodeur, je ne suis pas persuadé que les PR soient 
vraiment utilisés par le grand public, et que ceux qui en auront 
l'utilité auront développé des outils pour ça.

JB.

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

Re: [OSM-talk-fr] Rendu FR... un peu de neuf

[JB]

Le 08/09/2016 à 09:45, Christian Quest a écrit :
Pour les embankment là aussi il faut faire un choix graphique... si 
vous avez des idées ou propositions, je suis preneur !
Pour R25, je me suis inspiré du rendu de course d'orientation, qui est 
proche de ce qu'utilise l'IGN : 
http://jb.isonoe.net/CR/demo/l%C3%A9gende8.png quelque part au milieu. 
C'est décliné en levée de terre seule, cutting/embankment pour les 
routes, etc. (de mémoire assez laborieux pour aller bien pour chaque 
largeur de route, voie ferrée…)

JB.

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

Re: [OSM-talk-fr] Cela vaut le coup ?

[JB]

Le 24/08/2016 à 13:53, David Crochet a écrit :
Cela vaut le coup d'un access:conditional=no@week 34 Mo-Su 
00:00-24:00; week 35 Mo-We 00:00-24:00 ?

Surtout pas, c'est pas récurent d'une année sur l'autre !
JB.
(Pour moi, si ça termine dans moins d'un mois, ça met plus le bordel 
chez les utilisateurs de données, surtout s'ils ne mettent pas leur base 
à jour quotidiennement…)


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

Re: [OSM-talk-fr] Arrivée d'un itinéraire de pélerinage en Bretagne à mapper

[JB]

C'est bête, j'ai pas trouvé à récupérer une trace gpx… Sinon, j'aurais 
essayé dare-dare de voir ce que ça peut donner avec CarnetRando/R25…

JB.

Le 08/08/2016 à 18:26, Christian Rogel a écrit :
Le Tro Breiz (Tour de Bretagne) est un très ancien pélerinage qui a la 
particularité d’être circulaire et dont l’itinéraire de 500 km relie 7 
cathédrales (Quimper, St-Pol-de-Léon, Tréguier, Saint-Brieuc, 
Saint-Malo, Dol-de-Bretagne et Vannes) en passant près de nombre de 
chapelles et de croix de chemin.

On écrit aussi Trobreiz et Tro Breizh.

Une association, Les Chemins du Tro Breiz, patronne une marche ouverte 
à tous, couvrant l’une des étapes chaque année. Au début de ce mois, 
1300 marcheurs sont allés de Quimper à Saint-Pol.
J’avais rencontré une balise « Tro Breiz » et remarqué qu’un certain 
Yvon Autret avait signé, d’une part un topoguide (et un livre guide) 
et, d’autre part, une application Android 
<https://play.google.com/store/apps/details?id=carte50.bretagne>  
incluant les traces GPS reportées sur une carte (IGN ?). Noter qu’il 
utilise aussi OSM en le créditant


Je l’ai interrogé sur la question de la licéité de mettre l’itinéraire 
(moderne), soit par observation des balises, soit par récupération,


Extrait de la réponse :
/"On peut mettre l'itinéraire TB dans la base OSM. //J'ai la totalité 
de l'itinéraire et de ses variantes sous forme de traces GPS.C'est 
d'ailleurs déjà en ligne sur http://permanent.trobreiz.com,mais avec 
une précision réduite./
/J'ai établi moi-même la totalité du circuit et effectué tous les 
enregistrements GPS.Il n'y a donc pas d'autorisation à demander à 
l'association TB (ce qui n'empêche pas de lui en faire part).
Le nom TROBREIZ (ainsi que les variantes du nom) n'a jamais été déposé 
et n'importe qui peut l’utiliser."
A mon avis il faudrait faire comme pour St-Jacques et indiquer dans 
OSM soit "TROBREIZ" en majuscule et tout attaché, soit "Tro Breizh".

/

La réponse contient 3 points importants :

- Selon Y. Autret, le travali de balisage et de recueil des traces 
qu’il a fait, ne doivent rien à l’association les Chemins du Tro Breiz 
qui, cependant, les mentionnent sur son site (voir URL plus haut).


- Le nom Tro Breiz n’ayant pas été déposé, il n’y a pas d’obstacle à 
l'appellation de l’itinéraire dans OSM


- Il a bien saisi que la réédition ultérieure de son topoguide 
pourrait être basée sur des outils OSM et il trouve intéressant uMap 
que je lui ai fait connaïtre. Citation : /« Je vous conseille de 
prendre contact avec Coop-Breizhpour voir si les cartes OSM peuvent 
les intéresser pour l'édition du nouveau topoguide, voire d'autres 
livres. Les cartes actuelles sont des cartes au 1/7 faites "à la 
main"par une société spécialisée »./

/
/
Je voudrais donc savoir si  la communauté OSM de Bretagne et au-delà 
(d’où envoi parallèle sur la liste OSM FR) trouve intéressant d’ouvrir 
ce chantier.


Le schéma de taggage est :
type <http://wiki.openstreetmap.org/wiki/Key:type>=route
route <http://wiki.openstreetmap.org/wiki/Key:route>=hiking/bicycle
pilgrimage <http://wiki.openstreetmap.org/wiki/Key:pilgrimage>=yes
ref <http://wiki.openstreetmap.org/wiki/Key:ref>=NN
name <http://wiki.openstreetmap.org/wiki/Key:name>=/NNN/
network <http://wiki.openstreetmap.org/wiki/Key:network>=inc/ncn
/operator/ <http://wiki.openstreetmap.org/wiki/Key:operator>/=nn/
/symbol/ <http://wiki.openstreetmap.org/wiki/Key:symbol>/=/NNN
religion <http://wiki.openstreetmap.org/wiki/Key:religion>=/NNN/
/
/
Le principal obstacle pour la récupération des traces GPS est que Yvon 
Autret ne semble pas sensibilisé à la question de formalisation de la 
licence de réutilisation. Que faudrait-il li suggérer?



Christian R.
Mandataire OSM France pour la Cornouaille historique.


___
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] botdidier2020 est mort !

[JB]

Euh, en même temps, c'est pas dans les bonnes pratiques, de faire 
tourner les bots et de faire de l'armchair mapping dans son pays (mis à 
part pour l'humanitaire) ?
Personnellement, la réponse de SomeoneElse ne me choque ni dans un cas, 
ni dans l'autre.
Vous vous souvenez de la réaction des Français quand PN (il me semble) 
était venu supprimer des multipolygones de landuse en France ?

JB.

Le 01/08/2016 à 19:37, Jérôme Amagat a écrit :
Moi aussi, j'ai déjà eu quelques commentaires de SomeoneElse mais pas 
de blocage juste un revert :( parce que soit disant c’était un 
"armchair edit".
Et il m'a dit aussi que je devais expliquer aux autres contributeurs 
pourquoi je modifiais ce qu'ils avaient créé. ça devient tout de suite 
plus chiant s'il faut aller donner des explications précises à chaque 
fois que l'on touche à un objet même quand l'objet a été créé il y a 
plusieurs années.
Maintenant j’évite l'Angleterre et les changeset trop grand (plusieurs 
pays ou plusieurs continent) pour passer sous le radar :)



2016-08-01 18:30 GMT+02:00 didier2020 <didier2...@free.fr 
<mailto:didier2...@free.fr>>:


http://www.openstreetmap.org/changeset/4643

il re-su-sitera peut etre quand il se sera calmé 


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




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
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] Points d'apport volontaire verre ou bornes à verre

[JB]

Très rapidement, je me demande si la différentiation ne vient pas 
d'Allemagne où le conteneur n'est pas forcément le même pour le pot à 
moutarde, la bouteille verte, la bouteille blanche ou la bouteille 
brune. En France, il ne me viendrait pas à l'esprit d'utiliser autre 
chose que recycling:glass. Si glass est à oui, alors les bouteilles sont 
prises avec. L'inverse n'est pas vrai.

JB.

Le 29/07/2016 à 17:34, Vincent Bergeot a écrit :

Le 29/07/2016 à 17:10, Stéphane Péneau a écrit :

Le 29/07/2016 à 16:37, Vincent Bergeot a écrit :


Bonjour,

suite à un échange concernant les tags associés aux bornes à verre 
pour le recyclages du verre, je souhaiterai avoir vos avis sur les 
tags à utiliser !


En effet sur le wiki, nous avons 
(http://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Drecycling):

|recycling:glass=yes/no|Verre.
|recycling:glass_bottles=yes/no|Bouteilles de verre uniquement.


Or, aux bornes à verres peuvent être amenés tous les verres à usage 
alimentaire, incluant bouteilles mais pas uniquement car aussi les 
bocaux, pots de moutarde, verre pour boire -> donc 
recycling:glass_bottles=yes n'est pas suffisant


Attention, en général, on ne met pas les verres de table dans ces 
conteneurs.


oui tu as raison, pyrex, cristal sont exclus (j'ai tellement 
l'habitude des pots à moutarde comme verre  pour boire !!!).


Si on lit la version anglaise du wiki, je pense que c'est 
glass_bottle qu'il faut choisir.


je suis assez de cet avis également. Puis-je préciser dans la version 
française que le recycling:glass_bottles=yes inclut les bocaux et donc 
correspond aux PAV (point d'apport volontaire) verre ?





--
Vincent Bergeot


___
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] Ombrage du relief avec Maperitive

[JB]

Bonjour,
Est-ce que tu travailles avec le mnt par défaut, probablement SRTMV3R3 ? 
Même dans ce cas, je n'obtiens pas de problème particulier, notamment de 
pixellisation, sauf que la précision est moins fine qu'à 1°. Si tu as 
vraiment un problème, peux-tu montrer ce que ça donne ?
Sinon, tu peux aussi bidouiller Maperitive pour produire avec le SRTM1, 
vois le message là : 
https://lists.openstreetmap.org/pipermail/talk-fr/2015-June/076845.html

Voilà voilà,
JB.

Le 18/07/2016 à 15:54, Léo Serre a écrit :

Salut,

JB a fait ce que tu essayes de faire, des infos, tutos et autre ici : 
http://wiki.openstreetmap.org/wiki/R25_Maperitive_style

Pour ma part j'avais suivi son tuto à la lettre et c'était parfait.

Léo

Le 18/07/2016 à 14:52, Samy Mezani a écrit :

Bonjour,

Je cherche à faire une carte pour un syndicat d'initiative d'une 
petite commune de Saône-et-Loire à partir des données OSM qu'on a 
ajouté. L'objectif est de tracer un sentier de découverte géologique 
sur un fond Mapnik avec l'ombrage du relief.


Un aperçu du parcours : https://www.openstreetmap.org/relation/6283049

Je souhaite utiliser Maperitive pour exporter un fichier qui pourra 
être modifié par leurs soins.


Dans Maperitive, je n'arrive pas à avoir une résolution suffisante 
pour l'ombrage du relief avec une commande du style 
generate-relief-igor. Je travaille à une échelle de l'ordre du 1/25000e.


Est-ce quelqu'un aurait une solution pour avoir un rendu moins 
pixellisé ?


Merci

Samy

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


--
LSTRONIC logo

Léo SERRE

mail l...@lstronic.com <mailto:l...@lstronic.com>
website lstronic.com <http://lstronic.com>



___
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] Tag 'network' et 'name' pour une relation de type route départementale

[JB]

Le 10/07/2016 à 19:23, François Lacombe a écrit :


Oui, c'est pour ça que j'ai donné l'exemple... les relations se
cassent très facilement et si on ne jardine pas en permanence se
baser uniquement dessus n'est malheureusement pas fiable.


Il y a pourtant tous les contours de communes qui sont décris comme ça.
Personne ne serait d'accord pour indiquer le nom de chaque commune sur 
les tronçons de limite pour utiliser une requête overpass de la même 
manière.


TLDR : mauvaise foi ou aveuglement ? De moi, ou des autres ?

Salut François, et la liste,
Autant, je suis régulièrement d'accord avec toi sur les modèles pour les 
lignes électriques, autant, je trouve que tu accumules la mauvaise foi 
sur ce sujet, en essayant de coller ton schéma électrique sur les routes 
pour automobiles.
Pour le vraiment mauvaise foi : comparer un multipolygone administratif 
et une route (pour automobiles). Franchement, entre un objet qu'il 
serait encore plus tordu de modéliser autrement que par un MP et que les 
débutant n'iront pas trop trifouiller ; et une route, objet concret, 
visible, compréhensible matériellement, tu veux vraiment y coller la 
même méthodologie ? (Je propose de ne pas revenir ici sur la comparaison 
route avec un ref=D* et les itinéraires d'autobus, que je trouve du même 
acabit).
La logique relationnelle que tu appliques aux lignes électriques me 
semble compréhensible pour plusieurs raisons : réseau cohérent, à grande 
échelle, facilement modélisable intellectuellement, peu touché par des 
débutants ou avec peu de risques de dégâts (ajouts de pylônes, affinage 
de la géométrie). Pour la voirie, ça reste un sujet qui devrait être 
abordable pour tous dès la première approche d'OSM. Est-ce qu'on veut 
vraiment déplacer le tag highway dans une relation ? J'espère que non, 
et pour moi, les autres tags non plus.
Et pour l'analyse de la discussion, puisque pas grand monde n'ose mettre 
les pieds dans le plat, je m'y colle : je propose un modèle, tout le 
monde (sauf si j'ai raté quelqu'un) dit que name=Route Départementale 
n'est pas valable, et je le conserve dans la synthèse finale, c'est de 
l'aveuglement aussi ?
Aller, c'était bien trop long pour ce soir, je vais dormir dessus et ne 
pas reparler des autres sujets abordés qui m'ont aussi fait sauter au 
plafond.
Oui, KISS ou vous finirez par ne plus pouvoir recruter de contributeurs 
dans le projet,

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[JB]

Le 06/07/2016 à 11:45, François Lacombe a écrit :
Par contre sur la redondance ref sur le chemin et sur la relation, je 
croyais que c'était nécessaire pour le rendu ? (i.e mapnik ne sait pas 
aller chercher dans la relation pour dessiner le chemin et ne sait pas 
rendre des relations sur la base de la géométrie de ses membres).
Apparemment pas tant que ça : 
http://www.openstreetmap.org/user/SomeoneElse/diary/38988

Par contre, gérer la double entrée sur les ways et relation, peut-être plus.
JB.

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

Re: [OSM-talk-fr] Tag 'network' et 'name' pour une relation de type route départementale

[JB]

Bonjour,
Personnellement, je ne suis pas convaincu par le name=*. Pour moi, le 
ref suffit largement, ce que tu mets dans name est juste une description 
de ce ref.
Pour ma part, je ne suis pas fan des relations non plus. Si elles sont 
élégantes sur le plan de la modélisation, elles sont peu accessibles aux 
nouveaux mappeurs. Attendez-vous à avoir des doublons ref sur la 
relation + ref sur certains tronçons.

JB.

Le 06/07/2016 à 00:28, LeTopographeFou a écrit :

Bonjour,

J'ai attaqué un imposant chantier visant à améliorer la prise en 
compte des Routes Départementales (RD) françaises dans OSM. Ce 
chantier vise à :


 1. Faire qu'il y ait une relation par RD par département (ex :
http://www.openstreetmap.org/relation/6335278)
 2. Vérifier et corrigé le tracé des RD

Le tout étant fait _à la main_ (j'insiste sur le fait qu'il n'y a pas 
d'automate) en comparant les données OSM avec Route500. A ce jour j'ai 
fais les Yvelines et attaque l'Essonne. Aucune des RD n'avait de 
relation ad-hoc et certaines n'étaient carrément pas (ou 
incomplètement) référencées par leurs champ ref=*. Donc je les attaque 
une à une avec de belles trouvailles.


Pour le moment je mets 4 tags à chaque relations (cf. 
http://www.openstreetmap.org/relation/6335278) mais je ne trouve pas 
cela très optimal d'où deux points à vous soumettre :


 1. Il faudrait en profiter pour mettre un tag 'network'. Pour info
les RN ont visiblement un tag 'network=FR:n-road'. Afin de coller
avec la logique utilisées aux EU j'ai deux propositions à faire :
 1. Utiliser le code pays et le code INSEE du département (en
l’occurrence cela ferait 'FR:78')
 2. Faire comme précédemment mais avec également le code INSEE du
département (en l’occurrence cela ferait 'FR:11:78)
 3. Utiliser le code ISO 3166-2 (en l’occurrence cela ferait 'FR-78')
 2. Concernant le tag 'name' il y a des risques d'amalgames entre deux
départements. Est-il judicieux d'y mentionner le nom du
département ? Le hic est que, rigoureusement parlant, le nom
"officiel" est 'Route départementale 29' sans autre fioriture
 1. Exemple 1 : 'Route départementale 29 (Yvelines)' => clair et
concis, facile à parser
 2. Exemple 2 : 'Route départementale des Yvelines 29' => bof
 3. Autre solution : ne rien faire, se dire que l'ajout de
'network' suffit et que si amalgame il y a c'est un problème à
gérer par l'éditeur/l'app et non par le cartographe => c'est
ma solution préféré mais autant réfléchir avant d'aller plus loin.

A ce jour je ne vois pas de réponse ni dans les relations existantes 
ni sur le wiki. Qu'en pensez-vous ?


LeTopographeFou



___
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] OpenStreetMap en famille : un jeu de société

[JB]

Salut Nicolas,
C'est prévu mais comme le seul jeu disponible est chez moi, il suffit 
d'aller voir la porte du salon pour retrouver la cathédrale qui 
correspond ! Oui, il faut que je ressorte la planche avec juste les 35 
plus grandes cathédrales… sur la liste à faire, quand j'aurai fini un 
memory d'un autre type… mais bon je veux pas vous lasser avec ce jeu.

JB.

Le 05/07/2016 à 17:39, Nicolas Moyroud a écrit :

Salut JB,

Je me joins au concert de louanges (un peu à retardement mais bon...) 
à propos de cette superbe réalisation.
Pour une v2 un truc qui serait super à ajouter c'est une planche 
reprenant toutes les formes avec le nom de chaque cathédrale en 
dessous + le nom de la commune et du département. Ça ajouterai un 
petit plus concernant l'aspect culturel de la chose.


a+
Nicolas

Le 05/07/2016 17:21, JB a écrit :

Le 23/06/2016 à 00:44, Christian Quest a écrit :
ça mérite une bonne place sur le wiki.osm.org <http://wiki.osm.org>, 
non ?
Ça n'aura pas pris longtemps, c'est l'image de la semaine : 
http://wiki.openstreetmap.org/wiki/Main_Page
Je l'ai aussi vu passer sur le weeklyosm, là, je n'y suis pour rien ! 
http://weeklyosm.com/ section Community

JB.




___
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] OpenStreetMap en famille : un jeu de société

[JB]

Le 23/06/2016 à 00:44, Christian Quest a écrit :

ça mérite une bonne place sur le wiki.osm.org <http://wiki.osm.org>, non ?
Ça n'aura pas pris longtemps, c'est l'image de la semaine : 
http://wiki.openstreetmap.org/wiki/Main_Page
Je l'ai aussi vu passer sur le weeklyosm, là, je n'y suis pour rien ! 
http://weeklyosm.com/ section Community

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

[OSM-talk-fr] Forum HS

[JB]

Bonjour,
Le forum a l'air d'être HS ce matin : http://forum.openstreetmap.fr/

General Error
SQL ERROR [ mysqli ]
Can't create UNIX socket (12) [2001]
An sql error occurred while fetching this page. Please contact an 
administrator if this problem persists.


JB

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

Re: [OSM-talk-fr] Bonne méthode pour ajouter un feu rouge? et restrictions

[JB]

Le 04/07/2016 à 20:13, Shohreh a écrit :

Morale de l'histoire : les données peuvent être suffisamment pourries pour
démarrer et nécessiter, pour être corrigées avant d'aller plus loin, des
connaissances bien au dessus du débutant de bonne volonté qui voulait
modestement apporter sa pierre à l'édifice. Pas simple.
Sans vouloir être mauvaise langue, tu choisis quand même le type de 
données le plus complexe (relation), avec l'outil le moins adapté (iD), 
avec très peu de connaissance des modélisation OSM (voir les questions 
initiales sur les feux rouges). Pas simple non plus.

JB.

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

Re: [OSM-talk-fr] path, cycleway et footway

[JB]

Heu… Je ne cherche pas forcément à défendre mon point de vue à tout 
prix, mais la page que tu donnes en référence ne me semble pas trancher 
comme tu l'écris, aussi bien dans la version anglaise que française :

 - en anglais, les deux systèmes de tags sont présentés à égalité :
highway <http://wiki.openstreetmap.org/wiki/Key:highway>=*cycleway* + 
foot <http://wiki.openstreetmap.org/wiki/Key:foot>=designated 
<http://wiki.openstreetmap.org/wiki/Tag:foot%3Ddesignated> + segregated 
<http://wiki.openstreetmap.org/wiki/Key:segregated>=noor highway 
<http://wiki.openstreetmap.org/wiki/Key:highway>=path 
<http://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath> + bicycle 
<http://wiki.openstreetmap.org/wiki/Key:bicycle>=designated 
<http://wiki.openstreetmap.org/wiki/Tag:bicycle%3Ddesignated> + foot 
<http://wiki.openstreetmap.org/wiki/Key:foot>=designated 
<http://wiki.openstreetmap.org/wiki/Tag:foot%3Ddesignated> + segregated 
<http://wiki.openstreetmap.org/wiki/Key:segregated>=no

 - en français, pareil, en inversant les propositions :
highway <http://wiki.openstreetmap.org/wiki/FR:Key:highway>=path 
<http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dpath> bicycle 
<http://wiki.openstreetmap.org/wiki/FR:Key:bicycle>=designated 
<http://wiki.openstreetmap.org/wiki/Tag:bicycle%3Ddesignated> foot 
<http://wiki.openstreetmap.org/wiki/FR:Key:foot>=designated 
<http://wiki.openstreetmap.org/wiki/Tag:foot%3Ddesignated> ou highway 
<http://wiki.openstreetmap.org/wiki/FR:Key:highway>=*cycleway* foot 
<http://wiki.openstreetmap.org/wiki/FR:Key:foot>=designated 
<http://wiki.openstreetmap.org/wiki/Tag:foot%3Ddesignated>

JB, qui ne pensait pas que le wiki le soutiendrait ce soir…

Le 24/06/2016 à 22:15, Romain MEHUT a écrit :
Je trouve encore plus tordu la combinaison highway=cycleway + 
foot=yes. La description du wiki 
http://wiki.openstreetmap.org/wiki/FR:Tag:highway%3Dcycleway est 
pourtant suffisamment claire. Cycleway c'est pour les cyclistes, 
point. Si piétons et cyclistes (ou autres non motorisés) sont 
autorisés, on emploie highway=path...


Le 24 juin 2016 à 14:52, JB <jb...@mailoo.org 
<mailto:jb...@mailoo.org>> a écrit :


Je suis bien d'accord avec toi, cette méthode est acceptée, mais
souvent mise en minorité sur cette liste. Je suis souvent partisan
de tagguer au plus simple, mais d'autres préfèrent au plus général.
JB


Le 24/06/2016 à 10:26, Tony Emery a écrit :

Toute cette discussion pour dire que, au final, une voie verte
est comme une
piste cyclable partagée avec les piétons (ou l'inverse) et
pour lesquels on
peut parfois avoir des cavaliers et parfois des véhicules
motorisés...

Du coup (pourquoi faire simple quand on peut faire compliqué),
mettre
highway=path + bicycle=yes/designated/segregated +
foot=yes/designated/segregated me semble plus tordu qu'un simple
highway=cycleway + foot=yes/designated/segregated.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context:

http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181p5876369.html
Sent from the France mailing list archive at Nabble.com.

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



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




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
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] path, cycleway et footway

[JB]

Je suis bien d'accord avec toi, cette méthode est acceptée, mais souvent 
mise en minorité sur cette liste. Je suis souvent partisan de tagguer au 
plus simple, mais d'autres préfèrent au plus général.

JB

Le 24/06/2016 à 10:26, Tony Emery a écrit :

Toute cette discussion pour dire que, au final, une voie verte est comme une
piste cyclable partagée avec les piétons (ou l'inverse) et pour lesquels on
peut parfois avoir des cavaliers et parfois des véhicules motorisés...

Du coup (pourquoi faire simple quand on peut faire compliqué), mettre
highway=path + bicycle=yes/designated/segregated +
foot=yes/designated/segregated me semble plus tordu qu'un simple
highway=cycleway + foot=yes/designated/segregated.



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/path-cycleway-et-footway-tp5876181p5876369.html
Sent from the France mailing list archive at Nabble.com.

___
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] OpenStreetMap en famille : un jeu de société

[JB]

Bonjour,
@Denis : vil flatteur, merci !
@Christian : oui, peut-être à soumettre à l'image de la semaine. Bonne idée.
@JY : oui, si je m'acharne sur les églises puis les cathédrales, c'est 
parce que leurs formes sont généralement plus intéressantes que les 
mairies, les boulangeries… Je cherchais d'autres idées.

@re-Christian : justement, les stades en sont peut-être une (d'idée).
@Nicolas : oui, j'avais aussi l'idée avec du jeu avec les cartes en rond 
dont j'ai oublié le nom. La plupart des jeux qui fonctionnent sur des 
images proches fonctionneraient.
@re-Nicolas : super, des autres idées ! J'aime beaucoup celle des lacs 
(Qui a ses entrées pour faire financer le jeu des lacs des volcans par 
le PNR ?). Départements, j'avais pensé aux villes. Grands parcs, encore 
une autre idée, peut-être moins automatisable.
Pour ce qui est de la créativité, j'essaye juste de mettre en pratique 
ce que je soutenais au SOTM : amusez-vous avec la donnée. Et tout le 
monde devrait pouvoir trouver un projet à sa portée. La prestation que 
j'ai utilisée est monpuzzlephoto point fr, un peu moins chère que sa 
concurrente, mais que je ne recommanderais pas sans en avoir essayé 
d'autres (quelques petits défauts).

JB.

Le 23/06/2016 à 08:58, Christian Quest a écrit :

Une version "grands stades" serait plus vendeuse en ce moment ;)

Le 23 juin 2016 à 08:14, <osm.sanspourr...@spamgourmet.com 
<mailto:osm.sanspourr...@spamgourmet.com>> a écrit :


+1

Jean-Yvon (athée, apostasié, non je ne propose pas de remplacer
les églises par des mairies ;-))


Le 23/06/2016 à 00:44, Christian Quest - cqu...@openstreetmap.fr
<mailto:cqu...@openstreetmap.fr> a écrit :

C'est une magnifique réutilisation des données OSM !

ça mérite une bonne place sur le wiki.osm.org
<http://wiki.osm.org>, non ?
-- 


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

[OSM-talk-fr] OpenStreetMap en famille : un jeu de société

[JB]

Bonjour,

J'ai continué l'aventure des cathédrales, avec cette fois, un (premier 
?) jeu de société à base d'OSM : le mémory des cathédrales. Il est 
arrivé aujourd'hui dans la boite aux lettres, on s'est empressés de 
l'essayer avec ma compagne. Pas de doute, il est tout à fait jouable : 
72 cartes, soit 35 cathédrales, une carte avec l'échelle et les crédits. 
Une photo est visible ici : http://jb.isonoe.net/demo/Jeu_cathedrales.jpg


Rapidement, la démarche de fabrication : comme une partie mémory à près 
de 200 paires risquerait d'être un peu longue à terminer, il a bien 
fallu trouver un mode de sélection des édifices à conserver. Le plus 
neutre que j'ai trouvé : les plus grandes (en surface). Alors, pour 
trier ça:
(pour les références, voir le mél précédent intitulé « Nouvelle affiche 
disponible : on s'amuse avec les cathédrales ! » du 13/6)
 - calcul des surfaces : importation du fichier .osm des cathédrales 
dans QGIS, compléter la table attributaire avec la surface (auparavant, 
pour les brelles, comprendre pourquoi cette table attributaire ne veut 
pas passer en mode édition),
 - exporter la partie intéressante de la table attributaire : 
l'identifiant des objets et leur surface,
 - ajouter l'information de surface aux éléments du fichier .osm 
(mini-script python qui cherche l'id de l'élément dans la table),
 - ressortir un fichier avec les cathédrales « au carré » mais triées 
cette fois par surface décroissante (modification à la marge du script 
de l'affiche),

 - exporter un petit png centré sur chaque cathédrale.
Sur les conseils design de ma compagne, le gris morose des bâtiments de 
la feuille de style est passé à un vague sépia, la boite du jeu est 
conseillée en bleu.
On envoie tout ça à un fabricant de jeux à la demande, et hop, dans la 
boite aux lettres (en passant par la case carte bleue).


Alors, après réception, il y aurait quelques ajustements à faire (le 
calage chez le fabricant n'est pas parfait, du coup, le dessin frôle les 
bordures dans certains cas… et cette fichue cathédrale de Marseille qui 
se prend des envies de longueurs !), voir à ajouter un fond de couleur à 
la place du blanc, et puis trouver un fabricant qui propose un dos de 
cartes un peu plus élégant… Pour une version zéro, c'est pas vilain.


Voilà voilà, bonne soirée,

JB.

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

Re: [OSM-talk-fr] Nouvelle affiche disponible : on s'amuse avec les cathédrales !

[JB]

Salut Nicolas, et les autres.
Quelques réponses ci-dessous :

Le 14/06/2016 à 10:08, Nicolas Moyroud a écrit :
Si je peux me permettre une remarque je trouve que dans le résultat 
final c'est dommage de mettre un carré rouge et aussi de faire 
apparaître le label sur la cathédrale. 
Et oui, on ne se refait pas… J'avais essayé sans le carré rouge… et puis 
j'ai pas aimé. Un autre avantage est que le texte est placé par rapport 
au centre du bâtiment. Ce n'est pas forcément évident de trouver un 
autre emplacement qui rende bien pour tous les bâtiments. À 
l'impression, le rouge ne me choque pas. Comme le texte est petit, il 
faut déjà s'approcher de l'affiche pour le voir.
Dans la feuille de style utilisée avec Maperitive il me semble qu'il 
serait relativement facile de faire disparaître le carré et de 
positionner le label en dessous de chaque objet. Peut-être même 
qu'avec un autre couleur mieux choisie que ce rouge un peu pétard ce 
serait encore mieux.

Si tu bricoles une image en exemple, je veux bien coder le style.
Dans l'idée d'automatiser quasi intégralement le processus peux tu me 
dire quelles sont les manips finales que tu réalises avec Gimp ? Je 
pense notamment à l'utilisation d'magemagick qui permet également de 
faire des retouches d'images mais en ligne de commande.

Pas grand chose : ajouter le titre, l'attribution, déplacer l'échelle.


Nicolas

Le 13/06/2016 19:33, JB a écrit :

Bonjour,

Après l'essai de faisabilité vite fait avec les églises d'Auvergne 
pour le SotM-FR pour ceux qui y étaient, j'ai essayé de faire quelque 
chose de plus complet : l'affiche des cathédrales de France. Le final 
ici : http://jb.isonoe.net/demo/Cathedrales_A1_400dpi_v0.png, fait 
pour être imprimé en A1 à 400dpi.


La démarche :

 - trouver une source de données qui liste les cathédrales. J'ai 
utilisé wikipédia, qui n'est peut-être pas forcément parfait (voir 
plus loin) :

https://fr.wikipedia.org/wiki/Liste_des_cath%C3%A9drales_de_France
https://fr.wikipedia.org/wiki/Liste_des_cath%C3%A9drales_catholiques_de_France 

https://upload.wikimedia.org/wikipedia/commons/b/b7/Cath%C3%A9drales_catholiques_romaines_de_France.png 



 - vérifier les données dans OSM :

- première extraction des building=cathedral. Quelques petits 
villages se sont attribués des cathédrales, je les repasse en 
building=church


- plus embêtant, trouver les batiments non indiqués en 
cathédrales : il faut se payer la comparaison entre la liste des 
existants dans OSM et la liste globale. Dans la plupart des cas, ça 
se fait relativement bien. Parfois c'est un peu plus tordu, rarement, 
aucune information ne recoupe les indications de wikipédia. Dans ces 
quelques cas, je n'ai touché à rien. La liste des éléments : 
http://jb.isonoe.net/cath/cath.csv (parmi les plus litigieux : Mâcon 
et celles marquées comme telles dans la dernière colonne). Je 
n'affirme pas avoir été parfait ni que ma source de données l'était : 
je pense avoir amélioré la qualité globale de la base de données mais 
si vous n'êtes pas d'accord avec le résultat, n'hésitez pas à modifier.


 - ré-extraire les données : Geofabrik est là pour la France d'ici 
avec un coup d'Osmosis derrière, Overpass pour les dom-tom. On 
rassemble les deux, on élimine la cathédrale de Monaco (et on gère 
l’éphémère doublon de Rodez).


La suite se fait par un petit script python/Maperipy exécuté sous 
Maperitive.


 - géocoder : l'api d'adresse.data.gouv.fr fait le gros du travail. 
Dans quelques territoires éloignés où la ban avoue son échec, le 
géocodage est fait à la main.


 - déplacer les éléments et les placer « au carré » : toujours 
python/Maperipy. Une première version assez crado ne reprojetait pas 
les objets, d'où des déformations assez importantes, surtout pour les 
éléments des dom-tom mais aussi certains en métropole : 
http://jb.isonoe.net/cath/Reproj.png. Le script est modifié pour 
respecter distances/formes (si je m'y suis bien pris).


 - exporter l'image, mettre en forme sous Gimp.

Le code, pas fait pour être partagé et qui ne fonctionnera 
probablement pas (très moche, non retravaillé, à peine commenté), est 
visible ici : http://jb.isonoe.net/cath/Eglises_rel1.py


Quelques autres documents intermédiaires :

 - Cathédrales utilisées, avec géocodage : 
http://jb.isonoe.net/cath/cath_brut_geocode_manuel.osm


 - Cathédrales au carré :
- non reprojetées : 
http://jb.isonoe.net/cath/Egl_offset_direct_ok.osm

- reprojetées : http://jb.isonoe.net/cath/Egl_offset_reproj_ok.osm

Ma version personnelle : http://jb.isonoe.net/cath/Photo_affiche.jpg

JB.


PS : pour le teasing, j'ai une autre idée plus matérielle… ça arrive 
dans quelques semaines !


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

[OSM-talk-fr] Nouvelle affiche disponible : on s'amuse avec les cathédrales !

[JB]

Bonjour,

Après l'essai de faisabilité vite fait avec les églises d'Auvergne pour 
le SotM-FR pour ceux qui y étaient, j'ai essayé de faire quelque chose 
de plus complet : l'affiche des cathédrales de France. Le final ici : 
http://jb.isonoe.net/demo/Cathedrales_A1_400dpi_v0.png, fait pour être 
imprimé en A1 à 400dpi.


La démarche :

 - trouver une source de données qui liste les cathédrales. J'ai 
utilisé wikipédia, qui n'est peut-être pas forcément parfait (voir plus 
loin) :

https://fr.wikipedia.org/wiki/Liste_des_cath%C3%A9drales_de_France
https://fr.wikipedia.org/wiki/Liste_des_cath%C3%A9drales_catholiques_de_France
https://upload.wikimedia.org/wikipedia/commons/b/b7/Cath%C3%A9drales_catholiques_romaines_de_France.png

 - vérifier les données dans OSM :

- première extraction des building=cathedral. Quelques petits 
villages se sont attribués des cathédrales, je les repasse en 
building=church


- plus embêtant, trouver les batiments non indiqués en cathédrales 
: il faut se payer la comparaison entre la liste des existants dans OSM 
et la liste globale. Dans la plupart des cas, ça se fait relativement 
bien. Parfois c'est un peu plus tordu, rarement, aucune information ne 
recoupe les indications de wikipédia. Dans ces quelques cas, je n'ai 
touché à rien. La liste des éléments : 
http://jb.isonoe.net/cath/cath.csv (parmi les plus litigieux : Mâcon et 
celles marquées comme telles dans la dernière colonne). Je n'affirme pas 
avoir été parfait ni que ma source de données l'était : je pense avoir 
amélioré la qualité globale de la base de données mais si vous n'êtes 
pas d'accord avec le résultat, n'hésitez pas à modifier.


 - ré-extraire les données : Geofabrik est là pour la France d'ici avec 
un coup d'Osmosis derrière, Overpass pour les dom-tom. On rassemble les 
deux, on élimine la cathédrale de Monaco (et on gère l’éphémère doublon 
de Rodez).


La suite se fait par un petit script python/Maperipy exécuté sous 
Maperitive.


 - géocoder : l'api d'adresse.data.gouv.fr fait le gros du travail. 
Dans quelques territoires éloignés où la ban avoue son échec, le 
géocodage est fait à la main.


 - déplacer les éléments et les placer « au carré » : toujours 
python/Maperipy. Une première version assez crado ne reprojetait pas les 
objets, d'où des déformations assez importantes, surtout pour les 
éléments des dom-tom mais aussi certains en métropole : 
http://jb.isonoe.net/cath/Reproj.png. Le script est modifié pour 
respecter distances/formes (si je m'y suis bien pris).


 - exporter l'image, mettre en forme sous Gimp.

Le code, pas fait pour être partagé et qui ne fonctionnera probablement 
pas (très moche, non retravaillé, à peine commenté), est visible ici : 
http://jb.isonoe.net/cath/Eglises_rel1.py


Quelques autres documents intermédiaires :

 - Cathédrales utilisées, avec géocodage : 
http://jb.isonoe.net/cath/cath_brut_geocode_manuel.osm


 - Cathédrales au carré :
- non reprojetées : http://jb.isonoe.net/cath/Egl_offset_direct_ok.osm
- reprojetées : http://jb.isonoe.net/cath/Egl_offset_reproj_ok.osm

Ma version personnelle : http://jb.isonoe.net/cath/Photo_affiche.jpg

JB.


PS : pour le teasing, j'ai une autre idée plus matérielle… ça arrive 
dans quelques semaines !



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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[JB]

Et le triplon était sur l'hôtel (tourism=hotel).

JB.


Le 11/06/2016 à 21:45, Romain MEHUT a écrit :

Le doublon était sur l'adresse qui existait déjà...

Romain

Le 11 juin 2016 à 17:59, Philippe Verdy <verd...@wanadoo.fr 
<mailto:verd...@wanadoo.fr>> a écrit :


Là ce n'est pas méchant il n'y a pas d'erreur c'est juste que la
mention de la ville et du code postal peut éventuellement être
déduite.
Attention de ne pas être trop exigeant sur les champs d'adresse,
d'autant que nombre de communes ont fusionné mais les adresses
sont parfois ambigues et qu'il est difficile de se repérer sur le
nom de la nouvelle commune; l'acnienne commune conservant en fait
son nom local la plupart du temps, il n'y a pas d'impact sur les
adresses.




___
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] Bonnes et moins bonnes visibilités OSM

[JB]

J'en ai profité pour regarder ses dernières modifications, il n'a pas 
l'air d'avoir amélioré ses pratiques : création d'un triplon (au dessus 
d'un doublon…). À sa décharge, le doublon existait déjà, mais ça reste 
du travail crado :


https://www.openstreetmap.org/way/205475033

https://www.openstreetmap.org/way/144247997

https://www.openstreetmap.org/node/4235391319

https://www.openstreetmap.org/changeset/39928749

Finir par demander un blocage ou un revert en règle ?

JB.


Le 10/06/2016 à 23:58, Pierre Béland a écrit :

voir discussion changeset https://www.openstreetmap.org/changeset/39924306

Pierre


___
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] [OverpassTurbo] Obtenir une seule route à partir de ways?

[JB]

Le 07/06/2016 à 17:23, Shohreh a écrit :

Merci. Dommage qu'il n'y ait pas une commande dans OverpassTurbo pour
directement fusionner les ways avant de télécharger le fichier.
Pas vraiment. Ce n'est juste pas son boulot. Overpass permet de filtrer 
et charger des données OSM, pas de les post-traiter. Si les tronçons 
sont dans le « bon » ordre dans OSM, ils sortiront de même.

JB.

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

[OSM-talk-fr] Bano et territoires lointains

[JB]

Bonsoir,

Après m'y être pris comme une patate pour gérer le json fourni par l'api 
de la Ban, j'ai une autre question que j'espère plus productive…


Dans certains territoires lointains, l'api de reverse-géocodage renvoie 
un json vide, par exemple : 
http://api-adresse.data.gouv.fr/reverse/?lon=-56.17204=46.78129 qui 
devrait tomber du côté de Saint-Pierre (sans Miquelon). Est-ce voulu, ou 
pourrait-elle renvoyer au moins une ville, éventuellement un code postal 
même s'il n'y a pas forcément de rue ou de numéro ? Ou c'est moi qui m'y 
prend mal encore une fois ?


Sinon, d'autres zones fonctionnent bien 
(http://api-adresse.data.gouv.fr/reverse/?lon=55.44879=-20.88019 du 
coté de Saint-Denis)


JB.


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

[OSM-talk-fr] Api adresse - reverse

[JB]

Bonjour,

Je n'ai pas vu passer cette question : Est-ce que c'est moi qui me 
débrouille mal, ou bien l'api de la Ban en reverse ne gère pas les 
caractères spéciaux ?


Par exemple, pour la requête : 
http://api-adresse.data.gouv.fr/reverse/?lon=2.4441661=48.7897578, 
j'ai la réponse :


{"limit": 1, "attribution": "BAN", "version": "draft", "licence": "ODbL 1.0", "type": "FeatureCollection", "features": [{"geometry": {"type": "Point", "coordinates": [2.444308, 48.790001]}, "properties": {"street": "Rue Andr\u00e9 Maurois", "label": "2 Rue Andr\u00e9 Maurois 94000 
Cr\u00e9teil", "distance": 28, "context": "94, Val-de-Marne, \u00cele-de-France", "id": "94028_0068_2f0620", "citycode": "94028", "name": "2 Rue Andr\u00e9 Maurois", "score": 0.996646758574, "postcode": "94000", "housenumber": "2", "city": "Cr\u00e9teil", "type": "housenumber"}, 
"type": "Feature"}]}

avec les morceaux choisis : 2 Rue Andr\u00e9 Maurois 94000 Cr\u00e9teil.

JB.


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

Re: [OSM-talk-fr] Je ne comprends pas ces points ?

[JB]

Le 14/05/2016 à 16:01, Jérôme Amagat a écrit :
si la position est bonne c'est déjà bien après je vous laisse faire 
pour les tag
Mouaif. C'est quand même ce genre d'objet qui m'énerve quand je 
contribue sur une zone. Personnellement, je préfère rien qu'un truc mal 
fichu : comme j'aime bien les choses propres, je vais passer pas mal de 
temps à essayer de faire mieux et avoir l'impression de perdre mon 
temps. D'autres préfèrent avoir plein d'éléments… mais avec une valeur 
ajoutée faible (voire nulle) : sans tag principal, pas ou peu 
d'utilisation par d'autres outils, et des outils très pointus auraient 
su les chercher dans la BDD spécialisée d'où ils ont été intégrés.

JB.

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

Re: [OSM-talk-fr] Je ne comprends pas ces points ?

[JB]

Ce qui n'empêche quand même pas de trouver un tag principal à l'objet. 
Pour moi, ce sont quand même des mauvaises pratiques d'importer un 
élément avec un tag name, un tag réf, et rien d'autre. Le premier, à 
voir si il correspond à l'église à 10m de là, le deuxième aurait pu 
avoir un social_facility en complément.



Le 13/05/2016 à 22:50, Christian Quest a écrit :

On ne peut/doit pas toujours associer des infos à un bâtiment.

Dans le cadre du couvent, il s'agit sûrement d'une zone bien plus 
large qu'un unique polygone de bâtiment.


Pour le 2ème point, le bâtiment sert peut être à autre chose...


Le 13 mai 2016 à 20:48, Vincent Bergeot > a écrit :


re,

Le 13/05/2016 20:41, didier2020 a écrit :

bonsoir,

je n'arrive pas a ouvrir le wiki pour t'indiquer les pages
concernées ...


oui j'ai vu que le wiki est en maintenance ce w-e :
https://blog.openstreetmap.org/2016/05/13/server-maintenance-may-13-15/


- le premier point = monument historique (les tags sont
différens quand
c'est classé ou inscrit)

http://www.culture.gouv.fr/public/mistral/merimee_fr?ACTION=CHERCHER_1=REF_1=PA6343


je comprends mais ce qui me surprend c'est que cela ne soit pas
associé à un bati ?

- le 2eme point = base des établissements sanitaires et sociaux
je trouve compliqué de trouver un tag pour ces établissements
http://finess.sante.gouv.fr/finess/jsp/rechercheSimple.jsp


idem, le "node" pourrait être sur le bati non ?

merci pour ta réponse,











Le vendredi 13 mai 2016 à 20:13 +0200, Vincent Bergeot a écrit :

Bonjour,
un peu par hasard, je suis tombé sur ce premier point qui
m'intrigue :
http://www.openstreetmap.org/node/3886714389#map=19/45.77735/3.09172

le point n'est associé à aucun élément tangible, type
batiment,
l'article dans wikipedia n'existe pas, ...
On dirait que cela vient d'une liste des bâtiments
historiques ?

Du coup sur la base du contributeur, j'ai vu cela en
second et la encore
une fois ce n'est associé à aucun bâtiment, la aussi cela
semble
provenir d'une liste finess ?
http://www.openstreetmap.org/node/4176821295#map=18/48.80928/2.15700

Avant de regarder un peu plus, je pars du principe que
peut-être qu'il y
a quelque chose que je ne comprends pas ?

Quelques lumières ?

Bonne soirée

--
Vincent Bergeot

___
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



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




--
Christian Quest - OpenStreetMap France


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


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

Re: [OSM-talk-fr] Covoiturage pour Clermont-Ferrand (State of the Map)

[JB]

Pour les hésitants entre covoiturage et train, y a-t-il des possibilités 
de stationnement facile proches de l'événement ?


JB.


Le 04/05/2016 à 10:03, Vincent de Château-Thierry a écrit :

Bonjour,
en prévision du State of the Map à Clermont-Ferrand dans 2 grandes semaines, 
pour ceux qui cherchent une place ou ont des places à proposer dans un 
véhicule, nous avons mis en place ce tableau : 
https://framacalc.org/Covoiturage%20SOTM-FR-2016

Bonne journée,
vincent

ps. en amuse-bouche : 
http://www.dailymotion.com/video/x474g5w_sotm-fr2016-bande-annonce-state-of-the-map-france-2016-clermont-ferrand_tech
 :)

___
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] Cartes papiers (A3/A2) avec ajout données locales : suites logicielles et conseils

[JB]

Encore quelques réponses en vrac, j'évite ce qui me semble hors-sujet :

 - Vectoriel : Maperitive permet de sortir des fichiers vectoriels. Ce 
que j'essayais de dire, c'est que ce n'est pas forcément une solution 
facile pour le post-traitement des images.


 - Maperitive/Mapnik : l'intérêt de Mapnik n'est pas dans la qualité de 
l'export vectoriel. C'est plus sur la richesse de la chaine de travail, 
notamment avec la puissance de PostGis. Mais avec un peu de scriptage, 
on peut rattraper une partie du retard, voir ce que j'ai sorti 
dernièrement sur l'orientation des barrières, cascades et autres.


 - Maperitive/Mapnik bis : Maperitive permet comme Mapnik de sortir des 
résolutions élevées (jusqu'à une certaine limite de gestion du fichier 
image par .NET, que je n'ai jamais atteinte).


 - Résolution et taille des textes et des icônes : c'est un grand 
hors-sujet : on parle de résolution de sortie, et non d'échelle. À 
grande résolution, un caractère fait 10 pixels à la place de 5, mais 
fait toujours 5mm de hauteur. (Par contre, les icônes que j'utilise et 
que j'ai pour la plupart créées moi-même n'ont pas forcément une 
résolution phénoménale… à voir s'il faut les retravailler.)


 - Post-traitement du SVG, pré-traitement des données ou… gestion 
manuelle des éléments : ma (petite) expérience, c'est que sur une zone 
définie, pour un résultat très propre, tout ne pourra pas être géré 
automatiquement pour la position de textes, icône, ou autres. La 
solution de post-traitement de l'image est possible, mais je pense 
qu'une gestion intermédiaire d'adaptation de la feuille de style « à la 
main » est une bonne solution. On gagne la propreté, on perd 
l'automatisation.


Après, il faut entrer dans le concret pour en dire plus.

JB.


Le 01/05/2016 à 16:06, Christian Quest a écrit :
Il est possible de positionner ce qu'on veut là où l'on veut... tout 
dépend du pré-processing qu'on fait sur les données.


Par défaut le placement est relativement basique, le moteur de rendu 
n'a pas connaissance que le polygone gris est en fait un bâtiment et 
qu'on voudrait que le texte aille par là un peu plus tard quand on 
arrivera à cette couche du rendu.


On peut faire des trucs dingues en pré-processant, mais c'est pas 
"plug and play".



Le 1 mai 2016 à 15:12, Valentin Surrel <openstreet...@surrel.org 
<mailto:openstreet...@surrel.org>> a écrit :


Inkscape c'était plus pour le post-processing (éventuellement
déplacer 2-3 éléments de carto et ajouter les données propres à
l'office du tourisme). Il y a peut-être des logiciels plus adaptés
mais je ne connais pas trop cette partie.

J'essayerai éventuellement Mapnik en high-res mais en fait y'a pas
de stylesheet qui correspondent à mon besoin vu que Opencyclemap &
cie ont tout gardé fermé...

Par ailleurs j'ai une question, j'ai pas encore creusé mais
peut-être sais tu d'ores et déjà la réponse : est-il possible avec
Maperitive de positionner les nom de manière plus intelligente ?
(ie. pas juste au dessus du point, mais par exemple en bordure de
90% du bâti)


    Le 2016-05-01 12:51, JB a écrit :

- Point vectoriel : les retours que j'ai de mapnik indiquent des
fichiers très difficilement utilisables. Maperitive semble
faire un
peu mieux. De mon coté, le petit imprimeur avec qui j'avais
bossé une
petite fois me disait qu'au-dessus de 300-400dpi (natif au
format), il
n'avait pas forcément d'intérêt à passer au vectoriel (par
contre, il
a des clients qui récupèrent une image sur internet et la
modifient
pour arriver à 300dpi… et arrivent avec un fichier qui fait 3 ou 4
centimètres de coté). Du coup, je t'encourage de regarder ce
que ça
peut donner sous Inkscape, je suis intéressé par tes retours.
(Et au
fait, quels travail vas-tu faire sous Inkscape ?)

- Malgré la libération de .NET par Microsoft, les bibliothèques
graphiques n'avaient pas encore été intégrées par Mono. Je ne
sais pas
si ça a évolué, mais les exports sous Linux étaient d'assez
mauvaise
qualité sur les rendus de couleurs et de transparences (voir
notamment
les éléments rouges touristiques).

- Quelqu'un avait abordé l'idée de passer R25 en CSS, je lui
avais dit
que j'étais curieux du boulot que ça donnerait mais le projet
semble
avoir été abandonné depuis longtemps. R25, c'est actuellement
plus de
5000 lignes, sous une syntaxe très différente du CSS… donc du
boulot,
du boulot. L'idée avait été évoquée de monter un petit serveur
pour
produire des cartes à la demande, mais comme je n'ai pas les
compétences et qu'on n'avait pas monté d'équipe, c'est resté
au stade
de l'idée. (Et de mon coté, je ne coderai pas le 

Re: [OSM-talk-fr] Cartes papiers (A3/A2) avec ajout données locales : suites logicielles et conseils

[JB]

- Point vectoriel : les retours que j'ai de mapnik indiquent des 
fichiers très difficilement utilisables. Maperitive semble faire un peu 
mieux. De mon coté, le petit imprimeur avec qui j'avais bossé une petite 
fois me disait qu'au-dessus de 300-400dpi (natif au format), il n'avait 
pas forcément d'intérêt à passer au vectoriel (par contre, il a des 
clients qui récupèrent une image sur internet et la modifient pour 
arriver à 300dpi… et arrivent avec un fichier qui fait 3 ou 4 
centimètres de coté). Du coup, je t'encourage de regarder ce que ça peut 
donner sous Inkscape, je suis intéressé par tes retours. (Et au fait, 
quels travail vas-tu faire sous Inkscape ?)


- Malgré la libération de .NET par Microsoft, les bibliothèques 
graphiques n'avaient pas encore été intégrées par Mono. Je ne sais pas 
si ça a évolué, mais les exports sous Linux étaient d'assez mauvaise 
qualité sur les rendus de couleurs et de transparences (voir notamment 
les éléments rouges touristiques).


- Quelqu'un avait abordé l'idée de passer R25 en CSS, je lui avais dit 
que j'étais curieux du boulot que ça donnerait mais le projet semble 
avoir été abandonné depuis longtemps. R25, c'est actuellement plus de 
5000 lignes, sous une syntaxe très différente du CSS… donc du boulot, du 
boulot. L'idée avait été évoquée de monter un petit serveur pour 
produire des cartes à la demande, mais comme je n'ai pas les compétences 
et qu'on n'avait pas monté d'équipe, c'est resté au stade de l'idée. (Et 
de mon coté, je ne coderai pas le style en carto-CSS pour diverses raisons).


JB.

Le 01/05/2016 à 09:49, Valentin Surrel a écrit :

Bonjour,

Mes réponses suite à vos 2 mails et avoir joué une petite heure avec 
Maperitive/R25.


- je tiens au rendu vectoriel, on va travailler avec un imprimeur et 
par expérience (certe minuscule mais expérience quand même) ils 
préfèrent largement le vectoriel pour un bon rendu, surtout en A2.


- J'ai réussi un "export-svg" avec Maperitive, çela semble donc bon. 
Pourquoi JB tu ne parles que de l'export haute résolution ? Je n'ai 
pas encore joué avec ce SVG sous Inkscape toutefois.


- Pourquoi c'est mieux sous Windows ? C'est connu que le rendu 
Maperitive est meilleur sous Windows ? Car dans l'idée ma chaîne de 
production serait sur des serveurs sous Linux complètement automatisé. 
Et accessoirement je n'ai aucun Windows... Mais bon si ca devient un 
pré-requis je partirai la dessus quand même, vu que le thème R25 
semble correspondre parfaitement à mes besoins.


Et question d'ordre plus général, vu la qualité du thème R25, pourquoi 
personne n'a jamais été intéressé pour le mettre en thème Mapnik ou 
CartoCSS ou autre ?


Bonne journée,

Valentin

Le 2016-05-01 00:24, Philippe Verdy a écrit :

L'export à forte résolution peut marcher, mais il faut que le rendu
utilise des tailles de police adaptées (et pas calculées pour un
affichage à l'écran: la réduction d'échelle une fois imprimé
rendra ce texte illisible).
C'est faisable mais ça demande des tailles de bitmap très élevées,
et il faut connaitre la résolution effective d'impression (qui varie
selon le dispositif). De plus les techniques de jet d'encre ont des
méthodes spécifiques de placement des pixels et de redistribution
des gouttes (qui sont en fait de taille variable pour couvrir plus ou
moins les "pixels" théorique au centre des desquels on les
gouttelettes sont projetées. Mais avec une impression d'image en
résolution élevée, l'algo de placement optimal pour le texte ne
marche plus, c'est l'algo "photographique qui est utilisé et on
obtient un texte diffiocilement lisible.
Bref pour imprimer corectement il vaut mieux un rendu vectoriel (à
partir duquel les "masques" de positionnement (et de recouvrement
éventuel) des encres pourront être plus idéalement placés (une
imprimante couleur ne fonctionne pas du tout avec une matrice fixe
comme un écran, surtout en jet d'encre, les "sous-pixels" de l'écran
sont beaucoup plus simples, et surtout ils ont une gamme plus étendue
en colorimétrie alors que les encres sont de couleur fixe et on ne
peut jouer que sur la taille des gouttelettes).
En rendu sur laser c'est plus délicat d'avoir de belles couleurs, les
particules sont de taille à peu près constante (mlais ne peuvent pas
se recouvrir partiellement come avec l'encre. On a donc des matrices
similaires à l'écran, mais les sous-pixels doivent être extrêment
fins pour compenser la gamme plus réduite, et alors se pose le
problème de cette résolution élevée sur des surfaces très grandes
: les tailles de bitmap sont considérablement plus grandes.
Là encore le rendu vectoriel par par le dispositif d'impression sera
bien meilleur (et nettement plus performant).
Je connais peu d'imprimantes qui soient capable d'imprimer
correctement du texte rendu avec des tailles de polices réduites à
partir d'une bitmap sans rendre ce texte souvent illisible
(l'intelligence du pilote d'impression peut cependant compenser 

Re: [OSM-talk-fr] Cartes papiers (A3/A2) avec ajout données locales : suites logicielles et conseils

[JB]

Salut Valentin,

Quelques questions :

 - est-ce qu'un export à forte résolution est envisageable à la place 
d'une sortie vectorielle ? (même s'il la plupart des retours sont que 
les sorties vectorielles sont souvent plus foireuses que ce qu'on 
voudrait croire…)


 - est-ce que l'emploi d'un logiciel gratuit non libre est envisageable 
(en plus, qui tourne mieux sous Windows…) ?


 - est-ce qu'il faut une solution prête à l'emploi, ou est-ce qu'un peu 
de bidouille est prévue ?


Selon tes réponses, R25 est éventuellement une solution parmi d'autres. 
Tu peux jeter un coup d'œil là : 
http://jb.isonoe.net/CR/demo/Volcans_2016.pdf, là : 
http://jb.isonoe.net/temp/Chemin_des_Arts.png ou encore là : 
http://jb.isonoe.net/temp/Samoens_ent.png. En Avec légende, par exemple 
ici : 
http://jb.isonoe.net/temp/Base_affiche_osm_paysage_A0_300_Moselle_V2.png. 
(Pas forcément tous à jour, mais ça peut te donner une idée.)


Voilà voilà,

JB.

Le 30/04/2016 à 22:01, Valentin Surrel a écrit :

Bonsoir la liste,

Je reviens sur la liste après plusieurs années d'absence, non pas par 
manque d'intérêt pour le projet mais par faute de temps. Je suis de 
nouveau un peu plus libre professionnellement, je me relance donc un 
peu plus dans le projet OSM... en constatant que beaucoup de choses 
ont évolué depuis !!


J'ai donc pour projet d'aider une communauté de communes de moyenne 
montagne d'éditer des cartes (papier) de sentiers de rando du coin 
pour chacune des communes. A ce jour, seule une feuille A4 recto-verso 
100% textuelle (en Comic Sans MS qui plus est) est à disposition des 
touristes pour les guider sur ces sentiers, à moitié à l'aveugle donc.


Je veux donc leur proposer un .pdf vectoriel à imprimer qui comprend 
un fond de carte OSM avec en overlay les N sentiers de rando, avec sur 
les bords de la carte une légende et un petit topo de chaque rando.


Je me suis fixé les contraintes suivantes :
- fond de carte facilement updatable, et surtout le plus simplement 
possible (ie. un script bash qui télécharge un export, le traite, et 
update le fichier précédent (que celui-ci servent d'input mapnik, de 
layer QGIS ou autre)

- 100% vectoriel (pour une belle impression sur A3 voire A2 plié)
- ajouter un overlay propre à la commune (les N sentiers de chacune 
des communes qu'ont tracé les offices de tourisme). Les sentiers sont 
présents sur OSM ou seront rajoutés, mais les circuits seront tracés 
par dessus en fonction des envies des offices de tourisme.
- rendu "sympa" avec courbes de niveau (style francetopo, 
opencyclemap, mapquest ouverte...)

- échelle proche 1:25000


J'essaye de dresser l'éventail de solutions techniques possibles. 
Celles ci ont bien évoluées ces années, et j'ai peur de louper des 
"nouveautés", j'en ai isolé que 2 crédibles :


- Mapnik avec export SVG, pour inclure ça dans Inkscape pour ajouter 
les overlay spécifique. Surement la solution la plus simple pour 
utiliser un thème existant (encore que j'ai l'impression que 
francetopo, opencyclemap et compagnie ne publient pas leurs themes...)
- QGIS avec l'export OSM (en ESRI) et partir sur un theme existant (ex 
: https://github.com/charleyglynn/OSM-Shapefile-QGIS-stylesheets). Par 
contre j'ai l'impression que le bâti ne fait pas parti des exports 
ESRI geofabrik...


(maposmatik même si c'est un truc que j'adore ne répond pas trop aux 
contraintes)


Je suis dans une démarche ouverte (ie. tout dispo sur github), l'idée 
est de pouvoir avec un minimum de travail pouvoir itérer le projet 
dans d'autres syndicats d'initiative, cela permet d'afficher le projet 
OSM indirectement à un maximum de monde.


Qu'en pensez vous ? Certains ont ils déjà mené des projets similaires 
? avez-vous des idées autres (logiciel/thèmes/...) que je puisse 
creuser ? avez-vous des bonnes adresses de thèmes ouverts ?


Merci à tous !

Valentin

___
Talk-fr mailing list
Talk-fr@openstreetmap.org
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] R25, Maperitive et orientation d'objets

[JB]

Pour le sondage autour de chez moi (zone rurale, peut-être moins de 
contraintes liées à des cartes trop chargées) :

 - orientés correctement : 9 églises
 - orienté à 180° : 1 église
 - orienté autrement : aucun.
Sans forcément chercher à pinailler, à Séverac-l'Église, le symbole 
n'est pas que mal orienté, il est aussi mal placé (mauvais angle du 
triangle des rues)

JB.

Le 25/04/2016 00:35, Philippe Verdy a écrit :

Regarde aussi à Rodez...

Le 25 avril 2016 à 00:33, Philippe Verdy <verd...@wanadoo.fr 
<mailto:verd...@wanadoo.fr>> a écrit :


Si tu veux un exemple, regarde les cartes IGN pour
Séverac-l'Eglise et vois comment le symbole change d'orientation
sans *jamais* afficher l'orientation réelle de l'édifice...


Le 25 avril 2016 à 00:03, Philippe Verdy <verd...@wanadoo.fr
<mailto:verd...@wanadoo.fr>> a écrit :

En plus j'ai vérifié, l'IGN n'oriente pas ses symboles sur ses
cartes. Si parfois le symbole est "penché" c'est juste pour le
dessiner en évitant de le superposer à autre chose, mais pas
en tenant compte de l'orientation réelle de l'édifice.

A grande d'échelle, le symbole (légèrement différent selon
qu'il s'agit d'une église ou cathédrale, d'une petite chapelle
ou juste d'un calvaire ouvert sur l'extérieur sans nef) n'est
jamais orienté (la croix est toujours verticale, ou pas
affiché du tout pour les plus petits édifices s'il y a autre
chose plus remarquable à afficher). A petite échelle, il n'y a
aucun symbole sur le bâtiment, c'est le bâtiment qui est
représenté dans sa forme réelle, la croix disparait, il reste
juste un petit cercle signalant son entrée principale, et le
nom de l'édifice (ou l'abréviation "Egl.") peut être affiché
sans symbole.

C'est à échelle moyenne qu'on peut voir des ajustements
manuels de l'orientation pour éviter de recouvrir un autre
symbole proche pour éviter de couper un libellé; il n'y a
aucune règle prédéterminée selon les endroits un ajustement
est fait... ou pas (selon l'importance relative des autrers
éléments voisins à représenter, ce n'est pas toujours ce
symbole qui est ajusté mais les libellés autour qui peuvent
être décalés).


Le 24 avril 2016 à 23:40, Philippe Verdy <verd...@wanadoo.fr
<mailto:verd...@wanadoo.fr>> a écrit :

H. Je n'ai pas dit ça (et surtout pas dans ces termles
insultants). Mais je voudrais un exemple clair.

Le 24 avril 2016 à 17:34, JB <jb...@mailoo.org
<mailto:jb...@mailoo.org>> a écrit :

Bien, Philippe, tu penseras donc à faire suivre ce mél
à l'IGN pour leur expliquer qu'il bossent comme des
porcs depuis quelques dizaines d'années, et qu'ils
s'entêtent dans cette voie-là.
JB.


Le 24/04/2016 13:15, Philippe Verdy a écrit :


Le 22/04/2016 22:08, Frédéric Rodrigo a écrit :

Pour les églises c'est d'autant plus
"intéressant" que le symbole est orienté et
la forme non triviale !

Je crois que le défi est lancé. Par contre, ça
risque d'attendre un peu, ma liste de choses à
faire avant est un peu longue.


Je ne vois pas en quoi le symbole d'une église ou
temple (la croix) ou d'une synagogue (classiquement
une étoile de David) ou d'une mosquée (classiquement
un croissant) est orienté : il n'y a qu'une
orientation valable dans chaque cas (celle de
représetnation de la carte), c'est un symbole qui
apparaitre ancré sur le batiment, même s'il n'est
représenté que par un noeud ou par un polygone
complexe. Faire tourner cette croix ou le croissant
aura un sens un peu particulier et pourrait même être
perçu négativement (imaginez l'effet de voir une
croix renversée).
Dans tous les cas on se place dans l'orientation
d'observation de la carte (et de lecture de sa
légende éventuelle).
Ce n'est pas comme les terrains de sport ou les
barrières et barrages qu'on a intéret à rienter dans
le bon sens dans ils ne sont représentés que par un
noeud (le symbole étant figuratif de la réalité). Je
ne vois même pas en quoi cela améliore la lisibilité
de la carte et la reconnaissance du symbole. Si cela
dépend de l'orientation du batiment, c'est le
batiment lui-même qu'il faut représenter 

Re: [OSM-talk-fr] R25, Maperitive et orientation d'objets

[JB]

Bien, Philippe, tu penseras donc à faire suivre ce mél à l'IGN pour leur 
expliquer qu'il bossent comme des porcs depuis quelques dizaines 
d'années, et qu'ils s'entêtent dans cette voie-là.

JB.

Le 24/04/2016 13:15, Philippe Verdy a écrit :


Le 22/04/2016 22:08, Frédéric Rodrigo a écrit :

Pour les églises c'est d'autant plus "intéressant" que le
symbole est orienté et la forme non triviale !

Je crois que le défi est lancé. Par contre, ça risque d'attendre
un peu, ma liste de choses à faire avant est un peu longue.


Je ne vois pas en quoi le symbole d'une église ou temple (la croix) ou 
d'une synagogue (classiquement une étoile de David) ou d'une mosquée 
(classiquement un croissant) est orienté : il n'y a qu'une orientation 
valable dans chaque cas (celle de représetnation de la carte), c'est 
un symbole qui apparaitre ancré sur le batiment, même s'il n'est 
représenté que par un noeud ou par un polygone complexe. Faire tourner 
cette croix ou le croissant aura un sens un peu particulier et 
pourrait même être perçu négativement (imaginez l'effet de voir une 
croix renversée).
Dans tous les cas on se place dans l'orientation d'observation de la 
carte (et de lecture de sa légende éventuelle).
Ce n'est pas comme les terrains de sport ou les barrières et barrages 
qu'on a intéret à rienter dans le bon sens dans ils ne sont 
représentés que par un noeud (le symbole étant figuratif de la 
réalité). Je ne vois même pas en quoi cela améliore la lisibilité de 
la carte et la reconnaissance du symbole. Si cela dépend de 
l'orientation du batiment, c'est le batiment lui-même qu'il faut 
représenter (et ce n'est pas lié au culte qui est célébré dedans... ou 
pas).


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

Re: [OSM-talk-fr] R25, Maperitive et orientation d'objets

[JB]

Le 22/04/2016 15:07, Nicolas Dumoulin (by way of Nicolas Dumoulin 
<nico...@dumoulin63.net>) (by way of Nicolas Dumoulin 
<nico...@dumoulin63.net>) a écrit :

Pratique ces détails de rendu, du coup, j'ai repéré et corrigé deux
cascades mal taguées;-)
Et tiens, il y avait deux cols de la croix saint-robert à 300m l'un de
l'autre.

Et hop, remis à jour : http://jb.isonoe.net/PonW/Demo_orientation.png

Le 22/04/2016 22:08, Frédéric Rodrigo a écrit :
Pour les églises c'est d'autant plus "intéressant" que le symbole est 
orienté et la forme non triviale !
Je crois que le défi est lancé. Par contre, ça risque d'attendre un peu, 
ma liste de choses à faire avant est un peu longue.

JB.



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

Re: [OSM-talk-fr] R25, Maperitive et orientation d'objets

[JB]

Réponse rapide : la plus logique est probablement la bonne.
À ta décharge, je n'ai pas évoqué le fichier d'initialisation dans le 
readme, je le ferai à l'occasion. Ce fichier indique quels types de 
points chercher sur quels types de chemins.
Et pour le calcul d'angle, quand un seul segment part du point, c'est 
évident, quand deux segments partent du point (pas forcément sur un même 
way), c'est pareil. Quand plus de deux segments partent du point, il n'y 
a pas d'angle défini et le script l'indique bien.

JB.

Le 22/04/2016 17:05, Philippe Verdy a écrit :
Comment tu fais pour orienter un noeud s'il n'y a pas un et un seul 
chemin qui traverse ce noeud ?
Que se passe-t-il si ce noeud est à une position de coupure du chemin 
en deux segments (autrement dit à leur extrémité commune) ?
S'il y a plusieurs chemins, essayes-tu de déterminer un chemin 
pertinent elon ses attributs (par exemple pour un barrage, chercher un 
waterway) ?
Et quand il y a un angle non plat à ce noeud même s'il n'y a pas de 
coupure et bien un et un seul chemin dans tes données, prends-tu 
arbitrairement la direction du segment placé avant (ou après) dans la 
direction du tracé ou bien détermines-tu une direction bissectrice ?



Le 22 avril 2016 à 12:16, JB <jb...@mailoo.org 
<mailto:jb...@mailoo.org>> a écrit :


Bonjour,
Du nouveau du coté de R25 (ou autres feuilles de style sous
Maperitive) !
Maperitive ne permettait pas d'orienter certains objets, par
exemple, orienter une barrière (node) en travers un chemin (way).
Ça me travaillait depuis un petit bout de temps, et j'ai fini par
mettre les mains dans le cambouis. Le temps de résoudre un bug
débile, et ça finit par fonctionner.
Un exemple en images :
http://jb.isonoe.net/PonW/Demo_orientation.png : cherchez les
cascades et les barrières ! Si quelqu'un connait l'endroit rêvé en
France qui contient sur une zone réduite des cascades, des
barrages, des écluses, des barrières où les piétons peuvent passer
et d'autres où ils ne peuvent pas, merci de faire passer l'info…
Le petit code et indications d'utilisation :
https://github.com/JBacc1/PonW. Tests bienvenus !
Le système sera bientôt intégré à R25 (feuille de style) et à
CarnetRando (génération de topoguides).
JB.

PS : je n'aborde pas les questions métaphysiques de savoir si on
cherche à faire faire à un logiciel plus que ce qu'il ne devrait,
plutôt que de se tourner vers une chaine de rendu plus lourde…
Est-ce qu'on arrivera à orienter les symboles d'églises un jour ?

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




___
Talk-fr mailing list
Talk-fr@openstreetmap.org
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] R25, Maperitive et orientation d'objets

[JB]

Le 22/04/2016 18:54, Christian Quest a écrit :

Pas pire que les passages piétons ou les terrains de sport ;)
Que les passages piétons, non (et je pense qu'on doit avoir la même 
approche, sauf qu'avec Python, c'est un peu plus rustique). Mais pour 
les terrains de sports ou les églises… il faut recaler un modèle sur un 
objet, et je ne suis pas sûr de la méthode !


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

[OSM-talk-fr] R25, Maperitive et orientation d'objets

[JB]

Bonjour,
Du nouveau du coté de R25 (ou autres feuilles de style sous Maperitive) !
Maperitive ne permettait pas d'orienter certains objets, par exemple, 
orienter une barrière (node) en travers un chemin (way). Ça me 
travaillait depuis un petit bout de temps, et j'ai fini par mettre les 
mains dans le cambouis. Le temps de résoudre un bug débile, et ça finit 
par fonctionner.
Un exemple en images : http://jb.isonoe.net/PonW/Demo_orientation.png : 
cherchez les cascades et les barrières ! Si quelqu'un connait l'endroit 
rêvé en France qui contient sur une zone réduite des cascades, des 
barrages, des écluses, des barrières où les piétons peuvent passer et 
d'autres où ils ne peuvent pas, merci de faire passer l'info…
Le petit code et indications d'utilisation : 
https://github.com/JBacc1/PonW. Tests bienvenus !
Le système sera bientôt intégré à R25 (feuille de style) et à 
CarnetRando (génération de topoguides).

JB.

PS : je n'aborde pas les questions métaphysiques de savoir si on cherche 
à faire faire à un logiciel plus que ce qu'il ne devrait, plutôt que de 
se tourner vers une chaine de rendu plus lourde… Est-ce qu'on arrivera à 
orienter les symboles d'églises un jour ?


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

Re: [OSM-talk-fr] [OSM-talk-fr-bzh] rennes - chemin au lieu de relation

[JB]

Mouaif, les nœuds de ce genre, je suis pas convaincu quand même :
http://www.openstreetmap.org/node/4071657397
http://www.openstreetmap.org/node/4071657288
Et la plupart des autres. S'il y a une plaque explicative, on taggue la 
plaque. Si c'est autre chose, on trouve autre chose, mais le 
tourism=attraction, ça sent le taggué soit pour le rendu, soit pour un 
usage particulier.

JB.

Le 12/04/2016 22:42, PanierAvide a écrit :

Pour le suivi :
http://overpass-turbo.eu/s/fCk

Il y en a 3 de transformées et une incomplète. Par ailleurs, la ligne 
7 qui est disponible en tant que relation a été recréée sous forme de 
chemin en doublon par l'utilisateur Philippe21. Quelqu'un s'était 
chargé de le contacter pour signaler le souci ?


Cordialement.


Le 11/04/2016 22:11, Romain MEHUT a écrit :

C'est parfait :)

Le 11 avril 2016 à 22:07, Nicolas VIGNERON 
<vigneron.nico...@gmail.com <mailto:vigneron.nico...@gmail.com>> a 
écrit :


Ils sont bien visibles ; ils sont même mieux que balisés, puisque
le tracé est directement et intégralement matérialisé par une
ligne rouge au sol ;) (source

http://www.rennes.lemensuel.com/actualite/article/2016/03/15/suivez-la-ligne-rouge-pour-decouvrir-rennes-autrement-16174.html
).

Cdlt, ~nicolas





___
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] Les poubelles

[JB]

Euh, non ?
Shelter=yes, à froid, pour moi, c'est pour les humains. À tiède, wiki à 
l'appui, c'est aussi pour les humains 
(http://wiki.openstreetmap.org/wiki/Key:shelter).
Pas sûr que dévoyer ce tag pour les poubelles soit vraiment une bonne 
idée, même si c'est celle qui vient à l'esprit en premier.
À quand l'appli qu'on utilise sous la pluie pour chercher à s'abriter 
qui nous amène au conteneur à poubelle ?

JB.

Le 07/03/2016 16:21, Tony Emery a écrit :

Quoi qu'il en soit, l’illustration de la page wiki de la clé
amenity=waste_disposal montre bien un  bac mobile
<http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dwaste_disposal>  , non ?

Donc, je vous propose qu'on les cartographie tel quel est que l'on ajoute un
tag du type shelter = yes pour ceux qui se trouvent dans un abris clos ou
non.

Ça vous va ?



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Les-poubelles-tp5866687p5869306.html
Sent from the France mailing list archive at Nabble.com.

___
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] JOSM et angles

[JB]

Du coup, comme ça marche chez vous j'ai cherché un peu, j'ai trouvé à 
bidouiller avec le clic droit dans la barre d'état en bas. J'ai remis le 
raccourci d'aplomb dans les options, mais même après redémarrage, il ne 
veut toujours pas le prendre en compte… Je creuserai à l'occasion.

JB

Le 02/03/2016 13:24, Christian Quest a écrit :
Cette fonction est toujours présente dans la version que j'utilise 
(9900).



Le 02/03/2016 12:41, JB a écrit :

Bonjour,
À une époque, il me semble qu'en mode ajout sous JOSM, en appuyant 
une deuxième fois sur la touche A, on trouvait facilement des angles 
spécifiques (30°, 45°, 90°…).

Est-ce que c'est complètement disparu, ou juste caché ailleurs ?
JB.

___
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

[OSM-talk-fr] JOSM et angles

[JB]

Bonjour,
À une époque, il me semble qu'en mode ajout sous JOSM, en appuyant une 
deuxième fois sur la touche A, on trouvait facilement des angles 
spécifiques (30°, 45°, 90°…).

Est-ce que c'est complètement disparu, ou juste caché ailleurs ?
JB.

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

Re: [OSM-talk-fr] Couche Route500 mise à jour (édition 2015)

[JB]

Le 13/02/2016 12:38, Erwan Salomon a écrit :

on peut utiliser cette couche pour renseigner le type de highway ?

Dans les zones « bien » cartographiées : non, ce n'est pas une bonne idée.
Une personne avec qui on travaillait par l'intermédiaire de notes 
proposait toute une série de reclassement d'après Route500, on les avait 
finalement toutes refusées. La contribution manuelle avec la 
connaissance du terrain est beaucoup plus efficace et cohérente que 
Route500.

JB.

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

Re: [OSM-talk-fr] Doute sur le calage Bing/Cadastre

[JB]

Le 09/02/2016 12:01, Tyndare a écrit :
Je ne sais pas ce qu'elle vaut dans ce coin mais en cas de doutes de 
callage j'ai tendance à faire confiance à la couche des traces Strava 
(en désactivant le zoom automatique dans JOSM pour zoomer plus que le 
fond qu'ils rendent disponible, et en affichant la couche plusieurs 
fois si il y a peu de points pour les rendre plus visibles)
J'apprécie aussi Strava dans les zones où les VTTistes passent, et 
regrette la faible visibilité et manque de zoom aux échelles de traçage.

Mais désactiver le zoom automatique, tu fais ça comment ?
JB.

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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[JB]

(Il me semblait l'avoir vu la première fois que j'étais allé sur la 
page, mais c'est vrai que la deuxième fois, j'ai dû chercher un peu.)
En haut à droite de la page, l'œil, puis « vue complète », puis onglet « 
complet ».

JB.

Le 07/02/2016 00:29, Christian Quest a écrit :

Tu vois ça où ?

Le 7 février 2016 à 00:05, JB <jb...@mailoo.org 
<mailto:jb...@mailoo.org>> a écrit :


Je vais pas me battre là-dessus, mais comment tu interprèterais le :
/Contraintes légales//
//Limitation d'utilisation//
//Mentions obligatoires : "CG63-2014"//
//Restriction d'accès//
//Droit de propriété intellectuelle / Droit patrimonial//
//Restriction d'utilisation//
//Droit de propriété intellectuelle / Droit patrimonial//
/vu sur le descriptif complet ?
JB.



Le 06/02/2016 21:15, Christian Quest a écrit :

Sur

http://ids.craig.fr/geocat/srv/fre/catalog.search#/metadata/3bd16d2d-5fc7-4816-b824-c274603cfd16
il est indiqué:

Contraintes légales

Mentions obligatoires : "CG63-2014"


Donc un simple source=CG63-2014 devrait suffire. De toute façon
c'est de la donnée publique, non soumise à redevance...


    Le 6 février 2016 à 20:17, JB <jb...@mailoo.org
<mailto:jb...@mailoo.org>> a écrit :

Euh, juste un truc en passant… c'est pas en train de
dégénérer, c't'histoire ? J'avais noté que les itinéraires du
PDIPR du Puy de Dôme n'étaient pas sous licence libre. Là, si
je comprends bien, vous êtes en train de les entrer dans une
base en ODbL, non ?
    Bon, j'dis ça, j'dis rien.
JB.

Le 06/02/2016 19:37, bernard a écrit :

J'ai résolu le problème d'import dans JOSM en téléchargeant
la trace dans mon PC puis en la chargeant dans JOSM.
Par contre, la recherche de la relation n'est pas
instantané. Après création il faut lui indiquer pour l'analyser.
J'ai ouvert la page discussion associé à la page
http://wiki.openstreetmap.org/wiki/France:Puy-de-D%C3%B4me/PDIPR
Il faudrait rajouter quelques colonnes dans le tableau :
-relation
- ...

Le 06/02/2016 19:10, Nicolas Dumoulin a écrit :


Le Saturday 06 February 2016, 11:44:38 bernard a écrit :

> Pratique,

> je vais en faire qq'unes.

> Faut-il créer également une relation?

> Si oui, une colonne supplémentaire serait utile, pour y
mettre le numéro

> de cette relation

Oui, bonne idée la question de la relation. J'avoue ne pas
y avoir réfléchi plus que ça.

Je découvre l'analyseur de relation sur osmsurround qui est
plutôt sympa :-)

Plutôt que "ref=ITI0360", il vaudrait mieux un truc du
genre "ref:FR:CD63=ITI0360", car c'est une référence
interne et non visible sur le terrain.

De même plutôt que "symbol=blue", il faut mettre "colour=blue".

cf. http://wiki.openstreetmap.org/wiki/Walking_Routes

Ce doit être possible de générer une relation prête pour JOSM.

Il faut que je regarde votre pb d'import dans JOSM également …

-- 


Nicolas Dumoulin

http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin



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




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



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




-- 
Christian Quest - OpenStreetMap France



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



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




--
Christian Quest - OpenStreetMap France


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


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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[JB]

Je vais pas me battre là-dessus, mais comment tu interprèterais le :
/Contraintes légales//
//Limitation d'utilisation//
//Mentions obligatoires : "CG63-2014"//
//Restriction d'accès//
//Droit de propriété intellectuelle / Droit patrimonial//
//Restriction d'utilisation//
//Droit de propriété intellectuelle / Droit patrimonial//
/vu sur le descriptif complet ?
JB.


Le 06/02/2016 21:15, Christian Quest a écrit :
Sur 
http://ids.craig.fr/geocat/srv/fre/catalog.search#/metadata/3bd16d2d-5fc7-4816-b824-c274603cfd16 
il est indiqué:


Contraintes légales

Mentions obligatoires : "CG63-2014"


Donc un simple source=CG63-2014 devrait suffire. De toute façon c'est 
de la donnée publique, non soumise à redevance...



Le 6 février 2016 à 20:17, JB <jb...@mailoo.org 
<mailto:jb...@mailoo.org>> a écrit :


Euh, juste un truc en passant… c'est pas en train de dégénérer,
c't'histoire ? J'avais noté que les itinéraires du PDIPR du Puy de
Dôme n'étaient pas sous licence libre. Là, si je comprends bien,
vous êtes en train de les entrer dans une base en ODbL, non ?
    Bon, j'dis ça, j'dis rien.
JB.

Le 06/02/2016 19:37, bernard a écrit :

J'ai résolu le problème d'import dans JOSM en téléchargeant la
trace dans mon PC puis en la chargeant dans JOSM.
Par contre, la recherche de la relation n'est pas instantané.
Après création il faut lui indiquer pour l'analyser.
J'ai ouvert la page discussion associé à la page
http://wiki.openstreetmap.org/wiki/France:Puy-de-D%C3%B4me/PDIPR
Il faudrait rajouter quelques colonnes dans le tableau :
-relation
- ...

Le 06/02/2016 19:10, Nicolas Dumoulin a écrit :


Le Saturday 06 February 2016, 11:44:38 bernard a écrit :

> Pratique,

> je vais en faire qq'unes.

> Faut-il créer également une relation?

> Si oui, une colonne supplémentaire serait utile, pour y mettre
le numéro

> de cette relation

Oui, bonne idée la question de la relation. J'avoue ne pas y
avoir réfléchi plus que ça.

Je découvre l'analyseur de relation sur osmsurround qui est
plutôt sympa :-)

Plutôt que "ref=ITI0360", il vaudrait mieux un truc du genre
"ref:FR:CD63=ITI0360", car c'est une référence interne et non
visible sur le terrain.

De même plutôt que "symbol=blue", il faut mettre "colour=blue".

cf. http://wiki.openstreetmap.org/wiki/Walking_Routes

Ce doit être possible de générer une relation prête pour JOSM.

Il faut que je regarde votre pb d'import dans JOSM également …

-- 


Nicolas Dumoulin

http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin



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




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



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




--
Christian Quest - OpenStreetMap France


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


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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[JB]

Euh, juste un truc en passant… c'est pas en train de dégénérer, 
c't'histoire ? J'avais noté que les itinéraires du PDIPR du Puy de Dôme 
n'étaient pas sous licence libre. Là, si je comprends bien, vous êtes en 
train de les entrer dans une base en ODbL, non ?

Bon, j'dis ça, j'dis rien.
JB.

Le 06/02/2016 19:37, bernard a écrit :
J'ai résolu le problème d'import dans JOSM en téléchargeant la trace 
dans mon PC puis en la chargeant dans JOSM.
Par contre, la recherche de la relation n'est pas instantané. Après 
création il faut lui indiquer pour l'analyser.

J'ai ouvert la page discussion associé à la page
http://wiki.openstreetmap.org/wiki/France:Puy-de-D%C3%B4me/PDIPR
Il faudrait rajouter quelques colonnes dans le tableau :
-relation
- ...

Le 06/02/2016 19:10, Nicolas Dumoulin a écrit :


Le Saturday 06 February 2016, 11:44:38 bernard a écrit :

> Pratique,

> je vais en faire qq'unes.

> Faut-il créer également une relation?

> Si oui, une colonne supplémentaire serait utile, pour y mettre le 
numéro


> de cette relation

Oui, bonne idée la question de la relation. J'avoue ne pas y avoir 
réfléchi plus que ça.


Je découvre l'analyseur de relation sur osmsurround qui est plutôt 
sympa :-)


Plutôt que "ref=ITI0360", il vaudrait mieux un truc du genre 
"ref:FR:CD63=ITI0360", car c'est une référence interne et non visible 
sur le terrain.


De même plutôt que "symbol=blue", il faut mettre "colour=blue".

cf. http://wiki.openstreetmap.org/wiki/Walking_Routes

Ce doit être possible de générer une relation prête pour JOSM.

Il faut que je regarde votre pb d'import dans JOSM également …

--

Nicolas Dumoulin

http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin



___
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


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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[JB]

Ça confirme au moins que si je savais utiliser QGis pas qu'avec les 
pieds, je m'empresserais de comparer les itinéraires PDIPR avec la 
voirie OSM, pour voir quel pourcentage de points de voie PDIPR n'est pas 
rapprochable avec un highway OSM. Mais à première vue, OSM n'a pas l'air 
d'avoir trop à rougir, peut-être un peu plus dans les zones reculées.
Ceci dit, je suis curieux de voir si ce que j'ai mis dans les mains des 
décideurs locaux de mon coté les fera réfléchir la prochaine fois avant 
de débourser des fortunes en éditions/cartes classiques.

JB.

Le 05/02/2016 22:30, Nicolas Dumoulin a écrit :


Bon, ça m'a démangé et je voulais me dérouiller avec OpenLayers 3, 
alors je me suis fait une petite carte pour aider :


http://osm.dumoulin63.net/pdipr63/

Et un tableau d'avancement pour ceux qui sont motivés :-)

http://wiki.openstreetmap.org/wiki/France:Puy-de-D%C3%B4me/PDIPR



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

Re: [OSM-talk-fr] Geofabrik downloads

[JB]

Bonjour,
Les fichiers sont déjà bien lourds, et les « anciennes » régions vont 
rester longtemps dans les mentalités en France. En tant que « petit » 
utilisateur, je préfère largement les découpes actuelles.

JB.

Le 05/02/2016 08:05, Christine Karch a écrit :

Bonjour,

qu'est-ce que vous pensez? Doit Geofabrik changer les régions
françaises? Avantage: Les régions seraient correctes. Désavantage: Les
gens qui utilisent Geofabrik download doivent changer leurs scriptes et
codes. Et enfin les fichiers sont déjà très larges. Changer ou non?

Cordialemnet

Christine

___
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] Fond OSM dans des guides de rando du CD63 ?

[JB]

Ok, en fait, j'ai à peu près rien compris :-(

Le 02/02/2016 20:46, Landry Breuil a écrit :

2016-02-02 18:21 GMT+01:00 JB <jb...@mailoo.org>:

Bonjour,
Une très bonne nouvelle !
Je me souviens d'une longue discussion que j'avais eue l'été 2014 avec un
gars bien informé de l'office de tourisme à Clermont-Ferrand. Je pensais en
avoir fait un compte-rendu, mais je n'arrive pas à en retrouver de trace.
C'était à l'époque du deuxième topoguide®, on avait notamment parlé de FFRP,
IGN, carte IGN, et un peu OpenStreetMap. J'avais par hasard avec moi la
carte que j'avais sortie pour le tour de la chaine des Puys.
Ceci dit :
  - est-ce qu'il serait possible de connaitre les circuits pressentis pour le
prochain guide, histoire de contribuer au meilleur endroit ?

Bonne question, ne pas hésiter à demander directement à guillaume, je suis
juste le messager...


  - les traces gps fournies sont de qualité… moyenne, à ne pas privilégier
sur d'autres sources, ou à moyenner avec d'autres traces (j'ai contribué
dans la zone, et en comparant certaines dont je pense la précision correcte,
celles fournies restent moyennes). En tous cas, ne pas supprimer la donnée
OSM pour la remplacer par cette donnée qui serait « de référence ».

J'ai l'impression qu'il y'a mésentente ici. les PDIPR ne sont pas
*pas* en opendata,
donc pas importables dans OSM. J'avais pourtant pensé etre clair dans
mon mail initial.
La notion 'donnée de référence' est annexe ici.

J'ai fourni le lien vers le shapefile des PDIPR présents sur notre
catalogue de données
*uniquement* pour la liste/les emprises des zones concernées...


  - si R25 est pressenti pour le rendu, je veux bien y passer un peu de
temps. Quand la donnée est bonne, la génération de carte est rapide (quand
on a l'habitude, en tous cas).

A discuter directement avec guillaume, quand on avait évoqué le sujet
c'était plutôt
"dans arcgis on a accès directement a un fond OSM" donc je ne sais pas a quel
rendo/fond/service ca correspond. A mon avis dans un premier temps il
n'était pas
prévu de rendu particulier, sauf si evidemment quelqu'un se porte
volontaire pour
gérer ca..

Landry


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

Re: [OSM-talk-fr] Fond OSM dans des guides de rando du CD63 ?

[JB]

Bonjour,
Une très bonne nouvelle !
Je me souviens d'une longue discussion que j'avais eue l'été 2014 avec 
un gars bien informé de l'office de tourisme à Clermont-Ferrand. Je 
pensais en avoir fait un compte-rendu, mais je n'arrive pas à en 
retrouver de trace. C'était à l'époque du deuxième topoguide®, on avait 
notamment parlé de FFRP, IGN, carte IGN, et un peu OpenStreetMap. 
J'avais par hasard avec moi la carte que j'avais sortie pour le tour de 
la chaine des Puys.

Ceci dit :
 - est-ce qu'il serait possible de connaitre les circuits pressentis 
pour le prochain guide, histoire de contribuer au meilleur endroit ?
 - s'il y en a un du coté du col du Béal, je veux bien aller faire une 
sortie par là-bas (je suis de l'autre coté du col, chez les Rhône-Alpiens…)
 - les traces gps fournies sont de qualité… moyenne, à ne pas 
privilégier sur d'autres sources, ou à moyenner avec d'autres traces 
(j'ai contribué dans la zone, et en comparant certaines dont je pense la 
précision correcte, celles fournies restent moyennes). En tous cas, ne 
pas supprimer la donnée OSM pour la remplacer par cette donnée qui 
serait « de référence ».
 - si R25 est pressenti pour le rendu, je veux bien y passer un peu de 
temps. Quand la donnée est bonne, la génération de carte est rapide 
(quand on a l'habitude, en tous cas). On est dans la zone là, tiens : 
http://jb.isonoe.net/CR/demo/Volcans_A5_d%C3%A9mo.pdf
(et puis enfin surimprimer la trace gps de manière semi-transparente, et 
arrêter de cacher ce qu'il y a dessous !)
Voilà voilà, ce serait vraiment chouette que ça aboutisse… probablement 
plus de chances que dans ma zone, ou le topoguide® est en réfection…

JB.

Le 02/02/2016 11:52, Landry Breuil a écrit :

Hello,

le conseil départemental du Puy-de-Dôme envisage d'utiliser des fonds
OSM pour l'édition de son prochain guide papier/pdf de randonnées
suivant les PDIPR - ces guides utilisaient jusqu'ici le fond scan 25
de l'IGN (que le CRAIG fournit au CD63), mais a priori (?) les
conditions de licence ne le permettent plus de la même manière, donc
pour des questions de coût le service SIG s'oriente potentiellement
vers un fond OSM.

Cf 
http://www.planetepuydedome.com/destination-volcans/tout-le-puy-de-dome/le-puy-de-dome-terre-de-randonnee-au-coeur-des-volcans/randonnez-vous-661-1.html,
http://www.planetepuydedome.com/destination-volcans/tout-le-puy-de-dome/le-puy-de-dome-terre-de-randonnee-au-coeur-des-volcans/randos-a-croquer-662-1.html
et http://www.planetepuydedome.com/brochures-688-1.html pour les
précedentes éditions. Oui, y'a du google maps sur les versions web des
itinéraires, mais du scan 25 dans la version pdf/papier.

Après en avoir discuté avec Guillaume Tournadre (du service SIG) qui
trouvait que les données OSM étaient un peu pauvres sur les zones
concernées (les PDIPR), je lui ai proposé de faire appel à la
communauté pour enclencher le cercle vertueux de -> les itinéraires
sont la -> on améliore les données -> le fond devient plus riche ->
tout le monde en bénéficie!

Dans tout les cas, les itinéraires des PDIPR sont disponibles en ligne
chez nous: 
http://ids.craig.fr/geocat/apps/search/?uuid=3bd16d2d-5fc7-4816-b824-c274603cfd16

Les données ne sont pas en opendata (pas encore, mais guillaume y
travaille!) mais rien n'empèche (ou plutôt, on a l'accord) de les
utiliser pour connaitre les zones à améliorer/cartographier

Ca ne sera peut-être pas pour cette édition because timing serré...
mais ca ne sera jamais perdu!

Guillaume est en copie de ce mail, vous pouvez le contacter pour plus
d'informations.

Landry

___
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] Icone verte sur les lieu dit

[JB]

Bonne amélioration !
Pour le tri du tableau, je suppose que c'est d'abord les lieux 
construits selon le cadastre, puis par lettre alphabétique de la valeur 
place ? Je pense que ce serait plus pratique par « taille » de lieu 
habité : pour l'instant, neighbourhood apparait après locality. J'aurais 
plutôt vu quelque chose comme d'abord neighbourhood, puis hamlet, 
isolated_dwelling, et locality à la fin.

JB.

Le 31/01/2016 08:46, Vincent de Château-Thierry a écrit :

Bonjour,

Le 27/01/2016 17:52, Vincent de Château-Thierry a écrit :

De: "JB" <jb...@mailoo.org>

Je déterre ce vieux sujet. Je reprenais les lieux-dits et autres
habitations isolées dans ma campagne profonde sur la page fantoir
http://cadastre.openstreetmap.fr/fantoir. L'icône verte est chouette
pour la partie cadastre (même si très largement sujette à erreur), et
je me disais que ce serait aussi chouette d'en mettre une du côté OSM
(même si également très largement sujet à erreur pour tout ce qui a été
importé sans travail derrière). Du genre, si place =
hamlet/isolated_dwelling/farm : une icône, et rien pour
place=locality.
C'est imaginable ?


Oui, on a prévu dans le modèle de garder la valeur de place=* 
associée au nom. Donc c'est possible, même si pas déjà fait. Un peu 
de plomberie dans les jours à venir, et à suivre ici.


Voilà c'est ajouté. J'ai finalement repris le texte de la valeur du 
tag place, directement accolé au nom. L'idée est de garder la variété* 
du contenu source, sans une déclinaison en pictos qui doucement sinon 
transforme la page en arbre de noël.

Retours bienvenus.

vincent

* on rencontre à la marge comme valeurs :
"isolated dwelling"
"Voisinage"
"isolated-dwelling"
"Hameau"
"Kroaz ar Marichal"
"isolared_building"
"place"
"isolated_dwelling+"
""
"Combe des Bourguignons"
"residence"
"hamlet+++"
"Bray"
"islated_dwelling"
"city_block"
"square"
"plot"

___
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] Doit-on encore renseigner les adresses dans OSM ou se focaliser sur BANO ?

[JB]

Le 29/01/2016 09:12, Christian Quest a écrit :

En alternant avec un peu de CLC à affiner

Et à découper en petits morceaux…
Euh, non, en fait, ça, c'est quand on a du temps.

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

Re: [OSM-talk-fr] Icone verte sur les lieu dit

[JB]

Bonjour,
Je déterre ce vieux sujet. Je reprenais les lieux-dits et autres 
habitations isolées dans ma campagne profonde sur la page fantoir 
http://cadastre.openstreetmap.fr/fantoir. L'icône verte est chouette 
pour la partie cadastre (même si très largement sujette à erreur), et je 
me disais que ce serait aussi chouette d'en mettre une du côté OSM (même 
si également très largement sujet à erreur pour tout ce qui a été 
importé sans travail derrière). Du genre, si place = 
hamlet/isolated_dwelling/farm : une icône, et rien pour place=locality. 
C'est imaginable ?

Bonne soirée,
JB.

Le 23/12/2015 09:09, Vincent de Château-Thierry a écrit :

Bonjour,

Le 23/12/2015 08:30, Ludovic Hirlimann a écrit :

http://cadastre.openstreetmap.fr/fantoir/#insee=24191=4

Le debut de la liste est constitué de nom précédé d'icone verte (et
genre la lidoire , une rivière), elles représentent quoi ces icones ?


C'est l'icône utilisée dans JOSM pour représenter les nodes place=* 
habités :

http://wiki.openstreetmap.org/wiki/Key:place

Je l'ai utilisée ici pour distinguer les lieux-dits batis d'après 
Fantoir, donc avec '1' comme valeur de ld_bati :
http://cadastre.openstreetmap.fr/fantoir/liste_brute_fantoir.html#insee=24191 



vincent

___
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] Conservatoires et écoles de musique

[JB]

Pour ma part, j'ai opté pour amenity=music_school. 50 occurences en 
France, 300 dans le monde. C'est du taggage au canard, trop éloigné 
d'une école classique pour surcharger un amenity=school, assez 
spécifique pour son tag à lui. Et un peu sur le modèle du plus répandu 
amenity=driving_school.

JB.

Le 23/01/2016 23:38, Muselaar a écrit :

Bonsoir,

J'ai l'impression qu'il n'y a rien de prévu pour taguer les 
conservatoires et écoles de musique, comme les écoles d'art, du reste. 
Pourtant, ce sont des équipements généralement publics, tout à fait 
spécifiques, qu'il serait autant nécessaire de signaler, sans que cela 
ne surcharge beaucoup les données.
Certains sont tagués en « university » (il y a de l'enseignement 
supérieur dans un certain nombre), mais ça ne me semble pas refléter 
la réalité. Car il n'y a que 2 conservatoires en France (Lyon et 
Paris) qui ne dispense que de l'enseignement supérieur, tous les 
autres démarrent aux petits niveaux, et comportent quelques niveaux 
reconnus comme enseignement supérieur.


Que pourrait-on faire ?

Muselaar

___
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