Re: [Talk-de] Grundriss vs Dachfläche
Moin, ich habe nochmal das Problem im Wiki nieder geschrieben und probiert eine Lösung zu formulieren. Auch wenn hier einige behauptet haben, dass in der OSM die Mauer am Boden das Ziel ist, kann ich im Wiki nicht so viel dazu finden. Dort wo so etwas erwähnt wird, geht es um Dachüberstände. Aber lest selbst. http://wiki.openstreetmap.org/wiki/DE_talk:Buildings#Umriss.2C_Grundriss.2C_Grundrisslinie_und_Mauern_am_Boden:_.C3.9Cberarbeitung_des_building-Tags LG cracklinrain ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Kurz vorweg: Sorry für mögliche doppelte Antwort. Am 12.01.2014 20:29, schrieb Martin Koppenhoefer: ja, da stand ja auch zum Beispiel, mit dem building-key sollte man (m.E.) ausser der Überdachung nichts taggen, sondern ggf. die Dachfläche (bzw. das Dach mit Neigung und Überständen etc.) im 3D-Mapping, und definiert als Teil des Gebäudes (über den key). Grundriss bezeichnet normalerweise den Plan einer Etage und hat hier m.E. nichts in der Diskussion zu suchen. Sorry für die Frage. Ich sehe gerade, dass das im deutschen Wiki auch teilweise beantwortet ist. http://wiki.openstreetmap.org/wiki/DE:Buildings#Umriss Trotzdem bleiben meinerseits Fragen offen: So wie ich das nun verstehe gibt es da in OSM eine Coexistenz zweier Umrisserfassungsmöglichkeiten. Einmal die Erfassung der Außenwand am Boden und dann die Grundrisslinie. Ich würde es für sinnvoll halten zu Gebäuden nach Möglichkeit beide Flächen in der OSM zu haben. Der einfachste Weg wäre wahrscheinlich eine neue Rolle in der building-Relation. Aber welche soll schließlich den Building-Tag tragen? Ich finde, dass das wiki dazu eine Aussage treffen sollte. Zum 3D-Mapping: Es gibt dort derzeit die Rolle outline. Allerdings weiß ich nun nicht, ob damit nicht vielleicht die Gebäudewand am Boden gemeint ist. Beispiele: Die Portale des Bremer Doms schneiden zum Beispiel in den Grundriss, den das LfD bereitstellt, eine Aussparung, die nur am Boden existiert. Das heißt über dieser Fläche, die dort ausgespart ist befindet sich zum Beispiel Mauer oder übrige Gebäudeteile wie teilweise die Türme. Hier die Aussparung, die bei der Erfassung der Mauer am Boden nicht zum Umriss gehören würde. http://www.openstreetmap.org/way/211749964 Hier ein Link zu der Karte beim LfD. http://194.95.254.61/cgi-denk/getdoc.pl?DEF=/home/schwartz/daten/bremenDATEN=/home/schwartz/daten/datenTHE=/home/schwartz/daten/idxDOK_TPL=lfd_bremen_doc2.tplKEY=obj%200314 Es gibt auch Beispiele bei denen nahezu das gesamte Gebäude verschwindet, wenn man die Mauer am Boden als Gebäudeweg erfasst: http://194.95.254.61/denkmalpflege/jpg1/1009a05.jpg Hier der Link zur Seite beim LfD. http://194.95.254.61/cgi-denk/getdoc.pl?DEF=/home/schwartz/daten/bremenDATEN=/home/schwartz/daten/datenTHE=/home/schwartz/daten/idxDOK_TPL=lfd_bremen_doc2.tplKEY=obj%201009 Die freistehenden Gebäudeteile wie Dächer etc sind hier mit einem X durchgestrichen. BTW: Wer sich die Bilder ansieht, wird vielleicht bemerken, dass das so nicht ganz richtig sein kann - abgesehen davon ein valides Beispiel für mein Problem. So wie ich nun die Grundrisslinie verstanden habe, ist in OSM alles soweit nach Grundrisslinie getagt. Nun wäre es aber auch sinnvoll das Gebäude nach Mauer am Boden zu taggen und mappen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 12:29, schrieb Ronnie Soak: Ich weiß nicht ob die 3D Renderer in letzter Zeit toleranter geworden sind, aber bei einem Turm mit Kopf muss die Umrisslinie des Kopfes als building eingetragen werden (also die breiteste Stelle), und nicht die Aufstandsfläche des Turmfußes. Auslegungssache. Ich würde sagen, dann muss weiterhin die Aufstandsfläche gemappt werden und ggfs. ein falsches Renderergebnis in Kauf genommen werden, bis der Renderer das vernünftig unterstützt. Wenn ich an Dächer Denke, ist das derzeit aber nicht Praxis. Man müsste dann die Dachstützen statt der Dachfläche mappen. Oder mit welcher Begründung ist hier ein einzelner Spezialrenderer plötzlich ausschlaggebend für die Auslegung bestehender Taggingpraxis? Das hat mit dem Renderer nichts zu tun. Wenn die Frage für mich klar wäre, was erfasst wird, würde ich den Anwender/Renderer darauf hinweisen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 14:52, schrieb Tobias Knerr: Dass tatsächlich nur der Umriss auf dem Erdboden gemappt würde, ist auch in der Praxis nicht unbedingt der Fall, denn bei Gebäuden auf Pfeilern u.ä. Konstruktionen vermitteln ein paar einsame Punkte ein völlig verzerrtes Bild vom Gebäude. Wobei man beim 3D-Mapping tendenziell ohnehin alle Infos braucht. Und ich halte es auch keineswegs für abwegig, dass das 3D-Rendering eine wichtige Rolle bei der Etablierung solcher Definitionen spielt. Schließlich ist das der erste Anwendungsfall, in dessen Rahmen die vertikale Dimension von Gebäuden überhaupt nennenswert berücksichtigt wird. +1 Aber beim 3D-Modellieren könnte man zur Not doch auch das Modell so ändern, dass neben der Mauer am Boden auch die größte Fläche, die das Gebäude beschreibt gemapt wird (nicht unbedingt mit dem building-Tag) - das würde ich dort zumindest als wünschenswertes Ziel sehen. Das heißt: Eigentlich motiviert das 3D-Modellieren erstmalig das Mappen der Mauer am Boden. Bisher sehe ich da nur Tags wie tunnel=building_passage oder covered=yes, die suggerieren, dass es nicht um die Mauer am Boden geht. Trotzdem: Aus meiner Sicht gibt es derzeit keine Saubere Definition der building-Fläche im Wiki. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 13.01.2014 19:35, schrieb Martin Koppenhoefer: Am 13. Januar 2014 14:52 schrieb Tobias Knerr o...@tobias-knerr.de: Wir reden nicht von einem einzelnen Renderer, sondern von einer software-übergreifenden Konvention fürs 3D-Mapping und -Rendering. Nach dieser Definition wäre die building-Fläche der Gesamt-Mauerumriss aller Stockwerke, um es mal so auszudrücken. was allerdings gravierende Nachteile für alle die hätte, die sich die Welt nur in 2D ansehen, weil für die in manchen Fällen ein völlig verzerrtes Bild der Freiräume auf der Ebene entsteht, die für sie ggf. zugänglich ist (aussen drum herum). Ich finde, dass an beiden Positionen etwas dran ist. Aber letztendlich sollte das doch der Renderer entscheiden können. Vor allem sollten die Positionen aber nicht als Gegenposition verstanden werden, weil wie gesagt für die 3D-Modelle alle Daten wichtig sind. Zuletzt liegt es aber auch nicht an den 3D-Tags, dass ein Gebäude, durch das eine Einfahrt verläuft, in OSM als eine durchgehende Fläche gemapt wird. wobei die Leute, die 3D betreiben, da ein ziemlich isoliertes Süppchen kochen, und (zumindest noch vor einiger Zeit, vielleicht ist das ja jetzt besser geworden) auch verschiedene Konzepte parallel umgesetzt werden. Wer tag-Definitionen etablieren will, sollte sich auch auf [tagging] mit der Kommunity auseinandersetzen und sehen, ob seine Vorstellungen in Teilbereichen evtl. mit anderen Erfordernissen bzw. Setzungen kollidieren, und wie man das am besten unter einen Hut bekommen kann. Ich erinnere mich z.B. an die building:levels (Stockwerksanzahl), wo einfach mal jemand ein Schaubild ins Wiki gestellt hat, dass es sich dabei nur um überirdische Stockwerke handele, dafür aber nichtexistierende Stockwerke mitgezählt werden bei kragenden Bauteilen. Nach einiger Zeit hiess es dann, das sei etabliert und so ist der Stand AFAIK noch heute, wobei ich das für extrem fehlerträchtig und unintuitiv halte. +1. Ich benutze das zwar häufig, aber vom intuitiven Verständnis würde jeder vermuten, dass dieser Key die Gesamtstockwerkezahl des Gebäudes beschreibt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schienenkreuze und Weichen
Am 13.01.2014 02:00, schrieb Michael Kugelmann: Am 30.12.2013 13:26, schrieb Andreas Neumann: Bei der Schienen ist mir ein kleines Dilemma aufgefallen. Beispiel an diesem Straßenbahn-Schienenkreuz http://osm.org/go/0MAe~EE4F BTW: eine Idee meinerseits war auch Abbiege-Relationen zu verwenden (wie bei Straßen für Autos). In Bremen gibt es auch solche Straßenbahnschienenkreuze. Dort haben wir das mit railway=railway_crossing gelöst: http://www.openstreetmap.org/node/2573586593 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Grundriss vs Dachfläche
Liebe Gebäude-Mapper, 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. In Bremen gibt es in der OSM schon seit längerem Gebäude anhand ihrer Grundrisse aus Importen neben Gebäuden anhand ihrer Dachfläche gemapt. Das kann sehr problematisch sein, denn es gibt bei den Grundrissen immer wieder mir unerklärliche Abweichungen und Löcher. Das mögen zunächst möglicherweise Ungenauigkeiten vom Import als auch der Mapper-Handarbeit sein. Aber es gibt ja auch tatsächliche Unterschiede wie Dachüberstände, die zu Differenzen führen. Weil uns Mappern in der Regel nur Luftbilder zur Verfügung stehen, hatte ich die Lage bisher so eingeschätzt, dass die Dachflächen gemapt werden. Ich sehe allerdings, dass es Anwendungen für die OSM gibt, die den Grundriss gegenüber der Dachfläche bevorzugen. Im Wiki habe ich dazu noch keine konkrete Erläuterung gefunden und am Rande der Diskussionsbeiträge zum Gebäudeimport in NRW habe ich die Äußerungen teilweise so wahrgenommen, dass es Mapper gibt, die den Grundriss wichtiger finden. Aus meiner Sicht sind Grundrisse eine nette Ergänzung zum gesamten Gebäude: * Anhand von Grundrissen ist leichter erkennbar wo man sich auf dem Grund entlang bewegen kann. * Dachüberstände lassen Gassen oft schmaler erscheinen oder sogar verschwinden - mit Grundrissen passier so etwas nicht. * Statische Elemente wie freistehende Stützen bzw. Säulen sind lokalisierbar und können als Hindernis erkannt werden. * Grundrisse sind für das Indoormapping wichtig. Das ist eigentlich nicht sehr viel was für Grundrisse spricht. Die wichtigeren Informationen liefert aus meiner Sicht die Dachfläche: * Es gibt zahlreiche Tags wie covered=* und tunnel=building_passage, die markieren, wenn ein Weg durch Gebäude verläuft. * Man erkennt leichter welcher Grund durch Gebäude bedeckt ist. * Ein Dach umschließt meist das gesamte Gebäude, daher sind mehrere Gebäude leichter erkennbar - was auf vielen Karten wichtig ist. * Einige Gebäudetypen sind durch Grundrisse nicht sinnvoll darstellbar (z.B. Carports, Bahngleisüberdachungen/Unterstände und weitere Dächer vom Typ building=roof) * Viele Gebäude haben einen Überhang, durch den das Gebäude deutlich größer ist, als es der Grundriss angibt. * Dachflächen sind deutlich leichter verifizier- und erfassbar. Das ist das, was mir dazu im Moment einfällt. Ich würde mir es nun allerdings weiterhin so wünschen, dass Dachflächen den Tag building=* erhalten und Grundrisse z.B. per building-Relation referenziert werden. Das hat den Vorteil, dass man z.B. beim Indoormapping auf diese zurückgreifen kann. Wenn Grundriss und Dachfläche referenziert sind, kann ein Anwender wählen, ob z.B. Grundriss oder Dachflächen gerendert werden sollen. Es gibt zwar bereits ein Proposal zur building-Relation, das auch eine Rolle outline einschließt, jedoch wird dort nicht die Dachfläche thematisiert. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings Aus meiner Sicht müsste man dieses Proposal noch einmal differenzieren. Vielen Dank schon einmal für eure Meinungen, weitere wichtige Aspekte und links zu verwandten Themen. LG cracklinrain ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 11.01.2014 18:57, schrieb Markus: Dafür braucht man zwei unterschiedliche tags. Beispielsweise: building=Dachfläche building=Grundriss building=Überdachung (laut Frank: Bauwerke wie Carport, etc) Im übertragenen Sinn sieht es in der OSM so aus: building Beschreibt all diese Gebäude. Aber die Werte vom building-Tag beschreiben natürlich die genauere Gebäudespezifizierung. Wenn man all diese Tags auf ein Gebäude anwenden würde, wären das für jede Anwendung drei verschiedene Gebäude übereinander bzw. ineinander, obwohl es ja nur eins sein sollte. Jeder kann hinschreiben was er gemacht hat, man kann auch alles kombinieren, und der Renderer kann das auseinanderhalten. So einen Hinweis fände ich ja schon nicht schlecht, aber es löst nicht das Problem, welcher Weg der eigentliche building-Weg ist. Die anderen (Dachüberstände einschließenden) sollten aus meiner Sicht auf jeden Fall irgendwie in der OSM sein. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 11.01.2014 18:31, schrieb Frank: hier findet in der Tat gerade eine Vermischung beider Erfassungsmethoden statt, die kaum noch zu trennen ist. Bisher wurden die Gebäude meist nach Luftbild gemappt also einschließlich der Dachüberstände. Ich beobachte, dass zur Zeit massenhaft Gebäude mit dem tracer2-plugin erfasst werden. Ich musste mir schon Klagen meiner Nachbar-Mapper anhören weil dabei zum Teil vorhandene Gebäude falsch überschrieben wurden, die zuvor mit Aufwand vor Ort erfasst worden waren. Tracer2 nutzt die ALK- bzw. ALKIS-Grundrissdarstellung um aus dem dargestellten Bild des Gebäudeumrings (Raster) aus einem WMS wieder Vektordaten zu machen. Ich kenne die ALKIS-Daten recht gut, weil ich beruflich damit zu tun habe. ALKIS und das Vorgängerverfahren ALK zeigen den Gebäudegrundriß, also Außenmauer im Bodenbereich. Normale Dachüberstände werden nicht mit erfasst. Überdachungen sind in ALKIS nicht Gebäude sondern Bauwerke und werden anders dargestellt. Das können z.B. Carports sein, Tankstellen-Dächer, Dächer über der Laderampe eines Industriegebäudes oder *überdachte Terrassen* oder Balkone. Gibt es einen Tag für Bauwerke in OSM? Carports wären ja nach der Definition Bauwerke, würden in OSM aber als building=roof erfasst. Nun sagen andere hier, dass in der Kartographie in Deutschland Gebäude immer anhand ihrer Grundfläche erfasst werden. Wenn ich den Artikel zur Grundfläche auf Wikipedia nicht falsch verstehe, zählen Balkone in Deutschland nicht zur Grundfläche, aber zum Bauwerk bzw. sind Bauwerk. https://de.wikipedia.org/wiki/Grundfl%C3%A4che_%28Architektur%29 Carports hingegen sind dann Bauwerke aber keine Gebäude? Könnte ich soweit von Amtswegen nachvollziehen. In OSM heißt das aber mit anderen Worten, dass es da diese Unterscheidung zwischen Bauwerk und Gebäude nicht gibt. Wie ist das denn international? Ist eine Hütte noch/schon ein Gebäude? Und was ist mit einem Wohnwagen, vor den ein Vordach gebaut ist. Den könnte man doch dann mindestens mit building=roof taggen. Letzteres führt zu folgendem Effekt: Die Grundmauern rechts und links der Terrasse oder des Balkons gehören zum Grundriß. Dazwischen ist die Überdachung als Bauwerk dargestellt. Tracer2 importiert nur den Grundriss, stellt also die Mauern als Stacheln am Gebäude dar und ignoriert die Überdachung (Bauwerk) dazwischen. Beispiel: http://www.openstreetmap.org/way/251724992 http://www.openstreetmap.org/#map=19/52.02577/8.89731 oder http://www.openstreetmap.org/way/251754777 Vielen Dank für diese Erläuterung! Nachdem mir nun ALK erklärt wurde, erkenne ich das wohl aus Bremen alles wieder soweit. Eine nach innen verspringende Terrasse sollte außen (Dachkante) begradigt werden. Also gehören nach ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 11.01.2014 19:38, schrieb Norbert Kück: Hausumringe, die Außenlinie des Grundrisses an der Geländeoberkante sind die Geometrien, die in herkömmlichen Karten und Plänen enthalten sind. Und was ist mit reinen Dachkonstrukten? Ich habe hier mal einen Link auf den Bremer Bahnhof in dessen Umgebung es einige Überdachungen gibt, die durchgestrichen dargestellt sind. Selbst das riesige Bahnhofsdach ist in der Karte als Dach eingezeichnet. http://194.95.254.61/cgi-denk/getdoc.pl?DEF=/home/schwartz/daten/bremenDATEN=/home/schwartz/daten/datenTHE=/home/schwartz/daten/idxDOK_TPL=lfd_bremen_doc2.tplKEY=obj%200100 Schaut man sich beim Geoportal die Karte an http://www.geoportal.de/DE/Geoportal/Karten/karten.html?lang=debbox=487187.665629,5881397.041579,487942.481255,5881745.785507background=hintergrundkarte ist das ähnlich, aber ohne Dächer. Der unterirdische Bunker unter dem Busbahnhof ist auch als Gebäude eingezeichnet. 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. Ich vermute mal, dass das Sarkasmus ist und nicht ernst gemeint war. Es gibt ja schon einige oft benutzte Tags, die mit dieser Ansicht nicht vereinbar sind. Zum Beispiel http://taginfo.openstreetmap.org/tags/building=roof Gut. Das mag die Einschränkung sein. Aber ich möchte auch bezweifeln, dass solch ein Kartographieren ohne Importe möglich ist. Und dann kann man besser sagen: Leute lasst es einfach. Wir löschen das sowieso alles und importieren lieber vom Amt. Und welcher Mapper soll schon verstehen, dass der Dachüberstand und der Balkon über der Kellertreppe nicht zum Gebäude gehören, aber ein Dach als building=roof gemappt wird. Und doch finde ich building=roof als laie irgendwie sinnvoll. Auch wenn es nur ein Bauwerk ist. Außerdem gibt es noch Kandidaten wie building=bridge, die sinnvoll sind, aber http://wiki.openstreetmap.org/wiki/Tag:building%3Dbridge Dachflächen sind gut für spezielle Anwendungen. Auf einer Landkarte oder in einem Stadtplan würde ich sie nicht erwarten. Siehe oben. Auch wenn ich es so total klar finde, dass ein unterirdischer Bunker ein Gebäude ist, würde ich so etwas auch nicht auf einem Stadtplan als Gebäude erwarten. Ist das so üblich? Gibt es dafür einen Tag in OSM? Ist das wirklich der building-Tag? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grundriss vs Dachfläche
Am 11.01.2014 20:08, schrieb Tobias Knerr: Am 11.01.2014 18:37, schrieb chris66: Pragmatische Antwort: Luftbildabzeichner erfassen die Dachfläche Auch beim Luftbildzeichnen kann man darauf achten, die Fläche halbwegs korrekt am Grundriss auszurichten. Und generell sehe ich schon, dass das oft auch so gehandhabt wird. Nur wenige würden ein Gebäude, das neben der Straße steht, über die Straße drüber malen, nur weil das Dach im Luftbild hineinragt. Es geht hier schon um Luftbildabzeichner, die das Gebäude danach noch einmal um die perspektivische Verschiebung korrigieren. Mein Problem ist jetzt: Was bezeichnet die Gebäudefläche in OSM? Der tatsächlich (und nicht nur im Luftbild) über die Straße ragende Gebäudeteil und der Rest vom Gebäude oder nur der Gebäudegrundriss. Also das Gebäude am Boden. Dächer haben ja z.B. keine Wände am Boden und werden dennoch im building-Tag erfasst. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Voting landuse=highway
Am 05.12.2013 00:05, schrieb Garry: Eine 6spurige Autobahn nebst Böschung, Entwässerungsgräben, Sicherheitszonen etc. kann man nicht mehr einfach ignorieren und den umgebenden landuse zuordnen. Bisher war die sinnvollste Regelung, dass man keinen landuse nutzt und die Fläche ungetagt lässt. Bei highway=residential in/auf landuse=residential würde ich komplett von landuse=highway absehen. Bei highway=track auf landuse=farm ebenso. Allerdings würde ich für landuse=road plädieren und die eigentliche befestigte Fahrbahnfläche inklusive der Sperrflächen einem landcover=highway zuordnen. -1 landcover=highway geht mir deutlich zu weit. Wenn jemand landcover für z.B. sein 3D-rendering haben möchte, soll er es taggen, dabei aber niemanden stören. Aber so etwas offiziell zu empfehlen, führt dazu, dass wir nicht einmal die Straßen in unserer Nachbarschaft (ganz zu schweigen von den Hausnummern) erfassen und mit landcover beschäftigt sein werden. So wie bei landuse=village_green. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sketch-line
Am 29.11.2013 07:41, schrieb Roland Olbricht: Ich habe daher Sketch-Line nicht mehr weiterentwickelt. So wie ich das bisher beurteilen kann ist Sketch-Line eine sehr gute Anwendung. Das einzige Problem ist bisher wahrscheinlich, dass es sehr aufwendig ist eine Buslinie so genau zu mappen. Und deshalb gibt es wahrscheinlich auch nur wenige ÖPNV-Relationen, die fehlerfrei dargestellt werden. Sketch-Line arbeitet zuverlässig mit highway=bus_stop und public_transport=platform zusammen. stop_position wird ab irgendwann wieder komplett ignoriert werden. Es ist ohenhin nicht flächendeckend verfügbar. Ich habe mir das mal bei meinem Prototypen angeschaut: Hier eine Haltestelle ohne highway=* (Das Tagging ist so für beide Richtungen): http://www.openstreetmap.org/browse/node/294076198 Diese wird in Sketch-Line als einzelner Halt Dargestellt. http://www.overpass-api.de/api/sketch-line?ref=22network=VBNstyle=wuppertal Das funktioniert also. Nun habe ich mir das ganze angeschaut, wenn ich auf dem platform-Weg den highway=platform-Tag habe (Im Beispiel sind wieder beide Richtungen gleich getagt). http://www.openstreetmap.org/browse/way/249003334 Das funktioniert also auch. Trotz eines highway=*-Tags wird in Sketch-Line die Haltestelle nur einmal dargestellt. Nun das was nicht funktioniert: Eine Haltestelle, die public_transport=platform und highway=bus_stop trägt (auch wieder in beiden Richtungen dasselbe). http://www.openstreetmap.org/browse/node/299731075 Diese funktioniert nicht. http://www.overpass-api.de/api/sketch-line?ref=22network=VBNstyle=wuppertal Was ich aber auch weiß: highway=bus_stop alleine mit Rolle platform funktioniert. Fazit: highway=bus_stop und public_transport=platform zusammen wird in Sketch-Line nicht unterstützt. Ich würde empfehlen, - Nodes als Haltestellen mit highway=bus_stop und public_transport=platform und Namen zu taggen Hm ich sehe gerade, dass man highway=platform auch auf nodes taggen kann. http://wiki.openstreetmap.org/wiki/Tag:highway%3Dplatform Ich meine ich hätte im Wiki irgendwo mal das Gegenteil gelesen. Das würde ich zwar nicht als bessere alternative vorschlagen, aber highway=bus_stop und public_transport=platform klingt schon ein bisschen redundant - auch wenn ich das bisher so getagt habe. - Ways als Haltestellen mit public_transport=platform und Namen zu taggen - diese Elemente und nur diese Element mit der Rolle stop in Reihenfolge der Bedienung in die Linie einzufügen - mit den Rollen forward und backward die Wege des befahrenen Linienwegs aufzubauen Das habe ich mal gemacht für ein paar Linien. Es gibt da glaube ich auch Anwendungen für, die dann Pfeile rendern. (Bin mir nicht sicher, ob das folgende Beispiel auf den Rollen forward und backward beruht) http://www.öpnvkarte.de/?zoom=17lat=53.09484lon=8.7972layers=TBTTT Sketch-Line sollte dann korrekt funktionieren, verbleibende Fehler korrigiere ich gerne. Erfahrungsgemäß gibt es auch selten bis nie Widerspruch, wenn man so mappt. Ich bin mir nicht sicher, ob ich etwas ändern würde, von dem, das nun doch nicht so funktioniert. Ich finde vielmehr, dass Mapnik langsam mal Knoten mit public_transport=platform und bus=yes als Bushaltestellen rendern sollte. Bei Wegen kann ich ja noch verstehen, wenn dort ein highway=platform getagt werden soll, schließlich hat so ein Wartebereich Ähnlichkeiten mit einem Fußweg. Das muss aber hinter der dringenderen Weiterentwicklung der Overpass API leider zurückstehen, weil Wiki-Diskussion unvermeidlich sehr zeitraubend sind. +1 Ich kann das nur unterstützen. Diese ÖPNV-Geschichte scheint ja doch irgendwie eher ein Proposal- und Tagging-Problem zu sein. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sketch-line
Nachtrag: Mir fällt da auch gerade ein, dass das ersetzen von highway=platform durch public_transport=platform auch den Vorteil hätte, dass dann die Wartebereich nicht mehr als Weg, den der Bus/die Straßenbahn etc fährt gerendert wird, sondern solche Objekte einzeln ansprechbar wären. Diesen Fehler haben die ÖPNV-Karte, openptmap und die Verkehrskarte auf osm.org. Positivbeispiele habe ich keine. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] landuse=grass
http://geoobserver.wordpress.com/2013/11/28/osm-golfplatz-in-30-minuten/ Mir ist mal aufgefallen, dass in dem Video landuse=grass genutzt wird. Sollte der Tag nicht mal durch so etwas wie landcover=grass ersetzt werden? Darum geht es hier ja eigentlich. landuse=recreation_ground, wenn auch für andere Polygone, wäre doch hier passender. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Sketch-line
Hallo, ich versuche gerade eine Buslinie in Bremen so nach dem neuen ÖPNV Schema zu taggen, dass auch Sketch-Line damit funktioniert. Allerdings funktioniert das nicht alles so wie es soll. Seht es euch selbst an: http://www.overpass-api.de/api/sketch-line?ref=22network=VBN http://www.overpass-api.de/api/sketch-line?ref=22network=VBNstyle=wuppertal Das Problem ist, dass fast alle Haltestellen doppelt dargestellt werden. Solche wo auch eine Straßenbahn am gleichen Steig hält, werden korrekt dargestellt (Kurfürstenallee, Crüsemannallee, Busestraße, Universität / Zentralbereich). Nun habe ich einmal in beiden Richtungen von einer reinen Bushaltestelle (Bruchhauser Straße) den highway=bus_stop Tag entfernt. Das Ergebnis ist, dass eine Lücke entsteht, aber die Haltestelle nun nicht mehr doppelt dargestellt wird. Hier einmal der Direktlink zur route_master-Relation: http://www.openstreetmap.org/browse/relation/571202 Ich frage mich nun, ob die Darstellung so beabsichtigt ist bzw. welche eigentlich die Zieldarstellung sein soll. Schon einmal Danke, dass ihr überhaupt so weit gelesen habt. Ich würde mich sehr über Antworten und Einschätzungen freuen. LG cracklinrain PS: Kann es sein, dass highway=bus_stop im neuen Schema nicht unterstützt wird oder kann Sketch-Line bloß nicht mit doppelt getagten Objekten umgehen? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sketch-line
Am 29.11.2013 00:15, schrieb Jo: Meine funktioniert schon: http://overpass-api.de/api/sketch-line?network=De+Lijn+West-Vlaanderenref=20operator= Ich finde es aber blöt um alle stop_position hin zu fügen. Wenn ich mir dein Beispiel ansehe, ist das (zumindest für Sketch-line) auch nicht nötig - funktioniert auf den ersten Blick ja. Für das Norten von Belgien gibt es 1000e Routes (+Variationen). Es wird schon mühsam sein um die alle zu 'maintainen'. Umtaggen von highway=bus_stop auf das neue Schema braucht man aber dann zumindest für so eine Anwendung wie Sketch-line nicht - zumindest gehe ich nicht davon aus und es war ja auch so gedacht, dass das alte Schema weiterhin unterstützt wird (so stand das irgendwo im Wiki). Was wichtig ist für mich sind die highway=bus_stop/public_transport=platform. Das hat mir erst einmal sehr weiter geholfen! Bei Sketch-line wird also highway=bus_stop im neuen Schema durch public_transport=platform ersetzt. Aus meiner Sicht ist das so sinnvoll, weil ich die highway=platform/bus_stop Tags nur zum Mappen für denen Renderer benutzen würde. Und das ist ja eher nicht so toll. Die stop_position kann man ziemlich einfach kalkulieren oder mittels Relationen mit Typ public_transport=stop_area ableiten. Ja ausrechnen könnte man mal probieren, aber ich vermute, dass die Ergebnisse für einen Bot nicht ausreichen. Man müsste wahrscheinlich alle noch einmal überprüfen. Aber so wichtig sind die Haltepositionen zur Zeit auch nicht (ich würde mich freuen eines besseren belehrt zu werden :)). - Was mich jetzt noch interessieren würde: Wenn ich eine Haltestelle/Haltestellenbereich nach dem neuen Schema gemapt habe, darf/muss ich dann noch all die alten Tags wie railway=platform/tram_stop/halt highway=bus_stop/platform hinzufügen? Und wann wird das neue Schema von Mapnik (und diversen anderen Anwendungen) unterstützt? Welche Anwendungen außer Sketch-line unterstützen überhaupt das neue Schema? ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetMap und Bürgerbus
Am 27.11.2013 09:22, schrieb Volker Schmidt: Ich weiss nicht, wie weit das uebertragbar ist, aber fuer Rad-Routen, die geplant aber noch nicht ausgeschildert sind, habe ich in der relation state=proposed verwendet. Der wichtigste renderer fuer Radkarten, Opencyclemap, stellt diese Routen gestrichelt dar. Im preset von JOSM für Relationen (allgemein), wird auch für Buslinien dieser Tag verwendet, sehe ich gerade. Beispiel: relation 1742549 Weiss nicht, ob das einfach uebertragbar ist. Hat jemand mal im Zusammenhang mit ÖPNV-Relationen damit (state=proposed) erfahrungen gemacht? Für die Haltestellen könnte man ja vielleicht (sofern diese noch nicht vor Ort vorhanden sind) proposed=platform und proposed=stop_position benutzen. Wird das Rendering von stop_position und platform von Mapnik eigentlich schon unterstützt? Vor einem halben Jahr etwa, funktionierte das noch nicht. Wenn es nicht unterstützt wird, würde ich erst einmal vorschlagen, dass man schließlich an alle public_transport=stop_position zusätzlich den alten Tag highway=bus_stop tagt. Wenn man das am Ende einmal macht, wäre das keine zusätzliche Arbeit. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenStreetMap und Bürgerbus
Hallo Andreas, ich weiß nicht, ob zu dem Problem bisher irgendwo ein Vorgehen vorgeschlagen ist. Ich probiere einfach Mal zu beschreiben wie ich das Problem angehen würde. Am 26.11.2013 21:44, schrieb Andreas Schmidt: Hallo! In unserer Gemeinde (Eschede) gibt es einen neu gegründeten Bürgerbus-Verein. Da ich schon einige Zeit bei OSM mitwirke, hatte ich die Idee, die vier geplanten Linien in OSM einzutragen. Derzeit ist es noch Planung, soll aber nächste Woche beantragt werden. Nun möchte ich schon mal die festgelegten Haltestellen als Punkte eintragen und die Verläufe der Linien darstellen. Kann ich das direkt schon in der OSM-Datenbank eintragen (mit tags wie proposed_route o.ä.) oder muss ich sowas auf einem getrennten System laufen lassen? Bei bereits bestehenden Buslinien ist das so, dass man wie du es beschreibst die Haltestellen und die Route in die OSM einträgt. Hier einmal ein Beispiel einer Nachtlinie (N5) aus Bremen: http://www.openstreetmap.org/browse/relation/2762573 Nach dem neuen Proposal würdest du dann für jede Fahrtrichtung eine Relation anlegen. Also http://www.openstreetmap.org/browse/relation/2762542 Wenn es Alternativrouten (manche Haltestellen werden nicht angefahren oder der Bus fährt eine andere Strecke zu manchen Zeiten) gibt, kannst du die durch weitere Relationen erfassen. Was auf jeden Fall in der Relation enthalten sein sollte, sind die Weg segmente, die der Bus abfährt und die Halte stellen, an denen der Bus hält. Letzteres habe ich nich nie gemacht. Ich hätte zwar eine Domain mit ein paar wenigen features[1], die ich zur Verfügung stellen würde. Die Linie soll aber spätestens, wenn sie in Betrieb geht, öffentlich in OSM verfügbar werden, so dass ich am liebsten alles nur einmal abarbeiten möchte. Ich würde es für absolut in Ordnung halten, wenn du die Haltestellen soweit taggst, dass bis auf die entscheidenden Tags highway=bus_stop oder ggf. public_transport=platform und public_transport=stop_position alle weiteren Tags wie name=*, bus=*, shelter=*, bin=* etc in der OSM gemappt sind. Genauso die Relation. Wenn du dort die entscheidenden Tags wie route=bus erst einmal weglässt (type=route würde sicherlich nicht stören - aber da bin ich mir unsicher) wird die Route von von keinem Renderer erkannt. Du solltest also zusätzlich vielleicht einen proposed=*-Tag benutzen, damit andere Mapper das so verstehen. Diese proposed Tags könntest du dann später auch dazu nutzen, mit z.B. der Suche in JOSM nach z.B. den Haltestellen (highway=bus_stop bzw. public_transport=stop_position und public_transport=platform) anhand deiner proposed Tags zu suchen und alle auszuwählen, um sie schließlich auf einen Schlag funktionstüchtig zu taggen. Das wäre eine Variante, gegen die eigentlich niemand etwas haben kann. Wenn du alles sofort mapst könnte natürlich irgendwer etwas dagegen haben, allerdings solltest du auf jeden Fall berücksichtigen, dass es eine Weile dauert, bis die Daten gerendert werden (etwa 24 Std. auf der osm.org-Seite). Wo fange ich an mit mich-schlau-lesen? Die Wiki-Seiten zu public_transport (vor allem die englischen) beinhalten eigentlich alles nötige und sehr viele weitere Möglichkeiten zum Taggen von Details. Wenn du fragen dazu hast, beantworte ich sie dir gerne. Beim Eingeben der Daten kann man auf jeden Fall einige Tricks nutzen, um sich Arbeit zu ersparen. LG cracklinrain ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ich habe mal experimentell eine street-Relation erstellt: http://www.openstreetmap.org/browse/relation/2703394 Aber es gibt natürlich keine Unterstützung für solche Relationen. Und ich habe immer mal wieder daran gedacht, das Tagging durch ein besseres anderes zu ersetzen. Ich bin mir darüber bewusst, dass dieses Schema umstritten ist. Aber es gab einfach ein paar Vorteile für dieses Schema: * Man kann oneway leichter definieren * Im Zusammenhang mit Fußgängerüberwegen ist mehr Konsistenz möglich * Man kann genauer erkennen wo man her fahren kann * Oft muss man einen Radweg früher verlassen und auf die Straße fahren, damit man in eine andere Straße abbiegen kann. So etwas kann durch Taggen an Straßen nicht gelöst werden. Am 31.10.2013 19:20, schrieb Dirk Sohler: Stephan Wolff schrieb: Auch für gutes Fahrradrouting muss man straßenbegleitende von eigenständigen Radwegen unterscheiden können. Und benutzungspflichtige, von nicht benutzungspflichten Radwegen. Gibt es da eine Möglichkeit? In der Regel ist es ja nicht verboten auf der begleiteten Straße zu fahren. Wenn es dann einen begleitenden Weg mit bicycle=designated gibt, sollte der bevorzugt werden. Wenn es um Details geht finde ich das gesamte Tagging für Radwege noch nicht zufriedenstellend. Wenn man die Tags an den Straßen mehr unterstützen wollte, sollte man sich vielleicht auch mal um ein Rendering der vielen speziellen Tags in JOSM bemühen und die Eingabe erleichtern. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJScqt1AAoJEHSvWLoMVLeJETkQAICoSlrKNibYRzkk1PvQYfEL yOwY9qZGVIfr3FVnDVJ5HpMlIRshhtzmakXeXCf1HJCYAgILVWPR37/Ao1ekjEgt cUbuFEtZy/czWmchBiInbuDVbBbOWgkD2lG9FV2tS+E47AeCsbGPkHWntahDFW+g Hu6UDFXqhXlECEb9mIwKdqe5PW86Bu4d8vDHf6G1p6JldVPSo7aD6IR1gx5v5mpy x10O7/F+S7Gjo0IggVZmoUr3E3RhfENRT1qWyEQgmaoulXxRSSeZZrNy1IFmc163 c9yIc9DJaJFT8+jt7iLeJve7cOIEURDhefSXbTxAbJaMzYgg0xMulGanT4hlWamO RGZfoB8ef7PhNG+514bmCX8qFIriwQzHMT1ea6aVAN9U/fpmgI4mQlAa9XyMfikr SEvL8rsf3/orPB5jG/r2TtO9qJmo3ewgD7GBi0zd6wrXrFh9jCNSl/2/eI+Cbjc5 i+XeuXADqpx3hwNU3hodVy6EMGKOz5MtSVxOC7cJevtI95ACEretBJqmYljDOF+Q pgI1GVwSLAcO7p7DPjmgRreXZQVuDIPOoyy+35jvG4wlhU6mOFkY/JhQQMuuJ4xZ nD57vmX/CEA8h9NCWNeaH7jufQ6izyTqc2fFa3K4c2iCCqzrfOi9IHaGVHlkfV1u HaoHcMa5lTnFkXewdyhF =Jir3 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amtliche Daten
Am 29.10.2013 17:11, schrieb Michael Reichert: Hallo, Am 29.10.2013 16:30, schrieb Johann H. Addicks: BTW: Nicht unerwähnt lassen möchte ich die (Rechts-)Auffassung, die z.B. von Daniel A. Rehbein vertreten wird, die (so ich es richtig verstanden habe) etwa wie folgt lautet: Bei Straßennamen und Hausnummern handelt es sich um Anschriften im Briefdienst der Deutsche Post AG, nicht jedoch um gesetzliche/hoheitliche Ortsangaben. Letzteres Kriterium erfüllen nur die bei den Kasterämtern geführten Verzeichnisse. Dort sind es jedoch Gemarkungen und Flurstücke. Also kann man in den überwiegenden Fällen die Anschriften der Post in Gemarkungen der Flurstücke überführen - und umgekehrt. Verstehe ich das richtig? Sprich: Auch wenn man diese Ansicht vielleicht nicht teilt, so fehlt uns afaik ein Tagging für Flurstücke Ich will jetzt keine Diskussion über dir Relevanz von Flurstücken anstoßen, aber vom Flurstücksmapping halte ich gar nichts. Das ist Katastersache. Hätten Flurstücke denn eine Relevanz in OSM? Mir fällt gerade nichts wichtiges ein. Ad hoc erscheint mir die Erfassung durch Mapper unmöglich. Solche Daten würden einmal importiert und müssten dann von den Behörden regelmäßig mit Updates versorgt werden, weil Änderungen kaum bemerkt werden können. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amtliche Daten
Am 26.10.2013 09:59, schrieb Norbert Kück: 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. Sicher ist keine von beiden Quellen. Anderes habe auch ich nie behauptet. 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. OSM ist wesentlich transparenter, da wir Kontakt zu jedem einzelnen Mapper aufnehmen können und die Herkunft der Schreibweise dokumentieren können. Wir können sogar dokumentieren, wenn die Schreibweise vor Ort vom Amt eigentlich anders gewünscht wäre. Wir haben also deutlich bessere Mittel, auf unterschiedliche Schreibweisen einzugehen, als direkt die aus der amtlichen Liste direkt - ohne vor Ort zu überprüfen - zu übernehmen. Auch wenn einzelne Fehler nicht jeden anderen Eintrag in der Liste falsch machen, macht es doch die Liste insgesamt falsch. Ein Mapper kann sich daher nicht auf die Liste verlassen. Aber grundsätzlich war das auch schon bevor die Fehler als solche benannt wurden klar. Du solltest in deiner Meinung einem Mapper wenigstens einräumen die Schreibweise nicht zwingend aus der Liste zu übernehmen. Diese Freiheit würde aber ausschließen, dass die amtliche Liste der Schreibweise vor Ort vorgezogen wird oder in jedem Fall vorgezogen wird (was bisher deine Meinung dazu darstellt, wenn ich dich zuvor nicht falsch verstanden habe). 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. 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. Es ist schon interessant, dass bei dir die Schreibweise vor Ort nicht zu Wissen zählt. Wissen hat auch etwas mit Arbeitsweise zu tun. Wenn unreflektiert Daten aus einer amtlichen Liste übernommen werden müssen und keine weiteren Quellen zulässig sind, hat das für mich nichts mehr mit einer wissenschaftlichen Arbeitsweise zu tun, die für Wissen erforderlich ist. Wenn du die Schreibweise vor Ort als Vermutung einstufst, dann finde ich deine Meinung falsch. Ich finde es super, dass wir die amtliche Liste haben - und wir brauchen sie auch. Und deshalb finde ich auch super, dass du dich dafür so einsetzt. Grundsätzlich möchte ich zu bedenken geben, dass wir solche Fehler niemals herausfinden werden, wenn wir irgendwelche Daten (Schreibweisen) aus der amtlichen Liste kopieren und in die OSM eintragen. Ich finde, dass wir daher weiterhin verfolgen sollten, die Daten vor Ort zu erfassen. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amtliche Daten
Am 26.10.2013 13:38, schrieb Norbert Kück: 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.) Deshalb finde ich das amtliche Straßenverzeichnis ja auch gut. Da du im Wiki bereits geschrieben hattest, dass du die Schreibweisen vor Ort überprüft hast, hatte ich von dir bearbeitete Straßen, wo es Differenzen gab direkt entsprechend eingeordnet. Dass Mapper trotz Aufnahme der Daten vor Ort Fehler machen, habe ich auch schon oft festgestellt. Das passiert eben und es arbeitet auch nicht jeder Mapper zu jeder Zeit gleichermaßen zuverlässig. Aber das wird ja gerade auch durch den Straßenlistenvergleich ein wenig aufgefangen. 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. Ich finde das gut. Sicherlich freuen sich auch die Behörden über diese Unterstützung. Wenn du solch ein Vertrauen genießt, dass man auf deine Hinweise eingeht, ist das aber sicher nicht für jeden Mapper der OSM möglich. Außerdem ist es problematischer für Mapper, die anonym bleiben wollen, aber dennoch auf OSM verweisen. Ich habe bisher keine guten Erfahrungen damit gemacht, mich anonym an offizielle Stellen zu wenden. Auch wenn ich meinen Namen mitgeteilt habe, habe ich keine Antwort erhalten. Aus diesen und auch aus anderen Gründen, mache ich mir nicht die Mühe die Fehler persönlich und Straße für Straße an Behörden weiter zu geben. Und ich finde, dass man solch eine Kooperation von Mappern mit offiziellen Stellen nicht als üblich erwarten sollte. Die können in unsere Liste schauen und wir in deren. Mir genügt das schon, um es als eine Art von Kooperation zu verstehen. Schließlich ist es die Aufgabe der Ämter in betreffenden Gebieten für Beschilderung zu sorgen. 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. Das ist deine Meinung. Ich kenne sehr viele Menschen unter 30, die eine konventionelle Karte benutzen. Wer Deinen Beitrag liest, könnte glauben, ich würde das Gehirn abschalten wenn ich irgendeinen Text aus amtlicher Quelle lese. Na danke! Nein. Die Darstellung deiner Haltung war bisher einfach so, dass die Einträge im amtlichen Straßenverzeichnis immer noch amtlicher seien als die amtliche Beschilderung vor Ort. Wenn ich dich nun nicht falsch verstehe, ist deine Prioritätenfolge so: 1) amtliches Straßenverzeichnis ... *) Beschilderung vor Ort Meine ist so: 1) amtliche Beschilderung vor Ort (sofern vorhanden und widerspruchsfrei) 2) sehr vertrauenswürdige Mapper mit sehr sorgfältigen Beiträgen ... m-1)... m) viele Anwohner (einer Straße) m+1)... ... *) einzelner Anwohner *) von mir erfasste Daten an die ich mich nicht mehr vollständig erinnere, ich aber auch nicht mehr belegen kann *) amtliches Straßenverzeichnis *) andere Karten n) Daten in OSM (ohne 2) Wobei der Vergleich mit den OSM-Daten natürlich möglich ist, aber generell immer angezweifelt werden sollte. Außerdem können wir in Bremen nicht (unbedingt) aus anderen Karten Daten übernehmen - zudem ergibt dies auch keinen Sinn. Ich finde es aber grundsätzlich falsch, die OSM zu einem Sammelbecken von amtlichen Daten zu machen. Wenn die OSM Fehler hat, dann kann da jeder mit Leben, weil er sie korrigieren kann. Auch wenn man dafür vielleicht gelegentlich einen anderen Mapper überzeugen muss. Aber wo es geht sollten die Daten auch überprüfbar sein. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Amtliche Daten
Vielen Dank soweit für eure Antworten! Bisher sehen die meisten Mapper das also so, dass der Name vor Ort im name-Tag eingetragen werden sollte. Ich stimme dieser Haltung/Lösung grundsätzlich zu. Nachdem ich mir nun weiter darüber Gedanken gemacht habe, würde ich auch sagen, dass die Schilder aufstellende Autorität schließlich auch seine Rolle erfüllen muss, amtlich korrekte Schilder aufzustellen. Ist ja eigentlich ein Witz, wenn sich da irgendwer rausreden kann. Weiteres: * Der Punkt zur falschen Schreibweise ist natürlich noch einmal sehr pikant. Ich finde das (falsche Schreibweisen zu korrigieren) selber auch nicht falsch so. Grundsätzlich halte ich diese Gedanken (was man machen soll, wenn vor Ort und in der amtlichen Liste der Name nicht richtig ist) für wichtig. Ich selber würde diese couragierte bzw. kritische Haltung ungerne auch noch annehmen, da das unglaublich viele Diskussionen hervorrufen würde (siehe H.-H.-Meier-Allee in Bremen: Wenn man Abkürzungen in OSM für falsch hält, hat man da einen schweren Stand, siehe history zum ältesten Abschnitt). * Angenommen vor Ort fehlt das Schild, weil es geklaut oder umgefahren wurde. Vielleicht sogar durch ein privates Schild ersetzt wurde. Dann müssten wir in OSM auch klären, ob der Name vor Ort oder der alte Name nun genommen wird. (Entschuldigt die theoretische Natur meines Falles.) * @Martin: Am 25.10.2013 08:55, schrieb Martin Trautmann: Ich persönlich ziehe es vor, die korrekte Schreibweise zu verwenden - vor dem Hintergrund, dass jemand, der etwas SUCHT, nicht die falsche Schreibweise verwendet, sondern die wohl richtige. Über diese Variante hatte ich mir aufgrund der Diskussion in Bremen noch gar keine Gedanken gemacht. Das müsste aber nach meinem aktuellen Informationsstand von einigen Bremer Mappern vehement abgelehnt werden. Zusätzlich gebe ich die falsche als alternative Schreibweise ein, egal ob die aus einer amtlichen Liste stammt oder vor Ort so auf dem Straßenschild steht. Beispiele: * Es gibt diverse Fälle, wo an einem Ende der Straße ein anderes Schild steht als am anderen. Das stimmt. Allerdings wäre ich mir dann selber nicht sicher und würde hoffen, dass es nicht mehr als 3 Varianten gibt. Um überhaupt erst einmal alle Varianten in der OSM zu haben. * Manche Gemeinden vergeben falsche Namen, aus Unkenntnis der richtigen Schreibweise. Das wird irgendwann dann mal korrigiert, oder auch nicht. Typische Beispiele: Gerhard-Hauptmann-Straße vs. Gerhart-Hauptmann-Straße, Bismarkstraße vs. Bismarckstraße, Elsa Brandström vs. Elsa Brändström, Straßen mit Sonderzeichen (Bartók vs. Bartok), Getrenntschreibung. * aktuell sehr beliebt ist vorauseilender Gehorsam mit automatischer Korrektur der Rechtschreibung, wo z.B. aus dem jahrhundertealten Schloßweg durch die Rechtschreibprüfung der Schlossweg wurde - und ich die alte Schreibweise beibehalte. Das könnte man dann aber auch gut durch old_name lösen. Das wäre für mich jeden Falls nicht leicht zu begründen, weshalb OSM nun nicht die vor Ort und auch nicht die im amtlichen Verzeichnis nimmt. Als ich das letzte Mal nachsah, da hat die Straßenlistenauswertung ss vs. ß bemängelt. Persönlich unterscheide ich das vorerst nicht als Fehler. Ist das ß dann auch vor Ort ersetzt? * Konkret gibt es hier in der Nachbarschaft die Straße Steinmatten im Ortsteil Wildtal, Gemeinde Gundelfingen, Landkreis Breisgau-Hochschwarzwald. Diese Straße führt ein paar Häuser über die Gemeinde- und Landkreisgrenze hinaus. Die Stadt Freiburg führt sie als Steinmattenstraße in deren amtlichem Verzeichnis. Was ist nun also die richtige Schreibweise In Bremen könnte es auch solche Fälle geben. Es werden zumindest Straßen geführt, die selbst nicht in Bremen liegen, aber dessen Bebauung. So etwas wird es wohl in nahezu jedem Ort geben. Am 25.10.2013 11:15, schrieb Martin Trautmann: Gewissensfragen, wo ich mich in Bremen anders entschieden habe: * Getrenntschreibung / Bindestriche Airbus-Allee Airbusallee Am Kaffee-QuartierAm Kaffeequartier Am Weser-Terminal Am Weserterminal Bordeaux-Str. Bordeauxstr. Bodenwerderstr. Bodenwerder Str. Braut-Eichen Brauteichen Dudweilerstr. Dudweiler Str. Nantes-Str. Nantesstr. Sankt-Gallener-Str. Sankt Gallener Str. Störtebeker-Weg Störtebekerweg * Zeichensalat An´n Graaben An'n Graaben In n Dörp In'n Dörp To n Böversten Diekkampe To'n Böversten Diekkampe Ich bin mir nicht sicher was du meinst. Meinst du, dass du diese Schreibweise entsprechend deinem Vorschlag in OSM ändern würdest? Am 25.10.2013 14:55, schrieb Martin Trautmann: Deshalb, unabhängig von meinen persönlichen Vorlieben, gehört da eher die Airbus-Allee hin - denn das ist wenn auch nicht schön, so doch auch nicht grundfalsch. Deine Haltung finde ich auf jeden Fall toll: Wir sollten auch gelegentlich mal abwägen zwischen der Arbeitsweise wie wir bei OSM bisher gearbeitet haben und dessen Alternativen.
Re: [Talk-de] Amtliche Daten
Am 25.10.2013 22:21, schrieb Martin Trautmann: On 13-10-25 15:17, cracklinrain wrote: * Zeichensalat An´n GraabenAn'n Graaben In n Dörp In'n Dörp To n Böversten DiekkampeTo'n Böversten Diekkampe Ich bin mir nicht sicher was du meinst. Meinst du, dass du diese Schreibweise entsprechend deinem Vorschlag in OSM ändern würdest? In den drei Fällen betrachte ich die rechte als die richtige. Was vor Ort steht weiss ich nicht - ich hoffe, die rechte, richtige. Die amtlichen Listen sind hier einfach falsch. Ja das ist auch vor Ort anders. Liegt aber natürlich auch nahe, dass das vorliegende Dokument der amtlichen Liste hier nicht korrekt ist. Schließlich geht es hier um Sonderzeichen und EDV. Wegen solcher Straßen wie Nantes-Str. und Bordeaux-Str. könnte man die Stadt fragen, was sie sich dabei gedacht hat. Nur weil ein Wort französisch ausgesprochen werden soll rechtfertigt das noch keine Getrenntschreibung. Und die Fälle von Störtebeker-Weg, Sankt-Gallener-Straße usw. legen nahe, dass die Leute dort mal einen Duden bräuchten. Ah verstehe. Hätte ich natürlich drauf kommen können. Intuitiv stimme ich deiner Kritik zu, daher werde ich Vorschläge als alt_name in die OSM eintragen. Ich habe nun einen Abschnitt in der Doku über die Vergleichsliste angefügt, in dem diese Fälle dokumentiert werden können. So etwas wird uns in jedem Fall im Falle einer Änderung die Wartung erleichtern, denke ich. In allen diesen Fällen muss man wohl die Schreibweise so akzeptieren. Aber die richtige würde ich als alt_name ergänzt haben wollen. Da stimme ich auch zu. Siehe auch oben. Sobald die Gemeinde den Fehler einsieht und korrigiert - was bei unbewohnten Straßen leichter fällt - muss man dann für OSM nachziehen. Die falsche wandert dann wohl nach old_name. Das wäre natürlich insgesamt wünschenswert, den Ämtern diese Transparenz zu bieten - schließlich bieten sie uns in dem Rahmen den die Politik ihnen einräumt sicherlich schon viel! ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Amtliche Daten
Wie gebt ihr Namen oder Hausnummern in die OSM ein, wenn sie nicht mit der Schreibweise der entsprechenden amtlichen Liste übereinstimmen? Hintergrund ist: Ich habe in den letzten Tagen die Straßenvergleichsliste in Bremen (http://regio-osm.de/listofstreets/wiki/index.php?title=Bremen) ein wenig gepflegt und dabei die Einzelnen Fälle von Differenzen unterschieden. Nun gibt es solche harten Abweichungen wie In'n Dörp (vor Ort) und In n Dörp (amtliche Liste), Friedrich-Meier-Weg (vor Ort) und Fritz-Meier-Weg (amtliche Liste) oder Wurtmannplatz (vor Ort) und Johann-Wurtmann-Platz (amtliche Liste). Teilweise waren auch groß- und Kleinschreibung anders. Die betreffende Liste von der Stadt ist eine xls-datei und unter der Creative Commons Namensnennung 3.0 veröffentlicht. (siehe http://www.daten.bremen.de/de/datensatz/bremen236.c.8060.de) Ich selbst mappe eigentlich - sofern es kein offensichtlicher Fehler ist - namen wie sie vor Ort auf Schildern stehen. LG cracklinrain ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
