Merci de ton retour. C'est sûr que le sujet n'est pas simple. Quand tu dis que les arrêts ne sont pas bien localisés, c'est côté OSM ou dans le GTFS ? L'intérêt d'utiliser un outil comme Pic4Review (pic4review.pavie.info) c'est que tu peux repositionner dans l'interface web directement l'arrêt selon ce que tu vois sur la photo et image aérienne. Après c'est à condition d'avoir des photos disponibles, ce qui est pas toujours le cas sur le réseau Illenoo. Si je peux t'aider à faire cette mise à jour fais-moi signe ;-)

Bonjour,
Il y a une raison pour laquelle tu supprimes systématiquement les tags survey:date=* ? Ceux-ci sont documentés et ont leur intérêt : survey:date=* Si c'est suite à une visite terrain, autant mettre à jour la date.
Cordialement.

Bonjour,
Merci pour votre contribution à OSM. Je vois que vous avez ajouté les numéros des maisons dans le champ "name". C'est plutôt à indiquer à l'aide de l'attribut "addr:housenumber". Si vous avez besoin d'aide, n'hésitez pas.
Cordialement.

Bonjour,
Merci pour la contribution :-) Ça dépend de la nature du point de covoiturage :
- Si c'est une aire où on peut laisser son véhicule pour en emprunter un autre, dans ce cas plutôt utiliser amenity=parking + carpool=designated (si il y a un panneau covoiturage, sinon yes)
- Si c'est juste un point de pose/dépose (pas de stationnement long), amenity=car_pooling est adapté.
Cordialement,
Adrien.

Bonjour,
Excellente question ! En général les références des conteneurs sont une succession de chiffres obscurs. Là comme c'est plutôt compréhensible, ça sonne presque comme un nom. Mais si c'est la seule façon d'identifier le conteneur, ça pourrait être noté comme ref=*. Je n'ai pas de réponse hyper tranchée pour le coup, à toi de voir ;-)
Cordialement,
Adrien.

Bonjour, bienvenu sur OpenStreetMap ! Je me permets de vous signaler deux/trois petites choses pour améliorer vos prochaines contributions :
- Sur les ateliers reliés, le champ "name" ne doit contenir que le nom de la structure. Le site web peut être renseigné séparément (champ "website" ou "ajouter un champ > site web" dans l'éditeur principal)
- Pour les activités pratiquées, le champ "craft" a été utilisé. Il faut utiliser pour craft (et la plupart des champs) des valeurs en anglais. Par exemple un menuisier + peintre sera noté : craft=joiner;painter
La liste des spécialités est précisée ici : osm.wiki/FR:Key:craft
Si vous avez des questions, vous pouvez répondre ici, me contacter via les messages privés, ou joindre le groupe de contributeurs sur Rennes : http://rennes.osmfr.org/
Cordialement,
Adrien.

Sauf que là où tu te trompes, c'est en disant qu'il n'y avait aucun moyen de vérifier : il y a à minima les photos Mapillary, disponibles assez simplement dans les principaux éditeurs, la communauté locale, et surtout le fait que mes modifications étaient sourcées et récentes, ce qui doit mettre la puce à l'oreille. Concernant la précision de la localisation des petits objets, certes ce n'est pas précis au sens positionnement absolu, mais c'était précis relativement au tracé des voies, ce qui au final est le plus important quand on regarde un plan. Le salut ne passe pas uniquement par les images aériennes, au début d'OSM on en avait pas à disposition et pourtant on s'en sortait quand même. On a pas grand chose à proposer si on attend 5 ans avant de mettre à jour sous prétexte que "c'est pas visible sur les images aériennes".

OK pour l'aspect fraîcheur qui n'est pas évident à évaluer sur les images aériennes. Mais dans ce cas tu peux demander à la communauté locale, qui est quand même active sur Rennes. Une note déposée, ça coûte rien et ça permet de faire ça en lien avec les contributeurs locaux plutôt que d'avancer dans le flou.
Le fait que j'ai déménagé n'enlève rien au fait que ma contribution, même si elle était moins précise que ce qui était possible avec une imagerie à jour, était plus précise que le tracé approximatif que tu avais mis. Après j'y peux pas grand chose si la ville est aménagée "en spaghetti", je suis pas urbaniste.
Ce qui m'agace c'est que tu persiste à dire que tu n'as pas cassé. Fondamentalement c'est pas dramatique, c'est qu'un parking au fond. Mais la vérité terrain est ce qui fait la valeur ajoutée d'OSM, c'est ce que l'on met en avant quand on parle du projet. Donc voir annulée cette primeur des données par une contribution à distance non vérifiée c'est pénible. La "propreté" topologique n'a d'intérêt que si ce que l'on représente est vérifié sur le terrain. Si ça n'existe plus (ou n'a jamais existé) ça n'est pas propre, c'est juste périmé ou faux.
Chacun doit prendre ses responsabilités dans la contribution : c'est pas grave de se tromper, mais il faut reconnaître qu'on aurait pu faire mieux, et surtout éviter que ça se reproduise. J'ai pas envie d'avoir à vérifier quotidiennement tes modifications et annuler ce qui n'a pas de sens, surtout que tu es contributeur expérimenté, pas un débutant. Donc je te serai reconnaissant la prochaine fois de contribuer en bonne intelligence avec la communauté locale, et pas aveuglement à partir de données périmées et surtout en supprimant ce qui est à jour.

Merci d'avoir réparé. Ce serait bienvenu si dans le futur tu peux faire preuve de plus de précaution quant à la fraîcheur des imageries aériennes face à la réalité terrain.

Il se trouve que j'ai déménagé 2 mois avant ces modifs, donc oui je m'en suis pas rendu compte de suite. Ça ne change en rien la problématique des tes contributions hors sol et sans vérification préalable.

C'est pas faute qu'il y ait plein de photos de rues disponibles sur Mapillary, encore une autre source que tu peux mobiliser pour vérifier avant de tout changer. On se demande à quoi ça sert les preuves terrains si c'est pour faire ce genre de dégradations à l'aveugle.

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.