[Talk-de] Fragen an die Kandidaten (was: Vorstandswahlen der OSMF ...)
Hallo zusammen, außer der Kandidatur läuft auch sehr bald die Frist für Fragen an die Kandidaten ab: https://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM20/Election_to_Board#Community_questions_to_OSMF_board_candidates.2C_upon_which_the_official_set_will_be_based Damit da überhaupt was steht, habe ich die Fragen für 2019 kopiert und angepasst. Ich werde mich im Übrigen zurückhalten, da ich nicht als Kandidat die Fragen dominieren will. Man kann und darf da auch Fragen auf Deutsch stellen, falls Englisch das Hindernis ist. Bitte macht davon Gebrauch! Wenn es also ernsthaftes Interesse an der Causa Facebook gibt, wäre es gut, ein paar Fragen zu stellen, die die Lücke demonstrieren: Attributierung: Was ist eine angemessene Form der Attributierung? Wie soll die OSMF das gegenüber großen Unternehmen wie Facebook und Mapbox durchsetzen? Schäden durch KI: Die philippinische Community hat sich über zerstörte Daten wie fälschlich verbundene Sackgassen durch "KI-Edits" beschwert? Wie soll die OSMF solche und ähnliche Probleme durch organisiertes Editieren einhegen? Finanzierung der OSMF: Die OSMF hat sich durch ihre Angestellten auf ein Budget verpflichtet, das viel höher als ihre Einnahmen aus Mitgliedsbeiträgen ist. Soll die OSMF eine Abhängigkeit von großen Sponsoren in Kauf nehmen? Also: im Notfall (Deadline!) hilft es schon, die Fragen eins-zu-eins auf die Seite https://wiki.openstreetmap.org/wiki/Talk:Foundation/AGM20/Election_to_Board zu kopieren. Noch mehr würde ich ich freuen, wenn jemand die Fragen überdenkt, umformuliert, kürzt oder ergänzt. Hinweis: wegen der Deadline auch ins Forum eingestellt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorstandswahlen der OSMF - Kandidatur bis 7.11. Ende des Tages
Hallo, Im Dezember ist wieder OSMF-Vorstandswahl. In ziemlich genau 52 Stunden ist Ende der Bewerbungsfrist. Wenn ihr Interesse habt, als Vorstandsmitglied zu dienen, könnt ihr Euch hier eintragen: [..]> Ich selber bin ja nun schon eine Weile raus da, aber es ist meiner Ansicht nach eine wichtige Arbeit. Die OSMF driftet ständig in Richtung der "big business"-Leute, und auch dieses Jahr wird sich wieder Michal Migurski zur Wahl stellen, der beim letzten Mal noch ganz deutlich in seinem Wahlprogramm schrieb, dass er nicht als Privatmann, sondern als Vertreter von Facebook in den Vorstand will - für mich eine sehr schwierige Vorstellung. Auf die Liste habe ich mich jetzt eingetragen. Wenn noch jemand Lust hat, trage ich mich gerne wieder aus. Es bleiben bei mir ohnehin schon mehr OSM-Themen liegen als mir lieb ist. Ich denke aber, dass es schwierig wird, gezielt einen unerwünschten Kandidaten draußen zu halten: das verwendete Wahlsystem STV hat ja gerade als Zweck, die Chancen von Nischen-Bewerbern zu verbessern und taktische Züge zu erschweren. Eine Bitte an alle diejenigen, die mich wählen wollen: Mit Tobias' Arbeit bin ich sehr zufrieden und möchte ihn auf keinen Fall verdrängen. Setzt ihn also daher bitte VOR mich auf den Wahlzettel. Zur Taktik: wenn ich Michal verdrängen soll, muss ich darauf abzielen, bei möglichst vielen Wählern vor ihm auf dem Wahlzettel zu stehen, die absolute Position ist weitgehend egal. Ich werde daher mit einer eher business-freundlichen Position auftreten, die ich aber nicht in der OSMF fortzusetzen beabsichtige. Generell ist der Zweck der Overpass API ja, dass mehr Leute zu Tagging-Fragen auf Augenhöhe mitreden können, und die Share-Alike-Lizenz ist wohlabgewogen gewählt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Evangelische Kirchen in Deutschland
Hallo zusammen, die Idee für die Wochenaufgabe verdient auf jeden Fall Unterstützung. Jenseits des denomination-Tags lohnt es sich bei allen Gemeinden, auch die URL der Gemeinde, die das Gebäude nutzt, einzutragen. Neben der Service-Funktion, um tatsächliche Gottesdienst- und Öffnungszeiten zu finden, ist das auch in der Zukunft der beste Indikator, ob die Kirche noch aktuell ist. so einfach ist das leider nicht. Die deutschen evangelischen Kirchen sind je nach Region entweder lutherisch, reformiert oder uniert. Um den längeren, sehr interessanten Unterschied https://de.wikipedia.org/wiki/Reformierte_Kirchen https://de.wikipedia.org/wiki/Union_Evangelischer_Kirchen mal abzukürzen: es gibt größere gemischte, aber auch fast ausschließlich lutherische oder reformierte Gebiete in Deutschland Als On-the-ground: Wenn es einen stilisierten fast-nackten Mann über dem Altar gibt, dann ist es sicher lutherisch, die reformierten Gemeinden orientieren sich am immer Wort und haben abstrakte Kreuze. Mitunter sind lutherische Nebenstellen aber so schlicht gestaltet, dass die Umkehrung nicht gilt. Es ist im Zweifel keine Schande, denomination=protestant zu notieren, nur halt sehr unpräzise. denomination=lutherian ist dagegen häufig genauso falsch wie denomination=evangelical Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Regionalbahn-Relationen: was in network einzutragen?
Hallo Michael, Mir ist noch etwas eingefallen, was bei der Aufgabenträger-Bedeutung problematisch wäre Ich denke mal, dass die Idee hinter dem "network=" urpsrünglich mal war, dass derjenige drinsteht, der die Liniennummer vergibt. Dann ist die Kombination aus network= und ref= für jede Linie eindeutig. Es ist eine recht häufige und naheliegende Forderung, dass man mit einem einfachen Filterkriterium genau die gesuchte Linie finden kann, und da hilft die Eindeutigkeit. Der Rest ist jetzt das übliche Missverständnis-Potential. Bei den alten Verkehrsverbünden (z.B. MVV, VRR, VRS) sind die Liniennummern verbundweit koordiniert. Daher dürfte (für vor allem Busverkehr) die Formulierung "network= ist der Verkehrsverbund" stammen. Bei neueren Verkehrsverbünden ist das nicht mehr der Fall. Wer aus einem solchen kommt, wird aus der Vorgabe "network= ist Verkehrsverbund" nicht zurückschließen, dass die Eindeutigkeit das wesentliche Merkmal ist, und sich seine Eindeutigkeit auf anderem Wege basteln, z.B. unter Mitnutzung des "operator=" (mit eigenen Schwierigkeiten) oder Ähnliches. Jedenfalls kann man auch aus Semikolon-Listen in "network=" (plus "ref=") noch einen einfachen Filter bauen, der genau die gewünschte Linie findet. Von daher kann man das machen, sollte dann aber im Zweifelsfall mehr eintragen, damit der Filter nicht ins Leere greift. Eine ungelöste Aufgabe ist dann, was man mit den Verkehrsverbünden macht, in denen Liniennummern mehrfach vorkommen. Von der Berücksichtigung von Tarifinformationen würde ich dagegen sehr dringend abraten: es gibt endlos viele Sonder- und Kulanzregeln, oder nur teilweise gültige Sortimente. Es kann durchaus passieren, dass auf einem bestimmten Abschnitt nur Zeitkarten eines Verbundes anerkannt werden. Sonst müsste man z.B. auch anfangen, Regelungen wie das Bahncard-Cityticket im "network="-Tag einzutragen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuz Werl - seltsame Spurnutzung
Hallo Michael, Was für eine Geschwindigkeit sollte vom routing bei signals angenommen werden? Kurzfassung: Ich würde mir 120 km/h für maxspeed=signals und 80 km/h für highway=motorway_link wünschen. Zu maxspeed=signals kenne ich viele der Anlage in NRW https://overpass-turbo.eu/s/N9k Auf dem Kölner Ring und der A46 bin ich regelmäßig und auch zu allen Tageszeiten unterwegs. Dort sind tatsächlich niemals mehr als 120 km/h ausgewiesen. Auf der Anlage auf der A1 bei Dortmund gibt es vereinzelt auch die Richtgeschwindigkeit. Es gibt aber auch prinzipielle Überlegungen: in Deutschland kann wegen der Richtgeschwindigkeit vernünftigerweise keine Autobahn mit mehr als 130 km/h berechnet werden. Die Definition der Richtgeschwindigkeit besagt ja, dass der Betreiber der Autobahn auch bei günstigen Wetter- und Verkehrsverhältnissen eine höhere Geschwindigkeit für gefährlich hält. Insofern sollte ein guter Router auch niemanden zu gefährlichem Verhalten verleiten. Die 120 km/h sind also selbst bei Anzeige von Richtgeschwindigkeit nur geringfügig zu langsam bemessen. Umgekehrt wird eine niedrigere Geschwindigkeit als 120 km/h hauptsächlich dann angezeigt, wenn Staus oder schlechten Verkehrs- oder Wetterverhältnissen vorgebeugt werden soll. Das ist aber außerhalb des Anspruchs eines Routers mit statischen Daten. Ein Stau-Modell haben wir auch nicht für Autobahnen mit fixem Limit. D.h. wer in der Hautverkehrszeit Routen berechnet, wird für realistische Zeiten ohnehin einen Router mit Echtzeitdaten oder sogar Prognosemodell bemühen wollen. Von daher fällt auch die Abweichung nach unten nicht groß ins Gewicht. Zu den Rampen, also highway=motorway_link: Das Konzept der Selbstverantwortung ist überraschend prominent in der deutschen Verkehrsordnung. Geschwindigkeitbegrenzungen dienen vorwiegend dazu, eine Fremdgefährdung auszuschließen. Ich kenne durchaus enge Linkskurven, vor denen das Geschwindigkeitslimit aufgehoben wird, obwohl man schon das praktisch nicht fahren kann. Linkskurve heißt: man fährt nur sein eigenes Fahrzeug in den Abgrund. Das formale Geschwindigkeitslimit ist also nicht automatisch die vernüftigerweise oder selbst realistischerweise fahrbare Geschwindigkeit. Verbindungsrampen werden oft mit Entwurfsgeschwindigkeiten von 40 km/h bis 60 km/h konzipiert. Schaut man sich die Kurvenradien der Kleeblätter am Autobahnkreuz in Werl an, so sind dort auch eher 40 km/h oder weniger konzipiert worden. Ein explizites Schild gibt es an solchen Kurven nur vereinzelt (speziell Werl kenne ich nicht, bei anderen Autobahnkreuzen gibt es beide Fälle), aber OSRM hat meines Wissens auch keinen Präprozessor, der Kurvenradien auf Geschwindigkeitsgrenzen umrechnet. Damit bleibt außer dem Tag highway=motorway_link aus Sicht der Routers kein besserer Indikator. Entsprechendes gilt für die Verflechtungsstreifen. Auch dort ist zwar kein Limit ausgewiesen, aber die Gefahr langsam auffahrender Fahrzeuge und das nötige Bremsmanöver zum Abbiegen bedeuten, dass auch dort effektiv Geschwindigkeiten von weniger als 80 km/h gefahren werden können. Von daher würde ich für einen Router nach aktuellem Stand der Technik (Auswertung von Tags im Kantenmodell, keine Kurvenradien, keine Erkennung von Verflechtungsstreifen, kein probabilistisches Staumodell) die beiden Limits empfehlen. In über 95% der Fälle wird man damit den real sinnvollsten Weg mit einer bis auf Stau nahezu korrekten Zeit bestimmen können. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen, Anregung eines Neulings
Sehr geehrter Herr Mehl,
https://routing.openstreetmap.de/?z=15=50.738180%2C8.291759=49.908459%2C8.647996=51.956580%2C7.632351=de=0=0
erhalte ich zwei unverständliche Umleitungen:
- die A5 nicht bis zum Gambacher Kreuz, sondern vorher Abfahrt
um Butzbach, Langengöns
- um Herborn herum auf der B277,
erst einmal herzlich willkommen und danke für die Rückmeldung. Das ist
durchaus schon konkret genug, um den konkreten Mangel zu finden.
Das schöne bei Open-Source ist, dass jeder der Ursache noch weiter
nachgehen kann. Zum Nachfolgenden möchte ich Sie gerne ermuntern, aber
nicht verpflichten; für die erfahrenen Leser ist aber aber sicherlich
gut zu wissen:
In diesem Fall gibt es unten links auf der Routing-Ansicht, drittes
Symbol (Lupe vor Quadrat) eine sogenannte Debug-Ansicht:
https://routing.openstreetmap.de/debug/car.html#14/50.4915/8.6899
Dort bleibt die Fahrbahn Richtung Dortmund grau. D.h. aus Sicht der
Ruting-Software ist diese Fahrbahn nicht befahrbar.
Ab diesem Punkt könnte man den Macher der Routing-Software anschreiben,
https://routing.openstreetmap.de/about.html
liefert fossgis-routing-ser...@openstreetmap.de
als Ansprechpartner.
Oder selber herausfinden, warum die Fahrbahn nicht verwendet wird:
https://overpass-turbo.eu/s/MNy
liefert die fraglichen Elemente sowie die Elemente kurz davor und
dahinter, zum Anklicken mit Sicht auf die Tags.
Bei den Tags unterscheiden sich die routbaren Elemente von den nicht
routbaren Elementen am Ehesten durch das Tag "construction=yes".
Wie sich herausstellt, wenn man auf
https://routing.openstreetmap.de/about.html
nach den Routing-Regeln
https://github.com/fossgis-routing-server/cbf-routing-profiles/blob/master/car.lua
schaut, dann findet man, dass
avoid = Set {
[...]
'construction',
'proposed'
},
d.h. es wird in der Tat die Route von routing.openstreetmap.de nicht
genutzt, weil "construction=yes" gesetzt ist. Hier wäre jetzt die
Einschätzung gefragt, ob das Tag "construction=yes" gerechfertigt ist.
Aus der Erfahrung und Beschreibung auf
https://wiki.openstreetmap.org/wiki/DE:Key:construction
liest man, dass das Tag nicht verwendet werden sollte (sondern
"highway=construction" + "construction=motorway", wenn und nur wenn die
Fahrbahn unbefahrbar ist).
An dieser Stelle ließe sich nun entweder das Tag entfernen oder
sinnvollererweise per Changeset-Diskussion der Mapper kontaktieren, was
das Tag "construction=yes" eigentlich hätte sein sollen. Ich habe das in
https://www.openstreetmap.org/changeset/74156647
jetzt getan.
Wie gesagt, die komplette Recherche würde ich zwar nicht erwarten, aber
es ist ein guter Fall vorzuführen, warum durch Open Source man schnell
den richtigen Ansprechpartner mit dem richtigen Kontext finden kann.
Viele Grüße,
Roland Olbricht
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Spielregeln fürs Tagging
Hallo zusammen,
bei der SotM werde ich eine Stunde zum Thema Tagging moderieren
und will die Gelegheit nutzen, etwas möglichst langfristig Hilfreiches
zu schaffen. Damit ich dabei nicht meine persönlichen Wünsche über die
tatsächlichen Bedürfnisse stelle, würde ich mir Rückmeldung wünschen,
inwiefern die nachfolgend gelisteten Probleme auch die relevanten sind.
Die Mail darf gerne weitergereicht werden; ich strebe eine breite
Diskussion im Vorfeld an.
Mängel im Informationsfluss
Zwar sind viele Teile von OpenStreetMap gut übersetzt,
aber die Tagging-Dokumentation hat spürbare Mängel. Bei einer Stichprobe
von 10 Tags sind zwar per Tag zwischen 2 und 18 Sprachen gelistet
worden, aber nur wenige der Übersetzungen sind vollständig und aktuell
(in der Stichprobe 2 für Deutsch, 3 für Französisch).
Ein anderes Defizit ist, dass Tag-Dokumentationen auf den Wiki-Seiten
auch dann erheblich geändert werden können, wenn das Tag längst breit in
Gebrauch ist.
Es kommt zudem ebenso vor, dass ein Tag ohne jegliche Dokumentation
eingeführt wird. Wenn dies durch normale Mapper passiert, ist dies
üblicherweise langsam genug um das Tag deuten zu können; so können
Imports oder Organisiertes Editieren die De-Facto-Bedeutung eines Tags
substantiell verschieben, unabhängig davon ob es verbreitet,
dokumentiert oder beides ist.
Bedarf nach mehr Struktur
Die Tag-Übersetzungen mischen sich mit einem anderen Problem:
verschiedene Features können sehr unteschiedlich in verschiedenen
Regionen aussehen. Z.B. sehen ein highway=primary und
highway=unclassified gegenüber highway=track in Deutschland deutlich
anders aus als in Island oder dem ländlichen Afrika. Es passiert
schnell, dass lokale Unterschiede nur in die Übersetzung der jeweils
dominanten Sprache eingehen, obwohl z.B. die Tagging-Anforderungen in
den französischsprachigen Ländern Belgien, Kanada und Niger spürbar
verschieden sind. Umgekehrt gibt es keinen sinnvollen Grund, die
Tagging-Regeln in Brüssel pro Häuserblock zu ändern.
Darüberhinaus haben Nutzer oft andere Suchbegriffe als die Tag-Namen in
britischem Englisch, aber die Suche der Wiki-Software ist eher
berüchtigt. Es sei daher in den Raum gestellt, ob Schlüsselwörter zum
Suchen ("How to Map a ...") helfen könnten.
Eine erhebliche Quelle der Probleme mit Proposals ist, dass sie mit der
Beschreibung vieler Tags wechselwirken. Allenfalls sehr selten werden
die Änderungen auf alle betroffenen Tag-Definitionen nachgezogen.
Im Moment ist ein Proposal eine zusätzliche Seite im Wiki;
seinem Wesen nach ist es aber eher ein Änderungssatz ähnlich z.B. einem
Commit bei Git.
Spielregeln und deren Legitimation
Wie legitim sind Prozesse, wenn bloß eine Handvoll Personen mit der
nötigen Zeit um Mails auf der Mailingliste und Wiki-Seiten zu schreiben,
teilnehmen können? Insbesondere, wenn die Proposals zahlreiche
Widersprüche enthalten, vage bleiben oder notwendige Details offen
lassen. Dennoch sind es die Aktiven dieser Liste, die das nötige
Durchhaltevermögen gezeigt haben, damit die Dokumentation zumindest
grundliegend gepflegt bleibt. Jede Änderung zu neuen Prozessen muss sich
also daran messen, ob sie die Teilnehmer-Basis wirklich vergrößert.
Umgekehrt habe ich größtes Verständnis für Mapper, die sich Sorgen über
unabgestimmte Änderungen im Rendering oder der Editier-Software machen.
Viele dürften es wertschätzen, sobald der Prozess von der Änderung im
Wiki zur Änderung im Rendering und anderswo vollständig nachvollziehbar
ist. Die Prozesse sind nicht geheim, aber doch un- oder unterdokumentiert.
Auch hier trägt die Vielzahl der Diskussionskanäle und der mangelnde
Informationsfluss dazwischen dazu bei die Stimmung zu verderben. Noch
schlimmer: das Verhältnis zwischen Anzahl der Kanäle und Anzahl der
Aktiven bedeutet das Risiko, dass bösartige oder auch nur grob
inkompetente Teilnehmer einen der Kanäle übernehmen und erheblich zur
Verwirrung beitragen können. Gute Ideen, wie man Teilnehmern die besser
gepflegten Kanäle schmackhaft macht und einige Kanäle (z.B. die
Wiki-Diskussionsseiten) schließt können lohnen, sie zu verfolgen. Dazu
kommt, dass die History des Wiki so unzureichend gegenüber dem ist, was
Versionskontrollsysteme heute bieten, dass zu überlegen ist, wie man
Metaphern und Paradigmen von dort übernehmen könnte.
Dies wird hoffentlich helfen zu verstehen, ob und wann die Autoren der
Dokumentation und die tatsächlichen Mapper der Tags die gleiche
Bedeutung anwenden.
Viele Grüße,
Roland
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Änderungen im Wiki: Tag:public transport=platform
Hallo Nzara, da pflichte ich Martin dringend bei. Gut 99% aller Name-Nutzungen an public_transport=platform in Deutschland sind die Namen der Station. Ich habe das für die fünf größten Bundesländer ausgezählt: Land Hst mit Name Hstname Steigref NRW673246630466299 5 Bayern 391263409733991 106 BaWü 256732215922002 157 NDS22372204432038063 Hessen 22967214852147124 Da es eine händische Sichtung der Hstnamen ist, werde ich das auch nicht aufs ganze Bundesgebiet ausdehnen; der Trend ist eindeutig. Wer selber bei sich auszählen möchte, kann alle vorkommenden Namen listen: https://overpass-turbo.eu/s/Lp4 Bitte die Bounding-Box zum Zielort schieben. Wenn es einen Sonderwunsch gibt, kann man den gerne diskutieren. Aber er gehört auf keinen Fall in die Tag-Dokumentation; Leser der Dokumentation könnten das für anerkannt halten. Wenn ein Tag wie hier breite Verwendung gefunden hat, sollte es auch auf keinen Fall umdefiniert werden. Ich persönlich halte diesen Sonderwunsch auch nicht für sinnvoll. Ziel muss es sein, das Arbeiten für den Mapper einfach zu halten, und da ist es besser, wenn wir für jedes Objekt (Straße, Ladengeschäft, Bushaltestelle, etc.) beibehalten: Name ist die Bezeichnung, die am Schild drüber dafür steht. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Dokumentation zur Overpass API
Hallo zusammen, es gibt jetzt ein nutzbares Handbuch zur Overpass API https://dev.overpass-api.de/overpass-doc/de/ Das Handbuch soll einerseits den Wunsch nach einer umfassenden Dokumentation erfüllen, andererseits Features jenseits von schlichtem key=value und Bounding-Box mehr Mappern zugänglich machen. Unter anderem deswegen ist es auf Deutsch verfügbar, Englisch und Französisch werden folgen. Zwar befindet sich das Handbuch noch in Aufbau, aber die wichtigen Kapitel "Einführung", "Räumliche Datenauswahl" und "Objekte finden" sind bereits einsatzreif. Die übrigen Kapitel und Abschnitte werde ich in den nächsten Monaten nachtragen. Über Rückmeldung würde ich mich freuen und werde dazu den Github-Issuetracker, die Mailingliste sowie Mails direkt an mich und auch das Forum lesen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Erreichbarkeit von Adressen
Hallo zusammen, Wie hast du die Auswertung erstellt, mit Overpass turbo evtl.? Kannst du die Abfrage bekanntgeben? Ohne zu wissen, wie Florian das konkret gemacht hat. Es funktioniert https://overpass-turbo.eu/s/IF0 Empfohlene Zoom-Level 13-19. Liste der Highway-Typen in Zeile 1, Abstands-Schwellwert in Zeile 3, hier "100". Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass API wegen Upload-Filtern temporär aus
Hallo zusammen, danke für das Verständnis und die positive Rückmeldung. Die Overpass API ist jetzt wieder im Normalbetrieb. Es ergibt natürlich trotzdem Sinn, weiterhin die EU-Abgeordneten anzurufen, siehe https://www.openstreetmap.de/uf/ Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass API wegen Upload-Filtern temporär aus
Hallo zusammen, Super, dass eine weiterhin funktionstüchtige Alternative eingerichtet wurde -- leider erhalte ich dort aber nur einen 403-Fehler. Ist da eventuell ein Konfigurationsfehler drin? Der Zugriff z.B. mit der URL https://overpass-api.de/no_art11art13/interpreter?data=out; sollte funktionieren. Je nach verwendetem Tool muss also entweder https://overpass-api.de/no_art11art13/ als Basis-URL hinterlegt werden (z.B. bei Overpass Turbo, "Einstellungen" > "Allgemeines") oder https://overpass-api.de/no_art11art13/interpreter anstelle von https://overpass-api.de/api/interpreter mit einem POST-Request kombiniert werden oder wie üblich die Anfrage per GET an https://overpass-api.de/no_art11art13/interpreter? angehängt werden. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Overpass API wegen Upload-Filtern temporär aus
Hallo zusammen, am 26. März soll das EU-Parlament über eine Urheberrechtsreform abstimmen, die als Seiteneffekt unter anderem OpenStreetMap gefährdet. Details siehe https://www.openstreetmap.de/uf/ Um alle Nutzer auf die Möglichkeiten zu Protesten hinzuweisen, schließen sich mehrere OSM-Dienste einschließlich der Overpass API dem heutigen Aktionstag an. Bei der Overpass API dauert die Unterbrechung bis ca. 21 Uhr. Nutzer, die statt der normalen Suchergebnisse das Informationsergebnis sehen, können die URL temporär auf https://overpass-api.de/no_art11art13/ ändern. Diese temporäre URL wird dann mit der Wiederherstellung des normalen Betriebs wieder abgeschaltet. Ich bedauere die Unannehmlichkeiten, erinnere aber daran, dass dies der Vermeidung weitaus größerer Unannehmlichkeiten dient. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass Abfrage
Hallo, area[name="Rettungsdienstbereich Trier"]; out tags; hat den folgenden Fund: und ( node[amenity=nursing_home](area:3604168993); way[amenity=nursing_home](area:3604168993); relation[type=multipolygon][amenity=nursing_home](area:3604168993); ); out count; hat zumindest 1 Treffer. Gemäß Gegenprobe mit node[highway=bus_stop](area:3604168993); out count; und 1641 Treffern spricht vieles dafür, dass rund um Trier wohl nur 1 Objekt mit dem Tag "amenity=nursing_home" versehen ist. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass Abfrage
Hi,
Was ich mich schon lange frage bzw. wünsche ist, dass auch bei anderen
Output-Formaten als CSV (also den out settings xml,json,custom,popup)
die Rückgabe-Attribute eingeschränkt werden könnten.
Grundsätzlich geht das mit "convert", hat aber gewollte Einschränkungen.
Beispiel:
(
node[amenity=nursing_home]({{bbox}});
way[amenity=nursing_home]({{bbox}});
relation[type=multipolygon][amenity=nursing_home]({{bbox}});
);
convert poi ::geom=geom(),name=t["name"];
out center;
Als Seiteneffekt kommen dann statt Objekten vom Typ z.B. "way" solche
mit dem Tagnamen "poi" heraus. Außerdem sieht die Geometrie etwas anders
aus. Im JSON-Modus ist die Geometrie GeoJSON-konform, im XML-Modus eine
Übersetzung davon.
Der Grund ist, dass ich vermeiden möchte, dass jemand Tags abschneidet
oder umschreibt und die Daten wieder hochlädt. Die Datenstrukturen
sollten also hinreichend anders aussehen, um Wiederhochladen nach dem
automatischen Umschreiben zu verhindern. Bei den produzierten Formaten
ist noch Gestaltungsspielraum, so dass ich für Rückmeldung insbesondere
zu Anwendungsfällen dankbar bin.
Mit dem Ausrufezeichen kann man noch Keys ausschalten, falls man nicht
nur eine Positivliste möchte:
convert poi ::geom=geom(),::=::,!name;
Referenz:
https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#The_statement_convert
Es gibt zwei Blogbeiträge zu dem Thema:
https://dev.overpass-api.de/blog/final_0_7_54.html
befasst sich mit convert
https://dev.overpass-api.de/blog/flat_world.html
befasst sich mit der Geometrie in diesem Zusammenhang.
Und ich ergebe nicht den Anspruch, Großkreise toll berechnen zu können,
sondern es geht darum, wie ich abzufangen versuche, dass GeoJSON im
Gegensatz zu OSM die Erde als flaches Rechteck betrachtet.
Viele Grüße,
Roland
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Rein unterirdische Gebäude?
Hallo zusammen, aus der Changeset-Diskussion https://www.openstreetmap.org/changeset/64670512 ist die Frage aufgekommen, ob eine Tiefgarage schon ein Gebäude darstellt, wenn die Zufahrt an einer Seite ebenerdig ist. Erschwerend kommt hinzu, dass der Betreiber die Tiefgarage "Parkhaus" nennt. Von der Lage her gibt es rund um das historische Bahnhofsgebäude die Bahngleise auf der einen Seite und einen neu angelegten Bahnhofsvorplatz mit Busbahnhof auf der anderen Seite. Diese sind zueinander ebenerdig. Das Gelände südlich des Bahnhofs liegt viel höher, das Gelände nördlich des Bahnhofs viel tiefer. Dementsprechend ist die Nordfront des Verteilgeschosses unter dem Bahnhofsvorplatz und der Tiefgarage sichtbar. Da der Fußgängerdurchgang zwischen Bahnhofstunnel und Innenstadt somit ebenerdig ist, bildet dies auch die dominante Verkehrsachse. Allerdings haben wir vergleichbare Situationen auch bei Bahndämmen in Köln Hbf, Essen Hbf, Frankfurt Ostbahnhof und Berlin-Friedrichstraße. Dort sind die Bahndämme mit Stützmauern ja ebenfalls kein Gebäude. Ich wäre daher an Rückmeldung interessiert, wie andere die Situation einschätzen. Insbesondere: Gibt es eine sinnvolle Lösung, 3D-Mapping an solchen Hanglagen durchzuführen? Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für Gebäude
Hallo zusammen, Ich arbeite gerade an Indoor-Karten und bin jetzt am Problem dran, ein gesamtes Gebäude herunterzuladen. Das Gebäude besteht aus einem Multipolygon für den Umriss und natürlich den diversen Räumen und POIs im Inneren. Das über eine Flächenabfrage mit Overpass oder über die einzelnen Knoten abzufragen ist, gelinde gesagt, hässlich und sehr fehleranfällig (beispielsweise U-Bahnen, Stromleitungen, Zäune an der Hauswand, etc.). Nun wäre eine Relation, die das gesamte Gebäude einschließt, eine super Sache, um das gesamte Gebäude strukturiert herunterladen und verarbeiten zu können. Es gab bereits Proposals dazu, die Relationen definiert haben, die dafür sehr gut geeignet wären (beispielsweise https://wiki.openstreetmap.org/wiki/Proposed_features/indoor), aber die sind leider alle inaktiv. Wir machen (in Absprache mit Roland Wagner von der Beuth-Hochschule, der SNCF und Simon Poole, der Simple-Indoor entworfen hat) seit einigen Jahren Indoor-Navigation. Die Vorschläge für Relationen sind aus gutem Grund immer wieder aufgegeben worden. Eines der Probleme ist z.B., dass die wichtigsten Strukturen überwiegend ÖPNV-Anlagen sind; diese bestehen nahezu immer aus überirdischen, unterirdischen und ebenerdigen Anteilen. Es gibt eigentlich nie Konsens, was davon noch zum "Gebäude" gehört und nicht einmal wie viele Gebäude es sind - weder unter den OSM-Mappern, noch außerhalb von OSM auf Basis der Definition von Gebäude (gebautes Ding mit Dach); weder Steit darum noch zahlreiche Relationen pro Struktur sind da hilfreich. Von daher wäre ich sehr interessiert zu wissen, um welches Gebäude es sich handelt und warum nicht schon "alles mit Tag 'level' in der Bounding Box/im Polygon" reicht (was in allen anderen bekannten Fällen funktioniert). Viele Grüße, Roland (in diesem Fall dienstlich) -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenzen finden
Hallo, alle Gemeinden in Bayern als Tabelle: https://overpass-turbo.eu/s/BpC Für andere Ziele als Bayern müsste man den Eintrag hinter "area" anpassen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM + Wikidata: Wikidata property proposal fuer eine OSM node ID
Hallo, > Ob OSM "Permanent ID" bereits aus dem Experimentierstadium raus ist, > ist mir unklar. Auf der technischen Ebene ist die Permanent-Id seit Jahren ausgereift. Sie hat aber praktisch keine Akzeptanz. Die Externen suchen da nach einer dauerhaft vergebene Id, und weder Koordinaten nach Namen werden akzeptiert. Umgekehrt bereiten die OSM-Ids auch nicht soviel Leidensdruck, dass da jemand eine konzeptionell schwierigere Lösung akzeptiert. Das Problem ist, dass alle Datenbank-Einführungen, von Relationalen Datenbanken bis zum Semantic Web da sehr dogmatisch sind - es wird immer vorausgesetzt, dass in der Dtanebank repräsentierte Objekte eine Identität haben. Jeder Wikidata-Aktive wird als immer aufs Neue argumentieren müssen, warum er für Geodaten von Ids abgerückt ist - eine Sisyphos-Arbeit. Also konkreter: als OSMler muss ich bei einem Ladengeschäft nicht entscheiden, ob das Gebäude oder der Verkauf das relevante Objekt ist, und ob der Rasen vorm Haus, der Bürgersteig, der Parkplatz und weiteres dazugehören oder nicht. Oder ob es einen Umzug darstellt, wenn ein Geschäft eine Filiale eröffnet und später das Stammhaus schließt, aber die Filiale weiterführt. Für die Identitätsbildung muss ich das festlegen, sonst transportiert die Identität nur einen Namen, und die Koordinate wäre schon die präzisere Information. Ich schlage stattdessen vor, in Wikidata schlicht Koordinaten zu nutzen - wie bisher. Das ist, aus OSM- weil geographischer Sicht die richtige Lösung. Aber da steht uns die Datenbank-Dogmatik entgegen, die, wie geschrieben, Identität als selbstverständlich voraussetzt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass-Integration meldet seit kurzem "Bad-Request" ohne Code-Änderung
Hallo, auf der TüBus-Karte [1] funktioniert seit kurzem -- obwohl der Code nicht geändert wurde -- die Overpass-Abfrage nicht mehr. Der Request wird mit Status 400 beantwortet. Weiß jemand, was sich geändert hat und was ich ändern müsste, damit die Abfrage wieder funktioniert? da muss ich ich entschuldigen. Das war natürlich nicht beabsichtigt. Es handelt sich, wie schon festgestellt, um eine Nachlässigkeit in der Syntax (fehlendes Semikolon). Ich bin schlicht nicht auf die Idee gekommen, dass das bisher funktioniert hat und dass es tatsächlich jemand nutzt. Zu den neuen Version dann möglichst bald mehr Informationen. Die Dokumentation ist noch nicht fertig, daher ist die Version noch nicht angekündigt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Verkehrsverbund Mittelsachsen und OSM
Hallo zusammen, im Auftrag des VMS die folgende Einladung: Herzliche Einladung zum Ideenaustausch beim VMS! Das Gebiet des Verkehrsverbundes Mittelsachsen (VMS) umfasst die kreisfreie Stadt Chemnitz, den Erzgebirgskreis sowie die Landkreise Mittelsachsen und Zwickau. Wir planen, OSM-Daten als Routinggrundlage für unsere elektronische Fahrplanauskunft und als Grundlage zur Erstellung von pdf-Karten zu nutzen. Dieses Vorhaben soll aber nicht ohne Mitwirkung der Community angegangen werden. Der VMS möchte daher zu einem ersten Ideenaustausch einladen: Wann: Montag, 19.02.2018, 18:00 Uhr Wo: Verkehrsverbund Mittelsachsen GmbH, Am Rathaus 2, 09111 Chemnitz, Beratungsraum 4. Etage Nach einem Vortrag zu unserem Vorhaben, würden wir gerne den Dialog mit euch suchen. Wenn ihr teilnehmen wollt, tragt euch bitte hier (https://wiki.openstreetmap.org/wiki/DE_talk:VMS_GmbH) ein, gern auch mit Themen, die diskutiert werden sollten. Viele Grüße, Roland -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relationen löschen (was: Königreich Württemberg)
Hallo zusammen, ich habe mal eine Anleitung geschrieben, damit man das gut in einem Changeset hinbekommen kann: https://wiki.openstreetmap.org/wiki/DE:How_to_delete_a_relation Da ich gerade keine löschbedürftige Relation gefunden habe, habe ich das Hochladen nicht ausprobiert. Von der Logik her sollte es aber gehen. Die Seite ist gewollt im Wiki abgelegt, denn ich freue mich über Ergänzungen aus der tatsächlichen Erprobung. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagprioritaet bei OSM-Suche (historic=yes vs. man_made=*)
Hoi, wenn man in der Kartenansicht auf osm.org mit dem Fragezeichen sucht, dann bekommt man auf der linken Seite eine Trefferliste angezeigt. Keine Ahnung welche Softwarekomponente, die erstellt, jedenfalls wird dort jeweils die Objektnummer und das Haupttag anzeigt, also um was es sich grundsaetzlich handelt. Bei folgender Kombination: man_made=water_well historic=yes wird ``yes'' statt ``water_well'' angezeigt. Siehe https://github.com/openstreetmap/openstreetmap-website/blob/7fd1e559383807dd0b509c7a08642f9d3a48616e/app/assets/javascripts/index/query.js Zeilen 80 bis 112. Es wird wahrscheinlich die Konfiguration aus https://github.com/openstreetmap/openstreetmap-website/blob/e3357b27e61c3ee4f4cf51c87fdc94deeaaa7c6f/config/locales/de.yml verwendet. Es gibt dort unter man_made (Zeilen 715 bis 720) keinen Eintrag für water_well und auch sonst keine Key-Value-Kombination, die passt. Also wird alternativ unter den bekannten Keys für den alphabetisch ersten sein Wert direkt übernommen. Der alphabetisch erste ist hier "historic", und das hat den Wert "Yes". Um das zu beheben, mache also bitte einen Issue auf https://github.com/openstreetmap/openstreetmap-website auf, dass in die Datei openstreetmap/openstreetmap-website/config/locales/de.yml der Eintrag "man_made: water_well: Übersetzung auf Deutsch" hinein soll. Den wird vermutlich jemand schließen und erklären, auf welchem Weg die Übersetzungen in das Repository kommen (war, glaube ich, mal Transifex ?!?). Da müsste dann eine Übersetzung für "man_made"="water_well" auf Deutsch eingetragen werden. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Public transport V2: wie Fahrt-Nr. zu einer Ref angeben?
Hi Dietmar, beim Matching Fahrpläne vs. OSM ist Mentz eigentlich immer betroffen. Augsburg wird entweder direkter Kunde sein oder über die bayrische Auskunft DEFAS versorgt. Zur Erinnerung: Mentz routet auf dem OSM-Straßen- und Schiennetz, d.h. wir werten Haltestellen aus, und der Ablgeich zwischen VU-Daten und OSM-Daten findet auf dieser Ebene (ganz präsize: auf Ebene der Steige) statt. Wir benutzen keine Routen-Relationen aus OSM. Die andere Frage ist: wofür wollen wir die oben genannten Daten erfassen? Erst wenn man eine konkrete Anwendung benennt, dann kann man herausfinden, ob die Daten sich dafür eignen. Das schließt nicht aus, dass es später auch andere Anwendungen gibt, und so sollte es auch sein. Aber ohne zumindest eine Anwendung produziert man das, was Jochen neulich zum Thema Grenzrelationen als schwer auswertbare Daten angesprochen hatte. Für die Anwendung "Fahrplanauskunft" braucht man gar keine Routen-Relationen. Ich persönlich hätte ansonsten gerne eine Karte, auf der alle Linien eingetragen sind, die häufig fahren. Wie es jemand auf der FOSSGIS so schön schilderte: er sucht sich Hotels danach aus, dass sie eine häufige Verbindung zum Konferenzort haben, und dafür möchte er wissen, wo man vom Konferenzort aus häufig und problemlos hinkommt. Dann wäre es vor allem gut, auf den Relationen der oben genannten Linien ein Tag "Fahrten pro Tag" zu haben, so dass man die Relationen als selten bedient identifizieren kann. Die Diskussion darum versandet allerdings regelmäßig in anderen Grabenkämpfen. Die Fahrten-Nr selbst sind mir sonst noch nirgendwo als relevante Information begegnet, sondern entweder betriebsintern oder tiefer Bestandteil der Fahrplandaten. Ich würde in der Gesamtwürdigung die Fahrten-Nr einfach in "note:de" belassen und überlegen, für welche Anwendung man die Daten haben möchte. Ansonsten sei auf die Mailingliste nahverkehr@ hingewiesen; dort lesen zumindest mehr ÖPNV-affine Mapper mit. Viele Grüße, Roland Am 22. Juni 2017 um 22:06 schrieb Dietmar Seifert <ostr...@diesei.de>: > Hallo Toni, > > Du hast geschrieben: >> Die Frage ist aber: brauchen wir das wirklich, dass eine Anwendung ref >> und Fahrt-Nr. auswählen will? >> Was wäre das Szenario für sowas? >> Oder kann das anderweitig hergeleitet werden - nicht zu kompliziert halt? >> "anderweitig hergeleitet" vor allem für Relationen für die es keine >> Fahrt-Nr. gibt - im MVV ist mir sowas noch nicht aufgefallen. >> "anderweitig hergeleitet" als kleinster gemeinsamer Nenner? >> > > Nehmen wir an, ich nutze ein ÖPNV-App und will von Ort A Haltestelle x > nach Ort B Haltestelle y: dann kann die App pur in OSM die möglichen > Relationen finden. > > Eine App muß aber auch konkret sagen, wann der nächste Bus kommt. Das > geht nur mit dem Fahrplan der ÖPNV-Linie. Der User gibt Zeitpunkt und > Srt und Ziel an und dann wird im Fahrplan die richtige Tour gefunden. > Dann kann zwar in OSM geprüft werden, ob es eine oder mehrere Relationen > gibt, wo Start und Ziel enthalten sind. Zusätzlich müssten aber alle > weiteren Stopps auch noch geprüft werden. Erst bei kompletter > Übereinstimmung würde vermutlich eine OSM-Relation übrig bleiben. > > Ich würde als App-Entwickler eine stabile Querbeziehung suchen und das > wäre erst die Fahrtnummer (oder bereits eindeutig oder nur in Verbindung > mit Buslinie, muss ich noch prüfen). > > @Roland: seid Ihr da betroffen bzgl. Matching Fahrpläne vs. OSM > Bus-Relationen? > > viele Grüße > > Dietmar > > > > Am 22.06.2017 um 21:48 schrieb Toni Erdmann: >> Hallo Dietmar, >> >> für die unterschiedlichen Strecken- und/oder Stopverläufe sollen laut >> PTv2 jeweils genau eine Relation erstellt werden. >> PTv2 sagt nichts über die von Dir hier erwähnten Fahrt-Nr. - die scheint >> es nicht so häufig zu geben. >> >> Ich interpretiere PTv2 aber so, dass die Fahrt-Nr. *nicht* in die "ref" >> hinein kommt. >> Wenn wir also eine Unterscheidung der Fahrt-Nr. machen wollen, dann >> brauchen wir meiner Meinung nach einen weitere Key: ref:xxx oder so? >> >> name=Bus 15 >> ref=51 >> ref:xxx=1501 >> ref:xxx=1502;1503 >> ref:xxx=1504 >> >> für 4 Fahrten über 3 unterschiedliche Routen. >> >> Die Frage ist aber: brauchen wir das wirklich, dass eine Anwendung ref >> und Fahrt-Nr. auswählen will? >> Was wäre das Szenario für sowas? >> Oder kann das anderweitig hergeleitet werden - nicht zu kompliziert halt? >> "anderweitig hergeleitet" vor allem für Relationen für die es keine >> Fahrt-Nr. gibt - im MVV ist mir sowas noch nicht aufgefallen. >> "anderweitig hergeleitet" als kleinster gemeinsamer Nenner? >> >> Gruß >>
Re: [Talk-de] Nutzung von building:part durch Mentz GmbH
Hallo Tobias, danke für den Hinweis. Zum Wiki ist orgendwie wohl bei keinem eine Benachrichtigung angekommen. mir ist aufgefallen, dass Mentz beim Bahnhofsmapping eine inkompatible Interpretation des Schlüssels building:part gewählt hat. Generell brauchen wir von Aufzügen zwei Objekte: - der Aufzug selbst, der für das Routing angibt, in welcher Etage auf welcher Seite überhaupt Türen sind - die Aufzugfläche. Diese zeigt an, welchen Raum der Aufzug einnimmt. Nun haben Aufzüge immer ein Dach. Nach oben offene Aufzüge sind mir (zumindest im ÖPNV-Umfeld) noch nicht begegnet. Daher befindet sich ein Aufzugschacht immer in einem Gebäude oder bildet selbst ein Gebäude (per Definition eine von Menschen errichtete Struktur mit Dach). Der Prototyp aller Aufzüge ist aus unserer Sicht immer der Aufzug in Lehel: https://wiki.openstreetmap.org/wiki/File:M%C3%BCnchen_Lehel_Lift.jpg http://www.openstreetmap.org/way/305665757 Dass die Struktur ein Dach hat, dürfte zweifelsfrei sein. Auch, dass sie so prägend für das Bild des Platzes ist, dass sie im 3D-Rendering zu sehen sein sollte. Es bleibt die Frage, ob jetzt der Aufzug alleine das Gebäude ist oder ob die U-Bahn-Station insgesamt ein Gebäude bildet. Letzlich würde ich aus der Rückfrage den Vorschlag ableiten, dass - wir einen Stationsumriss mit building=subway_station zeichnen, wenn die Station in der Gesamtheit ein Gebäude bildet. Dann bekommt der Aufzugschacht building:part=yes. - wir ansonsten den Aufzug als building=elevator eintragen Für die Stockwerke ist der Verweis auf building:part auch für mich etwas verwirrend. Ich muss mal herausfinden, ob wir das überhaupt für etwas brauchen. Eigentlich sollte indoor=yes reichen. Viele Grüße, Roland -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer: Christoph Mentz, Amtsgericht München, HRB 91898 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM - mehr Speicher
Hi, generell lässt sich das am besten mit dem JAR-File bewerkstelligen, für WebStart ist mir keine Lösung bekannt. Wie kann ich JOSM sagen, dass er gern 1..2 GB benutzen darf? beim Start? in den Einstellungen? wie? [..] java -Xmx2048M -jar "josm-latest.jar" Dies funktioniert auf Betriebssystemen mit vollwertiger Kommandozeile. Viele Computernutzer sind aber dazu gezwungen, auf Windows zu arbeiten. Weil wir das Problem hier auch unter Windows hatten: - stelle sicher, dass Du 64-Bit-Java benutzt. 32-Bit-Java kann keine 2 GB RAM, sondern nur etwa 1 GB (genaue Grenze unklar, Betriebssystem minus Java-VM) - baue Dir eine Datei josm.bat, die im gleichen Verzeichnis wie josm-latest.jar liegt und die Zeile C:\Pfad\zu\java.exe -Xmx20148M -jar "josm-latest.jar" enthält. Dabei muss Pfad\zu ersetzt werden durch den tatsächlichen Pfad; bei mir auf dem Dienstrechner liegt im Download-Verzeichnis: "C:\Program Files (x86)\Java\jre7\bin\java.exe" -jar "josm-tested.jar" Grüße Roland -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer Dr.-Ing. Hans-J. Mentz Amtsgericht München, HRB 91898 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mechanischer Edit: Tag-Anpassung
Hallo zusammen, thematisch gehört es auf die Liste nahverkehr@, aber aus Sichtbarkeitsgründen auch einmalig an talk-de@. Im Nachgang zu https://forum.openstreetmap.org/viewtopic.php?id=54210 würde ich gerne - alle Vorkommen von "entrance:light"="yes" auf "entrance_marker:s-train"="yes" ändern - alle Vorkommen von "entrance:subway"="yes" auf "entrance_marker:subway"="yes" ändern - alle Vorkommen von "entrance:tram"="yes" auf "entrance_marker:tram"="yes" ändern - alle Vorkommen von "entrance:train"="yes" auf "entrance_marker:train"="yes" ändern Ich werde mich jeweils vergewissern, dass das Tag zumindest zum Eingang eines Bahnhofs gehört, der in Deutschland liegt und an dem die betreffenden Verkehrsmittel (nach Auffassung des Bahnhofsbetreibers) auch verkehren. Das es sich um Bahnhöfe in Großstädten handelt, habe ich oft Ortskenntnis, wenn auch bis zu 10 Jahre alt. Was ich bei diesem Edit nicht prüfen würde, ist ob das Schild kürzlich wegvandaliert wurde oder ähnliches. Insofern ist es ein Mechanical Edit. Viele Grüße, Roland (dienstlich) -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer Dr.-Ing. Hans-J. Mentz Amtsgericht München, HRB 91898 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 20 City-Zonen in Westfalen
Hallo zusammen, gibt es Wünsche, wie wir die Tarifgebiete im künftigen Westfalentarif taggen sollen? Nachdem jetzt über einge Tage keine weitere Rückmeldung gekommen ist, würden wir den Vorschlag von Nakaner aufgreifen. Die Gemeinde-gleichen Tarifgebiete als kopierte Relationen und die Gemeinde-abweichenden Relationen als eigens gemappte Multipolygone. Den Vorschlag mit den Shapefiles von Thomas kann ich nachvollziehen, wir werden ihn aber nicht weiterverfolgen können. Aus Geo-Sicht sind Shapefiles vertraut. Aber aus VU-Sicht muss ich dann den Sachbearbeiter, der die Geografie unter Umständen als Nur-Teilaufgabe miterledigt, auch ein Tool für Shapefiles bekommen, darin geschult werden und wir müssen Support dafür leisten, obwohl alle übrigen Aufgaben mit JOSM gehen. Auch das ist dann eher mit Kanonen auf Spatzen geschossen. Viele Grüße, Roland -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer Dr.-Ing. Hans-J. Mentz Amtsgericht München, HRB 91898 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 20 City-Zonen in Westfalen
Hallo zusammen, gibt es Wünsche, wie wir die Tarifgebiete im künftigen Westfalentarif taggen sollen? Ab August 2017 wird in Westfalen ein neuer Gemeinschaftstarif eingeführt. Um Fragen für die Zugänglichkeit als Open Data der Tarifzonen gleich im Ansatz zu lösen, überlegen die beteiligten Städte und Kreise bzw. Verkehrsunternehmen, die Geographie direkt in OSM einzutragen. Bei den meisten der 300 Tarifzonen gibt es dazu nichts zu tun, weil sie mit den Gemeindegrenzen identisch sind. Rund 20 Tarifzonen weichen aber davon ab, entweder als Sammlung von Stadtteilen oder als Straßenliste. Details habe ich noch nicht. Wir würden daher gerne den Sachbearbeitern eine Empfehlung zum Taggen geben. Bisher würde ich dazu neigen - an bestehenden Gemeindegrenzen ein Tag "westfalentarif:zone"= zu ergänzen - bei den 20 abweichenden Tarifgebieten jeweils ein Multipolygon möglichst unter Nutzung bestehender Grenz-Ways mit -- type=boundary -- boundary=public_transport -- westfalentarif:zone= anzulegen. Zur Unterstützung der Themenstruktur für die Mailinglisten rege ich an, das auf der nahverkehr@-Liste zu diskutieren. Gerne kann jemand auch im Forum darauf hinweisen, dann böte es sich an, den Link hier zu posten. Viele Grüße, Roland (dienstlich) -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer Dr.-Ing. Hans-J. Mentz Amtsgericht München, HRB 91898 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konfigurationsfehler Apache www.openstreetmap.de (WAS: Deutsche Homepage - Fehlermeldung)
Hi, es gibt einen ganz neuen Security-Checker von Mozilla. http://www.heise.de/newsticker/meldung/Mozilla-bringt-kostenlosen-Sicherheitstest-fuer-Websites-3306197.html An dem beiße ich mir zur Zeit die Zähne aus. Die Details kann ich noch nicht beurteilen, geschweige denn anpassen. Das Ding ist grob unseriös. Z.B. ist CORS ein anerkannter Web-Standard, der regelt, wie Daten von Drittseiten eingebunden werden können. Folgt man dem Standard, dann besteht keinerlei Sicherheitsrisiko. Ohne auch nicht unbedingt, aber das ist ein anderes Thema. Der Security Check streicht aber die Hälfte der Punkte, wenn eine Website den Standard unterstützt. Auch die übrigen Anforderungen sind vom Typ: "sende noch diese 27 Extra-Header mit". Vom Senden zusätzlicher Header wird allerdings nichts sicherer. Entweder hat der Server oder der Client eine Sicherheitslücke oder nicht. Entweder gibt es einen Man-In-The-Middle, der dann auch die Header setzen oder durchreichen kann, oder nicht. Das steht im starken Kontrast zu SSLLabs. Dort wird gezielt getestet, ob man abgehört werden oder Inhalte untergeschoben bekommen kann, obwohl die SSL-Verschlüsselung aktiv ist. Das ergibt Sinn, weil man mit SSL (HTTPS) das nicht erwarten würde. Es lohnt also nicht, für den Mozilla-Scan irgendwas zu tun. Das Ding ist Web-Politik, nicht Web-Sicherheit. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Eisenbahn-Themen auf osm-nahverkehr
Hallo zusammen,
bevor jemand sich übergangen fühlt, ein Mechanischer Edit ("priority"
von Ways mit "railway" entfernen) und eine Fragestellung zu einem
Eisenbahn-Tag ("service"="siding" an wichtigen Bahnhofsgleisen) habe ich
auf der Liste
http://lists.openstreetmap.de/mailman/listinfo/nahverkehr
aufgeworfen.
Zur Entlastung der Liste talk-de schlage ich vor, Diskussionen dort zu
führen.
Viele Grüße,
Roland
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Solingen
Hallo Simon, Ich habe einen Kontakt. via legal-questi...@osmfoundation.org, mit jemand von "Vermessung und Kataster" der Stadt Solingen, der uns anscheinend diverse Strassen(um)benennungen mitteilen will. Der nächstgelegene tatsächlich aktive Stammtisch ist Düsseldorf. In der Umgebung, in Wuppertal, sehr aktiv und ansprechbar ist User bilderhobbit. Von der Ortskenntnis her kannst Du mich aber auch gerne in CC nehmen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] DB-Bahnhöfe und OSM
Hallo zusammen, die Bahn hat, wie hier ja schon angekündigt, eine Liste aller ihrer Aufzüge in ihr Open-Data-Portal gestellt http://data.deutschebahn.com/datasets/aufzug/ und dazu eine experimentelle API aufgesetzt, die zu einigen Aufzügen ihren Betriebsstatus anzeigt: https://www.mindboxberlin.com/index.php/contest.html?file=files/cto_layout/downloads/opendata/SSTBT_REST-API_ADAM_1_contest_alpha.yaml Viele der Aufzüge, wenn auch nicht alle, haben Geokoordinaten. Der (mit oder ohne OSM) nützlichste Anwendungszweck ist sicher, dass man als Rollstuhlfahrer weiß, bevor es zu spät ist, ob man an einem Bahnhof aussteigen kann. Ein solches Routing sollte natürlich auf OSM-Daten stattfinden (und sonst hat auch keiner genug Geodaten). Also habe ich ein Tool gebastelt, mit dem man pro Bahnhof nachvollziehen kann, wie gut die DB- und OSM-Daten zusammenspielen oder wie gut unsere Daten überhaupt sind: http://olbricht.nrw/adam/bahnhof.html Man gibt dem Tool einen Bahnhof, und dann zeigt es, welche DB- und OSM-Daten es hier gibt. Im besten Fall sind die Aufzüge lila oder grün, und das Routing funktioniert in alle Richtungen, wie z.B. in "Aachen-Rothe Erde". In vielen Fällen fehlen Aufzüge in OSM noch völlig, obwohl die DB angibt, dass dort welche existieren, so z.B. in "Remagen" (gelbe Punkte auf der Karte). In machen Fällen sind einfach die Geodaten der DB vermutlich falsch, z.B. in "Aachen Hbf" (ebenfalls gelbe Punkte). Dennoch kann das Routing in solchen Bahnhöfen funktionieren oder auch nicht. In Aachen Hbf gibt es z.B. Nodes, die ungewollt den Bahnsteig mit der Unterführung verbinden: http://overpass-turbo.eu/s/dLU Andere Fehler sind weitaus subtiler: In "Anderten-Misburg" z.B. schließt der Aufzug direkt an eine Treppe an - was hoffentlich nicht so in der Wirklichkeit gebaut worden ist. Vielleicht hat ja der eine oder andere Lust, die Routbarkeit seines Gewohnheitsbahnhof aufzubessern. Ich werde mich mal an die Bahnhöfe zwischen Troisdorf und Münster geben. Insgesamt gibt es noch sehr viel zu tun. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit Bahnhofsmapping von MentzDV
Hallo zusammen, > Ja. Ein Revert wäre sicherlich übertrieben. Mein eigentlicher Punkt ist > und bleibt aber, dass ich bei bezahlten Mappern (auch wenn "nur" Hiwis) > doch etwas höhere Ansprüche anlegen will, da man bei beruflichem > Mapping einfach auch schneller mehr kaputt machen kann. Imho verhält > sich das ählich zu Imports und mechanischen Edits. Ja, das Anliegen verstehe ich sehr gut. Allerdings würde ich aus den "Ansprüche" lieber gerne konkrete und messbare Qualitätskriterien machen. Wenn man weiß, was genau man einhalten sollte, kann man es auch einhalten. Insofern habe ich jetzt "kleinere Changesets" mit auf die Liste genommen und unten ein paar Details dazu unten aufgeführt. >> - Erinnerung an richtige Quellen: Daten allein aus "bahnhof.de" >> gehören nicht nach OSM. > > Gut. Aber wie handhaben wir das, falls er/sie wirklich aus dieser Quelle > nach OSM übertragen hat? Es wurden zudem mehrere Quellen angegeben, was > es nochmal komplizierter macht. Bei source=Google wäre es wohl ein > klarer Revert. Ich denke, dass es darauf hinausläuft, generell keine Daten systematisch ohne weitere Kontrolle aus schematischen Plänen zu übernehmen. Das betrifft hier nur die Bushaltestellen, und die hat Lars mittlerweile gelöscht, so dass diese Quelle wegfällt. Im Allgemeinen haben solche Skizzen-Quellen nur einen geringen Nutzen; ausreichend genaue Positionen wird man üblicherweise nicht erreichen können. Wenn ein Mapper (bezahlt oder unbezahlt) eine ausreichend exakte Position für ein skizziertes Objekt aus anderen Bezügen ermittelt, ist das ein eigenständiges Faktum unabhängig von der Skizze. > Was mir persönlich geholfen hätte: Etwas kleinere Changesets. Thematisch > noch zusammenhängender und auch quellenabhängig. Dann kann man auch > schneller und vor allem einfacher prüfen, ob ein Changeset ok ist oder > nicht. Danke für den Hinweis. Ich würde das im konkreten Fall lesen als: - ein Changeset für die Bahngleise und Bahnsteige - ein Changeset für die Bushaltestellen - ein Changeset für den sonstigen Bahnhofsvorplatz - ein Changeset für die Brücke "Bahnsteg" samt Aufzug Reicht das oder ließe sich das noch sinnvoll feiner teilen? > Deinem Punkt "Kontakt mit der Community suchen" kann ich mich nur > anschließen, würde das aber gerne argumentativ mit dem beruflichen Mappen > verknüpfen. Ich fände es in solchen Fällen nämlich nicht akzeptabel, wenn > man/ihr durch häufiges Verwenden und viel Mappen Fakten schaffen würdet. Im Hinblick auf ein "Fakten schaffen" ist das durchaus schwierig. Wenn ein Verkehrsverbund mit einer Datenbank um die Ecke käme, welche Bushaltestellen ein Wartehäuschen haben und welche nicht, hätten danach fast alle Haltestellen in der Region ein "shelter"-Tag. Das verändert unvermeidlich Tagging-Proportionen. Einen ähnlichen Effekt hat die Wochenaufgabe, ganz ohne bezahlte Mapper. Auch da ist es ja gewollt, dass ein bestimmtes Phänomen möglichst flächendeckend auf eine einheitliche Weise erfasst wird - und dann anschließend die vorherrschende Modellierung ist. Auf der anderen Seite steht eine durchaus lange Liste an Wiki-Proposals, die dann schlussendlich nie umgesetzt worden sind, weil man sich in eigentlich irrelevanten Details festdiskutiert und gleichzeitig real auftretende Probleme übersehen hat, statt eine Lösung umzusetzen, die gut genug ist. Von daher würde ich persönlich sehr stark dazu tendieren, etwas erst in signifikantem Umfang zerstörungsfrei zu taggen, dabei und danach drüber zu diskutieren, und dann gegebenenfalls umzutaggen - viele Konzepte lassen sich erst an konkreten Beispielen gut erläutern. Das gilt für bezahltes Mapping wie für unbezahltes Mapping. Da es für das "level"-Tag zumindest nicht ohne Werkzeuge möglich ist, es automatisch außerhalb von Gebäudekonturen zu unterdrücken, kann ich gerne damit leben, es dort auch nicht zu taggen. Gruß, Roland Am 31. August 2015 um 20:36 schrieb Peter Barth <osm-p...@won2.de>: > Hallo Roland, > > vielen Dank für deine schnelle Reaktion. > > Roland Olbricht schrieb: >> [...] >> Es sind höchstwahrscheinlich weitere Spielräume für Verbesserungen, >> die sich zu mappen lohnen. Allerdings würde ein Revert wie oben >> aufgeführt einen deutlich schlechteren Zustand zurückholen. Daher >> würde ich hier eher die Passauer Mapper bitten, den jetzigen Zustand >> weiterzupflegen. >> [...] >> Insgesamt: Ich finde es gut, dass wir miteinander reden. Angesichts >> des vorherigen Zustands würde ich stark vermuten, dass Weiterpflegen >> zielführender als ein Komplett-Revert ist. > > Ja. Ein Revert wäre sicherlich übertrieben. Mein eigentlicher Punkt ist > und bleibt aber, dass ich bei bezahlten Mappern (auch wenn "nur" Hiwis) > doch etwas höhere Ansprüche anlegen will, da man b
Re: [Talk-de] Problem mit Bahnhofsmapping von MentzDV
node/2859736224 * Das Dach an Gleis 1 (http://osm.org/way/367435344) wurde im Rahmen der Umbauarbeiten abgerissen. * Diese Dinger hier (http://osm.org/way/367435327) sind Verkaufsautomaten und keine Kioske Ich denke, hier gibt es vor allem die für Armchair-Mapping typischen Probleme: - nicht jedes Lufbild ist noch ausreichend aktuell - nicht alles ist auch das, wonach es auf Luftbildern aussieht Ich würde dazu eigentlich nur die ergänzende Empfehlung aussprechen wollen, dass Armchair-Mapper bestehende Strukturen, gerade was in was enthalten ist, nicht verändern sollten. Tagging-Varianten: * Was sollen die ganzen Fußwege? Ich finde es nicht gut, die zum Zwecke eines Routings einzutragen. Die sind da nämlich nicht sondern die ganzen Bushaltestellen sind direkt entlang der Straße und da gibt's halt noch einen Gehsteig. Z.B. das hier: http://osm.org/way/367608093 Generell gibt es für Fußwege die beiden Modelle, den Fußweg separat zu mappen oder den Fußweg über Attribute im Weg zu beschreiben, und beide stehen gleichberechtigt nebeneinander. Fußwege wegzugeneralisieren erlaubt, wenige Objekte zu zeichen. Das führt in komplizierten Situatione aber regelmäßig dazu, dass man eine falsche Topologie liefert oder gar nicht mehr weiß, wo es Fußwege gibt und wo nicht. Der obige Fall ist da durchaus ein gutes Beispiel: Weg 7718378 ist vorher getaggt gewesen als für Fußgänger verboten. D.h. ganz strikt hätte man an den Haltstellen in der Unterführung also nur aussteigen und wieder einsteigen, aber nicht weggehen dürfen. Selbst wenn man jetzt nur das "access"-Recht für Fußgänger umgesetzt hätte, wäre überhaupt nicht klar, wo da die Fahrradfahrer durchmüssen: es existiert andernorts sowohl die Variante "Fahrradfahrer auf der Busspur" (Münster Hbf) als auch "Fahrradweg zwischen Busbucht und Bushaltestelle" (auch mehrere Fälle in Münster) als auch "Fahrradweg hinter der Haltestelle" und eventuell weitere Varianten. Das kann man in einem komplexen Lane-Tagging umsetzen, das 80% aller Mapper dann erst einmal interpretieren müssten und dass sich zu exakten Positionen ausschweigt. Oder man mappt einfach mit separaten Linien das, was da ist und dort, wo es ist bzw. pro separiertem Verkehrsmittel die Mittellinie - das versteht dann jeder Map per. So weiß man jetzt: die Fahrradfahrer benutzen die gleiche Fahrbahn wie der Bus, auf der Nordseite ist kein Fußweg und auf der Südseite läuft er hinter der Bushaltestelle. * Gleiches auf den Bahnsteigen (http://osm.org/way/367435362). Imho gehören da keine Fußwege hin. Ein Router sollte schon selbst erkennen können, dass die ganze Bahnsteiglänge für's Einsteigen gedacht ist. Das Modell stammt gar nicht von uns, sondern hat sich schon seit langer Zeit etabliert: man mappt die Blindenleitstreifen als Fußwege. Wenn keine vorhanden sind, mappt man trotzdem die Fußwege da, wo üblicherweise Blindenleitstreifen wären. Wiederum ist das für einen Durschnittsmapper leicht zu verstehen, es ist topologisch korrekt, und es hält die Tür Richtung Blindenmapping offen. * Dann gibt es zig Wege die jetzt ein level-Tag haben, was outdoor wohl wenig Sinn macht (z.B. http://osm.org/way/8099444) Immerhin gibt es einen Aufzug am Nordende. Wie ist der Aufzug beschriftet? Ich würde mal vermuten, dass sich dessen Obergeschoss auf den ganzen "Bahnsteg" bezieht und nicht an der Turmgrenze endet. Zumindest in Wuppertal induziert der Ausgang an der Kluse durchaus Ebenen auf seinen diversen Zugängen. Generell: Wie wollen wir sonst mit vertikalen Strukturen umgehen? Für einen Laien dürfte eine Gliederung in Ebenen der intuitivste Zugang sein, siehe Tools wie http://github.pavie.info/openlevelup/ Von daher würde ich anregen, das dann auch so in OSM zu leben. * Die Hüttchen (z.B. http://osm.org/way/367435322) sind buildings und keine Unterstellmöglichkeiten. Die Dächer hingegen (z.B. http://osm.org/way/367435339) sind nur Dächer. * Als Busbahnhof würde ich das (http://osm.org/node/2098613373) auch nicht bezeichnen. Der Busbahnhof ist ein paar Hundert Meter weiter östlich. Ich denke, das werdet Ihr mit Ortskenntnis sicher besser einschätzen können oder Euch auf etwas einigen. Insgesamt: Ich finde es gut, dass wir miteinander reden. Angesichts des vorherigen Zustands würde ich stark vermuten, dass Weiterpflegen zielführender als ein Komplett-Revert ist. Für die Betreuung unserer Hiwis nehme ich folgende Erkenntnisse mit: - Erinnerung an richtige Quellen: Daten allein aus "bahnhof.de" gehören nicht nach OSM. - Armchair-Mapping: Keine Bestandsdaten in OSM ohne triften Grund überschreiben, Luftbilder können veralten. - Den Kontakt zur Community suchen. Dazu brauchen wir allerdings noch zielführende Tools. Bitte ergänzt die Liste, falls ich etwas vergessen habe. Viele Grüße, Roland -- Dr. Roland Olbricht mdv - Mentz Datenverarbeitung GmbH Westfalenstraße 224 48165 Münster e-Mail: olb
Re: [Talk-de] OSM und der Bahnstreik
Hallo Harald, Und was ist, wenn in dem von mir angesprochenen Bereich (Südthüringen, nordwestliches Oberfranken) an sehr vielen route=train ein name mit KBS sonstnochwas steht? Das wäre dann nach obiger Ausführung falsch und müsste nach route=railway umgetaggt werden und wäre somit nicht mehr für die von Roland gewünschte Karten nützlich?! eine Liste der Linien in Thüringen gibt hier http://de.wikipedia.org/wiki/Liste_der_SPNV-Linien_in_Th%C3%BCringen Zumindest in Nordrhein-Westfalen werden die Liniennummern auch aktiv verwendet, während man die KBS-Nummern suchen muss. Allerdings ist das keine 1:1-Korrespondenz, so dass man ggf. die Linienrelationen erst zusammenbauen muss. Ich kann verstehen, dass das wiederum nicht mal eben geht. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM und der Bahnstreik
Hallo zusammen, heute melde ich mich mit einem etwas pragmatischen Anliegen. Das Thema Bahnstreik wird ja wieder aktuell, aber viele Bahnlinien sind gar nicht vom Streik betroffen, weil sie nicht (mehr) von der Deutsche Bahn AG betrieben werden. Ich denke, dass man da mit einer Karte, was alles fährt, durchaus auch außerhalb von OSM interessierte Nutzer findet. Als Werkzeug der Wahl habe ich uMap genommen, da es auf jeden Fall öffentlichkeitserprobt ist. Ich habe das mal für NRW zusammengestellt: https://wiki.openstreetmap.org/wiki/DE:UMap/Beispiele Die hier gesammelten Links können wir dann auch an die Presse weitergeben. Meine Bitte wäre, dass vielleicht der eine oder andere Lust hat, das für andere Bundesländer nachzubauen. Für ganz Deutschland würde das zwar im Prinzip auch gehen, aber die Karte ist so schon eher grenzwertig langsam. Die wesentlichen verwendeten Daten sind die Linienrelationen rel[route=train][operator=...] wobei das Operator-Tag das spannende ist. Erster Schritt ist Qualitätssicherung. Zumindest in NRW sind die Tags nicht sehr flächendeckend erfasst gewesen. Die Nacherfassung habe ich wie folgt gemacht: Eine Abfrage wie http://overpass-turbo.eu/s/9ri erlaubt, die gewünschte Bahnlinie zu finden, indem man vorher den Bahnhof in Sicht holt und passende Werte einträgt (oder [ref...] ganz weglässt, wenn es hier nicht zu viele Linien gibt) . Das geht gut mit der kleinen Textzeile in der Kartenansicht in Overpass-Turbo. Mit einem Klick auf (nicht Ausführen, sondern) Export Daten Level 0 bekommt man eine Warnmeldung, die man wegklicken kann, dann mit erneutem Klick auf Level 0 werden die Daten im Editor Level 0 geöffnet. Da kann man jetzt pro relevanter Relation den Operator-Tag leicht ergänzen (ohne Berge von Daten laden zu müssen). Hier muss man sich nur noch Anmelden, einen Changeset-Kommentar eintragen und Zu OSM hochladen. Der zweite Schritt ist, die Karte zu bauen: Wir wählen auf http://umap.openstreetmap.fr/de/ Erstelle eine Karte. Hier habe ich für das Beispiel den Hintergrund gewechselt, das Kartenscrollen begrenzt und unter Karteneinstellungen (Zahnrad rechts) Standardeinstellungen die Werte 4 für Glättungsfaktor, 0.5 für Deckkraft und 4 für Stärke eingetragen. Damit werden sie als Defaults verwendet. Die Daten bekommen wir wie folgt nach uMap. Mit einer Abfrage wie http://overpass-turbo.eu/s/9rj sammelt man die Daten in Overpass-Turbo. Dort kann man rechts mit dem Reiter Daten die Daten gesammelt markieren und kopieren (z.B. Reinklicken und Strg+A) und in uMap in das Feld Daten importieren (Pfeil nach oben) Füge Deine Daten hier ein einfügen. Nun noch Datenformat OSM und In eine neue Ebene hochladen auswählen und auf Importieren klicken. Final können wir jetzt auf das Symbol links unter +/- zeigen und dort die passende Ebene 2 zum Bearbeiten anklicken. Wieder rechts können wir der Ebene einen Namen geben und unter Erweiterte Eigenschaften die Farbe zentral für diese Ebene festsetzen. In der Hoffnung, dass man dann besser erkennen kann, wo ab Mittwoch noch was fährt, Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM und der Bahnstreik
Hallo Harald, Hauptfrage meinerseits wäre, warum du z.B. die Overpass-Abfrage nicht selbst als Datenquelle in uMap nutzen möchtest. Gibt ja hier definitiv Nachteile (Daten werden jedes Mal neu geladen wirkt sich negativ auch auf overpass aus) und Vorteile (Daten sind aktuell ohne jedes Mal manuell Daten zu ersetzen. Der Vorteil fällt hier nicht sehr ins Gewicht, weil sich die Bedienung einer Linie allenfalls am Fahrplanwechsel ändert. Umgekehrt habe ich die Verbindung zwischen Overpass API und uMap im ersten Anlauf nicht ans Laufen gebracht und daher darauf verzichtet. Hier geht es ja darum, eine solche Karte schnell (2 Stunden nach der Idee dazu) fertigzustellen, und einen Großteil braucht da schon die Präsentation sowie die Prüfung, ob die Daten vollständig sind. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene OSM-Karte mit Overpass
Hallo, ist vielleicht die Briefkastenkarte sowas was du suchst: http://briefkastenkarte.de/ erst einmal freut es mich, dass jemand die Seite herausgesucht hat. Ich finde sie von der Idee her sehr gut. Man sollte da technische Details nicht zu hoch hängen. Im Blog dazu gibt es auch eine gute Anleitung wie sie gemacht wurde: http://blog.briefkastenkarte.de/ Mit der neuen Quota-Regel für die Overpass API [2] werden inzwischen auch etliche Abfragen mit einem Fehler abgewiesen (429 Too Many Requests). Ob dadurch Briefkästen nicht angezeigt werden oder einfach eine neue Abfrage abgesetzt wird, habe ich mir allerdings nicht mehr genau angesehen. Es sieht eher danach aus, als wenn Briefkästen dann nicht gefunden werden. Es scheint mir beim Drüberschauen vielleicht doch ein Problem der briefkastenkarte.de zu sein, weil das Problem auf der Beispielseite des Leaflet-Plugins nicht auftritt. Falls auch OpenLayers geht, was meistens der Fall ist, möchte ich gerne auch auf die Seiten http://overpass-api.de/open_layers_mashup.html und speziell http://overpass-api.de/open_layers_multilayer.html hinweisen. Das sieht zwar nicht schön aus, aber zeigt die Abfragemechanik. Das wesentliche Detail ist hier der sehr kurze Timeout. Dies verringert das Risiko von 429ern, weil die Abfragen nicht noch auf dem Server nachlaufen, wenn der Benutzer schon weggescrollt hat. 5 Sekunden wären vermutlich auch OK, aber 180 Sekunden sind für diesem Einsatzzweck definitiv zuviel. Generell würde ich die folgenden Maßnahmen empfehlen: - max. 5 Sekunden Timeout - Anzeige einer unaufdringlichen Sanduhr, solange Requests laufen oder dafür pausiert wird, damit der Endnutzer noch keine Daten von leeres Suchergebnis unterscheiden kann - mit 429 zurückkehrende Requests nach 15 Sekunden wiederholen - Requests serialisieren Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
Hallo zusammen, Kurze Nachfrage. In wie fern hängen footway/path=sidewalk und sidewalk=detached zusammen, bzw unterschieden die sich? Danke für den Hinweis. Das ist (für Fußwege) ziemlich genau das, was ich gesucht habe und zu Jochens Vorschlag passt. Dass es zusätzlich sidwalk=detached gibt, liegt vermutlich daran, dass der russische Nutzer ebenfalls das Tag footway=sidewalk nicht gefunden hat. Es sollte mit in die Wiki-Dokumentation zu highway=footway aufgenommen werden: http://wiki.osm.org/wiki/DE:Tag:highway%3Dfootway In diesem Fall reicht es sogar, das nur in der deutschen Version nachzuziehen. Nun bräuchten wir ein ähnliches Tag für straßenbegleitende Radwege. Ob es noch andere straßenbegleitende Wege gibt und insofern ein allgemeinerer Ansatz Sinn ergibt, weiß ich nicht. I.e. ein Router kann bei Vorhandensein von footway=sidewalk den Namen der nächstgelegenen Straße holen Das ist eben algorithmisch nicht sinnvoll lösbar. Dazu möchte ich an das Beispiel In der Beek (Fußweg ziemlich weit weg, trotzdem ersetzt er den Fußweg an der Straße) erinnern. Vermutlich gibt es auch den umgekehrten Fall, bei denen mehrere Straßen als Namensgeber in Frage kämen, aber da habe ich gerade keines zur Hand. Man kann mit Heuristiken gute Trefferquoten erreichen, aber ich würde daher die Empfehlung ins Wiki schreiben wollen, den Namen einzutragen. Umgekehrt ist Name ignorieren, wenn footway=sidewalk ein sehr einfacher Algorithmus. Aus ähnlichem Grund tragen wir bei Adressen im Allgemeinen ja auch den Straßennamen erneut mit ein. Weil es auf überraschend viele Arten mehrdeutige Situationen geben kann, auch wenn die meisten Gebäude an einer eindeutig bestimmbaren Straße liegen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
Hallo zusammen, erst einmal danke für die umfangreiche Rückmeldung und auch einige weitere erhellende Beispiele. Ich würde gerne an Jochens Analyse und Vorschlag anknüpfen wollen. Aber wir haben halt nunmal sehr viel Renderer (bzw. Kartenstile), die damit nicht umgehen könnten. Und ich sehe auch nicht, wie man das mit vertretbarem Aufwand in die Software einbauen kann. Wir würden damit also bestehende Anwendungen vor ein Problem stellen. Diese Information ist ganz wichtig. Offenbar haben Renderer mehr Fallstricke als ich erwartet hätte. Ich nehme an, es geht nicht so sehr um die zusätzlichen Labels, wenn Platz ist: https://www.openstreetmap.org/#map=19/48.13872/11.61015 sondern um die in die Straße ragenden Labels, wenn eigentlich kein Platz ist https://www.openstreetmap.org/#map=17/48.13872/11.61015 Das scheint allgemein ein schwieriges Problem zu sein, weil ein paar Meter weiter https://www.openstreetmap.org/#map=17/48.13711/11.61489 es für die Secondary-Straße in Nord-Süd-Richtung so aussieht, als wenn sie Richard-Strauß-Tunnel heißen würde - sie heißt Leuchtenbergring, wie der Trunk, der südlich anschließt. Umgekehrt scheint es wohl keinen anderen Anwendungsfall außer Rendering zu geben, in denen die zusätzlichen Informationen ein Problem bedeuten würden. Dies ist ein Nebenweg der mehr oder weniger parallel zu einem Hauptweg lang geht. Dieses Tag könnte beim Rendering bzw. bei der Suche herangezogen werden, um den Straßennamen zu unterdrücken. Der Name kann dann auf die Nebenwege drauf, der Router kann ihn wie von Roland gewünscht nutzen. Danke für den Vorschlag. Von Marc Gemis kam der Hinweis, dass dafür sidewalk=detached in Gebrauch ist. Fürs Routing würde sich der Ansatz auf jeden Fall eignen. Ich nehme an, dass Renderer das Rendern des Namens unterdrücken können, wenn ein spezielles zusätzliches Tag auftritt? Alternativ könnte man natürlich auch einen neuen name-Tag einführen: Name des parallel führenden Hauptweges. Damit muss man beim Rendering nichts ändern. Mit diesem Ansatz könnte ich auch gut für den Router arbeiten. Einziger Nachteil wäre, dass andere Routing-Engines das nicht automatisch übernehmen, im Gegensatz zum name-Tag. Für die Renderer wäre das vermutlich die arbeitssparendere Lösung. Wenn sich kein großer Protest erhebt, würde ich also dann an osm-talk herantreten mit kurzer Zusammenfassung des Problems und der Einschätzung aus talk-de, dass a) name-Tag plus ein Zusatztag (z.B. sidewalk=detached oder parallel_to_road=yes, sollen die britischen Muttersprachler entscheiden) b) parallel_road:name = Name (oder andere Keys, nach Votum der Muttersprachler) pragmatische Lösungen wären und dem Ziel, das im Wiki als geeignete Vorgehensweise zu dokumentieren und für neue Edits zu verwenden. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
Hallo, erst einmal danke für die rege Beteiligung an der Diskussion. Es macht Hoffnung, dass eine daraus abgeleitete Regel ausreichend breit diskutiert worden ist. Ich verstehe nicht ganz, worum es geht Ich würde gerne zu einer einfachen Regel kommen: Alle Teile eines Straßenzuges tragen den Namen des Straßenzuges im name-Tag. Ob die Aufteilung bei der Modellierung längs zur Straßenrichtung (verschiedene Eigenschaften in verschiedenen Abschnitten, z.B. Geschwindigkeiten oder Relationszugehörigkeiten) oder quer zur Straßenrichtung (verschiedene parallele Fahrbahnen je Richtung oder Verkehrsmittel) erfolgt, ist dabei unwichtig. Das ist eine Regel, die für Mapper gut zu verstehen und intuitiv ist. Bis jetzt sieht es auch so aus, als wenn alle heute vorstellbar Software damit gut funktionieren kann. wer löscht hier was? In diesem Fall geht es zunächst um das Changeset http://www.openstreetmap.org/changeset/30258818 Julia hat hier nach Rücksprache mit ortskundigen Kollegen entschieden, dass der Weg neben der Straße Bestandteil des Straßenzugs ist. Den ersten Kommentar im Nachhinein zum Löschen zufolge scheint es historisch in München an anderen Stellen Mapper gegeben zu haben, die solche Information gelöscht haben. Da ich jene Ereignisse nicht gefunden habe, habe ich nach aktuellen Meinungen gefragt. Grundsätzlich sollten in OSM nur Dinge ein name-Tag haben, die auch so heissen. Die Frage, zur der ich gerne ein Meinungsbild hätte, ist ja gerade, ob alle Teile einer Straße den Namen haben oder nur irgendwelche speziellen Fahrbahnen nach irgendwelchen technischen Kriterien. Ich habe hier Fälle im Kopf wie a) die Siebengebirgsallee in Troisdorf Da gibt es auf jeder Seite eine durchgehende Fahrbahn für Anlieger mit Bürgerstein und Bordstein und in der Mitte eine (nichr verbundene) Durchgangsfahrbahn für PKWs. Ich denke, dass da die Anliegerfahrbahnen den Namen der Straße zweifelsfrei verdient haben (und nicht namenlose Fahrbahnen sind, weil in der Mitte eine weitere Fahrbahn liegt. b) die Kölnstraße in Bonn, nörderlich der A565 Da gibt es eine PKW-Fahrbahn plus auf einer Seite einen sehr breiten Fußweg, der Anliegern zur Zufahrt und als Parkflächen dient. Von a) unterscheidet er sich im Wesentlichen durch die Abwesenheit einer Bordsteinkante. c) die von Christian Horrmann zitierte Straße Da liegt ein getrennter Rad-/Fußweg vor. Genauso wie Volker Schmidt würde ich dann gerne beim Radouting die Anweisung entlang der Tunibergstraße bekommen und nicht entlang dem namenlosen Radweg. Für mich hat also in allen Fällen der Parallelweg ebenso den Namen wie die eigentliche Straße. Kriterien wie Dieser Straßenabschnitt hat nur einen Namen, wenn er einen Bordstein hat oder es keine parallele Fahrbahn gibt (für a) und Fußgängerzonen) oder Dieser Straßenabschnitt hat nur einen Namen, wenn er mit einem mindestens 3,5-t-Fahrzeug befahren werden könnte (für nur a) und b) ) erscheinen mir arg künstlich. Die obige Regel Namen an alle Teile eines Straßenzuges ist da viel einfacher und klarer. Umgekehrt gibt es auch nur zufällig parallele Wege, z.B. hier: http://www.openstreetmap.org/#map=18/50.8/7.17300 (vor Ort ist ein deutlicher Höhenunterschied zwischen Fuß-/Radweg am Fluss und PKW-Fahrbahn) auf denen die ortskundigen Mapper dann den Namen nicht eintragen würden. Das ist die eigentliche Krux: es handelt sich um ein Problem, dass algorithmisch nicht lösbar ist. Und daher würde ich gerne die Mapper ermuntern, ihre Ortskenntnis in die Kartendaten einzubringen statt mit Algorithmen herumzuraten. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fußgänger-Diskriminierung?
Liebe Mitmapper, für die Arbeit am Fußgängerrouting von mdv würde ich gerne ein Meinungsbild einholen. Dort haben wir (in diesem Fall MentzDV, aber z.B. Graphhopper auf osm.org ist auch von dem Phänomen betroffen) für viele Fußwege derzeit keinen Namen. Die Arbeit, Fußwege getrennt zu erfassen, können wir zum Glück ja noch an den meisten Stellen vermeiden; das Kriterium aus dem Wiki, Fußwege nur getrennt zu erfassen, wenn man als Fußgänger nicht an jeder Stelle die Straße überqueren kann http://wiki.openstreetmap.org/wiki/File:Bremen_cycleway_separate_1.jpg (Geländer im hinteren Teil des Bildes) reduziert die zu erfassenden Fälle aufs Wesentliche. Es ist schwer vorstellbar, Wege noch sinnvoll in Tags der Fahrbahn kodieren zu können, wenn da schon ein Erdwall http://www.openstreetmap.org/#map=19/52.10108/4.36549 (Weg entlang der N14) oder gar ein Bach zwischen ist http://www.openstreetmap.org/#map=19/51.26546/7.10764 (Weg entlang In der Beek) Bei solchermaßen aufgeteilten Straßen gibt es nun die Tendenz, den üblicherweise auf einem Straßenschild auf dem Fußweg http://wiki.openstreetmap.org/wiki/File:IMG_20150416_125451.jpg angebrachten Namen nicht nur zusätzlich auch auf der PKW-Fahrbahn unterzubringen, sondern auch vom Fußweg wieder zu löschen. Gibt es dafür einen triftigen Grund? Der einzige, der mir bisher genannt wurde, sind technische Unzulänglichkeiten in einigen Renderern (Unerwünschtes Mehrfach-Rendering des Namens). Das würde ich aber nicht als einen Grund ansehen, von der On-The-Ground-Regel (Schild steht ja meist im Fußweg oder an der Hauswand oberhalb des Fußwegs) abzuweichen und nur willkürlich ausgewählte Fahrbahnteile ohne physisch vorhandenes Schild mit Namen zu versehen. Wenn es keinen triftigen Grund gibt, würde ich das dann gerne im Wiki ordentlich dokumentieren, dass der Name an allen Teilen eines Straßenzugs vermerkt wird. Es würde das Fußgängerrouting dann enorm erleichtern, wenn man nicht darüber spekulieren müsste, welcher Fußweg, gerade in Grenzfällen, noch dem Namen einer nahegelegenen Fahrbahn zuzuordnen ist und welcher nicht. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] HTTPS auf overpass-api.de
Liebe Mitmapper, danke für den Hinweis mit dem SSL-Zertifikat. Ich werde es auch in den nächsten Tagen erneuern. Zu einem verantwortungsvollen Umgang mit der Technik gehört aber auch, die Sicherheit dahinter einzuschätzen. Ich denke, das Image der SSL-Zertifkate ist, dass sie irgendwie sicher sind, während Seiten ohne Verschlüsselung irgendwie unsicher sind. Ich würde das gerne detaillieren. Die Zertifikate werden von Organisationen herausgegeben, die damit Geld verdienen wollen. Sie sind arauf angewiesen, dass die Browser-Hersteller sie als vertrauenswürdige Institution eintragen. Das machen Browser-Hersteller erschreckend häufig: über 200 solcher Organisationen stehen im Browser. Wenn irgendeine der Organisationen sich bösartig verhält, kann sie an einen Dritten ein Zertifkat ausstellen, mit dem er behaupten kann, der legitime Anbieter von overpass-api.de zu sein. Um das mal zu vergleichen: stell Dir vor Zugschaffner zu sein, und 200 verschiedene Firmen dürfen für den Zug gültige Fahrscheine herausgeben. Nicht nur der Betreiber, sondern 200 verschiedene Firmen. Wie wahrscheinlich ist es, alle Schwarzfahrer zu finden? Welche Chancen hat ein Fahrgast, trotz gutem Willen ein ungültiges Ticket zu haben, weil sein Verkäufer unseriös war? Man kann einwenden, dass ein Angreifer mehr tun muss: er muss den Datenverkehr zwischen Browser und dem Webserver, auf dem die Overpass API liegt, abfangen. Das muss er allerdings für eine unverschlüsselte Verbindung ebenfalls. Ohne große Mühen können das z.B. Programme auf dem eigenen Rechner (macht der Notebook-Hersteller Lenovo [1]), Dein Zugangsprovider [2] oder im Falle eines WLANs in der Regel jeder andere Teilnehmer im WLAN, mein Zugangsprovider oder Hosting-Anbieter oder auch Lauscher an großen Umschlagpunkten [3]. In allen diesen Fällen haben die Mitlauscher es geschafft, sich auch ein gültiges Zertifikat zu verschaffen. Zwischen der Sicherheit verschlüsselter und unverschlüsselter Verbindungen hat es also exakt keinen Unterschied gegeben. Unberechtigte Zertifikate zu ehalten ist aber nicht nur für Geheimdienste [2] und Anbieter suspekter Software [1] möglich, sondern auch für Einzelpersonen [4]. Um ein Zertifkat für eine Website zu bekommen, muss man nur in der Lage sein, eine eMail an eine Adresse wir postmas...@overpass-api.de zu einem selbstgewählten Zeitpunkt lesen zu können. Praktischerweise passiert das auf dem gleichen Kanal wie die spätere Verbindung zur Overpass API per HTTPS; diesen muss man für einen Angriff ohnehin kontrollieren können. Dazu kommen alle außerplanmäßigen Wege, wie z.B. Geheimdienst oder Polizei oder ausreichend wichtiger Mitarbeiter eines der Zertifikat-Herausgeber zu sein oder sich als Geheimdienst oder Polizei oder Mitarbeiter plausibel ausgeben zu können. Umgekehrt haben die Zertifikat-Herausgeber ein kommerzielles Interesse, diesen Zustand so aufrecht zu erhalten. Den anderen großen Hebel haben die Browser-Hersteller: aber auch für sie bringt es keinen Vorteil, die Liste der Herausgeber zu verkürzen; jeder Herausgeber könnte im Ernstfall eine Geldquelle sein, weil die Herausgeber auf das Vertrauen der Browser-Hersteller angewiesen sind. Nutzer können das zwar individuell überstimmen, aber die Mehrheit wird das nicht oder zumindest nicht auf allen genutzten Rechnern tun. Es sei in den Raum gestellt, dass sich Mozilla für Firefox ausgerechnet mit dem Community-basierten CACert schwertut, sie in die Standardliste der vertrauenswürdigen Anbieter aufzunehmen [5]. Möglich wäre mehr Sicherheit durchaus: letztlich läuft es daraus hinaus, dass ich meine persönliche Quelle des Vertrauens als gesonderte Hardware mit dem Gerät verbinde. Als Karte analog zur SIM-Karte oder als USB-Stick, um davon zu booten. Im Gegensatz dazu verbreitet sich mit Certificate Pinning [6] ein Verfahren, das inhärent große Anbieter bevorzugt: man muss sich wieder mit dem Browser-Hersteller gutstellen, damit er für die eigene Seite nur die Zertifikate eines einzelnen Anbieters akzeptiert. In der Praxis wird das heißen, eine Bürokratie zu durchlaufen, Geld auf den Tisch zu legen oder eine Kombination aus beidem. Wie aussichtsreich das für die Seiten im OSM-Umfeld ist, kann man an dem Umgang mit CACert absehen. In der Summe heißt das also, dass ich jemandem Geld oder Zeit schenken soll, damit er meinen Nutzern keine Angst einjagt (legal, im Gegensatz zu [7]). Im Sinne des Komforts für den Nutzer tue ich das. Aber es soll niemand sagen, er habe nicht gewusst, dass es keinen Sicherheitsgewinn bringt. Für die Quellen danke ich übrigens Fefe und der Suchfunktion in seinem Blog. Viele Grüße, Roland [1]: http://thenextweb.com/insider/2015/02/19/lenovo-caught-installing-adware-new-computers/ [2]: http://googleonlinesecurity.blogspot.de/2013/12/further-improving-digital-certificate.html [3]: http://www.heise.de/newsticker/meldung/NSA-Skandal-Provider-hilft-BND-angeblich-beim-Zugriff-am
Re: [Talk-de] Ein Wunsch für openstreetmap.de
Hallo, Aber mit gebräuchlichen oder historischen deutschen Bezeichnungen hat sie es nicht. Man kann aber den Deutschen Mapnik Style wählen, dann taucht name:de auf. Man kann auch old_name:de ohne eigenen Server auf eine Karte bekommen: Ein Beispiel http://umap.openstreetmap.fr/de/map/anonymous-edit/31333%3AtEnT47_lN4SM17iFWEDfdD_bZ3g und die Anleitung, wie man das bauen kann: Wir brauchen zunächst die Daten. Das geht mit einer Abfrage wie: http://overpass-turbo.eu/s/83n Im Grunde kann man auf diese Weise die Daten auch gleich visualisieren, wobei eben noch keine Namenspopups dranstehen. Dafür spiegelt die Abfrage immer den aktuellen Stand wider. Die vor dem Drücken auf Ausführen eingestellte Kartenansicht ist wesentlich. Es wird nur innerhalb der Kartenansicht gesucht. Ansonsten erhält man so viele Daten, dass der Browser in die Knie geht. Wir wollen das aber jetzt in eine Karte auf uMap umsetzen und nutzen die Daten zur Weiterverarbeitung: http://overpass-turbo.eu/s/83o und auf Ausführen klicken. Den Tab dann bitte offen lassen, wir werden das Ergebnis gleich brauchen. Von https://umap.openstreetmap.fr/de/ startet man mit Erstelle eine Karte. Mit Daten importieren (Pfeil nach oben in Kreis am rechten Rand) bekommen wir das benötigte Werkzeug. Wir stellen das Datenformat auf csv. Dann kommen per CopyPaste aus dem anderen Tab, dort unter Daten, die Daten in das Textfeld. In der obersten Zeile der kopierten Daten ersetzen wir old_name:de durch name, damit wir die Spalte gleich als Namensfeld zur Verfügung haben. Durch Klick auf Importieren übernehmen wir die Daten. Nun wählen wir Karteneinstellungen bearbeiten (direkt unter Daten importieren in der Werkzeugleiste), dort Standardeigenschaften und weit unten in der aufklappenden Liste über Name immer anzeigen den Wert Ja anstelle von erben. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass-QL Frage
Moin, Ich möchte gerne alle Daten eines Gebietes (eingegrenzt durch Relation). [..] Gibt es eine Möglichkeit die Objekte außerhalb der Grenzrelation ohne Attribute zu laden? Ja, das geht. Probiere mal bitte die folgende Abfrage: [out:xml]; area['de:amtlicher_gemeindeschluessel'='16070029']-.a; ( way(area.a); node(area.a); relation(area.a); )-.b; .b out; // Zeile 8 .b ; (._;- .b;); out skel; In Zeile 8 geben wir alle Objekte aus, die tatsächlich in dem Gebiet liegen. Weil wir die Menge gleich nochmal brauchen, speichern wir sie nach .b zwischen. In Zeile 9 lösen wir die Referenzen der Relationen und Ways auf, mit Standardergebnis nach ._. In Zeile 10 bilden wir die Differenz mit .b, so dass nur noch Objekte übrig sind, die wir noch nicht ausgegeben haben. In Zeile 11 geben wir das fertige Resultat dann aus. Was leider nicht geht, ist, die Objekte dabei strikt nach Typ zu sortieren. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Beispielhafte OSM-Nutzung für Online-Artikel gesucht
Am Mon, 9 Feb 2015 01:25:52 +0100 schrieb Jo winfi...@gmail.com: [..., viele Beispiele, ...] Danke für eure weiteren Infos, das sind schöne Anwendungen! Das sollte reichen, um was draus zu machen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Beispielhafte OSM-Nutzung für Online-Artikel gesucht
Hallo Leute, die Open-Data-Arbeitsgruppe des Landes NRW (Open.NRW) möchte einen Online-Artikel über OSM veröffentlichen, in dem die Vorteile von offenen Geodaten durch einen konkreten Nutzungsfall beschrieben werden. Dafür suchen wir einen OSM-Benutzer, der mit OSM-Daten oder -Karten etwas machen konnte, was er ohne OSM nicht hätte umsetzen können, z.B. weil die kommerziellen Lizenzen zu teuer oder restriktiv gewesen wären oder die Daten von OSM besser waren. Das muss nichts spektakuläres sein, z.B. fällt mir spontan eine Nutzung der Karte im Schulunterricht o.ä. ein. Wenn Du Lust hast der zuständigen Redakteurin Deine OSM-Nutzung kurz zu beschreiben und mit Namen in dem Beitrag auftauchen magst, würde ich mich über eine Mail sehr freuen. Dann stelle ich den Kontakt her. Beste Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schwarzwald bei Ludwigsburg ?
Hallo, http://overpass-turbo.eu/s/64G findet den Teilstring Schwarzwald in allen Relationen. http://overpass-turbo.eu/s/64H läuft etwas schneller, weil es nur auf den String Schwarzwald anspricht. Das ganze für Ways (nur die exakte Variante): http://overpass-turbo.eu/s/64I Achtung: zieht man die Bounding-Box größer, wird die Abfrage nicht langsamer. Da ist aber auch nichts plausibles bei. Es handelt sich also wohl um einen Bug in der Rendering-Queue. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schwarzwald bei Ludwigsburg ?
Entschuldigung, Tippfehler: Achtung: zieht man die Bounding-Box größer, wird die Abfrage nicht langsamer. *deutlich* langsamer Das hat technische Gründe: bei dieser Größe wechselt der Abfragekern die Strategie, und das ist in diesem Fall wohl keine gute Idee. Kommt zu den Enhancements für die Overpass API. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] priority=* an railway=*
notwendig, auf den meisten Nahverkehrsstrecken das Tag service=regional nachzuerfassen. Eine Änderung ist hier aber unvermeidlich, da sich solche Routenrelationen im Tagging sonst nicht von Güter- und Museumsbahnen unterscheiden. Viele Grüße, Roland (drolbr_mdv) -- Dr. Roland Olbricht mdv - Mentz Datenverarbeitung GmbH Westfalenstraße 224 48165 Münster e-Mail: olbri...@mentzdv.de Tel: +49 (0) 2501 969 232 Fax: +49 (0) 2501 969 300 http://www.mentzdv.de Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer Dr.-Ing. Hans-J. Mentz Amtsgericht München, HRB 91898 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Karte auf openstreetmap.de defekt
Hallo Leute, die Karte auf http://www.openstreetmap.de/karte.html ist seit mindestens gestern Nachmittag defekt. Ich erinnere mich, dass es mal ein Repository mit den Webseite-Quellen gab, kann es aber momentan nicht finden. Daher bin ich dankbar für Hinweise, wo das Repository ist und was evtl. kaputt sein könnte bzw. eine Reparatur. Vielen Dank und beste Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Umweltzone Köln
Köln nachfragen, was die Aufklärung vermutlich vereinfacht. Wie sieht es in anderen Städten aus? Treten dort die Probleme auch auf? Fazit: Insgesamt hat es zwar einige Stunden gedauert, die Umweltzone einzutragen. Aber die Daten anzufragen, unter Umständen nachzuhaken, sie in irgendeinem nicht direkt konvertierbaren Format zu bekommen, eine Konvertierung zu basteln und auf Plausibilität zu prüfen hätte länger gedauert. Viele Grüße, Roland (drolbr) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gelöschte Daten finden [was: 3D-Mapping]
Hallo zusammen, Wie weit geht denn das in die Vergangenheit? Es sind alle Daten ab dem Lizenzwechsel eingespielt, also erster OdBL-Planet (vom September 2012) plus alle Diffs seitdem. Abfragen vor dem September 2012 sind technisch möglich, finden aber keine weiteren gelöschten Daten, da obiger Planet kein History-Planet gewesen ist. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wartungsarbeiten auf der Overpass API
Dear all, overpass-api.de ist wieder im Normalbetrieb. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wartungsarbeiten auf der Overpass API
Liebe Overpass-Nutzer, der Server overpass-api.de wird am Mittwoch morgen, zwischen 7 Uhr und 12 Uhr MESZ für Wartungsarbeiten heruntergefahren. Die tatsächliche Unterbrechung sollte weitaus kürzer sein, ich möchte aber keine Mutmaßungen abgeben. Der Server unter overpass.osm.rambler.ru steht wie gewohnt zur Verfügung und sollte während der Wartungspause als Ersatz genutzt werden. Wir werden die Hardware um eine SSD zu 480 GB erweitern. Das sollte die Geschwindigkeit für Abfragen spürbar erhöhen. Ein Dank an dieser Stelle an den FOSSGIS für die Finanzierung. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?
Hallo zusammen, Wenn du möchtest, dass der Käfertaler Wald wieder gerendert wird, musst du ihn so eintragen, wie es gute fachliche Praxis ist. Aus wessen Fach? Ich kenne andere Meinungen. Für den gesamten Käfertaler Wald legst du ein Multipolygon an, das aus zwei outer-Inseln besteht – eine nördlich der A 6, eine südlich davon, ggf. noch weitere Inseln, falls es zwischendrin breite Schneisen durch Straßen/Stromleitungen/... gibt. Das Multipolygon trägt die Tags Generell sind großflächige Relationen aus technischer Sicht heikel, und daher ist von deren Gebrauch eher abzuraten. OSM unterstützt drei Arten von Gliederung. Das eine ist String-Gleichheit, das zweite ist räumlicher Bezug, das dritte sind Relationen. String-Gleichheit ist effizient zu komprimieren, robust gegen Fehler und einfach zu verstehen. Z.B. trägt ein Großteil unseres Straßennetzes Tags wie highway=residential oder highway=motorway. Auch Filialen eines verteilten Systems lassen sich gut identifizieren, z.B. operator=Sparkasse. Räumlicher Bezug entsteht dadurch, dass ein Objekt in einem anderen enthalten ist. Wenn man z.B. alle Sparkassen-Filialen in Mannheim finden will, kann man mit PostGIS, QGIS, der Overpass API etc. einfach den Umriss von Mannheim anlegen. Das ist für Datennutzer etwas anspruchsvoller als String-Gleichheit, aber für Mapper sehr bequem, denn die Bezüge stimmen ebenfalls automatisch, wenn man das Objekt am richtigen Ort plaziert. Und umgekehrt hilft die Lage geographischer Objekte oft, andere zu plazieren. Wenn ich weiß, dass mein Lieblingsrestaurant rechts im Einkaufszentrum XY ist, kann ich den Node ausreichend genau legen, ohne das Einkaufszentrum ausmessen zu müssen. Das dritte Kriterium zur Gliederung sind Relationen. Sie haben erhebliche Unfallgefahr: man sieht der Relation nicht automatisch an, welche Eigenschaften wie Tags und räumliche Ausdehnung sie haben und schlimmer, man sieht einem Objekt nicht automatisch an, dass es Teil einer Relation ist. Ändert man die Geometrie des Objektes, so zerstört man oft die Relation. Daher ist aus der Sicht von Editoren, Tools zur OSM-Datennutzung, Datenformaten und dem Renderer sinnvoll, Relationen nur dann zu benutzen, wenn weder String-Gleichheit noch räumlicher Bezug vorhanden sind. Im konkreten Fall liegt aber in jedem Fall räumlicher Bezug vor. Ein Baum steht im Käfertaler Wald, weil er sich innerhalb der scharfen oder unscharfen Grenzen des Käfertaler Waldes befindet und nicht, weil ihn irgendeine besondere Eigenschaft mit den übrigen Bäumen im Käfertaler Wald verbindet. Denkprobe: Wenn zu Weihnachten Weihnachtsbäume im Käfertaler Wald eingeschlagen werden, verteilt sich dann der Wald danach auf ein paar hundert Wohnungen? Wohl eher nicht. Zweite Denkprobe: Einen hypothetischer See im Wald würde ich als liegt im Käfertaler Wald bezeichnen. Spricht ebenfalls für räumliche Zugehörigkeit. würde es sich eher anbieten, außen herum die Grenze als place=locality, name=Käfertaler Wald zu taggen und die einzelnen Gebiete mit landuse=forest, name=[jeweils passender Name] taggen. Schneisen sind eine schlechte Idee, da sie wiederum die Arbeit mit den Daten dazwischen enorm erschweren. Sie erwecken zudem den Eindruck, man hätte die genaue Straßenbreite berücksichtigt. Ich habe mehrmals die Freude gehabt, Straßen zwischen landuse-Nutzungen zu editieren, was enorm mühselig ist, weil der Editor nicht weiß, dass man jetzt Straßennodes und nicht landuse-Nodes anfassen möchte und schon gar nicht, dass die landuse-Nodes bei Verschiebungen den Straßennodes folgen müssten. Auch da gilt: Dem Datennutzer ist durchaus bekannt, dass mitten auf der A6 keine Bäume wachsen, und die Straßenbreite ist entweder an der Straße spezifiziert oder nicht genau bekannt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] konkurrierende Tags vs mechanical edits [war Re: Stolperstein-Relationen entsorgen?]
Hallo zusammen, Spätestens dann, wenn ich konkurrierende, undokumentierte Tags im zweistelligen Bereich aufräume. Der andere Weg wäre, die beiden konkurrierenden Tags vor sich hin wachsen zu lassen. Wie wäre es mit: Die Mapper anschreiben, die das Tag benutzen, auch bei kleiner Anzahl? Es könnte helfen zu klären, ob die Tags überhaupt das gleiche bezeichnen. Wenn ja, lassen sich Mapper eigentlich immer von einheitlichem Tagging überzeugen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was ist Openstreetmap wert?
Nachdem ich heute gelesen habe, für wieviel Geld ein Datenaufbereiter über die Theke gegangen ist, frage ich mich wieviel Openstreetmap wert sein könnte? OpenStreetMap ist keine handelbare Sache. Das ist auf talk-fr auch gerade diskutiert worden: https://lists.openstreetmap.org/pipermail/talk-fr/2014-January/066466.html Man könnte theoretisch die Foundation übernehmen wollen, aber das macht vor allem Ärger, weil man seinen Ruf dabei ruiniert ohne viel zu gewinnen. Der frustrierte Rest kann einen Fork gründen, was z.B. bei LibreOffice auch funktioniert hat. Die Daten einsperren könnte man auch nur abstrakt: man müsste die Foundation dazu bekommen, mit entsprechend großer Mitgliedermehrheit die Daten ohne Share-Alike umlizensieren zu lassen, dann mit einer proprietären Lösung zusammenführen und das Ganze soweit verbessern, dass niemand mehr Lust hat, an den Originaldaten weiterzupflegen. Das ist ähnlich aussichtsreich wie der erste Ansatz, weil man auch dabei seinen Ruf ruiniert. Nebenbei könnte man sich sogar juristischen Ärger einhandeln, weil das Vorgehen klar gegen die Offene-Lizenz-Klausel verstößt. In jedem Fall hat die Gemeinschaft alle Mittel, einfach mit anderem Namen und Sympathiebonus weiterzumachen. Eine andere Stoßrichtung des Threads könnte sein, eine beeindruckende Zahl zu produzieren. Das ist enorm schwierig. Zunächst einmal sind das eigentlich beeindruckende die geringen Betriebskosten von etwa 25.000 EUR im Jahr. Angesichts der sehr breiten Nutzung dürfte es nur Tage oder Stunden dauern, den Betrag zusammenzubekommen, wenn das nötig würde. Das hat sich gerade beim Betriebssystem OpenBSD gezeigt. Also noch die Zahl des Tages: Im Jahr 2013 sind auf der Overpass API Daten von über 14000 Teilnetzen des Internet mit 198 verschiedenen Länderkennungen (sind so ziemlich alle), zusammen aus gut 60% des überhaupt verfügbaren IPv4-Raumes abgefragt worden. Die Kartenabrufe auf osm.org werden wohl noch breitere Nutzerschichten erreichen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stolperstein-Relationen entsorgen?
Hallo zusammen, Könntest du mir so eine einfache Abfrage, die mir alle z.B. Bushaltestellennodes listet die nicht in einer bestimmten Relation sind. Das habe ich bisher nicht hinbekommen. http://overpass-turbo.eu/s/2kh Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Ortsnamen in Osteuropa
Hallo zusammen, Ich würde gerne eine breit angelegte Aufräumaktion vorschlagen, bei der wir alle name:de keys in old_name:de verwandeln. Die Änderungen wären auf ein noch genauer zu definierendes Gebiet und für Orte unter einer noch genauer zu definierenden Einwohnerzahl (zb 500 000) beschränkt. Findet Nominatim den Schlüssel old_name:de? Tourismus ist zumindest nahe der Ostsee-Küste ein relevanter Wirtschaftszweig, und daher möchte manche Stadt auch anhand des alten deutschen Namens zuverlässig gefunden werden. Was sagt die jeweilige lokale Community? Die polnische hat auf jeden Fall gerade einen missglückten Massenedit abbekommen. Da müsste eine solche Änderung unbedingt in jedem Fall zuerst vor Ort diskutiert werden. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass sehr langsam
Hallo zusammen, Kommt es mir nur so vor, oder ist Overpass seit Beginn der Weihnachtsfeiertage extrem langsam geworden? Anfragen, die vorher 1-30sec dauerten laufen nun oftmals 3min oder länger. Zeitgleiche Requests gehen fast gar nicht (http 429: too many requests)... Es gibt auf overpass-api.de eine Reihe von Ereignissen, die gerade in der Tat für Verlangsamung sorgen. Verbesserung auf das alte Niveau ist ab Silvester zu erwarten, Verbesserung auf ein besseres Niveau ab Ende Januar. Im Detail: Zunächst einmal hat seit Einführung des Export-Links von osm.org aus (siehe unter Export, dann unter dem Export-Button) für vermehrte übergroße Map- Abfragen gesorgt - zum Teil bis zu dem halben Planeten. Da die Abfrage aber auch eine Reihe von Export-Anliegen sinnvoll löst, möchte ich den Link nicht wieder entfernen. Um zu verhindern, dass die Map-Calls zu sehr auf den Server insgesamt durchschlagen, habe ich den Parameter für parallel von der gleichen IP-Adresse mögliche Abfragen von 2 auf 1 gesenkt. Damit richten insbesondere die beiden häufigsten problematischen Verhalten nur noch halb so viel Schaden an: Vermeidbare Last erzeugt es, eine große Anfrage zu stellen, nach einigen Sekunden abzubrechen und dann sofort die gleiche Anfrage erneut zu stellen. Generell kann man eine laufende Abfrage mit http://overpass-api.de/api/kill_my_queries abbrechen und Platz für eine alternative Query schaffen. Ein anderes problematisches Verhalten ist es, dutzendweise Anfragen ohne Rückmeldung parallel zu stellen. Das erzeugt Lastspitzen bzw. würde Lastspitzen erzeugen und die Zeit bis zum Abschluss der letzten Abfrage ist genauso lang wie bei einer sequentiellen Abarbeitung. In manchen Einsatzszenarien, z.B. einer Slippy Map mit Ereignissteuerung, lässt es sich aber nur schwer Client-seitig vollständig verhindern. Daher behält der Server bei mehreren parallelen Anfragen alle weiteren Anfragen für bis zu 15 Sekunden im Wartezustand und beendet sie erst dann, wenn bis dahin durchgehend Anfragen von der gleichen IP-Adresse diese Abfrage blockieren, sonst werden diese Anfragen nacheinander abgearbeitet. Der zweite große Komplex sind Areas. Um Ärger mit nicht orientierten-Wegen und mehr oder weniger falschen Relationen-Rollen gleich im Ansatz zu vermeiden, benutzt die Overpass API ein sehr einfaches Flächen-Modell - der Südpol ist außen - alle übrigen Punkte sind genau dann innen, wenn sie vom Südpol durch eine ungerade Zahl Kanten getrennt sind - Area-Beschreibungen, bei denen in irgendeinem Punkt eine ungerade Zahl Kanten zusammenkommt, werden als ungültig verworfen. Das führt nur dann zu einem Fehler, wenn Gebiete hinzugefügt werden, die den Südpol umschließen; bei diesen verwendet der Algorithmus irrtümlich den Rest der Erdkugel statt des beabsichtigen Gebiets als inneres Gebiet, und jede Area-Abfrage ist dann mehr oder weniger relevant für dieses Gebiet. Das ist nicht passiert bis http://overpass-turbo.eu/s/1T6 bzw. http://overpass-turbo.eu/s/1T5 Provisorisch nehme ich Gebiete mit admin_level=2 aus der Area-Erzeugung heraus. Danach gilt es, den Fehler in der Software zu beseitigen. Das wird mit der nächsten Version v0.7.50 passieren und leitet über zum dritten Ereignis: v0.7.50 hat eine deutlich andere Datenbank-Struktur, um einerseits Abfragen mit großen Bounding-Boxen zu beschleunigen, andererseits alte Datenbestände abfragen zu können und so z.B. bequem beliebige Undo- Operationen ausführen oder Änderungen verfolgen zu können. Intern verringert es drastisch den Aufwand, Änderungen nachzuverfolgen, was bisher mit den Augmented Diffs, die in Echtzeit erzeugt werden müssen, sehr mühsam ist. Augmented Diffs werden dann zur Abfragezeit für den exakt passenden Zeitraum erzeugt statt in Echtzeit jede Minute. Dafür berechne ich gerade die notwendige Datenbank neu und verarbeite dafür alle Daten seit dem Lizenzwechsel im September 2012. Da das mit niedrigster Priorität passiert, wird es voraussichtlich einen Monat bis Ende Januar dauern, die 1,5 Jahre Änderungen zu durchlaufen. Theoretisch darf sich diese Neuberechnung nicht auf die laufende Datenbank auswirken. Praktisch lässt sich nicht ausschließen, dass nicht allein das oben geschilderte Große-Map-Exporte-Phänomen die Last auslöst, sondern auch die neue Datenbank. In jedem Fall ist daher ab Ende Januar mit einer generellen Verbesserung zu rechnen, und spätestens schon Silvester sollte das Problem mit der Area- Neuberechnung keine Last mehr verursachen. Ich werde versuchen, einen Blogbeitrag auf blog.openstreetmap.de zu verfassen, wenn die aktuellen Area-Probleme geklärt sind. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)
80% des Aufwands, den ich im Moment in der Reparatur von Busrouten habe, besteht darin, den Anfangspunkt zu finden, wenn einige Mapper das Ding durcheinander gewürfelt haben. Das Public-Transport-Plugin kann Routen automatisch sortieren und umdrehen, wenn sie genau falsch herum sortiert sind. Die forward/backward-Rollen sind allerdings für eine eindeutige Sortierung notwendig, vor allem, wenn eine Buslinie z.B. in einem Busbahnhof einen kreisförmigen Weg befährt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gzip von der Overpass API
Guten abend zusammen, die Overpass API liefert Inhalte jetzt standardmäßig mit Gzip komprimiert aus. Das verbessert in der Regel die Übertragungsgeschwindigkeit, ist standardkonform und hat bei Tests keine Schwierigkeiten gezeigt. Sollte es wider Erwarten doch Schwierigkeiten geben, die seit heute etwa 20h auftreten, bitte ich um eine kurze Nachricht per eMail an mich, damit ich das Problem untersuchen kann. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stolpersteine Elternrelation gelöscht?
Hallo zusammen, persönlich würde ich zum Editieren in JOSM empfehlen, eine Hintergrundkarte, z.B. die OSM-Karte einzuschalten und dann mit dem mirrored_download-Plugin unter dem Menüpunkt Datei Mittels Overpass-API laden im Dialogfenster [timeout:180];node[memorial:type=stolperstein];out meta; eingeben und den Bereich der Wahl im Auswahlfenster wählen. Für eine Bounding- Box in der Größe von Köln dauert der Download etwa 7 Sekunden, und JOSM reagiert dank kleiner Objektzahl sehr flott. Außerdem kann ich sehr die Dorstener Lösung empfehlen: http://wiki.openstreetmap.org/wiki/Dorsten#.C3.9Cbersichtskarten Dort wird ohne Gebrauch irgendwelcher Relationen aus einem Wiki-Template eine Übersichtskarte generiert. Kurz noch ein paar Zahlen zu dem Thema: http://api.openstreetmap.org/api/0.6/relation/407359/full braucht 3-5 Sekunden (je nach Cache-Zustand), findet aber neben mehreren Relationen auch nur 3 Stolpersteine. Das exakte Äquivalent dazu ist: http://overpass-api.de/api/interpreter?data=(rel(407359);rel(r)- .a;node(r););out meta; braucht etwa 3-7 Sekunden (je nach Cache-Zustand) Mit der Abfrage, die auch alle indirekten Referenzen verfolgt: http://overpass-api.de/api/interpreter?data=(rel(407359);;);out meta; findet man 7572 Stolpersteine in 60-80 Sekunden. Mit der Abfrage, die alle Stolpersteine sucht: http://overpass- api.de/api/interpreter?data=node[memorial:type=stolperstein];out meta; findet man 10753 Stolpersteine in 60-90 Sekunden. Relationen über mehrere Relationen-Level aufzulösen ist meines Erachtens mit der Main API nicht möglich. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stolpersteine Elternrelation gelöscht?
Hallo, Außerdem dachte ich bisher bei 4 Knoten, die gemeinsamen Daten wie Künstler, übergeordnete Website wäre vorteilhafter in der Relation. Nein. Mindestens die Main API, komprimiertes XML, PBF und auch die OVerpass API ersetzen Strings intern durch Referenzen auf Strings, d.h. sie speichern jeden String nur einmal. Das deckt aber auch schon so ziemlich alles ab. Zum groben Vergleich: schreibt man 1000 Nodes mit dem gleichen Tag in eine .osm.gz-Datei, so braucht das nur etwa halb so viel Platz (unter 3 KB) wie 1000 Nodes ohne Tag und mit dem Tag einmalig an der Relation (knapp über 6 KB). Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM: Chateaus in Bordeaux gesucht
Hallo zusammen, ich suche die Chateau-Standorte der berühmten Bordeaux-Erzeuger · Als Punkte die Chateaus · Als Polygone die den Chateaus zugeordneten Weinberge/-hänge/-hügel (Kataster-Polys (entspricht ALK?) gibt es ja, aber ohne die Namen (entspricht ALB?)) Gibt's so was schon bei OSM (oder woanders) , wenn nicht wie kann man es erfassen (tags?). Gibt es datenschutzrechtliche Probleme? Als Anhaltspunkt benannte Weinberge rund um Bordeaux: http://overpass-turbo.eu/s/1Fo Chateaus selbst habe ich keine erfasst gefunden. Die vorhandenen Gebäude sind in der Regel schlicht aus dem Import, ohne spezifische Tags. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sketch-line
Hallo, ich versuche gerade eine Buslinie in Bremen so nach dem neuen ÖPNV Schema zu taggen, dass auch Sketch-Line damit funktioniert. Allerdings funktioniert das nicht alles so wie es soll. Seht es euch selbst an: http://www.overpass-api.de/api/sketch-line?ref=22network=VBN http://www.overpass-api.de/api/sketch-line?ref=22network=VBNstyle=wupperta l Das Problem ist, dass fast alle Haltestellen doppelt dargestellt werden. Solche wo auch eine Straßenbahn am gleichen Steig hält, werden korrekt dargestellt (Kurfürstenallee, Crüsemannallee, Busestraße, Universität / Zentralbereich). Das neue Public-Transport-Schema ist eines der prominentesten Beispiel für ein großflächig gescheitertes Wiki-Proposal. Leider gibt es nun sehr viele Varianten für das Tagging statt vorher nur einer, und etliche Mapper bestehen darauf, dass ihr Ansatz die einzige Wahrheit sei. Die Varianten sind untereinander widersprüchlich, so dass keine sinnvolle Auswertung mehr möglich ist. Ich habe daher Sketch-Line nicht mehr weiterentwickelt. Sketch-Line arbeitet zuverlässig mit highway=bus_stop und public_transport=platform zusammen. stop_position wird ab irgendwann wieder komplett ignoriert werden. Es ist ohenhin nicht flächendeckend verfügbar. Ich würde empfehlen, - Nodes als Haltestellen mit highway=bus_stop und public_transport=platform und Namen zu taggen - Ways als Haltestellen mit public_transport=platform und Namen zu taggen - diese Elemente und nur diese Element mit der Rolle stop in Reihenfolge der Bedienung in die Linie einzufügen - mit den Rollen forward und backward die Wege des befahrenen Linienwegs aufzubauen Sketch-Line sollte dann korrekt funktionieren, verbleibende Fehler korrigiere ich gerne. Erfahrungsgemäß gibt es auch selten bis nie Widerspruch, wenn man so mappt. stop_position war ursprünglich der Sonderwunsch einer der treibenden User hinter dem Proposal. Derjenige hat es aber auch nach nun mehreren Jahren nicht hinbekommen, ein funktionierendes Stück Software zur Auswertung zu schreiben. Generell würde ich obiges auch als offizielle Vereinfachung im Wiki unterbringen, um endlich wieder funktionsfähige Software zu haben. Das muss aber hinter der dringenderen Weiterentwicklung der Overpass API leider zurückstehen, weil Wiki-Diskussion unvermeidlich sehr zeitraubend sind. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gelöschte Linien finden und wieder herstellen
ein Server, der die gesamte Historie von OSM enthält und den Download der Daten eines (kleinen) Gebiets zu einem wählbaren Datum erlaubt, wäre für solche Probleme sehr nützlich. Damit könnte man auch die zeitliche Entwicklung eines Gebiets oder die Veränderungen durch ein Changeset visualisieren. Gibt es Überlegungen, so etwas einzurichten? Ich arbeite gerade daran, die Overpass API auch auf die Vergangenheit auszudehnen. Wird avoraussichtlich bis Weihnachten dauern. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ankündigung: Popup-Layer auf osm.org aufgefrischt
Hallo Tobias, Bei dir ist das ziemlich analytisch umgesetzt: Man bekommt viele Einträge in einer Liste präsentiert und kann sich die Rohdaten anschauen - eher versteckt sogar auch eine halbwegs übersetzte Form. In einer benutzerorientierten Web-Karte würde ich in einem Pop-Up aber ansprechend gestaltete Informationen über (idealerweise) genau ein Objekt erwarten.ass Nun, das ganze Feature ist Mapper-orientert. Wir können keine Karte bieten, in der alles angezeigt wird, was sinnvoll gemappt werden kann, weil dafür keine bekannte Gestaltung mehr existiert. Das ist, wo ich eigentlich hin möchte: Ein Mapper soll Rückmeldung bekommen, dass sein Objekt nicht nur als XML angekommen ist, sondern eine semantische Interpretation besitzt. Die Ein-Objekt-Regel halte ich gerade im Hinblick auf Touch-Oberflächen für problematisch. Bei Objekten, die im Extremfall weniger als ein Meter auseinanderliegen (Bushaltestelle auf der Brücke), ist wiederholtes Zoomen, Neu-Pannen, Zoomen, Neu-Pannen, bis man mal das richtige Objekt trifft, für meine Bediengewohnheiten ein großer Umweg. Die zweite Alternative sind Cluster, die aber ziemlich erklärbedürftig werden, wenn sehr verschiedene Objekte (Nodes mit Wegen, Bushaltestellen und Flüsse) miteinander geclustert werden. Alles anzuzeigen, war dann einfach semantisch einfacher: Jedes erkannte Objekt liegt dann nur einen Klick entfernt (wenn man weit genug gezoomt hat, um nicht mehr seitenweise Objekte zu bekommen). * Regionen/Grenzen wie Nordrhein-Westfalen weglassen, denn dafür gibt es schon das Wo bin ich?-Feature - und sie blähen die Liste auf Die verstopfen in der Tat das Popup. Andererseits habe ich das Wo bin ich?- Feature wiederholt nicht gefunden. Show my location schickt mich an meine Adresse, ohne sie mir zu nennen. Daher neige ich momentan dazu, der Empfehlung unseres lokalen Stammtisches zu folgen und alle Areas unter einer Überschrift zusammenzufassen. Das rettet viel von der Übersichtlichkeit. * falls praktikabel zoomstufen-abhängig arbeiten: kleine Gedenktafeln etc. waren vom Benutzer in deiner Beispielansicht sicher nicht gemeint Die Praktikabilität scheitert da vorwiegend daran, dass ich dann auch zu jeder Objektklasse vorgeben müsste, in welchen Zoomstufen sie auftaucht. Nachdem die Erfahrungen mit der Rückmeldung zur Objektklassifizierung sehr gut gewesen sind, werde ich es versuchen, da auch um Unterstützung zu fragen. * Einzelobjekt-Ansicht bieten statt nur den aufklappbaren Listeneintrag Was genau heißt hier Einzelobjekt-Ansicht? * in der Liste [details][tags] weglassen und ersetzen durch einen Link zur osm.org-Details-Seite in der o.g. Einzelobjekt-Ansicht Da sehe ich noch keinen Vorteil: Man entfernt ein nützliches Feature. Was gewinnt man dadurch? Die Tag-Ansicht ist wesentlich leichtgewichtiger als ein neuer Tab mit der OSM-Objektansicht (die ja trotzdem erreichbar ist), und für die [details]-Ansicht gibt es kein Äquivalent: hier wird ja gerade gezeigt, wie das Tag interpretiert wird. Generell denke ich, dass es gerade für komplexere Mapping-Themen wichtig wird, eine Debug-Ansicht zu haben, damit man nachverfolgen kann, warum ein konkretes Tagging sich anders auf die Datenkonsumenten auswirkt als erwartet. Allgemeiner bräuchten wir also Mechanismen, um * für bestimmte Objektklassen Zoombegrenzungen vorzugeben * für bestimmte Objektklassen (Boundaries) Oberbegriffe einzuführen, unter denen alle Objekte zusammengefasst werden Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ankündigung: Popup-Layer auf osm.org aufgefrischt
Hallo Peda, Kannst du daher vielleicht nochmal etwas grundsätzlicher erklären, was du da konkret vorhast? Gerne. Es geht darum, einem Mapper ein Feedback der Eintrag ist angekommen und auswertbar zu geben. Das ist fürs Mappen wichtig, aber von einer vorgerenderten Karte nicht leistbar. Natürlich kann man darüber streiten, ob man dafür den Linksklick der Maus belegen will. Es gibt einige andere Ansätze für Popup-Mechanismen, die für eine Konsumenten-Karte sehr reizvoll sind, aber osm.org stellt Mapper und nicht reine Konsumenten in den Mittelpunkt. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ankündigung: Popup-Layer auf osm.org aufgefrischt
Hallo Tim, Aus den boundary Informationen könnte man ja noch einen Baum derart stricken: Deutschland/NRW/Köln/Innenstadt. Ich würde das aber eher verstecken oder zumindest anders formatieren. Ich würde das auch gerne als Baum darstellen, habe aber die Informationen über die Hierarchie nicht so ohne weiteres. Ich denke, ich werde es erst einmal in einer Kategorie zusammenfassen. Komischer Weise ist es mir nicht gelungen, die Toilette neben dem Dom abzufragen. Woran liegt das? Die Toilette hat keinen Namen. Der Versuch, alle Objekte mit Tags aber ohne Namen als [unnamed] aufzulisten, hat das Popup selbst auf hohen Zoomstufen im Testgebiet, der Innenstadt von Bonn, mit Einträgen überflutet. Wenn wir mit dem Punkt Zoostufen für Objektarten definieren weiterkommen, kann man das wieder in Angriff nehmen. Nebenbei: Vielleicht sollte man statt Zoomstufen lieber Prioritäten setzen und danach sortieren, da sonst die Verwirrung über abwesende Objekte zu groß ist. Dass Objekte in der Auflistung nach hinten rutschen können, ist glaube ich eher intuitiv als vorgegebene Zoomstufen (Achtung: Fixe Zoomstufen für Objektklassen sind Teil jeder Rendering-Strategie, aber wir wollen ja gerade die Schwächen eines graphisch sinnvollen Renderings ausgleichen). Auch wenn das Objekt im oberen Bildteil liegt, sollte das Popup vollständig auf dem Bildschirm erscheinen, und nicht oben raus schießen. Ja, richtig. Habe ich im Moment keine Lösung für. Möglichkeit 1: kein Popup anzeigen. Stiftet Verwirrung, wenn Popups manchmal funktionieren, manchmal aber auch nicht. Möglichkeit 2: Unaufgefordert die Karte zentrieren. Ist auch nicht so nett. Ein ähnliches Problem exisitert für Objekte mit vielen Tags: die können auch das Popup maßlos verlängern. Da neige ich momentan am ehesten dazu, die Anzahl der angezeigten Tags zu begrenzen und Nutzer auf die Element-Seite zu verweisen. Der Id-Editor übersetzt die Tags ja mittlerweile ins Deutsche, sodass ich schrecklicher Weise noch nicht mal an die Original-Tags ran komme. Für den Popup-Layer könnte so eine Übersetzung aber ggf. sinnvoll sein. Je nachdem ob, wir Leuten nützliche Informationen liefern wollen oder aber den Leuten unser Key-Value-Schema lernen lassen wollen. Ehrlich gesagt würde ich das sehr gerne. Ich habe aber weder verstanden, wie man die Lokalisierung in JavaScript Assets innerhalb des Rails-Port richtig macht, noch, wie ich in JavaScript herausbekommen kann, welche Lokalisierung der Benutzer eingestellt hat. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ankündigung: Popup-Layer auf osm.org aufgefrischt
Schick wäre, wenn Du Öffnungszeiten auch direkt in die Details aufnehmen könntest, das dürfte eines der meistgesuchten Infos bei Geschäften sein, wenn man auf die Karte klickt. Danke. Das kommt auf die Aufgabenliste. Gibt es bereits irgendwo Referenzcode, der die Notation in allen Fällen sinnvoll dekodiert? Ich würde mich gerne um die Sonderfallanalyse herumdrücken. :) Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ankündigung: Popup-Layer auf osm.org aufgefrischt
Liebe Mitmapper, Die Popup-Erweiterung für die Website osm.org habe ich gerade grundlegend überarbeitet und dabei die Rückmeldungen der letzten Version in neue Funktionalität umgesetzt. Per Beispiel: http://overpass.apis.dev.openstreetmap.org/#map=15/50.9429/6.9541 Bitte klicke auf das graue Gebäude ziemlich in der Mitte neben der Bahnstrecke (es ist der Kölner Dom). Ein blaues Rechteck und ein Popup erscheint: Im Popup werden alle benannenten OSM-Elemente aufgelistet, die in der blauen Box liegen. Bitte klicke neben Kölner Dom auf [details]: * [wikipedia] kommt aus dem Tag wikipedia * [website] kommt aus dem Tag website * die Adresse kommt aus den diversen addr:*-Tags * die Liste der Übersetzungen aus den name:*-Tags Möchte man das OSM-Element zum Kölner Dom im Detail untersuchen, so führt der Klick auf den Namen auf die Webseite zum OSM-Element. Objekte mit gleichen Tags werden zusammengefasst und sind dann mit Ziffern ab [2] klickbar. Z.B. auf Seite [2] die Elemente zur Trankgasse. Worum ich bitten würde: Viele Objekte tauchen hier noch als Other object auf. Das liegt daran, dass sie nicht in der Liste https://github.com/drolbr/openstreetmap- website/blob/master/app/assets/javascripts/tagprocessor.js stehen. Wenn Ihr eine Kategorie habt, so tragt sie bitte unter http://wiki.openstreetmap.org/wiki/DE:POI_display ein. Wenn jemand weiß, wie man die Lokalisierung richtig (d.h. entweder aus der Rails-Plattform heraus oder Browser-neutral) hinbekommt, wäre ich für Tipps auch dankbar. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSMF-Vorstandswahl
Hallo Frederik, Wenn jemand ueberlegt, ob das was fuer ihn/sie ist, beantworte ich Fragen zur Vorstandsarbeit gern auch per Mail. Nur mal der Neugierde halber. Mit wieviel Aufwand an - regelmäßigen Fernkonferenzen (Frequenz, Terminlage, Dauer, Medium)? - Reiseaktivität - sonstigem finanziellen Aufwand ist für ein Board-Mitglied zu rechnen? Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Berliner Gespräche zur Digitalen Kunstgeschichte
Hallo Liste, die Veranstalter der Berliner Gespräche zur Digitalen Kunstgeschichte würden bei einer ihrer Veranstaltungen gerne jemanden von OSM dabei haben, der etwas zum Thema erzählen mag - idealerweise jemanden mit kulturgeographischem Hintergrund. Zur Veranstaltung ein paar Worte der Organisatoren: --- Es handelt sich dabei um eine Gesprächsreihe, die verschiedene Projekte aus dem Bereich der Digitalen Kunstgeschichte einlädt. Wichtig ist uns dabei vor allem ein Austausch und eine Diskussion über digitale Technologien in der Kunstgeschichte an der Schnittstelle von technischen, konzeptionellen und fachlichen Fragen. Beim nächsten Termin am 18. November 2013 wird es um Geosyteme gehen, Titel des Workshops lautet: Kultur in Raum und Zeit - Spatiotemporale Dokumentation. Bisher haben wir in das Programm vor allem Sprecherinnen und Sprecher aufgenommen, die aus dem Blickwinkel der Architektur, Kunstgeschichte, Denkmalpflege berichten, wie sie in aktuellen Projekte mit digitalen geografischen Systemen arbeiten. Es handelt sich also vor allem um Nutzer und Nutzerinnen dieser Systeme. Nun wäre es sehr interessant, auch jemanden an Bord zu holen, der oder die aus der Sicht der Geosysteme berichtet. Es würde uns sehr freuen, wenn jemand aus dem Kreis von OpenStreetMap Interesse hätte, an den Gesprächen teilzunehmen. Gerade, falls jemand sich besonders für kulturgeografische Fragestellungen interessiert, oder sich mit diesen sogar professionell beschäftigt, wäre die Teilnahme an den BGDK sicher bereichernd. Schön wäre es, wenn der oder die Interessierte einen ca. 15-minütigen Vortrag (wenn gewünscht mit PPP) darüber halten könnte, wie OpenStreetMap in der kulturhistorischen Forschung genutzt werden kann, ob es Bestrebungen gibt, solche Zusammenarbeit auszubauen etc. - das Konzept ist also noch sehr offen und wir freuen uns auch über eigene Vorschläge. [...] Kurztext zur Veranstaltung: Die räumliche Zuordnung stellt für die Kunstgeschichte und andere objektbezogene Disziplinen eine grundlegende Kategorie dar. Raum- und ortsbezogene Betrachtung von Kunst hat eine lange Traditon sowohl hinsichtlich ihrer Wissenskonzepte (Kunstlandschaften) als auch hinsichtlich ihrer historischen Literaturgattungen (Guiden, Stadt- und Länderbeschreibungen, Denkmaltopographie). Die traditionellen Dokumentations- und Vermittlungsmedien (gedruckte Publikationen, allenfalls Karten und Stadtmodelle) erlaubten jedoch nur eine sehr eingeschränkte Wiedergabe der räumlichen Aspekte der Kunstgeschichte. Auch in der Dokumentation und Beschreibung von Kunst und Kultur konnten zwar Karten und Modelle eingesetzt werden, jedoch waren der Verbindung untereinander oder mit weiteren Bildmedien und sonstigen Daten enge Grenzen gesetzt. Durch die Möglichkeiten der digitalen Dokumentation kann der Raum – ebenso wie die Zeit – in unvergleichlich größerem Umfang wiedergegeben werden. Die Diskussion aktueller Standards, Konzepte, Systeme und Projekte soll neue Erkenntnisse bringen und Kooperationen den Weg bereiten. --- Falls jemand Interesse hat dort mitzumachen, kann er sich bei mir melden. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umgang mit Proposals
Hi, noch eine viel einfachere Vorgehensweise: Wenn nicht innerhalb von 30 Tagen zu einem Proposal 25% der Wiki-Account-Inhaber geäußert haben, wird das Proposal in den Zustand Not Relevant versetzt und stattdessen die vorhandenen Stile beim Mappen dokumentiert. Das erlaubt, die wichtigen von den unwichtigen Proposals zu unterscheiden. Und es wertet tatsächliches Mappen höher als unerprobte Konzepte und Geschäftsordnungsdebatten. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autokennzeichen
Hallo, für Nominatim hat jemand den Featurewunsch geäussert, dass es doch die Suche nach deutschen Autokennzeichen unterstützen möge. Finde ich jetzt keine schlechte Idee, weil die Kennzeichen ja im Prinzip als ref für die Kreise dienen. Berlin macht das bereits so, mit dem Erfolg, dass jetzt solche Suchergebnisse herauskommen: http://nominatim.osm.org/search.php?q=berlinaccept-language=xx Sämtliche Bundesländer (und auch die in Italien) tragen solche Abkürzungen. Genauer: Beim Sichten der Einträge in Admin-Level 4 und 6 hat sich herausgestellt, dass da bis auf je eine Relation immer Abkürzungen drinstehen. Bisher wurde short_name eigentlich eher da verwendet, wo eine kürzere aber immernoch lesbare Version des Namens gebräuchlich ist. Was ist mit NRW? Die Frage: Wo liegt NRW? würde ein Großteil der Bevölkerung mit dem Verweis auf Nordrhein-Westfalen beantworten. Dass Wo liegt B? weniger gängig ist, wäre ich bereit zu glauben. Man macht da allerdings ein sehr subjektives Fass auf. Verwiesen sei auf M'gladbach, was recht gebräuchlich ist für Mönchengladbach, im Gegensatz zum selteneren und eher missbilligten D'dorf und W'tal. Gängig, auch auf Straßenschildern, sind hier z.B. K-Ehrenfeld W-Elberfeld BN-Auerberg MS-Hiltrup Ich würde es für einen Gewinn halten, wenn diese Strings auf die entsprechenden Stadtteile auflösen, aber sehe jetzt auch keine sinnvolle Verallgemeinerung auf außerhalb Deutschlands. Wenn man so ansetzt, wäre eben auch Tdf-Spich legitim (Tdf ist kein Autokennzeichen), und Kreiskennzeichen verweisen dann eher auf die Kreisstadt als auf den Gesamtkreis. Also: Rothenburg ob der Tauber - Rothenburg Auch auf admin_level=8 kommt short_name in dieser Verwendung nur selten (weniger als 10 mal) vor. Ich hielte es dann für das aussichtsreichste, ref gleichwertig zu unterstützen und dann alle Vorkommen von short_name zu sichten und in der Regel zu entfernen. Casper-David-Friedrich-Strasse - CD-Friedrich-Strasse Deshalb zieht Nominatim das short_name-Tag dem name-Tag bei der Anzeige vor. Wenn short_name mit Kürzeln gefüllt wird, ist das leider nicht mehr möglich. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autokennzeichen
Hallo Sarah, für Nominatim hat jemand den Featurewunsch geäussert, dass es doch die Suche nach deutschen Autokennzeichen unterstützen möge. Finde ich jetzt keine schlechte Idee, weil die Kennzeichen ja im Prinzip als ref für die Kreise dienen. Dieses Tag finde ich weniger unterstützenswert, weil es a) von einem speziellen Import stammt und damit spezifisch nur für die deutschsprachige Region gilt, Außerdem der deutschsprachigen Region haben die Autokennzeichen oft keinen geographischen Bezug. Beispiele sind die NL (gar kein Bezug) oder Frankreich (letzte 2 Ziffern gleich Departement, sonst kein Bezug). Das globale Äquivalent dürfte allgemein eine Abkürzung des Städtenamens sein. short_name hat immerhin über 11000 Verwendungen, davon bereits 120 auf Relationen mit admin_level=6. Ich denke, das sinnvollste wäre, das zu verwenden und die deutsche Community aufzufordern, das Autokennzeichen, das ja als Abkürzung dient, dort einzutragen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Nur ausgewählte Objekte editieren
Hallo zusammen, wie versprochen nun auch die Anwendung für das Global-Bbox-Feature der Overpass API v0.7.4: Editieren nur ausgewählter Objekte: http://wiki.openstreetmap.org/wiki/DE:Overpass_API/Beispielsammlung#Ausgew.C3.A4hlte_Datenkategorien_editieren So könnte man z.B. alle Shops in Bonn darauf überprüfen, inwiefern sie ein wheelmap-Tag tragen. Grundsätzlich hat das Global-Bbox-Feature, siehe http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Global_Bbox zwei Effekte: - Die angegebene Bounding Box wird auf alle Teilabfragen angewendet - Die Werte aus der Bounding Box werden im Element embounds/em in der Antwort mit angegeben. So sind z.B. die beiden Abfragen ( way[shop=supermarket](50.6,7.0,50.8,7.3); ; node[shop=supermarket](50.6,7.0,50.8,7.3);); out; und [bbox:50.6,7.0,50.8,7.3]; ( way[shop=supermarket]; ; node[shop=supermarket];); out; gleich. Es erlaubt, ohne Verrenkungen Bouding Boxen aus vielen Quellen, z.B. Slippy Maps mit OpenLayers oder eben JOSM zu verwenden ohne sie explizit angeben zu müssen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass API 0.7.4: Differenz-Operator
Der Differenz-Operator ist eine sinnvolle Erweiterung. Nur bin ich mit der Benennung nicht so glücklich - wie mit anderen Syntax-Elementen ja auch/nicht (wie namentlich print und recurse). [...] Difference ist mir zu nahe an Intersect. Natürlich muss die Overpass API nicht SQL übernehmen, doch gibt SQL eine schöne theoretische Basis her (z.B. dass ein weiterer Operator INTERSECT heissen könnte :-). Ich schlage daher vor, lieber vom EXCEPT Operator/Statement zu sprechen. Was meinst du dazu? Namen sind Schall und Rauch, und ich bin grundsätzlich offen für eine systematische Umbenenneung. Bisher haben die Statements ihre Namen von C++ bezogen (und dort heißt es in der sTL set_union, set_intersection und set_difference. Die Benennung von recurse (besser wäre traverse, follow- link oder einfach follow) ist ebenso wie die sorgsam wieder vermiedene Bezeichnung clause (besser wohl conditional) dagegen ein Betriebsunfall, mit dem ich auch nicht glücklich bin. Generell ergäbe es durchaus Sinn, sich eher an SQL zu orientieren, da vermutlich mehr Datennutzer mit SQL als mit fortgeschrittenem C++ vertraut sind. Das gibt aber insgesamt nochmal einen neuen Dialekt, so dass ich die Idee notieren würde, wenn für eine sehr viel spätere Version 1.0 eine Generalüberholung der Sprache ansteht. Andere leidige Themen sind z.B. die Reihenfolgen Lat-Lon versus Lon-Lat oder die Frage, wo genau ein Semikolon stehen muss oder darf. Vermutlich gibt es weitere solche Punkte. Es sind aber auch Themen, die endlos viel Zeit vereinnahmen können, so dass ich in den nächsten Monaten erst einmal noch fehlende Funktionalität nachrüsten möchte und Syntax-Diskussionen zurückstelle. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Overpass API 0.7.4: Differenz-Operator
Liebe Mitmapper, eine neue Version der Overpass API, Version 0.7.4 steht auf http://overpass-api.de zur Verfügung. Auf der Rambler-Instanz folgt das Update in den nächsten Tagen. Neben zahlreichen behobenen Bugs ist vor allem die Abfrage nach Ways und damit auch Relationen in kleinen Bounding-Boxen effizienter geworden. Damit sollte sich mit dem POI-Overlay-Prototyp http://overpass.apis.dev.openstreetmap.org/ jetzt zügig arbeiten lassen. An Erweiterungen der Syntax gibt es zwei: Zum einen global deklarierte Bounding-Boxen; diese werde ich morgen genauer erläutern, wenn das korrespondierende JOSM-Plugin mirrored_download sich aktualisiert hat. Zum anderen der Differenz-Operator. Er dient dazu, Suchen der Art alle Objekte die X haben/sind, aber nicht Y haben/sind zu finden. Zum Beispiel hier alle Nodes, die einen Wert für maxheight gesetzt haben, aber nicht Teil einer Straße (d.h. eines ways mit Tag highway) sind: http://overpass-turbo.eu/s/I6 // Neu in Overpass 0.7.4: Der Differenz-Operator [bbox:50.6,7.0,50.8,7.3]; ( node[maxheight]; // Alle Nodes mit irgendeinem Wert für maxheight - (way[highway];;); // die nicht auf irgendeiner Form von Straße liegen ); out; Für den besonders häufigen Fall, dass es um hat Tag X, aber nicht Tag Y geht, empfehle ich weiterhin die bekannte Syntax mit [...!~...]. Diese arbeitet effizienter als der Differenzoperator es kann. http://overpass-turbo.eu/s/I8 // Neu in Overpass 0.7.4: Der Differenz-Operator // // Wenn es bloß um nicht gesetzte Tags geht, sollten diese lieber // als Bedingung aufgelistet werden und nicht als Differenz-Operator. // Das funktioniert schneller [bbox:50.7,7.0,50.75,7.1]; ( way[highway=residential][name!~'.']; // Ways mit Tag highway, aber ohne Tag name. ; ); out; Alle Details zur neuen Version gibt es im Wiki: http://wiki.openstreetmap.org/wiki/Overpass_API/versions Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?
Aha. Eine gute Gelegenheit mal zu testen, wieviel Datenschutz das kastrierte Planet-File bringen könnte. Sicher feststellen wird man es natuerlich nicht koennen ob die Person nun tatsaechlich vor Ort war oder nicht, aber man kann es haeufig durchaus einschraenken. Zum Beispiel kann man analysieren ob alles was man gemappt hat Sachen sind die man von Satelitten gemappt werden koennen, oder ob man eben doch lokales Wissen benoetigt. Mit Verwendung eines Urlaubs-Accounts hat sich das sofort erledigt. Egal, was noch auf welchem Wege herauszubekommen ist. Oder, man verknuepft das ganze mit mailing list (Foren posts) und stellt fest das diese Person z.B. ueberwiegend morgens und abends postet. Nun, in der Zeit wo die edits ausserhalb der Heimat waren, hat sich dieses Verhalten ploetzlich veraendert. Die Mail-Adressen in der Mailingliste werden nicht verschwinden, egal was mit dem Planet-File passiert. Gut. Das eine Szenario wird also besser mit anderen Werkzeugen gelöst. Das andere Szenario wird gar nicht durch Änderungen am Planet gelöst. Es werden also durch den Vorschlag zwei Probleme nicht gelöst, aber neue Probleme geschaffen. Sollte man nicht besser erleichtern, einen Zweit-Account anzulegen? Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?
Allgemein: Die Gegner des gegenwärtigen Umgangs von OSM mit Daten möchten bitte allmählich darstellen, wie sie sich den zukünftigen Umgang vorstellen würden. Daten, von denen auf einen Useraccount geschlossen werden können, aus dem Planet raus, und nicht über die API abrufbar machen. Frederik hat freundlicherweise daran erinnert, warum OSM auf das gegenteilige Vorgehen gewechselt hat. Zur Erinnerung: http://lists.openstreetmap.org/pipermail/talk/2007-October/018853.html Seitdem sind zahlreiche Vandalismusfälle und ähnliches anhand der Zuordnung von Edits zu Benutzeraccounts gelöst worden. Und das ist eine Maßnahme, um für die Mapper nachvollziehbar zu machen, dass ihre Edits weder willkürlich entfernt noch durch Vandalismus gefährdet sind. Ich sehe keine Möglichkeit, das ohne die Zuordnung zu leisten. Keine Option ist ein schlecht legitimiertes Datenschutz-Gremium, das unter anderem diese Daten und eventuelle Sonderrechte als Machtmittel missbraucht. Es sei denn, man möchte sich eine vermeintliche Machtposition schaffen. Sehr wohl ist es aber eine Option, auf Basis des Planet-Files eine eigene Datenbank zu betreiben, dort anonyme Edits entgegenzunehmen und nur die anonymisierten Planet-Daten wieder zu veröffentlichen. Die ODbL erlaubt das. Es ist allerdings ein anderes Projekt als OSM, und es wäre nur fair, niemanden dort hinzuzwingen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass API: Gegeben id/name gesucht Area: Wie?
Hallo zusammen, 1. http://overpass-turbo.eu/?template=type-idtype=relationid=2135966R 2. In overpass-turbo einfach unter Export-als GeoJSON auswählen. Den Weg über Overpass Turbo würde ich ebenfalls empfehlen. Das ließe sich im Prinzip sogar automatisieren, wenn man das nötige JavaScript client-seitig ausführt. Ein XML-basiertes Polygonformat gibt es im OSM-Umfeld meines Wissens nicht, weswegen ich auch ungerne eines neu einführen würde. Die direkte Konvertierung in GeoJSON bietet die Overpass API zur Zeit nicht an. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Export der Postleitzahlen-Gebiete
Hallo, 1) Weiß jemand, ob z.B. die 22767 nicht erfasst ist, oder ob ich sie nur nicht finde? Weil die 22767 so einen zentralen Bereich in Hamburg abdeckt, könnte ich mir vorstellen, dass die Relation irgendwo in OSM existiert aber anders getagged ist. Ich habe versucht sie über Overpass-Queries zu finden. Und ich habe die Nachbar-PLZ-Gebiete in overpass-turbo angezeigt und versucht, über die Grenz-Ways angrenzende Postal-Code-Relationen zu finden. Leider ohne Erfolg. Ich habe aber auch, wie gesagt, keine große Erfahrung, wie ich geschickt in OSM suche. Kann mir jemand einen Tip geben, wie ich suchen muss, um z.B. die 22767 zu finden? Das wäre super. Wenn das Postleitzahlengebiet auf ungewöhnliche Weise gemappt ist, sollte es auf jeden Fall zusätzlich auch auf üblichem Wege gemappt werden. In OSM ist Redundanz kein Mangel, sondern hilfreich, im Gegensatz zu vielen anderen Datenbankkonzepten. Es gibt gelegentlich verschiedene Sichtweisen auf die gleichen Objekte, z.B. ob eine Hausnummer eher zu einem Eingang oder zu einem Gebäude gehört. So kann man beides dokumentieren. Es erleichtert Datennuztern die Arbeit. Und es verbessert die Robustheit bei Fehlern, da man Inkonsistenzen finden kann, fehlen Daten aber nicht. Konkret zu 22767: In einem kompletten Hamburg-Extrakt kommt der String 22767 ausschließlich als Wert der Tags postal_code und addr:postcode vor. Schaut man sich in Overpasas Turbo mit den Abfragen area[name=Hamburg];(way(area)[addr:postcode=22767];;);out; area[name=Hamburg];(way(area)[postal_code=22767];;);out; area[name=Hamburg];(way(area)[addr:postcode=22767];;);out; area[name=Hamburg];(way(area)[postal_code=22767];;);out; die Objekte an, so kann man sehr gut die Umrisse des Bereichs abschätzen (und dann mappen), sieht aber auch, dass es kein Objekt gibt, das die PLZ irgendwie als Fläche erfasst. 2) Das Extrahieren war - zumindest für mich - einige Arbeit. ich nehme an, dass auch andere die Plz-Gebiete in dieser konzentrierten Form gut gebrauchen könnten und würden sie gerne an einer gut auffindbaren Stelle zum Download ablegen. Hat jemand einen Tipp, was eine gut auffindbare Stelle sein könnte? Wo würdet ihr suchen, wenn ihr die PLZ-Gebiete braucht? Generell würde ich im Wiki die Seiten PLZ und Postleitzahl befüllen und mit Querverweisen auf das vorhandene Material versehen (z.B. Key:postal_code). Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenverlust durch Server-outage?
Hallo, Er wird mir im Firefox auf der OSM-Seite angezeigt - siehe Screenshot: http://imgur.com/dk9hpY4 [...] Muss ich die Verbesserungen erneut mappen oder kommt der Stand, wie im Firefox angezeigt, von allein zurück? Siehe http://www.openstreetmap.org/browse/way/220847370 Der Änderungssatz http://www.openstreetmap.org/browse/changeset/16126487 scheint alle Änderungen zu beinhalten. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Stand auf der FROSCON
Hallo Sven, Ich wäre bereit, das in diesem Jahr zu ändern und suche Mitstreiter für den Aufbau eines OSM Standes. Wenn sich noch 2-3 Leute bei mir melden würde ich einen Stand beantragen. Ich habe unsere lokale Community hier in Bonn gefragt, und wir werden es auf dem nächsten Stammtisch besprechen. Ich wäre auf jeden Fall dabei. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Overpass API v0.7.3
Hallo zusammen, es gibt eine neue Version der Overpass API. Die Version korrigiert das Verhalten der area-Anweisung für Relationen: So findet eine Abfrage wie area[name=Wuppertal];rel(area)[postal_code];out; jetzt exakt die Postleitzahlen, die in Wuppertal liegen. Die Abfrage auf Overpass Turbo: http://overpass- turbo.eu/?Q=area%5Bname%3D%22Wuppertal%22%5D%3Brel(area)%5Bpostal_code%5D%3Bout%3B%0A%0A Abfragen für Stadtteile und auf Bundesländern funktionieren entsprechend. Mit der Semanik aus 0.7.2 wäre es dagegen nicht möglich gewesen, die untergeordneten Objekte zu finden. Aber auch das erzeugende Objekt einer Area kann jetzt leichter gefunden werden. Eine Abfrage wie is_in(50.938,6.9515)-.a; ( way(pivot.a)[building]; rel(pivot.a)[building]; ); out meta; findet heraus, dass die Koordinaten (50.938,6.9515) im Opernhaus Köln liegen und liefert auch das dazugehörige Objekt in OSM, so dass man es direkt editieren könnte. Link auf Overpass Turbo: http://overpass- turbo.eu/?Q=is_in(50.938%2C6.9515)-%3E.a%3B%0A(%0A%20%20way(pivot.a)%5Bbuilding%5D%3B%0A%20%20rel(pivot.a)%5Bbuilding%5D%3B%0A)%3B%0Aout%3B%0A Und es lässt sich jetzt nach einzelnen Rollen suchen: rel[ref=636][network=VRS]-.a; ( node(r.a:platform); way(r.a:platform); ; ); out; Damit erhält man zur Buslinie 636 nur die Haltestellen, egal ob es Nodes oder Ways sind (hier nur Nodes). Link: http://overpass- turbo.eu/?Q=rel%5Bref%3D636%5D%5Bnetwork%3DVRS%5D-%3E.a%3B%0A(%0A%20%20node(r.a%3A%22platform%22)%3B%0A%20%20way(r.a%3A%22platform%22)%3B%0A%20%20%3E%3B%0A)%3B%0Aout%3B%0A Außerdem lassen sich Unicode-Zeichen in QL nun doch \u escapen. Mehr zu diesem Thema (auf Englisch): https://developer.mozilla.org/en- US/docs/JavaScript/Guide/Values,_variables,_and_literals#Unicode_escape_sequences Die neue Version ist auf overpass-api.de bereits aktiv und folgt auf overpass.osm.rambler.ru am Freitag, wenn bis dahin keine Fehler auf overpass- api.de auftreten. Wer seine eigene Instanz installiert hat, kann die neueste Version unter http://wiki.openstreetmap.org/wiki/Overpass_API/versions#Overpass_API_v0.7.3 herunterladen. Viel Spaß mit der erweiterten Version, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Admin-Grenzen exportieren als Shapefiles
Hallo Marian, Konkret interessiere ich mich gerade für die Landkreise (und kreisfreie Städte) in NRW, demnächst möchte ich dies für ganz Deutschland zusammen tragen. Mit der Overpass API kannst Du die Grenzen mit http://overpass-api.de/api/interpreter?data=area[name=Nordrhein- Westfalen];rel(area)[admin_level=6];(._;;);out; bekommen. Mehr zum Thema Konvertierung von OSM XML nach SHP gibt es bei http://wiki.openstreetmap.org/wiki/Shapefiles#Obtaining_shapefiles_from_OSM_data Damit habe ich bisher allerdings noch nicht gearbeitet. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Hi! Habe nun etwas herum probiert und muss feststellen, dass der Fehler wo anders liegt. Was habe ich gemacht: [...] Hier liegt das grundlegende Problem: das ist ein Konflikt mit mir selbst, den es so nicht geben darf. Danke für das detaillierte Recherchieren. Die gedoppelte Relation ist allerdings in der Tat ein JOSM-Bug. Vielleicht sollte man eine Operation Wege teilen auf der Main API implementieren. Das würde nebenbei auch die Qualität der Daten-Historie verbessern. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Relationen
Hi, Wir sollten sobald wie möglich eine Lösung für ÖPNV-Relationen finden, denn sowas kann auf Dauer nicht funktionieren: http://www.openstreetmap.org/browse/way/102155261 Im konkreten Fall ist praktisch eine komplette Autobahn kaum zu editieren. Nur als Beispiele von heute: * Eine 30 Sekunden Editoraktion (vorher Daten aktualisiert) führte zu 43 Konflikten und mehr als 30 Minuten Aufräumaktion mit weiteren hunderten Konflikten. * Ein Knoten markieren - Daten aktualisieren - Sofort P drücken zum aufteilen - Sofort hochladen (weniger als 1 Sekunde nach derhttp://overpass-turbo.eu/ Aktualisierung) - 29 Konflikte Wo genau hat es den Konflikt gegeben? Auf dem Server? Im JOSM-Validator? Aus der Historie sehe ich jetzt erst einmal nicht den Hergang. Gerade beim Editieren in Köln hat es keine Probleme gegeben. JOSM passt normalerweise die Relationen beim Teilen von Wegen automatisch an. Und eigentlich können Konflikte nur auftauchen, wenn die Relation zwischenzeitlich von jemand anderem geändert worden ist oder ein Mitglied der Relation als Element gelöscht worden ist, aber nicht als Member der Relation. Insofern wäre es wichtig zu wissen, wo eogentlich die Konflikte aufgetreten sind. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenlizenz Deutschland - Namensnennung
Hallo zusammen, Was halten die OSM und die FOSSGIS Community eigentlich von der Datenlizenz Deutschland - Namensnennung [1] ? Die Lizenz ist kurz und für Verwaltungsrecht sehr verständlich geschrieben. In der Open-Data-Arbeitsgruppe bei der Stadt Bonn haben wir beispielsweise erfahren, dass der etwas eigenwillige Haftungsausschluss eben auf das Verwaltungsrecht zurückgeht. Das ist erst einmal sehr gut. Laut Open-Data-Arbeitsgruppe war bei der Lizenz das Ziel, CC-BY im Verwaltungsrecht nachzubilden. Der Geist der Lizenz ist Open Data. Und damit sollten wir Verwaltungen ermuntern, lieber diese als eine andere Lizenz aus dem Verwaltungsrecht zu verwenden. In der Praxis wird man die Daten sicherlich mit ODbL- oder CC-BY-SA- lizensierten Daten verknüpfen wollen. Ich denke, man sollte diplomtisch versuchen, eine offizielle Stellungnahme zu der Frage der Kombinierbarkeit und damit implizit auch Konvertierbarkeit zu bekommen. Wenn das als zulässig gesehen wird, dürfte die Lizenz auch als Open Data wirken. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Overpass API: Neue Version 0.7.2
Hallo zusammen, von der Overpass API ist eine neue Version verfügbar und online gegangen. Die wesentlichen Neuerungen sind auf Englisch auf http://wiki.openstreetmap.org/wiki/Overpass_API/versions beschrieben. Für den Endanwender möchte ich daraus zwei herausgreifen: Es ist jetzt einfacher möglich, eine Straßenliste einer Stadt zu generieren, deutsche Beschreibung siehe http://wiki.openstreetmap.org/wiki/DE:Overpass_API/Beispielsammlung#Stra.C3.9Fenliste Die Maxheight-Karte von mmd funktioniert dank einer deutlichen Beschleunigung der Around-Abfrage jetzt schneller: http://maxheight.bplaced.net/overpass/map.html Hier geht mein Dank an mmd sowohl dafür, dass er Karte auf Overpass-Basis neu aufgebaut hat als auch für die Analyse des Around-Statements, die die Beschleunigung erst möglich gemacht hat. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vorträge auf der FOSSGIS
Hallo zusammen, als kurzer Reminder: auch dieses Jahr bietet sich die FOSSGIS, Konferenz für freie Geosoftware, wieder als Treffpunkt für die deutschsprachigen OSMler an. Diesmal von 12.-14. Juni 2013 in Rapperswil in der Schweiz http://www.fossgis.de/konferenz/2013/ Damit es für OSM ein interessantes Programm gibt, werden noch Interessenten für Vorträge gesucht. Anmeldeschluss für Vorträge ist der 31. Januar. Details auf der obigen Website. Ich kann vom letzten Jahr bestätigen, dass die Zuschauer mit großer Begeisterung dabei sind und es einem Projekt den Durchbruch bringen kann. Also eine hervorragende Gelegenheit, das eigene Projekt vorzustellen. Ich bin dabei und freue mich darauf, möglichst viele von Euch dort ebenfalls zu treffen. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Vorträge auf der FOSSGIS
geographisch, so können sogar Objekte ohne Versionsänderung im Augmented Diff als gelöscht markiert werden müssen. Insgesamt ergibt sich eine unerwartet komplexe Semantik von Änderungstypen. Dazu kommen Probleme jenseits der Semantik: Einerseits sollen Relationen komplett aufgeführt werden, wenn sich ihre Geometrie ändert. Andererseits sorgt dies bei den doch häufigen Änderungen an Landesgrenzen für Dateigrößen, die nicht nur für andere Clients schwer beherrschbar sind, sondern auch erhebliche Kapazitäten des Server belegen. Sie sorgen zudem dafür, dass sich nur schwer Zeiträume von mehr als einigen Stunden überbrücken lassen. Es wird als Ausweg ein Ausblick auf den zukünftigen Full-History-Modus der Overpass API gegeben: Damit können dann Augmented Diffs mit den auf den jeweiligen Anwendungszweck zugeschnittenen Inhalten generiert werden, so dass insbesondere längere Zeiträume für kleine Bounding Boxen schnell erstellt werden können, was wiederum die Änderungsverfolgung drastisch verbessert. - Ich werde realistischerweise höchstens einen Workshop plus einen Vortrag vorbereiten können. Bitte bennent ein Wuschthema für einen Workshop und ein Wunschthema für einen Vortrag. Wie üblich werde ich nicht strikt auszählen, sondern den besten Argumenten folgen wie z.B. inhaltliche Überschneidungen zu ähnlichen Vorträgen zu vermeiden. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Overpass-Anfragen: großes Gebiet, nur einige Punkte
Hallo, danke für die Anfrage. Das Beispiel kommt dann gleich mit auf die Beispielseite. Wie bekomme ich mit einer Overpass-Abfrage die Punkte innerhalb eines Gebietes hin, also zum Beispiel alle Apotheken in Deutschland? area[name=Deutschland];node(area)[amenity=pharmacy];out; Die Abfrage sollte deutlich unter 3 Minuten brauchen (hat beim Testen 30 Sekunden gebraucht), ansonsten bitte [timeout:900];area[name=Deutschland];node(area)[amenity=pharmacy];out; Wenn ich mit area-query und eingebetteter query arbeite, versucht Overpass erst einmal, alle Punkte innerhalb des Gebiets zu kriegen, und bricht dann irgendwann ab. Gibt's keine Möglichkeit, die Und-Verknüpfung anders zu formulieren als über Schachteln? Die Und-Verknüpfung wird üblicherweise mit mehreren Clauses in der gleichen Query realisiert. Hier sind dies (area) und [amenity=pharmacy] Bei der Ausführung des Query-Statements werden diese dann verschachtelt, ähnlich dem Query-Plan einer SQL-Datenbank, so dass nicht alle Nodes geladen werden müssen. Das Grundprinzip ist in http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Clauses erläutert (leider bisher nur auf Englisch verfügbar). Etwas anders sieht es im Spezialfall einer area-Clause für Ways oder Relations aus. Das ist leider noch nicht implementiert (es fehlt der Schnittest Ways mit Area-Grenzen), so dass hier die umständliche Abfrage unvermeidlich ist. Dafür muss ich leider auf später vertrösten, die Funktionalität steht aber auf der ToDo-Liste. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hausnummern
Hallo zusammen, passend zu Frederiks Appell http://blog.openstreetmap.de/2012/12/1000-adressen/ stelle ich eine minutenaktuelle Karte der Hausnummern bereit: http://overpass-api.de/hausnummern.html Die Karte markiert ab Zoomstufe 16 alle Nodes und Ways an, die ein Tag addr:housenumber tragen. So erhält man eine visuelle Hilfe, wo Hausnummern noch sehr dünn gemappt sind. Wer seinem Browser und Rechner mehr zutraut oder ein ausreichend kleines Browserfenster hat, kann auch die weniger zoom-beschränkte Variante http://www.overpass- api.de/api/convert?data=%5Btimeout%3A1%5D%3B%28node%5B%22addr%3Ahousenumber%22%5D%3Bway%5B%22addr%3Ahousenumber%22%5D%3B%3E%3B%29%3Bout+skel%3B%0D%0Atarget=ol_bbox (Link ist eine Zeile) bzw. http://www.overpass-api.de/api/convert?data=[timeout:1]; (node[addr:housenumber];way[addr:housenumber];;);out skel; (Link ist nur eine Zeile) verwenden. Das liefert bei üblicher Baudichte einer Großstadt bei mir allerdings ab Zoomstufe 14 wegen mehr als 1 Objekten bereits einen eingefrorenen Browser. Daher obige Variante mit strikter Zoombegrenzung. Viel Spaß und viel Erfolg beim Mappen, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern
super, danke. Was mir noch auffiel: Permanentlink wär praktisch. Gibt es jetzt unter http://overpass-api.de/api/hausnummern Der Link unten rechts liefert dann URLs wie z.B. http://overpass-api.de/api/hausnummern?zoom=14lat=50.75lon=7.1layers=BT Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mehrere URLs fuer ein Objekt
1. Finanzamt Mannheim-Stadt: website = http://www.fa-mannheim-stadt.de 2. Finanzamt Mannheim-Neckarstadt: website = http://www.fa-mannheim-neckarstadt.de Einen gemeinsamen Web-Auftritt für die Finanzämter Mannheim kenne ich nicht. Ich plädiere für zwei getrennte Nodes im Gebäude mit Tags jeweils name, website und note=Verschieden vom Finanzamt ... im gleichen Gebäude. Das wirkt dann nicht nur für die Links, sondern erlaubt auch Tools wie z.B. Routing-Software, beide Finanzämter unter ihrem echten Namen im name-Tag (und damit überhaupt) zu finden. Viele Grüße, Roland ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
