Re: [Talk-de] Datenbankbereinigung
On Thu, 7 Aug 2008, Florian Lohoff wrote: Ich habe keinen stress das jeder tags nutzt wie er will aber syntaktisch sollte das so strickt wie moeglich machen damit nicht jedes blode script was irgendwas mit den OSM daten macht angepasst werden muss wenn wieder jemand bullshit da reinschreibt. Ich bin gespannt was alles auf die fresse geht wenn jemand onway=`hostname` oder oneway='\' da reinschreibt oder irgendwelche SQL injection geschichten. Wieso. Alles was der Render, Nutzer, Konverter nicht kennt wird ignoriert. Ist doch einfach. Und das tagwatch-Interface kann man nutzen, um offensichtliche Fehler zu korrigieren (falls Du es nicht bemerkt hast, wenn man die Einträge anklickt, bekommt man eine OSM-Datei geliefert, welche man z.B. in JOSM korrigieren kann). z.B. Für Routingkarten wird jeder Gerätehersteller irgendwann ein OSM--eigenes Format Konverter haben, der Darstellungen vereinheitlicht, bekannte Fehler korrigiert und das Datenformat für die Zielanwendung optimiert. Idealerweise schickt er die beim Fehlerkorrigieren angefallenen Änderungen dann wieder in die Datenbank. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Validator
On Fri, 8 Aug 2008, Michael Strauß wrote: Bin gerade dabei meine ersten Schritte als Mapper zu machen. Benutze dabei JOSM, weil dieser mir erheblich mehr zusagt, als POTLATCH. Dazu einige Fragen: Ich habe einen Parkplatz als Areal gezeichnet, der von einer Straße begrenzt wird. Dabei habe ich für die Begrenzungs des Parkplatzes die Nodes der Straße benutzt. Der Validator gibt nun aus: Other - Overlapping Ways Soll ich da was ändern? Außerdem meckert der Validator unbenannte Straßen an, die aber in einer Relation mit name-Tag stehen. (Wenn ich Sie einzeln Benenne, meckert er doppelte Namen an!) Demnächst(TM) hat der Validator eine Ignorier-Option, mit der Du falsche Meldungen ab sofort ignorieren lassen kannst. Außerdem sollten aktuelle Validator-Versionen eigentlich zwischen verschiedenen Arten von Überlappungen trennen. Überlappende Straßen sind i.d.R. falsch. Überlappende Flächen i.d.R. nicht :-) Was meckert er an, wenn Du die Straßen benennst? So ein Test ist gar nicht drin. Gleiche Namen meckert er nur bei Knoten an. Hast Du vielleicht nicht nur die Straße, sondern auch die Knotenpunkte der Straße benannt? Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kilometrierung von Autobahnen und anderen Strassen
On Thu, 7 Aug 2008, Oliver Koppisch wrote: Ein Bekannter von mir setzt in seinen Streckenkontrollfahrzeugen (er arbeitet bei einer Autobahnmeisterei) Windows mobile-PDAs mit GPS ein. Er hat mich nun gefragt, ob es möglich wäre dem Fahrer anzuzeigen, auf welchem Autobahnkilometer er sich gerade befindet, und das möglichst genau (ca. 50m). Da kam mir nun der Gedanke, für die Ermittlung des Standorts OSM-Daten einzusetzen. Mein erster Ansatz (Nullpunkt für die Autobahn in den OSM-Daten setzen und die Segmente bis zur momentanen Position aufaddieren) hat sich in Luft aufgelöst, als ich mir auf http://www.autobahnatlas-online.de/ exemplarisch die A8 angeschaut habe. Ich führe hier mal ein paar Merkwürdigkeiten auf : - Die A8 hat vier Abschnitte mit drei Nullpunkten - München-Haidhausen bis österreich. Grenze - München-Obermenzing bis Adreieck Karlsruhe - Landstuhl bis zur saarländ./rheinl.pfälz. Grenze - saarländ./rheinl.pfälz. Grenze bis luxemburgische Grenze. - Die Saarländer fangen bei km 0 an zu zählen, die Pälzer bei km 100, aber in die andere Richtung - Bei München-Haidhausen gibt es negative Autobahnkilometer, weil die Autobahn im Nachhinein verlängert wurde. Nun meine Fragen : Wie könnte man dies in den OSM-Daten modellieren ohne all zuviel Aufwand? Ich hatte zunächst an Relatione für die einzelnen Abschnitte gedacht. Aber mit Relationen gibt es momentan wohl noch Probleme. Für mich klingt Dein erster Ansatz zu einfach (Du hättest hier eine extreme Fehlerfortpflanzung, die kaum genaue Ergebnisse ermöglicht), der zweite zu kompliziert. Warum setzt Du nicht einfach in die Autobahn an den Kilometertafeln einen Node mit einem Tag z.B. chainage=100.5 Je mehr solcher Tags Du drin hast, desto besser kann ein Interpolationsalgorithmus den Wert für einen bestimmten Punkt herausfinden. Da mittlerweile auch alle Autobahnen in Relationen stecken, ist es auch relativ leicht die Kilometrierungspunkte zu finden. Allerdings ist es nicht leicht die Punkte auf der Autobahn zu bestimmen, da man dazu ja sehr langsam sein müßte, was auf der Autobahn immer etwas schlecht ist. P.S. Das ganze funktioniert dann übrigens auch mit Schienen und Landstraßen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kilometrierung von Autobahnen und anderen Strassen
Hallo. Am Freitag, 8. August 2008 schrieb Dirk Stöcker: Allerdings ist es nicht leicht die Punkte auf der Autobahn zu bestimmen, da man dazu ja sehr langsam sein müßte, was auf der Autobahn immer etwas schlecht ist. Wenn die Straßenmeisterei von einer solchen Datenspeicherung einen Nutzen hätte, sollte es möglich sein, bei Streckenkontrollfahrten (die auch mal langsamer gemacht werden können) entsprechende Daten aufzuzeichnen. Natürlich ist das immer so ne Sache mit dem Engagement für OSM weil ja solche Betriebe ihre Daten in der Regel schon haben oder vom Vermessungsamt bekommen. :) Mit Florian Lohoffs StreetView-mäßigem Kamera-Setup sollte aber auch sowas durchaus recht genau aufzeichenbar sein wenn man z.B. mit 60 rechts auf ner Autobahn fährt... ;-) P.S. Das ganze funktioniert dann übrigens auch mit Schienen und Landstraßen. Ack. Und bei Landstraßen kann man es i.d.R. auch selbst genau genug erfassen. Gruß, Bernd -- Joey: Also gut Ross hör zu. Du fühlst dich momentan hundeelend, du bist sehr wütend, und gekränkt. Soll ich dir mal 'nen guten Rat geben? Ross: Ah. Joey: Geh in ein Striplokal. - Friends (am. Sitcom) 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] Datenbankbereinigung
On Thu, 7 Aug 2008, Sven Geggus wrote: Tobias Wendorff [EMAIL PROTECTED] wrote: Heul doch! Das war unnötig! Aus der Tatsache, dass Du den durchaus konstruktiven Teil meines Postings unkommentiert läßt mag sich der geneigte Leser selbst seine Meinung bilden. Ich ignoriere Positings mit persönlichen Angriffen generell, egal ob sie sonst noch sinnvolle Argumente enthalten oder nicht. Das muss Tobias noch lernen. Ansonsten hat er vollkommen recht. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SHAPE Format
Hallo, Christoph Brill schrieb: gibt es eine einfache Möglichkeit Daten aus dem SHAPE-Format in OpenStreetMap zu konvertieren? Ich habe von der Stadt Koblenz die Erlaubnis die Stadtteile aus einer Datei in diesem Format in OpenStreetMap zu übernehmen. Nur wie? Vorschläge? bin leider in 4-5 Minuten weg, kann Dir morgen aber den kompletten Datensatz konvertieren. Grüße Tobias Sorry, ich war gestern abend nicht mehr am Rechner und komme erst Montag wieder an die Daten. Mich würde aber vor allem nicht nur das Ergebnis interessieren sondern wie man dahin kommt. Über shp2osm? Oder kann gpsbabel das sogar? Viele Grüße und vielen Dank im Voraus, Christoph -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kilometrierung von Autobahnen und anderen Strassen
Oliver Koppisch wrote: - Die A8 hat vier Abschnitte mit drei Nullpunkten - München-Haidhausen bis österreich. Grenze - München-Obermenzing bis Adreieck Karlsruhe - Landstuhl bis zur saarländ./rheinl.pfälz. Grenze - saarländ./rheinl.pfälz. Grenze bis luxemburgische Grenze. was meinst du mit Landstuhl - saarländ./rheinl.pfälz. Grenze ? in Landstuhl kreuzen sich die A5 und die A62 die A8 geht von Pirmasens (A62) in einem Stück bis zur luxemburgischen Grenze. (laut http://www.autobahnatlas-online.de/ mit einem neuen km-Nullpunkt an der Grenze SAR/RLP) Nun meine Fragen : Wie könnte man dies in den OSM-Daten modellieren ohne all zuviel Aufwand? Ich hatte zunächst an Relatione für die einzelnen Abschnitte gedacht. Aber mit Relationen gibt es momentan wohl noch Probleme. ich habe einige der km-Schilder mit dem Diktiergerät aufgenommen (A5,A67,A6,A3) und als marker= eingetragen. Die Hin-/Rückrichtung haben da eigentlich meistens ganz gut zusammengepasst. Frank ___ Der frühe Vogel fängt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wegpunkte aus JOSM exportieren
Hallo, On Mon, Jul 28, 2008 at 08:26:25PM +0200, Frederik Ramm wrote: gibt es eigentlich schon irgendeine Möglichkeit in JOSM Wegpunkte mit Namen zu setzen und diese anschließend als GPX zu speichern, so dass man diese in ein GPS laden kann (mit Namen)? Save as GPX? das speichert aber nicht den Namen ab. Ich hatte einfach ein Tag mit dem Namen name in OSM erstellt. Außerdem habe ich desc und description erstellt. Die GPX hatte aber keinen Tag mit dem Namen name. Das Konvertieren mit gpsbabel probiere ich bei Gelegenheit aus. Viele Grüße Sebastian Waschik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Hallo, Die Herausforderung bei OSM ist, aus den Daten was gutes zu machen, ohne dass es feste Regeln gibt, weil feste Regeln den Evolutionsprozess zerstoeren, den Mapper zum tumben Datentypisten machen und dem Projekt die Dynamik nehmen, die es zum Leben braucht. So nach dem Motto, ich hab was eigenes kreiert, ich schreibe oneway=true statt yes? Warum dann nicht auch noch ja, oui, natürlich und wag es nicht da rein zu fahren Die OSM-Datenbank ist doch keine Prosa, wir wollen damit keinen Literaturnobelpreis gewinnen. Es ist eine primär maschinenlesbare Datenbank, und da muß man sich schon an gewisse Formate halten damit es klappt. Es ist kein evolutionärer Prozess einfach ein Synonym zu benutzen. Herausfinden welche Methode am besten/einfachsten ist um Abbiegeverbote einzutragen o.ä. da kann es sinnvoll sein verschiedene Wege zu probieren. Ich gebe keine Daten bei OSM ein, damit ich sie mir dann ausdrucken und an die Wand hängen kann um zu sagen, das habe ich geleistet. Ich möchte, daß sie für möglichst viele Leute nützlich sind. Und wenn ich da true statt yes eingebe sind die Daten erstmal nutzlos, es sei denn irgendein Programierer von Renderern, Routern o.ä. fügt true in die Einleseroutine ein. Nur könnte der statt dessen etwas sinnvolleres machen was den Nutzen von OSM wirklich erhöht. Stellt Euch vor, die OSM-Programierer würden mit so einer Logik programieren, dann würde kein einziges Programm laufen. Da können die Mapper doch etwas solidarisch mit ihnen sein und ihnen das Leben leichter machen. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, Aug 08, 2008 at 08:38:41AM +0200, Dirk Stöcker wrote: Wieso. Alles was der Render, Nutzer, Konverter nicht kennt wird ignoriert. Ist doch einfach. Und das tagwatch-Interface kann man nutzen, um offensichtliche Fehler zu korrigieren (falls Du es nicht bemerkt hast, wenn man die Einträge anklickt, bekommt man eine OSM-Datei geliefert, welche man z.B. in JOSM korrigieren kann). Der punkt ist das man z.b. beliebig zeugs da reinpacken koennte um das XML zu zerstoeren was als export da rauskommt. Damit ist das ganze file unbrauchbar ... Im XML file: tag k=created_by v=JOSM/ Jetzt setze ich ein tag created_by=/ Damit wuerde da stehen tag k=created_by v=// Koennte mir dem parsen von XML eng werden. Alternativ koennen da auch tags eingeschmuggelt werden: created_by=JOSM/tag k=hidden_tag v=test damit kaeme da raus: tag k=created_by v=JOSM/tag k=hidden_tag v=test/ Und mit genuegend krimineller energie laesst sich das bestimmt fortpflanzen d.h. statt einfacher OSM XML Tags einfach ein paar SVG elemente einbauen. Dank XSLT und nen bischen handcraft landet das in der karte. D.h. jemand schreibt texte auf die Karte die in den rohdaten so nicht drin sind. z.B. Für Routingkarten wird jeder Gerätehersteller irgendwann ein OSM--eigenes Format Konverter haben, der Darstellungen vereinheitlicht, bekannte Fehler korrigiert und das Datenformat für die Zielanwendung optimiert. Idealerweise schickt er die beim Fehlerkorrigieren angefallenen Änderungen dann wieder in die Datenbank. Es geht nicht um semantische sondern um syntaktische fehler. Wenn jeder seinen eigenen konverter baut ist eben der inhalt interpretationssache und ich denke das das nicht in unserem sinne ist. Ich bin ja dafuer das jeder erfasst und tagged was er moechte, aber am liebsten so das es mit gaengigen nutzungsformen der karte nicht kollidiert. Wie man das im einzelnen macht ist mir auch nicht so klar, aber wenn man sich RFC822/RFC2822 ansieht gibts halt pflicht und kuer. D.h. ich habe Tags/Elemente die sind definiert in ihrem syntaktischen aufbau und es gibt eben freie felder die applikations oder interpretationsabhaengig sind. Diese fangen im Mailheader typischerweise mit X-tag: value an. Ob das besser ist als die herrschende Anarchie die uns ja schon weit gebracht hat weiss ich nicht. Nur so als denkanstoss. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SHAPE Format
Hallo nochmal, was ist denn die beste Projektion[1] in dem eine Datei im SHAPE Format vorliegen sollte, damit sie möglichst einfach konvertiert werden kann? Viele Grüße, Christoph [1] http://de.giswiki.net/wiki/Projektion Original-Nachricht Datum: Thu, 07 Aug 2008 21:38:06 +0200 Von: Christoph Brill [EMAIL PROTECTED] An: talk-de@openstreetmap.org Betreff: [Talk-de] SHAPE Format Hallo zusammen, gibt es eine einfache Möglichkeit Daten aus dem SHAPE-Format in OpenStreetMap zu konvertieren? Ich habe von der Stadt Koblenz die Erlaubnis die Stadtteile aus einer Datei in diesem Format in OpenStreetMap zu übernehmen. Nur wie? Vorschläge? Viele Grüße, Christoph ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen! Jetzt dabei sein: http://www.shortview.de/[EMAIL PROTECTED] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kilometrierung von Autobahnen und anderen Strassen
Bernd Wurst schrieb: mit 60 rechts auf ner Autobahn fährt... ;-) er dürfte sogar noch langsamer... die 60 Kmh sind ja nur die kleinste Höchstgeschwindigkeit der autos, mit denen man noch auf der autobahn fahren darf. dh: sobald dein auto mehr als 60 fahren _kann_, darfst du auf der autobahn fahren... egal wie langsam (solange du den verkehr nicht stark behinderst (zb auf einer einspurigen strecke)) diese regelung wurde übrigens wegen Staus erlassen (sonnst dürfte ja keiner im Stau unter 60 fahren) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, Aug 08, 2008 at 03:11:11AM +0200, Frederik Ramm wrote: Bei OpenStreetMap wird an der Ausgabeseite gefiltert, nicht an der Eingabeseite. Das ist ein (noch) recht unuebliches Konzept, aber man kann m.E. damit gut arbeiten und erfolgreich sein, wenn man sich darauf einlaesst, denn es hat auch sehr viele Staerken gegenueber einem System, das an der Eingabeseite filtert. So habe ich es noch nicht gesehen - aber interessante sichtweise die ich erstmal spannend finde. Ich hoffe das die entsprechenden feedback prozesse nach vorne finden denn ich denke diese sind essentiell um einen Datenbestand zu bekommen der so konsistent ist das das was vorne eingegeben wird auch hinten die richtige wirkweise erzeugt. Das beispiel mit dem Oneway wird sicherlich so nicht funktionieren sondern ignoriert werden daher ist es fragwuerdig ob der mapper/author der daten nicht vielleicht ein strikteres datenmodell bevorzugt haette in dem er sicher gehen kann das das erwuenschte ergebniss raus kommt. Wie ja des haeufigeren zu beobachten wird ja schon fuer die renderer getagged und erfasst und an den tags rumgeschraubt bis es auf der Karte schoen aussieht. Sicherlich ist das nicht das gewuenschte vorgehen aber doch halt sehr menschlich. Ich habe arbeit geleistet und die motivation wird aus dem ergebniss geschoepft. Bei einem renderer (z.b. osmarender) habe ich ja ein feedback innerhalb von 30 minuten im optimalfall. Bei einem distributor der die karten durchnudelt ggfs nach 6 monaten wenn der den datenbestand abgleicht und die feedback schleife funktioniert. Vielleicht ist des raetsels loesung auf ein validator der zusaetzlich zu den syntaktischen auch auf semantische fehler achtet und gleich sich meldet wenn eingaben vermutlich in der ausgabe ignoriert werden. Vielleicht baut uns das ja auch der Distributor der Daten ;) Ich denke aber das fuer gute daten im sinne von konsistent und syntaktisch wie semantisch zu parsen und interpretieren essentiell von der latenz des feedbacks abhaengen. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, 8 Aug 2008, Florian Lohoff wrote: Vielleicht ist des raetsels loesung auf ein validator der zusaetzlich zu den syntaktischen auch auf semantische fehler achtet und gleich sich meldet wenn eingaben vermutlich in der ausgabe ignoriert werden. Ich baue gerade ein entsprechendes Modell in den JOSM-Validator ein, welches komplexe Prüf-Regeln zuläßt. Dauert aber noch ein Weilchen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Hallo. Am Freitag, 8. August 2008 schrieb Dimitri Junker: So nach dem Motto, ich hab was eigenes kreiert, ich schreibe oneway=true statt yes? Warum dann nicht auch noch ja, oui, natürlich und wag es nicht da rein zu fahren Nein, nach dem Motto: Wenn es noch nichts gibt was genau das darstellt was ich will, dann nehm ich was ähnliches oder was ganz anderes. Im Fall von oneway (bzw. allen Ja-Nein-Angaben) gab es irgendwann mal, vor längerer Zeit keine Definition im Wiki wie man das machen könnte. Dann kamen die einen, vielleicht Programmierer, die sagten true/false nehmen wir dafür, das ist die intuitive Darstellung von boolschen Werten. Dann kamen die anderen, vermutlich keine Programmierer, die sagen: nee, das kann ich mir nicht merken, yes/no ist doch viel intuitiver und das versteht dann jeder. Und dann kommt der Schlaumeier, der meint wenn man mehrere richtungsgebundene Dinge an einer Straße hat, brauchen wir auch ein Gegenrichtungs-Einbahnstraßen-Tag. Da wurde dann -1 eingeführt. Vielleicht benutzen auch manche Leute intuitiv opposite, ich weiß es nicht. Jedenfalls wurde dann irgendwann mal beschlossen, wir dokumentieren einfach diese drei Dinge: yes/no, true/false und -1. Dann muss man an den eingegebenen Daten keine unnötigen Änderungen machen und sowohl der Programmierer als auch der 08/15-Mapper sollte jeweils für sich eine diese Varianten als intuitiv ansehen. Ich kann mich nicht dran erinnern, dass jemals irgendjemand eines deiner polemischen anderen Beispiele ernsthaft als das wäre sehr viel praktischer kommuniziert hat. Bei den von mir genannten (und auch in Gebrauch befindlichen) kann ich mir das wie oben geschrieben sehr gut vorstellen. Bei allen obskuren Beispielen bedenke: Dass wir Tag-Inhalte oft auf englisch formulieren ist hoffentlich jedem bekannt und daher sind deutsche oder französische Texte sowieso am internationalen Charakter vorbei gewählt. Und innerhalb des englischen gibt es halt das technische true/false und das umgangssprachliche yes/no. Keins ist falsch und daher sind einfach beide dokumentiert und keiner wird gezwungen was für ihn unintuitives zu benutzen. Die OSM-Datenbank ist doch keine Prosa, wir wollen damit keinen Literaturnobelpreis gewinnen. Schade, hatte mir grade Hoffnungen gemacht... ;-) Es ist eine primär maschinenlesbare Datenbank, und da muß man sich schon an gewisse Formate halten damit es klappt. Tun wir doch. Es ist kein evolutionärer Prozess einfach ein Synonym zu benutzen. Nicht? Die Welt braucht auch keinen zweiten, äquivalenten Text-Dokument-Standard. Wir brauchen auch keine mehreren Methodn wie man Zeilenenden in einer Textdatei speichert. Wir brauchen eigentlich keine unterschiedlichen Papierformate weltweit. Trotzdem haben wir es. Und jeder, der ernsthaft mit den entsprechend unterschiedlichen Dingen zu tun hat, versteht es einfach, alles zu lesen und es funktioniert. Und wenn ich da true statt yes eingebe sind die Daten erstmal nutzlos, es sei denn irgendein Programierer von Renderern, Routern o.ä. fügt true in die Einleseroutine ein. Das haben bisher alle getan, die unsere Daten nutzen. true ist als äquivalent von yes schon so lange im Wiki dokumentiert, dass das von je her alle Daten-Konsumenten einfach so eingebaut haben. Nur könnte der statt dessen etwas sinnvolleres machen was den Nutzen von OSM wirklich erhöht. In den 2 Minuten die er für eine solche ODER-Abfrage braucht, könnte der auch auf's Klo gehen. Ich denke nicht, dass irgendjemand ernsthaft aus diesem Zustand ein reales Problem bekommt. Stellt Euch vor, die OSM-Programierer würden mit so einer Logik programieren, dann würde kein einziges Programm laufen. Die OSM-affinen Projekte machen das seit je her. Jedes oneway=true wird in Mapnik und Osmarender eingezeichnet, genauso wie sich openrouteservice daran hält. Ich versteh dein Problem nicht. Nochmal: Wir es ist nicht so beschlossen bzw. dokumentiert, dass JEDER WERT eine maschinenlesbare Aussage hat, sondern dass 3 (DREI) verschiedene Bezeichnungen für dasselbe existieren. Das sind nur drei Stück, das ist echt abzählbar und überschaubar. Es sind NUR DREI. Kein yo, jau, jawoll, oui oder so ist es wird von einem Datenkonsument verstanden. Das muss es auch nicht, weil das NIEMAND EINTRÄGT. Auch wenn es technisch geht und geeignet wäre, hier Stimmung zu machen. Da können die Mapper doch etwas solidarisch mit ihnen sein und ihnen das Leben leichter machen. Da ich in meiner Freizeit mappe, möchte ich eigentlich erstmal dass mir das Leben nicht schwer gemacht wird. Gruß, Bernd -- Es vergeht kein Tag an dem ich nicht alles wieder infrage stelle. - André Gide (frz. Schriftsteller) 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] Datenbankbereinigung
Am 8. August 2008 01:34 schrieb Dimitri Junker [EMAIL PROTECTED]: So nach dem Motto, ich hab was eigenes kreiert, ich schreibe oneway=true statt yes? Warum dann nicht auch noch ja, oui, natürlich und wag es nicht da rein zu fahren [...] Ich möchte, daß sie für möglichst viele Leute nützlich sind. genau - schon deshalb wirst du auch von vornherein davon Abstand nehmen etwas anderes als true, yes oder 1 dafür zu nehmen Und wenn ich da true statt yes eingebe sind die Daten erstmal nutzlos, es sei denn irgendein Programierer von Renderern, Routern o.ä. fügt true in die Einleseroutine ein. Was ja nicht zuviel verlangt ist, wenn man bedenkt was alternative Daten kosten - der Aufwand für yes or true or 1 ist gegenüber Tausender € trivial. Stellt Euch vor, die OSM-Programierer würden mit so einer Logik programieren, dann würde kein einziges Programm laufen. Da können die Mapper doch etwas solidarisch mit ihnen sein und ihnen das Leben leichter machen. Die Mapper haben das Interesse, das ihre Daten benutzt werden, die Programmierer wollen das ihre Programme funktionieren... Da können die Programmierer ruhig etwas solidarisch sein und mit der Vielfalt von 3(!) Varianten umgehen lernen. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Am 8. August 2008 11:32 schrieb Dirk Stöcker [EMAIL PROTECTED]: On Fri, 8 Aug 2008, Bernd Wurst wrote: Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall vorstellen, wo man es gebrauchen kann. Einbahnstraße entgegen der Richtung des Ways... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kilometrierung von Autobahnen und anderen Strassen
Am 7. August 2008 23:16 schrieb Oliver Koppisch [EMAIL PROTECTED]: Hallo zusammen! Ein Bekannter von mir setzt in seinen Streckenkontrollfahrzeugen (er arbeitet bei einer Autobahnmeisterei) Windows mobile-PDAs mit GPS ein. Er hat mich nun gefragt, ob es möglich wäre dem Fahrer anzuzeigen, auf welchem Autobahnkilometer er sich gerade befindet, und das möglichst genau (ca. 50m). Da kam mir nun der Gedanke, für die Ermittlung des Standorts OSM-Daten einzusetzen. Hallo Oliver. Ich habe letzens auf der A5+A8 einige solche Kilometrierungen getagged. Erstmal nur als name=A8 Kilometer XYZ auf dem Node, damit nichts verlohren geht bis ich ein passendes Tag gefunden habe. (Musste schnell gehen, der Accu war fast alle.) Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, 8 Aug 2008, Stefan Schwan wrote: Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall vorstellen, wo man es gebrauchen kann. Einbahnstraße entgegen der Richtung des Ways... Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen? Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
2008/8/8 Dirk Stöcker [EMAIL PROTECTED]: On Fri, 8 Aug 2008, Stefan Schwan wrote: Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall vorstellen, wo man es gebrauchen kann. Einbahnstraße entgegen der Richtung des Ways... Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen? Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen left oder right... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Hallo. Am Freitag, 8. August 2008 schrieb Dirk Stöcker: Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall vorstellen, wo man es gebrauchen kann. Oneway ist abhängig von der Richtung des Weges. Es gibt aber auch andere Tags, die Abhängig von der Richtung sind. So z.B. das eigentlich obsolete incline, aber auch unabhängig von nem konkreten Beispiel, es wird irgendwelche Dinge geben und daher sind wir froh, dass es möglichkeiten gibt, sowas auch falsch herum eintragen zu können. Außerdem können die Pedanten unter uns ja den Weg absichtlich falsch rum setzen und dann mit oneway=-1 auszeichnen um sich nicht zwischen true, yes oder 1 entscheiden zu müssen. ;-) Gruß, Bernd -- Wir stehen gesellschaftlich auf Stufe 3! Da werden wir zwar verprügelt, aber es gibt einen Grund dafür! - Milhouse, Die Simpsons 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] Datenbankbereinigung
On Fri, 8 Aug 2008, Stefan Schwan wrote: Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall vorstellen, wo man es gebrauchen kann. Einbahnstraße entgegen der Richtung des Ways... Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen? Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen left oder right... Left/right geht auch andersrum. Ist kein also Argument. Die Richtung bergaufwärts auch nicht: a) Erstens ist das kein Standard, also eh nichtssagend. Ich trage die Richtung z.B. so ein, wie ich gefahren bin. b) kann man sowas Höhendaten herausbekommen. c) könnte man das mit elevation-Daten oder Tags eintragen, wenn es denn unbedingt in den Daten sein soll (verschneiden mit Höhenmodell kommt mir allerdings sinnvoller vor). Andere Argumente? Das -1 wird ja sowieso kaum genutzt. Die einzige Anwendung, die ich gesehen habe waren parallele Autobahnen und dort kann man ohne weiteres die zweite Spur umdrehen. Es gibt 1336 Wege mit oneway=-1 in der Datenbank (gegenüber 40 true/yes). http://tagwatch.stoecker.eu/Europe/En/tagstats_oneway_-1.html 7 oneway=-1 liegen auf Knoten, sind also sehr wahrscheinlich Unfug. Ich wette, dass man alle diese 1336 Wege einfach umdrehen kann. Dann kann man diese dämliche -1-Regel abschaffen. Aus meiner Sicht ist diese nämlich eine unsinnige Ausnahme, die die Software nur unnötig verkompliziert. Diese Regel hat auch keine Entsprechung in irgendwelchen anderen OSM-Regeln. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Ich verstehe auch nicht, warum es problematisch ist sich auf ein einheitliches Schema zu einigen. Bisher habe ich oneway=true benutzt, weil ich dachte das wäre am verbreitetsten. Ist es wohl nicht. Wenn jetzt einer ein Skript durch die Datenbank jagt und alles von true nach yes konvertiert und irgendwo abgemacht wird, dass wir yes statt true benutzen, dann hätte ich da als Mapper wirklich überhaupt kein Problem damit. Da fühle ich mich echt in meiner Freiheit nicht eingeschränkt. Das würde mir auch irgendwie Sicherheit geben, wenn überall yes steht, dass dann zumindest das korrekt ist. Das klingt ja hier manchmal so, als wäre es den Mappern unzumutbar einen standartisierten Wahrheitswert zu verwenden. Und wenn man nach 2 Wochen nochmal die Datenbank aufräumt diesbezüglich, finde ich das auch nicht schlimm. Ich weiß schon, dass einige denken, dass es eigentlich auch egal ist, da ja eben alle 3 Varianten gerendert werden und es ja nur 3 sind usw. und das stimmt auch. Es macht das Leben aber oft einfacher, wenn man nur eine hat. Auch für die Mapper. Also wie gesagt, von mir aus gerne vereinheitlichen. Ich stell mich gerne um. Grüße signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, 8 Aug 2008, Bernd Wurst wrote: Oneway ist abhängig von der Richtung des Weges. Es gibt aber auch andere Tags, die Abhängig von der Richtung sind. So z.B. das eigentlich obsolete incline, aber auch unabhängig von nem konkreten Beispiel, es wird irgendwelche Dinge geben und daher sind wir froh, dass es möglichkeiten gibt, sowas auch falsch herum eintragen zu können. Auch wenn ich ansosnten Frederik recht gebe, dass man alles taggen soll wie man will, wäre ich bei oneway=-1 der Meinung die 1336 Wege in der Datenbank mal alle durchzugehen und durch drehen+yes zu ersetzen wenn möglich. Bleibt dann noch ein Grund für -1 übrig, dann soll meinetwegen bleiben. Allerdings sollte mal ein Standard für richtungsbezogene Sachen gefunden werden, damit man es in den Editoren automatisch handhaben kann. Der jetzige Zustand ist leider zu chaotisch und führt deshalb zu Fehlern. Fragen: a) wie sollten richtungsbezogene Tags aussehen: z.B. left:xxx, right:xxx oder xxx:left, xxx:right b) wie sollten richtungsbezogene Values aussehen: z.B. direction_reverseway, direction_way (-1 ist schlecht, weil das vieles bedeuten kann, opposite ist auch nicht ideal, da es sich auf vielen beziehen kann) Hier ist ausnahmsweise mal Standardisierung angesagt, um es automatisieren zu können. Oneway wird wohl leider eine Ausnahme bleiben. Statt oneway=yes wäre nämlich z.B. oneway=direction_way eine bessere Wahl. Dann könnte man es nämlich automatisch erkennen. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, Aug 08, 2008 at 10:51:56AM +0200, Till Maas wrote: Florian Lohoff wrote: Der punkt ist das man z.b. beliebig zeugs da reinpacken koennte um das XML zu zerstoeren was als export da rauskommt. Damit ist das ganze file unbrauchbar ... Im XML file: tag k=created_by v=JOSM/ Jetzt setze ich ein tag created_by=/ Damit wuerde da stehen Bei einem korrekten Umgang mit den Benutzereingaben, käme eher sowas im Export dabei raus: tag k='created_by/' v=/ oder tag k=created_byquot;/ v=/ Ich bin mir jetzt nicht sicher, ob in reinem XML auch quot; verwendet wird. Man braucht die Benutzereingaben dafür aber nicht irgendwie einzuschränken. Du hoffst das jeder der was mit den daten macht das escapen von daten beherrscht. Genau das ist ja mein punkt. Ich wuerde gleich strikte regeln fuer daten in der datenbank erlassen so das sich nicht jeder um die boshaftigkeit der jeweiligen Datentypisten kuemmern muss. Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Hallo, On Thu, Aug 07, 2008 at 07:25:28PM +0200, Frederik Ramm wrote: Niemand hatte je den Anspruch, ein Format zu schaffen. Die Herausforderung bei OSM ist, aus den Daten was gutes zu machen, ohne dass es feste Regeln gibt, weil feste Regeln den Evolutionsprozess zerstoeren, den Mapper zum tumben Datentypisten machen und dem Projekt die Dynamik nehmen, die es zum Leben braucht. Mir ist schon klar, dass es fuer die Nutzer der Daten etwas komplizierter ist, aber die vernuenftige Loesung waere, sich einen normierenden Zwischenlayer auszudenken, der die Daten in das wandelt, was man gerne haette, und NICHT, die Mapper normieren zu wollen. zwingen etwas normiert zu machen wäre ein falscher ansatz. zwischenschicht ist der richtige ansatz, nur sollte man meiner meinung nach die zwischenschicht, nicht beim herauslesen der daten ansetzen, sondern für bekannte sachen beim hineinscheiben in die datenbank oder in periodischen jobs, denn: - beim lesen der daten (zum beispiel: das api ersetzt die werte) würde es bedeuten, daß es immer wieder gemacht werden muß was performance kostet. - wenn jede anwendung eine zwischenschicht implementiert und für die interpretation der werte zuständig ist, bedeutet das eine fehleranfälligkeit und pflegeaufwand. beispiel: für boolean werte (z.B. oneway) kann folgendes in der db stehen: oneway=true oneway=TRUE oneway=trUE oneway=yes oneway=YES oneway=1 usw. jede anwendung muss nun um dieses eine feld zu unterstützen ein regelwerk und normierung der werte durchführen. dies bedeutet aufwand und fehleranfälligkeit für jede anwendung. und wenn dann einer hinkommt und oneway=ja oder oneway=si hinschreibt muß jede anwendung angepasst werden. beim hineinschreiben passiert es nur ein einziges mal und alle die da drauf zugreifen können sich da drauf verlassen, daß die daten sauber sind und eben bei boolen werten wie oneway da z.B. immer true zurückkommt. gruss christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Treffen mit Vermessungsamt Darmstadt
Hallo OSM'ler, ich habe mal das Vermessungsamt Darmstadt [1] gefragt, wie es aussieht mit einer (teilweisen) Datenübernahme aus der offiziellen Karte. Jetzt habe ich eine Antwort erhalten, mit einer Einladung zu einem persönlichen Treffen: Sehr geehrter Herr Stotz, vielen Dank für Ihr Interesse an unseren Daten. Machen Sie bitte mit uns einen Termin aus, damit wir Ihnen unsere Datenbasis vorstellen und Möglichkeiten für die Übernahme in das Open-Street-Projekt diskutieren können. Mit freundlichen Grüßen Harry Korn Wissenschaftsstadt Darmstadt Vermessungsamt Abteilungsleitung Kartographie Daraus ergeben sich nun zwei Fragen: 1. Gibt es im Raum Darmstadt Mapper, die mitkommen wollen, so dass ich mich nicht ganz alleine dort auftreten muss? 2. Was kann man von einem Vermessungsamt erwarten? Ich dachte da an folgende Dinge (mit steigendem Anspruch): * Übernahme von Straßen-/Wegenamen (es gibt immer so viele Wege, die unbeschildert sind) * Nutzung der offiziellen Karte für Vergleiche auf Vollständigkeit * Offizielle Karte als Quelle zum Abpausen Straßen und/oder Gebäude * ... Weitere Vorschläge? Gruß Jan [1] http://www.darmstadt.de/freizeit/stadtplan/index.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Dirk Stöcker wrote: On Fri, 8 Aug 2008, Stefan Schwan wrote: Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall vorstellen, wo man es gebrauchen kann. Einbahnstraße entgegen der Richtung des Ways... Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen? Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen left oder right... Left/right geht auch andersrum. Ist kein also Argument. Die Richtung bergaufwärts auch nicht: a) Erstens ist das kein Standard, also eh nichtssagend. Ich trage die Richtung z.B. so ein, wie ich gefahren bin. b) kann man sowas Höhendaten herausbekommen. c) könnte man das mit elevation-Daten oder Tags eintragen, wenn es denn unbedingt in den Daten sein soll (verschneiden mit Höhenmodell kommt mir allerdings sinnvoller vor). Andere Argumente? Das -1 wird ja sowieso kaum genutzt. Die einzige Anwendung, die ich gesehen habe waren parallele Autobahnen und dort kann man ohne weiteres die zweite Spur umdrehen. Es gibt 1336 Wege mit oneway=-1 in der Datenbank (gegenüber 40 true/yes). http://tagwatch.stoecker.eu/Europe/En/tagstats_oneway_-1.html 7 oneway=-1 liegen auf Knoten, sind also sehr wahrscheinlich Unfug. Ich wette, dass man alle diese 1336 Wege einfach umdrehen kann. Dann kann man diese dämliche -1-Regel abschaffen. Aus meiner Sicht ist diese nämlich eine unsinnige Ausnahme, die die Software nur unnötig verkompliziert. Diese Regel hat auch keine Entsprechung in irgendwelchen anderen OSM-Regeln. Das sollte dennoch jeweils vorbehaltlich einer händischen Prüfung sein. Vielleicht stehen andere Infos ala right/left drin die erst bei einer händischen Prüfung/Änderung auffallen würden und die du bei einem Skriptlauf schlichtweg nicht beachten (somit verfälschen würdest). Regards, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treffen mit Vermessungsamt Darmstadt
Jan Peter Stotz schrieb: Hallo OSM'ler, ich habe mal das Vermessungsamt Darmstadt [1] gefragt, wie es aussieht mit einer (teilweisen) Datenübernahme aus der offiziellen Karte. Jetzt habe ich eine Antwort erhalten, mit einer Einladung zu einem persönlichen Treffen: Sehr geehrter Herr Stotz, vielen Dank für Ihr Interesse an unseren Daten. Machen Sie bitte mit uns einen Termin aus, damit wir Ihnen unsere Datenbasis vorstellen und Möglichkeiten für die Übernahme in das Open-Street-Projekt diskutieren können. Mit freundlichen Grüßen Harry Korn Wissenschaftsstadt Darmstadt Vermessungsamt Abteilungsleitung Kartographie Daraus ergeben sich nun zwei Fragen: 1. Gibt es im Raum Darmstadt Mapper, die mitkommen wollen, so dass ich mich nicht ganz alleine dort auftreten muss? 2. Was kann man von einem Vermessungsamt erwarten? Ich dachte da an folgende Dinge (mit steigendem Anspruch): * Übernahme von Straßen-/Wegenamen (es gibt immer so viele Wege, die unbeschildert sind) * Nutzung der offiziellen Karte für Vergleiche auf Vollständigkeit * Offizielle Karte als Quelle zum Abpausen Straßen und/oder Gebäude * ... Weitere Vorschläge? Luftbilder fände ich noch sehr interessant. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
FreeWorld wrote: Ich verstehe auch nicht, warum es problematisch ist sich auf ein einheitliches Schema zu einigen. Bisher habe ich oneway=true benutzt, weil ich dachte das wäre am verbreitetsten. Ist es wohl nicht. Wenn jetzt einer ein Skript durch die Datenbank jagt und alles von true nach yes konvertiert und irgendwo abgemacht wird, dass wir yes statt true benutzen, dann hätte ich da als Mapper wirklich überhaupt kein Problem damit. Da fühle ich mich echt in meiner Freiheit nicht eingeschränkt. Das würde mir auch irgendwie Sicherheit geben, wenn überall yes steht, dass dann zumindest das korrekt ist. Das klingt ja hier manchmal so, als wäre es den Mappern unzumutbar einen standartisierten Wahrheitswert zu verwenden. Und wenn man nach 2 Wochen nochmal die Datenbank aufräumt diesbezüglich, finde ich das auch nicht schlimm. Ich weiß schon, dass einige denken, dass es eigentlich auch egal ist, da ja eben alle 3 Varianten gerendert werden und es ja nur 3 sind usw. und das stimmt auch. Es macht das Leben aber oft einfacher, wenn man nur eine hat. Auch für die Mapper. Also wie gesagt, von mir aus gerne vereinheitlichen. Ich stell mich gerne um. Grundsätzlich teile ich deine Meinung in diesen speziellen Fällen. Für Infos abseits davon muss jedoch trotzdem noch Platz/Freiheit bleiben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Christian Malolepszy wrote: Hallo, On Thu, Aug 07, 2008 at 07:25:28PM +0200, Frederik Ramm wrote: Niemand hatte je den Anspruch, ein Format zu schaffen. Die Herausforderung bei OSM ist, aus den Daten was gutes zu machen, ohne dass es feste Regeln gibt, weil feste Regeln den Evolutionsprozess zerstoeren, den Mapper zum tumben Datentypisten machen und dem Projekt die Dynamik nehmen, die es zum Leben braucht. Mir ist schon klar, dass es fuer die Nutzer der Daten etwas komplizierter ist, aber die vernuenftige Loesung waere, sich einen normierenden Zwischenlayer auszudenken, der die Daten in das wandelt, was man gerne haette, und NICHT, die Mapper normieren zu wollen. zwingen etwas normiert zu machen wäre ein falscher ansatz. zwischenschicht ist der richtige ansatz, nur sollte man meiner meinung nach die zwischenschicht, nicht beim herauslesen der daten ansetzen, sondern für bekannte sachen beim hineinscheiben in die datenbank oder in periodischen jobs, denn: - beim lesen der daten (zum beispiel: das api ersetzt die werte) würde es bedeuten, daß es immer wieder gemacht werden muß was performance kostet. - wenn jede anwendung eine zwischenschicht implementiert und für die interpretation der werte zuständig ist, bedeutet das eine fehleranfälligkeit und pflegeaufwand. beispiel: für boolean werte (z.B. oneway) kann folgendes in der db stehen: oneway=true oneway=TRUE oneway=trUE oneway=yes oneway=YES oneway=1 usw. jede anwendung muss nun um dieses eine feld zu unterstützen ein regelwerk und normierung der werte durchführen. dies bedeutet aufwand und fehleranfälligkeit für jede anwendung. und wenn dann einer hinkommt und oneway=ja oder oneway=si hinschreibt muß jede anwendung angepasst werden. beim hineinschreiben passiert es nur ein einziges mal und alle die da drauf zugreifen können sich da drauf verlassen, daß die daten sauber sind und eben bei boolen werten wie oneway da z.B. immer true zurückkommt. Mir sind übrigens auch ein paar Tags aufgefallen, die vorne/hinten ein Leerzeichen hatten o.ä. Das wirkt sich in der Praxis dahingehend aus, daß ein name (vielleicht copy-n-paste-error?) nicht gerendert wird und name tadellos funktioniert. Auch hier könnte vielleicht ein trimmen (Leerzeichen, Zeilenumbrüche - unter PHP quasi die Funktion trim()) für keys und ggf. auch values durchaus gute Dienste leisten ohne Daten zu verfälschen. Das macht im übrigen auch der JOSM-Validator, wenn man ihm für jene Fehler nach dem validieren sagt fix. Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, 8 Aug 2008, Stefan Neufeind wrote: Ich wette, dass man alle diese 1336 Wege einfach umdrehen kann. Dann kann man diese dämliche -1-Regel abschaffen. Aus meiner Sicht ist diese nämlich eine unsinnige Ausnahme, die die Software nur unnötig verkompliziert. Diese Regel hat auch keine Entsprechung in irgendwelchen anderen OSM-Regeln. Das sollte dennoch jeweils vorbehaltlich einer händischen Prüfung sein. Vielleicht stehen andere Infos ala right/left drin die erst bei einer händischen Prüfung/Änderung auffallen würden und die du bei einem Skriptlauf schlichtweg nicht beachten (somit verfälschen würdest). Yup. Das versteht sich von selbst. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treffen mit Vermessungsamt Darmstadt
On Fri, 8 Aug 2008, Jan Peter Stotz wrote: 2. Was kann man von einem Vermessungsamt erwarten? Ich dachte da an folgende Dinge (mit steigendem Anspruch): * Übernahme von Straßen-/Wegenamen (es gibt immer so viele Wege, die unbeschildert sind) * Nutzung der offiziellen Karte für Vergleiche auf Vollständigkeit * Offizielle Karte als Quelle zum Abpausen Straßen und/oder Gebäude * ... Ich würde a) OpenStreetMap etwas vorstellen, nicht zu sehr, aber so - dass man sieht was hier geschaffen wird, - die Motivation klar wird, - gezeigt wird, dass auch die Ämter bei allen Werken die nicht-amtlichen Charakter haben auch davon provitieren können b) Die Lizenfrage klären c) Mit dem Mitarbeitern dort gemeinsam ermitteln, wie man sich gegenseitig helfen kann. Immerhin werden das wohl Vermesser von Berufs wegen sein und damit auch nicht ganz unwissend. Die Tatsache, dass sie Dich eingeladen haben zeigt wohl an, dass Du hier einen etwas aufgeschlosseneren Mitarbeitstab treffen wirst. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wechselspiele (was Datenbankbereinigung)
Zitat Dirk Stöcker: Oneway wird wohl leider eine Ausnahme bleiben. Statt oneway=yes wäre nämlich z.B. oneway=direction_way eine bessere Wahl. Dann könnte man es nämlich automatisch erkennen. Was mich zu einer Frage fuehrt, die ich schon immer mal stellen wollte. Keine Ahnung, ob das schon mal Diskussionsgegenstand war: http://www.sierichstrasse.de/ quote Die Sierichstrasse ist z.Zt. die einzige Strasse in Europa, die Tageszeitabhängig ihre Richtung wechselt. Von 4 bis 12 Uhr kann man auf der zweispurigen Straße stadteinwärts fahren, von 12 bis 4 Uhr stadtauswärts. /quote Getaggt ist das momentan oneway=morning to south, evening to North Hat irgendjemand einen besseren Vorschlag? -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Hallo. Am Freitag, 8. August 2008 schrieb Dirk Stöcker: Dann kann man diese dämliche -1-Regel abschaffen. Kann man nicht diese Leute abschaffen, die alles abschaffen wollen? Ach nee, kann man nicht, weil wir ja Freiheit als oberstes Ziel auf unsere Aktionen kleben. Und unter Freiheit verstehe ich, dass nichts abgeschafft oder verboten wird. Es wird definitiv irgenwo irgendwelche richtungsbezogenen Tags geben, die parallel zum oneway existieren können und nicht notwendigerweise in die selbe Richtung zeigen. Ob es das jetzt aktuell schon gibt tut überhaupt nichts zur Sache. Seien wir einfach froh, dass wir eine Möglichkeit haben, boolean rückwärts irgendwie darzustellen. Eine Konvention schon vor dem Einsatz zu haben, schafft uns in diesem Bereich eine Möglichkeit, gar nichts anderes als verstehbaren Wert in das Wiki aufzunehmen. Freu dich doch darüber. Gruß, Bernd -- Gewinn anderer wird fast wie Verlust empfunden. - Wilhelm Busch 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] Datenbankbereinigung
On Fri, 8 Aug 2008, Bernd Wurst wrote: Dann kann man diese dämliche -1-Regel abschaffen. Kann man nicht diese Leute abschaffen, die alles abschaffen wollen? Ach nee, kann man nicht, weil wir ja Freiheit als oberstes Ziel auf unsere Aktionen kleben. Und unter Freiheit verstehe ich, dass nichts abgeschafft oder verboten wird. Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren und abschaffen widerspricht dem nun wirklich nicht. Es wird definitiv irgenwo irgendwelche richtungsbezogenen Tags geben, die parallel zum oneway existieren können und nicht notwendigerweise in die selbe Richtung zeigen. Ob es das jetzt aktuell schon gibt tut überhaupt nichts zur Sache. Seien wir einfach froh, dass wir eine Möglichkeit haben, boolean rückwärts irgendwie darzustellen. Eine Konvention schon vor dem Einsatz zu haben, schafft uns in diesem Bereich eine Möglichkeit, gar nichts anderes als verstehbaren Wert in das Wiki aufzunehmen. Freu dich doch darüber. Wenn es eine vernünftige anwendbare Regel wäre, gern, aber a) Das ist nicht automatisch erkennbar b) Gilt nur für oneway, kann nicht auf andere Tags übertragen werden c) Wird kaum angewendet d) Macht die Software unnötig kompliziert Ich habe nichts gegen Auslegungsfragen. Jeder nach seinem Belieben. Nur diese Richtungsabhängig ist leider nun mal ein Grundkonzept, was in OSM momentan vollkommen ungeklärt ist (und deshalb wohl auch nur bei oneway funktioniert, weil es hier in jeder Software direkt abgebildet wird). Eine generelle Lösung fehlt. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SHAPE Format
Hallo, [EMAIL PROTECTED] schrieb: was ist denn die beste Projektion[1] in dem eine Datei im SHAPE Format vorliegen sollte, damit sie möglichst einfach konvertiert werden kann? Yahoo, Google und die ganzen arbeiten mit Spherical / Web Mercator. Dabei handelt es sich um eine leicht veränderte Version von der normalen Mercator-Projektion (Achtung: nicht UTM!). Da die Yahoo-Tiles bei Potlatch funktionieren, gehe ich stark davon aus, dass OSM auch damit arbeitet. Der offizelle Code ist EPSG:3785. Wenn die Kommune mit ArcGIS arbeitet, könnte ich eine .PRJ-Datei bereitstellen, die ich dafür erstellt habe. Ansonsten lassen sich die Daten mit Proj4 recht einfach aus jedem Format transformieren. In Deutschland gängig sind: EPSG:25832 = ETRS89, UTM, Zone 32 (1.) EPSG:25833 = ETRS89, UTM, Zone 33 (3.) EPSG:4326 = WGS84, geographische Koordinaten (2.) EPSG:4258 = ETRS89, geographische Koordinaten EPSG:31466 = DHDN, GK, 2. Streifen EPSG:31467 = DHDN, GK, 3. Streifen EPSG:31468 = DHDN, GK, 4. Streifen EPSG:31469 = DHDN, GK, 5. Streifen EPSG:2398 = 42/83, GK, 4. Streifen EPSG:2399 = 42/83, GK, 5. Streifen Grüße Tobias Viele Grüße, Christoph [1] http://de.giswiki.net/wiki/Projektion Original-Nachricht Datum: Thu, 07 Aug 2008 21:38:06 +0200 Von: Christoph Brill [EMAIL PROTECTED] An: talk-de@openstreetmap.org Betreff: [Talk-de] SHAPE Format Hallo zusammen, gibt es eine einfache Möglichkeit Daten aus dem SHAPE-Format in OpenStreetMap zu konvertieren? Ich habe von der Stadt Koblenz die Erlaubnis die Stadtteile aus einer Datei in diesem Format in OpenStreetMap zu übernehmen. Nur wie? Vorschläge? Viele Grüße, Christoph ___ 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] Datenbankbereinigung
Am 8. August 2008 12:16 schrieb Dirk Stöcker [EMAIL PROTECTED]: On Fri, 8 Aug 2008, Stefan Schwan wrote: Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall vorstellen, wo man es gebrauchen kann. Einbahnstraße entgegen der Richtung des Ways... Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen? Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen left oder right... Left/right geht auch andersrum. Ist kein also Argument. Wenn man den weg dreht ist das was vorher links war, rechts. Je nachdem wieviele left/right geschichten am weg hängen ist es deutlich einfacher einmal yes/true/1 in -1 zu ändern. Die Richtung bergaufwärts auch nicht: a) Erstens ist das kein Standard, also eh nichtssagend. Ich trage die Richtung z.B. so ein, wie ich gefahren bin. Wenn du den Standard aus deinem eigenen Verhalten definieren willst - bitte schön... Es könnte eventuell helfen, wenn du eine neue Killer-Applikation programmierst die nur auf oneway=yes reagiert - möglicherweise ändern andere dann ihr Verhalten beim Taggen von Oneways, möglicherweise sind ihnen aber dein Programm und deine Probleme eine Disjunktion über 3 Alternativen zu implementieren aber auch sch*** egal. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SHAPE Format
[EMAIL PROTECTED] schrieb: Sorry, ich war gestern abend nicht mehr am Rechner und komme erst Montag wieder an die Daten. Mich würde aber vor allem nicht nur das Ergebnis interessieren sondern wie man dahin kommt. Über shp2osm? Oder kann gpsbabel das sogar? Ich könnte mir vorstellen, dass es sogar auch mit GPSBabel geht, indem man einen Zwischenschritt über KML oder GPX geht. Es gibt sicher eine Menge Wandler, die KML und GPX ins Shapeformat konvertieren können. Habe Dir eine Mail bezüglich meiner Methode geschickt und dass ich eine Veröffentlichung zu erreichen versuche. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wechselspiele
Die Sierichstrasse ist z.Zt. die einzige Strasse in Europa, die Tageszeitabh?ngig ihre Richtung wechselt. Würde ich nicht so sagen :) Da wäre zumindest der Messeschnellweg (A37) in Hannover, der während der CeBIT und der Industriemesse morgens und abends jeweils für ein paar Stunden zu einer 4-spurigen Einbahnstraße in die jeweils benötigte Richtung wird. Alles durch fernbediente Schranken und Lichtzeichenanlagen geregelt. Ich denke, so etwas ist weder zu taggen noch dem schlauesten Routingprogramm zu vermitteln. Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wechselspiele (was Datenbankbereinigung)
Was ist eigentlich mit Straßen die abhängig von der Urhzeit bestimmte Parameter aufweisen? Es gibt Autobahnteilstücke da ist von 7-16 Uhr Tempo 120KMh vorgegeben. Ist ja so zimelich das selbe Problem Michael Buege schrieb: Zitat Dirk Stöcker: Oneway wird wohl leider eine Ausnahme bleiben. Statt oneway=yes wäre nämlich z.B. oneway=direction_way eine bessere Wahl. Dann könnte man es nämlich automatisch erkennen. Was mich zu einer Frage fuehrt, die ich schon immer mal stellen wollte. Keine Ahnung, ob das schon mal Diskussionsgegenstand war: http://www.sierichstrasse.de/ quote Die Sierichstrasse ist z.Zt. die einzige Strasse in Europa, die Tageszeitabhängig ihre Richtung wechselt. Von 4 bis 12 Uhr kann man auf der zweispurigen Straße stadteinwärts fahren, von 12 bis 4 Uhr stadtauswärts. /quote Getaggt ist das momentan oneway=morning to south, evening to North Hat irgendjemand einen besseren Vorschlag? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SHAPE Format
Hi, Der offizelle Code ist EPSG:3785. Wenn die Kommune mit ArcGIS arbeitet, könnte ich eine .PRJ-Datei bereitstellen, die ich dafür erstellt habe. Damit würde ich vorsichtig sein. Da die prj-Datei ja nur in ArcGIS die Daten on-the-fly projiziert. Die eigentlichen Geodaten im Shapefile aber aber im alten System bleiben. Von daher wäre es sicher besser die Shape-daten richtig zu transformieren. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SHAPE Format
Hallo, Alexander Schulze schrieb: Damit würde ich vorsichtig sein. Da die prj-Datei ja nur in ArcGIS die Daten on-the-fly projiziert. Die eigentlichen Geodaten im Shapefile aber aber im alten System bleiben. Data Managment Tools = Projections and Translations = Feature = Project. Von daher wäre es sicher besser die Shape-daten richtig zu transformieren. Siehe oben :-) Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SHAPE Format
Hi, Data Managment Tools = Projections and Translations = Feature = Project. das is mir schon klar. Ich wollte nur drauf hinweisen, da ich es des öfteren erlebe, dass es genau dabei zu Mißverständnissen kommt (sicher nicht bei dir, aber nicht jeder hier kommt ja aus dem GIS bzw. Vermessungsbereich). Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, 8 Aug 2008, Stefan Schwan wrote: Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall vorstellen, wo man es gebrauchen kann. Einbahnstraße entgegen der Richtung des Ways... Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen? Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen left oder right... Left/right geht auch andersrum. Ist kein also Argument. Wenn man den weg dreht ist das was vorher links war, rechts. Je nachdem wieviele left/right geschichten am weg hängen ist es deutlich einfacher einmal yes/true/1 in -1 zu ändern. Das macht z.B. JOSM mittlerweile automatisch. Nur eben mehr durch Raten. Ein vernünftiger einheitlicher Standard würde hier helfen. Und darum geht es eben. Nicht um -1 oder nicht, sondern darum, dass dies eben nur mit oneway klappt und nicht allgemein. Die Richtung bergaufwärts auch nicht: a) Erstens ist das kein Standard, also eh nichtssagend. Ich trage die Richtung z.B. so ein, wie ich gefahren bin. Wenn du den Standard aus deinem eigenen Verhalten definieren willst - bitte schön... a) Nicht dokumentiert b) Manche Mapper... c) Nicht an den Daten zu erkennen -- Kein Standard. Was hat das mit meinem Verhalten zu tun? Es könnte eventuell helfen, wenn du eine neue Killer-Applikation programmierst die nur auf oneway=yes reagiert - möglicherweise ändern andere dann ihr Verhalten beim Taggen von Oneways, möglicherweise sind ihnen aber dein Programm und deine Probleme eine Disjunktion über 3 Alternativen zu implementieren aber auch sch*** egal. Kann es sein, daß Du bewußt versuchst alles falsch zu verstehen, damit Du andere Meinungen als blöd darstellen kannst? In diesem Fall war das meine letzte Antwort auf Deine Posts. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SHAPE Format
Hallo, Alexander Schulze schrieb: Data Managment Tools = Projections and Translations = Feature = Project. das is mir schon klar. Ich wollte nur drauf hinweisen, da ich es des öfteren erlebe, dass es genau dabei zu Mißverständnissen kommt (sicher nicht bei dir, aber nicht jeder hier kommt ja aus dem GIS bzw. Vermessungsbereich). Ja, aber solche Leute haben theoretisch auch gar keinen Zugang zu ArcGIS, Manifold Co. und die Leute die Zugang dazu haben, sollten hoffentlich wissen, was sie damit machen ;-) Laut einigen Definition ist JOSM übrigens auch ein GIS, allerdings halt ein sehr kleines :-) Grüße Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] SHAPE Format
Tobias Wendorff schrieb: Es gibt sicher eine Menge Wandler, die KML und GPX ins Shapeformat konvertieren können. Woops ... ich meinte genau andersrum: http://www.obviously.com/gis/shp2text/ Ich probiere es mal aus und schreibe ggf. ein HowTo! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, 8 Aug 2008, Frederik Ramm wrote: Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren und abschaffen widerspricht dem nun wirklich nicht. Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind Strassenlaternen Unfug? Parkbaenke? Flugrouten? Deswegen: a) Alle momentanen -1 anschauen (knapp 1300) b) Wenn drehbar dann durch oneway=yes ersetzen. c) Wenn -1 nachher weg ist, dann wars Unfug. Ist doch einfach :-) Alternativ - Bessere allgemeingültige Lösung finden und Datenbestand konvertieren. Ich hatte ja mal folgende Idee: Jedes Tag kann zu xxx:+, xxx:- (oder +:xxx, -:xxx) werden. + bedeutet dabei in Richtung Weg. - entgegengesetzt des Weges. Das wäre allgemeingültig (ist dafür nicht unbedingt sehr intuitiv). Passt auch gut mit der :left-, :right-Variante zusammen. oneway=yes wäre dann korrekt oneway:+=yes, oneway=-1 wäre dann korrektr oneway:-=yes Als Legacy-Lösung könnte man oneway in der bisherigen Form weiter unterstützen (statt mit einem Schlag 40 Einträge zu ändern). Egal wie es wird, wir brauchen einen Standard dafür, sonst haben wir lauter verschiedene Lösungen, die man softwaretechnisch dann gar nicht mehr in den Griff bekommt. Allgemeingültig -- Klappt auch für maxspeed, access, was-weiß-ich-alles. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Friday 08 August 2008 14:41:40 Frederik Ramm wrote: Hallo, Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren und abschaffen widerspricht dem nun wirklich nicht. Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind Strassenlaternen Unfug? Parkbaenke? Flugrouten? Nun ja, aus dieser Argumentation könnte man auch ableiten, dass jede Änderung an von anderen eingepflegten Daten einer ausführlichen Diskussion zwischen den Beteiligten zur Voraussetzung hat. Und ich glaube, dass dies niemand hier wirklich befürworten würde. Keine Frage, Kommunikation muss sein, aber nicht vor dem Ändern jeglicher Bestandsdaten. Mir ist es aktuell egal, ob eine Einbahnstrasse nur mit einem Tag oder mit mehreren beschrieben werden kann. Aber auch nur, da ich aktuell nur Mapper bin, und keine Anwendung schreibe. Ich glaube allerdings, dass viele Mapper nicht verärgert wären, wenn man ihre Definition einer Einbahnstrasse ändern würde. Mir ist es jetzt schon mehrfach passiert, dass mich Neulinge, welche ich anschrieb, um evtl. Hilfe beim Einstieg in OSM anzubieten, mich fragten, Was denn nun die richtige Variante des Taggens ist, und ob es Vor- oder Nachteile zwischen den Varianten geben würde? Daraus leite ich ab, dass die entstandene Vielfalt auch verwirrend wirken kann. Bei der ganzen Diskussion könnte ich mir sehr gut vorstellen, dass daraus durchaus ein Edit-War entwickeln könnte. Vielleicht wäre ein Tag clever, welches man anbringen könnte, um den Wunsch mitzuteilen, dass dieser oder jener key nicht von Skripten bearbeitet werden soll. So in etwa für das Einbahnstrassen-Problem noscript;oneway. Ich persönlich würde von soetwas nicht Gebrauch machen wollen, aber vielleicht kann es ja die eine oder andere Diskussion nach Skriptläufen erübrigen. ;-) Gruss Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Validator
Am Fri, 8 Aug 2008 08:44:40 +0200 (CEST) schrieb Dirk Stöcker [EMAIL PROTECTED]: Außerdem meckert der Validator unbenannte Straßen an, die aber in einer Relation mit name-Tag stehen. (Wenn ich Sie einzeln Benenne, meckert er doppelte Namen an!) Was meckert er an, wenn Du die Straßen benennst? So ein Test ist gar nicht drin. Gleiche Namen meckert er nur bei Knoten an. Hast Du vielleicht nicht nur die Straße, sondern auch die Knotenpunkte der Straße benannt? Die doppelten Namen habe ich gelöscht. Und nun kann ich das nicht mehr reproduzieren. Vermutlich hast du recht. Grüße, Michael -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Bernd Wurst schrieb: Hallo. Am Freitag, 8. August 2008 schrieb Dirk Stöcker: Dann kann man diese dämliche -1-Regel abschaffen. Kann man nicht diese Leute abschaffen, die alles abschaffen wollen? Ach nee, kann man nicht, weil wir ja Freiheit als oberstes Ziel auf unsere Aktionen kleben. Und unter Freiheit verstehe ich, dass nichts abgeschafft oder verboten wird. Es wird definitiv irgenwo irgendwelche richtungsbezogenen Tags geben, die parallel zum oneway existieren können und nicht notwendigerweise in die selbe Richtung zeigen. Ob es das jetzt aktuell schon gibt tut überhaupt nichts zur Sache. Seien wir einfach froh, dass wir eine Möglichkeit haben, boolean rückwärts irgendwie darzustellen. Eine Konvention schon vor dem Einsatz zu haben, schafft uns in diesem Bereich eine Möglichkeit, gar nichts anderes als verstehbaren Wert in das Wiki aufzunehmen. Freu dich doch darüber. Gruß, Bernd Was ist denn ein boolean rückwärts? Ist dann tunnel=-1 ne Brücke? Oder building=-1 ne Grube? Ich denke tatsächlich diesen -1 Wert braucht man in dem Zusammenhang eines boolean nicht. Nennt mir bitte nur ein Einziges, wegen mir frei konstruiertes Szenario, wo dieser -1 Wert irgendetwas verbessert. Grüße signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, Aug 08, 2008 at 01:45:09PM +0200, Bernd Wurst wrote: Hallo. Am Freitag, 8. August 2008 schrieb Florian Lohoff: Du hoffst das jeder der was mit den daten macht das escapen von daten beherrscht. Davon muss man ausgehen, ja. Man macht ja auch keine Löcher hinten in die Hosen nur weil evtl. manche Leute zu blöd sind die vor dem Kacken auszuziehen. Ne - Aber Gurtwarner weil die leute vergessen sie anzulegen. Nicht alles was hinkt ist ein vergleich ... Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Hallo Dirk On Friday 08 August 2008 14:57:53 Dirk Stöcker wrote: Ich hatte ja mal folgende Idee: Jedes Tag kann zu xxx:+, xxx:- (oder +:xxx, -:xxx) werden. + bedeutet dabei in Richtung Weg. - entgegengesetzt des Weges. Das wäre allgemeingültig (ist dafür nicht unbedingt sehr intuitiv). Passt auch gut mit der :left-, :right-Variante zusammen. Bzgl. der Intuitivität muss ich dir leider zustimmen. Das wäre wohl zu gebrauchen, wenn die Editoren das kapseln würden. oneway=yes wäre dann korrekt oneway:+=yes, oneway=-1 wäre dann korrektr oneway:-=yes Als Legacy-Lösung könnte man oneway in der bisherigen Form weiter unterstützen (statt mit einem Schlag 40 Einträge zu ändern). Egal wie es wird, wir brauchen einen Standard dafür, sonst haben wir lauter verschiedene Lösungen, die man softwaretechnisch dann gar nicht mehr in den Griff bekommt. Allgemeingültig -- Klappt auch für maxspeed, access, was-weiß-ich-alles. Das ist insofern allgemeingültig, so lange du für die Richtungsfahrbahnen identische Beschilderungen hast, was bei einer Spur pro Richtung zwangsweise gegeben ist, sieht bei mehreren Fahrspuren pro Richtung schon wieder ganz anders aus. Ich sinne auch schon einige Zeit über ein konsistentes, umfassendes und trotzdem einfaches Schema bzgl. Richungsrelevantem Taggen nach. Eingefallen ist mir da schon vieles, allerdings habe ich es immer wieder als unpraktikabel verwerfen müssen. Vielleicht lässt sich so etwas wirklich nur durch optische Unterstützung der Editoren einfach halten. Gruss Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, Aug 08, 2008 at 02:57:53PM +0200, Dirk Stöcker wrote: Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren und abschaffen widerspricht dem nun wirklich nicht. Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind Strassenlaternen Unfug? Parkbaenke? Flugrouten? Deswegen: a) Alle momentanen -1 anschauen (knapp 1300) b) Wenn drehbar dann durch oneway=yes ersetzen. c) Wenn -1 nachher weg ist, dann wars Unfug. Ist doch einfach :-) bei den meisten Wegen wird es so sein wie hier in den drei folgenden Beispielen. es spricht eigentlich nichts dagegen sie zu drehen, auch in den Nodes sind keine Tags außer tag k=created_by v=JOSM/. Der Erfasser hat sie von links nach rechts gezeichnet, die Einbahnstraße verläuft aber andersherum und da es -1 gibt macht man sich die Arbeit mit dem drehen der Wege nicht. Da bei dem Projekt jeder die Daten ändern kann, so wie er meint, daß es richtig ist $ ./oneway_aufraeumen.sh ;- Keine Panik, das script gibt es noch nicht. PS: wer sagt mir, daß ich die Namen von links nach rechts schreiben soll und nicht umgekehrt? - Irrgarten = netragrrI Oder wie wärs mit highway=false für Wälder? Irgendeiner baut es schon irgendwann in den Render ein ;-) was interessieren mich die Probleme anderer, wenn ich es so erfassen will, dann mache ich es auch! In dem Sinne: Wir sind eine Community, die miteinander lebt. Man kann sich auf Normen und Vorgehensweisen verständigen. Strenge Prüfungen und Verbote an der API nützen genausowenig wie Leute die alles anders machen. Hauptsache sie haben ihr -1! Gruß Christian way id=4274375 timestamp=2008-03-22T08:21:35Z user= nd ref=25161088/ nd ref=25600127/ tag k=highway v=unclassified/ tag k=created_by v=JOSM/ tag k=maxspeed v=50/ tag k=name v=Irrgarten/ tag k=oneway v=-1/ /way way id=7979268 timestamp=2007-11-01T10:12:31Z user= nd ref=59598831/ nd ref=59598833/ nd ref=59598834/ nd ref=59598826/ tag k=created_by v=JOSM/ tag k=name v=Goldener Winkel/ tag k=highway v=residential/ tag k=oneway v=-1/ /way way id=7995375 timestamp=2008-06-12T15:01:39Z user= nd ref=34042690/ nd ref=25761178/ tag k=postal_code v=30159/ tag k=name v=Ebhardtstraße/ tag k=created_by v=Potlatch 0.9c/ tag k=highway v=residential/ tag k=oneway v=-1/ /way ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Hallo, Nun ja, aus dieser Argumentation könnte man auch ableiten, dass jede Änderung an von anderen eingepflegten Daten einer ausführlichen Diskussion zwischen den Beteiligten zur Voraussetzung hat. Und ich glaube, dass dies niemand hier wirklich befürworten würde. Keine Frage, Kommunikation muss sein, aber nicht vor dem Ändern jeglicher Bestandsdaten. Das Aendern von Bestandsdaten ist eine Sache. Zumeist geht es ja aber einher mit dem Verlangen: Jetzt wo ich erstmal alle X-Tags aufgeraeumt hab, soll bitte niemand mehr ein falsches X-Tag anlegen duerfen. Und da sehe ich das Problem - das wird nicht gehen, weder technisch (weil die Regeln alle in die API kodiert werden muessten) noch politisch (wegen der wer entscheidet was erlaubt ist-Frage). Wen man aber ohnehin immer davon ausgehen muss, dass sich im Datenbestand eine Anzahl von unaufgeraeumten Tags befinden, die seit dem letzten Aufraeumen entstanden sind - wozu dann noch aufraeumen? Ein Renderer, der mit oneway=true und oneway=yes umgehen kann, dem ist es doch egal, ob er 999 mal true und 1 mal yes hat oder 500 mal das eine und 500 mal das andre. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treffen mit Vermessungsamt Darmstadt
-Ursprüngliche Nachricht- Von: Dirk Stöcker [EMAIL PROTECTED] An: talk-de@openstreetmap.org Gesendet: Freitag, 8. August 2008 13:17 Betreff: Re: [Talk-de] Treffen mit Vermessungsamt Darmstadt Du könntest noch nach Dingen fragen, die nicht mittels GPS zu erfassen sind. 1. Wir haben ja mitlerweile schon ein Tag für Pipelines. Du könntest ja mal fragen, ob die uns Daten über verlegte Gas-/Wasserleitungen geben können. Nicht daß das irgendwer brauchen würde...wäre nur mal ganz interessant zu sehen was da so alles in unserem Vorgarten verlegt ist. :-) 2. Wälder haben oft Namen. Auch wenn die meistens außer dem Förster keiner kennt. Könnte auch interessant sein die zu erfahren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem bei Aschaffenburg
Stefan Leiner schrieb: Hallo Zusammen, anscheinend ist in Aschaffenburg etwas ziemlich schief gegangen. Der Link http://www.openstreetmap.org/?lat=49.9802lon=9.1482zoom=13layers=B00TTF zeigt, das hier wohl jemandem ein Fehler unterlaufen ist. Ein ganzes Bündel Straßen Richtung Nordosten verzogen. Wie bekommt man denn raus wer das verbrochen hat? Ja, da bin ich grad dran... War jemand namens Jessica M, ich reverte das ganze soweit es die OSMXAPI hergibt. Leider wurden da schon einige Nodes gefixt, also manuell ungefähr da hingezogen, wo sie mal waren, deswegen bekomme ich die nicht mehr in der OSMXAPI-Abfrage aber wartet mal 2-3 Tage dann hab ich das gerichtet. Evtl. wird das Script so gut, dass man das veröffentlichen kann ;) Jannis 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] Datenbankbereinigung
Am 8. August 2008 14:48 schrieb Dirk Stöcker [EMAIL PROTECTED]: On Fri, 8 Aug 2008, Stefan Schwan wrote: Das macht z.B. JOSM mittlerweile automatisch. Nur eben mehr durch Raten. Ein vernünftiger einheitlicher Standard würde hier helfen. Und darum geht es eben. Nicht um -1 oder nicht, sondern darum, dass dies eben nur mit oneway klappt und nicht allgemein. Außer Flüssen fällt mir keine andere Situation ein, wo die Richtung überhaupt eine Rolle spielt.. a) Nicht dokumentiert b) Manche Mapper... c) Nicht an den Daten zu erkennen -- Kein Standard. Was hat das mit meinem Verhalten zu tun? Das es eben keinen Standards gibt, sondern nur Konventionen. Nur weil du etwas als vermeintlichen Standard annimmst, heißt das noch lange nicht, das sich andere Mapper danach richten müssten, oder das es automatisierte Berichtigungen geben sollte - insbesondere, wenn es defacto nicht falsch ist. Kann es sein, daß Du bewußt versuchst alles falsch zu verstehen, damit Du andere Meinungen als blöd darstellen kannst? In diesem Fall war das meine letzte Antwort auf Deine Posts. Keineswegs - ich wundere mich nur darüber, das du sämtliche Vorschläge wie man mit sowas umgeht gekonnt ignorierst und weiterhin darauf beharrst, das es hier ein Problem gibt wo keins ist: Es ist nämlich softwaremäßig überhaupt kein Problem eine ODER Anweisung aufzunehmen. Wir reden ja nicht von hunderten sondern überschaubaren 3 oder 4 Möglichkeiten. Gruß Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri Aug 08, 2008 at 02:4140PM +0200, Frederik Ramm wrote: Hallo, Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren und abschaffen widerspricht dem nun wirklich nicht. Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind Strassenlaternen Unfug? Parkbaenke? Flugrouten? Lasst uns doch bitte mal einen Schritt zuruecktreten. Es geht naemlich nicht darum, ob nun TRUE, true, YES, yes oder 1 in der Datenbank steht, es geht auch nicht darum, dass die Freiheit eingeschraenkt werden soll und sich irgendjemand anmasst, allgemeinverbindlich etwas als Unfug zu deklarieren. Wir wollen mit Openstreetmap etwas erreichen, naemlich Kartendaten in einer Art und Weise zur Verfuegung stellen, dass sie von der Allgemeinheit ohne grosse Einschraenkungen benutzt werden koennen. Benutzt werden koennen setzt aber voraus, dass die Daten benutzbar sind, insbesondere eben, dass die Daten in einem definierten Format abrufbar sind, parseable sind. Warum taggen die meisten Leute Wege mit einem 'highway'-Tag und einigen bestimmten Werten? Weil sie ihre erfassten Daten gerne gerendert sehen wollen und sich so einschraenken. Das Tagging-Schema, das im Wiki beschrieben ist und weiterentwickelt ist, fasse ich persoenlich als 'Best (current) practise' auf, und es schraenkt auch nicht ein. Jeder kann jederzeit andere Tags und Werte benutzen - und er bekommt sie auch gerendert, wenn er sich selbst nen Renderer dafuer anpasst. Ob aber nun yes, no oder true, false, 0, 1 und -1 fuer booleans verwendet werden - irgendwie finde ich es laecherlich. Haben wir nichts besseres zu tun, als darueber zu streiten? In der Zeit, die hier mit diskutieren verbracht worden ist haette man sicherlich einiges an Code schreiben koennen, der mit diesem Problem umgehen kann. -- Michael Bergbauer [EMAIL PROTECTED] Munich, Germany ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [tagging] Feature Proposal - RFC - (baby hatch)
Please have a look at the following proposal: Baby hatch (de: Babyklappe) http://wiki.openstreetmap.org/index.php/Proposed_features/baby_hatch Thanks. Lulu-Ann -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/6169196 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Michael Bergbauer schrieb: Ob aber nun yes, no oder true, false, 0, 1 und -1 fuer booleans verwendet werden - irgendwie finde ich es laecherlich. Haben wir nichts besseres zu tun, als darueber zu streiten? In der Zeit, die hier mit diskutieren verbracht worden ist haette man sicherlich einiges an Code schreiben koennen, der mit diesem Problem umgehen kann. [x] habe ich (für meine Scripts) gemacht: Sobald in einem Datensatz Dinge auftauchen, die nicht ja / nein / 1 / 0 / true / false / -1 entsprechen, werde ich gefragt, wie die Sonderfälle gehandhabt werden sollen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zäune (was: abgesperrter Privatwald (was: Zäune / Privatwald))
Hi, mich würde interessieren, wie der Konsens z.Zt. aussieht. Wie hierbei am besten verfahren wird, scheint nämlich noch etwas unklar zu sein. Ich plädiere für eine konsequent topographische Herangehensweise, d.h. ich sehe einen Zaun, also nehme ich diesen als solchen auf. Mehr nicht. Der passende Objekttyp wäre wohl 'Weg'. Die Map-Features-Seite sieht noch keine Tags vor. Wie wäre fence=deer|barbed_wire|... [1]? Etwaige gewagten und nicht nachvollziehbaren Interpretationen der umzäunten Flächen, wie im Beispiel das Besitzverhältnis des Waldes, sind irrelevant. Viel versprechend ist oftmals auch die Orientierung an der Kartengrafik bzw. den Signaturen der amtlichen Topographischen Karte 1:25' bzw. 1:50'. Nicht zum Thema gehörend (Betreff ändern!) ist meine Bitte an alle OSMper im Feld, eine gewissen Sensibilität für Geländeformen zu entwickeln. Damit aus unseren Daten mal eine gute Karte wird, gilt es, künftig auch weniger offensichtliche Dinge wie etwa die Böschungskante einer sich höhenfrei kreuzenden Straße aufzunehmen, bevor man aus Gründen der Unterbeschäftigung über wenig sinnvolle Dinge wie bspw. die Flächenhaftigkeit von Straßenobjekten nachdenkt. Auch hierfür dient als Inspiration die Legende amtlicher Karten, im Beispiel[2] 'Geländekante' unter dem Abschnitt 'Relief'. k127 [1] http://de.wikipedia.org/wiki/Zaun#Verschiedene_Zauntypen [2] http://www.laiv-mv.de/land-mv/LAiV_prod/LAiV/AfGVK/_faltblaetter/FB_Zeichenerkl.pdf ; wire fence [FENC] Strength=1 Armor=none TechLevel=2 Sight=0 Owner=soviet Cost=25 Points=1 Repairable=false Adjacent=1 Am Mon, 28 Jul 2008 00:34:25 +0200 hat Johann H. Addicks [EMAIL PROTECTED] geschrieben: Philipp Klaus Krause schrieb: Nun ja, als Privatwald bzeichnet man Wald im Privatbesitz. Nahezu aller ist genauso durchwanderbar wie Staats- und Gemeindewald. Zäune kenne ich eigentlich nur bei Aufforstungen damit das Wild nicht die Bäume abfrißt. Wo es wirklich fette Zäune rundherum gibt, sollte man das in der Karte nicht einfach als Privatwald bezeichnen, um Verwechslungen zu vermeiden. O.k. Dann anders gefragt: Wie kann ich auch für Fußgänger nicht zugänglichen Forst taggen? Zumindest ich habe highway=gate immer mit keine Autos und fenced=yes mit Naja, irgendein Überstieg wird schon da sein, wenn denn sogar ein Weg dahinter eingezeichnet ist übersetzt. Reicht da ein access=no? Wenn ja, wie wird das gerendert? -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Michael Buege schrieb: Zitat Torsten Leistikow: Wir schrecken aber auch genug Leute ab, weil OSM heute doch ziemlich unuebersichtlich ist. Woher hast Du diese Informationen? Kennst Du Leute, die sich haben abschreckenlassen und wie haben sie das konkret begruendet? Wie viele Leute waren das bei Dir bis jetzt? 100% der Leute, die ich zur Mitarbeit motivieren konnte, haben sich darueber beschwert, wie durcheinander bei OSM alles ist und das man nirgendwo eindeutige Antworten oder Vorgehensweisen bekommt. N = 1. Was ist das Beste? Wer bestimmt, was das Beste ist und was sind die Massstaebe? Wie kann man das festlegen, welche Prozedere sind notwendig und wer bestimmt wiederum, welches der richtige Weg ist, um solche Festlegungen zu treffen? Und welches sind die Qualifikationsbedingungen fuer Leute, die das machen? Wie waere es mit einer guten alten Abstimmungsprozedur. Es gibt ja auch schon einen Weg, wie neue Features eigentlich eingefuehrt werden sollten. Bei irgendwelchen Normierungsgremien gibt es ja genug vorbild, wie so etwas laufen sollte (und auch das eine oder andere gegenbeispiel). Zwangbereinigung? Wir reden doch immer noch ueber _Open_ streetmap, oder? Ich habe Open immer im Sinne von Frei zur Nutzung verstanden. Voellig unreglementiert ist eine ander Sache. Bei Open-Source-Software oder -Hardware erwarte ich ja auch, dass sie sich an die verschiedenen Normen und Standards haelt. PS: Es waere mal interessant zu wissen, wieviele Leute bei OSM um des Mappens-Willen mitmachen, und wieviele staerker am Ergebniss bzw. Nutzen interessiert sind. Was ist mit Mischformen? Da ich den Komparativ verwendet habe, ist theoretisch nur eine einzige Mischform denkbar: Diejenigen, denen beide Sichtweisen voellig gleich sind :-) Hier in den Diskussionen prallen doch immer wieder beide Sichtweisen aufeinander. Findest Du das nicht normal? Normal schon, aber nicht unbedingt foerderlich. Bei dem Hinweis auf Open ist mir aber was ganz anderes eingefallen: Wenn ich, oder jemand anderes eine automatische Bereinigung haben will, so kann er das ja einfach machen. Die Lizenz gestattet es ja gerade, dass man die Daten nach seinen Wuenschen veraendern kann. Es steht natuerlich auch jedem frei, einen Bot anzuschmeissen, der die Werte nach Belieben (oder auch zufaellig) wieder vertauscht. Ist die OSM-Welt ohne Regeln nicht etwas Wunderbares? Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, Aug 08, 2008 at 04:50:07PM +0200, Torsten Leistikow wrote: Es steht natuerlich auch jedem frei, einen Bot anzuschmeissen, der die Werte nach Belieben (oder auch zufaellig) wieder vertauscht. Ist die OSM-Welt ohne Regeln nicht etwas Wunderbares? :-) meine Meinung . und weil jeder so darf wie er will und keiner niemanden dran hindert, werden ab morgen alle namen rückwärts geschrieben *lol* das ist auch der grund wieso mittlerweile bei wikipedia nicht alles von jedem bearbeitet werden kann schönen abend noch christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treffen mit Vermessungsamt Darmstadt
2. Was kann man von einem Vermessungsamt erwarten? Geodaten, wenn man ihm auch einen eigenen Vorteil aufzeigt. * Übernahme von Straßen-/Wegenamen (es gibt immer so viele Wege, die unbeschildert sind) Das Vermessungsamt verfügt über wesentlich wertvollere Informationen als Straßennamen, nämlich die Straßen selbst. * Nutzung der offiziellen Karte für Vergleiche auf Vollständigkeit * Offizielle Karte als Quelle zum Abpausen Straßen und/oder Gebäude Gut, aber warum so umständlich? Versuche doch, auszuhandeln, dass wir Daten in Vektorform erhalten. Das spart ein Menge Arbeit, ist exakt und dürfte Verwertungsrechtlich keinen allzu großen Unterschied machen. Sprich bitte -- damit OSM glaubwürdig bleibt -- die Daten über verlegte Gas-/Wasserleitungen nicht an. Wozu sollte das gut sein. Diese Daten wären höchstwahrscheinlich auch eher bei den Stadtwerken zu finden. Was allerdings die Dinge betrifft, die nicht mittels GPS zu erfassen sind, so stimme ich grundsätzlich mit Christian überein. Auch wären -- um mich zu wiederholen -- Geländedaten interessant. k127 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder Vermessungsamt Ba-Wü
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bernd Wurst wrote, on 07.08.2008 10:37: | Hallo. | | Am Donnerstag, 7. August 2008 schrieb Bernd Wurst: | Kann mir jemand sagen, wie man einen | WMS-Server ansteuert, damit ich mal manuell die Fehlermeldung provozieren | kann? Sieh Dir mal WMSGrabber.java vom WMS-Plugin an. Dort werden die Parameter bbox, width und height an die Basis-URL angehängt, die in den Plugin-Einstellungen konfiguriert ist. Beispiel für Bayern: http://www.geodaten.bayern.de/ogc/getogc.cgi?SERVICE=WMSVERSION=1.1.1LAYERS=DOPsrs=EPSG:4326format=image/pngrequest=GetMapbbox=10.7525169,47.6441657,10.8392587,47.7277723width=913height=880 Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkicdmkACgkQnMz9fgzDSqeDlQCeK5z1tqxEfjdVT1MgkciOcN5H WRkAn09H4OBOkTuDDe7D1jx9zKDC4EL8 =Hh5V -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wechselspiele (was Datenbankbereinigung)
Frederik Granna schrieb: Was ist eigentlich mit Straßen die abhängig von der Urhzeit bestimmte Parameter aufweisen? Es gibt Autobahnteilstücke da ist von 7-16 Uhr Tempo 120KMh vorgegeben. Ich haette da in Bad Homburg eine Strasse, die von 22-6 eine Sackgasse ist... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kilometrierung von Autobahnen und anderen Strassen
Dieter TD schrieb: Die Frage steht wirklich: Wie sinnvoll taggen?? Es trifft ja nicht nur Straßen, sondern beispielsweise auch Bahnstrecken (km-Angaben) oder Grenzen (Grenzzeichen). Ich habe bislang immer dem entsprechenden Node einen Namen (bspw. GZ III/12/24) gegeben. Lösung ist das natürlich keine. Hat jemand eine bessere Idee?? Leider auch nicht wirklich. Nur führt Dein Weg evtl. zum Datenschrott, da es nicht jeder Mapper etwas mit den Tags anfangen kann und dann schnell, ohne Bedacht, aus welchen Gründen auch immer, dieselben verschiebt oder gar löscht. Diese Gefahr ist mit extra Nodes bei weitem niedriger. Generell dürften Extra-, Super- und Sonder-Tags viel schneller den Datenbarbaren und Vandalen anheimfallen als dem Ersteller lieb sein dürfte. Immerhin haben wir es mit einer großen Community zu tun in der jeder alles ändern kann, darf und soll. Nur Tags die auch ein durchschnittlicher Mapper versteht dürften auf Dauer Freude machen. Gruß Thorsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wechselspiele (was Datenbankbereinigung)
Michael Buege schrieb: Die Sierichstrasse ist z.Zt. die einzige Strasse in Europa, die Tageszeitabhängig ihre Richtung wechselt. Von 4 bis 12 Uhr kann man auf der zweispurigen Straße stadteinwärts fahren, von 12 bis 4 Uhr stadtauswärts. Aha. Kitzbühel liegt also nach Hamburger Meinung nicht in Europa. CU Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
Hallo, Nein, nach dem Motto: Wenn es noch nichts gibt was genau das darstellt was ich will, dann nehm ich was ähnliches oder was ganz anderes. Da sind wir uns ja einig, aber es ging darum ob man statt yes auch true verwenden kann. Und wenn man da Vorgaben macht werden wir nicht zu: tumben Datentypisten Tun wir doch. Die Mail die ich zitierte war ja auch nicht von Dir Ich versteh dein Problem nicht. Es ging nur darum, daß ich die große Angst vor Regeln die Frederik so deutlich machte: weil feste Regeln den Evolutionsprozess zerstoeren, den Mapper zum tumben Datentypisten machen und dem Projekt die Dynamik nehmen, die es zum Leben braucht. nicht nachvollziehen kann. Da ich in meiner Freizeit mappe, möchte ich eigentlich erstmal dass mir das Leben nicht schwer gemacht wird. Das gleiche gilt aber auch für die Programmierer. Wir solten eine Methode finden wie es für alle einfacher wird. Derzeit benutzt man entweder Presets oder tippt einfach ein, ist man sich nicht sicher schaut man ins Wiki, eher aufwendig. Warum kann man die Map-Features- Seite nicht in eine maschinenlesbare Form bringen, so daß alle Editoren sie lesen können. Sie könnten dann einfach anzeigen ob die Eingabe richtig oder falsch (besser unbekannt) ist. Genau so wie eine Textverarbeitung ihr unbekannte Wörter unterstreicht. Bei Josm gibt es ja schon die Autovervollständigung, die benutzt aber wenn ich es richtig sehe alles was gerade geladen ist als Vorlage. Gibt es also in dem Gebiet noch kein cycleway=opposite hilft mir JOSM da nicht zu wissen ob es mit einem oder 2 p geschrieben wird. Hier könnte es z.B. alles was in der Map-Features-Seite steht mit einem grünen Kreis und alles was irgendwo im geladenen Bereich ist mit einem gelben Kreis markieren. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbankbereinigung
On Fri, Aug 08, 2008 at 05:38:52PM +0200, Stefan Neufeind wrote: :-) meine Meinung . und weil jeder so darf wie er will und keiner niemanden dran hindert, werden ab morgen alle namen rückwärts geschrieben *lol* Aber dann auch brav mit name:lefttoright=... oder name:reverse oder name:andersherum taggen :-) nööö, entweder schreibe ich ein - davor, oder aber shit egal und warte, bis es einer in den renderer implementiert gruß christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Richtungsbezug (was: Datenbankbereinigung)
On Fri, 8 Aug 2008, Frederik Ramm wrote: Wen man aber ohnehin immer davon ausgehen muss, dass sich im Datenbestand eine Anzahl von unaufgeraeumten Tags befinden, die seit dem letzten Aufraeumen entstanden sind - wozu dann noch aufraeumen? Ein Renderer, der mit oneway=true und oneway=yes umgehen kann, dem ist es doch egal, ob er 999 mal true und 1 mal yes hat oder 500 mal das eine und 500 mal das andre. Ja. Gegen die Booleans sage ich ja gar nichts. Finde ich zwar nichts schön, aber sei es drum. Das ist technisch einfach zu lösen. Mich stört nur die fehlende Allgemeingültigkeit des Richtungsbezuges. Da werden nämlich in Zukunft noch mehr Sachen kommen, die darauf aufbauen und jeder Mapper wird wieder und wieder schimpfen, wenn irgendwo ein Weg gedreht oder verbunden wird, weil keine Software die Richtungsbezüge korrigiert (oder aufgrund von mannigfaltigen Regeln überhaupt könnte). Schau mal im TagWatch nach left, right, opposite, other und sag mir, wie dass algorithmisch handhabbar sein soll. Bei vielen Sachen sehe ich ja nicht mal als Mensch durch, was gemeint ist, wie soll das ein Programm klarkommen. P.S. Um noch mal zum alten Thema zurückzuschweifen - Du kannst die Booleans auch technisch in den Griff bekommen. Wenn der Server beim Upload einfach bekannte Konvertierungen vornimmt hast Du auch einen konsistenten Datenbestand ;-) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtungsbezug (was: Datenbankbereinigung)
On Fri, Aug 08, 2008 at 09:43:03PM +0200, Dirk Stöcker wrote: On Fri, 8 Aug 2008, Frederik Ramm wrote: Wen man aber ohnehin immer davon ausgehen muss, dass sich im Datenbestand eine Anzahl von unaufgeraeumten Tags befinden, die seit dem letzten Aufraeumen entstanden sind - wozu dann noch aufraeumen? Ein Renderer, der mit oneway=true und oneway=yes umgehen kann, dem ist es doch egal, ob er 999 mal true und 1 mal yes hat oder 500 mal das eine und 500 mal das andre. Ja. Gegen die Booleans sage ich ja gar nichts. Finde ich zwar nichts schön, aber sei es drum. Das ist technisch einfach zu lösen. Mich stört nur die fehlende Allgemeingültigkeit des Richtungsbezuges. Da werden nämlich in Zukunft noch mehr Sachen kommen, die darauf aufbauen und jeder Mapper wird wieder und wieder schimpfen, wenn irgendwo ein Weg gedreht oder verbunden wird, weil keine Software die Richtungsbezüge korrigiert (oder aufgrund von mannigfaltigen Regeln überhaupt könnte). man sollte vielleicht die richtung der wege abschaffen und wir sollten uns ein konstrukt überlegen das uns mehr bringt als pfeile bzw die ordnung der nodes innerhalb eines wegs bei oneway könnte man zum beispiel die tags auf die endnodes setzen oneway=begin oneway=end oder ein einfahrt verbotenschild am ende und ein einbahnstrassen schild am anfang Schau mal im TagWatch nach left, right, opposite, other und sag mir, wie dass algorithmisch handhabbar sein soll. Bei vielen Sachen sehe ich ja nicht mal als Mensch durch, was gemeint ist, wie soll das ein Programm klarkommen. P.S. Um noch mal zum alten Thema zurückzuschweifen - Du kannst die Booleans auch technisch in den Griff bekommen. Wenn der Server beim Upload einfach bekannte Konvertierungen vornimmt hast Du auch einen konsistenten Datenbestand ;-) das ist ja auch mein tip aber na ja man ändert die daten des mappers und das könnte ih verärgern Ciao -- http://www.dstoecker.eu/ (PGP key available) ___ 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] Rendering-Experimente // Radwege
Tobias Wendorff wrote: Ich habe jetzt mal einige Radwege eingetragen und die Engine erweitern. Ich glaube, dass ich an den Schnittpunkten mit anderen Straßen die Überwege stricheln werde, wie es auch wirklich auf der Straße gemacht wird. Allerdings kann man derzeit noch nicht sagen, ob der Weg auf der Straße oder neben der Straße verläuft. http://raumplanung.tobwen.de/OSM/rendering/OSM_03.png Allein, das die Radwege angezeigt werden finde ich phantastisch! Gestrichelte Überwege wären wirklich gut. Eine Unterscheidung auf/neben der Straße halte ich nicht für entscheidend, wenn Du es wichtig findest, nimm doch einen etwas abgewandelten Farbton. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Weitere WMS-Layer in JOSM einbinden?
Hallo, habe im Netz diese Liste von WMS-Servern gefunden: http://www.skylab-mobilesystems.com/ger/wms_serverlist.html Vielleicht ist das eine blöde Frage, aber kann man die nicht irgendwie über das WMS Plugin in JOSM einbinden? Gruß Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lokale Mailingliste Düsseldorf
Hallo, nach dem gestrigen Treffen existiert nun für Düsseldorf eine lokale Mailingliste: http://lists.openstreetmap.de/cgi-bin/mailman/listinfo/duesseldorf Vielen Dank an Sven für die Einrichtung, Dominik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendering-Experimente // Radwege
Gerrit Lammert [EMAIL PROTECTED] wrote: Allein, das die Radwege angezeigt werden finde ich phantastisch! Hm, dürfte nicht so schwer sein, das auch in osmarender einzubaun ich schau mal bei Gelegenheit. Nun was gerendert wird verwenden die Leute auch... Sven -- If you continue running Windows, your system may become unstable. (Windows 95 BSOD) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere WMS-Layer in JOSM einbinden?
Thomas Berendes [EMAIL PROTECTED] wrote: Vielleicht ist das eine blöde Frage, aber kann man die nicht irgendwie über das WMS Plugin in JOSM einbinden? Man kann! Aa josm jedoch kein GetCapabilities unterstützt muss man da leider vieles manuell konfigurieren. Prinzipiell schaust Du einfach mal durch runterladen der GetCapabilities Antwort wie die Layer heißen und baust Dir daraus eine passende URL für josm zusammen. Ich nehme mal als Beispiel diesen Server von der Liste: http://132.156.10.87/cgi-bin/atlaswms_en?REQUEST=GetCapabilitiesSERVICE=wms Entweder mit dem Broser speicher oder unter Unix per: wget -q -O - 'http://132.156.10.87/cgi-bin/atlaswms_en?REQUEST=GetCapabilitiesSERVICE=wms' |less Wenn Du jetzt zum Beispiel das hier haben möchtest: Names of Water Survey of Canada sub-sub-drainage areas (1:1 000 000). musst Du den layer can_1m_env_s_subdr_nam anfragen. Die passende URL für josm würde dann wie folgt aussehen (untested): http://132.156.10.87/cgi-bin/atlaswms_en?SERVICE=WMSVERSION=1.1.1LAYERS=can_1m_env_s_subdr_namSTYLES=srs=EPSG:4326format=image/pngrequest=GetMap Wäre schön wenn jemand GetCapabilities in josm implementieren würde... Schön kann man WMS und WFS layer mit dem freien QGIS betrachten. Gruss Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Proposal für Automaten
Hi im Wiki ist nun auch ein Vorschlag für Verkaufsautomaten aller Art zu finden. http://wiki.openstreetmap.org/index.php/Tag:amenity%3Dvending_machine Gruß Thorsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere WMS-Layer in JOSM einbinden?
Hi, einbinden kann ich ja alles mögliche, aber sollte dann nicht auch geklärt sein, ob ich die Daten für OSM überhaupt nutzen darf. Nicht das es da noch zu Unstimmigkeiten kommt und wir vielleicht doch mal Ärger bekommen. Alex Sven Geggus schrieb: Thomas Berendes [EMAIL PROTECTED] wrote: Vielleicht ist das eine blöde Frage, aber kann man die nicht irgendwie über das WMS Plugin in JOSM einbinden? Man kann! Aa josm jedoch kein GetCapabilities unterstützt muss man da leider vieles manuell konfigurieren. Prinzipiell schaust Du einfach mal durch runterladen der GetCapabilities Antwort wie die Layer heißen und baust Dir daraus eine passende URL für josm zusammen. Ich nehme mal als Beispiel diesen Server von der Liste: http://132.156.10.87/cgi-bin/atlaswms_en?REQUEST=GetCapabilitiesSERVICE=wms Entweder mit dem Broser speicher oder unter Unix per: wget -q -O - 'http://132.156.10.87/cgi-bin/atlaswms_en?REQUEST=GetCapabilitiesSERVICE=wms' |less Wenn Du jetzt zum Beispiel das hier haben möchtest: Names of Water Survey of Canada sub-sub-drainage areas (1:1 000 000). musst Du den layer can_1m_env_s_subdr_nam anfragen. Die passende URL für josm würde dann wie folgt aussehen (untested): http://132.156.10.87/cgi-bin/atlaswms_en?SERVICE=WMSVERSION=1.1.1LAYERS=can_1m_env_s_subdr_namSTYLES=srs=EPSG:4326format=image/pngrequest=GetMap Wäre schön wenn jemand GetCapabilities in josm implementieren würde... Schön kann man WMS und WFS layer mit dem freien QGIS betrachten. Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bennenen von GebÀuden, Plà €tzen, etc.
, da Aral weder verantwortlich ist für die Tankstelle von Paul Brause, noch sie betreibt. Richtig wäre in meinen Augen operator=Paul Brause. Ggf. könnte man Aral im Namen unterbringen: name = ARAL, am Seehof. Im Falle des Dönerladens müsste man wissen, ob EURO-Döner Mustafa Yildirim angestellt hat, oder es sich z.B. um ein Franchising handelt. In letzterem Fall wäre er auch der Operator, im ersten Fall in der Tat EURO-Döner. So oder so ist das operator-tag ein bisschen unbefriedigend. Im Falle von Briefkästen und Telefonzellen funktioniert es besser (und bezeichnet dort auch durchaus den Betreiber). Also bei Tankstellen läuft es meistens so, dass sich Bspw. Aral die Tanke mietet, den Shop an Paul Brause weiterverpachtet und der Sprit im Namen und Rechnung von ARAL verkauft wird. Dies ist die einzige Möglichkeit, den Pächter dazu zu zwingen, den gesamten Wareneinkauf über Aral abzuwickeln. Dabei kann es durchaus vorkommen, dass der Grundstücksbesitzer sein eigenes Gelände von ARAL zurückpachtet. Also doch: operator=ARAL was für mich als Spritkäufer am interesantesten ist. Denn bei operator=Paul Brause würde ich eine freie Tankstelle erwarten. Tobias signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zäune
Hi, mich würde interessieren, wie der Konsens z.Zt. aussieht. Wie hierbei am besten verfahren wird, scheint nämlich noch etwas unklar zu sein. Mir sind kaum diesbezuegliche Diskussionen bekannt. Es scheint einen Unterschied zwischen expliziten Zaeunen zu geben - das ist das, was Du beschreibst - und impliziten Zaeunen - sowas wie amenity=parkplatz, eingezaeunt=true. Der explizite Zaun ist naeher an der Realitaet, ihm fehlt aber die Info, wozu der Zaun da ist; der implizite Zaun ist ein abstrakteres Konstrukt, aber man weiss dabei gleich, was hier eigentlich das geschuetzte Objekt ist, und das ist ja auch nicht schlecht. Ich wuerde das je nach Informationslage taggen - wenn Du nur den Zaun siehst und alles andere geraten waere, dann taggst Du eben nur den Zaun. Konsequent topographische Herangehensweise ist vielleicht eine etwas hochtrabende Bezeichnung daufer, und wie gesagt, ich kann mir auch Situationen vorstellen, in denen implizite Zaeune praktischer sind. Topographisch ist halt mehr fuers Kartenmalen. Etwaige gewagten und nicht nachvollziehbaren Interpretationen der umzäunten Flächen, wie im Beispiel das Besitzverhältnis des Waldes, sind irrelevant. Weiss nicht genau, was Du damit sagen willst. Wenn Du etwas ueber die umzaeunte Flaeche weisst, dann ist es selbstverstaendlich nicht irrelevant, und Du traegst es ein. Wenn Du stattdessen nichts weisst, dann traegst Du natuerlich auch nichts ein. (Das Prinzip nichts mappen, wenn man nichts weiss hat mir bislang immer gute Dienste geleistet, obwohl ich manchmal versucht bin, irgendwo ein riesiges Rechteck mit dem Tag building=no hinzumalen. Was ja korrekt waere ;-) Damit aus unseren Daten mal eine gute Karte wird, gilt es, künftig auch weniger offensichtliche Dinge wie etwa die Böschungskante einer sich höhenfrei kreuzenden Straße aufzunehmen, bevor man aus Gründen der Unterbeschäftigung über wenig sinnvolle Dinge wie bspw. die Flächenhaftigkeit von Straßenobjekten nachdenkt. Sehr schwurbelige Formulierung, in der zahlreiche meiner Meinung nach fehlen. Erstens teilt sicherlich nicht jeder die Meinung, dass Boeschungskanten fuer eine gute Karte wichtig seien. Zweitens teilt sicherlich nicht jeder die Meinung, dass die Flaechenhaftigkeit von Strassen im Gegenzug fuer eine gute Karte irrelevant sei. Drittens ist die Formulierung aus Gruenden der Unterbeschaeftigung unnoetig herablassend; ich bin sicher, es gibt zahlreiche Leute auf der Welt, die der Ansicht sind, dass jede Art der Teilnahme an OSM irgendwie mit Unterbeschaeftigung zu tun hat. Die Leute, die so reden, haben es oft einfach nicht verstanden, oder wollen es nicht. Ihre freie Entscheidung, aber mal so im Giesskannenprinzip die anderen als vermeintlch unterbeschaeftigt hinzustellen, gereicht ihnen nicht gerade zum Ruhm. Bye Ferderik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Worldfile vom 6.8.08
Carsten Schwede schrieb: das neue Worldfile liegt an bekannter Stelle zum Download bereit. Hmmm... In meinem MapSource 6.13.7 geht die Welt nur von E 31° bis E/W 180°. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bennenen von Gebaeuden, Plaetzen, etc.
Hi, On Sat, 09 Aug 2008 00:01:49 +0200, Tobias Hägele [EMAIL PROTECTED] wrote: Also bei Tankstellen läuft es meistens so, dass sich Bspw. Aral die Tanke mietet, den Shop an Paul Brause weiterverpachtet und der Sprit [...] Also doch: operator=ARAL was für mich als Spritkäufer am interesantesten ist. Denn bei operator=Paul Brause würde ich eine freie Tankstelle erwarten. Ich denke auch, dass die Paul Brause-Info etwas weniger spannend ist als die Aral-Info. Aber man koennte das schon euber den Namen abwickeln, oder? Name=ARAL Tankhof Pforzheim Mitte, Operator=Paul Brause? Auch in meinem lokalen Subway-Fastfood haengt ein Schild This store is proudly operated by Paul Brause. Es waere also schlicht falsch, ein operator=Subway hinzuschreiben. Dennoch ist das nateurlich das, was mich interessiert. Also Name=Subway? Andrerseits ist das, wie bei den Tankstellen auch, uneindeutig... Name=Subway Store 123 Karlsruhe-Mitte? Auch doof. Vielleicht sollten wir doch als Faustregel sagen, dass wir als Name das taggen, was die Leute auch benutzen, und nicht das, was der offizielle Name ist...? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere WMS-Layer in JOSM einbinden?
Alexander Schulze [EMAIL PROTECTED] wrote: einbinden kann ich ja alles mögliche, aber sollte dann nicht auch geklärt sein, ob ich die Daten für OSM überhaupt nutzen darf. Das war eine rein technische Erklärung, die Copyrightfragen völlig außer Acht läßt. Es kann ja durchaus hilfreich sein WMS Daten, die man nicht abzeichnen darf unter die Karte zu legen. Im Prinzip nichts anderes als der Webbasierte Kartenvergleich von Frank Sautter. Oft stehen die Nutzungsbedingungen in der Antwort des GetCapabilities Request. Ich habe echt ein Problem damit, wenn man Leute durch Unwissen davon abbringen möchte etwas verbotenes zu Tun! Das ist in etwa so sinnvoll wie dieses tolle Verbot von sogenannten Hackertools. Gruss Sven -- and on the third day he rebooted into Linux-1.3.84 (Linus Torvalds, Easter Kernel Release 1996) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treffen mit Vermessungsamt Darmstadt
Christian Winterstein schrieb: 2. Wälder haben oft Namen. Auch wenn die meistens außer dem Förster keiner kennt. Könnte auch interessant sein die zu erfahren. Namen von Schneisen wären auch schön. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Weitere WMS-Layer in JOSM einbinden?
Hallo, es ging mir gar nicht darum, eine Anleitung für etwas Verbotenes zu erhalten. Außerdem ist es doch viel interessanter, die Örtlichkeiten mit dem GPS-Gerät selbst abzufahren oder abzugehen. Die Frage nach den technischen Möglichkeiten hat mich grundsätzlich interessiert. Allein die Kontrolle der gezeichneten Daten ist natürlich schon hilfreich. Gruß Thomas Sven Geggus schrieb: Alexander Schulze [EMAIL PROTECTED] wrote: einbinden kann ich ja alles mögliche, aber sollte dann nicht auch geklärt sein, ob ich die Daten für OSM überhaupt nutzen darf. Das war eine rein technische Erklärung, die Copyrightfragen völlig außer Acht läßt. Es kann ja durchaus hilfreich sein WMS Daten, die man nicht abzeichnen darf unter die Karte zu legen. Im Prinzip nichts anderes als der Webbasierte Kartenvergleich von Frank Sautter. Oft stehen die Nutzungsbedingungen in der Antwort des GetCapabilities Request. Ich habe echt ein Problem damit, wenn man Leute durch Unwissen davon abbringen möchte etwas verbotenes zu Tun! Das ist in etwa so sinnvoll wie dieses tolle Verbot von sogenannten Hackertools. Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
