[Talk-de] Kontakte zum ADFC Nürnberg (was: N eue Mailingliste Franken)
Ulf Lamping ulf.lamp...@googlemail.com writes: [...] Ein Schwerpunkt wird wahrscheinlich der Raum Nürnberg/Fürth/Erlangen bilden, aber es sind auch Leute aus anderen fränkischen Gegenden gern gesehen. Jetzt bin ich auf der Regionalseite gelandet und habe mir die ADFC-Sachen angesehen. http://wiki.openstreetmap.org/wiki/NFE-Treffen#ADFC_und_GPS Der ADFC Nürnberg scheint ja wirklich aktiv zu sein: http://gps.adfc-nuernberg.de/ Da ist wirklich zu wenig OSM :-), mindestens /Links/ zu Opensteetmap und http://gnuher.de/cycleroute/ wären cool. Wie sieht es mit den Kontakten zur GPS-Arbeitsgruppe des ADFC auf? Radfahrer sind vermutlich auch recht gut zum Mappen zu motivieren. [...] http://lists.openstreetmap.de/cgi-bin/mailman/listinfo/franken Ich habe das mal bei Gmane registriert. Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Worldfile vom 7.1.09 - Befreit die Seen vom Wald!
On Mon, 19 Jan 2009, Torsten Leistikow wrote: Solange man sich auf die einfachsten Faelle beschraenkt, bleibt der Algorithmus auch noch einfach. Sobald da aber mehr als zwei Mitglieder zugehoeren, wird die Sache doch schnell unuebersichtlich (siehe oben). JOSM kann mit den Multipolygonen mittlerweile umgehen und so kompliziert ist das nicht. So wie ich das momentan verstehe, definiert die Summe aller outer-Polygone die aeussere Grenze. Ich schaetze mal, die sollten auch alle die gleiche Markierung haben, in obigen Beispiel landuse=forest, worueber die Eigenschaft fuer das gesammte, durch die Relation beschriebene Gebiet festgelegt wird. Muessen die outer-Polygone einen zusammenhaengenden Polygonzug ergeben? Nein. Eigentlich gehört die Markierung in die Relation. JOSM (und die Renderer, wenn sie es irgendwann können) unterstützen allerdings auch Merkmale auf den äußeren Wegen (Kompatibilität). JOSM macht es momentan so: Zeichenstil kommt aus der Relation oder wenn nicht, dann wird der erste Stil eines Outer-Weges genommen. Wenn die outer-Wege unterschiedliche Flächentypen ergeben, gibt es eine Warnung. Duerfen die inner-Polygone sich gegenseitig schneiden? Duerfen sie die outer-Polygone schneiden? Nein. Das wäre ein Fehler. Wenn die Polygone sich schneiden, dann ist die Geometrie falsch und muss korrigiert werden. Bei einer ebenen Fläche können sich die Kanten der Fläche nicht schneiden. Wie realisiere ich es, wenn der See im Wald eine Insel hat, auf der der Wald weiter geht? Dann hat der Wald eine Aussengrenze, die gleichzeitig Innengrenze von einem Element ist, dass eigentlich innerhalb des Waldes liegt. Du brauchst zwei Relationen, je eine für jedes Flächenobjekt beschreibt: Wald: Außenkante See ist ein Inner. Innenkante See ist ein outer. See: Genau andersherum. Das könnte man theoretisch auch automatisch erkennen, aber es bleibt ein Spezialfall und ich persönlich bin gegen eine spezielle Regel in der Multipolygon-Beschreibung für diesen Fall. In Zukunft wären dann die Tags in der Relation, momentan würde ich den Seeaußenrand als Wasser, den Rest als Wald eintragen. Wenn Du allerdings ein Waldgebiet mit 50 Seen hast, würden 2 Relationen ausreichen (sofern die Seen keine eigenen Namen haben, sondern alle ein Objekt sind :-). Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Worldfile vom 7.1.09 - Befreit die Seen vom Wald!
On Mon, 19 Jan 2009, Bernd Wurst wrote: ja, am besten waere wohl ein preprocessing, das erkennt, welche Flaeche von welcher umschlossen ist, und das dafuer sorgt, dass zuerst die groessere (untere/aeussere) Flaeche gerendert wird und darueber die kleinere/eingeschlossene. Das man damit keine Flaechenstatistiken machen kann, ist natuerlich klar. Der JOSM-Multipolygon-Code enthält entsprechendes. Natürlich greift er auf Java-Polygon-Funktionen zurück. Nein, das meine ich nicht. Im Fall des Garmin kann man z.B. nicht pro Objekt bestimmen in welcher Reihenfolge so etwas gerendert werden soll. Und man kann ja nicht alle Seen über Wälder oder andersrum legen, sonst hat man genau das aktuelle Verhalten. :) Ich dachte an einen Algorithmus, der aus ,--. | | | ,. | | || | | `' | `--' dann sowas macht: ,--. | | | ,. | +---+| | | `' | `--' Mit einem solchen Polygon könnte dann auch ein einfacher Renderer umgehen. In den Daten gefällt mir so etwas nicht, aber es ist ein probates Mittel wenn man für diese Anwendung nur eine Malvorlage braucht und keine korrekten Daten. Auch das ist in JOSM so umgesetzt. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Realation 68984 über nacht weg
Moin ! gestern hatte ich eine Relation für den E1 Fernwanderweg in Schleswig-Holstein angelegt. Heute ist dieser nicht mehr da ! Die Ralation ist oder was http://www.openstreetmap.org/browse/relation/68984 und müßte u.a. an dem Element http://www.openstreetmap.org/browse/way/30313266 hängen. Kann mir einer weiterhelfen ?? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wander Magazin - GPS Bericht - hat einer gelesen
Moin ! ich werde mal beim Verlag nachfragen ob interesse besteht und wie es mit einer Deadline aussieht. Mir ginge es auch darum - es gibt viele angebotene GPS-Tracks von Wanderwegen die vermutlich irgendwelchen Urheberrechten unterliegen. Auch wurde in der Zeitung über viele Orte berichtet (ihr seht ich habe mir die Ausgabe noch zugelegt) die soetwas anbieten (u.a. Paderborn). Wenn nun einer sowieso auf diesen Tracks läuft, dann könnte er diese ja mit aufzeichnen - ich denke hierbei auch an andere Länder die noch OSM-arm sind. Gruß Jan :-) Holger Schöner schrieb: Hallo, Am Donnerstag, 15. Januar 2009 schrieb Jan Tappenbeck: vielleicht wuerde es fuer die naechste Ausgabe helfen, denen mal was von OSM zu erzaehlen. [...] könnte mir gut vorstellen etwas zusammenzuschreiben - vielleicht findet sich noch einer von den wander/reit/cycle/etc.-karten machern ! Wenn es in drei, vier Wochen reichen würde, könnte ich das Rendern von Karten in dem Stil von http://www.ancalime.de/gutau.html; übernehmen. Der Stil ist noch in Entwicklung, und in anderen Gebieten noch nicht viel getestet, deswegen der vorgeschlagene Zeitraum ... Einen ersten Eindruck könnte ich nach ca. 1/2 bis ganzen Stunde zur Verfügung stellen (hängt natürlich auch von der Gebietsgröße ab). Was bei Zeitschriften auch eine Rolle spielen könnte, ist die Auflösung der Karte. Die Standardstile (Mapnik, Osmarender) sind wegen Schrift- und Icon-Größe eher für Bildschirm-Auflösungen geeignet, deshalb macht es Sinn, etwas neues zu entwickeln ... -- Freundliche Grüße Jan Tappenbeck --- OpenStreetMap (OSM) - das FREIE Kartenprojekt http://www.openstreetmap.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Status Multipolygon-Support
Hallo. Ich bin grade mal wieder drüber gestoplert, dass bei uns hier Waldflächen einfach zu riesig werden um alles in einem Linienzug umrunden zu können. Da im Thread Worldfile vom 7.1.09 grade von Dirk Stöcker folgendes geschrieben wurde... | Eigentlich gehört die Markierung in die Relation. JOSM (und die | Renderer, wenn sie es irgendwann können) unterstützen allerdings auch | Merkmale auf den äußeren Wegen (Kompatibilität). ...frage ich mich, wie denn der Unterstützungs-Status von Multipolygon-Relationen bei diversen Renderern bisher ist. Mapnik macht ja immernoch Probleme wenn nur die Richtung der Wege falsch herum ist [sic!], Osmarender scheint das Problem nicht zu haben. Aber wie sieht es mit der Unterstützung von echten Multipolygonen aus? Also mehrere Außenlinien und mehrere Innenlinien (die jeweils nicht zwingend ein eigenes Polygon bilden) in einer Multipolygon-Unterstützung. Gibt es in dieser Richtung schon Unterstützung? Kann Osmarender eigentlich prinzipbedingt überhaupt Tags aus Relationen herauslesen? Ich würde ja selbst mal was versuchen, aber da ich kein Fallbeispiel kenne, wann Osmarender Tags aus Relationen nutzt, weiß ich nicht wo anfangen. Gruß, Bernd 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] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Mir ist in letzter Zeit immer wieder aufgefallen, dass es in OSM keine Möglichkeit gibt, richtige Entscheidungen zu treffen. Die Admins und Programmierer treffen natürlich Entscheidungen bezüglich der Websites, der API (wie läuft das eigentlich?) oder der Anwendungen rund um OSM. Aber inbesondere das Mapping, die Tags, also letztlich der Bereich der OSM am Laufen hält, ist kaum reglementiert. Im Moment scheint es mir eher so, dass es für alles einen eher schwammigen Konsens gibt, aber weniger klare (dokumentierte) Regeln. ja, leider. ein altes thema, das immer wieder mal aufgewaermt wird. ich bin ja auch der meinung, dass genaue definitionen und richtlinien viele dinge einfacher machen wuerden und auch einen ganzen haufen unnoetiger arbeit ersparen koennten. eine erweiterbarkeit muss sowas dennoch nicht ausschliessen. du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. 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] Status Multipolygon-Support
On Wed, 21 Jan 2009, Bernd Wurst wrote: ...frage ich mich, wie denn der Unterstützungs-Status von Multipolygon-Relationen bei diversen Renderern bisher ist. Wahrscheinlich null. JOSM's Multipolygon-Unterstützung kam zwar spät, aber dafür dann gleich auf den neuesten Stand :-) Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Am Dienstag 20 Januar 2009 schrieb Florian Schweikert: Am 20. Januar 2009 22:36 schrieb Patrick Kolesa patrick.kol...@web.de: Es kann ja durchaus sein, dass Nachtclubs keine Musik spielen (wobei ich keinen solchen Club kenne :), dafür wäre dann music=yes/no möglich. Soweit ich weiß gibt es in Spanien ein Café/Club, welches nur freie Musik (z.B, cc) spielt. Da könnte man als Erweiterung auch music_license=* oder music:license=* nehmen. Allgemein finde ich differenzierte Tags besser, denn music allein sagt nicht viel aus. Gruß Patrick Auch wieder war, das mt license kann man auch später mal hinzufügen, ist (noch) nicht so verbreitet freie Musik zuspielen. mfg, Kelvan wie waers denn mit dem gern benutzten namespace schema: ein generelles tag in dieser form: music = yes|no|dj|live|. falls bekannt: music:genre = . music:license = . 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] Ortshinweisschild Z 385 (Weiler) Ortsschild
Am Dienstag 20 Januar 2009 schrieb Garry: RalfGesellensetter schrieb: (vgl. http://de.wikipedia.org/wiki/Ortstafel) Ortsschilder können aus JOSM heraus nun sehr komfortabel getaggt werden (auch wenn ich noch nicht weiß, woran ersichtlich sein soll, in welche Richtung vom Schild aus der Ort liegt). Die grünen Ortshinweisschilder könnten ggf. als Weiler getaggt werden - aber es ist meist nicht sofort ersichtlich, wo der Schwerpunkt des Weilers liegt - und manchmal handelt es sich wohl auch um eine Ortsvorbeifahrt. Bitte jetzt nicht alles was ein Ortshinweisschild hat als Weiler mappen! Das Schild taucht dort vielleicht überdurschnittlich häufig auf, hat aber ansonsten nichts mit Weiler zu tun. Im Gegensatz zum normalen Ortsschild gibt es hier einfach nur keine besonderen innerörtlichen Verkehrsregeln zu beachten. in 90% aller von mir gesehenen faelle war die assoziation gruenes schild - weiler durchaus richtig. in den anderen faellen ging die strasse mit dem gruenen schild an einer geschlossenen ortschaft, die dann durchaus als village herhalten konnte, vorbei. 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] Realation 68984 über nacht weg
Am Mittwoch, 21. Januar 2009 09:25 schrieb Jan Tappenbeck (OSM): Moin ! gestern hatte ich eine Relation für den E1 Fernwanderweg in Schleswig-Holstein angelegt. Heute ist dieser nicht mehr da ! Die Ralation ist oder was http://www.openstreetmap.org/browse/relation/68984 und müßte u.a. an dem Element http://www.openstreetmap.org/browse/way/30313266 hängen. Kann mir einer weiterhelfen ?? Schaust du unter: http://www.openstreetmap.org/browse/relation/68984/history siehst du das der Benutzer Lübeck die Relation um: 07:49:39 + 2009 gelöscht hat (keine Einträge mehr). Ich glaube das bist du (beachte das die Zeit UTC ist). wenn du es nicht warst, solltest du dein unbedingt dein Passwort ändern und ich würde dann auch einen (englischen) Admin davon berichten. Kann z.B. auch ein Bug in einem Editor sein. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sven Anders: Der/Die Entwickler von GPSDrive haben sowas auch mal gemacht, da fangen die tags mit poi an (weiß nicht ob das noch aktuell ist). das ist immer noch aktuell, ja ;-) ich bin grad dabei, das ganze fuer unser kommendes release zu ueberarbeiten. vielleicht schaff ich's dann auch irgendwann mal, ein proposal zu schreiben, in der hoffnung, dass die vorteile mal verstaendlich rueberkommen... 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
[Talk-de] Flächen taggen
Hallo, bitte zerreißt mich nicht, bin ein Newbie. Wie sieht es aus, gibt es irgendwo eine EINFACHE Anleitung fürs Flächen zeichnen? Ich komme da irgendwie nicht klar. Der nimmt scheinbar immer nur drei Punkte und macht daraus eine Fläche. Also Dreiecke, keine Vierecke oder Mehrecke. Ich würde Flächen gerne unter Nutzung bereits gezeichneter Straßen, Flüsse etc. einzeichnen. Wie geht das aber. Grüße, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Getränkemarkt - tag gesucht
Moin ! wie würdet Ihr einen Getränkemarkt attributieren ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Claudius Henrichs: ...offenbar ist diese Notation, die zu mehreren shop-Einträgen für dasselbe Objekte in der Datenbank führt ab API 0.6 nicht mehr gültig. Weiß da jemand genaueres? AFAIK: Das verwenden mehrerer Tags mit dem selben Schlüssel (also shop=bakery und dazu shop=cafe) wird in der API 0.6 nicht mehr möglich sein. Da die verbreiteten Editoren das auch momentan schon gar nicht zulassen, wird sich da also für den normalen Anwender nicht viel ändern. Gruß, Bernd -- Arbeit hat noch nie einen umgebracht. Aber warum sollte ich es herausfordern? 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] Geschäft mit mehreren Funktionen
Jan Tappenbeck schrieb: Moin ! es gibt ein Tag für Cafe und Bäckerei. Wie ist nun aber ein POI zu attributieren der beide Eigenschaften vereint. Ich halte Bäckereien mit Cafe inzwischen für die Standardausgabe einer Bäckerei. Bäckereien ohne Cafe dürften inzwischen Ausnahmen darstellen. Daher reicht meiner Ansicht nach in diesen Fällen der Tag für bakery. Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Getränkemarkt - tag gesucht
Am Mittwoch 21 Januar 2009 schrieb Jan Tappenbeck: Moin ! wie würdet Ihr einen Getränkemarkt attributieren ? Gruß Jan :-) poi=shop.beverages 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] Geschäft mit mehreren Funktionen
Am Mittwoch 21 Januar 2009 schrieb René Falk: Jan Tappenbeck schrieb: Moin ! es gibt ein Tag für Cafe und Bäckerei. Wie ist nun aber ein POI zu attributieren der beide Eigenschaften vereint. Ich halte Bäckereien mit Cafe inzwischen für die Standardausgabe einer Bäckerei. Bäckereien ohne Cafe dürften inzwischen Ausnahmen darstellen. Daher reicht meiner Ansicht nach in diesen Fällen der Tag für bakery. davon wuerde ich nicht ausgehen. wenn es neben backwaren auch cafe oder was anderes gibt, sollte man das auch notieren. 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] Getränkemarkt - tag gesucht
2009/1/21 Guenther Meyer d@sordidmusic.com Am Mittwoch 21 Januar 2009 schrieb Jan Tappenbeck: Moin ! wie würdet Ihr einen Getränkemarkt attributieren ? Gruß Jan :-) poi=shop.beverages lieber Guenther, wer hier schon einige Zeit mitliest kennt Dein System, aber es ist ein ziemlicher Exot unter den moeglichen OSM-tagging-Schemata, von daher waere es nicht schlecht, bei solchen posts noch etwas mehr Erlaeuterung beizufuegen der Art: in *meinem persoenlichen* Schema wird es so gemacht. Der Punkt als Trenner ist z.B. etwas ueberholt, nachdem sich mittlerweile u.a. aufgrund der Adressen der Doppelpunkt durchgesetzt hat. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen taggen
Hallo, Sorry, ich meinte in JOSM. Naja, Du machst halt 'nen Way und klickst irgendwann wieder auf den Startpunkt. Das ist klar. Und dann markiere ich den Weg, geh auf auf Vorlagen und wähle eine aus. Dann aber zieht der mitten durch mein eben gezeichnetes Feld eine Linie und zerteilt mein schönes Viereck in ein als Fläche markiertes Dreieck und ein freibleibendes Dreieick. Weiß nicht ob ich das so richtig erklärt habe. Grüße, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Treffen mit dem Vermessungs- Katasteramt Dortmund
Hallo Tobias, Was ist denn nun, 5 Monate später, effektiv aus der Zusammenarbeit geworden? Tät mich mal interessieren, weil uns hier in Frankfurt (Oder) auch ein Gespräch bevorsteht. Grüße, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen taggen
Arne Bischoff schrieb: irgendwo eine EINFACHE Anleitung fürs Flächen zeichnen? Ich komme da irgendwie nicht klar. Der nimmt scheinbar immer nur drei Punkte und Hi, wer ist der ? Potlatch oder JOSM ? Naja, Du machst halt 'nen Way und klickst irgendwann wieder auf den Startpunkt. Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Am 21.01.2009 11:03, Jan Tappenbeck: Moin ! es gibt ein Tag für Cafe und Bäckerei. Wie ist nun aber ein POI zu attributieren der beide Eigenschaften vereint. shop=bakery;cafe ...offenbar ist diese Notation, die zu mehreren shop-Einträgen für dasselbe Objekte in der Datenbank führt ab API 0.6 nicht mehr gültig. Weiß da jemand genaueres? Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geschäft mit mehreren Funktionen
Moin ! es gibt ein Tag für Cafe und Bäckerei. Wie ist nun aber ein POI zu attributieren der beide Eigenschaften vereint. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Hallo Rene, ich meine in meinem Fall nicht die Kaffee-Klappe - Bäckerei mit zwei Stehttischen. Hier sind wirklich Sessel vorhanden und schöne Tische - sogar ein Kamin ! Gruß Jan :-) René Falk schrieb: Jan Tappenbeck schrieb: Moin ! es gibt ein Tag für Cafe und Bäckerei. Wie ist nun aber ein POI zu attributieren der beide Eigenschaften vereint. Ich halte Bäckereien mit Cafe inzwischen für die Standardausgabe einer Bäckerei. Bäckereien ohne Cafe dürften inzwischen Ausnahmen darstellen. Daher reicht meiner Ansicht nach in diesen Fällen der Tag für bakery. Grüße René -- Freundliche Grüße Jan Tappenbeck --- OpenStreetMap (OSM) - das FREIE Kartenprojekt http://www.openstreetmap.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Am Mittwoch 21 Januar 2009 schrieb Claudius Henrichs: Am 21.01.2009 11:03, Jan Tappenbeck: Moin ! es gibt ein Tag für Cafe und Bäckerei. Wie ist nun aber ein POI zu attributieren der beide Eigenschaften vereint. shop=bakery;cafe ...offenbar ist diese Notation, die zu mehreren shop-Einträgen für dasselbe Objekte in der Datenbank führt ab API 0.6 nicht mehr gültig. Weiß da jemand genaueres? ne, andersrum, wenn ich das richtig verstanden habe: die o.g. zusammenfassende variante soll wohl die richtige sein. mehrfaches taggen im stile von shop=bakery shop=cafe welches ich persoenlich eigentlich besser finde, ist dann nicht mehr moeglich. 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] Musik Genre
Florian Schweikert kelvan.mailingl...@gmail.com wrote: Da ich keinen tag fand um die Musikrichtung in Lokalen anzugeben habe ich mal ein proposal angefangen: http://wiki.openstreetmap.org/wiki/Proposed_features/Music_genre Au weia. Soll mir recht sein so lange das keiner in den Renderer einbaut :) Sven -- Whenever there is a conflict between human rights and property rights, human rights must prevail. (Abraham Lincoln) /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] Wieviel Plattenplatz brauchen die Tiles f ür Deutschland?
2. Alles was großflächiges Wasser ist, muss nicht gerendert werden. Eine Markierung das ist Meer reicht und es muss nur ein blaues Bild gespeichert werden. So spart man sich mal deutlich über die Hälfte der Erdoberfläche. das wird momentan (noch?) so gesehen, aber theoretisch waere es durchaus denkbar, dort die Tiefeninformationen, Meeresnamen, Stroemungen (?), etc. zu visualisieren wie in jeder physischen Karte (Gebirge am Meeresgrund, etc.). http://upload.wikimedia.org/wikipedia/de/0/09/Weltkarte.jpg Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächen taggen
Arne Bischoff schrieb: Sorry, ich meinte in JOSM. Naja, Du machst halt 'nen Way und klickst irgendwann wieder auf den Startpunkt. Das ist klar. Und dann markiere ich den Weg, geh auf auf Vorlagen und wähle eine aus. Dann aber zieht der mitten durch mein eben gezeichnetes Feld eine Linie und zerteilt mein schönes Viereck in ein als Fläche markiertes Dreieck und ein freibleibendes Dreieick. Ah ok, das ist die Hilfslinie, die kann man ignorieren, oder du drückst am Ende einfach S (Objekt bleibt selektiert) oder ESC (Objekt wird nicht mehr selektiert). Grüße Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] addr:country Groß-/Kleinschreibung
Hallo, der Adressinspector von der geofabrik wertet ja für die PLZ-Boxen das addr:country Tag aus und unterscheidet dabei zwischen Groß- und Kleinschreibung beim Länderkürzel. Auf der engl. Wikiseite [1] steht auch, dass die Länderkürzel klein sein sollen, ist das aber generell nicht egal? Die Länderkürzel sollen nach ISO-3166-1 ALPHA-2 kodiert werden. Diese Kodierung unterscheidet aber nicht nach Groß-/Kleinschreibung. Außerdem existiert ein Kürzel nur einmal, nicht doppelt in anderer Groß-/Kleinschreibung. Ich plädiere deshalb dafür diese Einschränkung zu entfernen, da sie nicht notwendig ist und nur dazu führt, das jemand die unterschiedlichen Schreibweisen (de, DE, De etc.) auf eine anpassen muss. Der Inspector sollte deshalb dabei case-insensitive arbeiten. Vielen Dank fürs lesen ;) Grüße, Fabian [1] http://wiki.openstreetmap.org/wiki/Proposed_features/House_numbers/Karlsruhe_Schema#Tags [2] http://de.wikipedia.org/wiki/ISO-3166-1-Kodierliste signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Als theorielastiger Universitätsinformatiker wünsche ich mir auch häufiger stärkere Eindeutigkeit und verstehe Sebastians Ansinnen. Ich glaube aber der einzig richtige Weg geht hier nicht über Regeln, sondern über gute Beispiele, weswegen Frederiks Vorschlag hier ganz viele erhält: Am 21.01.2009 08:32, Frederik Ramm: Wenn eine Definition so vage ist, dass sie Auslegungsspielraum hat, dann lege sie so aus, wie Du es fuer richtig haeltst. Dazu musst Du sie nicht aendern. Wenn Du das gesamte Konzept fuer unsinnig haeltst, dann denke Dir was eigenes brauchbares aus und verwende das; dokumentiere es ggf. auf einer eigenen Wikiseite (vielleicht zunaechst im User-Namensraum, wenn es sehr esoterisch ist). In allen freien (i.S.v. regelarmen/regellosen) Communities, die ich bisher erlebt habe ergibt sich eine Richtung, indem einer oder eine Gruppe voranschwimmt und für diese Richtung Werbung macht. Sammle deine Empfehlungen mit Begründungen auf einer Wiki-Seite. Mache Werbung auf talk und talk-de und wenn's gut läuft werden wir in einem Jahr nur noch auf Sebastians Liste als deFacto-Standard verweisen. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Fabian -Patzi- Patzke: Ich plädiere deshalb dafür diese Einschränkung zu entfernen, da sie nicht notwendig ist und nur dazu führt, das jemand die unterschiedlichen Schreibweisen (de, DE, De etc.) auf eine anpassen muss. Der Inspector sollte deshalb dabei case-insensitive arbeiten. Inhaltlich gebe ich dir Recht. Aber ein Debugging-Tool wie der OSM-Inspector darf meiner Meinung nach gerne strenger prüfen und schneller meckern als andere Daten-Nutzer. Es schadet ja nicht, wenn alles klein geschrieben ist. ;-) Gruß, Bernd -- Drinking won't solve your problems. But it will bring you lots of interesting new ones. 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] Getränkemarkt - tag gesucht
Am Mittwoch 21 Januar 2009 schrieb Martin Koppenhoefer: 2009/1/21 Guenther Meyer d@sordidmusic.com Am Mittwoch 21 Januar 2009 schrieb Jan Tappenbeck: Moin ! wie würdet Ihr einen Getränkemarkt attributieren ? Gruß Jan :-) poi=shop.beverages lieber Guenther, wer hier schon einige Zeit mitliest kennt Dein System, aber es ist ein ziemlicher Exot unter den moeglichen OSM-tagging-Schemata, von daher waere es nicht schlecht, bei solchen posts noch etwas mehr Erlaeuterung beizufuegen der Art: in *meinem persoenlichen* Schema wird es so gemacht. es wurde eine frage gestellt, und die habe ich beantwortet, nicht mehr und nicht weniger. dadurch, dass es eben etwas anders aussieht, sollte eigentlich recht klar sein, dass hier was anderes, als das allgemein uebliche angeboten wird. wenn jemand genauere infos wuenscht, stelle ich diese auf nachfrage gerne zur verfuegung. Der Punkt als Trenner ist z.B. etwas ueberholt, nachdem sich mittlerweile u.a. aufgrund der Adressen der Doppelpunkt durchgesetzt hat. ueberholt? nicht richtig! da wo der doppelpunkt eingesetzt wird, ist er auch sinnvoll so, dem moechte ich gar nicht widersprechen; ganz im gegenteil. aber die bedeutung der punkte in den values meines schemas ist eine ganz andere - deswegen benutze ich eben NICHT doppelpunkte. 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] Flächen taggen
Chris-Hein Lunkhusen schrieb: Arne Bischoff schrieb: Sorry, ich meinte in JOSM. Naja, Du machst halt 'nen Way und klickst irgendwann wieder auf den Startpunkt. Das ist klar. Und dann markiere ich den Weg, geh auf auf Vorlagen und wähle eine aus. Dann aber zieht der mitten durch mein eben gezeichnetes Feld eine Linie und zerteilt mein schönes Viereck in ein als Fläche markiertes Dreieck und ein freibleibendes Dreieick. Ah ok, das ist die Hilfslinie, die kann man ignorieren, oder du drückst am Ende einfach S (Objekt bleibt selektiert) oder ESC (Objekt wird nicht mehr selektiert). Es könnte aber auch sein, dass es kein geschlossener Linienzug ist, Du (Arne) hats ja vorhin geschrieben, dass Du bestehende Ways nutzen will. Zeichnest Du dabei auch Dein Polygon noch einmal über die Straße drüber (Nutzung der selben Nodes)? Wenn du das nicht machst und nur sotwas hast: S = Straße P = Polygongrenze f = JOSM Füllung P PfffS Pff S Pf S P S PfffS Pff S Pf S S Dann erscheint die Füllung auch nur halb, ergibt eine Linie. Du musst es aber so machen X = Straße und Polygongrenze P = Polygongrenze f = JOSM Füllung P PfffX PfffX PfffX PfffX PfffX PfffX PfffX X Dann erhälst Du einen geschlossenen Ploygonzug und die Fläche sollte gefüllt sein. Ich hoffe das hat geholfen. Grüße, Fabian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Objekte gegen ?nderungen sch?tzen
Bernd Wurst be...@bwurst.org wrote: Diese gesichteten Versionen haben dazu gef?hrt, dass ich seither keine Wikipedia-?nderungen mehr mache. Ich wollte eine aktuelle Entwicklung in meinem Heimatort in Wikipedia eintragen und nach einem Tag Wartezeit wurde meine ?nderung von jemandem der sich scheinbar nicht mit dem Ort auskennt umformuliet so dass die gesichtete Version danach wesentlich falscher war als vorher. Das hat nix mit gesichtet zu tun, das kann ohne dem auch passieren, wenn jemand die Seite auf Beobachtung hat und sich die ?nderungen anschaut und ggfs. verbessert. So mache ich das ;-) Bei aktuelle Entwicklung leigt der Verdacht nahe, dass das vielleicht zu sehr als POV formuliert wurde... Dann halt nochmal sein Glueck versuchen mit neutralerer Formulierung. Sowas passiert mir auch schon mal, dass eine notwendige Aenderung erst im 2. Anlauf glueckt, zu recht, weil der 1. Anlauf im Nachhinein nicht so gut war. MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.b?ro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Sven Geggus li...@fuchsschwanzdomain.de writes: Florian Schweikert kelvan.mailingl...@gmail.com wrote: Da ich keinen tag fand um die Musikrichtung in Lokalen anzugeben habe ich mal ein proposal angefangen: http://wiki.openstreetmap.org/wiki/Proposed_features/Music_genre Au weia. Soll mir recht sein so lange das keiner in den Renderer einbaut :) Rendern wir auch akustisch? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] [AT] Heute 13:40 - Daniel AJ bei FM4
Hallo! Daniel AJ Sokolov (dem wir btw zu einem Gutteil unsere österr. Medienpräsenz verdanken... vielen Danke dafür!) wird so um 13:40 bei FM4 zum Thema OpenStreetMap zu hören sein... Also wer Zeit hat oder das vielleicht aufzeichnen kann... Website: http://fm4.orf.at/ Livestream: mms://stream1.orf.at/fm4_live Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
Bernd Wurst schrieb: Hallo. Am Mittwoch, 21. Januar 2009 schrieb Fabian -Patzi- Patzke: Ich plädiere deshalb dafür diese Einschränkung zu entfernen, da sie nicht notwendig ist und nur dazu führt, das jemand die unterschiedlichen Schreibweisen (de, DE, De etc.) auf eine anpassen muss. Der Inspector sollte deshalb dabei case-insensitive arbeiten. Inhaltlich gebe ich dir Recht. Aber ein Debugging-Tool wie der OSM-Inspector darf meiner Meinung nach gerne strenger prüfen und schneller meckern als andere Daten-Nutzer. Es schadet ja nicht, wenn alles klein geschrieben ist. ;-) Naja das führt dann aber evtl. dazu, dass man, um ein richtiges debugging der PLZ Gebiete durchführen zu können, erstmal alle addr:country anpassen muss. Ist eine unnötige Bearbeitung der Nodes nicht mal eben so gemacht und führt zu mehr Einträgen in der Datenbank, insofern schadet es evtl. nicht ist aber doch schon arg störend, zumindest stört es mich ein wenig ;). Ich denke halt dass man hier keine künstliche Unterscheidung der Tags herbeiführen muss, sondern es ruhig einfacher belassen könnte. Schließlich haben de, DE, De und dE hierbei eindeutig die selbe Bedeutung. Grüße, Fabian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Hi, 2009/1/21 Norbert Wenzel n_wen...@gmx.net: Sebastian Niehaus wrote: Rendern wir auch akustisch? Also für music:genre=Gangsta_Rap fielen mir schon ein paar gute Icons ein. Ein Best of... aus den Musikvideos würde sich bestimmt gut auf Openstreetmap.org in der Karte machen. ;-) Besser: Travelling-Salesman über alle Kneipen/Clubs in Köln, die Drum 'n' Bass spielen. (Mit Berücksichtigung der Öffnungszeiten und Ranking via Kölschpreis.) Tschüss, Tim. -- http://wikipedistik.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
Fabian -Patzi- Patzke wrote: Die Länderkürzel sollen nach ISO-3166-1 ALPHA-2 kodiert werden. Diese Kodierung unterscheidet aber nicht nach Groß-/Kleinschreibung. ISO 3166-1 alpha-2 Ländercodes sind immer in Großbuchstaben[0]. Im Gegensatz dazu sind ISO 639 Sprachcodes in Kleinbuchstaben. Also z.B. DE = Deutschland, de = Deutsch Der Inspector sollte deshalb dabei case-insensitive arbeiten. ACK. Servus, Andreas (aber an sich ist der addr:country Tag keine gute Idee ;) [0] z.B.: http://www.iso.org/iso/country_codes/iso_3166_code_lists/english_country_names_and_code_elements.htm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Getränkemarkt - tag gesucht
Jan Tappenbeck o...@tappenbeck.net writes: wie würdet Ihr einen Getränkemarkt attributieren ? shop=beverages ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Proposal für amenity=clock
Hallo, ich habe gerade mein erstes Proposal zu einem Tag fertiggestellt, welches meiner Ansicht nach schon lange überfällig ist: öffentliche Uhren. Es würde mich freuen, wenn ihr einen Blick auf http://wiki.openstreetmap.org/wiki/Proposed_features/Clock werfen könntet. Ich freue mich über Anregungen, Erweiterungen, Kritik (im Wiki). Tschüss, Tim. -- http://wikia.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
Andreas Labres schrieb: ISO 3166-1 alpha-2 Ländercodes sind immer in Großbuchstaben[0]. Im Gegensatz dazu sind ISO 639 Sprachcodes in Kleinbuchstaben. Also z.B. DE = Deutschland, de = Deutsch Der Inspector sollte deshalb dabei case-insensitive arbeiten. Zusätzlich sollte der Editor hier unterstützen und in Grossbuchstaben wandeln. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Norbert Wenzel n_wen...@gmx.net writes: Sebastian Niehaus wrote: [...] Rendern wir auch akustisch? Also für music:genre=Gangsta_Rap fielen mir schon ein paar gute Icons ein. Für das /visuelle/ Rendering schlage ich eine brennende Mülltonne vor. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Sebastian Niehaus wrote: Sven Geggus li...@fuchsschwanzdomain.de writes: Florian Schweikert kelvan.mailingl...@gmail.com wrote: Da ich keinen tag fand um die Musikrichtung in Lokalen anzugeben habe ich mal ein proposal angefangen: http://wiki.openstreetmap.org/wiki/Proposed_features/Music_genre Au weia. Soll mir recht sein so lange das keiner in den Renderer einbaut :) Rendern wir auch akustisch? Also für music:genre=Gangsta_Rap fielen mir schon ein paar gute Icons ein. Ein Best of... aus den Musikvideos würde sich bestimmt gut auf Openstreetmap.org in der Karte machen. ;-) Norbert smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Am 21. Januar 2009 12:21 schrieb Tim 'avatar' Bartel openstreet...@computerkultur.org: Hi, 2009/1/21 Norbert Wenzel n_wen...@gmx.net: Sebastian Niehaus wrote: Rendern wir auch akustisch? Also für music:genre=Gangsta_Rap fielen mir schon ein paar gute Icons ein. Ein Best of... aus den Musikvideos würde sich bestimmt gut auf Openstreetmap.org in der Karte machen. ;-) Besser: Travelling-Salesman über alle Kneipen/Clubs in Köln, die Drum 'n' Bass spielen. (Mit Berücksichtigung der Öffnungszeiten und Ranking via Kölschpreis.) Tschüss, Tim. und wenn dann Montags Abend der Volksmusik, Dienstags Soul classics und Freitags Best of 50ies und 60ies ist, Mittwochs an ungeraden Tagen ethno und an geraden Tagen Reggae? Geht alles noch, music:genre:monday=folk oder so. Schwieriger wird dann schon ein am letzten Sonntag im Monat oder noch besser am ersten Samstag nach Vollmond. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
Andreas Labres l...@lab.at writes: [...] (aber an sich ist der addr:country Tag keine gute Idee ;) Ähh... warum nicht? Sebastian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
Hallo, Andreas Labres wrote: Fabian -Patzi- Patzke wrote: Die Länderkürzel sollen nach ISO-3166-1 ALPHA-2 kodiert werden. Diese Kodierung unterscheidet aber nicht nach Groß-/Kleinschreibung. ISO 3166-1 alpha-2 Ländercodes sind immer in Großbuchstaben[0]. Im Gegensatz dazu sind ISO 639 Sprachcodes in Kleinbuchstaben. Also z.B. DE = Deutschland, de = Deutsch Der Inspector sollte deshalb dabei case-insensitive arbeiten. ACK. Also Vorschlag: 1. Wiki umstellen auf es sollen Grossbuchstaben genutzt werden 2. Inspector umstellen auf case-insensitive fuer die PLZ-Gebietsbestimmung 3. existierende kleingeschriebene addr:country mit Bot einmalig auf Grossbuchstaben abändern 4. alles, was im addr:country-Feld steht und nicht zwei Grossbuchstaben hat, künftig vom Inspector anmeckern lassen Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal für amenity=clock
Am 21. Januar 2009 12:37 schrieb Tim 'avatar' Bartel openstreet...@computerkultur.org: Hallo, ich habe gerade mein erstes Proposal zu einem Tag fertiggestellt, welches meiner Ansicht nach schon lange überfällig ist: öffentliche Uhren. Es würde mich freuen, wenn ihr einen Blick auf http://wiki.openstreetmap.org/wiki/Proposed_features/Clock werfen könntet. Ich freue mich über Anregungen, Erweiterungen, Kritik (im Wiki). Tschüss, Tim. habe mal ein paar Kommentare in discussion hinterlassen. Nett waere m.E., zu unterscheiden zwischen zentral gesteuerten Uhren, Funkuhren und unabhaengigen/eigenstaendigen Uhren. Weiterhin koennte man anstatt amenity sowas wie clock=type machen, wo type angibt, ob es sich um eine Digitaluhr, eine Zeigeruhr oder sonst was handelt (oder im einfachsten Fall clock=yes). Dieses clock=yes koennte man dann auch zusaetzlich z.B. an Kirchen taggen. Wenn die Uhr an mehreren Seiten angebracht ist, z.B. auch clock:amount=4. Wie wuerdest Du denn die Weltzeituhr am Alex in Berlin taggen? Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal für amenity=clock
Hi, Am 21. Januar 2009 13:00 schrieb Martin Koppenhoefer dieterdre...@gmail.com: habe mal ein paar Kommentare in discussion hinterlassen. Nett waere m.E., zu unterscheiden zwischen zentral gesteuerten Uhren, Funkuhren und unabhaengigen/eigenstaendigen Uhren. Weiterhin koennte man anstatt amenity sowas wie clock=type machen, wo type angibt, ob es sich um eine Digitaluhr, eine Zeigeruhr oder sonst was handelt (oder im einfachsten Fall clock=yes). Dieses clock=yes koennte man dann auch zusaetzlich z.B. an Kirchen taggen. Wenn die Uhr an mehreren Seiten angebracht ist, z.B. auch clock:amount=4. Vielen Dank für deine Anregungen! Die clock=type Lösung gefällt mir recht gut - allerdings bin ich mir noch nicht komplett über alle Vor- und Nachteile im klaren. Ein Doppeltagging gibt es ja auch bei amenity=shelter, dass bei bushaltestellen als shelter=yes getagged wird. Ich sammel gerne noch weitere Anregungen um mir dann eine fundierte Meinung zu bilden. Wie wuerdest Du denn die Weltzeituhr am Alex in Berlin taggen? Das ist natürlich ein Sonderfall - um ehrlich zu sein, kann ich mich auch nicht mehr richtig daran erinnern, wann ich sie das letzte mal gesehen habe. Nach dem Bild und der Beschreibung auf http://de.wikipedia.org/wiki/Urania-Weltzeituhr zu urteilen, würde ich basierend auf dem Ursprungs-Proposal vorschlagen: amenity=clock support=pole display=unorthodox visibility=area (Oder doch nur street? Das müsste man vor Ort abschätzen.) Tschüss, Tim. -- http://wikia.com ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Plattenplatz brauchen die Tiles für Deutschland?
Hallo Michael, die maxspeed-Karte http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte rechne ich auch mit Kosmos, allerdings erzeuge ich nur einen overlay und nicht die ganze Karte. Da daher viele Kacheln leer bleiben (keine maxspeed-Info), kann ich diese nach dem Rendern löschen und spare so recht viel Platz. (Allerdings dauert das Löschen mit meiner Batch-Prozedur ähnlich lange wie das Rendern...) Ich berechne einen Teilbereich von Mitteleuropa (E005 bis E017 und N35 bis N55) und komme so auf folgende Werte: WErte in Klammern ist die Größe auf den Datenträger) 0 - 12: 58 MB (100 MB) 13: 68 MB (83 MB) 14: 293 MB (786 MB) (hier habe ich einige leere Dateien noch nicht gelöscht) 15-17 rechne ich erst gar nicht... ein Rendern on demand ist mit Kosmos nicht so einfach möglich (da müsste ich mir erst mal was ausdenken). Gruß, Stefan Michael Buchberger schrieb: Hallo Liste, bin gerade dabei mit Kosmos herumzuspielen und habe als Beispiel mal die kompletten Daten von Rheinland-Pfalz in den Zoomstufen 0-17 berechnen lassen. Dabei werden 1779 Ordner mit 132 Dateien angelegt. Gesamtgröße ~3,6GB. Gebraucht hat mein Rechner dafür etwas über 24h Zoom 01,85kB Zoom 11,94kB Zoom 22,29kB Zoom 32,40kB Zoom 42,93kB Zoom 57,03kB Zoom 614,3kB Zoom 729,7kB Zoom 894,8kB Zoom 9293kB Zoom 101,45MB Zoom 114,08MB Zoom 1212,8MB Zoom 1335,6MB Zoom 1494,8MB Zoom 15265MB Zoom 16783MB Zoom 172450MB Das kommt mir jetzt ziemlich viel vor. Wieviele Terabytes verbraten den die Tiles von planet.osm in t...@h oder Mapnik? Tschuess Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
Am 21.01.2009 12:59, Frederik Ramm: Also Vorschlag: 1. Wiki umstellen auf es sollen Grossbuchstaben genutzt werden 2. Inspector umstellen auf case-insensitive fuer die PLZ-Gebietsbestimmung 3. existierende kleingeschriebene addr:country mit Bot einmalig auf Grossbuchstaben abändern 4. alles, was im addr:country-Feld steht und nicht zwei Grossbuchstaben hat, künftig vom Inspector anmeckern lassen Zustimmung. Wer schreibt den Bot? :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Guenther Meyer schrieb: du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. Ich hab jetzt schon keine Lust mehr. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Bernd Wurst schrieb: Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Bisher hat scheinbar niemand genau diese Ansprüche, die du hast. Es gibt schon einige, aber anscheinend nicht genug. Oder sie sind sich der Unterschiede nicht bewusst. Aber die meisten der von dir aufgelisteten Dinge hat mit den von mir bemängelten Dingen nicht allzuviel zu tun. Die Karten sehen so und so gut aus, egal ob die Daten stimmen oder nicht. Routing funktioniert auch. Fragt sich halt bloss welche Ansprüche man daran stellt. Ob man als z.B. zwischen Feinheiten wie (Reise)Bus-Routing und PKW-Routing unterscheiden will. Ich glaube gerne, dass routing für LKW und Reisebusse bald irgendwo mal mit diesen Daten gemacht wird. Ob Anlieger frei für Fahrräder gilt oder nicht, ist dafür irrelevant. Es geht ja auch nicht um Anlieger frei für Fahrräder wenns um LKW Routing geht. Sondern um z.B. korrekte LKW-relevante Tags. Zum Beispiel den Unterschied zwischen Gewicht und zulässigem Gewicht wird oder verwässert. Aber vielleicht ist das auch egal. Wenn LKW-Fahrer sich massenweise dafür anfangen zu interessieren, können die das ja regeln. Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Ich mach das. Vielleicht hat es dann wenigstens ETWAS Gutes, wenn ich so gründlich sein will... Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Nein. Es legt bisher niemand etwas fest sondern mit funktionierenden Anwendungen kann man eine große Zahl an Mitstreitern motivieren, freiwillig am gleichen Strang zu ziehen. Womit es letztlich festgelegt ist. Da es technisch sowieso nicht möglich ist jemanden zu etwas zu zwingen, ist es wenn die große Zahl mitzieht, quasi festgelegt. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. Um aber im Wiki etwas zu erreichen, braucht es einfach klare Regeln. Nein. Da sind wir dann unterschiedlicher Meinung. Oder man schafft das Accepted/Rejected Proposal gleich ab und schreibt nur das Ergebnis der Abstimmung als Stimmungsbarometer der Interessierten hin. Bleibt trotzdem noch die Frage was in die Map Features kommt. Wenn es nicht nach dem Voting geht, nach was dann? Das ist ein konkretes Problem, das nunmal so oder so entschieden werden muss. Langsam habe ich keine große Lust mehr, mich im Wiki zu engagieren. Das Wiki ist eine Daten-Halde, in dem man suchen kann wenn man Tags für irgendwas braucht und in das man eintragen kann, was man selbst so benutzt. Außerdem ist es eine rudimentäre Anleitung für Einsteiger und Dokumentation für unzählige Programme aus dem OSM-Umfeld. Halde klingt eher nach Abfall. Es ist kein Gesetzbuch oder irgend etwas was ein Mapper *braucht*. Seit es Presets gibt, braucht man noch nichtmal die Map-Features-Seite unbedingt wenn man mit OSM anfängt. Wenn du dich nicht im Wiki engagieren möchtest, lass es. Wenn du etwas verbessern willst: Mach es. Wenn du viel verbessern willst und keine Leute verprellen möchtest, leg jeweils eine neue Seite an und verweise auf der Diskussions-Seite der alten Variante auf deinen Neuvorschlag. Gut. Seit der Einfühung von highway=path mit der Brechstange sollte jedem klar sein, wie viel Bedeutung das Wiki hat und wie ernst zu nehmen das ist. Man kann aber auch ganz prima mappen ohne das Wiki zu benutzen. Welche Brechstange? Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: Wenn es nicht gelingt, die Menschen im Projekt von Deiner Idee zu ueberzeugen, dann nuetzt Dir jede formale Prozedur nichts. Umgekehrt verbietet Dir auch niemand, Deine Idee umzusetzen... Wenn mir also im Wiki eine Definition nicht gefällt, soll ich sie einfach ändern? Wenn eine Definition so vage ist, dass sie Auslegungsspielraum hat, dann lege sie so aus, wie Du es fuer richtig haeltst. Dazu musst Du sie nicht aendern. Wenn Du das gesamte Konzept fuer unsinnig haeltst, dann denke Dir was eigenes brauchbares aus und verwende das; dokumentiere es ggf. auf einer eigenen Wikiseite (vielleicht zunaechst im User-Namensraum, wenn es sehr esoterisch ist). All diese Moeglichkeiten stehen Dir offen, ohne dass Du andere nach Deiner Pfeife tanzen lassen musst. Ich will auf keinen nach meiner Pfeife tanzen lassen, ich besitze nichtmal eine. Ich denke, bei sowas wie bicycle=yes und motorcar=no gibt es relativ wenig Deutungs-Unterschiede. [...] Oh doch. Ist motorcar inklusive hgv, goods, psv? Je nachdem wie derjenige der die Daten auswertet das sieht, darf ein LKW plötzlich überall durch wo Kraftfahrzeuge gesperrt sind oder auch nicht. Das ist halt sowas, wo die Programmierer sich etwas mehr auf den Charakter von OSM einlassen muessen. Ist es realistisch, eine Strasse zu haben, die fuer PKW gesperrt, fuer LKW aber frei ist? Sollte der Router in so einem Fall eventuell lieber auf der Seite der Vorsicht irren? (Ist uebrigens hgv nicht identisch mit goods?) Gut, also raten. Mir geht es weniger darum irgendjemand dazu zu zwingen es genauso zu machen, wie es im Wiki steht, sondern eher darum, dass die Mapper meist garkeine Möglichkeit haben, sich an etwas zu orientieren. Ich mappe ja selbst wie ich es am logischsten finde. Man müsste sich aber weniger selbst zusammenraten, wenn Manches im Wiki klarer definiert wäre. Wem die Definition nicht gefällt, mappt natürlich trotzdem wie er es für besser hält. Dann brauchen wir aber keinen Prozess, sondern einfach eine einzige Person, die einfach gut ist, oder von mir aus ein Team von Leuten, die sich im Rahmen der allgemein akzeptieren vagen Regeln konkrete Tagging-Howtos ausdenken (und das passiert ja auch schon vielerorts im Wiki, z.B. dort wo jemand angefangen hat, zu jedem Verkehrsschild aufzuschreiben, wie man das seiner Ansicht nach taggen sollte). Diese Leute koennen dann ja eine stimmige Interpretation/Empfehlung aufschreiben, und jeder, der das gut findet, kanns uebernehmen. Wenn es in einem anderen Land andere solche Leute gibt, die sich etwas anders entscheiden - was solls. Gut. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
On Wed, 21 Jan 2009 13:16:44 +0100, Claudius Henrichs claudiu...@gmx.de wrote: Am 21.01.2009 12:59, Frederik Ramm: Also Vorschlag: 1. Wiki umstellen auf es sollen Grossbuchstaben genutzt werden 2. Inspector umstellen auf case-insensitive fuer die PLZ-Gebietsbestimmung 3. existierende kleingeschriebene addr:country mit Bot einmalig auf Grossbuchstaben abändern 4. alles, was im addr:country-Feld steht und nicht zwei Grossbuchstaben hat, künftig vom Inspector anmeckern lassen Zustimmung. Wer schreibt den Bot? :) Klingt gut. Wäre da ein SQL-Befehl nicht einfacher als einen Bot zu schreiben? Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Jan Tappenbeck schrieb: Hier sind wirklich Sessel vorhanden und schöne Tische - sogar ein Kamin ! Wie verschwenderisch ... einfach den Ofen beim Backen aufmachen :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Sven Anders schrieb: Am Mittwoch, 21. Januar 2009 03:34 schrieb Sebastian Hohmann: Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Es geht doch darum es für die Mapper einfacher zu machen. Anstatt in den JOSM Presets 'vorzuschreiben' was benutzt wird, würde ich es eben auch gerne im Wiki machen. Was dann letztlich benutzt wird, ist dann Sache der Mapper. Es steht dir frei ein eigenes Schema zu entwerfen und dafür auch eine Entscheidungsstruktur aufzubauen. Ich will kein eigenes Schema, ich will nur das vorhandene verbessern. Vielleicht sollte man gleich auf die Anfänger-Seite schreiben, dass man nicht allzuviel Genauigkeit erwarten sollte, wenn man nicht vorhat eine konkrete Anwendung zu programmieren, die diese speziellen Daten braucht (eigentlich dachte ich ja OSM sammelt Daten auch erstmal unabhängig davon ob sie schon irgendwo dargestellt werden). Ja, ich denke das sollte doch eigentlich klar sein. Von der Wikipedia erwarte ich ja auch nicht, das jeder Artikel 100% stimmt. Auf der anderen Seite kann man ja auch als Anwendungsbenutzer den lokalen Mappern sagen: Schaut mal auf meiner Landkarte stimmt was nicht. Ich denke schon, das dann versucht wird, das genauer zu erfassen. Ebene. Dinge die von irgendeinem Programm dargestellt werden. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Bathymetrische Karte
Hallo Martin, Tiefeninformationen, Meeresnamen, Stroemungen, etc. zu visualisieren http://upload.wikimedia.org/wikipedia/de/0/09/Weltkarte.jpg Sehr schön! wie könnte man das realisieren? Gibt es ein frei verfügbares Höhenmodell für Meerestiefen? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: Mir geht es weniger darum irgendjemand dazu zu zwingen es genauso zu machen, wie es im Wiki steht, sondern eher darum, dass die Mapper meist garkeine Möglichkeit haben, sich an etwas zu orientieren. Ich mappe ja selbst wie ich es am logischsten finde. Man müsste sich aber weniger selbst zusammenraten, wenn Manches im Wiki klarer definiert wäre. Wem die Definition nicht gefällt, mappt natürlich trotzdem wie er es für besser hält. Dann brauchen wir aber keinen Prozess, sondern einfach eine einzige Person, die einfach gut ist, oder von mir aus ein Team von Leuten, die sich im Rahmen der allgemein akzeptieren vagen Regeln konkrete Tagging-Howtos ausdenken (und das passiert ja auch schon vielerorts im Wiki, z.B. dort wo jemand angefangen hat, zu jedem Verkehrsschild aufzuschreiben, wie man das seiner Ansicht nach taggen sollte). Diese Leute koennen dann ja eine stimmige Interpretation/Empfehlung aufschreiben, und jeder, der das gut findet, kanns uebernehmen. Wenn es in einem anderen Land andere solche Leute gibt, die sich etwas anders entscheiden - was solls. Mal ganz konkret die Frage: Wie wird entschieden, was in die Map Features kommt und eine eigene Key/Tag-Seite bekommt? Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal für amenity=clock
Sieht doch gut aus und ist überfällig - in Lübeck habe ich schon eine Vielzahl gemappt. Muss mich allerdings den Einwänden von Günther anschließen (Art der Steuerung) ! Gruß Jan :-) Guenther Meyer schrieb: Am Mittwoch 21 Januar 2009 schrieb Martin Koppenhoefer: habe mal ein paar Kommentare in discussion hinterlassen. Nett waere m.E., zu unterscheiden zwischen zentral gesteuerten Uhren, Funkuhren und unabhaengigen/eigenstaendigen Uhren. da stellt sich wohl die schwierigkeit, dass das in den meisten faellen nicht erkennbar sein wird... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- Freundliche Grüße Jan Tappenbeck --- OpenStreetMap (OSM) - das FREIE Kartenprojekt http://www.openstreetmap.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
Claudius Henrichs schrieb: Am 21.01.2009 12:59, Frederik Ramm: 1. Wiki umstellen auf es sollen Grossbuchstaben genutzt werden 2. Inspector umstellen auf case-insensitive fuer die PLZ-Gebietsbestimmung 3. existierende kleingeschriebene addr:country mit Bot einmalig auf Grossbuchstaben abändern 4. alles, was im addr:country-Feld steht und nicht zwei Grossbuchstaben hat, künftig vom Inspector anmeckern lassen FULL-ACK Zustimmung. Wer schreibt den Bot? :) bot steht bereit grüße frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Proposal für amenity=clock
Am Mittwoch 21 Januar 2009 schrieb Martin Koppenhoefer: habe mal ein paar Kommentare in discussion hinterlassen. Nett waere m.E., zu unterscheiden zwischen zentral gesteuerten Uhren, Funkuhren und unabhaengigen/eigenstaendigen Uhren. da stellt sich wohl die schwierigkeit, dass das in den meisten faellen nicht erkennbar sein wird... 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] addr:country Groß-/Kleinschreibung
Hallo Andreas, (an sich ist der addr:country Tag keine gute Idee ;) Ja das ist DB-technisch m.E. Unsinn. Dafür sind Relationen da. Am besten auch grafischer Basis mit geschlossenen Polygon-Linien. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Plattenplatz brauchen die Tiles für Deutschland?
Hallo Stefan, die maxspeed-Karte http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte rechne ich auch mit Kosmos, allerdings erzeuge ich nur einen overlay und nicht die ganze Karte. Die Karte hatte ich auch noch im Hinterkopf. Muss mir unbedingt mal anschauen wie Du das mit den Openlayer-Overlays gemacht hast. Da daher viele Kacheln leer bleiben (keine maxspeed-Info), kann ich diese nach dem Rendern löschen und spare so recht viel Platz. (Allerdings dauert das Löschen mit meiner Batch-Prozedur ähnlich lange wie das Rendern...) Über Dateigröße zu ermitteln? Tschuess Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo, Sebastian Hohmann wrote: Ist es realistisch, eine Strasse zu haben, die fuer PKW gesperrt, fuer LKW aber frei ist? Sollte der Router in so einem Fall eventuell lieber auf der Seite der Vorsicht irren? (Ist uebrigens hgv nicht identisch mit goods?) Gut, also raten. Sagen wir: Vernuenftige Annahmen treffen. - Am Wort raten gefaellt mir nicht, dass es sich so anhoert, als koenne bestenfalls eine Trefferwahrscheinlichkeit von 50% erzielen ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Worldfile vom 7.1.09 - Befreit die Seen vom Wald!
solange Du nicht anfängst, Multipolygon-Objekte anderer von Hand nach Deinem System zu zergliedern, kannst Du gerne damit weitermachen, ich vermute allerdings, sobald die Editoren das Ganze intuitiver behandeln und problemlos darstellen, wirst Du auch dazu übergehen. Stell Dir vor, es ist quasi ein Datentyp wie way und node, und mkgmap kommt irgendwie damit klar (passende Vorbereitung der Daten). Willst Du dann auch die Siedlungsgebiete so zeichnen dass die gesamte Fläche ein Gebäude ist und alles was nicht Gebäude ist herausgeschnitten wird? Oder lieber den ganzen Ort als eine Strassenfläche markieren und mit Häusern und Grünflächen den nicht befahrbaren Teil herausschneiden? Wieso sollte man? Die Häuser und die Straßen befinden sich _im_ Siedlungsgebiet (jeder Punkt im Haus ist gleichzeitig in der Siedlung), also passt das so. Der See befindet sich aber nicht im Wald, sondern in einer Lichtung, also da wo kein Wald ist. -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
2009/1/21 Sebastian Niehaus nieh...@nospam.arcornews.de: Norbert Wenzel n_wen...@gmx.net writes: Sebastian Niehaus wrote: [...] Rendern wir auch akustisch? Also für music:genre=Gangsta_Rap fielen mir schon ein paar gute Icons ein. Für das /visuelle/ Rendering schlage ich eine brennende Mülltonne vor. Gegenvorschlag: eine cd in einer Mülltonne. ;-) Juhu, Musikgeschmacks-Flamewar! SCNR, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:country Groß-/Kleinschreibung
Hallo Marcus, Der Inspector sollte case-insensitive arbeiten. Zusätzlich sollte der Editor hier unterstützen und in Grossbuchstaben wandeln. Was ist Der Editor wo hast du eine vollständige Liste aller Regeln dokumentiert welche die Entwickler berüchtichtigen sollten Für welche Editoren bietest du an so einen Patch zu schreiben? Chris-Hein meint hier: Es wäre gut, wenn die *Qualität am Eingang generiert* wird (Editor), statt sie am Ausgang zu korrigieren (Inspektor). Dies ist im Qualitätsmanagement eine grundlegende Erkenntnis. Ich fände sinnvoll, wenn die derzeit von hinten eingeführten Regeln (durch die Anwendungsprograme) offen dokumentiert und bereits vorne berücksichtigt werden. In JOSM funktioniert das ja bereits zunehmend. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
2009/1/21 Jan Tappenbeck o...@tappenbeck.net: Moin ! es gibt ein Tag für Cafe und Bäckerei. Wie ist nun aber ein POI zu attributieren der beide Eigenschaften vereint. Gruß Jan :-) Dasselbe Problem begegnet einem auch bei anderen Konstellationen, z.B. Hotel/Kneipe/Restaurant oder Restaurant/Biergarten... Manche tragen das als getrennte nodes mit gleichem Namen ein, andere als amenity=bla;blubb Die erste Variante funktioniert halt für die Renderer/Konverter/POI-Suche, die zweite ist meiner Meinung nach eigentlich richtiger, wird aber bis jetzt nicht ausgewertet... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Natur- und Landschaftsschutzgebiet-Kart en für OSM
Hallo Claudius, da hast Du vermutlich etwas falsch verstanden - mir ging es um die rechtliche Übernahmemöglichkeit der Konturen aus den vorliegenden Unterlagen. Die Art der Attributierung ist etwas ganz anderes. Gruß Jan :-) Claudius Henrichs schrieb: Am 20.01.2009 09:35, Jan Tappenbeck: kann mir einer sagen in wieweit die Definitionen für Natur- und Landschaftsschutzgebiete (siehe auch http://www.luebeck.de/bewohner/umwelt_gesundheit/naturschutz/schutzgebiete/schutzgebiete.html) in OSM übernommen werden können ?? Ich dachte hierbei an die visuelle Übertragung der Begrenzung. Das OSM-Wiki hat eine Suchfunktion: http://wiki.openstreetmap.org/wiki/Proposed_features/Nature_reserve http://wiki.openstreetmap.org/wiki/Proposed_features/conservation Bisher gibt es noch keine Einigung darüber. Es bedarf offenbar eines Tags, das zusätzlich zu natural=* und landuse=*-Tags verwendet werden kann. Gruß, Claudius -- Freundliche Grüße Jan Tappenbeck --- OpenStreetMap (OSM) - das FREIE Kartenprojekt http://www.openstreetmap.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Guenther Meyer schrieb: du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. Ich hab jetzt schon keine Lust mehr. du gibst aber schnell auf ;-) leider sind manche dinge bei osm nicht so einfach, wie sie sein koennten... es gibt sehr viele dinge, die sich verbessern liessen, und verschiedene leute haben verschiedene konzepte. es waere schade, wenn neue ideen nicht genannt werden, weil sie nicht angenommen werden koennten. am besten ist es wohl, neue konzepte gut zu dokumentieren und mit beispielen zu demonstrieren, damit die leute verstehen koennen, was denn besser ist. mit kleinen schritten wird man im allgemeinen auch weiter kommen, als mit radikalen aenderungen. wenn man nun noch ein integration in die ganze kette vom editor ueber die datenbank bis zum renderer/router anbieten kann, stehen die chancen wahrscheinlich noch besser. aber eines sollte man sich immer bewusst sein: so gut ein konzept auch sein mag, man kann es nur anbieten, und hoffen, dass es angenommen wird. die alternative waere - wie schon vorgeschlagen - das ganze parallel zu osm aufzuziehen, und zu hoffen, dass genug leute mitmachen... 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] Entscheidungen treffen / Proposal-Prozess
Hallo, Sebastian Hohmann wrote: Mal ganz konkret die Frage: Wie wird entschieden, was in die Map Features kommt und eine eigene Key/Tag-Seite bekommt? Die Frage ist falsch gestellt. Grundsaetzlich kann jeder das Wiki aendern. Das heisst, ich kann auch meinen Fantasie-Tag in die Map Features schreiben. Jemand anders kann ihn dann wieder löschen. Und so weiter. Und wir haben keinen Obermufti, der entscheidet, wer im Recht ist. Den klaren Entscheidungsprozess, nach dem Du fragst, den gibt es also gar nicht. In der Praxis ist es eine Art Akklamations-System. Wenn Du an den Map Features was aenderst und die Leute auf der Talk-Liste das gut finden oder zumindest niemand gross protestiert, dann ist die Aenderung drin. Wenn Du einfach so was eintraegst, was Dir grad einfaellt, ohne dass es dazu was auf der Liste oder wenigstens eine Diskussion im Wiki gab oder so, wird jemand anders es vermutlich wieder rauswerfen. Ich wuerde mal so formulieren: Um die Map Features-Seite zu aendern, brauchst Du einen guten Grund und musst willens und in der Lage sein, diesen Grund auf Nachfrage zu erlaeutern oder dies gleich ohne Nachfrage prohpylaktisch tun. Ulf Lamping zum Beispiel fuegt seit Monaten ab und zu neue shop-Werte auf die Map-Features-Seite hinzu, ohne jede Abstimmung (Skandal!), nur mit einer lapidaren Mail an talk: shop=computer wird derzeit 115mal benutzt, ich hab das mal hinzugefügt. Wenn ein Tag 115mal benutzt wird, ist das in der Regel ein guter Grund, ausser in Streitfällen wird niemand protestieren. Es ist allgemein anerkannt, das Map Features dokumentieren soll, was benutzt wird. Es kann aber auch andere gute Gründe geben, z.B. ein erfolgreich abgestimmtes Proposal. (Auch hier gilt, dass es in Streitfällen Widerstand geben kann, aber in den allermeisten Fällen wird niemand was einzuwenden haben.) Meine letzten beiden Änderungen an den Map Features waren z.B. eine Klarstellung bei highway=track - da stand, dass tracks generell nicht asphaltiert seien, was ja mittlerweile durch die Nutzung in Kombination mit tracktype=grade1 nicht mehr stimmt. Irgendjemand hatte auf der Liste geschrieben ätschibätsch, grade1 ist Quatsch, hier steht doch dass tracks nie asphaltiert sind, ich habe das daraufhin geändert und kurzerhand geantwortet: danke für den Hinweis, Wiki ist korrigiert - einer oder zwei fühlten sich durch diesen respektlosen Umgang mit dem Wiki auf den Schlips getreten, aber es war unbestreitbar, dass ich in diesem Punkt recht hatte, und so ist die Änderung auch heute noch drin. Oder ich habe bei amenity=hospital ergänzt, dass oft ein emergency=yes/no dazu gesetzt wird, weil ich es für bescheuert hielt, dass das Proposal für das emergency-Tag von irgendjemand als abandoned klassifiziert worden war. Auch das habe ich kurz auf talk dargestellt, und niemand hat sich beschwert... Eine eigene Key/Tag-Seite kann man m.E. für alles anlegen, was nicht gerade komplett erfunden ist. Die meisten machen erst ein Proposal usw., aber man muss nicht. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Florian Schweikert schrieb: Da ich keinen tag fand um die Musikrichtung in Lokalen anzugeben habe ich mal ein proposal angefangen: Hmmm, also ich kenne keine Lokal, welches immer dieselbe Mucke spielt (bis auf ein China-Restaurant wo jedesmal wenn ich da bin Kenny-G läuft), also lasse ich das. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ich glaube gerne, dass routing für LKW und Reisebusse bald irgendwo mal mit diesen Daten gemacht wird. Ob Anlieger frei für Fahrräder gilt oder nicht, ist dafür irrelevant. Es geht ja auch nicht um Anlieger frei für Fahrräder wenns um LKW Routing geht. Sondern um z.B. korrekte LKW-relevante Tags. Zum Beispiel den Unterschied zwischen Gewicht und zulässigem Gewicht wird oder verwässert. Aber vielleicht ist das auch egal. Wenn LKW-Fahrer sich massenweise dafür anfangen zu interessieren, können die das ja regeln. Soweit ich weiß gibt es momentan noch kein Massenmarkt-taugliches Navi für Reisebusse und LKW. Die meisten der Fahrer haben ein Auto-Navi dabei. Das liegt vermutlich daran, dass die LKW-spezifischen Dinge in den Daten der kommerziellen Hersteller auch noch gar nicht enthalten sind. Ein einfacher Mapper wird gar nicht wissen, auf was er alles achten muss. Wenn aber in Zukunft mal die Information die Runde macht, dass jetzt das erste Massenmarkt-taugliche LKW-Navi auf Basis von OSM-Daten existiert und OpenStreetBugs in dem Gerät voll integriert ist, dann prophezeihe ich dir, dass die Daten *sehr* schnell nachgetragen werden. Von Mappern und Anwendern. Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Ich mach das. Vielleicht hat es dann wenigstens ETWAS Gutes, wenn ich so gründlich sein will... Ich mach das auch soweit ich die Beschränkungen erkenne. Man hat halt nen anderen Blick, mit welchem Verkehrsmittel man grade unterwegs ist. mit dem Fahrrad achtet man nicht auf enge Durchfahrten und Größenbeschränkungen, da geht einem schonmal was durch. Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. Naja, aber was ist wenn einer sagt, access=destination ist per se Quark und der nächste sagt, das reicht mir für meine Ansprüche? Oder tracktype: Es gibt viele die das aktuelle Schema grausam finden, alle Eigenschaften in einen Wertebereich von 1 bis 5 zu zwängen. Ich war auch skeptisch. Aber hey, es funktioniert. Man kann damit keine Statistiken machen wie viele Schlaglöcher ein Weg hat, aber man weiß ob man ihn im matschigen Herbst als Wanderweg nutzen will oder nicht. Das Wiki ist eine Daten-Halde, in dem man suchen kann wenn man Tags für irgendwas braucht und in das man eintragen kann, was man selbst so benutzt. Außerdem ist es eine rudimentäre Anleitung für Einsteiger und Dokumentation für unzählige Programme aus dem OSM-Umfeld. Halde klingt eher nach Abfall. Bei manchen Artikeln im Wiki ist der Begriff auch im Rahmen der möglichen Bezeichnungen. :) Seit der Einfühung von highway=path mit der Brechstange sollte jedem klar sein, wie viel Bedeutung das Wiki hat und wie ernst zu nehmen das ist. Man kann aber auch ganz prima mappen ohne das Wiki zu benutzen. Welche Brechstange? highway=path wurde etwas vage vorgeschlagen als einen Weg den man zu Fuß oder mit einem Fahrrad benutzen kann. Weitere Tags wurden vorgeschlagen um das dann genauer zu spezifizieren. Manche haben darunter einen Trampelpfad und manche einen Wanderweg verstanden, andere dagegen sehen das als Ersatz für alle Fuß- und Radwege die momentan eingetragen sind. Ein Voting brachte zwar eine Mehrheit für das neue Tag highway=path aber eine deutliche Ablehnung bzgl. des Ersetzens von footway und cycleway. In der Folge haben die eifrigen Mapper aber nach und nach alle Beschreibungen im Wiki so geändert, dass dort wo vorher z.B. highway=footway stand, nachher das path-Konstrukt stand. Auch in den Diskussionen der Mailingliste und bei tagwatch kann man deutlich sehen, dass der gemeine Mapper sich nicht umgestellt hat und die meisten weiterhin Fußwege als Fußwege eintragen. Es wurde viel Arbeit in die Umstellung des Wikis investiert, Dokumentationen und Beispiele wurden geschrieben aber die Masse hat das Tag nicht wirklich übernommen. Bis heute gibt es unterschiedliche Auffassungen was das Tag eigentlich bedeutet, denn das war schon zum Zeitpunkt der Abstimmung unklar. Es gibt weiterhin eine große Zahl an Mappern die das Tag nicht nutzen und prima ohne das auskommen. Gruß, Bernd -- Ein Pessimist ist jemand, der vorzeitig die Wahrheit erzählt. - Cyrano de Bergerac (frz. Schriftsteller 1619-1655) 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] Musik Genre
Chris-Hein Lunkhusen wrote: Florian Schweikert schrieb: Da ich keinen tag fand um die Musikrichtung in Lokalen anzugeben habe ich mal ein proposal angefangen: Hmmm, also ich kenne keine Lokal, welches immer dieselbe Mucke spielt (bis auf ein China-Restaurant wo jedesmal wenn ich da bin Kenny-G läuft), also lasse ich das. ;-) Ich hab das bis jetzt einmal verwendet, und zwar bei einem Lokal, dass sich mitten in der Stadt als Skihütte, mit all der Musik die dort gespielt wird, ausgibt. Dort spielts tatsächlich die ganze Zeit nur die üblichen Hüttenschlager. Bei dem Nightclub hab ich das als Warnung drangesetzt, weil ich nicht schuld sein wollt, dass dann einer sagt, er hat den Nightclub in OSM gefunden und wurde nicht gewarnt, was für ein Laden das eigentlich ist. ;-) Aber du hast Recht, music_genre ist vielleicht etwas zu detailliert, dennoch kann bei Nachtclubs eine grobe Zuordnung durchaus hilfreich sein. Zumindest so nach dem Motto, ob man dort an gemütlichen Abend verbringen kann, oder erstmal dem Türsteher einen 50er in die Tasche steckt, um den Laden überhaupt betreten zu dürfen, kann eine Einteilung durchaus Sinn machen. Norbert smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Bernd Wurst schrieb: Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Bisher hat scheinbar niemand genau diese Ansprüche, die du hast. Es gibt schon einige, aber anscheinend nicht genug. Oder sie sind sich der Unterschiede nicht bewusst. sinnvollerweise sollten solche dinge so getaggt, wie es die stvo fuer das jeweilige schild beschreibt, das ist zumindest in diesem fall recht eindeutig. leider ist aber die wahrscheinlichkeit, dass ein autofahrender mapper nur aus seinem blickwinkel mappt, sehr hoch. viele dinge fallen einem erst auf, wenn man selber betroffen ist. entpsrechende presets in den editoren koennten diese situation sicherlich verbessern... Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Ich mach das. Vielleicht hat es dann wenigstens ETWAS Gutes, wenn ich so gründlich sein will... gruendlichkeit ist sehr gut! leider wird es trotzdem wohl nie eine garantie geben, dass alle vorhandenen hoehen- und gewichtsbeschraenkungen auch in die datenbank eingetragen wurden. Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Nein. Es legt bisher niemand etwas fest sondern mit funktionierenden Anwendungen kann man eine große Zahl an Mitstreitern motivieren, freiwillig am gleichen Strang zu ziehen. Womit es letztlich festgelegt ist. Da es technisch sowieso nicht möglich ist jemanden zu etwas zu zwingen, ist es wenn die große Zahl mitzieht, quasi festgelegt. man kann sich dann zumindest darauf verlassen, dass etwas in einem gewissen rahmen funktioniert, auch wenn es nicht die optimale loesung darstellt. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. eindeutig ist besser, da stimme ich dir zu. auf welche art das realisiert wird, ist da zweitrangig. das problem ist aber einerseits, dass eindeutig nicht zwangslaeufig einfacher bedeutet (was sich aber auf userseite durchaus realisieren liesse), und dass dafuer altbekannte mechanismen und pfade, die ja funktionieren, zugunsten neuer verlassen werden muessen. 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] addr:country Groß-/Kleinschreibung
Frederik Ramm wrote: 1. Wiki umstellen auf es sollen Grossbuchstaben genutzt werden 2. Inspector umstellen auf case-insensitive fuer die PLZ-Gebietsbestimmung 3. existierende kleingeschriebene addr:country mit Bot einmalig auf Grossbuchstaben abändern 4. alles, was im addr:country-Feld steht und nicht zwei Grossbuchstaben hat, künftig vom Inspector anmeckern lassen Gute Vorschläge, gefallen mir alle. :) IMO sollte man sich trotzdem eine bessere Alternative überlegen... jetzt muß ich schon überall Wien dazuschreiben, wo doch eigentlich eh kloa ist, daß PLZ 1xxx immer Wien ist. Aber daß ich jetzt tausendfach dazuschreiben muß, daß Wien auch wirklich in AT ist, is mühsam... beim place tag dazuschreiben oder sowas. Irgendwie schiene mir das überhaupt ein gangbarer Weg, sich die optional Dinge einer Adresse zusammenzusuchen... die Straße über die nächstliegende Straße und dann nach einem place tag in der Nähe suchen, dort könnten dann PLZ und Ort zu finden sein... Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: Hallo, Sebastian Hohmann wrote: Mal ganz konkret die Frage: Wie wird entschieden, was in die Map Features kommt und eine eigene Key/Tag-Seite bekommt? Die Frage ist falsch gestellt. Grundsaetzlich kann jeder das Wiki aendern. Das heisst, ich kann auch meinen Fantasie-Tag in die Map Features schreiben. Jemand anders kann ihn dann wieder löschen. Und so weiter. Und wir haben keinen Obermufti, der entscheidet, wer im Recht ist. Den klaren Entscheidungsprozess, nach dem Du fragst, den gibt es also gar nicht. In der Praxis ist es eine Art Akklamations-System. Wenn Du an den Map Features was aenderst und die Leute auf der Talk-Liste das gut finden oder zumindest niemand gross protestiert, dann ist die Aenderung drin. Wenn Du einfach so was eintraegst, was Dir grad einfaellt, ohne dass es dazu was auf der Liste oder wenigstens eine Diskussion im Wiki gab oder so, wird jemand anders es vermutlich wieder rauswerfen. Ich wuerde mal so formulieren: Um die Map Features-Seite zu aendern, brauchst Du einen guten Grund und musst willens und in der Lage sein, diesen Grund auf Nachfrage zu erlaeutern oder dies gleich ohne Nachfrage prohpylaktisch tun. Ulf Lamping zum Beispiel fuegt seit Monaten ab und zu neue shop-Werte auf die Map-Features-Seite hinzu, ohne jede Abstimmung (Skandal!), nur mit einer lapidaren Mail an talk: shop=computer wird derzeit 115mal benutzt, ich hab das mal hinzugefügt. Wenn ein Tag 115mal benutzt wird, ist das in der Regel ein guter Grund, ausser in Streitfällen wird niemand protestieren. Es ist allgemein anerkannt, das Map Features dokumentieren soll, was benutzt wird. Es kann aber auch andere gute Gründe geben, z.B. ein erfolgreich abgestimmtes Proposal. (Auch hier gilt, dass es in Streitfällen Widerstand geben kann, aber in den allermeisten Fällen wird niemand was einzuwenden haben.) Meine letzten beiden Änderungen an den Map Features waren z.B. eine Klarstellung bei highway=track - da stand, dass tracks generell nicht asphaltiert seien, was ja mittlerweile durch die Nutzung in Kombination mit tracktype=grade1 nicht mehr stimmt. Irgendjemand hatte auf der Liste geschrieben ätschibätsch, grade1 ist Quatsch, hier steht doch dass tracks nie asphaltiert sind, ich habe das daraufhin geändert und kurzerhand geantwortet: danke für den Hinweis, Wiki ist korrigiert - einer oder zwei fühlten sich durch diesen respektlosen Umgang mit dem Wiki auf den Schlips getreten, aber es war unbestreitbar, dass ich in diesem Punkt recht hatte, und so ist die Änderung auch heute noch drin. Oder ich habe bei amenity=hospital ergänzt, dass oft ein emergency=yes/no dazu gesetzt wird, weil ich es für bescheuert hielt, dass das Proposal für das emergency-Tag von irgendjemand als abandoned klassifiziert worden war. Auch das habe ich kurz auf talk dargestellt, und niemand hat sich beschwert... Eine eigene Key/Tag-Seite kann man m.E. für alles anlegen, was nicht gerade komplett erfunden ist. Die meisten machen erst ein Proposal usw., aber man muss nicht. Danke für die Erläuterung. Wenn es dir recht ist werde ich das teilweise auch ins Wiki übernehmen. Ich will schließlich nur klare Regeln. Wenn diese Regeln das besagen was du gerade erklärt hast, dann ist das eindeutiger, als ein Proposal-Prozess von dem erwartet wird, dass das Ergebnis in die Map Features aufgenommen werden MUSS, wenn dem garnicht so ist, sondern nur ein guter Grund vorhanden sein muss. Deshalb finde ich, muss die Vorgehensweise (die du gerade erläutert hast) dokumentiert werden, sonst muss bloss wieder geraten werden, wie man es denn machen muss/darf. Obwohl in Einzelfällen ein Obermufti (aka Admin) nützlich wäre, um mal die Seite zu sperren, wenn es nur hin- und hergeht. Aber das kommt wohl zugegeben selten vor. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Musik Genre
Am Mittwoch 21 Januar 2009 schrieb Chris-Hein Lunkhusen: Florian Schweikert schrieb: Da ich keinen tag fand um die Musikrichtung in Lokalen anzugeben habe ich mal ein proposal angefangen: Hmmm, also ich kenne keine Lokal, welches immer dieselbe Mucke spielt (bis auf ein China-Restaurant wo jedesmal wenn ich da bin Kenny-G läuft), also lasse ich das. ;-) grade bei kneipen, bars, clubs, diskotheken ist das durchaus relevant. in reinen speiselokalen sehe ich da jetzt auch keine notwendigkeit... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Plattenplatz brauchen die Tiles für Deutschland?
Michael Buchberger schrieb: Hallo Stefan, die maxspeed-Karte http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte rechne ich auch mit Kosmos, allerdings erzeuge ich nur einen overlay und nicht die ganze Karte. Die Karte hatte ich auch noch im Hinterkopf. Muss mir unbedingt mal anschauen wie Du das mit den Openlayer-Overlays gemacht hast. Du musst halt in Kosmos einstellen, dass ein transparenter Hintergrund gerendert wird und dann die Tiles als overlay in OL einbinden. Da daher viele Kacheln leer bleiben (keine maxspeed-Info), kann ich diese nach dem Rendern löschen und spare so recht viel Platz. (Allerdings dauert das Löschen mit meiner Batch-Prozedur ähnlich lange wie das Rendern...) Über Dateigröße zu ermitteln? Ja ich mache das momentan mit einer DOS-BATCH-Datei: for /R .\ %%N IN (*.PNG) DO if %%~zN LSS 1300 del %%N Funktioniert, aber ist elend langsam (Vista?) Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Martin Simon schrieb: 2009/1/21 Jan Tappenbeck o...@tappenbeck.net: Moin ! es gibt ein Tag für Cafe und Bäckerei. Wie ist nun aber ein POI zu attributieren der beide Eigenschaften vereint. Gruß Jan :-) Dasselbe Problem begegnet einem auch bei anderen Konstellationen, z.B. Hotel/Kneipe/Restaurant oder Restaurant/Biergarten... Manche tragen das als getrennte nodes mit gleichem Namen ein, andere als amenity=bla;blubb Die erste Variante funktioniert halt für die Renderer/Konverter/POI-Suche, die zweite ist meiner Meinung nach eigentlich richtiger, wird aber bis jetzt nicht ausgewertet... Wie soll eigentlich ein Renderer mit solchen POIs umgehen? Zwei Symbole übereinander/nebeneinander malen? Wäre es da nicht sinnvoller gleich einen neuen value zu definieren, also statt amenity=bla;blubb dann gleich amenity=bla_blubb und dann rein passendes Symbol generieren. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Deutsche Namen ausländischer Orte
Hallo, Ich weiß nicht ob diese Diskussion hier schon mal geführt wurde. Werden die deutschen Namen ausländischer Orte als name:de oder als old_name getaggt? Wie ich sah, haben viele Orte in Polen die deutschen Namen als old_name eingetragen bekommen. Ich meine, richtigerweise wäre name:de, weil es einfach der deutsche und nicht der alte Name des Ortes ist. Streitfälle wären Namen, die nur während der Nazizeit genutzt wurden, wie Litzmannstadt (Łódź). Wie sieht es bei den alten Straßennamen aus? Hier wäre hingegen old_name jedenfalls angebrachter, weil die deutschen Straßennamen ja heute nicht mehr gebräuchlich sind. BTW: Trage ich zusätzlich den deutschen Namen bei einem Ort ein, wird in JOSM nur noch der deutsche Name angezeigt. Gerendert wird aber weiterhin der richtige polnische Name. Grüße, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Namen ausländischer Orte
Arne Bischoff bisch...@gueldendorf.de wrote: Wie ich sah, haben viele Orte in Polen die deutschen Namen als old_name eingetragen bekommen. Ich meine, richtigerweise wäre name:de, weil es einfach der deutsche und nicht der alte Name des Ortes ist. ACK! Man denke auch an die Orte in Tschechien und Elsaß-Lothringen. Gerade bei letzterem hat ja der Besitzer mehr als einmal gewechselt. Trotzdem heißt Straßburg nicht Strasbourg. Streitfälle wären Namen, die nur während der Nazizeit genutzt wurden, wie Litzmannstadt (Łódź). Wir mappen hier und heute und nicht in der Vergangenheit. Wir taggen ja bei Chemnitz auch nicht old_name=Karl-Marx-Stadt um die Internationalisierung mal ganz weg zu lassen. 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] Entscheidungen treffen / Proposal-Prozess
Bernd Wurst schrieb: Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. Naja, aber was ist wenn einer sagt, access=destination ist per se Quark und der nächste sagt, das reicht mir für meine Ansprüche? Persönliche Vorlieben eben. Damit muss man sich wohl abfinden und weit verbreitete die persönlichen Vorlieben dokumentieren, damit nicht nur die eigenen Interpretationen berücksichtigt werden. Da es access=destination eigentlich in Deutschland garnicht geben dürfte, ist in dem Fall eigentlich eine Benutzung auch nicht schlimm. Auch wenn ich es 'Quark' finde. Aber trotzdem ist es doch besser, wenn die Daten eindeutig sind, oder nicht? Sonst kann man eben nur raten. Oder sagen wir so, damit man besser versteht was ich meine: Eindeutig genug, um mit recht hoher Wahrscheinlichkeit die vom Mapper angedachte Bedeutung herausfinden zu können. Oder tracktype: Es gibt viele die das aktuelle Schema grausam finden, alle Eigenschaften in einen Wertebereich von 1 bis 5 zu zwängen. Ich war auch skeptisch. Aber hey, es funktioniert. Man kann damit keine Statistiken machen wie viele Schlaglöcher ein Weg hat, aber man weiß ob man ihn im matschigen Herbst als Wanderweg nutzen will oder nicht. Ja. Tracktype funktioniert nicht so schlecht, wie es vielleicht aussah. Das Wiki ist eine Daten-Halde, in dem man suchen kann wenn man Tags für irgendwas braucht und in das man eintragen kann, was man selbst so benutzt. Außerdem ist es eine rudimentäre Anleitung für Einsteiger und Dokumentation für unzählige Programme aus dem OSM-Umfeld. Halde klingt eher nach Abfall. Bei manchen Artikeln im Wiki ist der Begriff auch im Rahmen der möglichen Bezeichnungen. :) Schade eigentlich. Gerade Anfänger orientieren sich doch am Wiki. Nicht jeder hat einen persönlichen Mentor. Es wurde viel Arbeit in die Umstellung des Wikis investiert, Dokumentationen und Beispiele wurden geschrieben aber die Masse hat das Tag nicht wirklich übernommen. Bis heute gibt es unterschiedliche Auffassungen was das Tag eigentlich bedeutet, denn das war schon zum Zeitpunkt der Abstimmung unklar. Genauso wie es unterschiedliche Auffassungen gibt was footway oder cycleway bedeutet. Findest du das gut? Es gibt weiterhin eine große Zahl an Mappern die das Tag nicht nutzen und prima ohne das auskommen. Fürchterlich wenig sind 40k paths aber auch nicht. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Stefan Dettenhofer (StefanDausR) wrote: Martin Simon schrieb: Hotel/Kneipe/Restaurant oder Restaurant/Biergarten... Manche tragen das als getrennte nodes mit gleichem Namen ein, andere als amenity=bla;blubb Die erste Variante funktioniert halt für die Renderer/Konverter/POI-Suche, die zweite ist meiner Meinung nach eigentlich richtiger, wird aber bis jetzt nicht ausgewertet... Wie soll eigentlich ein Renderer mit solchen POIs umgehen? Zwei Symbole übereinander/nebeneinander malen? Wäre es da nicht sinnvoller gleich einen neuen value zu definieren, also statt amenity=bla;blubb dann gleich amenity=bla_blubb und dann rein passendes Symbol generieren. Stell ich mir schwierig vor. Die Kombination könnte ja in ins beliebige wachsen. Da ist es wohl deutlich leichter, die Daten an einem Semikolon zu trennen (wie auft auch immer), als alle möglichen bli_bla_blu Kombinationen als Spezialfall zu behandeln. Welches Icon dann gerendert wird ist dann entweder Glückssache oder ein Spezialfall im Renderer. Aber wenn ich nur an den Daten interessiert bin, dann ist das parsen mit semikolongetrennten Werten deutlich leichter. Norbert smime.p7s Description: S/MIME Cryptographic Signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Mailingliste Franken
Ulf Lamping schrieb: Es gibt jetzt eine neue Mailingliste für Franken. Ein Schwerpunkt wird wahrscheinlich der Raum Nürnberg/Fürth/Erlangen bilden, aber es sind auch Leute aus anderen fränkischen Gegenden gern gesehen. Hi Ulf, wo melde ich mich den am Besten an? Die Region hier nennt sich trefflich Hohenlohe Franken. André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Guenther Meyer schrieb: Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Bernd Wurst schrieb: Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Bisher hat scheinbar niemand genau diese Ansprüche, die du hast. Es gibt schon einige, aber anscheinend nicht genug. Oder sie sind sich der Unterschiede nicht bewusst. sinnvollerweise sollten solche dinge so getaggt, wie es die stvo fuer das jeweilige schild beschreibt, das ist zumindest in diesem fall recht eindeutig. leider ist aber die wahrscheinlichkeit, dass ein autofahrender mapper nur aus seinem blickwinkel mappt, sehr hoch. viele dinge fallen einem erst auf, wenn man selber betroffen ist. entpsrechende presets in den editoren koennten diese situation sicherlich verbessern... Presets sind ja letztlich wie Dokumentation im Wiki: Vorschläge wie man etwas Taggen kann. Ich habe auch versucht diese Vorschläge an der STVO auszurichten. Denn auch wenn es eindeutig ist, denkt (wie du richtig sagst) nicht jeder Mapper an die gleichen Dinge. Insofern ist es von Vorteil wenn man da Vorschläge macht, damit nicht jeder wieder neu die Bedeutung der Verkehrszeichen nachschlagen muss. Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Ich mach das. Vielleicht hat es dann wenigstens ETWAS Gutes, wenn ich so gründlich sein will... gruendlichkeit ist sehr gut! leider wird es trotzdem wohl nie eine garantie geben, dass alle vorhandenen hoehen- und gewichtsbeschraenkungen auch in die datenbank eingetragen wurden. Darum geht es mir auch nicht, die Garantie kann wohl keiner geben. Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Nein. Es legt bisher niemand etwas fest sondern mit funktionierenden Anwendungen kann man eine große Zahl an Mitstreitern motivieren, freiwillig am gleichen Strang zu ziehen. Womit es letztlich festgelegt ist. Da es technisch sowieso nicht möglich ist jemanden zu etwas zu zwingen, ist es wenn die große Zahl mitzieht, quasi festgelegt. man kann sich dann zumindest darauf verlassen, dass etwas in einem gewissen rahmen funktioniert, auch wenn es nicht die optimale loesung darstellt. Genau. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. eindeutig ist besser, da stimme ich dir zu. auf welche art das realisiert wird, ist da zweitrangig. das problem ist aber einerseits, dass eindeutig nicht zwangslaeufig einfacher bedeutet (was sich aber auf userseite durchaus realisieren liesse), und dass dafuer altbekannte mechanismen und pfade, die ja funktionieren, zugunsten neuer verlassen werden muessen. Das kann ich so stehen lassen. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Guenther Meyer schrieb: Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Guenther Meyer schrieb: du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. Ich hab jetzt schon keine Lust mehr. du gibst aber schnell auf ;-) leider sind manche dinge bei osm nicht so einfach, wie sie sein koennten... es gibt sehr viele dinge, die sich verbessern liessen, und verschiedene leute haben verschiedene konzepte. es waere schade, wenn neue ideen nicht genannt werden, weil sie nicht angenommen werden koennten. Naja, wenn man sowas hier vorschlägt schlägt einem eben gleich eine Welle von Mails entgegen, die nicht gerade motivierend sind. die alternative waere - wie schon vorgeschlagen - das ganze parallel zu osm aufzuziehen, und zu hoffen, dass genug leute mitmachen... Da habe ich nun garkeine Ambitionen. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Am Mittwoch 21 Januar 2009 schrieb Stefan Dettenhofer (StefanDausR): Wie soll eigentlich ein Renderer mit solchen POIs umgehen? Zwei Symbole übereinander/nebeneinander malen? je nach zweck der karte das eine oder das andere, oder beide nebeneinander. bzw. ueber einen benutzerkonfigurierbaren filter, der nur bestimmte einblendet. pauschal alle moeglichen pois einzuzeichnen macht sowieso keinen sinn, da wird man irgendwann nichts mehr erkennen koennen... Wäre es da nicht sinnvoller gleich einen neuen value zu definieren, also statt amenity=bla;blubb dann gleich amenity=bla_blubb und dann rein passendes Symbol generieren. finde ich nicht sinnvoll. es gibt zuviele kombinationen, als dass man das vernuenftig realisieren koennte. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wieviel Plattenplatz brauchen die Tiles für Deutschland?
Hi Stefan, Du musst halt in Kosmos einstellen, dass ein transparenter Hintergrund gerendert wird und dann die Tiles als overlay in OL einbinden. Hatte ich vor längerem auch schon gefunden: | LandBackgroundColor || #00FF Über Dateigröße zu ermitteln? Ja ich mache das momentan mit einer DOS-BATCH-Datei: for /R .\ %%N IN (*.PNG) DO if %%~zN LSS 1300 del %%N Funktioniert, aber ist elend langsam (Vista?) Ich benutze auch Vista. Vielleicht mal ein kleines .net Progrämmchen schreiben das dies macht. Macht es Openlayers nix aus, wenn er zwischendurch keine Tiles findet, oder hast Du das abgefangen? Tschuess Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] API 0.6 Umstellung: 21 bis 23 März 2008
Sven Anders schrieb: Auf Talk [1] kam gerade eine Mail von Steve, das die Umstellung am 21/22 März stattfinden soll. Wahrscheinlich wird es auch danach noch zu Ausfällen kommen oder etwas haken. Die API wird komplett abgeschaltet, so das es keinen Sinn macht zu dem Termin z.B. eine Mapping Party dort zu planen. Bitte gebt diese Infos auch auf die Lokalen-Mailinglisten und an Foren etc. weiter. 1: http://lists.openstreetmap.org/pipermail/talk/2009-January/033294.html bzw. http://lists.openstreetmap.org/pipermail/talk/2009-January/033296.html In der Mail von Frederik [1] war es der 20.-23. März. Im deutschsprachigen Forum wurde es auch schon angesprochen. Aber sicherlich kann man es nicht oft genug sagen. :) 1: http://lists.openstreetmap.org/pipermail/talk-de/2009-January/034373.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Namen ausländischer Orte
On Wed, 21 Jan 2009, Arne Bischoff wrote: Wie ich sah, haben viele Orte in Polen die deutschen Namen als old_name eingetragen bekommen. Ich meine, richtigerweise wäre name:de, weil es einfach der deutsche und nicht der alte Name des Ortes ist. Streitfälle wären Namen, die nur während der Nazizeit genutzt wurden, wie Litzmannstadt (Łódź). Ich nehme name:de im Gebiet der Tschechei. Ich glaube das old_name ist ein Überbleibsel aus älteren Tagen, wo name:de noch nicht so verbreitet war. Falls ich so etwas treffe, dann korrigiere ich es in der Regel. Wie sieht es bei den alten Straßennamen aus? Hier wäre hingegen old_name jedenfalls angebrachter, weil die deutschen Straßennamen ja heute nicht mehr gebräuchlich sind. Würde ich trotzdem name:de nutzen. Oder old_name:de. Ich würde unter old_name wirklich einen reinen Umbenennungswert sehen und nicht einen Sprachwechsel. BTW: Trage ich zusätzlich den deutschen Namen bei einem Ort ein, wird in JOSM nur noch der deutsche Name angezeigt. Gerendert wird aber weiterhin der richtige polnische Name. Das kannst Du einstellen, wenn Du willst. Es wird nicht der deutsche Name gezeigt, sondern der Name in der Sprache des Benutzers (was bei Dir halt deutsch ist :-). Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Am 21. Januar 2009 15:15 schrieb Norbert Wenzel n_wen...@gmx.net: Stefan Dettenhofer (StefanDausR) wrote: Wie soll eigentlich ein Renderer mit solchen POIs umgehen? Zwei Symbole übereinander/nebeneinander malen? Wäre es da nicht sinnvoller gleich einen neuen value zu definieren, also statt amenity=bla;blubb dann gleich amenity=bla_blubb und dann rein passendes Symbol generieren. Stell ich mir schwierig vor. Die Kombination könnte ja in ins beliebige wachsen. Da ist es wohl deutlich leichter, die Daten an einem Semikolon zu trennen (wie auft auch immer), als alle möglichen bli_bla_blu Kombinationen als Spezialfall zu behandeln. Welches Icon dann gerendert wird ist dann entweder Glückssache oder ein Spezialfall im Renderer. Aber wenn ich nur an den Daten interessiert bin, dann ist das parsen mit semikolongetrennten Werten deutlich leichter. Eventuell könnte ein renderer die Icons für die einzelnen amenities nehmen, jeweils um 50% verkleinern und in einem 2x2-Raster in der größe eines normalen icons anordnen. das sollte noch zu erkennen sein und mehr als 4 Werte dürften nicht so häufig vorkommen... dasselbe kann man dann auch für die Hausnummer nutzen. :-) -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geschäft mit mehreren Funktionen
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Stefan Dettenhofer (StefanDausR): Wie soll eigentlich ein Renderer mit solchen POIs umgehen? Zwei Symbole übereinander/nebeneinander malen? Wäre es da nicht sinnvoller gleich einen neuen value zu definieren, also statt amenity=bla;blubb dann gleich amenity=bla_blubb und dann rein passendes Symbol generieren. Wenn du dann eine Bäckerei mit Café erfindest und eine Bäckerei mit Lotto-Annahmestelle und eine Bäckerei mit Zeitungskiosk und eine Bäckerei mit Partyservice und eine Bäckerei mit Computerladen... Ein POI-finder, der dann nur eine Bäckerei suchen soll muss dann entweder ein vielfaches an Tags lernen oder wild mit Platzhaltern jonglieren um vielleicht was passendes zu finden. Das ; als Trennzeichen ist halbwegs üblich und sollte in normalen Werten nicht vorkommen. Es kann daher zur Auftrennung von solchen Konstrukten fest benutzt werden. Anders herum wird ein Schuh draus: Der Renderer kann sich überlegen was er alles rendern soll und dann für die Menge an Tags die er darstellen soll das richtige heraussuchen. Wenn er ein Symbol hat für Bäckerei und Café, dann nimmt er das. Hat er nur eins für Bäckerei, dann nimmt er das, ist ja besser als nix. Gruß, Bernd -- Jedes gelöste Problem ist einfach. - Thomas Alva Edison 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] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Guenther Meyer schrieb: sinnvollerweise sollten solche dinge so getaggt, wie es die stvo fuer das jeweilige schild beschreibt, das ist zumindest in diesem fall recht eindeutig. leider ist aber die wahrscheinlichkeit, dass ein autofahrender mapper nur aus seinem blickwinkel mappt, sehr hoch. viele dinge fallen einem erst auf, wenn man selber betroffen ist. entpsrechende presets in den editoren koennten diese situation sicherlich verbessern... Presets sind ja letztlich wie Dokumentation im Wiki: Vorschläge wie man etwas Taggen kann. Ich habe auch versucht diese Vorschläge an der STVO auszurichten. Denn auch wenn es eindeutig ist, denkt (wie du richtig sagst) nicht jeder Mapper an die gleichen Dinge. Insofern ist es von Vorteil wenn man da Vorschläge macht, damit nicht jeder wieder neu die Bedeutung der Verkehrszeichen nachschlagen muss. mein vision bzgl. der presets ist die folgende: der mapper will ein schild eintragen, und klickt dazu im editor auf ein bildchen desselben, fuegt evtl. durch klicken auf deren fotos noch zusatzschilder hinzu (haeufig benutzte kombinationen kann man vielleicht auch speichern), so dass er letztendlich im editor genau dasselbe sieht, wie auch in der freien wildbahn. mit einem klick auf ok generiert der editor eindeutige tags, die genau diese situation beschreiben, ohne dass sich der user jemals gedanken darueber machen musste, wie er denn sowas jetzt realisiert... eindeutig ist besser, da stimme ich dir zu. auf welche art das realisiert wird, ist da zweitrangig. das problem ist aber einerseits, dass eindeutig nicht zwangslaeufig einfacher bedeutet (was sich aber auf userseite durchaus realisieren liesse), und dass dafuer altbekannte mechanismen und pfade, die ja funktionieren, zugunsten neuer verlassen werden muessen. Das kann ich so stehen lassen. endlich mal jemand der mir zustimmt... ;-) 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] Geschäft mit mehreren Funktionen
2009/1/21 Martin Simon grenzde...@gmail.com Dasselbe Problem begegnet einem auch bei anderen Konstellationen, z.B. Hotel/Kneipe/Restaurant oder Restaurant/Biergarten... Manche tragen das als getrennte nodes mit gleichem Namen ein, andere als amenity=bla;blubb Die erste Variante funktioniert halt für die Renderer/Konverter/POI-Suche, die zweite ist meiner Meinung nach eigentlich richtiger, wird aber bis jetzt nicht ausgewertet... naja, da kann man auch streiten, das Hotel wird ja z.B. oft einen anderen Eingang haben als die Kneipe. Im Biergarten laesst sich das/die Restaurant(s) auch lokalisieren, die Namen sind da oft ebenfalls verschieden, von daher sind mehrere POIs oder getrennte Flaechen IMHO oft richtiger als der Versuch, alles auf einen Knoten zu legen. Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo Bernd, Ein einfacher Mapper wird gar nicht wissen, auf was er alles achten muss. Die meisten Neuen sind begeistert von der OSM-Idee und hoch motiviert. Wenn wir ihnen sagen, wie das Mappen funktioniert und worauf sie achten müssen, dann werden sie sich freudig bemühen, das möglichst genau so zu machen - und sich Mitte der Woche über die schönen Ergebnisse freuen. Dazu ist es erforderlich, dass wir: - im Wiki möglichst verständliche Anleitungen schreiben - klare verständliche Tagging-Regeln formulieren - im Editor eine regelkonforme Benutzerführung gestalten - die gemappten Daten möglichst schnell und vollständig anzeigen (dabei geht es NICHT um Einschränkung der Freiheit, sondern nur um Verbesserung von OSM, der Daten und der möglichen Anwendungen. Freiheit ist die Grundlage von Innovation) Wenn aber in Zukunft mal die Information die Runde macht, dass jetzt das erste Massenmarkt-taugliche LKW-Navi auf Basis von OSM-Daten existiert und OpenStreetBugs in dem Gerät voll integriert ist, dann prophezeihe ich dir, dass die Daten *sehr* schnell nachgetragen werden. Dazu ist bereits ein Programm in Entwicklung, das Onroad-Tagging für Anfänger erlaubt... Man hat halt nen anderen Blick, mit welchem Verkehrsmittel man grade Ja - und diesen Blick kann man durch gute Information - beispielsweise im Wiki - erweitern, schärfen, vertiefen. Damit man/frau zunehmend die Belange auch anderer Anwender mit einbeziehen lernt. Besser im Sinne von eindeutiger. Das wäre ein Kriterium. Andere wären: - verständlicher - schneller erfassbar (Tagging) - besser erkennbar (Karte lesen, Routing) - umfassender (LKW, Fahhrad, Pferd) - ... aber was ist wenn einer sagt, ist Quark und der nächste sagt, das reicht mir für meine Ansprüche? Dann versucht man aus beiden Bedürfnissen das für alle denkbaren Anwendungsfälle Optimale zu bilden. Das Wiki ist eine Daten-Halde die aber nur Sinn macht, wenn die Daten - schnell auffindbar (Links, Gliederung, Kategorien) - verständlich formuliert - eindeutig - umfassend - schnell erfassbar sind wurde etwas vage vorgeschlagen und jeder versteht etwas anderes darunter... Bis heute gibt es unterschiedliche Auffassungen was das Tag eigentlich bedeutet, denn das war schon zum Zeitpunkt der Abstimmung unklar. Eben. Und dann macht halt jeder irgendetwas... In der Programmierung nannte man das Spaghetti-Programm. Diese waren ganauso wenig dokumentiert. Es gibt weiterhin eine große Zahl an Mappern die das Tag nicht nutzen und prima ohne das auskommen. Aber halt nicht daran denken, dass eine Geo-DB eben nur mit einer funktionierenden Anwendung Sinn macht, also /nicht/ ohne diese zu berücksichtigen auskommt. Die Lösung heisst: *Best Practice* dokumentieren, bekannt machen, für Umsetzung sorgen. Also Qualität generieren schon beim Erfassen und Speichern der Daten, immer im Hinblick auf mögliche Anwendungen. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche Namen ausländischer Orte
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sven Geggus: Wir taggen ja bei Chemnitz auch nicht old_name=Karl-Marx-Stadt um die Internationalisierung mal ganz weg zu lassen. Das wäre aber ein Fall bei dem ich old_name wirklich einsetzen würde. Warum denn nicht? Den älteren Menschen falen doch oft nur die alten Namen für irgendwas ein und da sollen sie doch auch Erfolg haben im Namefinder. ;-)) Gruß, Bernd -- Das Leben ist wie eine Toilettenbrille: Man macht viel durch, aber auch so manches geht daneben. 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] Deutsche Namen ausländischer Orte
On Wed, 21 Jan 2009, Sven Geggus wrote: Wir mappen hier und heute und nicht in der Vergangenheit. Wir taggen ja bei Chemnitz auch nicht old_name=Karl-Marx-Stadt um die Internationalisierung mal ganz weg zu lassen. Diese Aussage ist falsch. Wir tragen construction-Wege ein, wir tragen verlassene Straßen und Eisenbahnlinien ein. Wir tragen alte Namen ein. Wir mappen also nicht nur in der Gegenwart. Das wäre ja auch grausam. Bloss weil irgendwer wieder mal Straßen umbenennt findet man nachher nichts mehr, weil die Karte den neuen Stand darstellt, aber die eigene Adresse nicht. In Königs Wusterhausen gibt es sogar Straßen mit zwei Straßenschildern, jeweils eins davon rot durchgestrichen. Genau für solche Umbenennungen ist old_name ja da und Karl-Marx-Stadt ist ein Beispiel, wo old_name sinnvoll ist. Stell Dir mal vorher einer der ehemaligen Studenten der DDR kommt nach Jahren wieder und sucht seinen Studienort Karl-Marx-Stadt in der Karte. Wenn der nicht drin steht wundert er sich, wenn drin steht, dass es jetzt Chemnitz ist wird er denken Aha, in Deutschland benennen die auch dauernd alles um und merkt sich ab jetzt Chemnitz. Und digitale Karten haben ja eben den Vorteil, dass nicht alles auch im Kartenbild sichtbar sein muss. Bei Orten ist das eher ein kleines Problem, bei Straßennamen ist es noch viel wichtiger. Statt dass mich das Navigationsgerät nach einer Eingemeindung kommentarlos zum falschen Fleck führt ist eine kurze Nachfrage Es gibt auch eine alte Hauptstraße welche jetzt Ahornweg heißt, meinen sie vielleicht die sehr hilfreich. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
