Bonjour Philippe, encore content de découvrir une rue (Rue René Dumont) remise en l'état des anciennes images aériennes... Si tu constates qu'il existe des différences entre OSM et les images aériennes, vérifie la date des images et celles des groupes de modifications. Surprise, des fois des contributeurs se sont embêtés à faire des relevés pour ajouter JUSTEMENT ce qui ne se voit pas sur les images aériennes. J'ai habité deux ans dans cette rue, donc voir les tracés bousillés par du chair mapping c'est énervant. Merci de remettre au propre maintenant que les images aériennes sont à jour. Et pas de "c'est pas moi", les modifications de ce changesets sont visibles ici : https://nrenner.github.io/achavi/?changeset=61742880 et on voit bien la suppression des voies de parking.
Adrien (agacé).

Bonjour, bienvenu dans la communauté OpenStreetMap. Vous avez ajouté un parc sur cette zone, mais il ne semble pas qu'il y ait quelque chose de la sorte à cet endroit. Si vous avez des questions sur le fonctionnement de la communauté et l'édition des données, je reste à disposition.

Je crois que c'était un atelier dans le sens réparation, avec des outils classiques. Mais pas certain.

Hello, sorry about that, some manipulation error. Just fixed it, thanks for pointing it out :-)

Il vaut mieux éviter effectivement d'utiliser Google Street View pour contribuer. Côté Mapillary vous avez le droit car les images sont sous licence libre et Mapillary autorise clairement la contribution OpenStreetMap. La couverture n'est pas exhaustive mais comme pour OSM, c'est au gré du travail des contributeurs bénévoles.

Je ne sais pas pourquoi elles ont été enlevées, mais si les informations sont toujours d'actualité, rien n'empêche de les remettre.

Merci pour ce retour à la raison :-) Je suis certain qu'il y a des façons de répondre aux problématiques que tu poses (que ce soit par de l'analyse topologique des données, ou quand c'est impossible par l'ajout de tags). Et c'est mieux d'y répondre collectivement. Seul on va plus vite, ensemble on va plus loin ;-)

Justement il aurait pas fallu basculer, dans les tags OSM on peut ajouter des tags autant que l'on souhaite, mais pas changer les valeurs existantes sauf si ça se justifie, comme le terrain qui change ou une valeur évidemment inadaptée (chemin piéton marqué comme autoroute). On se doit d'assurer une certaine rétro-compatibilité, même si certaines sémantiques sont imparfaites.

Ici c'est un bon exemple de bretelles pas du tout accessibles en vélo/piéton. Primary implique que c'est possible, là où trunk_link c'est assez clair que non. D'où la nécessité de rebasculer, on a déjà assez souvent des accidents vélos, autant ne pas envoyer les cyclistes là où c'est dangereux.

Puis niveau bretelles la question vraiment à se poser c'est qui peut y accéder :
- Si c'est uniquement des véhicules motorisés (voiture/camion) -> trunk_link ou plus
- Si c'est tout type (vélo/piéton/...) : à la limite on s'en fiche de prendre la route de début ou fin
Et en l'état les modifs type porte de villejean en highway=primary, bah non en vélo j'aurais assez peur de mourir. Alors que dans rennes une highway=primary reste accessible pour du vélo.

J'ai modifié les bretelles mais pas changé leur tag highway=*. Puis c'est discutable sur des primary/secondary/tertiary, moins sur du motorway/trunk. Théoriquement ça doit pouvoir se calculer en suivant les étapes suivantes :
- Télécharger un extrait OSM sur Geofabrik
- Filtrer les routes avec Osmosis
- Monter ça en base avec osm2pgrouting
- Puis écrire la requête SQL pour voir ce qu'il y a comme route au début et à la fin d'une voie en *_link
- Et enfin sortir les chiffres
J'ai pas spécialement le temps de m'y pencher, mais ça reste dans les choses faisables. Même si ce point reste à clarifier, ça ne remet pas en question les points évoqués précédemment.

C'est à dire ? Une bretelle qui lie trunk et secondary serait notée secondary_link au lieu de trunk_link ? Si c'est ça pareil c'est pas documenté en ce sens, et je suis preneur de stats fiables sur le sujet s'il y en a.

Ma façon de voir les choses :
- Ajouter des nouveaux tags : pourquoi pas, en les documentant quelque part (sur le wiki c'est bien).
- Modifier sans consensus des tags établis depuis bien trop longtemps : non, juste non.
Donc pour les *_link pareil, remettre les tags standards oui. Après qu'il y ait des tags supplémentaires pourquoi pas. S'ils présentent un intérêt, la communauté s'en saisira et leur usage se répandra. Une application concrète de la théorie de l'évolution :-)

Bonjour, je vois que de nombreuses routes sont récemment passées en highway=trunk (genre la D29). Ces modifications font l'objet d'une discussion controversée sur les listes de diffusion. Ce serait possible de ne pas modifier en masse en attendant que la question soit clarifiée ? Et possiblement annuler les modifications récentes ? Ça évitera de casser les nombreux outils qui s'appuient sur les définitions établies. Merci !

Super, merci pour ta compréhension. N'hésite pas à faire remonter l'incohérence potentielle de l'analyse JOSM de manière à ce que ça n'arrive pas à d'autres contributeurs :-)

Effectivement les codes postaux mériteraient d'avoir leur propre découpage, mais si je me souviens bien le découpage des zones des codes postaux n'est pas précis. On peut simplement le reconstituer par regroupement au niveau des adresses. En tout cas le fait de le préciser à la commune ne me paraît pas gênant, c'est un premier niveau d'information, que l'on pourra améliorer à l'avenir (y compris dans les cas où l'on a plusieurs codes pour une commune).

Au-delà du choix du tag (plutôt à discuter sur une liste de diffusion), c'est plutôt la modification massive qui n'est pas l'objet du groupe de modification qui m'embête. J'entends l'argument technique de l'analyse JOSM, mais à partir du moment où il y a consensus de fait sur le addr:postcode au niveau national, ça fait clairement tâche sur le département. Sans compter la complexité pour les réutilisateurs qui doivent gérer n tags différents. Tu peux remettre addr:postcode à la place de postal_code en attente d'une discussion plus formelle sur le sujet ?

Et pourquoi des horaires d'ouverture sur la limite de Paramé, à quoi ça correspond ?
relation/5834867

Bonjour, est-ce que c'était bien utile de changer tous les addr:postcode en postal_code, en sachant que leur usage n'est pas hyper répandu :
https://taginfo.openstreetmap.fr/keys/postal_code#map
Comparé à :
https://taginfo.openstreetmap.fr/keys/addr:postcode#map

Plusieurs solutions existent pour faire ressortir des points d'intérêts contenus dans OSM sur une carte : uMap, Leaflet et Overpass... Si vous voulez en discuter plus en détail, vous pouvez m'envoyer un message privé.