Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
TMC scheint mind. innerhalb OSM tot zu sein. Vgl. [1]. Und so oder so, scheint mir TMC doch reichlich kompliziert, unzugänglich und daher ungeeignet für diese Zwecke hier. Oder kannst du mir ein Beispiel geben, wie man die Neustadtstrasse, Landshut, mittels TMC für nächstes Wochenende sperren würde? LG, Stefan Hallo Stefan, TMC ist innerhalb OSM tot, weil es für den Normalmapper zu kompliziert und schwer nachvollziehbar ist. Solche komplexen Sachen, die nur von wenigen Experten so richtig verstanden werden, gehören von außerhalb integriert, ohne allzugroße Eingriffe in den OSM-Datenbestand. Blicken wir lieber in Richtung TPEG [1], dem TMC-Nachfolger für das Digitalradio. Dises System ist unabhängig vom Kartenmaterial und auch vom Übertragungskanal. Die ARD-Rundfunkanstalten stehen kurz vor dem Beta-Test und stellen dann auch die Meldungen z.B. als RSS-Feed zur Verfügung. Mit TPEG-Technologie dürfte es kein Problem sein, einzelne Straßen oder Parkplätze kurzfristig zu sperren, besetzte Parkhäuser oder auch die Preise an Tankstellen anzuzeigen. Grüße Joachim [1] http://de.wikipedia.org/wiki/TPEG ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
On 23/lug/2013, at 09:30, Joachim Kast osm...@dd1gj.de wrote: TMC ist innerhalb OSM tot, weil es für den Normalmapper zu kompliziert und schwer nachvollziehbar ist. Wenn ich das richtig in Erinnerung habe war das erste Schema komplett umständlich und unnötig kompliziert sowie kaum menschenlesbar*. Diese erste Schema ist das, was anfangs umgesetzt wurde, aber aufgrund der Unverständlichkeit nicht großartig gepflegt oder gewartet wurde, während der zweite Vorschlag ganz OK und relativ simpel war, aber der vorschlagenden Firma (?) irgendwie die Luft ausgegangen ist (?), so dass das bisher nicht umgesetzt wurde. http://wiki.openstreetmap.org/wiki/DE:Proposed_features/New_TMC_scheme#Proposal:_Neues_Tagging-Schema_f.C3.BCr_TMC-Daten * so wurde im ursprünglichen Schema z.B. TMC:cid_58:tabcd_1 jedem einzelnen Objekttag vorangestellt, was einfach bedeutet Deutschland, erste (und einzige) Tabelle. Dadurch wurden die Tags kryptisch und lang ohne das etwas gewonnen worden wäre. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Joachim Vielen Dank für den Hinweis auf TPEG. Das kannte ich noch nicht. Ich befürchte aber, dass TPEG auch nicht viel einfacher ist als TMC. Die v.a. weil es sich - wie TMC - auf effiziente Übermittlung über Übertragungskanäle konzentriert. Hingegen gibt der Abschnitt Aufbau einer RTM Nachricht undder nachfolgende (aus deinem Link [1]) interessante Hinweise, um die Vollständigkeit der hier besprochenen Schemata zu prüfen. In die richtige Richtung geht hingegen: Eckhart's Hinweis Am 22. Juli 2013 08:07 schrieb Eckhart Wörner ewoer...@kde.org: ... • gesperrte Straßen: http://wiki.openstreetmap.org/wiki/Conditional_restrictions Ich kläre nun ab, inwiefern das meinen Vorschlag vom 22.07.2013, 22:36 +0200 ersetzt. LG, Stefan Am 23. Juli 2013 09:30 schrieb Joachim Kast osm...@dd1gj.de: TMC scheint mind. innerhalb OSM tot zu sein. Vgl. [1]. Und so oder so, scheint mir TMC doch reichlich kompliziert, unzugänglich und daher ungeeignet für diese Zwecke hier. Oder kannst du mir ein Beispiel geben, wie man die Neustadtstrasse, Landshut, mittels TMC für nächstes Wochenende sperren würde? LG, Stefan Hallo Stefan, TMC ist innerhalb OSM tot, weil es für den Normalmapper zu kompliziert und schwer nachvollziehbar ist. Solche komplexen Sachen, die nur von wenigen Experten so richtig verstanden werden, gehören von außerhalb integriert, ohne allzugroße Eingriffe in den OSM-Datenbestand. Blicken wir lieber in Richtung TPEG [1], dem TMC-Nachfolger für das Digitalradio. Dises System ist unabhängig vom Kartenmaterial und auch vom Übertragungskanal. Die ARD-Rundfunkanstalten stehen kurz vor dem Beta-Test und stellen dann auch die Meldungen z.B. als RSS-Feed zur Verfügung. Mit TPEG-Technologie dürfte es kein Problem sein, einzelne Straßen oder Parkplätze kurzfristig zu sperren, besetzte Parkhäuser oder auch die Preise an Tankstellen anzuzeigen. Grüße Joachim [1] http://de.wikipedia.org/wiki/TPEG ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am Mon, 22 Jul 2013 16:43:25 +0200 schrieb fly lowfligh...@googlemail.com: Hat sich das denn jetzt aufgeklärt oder geht das weiter ? taoxue hat vorhin mit mir Kontakt aufgenommen und ich habe dazu geraten, die Sache hier in der Liste zu besprechen. Ich denke, dass wir akzeptable Lösungen finden können, aber die Sachen müssen jetzt in der Liste geklärt werden. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten
Hallo Masi Finde deine Überlegungen interessant, v.a. der Teil Am 23. Juli 2013 00:13 schrieb Masi Master masi-mas...@gmx.de: ... Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von Routern nicht mehr berücksichtigt werden und aufgrund des Datums können alle überfälligen Baustellen aus der Datenbank gelöscht werden. Ok. Aber warum zwingend mit Relationen? Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch, versteht sich) Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags. Stimmt. Die langen Tags sind problematisch. Aber immer noch das kleinere Übel als Tags, die voneinander abhängig sind. Könnte man z.B. eine temporäre Sperrrung nicht so erfassen - gemäss Eckharts Hinweis auf das bereits existierende [1]? motor_vehicle:conditional=no @ (2014-07-27..2014-07-28) LG, Stefan [1] http://wiki.openstreetmap.org/wiki/Conditional_restrictions Am 23. Juli 2013 00:13 schrieb Masi Master masi-mas...@gmx.de: Am 22.07.2013, 20:25 Uhr, schrieb Frank fr...@fotodrachen.de: Am 22.07.2013 08:07, schrieb Eckhart Wörner: Hallo Alexander, Am Montag, 22. Juli 2013, 00:45:04 schrieb Alexander Lehner: Aus gegebenem Anlass - 'historisches Stadtfest' alle 4 Jahre mit hunderttausendend von Gaesten, gesperrte Parkplaetze und Strassen, Umleitungen, zusaetzliche amenities etc.. Das Thema wurde schon ein paar Mal angeschnitten. Gibt's da irgendwelche neuen Erkenntnisse? • gesperrte Straßen: http://wiki.openstreetmap.org/wiki/Conditional_restrictions • Umleitungen: ergeben sich normalerweise aus den gesperrten Straßen • zusätzliche amenities: opening_hours? Eckhart Ich denke, es ging Alexander eher um die Frage, ob man die temporären Zustände in die Datenbank eintragen und anschließend wieder heraus nehmen sollte. Es wäre zwar nett, wenn die Karte auch während des Ausnahmezustandes Stadtfest aktuell wäre, aber das erwartet der Besucher wohl nicht wirklich. Er weiß ja, dass die Sperrungen nur aus gegebenem Anlass vorübergehend eingerichtet wurden. Das hin- und herändern (alle 4 Jahre) wäre auf ewig in der Historie. Wer sich gerade während des Stadtfestes eine Garmin-Karte zieht, fährt dann wochenlang mit diesen Sonder-Anpassungen herum. Auch andere Auszüge werden nicht täglich aktualisiert. Ich denke, die OSM-Datenbank sollte nur den Normalzustand wiedergeben und nicht den temporären Ausnahmezustand. Dies kann evtl. auf einer Webseite oder in Flyern durch Overlays dargestellt werden. Das Problem ist doch, dass das zeitliche Sperren nicht funktioniert und zu lange in der Datenbank bestehen bleibt (oft wird die Sperrung vergessen aus OSM herauszunehmen) Angenommen eine Straße hat das Tagging motorcycle=no + mofa=yes. Nun kommt einer und will die Straße mit access=no sperren. Funktioniert natürlich nicht für Mofas und alle anderen (vorher überflüssigen) *=yes Tags werden zum Verhängnis. date_on date_off geht genausowenig, da nicht klar ist, auf welche Tags es sich bezieht. Eine mögliche Lösung ist eine Baustellen- oder Sperrungs-Relation, die alle access tags der Wege nicht beachtet und mit access=no überschreibt. Gleichzeitig kann die Relation weitere access tags aufnehmen, zB Freigabe für Fußgänger und Radfahrer, oder Freigabe für Anwohner. Bei der Relation MUSS aber mit angegeben werden, von wann - und noch wichtiger - BIS wann gesperrt ist. Wenn der Zeitrahmen der Baustellenrelation abgelaufen ist, kann diese von Routern nicht mehr berücksichtigt werden und aufgrund des Datums können alle überfälligen Baustellen aus der Datenbank gelöscht werden. Das Gleiche geht natürlich auch über einen Zusatztags eines Namenraums wie sperrung:von=*, sperrung:bis=*, sperrung:access=* usw. (in Englisch, versteht sich) Vorteil bei Zusatztags ist, dass man Straßenabschnitte unterschiedlich taggen kann. Nachteil sind die Kryptischen und sehr lang werdenden Tags. Falls das Enddatum unbekannt ist, sollte/muss eine Schätzung angegeben werden, damit die Mapper nach der Frist die Baustelle nochmal überprüfen/aktualisieren können. So, das war meine bisherige Überlegung. Aber vielleicht hat jemand noch einen besseren Vorschlag? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserturm verschwunden
dieterdreist wrote Wo? Bisher hieß es immer, das ist zwar eine Abweichung von üblichen GIS Standards, aber in osm dürfen sie das, weil es bequemer für den Mapper ist. Ja, leider :( Es ist ja historisch bedingt und mag für den Mapper bequem sein, aber für jemanden, den mit GIS an die Auswertung drangeht, ist es ein Graus. Bin sowohl Mapper als auch Auswerter und schlage mich permanent damit herum, nicht-GIS-konforme Konstrukte so hinzubiegen (*), dass GIS-Software damit klar kommt. Aus diesem Grunde begrüße ich jede Aktion in Richtung GIS Standard und hoffe sehr auf api 0.7, falls die überhaupt mal kommen sollte. Genaugenommen ist die Datenstruktur von OSM ein propertiäres System - und das in einer Open World. Wir sind zwar Open für jedermann und mächtig stolz drauf, nur kann die Open World nicht viel damit anfangen. Gruss walter *) natürlich nicht in der DB sondernmit - unnötigen und teilweise sehr komplexen - Konvertierungen im Rahmen der Auswertungen. Derzeit suche ich eine Unverträglichkeit bei Multipolygonen, die meinen Postgresql/PostGIS-Server *abrauchen* läßt (Server Restart!), wenn er bestimmte MP fressen soll. :( - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Wasserturm-verschwunden-tp5770618p5771037.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft auf OSM zu setzen. Das betrifft folgende Produkte · Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern beiliegen und die an den Haltestellen aushängen sollen aus den OSM Daten errechnet und im VRR Layout dargestellt werden. · Die Haltestellenumgebungspläne, die von einigen Betrieben erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen aus OSM Daten erzeugt werden. · Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen aus OSM Daten berechnet werden · Die interaktiven Karten der VRR App, dieselben wie die aus efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca. 1.000.000 mal heruntergeladen) · Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten (dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten gezeichnet werden (siehe auchefa.vrr.de und die Apps) · Die Fußwege zu den Haltepunkten und bis zum Gleis der Schienenverkehre sollen auf OSM Daten geroutet werden · Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen · Das Fußwegrouting soll barrierefreie Wege suchen können (wird weiter unter erklärt) Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem auch der Qualität und der Detailreichtum der OSM Daten hat den VRR begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere Datenmaterialien. Das Datenmaterial, das wir in OSM vorfinden hat vor allem bezüglich der Wege (Straßen und Schienenwege) aus ausgezeichnete Qualität. Einige Daten sind allerdings noch unvollständig für unsere Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam mit der OSM Gemeinde. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das? Gehen wir von drei typischen Benutzern aus: Nutzer 1 ist Student, Pendler und in Turnschuhen unterwegs. Er kommt immer knapp vor der Zugabfahrt. Er geht schnellen Schrittes durch den Bahnhof und nimmt die Treppen hinauf zum Bahnsteig, damit er nirgends warten muss. Nutzer 2 ist der Reisende mit Koffer, oder die/der Frau/Mann mit Kinderwagen. Der Nutzer kann nur mit großer Mühe die Treppen nutzen und sucht Wege über Rolltreppen zum Bahnsteig. Nutzer 3 kommt im Rollstuhl. Er ist auf Aufzüge und Rampen angewiesen um zum Bahnsteig zu kommen, er braucht entsprechende Wege. Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen von Plattformen gefunden: · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner Platz/Hohe Straße) · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist, eignet sich bei Seitenbahnsteigen (Beispiel, ….) · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München Ost) Keine der drei Modellierungsarten ist unsere Erfindung, statt der gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten (Multipolygonen), das ist aber noch komplizierter und das haben wir noch nirgends gesehen. Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil,
Re: [Talk-de] Wasserturm verschwunden
Am 23. Juli 2013 11:27 schrieb Walter Nordmann pil...@hotmail.com: Es ist ja historisch bedingt und mag für den Mapper bequem sein, aber für jemanden, den mit GIS an die Auswertung drangeht, ist es ein Graus. Bin sowohl Mapper als auch Auswerter und schlage mich permanent damit herum, nicht-GIS-konforme Konstrukte so hinzubiegen (*), dass GIS-Software damit klar kommt. in diesem Fall muss der Konverter eben einen zusätzlichen inner Way schaffen, der die beiden sich berührenden Ways ersetzt. Das ist schon aufwendiger als wenn man das nicht machen muss, aber zumindest bisher war es so, dass das halt so ist in OSM. Wann das geändert wurde und von wem weiss ich nicht, ggf. ist das ein Fall von Wiki-Fiddling? Genaugenommen ist die Datenstruktur von OSM ein propertiäres System - und das in einer Open World. Wir sind zwar Open für jedermann und mächtig stolz drauf, nur kann die Open World nicht viel damit anfangen. gibt ja Möglichkeiten, zwischen den Systemen zu konvertieren. proprietäres System lasse ich nicht gelten für OSM, egal wie genau man es nimmt ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar
Moin Dietmar, Die grafischen Auswertungen funktionieren scheinbar nicht mehr: http://regio-osm.de/hausnummerauswertung/grafikdarstellung/anzeige.html?ort=K%C3%B6ln Die *.osm Datei kann nicht geladen werden, für München das selbe. Grüße, Malte ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo, Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Tracy (taoxue) Inhaltlich kann und will ich nichts beitragen, aber aus meiner Sicht fällt das Eintragen dieser Daten unter die Import Guidelines [1]. Deshalb, aber auch wenn man das nicht so sieht, wäre es sinnvoll, die Änderungen an der OSM-Datenbank unter einem (oder mehreren) dafür vorgesehenen Account zu machen, dessen Bezeichnung zum Ausdruck bringt, worum es geht, mit einer kurzen Beschreibung des Projekts in der Profilbeschreibung und ggf. einer Wiki-Seite. Das würde Mappern, die auf eure Changes stoßen, ungemein helfen und auch manche etwas ungehalten wirkende Beiträge auf der Liste verhindern. Gruß Rainer [1] http://wiki.openstreetmap.org/wiki/Import/Guidelines ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar
Hallo Malte, jetzt gehen sie wieder. Ich hatte gestern abend und heute vormittag neue Auswertungen durchgeführt und die Dateinamen in falsche Umlautschreibweise abgelegt, derzeit gehen Aktualisierungen noch nicht automatisch. Viele Grüße Dietmar Am 23.07.2013 11:59, schrieb Malte Blättermann: Moin Dietmar, Die grafischen Auswertungen funktionieren scheinbar nicht mehr: http://regio-osm.de/hausnummerauswertung/grafikdarstellung/anzeige.html?ort=K%C3%B6ln Die *.osm Datei kann nicht geladen werden, für München das selbe. Grüße, Malte ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserturm verschwunden
dieterdreist wrote gibt ja Möglichkeiten, zwischen den Systemen zu konvertieren. proprietäres System lasse ich nicht gelten für OSM, egal wie genau man es nimmt ;-) Klar gib es Möglichkeiten - ich mache das ja auch, damit ich nachher z.B. mit QGIS was mit dem Zeug anfangen kann. (*) Das klappt aber eigentlich nur, da OSM-ler Insiderwissen haben und die Datenstrukturen beherrschen. Außenstehende haben da erhebliche Probleme. Und das bezeichne ich nun mal als Propertiäres System. Selbst MS hat inzwischen eingesehen, dass sowas wie das Open-Document-Format Sinn macht um sich der Welt zu öffnen. Gruss walter *) Ich nutze das Snapshot-/Osmosis-Schema der DB und kann/will auf die zum Rendern optimierten Vorarbeiten von osm2pgsql gerne verzichten. ps: Der Vergleich hinkt vielleicht ein wenig: Alle bauen Autos mit 4 Rädern - OSM-Autos haben 5 ;) - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Wasserturm-verschwunden-tp5770618p5771052.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar
Hallo Dietmar, sehe ich mir die Berliner Str. in Westhoven an, sagt die grafische Auswertung, dass 251 Hausnr. fehlen. Soviele Häuser gibt es da gar nicht. Kann es sein, dass die Hausnummer von einer anderen Berliner Str. in Köln kommen? Viele Grüße Johannes Am 23. Juli 2013 12:13 schrieb Dietmar ostr...@diesei.de: Hallo Malte, jetzt gehen sie wieder. Ich hatte gestern abend und heute vormittag neue Auswertungen durchgeführt und die Dateinamen in falsche Umlautschreibweise abgelegt, derzeit gehen Aktualisierungen noch nicht automatisch. Viele Grüße Dietmar Am 23.07.2013 11:59, schrieb Malte Blättermann: Moin Dietmar, Die grafischen Auswertungen funktionieren scheinbar nicht mehr: http://regio-osm.de/**hausnummerauswertung/**grafikdarstellung/anzeige.* *html?ort=K%C3%B6lnhttp://regio-osm.de/hausnummerauswertung/grafikdarstellung/anzeige.html?ort=K%C3%B6ln Die *.osm Datei kann nicht geladen werden, für München das selbe. Grüße, Malte __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo Tracy, Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Das ist super ;) [...] Einige Daten sind allerdings noch unvollständig für unsere Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam mit der OSM Gemeinde. Das klingt gut. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Das klingt gut - aber nach Import, deshalb bitte die Import-Richtlinien berücksichtigen, wenn ihr nicht jede Haltestelle selbst kontrolliert dabei. Eine Alternative ist oft, die Daten öffentlich und für die Nutzung freigegeben zu hinterlegen, damit man verteilt die Haltestellen anhand dessen überprüfen kann. [...] Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Fast richtig. Ein Aufzug muss nicht zwingend ein way sein, um darauf route zu können. Beispiel: .x-' .x und ' seien Nodes, und jeweils dazwiscchen ways. x sei ein Aufzug und als solcher getagged (auf einem Node. trägt außerdem level=0, x trägt level=1 (was jeweils das Stockwerk angibt). Das Routing mit Berücksichtigung des Aufzugs ist hier problemlos möglich. Ebene Wege, Treppen, Rolltreppen und Rampen sind üblicherweise ways in OSM, Aufzüge aber nicht, weil sie kaum eine horizontale Ausdehnung haben. Technisch ist das aber kein Problem auch im Routing zu berücksichtigen. Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen von Plattformen gefunden: · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner Platz/Hohe Straße) stimmt, und sollte für euch kein Problem darstellen. · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist, eignet sich bei Seitenbahnsteigen (Beispiel, ….) auch das sollte kein Problem sein zu nutzen. · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München Ost) Falsch: Wieso sollte das Splitten notwendig sein? Die Plattform ist die von den Gleisen (z.B.) 2 und 3. Die linke Seite bietet den Zustieg zu Gleis 2, die rechte zu Gleis 3. Es bleibt aber erstmal trotzdem ein Bahnsteig. Wieso man diesen horizontal aufsplitten muss, verstehe ich nicht. Wenn ich zu GLEIS (!) 2 route (da fährt der Zug ab), dann route ich (so machen das bei Adressen auch alle gängigen Router) zum nächsten Punkt, der erreichbar ist. Das ist in diesem Fall der Bahnsteig 2/3, und da die linke Seite. Wo ist das Problem? Warum muss dafür der Bahnsteig gesplittet werden? und vor allem: Warum in den Rohdaten? Keine der drei Modellierungsarten ist unsere Erfindung, statt der gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten (Multipolygonen), das ist aber noch komplizierter und das haben wir noch nirgends gesehen. Ich find auch kein Beispiel; logisch wäre es aber meines Erachtens schon, und es würde mit Multipolygonen auf ein etabliertes OSM-Schema zurückgreifen, ohne dass neue Erfindungen mit falschen Daten gemacht werden müssten. Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil, dass man in der Mitte Aussparungen lassen kann. In diesen Aussparungen können dann Treppen, Rolltreppen oder Aufzüge münden, die meist aus dem Fußgängertunnel kommen. Damit wir wissen, welche Teile zu einer Plattform gehören fassen wir diese Teile in einer Relation zusammen. Also trennt ihr erst um dann wieder per Relation zu verbinden... Selbst wenn ihr trennen müsstet (was ich bezweifle), wäre die Relation unnötig, denn die lässt sich einfach aus der Geometrie herleiten (die beiden Bahnsteige sind miteinander verbunden über eine gemeinsame Kante). Meine Empfehlung (darf gerne von anderen noch kommentiert werden) wäre: Eine Plattform ist eine Plattform und kein Gleis. Eine Plattform gehört z.B. zu zwei, manchmal auch zu drei oder mehr Gleisen, und das ist erstmal gar kein Problem. Ein Gleis ist ein Gleis und hat eine Nummer. Wenn ein Zug auf Gleis 2
[Talk-de] Tag designation (war: Einführung eines neuen Tags (globaleID))
Tracy Kasperczyk writes: Objekt: Tunnel (Type: Fläche) - designation = Unterführung Dieser Tag ist ganz sicher falsch. Es gibt wohl vermehrt im deutschsprachigen Raum Fälle wo das mit description verwechselt wurde. Designation bezieht sich vor allem auf UK Wegerecht. Siehe auch das Wiki. http://wiki.openstreetmap.org/wiki/DE:Key:designation Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hallo, da habt ihr euch ja einiges vorgenommen. Leider stoßt ihr bei einigen Sachen in Bereiche vor, wo sich die OSM-Community noch nicht wirklich einig ist. Ich bin mir nicht sicher, wie man da am besten zu einer Klärung kommt. Aber versuchen wir es erst mal mit ein paar konkreten Hinweisen auf dieser Liste: Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Objekt: Rolltreppe (Type: way) [...] Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Escalator Es gibt ein alternatives Proposal, das im Gegensatz zu dem von euch verwendeten approved ist. Es beseitigt auch ein paar Probleme bei der Angabe der Richtung, die fürs Routing ja evtl. auch relevant ist: http://wiki.osm.org/Proposed_features/Escalators_and_Moving_Walkways Objekt: Tunnel (Type: Fläche) - area = yes [...] - building = yes (es handelt sich um ein Indoor-Elment und soll in der Karte angezeigt werden) Einen Tunnel als building = yes zu kennzeichnen halte ich für sehr ungewöhnlich und sicher keine etablierte Praxis. Ich würde eher zu area:highway = footway für diese Fläche raten (unter Annahme, dass der bestehende Way für den Tunnel als highway = footway erfasst ist). Der Schlüssel area:highway ist zwar bisher nur ein Vorschlag, aber das hat vor allem damit zu tun, dass Flächenerfassung von Straßen und Wegen bei uns generell noch in den Kinderschuhen steckt. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Hi, zunächst einmal: Ich finde es großartig, dass sich da etwas zu entwickeln scheint (ein Hoch auf den VRR :-) ) Ich habe den Thread nur überflogen. Falls das Folgende also schon erwähnt wurde oder nicht passt, einfach ignorieren ... Ich möchte hier kurz einen Querverweis machen auf einen aktuellen Thread im OSM-Forum, wo es um ein paar Ideen bzgl. des ÖPNV-Schemas geht [1]. Der User Weide hat hier eine Vorversion [2] zu etwas erarbeitet, was mal ein Proposal zu einem überarbeiteten public_transport-Schema werden könnte. Die meisten der Punkte betreffen ÖPNV-Routen, aber es gibt auch Ideen/Ergänzungen z.B. zu platform. Möglicherweise gibt es hier zumindest an einigen Punkten Synergien? Es wäre schade, wenn diese beiden Arbeiten parallel existieren würden ohne voneinander Notiz zu nehmen ... Grüße Gerhard (Seoman) [1] http://forum.openstreetmap.org/viewtopic.php?pid=349000#p349000 [2] http://wiki.openstreetmap.org/wiki/User:Weide Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft auf OSM zu setzen. Das betrifft folgende Produkte · Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern beiliegen und die an den Haltestellen aushängen sollen aus den OSM Daten errechnet und im VRR Layout dargestellt werden. · Die Haltestellenumgebungspläne, die von einigen Betrieben erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen aus OSM Daten erzeugt werden. · Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen aus OSM Daten berechnet werden · Die interaktiven Karten der VRR App, dieselben wie die aus efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca. 1.000.000 mal heruntergeladen) · Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten (dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten gezeichnet werden (siehe auchefa.vrr.de und die Apps) · Die Fußwege zu den Haltepunkten und bis zum Gleis der Schienenverkehre sollen auf OSM Daten geroutet werden · Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen · Das Fußwegrouting soll barrierefreie Wege suchen können (wird weiter unter erklärt) Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem auch der Qualität und der Detailreichtum der OSM Daten hat den VRR begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere Datenmaterialien. Das Datenmaterial, das wir in OSM vorfinden hat vor allem bezüglich der Wege (Straßen und Schienenwege) aus ausgezeichnete Qualität. Einige Daten sind allerdings noch unvollständig für unsere Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam mit der OSM Gemeinde. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das? Gehen wir von drei typischen Benutzern aus: Nutzer 1 ist Student, Pendler und in Turnschuhen unterwegs. Er kommt immer knapp vor der Zugabfahrt. Er geht schnellen Schrittes durch den Bahnhof und nimmt die Treppen hinauf zum Bahnsteig, damit er nirgends warten muss. Nutzer 2 ist der Reisende mit Koffer, oder die/der Frau/Mann mit Kinderwagen. Der Nutzer kann nur mit großer Mühe die Treppen nutzen und sucht Wege über Rolltreppen zum Bahnsteig. Nutzer 3 kommt im Rollstuhl. Er ist auf Aufzüge und Rampen angewiesen um zum Bahnsteig zu kommen, er braucht entsprechende Wege. Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). Wir brauchen also alle
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 23.07.2013 13:27, schrieb Peter Wendorff: Hallo Tracy, Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Das ist super ;) [...] Einige Daten sind allerdings noch unvollständig für unsere Aufgabenstellung und diese wollen wir nacherfassen, gerne auch gemeinsam mit der OSM Gemeinde. Das klingt gut. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Das klingt gut - aber nach Import, deshalb bitte die Import-Richtlinien berücksichtigen, wenn ihr nicht jede Haltestelle selbst kontrolliert dabei. Eine Alternative ist oft, die Daten öffentlich und für die Nutzung freigegeben zu hinterlegen, damit man verteilt die Haltestellen anhand dessen überprüfen kann. [...] Das Ziel im Bahnhof ist also der Bahnsteig und der Punkt, wo man in die Bahn einsteigen kann. (Solange wir die Reihung der Züge nicht kennen oder deren Haltepositionen rechnen wir mit einem Punkt). Bahnsteige, wir nennen sie Plattformen, sind für Menschen mit Mobilitätseinschrängungenzugänglich oder nicht, weil sie einen Aufzug haben oder nicht. Es gibt Bahnhöfe, da sind nur einige Plattformen oder nur eine für Menschen mit Mobilitätseinschrängungen zugänglich. Auch auf der Plattform kann es mehrere Zugänge geben, oft einen mit Aufzug und Rolltreppe und andere mit fester Treppe (Beispiel Düsseldorf Hbf). Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Fast richtig. Ein Aufzug muss nicht zwingend ein way sein, um darauf route zu können. Beispiel: .x-' .x und ' seien Nodes, und jeweils dazwiscchen ways. x sei ein Aufzug und als solcher getagged (auf einem Node. trägt außerdem level=0, x trägt level=1 (was jeweils das Stockwerk angibt). Das Routing mit Berücksichtigung des Aufzugs ist hier problemlos möglich. Ebene Wege, Treppen, Rolltreppen und Rampen sind üblicherweise ways in OSM, Aufzüge aber nicht, weil sie kaum eine horizontale Ausdehnung haben. Technisch ist das aber kein Problem auch im Routing zu berücksichtigen. Wir haben in den existierenden OSM Daten unterschiedliche Modellierungen von Plattformen gefunden: · Einen „way“ der an das Fußwegenetz angebunden ist, eignet sich bei schmalen Bahnsteigen (Beispiel Stuttgart, Stadtbahnhaltestelle Berliner Platz/Hohe Straße) stimmt, und sollte für euch kein Problem darstellen. · Eine Fläche die an den Rändern an das Fußwegnetz angebunden ist, eignet sich bei Seitenbahnsteigen (Beispiel, ….) auch das sollte kein Problem sein zu nutzen. · Gesplittete Flächen, notwendig bei Mittelbahnsteigen (Gleise an beiden Seiten) mit Zugang aus Tunnels oder von Brücken (Beispiel München Ost) Falsch: Wieso sollte das Splitten notwendig sein? Die Plattform ist die von den Gleisen (z.B.) 2 und 3. Die linke Seite bietet den Zustieg zu Gleis 2, die rechte zu Gleis 3. Es bleibt aber erstmal trotzdem ein Bahnsteig. Wieso man diesen horizontal aufsplitten muss, verstehe ich nicht. Wenn ich zu GLEIS (!) 2 route (da fährt der Zug ab), dann route ich (so machen das bei Adressen auch alle gängigen Router) zum nächsten Punkt, der erreichbar ist. Das ist in diesem Fall der Bahnsteig 2/3, und da die linke Seite. Wo ist das Problem? Warum muss dafür der Bahnsteig gesplittet werden? und vor allem: Warum in den Rohdaten? Keine der drei Modellierungsarten ist unsere Erfindung, statt der gesplitteten Flächen können man auch mit Flächen mit Löchern arbeiten (Multipolygonen), das ist aber noch komplizierter und das haben wir noch nirgends gesehen. Ich find auch kein Beispiel; logisch wäre es aber meines Erachtens schon, und es würde mit Multipolygonen auf ein etabliertes OSM-Schema zurückgreifen, ohne dass neue Erfindungen mit falschen Daten gemacht werden müssten. Das Splitten der Bahnsteige in 2 oder mehr Teile hat den Vorteil, dass man in der Mitte Aussparungen lassen kann. In diesen Aussparungen können dann Treppen, Rolltreppen oder Aufzüge münden, die meist aus dem Fußgängertunnel kommen. Damit wir wissen, welche Teile zu einer Plattform gehören fassen wir diese Teile in einer Relation zusammen. Also trennt ihr erst um dann wieder per Relation zu verbinden... Selbst wenn ihr trennen müsstet (was ich bezweifle), wäre die Relation unnötig, denn die lässt sich einfach aus der Geometrie herleiten (die beiden Bahnsteige sind miteinander verbunden über eine gemeinsame Kante). Meine Empfehlung (darf gerne von anderen noch kommentiert werden) wäre: Eine Plattform ist eine Plattform und kein Gleis. Eine Plattform gehört z.B. zu zwei, manchmal auch zu drei oder mehr Gleisen, und das ist
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
On 07/23/2013 11:40 AM, Tracy Kasperczyk wrote: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. [...] Objekt: Aufzug (Type: way) - highway = elevator - level = -1,0 Aus dem Wiki: http://wiki.openstreetmap.org/wiki/Elevator Tags die schon vorhanden sind werden nicht von uns gelöscht. Sollte man den Elevator nicht evtl. als Node taggen? Die meisten gehen kerzegerade nach oben, was auf einer 2d-karte schlecht darstellbar ist. Die Option way würde ich beibehalten, da es ein paar Fahrstühle gibt, die schrägen Hochfahren (was aber wohl die Ausnahme sein dürfte) Gebäude mit weiteren Flächen: Objekt: Tunnel (Type: Fläche) - area = yes - tunnel = yes - level = ... - layer = ... - building = yes (es handelt sich um ein Indoor-Elment und soll in der Karte angezeigt werden) - designation = Unterführung Es werden die Fußwege auf den Tunnelflächen ebenfalls, erstellt bzw. wenn diese schon vorhanden sind, dann werden diese nicht gelöscht bzw. verändert. Wie bereits von einigen angesprochen, handelt es sich bei Tunneln nicht wirklich um Gebäude (ansonsten müssten wir auch jede Brücke und jede Straße als solches kennzeichnen, was ziemlich unübersichtlich wird. Besser wäre es highway=footway zu nehmen. Sollte es sich wirklich um eine Unterführung handeln, dann mit tunnel=yes. Bei Unterführungen, die abgeschlossen sind und wie ein innerer Bahnhof wirken, wie im neuen Erfurter Hauptbahnhof, wäre wohl eher indoor=yes angebracht. Aber darüber kann man streiten. in meiner Gegend hat sich ziemlich herauskristalisiert, dass man zwar Flächen von Verkehrsflächen angeben kann, aber immer zusätzlich einen Way in der Mitte zeichnet, der das Routing ermöglicht. Ansonsten können die meisten Router nur am Rand der Fläche Routen. Sprich, wenn ihr einen Tunnel als Area einzeichnet, dann legt in der Mitte noch einen Way an. Und ganz wichtig. Verbindet den Way auch zu den (Roll-)Treppen und Aufzügen! Alternativ zu den Flächen könnte man auch überlegen dem Tunnelway ein Attribut mitzugeben, dass aussagt, wie breit der Tunnel ist, oder ihr erfindet, ähnlich dem Flussufer, ein Polygonattribut für Verkehrsflächenumrandungen. Bitte gebt immer an, ob Radfahren in den Unterführungen erlaubt ist oder nicht! Dann könnte man Radfahrer evtl. an den nächsten mit Rad zugänglichen Zugangspunkt am Bahnhof leiten, ohne ihn durch den ganzen Bahnhof zu jagen [...] just my 2 cents, Andreas -- Andreas Neumann http://stadtplan-ilmenau.de signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar
Hallo Johannes, Am 23.07.2013 13:18, schrieb jotpe: Hallo Dietmar, sehe ich mir die Berliner Str. in Westhoven an, sagt die grafische Auswertung, dass 251 Hausnr. fehlen. Soviele Häuser gibt es da gar nicht. Kann es sein, dass die Hausnummer von einer anderen Berliner Str. in Köln kommen? Ja stimmt. Es gibt eine weitere Berliner Straße im Nordosten Kölns, die sich über die Bezirke Mülheim, Höhenhaus und Dünnwald erstreckt. In der Spalte Hausnummern nur OSM werden noch zuviele Einträge angezeigt, hier die schon erfassten, die aber in den anderen Bezirks-Listen stehen, also nicht nur in OSM existieren. Ich muß da noch eine kleine Strukturänderung der DB vornehmen, dann ist der Fehler hoffentlich bald weg. Ich versuche, nach der Beseitigung Bescheid zu geben, wenn ich's nicht vergesse ;) Danke und viele Grüße Dietmar Viele Grüße Johannes Am 23. Juli 2013 12:13 schrieb Dietmar ostr...@diesei.de: Hallo Malte, jetzt gehen sie wieder. Ich hatte gestern abend und heute vormittag neue Auswertungen durchgeführt und die Dateinamen in falsche Umlautschreibweise abgelegt, derzeit gehen Aktualisierungen noch nicht automatisch. Viele Grüße Dietmar Am 23.07.2013 11:59, schrieb Malte Blättermann: Moin Dietmar, Die grafischen Auswertungen funktionieren scheinbar nicht mehr: http://regio-osm.de/**hausnummerauswertung/**grafikdarstellung/anzeige.* *html?ort=K%C3%B6lnhttp://regio-osm.de/hausnummerauswertung/grafikdarstellung/anzeige.html?ort=K%C3%B6ln Die *.osm Datei kann nicht geladen werden, für München das selbe. Grüße, Malte __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de __**_ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar
Hallo Markus, ich habe Deinen Post nicht vergessen, sondern wollte warten, ob sich noch jemand meldet und hier ruft, war aber nicht ;) Es sollte dann wohl einer von uns beiden eine Lösung erstellen und würde möglichst dem Anderen einen Service anbieten, diesen für sich zu nutzen. Nimm bitte initialen Kontakt mit mir auf über OSM PM Useraccount okilimu, dann können wir das weitere per Mail ausmachen. Viele Grüße Dietmar aka okilimu Am 20.07.2013 10:41, schrieb Markus Semm: Hallo, Zur SOTM im September planen wir eine neue Version des Keypad-Mapper 3, die u.a. eine Liste fehlender Hausnummern pro Strasse in der Umgebung des aktuellen Standorts des Mappers enthalten wird. Dabei haben wir dasselbe Problem wie Bernd, dass es Hausnummern in der Realität schlicht nicht gibt, die eigentlich ins Schema passen würden, also z.B. 1,3,7 statt 1,3,5,7 auf einer Strassenseite. Aktuell planen wir, eine eigene Datenbank vorzuhalten, die außerhalb von OSM solche Fälle vermerkt, damit nicht jeder Mapper immer wieder in die selbe Falle läuft und nach der Hausnummer sucht. Nachdem Dietmar auch auf solche Daten angewiesen ist für eine zuverlässige Anzeige und sicherlich auch weitere Software in der Zukunft macht es Sinn, diese Information an zentraler Stelle zu sammeln. Hat jemand eine Idee, wo man diese Information am Besten ablegen könnte? Cheers Markus -Ursprüngliche Nachricht- Von: Bernd Weigelt [mailto:weigelt.be...@web.de] Gesendet: Samstag, 20. Juli 2013 08:41 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Hausnummernauswertung in einer ersten Version verfügbar Am 19.07.2013 22:48, schrieb Dietmar: Fehler (davon gibts noch eine Menge) und Verbesserungswünsche (da aber bitte viel Geduld mitbringen) melden. Hallo Dietmar gute Arbeit, vielen Dank dafür. Mir ist aufgefallen, dass es einige Hausnummer als fehlend angezeigt werden, obwohl ist die gar nicht gibt Z.B. In Köln-Mülheim die Juliusstraße, die geraden Hausnummern, die dort angemäckelt werden, sind nicht vorhanden. Bei der 9f bin ich mir nicht ganz sicher, aber ich glaube , die ist auch false positive. Bei vielen anderen Straßen ist es ähnlich Ansonsten ist das eine sehr gute Arbeitshilfe Bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserturm verschwunden
Am 23.07.2013 12:25, schrieb Walter Nordmann: Das klappt aber eigentlich nur, da OSM-ler Insiderwissen haben und die Datenstrukturen beherrschen. Außenstehende haben da erhebliche Probleme. Und das bezeichne ich nun mal als Propertiäres System. Das ist aber eine sehr merkwürdige Definition, weil nach dieser alles proprietär ist. Proprietär wäre es in meinen Augen, wenn das Format geheim ist. Das ist es bei OSM aber nicht. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserturm verschwunden
Henning Scholland wrote Das ist aber eine sehr merkwürdige Definition, weil nach dieser alles proprietär ist. Proprietär wäre es in meinen Augen, wenn das Format geheim ist. Das ist es bei OSM aber nicht. Ist eventuell etwas zu hart formuliert. Dieser Auszug aus http://de.wikipedia.org/wiki/Propriet%C3%A4r trifft meiner Meinung für OSM zu: Traditionell werden im IT-Bereich solche Dateiformate, Protokolle usw. aber auch Hardware als proprietär bezeichnet, die nicht allgemein anerkannten Standards entsprechen, also sozusagen „hauseigene“ Entwicklungen sind (Beispiele sind die Cisco VoIP-Telefone mit Skinny-Protokoll und die Software Skype). Dass das OSM-Schema nicht zum Schutz vor irgendwas stehen soll, ist klar. Es ist schlicht veraltet. Gruss walter aber alles Diskutieren bringt uns eh nicht weiter - Api 0.7 ist nicht in Sicht, also bleibt alles beim Alten - [url=http://osm.wno-edv-service.de/residentials] Missing Residentials Map 1.17[/url] [url=http://osm.wno-edv-service.de/plz] Postcode Map 2.0[/url] -- View this message in context: http://gis.19327.n5.nabble.com/Wasserturm-verschwunden-tp5770618p5771120.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Tracy Kasperczyk schrieb: · Gesplittete Flächen, notwendig bei Mittelbahnsteigen Nein. Notwendig für EURE Daten, aber generell nicht notwendig, und auch nicht erwünscht. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-07-23T19:56:12+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID) - bitte sofort stoppen
Am 22.07.2013 07:16, schrieb Wilhelm Spickermann: Wenn mein Name oben drüber steht und dann nur Text kommt, der nicht von mir ist, dann ist das irreführend. Sorry, ich hatte das Verrutschen um eine Einzug übersehen. Ich entschuldige mich dafür. Aber: Stephan hatte das Ganze sehr allgemein zitiert und auf den ganzen Thread Bezug genommen = etwas mehr Gelassenheit würde der ganzen Diskussion gut tun... Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: Tunnel sind oft schon in den Daten vorhanden. Die sind für uns als Wegelemente sehr hilfreich. Allerdings wollen wir auch Karten für den Untergrund zeichnen, wenn sehr breite Tunnels nur als Strich daherkommen ist das irreführend. Wir brauchen also zusätzlich Flächen. -1, absolut dagegen. Wir malen keine Karten mit einem Malprogramm sondern wir erfassen die Topologie! Da was schon immer so und sollte auch so bleiben. Wenn, dann gebt z.B. für einen Weg eine Breite mittels width == xxx an. Wir sind schon seit einiger Zeit mit der Münchner OSM Gruppe in Kontakt und haben viel gelernt. :-) Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 24.07.2013 um 00:39 schrieb Michael Kugelmann michaelk_...@gmx.de: -1, absolut dagegen. Wir malen keine Karten mit einem Malprogramm sondern wir erfassen die Topologie! Da was schon immer so und sollte auch so bleiben. Wenn, dann gebt z.B. für einen Weg eine Breite mittels width == xxx Wir erfassen ja nicht nur einen Graphen, auch wenn der ziemlich nützlich ist. M.E. Ist der Wunsch legitim, auch unterirdische Plätze und Verkehrsräume von öffentlichen Gebäuden mit ihren Grenzen aufzunehmen und nicht nur als linearen Graph, mit einem Malprogramm sollte man das nicht verwechseln, allerdings ist mit derzeitiger Editor-Technik mehr als ein Stockwerk übereinander eigentlich nicht effizient bearbeitbar oder verständlich, von daher ist der Einwand auch nicht völlig unberechtigt. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] nochmal temporäre Sperrungen: Ablaufdatum? (Was: Einführung eines neuen Tags (globaleID))
Auch bei OSM-Daten haben Navis nicht ständig eine aktuelle Karte, sondern z.B. alle paar Monate neu generierte Offline-Daten. Das ist prinzipiell schneller möglich als bei anderen Anbietern, aber das heißt nicht, dass es schneller aktualisiert wird. Wenn dann eure 3-Tage-Wartung der Rolltreppe im Kartenmaterial von Max Mustermanns Navi für die nächsten 6 Monate festgelegt ist, ist das Mist. Da wir das Problem wohl mit steigender Frequenz bekommen: Warum temporäre Sperrungen nicht mit Ablaufdatum (selbst wenn das noch geraten ist) versehen? Oder zumindest mit einem temporär-Tag. Dann kann der Extraktor, der die Daten für sein Medion-, Navit oder was auch immer zieht, die Dinger gleich abfiltern und so rendern, als ob nix wäre, wenn er schon weiss, dass er (und seine Anwendung) keinen regelmäßigen Datenabgleich hinbekommt. (Wobei ich natürlich immernoch Bauchschmerzen habe, so ein Mappen für den Medion zu betreiben, nur weil die keine sinnvollen Aktualisierungszyklen hinbekommen mit OSM-Daten.) -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Zunächst einmal an die Community. Im Allgemeinen wünschen wir Quellen für Importe. Bezogen auf die geografischen Einordnung ist dies aber in diesem Falle möglicherweise schwierig, wenn diese Daten überhaupt erst mit Hilfe von OSM Werkzeugen erstmals im geografischen Umfeld erfasst werden. Wir haben hier möglicherweise eine bisher nie oder kaum dagewesene Situation, dass OSM die Erstveröffentlichungsquelle ist und damit eine andere Quelle nicht zur Verfügung steht. Dann müssten wir uns im Rahmen dieses Imports überlegen, wie die für Importe notwendige Zusicherung, diese Daten unter der OSM Lizenz veröffentlichen zu dürfen, bewirkt werden kann. Ich denke, hier sollten wir unsere Data-Working-Group mit ihren entsprechenden Erfahrungen mit größeren Importen um Mithilfe bitten. Tracy Kasperczyk kasperc...@mentzdv.de wrote: Liebe OSM Gemeinde, Wir wollen euch noch mal genauer erklären was wir machen. Sehr gut. :-) Der VRR (Verkehrsverbund Rhein-Ruhr) auch tätig als zentraler Koordinator für das Land Nordrhein Westfalen beabsichtigt als Kartenbasis in Zukunft auf OSM zu setzen. Das betrifft folgende Produkte Wenn der VRR der zentrale Koordinator für NRW ist, dürfte ihm nicht entgangen sein, dass Marcel Hövelmann vom Verkehrsverbund Rhein Sieg sowie Thomas Reincke vom Aachener Verkehrverbund aus ähnlichen Beweggründen wie ihr, schon Jahre eine gedeihliche Zusammenarbeit mit OSM pflegen. Ist Euch das bekannt? Hier der Vortrag der beiden auf unserer D-A-CH Konferenz namens FOSSGIS 2011: http://ftp5.gwdg.de/pub/misc/openstreetmap/FOSSGIS2011/FOSSGIS2011-191-de-oepnv_vrs_aav.webm Hier die neueste OSM Anwendung des VRS, die übrigens immer weiter in den Bereich des VRR, insbesondere der Rheinbahn hineinreicht. Zum Beispiel findet man dort den U-Bahnhof Heinrich-Heine-Allee in Düsseldorf: http://www.vrsinfo.de/fahrplan/haltestellen-und-linieninformationen.html Von daher wäre es vielleicht nicht das Schlechteste, mit den beiden Herren Kontakt aufzunehmen. Sie sind daneben auch OSM-Community erfahren. · Die Karten, die Verkehrslinienpläne, die den Fahrplanbüchern beiliegen und die an den Haltestellen aushängen sollen aus den OSM Daten errechnet und im VRR Layout dargestellt werden. · Die Haltestellenumgebungspläne, die von einigen Betrieben erstellt und ausgehängt werden, z.B. von der Rheinbahn in Düsseldorf sollen aus OSM Daten erzeugt werden. Zur Info für die Community: So sehen die Umgebungspläne der Rheinbahn heute aus, die im Wesentlichen nur für die inneren Stadtteile Düsseldorfs existieren: http://www.rheinbahn.de/fahrplan/karten/Seiten/haltestellen.aspx In den peripheren Stadtteilen Düsseldorfs und in fast allen umliegenden Städten kann der Fahrgast nicht auf solche Pläne zurückgreifen. Selbst die Umsteigepunkte mit vielen Linien sind in deren Plänen derzeit nur durch einen gemeinsamen Punkt gekennzeichnet. · Die interaktiven Karten die sie z.B. in efa.vrr.de sehen sollen aus OSM Daten berechnet werden · Die interaktiven Karten der VRR App, dieselben wie die aus efa.vrr.de sollen aus OSM berechnet werden (die Apps wurden schon ca. 1.000.000 mal heruntergeladen) · Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten (dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten gezeichnet werden (siehe auchefa.vrr.de und die Apps) · Die Fußwege zu den Haltepunkten und bis zum Gleis der Schienenverkehre sollen auf OSM Daten geroutet werden · Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen · Das Fußwegrouting soll barrierefreie Wege suchen können (wird weiter unter erklärt) Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem auch der Qualität und der Detailreichtum der OSM Daten hat den VRR begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere Datenmaterialien. Sehr gut. Ich bin sicher, dass sehr viele in der Community genau dafür mappen, dass ihre Daten entsprechend nützlich werden können - insbesondere was die in anderen Karten nicht zu findende Detailliertheit an Fuß- und Radwegen angeht. Weitere Datenelemente die wir brauchen, sind die oben erwähnten Haltepunkte auf den Schienen oder die Haltepunkte der Busse vor dem Bahnhof. Dies Punkte brauchen wir um einen Weg auf die Karte zeichnen zu können. Dort ist Anfang oder Ende des Wegs im Fahrzeug und der Übergang auf den Fußweg. Das sind bekannte OSM Objekte ( http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_position) Insbesondere bei den Bussen ist mir nicht klar, wozu ihr die stop_position braucht. Ein Bus hält etwa am Haltestellenschild bzw. an der Mitte der Plattform (public_transport=platform) auf seiner in OSM enthaltenen Route. Warum fällt ihr nicht einfach das Lot
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Michael Kugelmann michaelk_...@gmx.de wrote: Allerdings wollen wir auch Karten für den Untergrund zeichnen, wenn sehr breite Tunnels nur als Strich daherkommen ist das irreführend. Wir brauchen also zusätzlich Flächen. -1, absolut dagegen. Wir malen keine Karten mit einem Malprogramm sondern wir erfassen die Topologie! Da was schon immer so und sollte auch so bleiben. Hmm http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver aber auch http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank Machen wir damit nicht das Eine, ohne das Andere zu lassen? Wenn, dann gebt z.B. für einen Weg eine Breite mittels width == xxx an. Ginge auch. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Am 23.07.2013 11:40, schrieb Tracy Kasperczyk: · Die Fahrten der Verkehrsmittel sollen referenziert mit OSM Daten (dabei werden die Koordinaten der Fahrwege übernommen) auf diese Karten gezeichnet werden (siehe auchefa.vrr.de und die Apps) als Overlay oder als Verknüfung zu den OSM-Daten? Ich Route die Linienwege auf der OSM-Karte. Die dabei entstehenden Fahrwege sind jedoch von OSM unabhängig. Eine Verknüpfung findet nicht statt. Wenn ein neuer Kreisverkehr eingerichtet wird oder der Straßenverlauf verfeinert wird, bekomme ich das nicht mit. Das wird im Rahmen der regelmäßigen Durcharbeitung des Bestandes korrigiert - oder eben auch nicht. bei einer technischen Lösung sähe ich einen erheblichen Mehraufwand bei einem nur marginalen Mehrnutzen. Extrem wird es bei den Eisenbahnen, wo inzwischen an vielen Stellen jedes Gleis eingezeichnet ist. Eigentlich müsste man dann wirklich den genauen Fahrweg über jede Weiche prüfen und darstellen. Diesen Aufwand treibe ich nicht. · Die Fußwege zu den Haltepunkten und bis zum Gleis der Schienenverkehre sollen auf OSM Daten geroutet werden · Die Apps sollen Fußwegnavigation auf den OSM Daten unter stützen · Das Fußwegrouting soll barrierefreie Wege suchen können (wird weiter unter erklärt) Dazu brauche ich m.E. keine Integration der ÖV-Daten in OSM. Wenn es ungefähr zueinander passt, reicht das völlig aus. Für die Entscheidung des VRR waren Kostengründe maßgebend, aber vor allem auch der Qualität und der Detailreichtum der OSM Daten hat den VRR begeistert. Gerade in der Welt des Öffentlichen Verkehrs und des Fuß- und Radverkehrs gibt es keine vergleichbaren GIS Daten. Gerade beim Fußweg-Routing versprechen wir uns wesentlich Verbesserungen, da die OSM Daten weit mehr Fuß- und Radwege und Straßenquerungen enthalten als andere Datenmaterialien. Diese Gründe waren für uns vor über drei Jahren ebenfalls ausschlaggebend. Ein Bereich der Nacherfassung umfasst die Busspuren und die Abbiegeverbote oder Abbiegeerlaubnisse von Bussen. Wir haben Kontakt zu allen Verkehrsbetrieben, wir können die Informationen von dort bekommen und nachpflegen. Schön, aber wozu? Ich würde mir den Linienverlauf als Layer besorgen und mit OSM abgleichen, ob er dort fahrbar ist. Busspuren müssen dort rein, wo sie baulich eine eigene Fahrbahn sind. Das wird wahrscheinlich fast überall der Fall sein. Der zweite Bereich umfasst die Bahnhöfe und die Haltestellen der Schienenverkehre (Straßenbahn, U-Bahn). Es ist das Ziel einen Fußweg bis von einem beliebigen Punkt im Wegenetz bis zum Bahnsteig und dem Haltepunkt des Fahrzeugs zu berechnen, anzuzeigen und Navigation auf diesem Weg zu ermöglichen. Dieser Weg soll auch barrierefrei sein. Was bedeutet das? Ist das so sinnvoll? Wichtig sind die Ausgänge einer U-Bahn-Station. Die müssen innerhlb des Haltestellenmodells erfasst sein. Die Wege innerhalb des Bauwerks wird festgelegt und durch eine Zeit sowie ggf. die Arten der Einschränkungen in der Nutzbarkeit festgelegt. Die Zeiten hängen von der zurückgelegten Strecke, der Zahl der Stufen sowie ggf. technischen Parametern, wie Warte- und Fahrzeit eines Aufzuges ab. Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Einmalig, bei der Erstellung. Aber nicht on the Fly bei jeder Verbindungsabfrage. Der VRR macht sich die Entscheidung, auf OSM zu setzen nicht leicht. Man ist immer noch besorgt, dass Daten, die in die Produktion der Fahrplanunterlagen und Karten gehen sich kurzfristig unkontrolliert ändern. Wir bitte deshalb auch die OSM-Gemeinde hier Vorsicht walten zu lassen. Man kann immer mit uns Kontakt aufnehmen. Deshalb die eigenen Daten von den Kartendaten trennen. Es ist nicht nur so das der VRR in Zukunft auf OSM umstellen möchte, es werden sondern noch weitere Verkehrsverbünde und Betriebe diesem Beispiel folgen. Der VRR ist nicht der erste Verbund der das macht... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einführung eines neuen Tags (globaleID)
Thomas Reincke schrieb: Wir brauchen also alle Plattformen einzeln und alle Wegelemente im Bahnhof, ebene Wege, Treppen, Rolltreppen, Rampen und Aufzüge. Diese Wegelemente müssen „ways“ sein, sonst kann man nicht darüber routen. Einmalig, bei der Erstellung. Aber nicht on the Fly bei jeder Verbindungsabfrage. Vor allem wird hier wieder „wir“ durch „man“ ersetzt, denn „man“ kann sehr wohl darüber routen. Dass das geht, zeigen diverse Routingprogramme, die ohne Probleme über Treppen und Aufzüge routen können. Der VRR macht sich die Entscheidung, auf OSM zu setzen nicht leicht. Man ist immer noch besorgt, dass Daten, die in die Produktion der Fahrplanunterlagen und Karten gehen sich kurzfristig unkontrolliert ändern. Wir bitte deshalb auch die OSM-Gemeinde hier Vorsicht walten zu lassen. Man kann immer mit uns Kontakt aufnehmen. Deshalb die eigenen Daten von den Kartendaten trennen. Das sage ich denen schon seit der ersten Mail :) Spezialdaten als eigenen Layer bereitstellen, und dort, wo es gewünscht ist, eben mit den Daten aus OSM zusammenfügen, und ausliefern. Das ist ja auch wesentlich stressfreier, da nicht unnötig Bahnhöfe gespalten, oder Aufzüge als Weg gemappt werden müssen. Grüße, Dirk -- Local time :: Ortszeit :: DE-HH 2013-07-24T07:31:50+0200 signature.asc Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
