- talk-ch - openstreetmap.ch

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

Merkwürdiger Edit in Basel
by Simon Poole 07 Nov '17

07 Nov '17

Wenn jemand Zeit hat https://www.openstreetmap.org/node/2609328113 kommt mir spanisch vor (aus mehreren Gründen).

5 6

OSM-Stammtisch Zürich: 13. November
by Patrick Staehlin 06 Nov '17

06 Nov '17

Salut! Der nächste OSM-Stammtisch in Zürich findet in einer Woche zur üblichen Zeit am üblichen Ort statt: Datum: Montag, 13. November 2017 Zeit: ab 18:30 Uhr Ort: ETH-Hauptgebäude, drinnen zwischen bQm und ETH-Mensa Karte, weitere Infos und (unverbindliche) Anmeldung: http://wiki.openstreetmap.org/wiki/DE:Switzerland:Z%C3%BCrich/OSM-Treffen#8… Gruss Packi

1 0

Re: [talk-ch] Adresses Bern
by Olivier Chatelain 05 Nov '17

05 Nov '17

Okay Simon - please pardon for my missing knowledge about our state and my city. - We could fix the "Hauptstadtfrage" with the takeover too ;-) tl;dr - Bern wird "Bundesstadt (nicht Hauptstadt)" genannt - Sie ist nur de facto und nicht de jure die Hauptstadt der Schweiz Long version: - https://de.wikipedia.org/wiki/Hauptstadtfrage_der_Schweiz Simon Poole <simon(a)poole.ch> schrieb am So., 5. Nov. 2017 um 20:19 Uhr: > tss tss, you should know that Berne is not the capital of Switzerland, it > is just the seat of parliament :-) > > Am 05.11.2017 um 18:33 schrieb Olivier Chatelain: > > Good idea. > > What about Bern conquering all Switzerland (the capital would not change)? > Then ask for the data and pardon all cantons back to independence - > #legalglitch > > Happy Weekend to everybody > Oli > > amilopowers(a)u-cloud.ch <amilopowers(a)u-cloud.ch> schrieb am So., 5. Nov. > 2017, 16:32: > >> And #208 >> >> ---- >> Sent from ProtonMail <https://protonmail.ch>, encrypted email based in >> Switzerland. >> >> >> -------- Original Message -------- >> Subject: Re: [talk-ch] Adresses Bern >> Local Time: 5. November 2017 4:31 PM >> UTC Time: 5. November 2017 15:31 >> From: amilopowers(a)u-cloud.ch >> To: Openstreetmap Schweiz/Suisse/Svizzera/Svizra < >> talk-ch(a)openstreetmap.ch> >> >> I forgot to say that those are the tasks #200 and #209 >> >> http://tasks.osm.ch/project/2#task/209 >> http://tasks.osm.ch/project/2#task/200 >> <http://tasks.osm.ch/project/2#task/209> >> >> ---- >> Sent from ProtonMail <https://protonmail.ch>, encrypted email based in >> Switzerland. >> >> >> -------- Original Message -------- >> Subject: [talk-ch] Adresses Bern >> Local Time: 5. November 2017 4:29 PM >> UTC Time: 5. November 2017 15:29 >> From: amilopowers(a)u-cloud.ch >> To: Openstreetmap Schweiz/Suisse/Svizzera/Svizra < >> talk-ch(a)openstreetmap.ch> >> >> Hello >> >> While working on the addresses of Canton of Bern I thought about the >> political situation around Moutier [1]. It seems like Moutier has decided >> to leave the Canton of Bern and join Jura. It isn't definitive yet but >> there is a good chance that Moutier eventually leaves at some date in the >> future. Belprahon and Sorvilier voted to stay in the last vote. >> >> I just want to point out that if you don't know to map what community >> first or next then it might be a good idea to start/continue with those. >> Just to make sure the data is legally imported before they leave and the >> data becomes illegal or in a somewhat gray zone. >> >> Just my 5 cents... >> >> Have a nice Sunday. >> Ueli >> >> [1] >> >> https://www.srf.ch/news/regional/bern-freiburg-wallis/moutier-sagt-dem-kant… >> >> https://www.bernerzeitung.ch/region/bern/Jurafrage-Bekenntnis-zum-Kanton-Be… >> >> ---- >> Sent from ProtonMail <https://protonmail.ch>, encrypted email based in >> Switzerland. >> >> >> >> >> _______________________________________________ >> talk-ch mailing list >> talk-ch(a)openstreetmap.ch >> http://lists.openstreetmap.ch/mailman/listinfo/talk-ch >> > > > _______________________________________________ > talk-ch mailing listtalk-ch@openstreetmap.chhttp://lists.openstreetmap.ch/mailman/listinfo/talk-ch > > >

1 0

Adresses Bern
by amilopowers＠u-cloud.ch 05 Nov '17

05 Nov '17

Hello While working on the addresses of Canton of Bern I thought about the political situation around Moutier [1]. It seems like Moutier has decided to leave the Canton of Bern and join Jura. It isn't definitive yet but there is a good chance that Moutier eventually leaves at some date in the future. Belprahon and Sorvilier voted to stay in the last vote. I just want to point out that if you don't know to map what community first or next then it might be a good idea to start/continue with those. Just to make sure the data is legally imported before they leave and the data becomes illegal or in a somewhat gray zone. Just my 5 cents... Have a nice Sunday. Ueli [1] https://www.srf.ch/news/regional/bern-freiburg-wallis/moutier-sagt-dem-kant… https://www.bernerzeitung.ch/region/bern/Jurafrage-Bekenntnis-zum-Kanton-Be… ---- Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland.

3 4

"Historic" and broken boundaries in the Canton Vaud
by Simon Poole 05 Nov '17

05 Nov '17

Jonathan Masur has added a larger number of historic municipality boundaries in the canton Vaud, breaking a fair number of real boundaries in the process, see https://www.openstreetmap.org/changeset/53490105#map=14/46.5737/6.7725 Any Objections to reverting all of this? Simon

6 8

addr:city Tag
by openstreetmap＠rothen.com 31 Oct '17

31 Oct '17

Hallo zusammen Ab und zu erfasse ich Adressen im Kanton Bern. Als ich nun angefangen habe die Adressen in der Gemeinde Köniz zu erfassen bin ich auf folgende Spezialität gestossen. Die Gemeinde Köniz umfasst mehrere PLZ und Orte. Bisher habe ich jeweils die Offiziellen PLZ und den dazugehörigen Ortsnamen im Tag addr:city erfasst. In der Gemeinde Köniz habe ich nun Adressen gefunden welche mit dem Tag addr:city=Köniz und addr:suburb=Spiegel b. Bern erfasst sind. Für den Ort Spiegel b. Bern gibt es auch einen eigene PLZ und die Offizielle Adresse ist Spiegel b. Bern. Dies sowohl bei der Postadresse wie auch bei den Kantonalen Daten. Was gehört hier nun korrekter Weise in das addr:city Tag? Andere ähnlich gelagerte Fälle sind Adressen welche in der Gemeinde Bern liegen, aber dem PLZ Kreis von Ostermundigen angehöhren. Soll das addr:city Tag die Postadresse widerspiegeln oder die Politische Gemeinde in der diese Adresse liegt? Bin gespannt auf eure Meinungen. Gruss, Christof

6 5

Re: [talk-ch] Kanton Wallis - Nutzung der Geodaten: Attribution auf Wiki ausreichend gemäss Genehmigung? (Re: WG: Kanton Wallis - Nutzung der Geodaten)
by Tobias Heinzmann 30 Oct '17

30 Oct '17

Nein, ich habe eine Veröffentlichung auf der Wiki-Seite dem Kanton noch nicht vorgeschlagen. Ich möchte dies zuerst mit euch besprechen, ansonsten gibt es plötzlich ein ewiges hin-und her mit der Behörde. Ich denke wenn der Kanton Wallis den gleichen Eintrag wie der Kanton Schaffhausen genehmigt, wäre dies eine gute Sache.http://wiki.openstreetmap.org/wiki/Contributors#Switzerland Raphael Das Gupta (das-g) <lists.openstreetmap.ch(a)raphael.dasgupta.ch> schrieb am 10:03 Montag, 30.Oktober 2017: Hallo Tobias Vielen Dank für das Nachhaken (beim Kanton und hier)! Beim Zitierten Mail-Verkehr blicke ich nicht ganz durch: On 30.10.2017 08:49, Tobias Heinzmann wrote: Ich werde Herrn Oggier diesbezüglich eine Veröffentlichung der http://wiki.openstreetmap.org/ wiki/Contributors#Switzerland vorschlagen. Ist das bereits geschehen und liegt eine Antwort des kantonalen Amtes auch diesbezüglich vor? Herzlichen Gruss, Raphael _______________________________________________ talk-ch mailing list talk-ch(a)openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch

1 0

Re: [talk-ch] Kanton Wallis - Nutzung der Geodaten
by Tobias Heinzmann 30 Oct '17

30 Oct '17

Liebe OSMler Ich habe nun eine Antwort vom Kanton bekommen. Den Wunsch eine Quellenangabe bei auf dem Internet und auf den Auszügen anzubringen kann von OSM nicht umgesetzt werden. Ich werde Herrn Oggier diesbezüglich eine Veröffentlichung der http://wiki.openstreetmap.org/ wiki/Contributors#Switzerland vorschlagen. Wobei wenn ich den Eintrag vom Kanton Schaffhausen anschaue kommt es der Forderung des Kantons Wallis ziemlich nahe:Field names, addresses and building outlines derived from the Canton Schaffhausen (Amt für Geoinformation Schaffhausen) Attribution: "Geodaten des Kantons Schaffhausen". Was denkt ihr? Obwohl ich im Mail eine klare Aussage gewünscht habe, ist seine Aussage wahrscheinlich noch zu wenig konkret. Ich werde ihn bitten eine klare Aussage diesbezüglich zu machen. Was denkt ihr? Kurz noch zurück auf die Empfehlung von Simon ich solle die Vorlage3 verwenden. http://wiki.openstreetmap.org/wiki/Import/GettingPermission#Letter_Template… Vorlage 3 ist ja ein Vertrag der von der Seite des Kantons ausgefüllt und unterschrieben wird. Als ich das durchgelesen haben kam es mir so vor als ob es einen Pakt mit dem Teufel ist :) Natürlich will OSM nichts Böses aber ich denke, dass ein solches Formular eher abschreckend wirkt und evtl. eine grosse Bürokratie ins Rollen bringt. Deshalb habe ich auf diese Vorlage verzichtet. Gibt es denn keine "Schweizer Vorlage" für Bund, Kantone und Gemeinden die man verwenden möchte und die ein wenig einfacher Formuliert ist? Ich muss dazu sagen, dass ich es auch wichtig und richtig finde sich ganz klar abzusichern. Weiter unten ist noch der Mailverkehr zwischen mir und dem Kanton Wallis. Vielen Dank für eure Inputs. Gruss Tobi-------------------------------------------------------------- Meine Mail:----------------------------------------------------------------------------------------------Guten Tag Herr Heinzmann Vielen Dank, dass Sie die Daten der Amtlichen Vermessung des Kanton Wallis der Öffentlichkeit zugänglich machen. Als Mitwirkender am OpenStreetMap-Projekt[1], einem offenen Gemeinschaftsprojekt zur Erstellung eines globalen Geodatensatzes, der von jedermann frei verwendbar ist[2], brauche ich noch eine konkretere Aussage, um die Geodaten für OSM benützen zu können. Im einfachsten Fall würde ich eine Aussage wie diese benötigen: "Die Dienststelle für Geoinformation des Kanton Wallis haterlaubt es, dass die Geodaten "Amtliche Vermessung: Bodenbedeckung", "Amtliche Vermessung: Nomenklatur" und "Amtliche Vermessung: Einzelobjekte" , die via https://www.geopol.ch/#/ workspaces/30 bezogen werden können, in die OpenStreetMap-Projektgeodatenb ank aufgenommen und unter einer freien und offenen Lizenz freigegeben werden"[1]. Ich bitte auch darum, dass jede Erklärung, die Sie abzugeben bereit sind, zu Informationszwecken veröffentlicht werden kann. Unten ist ein Factsheet. Wenn Sie weitere Informationen wünschen, werde ich mich bemühen, Ihnen zu helfen oder die Lizenzarbeitsgruppe unseres Projektes bitten, sich mit Ihnen in Verbindung zu setzen. Vielen Dank im Voraus. Freundliche Grüsse Heinzmann Tobias Faktenblatt 1] Das OpenStreetMap-Projekt hat derzeit weltweit über 750.000 registrierte Mitwirkende. Unsere Hauptseite ist http://www.openstreetmap.org 2] Wir sind dazu verpflichtet, unsere Geodaten auf Dauer unter einer freien und offenen Lizenz zur Verfügung zu stellen. Es ist uns nicht gestattet, eine kommerzielle Lizenz zu nutzen, aber kommerzielle Organisationen sind berechtigt, unsere Daten unter den selben Bedingungen zu verwenden. 3] Unsere Daten werden derzeit unter der Open Database License 1.0, http://www.opendatacommons.org /licenses/odbl/ veröffentlicht. 4] Die meisten unserer Geodaten stammen von Einzelpersonen. Wir sind jedoch sehr dankbar, wenn wir in der Lage sind, Geodaten aus anderen Geodatensätzen zu übernehmen oder daraus abzuleiten, wenn die Lizenzbedingungen kompatibel sind. 5] Wir weisen alle Quellen auf http://wiki.openstreetmap.org/ wiki/Attribution ausdrücklich zu und verwenden, wenn Sie es wünschen, einen bestimmten Wortlaut. Wir versuchen auch, einen Link zu dieser Seite mit allen möglichen Auszügen aus unserer Datenbank zu erstellen. Aus praktischen Gründen ist es jedoch nicht erforderlich, dass Endbenutzer eine solche Zuweisung wiederholen, da sie Hunderte von Benutzern betrifft. Wir führen auch einen öffentlichen Track der Datennutzung durch Dritte unter http://wiki.openstreetmap.org/ wiki/Import/Catalogue und haben normalerweise eine Projektseite für jeden Datensatz, auf der beschrieben wird, wie wir ihn verwenden und ob es irgendwelche Lizenzbeschränkungen gibt. Wenn Sie spezielle rechtliche Fragen haben, steht Ihnen die Lizenzarbeitsgruppe der OpenStreetMap Foundation unter legal(a)osmfoundation.org gerne zur Verfügung.------------------------------------------------------------------------------------------------ Antwort Mail:------------------------------------------------------------------------------------------------Sehr geehrter Herr Heinzmann,ich beziehe mich auf Ihre E-Mail vom 19. Oktober 2017 betreffend die Nutzung der Daten der amtlichen Vermessung im OpenStreetMap-Projekt und gestatten hiermit die Nutzung und Veröffentlichung der Daten der amtlichen Vermessung im OpenStreetMap-Projekt. Wir möchten Sie jedoch bitten, eine Quellenangabe bei der Veröffentlichung auf dem Internet und auf den Auszügen anzubringen: „Quelle: Kanton Wallis (2017).“ Mit freundlichen GrüssenRainer Oggier | | Rainer Oggier Dipl. Kulturingenieur ETH / Ingénieur du génie rural EPF Pat. Ingenieur-Geometer / Ingénieur-géomètre brevetéChef CC GEO https://www.vs.ch/egeo | | | | Département des finances et de l’énergie (DFE) Service de la géoinformation (SGI) CC Géomatique (CCGEO) Avenue de la Gare 39 CH - 1950 Sion | | | Tél 1 Tél 2 email | : : : : | 027 606 28 28 027 606 28 50 rainer.oggier(a)admin.vs.ch | | ------------------------------------------------------------------------------------------------------------- Simon Poole <simon(a)poole.ch> schrieb am 10:43 Dienstag, 17.Oktober 2017: Am 16.10.2017 um 15:08 schrieb Tobias Heinzmann: ........ "Die Dienststelle für Geoinformation des Kanton Wallis hat keine Einwände dagegen, dass die Geodaten der „amtlichen Vermessung“, die via https://www.geopol.ch/#/ workspaces/30 bezogen werden können, in die OpenStreetMap-Projektgeodatenbank aufgenommen und unter einer freien und offenen Lizenz freigegeben werden"[1]. Wir haben historisch auch schon mit weniger Daten genutzt, aber trotzdem "keine Einwände dagegen" (Duldung) ist nicht dasselbe wie "erlaubt" (positive Zustimmung). 2] Wir sind dazu verpflichtet, unsere Geodaten auf Dauer unter einer freien und offenen Lizenz zur Verfügung zu stellen. Es ist uns nicht gestattet, eine kommerzielle Lizenz zu nutzen, aber kommerzielle Organisationen sind berechtigt, unsere Daten unter ähnlichen Bedingungen zu verwenden. Nicht "ähnlich", die ODbL, wie alle offene Lizenzen, macht keine Unterschieded bezüglich Nutzungsart. Simon _______________________________________________ talk-ch mailing list talk-ch(a)openstreetmap.ch http://lists.openstreetmap.ch/mailman/listinfo/talk-ch

2 2

itinéraire des bus
by marc marc 28 Oct '17

28 Oct '17

Bonsoir, Il y a quelques années, il y a eu un import massif des arrêts de bus. La localisation des arrêts n'est pas très précise mais c'est une import pratique et la localisation des arrêts s'améliore régulièrement. J'ai même vu que les tpf utilisait un fond de carte osm pour afficher les arrêts (même si cela a l'air en panne ce soir) Par contre, les relations des itinéraires de bus eux-même n'ont pas été importées. est-ce parce qu'il n'y a pas de source opendata ? ne serrait-il pas utile d'en rechercher une pour éviter de devoir créer les lignes qui manquent manuellement ? Cordialement, Marc

4 3

Kanton Wallis - Nutzung der Geodaten
by Tobias Heinzmann 27 Oct '17

27 Oct '17

Liebe OSMler Ich habe bei bei der Dienststelle für Geoinformation des Kanton Wallis nachgefragt (siehe Mail unten) ob wir die AV-Daten für OSM benutzen können. Die Antwort ist positiv. Die Daten können benutzt werden.Reicht eine Zusage in dieser Form? Vielleicht währe es gut, wenn man dies im OSM-Wiki vermerken könnte. Wie sollte ich da am besten vorgehen? Vielen Dank für eure Hilfe Gruss Tobair | | | | | | | | | Gesendet: Sonntag, 15. Oktober 2017 21:01 An: SITVS Betreff: Nutzung der Daten für OSM Guten TagWie ich auf eurer Internetseite gesehen habe, stellt Ihr AV-Geodaten als Download via Geopol.ch zur Verfügung.Ich würde gerne diese Daten nutzen um Gebäude in Open-Street-Map (OSM) zu integrieren.https://www.openstreetmap.orghttp://wiki.openstreetmap.org/wiki… http://wiki.openstreetmap.org/wiki/Contributors#Switzerland Bei Geocat finde ich den Hinweis, dass bei den Daten der Bodenbedeckung (Gebäude) keine Anwendungseinschränkung gibt. Auch ist geschrieben, dass die Geodaten öffentich zugänglich sind. https://www.geocat.ch/geonetwork/srv/ger/md.format.html?xsl=vs_full_de&id=a… Um die Daten der Bodenbedeckung (Gebäude) für OSM nutzen zu können benötige ich eine klare positive Aussage. Bei Fragen stehe ich Ihnen gerne zur Verfügung. Um eine baldige Rückmeldung währe ich sehr dankbar. Freundliche GrüsseHeinzmann Tobias Antwort:Guten TagUnter folgendem Link können Sie die Daten direkt herunterladen:https://www.geopol.ch/#/workspaces/30Die Daten sind öffentlich zugänglich und können weiter bearbeitet resp. integriert werden. Freundliche GrüsseS.Heinzmann

4 15

Hallo
by Mark Hersche 26 Oct '17

26 Oct '17

Hallo zusammen Ich war heute auch in Bern und ein Par von euch haben mich gesehen ;) Noch eine frage kent sich jemand mit der erfassung von Wegweissern aus? Gruss aus Thun Mark

2 1

Label Node für den Kanton Zürich
by Simon Poole 23 Oct '17

23 Oct '17

Mir ist heute aufgefallen, dass der Label KNoten für den Kanton Zürich doch sehr ungünstig liegt, speziell wenn eine Karte (z.B. die HOT Karte) den Kantonsnamen noch bei relativ hohen Zoom noch anzeigt: http://www.openstreetmap.org/node/313870420/history#map=10/47.4448/8.8344 Hat jemand etwas dagegen den ca. in die Mitte des Kantons zu verschieben? Simon

3 3

DINAcon award 2017
by Simon Poole 20 Oct '17

20 Oct '17

https://twitter.com/sp8962/status/921433560334110721

2 1

Parc Naziunal Svizzer / Schweizerischer Nationalpark
by michael spreng 19 Oct '17

19 Oct '17

The Swiss National Park would like to have the German name as the main name tag in OSM. I'd like to get some opinions on this. The Swiss Parks Network (parks.swiss) has provided me with updates of the outlines of the national and regional parks in Switzerland, and I have updated them in OSM. Via this contact I was asked to change the name of the Swiss National Park from Parc Naziunal Svizzer to Schweizerischer Nationalpark. They would like to see that name on the OSM standard map. They say the park is better identified (more widely known) with the German name. I'm not sure about this. Should we accept their wish or should we insist on the naming it in Rumantsch as it is in that language region? Michael

7 12

Retina / High DPI
by Johannes Singler 18 Oct '17

18 Oct '17

Hallo zusammen! Mein Notebook hat ein High DPI Display (276 dpi), ungefähr entsprechend "Retina" auf Apple-Maschinen. Nur leider wird die hohe Auflösung von openstreetmap.org nicht unterstützt. Dabei ist sie IMHO gerade für Landkarten eine Offenbarung, wie ich finde: https://osm.rrze.fau.de/testhd.html (falls kein Retina, vergleich es bei Browser-Zoom 200%) Im Prinzip wird sie von Leaflet ja auch untersützt: http://leafletjs.com/reference.html (Flag detectRetina) Weiß jemand, ob Retina-Unterstützung auf der .org-Seite bald geplant ist? Oder könnten wir es einfach für http://routing.osm.ch/ mal aktivieren? Klar, es kostet Speicherplatz und Rechenzeit, aber es macht wirklich einen Unterschied, und es würde einen Vorsprung von Google Maps ausgleichen. Grüsse, Johannes

6 9

Weiterführung Import Geodaten Basel-Stadt
by Johannes Singler 18 Oct '17

18 Oct '17

Hallo zusammen, 2015 wurde in Basel mit dem Import von Gebäudeumrissen und Adressen von den Geodaten des Kantons Basel-Stadt begonnen. Die Ergebnisse waren IMHO sehr überzeugend, aber leider wurde das Projekt nicht fertiggestellt und ist in der Zwischenzeit eingeschlafen. Ich würde gern daran weitermachen, und habe mal mit einem Viertel angefangen, das sehr einfach ist, weil es bisher dort keinerlei Gebäudeumrisse gibt. Das OSM-File ist zum Review der Einfachheit halber angehängt. Der Import ist beschrieben unter https://wiki.openstreetmap.org/wiki/DE:Switzerland:Basel-Stadt#Datenimport_… ich habe diesen Abschnitt aktualisiert. Ich plane, für den Import den Account js-import-geodaten-basel-stadt zu verwenden. Oder soll ich einen unpersönlichen Account anlegen, den auch andere verwenden könnten? Soll ich das ganze noch auf der imports-Liste ankündigen? Erscheint mir wenig sinnvoll für so lokale Daten auf einer internationalen Liste, und die Doku ist auch nur auf Deutsch vorhanden... ausserdem wurde das Projekt letztlich schon vor längerem begonnen. Alles okay so? Dann würde ich das so hochladen und in der nächsten Zeit mit dem Hirzbrunnen-Quartier weitermachen, wo >1000 Häuser und Adressen fehlen: https://www.openstreetmap.org/#map=16/47.5661/7.6167 Gruss, Johannes

4 11

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

talk-ch