talk-ch

talk-ch@openstreetmap.ch

10 participants
2187 discussions

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

R.I.P. Stauffacherplatz Bern
by Andreas Bürki 13 Nov '17

13 Nov '17

Salut In Bern git's seit Mitte 2015 einen Stauffacherplatz. Nachzuvollziehen hier: http://map.bern.ch/stadtplan/ Leider ist dieser Stauffacherplatz letzthin einer der in Bern üblichen Löschorgien zum Opfer gefallen Hier ist das Changeset: http://www.openstreetmap.org/changeset/51414121 cheeers, h. -- Andreas Bürki abuerki(a)anidor.com S/MIME certificate - SHA-256 fingerprint: 8A:1A:C2:93:10:4B:CE:91:2C:80:79:44:24:1D:38:CA:EE:0E:89:C9:A5:A4:A0:03:FF:5A:FB:D1:15:18:B5:45 GnuPG - GPG fingerprint: 5DA7 5F48 25BD D2D7 E488 05DF 5A99 A321 7E42 0227

3 3

Re: [talk-ch] talk-ch Digest, Vol 1400, Issue 1
by Jonathan Masur 10 Nov '17

10 Nov '17

Bonjour/Bonsoir à tous, > To be clear this is wrong. > > The current copyright protection term is 70 years in Switzerland, how > this is actually calculated depends on details of the publication that > we don't really know (assuming that for example a map series is > considered a single work, it wouldn't start counting before the last > map of the series was published, which for the 1:25'000 maps is sometime > in the 1960's), but anything younger than 1947 is definitely not out of > copyright. Determining the exact legal status depends on what Jonathan > was actually using (which he hasn't actually told us) and is in any case > difficult, but it is likely that none of the post Siegfriedkarte maps > can be a legitimate source for OSM. Comme je vous l'ai déjà dit, j'ai utilisé des cartes au 25:000 des années 1950 et 1960, mais vu que celles-ci sont "absolument illégales" il n'est pas nécessaire de poursuivre cette discussion il semblerait. D'après la règle d'or d'Yves, il faut prouver qu'une source est légale avant de l'utiliser, donc par défaut toute modification d'OSM est illégale - il faut commencer par prouver la légalité d'une source, ce qui reviendrait à lire le code civil en entier pour y trouver aucune contradiction avec mon intension ? Je crains que la majorité des modifications d'OSM (et pas seulement les miennes !), soient fortement compromises avec votre règle d'or. Par exmple si j'ai constaté qu'un nouveau giratoire à été construit, qu'est-ce qui me donne explicitement le droit de l'introduire sur OSM ? C'est l'opposé exact de la "présomption d'innocence", ou il faut prouver avec une loi précise comme quoi quelque chose est illégal, sinon l'accusé est innocent par défaut. Enfin bref je m'écarte du sujet désolé... Il ne devrait pas être trop compliqué de trouver des sources plus anciennes encore pour les frontières de communes (celles-ci se déplacent rarement) si c'est utile. Je pense que le copyright s'applique à la carte en question et non à la frontière qui est dessinée dessus ? Je trouverais absurde de mettre un copyright sur une frontière. Les frontières peuvent être retrouvées à partir des bornes qui sont souvent encore là, mais certaines pourraient en effet manquer ou avoir été détruites. L'avantage serait une meilleure précision. > Further Jonathan confuses the matter further by not pointing out that he > was adding borders that were never in OSM in the first place, the > dataset we used for the original import is from 2011, so borders for > example from 2008 that Jonathan was adding were simply never there. > Existing border ways that were deleted during the merger process could > be restored if necessary, so there is no real reason to use a third > party source if we choose to recreate them. Le fait que les communes aient fusionné avant ou après 2011 ne change rien au fait qu'elles aient fusionné. OSM doit décrire le monde tel qu'il existe - il n'y a aucune différence fondamentale entre une commune qui a fusionné en 2012 et une en 2010. Mon souci est la cohérence : Tout doit être mappé selon les mêmes règles, et il ne devrait pas il y avoir une anarchie au cas par cas. Si les anciennes communes doivent être représentées (mon avis est que oui et celui de Simon que non - mais ce n'est pas le débat ici), alors toutes les anciennes communes devraient être représentées, et ce de façon cohérente. Il n'y a aucune raison valable d'avoir certaines anciennes communes et pas d'autres. On /pourrait /décréter que les anciennes communes d'après 2011 sont désirables et celles d'avant non, mais alors dans ce cas cette règle doit être documentée quelque part et suivie autant que possible de manière uniforme. Je ne savais pas qu'il était possible de retrouver les frontières qui avaient été purement et simplement supprimées des serveurs. C'est pourquoi j'ai malheureusement du me contenter de les redessiner, avec la perte de précision que ça implique (et ce potentiel problème de légalité). > First a clarification, Wambacher recommendations are based on the > situation in Germany, and they are not directly applicable to > Switzerland in any case (I would consider a number of his arguments > rather hand wavy even for Germany, but that is a different story). La situation en Allemagne est similaire, mais avec 30 ans d'avance car les fusions de communes ont été encouragées/imposées dans les années 1970, (probablement imposées par les élites sans se soucier de l'avis des populations locales, comme d'habitude). De nombreuses anciennes communes allemandes semblent être notées avec admin_level=10. Concernant, la suggestion de Michael de partir sur le projet Open HIstorical Map, je serais très enthousiaste d'y contribuer, mais le projet semble, hélas, mort. Cette page wiki complètement vide (http://wiki.openstreetmap.org/wiki/Open_Historical_Map/FAQ) montre hélas à quel point ce projet est délabré :( Avec mes meilleures salutations, -- Jonathan Masur PS : Après réflexion, je pense que l'idée de différentier les fusion de communes avant et après 2011 n'est pas si bête étant donnée la situation - c'est à dire qu'il est difficile d'obtenir les frontières d'avant 2011 en respectant les conditions d'utilisation. Les communes fusionnées avant 2011 seraient ignorées, mais celles fusionnées après 2011 seraient présentes en tant que "quartiers", (en utilisant bien entendu les frontières importées en 2011 et non pas des dessins de ma part). Qu'en pensez-vous ?

2 1

Fusion de communes
by Jonathan Masur 08 Nov '17

08 Nov '17

Bonjour/Bonsoir à tous, Je n'ai pas vraiment compris si le problème de Simon est que 1) que la présence des anciennes frontières communales sur les serveurs d'OSM qui vous dérangent, ou 2) les sources utilisées pour mes modifications de ces derniers temps Vu que les deux problèmes sont orthogonaux, je vais en discuter de manière séparée. 1) Jusqu'à présent, le traitement des fusions de communes sur OSM a été relativement chaotique, au cas par cas il n'y avait aucune consistance dans le traitement qui était fait à ces frontières. En l'occurence dans le canton de Vaud j'ai rencontré les cas suivants: a) Frontières purement et simplement supprimées des serveurs b) Frontières avec "admin_level=9", avec ou sans relation pour les anciennes communes c) Frontières avec "admin_level=10", avec ou sans relation pour les anciennes communes d) Frontières taguées "boundary=old_administrative" au lieu de "boundary=administrative" e) Frontières taguées "boundardy=historic" Il n'est pas sain d'avoir 5 façons différentes de représenter les fusions de communes - de plus, je ne vois aucune raison valable de représenter certaines anciennes communes et pas d'autres en fonction de si elles ont déjà été sur OSM par le passé ou non. Une commune fusionnée est une commune fusionnée, peu importe que la fusion ait eu lieu avant ou après que les frontières aient été importées sur OSM, ou avant même que OSM existe. J'ai donc utilisé le système qui était recommandé par Wambacher : Les anciennes frontières communales sont marquées "boundary=historic" et "admin_level=8" avec la date de la fusion des communes sous le tag "end_date". Les anciennes communes sont des relations avec "admin_level=10". Dans tout les cas les dates de début et de fin de communes sont ajoutées au tags, sauf lorsqu'une commune déjà existante s’agrandit sans changer de nom (comme par exemple Servion qui annexe Les Cullayes - dans ce cas "Servion" n'a pas de date de début et de fin). Ceci à l'avantage d'expliquer clairement la situation - la frontière est historique, mais les "quartiers" de la nouvelle commune existent encore aujourd'hui - par exemple il se peut que la représentation au conseil communal doive être proportionnelle avec les anciennes communes, dans ce cas les anciens territoires sont utilisés. 2) Simon semble terrorisé à l'idée d'une "importation illégale" de frontières. Lorsque cela était possible j'ai utilisé les frontières déjà en place. Malheureusement, certaines fois elles avaient été supprimées, et j'ai du les redessiner à partir d'anciennes cartes de la confédération. Celles datant d'avant 1967 sont dans le domaine public puisqu'elles ont plus de 50 ans. De plus leur réalisation à été faite par la confédération avec nos impôts. La précision est hélas très approximative et je regrette de ne pas avoir de meilleure option - si vous avez une meilleure idée je suis preneur. Dans l'immense majorité des cas, les bornes en pierre sont toujours présentes donc il est parfaitement possible de les retrouver et de tracer la frontière de manière plus précise, cependant certaines bornes pourraient avoir été dégradées avec le temps. Quand aux dates et fusions de communes, celles-ci sont disponibles sur le site de l'état de Vaud : https://www.vd.ch/themes/territoire/communes/fusions-de-communes/ Je ne comprends pas votre paranoïa quand aux sources soi-disons illégales - si vous m'expliquez plus en détail peut être pourra-t-on arriver à se comprendre. La prochaine fois qu'un tel problème se produit, veuillez en parler plus rapidement - après les premières éditions si possible. J'ai déjà commencé ce travail il y a deux semaines donc vous auriez pu en parler tout de suite au lieu de me laisser bosser de nombreuses heures dessus pour tout effacer immédiatement, ce qui en résulte une certaine perte de temps et une frustration de ma part - tout le monde y aurait été gagnant Je suis navré d'avoir accidentellement affecté des communes actuelles (Saint-Barthélémy je crois ?!) - de toutes manières j'aurais repéré le problème sur le site de Wambacher et je l'aurais corrigé dans la semaine qui vient. Veuillez recevoir mes meilleures salutations, Jonathan PS : Même dans le cas ou toutes mes modifications seraient 100% indésirables, j'ai tout de même repéré quelques problèmes avec le jeu de données existant, comme une commune qui était présente deux fois dans la base de données ! (Je ne me rapelle plus laquelle)

3 3

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

talk-ch