« ball » ?

> Il me paraissait problématique d'indiquer le même code GPS pour un service public et pour un établissement de conseil aux entreprises.

Ça ne nécessite pas de dupliquer le bâtiment, il suffisait d’ajouter un point pour le CIO (comme je l’ai fait dans changeset/179129740), de la même manière que pour le point KPMG existant.

Mais si les deux existent au même endroit, il n’y a aucun problème à ce qu’ils partagent le même « code GPS » : c’est simplement une description de la réalité.

(Cela écrit, la position actuelle des points dans le bâtiment est probablement erronée ; vous pouvez l’améliorer si vous avez plus de détails.)

> Est-ce que l'affichage peut indiquer seulement le CIO ?

OpenStreetMap est une base de donnée géographique, pas une carte. Nous enregistrons ce qui existe sur le terrain, charge aux divers rendus de choisir ce qu’ils affichent et comment ils le priorisent.

Le rendu par défaut sur osm.org (nommé « OpenStreetMap Carto ») est un rendu aux objectifs multiples (et souvent contradictoires), qui ne peut pas convenir à tous les usages. Vous pouvez en utiliser d’autres ; par exemple le rendu « Humanitaire » affiche uniquement le CIO à cet emplacement (osm.org/#map=19/47.445013/-0.545475&layers=HN).

Ces noms sont déjà présents sur les landuse=residential autour, aucune nécessité de les dupliquer.

Je suis plutôt d’accord pour garder le choix existant à priori. Mais quand ça commence à impliquer des conflits de classification (comme la suppression de la source ici), je n’hésite en général pas à séparer.

👋 Bienvenue sur OpenStreetMap et merci pour votre ajout !

Votre modification m’intrigue :

– Pourquoi avez-vous créé un second bâtiment plutôt que simplement modifié celui existant ?
– Pourquoi avez-vous classifié ces bâtiments comme bâtiments d’habitation ?

J’ai simplifié pour le premier point dans changeset/179129740, mais laissé pour l’instant pour le second.

D’autre part, ce bâtiment était déjà noté comme hébergeant KPMG (node/8964262670). Savez-vous si c’est toujours le cas ou si le CIO le remplace ?

En général, on fait plutôt building=construction + construction=* dans ce cas-là.

Pour ce genre de cas, il est utile d’ajouter landuse=brownfield.

Pourquoi fusionner le bâtiment et son contenu ?

amenity=school (ou education=school) n’implique pas building=*, il faut les deux (changeset/179121826).

Oh, j’ai vu l’image sur Panoramax. Corrigé.

« Biencenue » ?

Merci !

Non en effet : way/1476281456 plutôt.

J’ai tendance à ajouter maintenant cycleway=link pour marquer le fait que ce n’est pas un « vrai » chemin mais un détail technique pour le routage ; mais je ne l’ai pas fait systématiquement sur mes anciennes modifications. Je ne suis pas fan du highway=footway + footway=link à un endroit où aucun piéton ne devrait avoir besoin de marcher.

Merci !

Pourquoi avoir séparé way/178396478 et way/1476281457 ?

Normalement parking=surface est réservé aux parkings contenant leur voie d’accès. Cette interprétation de la zone aurait plutôt amené un parking=street_side ici. Cependant je suis d’accord avec parking=surface si on étend le parking à la zone comme je viens de le faire dans changeset/178396478.

Vu le site web (et ce que j’ai lu sur le bâtiment), la résidence est dans le bâtiment « Climax ». Pourquoi l’avoir mis sur une pelouse 20 m plus loin ?

Même remarque que pour changeset/178314752 : way/993410091 n’a aucune raison d’exister si ce n’est comme accès à way/359127728.

Même remarque que pour changeset/178314752 : way/1278059884 n’a aucune raison d’exister si ce n’est comme accès à way/618337586.