Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Am 03.02.2011 07:43, schrieb NopMap: Dann trifft es nach Deiner Ortskenntnis auf Deine Gegend nicht zu. Ich rede ausschließlich von leicht flüchtigen Einrichtungen, nicht ausgeschildert, nicht markiert, keine Tafeln und restlos verschwunden. Sowas gehört meiner Ansicht nach nicht in einen Datenbestand, nur auf der Basis daß es vielleicht mal wieder so ähnlich ungefährt in der Nähe angelegt werden könnte. Redest Du jetzt von maschinell gespurten Loipen oder meinst Skispuren von Langläufern die sich ausnahmsweise mal in einer schneearmen Gegend bei guter Schneelage durch eine Hand voll Läufer gebildet haben? Letzteres macht wenig Sinn, aber sobald maschinell gespurt wird und dies nicht nur eine einmalige Sonderveranstaltung ist sehe ich keinen Grund die Loipen zu löschen. Systembedingt wird es da immer die eine oder andere saisonale Abweichung geben. Vielleicht sollte man einfach darauf verzichte die Loipen mit anderen Verkehrswegen zu verknüpfen - ist ja auch ein eigenes Verkehrssystem bei dem andere Verkehrsteilnehmer ehr nicht erwünscht sind. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exzessive Einzelrequests an die API
Hallo Frederik, Könnte es sich um solche Seiten wie: http://datenkueche.com/osmlive/ oder http://www.khtml.org/osm/v0.63/examples/changes.html oder http://www.khtml.org/osm/v0.83/index.php (Ticker) handeln? Ich weiß nicht wie diese implementiert sind, aber sie benutzen intensiv die Changesets. Gruß Jacques Am 03.02.2011, 00:42 Uhr, schrieb Frederik Ramm frede...@remote.org: ... Kennt jemand irgendein Perl-Tool, das sowas macht? Man gibt eine Changeset-ID an und dann laedt es irgendwie was runter? Normalerweise hat man die Nodes ja alle schon, wenn man das Changeset heruntergeladen hat, aber dann macht das Skript wohl fuer jeden Node nochmal extra einen GET-Request - eventuell, um die letzte Version festzustellen? Bye Frederik ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am 02.02.2011 23:40, schrieb Frederik Ramm: Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am einfachsten ist. Was den Speicherort der Datenbank 2 betrifft, glaube ich aber, dass der potentielle Anwender es einfacher haette, wenn diese Datenbank separat waere. Die TMC-Daten beziehen sich jeweils auf ein konkretes Wegstück. Wie willst Du mit vertretbarem Aufwand sicherstellen dass die Zuordnung der Datenbank 2 das richtige Wegstück findet. Habe ich die Datenbank 2 separat vorliegen, so kann ich auf jeden Fall korrekt und exakt bestimmen, dass es sich insgesamt um die Strecke TMC-Id 1234-5678-7890-2345 handelt (oder so), und selbst wenn ich einzelne davon nun nicht in OSM finde, weiss ich trotzdem grob, wo's langgeht. Also: Wenn der Softwareschreiber/Datenaufbereiter die Datenbank 2 als echte Datenbank hat, hat er's leichter, nicht schwerer. Er hat eine zusätzliche Fehlerquelle die er berücksichtigen muss, denke nicht dass es dadurch leichter wird ein funktionierendes System aufzubauen.. Alternative wäre in OSM ein System zu schaffen dass jedem Wegstück eine eindeutige, gleichbleibende ID gibt und die entlang eines Weges ein möglichst in Folge liegen. So könnte man ein OpenTMC aufbauen bei dem in einer externen Datenbank beliebige Statusmeldungen abgelegt werden können, z.B. auch die Befahrbarkeit von Skipisten... Garry Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exzessive Einzelrequests an die API
Hallo, On 02/03/11 09:07, Jacques Nietsch wrote: Könnte es sich um solche Seiten wie: http://datenkueche.com/osmlive/ oder http://www.khtml.org/osm/v0.63/examples/changes.html oder http://www.khtml.org/osm/v0.83/index.php (Ticker) handeln? Diese Seiten basieren, soweit ich weiss, einfach darauf, dass sie die minuetlichen Updates (!= Changesets) herunterladen und auswerten. Damit gibt es kein Problem, das sind ja statisch bereitgelegte Dateien, die kann jeder so oft abrufen, wie er will. Problematisch sind die API-Requests, die jedesmal einen Datenbankzugriff erfordern. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, On 02/03/11 09:20, Garry wrote: Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am einfachsten ist. Was den Speicherort der Datenbank 2 betrifft, glaube ich aber, dass der potentielle Anwender es einfacher haette, wenn diese Datenbank separat waere. Die TMC-Daten beziehen sich jeweils auf ein konkretes Wegstück. Wie willst Du mit vertretbarem Aufwand sicherstellen dass die Zuordnung der Datenbank 2 das richtige Wegstück findet. Ich glaube, wir reden aneinander vorbei. Was ich sage, ist: Die Information, dass auf den TMC-Knoten 1234 in positiv-Richtung der TMC-Knoten 8765 folgt, sollte nicht in OSM stehen; OSM sollte sich - wenn ueberhaupt! - darauf beschraenken, zu identifizieren, wo sich der Knoten 1234 befindet. Das schafft keine zusaetzliche Fehlerquelle, sondern beseitigt eine, meiner Ansicht nach. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exzessive Einzelrequests an die API
Hallo Könnte es sich um solche Seiten wie: http://datenkueche.com/osmlive/ Das verwendet nur die minute diffs. oder http://www.khtml.org/osm/v0.63/examples/changes.html Diese Applikation kann wirklich die API belasten. Überall wo es möglich ist, wird die XAPI verwendet. Bei jedem Request sende ich meine Kontaktdaten mit und wenn es hier ein Problem geben sollte, bin ich erreichbar. Zudem ist das ganz nur Insidern bekannt und wird nur wenig verwendet. Da alle Requests über meinen Server gehen, wäre eine Sperre der IP Adresse im Notfall auch sehr einfach. oder http://www.khtml.org/osm/v0.83/index.php (Ticker) Hier werden im Wesentlichen die minute-diffs verwendet. Erst wenn der User irgendwo draufklickt gibt es einen Request auf die XAPI. liebe Grüße Bernhard handeln? Ich weiß nicht wie diese implementiert sind, aber sie benutzen intensiv die Changesets. Gruß Jacques Am 03.02.2011, 00:42 Uhr, schrieb Frederik Ramm frede...@remote.org: ... Kennt jemand irgendein Perl-Tool, das sowas macht? Man gibt eine Changeset-ID an und dann laedt es irgendwie was runter? Normalerweise hat man die Nodes ja alle schon, wenn man das Changeset heruntergeladen hat, aber dann macht das Skript wohl fuer jeden Node nochmal extra einen GET-Request - eventuell, um die letzte Version festzustellen? Bye Frederik ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exzessive Einzelrequests an die API
Hi, On 02/03/11 09:25, Bernhard Zwischenbrugger wrote: http://www.khtml.org/osm/v0.63/examples/changes.html Diese Applikation kann wirklich die API belasten. Überall wo es möglich ist, wird die XAPI verwendet. Bei jedem Request sende ich meine Kontaktdaten mit und wenn es hier ein Problem geben sollte, bin ich erreichbar. Zudem ist das ganz nur Insidern bekannt und wird nur wenig verwendet. Da alle Requests über meinen Server gehen, wäre eine Sperre der IP Adresse im Notfall auch sehr einfach. Wir haben es hier mit etwas zu tun, wo nicht nur ein changeset heruntergeladen wird, sondern danach noch fuer jeden einzelnen Node, der im Changeset erwaehnt ist, ein einzelner GET-Request geschickt wird. Das machst Du doch nicht, oder? Ausserdem suchen wir jemanden, der das Arcor-Einwahlnetz in Deutschland benutzt; auch das tut Dein Server vermutlich nicht ;) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Am 3. Februar 2011 07:43 schrieb NopMap ekkeh...@gmx.de: Joerg Fischer-2 wrote: Ich beobachte hier das Gegenteil. Es sind immer die gleichen Leute die rum rutschen und die benutzen immer die gleichen Wege. Viele Loipen, insbesondere in Wintersportgebieten, sind sogar ausgeschildert. Dann trifft es nach Deiner Ortskenntnis auf Deine Gegend nicht zu. Ich rede ausschließlich von leicht flüchtigen Einrichtungen, nicht ausgeschildert, nicht markiert, keine Tafeln und restlos verschwunden. Sowas gehört meiner Ansicht nach nicht in einen Datenbestand, nur auf der Basis daß es vielleicht mal wieder so ähnlich ungefährt in der Nähe angelegt werden könnte. Ich sehe so, dass ich nur gepflegte Langlaufrouten eintrage. Die Routen, welche durch das Querfeldeinfahren entstehen und dann nur von anderen genutzt werden, zeichne ich nicht ein. Ausgeschilderte oder auch von einem Skiverein jährlich neu gezogene Routen zeichne ich ein, auch wenn sich ihr verlauf mal um ein paar Meter verschiebt. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Ulf Lamping wrote: Da gibt es jetzt bestimmt (jemand wissender möge mich korrigieren) eine ziemliche Bandbreite zwischen ist auf Schildern und einschlägigen Büchern eingetragen und im Winter immer gespurt, über in der Hochsaison gespurt bis zu hat man einmal ausprobiert und dann nie wieder. Genau. Und bis auf Letzteres sind das IMHO sehr erhaltenswerte Daten. Das Problem der Datenaktualität würde ich dabei aber gerne den Langlaufgehern und nicht dem Tauwetter überlassen ... Dafür. Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
NopMap wrote: Ich rede ausschließlich von leicht flüchtigen Einrichtungen, nicht ausgeschildert, nicht markiert, keine Tafeln und restlos verschwunden. Wie entscheidest Du ob Du löschst? Nur in einer Dir sehr gut bekannten Gegend, wenn Du selbst Skifahrer bist und genau weißt, dort ist dreimal im Leben Einer lang gefahren und sonst nichts? Dann ACK. In fremder Gegend im Wald stehend, ups, hier ist was eingezeichnet, da ist doch gar nichts, lösch ich mal eben schnell? Dann bin ich immer noch dagegen. In unseren Daten sind wirklich eine Menge Dinge die *ich* als überflüssig ansehe. Beginnend bei liebevoll mit Mastnummer, Anzahl der Adern und Spannung eingetragenen Hochspannungsmasten über einzelne Bäume mit Artenangabe und Höhe (ja, hab ich schon gesehen) bis hin zum Puff. Ich käm aber nicht auf die Idee die alle löschen zu wollen nur weil sie *mich* nicht interessieren und irgendwie beim editieren stören. Da hat nämlich auch jemand mit viel Mühe und Fleiß lange dagestanden und das alles erfasst, dessen Arbeit ich zerstöre. Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am 03.02.2011 09:26, schrieb Frederik Ramm: Hallo, On 02/03/11 09:20, Garry wrote: Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am einfachsten ist. Was den Speicherort der Datenbank 2 betrifft, glaube ich aber, dass der potentielle Anwender es einfacher haette, wenn diese Datenbank separat waere. Die TMC-Daten beziehen sich jeweils auf ein konkretes Wegstück. Wie willst Du mit vertretbarem Aufwand sicherstellen dass die Zuordnung der Datenbank 2 das richtige Wegstück findet. Ich glaube, wir reden aneinander vorbei. Was ich sage, ist: Die Information, dass auf den TMC-Knoten 1234 in positiv-Richtung der TMC-Knoten 8765 folgt, sollte nicht in OSM stehen; OSM sollte sich - wenn ueberhaupt! - darauf beschraenken, zu identifizieren, wo sich der Knoten 1234 befindet. Das schafft keine zusaetzliche Fehlerquelle, sondern beseitigt eine, meiner Ansicht nach. Ich glaube es wäre in OSM einfacher abzubilden und für die Router einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an die entsprechenden OSM-Wege tagt. Bsp: Auf dem OSM-Weg verläuft nur eine Richtung: (1234)---(5678) -- TMC:forward=1234:5678 oder (1234)---(5678) -- TMC:backward=1234:5678 Auf dem OSM-Weg verlaufen beide Richtungen: (1234)---(5678) TMC:forward=1234:5678 und TMC:backward=5678:1234 oder (1234)---(5678) TMC:backward=1234:5678 und TMC:forward=5678:1234 Der Algorithmus bekommt als Input gesagt, zwischen 1234 und 5678 ist in positiver Richtung Stau. Positive Richtung bedeutet für ihn: Suche alle Wege, die TMC:forward=1234:5678 und TMC:backward=1234:5678 haben und sperre diese in die entsprechende Wayrichtung fürs Routing. Viele Grüße Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exzessive Einzelrequests an die API
On 2011-02-03 09:32, Frederik Ramm wrote: Hi, On 02/03/11 09:25, Bernhard Zwischenbrugger wrote: http://www.khtml.org/osm/v0.63/examples/changes.html Diese Applikation kann wirklich die API belasten. Überall wo es möglich ist, wird die XAPI verwendet. Bei jedem Request sende ich meine Kontaktdaten mit und wenn es hier ein Problem geben sollte, bin ich erreichbar. Zudem ist das ganz nur Insidern bekannt und wird nur wenig verwendet. Da alle Requests über meinen Server gehen, wäre eine Sperre der IP Adresse im Notfall auch sehr einfach. Wir haben es hier mit etwas zu tun, wo nicht nur ein changeset heruntergeladen wird, sondern danach noch fuer jeden einzelnen Node, der im Changeset erwaehnt ist, ein einzelner GET-Request geschickt wird. Das machst Du doch nicht, oder? Wenn in einem changeset ein way verhanden ist bei dem nur die tags geändert sind, werden die nodes zum way nicht mir dem changeset mitgeliefert. Um diesen way auf der Karte darstellen zu können lade ich dann die nodes. Das sind aber keine Einzelrequests. Es werden immer mehrere Nodes gleichzeitg abgefragt. Bei GET Requests ist die Anzahl der Nodes die man mit einem einzelnen Request abfragen kann durch die URL-Länge beschränkt. Schön wäre wenn die Changesets ein bisschen mehr Informationen enthalten würden. Changesets ändern sich nie und das könnte man auch am OSM Server Cachen. Ich cache das zwar auch, weil das aber wenig verwendet wird greift der Cache kaum. Ausserdem suchen wir jemanden, der das Arcor-Einwahlnetz in Deutschland benutzt; auch das tut Dein Server vermutlich nicht ;) Ich bin das nicht. Gibt es eine Möglichkeit rauszufinden wie sehr mein Tool die DB belastet? Die IP 88.198.70.26. Mittelfristig werde ich eine eigene DB haben. liebe Grüße Bernhard Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am 3. Februar 2011 10:05 schrieb Henning Scholland o...@aighes.de: Ich glaube es wäre in OSM einfacher abzubilden und für die Router einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an die entsprechenden OSM-Wege tagt. Bsp: Auf dem OSM-Weg verläuft nur eine Richtung: (1234)---(5678) -- TMC:forward=1234:5678 oder (1234)---(5678) -- TMC:backward=1234:5678 Auf dem OSM-Weg verlaufen beide Richtungen: (1234)---(5678) TMC:forward=1234:5678 und TMC:backward=5678:1234 oder (1234)---(5678) TMC:backward=1234:5678 und TMC:forward=5678:1234 Der Algorithmus bekommt als Input gesagt, zwischen 1234 und 5678 ist in positiver Richtung Stau. Positive Richtung bedeutet für ihn: Suche alle Wege, die TMC:forward=1234:5678 und TMC:backward=1234:5678 haben und sperre diese in die entsprechende Wayrichtung fürs Routing. Klingt gut. Jedoch müssen die Punkte trotzdem in den Daten bleiben, denn es gibt ja noch Meldungen wie Kreuzung/Abfahrt gesperrt. Desweiteren sind Land und Listen-Nummer noch nicht im Schlüssel oder Wert. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Der Doppelpunkt
Hi. Die Diskussionen zu TMC, aber auch zu Rad- und Fußwegen und vielem anderen, vor allem gepaart mit dem Argument zu vieler Tags an Objekten lässt mich jetzt wiederholt darüber nachgrübeln, warum die praktische Erfindung des Doppelpunkts nicht sinnvoll die Arbeit der Mapper erleichtern könnte - über die Strukturierung von Tags hinaus. Soweit ich das sehe, wird der Doppelpunkt vor allem dazu genutzt, entweder thematische Prefixe zu bilden (z.B. TMC), oder aber Teilaspekte eines Objekts getrennt zu betrachten (z.B. footway:* oder footway:left:*) Eine nicht vollständige Durchsicht der Tags mit Doppelpunkt über taginfo [1] bestätigt das zunächst - Ausnahmen will ich jedoch nicht ausschließen. (@Frederik: Die Suche nach dem Unterstrich scheint nicht zu funktionieren bzw. alle Tags zurückzugeben - ist das gewollt bzw. wie kann man das maskieren/umgehen?) Dies ist also sowas wie Common Practice in OSM; Für API 0.7 ist zudem auch vorgeschlagen, Entsprechende Namensräume für Abfragen zu unterstützen [2]. Zwei Dinge stören mich dabei aber noch... 1) Es ist nirgendwo als Richtlinie dokumentiert; 2) Warum nicht im Editor unterstützen? Sowohl JOSM als auch Potlatch stellen Tags mindestens im Roh-Modus als Key-Value-Liste dar. Dabei werden die Tags teilweise Alphabetisch sortiert. Die Sortierung sorgt sowieso schon dafür, dass die durch Doppelpunkte gebildeten Namensräume beieinander liegen. Ich würde mir wünschen, dass diese Blöcke gemeinsam einklapp-bar sind; was einen Teil der zu-viele-Tags-Problematik lösen würde. Hat ein Weg einen durch Tags beschriebenen Bürgersteig, dann ist das die Information, die ich auch dann brauche, wenn ich den Weg als ganzes bearbeite; nicht aber, welche Oberfläche dieser Fußweg hat, ob er links oder rechts verläuft, wo dabei Fahrräder fahren dürfen etc. Ähnliches gilt für TMC; fast gilt sowas auch für Adressen (addr:*), wobei diese vermutlich seltener ausgeblendet werden würden. Zunächst würde ich mich vor allem über Meinungen freuen: Gibt es Argumente gegen eine solche Kategorisierung? Habe ich Strömungen gegen den Doppelpunkt übersehen? und so weiter. Gruß Peter [1] http://taginfo.openstreetmap.de/search?q=%3A#keys [2] http://wiki.openstreetmap.org/wiki/API_v0.7#Support_to_download_queries_like_addr:.2A.3D.2A ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] thermosolar = photovoltak ??
hi ! in Spanien gibt es ein riesiges Thermosolar-Kraftwerk [1], [2] - ist das eigentlich dasselbe wie ein Solarkraftwerk oder welches Tag würdet Ihr dafür verwenden ? Gruß Jan :-) [1] http://es.wikipedia.org/wiki/Andasol [2] http://www.openstreetmap.org/?lat=37.2275lon=-3.0619zoom=14layers=M [3] http://wiki.openstreetmap.org/wiki/DE:Key:generator:source ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] thermosolar = photovoltak ??
Hallo! Photovoltaik und Solarthermie sind zwei verschiedene Arten, die Sonnenenergie zu nutzen, und sind deutlich von einander abzugrenzen. Photovoltaik ist die direkte Art, aus Sonnenenergie Strom zu erzeugen. Solarthermie hingegen wärmt zunächst eine Flüssigkeit auf (bspw. behandeltes Wasser, teilweise auch Flüssigkeiten, die höhere Temperaturen annehmen können). Wie die Wärme dieser Flüssigkeit genutzt wird, steht dann auf einem anderen Blatt. In den meisten Haushalten mit Solarthermie wird damit Warmwasser erzeugt. Solarthermie kann auch dazu verwendet werden, um Strom aus der Sonne zu gewinnen, wird dann dennoch nicht als Photovoltaik bezeichnet. Gruß, Philip signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] thermosolar = photovoltak ??
Hi Jan, Solarkraftwerk ist nur der Oberbegriff für viele Techniken. Hauptsache sie wandeln Sonneneinstrahlung in nutzbarere Energie um. Das passiert bei Andasol offensichtlich. Also wäre generator:source=solar richtig. Um auf deinen Betreff zu antworten: Thermosolarkraftwerke sind nicht das gleiche wie Photovoltaik. Ersteres bündelt mit Spiegeln das Licht (ähnlich einer Linse) auf eine kleinere Fläche und wandelt die entstehende Wärme in el. Energie um (ist also Thermodynamik). Photovoltaik wandelt Sonnenlich direkt in el. Energie um. Das sind auch die Dinger, die auf privaten Dächern Strom produzieren. VG Christian hi ! in Spanien gibt es ein riesiges Thermosolar-Kraftwerk [1], [2] - ist das eigentlich dasselbe wie ein Solarkraftwerk oder welches Tag würdet Ihr dafür verwenden ? Gruß Jan :-) [1] http://es.wikipedia.org/wiki/Andasol [2] http://www.openstreetmap.org/?lat=37.2275lon=-3.0619zoom=14layers=M [3] http://wiki.openstreetmap.org/wiki/DE:Key:generator:source ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, On 02/03/11 10:05, Henning Scholland wrote: Ich glaube es wäre in OSM einfacher abzubilden und für die Router einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an die entsprechenden OSM-Wege tagt. Wuerde dies nicht zu einer noch groesseren Inflation von TMC-Tags fuehren, weil nun saemtliche Ways zwischen zwei Punkten getaggt werden muessten? Bsp: Auf dem OSM-Weg verläuft nur eine Richtung: (1234)---(5678) -- TMC:forward=1234:5678 oder (1234)---(5678) -- TMC:backward=1234:5678 Was waere der Unterschied zwischen TMC:forward=1234:5678 und TMC:backward=5678:1234? Was waere, wenn ich ueberhaupt keine Nodes und Ways taggen wuerde, sondern stattdessen aussschliesslich Relationen anlegen wuerde, und zwar eine pro TMC-Segment, mit den Tags tmc:from=1234 tmc:to=5678 (von mir aus noch Land und Listennummer und so, aber das scheint mir ziemlich uebertrieben zu sein - Land wuerde ich maximal im Grenzbereich verwenden, und welche praktische Relevanz die Listennummer hat, hab ich noch nicht verstanden) und dann noch mit einer Reihe von Members. Dabei wird es oft reichen, als Member nur einen Node an jedem Ende anzugeben; man muss nicht jedes Wegstueck, das zwischen den beiden liegt, der Relation hinzufuegen, aber man kann, wenn es zur Vermeidung von Missverstaendnissen notwendig ist. (Wenn ich einem Router sage, er soll die Punkte Autobahnkruez Wiesbaden und Abfahrt Niedernhausen meiden, dann brauche ich ihm nicht noch zusaetzlich zu sagen, dass er die 10 Autobahn-Ways dazwischen auch meiden soll, das ergibt sich automatisch.) Wenn man unbedingt will, kann man auch eventuelle Kindrelationen als Member einbauen und dadurch die Hierarchie nachbilden. Aber eigentlich bin ich noch nicht ueberzeugt, dass wir die Segmente ueberhaut bei uns speichern sollten; vielleicht ist es besser, ueber Relationen abzubilden: Diese Punkte hier gemeinsam bilden das AK Wiesbaden und das hat die TMC-ID 1234 (so eine Relation haette auch anderen Nutzen, z.B. ein Renderer koennte auf einer kleinen Zoomstufe das ganze Autobahnkreuz durch einen Punkt symbolisieren und mit einem Label beschriften). Den tatsaechlichen TMC-Graphen (auf Punkt 1234 folgt in Positivrichtung der Punkt 6543) koennte man dann ausserhalb lagern. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hi, Henning Scholland schrieb: Am 03.02.2011 09:26, schrieb Frederik Ramm: Hallo, On 02/03/11 09:20, Garry wrote: Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am einfachsten ist. Was den Speicherort der Datenbank 2 betrifft, glaube ich aber, dass der potentielle Anwender es einfacher haette, wenn diese Datenbank separat waere. Die TMC-Daten beziehen sich jeweils auf ein konkretes Wegstück. Wie willst Du mit vertretbarem Aufwand sicherstellen dass die Zuordnung der Datenbank 2 das richtige Wegstück findet. Ich glaube, wir reden aneinander vorbei. Was ich sage, ist: Die Information, dass auf den TMC-Knoten 1234 in positiv-Richtung der TMC-Knoten 8765 folgt, sollte nicht in OSM stehen; OSM sollte sich - wenn ueberhaupt! - darauf beschraenken, zu identifizieren, wo sich der Knoten 1234 befindet. Das schafft keine zusaetzliche Fehlerquelle, sondern beseitigt eine, meiner Ansicht nach. Ich glaube es wäre in OSM einfacher abzubilden und für die Router einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an die entsprechenden OSM-Wege tagt. Bsp: Auf dem OSM-Weg verläuft nur eine Richtung: (1234)---(5678) -- TMC:forward=1234:5678 oder (1234)---(5678) -- TMC:backward=1234:5678 Auf dem OSM-Weg verlaufen beide Richtungen: (1234)---(5678) TMC:forward=1234:5678 und TMC:backward=5678:1234 oder (1234)---(5678) TMC:backward=1234:5678 und TMC:forward=5678:1234 Der Algorithmus bekommt als Input gesagt, zwischen 1234 und 5678 ist in positiver Richtung Stau. Positive Richtung bedeutet für ihn: Suche alle Wege, die TMC:forward=1234:5678 und TMC:backward=1234:5678 haben und sperre diese in die entsprechende Wayrichtung fürs Routing. sowas in der Art wollte ich in meinem Vortrag auf der #FOSSGIS auch präsentieren, oder zumindest zur Diskussion stellen. Wenn ich mich gerade nicht ganz täusche macht das TeleAtlas in seinen Daten auch so ... viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] thermosolar = photovoltak ??
Ich unterscheide die Art mit dieser Erweiterung [1] Viele Grüße Dietmar [1] http://wiki.openstreetmap.org/wiki/Key:generator:method -Ursprüngliche Nachricht- Von: chr_bra...@gmx.de [mailto:chr_bra...@gmx.de] Gesendet am: Donnerstag, 3. Februar 2011 10:40 An: o...@tappenbeck.net; Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] thermosolar = photovoltak ?? Hi Jan, Solarkraftwerk ist nur der Oberbegriff für viele Techniken. Hauptsache sie wandeln Sonneneinstrahlung in nutzbarere Energie um. Das passiert bei Andasol offensichtlich. Also wäre generator:source=solar richtig. Um auf deinen Betreff zu antworten: Thermosolarkraftwerke sind nicht das gleiche wie Photovoltaik. Ersteres bündelt mit Spiegeln das Licht (ähnlich einer Linse) auf eine kleinere Fläche und wandelt die entstehende Wärme in el. Energie um (ist also Thermodynamik). Photovoltaik wandelt Sonnenlich direkt in el. Energie um. Das sind auch die Dinger, die auf privaten Dächern Strom produzieren. VG Christian hi ! in Spanien gibt es ein riesiges Thermosolar-Kraftwerk [1], [2] - ist das eigentlich dasselbe wie ein Solarkraftwerk oder welches Tag würdet Ihr dafür verwenden ? Gruß Jan :-) [1] http://es.wikipedia.org/wiki/Andasol [2] http://www.openstreetmap.org/?lat=37.2275lon=-3.0619zoom=14layers=M [3] http://wiki.openstreetmap.org/wiki/DE:Key:generator:source ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hi, Frederik Ramm schrieb: On 02/03/11 10:05, Henning Scholland wrote: Ich glaube es wäre in OSM einfacher abzubilden und für die Router einfacher auszuwerten, wenn man nicht die TMC-Knoten einträgt, sondern die Abschnitte zwischen den TMC-Knoten eine ID gibt und diese dann an die entsprechenden OSM-Wege tagt. Wuerde dies nicht zu einer noch groesseren Inflation von TMC-Tags fuehren, weil nun saemtliche Ways zwischen zwei Punkten getaggt werden muessten? Dies ist/wäre ein Nachteil bei diesem Verfahren ... Aber sehr gut um TMCs Sachen in einem Router oder auf der Karte darzustellen. Bsp: Auf dem OSM-Weg verläuft nur eine Richtung: (1234)---(5678) -- TMC:forward=1234:5678 oder (1234)---(5678) -- TMC:backward=1234:5678 Was waere der Unterschied zwischen TMC:forward=1234:5678 und TMC:backward=5678:1234? Was waere, wenn ich ueberhaupt keine Nodes und Ways taggen wuerde, sondern stattdessen aussschliesslich Relationen anlegen wuerde, und zwar eine pro TMC-Segment, mit den Tags Man muss hier mit den Begriffen etwas aufpassen. Ein TMC-Segment enthält bei TMC mehrere Untersegmente. Die eigentlichen TMC-Segmente werden ja bereits in OSM importiert, was wir aber meiner Meinung nach brauchen ist eine Darstellung der (ich nenne es jetzt mal) Untersegmente. Also von wo nach wo geht das Untersegment von LCL:1234 to LCL:1235. Denn genau diese brauche ich bei der Verarbeitung von TMC-Nachrichten. Aber dein Vorschlag diese ebenfalls mit Hilfe von Relations abzubilden könnte vlt. besser sein, als die TMC Codes an alles beteiligten Ways zu haengen. Stift und Papier zum Malen wäre jetzt hilfreich ... :) viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Exzessive Einzelrequests an die API
Hallo, On 02/03/11 10:06, Bernhard Zwischenbrugger wrote: Wenn in einem changeset ein way verhanden ist bei dem nur die tags geändert sind, werden die nodes zum way nicht mir dem changeset mitgeliefert. Um diesen way auf der Karte darstellen zu können lade ich dann die nodes. Das sind aber keine Einzelrequests. Es werden immer mehrere Nodes gleichzeitg abgefragt. Du koenntest auch den /way/1234/full-Ansatz benutzen. Was leider nicht geht, ist die Abfrage *mehrerer* Ways gleichzeitig als /full. Der User, den wir hier suchen, bzw. das Tool, weiss aber nichts von der Moeglichkeit, mehrere Nodes gleichzeitig abzufragen, und fragt jeden einzeln ab. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, Sorry meinen grundsätzlichen Einwurf... Ich kenne TMC etwas und interessiere mich immer, wie ein externe Fachinformationssysteme (FIS) und OSM zusammenarbeiten können und kann Frederiks Bedenken in diesem Falle nachvollziehen. Nun scheint ja ein Kompromiss zu entstehen, denn eine Löschung von FIS-Daten wäre schon FIES :- Nur tmc_id=8326765 scheint mir ev. etwas zuwenig zu sein, denn oft möchte ein SW-Client die Infos möglichst direkt haben. Also sollte meiner der Kompromiss nochmals auf wenige weitere Tags ausgedehnt werden zu müssen. Man denke da z.B. an die Situation, wo OSM bei Katastrophen real-time (wie TMC) helfen will, und Brücken/Strassen als unpasierbar kennzeichnen. Die Tags sollten aber auf jeden Fall menschenlesbar sein (Präfix hin oder her). Weiter schrieb Frederik am 2. Februar 2011 23:40: Wir haben hier ja sozusagen drei verschiedene Datenbanken: 1. OSM 2. Das TMC-Netz, das wir auf OSM abbilden 3. aktuelle Verkehrsdaten, die auf das TMC-Netz abgebildet werden Um 3 brauchen wir uns nicht zu kuemmern. Wer pflegt die Datenbank 2, also das TMC-Netz an sich - gibt es da regelmaessig neue TMC-Nodes oder Aenderungen inden bestehenden, oder ist das weitgehend statisch? 2. ist eine Geometrie und die ändert nicht so schnell (mindestens die Hauptrouten/Knoten). Solche Geometrien - konkret: Way oder Relation über Ways - kennen wir doch schon beim öffentlichen Verkehrsnetz (z.B. S-Bahn). Da sehe ich grundsätzlich keinen Unterschied und würde das in OSM dulden. Fazit: FIS sollen OSM nutzen können unter bestimmten Bedingungen (u.a. Zurückhaltung). Habe dazu eine Wiki-Seite eröffnet: http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS . Nur zu mit Editieren... = Gibt es gute Beispiele zur Nutzung von OSM durch FIS? LG, -S. P.S. Die vielen Opengeodb-Tags stören mich (auch) schon lange. Sind die nicht veraltet? Kann man ev. nicht mal die löschen? Am 2. Februar 2011 23:40 schrieb Frederik Ramm frede...@remote.org: Hallo, On 02/02/11 23:17, Ulf Lamping wrote: Bist Du auch davon ueberzeugt, dass diese Daten in OSM direkt enthalten sein muessen, um genutzt werden zu koennen? Ich bin davon überzeugt, das diese Daten direkt in OSM enthalten sein sollten, wenn der Aufwand für einen potentiellen Anwender der Daten ungleich geringer ist als diese seperat zu pflegen. Das ist hier aus meiner Sicht der Fall. Wir haben hier ja sozusagen drei verschiedene Datenbanken: 1. OSM 2. Das TMC-Netz, das wir auf OSM abbilden 3. aktuelle Verkehrsdaten, die auf das TMC-Netz abgebildet werden Um 3 brauchen wir uns nicht zu kuemmern. Wer pflegt die Datenbank 2, also das TMC-Netz an sich - gibt es da regelmaessig neue TMC-Nodes oder Aenderungen inden bestehenden, oder ist das weitgehend statisch? 1 pflegen wir sowieso. Derzeit ist in OSM sowohl die Abbildung 1-2 als auch, wie mir scheint, die komplette Datenbank 2 erhalten (oder es ist zumindest als Zielzustand so geplant). Der potentielle Anwender ist also einer, der irgendwas programmiert, was Meldungen aus der Datenbank 3 annimmt und auf der Datenbank 1 anzeigt und sich dazu die 2 und deren Abbildung 1-2 zunutze macht. Vermutlich hast Du recht, dass die Pflege des 1-2-Mappings in OSM am einfachsten ist. Was den Speicherort der Datenbank 2 betrifft, glaube ich aber, dass der potentielle Anwender es einfacher haette, wenn diese Datenbank separat waere. Ohne jetzt die genauen Details zu kennen, scheint mir das Vorgehen ja so: Es kommt eine Meldung von TMC-Id 1234 bis TMC-Id 2345 ist Zustand ABCD. Es gilt nun, zunaechst herauszufinden, welche TMC-Ids alle zwischen 1234 und 2345 liegen, dann, diese auf der Karte zu identifizieren, und dann das ganze einzuzeichnen bzw, herumzurouten. Wenn ich nun anstatt einer sauberen TMC-Datenbank 2, die einfach eine komplette Liste aller Knoten und Kanten des TMC-Graphen enthaelt, die derzeit in OSM vorliegende Schlaglicht-Sichtweise habe, bedeutet das, dass ich mir zuerst alle TMC-IDs aus OSM heraussuchen muss, dann anhand der next/previous-IDs mit einen Graphen aufbauen, der im worst case sogar lueckenhaft sein wird (ein einzelner fehlender Node reisst da ja schon ganze Verbindungen ein). Habe ich die Datenbank 2 separat vorliegen, so kann ich auf jeden Fall korrekt und exakt bestimmen, dass es sich insgesamt um die Strecke TMC-Id 1234-5678-7890-2345 handelt (oder so), und selbst wenn ich einzelne davon nun nicht in OSM finde, weiss ich trotzdem grob, wo's langgeht. Also: Wenn der Softwareschreiber/Datenaufbereiter die Datenbank 2 als echte Datenbank hat, hat er's leichter, nicht schwerer. Oder? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kraftwerks-Karte (war: Open Windrad Map)
Am 02.02.2011 18:41, Stephan Wolff: Am 02.02.2011 14:43, schrieb Claudius: Am 02.02.2011 11:28, Stephan Wolff: Ich arbeite an einer Karte zu Kraftwerken und Stromnetzen. Wäre toll, wenn du dabei auch das erweiterte Schema http://wiki.openstreetmap.org/wiki/Key:generator:source für Quelle und Art der Stromerzeugung unterstützen könntest. generator:source und generator:output:electricity werden ausgewertet. Was vermisst du? Sorry, Ich hatte die falsche Schlußfolgerung gezogen, weil Solarkraftwerke auf deiner Karte mit dem generischen weißen Kraftwerkssymbol angezeigt werden. Wie beispielsweise hier das Solarkraftwerk Espenhain: http://toolserver.org/~osm/styles/?zoom=13lat=51.18983lon=12.44587layers=F0FFF0FFFB000T Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] XAPI vs. API
Hallo, ich nutze XAPI, um eine mit OpenLayers gebaute, auf Openstreetmap basierte, Vereinskarte mit einigen POIs aufzubereiten. Die POIs habe ich via GPS erfasst und in der OpenStreetMap-Datenbank eingepflegt. Um mögliche Änderungen mitzubekommen, hole ich die Daten (Nodes in einem bestimmten Bereich) täglich via Cron-Job ab. Allerdings wird XAPI mehr und mehr unbenutzbar. Gegen sporadische Ausfälle ist mein Script auf dem Server gewappnet. Wenn der Server innerhalb einer bestimmten Zeit nicht antwortet, dann wird abgebrochen. Mein System läuft dann von meinem eigenen (dann eben nicht aktuellen) Cache-File. Die Benutzer merken davon nichts. Was in letzter Zeit abgeht ist aber kein sporadischer Ausfall mehr, sondern man bekommt dann und wann tagelang garkeine Antwort vom Server. Neu erfasste Punkte bekomme ich so nicht auf die Vereinskarte. Eine Suche im Wiki ergab keinen Hinweis darauf, dass die offizielle API nicht für die Nutzung beim Generieren z.B. einer Vereinskarte genutzt werden darf. Es geht in meinem Fall um eine genau bekannte Gruppe von Nodes, denn die OSM-Nodes werden mit Daten aus meiner eigenen Datenbank (Fotos) aufgewertet. Nodes für die meine DB kein Foto hat, interessieren mich nicht. Ich würde also mit einer einzigen nodes?nodes=...-Anfrage täglich auskommen und so gezielt die Nodes, die ich suche, via ID anfragen. Es geht um etwa 40 Nodes. Spricht etwas *gravierendes* dagegen, dass ich meine Script auf die offizielle API umbaue? Eine einzige nodes-Anfrage geht vermutlich in der Vielzahl an Anfragen schlicht unter. Bei meinen täglichen Editierarbeiten an der OSM erzeuge ich vermutlich ein hundertfaches an Traffic. IMHO sollte es dann doch kein Problem sein, meine erfassten Daten auch zu nutzen. Und um die Diskussion im Voraus abzuwürgen: Planet-File ist indiskutabel! Ich brauche 40 Nodes und nicht ganz Bayern! Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
On Wed, Feb 02, 2011 at 03:26:28PM +0100, Jan-Benedict Glaw wrote: ...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur gesprochen vom Radio-Moderator, sondern wird eben auch via TMC übertragen. NA - an der Grenze fuer NRW sind die Daten aber dran - Also der TMC Location code ... http://www.openstreetmap.org/browse/relation/62761 So weit ich weiss bezieht sich TMC auch immer auf administrative Grenzen und eben die wollen wir in OSM auch haben. Flo -- Florian Lohoff f...@zz.de Professionell gesehen bin ich zu haben signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
On Wed, Feb 02, 2011 at 07:11:16PM +0100, malenki wrote: NopMap schrieb: Von daher würde ich anregen, Langlaufloipen, die abgetaut sind bzw. allgemein formuliert die vor Ort absolut nicht mehr nachvollziehbar sind, konsequenterweise auch aus dem Datenbestand zu löschen. Konsequent aus deiner Sicht wäre sicher, die erst gar nicht zu erfassen, oder? ... und ich frage mich warum ich mir extra eine Loipenkarte für mein Gebiet hier gekauft habe - muß ich die im Frühjahr verbrennen? Im Ernst: Natürlich ändern sich auch mal Loipen, weil sie teilweise nicht mehr passierbar sind (Baumbruch etc.) aber das ist auch bei Wegen der Fall. Die Änderungs-Frequenz ist halt bei wegen nicht so groß. Prinzipiell gibt OSM an: Hier ist eine Loipe ... und wenn man vor Ort feststellt, daß die sich geändert hat wird halt die Änderung nachgeführt. Die Eigenschaft Loipenroute besteht auch im Sommer (genau wie bei einer im Bau befindlichen Straße nach wie vor eine Straße ist). Die Eigenschaft befahrbahr oder nicht wäre ein interessantes Feature - ich glaube nur nicht, daß man das zuverlässig pflegen kann und würde das daher eher dem gesunden Menschenverstand überlassen. Viele Grüße Andreas. -- http://fam-tille.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] XAPI vs. API
Hallo, On 02/03/11 12:06, Manuel Reimer wrote: Eine Suche im Wiki ergab keinen Hinweis darauf, dass die offizielle API nicht für die Nutzung beim Generieren z.B. einer Vereinskarte genutzt werden darf. Das ist auch nicht der Fall. So richtig deutlich steht das nirgends. Klar ist, dass die offizielle API eigentlich eine Editing API ist - sie ist in der Hauptsache zum Editieren gedacht, und alle Zugriffe, die mit dem Editieren in Zusammenhang stehen, sind legitim. Die API wird aber auch benutzt, um auf den Webseiten Objekte anzuzeigen, also wenn Du z.B. http://www.openstreetmap.org/browse/way/97162579 aufrufst, kommen die Daten auch von der API. Und ein Klick auf diesen Link macht schon mehr last auf der API als der von Dir skizzierte Nodes-Request mit 40 IDs. Also, langer Rede kurzer Sinn, Du hast zwar kein verbrieftes Recht, die API fuer Deinen Zweck zu benutzen, aber diese Nutzung ist voellig unproblematisch. Andere Leute machen eine sechsstellige Anzahl von Abfragen am Tag, bis sie endlich gesperrt werden ;) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
On Thu, 2011-02-03 12:13:29 +0100, Florian Lohoff f...@zz.de wrote: On Wed, Feb 02, 2011 at 03:26:28PM +0100, Jan-Benedict Glaw wrote: ...und in ganz NRW gibts Nebel und Eisregen. Sowas kommt nicht nur gesprochen vom Radio-Moderator, sondern wird eben auch via TMC übertragen. NA - an der Grenze fuer NRW sind die Daten aber dran - Also der TMC Location code ... http://www.openstreetmap.org/browse/relation/62761 So weit ich weiss bezieht sich TMC auch immer auf administrative Grenzen und eben die wollen wir in OSM auch haben. Na, das schreib' ich doch! Via TMC wird eben nicht nur über Verkehrsbehinderung an Straßenzügen berichtet, sondern eben auch in Polygonen (zumeist Kreise bzw. Bundesländer.) MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: The course of history shows that as a government grows, liberty the second : decreases. (Thomas Jefferson) signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] cycleway=track vs. cycleway=opposite_track
Hi, NEIN. Die Heidelberger Radfahrer halten es wohl nicht besonders mit der StVO. Laut StVO [1] gilt das Verkehrszeichen 220 (Einbahnstraße) sowie Verkehrszeichen 250 (Verbot für Fahrzeuge aller Art) auch für Radfahrer. In diesem Fall kann man für einen Radweg cycleway:track mappen. Cycleway=opposite_track ist nur möglich wenn unter dem Verkehrszeichen 220 (Einbahnstraße) das Zusatzschild 1000-33 (Radfahrer im Gegenverkehr) oder unter dem Verkehrszeichen 250 (Verbot für Fahrzeuge aller Art) das Zusatzschild 1022-10 (Radfahrer frei) hängt. [1] http://de.wikipedia.org/wiki/Bildtafel_der_Verkehrszeichen_in_Deutschland Mit freundlichen Grüßen Stephan aka smarties Original-Nachricht Datum: Wed, 02 Feb 2011 22:32:21 +0100 Von: Pascal Neis pascal.n...@gmail.com An: talk-de@openstreetmap.org Betreff: [Talk-de] cycleway=track vs. cycleway=opposite_track Hi, bin vor ein paar Tagen auf ein Fahrrad-Routing-Problem mit Ways die ein cycleway=track-Tag besitzen aufmerksam gemacht worden. (danke Sven :) ) Folgendes Problem: Darf ein Way der als cycleway=track und auch als Einbahnstraße getaggt ist in verkehrter Richtung mit dem Fahrrad befahren werden ? Laut der Tag-Beschreibung im Wiki[1] eher nein! Ansonsten müsste er als cycleway=opposite_track gemappt sein. Laut Tagwatch gibt es um einige mehr cycleway=track als cycleway=opposite_track vgl.[2]. Sollte aber dennoch ein Way mit cycleway=track mit dem Fahrrad in falscher Richtung befahrbar sein ? In Heidelberg machen das alle Radfahrer so ... :) dankeviele gruesse pascal [1] http://wiki.openstreetmap.org/wiki/DE:Key:cycleway?uselang=de [2] http://tagwatch.stoecker.eu/Germany/De/keystats_cycleway.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Luftbildrätzel II
HI ! jetzt habe ich mal ein Bild und wüßte gerne was es in Spanien ist. Das Bild findet sich unter http://www.tappenbeck.net/forum/osm/osm_luftbild_20110203.jpg Das Bild entstammt http://www.openstreetmap.org/?lat=37.29269lon=-3.18485zoom=17. ...? Hat einer eine Idee ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am 03.02.2011 10:44, schrieb Frederik Ramm: Hallo, On 02/03/11 10:05, Henning Scholland wrote: Bsp: Auf dem OSM-Weg verläuft nur eine Richtung: (1234)---(5678) -- TMC:forward=1234:5678 oder (1234)---(5678) -- TMC:backward=1234:5678 Was waere der Unterschied zwischen TMC:forward=1234:5678 und TMC:backward=5678:1234? Das forward bzw. backward sollte die Richtung des Verkehrsstromes in Bezug auf die Wegrichtung in den OSM-Daten anzeigen. Bei oneway=yes hätte man typischerweise forward und bei oneway=-1 hätte man backward. Auf einem Weg mit zwei Verkehrsrichtungen wäre es nötig um nur eine Richtung sperren zu können. Man könnte es auch über Relationen machen, da hast du recht. Für das allgemeine Verständnis finde ich die Variante über Wege (meinetwegen auch Relationen) zu gehen einfacher als wenn man nur irgendwelche Knoten einträgt. Man selektiert den betreffenden Weg und hat die Info im Sichtfeld und kann diese bearbeiten und muss nicht erst nodes suchen. Die Idee ist sicher nicht perfekt, sondern wäre meiner Meinung nach verständlich und für Router einfach auszuwerten. Weil theoretisch gäbe es unendlich viele Möglichkeiten zwei Punkte mit einander zu verbinden. Welches nun der richtige Weg ist, wäre meiner Meinung nach mehr raterei. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbildrätzel II
Wie wäre es mit einem Parabolrinnenkraftwerk? http://www.google.de/images?q=Parabolrinnenkraftwerk Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Hallo, Am Donnerstag 03 Februar 2011 08:32:54 schrieb André Joost: Das aktuelle Problem ist wohl eher, ob die Loipen im Jahr 2 nach Bing noch mit den bisher in OSM erfassten Geodaten zusammenpassen. Derzeit werden ja massiv Knoten nach Luftbildern geschubst. Da passt eine nach schlechten GPS-Daten gezeichnete Spur irgendwann nicht mehr. Hochgeladene GPX-Tracks helfen da wenig, weil man ja nicht weiß, ob derhjenige auf Ski oder Sohle unterwegs war. Viele nach GPS gezeichnete Wege sind besser als das, was bing so liefert. Haufenweise nicht aneinander passende Bildansätze, Schlieren, Streifen etc. In unebenem Gelände durch die Schrägaufnahmen ein reines Glückspiel, ob der Weg passt oder nicht. Bing ist eine Hilfe beim Mappen, aber ohne die Tracks unbrauchbar. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Am 02.02.2011 22:56, schrieb Frederik Ramm: Hallo, On 02/02/11 21:16, Sven Anders wrote: Mein Eindruck ist: Marcus hat sich sehr viel Mühe gemacht ein funktionierendes TMC Schema zu entwerfen. Marcus hat ein Schema fuer Maschinen entworfen. OSM ist aber fuer Menschen. Fuer Menschen ist dieses Schema nicht wartbar. Naja die Bundesanstallt für Straßenwesen pflegt ja solche Tabellen auch. Leider gab es sehr wenig Kommentare dazu. Alle die ich gerne dazu um eine Meinung gefragt hätte, haben immer nur abgewunken, und gesagt, mit TMC beschäftige ich mich nicht, da habe ich keine Zeit zu etc.. Ich meine mich zu erinnern, das ich auch dich gefragt hatte. Das ist sehr gut moeglich. Wie gesagt, normalerweise finde ich es auch das richtige Verhalten, Leute, die sich mit etwas auskennen, einfach mal machen zu lassen, und wuerde mich selber jetzt da nicht einmischen. Es draengt sich mir aber mehr und mehr der Verdacht auf, dass dieses Problem sehr suboptimal geloest wurde und an anderen Stellen Probleme schafft, und dass man daher jetzt einen Kurswechsel einleiten (oder die Notbremse ziehen) muss, bevor das Problem immer groesser wird. Wo bitte ist das Problem an anderen Stellen? Du vermutest Probleme, wenn jemand eine Schema ändert etc. aber bislang sagst du nicht ich will das und das ändern und das beißt sich mit TMC. Außer das es dir nichts gefällt, habe ich bislang nichts dazu gehört. Bist Du auch davon ueberzeugt, dass diese Daten in OSM direkt enthalten sein muessen, um genutzt werden zu koennen? Ein Teil der Daten macht IMHO nur in OSM Sinn. Die Angaben von dem Bundesamt sind an manchen Stellen so schlecht, das es auch nicht einfach zu berechnen wäre. Andere Daten wie z.B. alles was der TMC Bot ergänzt müssen nicht im OSM enthalten sein. Aber ich fände es trotzdem gut sie drinn zu habem, weil dann niemand für eine TMC Unterstützung beim Bundesamt nachfragen müsste. Sonst müssten diese Daten z.B. zusammen mit Navit ausgeliefert werden. Damit eröffnest du aber ganz klar eine Relevanz-Diskussion. Ich will nur eine Datenbank für alle Geo-Informationen. Die soll OpenStreetMap heißen. Ich hingegen werde nicht muede, jedem zu sagen, dass alles, was sinnvollerweise ausserhalb von OSM gepflegt werden kann, auch ausserhalb von OSM gepflegt werden sollte. Das ist ja ein toller Satz, die Frage ist ja was wird sinnvollerweise außerhalb gefplegt? Wo ich aber die Grenze ziehe, ist, wenn diese kompletten externen Datenbanken mit in OSM abgebildet werden (wenn jetzt zusaetzlich noch vermerkt werden soll, in welcher Richtung der naechste Mautknoten liegt, wie viele Tarifkilometer der entfernt ist, undsoweiter). *Das* sind keine Geodaten mehr. Natürlich kann ich Dir da nicht ganz widersprechen. Aber ein wenig: Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten benutzen. Natürlich gibt es Grenzen, aber bei dem was wir bislang an TMC Daten haben ist das IMHO doch nicht das Problem. Es wäre doch toll, wenn jemand für einen Mautkalkulator nur OSM Daten verwenden müsste, und dazu sind halt die Tarifkilometer wichtig. Das ist eine Relevanz-Diskussion. Wo ziehen wir die Grenze? Deine Grenze ist Geodaten. Die TMC Daten besteht eigentlich fast nur aus Geodaten, es geht ja auch nur um Zuordnung einer Verkehrsmeldung zu Geodaten. Das ist der Sinn von TMC. Aber nicht, wenn Du irgendwann damit rechnen musst, durch die Verfeinerung einer Strassengeometrie ploetzlich die akribisch erstellte next-node-id-previous-node-id-Struktur von jemand anders kaputt zu machen und der sich dann bei Dir beschwert. Ist das schon passiert? Oder ist das ein theoretisches Problem? Entschuldigung ich reite darauf vielleicht etwas rumm, aber ich hab immer noch den verstehe immer noch nicht, warum du bei dem Thema so Radikal argumentierst. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbildrätzel II
Henning Scholland osm at aighes.de writes: Wie wäre es mit einem Parabolrinnenkraftwerk? http://www.google.de/images?q=Parabolrinnenkraftwerk Henning Unwahrscheinlich, dann wären die Rinnen von West nach Ost um die Sonne von Süden her effektiv nutzen zu können Ich tippe auf irgendwelche landwirtschaftliche Lager- / Trockeneinrichtungen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, Am Mittwoch 02 Februar 2011 21:16:57 schrieb Sven Anders: sehr viel sinnvollen Text +1 Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Von OpenStreetMap abmelden
Hallo, Wie kann ich mich von OpenStreetMap abmelden? Ich möchte mich vom Wiki und von OpenStreetMap.org löschen. Gibt es nicht ein Deutsches bzw. EU-Gesetz dass das möglich sein muss? Man liest ja immer so viel in den Zeitungen darüber, wegen Datenschutz. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, On 02/03/2011 02:59 PM, Sven Anders wrote: Du vermutest Probleme, wenn jemand eine Schema ändert etc. aber bislang sagst du nicht ich will das und das ändern und das beißt sich mit TMC. Ich moechte, dass OSM nach Moeglichkeit auch weiterhin ohne Fuehrerschein bedienbar ist. Dass man sich ein bisschen reinfuchsen muss in die Art, wie OSM tickt - was sind Tags, was sind Ways usw., laesst sich nicht vermeiden. Aber dass man sich dazu noch - je nachdem, was man gerade editiert - in verschiedene Fachdatenwelten hineinfuchsen muss, dass missfaellt mir. Ich habe normalerweise keine unterdurchschnittliche Auffassungsgabe, aber fuer mich sahen und sehen diese TMC-Daten in OSM wie Kraut und Rueben aus, wie etwas, das ich ohne zusaetzliche Software nicht verstehen kann und dessen Korrektheit ich nicht pruefen kann. Ich habe die Befurechtung, dass dadurch Mapper abgeschreckt werden - und mindestens einer hat mir hier ja auch recht gegeben und gesagt, er laesst von einer so getaggten Strasse dann lieber die Finger. Das ist genau das, was ich vermeiden will. Ich mag auch einige andere Sachen nicht, es gibt z.B. eine ganze Anzahl von Relationen nach dem neuen OePNV-Schema, an denen gross eine Warnung dran steht Bitte nicht aendern, bevor Du nicht die Seite XYZ gelesen hast. Das ist auch schon sowas, wo ein paar Leute sich in OSM eine kleine Mauer bauen und sagen hier darf nur mitmachen, wer die folgenden Bedingungen erfuellt. Mir ist schon klar, dass das manchmal notwendig ist, aber es ist ein notwendiges Uebel mit der Betonung auf Uebel. Ein bisschen muss TMC hier als Stellvertreter fuer viele andere aehnliche Situationen herhalten, die noch kommen werden - aber, auch das wurde gesagt, Marcus hatte ja angeblich mit dem TMC-Import auch vor, in gewisser Weise richtungsweisend zu sein. Und da muss ich sagen, in *diese* Richtung - naemlich mehr und mehr unverstaendliche Spezialtags, die dem Mapper jede Sicherheit rauben - moechte ich nur sehr ungern gehen. Ich habe die ernste Befuerchtung, dass das unserem Projekt die Basisdemokratie raubt, dieses jeder kann ganz einfach mitmachen. Das finde ich aber elementar wichtig. Fuer mich kommt so ein Node mit 4 TMC-Tags an wie eine Reviermarkierung. Hier nichts aendern, dieser Node bedeutet was bestimmtes, und was genau, das wirst Du auch dann nicht verstehen, wenn Du auf die Wikiseite geschaut hast. Ich halte mich fuer nicht ganz bloed, aber ein einfaches auf-die-Wikiseite-Schauen hat mir nicht gereicht, um zu verstehen, was das alles soll. Und ich bin ein alter OSM-Hase. Wie soll das also erst bei einem Neuling ankommen? Der schlaegt doch die Haende ueberm Kopf zusammen und geht lieber wieder. Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten benutzen. Nein, das sehe ich ganz anders, zumindest ist unsere Technologie fuer sowas nicht ausgelegt - dann muessten wir viel mehr filtern koennen und z.B. dafuer sorgen koennen, dass ein Tileserver nicht saemtliche Telefonzellen-Stoerungsmeldungen gefuettert bekommt und so weiter. Ich sehe generell mit Besorgnis, was Leute alles in OSM stopfen moechten - meistens aus Faulheit oder Inkompetenz: Ich habe hier diesen Datensatz mit Vogelbeobachtungen, aber weil ich nicht in der Lage bin, eine Karte zu rendern, auf der diese Vogelbeobachtungen ueber einen OSM-Hintergrund eingezeichnet werden, will ich lieber die Vogelbeobachtungen zu OSM hochladen, dann kann ich das komfortabel in meinem Renderer einstellen. Entschuldigung ich reite darauf vielleicht etwas rumm, aber ich hab immer noch den verstehe immer noch nicht, warum du bei dem Thema so Radikal argumentierst. Vielleicht ist das jetzt einigermassen klar geworden. Die 175000 TMC-Tags in der Datenbank allein wuerden eine solche Haltung vielleicht noch nicht rechtfertigen - aber die Richtung, in die das zeigt, und die Angst, dass mit anderen Nischeninformationen ebenso verfahren wird. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Ih möchte da Frederik etwas die Stange halten. Die Erläuterungen zu TMC und das TMC Schema entsprechen z.zT. wirklich nicht den Regeln der sinnvoller OSM-Schemas. Ich beziehe mich auf die Schema-Diskussion oben und den wohl relevanten Artikel http://wiki.openstreetmap.org/wiki/TMC/TMC_Import_Germany#Tagging_Schema Da steht u.a. TMC:LocationCode, TMC:Direction, TMC:NextLocationCode,TMC:PrevLocationCode. Auch konkrete OSM-Beispieldaten helfen da nicht weiter. Das bringt mich - nebst bitte menschenlesbaren Tag-Namen - auf einen weiteren Punkt in http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS Es besteht die Gefahr, dass das Schema aus Sicht FIG modelliert wird, mit fachinternen Abkürzungen und Codes. Solche sollten vermieden und/oder ausgedeutscht werden (z.B. textuelle Aufzähltypen/Enumeration statt Zahlen). Präzise (Fach-)Begriffe sind wichtig, sie müssen aber trotzdem mit vertretbarem Aufwand verständlich sein. LG, S. Am 3. Februar 2011 16:10 schrieb Frederik Ramm frede...@remote.org: Hallo, On 02/03/2011 02:59 PM, Sven Anders wrote: Du vermutest Probleme, wenn jemand eine Schema ändert etc. aber bislang sagst du nicht ich will das und das ändern und das beißt sich mit TMC. Ich moechte, dass OSM nach Moeglichkeit auch weiterhin ohne Fuehrerschein bedienbar ist. Dass man sich ein bisschen reinfuchsen muss in die Art, wie OSM tickt - was sind Tags, was sind Ways usw., laesst sich nicht vermeiden. Aber dass man sich dazu noch - je nachdem, was man gerade editiert - in verschiedene Fachdatenwelten hineinfuchsen muss, dass missfaellt mir. Ich habe normalerweise keine unterdurchschnittliche Auffassungsgabe, aber fuer mich sahen und sehen diese TMC-Daten in OSM wie Kraut und Rueben aus, wie etwas, das ich ohne zusaetzliche Software nicht verstehen kann und dessen Korrektheit ich nicht pruefen kann. Ich habe die Befurechtung, dass dadurch Mapper abgeschreckt werden - und mindestens einer hat mir hier ja auch recht gegeben und gesagt, er laesst von einer so getaggten Strasse dann lieber die Finger. Das ist genau das, was ich vermeiden will. Ich mag auch einige andere Sachen nicht, es gibt z.B. eine ganze Anzahl von Relationen nach dem neuen OePNV-Schema, an denen gross eine Warnung dran steht Bitte nicht aendern, bevor Du nicht die Seite XYZ gelesen hast. Das ist auch schon sowas, wo ein paar Leute sich in OSM eine kleine Mauer bauen und sagen hier darf nur mitmachen, wer die folgenden Bedingungen erfuellt. Mir ist schon klar, dass das manchmal notwendig ist, aber es ist ein notwendiges Uebel mit der Betonung auf Uebel. Ein bisschen muss TMC hier als Stellvertreter fuer viele andere aehnliche Situationen herhalten, die noch kommen werden - aber, auch das wurde gesagt, Marcus hatte ja angeblich mit dem TMC-Import auch vor, in gewisser Weise richtungsweisend zu sein. Und da muss ich sagen, in *diese* Richtung - naemlich mehr und mehr unverstaendliche Spezialtags, die dem Mapper jede Sicherheit rauben - moechte ich nur sehr ungern gehen. Ich habe die ernste Befuerchtung, dass das unserem Projekt die Basisdemokratie raubt, dieses jeder kann ganz einfach mitmachen. Das finde ich aber elementar wichtig. Fuer mich kommt so ein Node mit 4 TMC-Tags an wie eine Reviermarkierung. Hier nichts aendern, dieser Node bedeutet was bestimmtes, und was genau, das wirst Du auch dann nicht verstehen, wenn Du auf die Wikiseite geschaut hast. Ich halte mich fuer nicht ganz bloed, aber ein einfaches auf-die-Wikiseite-Schauen hat mir nicht gereicht, um zu verstehen, was das alles soll. Und ich bin ein alter OSM-Hase. Wie soll das also erst bei einem Neuling ankommen? Der schlaegt doch die Haende ueberm Kopf zusammen und geht lieber wieder. Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten benutzen. Nein, das sehe ich ganz anders, zumindest ist unsere Technologie fuer sowas nicht ausgelegt - dann muessten wir viel mehr filtern koennen und z.B. dafuer sorgen koennen, dass ein Tileserver nicht saemtliche Telefonzellen-Stoerungsmeldungen gefuettert bekommt und so weiter. Ich sehe generell mit Besorgnis, was Leute alles in OSM stopfen moechten - meistens aus Faulheit oder Inkompetenz: Ich habe hier diesen Datensatz mit Vogelbeobachtungen, aber weil ich nicht in der Lage bin, eine Karte zu rendern, auf der diese Vogelbeobachtungen ueber einen OSM-Hintergrund eingezeichnet werden, will ich lieber die Vogelbeobachtungen zu OSM hochladen, dann kann ich das komfortabel in meinem Renderer einstellen. Entschuldigung ich reite darauf vielleicht etwas rumm, aber ich hab immer noch den verstehe immer noch nicht, warum du bei dem Thema so Radikal argumentierst. Vielleicht ist das jetzt einigermassen klar geworden. Die 175000 TMC-Tags in der Datenbank allein wuerden eine solche Haltung vielleicht noch nicht
[Talk-de] Störende OpenGeoDB Daten
Am 03.02.2011 11:44, schrieb Stefan Keller: P.S. Die vielen Opengeodb-Tags stören mich (auch) schon lange. Sind die nicht veraltet? Kann man ev. nicht mal die löschen? Ich hab die damlas importiert, als es für viele Orte noch nicht mal die Hauptstraße gab. Das führte dazu, das man zumindest die Orte suchen konnte. Die Daten sind für uns wahrscheinlich nicht mehr wichtig. Für die OpenGeoDB sind sie auch nicht so interessant, da die OSM Lizenz restriktiver ist als die Lizenz von OSM. Hier mal ein paar Beispieldaten für einen Place. openGeoDB:auto_update: population openGeoDB:community_identification_number: 0200 openGeoDB:is_in: Freie und Hansestadt Hamburg,Bundesrepublik Deutschland,Europe openGeoDB:is_in_loc_id: 17838 opengeodb:lat: 53.4855784 openGeoDB:layer: 9 openGeoDB:license_plate_code: HH openGeoDB:loc_id: 26754 opengeodb:lon: 9.8803265 openGeoDB:name: Hausbruch openGeoDB:population: 17009 openGeoDB:postal_codes: 21075,21079,21147,21149 openGeoDB:sort_name: HAUSBRUCH openGeoDB:telephone_area_code: 040 openGeoDB:version: 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/ Allerdings wird die OpenGeoDB immer noch weiter gepflegt. Siehe: http://fa-technik.adfc.de/code/opengeodb.pl?action=changes Man könnte jederzeit zur Qualitätsicherungssicherung eine Prüfung gegen die OpenGeoDB laufen lassen. Dazu würde aber die openGeoDB:loc_id ausreichen. Das würde ich nicht gerne verlieren, auch wenn ich im Moment keinen Kontrollauf plane. Gibt es andere Meinungen zu den Tags? Drinn lassen? Raus löschen? Ich würde sie drinn lassen, da sie nicht wirklich stören. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 16:10, schrieb Frederik Ramm: Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten benutzen. Nein, das sehe ich ganz anders, zumindest ist unsere Technologie fuer sowas nicht ausgelegt - dann muessten wir viel mehr filtern koennen und z.B. dafuer sorgen koennen, dass ein Tileserver nicht saemtliche Telefonzellen-Stoerungsmeldungen gefuettert bekommt und so weiter. Ja, aber ich mappe doch nicht für den Tileserver. Ich erinnere mich an eine Diskussion mit Sven Sommerkamp, der mir verbieten wollte straßenbegleitende Radwege in OSM als extra Way anzulegen, weil ansonsten sein Garmin nicht mehr in Hamburg routen konnte[1]. Das kann doch kein ernst zu nehmendes Argument sein. Ich will jetzt nicht die Dikssion über straßenbegleitende Radwege weider aufwecken. Ich finde die Diskussion hat ähnlichen Character. Die Wheelmap-Leute haben einen echten Mehrwert, wenn sie wissen, ob ein Fahrstuhl funktioniert, okay ist nicht die Telefonzelle, aber genau so eine Information. Mache Fahrstühle gehen in Hamburg über 6 Monate nicht. Da ist dann überhaupt die Frage ob man den Fahrstuhl nicht löschen sollte. Ich sehe generell mit Besorgnis, was Leute alles in OSM stopfen moechten - meistens aus Faulheit oder Inkompetenz: Ich habe hier diesen Datensatz mit Vogelbeobachtungen, aber weil ich nicht in der Lage bin, eine Karte zu rendern, auf der diese Vogelbeobachtungen ueber einen OSM-Hintergrund eingezeichnet werden, will ich lieber die Vogelbeobachtungen zu OSM hochladen, dann kann ich das komfortabel in meinem Renderer einstellen. Und jeder kann eigene Vorgelbeobachtungen hinzufügen und man kann es gemeinsam auswerten. Ist doch prima. Ich finde daran erstmal nichts inkompetent. Und Faulheit ist doch auch gut, ich bin gerne Faul. Ich hab gerade den Eindruck das du dich zuviel um Tileserver/OSM verarbeitende Jobs kümmerst und deshalb dich das Ansteigen der OSM-Daten nervt, das kann ich gut verstehen, der osm-tmc Validator läuft auch nicht rund, weil ich mit dem Umschreiben der Programme die das Erzugen nicht hinterher komme und die Daten so stark wachsen. Ich finde aber gerade das es eine Stärke von OSM ist solche Daten hinzu zu fügen. Wir sind eine Geodatenbank für fast alles das bedeutet, das wir natürlich auch viel Nischenkram drinn haben. Ich hab bislang für OSM damit geworben, das mein bei uns auch Nischenkram (DSL-Anschlußkästen,Hundekottütenspender etc.) verarbeiten kann. Gibt es hier noch andere Stellungnahmen zum Thema Relevanz in OSM? Was soll in unsere Datenbank und was nicht? Gruß Sven [1] http://lists.openstreetmap.org/pipermail/talk-de/2009-May/046344.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Die Siedlungsstruktur in OSM verfeinern (Place und rank)
Hallo, M∡rtin Koppenhoefer wrote: Grundsätzlich schlage ich einen Tag rank vor, der vom Größten ausgehend (rank=0) in Zehnerschritten unbedeutendere Objekte klassifiziert. Mit den folgenden Beispielen, die ich hiermit auch zur Diskussion vorschlage, erläutert sich das: Irgendjemand (User etrumap) setzt das gerade in groesserem Stil um. Bist Du das oder stehst Du mit dem in Kontakt? Ich finde das verfrueht und stehe solchen weltweiten, halb-automatischen Edits eher ablehnend gegenueber. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Habe wie schon an anderer Stelle erwähnt, extra dazu eine Wiki-Seite eröffnet: http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS ! Manchmal ist es auch nützlich, gute Beispiele anzuführen: Gibt es solche? LG, S. Am 3. Februar 2011 17:23 schrieb Sven Anders s...@anders-hamburg.de: Am 03.02.2011 16:10, schrieb Frederik Ramm: Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten benutzen. Nein, das sehe ich ganz anders, zumindest ist unsere Technologie fuer sowas nicht ausgelegt - dann muessten wir viel mehr filtern koennen und z.B. dafuer sorgen koennen, dass ein Tileserver nicht saemtliche Telefonzellen-Stoerungsmeldungen gefuettert bekommt und so weiter. Ja, aber ich mappe doch nicht für den Tileserver. Ich erinnere mich an eine Diskussion mit Sven Sommerkamp, der mir verbieten wollte straßenbegleitende Radwege in OSM als extra Way anzulegen, weil ansonsten sein Garmin nicht mehr in Hamburg routen konnte[1]. Das kann doch kein ernst zu nehmendes Argument sein. Ich will jetzt nicht die Dikssion über straßenbegleitende Radwege weider aufwecken. Ich finde die Diskussion hat ähnlichen Character. Die Wheelmap-Leute haben einen echten Mehrwert, wenn sie wissen, ob ein Fahrstuhl funktioniert, okay ist nicht die Telefonzelle, aber genau so eine Information. Mache Fahrstühle gehen in Hamburg über 6 Monate nicht. Da ist dann überhaupt die Frage ob man den Fahrstuhl nicht löschen sollte. Ich sehe generell mit Besorgnis, was Leute alles in OSM stopfen moechten - meistens aus Faulheit oder Inkompetenz: Ich habe hier diesen Datensatz mit Vogelbeobachtungen, aber weil ich nicht in der Lage bin, eine Karte zu rendern, auf der diese Vogelbeobachtungen ueber einen OSM-Hintergrund eingezeichnet werden, will ich lieber die Vogelbeobachtungen zu OSM hochladen, dann kann ich das komfortabel in meinem Renderer einstellen. Und jeder kann eigene Vorgelbeobachtungen hinzufügen und man kann es gemeinsam auswerten. Ist doch prima. Ich finde daran erstmal nichts inkompetent. Und Faulheit ist doch auch gut, ich bin gerne Faul. Ich hab gerade den Eindruck das du dich zuviel um Tileserver/OSM verarbeitende Jobs kümmerst und deshalb dich das Ansteigen der OSM-Daten nervt, das kann ich gut verstehen, der osm-tmc Validator läuft auch nicht rund, weil ich mit dem Umschreiben der Programme die das Erzugen nicht hinterher komme und die Daten so stark wachsen. Ich finde aber gerade das es eine Stärke von OSM ist solche Daten hinzu zu fügen. Wir sind eine Geodatenbank für fast alles das bedeutet, das wir natürlich auch viel Nischenkram drinn haben. Ich hab bislang für OSM damit geworben, das mein bei uns auch Nischenkram (DSL-Anschlußkästen,Hundekottütenspender etc.) verarbeiten kann. Gibt es hier noch andere Stellungnahmen zum Thema Relevanz in OSM? Was soll in unsere Datenbank und was nicht? Gruß Sven [1] http://lists.openstreetmap.org/pipermail/talk-de/2009-May/046344.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Störende OpenGeoDB Daten
Ich würde *ein* Tag mit den OpenGeoDB-Identifikator drin lassen. Dies ist offenbar openGeoDB:loc_id=*. Alle anderen OpenGeoDB-Tags würde ich radikal löschen (mit Dank an diejenigen, die hinter OpenGeoDB stecken). Das gehört m.E. zur DB-Hygiene :-. Der zugehörige Wiki-Artikel (http://wiki.openstreetmap.org/wiki/OpenGeoDB) könnte noch etwas Zuwendung gebrauchen und mind. zu Beginn ebendieses Tag und etwaige Projekte die das Nutzen erwähnen :- LG, S. Am 3. Februar 2011 16:46 schrieb Sven Anders s...@anders-hamburg.de: Am 03.02.2011 11:44, schrieb Stefan Keller: P.S. Die vielen Opengeodb-Tags stören mich (auch) schon lange. Sind die nicht veraltet? Kann man ev. nicht mal die löschen? Ich hab die damlas importiert, als es für viele Orte noch nicht mal die Hauptstraße gab. Das führte dazu, das man zumindest die Orte suchen konnte. Die Daten sind für uns wahrscheinlich nicht mehr wichtig. Für die OpenGeoDB sind sie auch nicht so interessant, da die OSM Lizenz restriktiver ist als die Lizenz von OSM. Hier mal ein paar Beispieldaten für einen Place. openGeoDB:auto_update: population openGeoDB:community_identification_number: 0200 openGeoDB:is_in: Freie und Hansestadt Hamburg,Bundesrepublik Deutschland,Europe openGeoDB:is_in_loc_id: 17838 opengeodb:lat: 53.4855784 openGeoDB:layer: 9 openGeoDB:license_plate_code: HH openGeoDB:loc_id: 26754 opengeodb:lon: 9.8803265 openGeoDB:name: Hausbruch openGeoDB:population: 17009 openGeoDB:postal_codes: 21075,21079,21147,21149 openGeoDB:sort_name: HAUSBRUCH openGeoDB:telephone_area_code: 040 openGeoDB:version: 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/ Allerdings wird die OpenGeoDB immer noch weiter gepflegt. Siehe: http://fa-technik.adfc.de/code/opengeodb.pl?action=changes Man könnte jederzeit zur Qualitätsicherungssicherung eine Prüfung gegen die OpenGeoDB laufen lassen. Dazu würde aber die openGeoDB:loc_id ausreichen. Das würde ich nicht gerne verlieren, auch wenn ich im Moment keinen Kontrollauf plane. Gibt es andere Meinungen zu den Tags? Drinn lassen? Raus löschen? Ich würde sie drinn lassen, da sie nicht wirklich stören. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Hallo, Mapnik baut um deine Abfrage noch eine Bounding Box in die Where-Klause, in etwa in der Art: AND way ST_Transform(ST_SetSRID(ST_MakeBox2D(ST_Point(13.5333,50.95),ST_Point(13.9333,51.15)),4326),900913)) So kannst du dann deine Abfragen auch testen (EXPLAIN). Generell sind die Operation in der Select-Klausel wohl eher unkritisch, während die Bedingungen in der Where-Klausel kritisch sind und diese müssen unbedingt auf einen Index zugreifen, was bei die aber der Fall zu sein scheint. Grüße Tim Am 03.02.2011 01:45, schrieb Stephan Wolff: Am 02.02.2011 00:01, schrieb Kolossos: Vielleicht wäre es ja eine Idee erstmal einen temporären View auf power=* innerhalb der BBOX zu kreieren und dann darauf in den folgenden 20 Abfragen auf diesen stark reduzierten Datensatz zuzugreifen. Dafür müsste man vermutlich die Syntax des mapnik-styles um einen Parameter erweitern. Leider verstehe ich nicht, wie aus den x,y,z-Koordinaten und der SELECT-Anweisung in der xml-Datei eine SQL-Abfrage mit geografischem Filter entsteht. Erstaunlicherweise werden manche Tiles nicht gerendert, obwohl sie keine oder sehr wenige Elemente mit power=* beinhalten (z.B /tiles/powermap/10/536/328.png), während andere Tiles mit viel mehr Objekten berechnet werden (z.B. /tiles/powermap/10/537/327.png). Scheinbar werden viel größere Bereiche als ein Tile geografisch selektiert. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 17:23, schrieb Sven Anders: ... Prinzipiell bin ich deiner Meinung, dass alles hinein darf. Die Frage ist immer nur wie. Wichtig ist mir, dass man es Filtern kann. Daher sollte sich alles in bestimmten Namensräumen befinden und nicht bisherige Nutzung erschweren. Weiterhin sollten sich die Infos bzw. das Schema auf das beschränken, was man zur Auswertung braucht. Meiner Meinung nach sind detailierte Infos in externen (aber gekoppelten) DB's besser aufgehoben. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Hallo, Sven Anders wrote: Ich erinnere mich an eine Diskussion mit Sven Sommerkamp, der mir verbieten wollte straßenbegleitende Radwege in OSM als extra Way anzulegen, weil ansonsten sein Garmin nicht mehr in Hamburg routen konnte[1]. Das kann doch kein ernst zu nehmendes Argument sein. Ich will jetzt nicht die Dikssion über straßenbegleitende Radwege weider aufwecken. Ich finde die Diskussion hat ähnlichen Character. Ich finde, es geht um etwas grundsaetzlich verschiedenes. Die Wheelmap-Leute haben einen echten Mehrwert, wenn sie wissen, ob ein Fahrstuhl funktioniert, okay ist nicht die Telefonzelle, aber genau so eine Information. Mache Fahrstühle gehen in Hamburg über 6 Monate nicht. Da ist dann überhaupt die Frage ob man den Fahrstuhl nicht löschen sollte. Im Idealfall gibt es eine externe Datenbank mit Informationen zu Fahrstuehlen - z.B. vom Fahrstuhlbetreiber -, der man entnehmen kann, ob ein Fahrstuhl gerade geht oder nicht, wann die naechste Wartung geplant ist, welches die Notfallrufnummer fuer diesen Fahrstuhl ist und so weiter. Haben wir vielleicht heute noch nicht, aber Open Government ist in aller Munde, und solche Sachen wird es mehr und mehr geben. Dann wuensche ich mir eine halbwegs verlaessliche Art - unter Umstaenden mit einem Tag, der auf die Aufzug-ID in der betr. Datenbank verweist -, wie man OSM-Daten und die nicht-OSM-Welt verknuepfen kann. Dass man solche Daten *in* OSM direkt erfasst, das kann man als Notloesung machen, solange es noch keine solche frei zugaengliche Aufzugsdatenbank gibt. Du aber hoerst Dich gerade so an, als ob Du selbst dann, wenn eine solche Datenbank verfuegbar waere, lieber einen Bot schriebest, der einmal pro Stunde den Aufzugsstatus aus der Datenbank abfragt und ihn in OSM aktualisiert - nach dem Motto ist doch praktisch. OSM kann und will aber nicht der Sammelpott fuer alle irgendwo frei erhaeltlichen Daten sein - dafuer gibt es einfach zu viel davon, und ich bin bei weitem nicht der einzige, der jede Art von Import kritisch beaeugt. Ich sehe generell mit Besorgnis, was Leute alles in OSM stopfen moechten - meistens aus Faulheit oder Inkompetenz: Ich habe hier diesen Datensatz mit Vogelbeobachtungen, aber weil ich nicht in der Lage bin, eine Karte zu rendern, auf der diese Vogelbeobachtungen ueber einen OSM-Hintergrund eingezeichnet werden, will ich lieber die Vogelbeobachtungen zu OSM hochladen, dann kann ich das komfortabel in meinem Renderer einstellen. Und jeder kann eigene Vorgelbeobachtungen hinzufügen und man kann es gemeinsam auswerten. Ist doch prima. Ich finde daran erstmal nichts inkompetent. Und Faulheit ist doch auch gut, ich bin gerne Faul. Es gibt freie Datensaetze aller Art, z.B. mit Temperaturentwicklungen oder so, die ganz OSM vom Datenvolumen her locker in den Schatten stellen. Wenn Du moechtest, starte ich mal ein kleines historisches Wetterprojekt in Hamburg, und weil ich gerne faul bin und es zugleich doch spitze ist, wenn andere auch an diese Wetterdaten herankommen, lade ich die gleich zu OSM hoch. Jeder Download, den Du von da an in Hamburg machst, ist 4x so gross wie vorher, die Tiles rendern gar nicht mehr und im Editor siehst Du nur noch Wettermesspunkte ;) also im Ernst, da muss man schon ein bisschen auf dem Boden bleiben, und sowas muss ganz klar extern mit OSM verknuepft statt in OSM hineingekippt werden. Wir fuehren normalerweise keine Relevanzdiskussion, weil die meisten von uns sich einig sind, dass alles, was Menschen vor Ort selber mappen, auch einen Platz in OSM hat. Auch das Vogelhaeuschen. Das koennen wir uns leisten - ein einzelner Mensch kann nur eine begrenzte Menge an Unsinn selber mappen, also brauchen wir uns nicht um die Definition zu pruegeln, was Unsinn ist und was nicht. Aber das heisst nicht, dass wir jedem erlauben koennen, alles zu importieren - denn da kann man mehr Unsinn machen. (Konkret an den TMC-Tags hat mich aber nicht die Menge an sich gestoert, sondern, dass sie die Huerde fuer Mapper m.E. unnoetig erhoehen, wie ich hoffe, im vorigen Posting dargelegt zu haben.) Ich hab gerade den Eindruck das du dich zuviel um Tileserver/OSM verarbeitende Jobs kümmerst und deshalb dich das Ansteigen der OSM-Daten nervt Nein; wenn das mein Grund gewesen waere, dann haette ich das auch gesagt und nicht irgendwelche Ausreden erfunden. 175000 TMC-Tags - das sind insgesamt *halb so viele*, wie der OSM-Datenbank jeden Tag neu hinzugefuegt werden. Wenn ich jetzt alle TMC-Tags loesche, dann ist die Datenmenge nach 12 Stunden wieder so gross wie davor. Mein Hauptproblem mit TMC ist, dass ich diese Daten als invasiv empfinde; sie behindern in meinen Augen die Arbeit mit den Kerndaten. Das ist was andres als wenn jemand einen Hundekottuetenspender irgendwo hinmappt, finde ich. -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list
Re: [Talk-de] cycleway=track vs. cycleway=opposite_track
Am 2. Februar 2011 22:32 schrieb Pascal Neis pascal.n...@gmail.com: bin vor ein paar Tagen auf ein Fahrrad-Routing-Problem mit Ways die ein cycleway=track-Tag besitzen aufmerksam gemacht worden. (danke Sven :) ) Folgendes Problem: Darf ein Way der als cycleway=track und auch als Einbahnstraße getaggt ist in verkehrter Richtung mit dem Fahrrad befahren werden ? Laut der Tag-Beschreibung im Wiki[1] eher nein! Ansonsten müsste er als cycleway=opposite_track gemappt sein. wie viele lanes hat denn der cycleway? Wenn er für beide Richtungen gelten soll, sollte er wohl cyleway:lanes=2 (0 mal) und cycleway:oneway=no (kommt immerhin 13 mal vor) oder so was haben. Am besten man mappt diese ways konsistent mit unseren allgemeinen Mapping-regeln separat, sind ja baulich getrennte Fahrbahnen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbildrätzel II
Siehe http://de.wikipedia.org/wiki/Parabolrinnenkraftwerk#Parabolrinnenkraftwerke Die Parabolrinnen werden aus Kostengründen meist nur einachsig der Sonne nachgeführt. Sie sind deshalb in Nord-Süd-Richtung angeordnet und werden der Sonne im Tagesverlauf von Ost nach West nachgeführt. Dafür spricht auch die Power Leitung daneben. -- View this message in context: http://gis.638310.n2.nabble.com/Luftbildratzel-II-tp5988817p5990333.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 19:46, schrieb Frederik Ramm: Es gibt freie Datensaetze aller Art, z.B. mit Temperaturentwicklungen oder so, die ganz OSM vom Datenvolumen her locker in den Schatten stellen. Wenn Du moechtest, starte ich mal ein kleines historisches Wetterprojekt in Hamburg, und weil ich gerne faul bin und es zugleich doch spitze ist, wenn andere auch an diese Wetterdaten herankommen, lade ich die gleich zu OSM hoch. Jeder Download, den Du von da an in Hamburg machst, ist 4x so gross wie vorher, die Tiles rendern gar nicht mehr und im Editor siehst Du nur noch Wettermesspunkte ;) also im Ernst, da muss man schon ein bisschen auf dem Boden bleiben, und sowas muss ganz klar extern mit OSM verknuepft statt in OSM hineingekippt werden. (Konkret an den TMC-Tags hat mich aber nicht die Menge an sich gestoert, sondern, dass sie die Huerde fuer Mapper m.E. unnoetig erhoehen, wie ich hoffe, im vorigen Posting dargelegt zu haben.) Nodes mit TMC-Daten dürften überwiegend da zu finden sein wo die Daten in Bezug auf die Strassen schon relativ vollständig sind - nicht gerade der richtige Einstiegspunkt für Anfänger allgemein... Mein Hauptproblem mit TMC ist, dass ich diese Daten als invasiv empfinde; sie behindern in meinen Augen die Arbeit mit den Kerndaten. Das ist was andres als wenn jemand einen Hundekottuetenspender irgendwo hinmappt, finde ich. In meinen Augen sínd TMC-Daten Kerndaten die eine Datendienst-Mensch-Schnittstelle mit verfügbaren Zustands-Daten ermöglichen Schau Doch ab und zu mal wieder was OSM ausgeschrieben heisst... Impliziert das nicht gerade dass dort auch Daten zu finden sind die die Verbindung zwischen Mensch und Maschine im Strassenverkehr herstellen? Lange Zeit wurde ein grosses Geheimniss um die Daten gemacht, jetzt gibt es endlich die Möglichkeit frei an die Daten hernazukommen und Du willst sie wieder ausschliessen? Der Vergleich mit den Temperaturentwicklungen hinkt - die (insbesondere historischen) Temperaturwerte möchte man sicher nicht in OSM haben, deren Messpunkte würder aber vielleicht schon wieder Sinn machen... Jedenfalls enthalten die TMC-Daten ja keine eigentliche Verkehrsdaten sondern die Information wo diese abzubilden sind. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen von falschen und abgetauten Loipen
Joerg Fischer o...@jfis.de [Thu, Feb 03, 2011 at 09:53:02AM CET]: NopMap wrote: Ich rede ausschließlich von leicht flüchtigen Einrichtungen, nicht ausgeschildert, nicht markiert, keine Tafeln und restlos verschwunden. Wie entscheidest Du ob Du löschst? Nur in einer Dir sehr gut bekannten Gegend, wenn Du selbst Skifahrer bist und genau weißt, dort ist dreimal im Leben Einer lang gefahren und sonst nichts? Dann ACK. Sehe ich auch so. In vielen Gegenden ist selten Schnee, aber wenn, dann verläuft eine Loipe auch (modulo 50 m) entlang einer bestimmten Route, weil das Höhenprofil nichts anderes zulässt. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 17:23, schrieb Sven Anders: Und Faulheit ist doch auch gut, ich bin gerne Faul. Ich auch. Deshalb mag ich die TMC-Tags nicht, machen nur Arbeit. ;) Man kann seine Sicht eben nicht nur auf den Aufwand für denjenigen einschränken, der den Import durchführt. Es wird von Mappern wie mir erwartet, dass sie sich die Mühe machen, bei ihren Bearbeitungen die (für sie evtl. absolut uninteressanten) TMC-Daten intakt zu halten. Im Gegenzug erwarte ich von den Betreibern des TMC-Imports, dass sie mir diese Aufgabe so einfach wie möglich machen. Diesem Teil des Handels wird das TMC-Schema nicht sehr gut gerecht. Es ist kompliziert und nicht laientauglich dokumentiert. Ich hab gerade den Eindruck das du dich zuviel um Tileserver/OSM verarbeitende Jobs kümmerst und deshalb dich das Ansteigen der OSM-Daten nervt, das kann ich gut verstehen, der osm-tmc Validator läuft auch nicht rund, weil ich mit dem Umschreiben der Programme die das Erzugen nicht hinterher komme und die Daten so stark wachsen. Dann nimm mal meine Perspektive. Ich habe mit Tileservern nichts am Hut. Ich war aber kürzlich hier aktiv: http://www.openstreetmap.org/browse/node/595024 Ein eher harmloser Fall: Ein Knoten an der Einmündung in einen Platz, der als Ampel getaggt ist und mehrere TMC-Tags trägt. Die Ampel ist allerdings so nicht ganz richtig, denn es gibt keine zwei separaten Ampelanlagen an den Enden des Platzes, sondern nur einen einzigen (sehr breiten) Fußgängerüberweg. Eventuell werde ich diese Ampel also irgendwann löschen wollen. Da stellen sich mir mehrere Fragen: Zuerst mal - was bedeuten diese Tags? Ok, als ML-Leser habe ich TMC schon mal gehört und bin nach dieser Diskussion hier auch nicht mehr komplett ahnungslos. Das ist allerdings kein geeigneter Maßstab. Wichtiger in der Mappingpraxis sind aber solche Fragen: Wenn ich den Knoten umtagge oder lösche, wohin sollen diese Tags? Gehören die verschiedenen TMC-Tags untrennbar zusammen? Ist die genaue Koordinate wichtig? Ist die Tatsache wichtig, dass der Knoten an der Einmündung zum Platz liegt? Ist es wichtig, auf welcher Seite der abgehenden Einbahnstraße der Knoten liegt? Müssen solche Tags womöglich sogar an Ampeln hängen? Mit diesen Fragen wird man als Mapper ziemlich allein gelassen. Und das rechtfertigt diese Diskussion. Mit dem Etikett Relevanzdiskussion wird man dem nicht gerecht - ich finde die Möglichkeit einer Verknüpfung mit TMC keineswegs irrelevant. Aber die Art, wie das Vorhaben bisher umgesetzt wird, finde ich unschön. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 03.02.2011 23:03, schrieb Tobias Knerr: Man kann seine Sicht eben nicht nur auf den Aufwand für denjenigen einschränken, der den Import durchführt. Es wird von Mappern wie mir erwartet, dass sie sich die Mühe machen, bei ihren Bearbeitungen die (für sie evtl. absolut uninteressanten) TMC-Daten intakt zu halten. Nein, ich erwarte das nicht von dir und auch von keinem anderen. Wenn ich z.B. beim editieren von Straßen irgendwelche Radrouten, Jakobswege oder TMC Infos kaputt mache, dann ist das halt so. Ich editiere jetzt nicht wie ein wilder Berserker und versuche das natürlich passend hinzubekommen, aber wenn wir vor lauter Meta-Informationen uns nicht mehr trauen die eigentlichen Geodaten zu bearbeiten, haben wir ein Problem. Insofern stimme ich Frederik mit dem potenziellen Problem überein - komme aber zu einer ganz anderen Lösung. Wohl auch, weil ich bei der deutschen Wikipedia gesehen habe, wozu der Ansatz: Vereinsdaten ins Vereinswiki, das hat hier nix zu suchen geführt hat. Im Gegenzug erwarte ich von den Betreibern des TMC-Imports, dass sie mir diese Aufgabe so einfach wie möglich machen. Da stimme ich dir zu. Ich habe nichts gegen kryptische Daten in OSM, aber es muß den Leuten klar sein: Je kryptischer, desto schneller wieder kaputt ;-) Gruß, ULFL P.S: Ich bin bei der globalen Auswertung von Tags auf viele kryptische Sachen gestoßen. Die TMC Tags sind wenigstens im Wiki recht ordentlich beschrieben, was man von vielen anderen Kryptotags leider nicht behaupten kann - da half nur Google um zumindest ne Idee zu bekommen, was überhaupt gemeint ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Am 3. Februar 2011 23:03 schrieb Tobias Knerr o...@tobias-knerr.de: Ein eher harmloser Fall: Ein Knoten an der Einmündung in einen Platz, der als Ampel getaggt ist und mehrere TMC-Tags trägt. Die Ampel ist allerdings so nicht ganz richtig, denn es gibt keine zwei separaten Ampelanlagen an den Enden des Platzes, sondern nur einen einzigen (sehr breiten) Fußgängerüberweg. Eventuell werde ich diese Ampel also irgendwann löschen wollen. ... das ist eigentlich kein Problem, wenn Du nur die Ampel löschen willst, dann reicht es ja, highway=traffic_lights zu entfernen. Um die TMC-tags brauchst Du Dich nicht zu kümmern. Aber ich gebe zu, dass die tags nicht direkt schön sind. Angerührt habe ich die bisher auch noch nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbildrätsel II
Die Parabolrinnen werden aus Kostengründen meist nur einachsig der Sonne nachgeführt. Sie sind deshalb in Nord-Süd-Richtung angeordnet und werden der Sonne im Tagesverlauf von Ost nach West nachgeführt. naja, aber diese Strukturen sind nicht Ost-West und nicht Nord-Süd orientiert, sondern von Süd-West nach Nord-Ost - das spricht doch gegen eine solare Anwendung - mein tipp ist auch eher, dass es sich um etwas aus der Landwirtschaft handelt. Gruß, Schusch (der das Thema mal korrigiert hat)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?)
Ich verstehe jetzt bei dieser Relevanz/Grundsatz-Diskussion beide Seiten nicht ganz, weil sich drüben im Thread Koennen wir die TMC-Daten rauswerfen? ja eine Lösung (Frederik nannte es Kompromiss) abzeichnete. Am 3. Februar 2011 16:10 antwortete Frederik: Hallo, On 02/03/2011 02:59 PM, Sven Anders wrote: Du vermutest Probleme, wenn jemand eine Schema ändert etc. aber bislang sagst du nicht ich will das und das ändern und das beißt sich mit TMC. Ich moechte, dass OSM nach Moeglichkeit auch weiterhin ohne Fuehrerschein bedienbar ist. Dass man sich ein bisschen reinfuchsen muss in die Art, wie OSM tickt - was sind Tags, was sind Ways usw., laesst sich nicht vermeiden. Aber dass man sich dazu noch - je nachdem, was man gerade editiert - in verschiedene Fachdatenwelten hineinfuchsen muss, dass missfaellt mir. ... Ich mag auch einige andere Sachen nicht, es gibt z.B. eine ganze Anzahl von Relationen nach dem neuen OePNV-Schema, an denen gross eine Warnung dran steht Bitte nicht aendern, bevor Du nicht die Seite XYZ gelesen hast. Dann fällt also das OePNV-Schema als Beispiel in http://wiki.openstreetmap.org/wiki/DE:Nutzung_von_OSM_durch_FIS weg? Ich habe übrigens manchmal den Eindruck, dass viele Mapper grundsätzlich nicht gerne lesen (insbesondere Wiki-Seiten) :- Ein bisschen muss TMC hier als Stellvertreter fuer viele andere aehnliche Situationen herhalten, die noch kommen werden - aber, auch das wurde gesagt, Marcus hatte ja angeblich mit dem TMC-Import auch vor, in gewisser Weise richtungsweisend zu sein. Und da muss ich sagen, in *diese* Richtung - naemlich mehr und mehr unverstaendliche Spezialtags, die dem Mapper jede Sicherheit rauben - moechte ich nur sehr ungern gehen. Ich habe die ernste Befuerchtung, dass das unserem Projekt die Basisdemokratie raubt, dieses jeder kann ganz einfach mitmachen. Das finde ich aber elementar wichtig. Da das scheint mir auch wichtig. Es wäre doch toll, wenn alle nur noch OSM benutzen, wenn z.B. die Telekom an jeder Telefonzelle gleich erfassen würde, ob diese gerade geht, oder defekt ist, wäre das doch ein Vorteil für alle die OSM Daten benutzen. Nein, das sehe ich ganz anders, zumindest ist unsere Technologie fuer sowas nicht ausgelegt - dann muessten wir viel mehr filtern koennen und z.B. dafuer sorgen koennen, dass ein Tileserver nicht saemtliche Telefonzellen-Stoerungsmeldungen gefuettert bekommt und so weiter. Hier muss ich Sven zustimmen: OSM soll weiterhin Platz bieten aktuelle Informationen (= aktuell verglichen mit dem maximal Halbjahres-Rhythmus offizieller Geodatenquellen). Ich möchte da nochmals aufs Beispiel Haiti hinweisen mit den Strassen, die von einem Tag auf den andern unpassierbar waren. Ein interessanter Hinweis steckt in der Antwort oben: Der Hauptrenderer soll tatsächlich möglichst wenig Ballast erhalten. = Kann dies nicht geregelt (oder einfach implementiert und kommuiziert) werden, indem Präfix-Tags *nicht* per default weiterverarbeitet werden - insbesondere nicht zum Hauptrenderer? Um auf TMC zurückzukommen: TMC (Traffic Message Channel) ist bekanntlich ein Staumeldesystem für Verkehrsradio, dann v.a. für (Auto-)Navis. TMC ist keine Nischeninformation, bzw. genauso eine wie viele andere. TMC ist höchstens ev. ein Fachinformationssystem (FIS) mit zu kurzlebigen Daten. Wenn wir ein TMC-Schema finden, dass etwas allgemeinverständlicher ist, können alle mitreden. Ich sehe hier - wie auch bei Vogelhäuschen und Fahrstühlen - eine wichtige Frage, die sich sowohl FIS-Macher wie auch OSM-Gralshüter stellen müssen: Es muss möglich sein, dass jedermann (natürlich möglichst korrekte) FIS-Daten erfassen kann. Für mich ist wünschenswert, dass (jeder-)mann Baustellen, Vogelhäuschen und Fahrstuhl-Zustände mappen kann. Aber für Daten, die flüchtiger als weniger als eine Stunde hat OSM vorläufig wohl (noch) keine Ressourcen. Daher meine Gretchenfrage an die TMC-Befürworter: = Dürfen alle - auch wir Nicht-Bots (:-) - TMC-Daten erfassen und verändern? = Wie flüchtig sind TMC-in-OSM-Daten? Und an alle: Wie flüchtig dürfen OSM-Daten sein? Eine Woche? Ein Tag? Zwei Stunden? LG, S. Am 3. Februar 2011 19:46 schrieb Frederik Ramm frede...@remote.org: Hallo, Sven Anders wrote: Ich erinnere mich an eine Diskussion mit Sven Sommerkamp, der mir verbieten wollte straßenbegleitende Radwege in OSM als extra Way anzulegen, weil ansonsten sein Garmin nicht mehr in Hamburg routen konnte[1]. Das kann doch kein ernst zu nehmendes Argument sein. Ich will jetzt nicht die Dikssion über straßenbegleitende Radwege weider aufwecken. Ich finde die Diskussion hat ähnlichen Character. Ich finde, es geht um etwas grundsaetzlich verschiedenes. Die Wheelmap-Leute haben einen echten Mehrwert, wenn sie wissen, ob ein Fahrstuhl funktioniert, okay ist nicht die Telefonzelle, aber genau so eine Information. Mache Fahrstühle gehen in Hamburg über 6 Monate nicht. Da ist dann überhaupt die Frage ob man den Fahrstuhl nicht löschen sollte.
Re: [Talk-de] cycleway=track vs. cycleway=opposite_track
On 03.02.2011 20:10, M∡rtin Koppenhoefer wrote: Am 2. Februar 2011 22:32 schrieb Pascal Neispascal.n...@gmail.com: bin vor ein paar Tagen auf ein Fahrrad-Routing-Problem mit Ways die ein cycleway=track-Tag besitzen aufmerksam gemacht worden. (danke Sven :) ) Folgendes Problem: Darf ein Way der als cycleway=track und auch als Einbahnstraße getaggt ist in verkehrter Richtung mit dem Fahrrad befahren werden ? Laut der Tag-Beschreibung im Wiki[1] eher nein! Ansonsten müsste er als cycleway=opposite_track gemappt sein. wie viele lanes hat denn der cycleway? Wenn er für beide Richtungen gelten soll, sollte er wohl cyleway:lanes=2 (0 mal) und cycleway:oneway=no (kommt immerhin 13 mal vor) oder so was haben. Am besten man mappt diese ways konsistent mit unseren allgemeinen Mapping-regeln separat, sind ja baulich getrennte Fahrbahnen. Gruß Martin Nein, das ist für jegliche Auswertung das blödeste. Im Prinzipiellen will man als Fahrradfahrer der schnell fahren möchte, alle cyleway=track vermeiden. Ist es nun highway=cycleway kann man als Router nichts mehr damit anfangen, da man nicht weiß ob so ein Weg gut oder Schlecht fahrbar ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
