Re: [Talk-de] api-download bei semikon-getrennten-values
also ich glaube, ich verstehe hier bahnhof. für mich ist ein semicolon - genau wie anderer zeichen - ein TRENNER zwischen verschiedenen teilen. was soll das denn am anfang der tags? willst du damit (d)einem parser das leben einfacher machen? oder was soll das? -1 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/api-download-bei-semikon-getrennten-values-tp5620526p5650168.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] api-download bei semikon-getrennten-values
Hallo, Am Dienstag 19 Oktober 2010 11:42:48 schrieb Walter Nordmann: also ich glaube, ich verstehe hier bahnhof. für mich ist ein semicolon - genau wie anderer zeichen - ein TRENNER zwischen verschiedenen teilen. was soll das denn am anfang der tags? willst du damit (d)einem parser das leben einfacher machen? oder was soll das? -1 walter ok, etwas unklar formuliert, außerdem geht es _ausschließlich_ um einen Test. Bsp: tag k='landuse' v='residential' / verändert in tag k='landuse' v='residential;1.Wert;2.Wert;3.Wert' damit der Test laufen kann. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Wolfgang-4 wrote: Bsp: tag k='landuse' v='residential' / verändert in tag k='landuse' v='residential;1.Wert;2.Wert;3.Wert' negativ. was soll wert1-3 sein? subtags von residential? und woher willst du -automatisch- die richtigen werte für w1-3 nehmen? ausserdem ist mir immer noch unklar, was die ganze sache soll. omm... 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/api-download-bei-semikon-getrennten-values-tp5620526p5650304.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] api-download bei semikon-getrennten-values
Am 19.10.2010 12:32, schrieb Walter Nordmann: ausserdem ist mir immer noch unklar, was die ganze sache soll. omm... Also so wie ich das sehe wollte er beweisen, dass das gesonderte Verarbeiten von Semikolon getrennten Tags nicht besonders viel extra Aufwand bedeutet. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Peter Körner wrote: Also so wie ich das sehe wollte er beweisen, dass das gesonderte Verarbeiten von Semikolon getrennten Tags nicht besonders viel extra Aufwand bedeutet. jo, jetzt ist mir sein beitrag klar ;) danke. war nur heute früh etwas geplättet, da für mich nicht rüberkam, was das sollte. 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/api-download-bei-semikon-getrennten-values-tp5620526p5650378.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] api-download bei semikon-getrennten-values
Wolfgang schrieb: Das bedeutet nicht, dass man jetzt unbedingt cucina=kretian taggen muss, wenn der Wirt hauptsächlich Gerichte aus Kreta anbietet. Da würde ich eher cretian empfehlen ;-) 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. Wenn es darum geht, Busrelationen auszufiltern, die in mehr als einem Verbund fahren und deshalb z.B. VRR;VRS im network-tag stehen haben, reicht als Datenbankabfrage: SELECT * FROM bla WHERE (network Like *VRR* Or network=Verkehrsverbund Rhein-Ruhr); Mit osmosis oder xapi-Abfrage wird das vermutlich nicht so einfach zu lösen sein. -- Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Wolfgang-4 wrote: 4. Das Problem liegt in den Scheuklappen vieler Aktiven. Das Hauptproblem liegt für mich in der stark vereinfachten Darstellung und dem Optimismus der Aktiven, die bevorzugt nur den einfachsten Fall betrachten und die tatsächliche Komplexität des Problems nicht voll erfaßt haben. Natürlich brauchen wir auf Dauer eine Lösung für das Problem mehrerer Eigenschaften. Aber es ist noch nicht mal ansatzweise ausreichend, einfach bei jedem ; das Objekt zu duplizieren. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5647847.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] api-download bei semikon-getrennten-values
Hallo, Am Montag 18 Oktober 2010 19:09:05 schrieb NopMap: Natürlich brauchen wir auf Dauer eine Lösung für das Problem mehrerer Eigenschaften. Aber es ist noch nicht mal ansatzweise ausreichend, einfach bei jedem ; das Objekt zu duplizieren. Besserer Vorschlag? bye, Wolfgang ___ 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, NopMap wrote: Das Hauptproblem liegt für mich in der stark vereinfachten Darstellung und dem Optimismus der Aktiven, die bevorzugt nur den einfachsten Fall betrachten und die tatsächliche Komplexität des Problems nicht voll erfaßt haben. Aber ist eben gerade des Erfassen der tatsaechlichen Komplexitaet ein Problem - lebt es sich nicht ohne viel besser in OSM? Wenn ich bei allem, was ich in OSM angefasst habe, vorher gewusst haette, wie komplex es ist, haette ich ja nie was gemacht ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Sonntag 17 Oktober 2010 01:35:42 schrieb M∡rtin Koppenhoefer: 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 Mal unabhängig von pro und contra Semikolon, ich habe mal testweise in ganz Hamburg in allen tags die Values mit 3 Semikolons auf 4 Werte erweitert (;1.Wert; 2. Wert; 3.Wert) Das sind gut 600.000 Tags von gut 3.000.000 Zeilen, die diese osm-Datei zur Zeit hat. Reine Laufzeit zum Parsen des Files, alle Tags eingelesen und zum Zugriff geordnet ohne weitere Vor- oder Nachverarbeitung: Normales osm-File, Test auf Semikolon deaktiviert 1:19 Normales osm-File mit Test auf Semikolon: 1:23 Mit 1.800.000 zusätzlichen Tags, abgetrennt durch Semikolon: 1:32 Das erscheint mir jetzt angesichts der Menge eigentlich nicht signifikant problematisch, insbesondere da man in der Praxis kaum von einer solchen Übertaggung auszugehen hat. Mehrfache Eigenschaften kommen vor, sie sind aber nicht die Regel. Mit etwas mehr Memory (4GB) würde der Unterschied vermutlich noch wesentlich geringer ausfallen, da das System am Ende der Tests bereits zu swappen beginnt. Gleicher Test, aber Auslassen der fest zu den Objekten gehörenden Eigenschaften wie timestamp, nur Objekt und Tags: 0:39,3 0:39,8 0:47,9 Dabei reichte das Memory. Der Test auf das Semikolon ist praktisch zu vernachlässigen, und bei realistischen Anzahlen von Mehrfacheigenschaften ist das Semikolon kein zeitliches Problem. Natürlich werden die Zahlen bei mehrfachen Testläufen noch etwas schwanken, ich habe hier keinen Laborrechner. Aber das Verhältnis zueinander wird sich kaum nennenswert verändern. Gruß, Wolfgang ___ 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.10.2010 23:56, schrieb Wolfgang: Beim ÖPNV werden die Linien und ihre Haltestellen in eine Relation gepackt. Das vermeidet das Semikolon an der Haltestelle. Nein, die Relation einer Buslinie bildet die geografische Realität ab, die man sonst nicht anders bekommen kann. Über welche Straßen führt eine Buslinie, wenn man nur die Bushaltestellen mappt? Ich gratuliere dir übrigens dazu, eine Anwendung schreiben zu können, die für Spezialfälle mit dem Semikolon umgehen kann. Ich habe nie bestritten das das geht. Ich habe allerdings weder Zeit noch Lust den Rest deiner Ausführungen zu kommentieren, da sind für mich (noch?) zuviele Denkfehler drin ... Gruß, ULFL ___ 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] 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] api-download bei semikon-getrennten-values
Am 11.10.2010 10:54, schrieb M∡rtin Koppenhoefer: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Wird vermutlich allerdings ne Weile dauern, wenn man den Planet damit durchackern will. Das ließe sich jedoch recht gut in osm2pgsql einbauen. Da mein letzter Patch für osm2pgsql [1] allerdings genau null Beachtung gefunden hat, zögere ich etwas, mich da mal drum zu kümmern.. Lg [1] http://lists.openstreetmap.org/pipermail/dev/2010-September/020613.html ___ 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, Peter Körner wrote: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Wird vermutlich allerdings ne Weile dauern, wenn man den Planet damit durchackern will. Das ließe sich jedoch recht gut in osm2pgsql einbauen. Aber nicht ganz trivial. Du muesstest ja Deinen Pseudo-Node in die planet_osm_points einfuegen, aber wenn Du im slim mode operierst und irgendwann kommt ein Update, bei dem der Original-Node von amenity=bank;atm auf nur amenity=bank geaendert wird, muesstest Du Deinen Pseudo-Node ausfindig machen und loeschen... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Peter Körner wrote: Am 11.10.2010 10:54, schrieb M∡rtin Koppenhoefer: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Wird vermutlich allerdings ne Weile dauern, wenn man den Planet damit durchackern will. Das ließe sich jedoch recht gut in osm2pgsql einbauen. Da mein letzter Patch für osm2pgsql [1] allerdings genau null Beachtung gefunden hat, zögere ich etwas, mich da mal drum zu kümmern.. Eine pauschale Lösung funktioniert auch nicht wirklich. - Es scheitert, wenn mehr als ein Value mit ; vorkommt, da dann nicht klar ist, ob und wie sich die verschiedenen Einzelteile aufeinander beziehen. - Es scheitert für schlichtweg sinnlose Kombinationen wie highway=track;residential. - Und es hat keinen sichtbaren Effekt, weil zwei Icons an derselben Stelle von Mapnik eh weggefiltert werden. Du bräuchtest also eine Steuerdatei mit den sinnvollen Einzelfällen und komplexe Regeln für den Umgang mit Mehrfach-Konkatenationen und noch eine Anpassung der Renderer für die Auflösung von gestapelten POIs. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5638043.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] api-download bei semikon-getrennten-values
Am 15. Oktober 2010 10:25 schrieb NopMap ekkeh...@gmx.de: Am 11.10.2010 10:54, schrieb M∡rtin Koppenhoefer: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Eine pauschale Lösung funktioniert auch nicht wirklich. - Es scheitert, wenn mehr als ein Value mit ; vorkommt, da dann nicht klar ist, ob und wie sich die verschiedenen Einzelteile aufeinander beziehen. doch, diese Anmerkung kam schon und es ist so, dass alle Tags jeweils für alle Values gelten müssen, weil sonst der doppelte Wert mit Semikolon nicht gesetzt werden kann (ist sonst ein Fehler in den Daten). Praktisch wird das allerdings sehr oft vorkommen, sieht man schon an den unmöglichen Kombinationen wie maxspeed=10;30 - Es scheitert für schlichtweg sinnlose Kombinationen wie highway=track;residential. ja, aber auch das sind klar Fehler, die man auch ohne diese Umsetzung nicht auswerten kann - Und es hat keinen sichtbaren Effekt, weil zwei Icons an derselben Stelle von Mapnik eh weggefiltert werden. es ist sowohl bei der Suche interessant, weil man dann jeweils fündig wird, als auch beim Rendern dann demjenigen überlassen, der den Stylesheet macht (Priorisierung bzw. Icon-Position optimieren) Du bräuchtest also eine Steuerdatei mit den sinnvollen Einzelfällen und komplexe Regeln für den Umgang mit Mehrfach-Konkatenationen und noch eine Anpassung der Renderer für die Auflösung von gestapelten POIs. für eine einfache Berücksichtigung sind die Renderer (mapnik) bereits vorbereitet: ist nichts anderes als dicht beieinanderliegende POIs: wer die Regeln macht entscheidet, was ihm wichtiger ist (oder er bekommt es hin, die Positionierung automatisch zu verbessern durch kl. offsets). 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
M∡rtin Koppenhoefer wrote: doch, diese Anmerkung kam schon und es ist so, dass alle Tags jeweils für alle Values gelten müssen, weil sonst der doppelte Wert mit Semikolon nicht gesetzt werden kann (ist sonst ein Fehler in den Daten). Praktisch wird das allerdings sehr oft vorkommen, sieht man schon an den unmöglichen Kombinationen wie maxspeed=10;30 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. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5638558.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] api-download bei semikon-getrennten-values
Hi Tom Müller, Wobeo diese Semikolons erstaunlicherweise in fast allen tags mal auftauchen. zb. auch im maxspeed-tag gelegentlich. was soll ein maxspeed 10;30 heißen? Soll wahrscheinlich gar nichts heissen, sondern ist meist aus der Zusammenfuegung mehrerer Wege entstanden. Oft zu finden in Kombination mit highway=unclassified;residential oder aehnlichem Zeugs. Um das wieder auseinanderzuklamuesern ist Ortskenntnis gefragt, oder eine Historie der beiden Wege. stw -- - Ich möchte einen Anschlag mit Biowaffen anmelden. - Gern. Bitte füllen Sie das Anthraxformular aus! [Hauke Reddmann in dtj] ___ 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 12.10.2010 12:05, schrieb Stefan Dettenhofer (StefanDausR): Wie kann man eigentlich Wege unterschiedlicher Klassen und/oder mit unterschiedlichen Namen zusammenfassen, ohne dass einem dabei größte Zweifel kommen müssten?? Das Frage ich mich ebenso wie man Wege mit unterschiedlichen maxspeeds zusammenfassen kann ... Mein parser spuckt mir die immoment aus, sodass ich die zumindest in Berlin bei Gelegenheit mal mit einem fixme versehen kann. Tom ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Steffen Wolf-2 wrote: Wobeo diese Semikolons erstaunlicherweise in fast allen tags mal auftauchen. zb. auch im maxspeed-tag gelegentlich. was soll ein maxspeed 10;30 heißen? Soll wahrscheinlich gar nichts heissen, sondern ist meist aus der Zusammenfuegung mehrerer Wege entstanden. Oft zu finden in Kombination mit highway=unclassified;residential oder aehnlichem Zeugs. Um das wieder auseinanderzuklamuesern ist Ortskenntnis gefragt, oder eine Historie der beiden Wege. Bedeutet wahrscheinlich, daß jemand zwei unterschiedliche Wege fälschlicherweise gejoined hat. Leider schlägt einem dann JOSM so eine unsinnige Konkatenation der Tagwerte als Default vor. Wenn der Anfänger jetzt auf Ok klickt, erhält man solche Ergebnisse. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5627549.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] api-download bei semikon-getrennten-values
Wolfgang wolfg...@ivkasogis.de [Mon, Oct 11, 2010 at 08:59:18AM CEST]: [...] Als diese Unsitte mir area=yes eingeführt wurde, verpassten wir die Gelegenheit, die Bodennutzung mit area zu definieren. area=residential, building=wohnhaus... . Der Zug ist abgefahren. Soll das heißen, dass die Renderer building=steeple wie buildung=no betrachten? -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, Life on the Mississippi) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 00:07, schrieb Guenther Meyer: Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Es ist immer einfach zu sagen das das technisch ginge, wenn man es nicht selber tun muß. Wieviele Renderer/Karten hast du selber schon geschrieben, die sowas generell (und nicht nur ein Paar Spezialfälle) auswerten können? Das sowas bislang kaum einer (keiner?) der Renderer auswertet deutet darauf hin, das es doch nicht ganz so trivial ist ... Gruß, ULFL ___ 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 Montag 11 Oktober 2010 00:07:38 schrieb Guenther Meyer: Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Ich hatte schon vor einiger Zeit mal angemerkt, daß die Sache mit dem Semikolon so eine Sache ist ;-) das liegt aber meist nicht am Semikolon selbst, sondern an den Anwendungen, die das nicht verstehen (wollen)... +1 Wenn du ein amenity=pub;cafe einträgst, ist die Wahrscheinlichkeit sehr hoch, das keiner der Renderer so ein Haupttag findet. Ich erwarte nicht, das sich das in Zukunft großartig ändern wird. Hier taggt jemand aber nur noch für bloed nur, dass sich sowas nicht anders darstellen laesst. [...] Es ist gut eine Regel zu haben, wie man mit mehreren Werten in einem Tag umgeht (sowas bei jedem Tag anders zu lösen macht ja keinen Sinn). +1 +1 Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Das ist auch ganz unabhaengig davon, um welches Tag oder welche Kombinationen es sich handelt. Es stellt sich nur die Frage, tut man's oder tut man's nicht. +1 Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Ein Tag kann halt mehrere Werte haben. Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als diese yes-Krankheiten, die Tag und Value im einem auszudrücken versuchen. cafe=yes restaurant=yes cusine_greek=yes cuisine:italian=yes (schauder) -/- amenity=cafe;restaurant cuisine=greek;italian Als diese Unsitte mir area=yes eingeführt wurde, verpassten wir die Gelegenheit, die Bodennutzung mit area zu definieren. area=residential, building=wohnhaus... . Der Zug ist abgefahren. Und wenn man bei xml/osm bleibt, kann man das im File auch noch lesen. Im Gegensatz zu diesem allenfalls für den zügigeren Download sinnvollen Binärformat, dass als Datenfile IMO einen Rückschritt in das Mittelalter des PC darstellt, als man für jede Datei eine spezielle SW brauchte, um den Inhalt zu verstehen. Eine Art Entmündigung der Mapper. (scnr) Gruß, Wolfgang ___ 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 Montag 11 Oktober 2010 08:34:10 schrieb Ulf Lamping: Am 11.10.2010 00:07, schrieb Guenther Meyer: Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Es ist immer einfach zu sagen das das technisch ginge, wenn man es nicht selber tun muß. Wieviele Renderer/Karten hast du selber schon geschrieben, die sowas generell (und nicht nur ein Paar Spezialfälle) auswerten können? Das sowas bislang kaum einer (keiner?) der Renderer auswertet deutet darauf hin, das es doch nicht ganz so trivial ist ... Mit den richtigen Werkzeugen ist das parsen trivial. Mit mehreren Eigenschaften umzugehen, ist unabhängig von der Einlesetechnik nicht trivial, weil man sich überlegen muss, wie man es darstellt. Das aber ist und muss dem Renderer freigestellt sein. Eben das ist ja der Vorteil bei OSM, dass erfasst wird, was vorliegt. Wer das wie auswertet, ist für die Erfassung _absolut_ egal. Ich habe selbst schon einiges erfasst, was nirgends gerendert wird, so what! Wenn ich es brauche sollte, schreibe ich halt irgend etwas, oder lasse es schreiben. Wir können doch nicht bei der Erfassung Rücksicht auf vermeintlich unzureichende Auswertesoftware nehmen! Wenn wir immer nur das erfasst hätten, was im Moment gerendert wird, würde die Karte bis heute nur aus einem Strickmuster von unklassifizierten Straßen und Wegen bestehen. Gruß, Wolfgang ___ 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 Sonntag 10 Oktober 2010 21:48:30 schrieb Jan Tappenbeck: ... nämlich das semikolon ist dem tag sein tod ! -1 Gruß, Wolfgang ___ 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 11.10.2010 08:59, schrieb Wolfgang: amenity=cafe;restaurant cuisine=greek;italian Ich denke mal, dass man als Programmierer einfach nicht entscheiden kann (oder will), was in so einem Fall gerendert (ausgewertet) werden soll: Soll das Symbol für Cafe oder für Restaurant dargestellt werden? Gibt es dort griechischen Kaffee und italienisches Essen oder italienischen Kaffee und griechisches Essen oder griechisch-italienisches Essen und auch Kaffee? Wenn ich soetwas auswerten wollte, würde ich bestenfalls das jeweils erste Element nehmen, also hier ein griechisches Cafe darstellen. Stell Dir mal vor, man will eine Liste mit griechischen Restaurants machen. Soll das dann aufgenommen werden oder nicht? Ich könnte mir bei cuisine alleine noch Mehrfachnennungen vorstellen, aber bei amenity gar nicht. Etwas Anderes ist es bei den opening_hours, dort ist klar definiert, wie das Semikolon zu interpretieren ist. Gruß, Stefan ___ 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, Stefan Dettenhofer (StefanDausR) wrote: Ich könnte mir bei cuisine alleine noch Mehrfachnennungen vorstellen, aber bei amenity gar nicht. Der Klassiker ist eine Bank mit Geldautomat: amenity=bank;atm Ich benutze das selber aber auch nicht, weil ich im Herzen eben doch Programmierer bin und weiss, dass einem das ueberall nur Stress macht (Wie soll osm2pgsql damit umgehen, wenn es nur eine amenity-Spalte befuellen kann? wie soll ein SQL-Query aussehen, der alle Banken aus einer semikolon-getrennten Spalte sucht - etwa mit amenity like '%;bank;%' or amenity like 'bank;%' or amenity like '%;bank' or amenity='bank'? wie soll ich im JOSM schnell alle Geldautomaten loeschen, ohne eine Bank mitzuloeschen? Wie sollen Statistikseiten wie taginfo das zaehlen? Gibt es einen Unterschied zwischen bank;atm und atm;bank? ...) Ich halte es da pragmatisch wie Ulf - wenn das Tag eins ist, das ohnehin kaum automatisch ausgewertet wird (oder bei dem ein automatischer Auswerter ohnehin erstmal gruendlich recherchieren muss), dann kann man sich ein Semikolon erlauben; wenn man aber bei sowas wie amenity ein Semikolon benutzt, dann nimmt man damit (egal ob im Recht oder nicht) in Kauf, dass das so getaggte Objekt auf Jahre hinaus in den meisten Karten unsichtbar bleibt. Bei sowas wie amenity=bank;atm ist die Sache klar, da setze ich zwei Nodes. Bei sowas wie amenity=cafe;restaurant ist es etwas bloeder, da entscheide ich mich in der Regel fuer eins. Bye Frederik ___ 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 Montag 11 Oktober 2010 09:42:43 schrieb Frederik Ramm: Hallo, Stefan Dettenhofer (StefanDausR) wrote: Ich könnte mir bei cuisine alleine noch Mehrfachnennungen vorstellen, aber bei amenity gar nicht. Das Beispiel cafe/restaurant ist zugegeben in vielen Fällen eine Werbeaussage. Trotzdem gibt es den Unterschied: Viele Restaurants haben Mittags und Abends auf, viele Cafés haben vom Vormittag bis späten Nachmittag geöffnet. In Restaurants liegt das Schwergewicht auf festen Mahlzeiten, während Cafés nahezu ausschließlich Kaffee, Kuchen und ggf. Eis anbieten. Wer beides hat, ist halt Café;Restaurant. Der Klassiker ist eine Bank mit Geldautomat: amenity=bank;atm Ich benutze das selber aber auch nicht, weil ich im Herzen eben doch Programmierer bin und weiss, dass einem das ueberall nur Stress macht (Wie soll osm2pgsql damit umgehen, wenn es nur eine amenity-Spalte befuellen kann? wie soll ein SQL-Query aussehen, der alle Banken aus einer semikolon-getrennten Spalte sucht - etwa mit amenity like '%;bank;%' or amenity like 'bank;%' or amenity like '%;bank' or amenity='bank'? Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. wie soll ich im JOSM schnell alle Geldautomaten loeschen, ohne eine Bank mitzuloeschen? Gar nicht. Bitte beim Löschen von Objekten jeden Einzelfall prüfen (scnr). Wie sollen Statistikseiten wie taginfo das zaehlen? Gibt es einen Unterschied zwischen bank;atm und atm;bank? ...) Das ist jetzt nicht dein Ernst? Ich halte es da pragmatisch wie Ulf - wenn das Tag eins ist, das ohnehin kaum automatisch ausgewertet wird (oder bei dem ein automatischer Auswerter ohnehin erstmal gruendlich recherchieren muss), dann kann man sich ein Semikolon erlauben; wenn man aber bei sowas wie amenity ein Semikolon benutzt, dann nimmt man damit (egal ob im Recht oder nicht) in Kauf, dass das so getaggte Objekt auf Jahre hinaus in den meisten Karten unsichtbar bleibt. Genau das ist mir egal. Ich tagge nicht für den Renderer. Wenn jemand das Semikolon auswertet, ist es der Software egal, für wieviel tags er das auswertet. Es bleibt dem Renderer ja freigestellt, im Falle von Mehrfacheigenschaften generell nur die erste zu rendern. Für andere Anwendungen kann es aber durchaus sinnvoll sein zu wissen, es gibt hier in einer Entfernung von weniger als 3 km nicht nur warmes Essen, sondern auch Kuchen. Die Öffnungszeiten werden auch nicht gerendert, aber trotzdem eingetragen. Es gibt auch andere Software als Renderer. Gerade Anwendungen wie der openstreetbrowser sind prinzipiell in der Lage, gezielt Mehrfacheigenschaften auszuwerten. Gruß, Wolfgang ___ 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, Wolfgang wrote: Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Darunter leidet halt auch die Effizienz. Das verstehe ich schon, dass die Programmierer dazu keine Lust haben. Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. Ich (als Programmierer) setze eher darauf, dass die Semikolons irgendwann wieder verschwinden. Ich fand die noch nie gut. Wenn jemand anders das in Mapnik und osm2pgsql und so einbauen will - ich werd's bestimmt nicht tun. Genau das ist mir egal. Ich tagge nicht für den Renderer. Wenn jemand das Semikolon auswertet, ist es der Software egal, für wieviel tags er das auswertet. Es bleibt dem Renderer ja freigestellt, im Falle von Mehrfacheigenschaften generell nur die erste zu rendern. Oder keine ;) Bye Frederik ___ 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 Montag, 11. Oktober 2010 08:59:18 schrieb Wolfgang: Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Da möchte ich jetzt doch mal widersprechen. Ich tagge sehr wohl für Renderer, Router und Auswertesoftware, und eher nicht für die Datenbank. Nicht für den Renderer taggen bedeutet für mich, dass ich keine verfälschten Daten eintrage, um damit ein bestimmtes Render-Ergebnis zu erreichen. Es ist auch klar, dass ich keine Daten entferne, bloß weil sie nicht gerendert werden. Und ich gestehe auch gerne zu, dass zum Zwecke einer besseren Datenerfassung hin und wieder Änderungen eingeführt werden, an die bestehende Auswertesoftware erst angepasst werden muss. Aber dass man die Möglichkeiten der bestehenden Auswertesoftware und gegebenenfalls nötigen Änderungsaufwand völlig ignoriert, kann ich nicht verstehen. Wie gesagt, _ich_ mappe nicht für die Datenbank. Gruß, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Ulf Lamping wrote: Am 11.10.2010 09:09, schrieb Wolfgang: Mit den richtigen Werkzeugen ist das parsen trivial. Mit mehreren Eigenschaften umzugehen, ist unabhängig von der Einlesetechnik nicht trivial, weil man sich überlegen muss, wie man es darstellt. Nein, wie Stephan an anderer Stelle am Beispiel gezeigt hat, geht der Aufwand schon damit los, daß man sich überhaupt erstmal überlegen muß, was denn der Mapper mit dieser Kombination gemeint haben könnte. Die Darstellung ist dann einer der weiteren nicht trivialen Schritte. Und das muß man dann für jedes Tag einzeln bewerten. +1 -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5622338.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] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 10:30 schrieb Frederik Ramm frede...@remote.org: Hallo, Wolfgang wrote: Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Darunter leidet halt auch die Effizienz. Das verstehe ich schon, dass die Programmierer dazu keine Lust haben. Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Wird vermutlich allerdings ne Weile dauern, wenn man den Planet damit durchackern will. Ein pragmatischer Ansatz wäre evtl. auch schonmal, die Reihenfolge vorzugeben (alphabetisch), mit der doppelte Werte eingetragen werden. Dann könnte man cafe;restaurant, atm;bank und was einem sonst noch so am Herzen liegt, mit endlichem Aufwand als einen Wert definieren. Skaliert natürlich nicht, aber könnte ein paar Spezialfälle abfangen, ohne dass man auch noch jeweils bank;atm und restaurant;cafe prüfen müsste. 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 11. Oktober 2010 08:59 schrieb Wolfgang wolfg...@ivkasogis.de: Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Ein Tag kann halt mehrere Werte haben. das kann er eben nicht so einfach, daher gibt's ja die Probleme. Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als diese yes-Krankheiten, die Tag und Value im einem auszudrücken versuchen. cafe=yes restaurant=yes cusine_greek=yes cuisine:italian=yes (schauder) warum schauderts Dich da? Das ist besser auszuwerten und wird daher in der Regel dargestellt. Was Du dagegen forderst vernichtet im Prinzip die Daten auf der Auswertungsseite. Früher konnte man ja mehrmals denselben Key auf demselben Objekt verwenden (zumindest erlaubten Editoren und DB das), was war da genau der Grund, dass man es abgeschafft hat? (Sorry für die Frage, bin weder Mathematiker noch Informatiker wie man sicher leicht erkennen kann). 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 Montag 11 Oktober 2010 10:30:57 schrieb Frederik Ramm: Hallo, Wolfgang wrote: Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. Ich (als Programmierer) setze eher darauf, dass die Semikolons irgendwann wieder verschwinden. Ich fand die noch nie gut. Wenn jemand anders das in Mapnik und osm2pgsql und so einbauen will - ich werd's bestimmt nicht tun. Vielleicht verschwindet das Semikolon und wird durch etwas anderes ersetzt. Ich glaube aber nicht, dass Mehrfacheigenschaften verschwinden werden. Es bleibt dem Renderer ja freigestellt, im Falle von Mehrfacheigenschaften generell nur die erste zu rendern. Oder keine ;) Ist auch OK. Dann rendert es halt ein anderer. Später. :) Ich kann es aber jetzt auswerten. Z.B. Summe der italienischen Restaurants in x-Stadt. Gruß, Wolfgang ___ 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 11.10.2010 10:15, schrieb Wolfgang: Hallo, Am Montag 11 Oktober 2010 09:42:43 schrieb Frederik Ramm: Der Klassiker ist eine Bank mit Geldautomat: amenity=bank;atm Ich benutze das selber aber auch nicht, weil ich im Herzen eben doch Programmierer bin und weiss, dass einem das ueberall nur Stress macht (Wie soll osm2pgsql damit umgehen, wenn es nur eine amenity-Spalte befuellen kann? wie soll ein SQL-Query aussehen, der alle Banken aus einer semikolon-getrennten Spalte sucht - etwa mit amenity like '%;bank;%' or amenity like 'bank;%' or amenity like '%;bank' or amenity='bank'? Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. Hier argumentiert Frederik mit konkreten Problemen auf die ein Entwickler stößt, wenn er es denn einbauen wollte. Du argumentierst hingegen mit: es hätte, muß es, ... Für andere Anwendungen kann es aber durchaus sinnvoll sein zu wissen, es gibt hier in einer Entfernung von weniger als 3 km nicht nur warmes Essen, sondern auch Kuchen. Es geht hier nicht darum, ob man sowas eintragen kann (oder sollte), sondern wie es sinnvoll gemacht wird. Gruß, ULFL ___ 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 11.10.2010 10:54, schrieb M∡rtin Koppenhoefer: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Das geht wahrscheinlich oft auch nicht so einfach, weil an dem Knoten noch andere Eigenschaften, zum Beispiel die Adresse, dranhängen können. Dann hättest du diese Information auch dupliziert, was du wahrscheinlich nicht willst. -fri- ___ 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 Montag 11 Oktober 2010 10:54:28 schrieb M∡rtin Koppenhoefer: Am 11. Oktober 2010 10:30 schrieb Frederik Ramm frede...@remote.org: Hallo, Wolfgang wrote: Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Darunter leidet halt auch die Effizienz. Das verstehe ich schon, dass die Programmierer dazu keine Lust haben. Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Wird vermutlich allerdings ne Weile dauern, wenn man den Planet damit durchackern will. 0/-1 In deinem speziellen Beispiel ginge das, aber für das Beispiel Amenity oder Cuisine geht es nicht, weil damit die Statistik in die Tonne getreten würde. Wer das für seine Auswertung so machen will, dem steht das frei. Ein pragmatischer Ansatz wäre evtl. auch schonmal, die Reihenfolge vorzugeben (alphabetisch), mit der doppelte Werte eingetragen werden. Dann könnte man cafe;restaurant, atm;bank und was einem sonst noch so am Herzen liegt, mit endlichem Aufwand als einen Wert definieren. Skaliert natürlich nicht, aber könnte ein paar Spezialfälle abfangen, ohne dass man auch noch jeweils bank;atm und restaurant;cafe prüfen müsste. Hier habe ich ein grundlegendes Verständnisproblem - ich finde das Problem einfach nicht. Wenn ich das Datenschema nicht anpasse, bekomme ich für den key amenity den Value cafe;restaurant. Jetzt mit einer klitzekleinen Programmzeile eben prüfen, ob ein Semikolon vorliegt, und im Falle, dass dieses zutrifft, einen Value-Array mit den einzelnen durch Semikolon(s) getrennten Werten erzeugen. Hier den ersten Wert dem Value wieder zuweisen und den übrigen Programmablauf so lassen, wie bisher. Damit wird ausschließlich der erste Wert benutzt. Nicht optimal, aber für den 08-15-Renderer eine brauchbare Möglichkeit. Geht viel schneller als die ganzen Diskussionen über das Semikolon in nicht nur diesem Thread. Die Idee mit der Sortierung ist auch nicht schlecht. Wenn ich den erzeugten Value-Array noch sortieren lasse, kann ich auf bestimmte Kombinationen abprüfen. Das geht allerdings auch ohne Sortierung. Wer den Programmablauf beschleunigen will, könnte für die Keys und Values in der DB eine zusätzliche Spalte für Integers einführen. Dann bekäme jeder Key und Value eindeutige int, die nur einmal erzeugt werden muss (und einmal für den Inhalt jedes Updates). Die Queries könnten dann integers zurückgeben, die viel schneller (automatisch) auszuwerten sind. Nur so als Idee. Zugegeben einmalig viel Aufwand. Beschleunigt aber erheblich mehr, als die Auswertung von ein paar Semikolons sonst kosten könnte. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 11:31, Friedhelm Schmidt wrote: Am 11.10.2010 10:54, schrieb M∡rtin Koppenhoefer: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Das geht wahrscheinlich oft auch nicht so einfach, weil an dem Knoten noch andere Eigenschaften, zum Beispiel die Adresse, dranhängen können. Dann hättest du diese Information auch dupliziert, was du wahrscheinlich nicht willst. Für die grafische Darstellung ist das egal - nur wird meist einer der Knoten dann immer noch rausfallen, weil zwei POIs auf dem gleichen Punkt zufällig oder aus anderen Gründen auf einen reduziert werden. Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Gelten die wirklich nur für die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Wolfgang-4 wrote: Und wenn man bei xml/osm bleibt, kann man das im File auch noch lesen. Im Gegensatz zu diesem allenfalls für den zügigeren Download sinnvollen Binärformat, dass als Datenfile IMO einen Rückschritt in das Mittelalter des PC darstellt, als man für jede Datei eine spezielle SW brauchte, um den Inhalt zu verstehen. Eine Art Entmündigung der Mapper. (scnr) hi wolfgang, ich fühle mich in keiner hinsicht entmündigt ;) a) das neue binärformat ist nicht bindend, du kannst auch einfach das alte nehmen. b) osmosis kann alles lesen und alles schreiben. omosis --read-pbf . --write-xml und dein altes osm-file ist da. 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/api-download-bei-semikon-getrennten-values-tp5620526p5622707.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] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 10:59:30 schrieb M∡rtin Koppenhoefer: Am 11. Oktober 2010 08:59 schrieb Wolfgang wolfg...@ivkasogis.de: Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Ein Tag kann halt mehrere Werte haben. das kann er eben nicht so einfach, daher gibt's ja die Probleme. Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als diese yes-Krankheiten, die Tag und Value im einem auszudrücken versuchen. cafe=yes restaurant=yes cusine_greek=yes cuisine:italian=yes (schauder) warum schauderts Dich da? Das ist besser auszuwerten und wird daher in der Regel dargestellt. Was Du dagegen forderst vernichtet im Prinzip die Daten auf der Auswertungsseite. Du übersiehst, dass der Programmierer hier ein im Grunde größeres Problem hat. Die Eigenschaften sind nach wie vor mehrfach vorhanden. An dieser grauenvollen Wirklichkeit führt auch dieses Schema nicht vorbei. Aber die Auswertung muss erkennen, dass cuisine_greek und italian sich auf die gleiche Eigenschaftsgruppe beziehen. Zusätzlich zum Vorhandensein der Mehrfacheigenschaft muss diese Mehrfacheigenschaft erkannt werden, sonst malt der Renderer das eine Icon über das andere. Oder er nimmt immer das zuerst gefundene. Damit wären wir auch nicht weiter. Eine Software, die ein Icon für eine relativ häufige Kombi wie diese hier darstellen könnte, hätte einen erheblichen Mehraufwand, weil sie die Kombi erst suchen müsste. Aber die Eigenschaftenliste wird in jedem Editor länger und auch hier muss die humane Schnittstelle die Mehrfacheigenschaft erst mühsam erkennen, während das Semikolon diese brutal vor das entsetzte Auge zerrt. Man muss sich immer überlegen, dass es sich letztlich um ein grundsätzliches Problem handelt. Wenn nur ein yes-Tag dabei ist, fällt das Problem nicht auf. Wenn aber alles so getaggt würde, weil es scheinbar einfacher ist, würde die Übersicht schnell sparsamer werden: automatic_entrance_door=yes bar=yes blinking_leuchtreklame=no cafe=yes cuisine_greek=yes cuisine_italian=yes decoration_greek=yes decoration_italian=yes english_money_accepted=no english_spoken=yes euro_accepted=yes fish_dishes=yes german_spoken=yes good_speed_of_service=yes greek_music_sound=yes greek_spoken=yes high_qality_of_food=no interior_color_read=yes italian_music_sound=yes italian_spoken=yes japanese_spoken=no kitchen_visible=yes kitchen_visible_by_window=yes leuchtreklame=yes leuchtreklame_color_blue=yes leuchtreklame_color_red=yes maestro_card_accepted=yes master_card_accepted=yes music_box=yes music_box_accepts_credit_cards=no music_box_accepts_coins=yes number_of_seats=100 oven_in_guest_room=no outside_color_blue=yes pizza_oven=yes prices_high=yes restaurant=yes tables=25 traveller_cheques_accepted=yes visa_card_accepted=yes weelchair_geeignet=yes Da habe ich natürlich maßlos übertrieben. Aber ein Problem zeigt sich immer am Extremfall, und so eine Liste möchte ich weder im josm noch im merkaartor editieren müssen. Mehrfacheigenschaften sind trotzdem drin. Wenn man das Schema noch etwas ausbaut, kann das yes/no weggelassen werden, und wir sind beim valuelosen tagging. Früher konnte man ja mehrmals denselben Key auf demselben Objekt verwenden (zumindest erlaubten Editoren und DB das), was war da genau der Grund, dass man es abgeschafft hat? (Sorry für die Frage, bin weder Mathematiker noch Informatiker wie man sicher leicht erkennen kann). Da würde ich auf die DB-Struktur zu dem Zeitpunkt tippen. Ist aber nur Spekulation. Gruß, Wolfgang ___ 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 Montag 11 Oktober 2010 12:45:36 schrieb Walter Nordmann: Wolfgang-4 wrote: Und wenn man bei xml/osm bleibt, kann man das im File auch noch lesen. Im Gegensatz zu diesem allenfalls für den zügigeren Download sinnvollen Binärformat, dass als Datenfile IMO einen Rückschritt in das Mittelalter des PC darstellt, als man für jede Datei eine spezielle SW brauchte, um den Inhalt zu verstehen. Eine Art Entmündigung der Mapper. (scnr) hi wolfgang, ich fühle mich in keiner hinsicht entmündigt ;) a) das neue binärformat ist nicht bindend, du kannst auch einfach das alte nehmen. b) osmosis kann alles lesen und alles schreiben. omosis --read-pbf . --write-xml und dein altes osm-file ist da. Stimmt, ich habe es auch etwas drastisch ausgedrückt. Im Grunde will ich nur darauf hinweisen, dass das Binärformat zwar Platz spart und damit eine gewisse Berechtigung hat (für ISDN-User z.B.), aber sonst das xml-Format nicht ersetzen sollte. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 13:01, Wolfgang wrote: Stimmt, ich habe es auch etwas drastisch ausgedrückt. Im Grunde will ich nur darauf hinweisen, dass das Binärformat zwar Platz spart und damit eine gewisse Berechtigung hat (für ISDN-User z.B.), aber sonst das xml-Format nicht ersetzen sollte. Ich denke, das hat niemand vor. Die Vorteile liegen aber absolut auf der Hand. Ohne das geprüft zu haben: - Ein Bottleneck an der API ist der Datentransfer - komprimierung spart hier. - Bottleneck in vielen Anwendungen ist die Festplatte - Komprimierung hilft. Komprimierte Daten sind selten gut, wenn es um kleine Ausschnitte geht: Zwei Häuserblocks runterladen, um in JOSM einen Briefkasten einzutragen ist unspannend im komprimierten Format. Aber es gibt ja andere Anwendungen, und insofern finde ich auch da ein offenes, wenn auch nicht unbedingt gut menschenlesbares Format eine gute Sache. Gruß Peter ___ 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 11.10.2010 12:33, schrieb Peter Wendorff: Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Natürlich gelten die Eigenschaften hier oft nicht für beide Teile, das fängt schon beim Namen an - der Geldautomat hat in der Regel gar keinen. Aber amenity=bank;atm ist sowieso ein schlechtes Beispiel. Denn das ist kein Objekt, das gleichzeitig ein Geldautomat und eine Bank ist. Das ist ein Geldautomat *in* einer Bank. Also sollte man m.E. einen node mit amenity=atm in der Fläche der Bank platzieren. Dann kann man auch noch zusätzliche Tags für den Geldautomaten und die Bank unabhängig vergeben. An sich könnte eine Software so eine liegt im Polygon-Geschichte sogar auswerten und auf die is in-Beziehung kommen. Praktischerweise funktionieren die üblichen Anwendungen aber auch ohne diesen Zusatzaufwand ganz gut. Tobias Knerr ___ 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 11. Oktober 2010 12:33 schrieb Peter Wendorff wendo...@uni-paderborn.de: Das geht wahrscheinlich oft auch nicht so einfach, weil an dem Knoten noch andere Eigenschaften, zum Beispiel die Adresse, dranhängen können. Dann hättest du diese Information auch dupliziert, was du wahrscheinlich nicht willst. Für die grafische Darstellung ist das egal - nur wird meist einer der Knoten dann immer noch rausfallen, weil zwei POIs auf dem gleichen Punkt zufällig oder aus anderen Gründen auf einen reduziert werden. +1 Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Gelten die wirklich nur für die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? das ist dann ein Problem (Fehler) in den Daten. Die anderen tags müssen für alles gelten, sonst ist ein doppelter Wert sowieso nicht möglich. 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 11. Oktober 2010 12:48 schrieb Wolfgang wolfg...@ivkasogis.de: Übersicht schnell sparsamer werden: automatic_entrance_door=yes bar=yes blinking_leuchtreklame=no cafe=yes cuisine_greek=yes cuisine_italian=yes decoration_greek=yes decoration_italian=yes english_money_accepted=no english_spoken=yes euro_accepted=yes fish_dishes=yes german_spoken=yes good_speed_of_service=yes greek_music_sound=yes greek_spoken=yes high_qality_of_food=no interior_color_read=yes italian_music_sound=yes italian_spoken=yes japanese_spoken=no kitchen_visible=yes kitchen_visible_by_window=yes leuchtreklame=yes leuchtreklame_color_blue=yes leuchtreklame_color_red=yes maestro_card_accepted=yes master_card_accepted=yes music_box=yes music_box_accepts_credit_cards=no music_box_accepts_coins=yes number_of_seats=100 oven_in_guest_room=no outside_color_blue=yes pizza_oven=yes prices_high=yes restaurant=yes tables=25 traveller_cheques_accepted=yes visa_card_accepted=yes weelchair_geeignet=yes Da habe ich natürlich maßlos übertrieben. +1 und die Hierarchien, die wir durch Doppelpunkte zur Strukturierung erzeugen, mal eben ignoriert. Diese Liste würde auch durch Mehrfachwerte kaum übersichtlicher: im Gegenteil (zugegebermaßen sowohl von den konkreten Editoren als auch von den persönlichen Präferenzen und auch von der Maus/Steuerung abhängig): Während lange (Mehrfach-)Werte in der meist schmalen (in Potlatch 1 definitiv zu schmalen) Valuespalte oft horizontales Scrollen erfordern, ist eine lange Liste in der Regel durch bessere Unterstützung von vertikalem Scrolling (Mausrad) einfacher handlebar. Wenn wir uns einem Punkt annähern, dass viele Objekte so lange Attributslisten haben, wird sich sicherlich auch auf Editorseite eine Lösung finden, diese gruppiert / strukturiert zu präsentieren. 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 11.10.2010 00:07, schrieb Guenther Meyer: bloed nur, dass sich sowas nicht anders darstellen laesst. http://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags :) Lg, Peter ___ 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 11.10.2010 17:10, schrieb Peter Körner: http://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags :) Oh, eine API V0.7 Wunschliste. Gut gefällt mir: No trolls We need to ruthlessly hunt down and exterminate trolls wherever they may be found. :-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 15:46, M∡rtin Koppenhoefer wrote: Am 11. Oktober 2010 12:33 schrieb Peter Wendorffwendo...@uni-paderborn.de: Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Gelten die wirklich nur für die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? das ist dann ein Problem (Fehler) in den Daten. Die anderen tags müssen für alles gelten, sonst ist ein doppelter Wert sowieso nicht möglich. An vielen Stellen wird es aber trotzdem so gemacht, weil verschiedene Entitäten eben nicht sauber getrennt werden. Das Beispiel von Bank und Geldautomat ist eins, Bei Tankstellen ist die Zahlungsmodalität während der Öffnungszeiten und am Automaten zu unterscheiden. Poststellen innerhalb von Geschäften sind mehrfach diskutiert worden - hier kann der operator unterschiedlich sein. Beispiel Tankstelle: Gleiche Zapfsäule(n), aber unterschiedliche Daten; mehrere Nodes machen? blöde Redundanz von Sprit-Sorten, operator, brand etc. Beispiel Post: operator gilt einmal für das Postunternehmen (Deutsche Post/Hermes/), aber auch für den Laden (Tante Emma/...) Ich merke immer wieder, dass Leute Nodes mergen, die unterschiedliche; auch widersprüchliche Attribute haben. Das wird hier erst recht der Fall sein. Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... Pizzerien sind nunmal lange nicht immer italienische Restaurants, italienische Restaurants haben aber tatsächlich nicht immer Pizza auf der Karte (Ausnahme z.B. Raffaello in Kassel - wobei das italienische Küche ohne Pizza mit ägyptischem Koch ist; lecker (und leider teuer) isses trotzdem). Ähnliches ließe sich in Deutschland mit Schnitzel und german finden, denke ich. Vielleicht ist dies wieder ein Beispiel für eine blöde Vermischung von Tags. Als ich wegen dem Raffaello grade meine Freundin fragte, meinte sie andererseits: Pizza ist für mich italienisch. wenn da Pizza und Türkisch steht, würde ich Lahmacun erwarten. Das ist sicherlich geprägt von der Anwenderseite - die Tags sind IMHO nicht so gemeint und zu interpretieren. Als Beispiel zeigt es aber, denke ich, dass mehrfache Werte durchaus sinnvoll sein könnten, ohne dass das ein Fehler in den Daten wäre (wenn man es nicht grundsätzlich verbietet). Gruß Peter ___ 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 11. Oktober 2010 17:58 schrieb Peter Wendorff wendo...@uni-paderborn.de: On 11.10.2010 15:46, M∡rtin Koppenhoefer wrote: die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? das ist dann ein Problem (Fehler) in den Daten. Die anderen tags müssen für alles gelten, sonst ist ein doppelter Wert sowieso nicht möglich. An vielen Stellen wird es aber trotzdem so gemacht, weil verschiedene Entitäten eben nicht sauber getrennt werden. ja, aber es bleibt falsch. Es gibt sehr viele Fehler in den Daten, manche sind offenkundig, andere eher versteckt oder im Detail. Poststellen innerhalb von Geschäften sind mehrfach diskutiert worden - hier kann der operator unterschiedlich sein. operator gilt einmal für das Postunternehmen (Deutsche Post/Hermes/), aber auch für den Laden (Tante Emma/...) wobei ich da (sorry kenne mich nicht 100% aus, weil kaum je damit in Berührung gekommen) doch der Ladenbetreiber im Auftrag der Post handelt, oder? Von daher wäre er doch der operator und die Post was für den brand-tag. Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... ja, wobei das auch so eine Sache ist. Italienische Küche gibt es vielleicht im Ausland, in Italien ist man da aber doch deutlich genauer (jede Region hat ihre eigene Küche, z.T. auch noch feingranularer --- in OSM allerdings bisher noch nicht so richtig durchdacht). Ich nutze meistens cuisine=local, weil es das noch am genauesten beschreibt. Pizzerien sind nunmal lange nicht immer italienische Restaurants, italienische Restaurants haben aber tatsächlich nicht immer Pizza auf der Karte ja klar Ähnliches ließe sich in Deutschland mit Schnitzel und german finden, denke ich. na komm, das Schnitzel lassen wir den Österreichern. ;-) 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
On 11.10.2010 19:06, M∡rtin Koppenhoefer wrote: Am 11. Oktober 2010 17:58 schrieb Peter Wendorffwendo...@uni-paderborn.de: Poststellen innerhalb von Geschäften sind mehrfach diskutiert worden - hier kann der operator unterschiedlich sein. operator gilt einmal für das Postunternehmen (Deutsche Post/Hermes/), aber auch für den Laden (Tante Emma/...) wobei ich da (sorry kenne mich nicht 100% aus, weil kaum je damit in Berührung gekommen) doch der Ladenbetreiber im Auftrag der Post handelt, oder? Von daher wäre er doch der operator und die Post was für den brand-tag. brand ist die Marke... Ich hab zwar kein praktisches Beispiel, wo diese Kombination tatsächlich vorkommt, aber auch ein Laden an sich kann ein brand haben. Bei Kleidungsgeschäften ist das häufig, bei Schreibwarenläden und Kiosken, die meist als Post-Annahmestellen handeln, kenne ich es tatsächlich nicht. Trotzdem finde ich diese Lösung aus dem Grund nicht gut. Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... ja, wobei das auch so eine Sache ist. Italienische Küche gibt es vielleicht im Ausland, in Italien ist man da aber doch deutlich genauer (jede Region hat ihre eigene Küche, z.T. auch noch feingranularer --- in OSM allerdings bisher noch nicht so richtig durchdacht). Ich nutze meistens cuisine=local, weil es das noch am genauesten beschreibt. ja? wie lokal ist das denn dann? gutbürgerlich Deutsch oder gutbürgerlich Bayrisch? oder die ganz besonderen Dorfspezialitäten? Ähnliches ließe sich in Deutschland mit Schnitzel und german finden, denke ich. na komm, das Schnitzel lassen wir den Österreichern. ;-) Als Wiener Schnitzel sicherlich, aber ob das Schweineschnitzel Wiener Art wirklich auf Österreich zu beschränken wäre, weiß ich nicht - nichtmal, ob die Österreicher (oder zumindest die Wiener) damit wirklich glücklich sind Gruß Peter ___ 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 11. Oktober 2010 20:53 schrieb Peter Wendorff wendo...@uni-paderborn.de: On 11.10.2010 19:06, M∡rtin Koppenhoefer wrote: Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... ja, wobei das auch so eine Sache ist. Italienische Küche gibt es vielleicht im Ausland, in Italien ist man da aber doch deutlich genauer (jede Region hat ihre eigene Küche, z.T. auch noch feingranularer --- in OSM allerdings bisher noch nicht so richtig durchdacht). Ich nutze meistens cuisine=local, weil es das noch am genauesten beschreibt. ja? wie lokal ist das denn dann? gutbürgerlich Deutsch oder gutbürgerlich Bayrisch? oder die ganz besonderen Dorfspezialitäten? es gibt ja auch noch regional, was für Dein Bayern-beispiel wohl am besten passt. Das ist übrigens weltweit auch der häufigste Wert überhaupt im cuisine-tag http://taginfo.openstreetmap.de/keys/cuisine wobei die deutsche Küche international auch einen guten Stand zu haben scheint (gleich nach burgern, italienisch und chinesisch) ;-) Sowas wie cuisine=german macht eigentlich sowieso keinen Sinn, wie Du selbst auch schon erkannt hast, es gibt nicht die deutsche Küche, sondern jeweils regionale Varianten davon. Wäre was für einen Subtag. 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
nochmal kurz zum Thema: cuisine=pizza;kebab 111x cuisine=kebab;pizza 158x eine Definition, dass die Reihenfolge durch den Mapper alphabetisch erfolgen sollte, würde hier schonmal für sowas wie cuisine=pizza;kebab 3x cuisine=kebab;pizza 266x sorgen ;-) 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
Ich bin jetzt kein Server Entwickler, aber soweit ich weiß wird das Ganze von fast allen Programmen als genau ein String-Wert interpretiert, egal wieviele Strichpunkte man hineinschreibt. Und von der API sowieso. Also ein klares Nein, und die Verwendung von solchen Strichpunkt-Konkatenationen ist ein guter Weg, das Objekt von allen Karten und aus allen Auswertungen zu entfernen. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5620982.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] api-download bei semikon-getrennten-values
mit ner eigenen datenbank ist das kein Problem. ich bin aber genauso wie Nop der Meinung, dass solche aufgebohrten tags nicht gerade nützlich sind. eventuell mach ich mal ne Müll-Karte, in der all die Objekte drin sind, die *nicht* vernünftigt dargestellt werden können - so etwa die bottom-1000 der tagwatch-liste. ;) 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/api-download-bei-semikon-getrennten-values-tp5620526p5621074.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] api-download bei semikon-getrennten-values
Am 10.10.2010 21:29, schrieb Walter Nordmann: mit ner eigenen datenbank ist das kein Problem. ich bin aber genauso wie Nop der Meinung, dass solche aufgebohrten tags nicht gerade nützlich sind. eventuell mach ich mal ne Müll-Karte, in der all die Objekte drin sind, die *nicht* vernünftigt dargestellt werden können - so etwa die bottom-1000 der tagwatch-liste. ;) gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg also wenn ich das richtig verstehe ist das ; in den tags - entgegen allen diskussionen der mehrfacheingeschaften eines elementes - genau das gegenteil von dem was es erreichen soll. ... nämlich das semikolon ist dem tag sein tod ! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Wobeo diese Semikolons erstaunlicherweise in fast allen tags mal auftauchen. zb. auch im maxspeed-tag gelegentlich. was soll ein maxspeed 10;30 heißen? ... nämlich das semikolon ist dem tag sein tod ! +1 tom ___ 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 10.10.2010 21:48, schrieb Jan Tappenbeck: Am 10.10.2010 21:29, schrieb Walter Nordmann: mit ner eigenen datenbank ist das kein Problem. ich bin aber genauso wie Nop der Meinung, dass solche aufgebohrten tags nicht gerade nützlich sind. eventuell mach ich mal ne Müll-Karte, in der all die Objekte drin sind, die *nicht* vernünftigt dargestellt werden können - so etwa die bottom-1000 der tagwatch-liste. ;) gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg also wenn ich das richtig verstehe ist das ; in den tags - entgegen allen diskussionen der mehrfacheingeschaften eines elementes - genau das gegenteil von dem was es erreichen soll. ... nämlich das semikolon ist dem tag sein tod ! Ich hatte schon vor einiger Zeit mal angemerkt, daß die Sache mit dem Semikolon so eine Sache ist ;-) Wenn du ein amenity=pub;cafe einträgst, ist die Wahrscheinlichkeit sehr hoch, das keiner der Renderer so ein Haupttag findet. Ich erwarte nicht, das sich das in Zukunft großartig ändern wird. Wenn du ein Zusatztag wie brand=Suzuki;Honda einträgst (das zusätzlich zu einem Haupttag verwendet wird), werden das viele Renderer vielleicht auch nicht auswerten können - ist aber hier erstmal kein so richtig großer Beinbruch. Ein Renderer sucht aber eh erstmal nach sowas wie shop=motorcycle, und weiß dann (bei Interesse), wie mit brand umzugehen ist. Kommt also auf den Tag-Einzelfall an. Es ist gut eine Regel zu haben, wie man mit mehreren Werten in einem Tag umgeht (sowas bei jedem Tag anders zu lösen macht ja keinen Sinn). Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Gruß, ULFL ___ 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 Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Ich hatte schon vor einiger Zeit mal angemerkt, daß die Sache mit dem Semikolon so eine Sache ist ;-) das liegt aber meist nicht am Semikolon selbst, sondern an den Anwendungen, die das nicht verstehen (wollen)... Wenn du ein amenity=pub;cafe einträgst, ist die Wahrscheinlichkeit sehr hoch, das keiner der Renderer so ein Haupttag findet. Ich erwarte nicht, das sich das in Zukunft großartig ändern wird. bloed nur, dass sich sowas nicht anders darstellen laesst. Wenn du ein Zusatztag wie brand=Suzuki;Honda einträgst (das zusätzlich zu einem Haupttag verwendet wird), werden das viele Renderer vielleicht auch nicht auswerten können - ist aber hier erstmal kein so richtig großer Beinbruch. Ein Renderer sucht aber eh erstmal nach sowas wie shop=motorcycle, und weiß dann (bei Interesse), wie mit brand umzugehen ist. Kommt also auf den Tag-Einzelfall an. Ob's jetzt in einem Haupttag vorkommt oder in einem Zusatztag ist relativ egal; je nach Anwendung kann beides leichter oder schwieriger auszuwerten sein... Es ist gut eine Regel zu haben, wie man mit mehreren Werten in einem Tag umgeht (sowas bei jedem Tag anders zu lösen macht ja keinen Sinn). +1 Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Das ist auch ganz unabhaengig davon, um welches Tag oder welche Kombinationen es sich handelt. Es stellt sich nur die Frage, tut man's oder tut man's nicht. 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
