Re: [OSM-talk-fr] [Python] Générer image carte statique à partir coordonnées GPS?

2019-06-25 Par sujet Shohreh 
Que doit-on mettre dans un script ?



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] [Python] Générer image carte statique à partir coordonnées GPS?

2019-06-25 Par sujet marc marc 
Bonjour,

Le 25.06.19 à 17:04, Shohreh a écrit :
> headers = {"User-Agent": "Mozilla/5.0 (Windows NT 6.1; WOW64)
> AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5",
> "Referer": "https://www.google.com"}

sur osm.org et ailleurs, certains règles ont été durcie
pour bannir/pénaliser ceux qui envoient volontairement des faux headers.
aucune idée pour ce service là en particulier, mais c'est "pas cool"
les usurpations, vraiement pas cool. et pas pratique quand on souhaite
contacter l'usurpateur pour un soucis ou débuger un problème réel.

as-tu essayé avec des entêtes non faussée ?

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

Re: [OSM-talk-fr] Recommandations pour le routage piéton

2019-06-25 Par sujet osm . sanspourriel 

Sur
https://wiki.openstreetmap.org/wiki/File:Pedestrian_area_routing-FR.png,
partie place piétonne traversée par une rue piétonne, ne doit-on pas
avoir un nœud à l'intersection entre les deux chemins pour qu'un moteur
linéaire puisse passer d'une rue à l'autre ?

> le /périmètre/ d'une surface constituant une barrière implicite :
bâtiment building
=* (à l'exception
des toits building
=roof
), kiosque à
musique leisure
=bandstand
, etc.

J'aurais dit :

le /périmètre/ d'une surface constituant une barrière implicite :
kiosque à musique leisure
=bandstand
,
bâtiment building
=* (à l'exception
des toits building
=roof
), etc.

Certes le cas le plus classique est le bâtiment pas le kiosque à musique
mais sinon une lecture rapide fait croire que les kiosques à musique ne
sont pas des obstacles.

> Le *niveau plancher* d'une /aire piétonne indoor/ correspond à la
valeur de level la plus basse : le routage piéton se fait à ce niveau
uniquement.

Pourquoi cette restriction ? On peut imaginer que pour passer d'un
endroit level=0 à un autre level=0 on doive monter au level=1 puis
redescendre. Sinon à quoi bon modéliser les escaliers ?

Ou veux-tu dire que le routage du monde extérieur au monde indoor se
fait forcément par un nœud level=0 ?

https://wiki.openstreetmap.org/wiki/File:Building_indoor_elevator-FR.png

Pour les postes de l'ascenseur j'aurais mis automatic_door
=*, peut-être
door=sliding, sûrement pas door=no !

Jean-Yvon

Le 25/06/2019 à 19:30, Antoine Riche via Talk-fr -
talk-fr@openstreetmap.org a écrit :

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

[OSM-talk-fr] Recommandations pour le routage piéton

2019-06-25 Par sujet Antoine Riche via Talk-fr 

Bonjour,

Dans le cadre d'un projet avec la SNCF nous avons rédigé sur le wiki des 
recommandations pour le routage piéton : 
https://wiki.openstreetmap.org/wiki/FR:Recommandations_pour_le_routage_piéton


Cette page est le fruit de l'expérience du développement d'un 
calculateur d'itinéraires combinant espaces intérieurs (indoor) et 
extérieurs, et mettant en œuvre un routage surfacique sur certains 
éléments (places piétonnes, espaces indoor). Ce travail a été présenté à 
Montpellier lors du SOTM, la présentation peut être téléchargée en 
cliquant sur ce lien 
.


L'objectif de cette page est de décrire comment cartographier pour 
permettre des calculs d'itinéraires précis et réalistes pour les piétons 
(les piétons ont en effet la particularité d'emprunter trottoirs, 
escaliers et ascenseurs, d'entrer dans les bâtiments, de traverser les 
places en ligne droite, etc.). Cette page n'introduit aucune nouveauté, 
elle décrit tous les éléments pouvant servir au routage piéton, elle 
clarifie peut-être certains concepts - par exemple les jonctions 
géométriques pour le routage surfacique. Une dizaine de schémas 
s'efforcent d'illustrer les propos.


Si ce sujet vous intéresse, merci de lire cette page et de me faire vos 
retours et remarques.


Merci,
Antoine.


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

Re: [OSM-talk-fr] routage surfacique

2019-06-25 Par sujet Antoine Riche via Talk-fr 

Merci de ton retour.

On peut faire un fil spécifique sur Talk-fr (c'est peut-être mieux 
d'utiliser la page de discussion pour des évolutions plutôt que des 
clarifications ?) : je vais envoyer un mail dédié.


Pour le schéma il y a bien un highway=crossing sur chacun des nœuds 
représentés par un passage piéton. J'ai mis à jour le schéma : 
https://wiki.openstreetmap.org/wiki/File:Sidewalk_crossing-FR.png . 
C'est plus clair comme ça ?


Antoine.

Le 25/06/2019 à 18:17, osm.sanspourr...@spamgourmet.com a écrit :


Tu veux qu'on en discute comment ? En direct ? Sur talk-fr (avec un 
fil spécifique ;-)), sur la page de discussion ?


Sur la première image :


J'ai du mal à comprendre : n'est-ce pas plutôt un nœud commun au 
chemin séparé (highway=footway) et à la route (highway=*, sidewalk=*) 
qui est tagué crossing=) ? Et grosso-modo juste la petite partie entre 
le croisement des deux trottoirs séparés et et les rues qui doivent 
être en footway=crossing c'est à dire la partie linéaire correspondant 
aux zébras sur la route ?


Le 25/06/2019 à 16:17, Antoine Riche via Talk-fr - 
talk-fr@openstreetmap.org a écrit :


Bonjour,
Je raccroche cette échange un peu tardivement...

Le wiki sur la clef area:highway inclut une section 
 
qui dit explicitement que area:highway n'est *pas* fait pour le 
routing, alors que la combinaison de highway=* et area=yes peut être 
utilisée pour le routing surfacique.


Je suis d'accord aussi sur une approche pragmatique : conserver des 
éléments linéaires qui permettent aux principaux outils de calcul 
d'itinéraires de fonctionner, sans pour autant tracer toutes les 
routes possibles. Et permettre aux logiciels qui font du routing 
surfacique de produire des itinéraires plus réalistes. Il faut pour 
cela connecter les routes linéaires aux places surfaciques en 
partageant un node.


C'est le moment de vous présenter la page de recommandations pour le 
routage piéton 
, 
qui inclut une grosse section sur le routage surfacique, prend en 
compte le indoor comme le outdoor, et inclut une dizaine de schémas. 
Cette page a été présentée lors du SOTM à Montpellier, la 
présentation correspondante est téléchargeable avec ce lien 
.


Je suis preneur de vos retours sur cette page.

Antoine.


Le 19/06/2019 à 17:09, Jérôme Seigneuret a écrit :
Pour l'exemple de Montpellier, les tracés ont été supprimés par mes 
soins puis rajouté par les services de la métropole qui utilise des 
extractions pour ses propres outils de routing (non OSM compliant) 
et qui existe historiquement. Donc les linéaires correspondent à une 
nécessité de leurs outils pour le routing et je pense pour 
l'intermodalité (adresse vers adresse). (non compatible avec de 
l'itinéraire polygonale)


D'où un commentaire dans les tracés.
C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a 
aussi des tracés en double pour palier au problème d'affichage des 
noms (linéaire plus zone en dessous)


L'autres système qui a encore d'autres implications c'est 
*area:highway=**.


Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut 
mieux faire un post traitement sous forme de maille avec détection 
d’obstacle pour générer du tracé virtuel plutôt que ce que l'on voit 
sur ta capture d'écran.





Le mer. 19 juin 2019 à 16:54, lenny.libre > a écrit :



Le 18/06/2019 à 20:33, marc marc a écrit :

j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
mais aucun des 4 itinéraires n’atteint l'itinéraire réel
alors que ce sont 2 points de osm de la place.
donc même ce site a du limiter le nuage de way représentant la place.
alors imagine les dégâts si tu routes entre Paris et Monpellier
en surfacique.

A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied
(même quand j'étais jeune, je ne le faisais pas).

Le 18/06/2019 à 20:10, marc marc -marc_marc_...@hotmail.com  
  a écrit :

Le 18.06.19 à 18:48, lenny.libre a écrit :

donc pour ma part, les routes donnant sur une place
se rejoignent en un point + souvent place=square
c'est une représentation imparfaite, mais c'est
à l'heure actuelle sans doute le meilleur compromis

Pour l'anomalie que j'avais signalée, comme le dit Phyks (2
accès sur la place à quoi bon tracer un chemin fictif qui n'est
pas nécessaire aux calculateurs)

Pourquoi les outils évolueraient-ils, si on leur mâche le
boulot ? 

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed

Re: [OSM-talk-fr] routage surfacique

2019-06-25 Par sujet osm . sanspourriel 

Tu veux qu'on en discute comment ? En direct ? Sur talk-fr (avec un fil
spécifique ;-)), sur la page de discussion ?

Sur la première image :

https://wiki.openstreetmap.org/w/images/5/5c/Sidewalk_crossing-FR.png

J'ai du mal à comprendre : n'est-ce pas plutôt un nœud commun au chemin
séparé (highway=footway) et à la route (highway=*, sidewalk=*) qui est
tagué crossing=) ? Et grosso-modo juste la petite partie entre le
croisement des deux trottoirs séparés et et les rues qui doivent être en
footway=crossing c'est à dire la partie linéaire correspondant aux
zébras sur la route ?

Le 25/06/2019 à 16:17, Antoine Riche via Talk-fr -
talk-fr@openstreetmap.org a écrit :


Bonjour,
Je raccroche cette échange un peu tardivement...

Le wiki sur la clef area:highway inclut une section

qui dit explicitement que area:highway n'est *pas* fait pour le
routing, alors que la combinaison de highway=* et area=yes peut être
utilisée pour le routing surfacique.

Je suis d'accord aussi sur une approche pragmatique : conserver des
éléments linéaires qui permettent aux principaux outils de calcul
d'itinéraires de fonctionner, sans pour autant tracer toutes les
routes possibles. Et permettre aux logiciels qui font du routing
surfacique de produire des itinéraires plus réalistes. Il faut pour
cela connecter les routes linéaires aux places surfaciques en
partageant un node.

C'est le moment de vous présenter la page de recommandations pour le
routage piéton
,
qui inclut une grosse section sur le routage surfacique, prend en
compte le indoor comme le outdoor, et inclut une dizaine de schémas.
Cette page a été présentée lors du SOTM à Montpellier, la présentation
correspondante est téléchargeable avec ce lien
.

Je suis preneur de vos retours sur cette page.

Antoine.


Le 19/06/2019 à 17:09, Jérôme Seigneuret a écrit :

Pour l'exemple de Montpellier, les tracés ont été supprimés par mes
soins puis rajouté par les services de la métropole qui utilise des
extractions pour ses propres outils de routing (non OSM compliant) et
qui existe historiquement. Donc les linéaires correspondent à une
nécessité de leurs outils pour le routing et je pense pour
l'intermodalité (adresse vers adresse). (non compatible avec de
l'itinéraire polygonale)

D'où un commentaire dans les tracés.
C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a
aussi des tracés en double pour palier au problème d'affichage des
noms (linéaire plus zone en dessous)

L'autres système qui a encore d'autres implications c'est
*area:highway=**.

Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut
mieux faire un post traitement sous forme de maille avec détection
d’obstacle pour générer du tracé virtuel plutôt que ce que l'on voit
sur ta capture d'écran.




Le mer. 19 juin 2019 à 16:54, lenny.libre mailto:lenny.li...@orange.fr>> a écrit :


Le 18/06/2019 à 20:33, marc marc a écrit :

j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
mais aucun des 4 itinéraires n’atteint l'itinéraire réel
alors que ce sont 2 points de osm de la place.
donc même ce site a du limiter le nuage de way représentant la place.
alors imagine les dégâts si tu routes entre Paris et Monpellier
en surfacique.

A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied
(même quand j'étais jeune, je ne le faisais pas).

Le 18/06/2019 à 20:10, marc marc -marc_marc_...@hotmail.com  
  a écrit :

Le 18.06.19 à 18:48, lenny.libre a écrit :

donc pour ma part, les routes donnant sur une place
se rejoignent en un point + souvent place=square
c'est une représentation imparfaite, mais c'est
à l'heure actuelle sans doute le meilleur compromis

Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès
sur la place à quoi bon tracer un chemin fictif qui n'est pas
nécessaire aux calculateurs)

Pourquoi les outils évolueraient-ils, si on leur mâche le
boulot ?

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed
puis lanes puis turn:lanes par ex)
- soit par un changement de tags (par ex power=sub_Station
divisé en 2 power=substation et power=generator).
Si on suit cette logique, c'est area:highway qui devrait
être utilisé pour une transitions sans dégradation.

casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :

Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne
devrais pas en parler ... , je serais bien

[OSM-talk-fr] [Python] Générer image carte statique à partir coordonnées GPS?

2019-06-25 Par sujet Shohreh 
Bonjour,

Le code Python suivant fonctionne si j'utilise l'example donné sur le site
StaticMapLite*, mais il retourne un fichier noir si j'utilise mes propres
coordonnées.

=
import requests

#NOK
url =
'https://staticmap.openstreetmap.de/staticmap.php?center=48.8591,2.3470=14=400x400=mapnik'
#OK
url =
'https://staticmap.openstreetmap.de/staticmap.php?center=40.714728,-73.998672=14=400x400=mapnik'

headers = {"User-Agent": "Mozilla/5.0 (Windows NT 6.1; WOW64)
AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.52 Safari/536.5",
"Referer": "https://www.google.com"}

f=open('static.png','wb')
f.write(requests.post(url, headers=headers).content)
f.close()
=

Serait-ce parce que l'admin du serveur ne veut plus que les gens l'utilisent
?**

Si c'est le cas, y a-t-il une alternative pour quelques dizaines de
requêtes/jour maximum ?

Merci.

* http://staticmaplite.sourceforge.net/
**
https://wiki.openstreetmap.org/wiki/StaticMapLite#openstreetmap.de_hosting



--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] question philantropique - impact environnemental du libre

2019-06-25 Par sujet Romain MEHUT 
Bonjour,


Axelos wrote
> Je pense qu'il s'agit clairement du principal atout du logiciel libre.
> La pollution numérique ne concerne pas uniquement la durée de vie utile
> de l’appareil, mais aussi sa conception et son recyclable ... ou son
> trafic dans le tiers monde.
> 
> Exploitation de métaux rares, non recyclage possible de la majorité de
> ces mêmes métaux, eau, énergie consommé pour la génération de l’appareil
> et son démantèlement ...
> Dans le numérique, le geste le plus écologique est sûrement à ce jour le
> prolongement de vie des appareils.

Oui une des conclusions du rapport "Pour une sobriété numérique" cf.
https://theshiftproject.org/article/pour-une-sobriete-numerique-rapport-shift/
est bien de faire durer le plus longtemps possible les appareils car ce qui
impacte le plus dans la vie d'un appareil c'est la phase de production.

Romain




--
Sent from: http://gis.19327.n8.nabble.com/France-f5380434.html

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

Re: [OSM-talk-fr] routage surfacique

2019-06-25 Par sujet Antoine Riche via Talk-fr 

Bonjour,
Je raccroche cette échange un peu tardivement...

Le wiki sur la clef area:highway inclut une section 
 
qui dit explicitement que area:highway n'est *pas* fait pour le routing, 
alors que la combinaison de highway=* et area=yes peut être utilisée 
pour le routing surfacique.


Je suis d'accord aussi sur une approche pragmatique : conserver des 
éléments linéaires qui permettent aux principaux outils de calcul 
d'itinéraires de fonctionner, sans pour autant tracer toutes les routes 
possibles. Et permettre aux logiciels qui font du routing surfacique de 
produire des itinéraires plus réalistes. Il faut pour cela connecter les 
routes linéaires aux places surfaciques en partageant un node.


C'est le moment de vous présenter la page de recommandations pour le 
routage piéton 
, 
qui inclut une grosse section sur le routage surfacique, prend en compte 
le indoor comme le outdoor, et inclut une dizaine de schémas. Cette page 
a été présentée lors du SOTM à Montpellier, la présentation 
correspondante est téléchargeable avec ce lien 
.


Je suis preneur de vos retours sur cette page.

Antoine.


Le 19/06/2019 à 17:09, Jérôme Seigneuret a écrit :
Pour l'exemple de Montpellier, les tracés ont été supprimés par mes 
soins puis rajouté par les services de la métropole qui utilise des 
extractions pour ses propres outils de routing (non OSM compliant) et 
qui existe historiquement. Donc les linéaires correspondent à une 
nécessité de leurs outils pour le routing et je pense pour 
l'intermodalité (adresse vers adresse). (non compatible avec de 
l'itinéraire polygonale)


D'où un commentaire dans les tracés.
C'est pas la seul zone en double (voir la zone d'Odysseum) et il y a 
aussi des tracés en double pour palier au problème d'affichage des 
noms (linéaire plus zone en dessous)


L'autres système qui a encore d'autres implications c'est 
*area:highway=**.


Je suis d'accord que la double infos n'a pas d'intérêt et qu'il vaut 
mieux faire un post traitement sous forme de maille avec détection 
d’obstacle pour générer du tracé virtuel plutôt que ce que l'on voit 
sur ta capture d'écran.





Le mer. 19 juin 2019 à 16:54, lenny.libre > a écrit :



Le 18/06/2019 à 20:33, marc marc a écrit :

j'ai bien vu cela (même si n'est pas compréhensible sur la capture)
mais aucun des 4 itinéraires n’atteint l'itinéraire réel
alors que ce sont 2 points de osm de la place.
donc même ce site a du limiter le nuage de way représentant la place.
alors imagine les dégâts si tu routes entre Paris et Monpellier
en surfacique.

A mon âge, je ne suis pas prêt de faire Paris Montpellier à pied
(même quand j'étais jeune, je ne le faisais pas).

Le 18/06/2019 à 20:10, marc marc -marc_marc_...@hotmail.com  
  a écrit :

Le 18.06.19 à 18:48, lenny.libre a écrit :

donc pour ma part, les routes donnant sur une place
se rejoignent en un point + souvent place=square
c'est une représentation imparfaite, mais c'est
à l'heure actuelle sans doute le meilleur compromis

Pour l'anomalie que j'avais signalée, comme le dit Phyks (2 accès
sur la place à quoi bon tracer un chemin fictif qui n'est pas
nécessaire aux calculateurs)

Pourquoi les outils évolueraient-ils, si on leur mâche le
boulot ? 

les évolutions des tags dans osm se font généralement
- soit par des tags supplémentaires (highway puis maxspeed
puis lanes puis turn:lanes par ex)
- soit par un changement de tags (par ex power=sub_Station
divisé en 2 power=substation et power=generator).
Si on suit cette logique, c'est area:highway qui devrait
être utilisé pour une transitions sans dégradation.

casser en disant "yaka faire du routage surfacique",
c'est méconnaître ce que cela implique techniquement :

Tu caricatures ce que je dis, j'ai bien précisé "je sais, je ne
devrais pas en parler ... , je serais bien incapable de faire ces
outils" donc je ne suis peut-être pas technique, mais je remarque
simplement qu'il y a des outils qui font sans ces "chemins"

il y a un gros travail de prétraitement à faire.
je ne retrouve plus hélas l'article qui était publiée sur osmweekly
mais la moindre place avec qlq rues est transformée en un nuage
de way qui connectent tous les paires de points de la surface.
en passant, cela veux dire aussi qu'une place surfacique
avec 8 nœuds consomme 9x l'espace disque et mémoire
comparé à sa version linéaire et ce n'est pas en un claquement
de doigt qu'on augmente la

Re: [OSM-talk-fr] Hameau entre deux communes

2019-06-25 Par sujet osm . sanspourriel 

La réponse est simple : il n'y a pas de frontière officielle pour un
hameau, c'est une frontière floue.

Déjà des panneaux routiers d'entrée des deux côtés c'est du luxe. Je
connais deux hameaux fléchés depuis deux des trois routes qui y mènent
mais pas de panneau sur place. Donc sur le terrain on ne voit si on est
dans un hameau ou dans l'autre.

Donc soit tu mets comme souvent place= sur un nœud bien placé soit tu
mets sur le landuse qui va bien. Les terres agricoles ne sont pas
naturellement partie intégrante du hameau, si en limite un bout de champ
est bâti alors le hameau va s'étendre un peu dans cette direction.

Je conseille de mettre le place sur le landuse car certains nomment le
landuse et doublonnent ainsi l'affichage du nom.

Et si jamais tu inclus ou exclus à tort, le suivant pourra corriger. Le
suivant pouvant être toi.

Jean-Yvon

Le 25/06/2019 à 11:52, Lionel Allorge - lio...@allorge.fr a écrit :

Bonjour,


j'aurais sans doute aussi utilisé les noeuds existants
de la limite de la forêt, prairie etc)

+1

Et sans doute utilisé landuse=residential

Merci pour vos conseils.

Le problème c'est que je ne sais pas s'il existe un moyen de savoir si
tel portion de terre est effectivement une partie du hameau. La seule
mention sur le terrain ce sont les deux panneaux routiers à l'entrée du
hameau.

Librement.

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

Re: [OSM-talk-fr] Josm - raccourcis-clavier de "Télécharger le long"

2019-06-25 Par sujet osm . sanspourriel 

Oups, je cherchais justement à télécharger les données, et je me suis
mélangé les pinceaux.

Mais sur le D comme Down/Bas j'ai du mal à suivre.

Ce n'est pas plutôt D comme Download?

J'ai tendance à préférer conserver les raccourcis quelles que soient les
langues d'interface.

Donc D comme déléchargement, ça me va ;-).

Jean-Yvon

Le 25/06/2019 à 11:43, lenny.libre - lenny.li...@orange.fr a écrit :



Le 25/06/2019 à 09:24, osm.sanspourr...@spamgourmet.com a écrit :


J'utilise la 15155 en français et le raccourci par défaut (que je
n'ai pas changé) est Ctrl+Maj+Bas comme indiqué dans le menu.

Ni Alt+Maj+D ni Alt+Maj+Bas.


j'utilise aussi la 15155 avec W10, le raccourcis-clavier de
"Télécharger le long" c'est bien Alt ...
Celui que tu indiques correspond à "Télécharger les données ..."



Le 24/06/2019 à 22:35, LeTopographeFou - letopographe...@gmail.com a
écrit :

Par contre j'ai essayé dans JOSM 15155, le raccourci est bien
Alt+Maj+D et non pas Alt+Maj+Bas. Donc je pense qu'il faut laisser
Alt+Maj+D. Ou alors je n'ai (encore) rien compris ?


Je devais avoir bu (pourtant je ne m'en souviens pas) il me semblait
l'avoir testé, je viens de retenter et tu as raison c'est bien D


___
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] Hameau entre deux communes

2019-06-25 Par sujet Lionel Allorge 
Bonjour,

>> j'aurais sans doute aussi utilisé les noeuds existants
>> de la limite de la forêt, prairie etc)
> 
> +1
> 
> Et sans doute utilisé landuse=residential

Merci pour vos conseils.

Le problème c'est que je ne sais pas s'il existe un moyen de savoir si
tel portion de terre est effectivement une partie du hameau. La seule
mention sur le terrain ce sont les deux panneaux routiers à l'entrée du
hameau.

Librement.

-- 
Lionel Allorge
Wikimedia France : http://wikimedia.fr
April : http://www.april.org
OpenStreetMap France : http://www.openstreetmap.fr/

« Je vais le renvoyer tout droit à la maison mère,
au terminus des prétentieux »
Les tontons flingueurs

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

Re: [OSM-talk-fr] Josm - raccourcis-clavier de "Télécharger le long"

2019-06-25 Par sujet lenny.libre 


Le 25/06/2019 à 09:24, osm.sanspourr...@spamgourmet.com a écrit :


J'utilise la 15155 en français et le raccourci par défaut (que je n'ai 
pas changé) est Ctrl+Maj+Bas comme indiqué dans le menu.


Ni Alt+Maj+D ni Alt+Maj+Bas.

j'utilise aussi la 15155 avec W10, le raccourcis-clavier de "Télécharger 
le long" c'est bien Alt ...

Celui que tu indiques correspond à "Télécharger les données ..."


Le 24/06/2019 à 22:35, LeTopographeFou - letopographe...@gmail.com a 
écrit :
Par contre j'ai essayé dans JOSM 15155, le raccourci est bien 
Alt+Maj+D et non pas Alt+Maj+Bas. Donc je pense qu'il faut laisser 
Alt+Maj+D. Ou alors je n'ai (encore) rien compris ?


Je devais avoir bu (pourtant je ne m'en souviens pas) il me semblait 
l'avoir testé, je viens de retenter et tu as raison c'est bien D


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

Re: [OSM-talk-fr] Josm - traduction du logiciel - couper le chemin

2019-06-25 Par sujet osm . sanspourriel 

J'utilise la 15155 en français et le raccourci par défaut (que je n'ai
pas changé) est Ctrl+Maj+Bas comme indiqué dans le menu.

Ni Alt+Maj+D ni Alt+Maj+Bas.

Le 24/06/2019 à 22:35, LeTopographeFou - letopographe...@gmail.com a écrit :

Par contre j'ai essayé dans JOSM 15155, le raccourci est bien
Alt+Maj+D et non pas Alt+Maj+Bas. Donc je pense qu'il faut laisser
Alt+Maj+D. Ou alors je n'ai (encore) rien compris ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr