Re: [Talk-de] [Archologie] - Langbett
Torsten Leistikow schrieb: Dass weder Dolmen noch Grosssteingrab haeufig eingetragen wurde, duerfte daran liegen, dass die betreffende Wiki-Seite es ja noch nicht mal in den Proposal-Status geschafft hat und somit kaum bekannt sein duerfte. Freiwillige vor, die erstmal fuer eine Uebersetzung ins Englische sorgen. Ich halte ja viel von dem Ansatz, gerade bei Spezialbegriffen, die ganz konkret bestimmte historische Erscheinungsformen vergangener Kulturen bezeichnen, diese auch als Wert im Tag zu verwenden. Ich erinnere in diesem Zusammenhang an die Diskussion über mögliche Bezeichnungen für Burgen aus 2008. Castle mag überall auf der Welt als Bezeichner für mittelalterliches befestigtes Zentrum militärischer Macht herhalten können, aber es ignoriert halt die kulturellen Unterschiede zwischen englischen Castles, deutschen Burgen (oder Schlössern), russischen Kremls oder japanischen Shiros. Dasselbe Problem der kulturellen Unterschiede gibt es sogar beim Highway-Key: trunk ist eine rein englische Verwaltungsbezeichnung für unterschiedlichste Straßentypen (hinsichtlich der Fahrbahngestaltung), die man nicht ohne Übersetzungsfehler auf deutsche Straßen anwenden könnte. Die nationale Übereinkunft für Deutschland sieht nun halt vor, dass trunk für Autostraßen und ähnliche, autobahnähnliche Verkehrswege genutzt wird - aber mit dieser Erwartung darf man halt nicht ins schottische Hochland kommen und dort dasselbe für die dortigen Trunks erwarten. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Wiki: chriscf vandalism
Richard Fairhurst schrieb: Frederik Ramm wrote: the German community takes offence at user:chriscf's deletion of the smoothness voting result from approved features and moving it to rejected features in spite of of there having been a proper vote with an approved outcome. Then the German community should come to this, non-localised mailing list and have the cojones to say so. Frederik as a member of the german community just did so. And if this is not enough for you: I take offense in chriscf's action as well. No matter how much I like this tag, his action is simply unacceptable. And now? ... Chris has had the courage of his convictions to stand up against an utterly ridiculous tag, thereby pointing out the flaws in a voting system which a lot of us are silently unhappy with. Good luck to him. Edit war on the wiki? Regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki: chriscf vandalism
Pieren schrieb: The problem here is that Chriscf just wants to avoid that this tag is used by others and never proposed some alternative solutions. The current voting is 19 yes and 10 no. If Chriscf cannot convince at least another 10 people to oppose this proposal, he must face the fact that he has been overruled. Chris: Organize more opposition, and nobody will complain about this tag being rejected because too many people were against it. But do not put your single vote above all others. Regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Wiki: chriscf vandalism
Richard Fairhurst schrieb: With smoothness that's gone out of the window. As far as I'm concerned, with the approval of smoothness=very_horrible (come _on_!), all bets are off. The voting system has just voted itself into irrelevance. I take it that you oppose this tag. Why haven't you said so in the voting section until now? :) Regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Kurze Brücken
Stefan Hirschmann schrieb: Ich gebe solche Brücken überhaupt nicht ein. Bach Layer=-1 und Straße Layer=0 und alles wird korrekt dargestlelt und sogar der Validator ist zufrieden. An den Bach gehört kein Layer=-1 ran. Grundsätzlich nicht. Weil der Layer dann nämlich gern pauschal an den gesamten Bach gepackt wird, nicht nur, wie es sich eigentlich gehören würde, an das lokale kleine Stück im Bereich der Nicht-Brücke. Und wenn ich mir so die Aussagen zu diesem Validator durchlese, dann komme ich zu der Erkenntnis, dass dieser Programmteil offenbar hinsichtlich seines Regelwerks einige Monate bis Jahre hinter der aktuellen Entwicklung herhinkt. Ich würde ihm also nicht allzu große Bedeutung beimessen. Wenn überhaupt ein Layer, dann gehört layer=1 an ein Stückchen der Straße, was sich, sofern die Brücke schwer einzuzeichnen ist, gern auch unabhängig von der realen Brücke etwas weiter ausdehnen darf. Wobei ich mich immer noch frage, wo denn eigentlich das genaue Taggingproblem sein soll. Und ein intelligentes Auswerteprogramm weiß sowieso, dass es eine Brücke sein muss, bzw. dass auf jeden Fall die Straße drüber geht. Also gar nichts taggen? Vorteil: wenn den Bach verschiebst, passt immer noch alles, da sich Bach und Straße keinen Punkt teilen. Straße und Bach dürfen keinen gemeinsamen Punkt haben. Ich erkenne als Potlatch-User auch nicht, wo das Problem des Verschiebens sein soll. Ich verschiebe Punkte, daraus resultiert dann ein neuer Linienverlauf von Straße oder Bach. Und wenn ich was verschiebe, dann kann daraus selbstverständlich resultieren, dass ich Daten, die mit dem alten Verlauf zusammenhingen, ebenfalls korrigieren muss. So ist das nun mal. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] [Tag-Proposal] Freifunk/Mesh nodes + links
Linus Lüssing schrieb: In my opinion Freifunk and OpenStreetMap are both very good and valuable public services run by eager indivuals. However, I'm wondering, if these public services shouldn't be interconnected with each other a bit more. While I am not against working together, I doubt it would be useful to dump your database into OSM. So far, most Freifunk-communities are mostly using Google for visualising the nodes and connections between these nodes on a map, which does not really suite the Freifunk ideology in my opinion. Then you are free to use OSM as an alternative background layer for your visualisations. That's fine - if you can accept the usual hiccups of the OSM servers. OSM is not Google, it cannot deliver 24/7 service, although we would all like it to be so. Therefore I propose the following new tags for a mesh-node in general and the connections between mesh-nodes in OSM. We had an import of Fon nodes about a year ago, which resulted in a discussion about the usefulness of such data in OSM. The import itself was questioned because of a unclear database license at the source (so it should not have happened in the first place), but also the usability was questioned because OSM data is rather static, and the availability of WLAN nodes is quite dynamic. In the end it turned out that nobody felt responsible for the data, neither for keeping them current and correct them nor for removing them from the OSM database again. In my opinion OSM should stick to map physical objects which can be seen by humans, not try to integrate the more obscure world of radio waves. That is not to tell you your data is useless, but to distinguish between your special interest group and the public. What is good for the public in terms of map rendering might not be good for you, and vice versa. Currently we see the development of several special-interest-maps which highlight certain parts of the OSM data (such as the cycle map, the hiking map, the public transport map, as well as some validator maps to spot data problems). I can imagine that there will be some kind of general background map, which can be used together with a separate map layer that contains special interest data from a different source, e.g. Freifunk node locations. One comment on your proposal: Tags for connections between nodes: highway - data type - wireless oneway - yes, no (omitting this tag implies no) No! highway is for mapping roads - patches of earth surface used by vehicles for ground transport. highway=data is an abuse. PPS: So far, the idea is, that every person who is running a node and wants to publish this will have to do this manually in OSM first. But I could also imagine an implementation in the firmwares themselves for adding parts of the details automatically. The connections between the nodes could be probed, measured and uploaded to OSM in certain periods of time. (Transmitting the link details every hour wouldn't harm the database, would it? The big advantage of this would also be, to be able to visualise the growth of a mesh-network over time.) I think OSM is the wrong place for your ideas. Yes, they are nice and sound good, but I think you'd be better off if you use a separate database for stuff like this. Regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Fehlerhaft NOEXIT-Anwendung
Chris-Hein Lunkhusen schrieb: Moin Jan, meiner Meinung nach wäre folgendes korrekt: noexit=yes auf Node: sollte dort sein, wo das Schild steht, so wird es ja auch in JOSM gemalt und irgendwann vllt auch in Osma /Mapnik. Diese Info ist allerdings redundant dadurch, dass man leicht auf der Karte erkennen kann, dass die Straße endet. Ich sehe den Sinn nicht, das extra einzutragen. optional: noexit=yes auf den Way. Dito. Und vor allem widersprüchlich, wenn am Ende der Sackgasse ein Fuß- oder Radweg weiterführt, auch wenn der auf dem Straßenschild nicht erwähnt wird. um das Straßenende auf dem letzten Node zu markieren: highway=turning_circle Wenn da einer ist, und der so klein ist, dass es sich nicht lohnt, die kreisförmige Fahrbahn zu mappen. oder highway=end_of_road(vorschlag) falls es keinen Wendehammer gibt. Die Abwesenheit von turning_circle bedeutet end_of_road - vor allem dann, wenn der End-Node noexit kriegt. Insgesamt würde ich sagen: Das Mappen von noexit als Replikation von Straßenschildern erscheint mir einerseits überflüssig und zweitens auch zu autofahrerzentriert. noexit als tatsächlicher Endpunkt eines nicht mehr weiterführenden Wegs in den Fällen, wo ein Validator ansonsten meckern würde, erscheint mir hingegen sinnvoll. Ob's schlau ist, ein Wegesende irgendwo in der Pampa zu markieren, damit man anderen Mappern die Arbeit spart, später die fehlende Wegfortsetzung nachzuprüfen, mag jeder selbst entscheiden. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserski-Anlage
Jan Tappenbeck (OSM) schrieb: Moin ! wie würdet Ihr die Bahn einer Wasser-Ski-Anlage definieren ? Als Wasser. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Linien richtig taggen?
Gerrit Lammert schrieb: Sieht erstmal so richtig aus. Du könntest noch operator=name_des_örtlichen_Verkehrsverbundes eintragen und ich würde auch noch ein name= dransetzen. Vermutlich ist name das gleiche wie ref und damit überflüssig, aber schadet ja nicht. :) Die in Hamburg verbreitete Art des Taggings ist: network=HVV (Verkehrsverbund) operator=PVG (Im Verbund enthaltenes Unternehmen, das die Linie betreibt - Angabe nur, wenn bekannt) name=HVV-Buslinie 23 (Etwas beschreibenderer Name, um unterscheidbar zu sein von anderen Linien 23 in anderen Städten) ref=23 (Diese Angabe kommt in die ÖPNV-Karte) Warum hast Du als role denn way vergeben? Ist IMHO überflüssig, dort sollte man eher forward/backward eintragen für Abschnitte, die nur in eine Richtung befahren werden. Wobei wichtig anzumerken ist, dass sich forward/backward als relative Bewegungsrichtung ausschließlich auf die Richtung des jeweiligen Wegstücks beziehen, nicht auf die Bewegungsrichtung der Linie (Hin- bzw. Rückfahrt). Ich selbst füge die Haltestellen auf dem Weg auch noch in die Relation ein, aber darüber herrscht uneinigkeit. Das tue ich auch, und habe kein schlechtes Gewissen dabei. Immerhin wird auf diese Weise schon mal festgehalten, welche Linie an welcher Haltestelle zu finden ist. Manche Expresslinien lassen ja Haltestellen aus. Da anzunehmen ist, dass sich einerseits Linien auch mal ändern/wegfallen/neu erstellt werden, und andererseits die konkreten Anforderungen an das Tagging erst dann bekannt sind, wenn eine Software diese Angaben wirklich nutzen will, werden sowieso im Laufe der Zeit noch diverse Änderungen vorzunehmen sein. Das finde ich allerdings absolut nicht dramatisch. Ich würde sogar davon ausgehen, dass es zu gegebener Zeit mindestens einen entsprechenden Validator gibt, wenn nicht sogar einen Konvertierbot. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] reine S-Bahn-Strecken
Tobias Wendorff schrieb: Ich würde daher für reine S-Bahn-Netze und Linien, die nur als solche ausgezeichnet sind, folgendes Tagging vorschlagen: railway = interurban Warum dies? S-Bahn-Gleise werden als railway=light_rail getaggt. Dasselbe gilt für entsprechende Routen z.B. in der ÖPNV-Karte. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] construction
Heiko Jacobs schrieb: Garry garr...@gmx.de wrote: Ich werde meine m?hsam erstellten Objekte weiterhin gegen Dich verteidigen das ich sie weiterhin vor Ort mit Mobilger?ten verfeinern kann. Einige dieser Objekte hast Du nicht muehsam erstellt und ein anderes Objekt wird nur ueber meine Leiche als existent gerendert, solange das noch nicht mal richtig geplant ist, geschweige denn, dass da die naechsten Jahre ueberhaupt eine Baumschine in der Naehe ist. Wenn ihr weiter idiotische Edit-Wars in OSM und auf der Mailingliste aufführt, wäre ich sehr dafür, euch den Account zu schließen - egal wer angefangen hat und wer Recht hat. Viele Grüße (naja, vielleicht eher nicht...) Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.
Karl Eichwalder schrieb: Hatto von Hatzfeld ha...@salesianer.de writes: Da sollte man sich immer fragen, wer denn diese Information nutzen kann: Kein Radfahrer wird doch je auf einer Karte nachschauen, wann denn ein solcher Bordstein kommt. Und für die Routenplaner genügt es, wenn an den Kreuzungen erfasst ist, wie man in welche Richtung weiterfahren kann. Das denken die verkehrsplaner auch, aber du auf einem radweg bist und erst kurz vor der kreuzung erfährst, bei der nächsten kreuzung links abbiegen, dann ist das meist zu spät. Du wirst nicht mehr vom radweg kommen und links abbiegen können; dann wird dir nur noch indirektes abbiegen möglich sein. Wenn man auf einem benutzungspflichtigen Radweg fährt, hat man sowieso keine legale Chance, auf die Straße zu wechseln und links abzubiegen. Das wird einem vermutlich aber auch durch den Straßenverkehr unangenehm gemacht, denn Radwege sind nicht zum Spaß da, dazu sind sie viel zu teuer. Insofern sehe ich nicht, was dagegen spricht, den Linksabbiegevorgang einfach durch das Überqueren zweier Fußgängerfurten rechtsaußen an der Kreuzung zu vollziehen - insbesondere, weil Ampeln nicht unwahrscheinlich sein dürften. Davon unberührt bleibt natürlich die eher generelle Maßgabe von Radfahrern für Radfahrer, die Radwege aus Gefährdungsgründen eher zu meiden. Wer sich für diesen Weg entscheidet, wird nie Probleme haben, vom Radweg auf die Fahrbahn zu wechseln, weil er keinen Radweg nutzt. Der router muss dich mindestens 250m vor der kreuzung auf die straße schicken, damit du dich sicher zum linksabbiegen einordnen kannst. Sowas kann man einem Radrouter ja einprogrammieren. Bei Autoroutern klappt das ja auch, sogar noch deutlich frühzeitiger: Auf Autobahnen üblicherweise sogar schon drei Kilometer im Voraus. Woher die Router bloß so weit vorausgucken können? ... Wenn das nicht geht, weil diese angaben in der datenbank fehlen und du schon deutlich früher auf die fahrbahn wechselst, riskierst du diskussion mit der polizei. Die müsste ja aber erstmal da sein. Es kann auch sein, dass du schon früher, zwischen den kreuzungen, auf die linke seite willst; dafür brauchst du entsprechend frühere bordstein-absenkungen. Diese ganzen details müssen also eingetragen werden. Als Radfahrer hat mal zweifelsfrei eine deutlich variantenreichere Wegfindungsmöglichkeit, als der Autofahrer. Ich hielte es allerdings für übertrieben, diesen Detailreichtum ungefiltert nach OSM zu übertragen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bus-Relationen: Hin- und Rückstreck e
Andreas Pothe schrieb: Ich packe momentan die komplette Strecke samt Haltestellen in einer Relation. Von den stop_X halte ich gar nichts, da viel zu mühsam in der Pflege - zumindest hierzulande gibt es bei *jedem* Fahrplanwechsel nämlich irgendwelche Linienänderungen, was eine komplette Neunumerierung zur Folge hätte. Meine Hoffnung ist ja, dass es bald geordnete Relationen geben wird, die dann derartige Krücken wie dieses stop_X überflüssig machen. Wenn ich mich aber recht erinnere, hat Frederik genau das für die API 0.6 angekündigt. Fredi, kannst du dich dazu äußern? Mal ganz dumm gefragt: Wenn in einer Relation sowohl die Wegstrecke als auch dabei angefahrene Haltestellen vereint sind, warum kriegt es dann ein Computerprogramm nicht hin, sowohl die einzelnen Wegstreckenschnipsel anhand ihrer Geo-Koordinaten zu sortieren und geordnet hintereinander zu hängen, als auch die Haltestellen dann anhand der gefundenen Wegstrecke zu sortieren? Ein Bus wird niemals eine Haltestelle überspringen, und dann diese Haltestelle im Rückwärtsgang doch noch anfahren... :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation für Lange Ways
Frederik Ramm schrieb: Durch Karlsruhe verläuft die A5. Sie besteht aus vielen einzelnen Ways. Die sind derzeit alle noch mit highway=motorway, ref=A5 getaggt. Zugleich befinden sie sich in einer Relation für die A5. Die Vererbung von Tags (alles bis auf type wird abwärts vererbt, Way schlägt Relation) ist derzeit, wie Du vermutlich weisst, noch nicht flächendeckend implementiert, das heisst, man kann das highway=motorway, ref=A5 an den einzelnen Ways noch nicht entfernen, aber eines Tages wird man das können und einfach nur die Relation entsprechend taggen. Das einzelne Wegstück wird dann unter Umständen *gar keine* Tags mehr haben (genauso wie Nodes oft *gar keine* Tags haben, weil sie eben nur als Bausteine für einen Way gebraucht werden). Ich weiß nicht, ob dieses Streben nach totaler DB-Normalisierung und Abwesenheit von Redundanz in OSM überhaupt sinnvoll ist. Ich habe bei etlichen beschriebenen Anwendungen von Relationen so meine Verständnisprobleme, welchen Zweck sie eigentlich erfüllen sollen, bzw. welchen Sinn es machen soll, in die entsprechende Generierung manuelle Arbeit hineinzustecken, anstatt es maschinell zu erledigen. Das Beispiel der Autobahn ist so ein Mittelding: Ich halte es für extrem sinnvoll, wenn jedes einzelne Teilstück sein zugehöriges ref-Tag trägt. Ich kann auch nur halbwegs nachvollziehen, warum man den gesamten Straßenzug nochmal zusätzlich in eine Relation stecken will. Was wird dadurch gewonnen? Genausogut kann man doch die API nach Wegelementen mit ref=A 5 befragen und erhält im Prinzip dasselbe. Zugegeben, eine weltweite Abfrage liefert vermutlich mehr als nur die Autobahn in Karlsruhe, und in der Relation könnten sich auch noch weitere verbundene Informationen befinden. Da ist nur die Frage: Welchen Sinn hat die Zuordnung solcher Informationen heute für welche Anwendung? Ein in meinen Augen nun wirklich absurder Vorschlag ist, alle Einzelteile einer durchgehenden Straße in eine Relation zu packen, um dann nur der Relation den durchgehenden Straßennamen zu geben, damit das Rendering z.B. auf Brücken nicht ständig den Namen wiederholt. Da sage ich mir: Wenn ein Renderer wirklich will, dass gleiche Straßennamen schöner verteilt werden, dann wird er so programmiert werden, dass er die Namensidentität der Einzelteile erkennt und selbst zusammenfaßt. Für sowas braucht es keine Relation. Andererseits: Relationen können natürlich auch wertvolle Zusatzinformationen zu einer Gruppe von Wegstücken hinzufügen, beispielsweise die Nutzung durch eine Buslinie. Diese Art von Extra-Info könnte man natürlich auch in Tags packen, das ist aber weitaus weniger schön, weil es sich doch eher um eine Art Meta-Information handelt. Stichwort Redundanz: Ich glaube, dass es in OSM Redundanz geben muß, weil dadurch die Informationen leichter in einem konsistenzen Zustand gehalten werden können. Wenn ich die Gültigkeit einer Information lediglich anhand einer einzigen Quelle bewerten muß, dann kann ich die Info glauben, oder nicht. Geben mir zwei oder mehr Quellen gleichartige Informationen, dann hebt das die Vertrauensbasis schon erheblich. Außerdem wird es immer wieder vorkommen, dass gleichartige Dinge unterschiedlich getaggt werden - Redundanzen helfen dann dabei, zu ermitteln, was tatsächlich gemeint ist. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen einer Winterrodelbahn
Manuel Rösler schrieb: Also mittlerweile hab ich diese Seite in der englischen Wiki gefunden: http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps#Pistes Allerdings muss man doch hier den landuse=piste Tag vergeben, der aber nur auf Flächen angewandt werden kann. Die genannte Rodelbahn würde ich aber gerne als Weg eintragen, da sie die Ausmaße einer Straße besitzt. Kann ich dann den piste:type=sleigh Tag auch ohne landuse verwenden? Oder was muss ich hier anders machen? Wenn es noch keine Vorbilder irgendwo auf der Welt gibt, die bereits getaggt sind, mußt du dir halt selbst was ausdenken und so taggen, dass die Nachwelt nicht nur irgendein Tag vorfindet, sondern auch deuten kann, was du da wohl gemeint haben könntest. Sprich: Werde ausführlicher im note-Tag, welches du ebenfalls hinzufügst, und nutze ggf. auch ein nettes name-Tag. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Karte
Melchior Moos schrieb: Superkarte! Gratulation! Kritik und Anregungen sind natürlich immer willkommen! Eher eine Frage. Mir ist aufgefallen, das in Hamburg die U1 erst in höheren Zoomstufen sichtbar ist, als die U2. Weiss jemand warum? Ja, das kommt daher, dass die U1 noch nicht lange eingetragen ist und erst beim aktuellen Update (an dem der Server gerade arbeitet) auf der Karte erscheint. Da jedoch die Zoomstufen = 14 dynamisch erzeugt werden ist Sie da bereits zu sehen. Genau genommen fehlt die Linie in Zoom 12 und 13. Ja. :) Die U2 war mein erstes Testobjekt, mittlerweile gibts auch die U1 und U3 sowie die A2 eingezeichnet (A1 und A3 bastel' ich gerade rein, nachdem ich lange auf's Update gewartet habe) - und eine Wikiseite: http://wiki.openstreetmap.org/wiki/Hamburg/Transportation Anregung von meiner Seite: In Hamburg sind auch Fähren im Nahverkehr aktiv - und ich schätze mal, das das nicht die einzige Stadt ist, in der auch Wasserstraßen zum ÖPNV genutzt werden. Insofern schlage ich vor, auch ferry als Relation in die Legende einzufügen und zu zeichnen. Hab da allerdings noch keine Eintragung in OSM gemacht, man würde also erstmal nichts sehen, weil es nichts gibt. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anzeige von Multipolygonen
Martin Koppenhoefer schrieb: zum Rendering von Multipolygonen habe ich auch ein Beispiel, dass ich in Osmarender nicht gerendert bekomme, in Mapnik allerdings schon: http://openstreetmap.org/?lat=40.75122lon=14.49542zoom=17layers=B000FTF weiss hier jemand Rat? Mapnik und Osmarender haben noch ein Problem mit verschachtelten Multipolygonen. Bei deinem Beispiel hast du Glück, dass Mapnik korrekt falsch liegt. Ich habe ein ähnliches Beispiel (See im Wald mit Waldinsel), bei dem Mapnik falsch und Osmarender korrekt arbeitet. Die Cyclemap (ein anderer Mapnik) kriegt übrigens beide Beispiele nicht korrekt hin. Ach ja, weil es auf dieser Mailingliste immer wieder vergessen wird: Wenn ihr nur einen Link angebt und die Aussage Da ist Renderer X falsch, dann wäre es als wichtige Zusatzinfo notwendig, auch zu sagen, was ihr denn als Erwartungswert für richtig habt, bzw. was genau denn falsch sein soll. Denn genau betrachtet ist deine Aussage falsch: Du kriegst dein Beispiel ja sowohl in Mapnik als auch Osmarender als auch Cyclemap gerendert. Aber was gefällt dir an den einzelnen Ergebnissen nicht? Das sollte erwähnt werden, ansonsten ist es nämlich ein Ratespielchen, bei dem man raten muss, was du mit deinem Tagging wohl gemeint haben könntest, und ob nun das Tagging korrekt (also passend zu deiner Intention) ist und das Rendering falsch, oder ob das Rendering zum Tagging passt, aber dieses falsch ist und nicht zu deiner Intention passt. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Bug beim Speichern als OSM Datei
Detlef Reichl schrieb: Am Freitag, den 09.01.2009, 14:42 +0100 schrieb Jacques Nietsch: Seit einigen Versionen schreibt Josm falschen XML Code. In Zeile 3 landet immer ein nicht abgeschlossnes Tag origin='OpenStreetMap server' / Josm selbst stört sich beim Einlesen nicht daran, aber andere Programme z.B. Kosmos steigen aus. Jacques Hallo, außerdem wird die Boundingbox falsch angegeben. Ich hatte mir die Grenze von BaWü gespeichert und in der Datei fand ich dann bounds minlat='47.5792334179688' minlon='9.5947668359375' maxlat='47.5847265820312' maxlon='9.6057531640625' origin='OpenStreetMap server' / das ist definitiv viel zu klein. Grüßle, detlef Schreibt Fehlermeldungen doch bitte in den Bugtracker rein. Nur dort werden sie von allen JOSM-Entwicklern gelesen und beachtet - hier auf der Talk-Mailingliste gehen sie wahrscheinlich unter. Die Anmeldung im Trac nutzt die gleichen Zugangsdaten, wie OSM allgemein. Wer seine Mailadresse nicht im Trac sehen will, nutzt seinen Usernamen zur Anmeldung. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 2. RFC für Internet Cafes
Stefan Hirschmann schrieb: Wichtigste Sachen zusammen gefasst: * Zusätzlich zum Tag wird auch der Namespace internet:access= erlaubt. Das halte ich für großen Blödsinn und extrem überflüssig. Meine Argumente dagegen: 1. OSM kennt keine Namespaces. Alle Keywerte müssen OSM-global unique sein, die Datenbank und die API interessieren sich absolut nicht für den Doppelpunkt innen drin, und selbst wenn der Doppelpunkt in XML als Zeichen für Namespace-Trennung verwendet wird, so gilt dies nicht für die aus OSM exportierbaren XML-Dateien, weil der Key dort ein Attributwert ist, kein Tag-Name. 2. Es ist ebenso unsinnig, für einunddasselbe ZWEI Keys zu erfinden. Das bürdet den Mappern auf, sich für eines von beiden zu entscheiden (welches nimmt man schlauerweise?), und den Renderern das Verarbeiten von zwei Regeln zum Malen der optischen Erscheinung beider Varianten. Und da ich im Moment auch nicht erkennen kann, dass sich für den ersten Wortbestandteil internet so wahnsinnig viele weitere Nutzungen aufdrängen, sehe ich nicht ein, warum internet:access ein sinnvoller Key sein sollte. Sollte es Dinge wie internet:backbone, internet:CIX oder internet:satlink irgendwann wirklich geben, würde es diese Dinge auch als data_wire, internet:infrastructure=CIX, operator... oder building=satellite_uplink geben können - je nachdem, was zu dem Zeitpunkt dann der jeweilige Stand der Diskussion und Tag-Entwicklung ist. Wenn das Namespace-Argument schon irgendwie ziehen soll, dann wäre das allerhöchstens für die sich eventuell andeutenden Extrainformationen zu internet_access, also z.B. internet_access:price oder internet_access:speed. Da will man nämlich keine doppelten Doppelpunkte haben. * Es werden versch. Arten des Internets unterschieden. Ich frage mich, warum es internet_access=service gibt. Warum nicht internet_access=public. Ich würde allerdings vorschlagen, einfach mal Bilder von Beispielen zu sammeln. Je mehr Beispiele es gibt, desto klarer wird das Bild, wie unterschiedlich auf der Welt Internetzugänge aussehen können, und dann kann man anhand der Bilder auch gleich Beispieltagging demonstrieren, sollte das Proposal einmal akzeptiert werden. * Internet_access berücksicht keine Kosten, aber durch Namespace internet: möglich, allgemeine Tags für Internet zu spezifizieren. Ja, ich bin sehr dafür, keine Preise zu taggen, allenfalls die Information, ob ein Angebot kostenlos ist oder nicht. * Wichtig: Internet_access ist ein Zusatzattribut. D.h. ein Internet Cafe wird als amenity=cafe internet_access=terminal getaggt. Es gibt in OSM keine Zusatzattribute, nur Attribute, also Hauptattribute. Das Proposal muss also damit klarkommen, dass es auch alleinstehend funktioniert. Deshalb sollte besser schon jetzt daran gegangen werden, die Argumentation so auszurichten, dass dieses Tag sich ausschließlich darauf konzentriert, das Vorhandensein des Internetzugangs zu dokumentieren, unabhängig von möglichen weiteren Eigenschaften des Ortes, die sich in anderen Tags widerspiegeln. So wie man nicht highway=private_residential taggt, sondern highway=residential, access=private, um sich das Erfinden von hundert Kombinationsstraßentypen zu sparen, so zielt dieses Tag eben auf den Internetzugang ab. Egal ob es nun amenity, shop oder gar nichts Zusätzliches an dem Ort gibt. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
Melchior Moos schrieb: 2008/12/22 Johann H. Addicks addi...@gmx.net Im Irc erreichte mich die Frage, von wem das ÖPNV-Layer ist, was unter http://81.89.97.206/oepv.html abrufbar ist. Meine Wenigkeit... Schöne Sache. Verbesserungsvorschlag: Setze auf die Seite noch einen Link zu einer Wikiseite, in der beschrieben wird, wie die Relationen zu taggen sind, die du da farblich hervorhebst. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
Florian Lohoff schrieb: On Thu, Dec 25, 2008 at 12:12:14PM +0100, Sven Rautenberg wrote: Melchior Moos schrieb: 2008/12/22 Johann H. Addicks addi...@gmx.net Im Irc erreichte mich die Frage, von wem das ÖPNV-Layer ist, was unter http://81.89.97.206/oepv.html abrufbar ist. Meine Wenigkeit... Schöne Sache. Verbesserungsvorschlag: Setze auf die Seite noch einen Link zu einer Wikiseite, in der beschrieben wird, wie die Relationen zu taggen sind, die du da farblich hervorhebst. Das Datum des letzten updates waere auch super - Ich habe versucht eine BUS route relation zu bauen und die wird nicht gerendert - Im moment rate ich ob ich zu bloede bin oder das einfach nur daran liegt das seit ein paar tagen das nicht geupdated wurde ... Ja, das wäre absolut super. So in der Art Basis des derzeitigen Renderns sind die OSM-Daten vom $Datum $Uhrzeit. Es ist ja auch nicht schlimm, wenn die Karte nur alle paar Tage oder Wochen neu gerendert wird, aber man kann sich besser drauf einstellen, wenn man die Info hat. Dass es mit dieser Info dann Leute geben wird, die sich drüber beschweren, dass das nicht schneller geht, dürfte mit Sicherheit passieren, aber einem geschenkten Gaul... Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Indiscrimate layering
Elena of Valhalla schrieb: On Sat, Dec 20, 2008 at 1:17 AM, Sven Rautenberg s...@rtbg.de wrote: Please reconsider. I hate it when I see rivers, streams etc. illogically marked as layer=-1. There is no reason to do so, because a river usually is at the top of the surface, and that is no layer or layer=0. not so true everywhere: in mountain areas rivers are usually at the bottom of valleys, The bottom of a valley is layer=0. and I've seen many small rivers covered and practically brought underground in urban areas. These streams should be tagged tunnel=yes, layer=-1. as a guideline, i usually mark the road +1 if it rises to become a bridge, but 0 and the river -1 if the river is lower than the ground where most of the road is If you come across an existing stream which has no layer tag, do you add layer=-1 to the whole stream and then check the whole stream if your change may conflict e.g. with a tunnel which is already at layer=-1? I don't think so. Tagging a part of a way with a non-default layer does not mean anything about it's elevation. It is all relative, but it is a good idea to assume natural surface level to be layer=0 in most cases. The stream therefore is the natural surface wherever its water flows. The bridge is above the water, so it is layer=1. And it is less dangerous when just tagging the bridge compared to tagging the whole stream. Regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Indiscrimate layering
David Earl schrieb: An anonymous user has being changing all bridges without layer tags to layer=1 in my area. I suspect this is a bot. Because the continuity is better without changing layer along a road, for streams I often set the stream to layer=-1, and leave the layer alone and that is the case in many of these changes. Please reconsider. I hate it when I see rivers, streams etc. illogically marked as layer=-1. There is no reason to do so, because a river usually is at the top of the surface, and that is no layer or layer=0. Wherever a street crosses a stream, the street has to be split into the normal part and the bridge part. As the layer tag is to help renderers get the vertical ordering right, it is far less intrusive to add layer=1 to the bridge, instead of adding layer=-1 to the stream, because this layer usually applies to the whole way of the stream, most likely affecting many other crossings of this stream. Because the layer tag is only a relativ positioning, it's effects should be kept as local as possible. That means to avoid tagging things with it which are very long or very big. It looks like the change has been made blindly with no real reference to what the bridge is doing. If the stream is layer=-1 and the bridge was layer=0 and is now layer=1, I cannot see any problem here because nothing is broken. Humph. I'm going to change a lot of them back, but if this procedure is run repeatedly this will be an edit war where I'm competing with an anonymous robot. Don't change it back, change it forward. Remove layer=-1 from the stream. Regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Ortsgebiet
Wolfgang Wienke schrieb: Hallo! Bernd Raichle schrieb: Besser ist IMHO ein eingetragenes Ortsschild als _kein_ eingetragenes Ortsschild. Wenn einem die Tags nicht passen, kann die spaeter jemand anderes immer noch entsprechend korrigieren bzw. so umsetzen, dass ein Router/Renderer/... was damit anfangen kann. Und jetzt nenn mir dochmal einen vollstaendigen und eindeutigen Algorithmus der solchen Quatsch verarbeiten soll? Wenn ich mal davon ausgehe, dass der Renderer weiß, dass die Straße in Deutschland (Rechtsverkehr) ist, und weiterhin das Schild an der RICHTIGEN (rechts in Fahrtrichtung) Seite neben der Straße steht, so kann er erkennen, ob es Ortseingang oder -ausgang ist. Die Nodes mit Ortsschildern, die mir bislang begegnet sind, waren immer Bestandteil der Straße, für die sie galten, und daher nicht links oder rechts der Straße. Zumal es kein unwahrscheinliches Szenario ist, dass am Ortsein-/-ausgang auf beiden Straßenseiten Schilder stehen, und ein Tagging des Schildstandortes links oder rechts der Straße in so einem Fall dazu führen wird, dass vollkommen zu Recht dort zwei Nodes eingezeichnet werden - nach demselben Schema, mit dem beispielsweise auch Bushaltestellen sowohl auf als auch links oder rechts neben der Straße eingezeichnet werden. Dein Ansatz wird also scheitern, weil du für Ortsschilder eine vom allgemeinen Standard abweichende Behandlung erstellst, die du niemals global oder wenigstens deutschlandweit allen Mappern vermittelt kriegst. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] genauer Online-Transformator für Marku s OSM
Tobias Wendorff schrieb: Achja: BITTE Realname posten ... Netiquette. Die Forderung nach Realname-Postings ist gerade in Zeiten steigender staatlicher Vollüberwachung, aber auch im Interesse eines klein gehaltenen Google-Suchprofils absurd. Aber selbstverständlich kann den Realname-Fanatikern durch Wahl eines plausibel klingenden Kunstnamens Genüge getan werden. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie markiere ich ein Internet-Cafe?
Ossi schrieb: Hmmm, hab mich auch schon gefragt, was man damit anfangen soll. In Düsseldorf (zumindest ist es mir da aufgefallen) hat jemand die WLAN Spots von Fon (http://www.fon.com) eingetragen und zwar so: amenity:wlan class:free source:maps.fon.com Diese Einträge sind hinsichtlich der Legalität aus Lizenzsicht unter zweifelhaften Umständen zustande gekommen und sollten insbesondere deswegen, weil die Datenqualität (sprich: Korrektheit des Orts) dieses Imports überwiegend schlecht ist, eher wieder entfernt werden. Dummerweise hat sich seinerzeit der Importeur nur drum gekümmert, die Daten in OSM reinzukippen, aber nach entsprechend negativen Reaktionen auf dieser Mailingliste hat sich niemand drum gekümmert, diese schlechten Daten wieder rauszuwerfen. Ich hab erstmal die Finger davon gelassen, allerdings finde ich den Eintrag Free so nicht korrekt, da der Zugang nur dann frei ust, wenn man auch bei Fon mitmacht. Andernfall smuß man dafür zahlen. Wäre gut, wenn man das gleich mit abfrühstücken könnte. Insbesondere war es keine gute Idee, das Tag class zu verwenden, denn das hat in OSM offenbar schon eine Vergangenheit als Straßentyp und soll komplett entfernt werden. Wird folgerichtig von Maplint und anderen angemeckert. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [JOSM] Segmentweises taggen / Autorelation?
RalfGesellensetter schrieb: Hallo, es wurde vor kurzem darauf hingewiesen, dass in vielen Bereichen für sinnvolles Routing noch Tempolimits nachzutragen sind. Beispiel: Eine Landstraße zieht sich geradlinig über 30 km hin und durchläuft dabei mehrere Ortschaften (Tempo 50). Außerdem gibt es an Kreuzungen und Bushaltestellen einige Bereiche mit Tempo 70. Augenblicklich sehe ich in solchen Fällen nur die Möglichkeit, die Straße an den entsprechenden Stellen zu splitten (was sich immer dann als schwierig erweist, wenn Nebenstraßen einmünden). Ich persönlich sähe es eher als ungünstig an, eine Landstraße tatsächlich mit 30 km am Stück in der Datenbank zu haben. Auch wenn wir ja nicht für die Renderer taggen, so würde ich es dennoch als ungünstig ansehen, wenn auf dem Gesamtstück von 30 km nur an einer einzigen Position der Strassenname gerendert wird. Ich hab' kein Problem damit, die Strasse in Einzelteile zu zerlegen, wenn das Tagging es erforderlich macht. Ich bin auch noch nirgendwo auf eine verständliche Argumentation gestoßen, wo der Vorteil liegen soll, anstelle dessen Relationen zu verwenden. Denn egal wie man es macht, es ist unumgänglich, irgendwie zwei oder mehr Wegstücke mit unterschiedlichen Werten zu haben, und dafür eine Datenstruktur zu finden. Wie diese Datenstruktur dann elektronisch weiter ausgewertet wird, ist in meinen Augen eine ganz andere Sache. Wieso muss ich als Mensch manuell Relationen anlegen, um aneinandergrenzende Straßenstücke gleichen Namens in eine Relation zu packen? Wenn eine Software das gerne so hätte, kann sie doch direkt selbst auswerten, dass der Straßenzug aus mehreren Stücken besteht, und bei einzelnen Stücken gewisse Tags identisch sind, somit also als übergreifend gewertet werden können. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Rendering barangays for the Philippines
David Earl wrote: Here's an example of how I'm seeing it working: User T is Thai so sets JOSM to work in Thai (I'm not considering UIs here, just the data). JOSM tells the API that's what the language is when it uploads or downloads. So T's download automatically sees what I know as a village as thai-for-village. N, the Norwegian visitor to Bangkok entered that village the previous day in norwegian-for-village having told Potlatch she was working in Norwegian. T decides it is really a town, so changes it to town-in-thai and uploads it. N downloads it the following day and sees town-in-norwegian. Mapnik also sees it and renders town-as-a-symbol. You are ignoring the fact that human languages rarely produce interchangeable words which really mean the same. Each language is heavily influenced by it's peoples history. Just let's pick up your village-example. In German we name it Dorf. If you ask how to translate Dorf to English, you'll get village and cottage. cottage translates back either to Dorf (multiple houses), but also as Häuschen, Hütte, Landhaus (forms of a single house). Just think of someone inventing a Tag cottage, which should be translated? Which meaning does apply? The best example for such an untranslatable word is trunk as in highway=trunk. What is this? In the UK, it is a declaration that a street is part of the main road system, but it does in no way indicate any kind of traffic rules, number of lanes to expect etc. In fact, any trunk road could end up being anything from motorway down to unclassified if it hadn't been labelled trunk by the authorities. This trunk produces all kinds of strange conflicts because of its unclear meaning, which leads to having every country define which kind of road should be tagged as trunk. In Germany we chose to tag roads which are similar to Autobahn (dual carriageway or four lanes), but lack the blue road sign. But this is simply not what you'd expect in Great Britain. By simply translating the word trunk, you'll end up in a mess if you have Germans running around in the UK, retagging every trunk road as primary road because it is no Kraftfahrstrasse (or whatever the translation would be). Regards, Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] touchandtravel - Fahrkarte per Handy buchen
Tobias Hägele schrieb: Am Dienstag, den 25.11.2008, 16:12 +0100 schrieb Jan Tappenbeck: Moin ! bei uns habe ich gerade neue Gerätschaften am Bahnhof um per NFC-Technik Fahrkarten mit dem Handy zu buchen. http://www.touchandtravel.com/site/touchandtravel/de/start.html Hat einer schon überlegt die Standort zu mappen und wie diese zu taggen wären ?? Kann mir nicht vorstellen, dass das nützlich ist. Bei den Bahnhöfen hier hängen ziemlich viele von den Dingern rum, also man hat immer eines in Sichtweite. Es wär evtl während der Testphase interessant die Bahnhöfe selbst mit sowas wie NFC YES/NO zu markieren. nfc=yes/no ist vermutlich das schlechteste Tagging dafür. Erstens: Niemand kennt die Abkürzung NFC. Zweitens: Selbst wenn er sie kennt, ist NFC nicht nur zum drahtlosen Fahrkartenkaufen da, sondern eine allgemein nutzbare Technologie. Drittens: yes/no-Werte für ein Tag sind in der Regel verschwendete Information, sprich: No wird selbsterklärend dort angenommen, wo das Tag nicht vorhanden ist, und anstelle von yes könnte man viel besser weiterführende Informationen eintragen, weil sich mit Sicherheit herausstellen wird, dass da noch mehr eintragbar wäre. Wenn du also das Vorhandensein von Touchandtravel-Terminals taggen willst, dann benenne das Tag auch entsprechend. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern mit Buchstaben
Marcus Wolschon schrieb: Am 14. November 2008 15:14 schrieb Sven Anders [EMAIL PROTECTED]: Was mit Interpolation halt nicht geht ist 1...9a ..17 (weil nicht klar ist ob es 1...9 9a 11 ...17 ist oder 1..7 9a 9 ...17), aber eine Interpolation von 9a bis 9f ist doch kein Problem. Zur Diskussion über kyrillische Buschstaben bei Hausnummern: Mag sein das die dann ein anderes Tool zur Berechnung von Interpolierten Hausnummern brauchen. Aber das sollen dann die Programmierer aus dieser Region regeln, wir müssen nicht die ganze Welt retten. Diese Aussage finde ich realitätsfremd. Das Tool um das es mir geht ist mein eigenes Navi (Traveling Salesman). Die erste Anwendung, die die Hausnummern auswertet. Wenn du also von Berlin zu einem Reihenhaus in Moskau fahren willst, dann schlägst du vor 2 verschiedene Navis zu nutzen? ;) Nein, der Vorschlag war, dass sich nicht Deutsche hinsetzen und die Hausnummernregeln der Welt in ein Taggingschema gießen, weil sie dazu in der Regel nicht das lokale Fachwissen haben, sondern dies Programmierern und Mappern aus der jeweiligen Region überlassen. Abgesehen davon: Man muss nicht erst nach Moskau fahren, um auf Hausnummern zu stoßen, die von der normalen Buchstabenregel (a...z) abweichen. Frankreich hat beispielsweise bis anstelle von b in der Nummer, und wer weiß, was noch alles nachfolgt. Es ist auf der talk-Liste auch schon mehrfach deutlich geworden, dass das Karlsruhe-Schema sich für diverse andere Länder absolut nicht eignet. Es wird daher zwangsläufig drauf hinauslaufen, dass es mehrere Arten des Hausnummerntaggings geben wird, und dass interessierte Applikationen jedes Schema beherrschen müssen, wenn sie diese Länder abdecken wollen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Druchfahrtshöhe Brücke
Wolfgang W. Wasserburger schrieb: Habt beim Taggen doch Mitleid mit denen, die das Rendern bzw. damit Routen sollen. Sehe ich genauso. Eine Brücke über eine Straße hat in der Regel nur dann eine leicht und eindeutig ablesbare maximale Durchfahrtshöhe, wenn ein entsprechendes Straßenschild aufgestellt ist. Dieses Schild (Zeichen 265, z.B. http://wiki.openstreetmap.org/index.php/Image:120px-Zeichen_265.svg.png) als Streckenverbot bis zum gegenüberliegenden Zeichen aufzufassen halte ich für absolut gerechtfertigt. Ein künstlich irgendwohin gesetzter Punkt wäre sachlich inkorrekt, wenn er nicht am Schildstandort liegen würde. Abgesehen davon ist auch zu bedenken, dass die eingegebenen Daten mit den bestehenden Editoren noch vernünftig bearbeitbar bleiben sollten. Ich persönlich habe mit aufgetrennten Wegen jedenfalls kein Problem. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] autobug update
Florian Lohoff schrieb: Hi, autobug zeigt seit gestern abend auch nodes an deren note ein FIXME enthaelt. Explizit ausgenommen sind die FON wlans die einfach nur die Landschaft verschandeln Ja, ein Paradebeispiel dafür, wie man Massenimporte nicht gestalten sollte: Erstmal wird der Datenbestand in OSM reingetan, dann festgestellt, dass die Information mehr oder weniger ungenau ist, obendrein ist höchst zweifelhaft, ob die Daten überhaupt hätten verwendet werden dürfen - nur um das Entfernen kümmert sich dann niemand mehr, insbesondere nicht der initiale Importeur. Gibts eine Chance, dass diese FON-Wlans automatisiert entfernt werden? Wenn nein, würde ich vorschlagen, dass du die eben gerade nicht rausfilterst, damit man zumindest manuell eine Chance hat, die flächendeckend wieder loszuwerden. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bulk changes
Markus schrieb: Ignorieren von Leistung führt immer zu Frustration. Und Frustration hemmt Kreativität, Motivation und Produktivität. Darin besteht auch die Problematik von nicht kommunizierten Bot-Änderungen. Kommunikation ist aber grundsätzlich ein Problem. Wo beispielsweise würdest du beabsichtigte Bot-Änderungen kommunizieren wollen: - eine OSM-Wikiseite - ein OSM-Webforum - eine OSM-Mailingliste - ein eigener Bot-Änderungs-Nachrichtenkanal - oder in allen diesen Medien Bedenke bei der Antwort aber, wieviele Wikiseiten, Webforen, Mailinglisten etc. es gibt... :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Geschäfte] Übersicht
Raphael Studer schrieb: Hi, erscheint in der deutschsprachigen Kartenversion Bürobedarf und in der französischen Kartenversion Wo findet sich diese ominöse deutssprchige Kartenversion? Überall dort, wo Deutschland als Karte dargestellt wird. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Lake rendering
Gustav Foseid schrieb: Could someone take a look at lake Østensjøvannet near Oslo, and tell me how to fix the mulitpolygons, so both Osmarender, Mapnik and the Cycle Map understand them? http://www.openstreetmap.org/?lat=59.8815lon=10.8767zoom=14layers=0B00FTF http://www.openstreetmap.org/?lat=59.8816lon=10.8768zoom=14layers=B000FTF http://www.openstreetmap.org/?lat=59.8816lon=10.8768zoom=14layers=B000FTF I have made a couple of attempts, but without much luck. I think you cannot complete this task until Mapnik gets some software fixes. One general rule for tagging holes within an area is to use a multipolygon relation and to put all tags on the outer border way marked as outer in the relation, leaving the inner way untagged. This works great in all renderers. Example: Lake with island, or wood with a clearance. What if the inner way marks something other than nothing? Simply tag it as such. This works great, too. Example: Lake with wood island. What if this inner way has holes by itself? Example: Wood with lake inside, which has an island with wood. You can tag the wood as outer, tagging the way of the lake as inner, which renders fine. The lake too is a outer, with the island as an inner way. Only Osmarender can render this correctly so far. Mapnik fails (and Cyclemap's Mapnik fails different than the general Mapnik). I'd suggest tagging your lake correctly and try to get Mapnik fixed, instead of trying to find a workaround tagging that works in Mapnik and Osmarender. Viele Grüße Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] noexit - wie weit anwenden
Thomas Hog schrieb: Guenther Meyer schrieb: nur sind osm-daten schon prinzipbedingt zur zeit unvollstaendig, und da ist es durchaus sinnvoll, unterscheiden zu koennen, ob eine strasse, die ploetzlich aufhoert, wirklich so aussieht, oder ob es nur ein fall von ich hab nicht mehr in diese richtiung weitermappen koennen, aber da kommt schon noch was... ist. Gibts dafür denn eine allgemein genutzte Lösung? fixme=yes, incomplete=yes, note=bin nicht fertig, macht mal weiter? note=FIXME Individueller Erklärtext Scheint sich jedenfalls großflächig durchgesetzt zu haben, was individuelle Alternativlösungen jedoch nicht ausschließt. Wichtig dabei dürfte vor allem der Text FIXME sein - der kann automatisiert entdeckt und weiterverarbeitet werden. Wenn man sich da auf irgendwas einigt kann das ja mit autobug markiert werden. Oder sollte man seine eigenen unfertigen Sachen auf OSB ablegen? Ich denke, das hängt von der persönlichen Einschätzung ab. OSB hat den Vorteil, dass es (hoffentlich) viele Abonnenten von umgebungsabdeckenden RSS-Feeds gibt, die sich der dort eingetragenen Meldungen dann annehmen. Allerdings würde ich aus meiner persönlichen Sicht (die von der 99,8% Straßenabdeckung in Hamburg geprägt ist) in OSB nicht unbedingt Fehler vom Maßstab Hier fehlt noch eine ganze Kleinstadt, bitte mal mappen eintragen. Es gibt kein einziges, alleiniges Standardverfahren - und das ist durchaus auch gut so. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäudedurch-gänge / fahrten
RalfGesellensetter schrieb: Am Sonntag 02 November 2008 schrieb Martin Koppenhoefer: ich nehme auch Tunnel Tunnel sind für mich unterirdisch. Bei Eisenbahnunterführungen verwendet man unterschiedliche Level. Geht das nicht auch mit Gebäuden? Es gibt im Straßenbau ja irgendeine Definition, wann ein Bauwerk eine Brücke und wann ein Tunnel ist. Das geht aber nur, wenn das den unteren Weg kreuzende Bauwerk sich als Brücke taggen lässt. Bei Häusern hätte ich da so meine Zweifel. Insofern bleibt eigentlich nur noch Tunnel, da das wichtigste Kennzeichen eines Tunnels ist, dass er rundherum um den Weg eine einhüllende, feste Umbauung hat, die sowohl die Durchfahrthöhe beschränkt, als auch den freien Blick und die Durchlässigkeit von z.B. Tageslicht behindert. Halt alles das, was man mit einer Tunnelwand oder einer Tunneldecke so verbindet. Dabei dürfte es eher irrelevant sein, dass sich hinter dieser Wand eben gerade kein Erdreich befindet, sondern Hausinhalt. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strommast Kennzeichnung
Christian Schuhmann schrieb: Ich sag wie ich es mache: Mast: power=tower, ref=6 Leitung: power=line, name=1015, operator=PreussenElektra, layer=(zwischen 2 und 5), wires=single Du bist das also. Mir sind schon die diversen kreativen Einträge im Tagwatch aufgefallen. Du missbrauchst das layer-Tag, welches OSM-global dazu da ist, die Render-Sortierreihenfolge für übereinanderliegende Elemente wie Straßen zu definieren, für einen nicht öffentlich dokumentierten anderen Zweck. Nichts dagegen, dass du sowas wie eine Ebene taggst - dann nimm aber doch bitte nicht genau dieses Tag - denn damit verursachst du unter Umständen mehr Probleme, als du an Information hinzufügst. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Intergeo, oder: Betriebsgeheimnisse die eigentlich keine sind
Dirk-Lüder Kreie schrieb: Ein weiterer Kontakt mit einem Mitarbeiter eines großen deutschen Energieanbieters stellte sich auch als interessant heraus: Er hatte mal seine eigenen, Firmeninternen Top-Secret Daten über die Standorte von Strommasten mit denen von OSM verglichen, und war erschrocken und sehr erstaunt über das Ergebnis: überall wo Strommasten seiner Firma verzeichnet waren, stimmten die Positionen. Erst dachte er an ein Datenleck in der Firma, dann kam ihm die Theorie, dass irgend ein Verrückter diese Daten mit Hilfe von GPS und/oder Luftbildern gesammelt haben könnte und das die Geheimhaltung dieser Daten lediglich ein Spiel auf Zeit sein könnte. Nach einem kurzen Gespräch am OSM Stand war er von ~ dieser Zweiten Möglichkeit so überzeugt, dass er sich dafür einsetzen will, die Datensätze über Strommasten, Stromtrassen usw. OSM als Import bereitzustellen. Ob was daraus werden kann, wird die Zeit zeigen, aber als Argumentation gegenüber anderen möglichen Spendern evtl. erwähnenswert. Wir dürfen uns also darauf vorbereiten, dass man OSM demnächst auch Förderung von Terrorismus vorwerfen kann. Denn die detaillierten Karten des Energieversorgungsnetzes kann man ja ganz leicht[TM] auf Engstellen und Schwachpunkte durchsuchen, und so die Effizienz von Anschlägen erhöhen. Böse, böse!!! Auf die Idee, dass eine Terrorzelle sich auch einfach selbst die Mühe machen könnte, die Überlandleitungen zu erfassen, oder die Mühe sein lassen und einfach pauschal mehr sprengen könnte, als minimal notwendig, wird niemand kommen - das Szenario ist einfach zu unrealistisch. Und dass das veröffentlichte Leitungsnetz auch von den Guten zur Analyse und Behebung gerade solcher Anfälligkeiten genutzt werden kann... pah! Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] weitere maxspeed-Values brauchen wir!
Garry schrieb: Nein, eine technisch sinnvolle Sicht. Leiten wir mal her: 10km/h Schilder gibt es - die kann der Gesetzgeber also nicht gemeint haben sonst hätte er es entsprechend formuliert. Darüber kann er nicht gemeint haben weil man dann doch schon so langsam ausserhalb der möglichen Gehgeschwindigkeit auch für sehr sportliche Menschen kommt. Unter 7km/h können sehr viele Autos ohne die Kupplung schleifen zu lassen schon gar nicht fahren -erhöhter Verschleiss ist garantiert auch nicht das Ziel des Gesetzgebers ist, zumahl es ja auch Schrittgeschwindigkeit an Steigungen gibt. 9km/h würde nicht wirklich Sinn machen (1km/h unter verfügbaren 10km/h-Schilder), 8km/h ist nicht so viel besser - bleibt die 7km/h als vernüftigster Wert. Ob du es glaubst, oder nicht: Ich bin unlängst in Hamburg an einer Baustelle mit einspuriger, verengter Fahrbahn, die noch dazu über irgendeine improvisierte Behelfsbrückenkonstruktion führte (vermutlich, damit die Baugrube des Hauses daneben nicht zusammensank) über eine Geschwindigkeitsbegrenzung von 6 km/h gestolpert. Nein, hab' leider kein Foto als Beweis. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benutzung von highway: tertiary
Dominik Spies schrieb: Mal folgende Situation: http://www.informationfreeway.org/?lat=48.618857367209095lon=12.485006173898954zoom=16layers=0F0B0F http://maps.google.de/maps?f=qhl=degeocode=q=dingolfingie=UTF8ll=48.620201,12.481263spn=0.012525,0.026007t=hz=16iwloc=addr Es geht um die Brunner Straße und die Ringstraße. Würdet ihr die wirklich als tertiary taggen? Klar haben die irgendwo Erschließungscharakter als Zubringer ins Wohngebiet, aber tertiary halte ich irgendwie übertrieben.. Fahren da viele Autos? Fahren da Busse? Sind die Straßen in irgendeiner Weise sonst noch wichtig für Durchgangsverkehr? Sehen sie von ihrer Gestaltung her wichtig (d.h. breiter, gut ausgebaut etc.) aus? Würdest du mit Ortskenntnis als Verkehrsteilnehmer diese Straßen irgendwie höher einstufen, weil man lieber diese benutzen sollte, als irgendeine andere Straße, um sein Ziel zu erreichen? Aus meiner Sicht ist das alles hier nicht so wirklich gegeben, aber ich sehe ja auch nur die Karten und Sat-Bilder. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] metered parking
Matias D'Ambrosio schrieb: I would like to mark certain streets as having metered parking, but I found no reference to it in the wiki, maybe we could decide on something? At least according to the system used in my city (Bahia Blanca, Argentina), and I think the country, this tag would apply to ways. Also, it has a time restriction (in my city the same applies to all metered parking streets, they are metered 7-20 or 8-20, I can't recall exactly). metered_parking=boolean or maybe with two hours separated by a dash as in 7-20 (I have no idea if this is allowed)? Your wish touches several unresolved topics of OSM tagging. a) Not all parking space is created symmetrical. It is more likely that parking regulations depend on what side of the street you are. Unfortunately we have not decided on how to tag things connected to a way, which are on one side, and that matters. Among these things are cycleways, pavements, lanes per driving direction, etc. b) Tagging of time-dependant features. Your example is easy, but it simply is not enough to have a tag for time_start and time_end, as there might be the weekday influencing the times. c) Hierarchical tagging. If you tag what time the parking meter has to be used, those time tags are independent from every other tag. How can it be made clear that those tags are for the parking meter tag, not for the maxspeed tag? Does it make sense to invent parking_meter_start_time to distinguish it from maxspeed_start_time? If you can come up with a tagging scheme (need not be great, just sufficient for what you need to tag), just go ahead and do it. Expect to change your tagging some time later after there has built a consensus on the above questions. Your tagging until then might help finding a better solution. Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Garmin USB on Windows
Stefan Monnier schrieb: They use a Windows PC and, unfortunately, it's an employer's managed laptop so they can't install stuff on it - like the Garmin drivers. Why not boot a GNU/Linux live distribution (e.g. from a USB key)? Because the primary boot device is the hard drive and the BIOS is locked with a password? Sven ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] historic=yes
Michael Buchberger schrieb: Hallo Liste, was haltet Ihr von einem Tag historic=yes das man an Kirchen, Brücken, Gebäude u.v.m. machen kann, um klarzumachen das dies Historische Objekte sind. (z.B. zur Unterscheidung alte/neue Kirche) Mir gefällt schon mal die Kategorisierung historisch nicht. Was ist das? Einteilung nach Alter? Ab welchem Alter? Und wenn ja, warum taggt man nicht einfach das Baudatum, dann kann jeder sich seine persönliche Grenze selbst herausfiltern. Oder kommt es darauf an, dass noch Geschichte dran haftet? Welche Geschichte? Wo ist die Relevanzstufe? Damit umgehe ich in den Wildwuchs im historic-Tag (historic=place_of_worship|church, historic=bridge, historic=building) und die vorhandenen Objekte werden ja schon z.T. auf der Karte angezeigt (place_of_worship, bridge, building) Wildwuchs entsteht entweder dadurch, dass niemand regulierend eingreift und eine Vereinheitlichung anschiebt, oder weil das Tag einfach extrem schwammig ist. Mit dem zusätzlichen Wert yes änderst du daran absolut nichts. Im Gegenteil: Ein ja/nein-Tag ist in den allermeisten Fällen viel zu eindimensional und verschenkt dadurch die Möglichkeit, nicht nur durch das Tag-Label, sondern auch durch den zugewiesenen Wert Information zu transportieren. Was spricht gegen ein solches Tag? Zusätzlich könnte man dazu noch Datumsangaben machen: * historic_date:construction (Baujahr) * historic_date:battle (wann war die Schlacht) * historic_date:destruction (Zerstörung bei ruins=yes) OSM ist in der derzeitigen Form nicht für die aufwendige Verwaltung von historischen (d.h. zeitlich zurückliegenden) Informationen bereit. Es ist die Frage, ob dies jemals der Fall sein wird. Dein Vorschlag hinsichtlich des Taggings von Daten halte ich für ungünstig. Vor allem battle ist etwas, was man in OSM nicht einzeichnen und taggen kann. Man kann Schlachtfelder, die heute noch gekennzeichnet sind, in der Karte verzeichnen - das läuft dann entweder auf das Taggen eines Denkmals oder eines Museums heraus. Und in der Namensbenennung könnte dann auch eine Jahreszahl auftauchen. Aber das ist nichts, was derzeit ein separates Datumstagging verdient hätte. Dasselbe gilt für Daten baulicher Veränderungen. Gebäude werden geplant, gebaut, umgebaut, erweitert, zerstört, wiederaufgebaut, abgerissen, neugebaut... Überall, wo heutzutage in Städten Gebäude stehen, dürfte es aufgrund der langen Geschichte eine lange Liste von baulichen Veränderungen gegeben haben, die man nicht mit einem einzigen historic_date:construction erledigen kann. In dem Zusammenhang wäre auch ein allgemeines Baujahr interessant construction_date? Ich frage mich, welchen Wert diese Information hätte. Zum einen: Auch die noch bestehende Burg, erbaut vor dreihundert Jahren, hat eher ein construction_date, als separat davon ein historic_date:construction. Weil sonst nicht zu entscheiden ist, wann das eine und wann das andere zu verwenden wäre. Zweites Problem: Für die allermeisten Features, die man in OSM einträgt, ist so ein Datum nicht feststellbar, weil niemand es erinnert. Drittens: Ich sehe im Moment auch keine sinnvolle Anwendung für solch ein Datum. Der vielleicht damit verbundene Wunsch, sich auf Anforderung Karten von früher erstellen zu lassen, schlägt fehl. Man kann derzeit, um nur ein Beispiel zu nennen, einfach keine Straßen eintragen, die früher einmal existierten, aber jetzt verschwunden oder umgebaut sind. Solche Straßen würden auf allen aktuellen Renderern eingezeichnet werden. Schon allein daran scheitert also im Moment der historisch Ansatz. Zweites Beispiel ist die Aussage einiger hier teilnehmender Historiker, dass solch eine historische Landkarte nur sehr gering in die Vergangenheit reichen kann, weil gar nicht mehr Infos bekannt sind. Deshalb wiederhole ich meine Aussage: OpenStreetMap ist zum Erfassen zeitlicher Abläufe bzw. historischer Daten aktuell nicht geeignet. Ich halte es auch für fraglich, ob genug Interesse besteht, OSM dahingehend aufzubohren. Wer es tun will, hat eine Menge Programmierarbeit vor sich - es ist nicht damit erledigt, sich einfach ein paar passende Tags auszudenken. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellungsfehler auf www.openstreetmap.org
Alexander Schulze schrieb: Hi, das Problem ist, dass momentan standardmäßig Maplint aktiviert ist. Das war vorher nicht so. Vielleicht kann man das wieder ändern. Denn jedesmal den Maplint-Layer wieder zu deaktivieren ist auch ziemlich nervig. Von unbedarften Besuchern ganz zu schweigen. Nein, das ist nicht das Problem. Standardmäßig ist der Maplint-Layer deaktiviert. Das Problem ist, dass sich die Layeroptionen mit der Zeit geändert haben, und alte Bookmarks nicht mehr kompatibel sind, bzw. unerwartet den Maplint-Layer einschalten. Bookmarks ohne layers-Parameter machen das Problem nicht. Aktivieren allerdings auch immer Mapnik, und nicht irgendeine der Alternativen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verknüpfung mit Wikipedia oder anderen Datenbanken
Florian Schweikert schrieb: Ich verwende wikipedia=page_name, steht zumindest so in der wiki. Für anderes kann soll man angeblich website= verwenden, wenn ich es recht in Erinnerung habe. Das finde ich irgendwie unglücklich. Warum wird die Wikipedia als Webseite so herausgehoben im Vergleich zu allen anderen Webseiten? Auch ein Link auf eine Wikipedia-Seite ist zuallererst mal nur ein Link. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewässer im Bereich Itzehoe defekt
[EMAIL PROTECTED] schrieb: Ansonsten: Klasse, dass fast jeder Node in Itzehoe mit einer ele (Höhe)- Information versehen ist. :-) Diese ele-Infos kann man meiner Ansicht nach oft ziemlich in der Pfeife rauchen. Ich habe die Höheninfos der lokalen Autobahn jedenfalls alle gelöscht: Es entsprach einfach nicht den Fakten, dass die beiden Richtungsfahrbahnen mehr als 10 Meter Höhenunterschied aufwiesen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unclassified vs. Tracks
Heiko Jacobs schrieb: Die Strassen sind aspaltiert und sehen so aus wie in den DE:Mapfeatures bei highway=unclassified abgebildet. Sie werden in der Regel auch von KFZ genutzt. Der Unterschied unclassified contra track-grade1 steht bei asphaltierten Wegen eigentlich immer am Anfang des Weges: Verbotsschild 250 (roter Kringel mit nix drin) mit Zusatz Land- und forstwirtschaftlicher Verkehr frei ist track-grade1, alles andere unclassified Nach meiner Auffassung sind highway=track alles Wege, die *nicht* asphaltiert sind. Dementsprechend kommt track dann nicht in Frage, wenn Asphalt als Oberfläche feststellbar ist. Welche Nutzungsbeschränkungen der Weg verkehrsrechtlich aufweist, sollte mit seinem Typ nichts zu tun haben. Da es aber anscheinend unterschiedliche Auffassungen gibt, sollte dieser Punkt vielleicht mal einer Klärung unterzogen werden. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu FON-FIXME
Johann H. Addicks schrieb: Wenn die meisten FON Spots sowieso aus Google Geocoding hervorgehen, ist es dann überhaupt rechtlich okay, die Dinger in OSM zu haben Wenn wir die Adresse mit importieren, dann auf jeden Fall nicht. Da wir in der Datenbank aber weder das Datum des Imports haben, noch die Angabe, ob die Koordinate verifiziert wurde bzw. wann das Signal dort empfangen wurde: Beim nächsten Importlauf der Fon-APs ist wieder alles was wir bis dahin evtl. nachgebessert (oder an grob falschem gelöscht) haben für die Katz. Das Problem ist, dass über einen regelmäßigen Import bzw. dessen schmerzfreie Integration, gar nicht nachgedacht wurde. Das ist übrigens das Problem mit allen derartigen Datenimporten, bei denen sich nach dem Importzeitpunkt sowohl die Datenquelle als auch (naturgemäß) das Datenziel OSM verändern. Die Synchronisation ist extrem schwierig. Das sieht man ja schon allein an dem OpenGeoDB-Import - und der war, was dieses Thema angeht, schon extrem gut organisiert. Solange es kein generelles Konzept gibt, das den regelmäßigen Import aus externen Quellen regelt, ist das Importieren von veränderlichen Datenquellen eigentlich illusorisch. Im Grunde gibt es genau drei Szenarien: 1. Die Datenquelle ist der eindeutige Master. Änderungen in OSM gehen bei jedem Import wieder verloren. Der einzige Ort, um dauerhaft Änderungen zu integrieren, ist die Datenquelle selbst. 2. Die Datenquelle ist nur einmalig der Master. Danach werden die Daten nur noch in OSM gepflegt, und alle Änderungen werden bei Bedarf aus OSM zur Datenquelle zurückgespielt. 3. Datenquelle und OSM werden parallel genutzt und gleichen Änderungen jeweils untereinander ab. Problematisch sind hierbei Änderungen an demselben Punkt parallel in beiden Systemen - welche Änderung hat Vorrang? Szenario 3 ist sehr schwierig zu realisieren - der OpenGeoDB-Import versucht mit vielen Tricks, so zu wirken, als würde er sowas machen. In Wirklichkeit aber mischt er Szenario 1 und 2. Wenn ein importierter Ortspunkt in OSM verändert wird, soll man ja in einem speziellen Tag diese veränderten Felder entfernen, um zu verhindern, dass der nächste Import die Änderung wieder überschreibt. D.h. alle importierten Werte sind erstmal Szenario 1, und bedarfsweise werden Felder nach Szenario 2 behandelt. Das ist insgesamt zwar trickreich, aber bekanntlich hat seitdem noch niemand einen zweiten Import gewagt, so dass nicht mal Erfahrungswerte vorliegen, ob diese Tricks wie gewünscht funktionieren. Mutmaßlich müßte man für jeden gewünschten Import einer externen Datenquelle eine Zwischendatenbank anlegen, die dafür zuständig ist, die Änderungen in OSM und der Quelle zu analysieren und zusammenzuführen, und sie dann jeweils wieder an OSM und die Quelle zurückzugeben. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cyclemap als Overlay
Tobias Wendorff schrieb: kann mir jemand erklären, wieso Cyclemap nicht einfach als Overlay zur Mapnik oder Osmarender angeboten wird? Weil die Macher der Cyclemap sich Mapnik installiert und dessen Stylesheet angepaßt haben, weil es ihnen offenbar einfacher erschien, als sich mit irgendwelchem Overlay-Krams herumzuschlagen. Abgesehen davon ist die Cyclemap ja nicht nur eine Mapnik-Karte mit hervorgehobenen Radwegen, sondern sämtliche Features, die ein Radfahrer eher nicht benötigt, wie z.B. Autobahnen und Landstraßen, sind deutlich unauffälliger gezeichnet. Sowas kriegt man nicht hin, wenn man nur ein Overlay über die Standard-Mapnik-Karte legt. So könnte man nur die Radwege berechnen und dann über die vorhandenen Karten legen. Rendering wäre schneller, Traffik wäre geringer. Der Traffik würde sich (pauschal geschätzt) verdoppeln, da ja sowohl die Tiles des Standard-Mapniks zu laden wären, als auch die Tiles des Overlays. Außerdem könnte man so die Radwege auch extern einbinden. Niemand behauptet, die Cyclemap wäre perfekt. Wie sich zeigt (vor allem am zunehmenden Auswahlmenü von Kartenlayern auf www.openstreetmap.org), kommen im Laufe der Zeit immer mehr Anbieter dazu, die durch die Installation von Mapnik, Osmarender etc. durchsteigen, auf ihre eigenen Wünsche anpassen und das Ergebnis dann auch noch öffentlich verfügbar machen. Wenn du gern ein Radwege-Overlay haben möchtest, wärst du der beste Kandidat, dir die freien Kartendaten zu nehmen, um genau das zu realisieren. Vielleicht erhört man deinen Wunsch auch (entweder bei der Cyclemap, oder sonstwo), weil er sich mit dort vorhandenen eigenen Wünschen deckt, und realisiert was Neues - wer kann das schon wissen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Layer-Hierachie - so richtig verstanden ??
bevor ich jetzt weiter Flächen anlege möchte ich mich noch einmal vergewissern, dass ich die Layer-Hierachie auch richtig verstanden habe! Ist es richtig, dasss Grundsätzlich alle Element zunächst keinen Layer zugewiesen bekommen. Das ist korrekt. Flächen (Parks etc) bekommen Layer=0 und die darauf verlaufenden Ways (Weg etc.) Layer=1 Das ist falsch. Es gibt keinen Grund, einer Fläche einen Layer zu vergeben. Es gibt ebenfalls keinen Grund, den Wegen einen Layer zu vergeben. Alle Renderer malen die Wege prima über die Flächen, auch ohne Layerangabe. (Zugegeben, manches Renderer-Verhalten der Vergangenheit hat vielleicht Anlaß gegeben, Flächen übereinander zu stapel und mit Layer zu versehen, aber für Renderer taggen wir ja nicht.) Dasselbe gilt auch für Flüsse und sonstige Gewässer, die man nicht durch eine Layerangabe explizit unter ein eventuelles Landuse zwingen sollte, nur weil sie unterhalb der üblichen Erdoberfläche verlaufen. layer=0 ist kein Synonym für Erdoberfläche, die Layer-Angabe soll dem Renderer helfen, sich kreuzende Wege korrekt übereinanderzumalen. großräumige Flächen, wie Landuse=residental, retail etc., bekommen den Layer = -1 und können übergreifend angelegt werden. Mit übergreifend meine ich, dass darauf auch Parks, Wasserflächen etc. liegen können. residental co dienen primär der Gebietsklassifizierung. Auch das ist nach meiner Ansicht falsch. Die richtige Vorgehensweise ist, keinerlei Layer zu vergeben, und stattdessen mit einer Multipolygon-Relation Löcher in die großflächige Fläche zu brennen, und die Löcher dann entsprechend ihrer abweichenden Inhalte zu taggen. Mapnik und Osmarender kriegen diese gefüllten Löcher der Multipolygone mittlerweile bestens hin. Einzig Mapnik scheitert derzeit noch an verschachtelten Multipolygonen. Mein Testcase dazu ist das hier: http://www.openstreetmap.org/?lat=53.69531lon=9.85239zoom=17layers=B000FTF Ein Waldstück, in dem ein See ist, in dem wiederum eine Insel aus Wald ist. Mapnik zeichnet die Insel nicht, kriegt es aber hin, den Wasserlauf trotz layer=-1 über den Wald zu zeichnen. Osmarender zeichnet die Insel, versteckt aber den Wasserlauf unter dem Wald. Da Wasserläufe in der Regel durch Brücken über oder durch Tunnel unterquert werden, und diese Bauwerke mit layer=1/-1 zu taggen sind (die Diskussion, ob das vom Renderer nicht als Default angenommen werden sollte und deshalb entfallen kann, hatten wir gerade - Meinungsbild war: Nein, nicht soviele Defaultwert-Ausnahmen), ist es vollkommen problemlos, wenn der Wasserlauf auf Layer 0 bleibt. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Layer-Hierachie - so richtig verstanden ??
Jan Tappenbeck schrieb: Hallo Sven, und wie siehst Du das mit den Residental-Flächen - auch einfach keinen Layer zuweisen und übergreifend (Parkflächen etc.) Vielleicht nur aus Zufallsgründen, aber ich habe kein Problem gehabt, innerhalb von großen Residential-Flächen kleinere Inseln mit anderen Landuses oder Amenitys einzuzeichnen - das wird überall bestens gerendert, auch ganz ohne Layerangabe. Ich würde Layer erst dann zu Hilfe nehmen, wenn es anders nicht mehr geht. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Layer-Hierachie - so richtig verstanden ??
Jan Tappenbeck schrieb: Kannst Du aber bitte einmal einen Blick auf die beiden Teiche (in OSM vorhanden) werfen. (http://www.openstreetmap.org/?lat=54.13447lon=9.3069zoom=16layers=B000FTF) Die wurden beim Anlegen der Relation gleich doppelt (Relation und Teil) angelegt Warum auch immer - die ungetaggten Pfade ohne Relation habe ich mal direkt entfernt. Osmarender kriegt die Seen hin, Mapnik war noch nicht wieder dran. - werden aber in meinem KOSMOS nicht mehr angezeigt - vorher aber da. Vorher heißt Wald =-1 und Teich =1. Das Problem bei KOSMOS ist, dass dieser Renderer derzeit wohl noch komplett ohne Relations-Unterstützung daherkommt. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] WayCheck - Programm veröffentlicht und erste Verbesserungen in OSM Daten
Stephan schrieb: Oder ist es so, dass bridge, bzw. tunnel zwangsläufig ein Layer brauchen? Bin recht sicher, dass ich in der Mailingliste hier gelesen habe, dass Brücken ein default=1 haben. Die Wiki scheint sich nicht einig zu sein. Der von layer=0 abweichende Default bei Brücken und Tunneln war der Wunsch eines einzelnen Users (oder waren es zwei User? Ich bitte um Verzeihung, zumindest waren sie bislang in der Minderheit). Die Story ist allerdings ein Klassebeispiel, wie durch Unachtsamkeiten und Mißverständnisse die Grundlage der OSM-Datenbasis erodiert wird. Ich schätze, dass schon in absehbarer Zeit der Wildwuchs beim Tagging zumindest für lange bestehende Tags eingedämmt werden wird, weil er einfach eingedämmt werden muss. Die Alternative dazu wäre ein 100% durchgängiger, immer topaktueller Informationsfluß zu allen Usern und auf allen Ebenen, Wiki, Editoren, Renderer. Dass sowas jemals stattfinden wird, darauf wette ich lieber nicht. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eisenbahnbrücken
Tobias Wendorff schrieb: Jochen Topf schrieb: Redundanzen erlauben einem, diese Fehler eher zu finden. Redundanzen können aber auch Fehler erzeugen. Wenn man die Brücke mit einem Layer=1 einzeichnet, aber nicht geschaut hat, ob die Straße darunter bereits Layer=1 hat, gibt es Probleme. Wer nicht schaut, was er macht, sieht es spätestens beim Rendern auf der Karte - und korrigiert dann. Layer=+1 wäre sinnvoller. +1 auf was bezogen? Nur mal angenommen, die Brücke führt sowohl über eine Straße layer=1, einen Radweg layer=0 und einen Fluß layer=-1... Abgesehen davon halte ich nicht viel davon, einfach das im Wiki dokumentierte Vorgehen zu verändern, ohne auch die vielen Beteiligten mit einzubeziehen, namentlich die Editoren und die Renderer. Niemandem ist geholfen, wenn kein Renderer die neue Standardvorgabe layer=1 für Brücken nicht kennt, weil als Konsequenz die Layer-Angabe dann (von einem leicht verärgerten Mapper) nachgetragen werden muss, damit das Rendering wieder stimmt. Abgesehen davon hat sich auf diese Weise mal eben korrigiert-Weise wieder ein weiterer Widerspruch im Wiki etabliert, denn die Seite zum Brücken-Tag spricht weiterhin davon, Brücken explizit mit layer=1 auszuzeichnen, die Tunnelseite fordert layer=-1. Und was die Statistik angeht: Selbst wenn 95% der Brücken layer=1 haben - interessant ist ja vielmehr, wieviel Prozent der Brücken und Tunnel keine Layerangabe haben. Wäre das signifikant viel, könnte ich ja noch verstehen, dass diese scheinbare Doppelangabe nervig und redundant ist und von vielen deshalb bereits weggelassen wird. Aber wenn nahezu jede Brücke und jeder Tunnel sein Layer-Tag hat, ist es unsinnig, von dieser Verfahrensweise abzuweichen - jedenfalls nicht eher, als bis alle relevanten Renderer sich drauf eingestellt haben und layer=1/-1 als Default bei Brücken verwenden. Vorher wird sich niemand, dessen Hauptinteresse ansehnlichen Karten gilt, drauf einlassen, wenn das Render-Ergebnis Mist ist. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mini_roundabout?
Sascha Silbe schrieb: On Thu, Sep 11, 2008 at 01:30:32PM +0200, Andreas Labres wrote: Einverstanden, daß das http://lab.at/osm/fotos/mini_roundabout.htm ein highway=mini_roundabout ist? Kreisverkehre mit physikalischen Hindernissen in der Mitte (z.B. Verkehrsinseln) sind keine mini_roundabouts. Das Konzept des Mini-Roundabout ist, eine bisher normale Verkehrskreuzung mit ggf. beschilderter Vorfahrsregelung nur durch einen dicken kreisförmigen Farbklecks in der Kreuzungsmitte sowie neuer Beschilderung (Kreisverkehr + Vorfahrt achten für alle einmündenden Straßen) zu einem Kreisverkehr umzugestalten. Die dabei genutzte Straßenfläche wird dabei evtl. nur unwesentlich vergrößert. Ich würde die zwei Fotos ja gern als Anti-Beispiel ins Wiki laden (Erlaubnis?). Oder Andreas macht das selbst. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege auf Parkplätzen
Jan Tappenbeck schrieb: Moin ! da ja jeder macht was er will - frage ich dennoch. Große Parkplätze versuchen, wie wir, mit Wegen Ordnung zu halten. Mit dem highway-service finde ich das sehr mächtig ! Wie macht Ihr das ??? path mit Auto erlaubt ? Wege auf Parkplätzen mappe ich nicht. Dazu ist so ein Parkplatz viel zu sehr Wilder Westen, und jeder fährt, wo er will. Würde man die Aufgabe wirklich SOOO ernst nehmen, müßte man den Parkplatz in den allermeisten Fällen als Multipolygon anlegen und sämtliche grünen Inseln mit Bepflanzung aus dem Parkplatzpolygon herausnehmen. Das ist mir dann doch zu viel Arbeit mit viel zu wenig Effekt. Der die Karte verwendende Verkehrsteilnehmer soll froh sein, dass der Parkplatz eingezeichnet ist und irgendein Router ihn bis zur Einfahrt geführt hat. Die Orientierung innerhalb des Parkplatzes überlasse ich vollkommen ihm selbst. Die einzige Ausnahme von dieser Regel ist eine zweispurig ausgebaute und sogar von einer Buslinie genutzte Hauptverkehrs-Ringstraße auf dem lokalen IKEA-Parkplatz - vornehmlich aber auch, weil dieser Weg auch der einzige Zugangsweg zu einem noch dahinter befindlichen Campingplatz ist. Alle von dieser Straße abzweigenden Wege ignoriere ich allerdings. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eisenbahnbrücken
Markus schrieb: Hallo Sven, wenn das Render-Ergebnis Mist ist. Du meinst: also doch für die Renderer tagen/taggen/tacken/tackern? ;) Jede Regel braucht ihre Ausnahme. Und was mit dem Layer-Tag angestellt wird, wird sowieso kaum in geordnete Bahnen zurückgedrängt werden können. Mir gefällt der Gedanke recht gut, bei den Tags möglichst wenige und wenn, dann einheitliche Default-Werte zu haben. layer=0 als Default für alles ist mir sympathischer, als Ausnahmen für Brücken und Tunnel - selbst wenn die systematische Logik, dass Brücken normalerweise oben und Tunnel unten sind. Was wäre denn gewonnen? Sehr wenig. Der Mapper muß weiterhin ein Stück Straße abtrennen und als Brücke/Tunnel taggen. Dabei muß er weiterhin drauf achten, welchen Layer die durch die Brücke/Tunnel überquerten vorhandenen Wege haben, um das Layer-Tag der Brücke/Tunnel entsprechend zu wählen. Da er sowieso die Tags der Brücke bearbeitet, ist es wirklich nur ein winziger Zusatzaufwand, noch einen passenden Layer anzugeben. Wenn sich die Unsitte, Flüsse pauschal mit layer=-1 zu taggen, weiter verbreitet, dann hätte ein standardmäßiger Tunnel mit layer=-1 beispielsweise ein Problem. Ich bin ganz bei Dir: die Kommunikation zwischen Datensammlern und Renerern ist höchst mangelhaft... Kommunikation ist in einem diversifizierten Projekt wie OSM grundsätzlich ein Problem. Aber es ist illusorisch, zu verlangen, dass jeder OSM-Aktivist, egal welche Funktion er wahrnimmt, sich parallel noch in tausend weitere Informationsquellen einklinkt und viel Zeit aufwendet, um das empfangene Rauschen zu ignorieren. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] oberirdische U-Bahn = subway?
Andreas Barth schrieb: Hallo, wie tagged man denn eine oberirdische U-Bahn richtig? Die in München ist teilweise als subway, teilweise als railway getagged. railway ist sie m.E. definitiv nicht, subway ist richtiger von der Erwartung, was da fährt. (andere) Meinungen? Alle U-Bahn-Strecken in Hamburg sind railway=subway, auch dort, wo sie dem Namen des Betreibers Hamburger Hochbahn nachkommen und oberirdisch bzw. sogar auf Viadukten verlaufen. Die genauere Auszeichnung erfolgt dann mit tunnel=yes bzw. bridge=yes und entsprechendem Layer. S-Bahnen sind in Hamburg allesamt railway=light_rail, da sie über ein separates Schienennetz verlaufen. Es ist zwar an vielen Stellen mit dem normalen Bahnnetz über Weichen verbunden, diese Übergänge werden allerdings nur in Ausnahmesituationen benutzt. Außerdem gibt es noch die Linien der AKN. Diese Bahngesellschaft ist teilweise im Hamburger Verkehrsverbund integriert, verkehrt aber bis ganz nach Neumünster und läßt auf ihrer Strecke auch (vor allem nachts) Güterzüge fahren. Aus diesem Grund ist die AKN pauschal railway=rail, selbst auf den Abzweigungen, auf denen nur S-Bahn-artige Personenbeförderung stattfindet. Da in anderen Städten das schienengebundene Nahverkehrssystem nicht unbedingt so eindeutig getrennt ist, sondern sich Mischformen entwickelt haben (Straßenbahn fährt teilweise unterirdisch bzw. als S-Bahn), sollte sich das Tagging an der Erwartung des Kartenbetrachters orientieren. Ich würde beispielsweise Straßenbahnstrecken immer als railway=tram taggen, selbst wenn die Triebwagen irgendwann den Straßenbereich verlassen und auf separaten Strecken als S-Bahn gewertet werden müssen. Mitunter gibts für den Wechsel von Tram auf Light Rail ja auch technische Anhaltspunkte, beispielsweise den Wechsel der Stromversorgung. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu FON-FIXME
Tobias Wendorff schrieb: Hallo Leute, wieso stecken an den ganzen W-LAN Dingern von FON FIXMEs ? Damit du drüber stolperst und nochmal drauf aufmerksam gemacht wirst, dass diese WLAN-POIs aus einem bislang nicht durch FON autorisierten DB-Import stammen und deshalb wieder gelöscht gehören. Abgesehen davon kann man sich auch trefflich streiten, ob in die OSM-Datenbank Features gehören, deren Anwesenheit oder Abwesenheit von einem Menschen nicht ohne Hilfsmittel festgestellt werden kann. Elektromagnetische Strahlung eines WLAN-Access-Points, der versteckt irgendwo in einer Wohnung steht, ist so ein Ding. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisverkehr als Wendehammer
Jan Tappenbeck schrieb: Moin ! kann sich einer von Euch einen Reim darauf machen, warum jemand Wendehämmer (richtige Mehrzahl ?) mit einem mini_roundabout kennzeichnet ??? Weil man in beiden im Kreis fährt? Habe ich in meiner Gegend auch entdeckt und wieder entfernt, weil es faktisch falsch ist. http://www.informationfreeway.org/?lat=53.894068255462976lon=10.644024135510545zoom=15layers=B000F000F Da ist in der Nähe allerdings noch eine T-Kreuzung, auch mit Mini-Roundabout getaggt. Ist das wirklich nur ein Farbklecks in der Mitte der Straße (weil nur das sind in UK mini-roundabouts), oder ist da doch eine Verkehrsinsel, die man normalerweise nicht überfahren kann bzw. sollte. Dann wäre das als echter Kreisverkehr zu taggen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] wlan von maps.fon.com
Guenther Meyer schrieb: Am Montag 01 September 2008 schrieb Michael Buege: Zitat Johann H. Addicks: Lass gut sein, Johann, wir drehen uns hier im Kreis. Ich verstehe Deine Einwaende durchaus, gleichwohl kann ich sie nicht akzeptieren. Denn mir geht es nicht um diese konkreten Wlan-Punkte, auch nicht um Flugrouten oder andere Dinge, die der ersatzlosen Loeschung anheim fallen sollen, nur weil irgendjemand den Sinn dieser Eintraege nicht erkennt oder versteht. Es braucht genau _einen_ Grund, um diese Daten im Bestand zu belassen: Derjenige, der sie eingetragen hat, moechte, dass sie drin sind. wie waers denn, wenn man denjenigen ganz einfach nach seinen beweggruenden fragt, und ihm die hier genannten punkte nahelegt, anstatt hier sinnlos rumzudiskutieren? [x] done Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Newby fragen, tips gesucht...
Lars Schimmer schrieb: Leider hatte ich vor Ort nur ISDN und hab somit wohl vieles nicht beachtet. Gerade im Sinne der Qualitätsoffensive wollt ich mal nach generellen Fehlern in meiner Vorgehensweise fragen, damit ich nächstes Mal bessere Ergebnisse liefern kann ;-) Du hast alle Wohnstraßen als road getaggt. Das ist falsch. road ist ein Platzhalterwert für hier ist eine Straße, dessen Typ ich nicht kenne. Ich vermute aber mal, dass du sehr wohl den Typ kennst, mutmaßlich sind das alles residential, also Wohnstraßen. Ansonsten taucht in dem Kartenausschnitt zweimal der Straßenname Feldweg für zwei nicht zusammenhängende Tracks auf. Ich nehme an, dass diese Feldwege nicht offiziell Feldweg heißen, sondern gar keinen Namen haben - also ist das name-Attribut hier fehl am Platz. Dass es ein Feldweg ist, erkennt man am Tagging als track mit zugehörigem tracktype. Den Rahmen um den Ort solltest du, sofern das alles bebaute Fläche ist, mit landuse=residential taggen. Ob die zusätzliche Angabe von name und place dann noch notwendig sind, würde ich anzweifeln. Dafür gibts ja schon den Punkt in der Ortsmitte. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strassenbegleitende Wege aller Art
René Falk schrieb: Am Freitag, 29. August 2008 schrieb Frederik Ramm: Ich bin sowieso total gegen links und rechts. Das kommt mir einfach unprofessionell vor. Ist das echt ueblich in der Strassenbau-Szene, dass man von linken und rechten Seiten einer Strasse spricht? Bei Fluessen kann ich mir das ja noch vorstellen, weil die Flussrichtung dort natuerlich vorgegeben ist; es bedarf keiner Zusatzinformation fuer mich, wenn ich als Mensch die Information linksrheinisch bei Karlsruhe verarbeiten will. Will ich aber links der B36 bei Karlsuhe verarbeiten, brauche ich zusaetzlich die Info, wierum die B36 denn verlaeuft, und dafuer gibt es keine Definition. Ist meiner Meinung ein schlechtes Beispiel. Bundesstraßen haben im allgemeinen schon eine Richtung durch die Stationierung. Aber natürlich hast Du recht, das sollte mal professionell geklärt werden. Vermutlich kann man über die amtlichen Straßenverzeichnisse die Richtung klären, solange diese keine reinen Bestandslisten sind, was ja auch vorkommen kann. Aber dann hat man immer noch keine Regel dafür. Ich sehe auch noch den pragmatischen Aspekt: Als Mapper bewegt man sich auf einer Straße entlang und notiert sich, was links und rechts des Weges anzutreffen ist. Dann wird die Straße gemappt. Und es gibt diverse Möglichkeiten für Fehlerquellen: 1. Die Richtung der Straße in OSM sollte natürlich entsprechend der Bewegungsrichtung des Mappers angelegt werden, denn nur dann stimmen die Seitenangaben links und rechts in den Notizen mit dem vorzunehmenden Tagging. 2. Andererseits ist es wahrscheinlich, dass die Straßenrichtung nicht schön von unten nach oben verläuft, links und rechts der Straße sind dann mitunter rechts und links auf dem Bildschirm. Oder oben und unten. 3. Die Problematik mit der per Editor durchgeführten Wegdrehung wurde auch schon mal angesprochen: Alle Editoren, die so eine Funktion anbieten, werden gezwungen, alle irgendwo erfundenen links/rechts-Taggingschemata zu kennen (oder zu erkennen), um dann die Seitenangabe korrekt anzupassen. Das mag für einige eine triviale Aufgabe sein, aber ich befürchte, dass wir uns damit ganz gehörig ins Knie schießen werden - denn sobald die Möglichkeit des straßenseitenabhängigen Taggings erstmal besteht, wird wieder die Mapperkreativität neuer Tags zuschlagen. Und es ist jetzt noch nicht abzusehen, welche Formen des Taggings für künftig zu erfassende Daten notwendig sein werden. Sprich: Die Umkehrungsregeln der Editoren werden künftig so unvollständig sein, wie die Rendering-Regeln von Mapnik oder Osmarender. Was allerdings deutlich problematischer wäre. Entweder der den Weg drehende Mapper paßt manuell alle Tags des Weges an, oder alles geht automatisch. Wenn nur 90% automatisch angepaßt wird, werden die letzten 10% vergessen werden. Zum Glück ist die Notwendigkeit, Wege zu drehen, durch oneway=-1 praktisch auf Null gesunken. Die Alternative zu links/rechts wäre ein Himmelsrichtungstagging. Wurde hier auf der ML auch schon von irgendwem angesprochen. Hätte den Vorteil, dass der Mapper vor Ort sich nach der eindeutigen Himmelsrichtung (Kompaß liefert ihm hoffentlich sein GPS) orientiert, und beim Arbeiten am PC sind die Himmelsrichtungen immer identisch, ohne Verwechslungsgefahr. Allerdings eignet sich das auch nicht wirklich uneingeschränkt für alle Anwendungen. Man stelle sich nur mal vor, ein Radweg begleitet eine Straße auf der einen Straßenseite während eines 180-Grad-Bogens oder noch üblerer Schlangenlinien. Oder man nehme nur irgendeine ringförmige Rennstrecke. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] RFC: Tags für Tags - warum so kompl iziert?
Birgit Nietsch schrieb: Guenther Meyer schrieb: Es gibt Fälle, die man nicht automatisch entscheiden kann, weil sich die Schilder in einem Fall auf nachfolgende Gegebenheiten beziehen, und im anderen nicht. Und jetzt kommen nette Konstrukte, deren Realitätsbezug durchaus angezweifelt werden dürfen. - max. 9,5t - max. 30 km/h - Anlieger frei Heisst in dem Fall nicht, dass Anlieger rasen dürfen, sondern dass Bauer Hinnerk mit seinem Viehtransporter da durch darf. Sollte tatsächlich solch eine Kombination von Schildern auftreten, wird das sicherlich so aussehen: max. 30 km/h Lücke max. 9,5t Zusatzschild: Anlieger frei. Damit dürfte der Sinnzusammenhang einigermaßen ausgedrückt sein, allerdings kann ich mir gut vorstellen, dass manche Verkehrsämter aufgrund der Uneindeutigkeitsmöglichkeit darauf verzichten, diese beiden Schilder an einem Pfosten zu kombinieren. - max. 12t - max. 30 km/h - LKW verboten - Anlieger frei - das ganze vor 'ner Brücke Bauer Hinnerk darf mit dem Viehtransporter durch, solange jener nicht mehr als 12t wiegt, denn sonst bricht die Brücke ein. Laut Vorschrift dürfen an einem Pfosten nicht mehr als zwei Verbotsschilder, nur ausnahmsweise drei Verbotsschilder, montiert werden - bei drei Schildern darf sich aber nur eines auf den fließenden Verkehr beziehen. Dein Beispiel umfaßt vier Schilder, die sich ALLE auf den fließenden Verkehr beziehen. Es wird also in der Praxis nicht vorkommen. Zudem baust du noch einen Logikfehler ein. Was meinst du denn mit LKW verboten? Doch nicht etwa dieses runde rotumrandete Schild mit dem Schwarzen LKW drauf? Dieses Schild steht für: Verbot für Kraftfahrzeuge mit einem zulässigen Gesamtgewicht über 3,5 t, einschließlich ihrer Anhänger und Zugmaschinen, ausgenommen Personenkraftwagen und Kraftomnibusse. Nicht für LKW verboten. Dieses Schild kombiniert sich ganz schlecht mit einem Verbot eines tatsächlichen Gewichts. Bleibt also übrig: Maximales Gewicht 12 Tonnen, maximale Geschwindigkeit 30 km/h - keine Ausnahme für Anlieger, weil das Anliegerschild für LKW verboten ja mit entfällt. Es liegt mir fern, zu behaupten, die Behören würden es nicht hinkriegen, absoluten Schilderschwachsinn zu produzieren - das Gegenteil ist mit Sicherheit der Fall. Aber wenn schon irgendwelche Beispiele ausgedacht werden, dann doch bitte welche, die in der Realität auch vorkommen können. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Waldwege
Bernd Wurst schrieb: Hallo. Am Samstag, 23. August 2008 schrieb Johann H. Addicks: Ich sehe auf dem Schild nur was zum Thema Kraftfahrzeuge. Radler, Reiter und Fußgänger dürfen den Weg nutzen. Das ist für mich permissive. Der erste Sat ist richtig, auf dem Schild steht nur was von Kfz. Warum also access=permissive? Auf dem Schild steht aber auch Waldweg - Nicht öffentlich. Das ist dann nicht access=yes, sondern eben nur access=permissive, halt die offenere Variante vor access=private. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Talk-de Digest, Vol 25, Issue 214
Marc Schütz schrieb: Ach ja, und highway=minor wird anscheinend nicht berücksichtigt. highway=minor ist abgeschafft und soll durch gültiges Tagging ersetzt werden. Sie wird hier http://wiki.openstreetmap.org/index.php/Highway nicht gelistet. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] API v7
Henry Loenwind wrote: first, the following are some half-baked ideas I just want to get out of my head because I need the space they are taking up ;) I think you brought up some valid points. The echo so far proves that you touched regions for the experts only[TM], nothing the average mapper feels able to discuss. But nevertheless it has to be discussed. Reoccurring problem 1: Way splitting. At the moment we need split ways at every point there is some change to them. While this is much better than segments were, recombining them with relations just demotes ways to segments and makes relations our new ways. Nothing gained. Going the opposite way, by not splitting the ways and giving parts of them different properties with relations is not much better---there is no support for including parts of a way in a relation, so the relations will contain one way and (hopefully) two nodes an some obscure meaning how to cut the way. (Note: obscure meaning not in the data model.) As Frederik pointed out: Why in general are split ways bad? No matter how you turn it around, a way will always be split at a certain level. As an example: A primary street running from village A to B might change its name somewhere in the middle, but using the same reference number. And each part of the named street has two different maxspeeds (inside the village and outside). With the current model, we have four ways. Using relations, one could group each two ways with the same name to be one named street. From the data models perspective, this sounds preferable. But what is gained with this approach? The current tools force mappers to think in internal data structures. But that's because the tools do not comfortably, automagically create relations based on user input. There are two ways with a shared node and the same name? Then make the name a relation. Of course this could be done internally in the API, transparently, just to optimize data storage or whatever this is good for, and me might end up having two different API modes, one with relations, and one without (all tags within relations mapped as attributes to every single way), or the API data model becomes more and more obscured by the editing tools, because it simply does not help mappers to be forced to think about all the internal stuff. The point is: If the development goes away from presenting ways and relations to the mapper, then it becomes less and less relevant to the mapper to worry about how it is all stored in the data blackbox. Reoccurring problem 2: Two side of a coin, oops, a way. Most ways have two sides, often they are the same, but also often they are not. Different maximum speeds, or different access rules, sometimes even different highway types (highway=residential, oneway=yes on one side, highway=cycleway the other). No clean way to model this, too. There are some tags for common cases, like cycleway=opposite, but that's all. While I don't see the point with splitting ways, here you have a valid point - but let me state the problem I see a bit different. I don't like the method of current oneway street tagging, because it interferes with other street tagging relying on the direction of the street. This somehow relates to your suggestion: tag k=bridge v=yes from=P1 to=P2 side=both/ tag k=maxspeed v=30 from=P1 to=P2 side=left/ tag k=maxspeed v=50 from=P2 to=P1 side=right/ ... tag k=highway v=bus_stop from=P1 to=P1 side=left/ tag k=highway v=bus_stop from=P2 to=P2 side=right/ ... The problem I see is not where streets are actually tagged as oneway streets - it's all streets without them that make the problem. Because if a oneway street is accidentially reversed, this error will eventually be noticed and corrected. But every normal street might be reversed without any noticable impact as of today. But there is a need to tag not just the direction of the main traffic component of the street (e.g. motorized, fast, four-wheeled), but to add facilities for the others: pedestrians, cyclists and so on. Using current tagging, you would be able to add a tag both sides of this street have a cycleway. And this might be rendered as a blue (or blue dotted, to mimik the pure cycleway) border on the street. How do I tag that only one side of the street has a cycleway or a sidewalk/pavement. I could use cycleway=left, but where is left. It has to depend on the direction of the way (although I don't really like this directional word for this task, there should be some other way to encode this fact). But the direction is directly connected with the oneway tag, and I really doubt that the editors, which until now have an easy task reversing a way, will be able to consider and adjust all tags connected with the direction of the way. I'd suggest to let the original creator of a way define its direction, and then to never touch it again. Every tagging which relies on the ways direction can either be along it's
Re: [Talk-de] ÖMTC-Übungsplatz
Florian Schweikert schrieb: Hallo, da ich gerade den Führerschein mache und vor habe zum ÖMTC-Übungsplatz zu fahren, frage ich mich wie ich die Strecken am Platz mappen kann. Würde mal zu highway=unclassisfied tendieren, was soll ich aber für access verwenden? Ist destination dafür das richtige? mfg, Florian (Kelvan) Wenn man die Wege des Übungsplatzes befahren darf, ohne die Erlaubnis des Besitzers zu haben, weil man an einen Ort gelangen möchte, der nur über diesen Weg erreichbar ist, wäre destination angesagt. Das bezweifle ich aber. In der Regel steht so ein Verkehrsübungsplatz abgesperrt von der sonstigen Öffentlichkeit in der Gegend rum, und man muß irgendeine Form von Eintritt bezahlen. Also Zutritt nur mit Genehmigung des Besitzers: access=private. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Benutzbarkeit eines Weges z .B. als Fußgänger?
Florian Heer schrieb: Ich stell mir das so vor, dass es 3 Kategorien geben sollte: vermeiden, normal, bevorzugen (avoid, standard, favor), wobei die Werte dann avoid, ungesetzt und favor sein könnten. Die Idee an sich ist zwar nicht komplett schlecht, allerdings möchte ich einen Aspekt zu bedenken geben: Ein Rating der Form bevorzugen vs. meiden kann man nur treffen, wenn man eine Wahl hat. Wenn du als Ortskundiger regelmäßig mit Verkehrsmittel V von A nach B willst, und dir stehen dafür zwei oder drei Wege zur Verfügung, hast du eine Wahl und kannst für z.B. den Landstraßenweg vermeiden setzen, und für den (leicht längeren, aber für dein V besser geeigneten) Feldweg bevorzugen. Wenn es nur einen einzigen Weg von A nach B gibt, der dein Verkehrsmittel V zwar grundsätzlich erlaubt, aber dir absolut ungeeignet erscheint, bleibt dir trotz aller Abscheu nichts anderes übrig, als diesen Weg zu nehmen - mangels Alternativen. Obendrein ist die Bewertung eben nur im Verhältnis zu sehen zwischen typischerweise zwei alternativen Wegen. Du willst von A nach B und hast die Wahl zwischen Weg 1 und 2. Dein Favorit ist die 2. Jemand anderes will von C nach B, und er hat dafür sowohl Weg 2 als auch Weg 3 zur Verfügung, und seine Wahl fällt ganz eindeutig auf Weg 3. Mal konkret: Dein Weg 1 ist die stark befahrene, kurvige und radweglose Landstraße (also avoid), dein Weg 2 ein Schotterfeldweg (für dich favour). Der Weg 3 wäre ein schöner Radweg-Teerstreifen entlang einer wenig befahrenen Straße (für jeden Nutzer im Vergleich zu dem Schotterweg favour). Jetzt steht also Aussage gegen Aussage. :) Ich glaube nicht, dass man die Routenplanung durch solche allgemeinen Tags sinnvoll beeinflussen kann. Ich glaube, dass vielmehr die existierenden Tags zusammen mit einer komplexeren Auswahllogik, auch beeinflußt vom Nutzer selbst, zu den gewünschten, individuellen Ergebnissen führen werden. Angenommen, du routest dich von A nach B, und der Router listet dir (ggf. schon mit Hinweis, weil er highway=primary, maxspeed=100, aber kein cycleway-Tag dabei gefunden hat) diese eklige Landstraße auf, die du nicht magst (dank Ortskenntnis). Wenn du dem Router jetzt klarmachst, diese Straße zu meiden, kann er direkt um diese Straße herumrouten. Oder er hätte die Straße für deine Verkehrsmittelwahl und deine Präferenzen ([x] Immer mit Radweg, [x] bis 10% Umweg erlauben, [ ] auch schlechte Wegstrecken verwenden (grade 3 und schlechter)) sowieso ausgeschlossen, sofern die Schotterstrecke als gut getaggt ist. Ich glaube, alle tollen Routingwünsche lassen sich irgendwann einmal erfüllen. Ich glaube allerdings nicht, dass die Antwort auf beliebige Routingwünsche ein immer ausgefeilteres Tagging ist - zumindest nicht zum heutigen Zeitpunkt. Was derzeit fehlt, sind entsprechend ausgefeilte Routing-Applikationen, an denen man die Effizienz der derzeit vorhandenen Tags erst einmal testen kann. Solange an dieser Front die Entwicklung nicht voran geht (denn auch alle neu erfundenen Tags müssen ja vom Router ausgewertet werden), bringen Überlegungen zu neuen Tags relativ wenig. Allerdings kann ich verstehen, warum sie trotzdem angestellt werden: Neue Tags sind in OSM deutlich schneller erdacht und eingetragen, als wie Routingsoftware entwickelt werden kann. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tag für Benutzbarkeit eines Weges z .B. als Fußgänger?
Florian Heer schrieb: Bei meinem Beispiel, wegen dem ich überhaupt auf die Idee gekommen bin, gibt es 2 Landstraßen, die gleich getaggt sind. Eine ist unübersichtlich und verkehrsreich, die andere, die in diesem Fall minmalst länger wäre, ist genau das nicht. Somit gibt es in diesem Fall keine Entscheidungsmöglichkeit, die die für Fußgänger extrem ungünstige Variante NICHT bevorzugen wird. Es gilt ja: Gleiches Recht für alle. Wenn du also für dich als Fußgänger die eine Straße als avoid taggst, die andere aber nicht, dann haben Autofahrer genau dasselbe Recht. Die werden dann auch die überfüllte, schlechter fahrbare Straße als avoid taggen, wenngleich auch aus anderen Überlegungen. Als Resultat werden dann alle[TM] Autofahrer nur noch die minimal längere, leere Landstraße befahren - und schon ist dein Fußgängertagging genau falsch geworden. Im schlechtesten Fall endet es damit, dass beide Straßen gleichstark und gleich ungünstig für Fußgängerverkehr von Autos frequentiert werden. Ich glaube halt nicht, dass so ein Tagging von weichen, subjektiven Eindrücken wirklich hilfreich ist. Wenn du einer bestimmten Gruppe von Verkehrsteilnehmern deutlich machen willst, dass sie schlauerweise einen ganz bestimmten Weg nehmen sollten, so würde es sich anbieten, das als Route (mit Relation und dem ganzen Zeugs) zu tun. Noch die passende Bezeichnung dran (Florian's empfohlene Fußgängerroute als Alternative zur Landstraße XY), und schon könnte man glücklich sein. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sprechende Namen!! (Re: pathtype ? grades für Fußwege )
Sven Anders schrieb: Am Freitag, 25. Juli 2008 10:46 schrieb Bernd Wurst: Hallo. Klar, wenn man sich tagwatch anschaut, graust es einen auch, wie viele Fehler man bei der aktuellen Anwendung machen kann. Aber da ist es wenigstens eindeutig umzuwandeln bzw man zieht sich einfach den numerischen Teil raus. Aber du musst dir dann die nummerischen Werte und die Zuordnung merken!! Ich persönlich kümmere mich eigentlich wenig um irgendeine Zuordnung von Wegstruktur zu Nummernbezeichner. Ich sehe die grade1-5-Angabe als eine zusammenfassende Bewertung der Wegqualität. Ich hab allerdings auch noch nicht sonderlich viele Tracks gemappt. :) Besser fände ich (müsste noch nach englisch übersetzt werden) zustand=sehr_eben zustand=eben zustand=schotter zustand=festes_Schuhwerk zustand=schlamm Wie taggst du dann sehr ebene Schlammwege, oder unebene Schotterwege. Und überhaupt: Welche Tags bezeichnen denn jetzt die besseren und die schlechteren Wege, welche sollte man bevorzugen? Ich kann mir deutlich leichter merken, dass die zusammenfassende Abstufung von grade1 bis grade5 geht (grade2 ist dabei eindeutig schlechter, als grade1, aber noch viel besser, als grade5), als dass ich mir merke, welche umfassende Attributierung man für die physikalischen Eigenschaften des Weges im Detail anwenden könnte. Und erst recht, wenn's dann doch auf so unscharfe Attribute wie sehr_eben, eben, eher_uneben,ziemlich_uneben,uneben rausläuft. War uneben jetzt ganz am Ende der Skala, oder kommt es noch vor ziemlich_uneben? Kann man uneben noch weiter steigern zu extrem_uneben? Ist mein extrem_uneben vielleicht dasselbe, wie dein ziemlich_uneben, weil ich einfach spiegelglatte Wege bevorzuge und schon leichten Rollsplit als Unebenheit klassifiziere, du aber mit deinem Geländewagen nie genug Schlaglöcher haben kannst... :) Mit Schlamm wär's ja dasselbe: Der zeigt sich tendentiell nur, wenn die Anwesenheit von Wasser zum Zeitpunkt der Beobachtung festgestellt werden kann. Es gibt bestimmt dutzende wissenschaftliche Literatur aus der Softwaretechnik, warum sprechende Bezeichner besser sind. Kartendaten sind zwar auch erstmal soft, Softwaretechnik halte ich hier aber nicht für anwendbar. Bei den Straßentypen ist das doch auch kein Problem: Primary = rank1, secondary = rank2, tertiary = rank3 - ziemlich willkürlich und an vielen Stellen nur durch die subjektive Einschätzung des Mappers vergeben. Macht aber relativ wenig Probleme bislang. Würdest du stattdessen die rechnerisch und/oder tatsächlich vorhandene Aufnahmekapazität in Fahrzeuge pro Stunde mappen wollen? Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Mapping von Flugrouten sinnvoll?
Hallo, Liste! Mir ist unlängst aufgefallen, dass ein Mapper offenbar die Flugroute von Hamburg nach Nürnberg eingetragen hat. Dieses Vorhaben gefällt mir weniger gut, aus mehreren Gründen: 1. Der Hamburger Flughafen hat zwei Landebahnen in vier Himmelsrichtungen, und grundsätzlich wird zumindest für Landungen auch jede Landebahn genutzt (Starts nur in drei Richtungen), je nach Windrichtung. Würde man also wirklich Flugrouten von/nach Hamburg eintragen wollen, müßte man also eigentlich vier Anflüge nach Hamburg eintragen. Dasselbe nochmal beim Zielflughafen: Nürnberg hat nur eine Landebahn, also zwei Start/Landerichtungen - insgesamt also acht Routen, die der Vollständigkeit halber zu mappen wären. 2. Genauso wie wir es lieber lassen, Routing von Wasserfahrzeugen zu unterstützen, weil es für diesen Anwendungszweck strengere Vorschriften und höhere Anforderungen an Datengenauigkeit gibt, sollten wir es ebenso lassen, Routing von Luftfahrzeugen zu unterstützen. 3. Ich kann mir außerdem sehr gut vorstellen, dass die eingetragene Route nur EINE von mehreren möglichen Wegen von Hamburg nach Nürnberg ist. 4. Die gemappte Route führt zu unschönen Rendering-Ergebnissen: http://www.openstreetmap.org/?lat=53.55823lon=9.8593zoom=17layers=B00FTF Westlich des Ordinger Wegs taucht auf der Karte unmotiviert der Routenname EDDH-EDDN auf (mutmaßlich auch noch an anderen Stellen entlang der Route. 5. Würde diese Idee breiter eingesetzt, hätte es zur Folge, dass alle Flughäfen mit einer Vielzahl anderer Flughäfen in Verbindungsrouten konnektiert werden - das Liniengewimmel an den Endpunkten der Landebahn will ich mir lieber nicht vorstellen - zumal es ja nicht damit getan wäre, nur die Routen internationaler Flughafen zu mappen. Die Welt ist übersät mit vielen winzigen Grasspisten, auf denen sich die üblichen einmotorigen Privatflieger herumtreiben. 6. Flugrouten ändern sich mit schöner Regelmäßigkeit. Einem Nutzer ist nicht damit geholfen, dass er der Karte entnehmen kann, dass man grundsätzlich von Hamburg nach Nürnberg kommen kann, sondern ihn interessiert auch, wann das geschehen kann - und wie teuer es wird. All dies recherchiert er aber besser auf den Webseiten der Flughäfen oder Fluggesellschaften. Ich würde diese Route wieder aus OSM löschen, wenn der Liste nicht noch irgendeine sinnvolle Nutzung einfällt. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Verkehrszeichen abschaffen!
FreeWorld schrieb: Außerdem auch Gehwege, Fußgängerüberwege usw. Warum nicht? Ich halte immer noch daran fest, dass ich es für eine gute Lösung halte. Vor allem kann dann ein Unfallverursacher nicht mehr behaupten, er hätte aber Vorfahrt gehabt - es zahlt der, der nicht rücksihtsvoll fährt! Das ist doch aber genau das Problem. Wenn es zu einem Unfall kam, kann ja jeder behaupten, der andere war nicht rücksichtsvoll genug. Wenn du keine Schilder mehr hast, die eindeutig festlegen, wer Recht hatte, kommst du zumindest versicherungstechnisch schnell in Schwierigkeiten. Du übersiehst, dass es bei der Klärung der Schuldfrage deutlich mehr Faktoren gibt als nur die Aussage der jeweiligen Fahrzeugführer. Außerdem kann ich mir vorstellen, dass es immer Assis gibt, die solch eine schilderlose Situation gnadenlos ausnutzen und eben mit 160 durch die ehemalige 30er Zone düsen, auf Kosten der anderen, die dadurch mehr aufpassen müssen, bzw. sich selbst einschränken müssen - fänd ich unfair. Neidgedanken? Die anderen kommen schneller voran, als ich selbst! Frechheit! Jemand, der innerhalb geschlossener Ortschaften schneller als 50 km/h fährt, handelt verkehrswidrig. Sollte er 160 km/h in einem Shared Space fahren, dürfte wegen der erheblichen Gefährdung eine heftige Strafe zu erwarten sein. Shared Space heißt ja nicht, dass alle Regeln abgeschafft sind. Und noch ein Aspekt kommt bei Straßenschildern hinzu. Sie sollen nicht-ortskundigen einen Eindruck von der Verkehrssituation vermitteln. Ich würde behaupten, dass es gerade die Ortskundigen sind, die das Problem darstellen. Die sehen die Schilder zwar, nehmen sie aber nicht mehr wirklich wahr und handeln nicht nach ihnen. Zebrastreifen? Da ging noch nie jemand rüber. Baustelle, Langsamfahrt? Ich kenn die Stelle gut genug und kann auch schnell fahren. Überholverbot? Ich hab genug PS, um schnell vorbeizuziehen, hier kommt sowieso keiner entgegen. Ein nicht-ortskundiger kann vielleicht gar nicht einschätzen, dass es besser wäre hier 30 zu fahren oder vor der nächsten Kurve abzubremsen oder auf den Zug zu achten, der da gleich über die Bahnschienen um die Ecke kommt. Nicht alle Verkehrsschilder sind sinnlos zumindest nicht für jeden. Ein Ortsunkundiger wird eine scharfe Kurve sehen und abbremsen - wohlmöglich stärker, als notwendig - um die Kurve sicher zu nehmen. Ein Ortskundiger hingegen kennt die Kurve auswendig und weiß, dass man sie, obwohl die Geschwindigkeitsbegrenzung 30 km/h vorschreibt, auch noch mit 55 km/h umrunden kann. Zumindest bei trockener, rollsplitfreier Fahrbahn. Warum muß man das offensichtliche (eine Kurve) unbedingt noch mit einem Verkehrsschild pflastern? Von der Abschaffung der Kennzeichnung von Bahnübergängen hat man meines Erachtens im Rahmen des Shared Space noch nie gesprochen - dem stehen außer der Straßenverkehrsordnung ja auch noch bahnrechtliche Vorschriften im Weg. Pauschal ganze Gruppen von Verkehrsschildern abzuschaffen halte ich allerdings für fragwürdigen Aktionismus. Nicht die mögliche Auswahl an Schildern ist das Problem, sondern die Häufung der nutzbaren Schilder auf engstem Raum. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Zulässige Tragfähigkeiten von Brüc ken
Mario Salvini schrieb: was haben die eigentlich zu sagen? meine Vermutung is immer z.B: ohne kreuzenden Verkehr 100km/h bei Gegenverkehr auf beiden Seiten nur 50km/h. is das richtig vermutet? Ich würde die km/h eher durch Tonnen ersetzen. ;-) aber welches Fahrzeug wiegt denn 100t? aber ok.. dann müßten 2 kreuzende Leopard 2 Panzer halt nacheinander über die Brücke... erfassern wir diese Schilder denn in irgendeiner Form? oder einfach ein maxweight=100t? Die Zahl gibt die militärische Lastklasse an. Das entspricht nur SEHR GROB einem Gewicht in der Größenordnung von Tonnen. Abgesehen davon werden diese gelben Schilder in Westdeutschland wohl gerade allgemein abmontiert, in Ostdeutschland wurden sie nach der Wiedervereinigung niemals begonnen aufzustellen. Insofern: Nicht mappen, lohnt nicht mehr. Erstens interessiert es den zivilen Verkehr nicht die Bohne, zweitens haben zivile Fahrzeuge ohnehin keine Lastklasse, die man für den Vergleich mit der Schildaufschrift nutzen könnte. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Fl��� ��������������� ��
Robert Heel schrieb: Argumente, welche für die ausschließliche Markierung von besonderen landwirtschaftlich genutzen Flächen (Bauernhöfe, Felder innerorts) sprechen: - Es wird nicht ganz Deutschland Braun/Grün dargestellt - Bauernhöfe sind gut zu erkennen Heißt es nicht: Nicht für den Renderer taggen? Was kann der taggende OSMer dafür, wenn Renderer die ganze Landschaft braun-grün rendern, nur weil Fakten in der DB stehen? Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] upload not instant?
Ich wäre ja sehr dankbar, wenn die Mailingliste nicht noch zusäzlich durch sinnlose Diskussionen aufgebläht würde - und das Palaver über den richtigen Editor ist so eine Diskussion der Marke Bikeshed (siehe www.bikeshed.org). André Reichelt schrieb: Doru Julian Bugariu schrieb: Nunja, ich finde da sollte sich Richard aber nochmal Gedanken darueber machen. Mag ja sein, dass ein Upload-Button nicht ins Potlatch-Konzept passt, aber das (ungewollte) Zerstoeren von Daten, sobald man was anfasst, is m.E. viel schlimmer! Das stimmt. Man sollte unter diesem Gesichtspunkt echt shnell eine Lösung suchen, denn er kann definitiv nicht sein, dass man aus versehen ganze Straßen zerstören kann. Da sollte min. eine Rückfrage eingebaut werden oder eben wie vorgeschlagen ein Uploadbutton. Man könnte ja unten eine Liste mit allen bisherigen Änderungen einblenden und nebenan einen Button Änderungen bestätigen. Was wird hier jetzt eigentlich genau kritisiert? Dass Leute den Editor benutzen und die OpenStreetMap verändern? Lernt, damit zu leben! Wenn es euch stört, dass man Daten unwiderbringlich und unbemerkt in den Orkus schicken kann, dann wäre der wahre Ansatzpunkt, analog zur Wikipedia einen entsprechenden Ansatzpunkt zu implementieren, der ein leichtes Revert zu einer früheren Version erlauben würde. Solange sowas nicht bedienbar existiert, kann man mit jedem Editor die Karte zerstören. Gegen willentlichen Vandalismus hilft auch ein Save-Button nicht. Als unbedarfter wuerde ich auch nicht davon ausgehen, dass ich was geaendert habe, ohne es explizit zu speichern oder an einem Server zu senden. Das stimmt. Es geht nirgends offensichtlich hervor, dass die Änderungen SOFORT und OHNE RÜCKFRAGE gespeichert werden. Das schönste bei solchen Diskussionen ist aber, wenn sich erklärte Editor-Hasser über den Editor auslassen und Behauptungen aufstellen, die so gar nicht stimmen. Potlatch 0.9c hat ein wunderbares, explizit sichtbares Erklärfeld, welches exakt DIESE Aussage widerlegt. Vielleicht koennte man ja eine Checkliste mit Mindestanforderungen erstellen. Wenn jemand einen Editor programmiert, der die Live-Daten aendern moechte, muss er die Liste erfuellen koennen, bevor er schreibenden Zugriff bekommt. Hm, wie soll denn die Liste aussehen? Ich würde eher sagen, dass man das Live-Schreiben generell untersagt, um Missgeschicke zu vermeiden. Man könnte aber auch sagen, man muss ich als User erst einen bestimmten Rang verdienen, um den Bestätigungsbutton auszublenden, also eine gewisse Erfahrung im Umgang mit Potlach vorweißen. Ach ja, bevor die Freiheitsliebenden wieder aufschreien: Potlach ist vor allem als Einsteigerprodukt gestaltet und sollte daher eben genau NICHT sofort die Änderungen übernehmen, da ein völliger Neuling leicht alles kaputt machen kann. Deshalb auch mein Vorschlag mit den Rängen. Bitte mach keine Annahmen darüber, wozu ein Editor gedacht ist oder wozu er verwendet werden sollte - insbesondere nicht, wenn du ihn selbst gar nicht verwendest. Die ganze Diskussion entzündet sich an der Behauptung, dass unbedarfte Potlatch-User die Geodaten zerstören, weil sie direkt schreiben. Ist diese Behauptung überhaupt schon mal auch nur ansatzweise belegt worden? Und was ist mit JOSM-Usern, die die Geodaten ebenso unabsichtlich zerstören können - sei es, weil sie ungenaue GPS-Daten nutzen, weil ihr WPS-Server die falsche Projektion liefert, weil die Luftbilder nicht georeferenziert sind - oder weil sie schlicht andere Ansichten über die Art und Weise haben, wie Dinge zu taggen sind, als andere Teilnehmer? Ganz ehrlich: Hier wird ein Wirbel um etwas gemacht und das festgemacht an der angeblich falschen Verhaltensweise eines Editors - aber die Augen fest verschlossen vor dem viel grundsätzlicheren Problem. Stattdessen wird drüber nachgedacht, willkürliche Eingangshürden aufzubauen, nur damit die Elite bloß nicht von einfachen Usern gestört wird. Hätte Wikipedia so gearbeitet, wäre das Konzept direkt gescheitert, würde ich mal behaupten. Liefert Belege für die These, Potlatch-User würden unabsichtlich die Karte zerstören, oder laßt sie ein für allemal fallen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] mime type für gpx
Teste gerade die Brauchbarkeit der jsr311 (jersey, Java REST Implementierung) und habe mich für mein cycleroute Projekt erstmal für @ProduceMime(application/gpx+xml) ... .header(Content-Disposition, attachment; filename=+fname+\); entschieden. Zumindest im FF tut es was es soll. Ich hoffe ich kann es bald zugänglich machen. Das Problem ist, dass du einen nichtregistrierten Mimetyp verwendest. Das ist nicht standardkonform. Wenn du eigene Mimetypen benutzen willst, dann stelle - standardkonform - doch bitte ein x- vor den selbstausgedachten Teil. Richtig wäre dann z.B. application/x-gpx+xml. Oder bemühe dich um die Registrierung des offiziellen Mimetyps bei der IANA. Dass Browser mit Download reagieren, ist normal. Das tun sie immer, wenn sie einen ihnen unbekannten Mimetyp vorgesetzt bekommen. Kein Browser kennt gpx+xml - aber genausowenig kennt er x-gpx+xml, der Effekt ist also solange derselbe, wie der Browser keine Applikation kennt, die sich für diesen Mimetyp explizit registriert hat. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] mime type für gpx
Till Maas schrieb: On Wed May 21 2008, Sven Rautenberg wrote: Oder bemühe dich um die Registrierung des offiziellen Mimetyps bei der IANA. Weißt Du, wie gut und schnell das klappt? Das Formular dafür wäre ja hier: http://www.iana.org/cgi-bin/mediatypes.pl Ich habe keine Ahnung, hab das noch nie gemacht. Meine Mimetypen waren alle schon registriert: text/html, text/css und text/javascript. ;) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSM-Beitrag im WDR
Raphael Studer schrieb: Ich hätte auch Interesse! Ich denkt, alle die hier mitlesen hätten Interesse daran, wenn man den Beitrag irgendwo herunter laden kann. Wenn das natürlich Rechtlich etwas schwierig ist, dann wär ich froh, ich würden den Beitrag persönlich erhalten. Grüsse Raphael Der ganz offizielle Link; http://www.wdr.de/mediathek/html/regional/2008/05/20/lokk_03.xml Die Öffis sind doch schließlich auch im Netz. :) Wie lange der Link gilt, kann ich mangels Erfahrung nicht sagen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] mime type für gpx
Harald Kirsch schrieb: Hallo, weiß jemand, welchen mime type eine GPX-Datei sinnvollerweise haben sollte, wenn der Server sie an den Browser ausliefert und sie dort typischerweise auf Platte gespeichert werden soll? Ist text/xml die richtige Wahl? Falls das noch niemand beantwortet hat (ich bin mit dem Lesen hinterher)... Ein guter Mime-Typ, um Downloads zu provozieren, ist application/x-msdownload, den Typen kennt kein Browser, und auch der IE wird seine Autoerkennung zurückhalten (weshalb der eigentlich viel bessere Typ application/octet-stream leider ungeeignet ist). text/xml kennzeichnet zwar den tatsächlichen Inhalt der Datei korrekt, aber da heutzutage eigentlich alle Browser (und auch der IE) XML verstehen, werden sie diese Datei dem Benutzer nicht zum downloaden anbieten, sondern versuchen, das XML selbst darzustellen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] mime type für gpx
Christoph Eckert schrieb: Moin, text/xml kennzeichnet zwar den tatsächlichen Inhalt der Datei korrekt, aber da heutzutage eigentlich alle Browser (und auch der IE) XML verstehen, werden sie diese Datei dem Benutzer nicht zum downloaden anbieten, sondern versuchen, das XML selbst darzustellen. aus welchem Grunde eigentlich?!? Egal um was für ein XML es geht, meist will ich das doch gar nicht am Bildschirm lesen sondern irgendwie weiterverwurschten, oder? Browser verstehen es durchaus, auch nacktes XML mittels CSS ansehnlicher darzustellen, oder mittels XSL sogar clientseitig transformieren. Deshalb: Wenn man einen Download will, ist standardtheoretisch zwar application/octet-stream richtig, browserübergreifend funktioniert aber nur application/x-msdownload, weil der IE dem richtigen Mimetyp (und insgesamt noch ein paar weiteren, u.a. auch text/plain) mißtraut (zumindest in den Versionen bis 7), und durch Inhaltsanalyse versucht, einen besseren Mimetyp zu finden, der dann verwendet wird. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Oeffnungszeiten (hier: Zoo)
Guenther Meyer schrieb: Was ich fuer wenig zielfuehrend halte, ist der Versuch einer allgemeingueltigen, rechnerlesbaren Formatdefinition fuer Oeffnungszeiten. Prinzipbedingt werden da mit jedem zusaetzlichen Syntaxelement so 10% Syntaxfehler eingegeben werden, so dass man am Ende schlechter dasteht, als wenn man einfach versucht, das zu parsen, was Menschen normalerweise so schreiben, wenn sie anderen Menschen Oeffnungszeiten kommunizieren wollen. dem kann ich nicht ganz zustimmen. wenn man von anfang an ein sauberes format definiert, das auch problemlos maschinenlesbar ist, macht man es potentiellen entwicklern wesentlich einfacher, anwendungen zu schreiben. und dann wird genau das gemacht, wozu die daten da sind; sie werden genutzt. ausserdem bin ich immer noch der meinung, dass man es als einsteiger einfacher hat, wenn klare vorgaben da sind, nach denen man sich richten kann, so nach dem motto mach es su, und es wird genutzt/angezeigt/sonstwas... Das ist aber ja genau das Problem: Öffnungszeiten sind komplex. Wir hätten beispielsweise: - immer offen - Mo-Sa 0-24 Uhr - Mo-Fr 9-18 Uhr, Sa 9-13 Uhr - jeden ersten Dienstag im Monat 15-18 Uhr - Sonn- und Feiertags 12 - 15 Uhr - Feiertags geschlossen - Notdienst am 23./24.05.08 18-7 Uhr Es dürfte ziemlich schwierig werden, für diese Informationen ein maschinenlesbares Format zu finden, welches gleichzeitig auch noch menschenlesbar ist, außerdem menschengenerierbar, und welches wirklich alle weltweit auftretenden Öffnungszeitenfälle abdeckt. Vor allem: Wie willst du JETZT ein maschinenlesbares Format vorgeben für noch nicht existierende Applikationen, ohne zu wissen, was diese Applikationen später vielleicht wirklich benötigen? Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Generelle Fragen
Jonathan Schlüßler schrieb: Die Siedlung in der ich wohne ist größtenteils eine 30-Zone. Daher hab ich allen Straßen das Tag maxspeed=30 angehängt. Jetzt gibt es allerdings eine Straße, von der die ersten Meter noch keine 30-Zone ist, daher habe ich diese Straße zweimal angelegt, einmal mit maxspeed=30 und einmal ohne. Allerdings sieht dies wenn es gerendert wird nicht sonderlich schön aus, weil in dem recht kleinen Nicht-30-Zonen Stück erneut der Name der Straße angezeigt wird. Ist meine Lösung so die Richtige, oder macht man das anders? Das Problem liegt beim Renderer, nicht beim Tagging. Ich würde so eine Teilstraße auch so taggen. Es geschieht ohnehin an sehr vielen Orten, weil z.B. auch Brücken so getaggt werden müssen - oder Straßen mit baulicher Trennung der Fahrtrichtungen, die laufen parallel doppelt. Eine weitere Ungewissheit habe ich bei kleinen Zufahrtsstraßen. Diese Straßen gehören alle zu der Hauptstraße und sind durch ein kleines Straßenschild wo nur die Hausnummern draufstehen (zb. 45-47c) gekennzeichnet, gefolgt von einem Sackgassensymbol, gekennzeichnet. Sollte man diese Straßen mit mappen? Ja, in OSM gehört alles rein, was ein Weg ist - auch Zufahrtstraßensackgassen. Welche Geschäfte sollte man eintragen? Nur Geschäfte mit größerem Interesse (zb Supermärkte) oder auch das Tapetenfachgeschäft im Nachbarhaus, die Fahrschule um die Ecke, ...? Das ist eine Frage des persönlichen Geschmacks. Ich selbst würde Geschäfte nicht mit Priorität eintragen, Straßen sind wichtiger. Ich habe mir die Diskussion über die Hausnummern angeguckt, sollte man da jetzt sofort schon anfangen von jeder Straße die markanten Häuser (Erstes / Letztes, Kreuzungshäuser) mit Hausnummern einzuzeichen? Oder doch besser gleich alle Häuser? Die Diskussion ist erst ganz am Anfang, noch weiß doch niemand, wie das genau funktionieren soll. Also keine Hausnummern, wenn du vermeiden willst, später nochmal alles umzuändern. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mapping einer Kreuzung
Hallo, korrekt wäre an den Node tatsächlich beides zu setzen. Bei welchem Programm/Renderer verschwindet denn die Ampel? Am Ende geht es ja darum die Daten zu sammeln, nicht eine schöne Karte zu rendern. Die Karte ist nur eine Dreingabe. Das geht aber nicht, weil ich nur highway=affic_signals *ODER* highway=ossing angeben kann. Ist mir auch schon aufgefallen, dass das ein Problem werden wird. Ich hab gerade Schwierigkeiten, mir vorzustellen, wie sich dass den in der realen Welt[TM] kombinieren soll, Ampel und Zebrastreifen. Also entweder habe ich an dem Ort nur einen Zebrastreifen, oder ich hab das Upgrade eines Zebrastreifens, nämlich eine Ampel (Trampelampel mit Fußgängerzwangsanholungsknopf, oder so ähnlich). Sprich: Der Zebrastreifen ist mir als Fußgänger und Autofahrer egal, weil's die Ampel gibt - auch wenn der Straßenbelag dort streifig weiß bemalt ist. Und selbst wenn die Ampel nur zeitweilig in Betrieb ist, würde ich nur die Ampel taggen Irgendwo hatte ich glaub mal gesehen, dass jemand vorschlägt: highway=ossing, sowie crossingtype=affic_signals oder sowas zu verwenden, wobei crossingtype dann auch noch diverse andere Werte haben kann (pelicancrossing etc). highway=crossing;traffic_lights wäre die verlautbarte korrekte Zusammenfassung beider Tags für den node. Dummerweise macht so eine Zusammenfassung oft Probleme beim Rendering, weil die Renderer noch nicht beigebracht bekommen haben, einen Tag dieses Schemas wieder auseinanderzunehmen und einzeln zu behandeln. Gilt zumindest für das Wegezeichnen, wo sich Wege, die zufällig service;unclassified o.ä. abkriegen, auf der Karte in Luft auflösen. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Mapping einer Kreuzung
Ich hab gerade Schwierigkeiten, mir vorzustellen, wie sich dass den in der realen Welt[TM] kombinieren soll, Ampel und Zebrastreifen. und ich habe Schwierigkeiten, mir vorzustellen, dass sich ein anderer das nicht vorstellen kann. :-) Ich glaube, mal gelernt zu haben, dass die Ampel (eigentlich Lichtsignalanlage) Vorrang vor festen Verkehrszeichen hat. Ist die Ampel in Betrieb, gilt die Ampel. Ist die Ampel nicht in Betrieb, gilt das feste Verkehrszeichen. Für den Autoverkehr kann es das Vorfahrtszeichen sein, für den Fußgänger kann es der Zebrastreifen sein (wenn es wirklich einer ist und nicht nur eine breite Begrenzungslinie). Ja klar, die grundsätzliche Idee leuchtet mir ein - ich erkenne nur nicht den Sinn darin, beides zu kombinieren. Entweder reicht das Geld und das Verkehrsaufkommen nur für einen Zebrastreifen. Oder es reicht für eine Ampel. Warum aber sollte man eine Ampel installieren, die nur zu bestimmten Zeiten aktiv ist, und sich nicht bedarfsweise durch Knopfdruck eines Fußgängers aktivieren läßt - und stattdessen die wenig eingängige Regelung findet: Wenn Ampel an und Fußgänger vorhanden, dann haben Autos bei Grün Vorfahrt und bei Rot anzuhalten. Wenn Ampel aus und Fußgänger vorhanden, dann haben Autos anzuhalten. Wenn das mal nicht zu einem Unfallschwerpunkt führt... Abgesehen davon geht's in der Fragestellung ja nicht darum, was verkehrstechnisch sinnvoll ist, sondern was schlauerweise in die Karte eingetragen wird. Ich plädiere für Ampel, weil's das höherpriorisierte Verkehrshindernis ist. Es hindert sowohl Fußgänger als auch Autofahrer unter Umständen eine längere Zeit am Fortkommen. Dass der Verkehrsteilnehmer dort unter Umständen auf eine alternative Verkehrssituation treffen kann, erachte ich erstmal als unerheblich - auch für Navigationszwecke. Wie werden vorgelagerte Zweitampeln behandelt, die vor Kreuzungen einen Haltestellenbereich freihalten sollen, wenn eine Straßenbahn in diesen Bereich eingefahren ist? Und wie werden Ampeln behandelt, die ohne Kreuzung auf einer Fahrspur stehen und solche Haltestellenbereiche erzeugen sollen Es gibt aktuell ja keine Möglichkeit, Ampeln detaillierter zu taggen als Node hat Ampel. Welche Fahrspuren damit in welcher Fahrtrichtung für wielange zu welcher Uhrzeit und in welcher Taktung geregelt werden, ist derzeit nicht abbildbar. Klar würde es sicher ein reizvolles Experiment sein, dem Navigator auch die Grünphasentaktung der Ampeln beizubringen, um wirklich optimalen Verkehrsfluß (mit Geschwindigkeitsvorschlag für Grüne Welle) zu erreichen - diese Projektphase würde ich aber erst beginnen, wenn Deutschlands Straßen vollflächig erfaßt sind. :) Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Vereinheitlichung bei S-, U-, Stadt- und Straßenbahn
Heiko Jacobs schrieb: Versuche mal eine gleichzeitige Diskussion hier, im Wiki http://wiki.openstreetmap.org/index.php?title=lk:De:Key:railway und im Forum http://forum.openstreetmap.org/viewtopic.php?pid81#p1681 Drei Orte, vier Ergebnisse - würde ich tippen. :) Raum Hamburg: - S-Bahn-ähnlicher Verkehr der AKN mit Dieseltriebwagen Die AKN fährt dieselelektrische Triebwagen für den Personennahverkehr, sowie Diesellokomotiven für den Güterverkehr. Die Triebwagen sind umschaltbar auf S-Bahn-Betrieb mit Speisung aus der seitlichen Stromschiene - dies wird zwischen Eidelstedt und Hauptbahnhof für einzelne Züge genutzt, die planmäßig bis dort fahren. Insofern: Mischbetrieb, irgendwie. Und zwar in jeder Hinsicht. Die Triebwagen sind einsetzbar als S-Bahn, wenn sie auf der S-Bahn-Strecke fahren, das eigene AKN-Gleisnetz wird hingegen nicht nur von den Triebwagen, sondern auch von Güterzügen genutzt (allerdings vornehmlich nachts). railway=light_rail Ulzburg-Eidelstedt railway=rail Ulzburg-Norderstedt uneinheitlich also ab Ulzburg nordwärts fehlt... Angesichts des Güterverkehrs halte ich ein Tagging mit railway=rail für gerechtfertigt und hab' das kurzerhand mal korrigiert. Die Güterzüge werden in Eidelstedt auf das DB-Netz ausgefädelt. Dort würde ich ja auch gerne noch mehr Strecke aus dem Yahoo-Satbild hinmalen, aber irgendwas verursacht, dass die Bilder nur noch riesenpixelig angezeigt werden. Sehr unangenehm. U-Bahn-Verkehr auf drei Strecken mit seitlicher Stromschiene und Gleichstrom railway=bway Demnächst vier Strecken... :) Straßenbahn 1978 stillgelegt Leider... Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Packstation
A.g.A. ;) möchte ich gern diese Packstation (DHL) mappen. Spontan würde ich amenity=ckstation vorschlagen. Gibt es andere Ideen? Aus Gründen der Vollständigkeit sollte noch PLZ und die Nummer hinzukommen: amenity=ckstation ref=X (= Nummer der Packstation) zip=YYY(= PLZ der Packstation) + Betreiber Hallo, was wäre denn zu halten von amenity=post_office name=Packstation operator=DHL etc... Ich würde im Zweifel immer erstmal mit vorhandenen Tags das Ziel zu erreichen versuchen, und eine Packstation ist nunmal ein automatisierter Postshop (gibt zwar die Dienstleistung, aber kein Personal). Vorteil: Vorhandene Tags haben oft schon ein Icon. Und auch bei derzeitigen Icons für post_office steht ja nicht dabei, welche Angebote dort tatsächlich anzutreffen sind - die Überraschung trifft den Suchenden also sowieso beim ersten Kontakt. Da kann wenigstens der Name Packstation helfend eingreifen. Alternativ wäre sowas wie post_office_unmanned oder automated_post_office naheliegend. :) Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flyer-Entwurf
Frederik Ramm schrieb: Mit der Verwendung eines Original-Werbefotos sehe ich kein Problem, denn selbst wenn der Hersteller das verbieten wollte (was denkbar, aber unwahrschenlich ist) niemand kann mir nachweisen, dass ich nicht tatsaechlich das Geraet in einem Fotostudio fotografiert habe... Sorry, aber ist diese Herangehensweise an Lizenzen nicht etwas ... komisch angesichts der Tatsache, dass du bei einem Projekt mitmachst, dass genau deswegen existiert, weil sich Menschen eben an Lizenzen halten, und eben gerade NICHT Google-Maps kopieren? Wenn $Hersteller dir oder der Allgemeinheit die Erlaubnis gibt, Produktfotos für $Beliebiger_Einsatzzweck zu verwenden - ok. Wenn das in Form einer expliziten Einzelgenehmigung geschieht - noch viel besser. Aber die Methode Ich nehm's einfach mal, mir kann niemand was nachweisen ist einfach unterirdisch. Denn es dürfte dir problemlos nachzuweisen sein, weil du die Ausleuchtung und Nachbearbeitung etc. nie exakt identisch hinkriegst. Und wenn du das doch hinkriegen würdest, könntest du ja problemlos (durch Rohmaterial) auch den Nachweis führen, dass du es selbst fotografiert hast. Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
