Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Original-Nachricht Datum: Thu, 14 May 2009 21:27:16 + (UTC) Von: Heiko Jacobs heiko.jac...@gmx.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ? Johann H. Addicks addi...@gmx.net wrote: Dann heisst das zuk?nftig: Geb?udeh?hen mit erfassen und Dachformen klassifizieren... ...dachgauben- und schornsteingenau! Noe, aber vielleicht mit 3 geangigen Dachformen? Flachdach und die beiden: - || - || - - \ / | / \ | - Das ist eine Variable mit 3 Werten und ggf. kaeme dann noch die Ausrichtung dazu (node?). Bei den letzten beiden wuerde ich Ziegel als Default voraussetzen und Sondermaterialien (Schilf, etc.) kann man ja zusaetzlich anfuegen. Was auch immer Sinn macht, ist die Geschossanzahl einzutragen, denn die ist ja einfach von der Strasse aus abzulesen. Und schon ist ein gut angenaehertes 3-D Modell ableitbar. Gruesse Hubert -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wordfile über Bittorrent
Hallo, probeweise habe ich die aktuelle gmapsupp.img.gz, wie sie von Computerteddy dankenswerterweise erzeugt wird, über Bittorrent verfügbar gemacht. Die torrentdatei findet sich unter http://osm.dev-random.de/torrents/ Probiert es mal aus. Gruß Lutz -- email: lutz.h...@fastmail.fm Jabber: sttmj...@jabber.ccc.de web:http://www.dev-random.de/ GnuPG: http://www.dev-random.de/0x6EBDA359.asc ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tlw. erledigt....
noch eine Frage - weißt Du über welche css-eigenschaft (nicht css an sich - sondern das anzusprechende objekt - zb. #map oder ...?) ich einfluss auf die textfarbe nehmen kann. gruß Jan :-) Carsten Gerlach schrieb: Moin, Am Donnerstag 14. Mai 2009 16:08:48 schrieb Jan Tappenbeck: Hallo Georg, vielen Dank für den Hinweis. Hast Du jetzt noch eine Idee warum die Popups aufgehen - aber keinen Inhalt haben ??? Kann es sein, daß der Text die gleiche Farbe wie der Hintergrund hat (weiß)? Wenn ich mit gedrückter Maustaste drüberfahre wir der Inhalt markiert und damit sichtbar. Deine Zeichenkodierung scheint auch nicht zu stimmen, bei Umlauten sehe ich da seltsame Zeichen. Grüße, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wordfile über Bittorrent
Hallo, On Fri, 15 May 2009 08:52 +0200, Lutz Horn lutz.h...@fastmail.fm wrote: probeweise habe ich die aktuelle gmapsupp.img.gz, wie sie von Computerteddy dankenswerterweise erzeugt wird, über Bittorrent verfügbar gemacht. Die torrentdatei findet sich unter http://osm.dev-random.de/torrents/ Alternativ gibt es auch einen Eintrag bei mininova: http://www.mininova.org/tor/2592546 Lutz -- email: lutz.h...@fastmail.fm Jabber: sttmj...@jabber.ccc.de web:http://www.dev-random.de/ GnuPG: http://www.dev-random.de/0x6EBDA359.asc ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Am Fr, 15.05.2009, 08:46 schrieb qbert biker: Noe, aber vielleicht mit 3 geangigen Dachformen? Sowas habe ich vor Wochen vorgeschlagen, hat aber keinen interessiert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
-Ursprüngliche Nachricht- Von: Tobias Wendorff Am Fr, 15.05.2009, 08:46 schrieb qbert biker: Noe, aber vielleicht mit 3 geangigen Dachformen? Sowas habe ich vor Wochen vorgeschlagen, hat aber keinen interessiert. Ich fänd's genial, denn dann würde sich OSM auch absetzen können von anderen Anbietern, alleine von der Optik. Problem ist nur, ob das bei allen Gebäuden gut aussieht und nicht die Übersichtlichkeit zerstört. Frage ist auch, ab welcher Zoomstufe das dargestellt würde. So viel meinerseits. Gruß, guerda Ist Ihr wunschn...@freenet.de noch frei? Jetzt prüfen und kostenlose E-Mail-Adresse sichern! http://email.freenet.de/dienste/emailoffice/produktuebersicht/basic/mail/index.html?pid=6829 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neues beim Tag information=*
Hallo, es gibt neue Werte beim Proposal information=*. Dieser Vorschlag dient zur genaueren Unterscheidung von verschiedenen Punkten, welche mit tourism=information getaggt sind. Bitte schaut daher noch einmal vorbei und gebt eure Meinung dazu ab. http://wiki.openstreetmap.org/wiki/DE:Proposed_features/information Da ich während des Eintragens von verschiedenen Karten oder Wegweisern zu Ungenauigkeiten mit dem ersten Schema-Vorschlag gekommen bin, habe ich auf der Talk-Seite einen weiteren Vorschlag gemacht. Bitte gebt dazu ebenfalls eure Meinung ab, denn ich finde ihn weitaus skalierbarer. http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/information#New_scheme Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Mario Salvini schrieb: Damit das aber Sinn macht müsstest du dich von der Idee loslösen überamm maxspeed zu taggen, sondern nur da, wo auch echte Schilder stehen :). Warum? maxspeed ist für jeden Streckenabschnitt (in Deutschland) definiert, ob da ein Schild steht oder nicht. Die einzigen Ausnahmen sind die Autobahnen und autobahnähnliche ausgebaute Strassen. aber genau das wäre doch gerade der Benefit, dennn wir mit einem Wert wie trafficzone=* erreichen können. Eben alle implizierten Geschwindigkeiten mit einem Platzhalter wie in_city oder out_of_town zu erfassen. Außerorts müsste mann dann anstatt eigentlich maxspeed:motorcar=100, maxspeed:hgv=60, etc. nur ein trafficzone=out_of_town:DE zu taggen und der rest könne an einer zentralen Stelle (ähnlich wie die maxspeed-Defaults in der Wiki) erfaßt werden. Überleg Dir was das für Folgen hat: - Vielen werden für jede Strasse die sie bearbeiten so einen default-Wert eintragen weil es besser ist wie wenn gar nichts eingetragen ist. Wo schon etwas eingetragen ist werden viele Mapper nicht korrigieren da ja schon etwas eingetragen ist was plausibel erscheint - Erfassungsqualität sinkt. - Ein default-Wert der nicht in der Datenbank selbst vorhanden ist steht im Zweifelsfall gerade dann nicht zur Verfügung wenn man ihn braucht. - Eine Dokumentation der Veränderungen über die Zeit wird erheblich erschwert - bei diskreten maxspeed-Werten reicht ein einfaches sichern der Datenbank in regelmässigen Abständen, bei default-Wert im Web muss man eine ganze Menge mehr berücksichtigen und mit abspeichern was einem zum Zeipunkt der Sicherung häufig nicht bewusst sein wird. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausfäll e
Florian Lohoff schrieb: u-blox 5 soll via Firmware upgrade Galileo koennen. Ich hatte auf der letzten electronica hier in München mit einem u-blox Mitarbeiter geredet (Hatte glücklicherweise meine WBT-201 dabei). Das Thema Firmware-Update ist vor allem ein Lizenzthema (Galileo will angeblich Geld dafür, dass es benutzt wird). = ich bin diesbezüglich skeptisch...:-( MfG Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objek te
hi! dann muss du mir das nochmal genauer erläutern was du meinst. bin noch ca. 14 tage außer gefecht. ein anderer hatte auch schon eine ähnliche anfrage gestellt. siehe meine talk-seite im wiki. gruß Jan .-) Tobias Wendorff schrieb: Jan Tappenbeck schrieb: sollte vom grundsatz kein problem sein - hatte ich auch schon einmal darüber nachgedacht bloss die liste wird sicherlich explodieren ! Nein, auf Karlsruhe-Schema. lass uns mal abwarten ob andere das auch für notwendig halten. Nunja, bis dahin hab ich's auch selbst fertig. Trotzdem danke :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausf älle
Michael Kugelmann michaelk_...@gmx.de wrote: Ich hatte auf der letzten electronica hier in München mit einem u-blox Mitarbeiter geredet (Hatte glücklicherweise meine WBT-201 dabei). Das Thema Firmware-Update ist vor allem ein Lizenzthema (Galileo will angeblich Geld dafür, dass es benutzt wird). = ich bin diesbezüglich skeptisch...:-( Das bin ich auch! Ich denke, dass der Bussinessplan von Galileo so nicht aufgehen kann. Open Soucre Stacks zum Empfang von GPS-Signalen per Software defined Radio gibt es AFAIK bereits. Gruss Sven -- /* Fuck me gently with a chainsaw... */ (David S. Miller in /usr/src/linux/arch/sparc/kernel/ptrace.c) /me is gig...@ircnet, 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] Qualitätssicherung - unbenannte Objek te
Jan Tappenbeck schrieb: dann muss du mir das nochmal genauer erläutern was du meinst. bin noch ca. 14 tage außer gefecht. Ich möchte eine Information, an welchen adressfähigen Nodes noch die Adresse fehlt. Ich habe hier z.B. in Dortmund etliche Nodes, an denen Restaurants ohne Adresse eingetragen sind. Die habe ich jetzt gefixt, wo ich weiß, dass welche sind. Man sieht aber nur schlecht an den Daten, ob die Punkte Informationen und welche sie denn haben. Auch wenn man das Haus nicht skizziert, kann man ja wenigstens die Adresse drankleben :-) Wenn jemand z.B. PLUS/Netto-Filialen eingetragen hat, aber die Anschriften fehlen, kann man - meiner Meinung nach - diese bedenkenlos von deren Website abschreiben. Hat einmal den Vorteil, dass sich Postleitzahlengebiete bilden und zum anderen den Vorteil, dass es besser routbar ist. Hausnummern sind nie schlecht :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Philip Gillißen schrieb: Ich fänd's genial, denn dann würde sich OSM auch absetzen können von anderen Anbietern, alleine von der Optik. Problem ist nur, ob das bei allen Gebäuden gut aussieht und nicht die Übersichtlichkeit zerstört. Frage ist auch, ab welcher Zoomstufe das dargestellt würde. Ich schätze, man sollte eine Art Zusatzstufe einfügen oder eine komplett andere Map erstellen, denn aus der Sicht der klassischen Kartographie sieht's nicht so doll aus :-) Die Information wäre aber auch für 3D-Anwendungen, wie un osm-3D geeignet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wordfile über Bittorrent
Hallo, On Fri, 15 May 2009 08:52 +0200, Lutz Horn lutz.h...@fastmail.fm wrote: probeweise habe ich die aktuelle gmapsupp.img.gz, wie sie von Computerteddy dankenswerterweise erzeugt wird, über Bittorrent verfügbar gemacht. Die torrentdatei findet sich unter http://osm.dev-random.de/torrents/ Die folgenden vier Dateien sind jetzt über diesen Weg verfügbar: * eu_gmapsupp.img.gz * gmapsupp.img.gz * typ_eu_gmapsupp.img.gz * typ_gmapsupp.img.gz Lutz -- email: lutz.h...@fastmail.fm Jabber: sttmj...@jabber.ccc.de web:http://www.dev-random.de/ GnuPG: http://www.dev-random.de/0x6EBDA359.asc ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Garry schrieb: Mario Salvini schrieb: Damit das aber Sinn macht müsstest du dich von der Idee loslösen überamm maxspeed zu taggen, sondern nur da, wo auch echte Schilder stehen :). Warum? maxspeed ist für jeden Streckenabschnitt (in Deutschland) definiert, ob da ein Schild steht oder nicht. Die einzigen Ausnahmen sind die Autobahnen und autobahnähnliche ausgebaute Strassen. aber genau das wäre doch gerade der Benefit, dennn wir mit einem Wert wie trafficzone=* erreichen können. Eben alle implizierten Geschwindigkeiten mit einem Platzhalter wie in_city oder out_of_town zu erfassen. Außerorts müsste mann dann anstatt eigentlich maxspeed:motorcar=100, maxspeed:hgv=60, etc. nur ein trafficzone=out_of_town:DE zu taggen und der rest könne an einer zentralen Stelle (ähnlich wie die maxspeed-Defaults in der Wiki) erfaßt werden. Überleg Dir was das für Folgen hat: - Vielen werden für jede Strasse die sie bearbeiten so einen default-Wert eintragen weil es besser ist wie wenn gar nichts eingetragen ist. Wo schon etwas eingetragen ist werden viele Mapper nicht korrigieren da ja schon etwas eingetragen ist was plausibel erscheint - Erfassungsqualität sinkt. - Ein default-Wert der nicht in der Datenbank selbst vorhanden ist steht im Zweifelsfall gerade dann nicht zur Verfügung wenn man ihn braucht. - Eine Dokumentation der Veränderungen über die Zeit wird erheblich erschwert - bei diskreten maxspeed-Werten reicht ein einfaches sichern der Datenbank in regelmässigen Abständen, bei default-Wert im Web muss man eine ganze Menge mehr berücksichtigen und mit abspeichern was einem zum Zeipunkt der Sicherung häufig nicht bewusst sein wird. Garry Hi Garry, klar birgt diese Vorgehensweise gewisse Risiken. Besonders wenn die Dokumentation und Aufklärung der Methode nicht vernünftig betrieben wird. In meinen Augen sind die Vorteile die daraus entstehen aber signifikant größer. Nicht nur, dass wir endlch vernünftig erfassen können, ob eine Straße in der Stadt oder auswärts liegt. Wir können mit diesem Tag (nennen wir hn z.B. trafficzone) auch definieren welche Wege in der Datenbank überhaupt zum Straßenverkehrsnetz gehören - z.B. gesperrte Servicewege, Einfahrte, Feldwege (z.B. mit Zeichen 250). Außerdem hätte das mappen von trafficzone=* ja nur indirekt etwas mit maxspeed zu tun. Die Frage, ob man bestehende Werte von maxspeed korrigiert hat eher was damit zu tun welcher Tag-Philosophie man folgt (ich nutze maxspeed z.B. ausschließlich nur für explizite Beschränkungen und bin da bei mir in der Gegend scheinbar nicht der Einzige). Die Lücke die dabei bis jetzt geklafft hat, nicht zu wissen was denn auf den Straßen ohne Angabe gilt, schließt dafür ja die trafficzone; wenn auch nicht vielleicht mit einem konkreten Wert, sondern eben mit einem Platzhalter der für ein Bündel von Eigenschaften steht (im Grunde genau wie alle anderen nicht-numerischen Values) Grüße Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objek te
Wenn jemand z.B. PLUS/Netto-Filialen eingetragen hat, aber die Anschriften fehlen, kann man - meiner Meinung nach - diese bedenkenlos von deren Website abschreiben. ... bist Du dir da sicher ??? gruß Jan :-) Tobias Wendorff schrieb: Jan Tappenbeck schrieb: dann muss du mir das nochmal genauer erläutern was du meinst. bin noch ca. 14 tage außer gefecht. Ich möchte eine Information, an welchen adressfähigen Nodes noch die Adresse fehlt. Ich habe hier z.B. in Dortmund etliche Nodes, an denen Restaurants ohne Adresse eingetragen sind. Die habe ich jetzt gefixt, wo ich weiß, dass welche sind. Man sieht aber nur schlecht an den Daten, ob die Punkte Informationen und welche sie denn haben. Auch wenn man das Haus nicht skizziert, kann man ja wenigstens die Adresse drankleben :-) Wenn jemand z.B. PLUS/Netto-Filialen eingetragen hat, aber die Anschriften fehlen, kann man - meiner Meinung nach - diese bedenkenlos von deren Website abschreiben. Hat einmal den Vorteil, dass sich Postleitzahlengebiete bilden und zum anderen den Vorteil, dass es besser routbar ist. Hausnummern sind nie schlecht :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objek te
Jan Tappenbeck schrieb: Wenn jemand z.B. PLUS/Netto-Filialen eingetragen hat, aber die Anschriften fehlen, kann man - meiner Meinung nach - diese bedenkenlos von deren Website abschreiben. ... bist Du dir da sicher ??? Da ich kein Jurist bin und wir meines Wissens nach auch keinen Juristen in der Liste haben, habe ich meiner Meinung nach geschrieben. Wenn man die Veröffentlichungen der Adressen überhaupt als Datenbank im Sinne von §§ 87a f. UrhG sehen will, muss erstmal gegeben sein, dass die Beschaffung, Überprüfung oder Darstellung eine umfangreiche Investition erfordert hat. Da es sich aber nur eine Liste der Filialstandorten handelt, die der Konzern sowieso führt und nicht extra aufwändig für die Websites erheben musste und/oder angereicht hat, ist der Sachbestand nicht gegeben. Die Koordinaten übernehmen wir ja z.B. nicht. Auch sind die Adressdaten nicht urheberrechtlich geschützt, da es sich um Rohdaten ohne Schöpfungshöhe handelt. Ein anderes Beispiel wäre z.B. das Fahrradabstellanlagenkataster der Stadt Dortmund. Hier wurde von jedem Fahrradabstellbügel ein Foto gemacht, die genaue Herstellungsart beschrieben, Geokoordinaten hinterlegt etc. etc. Hier liegt also eine westenliche Investition in Zeit, Geld und Arbeit vor. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Verkehrszeichen taggen
Die Lösung ist einfach! Folge dem folgenden Mantra: Tagge was du siehst und nicht was es deiner Meinung nach bedeuten könnte! Daraus folgt für mich und hoffentlich auch für andere für das aktuelle Thema: Für mich mag Zeichen 310 und 274 jeweils nur maxspeed=50 bedeuten für andere ist die Unterscheidung vielleicht wichtig. Also tagge erstmal das Schild! http://wiki.openstreetmap.org/wiki/Key:traffic_sign http://wiki.openstreetmap.org/wiki/DE:Road_Signs traffic_sign=maxspeed:30zone traffic_sign=DE:274.1 Um das Interpretieren komischer Werte können sich Parser kümmern. Um das Berichtigen von Schreibfehlern können sich Bots kümmern. Es gibt derzeit keinen Weg die Ausrichtung des Schildes zu beschreiben. Also erfinde einen! traffic_sign:orientation=backward Nutze diesen Tag sofort und solange bis sie die Community auf etwas besseres geeinigt hat. Erst wenn alle Ortsschilder getaggt sind lassen sich verkehrsrechtlich relevante Ortsrelationen bilden, die leider nicht mit den Ortsgrenzen aus der Flächennutzung übereinstimmen. Da wir schon die Relation boundary=administrative haben wäre ein boundary=traffic sinnvoll. Will man diese Relation auf Straßen abbilden sollte man den Key nicht speedzone sondern besser trafficzone oder trafficboundary nennen, da er nicht nur für die maxspeed relevant ist. Es macht keinen Sinn sich auf Integerwerte zu beschränken, da die Realität das auch nicht tut. Für eine Spielstraße tagge nicht maxspeed=6 sondern maxspeed=living_street Eine Autobahn wird begrenzt durch die Zeichen 330 und 334. Dazwischen gilt maxspeed=DE:motorway es sei den es wird explizit etwas anderes ausgeschildert. out_of_town mag richtig sein, aber land ist nicht falsch und zudem noch schön kurz. DE als Präfix und nicht als Postfix, da dies der Suchhierarchie entspricht. maxspeed sollte immer explizit getagged werden, eine Relation boundary=traffic ist schön, besagt aber auch nicht mit Sicherheit das da nicht doch ein 30-Schild steht, sondern nur das die Straße sich innerhalb eines Ortes befindet und es für mach eine Navigationssoftware sinnvoll wäre dem Benutzer mitzuteilen, das hier evtl. eine maxspeed von 50 gelten könnte und das man ganz sicher kein Fernlicht verwenden darf. maxspeed-Werte auf ways sind besser zu parsen als Schilder, da diese für Karten und Router (nicht fürs direkt Anzeigen) auf die dahinter liegenden Straßen abgebildet werden müssen. Es wird also ein Präprozessor benötigt, der Schilder interpretiert. Da sich das automatisieren lässt, macht das besser nicht der OSM-User sondern ein Programm! Einige meiner hier aufgeführten Vorschläge, wurden schon vorher in der viel zu langen Diskussion genannt und ich habe sie eben erst gelesen. Man möge mir das verzeihen. Per signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Stefan Dettenhofer (StefanDausR) schrieb: Mario Salvini schrieb: man kanns ja auch gerne *traffic*zone nennen oder gleich nur zone=[...] Nein, da Ortsschilder selten auf Ortsgrenzen stehen und zum Teil Straßen durch Orte führen und dabei aber verkehrsrechtlich nicht Teil des Ortes sind. Eine Vorverarbeitung kann dann an alle relevanten ways, die *kein* maxspeed (etc.) haben, den entsprechenden Defaultwert setzten. Ja, diese errechneten Werte dürfen dann aber auf keinen Fall zurück in die Datenbank geschrieben werden! Sonst würde man dort explizit überprüfte Werte mit angenommenen überschreiben. Per signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Hallo. Am Freitag 15 Mai 2009 13:48:11 schrieb Per: Eine Vorverarbeitung kann dann an alle relevanten ways, die *kein* maxspeed (etc.) haben, den entsprechenden Defaultwert setzten. Ja, diese errechneten Werte dürfen dann aber auf keinen Fall zurück in die Datenbank geschrieben werden! Sonst würde man dort explizit überprüfte Werte mit angenommenen überschreiben. Bitte die Untergangsszenarien einfach mal draußen lassen. Erstens steht hier nirgendwas was vom Zurückschreiben der Werte und selbst wenn das jemand machen wollte, würde meiner Erfahrung nach keiner so beschränkt sein, abweichende, schon vorhandene Werte damit zu überschreiben. Gruß, Bernd -- Ein Diplomat ist jemand, der dich in einer Art und Weise zum Teufel wünscht, daß du dich auf den Trip freust. 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] Qualitätssicherung - unbenannte Objek te
Hallo. Am Freitag 15 Mai 2009 13:46:51 schrieb Tobias Wendorff: Jan Tappenbeck schrieb: Wenn jemand z.B. PLUS/Netto-Filialen eingetragen hat, aber die Anschriften fehlen, kann man - meiner Meinung nach - diese bedenkenlos von deren Website abschreiben. ... bist Du dir da sicher ??? Da ich kein Jurist bin und wir meines Wissens nach auch keinen Juristen in der Liste haben, habe ich meiner Meinung nach geschrieben. Ich übernehme einzelne Adressen von schon in OSM vorhandenen (Firmen-)POIs (Gaststätten, Supermärkte, Bankfilialen, ...) auch ohne schlechtes Gewissen aus der Website des jeweiligen Betreibers oder dem Telefonbuch. Auch wenn ich jetzt wegen dem letzten Wort des obigen Absatzes gesteinigt werden sollte: Bei einer einzelnen Adresse sehe ich da gar keine Bedenken. Es ist nichts automatisiert sondern es geht um einzelne Adressen. Gruß, Bernd -- Erfahrung nennt man die Summe aller unserer Irrtümer. - Thomas Alva Edison (amerikan. Erfinder) 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] Maxspeed map - Kompromissvorschlag
Bernd Wurst schrieb: Bitte die Untergangsszenarien einfach mal draußen lassen. Die Funktionen zum Rückgängigmachen von Änderungen sind leider noch mangelhaft. Erstens steht hier nirgendwas was vom Zurückschreiben der Werte und selbst wenn das jemand machen wollte, würde meiner Erfahrung nach keiner so beschränkt sein, abweichende, schon vorhandene Werte damit zu überschreiben. Das ist klar, aber auch das auffüllen noch nicht vorhandener Werte sollte vermieden werden. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objek te
Hallo. Am Freitag 15 Mai 2009 14:23:18 schrieb Tobias Wendorff: Meine Meinung: Im Endeffekt ist es wurscht, ob es automatisiert oder manuell gemacht wird, Entnahme ist Entnahme. Da habe ich schon andere Meinungen gehört. Der Datenbankschutz schützt meines Wissens nur signifikanten Auszüge der Datenbank und keine Einzeldatensätze. Aber eigentlich ist das egal, siehe unten. Beispiel: Wenn alle OSM-Nutzer jeden Tag nur eine Rufnummer aus dem Telefonbuch manuell abschreiben, haben wir in 2 Monaten die Ausgaben des Ruhrgebiets kopiert. Ich sehe wenig Zusammenhang zum Thema. Wir sind und wollen kein Telefonbuch. Es ist nur entscheidend, ob ein Schutz drauf liegt oder nicht. Bei Telefonbüchern sehe ich das massiv kritisch, da sie laut Urteilen geschützt sind. Bei Websites sehe ich es, wie dargelegt, nicht so. Bei Websites der Betreiber ist es IMHO sowieso klar. Denn der veröffentlicht seine Adresse ja damit man ihn findet. Ein weiteres Problem ist der Wettbewerb. Wenn wir ein eigenes, reines Branchen- oder Telefonbuch erzeugen würden, würden uns die Anbieter sicher auf die Finger hauen. Wir erzeugen jedoch ein komplett eigenständiges Werk, aus der man ein solches Verzeichnis ableiten kann. Muss ich verstehen, was du in diesem Absatz sagen willst? Wir sind kein Telefonbuch, meines Wissens werden Telefonnummern in den Daten von den meisten Mappern nicht gern gesehen. Ein Telefonbuch aus den Daten abzuleiten sollte also echt ein schweres Unterfangen sein. Nochmal zur Situation: Die Straßenzugehörigkeit eines POI kann ich in den meisten Fällen auch einfach aus der Karte ablesen, ich weiß ja wo das Dingen ist und wie die Straße daneben heißt. Ob die Hausnummer alleine also im Telefonbuch eine Schützenswerte Information ist, wird dir wohl keiner aus dem Stehgreif beantworten können. Die POIs von denen ich rede, haben i.d.R. einen hervorgehobenen Eintrag im Telefonbuch. Sind also eventuell sogar als Anzeige und nicht als redaktioneller Beitrag im Telefonbuch zu werten. Aus einer Werbeanzeige eine Information auszulesen halte ich für unkritisch. Gruß, Bernd -- Für jedes Problem gibt es eine einfache Lösung, die es noch schlimmer macht. - Hans-Jürgen Quadbeck-Seeger (dt. Chemiker und Manager) 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] ?OSM-Geb?ude in Google-Pseudo-3D ?
Tobias Wendorff schrieb: Am Fr, 15.05.2009, 08:46 schrieb qbert biker: Noe, aber vielleicht mit 3 geangigen Dachformen? Sowas habe ich vor Wochen vorgeschlagen, hat aber keinen interessiert. Ich erinner mich an eine Diskussion vor Wochen (nicht sicher, ob du da dabei warst) Auf jeden Fall denke ich, dass viel Potential vorhanden ist. Allerdings werden die Leute keine 12 verschiedenen Dächerformen (wie damals vorgeschlagen AFAIR) auseinanderhalten können und taggen wollen. Wenn dann ein einfaches, gut dokumentiertes und veranschaulichtes Schema. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objek te
Hallo, Bernd Wurst schrieb: Muss ich verstehen, was du in diesem Absatz sagen willst? Okay, also ausformuliert: Die bekannten Urteile (Google nach Entnahme Datenbankschutz) beziehen sich alle auf die wiederholte und systematische Entnahme einzelner Bewertungen aus einer Datenbank. Wenn Du einmal eine Adresse rausholst, ist es wurscht. Wenn Du es mehrmals tust oder wir halt als Community irgendwie organisiert (wir arbeiten ja alle am gleichen Projekt), dann könnte s Probleme geben. Diese Probleme treten aber nur auf, wenn die Datenbank, also die Beschaffung, Überprüfung oder Darstellung der einzelnen Elemente, erhebliche, menschliche, technische oder finanzielle Investition erfordert hat. Das sehe ich bei den Websites nicht so, jedoch bei Telefonbüchern und anderen Adressbeständen, wurde explizit darauf hingewiesen. Das denke ich mir nicht aus, sondern das wurde so geurteilt. Wir sind kein Telefonbuch, meines Wissens werden Telefonnummern in den Daten von den meisten Mappern nicht gern gesehen. Ein Telefonbuch aus den Daten abzuleiten sollte also echt ein schweres Unterfangen sein. Es muss ja kein Telefonbuch sein - ein Branchenbuch wäre genau das richtige. Bei uns im Telefonbuch stehen auch Adressen von Brancheneinträgen. Wie gesagt: Die Entnahme aus Daten von Telefonbüchern ist aufgrund der Urteile in Deutschland (wieder Google) höchst kritisch, aber wer kann's Dir schon nachweisen? Grüße Tobas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Jonas Krückel schrieb: Auf jeden Fall denke ich, dass viel Potential vorhanden ist. Allerdings werden die Leute keine 12 verschiedenen Dächerformen (wie damals vorgeschlagen AFAIR) auseinanderhalten können und taggen wollen. Wenn dann ein einfaches, gut dokumentiertes und veranschaulichtes Schema. Ich habe mich irgendwann ausgeklinkt, als verschiedene Architekten über 100 verschiedene Dachformen diskutiert haben. Für diese Leute sollten wir eine SketchUp!-Untersützung integrieren :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Bernd Wurst schrieb: ... m Zurückschreiben der Werte und selbst wenn das jemand machen wollte, würde meiner Erfahrung nach keiner so beschränkt sein, abweichende, schon vorhandene Werte damit zu überschreiben. Das ist klar, aber auch das auffüllen noch nicht vorhandener Werte sollte vermieden werden. Sehe ich nicht so. So lange der theoretisch korrekte Wert (warum ist das so) in einem separaten Tag erhalten ist, sehe ich kein Problem darin, alle nicht anderweitig ausgeschilderten Innerorts-Straßen mit 50 zu markieren. Ich sage nicht, dass der trivial-Algorithmus hier benutzt werden sollte. Aber wenn man sich halbwegs sicher sein kann, dass eine bestimmte Straße bereits ausreichend erfasst ist und nicht nur noch nicht erfasst wurde, dann ist das Eintragen eines expliziten Wertes IMHO etwas was man machen kann. Es muss ja nicht jeder für nötig halten, aber ich sehe jetzt nicht warum man sich da gleich auf die Füße getreten fühlen muss. IMHO stört das niemanden, so lange es richtige Werte sind. Gruß, Bernd es ist in soweit nicht richtig, als dass es nur für Kraftfahrzeuge gilt, nicht aber für Rad- und Fußvolk. Da Fußvolk nicht ohne Hilfsmittel in diese Regionen vordringt fallen sie mal aus der Überlegung raus, weil unbedeutend. Radfahren können aber je nach Umgebung und körperlicher Konstitution sehr wohl in diese Region abtauchen, und für sie gilt in geschlossenen Ortschaften nunmal kein maxspped=50 sondern erstmal maxspeed=nicht vorhanden. Ein globales maxspeed=50 ist als inkorrekt ohne gleichzeitig ein maxspeed:bicycle=no zu setzen, aber dass macht ja keiner. Eine explitize Begrenzung gilt für alle und verdient es so mit maxspeed=* abgebildet zu werden. Was glaube ich eher in deinem Fokus liegt ist maxspeed:motorcar=50. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Qualitätssicherung - unbenannte Objekt e
Berlin verfügbar ! Jan Tappenbeck schrieb: morgen mit dem berlin.osm gruß Jan :-) Christoph Henning schrieb: Großartig, lässt du das bitte auch für Berlin berechnen? 2009/5/14 Jan Tappenbeck o...@tappenbeck.net: Jetzt gibt es auch eine Übersicht unter http://wiki.openstreetmap.org/wiki/SearchNoNamePOI Die Pfade zu unten mußten nochmal angepaßt werden ! jetzt auch Köln und Müchen, Bayern und NRW Jan Tappenbeck schrieb: habe noch einige draufgelegt http://www.tappenbeck.net/osm/quality/poi_noname/schleswig-holstein/ http://www.tappenbeck.net/osm/quality/poi_noname/grossraum_kiel/ http://www.tappenbeck.net/osm/quality/poi_noname/grossraum_luebeck/ eine uebersichtsseite folgt ! Gruß Jan :-) Jan Tappenbeck schrieb: Moin ! ich habe mich auch an einem Tool versucht für das Auffinden von unbenannten Objekten - wenn schon Elemente in der Karte, dann auch mit dem entsprechenden Namen. Eine erste Auswertung für Hamburg findet sich unter http://www.tappenbeck.net/osm/quality/poi_noname/hamburg/ Bei Bedarf kann ich auch die anderen Bundesländer rechnen lassen oder Auszüge wenn die Bereiche zu groß sind. Schaut es Euch an und wenn es etwas zu verbessern gibt melden. Gruß Jan :-) ___ 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] Maxspeed map - Kompromissvorschlag
Hallo. Am Freitag 15 Mai 2009 15:20:15 schrieb Mario Salvini: Da Fußvolk nicht ohne Hilfsmittel in diese Regionen vordringt fallen sie mal aus der Überlegung raus, weil unbedeutend. Radfahren können aber je nach Umgebung und körperlicher Konstitution sehr wohl in diese Region abtauchen, und für sie gilt in geschlossenen Ortschaften nunmal kein maxspped=50 sondern erstmal maxspeed=nicht vorhanden. Ein globales maxspeed=50 ist als inkorrekt ohne gleichzeitig ein maxspeed:bicycle=no zu setzen, aber dass macht ja keiner. Ein Radfahrer der auf einer solchen Straße mehr als 50 km/h fährt, handelt zwar formal nicht unrechtmäßig, kann aber erstens nicht mehr mit der gebotenen Rücksichtnahme unterwegs sein (wohlgemerkt: auf einer Straße auf der Autos nicht über 50 freigegeben sind) und zweitens (das ist das wesentliche) wird dem schnurzpiepegal sein, was in den OSM-Daten als maxspeed hinterlegt ist. Formal hast du recht, aber ich wüsste nicht, warum diese hier immer wieder angesprochene Gesetzeslücke in der Praxis irgend eine Relevanz hätte. Gruß, Bernd -- Windows Error 019: User error. It's not our fault. Is not! Is not! 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] Maxspeed map - Verkehrszeichen taggen
Hallo Per, maxspeed sollte immer explizit getagged werden, eine Relation boundary=traffic ist schön, besagt aber auch nicht mit Sicherheit das da nicht doch ein 30-Schild steht, sondern nur das die Straße sich innerhalb eines Ortes befindet und es für mach eine Navigationssoftware sinnvoll wäre dem Benutzer mitzuteilen, das hier evtl. eine maxspeed von 50 gelten könnte und das man ganz sicher kein Fernlicht verwenden darf. Kleine Nebenbemerkung: Fernlicht ist nur bei durchgehender, ausreichender Beleuchtung verboten. Bei unbeleuchteten Ortschaften darf also auch mit Fernlicht gefahren werden. Quelle: StVO Art 17(3) http://www.verkehrsportal.de/stvo/stvo_17.php Gruss, Thomas, der diesen Artikel gerade gestern per Zufall gelesen hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Garminkarte auf Garmin N�VI 205T
Hallo, die OSM Karte auf einer SD Karte geht ja schon super. Die Adressuche will zwar noch nicht, aber mal schauen. Frage: Kann man die interne dazugelieferte Karte auch auf eine SD Karte kopieren/ Konvertieren? Dann könnte ich durch einfaches Umstecken der Speicherkarte, die Kartendaten wechseln. zZ muss ich immer erst im Menü (in der 3. Ebene), die Orginalkarte deaktivieren. Hat jemand eine Idee oder auch Infos zum Aufbau der Dateistruktur und Bedeutung der internen Speicherdaten? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Bernd Wurst schrieb: Hallo. Am Freitag 15 Mai 2009 15:20:15 schrieb Mario Salvini: Da Fußvolk nicht ohne Hilfsmittel in diese Regionen vordringt fallen sie mal aus der Überlegung raus, weil unbedeutend. Radfahren können aber je nach Umgebung und körperlicher Konstitution sehr wohl in diese Region abtauchen, und für sie gilt in geschlossenen Ortschaften nunmal kein maxspped=50 sondern erstmal maxspeed=nicht vorhanden. Ein globales maxspeed=50 ist als inkorrekt ohne gleichzeitig ein maxspeed:bicycle=no zu setzen, aber dass macht ja keiner. Ein Radfahrer der auf einer solchen Straße mehr als 50 km/h fährt, handelt zwar formal nicht unrechtmäßig, kann aber erstens nicht mehr mit der gebotenen Rücksichtnahme unterwegs sein (wohlgemerkt: auf einer Straße auf der Autos nicht über 50 freigegeben sind) und zweitens (das ist das wesentliche) wird dem schnurzpiepegal sein, was in den OSM-Daten als maxspeed hinterlegt ist. Formal hast du recht, aber ich wüsste nicht, warum diese hier immer wieder angesprochene Gesetzeslücke in der Praxis irgend eine Relevanz hätte. Gruß, Bernd die Gesetzeslücke für Innerorts ist auch weniger das Problem, da es nur in Deutschland Relavanz hat. Viel interessanter ist, wie du es außerorts handhaben würdest, wenn keine explizite Begrenzung vorliegt. Aus gleicher Argumentation ist das das globale maxspeed=* nämlich hier inkorrekt, denn es gilt nicht implizierte maxspeed=100 für alle, sondern nur maxspeed:motorcar=100, maxspeed:hgv=60, etc. Grüße :) Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] gefunden
es war die body -definition - weiße farbe auf weißem grund ! gruß Jan :-) Jan Tappenbeck schrieb: noch eine Frage - weißt Du über welche css-eigenschaft (nicht css an sich - sondern das anzusprechende objekt - zb. #map oder ...?) ich einfluss auf die textfarbe nehmen kann. gruß Jan :-) Carsten Gerlach schrieb: Moin, Am Donnerstag 14. Mai 2009 16:08:48 schrieb Jan Tappenbeck: Hallo Georg, vielen Dank für den Hinweis. Hast Du jetzt noch eine Idee warum die Popups aufgehen - aber keinen Inhalt haben ??? Kann es sein, daß der Text die gleiche Farbe wie der Hintergrund hat (weiß)? Wenn ich mit gedrückter Maustaste drüberfahre wir der Inhalt markiert und damit sichtbar. Deine Zeichenkodierung scheint auch nicht zu stimmen, bei Umlauten sehe ich da seltsame Zeichen. Grüße, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Hallo. Am Freitag 15 Mai 2009 16:10:08 schrieb Mario Salvini: es gilt nicht implizierte maxspeed=100 für alle, sondern nur maxspeed:motorcar=100, maxspeed:hgv=60, etc. Fällt dir für etc noch etwas ein? Ich weiß noch von pkw mit anhänger = 80, aber da wüsste ich kein tag für. Wichtig ist IMHO jetzt nicht, ob oder wie man das genau macht sondern dass es nicht sinnvoll ist, jetzt gleich kategorisch jede Kompromisslösung auszuschließen. Wenn jemand sich die Mühe macht, die Maxspeeds korrekt aus allem anderen zu berechnen, lasst ihn doch. Wenn es nicht korrekt war, macht man es rückgängig oder besser. Ich selbst hab auch gar kein besonderes Interesse daran, dass das jemand macht. Nur möchte ich nicht, dass hier so radikal ausgeschlossen wird, dass das Sinn machen kann. Gruß, Bernd -- Gehören Sie zu den 4 Millionen Menschen in Deutschland die weder lesen noch schreiben können? Dann lesen Sie hier bitte aufmerksam weiter und kontaktieren uns bei Interesse per Email [..] - Quelle unbekannt 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
Frage zu Garmin N�VI_205T
Hallo, die OSM Karte auf einer SD Karte geht ja schon super. Die Adressuche will zwar noch nicht, aber mal schauen. Frage: Kann man die interne dazugelieferte Karte auch auf eine SD Karte kopieren/ Konvertieren? Dann könnte ich durch einfaches Umstecken der Speicherkarte, die Kartendaten wechseln. zZ muss ich immer erst im Menü (in der 3. Ebene), die Orginalkarte deaktivieren. Hat jemand eine Idee oder auch Infos zum Aufbau der Dateistruktur und Bedeutung der internen Speicherdaten? Cu . **Michael* -- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Bernd Wurst schrieb: Die Funktionen zum Rückgängigmachen von Änderungen sind leider noch mangelhaft. Sehe ich nicht so. Bisher ist mir kein Fall bekannt, bei dem eine klar abgrenzbare Aktion (nach Zeit und Benutzer) nicht rückgängig gemacht werden konnte. Insbesondere wenn der Benutzer nur bestehende Werte verändert hat. Technisch möglich und für jedermann nutzbar sind zwei verschiedene Dinge. Es gibt keine Funktion undo this changeset oder revert to version X of this node die mir zu Augen gekommen wäre. Auf Seiten wie http://openstreetmap.org/browse/changeset/1199184 und http://openstreetmap.org/browse/way/28321003/history sollten solche Funktionen zur Verfügung stehen. In JOSM und Merkaartor gibt es da gar nichts und die Funktion in Potlach kann ich nur als rudimentär bezeichnen. Ich habe schon einige versehentliche Änderungen rückgängig gemacht, aber wir werden uns gezwungener Maßen auch mit absichtlichen Fehledits auseinandersetzen müssen. Erstens steht hier nirgendwas was vom Zurückschreiben der Werte und selbst wenn das jemand machen wollte, würde meiner Erfahrung nach keiner so beschränkt sein, abweichende, schon vorhandene Werte damit zu überschreiben. Das ist klar, aber auch das auffüllen noch nicht vorhandener Werte sollte vermieden werden. Sehe ich nicht so. So lange der theoretisch korrekte Wert (warum ist das so) in einem separaten Tag erhalten ist, sehe ich kein Problem darin, alle nicht anderweitig ausgeschilderten Innerorts-Straßen mit 50 zu markieren. 1. Das kann das auswertende Routingprogramm oder sein Präprozessor tun. Es gibt keinen Grund diese berechneten Werte zurück in die OSM-Datenbank zu schreiben. 2. Wenn irgendwo maxspeed=50 steht wird dieser Wert alt explizit getagged angenommen und nicht extra geprüft. Ein aus trafficzone=DE:city berechneter maxspeed=50 Wert, ist an vielen Stellen falsch, würde aber nicht zu einer überprüfung durch Mapper führen, sondern nur evtl. versehendlich von Navi-endbenutzern beim zufälligen abfahren der Straße entdeckt werden. 3. Programmierer von Routingprogrammen wären gut beraten, dem User mitzuteilen, das der maxspeed-Wert nicht explizit getagged wurde sondern nur vermutet wird. [...] IMHO stört das niemanden, so lange es richtige Werte sind. Ja, genau! Nur leider sind es eben oft falsche Werte. In einer noch nicht getaggeden 30-zone in einer Stadt würde der Navi Du darfst hier 50 fahren sagen. Besser wäre es wenn er sagt Du befindest dich in einer Ortschaft, genaue Geschwindigkeitslimits liegen nicht vor. Selbst ein Ich kenne das Limit nicht ist besser als dem User eine falsche Angabe zu machen. Siehe dazu auch Re: [Talk-de] Maxspeed map - Verkehrszeichen taggen! Per signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Log-Intervall
Garry schrieb: Meines Wissens gibt es (fast) keine GPS-Chips, die mehr als 1 Position Die genannten 4 Hz stehen auch im Datenblatt: http://www.u-blox.com/products/Data_Sheets/ATR0630_35_SglChip_Data_Sheet(GPS.G4-X-06009).pdf Den gibt es auch in Form einer USB-Maus von Conrad - wird zum Ausschlachten wegen der 4Hz auch gerne für Quaddrocopter genommen... Der u-blox ist z.B. auch in der bekannten Wintec WBT-201 verbaut... Alternative wäre der MTK Chipsatz, der z.B. in der Transystem BT747 enthalten ist: http://wiki.openstreetmap.org/wiki/GPS_Reviews#Transystem_i-Blue_747 Für die Speedfreaks: der kann 5 Positionen pro Sekunde speichern. Was die 747+ Version betrifft (neuer Chipsatz MTK v2-Chipsatz MTK 3329) kann ich aber nicht sagen, ob der auch bis 5Hz kann... MfG Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Original-Nachricht Datum: Fri, 15 May 2009 14:58:09 +0200 Von: Jonas Krückel o...@jonas-krueckel.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ? Auf jeden Fall denke ich, dass viel Potential vorhanden ist. Allerdings werden die Leute keine 12 verschiedenen Dächerformen (wie damals vorgeschlagen AFAIR) auseinanderhalten können und taggen wollen. Wenn dann ein einfaches, gut dokumentiertes und veranschaulichtes Schema. Meiner Ansicht nach brauchts drei Kriterien: - Die Unterscheidung von der Strasse aus und/oder Luftbild muss moeglich sein - Die Mehrzahl der Mapper soll die Formen einfach auseinanderhalten und einteilen koennen - Die Daecher muessen einfach zu parametrisieren sein, so dass ein 3-D-Renderer auch etwas damit anfangen kann. Ein nicht zu unterschaetzender Anfang waere die flaechendeckende Erfassung von Geschossanzahl und obs ein Flachdach oder Giebeldach ist. Alleine das gibt schon einen optischen Eindruck, der die Eigenheimsiedlung von Industriepark und Wohnhochhaeusern unterscheidbar macht (dargestellte Hoehe und graues oder rotes Dach). Das waere mein Vorschlag. Die beiden Parameter vergeben, durch die Visualisierung jagen, sehen wie es aussieht und dann ggf verfeinern. Gruesse Hubert -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
qbert biker schrieb: Original-Nachricht Datum: Fri, 15 May 2009 14:58:09 +0200 Von: Jonas Krückel o...@jonas-krueckel.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ? Auf jeden Fall denke ich, dass viel Potential vorhanden ist. Allerdings werden die Leute keine 12 verschiedenen Dächerformen (wie damals vorgeschlagen AFAIR) auseinanderhalten können und taggen wollen. Wenn dann ein einfaches, gut dokumentiertes und veranschaulichtes Schema. Meiner Ansicht nach brauchts drei Kriterien: - Die Unterscheidung von der Strasse aus und/oder Luftbild muss moeglich sein - Die Mehrzahl der Mapper soll die Formen einfach auseinanderhalten und einteilen koennen - Die Daecher muessen einfach zu parametrisieren sein, so dass ein 3-D-Renderer auch etwas damit anfangen kann. Ein nicht zu unterschaetzender Anfang waere die flaechendeckende Erfassung von Geschossanzahl und obs ein Flachdach oder Giebeldach ist. Alleine das gibt schon einen optischen Eindruck, der die Eigenheimsiedlung von Industriepark und Wohnhochhaeusern unterscheidbar macht (dargestellte Hoehe und graues oder rotes Dach). Das waere mein Vorschlag. Die beiden Parameter vergeben, durch die Visualisierung jagen, sehen wie es aussieht und dann ggf verfeinern. +1 Langsam anfangen und dann verfeinern, manch einer würde sagen, dass das der typische OSM-Weg ist ;-) Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Verkehrszeichen taggen
Thomas Ineichen schrieb: Hallo Per, maxspeed sollte immer explizit getagged werden, eine Relation boundary=traffic ist schön, besagt aber auch nicht mit Sicherheit das da nicht doch ein 30-Schild steht, sondern nur das die Straße sich innerhalb eines Ortes befindet und es für mach eine Navigationssoftware sinnvoll wäre dem Benutzer mitzuteilen, das hier evtl. eine maxspeed von 50 gelten könnte und das man ganz sicher kein Fernlicht verwenden darf. Kleine Nebenbemerkung: Fernlicht ist nur bei durchgehender, ausreichender Beleuchtung verboten. Bei unbeleuchteten Ortschaften darf also auch mit Fernlicht gefahren werden. Quelle: StVO Art 17(3) http://www.verkehrsportal.de/stvo/stvo_17.php Gruss, Thomas, der diesen Artikel gerade gestern per Zufall gelesen hat. Zur Unterscheidung hilft da dann ein lit=yes oder lit=no :) -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relationen-Listen (was: doppelte Relationen)
Hi, habe mal exemplarisch einige Listen mit Relationen erstellt. Ihr findet sie hier: http://wiki.openstreetmap.org/wiki/Relation_lists Wird wöchentlich aktualisiert. Dort könnt ihr nach Relationen suchen, bevor ihr welche anlegt. Namen und Refs sind angegeben. Format ist HTML oder CSV für Excel bzw. Open Office. Änderungswünsche...? Ciao Gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
qbert biker schrieb: Ein nicht zu unterschaetzender Anfang waere die flaechendeckende Erfassung von Geschossanzahl und obs ein Flachdach oder Giebeldach ist. Dazu sollten aber ansprechende Beispiele in den Mapfeatures niedergelegt werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Am Freitag 15 Mai 2009 16:58:01 schrieb Tobias Wendorff: qbert biker schrieb: Ein nicht zu unterschaetzender Anfang waere die flaechendeckende Erfassung von Geschossanzahl und obs ein Flachdach oder Giebeldach ist. Dazu sollten aber ansprechende Beispiele in den Mapfeatures niedergelegt werden. Ihr solltet einfach die schon vorhandenen Tags [1] nutzen, is ja nicht so als gäbe es das alles nicht schon seit langem. Nur die Renderer unterstützen das derzeit nicht. Es ist aber schon 1 großflächiger import gelaufen, der sich auf die unter [1] zu findenen Atrribute stützt. Gruß Jörg [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Building_attributes ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Hallo. Am Freitag 15 Mai 2009 16:24:32 schrieb Per: Technisch möglich und für jedermann nutzbar sind zwei verschiedene Dinge. Ja, ersteres ist wichtig, letzteres ist egal. Ich kann es auch nicht so direkt nutzen, aber so lange es eine ausreichende Zahl an Leuten gibt, die das können, ist das doch egal. Im Gegenteil, ich möchte dass Reverts nur gut überlegt gemacht werden. 1. Das kann das auswertende Routingprogramm oder sein Präprozessor tun. Es gibt keinen Grund diese berechneten Werte zurück in die OSM-Datenbank zu schreiben. Es gibt auch keinen Grund, ein Firmengelände zu micromappen, aber dennoch stört es wenig, wenn es einer macht. Du tust so, als würde irgendwas kaputt gehen, wenn mehrere Dinge parallel existieren. Das ist aber nicht so. 2. Wenn irgendwo maxspeed=50 steht wird dieser Wert alt explizit getagged angenommen und nicht extra geprüft. Ein aus trafficzone=DE:city berechneter maxspeed=50 Wert, ist an vielen Stellen falsch, würde aber nicht zu einer überprüfung durch Mapper führen, sondern nur evtl. versehendlich von Navi-endbenutzern beim zufälligen abfahren der Straße entdeckt werden. Ich glaube dass ein falscher Wert schneller korrigiert wird als ein fehlender eingetragen wird. Zudem glaube ich einfach nicht, dass es viele Stellen geben wird an denen jemand in einer eigentlichen 30er-Zone ein trafficzone:city:DE setzen würde ohne das maxspeed=30. 3. Programmierer von Routingprogrammen wären gut beraten, dem User mitzuteilen, das der maxspeed-Wert nicht explizit getagged wurde sondern nur vermutet wird. Hä? Es werden Daten angezeigt, die jemand eingetragen hat. Ich rechne damit, dass nur korrekte Daten und keine vermuteten Daten eingetragen werden. Ob jetzt eine eindeutige Implikation im Navi, in seiner Vorverarbeitung oder vom Mapper berechnet wurde, spielt dabei keine Rolle. [...] IMHO stört das niemanden, so lange es richtige Werte sind. Ja, genau! Nur leider sind es eben oft falsche Werte. Beispiel? Ich kenne bisher kein falsch eingetragenes maxspeed und kein falsch eingetragenes speedzone. Würde ich es kennen, würde ich es reparieren. In einer noch nicht getaggeden 30-zone in einer Stadt würde der Navi Du darfst hier 50 fahren sagen. Besser wäre es wenn er sagt Du befindest dich in einer Ortschaft, genaue Geschwindigkeitslimits liegen nicht vor. Selbst ein Ich kenne das Limit nicht ist besser als dem User eine falsche Angabe zu machen. Wenn jemand speedzone=city:DE setzt ohne zu wissen dass man da 50 fahren darf, dann ist das ein simpler Fehler in den Daten. Es gibt unendlich viele andere Fälle in denen jemand irgendwas falsch eintragen könnte. Ich verstehe nicht, was das damit zu tun hat. Gruß, Bernd -- Bahnübergänge sind die härtesten Drogen der Welt. Ein Zug und du bist weg! 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] ?OSM-Geb?ude in Google-Pseudo-3D ?
Am 15. Mai 2009 15:13 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Jonas Krückel schrieb: Ich habe mich irgendwann ausgeklinkt, als verschiedene Architekten über 100 verschiedene Dachformen diskutiert haben. Für diese Leute sollten wir eine SketchUp!-Untersützung integrieren :-) interessant wäre auf jeden Fall eine Unterstützung von gängigen Formaten zum Import (z.B. dxf). Die üblichen 3D-Modelle sind zwar von der Anzahl der Polygone etc. weit überdimensioniert, aber in Berlin z.B. (wenn ich mich recht erinnere) müssen Architekten wenn sie was bauen ein 3D-Modell digital zusätzlich einreichen für das 3D-Modell der Stadt. Wenn man die dazu bewegen könnte, zusätzlich bei uns die Modelle einzustellen, dann wäre das ziemlich cool und deren Zusatzaufwand gering. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Am 15. Mai 2009 14:58 schrieb Jonas Krückel o...@jonas-krueckel.de: Tobias Wendorff schrieb: Am Fr, 15.05.2009, 08:46 schrieb qbert biker: Noe, aber vielleicht mit 3 geangigen Dachformen? Sowas habe ich vor Wochen vorgeschlagen, hat aber keinen interessiert. Ich erinner mich an eine Diskussion vor Wochen (nicht sicher, ob du da dabei warst) Auf jeden Fall denke ich, dass viel Potential vorhanden ist. Allerdings werden die Leute keine 12 verschiedenen Dächerformen (wie damals vorgeschlagen AFAIR) auseinanderhalten können und taggen wollen. Wenn dann ein einfaches, gut dokumentiertes und veranschaulichtes Schema. man muss da halt unterscheiden: einfache symetrische Häuser mit Sattel- und Pultdächern (und Flachdach als Sonderform des Pultdachs mit gleicher Firsthöhe wie Traufhöhe) sind sicherlich die Mehrheit der gebauten Objekte. Da reichen 2-3 Standardformen gut aus. Für die restlichen, die in der Mehrheit Sonderbauten wie Schlösser, Kirchen, Museen, allg. größere Komplexe) etc. darstellen, und wo auch der Aussenraum räumlich evtl. wichtig ist (Terassen, Plätze, Unterführungen, Treppen, etc. eben eine gebaute räumliche Landschaft), bräuchte man echtes 3D (wobei Kirchturmspitzen sicherlich auch gut zu parametrisieren sind, und nach und nach könnten die einzelnen Länder typische Formen ergänzen). Gerade die letzteren sind halt die interessanteren, die den Wiedererkennungswert bestimmen. Manche Objekte lassen sich wohl auch nur über zusätzliche Texturen gut beschreiben (Säulen), s.z.B. wie es MS hier vormacht: http://maps.live.de/LiveSearch.LocalLive?cp=41.894714995740344~12.483527177618015scene=43152120style=blvl=1dir=0tilt=-90alt=-1000 (das mal so drehen, dass Osten in der Anzeige oben erscheint, wenn Ihr auf 3D Clickt und das Zeug installiert seht Ihr das entsprechende 3D-Modell). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Am 15. Mai 2009 08:46 schrieb qbert biker qbe...@gmx.de: ...dachgauben- und schornsteingenau! bei Kraftwerken sind die Schornsteine sicher wichtig. Auch Türme halte ich für wichtig, da sie auch aufgrund Ihrer Lage und Höhe leicht zu erkennen sind. Das ist eine Variable mit 3 Werten und ggf. kaeme dann noch die Ausrichtung dazu (node?). Bei den letzten beiden wuerde ich Ziegel als Default voraussetzen und Sondermaterialien (Schilf, etc.) kann man ja zusaetzlich anfuegen. Dachdeckung ist nochmal ein anderes Thema. Als Parameter würde ich Firsthöhe und Traufhöhe angeben, Neigung ergibt sich ja dann (bzw. alternativ nur eine der beiden Höhen und Neigung in Grad?) Was auch immer Sinn macht, ist die Geschossanzahl einzutragen, denn die ist ja einfach von der Strasse aus abzulesen. Und schon ist ein gut angenaehertes 3-D Modell ableitbar. ja, wobei hier ganz gut ist, grob zwischen 3m für Neubauten und 4 Metern für Altbauten zu unterscheiden. Bei Hallen, Kirchen, Säalen etc. versagt dieses Verfahren natürlich gänzlich (oder man gibt die Geschosshöhe zusätzlich an). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Martin Koppenhoefer schrieb: Am 15. Mai 2009 08:46 schrieb qbert biker qbe...@gmx.de: ...dachgauben- und schornsteingenau! bei Kraftwerken sind die Schornsteine sicher wichtig. Auch Türme halte ich für wichtig, da sie auch aufgrund Ihrer Lage und Höhe leicht zu erkennen sind. Kreis zeichnen, building=yes, height dranschreiben oderso. Dachdeckung ist nochmal ein anderes Thema. Als Parameter würde ich Firsthöhe und Traufhöhe angeben, Neigung ergibt sich ja dann (bzw. alternativ nur eine der beiden Höhen und Neigung in Grad?) Damit setzt Du wieder die Einfachheit des Systems schachmatt. Was auch immer Sinn macht, ist die Geschossanzahl einzutragen, denn die ist ja einfach von der Strasse aus abzulesen. Und schon ist ein gut angenaehertes 3-D Modell ableitbar. ja, wobei hier ganz gut ist, grob zwischen 3m für Neubauten und 4 Metern für Altbauten zu unterscheiden. Bei Hallen, Kirchen, Säalen etc. versagt dieses Verfahren natürlich gänzlich (oder man gibt die Geschosshöhe zusätzlich an). Dazu musst Du aber erstmal abschätzen können, um was für eine Bebauungsart es sich handelt ... Gründerzeitlich etc. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Martin Koppenhoefer schrieb: Wenn man die dazu bewegen könnte, zusätzlich bei uns die Modelle einzustellen, dann wäre das ziemlich cool und deren Zusatzaufwand gering. Würdest Du als Architekt es verschenken? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturschutzgebiete in Lübeck
Am 13. Mai 2009 11:24 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Falk Zscheile schrieb: Es gibt ein Proposal für landuse=conservation, das dafür passen würde. http://wiki.openstreetmap.org/wiki/Proposed_features/conservation Aber ein Landschaftsschutzgebiet ist doch gar keine ausschließliche Landnutzung. Ein LSG kann Wald, Wiese oder ein Dorf sein. Bei uns hier ist fast alles LSG. ja Sehr richtig! Deshalb wird auch ein tagging nach dem Muster boundary=nature_reserve, boundary=national_park etc. vorgeschlagen. Im Falle des LSG also etwa boundary=conservation_area o.ä. ja Was wird denn ausser boundary=national_park schon von den Renderen unterstützt? http://openstreetmap.org/?lat=28.69lon=-13.8456zoom=13layers=0B00FTF ich bin (wie schon öfters in diesem Zusammenhang dargelegt) auch in jedem Fall für ein boundary, bitte auf keinen Fall als landuse eintragen, das trifft es nicht (und sorgt für diverse Probleme s.o.im Thread). Wenn die Renderer das bisher nicht unterstützen müssen wir es ihnen eben beibringen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhlen / Höhleneingang
Am 12. Mai 2009 16:48 schrieb Stefan Dettenhofer (StefanDausR) o...@dentro.info: Markus schrieb: natural=cave natural=cave_entrance Die überwiegende Mehrheit der Tags ist cave_entrance. cave wurde ja abgelehnt: http://wiki.openstreetmap.org/wiki/Proposed_features/Cave das wurde ja nur in der vorgelegten Form abgelehnt (zu wenig beschrieben, zu ungenau), und auch dort nur 3 Neinstimmen, also eher wegen mangelnder Beteiligung. Die Ablehner haben z.T. auch schon Vorschläge in der hier vorgetragenen Art ergänzt. Da kann man also (wie sowieso immer) ohne weiteres eine verbesserte Version draus machen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aufkleber?
Am 13. Mai 2009 14:23 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Daher besser Vektorformat. Das kann man dann immer noch verlustfrei skalieren und mit vielen DPIs ausdrucken. Das stimmt leider nur bedingt. Wenn Du in einer SVG sagst, dass manche Linien nicht mitskaliert werden sollen oder schlecht vektorisierte Pfade drin hast, sieht das nach dem Skalieren einfach nur noch Scheiße aus. wenn man skaliert, dann natürlich alles. Ansonsten ist es ein Bedienfehler. Schlecht vektorisierte Pfade sind doch auch eher kein Argument, oder? Wenn Du eine Vektorgrafik in einer vernünftigen Anwendung skalierst ist das problemlos. Probleme kann es natürlich trotzdem geben, da beim Druck die Vektordatei in (fast) jedem Fall wieder gerastert wird, und sich da naturgemäß Probleme ergeben können (z.B. zu dünne Striche, inkompatible Farbräume, etc.) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aufkleber?
Martin Koppenhoefer schrieb: wenn man skaliert, dann natürlich alles. Er hat Skalierung als Vorteil angemerkt. Ansonsten ist es ein Bedienfehler. ?! Schlecht vektorisierte Pfade sind doch auch eher kein Argument, oder? Kein Argument wofür? Also für Skalierung schon. Wenn Du eine Vektorgrafik in einer vernünftigen Anwendung skalierst ist das problemlos. Skaliere bitte dieses Beispiel in einer vernünftigen Anwendung Deiner Art: http://depot.tu-dortmund.de/get/x2uaxl Probleme kann es natürlich trotzdem geben, da beim Druck die Vektordatei in (fast) jedem Fall wieder gerastert wird, und sich da naturgemäß Probleme ergeben können (z.B. zu dünne Striche, inkompatible Farbräume, etc.) Darum sprach ich von Absprache mit dem Dienstleister. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Bernd Wurst schrieb: Technisch möglich und für jedermann nutzbar sind zwei verschiedene Dinge. Ja, ersteres ist wichtig, letzteres ist egal. Troll? Ich kann es auch nicht so direkt nutzen, aber so lange es eine ausreichende Zahl an Leuten gibt, die das können, ist das doch egal. Es gibt ja noch nicht einmal ein offizielles Verfahren Revertwünsche zu äußern oder gar eine Liste von Leuten die das können. Von einer ausreichenden Zahl kann also noch gar nicht gesprochen werden. Ich habe wegen kleiner Revertwünsche niemanden gesucht, der das evtl. kann und andere tun das auch nicht. Bisher wurde vermutlich nur bei Spam und Botfehlern überhaupt mal revertiert. Anlässe dazu gibt es aber viel mehr. Im Gegenteil, ich möchte dass Reverts nur gut überlegt gemacht werden. Wenn man Reverts revertieren kann, dann ist es genau wie bei Wikipedia problemlos. Das kann das auswertende Routingprogramm oder sein Präprozessor tun. Es gibt keinen Grund diese berechneten Werte zurück in die OSM-Datenbank zu schreiben. Es gibt auch keinen Grund, ein Firmengelände zu micromappen, aber dennoch stört es wenig, wenn es einer macht. Was hat dies nun mit dem Thema zu tun? Du tust so, als würde irgendwas kaputt gehen, wenn mehrere Dinge parallel existieren. Das ist aber nicht so. Wenn man validierte mit vermuteten Daten in einem Tag (maxspeed) mischt, also z.B. aus trafficzone=DE:city abgeleitete maxspeed=50 Werte zurück in die Datenbank schreibt, dann macht man etwas kaputt! Wenn irgendwo maxspeed=50 steht dann bitte nur weil jemand Verkehrszeichen 274 gesehen hat und nicht weil jemand weiß das sich diese Straße zwischen Zeichen 310 und 311 befindet (also trafficzone=DE:city). Bist du der bisherigen Diskussion überhaupt gefolgt? Ich glaube dass ein falscher Wert schneller korrigiert wird als ein fehlender eingetragen wird. Ich nicht! Fehlende Werte kann man auf der maxspeed-Map schnell sehen, abfahren und dann eintragen. Falsche Werte kann man dort nicht erkennen. Zudem glaube ich einfach nicht, dass es viele Stellen geben wird an denen jemand in einer eigentlichen 30er-Zone ein trafficzone:city:DE setzen würde ohne das maxspeed=30. In der vorangegangene Diskussion wurde festgestellt, dass man es nicht speedzone sondern besser trafficzone nennt, da innerorts sich nicht nur auf maxspeed auswirkt. Damit ist trafficzone unabhängig von maxspeed zu taggen. Am besten tagged man beides. Programmierer von Routingprogrammen wären gut beraten, dem User mitzuteilen, das der maxspeed-Wert nicht explizit getagged wurde sondern nur vermutet wird. Hä? Es werden Daten angezeigt, die jemand eingetragen hat. Ich rechne damit, dass nur korrekte Daten und keine vermuteten Daten eingetragen werden. Ob jetzt eine eindeutige Implikation im Navi, in seiner Vorverarbeitung oder vom Mapper berechnet wurde, spielt dabei keine Rolle. Die Vermutung durch das Navi liegt in der Schlussfolgerung trafficzone=DE:city -- maxspeed=50 (falls der maxspeed-Wert fehlt und das Navi trafficzone mit auswertet). Korrekt eingetragene trafficzone-Werte lassen keinen sicheren Schluss auf die geltende maxspeed zu. Ich halte es sogar für sinnvoll maxspeed=DE:city trafficzone=DE:city parallel zu taggen. Aus ersterem leitet sich die Höchstgeschwindigkeit 50Km/h ab. Aus der trafficzone lassen sich Regeln fürs Parken und Fahrzeugbeleuchtung ableiten. Außerdem kann man bei fehlendem maxspeed-Tag eine Höchstgescwindikeit =50Km/h annehmen. Wie gesagt: Siehe Re: [Talk-de] Maxspeed map - Verkehrszeichen taggen Per ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aufkleber?
Am 15. Mai 2009 18:58 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Martin Koppenhoefer schrieb: wenn man skaliert, dann natürlich alles. Er hat Skalierung als Vorteil angemerkt. ist ja auch ein Vorteil. Aber man sollte natürlich nicht nur manches skalieren und anderes nicht (bei Linienstärken kommt es dazuhin auf die Einstellungen zum Skalieren an). Beispiel: man erstellt einen Aufkleber in 10x4 cm. Danach fällt dem Dienstleister (oder Vorlagenhersteller) auf, dass der Druckrand von 1 mm nicht berücksichtigt war, und daher nur 9,8 x 3,8 bedruckbar ist. Bei einem Bitmap wird das Ergebnis in jedem Fall schäbig, bei einem Vektor kein Problem, selbst wenn es eine Mülldatei wie die von Dir angehängte ist. Wenn Du eine Vektorgrafik in einer vernünftigen Anwendung skalierst, ist das problemlos. Skaliere bitte dieses Beispiel in einer vernünftigen Anwendung Deiner Art: http://depot.tu-dortmund.de/get/x2uaxl OK, ist im Anhang beigefügt. Die Datei ist total Müll, sicher aus einem PDF oder eps extrahiert, oder? Das Problem ist hier schon vorher: man muss natürlich auch eine vernünftige Vektordatei erstellen. Trotzdem ist auch mit dem Müll immer noch viel mehr zu machen als mit einem Bitmap (s. Anlage). Skalieren im kleinen Bereich (ein paar Prozent) geht immer und verschlechtert das Ergebnis (im Gegensatz zur Bitmap) überhaupt nicht. Und genau das ist ja der übliche Fall bei Drucken. Gruß Martin Grafik1_dd.wmf Description: Binary data ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Naturschutzgebiete in Lübeck
hi ! dann tragt doch bitte Eure Bedenken auf der Beschreibungsseite von Lübeck ein - ich bin dann gerne bereit die Tags in der nächsten Woche nochmal zu ändern. Dann ist der Überblick etwas einfacher - auch wenn keine Talk-Seite. hier noch einmal der Link: http://wiki.openstreetmap.org/wiki/L%C3%BCbeck/Schutzgebiete Gruß Jan :-) Martin Koppenhoefer schrieb: Am 13. Mai 2009 11:24 schrieb Chris-Hein Lunkhusen chris66...@gmx.de: Falk Zscheile schrieb: Es gibt ein Proposal für landuse=conservation, das dafür passen würde. http://wiki.openstreetmap.org/wiki/Proposed_features/conservation Aber ein Landschaftsschutzgebiet ist doch gar keine ausschließliche Landnutzung. Ein LSG kann Wald, Wiese oder ein Dorf sein. Bei uns hier ist fast alles LSG. ja Sehr richtig! Deshalb wird auch ein tagging nach dem Muster boundary=nature_reserve, boundary=national_park etc. vorgeschlagen. Im Falle des LSG also etwa boundary=conservation_area o.ä. ja Was wird denn ausser boundary=national_park schon von den Renderen unterstützt? http://openstreetmap.org/?lat=28.69lon=-13.8456zoom=13layers=0B00FTF ich bin (wie schon öfters in diesem Zusammenhang dargelegt) auch in jedem Fall für ein boundary, bitte auf keinen Fall als landuse eintragen, das trifft es nicht (und sorgt für diverse Probleme s.o.im Thread). Wenn die Renderer das bisher nicht unterstützen müssen wir es ihnen eben beibringen. Gruß Martin ___ 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] Probleme mit Fahrrad-Fußgänger-Rout ing etc.
Am 13. Mai 2009 16:10 schrieb Jürgen Frank o...@juergen-frank.de: Christoph könnte das Problem möglicherweise am einfachsten lösen, in dem er für verschiedene Anwendungen (Fahrrad, Fußgänger, Auto) unterschiedliche Layer verwendet, falls das Routing auch nur die Daten der aktiven Layer verwendet. Die Lösung kann also wohl (wenn nicht ne offene Firmware vom Himmel fällt) nur von Garmin kommen. Am besten dort ein Bug-Ticket einreichen... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Hallo. Am Freitag 15 Mai 2009 18:58:54 schrieb Per: Ich kann es auch nicht so direkt nutzen, aber so lange es eine ausreichende Zahl an Leuten gibt, die das können, ist das doch egal. Es gibt ja noch nicht einmal ein offizielles Verfahren Revertwünsche zu äußern oder gar eine Liste von Leuten die das können. Von einer ausreichenden Zahl kann also noch gar nicht gesprochen werden. Es gibt bei OSM für gar nichts ein offizielles Verfahren. Trotzdem bin ich lieber bei OSM aktiv als beim Finanzamt. Obwohl es dort offizielle Verfahren ohne Ende gibt. Hier wurde bisher jeder Revert-Wunsch von dem ich mitbekommen habe umgehend erledigt. Meistens von Frederik. So lange die Wünsche immer sofort umgesetzt wurden, ist die Zahl IMHO ausreichend. Anlässe dazu gibt es aber viel mehr. Beispiel? Im Gegenteil, ich möchte dass Reverts nur gut überlegt gemacht werden. Wenn man Reverts revertieren kann, dann ist es genau wie bei Wikipedia problemlos. Wikipedia hat mehr Edit-Wars als OSM. Meiner Meinung nach liegt das zu einem gewissen Teil auch daran, dass bei uns jeder Revert mit Arbeit verbunden ist und man daher naturgemäß mehr Zeit hat, sich zu überlegen wie wichtig einem die Änderung ist. Das kann das auswertende Routingprogramm oder sein Präprozessor tun. Es gibt keinen Grund diese berechneten Werte zurück in die OSM-Datenbank zu schreiben. Es gibt auch keinen Grund, ein Firmengelände zu micromappen, aber dennoch stört es wenig, wenn es einer macht. Was hat dies nun mit dem Thema zu tun? Es sind Daten, die dich (oder jemand anderen) augenscheinlich nicht interessieren. Dennoch ist es völlig egal, ob es da ist oder nicht. Du tust so, als würde irgendwas kaputt gehen, wenn mehrere Dinge parallel existieren. Das ist aber nicht so. Wenn man validierte mit vermuteten Daten in einem Tag (maxspeed) mischt, also z.B. aus trafficzone=DE:city abgeleitete maxspeed=50 Werte zurück in die Datenbank schreibt, dann macht man etwas kaputt! Darum plädiere ich mit allen Postings in diesem Thread dafür, dass man die neuen, aus Sicht mancher hier präziseren oder korrekteren Tags so designed, dass eine Koexistenz mit einem pragmatischen, einfachen, numerischen maxspeed möglich ist. Ich rede niemandem seine Sichtweise schlecht, im Gegenteil: Ich finde die Vorschläge gut. Nur diese egozentrische und kompromisslose Sichtweise (anders kann es gar nicht gehen) ist echt ätzend. Es *kann* beides geben. Und wenn man es sinnvoll designed, dann kann man auch einfach algorithmisch erkennen, was jetzt gilt und das maxspeed ggf. anders deuten, je nach dem was sonst noch so da ist. Bist du der bisherigen Diskussion überhaupt gefolgt? Ja, aber die Frage gebe ich gerne zurück. Ich bin es ja gewohnt, dass meine Postings inhaltlich ignoriert werden, aber ich glaube ich muss mir nicht vorwerfen lassen, dass ich den Thread nicht gelesen hätte. Meine Sicht der Dinge ganz kurz (und ein letztes Mal): Ich glaube nicht, dass das was hier diskutiert wird international an kommt. Kann man glauben, ich tu's nicht. Wenn jetzt jemand von hier ein Navi programmiert, wird er trafficzone=city:DE und/oder maxspeed=city:DE erwarten und auswerten. Ich würde das gerne unterstützen, weil ich es im Prinzip einen guten Vorschlag finde. Jetzt setzt sich das aber international nicht durch. Und ein amerikanischer Navi-Programmierer wertet nur numerische maxspeed aus, weil in Amiland nur numerische maxspeed vorhanden sind und er alles andere für unfug hält. Ich möchte gerne, dass meine Daten auch dort funktionieren. Ohne dass ich armer kleiner Mapper einen Preprozessor oder einen Konverter programmieren muss. Folglich tagge ich also maxspeed numerisch, weil das logischerweise immer jeder verstehen wird. Der Vorschlag hier ist in keiner Weise kompatibel zum bisherigen Vorgehen und das nervt mich so daran. Ich muss mich entscheiden, passe ich meine Daten auf das an was seit Jahren unangefochtener Konsens ist oder benutze ich werte, die mal eben auf einer regionalen Mailingliste von einer Hand voll Schreibtischtätern vorgeschlagen werden. Ich kann nicht beides machen um zu sehen was langfristig besser funktioniert. Ich glaube dass ein falscher Wert schneller korrigiert wird als ein fehlender eingetragen wird. Ich nicht! Fehlende Werte kann man auf der maxspeed-Map schnell sehen, abfahren und dann eintragen. Falsche Werte kann man dort nicht erkennen. Willst du mir erklären, dass du dich ins Auto setzt und anhand der maxspeed- Karte irgendwelche Stellen anfährst, die gar nicht zu deinem normalen Umfeld gehören? Korrekturen von einfachen Fehlern ist der Bereich in dem in Zukunft *jeder* mithelfen kann. Bei den Leuten die Lust haben sich mit komplexeren Dingen auseinander zu setzen ist bestimmt recht schnell eine Sättigung zu erkennen. Bei Dingen die jeder einzelne im Handumdrehen reparieren oder wenigstens berichten kann ist das anders. Bei da ist eine falsche Info würde ich sofort und
Re: [Talk-de] Naturschutzgebiete in Lübeck
Am 15. Mai 2009 19:34 schrieb Jan Tappenbeck o...@tappenbeck.net: hi ! dann tragt doch bitte Eure Bedenken auf der Beschreibungsseite von Lübeck ein - ich bin dann gerne bereit die Tags in der nächsten Woche nochmal zu ändern. wie schon dargelegt geht es mir (und wohl auch den anderen) nicht speziell um Lübeck, sondern darum, dass Schutzgebiet keine Landnutzung ist, vor allen Dingen, da Landnutzung bei vielen Tags auch wie Landbedeckung zu lesen ist. Ein Schutzgebiet ist eine rechtlich definierte Fläche, innerhalb derer mehrere landuse wie von uns verwendet vorkommen. Daher sollte es auch nicht allein angezeigt werden (als Fläche), sondern als Grenzumriss mit evtl. einer Schraffur, wo man aber die landuse noch durchsieht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Original-Nachricht Datum: Fri, 15 May 2009 17:51:13 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ? bei Kraftwerken sind die Schornsteine sicher wichtig. Auch Türme halte ich für wichtig, da sie auch aufgrund Ihrer Lage und Höhe leicht zu erkennen sind. Nix gegen Exoten, aber Schornsteine sind gegen die Masse an Wohn- und Geschäftshäusern eher vernachlässigbar. Die Frage ist, wie man einen Kompromiss zwischen exakter Abbildung und bildlicher Wiedererkennung erreichen kann. Google hat einen 3-D-Modeller dafür, OSM nach wie vor nur ein zweidimensionales Punkt-Strich-Konzept. Was man mit diesem 2D-Punkt-Strich-Konzept sicher erreichen kann, ist ein symbolische Darstellung 'das ist ein Wohnhaus', aber keine echte 3D-Modellierung. Dachdeckung ist nochmal ein anderes Thema. Es ist ein einfacher Parameter, den jeder Mapper setzen kann, der ein relativ grob aufgelöstes Luftbild als Vorgabe hat. Als Parameter würde ich Firsthöhe und Traufhöhe angeben, Neigung ergibt sich ja dann (bzw. alternativ nur eine der beiden Höhen und Neigung in Grad?) Schön, aber woher nimmst du die Daten dazu? Ich habe sie nicht. Ich kann von oben erkennen, ob das Dach flach ist oder Ziegel drauf hat und dann auch den Dachfirst. Ich kann die Stockwerke abzählen, weenn ich davorstehe und das wars dann. ja, wobei hier ganz gut ist, grob zwischen 3m für Neubauten und 4 Metern für Altbauten zu unterscheiden. Mal für mich persönlich gesprochen: Das ist mit schnurzegal, denn ich will ja keinen Flieger damit zwischen den Häusern metergenau fernsteuern ;) Wenn ich die ersten zaghaften Versuche der 3D-Visualisierung ansehe, ist erstmal jedes Dach rot. Ich denke doch, dass Gebäudehöhe und Dachfarbe hier einfach ein wenig Erkennungseffekt reinbringen könnten. Bei Hallen, Kirchen, Säalen etc. versagt dieses Verfahren natürlich gänzlich (oder man gibt die Geschosshöhe zusätzlich an). Das eine ist eine symbolische Darstellung von Standardformen, die sich zigtausendmal wiederholen, das andere ein echte 3D-Modellsprache. Beides hat seine Berechtigung aber alles mit einem Konzept zu erschlagen halte ich für eher schwierig bis unmöglich. Grüsse Hubert -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Am Freitag 15 Mai 2009 schrieb Garry: Da stellen sich mir alle Haare zu Berge... Höchstgeschwindigkeit=Stadt... Geschwindigkeit ist ein Wert der in Strecke pro Zeit definiert ist. Nichts anderes sollte hier zu finden sein! Dann kann man auch in 50 Jahren noch was mit den Daten anfangen! Wenn man erst anfangen muss zu rekonstruieren was damals town im Geschwindigkeitswert zu bedeuten hatte dann ist irgendwas falsch gelaufen... Implizieren kann man mit anderen Tags. Zuviel Intelligenz in die Tags packen zu wollen sorgt immer wieder zu unnötigen Fehlfunktionen wie es sich z.B. in fast regelmässigen Abständen bei den Waldflächen zeigt (siehe mal wieder: Schwarzwald und Mappnik). sorry, aber bist du jetzt wirklich so daemlich, oder tust du nur so!? dann nenn's meinetwegen in_town oder sonstwas. ich finde, town als wert ist einfach kurz, praegnant und klar. ausserdem dachte ich, das waere inzwischen lang und breit geklaert, warum rein numerische werte nicht ausreichend sind. aber nochmal extra fuer dich: der wert town bedeutet 50km/h weil innerorts, und nicht, weil ein 50-schild da steht. das ist klar und eindeutig. du bist es, der komplizierte fehlerhafte werte ableitet, in dem er z.B. maxspeed=7 fuer schrittgeschwindigkeit setzen will. 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] Maxspeed map - Kompromissvorschlag
Bernd Wurst schrieb: ... Ja, aber die Frage gebe ich gerne zurück. Ich bin es ja gewohnt, dass meine Postings inhaltlich ignoriert werden, aber ich glaube ich muss mir nicht vorwerfen lassen, dass ich den Thread nicht gelesen hätte. Meine Sicht der Dinge ganz kurz (und ein letztes Mal): Ich glaube nicht, dass das was hier diskutiert wird international an kommt. Kann man glauben, ich tu's nicht. Wenn jetzt jemand von hier ein Navi programmiert, wird er trafficzone=city:DE und/oder maxspeed=city:DE erwarten und auswerten. Ich würde das gerne unterstützen, weil ich es im Prinzip einen guten Vorschlag finde. Jetzt setzt sich das aber international nicht durch. Und ein amerikanischer Navi-Programmierer wertet nur numerische maxspeed aus, weil in Amiland nur numerische maxspeed vorhanden sind und er alles andere für unfug hält. Ich möchte gerne, dass meine Daten auch dort funktionieren. Ohne dass ich armer kleiner Mapper einen Preprozessor oder einen Konverter programmieren muss. Folglich tagge ich also maxspeed numerisch, weil das logischerweise immer jeder verstehen wird. Der Vorschlag hier ist in keiner Weise kompatibel zum bisherigen Vorgehen und das nervt mich so daran. Ich muss mich entscheiden, passe ich meine Daten auf das an was seit Jahren unangefochtener Konsens ist oder benutze ich werte, die mal eben auf einer regionalen Mailingliste von einer Hand voll Schreibtischtätern vorgeschlagen werden. Ich kann nicht beides machen um zu sehen was langfristig besser funktioniert. ... http://wiki.openstreetmap.org/wiki/Proposed_features/trafficzone Wir haben ja jetzt schon lang genug darüber hier in der Liste geschrieben und es reifen lassen. Vielleicht kann man es ja dem Rest der Welt auch näherbringen. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Am Freitag 15 Mai 2009 schrieb Mario Salvini: Garry schrieb: Mario Salvini schrieb: Damit das aber Sinn macht müsstest du dich von der Idee loslösen überamm maxspeed zu taggen, sondern nur da, wo auch echte Schilder stehen :). Warum? maxspeed ist für jeden Streckenabschnitt (in Deutschland) definiert, ob da ein Schild steht oder nicht. Die einzigen Ausnahmen sind die Autobahnen und autobahnähnliche ausgebaute Strassen. aber genau das wäre doch gerade der Benefit, dennn wir mit einem Wert wie trafficzone=* erreichen können. Eben alle implizierten Geschwindigkeiten mit einem Platzhalter wie in_city oder out_of_town zu erfassen. Außerorts müsste mann dann anstatt eigentlich maxspeed:motorcar=100, maxspeed:hgv=60, etc. nur ein trafficzone=out_of_town:DE zu taggen und der rest könne an einer zentralen Stelle (ähnlich wie die maxspeed-Defaults in der Wiki) erfaßt werden. Überleg Dir was das für Folgen hat: - Vielen werden für jede Strasse die sie bearbeiten so einen default-Wert eintragen weil es besser ist wie wenn gar nichts eingetragen ist. Wo schon etwas eingetragen ist werden viele Mapper nicht korrigieren da ja schon etwas eingetragen ist was plausibel erscheint - Erfassungsqualität sinkt. - Ein default-Wert der nicht in der Datenbank selbst vorhanden ist steht im Zweifelsfall gerade dann nicht zur Verfügung wenn man ihn braucht. - Eine Dokumentation der Veränderungen über die Zeit wird erheblich erschwert - bei diskreten maxspeed-Werten reicht ein einfaches sichern der Datenbank in regelmässigen Abständen, bei default-Wert im Web muss man eine ganze Menge mehr berücksichtigen und mit abspeichern was einem zum Zeipunkt der Sicherung häufig nicht bewusst sein wird. Garry Hi Garry, klar birgt diese Vorgehensweise gewisse Risiken. Besonders wenn die Dokumentation und Aufklärung der Methode nicht vernünftig betrieben wird. In meinen Augen sind die Vorteile die daraus entstehen aber signifikant größer. Nicht nur, dass wir endlch vernünftig erfassen können, ob eine Straße in der Stadt oder auswärts liegt. Wir können mit diesem Tag (nennen wir hn z.B. trafficzone) auch definieren welche Wege in der Datenbank überhaupt zum Straßenverkehrsnetz gehören - z.B. gesperrte Servicewege, Einfahrte, Feldwege (z.B. mit Zeichen 250). Außerdem hätte das mappen von trafficzone=* ja nur indirekt etwas mit maxspeed zu tun. Die Frage, ob man bestehende Werte von maxspeed korrigiert hat eher was damit zu tun welcher Tag-Philosophie man folgt (ich nutze maxspeed z.B. ausschließlich nur für explizite Beschränkungen und bin da bei mir in der Gegend scheinbar nicht der Einzige). Die Lücke die dabei bis jetzt geklafft hat, nicht zu wissen was denn auf den Straßen ohne Angabe gilt, schließt dafür ja die trafficzone; wenn auch nicht vielleicht mit einem konkreten Wert, sondern eben mit einem Platzhalter der für ein Bündel von Eigenschaften steht (im Grunde genau wie alle anderen nicht-numerischen Values) also wenn's NUR um das taggen von bestimmten attributen wie geschwindigket, parkverbot, geewichtsbeschraenkungen (meinetwegen auch als zone) geht, wuerde ich das jeweils entsprechende bekannte tag nehmen, also z.B. eben maxspeed fuer die geschwindigkeit. wenn aber ein bereich eine kombination von mehreren verschiedenen attributen enthaelt, und dieser bereich auch landesweit eindeutig definiert ist (z.B. die geschlossene ortschaft), dann finde ich ein tag wie zone=town durchaus sinnvoll. wobei ich da dann aber nicht trafficzone= nehmen wuerde, sondern eher ein allgemeines zone=, evtl noch ein zone:traffic fuer eine nur den verkehr betreffende zone... 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] Maxspeed map - Kompromissvorschlag
Am Freitag 15 Mai 2009 schrieb Bernd Wurst: Hallo. Am Freitag 15 Mai 2009 16:10:08 schrieb Mario Salvini: es gilt nicht implizierte maxspeed=100 für alle, sondern nur maxspeed:motorcar=100, maxspeed:hgv=60, etc. Fällt dir für etc noch etwas ein? Ich weiß noch von pkw mit anhänger = 80, aber da wüsste ich kein tag für. genau deswegen ist es doch einfacher, das mit maxspeed=out_of_town zu erschlagen. die dann geltenden geschwindigkeiten von 60/80/100 sind definiert fuer diesen bereich, und die jeweilige fahrzeugklasse nimmt sich das fuer sie geltende raus. 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] Maxspeed map - Kompromissvorschlag
Am Freitag 15 Mai 2009 schrieb Per: Ja, genau! Nur leider sind es eben oft falsche Werte. In einer noch nicht getaggeden 30-zone in einer Stadt würde der Navi Du darfst hier 50 fahren sagen. Besser wäre es wenn er sagt Du befindest dich in einer Ortschaft, genaue Geschwindigkeitslimits liegen nicht vor. Selbst ein Ich kenne das Limit nicht ist besser als dem User eine falsche Angabe zu machen. das wuerde ich niocht so sagen: wenn's ein normaler user ist, wird sich dieser so oder so uber das navi aergern. ein ich weiss es nicht ist da nicht besser als eine falschangabe. wenn's ein mapper ist, dann wird am ehesten auf den fehler aufmerksam (und kann ihn korrigieren), wenn er ihm mitgeteilt wird. abgesehen davon muessen sich beide an das 30-zone schild halten, das sie vor der nase haben; egal was das navi sagt... 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] ?OSM-Geb?ude in Google-Pseudo-3D ?
Am Freitag 15 Mai 2009 schrieb Jonas Krückel: qbert biker schrieb: Original-Nachricht Datum: Fri, 15 May 2009 14:58:09 +0200 Von: Jonas Krückel o...@jonas-krueckel.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ? Auf jeden Fall denke ich, dass viel Potential vorhanden ist. Allerdings werden die Leute keine 12 verschiedenen Dächerformen (wie damals vorgeschlagen AFAIR) auseinanderhalten können und taggen wollen. Wenn dann ein einfaches, gut dokumentiertes und veranschaulichtes Schema. Meiner Ansicht nach brauchts drei Kriterien: - Die Unterscheidung von der Strasse aus und/oder Luftbild muss moeglich sein - Die Mehrzahl der Mapper soll die Formen einfach auseinanderhalten und einteilen koennen - Die Daecher muessen einfach zu parametrisieren sein, so dass ein 3-D-Renderer auch etwas damit anfangen kann. Ein nicht zu unterschaetzender Anfang waere die flaechendeckende Erfassung von Geschossanzahl und obs ein Flachdach oder Giebeldach ist. Alleine das gibt schon einen optischen Eindruck, der die Eigenheimsiedlung von Industriepark und Wohnhochhaeusern unterscheidbar macht (dargestellte Hoehe und graues oder rotes Dach). Das waere mein Vorschlag. Die beiden Parameter vergeben, durch die Visualisierung jagen, sehen wie es aussieht und dann ggf verfeinern. +1 Langsam anfangen und dann verfeinern, manch einer würde sagen, dass das der typische OSM-Weg ist ;-) Gruß Jonas ja, klingt gut. 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] ?OSM-Geb?ude in Google-Pseudo-3D ?
Am Freitag 15 Mai 2009 schrieb Jonas Krückel: qbert biker schrieb: Original-Nachricht Datum: Fri, 15 May 2009 14:58:09 +0200 Von: Jonas Krückel o...@jonas-krueckel.de An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ? Auf jeden Fall denke ich, dass viel Potential vorhanden ist. Allerdings werden die Leute keine 12 verschiedenen Dächerformen (wie damals vorgeschlagen AFAIR) auseinanderhalten können und taggen wollen. Wenn dann ein einfaches, gut dokumentiertes und veranschaulichtes Schema. Meiner Ansicht nach brauchts drei Kriterien: - Die Unterscheidung von der Strasse aus und/oder Luftbild muss moeglich sein - Die Mehrzahl der Mapper soll die Formen einfach auseinanderhalten und einteilen koennen - Die Daecher muessen einfach zu parametrisieren sein, so dass ein 3-D-Renderer auch etwas damit anfangen kann. Ein nicht zu unterschaetzender Anfang waere die flaechendeckende Erfassung von Geschossanzahl und obs ein Flachdach oder Giebeldach ist. Alleine das gibt schon einen optischen Eindruck, der die Eigenheimsiedlung von Industriepark und Wohnhochhaeusern unterscheidbar macht (dargestellte Hoehe und graues oder rotes Dach). Das waere mein Vorschlag. Die beiden Parameter vergeben, durch die Visualisierung jagen, sehen wie es aussieht und dann ggf verfeinern. +1 Langsam anfangen und dann verfeinern, manch einer würde sagen, dass das der typische OSM-Weg ist ;-) Gruß Jonas ja, klingt gut! ich wuerde folgende tags vorschlagen: fuer die geschosse: floors = [1-xxx] fuer die dachformen (erstmal nur die drei angesprochenen, naemlich flach-, sattel- und walmdach): roof:type = flat|gable|hipped root:orientation = ??? 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] Relationen-Listen (was: doppelte Relationen)
habe mal exemplarisch einige Listen mit Relationen erstellt. Ihr findet sie hier: http://wiki.openstreetmap.org/wiki/Relation_lists Wird wöchentlich aktualisiert. Dort könnt ihr nach Relationen suchen, bevor ihr welche anlegt. Namen und Refs sind angegeben. Format ist HTML oder CSV für Excel bzw. Open Office. Änderungswünsche...? Eine kleine Statistik fänd ich noch interessant. Also Gesamtzahl der Relationen in einem Land und dann aufgeschlüsselt nach type. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relevanz, OSM und Wikipedia
Garry schrieb: In diesem Zug währe dann auch gleich eine Definition für Hochwassergefährdete Strassen und Wege sinnvoll - also die, die von einem normalen jährlichen Hochwasser betroffen sind. BTW: da fällt mir ein Schild in meiner Nähe ein Überflutung bei Regen. Ich kann ja mal ein Foto machen, fahre da so ca. 1 mal pro Woche vorbei. Ich werde es mir sparen, dies mangels Tags zu mappen... MfG Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Bernd Wurst schrieb: Es gibt ja noch nicht einmal ein offizielles Verfahren Revertwünsche zu äußern oder gar eine Liste von Leuten die das können. Von einer ausreichenden Zahl kann also noch gar nicht gesprochen werden. Es gibt bei OSM für gar nichts ein offizielles Verfahren. Trotzdem bin ich lieber bei OSM aktiv als beim Finanzamt. Obwohl es dort offizielle Verfahren ohne Ende gibt. Das ist doch pedantisch sich am Wort offiziell zu reiben! Es wird unerfahrenen OSM-Usern keine Hilfestellung gegeben, wenn sie etwas rückgängig machen wollen Ist das Satz so besser? Hier wurde bisher jeder Revert-Wunsch von dem ich mitbekommen habe umgehend erledigt. Meistens von Frederik. So lange die Wünsche immer sofort umgesetzt wurden, ist die Zahl IMHO ausreichend. Wenn man den Passierschein A 38 nur gut genug versteckt, dann füllt ihn hoffentlich auch keiner aus. Anlässe dazu gibt es aber viel mehr. Beispiel? Hab ich! Und selbst? Guck dir mal die History der B 76 an... Im Gegenteil, ich möchte dass Reverts nur gut überlegt gemacht werden. Wenn man Reverts revertieren kann, dann ist es genau wie bei Wikipedia problemlos. Wikipedia hat mehr Edit-Wars als OSM. Edit-Wars funktionieren auch ganz gut ohne revertieren! Ich behaupte die höhere Anzahl der Edit-Wars liegt nur an der leichteren Zugänglichkeit und der höheren Useranzahl. Das kann das auswertende Routingprogramm oder sein Präprozessor tun. Es gibt keinen Grund diese berechneten Werte zurück in die OSM-Datenbank zu schreiben. Es gibt auch keinen Grund, ein Firmengelände zu micromappen, aber dennoch stört es wenig, wenn es einer macht. Was hat dies nun mit dem Thema zu tun? Es sind Daten, die dich (oder jemand anderen) augenscheinlich nicht interessieren. Dennoch ist es völlig egal, ob es da ist oder nicht. Ok, bezogen auf unser Thema würde es bedeuten aus trafficzone=DE:city abgeleitete Höchstgeschwindigkeiten nicht in maxspeed sondern in einem bisher ungenutzten Key (z.B. maxspeed:default) zu speichern. Ja, der könnte mir dann völlig egal sein... Bist du der bisherigen Diskussion überhaupt gefolgt? Ja, aber die Frage gebe ich gerne zurück. Ich bin es ja gewohnt, dass meine Postings inhaltlich ignoriert werden, aber ich glaube ich muss mir nicht vorwerfen lassen, dass ich den Thread nicht gelesen hätte. Seit dem 30.4. Das war nun mal mein Eindruck, da du augenscheinlich speedzone und trafficzone durcheinander gebracht hast. trafficzone soll nur außerorts, innerorts und motorway auseinander halten. Damit hat der Tag nur indirekt etwas mit der Höchstgeschwindigkeit zu tun. Du scheinst verhindern zu wollen, dass Textwerte für maxspeed verwendet werden und willst deshalb Werte wie Höchstgeschwindigkeit deutscher Ortschaften in einen separaten Key auslagern und diesen dann z.B. speedzone nennen. Meine Sicht der Dinge ganz kurz (und ein letztes Mal)[...] OK... *zone* ist nur sinnvoll um Stadnardwerte anzunehmen, wenn maxspeed nichts gesetzt ist. Eine sinnvolle alternative für maxspeed=city:DE könnte maxspeed:sign=city:DE sein. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Guenther Meyer schrieb:
Am Freitag 15 Mai 2009 schrieb Per:
Ja, genau! Nur leider sind es eben oft falsche Werte.
In einer noch nicht getaggeden 30-zone in einer Stadt würde der Navi Du
darfst hier 50 fahren sagen. Besser wäre es wenn er sagt Du befindest
dich in einer Ortschaft, genaue Geschwindigkeitslimits liegen nicht
vor. Selbst ein Ich kenne das Limit nicht ist besser als dem User
eine falsche Angabe zu machen.
das wuerde ich niocht so sagen:
wenn's ein normaler user ist, wird sich dieser so oder so uber das navi
aergern. ein ich weiss es nicht ist da nicht besser als eine falschangabe.
wenn's ein mapper ist, dann wird am ehesten auf den fehler aufmerksam (und
kann ihn korrigieren), wenn er ihm mitgeteilt wird.
abgesehen davon muessen sich beide an das 30-zone schild halten, das sie vor
der nase haben; egal was das navi sagt...
ein eine Software auch z.B. trafficzone ausliest und da steht
trafficzone=DE:city und die Software aus seiner Datentabelle herausliest:
wo traffoczone=out_of_town da gilt {
maxspeed:motorcar=100
maxspeed:hgv=100
maxspeed:bicycle=no
...
dann braucht man nur noch in den Grunfeinstellungen der Software
definieren, was mann denn nun ist Bin ich ein Auto oder Bin ich ein
LKW, Bin ich ein Fahrrad?
Dann ist jede weitere Angabe am Weg wie ein globales maxspeed=100 nur
missverständlich und überföüssig, es sei denn es ist eine explizit
ausgeschilderte Begrenzung.
Insofern gibt es kein weiß ich nicht wenn ein trafficzone=out_of_town
zu finden ist, denn diese Angabe bedeutet ein Bündel von klar gesetzen
Werten.
Gruß
Mario
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Per schrieb: ... Meine Sicht der Dinge ganz kurz (und ein letztes Mal)[...] OK... *zone* ist nur sinnvoll um Stadnardwerte anzunehmen, wenn maxspeed nichts gesetzt ist. Eine sinnvolle alternative für maxspeed=city:DE könnte maxspeed:sign=city:DE sein. trafficzone + zusätzliches maxspeed macht bei expliziten Begrezungen sehr wohl Sinn. Z.B. bei trafficzone=DE:in_town + maxspeed=30 oder aber auch ber trafficzone=DE:in_town + maxspeed=70 Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mal wieder: Mapnik und Schwarzwald
Am 14. Mai 2009 09:13 schrieb Frank Sautter openstreet...@sautter.com: Sven Geggus schrieb: beim Schwarzwald Multipolygon hat sich imemr noch nix getan. Alle Dörfer sind im Grünen. Ist das Multipolygon falsch oder ist Mapnik buggy? Mein See mit Inseln wird ja auch korrekt dargestellt: http://www.openstreetmap.org/?lat=49.09674lon=8.54871zoom=16layers=B000FTF das problem existiert, seitdem mapnik innerhalb ein paar stunden neu rendert sobald daten geändert wurden... irgendwie hat er da probleme mit den multipolygonen. wenn der komplette datensatz neu gerendert wird, ist es dann wieder bis zur näxten änderung ok. ich wäre mir da nicht so sicher. Habe das Colosseum am 3. Mai zum Verschwinden gebracht: http://tools.geofabrik.de/map/?type=Mapniklon=12.49221lat=41.89033zoom=17 und ist immer noch weg auf der Mapnik-Karte. Habe schon ein trac-ticket erstellt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Am 15. Mai 2009 19:50 schrieb Bernd Wurst be...@bwurst.org: Ich glaube nicht, dass das was hier diskutiert wird international an kommt. Kann man glauben, ich tu's nicht. Ich denke schon, und da die community derzeit in Deutschland am größten ist bedeutet das durchaus auch eine Chance, manche Bereiche schonmal so vorzubereiten, dass man in anderen Ländern darauf aufbauen kann. Wenn jetzt jemand von hier ein Navi programmiert, wird er trafficzone=city:DE und/oder maxspeed=city:DE erwarten und auswerten. Ich würde das gerne unterstützen, weil ich es im Prinzip einen guten Vorschlag finde. eben. Jetzt setzt sich das aber international nicht durch. Und ein amerikanischer Navi-Programmierer wertet nur numerische maxspeed aus, weil in Amiland nur numerische maxspeed vorhanden sind und er alles andere für unfug hält. Die Amerikaner und alle anderen Staaten wo ich schon war haben alle eine allgemeine Geschwindigkeitsbegrenzung innerorts, wir stehen also nicht alleine mit diesem Problem, und wer ein Navi programmiert wird sich damit zurechtfinden müssen. Ich möchte gerne, dass meine Daten auch dort funktionieren. Ohne dass ich armer kleiner Mapper einen Preprozessor oder einen Konverter programmieren muss. Folglich tagge ich also maxspeed numerisch, weil das logischerweise immer jeder verstehen wird. ja, allerdings wird man es falsch verstehen, oder zumindest weniger daraus ablesen können, und bei Gesetzesänderungen große Probleme bekommen. Der Vorschlag hier ist in keiner Weise kompatibel zum bisherigen Vorgehen und das nervt mich so daran. Ich muss mich entscheiden, passe ich meine Daten auf das an was seit Jahren unangefochtener Konsens ist oder benutze ich werte, die mal eben auf einer regionalen Mailingliste von einer Hand voll Schreibtischtätern vorgeschlagen werden. Ich kann nicht beides machen um zu sehen was langfristig besser funktioniert. die Vorteile des Unterscheidens von explizit und implizit bei maxspeed-Werten liegen nach der Diskussion hier doch auf der Hand. Das bisherige Vorgehen berücksichtigt (auf alle unsere Daten gesehen) gar nicht so viele Details, meist sind erstmal nur die Straßen mit Namen da. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neues beim Tag information=*
Am 15. Mai 2009 11:45 schrieb André Riedel riedel.an...@gmail.com: Hallo, es gibt neue Werte beim Proposal information=*. Dieser Vorschlag dient zur genaueren Unterscheidung von verschiedenen Punkten, welche mit tourism=information getaggt sind. Bitte schaut daher noch einmal vorbei und gebt eure Meinung dazu ab. habe mal sitemap ergänzt für eine Karte eines bestimmten Gebiets, z.B. Ausgrabungsgelände, Kloster, Eurodisney, etc. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wordfile über Bittorrent
Am 15. Mai 2009 09:11 schrieb Lutz Horn lutz.h...@fastmail.fm: Alternativ gibt es auch einen Eintrag bei mininova: http://www.mininova.org/tor/2592546 der bei mininova ist offline: Torrent not found... The torrent you requested (id: 2592546) does not exist in our database. This could mean that: * The torrent was old, and automatically removed by our system. This happens if no torrent activity is recorded for a while. * The torrent was removed by one of our moderators, for example because we received complaints from users. * We received a copyright takedown request, and removed the torrent in compliance with our copyright policy. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] US-Behörde befürchtet GPS-Ausf älle
Am 15. Mai 2009 12:22 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Das bin ich auch! Ich denke, dass der Bussinessplan von Galileo so nicht aufgehen kann. Open Soucre Stacks zum Empfang von GPS-Signalen per Software defined Radio gibt es AFAIK bereits. Der Businessplan eines Produkts, für das seit einiger Zeit auch geplant ist, dass es den Militärs zur Verfügung stehen wird, und das von so vielen Ländern getragen wird, wird schon aufgehen, da ist m.E. das Interesse zu groß dran. Ob es für uns was bringen wird, weiss ich dagegen nicht. Wir haben mit GPS ja im Wesentlichen schon das, was wir brauchen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Am 15. Mai 2009 18:09 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: - Zitierten Text anzeigen - Martin Koppenhoefer schrieb: Wenn man die dazu bewegen könnte, zusätzlich bei uns die Modelle einzustellen, dann wäre das ziemlich cool und deren Zusatzaufwand gering. Würdest Du als Architekt es verschenken? ein einfaches Volumenmodell mit sehr wenigen Punkten und Flächen? Wenn es sowie im Genehmigungsvorgang anfällt, man hat ja auch was davon (Dein Haus ist in OSM): ja Die Grundlage für ein Rendering oder den kompletten Satz Ausführungspläne würde man nicht verschenken (nicht mal in Auszügen), aber so ein rudimentäres Volumenmodell? Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ?OSM-Geb?ude in Google-Pseudo-3D ?
Am 15. Mai 2009 20:36 schrieb qbert biker qbe...@gmx.de: bei Kraftwerken sind die Schornsteine sicher wichtig. Auch Türme halte ich für wichtig, da sie auch aufgrund Ihrer Lage und Höhe leicht zu erkennen sind. Nix gegen Exoten, aber Schornsteine sind gegen die Masse an Wohn- und Geschäftshäusern eher vernachlässigbar. ja, aber was soll man mit einer Masse an vereinfachten Einfamilienhäusern anfangen? Solange die einzelnen Besonderheiten (Gauben, Erker, Balkone, Fassaden) fehlen, ist das einfach nur langweilig, dient nicht der Orientierung, ... Die Frage ist, wie man einen Kompromiss zwischen exakter Abbildung und bildlicher Wiedererkennung erreichen kann. Google hat einen 3-D-Modeller dafür, OSM nach wie vor nur ein zweidimensionales Punkt-Strich-Konzept. Dachdeckung ist nochmal ein anderes Thema. Es ist ein einfacher Parameter, den jeder Mapper setzen kann, der ein relativ grob aufgelöstes Luftbild als Vorgabe hat. Interessant wären hier m.E. z.B. Dachterrassen und zugängliche Dächer, aber da müsste man auch schon wieder in Regionen vorstoßen, wo unsere Auflösung eigentlich gar nicht ausreicht. Als Parameter würde ich Firsthöhe und Traufhöhe angeben, Neigung ergibt sich ja dann (bzw. alternativ nur eine der beiden Höhen und Neigung in Grad?) Schön, aber woher nimmst du die Daten dazu? Ich habe sie nicht. Ich kann von oben erkennen, ob das Dach flach ist oder Ziegel drauf hat und dann auch den Dachfirst. Ich kann die Stockwerke abzählen, weenn ich davorstehe und das wars dann. ja, und damit kannst Du dann Traufhöhe und Firsthöhe schätzen. ja, wobei hier ganz gut ist, grob zwischen 3m für Neubauten und 4 Metern für Altbauten zu unterscheiden. Mal für mich persönlich gesprochen: Das ist mit schnurzegal, denn ich will ja keinen Flieger damit zwischen den Häusern metergenau fernsteuern ;) Es ändert die Proportionen halt gewaltig, ob das Haus 12 oder 16 m hoch ist. Wirst Du dann sehen. Auch ist es gerade in im Zusammenhang bebauten Gegenden durchaus machbar, relative Unterschiede zu erkennen (z.B. dieses Dach ist ca. 1 m niedriger als das daneben), denn gerade diese kleinen Details machen viel aus, um später eine Situation wiederzuerkennen. Bei Hallen, Kirchen, Säalen etc. versagt dieses Verfahren natürlich gänzlich (oder man gibt die Geschosshöhe zusätzlich an). Das eine ist eine symbolische Darstellung von Standardformen, die sich zigtausendmal wiederholen, das andere ein echte 3D-Modellsprache. Beides hat seine Berechtigung aber alles mit einem Konzept zu erschlagen halte ich für eher schwierig bis unmöglich. so unmöglich denke ich nicht, dass es ist. Gerade die allermeisten Kirchen könnte man sicher mit ein paar wenigen Parametern in den Griff bekommen, und da sie meist die höchsten und prägnantesten Gebäude sind, spielen sie für das Aussehen eine große Rolle. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Verkehrszeichen taggen
Eine Autobahn wird begrenzt durch die Zeichen 330 und 334. ja, das braucht man allerdings nicht mappen, da es sich aus dem highway bereits ergibt, oder wie machst Du das? out_of_town mag richtig sein, aber land ist nicht falsch und zudem noch schön kurz. naja, wenn Du schon deutsche Wörter in die Tags schreiben willst, dann bitte wenigstens mit DE: davor. Mir wäre es lieber, wenn wir für so was allgemein übliches auch einen englischen Ausdruck finden könnten, deutsch können halt dann doch weniger Leute als Englisch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Hallo. Deine Mails kommen nicht nur an mich als Kopie sondern sie kommen bei mir auch noch doppelt (plus einmal über die Liste) an. Das passiert nur bei deinen Mails. Kannst du das bitte irgendwie abstellen? Am Samstag 16 Mai 2009 00:29:53 schrieb Per: Das ist doch pedantisch sich am Wort offiziell zu reiben! Es wird unerfahrenen OSM-Usern keine Hilfestellung gegeben, wenn sie etwas rückgängig machen wollen Ist das Satz so besser? Der Satz ist besser, die Aussage aber jetzt IMHO falsch. Also ja, um etwas rückgängig zu machen gibt es keine Anleitungen. Aber um etwas rückgängig gemacht zu bekommen braucht man keine Anleitung sondern einfach diese Mailingliste als Ansprechpartner für alles was man wissen will. Grade bei unerfahrenen Mappern würde ich nicht wollen, dass die einfach alles rückgängig machen können. Man muss das Prinzip / Chaos OSM ne Weile ertragen um die Gelassenheit zu entwickeln dass man andere Leute auch unkonventionelle Dinge ausprobieren lässt. Hier wurde bisher jeder Revert-Wunsch von dem ich mitbekommen habe umgehend erledigt. Meistens von Frederik. So lange die Wünsche immer sofort umgesetzt wurden, ist die Zahl IMHO ausreichend. Wenn man den Passierschein A 38 nur gut genug versteckt, dann füllt ihn hoffentlich auch keiner aus. Mir ist der Fortschritt wichtiger als ein Rückschritt. Ich finde es beim OSM-Arbeitsmodell akzeptabel wenn eine Rückgängigmachung immer irgendwo diskutiert wird und nicht einfach nur per Klick von zu Hause aus geht. Es passiert zu oft, dass Leute Dinge total sinnlos finden, die Änderung aber irgendwie doch Sinn macht. Neu-Mapper kann man super vergrämen in dem man einfach immer gleich alles rückgängig macht, was sie ändern. Edit-Wars funktionieren auch ganz gut ohne revertieren! Ich behaupte die höhere Anzahl der Edit-Wars liegt nur an der leichteren Zugänglichkeit und der höheren Useranzahl. Das ist auch ein wichtiger Grund, klar. Deshalb schrieb ich auch. Du schreibst nur und das glaube ich nicht. Ok, bezogen auf unser Thema würde es bedeuten aus trafficzone=DE:city abgeleitete Höchstgeschwindigkeiten nicht in maxspeed sondern in einem bisher ungenutzten Key (z.B. maxspeed:default) zu speichern. Ja, der könnte mir dann völlig egal sein... Genau. Oder man definiert die neuen Tags so, dass aus den Tags alleine genug Information hervorgeht um zu entscheiden ob maxspeed jetzt implizit oder explizit ist. Also ob man es besser ignorieren sollte oder nicht. Das war nun mal mein Eindruck, da du augenscheinlich speedzone und trafficzone durcheinander gebracht hast. Hm, okay, die genauen Begriffe waren für mich immer komische Kunstworte die etwas nach ein Deutscher schaut im Wörterbuch klingen. Deren Schreibweise habe ich keine besondere Aufmerksamkeit gewidmet, da das alles am Prinzip und meiner Kritik an dem Vorgehen nichts ändert. Du scheinst verhindern zu wollen, dass Textwerte für maxspeed verwendet werden und willst deshalb Werte wie Höchstgeschwindigkeit deutscher Ortschaften in einen separaten Key auslagern und diesen dann z.B. speedzone nennen. Ich möchte, dass es für die Praxistestphase der hier vorgeschlagenen Tags möglich ist, diese Tags zu benutzen ohne dass ein parallel gesetztes maxspeed damit interferiert. Meine Sicht der Dinge ganz kurz (und ein letztes Mal)[...] OK... *zone* ist nur sinnvoll um Stadnardwerte anzunehmen, wenn maxspeed nichts gesetzt ist. Eine sinnvolle alternative für maxspeed=city:DE könnte maxspeed:sign=city:DE sein. Sowas in der Art, ja. Gruß, Bernd -- Ein kluger Mann widerspricht nie einer Frau. Er wartet bis sie es selbst tut. - Humphrey Bogart (am. Schauspieler 1899-1957) 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
