Re: [Talk-de] Sportvereine
Am 16.10.2010 07:41, schrieb Bernd Wurst: IMHO auf jeden Fall mit e.V.. Bei OSM gilt, den ausführlichsten Namen zu erfassen, denn Kürzen kann ein Algorithmus. e.V. als Abkürzung würde ich dabei dennoch stehen lassen, da es (genau wie GmbH) eine offizielle Schreibweise der Rechtsform ist. Ich würde bei sowas auch e.V. anfügen - nicht weil es die offizielle Schreibweise ist (die kann man bei Bedarf auch in official_name eintragen), sondern weil es klarer macht worum es geht. Deine generellen Aussagen sind mir aber etwas zu allgemein geraten. Der ausführlichste Name wäre xy eingetragener Verein, und das will wirklich keiner auf der Karte lesen ;-) Außerdem ist die Aussage das kann ein Algorithmus kürzen so generell ziemlich fragwürdig. Die Renderer können unmöglich alle Kürzungsmöglichkeiten in irgendwelchen Namen kennen - oder zumindest wird das noch shr, shr lange dauern bis sie es können. Noch eine Anmerkung zu langen Namen: Ich möchte eigentlich nicht: Spiel- und Turnverein Rot/Gold Alptraumania Leverkusen von 1903 e.V. auf der Karte lesen müssen (solange es sich um eine allgemeine und keine Turnvereinskarte handelt), und es wird ziemlich schwierig daraus algorithmisch was sinnvolles zu kürzen. Also eher sowas eintragen wie: name=Alptraumania e.V. oder name=Turnverein Alptraumania und zusätzlich: official_name=Spiel- und Turnverein Rot/Gold Alptraumania Leverkusen von 1903 e.V. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sportvereine
Hallo Stephan Wolff wrote: 4. Sammelvereine mit mehreren Sparten z.B. Dorfverein mit Fußball-, Tennis-, Turn- und Kanuabteilung - Jede Sportanlage mit name=SV Neudorf e.V. und sport=* Mögliche Alternativen: - name=SV Neudorf e.V. - Tennisabteilung - name=SV Neudorf e.V. (Tennisabteilung) Generell sollte im name-Tag der Name auftauchen und keine Beschreibung. Diese ist besser in seperaten Tags aufgehoben. Wenn du der Meinung bis, man könnte es als Mapper missverstehen mit den Zusatztags, dann kann man im note-Tag noch eine Beschreibung hinterlassen. Bei den Abkürzungen finde ich es sinnvoll, wenn man diese nutzt. Bedingung: sie müssen in dem Kontext eineindeutig sein. aighes -- View this message in context: http://gis.638310.n2.nabble.com/Sportvereine-tp5639928p5641531.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation runterladen?
?xml version=1.0 encoding=UTF-8?\nosm version='0.6' enerator='JOSM' moin moin, hier noch ein fast ungebrauchtes g zum einbauen, damit aus dem enerator wieder ein generator wird. ;) lg walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Relation-runterladen-tp5597080p5641594.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] lnm: freigegebenes Heft zu GPS, freien Karten und Linux
Hallo Zusammen, das Linux Magazin gibt inzwischen die Hefte die ein Jahr alt sind frei, aktuell ist dies also das Heft 12/2009 mit den Themen Linux and the City. Großer GPS-Wegweiser - freie Karten und Tools für Handys und Netbooks: http://www.linux-magazin.de/NEWS/Kostenloses-Lesefutter-Magazin-12-2009-kartografiert-die-Linux-Welt = http://www.linux-magazin.de/Heft-Abo/Ausgaben/2009/12 u.a. lnm: Openstreetmap für die Westentasche: Gute Führung http://www.linux-magazin.de/Heft-Abo/Ausgaben/2009/12/Gute-Fuehrung und vieles mehr :) -- Grüße, Benny gpg 0xFC505AB0 jabber be...@benny.de sip be...@benny.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wasserwerk - wie taggen
HI ! bisher wurde primär von Wasserzapfstellen gesprochen. In unseren Breiten wird die Wasserversorgung zentral geregelt. Weiß einer wie Wasserwerke und die zugehörigen (nicht frei zugänglichen) Brunnen getaggt werden ?? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt des Monats Oktober - Halbzeit
Hi ! sieht gar nicht so schlecht aus nach der halben Zeit: http://wiki.openstreetmap.org/wiki/DE:Project_of_the_month/2010/october#Statistik Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: Liste der bisherigen Zustimmungen veroeffentlicht
Walter Nordmann walter.nordm...@web.de writes: glaub ich nicht, dass er irgendwas erlauben wird. er ist doch vor einigen monaten tiefst-beleidigt und eingeschnappt abgehauen nicht ohne seine daten brutal zu löschen. Das wäre dann vandalismus gewesen und man hätte das mutwillige löschen rückgängig machen müssen. und trotzdem auf platz 2. alle achtung. Vielleicht zählt das löschen ja auch als edit... echt schade um ihn, er hat gute arbeit geleistet. Ich würde das entspannt sehen. Seine bearbeitungen waren wohl stellenweise schon etwas eigenwillig... -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserwerk - wie taggen
Am 16.10.2010 18:59, schrieb Jan Tappenbeck: HI ! bisher wurde primär von Wasserzapfstellen gesprochen. In unseren Breiten wird die Wasserversorgung zentral geregelt. Weiß einer wie Wasserwerke und die zugehörigen (nicht frei zugänglichen) Brunnen getaggt werden ?? http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dwater_works Gruß, ULFL P.S: Wäre nicht schlecht, wenn du ab und zu mal selber die Suche verwenden würdest ... ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] farmland in DE:MapFeatures
Moin, der Eintrag zu farmland in den http://wiki.openstreetmap.org/wiki/DE:Map_Features müsste mal berichtigt werden. Ist derzeit als veraltet eingetragen. Ich selber komme mit den Templates nicht zu recht. In den Original-MF sind beide Tags noch gleichberechtigt (farmland: Synonyme for farm) ich denke das sollte man angleichen. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 13 10.10. - 16.10.10
Wir haben soeben die neuste Ausgabe der Wochennotiz veröffentlicht, wie immer mit allen wichtigen und interessanten Neuigkeiten aus dem OSM-Universum: http://blog.openstreetmap.de/2010/10/osm-wochennotiz-nr-13/ Viel Spaß beim Lesen! -Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 15. Oktober 2010 13:32 schrieb NopMap ekkeh...@gmx.de: M∡rtin Koppenhoefer wrote: Ein weiteres Argument dagegen. Heute sind diese Fehler offensichtlich. Wenn sie beim Import pauschal ausmultipliziert werden, entstehen mehrere sich überlagernde Objekte, die insgesamt sinnlos sind, das Renderergebnis ist Zufall aber jedes für sich sieht korrekt aus. Den Fehler findet man nur noch unter größten Schwierigkeiten. Um es nochmal klar zu sagen: ich sprach nie davon, das in der Haupt-DB zu machen. Lokal kann es Sinn machen, weil die Werte sonst halt meist komplett untergehen. Dass dabei mehrere Objekte auf demselben Punkt entstehen, ist klar, das Renderergebnis ist aber trotzdem kein Zufall, sondern Ergebnis der Renderregeln (in einem dynamischen Rendering, wo man die POIs ein- und ausblenden kann, ist es z.B. egal, sonst muss man halt die Prioritäten so setzen, wie man es will). Bei der Suche spielt es auch überhaupt keine Rolle, da interessiert nur, ob man was findet oder nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Freitag 15 Oktober 2010 13:32:06 schrieb NopMap: Wenn sie beim Import pauschal ausmultipliziert werden, entstehen mehrere sich überlagernde Objekte, die insgesamt sinnlos sind, das Renderergebnis ist Zufall aber jedes für sich sieht korrekt aus. Den Fehler findet man nur noch unter größten Schwierigkeiten. Ich glaube, man muss hier verschiedene Dinge trennen, die zu häufig in einen Topf geworfen werden und nagel hier mal 7 Thesen an die Listentür ( :-) ) 1. In der real existierenden Welt gibt es Dinge, die nicht nur eine Eigenschaft einer Gruppe haben. Als einfaches Beispiel für Farben mag das Zebra herhalten, als sinnvolle Tags für OSM sehe ich hier den Wirt, der tatsächlich Speisen mehrerer Küchen zubereitet, häufige Beispiele dafür cucina=greek;italian oder greek;turkish; und es gibt Haltestellen, an denen - für den Fahrgast praktisch, für den geplagten OSM-Renderer-Schreiber ärgerlich - mehr als eine Linie des ÖPNV halten. 2. Diese Dinge dürfen für OSM nicht einfach, weil es der Renderer so will, unter den Tisch fallen. Es ist für mich nicht akzeptabel, dass der Mapper sagt, hier gibt es zwar griechische und italienische Gerichte, aber ich esse lieber griechisch, also tagge ich nur greek (oder umgekehrt). 3. Diese Dinge können auf verschiedene Weise verwaltet werden. Beim ÖPNV werden die Linien und ihre Haltestellen in eine Relation gepackt. Das vermeidet das Semikolon an der Haltestelle. Sieht wie eine prima Lösung aus. Leider ergibt sich aber beim Rendern der Haltestelle das gleiche Problem wie bei jedem anderen Modell - die Haltestelle gehört zu mehreren Relationen , zu mehreren Linien, und bei dieser Auswertung tauchen - schwupp - die verschiedenen Liniennummern (Eigenschaften) wieder auf. Damit will ich nicht kritisieren, dass hier Relationen benutzt werden, das ist beim ÖPNV sinnvoll. Ich will nur aufzeigen, dass dadurch die Anhäufung von Eigenschaften nicht verhindert wird, da sie fatalerweise in der Wirklichkeit existiert. Folgerichtig wäre es zwar möglich, auf das Semikolon bei Gaststätten zu verzichten, indem eine Relation aller griechischen, italienischen,... Restaurants erzeugt wird. Bei Auswertung der einzelnen Gaststätte hat der Renderer aber wieder das gleiche Problem - 2 oder noch mehr Relationen, weil der verd. Koch sich einfach nicht auf eine Küche festlegen will. Gewissermaßen kocht er damit OSM-widrig. Leider sind wir noch nicht mächtig genug, um diesem Treiben ein Ende zu setzen ( :-) ) (für den, der Ironie nicht erkennt). Daraus folgt, dass die Relation das Problem nicht löst, sondern versteckt. Mehr noch - sie ruft die Relations-Kritiker auf den Plan, die zwar keine Alternative wie z.B. eine Kollektion anbieten, sich aber jede Sammel-Relation verbieten. Was mach jetzt der verzweifelte Mapper, der die Küche korrekt taggen will, die Relation nicht darf, das Semikolon nicht soll und die doppelte Küche sieht? Macht er 2 Nodes, eine für jede Küche, worauf alle Auswertungen mit 2 Restaurants reagieren? Oder verbindet er die 2 Nodes mit dem Gebäude in einer Site-Relation?. Das wäre ein gangbarer Weg, der aber nichts daran ändert, dass der Renderer vor dem Problem steht, wie er jetzt das darstellen soll. Abgesehen davon, dass dieses Tagging sachlich falsch wäre, schließlich wird nicht in 2 Küchen in einem Gebäude, sondern in einer Küche gekocht. 4. Das Problem liegt in den Scheuklappen vieler Aktiven. Es ist letztlich egal, ob einer der heutigen Renderer eine Sache richtig darstellt. Ich wiederhole es nochmal: Wir taggen nicht für irgendeine Anwendung, sondern ausschließlich die Realität, und zwar so gut, wie es uns zur Zeit möglich ist. Das bedeutet nicht, dass man jetzt unbedingt cucina=kretian taggen muss, wenn der Wirt hauptsächlich Gerichte aus Kreta anbietet. Greek ist auch dafür sachlich richtig (gehört ja dazu) und für alle Anwendungen leichter auswertbar. Kretian ist andererseits aber auch nicht falsch - ein Ermessensfall, in dem ich Sympathie für die Bezeichnung greek hätte (abgesehen davon, dass ich die Unterschiede in verschiedenen griechischen Küchen einfach unterstelle, ohne sie zu kennen). In Bezug auf die deutsche Küche gilt ähnliches: bavarian, bremian, hamburgian, rhinian - Stopp!! Vielleicht für ein Subtag. Der Ausländer wird german taggen und Schweinebraten mit Ködel (und Sauerkraut!!) darunter verstehen. 5. OSM ist eine überholte Bezeichnung. Das Projekt wurde von Steve Cost mal Openstreetmap getauft, weil er sich damals eine offene Straßenkarte vorstellte. Das hätte vermutlich jeder am Anfang so gesehen. Inzwischen ist das Projekt aber mutiert zu einer offenen Geodatensammlung. Es werden viele Dinge gemappt, die kein Renderer darstellt oder kein Renderer darstellen kann. Einkaufszentren in 3D zu mappen ist zur Zeit - betrachtet aus Sicht der Renderer - sinnfrei. Es ist aber nichtsdestotrotz sachlich richtig und wird auch gemacht. 6. Der Lizenzwechsel ist nur die logische Antwort
Re: [Talk-de] Sportvereine
Am 15. Oktober 2010 20:24 schrieb Stephan Wolff s.wo...@web.de: Sportvereine werden sind in OSM sehr unvollständig und ziemlich unterschiedlich eingetragen, obwohl sie in vielen Dörfern oder Stadtteilen eine der wichtigsten Institutionen sind und häufig als Veranstaltungsorte erscheinen. Wie kann man Sportvereine einheitlich (und somit auswertbar) in OSM eintragen? Was meint ihr? Ich finde, der Verein an sich kommt noch ein bisschen kurz bei Deinen Vorschlägen (ist nur im Namen enthalten). M.E. sollte man für Vereine ein neues Tag entwerfen, wo dann auch andere als Sportvereine damit getaggt werden können, z.B. association (das kann auch andere Rechtsformen von Vereinigungen, vor allem in Ländern ausserhalb Deutschlands, beinhalten, wo es keine Vereine nach dt. Recht gibt). Z.B. association=sport oder gleich spezifischer association=soccer So könnte man dann auch das Büro erfassen: office=association bin mir nicht ganz sicher, ob das eine tolle Idee ist, oder man es doch lieber anders aufzäumen sollte, was meint Ihr? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 16. Oktober 2010 23:56 schrieb Wolfgang wolfg...@ivkasogis.de: 7. Es bleibt die Diskussion über das Semikolon. Mich hat die Implementation 5 Minuten und 3 Programmzeilen gekostet. Das ist zugegebenermaßen nicht ganz fair. da die App neu ist. Wer eine bessere Möglichkeit weiß, multiple Eigenschaften in den Daten so abzubilden, dass es für den Mapper einfach anzuwenden ist, melde sich bitte. Aber nicht mit dem üblichen Semikolon - Protest - Geheul, sondern konstruktiv. Damit beziehst Du Dich auf den Entwicklungsteil, was aber allgemein von den anderen Technikern auf den Liste erwähnt wird ist, dass das Parsing dadurch deutlich länger dauern würde. Kommt aber sicher darauf an, ob das überhaupt ne Rolle spielt (Gesamtdauer), oder ob dreimalsolang von 1 Minute dann halt 3 Minuten sind.ohne Ansonsten kann ich Deinen Gedanken weitgehend zustimmen, es ist in der Tat so, dass die Realität sich in absehbarer Zeit nicht nach OSM richten wird, und wir daher Lösungen finden sollten, sie trotzdem abzubilden. Zu den Küchen: es ist halt nicht gesagt, dass deutsch als Haupttag und dann die einzelnen deutschen Lokalen Küchen wirklich die überzeugendste Lösung ist, bzw. dass diese rein geografische Einteilung auch sonstwo am besten funktioniert. Es wäre z.B. genauso denkbar, im Haupttag nach Gegend (Meer, Berge, etc.) zu unterscheiden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt des Monats Oktober - Halbzeit
jan99 wrote: sieht gar nicht so schlecht aus nach der halben Zeit: http://wiki.openstreetmap.org/wiki/DE:Project_of_the_month/2010/october#Statistik ja, wenn klar wäre, was diese statistik bedeuten soll: a) die anzahl getaggter wasserstellen hat etwas zugenommen b) was bedeutet diese - für mich - obskure zahl hinter den werten? c) was ist mit den sachen, die ich immer noch nicht vernünftig eingeben kann? - mineralbrunnen, die von manchen mitstreitern als untrinkbar angesehen werden aber doch wesentlich zur namensgebung vieler orte beigetragen haben? bad schwalbach, bad ems, bad ..., baden-baden, xyz-born, ... - brunnen, die eindeutig da sind, sogar namen haben aber der öffentlichkeit nicht zur nutzung zur verfügung stehen? davon gibt es dutzende im taunus und sonst wo zur trinkwassergewinnung. - wasserstellen, die mit kein trinkwasser gekennzeichnet sind, wo aber die leute schlange stehen und sich den kofferraum mit kanistern zustellen? gerade dafür hatte ich im neuen wiki-chen und auch in dieser diskussion (fast 70 beiträge) etwas mehr substanz erwartet. muss ich mir immer noch in diversen wikis, poposals, forenbeiträgen, gerendertern karten, rohdaten, spezialprogrammen ansehen, wie das gemacht wird oder gibt es da irgend etwas, was die ganze chausse verwendbar zusammenfaßt? sorry, dass ich nerve, aber nach 3 wochen diskussion (sehr interessant die diskussion über die korrekte englische schreibweise - lernt lieber chinesisch) hab ich etwas mehr erwartet. gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/Projekt-des-Monats-Oktober-Trinkwasser-tp5582848p5643213.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
