[Talk-de] osm2pgsql Import Probleme
Hallo, ich will mit osm2pgsql Daten in eine Postgis DB importieren. Leider werden aber nicht alle Objekte, die in der Quell-Datei vorhanden sind, auch importiert. Die Styledatei habe ich schon angepasst, hat aber leider nichts gebracht. Alex ___ 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 05.02.2011 02:22, schrieb Stefan Keller: Also so können wir den Relevanz-Thread nicht stehen lassen: Habe mal versucht mich ins Schema einzuarbeiten und muss jetzt sagen, dass dieses TMC ein Negativbeispiel ist - so wie die Tags daherkommen und wie sie (nicht) erklärt sind. Bereits beim erst besten Tag, z.B. TMC:LocationCode steht auf http://wiki.openstreetmap.org/wiki/Key:TMC:LocationCode Man betrachte mal dort den Satz (CID) is replaced by the country-id (e.f. 58 for Germany): Was ist e.f.? Was ist (CID)? Auf was bezieht sich das? (aha rechts steht da etwas kryptisches TMC:cid_(CID):tabcd_(TABCD):LocationCode). Dann wird die Erklärung von CID zwei Sätze weiter unten gleich wieder abgeschwächt: Note: the unique CID(e.g. 58) used here is not the transmitted but a non-unique CCID(e.g. 0xD) and mapped to the CID via COUNTRIES.DAT of the LCL.. Man lasse sich diesen Satz durch die Zunge gehen... Dann diese Aneinanderreihung von Doppelpunkten... Keine Chance das zu verstehen - Das die Beschreibung verbessert werden kann, ist bei OSM selten die Frage ;-) Die Art, wie du hier über die Beschreibung herziehst, zeigt aber eher dein Unverständnis beim Lesen einer eher technischen Dokumentation (was ein System wie TMC nun mal ist). Ob wir hier eher eine andere Art von Beschreibung brauchen steht allerdings auf einem anderen Blatt. Der allererste Satz auf der Seite lautet: This key is used to add the TMC location-code to a map-element TMC/TMC_Import_Germany#Tagging_Schema. ... mit einem Link auf dieses Tagging Schema. Erstmal dort die Einleitung zu lesen hilft wirklich weiter (beantwortet aber auch nicht alles). Der Satz: (CID) is replaced by the country-id (e.f. 58 for Germany) legt nahe, daß hier schlicht ein Tippfehler ist und es besser: (CID) is replaced by the country-id (e.g. 58 for Germany) heissen sollte (hab's korrigiert). Aus diesem Satz kann man schon gut herauslesen, daß CID dann wohl eine Abkürzung für country-id sein dürfte und 58 dabei der Wert ist, der Deutschland repräsentiert. Die Beschreibung ist allerdings aus anderen Gründen unzureichend. Ich kann herauslesen wie die Tags zustandekommen. Damit kann ich aber weder meine eigene TMC Software schreiben (die Abbildung der TMC Empfangsdaten auf die Tags bleibt unklar) - was allerdings auch nicht unbedingt hier stehen muß. Auch ist es keine gute Anleitung wie ein Mapper mit diesen Tags umzugehen hat. Das Problem haben wir aber auch bei vielen anderen Tag Beschreibungen. auch mit den Links unten nicht: 4 von 5 auf der deutschen und englischen TMC-Seite sind tot... Ich habe hier nicht einen roten Link?!? Man könnte sicher hier und da Sachen vereinfachen, aber so krass wie du es darstellst ist es nun auch nicht ... Gruß, ULFL P.S: Das die Beschreibung etwas kryptisch ist, liegt sicher auch daran, das bislang kaum einer danach gefragt hat. Ich kann mich zumindest nicht dran erinnern, daß hier vorher schonmal solche Fragen wie deine gefragt wurden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Hallo, gerade verfolge ich offenkundige Wasserläufe, die am Baumbestand gut zu erkennen sind: 52.0419731 N / 8.2430264 E Hier hat jemand landuse=forest getaggt, m.E. gehören die Bäume am Wasserlauf jedoch nicht mehr zum Wald bzw. sind als linienhafte Struktur (Baumreihe, Hecke) zu erfassen. Was sagen die Experten? Danke Gruß Ralf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Ein Link zur Stelle statt der Koordinaten wär hilfreicher. Liebe Grüße Benni Am Samstag, den 05.02.2011, 13:21 +0100 schrieb RalfGesellensetter: Hallo, gerade verfolge ich offenkundige Wasserläufe, die am Baumbestand gut zu erkennen sind: 52.0419731 N / 8.2430264 E signature.asc Description: This is a digitally signed message part ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Hallo, Am Samstag 05 Februar 2011 13:21:16 schrieb RalfGesellensetter: Hallo, gerade verfolge ich offenkundige Wasserläufe, die am Baumbestand gut zu erkennen sind: 52.0419731 N / 8.2430264 E Hier hat jemand landuse=forest getaggt, m.E. gehören die Bäume am Wasserlauf jedoch nicht mehr zum Wald bzw. sind als linienhafte Struktur (Baumreihe, Hecke) zu erfassen. Was sagen die Experten? So was wie eine maritime Allee. Baumgruppe, Hecke, Knick und scrub passen nicht so recht. Wenn im Wiki noch nichts drin ist, denk dir ein Tag aus. Uferbebaumung? Uferbewaldung? Uferwald? Uferbaumreihe? Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Weinlagen
Hallo, wie sollte man bei einem Weinberg den Namen der Lage angeben? Im Weinbau ist es üblich damit anzugeben, von welchem Weinberg die Trauben für den Wein stammen. Gebe ich nur landuse=vineyard und name=Name_des_Weibergs an oder setze ich dazu noch ein place=locality? Und dann gibt es ja noch Großlagen, zu denen viele einzelne Weinberge gehören. Hier bietet sich die Zusammenfassung über eine Relation an? Danke für Eure Tipps, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weinlagen
Am 5. Februar 2011 13:41 schrieb Falk Zscheile falk.zsche...@googlemail.com: Hallo, wie sollte man bei einem Weinberg den Namen der Lage angeben? Im Weinbau ist es üblich damit anzugeben, von welchem Weinberg die Trauben für den Wein stammen. Gebe ich nur landuse=vineyard und name=Name_des_Weibergs an oder setze ich dazu noch ein place=locality? Und dann gibt es ja noch Großlagen, zu denen viele einzelne Weinberge gehören. Hier bietet sich die Zusammenfassung über eine Relation an? Ja, das schreit m.E. nach einem durchdachten Proposal. place=locality is natürlich möglich, andererseits ziemlich generisch. Ein tag aus dem hervorgeht, dass es sich um eine Weinlage handelt wäre nicht schlecht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 5. Februar 2011 13:21 schrieb RalfGesellensetter r...@gmx.de: Hier hat jemand landuse=forest getaggt, m.E. gehören die Bäume am Wasserlauf jedoch nicht mehr zum Wald bzw. sind als linienhafte Struktur (Baumreihe, Hecke) zu erfassen. Was sagen die Experten? m.E. ist es sinnvoll, die Landbedeckung möglichst detailliert zu erfassen. landuse=forest hat dabei derzeit m.E. nicht mehr Aussage als: da stehen Bäume. Wälder sind ja erst größere zusammenhängende Flächen, darunter gibt es sowas wie Hain, Baumgruppe etc., die m.E. derzeit alle in landuse=forest eingeschlossen sind. Sowas wie Teutoburger Wald, Schwarzwald o.ä. können wir derzeit kaum abbilden (gut, eine MP-Relation wäre geeignet, wenn es nicht zu viele Einzelteile sind). Ob sich eine linienhafte (oder punkthafte) Erfassung gegenüber einer flächenhaften anbietet, muss der Mapper entscheiden, ich mache derzeit entweder Einzelbäume oder Flächen. Man könnte auch landcover=trees für Baumbestand nehmen, und dann diese Flächen zu einer Relation mit landuse=forest (semantisch besser wäre evtl. natural=forest für große Flächen und natural=woods / woodland für kleinere/dünnere Teile, da geografisches Feature) zusammenzufassen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 5. Februar 2011 13:32 schrieb Wolfgang wolfg...@ivkasogis.de: So was wie eine maritime Allee. Baumgruppe, Hecke, Knick und scrub passen nicht so recht. Wenn im Wiki noch nichts drin ist, denk dir ein Tag aus. Uferbebaumung? Uferbewaldung? Uferwald? Uferbaumreihe? das würde ich eher als Subtag setzen. Erstmal: da sind Bäume, dann weiter, welche Art von Kontext es ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 13:32, schrieb Wolfgang: Hallo, Am Samstag 05 Februar 2011 13:21:16 schrieb RalfGesellensetter: Hallo, gerade verfolge ich offenkundige Wasserläufe, die am Baumbestand gut zu erkennen sind: 52.0419731 N / 8.2430264 E Hier hat jemand landuse=forest getaggt, m.E. gehören die Bäume am Wasserlauf jedoch nicht mehr zum Wald bzw. sind als linienhafte Struktur (Baumreihe, Hecke) zu erfassen. Was sagen die Experten? So was wie eine maritime Allee. Baumgruppe, Hecke, Knick und scrub passen nicht so recht. Wenn im Wiki noch nichts drin ist, denk dir ein Tag aus. Uferbebaumung? Uferbewaldung? Uferwald? Uferbaumreihe? Was soll denn mit dieser Unterscheidung erreicht werden? Das die Baumreihe am Wasser steht ergibt sich aus der Geometrie und ist kein direktes Feature dieser Baumreihe. Oder schreiben wir demnächst: Alleebaumreihe? Feldwegbaumreihe? Parkanlagenwegbaumreihe? NebenDemHospitalZurVerschönerungDerLandschaftBaumReihe? ... und sich dann am besten zwei Monate später beschweren, das sowas kein Renderer auswertet ... ;-) Was ist genau das Problem mit landuse=forest? Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 13:58, schrieb M∡rtin Koppenhoefer: Am 5. Februar 2011 13:21 schrieb RalfGesellensetterr...@gmx.de: Hier hat jemand landuse=forest getaggt, m.E. gehören die Bäume am Wasserlauf jedoch nicht mehr zum Wald bzw. sind als linienhafte Struktur (Baumreihe, Hecke) zu erfassen. Was sagen die Experten? m.E. ist es sinnvoll, die Landbedeckung möglichst detailliert zu erfassen. landuse=forest hat dabei derzeit m.E. nicht mehr Aussage als: da stehen Bäume. Und aus der Größe der Fläche kann man prima auf die Größe des Waldes schliessen ;-) Wälder sind ja erst größere zusammenhängende Flächen, darunter gibt es sowas wie Hain, Baumgruppe etc., die m.E. derzeit alle in landuse=forest eingeschlossen sind. Nein, ein Wald ist erstmal ein Gebiet wo hauptsächlich Bäume stehen. Ab wann jemand zu ein paar Bäumen nicht mehr Baumgruppe sondern kleiner Wald sagt dürfte sowohl regional als auch individuell sehr unterschiedlich sein. Sowas wie Teutoburger Wald, Schwarzwald o.ä. können wir derzeit kaum abbilden (gut, eine MP-Relation wäre geeignet, wenn es nicht zu viele Einzelteile sind). Das sind auch keine Wälder - wie der Name aufgrund der Historie suggeriert - sondern Mittelgebirge. Das dazu passende Thema Regionen hatten wir neulich schon. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 5. Februar 2011 14:14 schrieb Ulf Lamping ulf.lamp...@googlemail.com: m.E. ist es sinnvoll, die Landbedeckung möglichst detailliert zu erfassen. landuse=forest hat dabei derzeit m.E. nicht mehr Aussage als: da stehen Bäume. Und aus der Größe der Fläche kann man prima auf die Größe des Waldes schliessen ;-) nein, das geht leider nicht, da die Trennung der Flächen sowohl technisch bedingt ist, als auch teilweise zufällig. Wälder sind ja erst größere zusammenhängende Flächen, darunter gibt es sowas wie Hain, Baumgruppe etc., die m.E. derzeit alle in landuse=forest eingeschlossen sind. Nein, ein Wald ist erstmal ein Gebiet wo hauptsächlich Bäume stehen. Ab wann jemand zu ein paar Bäumen nicht mehr Baumgruppe sondern kleiner Wald sagt dürfte sowohl regional als auch individuell sehr unterschiedlich sein. das stimmt so nicht ganz. Die Grenzen sind zwar fließend, aber der Wald ist ein komplexes Ökosystem, das nicht nur durch Bäume definiert ist, und 3 Bäume sind z.B. definitiv kein ganz kleiner Wald. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 13:21, schrieb RalfGesellensetter: Hier hat jemand landuse=forest getaggt, m.E. gehören die Bäume am Wasserlauf jedoch nicht mehr zum Wald bzw. sind als linienhafte Struktur (Baumreihe, Hecke) zu erfassen. Was sagen die Experten? hier in der Eifel (und auch anderswo) sind Baumreihen oft aus Hecken herausgewachsen früher nicht ohne Grung: Brennholzgewinnung, heute weil keiner Zeit für die Heckenpflege mehr hat. Ich habe solche Gebilde hier in der nahen Umgebung mal als Hecke getaggt (gibts denn so was wie BAumreihen?) Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 14:18, schrieb M∡rtin Koppenhoefer: Am 5. Februar 2011 14:14 schrieb Ulf Lampingulf.lamp...@googlemail.com: Und aus der Größe der Fläche kann man prima auf die Größe des Waldes schliessen ;-) nein, das geht leider nicht, da die Trennung der Flächen sowohl technisch bedingt ist, als auch teilweise zufällig. Und was genau ist die Fläches des Waldes? Der von Ästen überschattete Bereich? Die äußerste Grenze der Stämme? Nein, ein Wald ist erstmal ein Gebiet wo hauptsächlich Bäume stehen. Ab wann jemand zu ein paar Bäumen nicht mehr Baumgruppe sondern kleiner Wald sagt dürfte sowohl regional als auch individuell sehr unterschiedlich sein. das stimmt so nicht ganz. Die Grenzen sind zwar fließend, aber der Wald ist ein komplexes Ökosystem, das nicht nur durch Bäume definiert ist, und 3 Bäume sind z.B. definitiv kein ganz kleiner Wald. Diese Frage ist übrigens ein weltweites Problem, was ist ein Wald? Dieses Problem treibt z.B. auch die großen in dem Bereich um, nur als ein paar Beispiele: FAO, UN, WWF, die Landwirtschaftsministerien aller Länder... Ist ein loser Verbund vieler Bäume auf einer kleinen Fläche schon ein Wald? Benötigt ein Wald eine bestimme Dichte, oder ist das abhängig von den Spezies, die dort wachsen? Ist es ein Wald, wenn alle Bäume in Reih und Glied stehen? Ist dichtes Unterholz ein Indiz für oder gegen einen Wald? Ist die Fauna ausschlaggebend? Derzeit läuft - mal wieder - ein groß angelegtes Fernerkundungsprogramm der ESA, bei dem auch mein derzeitiger Arbeitgeber eingebunden ist, und da hauen sich die Experten auch wieder die Köpfe ein. Mit anderen Worten: es gibt keine allgemein anerkannte Definition von Wald, und ich glaube auch nicht, dass die hier erschaffbar ist. Ich halte ein landuse=forest für überall sinnvoll, wo nicht wirklich vereinzelt stehende Bäume erfasst werden. Ein natural=* tag is IMHO übrigens immer noch (fast) überall falsch. In Europa z.B. gibt es (fast) keine natürlichen Wälder mehr. Viele Grüße, Florian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] C# Entwickler für kleine Reparatur gesucht
Hi! Das (leicht angestaubte) Tool srtm2osm zur Erzeugung von Höhenlinien funktioniert derzeit nicht mehr, da es für seine Höhenlinien Node-IDs ab 1 Milliarde vergibt, inzwischen gibt es allerdings echte Nodes in diesem Bereich. Hat jemand auf der Liste veilleicht eine C# Entwicklungsumgebung herumliegen und Lust das Tool in Ordnung zu bringen? Für eine Schnellreparatur geht es nur darum, eine einzige Konstante zu ändern und neu zu compilieren. Oder kennt jemand ein anderes Tool, das srtm2osm vollständig ersetzten könnte: - nimmt ein Rechteck als Parameter - erzeugt Höhenlinien aus SRTM für genau diesen Ausschnitt - Ausgabe in OSM oder einem ähnlich einfachen Format zur Weiterverarbeitung - läuft ohne ohne weitere Biblotheken unter Windows? bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/C-Entwickler-fur-kleine-Reparatur-gesucht-tp5995433p5995433.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] Wieviel Bäume sind ein Wald - Uferbäume
Am 5. Februar 2011 14:26 schrieb Steffen Heinz eifelhu...@gmx.de: Am 05.02.2011 13:21, schrieb RalfGesellensetter: Ich habe solche Gebilde hier in der nahen Umgebung mal als Hecke getaggt (gibts denn so was wie BAumreihen?) Für Baumreihen (unabhängig davon ob sie Alleen bilden): http://wiki.openstreetmap.org/wiki/Proposed_features/Tree_rows http://wiki.openstreetmap.org/wiki/DE:Tag:natural%3Dtree Wobei es wohl noch keinen klaren ausschlag zu einem der beiden Varianten gibt: natural=tree_row landuse=treerow Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Wolfgang schrieb: So was wie eine maritime Allee. Baumgruppe, Hecke, Knick und scrub passen nicht so recht. Wenn im Wiki noch nichts drin ist, denk dir ein Tag aus. Uferbebaumung? Uferbewaldung? Uferwald? Uferbaumreihe? natural=tree wäre vermutlich zu einfach? malenki ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 14:35, schrieb Falk Zscheile: Am 5. Februar 2011 14:26 schrieb Steffen Heinzeifelhu...@gmx.de: Am 05.02.2011 13:21, schrieb RalfGesellensetter: Ich habe solche Gebilde hier in der nahen Umgebung mal als Hecke getaggt (gibts denn so was wie BAumreihen?) Für Baumreihen (unabhängig davon ob sie Alleen bilden): http://wiki.openstreetmap.org/wiki/Proposed_features/Tree_rows http://wiki.openstreetmap.org/wiki/DE:Tag:natural%3Dtree hier siehts eher so aus http://de.wikipedia.org/wiki/Datei:Rotbuchenhecke_in_der_Eifel.jpg das sind allerdings noch junge Bäume ;) gibts auch in richtig groß mit mehr oder wenig gut erhalten Gesträuch dazwischen. auch die werden regelmäßig umgelegt... alle 50 bis 100 Jahre ;) Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
Am 05.02.2011 14:30, schrieb NopMap: Hat jemand auf der Liste veilleicht eine C# Entwicklungsumgebung herumliegen und Lust das Tool in Ordnung zu bringen? Für eine Schnellreparatur geht es nur darum, eine einzige Konstante zu ändern und neu zu compilieren. Wenn sich kein anderer meldet, kann ich mich gerne daran versuchen, ist aber schon was her, dass ich mit C# was zu tun hatte. Viele Grüße, Florian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] TMC-Reform (war Re: Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?))
Hallo, Am Samstag 05 Februar 2011 10:28:24 schrieb Ulf Lamping: [ ] (CID) is replaced by the country-id (e.f. 58 for Germany) legt nahe, daß hier schlicht ein Tippfehler ist und es besser: (CID) is replaced by the country-id (e.g. 58 for Germany) heissen sollte (hab's korrigiert). Aus diesem Satz kann man schon gut herauslesen, daß CID dann wohl eine Abkürzung für country-id sein dürfte und 58 dabei der Wert ist, der Deutschland repräsentiert. Die Beschreibung ist allerdings aus anderen Gründen unzureichend. Ich kann herauslesen wie die Tags zustandekommen. Damit kann ich aber weder meine eigene TMC Software schreiben (die Abbildung der TMC Empfangsdaten auf die Tags bleibt unklar) - was allerdings auch nicht unbedingt hier stehen muß. Auch ist es keine gute Anleitung wie ein Mapper mit diesen Tags umzugehen hat. Das Problem haben wir aber auch bei vielen anderen Tag Beschreibungen. [ ] Man könnte sicher hier und da Sachen vereinfachen, aber so krass wie du es darstellst ist es nun auch nicht ... Gruß, ULFL P.S: Das die Beschreibung etwas kryptisch ist, liegt sicher auch daran, das bislang kaum einer danach gefragt hat. Ich kann mich zumindest nicht dran erinnern, daß hier vorher schonmal solche Fragen wie deine gefragt wurden. nachdem dieser Thread aus dem ursprünglichen destruktiven Ansatz in ein sachlicheres Fahrwasser gelangt ist, könnte man sich vielleicht überlegen, wie man die tags so gestaltet, dass sie von Nicht-Insidern wie mir auch erahnt und vor allem einigermaßen sicher gehandhabt werden. Das Problem sehe ich weniger im Löschen oder Nicht-Verstehen der tags. Wenn da tmc-Kram drin steht, lass ich die Node am Way dran, lösche, falls erforderlich, eine andere und schiebe diese dann so, dass es geometrisch passt. Mit Ampel- oder anderen tags beißt es sich auch nicht, das ist nicht die eigentliche Baustelle. Ein Problem bekommt der Normalmapper, wenn eine Straße, wie selbst in den Großstädten noch häufig, nicht korrekt gemappt wurde. Problematisch ist häufig die Zuordnung baulich getrennt - nicht baulich getrennt. Wenn das falsch gemappt wurde, ist das verwirrend für den Benutzer, der die Karte mit der Realität vergleicht. Hier beginnt jetzt die Schwelle für den Mapper. Was soll er mit den ganzen Sch-tags und -relationen machen, die tmc, Bus und weiß-der-Henker-was betreffen? Ich habe mal in HH eine ziemlich zentrale Hauptstraße trennen müssen. Man muss da schon etwas Mut zur Lücke haben und ansonsten einfach raten und sich ein paar Stellen ansehen, wo die Fahrbahnen entsprechend getrennt sind. Hier sollten wir ansetzen, nach dem Motto: Wenn etwas funktionieren soll, frage jemanden, der sich damit auskennt, aber wenn du etwas erklärt haben willst, frage jemanden, der sich damit nicht auskennt. Ein Experte kann meistens nicht beschreiben, was ihm selbst klar ist. Ich bin dafür, 1. die tags so weit wie möglich in eine verständlichere Schreibweise umzusetzen. Das kann durch ein Script geschehen, wenn man sich auf eine Schreibweise verständigt hat. Dabei geht die schon erbrachte Arbeit nicht verloren. 2. im Wiki ein Kochrezept zu hinterlegen, mit dessen Hilfe der Mapper die häufigsten Vorgänge wie Punkt verschieben, Fahrbahnen trennen, Fahrbahnen zusammenfassen, Abbiegespur abtrennen etc. einfach bearbeiten kann. 3. für die Editoren ein plugin anzubieten, dass die Standardaufgaben dem Mapper abnimmt. 4. das ganze nicht nur für tmc, sondern auch für Bus-Relationen und andere nicht selbsterklärende Objekte. Bespiel: TMC:cid_58:tabcd_1:Class=Point TMC = Namensraum, sinnvoll cid_58 haben wir jetzt gelernt, ist Deutschland. Besser wäre möglicherweise TMC:country=58;(germany) tabcd_1 sagt mir gar nichts, ich habe auch nicht nachgesehen, will ich auch nicht, ich will mappen. Wie wäre es mit TMC:whatever=1;(verständliches Stichwort)? Class sagt mir, dass hier irgendetwas klassifiziert wird, vermutlich, dass es sich um einen Einzelpunkt handelt. Also: TMC:Class=Point Damit würde aus dem obigen TMC:cid_58:tabcd_1:Class=Point ein TMC:country=58;(germany) TMC:TableCommand=1;(very important) /* frei geraten */ TMC:Class=Point;(single waypoint) /* auch frei geraten */ Das hat natürlich den Nachteil, dass aus einem tag 3 werden. Möglicherweise kann man aber davon auch etwas weglassen, weil es sich von selbst ergibt, wie z.b. germany. Weiter: TMC:cid_58:tabcd_1:Direction=positive Das tag hat der tmc-Punkt auf der Gegenfahrbahn genauso. Warum auch immer. Hier reicht TMC:Direction=positive(short keyword, why) Weiter: TMC:cid_58:tabcd_1:LCLversion=8 TMC:Version=8 /* verständlich, wenn jetzt aus dem LCLversion ein GPLversion=8 werden sollte, kann man immer noch Gversion taggen ;-) */ Weiter: TMC:cid_58:tabcd_1:LocationCode=35565 TMC:LocationCode=35565;(coded position in tmc-Stream) Weiter: TMC:cid_58:tabcd_1:NextLocationCode=46004 TMC:NextLocationCode=46004 Damit heißt es: TMC:country=58;(germany)
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Hallo, Am Samstag 05 Februar 2011 14:02:32 schrieb Ulf Lamping: Am 05.02.2011 13:32, schrieb Wolfgang: Hallo, So was wie eine maritime Allee. Baumgruppe, Hecke, Knick und scrub passen nicht so recht. Wenn im Wiki noch nichts drin ist, denk dir ein Tag aus. Uferbebaumung? Uferbewaldung? Uferwald? Uferbaumreihe? Was soll denn mit dieser Unterscheidung erreicht werden? Das die Baumreihe am Wasser steht ergibt sich aus der Geometrie und ist kein direktes Feature dieser Baumreihe. Oder schreiben wir demnächst: Alleebaumreihe? Feldwegbaumreihe? Parkanlagenwegbaumreihe? NebenDemHospitalZurVerschönerungDerLandschaftBaumReihe? ... und sich dann am besten zwei Monate später beschweren, das sowas kein Renderer auswertet ... ;-) Was ist genau das Problem mit landuse=forest? :-) Du hast ja nicht völlig unrecht. Aber bei einer Wasserwegebaumreihe handelt es sich in der Regel um andere Pflanzen, häufig z.B. Weiden etc. Das hat schon ein typisches anderes Aussehen als eine Alle/Feldweg/Parkanlage/ NebenDemHospitalZurVerschönerungDerLandschaft-Baumreihe. Zu deiner Bemerkung mit den Renderern habe ich mal irgendwas gehört, was war das doch noch gleich? :-) Unter forest oder wood stellt man sich eine Fläche, nicht eine Reihe vor. Der Täter ist in den Wald gelaufen - Die suchen ewig, wenn der zwischen den Uferbäumen hockt. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
NopMap schrieb: Hat jemand auf der Liste veilleicht eine C# Entwicklungsumgebung herumliegen und Lust das Tool in Ordnung zu bringen? Für eine Schnellreparatur geht es nur darum, eine einzige Konstante zu ändern und neu zu compilieren. Das sollte ja kein Problem sein. Wo liegt denn der Sourcecode? Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Hallo, Am Samstag 05 Februar 2011 14:39:01 schrieb malenki: Wolfgang schrieb: So was wie eine maritime Allee. Baumgruppe, Hecke, Knick und scrub passen nicht so recht. Wenn im Wiki noch nichts drin ist, denk dir ein Tag aus. Uferbebaumung? Uferbewaldung? Uferwald? Uferbaumreihe? natural=tree wäre vermutlich zu einfach? nicht zu einfach, aber zu häufig. natural=waterside_trees ? bank_trees könnten u.U. vor der Sparkasse gemappt werden ;-) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
Am 05.02.2011 15:14, schrieb Michael Bemmerl: NopMap schrieb: Hat jemand auf der Liste veilleicht eine C# Entwicklungsumgebung herumliegen und Lust das Tool in Ordnung zu bringen? Für eine Schnellreparatur geht es nur darum, eine einzige Konstante zu ändern und neu zu compilieren. Das sollte ja kein Problem sein. Wo liegt denn der Sourcecode? Grüße, Michi//lists.openstreetmap.org/listinfo/talk-de Alle Infos dazu findest du auf der Dev-Wikiseite http://wiki.openstreetmap.org/wiki/Srtm2Osm_Development Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 14:35, schrieb Falk Zscheile: Wobei es wohl noch keinen klaren ausschlag zu einem der beiden Varianten gibt: natural=tree_row landuse=treerow so, ich hab mal, ebenso wie bei wikipedia, eine Weiterleitung erstellt! Wer nun Baumreihe eingibt landet an der richtigen Stelle. Ich wundere mich das so was nicht öfters gemacht wird. oder spricht was dagegen? Klar, bei Allee geht das nicht so einfach, da mehrsprachig Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
On 02/05/2011 02:30 PM, NopMap wrote: Für eine Schnellreparatur geht es nur darum, eine einzige Konstante zu ändern und neu zu compilieren. Auf welchen Wert soll die Konstante geändert werden ? Grüße ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 15:12, schrieb Wolfgang: :-) Du hast ja nicht völlig unrecht. Aber bei einer Wasserwegebaumreihe handelt es sich in der Regel um andere Pflanzen, häufig z.B. Weiden etc. Das hat schon ein typisches anderes Aussehen als eine Alle/Feldweg/Parkanlage/ NebenDemHospitalZurVerschönerungDerLandschaft-Baumreihe. Das würde ich mal bezweifeln :-) Da wird eher andersrum ein Schuh draus: Wenn ich irgendwo in der Pampa eine gerade Baumreihe sehe, ist da recht häufig auch ein Gewässer dran - aber vielleicht auch nur ein Weg. Zu deiner Bemerkung mit den Renderern habe ich mal irgendwas gehört, was war das doch noch gleich? :-) Na ja, wir taggen aber hoffentlich auch nicht gegen die Renderer. Wenn wir landuse=forest von sowas wegnehmen und natural=Wasserwegebaumreihe dranschreiben, hat der Renderer bei den ganzen möglichen Tags (ich hatte ja aufgezählt, was man alles so machen könnte) keine Chance mehr auf eine vernünftige Darstellung. Zur genaueren Beschreibung gibt es ja auch die Möglichkeit ganz genau die Baumart und andere Spezial-Eigenschaften anzugeben. Das aber *zusätzlich* zum allgemeinen Tag. Unter forest oder wood stellt man sich eine Fläche, nicht eine Reihe vor. Ich stelle mir da einfach einen Satz Bäume drunter vor - und weiß das dieser Satz im OSM Universum wahrscheinlich irgendwas zwischen 2 und 1 Millionen Bäumen sein wird ;-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 5. Februar 2011 14:46 schrieb Steffen Heinz eifelhu...@gmx.de: Am 05.02.2011 14:35, schrieb Falk Zscheile: Für Baumreihen (unabhängig davon ob sie Alleen bilden): http://wiki.openstreetmap.org/wiki/Proposed_features/Tree_rows http://wiki.openstreetmap.org/wiki/DE:Tag:natural%3Dtree hier siehts eher so aus http://de.wikipedia.org/wiki/Datei:Rotbuchenhecke_in_der_Eifel.jpg das sind allerdings noch junge Bäume ;) Für mich ist das ganz klar eine Hecke mit Baumreihe. Ich würde es in die Datenbank als landuse=tree_row und barrier=hedge eintragen. Beide Tags vertragen sich (zufällig) auch an einem way. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Hallo, meiner Meinung nach ist das ganze landuse und natural sowieso komplett verwässert. landuse=forest wird allzuoft einfach mit da stehen Bäume gleich gesetzt. Das das ganze genutzt wird, kann man dem ohnehin nicht mehr entnehmen. Wäre es nicht sinnvoll, wie allgemein üblich, einen Tag zu haben, der nur angibt, hier stehen Bäume. Also die Definition von landuse=forest zu ändern. Alles andere sollte dann in Subtags erfasst werden. Bspw. die dominierende Art des Baumes oder welche Art von Gruppierung oder wie genutzt. Ob der Wald nun an einem Weg liegt, in der Nähe der Sparkasse ist oder eben an einem Bach steht, ergibt sich aber aus den Objekten, die in der Nähe angeordnet sind. Das muss man nicht an dem Wald extra erfassen. Henning ___ 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, ich sehe das Problem eher darin begründet, dass unsere Editoren nicht besonders gut für den Einsatz mehrerer Tags optimiert sind. Man müsste bei diesen Namensraumkonstruktionen mit dem Doppelpunkt dazu übergehen, mehrere Tags gleichen Namensraumes in der Software zusammenzuziehen und aufklappbar zu machen. Wenn es zu viele Tags werden kann es doch nicht ernsthaft die Lösung sein zu sagen, wir erlauben diese nicht mehr oder nur noch unter bestimmten Bedingungen. Das ist doch Käse! Als weiteren Schritt sollten wir uns überlegen eine Möglichkeit zu schaffen, bestimmte Tags komplett ausblenden zu lassen. Wer sagt denn, dass TMC-Tags überhaupt angezeigt werden müssen? Es muss ein Schalter im Optionsdialog her, mit dem man komplette Namensräume direkt wegblenden kann. Tags wie TMC dürfen auch gerne von Hause aus ausgeblendet sein, da nur die Wenigsten an diesen Tags Änderungen vornehmen werden und dann eine manuelle Aktivierung einfacher ist. Sollte ein Objekt mit versteckten Tags verändert oder gelöscht werden müsste der User über eine Warnmeldung darauf hingewiesen werden. Das ist aber, denke ich, obligatorisch. Im Übrigen sollten im selben Zuge auch direkt ein System implementieren, mit denen man als historic getaggte Objekte direkt ausblenden kann, sodass diese den Mapper nicht mehr stören. Im nächsten Schritt muss es dann auch möglich sein ganze Taggruppen auszublenden, da es im innerstädtischen Bereich mitunter schon recht unübersichtlich wird. Jedenfalls ist das Löschen der TMC-Tags für mich *keine* Lösung, zumal diese, wie ja hier mehrfach gut begründet wurde, eine außerordentliche Relevanz haben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 5. Februar 2011 14:28 schrieb Florian Heer florianheerf...@yahoo.de: Am 05.02.2011 14:18, schrieb M∡rtin Koppenhoefer: Und was genau ist die Fläches des Waldes? Der von Ästen überschattete Bereich? Die äußerste Grenze der Stämme? das ist fast dasselbe bei echten Wäldern, IMHO der überschattete Bereich. Bei echtem Wald gibt es ja immer auch Waldrand, die Grenzen sind da fließend, der Randbereich wäre bei echtem Wald theoretisch auch nochmal zu unterscheiden zu tief drinnen. Diese Frage ist übrigens ein weltweites Problem, was ist ein Wald? Dieses Problem treibt z.B. auch die großen in dem Bereich um, nur als ein paar Beispiele: FAO, UN, WWF, die Landwirtschaftsministerien aller Länder... Ist ein loser Verbund vieler Bäume auf einer kleinen Fläche schon ein Wald? nein, das ist relativ unumstritten. Auch sprachlich wird das unterschieden, z.B. woodland gegenüber forest. Benötigt ein Wald eine bestimme Dichte, oder ist das abhängig von den Spezies, die dort wachsen? beides. Je nach Spezies unterscheidet sich auch die Dichte. Ist es ein Wald, wenn alle Bäume in Reih und Glied stehen? tendenziell ja, ursprünglich sicher nicht. (Holzplantage). Ist dichtes Unterholz ein Indiz für oder gegen einen Wald? es hat damit wenig zu tun, sondern mit der Intensität der Unterhaltung, dem Klima und der Spezies. Ist die Fauna ausschlaggebend? könnte man so sehen. Mit anderen Worten: es gibt keine allgemein anerkannte Definition von Wald, und ich glaube auch nicht, dass die hier erschaffbar ist. wir könnten versuchen, die Parameter genau genug zu erfassen, um jedem mit seiner eigenen Definition zu ermöglichen festzulegen, ob er eine bestimmte Fläche als Wald rechnen will oder nicht. landuse=forest wird dafür sicher nicht ausreichen (oder es gäbe eine Revolution und massives Umtaggen, da bin ich aber z.B. nicht dafür, lieber differenzieren). Ein natural=* tag is IMHO übrigens immer noch (fast) überall falsch. In Europa z.B. gibt es (fast) keine natürlichen Wälder mehr. je nachdem, ich hatte ja dazugeschrieben, dass ich natural als geografisches Feature sehe (also abstrakt), nicht als alles, was irgendwie natürlich ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
Michael Bemmerl wrote: Jedenfalls habe ich die Konstante von 1 Milliarde auf 2 Milliarden hochgesetzt. Da im Programm 32-Bit signed Integer eingesetzt werden, ist also noch Platz für 147.483.648 Nodes. Ich hoffe das reicht für's erste? Sollte es. Vielen Dank! Das Tool ist alt und vom Autor aufgegeben, aber eine vollwertige Alternative scheint es immer noch nicht zu geben. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/C-Entwickler-fur-kleine-Reparatur-gesucht-tp5995433p5995912.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] C# Entwickler für kleine Reparatur gesucht
Am 05.02.2011 18:24, schrieb NopMap: Michael Bemmerl wrote: Jedenfalls habe ich die Konstante von 1 Milliarde auf 2 Milliarden hochgesetzt. Da im Programm 32-Bit signed Integer eingesetzt werden, ist also noch Platz für 147.483.648 Nodes. Ich hoffe das reicht für's erste? Sollte es. Vielen Dank! Das Tool ist alt und vom Autor aufgegeben, aber eine vollwertige Alternative scheint es immer noch nicht zu geben. bye Nop Es gibt da noch Phyghtmap (http://wiki.openstreetmap.org/wiki/Phyghtmap). Ich habs noch nicht getestet, weil mir die Installation zu kompliziert ist. Ob das aber noch gepflegt wird. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 16:17, schrieb Falk Zscheile: hier siehts eher so aus http://de.wikipedia.org/wiki/Datei:Rotbuchenhecke_in_der_Eifel.jpg das sind allerdings noch junge Bäume ;) Für mich ist das ganz klar eine Hecke mit Baumreihe. mag sein! hier ist das aber typisch für eine Hecke http://de.wikipedia.org/wiki/Monschauer_Heckenland#Flurhecken Ich würde es in die Datenbank als landuse=tree_row und barrier=hedge eintragen. Beide Tags vertragen sich (zufällig) auch an einem way. auf jeden Fall wäre das angebraucht wo die Pflege vernachläßigt wurde und sich zu einer Baumreihe entwickelt haben nu mit rudimentärer Hecke dazwischen. Grüße aus der Eifel Steffen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 5. Februar 2011 18:32 schrieb Steffen Heinz eifelhu...@gmx.de: Am 05.02.2011 16:17, schrieb Falk Zscheile: hier siehts eher so aus http://de.wikipedia.org/wiki/Datei:Rotbuchenhecke_in_der_Eifel.jpg das sind allerdings noch junge Bäume ;) Für mich ist das ganz klar eine Hecke mit Baumreihe. mag sein! hier ist das aber typisch für eine Hecke http://de.wikipedia.org/wiki/Monschauer_Heckenland#Flurhecken Man muss ja nicht am am Wortlaut stehen bleiben. Was man sieht ist eine Hecke + Baumreihe und das (was man sieht) wollen wir bei OSM erfassen. Dass es Rotbuchenhecken sind kann über ein weiteres Tag: species=fagus sylvatica Wenn Du mit meinem Vorschlag Bauchschmerzen hast, dann bleibt Dir nichts anderes übrig, als Dir etwas eigenes auszudenken, wie z.B. landuse=monschauer_hecke. Die Definition hierfür wäre dann Hecke mit dazwischen hochgewachsenen Bäumen. Ich würde eine solche Lösung aber nicht gut finden. Ich bin ein Verfechter möglichst wenige Dinge und damit Definitionen in einem Tag zu verschmelzen. Ein Kompromiss aus beiden Lösungsansätzen wäre die Kombination aus hedge und tree_row um ein weiteres Tag zu ergänzen aus denen sich ergibt, dass hier eine Kombination vorliegt, z.B. lanschaftselement=Monschauer Heckenland Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweise der Europastraßen
Moin, On Fri, 4 Feb 2011, Andreas Perstinger wrote: nicht das Wikipedia immer recht hat ... das wird von Nation zu Nation ein bißchen anders gehandhabt Auch bei Wikipedia gibt es Unterschiede auf den verschiedenen Sprachseiten. = und wie ist das im allgemeinen bei uns ?? na, den Link auf die Richtlinie (o. ä.) hast du ja jetzt schon bekommen. Wenn ich unterwegs bin, führe ich keine Statistiken - aber ich würde sagen, in Deutschland überwiegend mit schmalem Zwischenraum (ist möglicherweise subjektiv eingetrübt, wie geschrieben ;-). Und da ein schmaler Zwischenraum doch zu umständlich ist, macht man halt einen normalen (denn gar kein Zwischenraum ist dann auf jeden Fall anders und somit falsch). Gruß, Schusch___ 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, André Reichelt wrote: ich sehe das Problem eher darin begründet, dass unsere Editoren nicht besonders gut für den Einsatz mehrerer Tags optimiert sind. Man müsste bei diesen Namensraumkonstruktionen mit dem Doppelpunkt dazu übergehen, mehrere Tags gleichen Namensraumes in der Software zusammenzuziehen und aufklappbar zu machen. Wenn es zu viele Tags werden kann es doch nicht ernsthaft die Lösung sein zu sagen, wir erlauben diese nicht mehr oder nur noch unter bestimmten Bedingungen. Das ist doch Käse! Diese Loesung geht, im konkreten Fall TMC, am Problem vorbei. Das Problem ist doch, dass da - egal wie viel ein Editor was zuklappt - irgendwelche semantisch schwer verstaendlichen Zusatzinformationen an einem Node haengen. Wieso hat diese Ampel hier Zusatztags, und die Ampel an der naechsten Kreuzung hat keine? Was tue ich, wenn diese Ampel hier abgebaut wird? Wir sind eines der am vollstaendigsten erfassten Laender bei OSM. Bei uns beginnt jetzt schon die Entwicklung weg vom Neuerfassen hin zum Erhalten, Pflegen, Aktualisieren. Einige der Pioniere, die noch auf weisser Flaeche mit GPS unterwegs waren, orientieren sich um; andere suchen sich in fernen Gefilden andere Betaetigungsfelder. Wir sind darauf angewiesen, dass staendig Newbies zu OSM stossen und unsere Daten aktuell halten. Unsere Daten duerfen sich nicht in eine staendig komplexere Richtung entwickeln, so dass sie nur noch von Experten gepflegt werden koennen. Als weiteren Schritt sollten wir uns überlegen eine Möglichkeit zu schaffen, bestimmte Tags komplett ausblenden zu lassen. [...] Sollte ein Objekt mit versteckten Tags verändert oder gelöscht werden müsste der User über eine Warnmeldung darauf hingewiesen werden. Das ist aber, denke ich, obligatorisch. Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade machen willst, kann Folgen haben, die Du nicht verstehst und die wir hier leider auch nicht erklaeren kann... - das ist *genau* der Kern des Problems. Ich will, dass jeder Newbie herkommen und eine Strassengeometrie verfeinern kann, eine Ampel loeschen oder eine Umgehungsstrasse eintragen, ohne dass er erst die Wikiseite zu TMC lesen muss (und 10 andere Wikiseiten zu anderen Spezialnamensraeumen auch). Deswegen ist mein Mantra: Jeder kann seinen Spezialkram mit OSM aufbauen (und fuer mich ist TMC Spezialkram), aber das darf nicht zu Lasten der Komplexitaet gehen. Man darf dadurch, dass man OSM fuer Spezialanwendungen nutzt, nicht Mauern aufbauen, die es Neulingen erschweren, an OSM teilzunehmen. Und Tags, die entweder ganz offen (ueber eine Editorwarnung) oder unterschwellig (durch ihre Komplexitaet gepaart mit unlesbaren Wikiseiten) suggerieren: Finger weg! (oder sollte ich sagen: pfoten_weg?), die sind meines Erachtens fuer OSM schaedlich. Es mag sein, dass es manchmal einfach nicht anders geht, und dann kann man mal einen Kompromiss machen, aber es sollte wenigstens klar sein, *dass* solche Tags schaedlich sind und dass man, wenn es irgend geht, an ihrer Vermeidung arbeiten sollte statt an ihrer Vermehrung. Im Übrigen sollten im selben Zuge auch direkt ein System implementieren, mit denen man als historic getaggte Objekte direkt ausblenden kann, sodass diese den Mapper nicht mehr stören. Im nächsten Schritt muss es dann auch möglich sein ganze Taggruppen auszublenden, da es im innerstädtischen Bereich mitunter schon recht unübersichtlich wird. JOSM kann bereits ganze Objekte anhand ihrer Tags ausblenden, jedoch nicht einzelne Tags eines Objekts. 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] Koennen wir die TMC-Daten rauswerfen?
Am 5. Februar 2011 19:32 schrieb Frederik Ramm frede...@remote.org: Diese Loesung geht, im konkreten Fall TMC, am Problem vorbei. dem stimme ich natürlich auch zu Unsere Daten duerfen sich nicht in eine staendig komplexere Richtung entwickeln, so dass sie nur noch von Experten gepflegt werden koennen Ich will, dass jeder Newbie herkommen und eine Strassengeometrie verfeinern kann, eine Ampel loeschen oder eine Umgehungsstrasse eintragen, ohne dass er erst die Wikiseite zu TMC lesen muss (und 10 andere Wikiseiten zu anderen Spezialnamensraeumen auch). m.E. ist es leider unausweichlich. dass das Taggingschema immer komplexer wird. TMC scheint im Vergleich zum ÖPNV noch simpel (mal davon abgesehen, dass es da auch noch verschiedene konkurrierende Möglichkeiten gibt, die Daten abzubilden). Durch das Bedürfnis der Mapper, immer mehr verschiedene Dinge einzutragen, und immer (m.E. auch sinnvolle) mehr Differenzierungen festzuhalten, gibt es halt auch immer mehr unterschiedliche Tags. Wenn unser Ziel ist, die Welt abzubilden, dann liegt es auf der Hand, dass das nicht so einfach sein kann wie eine Sammlung untereinander weitgehend unabhängiger Artikel (WP). Im Prinzip sind wir daher jetzt schon an einem Punkt angekommen, wo einfach mal Loseditieren nicht geht, ohne sich ein bisschen mit der Materie zu beschäftigen (und ich behaupte mal ketzerisch, das war schon immer so, die Tools sind ja auch deutlich benutzerfreundlicher geworden). Deswegen ist mein Mantra: Jeder kann seinen Spezialkram mit OSM aufbauen (und fuer mich ist TMC Spezialkram), aber das darf nicht zu Lasten der Komplexitaet gehen. Man darf dadurch, dass man OSM fuer Spezialanwendungen nutzt, nicht Mauern aufbauen, die es Neulingen erschweren, an OSM teilzunehmen. die Komplexität entsteht ja alleine schon durch die reine Masse an unterschiedlichen Dingen, die alle irgendwie miteinander in Zusammenhang stehen. Und Tags, die entweder ganz offen (ueber eine Editorwarnung) oder unterschwellig (durch ihre Komplexitaet gepaart mit unlesbaren Wikiseiten) suggerieren: Finger weg! (oder sollte ich sagen: pfoten_weg?), die sind meines Erachtens fuer OSM schaedlich. gut, der Hinweis auf das Wiki. Je besser unsere Dokumentation ist, um so eher bleibt das System auch beherrschbar und zugänglich. Das alles mehr oder weniger allgemein, TMC ist sicher ein Beispiel dafür, dass man es auch ein bisschen weniger programmiereraffin hätte gestalten können. M.E. wird die Entwicklung dahin gehen, dass es einerseits Editoren wie JOSM gibt, die einem alle Möglichkeiten bieten, an den Daten herumzumanipulieren, die aber auch Einarbeitung sowohl in die Software als auch in das Taggingsystem erfordern, und andere Editoren, die einen z.B. keine Ways kombinieren lassen, wohl aber ne einfache Möglichkeit bieten, mal einen Straßennamen einzutragen oder eine Einbahnstraße umzudrehen, bzw. die für einen speziellen Nutzerkreis (s.z.B. Openseamap) anhand deren Bedürfnisse entwickelt wurden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
sicher, dass es daran liegt? Ich habe vor ein paar Monaten auch schon mal Probleme mit srtm2osm gehabt, das Problem war dann allerdings banal: das Tool schreibt api0.5 in den header, wenn man aus der 0.5 eine 0.6 macht werden die Konturen anstandslos mit osm2pgsql importiert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweise der Europastraßen
Am 5. Februar 2011 19:29 schrieb Schorschi scho...@snafu.de: ... sagen, in Deutschland überwiegend mit schmalem Zwischenraum (ist möglicherweise subjektiv eingetrübt, wie geschrieben ;-). Und da ein schmaler Zwischenraum doch zu umständlich ist, macht man halt einen normalen (denn gar kein Zwischenraum ist dann auf jeden Fall anders und somit falsch). wenn richtig auf der Hälfte liegt, ist ein voller Space genauso falsch. M.E. ist kürzer besser, die Schilder verdecken nur die Karte. Andererseits ist das ein Thema, dass man bei hohen Ansprüchen wohl sowieso durch Postprocessing angehen wird, von daher ist es eigentlich egal. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
Am 05.02.2011 20:27, schrieb M∡rtin Koppenhoefer: sicher, dass es daran liegt? Ich habe vor ein paar Monaten auch schon mal Probleme mit srtm2osm gehabt, das Problem war dann allerdings banal: das Tool schreibt api0.5 in den header, wenn man aus der 0.5 eine 0.6 macht werden die Konturen anstandslos mit osm2pgsql importiert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ja, das ist ein Problem, wenn man wie Nops Composer die generierten Höhendaten mit den osm-Daten zusammenführen möchte. Dann gibt es Komplikationen, wenn die IDs nicht mehr eindeutig sind. Keine Ahnung, was osmosis dann macht. Wie groß wäre denn der Aufwand das auf int64 umzustellen? Muss da dann was am Algorithmus geändert werden, oder reicht es aus, den Datentyp der Variablen zu ändern? Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweise der Europastraßen
Moin, On Sat, 5 Feb 2011, M∡rtin Koppenhoefer wrote: Am 5. Februar 2011 19:29 schrieb Schorschi scho...@snafu.de: ... sagen, in Deutschland überwiegend mit schmalem Zwischenraum (ist möglicherweise subjektiv eingetrübt, wie geschrieben ;-). Und da ein schmaler Zwischenraum doch zu umständlich ist, macht man halt einen normalen (denn gar kein Zwischenraum ist dann auf jeden Fall anders und somit falsch). wenn richtig auf der Hälfte liegt, ist ein voller Space genauso falsch. nein, dieser Schluss ist falsch - denn es geht hier nicht um Geometrie, sondern um Lesbarkeit (durch Menschen, nicht durch Maschinen). Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Liebe Deutsche
Liebe Deutsche, Wir mögen es, wenn ihr bei uns in den Urlaub fahrt, und wir mögen es auch, wenn ihr in unserem Land als Mapper aktiv seid. Wir kommen nämlich auch zu euch und mappen dort ;). Unser aktivster Mapper steht sogar bei euch in der Top-5! Wir korrigieren auch gerne eure Fehler, die ihr beim mappen macht. Seit 1578 sind wir allerdings von Deutschland (eher Deutschland) unabhängig und hat sich unsere Sprache von eurer getrennt. Dementsprechend kann es vorkommen, dass ihr andere Namen für bestimmte Orte habt als wir. Es sollte allerdings nicht vorkommen, dass der deutsche Name als value des keys *name*eingetragen wird. Wir mögen das nicht. Tobt euch stattdessen bei *name:de* aus. (Und sonst taufen wir auch einfach ein Paar Orte um :P) Viele Grüße von 0.4m ü NN, Martien Scheepens ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 18:55, schrieb Falk Zscheile: Wenn Du mit meinem Vorschlag Bauchschmerzen hast, dann bleibt Dir nichts anderes übrig, als Dir etwas eigenes auszudenken, wie z.B. landuse=monschauer_hecke. Die Definition hierfür wäre dann Hecke mit dazwischen hochgewachsenen Bäumen. Ich würde eine solche Lösung aber nicht gut finden. Ich bin ein Verfechter möglichst wenige Dinge und damit Definitionen in einem Tag zu verschmelzen. Was ist denn für OSM ein Hecke? im normalen Sprachgebaut fängt die bei wenigen cm an und hört bei haushoch auf. mal sind es aufgereihte gleiche Pflanzen die auch ab und an beschnitten werden,, mal ist alles mögliche was in einer Reihe steht und Felder schützt (Knicks), auch ja, dann gibt es noch *Benjeshecken... so ist halt die Flurhecke auch ein Typ kennzeichen der Hecken sind halt linienförmig, dicht stehend, schließlich auch absperrend. durchgehen ist nicht einfach im Gegensatz zu Baumreihen oder Alleen Grüße aus der Eifel Steffen * ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
On Sat, Feb 05, 2011 at 03:47:56PM +0100, Michael Bemmerl wrote: Jedenfalls habe ich die Konstante von 1 Milliarde auf 2 Milliarden hochgesetzt. Da im Programm 32-Bit signed Integer eingesetzt werden, ist also noch Platz für 147.483.648 Nodes. Ich hoffe das reicht für's erste? Langfristig sollte man das Programm aber auf unsigned Integer umschreiben, solang man keine negativen Integer braucht. Falls doch, gäbe es noch die 64-Bit Integer. Wenn das noch mal angefaßt werden würde: Kann mal jemand prüfen, ob das auch mit Mono gebaut werden kann. Es soll Leute geben, die gar keinen Zugriff auf einen Windows-Rechner haben... 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] cycleway=track vs. cycleway=opposite_track
Am 5. Februar 2011 08:43 schrieb Felix Hartmann extremecar...@gmail.com: beispielsweise, indem man das cycleway=track an den Fahrradweg selbst hängt (zusätzlich). Ist das tatsaechlich so gedacht? Steht das irgendwo? Nein und auch aus gutem Grund. Weil dann fehlen weiterhin die ganzen Attribute der Straße. der tag war nur ein Beispiel, man kann das auch anders machen. Wenn wir also schon seperat die Wege einzeichnen (ist mir ein Graus), entspricht jedenfalls unserer Grundkonvention: getrennte Fahrbahn=eigener Weg dann gehören auch ALLE Attribute mit einem speziellen Schlüssel auf den Fahrradweg nebenan, sonst kann man nicht entscheiden was er taugt. hier sehe ich eher denjenigen gefragt, der das auswertet. Ob ein Fahrradweg neben einer Straße liegt sollte man über die Nähe erkennen können, explizit wäre es auch über eine Relation denkbar (das hätte noch mehr Vorteile: wer diese Wege dann z.B. lieber nicht im Rendering hat, kann sie rausmachen, ggf. auch zoomabhängig). Alle tags einer benachbarten Straße zusätzlich an den Fahrradweg zu hängen, halte ich dagegen quasi für Spam. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
Am 5. Februar 2011 21:43 schrieb Andreas Tille andr...@an3as.eu: On Sat, Feb 05, 2011 at 03:47:56PM +0100, Michael Bemmerl wrote: Wenn das noch mal angefaßt werden würde: Kann mal jemand prüfen, ob das auch mit Mono gebaut werden kann. Es soll Leute geben, die gar keinen Zugriff auf einen Windows-Rechner haben... das funktioniert bereits mit Mono, hatte das nicht auf einem Windowsrechner eingesetzt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weinlagen
Und nehme ich den Ortsnamen in die Lagebezeichnung auf? Schwarzlay und der Rest ergibt sich aus Grenzpolygonen oder Ürziger Schwarzlay? -- 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] Koennen wir die TMC-Daten rauswerfen?
Am Samstag, den 05.02.2011, 19:32 +0100 schrieb Frederik Ramm: Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade machen willst, kann Folgen haben, die Du nicht verstehst und die wir hier leider auch nicht erklaeren kann... - das ist *genau* der Kern des Problems. Das wird sich aber auch nicht durch eine ID in eine externe Datenbank lösen lassen, da auch hier der User zunächst überprüfen muss, was das Tag bedeutet und wie er hier vorgehen muss. Also bringt uns auch die Geforderte ID in eine externe Datenbank keinen Schritt weiter. Außerdem haben wir bereits festgestellt, dass man von einer anderen Datenbank nicht in die OSM-Datenbank linken kann, da hier die Gefahr groß ist, dass irgendwer ein paar Nodes/Wege löscht und dadurch die externe Datenbank ständig korrigiert werden müsste. Wir stehen hier meiner Meinung nach vor einem schwerwiegenden Problem, für das wir gegenwärtig keine Lösung parat haben. Nun einfach ohne Rücksicht auf Verluste zu fordern all diese Tags wieder zu löschen wäre falsch und destruktiv. Es mag sein, dass es manchmal einfach nicht anders geht, und dann kann man mal einen Kompromiss machen, aber es sollte wenigstens klar sein, *dass* solche Tags schaedlich sind und dass man, wenn es irgend geht, an ihrer Vermeidung arbeiten sollte statt an ihrer Vermehrung. Dass solche Tags »schädlich« sind konnte bisher noch niemand mit Fakten belegen. Die einzige Aussage die hier von Dir und von Anderen glaubhaft vermittelt werden konnte ist, dass die gegenwärtige Lösung suboptimal ist. Wir stehen nun also an dem Punkt, an dem wir dazu angehalten sind eine *bessere* Lösung zu finden. Dieses Ziel werden wir nicht erreichen, indem wir hier in Wikipedia-Manier irgendwelchen relevanzkriterien- ähnlichen Mist veranstalten. Ich möchte das Problem noch einmal allgemein gefasst darstellen: Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden werden soll. Eine direkte Verbindung mit der OSM-ID des Objektes nicht nicht möglich, da es in der OSM-Datenbank keinen »Fertig«-Zustand gibt, der ein Löschen oder Verändern des Objektes dauerhaft ausschließt. Daher muss ein Weg gefunden werden unabhängig von zukünftigen Änderungen an der OSM-Datenbasis zuverlässig eine Verknüpfung von OSM-Daten mit einer externen Datenquelle zu gewährleisten. Ich behaupte, dass wir hier von einem komplexeren Problem sprechen, dass sich durch blinden Aktionismus nicht lösen lässt. Bevor jedoch keine zuverlässige und stabile, weniger »schädliche« Lösung gefunden ist kommt eine Löschung der TMC-Daten nicht in Frage, da dadurch die Datennutzbarkeit in erheblichem Umfang eingeschränkt wird. Gruß André *Anhang:* Meine Idee für einen Lösungsansatz Ein Lösungsansatz könnte es sein, nicht nur auf das Objekt in der OSM-DB selbst zu verweisen sondern zusätzlich auf den Revisionsstand. Auch hier könnte es allerdings zu konflikten mit zukünftigen Änderungen kommen. Von unserer Seite aus müsste bei diesem Ansatz also ein System geschaffen werden dass zwar die Datenbasis *möglichst* aktuell zur Verfügung stellt. Wird jedoch in der Dump-Abfrage ein Objekt mit Revision abgefragt muss die Blackbox in der Lage sein alle involvierten zukünftigen Änderungssätze zu ermitteln, dort eventuelle Konflikte feststellen und die betroffenen Daten vor der Ausgabe auf einen konsistenten Revisionsstand zurücksetzen. Als Zwischen-/Notlösung könnte man sich auch vorstellen, dass einfach nur eine Liste von Objekten und deren Revisionsstand an die Blackbox übergeben wird. Diese gibt dann für jedes Objekt zurück, ob es mittlerweile einen neuen Revisionsstand hat. Diese Lösung hat allerdings den Nachteil, dass ich als Betreiber der externen Datenquelle, die in OSM linkt zunächst meinen Datensatz überprüfen muss und im Konfliktfall meine Verknüpfungen zu korrigieren habe. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 5. Februar 2011 21:37 schrieb Steffen Heinz eifelhu...@gmx.de: Am 05.02.2011 18:55, schrieb Falk Zscheile: Was ist denn für OSM ein Hecke? im normalen Sprachgebaut fängt die bei wenigen cm an und hört bei haushoch auf. naja, Hecken sind üblicherweise nicht haushoch. Habe mir mal den Spass gemacht, im dt. Wörterbuch der Gebr. Grimm nachzuschlagen. Interessanterweise wird unter 3 (von 9 Bedeutungen) beschrieben: wie hag 4 und hagen 5 (sp. 138. 151) gewinnt auch hecke die erweiterte bedeutung gehölz, kleiner wald: haben auch solche hecken begangen. weisth. 1, 595; aus des mannes eigenem gehölz und bäumen, so in seinen eigenen hecken gewachsen sein. 605; die sonsten ander gehölze in anderer leuthe röder und hecken hinweg genommen. das.; die hecke eines einzelnen kann ein theil eines der ganzen gemeinde zustehenden waldes sein... allerdings schreiben sie auch: 1) den stechenden dornstrauch, vorzüglich die gattung rubus, brombeere und ihre verwandte: dumus 2) viel häufiger im allgemeinen sinne, niedriges, dorniges und stachliches gebüsch: spinetum 4) von dem gärtner wird eine vornehmlich durch strauchobst gebildete wand in einem garten eine hecke genannt: 5) gewöhnlicher aber heiszt hecke die einfriedigung eines gartens oder feldes durch niedriges gesträuch, ausführlicher kann man das unter http://urts55.uni-trier.de:8080/Projekte/WBB2009/DWB/wbgui_py?lemid=GA1 nachlesen. M.E. ist Hecke in OSM genau das, was es sprachlich auch bedeutet: ein lineares Element aus niedrigen, eher dichten strauchigen Pflanzen oder beschnittenen Bäumen, üblicherweise zur Abtrennung oder Sichtschutz verwendet. Gruß Martin ___ 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, André Reichelt wrote: Am Samstag, den 05.02.2011, 19:32 +0100 schrieb Frederik Ramm: Das ist ja dann der absolute UI-GAU. Lieber User, mit diesem Objekt hier ist irgendwas, was Du nicht verstehst, und das, was Du hier gerade machen willst, kann Folgen haben, die Du nicht verstehst und die wir hier leider auch nicht erklaeren kann... - das ist *genau* der Kern des Problems. Das wird sich aber auch nicht durch eine ID in eine externe Datenbank lösen lassen, da auch hier der User zunächst überprüfen muss, was das Tag bedeutet und wie er hier vorgehen muss. Also bringt uns auch die Geforderte ID in eine externe Datenbank keinen Schritt weiter. Außerdem haben wir bereits festgestellt, dass man von einer anderen Datenbank nicht in die OSM-Datenbank linken kann, da hier die Gefahr groß ist, dass irgendwer ein paar Nodes/Wege löscht und dadurch die externe Datenbank ständig korrigiert werden müsste. Wir haben vielleicht festgestellt, dass es nicht trivial ist; aber nicht, dass man es nicht kann. Es braucht halt ein bisschen Gehirnschmalz, und mir es es lieber, die externen Datenbanken werden kompliziert und OSM bleibt einfach, als umgekehrt. Denn wir haben hunderte von externen Datenbanken und nur ein OSM ;) Ideal waere, wenn es gelaenge, komplett von aussen nach OSM hinein zu linken. Das kommt ja immer wieder auf den Tisch, und die Alternativen sind immer die gleichen - entweder man macht es sich leicht und traegt die externe ID bei OSM ein, was aber auf Dauer ein Problem werden kann und anfaellig gegen Loeschungen usw. ist, oder man findet eine Art symbolischer Links - so dass in der externen Datenbank steht: ein Objekt vom Typ Way oder Node mit den Tags amenity=restaurant und Name=La Cucina im Umkreis von 500m um diesen Punkt oder so etwas. So eine Verknuepfung mit etwas Spiel ist immun gegen viele Probleme und verkompliziert OSM gar nicht - sie ist aber technisch anspruchsvoll, weil man eine XAPI-artige Link-Finde-Maschine braucht. In irgendeiner Weise wird es sowas aber geben muessen, und vielleicht koennte man das fuer TMC dann auch verwenden. (Deine Idee mit dem Linken auf Revisionsstaende hat auch Charme, aber auch wieder ihre eigenen Probleme.) Wir stehen hier meiner Meinung nach vor einem schwerwiegenden Problem, für das wir gegenwärtig keine Lösung parat haben. Nun einfach ohne Rücksicht auf Verluste zu fordern all diese Tags wieder zu löschen wäre falsch und destruktiv. Ja, nun ist ja gut. Ich habe ja auch nicht gefordert, ohne Ruecksicht auf Verluste alle diese Tags wieder zu loeschen. Mir ist erstmal allgemein wichtig, grundaetzlich das Bewusstsein dafuer zu schaerfen, dass solche Tags weder gut noch unumgaenglich sind, sondern maximal eine Notloesung, weil wir gegenwaertig nichts besseres haben. In bezug auf TMC wuensche ich mir, dass wir diese Daten mittelfristig weitgehend in ein OSM-externes System migrieren koennen, dass keinerlei regelmaessige automatische Veraenderungen von OSM fuer mehr TMC-Konformitaet stattfinden, und dass Benutzer, die sich nicht fuer TMC interessieren, nicht im Dunkeln tappen muessen. Wenn wir uns einig sind, dass es so, wie es jetzt ist, ganz bestimmt nicht richtungsweisend ist, dann ist das schonmal ein guter Anfang. Dass solche Tags »schädlich« sind konnte bisher noch niemand mit Fakten belegen. Die einzige Aussage die hier von Dir und von Anderen glaubhaft vermittelt werden konnte ist, dass die gegenwärtige Lösung suboptimal ist. Ein einziger User, der sich wegen TMC-Tags nicht traut, ein Objekt zu bearbeiten - und da gab es mindestens einen hier im Thread - reicht in meinen Augen schon zum Schadensbeweis. Denk dran, dass sich hier in der Liste nur die Top 1% herumtreiben, und frage Dich, wie viele andere erschrocken ihre Finger von einer Verbesserung gelassen haben. Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden werden soll. Jup. Und nicht: Eine externe Datenbank, die in OSM abgebildet werden soll, was, wie mir scheint, derzeit der Fall ist. Eine direkte Verbindung mit der OSM-ID des Objektes nicht nicht möglich, da es in der OSM-Datenbank keinen »Fertig«-Zustand gibt, der ein Löschen oder Verändern des Objektes dauerhaft ausschließt. Jup. Daher muss ein Weg gefunden werden unabhängig von zukünftigen Änderungen an der OSM-Datenbasis zuverlässig eine Verknüpfung von OSM-Daten mit einer externen Datenquelle zu gewährleisten. Zuverlaessig und gewaehrleisten wird es nie geben. Was wir anstreben wuerden, waere allenfalls ein moeglichst geringes Risiko der unabsichtlichen Zerstoerung, sowie eine moeglichst einfache (automatisierte) Erkennung von solchen Problemen, so dass diese dann von Menschen repariert werden koennen. Ich behaupte, dass wir hier von einem komplexeren Problem sprechen, dass sich durch blinden Aktionismus nicht lösen lässt. Bevor jedoch keine zuverlässige und stabile Zu zuverlaessig und stabil s.o. weniger »schädliche« Lösung gefunden
Re: [Talk-de] TMC-Reform (war Re: Relevanzdiskussion (war Re: Koennen wir die TMC-Daten rauswerfen?))
Am 5. Februar 2011 15:01 schrieb Wolfgang wolfg...@ivkasogis.de: Das Problem sehe ich weniger im Löschen oder Nicht-Verstehen der tags. Wenn da tmc-Kram drin steht, lass ich die Node am Way dran, lösche, falls erforderlich, eine andere und schiebe diese dann so, dass es geometrisch passt. wenn man einen Tag nicht versteht sollte man natürlich auch die Geometrie nicht ändern oder nodes verschieben, weil man dadurch sehr oft was kaputt macht. Sobald man aber anfängt, was in der Umgebung zu ändern, kann es sein, dass man den Node verschieben müsste, damit man nichts kaputt macht. Von daher bergen solche Stellen die man nicht versteht immer Problempotenzial. Den Node nicht zu ändern dürfte in den meisten Fällen die beste Variante sein. Gruß Martin ___ 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 05.02.2011 22:44, schrieb Frederik Ramm: In bezug auf TMC wuensche ich mir, dass wir diese Daten mittelfristig weitgehend in ein OSM-externes System migrieren koennen, dass keinerlei regelmaessige automatische Veraenderungen von OSM fuer mehr TMC-Konformitaet stattfinden, und dass Benutzer, die sich nicht fuer TMC interessieren, nicht im Dunkeln tappen muessen. Was macht TMC weniger wichtig für OSM als ÖPNV, Wanderwege, ...? Es ist dir vielleicht nicht bewußt, aber das was du damit letztlich forderst ist nichts anderes als sowas wie die Relevanzkriterien der deutschen Wikipedia. Das gehört nicht hier her, das muß hier weg. Wenn du das Thema weiter denkst: Wieso müssen die TMC Daten raus in eine eigene Datenbank, aber die ÖPNV Daten dürfen drin bleiben? Mit der gleichen Argumentation wie du oben: Diese für mich überflüssigen und kryptischen ÖPNV Relationen stören mich die ganze Zeit beim Editieren - also raus damit! Und Wanderwege, kann doch eigentlich auch woanders hin, sind ja keine Geodaten, ... Was darf bleiben, was muß raus? Was sind die Kriterien, an denen du das bemißt? Wenn wir uns einig sind, dass es so, wie es jetzt ist, ganz bestimmt nicht richtungsweisend ist, dann ist das schonmal ein guter Anfang. Das wir ein allgemeines Problem mit der wachsenden Komplexität unserer Daten(strukturen) haben, ist ein offenes Geheimnis. Der Ansatz in externe DB auslagern hört sich auf den ersten Blick elegant an, hat aber schon bei der Wikipedia viel böses Blut erzeugt. Wir sollten versuchen bessere Lösungen zu finden als solche die schon anderswo mehr schlecht als recht funktioniert haben ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
Die Änderung der Konstante von 1 Mrd. auf 2 Mrd. habe ich nun auch im SVN eingecheckt. Hat jemand Zugriff auf topo.openstreetmap.de und könnte die Version austauschen? Henning Scholland schrieb: Wie groß wäre denn der Aufwand das auf int64 umzustellen? Muss da dann was am Algorithmus geändert werden, oder reicht es aus, den Datentyp der Variablen zu ändern? Ich hab' nun einfach mal die Datentypen auf 64-Bit Integer umgestellt. War keine große Aktion. Bei meinem Test auf einem 100 km² Gebiet hat das auch soweit funktioniert. Sicher bin ich mir trotzdem nicht, deswegen habe ich den Patch erstmal nur auf Gist hochgeladen: https://gist.github.com/812914 Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] C# Entwickler für kleine Reparatur gesucht
Michael Bemmerl wrote: Hat jemand Zugriff auf topo.openstreetmap.de und könnte die Version austauschen? Klar, das war meine Ecke bevor ich umgezogen bin. Werde das neue Binary hosten, sobald ich es ausprobieren konnte. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/C-Entwickler-fur-kleine-Reparatur-gesucht-tp5995433p5996662.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] C# Entwickler für kleine Reparatur gesucht
NopMap schrieb: Michael Bemmerl wrote: Hat jemand Zugriff auf topo.openstreetmap.de und könnte die Version austauschen? Klar, das war meine Ecke bevor ich umgezogen bin. Werde das neue Binary hosten, sobald ich es ausprobieren konnte. Versionsnummer habe ich allerdings keine geändert. Die Ausgabe im Programm ist noch auf v1.8.14.10. Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fehlerkorrektur in Crailsheim
Hallo zusammen, ich habe vor einigen Wochen das alte Residental-Area auf Landsat-Basis um Crailsheim herum mit mehr Details versehen und auf einen Stadtteil verkleinert. Den anderen Stadtteilen habe ich neue Areas spendiert. Aus irgend einem Grund wurde nun das veränderte Area zurückgesetzt. Könnte bitte jemand dem nachgehen und wieder die neue Version herstellen? http://www.openstreetmap.org/browse/way/39696094 Das Are sollte eigentlich z.B. unten bündig mit den Gebäuden sein. Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
PS: Offenbar hat das nur wer verschoben, was man an noch nicht neu gerenderten Kacheln sehr schön sehen kann: http://www.bilder-space.de/show_img.php?img=c1bc4d-1296950851.pngsize=original Kann das jemand zurücksetzen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
alle Änderungen seit Januar 2010 (zweitausend-zehn) wurden von dem User AndreR gemacht. Wer könnte das wohl sein? Schöne Grüße von der History Walter - 33,33% aller Statistiken beruhen auf kleinen Datenmengen. -- View this message in context: http://gis.638310.n2.nabble.com/Fehlerkorrektur-in-Crailsheim-tp5996702p5996753.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] Koennen wir die TMC-Daten rauswerfen?
Am 05.02.2011 22:44, schrieb Frederik Ramm: Wir haben vielleicht festgestellt, dass es nicht trivial ist; aber nicht, dass man es nicht kann. Es braucht halt ein bisschen Gehirnschmalz, und mir es es lieber, die externen Datenbanken werden kompliziert und OSM bleibt einfach, als umgekehrt. Denn wir haben hunderte von externen Datenbanken und nur ein OSM ;) TMC benötigt Fixpunkte die auf einer Strasse liegen. Benötigt man einen riesen Aufwand um diese Fixpunkte mit externen Lösungen zu finden ist die ganze Sache Wertlos. (Deine Idee mit dem Linken auf Revisionsstaende hat auch Charme, aber auch wieder ihre eigenen Probleme.) Im Gegesatz zu OSM gibt es diese bei TMC... In bezug auf TMC wuensche ich mir, dass wir diese Daten mittelfristig weitgehend in ein OSM-externes System migrieren koennen, dass keinerlei regelmaessige automatische Veraenderungen von OSM fuer mehr TMC-Konformitaet stattfinden, und dass Benutzer, die sich nicht fuer TMC interessieren, nicht im Dunkeln tappen muessen. Wenn wir uns einig sind, dass es so, wie es jetzt ist, ganz bestimmt nicht richtungsweisend ist, dann ist das schonmal ein guter Anfang. TMC-Daten sind relativ konstant und springen nicht wild umher! Autoradios bzw. Navis(Festeinbauten) werden relativ selten upgedated so dass sie schnell ändernde TMC-Daten wertlos machen würde. Dass solche Tags »schädlich« sind konnte bisher noch niemand mit Fakten belegen. Die einzige Aussage die hier von Dir und von Anderen glaubhaft vermittelt werden konnte ist, dass die gegenwärtige Lösung suboptimal ist. Ein einziger User, der sich wegen TMC-Tags nicht traut, ein Objekt zu bearbeiten - und da gab es mindestens einen hier im Thread - reicht in meinen Augen schon zum Schadensbeweis. Denk dran, dass sich hier in der Liste nur die Top 1% herumtreiben, und frage Dich, wie viele andere erschrocken ihre Finger von einer Verbesserung gelassen haben. Das ist absoluter Blödsinn! Mit der Begründung müsstest Du als aller erstes die Relationen wieder abschaffen! Sobald Du versuchst ein grob eingezeichnetes Stück Wald in zwei feiner aufgegliederte zu teilen kommt eine dicke Warnmeldung in JOSM wenn eine Relation im Spiel ist. Und Wälder sind mit Sicherheit nicht das wichtigste was OSM zu bieten hat - heisst ja auch OpenStreetMap und nicht OpenForestMap... Soll heissen es gibt ..zig Dingen die auch einem schon etwas geübteren User nicht geläufig sind und ihn davon abhalten können bestehende Daten aus seiner Sicht zu verbessern. Wir haben eine externe Datenquelle, die mit der OSM-Datenbank verbunden werden soll. Jup. Und nicht: Eine externe Datenbank, die in OSM abgebildet werden soll, was, wie mir scheint, derzeit der Fall ist. Es ist eine externe Datenbank die sich auf Bezugpunkte auf Strassen bezieht. Der Bezug auf feste Koordinaten ist wertlos weil es diesbezüglich Ungenauigkeiten sowohl in der externen Datenbank als auch bei OSM gibt. Der Stau findet auf der Strasse statt und nicht auf der daneben liegenden Wiese. Zuverlaessig und gewaehrleisten wird es nie geben. Was wir anstreben wuerden, waere allenfalls ein moeglichst geringes Risiko der unabsichtlichen Zerstoerung, sowie eine moeglichst einfache (automatisierte) Erkennung von solchen Problemen, so dass diese dann von Menschen repariert werden koennen. Das Ziel sollte sein möglichst wenig reparieren zu müssen und nicht möglichst viele Reparaturmöglichkeiten zu schaffen! weniger »schädliche« Lösung gefunden ist kommt eine Löschung der TMC-Daten nicht in Frage, da dadurch die Datennutzbarkeit in erheblichem Umfang eingeschränkt wird. Ehrlich gesagt scheint mir diese Datennutzbarkeit derzeit noch ein ziemliches Phantom zu sein. Das einzige, was ich gehoert habe, ist: Mein Nuevi kann mir einen Punkt anzeigen, an dem die Stoerung ist. Das aber kann ich auch, indem ich 100% extern jedem TMC-Node ein Koordinatenpaar zuweise. Ich verstehe, dass das gewuenschte Ziel ist, dass Router automatisch Wegsegmente highlighten und ausblenden koennen, aber gibt es irgendeine Software, und sei es auch nur proof of concept, die das macht? Oder reden hier alle nur von einer theoretischen, zukuenftigen, erhofften Nutzbarkeit? Hast nicht gerade Du immer gross auf Deine Fahnen geschrieben dass wir nicht für eine bestimmte Anwendung taggen sollen? Welche Anwendung zeigt Dir den den kürzesten Weg zum nächsten Hundekottütenspender an, welche zur nächsten Parkbank? Garry ___ 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 Ulf, Ulf Lamping wrote: Es ist dir vielleicht nicht bewußt, aber das was du damit letztlich forderst ist nichts anderes als sowas wie die Relevanzkriterien der deutschen Wikipedia. Das gehört nicht hier her, das muß hier weg. Es hat schon immer bei OSM die Auffassung gegeben, dass wir in der Regel keine Duplikate von extern gehaltenen Datenbestaenden bei uns anlegen wollen. Das hat noch nie jemand ein Relevanzkriterium genannt, aber wenn Du moechtest, kannst Du das tun. Es gibt Ausnahmen von dieser Regel, die aber nicht selten ziemlich umstritten sind. Ausnahmen kommen meistens vor, wenn * der externe Datenbestand von seinem Hersteller nicht mehr gepflegt wird und daher, wenn OSM ihn nicht adoptiert, immer nutzloser wird; * die Hoffnung besteht, dass die Arbeit in OSM durch diesen Datenbestand besser vorangeht (z.B. man importiert Ortsnamen aus der OpenGeoDB und erkennt dadurch dann leicher, wo man noch was tun muss) * man sich vom externen Datenbestand einen so hohen Nutzen erwartet, dass man alle Bedenken in den Wind schlaegt ;) Ausnahmen kommen nur aeusserst selten vor, wenn der externe Datenbestand *nicht* durch Mapper pflegbar ist; da gab es zum Beispiel mal eine lange Diskussion mit jemandem in den USA, der irgendwelche offiziellen Schutzgebietsgrenzen importieren wollte, die dann in OSM nicht editierbar sein sollten (denn sie waren ja offiziell) - das lief auch drauf hinaus: Wenn diese Daten so offiziell sind, dass man sie nicht aendern kann, dann brauchen wir sie auch nicht in OSM, denn OSM ist kein Sammelpott fuer coole Daten, sondern ein gigantisches Editierwerkzeug. Wenn du das Thema weiter denkst: Wieso müssen die TMC Daten raus in eine eigene Datenbank, aber die ÖPNV Daten dürfen drin bleiben? Die OePNV-Daten sind auch ein ziemlich komplexes Biest. Ich sehe den Unterschied, dass es die externe OePNV-Datenbank (im abstrakten Sinne, also in Form irgendeiner Liste, die von irgendwem herausgegeben oder gewartet wird) nicht gibt; diese Datenbank wird sozusagen durch OSM ueberhaupt erst aufgebaut. Beim OePNV ist es so, dass ein kundiger Mapper sich die OSM-Daten anschaut und selbst aus eigener Kenntnis eintraegt: Hier faehrt der Bus Nr. 67 lang. Es gibt keine offizielle Datenbank vom Verkehrsverbund, die man sich holen kann und in der das drin stuende (und erst recht keine bundesweite Datenbank). Aber mal angenommen, es *gaebe* eine solche Datenbank, die vom Bundesverband der Nahverkehrsunternehmen oder sonst wem gepflegt wuerde, dann waere ich der erste, der sagt: Lasst uns doch versuchen, einfach nur die Korrespondenz zwischen OSM und diesen Daten herzustellen, statt die Daten in OSM zu stopfen. Lasst uns ein Mapnik-Rendering-Backend schreiben, das die Verkehrsverbund-Daten anzapft und in die OePNV-Karte einzeichnet, statt diese und 100 andere Spartendaten alle bei uns pflegen zu wollen. Vielleicht kommt auch Transiki irgendwann mal dahin, dass dort Liniennetze und Tarif-/Fahrplaene gespeichert werden und bei uns die dazugehoerigen Geodaten. Das wuerde ich begruessen. Mit der gleichen Argumentation wie du oben: Diese für mich überflüssigen und kryptischen ÖPNV Relationen stören mich die ganze Zeit beim Editieren - also raus damit! Mich stoeren sie auch. Aber ich denke, man muss das pragmatisch sehen. Wir haben viele Leute, die gern daran arbeiten wuerden, diese OePNV-Daten zusammenzutragen, und ausser OSM gibt es derzeit kein geeignetes Vehikel. Ich sehe das auch als temporaer; irgendwann kann man die so gesammelten Daten vielleicht ausgliedern. Diese Argumentation trifft aber m.E. fuer TMC nicht zu. Diese Daten muessen nicht zusammengetragen werden, die existieren ja schon. Und Wanderwege, kann doch eigentlich auch woanders hin, sind ja keine Geodaten, ... Wie gesagt, ich sehe das pragmatisch. Grundsaetzlich ist OSM fuer Geodaten, und zwar im weitesten Sinne; wir erfassen von Restaurants ja mittlerweile auch schon, was sie kochen und ob sie rollstuhltauglich sind - weil alles andere nicht gescheit geht. *Gaebe* es aber eine deutschlandweite offizielle und garantiert richtige Restaurantdatenbank (zum Beispiel, weil sie von einer Behoerde rausgegeben wird, die die Genehmigungen zum Eroeffnen eines Restaurants erteilt), dann wuerden wir uns vieles sparen und einfach nur auf diese Datenbank verweisen (oder ein komplizierteres Link-Schema aufbauen). Bei TMC ist es nun mal so, dass es richtiger als die offizielle Datenbank nicht geht. Das ist komplett extern, da ist kein Spielraum fuer den Mapper, irgendwas zu verbessern. Oder sehe ich das falsch? Es gibt auch durchaus sowas wie die Lizenz zum Spielen in OSM. Man muss nicht alles rechtfertigen, was man macht. Aber ab einem gewissen Punkt muss man sich vielleicht schon mal fragen lassen, was man da gerade landes- oder weltweit fuer ein Schema ausrollt und ob man sich das auch gut ueberlegt hat, oder ob man da was konstruiert, mit dem zwar tausende in
Re: [Talk-de] Koennen wir die TMC-Daten rauswerfen?
Hallo, Garry wrote: TMC benötigt Fixpunkte die auf einer Strasse liegen. Benötigt man einen riesen Aufwand um diese Fixpunkte mit externen Lösungen zu finden ist die ganze Sache Wertlos. Ich bin nicht ueberzeugt, dass es sich hier um einen Riesenaufwand handelt. Ich koennte mir vorstellen, dass man mit einem halbwegs gescheiten Vorverarbeitungsschritt problemlos das Strassennetz aus OSM nehmen kann plus den TMC-Graphen und das gescheit aufeinander abbilden. Denn wie Du richtig sagst, werden die TMC-Segmente wohl kaum auf der Wiese liegen oder auf dem Radweg, der neben der Bundesstrasse verlaeuft. Und wer auch immer die OSM-Daten fuer das routingfaehige Navi aufbereitet, muss diese ganzen Daten doch eh durchnudeln. Aber das ist jetzt von mir zugegebenermassen so dahingesagt, ich habe das noch nicht selber ausprobiert. Vielleicht schlummern da irgendwelche Hunde, die ich nicht kenne. Pascal weiss das sicher besser, deswegen versuche ich jetzt mal, bis zu seinem Talk auf der FOSSGIS nicht mehr weiterzuspekulieren ;) Ein einziger User, der sich wegen TMC-Tags nicht traut, ein Objekt zu bearbeiten - und da gab es mindestens einen hier im Thread - reicht in meinen Augen schon zum Schadensbeweis. Denk dran, dass sich hier in der Liste nur die Top 1% herumtreiben, und frage Dich, wie viele andere erschrocken ihre Finger von einer Verbesserung gelassen haben. Das ist absoluter Blödsinn! Mit der Begründung müsstest Du als aller erstes die Relationen wieder abschaffen! Sind wir uns also darin einig, dass jeder User, der durch was-auch-immmer erschrocken seine Finger von etwas laesst, einen Schaden darstellt? Egal ob TMC:c347:tabcdefghi:next_pointer=0x3728754 oder durch eine Multipolygonrelation? Soll heissen es gibt ..zig Dingen die auch einem schon etwas geübteren User nicht geläufig sind und ihn davon abhalten können bestehende Daten aus seiner Sicht zu verbessern. Genau, und diese Dinge muessen wir kennen, verstehen, im Griff behalten, bekaempfen, reduzieren. Ich hab neulich, als ich eine Gruppe Studenten in OSM einfuehren sollte, schon ein Dorf in Turkmenistan mappen lassen, weil ich so viel gar nicht an einem Vormittag erklaeren konnte, wie die wissen muessten, um in einer deutschen Innenstadt was zu editieren. weniger »schädliche« Lösung gefunden ist kommt eine Löschung der TMC-Daten nicht in Frage, da dadurch die Datennutzbarkeit in erheblichem Umfang eingeschränkt wird. Ehrlich gesagt scheint mir diese Datennutzbarkeit derzeit noch ein ziemliches Phantom zu sein. Das einzige, was ich gehoert habe, ist: Hast nicht gerade Du immer gross auf Deine Fahnen geschrieben dass wir nicht für eine bestimmte Anwendung taggen sollen? Also wenn jemand 175000 Tags in Deutschland verteilt und wenn in der Mailingliste behauptet wird, dass deren Entfernung die Datennutzbarkeit in erheblichem Umfang einschraenken wuerde, dann wird doch mal die Frage erlaubt sein, worin konkret diese Datennutzbarkeit besteht? 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] Fehlerkorrektur in Crailsheim
Am Samstag, den 05.02.2011, 16:27 -0800 schrieb Walter Nordmann: alle Änderungen seit Januar 2010 (zweitausend-zehn) wurden von dem User AndreR gemacht. Wer könnte das wohl sein? Genau das ist ja das Seltsame an der Sache: Das Polygon wurde definitiv erst in den letzten paar Tagen oder gar Stunden verschoben (wie man zweifelsfrei an meinem Kartenausschnitt sehen kann). Gibt es denn eine Möglichkeit, Daten »um ein Changeset herum« zu manipulieren? Anders kann ich mir diesen Fehler nämlich nicht erklären. Hat jemand eine Erklärung für dieses Phänomen? Gruß, André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
André Reichelt schrieb: Am Samstag, den 05.02.2011, 16:27 -0800 schrieb Walter Nordmann: alle Änderungen seit Januar 2010 (zweitausend-zehn) wurden von dem User AndreR gemacht. Wer könnte das wohl sein? Genau das ist ja das Seltsame an der Sache: Das Polygon wurde definitiv erst in den letzten paar Tagen oder gar Stunden verschoben (wie man zweifelsfrei an meinem Kartenausschnitt sehen kann). Genauer gesagt: Am Freitag um 17:27, wie aus der History der einzelnen Nodes des Polygons ersichtlich ist. Die Änderung erfolgte in folgendem Changeset (Kommentar Turn restriction): http://www.openstreetmap.org/browse/changeset/7185246 Gibt es denn eine Möglichkeit, Daten »um ein Changeset herum« zu manipulieren? Anders kann ich mir diesen Fehler nämlich nicht erklären. Nicht das ich wüsste. Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Bäume sind ein Wald - Uferbäume
Am 05.02.2011 13:21, schrieb RalfGesellensetter: Was sagen die Experten? Nur als Aufheiterung in diesem etwas Längeren Thread, aber Georg Ahlers hatte das Problem auch schon letztes Jahr: http://www.youtube.com/watch?v=gOEs42xeGQw -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] rechtliches - Firmen-Symbole
Am 25.09.2009 17:45, schrieb Frederik Ramm: Gegen eine Karte, die an der Stelle, wo sich eine Filiale der entspr. Firma befindet, dieses Symbol abbildet, kann die Firma m.E. nichts einwenden. Ärger ist zumindest dann vorprogrammiert, wenn man die güldene Möve auf den nächsten Dönermann klebt. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
Hallo, André Reichelt wrote: Gibt es denn eine Möglichkeit, Daten »um ein Changeset herum« zu manipulieren? Anders kann ich mir diesen Fehler nämlich nicht erklären. Diese Moeglichkeit gibt es nicht. Aber habt ihr daran gedacht, dass eine Verschiebung herbeigefuehrt wird, indem man die *Nodes* aendert? Das Polygon bleibt dabei ja unveraendert. Und die Nodes scheinen mir allesamt am Freitag um 17:25 von einem gewissen AndreR verschoben worden zu sein - mit dem Changeset-Kommentar Turn Restriction ;) 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] Fehlerkorrektur in Crailsheim
Am Sonntag, den 06.02.2011, 03:02 +0100 schrieb Frederik Ramm: Und die Nodes scheinen mir allesamt am Freitag um 17:25 von einem gewissen AndreR verschoben worden zu sein - mit dem Changeset-Kommentar Turn Restriction ;) Danke Euch beiden. Ich habe am Freitag mit Mapzen herumgespielt, da ich den Turn-Restrictions-Editor ausprobieren wollte. Dabei habe ich wohl versehentlich auch den Way verschoben. Kann man die Verschiebung irgendwie rückgängig machen? Oder geht es schneller, das Ding von Hand wieder hinzuschieben? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Moin! Am 01.02.2011 19:41, schrieb Frederik Ramm: Stephan Wolff wrote: Der von mir erstellten Regeln führen leider zu sehr sehr langen Renderzeiten. [...] Ausserdem hat die Standard-Datenbank auch keine Indexe ausser dem geografischen; Deine Abfragen sind ja oft: select haufen krimskrams from planet_osm_line where power=line da wird dann ueber den GIN-Index alles rausgesucht, was in dem geogr. Bereich ist, und per table scan dann jede einzelne Linie angechaut, ob sie vielleicht power=line hat. Ich hatte vermutet, dass meine verschachtelten Abfragen Schuld sind, aber Frederik hat mit dieser Beschreibung die Hauptursache getroffen. Ich habe den Zeitbedarf verschiedener SQL-Abfragen für größere Bereiche verglichen. Eine einfache Abfrage aller Punkte mit power=generator $ time psql -c select count(*) from planet_point where power=generator and way bounding_box ... benötigte in meinem Testbereich etwa 2,5 Minuten. Komplexe, geschachtelte select-Anweisungen $ time psql -c select sum(output) from (select haufen krimskrams from planet_point where power=generator and way bounding_box ... waren nur wenige Sekunden langsamer. Auch die Position des geogr. Filters in der inneren oder in der äußeren select-Anweisung machten keinen Unterschied. Somit bleibt zur Beschleunigung nur die Möglichkeit, eine eigene Datenbank vorab anzulegen. Kann man Osm2pgsql so konfigurieren, dass eine weitere Tabelle mitgepflegt wird oder muss man in regelmäßigen Abständen die gesamte Hauptdatenbank filtern? Vielen Dank auch an meinen Namensvetter Stephan und Tim für die hilfreichen Kommentare. Jetzt verstehe ich besser, wie Mapnik die Karten rendert. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
André Reichelt schrieb: Am Sonntag, den 06.02.2011, 03:02 +0100 schrieb Frederik Ramm: Und die Nodes scheinen mir allesamt am Freitag um 17:25 von einem gewissen AndreR verschoben worden zu sein - mit dem Changeset-Kommentar Turn Restriction ;) Danke Euch beiden. Ich habe am Freitag mit Mapzen herumgespielt, da ich den Turn-Restrictions-Editor ausprobieren wollte. Dabei habe ich wohl versehentlich auch den Way verschoben. Kann man die Verschiebung irgendwie rückgängig machen? Oder geht es schneller, das Ding von Hand wieder hinzuschieben? Ich hab' deine letzte Änderung an den Nodes des landuse-ways rückgängig gemacht. Auf der (bereits neugerenderten) Karte schaut es passend aus. Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerkorrektur in Crailsheim
Am Sonntag, den 06.02.2011, 04:48 +0100 schrieb Michael Bemmerl: Ich hab' deine letzte Änderung an den Nodes des landuse-ways rückgängig gemacht. Auf der (bereits neugerenderten) Karte schaut es passend aus. Vielen Dank, scheint zu passen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
