[Talk-de] Konverter XErleben - OSM
Hallo liebe OSM-Community, ich melde mich hier im Namen einer Forschungskooperation bestehend aus dem Kreis Warendorf, FH-Münster, EFTAS Fernerkundung und PSV-Marketing. Für unser Projekt möchten wir OSM Points of Interest mit dem kommunalen POI-Datenmodell XErleben (siehe unter http://www.xerleben.de) vergleichbar bzw. auch kombinierbar zu machen. Der Kreis Warendorf setzt in seiner Datenhaltung auf den Einsatz des XErleben-Datenmodells (http://www.xerleben.de/). In einem ersten Schritt haben wir eine Kategorisierungs-Tabelle aufgestellt, in der einer sogenannten Funktion im XErleben-Modell 1-2 entsprechende key:value Paare zugeordnet sind, um diese zu kategorisieren. Ich versuche das mal am folgenden Auszug zu erläutern. Im XErleben-Modell gibt es Pakete, die einzelne Kategorien beinhalten, die wiederum die einzelnen Funktionen eines POIs beschreiben. Paket und Kategorie dienen nur der Einordnung, die Kategorisierung erfolgt über den Eintrag in Funktion. Siehe Auszug Kategorisierungs-Tabelle weiter unten. Demgegenüber stehen die verschiedenen OSM key:value Paare. Das Ziel unserer Tabelle ist es, für eine Kategorisierung in dem einen Modell eine entsprechende aus dem anderen Modell zu finden. So entspricht z.B. eine Touristeninformation in OSM einem POI der mit den key:value Paaren tourism:information und information:office getaggt ist. Eine Infotafel oder Infopoint wird dementsprechend mit tourism:information und information:board getaggt. Schöner und eindeutiger ist es natürlich, wenn ein key:value Paar ausreichend ist, wie z.B. bei einem Ticketshop durch ticket:shop. Auszug Kategorisierungs-Tabelle: Paket- Kategorie- Funktion - XE_TouristischeInfrastruktur - XE_Servicestelle - Touristinformation|| tourism:information, information:office - - Infopoint || tourism:information, information:board - - Ticketshop || shop:ticket - XE_Gastronomie- Brennerei ||- Bei der Zuordnung der Brennerei kommen wir zu dem ersten Problem. In der offiziellen Map Features Liste (http://wiki.osm.org/wiki/DE:Map_Features) gibt es noch keinen entsprechenden Tag um diese Funktion eines POI zu beschreiben. Weil nicht eindeutige Zuordnungen häufiger auftauchen hoffen wir auf die Zusammenarbeit mit der OSM Community. Die Lösung könnte z.B. die Einführung neuer Tags sein, aber da sind wir für alle Lösungsvorschläge offen und dankbar. Unsere Idee ist, diese Zuordnungsliste frei verfügbar zu machen (z.B. auf einer Seite im OSM Wiki) und dort zu pflegen, um anderen Kommunen, Personen, etc. Hilfestellung beim Import/Export von Daten in OSM zu ermöglichen. Eine erste Arbeitsversion befindet sich momentan unter https://docs.google.com/file/d/0B5hzMGhyvOK6c1dDQ21pYUxZZFE. Aber es existieren noch viele leere Zeilen (s.o.) und Unklarheiten, welche Tag-Kombinationen die Richtigen sind. Hier hoffen wir auf den Input der erfahreneren OSM Mapper, um gemeinsam diese Lücken zu füllen. Evtl. haben wir als schönen Nebeneffekt, dass das Wiki in Bereichen mit leicht widersprüchlichen Angaben harmonisiert wird. Die zweite Aufgabenstellung ist mehr technischer Natur und bezieht sich auf die Verwaltung dieser Datentabelle. Die Idee ist diese im Wiki zu pflegen, so dass jeder Zuordnungen hinzufügen oder korrigieren kann. Zusätzlich bräuchte man eine Exportfunktion (als csv etc.), um die Zuordnungstabelle maschinell einlesen zu können. Vielleicht kann hier der ein oder andere Wiki-Admin sagen, ob es dafür geeignete Plug-Ins gibt oder wie diese Funktion zu realisieren wäre. Wir freuen uns über Vorschläge und hoffen einen kleinen Beitrag zum OSM Projekt beitragen zu können. Mit freundlichen Grüßen Christian Röttger -- Dipl.-Geoinf. Christian Röttger -Forschung und Entwicklung E F T A SFernerkundung Technologietransfer GmbH Oststraße 2-18 48145 Münster Fon: +49 251 13307-23 E-Mail: christian.roett...@eftas.com Fax: +49 251 13307-33 Web: http://www.eftas.com Geschäftsführer: Dipl.-Ing. Georg Altrogge Sitz der Gesellschaft: Münster Amtsgericht Münster, HRB 2999 USt.-IdNr. DE 126038986 ** ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konverter XErleben - OSM
Am 03.04.2014 11:31, schrieb EFTAS Christian Röttger: Hallo liebe OSM-Community, Hallo, Bei der Zuordnung der Brennerei kommen wir zu dem ersten Problem. In der offiziellenMap Features Liste (http://wiki.osm.org/wiki/DE:Map_Features) gibt es noch keinen entsprechenden Tag um diese Funktion eines POI zu beschreiben. Weil nicht eindeutige Zuordnungen häufiger auftauchen hoffen wir auf die Zusammenarbeit mit der OSM Community. Die Lösung könnte z.B. die Einführung neuer Tags sein, aber da sind wir für alle Lösungsvorschläge offen und dankbar. Die Map Features beinhalten nicht alle tags, und man sollte sich nicht daran klammern. Bei nicht vorhandenen tags in DE:Mapfeatures solltet ihr sprachunabhängig suchen, beispielsweise gibt es ein craft=brewery schon, wie ihr vielleicht schon gemerkt habt. http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbrewery Unsere Idee ist, diese Zuordnungsliste frei verfügbar zu machen (z.B. auf einer Seite im OSM Wiki) und dort zu pflegen, um anderen Kommunen, Personen, etc. Hilfestellung beim Import/Export von Daten in OSM zu ermöglichen. Eine erste Arbeitsversion befindet sich momentan unter https://docs.google.com/file/d/0B5hzMGhyvOK6c1dDQ21pYUxZZFE. Aber es existieren noch viele leere Zeilen (s.o.) und Unklarheiten, welche Tag-Kombinationen die Richtigen sind. Hier hoffen wir auf den Input der erfahreneren OSM Mapper, um gemeinsam diese Lücken zu füllen. Evtl. haben wir als schönen Nebeneffekt, dass das Wiki in Bereichen mit leicht widersprüchlichen Angaben harmonisiert wird. Mit taginfo lassen sich tags überprüfen (z.B. Wie oft benutzt? ; Mit welchen Kombinationen? ; usw.) http://taginfo.openstreetmap.org Ich habe jedoch Zweifel, ob für Kombinationen nur ein zusätzliches Wertepaar ausreicht. Da müsste man schon Wissen welche Infos für euch in der Kombination relevant sind. Beispielsweise amenity=restaurant, da gibt es einige mögliche zusätzliche Infos wie z.B. Name, Öffnungszeiten, Art der Küche, Rauchen, Rollstuhltauglichkeit, WLan, usw. Wie wollt ihr diese Problematik lösen? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant Mit freundlichen Grüßen Christian Röttger Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit
Hallo Stephan, Am 03.04.2014 00:41, schrieb Stephan Wolff: Am 30.03.2014 13:57, schrieb Florian Schäfer: Hallo Liste, ich würde gerne mal bei euch ein kleines Meinungsbild einholen über die Verwendung des Keys noexit In den folgenden Situationen habe ich beispielsweise schon noexit=yes-Tags gesehen: *A*: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357 https://commons.wikimedia.org/wiki/File:Zeichen_357.svg) Ich finde noexit allenfalls in diesem Fall sinnvoll. Private Wege zu Haustüren oder Garagen, die dort abzweigen, würde ich ignorieren. Ja, solange der Weg zu Türen/Toren/... führt stimme ich Dir zu. Wenn ein Privatweg (oder Waldweg) aber einfach so aufhört, kann meiner Meinung nach auch dort noexit=yes sinnvoll sein. Laut deutschen Wiki ist noexit nur für Punkte definiert, in der englischen Version auch für Wege, ohne dass dies genauer beschrieben ist. Würde man Wendeschleifen in Sackgassen mit noexit=yes versehen? Sobald die Wendeschleife wirklich als Schleife gemappt ist, also nicht als Node mit highway=turning_circle oder so, würde ich noexit=yes nicht mehr setzen. Weder auf den Way der Schleife, noch auf einen der Nodes. Denn der Weg geht ja quasi weiter, nur halt auf dem selben Weg, den Du gekommen bist. Sollte man alle Werte außer yes und no entfernen oder ist eine Erweiterung wie noexit=motor_vehicle (169 Verwendungen) sinnvoll? Ich finde alle Werte außer yes nicht sinnvoll. no alleine schon von der doppelten Verneinung her, da ist fixme=continue besser. Und wenn sich jemand die Mühe macht, das Ende eines Wegs als noexit=motor_vehicle zu kennzeichnen, soll er doch bitte gleich den weiterführenden Weg einzeichnen und mit motor_vehicle=no (und weiteren passenden access-Tags) versehen. Und falls er den Verlauf nicht kennt, kann er ja den Anfang davon einzeichnen (ein paar Meter lang) und den mit fixme=continue und motor_vehicle=no (und weiteren passenden access-Tags) versehen. Heißt also: Wenn ich noexit=no begegnen würde, würde ich nach Möglichkeit den fehlenden Weg einzeichnen, oder es durch das geläufigere und eingängigere fixme=continue ersetzen. Vorausgesetzt natürlich, der weiterführende Weg ist noch nicht eingezeichnet, dann kann es einfach so entfernt werden. Die anderen noexit-Werte würde ich wie eben beschrieben durch den weiterführenden Weg (oder zumindest den Anfang davon) plus access-Tags ersetzen. Viele Grüße, Florian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Moin! Am 01.04.2014 10:14, schrieb Falk Zscheile: Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen, um der möglichen Doppelbedeutung von tags entgegenzuwirken. Damit führst du doch eine Doppelbedeutung erst ein. Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, access:traffic_sign=DE:397 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit traffic_sign=DE:397 der Inhalt vollständig beschrieben. Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur Straße nötig wäre, fehlt natürlich noch. access:traffic_sign statt traffic_sign wird jede Auswertung verhindern und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung beinhaltet. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. PS.: So handhabe ich es auch bei der Radweg-/Fußweg-/-kombinations-/Poblematik. Aber hoffentlich nicht mit access-Tags. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Hallo, bei uns hat vor einigen Tagen jemand eine Straße in eine Fläche umgewandelt: http://www.openstreetmap.org/way/270733792 Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten. Ist highway=pedestrian auf die Fläche überhaupt korrekt? Darf die Fläche an die zuführenden Straßen angeschlossen sein? Kann ich den Wegverlauf einfach als weiteres highway=pedestrian in Form einer Linie oben drüberlegen? Wo gehört dann der name dran? Bitte um Tipps. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de: Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit traffic_sign=DE:397 der Inhalt vollständig beschrieben. Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur Straße nötig wäre, fehlt natürlich noch. access:traffic_sign statt traffic_sign wird jede Auswertung verhindern und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung beinhaltet. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. +1, ich würde wenn ich Schilder erfassen würde (was ich derzeit nur für Ortseingangsschilder und Geschwindigkeitsbegrenzungen, und Höhen-, Breiten- und Gewichtsbegr. mache), das nicht an den Weg taggen, sondern an einen node, eben so, wie man es auch antrifft. Dabei setze ich das Schild in Fahrtrichtung rechts des Wegs in einem geringen Abstand, so dass die Richtung normalerweise klar wird (bisher noch keine Ausnahme angetroffen, gibt es aber vielleicht, kann man i.d.R. durch Optimieren der Abstände regeln). Wenn man das Schild an den way setzt, dann führt das hinterher zu ähnlichen Folgefehlern (durch Splitten des ways, Verschieben der Endnodes etc.) wie bei den übrigen tags auch. Diese Schilder sehe ich als ggf. hilfreich für andere Mapper an, aber ich erwarte davon nicht, dass deren Aussage von Datenkonsumenten wie Router etc berücksichtigt wird, von daher setze ich das zusätzlich zu den entsprechenden Auswirkungen / Interpretationen, die mit den entspr. osm-tags auf den Weg-segmenten getaggt werden. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 3. April 2014 10:01 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten. +1 Ist highway=pedestrian auf die Fläche überhaupt korrekt? Darf die Fläche an die zuführenden Straßen angeschlossen sein? JOSM schimpft da zwar, aber falsch finde ich es nicht. Kann ich den Wegverlauf einfach als weiteres highway=pedestrian in Form einer Linie oben drüberlegen? Wo gehört dann der name dran? name ggf. an beides, den highway=pedestrian linear kannst Du (würde ich) drüberlegen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit
Am 30.03.2014 13:57, schrieb Florian Schäfer: Hallo Liste, ich würde gerne mal bei euch ein kleines Meinungsbild einholen über die Verwendung des Keys noexit In den folgenden Situationen habe ich beispielsweise schon noexit=yes-Tags gesehen: *A*: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357 https://commons.wikimedia.org/wiki/File:Zeichen_357.svg) Ich finde noexit allenfalls in diesem Fall sinnvoll. Private Wege zu Haustüren oder Garagen, die dort abzweigen, würde ich ignorieren. Laut deutschen Wiki ist noexit nur für Punkte definiert, in der englischen Version auch für Wege, ohne dass dies genauer beschrieben ist. Würde man Wendeschleifen in Sackgassen mit noexit=yes versehen? Sollte man alle Werte außer yes und no entfernen oder ist eine Erweiterung wie noexit=motor_vehicle (169 Verwendungen) sinnvoll? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Hallo, bei uns hat vor einigen Tagen jemand eine Straße in eine Fläche umgewandelt: http://www.openstreetmap.org/way/270733792 Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten. Ist highway=pedestrian auf die Fläche überhaupt korrekt? Darf die Fläche an die zuführenden Straßen angeschlossen sein? Kann ich den Wegverlauf einfach als weiteres highway=pedestrian in Form einer Linie oben drüberlegen? Wo gehört dann der name dran? Bitte um Tipps. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 3. April 2014 09:47 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Ist highway=pedestrian auf die Fläche überhaupt korrekt? ist es denn eine Fußgängerzone? Das ist die Anforderung. Eine linearen Weg braucht man aber oft trotzdem, z.B. wenn es eine Einbahnstraße ist, oder fürs Routing. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Moin! Am 01.04.2014 10:14, schrieb Falk Zscheile: Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen, um der möglichen Doppelbedeutung von tags entgegenzuwirken. Damit führst du doch eine Doppelbedeutung erst ein. Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, access:traffic_sign=DE:397 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit traffic_sign=DE:397 der Inhalt vollständig beschrieben. Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur Straße nötig wäre, fehlt natürlich noch. access:traffic_sign statt traffic_sign wird jede Auswertung verhindern und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung beinhaltet. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. PS.: So handhabe ich es auch bei der Radweg-/Fußweg-/-kombinations-/Poblematik. Aber hoffentlich nicht mit access-Tags. Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konverter XErleben - OSM
Zu nennen wären auch noch die Seiten: http://wiki.openstreetmap.org/wiki/DE:How_to_map_a und http://wiki.osm.org/wiki/Map_Features Anmerkung: Die Definition auf den englischen Wikiseiten haben im Zweifelsfalle Vorrang vor der deutschen Übersetzung. Ihr nennt die Keys Cafe und Bauernhofcafe. Die sollten beide unter amenity=cafe zusammengefasst werden und gegebenenfalls das Bauernhofcafe durch einen zusätzlichen Key kenntlich gemacht werden. Neue Keys dafür einzuführen ist ungut, weil bestehende Anwendungen damit nicht umgehen können. Manchmal hilft auch das geschickte kombinieren von Tags weiter. Dann möchte ich noch auf die Tags tourism=yes (Wird benutzt um die touristische Bedeutung eines, durch andere Tags beschriebenen, Objektes anzugeben.) und tourism=attraction (Sehenswürdigkeit) aufmerksam machen: http://wiki.openstreetmap.org/wiki/DE:Key:tourism Damit könntet ihr z.B. euren Erlebnisbauernhof abbilden: landuse=farmyard + tourism=yes Es wäre aber auch denkbar bei Schaubrauereien (craft=brewery + tourism=yes) und anderen Sachen. Den Key leisure=swimming_pool habt ihr offenbar etwas falsch verstanden, damit werden lediglich einzelne Schwimmbecken eingezeichnet. Das Thema Seezeichen ist ziemlich komplex: http://wiki.openstreetmap.org/wiki/Marine_navigation http://wiki.openstreetmap.org/wiki/OpenSeaMap/Landmarks http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values Ich weiß nicht, inwiefern das Thema für euch wichtig ist. Schließt euch da am besten mit den Machern von OpenSeaMap kurz. In dem Bereich fanden auch schon einige Importe statt. Am 3. April 2014 13:03 schrieb René Falk li...@falconaerie.de: Am 03.04.2014 11:31, schrieb EFTAS Christian Röttger: Hallo liebe OSM-Community, Hallo, Bei der Zuordnung der Brennerei kommen wir zu dem ersten Problem. In der offiziellenMap Features Liste (http://wiki.osm.org/wiki/DE:Map_Features) gibt es noch keinen entsprechenden Tag um diese Funktion eines POI zu beschreiben. Weil nicht eindeutige Zuordnungen häufiger auftauchen hoffen wir auf die Zusammenarbeit mit der OSM Community. Die Lösung könnte z.B. die Einführung neuer Tags sein, aber da sind wir für alle Lösungsvorschläge offen und dankbar. Die Map Features beinhalten nicht alle tags, und man sollte sich nicht daran klammern. Bei nicht vorhandenen tags in DE:Mapfeatures solltet ihr sprachunabhängig suchen, beispielsweise gibt es ein craft=brewery schon, wie ihr vielleicht schon gemerkt habt. http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbrewery Unsere Idee ist, diese Zuordnungsliste frei verfügbar zu machen (z.B. auf einer Seite im OSM Wiki) und dort zu pflegen, um anderen Kommunen, Personen, etc. Hilfestellung beim Import/Export von Daten in OSM zu ermöglichen. Eine erste Arbeitsversion befindet sich momentan unter https://docs.google.com/file/d/0B5hzMGhyvOK6c1dDQ21pYUxZZFE. Aber es existieren noch viele leere Zeilen (s.o.) und Unklarheiten, welche Tag-Kombinationen die Richtigen sind. Hier hoffen wir auf den Input der erfahreneren OSM Mapper, um gemeinsam diese Lücken zu füllen. Evtl. haben wir als schönen Nebeneffekt, dass das Wiki in Bereichen mit leicht widersprüchlichen Angaben harmonisiert wird. Mit taginfo lassen sich tags überprüfen (z.B. Wie oft benutzt? ; Mit welchen Kombinationen? ; usw.) http://taginfo.openstreetmap.org Ich habe jedoch Zweifel, ob für Kombinationen nur ein zusätzliches Wertepaar ausreicht. Da müsste man schon Wissen welche Infos für euch in der Kombination relevant sind. Beispielsweise amenity=restaurant, da gibt es einige mögliche zusätzliche Infos wie z.B. Name, Öffnungszeiten, Art der Küche, Rauchen, Rollstuhltauglichkeit, WLan, usw. Wie wollt ihr diese Problematik lösen? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant Mit freundlichen Grüßen Christian Röttger Grüße René ___ 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] Meinungsbild noexit
Am 30.03.2014 13:57, schrieb Florian Schäfer: Hallo Liste, ich würde gerne mal bei euch ein kleines Meinungsbild einholen über die Verwendung des Keys noexit In den folgenden Situationen habe ich beispielsweise schon noexit=yes-Tags gesehen: *A*: Strikte Sackgassen auf öffentlichen Straßen (Zeichen 357 https://commons.wikimedia.org/wiki/File:Zeichen_357.svg) Ich finde noexit allenfalls in diesem Fall sinnvoll. Private Wege zu Haustüren oder Garagen, die dort abzweigen, würde ich ignorieren. Laut deutschen Wiki ist noexit nur für Punkte definiert, in der englischen Version auch für Wege, ohne dass dies genauer beschrieben ist. Würde man Wendeschleifen in Sackgassen mit noexit=yes versehen? Sollte man alle Werte außer yes und no entfernen oder ist eine Erweiterung wie noexit=motor_vehicle (169 Verwendungen) sinnvoll? Gruß Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AFD nutzt Openstreetmap ohne Attribution in Wahlwerbeflyer in Bremen
On 02.04.2014 01:53, Dirk-Lüder Kreie wrote: Ich hab hier grad einen Wahlflyer der AfD hier in Bremen in der Hand und beim Wegwerfen fiel mir eine Karte darin auf, und siehe da, es ist ein Ausschnitt der Bremer OSM-Karte drin, aber ohne den notwendigen Hinweis auf die Quelle. Ein Beweisfoto vorm Wegwerfen wäre nicht die schlechteste Idee gewesen… ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 03.04.2014 10:01, schrieb Manuel Reimer: Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten. Ist highway=pedestrian auf die Fläche überhaupt korrekt? Darf die Fläche an die zuführenden Straßen angeschlossen sein? Sie muss angeschlosssen werden, sonst funktioniert das Routing nicht mehr. Geroutet wird übrigens am Rand der Fläche entlang. Kann ich den Wegverlauf einfach als weiteres highway=pedestrian in Form einer Linie oben drüberlegen? Wo gehört dann der name dran? Ist unschön, aber verbessert das Routing. Wichtig: Fläche mit Linie verbinden, sonst gibt es Routing-Inseln. Den Namen würde ich an die Linie machen. Christian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konverter XErleben - OSM
-- Dipl.-Geoinf. Christian Röttger -Forschung und Entwicklung E F T A SFernerkundung Technologietransfer GmbH Oststraße 2-18 48145 Münster Fon: +49 251 13307-23 E-Mail: christian.roett...@eftas.com Fax: +49 251 13307-33 Web: http://www.eftas.com Geschäftsführer: Dipl.-Ing. Georg Altrogge Sitz der Gesellschaft: Münster Amtsgericht Münster, HRB 2999 USt.-IdNr. DE 126038986 ** -Ursprüngliche Nachricht- Von: Archer [mailto:arc...@gulli.com] Gesendet: Donnerstag, 3. April 2014 15:33 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Konverter XErleben - OSM Zu nennen wären auch noch die Seiten: http://wiki.openstreetmap.org/wiki/DE:How_to_map_a und http://wiki.osm.org/wiki/Map_Features Anmerkung: Die Definition auf den englischen Wikiseiten haben im Zweifelsfalle Vorrang vor der deutschen Übersetzung. Ihr nennt die Keys Cafe und Bauernhofcafe. Die sollten beide unter amenity=cafe zusammengefasst werden und gegebenenfalls das Bauernhofcafe durch einen zusätzlichen Key kenntlich gemacht werden. Neue Keys dafür einzuführen ist ungut, weil bestehende Anwendungen damit nicht umgehen können. Manchmal hilft auch das geschickte kombinieren von Tags weiter. Dann möchte ich noch auf die Tags tourism=yes (Wird benutzt um die touristische Bedeutung eines, durch andere Tags beschriebenen, Objektes anzugeben.) und tourism=attraction (Sehenswürdigkeit) aufmerksam machen: http://wiki.openstreetmap.org/wiki/DE:Key:tourism Damit könntet ihr z.B. euren Erlebnisbauernhof abbilden: landuse=farmyard + tourism=yes Es wäre aber auch denkbar bei Schaubrauereien (craft=brewery + tourism=yes) und anderen Sachen. Den Key leisure=swimming_pool habt ihr offenbar etwas falsch verstanden, damit werden lediglich einzelne Schwimmbecken eingezeichnet. Das Thema Seezeichen ist ziemlich komplex: http://wiki.openstreetmap.org/wiki/Marine_navigation http://wiki.openstreetmap.org/wiki/OpenSeaMap/Landmarks http://wiki.openstreetmap.org/wiki/OpenSeaMap/Lights http://wiki.openstreetmap.org/wiki/OpenSeaMap/Seamark_Tag_Values Ich weiß nicht, inwiefern das Thema für euch wichtig ist. Schließt euch da am besten mit den Machern von OpenSeaMap kurz. In dem Bereich fanden auch schon einige Importe statt. Am 3. April 2014 13:03 schrieb René Falk li...@falconaerie.de: Am 03.04.2014 11:31, schrieb EFTAS Christian Röttger: Hallo liebe OSM-Community, Hallo, Bei der Zuordnung der Brennerei kommen wir zu dem ersten Problem. In der offiziellenMap Features Liste (http://wiki.osm.org/wiki/DE:Map_Features) gibt es noch keinen entsprechenden Tag um diese Funktion eines POI zu beschreiben. Weil nicht eindeutige Zuordnungen häufiger auftauchen hoffen wir auf die Zusammenarbeit mit der OSM Community. Die Lösung könnte z.B. die Einführung neuer Tags sein, aber da sind wir für alle Lösungsvorschläge offen und dankbar. Die Map Features beinhalten nicht alle tags, und man sollte sich nicht daran klammern. Bei nicht vorhandenen tags in DE:Mapfeatures solltet ihr sprachunabhängig suchen, beispielsweise gibt es ein craft=brewery schon, wie ihr vielleicht schon gemerkt habt. http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbrewery Unsere Idee ist, diese Zuordnungsliste frei verfügbar zu machen (z.B. auf einer Seite im OSM Wiki) und dort zu pflegen, um anderen Kommunen, Personen, etc. Hilfestellung beim Import/Export von Daten in OSM zu ermöglichen. Eine erste Arbeitsversion befindet sich momentan unter https://docs.google.com/file/d/0B5hzMGhyvOK6c1dDQ21pYUxZZFE. Aber es existieren noch viele leere Zeilen (s.o.) und Unklarheiten, welche Tag-Kombinationen die Richtigen sind. Hier hoffen wir auf den Input der erfahreneren OSM Mapper, um gemeinsam diese Lücken zu füllen. Evtl. haben wir als schönen Nebeneffekt, dass das Wiki in Bereichen mit leicht widersprüchlichen Angaben harmonisiert wird. Mit taginfo lassen sich tags überprüfen (z.B. Wie oft benutzt? ; Mit welchen Kombinationen? ; usw.) http://taginfo.openstreetmap.org Ich habe jedoch Zweifel, ob für Kombinationen nur ein zusätzliches Wertepaar ausreicht. Da müsste man schon Wissen welche Infos für euch in der Kombination relevant sind. Beispielsweise amenity=restaurant, da gibt es einige mögliche zusätzliche Infos wie z.B. Name, Öffnungszeiten, Art der Küche, Rauchen, Rollstuhltauglichkeit, WLan, usw. Wie wollt ihr diese Problematik lösen? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant Mit freundlichen Grüßen Christian Röttger Grüße René ___ 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 mailing list
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
On 04/03/2014 03:22 PM, Martin Koppenhoefer wrote: Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten. +1 Sind wir schon zu zweit ;) name ggf. an beides, den highway=pedestrian linear kannst Du (würde ich) drüberlegen. Habe ich mittlerweile gemacht. Im Rendering erscheint die Linie garnicht erst. Das freut mich, weil es die Chance erhöht, dass es mir nicht direkt von einem für den Renderer-Mapper wieder gelöscht wird. Die Namen werde ich aber noch umhängen auf die nun sauber reingebastelten Linien. Gruß Manuel P.S. Das das Posting doppelt kommt und erst so spät erscheit (obwohl laut Zeit schon heute früh verschickt) liegt daran, dass es bei GMANE wohl Probleme gegeben hat. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 03.04.2014 10:01, schrieb Manuel Reimer: bei uns hat vor einigen Tagen jemand eine Straße in eine Fläche umgewandelt: http://www.openstreetmap.org/way/270733792 Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten. Ist highway=pedestrian auf die Fläche überhaupt korrekt? Nein, hier überwiegt klar der lineare Charakter. Das ist kein Platz. Du solltest m.E. die Linien mit den ursprünglichen Tags wieder herstellen und die neue Fläche zu area:highway=pedestrian umtaggen. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konverter XErleben - OSM
Hallo, diese aktuelle Tabelle ist nur zur Kategorisierung gedacht. Tags wie name, adresse, etc. sollen natürlich als normale Attribute mit übernommen werden aber nicht unbedingt der Kategorisierung dienen. Wir haben uns erst einmal an den Map Features entlang geangelt, hauptsächlich in Englisch und auch Seiten wie http://wiki.openstreetmap.org/wiki/DE:How_to_map_a und http://wiki.osm.org/wiki/Map_Features zum besseren Verständniss. Auch TagInfo hat die ein oder andere Info gebracht. Das Thema ist halt sehr komplex und kann sich nur sukzessiv entwickeln. Craft: brewery benutzen wir ja auch für eine Brauerei. Aber für eine Destillerie passt es nicht unbedingt. Auch kann man natürlich zu jedem Tag eine eigene Diskussion aufmachen, da es diverse Meinungen und Sichtweisen gibt. Wir möchten versuchen daraus einen recht ordentlichen Konsens zu schaffen. Viele Grüße Christian Betreff: Re: [Talk-de] Konverter XErleben - OSM Am 03.04.2014 11:31, schrieb EFTAS Christian Röttger: Hallo liebe OSM-Community, Hallo, Bei der Zuordnung der Brennerei kommen wir zu dem ersten Problem. In der offiziellenMap Features Liste (http://wiki.osm.org/wiki/DE:Map_Features) gibt es noch keinen entsprechenden Tag um diese Funktion eines POI zu beschreiben. Weil nicht eindeutige Zuordnungen häufiger auftauchen hoffen wir auf die Zusammenarbeit mit der OSM Community. Die Lösung könnte z.B. die Einführung neuer Tags sein, aber da sind wir für alle Lösungsvorschläge offen und dankbar. Die Map Features beinhalten nicht alle tags, und man sollte sich nicht daran klammern. Bei nicht vorhandenen tags in DE:Mapfeatures solltet ihr sprachunabhängig suchen, beispielsweise gibt es ein craft=brewery schon, wie ihr vielleicht schon gemerkt habt. http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbrewery Unsere Idee ist, diese Zuordnungsliste frei verfügbar zu machen (z.B. auf einer Seite im OSM Wiki) und dort zu pflegen, um anderen Kommunen, Personen, etc. Hilfestellung beim Import/Export von Daten in OSM zu ermöglichen. Eine erste Arbeitsversion befindet sich momentan unter https://docs.google.com/file/d/0B5hzMGhyvOK6c1dDQ21pYUxZZFE. Aber es existieren noch viele leere Zeilen (s.o.) und Unklarheiten, welche Tag-Kombinationen die Richtigen sind. Hier hoffen wir auf den Input der erfahreneren OSM Mapper, um gemeinsam diese Lücken zu füllen. Evtl. haben wir als schönen Nebeneffekt, dass das Wiki in Bereichen mit leicht widersprüchlichen Angaben harmonisiert wird. Mit taginfo lassen sich tags überprüfen (z.B. Wie oft benutzt? ; Mit welchen Kombinationen? ; usw.) http://taginfo.openstreetmap.org Ich habe jedoch Zweifel, ob für Kombinationen nur ein zusätzliches Wertepaar ausreicht. Da müsste man schon Wissen welche Infos für euch in der Kombination relevant sind. Beispielsweise amenity=restaurant, da gibt es einige mögliche zusätzliche Infos wie z.B. Name, Öffnungszeiten, Art der Küche, Rauchen, Rollstuhltauglichkeit, WLan, usw. Wie wollt ihr diese Problematik lösen? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant Mit freundlichen Grüßen Christian Röttger Grüße René ___ 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] AFD nutzt Openstreetmap ohne Attribution in Wahlwerbeflyer in Bremen
On Thu, Apr 03, 2014 at 04:34:19PM +0200, malenki wrote: On 02.04.2014 01:53, Dirk-Lüder Kreie wrote: Ich hab hier grad einen Wahlflyer der AfD hier in Bremen in der Hand und beim Wegwerfen fiel mir eine Karte darin auf, und siehe da, es ist ein Ausschnitt der Bremer OSM-Karte drin, aber ohne den notwendigen Hinweis auf die Quelle. Ein Beweisfoto vorm Wegwerfen wäre nicht die schlechteste Idee gewesen… Naja, schaut sich doch eh keiner an ;) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konverter XErleben - OSM
Zur Brennerei findet man unter How to map a folgende Anmerkung: Brennerei: craft=distillery + distillery=* Am 3. April 2014 17:16 schrieb EFTAS Christian Röttger christian.roett...@eftas.com: Hallo, diese aktuelle Tabelle ist nur zur Kategorisierung gedacht. Tags wie name, adresse, etc. sollen natürlich als normale Attribute mit übernommen werden aber nicht unbedingt der Kategorisierung dienen. Wir haben uns erst einmal an den Map Features entlang geangelt, hauptsächlich in Englisch und auch Seiten wie http://wiki.openstreetmap.org/wiki/DE:How_to_map_a und http://wiki.osm.org/wiki/Map_Features zum besseren Verständniss. Auch TagInfo hat die ein oder andere Info gebracht. Das Thema ist halt sehr komplex und kann sich nur sukzessiv entwickeln. Craft: brewery benutzen wir ja auch für eine Brauerei. Aber für eine Destillerie passt es nicht unbedingt. Auch kann man natürlich zu jedem Tag eine eigene Diskussion aufmachen, da es diverse Meinungen und Sichtweisen gibt. Wir möchten versuchen daraus einen recht ordentlichen Konsens zu schaffen. Viele Grüße Christian Betreff: Re: [Talk-de] Konverter XErleben - OSM Am 03.04.2014 11:31, schrieb EFTAS Christian Röttger: Hallo liebe OSM-Community, Hallo, Bei der Zuordnung der Brennerei kommen wir zu dem ersten Problem. In der offiziellenMap Features Liste (http://wiki.osm.org/wiki/DE:Map_Features) gibt es noch keinen entsprechenden Tag um diese Funktion eines POI zu beschreiben. Weil nicht eindeutige Zuordnungen häufiger auftauchen hoffen wir auf die Zusammenarbeit mit der OSM Community. Die Lösung könnte z.B. die Einführung neuer Tags sein, aber da sind wir für alle Lösungsvorschläge offen und dankbar. Die Map Features beinhalten nicht alle tags, und man sollte sich nicht daran klammern. Bei nicht vorhandenen tags in DE:Mapfeatures solltet ihr sprachunabhängig suchen, beispielsweise gibt es ein craft=brewery schon, wie ihr vielleicht schon gemerkt habt. http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbrewery Unsere Idee ist, diese Zuordnungsliste frei verfügbar zu machen (z.B. auf einer Seite im OSM Wiki) und dort zu pflegen, um anderen Kommunen, Personen, etc. Hilfestellung beim Import/Export von Daten in OSM zu ermöglichen. Eine erste Arbeitsversion befindet sich momentan unter https://docs.google.com/file/d/0B5hzMGhyvOK6c1dDQ21pYUxZZFE. Aber es existieren noch viele leere Zeilen (s.o.) und Unklarheiten, welche Tag-Kombinationen die Richtigen sind. Hier hoffen wir auf den Input der erfahreneren OSM Mapper, um gemeinsam diese Lücken zu füllen. Evtl. haben wir als schönen Nebeneffekt, dass das Wiki in Bereichen mit leicht widersprüchlichen Angaben harmonisiert wird. Mit taginfo lassen sich tags überprüfen (z.B. Wie oft benutzt? ; Mit welchen Kombinationen? ; usw.) http://taginfo.openstreetmap.org Ich habe jedoch Zweifel, ob für Kombinationen nur ein zusätzliches Wertepaar ausreicht. Da müsste man schon Wissen welche Infos für euch in der Kombination relevant sind. Beispielsweise amenity=restaurant, da gibt es einige mögliche zusätzliche Infos wie z.B. Name, Öffnungszeiten, Art der Küche, Rauchen, Rollstuhltauglichkeit, WLan, usw. Wie wollt ihr diese Problematik lösen? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant Mit freundlichen Grüßen Christian Röttger Grüße René ___ 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 mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AFD nutzt Openstreetmap ohne Attribution in Wahlwerbeflyer in Bremen
Am 03.04.2014 16:34, schrieb malenki: On 02.04.2014 01:53, Dirk-Lüder Kreie wrote: Ich hab hier grad einen Wahlflyer der AfD hier in Bremen in der Hand und beim Wegwerfen fiel mir eine Karte darin auf, und siehe da, es ist ein Ausschnitt der Bremer OSM-Karte drin, aber ohne den notwendigen Hinweis auf die Quelle. Ein Beweisfoto vorm Wegwerfen wäre nicht die schlechteste Idee gewesen… Wenn du das verfolgen mächtest (ich hab derzeit zu viel zu tun) kann ich dir gerne ein Beweisstück im Original zukommen lassen. -- Dirk-Lüder Deelkar Kreie Bremen - 53.0901°N 8.7868°E ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Überarbeitung der Wikiseite zu noexit=yes
Hallo zusammen, wie bereits angekündigt, habe ich mal die Wikiseite DE:Key:noexit [1] nach den Erkenntnissen aus der Diskussion hier überarbeitet. Wie schon bei der obigen Zusammenfassung soll dies natürlich nur ein Vorschlag sein. Kritik und Anregungen dazu sind selbstverständlich sehr willkommen. Falls ihr etwas aus der bisherigen Version [2] vermisst oder mit irgendetwas in der neuen Seite nicht zufrieden seid, ändert es gerne selber indem ihr die Wikiseite bearbeitet, oder antwortet auf diese Mail. Viele Grüße, Florian [1]: https://wiki.openstreetmap.org/wiki/DE:Key:noexit [2]: https://wiki.openstreetmap.org/w/index.php?title=DE:Key:noexitoldid=990619 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 03.04.2014 16:38, schrieb chris66: Am 03.04.2014 10:01, schrieb Manuel Reimer: Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten. Ist highway=pedestrian auf die Fläche überhaupt korrekt? Darf die Fläche an die zuführenden Straßen angeschlossen sein? Sie muss angeschlosssen werden, sonst funktioniert das Routing nicht mehr. Geroutet wird übrigens ...bei allen momentan bekannten auf OSM-Daten eingesetzten Routern am Rand der Fläche entlang. Ein Routing über Plätze wäre denkbar, Algorithmen existieren dafür (aus anderen Bereichen). Auch ein entsprechendes Preprocessing, das aus Plätzen für den Router Kreuzungen macht, ist durchaus im Rahmen des Möglichen. Kann ich den Wegverlauf einfach als weiteres highway=pedestrian in Form einer Linie oben drüberlegen? Wo gehört dann der name dran? Ist unschön, aber verbessert das Routing. Wir taggen nicht falsch für den Router! (genausowenig wie für's Rendering). Eigentlich müsste man das gerade bei Plätzen konsequent durchziehen, jedenfalls überall da, wo keine eindeutigen Wege über den Platz existieren (Rinnstein links und rechts der Fahrbahn oder ähnliches). Nur so wird irgendwann ein Router-Entwickler anfangen, sich darum zu kümmern. Wichtig: Fläche mit Linie verbinden, sonst gibt es Routing-Inseln. Richtig. Den Namen würde ich an die Linie machen. Die Frage halte ich generell für die schwierigste dabei. Wenn die Marktstraße über den Marktplatz führt, gebe ich dir recht. Wenn die Marktstraße durch den Marktplatz unterbrochen wird, dann nicht (und dann ist eine Linie über den Marktplatz auch nicht auf einmal Marktplatz). Wenn die Marktstraße zum Marktplatz führt und die Rathausstraße auf der anderen Seite weitergeht - welchen Namen würde bei dir dann die Linie bekommen? KORREKT ist die Linie nur, wenn sie als Straße existiert (und zwar unterscheidbar vom Platz; bei Fußgängerzonen oft nicht der Fall). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AFD nutzt Openstreetmap ohne Attribution in Wahlwerbeflyer in Bremen
Kannst ihn einscannen? On 2014-04-3 18:00, Dirk-Lüder Kreie wrote: Am 03.04.2014 16:34, schrieb malenki: On 02.04.2014 01:53, Dirk-Lüder Kreie wrote: Ich hab hier grad einen Wahlflyer der AfD hier in Bremen in der Hand und beim Wegwerfen fiel mir eine Karte darin auf, und siehe da, es ist ein Ausschnitt der Bremer OSM-Karte drin, aber ohne den notwendigen Hinweis auf die Quelle. Ein Beweisfoto vorm Wegwerfen wäre nicht die schlechteste Idee gewesen… Wenn du das verfolgen mächtest (ich hab derzeit zu viel zu tun) kann ich dir gerne ein Beweisstück im Original zukommen lassen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
On 03.04.2014 17:07, Tobias Knerr wrote: Am 03.04.2014 10:01, schrieb Manuel Reimer: bei uns hat vor einigen Tagen jemand eine Straße in eine Fläche umgewandelt: http://www.openstreetmap.org/way/270733792 Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten. Ist highway=pedestrian auf die Fläche überhaupt korrekt? Nein, hier überwiegt klar der lineare Charakter. Das ist kein Platz. +1 Im Unterschied zum Unterer Marktplatz ist das ja wohl eher eine Straße Du solltest m.E. die Linien mit den ursprünglichen Tags wieder herstellen und die neue Fläche zu area:highway=pedestrian umtaggen. +1, ja area:highway ist hier gefragt. Stehe bei mir auch vor dem Problem. Wie mappe ich eine Fußgängerzone, allerdings gibt es bei mir noch Straßenbahnschienen, Busse fahren und die Füßgängerzone darf von so einigen Fahrzeugen (zum Teil nur zu bestimmten Zeiten) benutzt werden. Dazu existieren auch noch Gehsteige, welche zum Teil als Arkaden unter den Häusern langführen. Ideen ? fly ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de: Am 01.04.2014 10:14, schrieb Falk Zscheile: Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen, um der möglichen Doppelbedeutung von tags entgegenzuwirken. Damit führst du doch eine Doppelbedeutung erst ein. Nein, entweder ist es redundant oder klarstellend. Aber jedenfalls keine Förderung von Doppelbedeutungen, denn im Gegensatz zu noexit=yes hat access:traffic_sign=DE:397 einen festen Bedeutungsinhalt, den du in der StVO nachschlagen kannst. Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, access:traffic_sign=DE:397 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit traffic_sign=DE:397 der Inhalt vollständig beschrieben. Und was machst du, wenn auf der Straße gleichzeitig noch eine Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da eine Lösung: access:traffic_sign=DE:value und parking:traffic_sign=DE:value und maxspeed:traffic_sign=DE:value Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur Straße nötig wäre, fehlt natürlich noch. access:traffic_sign statt traffic_sign wird jede Auswertung verhindern und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung beinhaltet. Ich bin optimistisch, dass die Vorteile meines Taggingingvorschlags auch andere zu würdigen wissen und sie vermehrt auftreten werden. Zur Not kann sich der Auswerter damit begnügen den value auszuwerten und zu schauen, ob der für seine Zwecke relevant ist. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. Aha? Übrigens heißt access nicht Zugangsbeschränkung sondern Zugang und darüber trifft traffic_sign=DE:397 sehr wohl eine Aussage. PS.: So handhabe ich es auch bei der Radweg-/Fußweg-/-kombinations-/Poblematik. Aber hoffentlich nicht mit access-Tags. s. o. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 15:20 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de:
Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre
mit traffic_sign=DE:397 der Inhalt vollständig beschrieben.
Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur
Straße nötig wäre, fehlt natürlich noch.
access:traffic_sign statt traffic_sign wird jede Auswertung verhindern
und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung
beinhaltet.
noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist
für das Schild nicht nur überflüssig sondern falsch.
+1, ich würde wenn ich Schilder erfassen würde (was ich derzeit nur für
Ortseingangsschilder und Geschwindigkeitsbegrenzungen, und Höhen-, Breiten-
und Gewichtsbegr. mache), das nicht an den Weg taggen, sondern an einen
node, eben so, wie man es auch antrifft. Dabei setze ich das Schild in
Fahrtrichtung rechts des Wegs in einem geringen Abstand, so dass die
Richtung normalerweise klar wird (bisher noch keine Ausnahme angetroffen,
gibt es aber vielleicht, kann man i.d.R. durch Optimieren der Abstände
regeln). Wenn man das Schild an den way setzt, dann führt das hinterher zu
ähnlichen Folgefehlern (durch Splitten des ways, Verschieben der Endnodes
etc.) wie bei den übrigen tags auch.
\begin{Ironie}So wie wir die Straßennamensschilder auch dort eintragen
wo sie stehen, aber keinesfalls den Namen an der Straße selbst, denn
da steht ja kein Namen auf den Asphalt gemalt?\end{Ironie}
Die Information gehört dorthin, wo sie sinnvoll ist und dass ist am
highway=value! So machen wir das bei oneway, maxspeed, maxweight/hight
etc. Also warum nicht auch bei allen anderen Verkehrsschildern, die
sich auf ein Wegstück und nicht auf einen Punkt (Fußgängerüberweg,
Ampel) beziehen?
Diese Schilder sehe ich als ggf. hilfreich für andere Mapper an, aber ich
erwarte davon nicht, dass deren Aussage von Datenkonsumenten wie Router etc
berücksichtigt wird, von daher setze ich das zusätzlich zu den
entsprechenden Auswirkungen / Interpretationen, die mit den entspr.
osm-tags auf den Weg-segmenten getaggt werden.
Ich trage die die Verkehrsschilder auf dem weg ein für den sie gelten
-- fertig. Was andere damit anfangen interessiert mich nicht, freue
mich aber natürlich, wenn es jemand nützlich findet. Und mir
persönlich hilft es klarzustellen, was genau für StVO-Eigenschaften
der Weg hat. aus vielen OSM-Tags geht das ja leider nicht klar hervor,
man denke nur an die Fuß-/Radwegproblematik ...
Gruß Falk
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 03.04.2014 20:16, schrieb Falk Zscheile: Und was machst du, wenn auf der Straße gleichzeitig noch eine Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Der Wert von traffic_sign kann ausdrücklich eine Semikolon-getrennte Liste von Schildern und Schildergruppen enthalten. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Hallo Stefan, hallo Falk, Am 03.04.2014 20:16, schrieb Falk Zscheile: Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de: Am 01.04.2014 10:14, schrieb Falk Zscheile: Ich bin dazu übergegangen im Verkehrsbereich (zusätzlich) zu den etablierten Tags von OSM auch explitzit das Straßenschild zu erfassen, um der möglichen Doppelbedeutung von tags entgegenzuwirken. Damit führst du doch eine Doppelbedeutung erst ein. Nein, entweder ist es redundant oder klarstellend. Aber jedenfalls keine Förderung von Doppelbedeutungen, denn im Gegensatz zu noexit=yes hat access:traffic_sign=DE:397 einen festen Bedeutungsinhalt, den du in der StVO nachschlagen kannst. Ich sehe im Tagging ebenfalls keine Doppelbedeutung. Denn traffic_sign=DE:397 sagt aus: Hier steht ein Schild und noexit=yes sagt aus: Diese Straße endet an diesem Punkt für alle Verkehrsteilnehmer. Es sollte zwar im Idealfall so sein, dass das Straßenschild das Tag noexit=yes impliziert, in der Realität sieht das aber anders aus. Außerdem würde ich traffic_sign=DE:397 nur da setzen, wo auch in der Realität ein Schild steht. Und zwar auch genau an die Stelle, wo es steht, also an in der Regel an den Anfang der Straße. Das Schilder-Tagging dient also dem Erfassen, wie es ausgeschildert ist. noexit hingegen bildet die faktische Realität ab, also ob die Straße tatsächlich eine Sackgasse ist. Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, access:traffic_sign=DE:397 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit traffic_sign=DE:397 der Inhalt vollständig beschrieben. Und was machst du, wenn auf der Straße gleichzeitig noch eine Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da eine Lösung: access:traffic_sign=DE:value und parking:traffic_sign=DE:value und maxspeed:traffic_sign=DE:value @Stefan: Nein, siehe oben. Das Schild beschreibt, wie ausgeschildert ist, noexit, wie die Realität aussieht. @Falk: Siehe oben, ich würde Verkehrsschilder immer dort mappen, wo sie stehen (nicht am Ende der Sackgasse). Zum Schildertagging würde ich sagen, ich tagge traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab. Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es Schilder, die mancher in parking, ein anderer in access einordnen würde. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. Aha? Übrigens heißt access nicht Zugangsbeschränkung sondern Zugang und darüber trifft traffic_sign=DE:397 sehr wohl eine Aussage. @Falk: Es könnte sein, dass Stefan meint, dass das Schild neben dem Weg am Anfang der Sackgasse steht und dort kein noexit=yes hinkommt. Gruß, Florian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
On 03.04.2014 20:29, Falk Zscheile wrote:
Am 3. April 2014 15:20 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de:
Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre
mit traffic_sign=DE:397 der Inhalt vollständig beschrieben.
Die Ausrichtung des Schildes, die für ein Rendering oder die Zuordnung zur
Straße nötig wäre, fehlt natürlich noch.
access:traffic_sign statt traffic_sign wird jede Auswertung verhindern
und passt auch logisch nicht, da das Schild keine Zugangsbeschränkung
beinhaltet.
noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist
für das Schild nicht nur überflüssig sondern falsch.
+1, ich würde wenn ich Schilder erfassen würde (was ich derzeit nur für
Ortseingangsschilder und Geschwindigkeitsbegrenzungen, und Höhen-, Breiten-
und Gewichtsbegr. mache), das nicht an den Weg taggen, sondern an einen
node, eben so, wie man es auch antrifft. Dabei setze ich das Schild in
Fahrtrichtung rechts des Wegs in einem geringen Abstand, so dass die
Richtung normalerweise klar wird (bisher noch keine Ausnahme angetroffen,
gibt es aber vielleicht, kann man i.d.R. durch Optimieren der Abstände
regeln). Wenn man das Schild an den way setzt, dann führt das hinterher zu
ähnlichen Folgefehlern (durch Splitten des ways, Verschieben der Endnodes
etc.) wie bei den übrigen tags auch.
\begin{Ironie}So wie wir die Straßennamensschilder auch dort eintragen
wo sie stehen, aber keinesfalls den Namen an der Straße selbst, denn
da steht ja kein Namen auf den Asphalt gemalt?\end{Ironie}
Die Information gehört dorthin, wo sie sinnvoll ist und dass ist am
highway=value! So machen wir das bei oneway, maxspeed, maxweight/hight
etc. Also warum nicht auch bei allen anderen Verkehrsschildern, die
sich auf ein Wegstück und nicht auf einen Punkt (Fußgängerüberweg,
Ampel) beziehen?
Diese Schilder sehe ich als ggf. hilfreich für andere Mapper an, aber ich
erwarte davon nicht, dass deren Aussage von Datenkonsumenten wie Router etc
berücksichtigt wird, von daher setze ich das zusätzlich zu den
entsprechenden Auswirkungen / Interpretationen, die mit den entspr.
osm-tags auf den Weg-segmenten getaggt werden.
Ich trage die die Verkehrsschilder auf dem weg ein für den sie gelten
-- fertig. Was andere damit anfangen interessiert mich nicht, freue
mich aber natürlich, wenn es jemand nützlich findet. Und mir
persönlich hilft es klarzustellen, was genau für StVO-Eigenschaften
der Weg hat. aus vielen OSM-Tags geht das ja leider nicht klar hervor,
man denke nur an die Fuß-/Radwegproblematik ...
In Deinem Tagging, hast Du dann aber zumindest die Richtung
unterschlagen (forward/backward).
Ich könnte ja auch gleich maxspeed=* weglassen und nur das
Verkehrszeichen eintragen, so ist OSM aber nicht aufgebaut. Wir
übersetzten eben genau diese Verkehrszeichen und tragen deren Bedeutung
in verständlichen Worten und Werten ein. Die genauen Schilder an den Weg
zu taggen zeigt doch eher, dass wir ein Problem mit unseren Tags und
deren Bedeutung haben (z.B. die lange Auseinandersetztung über blaue
Schilder und designated - official).
Deine Verkehrsschilder werden benutzt, aber nur wenn sie auch als Punkt
dort eingetragen werden, wo sie sich befinden.
Kannst Dir ja mal den kenzi3D-Plugin von JOSM anschauen.
Gruß fly
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 20:30 schrieb Tobias Knerr o...@tobias-knerr.de: Am 03.04.2014 20:16, schrieb Falk Zscheile: Und was machst du, wenn auf der Straße gleichzeitig noch eine Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Der Wert von traffic_sign kann ausdrücklich eine Semikolon-getrennte Liste von Schildern und Schildergruppen enthalten. Was genauso wenig ausgewertet wird, wie mein System. Mit Aufzählungen im value-Bereich tut man sich meines Wissens auch sehr schwer, oder? Bei mir ist nur klarer (für den Mapper), in welchem Bereich das Verkehrsschild eine Regelung trifft. Ich nehme eine Kategorisierung vor, indem ich access, parking, maxspeed dazu nehme. Am deutlichsten wird es bei maxspeed: maxspeed=30 und maxspeed:traffic_sign=DE:274-53. Da ist beim ersten lesen klar, um was es geht. Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 20:39 schrieb Florian Schäfer flor...@schaeferban.de: Am 03.04.2014 20:16, schrieb Falk Zscheile: Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de: Am 01.04.2014 10:14, schrieb Falk Zscheile: Im Falle eines Verkehrsschildes würde ich also mappen: noexit=yes, access:traffic_sign=DE:397 Wenn man das Schild erfassen will (ich finde das eher unnötig), dann wäre mit traffic_sign=DE:397 der Inhalt vollständig beschrieben. Und was machst du, wenn auf der Straße gleichzeitig noch eine Geschwindigkeitsbegrenzung und ein Halteverbot stehen. Ich habe da eine Lösung: access:traffic_sign=DE:value und parking:traffic_sign=DE:value und maxspeed:traffic_sign=DE:value @Stefan: Nein, siehe oben. Das Schild beschreibt, wie ausgeschildert ist, noexit, wie die Realität aussieht. @Falk: Siehe oben, ich würde Verkehrsschilder immer dort mappen, wo sie stehen (nicht am Ende der Sackgasse). Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll. Ich erinnere mich noch gut an die Klagen, von Leuten, die versucht haben die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das hat bei Stoppschildern nicht funktioniert, das funktioniert bei Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen Augen falsches Konzept übernehmen. Zum Schildertagging würde ich sagen, ich tagge traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab. Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es Schilder, die mancher in parking, ein anderer in access einordnen würde. Was genauso wenig ausgewertet wird, wie mein System. Mit Aufzählungen im value-Bereich tut man sich meines Wissens auch sehr schwer. Kennst du eine Anwendung, die das mittlerweile auswertet? Ich nehme eine Kategorisierung vor, indem ich access oder maxspeed dazu nehme. Gerade bei der zunehmenden Flut von tags an Straßen finde ich das sehr hilfreich. noexit=yes beschreibt, dass an diesem Punkt ein Weg blind endet, und ist für das Schild nicht nur überflüssig sondern falsch. Aha? Übrigens heißt access nicht Zugangsbeschränkung sondern Zugang und darüber trifft traffic_sign=DE:397 sehr wohl eine Aussage. @Falk: Es könnte sein, dass Stefan meint, dass das Schild neben dem Weg am Anfang der Sackgasse steht und dort kein noexit=yes hinkommt. Guter Hinweis! Danke :-) Gruß Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 03.04.2014 20:29, schrieb Falk Zscheile:
Am 3. April 2014 15:20 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
Am 3. April 2014 00:38 schrieb Stephan Wolff s.wo...@web.de:
+1, ich würde wenn ich Schilder erfassen würde (was ich derzeit nur für
Ortseingangsschilder und Geschwindigkeitsbegrenzungen, und Höhen-, Breiten-
und Gewichtsbegr. mache), das nicht an den Weg taggen, sondern an einen
node, eben so, wie man es auch antrifft. Dabei setze ich das Schild in
Fahrtrichtung rechts des Wegs in einem geringen Abstand, so dass die
Richtung normalerweise klar wird (bisher noch keine Ausnahme angetroffen,
gibt es aber vielleicht, kann man i.d.R. durch Optimieren der Abstände
regeln). Wenn man das Schild an den way setzt, dann führt das hinterher zu
ähnlichen Folgefehlern (durch Splitten des ways, Verschieben der Endnodes
etc.) wie bei den übrigen tags auch.
\begin{Ironie}So wie wir die Straßennamensschilder auch dort eintragen
wo sie stehen, aber keinesfalls den Namen an der Straße selbst, denn
da steht ja kein Namen auf den Asphalt gemalt?\end{Ironie}
Die Information gehört dorthin, wo sie sinnvoll ist und dass ist am
highway=value! So machen wir das bei oneway, maxspeed, maxweight/hight
etc. Also warum nicht auch bei allen anderen Verkehrsschildern, die
sich auf ein Wegstück und nicht auf einen Punkt (Fußgängerüberweg,
Ampel) beziehen?
Der Unterschied ist, dass an den Weg die Information kommt, was das
Schild aussagt.
Beim Straßenschild der Straßenname, bei DE:274:30 ist es maxspeed=30/
/Die Information, welches Schild dort steht und wo es steht, würde ich
an die genaue Position des Schildes (neben der Straße) taggen, _wenn_
ich Schilder mappen würde. Und die Auswirkungen des Schildes (maxspeed,
access, ...) auf den Weg, um die Ausdehnung des Gültigkeitsbereichs
deutlich zu machen und die Auswertung zu vereinfachen. Ausnahme
natürlich noexit=yes, wo es der Endnode statt dem Weg ist.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 03.04.2014 20:52, schrieb Falk Zscheile: Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll. Ich erinnere mich noch gut an die Klagen, von Leuten, die versucht haben die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das hat bei Stoppschildern nicht funktioniert, das funktioniert bei Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen Augen falsches Konzept übernehmen. Aber Du möchtest doch wie ich das verstanden habe auch punktförmige Schilder mappen, oder? Zum Thema mit den Straßennamen, siehe meine andere Mail zum Unterschied zwischen Aussage eines Schilds und Schild. Zum Schildertagging würde ich sagen, ich tagge traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab. Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es Schilder, die mancher in parking, ein anderer in access einordnen würde. Was genauso wenig ausgewertet wird, wie mein System. Was weder ein Argument für das eine, noch für das andere System ist. Mit Aufzählungen im value-Bereich tut man sich meines Wissens auch sehr schwer. Kennst du eine Anwendung, die das mittlerweile auswertet? Ich habe vor einiger Zeit mal eine gebaut (zwar nicht im Zusammenhang mit Straßenschildern, sondern mit POIs) ;-P. Und so schwer wäre das auch nicht umzusetzen. Ich nehme eine Kategorisierung vor, indem ich access oder maxspeed dazu nehme. Gerade bei der zunehmenden Flut von tags an Straßen finde ich das sehr hilfreich. Die Kategorisierung ist aber durch den Value für traffic_sign schon impliziert. Du hättest dann Probleme mit so etwas wie maxspeed:traffic_sign=DE:250 Das würde dann in etwa bedeuten: Die Höchstgeschwindigkeit ist, dass hier kein Fahrzeug durchfahren darf./ / Übrigens, nur um es klarzustellen: Ich bin eigentlich kein Fan vom Tagging von Verkehrsschildern. Wenn das aber gemacht wird, dann sollte die Art und Weise möglichst einheitlich sein und ein gewisser Konsens dazu herrschen, sonst wird es niemals ausgewertet werden. Gruß, Florian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 03/apr/2014 um 18:48 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wir taggen nicht falsch für den Router! (genausowenig wie für's Rendering). yep, richtig allerdings schon auch für den Router. Wieso hältst Du das für falsch? Wie tagst Du dann ohne linearen way eine Einbahnstraße in der Fußgängerzone? Gruß, Smarten ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Am 3. April 2014 21:13 schrieb Florian Schäfer flor...@schaeferban.de: Am 03.04.2014 20:52, schrieb Falk Zscheile: Wie gesagt, bei Straßennamen handhaben wir das anders und ich halte das auch bei anderen (hier Verkehrs-) Schildern für sinnvoll. Ich erinnere mich noch gut an die Klagen, von Leuten, die versucht haben die Bedeutung von als Punkt eingetragenen Schildern auszuwerten. Das hat bei Stoppschildern nicht funktioniert, das funktioniert bei Ortseingangsschildern nicht ... Deshalb will ich nicht ein in meinen Augen falsches Konzept übernehmen. Aber Du möchtest doch wie ich das verstanden habe auch punktförmige Schilder mappen, oder? Nein, das möchte ich nicht. Zum Thema mit den Straßennamen, siehe meine andere Mail zum Unterschied zwischen Aussage eines Schilds und Schild. Zum Schildertagging würde ich sagen, ich tagge traffic_sign=DE:value1;DE:value2;DE:value3 oder alternativ 3 Nodes nahe beieinander. Denn die Funktion des Schilds leitet sich aus dem Value ab. Das würde auch Missverständnissen vorbeugen. Vielleicht gibt es Schilder, die mancher in parking, ein anderer in access einordnen würde. Was genauso wenig ausgewertet wird, wie mein System. Was weder ein Argument für das eine, noch für das andere System ist. Absolut richtig. Meines gefällt mir nur besser :-) Mit Aufzählungen im value-Bereich tut man sich meines Wissens auch sehr schwer. Kennst du eine Anwendung, die das mittlerweile auswertet? Ich habe vor einiger Zeit mal eine gebaut (zwar nicht im Zusammenhang mit Straßenschildern, sondern mit POIs) ;-P. Und so schwer wäre das auch nicht umzusetzen. Gut zu wissen. Und schön zu hören, dass es Fortschritte gibt. Ich nehme eine Kategorisierung vor, indem ich access oder maxspeed dazu nehme. Gerade bei der zunehmenden Flut von tags an Straßen finde ich das sehr hilfreich. Die Kategorisierung ist aber durch den Value für traffic_sign schon impliziert. Du hättest dann Probleme mit so etwas wie maxspeed:traffic_sign=DE:250 Das würde dann in etwa bedeuten: Die Höchstgeschwindigkeit ist, dass hier kein Fahrzeug durchfahren darf. Ich gebe zu, dass Problem hätte man nicht, wenn man alles in eine Aufzählung von traffic_sign packt. aber für sotewas gibt es ja keep it right und ähnliches (falls sich meine Idee jemals durchsetzen sollte). Mit meinem System des kategorisierenden Taggens von Verkehrsschildern hat man aber zumindest die Chance Fehler bei der Eintragung zu erkennen. Bei einer Aufzählung aller an der Straße vorhandenen Verkehrsschilder sind die Möglichkeiten, um fehler zu erkennen, ungleich geringer, weil der key hier nicht die Richtung für den value angibt. Dies führt zu einem generellen Problem bei so abstrakten Angaben wie die StVO-Nummer von Verkehrsschildern. Bei amenity=secondary wird jeder stutzig bei traffic_sign=DE:4711 nicht unbedingt. Übrigens, nur um es klarzustellen: Ich bin eigentlich kein Fan vom Tagging von Verkehrsschildern. Das ist mir nicht entgangen :-) Wenn das aber gemacht wird, dann sollte die Art und Weise möglichst einheitlich sein und ein gewisser Konsens dazu herrschen, sonst wird es niemals ausgewertet werden. Ich nehme die hier vorgebrachten Einwände mit Interesse zur Kenntnis, auch wenn sie mich im Augenblick nicht überzeugen. Man muss ja auch mal was ausprobieren und schauen, ob man damit mehr bestehende OSM-Probleme löst als neue schafft :-) Viele Grüße Falk ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Meinungsbild noexit (Versuch einer Zusammenfassung)
Wenn das aber gemacht wird, dann sollte die Art und Weise möglichst einheitlich sein und ein gewisser Konsens dazu herrschen, sonst wird es niemals ausgewertet werden. Ich nehme die hier vorgebrachten Einwände mit Interesse zur Kenntnis, auch wenn sie mich im Augenblick nicht überzeugen. Man muss ja auch mal was ausprobieren und schauen, ob man damit mehr bestehende OSM-Probleme löst als neue schafft :-) Viele Grüße Falk Klar, probieren geht oft über studieren. Und insbesondere bei OSM hilft es oft, einfach mal zu machen, statt eine endlose Diskussion vom Zaun zu brechen. OK, dann haben wir das denke ich fürs erste ausdiskutiert. Übrigens geht die Diskussion gerade auf der Tagging-ML weiter ;-) (ich war's diesmal nicht). Viele Grüße, Florian ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konverter XErleben - OSM
Hallo Ich denke die Idee mit der Wiki Seite ist auf jedenfall nicht schlecht. Über den Disskussionsbereich lassen sich dann ja auch Diskussionen zu einzelnen Tags starten und es bleibt tortzdem übersichtlich. mfg Christian Am 3. April 2014 17:31 schrieb Archer arc...@gulli.com: Zur Brennerei findet man unter How to map a folgende Anmerkung: Brennerei: craft=distillery + distillery=* Am 3. April 2014 17:16 schrieb EFTAS Christian Röttger christian.roett...@eftas.com: Hallo, diese aktuelle Tabelle ist nur zur Kategorisierung gedacht. Tags wie name, adresse, etc. sollen natürlich als normale Attribute mit übernommen werden aber nicht unbedingt der Kategorisierung dienen. Wir haben uns erst einmal an den Map Features entlang geangelt, hauptsächlich in Englisch und auch Seiten wie http://wiki.openstreetmap.org/wiki/DE:How_to_map_a und http://wiki.osm.org/wiki/Map_Features zum besseren Verständniss. Auch TagInfo hat die ein oder andere Info gebracht. Das Thema ist halt sehr komplex und kann sich nur sukzessiv entwickeln. Craft: brewery benutzen wir ja auch für eine Brauerei. Aber für eine Destillerie passt es nicht unbedingt. Auch kann man natürlich zu jedem Tag eine eigene Diskussion aufmachen, da es diverse Meinungen und Sichtweisen gibt. Wir möchten versuchen daraus einen recht ordentlichen Konsens zu schaffen. Viele Grüße Christian Betreff: Re: [Talk-de] Konverter XErleben - OSM Am 03.04.2014 11:31, schrieb EFTAS Christian Röttger: Hallo liebe OSM-Community, Hallo, Bei der Zuordnung der Brennerei kommen wir zu dem ersten Problem. In der offiziellenMap Features Liste ( http://wiki.osm.org/wiki/DE:Map_Features) gibt es noch keinen entsprechenden Tag um diese Funktion eines POI zu beschreiben. Weil nicht eindeutige Zuordnungen häufiger auftauchen hoffen wir auf die Zusammenarbeit mit der OSM Community. Die Lösung könnte z.B. die Einführung neuer Tags sein, aber da sind wir für alle Lösungsvorschläge offen und dankbar. Die Map Features beinhalten nicht alle tags, und man sollte sich nicht daran klammern. Bei nicht vorhandenen tags in DE:Mapfeatures solltet ihr sprachunabhängig suchen, beispielsweise gibt es ein craft=brewery schon, wie ihr vielleicht schon gemerkt habt. http://wiki.openstreetmap.org/wiki/Tag:craft%3Dbrewery Unsere Idee ist, diese Zuordnungsliste frei verfügbar zu machen (z.B. auf einer Seite im OSM Wiki) und dort zu pflegen, um anderen Kommunen, Personen, etc. Hilfestellung beim Import/Export von Daten in OSM zu ermöglichen. Eine erste Arbeitsversion befindet sich momentan unter https://docs.google.com/file/d/0B5hzMGhyvOK6c1dDQ21pYUxZZFE. Aber es existieren noch viele leere Zeilen (s.o.) und Unklarheiten, welche Tag-Kombinationen die Richtigen sind. Hier hoffen wir auf den Input der erfahreneren OSM Mapper, um gemeinsam diese Lücken zu füllen. Evtl. haben wir als schönen Nebeneffekt, dass das Wiki in Bereichen mit leicht widersprüchlichen Angaben harmonisiert wird. Mit taginfo lassen sich tags überprüfen (z.B. Wie oft benutzt? ; Mit welchen Kombinationen? ; usw.) http://taginfo.openstreetmap.org Ich habe jedoch Zweifel, ob für Kombinationen nur ein zusätzliches Wertepaar ausreicht. Da müsste man schon Wissen welche Infos für euch in der Kombination relevant sind. Beispielsweise amenity=restaurant, da gibt es einige mögliche zusätzliche Infos wie z.B. Name, Öffnungszeiten, Art der Küche, Rauchen, Rollstuhltauglichkeit, WLan, usw. Wie wollt ihr diese Problematik lösen? http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant Mit freundlichen Grüßen Christian Röttger Grüße René ___ 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 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] Wochennotiz Nr. 193 25.3.-31.3.2014
Hallo, die Wochennotiz Nr. 193 mit allen wichtigen Neuigkeiten aus der OpenStreetMap Welt ist da: http://blog.openstreetmap.de/blog/2014/04/wochennotiz-nr-193/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 03.04.2014 21:16, schrieb Martin Koppenhoefer: Am 03/apr/2014 um 18:48 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wir taggen nicht falsch für den Router! (genausowenig wie für's Rendering). yep, richtig allerdings schon auch für den Router. Wieso hältst Du das für falsch? Gegen eine existierende (!) lineare Spur über den Platz habe ich nichts, das würd ich auch eintragen - also wenn die z.B. markiert ist, durch Bordsteine, Rinnsteine, Straßenmarkierung etc. Falsch halte ich es, wenn es sich um offene Plätze handelt, bei denen Autos eben einfach nur die gerade Linie zwischen Ein- und Ausgang nutzen, ohne dass dies vorgeschrieben oder markiert wäre - gerade beim Marktplatz in der Fußgängerzone durchaus denkbar und üblich. Wie tagst Du dann ohne linearen way eine Einbahnstraße in der Fußgängerzone? Wenn es eine Einbahnstraße ist, dann gibt es üblicherweise auch einen definierten Fahrweg und der kann als solcher ja auch wie üblich eingetragen werden. Ist aber die Durchfahrt verboten oder nur für Lieferverkehr erlaubt, gibt es einen solchen Fahrweg z.T. eben nicht, sondern der Platz ist bzgl. der Nutzung durch Fahrzeuge auf der ganzen Fläche gleichwertig, dann ist eben auch ein Weg drüber in OSM fehl am Platz, der in dem Fall nämlich nur den Router zufriedenstellt, der die direkte Verbindung zwischen Ein- und Ausfahrtspunkt dann nicht berechnen muss, sondern vorgekaut kriegt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 03/apr/2014 um 23:19 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wenn es eine Einbahnstraße ist, dann gibt es üblicherweise auch einen definierten Fahrweg In den Fußgängerzonen die ich kenne ist das normalerweise eine gepflasterte einheitliche Fläche ohne Bordsteine oder Fahrbahnmarkierungen (egal ob Einbahnstraße oder nicht), aber eine klare Richtung haben sie meistens trotzdem (ohne Fahrbahnmarkierungen gilt AFAIK auch innerorts das Rechtsfahrgebot) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
