talk-ch

talk-ch@openstreetmap.ch

2 participants
2220 discussions

Wanderwegenetz in Superrelation
by Raymond Smeets 15 Dec '17

15 Dec '17

Liebe OSM Gemeinschaft, Erstmal möchte ich mich entschuldigen für mein Deutch Niveau, ich bin seit nur vier Monaten in der Schweiz. Aber wenn man es nicht versucht und übt, dann wird es nie besser. Ich sehe dass im Kanton Zürich die separate Wanderwegstrecken teilweise gebündelt sind in Superrelationen. * Wanderwege ZH https://www.openstreetmap.org/relation/300476 * Wanderwege ZH, Bezirk Hinwil https://www.openstreetmap.org/relation/190641 * Wanderwege ZH, Bezirk Uster https://www.openstreetmap.org/relation/117797 * Wanderwege ZH, Bezirk Zürich https://www.openstreetmap.org/relation/300469 Teilweise verstehe ich der Hang eine Bündel dar zu stellen, aber wie im Wiki schön gesagt «https://wiki.openstreetmap.org/wiki/DE:Relationen/Relationen_sind_keine_Kategorien». Weil die Superrelationen schon seit 8 Jahre bestehen möchte ich sie nicht direkt löschen, aber es hier mal vorschlagen. Ich würde vorschlagen die zwei Ebenen Superrelationen zu löschen und nur die separate Relationen jede Strecke des Netz zu behalten. Liebe Grüsse, dikkeknodel<https://wiki.openstreetmap.org/wiki/User:Dikkeknodel>

1 0

Wochennotiz Nr. 385 28.11.2017–04.12.2017
by Wochennotizteam 09 Dec '17

09 Dec '17

Hallo, die Wochennotiz Nr. 385 mit vielen wichtigen Neuigkeiten aus der OpenStreetMap-Welt ist da: http://blog.openstreetmap.de/blog/2017/12/wochennotiz-nr-385/ Viel Spaß beim Lesen!

1 0

review_requested=yes sans commentaire
by marc marc 02 Dec '17

02 Dec '17

Bonjour, Le tag permet à un contributeur qu'il souhaite un deuxième avis sur sa modification. Je regarde régulièrement les changeset avec ce tag, le plus souvent utilisé par un contributeur récent. C'est un outil pratique pour aider à s'améliorer. A ma demande, Pascal Neis l'auteur du site web ci-dessous, a ajouté une option pour n'afficher que les changeset sans commentaire, ceux qui sont le + susceptible d'avoir besoin d'un coup d’œil. Pour la Suisse, cela donne > https://resultmaps.neis-one.org/osm-suspicious?country=182&hours=96&mapping… Pour que cette nouvelle option fonctionne, il faut bien sur prendre la peine de mettre un petit mot sur le changeset (même quand il n'y a rien à corriger). Cordialement, Marc

1 0

Wiedermal PokemonGo
by Simon Poole 02 Dec '17

02 Dec '17

Wir hatten gestern wieder ein paar Neulinge (das wird noch mehr werden) die vermutlich PokemonGo motiviert angefangen haben zu mappen, alle haben die Begrüssungsmail von uns bekommen, und allfällige Phantasieedits scheinen sich im Rahmen zu halten. Falls einer der folgenden Mapper sich bei euch in der Nähe befindet, könnt ihr kurz ein Blick darauf werfen und gegebenenfalls den Mappern etwas Hilfestellung leisten: * Mauro Gees * Guillaume Leuba * RenaSo * PxxTTrain * slimthugga Simon

1 0

Routes à contresens pour les cyclistes
by Rémi Bovard 29 Nov '17

29 Nov '17

Bonjour à tous, Vu dans le 24heures du jour : "On verra de plus en plus de vélos débouler à contresens à Lausanne" [1] S'il y a des mappeurs dans le coin qui peuvent aller vérifier la carte de l’article et qui veulent mettre à jour OSM... Bonne journée. Rémi [1] https://www.24heures.ch/vaud-regions/verra-plus-velos-debouler-contresens-l…

3 2

Dédoublement des routes avec les deux sens de circulation
by Jonathan Masur 28 Nov '17

28 Nov '17

Bonjour à tous, Je me demande dans quels situation est-ce qu'un dédoublement des routes avec les deux sens de circulation est justifié. Exemple ici : http://www.openstreetmap.org/#map=18/46.51730/6.57127 Meilleures salutations, -- Jonathan Masur

5 10

Re: [talk-ch] Dédoublement des routes avec les deux sens de circulation
by Jonathan Masur 26 Nov '17

26 Nov '17

Bonjour à tous, Ma question était juste de savoir quand cela était justifié, le lien était là seulement pour montrer de quoi je parlais dans un endroit connu. Je ne me posais pas la question si c'était justifié ici en particulier, mais de manière générale. Donc, si il y a un obstacle plus gros qu'un simple îlot de passage à piétons, un dédoublement est justifié. Merci pour la précision. Meilleures salutations -- Jonathan Masur

2 1

Re: [talk-ch] amélioration borne incendie (fire_hydrant)
by marc marc 18 Nov '17

18 Nov '17

Le 02. 10. 17 à 19:02, Marc M. a écrit : >>>>> - flow_capacity dans le tag name >>>>> Je souhaite migrer l'information dans le tag >>>>> fire_hydrant:flow_capacity >>>> D'accord >>> C'est encore à faire (pas d'outil automatique pour extraire la valeur) Vu le petit nombre (54), j'ai fais les modifications manuellement. La proposition ayant entre temps changé, le tag est flow_rate Il reste encore 132 faux nom à traiter. Cordialement, Marc

1 0

Re: [talk-ch] Proposition pour un tagging cohérent des fusions de communes
by Jonathan Masur 16 Nov '17

16 Nov '17

Bonjour/bonsoir à tous, Le 16.11.2017 à 12:00, talk-ch-request(a)openstreetmap.ch a écrit : > Il y a un problème de définition. Exemple avec une commune rurale. > Sa surface couvre les habitations mais aussi les champs jusqu'à la > limite de la commune voisine. > Lorsque cette commune fusionne avec sa voisine, son ancien tracé n'est > pas un quartier. A mes yeux, c'est son ancien tracé > qui devrait donc être mis en disused:admin_level et garder la même > valeur qu'avant donc 8. C'est du moins ainsi que c'est fait ailleurs qu'en Suisse. > En même temps, s'il n'existe pas, il faut créer le contour du village > (niveau 9) ou du hameau (niveau 10). Je n'ai pas de problème avec disused:amin_level, mais alors si c'est le cas ceci doit être cohérent partout. Il me semblait que le préfixe "disused:" est surtout prévu pour les objets physiquement en état de ruine, comme par example un restaurant qui a fait faillite, mais je pense que ça pourrait avoir le sens de l'utiliser pour une commune fusionnée. En Allemagne le niveau 9 est fréquemment utilisé pour d'anciennes communes fusionnées, en France l'énorme majorité des fusions de communes ont été annulés par la suite donc le problème ne se pose que rarement, et le reste du monde je ne le connais pas assez pour avoir une idée. Après réflexion, en effet c'est beaucoup plus loque d'utiliser admin_level=9 et non 10, comme prévu dans mon mail précédent. Admettons qu'une grande ville ayant plusieurs quartiers (admin_level=10) fusionne avec un village qui se trouve en dehors de la ville, alors il est logique que cette ancienne commune ait un niveau plus important que les quartiers de la ville. Donc, dans ma proposition, j'inverserais les niveaux. Le niveau 9 serait utilisé pour indiquer des communes ayant fusionné après le 31 juin 2011 et 10 serait utilisé pour les quartiers des grandes villes seulement. > Selon le wiki, 9 ne représente pas une commune mais un village. Donc il semble bien que c'est un numéro adéquat pour représenter une ancienne commune, qui représente souvent un village, non ? Le noeud "place=village" représente le village lui-même, et la relation représente son territoire, s'il en a un. Les villages n'ayant jamais été indépendants ou ceux ayant fusionnés avant le 1er juillet 2011 n'ont pas de territoire défini, seulement un centre, et les villages ayant fusionné après le 1er juillet 2011 ont un territoire défini donc on peut l'utiliser. La barrière entre hameau et village est extrêmement floue: D'après le wiki, les hameaux peuvent avoir jusqu'à 200 habitants, les villages dès 100, donc il y a un recouvrement. Je pense donc qu'il est plus simple de garder "9" dans tout les cas, même quelquefois il s'agit de hameaux qui étaient indépendants malgré que peuplés de moins de 100 habitants. > Tu vas trop vite. cette situation dure depuis des années, il faut laisser le temps au temps. Oh, je suis terriblement désolé d'avoir voulu paraître si pressé ! Aucun problème, on a tout le temps. > Gibt es auch fusionierte Gemeinden, die von den ursprünglichen Gemeindegrenzen abweichende Quartiere (oder Ortsteile) haben? Falls ja, wie wäre das dann zu handhaben? Das ist genau darum est keine gut Idee war , admin_level=10 für fusionierte Gemeinden zu verwenden. Mit admin_level=9 es ist kein mehr Problem, die ehemalien Quartiere oder Ortseile müssen admin_level=10 verwenden, und die ehemalien Gemeinden admin_level=9. Mit freundlischen grüssen, -- Jonathan Masur Rue du Bourg 18 1071 Chexbres Tel. 021 946 18 87

1 0

Proposition pour un tagging cohérent des fusions de communes
by Jonathan Masur 16 Nov '17

16 Nov '17

Bonjour/Bonsoir à tous, Après réflexion de ma part, je me rends compte que je n'avais en effet pas assez réfléchi au problème. J'ai essayé de trouver une solution satisfaisante pour tout le monde: Les frontières utilisées doivent être légalement importées, les tags en placent doivent êtres cohérents et répondre à des règles bien définies, et les anciennes communes devraient être représentées lorsque c'est possible. Je propose donc les règles suivantes en ce qui concerne la fusion de communes en Suisse : 1) Les communes ayant disparu avant le 1er juillet 2011 ne sont pas représentées sur OSM, car il est difficile voir impossible de maintenir leur frontière. Il est interdit de les redessiner depuis une carte existante, même ancienne. Bien entendu tout les noms de lieux (villages, etc..) restent, mais ils ne font partie d'aucune relation. 2) Les communes ayant fusionné depuis le 1er juillet 2011, y compris, sont présentes sous considérées comme des quartiers de la nouvelle commune. Des frontières avec "boundary=administrative" avec "admin_level=10" sont utilisées autant pour les relations que pour les frontières. Ces "quartiers" sont considérés comme étant toujours d'actualité, donc, il n'y a pas de tag "end_date=". 3) Les communes fusionnées qui ont un nouveau nom devraient avoir le tag "start_date=", indiquant le jour de création de la nouvelle commune, et ce peu importe si la fusion a eu lieu avant ou après 2011. Par contre une commune qui en absorbe une autre, sans changer de nom, ne doit pas avoir de tag "start_date=" pour indiquer la fusion, car il ne s'agit pas d'une création d'une nouvelle commune, mais simplement d'une absorption. 4) Les quartiers représentant d'anciennes communes qui ont disparu depuis le 1er juillet 2011 sont considérés comme étant toujours d'actualité (seule la commune ayant disparu), donc, contrairement à ce que j'ai moi-même utilisé, le tag "boundary=historic" ne doit jamais être utilisé dans ce cas. Il n'y a pas non plus de "end_date=". 5) Dans le cas ou une commune s'est agrandie avec une fusion réalisée en plusieurs étapes, les étapes d'avant le 1er juillet 2011 sont ignorées. Toutes les anciennes communes qui existaient en date du 1er juillet 2011 sont présentes sous formes de "quartiers", dans leurs frontière au 31 juin 2011. Aucune différence n'est faite entre les anciennes communes qui auraient été fusionnée lors de différentes étapes après le 1er juillet 2011. Toute commune temporaire issue d'une première fusion mais qui a disparu suite à une deuxième fusion, toutes deux après le 1er juillet 2011, n'est pas représentée. 6) Les règles précédentes sont la seule façon de représenter des anciennes communes. Le tag "boundary=adminstrative"+"admin_level=9" ou autres ne devraient pas représenter d'anciennes communes. Est-ce qu'il y a des objections ? Si il n'y en a pas dans le semaine à venir, je vais mettre ces règles sur le wiki sur les pages http://wiki.openstreetmap.org/wiki/Switzerland/2017_Municipality_Mergers et http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative Puis je les appliquerai au canton de Vaud, en laissant les utilisateurs des autres cantons à les appliquer à leurs propres cantons Kann jemanden helfen, meine Vorschlag auf Deutsch zu Übersetzen ? Vielen Dank. Jemanden können auch mir auf Deutsch antworten, dass ist für mich kein problem. Mit freundlischen Grüssen, -- Jonathan Masur

5 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

talk-ch