Re: [Talk-de] Overpass Turbo - Spracheinstellung
Hallo Markus, am 07.06.2020 um 18:15 schrieb Markus via Talk-de: Hilfe...: mein Overpass spricht plötzlich italienisch mit mir... Menü: Impostazioni Dialog: Impostazioni Generali | Lingua: de | salva: Klick Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekt-ID finden mit JOSM
Hallo, am 19.08.2019 um 19:07 schrieb Markus via Talk-de: Wenn ich in JOSM ein Objekt ausgewählt habe, wie bekomme ich dessen Objekt-ID? (wird zwar mit angezeigt, aber ist nicht kopierbar) Wenn es nur um die ID geht: Mit Strg-i wird die ID auch angezeigt (erste Zeile). Und das ist kopierbar. In dem Fenster kann man auch den Schwerpunkt oder die Mitte des Koordinatenbereichs von Geometrien abgreifen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM Lizenzverstoß bei Kraichgau-Stromberg Tourismus e.V.
Hallo, am 26.06.2019 um 13:24 schrieb Sven Geggus: Es wäre IMO eher unschön wenn das irgendein Mapper direkt machen würde. Diese Bedenken kann ich nicht teilen, weil meine Erfahrungen anders sind. In meiner Eigenschaft als Irgendeinmapper habe ich öfter schon Kartenverwender auf die Lizenzregeln hingewiesen – natürlich mit konkreter Hilfe zum Wie. In jedem Fall wurde der Mangel abgestellt. Mehrfach war die Reaktion sehr aufgeschlossen bis dankbar. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karte mit Leaflet selber bauen
Danke für die Info. Wie schön, dass die Browser wieder unterschiedliche "Standards" haben. Dabei sollten doch gerade (das nutzt das Leaflet-Beispiel) etc. nicht beschränkt werden. Gruß nk Am 02.01.2019 um 19:14 schrieb Martin Koppenhoefer: Am Mi., 2. Jan. 2019 um 17:25 Uhr schrieb Norbert Kück : mit lokalen Dateien hat mein Browser das immer blockiert wegen der CORS directive. Missverständnis? Wenn die Dateien des verlinkten Beispiels auf deiner Festplatte liegen, gibt es kein cross origin. bei Safari und Chrome werden die lokalen geojson Dateien bei mir nur geladen, wenn ich einen Webserver starte, sonst geht es nur im Firefox, die bei ersteren bekomme ich "Cross origin requests are only supported for HTTP." (allerdings mit mapbox-gl-js), bei dem oben verlinkten Leaflet-Beispiel bekomme ich "Origin null is not allowed by Access-Control-Allow-Origin" und "Cross-origin script load denied by Cross-Origin Resource Sharing policy.", aber nur, wenn ich die Datei lokal ausführe, bei der Datei auf dem leaflet Server gibt es keine Probleme. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karte mit Leaflet selber bauen
Hallo Martin, am 02.01.2019 um 17:06 schrieb Martin Koppenhoefer: On 2. Jan 2019, at 10:40, Norbert Kück wrote: Doch, geht. Leaflet-Beispiel zeigt, wie: https://leafletjs.com/examples/geojson/ mit lokalen Dateien hat mein Browser das immer blockiert wegen der CORS directive. Missverständnis? Wenn die Dateien des verlinkten Beispiels auf deiner Festplatte liegen, gibt es kein cross origin. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karte mit Leaflet selber bauen
Hallo Markus, am 01.01.2019 um 21:15 schrieb Markus: Die Idee, sich eine Karte aus entsprechenden Blöcken > "zusammenzukopieren", halte ich für verwegen. Ich hoffe, dass wir, wenn hier einige Erfahrene ihr Wissen einbringen, die Idee realisieren können. Ok, dann wünsche ich viel Erfolg. Ein Projekt mit dem Ansatz "Leaflet-Karte als Lego" kann meins nicht sein. Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karte mit Leaflet selber bauen
Hallo, am 02.01.2019 um 01:03 schrieb Martin Koppenhoefer: einfach die html Datei im Browser öffnen. Wenn Du Geojson aus weiteren Dateien laden willst geht das so allerdings vermutlich nicht Doch, geht. Leaflet-Beispiel zeigt, wie: https://leafletjs.com/examples/geojson/ Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karte mit Leaflet selber bauen
Hallo Markus, am 31.12.2018 um 18:04 schrieb Markus: Ist es so besser? Ja, so ist es besser. Hoffentlich ist mein Eindruck falsch: Kann es sein, dass du eine Anleitung erstellen möchtest, ohne je selbst mit Leaflet experimentiert zu haben? Dann würde ich empfehlen, zunächst eigene Erfahrungen zu sammeln. Die Beschreibung erweckt den Eindruck, Anwendungen auf Basis von HTML, JavaScript und CSS müssten unbedingt auf einen Server hochgeladen werden um lauffähig zu sein. Tatsächlich funktioniert das auch auf dem lokalen Rechner (zumindest bei Windows-Maschinen mit gängigen Browsern), ohne dass man einen Webserver installieren müsste. Alle meine Karten wurden lokal entwickelt. Onlinezugang braucht es dann nur für externe Quellen (Kartenkacheln sowie ggf. Leaflet, andere externe Scripte, Daten). FTP nutze ich erst für die Veröffentlichung. Wenn Du magst bist Du natürlich gern eingeladen, bei der Entwicklung von Standardlösungen mitzuhelfen. Vielleicht schaust du dir mal folgende Seite an. Sie enthält Links zu Kartenanwendungen, die drei unterschiedliche Arten von Datenquellen ansprechen und die Daten unterschiedlich darstellen. Das ist ein Ausschnitt aus meinem Portfolio. "Normale" Marker wirst du dort allerdings nicht sehen, weil sie m.E. zu sehr den Kartenhintergrund verkleistern. https://osm.nkbre.net Daraus abgeleitet gibt es ein paar Prototypen. Aus dem folgenden Modell wurden von Personen ohne Leaflet-Kenntnis bereits funktionierende Karten erstellt: https://osm.nkbre.net/x/rm_media/nk-rm_media.html Übrigens: Der eingebundene Ton deutet NICHT auf meine Vorliebe für Militärkapellen. Die Europahymne gespielt von US-Soldaten ist Publik Domain. :-) Wenn du dich mit dem Prototypen befassen willst, bekommst du Zugang zu einem ZIP-File, das auch etwas Erläuterung enthält. Die Idee, sich eine Karte aus entsprechenden Blöcken "zusammenzukopieren", halte ich für verwegen. Es bestehen immer einige Abhängigkeiten, die bei Nichtbeachtung den Showstopper geben. Möglich wäre wohl eine bessere Kapselung einzelner Module. Das ist aber (derzeit) nicht mein Weg. Ich bevorzuge funktionierende Prototypen, die nur Anpassungen in der Oberfläche, Starteinstellungen und Daten im passenden Formaten benötigen. Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karte mit Leaflet selber bauen
Hallo Markus, am 30.12.2018 um 23:13 schrieb Markus: ich habe mal etwas "Gerüst" gebaut: https://wiki.openstreetmap.org/wiki/DE:OSM_mit_Leaflet Der Satz "Kenntnisse in JavaScript werden nicht vorausgesetzt..." auf der Seite ist m.E. sehr mutig. Trotz (oder wegen?) einiger Jahre Erfahrung mit Leaflet kann ich mir nicht vorstellen, wie das stabil funktionieren soll. GeoJSON, das du nutzen möchtest, *IST* JavaScript. Beispielsweise die Füllung von Popups und die individuelle Initialeinstellungen der Karte bedeuten zwangsläufig Umgang mit JavaScript. Die Chance zu scheitern und der Betreuungsbedarf verhalten sich reziprok proportional zum Umfang der JavaScript-Kenntnisse – auch dann, wenn der Karten-Prototyp als Korsett (gibt Halt und engt ein) gebaut ist. Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Polygon zeichnen und als GeoJSON speichern
Hallo Markus, am 03.12.2018 um 21:30 schrieb Markus: Nur an einem Punkt komme ich noch nicht weiter: Wie kann ich eine bestehende GeoJSON in JOSM laden? (um das Polygon zu verändern) Ob das JOSM-Plugin "geojson" hilft, müsstest Du mal probieren. Einfach aber wirksam: das Polygon auch als .osm speichern und damit die Änderungen machen (wieder in beiden Formaten speichern). Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Polygon zeichnen und als GeoJSON speichern
Hallo Markus, am 03.12.2018 um 14:22 schrieb Markus: ich suche ein Tool, mit dem ich auf der OSM-Karte ein Polygon zeichnen und dieses als GeoJSON speichern kann. Vermutlich hast Du dieses Tool schon: JOSM, Datei|Speichern unter...|Dateityp: GeoJSON In einem Punkt muss man aufpassen: Wenn JOSM das Polygon nicht als Fläche erkennt, wird es als LineString gespeichert und muss von Hand angepasst werden. Onlinetool: http://geojson.io/ Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 30er Zone (Z274.1)
Am 06.10.2018 um 20:10 schrieb Martin Scholtes: Moin zusammen, wollte mal eben wieder eine Straße mit dem 30er Zone Zusatz ergänzen und festgestellt, das im Wiki drei Varianten vonsource:maxspeed gibt. Welche ist den nun eigentlich die offizielle? https://wiki.openstreetmap.org/wiki/DE:Key:source:maxspeed Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de Hallo, ich bin der Meinung, dass source angibt woher die Information stammt. z.B source:maxspeed=sign Ich tagge 30er Zonen mit zone:maxspeed=DE:30 Viele Grüße Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bing-Luftbilder - Aktualität
Hallo, am 25.06.2018 um 23:17 schrieb Markus: Wie kann ich das Aufnahmedatum der in JOSM verwendeten Bing-Luftbilder herausfinden? Schon mal Rechtsklick (Kontextmenü) versucht? Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Marker auf openstreetmap.de setzen?
Hallo Michael, am 12.06.2018 um 18:30 schrieb Michael Reichert: Falls jemand jetzt Code beisteuern möchte, der das implementiert: Ich würde als Maintainer zwar prinzipiell Patches annehmen, die das nachrüsten würden, weise aber darauf hin, dass über kurz oder lang dort OpenLayers 2 durch Leaflet ersetzt werden wird und die Arbeit dann nicht lang in Benutzung sein wird. Wenn dereinst auf Leaflet gewechselt wird: Da ist diese Funktion recht simpel zu machen - liefere ich gerne zu. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Craftmapping
Hallo, am 04.01.2018 um 15:39 schrieb Frederik Ramm: [...] "Craftmapping" (zu deutsch: "handwerkliches Kartieren"?) ist in meinen Augen die traditionelle OpenStreetMap-Arbeit: eine Gegend, die man selber kennt, mit allen verfügbaren Mitteln (vorallem mit Ortsbegehung) auf die Karte zu bringen. Da können Luftbilder schon eine Rolle spielen,[...] Der Beitrag tut richtig gut. Ich bevorzuge handwerkliches Kartieren und verwende unterstützend andere Quellen - allerdings nicht mechanisiert. Ein Ground-Truth-Dogma halte ich für verfehlt. OSM ist eine georeferenzierte Faktendatenbank, die glücklicherweise sehr viel mehr Informationen hält, als man im Gelände wahrnehmen kann. Und nicht alles, was man im Gelände sieht, ist wahr. Vernunft geht vor Schema. Gruß Norbert (übrigens OSMF-Mitglied) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging
Mit Sicherheit hast Du Recht. Wie so oft wird viel geschrieben und dann doch nichts konkret beschlossen oder getan :-(( Aber das Wiki müsste man trotzdem mal konkretisieren. Gruß Norbert Am 06.04.2017 um 17:41 schrieb Butrus Damaskus: 2017-04-06 13:47 GMT+02:00 Martin Koppenhoefer <dieterdre...@gmail.com>: Am 6. April 2017 um 13:16 schrieb Norbert <norbert.brunkha...@online.de>: Die ganzen source:maxspeed Tags sind doch nur ein Hinweis an die Mapper, woher die Erkenntnis kommt. jein, es geht dabei auch um den hypothetischen Fall, dass ein Default-limit geändert wird, z.B. innerorts nur noch 40 oder ausserorts nur noch 90. Wenn man anhand der Daten genau sagen kann, wo das limit herkommt, dann kann man in so einem Fall mit einem Schlag alles umtaggen. Gruß, Martin Das wird a) sowieso nie passieren, b) selbst dann muss man die Database manuell kontrollieren und alle anders getaggte Stellen per Hand korrigieren. Also, ehrlich gesagt, solange es da keinen Bedarf gibt (und den wird es sowieso in vorhesehbarerer Zeit nicht geben), ist der Aufwand nicht zu gerechtfertigen... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging
Naja, jeden hypothetischen Fall abzudecken ist sportlich. Aber nach dem Proposal ist in zone:traffic=DE:urban ja 50 default und analgo in DE:rural 100. Da bräuchte man gar kein maxspeed mehr. Also auch im hypothetischen Fall gar nichts umtaggen. Am 06.04.2017 um 13:47 schrieb Martin Koppenhoefer: Am 6. April 2017 um 13:16 schrieb Norbert <norbert.brunkha...@online.de>: Die ganzen source:maxspeed Tags sind doch nur ein Hinweis an die Mapper, woher die Erkenntnis kommt. jein, es geht dabei auch um den hypothetischen Fall, dass ein Default-limit geändert wird, z.B. innerorts nur noch 40 oder ausserorts nur noch 90. Wenn man anhand der Daten genau sagen kann, wo das limit herkommt, dann kann man in so einem Fall mit einem Schlag alles umtaggen. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging
Für wen taggen wir denn maxspeed und die sonstigen Tags um zone:traffic oder zone:maxspeed? Mir fällt nur ein: Navi oder App die die aktuell gültigen Geschwindigkeiten anzeigen. Oder ein Router, der über die maxspeed versucht die Reisezeit auszurechnen. Für diese Fälle würde ein maxspeed an der Straße ausreichen. Will man jetzt unterscheiden, ob ausserhalb oder innerhalb einer Ortschaft oder 30-Zone muss ein weiterer Tag her. Dafür gibt es ja aus dem Proposal zone:traffic. Leider wurde hier keine 30-Zone rein geschrieben. Alternativ gibt es ja zone:maxspeed=DE:30 Die ganzen source:maxspeed Tags sind doch nur ein Hinweis an die Mapper, woher die Erkenntnis kommt. Jetzt aber zurück zur eigentlichen Ausgangsfrage, ob die source:maxspeed Tags vereinheitlicht werden können. Zuerst muss man sich auf einen source:maxspeed einigen. Wie geht das in der Praxis? - Forum oder Abstimmung. Dann muss das Wiki entsprechend angepasst werden. Dort muss eindeutig beschrieben sein, wie Straßen ausserhalb, innerhalb und in den Geschwindigkeitszonen zu mappen sind. Und zwar ohne "oder". Meine Stichproben haben gezeigt, dass meisten maxspeed=30 zusammen mit einem soure:maxspeed getaggt ist. Wahrscheinlich, weil nirgends genau steht, dass eigentlich ein zone:maxspeed=DE:30 hin gehört. Wer macht das? Und dann muss die Änderung initiiert werden. Wie geht das? Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging
Ich denke mal Du meinst zone:traffic aus dem Proposal von 2009. Gibt es eigentlich auch mal abgesegnete Proposals? Ich verstehe aber den Grund für maxspeed:implicit nicht. Wenn ich innerorts die Hauptstraße mit zone:traffic=DE:urban tagge ist es doch getan. Wenn jetzt ein Stück Hauptstraße auf 30 begrenzt wird, bekommt diese Stück maxspeed=30 plus source:maxspeed=sign Die Seitenstraßen, die 30-Zone sind, bekommen dann ein zone:traffic=DE:30 ein maxspeed=30 ist dann auch nicht mehr nötig und ein source:maxspeed schon gar nicht. Man müsst beim Proposal nur bei den ? ? ? DE:30 mit den Defaultwerten ergänzen. Gruß Norbert Am 03.04.2017 um 11:32 schrieb Martin Koppenhoefer: es reicht für source:maxspeed dann aber eigentlich aus, zu wissen ob es ein explizites oder implizites limit ist, (weil es z.B. auch 50er Schilder innerorts gibt). D.h. man könnte was in dieser Art machen (angenommen, 30er und 20er Zonen sind immer innerorts): maxspeed:implicit=yes/no traffic_zone=DE:urban/DE:rural/DE:motorway/DE:zone30/DE:zone20 maxspeed=tatsächliche Begrenzung source:maxspeed bräuchte man nicht mehr, bzw. können diejenigen weiterverwenden, die da Werte wie "survey" eintragen wollen. Genausowenig bräuchte man zone:maxspeed, weil das bereits in der traffic_zone enthalten wäre, und wenn es dabei um mehr als nur maxspeed gehen soll (nicht hupen etc.), dann wäre der tag mit einem generischen Namen sowieso besser beschrieben. Das Umtaggen von source:maxspeed und zone:maxspeed zu traffic_zone und maxspeed:implicit sollte ausserdem in vielen Fällen (traffic_zone) bzw. allen Fällen (maxspeed:implicit) automatisch möglich sein. Gefixt wird dadurch, dass man auch bei einem explizit ausgeschilderten maxspeed highway sagen kann, ob er sich innerorts oder ausserorts befindet (gem. StVO) (indem man die Daten dort nachträgt, wo sie derzeit noch fehlen, nämlich bei source:maxspeed=sign road_marking etc,). Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging
Ich stimme Dir zu. Die 30 ist überflüssig. Aber wie ist denn eine 30-Zone überhaupt zu mappen? Viele, mich eingeschlossen mappen maxspeed=30 source:maxspeed=DE:zone30 oder DE:zone:30 So steht es ja auch im wiki Andere mappen maxspeed=30 zone:maxspeed=DE:30 Eigentlich müssten doch drei Tags angegeben werden maxspeed=30 --> Höchstgeschwindigkeit zone:maxspeed=DE:30--> Es handelt sich um eine 30 Zone source:maxspeed=DE:zone -- Die Quelle für maxspeed Diese Variante gibt es aber nur ca 500 mal. Norbert Am 01.04.2017 um 22:33 schrieb Bernhard Weiskopf: Welchen Sinn macht es, die Zahl "30" nochmal bei zone oder source anzugeben? "source:maxspeed=DE:zone" o. ä. empfinde ich als völlig ausreichend. Bei anderen Schildern wird auch nur "source:maxspeed = sign", "source:maxspeed = DE:urban" oder ähnlich angegeben, aber nicht "source:maxspeed = sign:30" oder "source:maxspeed = DE:urban:50". Oder stehe ich gerade auf dem Schlauch? Bernhard Aktuelle Zahlen von heute: maxspeed=30 and zone:maxspeed=DE:30 - 32952 uses maxspeed=30 and source:maxspeed=DE:zone30 - 32018 uses maxspeed=30 and source:maxspeed=DE:zone:30 - 21832 uses (die Nutzungen beziehen sich nicht auf die Kombination mit maxspeed=30 sondern nur auf den 2. Tag, sollte aber keine große Abweichung sein). Wie wärs, wenn wir zumindest source:maxspeed=DE:zone30 und source:maxspeed=DE:zone:30 vereinheitlichen würden, per Einigung auf eine Variante und mechanisches Umtaggen? Die weiteren dokumentierten Varianten sind source:maxspeed=DE:zone und source:maxspeed=zone mit 5k und 1,8k Nutzung. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging
Na das Thema scheint ja hier kein großes Interesse zu wecken. Im Forum wird es bestimmt eine endlose Diskussion geben. Es geht eigentlich nur über eine Abstimmung und dann das wiki anpassen und umstellen. Ich habe allerdings keine Ahnung wie man eine Abstimmung initiiert. Habe mich damit bisher nicht befasst. Gruß Norbert Am 31.03.17, 17:46, Martin Koppenhoefer <dieterdre...@gmail.com> schrieb: Am 31. März 2017 um 13:53 schrieb Norbert <norbert.brunkha...@online.de>: > Im wiki muss genau stehen, wie was einzutragen ist. > Wenn dort schon drei verschiedene Schreibweisen aufgeführt sind, braucht > man sich doch nicht zu wundern. > > Mein Vorschlag ist DE:zone30 - sind auch schon die meisten Einträge. > > Und zone:maxspeed=DE:30 würde ich auch gleich mit umstellen. > Ist im wiki ja auch äußerst spärlich beschrieben. > ja, wie macht man das nun konkret, wartet man einfach ein paar Tage und wenn kein Widerspruch kommt macht man es einfach? Soll man dazu auch was im Forum posten, und hätte jemand Lust, das zu übernehmen? Gibt es evtl. den tag in irgendwelchen presets? Gibt es Kartenauswerter, die nur auf die weniger genutzten Schreibvarianten bauen? Gruß, Martin _ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mechanisches Umtaggen, Vorschlag zur vereinheitlichung von 30er Zonen tagging
Im wiki muss genau stehen, wie was einzutragen ist. Wenn dort schon drei verschiedene Schreibweisen aufgeführt sind, braucht man sich doch nicht zu wundern. Mein Vorschlag ist DE:zone30 - sind auch schon die meisten Einträge. Und zone:maxspeed=DE:30 würde ich auch gleich mit umstellen. Ist im wiki ja auch äußerst spärlich beschrieben. Viele Grüße Norbert Am 30.03.2017 um 14:18 schrieb Martin Koppenhoefer: Es gibt mehrere Standards und ein paar weitere Alternativen, um 30er Zonen zu taggen. Dazu hier im wiki: https://wiki.openstreetmap.org/wiki/Key:source:maxspeed Aktuelle Zahlen von heute: maxspeed=30 and zone:maxspeed=DE:30 - 32952 uses maxspeed=30 and source:maxspeed=DE:zone30 - 32018 uses maxspeed=30 and source:maxspeed=DE:zone:30 - 21832 uses (die Nutzungen beziehen sich nicht auf die Kombination mit maxspeed=30 sondern nur auf den 2. Tag, sollte aber keine große Abweichung sein). Wie wärs, wenn wir zumindest source:maxspeed=DE:zone30 und source:maxspeed=DE:zone:30 vereinheitlichen würden, per Einigung auf eine Variante und mechanisches Umtaggen? Die weiteren dokumentierten Varianten sind source:maxspeed=DE:zone und source:maxspeed=zone mit 5k und 1,8k Nutzung. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gelöschte Objekte visuell wiederfinden
> Leider zeigt mir die Webseite nur Änderungen für einen Way an. Ich suche ein Point Objekt. Also achavi kann schon auch Änderungen an Nodes anzeigen, hast Du ein konkretes Beispiel? Oder meinst Du Potlach 1, vermutlich immer noch die beste Lösung zum Finden und Wiederherstellen gelöschter Ways [1] (aber eben nur Ways)? Zum Auffinden gelöschter Objekte ist leider auch achavi bzw. die dort verwendete Overpass adiff Abfrage nicht ideal. Diese ermittelt nur die Differenz zwischen zwei Zeitpunkten. Ein Objekt, das innerhalb des Zeitraums angelegt und wieder gelöscht wurde, bleibt dabei unberücksichtigt. Wenn man weiß wonach man sucht, könnte man auch mit der date Abfrage [2][3] in Overpass Turbo systematisch Stichproben in der Vergangenheit machen, das ginge evtl. etwas schneller als mit achavi, besonders mit einer Einschränkung nach Objekt und Tags. Ansonsten habe ich noch gesehen, dass es eine Wiki-Seite zum Finden gelöschter Nodes gibt: https://wiki.openstreetmap.org/wiki/Find_the_id_of_a_deleted_node Gruß, Norbert [1] https://wiki.openstreetmap.org/wiki/Change_rollback#Potlatch_1 [2] https://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Attic_data_.28.22date.22.29 [3] https://wiki.openstreetmap.org/wiki/DE:Overpass_API/Beispielsammlung#Stand_der_OSM-Daten_zu_einem_Stichtag ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS als deutsches OSMF-Chapter
Hallo, am 21.10.2016 um 21:52 schrieb Frederik Ramm: Was sagt ihr dazu? Prima, machen! Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koordinaten
Hallo, am 08.08.2016 um 15:21 schrieb Eifelhunde: wie machst du das? z.b. | Breitengrad= 50/43/49/N | Längengrad = 06/30/58/E (https://de.wikipedia.org/w/index.php?title=Motte_bei_Drove=edit) Siehe https://de.wikipedia.org/wiki/Vorlage:Infobox_Burg#Parameter dort die Zeile "Breitengrad und Längengrad", und dort den Link zu https://de.wikipedia.org/wiki/Vorlage:Coordinate#NS_und_EW Auch der visuelle editor will das in der ° " Schreibweise. Nein, auch der nimmt Dezimalschreibweise. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koordinaten
Hallo, am 08.08.2016 um 14:45 schrieb Eifelhunde: kann ich eigentlich osm überrede das die Koordinaten in ° " und' dargestellt werden? Brauche ich für Wikipedia Wo braucht man das für Wikipedia? Ich verwende dort NUR die Dezimalschreibweise. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisverkehr einfach löschen?
Am 09.05.2016 um 17:13 schrieb Florian Lohoff: On Mon, May 09, 2016 at 04:57:04PM +0200, Kevin Hemker wrote: Hallo allerseits, die Bing-Bilder im Anhang zeigen einen "Baustellen-Kreisverkehr", der vor 4/5 Jahren für ca 2 Wochen bestanden hat. (Wenn mans weiss sieht man rechts unten sogar eine Absperrbake). Nun existiert der natürlich garnicht - und bei Erstellung oder im Laufe der Zeit wurden etliche Busrouten zerschossen, die da durchlaufen (sollten) aber wo dieses Teilstück fehlt. Würdet ihr den Kreisverkehr einfach löschen, die ways miteinander verbinden und die Relationen wieder alle zusammenfriemeln? Kann man die Stelle dann irgendwie markieren, dass die Bing-Bilder hier veraltet sind? (dazu habe ich noch nicht wirklich viel gefunden) Wenn du die Objekte löscht wird der nächste sie wieder eintragen. Ich mache das meist dann so das ich die Objekte (Ways) da lasse - alle tags entferne und einen note auf den ways hinterlasse was das ist und warum... Dann ist die chance das jemand das liest und das neueintragen lässt. Wenn auf dem Luftbild ein Kreisverkehr zu sehen ist, in OSM aber keiner eingetragen ist, sollte man sich eigentlich vor Ort überzeugen was richtig ist. Aber die Idee den Weg zu lassen und eine note dranzuhängen ist gut. Dann wird sich hoffentlich ein Sesselmapper fragen was da los ist und die note auch beachten. Gruß Gino Flo ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Georeferenzierung von Commons-Bildern
Hallo Markus, am 06.01.2016 um 15:11 schrieb Markus: Ja, das hatte ich auch gefunden, und den Geolocator. Aber das HowTo und die Doku-Links im Geolocator sind irgendwie so kompliziert, das ich nicht herausfinde, was ich wo eintragen muss, und welchen String ich kopieren und wo und wie ich diesen einfügen soll... Nimm Dir etwas Zeit um mit dem Geolocator zu spielen. Es ist einfacher, als Du denkst. :-) Da habe ich nicht verstanden, wie man die Vorlagen nutzt. Eigentlich müssten die doch standardmässig auf der Hochlade-Seite von Commons eingebunden sein? Dort finde ich aber nichts, wo man eine Position eingeben könnte. Nun, es gibt DIE Hochladeseite nicht, sondern den sogenanten Assistenten und die herkömmlichen Formulare. Letzere entsprechen weitgehend dem Formular zum Ändern der Beschreibungsseite. Die Vorlagen werden im Assistenten NICHT eingegeben, aber durch die Technik generiert. Unter dem Register "Beschreiben" findest Du weit unten einen Link "Ort und weitere Informationen hinzufügen...", der u.a. Eingabefelder für Location öffnet. (Manchmal hilft einfaches Probieren!!) Commons bevorzugt die Kameraposition (Location). Macht Sinn :-) Nicht immer. Plus vermutlich die Blickrichtung? Ja. und die Entfernung zum Objekt? Eben nicht! Und damit fehlt die Lage des Objekts! Es wird lediglich dokumentiert, wo der Fotograf stand und wohin er sah. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Georeferenzierung von Commons-Bildern
Hallo Markus, am 04.01.2016 um 08:31 schrieb Markus: Was muss man wie in Commons eintragen? [1] erklärt, welche Info wie eingefügt wird. Dabei kommen die Vorlagen Location [2] und Object location [3] zum Einsatz. Beide Vorlagen verarbeiten (im Gegensatz zur Darstellung in [1]) sowohl Dezimalgrad als auch DMS-Koordinaten. Commons bevorzugt die Kameraposition (Location). Da ich kein GPS in der Kamera und keine Lust zur nachträglichen Ermittlung meines Standortes habe und mir die Position des abgebildeten Objekts meistens wichtiger ist, verwende ich Object location. Gruß nk [1] https://commons.wikimedia.org/wiki/Commons:Georeferenzierung [2] https://commons.wikimedia.org/wiki/Template:Location [3] https://commons.wikimedia.org/wiki/Template:Object_location ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Public Transport - Haltestelle ohne Linie / Austragen oder belassen
Hallo, ich würde bus_stop=yes auf disused setzen. Wäre doch ärgerlich, wenn jemand seine Navi-App befragt und dann zu der Bushaltestelle geht, um dann festzustellen, dass dort gar kein Bus fährt. Gruß Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] A Year of edits Liste
Am 08.09.2015 um 14:49 schrieb MonkZ: Ich suche nach einer Liste mit "A Year of Edits" Videos. Lass doch einfach Google oder Startpage nach "A Year of Edits" (genau diese Zeichenfolge!) suchen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Hallo, Am 18.08.2015 um 19:55 schrieb Butrus Damaskus: 2015-08-04 16:00 GMT+02:00 Norbert Kück o...@nkbre.net: Gewässer, die von Menschen NICHT GESCHAFFEN sondern VERÄNDERT wurden, sind KEINE KÜNSTLICHEN Gewässer. Der Rhein bleibt ein natürliches Gewässer trotz Begradigung, Stau, Uferbefestigung ... Falsch. Warum falsch? Wie ist denn dann richtig? Wer legt fest, was ein natürliches Gewässer ist? Die Gesetzgeber - Bund und Länder. Das WHG (Bund) bestimmt nicht den Begriff natürliche Gewässer, sondern nur künstliche Gewässer und erheblich veränderte Gewässer. Es schreibt aber in § 6 Abs. 2 vor: nicht naturnah ausgebaute NATÜRLICHE GEWÄSSER sollen so weit wie möglich wieder in einen naturnahen Zustand zurückgeführt werden (Hervorhebung durch mich). Landeswassergesetze enthalten (ich habe NICHT alle 16 geprüft) ergänzende Bestimmungen, dass auch künstlich veränderte Gewässer als natürlich gelten. Baden-Württemberg z.B. bestimmt sogar, dass künstlich angelegte Wasserläufe, die einen natürlichen Wasserlauf zum Teil ersetzen, zu den natürlichen gehören. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Hallo, am 04.08.2015 um 12:55 schrieb Michael Paulmann: Also selbst im Wiki ist das was bei Waterway=stream steht kein natürliches Gewässer https://wiki.openstreetmap.org/wiki/DE:Tag:waterway%3Dstream Also dieser Stream ist für mich eindeutig ein Entwässerungsgraben und damit ditch Die Frage nach einem natürlichen Gewässer lässt sich nicht anhand eines Fotos klären. Unterscheide natürliche Gewässer von naturbelassenen Gewässern. Letztere gibt es kaum noch. Entscheidend ist, ob die Gewässer von selbst oder durch Menschenhand entstanden sind. Leider sind viele Gewässer begradigt und/oder mit befestigter Sohle und Ufern ausgebaut - bleiben aber natürliche Gewässer. In meiner erweiterten Nachbarschaft gibt es natürliche Gewässer, die wesentlich schlimmer verbaut sind, als der Bach auf dem Foto. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Hallo, am 04.08.2015 um 14:02 schrieb Michael Paulmann: Ja aber halt mal, dann müssen wir jetzt erstmal klären was denn nun als Entwässerungsgraben zu taggen ist, denn ich kenne mindestens einen Bach der nie ein Bach war sondern immer ein Entwässerungsgraben und jetzt aufgrund von Umweltschutzmassnahmen wie ein Bach aussieht. Wie taggt man denn das? § 3 Wasserhaushaltsgesetz Für dieses Gesetz gelten folgende Begriffsbestimmungen: ... 4. Künstliche Gewässer von Menschen geschaffene oberirdische Gewässer oder Küstengewässer; 5. Erheblich veränderte Gewässer durch den Menschen in ihrem Wesen physikalisch erheblich veränderte oberirdische Gewässer oder Küstengewässer; ... Ergo: Ein natürlich gestaltetes von Menschen geschaffenes Gewässer ist ein künstliches Gewässer, ein durch den Menschen in seinem Wesen physikalisch erheblich verändertes Gewässer jedoch nicht. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Nachtrag: Der Graben ist gemäß Wasserhaushaltsgesetz ein natürlich gestaltetes künstliches Gewässer. Am 04.08.2015 um 14:02 schrieb Michael Paulmann: Ja aber halt mal, dann müssen wir jetzt erstmal klären was denn nun als Entwässerungsgraben zu taggen ist, denn ich kenne mindestens einen Bach der nie ein Bach war sondern immer ein Entwässerungsgraben und jetzt aufgrund von Umweltschutzmassnahmen wie ein Bach aussieht. Wie taggt man denn das? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagging von Bächen als waterway=ditch
Am 04.08.2015 um 15:05 schrieb Michael Paulmann: Sag das mal den Leuten die in 25 Jahren dort mappen wo Flüsse und Seen renaturiert werden. Nach der Definition ist das dann ja Künstlich. Also könnte man fast sagen das es in Deutschland keine natürlichen Gewässer mehr gibt. Oder? Oder! Gewässer, die von Menschen NICHT GESCHAFFEN sondern VERÄNDERT wurden, sind KEINE KÜNSTLICHEN Gewässer. Der Rhein bleibt ein natürliches Gewässer trotz Begradigung, Stau, Uferbefestigung ... Es geht hier nicht um den Zustand des Gewässers, sondern um die Entstehung. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage (Entwurf) zu Kleben von Landnutzungsflächen an Straßen
Am 09.07.2015 um 17:19 schrieb Markus: Hallo Norbert, Die Linie repräsentiert doch die Straße, die in ihrer wirklichen Breite nicht gemappt wird. Ja. Dabei ist die Linie ein Graph, eine Kante zwischen zwei Knoten. Damit wird der Weg für das Routing abgebildet. Der Graph entspricht die *Mittellinie* der Strasse (Form und Lage). (wie du oben schreibst: die Linie repräsentiert die Strasse) Der Renderer macht aus der Linie und den tags (Breite, Spurzahl, etc) die entsprechende Darstellung (Farbe, Breite). Beim mapnik kann ich das aber nicht erkennen. Wenn zum Beispiel auf der einen Seite einer Straße ein Gehweg ist und anschließend direkt die Friedhofsmauer Aus dem Graphen der Strasse und dem Attribut Gehweg macht der Renderer die Strasse mit Gehweg. Auch das macht mapnik nicht. Wenn ich nun den Friedhof mit seiner Mauer direkt an die Straße klebe, dann entspricht dies doch der Wirklichkeit. Nein. Der Friedhof ist eine Fläche, mit genauer Flächengrenze. Die Strasse hingegen ist ein Graph, der die Mittellage der Strasse angibt. Wo würdest Du die Friedhofsmauer/-Zaun eintragen? (ich hoffe, nicht auf der Strassenmitte ;-) ) Ich bin für zeichnen was man sieht :-) Du zeichnest ja keine Straße wie Du sie siehst, sondern nur eine Linie, bestenfalls in der Straßenmitte. Der Renderer mach dann daraus was er will. Wie oben schon beschrieben ignoriert mapnik die Anzahl der Spuren und Geh- oder Radwege. Wenn ein Haus zu nah an einer Straße steht, rendert mapnik ja auch die Straße einfach über das Haus, obwohl man nach bestem Luftbild das Haus richtig eingezeichnet hat. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umfrage (Entwurf) zu Kleben von Landnutzungsflächen an Straßen
Hallo, ich verstehe gar nicht, dass die Meisten doch gegen das Ankleben sind. Die Linie repräsentiert doch die Straße, die in ihrer wirklichen Breite nicht gemappt wird. Alles andere macht der Renderer (oder auch nicht). Wenn zum Beispiel auf der einen Seite einer Straße ein Gehweg ist und anschließend direkt die Friedhofsmauer, dann wird dies mit sidewalk an die Straße gemappt. Wenn ich nun den Friedhof mit seiner Mauer direkt an die Straße klebe, dann entspricht dies doch der Wirklichkeit. Zwischen Straße und Friedhof ist kein Niemandsland. Auf der anderen Seite der Straße gibt es Kleingärten, die auch direkt am Gehweg anfangen. Auch hier klebe ich das direkt an die Straße. Es ist die Aufgabe des Renderes dies korrekt darzustellen. Leider macht der mapnik mit den Angaben zu Gehwegen entlang der Straßen nichts. Bei einem Wald verlaufen die Wege auch über den landuse-Bereich. Ich mappe doch nicht jeden Acker oder jedes Waldstück separat. Das Argument der Bearbeitung kann ich auch nicht nachvollziehen. In JOSM ist es doch kein Problem das Richtige auszuwählen oder zu bearbeiten. Ich verweise mal auf die mittlere Maustaste. Viele Grüße Norbert Am 08.07.2015 um 18:10 schrieb Michael Reichert: Crossposting: http://forum.openstreetmap.org/viewtopic.php?pid=514639#p514639 Hallo, Sollen Landnutzungsflächen sich die Nodes mit Straßen-Ways teilen? Ob man Landnutzungsflächen an Straßen kleben soll oder nicht – wie oft wurde darüber schon gestritten, egal ob Forum oder Mailinglisten oder Stammtische. Beide Seiten haben ihre Argumente vorgebracht. Mich interessiert, wie ihr denkt. Ja. Die Straße und die angrenzende Landnutzungsfläche sollen sich die Nodes teilen. Nein. Die Landnutzungsfläche sollte dort aufhören, wo sie in der Realität aufhört und nicht in der Straßenmitte. Ich habe eine Umfrage vorbereitet, die noch im Entwurf-Stadium ist. Ich bitte um Kommentare zum Entwurf (hier, auf der OSM-Umfrageplattform oder im Forum). http://osm.haraldhartmann.de/umfrage/poll/36 Mailinglisten- und Forenposts sind das eine, mich interessiert, wie die Mapper denken, die sich nicht so sehr an diesen Diskussionen beteiligen. Kleine Liste an Argumente für das Kleben an Straßen: - kartographisch schöne, man lässt keine Lücke - bessere GIS-Modellierung (wurde mir in einer PN geschrieben) - Wegen überlappender Landnutzungsflächen ist eine Flächenberechnung aus OSM-Daten (z.B. wie viel Fläche in Deutschland bewaldet ist) nicht (leicht) möglich. Kleine Liste an Argumenten gegen das Kleben an Straßen: - Die Wiese geht nicht bis zur Straßenmitte. - Gauckelt größere Flächen vor. - an Straßenmitten geklebte Flächen sind schwer zu editieren Meine persönliche Meinung sagt, dass man Landnutzungsflächen nicht an Straßen kleben sollte. Viele Grüße Michael ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bitte um Hilfe/Verbesserung/Kritik Haltestellen-Relation
Hallo Andreas, leider gibt es viele unterschiedliche Meinungen zum Puplic-Transport-Schema V2 Für mich ist absolut unbefriedigend, dass man die alten Tags highway=bus_stop und highway=platform verwenden muss, damit in mapnik überhaupt was angezeigt wird. Wie Du es mappen willst ist im Prinzip ok. Allerdings muss Du der Platform (way) noch den Tag highway=platform geben. Wenn dieser way dann allerdings in eine Buslinienrelation aufgenommen wird, wird der Routenanlayzer einen Fehler melden. Ich nehme deshalb die Platform so auf, wie Du es ja auch gemacht hasst, und auch die Haltestelle mit public_transport=platform. Diesen Punkt, der auch alle weiteren Tags bekommt, verbinde ich mit einem Punkt des Platform-Weges. In die Relation kommt dann nur die stop_position und der Haltestellenpunkt. Hier mal ein Beispiel der Bushaltestelle Vogelsbergstraße mit einem way und einem area: https://www.openstreetmap.org/node/60661265#map=18/50.24082/8.99353layers=N Viele Grüße Norbert Am 05.07.2015 um 22:21 schrieb Andreas Schmidt: Guten Tag, könnte bitte jemand schauen, ob ich es richtig mache? https://www.openstreetmap.org/changeset/32434480 Ich möchte alle Haltestellen unseres Bürgerbusses so erfassen, dass die Linien demnächst auch in der ÖPNV-Karte erscheinen können. Bislang sind 1) manche Haltestellen nach dem alten Schema „Haltestellenpunkt neben der Straße“ vorhanden 2) manche Haltestellen überhaupt nicht erfasst 3) bei dem o.g. Beispiel habe ich mich bemüht, das neue, gültige Schema umzusetzen: ** stop_position auf der Fahrbahn ** platform auf dem Gehweg ** Relation die beide vorgenannten Elemente erfasst Ich würde gern alle Haltestellen wie Nummer 3 auf den neuesten Stand bringen. Mache ich das richtig so? Wenn ich in der Relation den/die Betreiber angebe, wie trenne ich zwei Namen von Betreibern? „CeBus; BürgerBus Eschede e.V.“ mit Semikolon? Vielen Dank Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Echtzeit-Tracker für Bahn- und Busverbindungen
Hallo, zur Info. Über XING bin ich auf den Artikel in Die Welt gestoßen. http://www.xing-news.com/reader/news/articles/64687 Unter http://tracker.geops.ch kann man die Bahn- und Buslinien in Echtzeit verfolgen. Die Karten sind von OpenStreetMap und der Bus fährt sogar, wenn die Route in OSM noch nicht erfasst ist. :-) Viele Grüße Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fußgänger-Diskriminierung?
On 04/16/2015 04:27 PM, Volker Schmidt wrote: wenn man als Fußgänger nicht an jeder Stelle die Straße überqueren kann Wenn mich nicht alles täuscht, gilt das für viele Gehwege, Mann kann man die Straße als Fußgänger nur dann einfach überqueren, wenn kein geeigneter Fußgängerübergang in der Nähe ist (§ 25 StVO) Man *kann* trotzdem. Man muss es sich nur leisten können. Ich denke nicht das derartige juristische Spitzfindigkeiten das Mapping beeinflussen sollten. Es sollte schon eine bauliche Trennung geben und nicht nur ein juristisches Gebot den nahen Schutzweg zu verwenden. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Visueller Vergleich von Geometrien
Ich suche nach einer Webseite, die es mir erlaubt Geometries zeitlich, visuell zu vergleichen. Vorschläge/Ideen: a) GeoJSON Diffs auf GitHub: https://github.com/blog/1772-diffable-more-customizable-maps https://github.com/benbalter/geojson-diff Der Stand zu einem bestimmten Zeitpunkt lässt sich mit der Overpass API date Query abfragen [1]. In Overpass Turbo als GeoJSON exportieren oder per osmtogeojson konvertieren: https://github.com/tyrasd/osmtogeojson b) adiff + Achavi Beispiel Änderungen an Umweltzonen seit 01.02. als Overpass API adiff Abfrage (abgewandelt aus Deiner Abfrage [2]): http://overpass-turbo.eu/s/7QE XML Daten speichern und per DragDrop oder url Parameter in Achavi visualisieren: http://overpass-api.de/achavi/?url=http://norbertrenner.de/share/umweltzonen.xml.gz Die vorherige Version wird erst ab Zoom 14, geänderte Knoten erst ab Zoom 16 angezeigt. Momentan hat die Overpass Attic Datenbank eine Inkonsistenz, deshalb kann es zu Way x cannot be expanded Fehlern kommen. Gruß, Norbert [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Attic_data_.28.22date.22.29 [2] https://bitbucket.org/tbsprs/umweltzonendatabaseapi/src/35615dfbb97bf6b24a7a874a38dca8409eed725c/commands/overpass-query.txt?at=master ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update of german Aral petrol stations
On 02/12/2015 05:24 PM, Knut Büscher wrote: Die Namen würde ich so wie unten im Beispiel gelistet übernehmen, da dies die vom Unternehmen geführten Bezeichnungen sind. Ein exakterer Name ist wohl nicht zu finden. Alternativ könnte für alle z.B. name=Aral Tankstelle vergeben werden, was sich für mich aber nach Informationsverlust anfühlt. Die offiziellen Namen sind vielleicht im Firmenbuch interessant, aber was braucht man die Gesellschaftsform in OSM? Ebenso ist der Zusatz Tankstelle vollkommen unnötig, wenn das Ding mit amenity=fuel eingetragen ist. Das kann ja auch kein normaler Mapper mehr nachvollziehen. Wenn draußen Aral draufsteht, dann reicht Aral als Name für OSM doch aus. Das ist zugegeben weniger Information, aber ob es ein Verlust ist, wag' ich stark zu bezweifeln. lg, Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieder einmal lcn Sammelrelationen
Zumindest im Bodenseekreis [1] sind das nicht nur allgemeine Richtungsweiser, sondern es sind konkrete, für Radfahrer besonders geeignete Verbindungen ausgeschildert, mit kleinen Richtungspfeilen an jeder Abzweigung [2]. Ich denke, der Bicycling Layer bei Google Maps [3] zeigt genau dieses ausgeschilderte Netz. Eine Knoten-Nummerierung oder Abschnitts-Bezeichnung - abgesehen von den Richtungs-/Zielangaben - gibt es aber nicht. Gruß, Norbert [1] http://www.bodenseekreis.de/landkreis-tourismus/radeln/radwege.html [2] https://wiki.openstreetmap.org/wiki/File:Richtungsanzeiger_BW.jpg [3] https://www.google.de/maps/@47.737923,9.349384,12z/data=!5m1!1e3 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Entfernung in Fuß?
Hallo, am 28.12.2014 21:39 schrieb Johannes: Wo kann man wieder Meter einstellen? Rechtsklick in das Anzeigefeld, Metric wählen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
On 12/19/2014 09:31 AM, Martin Vonwald wrote: Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich überlegen, da es nicht nur die Information liefert, dass das Geschwindigkeitslimit variabel ist, sondern zusätzlich: * das höchste mögliche(!) Geschwindigkeitslimit * den Grund(!) für das variable Limit Ok, der Grund steht zumindest in AT manchmal dabei, zumindest beim IGL. Aber in den anderen Fällen und vor allem bei der Maximalgeschwindigkeit die angezeigt werden kann, kann ich mir als normaler Mapper, der selten Autobahnen mapped, eigentlich nicht erklären, wo die Daten herkommen sollen. Werden da dann Verordnungstexte in OSM eingepflegt oder wie kann ich als Gelegenheitsmapper auf einer Autobahn feststellen, was denn hier die richtige Geschwindigkeit ist? Ich kann mich nämlich nicht dran erinnern in letzter Zeit noch irgendwo Stahlschilder neben Signalanlagen gesehen zu haben. Ich versteh den Grund warum die Daten drin sein sollen, aber für mich schaut das derzeit so aus, als wären das Daten, die ein Mapper vor Ort nicht mehr einfach nachvollziehen kann. Das macht mir zumindest etwas Bauchweh. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Talk-at] maxspeed=signals vs. maxspeed:variable=yes + maxspeed=x
On 12/19/2014 04:47 PM, Andreas Neumann wrote: On 19.12.2014 12:03, Norbert Wenzel wrote: On 12/19/2014 09:31 AM, Martin Vonwald wrote: Meiner Meinung nach ist maxspeed:variable dem Tag maxspeed=signals deutlich überlegen, da es nicht nur die Information liefert, dass das Geschwindigkeitslimit variabel ist, sondern zusätzlich: * das höchste mögliche(!) Geschwindigkeitslimit * den Grund(!) für das variable Limit Ich versteh den Grund warum die Daten drin sein sollen, aber für mich schaut das derzeit so aus, als wären das Daten, die ein Mapper vor Ort nicht mehr einfach nachvollziehen kann. Das macht mir zumindest etwas Bauchweh. Ich mappe immer maxspeed=Maximale Geschwindigkeit, source:maxspeed=signal, bzw. nutze seit kurzer Zeit auch das angesprochene maxspeed:variable=yes Ich akzeptier dass es genug Leute gibt die das mappen können auch wenn es keine einfachen Quellen dafür gibt, die ein Mapper so schnell mal vor Ort kontrollieren kann (zumindest nicht bei einem einzelnen Besuch). Ich versteh nur noch immer nicht warum maxspeed= auf eine maximal erlaubte Geschwindigkeit gesetzt wird. Das macht Sinn wenn wir davon ausgehen, dass diese Drosselung nur selten aktiv ist. Die in AT beliebten IGL Zonen (Immissionsschutzgesetz Luft) führen allerdings dazu, dass zwar theoretisch 130 erlaubt ist, praktisch aber nur 100 oder gar 80. Und zwar an deutlich mehr Tagen, als dort die maximal erlaubten 130 gefahren werden dürfen. Daher würd ich dafür plädieren, dass - wenn wir schon Daten erfassen, die nur ortskundige Mapper aufgrund der wiederholten Beobachtung schließen können (die Begrenzung hier zeigt nie mehr als x an) - wir gleich die Geschwindigkeit erfassen die meistens gilt. Denn bei den von mir genannten Beispielen bringt die Erfassung der Maximalgeschwindigkeit genau keinen Mehrwert, wenn sie ohnehin meistens nicht zutrifft. Ich halte das erfassen von maxspeed= bei gleichzeitiger Signalanlage hier also im Allgemeinen für ein Vortäuschen einer Objektivität, die nicht vorhanden ist. Und wenn ohnehin nur empirisch erfasste Werte eingetragen werden, dann sollten wir die als solche kennzeichnen. Das ist bei den von dir beschriebenen Tunneln dann der Wert den du derzeit als maxspeed=* einträgst und bei den von mir beschriebenen IGL Zonen halt dann die Beschränkung, weil die einfach öfter aktiv ist nicht. @Norbert: Wer als Nutzer ein Traffic-basiertes Routing wünscht, greift selten auf statische Daten, wie OSM zurück, sondern nutzt heutzutage Community-basierte Router, wie Waze. Ich versteh nicht ganz was du mir damit sagen willst, hab aber den Eindruck es ist für die Diskussion hier nicht wirklich wichtig. Korrigier mich bitte falls ich das falsch seh, ansonsten können wir das gern direkt per Mail klären, auf was sich die Antwort bezogen hat. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Copyright-Frage: Bekanntmachung einer Verordnung des Landkreises
Hallo, am 23.11.2014 15:06 schrieb Mark Obrembalski: Jedenfalls in Fällen wie hier, wo sich die Grenze gerade aus der Darstellung in Kartenform ergibt, halte ich das für unproblematisch. Ohne die Angabe des Grenzverlaufs hat die ganze Verordnung keinen Sinn, so dass sie wohl dazugehören muss. Was zur Verordnung gehört, ist nach § 5 Abs. 1 UrhG urheberrechtsfrei. Den Grenzverlauf darf man also übernehmen und die zugrundeliegende LGN-Karte zur Orientierung benutzen. Problematisch wäre es hingegen, außer dem Grenzverlauf auch noch Elemente der zugrundeliegenden Karte zu übernehmen. Aber das hast Du der Frage nach ja nicht vor. Genau so sehe ich das auch. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)
On 11/08/2014 05:03 PM, Falk Zscheile wrote: Das stellt die beauftragte Firma dann so dar, als ob das Ministerium zwei Einträge in der Datenbank wünscht, [...] Aber selbst wenn es wirklich so wäre: Wünschen dürfen sich alle Ministerien, aller Staaten was auch immer sie wollen, aber Anspruch auf Erfüllung hat halt ein Ministerium genauso viel wie jede andere an OSM beteiligte Person auch. Wenn die sich was wirklich wünschen bleibt ihnen entweder der Versuch ernsthaft mit den beteiligten Leuten zu reden und das irgendwie zu klären oder sie können versuchen es per Gesetz zu lösen. Ich bezweifel aber, dass es ein wir brauchen 2 Nodes wegen der Emailadresse-Gesetz jemals geben wird. Selbst wenn man durchaus pessimistisch sein sollte was Partikularinteressen in der Gesetzgebung angeht. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche OSM-Vertretung sinnvoll?
Hallo Markus, am 28.10.2014 07:26 schrieb Markus: Norbert schreibt von beabsichtiger Selbstauflösung. Bitte die Worte im Zusammenhang belassen. Ich schrieb: „Wenn man derzeit Osmf-talk liest, könnte man die beabsichtigte Selbstauflösung vermuten.“ Das zeigt schon, wie sinnvoll zusammenfassende Darstellungen kritisch werdender Konflikte sind. Der Teufel steckt oft im Detail, wie Du es in Deiner Berufstätigkeit sicher ständig erlebst. Also kommt man nicht daran vorbei, sich die Primärquellen anzutun - besonders schlimm, wenn man kein englischer Muttersprachler ist oder vergleichbare Kenntnis und Praxis hat. Was man aus der aktuellen Situation für eine DE-Vertretung lernen kann: Wo Menschen sind, da menschelt’s. Wenn man Unstimmigkeiten nicht frühzeitig bearbeitet, wachsen sie zu Konflikten aus, die sich irgendwann einen Anlass für eine Zündung suchen. Dann siehst du plötzlich eine Eigendynamik, die der Vernunft kaum noch zugänglich ist. Das Ergebnis ist Krieg oder doch noch die Einsicht, dass es keinen Sinn macht, ständig die Köpfe aneinander zu schlagen. Also nichts Besonderes im OSMF-Board, es toben die selben Prozesse, wie in vielen anderen Organisationen, Betrieben, Gruppen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche OSM-Vertretung sinnvoll?
Hallo, am 27.10.2014 01:51 schrieb Johann H. Addicks: Ich habe gerade Schwierigkeiten mich zu entscheiden, welches Szenario wir gerade haben und was wir anstreben sollten. Der Blick zu Wikimedia/Wikipedia sagt mir, dass auch ein irgendwie eigenen Verein nicht frei von Konfliktpotential ist. Soisses - natürlich kracht es auch bei OSM. Wenn man derzeit Osmf-talk liest, könnte man die beabsichtigte Selbstauflösung vermuten. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf der FOSDEM?
On 10/02/2014 09:59 AM, Martin Hammitzsch wrote: Für den Geospatial DevRoom gibt es die Idee die verschiedenen Communities über POCs einzubeziehen. Welche Ansprechpartner würdet Ihr für die OSM Community empfehlen? In dem unten zitierten Link von Jo steht, dass bei den Devroom Organisatoren bereits mit Gael MUSQUET ein Mitglied der französischen OSM Community dabei ist der sich auch schon mal um den OSM Stand aufd er FOSDEM gekümmert hat. Damit wär das von OSM Seite wohl in guten Händen, oder? On 10/02/2014 08:46 AM, Jo wrote: Hier ist etwas mehr information zu finden über das Devroom: https://titanpad.com/GptTJKIKJB Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf der FOSDEM?
On 09/29/2014 08:45 AM, Lars Lingner wrote: ich habe gerade den FOSDEM-Aufruf [1] gesehen. Sowohl für einen Stand als auch für Vorträge kann sich noch beworben werden. Im Wiki [2] ist noch keine Aktivität zu sehen. Veranstaltungsort ist Brüssel, Zeit: 31.01/1.2.2015 Gab es dieses Jahr einen Stand? Lohnt sich die FOSDEM für OSM? Ja, es gab die letzten Jahre immer einen Stand, auch heuer. Der wurde glaub ich immer von Brüsseler Mappern betreut, wobei vor 3 oder 4 Jahren glaub ich auch OSMer aus DE dabei waren. Vorträge über OSM wären mir allerdings nicht besonders aufgefallen auf der FOSDEM, aber es kann sein, dass ich die übersehen hab in der Menge. Ob sich das lohnt kann ich nicht beurteilen, ich hab den Stand immer nur kurz besucht, aber da wäre vielleicht die internationale Liste besser um die bisherigen Organisatoren zu befragen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unbenutzbare Wanderwege - was tun?
On 09/25/2014 01:03 PM, thsMD wrote: Noch eine Zusatzfrage: Welche Attribute verwendet man, wenn Radfahren auf dem Weg explizit nicht verboten ist (kein Schild), ich aber der Meinung bin, dass dort keiner mit seinem Rad langfahren möchte? Da ich von entsprechendem Gelände ausgeh würd ich mtb:scale[0] setzen. Praktisch unfahrbar bedeutet hier 6, wobei die Grenze für unfahrbar wirklich sehr hoch liegt. Norbert [0] http://wiki.openstreetmap.org/wiki/DE:Key:mtb:scale ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Account für Workshop
Hallo Markus, am 22.09.2014 11:30 schrieb Markus: Danke für die Tips! Habe sie hier zusammengefasst: https://wiki.openstreetmap.org/wiki/DE:JOSM/Guide/Gruppenkonto Weer sagt denn, dass man mit einer Wegwerfadresse keine Bestätigungsmail empfangen kann? Genau dafür sind sie doch gedacht. Sie haben lediglich eine Beschränkte Lebensdauer. Schwierigkeiten: 1. Die Anmeldedaten sind nicht in der Bestätigungsmail, müssen also aus dem Profil abgeschrieben und händisch irgendwo gespeichert werden, damit man sie weitergeben kann. An ein Verbreiten der Anmeldedaten hätte ich nie gedacht. Ein paar Vorführgeräte oder den eigenen Schlepptop für den externen Gebrauch (zum Schutz des eigentlichen Kontos) damit auszustatten, ist etwas anderes. 2. Wenn das Konto nicht gelöscht werden kann, kann es von jedermann weiter und anonym verwendet werden. Nein, wenn man nach der Aktion das Passwort ändert. 3. ich vermute, der Anmeldeprozess entspricht nicht dem BDSG: über Alias und Weiterleitungen können Mailadressen verknüpft und Persönlichkeitsprofile zusammengefügt werden ;-) Wer weiß denn von dem Alias/der Weiterleitung UND der Anmeldung? Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Account für Workshop
Hallo Markus, am 21.09.2014 17:59 schrieb Markus: Wie kann man einen temporären OSM-Account erstellen? beispielsweise für einen Workshop? Gar nicht. Accounts müssen dauerhaft sein, weil sie mit den Edits verknüpft sind. Es ist aber kein Problem, für solche Aktivitäten ein zweites Konto zu halten. Sinnvoll ist diese Trennung allemal. Abmelden, Konto anlegen, Workshop durchführen, abmelden, mit Hauptkonto anmelden. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Account für Workshop
Hallo Markus, am 21.09.2014 20:26 schrieb Markus: Also eine passende wegwerf-email besorgt und damit registriert. Aber OSM will mir eine Bestätigungsmail schicken - und die kommt bei mir natürlich nicht an... Wieso natürlich? Wenn Du beim Anbieter keine Weiterleitung auf Deine Adresse eingerichtet hast, musst Du die Nachricht auf seiner Website abholen. Wegwerfadressen sind übrigens nicht gut, weil sie die Benachrichtigungsfunktion von OSM (User zu User) unmöglich machen. Was nun? Das Problem hatte ich nicht, weil ich unter eigener Domain viele E-Mail-Konten einrichten kann. Vermutlich kannst Du Dich bei OSM einloggen, um die E-Mail-Adresse zu ändern - wäre ja blöd, nur wegen eines Tippfehlers einen Account zu verbrauchen. Einige Kost-Nix-Anbieter haben eine Alias-Funktion, auch GMX? Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Account für Workshop
am 21.09.2014 21:07 schrieb Norbert Kück: Wegwerfadressen sind übrigens nicht gut, weil sie die Benachrichtigungsfunktion von OSM (User zu User) unmöglich machen. Genauer: Die Benachrichtigung, dass Dir jemand geschrieben hat. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wettbewerb für eine OSM-Werbeanzeige
Hallo, am 05.09.2014 18:44 schrieb Florian Groß: EinkaufAktuell Ist das nicht dieser Plastikmüll, den man immer erst auspacken muss bevor er ins Altpapier kommt? Bei den gelben Mülleimern, die täglich geleert werden und überall herumstehen, ist das unnötig ;) Mit einem Schild Keine Werbung am Briefkasten hat man diese Sorgen nicht. Folge: Ich hatte zuerst Mühe zu verstehen, um welches Medium es geht. :-)) Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kontaktadresse vs. Objektadresse
On 08/18/2014 10:18 PM, Andreas Neumann wrote: beim mappen einer Universität ist mir aufgefallen, dass schwierig ist die Kontaktadresse zu hinterlegen. Meist ist dies eine Postfachadresse (was vom addr:*-Schema nicht abgedeckt wird). Da Postfächer ohnehin nicht automatisch validiert werden können, wie normale Adressen würd ich vorschlagen das einfach unter contact:addr:full zu schreiben. Dann ist es für Menschen auswertbar hinterlegt und könnte sogar direkt als Adressinformation auf Briefe übernommen werden. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Radweit routen löschen? (WAS: Radweit)
On 08/08/2014 11:44 PM, Henning Scholland wrote: damals vor vielen Jahren als das mit den Routenrelationen gerade begann hab ich auch ein paar Radweitstrecken eingetragen. Damals als network=radweit. Ob das jetzt immer noch so drin ist oder ob die jemand umgetaggt hat oder bereits gelöscht hat weiß ich nicht. Aber sowas in der Art halte ich für notwendig. Klar ist: Es braucht einen Unterschied zwischen dem herkömmlichen *cn. Aber nur unter der Annahme dass wirklich jeder jede beliebige Strecke eintragen können soll. Ob das jetzt Radweit ist oder eben meine eigene Lieblingsstrecke für Dreiräder mit Hartgummireifen. Ich denke dass wir eine Grenze ziehen müssen, da die Server sonst für diverese Routensammlungen als günstiger Hostingprovider missbraucht werden. Und die physische Ausschilderung ist imo ein gutes Kriterium, das objektiv und für jeden leicht überprüfbar ist. Wenn wir hingegen Qualitätskriterien verwenden, dann werden wir vermutlich so viele Meinungen wie User zu jeder beliebigen Strecke bekommen und uns dann erst auf nichts einigen können. Ich behaupte jede eingetragene Strecke wird für irgendwen irgendwann nützlich (gewesen) sein. Die Frage ist ob sie deshalb in der OSM Datenbank gehosted werden muss, was ich verneinen würde. Und ja, ich würde das ganze auch bei *way=proposed so sehen. Norbert PS: Und bitte, keine Analogien wieso wir dann Fernbuslinien auch löschen müssten. Das hat Frederik Ramm bereits beantwortet, dem würd ich mich genau so anschließen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Veggiekarte.de
Hallo, am 10.08.2014 18:51 schrieb Alexander Lehner: Bitte noch Permalink einfügen, damit man sie gezielt weitergeben kann. Schon drin, siehe Adresszeile. Extremst sinnvoll. Es waere nicht das erste Mappertreffen, wo ein vegi-Mapper verzweifelt Alternativen vorschlagen moechte, wenn spaet abends Futter gebraucht wird Das kann gründlich schief gehen: Wenn der vegi-Mapper sich z.B. hier auf die Datenbasis verlässt, wird es extrem schwierig: http://www.veggiekarte.de/#18/53.07812/8.80108 :-)) Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Veggiekarte.de
Hallo, am 10.08.2014 21:19 schrieb 715371: Speisekarte aber deutlich mehr Auszeichnungen bekommen. Und Gerichte: Von 9 Würsten ist dann nur noch eine vegan. Ich gestehe, die Speisekarte nicht gelesen zu haben - ich kenne den Laden. Man darf zweifeln, ob sich echte Veganer wirklich wohl fühlen, wenn sie zwischen diesen Fleischmassen ihre verirrte Veganwurst suchen sollen. :-) Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was tu, wenn ein user permanent Daten zerstört?
Hallo, am 30.07.2014 11:31 schrieb 715371: Dem User Ulamm musste ich auch schon hinterher wischen und war froh, die entsprechenden Geometrien (Kulturdenkmale) im Originalzustand zu bevorraten. Dabei hat er Geometrien nicht nur verformt, sondern auch zerteilt - ungünstig bei Flächen. Ich bin nicht bereit mit diesem user weiterhin zu kommunizieren, da er nicht zu einer normalen Kommunikation in der Lage zu sein scheint. Dinge wie andere permanent zu unterbrechen, vom Thema abzuschweifen und andere nicht zu Wort kommen lassen möchte ich nicht tolerieren - vor dem Hintergrund, dass sich diese Person als Mapper auch nicht anders verhält. Ja, so ist er. Ulamm ist unter diesem Namen auch in der Wikipeda tätig und für dieses Verhalten bekannt. Er ist nicht böswillig, aber er tut sich schwer, Argumente anderer und Regeln zu akzeptieren - leider ein anstrengender Umgang. Er ist fleißig, was in diesem Zusammenhang manchmal ein Nachteil ist. Ulamm nennt sich Hobbygeograf und zeichnet teils recht umfängliche Karten. Kann es sein, dass ihm der Unterschied zwischen OSM und seiner Malerei nicht klar ist? Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Was tu, wenn ein user permanent Daten zerstört?
Hallo, am 30.07.2014 15:04 schrieb 715371: Wie seid Ihr damit in der Wikipedia umgegangen? Ich vermute mal, dass es einfach eine nicht endende Diskussion oder einen edit-war gab. Gibt - nicht gab. Du triffst ihn immer wieder und die Diskussionen sind meist recht anstrengend. Mag sein, dass das in der Wikipedia noch verkraftbar ist. In der OSM gibt es ja immer das Problem, dass an einem Knoten mehr Objekte hängen, als man erwarten würde und sich dann erst einmal umschauen muss. Im Prinzip kann man dort tatsächlich leichter etwas zurück drehen, aber das hat durch bestimmte Regeln seine Grenzen - zu leicht bist Du selbst der Vandale. Andere Mapper-Neulinge fragen am Anfang wenigstens nach warum etwas so Er ist seit 4 1/2 Jahren dabei. :-( ulamm selbst hat mir gesagt, dass er Karte(n) von Bremen gezeichnet hätte und dass das Erfassen der Fahrradinfrastruktur in Bremen ja vernachlässigt sei. Wahrscheinlich hat er eben solche Fahrradinfrastrukturkarten von Bremen gezeichnet und versucht nun das was er da gemalt hat in die OSM zu pressen. Seine Ortskunde über die Fahrradinfrastruktur ist sehr umfangreich, was für die OSM hätte hilfreich sein können. Soisses! http://www.radweit.de/ Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wegenamen in Kleingärten
On 05/19/2014 02:35 AM, Wolfgang Hinsch wrote: Am Sonntag, den 18.05.2014, 22:03 +0200 schrieb Mark Obrembalski: On 18.05.2014 21:17, Johannes wrote: Sehe ich genauso. Wenn etwas keinen amtlichen Namen hat gehört es in loc_name rein und name entfernt. Quatsch! Kein Laden, keine Kneipe hat einen amtlichen Namen. Dann mach mal einen Laden ode eine Kneipe auf. Du wirst dich wundern, in wie viele Verzeichnisse, Anmeldungen, Lizenzen, Genehmigungen ... du den Namen eintragen musst. Aber ich denke worauf die Meldung abgezielt hat, war dass der offizielle Name wie Mustermann Gastronomie KG nicht unbedingt der Name ist, der an der Tür von Mäxchens Cafe steht und auch nicht der ist, den wir in OSM üblicherweise unter name=* eintragen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Planetarium
Hallo, am 23.02.2014 08:40 schrieb Georg Feddern: und wenn sich meine Erinnerung (und Wikipedia) nicht irrt, dann hat genau das Deutsche Museum ein Planetarium. Also ein Technik-Museum mit Planetarium. Wie erfasst man das dann? Mal wieder das Grundproblem: Ein Objekt mit mehreren Eigenschaften ... Nö. Das Museum HAT ein Planetarium, aber es IST keins. Niemand kartiert einen ganzen Supermarkt als Eingang. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Hallo, am 11.01.2014 17:34 schrieb cracklinrain: ich frage mich schon seit längerem was der Gebäudeweg in OSM darstellt und kann mich nicht erinnern im Wiki schon einmal etwas dazu gelesen zu haben. Hausumringe, die Außenlinie des Grundrisses an der Geländeoberkante sind die Geometrien, die in herkömmlichen Karten und Plänen enthalten sind. Und OSM sollte sie m. E. ebenso verwenden. Bei nicht ausreichend kritischem Umgang mit Luftbildern (die Gefahr ist besonders groß bei der Arbeit am 3D-Modell) kommt es leicht zu einer Verfälschung der Grundrisse. Luftbild-Mapping zeichnet Dächer. Anpassung an den Grundriss ist schwierig bis unmöglich. Folgende Fehlermöglichkeiten bieten sich an: * Falsche Lage. Luftbilder sind systematisch weniger korrekt und weniger präzise als die Ergebnisse der (amtlichen) Vermessung am Boden. o Luftbilder sind oft Schrägbilder. Manchmal kann man keine Grundlinie erkennen oder die Anpassung wird einfach unterlassen. o Luftbilder werden nachräglich entzerrt und dann georeferenziert. Damit treiben die Katasterverwaltungen einen Riesenaufwand, leistet sich Bing diesen hohen Aufwand? * Zu große Geometrie durch o Dachüberstände o perspektivische Verzeichnung (Projektion) - umso größer, je größer der Abstand Boden-Dachfläche und je geringer die Flughöhe. Im Wiki (DE:Building) ist - m.E. völlig zutreffend - zu lesen: Wenn möglich sollte der gezeichnete Umriss der Außenwand am Boden folgen, also z.B. Dachüberstände aussparen. Aber wir können ja auch beschließen, dass OSM nicht den Anspruch auf möglichst richtige Kartografie hat. Dachflächen sind gut für spezielle Anwendungen. Auf einer Landkarte oder in einem Stadtplan würde ich sie nicht erwarten. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Hallo, am 11.01.2014 19:59 schrieb Florian Lohoff: Leider sind aber auch zumindest hier in NRW die ALK Daten teilweise total daneben. Blindes Übernehmen von Daten lehne ich ab - auch bei ALK. Wenn ich Unstimmigkeiten sehe sage ich nicht alles Sch..., sondern spreche die Quelle an. Das geht hier gut, weil es um Einzelobjekte geht und nicht um flächendeckendes Abmalen. ALK und Luftbilder haben einen gravierenden Unterschied: Vermessungsdaten sind hinreichend genau und richtig, wenn nach dem Stand der Technik gearbeitet wird. Luftbilder haben systematische Nachteile, die durch die Nachbearbeitung nicht oder nur unvollkommen ausgeglichen werden können. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezialist für Satz und Druck gesucht
Hallo, am 04.01.2014 07:33 schrieb Markus: Booklet wird maximal 92 x 92 x 13 mm groß Schrift und Tabellen funktionieren so nicht... .odt (in Word geöffnet) und .pdf erwecken den Eindruck, als wäre der Entwurf im Format DIN A4 gemacht worden. So ist das Scheitern programmiert. Im Entwurf muss bereits die gewünschte Seitengröße (9,2 x 9,2 cm) festgelegt sein. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Name-Tags unterdrücken?
Hallo, diese Beschriftung hat mich irritiert und das könnte anderen wohl auch so gehen: http://osm.org/go/0G1LEIV4~?m= Nachgeforscht: Sie stammt von der Wahlkreisrelation Bremen II (ID 3133461). Frage: Muss das sein? Kann man die sinnfreie Anzeige der Namen solcher Gebilde nicht abstellen? Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wie .json, .geojson in JOSM schnell öffnen / importieren
Hallo, am 28.11.2013 12:22 schrieb tshrub: Sonst müsste Leaflet, das sich eher auf JSON eingestellt hat, OSM lernen, was aber aufwendiger ist. Well! Vielleicht gibts ja mal n PlugIn oder so ... In meiner vorigen Nachricht hatte ich eine Zeile zu wenig zitiert. Daher war die Antwort unvollständig. Es gibt bereits Plugins z.B. https://github.com/tyrasd/osmtogeojson, das im Rahmen von http://overpass-turbo.eu entwickelt wurde und auch dort eingesetzt wird. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wie .json, .geojson in JOSM schnell öffnen / importieren
Hallo, am 28.11.2013 12:22 schrieb tshrub: Sonst müsste Leaflet, das sich eher auf JSON eingestellt hat, OSM lernen, was aber aufwendiger ist. Leaflet kann OSM. Beispiel: http://unterkunftskarte.de Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wie .json, .geojson in JOSM schnell öffnen / importieren
Hallo, am 27.11.2013 18:48 schrieb tshrub: Zumindest in der mit JOSM selbst gepseicherten Struktur sollte .json, .geojson doch unter Datei öffnen angeboten sein? Dass JOSM den eigenen GeoJSON-Export nicht wieder einlesen mag, kann ich gut verstehen. Der Export enthält nämlich keine Meta-Informationen (Version, Timestamp, User ...) die beim Hochladen nach OSM benötigt werden. Darin besteht aber der Hauptzweck. Für bestimmte Fälle erstelle ich (z.B. nicht in OSM enthaltene) Daten mit JOSM, um sie als GeoJSON für Leflet-Karten zu verwenden. Zusätzlich (vor dem GeoJSON-Export) speichere ich meine Daten als .osm, da ich sie in diesem Format wieder in JOSM laden und bearbeiten kann. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gaskavernen
Hallo, am 22.11.2013 15:35 schrieb Peter Wendorff: wobei oft natürliche Hohlräume für die eigentliche Speicherung genutzt werden Natürliche Hohlräume zur Gaslagerung - wo? Da bin ich einfach nur neugierig. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gaskavernen
Hallo, am 22.11.2013 16:11 schrieb Peter Wendorff: (wobei ich mir nicht sicher bin, evtl. werden die Porenspeicher dann auch nicht mehr als Kavernenspeicher bezeichnet). Genau das ist der Punkt. Porenspeicher sind KEINE Kavernen. Zum Begriff siehe https://de.wikipedia.org/wiki/Kaverne. Das in in der Mail verlinkte Kavernenfeld nutzt einen Salzstock. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stellenausschreibung
Hallo, am 12.11.2013 19:42 schrieb Markus: Hier als Link: http://www.bkg.bund.de/nn_147094/DE/Aktu/OffeneStellen/stellen__node.html__nnn=true unter GI 8 / 15-13 EG 11 Die Stellen sind befristet -länger als zwei (konkret: knapp 4) Jahre. Es kann sich daher nur um eine Befristung mit Sachgrund handeln. (http://www.gesetze-im-internet.de/tzbfg/__14.html) Es wäre gut, den Sachgrund zu kennen und ggf. prüfen zu lassen, wenn sich nicht im Laufe der Zeit eine Anschlussbeschäftigung findet. Die Stellen sind nicht EG 11 ausgeschrieben, sondern BIS ZU EG 11. Wäre gut zu wissen, welche Voraussetzungen für welche Entgeltgruppe gelten. Ich finde diese Ausschreibung nicht besonders transparent. Zum Jahreswechsel soll die neue Entgeltordnung Bund in Kraft treten (Text mir noch nicht bekannt). Wenn die Tarifmerkmale nicht völlig anders sind als bei den Ländern, unterscheiden sich die Ing.-Stellen EG 10 und EG 11 nicht durch die Qualifikation des Stelleninhabers, sondern durch die Tätigkeit (Merkmal besondere Leistungen). Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amtliche Daten
Hallo, neue Argumente für den Vorrang der Schreibweise der Schildermaler gab es hier bisher nicht. Wurde alles schon x-mal geschrieben. Daher bleibe ich bei meiner Ansicht, dass es einen solchen Vorrang nicht geben kann. Wenn man den Prozess vom Beschluss über Straßennamen bis zum fertigen Schild analysiert, kann man gar nicht auf die Idee kommen, das Schild trage grundsätzlich die richtigere Schreibweise. Allerdings sind Fehler menschentypisch - das gilt sogar für OSMer. :-) Jeder Medienbruch und jede Schnittstelle zwischen beteiligten Dienststellen sind potentielle Fehlerquellen. Aber auch wenn in amtlichen Listen Fehler sind, werden sie dadurch nicht grundsätzlich falsch. Entgegen der hier geäußerten Meinung ist An'n Graaben, In'n Dörp und To'n Böversten Diekkampe falsch. Der korrekte Apostroph ’ ist Unicode U+2019. Das typographisch falsche Ersatzzeichen ' (Unicode U+0027) ist nur bei technischen Beschränkungen zu verwenden. Diese Beschränkungen gibt es Dank Unicode nicht - man muss nur wissen, wie man das Zeichen seiner Tastatur abringt, weil es kein Etikett hat. Zur Schreibweise in der amtlichen Liste siehe unten. Was nun zuletzt in der Diskussion heraus gearbeitet wurde, ist genau das, was ich anstrebe: Wenn wir freies WISSEN fördern wollen und nicht freie VERMUTUNG, sind wir in der Pflicht, Unstimmigkeiten und Widersprüche nicht nur zu dokumentieren, sondern auch deren Klärung anzustoßen. Dazu wird man alle beteiligten Dienststellen (in HB: Amt für Straßen und Verkehr, Landesamt für Geoinformation, Statistisches Landesamt) begrüßen müssen. Das ist möglicherweise kein einfacher, schneller Vorgang. Aber man kann etwas bewegen: Nach mehrfachem Bohren veröffentlicht das StaLa sogar die Straßenliste in Excel in monatlicher Folge. Vor einiger Zeit musste ich mit Verweis auf das Bremer Informationsfreiheitsgesetz etwas Druck machen, um sie als Einzelaktion zu erhalten. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amtliche Daten
Hallo, am 26.10.2013 10:51 schrieb cracklinrain: Bisher hast du vor mir die Position verteten, dass das was in der amtlichen Liste steht amtlich ist und in die OSM zu übernehmen ist - egal was vor Ort steht. Fehlinterpretation. Ich kenne seit langem einige Schwächen der StaLa-Liste. Dann versuche ich den Abgleich mit anderen Quellen (z.B. GeoInformation Bremen). Allerdings ist es wahr, dass ich den Straßenschildern das geringste Gewicht beimesse. Und nicht zu vergessen: Mancher Eintrag in OSM wurde falsch von den Straßenschildern abgelesen. (Was mir auffiel, habe ich natürlich berichtigt.) Leider bin nicht gleich zu Anfang auf die Idee gekommen, die Behörden mit den Differenzen zu befassen. Das ist aber strategisch der einzige Weg, widersprüchliche Datenlagen zu vermeiden. Das Argument mit den Suchenden zieht nicht, da sich heute viele Leute nicht mehr nach Straßenschildern orientieren. Navis werden gewöhnlich anders mit Daten gespeist. Wer Deinen Beitrag liest, könnte glauben, ich würde das Gehirn abschalten wenn ich irgendeinen Text aus amtlicher Quelle lese. Na danke! Ich denke, dass man die Argumente nicht weiter wiederholen muss. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amtliche Daten
am 26.10.2013 10:49 schrieb Martin Trautmann: Leider gilt das wohl nur für Bremen - oder wo findet man die Listen für Bremerhaven? Suchen auf bremerhaven.de. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] jetzt auch Bremen
Hallo, am 16.10.2013 09:12 schrieb gmbo: woher bekommt ihr die IDs für die Steine in Bremen? Die Quellen sind genannt auf http://wiki.openstreetmap.org/wiki/Stolpersteine und http://wiki.openstreetmap.org/wiki/Bremen_Todo Da muss man keine Liste für OSM doppeln. Die Wikipedia-Liste verlinkt ergänzend auf eine Karte, auf der man Steine in seiner Umgebung finden kann - die OSM-Basis zeigt, ob es da schon einen Eintrag gibt. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] jetzt auch Bremen
Hallo, am 16.10.2013 18:49 schrieb gmbo: die Seiten hatte ich mir angeschaut, nur finde ich in keiner der Listen IDs. Hier in Bochum hatte ich Kontakt mit den Verantwortlichen vom Stolpersteinprojekt und bekomme seittdem Infos für neue Steine auch schon bevor das Ganze irgendwann im Netz steht. So kann ich Jan dann so eine Liste zukommen lassen. Für Bremen muß da demnach auch eine solche Liste als csv-Datei generiert worden sein. Sorry, ich verstehe das Problem nicht. Es gibt eine von Wikipedia eingefädelte Kooperation mit dem Verein, der die wichtigsten Daten meist schon am Tag der Verlegung der Steine online stellt. Die ID ist verfügbar, auch wenn sie nicht in Listen offensichtlich ist. Bisher wurde die ID in der Wikipedia und von den Mappern als Teil des Links zur Datenbank verwendet. Jan ist zunächst vom örtlichen Wikipedia-Hauptakteur in dieser Sache versorgt worden und wird (wie, wird man noch klären) weiterhin aktuell versorgt werden. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] jetzt auch Bremen
Hallo, am 16.10.2013 22:26 schrieb gmbo: Das die Steine von einem Verantwortlichen direkt in Wikipedia eingetragen werden[...] Missverständnis. Die Initiative hat die Daten schnell auf der eigenen Webpräsenz online. Man darf sich auch die Frage stellen, wie viel administrativen Aufwand man sich und anderen zumuten will, ohne dass es eine Notwendigkeit gibt. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] jetzt auch Bremen
Hallo, am 02.10.2013 09:59 schrieb Jan Tappenbeck: auch für Bremen gibt es jetzt eine Auswertung: Prima, danke Jan! Anm.: leider fehlen da für die Eindeutigkeit im Namen bzw. memorial:name noch die geb. -Angaben. Das fehlt nicht wirklich. Ich möchte davon abraten die Geburtsnamen allein zum Zweck der Funktionsfähigkeit des Tools einzutragen. Gründe: 1. Es gibt derzeit in Bremen keine Steine mit Gleichheit von Vorname und Nachname. (Dank Datenbanktechnik würde das bei neuen Steinen auffallen.) 2. Der Geburtsname ist ungeeignet zur Herstellung der Eindeutigkeit. Die Methode funktioniert nur zufällig. Sie versagt systematisch bei männlichen Personen aus den betroffenen Generationen. Die IDs beziehen sich in Bremen auf die Steine. Eine schönere Eindeutigkeit kann man nicht haben. Wenn das Tool die Geburtsnamen ignoriert, wird sich die lange Liste der nicht in der Referenzliste gefundenen Stolpersteine vermutlich komplett auflösen. In Burglesum werden als Soll zwei Steine gezählt; das ist korrekt so: Martha Goldberg und Adolf Goldberg. In OSM eingetragen sind beide Steine. Frage: Warum wird Adolf Goldberg nicht gefunden? Dass Martha in der Liste der nicht in der Referenzliste gefundenen steckt, ist klar. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Owl API
Der Entwickler (Paweł) hat nen neuen Job angefangen und ist seither kaum mehr aktiv. [1][2] Potentielle Mitstreiter fanden wohl das Datenbankschema zu kompliziert, deshalb ist er dran erst mal das zu vereinfachen. [3] Gruß, Norbert [1] http://gis.19327.n5.nabble.com/Fixing-the-history-tab-tc5759340.html#a5759371 [2] https://github.com/ppawel [3] https://github.com/ppawel?tab=activity Am 10.09.2013 16:55, schrieb jotpe: Weiß jemand, ob an der owl API (Openstreetmap watch List) noch gearbeitet wird, und ob sie als chronik auf osm.org erscheinen soll? http://owl.apis.dev.openstreetmap.org/?lat=52.52082lon=13.4111zoom=17layers=M Gruß Johannes ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gibt OSM auch Daten über die Beitragenden heraus?
On 07/28/2013 01:08 AM, Mark Obrembalski wrote: On 27.07.2013 23:59, Norbert Wenzel wrote: In dem Fall bin ich für die Änderung, denn sie würde vermeiden, dass jemand durch die Wahl eines sprechenden Benutzernamens unwissentlich oder unbedacht persönliche Daten veröffentlicht. Das fällt aber schon unter allgemeine Lebensfähigkeit im Internet, dass man weiß, dass Accountnamen (zumindest halb)öffentlich sichtbar sind. Na ja, in vielen Fällen ist der Name ja nur für den Betreiber oder sonst einen kleineren Kreis von Beteiligten sichtbar. Im Fall von OSM kann er aber wirklich ziemlich direkt öffentlich werden. Bei näherer Überlegung finde ich aber tatsächlich, dass es nicht nötig ist, dass OSM deswegen irgendwelche eigenen Anonymisierungswerkzeuge anbietet. Es reicht sicher, wenn man bei der Anmeldung darauf hinweist, dass der gewählte Name veröffentlicht wird und man, wenn man anonym bleiben will, halt einen nichtssagenden Namen wählen sollte. Also meiner Meinung nach sollte man bei allen Accountnamen für Services in denen man irgendwas postet (Foren, Bewertungsportale, OSM) davon ausgehen, dass die Namen öffentlich sind. Normalerweise gibt's bei der Registrierung einen Hinweis wenn ein Feld nicht veröffentlicht wird. Aber ja, bei der Registrierung zum Usernamen den Text hinzuschreiben, dass dieser Name öffentlich ist und an alle in OSM eingetragenen Daten in die History gehängt wird, schadet sicher nicht. Die Leute, die man vor sich selbst beschützen muss, werden den ev. auch nicht lesen, aber man kann, wie ich vorher schon gesagt hab, nicht jedem Irrsinnigen helfen. Man kanns nur so gestalten, dass man die Info, wenn sie einen bei der Registrierung gerade interessiert, leicht findet. Norbert ___ 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?
Hallo, am 27.07.2013 11:38 schrieb Markus: PS: vermutlich ist direkter Maiverkehr nicht simpel zu lösen? Doch, es ist simpel - mit wenig serverseitiger Programmierung schaffen das auch einfache Mail-Formulare. Wikipedia macht das so, dass die Wiki-Mail gesendet wird, ohne das der Absender die Empfänger-Adresse erfährt, aber seinerseits seine eigene gespeicherte Adresse dem Empfänger offenbart wird. Damit ist dann Austausch abseits der Wiki-Technik möglich. Gruß nk ___ 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?
On 07/27/2013 02:00 PM, Mark Obrembalski wrote: Verstehe ich den Vorschlag richtig, dass der einzige in öffentlich zugänglichen Abfragen (planet file, Objektbrowser, Chronik, Abfragen über die diversen APIs etc.) erkennbare Unterschied darin bestünde, dass als Bearbeiter nicht mehr der vom jeweiligen Benutzer gewählte Name, sondern eine zufällig erzeugte, aber für jeden Benutzer feste Zeichenkette angezeigt würde? In dem Fall bin ich für die Änderung, denn sie würde vermeiden, dass jemand durch die Wahl eines sprechenden Benutzernamens unwissentlich oder unbedacht persönliche Daten veröffentlicht. Das fällt aber schon unter allgemeine Lebensfähigkeit im Internet, dass man weiß, dass Accountnamen (zumindest halb)öffentlich sichtbar sind. Wenn es daran schon scheitert, dann sollte einem der Vormund doch bitte gleich den Stecker zum Internet ziehen. Wenn man sich in einem beliebigen Internetprojekt seinen Realnamen gibt, aber gleichzeitig nicht will, dass jemand rausfindet wer man ist, dann ist das ähnlich intelligent wie seine Adresse an den Wohnungsschlüssel zu hängen, mit der Bitte der Finder möge ihn doch abgeben, oder den Pincode zur Bankkarte dazu zu schreiben. Wenn ich im Restaurantportal xy unter meinem Realnamen Restaurantbewertungen abgeb, dann kann auch jeder nachvollziehen wo ich war. Dasselbe ist, wenn ich im Urlaub die Pizzeria beim Hotel eintrage. Wenn der User schon zu dieser einfachen Schlussfolgerung nicht in der Lage ist, dann sollte man ihm tatsächlich den Internetstecker zu seiner eigenen Sicherheit ziehen. Norbert PS: Und wenn der User das nicht will, dann kann er ganz anonym immer noch das Add a note-Tool verwenden und dort schreiben, dass Lokal xy fehlt. Da weiß dann keiner mehr von wem das kommt und die NSA wird den User niemals nicht finden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Programm zur Überwachung von OSM-Relationen
- wie erkenne ich, dass ich die richtige Relation getroffen habe? wohl erst bei der nächsten Auswertung? Die Basisdaten sollten sofort ausgegeben werden. Stimmt, kann man nicht einsehen, man muss praktisch vorher schon wissen, welche Relationen man mit den Tags erwischt. Is ne gute Idee das anzuzeigen. Bei der Auswertung sieht man nur, wenn sich was geändert hat. Wenn sich nix geändert hat, sieht man nix :) Wenn ich das richtig sehe [1], wird aus der Eingabe eine Overpass Query generiert? (relation[operator=Schwäbischer Albverein][route=hiking];node(r)-.nodes;way(r);node(w););out meta; Die ließe sich mit Overpass Turbo verifizieren, den Link könnte man beim Anlegen erzeugen und ausgeben, z.B. (als Shortlink; bbox von mir manuell hinzu, da sonst zu viel für Browser): http://overpass-turbo.eu/s/BM Wenn die Eingabe tatsächlich eine Overpass Query erzeugt, könnte man die in einem Expertenmodus auch direkt eingeben (evtl. durch Regex validiert)? Mein Anwendungsfall wären Wander- und Rad-Routen (route=foot/hiking/bicycle) in einem bestimmten Gebiet, d.h. ich würde mir noch die Angabe einer Bounding Box wünschen. Mit UI wäre nett, könnte das aber erst mal auch direkt in der Query angeben. Gruß, Norbert [1] http://osmarelmon.won2.de/Feed?action=Schwaebischer%20Albverein ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dicht gemappte Gebiete
On 05/24/2013 09:28 PM, Jimmy_K wrote: Am 24.05.2013 15:01, schrieb Frederik Ramm: Hallo, wer haette das gedacht: http://fred.dev.openstreetmap.org/density/ unter den 208 z16-Metatiles (die haben rund 25km²) auf der Welt mit je mehr als 100.000 Nodes taucht Deutschland nur ein einziges Mal auf. Alles andere muessen also Datenimporte sein ;) Dass es oft Fälle sind, wo nichtmal die Hausnummern oder gar die Straßennamen getagged sind, zeigt wie wenig eine Statistik manchmal aussagt. Aber es gibt auch ehrliche Flächen. Österreich ist zwei Mal vertreten, während der erste Bezirk in Wien vermutlich viel vom Baumimport profitiert, ist z.B. Linz wirklich erarbeitet: http://www.openstreetmap.org/?box=yesbbox=14.2822265625,48.2831928954835,14.326171875,48.3124279040718 Der Baumimport mag hier eine Rolle spielen (Ring und Stadtpark) aber du tust dem Andreas K. unrecht was die Innenstadt angeht. Der hat mal als Sommerprojekt noch vor der Verfügbarkeit der Katasterbilder für Wien die Innenstadt um Häuser mit Hausnummern auf die gute altmodische Art erwandert. Auch sind überraschend viele Geschäfte und Cafes in den Einkaufsstraßen gemapped. Wenn das gezeichnete Rechteck dem gemessenen Tile entspricht fällt da auch ein großer Teil des 7ten Bezirk rein wo viele der Bäume in Innenhöfen stehen und daher großteils privat sind, d.h. auch nicht importiert wurden. Also ich würd mal davon ausgehen dass die importierten Bäume den Platz etwas nach oben geschoben haben aber mehr auch nicht. Zu behaupten Linz wäre erarbeitet und die Wiener Innenstadt ein Import wird der Datenqualität und aktiven Mapperanzahl dort absolut nicht gerecht. Norbert PS: Von mir selbst sind dort vielleicht eine handvoll Nodes, d.h. ich nehm mich da von den fleißigen Mappern ganz deutlich aus. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dicht gemappte Gebiete
On 05/25/2013 08:38 AM, Norbert Wenzel wrote: Zu behaupten Linz wäre erarbeitet und die Wiener Innenstadt ein Import wird der Datenqualität und aktiven Mapperanzahl dort absolut nicht gerecht. Nachtrag: Auf der Karte schaut Linz relativ gut gemapped, aber dünn aus. In den Daten hab ich gesehen dass wohl mit Abstand die meisten Nodes vom Taggen der einzelnen Parkplätze sind. Zugegeben, das ist wirklich Arbeit. Ich bin mir nicht sicher auf welcher Seite zur Grenze zum Wahnsinn die Arbeit liegt, aber Arbeit ist es auf jeden Fall. ;-) Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wikipedia - Tags
Hallo, am 28.04.2013 14:42 schrieb Jörg Frings-Fürst: beim bearbeiten ist mir bei der A1 nördlich nördlich des Dreiecks Vulkaneifel der Tag reg_name:wikipedia [1] aufgefallen. Sollte das nicht nur auf wikipedia lauten, zumal es einen Wikipediaartikel Eifelautobahn gibt? Die Verknüpfung mit der deutschsprachigen Wikipedia gelingt nur mit wikipedia:de=Artikel oder wikipedia=de:Artikel Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
On 03/18/2013 01:03 AM, Garry wrote: Die Straßenbahnstraße- und damit die über größere Abschnitte einheitlichen Tags - gibt es nicht. Wo möglich/finazierbar gibt man den Schienen einen eigenen Gleiskörper, [...] Ich wiederhole mich aber ich sags nochmal ganz deutlich. Es geht hier nicht um den Fall der baulichen Trennung, der ist absolut klar definiert. Wenn es *keinen* eigenen Gleiskörper gibt und die Schienen sich räumlich absolut nicht von der Fahrbahn für alle anderen Fahrzeuge unterscheiden macht es imo in einer geographischen Datenbank keinen Sinn diese Wege zu trennen. Ganz besonders dann nicht, wenn die einen Wege (in dem Fall Schienen) aus irgendeinem Grund lagegenauestens eingezeichnet werden und die anderen Wege nur als näherungsweise Ideallinie erfasst werden. Im Übrigen mag das mit den getrennten Gleiskörpern zwar auf viele Städte zutreffen, aber bei weitem nicht auf alle. Und wenn der Platz nicht da ist für eigene Spuren, dann teilt sich halt jeglicher Verkehr die eine Fahrbahn die vorhanden ist. Und da bin ich ganz stark der Meinung dass es, wenn es eben so ist, auch so abgebildet werden sollte. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
On 03/15/2013 09:20 PM, Martin Koppenhoefer wrote: Am 15. März 2013 09:49 schrieb Norbert Wenzel norbert.wenzel.li...@gmail.com: Natürlich kann ich alles einzelen eintragen, aber dann brauch ich irgendeine Art von Relation die mir eben sagt, dass all diese Einzelwege teil eines einzigen Verkehrswegs sind. Ansonsten bildet man damit vielleicht abstrakte Routinggraphen für einzelne Verkehrsteilnehmer ab, aber eben nicht die Realität, dass da eben exakt eine Straße ist. Das braucht nicht unbedingt eine Relation sein, es könnten z.B. auch Flächen für die Fahrbahn sein. Ja, Relation war als Ausdruck schlecht gewählt. Ich dachte eigentlich an eine Verbindung die besagt, dass diese Wege zusammen gehören. Das kann auch eine Fläche sein. Wobei natürlich die Relation (im Sinne von OSM) eine eindeutige und die am wenigstens rechenintensive Möglichkeit der Verbindung ist. Aber nicht die einzige, da hast du recht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
On 03/15/2013 09:41 PM, Martin Koppenhoefer wrote: Am 15. März 2013 15:18 schrieb Norbert Wenzel norbert.wenzel.li...@gmail.com: On 03/15/2013 02:32 PM, Andreas Neumann wrote: On 03/15/2013 02:09 PM, Norbert Wenzel wrote: Ja kann man, macht aber imo keinen Sinn es umzudrehen. Ich mein mit Straßenbeschreibung nicht unbedingt die PKW Straße sondern die umgangssprachliche Straße. D.h. den einen Way wo alles entlang geht mit dem Namen XY. wobei der in OSM nicht unbedingt nur ein way ist, sondern manchmal eben auch mehrere, z.B. wegen baulicher Trennung werden ways parallel geführt, sie werden wegen sich ändernden Attributen gesplittet, etc., d.h. was umgangssprachlich eine Straße ist, wird deshalb in OSM noch lange nicht als ein way gemappt. Das könnte man auch noch weiter spinnen, z.B. die Weinstraße (als touristische Route, umgangssprachlich eine Straße, etc.) Schon klar. Aber es braucht imo zwingend eine Möglichkeit diese beiden baulich getrennten Wege auf einen zu vereinen. Das sollte zumindest eine Relation sein, da das zusammenfinden ungefähr paralleler Ways außer rechenintensiv auch noch fehleranfällig ist. Relationen machen das Mapping aber (besonders für den von dir so oft beschworenen einfachen Mapper) kompliziert und fragil. Man könnte auch sagen um eine perfekte Detailkarte in z19+ zu erstellen erschwert man dadurch allen niedrigeren Zoomlevels das Arbeiten mit den Daten. Selbst getrennte Fahrtrichtungen am Gleis kann man ja dann nicht ohne Heuristik oder zusätzliche Datenstruktur zusammenfassen. Wenn ich hingegen nur ein Gleis mappe und dabei die Anzahl der Gleise in jede Fahrtrichtung angeb, hab ich das Problem nicht und kann bei Detailstufen halt von der einfachen Linie auf die Doppellinie wechseln. das kann man immer sagen, dass mehr Abstraktion besser sei, wobei es in der Praxis durch mehr Abstraktion praktisch immer komplexer und schwieriger zu verstehen und editieren wird. Z.B. auch Spuren einzeln zu mappen (mit entsprechenden tags, nicht highway) wäre für den gemeinen Mapper viel einfacher zu verstehen und umzusetzen als das mit Attributen zu tun (und auch lagegenauer). Aber mein Punkt ist nicht, dass das Erfassen einer perfekten Straße mit allen Spuren einfacher wird, sondern dass das Erfassen einer einfachen Straße einfacher wird bzw bleibt. D.h. der einfache Mapper zeichnet eine Linie und macht daraus highway=xy und der versierte Mapper verfeinert dann Spurtags. Andersrum kann ein Mapper zwar viele Linien zeichnen wo eine Spur, ein Radstreifen, ein Fußweg, etc. ist, aber je mehre Wege und Relationen du hast, umso weniger Mapper sind in der Lage das fehlerfrei zu mappen. Aber die Information, dass es sich bei den 5 Wegen um einen Verkehrsweg handelt fehlt und, schlimmer noch, kann von dem unbedarften Mapper nicht als fehlend erkannt werden. Unter Umständen zerstört ein neuer Mapper sogar ein kompliziertes Tagging eines erfahreneren Mappers und bekommt erstmal als Begrüngsnachricht einen halbfreundlichen Link auf eine Wikiseite und einen Revert. Das ist jetzt schon so und wird durch extensives Spurmapping nur noch mehr und mehr zunehmen. Je fragiler das Mappingschema ist (und ich halte Spurmapping, bei gleichzeitg halbwegs verwendbaren Daten für das komplexeste und fragilste mögliche Schema) umso mehr *muss* OSM wie Wikipedia werden, wo Admins praktisch jeden neuen Eintrag reverten, weil irgendwelche Kriterien bzw. Wikiregeln verletzt sind. Das ist dann auch aus Mappersicht nicht mehr erfreulich. Was ich also gemeint hab war, dass durch eine solche Art des Detailmapping die grobe und schnelle Übersicht über die Daten erschwert wird, was erstmal jeden, der auch nur mit den groben Daten arbeiten will, dazu zwingt, alle Detailmappingschemen zu verstehen, bevor er sie für seinen Gebrauch vereinfachen kann. das stimmt zwar, ist aber halt so. Da man Daten nur vereinfachen kann (automatisch), sie aber nicht automatisch mit Details anreichern kann, sollte es klar sein, welchen Weg man wählt (als Projekt). Das ist zwar richtig, aber vollkommen am Punkt vorbei. Natürlich kann man Daten nicht einfach erfinden, aber man kann Daten, wenn sie entsprechend eingetragen sind, von einer Basislinie aus genauso hinzufügen, wie man eine komplizierte Kreuzung mit vielen extra gezeichneten Spuren vereinfachen kann. Der Punkt ist also nur, ob die Daten erstmal für jeden kompliziert sind und vereinfacht werden müssen, oder erstmal einfach sind, und nur für komplizierte Anforderungen die Auswertung aller Tags auch kompliziert wird. Oder auch dass man, um diese Detailstufen zu vereinfachen relative rechenintsive geometrische Operationen ausführen muss, anstatt einfach erstmal ein relativ einfaches Stringprocessing indem man Tags, die einen nicht interessieren (bzw. die man noch nichtmal kennt) wegwirft. Man hätte also erst den Aufwand wenn man die Details wie Schienen, Fahrspuren, Fußwege, Radstreifen etc. auch wirklich braucht. wobei die Grundregel ist
Re: [Talk-de] *:lanes und Straßenbahnschienen
On 03/15/2013 04:11 PM, Wilhelm Spickermann wrote: Wir stehen doch nicht vor dem Problem, ein Tagging für Straßenbahnen erfinden zu müssen. Es gibt eine Lösung, diese Lösung ist schon so benutzt worden als es noch kein Spurmapping gab und die auswertenden Programme sind darauf ausgerichtet. [...] Bei vielen Grenzen zwischen Wald und Wiese liegen zwei Linien übereinander und es stört niemand. Ich geb dir vollkommen Recht, aber darum gings mir auch gar nicht. Wenn die Straßenbahn als ein Way über dem Straßenway liegt, dann ist das tatsächlich so wie es früher gehandhabt wurde und imo auch ok. Ich dachte dabei mehr daran, dass jemand die Ways räumlich trennt und zwei Schienen zeichnet (für jede Fahrtrichtung eine) und diese Schienen dann mit dem Luftbild so verortet, dass sie lagegenau sind, während die Straße als ein Way für beide Richtungen in der Mitte der Schienen geschätzt wird. Tatsächlich aber liegen die Schienen eben in der einen Straße und werden von allen Fahrzeugen gleich benutzt. Das ist kein althergebrachtes Railwaymapping und diese Mischung aus lagegenauen Einzelways für Spezialisten (bzw. den Detailbereich Schienenfahrzeuge) und geschätzten Sammelways macht die Daten, ohne die zusätzliche Information des Luftbildes, unbrauchbar. Das war der Punkt der mich stört. lg, Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
On 03/14/2013 05:54 PM, Martin Koppenhoefer wrote: Am 14. März 2013 17:45 schrieb fly lowfligh...@googlemail.com: Besser ist vielleicht ein ref:highway bzw. ref:railway. Analog bei name=*, wobei ich mir nicht sicher bin ob solche Schienenstränge eigene Namen haben. -1, besser ein eigenes Objekt für was eigen ist, so braucht man keine Extrawürste und kann das problemlos auswerten (geht ja nicht nur um ref, sondern prinzipiell um alle Eigenschaften, z.B. auch width und surface). Das ist vollkommen willkürlich als Grenze. Ich behaupte einfach das Objekt ist der Verkehrsweg an sich und der enthält Bereich für Fußgänger, ev. Radstreifen, allgemeine Fahrspuren und Schienen. Natürlich kann ich alles einzelen eintragen, aber dann brauch ich irgendeine Art von Relation die mir eben sagt, dass all diese Einzelwege teil eines einzigen Verkehrswegs sind. Ansonsten bildet man damit vielleicht abstrakte Routinggraphen für einzelne Verkehrsteilnehmer ab, aber eben nicht die Realität, dass da eben exakt eine Straße ist. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
On 03/15/2013 01:46 PM, Andreas Neumann wrote: usus ist es doch, das Fahrspuren, die baulich getrennt sind, auch als seperate Linien gemappt sind. Ich sehe aber zwei nebeneinanderverlaufende Schienenstränge als bauliche Trennung an, da es dem Schienenfahrzeug nicht ohne weiteres möglich ist die Fahrspur zu wechseln. Dies ist ansonsten bei einem Straßenzug physikalisch einfach möglich. Wenn die Schienen separat von der Straße verlaufen ist der Fall klar. Aber wenn die Schienen in beide Richtungen direkt in der normalen Straße verlaufen ist der Fall nicht mehr klar. Denn die bauliche Trennung existiert nur für die Schienenfahrzeuge, weil diese eben schienengebunden sind, also als Eigenschaft der Anzahl der Schienenstränge und nicht als Eigenschaft der Straße. Jeder andere Verkehrsteilnehmer kann da drüber fahren/gehen. Dann gibt es noch die Möglichkeit die Straße als einen Way in der Mitte und links und rechts die Gleiskörper. Dann zeichnet man allerdings 3 Ways für etwas, dass eigentlich nur ein einziger Way ist und es stellt sich die Frage wie man mit diesen Daten erkennt, dass die Schienen eigentlich in der einen Straße liegen. Das funktioniert vielleicht im Rendering, weil die Ausdehnung der Straße beim Zeichnen größer ist als der Abstand der beiden getrennten Schienenstränge. In den Daten hingegen ist es unmöglich zu erkennen ob da jetzt die Schienen teil der Straße sind (bspw. um beim Routing für Radfahrer Schienenstraßen etwas abzuwerten) oder ob die tatsächlich neben der Straße liegen. Ich hab das Gefühl hier werden aufgrund von Spezialproblemen (perfektes Erfassen der Gleiskörper) die allgemeinen Probleme (Wo ist welche Straße und wie ist sie aufgebaut?) vernachlässigt, was dazu führt, dass eben einzelne Spezialanfragen gut beantwortet werden können, sich aber allgemeine Aussagen nur durch erhöhten Mapping- und Rechenaufwand lösen lassen (Relationen, finden annähernd paralleler Wege in geringem Abstand, Ways mit Straßenflächen schneiden, etc.). Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] *:lanes und Straßenbahnschienen
On 03/15/2013 02:32 PM, Andreas Neumann wrote: On 03/15/2013 02:09 PM, Norbert Wenzel wrote: Ich hab das Gefühl hier werden aufgrund von Spezialproblemen (perfektes Erfassen der Gleiskörper) die allgemeinen Probleme (Wo ist welche Straße und wie ist sie aufgebaut?) vernachlässigt, was dazu führt, dass eben einzelne Spezialanfragen gut beantwortet werden können, sich aber allgemeine Aussagen nur durch erhöhten Mapping- und Rechenaufwand lösen lassen (Relationen, finden annähernd paralleler Wege in geringem Abstand, Ways mit Straßenflächen schneiden, etc.). Das Spiel kann man auch umdrehen: Ihr wollt die korrekt gemappten Gleise zerstören, um eine Speziallösung für eure Straßenbeschreibung zu haben. Ja kann man, macht aber imo keinen Sinn es umzudrehen. Ich mein mit Straßenbeschreibung nicht unbedingt die PKW Straße sondern die umgangssprachliche Straße. D.h. den einen Way wo alles entlang geht mit dem Namen XY. Man könnte auch sagen um eine perfekte Detailkarte in z19+ zu erstellen erschwert man dadurch allen niedrigeren Zoomlevels das Arbeiten mit den Daten. Selbst getrennte Fahrtrichtungen am Gleis kann man ja dann nicht ohne Heuristik oder zusätzliche Datenstruktur zusammenfassen. Wenn ich hingegen nur ein Gleis mappe und dabei die Anzahl der Gleise in jede Fahrtrichtung angeb, hab ich das Problem nicht und kann bei Detailstufen halt von der einfachen Linie auf die Doppellinie wechseln. Was ich also gemeint hab war, dass durch eine solche Art des Detailmapping die grobe und schnelle Übersicht über die Daten erschwert wird, was erstmal jeden, der auch nur mit den groben Daten arbeiten will, dazu zwingt, alle Detailmappingschemen zu verstehen, bevor er sie für seinen Gebrauch vereinfachen kann. Oder auch dass man, um diese Detailstufen zu vereinfachen relative rechenintsive geometrische Operationen ausführen muss, anstatt einfach erstmal ein relativ einfaches Stringprocessing indem man Tags, die einen nicht interessieren (bzw. die man noch nichtmal kennt) wegwirft. Man hätte also erst den Aufwand wenn man die Details wie Schienen, Fahrspuren, Fußwege, Radstreifen etc. auch wirklich braucht. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] overpass turbo - eine Web-GUI für die Overpass-API
Hallo, am 27.01.2013 16:51 schrieb Martin Raifer: * Der Export nach GeoJSON scheint mir einzigartig zu sein und geht über die Möglichkeiten von Overpass API hinaus, oder? Ja, in der Tat. Das ist auch der (programmiertechnische) Kern der ganzen Anwendung. Dieser Konverter [Overpass-API-Output GeoJSON] würde bestimmt vielen Kartenbauern nützlich sein. Wie wäre es, diesen Teil zu isolieren und als Leaflet Plugin ( http://leafletjs.com/plugins.html ) zur Verfügung zu stellen? Ich habe so etwas schon vermisst und wäre dankbar und begeistert. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
