Re: [Talk-de] Verkehrszeichen abschaffen!
André Reichelt schrieb: Martin Koppenhoefer schrieb: allerdings stand in den Beitrag, dass in der besagten Ortschaft neben Schildern auch Spuren abgeschafft wurden, von Spurwechsel kann daher dort zumindest keine Rede mehr sein. 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. 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. Und noch ein Aspekt kommt bei Straßenschildern hinzu. Sie sollen nicht-ortskundigen einen Eindruck von der Verkehrssituation vermitteln. 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. Grüße signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Harz geklaut
Frederik Ramm wrote: Mehr als 1000 punkte in eine relation zu packen, ist momentan auch nicht wesentlich besser. Das uploaden dauert recht lang, wenn ich beispielsweise einen weg der d11-relation hinzufügen will, in der mittlerweile so ca. 1300 schnipsel stecken. Es spricht sehr viel dafuer, diese Relation dann auch aufzuteilen. Es ist fuer die allermeisten Anwendungen relativ wurscht, ob es jetzt eine Relation d11 nord und eine d11 sued gibt oder ob alles in einer steckt. Hier würde es sich sogar anbieten, statt des D11 nord eine Relation Radfernweg Berlin-Kopenhagen (B-KO) zu erstellen[*] und diese als Member in die Relation D11 zu packen. Ich habe erst durch OSM bemerkt, dass es den D11 überhaupt gibt, obwohl ich diesen Weg schon von Berlin bis Rostock komplett gefahren bin. Dort ist aber nur Berlin-Kopenhagen ausgeschildert. Gruß Andreas [*]Diese Relation gibt es sogar schon. Nur müssten die entsprechenden Ways aus dem D11 wieder rausgelöscht werden, was ich bei Gelegenheit mal tun kann, sofern mir niemand zuvorkommt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM: Relation(route) aufspalten, Tei lwege löschen, neu zusammen setzen
Toni Erdmann schrieb: Karl Eichwalder schrieb: Toni Erdmann [EMAIL PROTECTED] writes: Na, das scheint bei 1400 Elementen in der Relation nicht so einfach zu sein. Ja. Es geht nur mit tricks: Straße komisch benennen (z.B. xxx000richtiger name). Dann in der relation nach xxx000 suchen (auch das ist bei 1400 elementen schwierig), löschen und rückbennenen. Cool, auf das Naheliegende kommt man zuletzt. Guter Trick. So brauche ich nicht mehr zwischen Potlatch und JOSM jonglieren. Danke für den Tipp. Schöner wäre es, wenn die aktuell markierten Ways im Relations-Editor auch angezeigt würden. Wäre das Ganze trival (für mich), hätt ich es schon mal eingebaut bzw. nen Patch geschickt. Gruss, Elwood ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Neues Tool: OSM Mapper
Das Tool ist wirklich hübsch! Da steckt ne ganze Menge Intelligenz drin, würd ich mal behaupten. Ich frag mich gerade aus welchem Grund diese Firma das gemacht hat. Sie wollen ja kein Geld oder sonst was. Einfach registrieren und fertig. Womit verdienen die ihr Geld und warum arbeiten die derart an OSM? Grüße signature.asc Description: OpenPGP digital signature ___ 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] JOSM: Relation(route) aufspalten , Teilwege löschen, neu zusammen setzen
On Sun, 20 Jul 2008, Frank Gruender wrote: Na, das scheint bei 1400 Elementen in der Relation nicht so einfach zu sein. Ja. Es geht nur mit tricks: Straße komisch benennen (z.B. xxx000richtiger name). Dann in der relation nach xxx000 suchen (auch das ist bei 1400 elementen schwierig), löschen und rückbennenen. Cool, auf das Naheliegende kommt man zuletzt. Guter Trick. So brauche ich nicht mehr zwischen Potlatch und JOSM jonglieren. Danke für den Tipp. Schöner wäre es, wenn die aktuell markierten Ways im Relations-Editor auch angezeigt würden. Wäre das Ganze trival (für mich), hätt ich es schon mal eingebaut bzw. nen Patch geschickt. Wie wäre es einfach mal mit einem Update? Seit einer ganzen Weile gibt es analog zu Ausgewählte Elemente der Relation hinzufügen nämlich auch Ausgewählte Elemente aus Relation entfernen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Geschlossene Ortschaften
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, ab und zu finde ich es lustig, wenn einige ihre Intelligenz einbringen, um meine Gedankengänge zu zerreden. Ab und zu nervt es auch. Wird denn ein Ortseingangsschild auf die Grüne Wiese gesetzt oder an eine Node eines Ways? Und besitzt dieser Way eine Richtung? Ich bin neu hier. Vielleicht sollen die Pfeile am Way nur oben und unten begründen? Rolf -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Dirk Stöcker Gesendet: Sonntag, 20. Juli 2008 00:20 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Geschlossene Ortschaften On Sat, 19 Jul 2008, Rolf Gehring wrote: ein Ortseingansschild ist immer fahrtrichtungsabhängig. Entweder beginnt in Fahrtrichtung hinter einem Ortseingangschild ein Ort oder es endet in Fahrtrichtung hinter einem Ortsausgangsschild ein Ort. Entweder beginnt entgegen der Fahrtrichtung hinter einem Ortseingangschild ein Ort oder es endet entgegen der Fahrtrichtung hinter einem Ortsausgangsschild ein Ort. Dabei ist egal, ob an der einen Stelle ein Ort endet und ein anderer beginnt. Tag muss die Verhältnisse der Tag in jedem Fall realitätsnah abbilden. Oder sehe ich etwas falsch? Nur klärt das die Frage nicht. Bei Ortseingang/Ortsausgang kann man mit etwas Fantasie noch klären, auf welcher Seite der Ort ist (z.B. Strassentypen oder Straßennamen, ...). Bei einem Ortswechsel hilft es nichts ein Namenstag and den Punkt zu kleben, weil nicht klar ist, was damit bezeichnet wird. Eine Richtung und damit links/rechts oder vorn/hinten gibt es für einen Punkt auch nicht. Ciao -- http://www.dstoecker.eu/ (PGP key available) -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) Charset: iso-8859-1 wj8DBQFIgx23X/cdferISG0RAt54AKDCSiX7TmFlmFNuPaOCjCdyhjiGeQCgpr3Y 9wP05muZLT5H6ShbstC4THQ= =sHT3 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Geschlossene Ortschaften
Rolf Gehring [EMAIL PROTECTED] wrote: Wird denn ein Ortseingangsschild auf die Gr?ne Wiese gesetzt oder an eine Node eines Ways? Und besitzt dieser Way eine Richtung? In meinem Originalvorschlag gab's ja noch die eigentliche Grenzlinie, die die Straszen kreuzt und dort, wenn in der Realitaet vorhanden, hat der Knoten auch noch tags. Ich habe aber auch shcon dort, wo ich die Grenzlinie noch nicht festgelegt hatte, die Ortstafeln auf der gruenen Wiese geparkt... Nur kl?rt das die Frage nicht. Bei Ortseingang/Ortsausgang kann man mit etwas Fantasie noch kl?ren, auf welcher Seite der Ort ist (z.B. Strassentypen oder Stra?ennamen, ...). Bei einem Ortswechsel hilft es nichts ein Namenstag and den Punkt zu kleben, weil nicht klar ist, was damit bezeichnet wird. Eine Richtung und damit links/rechts oder vorn/hinten gibt es f?r einen Punkt auch nicht. Ein solcher Ortswechsel wuerde auf zwei boundary=city-limit liegen. Jede mit eigenem Namen, damit waere die Zuordnung von ways innerhalb einer solchen boundary eindeutig. Oder man fuegt Wegstuecke ueber Relationen zusammen, wie man es wohl auch mit anderen boundaries vor hat. Der Knoten mit der einzelnen Ortstafel hat ja primaer das Ziel, dort ein Symbol hinzusetzen, das vermutlich unbeschriftet sein wird wg. zu klein? Und wenn doch, enthaelt name halt das, was man da in so einem Falle haben will... Naechste Woche werde ich da noch weiter tuefteln an der Idee... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Hallo, ich möchte euch auf einen Vorschlag (Proposal) zum Thema in Bau befindliche Objekte und nicht mehr benutzte Objekte aufmerksam machen: http://wiki.openstreetmap.org/index.php/Proposed_features/Status Die Idee ist, solche Objekte mit einem status=construction/disused/abandoned/preserved zu kennzeichnen. Beispiele: Nicht mehr genutzte Schienen: railway=[Railway-Typ] status=disused (Man beachte, dass – im Gegensatz zu railway=disused – die Art der Schiene wie gewohnt angegeben werden kann.) Im Bau befindliche Autobahn: highway=motorway status=construction Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Vor allem wäre das status-Tag explizit dafür gedacht, auf alles anwendbar zu sein – also auch Gebäude, Flugplätze, Militäranlagen etc. Damit hätten wir eine übersichtliche, einheitliche Lösung zu dem Thema – bisher existieren ja nur Insellösungen für highway und railway. Der Vorschlag ist ab heute in der RFC-Phase („Proposed“), Einwände und Verbesserungen sind also erwünscht. Grüße, Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tagwatch
On Fri, 18 Jul 2008, Christoph Eckert wrote: http://tagwatch.stoecker.eu/ habe ich basierend auf Jörg's TagWatch-Skript eine neues TagWatch aufgesetzt, welches ab jetzt automatisch aktualisiert werden wird (hoffentlich). phantastisch, danke! Und jetzt sind viele Bugs gefixt. Und außerdem auch alles täglich neu :-) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Linienglättung, Beispiel
Sowohl als auch. Ich zeichne das Luftbild bzw. mache die GPS-Korrekturen nicht mit JOSM. Daher zeichne ich die Tracks teilweise mit normalen Polylinien und teilweise mit Spline-/Bezier-Zeichentools ein. Da OSM nichts mit Bezier-Kurven anfangen kann, muss ich diese auf Punkte runterrechnen. Hier bleibt mir die Möglichkeit, viele Punkte (hohe Kurvengenauigkeiten) oder wenig Punkte (Zackelig) zu arbeiten. Es ist also nicht nur Interpolation... in dem Fall bin ich auch eher für die Variante mit mehr Punkten (nicht übertreiben), leider kann ich die Beispieldatei nicht mehr ansehen (zu alt). Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Tordanik schrieb: http://wiki.openstreetmap.org/index.php/Proposed_features/Status Die Idee ist, solche Objekte mit einem status=construction/disused/abandoned/preserved zu kennzeichnen. Zumindest ein Datumstag wäre auch nicht schlecht. Also wann der Statuswechsel stattgefunden hat (bie disused) bzw wann er voraussichtlich stattfinden wird (bei construction). Damit könnte man abbilden Kaserne rottet seit dem Abzug der Russen 1993 oder Autobahnabschnitt wird voraussichtlich August 2009 freigegeben. Als Krönung dann zeitweilig construction für Straßen die im Rahmen einer größeren Baumaßnahme über mehrere Monate komplett nicht verfügbar sind. Nur dann müsste man sich auch noch Gedanken über das Zeitformat machen, damit dort nicht später x-mal nachgebessert werden muss falls Leute anfangen, den Verkehrsfunk abzubilden ;-). Also vielleicht gleich ISO in beliebiger Präzision in GMT? Also 200807201158? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Geschlossene Ortschaften
On Sun, 20 Jul 2008, Rolf Gehring wrote: ab und zu finde ich es lustig, wenn einige ihre Intelligenz einbringen, um meine Gedankengänge zu zerreden. Ab und zu nervt es auch. Vielleicht solltest Du Dich mit dem Datenmodell mal genauer beschäftigen statt die Intelligenz anderer anzuzweifeln? Wird denn ein Ortseingangsschild auf die Grüne Wiese gesetzt oder an eine Node eines Ways? Und besitzt dieser Way eine Richtung? Ich bin neu hier. Vielleicht sollen die Pfeile am Way nur oben und unten begründen? Ein Knoten ist ein Knoten. Eine Kante ist eine Kante. Eine Kante/Way ist gerichtet über die Reihenfolge seiner Knoten. Ein Knoten selbst hat keine Richtung und kann außerdem zu mehreren Ways gehören. Nun ist es schon ein Problem mit den gerichteten Tags eines Ways, weil man ja die Richtung drehen kann, ohne dass die Tags beeinflußt werden (JOSM hat seit 2 Tagen einen Patch der das etwas einzudämmen versucht). Wie aber bitteschön willst Du jetzt eine Richtungsinformation an einem eindimensionalen Punkt festmachen? Außerdem habe ich i.d.R. an einem Ortseingangschild zwei Wege und nicht einen, weil nämlich am Ortseingangschild meist auch der Straßenname wechselt. Damit würde Deine Behauptung nichtmal funktionieren, wenn man das Prinzip eine Kante hat Knoten rückwärts betrachtet. Andersrum ist es nämlich wie gesagt nicht eindeutig. Es gibt nur drei brauchbare Lösungen: a) Relation: Definieren von Way vorher + Ortsname und Way nachher + Ortsname b) Fläche: Definieren der Ortsflächen c) Heuristik: Erkennen der Orschaften über Koordinate des Namens, Straßentypen, ... Die Fälle a und b sind exakt, allerdings finde ich die Lösung a grausam und bei b weiß ich nicht, wo ich die Daten herbekommen soll. Fall c wird bei komplizierteren Ortslagen versagen. Hier in der Gegend gibt es Fälle, wo ich auf einer Straße dreimal durch Ortseingang/Ortsausgang eines Dorfes komme. Das kann keine Heuristik vernünftig erkennen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] proposal Abstimmzeit
Hi, Ich habs jetzt einfach mal wieder auf Proposed gesetzt und bis 22.7. nachlaufen lassen. Der Benutzer Nickvet419 war der Meinung, dass die Bedingungen für Approved bereits erfüllt gewesen wären obwohl ganz klar geregelt ist, dass diese Angaben erst nach Ablauf der Wahlzeit greifen. Find ich einen voellig unnoetigen Formalismus. Bei uns ist nichts ganz klar geregelt, und mit solcher Paragraphenreiterei wirst Du eher Leuten auf die Fuesse treten als irgendjemandem etwas nuetzen. Gegner eines Proposals koennen zu jedem beliebigen Zeitpunkt *nach* Ablauf einer Abstimmung immer noch ihre Argumente zu Gehoer bringen. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [EMAIL PROTECTED] ... NARF!
On Friday 11 July 2008 20:07:47 Jens Müller wrote: OK, ein Gentoo-Ebuild wäre toll ;-) gibts hier im overlay: https://home.ub0r.de/svn/gentoo/overlay kann aber keine aussagen darüber machen :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Johann H. Addicks schrieb: Zumindest ein Datumstag wäre auch nicht schlecht. Also wann der Statuswechsel stattgefunden hat (bie disused) bzw wann er voraussichtlich stattfinden wird (bei construction). Ja, das wäre in diesem Zusammenhang brauchbare (und teils sogar in gedruckten Karten übliche) Information. Ich hatte auch daran gedacht, so etwas gleich mit im Proposal aufzunehmen, das dann aber bleiben lassen, da a) die Statusinformationen auch allein schon verwendet werden können und der Datumseintrag ohnehin in einem eigenen Tag am besten aufgehoben ist b) bei umfangreicheren Vorschlägen oft solche „Ich bin für X, aber Y lehne ich ab, falls Z durchkommt“-Abstimmungen entstehen (vgl. Proposal zu highway=path …) c) das Zeitformat wohl noch einiger Diskussion bedarf und tagübergreifend relevant ist. Insofern wäre dieses Feature ein gutes Folgeproposal. Nur dann müsste man sich auch noch Gedanken über das Zeitformat machen, damit dort nicht später x-mal nachgebessert werden muss falls Leute anfangen, den Verkehrsfunk abzubilden ;-). Also vielleicht gleich ISO in beliebiger Präzision in GMT? Also 200807201158? ISO wäre auch mein Favorit. Man könnte ggf. in Erwägung ziehen, Trennzeichen einzusetzen um die Lesbarkeit zu erhöhen, in dem Punkt bin ich aber eher unentschieden. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] www.openstreetmap.org - Export: Wunsch cycle map
Moin, ich wünsche mir... ;-) das ich auch auf www.openstreetmap.org Cycle Map Karten Exportieren kann. - alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] kann osmarender relationen berücksicht igen?
Hallo, ich möchte für eine Radfahrt mir ein Satz Karten erzeugen. Ist es möglich das ich z.B.im osm-map-features-z16.xml eine Regel erstelle welche ways in Relationen findet. Ich möchte alle Wege, welche Mitglied der Relation k=ref v=D11 mit einer dünnen roten versehen. dank vorab, alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] kann osmarender relationen berücksicht igen?
On Sunday 20 July 2008 15:34:20 Alexander Eickhoff wrote: Hallo, ich möchte für eine Radfahrt mir ein Satz Karten erzeugen. Ist es möglich das ich z.B.im osm-map-features-z16.xml eine Regel erstelle welche ways in Relationen findet. in osm-map-features-z17.xml ist so eine Regel ja enthalten, ;-) jetzt soll auch noch die rev gerendert werden... mal schauen sorry, alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] JOSM: Relation(route) aufspalten, Tei lwege löschen, neu zusammen setzen
Dirk Stöcker schrieb: On Sun, 20 Jul 2008, Frank Gruender wrote: Na, das scheint bei 1400 Elementen in der Relation nicht so einfach zu sein. Ja. Es geht nur mit tricks: Straße komisch benennen (z.B. xxx000richtiger name). Dann in der relation nach xxx000 suchen (auch das ist bei 1400 elementen schwierig), löschen und rückbennenen. Cool, auf das Naheliegende kommt man zuletzt. Guter Trick. So brauche ich nicht mehr zwischen Potlatch und JOSM jonglieren. Danke für den Tipp. Schöner wäre es, wenn die aktuell markierten Ways im Relations-Editor auch angezeigt würden. Wäre das Ganze trival (für mich), hätt ich es schon mal eingebaut bzw. nen Patch geschickt. Wie wäre es einfach mal mit einem Update? Seit einer ganzen Weile gibt es analog zu Ausgewählte Elemente der Relation hinzufügen nämlich auch Ausgewählte Elemente aus Relation entfernen. Erwischt! ;-) Gruß, Toni ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Für landuse Knoten von Strassen verwen den?
Rolf Gehring schrieb: könnte mal einer der Verfechter der Flächendarstellung von Straßen den wirklichen Hintergrund dieser Aktivitäten etwas erläutern? es wird an Geräten geforscht, die Blinden über einen Gürtel die Richtung weisen (vibration). dafür braucht man eine karte, die dezimeter genau arbeitet. und wo vor allem fußwege als flächen eingezeichnet sind. ich hab das letztens in der c't gelesen. aber ansonnsten binb ich auch eher für eine abstrakte karte... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Für landuse Knoten von Strassen verwe nden?
On Sun, 20 Jul 2008, Josias wrote: Rolf Gehring schrieb: könnte mal einer der Verfechter der Flächendarstellung von Straßen den wirklichen Hintergrund dieser Aktivitäten etwas erläutern? es wird an Geräten geforscht, die Blinden über einen Gürtel die Richtung weisen (vibration). dafür braucht man eine karte, die dezimeter genau arbeitet. und wo vor allem fußwege als flächen eingezeichnet sind. ich hab das letztens in der c't gelesen. aber ansonnsten binb ich auch eher für eine abstrakte karte... Der c't-Artikel hat ganz vergessen, dass das zwar schön und toll und was weiß ich nicht ist, aber auf keinen Fall praktikabel. Niemand ist in der Lage derartige Daten auf dem aktuellen Stand zu halten oder überhaupt zu erfassen (Von Vorzeigeprojekten und leuchtturm-Großstädten mal angesehen). Die GPS-Genauigkeit liegt immer nach im Bereich 3-5 Meter, bei Abschattungen teilweise 10-30 m. Für Dezimetergenauigkeit muss man schon etwas teurere System nutzen. Die Genauigkeit von absoluten Satellitensystemen wird sich nicht wesentlich steigern lassen. Mit der Verbesserung der Satellitensysteme, zusätzlichen neuen Satelliten und der zu erwartenden Entwicklung wird vielleicht circa 1m als verlässlicher Wert zu haben sein. Auch wenn bei freiem Himmel die Genauigkeit besser ist, zählen in Wahrheit die abgeschatteten Bereiche und die von Mehrwegesignalen gestörten Gebiete viel mehr. Und auch in Zukunft wird gelten, höhere Genauigkeiten nur mit guten Antennen. Ich kann auch mit aktuellen Lowcost-Empfängern und DGPS Genauigkeiten im Bereich 50cm erreichen. Dazu brauche ich aber eine Antenne für mehrere Tausend Euro. Bei manchen GPS-Nutzern habe ich das Gefühl, dass keinerlei Verständnis für die Technik und die erzielbare Genauigkeit vorhanden ist. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Routingfähige Garmin-Karte
Hallo. Am Sonntag, 20. Juli 2008 schrieb Martin Simon: Vorsichtig... in seiner ersten mail, die Martin Koppenhoefer hier zitiert hat (17. Juni, Titel: [Talk-de] Fwd: [OSM-dev] Looking for some place to host routable OSM based Garmin maps), sprach Radomir davon, daß sein Programm cgpsmapper benutzt um selbst erstellte mp-Dateien zu garmin zu wandeln. Auszug: I currently write a program/process which generates a Garmin Maps from OSM data. It produces MP files which are later compile them with cgpsmapper. Hm, ja, ist mir zwischenzeitlich auch aufgefallen. :( Okay, aber von der Sorte (produziert nur MP-files) gibt es ja nun mittlerweile einige Varianten. Ist aber der vergleichsweise uninteressante Schritt, da MP auch Text-Daten sind und sich ein Lesen und Vergleichen damit deutlich leichter gestalten lässt. Schade, dass die Hoffnung auf einen freien OSM-nach-Garmin-Konverter damit für's erste nicht erfüllt werden kann. :( Gruß, Bernd -- Alles was ich will, ist die Chance, zu beweisen, daß Geld mich nicht glücklich macht signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Für landuse Knoten von Strassen verwen den?
Dirk Stöcker schrieb: Und auch in Zukunft wird gelten, höhere Genauigkeiten nur mit guten Antennen. Ich kann auch mit aktuellen Lowcost-Empfängern und DGPS Genauigkeiten im Bereich 50cm erreichen. Dazu brauche ich aber eine Antenne für mehrere Tausend Euro. Bei manchen GPS-Nutzern habe ich das Gefühl, dass keinerlei Verständnis für die Technik und die erzielbare Genauigkeit vorhanden ist. Wo soll man denn auch ein Gefühl für die Möglichkeiten entwickeln? Klar, die Grenzen meiner eigenen GPS Empfänger die kenne ich inzwischen sehr gut. Aber dann liest man z.B. von Gallileo, und dann heißt es, es gäbe kommerzielle Dienste über Gallileo, über die Genauigkeiten im cm Bereich möglich wären (Punkt - keine weiteren Erklärungen zu den Einschränkungen oder sonstigen Rahmenbedinungen). Naiv wie ich dann bin gehe ich erst mal davon aus, dass es damit theoretisch möglich wäre sich ein Super-Duper-GPS zu bauen, dass beim Autofahren genau unterscheiden kann, wann ich einem parkenden Auto ausgewichen bin und mit dem es theoretisch möglich ist aufgrund der erfassten Tracks zu zählen, wieviele Spuren eine Autobahn an einer bestimmten Stelle hat. Woher soll man denn Infos bekommen um so was besser einschätzen zu können? Gruß Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Für landuse Knoten von Strassen verwe nden?
On Sun, 20 Jul 2008, Thomas Hieber wrote: Und auch in Zukunft wird gelten, höhere Genauigkeiten nur mit guten Antennen. Ich kann auch mit aktuellen Lowcost-Empfängern und DGPS Genauigkeiten im Bereich 50cm erreichen. Dazu brauche ich aber eine Antenne für mehrere Tausend Euro. Bei manchen GPS-Nutzern habe ich das Gefühl, dass keinerlei Verständnis für die Technik und die erzielbare Genauigkeit vorhanden ist. Wo soll man denn auch ein Gefühl für die Möglichkeiten entwickeln? Klar, die Grenzen meiner eigenen GPS Empfänger die kenne ich inzwischen sehr gut. Aber dann liest man z.B. von Gallileo, und dann heißt es, es gäbe kommerzielle Dienste über Gallileo, über die Genauigkeiten im cm Bereich möglich wären (Punkt - keine weiteren Erklärungen zu den Einschränkungen oder sonstigen Rahmenbedinungen). Naiv wie ich dann bin gehe ich erst mal davon aus, dass es damit theoretisch möglich wäre sich ein Super-Duper-GPS zu bauen, dass beim Autofahren genau unterscheiden kann, wann ich einem parkenden Auto ausgewichen bin und mit dem es theoretisch möglich ist aufgrund der erfassten Tracks zu zählen, wieviele Spuren eine Autobahn an einer bestimmten Stelle hat. Woher soll man denn Infos bekommen um so was besser einschätzen zu können? Habe ich Dir eben mitgeteilt :-) Richtwerte der Genauigkeiten: Absolutposition: Normale Empfänger: 3-10 m Gute Empfänger: 1-5 m geodätische Empfänger (10.000 EURO): 0.7-3m Lowcost-Empfänger mit geodätscher Antenne: 1-3m (wie geodät.) Gestörtes Umfeld (Bäume, Häuserschluchten, Täler): 10-30 m (Extremfälle bis 100m) Mit Differenzsignal: DGPS normale Empfänger: Keine Auswirkung DGPS gute Empfänger: 0.70-3 m geodätische Empfänger DGPS: 0.3-1 m Mit hochgenauen Korrekturen: geodätische Empfänger RTK: wenige cm (nahezu Echtzeit) geodätische Empfänger mit viel Aufwand: einige Millimeter oder besser (auf keinen Fall Echtzeit). Nagel mich nicht auf die einzelnen Werte fest, aber die Bereiche sind in etwa so. Mit den in Zukunft zu erwarteten Satellitensystemverbesserungen werden die Ergebnisse stabiler: a) bessere Verfügbarkeit b) bessere Qualität in gestörten Bereichen Generelle Wunder sind nicht zu erwarten. Wenn eine Gerätegeneration es vom 3-5 m Bereich in den 1-3 m Bereich schafft wäre das schon toll. Im hochgenauen Bereich (30cm) sind stabilere Positionen, schnellere Ergebnisse und etwas höhere Genauigkeiten zu erwarten (statt 3cm vielleicht 1cm bei gleichem Aufwand). Natürlich kann man das so nicht verkaufen, weswegen bei Galileo von Revolutionen in der Genauigkeit gesprochen wird. Das darf man nicht ernst nehmen. Die Verbesserungen, die es bringen wird sind schon wichtig genug. Wenn Lowcost-Empfänger in Zukunft kaum noch die 20 m Probleme haben werden, die heute im Gebirge eigentlich Standard sind, dann wäre das schon schön. Oder wenn ich Fahrspurgenauigkeit bei Straßen garantieren kann. Achso - Die Eigenschaft guter Empfänger liegt heute eigentlich hauptsächlich an den Antenneneigenschaften (bei schnellerer Bewegung sind die Filteralgorithmen im Chip auch wichtig). Die moderneren Chips selbst sind mittlerweile alle auf einem sehr hohen Niveau angekommen. P.S. Das ist übrigens mein Beruf: GPS+GLONASS im Bereich zwischen Lowcost und hochpräzisen System. Je nachdem, wer gerade unser Kunde ist :-) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Harz geklaut
Andreas Titz [EMAIL PROTECTED] writes: [*]Diese Relation gibt es sogar schon. Nur müssten die entsprechenden Ways aus dem D11 wieder rausgelöscht werden, was ich bei Gelegenheit mal tun kann, sofern mir niemand zuvorkommt. Da bin ich aber strickt dagegen. Was immer du tust, stell bitte sicher, dass man alle D11-wege bekommt, wenn eine entsprechende abfrage stellt und es muss auch weiterhin gewährleistet sein, dass D11 auf der karte erscheint. Bei routen ist es sehr üblich, dass damit bestimmte wege doppelt verbucht werden. Diese nord-wege müssen in deine Koppenhagen-Berlin-relation wie auch in die D11-relation. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Karte auf id positionieren
Heiko Jacobs [EMAIL PROTECTED] wrote: Geht sowas auch mit der normalen slippy map? Ich meine hier schon mal sowas gesehen zu haben, kann mich aber auch voellig irren... Der Data Layer hat sowas eingebaut. Von da aus kommt man auf sowas: http://www.openstreetmap.org/browse/way/24287489 Gruss Sven -- How to prevent Java from forking? Use a spoon. (Found on http://slashdot.org) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Geschlossene Ortschaften
Dirk Stöcker schrieb: Es gibt nur drei brauchbare Lösungen: a) Relation: Definieren von Way vorher + Ortsname und Way nachher + Ortsname b) Fläche: Definieren der Ortsflächen c) Heuristik: Erkennen der Orschaften über Koordinate des Namens, Straßentypen, ... Die Fälle a und b sind exakt, allerdings finde ich die Lösung a grausam und bei b weiß ich nicht, wo ich die Daten herbekommen soll. Fall c wird bei komplizierteren Ortslagen versagen. Hier in der Gegend gibt es Fälle, wo ich auf einer Straße dreimal durch Ortseingang/Ortsausgang eines Dorfes komme. Das kann keine Heuristik vernünftig erkennen. zu b) Fläche wäre hier nur eine Annährung an die Praxis - hier gibt es real keine Fläche da die Grenzen nur punktuell für jede Strasse separat politisch willkürlich festgelegt und bei Feldwegen etc. oftmals nicht definiert bzw. erkennbar. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Norbert Hoffmann schrieb: Tordanik wrote: Nicht mehr genutzte Schienen: railway=[Railway-Typ] status=disused (Man beachte, dass – im Gegensatz zu railway=disused – die Art der Schiene wie gewohnt angegeben werden kann.) Man beachte aber auch, dass an einer mit railway=art beschriebenen Stelle, nach deinem Vorschlag gar keine Schiene mehr liegt. Die derzeit gültige Vorschrift stellt die Realität besser dar. Bei status=disused liegt ebenso wie beim derzeitigen railway=disused sehr wohl noch eine Schiene, sie ist lediglich nicht mehr genutzt, daher i.d.R. überwuchert usw. Nichtsdestotrotz ist sie real existent und kann auch eindeutig einem der Typen zugeordnet werden. Hier ist die Definition des Proposals auch nahezu wörtlich identisch mit der Dokumentation von railway. Für „abandoned“ kommt dein Einwand eher zum Tragen. Ich sehe aber nicht wirklich einen Unterschied in der Darstellung der Realität, ob ich eine ehemalige Straßenbahnschine als „abandoned railway“ beschreibe oder als einen „tram-railway, der im abandoned-Status ist“. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Tordanik wrote: Für „abandoned“ kommt dein Einwand eher zum Tragen. Ich sehe aber nicht wirklich einen Unterschied in der Darstellung der Realität, ob ich eine ehemalige Straßenbahnschine als „abandoned railway“ beschreibe oder als einen „tram-railway, der im abandoned-Status ist“. Für mich gibt es im 2. Fall nichts mehr, das einen Status haben könnte. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Routingfähige Garmin-Karte
On Jul 20 18:10, Bernd Wurst wrote: Schade, dass die Hoffnung auf einen freien OSM-nach-Garmin-Konverter damit für's erste nicht erfüllt werden kann. :( ..auf einen freien, *routingfähigen* OSM-nach-Garmin-Konverter.. mkgmap erstellt schließlich ganz hübsche Garmin Karten aus OSM Daten und ist GPL lizensiert. Gruß, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Norbert Hoffmann schrieb: Tordanik wrote: Beispiele: Nicht mehr genutzte Schienen: railway=[Railway-Typ] status=disused (Man beachte, dass – im Gegensatz zu railway=disused – die Art der Schiene wie gewohnt angegeben werden kann.) Man beachte aber auch, dass an einer mit railway=art beschriebenen Stelle, nach deinem Vorschlag gar keine Schiene mehr liegt. Die derzeit gültige Vorschrift stellt die Realität besser dar. Wenn die Strecke renaturiert und spurlos beseitigt ist - ja. Ansonsten sollte die Strecke dargestellt werden - auch lange abgebaut Srecken sind meist noch auffindbar und können als Orientierungsmerkmal dienen. Auch deuten sie bei Umwidmungen zu Fahrradwegen auf eine sehr ebene Streckenführung hin. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Garry schrieb: Wenn die Strecke renaturiert und spurlos beseitigt ist - ja. Ansonsten sollte die Strecke dargestellt werden - auch lange abgebaut Srecken sind meist noch auffindbar und können als Orientierungsmerkmal dienen. Auch deuten sie bei Umwidmungen zu Fahrradwegen auf eine sehr ebene Streckenführung hin. Mit dem Abbau der Schienen und Schwellen hat die Renaturierung wenig zu tun, die setzt meist auch so nach 10 Jahren mit unnachgiebiger Härte ein. (Siehe diese einspurige Eisenbahntrasse im Essener Stadtgebiet, die seit etwa 1990 nicht mehr genutzt wird und auf der die Schienenstränge noch liegen. Und ja, dieses ist eine Brücke. http://www.addicks.net/albums/GeoCaching/DSCF0252.sized.jpg Weiter vorn sah es noch harmloser aus: http://www.addicks.net/albums/GeoCaching/DSCF0257.sized.jpg ) Will sagen: außer Betrieb genommene Bahndämme sind, gleich ob dort noch Schienen liegen oder nicht, für 5-15 Jahre trekking-tauglich, selbst wenn nichts für den Unterhalt getan wird. Und bei genügender Nutzung durch Wanderer/Offroader bleiben die ja dann auch offen. Und gerade das sollte mapbar sein. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Tordanik schrieb: Hallo, ich möchte euch auf einen Vorschlag (Proposal) zum Thema in Bau befindliche Objekte und nicht mehr benutzte Objekte aufmerksam machen: http://wiki.openstreetmap.org/index.php/Proposed_features/Status Die Idee ist, solche Objekte mit einem status=construction/disused/abandoned/preserved zu kennzeichnen. Unbedingt dafür! Die Diskussion hatte ich letzte Woche auch beim OSM-Treffen in Karlsruhe angeleiert.da ich oft auch bei der Baustellenerfassung tätig bin. Das derzeit gängige Verfahren verhindert dass die in Bau bedindliche Strecken vielen gängingen Produktiv-Andwendungen (Garmin, NaviPowm)dargestellt. Steht preserved für geplant? Ansonsten sollte das unbedingt mit berücksichtigt werden. Wegen Zeitangaben: Ich würde es in klammern hinter den Namen schreiben damit man es in jeder Anwendungen sehen kann und das somit möglichst alle OSM nutzer sehen und damit gegebenfall anpassen können. Dadurch besteht die grösste Wahrscheinlichkeit dass die Daten zeitnah angepasst werdenbzgl. Bauzustand, Freigabetermin... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] highway=bus_stop
Hi, bin gerade dabei die Bushaltestellen meiner Heimatstadt zu mappen. Bin da natürlich sofort auf das Problem gestoßen, dass teilweise Haltestellen nur einseitig sind bzw. bis 100m voneinander getrennt sind. Könnte man hierbei nicht nen ähnlichen tag wie bei straßenbegleitenden Fußwegen einführen. So dass in Abhängigkeit zur Richtung der Straße gesagt wird bus_stop=left bus_stop=right oder is da irgendwas anderes schon in Planung. Alex Gerrit Lammert schrieb: Remo wrote: Für mich sind halt die Tramhaltestellen einfach Markierungen auf dem Stadtplan an welchen ungefähren Orten (meist Kreuzungen) die Tram hält. Der offizielle Stadplan hier macht das ähnlich: Der ist ja tatsächlich nur für das Auge gemacht. OSM kann ja viel mehr. Ich würde eigentlich auch gerne mehr Punkte markieren. Aber wie tagge ich dann die Umsteigemöglichkeiten? Und Osmarender stellt die Haltestellen-Namen scheisse dar. Mapnik verzichtet ganz auf die Namen. Ich finde es bislang so am Besten: Jede Haltestelle wird etwa an der Position des H-Schildes, also neben der Straße, gezeichnet und mit highway=bus_stop und name=Haltestellenname versehen. Sie sind damit zeitlose POIs ohne aktuelle Informationen. In eine Relation werden dann die Busrouten eingetragen (incl liniennummer, Operator, etc), hier werden neben den angefahrenen Bushaltestellen auch die dabei befahrenen Wege/Straßen hinzugefügt. Dadurch sind ohne Redundanz alle nötigen Informationen vorhanden oder kann abgeleitet werden. Etwa welche Linien in welcher Richtung an welcher Station halten. Zugleich kann sehr einfach ein Liniennetzplan aus den Daten erzeugt werden. Es können sogar die Informationen über den Busverkehr beinahe direkt in einen Verkehrssimulator übernommen werden. Rendermöglichkeiten sind auch gegeben, der Renderer kann in der kleinsten Detailstufe die Liniennummern an jeder Halstestelle einblenden, und bei Übersichtskarten mehrere nahe beieinander liegende Haltestellen mit identischem namen zusammenfassen. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Für landuse Knoten von Strassen verwen den?
Josias schrieb: Rolf Gehring schrieb: könnte mal einer der Verfechter der Flächendarstellung von Straßen den wirklichen Hintergrund dieser Aktivitäten etwas erläutern? es wird an Geräten geforscht, die Blinden über einen Gürtel die Richtung weisen (vibration). dafür braucht man eine karte, die dezimeter genau arbeitet. und wo vor allem fußwege als flächen eingezeichnet sind. Meiner Meinung nach ist OSM dafür nicht geeignet. Man muss dazu eine Unmenge an Daten sehr genau erfassen wozu mittelfristig praktisch kein OSm_MApper auch nur annährend in der Lage sein dürfte - abgesehen davon dass viele dafür keine Motivation hätten den entsprechenden Aufwand zu treiben. Und ohne Qualitätsmanagment halte ich den Einsatz für Blinde für sehr bedenklich... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Hallo, ich möchte euch auf einen Vorschlag (Proposal) zum Thema in Bau befindliche Objekte und nicht mehr benutzte Objekte aufmerksam machen: [...] Ich halte diese Art des Taggings fuer fragwuerdig und will das an einem Beispiel illustrieren: Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Ein im Bau befindliches Atomkraftwerk ist fuer mich in ERSTER Linie eine Baustelle (auf der uebrigens ein AKW gebaut wird). Es ist fuer mich NICHT in erster Linie ein AKW (das sich uebrigens noch im Bau befindet). Daher faende ich es zutreffender, das ganze als Baustelle zu taggen, und evtl. eine Zusatzinfo dazu, was eigentlich gebaut wird, dranzuhaengen. Ich gebe zu, dass die Grenze oft fliessend ist, und ob irgendwo ein Radweg oder eine Autobahn gebaut wird, beeintraechtigt den Charakter der Baustelle u.U. erheblich. Dennoch ist auch eine Autobahnbaustelle nicht in erster Linie eine Autobahn, sondern in erster Linie eine Baustelle, finde ich. Noch deutlicher wird es, wenn die Sachen nichtmal im Bau sind, sondern nur in Planung. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Garry schrieb: Steht preserved für geplant? Ansonsten sollte das unbedingt mit berücksichtigt werden. „preserved“ = „konserviert“. Das Objekt ist also nicht mehr wirklich in Benutzung im Sinne des ursprünglichen Zwecks; es wird aber nicht abgerissen, sondern aktiv vor dem Verfall bewahrt, etwa aus historischem oder touristischem Interesse. Hab ich in dieser Form von railway übernommen. Für „geplant“ ist zwar noch nichts vorgesehen. Es spricht aber vom Konzept her absolut nichts dagegen, da ein „status=planned“ zu nehmen. Für das derzeitige Proposal habe ich mich halt lediglich auf Werte beschränkt, die in irgendeiner Form schon existieren, um die Entscheidung über Tagging-Struktur (da scheint es ja sehr wohl Diskussionsbedarf zu geben, wenn ich mir die ML so ansehe) und die Einführung neuer Werte getrennt zu halten. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Garry wrote: Das derzeit gängige Verfahren verhindert dass die in Bau bedindliche Strecken vielen gängingen Produktiv-Andwendungen (Garmin, NaviPowm)dargestellt. Das ist doch auch gut so. Ich möchte, dass mein Navi mich über Straßen routet und nicht über Baustellen. Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Hallo, Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Ein im Bau befindliches Atomkraftwerk ist fuer mich in ERSTER Linie eine Baustelle (auf der uebrigens ein AKW gebaut wird). Es ist fuer mich NICHT in erster Linie ein AKW (das sich uebrigens noch im Bau befindet). Daher faende ich es zutreffender, das ganze als Baustelle zu taggen, und evtl. eine Zusatzinfo dazu, was eigentlich gebaut wird, dranzuhaengen. Deinen konzeptionellen Einwand verstehe ich voll und ganz. Ich bin die Fragestellung eben von folgendem Ausgangspunkt her angegangen: 1. Man sollte im Bau befindliche, aufgegebene etc. Versionen von _jedem_ Objekt, das wir in OSM taggen können, eintragen können, auch wenn man Zusatztags hat (wie power_source=nuclear). 2. Dies sollte für jedes Objekt in gleicher Weise möglich sein, alles andere erhöht den Lern- und Dokumentationsaufwand. Gerade Punkt 1 kann eben am einfachsten gelöst werden, wenn man einfach eine zusätzliche Information zu den bestehenden hinzufügt und wird (ebenso wie 2) von den bisherigen highway- und railway-spezifischen Ansätzen nicht geleistet. Hast du einen speziellen Gegenvorschlag? Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Hallo, Ich bin die Fragestellung eben von folgendem Ausgangspunkt her angegangen: 1. Man sollte im Bau befindliche, aufgegebene etc. Versionen von _jedem_ Objekt, das wir in OSM taggen können, eintragen können, Aber mein Punkt war ja gerade, dass es solang es sich in Bau befindet eben noch gar keine Version von einem Objekt ist. Wuerde Dein Vorschalg konsequent umgesetzt, so waere es nicht moeglich, eine Baustelle zu taggen, ohne dass man weiss, was da gebaut wird (something=anything, status=construction?) Hast du einen speziellen Gegenvorschlag? Ich wuerde eine Baustelle als Baustelle taggen, von mir aus als landuse=construction_site oder was auch immer. Falls Zusatzinformationen vorhanden sind, koennen diese in einen note-Tag (note=Kernkraftwerk, leichtwassergekühlt, Typ RBMK1000, Bauherr EnBw, Fertigstellung Sommer 2010). Es ist illusorisch, anzunehmen, man koennte das Objekt schon komplett fertig taggen und muesste dann, wenn es fertig gebaut ist, einfach nur das status=construction loeschen. Irgendjemand wird das von Hand machen und wird dabei so oder so genau anschauen, was er tut - zu diesem Zeitpunkt dann aus der menschenlesbaren note die Tags zu machen, die zu diesem Zeitpunkt geeignet erscheinen, duerfte nicht allzu schwer sein. Eine Baustelle ist eine Baustelle und kein Kernkraftwerk. Ich wuerde eine Baustelle mit power=nucelar taggen, wenn wenn die Baufahrzeuge nuklear angetrieben sind. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Icons?
Am Samstag, 12. Juli 2008 15:17:49 schrieb Christoph Eckert: Hi, wo finde ich eine komplette Liste der verfügbaren RenderIcons? In der MapFeatures Seite sind einige aufgeführt, jedoch finde ich nicht alle dort... etliches findet sich im SVN unter applications/share/map-icons. Falls Dir SVN unbekannt ist kannst Du es auch über das Webinterface versuchen: http://svn.openstreetmap.org/applications/share/map-icons/ Diese werden dann z.b. auch von GpsDrive verwendet und deswegen findest du unter http://www.gpsdrive.de/development/map-icons/overview.en.shtml eine Übersicht über alle im Moment in svn befindlichen icons. - Joerg -- Jörg (Germany, Tettnang) http://www.ostertag.name/ irc://irc.oftc.net/#osm Tel.: +49 89 420950304 Skype: JoergOstertag ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Tordanik wrote: Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Hast du einen speziellen Gegenvorschlag? Zu jedem Objekttyp wäre doch eine Erfasung analog zu highway und rail möglich: power=construction construction=generator power-source=nuclear Norbert ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Garry wrote: Tordanik schrieb: Hallo, ich möchte euch auf einen Vorschlag (Proposal) zum Thema in Bau befindliche Objekte und nicht mehr benutzte Objekte aufmerksam machen: http://wiki.openstreetmap.org/index.php/Proposed_features/Status Die Idee ist, solche Objekte mit einem status=construction/disused/abandoned/preserved zu kennzeichnen. Unbedingt dafür! Die Diskussion hatte ich letzte Woche auch beim OSM-Treffen in Karlsruhe angeleiert.da ich oft auch bei der Baustellenerfassung tätig bin. Das derzeit gängige Verfahren verhindert dass die in Bau bedindliche Strecken vielen gängingen Produktiv-Andwendungen (Garmin, NaviPowm)dargestellt. Steht preserved für geplant? Ansonsten sollte das unbedingt mit berücksichtigt werden. Wegen Zeitangaben: Ich würde es in klammern hinter den Namen schreiben damit man es in jeder Anwendungen sehen kann und das somit möglichst alle OSM nutzer sehen und damit gegebenfall anpassen können. Dadurch besteht die grösste Wahrscheinlichkeit dass die Daten zeitnah angepasst werdenbzgl. Bauzustand, Freigabetermin... Hi Garry, du meinst im dem Zusammenhang ein Datum ala status:last_checked=20080721? Das könnte dann ja sinnvoll sein um regelmäßig mal zu schauen was ggf. noch zu kontrollieren wäre. Aber wie schon eingangs von jemand gesagt: Wir sollten uns bzgl. des Proposal vielleicht besser nicht verzetteln und Zeitstempel in ein zweites Proposal aufnehmen. Allgemein finde ich die Idee eines status gut, um so für die Orientierung sinnvolle Sachen (oder im Bau befindliche Straßen die demnächst fertig werden etc.) aufnehmen zu können, Router o.ä. aber davon abzuhalten so eine Straße oder whatever schon zu verwenden. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Frederik Ramm wrote: Hallo, ich möchte euch auf einen Vorschlag (Proposal) zum Thema in Bau befindliche Objekte und nicht mehr benutzte Objekte aufmerksam machen: [...] Ich halte diese Art des Taggings fuer fragwuerdig und will das an einem Beispiel illustrieren: Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Ein im Bau befindliches Atomkraftwerk ist fuer mich in ERSTER Linie eine Baustelle (auf der uebrigens ein AKW gebaut wird). Es ist fuer mich NICHT in erster Linie ein AKW (das sich uebrigens noch im Bau befindet). Daher faende ich es zutreffender, das ganze als Baustelle zu taggen, und evtl. eine Zusatzinfo dazu, was eigentlich gebaut wird, dranzuhaengen. Ich gebe zu, dass die Grenze oft fliessend ist, und ob irgendwo ein Radweg oder eine Autobahn gebaut wird, beeintraechtigt den Charakter der Baustelle u.U. erheblich. Dennoch ist auch eine Autobahnbaustelle nicht in erster Linie eine Autobahn, sondern in erster Linie eine Baustelle, finde ich. Noch deutlicher wird es, wenn die Sachen nichtmal im Bau sind, sondern nur in Planung. Das würde uns im Umkehrschluß bei einer Straße aber dazu führen, daß wir eine 5km lange Baustelle einzeichnen - von der die meisten Leute davon ausgehen das dies eine Straße seien wird. Ggf. vergibst du sogar schon ref=A 5 weil du weisst das dies die Verlängerung der neuen Autobahn ist ... hmm. Das es für Gebäude (auch ein AKW) ggf. ausreichend sein kann diese als Gebäude-Baustelle zu taggen, sehe ich ggf. ein - aber ... Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Karte auf id positionieren
Sven Geggus [EMAIL PROTECTED] wrote: Heiko Jacobs [EMAIL PROTECTED] wrote: Geht sowas auch mit der normalen slippy map? Ich meine hier schon mal sowas gesehen zu haben, kann mich aber auch voellig irren... Der Data Layer hat sowas eingebaut. Von da aus kommt man auf sowas: http://www.openstreetmap.org/browse/way/24287489 Ui, und mit Kaertchen dabei, wo way und node erstklassig eingezeichnet sind, das ist ja weltbestens. Danke!: MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Frederik Ramm schrieb: Ich bin die Fragestellung eben von folgendem Ausgangspunkt her angegangen: 1. Man sollte im Bau befindliche, aufgegebene etc. Versionen von _jedem_ Objekt, das wir in OSM taggen können, eintragen können, Aber mein Punkt war ja gerade, dass es solang es sich in Bau befindet eben noch gar keine Version von einem Objekt ist. Schön, dann formulieren wir es anders. Ich finde es sinnvoll, wenn man zu jeder Baustelle die Information hinzufügen kann, was da gebaut wird. Und dazu sollte man der Einfachheit halber das gleiche Tagging verwenden können, wie man es für fertiggestellte Dinge tut. Eine note ist keine echte Alternative, da nicht maschinell (etwa fürs Rendering) auswertbar. Ich möchte gerne die Baustelle des Atomkraftwerks anders darstellen können als die der U-Bahn. Wuerde Dein Vorschalg konsequent umgesetzt, so waere es nicht moeglich, eine Baustelle zu taggen, ohne dass man weiss, was da gebaut wird (something=anything, status=construction?) Es dürfte wohl kaum vorkommen, dass man nicht zumindest eine ganz grobe Klasse erkennt, z.B. ein Gebäude („building=yes, status=construction“) oder irgendeine Straße („highway=road, status=construction“). Prinzipiell hast du recht, dass ein reines „status=construction“ vom Modell her unschön ist, ich hatte auch nicht an eine Baustelle, sondern eben an objektbezogene Information gedacht, wie sie derzeit vereinzelt schon existiert. Verstehe ich richtig, dass du das Tagging, wie es derzeit im Einsatz ist (Straßenbaustelle als highway des Typs construction) aus dem gleichen Grund ablehnst? Ach ja, und hierzu: Eine Baustelle ist eine Baustelle und kein Kernkraftwerk. Ich wuerde eine Baustelle mit power=nucelar taggen, wenn wenn die Baufahrzeuge nuklear angetrieben sind. Das war einer der Gründe, weshalb ich die Semantik „Objekt im Zustand X“ gewählt habe, und nicht die Semantik „Baustelle von Objekt“ – eben damit sich die Zusatztags wie power_source=nuclear weiterhin klar auf das Objekt, und nicht auf die Baustelle beziehen. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Johann H. Addicks [EMAIL PROTECTED] wrote: Zumindest ein Datumstag w?re auch nicht schlecht. Also wann der Statuswechsel stattgefunden hat (bie disused) bzw wann Dann sind wir aber fix bei Zeitreihen: bei railways koennen schon disused (Verkehr eingestellt) und abandoned (Schienen abgebaut) viele Jahre auseinanderfallen... Dann kann die Strecke irgendwann wieder reaktiviert werden... disused nur f?r PV, paar Jahre sp?ter auch f?r GV, ... status=used construction_date=1895, used_date=1896, disused_date=1977, abandonded_date=1988, construction_date2=2002, used_date2=2003, ... :-) MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Frederik Ramm wrote, on 20.07.2008 23:56: Wuerde Dein Vorschalg konsequent umgesetzt, so waere es nicht moeglich, eine Baustelle zu taggen, ohne dass man weiss, was da gebaut wird (something=anything, status=construction?) Meistens gibt es an der Baustelle ein Schild, auf dem steht, was da gebaut wird. Das Schild steht oft schon da, bevor überhaupt mit den eigentlichen Arbeiten begonnen wird, und meistens ist es auch noch ziemlich groß, sofern es sich nicht gerade um die vorgeschriebene Bautafel bei einem Einfamilienhaus handelt. Wenn man nicht mehr weiß oder das nicht betrachten will, kann man das nach Deinem Vorschlag machen: Ich wuerde eine Baustelle als Baustelle taggen, von mir aus als landuse=construction_site oder was auch immer. Ich persönlich würde eine Baustelle in zwei Fällen eintragen: 1. Das vorgesehene Bauwerk erscheint mir irgendwie wichtig. Dann würde ich gleich die Tags für das zukünftige Bauwerk mit status=construction bevorzugen. 2. Die Baustelle blockiert einen Weg oder eine Straße und das Bauwerk ist (für mich) nicht relevant oder unbekannt. In diesem Fall würde ich eher Tags für Baustelle als solche verwenden. Es ist illusorisch, anzunehmen, man koennte das Objekt schon komplett fertig taggen und muesste dann, wenn es fertig gebaut ist, einfach nur das status=construction loeschen. Irgendjemand wird das von Hand machen und wird dabei so oder so genau anschauen, was er tut - zu diesem Zeitpunkt dann aus der menschenlesbaren note die Tags zu machen, die zu diesem Zeitpunkt geeignet erscheinen, duerfte nicht allzu schwer sein. Schwer natürlich nicht. Wenn die Tags gleich in der endgültigen Form notiert werden, erleichtert es aber die Arbeit für den, der es später ändert. Eine Baustelle ist eine Baustelle und kein Kernkraftwerk. Klar. Je nach Betrachtungsweise kann die Baustelle aber ein zukünftiges Kernkraftwerk sein. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Norbert Hoffmann schrieb: Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Zu jedem Objekttyp wäre doch eine Erfasung analog zu highway und rail möglich: power=construction construction=generator power-source=nuclear Ja, ich hatte erwartet, dass der Vorschlag kommt. :) Das ist m.E. eine der drei prinzipiellen Möglichkeiten (#3 wäre abandoned=yes/no, disused=yes/no, construction=yes/no etc.). Dieser von dir ins Spiel gebrachte Ansatz hat mir aus folgenden Gründen nicht so gut gefallen: * Welcher Tag wird ersetzt? Warum etwa heißt es nicht power=generator construction=nuclear power-source=power=construction – ok, weil power das „Haupt-Tag“ ist. Ist das immer klar erkennbar? Ich hab schon Dinge wie building=yes, amenity=... gesehen – ist dann building oder amenity das „Haupt-Tag“, dessen Wert mit construction auszutauschen ist? Und kann man das irgendwie allegemeingültig (d.h. nicht für jedes Paar von Tags extra) festlegen? * Erfinden eigener Werte Mit status=blah kann ich mir beliebige blahs ausdenken, beim objektkey=blah, blah=objektwert bin ich dagegen schon mal auf blahs beschränkt, die nicht selbst schon irgendein Key oder irgendein Value sind. Natürlich wird wohl niemand auf die Idee kommen, einen Status „primary“ einzuführen, aber ich wär mir nicht so sicher, alle Keys und alle Werte aller Keys zu kennen, wenn ich einen Status erfinde. * Erfinden eigener Werte 2: Softwareunterstützung Wenn ich diesen Wert blah nicht kenne, weiß ich außerdem nicht, ob es sich dabei jetzt um einen Status handelt oder um einen eigenen Wert. Das kann für alles mögliche nett sein zu wissen. Beispiel: Ich will mir eine Validatorsoftware schreiben, die festlegt, dass highway=stop_sign nur auf Nodes verwendet wird, highway=motorway dagegen nur auf Ways. Wenn ich jetzt einen Node mit so etwas highway=occupied_by_aliens occupied_by_aliens=motorway finde, kann ich nicht mehr validieren, weil ich nicht weiß, ob occupied_by_aliens ein highway-Typ oder ein Status ist. Bei einem highway=motorway status=occupied_by_aliens geht es dagegen problemlos. * Verständlichkeit Ich halte das Konzept power=construction construction=generator für absolut nicht intuitiv lesbar („power=construction ?“). Ein normales Objekttagging mit status=foobar lässt sich dagegen leicht als „aha, ein Objekt xy, das sich in foobarem Status befindet“ erkennen. * Dokumentation An sich handelt es sich hier ja um Werte von power, highway und letztlich jedem einzelnen anderen Tag. Die wird man aber dann nicht – wie es jetzt noch der Fall ist – bei jedem Key, wo sie möglich sind, (das wären nämlich schlicht alle) hineinschreiben wollen. Das passt nicht so ganz in unser derzeitiges Dokumentationsschema. Könnte man natürlich prinzipiell ändern, aber ich weiß erstmal nicht, wie. * Baustellen unbekannten Typs Daran hatte ich vorher nicht gedacht, aber da es ja einer von Frederiks Einwänden war … status=construction ohne sonstige Information ist sehr unschön, aber bei dem objekttyp=construction-Vorschlag ist eine Baustelle mit unbekanntem Objekttyp nicht nur unschön, sondern unmöglich. Puh, etwas lang geworden … *g* Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, ?nicht mehr genutzte Objekte
Norbert Hoffmann [EMAIL PROTECTED] wrote: F?r mich gibt es im 2. Fall nichts mehr, das einen Status haben k?nnte. Bei vielen abandoned railways sind noch Einschnitte und Daemme gut im Gelaende auszumachen, ebenso alte Bruecken, Fundamente von Oberleitungsmasten, Tunnel, ... oder einfach nur Schotter statt natuerlicher Boden... Das gilt auch fuer viele Ex-highways, wenn's nicht grad ein tracktype=grade5 ist, der von der Natur fix zurueckerobert wird. Aber selbst ein solcher hinterlaeszt womoeglich im huegeligen Gelaende Spuren genug... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Heiko Jacobs wrote, on 21.07.2008 01:08: Johann H. Addicks [EMAIL PROTECTED] wrote: Zumindest ein Datumstag w?re auch nicht schlecht. Also wann der Statuswechsel stattgefunden hat (bie disused) bzw wann Dann sind wir aber fix bei Zeitreihen: bei railways koennen schon disused (Verkehr eingestellt) und abandoned (Schienen abgebaut) viele Jahre auseinanderfallen... In Verbindung mit dem vorgeschlagenen Status-Tag wäre wohl nur das Datum der letzten Statusänderung sinnvoll. Andernfalls müßte man zusätzlich jeden früheren Status mit seinem zugehörigen Beginn-Datum speichern. Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Garry [EMAIL PROTECTED] wrote: Auch deuten sie bei Umwidmungen zu Fahrradwegen auf eine sehr ebene Streckenf?hrung hin. Das taete die Zeitreihenfrage weiter oben noch komplizierter machen... Derselbe way haette dann als highway=cycleway und als railway=rail voellig unterschiedliche Zustaende: status=abandoned status=used mit unterschiedlichen dazugehoerigen Datumsangaben... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Hi, Schön, dann formulieren wir es anders. Ich finde es sinnvoll, wenn man zu jeder Baustelle die Information hinzufügen kann, was da gebaut wird. Und dazu sollte man der Einfachheit halber das gleiche Tagging verwenden können, wie man es für fertiggestellte Dinge tut. Eine note ist keine echte Alternative, da nicht maschinell (etwa fürs Rendering) auswertbar. Ich möchte gerne die Baustelle des Atomkraftwerks anders darstellen können als die der U-Bahn. Da ist fuer mich halt das grosse Fragezeichen. Wir taggen im allgemeinen das, was in der physischen Welt sichtbar ist. Wenn jetzt zwei Baugruben nebeneinander ausgehoben werden, die eine soll mal ein Kernkraftwerk werden und die andre ein Schweinestall, dann gibt es in meinen Augen wenig Rechtfertigung dafuer, dies auf der Karte unterschiedlich zu modellieren - wenn ich vorbeifahre/gehe/fliege, sehe eine Baugrube, also habe ich nichts davon, wenn auf meiner Karte schonmal ein landuse=farm oder so eingetragen ist. Verstehe ich richtig, dass du das Tagging, wie es derzeit im Einsatz ist (Straßenbaustelle als highway des Typs construction) aus dem gleichen Grund ablehnst? Ich habe das bislang so hingenommen, weil es gerade bei Strassen ja eben ueblich ist, dass man sie schonmal gestrichelt einzeichnet, selbst wenn es sich nur um eine Baustelle handelt. Aber wenn dies nun zum Anlass genommen wird, zu postulieren, dass man generell alle Objekte so taggen sollte, als ob sie schon existierten, und dann einfach noch ein status=construction dranhaengt, dann wuerde ich dagegenhalten und kuenftig eine Strassenbaustelle als landuse=construction_site mit note=Nordtangente Karlsruhe, Fertigstellung 2018 taggen ;-) Ach ja, und hierzu: Eine Baustelle ist eine Baustelle und kein Kernkraftwerk. Ich wuerde eine Baustelle mit power=nucelar taggen, wenn wenn die Baufahrzeuge nuklear angetrieben sind. Das war einer der Gründe, weshalb ich die Semantik ???Objekt im Zustand X??? gewählt habe, und nicht die Semantik ???Baustelle von Objekt??? ??? eben damit sich die Zusatztags wie power_source=nuclear weiterhin klar auf das Objekt, und nicht auf die Baustelle beziehen. Aber das, was existiert, was sichtbar ist, was Krach macht und Menschen beschaeftigt, ist die Baustelle, nicht das Objekt ;-) Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] neue Sport Piktogramme
Am 20. Juli 2008 17:03 schrieb Josias [EMAIL PROTECTED]: Martin Koppenhoefer schrieb: find ich super, Dein Engagement für Icons. ich bin im gegensatz zu einigen anderen hier der meinung, dass OSM vom Aussehen der karten lebt, oder zumindest später leben können muss. dh, wenn die darstellung nicht vernünftig ist werden die meisten (zumindest ist das so bei den leuten mit denen ich gesprochen habe) ein tag nur wehnig benutzen. was ich aber noch viel besser fände, wenn wir statt die icons in der karte direkt zu render, nur ein overlay, das allerdings peformant genug ist, viele anfragen abzuarbeiten alles Gute Josias sicher wird man nicht alle alle Dinge auch als Icon in die Karte rendern wollen, und von daher ist ein Overlay in jedem Fall gut, aber manches will man halt auch (fast) immer drin haben in einer Karte (Krankenhaus, Flughafen, Bahnhof) und von daher ist die Frage, wo man die Grenze zwischen festem Karteninhalt und Overlay zieht. Die Overlays könnten auch verschiedene Voreinstellungen (Themes) haben, genauso könnte man sich auch verschiedene underlays (landuse, administrativ, Höhenlinien) und interlays (Straßen, Gebäude, etc.) vorstellen. Sozusagen das modulare Openstreet-mapkit. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Frederik Ramm [EMAIL PROTECTED] wrote: Ich halte diese Art des Taggings fuer fragwuerdig und will das an einem Beispiel illustrieren: Im Prinzip koennte man das Pferd genauso gut andersrum aufzaeumen: statt railway=rail/tram/... highway=primary/residential/... amenity=bank/police/... landuse=residential/commercial/... und status=construction/used/disused/... ginge ja auch highway=construction/primary/residential/... railway=construction/rail/tram/disused/... landuse=greenfield/construction/residential/brownfield/... mit construction=rail/tram/primary/residential fuer kuenftiges inc. geplant (alternati: future=...) oder former=rail/... fuer ehemaliges Dann ginge auch highway=cycleyway former=rail construction=primary/residential/... wird ja tw. schon verwendet... Datumsreihen sind aber noch offen, ob so oder so... date01=rail:planned:1895 date02=rail:construction:1899 ... mehrere date=.. geht wohl nicht? MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] RFC: Im Bau befindliche Objekte, ?nicht mehr genutzte Objekte
Stefan Neufeind [EMAIL PROTECTED] wrote: du meinst im dem Zusammenhang ein Datum ala status:last_checked=20080721? last_checked=20080720 waere sowieso mal eine Idee... Allgemein finde ich die Idee eines status gut, um so f?r die Orientierung sinnvolle Sachen (oder im Bau befindliche Stra?en die demn?chst fertig werden etc.) aufnehmen zu k?nnen, Router o.?. aber davon abzuhalten so eine Stra?e oder whatever schon zu verwenden. Optimal waere ein Navi, das, sobald es erkennt, dass der Fahrer gerade auf einem highway=construction construction=primary unterwegs ist, daraus selbsttaetig ein highway=primary bis zum naechsten Verzweigungspunkt macht und per UMTS eine Aenderungsmeldung an OSM absetzt :-) Es sei denn, der Fahrer ist mit job=construction getagged :-) MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Norbert Hoffmann schrieb: Garry wrote: Das derzeit gängige Verfahren verhindert dass die in Bau bedindliche Strecken vielen gängingen Produktiv-Andwendungen (Garmin, NaviPowm)dargestellt. Das ist doch auch gut so. Ich möchte, dass mein Navi mich über Straßen routet und nicht über Baustellen. Das lässt sich ganz einfach dadurch verhindern in dem man die Einfahrt als gesperrt markiert oder eine kleine Lücke an der Anbimdung zum öffentlichen Strassennetz lässt. Durch die Nichtdarstellung schliesst Du eine ganze Gruppe an Anwendern (die die mit der jeweiligen Baustelle zu tun haben) die besonders Interessante Daten für OSM zur Verfügung stellen könnten. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Heiko Jacobs schrieb: Dann ginge auch highway=cycleyway former=rail Ok, war ein highway=pedestrian area=yes former=residential dann früher mal ein Wohngebiet (landuse=residential) oder eine Wohnstraße (highway=residential)? Kurz, der Ansatz setzt voraus, dass man implizit weiß, zu welchem Key „rail“ gehört. Oder sollte dann da noch ein landuse=former oder landuse=abandoned stehen? construction=primary/residential/... wird ja tw. schon verwendet... Die generellen Nachteile dieser Idee siehe in meiner Antwort auf Norberts Mail. Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Ich halte diese Art des Taggings fuer fragwuerdig und will das an einem Beispiel illustrieren: Im Bau befindliches Atomkraftwerk: power=generator power_source=nuclear status=construction Ein im Bau befindliches Atomkraftwerk ist fuer mich in ERSTER Linie eine Baustelle (auf der uebrigens ein AKW gebaut wird). Es ist fuer mich NICHT in erster Linie ein AKW (das sich uebrigens noch im Bau befindet). Daher faende ich es zutreffender, das ganze als Baustelle zu taggen, und evtl. eine Zusatzinfo dazu, was eigentlich gebaut wird, dranzuhaengen. ich finde gerade im Gegenteil ist eine Baustelle eines AKW ein AKW, das sich in Konstruktion befindet. Es ist nicht anzunehmen, dass nach halber Bauzeit beschlossen wird: anstatt des AKW bauen wir doch lieber eine Autobahn da hin, oder eine Chip-Fabrik. Wenn ich eine Datenbankabfrage mache, wo AKW stehen, interessieren mich ggf. sehr wohl auch die im Bau befindlichen. Wenn ich eine Autobahnkarte mache, will ich die in Bau befindlichen auch sehen, etc. Zwischen einer Autobahnbaustelle (im Prinzip nach und nach eine Autobahn) und einer Hochhaus-baustelle (im Prinzip nach und nach ein Hochhaus) bestehen quasi unendliche Unterschiede. Weiterhin ist es bei Baustellen meist kein Problem festzustellen, was da gebaut wird. In aller Regel künden Schilder davon. Warum sollte man diese Informationen nicht schonmal in die Karte/Datenbank bringen? Noch deutlicher wird es, wenn die Sachen nichtmal im Bau sind, sondern nur in Planung. warum? Soll man da dann anstatt Baustelle Planungsgebiet eintragen? Eigentlich ist bei den Dingen (Autobahnen, etc.), die geplant werden und bekannt sind nicht schlecht, sie auch in der Karte zu haben. Was hingegen nicht bekannt ist, wird wohl auch nicht in unseren Karten erscheinen. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Für landuse Knoten von Strassen verwen den?
Garry schrieb: Meiner Meinung nach ist OSM dafür nicht geeignet. das meinte ich auch nicht, ich wollte nur eine anwendungsmöglichkeit für Straßen als Area zur diskussion beisteuern... meine meinung ist wowieso, dass eine karte abstrakt bleiben muss ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [tagging] RFC: Im Bau befindliche Objekte, nicht mehr genutzte Objekte
Hello again, Ich möchte gerne die Baustelle des Atomkraftwerks anders darstellen können als die der U-Bahn. Wir taggen im allgemeinen das, was in der physischen Welt sichtbar ist. Wenn jetzt zwei Baugruben nebeneinander ausgehoben werden, die eine soll mal ein Kernkraftwerk werden und die andre ein Schweinestall, dann gibt es in meinen Augen wenig Rechtfertigung dafuer, dies auf der Karte unterschiedlich zu modellieren. und wenn dann auf der einen Baustelle schon Kühltürme, Reaktoranlagen usw. stehen …? Dann unterscheidet sich das Objekt doch schon wesentlich stärker von einer Schweinestallbaustelle als von einem fertigen Atomkraftwerk. Ja, in der Phase „großes Loch“ stellt sich das etwas anders dar: Da macht äußerlich nur die Bautafel (und die Frage, ob Atomkraftgegner oder Tierschützer gegen das Projekt demonstrieren) den Unterschied. Mehr als ein Schild trennt aber auch Fuß- und Radweg nicht voneinander. Da aber nun – trotz der fehlenden Rechtfertigung – auf Karten üblicherweise nicht nur Fuß- und Radwege unterschieden werden, sondern ich auch schon im Bau befindliche U-Bahn-Linien und ähnliches in Stadtplänen gefunden habe, sehe ich durchaus einen praktischen Bedarf für solche Information. Das soll natürlich keinen daran hindern, sich alles mit status=construction undifferenziert als braune Baugrube rendern zu lassen. Aber wenn dies nun zum Anlass genommen wird, zu postulieren, dass man generell alle Objekte so taggen sollte, als ob sie schon existierten, und dann einfach noch ein status=construction dranhaengt, dann wuerde ich dagegenhalten und kuenftig eine Strassenbaustelle als landuse=construction_site mit note=Nordtangente Karlsruhe, Fertigstellung 2018 taggen ;-) Ich tagge oft Straßen, als ob sie jeder benutzen könnte, und hänge dann noch ein access=private dran. Irgendwie glaube ich aber nicht, dass wir uns da heute einig werden. ;-) Gute Nacht erstmal … Tordanik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Routingfähige Garmin-Karte
Hallo. Am Sonntag, 20. Juli 2008 schrieb Andreas Putzo: ..auf einen freien, *routingfähigen* OSM-nach-Garmin-Konverter.. mkgmap erstellt schließlich ganz hübsche Garmin Karten aus OSM Daten und ist GPL lizensiert. Natürlich routingfähig. Alles andere ist was für Freaks. Wenn ich meiner Tante auf ihr Garmin-Auto-Navi ne nicht-routingfähige Karte installiere, werd ich maximal ausgelacht. Und zwar unabhängig vom Umfang des Datenbestands. Gruß, Bernd -- Don't drink and su. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
