Re: [Talk-de] mapgen version 11 released
hi johannn, also bei mir rendert das programm dieses Eschborn file - trotz warnungen und fehlermeldungen - so tolerant ist es. ich kann natürlich nicht sagen, ob alles angezeigt wird. vermute eher nicht, wegen der fehlermeldungen. aber die meldungen, die ich sehe, beziehen sich nicht auf negative ids! und die meldungen sind korrekt. die daten fehlen tatsächlich. ciao gerhard On Fri, 2010-02-26 at 19:26 +, Johann H. Addicks wrote: v0.11 (rel. Feb 26th, 2010) Bei meinen noch nicht hochgeladenen .OSM-Dateien aus dem JOSM funktioniert es -im Gegensatz zum Kosmos- nach wie vor nicht. Wie wäre es, Snapshots aus dem SNV zu erstellen? Würde zumindest bei Updates die Sache vereinfachen, wenn man nicht auf der Kommandozeile 5-6 Dateien von Hand in die passenden Verzeichnisse holen muss, sondern nur ein tgz zu bekommen. -jha- ___ 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] Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?
Anyway, gebt den Nutzern die einfache Möglichkeit, Tracklogs zu fertigen und diese anonymisiert hochzuladen. Denn gerade in schwierigen Empfangslagen wird uns nur massiv mehr Tracks zu ROUTINGTECHNISCH nutzbaren Karten verhelfen. Diese Möglichkeit prüfen wir intensiv. Da wir bereits heute entsprechend Logfiles in der Anwendung generieren, ist die Ableitung und das Hochladen von GPX-Tracks daraus technisch relativ einfach. Zwei Punkte müssen wir aber noch abschließend klären: (1) Ist der GPS-Empfänger des iPhones ausreichend genau genug (dazu kommen ja auch schon in dem Thread Anmerkungen und Zweifel)? Alle, die das iPhone für Navigation genutzt haben, wissen, dass der Empfänger nicht der Beste ist, warum ja auch einige Anbieter aktive Fahrzeughalter mit seperatem GPS-Empfänger anbieten. Da wir die Ergebnis bisher hauptsächlich für die Anwendungsoptimerung genutzt haben, müssen wir uns das Ergebnis mal ansehen, wenn wir mehrere Tracks über die Karte legen. (2) Zudem muss geklärt werden, über welchen Account die Dateien hochgeladen werden sollen. Über den Nutzeraccount oder über einen Corporate-Account. Faktisch macht das wenig unterschied, da die Daten sowieso anonymisiert werden. Dennoch könnten hier Vorbehalte herrschen. Gruß Oliver -- View this message in context: http://n2.nabble.com/Motivation-zum-Beheben-von-Bug-meldungen-von-kommerziellen-Verwertern-der-OSM-Daten-tp4615339p4644453.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
[Talk-de] ÖPNV - Linienabschnitte nur zeitweise
Moin ! mit dem Oxomoa http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema-Schema habe ich noch einwenig meine Problem. Kann mir einer sagen wie eine Strecke deklariert wird welche nur zeitweise bedient wird ?? Gruß jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OT: Nur weil's TeamOS/2 nicht mehr gibt... (was: Luft anhalten)
Johann H. Addicks addi...@gmx.net [Fri, Feb 26, 2010 at 06:13:00PM CET]: ...und openoffice und inkscape und KDE und GNOME mit tausend Anwendungen, die sofort funktionieren und überhaupt Ubuntu, Kubuntu, Ich hatte gehofft, wir wären in den letzten 10 Jahren alle etwas älter geworden. Aber dieser OS-Evangelisten-Kindergarten scheint unausrottbar zu sein. Niemand verbietet Dir, Tomtom, Encarta und mehrere WinCE-Handys mit nicht ganz untereinander kompatiblen Betriebssystemen weiter zu nutzen. -- 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] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am 27.02.2010 08:49, schrieb Martin Simon: Also z.B. highway=primary / uturn=no dagegen spricht, - dass man dann diese bauliche Trennung nicht mehr von der durchgezogenen Mittellinie unterscheiden kann Naja, das was ich grad im Kopf habe (aufgesetzte Reflektorschildchen (senkrechte Plastiklappen), die zusätzlich zur Mittellinie deutlich machen sollen, daß man hier *wirklich* nicht drüber darf, aber im Prinzip überfahrbar sind) ist auch nicht unbedingt eine bauliche Trennung... Nicht für Fußgänger, nicht für Radfahrer und vermutlich auch nicht für Einsatzfahrzeuge etc. dann eben noch negative Tags: nouturn=yes für die Schnellmapper für ein simples hier darf man mit dem KFZ außerhalb der Kreuzungen nicht wenden. wer's präziser weiss, der kann dan mappen: nouturn=line nouturn=flaps nouturn=curb nouturn=guardrail nouturn=superrail nouturn=concrete_step_barrier nouturn=wall ggf. noch kombiniert mit nouturn_height=30cm damit der ein zukünftiger Fußgängerrouter sich je nach voreingestellter Sportlichkeit entscheiden kann. Schwierig wird's in der Tat bei Zufahren in Form von service. Da bräuchte es dann wieder pro Einfahrt eine Abbiegerelation, da es ja eine Kreuzung gibt, die obige Regel (außerhalb von Kreuzungen) aufheben würde. Oder man vereinbart für die Renderer, dass Highway-Kreuzungen mit Service und Track ebenfalls das NoUTurn gilt, sofern es nicht explizit über eine Abbiegerelation aufgehoben wird. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?
Hallo Tirkon, Welche Funktion hat Marcus innerhalb von Skobbler? Marcus gehört zur Geschäftsleitung und ist das offizielle Sprachrohr von skobbler. Für eine funktionierende Navigation (nach Adressen) sind die Grenzen der Ort(steil)e unverzichtbar. Bisher sind nur die Außengrenzen von kreisfreien Städten erfasst, welche aus einer freien Datenbank stammen. [..] Hätte oder kennt Skobbler da Mittel und Wege, um diese zu beschaffen? Du hast vollkommen Recht. Wenn man aus OSM eine Referenzdatenbank für einen Geocoder ableitet, ist das Ergebnis leider noch wenig brauchbar. Wir haben uns intensiv mit dem Thema beschäftigt und arbeiten mit zwei Lösungsansätzen. Zum Application-Launch arbeiten wir mit einem proprietären Ansatz. Parallel arbeiten wir an einer Langfristlösung gemeinsam mit einem Partner an einem anderen Ansatz, bei dem wir hoffen, dass er funktioniert. Wenn das so sein sollte, werden wir OSM die Daten bereitstellen. Der Nachweis steht allerdings noch aus. durchzogene Mittellinie: Ferner gehen die Links auf die fehlenden Abbiegeverbote ein. Abbiegeverbote sind in der Tat ein Thema, das uns stark beschäftigt. Bisher sind wir leider noch nicht fündig geworden bei der Suche nach einer Schilderdatenbank, die sowohl Abbiegeverbots-, Einbahnstrassen- und Geschwindigkeitsbegrenzungsschilder beinhaltet. Es scheint daher, dass man tatsächlich den Weg der manuellen Erfassung gehen muss. Bisher wurde die Aufnahme von Abbiegeverboten aus unserer Sicht aus zwei Gründen vernachlässigt (das ist zumindest unsere Wahrnehmung anhand der Statistiken): (a) die bisherige mangelnde Relevanz (richtig visualisert werden sie unserer Kenntnis nach nur bei http://osm.virtuelle-loipe.de/restrictions/) und (b) die komplizierte Erfassung über die Relationen. Hier sehen wir Ansatzpunkte. Auf die Frage der Abbildung zur durchgezogenen Mittellinie möchte ich an dieser Stelle nicht eingehen. Dazu gibt es ja jetzt einen seperaten Thread. Gruß Oliver -- View this message in context: http://n2.nabble.com/Motivation-zum-Beheben-von-Bug-meldungen-von-kommerziellen-Verwertern-der-OSM-Daten-tp4615339p4644581.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
[Talk-de] Skobbler sollte einfaches, anyonymes T racklogging ermöglichen (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Da ten?!?)
Am 27.02.2010 06:27, schrieb Thomas Reincke: Und wenn ich mir anschaue was ein iPhone so liefert dann ist das eher schauderlich. Das möchte ich nicht als Nicht-Ortskundiger auswerten müssen... Einen erkennbar schlechten (Zickzack-)Track kann man immernoch ignorieren. Aber man kann einen Brauchbaren nicht nutzen, wenn er nicht hochgeladen wurde. Auch Apple entwickelt weiter. Zumindest sind die Empfänger über die Modelle nicht schlechter geworden. Und Jobs wird auch zukünftig neue Geräte vorstellen. Ich gehe zudem davon aus, dass die meisten Skobbler-Benuter das Telefon nicht in der Hosentasche haben werden, insbesondere wenn die Gegend schlecht gemapt ist, so dass die Sprachanlagen verwirrend sind. Zumindest ich schaue bei meinen Navis dann gern aufs Display, um einen manuellen Abgleich zwischen Kartenbild und Realität herzustellen, um zumindest eine grobe Richtung zu ermitteln. Und falls Skobbler dann auch Werte für HDOP und Fix (also die Signalqualität) im GPX mitliefert, dann kann man sich die tracks auch entsprechend in Josm einfärben lassen. Und auf die Gefahr hin, eine Wir mappen nicht für GPS-Navigation-Antwort zu erhalten: Wenn es eine Straße gibt, in der aufgrund von Hanglage, Bebauung, Reflexionen etc die meisten GPS-Empfänger den gleichen Offset liefern, es also in den Tracks immer ähnliche Verzerrungen gibt: Warum dann nicht eben nach GPS Empfangslage mappen. Das hilft dann den Nutzern mehr als wenn man sagt So ist's aber richtig, siehe Yahoo-Luftbild. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Skobbler sollte einfaches, anyonymes Trackl ogging ermöglichen (was: Motivation zum Beheben von Bu g-meldungen von kommerziellen Verwertern der OSM Daten?!? )
Am 27.02.2010 12:01, schrieb Oliver Kuehn (1) Ist der GPS-Empfänger des iPhones ausreichend genau genug (dazu kommen ja auch schon in dem Thread Anmerkungen und Zweifel)? Es gibt keine schlechten Tracks. Besser ein schlechter Track als gar keiner. Und wenn das Tracklog dann noch Qualitätseinschätzungen (HDOP, Fix) enthält, dann ist der Durchschnittliche Josm-Benutzer in der Lage, aus vielen unscharfen Tracks etwas sinnvolles zu mitteln. Selbst ohne Qualitätsinformationen funktioniert das, wenn nur genügend Tracks vorhanden sind. Beispiel: http://www.addicks.net/albums/osm/Massaknoten.png Ich wage die Behauptung, dass ein durchschnittlicher OSM-Mapper mit einer solchen Tracklog-Situation in der Lage ist, eine Karte zu bauen, die mindestens 80% korrekt ist, was Wege, deren Kategorisierung (Unschärfe +/- zwei Klassen) und Kreuzungen anbelangt. Und das ohne überhaupt Ortskenntnis zu haben. Klar, das soll nicht sein, aber immerhin ist es möglich. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV - Linienabschnitte nur zeitweise
Hallo Jan, wir hier in Aachen haben das Oxomoa-Schema und die oft zitierte Linie 11 (oder so) aus Kiel zu dieser Doku zusammengefaßt: http://wiki.openstreetmap.org/wiki/Aachen_Editing#Taggen_von_Buslinien_in_A achen_und_Umgebung Das sollte zu den beiden Schemata kompatibel sein, aber einige Unklarheiten beheben. Aber zu Deiner Frage, das meißte steht auf: http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV- Schema#Linienvariante Also wenn es ein alternativer Verlauf ist bekommt er eine eigene Relation, ist es eine Teleskoplinie bekommen die Mitglieder die Rolle additional. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mapgen version 11 released
Moin! Ich habe noch ein paar Fragen/Anregungen: -da jetzt festgelegt werden kann, in welchem Zoombereich Objekte angezeigt werden sollen, könnte man sie, wenn sie nicht angezeigt werden, automatisch aus der Legende nehmen. -könnte man das grid auch in Metern angeben? Oder verträgt sich das mit deiner Projektion nicht(welche ist das eigentlich?)? -gibt es irgend eine Möglichkeit, *nur* einen Schlüssel oder *nur* einen Wert anzugeben (building=*), bzw mehrere Schlüssel-Wert-Paare (landuse=forest *oder* natural=wood)? In meiner Karte habe ich vielen ähnlichen osm-Objekten denselben Stil zugeordnet, so wie man es von topographischen Papierkarten gewohnt ist. Für Mapgen muss ich (anscheinend) pro osm-Objekt eine Definition anlegen, für mkgmap reicht meist eine pro Stil, die dann alle gewünschten osm-Objekte einsammelt. Weiter so! :-) -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OT: Nur weil's TeamOS/2 nicht mehr gibt... (was: Luft anhalten)
Am 26. Februar 2010 18:13 schrieb Johann H. Addicks addi...@gmx.net: ...und openoffice und inkscape und KDE und GNOME mit tausend Anwendungen, die sofort funktionieren und überhaupt Ubuntu, Kubuntu, Ich hatte gehofft, wir wären in den letzten 10 Jahren alle etwas älter geworden. Aber dieser OS-Evangelisten-Kindergarten scheint unausrottbar zu sein. Bin ich ein Evangelist, weil ich OpenSource-Projekte und Distributionen aufzähle, die entgegen seiner pauschalen Behauptung definitiv ohne Frickelei ootb nutzbar sind? (OK, unter Windows läuft KDE wirklich noch nicht so rund... ;-) ) Oder habe ich deinen Beitrag nur nicht verstanden? Wenn dem so ist: ja, die Evangelisten gehen mir auch auf den Senkel, ganz gleich, ob aus der Linux-, Windows-, [$Nischensystem-] oder Apple-Ecke. Gruß aus der Bauklötzchen-Ecke, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler sollte einfaches, anyonymes Trackl ogging ermöglichen (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am 27. Februar 2010 12:57 schrieb Johann H. Addicks addi...@gmx.net: Am 27.02.2010 06:27, schrieb Thomas Reincke: Und wenn ich mir anschaue was ein iPhone so liefert dann ist das eher schauderlich. Das möchte ich nicht als Nicht-Ortskundiger auswerten müssen... Einen erkennbar schlechten (Zickzack-)Track kann man immernoch ignorieren. Aber man kann einen Brauchbaren nicht nutzen, wenn er nicht hochgeladen wurde. das gilt halt nur, solange Zigzag-track halbwegs für sich steht. Gerade in Ballungsräumen, wo sich die meisten Iphone-Nutzer aufhalten werden, sorgt dieses Rauschen nur dafür, dass man die guten Tracks nicht mehr erkennen kann, weil sie von einem Grundrauschen schlechter Tracks überdeckt werden. Auch Apple entwickelt weiter. Zumindest sind die Empfänger über die Modelle nicht schlechter geworden. Und Jobs wird auch zukünftig neue Geräte vorstellen. die GPS-Qualität soll wohl ziemlich schlecht sein, auch beim der neuesten Generation. Wenn sich das irgendwann mal ändert, kann man immer noch reagieren. Dazu kommt, dass ein Durchschnittsnutzer sein Iphone wohl nicht vor sich herträgt sondern es in der Tasche hat. Solche Tracks sind IMHO nur in seltenen Fällen (Flachland ohne andere Tracks, also ungemapptes Gebiet) halbwegs sinnvoll. Überwiegend würden sie unsere Städte sinnlos mit schlechten Tracks zukleistern. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?
Oliver Kuehn (skobbler) osm.oliver.ku...@gmx.de wrote: Zwei Punkte müssen wir aber noch abschließend klären: (1) Ist der GPS-Empfänger des iPhones ausreichend genau genug (dazu kommen ja auch schon in dem Thread Anmerkungen und Zweifel)? Alle, die das iPhone für Navigation genutzt haben, wissen, dass der Empfänger nicht der Beste ist, warum ja auch einige Anbieter aktive Fahrzeughalter mit seperatem GPS-Empfänger anbieten. Da wir die Ergebnis bisher hauptsächlich für die Anwendungsoptimerung genutzt haben, müssen wir uns das Ergebnis mal ansehen, wenn wir mehrere Tracks über die Karte legen. Sehr löblich, dass Ihr dabei so umsichtig vorgeht und Euer gewonnenes Fachwissen auch im Dienste von OSM einsetzt. Denn weder uns noch Euch wäre geholfen, wenn sich das OSM Material hierdurch verschlechtern würde. Das ist durchaus eine vertrauensbildende Maßnahme, welche den vorsichtigen Anfangs-Pessimismus gegenüber Skobbler mildern könnte. Wenn man nämlich Google als Vergleich heranzieht, dann ist das existierende OSM Material zumindest in Deutschland in der Regel schon recht präzise. Um festzustellen, ob Google als Referenz dienen kann, habe ich schon vor meinen OSM-Zeiten Google punktuell in Niedersachsen mit den amtlichen Karten verglichen. Und das war in der Regel überzeugend. Wenn es Abweichungen gab, dann waren die gleich so gravierend, dass sie eindeutig als Bearbeitungsunglück identifizierbar waren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am 27. Februar 2010 12:39 schrieb Johann H. Addicks addi...@gmx.net: Am 27.02.2010 08:49, schrieb Martin Simon: Also z.B. highway=primary / uturn=no dagegen spricht, - dass man dann diese bauliche Trennung nicht mehr von der durchgezogenen Mittellinie unterscheiden kann Naja, das was ich grad im Kopf habe (aufgesetzte Reflektorschildchen (senkrechte Plastiklappen), die zusätzlich zur Mittellinie deutlich machen sollen, daß man hier *wirklich* nicht drüber darf, aber im Prinzip überfahrbar sind) ist auch nicht unbedingt eine bauliche Trennung... es ist zumindest rechtlich eine bauliche Trennung. Oft gibt es an solchen Stellen übrigens auch streckenweise stärkere Trennungen (z.B. gibt es in Rom an allen größeren Straßen diese Reflektortrennungen, um die Bus- und Taxispuren von der Straße zu trennen, dadurch gibt es aber auch Bushaltestellen in der Mitte, und dort dann entsprechend Drängelgitter und Verkehrs-/ Warteinseln). Wenn man diese dann jeweils wieder als bauliche feste Trennung mappt, wird es auch nicht übersichtlicher. Übrigens könnte man mit dieser Relation das alles schön beschreiben, indem man die Art der Trennung jeweils über Relationen explizit angibt: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Area Nicht für Fußgänger, nicht für Radfahrer und vermutlich auch nicht für Einsatzfahrzeuge etc. das könnte man beim Routing berücksichtigen, indem man die vg. Relation anwendet (d.h. je nach Verkehrsmittel könnte man Trennungen bis zu einer bestimmten Ausbildung/Höhe überwinden). dann eben noch negative Tags: nouturn=yes für die Schnellmapper für ein simples hier darf man mit dem KFZ außerhalb der Kreuzungen nicht wenden. ach, außerhalb der Kreuzungen? D.h. Du würdest damit implizieren wollen, dass man an Kreuzungen doch wenden darf? Wie unterscheidet man denn dann die Hauptkreuzung, wo das wirklich geht, von den Nebenkreuzungen, also Einmündungen, die auf beiden Seiten sind, aber in der Mitte die bauliche Trennung ist? Das ginge natürlich wieder mit expliziten Abbiegebeschränkungen... Weitere Probleme sehe ich bei assymetrischen Straßen, wo also z.B. verschiedene Richtungen verschiedene Spuranzahlen haben, unterschiedliche Zugangsbeschränkungen (PSV vs. alle Verkehrsteilnehmer), etc. wer's präziser weiss, der kann dan mappen: nouturn=line nouturn=flaps nouturn=curb nouturn=guardrail nouturn=superrail nouturn=concrete_step_barrier nouturn=wall ggf. noch kombiniert mit nouturn_height=30cm damit der ein zukünftiger Fußgängerrouter sich je nach voreingestellter Sportlichkeit entscheiden kann. in keinem Fall bitte bei einer trennenden Mauer diese unterschlagen. Führt m.E. zu mehr Problemen als dass es welche lösen würde. Schwierig wird's in der Tat bei Zufahren in Form von service. Da bräuchte es dann wieder pro Einfahrt eine Abbiegerelation, da es ja eine Kreuzung gibt, die obige Regel (außerhalb von Kreuzungen) aufheben würde. ja eben. Und selbst diese ausserhalb von Kreuzungen-Regel funktioniert m.E. nicht, weil man gar nicht mehr erkennt, wo eine Kreuzung ist... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: problem mit relations-sortierung
Moin! bevor ich ein JOSM-ticket aufmache wollte ich erst bei euch nachfragen, vielleicht ist mir ja auch ein fehler unterlaufen. es geht um die buslinie TRAVELINER von Lübeck nach Hamburg. Teilweise wird diese auch ab Bad Schwartau (dort wo die leckere Marmelade herkommt) bedient. Nun wollte ich für den Teleskopbereich BSchw.- HL die Rolle alternativ zuweisen und dabei ist mir aufgefallen das die Elemente wohl noch durcheinander sind - obwohl die Sortiergrafik im Editor fortlaufende Elemente ausweißt. Kann sich das einmal jemand ansehen und mir Rückmeldung geben. Das betreffende Element ist http://www.openstreetmap.org/browse/relation/368278 Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Traumpfade - Messe in Lübeck mit OSM- Vortrag
Moin ! am 21. März findet in Lübeck die Traumpfade - 6. Lübecker Radreise- und Wandermesse http://www1.adfc.de/Termine/2010/Maerz/21032010-Luebeck-Traumpfade---6-Luebecker-Radreise--und-Wandermesse statt auf der sich der OSM-Stammtisch präsentiert und ich einen Vortrag halten werde.(Eintritt 2 Euro / ADFC-Mitglieder 1 Euro - Angabe ohne Gewähr) Wer aus dem Raum Lübeck noch Zeit hat uns zu unterstützen ist herzlich willkommen - Info's finden sich unter [2]. Auch wer ansonsten OSM-Interessiert ist und nur keine Zeit hat zum Stammtisch zu kommen ist herzlich willkommen. Gruß Jan :-) [1] http://www1.adfc.de/Termine/2010/Maerz/21032010-Luebeck-Traumpfade---6-Luebecker-Radreise--und-Wandermesse [2] http://wiki.openstreetmap.org/wiki/L%C3%BCbeck/Traumpfade_2010 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] EPSG-Code
Was versteht man unter EPSG-Code? EPSG:4326 EPSG:900913 EPSG:... (im OSM-Wiki habe ich dazu nichts gefunden, und Wikipedia ist da auch nicht wirklich aussagekräftig: http://de.wikipedia.org/wiki/EPSG) Gruss Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Traumpfade - Messe in Lübeck mit OSM- Vortrag
Hallo Jan, (Eintritt 2 Euro / ADFC-Mitglieder 1 Euro - Angabe ohne Gewähr) Warum machst Du den Vortrag nicht ohne Eintrittsgebühr? Du könntest stattdessen Spenden sammeln. Gruss Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] EPSG-Code
Am 27.02.2010 16:51, schrieb Markus: Was versteht man unter EPSG-Code? EPSG:4326 EPSG:900913 EPSG:... (im OSM-Wiki habe ich dazu nichts gefunden, und Wikipedia ist da auch nicht wirklich aussagekräftig: http://de.wikipedia.org/wiki/EPSG) Gruss Markus Hallo Markus, da die Erde keine richtige Kugel ist kann man die Form des Körpers nicht eindeutig beschreiben. Aus diesem Grund definiert man die entsprechenden Parameter für einen begrenzten räumlichen Bereich. Dieser Definition wird eine eindeutige Bezeichnung zugewiesen damit diese in unterschiedliche Programme eindeutige identifiziert werden können. So jedenfalls eine einfache allgemeine Beschreibung. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: problem mit relations-sortierung
eventuell hilft dir das etwas weiter. ein tolles tool für relationen. mal auf Render relation on OSM klicken. gruss wambacher - Der Fehler tritt nicht sporadisch sondern nur ab und zu auf - Fehlermeldung eines DAUS -- View this message in context: http://n2.nabble.com/JOSM-problem-mit-relations-sortierung-tp4645218p4645493.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] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am 27.02.2010 15:48, schrieb Martin Koppenhoefer: Schwierig wird's in der Tat bei Zufahren in Form von service. Da bräuchte es dann wieder pro Einfahrt eine Abbiegerelation, da es ja eine Kreuzung gibt, die obige Regel (außerhalb von Kreuzungen) aufheben würde. ja eben. Und selbst diese ausserhalb von Kreuzungen-Regel funktioniert m.E. nicht, weil man gar nicht mehr erkennt, wo eine Kreuzung ist... Wenn NoUTurn=irgendwas, dann Wenden nur noch an Kreuzungen ab residential/unclassified aufwärts. Ausnahmen wieder per Abbiegerelation. Oder anders: Wieviele Abbiegerelationen willst Du bauen, wenn auf eine Straße mit durchgezogener Mittellinie haufwenweise service-ways von Geschäften etc. münden? Jedes Mal den Way nochmal durchhaken und eine turn-restriction-relation draufbauen? Oder überall getrennt Richtungsfahrbahnen mappen, wo gar keine solchen vorhanden sind? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] EPSG-Code
Markus schrieb: Was versteht man unter EPSG-Code? EPSG:900913 900913 ist einfach Google in Leetspeak. Google setzt eine eigene Projektion ein, die nicht der Standard-Mercator-Projektion [2] entspricht. [1] Grüße, Michi [1] http://crschmidt.net/blog/archives/243/google-projection-900913/ [2] http://de.wikipedia.org/wiki/Mercator-Projektion signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Traumpfade - Messe in Lübeck mit OSM- Vortrag
Am 27.02.2010 16:32, schrieb Jan Tappenbeck: am 21. März findet in Lübeck die Traumpfade - 6. Lübecker Radreise- und Wandermesse Du kannst die ja mal fragen, warum die ausgerechnet UTM auf ihre Pfosten schreiben. (So löblich das mit den Koordinaten auch ist...) -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Crisis Mapping in Chile
Hallo, wird es für die Erdbebengebiete in Chile ähnliche Aktionen wie in Haiti geben? Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Crisis Mapping in Chile
Am 27.02.2010 17:06, schrieb Alexander Matheisen: Hallo, wird es für die Erdbebengebiete in Chile ähnliche Aktionen wie in Haiti geben? Alex Moin ! derzeit scheinen die ML und IRC noch relativ ruhig zu sein - irgendjemand hat aber schon einmal nachgefragt ob Quellen für gute Luftbilder ggf. bekannt sind ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OT: Luft anhalten; War: Routing auf Nav i für Anfänger
Andre Joost glaubte zu wissen: Dass Freie Software auch anders geht, zeigt gimp im heutigen Stadium. Und wie lange hat Gimp gebraucht, um dieses Stadium zu erreichen? flo -- Deshalb bedurfte es auch keiner Aufklärung, ob das Pferd gegen das Auto getre- ten hat, weil es als Angehöriger einer Minderheit im Straßenverkehr eine Aversion gegen Blech entwickelt hat oder weil es in seiner Einsamkeit sein Herz mit schönem Klang erfüllen wollte oder ob es seinen Huf als Warnblinklicht be- tätigt hat, damit es mit dem liegengebliebenen Fahrzeug rechtzeitig als stehendes Hindernis erkannt werden konnte (§15 I StVO). [AG Köln, Urteil vom 12. Oktober 1984 (NJW 1986, 1266)] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Traumpfade - Messe in Lübeck mit OSM- Vortrag
Am 27.02.2010 17:00, schrieb Johann H. Addicks: Am 27.02.2010 16:32, schrieb Jan Tappenbeck: am 21. März findet in Lübeck die Traumpfade - 6. Lübecker Radreise- und Wandermesse Du kannst die ja mal fragen, warum die ausgerechnet UTM auf ihre Pfosten schreiben. (So löblich das mit den Koordinaten auch ist...) -jha- was soll UTM (die Projection) mit der Messe zu tun haben ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Crisis Mapping in Chile
Hallo Alex, bis jetzt gibt es dort noch keine Luftbilder: http://map.openseamap.org/map/?zoom=12lat=-36.73516lon=-73.08738layers=B0FTT Das Epizentrum lag 60 km nordwestlich. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: problem mit relations-sortierung
Am 27.02.2010 16:58, schrieb Walter Nordmann: eventuell hilft dir das etwas weiter. ein tolles tool für relationen. mal auf Render relation on OSM klicken. gruss wambacher - Der Fehler tritt nicht sporadisch sondern nur ab und zu auf - Fehlermeldung eines DAUS ??? was ist Render relation on OSM und wo gibt es einen Link ?? Gruß Jan .-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Traumpfade - Messe in Lübeck mit OSM- Vortrag
Am 27.02.2010 16:54, schrieb Markus: Hallo Jan, (Eintritt 2 Euro / ADFC-Mitglieder 1 Euro - Angabe ohne Gewähr) Warum machst Du den Vortrag nicht ohne Eintrittsgebühr? Du könntest stattdessen Spenden sammeln. Gruss Markus Das ist der Preis für den Messeeintritt - sorry war wohl etwas missverständlich ! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Crisis Mapping in Chile
Alexander Matheisen wrote: Hallo, wird es für die Erdbebengebiete in Chile ähnliche Aktionen wie in Haiti geben? Zumindest scheint es eine Wiki-Seite zu geben: http://wiki.openstreetmap.org/wiki/2010_Chile_earthquake ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: problem mit relations-sortierung
Jan Tappenbeck wrote: es geht um die buslinie TRAVELINER von Lübeck nach Hamburg. Teilweise wird diese auch ab Bad Schwartau (dort wo die leckere Marmelade herkommt) bedient. Nun wollte ich für den Teleskopbereich BSchw.- HL die Rolle alternativ zuweisen und dabei ist mir aufgefallen das die Elemente wohl noch durcheinander sind - obwohl die Sortiergrafik im Editor fortlaufende Elemente ausweißt. Kann sich das einmal jemand ansehen und mir Rückmeldung geben. Das betreffende Element ist http://www.openstreetmap.org/browse/relation/368278 Kannst du bitte erklären, wo genau das Problem mit der Relation ist? Soweit ich die einzelnen Stücke durchgegangen bin, war alles ok. Die Rolle der Elemente ist bei der grafischen Anzeige übrigens egal, es wird nur die Verbundenheit der Wege dargestellt. Gruß, Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS/OSM-Konferenz: Anmeldung noch bis 2 6.Februar möglich
Tirkon glaubte zu wissen: Frederik Ramm frede...@remote.org wrote: Russ Nelson hat auch mal einen Rueffel bekommen, weil er ein Perlskript geschrieben hat, das seine eigene Heimatposition in Minischritten veraendert hat, so dass er Schritt fuer Schritt ueber die 10 Mapper in meiner Naehe alle Leute bekam, die in seiner gegend ihre Heimatposition hatten... So habe ich das für die hiesige Region gemacht, allerdings nicht per Script, sondern per Hand. Es waren rund fünfzehn Heimatpositionen nötig. Eine Handvoll User wurden auch per Zufall durch mehrfache Edits in der Region gefunden. Ferner habe ich bei jedem so gefunden User von Hand geprüft, ob er laut seiner Bearbeitungsliste mindestens drei Seiten Edits vornehmlich im Gebiet hatte. _Damit_ hätte ich kein Problem. Wenn man mal nicht nur etwas einträgt sondern auch mal ein wenig Datenpflege betreibt (doppelte Wege, fehlende layer= an Brücken, level= statt layer= usw usf), hat man schnell Änderungen in halb D vorgenommen und wird bei automatischen Anschreiben auch schnell mal aus halb D mit mails beglückt. Mich stört das automatisch versenden per Knopfdruck an zig User, die mal einem bestimmten Bereich irgendwann mal etwas gemacht haben. Dass von 25 Angeschriebenen fast die Hälfte - teilweise sogar sehr dankbar - geantwortet hat, werte ich das Ganze mal als möglichst belästigungsarme Methode. +1 In der Liste hier wird oftmals empfohlen, bei Unstimmigkeiten erst einmal den Editierenden anzuschreiben. Da er aber dazu keine Zustimmung gegeben hat, wäre selbst dieses unzulässig. Folglich wäre es auch unmöglich, eine lokale Community insbesondere in ländlichen Regionen zusammen zu bekommen. Das würde ich den Hardlinern, die gegen den Spam mit allen Mitteln vorgehen würden, zu bedenken geben. Im Fall osm sehe ich mails, die sich z.B. einen meiner edits beziehen oder auch von jemand, der aus _meiner_ Gegend[1] kommt und Kontakt aufnehmen will, nicht als Spam oder als Belästigung an. Solche erhalte ich gerne und beantworte die auch gerne. Zig automatisch versandte mails aus ganz D zu irgendwelchen Treffen oder Aktionen, an denen ich nie teilnehmen *könnte* (oder wollte), nur weil ich mal einen Typo in der Ecke verbessert hab, sehe _ich_ als Belästigung an. Ich hab noch andere Hobbys als von Hand auszusortieren, ob mich eine über osm erhaltene Mail interessiert oder nicht. [1] ich hab eigentlich recht deutlich auf meiner Userpage und im Wiki stehen, wo das ist flo -- ähm..._ich_ hab das garnicht geschrieben, nur den Kommentar dazu, der wurde aber zensiert ;-) Von wem? ;-) von der 'Fettnäpchen'[tm]-Zensurstelle, Büro Nr. 5 ;-) [Thomas Goehring und Steffen Hillner in dafb] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Routing auf WinCE
Hallo! Die Problemstellung ist relativ einfach; wie man den kuerzesten Weg in einem Graphen sucht, das versteht jeder, und wenn jemand ein paar Semester Informatik oder Operations Research oder sowas hatte, dann sind ihm auch die einschlaegigen Algorithmen (Dijkstra, A*) schon ueber den Weg gelaufen. A* ist nicht schlecht. Die Lösung ist wohl grundsätzlich optimal - aber A* ist langsam :-/ -- Gruß... Tim ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mapgen version 11 released
hi, - legende habe ich auf todo liste gesetzt. macht sinn! - grid in metern ebenso. projektion ist ganz einfach mit cos (latitude)... - key=* steht schon auf der liste! danke für's testen und feedback! ich werde nun erst mal ein gescheites ruleset bauen und mir ein paar symbole etc. zimmern. ciao gerhard On Sat, 2010-02-27 at 14:45 +0100, Martin Simon wrote: Moin! Ich habe noch ein paar Fragen/Anregungen: -da jetzt festgelegt werden kann, in welchem Zoombereich Objekte angezeigt werden sollen, könnte man sie, wenn sie nicht angezeigt werden, automatisch aus der Legende nehmen. -könnte man das grid auch in Metern angeben? Oder verträgt sich das mit deiner Projektion nicht(welche ist das eigentlich?)? -gibt es irgend eine Möglichkeit, *nur* einen Schlüssel oder *nur* einen Wert anzugeben (building=*), bzw mehrere Schlüssel-Wert-Paare (landuse=forest *oder* natural=wood)? In meiner Karte habe ich vielen ähnlichen osm-Objekten denselben Stil zugeordnet, so wie man es von topographischen Papierkarten gewohnt ist. Für Mapgen muss ich (anscheinend) pro osm-Objekt eine Definition anlegen, für mkgmap reicht meist eine pro Stil, die dann alle gewünschten osm-Objekte einsammelt. Weiter so! :-) -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Crisis Mapping in Chile
bis jetzt gibt es dort noch keine Luftbilder: Das wird sich vermutlich ändern. This is to inform you that at the request of WFP, UNOOSA has requested the activation of the International Charter Space and Major Disasters to support the damage assessment and response efforts in the earthquake that impacted Concepción, Chile today. http://www.disasterscharter.org/web/charter/activations (noch nicht aktualisiert) Auf der talk Mailingliste wurde schon einiges gepostet und auf der Crisismappers-Liste ebenso. Ich vermute auf der chilenischen Mailingliste[1,2] wird auch einiges geschehen und es gibt die osm-emergency[3] Liste. Die Sprache der Wahl wird wohl vermutlich überall englisch sein. Ich persoenlich würde mich freuen wenn wir dieses mal nicht so viele Threads und einfache Weiterleitungen aus anderen Mailinglisten hier auf den normalen Listen bekommen. Gruß, Lars [1] http://wiki.openstreetmap.org/wiki/Mailing_lists [2] http://lists.openstreetmap.org/pipermail/talk-cl/ [3] http://groups.google.com/group/osm-emergency ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Johann H. Addicks addi...@gmx.net wrote: Am 27.02.2010 15:48, schrieb Martin Koppenhoefer: Schwierig wird's in der Tat bei Zufahren in Form von service. Da bräuchte es dann wieder pro Einfahrt eine Abbiegerelation, da es ja eine Kreuzung gibt, die obige Regel (außerhalb von Kreuzungen) aufheben würde. ja eben. Und selbst diese ausserhalb von Kreuzungen-Regel funktioniert m.E. nicht, weil man gar nicht mehr erkennt, wo eine Kreuzung ist... Wenn NoUTurn=irgendwas, dann Wenden nur noch an Kreuzungen ab residential/unclassified aufwärts. Ausnahmen wieder per Abbiegerelation. Oder anders: Wieviele Abbiegerelationen willst Du bauen, wenn auf eine Straße mit durchgezogener Mittellinie haufwenweise service-ways von Geschäften etc. münden? Jedes Mal den Way nochmal durchhaken und eine turn-restriction-relation draufbauen? Oder überall getrennt Richtungsfahrbahnen mappen, wo gar keine solchen vorhanden sind? Ihr vergesst bei Eurer Diskussion, dass sich nicht alle vorkommenden Fälle durch Tags darstellen lassen. Als einfachstes Gegenbeispiel sei hier ein Knotenpunkt mit drei Straßen genannt, die ich A, B und C nennen will. Mittels Tags kann man nicht darstellen, ob an dem Knoten eine nicht unterbrochene durchgezogene Mittellinie von A nach B, B nach C oder C nach A durchläuft. Das Ganze lässt sich mit der durchgezogene-Mittellinien-Relation darstellen, die ich schon unter was: Motivation zum Beheben von Bugmeldungen von kommerziellen Verwertern der OSM Daten?!? beschrieben habe: Man packt einfach alle Straßénabschnitte einer durchgezogenen Mittellinie von deren Anfang bis Ende in eine Relation und gibt dieser ein passendes englisches Tag Richtungsfahrbahntrennung. Geht die durchgezogene Linie an Straßenknoten (Kreuzungen, Abzweigungen) durch, so läuft auch die Relation durch. Ist die durchgezogenen Linie an Straßenknoten unterbrochen, so endet die Relation dort und eine neue beginnt. Dies ist mit den heutigen Mitteln von OSM zu bewerkstelligen. Möchte man allerdings aus Gründen der Übersichtlichkeit der Relations-Zerstückelung durch an Knotenpunkten unterbrochenen Nittellinien entgegen wirken, bräuchte man ein neues Feature in OSM. Dies wären (durchgehende-Mittelinien-) Relationen, welche Knotenpunkte explizit ausschließen können, nämlich dann, wenn die Mittellinie dort unterbrochen ist. Der Vorteil dieser Methode ist auch die 1:1 Darstellung der Realität. Eine Relation entspricht genau einer durchgezogenen Mittelinie in ihrer Gesamtlänge. Sie kann also nun auch einfach in die Karte eingezeichnet werden. Gleichzeitig könnt ihr die ganze unübersichtliche Ansammlung von Umkehrverboten und Abbiegebeschränkungsrelationen vergessen, die eigentlich in der Realität auch nicht explizit vorkommen, sondern lediglich Folge des Überfahrverbotes der durchgehenden Linie sind. Es ist nun Aufgabe der Navigations-/Router-Software durch entsprechendes Routen das Überfahren der durchgehenden Mittellinie zu unterlassen. Für Fußgänger und (abgestiegene) Radfahrer ist dies natürlich weiterhin möglich. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: problem mit relations-sortierung
uii, da war der link weg. sorry. http://betaplace.emaitie.de/webapps.relation-analyzer/analyze.jsp?relationId=62598 wambacher - Der Fehler tritt nicht sporadisch sondern nur ab und zu auf - Fehlermeldung eines DAUS -- View this message in context: http://n2.nabble.com/JOSM-problem-mit-relations-sortierung-tp4645218p4645847.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] EPSG-Code
Markus schrieb: Was versteht man unter EPSG-Code? EPSG:4326 EPSG:900913 EPSG:... (im OSM-Wiki habe ich dazu nichts gefunden, und Wikipedia ist da auch nicht wirklich aussagekräftig: http://de.wikipedia.org/wiki/EPSG) Gruss Markus Hallo Markus, der Code 4326 bezeichnet die geografischen Koordinaten mit Länge und Breite in Grad. Man kann damit jeden Punkt der Erde eindeutig bezeichnen. Dies System hat aber auch einige Nachteile. Wenn man eine Karte damit zeichnet, dann sieht die am Äquator noch einigermaßen richtig aus. Je weiter man sich aber aus den Tropen entfernt um so mehr wird die Darstellung in die Breite gezogen (verzerrt). Aus der Grad-Angabe lässt sich sowieso schwer ein Maßstab berechnen. Durch die Verzerrung ist der Nord-Süd-Maßstab dann auch noch unterschiedlich zum Ost-West-Maßstab. Kurz gesagt: zur Koordinatenerfassung OK, als Kartenprojektion nicht recht brauchbar. Daher sind im Laufe der Jahrhunderte auf der Welt tausende lokale Koordinatensysteme entstanden die ein Gebiet jeweils längentreu, winkeltreu usw. abbilden konnten. Dies hat die Tätigkeit der Ölindustrie beeinträchtigt, die weltweit nach Ölvorkommen sucht. Man hat also die Parameter der einzelnen Systeme systematisch zusammen getragen. Mit diesen Parametern ist es möglich, ein System in ein anderes umzurechnen. EPSG steht ursprünglich für European Petroleum Survey Group, jetzt OGP Surveying Positioning Committee. http://www.epsg.org/ Programme wie proj4 oder PostGIS benutzen die EPSG-Parameter für Transformationen. Hunderte verschiedene System reichten Google nicht, man wollte ein eigenes. Das 900913 ist kein offizieller EPSG-Code und daher z.B. in der Tabelle spatial_ref_sys von PostGIS nicht enthalten. Man kann es aber nachtragen. Richtige EPSG-Codes bzw. SRS gehen von 2000 - 32766. SRS = Spatial Reference System Apropos lokale Systeme ... In Deutschland wurden vom Liegenschaftskataster bisher die Gauß-Krüger-Koordinaten verwendet. Das waren jeweils 3 Grad breite Streifen in Nord-Süd-Richtung. Mitte war der Medidian 3, 6, 9° usw. 31467 ist z.B. das Gauß-Krüger-System im DHDN (Deutsches-Haupt-Dreiecks-Netz) Zone 3 (um 9°). Das Kataster wird gerade umgestellt in die 6 Grad breiten Streifen des UTM-Systems. In NRW landen wir dann im 32. Streifen. Da bei der Umstellung historische lokale Fehler beseitigt werden, ist das nicht nur eine einfache Transformation sondern eine Homogenisierung über Passpunkte. Es treten dabei Verschiebungen von mehreren Metern auf gegenüber der einfachen Umrechnung mit den Parametern aus den EPSG-Codes, wie sie die PostGIS machen würde. Wenn also mal kommunale Daten importiert wurden, die in einem schlechten Gauss-Krüger-Gebiet koordiniert waren, dann könnten demnächst solche Lagefehler auffallen, sobald z.B. die hinterlegten Luftbilder sauber auf UTM transformiert wurden. Ähnliches gilt, wenn Luftbilder verwendet wurden, die auf Gauß-Krüger referenziert waren. -- Frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: problem mit relations-sortierung
Am 27.02.2010 17:51, schrieb Sebastian Klein: Jan Tappenbeck wrote: es geht um die buslinie TRAVELINER von Lübeck nach Hamburg. Teilweise wird diese auch ab Bad Schwartau (dort wo die leckere Marmelade herkommt) bedient. Nun wollte ich für den Teleskopbereich BSchw.- HL die Rolle alternativ zuweisen und dabei ist mir aufgefallen das die Elemente wohl noch durcheinander sind - obwohl die Sortiergrafik im Editor fortlaufende Elemente ausweißt. Kann sich das einmal jemand ansehen und mir Rückmeldung geben. Das betreffende Element ist http://www.openstreetmap.org/browse/relation/368278 Kannst du bitte erklären, wo genau das Problem mit der Relation ist? Soweit ich die einzelnen Stücke durchgegangen bin, war alles ok. Die Rolle der Elemente ist bei der grafischen Anzeige übrigens egal, es wird nur die Verbundenheit der Wege dargestellt. Gruß, Sebastian da von Bad Schwartau bis Lübeck ZOB der Teleskopbereich ist müßten die Rollen-Elemente bei sortierter Reihenfolge zumindest hintereinander stehen. Das verwundert mich, das dieses nicht der Fall ist ! Die Rolle der Elemente ist bei der grafischen Anzeige übrigens egal ... das ist mir auch bekannt ! Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: problem mit relations-sortierung
Jan Tappenbeck wrote: Am 27.02.2010 17:51, schrieb Sebastian Klein: Jan Tappenbeck wrote: es geht um die buslinie TRAVELINER von Lübeck nach Hamburg. Teilweise wird diese auch ab Bad Schwartau (dort wo die leckere Marmelade herkommt) bedient. Nun wollte ich für den Teleskopbereich BSchw.- HL die Rolle alternativ zuweisen und dabei ist mir aufgefallen das die Elemente wohl noch durcheinander sind - obwohl die Sortiergrafik im Editor fortlaufende Elemente ausweißt. Kann sich das einmal jemand ansehen und mir Rückmeldung geben. Das betreffende Element ist http://www.openstreetmap.org/browse/relation/368278 Kannst du bitte erklären, wo genau das Problem mit der Relation ist? Soweit ich die einzelnen Stücke durchgegangen bin, war alles ok. Die Rolle der Elemente ist bei der grafischen Anzeige übrigens egal, es wird nur die Verbundenheit der Wege dargestellt. Gruß, Sebastian da von Bad Schwartau bis Lübeck ZOB der Teleskopbereich ist müßten die Rollen-Elemente bei sortierter Reihenfolge zumindest hintereinander stehen. Das verwundert mich, das dieses nicht der Fall ist ! Die Rolle der Elemente ist bei der grafischen Anzeige übrigens egal ... das ist mir auch bekannt ! Gruß Jan :-) Die Wegstücke sind zwar falsch sortiert, aber in der aktuellen Sortierung bilden sie trotzdem eine geschlossene Route ohne Unterbrechungen! Es gibt eine Stelle an der die Strecke sich selbst kreuzt. Damit gibt es theoretisch mehrere Möglichkeiten, die Wegstücke ohne Lücken aneinanderzureihen... In dem Fall müsste man das wohl von Hand ausbessern. Gruß Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Hallo zusammen, Am Sat, 27 Feb 2010 18:18:09 +0100 hat Tirkon tirko...@yahoo.de geschrieben: Johann H. Addicks addi...@gmx.net wrote: Das Ganze lässt sich mit der durchgezogene-Mittellinien-Relation darstellen ... Geht die durchgezogene Linie an Straßenknoten (Kreuzungen, Abzweigungen) durch, so läuft auch die Relation durch. Ist die durchgezogenen Linie an Straßenknoten unterbrochen, so endet die Relation dort und eine neue beginnt. Dies ist mit den heutigen Mitteln von OSM zu bewerkstelligen. Ich hatte mir letztes Jahr ebenfalls ein paar Gedanken gemacht, wie man Fahrspuren u.ä. erfassen kann und dabei auch die Trenner berücksichtigt (durchgezogene Linie, gestrichelte Linie, Grünstreifen, ...) Im Wiki zu finden unter http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts Die waypart-Relationen bilden im Prinzip deine Idee ab, indem diese mehrere Ways beinhalten können. Zusätzlich kann man die Relation an einem Node eines Ways enden lassen - so muss man nicht für jede Änderung den eigentlich Way trennen. Möchte man allerdings aus Gründen der Übersichtlichkeit der Relations-Zerstückelung durch an Knotenpunkten unterbrochenen Nittellinien entgegen wirken, bräuchte man ein neues Feature in OSM. Dies wären (durchgehende-Mittelinien-) Relationen, welche Knotenpunkte explizit ausschließen können, nämlich dann, wenn die Mittellinie dort unterbrochen ist. Theoretisch kann man es auch jetzt schon lösen, indem man die jeweiligen Nodes in die Relation mit einer entsprechenden Rolle aufnimmt. Wenn man das genau definiert, können es die Programme auch auswerten. Viele Grüße, Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] die strassenliste kommt ja so langsam ins rollen.
die strassenliste kommt ja so langsam ins rollen. ich hab da einige bitten, fragen , anmerkungen a) ich hab mich nochmals vertan: in hessen muss bad homburg und friedrichsberg in den hochtaunus-kreis. sind mir leider in den kreis bergstrasse gerutscht. kannst du die startseite nicht auch einfach augrund der wiki-daten neu erstellen - eventuell zusammen mit den grafiken? dann wäre hier ruhe. b) in der hessen-karte stehen komischerweise die namen von großstädten aus nrw drin. nur optik - nicht wichtig c) in der hessen-karte hab ich noch ein kleines loch, dass ich mir nicht erklären kann. könnte bad soden oder schwalbach (nicht bad schwalbach) sein. die grenze von bad soden ist etwas merkwürdig aber nur ein in sich geschlossener outer d) wann wird die grafik erstellt? e) im norden von rheinland-pfalz schein jemand amok zu laufen, der wohl nicht begriffen hat, worum es hier geht. z.b. kreis altenkirchen: besteht aus herdorf und 8 verbands-gemeinden, die jeweils für ihren bereich zuständig sind. diese v-gemeinden bestehen aus insgesamt 119 gemeinden (i.d.R Kuhdörfern) und der typ hat alle reingeklopp ohne wohl darüber nachzudenken, woher die daten kommen sollen. ach ja, die relationen fehlen meistens auch. in osm ist das ja ok, aber in der strassenliste? f) manche sehen die sache mit der strassenliste wohl darin, die weissen flecken rot anzumalen. um die notwendigen strassendaten kümmert sich fast keiner. und wenn sie drin stehen, dann frag ich mich manchmal schon, woher die kommen. ich warte noch auf den tag, wo jemand eine ganze telefon-cd reinklopft - wenn er nicht schon dabei ist. hauptsache grünlich. (grünlich ohne d) ein vernünftiger abgleich dauert bis zu 2 wochen, vom eintragen über den kontakt zur gemeinde, nachhaken, namen reinladen und abgleichen. dabei gibt es sogar fehler in der offiziellen liste der gemeinde. die wird nämlich bei kleineren gemeinden von hand als sheet (oder sh.t?) geführt und ist in der regel auch falsch! mfg walter p.s. hab nen neuen thread angefangen, weil der alte a) sehr lang b) inzwischen an thema vorbei ist. - Der Fehler tritt nicht sporadisch sondern nur ab und zu auf - Fehlermeldung eines DAUS -- View this message in context: http://n2.nabble.com/die-strassenliste-kommt-ja-so-langsam-ins-rollen-tp4646251p4646251.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] JOSM: problem mit relations-sortierung
Am 27.02.2010 19:28, schrieb Sebastian Klein: Jan Tappenbeck wrote: Am 27.02.2010 17:51, schrieb Sebastian Klein: Jan Tappenbeck wrote: es geht um die buslinie TRAVELINER von Lübeck nach Hamburg. Teilweise wird diese auch ab Bad Schwartau (dort wo die leckere Marmelade herkommt) bedient. Nun wollte ich für den Teleskopbereich BSchw.- HL die Rolle alternativ zuweisen und dabei ist mir aufgefallen das die Elemente wohl noch durcheinander sind - obwohl die Sortiergrafik im Editor fortlaufende Elemente ausweißt. Kann sich das einmal jemand ansehen und mir Rückmeldung geben. Das betreffende Element ist http://www.openstreetmap.org/browse/relation/368278 Kannst du bitte erklären, wo genau das Problem mit der Relation ist? Soweit ich die einzelnen Stücke durchgegangen bin, war alles ok. Die Rolle der Elemente ist bei der grafischen Anzeige übrigens egal, es wird nur die Verbundenheit der Wege dargestellt. Gruß, Sebastian da von Bad Schwartau bis Lübeck ZOB der Teleskopbereich ist müßten die Rollen-Elemente bei sortierter Reihenfolge zumindest hintereinander stehen. Das verwundert mich, das dieses nicht der Fall ist ! Die Rolle der Elemente ist bei der grafischen Anzeige übrigens egal ... das ist mir auch bekannt ! Gruß Jan :-) Die Wegstücke sind zwar falsch sortiert, aber in der aktuellen Sortierung bilden sie trotzdem eine geschlossene Route ohne Unterbrechungen! Es gibt eine Stelle an der die Strecke sich selbst kreuzt. Damit gibt es theoretisch mehrere Möglichkeiten, die Wegstücke ohne Lücken aneinanderzureihen... stimmt !!! darüber hatte ich gar nicht nachgedacht ! also gut das man einmal darüber gesprochen hat ! gruß Jan :-) In dem Fall müsste man das wohl von Hand ausbessern. Gruß Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV - Linienabschnitte nur zeitweise
Hallo! Am 27.02.2010 14:24, schrieb Dimitri Junker: Hallo Jan, wir hier in Aachen haben das Oxomoa-Schema und die oft zitierte Linie 11 (oder so) aus Kiel zu dieser Doku zusammengefaßt: http://wiki.openstreetmap.org/wiki/Aachen_Editing#Taggen_von_Buslinien_in_A achen_und_Umgebung Das sollte zu den beiden Schemata kompatibel sein, aber einige Unklarheiten beheben. Aber zu Deiner Frage, das meißte steht auf: http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV- Schema#Linienvariante Also wenn es ein alternativer Verlauf ist bekommt er eine eigene Relation, ist es eine Teleskoplinie bekommen die Mitglieder die Rolle additional. In Oxomoa habe ich dazu nur alternate gefunden. -- Mit freundlichen Gruessen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Biergärten
Hi! Irgendwie scheinen sehr wenige Biergärten mit amenity=biergarten getaggt zu sein. siehe http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbiergarten. Sollte man das nicht korrigieren? Zuumindest, wenn auch die Adresse fehlt? Viele Grüße von Dani ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Biergärten
moin On 27.02.2010, at 21:17, Daniela Duerbeck wrote: Irgendwie scheinen sehr wenige Biergärten mit amenity=biergarten getaggt zu sein. siehe http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dbiergarten. Sollte man das nicht korrigieren? Zuumindest, wenn auch die Adresse fehlt? hmm wäre interessant wenn man da auch irgendwie beischreiben könnte das so ein biergarten nur während der sommer saison oder so existiert. hier in der stadt sind einige restaurants aktiv die auch außenbereiche als mehr oder minder eigenständige biergärten betreiben. natürlich nur im sommer. cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Nils Heuermann w...@oemmes.net wrote: Theoretisch kann man es auch jetzt schon lösen, indem man die jeweiligen Nodes in die Relation mit einer entsprechenden Rolle aufnimmt. Wenn man das genau definiert, können es die Programme auch auswerten. Ich habe bisher keine Beschreibung von Rolle finden können und weiß daher auch nicht, was das ist. Könntest Du vielleicht einmal nichttechnisch beschreiben, was der Sinn und Zweck einer Rolle ist? Welches Problem war ursächlich dafür, dass man sie erfinden musste? Weiter ist mir unklar, wieso nicht nur hier wie selbstverständlich von einer Rolle gesprochen wird, obwohl nirgends beschrieben. Könntest Du daher auch einmal beschreiben, woher Du dieses Wissen hast? Ist Rolle vielleicht ein Import aus einem anderen Fachgebiet außerhalb von OSM? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Crisis Mapping in Chile
Am 27.02.2010 18:17, schrieb Lars Francke: bis jetzt gibt es dort noch keine Luftbilder: Das wird sich vermutlich ändern. paßt zwar nicht ganz in den Thread, aber gibt es denn auch Luftbilder für Madeira. Dort ist ja auch einiges an Straßen und Brücken zerstört worden? -- schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am Sat, 27 Feb 2010 21:37:37 +0100 hat Tirkon tirko...@yahoo.de geschrieben: Nils Heuermann w...@oemmes.net wrote: Theoretisch kann man es auch jetzt schon lösen, indem man die jeweiligen Nodes in die Relation mit einer entsprechenden Rolle aufnimmt. Wenn man das genau definiert, können es die Programme auch auswerten. Ich habe bisher keine Beschreibung von Rolle finden können und weiß daher auch nicht, was das ist. Könntest Du vielleicht einmal nichttechnisch beschreiben, was der Sinn und Zweck einer Rolle ist? Wenn man einer Relation [1] einen Weg oder Punkt (oder auch eine andere Relation) als Mitglied (member) hinzufügt, kann man dem jeweiligen Objekt eine Rolle (role) [2] zuordnen. Zum Beispiel gibt es bei Abbiegebeschränkungen [3] die Rollen from, to und via, um anzugeben, *von* welcher Straße man *über* welchen Punkt *in* welche Straße (nicht) fahren darf. Bei den wayparts habe ich für die einzelnen Wege, für die man Spuren eintragen möchte, die Rolle way vorgesehen [4]. Man könnte dann z. B. für die im Thread diskutierten Ausnahmen eine Rolle except (oder wie immer man sie auch nennt - deshalb erfinden/definieren) für Punkte/Nodes festlegen. Hoffe, das war verständlich :) Viele Grüße, Nils [1] http://wiki.openstreetmap.org/wiki/Relations [2] http://wiki.openstreetmap.org/wiki/Roles [3] http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Mindestanforderung [4] http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts#Mitglieder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] die strassenliste kommt ja so langsam ins rollen.
On Sat, Feb 27, 2010 at 11:16:27AM -0800, Walter Nordmann wrote: die strassenliste kommt ja so langsam ins rollen. ich hab da einige bitten, fragen , anmerkungen a) ich hab mich nochmals vertan: in hessen muss bad homburg und friedrichsberg in den hochtaunus-kreis. sind mir leider in den kreis bergstrasse gerutscht. kannst du die startseite nicht auch einfach augrund der wiki-daten neu erstellen - eventuell zusammen mit den grafiken? dann wäre hier ruhe. Das ist alles mehrstufig - Das wiki wird ausgelesen und eine auswertung gemacht. Dann wird der status gedumped und aus den stati alle auswerungen dann die uebersichtsseite gebaut. Das findet normalerweise nach jeder auswertung statt. Schief geht das im moment nur wenn man sich mal bei der relationid vertan hat - dann existiert da ein verzeichniss das falsche daten existiert (Im Wiki ist der primary key die seite, in der auswertung die relationid) Im moment sind die Wiki seiten aber auch als im Kreis Bergstraße drin? Die wiki seiten musst du dann schon loeschen und neu in der richtigen Einordnung anlegen. b) in der hessen-karte stehen komischerweise die namen von großstädten aus nrw drin. nur optik - nicht wichtig Um eine orientierung zu ermoeglichen suche ich mir einige markante Staedte zusammen - allerdings habe ich das bisher nur fuer NRW gemacht und merge da eine weitere tabelle in der datenbank. Da eliminiere ich im moment nicht gegen die area des Bundeslandes. Daher sind die NRW Staedte drin und die Hessen nicht. c) in der hessen-karte hab ich noch ein kleines loch, dass ich mir nicht erklären kann. könnte bad soden oder schwalbach (nicht bad schwalbach) sein. die grenze von bad soden ist etwas merkwürdig aber nur ein in sich geschlossener outer Hmmm - sind beide in meiner polygon tabelle drin. d) wann wird die grafik erstellt? Abends irgendwann - 18:00 oder so ... e) im norden von rheinland-pfalz schein jemand amok zu laufen, der wohl nicht begriffen hat, worum es hier geht. z.b. kreis altenkirchen: besteht aus herdorf und 8 verbands-gemeinden, die jeweils für ihren bereich zuständig sind. diese v-gemeinden bestehen aus insgesamt 119 gemeinden (i.d.R Kuhdörfern) und der typ hat alle reingeklopp ohne wohl darüber nachzudenken, woher die daten kommen sollen. ach ja, die relationen fehlen meistens auch. in osm ist das ja ok, aber in der strassenliste? Da kann ich nichts machen - versuchen aus der history zu reverse engineeren wer das ist - Deshalb schrieb ich ja - eine kontaktmoeglichkeit in die commit message ... f) manche sehen die sache mit der strassenliste wohl darin, die weissen flecken rot anzumalen. um die notwendigen strassendaten kümmert sich fast keiner. und wenn sie drin stehen, dann frag ich mich manchmal schon, woher die kommen. ich warte noch auf den tag, wo jemand eine ganze telefon-cd reinklopft - wenn er nicht schon dabei ist. hauptsache grünlich. (grünlich ohne d) Es wird nicht gruen je mehr Straßen in der list sind .. ein vernünftiger abgleich dauert bis zu 2 wochen, vom eintragen über den kontakt zur gemeinde, nachhaken, namen reinladen und abgleichen. dabei gibt es sogar fehler in der offiziellen liste der gemeinde. die wird nämlich bei kleineren gemeinden von hand als sheet (oder sh.t?) geführt und ist in der regel auch falsch! Also ich habe NRW in 8 Wochen gemacht - Boundarys raten und Listen abklappern. Und Kontakt zur Gemeinde war immer der letzte Notnagel - Das kann auch mal 2 Jahre dauern bis man da Antwort bekommt. Ich habe meist auf den Webseiten mir die Straßenlisten zur Wahlbekanntmachung besorgt und umkonvertiert. p.s. hab nen neuen thread angefangen, weil der alte a) sehr lang b) inzwischen an thema vorbei ist. Und so viele Punkte in einer Mail ist ein garant dafuer das es bald mit diesem auch wieder so ist. Flo -- Florian Lohoff f...@zz.de Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Routing auf WinCE
Johann H. Addicks schrieb: Wenn ich mir anschaue, welche Verrenkungen man unternehmen muss, um z.B. bei NaviPOWM überhaupt erstmal Kartenmaterial auf's Gerät zu bekommen Kacheln auf der Karte anklicken, entpacken und auf's Geraet kopieren? (Labyrinth von veralteten Repositories Das Repository auf SourceForge ist immer aktuell, da es dort gehostet wird. Ein Labyrinth ist es auch nicht wirklich. Es gibt binaries und den Source. Letzteren wahlweise ueber svn, oder als tgz. Die Optik ist die von SF, und ja, die war frueher besser (TM). DAU-inkombatibler Kachel-Downloader), Kacheln auf der Karte anklicken, entpacken und auf's Geraet kopieren? Ausserdem steht auf SF klar: Intended Audience: Advanced End Users, Developers, was ziemlich weit entfern von DAU-kompatibel ist. Und Status is ja noch alpha. dann keine (wahlweise verständliche oder aktuelle?) Doku für die Anwendung selbst Das stimmt allerdings. Hilfe kannst Du aber hier auf der Liste bekommen, oder aber unter: http://forum.pocketnavigation.de/forum1000212-openstreetmap/ dann ist das fehlender Routing-Anwendung fast noch das kleinste Problem. Es gibt eigentlich gar kein Problem. :-) (Wobei ich ernsthaft bezweifle, dass mit dem derzeitigen Kachel-Datenformat überhaupt Routing über weitere Strecken möglich sein wird.) Wenn es irgendwann an's Routing geht, wird das Format angepasst. Bis dahin sind die Vorteile groesser als die Nachteile. Julian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing auf Navi für Anfänger
Hallo André, bedauerlicherweise ist der Thread etwas unangenehm OT geworden. Danke an alle, die noch bei meiner Anfängerfrage sind. Bei den Antworten fürchtete ich schon, dass ich das Navi nun als MP3-Player und Foto-DB nutzen muss (oder notfalls halt mit den mitgelieferten Karten). Wäre auch nicht schlimm, war ja gratis. Inzwischen bin ich aber etwas weiter: Auf unserem Nürnberger Stammtisch hatte Robert ein Lowrance-Endura dabei. Das Enduro hat ein offenes System, und da ist auch eine Micro-SD drin. Also haben wir mal die Karten getauscht. Und siehe da: auf meinem Navi läuft TotalCommander! Das ist doch schon die halbe Miete - oder? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Otto-Normalmapper-kompatible Erklärung von Relationen
Nils Heuermann w...@oemmes.net wrote: Was ist eine Rolle? Wenn man einer Relation [1] einen Weg oder Punkt (oder auch eine andere Relation) als Mitglied (member) hinzufügt, kann man dem jeweiligen Objekt eine Rolle (role) [2] zuordnen. Zum Beispiel gibt es bei Abbiegebeschränkungen [3] die Rollen from, to und via, um anzugeben, *von* welcher Straße man *über* welchen Punkt *in* welche Straße (nicht) fahren darf. Bei den wayparts habe ich für die einzelnen Wege, für die man Spuren eintragen möchte, die Rolle way vorgesehen [4]. Man könnte dann z. B. für die im Thread diskutierten Ausnahmen eine Rolle except (oder wie immer man sie auch nennt - deshalb erfinden/definieren) für Punkte/Nodes festlegen. Hoffe, das war verständlich :) Viele Grüße, Nils [1] http://wiki.openstreetmap.org/wiki/Relations [2] http://wiki.openstreetmap.org/wiki/Roles [3] http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Mindestanforderung [4] http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts#Mitglieder Ahja, Vielen Dank! :-) Relationen sind für viele User von OSM ein Buch mit sieben Siegeln. Das schreibe ich einmal der algorithmisch korrekten Beschreibung im Wiki zu. Vielleicht sollte man zur Einführung erst einmal alle Fünfe gerade lassen, und ein anfängliches Grundverständnis vermitteln, indem man auf dem Weg erst einmal verkomplizierende Sachverhalte wegläßt und die Wahrheit nur stückweise ans Tageslicht gelangen läßt. So gerüstet kann der User dann auf die algorithmisch korrekte Erklärung losgelassen werden. Ich versuche im Folgenden einmal, dieses Basisverständnis von Relationen, deren Sortierung und Rollen für Nichtprogrammierer bzw. Otto Normalmapper zu vermitteln: Manche Dinge in OSM lassen sich nicht durch die üblichen Punkte und Wege mit angeschlossenen Tags in den Griff bekommen. Um komplexere Zusammenhänge zu beschreiben, gibt es daher die sogenannten Relationen. Eine einfache Relation ist zunächst einmal nur eine Auswahl von Wegen und Punkten, genannt Members (Mitglieder), welche in die Relation wie in einen Korb eingesammelt werden. Der Typ der Relation beschreibt, zu welchem Zweck die Relation dient. Ist der Zweck beispielsweise die Beschreibung einer Route, werden die betroffenen Wegstücke in die Relation eingesammelt. Obwohl dem User intuitiv klar ist, dass die Wegstücke in der richtigen Reihenfolge anzuordnen sind, ist die OSM Datenbank nicht in der Lage, die korrekte Reihenfolge zu erkennen. Daher muss man die Members in der richtigen Reihenfolge sortieren. Abgesehen von der Reihenfolge stehen die Members einer Relation vom Typ Route gleichwertig nebeneinander. Bei anderen Typen von Relationen können die Members nicht gleichwertig sein, sondern müssen spezielle Aufgaben in der Relation erfüllen. Diese spezielle Aufgabe nennt man Rolle. Hierzu hat jedes Member einer Relation ein Textfeld, in das diese Rolle eingegeben werden kann. Die Rolle darf nur aus einem einzigen Wort bestehen. Bleibt dieses Rollenfeld leer, wie im Falle der Routenrelation, dann hat das Member keine spezielle Aufgabe/Rolle, sondern nur eine Standardaufgabe. Anders in einer Relation vom Typ Abbiegerelation. Hier muss spezifiziert werden, *von* welcher Straße man *über* welchen Punkt *in* welche Straße (nicht) fahren darf. Dazu werden den Membern die Rollen from, via und to zugewiesen. Es muss also zunächst festgelegt werden, von welchem Typ die Relation ist. Erst dann weiß man, welche Werte die Rolle annehmen kann. Ohne die Typangabe der Relation ist die Angabe einer Rolle also sinnlos. Auch eine Menge von Relationen können wiederum in eine Vaterrelation eingesammelt werden. [Ende des Erklärungstextes] Was mir jetzt noch nicht klar ist: Was passiert, wenn beispielsweise *eine dem Relationstyp nicht zugeordnete Rolle verwendet wird? *eine notwendige Rolle fehlt? *eine Rolle, die es eigentlich nur einmal geben sollte, mehrfach vorkommt? Funktioniert dann die Relation nicht mehr? Ist es von der Anwendung abhängig, wie diese damit umgeht? Was passiert, wenn eine Routenrelation unsortiert bleibt? Ist die Sortierung ein reiner Service (,der aber empfohlen wird) für die Anwendung oder ist sie zwingend gemäß der Spezifikation der Datenbank?/der Routenrelation? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing auf Navi für Anfänger
Und siehe da: auf meinem Navi läuft TotalCommander! Das ist doch schon die halbe Miete - oder? darauf hatte ich dich ja in dem anderen von dir aufgemachten Thread hingewiesen. Ich kann dir da auch noch weitere Links posten, wenn du Interesse hast. Aber die Seiten und Links kann man glaub ich auch nutzen, wenn man nicht angemeldet ist. -- schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] die strassenliste kommt ja so langsam ins rollen.
Die wiki seiten musst du dann schon loeschen und neu in der richtigen Einordnung anlegen. ich suche immer noch im wiki ne möglichkeit, seiten zu löschen. :-( Hmmm - sind beide in meiner polygon tabelle drin. eventuell kronberg? dieser fliegensch.ß ist so klein, dass ich ihn nicht identifizieren kann. hab kronberg mal auf 100% gesetzt. mal sehen, wer grün wird. Abends irgendwann - 18:00 oder so ... und mittags vor 12 e) im norden von rheinland-pfalz schein jemand amok zu laufen, der wohl nicht begriffen hat, worum es hier geht. Da kann ich nichts machen - versuchen aus der history zu reverse engineeren wer das ist - Deshalb schrieb ich ja - eine kontaktmoeglichkeit in die commit message ... echt schade und verdammt unsicher. vor 2-3 tagen hat jemand die wiki-seite von hessen platt gemacht. ich konnte sie aber zurücksetzen. kannst dir ja mal kurz die history ansehen. Es wird nicht gruen je mehr Straßen in der list sind .. stimmt, dazu hab ich mich ja schon in dem alten thread geäußert: 1 strasse in der liste, die auch in osm ist - treffer - 100% -- grün Das kann auch mal 2 Jahre dauern bis man da Antwort bekommt. na ja, so nach zwei wochen ruf ich mal an und dann klappt das schon. Ich habe meist auf den Webseiten die Straßenlisten zur Wahlbekanntmachung besorgt und umkonvertiert. mach ich ähnlich. nutze u.a. pdftotext unter linux. ocr-software will noch nicht so richtig. Und so viele Punkte in einer Mail ist ein garant dafuer das es bald mit diesem auch wieder so ist. sind doch schon ganz wenige geworden :-) eigentlich nur 2 (wiki und weißer fleck) gruss wambacher - Der Fehler tritt nicht sporadisch sondern nur ab und zu auf - Fehlermeldung eines DAUS -- View this message in context: http://n2.nabble.com/die-strassenliste-kommt-ja-so-langsam-ins-rollen-tp4646251p4647233.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] Otto-Normalmapper-kompatible Erklärung v on Relationen
Am 28. Februar 2010 00:55 schrieb Tirkon tirko...@yahoo.de: Was passiert, wenn eine Routenrelation unsortiert bleibt? Ist die Sortierung ein reiner Service (,der aber empfohlen wird) für die Anwendung oder ist sie zwingend gemäß der Spezifikation der Datenbank?/der Routenrelation? die Route ist nicht in allen Fällen nur über die Member eindeutig vorgegeben, daher muss man sie zumindest in diesen Fällen manuell sortieren. Gruß Martin PS: In dem Bereich könnte man evtl. dem Mapper die Arbeit leichter machen, indem die Software bestimmte Dinge von selbst erkennt wie z.B. die Reihenfolge von Routen oder die inner und outer-ways von Multipolygonen (bei Bedarf müsste man dann manuell eingreifen). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am 27.02.2010 22:01, schrieb Nils Heuermann: Wenn man einer Relation [1] einen Weg oder Punkt (oder auch eine andere Relation) als Mitglied (member) hinzufügt, kann man dem jeweiligen Objekt eine Rolle (role) [2] zuordnen. Zum Beispiel gibt es bei Abbiegebeschränkungen [3] die Rollen from, to und via, um anzugeben, *von* welcher Straße man *über* welchen Punkt *in* welche Straße (nicht) fahren darf. Das mag ja alles richtig sein. Aber zumindest für mich kann ich sagen: Ich mappe keine Turn-Restrictions, weil ich schlicht nicht verstehe, wie das geht. Aber ich kippe die gern in Openstreetbugs ein, gibt sicher genügend Leute, die das abarbeiten können. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Otto-Normalmapper-kompatible Erklärung von Relationen
Hallo, Tirkon schrieb: Ich versuche im Folgenden einmal, dieses Basisverständnis von Relationen, deren Sortierung und Rollen für Nichtprogrammierer bzw. Otto Normalmapper zu vermitteln: Danke für Deine Mühe! Klingt für mich sehr gut, würde sicher auch meine Mutter verstehen :-) Wenn Dir eine derartige Erklärung im Wiki fehlt, dann nichts wie rein damit, ich konnte jedenfalls keine groben Unzulänglichkeiten entdecken. Mir war gar nicht mehr bewusst, dass Relationen sooo kompliziert sind ;-) Waren eigentlich von Anfang an ziemlich einleuchtend für mich - 2 oder 3 Beispiele angeschaut, irgendwie schien das selbsterklärend - aber ich könnte es nie so schön beschreiben... Was mir jetzt noch nicht klar ist: Was passiert, wenn beispielsweise *eine dem Relationstyp nicht zugeordnete Rolle verwendet wird? *eine notwendige Rolle fehlt? *eine Rolle, die es eigentlich nur einmal geben sollte, mehrfach vorkommt? Funktioniert dann die Relation nicht mehr? Der Relation als solches ist das ziemlich egal ;-) Ist es von der Anwendung abhängig, wie diese damit umgeht? Genau! Je nachdem wie fehlertolerant diese ist, wird es mehr oder weniger schief gehen... Nicht zugeordnete Rollen (= im Kontext unsinnige) würde ich einfach ignorieren; bei fehlenden notwendigen kann evtl. ein Standard-Wert angenommen werden. Grüße, Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV - Linienabschnitte nur zeitweise
Hallo Wolfgang, In Oxomoa habe ich dazu nur alternate gefunden. Dort steht: Für die Modellierung von abweichenden Linienverläufen wird auch jeweils eine eigene Relation für jeden auftretenden Verlauf erstellt. Das ist doch genau das gefragte oder? Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Nils Heuermann w...@oemmes.net wrote: Wenn man einer Relation [1] einen Weg oder Punkt (oder auch eine andere Relation) als Mitglied (member) hinzufügt, kann man dem jeweiligen Objekt eine Rolle (role) [2] zuordnen. Zum Beispiel gibt es bei Abbiegebeschränkungen [3] die Rollen from, to und via, um anzugeben, *von* welcher Straße man *über* welchen Punkt *in* welche Straße (nicht) fahren darf. Hoffe, das war verständlich :) Viele Grüße, Nils [1] http://wiki.openstreetmap.org/wiki/Relations [2] http://wiki.openstreetmap.org/wiki/Roles [3] http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Mindestanforderung [4] http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts#Mitglieder Ahja, Vielen Dank! :-) Ich habe einen neuen Thread aufgemacht, um die Thematik des Erklärens weiter zu führen: Otto-Normalmapper-kompatible Erklärung von Relationen Bei den wayparts habe ich für die einzelnen Wege, für die man Spuren eintragen möchte, die Rolle way vorgesehen [4]. Man könnte dann z. B. für die im Thread diskutierten Ausnahmen eine Rolle except (oder wie immer man sie auch nennt - deshalb erfinden/definieren) für Punkte/Nodes festlegen. Ist eigentlich das Aussschließen von Knotenpunkten aus einer Relation deswegen nicht möglich, weil die Editoren es nicht bereitstellen, oder weil die Datenbank es nicht speichern kann? Wayparts sind allerdings ohne speziellen, nahe an der Kartendarstellung arbeitenden grafikartigen Editor für Otto Normalmapper kaum mehr nachvollziehbar. Gerade in ländlichen Gebieten steht ein Mapper häufig allein vor einem großen Gebiet, so dass er vor Ort die einfachsten Änderungen z.B. Umbenennung der Straße wegen des Vorhandenseins von Wayparts nicht mehr aktualisieren könnte. Ich und auch viele meiner OSM-Nachbarn sähen sich außerstande, dies in seinem Gebiet zu tun. Wayparts wären - wie jedes komplizierte Relationengebilde - mit dem grafikartigen Potlatch nicht mehr zugreifbar. Wird Dein Waypart Plugin da Abhilfe schaffen, indem er einen solchen nahe an der Karte arbeitenden Editor bereitstellt? Oder ist das Plugin im üblichen JOSM (für mich undurchschaubaren) Text- und Fenster-Bastelstil für Relationen gehalten? Können eigentlich von Radweg und Straße eingeschlossene Eisenbahnlinien auch mit Waypart in die Linienbündelung eingeschlossen werden? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am 27. Februar 2010 16:59 schrieb Johann H. Addicks addi...@gmx.net: Am 27.02.2010 15:48, schrieb Martin Koppenhoefer: Oder anders: Wieviele Abbiegerelationen willst Du bauen, wenn auf eine Straße mit durchgezogener Mittellinie haufwenweise service-ways von Geschäften etc. münden? Jedes Mal den Way nochmal durchhaken und eine turn-restriction-relation draufbauen? das ist zugegebenermaßen auch unbefriedigend, daher würde ich im derzeitigen Datenmodell gerne die durchgezogene Mittellinie durch einen entsprechenden tag markieren, no u-turn finde ich dabei aber nicht besonders intuitiv (man darf ja z.B. auch nicht links abbiegen bzw. in gleicher Richtung über die Mittellinie fahren). Zusätzlich sollte man einen tag für Kreuzungsnodes haben, wenn dort die Mittellinie für Farhzeuge aus einmündenden Straßen und Einfahrten oder zum Abbiegen unterbrochen ist (gibt's häufiger, z.B. an Tankstellen). Durch Reflektoren und/oder Bordsteine baulich getrennte Fahrbahnen sehe ich hier allerdings nicht betroffen. Da würde ich eher mit einer Relation herangehen (m.E. könnte man das mit einer area-Relation machen, damit kannst Du definieren, dass zwischen parallelen Spuren gewechselt werden kann, und was ggf. die Trennung ist). Oder überall getrennt Richtungsfahrbahnen mappen, wo gar keine solchen vorhanden sind? ja, als getrennte Fahrbahnen zu mappen ist natürlich falsch, wenn es nur eine Fahrbahn ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am 28. Februar 2010 01:16 schrieb Johann H. Addicks addi...@gmx.net: Das mag ja alles richtig sein. Aber zumindest für mich kann ich sagen: Ich mappe keine Turn-Restrictions, weil ich schlicht nicht verstehe, wie das geht. es ist im Prinzip sehr einfach: man macht eine neue Relation und fügt die Straße, aus der man kommt und die Straße in die man fährt sowie den Kreuzungspunkt der beiden zu dieser Relation hinzu. Die beiden Straßen müssen dabei jeweils im Kreuzungspunkt enden (ways ggf. aufsplitten). Dann schreibt man ins Feld role/Rolle bei der Straße, aus der man kommt, from rein, der Node bekommt via und die Straße wo man hinwill to. Zuletzt gibt man der Relation selbst tags: type=turn_restriction sowie die Art der Einschränkung wie hier beschrieben: http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Hinweis%20zur%20Beschilderung z.B. restriction=only_left_turn (nur linksabbiegen erlaubt) Die Relationen macht man übrigens mit dem Zahnradsymbol und dann auf Plus. Das Hauptproblem sind dicht gemappte Bereiche, wo man ziemlich aufpassen muss, weil wenn die Straße schon Bestandteil einer Relation ist, diese Zugehörigkeit beim Splitten wieder auf beide Teilstücke übertragen wird. Bei einem muss man es nach dem Splitten allerdings löschen (habe gerade mal ein Enhancement-Vorschlags-Ticket hierzu erstellt, vielleicht könnte JOSM einem hier helfen). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Otto-Normalmapper-kompatible Erklärung von Relationen
Tirkon wrote: Was mir jetzt noch nicht klar ist: Was passiert, wenn beispielsweise *eine dem Relationstyp nicht zugeordnete Rolle verwendet wird? *eine notwendige Rolle fehlt? *eine Rolle, die es eigentlich nur einmal geben sollte, mehrfach vorkommt? Funktioniert dann die Relation nicht mehr? Ist es von der Anwendung abhängig, wie diese damit umgeht? Es ist ein undefinierter Zustand wenn solche Fehler vorhanden sind. Was die jeweilige Software daraus macht ist Zufall, die kann den Fehler ausbügeln aber es kann zu einer fehlerhaften Interpretation kommen bis zu kompoletten ignorieren/verwerfen der Relation. Also selbst wenn so eine Relation bei Software A (wie z.b. mapnik) funbktioniert so kann es bedeuten das die Relation verworfen wird von Software B. Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Otto-Normalmapper-kompatible Erklärung von Relationen
Hallo, Matthias Versen wrote: Was passiert, wenn beispielsweise *eine dem Relationstyp nicht zugeordnete Rolle verwendet wird? *eine notwendige Rolle fehlt? *eine Rolle, die es eigentlich nur einmal geben sollte, mehrfach vorkommt? Funktioniert dann die Relation nicht mehr? Ist es von der Anwendung abhängig, wie diese damit umgeht? Es ist ein undefinierter Zustand wenn solche Fehler vorhanden sind. Was die jeweilige Software daraus macht ist Zufall, die kann den Fehler ausbügeln aber es kann zu einer fehlerhaften Interpretation kommen bis zu kompoletten ignorieren/verwerfen der Relation. Also selbst wenn so eine Relation bei Software A (wie z.b. mapnik) funbktioniert so kann es bedeuten das die Relation verworfen wird von Software B. Das ist so wie bei allem anderen in OSM auch: Was ist, wenn ein Objekt ein Tag hat, das die Software nicht kennt? 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] Otto-Normalmapper-kompatible Erklärung von Relationen
Matthias Versen s...@mversen.de wrote: Es ist ein undefinierter Zustand wenn solche Fehler vorhanden sind. Was die jeweilige Software daraus macht ist Zufall, die kann den Fehler ausbügeln aber es kann zu einer fehlerhaften Interpretation kommen bis zu kompoletten ignorieren/verwerfen der Relation. Dann wäre also Folgendes denkbar: 1) Es existiert eine Buslinien Relation. Diese taucht aber in der ÖPNV-Karte nicht auf. Grund dafür könnte sein, dass an einer einzigen Haltestelle ein Tippfehler bei der Rolle existiert. 2) Das von der ÖPNV Karte unterstützte ÖPNV Schema wurde geändert. Eine ehemals unterstützte Rolle wird in einer neuen Version nicht mehr verwendet. Folge: Die Buslinie verschwindet von der Karte. 3) Ein Straßenstück hat eine Richtung. Diese Richtung wird von einer Relation benutzt. Der Editor Potlatch unterstützt Relationen nur rudimentär. Es ist dort nicht erkennbar, dass die Straßenrichtung von einer Relation benutzt wird. Ein User dreht daher die Richtung um. Die betroffene Relation verschwindet komplett aus der Anwendung. 4) Ein gerades Straßenstück besteht aus drei Punkten. Der mittlere Punkt erscheint zunächst überflüssig, ist aber Mitglied einer Relation. Ein User löscht den mittleren Punkt. Die Relation verschwindet aus der Anwendung. ... Es gibt da einen User, der Videoanleitungen für das Editieren in OSM herausgibt. In diesen Anleitungen löscht er solche überflüssigen Punkte, ohne den Anwender auf die mögliche Verwendung dieses Punktes in einer Relation hinzuweisen. Der Name des Autors dieser Anleitung ist ... SteveC. ;-) http://www.youtube.com/watch?v=8MF4oJIHuQwfeature=player_embedded ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Otto-Normalmapper-kompatible Erklärung von Relationen
Hallo, Tirkon wrote: 1) Es existiert eine Buslinien Relation. Diese taucht aber in der ÖPNV-Karte nicht auf. Grund dafür könnte sein, dass an einer einzigen Haltestelle ein Tippfehler bei der Rolle existiert. Ja, aber das waere von der Oepnv-Karte schon ziemlich bloed. Der Betreiber der Oepnv-Karte muss ja mit so etwas rechnen und ist daran interessiert, moeglichst viele Daten anzuzeigen und nicht moeglichst wenig. Auch alle anderen von Dir genannten Punkte fallen darunter - jede Anwendung darf so pingelig sein, wie sie will; natuerlich koennte ich auch einen Renderer schreiben, der Strassen, deren Ref-Tag kein Leerzeichen nach dem Buchstaben hat, grundsaetzlich nicht zeichnet, oder der eine highway=residential nicht zeichnet, wenn sie keinen Namen hat, oder sonst was. Aber richtig sinnvoll ist das nicht. Mit Relationen hat diese Frage der Pingeligkeit eigentlich gar nichts zu tun, auch mit normalen Objekten kann man schon beliebig viel falsch machen. 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] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Am Sun, 28 Feb 2010 02:00:57 +0100 hat Tirkon tirko...@yahoo.de geschrieben: Bei den wayparts habe ich für die einzelnen Wege, für die man Spuren eintragen möchte, die Rolle way vorgesehen [4]. Man könnte dann z. B. für die im Thread diskutierten Ausnahmen eine Rolle except (oder wie immer man sie auch nennt - deshalb erfinden/definieren) für Punkte/Nodes festlegen. Ist eigentlich das Aussschließen von Knotenpunkten aus einer Relation deswegen nicht möglich, weil die Editoren es nicht bereitstellen, oder weil die Datenbank es nicht speichern kann? wie schon gesagt: man kann es (selber) möglich machen. Eine Relation hat erst mal nichts mit einer Straße/Weg zu tun. Es gibt auch Relationen, die nur aus Punkten/Nodes bestehen (hab zwar gerade kein Beispiel...) oder eine Relation, die ausschließlich andere Relationen enthält. Man kann in/mit der Relation also speichern, was man möchte. Daher kann man Ways und Nodes lustig durcheinander reinspeichern, und wenn man in seinem Auswertungsprogramm Nodes mit einer bestimmten Rolle als Ausschluss-Nodes behandelt, ist es kein Problem. Ich sehe das als Anforderung an die auswertende Anwendung. Wayparts sind allerdings ohne speziellen, nahe an der Kartendarstellung arbeitenden grafikartigen Editor für Otto Normalmapper kaum mehr nachvollziehbar. Das ganze ist auch erst mal nur ein Ansatz. Das hat (wahrscheinlich) noch niemand benutzt, außer ich bei meinem Beispiel ;) Auch kann noch kein Programm damit umgehen. Wird Dein Waypart Plugin da Abhilfe schaffen, indem er einen solchen nahe an der Karte arbeitenden Editor bereitstellt? Damit das System funktioniert (vorausgesetzt, die Logik hat keine Macken), braucht man natürlich einen grafischen Editor, mit dem man sich die einzelnen Spuren usw. auf einfache Weise zusammenklicken kann. Da muss noch etwas Programmierarbeit reingesteckt werden :) Gerade in ländlichen Gebieten steht ein Mapper häufig allein vor einem großen Gebiet, so dass er vor Ort die einfachsten Änderungen z.B. Umbenennung der Straße wegen des Vorhandenseins von Wayparts nicht mehr aktualisieren könnte. Das wäre kein Problem. Die wayparts beschreiben den Querschnitt der Straße und ggf. spurabhängige Einschränkungen (z. B. Busspur). Der Name und andere allgemeine Eigenschaften (highway, surface, ...) bleiben weiterhin am ganz normalen Way (letztere könnten allerdings für einzelne Spuren überschrieben werden). Können eigentlich von Radweg und Straße eingeschlossene Eisenbahnlinien auch mit Waypart in die Linienbündelung eingeschlossen werden? Theoretisch ist das möglich. Man sollte allerdings abwägen, ob es in so einem Fall nicht sinnvoller ist, die Dinge als einzelne Wege zu erfassen. Schönen Sonntag noch! Nils ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] die strassenliste kommt ja so langsam ins rollen.
On Sat, Feb 27, 2010 at 04:06:50PM -0800, Walter Nordmann wrote: Die wiki seiten musst du dann schon loeschen und neu in der richtigen Einordnung anlegen. ich suche immer noch im wiki ne möglichkeit, seiten zu löschen. :-( Edit aufmachen - alles markieren - entfernen - abspeichern? Damit ist die Seite leer ... Ich habe meist auf den Webseiten die Straßenlisten zur Wahlbekanntmachung besorgt und umkonvertiert. mach ich ähnlich. nutze u.a. pdftotext unter linux. ocr-software will noch nicht so richtig. Manchmal funktioniert alles markieren und kopieren besser als pdftotext. Aber da ist jede liste anders ... Flo -- Florian Lohoff f...@zz.de Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
