Re: [OSM-talk-fr] barrier=block infranchissable à vélo malgré bicycle=yes

2020-01-03 Par sujet Gautier Pelloux-Prayer via Talk-fr

Bonjour,

Pas de soucis particulier ici. BRouter privilégie un autre itinéraire, 
car la route au sud de la "barrière" est en sens inverse vélo, le profil 
par défaut "cyclotourisme" pénalise fortement cela.


1. Si on inverse le chemin, il prend la barriére sans soucis.

2. Si on demande à brouter d'utiliser une alternative (en haut à gauche, 
au même endroit que le choix du profil), il prend la barrière.


3. Si on utilise un autre profil (par exemple "chemin le plus court", il 
y passe aussi).


Pour info, Brouter utilise le chemin avec le plus faible coût (on peut 
le voir en bas de la page).


On peut aussi voir le détails du calcul avec la 3ème icône à droite :

Bonne journée,

Le 02/01/2020 à 18:27, Florimond Berthoux a écrit :

Pour répondre à ta question, oui c'est la bonne façon de tagguer.

Ça ne serait pas dû au bout de rue piétonne ?
(que je trouve un peu inutile ici par ailleurs)

Le jeu. 2 janv. 2020 à 12:32, Shohreh  a écrit :

Oui, c'est bizarre. Si on étend le parcours, il fait faire tout le tour
plutôt que d'aller tout droite dans cette rue calme. C'est pour ça que j'ai
pensé à cette barrière au milieu, mais ça ne semble pas être ça
l'explication.

Merci.



--
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



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


Re: [OSM-talk-fr] Manque d'attribution (était 15 bougies pour OSM !)

2019-08-12 Par sujet Gautier Pelloux-Prayer via Talk-fr

Bonjour,

N'est-il pas possible de semi-automiser ce processus, par exemple en 
vérifiant le top 500 des sites utilisant le + les tuiles osm-fr ?


On 12/08/2019 11:33, deuzeffe wrote:

On 12/08/2019 11:26, Cédric Frayssinet wrote:


Il ne te reste plus qu'à renseigner
https://wiki.openstreetmap.org/wiki/FR:Lacking_proper_attribution

(si ce n'est déjà fait)

C'est fait, 


Merci à toi.


je n'avais pas connaissance de ce suivi.


Maintenant, oui :)



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


Re: [OSM-talk-fr] Bug JOSM avec gros fichiers du cadastre

2019-01-25 Par sujet Gautier Pelloux-Prayer via Talk-fr
Vu la position de l'exception, il semblerait que ce soit Marseille 8eme : 
http://cadastre.openstreetmap.fr/data/013/80208-MARSEILLE%208EME-houses.osm

A+

Le 25 janvier 2019 23:46:02 GMT+01:00, Vincent Privat 
 a écrit :
>Hello,
>Si la personne anonyme qui a créé ce bug me lit sur talk-fr:
>https://josm.openstreetmap.de/ticket/17242
>
>J'aurais besoin du fichier .osm.
>Merci,
>Vincent
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Suivi de l'état du bâti par rapport au cadastre

2018-12-19 Par sujet Gautier Pelloux-Prayer

Bonjour à tous,

Une version 1.1.0 de l'outil https://cadastre.damsy.net est sortie. 
Celle-ci apporte, entre autres :


- un mode d'emploi interactif s'affichant automatiquement à la 1ère visite ;

- une barre de recherche ;

- des raccourcis claviers pour optimiser le workflow des contributeurs 
les plus chevronnés ;) ;


- puis comme d'habitudes, des corrections de bugs, optimisations, …

Pour information, il y a en France *193 communes dont le bâti n'a jamais 
été importé* dans OSM (couleur rose sur la carte) ! C'est relativement 
simple à faire, si l'on maîtrise JOSM… Avis aux cartographes ;-)



On 29/10/2018 18:19, Gautier Pelloux-Prayer wrote:


Bonjour,

Un certain nombre d'outils de QA existent déjà sur OSM, alors pourquoi 
ne pas en rajouter un nouveau ?!


https://cadastre.damsy.net/ est une carte de suivi du bâti, commune 
par commune, afin de connaître de quand date le dernier import du 
cadastre réalisé. Cela permet de détecter :


- les villes qui n'ont jamais été importées (0 bâtiments + cadastre 
vectoriel disponible)


- les communes qui n'ont /a priori/ jamais été importés, mais où du 
bâti existe. Souvent, on trouve dans ces communes quelques bâtiments 
dessinés à la main (IGN, Bing)… mais il manque 90+% du bâti.


- et sinon la date d'import des autres villes (en se basant sur le tag 
/source/ des bâtiments).


Par ailleurs, le site permet d'ouvrir dans un JOSM préconfiguré le 
bâti d'une commune (généré via https://cadastre.openstreetmap.fr, en 
attendant que les fichiers Etalab soit prêts ?), afin de le mettre à 
jour (via le plugin Conflation, ou la méthode de votre choix..).


En espérant que ça puisse servir à d'autres, je m'en sers 
personnellement pour dégommer du rose et du gris ;-). Retours 
bienvenus, ici ou sur https://gitlab.com/bagage/cadastre-conflation/issues


Bonne journée,


___
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] Suivi de l'état du bâti par rapport au cadastre

2018-11-04 Par sujet Gautier Pelloux-Prayer
Bonsoir, et merci Marcmarc pour les remarques ! Je tâche d'y répondre ci 
dessous.


À bientôt :),

On 29/10/2018 19:25, marc marc wrote:

Bonjour,

Le 29. 10. 18 à 18:19, Gautier Pelloux-Prayer a écrit :

Un certain nombre d'outils de QA existent déjà sur OSM, alors pourquoi
ne pas en rajouter un nouveau ?!

hasard de calendrier, hier je me disais que je venais de trouver l'avant
dernière pièce manquante pour faire "un peu mieux que "trop à la main"
https://github.com/sebastien-bugzilla/BatiOsm
http://forum.openstreetmap.fr/viewtopic.php?f=5=1762
l'autre pièce manquante c'était la tienne :)


https://cadastre.damsy.net/ est une carte de suivi du bâti, commune par
commune, afin de connaître de quand date le dernier import du cadastre
réalisé. Cela permet de détecter :

double bravo !
- d'avoir eu l'idée et de l'avoir fait
- d'avoir éviter de recoder tous les briques au profit d'une utilisation
de l'existant (cela permet qu'une amélioration des ces briques profite
aussi à ton interface)


- les villes qui n'ont jamais été importées (0 bâtiments + cadastre
vectoriel disponible)

j'ai pas trop compris comment on obtenait cette liste.
il y a l'air d'avoir 0.3% de commune concernée.
mais soit elles sont trop petite pour les trouver avec le zoom affichant
la France entière, soit j'ai raté qlq chose :)
Pour le moment, le seul moyen de les retrouver en zoomant sur la carte. 
Probablement qu'une liste sera disponible plus tard si nécessaire, si 
l'outil est utile.



- les communes qui n'ont /a priori/ jamais été importés, mais où du bâti
existe. Souvent, on trouve dans ces communes quelques bâtiments dessinés
à la main (IGN, Bing)… mais il manque 90+% du bâti.

l'outil BatiOsm (ou une comparaison sommaire entre le nombre de bâtiment
osm et celui dans l'extract cadastre osm.fr) permettrait de se faire une
idée des communes où le manque est le plus criant.
On peux aussi encore plus sommairement se baser sur la présence ou non
de l'extract sur le serveur.
En effet, actuellement le calcul de la date d'import d'une commune est 
très basique. De plus, une commune importée il y a longtemps n'a pas 
forcément un énorme besoin de mise à jour (village pas dynamique qui 
change peu par ex). Si l'outil est utile/utilisé, je me pencherai sur 
une intégration de BatiOsm, merci pour la piste !



- et sinon la date d'import des autres villes (en se basant sur le tag
/source/ des bâtiments).

cette méthode histoire étant de + en + dépréciée,
une futur amélioration pourrait tenir compte de la date de modif ou
d'analyser l'historique (même si c'est bcp plus long)
Oui mais c'est aussi la plus simple à scripter. À terme je pense plutôt 
utiliser la date de dernière modification du bâtiment pour faire foi, 
parce que finalement certaines personnes ne sourcent pas le cadastre 
(c'est mal), ou avec la mauvaise année… L'idée, c'est de savoir quand 
est-ce que les bâtiments ont été mis dans OSM.



les fichiers Etalab

l'an passé il était urgent d'attendre.
quel est la situation actuelle ? quelqu'un les utilise ?
sur le wiki, si c'est documenté, c'est "sous le radar"
dans les pages concernant le cadastre

Cordialement,
Marc
___
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] Suivi de l'état du bâti par rapport au cadastre

2018-11-04 Par sujet Gautier Pelloux-Prayer


En effet, pour l'instant la date calculée correspond à la date 
majoritaire de l'ensemble des bâtiments dans la commune. En cliquant sur 
la commune, tu peux voir le détail des imports par année et ici tu 
devrais trouver une majorité des bâtiments datant de 2010, mais avec un 
certain nombre de bâtiments en 2017,2018 (lorsque /source=cadastre/ sera 
supporté sur un lot, voir mon autre message).


On 03/11/2018 22:16, osm.sanspourr...@spamgourmet.com wrote:


J'abonde pour les bravos.

Le 29/10/2018 à 19:25, marc marc - marc_marc_...@hotmail.com a écrit :

- et sinon la date d'import des autres villes (en se basant sur le tag
/source/  des bâtiments).

cette méthode histoire étant de + en + dépréciée,
une futur amélioration pourrait tenir compte de la date de modif ou
d'analyser l'historique (même si c'est bcp plus long)

Histoire de comprendre, j'ai regardé ma commune : dernier import 2010.
En fait depuis j'ai ajouté "à la main" quelques lotissements et 
traçant depuis la couche cadastre.
Les bâtiments ajoutés ainsi je ne mets source=cadastre qu'au niveau du 
lot (*).


Marc, pour les imports, on pourrait tout-à-fait faire une exception et 
laisser les source sur l'objet pour les imports de bâtis du cadastre.


Jean-Yvon

(*) pourquoi dire changeset alors qu'on télécharge un lot de 
modifications ?
Lot n'est pas utilisé dans notre contexte alors pourquoi ne pas 
l'utiliser en lieu et place de changeset, mot long en étranger ;-) ?


___
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] Suivi de l'état du bâti par rapport au cadastre

2018-10-29 Par sujet Gautier Pelloux-Prayer

Bonjour,

Un certain nombre d'outils de QA existent déjà sur OSM, alors pourquoi 
ne pas en rajouter un nouveau ?!


https://cadastre.damsy.net/ est une carte de suivi du bâti, commune par 
commune, afin de connaître de quand date le dernier import du cadastre 
réalisé. Cela permet de détecter :


- les villes qui n'ont jamais été importées (0 bâtiments + cadastre 
vectoriel disponible)


- les communes qui n'ont /a priori/ jamais été importés, mais où du bâti 
existe. Souvent, on trouve dans ces communes quelques bâtiments dessinés 
à la main (IGN, Bing)… mais il manque 90+% du bâti.


- et sinon la date d'import des autres villes (en se basant sur le tag 
/source/ des bâtiments).


Par ailleurs, le site permet d'ouvrir dans un JOSM préconfiguré le bâti 
d'une commune (généré via https://cadastre.openstreetmap.fr, en 
attendant que les fichiers Etalab soit prêts ?), afin de le mettre à 
jour (via le plugin Conflation, ou la méthode de votre choix..).


En espérant que ça puisse servir à d'autres, je m'en sers 
personnellement pour dégommer du rose et du gris ;-). Retours bienvenus, 
ici ou sur https://gitlab.com/bagage/cadastre-conflation/issues


Bonne journée,

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


Re: [OSM-talk-fr] Rendu avec relief sur osm.org

2018-03-28 Par sujet Gautier Pelloux-Prayer

Bonjour Christian et la liste,

A-t-on des nouvelles sur un éventuel service de rendu du relief ? Ça 
serait vraiment une très bonne nouvelle.



On 06/01/2018 19:36, Christian Quest wrote:
J'ai sorti du congélateur ce que j'avais fait l'hiver dernier sur 
l'ombrage...


STRMv3 est complet, j'avais calculé l'ombrage transparent, par contre 
certaines dalles de 10° x 10° étaient trop volumineuses et avaient 
dépassé les 2Go d'où un ombrage incomplet.


Je regarde pour corriger ça, sinon 95% du boulot est fait.

Pour info, l'image totale fait 1299600 x 414000 pixels, soit 538 
milliards de pixels ;)
Le dossier avec les tuiles finales et leurs overview pèse 133Go... 
tout le dossier du projet fait presque 600Go.


--
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] Modification du nom de plusieurs communes

2017-07-25 Par sujet Gautier Pelloux-Prayer

Bonjour,

Merci pour la confirmation et les indications, j'ai donc envoyé afin 
d'avertir le contributeur des problèmes - peut-être le croiserons-nous 
sur ce fil ;-).


Bon vèspre,

On 25/07/2017 16:49, Christian Rogel wrote:
Le 25 juil. 2017 à 00:28, Gautier Pelloux-Prayer <gaut...@damsy.net 
<mailto:gaut...@damsy.net>> a écrit :


Bonsoir,

La semaine dernière [1], un utilisateur "oc-passalaiga" a modifié un 
certain nombre de communes pour rajouter le nom Occitanais (name:oc). 
Il en a aussi profité pour modifier le nom (name) afin de contenir 
les 2 valeurs name et name:oc. Par exemple "Alixan" devient "Alixan / 
Aleissan".


Je pense que la seconde partie du changement (modification de la clé 
name) est en trop - mais n'étant pas forcément aux faits des bonnes 
pratiques, je poste ce message… Par ailleurs, peut-être que 
quelqu'un(s) a plus d'info sur ce projet ? Si mes doutes sont 
confirmés, j'enverrai un message directement sur les changesets en 
question.
[1] : 
http://www.openstreetmap.org/changeset/50324439#map=9/44.6070/5.1035


[2] : http://www.openstreetmap.org/relation/63575#map=12/44.9843/5.0167


Bonjour,

Ces erreurs sont, sans doute, liées à une découverte récente (le mois 
dernier) par les occitanistes bénévoles de l'Institut d'estudis 
occitans (IEO - Toulouse) du potentiel d'OSM pour obtenir une carte 
localisée.
Cette association qui couvre les 11 départements de l'aire occitane 
gère une base de 56 000 toponymes qu'elle a l'intention d'injecter 
progressivement dans OSM.
Les doublons relèvent d'un enthousiasme qu’on a vu quelquefois chez 
nous  en Bretagne.


A l'exemple (il s’agit plutôt d'imitation) du site d'OpenStreetMap e 
brezhoneg <http://www.openstreetmap.bzh> (dont je suis un des 
promoteurs), l'IEO a créé le site Openstreetmap en occitan 
<http://openstreetmap-oc.org/> (openstreetmap-oc.org 
<http://openstreetmap-oc.org>) qui servira de cadre à une future carte 
tout en occitan.


Tu peux donc passer un message à oc-passalaiga et, de mon côté, je 
signalerai à l'IEO qu'il indique bien à ses correspondants en que 
"name" ne doit contenir que le nom officiel.


Dans la mesure où notre petite équipe d’Openstreetmap e brezhoneg a 
acquis un savoir-faire technique, nous sommes à l’écoute de tous ceux 
que la question des langues régionales dans OSM intéresse.
Contact à daremp...@openstreetmap.bzh 
<mailto:daremp...@openstreetmap.bzh> .



On peut espérer que les localiseurs de toponymes iront un au delà de 
leur champ d'intérêts et amélioreront, au passage, le rendu de leurs 
secteurs géographiques.



Christian R.


___
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] Modification du nom de plusieurs communes

2017-07-24 Par sujet Gautier Pelloux-Prayer

Bonsoir,

La semaine dernière [1], un utilisateur "oc-passalaiga" a modifié un 
certain nombre de communes pour rajouter le nom Occitanais (name:oc). Il 
en a aussi profité pour modifier le nom (name) afin de contenir les 2 
valeurs name et name:oc. Par exemple "Alixan" devient "Alixan / Aleissan".


Je pense que la seconde partie du changement (modification de la clé 
name) est en trop - mais n'étant pas forcément aux faits des bonnes 
pratiques, je poste ce message… Par ailleurs, peut-être que quelqu'un(s) 
a plus d'info sur ce projet ? Si mes doutes sont confirmés, j'enverrai 
un message directement sur les changesets en question.


Merci,

[1] : http://www.openstreetmap.org/changeset/50324439#map=9/44.6070/5.1035

[2] : http://www.openstreetmap.org/relation/63575#map=12/44.9843/5.0167


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


Re: [OSM-talk-fr] Voir ce qui a été supprimé (et le remettre) ?

2017-05-24 Par sujet Gautier Pelloux-Prayer

Bonjour,

(puisque c'est moi le fautif, j'en profite pour apporter une solution; 
en l'occurence celle que j'ai utilisé pour corriger le soucis).


1. Télécharger la zone au format .pbf à une version avant la modif 
fautive (par ex via http://download.geofabrik.de/europe/france/).


2. Réduire le PBF afin de n'avoir que la zone qui nous intéresse via 
osmconvert. On peut récupérer la bounding box via osm.org 
(http://www.openstreetmap.org/export#map=16/44.8635/4.9451) :


$ osmconvert rhone-alpes-170301.osm.pbf -o=beaumonvalence-170301.osm.pbf 
-b 4.9282,44.8570,4.9619,4.9619


2. Ouvrir le PBF dans JOSM via le plugin "PBF"

3. Télécharger dans un autre calque la version actuelle et les comparer

4. Récupérer ce qui est intéressant dans l'ancien calque pour le mettre 
dans la version actuelle.



Je ne connaissais pas achavi, c'est intéressant.

Désolé pour la casse,

Gautier

On 24/05/2017 14:45, pepilepi...@ovh.fr wrote:


Bonjour,

Dans un bon gros changeset (5000 noeuds et 3000 chemins) quelqu'un a 
supprimé des chemins que j'avais pris la peine d'arpenter avec mon GPS.


Évidemment quant on clique sur l'identifiant d'un tel chemin on tombe 
sur la page qui dit "supprimé il y a n jours par..."


Comment peut-on retrouver ces chemins pour annuler la suppression ou 
les recréer facilement à l'identique ? Exemple 
https://www.openstreetmap.org/changeset/48771059 .


Merci,

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

2016-12-23 Par sujet Gautier Pelloux-Prayer
Serait-il possible d'ajouter le rendu des pistes de course : course 
équestre (leisure=horse_racing) ou piste d'athlétisme et de course à 
pied (sport=athletics et sport=running), etc. ?
Actuellement elles ne sont pas representées (par ex ici : 
http://umap.openstreetmap.fr/fr/map/preview-rendu-fr-2017_99740#19/45.17942/5.75833 
).



Le ven. 23 déc. 2016 à 20:23, Christian Quest 
 a écrit :
Pour les track/gradeX, j'ai repris les mêmes pointillés que sur le 
rendu international... dans la prochaine livraison...


Le 22 décembre 2016 à 15:40, JB  a écrit :

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





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


Re: [OSM-talk-fr] distance entre deux points sur une route

2016-06-30 Par sujet Gautier Pelloux-Prayer
Je ne sais pas si c'est un besoin utilisateur, mais dans ce cas précis il y a 
brouter dédié au routing vélo : http://brouter.de/brouter-web/ 

Gautier

> On 30 Jun 2016, at 14:41, osm.sanspourr...@spamgourmet.com wrote:
> 
> Certaines fois il est bon de rappeler la question :
> 
> J'aimerais connaître la distance entre deux points sur une relation
> route=bicycle,en l’occurrence la distance entre Nantes et Blain sur la
> Vélodyssée.
> 
> 
> Et oui, j'ose affirmer que le calcul n'est pas à 10 cm près.
> Adrien me démentira si besoin.
> La différence est de l'ordre de 1/3000.
> 0,03 % !
> L'erreur est fonction de la latitude, si tu as des cas pour le nord du 
> rond-point est à une latitude significativement différente du point le plus 
> au sud, je suis preneur.
> Le plus grand rond-point en France est / était celui de Pen Ar C'hleuz. A 
> priori, mais tu te feras un plaisir de le vérifier par le calcul, entre le 
> point le plus au nord 48,4150848, -4,4796283 et le point le plus au sud 
> 48,4140211, -4,4795085 nous restons comme entre Nantes et Blain dans des 
> latitudes où l'approximation reste correcte.
> A cet effet tu mesureras le périmètre avec et sans l'approximation puis avec 
> l'utilisation de la chaussée intérieure et de la chaussée extérieure (3 
> voies) et tu relativiseras alors l'écart.
> 
> 20 km sur 6  km (6366,000 km c'est 40  / pi / 2 c'est à dire la 
> définition initiale du mètre), oui pour un parcours à vélo entre Nantes et 
> Blain (latitude moyenne) c'est négligeable.
> 
> Adrien, je ne sais ajouter des points sur les calculs d'itinéraires d'OSM 
> (juste 2 points).
> Sur Graphhopper, tu peux le faire et en plus tu vois le profil altimétrique 
> et vois que tu ajoutes plusieurs centaines de mètres (290 m de montée, autant 
> de descente) à force de monter et descendre (soit >1 %, à comparer aux 0,03 % 
> des cas extrêmes de Philippe).
> En plus tu vois bien la tâche dans le paysage que constitue le bocage de 
> Notre-Dame-des-Landes ;-).
> 
> Le 30/06/2016 à 13:26, Philippe Verdy - verd...@wanadoo.fr a écrit :
> ___
> 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 langue

2016-01-25 Par sujet Gautier Pelloux-Prayer

Bonjour,

Si cela peut aider au débat, il y a le "même" problème pour les Alpes : 
http://www.openstreetmap.org/relation/2698607


Osmose n'est pas content car on utilise par défaut le nom Anglais, mais 
en même temps je vois pas de bonne solution pour qu'il le soit en 
l'état... ? La solution de ne pas avoir de nom du tout serait pour moi 
la plus logique, mais osmose ne sera toujours pas satisfait il me semble.


Le 25/01/2016 18:37, rainerU a écrit :

Am 25.01.2016 um 13:04 schrieb Dominique Faure:

   name=European route E 54

Pour moi, ce n'est pas la bonne solution. Cela ne fera pas disparaître
le signalement Osmose et cela ne correspond à aucune réalité, car c'est
une route qui passe par l'Allemagne et la France, et elle n'a pas de nom
anglais. La solution qui refléterait le mieux la réalité serait de ne
pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
faut absolument un attribut name=* il faut couper la relation en une
partie française et une partie allemande et les regrouper dans une
relation qui aura comme nom "Route européenne 54 / Europastraße 54".

Le plus simple serait de faire comme pour d'autres routes du même type,
c'est à dire de supprimer tous les attributs name. Si on veut on peut
toujours construire un nom à partir des tags network et ref :

https://www.openstreetmap.org/relation/2148632







___
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 langue

2016-01-25 Par sujet Gautier Pelloux-Prayer
Non, je ne crois pas : 
http://osmose.openstreetmap.fr/fr/map/#zoom=11=45.04=5.4897=Mapnik=T=5060=1%2C2%2C3==


La langue anglaise est bien dans la liste, mais au moins 
osmose.openstreetmap.fr n'est pas content. Ou alors tu parles 
uniquement pour les highways...



Le lun. 25 janv. 2016 à 19:02, Philippe Verdy <verd...@wanadoo.fr> a 
écrit :
Osmose est content quand au moins un des noms "name:lang=*" 
correspond à celui indiqué dans "name=*".


Bref renseigner un nom dans "name=*" (langue quelconque) et dans 
"name:fr=*"


Le 25 janvier 2016 à 18:56, Gautier Pelloux-Prayer 
<gaut...@damsy.net> a écrit :

Bonjour,

Si cela peut aider au débat, il y a le "même" problème pour les 
Alpes : http://www.openstreetmap.org/relation/2698607


Osmose n'est pas content car on utilise par défaut le nom Anglais, 
mais en même temps je vois pas de bonne solution pour qu'il le soit 
en l'état... ? La solution de ne pas avoir de nom du tout serait 
pour moi la plus logique, mais osmose ne sera toujours pas satisfait 
il me semble.



Le 25/01/2016 18:37, rainerU a écrit :

Am 25.01.2016 um 13:04 schrieb Dominique Faure:

   name=European route E 54
Pour moi, ce n'est pas la bonne solution. Cela ne fera pas 
disparaître
le signalement Osmose et cela ne correspond à aucune réalité, 
car c'est
une route qui passe par l'Allemagne et la France, et elle n'a pas 
de nom
anglais. La solution qui refléterait le mieux la réalité serait 
de ne

pas avoir un attribut name=* mais seulement name:fr et name:de. S'il
faut absolument un attribut name=* il faut couper la relation en une
partie française et une partie allemande et les regrouper dans une
relation qui aura comme nom "Route européenne 54 / Europastraße 
54".


Le plus simple serait de faire comme pour d'autres routes du même 
type,
c'est à dire de supprimer tous les attributs name. Si on veut on 
peut

toujours construire un nom à partir des tags network et ref :

https://www.openstreetmap.org/relation/2148632







___
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] Le Calque Cadastre le retour ;-)

2015-11-29 Par sujet Gautier Pelloux-Prayer

Bonsoir,

Le cadastre semble être HS à nouveau.

Cordialement

Le lun. 16 nov. 2015 à 22:54, Jérôme Seigneuret 
 a écrit :

Pour info,
Le cadastre est de nouveau disponible (TMS)

Bonne soirée Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Parking/Aire de covoiturage

2015-11-15 Par sujet Gautier Pelloux-Prayer

Bonsoir,

Pour info, j'ai donc créé la discussion sur le wiki : 
https://wiki.openstreetmap.org/wiki/Talk:Key:hov


Gautier

On Wed, Nov 11, 2015 at 8:06 PM, Jérôme Seigneuret 
<jseigneuret-...@yahoo.fr> wrote:



Le 11 novembre 2015 15:21, Axelos <axe...@broman.fr> a écrit :

Gautier wrote
> Pour la valeur de park_ride, je ne comprend pas la valeur "hov". 
Le wiki

> dit :
>  - valeur : "yes/no;bus;train;tram;metro;ferry"
>  - description : "Parc relais


Comme je disais c'est une proposition. Je le vois juste ainsi. Donc 
à ajouter au wiki en discussion. hov est un mode de déplacement 
tous comme les autres. Tu viens en voiture et tu pars par une autre 
en covoiturage. Donc c'est une forme de Parc Relais.
A défaut, mettre yes. Qu'en est-il pour les voies de taxi comme pour 
les aéroports? Es-ce aussi à ajouter à park_ride ? je me pose la 
question


> Si je comprend bien, c'est donc les transports qui sont disponibles
> lorsqu'on vient dans ces parcs relais. Il faudrait donc rajouter 
une
> valeur "hov" ? Si oui, ça se passe comment ? On le rajoute 
directement

> sur le wiki ou il y a une "procédure" (discussion) avant ?

Oui une discussion c'est mieux et sur la page anglaise

> Pour la clé access, je n'ai rien trouvé au niveau législatif 
sur les

> aires de covoiturage (ces places de parking sont-elles réellement
> limitées aux utilisateurs du covoiturage ?). Quelle est la raison 
de ton

> choix pour cela ?
Oui, il faudrait un peut plus d'info pour savoir si c'est un parking 
réservé au covoiturage. Si d'autre véhicule peuvent se garder ou 
si c'est juste une zone de dépose minute sur une voie réservé a 
covoiturage...



HOV : High-Occupancy Vehicle
En français : voie réservée aux véhicules à occupation multiple
Je pars du principe que pour covoiturer il faut être deux donc si tu 
pars avec quelqu'un soit tu fait du covoiturage du VTC ou taxi (si tu 
as la licence) ;-)



Pour l’accès, c'est vrai que l’intérêt de access=hov est 
assez limité.

Sauf si c'est un parking réservé

Toutefois il n'y a pas de présence de restriction d’accès tel 
que access=no,

ce qui n'interdit pas les nons covoitureurs d'accéder au parking.
En effet mais tu peux aussi le faire directement sur certaines places 
comme pour l'accès aux handicapés ou réservé aux familles.


Dans le genre j'y préfère plus un hov=designated : ça n'interdit 
pas les
autres usagés non plus, mais ça décrit que la voie est 
principalement dédié

aux covoitureurs.


Si tel est le cas je suis pour

Jérôme
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


Re: [OSM-talk-fr] Parking/Aire de covoiturage

2015-11-11 Par sujet Gautier

Bonjour,

Pour la valeur de park_ride, je ne comprend pas la valeur "hov". Le wiki 
dit :

- valeur : "yes/no;bus;train;tram;metro;ferry"
- description : "Parc relais 
<http://fr.wikipedia.org/wiki/Parc_relais>. Les valeurs précisent des 
moyens de transports qui y sont connectés. Dans le doute, mettez /yes/. 
(voir Proposal 
<http://wiki.openstreetmap.org/wiki/Proposed_features/Park_and_Ride>)"
Si je comprend bien, c'est donc les transports qui sont disponibles 
lorsqu'on vient dans ces parcs relais. Il faudrait donc rajouter une 
valeur "hov" ? Si oui, ça se passe comment ? On le rajoute directement 
sur le wiki ou il y a une "procédure" (discussion) avant ?


Pour la clé access, je n'ai rien trouvé au niveau législatif sur les 
aires de covoiturage (ces places de parking sont-elles réellement 
limitées aux utilisateurs du covoiturage ?). Quelle est la raison de ton 
choix pour cela ?


Gautier

On 10/11/2015 12:51, Jérôme Seigneuret wrote:

Bonjour,

J'ai fait une proposition:

amenity=parking (ou parking_space)
park_ride <http://wiki.openstreetmap.org/wiki/Key:park_ride>=hov
name=Aire de Covoiturage
access=hov

Je vous invite à voir le contenu du tag hov 
<http://wiki.openstreetmap.org/wiki/Key:hov>


Je pense qu'il faudrait aussi compléter la page 
http://wiki.openstreetmap.org/wiki/Key:access


Cette clé doit être présente (donc à ajouter) dans la liste 
"/motor_vehicle 
<http://wiki.openstreetmap.org/wiki/Key:motor_vehicle>=*// (category: 
any motorized vehicle) /-->***/By use/*

*/
/*
Jérôme

Le 10 novembre 2015 09:20, Nicolas Dumoulin 
<nicolas_openstreetmap@dumoulin63.net 
<mailto:nicolas_openstreetmap@dumoulin63.net>> a écrit :


Salut,

Le lundi 9 novembre 2015 20:08:01 Gautier a écrit :

> Nicolas Dumoulin, sur le forum, m'a proposé la solution

> http://www.openstreetmap.org/way/128277712 à savoir :

Je reposte ici mon dernier message où je donne l'origine de mon
choix d'époque :

http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Carpool

Aujourd'hui, ça n'est plus très approprié, je suis preneur de
mieux :-)

-- 


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
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] Parking/Aire de covoiturage

2015-11-09 Par sujet Gautier

Bonsoir,

Je me permet de copier une question que j'ai posé sur le forum 
(http://forum.openstreetmap.fr/viewtopic.php?f=2=2338=9737#p9737), 
en espérant qu'une solution soit trouvée :


Il existe de plus en plus de parkings dédiés au covoiturage, mais je 
n'ai rien trouvé pour cartographier ces éléments proprement. Le plus 
proche serait d'utiliser amenity=car_sharing 
 mais 
ce n'est pas du covoiturage à proprement parler.
La plupart des parkings de covoiturage sont de simples parkings avec 
name=Aire de covoiturage ou name=Parking de covoiturage. Peut-on faire 
mieux ?


Nicolas Dumoulin, sur le forum, m'a proposé la solution 
http://www.openstreetmap.org/way/128277712 à savoir :


- amenity=parking
- carpool=designated
- name=Aire de covoiturage
- park_ride=yes

Qu'en pensez-vous ?
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr


[OSM-talk-fr] Quelques questions sur le fonctionnement de BANO

2015-10-05 Par sujet Gautier

Bonsoir à tous,

Je suis tombé par hasard sur BANO il y a quelques temps et j'y ai 
contribué modestement au niveau de ma commune de résidence ainsi que les 
alentours.


J'ai pris connaissance du projet en lisant le très bon article BANO ? 
BANCO ! puis la page dédiée du wiki 
(http://wiki.openstreetmap.org/wiki/WikiProject_France/WikiProject_Base_Adresses_Nationale_Ouverte_%28BANO%29).


Même si Vincent a répondu à quelques-unes de mes questions sur IRC 
(merci à toi !), certaines restent en suspend à ce jour :


- "BANO servira en temps utile à aider l'alimentation d'OpenStreetMap en 
adresses, mais [...] le schéma d'étiquetage des adresses n'a pas encore 
atteint la maturité permettant pour qu'une saisie massive soit 
suffisamment harmonieuse et utile pour le plus grand nombre d'usages 
envisagés. Cette réflexion est en cours."
Où en est la réflexion aujourd'hui ? Est-ce qu'une solution 
"universelle" a été trouvé ? Si oui, va-t-on voir prochainement la 
contribution de BANO dans OSM (numérotage des maisons principalement) ?


- Est-ce possible de relancer la vérification BANO d'une commune 
spécifique sans avoir à attendre le processus automatique de minuit, à 
l'image des tuiles Mapnik pour openstreetmap.org (on peut spécifier 
"/dirty" à la fin d'une tuile pour demander sa régénération par ex : 
http://b.tile.openstreetmap.org/14/8138/5495.png/dirty) ? Sur certaines 
communes à 50 erreurs ou +, j'ai mis 4/5 jours pour tout faire suite aux 
oublis / fautes de frappe.


- Y a t-il d'autres documents de référence autre que l'article du Wiki ? 
(liste bogues connus [github ?], procédure à réaliser dans les 
différents cas, etc.) ?
Même si le wiki est assez complet, j'ai plusieurs fois eu des doutes sur 
la manière de corriger un problème sans trouver de procédure claire 
(notamment pour les lieux dits, mais je n'ai pas osé toucher à ce 
morceau expérimental pour le moment :-) ).


Merci,

Gautier.


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