Re: [Talk-at] Kartenhinweis ohne Ortsaugenschein aufgelöst
On 10.12.20 19:27, Florian Kratochwil wrote: Was ist überhaupt der default-access-Wert für barrier=gate? Habe das auf die schnelle nicht gefunden. Erst mal muss man sich fragen, was access-Tags auf barriers überhaupt bedeuten sollen. Wer das Türl öffnen und schließen darf, oder wer durchgehen darf, oder wer sich ins Türl hineinstellen darf? Meiner Meinung nach macht nur die erste Option Sinn. Wer durchgehen darf, das ergibt sich aus den Berechtigungen auf den Weg (oder die Fläche) auf der anderen Seite. Also wenn auf dem Türl steht "Öffnen verboten" => access=private. Wenn draufsteht "Privatgrund, Betreten verboten" => access=private auf den Weg (bzw. die Fläche) auf der anderen Seite. Wenn nichts draufsteht, aber zugesperrt => keine access-Tags, nur locked=yes. Default ergibt sich aus dem Gesetz. In Östereich gilt wie wahrscheinlich überall sonst auch: Was nicht verboten ist, ist erlaubt. Defaults für highway=*: https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions Eine entsprechende Seite für barrier=* gibt es nicht, weil man "yes" annehmen kann bzw. weil die Bedeutung noch nicht definiert ist, s.o. Anderslautende Behauptungen im Wiki stammen von Einzeltätern und beruhen auf keinem Konsens. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Kartenhinweis ohne Ortsaugenschein aufgelöst
On 10.12.20 15:09, Stefan Tauner wrote: Welchen Nachteil siehst du, wenn wir solche Fälle mit permissive taggen? Für den Anwender eher keine Nachteile. Aber man öffnet damit Pandoras Büchse. Wenn hier ein Weg, auf dem kein Verbot angeschrieben ist, als permissive getaggt werden soll, weil er auf Privatgrund liegt, müssten wir konsequenterweise alle anderen Wege auf Privatgrund genauso taggen. Vom Trampelpfad auf einer Wiese bis zum Weg durch eine Wohnhausanlage. Privat hat übrigens 2 Bedeutungen: Zum einen die Besitz- und Eigentumsverhältnisse, zum anderen die Privatsphäre. Ein Grundstück kann in Privateigentum stehen, aber trotzdem frei zugänglich sein (Wald, Wiese...). Ein Schrebergarten ist vielleicht Gemeindeeigentum, aber der Pächter liegt dort nackt am Swimmingpool und verlässt sich darauf, dass keiner übern Zaun steigt. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Kartenhinweis ohne Ortsaugenschein aufgelöst
On 10.12.20 13:49, Stefan Tauner wrote: Berechtigungen nur dann taggen, wenn welche angeschrieben sind. Ist hier nicht der Fall => foot=permissive bitte weglassen. Wieso? Es ist ja offensichtlich so, dass das Privatgrund ist, aber momentan keine rechtliche Einschränkung für Fußgänger besteht, weil der Besitzer kein Schild aufgestellt hat. Er könnte aber jederzeit. Du würdest dementsprechend nur mit permissive taggen, wenn dort explizit steht "durchgang/zugang bis auf widerruf gestattet"? Ist das rechtlich nicht equivalent? In OSM mappen wir keine Gesetze, sondern was wir vor Ort vorfinden. Ohne Insiderwissen wissen wir nicht, wo der Privatgrund anfängt und aufhört, ob das Türl absichtlich oder unabsichtlich unversperrt ist, ob der Eigentümer es mag, wenn Fremde durchgehen und auch nicht ob auf den Durchgang bereits ein Servitut besteht. Wenn "bis auf Widerruf" steht, ist klar, dass ein Widerruf einzukalkulieren ist. Andernfalls müssen wir von dem ausgehen, was wir sehen. Also dass die Benutzung nicht verboten, somit erlaubt ist. Natürlich kann der Besitzer das Türl jederzeit zusperren, genauso wie er auf seinem Grundstück neue Zäune aufstellen kann. Wenn so was passiert, müssen wir die OSM-Daten halt aktualisieren. Das bei jedem Weg präventiv zu taggen wäre übertrieben, so als würde man alle Gründflächen als landuse=greenfield taggen, weil ja vielleicht irgendwann in der Zukunft drauf gebaut wird. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Kartenhinweis ohne Ortsaugenschein aufgelöst
On 10.12.20 12:51, Florian Kratochwil wrote: Bezüglich access: Also der Pfad und die Furt sowie die Stufen können vom Wald aus kommend problemlos erreicht werden ==> keine access-Einschränkung. Dann, oberhalb der Stufen wo es zum Highway=service kommt, ist ein ca. 1m-hoher Holzzaun mit einer Türe. Diese ist nicht versperrt, hat aber nur auf einer Seite (vom Bach kommend) eine Klinke. Auf der anderen Seite ist ein Knauf. Man kann aber problemlos drübergreifen und es auch von Norden kommend öffnen. Es gibt keine Hinweistafel und ich weiß nicht, ob das zu gewissen Uhrzeiten vllt mal zugesperrt wird (glaub ich aber eher nicht). ==> Ich habe das Tor mit foot=permissive getaggt. Das ist aber nicht ganz korrekt. Hat wer eine bessere Idee? Berechtigungen nur dann taggen, wenn welche angeschrieben sind. Ist hier nicht der Fall => foot=permissive bitte weglassen. Ein paar Validatoren meckern es an, wenn auf barrier=gate o.ä. keine access-Tags für foot und bicycle gesetzt sind. Dafür gibt es keine Grundlage. Trotzdem werden wegen dieser verkorksten Validatoren alle Gates mit solchen Tags zugespammt. Wenn du taggen willst, dass das Türl nicht versperrt ist: locked=no. Wenn du taggen willst, dass ein zweispuriges Fahrzeug nicht durchpasst: width=1 o.ä. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] PLZ und Ortsvorwahlen von Österreich
On 10.12.20 09:49, blank via Talk-at wrote: Aber danke für den Hinweis, wiedermal auf deine Changesets ein Auge zu werfen. Was umgekehrt weniger gut geht, denn du trittst hier als "various" oder "blank" auf, und die gleichnamigen OSM-User haben 0 Edits. Also entweder kritisierst du ohne selber was beizutragen, oder du versteckst dich hinter deiner Anonymität wie ein Sniper, der aus dem Hinterhalt heraus schießt. Das ist nicht ok. Es gibt schon lange das Sprichwort: Man zeigt nicht mit dem nackten Finger auf angezogene Leute. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gefahr durch Internet-Bergrouten
On 09.12.20 21:40, Robert Grübler wrote: Die Entscheidung der DWG halte ich für richtig, als T6 Wanderweg mappen und im note vermerken "das ist eine Kletterroute" das geht nicht. Wie ich schon tausendmal geschrieben habe, gibt es zwischen Wandern und Klettern keine klare Trennlinie. Zumal aus der Versionsgeschichte hervorgeht, dass es dort schon mehrmals zu gefährlichen Situationen kam. Dann muss man dort ansetzen, wo der Fehler passiert: In den Apps, vor Ort (Warntafeln) und ggf. auch in den Schulen (die Kinder müssen lernen, was fürs Leben wichtig ist, und da gehört heute auch dazu, Navis richtig anzuwenden und nicht alles zu glauben, was einem angezeigt wird; überhaupt sollte jungen Menschen wieder beigebracht werden, das eigene Hirn zu verwenden). Das „sport=climbing“ in der Luft hängt ist unschön, sollte sich aber mit einem passenden natural=* einfach beheben lassen. Es gibt kein passendes lineares natural. Eine Wander- oder Kletterroute ist was Menschengemachtes und ich kenne keine, die vom Einstieg bis zum Ausstieg genau einer Gratkante folgt. Auch climbing=route am Weg bietet sich an (https://wiki.openstreetmap.org/wiki/Climbing#Climbing_Routes ) Das Problem gibt es nicht nur in Kanada. Zwei Beispiele: 1.) Weg zum Tuxeck https://www.openstreetmap.org/way/125672765 Ein 7m hoher, senkrechter Kamin im UIAA Grad 3 ist doch kein T6 Wanderweg. Oder? 2.) Wiederroute auf die Watzmann-Mittelspitze https://www.openstreetmap.org/relation/1959910 Die Relation ist eine Kletterroute (diesen Relationstyp finde ich im Wiki nicht) mit UIAA-Grad 3, der darunterliegende Weg ist ein T6 path! Natürlich ist dritter Grad kein Wanderweg, aber die Grenze fix zwischen 2 und 3 anzusetzen finde ich zu unelastisch, nicht nur weil die Schwierigkeitsangaben subjektiv sind (z.B. für den unteren Herminensteig am Schneeberg gibt es in der Literatur Schwierigkeitsangaben von 1+ bis 2+), sondern auch auch andere Faktoren mit reinspielen: 1.) Die Region: Auf dem Matterhorn ist der Normalweg ein 3+, aber eben der einfachste Anstieg, über den sich jährlich Tausende wälzen und auf dem Fixseile hängen. In einer Tiefebene hingegen wird man sogar einen 1er als Kletterei empfinden. Es ist genauso bei Höhlen (in Ungarn zählen sie ab 3m als katasterwürdig, in Österreich ab 5m), Straßen (eine zweispurige Straße in der Wüste hat einen anderen Stellenwert als in einer Millionenstadt) usw. 2.) Markierung: Eine markierte Route (z.B. Preintalersteig auf der Rax) ist was anderes als ein nur in der Literatur beschriebener Anstieg, von dem vor Ort nichts zu sehen ist. Die Markierungen und Einstiegskennzeichnungen sind sogar dann, wenn man diese Route nicht geht, für die Orientierung in der Umgebung hilfreich. 3.) Bekanntheit, beliebtes Ausflugsziel: Tausende Ungarn, Tschechen, Slowaken kommen jedes Jahr um den Haidsteig zu begehen. Es wäre unpraktisch, wenn sie ihn in der Karte nicht finden würden. 4.) Dichte: Wenn man zig Routen in einem Klettergarten alle als path mappt und die Zugangswege ebenfalls path sind, kennt sich keiner mehr aus. Ich finde, die DWG sollte die Einzelentscheidung generalisieren. Ich finde, das geht sie gar nichts an. Das ist Sache der lokalen Mapper, und für eine Vereinheitlichung kann man im Wiki diskutieren und Proposals schreiben. Für mich liegt die Begründung in der Definition von „path“( https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath ): „ highway=path is a generic path, either multi-use or unspecified usage, open to all non-motorized vehicles …” Demnach dürften wir so ziemlich gar keine Wege als path mappen, denn Fahrzeuge sind auf fast allen Pfaden in Österreich verboten. Diese Definition stammt wahrscheinlich noch aus der Urzeit, als highway=path mit access-Tags als generisches Äquivalent zu highway=footway/cycleway/bridleway etc. aufgefasst wurde. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Kartenhinweis ohne Ortsaugenschein aufgelöst
On 08.12.20 19:38, Stefan Tauner via Talk-at wrote: Insbesondere sehe ich es nicht notwendigerweise negativ, in dieser Form auf anonyme Hinweise zu reagieren, wenn es keinen Grund zur Annahme gibt, dass der Hinweis falsch ist. Es gibt nicht mehr und nicht weniger Grund anzunehmen, dass die vom ursprünglichen Mapper eingetragenen Daten falsch sind. Da steht Aussage gegen Aussage, und somit gibt es für einen ortsunkundigen Mapper keinen Anlass sich einzumischen, es sei denn man kann mit Fernerkundungsmetoden eine klare Beurteilung erreichen. Das ist in diesem Fall (Berechtigung) kaum möglich. Natürlich sollte dort jemand vorbei schauen. Der ursprüngliche Autor ist (mal wieder) ein ID-User, der nicht mehr aktiv ist. Das heißt noch lang nicht, dass er auf Anfragen nicht antwortet. Die Chance auf eine Antwort ist allemal höher als bei einer Rückfrage an einen anonymen Note-Ersteller, denn der wird davon nicht mal benachrichtigt. Vorbeischauen ist natürlich sowieso gut. Es ist nur eine Frage von Aufwand und Nutzen. Es ist ärgerlich, wenn man zig km fährt und dann vor Ort feststellt, dass der Hinweis falsch war. Wenn der Note-Ersteller anonym ist, kann man ihm dann nicht mal den Kopf waschen dafür. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Kartenhinweis ohne Ortsaugenschein aufgelöst
On 08.12.20 18:49, Florian Kratochwil wrote: User Connecticut bearbeitet offenbar in ganz D und Ö diese Hinweise und hat das sehr knapp kommentiert mit "access=private", aber den Hinweis als ungelöst belassen. Das ist das, was ich als Pacman-Mentalität bezeichne. Solche Leute – und von denen gibt es sehr viele – sehen OSM wie ein Computerspiel, in dem es darum geht, Aufgaben zu erledigen. Wenn sie die Aufgaben als erledigt kennzeichnen, glauben sie, sie haben etwas geleistet. Sie vergessen dabei, dass sie nur dann etwas leisten, wenn die Daten verbessert werden, nicht wenn ein Marker von rot auf grün wechselt. Zudem fällt es auch schwer, sich einzugestehen, dass man ein Problem nicht lösen kann. Wir sind von klein auf darauf gedrillt, bei Tests irgendeine Antwort hinzuschreiben, weil man dann vielleicht doch Punkte bekommt, während man ohne Antwort ganz sicher keine Punkte bekommt. Negativpunkte für falsche Antworten werden nicht vergeben. So werden falsche Antworten also besser bewertet als gar keine. Dieser Fall war insofern eine Ausnahme, als der Note offen gelassen wurde. Vielleicht nur ein Versehen. Wenn es Absicht war, macht es das ganze auch nicht besser, denn jemand, der das richtig bearbeiten will, muss sich dann außer dem Note auch eine Vorversion mehr anschauen. Der nichtssagende Kommentar im Changeset 652409058, der nicht mal den Note referenziert, trägt noch mehr zur Konfusion bei. Mit gutem Grund steht bei anonymen Notes immer explizit die Warnung dabei: "This note includes comments from anonymous users which should be independently verified." Leider lesen viele diese Warnung nicht, oder sie verstehen sie nicht. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gefahr durch Internet-Bergrouten
On 27.11.20 03:16, Kevin Kofler via Talk-at wrote: Robert Grübler wrote: Am 19. November 2020 02:01 schrieb Kevin Kofler In dem Vergleich schneidet aber keine der Online-Karten wirklich gut ab Du meinst keine ist empfehlenswert? Ich meine, keine erfüllt die Ansprüche, die von der Tabelle gestellt werden. Ob diese wirklich notwendig oder zu hoch gesteckt sind, kann ich nicht beurteilen, weil ich so gut wie nie wandere (und wenn, dann in der Lobau in Wien oder ähnlich flachen Gebieten). Das ist genau das Problem, dass viele OSM-Kartenstilentwickler in flachen Gebieten wohnen und sich daher nicht bewusst sind, wie wichtig genaue Höhenlinien sind. Dass die "Standardkarte" überhaupt keine Höhenlinien hat, ist eigentlich eine Farce, und was sich eine Wanderkarte nennen will, braucht nicht nur irgendwelche Höhenlinien, sondern möglichst genaue. Die aus SRTM generierten Höhenlinien reichen vielleicht für Übersichtskarten im Maßstab 1:5, alle kleineren Maßstäbe sollten den 10m-Raster nutzen, der für Österreich eh schon als OGD verfügbar ist. Das gehört aus meiner Sicht also zu den Mindestanforderungen. Als Mindestanforderung sehe ich es auch, dass die Namen von Tälern, Graten usw. angezeigt werden (natural=valley/ridge/gorge/arete/cliff usw.). Und generell sollte alles angezeigt werden, was auch schon in klassischen Papierkarten dargestellt wird (Schutzhütten, Aussichtspunkte, Sessellifte, Marterln, Gipfelkreuze, Schauhöhlen usw.). Ein schwieriges Thema sind Wegmarkierungen. Bis ungefähr zur Jahrtausendwende war das eine klare Sache: Jeder Weg ist in maximal einer Farbe markiert, und die Farbe wird in der Karte angezeigt. Aber inzwischen ist das zum totalen Chaos geworden. Es ist nicht mehr möglich, in einer gedruckten oder fix gerenderten Karte alle Markierungsfarben, Wegnummern usw. anzuzeigen. Man muss da eine Auswahl treffen (z.B. nur network=rwn aufwärts und davon das Höchstrangige) oder die Karte interaktiv machen (z.B. dass beim Anklicken eines Wegstücks eine Liste der Routen kommt). Anders als Robert sehe ich die Abdeckung eines Kontinents nicht als Mindestanforderung. Wenn ich in Niederösterreich eine Bergtour mache, wird sich ein Abstecher nach Portugal und zum Ural nicht am selben Tag ausgehen. trail_visibility ist keine Mindestanforderung, aber leicht zu realisieren (z.B. strichliert vs. punktiert) und bringt verhältnismäßig viel. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hausnummern in Puch bei Hallein
On 19.11.20 14:45, andreas wecer wrote: 44 dürfte es laut PDF nur einmal geben, aber es gibt bpsw. auch Bachweg 73 Urstein Nord 73 Vollererhofstraße 73 in der Ortschaft In der Gemeinde, nicht in der selben Ortschaft. Bachweg 73 (alt) ist ganz klar eine Konskriptionsnummer und sollte eigentlich Puch 73 heißen. Vollerhofstraße sieht auch sehr nach einer Konskriptionsummer aus (vielleicht Hinterwiestal 73 oder St. Jakob am Thurn 73). Nur Urstein Nord ist eine Orientierungsnummer, und entsprechend ändert sich die jetzt nicht. Dass die Konskriptionsnummern in den letzten Jahren wie Orientierungsnummern verwendet wurden (mit Angabe des Straßennamens), ist sehr ungeschickt und wird sich jetzt rächen, denn je nach Zusteller wird ein an Bachweg 73 adressiertes Paket mal im einen, mal im anderen Haus landen. Da wär's fast besser, sie würden die Straßen gleich mit umbenennen, damit es zu keinen Verwechslungen kommt. Aber noch besser wär's gewesen, in dem Moment, wo ein Straßenname vergeben wird, gleich allen Häusern an dieser Straße Orientierungsnummern zu geben, damit der Gebrauch der Konskriptionsnummern in Verbindung mit dem Straßennamen gar nicht erst aufkommt. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hausnummern in Puch bei Hallein
On 19.11.20 12:07, andreas wecer wrote: Im konkreten Fall sind die alten Adressen aber zum Teil gar keine Konskriptionsnummern und gab es diese vor der Neuadressierung auch schon wo anders Halleiner Landesstraße 44 war früher hier: https://www.openstreetmap.org/node/5574660523 und ist jetzt hier: https://www.openstreetmap.org/node/5543882614 Wenn das keine Konskriptionsnummer war, wo war dann Konskriptionsnummer 44? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hausnummern in Puch bei Hallein
On 19.11.20 10:27, Hagen Sassnick via Talk-at wrote: nach Rücksprache mit dem Amtsleiter der Gemeinde, Herrn Schwaiger, ist es nicht erfoderlich die alten Nummern/Straßennamen zu erhalten. Dein Engegement in Ehren, aber der Amtsleiter ist jetzt nicht unbedingt ein OSM-Experte, und man muss Wunschdenken von der Realität unterscheiden. Man kann sich schon wünschen, dass nur noch die neuen Hausnummern verwendet werden, aber das ist in der Realität nun mal nicht so. Es ist in eurem (Gemeindebürger) Sinn, dass die alten Hausnummern in OSM noch irgendwie erhalten bleiben, damit z.B. ein Zusteller einen mit der alten Adresse adressierten Brief noch zustellen kann. Die Schwierigkeit liegt in der technischen Umsetzung, weil es zwar ausgereifte Taggingmöglichkeiten (addr:conscriptionnumber, addr2:* Schema) gibt, die gängigen Anwendungen aber noch ziemlich mies sind und sie noch nicht unterstützen, und diesen Teil können wir hier kaum beeinflussen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hausnummern in Puch bei Hallein
On 18.11.20 20:37, scubbx wrote: Ist die alte Adresse noch am Gebäude sichtbar? Wenn nicht, hat die eigentlich keine Bedeutung mehr, weil ja nicht mehr existent. Am 18.11.20 um 20:04 schrieb feneks via Talk-at: Das heißt, man könnte die momentan in OSM gespeicherten Adressen nach "addr:conscriptionnumber" verschieben? Erfahrungsgemäß bleiben die Konskriptionsnummerntafeln oft Jahrzehnte lang hängen, und auch in Kundendatenbanken usw. spuken sie noch viele Jahre herum. addr:conscriptionnumber ist für Konskriptionsnummern passend, aber unabhängig davon empfehle ich, die alten Adressen ins addr2:* Schema zu verschieben, damit es zu keinen Konflikten bzw. Fehlerinterpretationen kommt. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ALS-Daten frei zugänglich
On 17.11.20 17:24, Robert Kaiser wrote: Friedrich Volkmann schrieb: Wenn ich Talent für Schönreden hätte, wär ich Unternehmer oder Makler geworden und stinkreich. Die Unternehmer in dieser Gruppe, die ziemlich sicher alle nicht "stinkreich" sind, können auf solche fehlplatzierten Kommentare in Zukunft gut verzichten. Danke! Hast du den Konditionalsatz bemerkt? A ... Talent für Schönreden B ... Unternehmer geworden C ... Makler geworden D ... stinkreich Ich habe geschrieben: Wenn A, dann (B oder C) und D Du hast verstanden: Wenn B, dann D Nebenbei bin ich enttäuscht, dass dich vom ganzen Mail nur der eine Satz interessiert hat, der nichts mit dem Geländemodell zu tun hat. Das bestätigt mich nur wieder in der Prognose, dass das 1m-Modell genausowenig genutzt werden wird wie das 10m-Modell. Wenn man etwas kriegen kann, sind alle Feuer und Flamme, aber wenn es darum geht, etwas zu tun, lichten sich die Reihen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ALS-Daten frei zugänglich
On 15.11.20 18:13, Patrick Strasser-Mikhail wrote: Ich wäre einmal sehr interessiert an einer Darstellung von dir, was alles brauchbar bis super funktioniert. Man könnte den Eindruck bekommen, dass gerade _alles_ beim Zusammenbrechen ist. Meine Höhlenlinien für Garmin sind brauchbar. Ich fände es schön in deinen Beiträgen zumindest einen explizit positiven Aspekt zu finden, probiers einmal. Wenn ich Talent für Schönreden hätte, wär ich Unternehmer oder Makler geworden und stinkreich. Höhenlinien muss auch irgendwer einmal aus den Daten extrahieren. Anscheinend hast du das schon einmal gemacht. Kannst du skizzieren wie das am besten geht (Algoritmus, bestes Datenformat)? Geht das mit einem Einzeiler oder dauert das ein paar Nachmittage? Ich hab es wie gesagt für Garmin-Geräte gemacht, und zwar mit den Shellscript im Anhang. Tiles zu rendern hab ich auch probiert, aber nicht zusammengebracht, darum kann ich dazu keinen Tipp geben. Ich hab eine Garmin-Karte (.IMG) mit den genauen Höhenlinien veröffentlicht, die hat auch keinen interessiert. Wenn man nicht gerade ein Garmin-Gerät hat werden die wohl eher weniger nützlich sein. Wenn es aber außer dir sonst noch zumindest eine Person nutzen kann war es nicht nur ein privates Vergnügen (was Grund genug sein könnte sich selber sowas zu erstellen). Weiß nicht, was du mit dem Absatz ausdrücken willst. Wer als Mapper oder Anwender im Gelände unterwegs ist, kommt um Garmin kaum herum. Zwar sind die Garmin-Modelle in den letzten 10 Jahren nicht besser geworden und hochpreisige Handys haben heute auch schon einen guten GPS-Empfang, aber der Stromverbrauch und die Robustheit machen immer noch einen entscheidenden Unterschied. Ein WMS mit Höhenlinien wär super sowohl als Overlay für Online-Karten als auch als Hintergrund zum Editieren, aber das hat noch keiner gemacht. Genau. Gute Idee. Vorschläge wie man das macht? Du kannst an den Beitrag von scubbx am 20.1.2019, Message-ID , anknüpfen. Vector Tiles sind wahrscheinlich effizienter als ein WMS. Ein Webservice, das als Parameter die Koordinaten nimmt und die Seehöhe retourniert, wär auch super. Hat auch noch keiner gemacht. Genau. Gute Idee. Vorschläge wie man das macht? Während für die Höhenlinien der 10x10m-Raster völlig ausreicht, ist bei Höhenabfragen der 1x1m-Raster um Welten besser. Der braucht allerdings den 100-fachen Speicher. Österreich hat 83879 km² ≈ 10^11 m². Eine normale Datenbanktabelle mit den Feldern RW, HW und Sh braucht nach meiner Berechnung etwas in der Größenordnung von 1 TB, ist aber wegen der Hohen Anzahl Datensätze unhandlich. Geschickter ist sicherlich eine Array DB, aber damit habe ich keine Erfahrung. Die Geoinformatiker unter uns wissen wahrscheinlich, welche dafür geeignet ist. Dazu ein Apache-Webserver und ein Python/Perl/PHP/dgl. Script, das ist keine Hexerei. Ich werfe als Idee noch eine Profilfunktion ein: Man übergibt einen Pfad und bekommt ein Höhenprofil zurück. Der Pfad und das daraus erzeugte Höhenprofil bestehen nur aus diskreten Werten, die erst in der Darstellung intrapoliert werden. D.h. der Server müsste halt ein Array von Werten akzeptieren bzw. zurückgeben (JSON, XML oder banalen Plaintext mit Zeilenumbrüchen als Trennzeichen). Das ist im Prinzip nicht viel anders, als das Service für jeden Punkt einzeln aufzurufen. Die Gefahr bei sowas ist, dass es von einzelnen Usern oder Apps für Massenabfragen missbraucht wird und der Server damit lahmgelegt wird. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria all.sh Description: application/shellscript ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] ALS-Daten frei zugänglich
On 14.11.20 14:46, Robert Kaiser wrote: Was in dem Beitrag ziemlich interessant wirkt, ist - für mich zumindest - dass sie behaupten, dass das BEV demnächst ein 1m-Modell mit orthometrischen Höhen in data-gv-at zur Verfügung stellen wird. Das könnte für uns alle hilfreich werden, auch außerhalb der Steiermark... Hilfreich war auch bisher schon das 10m-Geländemodell, aber diese Hilfe hat praktisch keiner genutzt. Die meisten Karten (z.B. die auf openstreetmap.org auswählbaren) nutzen das nicht, sondern immer noch die gesch... SRTM-Daten oder sie enthalten überhaupt noch keine Höhenlinien. Ich hab eine Garmin-Karte (.IMG) mit den genauen Höhenlinien veröffentlicht, die hat auch keinen interessiert. Ein WMS mit Höhenlinien wär super sowohl als Overlay für Online-Karten als auch als Hintergrund zum Editieren, aber das hat noch keiner gemacht. Ein Webservice, das als Parameter die Koordinaten nimmt und die Seehöhe retourniert, wär auch super. Hat auch noch keiner gemacht. Darum sehe ich keinen Grund zur Hoffnung, dass sich das mit dem 1m-Modell ändern wird. Die Daten werden da sein, aber genausowenig genutzt werden wie das 10m-Modell. Wenn nur einer der Profikorrigierer, die rund um die Uhr an Multipolygonen herumpfuschen oder Wege zusammenhängen, einmal seine Zeit in was Sinnvolles stecken würde, dann wär das alles schon fertig. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gefahr durch Internet-Bergrouten
On 01.11.20 22:22, Robert Grübler wrote: Am 31. Oktober 2020 23:32 schrieb Friedrich Volkmann ... Hallo Richard, Lass dich von Friedrich nicht ins Bockshorn jagen, das ist seine Meinung und nicht die der Mapper in Österreich. Und nimm seinen Kommunikationsstil nicht persönlich, der entgleist öfters. Hast du zum Thema auch was zu sagen, oder kreisen deine Gedanken nur um mich? Was sich liebt, das neckt sich, aber Liebesbekundungen wären in PMs doch besser aufgehoben. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gefahr durch Internet-Bergrouten
On 31.10.20 21:45, Richard wrote: Ach so.. macht das Viele in Ö so? Ist das irgendwo dokumetiert? highway=path, sac_scale=*, trail_visibility=*, surface=*, usw. sowie die Routenrelationen mit Tags wie osmc:symbol stehen im Wiki. uiaa_scale=*, was ich gern verwende, steht komischerweise nicht drin. Du kannst gern eine Wikiseite dafür anlegen. In Taginfo findet man aber sowieso alle Tags für Schwierigkeitsskalen, indem man einfach nach "scale" und nach "climbing" sucht. Es gibt Leute die sich bemühen sowas wie Klettersoftware zu bauen, die würde das sicher interessieren. Mach dir keine Sorgen, die werden Taginfo schon entdeckt haben. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gefahr durch Internet-Bergrouten
On 30.10.20 23:44, Richard wrote: Tatsache ist, dass jede Versicherung einen Steig einfacher und ungefährlicher macht, und dass es von einem Steig mit einem einzigen Trittstift bis zu einem von oben bis unten durchgängig versicherten Steig alle Übergänge gibt. trotzdem sind manche Klettersteige extrem schwierig und kein highway. Es ist kein Argument, daß sie ohne Versicherung noch schwieriger wären, dann wären es eben Kletterrouten und die werden auch nicht als highway gemappt. Ich mappe sehr wohl auch Kletterrouten als highway. Nein bitte nichts "zurückändern", keine Massenänderungen und keine Edit-wars. Ihr könnt Eure Klettersteige mappen wie Ihr wollt aber lasst die anderen in Ruhe. Sag das denen, die mit dem Umtaggen angefangen haben. Insbesondere halte ich es für *sehr* schlecht wenn manch einer Couchmapper ferratas im Ausland umändert. Das sehe ich auch so, und nicht nur bei Ferratas. Insbesondere aus Deutschland pfuschen ständig alle möglichen Leute ohne Ortskenntnis in Österreich an den Daten herum. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Aufgelassenen Wanderweg mappen?
On 04.10.20 18:43, Horst Willingshofer via Talk-at wrote: Ich ging mit einem ortansässigen Begführer die neue (seit ca. 15 Jahren) Alternativroute. Diese werde ich jetzt neu mappen. Der "alte" Weg wird weder gewartet noch begangen. Laut Bergführer ist vom Weg nichts mehr sichtbar ausser ein paar alten roten Markierungspunkten. Bergführer schwindeln manchmal. Vielleicht nicht alle, aber manche. Ich hab schon so Sachen gelesen, dass Bergführer Steinmänner zerstört haben um sich selber unentbehrlich zu machen, oder dass sie behauptet haben, ein Nebengipfel sei genauso hoch wieder der Hauptgipfel, um sich die Arbeit zu ersparen, den Kunden dort auch noch hinaufzuführen. Wenn der Bergführer also sagt, dass vom anderen Weg nichts mehr sichtbar ist, dann lässt sich daraus noch nicht ableiten, dass das stimmt. Wenn das ein vielbegangener Weg war, ist i.a. unwahrscheinlich, dass nach 15 Jahren nichts mehr davon zu sehen ist. Ich habe schon Jagdsteige aufgespürt, die seit hundert Jahren in keiner Wanderkarte mehr eingezeichnet sind. Selbst wenn die Wege verwachsen sind, erkennt man sie oft noch an der Geländestufe. Die Wege werden oft auch noch Jahrzehnte vom Wild genutzt. Es gibt aber auch markierte Routen auf alpinen Karstplateaus, wo sogar bei gepflegten Markierungen und häufigen Begehungen keine Steigspur sichtbar ist, weil es egal ist, ob man 20 m weiter links oder rechts geht, solang man die Richtung beibehält. Zuverlässig beurteilen lässt sich der Zustand eines Weges nur durch eigene Begehung. Und sogar dann kann die Sichtbarkeit von der Jahreszeit abhängen. Ich denke der Weg gehört entsprechend in OSM eingetragen. Ich möchte den Weg jedoch nicht einfach löschen. Diese könnte zu Missverständnissen vor Ort oder beim Abgleich mit anderen Kartenwerken führen. Wenn der alte Weg weder sichtbar noch markiert noch in der Karte eingezeichnet ist, wie kann es dann zu Missverständnissen kommen? Der Abgleich mit anderen Kartenwerken ist irrelevant, zumindest theoretisch. Praktisch gibt es aber immer wieder Leute, die falsche Daten aus anderen Karten abzeichnen. Wenn man diese Daten rauslöscht, tauchen sie deshalb bald wieder auf, wie der Schimmel an der Wand. Ist es für Wanderwege zielführend den Tag abandoned=yes zu verwenden? Empfehlt ihr mir eine andere Vorgehensweise? Wenn du den Zustand des alten Weges nicht kennst, setz am besten einen Map Note (Kartenhinweis) auf der Openstreetmap-Website, damit ein anderer Mapper, der dort zufällig vorbeikommt, sich das nach Möglichkeit vor Ort anschaut. Nicht schaden kann es auch, in einem note=* oder fixme=* zu dokumentieren, was dir der Bergführer gesagt hat. Wenn du dem Bergführer vertraust, kannst du auch trail_visibility=* entsprechend setzen (vielleicht nicht gleich none, aber halt bad oder horrible). Man muss zwischen Sichtbarkeit des Weges und der Markierungen unterscheiden. trail_visibility=* gibt eigentlich nur die Sichtbarkeit des Weges an (Steigspur, Schneise...). Ob Markierungen sichtbar sind, entscheidet eher darüber, ob eine Routenrelation mit Markierungstags (osmc:symbol u.dgl.) noch zweckmäßig ist. Wenn der Weg nicht mehr markiert wird, aber die Markierungen noch sichtbar sind, gebietet die On-the-ground-Rule, Routenrelation mit osmc:symbol zu erhalten, nur ist halt operator vom alpinen Verein o.dgl. auf "no" oder "none" (dafür gibt es noch keinen Standard) zu ändern. disused=yes setze ich i.a. dann, wenn etwas nicht mehr in Verwendung, aber noch verwendbar ist. abandoned=yes wenn es in seiner Hauptfunktion nicht mehr verwendbar ist. Also wenn auf einem highway=track nicht mahl mehr ein Traktor fahren kann, weil schon Bäume drauf wachsen, dann tagge ich ihn mit abandoned=yes, aber als Orientierungsmerkmal oder für Fußgänger kann er noch verwendbar sein. Bei highway=path wären alpine Steige mit abgerutschten Querungen oder zugewachsene Abschnitte, wo man lieber daneben im Wald geht, Beispiele für abandoned=yes. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gefahr durch Internet-Bergrouten
On 19.09.20 15:29, Marcus MERIGHI wrote: 3) wenn ich weiss, dass mein handeln (mapping) unerwuenschte folgen (bergnot) hat, kann ich dann mein handeln fortsetzen? Selbstverständlich. Indem du Steige mappst, ermöglichst du kompetenten Nutzern eine bessere Orientierung und Tourenplanung. Wenn jemand aus den guten Daten eine schlechte Karte macht oder jemand eine Karte fürs Bergsteigen verwendet, die nicht dafür gemacht ist, oder jemand sich ungenügend auf eine Tour vorbereitet oder die Grundregeln am Berg missachtet, ist das nicht deine Schuld, sondern das fällt alles mehr oder weniger unter Missbrauch. Leider haben wir heute eine Bevormundungs- und Verantwortungsvermeidungskultur, wo denen die Schuld gegeben wird, die einen Missbrauch ermöglichen, nicht denen, die ihn begehen. Es wird heute beinah als selbstverständlich angesehen, dass erwachsene Menschen nicht mündig genug sind um eigene Entscheidungen zu treffen. Wenn Plastikmüll im Meer landet, appelliert man nicht etwas an die Menschen, kein Plastik ins Wasser zu werfen, sondern man verbietet gleich alle Plastiksackerln. Bitte macht bei solchen Trends nicht mit, denn jeder, der mitmacht, macht sich mitschuldig. 4) das mapping ist nicht das problem, sondern das rendering. wenn markierte wanderwege auf der gerenderten landkarte gleich aussehen, wie wilde(ste) steige, dann fuehrt das in die irre (siehe 3!). 5) ich moechte weitermappen, muss also versuchen, das rendering zu verbessern. Das kannst du vergessen. Ich hab schon oft versucht, zur Verbesserung von Renderern beizutragen, aber meine Vorschläge wurden durchwegs abgelehnt (ausgenommen Maroufi, dessen Wanderkarte nicht perfekt ist, aber gut genug, dass ich sie seit Jahren selber verwende). Keine der von dir aufgezählten Karten ist überhaupt für die Benutzung durch Bergsteiger konzipiert. Das sieht du ja allein schon an den ungenauen oder sogar ganz fehlenden Höhenlinien. Weil man aus einem Apfel keine Banane machen kann, hat es keinen Sinn, die Entwickler mit Anforderungen zu nerven. Man müsste einen von Grund auf neuen Kartenstil designen. Aber letztlich würden diejenigen, die sich ungenügend auf ihre Touren vorbereiten, erst wieder die falschen Karten verwenden und dann in Bergnot kommen. Ich hab schon vor Jahren eine IMG-Datei mit genauen Höhenlinien (aus OGD) für Garmin-Geräte zum Download zur Verfügung gestellt, aber verwenden tut sie keiner. Letzlich kann man Hilfen zwar anbieten, aber niemanden zu seinem Glück zwingen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mapper A* beschädigt reihenweise Relationen
On 10.09.20 00:03, Robert Grübler wrote: Ich möchte dem Mapper keine böse Absicht unterstellen, aber ich beginne mich zu fragen, ob er nicht mehr Schaden, als Nutzen anrichtet. Wenn mir eine beschädigte Relation auffällt und ich der Ursache nachgehe, ist meist er der Täter. Er benutzt den Editor iD, und damit macht man fast zwangsweise Relationen kaputt. CS 87122017 (https://openstreetmap.org/changeset/87122017) der Edit von Straßen beschädigte 7 Relationen. Grundsätzlich finde ich Straßennamen wichtiger als solche Routenrelationen, weil die Straßennamen Ortskenntnis verlangen, während die Routenrelationen mit Sofamapping repariert werden können. Das soll nicht heißen, dass ich es gut finde, wenn sie kaputt gehen, aber wenn so ein Changeset revertiert wird, sollten dann manuell die Straßennamen nochmal korrigiert werden – unter der Voraussetzung natürlich, dass die von dem User gesetzten wirklich stimmen und nicht aus anderen, falschen Datenbeständen abgeschrieben sind. CS 76715523 (https://openstreetmap.org/changeset/76715523 ) der Edit vom Kreisverkehr Bad Radkersburg beschädigte 12 Relationen. Keine Antwort auf dem CS-Kommentar. Naja, du hast keine Frage gestellt. Die tausend Busrelationen sind ein Problem für sich und praktisch unwartbar. Da darf man sich nicht wundern, wenn was kaputtgeht. Das sollte man wirklich anders lösen, z.B. jeden Abschnitt nur in eine Relation und daraus Metarelationen basteln, oder die Varianten einer Buslinie mittels Rollen kennzeichnen, oder die selteneren Varianten einfach weglassen. Das Tohuwabuhu hat ja schon angefangen mit der unnötigen Aufteilung in Hin- und Retourrouten. CS 76069278 (https://openstreetmap.org/changeset/76069278 ) der Edit vom Kreisverkehr Eibiswald beschädigte 7 Relationen. Keine Antwort auf dem CS-Kommentar. Was auffällt: (1) keine Kommunikationsbereitschaft Das kann verschiedene Ursachen haben. Manche Leute lesen ihre Mails am Handy, und da übersieht man natürlich die Hälfte der Mails, und von den übrigen wird nur jeweils nur der erste Satz gelesen. In deinem letzten Beispiel kann ich mir vorstellen, dass er einfach überfordert war und nicht verstanden hat, was das alles bedeuten soll. Wenn man nur Bahnhof versteht, neigt man dazu, die Reaktion auf das Mail aufzuschieben und bald ganz darauf zu vergessen. Daher mein Rat: Solchen Leuten nicht zu viel auf einmal schreiben. Nur ein kurzer Satz, eine einfache Frage, und wenn er antwortet, dann wieder ein kurzer Satz usw. Fehler passieren, das ist normal, aber Fehler wiederholen und die Diskussion verweigern, das ist schon problematisch. Früher war das vielleicht anders, aber heute verschwimmen immer mehr die Grenzen zwischen Unbedarftheit, Bequemlichkeit, Schlampigkeit und Ignoranz und somit auch zwischen Absicht, Fahrlässigkeit und Irrtum. Wenn CS-Kommentare wirkungslos bleiben, was kann man noch tun? Wie Stefan schon angemerkt hat, kann die DWG jemanden zeitweise sperren um ihn zum Antworten zu zwingen. Aber dann kann es sein, dass er das nicht überreißt und glaubt, dass nur die Software spinnt, und dann halt nach Ablauf der Zeit so weitermacht wie vorher. Oder dass er sich mit einem anderen Usernamen neu registriert. Generelle Regel: Je dümmer jemand ist, desto weniger kann man gegen ihn ausrichten. Aber noch gefährlicher sind die Leute, die dumm sind, aber über genug technisches Halbwissen verfügen um selber automatisierte Edits durchzuführen. Da musst du z.B. damit rechnen, dass sie deine Reverts zurückrevertieren (oder ihre Edits nach einiger Zeit wiederholen, was aufs selbe herauskommt). Noch zu Stefans Antwort: nicht nur Relationen. Gleich das 1. CS, das ich angeklickt hab (sein Letztes, https://www.openstreetmap.org/changeset/90349004) löscht ein Gebäude (vmtl. OK) inklusive allen addr-Tags (nicht OK - die Adresse löst sich ja nicht in Luft auf... und gehört dann in einen POI zumindest). Außerdem sollte der Changesetkommentar Aufschluss geben, warum man das Gebäude gelöscht hat. Nicht nur "Richtigstellung" hinschreiben. Außerdem sollte man das Objekt, selbst wenn das Gebäude abgerissen wurde, nicht löschen, sondern nur die Tags löschen und sowas wie note="Gebäude 2020 abgerissen" dazuschreiben, damit andere Mapper es nicht wieder vom Luftbild abzeichnen. Aber wie kann man das einem iD-User erklären? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Fwd: What's new @ GeoDaten Burgenland
https://geodaten.bgld.gv.at/index.php?id=172=web Irgendwas dabei, was wir für OSM verwenden können? Mag jemand einen WMS aufsetzen mit Hangneigungskarte oder mit Schummerung mit verschiedenen Beleuchtungsrichtungen? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gefahr durch Internet-Bergrouten
On 30.08.20 11:50, Robert Grübler wrote: Ein überwälzen auf den Anwender ist nur gestattet, wenn es keine technische Lösungsmöglichkeit gibt. Überwälzen kann man nur etwas, was man hat. Der Wanderer trug immer schon die Alleinverantwortung für seine Routenwahl. Das ist seit der Steinzeit so. Nur wenn der Wanderer eine Navi-App oder eine Wanderkarte kauft und der Anbieter damit wirbt, dass die Daten alle stimmen, kann man argumentieren, dass durch den Kaufvertrag ein Teil der Verantwortung auf den Anbieter (Hersteller, Händler) übergegangen ist. Aber da sind wir noch nicht beim Mapper. Wenn der Anbieter die Daten einkauft und im Kaufvertrag garantiert wird, dass die Daten alle stimmen, kann der wiederum den Daten-Anbieter zur Verantwortung ziehen. Das ist bei OSM-Daten aber nicht der Fall. Wir stellen die Daten unter einer bestimmten Lizenz zur Verfügung. Man kann drüber streiten, ob das ein Vertrag ist (durch schlüssige Handlung?), aber die Richtigkeit der Daten ist jedenfalls kein Vertragsbestandteil. Wer die OSM-Daten gratis übernimmt, trägt zu 100% selbst die Verantwortung, sie auf Richtigkeit zu überprüfen oder halt damit leben zu müssen, dass sie nicht zuverlässig sind. Leider ist – anscheinend ausgehend von den USA – die Unsitte zu uns herübergeschwappt, bei eigenen Fehlern andere zur Kasse zu bitten. Leute, die ihr Haus in die Au oder an einen Murenhang bauen, lassen sich bei einem Unwetter die Schäden vom Land ersetzen. Leute, die das Brems- mit dem Gaspedal verwechseln, verklagen den Autohersteller. Raucher verklagen bei Lungenkrebs den Zigarettenhersteller. Aktienkäufer verklagen bei einem Kursverfall den Anlageberater. Wanderer verklagen den Steigerhalter; und Navi-User, die zu blöd sind, auf die Straße zu schauen, den Navi-Anbieter. Kein Wunder, dass heute die Auto-Navis bei jedem Start seitenweise Nutzungsbedingungen bestätigen lassen. So machen sich die Anbieter noch mehr zu Nervensägen, als es die klagewütigen Kunden sind. Es ist eine der schlimmsten Seuchen der heutigen Zeit, dass keiner mehr Verantwortung übernehmen will. Es will zwar jeder die Entscheidungshoheit haben, aber nicht schuld sein, wenn was passiert. So kam es auch zu den Lockdowns, den Absagen von Veranstaltungen und der Maskenpflicht. Jeder weiß, dass das alles Blödsinn ist, aber keiner hat den Mumm, zu sagen: "Ich lasse die Veranstaltung normal stattfinden." Denn wenn es bei der Veranstaltung zu einem Ausbruch kommt, rollt ein Kopf... Mit Maskenpflict hingegen kann man bei einem Ausbruch sagen: Schaut her, mit der Maskenpflicht haben wir unser Möglichstes getan und Schlimmeres verhindert. Wenn man die Veranstaltung ganz absagt, ist man überhaupt immun gegen alle Angriffe. Bitte, wir brauchen keine allglatten Egoisten, die nur an ihr Image denken. Wir brauchen Leute mit Zivilcourage. Leute mit Mut, Verantwortung zu übernehmen. Einen Steig in OSM zu mappen, ist doch wohl das Mindeste, was ein Mapper mit Mut zur Verantwortung tun kann. Das widerspricht fundamental dem Grundsatz zu Mappen "was ist" aka "ground truth". Überhaupt nicht. Es geht nur darum es richtig zu taggen. Es spießt sich an der Begrifflichkeit „Weg“. Ein alpiner Steig, dessen Begehung alpinistische Erfahrung erfordert, ist m.E. etwas anderes als ein Wanderweg, den jeder gesunde Mensch ungefährdet begehen kann. Dann warst du noch nie wandern. Es gibt wie gesagt alle Übergänge. Und das ist nicht eine eindimensionale Skala von leicht bis schwierig, sondern es gibt unterschiedliche Schwierigkeiten, z.B. auch die Weglänge und die Höhendifferenz. Jemand mit guter Klettertechnik und schlechter Ausdauer kriegt auf anderen Steigen Probleme als jemand mit guter Ausdauer und ohne Klettererfahrung. Letztlich ist jede Routenwahl eine Optimierungsaufgabe, die von den individuellen Parametern abhängt. Wir können nur die Daten bereitstellen. Was der Anwender daraus macht, ist seine Sache. Genauso wie es die Sache desjenigen ist, der im Supermarkt ein Messer kauft, was er dann mit dem Messer macht. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gefahr durch Internet-Bergrouten
On 29.08.20 18:34, Stefan Kopetzky wrote: einfach vor kurzem wild reingelöscht, was er(?) für keine offiziellen Wege hält https://www.openstreetmap.org/changeset/88569171), was ich persönlich so, ganz ohne Diskussion für eine grobe Missachtung der Arbeit der Vormapper und wg. dem Sockenpupperlaccount, eigentlich für eine Sauerei halte. Ich wär hier für einen Revert. Nicht dass die Wege vorher unstrittig wären (access=private, width=0 etc.), aber so ists "keine Art", wie man hier sagt. Das ist nicht nur keine Art, sondern klarer Vandalismus, und da braucht ein Revert keine vorherige Diskussion. Machst du? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gefahr durch Internet-Bergrouten
On 27.08.20 19:58, PPete wrote: Der Klettersteig ist mit highway=via_ferrata getaggt. Und dieser wird in der Standardkarte - bewusst oder unbewusst - nicht eingezeichnet. Da hab ich mir gedacht, ist vielleicht gar keine schlechte Idee für die Standardkarte. So kommt man als Wanderer ohne Absichten zu Klettern nicht auf die Idee Klettersteige als "normale" Pfade zu sehen und diese in die Tourenplanung von A nach B einzubeziehen. Das ist eine ganz schlechte Idee, die aber immer wieder auftaucht. Die Proponenten gehen von zwei falschen Prämissen aus: Erstens dass versicherte Steige schwieriger oder gefährlicher sind als unversicherte, und zweitens dass sie etwas grundsätzlich anderes sind. Tatsache ist, dass jede Versicherung einen Steig einfacher und ungefährlicher macht, und dass es von einem Steig mit einem einzigen Trittstift bis zu einem von oben bis unten durchgängig versicherten Steig alle Übergänge gibt. Darum kann ich euch nur eindringlich ersuchen, alle highway=via_ferrata, denen ihr begegnet, auf highway=path zurückzuändern. Ähnliches könnte man technisch natürlich auch z.b. für Pfade mit einer Schwierigkeit von T4, T5, T6 machen. Ob das sinnvoll ist um "den normalen Wanderer" welcher die Standardkarte verwendet von der Routenführung über schwierige Pfade abzuhalten, ist natürlich eine Diskussionssache. Vor allem ist es von der Karte abhängig. In einer Bergsteigerkarte will man tendenziell auch die schwierigeren Anstiege sehen, in einer MTB-Karte eher nicht, und in einer Schifffahrtskarte blendet man vielleicht überhaupt alle Pfade aus. Es steht Mappern nicht zu, die Kartenanbieter mit einer Vorauswahl zu zwangsbeglücken. Die können sich ihre Auswahl selber machen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OSM AT Erreichbarkeit
On 20.08.20 13:21, Stefan Tauner via Talk-at wrote: Du schließt, wie leider sehr oft, von dir auf alle anderen. Und Frederik hat mit einem sarkastischen Witz auf eure Trollerein geantwortet - ganz einfach. Natürlich schließe ich von mir (und nicht von einem Fabelwesen) auf alle anderen. Und dass ich nachfrage, wenn ich etwas nicht verstehe, wird mir hoffentlich keiner vorwerfen. Wenn schon früher jemand gefragt hätte, wäre die ganze Steiterei gar nicht entstanden. Solche Streitereien entstehen nur durch Missverständnisse. Ein Sprichwort sagt, dass es keine blöden Fragen, sondern nur blöde Antworten gibt. Ich gehe davon aus, dass Frederik keine blöde Antwort gab, sondern dass er das dachte, was er geschrieben hat. Aber ich schätze, dass die Erklärung von vari...@mailbox.org ihn überzeugen wird. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OSM AT Erreichbarkeit
On 20.08.20 12:16, vari...@mailbox.org wrote: Local Chaper eher wie die Chapters von Motorradclubs. Nur, falls das jemand nicht wissen sollten https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters Ich weiß es nicht, bin kein Mitglied in einem Motorradklub. Nach der Definition, zu der dein Link führt, ist der Verein OSM AT schon ein "local chapter", wenn man von "established with the OpenStreetMap Foundation (OSMF)" absieht, wo auch wieder keiner weiß, was damit gemeint ist. Was heißt "established with"? Ich finde es sinnlos, mit solchen Worthülsen (Buzzwords) um sich zu werfen, wenn sich keiner was drunter vorstellen kann – oder sich jeder was anderes drunter vorstellt. Frederik dachte, es geht um einen Reiseführer. Darum: Wenn ihr was zu sagen habt, dann drückt euch bitte verständlich aus. Nicht auf Klingonisch und nicht im Motorradfahrer-Jargon (es sei denn, es geht ums Motorradfahren). -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OSM AT Erreichbarkeit
On 20.08.20 10:20, Frederik Ramm wrote: Gestattet mir trotzdem eine Frage: Warum redet ihr immer von einem "local Chapter"? Wovon handelt dieses Kapitel, und in welcher Publikation soll es erscheinen? Schreibt ihr an einem Buch über OSM? Können wir dazu was beitragen? Es geht dabei um dasjenige Kapitel im Reiseführer, in dem die Gaststätten aufgelistet sind. Das ist für OSM relevant, weil wir ja regelmässig Stammtische abhalten wollen, deswegen sind wir alle bemüht, dazu beizutragen. In welchem Reiseführer? Kein Mensch sucht sich ein Lokal für einen OSM-Stammtisch nach einem Reiseführer aus, und nicht alle Stammtische sind in Gaststätten. Z.B. die Treffen in Wiener Neustadt waren in der Fachhochschule, die Leobersdorfer Stammtische in einem sogenannten Hackerspace, und die Wiener Stammtische waren z.T. in Räumlichkeiten der TU Wien. Außerdem werden die Stammtische schon lang nicht mehr regelmäßig abgehalten, und jetzt mit dem Corona-Wahn ist nicht der richtige Zeitpunkt für solche Planungen. Besser kurzfristig ausmachen, also z.B. ein, zwei Wochen vorher. Aber bitte nicht erst am selben Tag, wie das auch schon passiert ist. Denn dann sehen viele die Ankündigung nicht rechtzeitig, oder sie haben den Abend schon anders verplant. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OSM AT Erreichbarkeit
On 20.08.20 00:10, scubbx wrote: Das Thema Local Chapter wird vom Verein seit ca. 2-3 Jahren immer wieder mal diskutiert. Auch dies hättest du bei jeder der öffentlichen Versammlungen mitbekommen können. Ich fordere dich auf, die Verbreitung von Unwahrheiten zu unterlassen, genauso wie wilde Vermutungen von dir nicht als Tatsachen hinzustellen. Wow. Dass dich mal jemand aus der Ruhe bringen kann! Ich verstehe nicht, worum es in diesem Streit überhaupt geht. Soweit ich mich erinnern kann, und jetzt lese ich es auch im Wiki, wurde der Verein gegründet mit dem Zweck: "OpenStreetMap in Österreich fördern, die Community in Österreich unterstützen, Ansprechpartner für Behörden oder Sponsoren sein und insgesamt den Mappern in Österreich helfen". Ich sehe nicht, was daran falsch sein kann – außer dass einige Leute im Verein ihre Freizeit dafür opfern. Gestattet mir trotzdem eine Frage: Warum redet ihr immer von einem "local Chapter"? Wovon handelt dieses Kapitel, und in welcher Publikation soll es erscheinen? Schreibt ihr an einem Buch über OSM? Können wir dazu was beitragen? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Saisonalität bei Sportgeschäften
On 13.08.20 11:38, Rudolf Mayer wrote: Sorry, aber du vergleichst hier zwei Extreme. Klar, jedes Geschäft hat so seine saisonalen *Änderungen* im Sortiment, aber hier ist es wirklich oft de-facto wie zwei ganz unterschiedliche Geschäfte. Du kannst im Eybl auch im Winter deine Golfschläger kaufen, halt nicht aus so viel Auswahl; und du bekommst in den größeren Geschäften im Winter auch dein Fahrrad, auch wenn es da vielleicht nur 20 Stück davon gibt, und nicht 100, wie im Sommer.. Aber in so einem kleinen Shop in einem Tourismusort ist es oft wirklich so, dass du im Winter ein reines Ski/Snowboardgeschäft/Wintersportgeschäft hast (in dem du keinen Tennisschläger bekommst!), und im Sommer gibt's dann dort nur Sommersport. Ich traue mich wetten, dass du auch im Sommer Schi dort bestellen kannst und im Winter ein MTB. Dass der Händler verpflichtet ist, Garantiefälle aus dem anderen Halbjahr zur Reparatur anzunehmen, habe ich schon erklärt. Das ist daher schon etwas extremer als Dein Beispiel vom Hofer - und natürlich bekommt man dort Germknödel auch im Sommer, ein unwahres Beispiel hilft Deinem Argument auch nicht wirklich... Muss ich dir das mit den Germknödeln jetzt wirklich beweisen? Was ist denn das für ein Niveau? Ob das zwei Nodes rechtfertigt ist eine andere Diskussion, aber dein Grundansatz, die Diskussion ersticken zu wollen, weil das ja "eh das selbe ist wie beim Hofer", ist meiner Meinung nach nicht gerechtfertigt, und hilft der Sache gar nicht. Was hilft denn deiner Meinung nach? Wenn du das Hofer-Beispiel als Versuch siehst, die Diskussion im Keim zu ersticken, dann war es offenbar ein gut gewähltes Beispiel, das gewirkt hat. Der einzige Unterschied, den du bisher angeführt hast, ist ein quantitativer, aber dann wirst du dir Gedanken machen müssen, wo die Grenze liegt: Ab wie viel % Unterschied im Sortiment wird es deiner Meinung nach zu einem anderen Shop? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Saisonalität bei Sportgeschäften
On 13.08.20 10:11, Stefan Tauner via Talk-at wrote: Es ist nur 1 Shop, darum sollte es nur 1 Node sein. Auch Supermärkte ändern ihr Sortiment je nach Jahreszeit. Z.B. hat der Hofer den Scamorza-Käse nur im Sommer und die Germknödel nur im Winter. Machen wir deswegen 2 verschiedene Nodes? Vergleich von Äpfel und Birnen. Ein anderes Beispiel, das ich noch kenn und das selbe Grundproblem hat, ist Dr.-Karl-Lueger-Platz 2 in Wien. Das ist im Winter ein Kürschner (kA ob noch immer, aber das spielt ja keine Rolle) und im Sommer ein Eisgeschäft. Andere Betreiber, andere Öffnungszeiten, andere Auslage, anderer Name, ... würde man auch nicht als eine Node mappen. Im Moment ist dort kein Kürschner gemappt. Aber wie du schon sagst, ist das was anderes, weil 2 verschienene Firmen. Das geht mehr in Richtung Coworking-Space. Aber sie werden mir nicht aufsperren, wenn ich zur Sommeröffnungszeit hinkomm. Wenn du um Mitternacht hinkommst, auch nicht. Das ist nun mal das Wesen von Öffnungszeiten, dass dann offen ist und sonst nicht. Saisonal unterschiedliche Öffnungszeiten gibt es auch in Gaststätten, Museen, usw., das macht ein Naturhistorisches Museum im Winter nicht zu einem anderen als im Sommer. Die derzeitige "Lösung" verschiebt das Problem auf den User, wo das in dem Fall am besten aufgehoben ist... Derzeit sind noch 2 Nodes gemappt, was keine Lösung ist, sondern ein Fehler. Die richtige Lösung besteht darin, die Nodes zu vereinigen und auf shop=sport zu ändern. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Saisonalität bei Sportgeschäften
On 13.08.20 07:51, Stefan Tauner via Talk-at wrote: in den Ski-Regionen gibt es ja desöfteren Sportgeschäfte, die komplett das Sortiment und Öffnungszeiten nach Saison umstellen (meist Fahrrad im Sommer, Ski/Snowboard im Winter). Ein paar Metadaten bleiben dabei natürlich erhalten, aber ich hab das bei meinem 1. Fall trotzdem als 2 eigenständige Nodes mit Unterscheidung im name-Tag (ja, furchtbar) gemacht, weil die Anzahl der tags recht hoch ist und ein conditional prefix auf fast allen tags etwas komisch vorkommt. Ein Problem ist dabei auch, dass die temporalen Grenzen der Saisonen nicht klar sind. Das konkrete Beispiel: https://www.openstreetmap.org/node/7795861689 https://www.openstreetmap.org/node/7795861690 Gibt's bessere Ideen? Dürfte ein recht alpin-spezifisches Problem sein vmtl. :) Schau mal ins Wiki: »Consider to use shop=sports instead and just add the services tags in case it is a "mixed" shop.« Es ist nur 1 Shop, darum sollte es nur 1 Node sein. Auch Supermärkte ändern ihr Sortiment je nach Jahreszeit. Z.B. hat der Hofer den Scamorza-Käse nur im Sommer und die Germknödel nur im Winter. Machen wir deswegen 2 verschiedene Nodes? Dass im Sommer keine Winter- und im Winter- keine Sommerware ausgestellt ist, liegt ja wohl nur am begrenzten Raum. Sogar in den Eybl-Megastores war das z.T. so. Das heißt nicht unbedingt, dass auch das Lager leergeräumt ist, geschweige dass nichts mehr serviciert/repariert wird. Wenn du im Sommer ein Rad kaufst und im Winter mit einem Garantiefall kommst, werden die dich ja wohl nicht wegschicken (sonst kannst du sie verklagen). Ich finde shop=ski sowieso albern. Kommt weltweit 228x vor und hatte nie ein Proposal. Was treibt jemanden dazu, so einen Blödsinn ins Wiki einzutragen? Was spricht gegen shop=sports (32497x) + sport=skiing (5824x)? Im konkreten Fall würde ich sport=* überhaupt weglassen, solang nicht klar ist, was sie alles haben. Laut Website haben sie im Sommer auch Wander- und Freizeitzubehör. Bei opening_hours=* musst du halt eruieren, was genau mit "Sommer" und "Winter" gemeint ist. Wenn du das nicht weißt, lass es ganz weg. Besser keine Info als eine falsche. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Anfrage Mountainbike-Weg
On 12.08.20 21:26, scubbx wrote: Ein Waldeigentümer hat angefragt, folgendem Mountainbike-Weg das Mountainbike-Tagging zu entfernen: https://www.openstreetmap.org/way/173518162/history#map=19/47.08752/15.39607 Die MTB-Tags (oder auch den ganzen Weg) aus OSM zu entfernen ist ein häufiger Wunsch von OSM-Laien, und manche Grundbesitzer melden sich extra bei OSM an nur um auf alle Wege access=no zu setzen oder sie mit Stumpf und Stiel rauszulöschen. Diesen Leuten muss man klarmachen, dass erstens der Eigentümer des Grundstücks nicht der Eigentümer der OSM-Daten ist, also insbesondere keinen Anspruch auf Löschung einzelner Tags oder der ganzen Wege aus OSM hat. Und dass zweitens die mtb:* Tags nur die Schwierigkeit beschreiben und nicht die Berechtigung. Selbst wenn das Befahren nicht erlaubt ist, kann es nicht schaden, die Schwierigkeiten zu taggen für den Fall, dass es doch mal erlaubt wird oder auch für Notfälle. Im konkreten Fall ist aber auch bicycle=yes gesetzt, was natürlich genau verkehrt ist, falls Radfahren dort wie vom Eigentümer behauptet verboten ist. Von einer Verbotstafel gibt es hier ein Foto: https://www.komoot.com/highlight/1080467 ...aber es ist aus diesem Artikel nicht klar ersichtlich, welche Weg der verbotene und welcher der erlaubte ist. Kann auch sein, dass der Karolinentrail ganz aufgelassen wurde. Solche Mountainbike-Routen kommen und gehen, und oft stehen auch noch Tafeln dabei, zu welchen Jahres- und Tageszeiten es nur erlaubt ist usw., oder dass auf man auf einem bestimmten Abschnitt absteigen und das Rad schieben muss, weil der Eigentümer gerade keine Lust auf Mountainbiker hat. So ist das eine Farce. Die Tourismusverbände versuchen mit der Bewerbung von MTB-Routen, die mehr oder weniger nur am Papier existieren, zahlende Gäste anzulocken. Das grenzt an Betrug. Kennt sich da wer vor Ort aus, wie sich die Situation dort gestaltet? Warum fragst du nicht User "pkm" direkt, der 2x explizit bicycle=yes gesetzt hat? Im übrigen fällt mir auf, dass hier schon mindestens eine Löschung wie oben beschrieben stattgefunden hat (https://www.openstreetmap.org/changeset/87923272) - die gehört revertiert. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Regionen mappen
On 11.08.20 20:32, Florian Kratochwil wrote: Das Mühlviertel habe ich gestern als admin_level umgetagged, und schwupps, wurde das rückgeändert mit dem Kommentar, es sei "keine Verwaltungsgrenze". Siehe Änderungssatz 89220166 https://www.openstreetmap.org/changeset/89220166#map=9/48.4700/14.3596 Mir persönlich ist es egal, ob es place=region oder boundary=administrative ist. Wichtig ist, dass es drinnen ist, aber es sollte einheitlich sein. Freidrich und Stefan, wie begeistert seid ihr von eurer administrative-Idee? Wollt ihr den user "Garmin-User" überzeugen, oder machen wir einfach alle Viertel als place=region? Ich habe geschrieben, dass administrative nicht ganz abwegig ist, nicht dass ich das für die beste Lösing halte. Aber der Revert durch diesen "Garmin-User" ist eine Schweinerei. Der hat wahrscheinlich noch nie ein Garmin in der Hand gehalten. Er pfuscht nur in ganz Europa an Relationen herum ohne irgendwas beizutragen. Solche selbsternannten OSM-Polizisten, die in Wahrheit selber alle Regeln verletzen, gehören lebenslang gesperrt. Ich kann auf Wunsch den Revert auch wieder revertieren... * Cisdanubien (1-20,23) vs. Transdanubien (21-22), Cisdanubien habe ich noch nie gehört. Transdanubien schon. Dagegen hätte ich nichts. Das wäre wohl place=suburb und loc_name=Transdanubien Die Bezeichnungen Cis- und Transdanubien sind genauso wie Vorarlberg, Fischauer Vorberge und Antipoden relativ zum Standpunkt und somit absurd, sobald der eigene Standpunkt auf der anderen Seite liegen kann – was in einer weltweit genutzten Geodatenbank offensichtlich der Fall ist. Weil Wien ursprünglich nur am rechten Ufer der Donau war, bezeichnen Wiener traditionell diese Seite als Cis- und die andere als Transdanubien. In Ungarn ist es aber genau andersrum, weil die Ungarn vom linken Donauufer her eingewandert sind. Wir werden hier nicht durchsetzen können, dass Vorarlberg in Ländle umbenannt wird, aber die Fischauer Vorberge können wir in OSM einfach Fischer Berge nennen und Cis-/Transdanubien als "Stadtteile" von Wien ganz weglassen. Im übrigen hören Cis- und Transdanubien nicht an der Stadtgrenze auf, weil ja auch die Donau nicht an der Stadtgrenze aufhört. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Regionen mappen
On 07.08.20 13:53, Florian Kratochwil wrote: Ich habe in den letzten Wochen ein paar Österreichische Regionen gemappt. Ich finde nämlich, dass diese in der Gesellschaft bekannten Bezeichnungen wichtig sind in OSM. Wenn eine Karte nicht "weiß", wo oder was das Waldviertel ist, dann ist das peinlich. Das Waldviertel war bereits einmal korrekt als place=region gemappt, aber irgendein Rumpelstilz hat es gelöscht. Einleitung: Es gibt verschiedene Regionstypen: Regionen können begrenzt sein durch Grenzen einer oder mehrerer Kategorien. Politische, geografische, wirtschaftliche, klimatische, kulturelle, landschaftliche, ... a) "Viertel": zB Weinviertel, Waldviertel oder Mühlviertel: Die sind landschaftlich unterscheidbar, durch ihre Geologie, ihre landwirtschaftliche Nutzung, ihr Klima. Nicht wirklich. Geologisch gehören z.B. die Neustadtler Platte und der Dunkelsteiner Wald zum Waldviertel. Ebenso hat das südliche Wiener Becken geolisch und botanisch mehr mit dem Marchfeld gemeinsam als mit dem Schneeberg. Die Viertel sind eher nur das, was der Name schon sagt: Man hat das Bundesland in ungefähr 4 gleiche Teile geteilt und die Grenzen hauptsächlich nach der Geometrie festgelegt. Es wäre sogar nicht ganz abwegig, diese Viertel als boundary=administrative + admin_level=5 zu taggen. "administrative" heißt ja nicht, dass es eine eigene Regierung gibt, sondern dass sie verwaltungstechnisch zusammengehören. Sportverbände, die ja doch so halb amtlich sind, richten z.B. einene Ligen und Meisterschaften für die Vierteln aus. Ich habe Fall a) als place=region und region:type=natural_area gemappt (Anm.: OpenTopoMap rendert Regionen, sobald es ein region:type gibt). Mit dem region:type-key bin ich nicht 100% zufrieden, wollte aber vorerst nichts neues erfinden. Es gibt bei region:type bis auf mountain_area noch keine Wiki-Empfehlungen. Gebirge gehören als natural=mountain_range getaggt, nicht als region. Die einzige logische Alternative wäre geological=*. region:type=* ist in der jetzigen Form ein Unsinn, und die Wikiseite hat ein gewisser "Geozeisig" erstellt, der schon bekannt dafür ist, alle möglichen abstrusen Tags nach eigener Lust und Laune und ohne jedwede Diskussion im Wiki zu Standards zu erklären. Von der Nutzung von Keys, deren Bedeutung noch nicht mal definiert ist, rate ich grundsätzlich ab. landcover=* ist ein abschreckendes Beispiel. Alle Keys, die mit :type bzw. _type enden, weisen schon mal darauf hin, dass der Erfinder entweder der englischen Sprache nicht mächtig genug war um sich einem sprechenderen Schlüsselnamen auszudenken (z.B. artwork:artform start artwork_type, fence:construction statt fence_type, castle:function statt castle_type, board:subject statt board_type, usw.) oder dass er sich keine Gedanken darum gemacht hat, um was für eine Art von Kategorisierung es sich überhaupt handelt. b) "Ebenen": zB Tullnerfeld, Eferdinger Becken, Marchfeld, Machland: Diese Gebiete haben meistens einen Gebirgszug am Rand, aber nicht immer (zB das Marchfeld ist durch die Donauauen im Süden begrenzt) und werden intensiv landwirtschaftlich genutzt. Ich habe das getrennt in "Grenze ist rein topografisch" (Fall b1) und "die Grenze setzt sich zusammen aus topografischen und anderen Grenzen" (Fall b2). Für Ebenen wär eher sowas wie natural=plain angemessen, analog zu natural=valley und mountain_range. Aber mir ist schon klar, dass du Ebenen unter Anführungszeichen gesetzt hast und die Beispiele nur Teile von Ebenen sind. place=region scheint mir für solche Fälle schon richtig, aber für eine Unterkategorisierung müsste man sich wie gesagt erst mal die Bedeutung des Schlüssels überlegen, bevor man sich über Tag-Werte Gedanken macht. Und jetzt habe ich entdeckt: natural=plain, zum Beispiel genutzt beim Wiener Becken und natural=basin (einige Male genutzt in der Slowakei). natural=basin kann verschiedenes bedeuten, genauso wie das deutsche Wort "Becken" verschiedenes bedeuten kann: In der Geomorphologie (und gemeinsprachlich) ist es eine Hohlform, in der Geologie hingegen ein Gebiet, wo Sediment abgelagert wird. Dass der Node fürs Wiener Becken im Weinviertel liegt, kommt wahrscheinlich von der Nationalität des Mappers, der quasi von N oder NO ins Wiener Becken herüberschaut. Ich würde den Node südlich der Donau setzen. Geologisch gesehen ist es bei Fischamend am tiefsten. --> Was meint ihr: Ist Fall b1 eher natural=plain / natural=basin als place=region? Ich finde: Wenn mountain_area ein place=region ist und kein natural (so stehts im Wiki) dann ist auch ein Becken ein place_region. Wenn man von einer falschen Prämisse ausgeht, ist natürlich auch die Schlussfolgerung falsch. Wie man diese Fälle taggt, hängt dennoch davon ab, als was man sie sieht. Man darf Ebenen / Becken (geomorph.) / Becken (geolog.) nicht durcheinander bringen, und beim Marchfeld denke ich eher an die Landwirtschaft als an die Ebene. natural=basin erfordert
Re: [Talk-at] Massenedit von Industriegebieten
On 31.07.20 03:16, Woazboat wrote: Mag vielleicht noch jemand einen Blick auf diesen Changeset werfen? Der User wurde vor zwei Tagen erstellt und editiert seither kreuz und quer vorrangig Industriegelände auf der halben Welt. Die anderen Changesets dieses Users sehen, soweit ich das nach kurzem drüberschauen bewerten kann, halbwegs sinnvoll aus, hier wurden jedoch anscheinend einfach massenhaft man_made=works Tags in Ost-Österreich gelöscht. Wenn er das weltweit macht, gehört das der DWG gemeldet, denn es hat keinen Sinn einen einzelnen Changeset zu revertieren und überall anders die Änderungen zu lassen. Was er da macht, ist das gleiche, was schon viele vor ihm gemacht haben und nach ihm machen werden. Es gibt da mehrere Kategorien von Massenumtaggern. Eine Kategorie sind Leute, die OSM für ein einzelnes Projekt (meist fürs Studium oder beruflich) ge-(oder miss-)brauchen. Wenn sie sehen, dass das Tagging uneinheitlich ist, taggen sie erst mal alles um, damit sie ihn ihrer Auswertung keine unterschiedlichen Tags berücksichtigen müssen. Eine andere Kategorie sind die Leute, die für diese Art der "Qualitätssicherung" von Firmen wie Mapbox bezahlt werden. Die machen den ganzen Tag nichts anderes, als fremde Daten umzutaggen. Dann gibt es noch die "Weltverbesserer", die das aus eigenem Antrieb heraus machen, weil ihnen fad ist und sie anders nichts beizutragen wissen. Typischerweise fängt das damit an, dass sich ein Kartenstil-, Editor- oder Validator-Entwickler in den Kopf gesetzt hat, dass ein bestimmtes Tag obsolet ist. Wenn die User einer Karte sehen, dass etwas aus der Karte verschwindet, oder die User eines Validators eine Fehlermeldung aufblinken sehen, gehen sie eifrig daran, die Daten umzutaggen, damit alles wieder richtig ausschaut. Jene User, die wissen, wie man im Wiki editieren kann, schreiben dann auch gleich hinein, dass das alte Tagging "deprecated" ist und wie man es jetzt richtig macht. Daraufhin finden sich noch mehr Leute, die die Daten systematisch "korrigieren", und im Nu sind von den Millionen Vorkommen in der Datenbank fast alle weg. Wenn man dann versucht, im Wiki eine Diskussion zu starten, wird man darauf hingewiesen, dass Taginfo ja beweist, dass das Tag fast nirgends mehr vorkommt. Und man ist ja nur ein Nörgler, und man soll aufhören zu streiten, sonst wird man gesperrt. Lange vorbei sind die Zeiten, wo man als Mapper noch was mitzureden hatte und über Änderungen demokratisch abgestimmt wurde. Aber wen wundert das in einer Zeit, wo auch die Rede- und Versammlungsfreiheit immer mehr abgeschafft wird. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] AGIT 2020 Virtuell - Vorträge
On 28.07.20 13:17, Markus Mayr wrote: Für kurze Zeit sind die virtuellen AGIT Vorträge, und somit auch die Vorträge des OSGeo Days abrufbar. * Teil #1 (OpenSource Geo Dienste): https://echo360.org.uk/lesson/6648a0f4-a0c4-4273-b2d0-09c5733119e6/classroom * Teil #2 (Open Source Desktop GIS/ QGIS): https://echo360.org.uk/lesson/15f34991-3d53-4c3f-b318-26b163d9a7e9/classroom * Teil #3 (Open Source Geodatenmanagement): https://echo360.org.uk/lesson/cd5f320c-93de-4ef5-80f3-0a1aa78edab1/classroom Da muss man sich einloggen!? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] landuse: line oder multipolygon?
On 25.07.20 15:05, Patrick Strasser-Mikhail wrote: Eine Frage zu Stil und Praktikabilität: Wenn ein detailliert gemaptes Gebiet ohne Lücken mit landuse oder gleichwertig getagt ist, dann stoßen ja immer exakt Flächen aneinander, entweder als geschlossene Linien oder als Multipolygone. Es kommt aber immer wieder einmal vor, dass Ungenauigkeiten auftauchen, wie dass die aneinander stoßenden Linien nicht immer die gleichen Punkte verwenden, und dann bei Änderungen kleine Keile entstehen, wo dann halt nix ist, oder Überlappungen. Auch ein Klassiker ist, dass highway oder ähnliches sich Punkte mit der Linie teilt und dann das eine verschoben wird, aber ungewollt das andere mit verändert wird. Mit Multipolygonen hätte man den Vorteil, dass idealerweise immer nur eine Linie eine Grenze darstellt, die von mehreren Multipolygon-Relationen verwendet wird. Nachteilig sehe ich aber, dass der Aufwand für Multipolygone deutlich höher ist, immer noch Fehler passieren können (irrtümliche einen highway als Multipolygon-Grenze gewählt), oder nicht-zusammgehörige Dingen mit einer gemeinsamen Linie "verbunden" werden. Wie du schon festgestellt hast, können so oder so Fehler passieren. Grundsätzlich sollten im Sinne einer Fehlerminimierung: - Anfänger nicht an komplexen Gebilden herumpfuschen - Leute nicht auf lustig Multipolygone anderer Mapper verändern, nur weil irgendein Validator eine Warnung ausgibt - Jene Mapper entscheiden, die in einem Gebiet am meisten mappen - denn sie sind es, die mit der gewählten Variante zurechtkommen müssen. Bitte keinesfalls Daten eines anderen verändern nur mit der Begründung, es für einen fiktiven Dritten einfacher zu machen. So à la "ich verstopfe jetzt den Rauchfang meines Nachbarn, damit kein Kind hineinfällt". Gibt es dazu - abgesehen von den technischen Ausführungen im Wiki (die sich darauf beziehen, dass ein Multipolygon halt notwendig ist, wenn es Löcher gibt und die Rolle "inner" benötigt wird) - bekannte Kriterien, wann eine geschlossene Linie und wann ein Multipolygon sinnvoll sind? Genau genommen ist ein Multipolygon nie nötig, denn man könnte die äußere Fläche als 2 Teilflächen mappen oder als sich selbst berührende Fläche (Wurm, der seinen Schwanz küsst). Aber abgesehen von technischen Problemen (z.B. früher renderte Mapnik dort, wo die Flächen zusammenstoßen, eine weiße Linie) sind solche Lösungen für andere Mapper irritierend. Eine Regel, die vielleicht nicht im Wiki steht, aber sich aus dem gesunden Menschenverstand ergibt: Jedes reale Objekt sollte als 1 Objekt in OSM abgebildet werden, und die Abbildung sollte dem Wesen nach der Realität entsprechen. Da sehen wir auch gleich ein Problem beim Verwenden von Straßen als MP-outer: Sagen wir, die Straße begrenzt den Wald, dann tritt der Waldrand etwas zurück, dann tritt er wieder an die Straße heran, usw. Man muss dann die Straße mehrmals zerstückeln. Dann hat man mehrere Ways, obwohl es in der Realität nur eine einzige Straße ist. Das gleiche Problem haben wir natürlich auch, wenn wir maxspeed etc. auf einzelne Straßenabschnitte setzen wollen. Da geht es nicht anders, aber i.a. ist es wünschenswert, das Zerstückeln zu vermeiden. Eine praktische Auswirkung dieses Zerstückelns ist, dass Suchfunktionen wie Nominatim dann die Foobar-Straße nicht 1x finden und die ganze Straße anzeigen, sondern eine Liste von 20 Straßenstückerln anzeigen. Theoretisch ließe sich das fixen, indem man den Straßennamen und -typ nicht auf die einzelnen Ways, sondern auf eine Multilinestring-Relation setzt, aber die meisten Anwendungen werten diese Relationen nicht aus, und damit verschwindet die Straße ganz von der Karte. Eine Straße (oder einen Fluss, Zaun, etc.) als MP-outer zu nehmen, bringt vor allem dann was, wenn es ein langer Abschnitt ist, auf dem sehr viele Nodes liegen. Dann wäre es umständlich, die Straße für die Landusegrenze nachzuzeichnen. Ähnliches gilt für MP vs. einfache Flächen: Wenn ein Landuse von den angrenzenden Landuses durch lange Linien mit vielen Nodes abgegrenzt ist, ist es zweckmäßig, die Flächen in Multipolygone umzuwandeln um die Linien nicht doppelt zeichnen zu müssen und dabei womöglich ein paar Nodes zu übersehen. Wenn es aber sehr viele, kurze Landuse-Grenzen mit wenig Nodes gibt, ist die Aufwandsersparnis gering. Ein MP mit vielen kurzen outer wird eher unübersichtlich und fehleranfällig. Und gibt es praktikable Werkzeuge, die es erleichtern, vom einen in das andere System zu kommen, oder auch problematische Flächen zu reparieren? Nein. Wenn du weißt, was du tust, brauchst du solche Tools nicht. Andernfalls lässt du sowieso besser die Finger davon. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at geändert
On 19.07.20 15:56, Robert Kaiser wrote: Friedrich Volkmann schrieb: On 13.07.20 08:46, Norbert Wenzel wrote: Friedrich, mittlerweile ist ein Mail eingetroffen, mit der Bitte um eine Änderung der URL. Bei mir nicht und bei Robert auch nicht. Auf dem Account, den sowohl ich als auch Norberet und Markus lesen, ist am 9. Juli eine Nachricht darübner eingegangen, darüber hat dir Norbert berichtet. Du kannst nicht am 13. behaupten, dass ich nichts bekommen habe, wenn ich das am 6. gesagt habe, denn in der Woche dazwischen kann viel passieren. Soll das heißen, dass ihr alle drei diese wichtige Info, von der zumindest du schon wusstest, dass ich darauf warte, 4 Tage lang zurückgehalten habt? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at geändert
On 13.07.20 15:07, Wolfgang Schreiter wrote: On 13.07.20 11:34, Wolfgang Schreiter wrote: Der Versatz von geoimage zur basemap beträgt ca. 0.13; -0.44 (JOSM Versatz-Einstellungen). Was bedeuten diese Zahlen, und wo kommen sie her? https://josm.openstreetmap.de/wiki/Help/Action/ImageryAdjust "east and north offset in Mercator coordinates" Zugänglich in JOSM unter Hintergrund -> Neuer Versatz. 0.44 Grad erscheint mir ein bisschen viel, wahrscheinlich sind damit Meter gemeint? Dass das weder im JOSM-Dialogfenster noch in der Doku erklärt ist, ist ein grobes Versäumnis! Außerdem ist nicht gerade offensichtlich, wie die Vorzeichen einzugeben sind: Heißt -0.44, dass der Hintergrund 0.44 m Versatz aufweist oder dass JOSM ihn um -0.44 m zurechtrückt? Bzgl. Lagegenauigkeit: ich habe jetzt mal schnell mit Google Maps und NÖ Atlas verglichen. Geoimage stimmt etwas besser überein, ist auch noch geringfügig daneben. Bei der letzen amtlichen Orthofotogeneration (2016-2018) zumindest in NÖ ist irgendwas schiefgegangen, die Lagegenauigkeit hat gegenüber den vorigen zwei Versionen abgenommen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at geändert
On 13.07.20 11:34, Wolfgang Schreiter wrote: Der Versatz von geoimage zur basemap beträgt ca. 0.13; -0.44 (JOSM Versatz-Einstellungen). Was bedeuten diese Zahlen, und wo kommen sie her? Wenn du in JOSM einen Versatz siehst, wär interessant, was in JOSM lagerichtig ist: geoimage oder basemap? Wie kann ich das überprüfen? DGPS? Seit wir vom Problem mit der Kontinentalverschiebung wissen (siehe anderen Thread), ist das alles viel komplizierter geworden. Aber ich lasse das jetzt mal beiseite. Eine einzelne Messung wär auch mit DGPS nicht genau genug. Aber es reicht normales GPS, wenn du einen längeren GPS-Track von einer Wanderung mit dem zu überprüfenden Hintergrund vergleichst, am besten in offenem, ebenen Gelände (unbewaldetes Plateau) um Reflexionen zu vermeiden. Im Schnitt sollte der GPS-Track gleich oft östlich und westlich von N-S verlaufenden Wegen liegen, usw. Eine andere Möglichkeit besteht darin, die Bilder mit atlas.noe.gv.at zu vergleichen (wo wir von hoher Lagerichtigkeit ausgehen können). Die Koordinaten eines markanten Punktes kann man ja sowohl dort als auch im OSM-Editor auslesen. Ein nicht notwendiges, aber hinreichendes Kriterium zum Erkennen eines nicht lagerichtigen Hintergrundes ist es, wenn sich die Lage von OSM-Nodes relativ zum Hintergrund beim Verschieben des Kartenausschnitts ändert. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at geändert
On 13.07.20 09:45, Wolfgang wrote: Mit JOSM funktioniert die neue URL, schärfer wird das Bild aber dadurch (jedenfalls im getesteten Ausschnitt) nicht. Sieht bei mir gleich aus wie basemap Orthofoto, Dann sind die vordefinierten Einstellungen in JOSM offenbar ungenügend. bloß mit ein paar cm Versatz. Ein paar cm? Das liegt doch unter der Wahrnehmungsgrenze. Ein wahrnehmbarer Versatz würde mich wundern. Als die Basemap-Schummerungsläyers hinzukamen und mir in Merkaartor der Versatz gegenüber geoimage.at auffiel, schaute ich mir das in JOSM an, und dort gab es keinen Versatz. Ich ging seither davon aus, dass Merkaartor da irgendeinen Bug hat. Wenn du in JOSM einen Versatz siehst, wär interessant, was in JOSM lagerichtig ist: geoimage oder basemap? Hab's im Wiki aktualisiert, wann das aktiv wird kann ich aber nicht sagen. Änderungen im OSM-Wiki werden sofort aktiv, anders als in der Wikipedia, wo jede Änderung von einem privilegierten User freigegeben werden muss (und mitunter lässt das Jahre auf sich warten). -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at geändert
On 13.07.20 08:46, Norbert Wenzel wrote: Friedrich, mittlerweile ist ein Mail eingetroffen, mit der Bitte um eine Änderung der URL. Bei mir nicht und bei Robert auch nicht. Geoimage: ich würde Sie bitten, falls nicht ohnehin schon so implementiert, den Geoimage DOP-WMS in ihrer Anwendung nur mit der Base-URL https://gis.lfrz.gv.at/.. bspw. https://gis.lfrz.gv.at/wmsgw/?key=4d80de696cd562a63ce463a58a61488d=1.1.1=GetCapabilities=WMS Kannst du mal probieren ob das der Grund für deinen Fehler ist? Das ist nicht mein Fehler, sondern der Fehler des Bundesrechenzentrums. Die haben beim WMS die Domain heimlich von gis.bmnt.gv.at auf gis.lfrz.gv.at geändert. Wenn man diese Änderung im Editor nachzieht, funktioniert es wieder. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at geändert
On 06.07.20 13:52, Robert Kaiser wrote: Friedrich Volkmann schrieb: On 26.12.19 17:36, Robert Kaiser wrote: Friedrich Volkmann schrieb: On 26.12.19 16:20, Robert Kaiser wrote: Ja, das haben sie vor einiger Zeit an alle geschrieben, die bei Geoimage registriert sind, so auch auf unsere Info-Adresse: Nicht an alle. Ich bin dort auch registriert und hab das Mail nicht bekommen. Die Registrierung ist eigentlich fürn Hugo, weil man weder diese Benachrichtigungen zuverlässig kriegt noch den WMS-Server besser nutzen kann (obwohl das ursprünglich vorgesehen war). Ah, interessant. Ich dachte, dass das wohl an alle rausgegangen ist und hab's daher nicht an die Liste hier weitergeleitet. Sorry. Ist aber jetzt auch geschehen. Hoffentlich denken wir dran, wenn wieder mal so eine Nachricht kommen sollte. Ist es jetzt wieder soweit? geoimage.at-Hintergrund geht bei mir mindestens seit gestern nicht mehr. basemap.at-Hintergründe gehen noch. Keine Ahnung, ich sehe keine Nachricht von Geoimage. Gibt es irgendwen, bei dem geoimage.at noch funktioniert? Oder ist es allen wurscht, dass es nicht mehr funktioniert? Vor ein paar Jahren hätten hier noch alle in Panik aufgeschrien bei einem so langen Ausfall. Das basemap.at-Orthofoto ist kein gleichwertiger Ersatz, weil erstens unschärfer und zweitens in Merkaartor über 1m versetzt (genauso wie die Geländeschummerung). -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at geändert
On 26.12.19 17:36, Robert Kaiser wrote: Friedrich Volkmann schrieb: On 26.12.19 16:20, Robert Kaiser wrote: Ja, das haben sie vor einiger Zeit an alle geschrieben, die bei Geoimage registriert sind, so auch auf unsere Info-Adresse: Nicht an alle. Ich bin dort auch registriert und hab das Mail nicht bekommen. Die Registrierung ist eigentlich fürn Hugo, weil man weder diese Benachrichtigungen zuverlässig kriegt noch den WMS-Server besser nutzen kann (obwohl das ursprünglich vorgesehen war). Ah, interessant. Ich dachte, dass das wohl an alle rausgegangen ist und hab's daher nicht an die Liste hier weitergeleitet. Sorry. Ist aber jetzt auch geschehen. Hoffentlich denken wir dran, wenn wieder mal so eine Nachricht kommen sollte. Ist es jetzt wieder soweit? geoimage.at-Hintergrund geht bei mir mindestens seit gestern nicht mehr. basemap.at-Hintergründe gehen noch. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Anpassung der Plattentektonik
On 03.07.20 00:43, Kevin Kofler wrote: So genau sind die Koordinaten, die wir eintragen, doch in der Regel gar nicht. 1. Viele Features werden auf Sicht gemappt, d.h., der Mapper schaut ungefähr, auf welcher Höhe einer Referenzlinie (z.B. Häuserfront) ein POI ist und klickt dann im Editor ungefähr dort hin. 2. Ebenfalls häufig ist das Abpausen von einer Hintergrundkarte. Auch das ist gewissermaßen "auf Sicht". Und außerdem sind die Hintergrundkarten auch nicht immer ganz exakt. 3. Selbst, wenn tatsächlich eine GPS-Messung vorgenommen wird, ist diese mit einem Meßfehler behaftet. D.h., ±1m ist ein relativ kleiner Fehler. Mit einem normalen GPS kriegt man die Toleranz (HDOP) kaum unter 2 m. Das ist aber – zumindest in ebenem, freiem Gelände – ein nicht-systematischer Fehler, d.h. je mehr Messungen, desto genauer wird es. Dann kann man auch auf unter 1 m kommen. Der Kontinentaldrift erzeugt hingegen einen systematischen Fehler. Das meiste wird, wie du eh schon angesprochen hast, nach Hintergrundkarten, z.B. Orthofotos und Laserscan, gemappt. Die sind meist schon ziemlich genau (Fehler <1m). Für den Höhlenkataster schaue ich mir meistens mehrere Luftbilder, Geländeschummerung und Hangneigung an, um möglichst genaue Koordinaten zu bekommen. Soviel mal als Gegenbeispiel zur Behauptung, dass wir eh alles nicht so genau machen. Wenn jemand POIs entlang einer Rerenzlinie ausrichtet, dann ist es vielleicht erst mal ein Trost, dass wenigstens die Relative Lage zueinander stimmt. Aber das ist nicht von Dauer. Sobald die Referenzlinie auf neuen Orthofotos woanders zu sehen ist, wird der nächste Mapper die Lage (z.B. des Häuserfront oder der Straße) korrigieren, die POIs daneben aber nicht. Das war schon damals so, als wir von Yahoo abgezeichnet haben (Fehler > 10 m, IIRC). Als dann die Bing-Bilder verfügbar wurden, korrigierte jeder die Straßen und keiner die POIS. Der Mistkübel südöstlich der Kreuzung war dann auf einmal nordwestlich der Kreuzung, und der Shop auf der einen Seite des Häuserblocks, zur Straße X hin, war dann auf der anderen Seite, zur Straße Y hin. Wege werden schon zurechtgerückt, wenn der Unterschied zum Orthofoto nur 1 m beträgt. Ich tu das selber auch, obwohl ich weiß, dass das Orthofoto auch nicht überall so genau ist und womöglich sogar das alte lagerichtiger war. Ein Unterschied von 1 m ist auffälliger, als man glauben möchte. Merkaartor hat einen Bug, durch den er die basemap-Geländeschummerung um 1-2 m nach W versetzt anzeigt. Das fliegen einem die Augen raus, wenn man das sieht. Ich zeichne zwar oft von der Schummerung ab, bemühe mich aber, diesen Versatz manuell zu kompensieren, indem ich alles um 1-2 m weiter östlich einzeichne. Vielleicht kommt dieser Versatz gerade daher, dass Merkaartor bei der Umrechnung nicht die richtige Epoche angibt? Fazit ist also, dass dort, wo man am Luftbild nichts sieht, die Koordinaten immer falscher werden, weil sie nie wer korrigieren wird, während dort, wo man am Luftbild was sieht, zusätzlich zu absoluten Lagefehlern auch noch relative hinzukommen werden. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Anpassung der Plattentektonik
On 02.07.20 14:54, Frederik Ramm wrote: On 02.07.20 14:35, scubbx wrote: Hui, peinlich! Gar nicht mal so - die Australier bei OSM denken inzwischen ernsthaft drüber nach, ob sie da was machen sollen. Deren Regierung gibt wohl demnächst neue, korrigierte Luftbilder raus und dann ist alles, was bisher bei OSM abgezeichnet wurde, ein bisserl falsch... Ein bisserl falsch ist es jetzt auch schon, nur fällt es noch nicht so auf. Im Blogpost ist eine Grafik und darin steht ein Link, der tatsächlich zu so einer Karte der NASA führt. Wenn ich dort die Messung für Mattersburg (= näheste für Wien) anklicke, wird eine Bewegung von 21.726 mm nach O und 15.942 mm nach O angezeigt. D.h. 27 mm ungefähr nach NO. Nach 37 Jahren sind alle Koordinaten um 1 m falsch. Das mag manchen wie ein langer Zeitraum erscheinen, aber die Zeit vergeht schneller, als man denkt. Seit ich zum Mappen angefangen habe, sind schon 10 Jahre vergangen. Also immerhin schon mehr als ¼ m Drift seither. In Merkaartor kann ich bei den Koordinaten (Grad) 7 Nachkommastellen eingeben. Wenn ich die letzte Ziffer um 1 verändere, ergibt das rund 3 cm, also ziemlich genau die Distanz, die der jährliche Drift ausmacht. Auf Dauer werden wir um eine automatische Anpassung wahrscheinlich wirklich nicht herumkommen. Je früher wir dafür etwas ausarbeiten, desto weniger blutig wird der erste Schnitt werden. Die Anpassung muss nicht unbedingt in den Daten selber vorgenommen werden, sondern kann auch erst bei der Abfrage passieren. Für eine Anpassung in den Daten sind entweder eine große Anzahl Nachkommastellen oder ein Schwellwert (z.B. 50 cm) nötig um akkumulierte Rundungsfehler zu vermeiden. Oft war von einer neuen API-Version die Rede (mit eigenem Flächentyp und was weiß ich was noch alles). Da sollte dann auch ein Attribut fürs Koordinatendatum mit rein. Wenn das nicht versorgt ist, kann als Koorinatendatum jenes angenommen werden, an dem der Node erstmals diese Koordinaten erhielt. Die Editoren wiederum können beim Abzeichnen von Luftbildern das Flugdatum o.ä. als Koordinatendatum hernehmen. Wenn man einen GPS-Track in den Editor lädt, dann sollte natürlich dessen Datum auswählbar sein. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] shop=second_hand vs. shop=charity
On 25.06.20 12:14, Kevin Kofler wrote: beim Korrigieren des Taggings des 48er-Tandlers: https://48ertandler.wien.gv.at/ (der war doppelt getaggt, und außerdem als shop=antiques, was nicht wirklich passend ist) bin ich darauf gestoßen, daß sich die Definitionen im englischsprachigen und im deutschsprachigen Wiki widersprechen. Und zwar geht es um Trödelläden, deren Einnahmen wohltätigen Zwecken zukommen, wie es beim 48er-Tandler der Fall ist: https://48ertandler.wien.gv.at/site/karitatives-engagement/ Im englischsprachigen Wiki heißt es unter: https://wiki.openstreetmap.org/wiki/Tag:shop%3Dsecond_hand A privately owned shop selling second hand goods, purely for the benefit of the owner (not for charity). und es wird vorgeschlagen, stattdessen shop=charity mit second_hand=yes zu verwenden: https://wiki.openstreetmap.org/wiki/Tag:shop%3Dcharity A charity shop is a shop operated by a charity, for the purposes of fundraising. Im deutschsprachigen Wiki heißt es hingegen, shop=charity wäre für Sozialkaufhäuser: Ein Sozialkaufhaus ist ein Geschäft, in dem gebrauchte und kostenlos abgegebene Produkte sehr günstig, zu symbolischen Preisen oder entgeltfrei angeboten werden. Da geht es primär um den niedrigen Preis für den Käufer, nicht um den Zweck der Einnahmen. Also, was ist das sinnvollere Tagging hier: a) shop=charity, second_hand=yes (wie im englischsprachigen Wiki), b) shop=second_hand, charity=yes oder c) ganz was anderes? (Warum nicht second_hand=only? Weil es auch Fanartikel der MA 48 zu kaufen gibt.) shop=second_hand wurde am 21.11.2009 in die Map Features (d.h. als Standard) eingetragen (https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:shop=376750=376704) mit der Beschreibung: "A shop bying and selling used clothes and other things" Für shop=charity wurde am 29.12.2009 die Feature-Page angelegt (https://wiki.openstreetmap.org/w/index.php?title=Tag:shop%3Dcharity=396992), und am 8.6.2010 wurde es in die Map Features eingetragen (https://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:shop=484707=484703). Die erste Beschreibung lautete: "A charity shop is a shop operated by a charity, for the purposes of fundraising." Soweit ich es sehe, wurden beide Tags ohne eine Diskussion, geschweige einen Proposal-Prozess dokumentiert. Aber die späteren Verschönbesserungen einschließlich der abweichenden deutschen Übersetzung sind noch weniger autorisiert. Grundsätzlich finde ich, dass die Tagwerte für shop=* etwas darüber aussagen sollen, was dort verkauft wird und nicht was mit den Erlösen passiert. Ersteres ist es, was die Anwender normalerweise interessiert und was vor Ort überprüfbar ist. Was mit dem Geld passiert, ist nicht überprüfbar, und "wohltätiger Zweck" ist ein dehnbarer Begriff. Man könnte genausogut einen Laden, der Microsoft-Produkte vertreibt, als shop=charity taggen mit der Begründung, dass ein Teil des Geldes der Bill-und-Melinda-Gates-Stiftung zufließt. Meiner Meinung nach ist also die englische Dokumentation von shop=charity eine Themenverfehlung, und die deutsche Dokumentation ist genauso verwerflich, weil ihr nicht zusteht, von der englischen abzuweichen. Es gehört erst mal die englische Version ausgebessert. Bis dahin würde ich shop=charity nicht verwenden, weil es als "nomen dubium" wertlos ist. shop=second_hand passt für den 48er-Tandler gut genug, und den komischen Zusatz "purely for the benefit of the owner (not for charity)", den vor 2 Jahren ein Verrückter ins Wiki hineingeschrieben hat, kannst du dort getrost wieder rauslöschen. Dass es beim 48er-Tandler auch Fanartikel zu kaufen gibt, ändert nichts daran, dass es primär ein Second-Hand-Shop ist. Danach hat sich die Klassifizierung zu richten. Denn bei Maintags sind mit Strichpunkt getrennte Werte generell verrufen (shop=second_hand;gift genauso wie amenity=cafe;restaurant, highway=footway;cycleway, natural=cave_entrance;spring usw.). -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Irreführendes Nominatim-Ergebnis
On 18.06.20 12:28, Florian Ledermann wrote: hat einer für euch eine Erklärung, warum eine Suche bei Nominatim nach "Schelleingasse 8" als erstes Ergebnis die Node "Alois-Drasche-Park 8" liefert? Weil Nominatim nicht für Adresssuche konzipiert ist. Es ignoriert alle addr:* Tags mit Ausnahme der Hausnummer (und soweit ich weiß addr:place). Auffällig ist allerdings noch, dass Adress-Nodes im Alois-Drasche-Park von Nominatim anscheinend generell nicht gefunden werden (z.B. https://nominatim.openstreetmap.org/search.php?q=Alois-Drasche-Park+8 ) - keine Ahnung ob das etwas damit zu tun hat... Im vorigen Beispiel hat es diesen Node aber gefunden (wo es falsch war). Dem Draschepark hingegen ordnet Nominatim keine außerhalb befindlichen Nodes zu, da er kein highway ist. Ich würde gerne das Tagging verbessern Falscher Ansatz, denn der Fehler liegt nicht im Tagging, sondern in Nominatim. Verbessern müsstest du also Nominatim, oder einfacher ganz neu schreiben. Eine Alternative zu Nominatim würden sicher viele begrüßen. Nominatim ist auf schnelle Aktualisierung optimiert, nicht auf Korrektheit der Ergebnisse. Normalerweise will man das Gegenteil. Ob die Daten minutenaktuell sind oder von voriger Woche, interessiert selten wen. Ich habe in meinem Auto noch ein Navi aus 2010 und finde trotzdem überall hin. Ganz nützlich wär vor allem eine API, in der man nach Ort/Straße/Hausnr/PLZ/Firmenname usw. in separaten Feldern (CGI-Parametern) suchen kann. Nominatim unterscheidet das alles nicht. Ob du nach 1040 Wien Alois-Drasche-Park 8 oder nach Wien 8 Alois-Drasche-Park 1040 suchst, ist Nominatim egal. Das ist so, wie wenn du von einem davonfahrenden Bankräuber die Autonummer W729476 notierst und sie einem Polizisten gibst, und der schreibt zur Fahndung aus: "Kennzeichen mit einem 2er, einem 4er, einem 6er, 2 7ern, einem 9er und einem W" -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Flurnamen im Wienerwald von Basemap
On 30.05.20 10:06, Florian Kratochwil wrote: In der "echten" Basemap sind zahlreiche Flurnamen eingetragen, die sich in OSM noch nicht finden. Die Namen kenne ich meist nicht und kann sie vor Ort auch nicht verifizieren. Dann vergiss sie. Ich überlege jetzt, ob ich die nebenbei nach OSM abschreiben soll. Rechtlich sollte es ja passen (das nehme ich an, weil im JOSM würde es sonst wohl nicht als Hintergrundkarte angeführt werden. Bitte um Einspruch, wenn dem nicht so sein sollte). Aber ich weiß nichts über die Qualität der Basemap-Namen bzw. deren Verortung. Habt ihr da eine Einschätzung? Fehlerbehaftet? Erwünscht? Das kann alles mögliche sein: Bergnamen, Talnamen, Waldnamen, Flurnamen, Riednamen... Meist sind diese Namen aus den alten Grundstückskatasterkarten abgeschrieben. Die findest du z.B. auf mapire.eu, wenn du dort den Franziszeischen Kataster auswählst. Diese Katasterkarten setzten sich aus unzähligen Kartenblättern zusammen, die alle nur kleine Areale umfassten. Zur Orientierung wurde oft in eine Ecke irgendwas geschrieben, was dort in der Nähe war. Also nicht unbedingt genau dort. In die Basemap wurden diese Bezeichnungen aber genau dort übernommen, wo sie auf dem Katasterblatt eingezeichnet waren. Wenn ein Berg o.dgl. auf 2 Katasterblättern zur Orientierung am Rand hingeschrieben wurde, ist er in der Basemap also u.U. doppelt - zusätzlich zur eigentlichen Gipfelbezeichnung. Die Schreibweise kann unterschiedlich sein; dann fällt es gar nicht so auf, dass der Name mehrmals vorkommt. Wenn es wie ein Bergname aussieht und es ist ein Berg in der Nähe, von dem sonst kein Name bekannt ist, dann stehen die Chancen gut, dass jener Berg so heißt. Das gleiche gilt für Täler. Aber man muss auf jeden Fall mitdenken. Ein place=locality Node ist meistens falsch, und dann die Lage erst recht. Den Fehler, diese (vermeintlichen) Flurnamen ungeprüft aus der Basemap abzuschreiben, machen leider viele Mapper, und mitunter kommt man mit dem Löschen gar nicht nach. Das ist so ein ähnliches Problem wie mit den Straßennamen, die in der Basemap ja ebenso oft falsch sind. Kaum hat man sie gelöscht, kommt schon der nächste und schreibt sie wieder aus der Basemap ab. Irgendwie scheinen jene, die alles aus anderen Karten abschreiben wollen, nicht viel von OSM zu halten. Denn sonst würden sie nicht davon ausgehen, dass die Daten in der anderen Karte stimmen und in OSM nicht. Sonstige Ideen, wo ich diese Namen Doppel-Checken könnte? Auf mapire die Originale ansehen - und nicht nur den Kataster, sondern auch die 3 Landesaufnahmen. Aber aufpassen: Die können ebenfalls fehlerhaft sein. Hilfreich sind oft Karten, die man auf den Gemeindeämtern bekommt, und heimatkundliche Literatur, z.B. Orts-Chroniken. Und natürlich kann man versuchen, die Anwohner und Grundbesitzer zu fragen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Abzeichnen von OpenTopoMap?
On 25.05.20 08:43, Patrick Strasser-Mikhail wrote: Nicht alles ist Österreich. Hier schon. Was glaubst du, wofür das "AT" in Talk-AT steht? Und warum es für OSM zig verschiedene Mailinglisten gibt? Für das Land, in dem du mappst, gibt es wahrscheinlich auch eine. Auf jeden Fall gibt es zwei Mailinglisten für Lizenzfragen: Legal-general und legal-talk. Dort kommst du an die Leute, die sich mit Lizenzfragen auskennen. Wenn du die Frage gleich dort gestellt hättest statt hier, hättest du dir viel Zeit erspart und mir auch. Wenn du eine Frage zu Katzennahrung hast, fragst du ja auch nicht in einem Hundeforum nach, oder? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Abzeichnen von OpenTopoMap?
On 24.05.20 20:28, Patrick Strasser-Mikhail wrote: Ich zeichne gerade in einer sehr spärlich gemappten Region der Welt grundlegende Dinge (Straßen, Gewässer, Wald/Farmland, Gebäude). Ich verwendet JOSM, mit den in JOSM vorhandenen Hintergründen. Normalerweise ist in der Gegend Bing die beste Quelle, manchmal ist OpenTopoMap hilfreich, um die Luftbilder besser zu interpretieren: in welche Richtung fließt das Gewässer, ist der Weg hier plausiebel, ist das Gelände eher sehr Steil und nicht wirklich bearbeitbar usw. Ich wurde in einem Kommentar darauf aufmerksam gemacht, dass OpenTopoMap als Quelle wegen der SRTM-Lizenz ungeeignet ist. Die Lizenzfrage erübrigt sich, weil es sowieso keinen Sinn hat, irgendwas aus der Opentopomap abzuzeichnen. Die Geländedaten sind aus SRTM, und das ist irrsinnig ungenau. Es stehen viel genauere Geländedaten (10m-Raster) als OGD zur Verfügung, und die Openslopemap nutzt diese bereits für ihre (folglich viel genaueren) Höhenlinien. Ich hab für Garmin-Geräte ebenfalls schon die genauen Höhenlinien zum Download bereitgestellt, und man könnte auch einen Vector-Tile-Server aufsetzen mit diesen Höhenlinien. (Hat noch keiner gemacht, wär aber super.) Ob ein Weg plausibel ist, siehst du aber auch mit dem 10m-Raster nicht, dafür aber mit dem Geländeschummerungslayer von basemap.at. Dass Bing die beste Quelle ist, kann ich kaum glauben, denn Bing ist bekannt dafür, oft mehrere Meter daneben zu liegen, sogar in flachem Gelände. Kein Wunder, weil Bing das genaue amtliche Geländemodell und wahrscheinlich auch die Fixpunkte nicht zur Verfügung hat und die Luftbilder somit nicht danach ausrichten kann. Verwende im Normalfall lieber geoimage.at. Bing kann aber hilfreich sein, wenn z.B. ein Waldweg auf geoimage.at wegen der Vegetation oder wegen eines schiefen Winkels nicht gut sichtbar ist. Manchmal ist er auf Bing besser sichtbar - aber man muss dann beim Abzeichnen den Versatz berücksichtigen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Lime Betriebsgebiet Wien
On 26.04.20 09:22, Robin Daeneke.at wrote: mir ist heute dieses Changeset [0] aufgefallen, in dem das Lime-Betriebsgebiet insgesamt als landuse=commercial gemapt wurde. Ich glaube nicht, dass das so gehört, wollte aber hier mal nachfragen, bevor ich das Changeset reverte. Ist es so richtig, gehört es reverted, oder gibt es eine Alternative, wie man solche “Bediengebiete” abbilden kann? Können tut man viel, aber so etwas hat in OSM nichts verloren. Lime ist eine Firma und ihr Betriebsgebiet im Prinzip nur ein Vertragsbestandteil zwischen der Firma und ihren Kunden, genauso wie Tarifzonen von Verkehrsbetrieben, Zustell- und Telekomunterunternehmen oder in welche Bezirke eine Pizzeria gratis liefert. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Grundlegende Frage zu OSM / crosseye Marketing
On 20.04.20 12:23, Laura Pöckelhofer ... crosseye Marketing wrote: 1. Ein Kunde von uns betreibt eine Pension. Muss ich diese Pension jetzt als Gebäude UND als Punkt anlegen? Oder reicht es, das Gebäude mit dem Tag amenity=guest_house zu versehen und alle wichtigen Informationen einzugeben? Im Normalfall setzt man alle Tags aufs Gebäude. Wenn das Gebäude aber weitläufig ist und die Pension nur auf einer Seite ist, dann kann es hilfreich sein, einen Punkt (Node) dort anzulegen oder - wenn man es genauer machen will - die Pension als Teilfläche des Gebäudes einzuzeichnen. Das gleiche gilt, wenn in einem Gebäude zwei verschiedene Dinge vorkommen, die man nicht vermischen will, z.B. eine Pension und eine Fleischerei, vor allem wenn sie unterschiedliche Eigenschaften haben (Name, Öffnungszeiten...). 2. Ein weiterer Kunde betreibt ein Gasthaus, in dem 3 kleine Gästezimmer vermietet werden. Ist es jetzt korrekt, wenn ich das Gebäude mit der Kategorie Restaurant anlege und die Pension als Punkt im Gebäude? Da das Gasthaus ja der Hauptbetrieb ist. Ja. Es ist eine von mehreren Möglichkeiten. Man könnte genauso für beides jeils einen Node anlegen oder auch umgekehrt alle Tags aufs Gebäude setzen (da amenity=restaurant und tourism=guest_house unterschiedliche Schlüssel haben). Es hängt von der Sichtweise ab: Sieht man alles als ein und dasselbe an (typischerweise mit "Gasthof..." im Namen), oder als weitgehend voneinander unabhängig, oder ist das Gebäude im Wesentlichen ein Gasthaus, und die Gästezimmer nehmen nur einen kleinen Bereich ein... Der Vollständigkeit halber sei noch erwähnt, dass die Unterscheidung zwischen Gasthöfen und Hotels sowohl im normalen Sprachgebrauch als auch in OSM ziemlich schwammig und willkürlich ist. Während gesetzlich vorgegeben ist, dass sich nur Gastwirtschaften mit Nächtigungsmöglichkeit "Gasthof" nennen dürfen (im Ggs. zu "Gasthaus", "Wirtshaus" etc.), gibt es so ein gesetzliches Kriterium für Hotels meines Wissens nicht. Unter einem Hotel stelle ich mir vor, dass es eine Rezeption gibt, während man in einer Pension den Gastgeber mitunter am Handy anrufen muss oder stundenlang auf ihn warten muss, wenn man was braucht. Ein Gasthof kann das eine oder das andere sein, es gibt etliche 3- und 4-Stern-Hotels mit "Gasthof" im Namen. In OSM war der Unterschied zwischen Hotels (tourism=hotel) und Pensionen (tourism=guest_house) früher so definiert, dass es in einem Hotel etwas zu essen gibt. Das trifft natürlich auf jeden Gasthof zu. Wie ich jetzt sehe, hat das inzwischen jemand umdefiniert (ohne Absprache übrigens), so dass die Unterscheidung in OSM genauso schwammig ist wie im normalen Sprachgebrauch. Ob das gut oder schlecht ist, sei dahingestellt, aber zumindest kann man jetzt guten Gewissens jedes Hotal als tourism=hotel taggen und jeden Gasthof als tourism=guest_house + amenity=restaurant. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] serice=alley am Lande
On 17.03.20 20:59, Patrick Strasser-Mikhail wrote: In ganz Österreich gibt es viele highway=service (Haus- und Hofzufahrten ohne weiter Verbindungsfunktion), die zusätzlich service=alley (also "Enge Gasse, Versorgungssgasse") haben[...] Also, wo kommt es her und was macht man damit? Wer oft englische Texte liest, denkt auf Englisch anders als auf Deutsch. Weniger Geübte übersetzen jeden Englischen Satz Wort für Wort auf Deutsch um ihn zu verstehen (und umgekehrt um etwas auf Englisch von sich zu geben). Wenn eine Bedeutung scheinbar klar ist, weil es ein ganz ähnlich aussehendes deutsches Wort gibt, neigt man dazu, sich das Nachschlagen im Wörterbuch zu ersparen. Darum fallen Ungeübte auf viele "falschen Freunde" herein, z.B. kam mir in verschiedenen Firmen unter, dass "aktuell" konsequent mit "actual" übersetzt wurde oder "muss nicht" mit "must not" und "darf nicht" mit "may not". Berühmt ist der Fall, wo ein Journalist Brian Ferry gegenüber dessen Songs als "pathetic" lobte und der dann eingeschnappt war. Solche "falschen Freunde" sind auch "alley" und "Allee". Ich glaube, dass die Existenz von Bäumen neben einer Straße manche Mapper dazu bewegt, die Straße als "alley" zu taggen. Wo ich falschen service=alley begegnet bin, war meistens auch highway=service schon dubios. Das sollte nur für unmittelbare Zufahrten zu einem oder sehr wenigen Objekten verwendet werden. Wenn eine Zufahrt länger ist, ist sie nicht mehr nur eine Zufahrt zum Gehöft, sondern auch zu den Feldern/Wiesen/Wäldern neben der Straße. Oft zweigen sogar Feldwege ab, womit sich ein Wegenetz ergibt. Solche vermeintlichen Zufahrten sollten besser als highway=track (oder evtl. unclassified bzw. residential) getaggt werden, nicht als service. Was man damit macht? Umtaggen halt. Aber noch besser ist es, den jeweiligen Mapper anzuschreiben, damit er den Fehler nicht immer wieder macht. Aber wenn du jemanden anschreibst, dann warte erst mal seine Antwort ab, bevor du alles von ihm umtaggst. Jemanden vor vollendete Tatsachen zu stellen und dann so zu tun, als wär man zu einer Diskussion bereit, ist Heuchelei und kommt entsprechend schlecht an. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wien "Zählbezirke" unvollständig und falsch -> historische Vorstäde falsch getagged
On 29.12.19 19:19, realadry wrote: In der offiziellen OSM Karte werden Namen angezeigt und ich habe wie dumm gesucht woher die kommen. Aber jetzt sehe ich erst, dass es einen Node mit "place=suburb" gibt wo der Name in der Karte steht... Zufällig deckt sich das aber mit den falsch gemappten "Zählbezirken". Nein, das deckt sich nicht, denn die Zählbezirke sind flächig gemappt, die Suburbs hingegen als Place-Nodes auf die Ortskerne. Kann es also sein, dass hier nicht Zählbezirke sondern diese historischen suburbs von mmarinschek gemapped wurden? Nein. Mit den Suburbs ist das eine längere Geschichte, weil ursprünglich auch die Katastralgemeinden als Suburbs gemappt waren. Ich hab das getrennt und die Katastralgemeinden (die ja definierte Grenzen, aber nicht unbedingt Siedlungskerne haben) zu Boundary-Relationen gemacht und nur dort die Place-Nodes gelassen (bzw. ergänzt), wo die Namen mit Siedlungskernen korrespondieren, und zu diesen hab ich sie hingeschoben. Das war alles viel Arbeit und es ist jetzt einheitlich, wiki-konform und praktikabel und darum bitte ich dich, das so zu lassen. [1] Bestätigt auch, dass es ein historischer Ort ist und nicht mehr existiert. [1]https://www.geschichtewiki.wien.gv.at/Gumpendorf_(Vorstadt) Es existiert sehr wohl noch, denn da ist heute weder Wald noch Wiese, sondern dicht verbautes Gebiet mit einem klar erkennbareren Siedlungskern mit Kirche, Hauptplatz (Kurt-Pint-Platz) und Hauptstraße (Gumpendorfer Straße). Wir hatten hier schon eine ähnliche Diskussion wegen Nikolsdorf. Jemand plädierte für eine Löschung, weil es keiner mehr kenne. Aber ein Freund, den ich fragte, weil er in diesem Bezirk wohnt, meinte nur: selbstverständlich kennt er Nikolsdorf. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wien "Zählbezirke" unvollständig und falsch
On 29.12.19 17:17, realadry wrote: Mir ist zufällig aufgefallen, dass die Zählbezirke in Wien (boundary=statistical) völlig falsch und dazu auch unvollständig sind [1] Hier gab's vor ein paar Jahren eine Diskussion dazu, und soweit ich mich erinnern kann, war die Conclusio, dass die Zählbezirke eigentlich keiner braucht. Aber nachdem sich schon jemand (mmarinschek, der aber bald danach das Handtuch warf und in OSM nicht mehr aktiv ist) die Mühe gemacht hatte, haben wir die schon gemappten nicht rausgelöscht, sondern nur so umgetaggt, dass sie nicht stören. Ich glaube, boundary=statistical war meine Erfindung. Ich frage mich, was ist die Quelle der bisher eingetragenen (source=* fehlt), Das solltest du nicht dich selber, sondern mmarinschek fragen. woher kommen die Namen (Das Ortsverzeichnis [2] enthält völlig andere Namen z.B. "Gumpendorf" gibt es nicht) und sollten wir nicht (automatisch?) die offiziellen Grenzen [3] eintragen? Wenn du sie berichtigen und vervollständigen kannst, dann nur zu. "Problem" ist, dass viele Karten (jaja wir mappen nicht für den renderer usw..) diese Gebiete (boundary=statistical) beschriften, auch wenn sie in Wirklichkeit überhaupt keine Relevanz auf einer gezeichneten Karte haben. Welche Karten tun das? Mir sind noch keine untergekommen. Wenn eine Karte boundary=statistical auswertet, dann wird das hoffentlich einen guten Grund haben, sonst solltest du das dem Kartenanbieter als Bug melden. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Userdaten Löschen
On 28.12.19 23:19, scubbx wrote: Ich/Wir haben eine Unterstützungsanfrage von einem User erhalten, der nach DSGVO sein Konto und alle seine persönlichen Daten gelöscht haben möchte. Da ich selber damit noch nichts zu tun hatte, frage ich mich, wie das OpenStreetMap handhabt. Weiß jemand mehr dazu, bzw wie man die Löschung seiner persönlichen Daten erreicht? (ich gehe davon aus, dass der User NICHT von seinen Edits spricht) Das ist aber erst mal zu klären, was er genau gelöscht bekommen will. Bei einem OSM-Account bestehen die persönlichen Daten ja eigentlich nur aus der E-Mail-Adresse, der "home location" und mit etwas Fantasie auch noch Username, Passwort, PMs und Profiltext, wobei letzte beide und die home location sowieso jeder selber löschen kann. Ich glaube, soweit macht das die DWG (obwohl auch die LWG ein möglicher Ansprechpartner wäre). Ein User mit ID 12345 kriegt dann den Pseudo-Usernamen user_12345. Aber dann gibt es noch das Wiki, die Mailinglisten und Webforen... Ich schätze, dass jemand, der bei OSM Austria nachfragt, da noch nirgends aktiv war, aber wenn doch, dann müsste er sich wahrscheinlich an die jeweilgen Admins wenden. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at geändert
On 26.12.19 16:20, Robert Kaiser wrote: Ja, das haben sie vor einiger Zeit an alle geschrieben, die bei Geoimage registriert sind, so auch auf unsere Info-Adresse: Nicht an alle. Ich bin dort auch registriert und hab das Mail nicht bekommen. Die Registrierung ist eigentlich fürn Hugo, weil man weder diese Benachrichtigungen zuverlässig kriegt noch den WMS-Server besser nutzen kann (obwohl das ursprünglich vorgesehen war). -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] geoimage.at geändert
Bei mir ging seit einiger Zeit der geoimage.at-Hintergrund nicht mehr. Weil ein vorübergehender Serverausfall nicht so lang dauern kann, bin ich der Sache jetzt mal auf den Grund gegangen. Also für den Fall, dass ihr das selbe Problem habt: Die haben heimlich die Parameter geändert. Statt... LAYERS=Luftbild_MR,Luftbild_1m,Luftbild_8m,Satellitenbild_30m ...müsst ihr jetzt angeben einfach: LAYERS=Luftbild -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wie vielfache benannte Eingänge mappen?
On 16.11.19 09:10, Patrick Strasser-Mikhail wrote: Ich bin gerade dabei Eingänge im LKH Graz zu mappen. Das LKH Graz hat duzende Gebäude mit eigenen Hausnummern und jedes Gebäude hat normalerweise eine handvoll Eingänge. Praktischerweise sind die mit / beschildert und auch auf Lageplänen eingezeichnet. Lifttüren nach Außen haben dann Bezeichnung /L, wobei die Eingangsnummer und Liftnummern getrennt gezählt werden. Diese Information ist natürlich Gold wert und gehört in die Openstreetmap. Die Frage ist jetzt aber, wie mappen. Die Eingänge haben teilweise addr:housename dabei, worüber sich JOSM dann aufregt. JOSM ist irrelevant, aber Hausnamen sind in Österreich als Adressbestandteil unüblich, und Adressen würde ich sowieso nur auf Gebäude oder Grundstücke setzen, nicht auf Eingänge. Eingänge nur mit ref=* (und entrance=main/yes/...). Schön wäre es, wenn die Eingangsnummer gut nutzbar wären, sowohl auf der Karte als auch im Routing (z.B. um mit dem Taxi gleich zur richtigen Ambulanz zu kommen, weil ich die Türnummer weiß). Kein Taxifahrer navigiert mit OSM, und in Krankenhäusern orientiert man sich nicht nach Eingangsnummern, sondern nach Gebäuden/Pavillons und Stationen/Ambulanzen. Dafür gibt es Leitsysteme. Nicht alles, was man weiß, hat es Sinn zu mappen. Schlag dir das Mappen der Lifttüren u.dgl. gleich aus dem Kopf, das wäre Teil eines umfangreichen Indoormappings, welches als Thema einer Bachelorarbeit denkbar wäre und auch insofern dafür passen würde, als es nur akademischen Wert hätte. Der praktische Nutzen ist null. Genauso wie zwischen den Gebäuden gibt es auch innerhalb Leitsysteme und Wegweiser, und anders fände man sich innerhalb eines Gebäudes sowieso nicht zurecht. Wenn du was für die Nutzer tun willst, dann mappe die Namen der Gebäude so, wie sie am Lageplan auf der Website angegeben sind (http://www.klinikum-graz.at/cms/dokumente/10020626_2096225/f4de41b8/Lageplan-web.pdf). Die zweistelligen Nummern gehören in ref=* (oder addr:unit, falls man die Nummer als Adressbestandteil sieht) - aufs Gebäude wohlgemerkt. Das ganze Areal ist amenity=hospital + name="Landeskrankenhaus-Universitätsklinikum Graz" + short_name="LKH Graz" + alt_name=... + Adresse + Website + operator etc. Fürs Mapping der einzelnen Stationen/Ambulanzen/Abteilungen gibt es noch keinen Taggingstandard. Sonst könnte man jede davon einzeln mappen mit Angabe, in welchem Stockwerk (level=*) und ggf. in welchem Trakt (am besten flächig mappen) sie sich befindet. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On 12.11.19 03:19, Robert Kaiser wrote: andreas wecer schrieb: Am Sa., 9. Nov. 2019 um 15:16 Uhr schrieb Robert Kaiser : Der Name der Stadt und der Gemeinde ist "Steyr", das stimmt. Der Name des Bezirkes ist allerdings "Steyr-Stadt" (hauptsächlich, weil es daneben noch "Steyr-Land" gibt). Nein, Statistik Austria führt den Bezirk als "Steyr(Stadt)", wobei der Zusatz in der Klammer allerdings (im Gegensatz zu "Steyr-Land" z.B.) kein Teil des Namens ist Statistik Austria ist eine Privatfirma, kein Amt. Demnach müssten wir alle Gemeindekennziffern und Postleitzahlen aus OSM rauslöschen, weil sie von Privatfirmen definiert wurden. Ich hab bisher den Bezirk überall nur als "Steyr-Stadt" geschrieben gsehen. Und Steyr-Land ist definitiv ein ganz anderer Bezirk als Steyr-Stadt. Und sowas wie https://www.land-oberoesterreich.gv.at/147155.htm vom Land OÖ glaube ich immer noch mehr als der Bundeszwangsstitisktikfirma. Österreich ist angeblich ein Rechtsstaat, und in einem Rechtsstaat sollte nicht ein Webmaster bestimmen, was ein Bezirk ist, sondern ein Gesetz. Interessant ist, dass laut Bundesverfassung die Republik nur aus Bund, Ländern und Gemeinden besteht, die Existenz von Bezirken wird nur bei den Wahlsprengeln überhaupt erwähnt. Laut folgendem Landesgesetz bildet die Stadt Steyr einen eigenen politischen Bezirk und kann wiederum in Stadtbezirke aufgeteilt werden. Vom politischen Bezirk wird kein Name angegeben: https://www.ris.bka.gv.at/eli/lgbl/OB/1992/9/P2/LOO12004580 Vielleicht sollten wir in OSM das name-Tag der politischen Bezirke überhaupt leer lassen, weil sie offiziell gar keinen Namen haben? Aber ich bin ja der Meinung, dass nicht der offizielle, sondern der übliche Name ins name-Tag gehört. ;-) Z.B. "Südautobahn", nicht "Süd Autobahn". -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Schneekettenpflicht
On 09.11.19 12:14, Patrick Strasser-Mikhail wrote: Ich bin über eine Straße mit den Verkehrstafel gestoßen: "Schneeketten vorgeschrieben" (STVO §52 Abs a Z.22) mit Zusatztafel "Schneestern" also "Diese Zusatztafel weist darauf hin, dass das Straßenverkehrszeichen bei Schneelage oder Eisbildung auf der Fahrbahn zu beachten ist." STVO §54 Abs. 5 Lit f Ich habe ausgiebig danach gesucht, keine Idee gefunden, wie das zu mappen ist. Viele dieser Schilder werden nur dann aufgestellt (oder hervorgedreht), wenn die Jahreszeit bzw. Witterung entsprechend ist. Solche temporären Beschränkungen zu mappen hat wenig Sinn. Noch dazu gilt nicht der Umkehrschluss, dass man ohne dieses Zeichen die Straße ohne Schneeketten befahren kann. Bei winterlichen Verhältnissen ist Hirn gefragt, nicht Routing. Mit der Zusatztafel liegt allerdings nahe, dass das Schild das ganze Jahr über dort steht, und dann ist ein Tagging wie motor_vehicle:conditional="no@snow AND snow_chains=no" technisch möglich. Aber dann sollte es wahrscheinlich auch ein gleichlautendes standalone-Tag geben, und als solches wär snow_chains=yes/no weniger zweckmäßig. Vielleicht besser sowas wie tyres=any/winter/spikes/snow_chains? Keine Ahnung. Muss man sich überlegen, wenn man ein entsprechendes Proposal schreibt. Zu geben scheint es noch keins, also Bahn frei für dich, wenn du Lust hast. :-) -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On 31.10.19 11:16, Robert Kaiser wrote: Friedrich Volkmann schrieb: Kann mir schwer vorstellen, dass die Selbstbeweihräucherung als Markt in einem Unfallbericht Platz hat. Aber "in der Gemeinde Münster" oder "im Gemeindegebiet von Münster" ist in einem Unfallbericht ganz normal. Auch wenn es irgendwo im Niemandsland passiert ist (Wald, Freilandstraße), gehört jeder Unfallort zu einem Gemeindegebiet, und das gehört zu den Eckdaten einer Unfallerfassung. Dann sollten wir aber laut dir auch "Gemeindegebiet Münster" ins "name"-Tag schreiben, oder nicht? Das wär sogar eindeutiger, kommt aber seltener vor. Google-Treffer: "Gemeinde Münster" ... 34.700 "Gemeindegebiet von Münster" ... 1.950 "Gemeindegebiet Münster" ... 177 Im name-Tag soll der übliche Name stehen. Mit "Gemeinde Münster" wird zwar meistens die Behörde gemeint sein und nicht das Gebiet, doch angesichts der Zahlen liegt zumindest der Verdacht nahe, dass auch fürs Gebiet die Bezeichnung "Gemeinde Münster" die häufigere ist. "Gemeindegebiet Münster" ist dann ein Kandidat für alt_name, aber praktischen Nutzen würde ich mir keinen davon erwarten, weil alt_name eigentlich nur für Suchfunktionen gebraucht wird, und bei einer Suche tippt keiner das lange Wort "Gemeindegebiet" ein. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On 29.10.19 10:56, Florian Lohoff wrote: Das hat was mit Datenhaltung zu tun. Wenn du einmal Daten ineinander rührst gehen sie halt nicht wieder auseinander. Wenn du einmal information löscht kannst du sie nicht wieder hinzufügen. Du brauchst mir nichts von Normalisierung erzählen, ich bin Datenbankentwickler. "Bezirk Mödling" und "Gemeinde Mödling" sind eigenständige Namen, keine miteinander verrührten. Genauso wie "Florian Lohoff" ein eigenständiger Name ist und keine Mischung aus den Florians und den Lohoffs. Man kann natürlich Vorname und Nachname getrennt speichern, aber zusammen ergeben sie den Namen. Wenn du Arzt bist, wirst du als amenity=doctors mit name="Dr. Florian Lohoff" gemappt, nicht mit name=Lohoff und name:prefix=Florian. Wenn du "Multikultistadt Langstrumpf an der I." hast kriegt die Maschine das nicht mehr auseinander. Das "Multikulti-" ist ein Schmafu, den wir uns in OSM sparen können. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On 29.10.19 10:22, PPete wrote: Aus Sicht der Gemeinden in Oberösterreich, die ich etwas genauer kenne, ich wohne selbst in einer Marktgemeinde, deren Erhebung zur Marktgemeinde noch nicht so lange zurück liegt. Der Name "Marktgemeinde" mag sich zwar historisch auf das Recht zum Abhalten von Märkten beziehen. Aber heutzutage ist dieses "Recht zum Abhalten eines Marktes" recht unbedeutsam (in meiner Gemeinde wird kein regelmäßiger Markt abgehalten und falls zu vereinzelten besonderen Anlässen doch, dann wäre dieser ganz genauso auch in "normalen" Ortsgemeinden meines Bezirkes möglich und erlaubt. Wenn das "Markt-" in "Marktgemeinde nur eine leere Worthülse für den schönen Klang ist, dann ist spricht das um so mehr dafür, es in OSM einfach wegzulassen - genauso wie die Wohlfühl- und Klimabündnisgemeinden. Wiederum aber die entscheidende Frage: Was benützen wir für den "name"-Tag? Jene Bezeichnung welche in der Sprache der Bevölkerung und bei Berichten in den Medien über Ereignisse in dieser Gemeinde verwendet wird? Dann sollte man nur z.b. "Wels" verwenden. So gut wie keiner sagt: "ich fahre jetzt in die "Stadtgemeinde Wels" einkaufen. Da sagt man "nach Wels einkaufen", weil man die Siedlung (entspricht dem place-Node) meint und nicht die Gemeinde. Es gibt genug Fälle, wo man sehr Wohl "Gemeinde Wels" sagt, z.B. eine Wohnhausanlage der Gemeinde Wels (weil die Gebietskörperschaft gemeint ist und nicht die Siedlung) oder der höchste Punkt der Gemeinde Wels (= im Gemeindegebiet, nicht nur im Siedlungsgebiet). Oder "gestern wurde kam es in der Martgemeinde Kremsmünster zu einem Unfall". Kann mir schwer vorstellen, dass die Selbstbeweihräucherung als Markt in einem Unfallbericht Platz hat. Aber "in der Gemeinde Münster" oder "im Gemeindegebiet von Münster" ist in einem Unfallbericht ganz normal. Auch wenn es irgendwo im Niemandsland passiert ist (Wald, Freilandstraße), gehört jeder Unfallort zu einem Gemeindegebiet, und das gehört zu den Eckdaten einer Unfallerfassung. Mir ist wiegesagt die Variante mit name und official_name sympatischer auf Gemeindeebene, da meiner Meinung nach im Name die am häufigsten gegrauchte Variante stehen sollte. So seh ich das auch. Darum bitte Gemeinde Wels wenn von der Gebietskörperschaft die Rede ist, und nur Wels wenn von der Siedlung die Rede ist (place-Node). Und Südautobahn, nicht Süd Autobahn. Wieder anders bei Betrachtung des Bundeslandes, da wird das Wort "Bundesland" kaum dazugesagt: "Ich fahr nach Kärnten auf Urlaub". Ja, weil keine Verwechslungsgefahr besteht - außer in Wien (Land Wien / Gemeinde Wien). Eine Frage zum Abschluss, weil ich sowas noch nie gesehen habe: Wenn hier in der Debatte alle ihren Input gegeben haben, und diese auch zu einem "Ergebnis" führen soll: Wo wird denn dann schließlich überhaupt über ein Taggingschema für Österreich abgestimmt? Nirgends, weil wir ein weltweites Taggingschema brauchen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On 29.10.19 09:22, Rudolf Mayer wrote: Das "keine Geodaten" Argument wird meiner Meinung nach etwas übertrieben oft verwendet (auch wenn es für *Markt*gemeinde evtl. sogar gerechtfertigt ist). Denn bei genauer Betrachtung - was sind denn wirklich genau Geodaten? Man könnte sie definieren als solche, die sich direkt verorten lassen und nicht nur indirekt Schuhgröße der Schwiegermutter des Grundbesitzers). Aber pragmatisch nehmen wir oft auch Informationen dazu, die nicht direkt Geodaten sind, aber in gängigen Karten angezeigt werden sollen oder anders nicht verfügbar sind. Ob eine Gemeinde ein Marktrecht hat, interessiert in einer Landkarte niemanden (sondern nur wo die Marktplätze sind) und zugleich ist es eine Information, die auch in anderen Datenquellen frei verfügbar ist. Ja, eine Telefonnummer, welches Essen es wo gibt, und Öffnungszeiten sind wohl keine (primänre) Geodaten. Aber sie machen OSM wertvoll... Meiner Meinung haben diese Infos in OSM nichts verloren, erstens weil sie keine Geodaten sind und zweitens weil sie zu volatil sind. Z.B. Telefonnummern und Öffnungszeiten ändern sich so oft, dass der Anwender zur Sicherheit sowieso auf der Website des Lokals nachsehen muss, und somit ist mit dem Kopieren der Daten nach OSM nichts gewonnen. Wer solche Informationen taggt, befriedigt mehr sein eigenes Selbstwertgefühl als die Bedürfnisse der Anwender. Und genauso mag das Attribut "Markt" wertvoll sein, wenn ich eine Anwendung machen will, die z.b. die geographische Verteilung von Marktgemeinden anzeigen will. Wenn der Wenn nicht wär... Glaubst du ernsthaft, dass irgendwer so eine Anwendung haben will? Praktisch interessant sind wie gesagt nur die Marktplätze. Und eine Verknüpfung zweier Listen über die GKZ ist nun wirklich ein Kinderspiel. Da wäre der Aufwand beim Taggen und Aktuellhalten in OSM viel größer als die Zeitersparnis beim Programmieren der Auswertung. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On 29.10.19 03:33, Robert Kaiser wrote: Damit kann ich mich anfreunden. Mit Dingen wie "Marktgemeinde" oder "Bezirk" im "name"-Tag dagegen nicht. Das ist halt die Sicht eines Programmierers und keines Geografen. Programmierer sind gewöhnt, dass zwischen den Daten und dem User eine mächtige Software steht, welche die Daten auf ausgeklügelte Weise aufbereitet. Das ist in OSM aber nicht der Fall. Die Daten landen mehr oder weniger unverändert beim User. Programmierer-Grundsätze sind hier schlichtweg fehl am Platz. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On 28.10.19 10:23, PPete wrote: Genau diese Frage ist die entscheidende: Was kommt in den "name"-Tag und wird damit wohl exklusiv in fast allen Karten mit Gebietsgrenzen auch ANGEZEIGT. Na selbstverständlich "Gemeinde XYZ" bzw. "Bezirk XYZ", sonst weiß keiner, was XYZ ist. Zu dem Problem, dass man dann auf einer Karte bei der Grenzbeschriftung nicht mehr auf den ersten Blick erkennt ob es sich um eine Gemeinde- oder Bwzirksgrenze handelt (z.b. Bezirk Vöcklabruck und Stadtgemeinde Vöcklabruck): Ist eigentlich eine Sache des Renderers die BEschriftungen verschiedener Admin-Ebenen durch andere Schriftgrößen oder Farben unterscheidbar zu machen - auch wenn das im OSM-Carto Stil derzeit nicht der Fall ist und alles gleich beschriftet wird. Ganz abgesehen davon, dass die für Carto Commit-Berechtigten von erforderlichen Änderungen, die sie mangels persönlichen Bezugs nicht verstehen, erfahrungsgemäß schwer zu überzeugen sind (siehe natural=fell, addr:conscriptionnumber usw.), ist eine Unterscheidung durch den Schriftstil schwer machbar. Es gibt 11 Admin-Levels, und so groß bzw. klein kann die Schrift nicht werden, dass der Betrachter genau erkennen kann, um welche der 11 verschiedenen Größen es sich handelt. Auch bei Schriftart und -farbe stehen nicht unbegrenzt viele zur Verfügung, und jede, die man dafür "verbrät", steht für andere Kartenfeatures nicht mehr zur Verfügung oder führt zu einem Konflikt. Abgesehen davon müsste der Kartennutzer in einer Legende nachschauen können, was die Beschriftungen in den unterschiedlichen Schriftstilen überhaupt bedeuten. So eine Legende würde gewaltig groß werden, wenn sie die Verwaltungseinheiten für die ganze Welt auflisten müsste (https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative#10_admin_level_values_for_specific_countries). Ich kann nur jeden, der der Meinung ist, name="XYZ" sei ausreichend, weil der Renderer eh admin_level zur Verfügung hat, dazu einladen, auf https://github.com/gravitystorm/openstreetmap-carto/issues einen konkreten Vorschlag einzubringen und darum zu kämpfen, dass er umgesetzt wird. name="Gemeinde XYZ" / "Bezirk XYZ" ist hingegen eine Lösung, die wir sofort selber umsetzen können und die binnen weniger Sekunden für die Anwender verfügbar ist. Spatz in der Hand, Taube auf dem Dach... -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On 28.10.19 09:48, Thomas Rupprecht wrote: Was haltet ihr von diesen Varianten?: official_name=Marktgemeinde XYZ name=XYZ Erstens genau verkehrt: Der offizielle Name laut Gesetz (Verordnung?) ist nur "XYZ", der gebräuchliche ist "Gemeinde XYZ" (wohlgemerkt für die Gemeinde, im Gegensatz zum Ortsnamen "XYZ", der auf den place-Node gesetzt wird). Zweitens bitte nur "Gemeinde" statt "Marktgemeinde", denn das Marktrecht ist eine separate Information und gehört daher in ein separates Tag (sowas wie market_rights=yes oder municipal_privilegues=market oder town_status=market, bitte ggf. mit Leuten diskutieren, die sich auf Englisch damit auskennen) oder ganz weglassen (weil keine Geodaten!). oder name=Marktgemeinde XYZ short_name=XYZ Besser, aber wie gesagt statt "Marktgemeinde XYZ" nur "Gemeinde XYZ"; und statt short_name bitte official_name. short_name ist hilfreich für "St." statt "Sankt" oder zum Weglassen von Zusätzen wie "im Burgenland", "am Leithagebirge" etc., die nur zur Unterscheidung von gleichnamigen Orten bzw. Gemeinden irgendwo anders in Österreich dienen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] name:suffix & name:prefix (de)
On 28.10.19 09:42, Andreas wrote: Ich bin auch der Meinung, dass dieses Präfix im Namen eher kontraproduktiv ist. Dies hat, wie schon festgestellt wurde, teilweise negative Auswirkungen bei Suchdiensten wie Nominatim. Ganz im Gegenteil. Wenn du mit Nominatim nach "Gemeinde Mödling" oder "Bezirk Mödling" suchst, findest du sofort das Richtige, während bei einer Suche nach nur "Mödling" lauter Mist kommt. Warum das so ein riesen Problem ist, dies in einem eigenen tag zu verspeichern ist mir schleierhaft. Dann hast du mein Proposal verschlafen, auf das ich hier schon oft genug hingewiesen habe. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] geoimage.at mit Versatz
Seit 1 Tag oder so sind die Orthofotos von geoimage.at 300m nach W versetzt. (Ich habe es mit Merkaartor und mit einem alten JOSM ausprobiert.) Weiß wer wieso? Hat wer einen guten Kontakt zu denen und kann den Fehler melden? basemap.at ist von dem Fehler nicht betroffen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OSM Nutzung in Buch ohne Nennung
On 13.10.19 23:57, Michael Reichert wrote: Die Kartenbilder sind nämlich recht alt und zeigen eine mehrere Jahre alte Version des Kartenstils OSM Carto oder noch seinen Vorgänger den Mapnik-OSM-Stil. Marcus hat inzwischen klargestellt, dass das Buch aus 2014 ist. Angesichts des Alters der Daten und des stark heruntergesetzten Preises würde ich den Fall gar nicht weiterverfolgen. Ich vermute, dass da ein Ladenhüter verramscht werden soll. Das ist unsererseits den Aufwand nicht wert. Das sehe ich auch so. (Rechtlich möglich wär es aber. Die Verwertungsrechte verjähren erst 70 Jahre nach dem Tod des Urhebers.) Jeder Mapper hat nicht exklusive Nutzungsrechte an seinen Beiträgen durch die Contributor Terms an die OSMF abgetreten. Nicht abgetreten, sondern gewährt. Der Mapper verliert seine Rechte ja nicht. Er kann mit den von ihm gemappten Daten selber machen, was er will. Z.B. unter anderer Lizenz nochmals veröffentlichen. Oder gegen Urheberrechtsverletzungen vorgehen. Bei uns Deutschland wäre der Versuch, Schadensersatz wegen einer ODbL- oder CC-*-Lizenzverletzung einzuklagen, riskant, da man die Daten/das Werk kostenlos bekommt und somit "kein Schaden" entstanden ist. Bei euch in DE gibt es aber das Abmahnunwesen, wo Geld eingehoben wird unabhängig von einem Schaden. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OSM Nutzung in Buch ohne Nennung
On 13.10.19 18:41, Markus Mayr wrote: Im Abbildungsverzeichnis am Ende des Buches tauch die OSM nicht auf. ... Ich finde das Projekt und Buch eigentlich eine tolle Sache, bin aber etwas traurig, dass die OpenStreetMap darin nicht entsprechend gewürdigt wird, obwohl das den Autoren nicht geschadet hätte. Damit wendest du dich am besten an den Verein Openstreetmap Austria, vielleicht direkt an den Obmann. ;-) Denn der Verein wurde ja, soweit ich mich erinnern kann, als Schnittstelle für die Kommunikation der OSM-Community mit Dritten konzipiert. Fallback wär die LWG (Licence Working Group alias Licencing Working Group) der OSMF. Als einzelner Mapper kann man schwer was gegen so einen Lizenzverstoß unternehmen, schon gar nicht wenn man in dem Kartenausschnitt nicht selber editiert hat. Natürlich kann man immer den Verlag anschreiben, aber dann gibt es 2 Möglichkeiten: Sie ignorieren einen, oder sie entschuldigen sich. Letzteres ändert aber nichts am daran, dass das Buch schon so im Umlauf ist. Auszahlen tut sich der Kontakt nur dann, wenn der Verlag wenigstens auf seiner Website eine entsprechende Entschuldigung verlautbart. Ganz korrekt wäre es, den Verkauf des Buches zu stoppen und jedem Buch einen Zettel mit dem Lizenzhinweis beizulegen. Als (Mit-)Urheber könnte man beim Gericht einen Verkaufsstopp per einstweiliger Verfügung beantragen, oder so ähnlich. Ganz auskennen tu ich mich damit aber nicht. Bei Urheberrechtsverletzungen kann man oft auch auf Schadenersatz klagen, aber da die OSM ja kostenlos verfügbar ist, wird es schwer sein, einen finanziellen Schaden (abgesehen vom Anwaltshonorar) glaubhaft zu machen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg
On 03.10.19 23:44, vari...@mailbox.org wrote: Die Frage ist, ob 130k wirklich genug ist um von "Akzeptiert weil genug benutzt" zu reden. https://taginfo.openstreetmap.org/keys/name%3Aprefix ich glaube eher nicht :) 130k hört sich imposant an, aber wenn man die Verbreitungskarte und die häufigsten Werte ansieht, erkennt man rasch, dass dieser Key auf wenige Länder beschränkt ist. Und teilweise wurde er in Massenedits (z.B. 52736774) hinzugefügt, die nicht so aussehen, als wär damit der automated edits code of conduct eingehalten worden. Man kann aber auch nachträglich ein Proposal erstellen dafür - aber warum unbedingt einen neuen Tag erfinden und nicht einen bestehenden benutzen? Weil es dir schwer fallen wird, für name:prefix eine Bedeutung zu definieren. Und weil es für manche Länder nicht verwendbar ist. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg
On 03.10.19 20:58, eest9 wrote: Verstehe nicht warum wir in Österreich einen Sonderweg einnehmen sollten Ich auch nicht. So schwindlige Tags, die nicht mal dokumentiert, geschweige approved sind und die nur in einzelnen Ländern in Gebrauch sind (designation=* in UK, name:prefix=* in DE, official_status=* in RU), werden sich international nie durchsetzen und wir sollten keinen Gedanken mehr daran verschwenden. ein kurzer Blick nach Deutschland zeigt auf, dass auch hier die Prefixes nicht im Namen stehen, etwa hier: https://www.openstreetmap.org/relation/966163#map=13/49.3496/11.2594 Wenn du genauer hinschaust, wird dir auffallen, dass die nächsthöhere Einheit (ID=62744) "Landkreis Nürnberger Land" heißt. Und gleich angrenzen tut der "Landkreis Roth" (ID=62431). Also sehr wohl die Prefixes im Namen. Darauf hat Andreas Wecer gestern schon hingewiesen. Ist es dir zu mühsam, eine Diskussion zu lesen, bevor du etwas dazuschreibst? Was glaubst du, was passiert, wenn das alle so machen? die programmierten Anwendungen sind also nicht darauf ausgelegt, dass das Prefix direkt im Namen steht Doch, das sind sie. Siehe Standardkarte, wo diese Taggingvariante die einzige ist, die unterstützt wird. Das wir es also in einem extra Tag erfassen sollte ausreichen. Mir konnte zumindest noch niemand schlüssig erklären warum es nicht ausreichen sollte Die Frage musst du dir erst mal selber stellen, denn du hast nicht für mein Proposal gestimmt, in dem ich genau so ein Tag vorgeschlagen habe. und die letzten Jahre hat es doch auch kein Problem damit gegeben Wenn du persönlich kein Problem damit hast, heißt das noch lang nicht, dass es keines gibt. Ich z.B. habe immer wieder Probleme damit, wenn ich für den Höhlenkataster den Gemeindenamen angeben muss und in der Karte die Gemeinden nicht von den Bezirken unterscheidbar sind. Wenn ich nicht mal als lokaler Mapper mit so einem Sauhaufen arbeiten kann, wie sollen gewöhnliche Anwender es dann erst können? Das ist halt ein Fehler vieler Mapper, dass sie nur den Bildschirm vor sich sehen und nicht die Bedürfnisse der Anwender. Mappen als Computerspiel, nicht zur Schaffung von Mehrwert für andere. Darum sind auch jene Validatoren so beliebt, wo man sich wie Pacman durch die Levels frisst, sowie eine Gamingplattform mit dem bezeichnenden Namen Maproulette. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg
On 02.10.19 00:15, Rudolf Mayer wrote:
Das beste ist - nur relevante Information drinnen haben, nicht im Namen
Redundanz erzeugen, nur damit es auf carto besser aussieht.
Gemeinde/Bezirk im Namen ist keine Redundanz, da die Information woanders
nicht vorkommt.
Wenn du schon für die App mappen willst - viel besser wäre da schon "Mödling
(Gemeinde)", weil dann die wichtige Information vorne steht - und man mit
einem abgeschnittenen z.b. ("Ge..." viel mehr anfängt als mit einem
zweideutigen "Mö" o.Ä.
Ist aber insgesamt um 2 Zeichen länger.
Wie auch immer. admin_title=* gibt Anwendungen die Möglichkeit, die Namen so
anzuzeigen wie von dir vorgeschlagen. Im übrigen führt diese Anzeigevariante
den von den Deutschen bevorzugten Schlüsselnamen name:prefix ad absurdum.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg
On 02.10.19 00:29, Andreas wrote: Wenn eine Anwendung einen zusätzlichen Tag admin_level nicht beachten kann, dann ist da was faul. Dann müsste man ja auch bei Straßen im Namen davor schreiben "Gemeindestraße Hauptstraße", "Gemeindestraße Finkenweg", ... Da gibt es die Konvention, dass nur die Straßennamen der Gemeinde auf die Ways gesetzt werden, während Bundesstraßennamen auf die Relation kommen. Somit ist eindeutig, was was ist. Eine Anwendung kann mit admin_level nicht viel anfangen, solang es keine Umschlüsselungstabelle gibt. Und selbst wenn wir eine erstellen, dann fürchte ich, dass die Programmierer zu faul sind, um die Tabelle zu implementieren. Das ist ja auch bei den access- und maxspeed-Defaults so, wo es seit Ewigkeiten genaue Tabellen gibt und keiner sie nutzt. Ich habe mir das Proposal angeschaut und auch die Gründe der Ablehnung kann ich verstehen. Ich auch. Die Leute haben alle ein Brett vor dem Kopf: Sie akzeptieren nur das, was sie aus ihrem eigenen Land gewohnt sind. Das Ergebnis ist, dass keines dieser sonderbaren Tags von Anwendungen unterstützt wird. admin_level und admin_title sind keine Alternativen, sondern sie ergänzen einander, genauso wie protect_class und protection_title. Funktioniert ja in Deutschland anscheinend doch, muss man immer eigene Süppchen kochen? Funktioniert überhaupt nicht. In der Standardkarte scheinen die Prefixes nicht auf. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg
On 01.10.19 21:53, Andreas via Talk-at wrote: Es gibt aber Geräte wie Navis, wo man nicht ständig scrollen will, um den ganzen Namen lesen zu können. Das kann ich mir schwer vorstellen. Scrollen ist allemal besser als Informationen zu unterschlagen. Abgesehen davon lassen sich "Gemeinde" und "Bezirk" automatisch abkürzen (https://wiki.openstreetmap.org/wiki/Name_finder:Abbreviations). Man würde sich solche Diskussionen ersparen, wenn man einfach im osm-wiki nachschaut. https://wiki.openstreetmap.org/wiki/DE:Gemeindegrenze Was hast denn du da für eine Seite ausgegraben? Die hat ja nicht mal eine englische Version! Warum name:prefix ein Blödsinn ist, wurde schon hundertmal durchgekaut (hier und im Proposal). und siehe da, es gibt das Tag "admin_level". Und wenn man dann noch dem Link "kommunale Ebene" folgt, kommt man zur Auflistung https://wiki.openstreetmap.org/wiki/DE:Grenze#Kommunale_Ebene_-_Ortsgrenzen_admin_level.3D7-9 Und dort erkennt man, dass für Gemeinde die Werte admin_level=7–8 vorgesehen sind. Die Seite behandelt nur Deutschland. Die richtige Seite lautet: https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative Aber auch dort sind die Daten nicht in einer für Anwendungen verwertbaren Form aufbereitet. Wenn du anderer Meinung bist, kannst du ja wie von eest9 angeregt einen Issue auf github erstellen. Viel Spaß. Ich war zum damaligen Zeitpunkt noch nicht Leser der ML und es wurden in der Vergangenheit schon öfters Proposals überarbeitet und dann doch angenommen. Aber mit "admin_level" sollten wir dem wiki folgen. admin_level und admin_title sind keine Alternativen, sondern sie ergänzen einander, genauso wie protect_class und protection_title. Wenn du das Proposal wiederbeleben willst, nur zu. Hier ist es: https://wiki.openstreetmap.org/wiki/Proposed_features/admin_title -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg
On 01.10.19 20:19, eest9 wrote: Ich bin nicht der Ansicht, dass das Salonfähig geworden ist, wenn mir mein Navi erst mal 15 Minuten das Prefix vorlesen muss bevor ich zur wichtigen Info komm bin ich 3 mal über die Kreuzung gefahren. Was hat dein Navi mit Gebietskörperschaften zu tun? Wenn du im Navi einen Zielort eingibst, dann nimmt es (hoffentlich) den Place-Node. Bei Anzeigen steht dann auch oft nur "Gemeinde A…" da weil sie einfach zu kurz Das ist nun aber wirklich ein Fehler in der Anwendung. Wenn ein Text sich nicht ausgeht, sollte er scrollen. In der Standardkarte gibt es jedenfalls kein Problem mit langen Gemeinde- und Bezirksnamen, die werden nirgends abgeschnitten. sind und es ist schlicht nicht Teil des Namens. Ansichtssache. Wenn ich vom Bezirk Mödling spreche, dann immer nur mit "Bezirk" im Namen. Auch in der Wikipedia steht es so. PS: ich möchte zusätzlich darauf verweisen, dass wir die Diskussion auch schlicht schon von September 2014 bis Mai 2015 unter dem Betreff "[Talk-at] Grenzen" hatten und ich eigentlich dachte, dass wir das seither geklärt hätten wie wir das in Österreich machen wollen. Der Thread endete in besagtem Proposal, für das zu stimmen alle Leser dieser Mailingliste zu faul waren. Das ist halt typisch österreichisch: Herumnörgeln tun alle, aber wenn es mal die Chance gibt, wirklich was zu verbessern, dann wartet jeder darauf, dass andere es machen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg
On 01.10.19 19:54, eest9 wrote: Das wäre dann aber das was man allgemein unter "mappen für die Karte" versteht. Das ist salonfähig geworden, spätestens als alle landuse=farm auf farmland umgetaggt wurden, nur weil Carto landuse=farm nicht mehr darstellte. Die OSM ist immer noch eine Datenbank und wenn die Darstellung nicht passt, dann muss man die Darstellung anpassen Das ist in diesem Fall nicht möglich, da es kein international anerkanntes Tag für Gemeinde/Bezirk/etc gibt. Mein Proposal für admin_title=* wurde leider niedergestimmt. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Änderung von Bezirks- und Gemeindenamen in Tirol und Vorarlberg
On 01.10.19 18:48, PPete wrote: Mir ist aufgefallen, das kürzlich in Tirol und Vorarlberg die Namen vieler Gemeinde- und Bezirksrelationen verändert werden. Z.b: https://www.openstreetmap.org/changeset/75069032 Ich weiß, dass das ein sehr ambivalent diskutiertes Thema ist, und es meines Wissens nach dazu in Österreich keinen Konsens gibt, ob man z.b. die Wörter "Gemeinde" und "Bezirk" in den name-Tag packt, in einen prefix-Tag oder sonstwo hin. Auf jeden Fall erstellt diese Umbezeichung aus derzeitiger Sicht keine Verbesserung der vorhanden Daten da und erzeugt ohne vorige Diskussion und Übereinkunft im Forum oder in der Mailingliste sicherlich Spannungen in der Communtiy. Ich für mich würde z.b. eine Umbennung durch einen einzelnen Mapper ohne vorige Abstimmung des über mehrere Jahre hinweg vereinheitlichten Relationsschemas in Oberösterreich nicht für gut heißen. Auch die bisherigen Umbebennungen waren ein Hin und Her durch einzelne Mapper. Ich finde "Gemeinde" und "Bezirk" im name-Tag notwendig, weil ein Anwender beim Betrachten der Karte sonst nicht weiß, ob eine Beschriftung "Bludenz" an einer Grenze für den Bezirk oder für die Gemeinde steht. (Evtl. könnte man bei Gemeinden darauf verzichten, wenn die Bezirke alle "Bezirk" im Namen haben, denn das ist dann einigermaßen eindeutig.) "Marktgemeinde" ist aber m.E. zu viel des Guten, weil das Marktrecht, wenn man es denn überhaupt zu den Geodaten zählt, eine separate Information ist, die besser in einem eigenen Tag untergebracht wird. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hallo (Vorstellung)
On 01.09.19 22:05, Immanuel Hayden wrote: Ich habe die Stammtisch-Site im Wiki gefunden (also die hier: https://wiki.openstreetmap.org/wiki/Wien/Stammtisch), aber keine Ahnung wie ich hier up-to-date bleiben kann wenn tatsächlich ein Termin eingetragen wird. Wenn da jemand einem Noob aushelfen könnte wäre ich sehr verbunden :) Auf jeder Wikiseite ist in der Menüleiste ein Stern (rechts von "view history"), mit dem du die Seite auf die Watchlist stellen (oder von ihr runternehmen) kannst. Dann kriegst du bei einer Änderung automatisch eine E-Mail-Benachrichtigung (bei weiteren Änderungen allerdings keine mehr bis zu deinem nächsten Besuch dieser Wikiseite). Stammtische sollten aber sowieso auch hier in der Maillingliste angekündigt werden, da sie nicht regelmäßig stattfinden. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] highway=trunk in Österreich
On 19.08.19 22:26, PPete wrote: Hallo, nur falls es nicht klar rübergekommen ist: Die obigen Diskussionsgrundlagen sind mögliche Parameter. Sie dienen nur als Diskussionsgrundlage die immer wieder auch z.b. in den deutschen OSM-Forumsbeiträgen und teilweise auch Wikieinträgen zu diesem Thema genannt wurden. Die Deutschen haben halt immer noch eine Altlast aufzuarbeiten (siehe mein erstes Mail), während wir Österreicher gemeinsam mit anderen Ländern seit Ewigkeiten eine klare Definition für trunk haben. Sie decken sich nicht zwingend mit meiner persönlichen Sichtwiese. Eigentlich ist hier nur deine Sichtweise interessant und nicht die von unbekannten Dritten. Wer will denn mit einem Phantom diskutieren? Gab es irgendwo in der Vergangenheit einen Konsens der österreichischen OSM-Communtiy, dass trunk = Autostraße in Österreich? Ja. Das war seit mindestens 2010 (als ich dazukam) die Taggingpraxis, an die sich 99% der Mapper gehalten haben. Der beste Konsens ist der, über den man gar nicht diskutieren muss, weil sich sowieso jeder dran hält. Oder verstehst du unter einem Konsens, dass sich 3 Leute in einer Mailingliste einig werden? Bzw. was meinst du mit "was es auch in den Nachbarländern bedeutet"? Wenn ja, bitte um Links dazu. Den auf die trunk-Seite hast du doch selber schon gebracht? Also nochmal: https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk#International_equivalence Nicht zu vergessen auch: https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions Wenn wir die Bedeutung von highway=trunk ändern, dann werden automatisch auch die access-Defaults unbrauchbar. Totales Chaos. Ich kenne einige Abschnitte von 2 spurigen "B"-Straßen in Oberösterreich die als Autostraße geführt sind. Viele davon unterscheiden sich in keinster Weise von einer "normalen" "B"-Straße. Wenn du den Unterschied nicht kennst, dann probier mal, mit dem Fahrrad dort zu fahren. Sollte man diese Stückl jetzt aufgrund von deiner Definition auf "trunk" umändern Selbstverständlich. - ähnlich wie es der Kollege bei der Umfahrung Lambach gemacht hat? Halte ich für mehr als zweifelhaft - aber laut derzeitiger Defintion in der Wiki spricht auch nichts dagegen falls das jemand macht. Dazu ist die Dokumentation ja da, damit Zweifel beseitigt werden. ;-) -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] highway=trunk in Österreich
On 19.08.19 11:06, PPete wrote: - bei Straßen vom Typ "Autostraße" gibt als Extreme "B"-Straßen, auf denen nur z.b. 80km/h erlaubt sind, Das haben manche Autobahnen auch (z.B. in Wien). nur 2 Spuren haben (z.b. durch Tunnels, oder kurze Umfahrungen von Ortszentren wie jene in Lambach). Auf der andern Seite auch 4 spurige autobahnänhliche "S"-Straßen. Gibt es auch bei B-Straßen: In der Wiener Westeinfahrt (bei 16.23253/48.20310) ist die B1 7-spurig, mit Richtungsfahrbahnen und Leitschienen, trotzdem kein Verbot für Radfahrer, Fußgänger, Pferde... - auf einem trunk soll der durchschnittliche Autoverkehr "flotter" vorankommen als auf einer "primary". Das hast du genau bei einer Autostraße, denn dort sind keine Mopedautos und Traktoren im Weg. Natürlich helfen weitere Spuren, wenn du z.B. einen Opel überholen willst. Aber gerade dort, wo mehr Spuren sind, ist typischerweise auch mehr Verkehr (sonst wären dort nicht so viele Spuren gebaut worden), sodass aus dem Geschwindigkeitsgewinn nichts wird, außer um 4 Uhr früh... So gibt es auf der 8-spurigen A23 eine 80er-Beschränkung und oft Stau, während man auf vielen schmalen Landstraßen problemlos 120 fahren kann. Mögliche Parameter könnten sein: * durch 4-spuren überholen von langsameren LKW ohne Gegenverkehr möglich. als Grenzfall vielleicht ähnliches für druchgehend 3 spurigen Straßen, an denen sich die doppelte Spur regelmäßig alle paar km mit der Gegenrichtung abwechselt (z.b. 38 östlich von Zwettl) * keine kreuzenden Straßen und Kreisverkehre * keine Ampeln * Anschlussstellen mit unterem Straßennetz durch Verzögerungs/Beschleunigungsstreifen - damit eine Straße als "trunk" gilt muss er die von uns definierten Eigenschaften über eine gewisse Länge haben. es reicht nicht wenn er die z.b. einen kurzzeitigen Überholstreifen hat weil die Straße bergauf führt Dir ist sicher schon beim Schreiben dieser Zeilen bewusst geworden, wie unpraktikabel solche komplizierten Regeln sind. Kein Mapper würde sich daran halten, und kein Anwender könnte nachvollziehen, warum hier eine Straße als trunk angezeigt wird und dort eine Autostraße nur als primary. Von den Radfahrern, die auf einer primary von einem Autostraßenschild überrascht werden, ganz zu schweigen. Jetzt haben wir eine Definition, die eine kurze und klare Erklärung in jeder Kartenlegende ermöglicht, und eine in OSM gar nicht selbstverständliche Einheitlichkeit: highway=trunk bedeutet in Österreich genau dasselbe wie in den meisten unserer Nachbarländer: Tschechien, Slowakei, Ungarn, Slowenien, Schweiz. Ich verstehe nicht, wie jemand überhaupt auf die Idee kommen kann, diese Einheitlichkeit zu sprengen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] highway=trunk in Österreich
On 17.08.19 15:26, PPete wrote: ich bin darauf aufmerksam geworden das in diesem Changeset https://www.openstreetmap.org/changeset/61480368 die Straße B1 im Norden Lambachs von "highway=primary" auf "highway=trunk" umgeändert wurde. Es handelt sich dabei in diesem Abschnitt um eine erst vor wenigen Jahre fertiggestellte Umfahrung im Norden von Lambach. Eine 2-spurige Straße ohne getrennte Richtungsfahrbahnen, aber in diesem (kurzen) Abschnitt auch ohne einmündende Querstraßen. Dieser Abschnitt ist als "Autostraße" ausgeschildert. Genau dafür gibt es in OSM aber den Tag "motorroad=yes" https://wiki.openstreetmap.org/wiki/DE:Key:motorroad. Meiner Meinung nach hat die Eigenschaft "Autostraße" nichts damit zu tun, mit welchem Typ man eine Straße mappt, also nach deren Ausbauzustand. Ich kenne einige Beispiel von "ganz gewöhnlichen" Straßenabschnitten, die in keinster Weise ein "autobahnähnliche Schnellstraße sind" (trunk) und trotzdem eine Autostraße: In Traunkirchen auf der B145 der Tunnel "Geißwand", oder in Losenstein auf der B115 der Tunnel. In der Wiki https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk steht tatsächlich, dass in Österreich jede Autostraße eine "trunk" ist. Das zweifle ich an. Gibt es dazu einen Konsens? Gab es überhaupt irgendwo schon eine Diskussion wie man mit "trunks" in Österreich umgeht? Das war ich, der das dort eingetragen hat. Das hab ich mir damals (2011) nicht aus dem Finger gesogen, sondern ich habe damit das schon damals in Österreich übliche Tagging dokumentiert. Zuvor war da gestanden, dass trunk in Österreich für Schnellstraßen steht – die es jedoch, wie jeder weiß, in der die österreichischen Straßenverkehrsordnung gar nicht gibt. Die highway=* Tags waren in OSM historisch bedingt immer schon schwammig definiert. OSM wurde von einem Engländer ins Leben gerufen, und der dachte sich highway=trunk aus für jene Straßen, die in England trunk genannt werden. Im Standard-Renderer wurden sie bis vor wenigen Jahren noch in grüner Farbe dargestellt, weil das in England so üblich ist. Mit der Internationalisierung von OSM ist nicht nur das Grün letztlich verschwunden, sondern es haben sich natürlich die Mapper vom Rest der Welt überlegt, wie man diesen komischen Straßentyp, den es eigentlich nur in GB gibt, für ihre jeweiligen Heimatländer nutzen kann. Viele Länder haben ihn also für Autostraßen verwendet, denn ob eine Straße eine Autostraße ist, ist für viele Verkehrsteilnehmer ganz wesentlich, denn es entscheidet, ob Fußgänger, Radfahrer usw. die Straße überhaupt benützen dürfen. Der Ausbauzustand ist vergleichsweise unbedeutend, und als Kriterium ist er sowieso nicht tauglich, weil auch wieder nur schwammig. Man müsste das schon an der Anzahl der Spuren o.ä. festmachen, doch für alle solchen Eigenschaften gibt es spezielle Tags (lanes=* usw.). Wer trunk=Autostraße deswegen ablehnt, weil es dafür ein spezielles Tag (motorroad=yes) gibt, muss also alle alternativen Definitionen für trunk genauso ablehnen. Noch am besten war ein Vorschlag, den mal jemand hier auf Talk-AT brachte, nämlich trunk für alle vignettenpflichtigen Straßen zu verwenden, die keine Autobahnen sind. Denn toll=yes ist nicht eindeutig, es kann sowohl für Vignettenmaut als auch für andere Maut stehen. Der Vorschlag fand in der Mailingliste jedoch keine Resonanz, und so blieb es für trunk = Autostraße. Zu motorroad=yes möchte ich noch sagen, dass es von den Deutschen erfunden wurde, weil sie aus mir unbekannten Gründen highway=trunk/primary/.../tertiary so schwammig definiert hatten, dass die einzige Möglichkeit, Autostraßen von anderen Straßen zu unterscheiden, ein zusätzliches Tag war. Die Länder, die für die highway=* Tags nachvollziehbare Kritierien aufgestellt hatten, hatten das Problem nie und hatten daher keinen Bedarf für ein Zusatztag. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Relationschaos nach Landesstraßenanpassung (Kreisverkehr Erstellung)
On 12.08.19 06:39, andreas wecer wrote: Am So., 11. Aug. 2019 um 12:56 Uhr schrieb Andreas via Talk-at mailto:talk-at@openstreetmap.org>>: Gibt es dazu einen leichteren Weg, oder ist es einfach mit den Relationen so kompliziert? die Frage habe ich mir auch schon gestellt. Was das Auftrennen des Kreisverkehres betrifft, bin ich auch erst später draufgekommen, dass das - insbesondere bei kleinere Kreisverkehren - nicht unbedingt zwingend notwendig ist und man diesen auch abstrakter als ein geschlossenes Objekt ansehen kann. In der JOSM-Relationsansicht erscheint er dann auch als Kreisverkehr-Symbol JOSM ist aber nicht die einzige Anwendung. Du kannst den Kreisverkehr abstrakt als geschlossenes Objekt ansehen, aber du kannst dich nicht darauf verlassen, dass andere das genauso tun, denn das ist fürs Routing nirgends so spezifiziert. Darum ist das Auftrennen weiterhin nötig. Im von Andreas genannten Fall besteht das Relationschaos nur deshalb, weil emergency99 für jede Buslinie zwanzig Relationen angelegt hat. Wenn es für jede Buslinie nur 1 Relation gäbe, wären die Relationen überschaubar. Ich habe emergency99 in einem ähnlichen Fall darauf angesprochen und er meinte, ich brauche mir keine Sorgen machen, dass ich dort die Relationen kaputtmache, denn er bringe sie sowieso wieder in Ordnung. Das ganze komplizierte ÖPNV-Mapping ist nicht nur deshalb extrem wartungsintensiv, sondern auch weil ständig Aktualisierungen nötig sind. Ich sehe keinen großen Nutzen darin, denn die gleichen Daten stehen sowieso auf den Websites der Verkehrsbetriebe (oder sollten zumindest). Wenn ÖPNV-Freaks sich trotzdem den Aufwand antun wollen, dann ist es nur fair, dass sie sich auch bei solchen Kreisverkehren darum kümmern. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Way: 357911189
On 06.08.19 04:40, fors...@ozonline.com.au wrote: Way: 357911189 renders as a lake, in reality it is a scree slope/gravel bed with a braided stream running through it. It is tagged waterway riverbank. Do you have any suggestions for better tagging? This should be micro-mapped from aerial images. You need to compare images from different years to see which parts of the area are frequently changing, and which are not. natural=scree seems fine for most oft that area. The green parts are certainly natural=fell. waterway=riverbank is ok on the area around E 11.6636714 / N 47.0004158, which is covered most of the time by the varying branches of the stream. I have never been to that region, but in general the alpine waterways carry a lot more water in spring and early summer due to snowmelt. You don't see these water levels in aerial images because they are taken when the snow is gone. So it's possible that waterway=riverbank is correct on a bigger area, but then it should be accompanied by intermittent=yes. See https://wiki.openstreetmap.org/wiki/Proposed_features/ephemeral for ideas how to specify the season. The waterway=stream itself should be adapted to the latest aerial image. This may by outdated anyway, but it's still better than what is mapped by now. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Historisches Gebäude mit gewerblicher Nutzung?
On 23.07.19 23:21, Johannes Zarl-Zierl wrote: Ich habe eine Frage zum korrekten Mappen dieses Gebäudes: https://www.openstreetmap.org/relation/9830120 Das Gebäude hat offensichtlich einen Namen unter dem es bekannt ist und der z.B. auch in der städtischen Denkmaldatenbank zu finden ist: https://stadtgeschichte.linz.at/denkmal/Default.asp? action=denkmaldetail=994 Wie ist eine Indoor-Kartbahn zu mappen, die das Gebäude bezogen hat? Soweit ich sehe, wäre leisure=track und sport=karting ein Anfang, kann aber nicht den Namen der Bahn miteinbeziehen, weil das Gebäude schon einen Namen hat. Ein Taggen als Punkt im Gebäude ist laut https://wiki.openstreetmap.org/wiki/ DE:Geb%C3%A4ude auch keine Alternative: "Nimmt eine Einrichtung - nahezu - das gesamte Gebäude ein, erfolgt die Auszeichnung über die Umrisslinie des Gebäudes." Diese Wiki-Aussage ist eine Vereinfachung, die hier nicht stimmt. Wenn es in der Realität 2 Objekte gibt und sie noch dazu unterschiedliche Namen haben, dann müssen sie auch in OSM als 2 verschiedene Objekte gemappt werden. Wenn die Kartbahn das ganze Gebäude einnimmt, dann halt den Gebäudeumriss exakt nachzeichnen. Es ist ein ähnlicher Fall wie wenn einer Firma X der ganze 2. Stock gehört. Dann muss man ebenfalls den Gebäudeumriss nachzeichnen. Eine regelkonforme Alternative wäre ein POI (Node) für die Firma (bzw. die Kegelbahn), aber das macht man nur dann, wenn man die Ausdehnung nicht weiß. Nicht regelkonform ist das im Moment gemappte Multipolygon, denn 2 "outer"-Ringe berühren sich entlang einer Linie. Das ist nur bei "inner"-Members erlaubt. Dieses Multipolygon ist eigentlich unnötig, denn es genügt, die Gesamtfläche als einfache Fläche zu mappen. Anscheinend hast du mit dem Multipolygon versucht, die building:part logisch zusammenzufassen, doch das ist nicht der Zweck eines Multipolygons. Ein Multipolygon dient nur dazu, Flächen zu definieren. Wenn unabhängige Objekte logisch zusammengefasst werden sollen, dann sind andere Relationentypen besser geeignet, z.B. type=cluster (dazu gibt es ein Proposal von mir) oder type=site. Bei zusammenhängenden Gebäudeteilen ist das wie gesagt nicht nötig, da genügt eine einfache Fläche. Für die Kartbahn bietet sich leisure=sports_centre + sport=karting an. Nicht leisure=track, denn das wär nur der Verlauf der Fahrbahn, nicht die sonstigen Räumlichkeiten (Abstellplätze, Platz für Zuschauer, Kassa, Garderoben, Sanitäranlagen, keine Ahnung was es da alles gibt). Außerdem soll man leisure=track laut Wiki nur für nicht-motorisierte Sportarten verwenden; Karts haben aber einen Motor. Damit wäre für die Fahrbahn highway=raceway richtig. Aber ich würde den raceway nicht mappen, weil das nur die Renderer durcheinander bringen würde. Sondern nur das sports_centre als Ganzes. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Österreich Open Data Adresslisten des Bundesamt für Eich und Vermessungswesen, gejammt.
On 26.06.19 22:49, Rudolf Mayer wrote: Obwohl Du zum (zugegebenermaßen nicht sehr produktiven Abschlusskommentar von fkv) selbst vorher schreibst: Nur um das klarzustellen: Es war kein sehr produktiver Abschlusskommentar möglich, da er meine Fragen partout nicht beantworten wollte. Er wurde allein in diesem Thread von 3 verschiedenen Leuten gefragt, was er mit "Craftmapper" meint. Das sollte doch leicht zu beantworten sein? Wenn er einen Begriff immer wieder verwendet, wird er doch wissen, was er damit meint? Doch sein Kommentar dazu lautete: "Hier trollst Du, darauf muss ich nicht eingehen." Mit diesem Menschen ist keine Diskussion möglich, denn er ist ja nicht mal daran interessiert, seine eigene Meinung verständlich zu machen, geschweige die Meinung anderer zu hören. Den Anzeichen nach Asperger-Syndrom. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Österreich Open Data Adresslisten des Bundesamt für Eich und Vermessungswesen, gejammt.
On 26.06.19 22:17, andreas wecer wrote: Pseudoadressen sind an einer Neubaustraße entlang vergebene Zähladressen. Eine Besonderheit im Osten von Österreich, im Westen unbekannt. Ich muss zugeben, ich verstehe es auch immer noch nicht ganz, aber auf der anscheinend grünen Wiese verstreute Adressen gibt es in Tirol zumindest genügend https://www.openstreetmap.org/node/6445735318 https://www.openstreetmap.org/node/6445735089 https://www.openstreetmap.org/node/6467554894 Ich finde es ok, solche Adressen zu importieren, weil es sich um Ortserweiterungsgebiete handelt, wo man annehmen kann, dass sie schon parzelliert sind und früher oder später gebaut wird (und selbst wenn nicht gebaut wird, dann stimmt die Adresse für das Grundstück trotzdem). Im ersten Fall sind in der Basemap-Mehrzweckkarte schon Straßen eingezeichnet, im zweiten Fall hat jemand schon ein Hotel gemappt. Das Luftbild mit der grünen Wiese ist offenbar veraltet. Aber natürlich wär's schöner, jemand würde beim Importieren ein bisschen mitdenken und z.B. landuse=greenfeld mappen sowie bestehende Gebäude (https://www.openstreetmap.org/way/89409974) mit einbeziehen bzw. bei Unklarheiten ein fixme oder einen Map note setzen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Österreich Open Data Adresslisten des Bundesamt für Eich und Vermessungswesen, gejammt.
On 26.06.19 16:35, Johann Haag wrote: Hier trollst Du, darauf muss ich nicht eingehen. Dann werde ich auf dein wirres Geschreibsel auch nicht mehr eingehen. Du weißt offenbar selber nicht, was du eigentlich sagen willst. Vielleicht solltest du dir ein Hobby zulegen, bei dem die Kommunikation mit anderen Menschen nicht so wichtig ist, z.B. Stillleben malen. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Österreich Open Data Adresslisten des Bundesamt für Eich und Vermessungswesen, gejammt.
On 26.06.19 13:52, Johann Haag wrote: > nicht nur reale Adressen, sondern auch Pseudoadressen. Bitte erklär: 1.) was du unter Pseudoadressen bzw. Geisteradressen verstehst Adresstyp lt: https://www.wien.gv.at/advadrwebapp/public/advadrwebapp.htm Ok. Dort ist es allerdings auch nicht erklärt. Ergänzung: Geisteradressen sind willkürlich in die Landschaft gestreute Adressen ohne Bezug: Beispiel in Tirol https://osmcha.mapbox.com/?filters=%7B%22date__gte%22%3A%5B%7B%22label%22%3A%22%22%2C%22value%22%3A%22%22%7D%5D%2C%22ids%22%3A%5B%7B%22label%22%3A%2270171175%22%2C%22value%22%3A%2270171175%22%7D%5D%7D Der Link liefert nur eine Fehlermeldung. Wenn du ein konkretes Beispiel hast, dann bitte als ID oder als Link in der Form https://www.openstreetmap.org/node/xxx (mit xxx=ID). 2.) was du mit "gejammt" meinst (im Betreff) Daten sind gejammt, sofern solche zu einem bestimmten zweck absichtlich mit Stördaten überlagert sind. Ziel ist hierbei oft, solche Daten zwar weiterzugeben, dass aber Personen ohne Insiderwissen mit solch veränderten Daten nichts vernünftiges anfangen können. Der Anwender wird dazu gezwungen selbst den Versuch zu wagen, Jamming Daten wieder zu entfernen. Anschließend kann man diesen z.b. ob des Löschens von leeren Nodes anklagen, und hierdurch diskreditieren. Du bist also der Meinung, dass das BEV absichtlich schlechte Daten bereitstellt, um dich nachher diskreditieren zu können? Warum sollten die so einen heimtückischen Plan gegen dich ausgeheckt haben? Du warst doch immer derjenige, der das BEV so hochgelobt hat... 3.) was du unter einem Craftmapper verstehst Siehe Definition von Nakaner Ich sehe keine Definition von Nakaner, und offen gesagt bin ich froh, wenn ich nichts von ihm sehe. Darum bitte ich dich um deine eigene Definition, was du unter einem Craftmapper verstehst. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Österreich Open Data Adresslisten des Bundesamt für Eich und Vermessungswesen, gejammt.
On 26.06.19 07:15, Johann Haag wrote: nicht nur reale Adressen, sondern auch Pseudoadressen. Bitte erklär: 1.) was du unter Pseudoadressen bzw. Geisteradressen verstehst 2.) was du mit "gejammt" meinst (im Betreff) 3.) was du unter einem Craftmapper verstehst Es ist schwer, dich zu verstehen, wenn du laufend neue Wörter erfindest, unter denen sich keiner etwas vorstellen kann. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] fahrverbote in tirol
On 19.06.19 21:56, Rainer Fügenstein wrote: "Navis sollten Fahrverbote übernehmen Der Ausweichverkehr soll mit Hilfe der Navis unterbunden werden, erklärte der Landeshauptmann. Die Fahrverbote seien bereits an das Innenministerium übermittelt worden, das wiederum den Navi-Betreibern die Verkehrsdaten zur Verfügung stellt." Für so was (Ziel-/Quellverkehr) ist vehicle=destination übrigens gedacht (und nicht für Anrainerverkehr). Da aber nur an bestimmten Stellen Verbotsschilder stehen (bzw. Kontrollen stattfinden) und die Verbote zudem so schwammig sind, dass sogar die Polizei nur "mit dem nötigen Fingerspitzengefühl" entscheiden kann, wird sich das mit Tagging sowieso nicht lösen lassen, sondern nur mit in im den Routingengines hartcodierten Routingregeln. Ich schätze, dass OSM-basierte Router nicht die einzigen sind, die an dieser Aufgabe scheitern werden. Jetzt können wir gespannt sein, ob das Innenministerium OSM oder OSM-nutzende Navianbieter (Osmand usw.) überhaupt kennt und ob über diesen Kanal die Informationen jemals an die Tiroler Mapper weitergeleitet werden. Ich würde als Mapper jetzt erst mal gar nichts tun, denn erstens ist die Umsetzbarkeit sowieso fraglich (s.o.), zweitens ist der Wartungsaufwand hoch, und drittens ist der praktische Nutzen gleich null, da die Fahrverbote nur jenen ein Problem bereiten, die vom Navi wegen einer Stauwarnung auf eine Ausweichroute geschickt werden. OSM-basierte Navis können das noch gar nicht. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?
On 17.06.19 14:10, gppes_osm--- via Talk-at wrote: Auch wenn ich mich wiederhole: Bei unbekannten Gebaeuden mit komplexer Struktur ist es im Survey oft am einfachsten die Adresse an den Haupteingang zu machen. Das wird dir in der Wohnhausanlage, in der ich wohne, schwer fallen. Adresse aufs Gebäude setzen geht hingegen immer, und ich sehe nicht, was daran schwierig sein soll. Im Zeitalter von Orthofotos und Basemap-Basiskarte sehen wir sowieso genau, für welche Gebäude-Grundfläche eine Hausnummer gilt. In OSM-Urzeiten, wo wir noch mit GPS, Bleistift und Papier die Häuser aufnahmen, da wussten wir nicht, wo ein Haus anfängt und das nächste anfängt. Aber sogar damals war es nicht zweckmäßig, eine Hausnummer auf einen Eingang zu setzen. Sondern wir setzten die Adressnodes dort, wo die Nummer angeschrieben ist. Das ist meistens nicht genau über einem Eingang, sondern daneben oder an der Ecke eines Hauses. Die Unsitte, Adressen auf Eingänge zu setzen, kam erst auf, als die Basemap-Basiskarte und die Daten von wien.at für OSM verfügbar wurden. In der Basemap und im Stadtplan auf wien.at werden die Hausnummern auf den Eingängen positioniert, und einige Mapper glauben, sie müssen das nachmachen. Dabei berücksichtigen sie nicht, dass die Voraussetzungen in OSM ganz andere sind als im wien.at-Stadtplan. Z.B. ist es in letzterer nötig, die Hausnummer am Gebäuderand anzuzeigen, weil es kein addr:street Tag gibt, aus der die zugeordnete Straße hervorgeht. Mit der Hausnummer an der Stelle vom Eingang erspart sich der wien.at-Stadtplan eine eigene Signatur für den Eingang. Um die Eingänge von Shops muss sich der wien.at-Stadtplan nicht kümmern, weil die im Datenbestand gar nicht vorkommen. Außerdem ist es eine gerenderte Karte, während wir in OSM Rohdaten verwalten. Die Privatsphaere der Bewohner ist so am besten gewaehrleistet. Man muss nicht rein um die Struktur des Gebaeudes zu durchschauen, man muss keine Nebeneingaenge suchen, und wenn man einen gefunden haette, muss man nicht an der Tuer ruetteln um zu pruefen, ob das eine zusaetzliche Zugangsmoeglichkeit (fuer das access-Tag) waere. Wenn dir die Privatsphäre der Bewohner so wichtig ist und du ein Routing zu Nebeneingängen vermeiden willst, warum willst du sie dann überhaupt mappen? Du hältst legale Besucher von Abkürzungen durch Nebeneingänge ab, gibst aber Einbrechern die Information auf dem Silbertablett, wo sie es probieren können. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?
On 18.06.19 00:36, Kevin Kofler wrote: Ich hatte mal eine Lehrveranstaltung in der Liechtensteinstraße 22. Dort gibt es mindestens 3 getrennte Gebäudeteile: vorne im Erdgeschoß ein Supermarkt, über dessen Eingang logischerweise nur der Supermarkt selbst erreichbar ist, dahinter ein Stiegenhaus mit Lift, von dem aus der gesuchte Raum aber auch nicht auffindbar war, und ganz hinten ein Stiegenhaus ohne Lift, über das ich von Ortskundigen hinaufgeschickt wurde. Dabei hatten die Gebäudeteile nicht einmal getrennte Adressen! Ich kenne das Gebäude nicht. Im Moment hat hat es in OSM die Hausnummer 22-22a. Daran ist was faul, denn Hausnummern mit a, b... werden in Wien dann vergeben, wenn ein neues Haus eingefügt wird und man nicht die Nummern aller folgenden Häuser erhöhen will. Hausnummern mit "bis" werden im umgekehrten Fall vergeben, nämlich wenn dort, wo früher 2 Häuser waren, jetzt nur noch 1 großes ist und man in den Hausnummern keine Lücke lassen will. Im konkreten Fall trifft beides nicht zu und es spricht somit nichts dagegen, dem Haus einfach die Nummer 22 zu geben. Auch der Spar hat laut Website nur die Hausnummer 22 und nicht 22-22a. Dort, wo in der Basemap die Nummer 22A anzeigt, sieht man in Google Streetview tatsächlich einen Eingang mit der Nummer 22A, aber wohlgemerkt mit großgeschriebenem A, und es ist hochgestellt. Weiß jemand, was diese Großbuchstaben bedeuten? Diesen Eingang kannst du nicht meinen, denn das A wär dir aufgefallen. Dein Stiegenhaus mit Lift muss also irgendwo im Durchhaus sein und das ohne Lift dahinter im Hof (Node 1708783545). Dessen Tagging (access=customers) passt aber nicht zu deiner Angabe, dass dort eine LVA stattgefunden hat. Und in der Basemap steht da die Stiegennummer 4 – doch wo ist die Stiege 3? Die wird in der Basemap unterschlagen. Wenn dort Stiegennummern angeschrieben sind, dann hättest du nicht rätseln müssen, welche Stiege die richtige ist. Jedenfalls sieht man in diesem Fall, dass es nichts bringt, die Hausnummer an den Haupteingang zu setzen, denn der Spar ist so weder auffind- noch routbar (selbst wenn sein Eingang gemappt wäre), und auch zu dem Eingang, wo deine LVA stattfand, wärst du nicht hingeroutet worden. Wenn man die Hausnummer aufs ganze Gebäude setzt, können Anwendungen dem Benutzer wenigstens die Ausdehnung des Gebäudes anzeigen, in dem er sein Ziel suchen muss. Und wenn der Hörsaal oder das Institut als POI gemappt ist, dann ist sogar klar, auf welcher Seite des Gebäudes man zum Suchen anfangen muss. Einen Eingang beim Routing sicher zuordnen geht nur mittels Indoormapping. Beim Spar ist das ganz einfach: Man muss ihn nur flächig mappen, und der Eingang schließt dann direkt an. Bei der LVA müsste man zusätzlich zum Institut auch das Stiegenhaus und ggf. einen Korridor mappen um die Verbindung herzustellen. Ich weiß nicht, ob irgendein Router das überhaupt schon kann, aber die Firma Merz (alias Weltstaat) hat in Wien schon alle U-Bahn-Stationen in OSM mit solchem Indoormapping zugepflastert, und die werden das nicht aus Idealismus gemacht, sondern einen konkreten Zweck damit verfolgt haben. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?
On 17.06.19 10:25, gppes_osm--- via Talk-at wrote: Jawoll, weiters sind Seiteneingaenge oft versperrt und/oder fuer Besucher nicht gedacht; Darum gibt es access-Tags, und bei entrance=* ist "yes" nicht der einzige mögliche Wert... Von: "Kevin Kofler" Friedrich Volkmann wrote: Für Fußgängerrouting kommt es darauf an, auf kürzestem Weg zum Haus hinzukommen und dann möglichst durch einen Eingang auf der Seite, von der man kommt, ins Haus hineinzugehen. Keiner will auf einen Umweg um das Haus herum geschickt werden. Das gilt aber nur, wenn alle Gebäudeteile auch von allen Eingängen aus erreichbar sind. Das ist nicht in jedem Haus so. Normalerweise stehen zusammenhängende Gebäudeteile miteinander in Verbindung (sonst sind es nämlich verschiedene Gebäude), außer in Wohnhausanlagen, aber da gibt es Stiegennummern. Ohne konkrete Beispiele erscheinen mir solche Probleme nur herbeigeredet. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Hausnummern + Hauseingänge / Adressen in Wien?
On 17.06.19 03:28, Kevin Kofler wrote:
Friedrich Volkmann wrote:
Wie Robert Kaiser schon angemerkt hat, war das einst Konsens für Häuser
mit mehreren Adressen. Heute gibt es dafür was Besseres, nämlich das
addrN-Schema.
Das addrN-Schema ist aber nicht Konsens und ist aufgrund der fehlenden
räumlichen Positionierung der verschiedenen Adressen für Rendering völlig
ungeeignet und für Routing nur bedingt geeignet.
Der oben erwähnte Konsens sah so aus, dass Andreas Labres bei einem
Stammtisch mit lauter Stimme sagte, wie etwas gemacht gehört, und dann haben
es alle so gemacht. In Wien halt. Aber OSM gibt es nicht nur in Wien, und
wir können auch mal über dir Grenzen schauen, wie andere es machen.
addr2:housenumber kommt 14414 mal vor. Das kann man schon als de-facto
Standard ansehen.
Für Rendering ist es sehr wohl geeignet, das hab ich ich schon vor vielen
Jahren im Zuge des Proposals im Detail erklärt. Ein Renderer braucht nur
schauen, auf welcher Seite des Hauses eine Straße dieses Namens existiert,
und dort die Hausnummer platzieren. Was das Routing betrifft, da ist es
sowieso absurd, jemanden zu einem bestimmten Hauseingang zu routen. Für
Fußgängerrouting kommt es darauf an, auf kürzestem Weg zum Haus hinzukommen
und dann möglichst durch einen Eingang auf der Seite, von der man kommt, ins
Haus hineinzugehen. Keiner will auf einen Umweg um das Haus herum geschickt
werden. Fürs Kfz-Routing gilt im Prinzip das gleiche, außerdem wird man
sowieso selten genau vorm Eingang einen Parkplatz bekommen. Es ist dann also
erstrebenswert, vom Router das Haus als Ziel angezeigt zu bekommen, damit
man auf der Suche nach einem Parkplatz um das Haus herum fahren kann.
Und seien wir uns ehrlich: Eigentlich ist das alles Hirnw*xerei ("eine
akademische Diskussion"), denn wenn ein Ziel so weit weg ist, dass man ohne
Routing nicht hinfindet, dann wird es keinem auf die paar Sekunden ankommen,
die man am Schluss zum Eingang hingeht. Wenn man sich in solche Diskussionen
verliert, dann verliert man zugleich auch den Bezug zu den wirklichen
Bedürfnissen der Anwender.
--
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at
