Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hi! Guenther Meyer schrieb: - Und wie stellst Du dann drei Läden in einem Haus dar? siehe martin. Dann mußt Du Dich erst mal mit den Leuten auseinandersetzen, die Deine Listen lieber für diesen Fall (unterschiedlich Läden an einem Ort) einsetzen, und sie überzeugen Deine Interpretation zu verwenden. - Wie stellst Du es dar, wenn die Postfiliale andere Öffnungszeiten hat (durchaus üblich)? den vorschlag dazu gabs auch schon mal vor ein paar wochen. Soweit ich mich erinnern kann, paßte der aber nicht in Dein Konzept. Die Frage war schon mit Bedacht gestellt. Erklär das doch mal. das beispiel erscheint mir unsinnig. die tracktypes sind recht klar definiert. man sollte sich aufgrund der dokumentation durchaus fuer eins davon entscheiden koennen. Das Besipiel stammt von TagWatch und kommt dort öfters vor. :-) nur weil listen fuer viele dinge eine einfache und praktische loesung darstellen, heisst das nicht, das sie fuer jedes tag sinnvoll sind! Siehst Du, genau das ist das Problem. Dur redest nicht von einer halbwegs allgemeinen Lösung, sondern von Einzelfallregelungen, die dann für jedes Tag, jeden Use Case und jede Tagkombination anders aussehen können. Das ist weder eine allgemein anwendbare Lösung noch technisch mit vernünftigem Aufwand umzusetzen. Ein Programm, daß auf einen ; stößt weiß ohne ausimplementierten Spezialfallkatalog nicht, was es damit anfangen soll. Das verstehe ich unter nicht so einfach. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
On Tue, Nov 03, 2009 at 12:49:39AM +0100, Tobias Knerr wrote: wenn das ganze dagegen folgendermassen getaggt ist: amenity = recycling recycling:batteries = yes recycling:glass = yes recycling:paper = yes recycling:cars = no ist das wesentlich aufwendiger zu verarbeiten, Für welche Zwecke? Bei den Beispielen, die mir so einfallen, kann ich da keinen Zusatzaufwand erkennen. Einfacher Fall: Ich will wissen, ob ein Objekt eine Recyclingstelle für (unter anderem) Glas ist. Pseudocode yes/no: wenn objekt.wertVon(amenity) ist recycling und objekt.wertVon(recycling:glass) ist yes dann ... Pseudocode Semikolon: wenn objekt.wertVon(amenity) ist recycling und objekt.wertVon(recycling).trenneAn([whitespace]*;) .enthält(glass) dann ... Sieht ähnlich aus. Wenn überhaupt ist die Notwendigkeit der Trennung des Wertes noch ein zusätzlicher Aufwand. Leider funktioniert das in der Realität nicht wirklich, weil die meisten amenity = recycling ohne Zusatztags daherkommen. Das heisst, damit deine Verarbeitung einigermassen robust ist, möchtest du zusätzlich alle amenities = recycling finden, die ohne Material-Infos getaggt sind. Mit Simikolon-Notation ist das programmtechnisch ganz einfach zu lösen, mit yes/no-Notation wird das ganze extrem aufwändig, weil du immer alle Tags des Objektes scannen musst. Oder versuche mal, mit Hilfe von osm2pqsql/Mapnik, eine Karte zu erzeugen, die tagesaktuell Recycling-Stellen mit den entsprechenden Untertypen anzeigt. Dort muss beim Import in die Postgresql für jeden recycling:..-Tag eine eigene Spalte in der DB-Tabelle angelegt werden. Das heisst, jedes Mal, wenn du eine neue Art von Recycling- Material anzeigen willst, musst du die Datenbank komplett neu importieren Das dauert je nach Rechenpower zwischen 2 Tagen und einer Woche. In der Semikolon-Notation müsste man lediglich eine neue Rendering- Regel einfügen. Es ist einfach müssig, Tagging-Schemen aufgrund irgendwelcher Software- Anforderungen auszuwählen. Dafür gibt es viel zu viele Anwendungs- möglichkeiten der OSM-Daten, die alle anders funktionieren. Die Software muss sich da einfach an das existierende anpassen. Es wäre vermutlich recht einfach, osm2psql so umzuprogrammieren, dass es mit recyling:...-Tags zurechtkommt, aber genauso hat der OSM-Composer nicht die geringsten Probleme damit, das osmc:symbol-Tag zu verstehen, dass mit Doppelpunkt-getrennten Werten daherkommt. Gruss Sarah ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am 3. November 2009 09:14 schrieb Nop ekkeh...@gmx.de: das beispiel erscheint mir unsinnig. die tracktypes sind recht klar definiert. man sollte sich aufgrund der dokumentation durchaus fuer eins davon entscheiden koennen. Das Besipiel stammt von TagWatch und kommt dort öfters vor. :-) Das sind wahrscheinlich Überreste von einem automatischen Zusammenwerfen von Tags, wenn Wege verschmolzen werden. Merkaartor macht(e) das z.B. so, Potlatch vielleicht auch. Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am 3. November 2009 07:56 schrieb Guenther Meyer d@sordidmusic.com: - und wohin ist eigentlich das Beispiel mit tracktype verschwunden? Da hätte mich Deine Antwort schon interessiert. das beispiel erscheint mir unsinnig. die tracktypes sind recht klar definiert. man sollte sich aufgrund der dokumentation durchaus fuer eins davon entscheiden koennen. nur weil listen fuer viele dinge eine einfache und praktische loesung darstellen, heisst das nicht, das sie fuer jedes tag sinnvoll sind! +1 wenn ich eine Anwendung programmieren würde, und dort diesen Fall abfangen wollte, würde ich den schlechteren Tracktype wählen und den anderen verwerfen... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am 3. November 2009 08:27 schrieb Guenther Meyer d@sordidmusic.com: wenn das ganze dagegen folgendermassen getaggt ist: amenity = recycling recycling:batteries = yes recycling:glass = yes recycling:paper = yes recycling:cars = no ok, nehmen wir diese beispiel, erst mal den einfachsten fall (das amenity=recycling lass ich mal weg, das ist ja immer gleich): meine methode: recycling = glass 1. key recycling suchen 2. (value aufsplitten, falls liste) 2. wenn gefunden, falls value glass enthaelt - ende. deine methode: recycling:glass = yes 1. key mit anfang recycling suchen 2. wenn gefunden, key am doppelpunkt trennen 3. zweite haelfte des keys auf glass pruefen, falls nein - weiter bei 1. 4. enthaelt wert yes - ende. 5. sonst weiter bei 1. bis gefunden oder ende der tags wobei es natürlich auch immer sein könnte: recycling:glass=rundcontainer recycling:glass=braunglas recycling:glass=float_glass recycling:glass=Annahmestelle etc. muss ja nicht immer nur yes sein ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am 3. November 2009 12:57 schrieb Colin Marquardt cmarq...@googlemail.com: Am 3. November 2009 09:14 schrieb Nop ekkeh...@gmx.de: das beispiel erscheint mir unsinnig. die tracktypes sind recht klar definiert. man sollte sich aufgrund der dokumentation durchaus fuer eins davon entscheiden koennen. Das Besipiel stammt von TagWatch und kommt dort öfters vor. :-) Das sind wahrscheinlich Überreste von einem automatischen Zusammenwerfen von Tags, wenn Wege verschmolzen werden. Merkaartor macht(e) das z.B. so, Potlatch vielleicht auch. JOSM macht es auch so. Wenn man nicht aufpasst, baut man da schnell Unfug. Besser wäre eine Warnung, dass die beiden Tags inkompatibel sind, nur im selteneren Fall macht das wirklich Sinn, z.B: auch Namen zusammenwerfen ist Quatsch. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Dienstag 03 November 2009 09:14:11 schrieb Nop: Hi! Guenther Meyer schrieb: - Und wie stellst Du dann drei Läden in einem Haus dar? siehe martin. Dann mußt Du Dich erst mal mit den Leuten auseinandersetzen, die Deine Listen lieber für diesen Fall (unterschiedlich Läden an einem Ort) einsetzen, und sie überzeugen Deine Interpretation zu verwenden. wuerde ich gerne. doch das ist ein kampf gegen windmuehlen, wenn man keine fuer osm wichtige anwendung wie einen editor oder renderer hat... - Wie stellst Du es dar, wenn die Postfiliale andere Öffnungszeiten hat (durchaus üblich)? den vorschlag dazu gabs auch schon mal vor ein paar wochen. Soweit ich mich erinnern kann, paßte der aber nicht in Dein Konzept. Die Frage war schon mit Bedacht gestellt. Erklär das doch mal. es ging um die oeffnungszeiten des postschalters im gegebenen laden? opening_hours = [ladenoeffnungszeiten] opening_hours:Post_office = [oeffnungszeiten des postschalters] das beispiel erscheint mir unsinnig. die tracktypes sind recht klar definiert. man sollte sich aufgrund der dokumentation durchaus fuer eins davon entscheiden koennen. Das Besipiel stammt von TagWatch und kommt dort öfters vor. :-) ich find's trotzdem unsinnig, denn was soll es bedeuten? irgendwas zwischen 2 und 3? je nach witterung mal so mal so? vormittags an feiertagen 2, ansonsten 3? ein track laesst sich recht gut mit einem wert beschreiben, wenns unter bestimmten bedingungen anders ist, muss man das auch eindeutig beschreiben. nur weil listen fuer viele dinge eine einfache und praktische loesung darstellen, heisst das nicht, das sie fuer jedes tag sinnvoll sind! Siehst Du, genau das ist das Problem. Dur redest nicht von einer halbwegs allgemeinen Lösung, sondern von Einzelfallregelungen, die dann für jedes Tag, jeden Use Case und jede Tagkombination anders aussehen können. nein, ich rede durchaus von einer generellen loesung fuer listen, die fuer alle tags, wo listen sinnvoll sind, benutzt werden kann. Das ist weder eine allgemein anwendbare Lösung noch technisch mit vernünftigem Aufwand umzusetzen. Ein Programm, daß auf einen ; stößt weiß ohne ausimplementierten Spezialfallkatalog nicht, was es damit anfangen soll. Das verstehe ich unter nicht so einfach. man muss einfach das ; als trennzeichen fuer listen definieren. es wird ja auch in so ziemlich allen faellen, die ich bisher gesehen habe, so genutzt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Guenther Meyer schrieb: Wenn es einfach (mehrere) mehrwertige Tags gibt, dann sollte die Abbildung auch durch ein Objekt mit entsprechenden Tags geschehen. Wie man mehrwertige Tags nun umsetzt, ist davon unberührt - neben dem Verfahren mit Semikolon gibt es ja auch noch die Alternative, wie beim Recycling mehrere Keys zu verwenden: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drecycling das ist sicher auch eine moeglichkeit. nur finde ich, dass hier dieses yes/no-schema einfach inflationaer missbraucht wird. Begründung? Es ist eindeutig, verständlich und funktionieren tut es auch. Sehe jetzt grade kein Problem damit? wie waers mit: recycling = batteries;glass;paper;... nichts spricht dagegen. Ein wenig was schon. Beispielsweise: * Tag-basierte Auswahl (etwa an XAPI: alle Glas-Recyclingstellen bitte) funktioniert nicht * Werkzeuge wie Tagwatch liefern keine wirklich sinnvollen Ergebnisse Generell: Dumme Software, die eigentlich keine Ahnung von der Bedeutung und Struktur der Tags haben, sondern Schlüssel und Wert jeweils als atomare Einheit betrachten soll, benötigt dann genau diese Information. Das ist also kein Problem lediglich der aktuellen Anwendungen, sondern eine konzeptionelle Frage. Das wäre jetzt nicht derart wichtig, die Idee ist auch noch bei weitem besser als eine Nodehaufen-Lösung, aber mangels echter Vorteile gegenüber yes/no sehe ich momentan nicht so ganz, warum man nicht einfach das nehmen sollte. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Montag 02 November 2009 08:33:32 schrieb Nop: Hi! Guenther Meyer schrieb: Listen wurden noch nie irgendwo ausgewertet - und das hat seinen Grund. nur weil es nicht ausgewertet wird soll es nicht benutzt werden?!? unsinn. es gibt nunmal listen in osm, das ist fakt! Nein. Weil es nicht funktioniert, wird es von keinem Programm ausgewertet und sollte auch nicht benutzt werden. aha. dann eruebrigt sich ja jegliche weitere diskussion mit dir... ich weiss nicht, warum's andere programme nicht machen; zumindest bei gpsdrive ist es so, dass noch keiner die zeit dazu hatte, bzw. die prioritaeten im moment woanders liegen. geplant ist es aber... Und sobald es an der Reihe ist und Du es versuchst, wirst Du verstehen: - daß es nur für bestimmte Tags klar und einfach ist was gemeint ist - nur solange genau ein Tag eine Liste enthält, bei mehr als einem ist nicht klar was das bedeuten soll - daß verschiedene Leute das ; mit verschiedenen Bedeutungen einsetzen und Du es deshalb nichts Sinnvolles rauskommt. ich hab das ganze durchaus mal durchgespielt, und denke schon, dass man da zu einem brauchbaren ergebnis kommen kann. nur weil du dir das nicht vorstellen kannst, muss das nicht so sein. Hast Du eigentlich jemals in Tagwatch nachgesehen, wie solche Listen überall verwendet werden bevor Du Die Behauptung aufstellst, das sei alles ganz einfach? ja, hab ich. aber da du ja weisst, dass das alles unsinn ist, brauche ich es gar nicht mehr zu versuchen... Wenn jemand anders einen Node sauber und funktionstüchtig eingetragen hat und Du kommst, machst eine Liste aus einigen Tags und sorgst dafür, daß der Node von keinem Tool und keinem Renderer mehr erkannt wird, so würde ich das durchaus auch als kaputtmachen bezeichen. informationen hinzufuegen und dafuer eine bereits bestehende und oft genutzte methode benutzen nennst du kaputtmachen. ja ne, is klar... Ja. Objekte, die einwandrei verarbeitet werden in einen Zustand zu bringen, in dem sie nicht mehr verarbeitet werden können, nenne ich kaputtmachen. Dabei ist es egal, wieviele andere kaputte Objekte es schon gibt. relationen sind schoen und gut - fuer manche dinge. bei anderen bringen sie nur unnoetige komplexitaet rein. es ist EIN laden, also reicht ein node. einfacher geht's nicht. Nein, reicht nicht, weil der logische Zusammenhang zwischen mehreren Tags verloren geht. was geht denn verloren?!? amenity=bakery;postoffice;flowershop opening_hours=Mo-Fr 8:00-19:00;Sa 9:00-16:00 Ist das jetzt: - ein Gebäude mit drei Läden? - ein Laden mit drei Angeboten? - zu wem gehören die Öffnungszeiten? - warum kommt Schmarrn raus, wenn ich das ; bei opening_hours genauso verarbeite wie das ; bei amenity? so wie's da steht? ein laden wo man blumen und brot kaufen kann, und auch postgeschaefte erledigen kann. und dazu die oeffnungszeiten dieses ladens. wo ist das problem? ja, die gibt es. zumindest ich bevorzuge die einfachste loesung, die mich zum ziel bringt. und das ist in diesem fall nicht die relation. Ich bevorzuge die Lösung, die nicht nur im allereinfachsten Fall für ein paar ausgesuchte Tags funktioniert. :-) ich ebenso. nur sieht meine wohl anders aus als deine... Wenn es einen Konsens dazu gibt, dann den von allen Tools und allen Renderern, daß das keine gute Idee ist und nicht ausgewertet wird. Möglcherweise wissen die Entwickler ja, warum sie sich in dem Punkt ausnahmsweise alle einig sind. :-) im osm gibt es einige dinge die nicht ueberall implementiert sind. zumindest was dieses thema angeht, koennte ich mich nicht dran erinnern, dass das diese schreibweise irgendwann mal von einem entwickler negativ bewertet wurde. Nicht von einem Entwickler. Von *ALLEN* Entwicklern. Aber vermutlich sind die wohl alle nur zu dumm dazu... :-) danke, dass du mich als dumm hinstellst. damit waere dann wohl alles gesagt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Montag 02 November 2009 22:12:27 schrieb Tobias Knerr: Guenther Meyer schrieb: Wenn es einfach (mehrere) mehrwertige Tags gibt, dann sollte die Abbildung auch durch ein Objekt mit entsprechenden Tags geschehen. Wie man mehrwertige Tags nun umsetzt, ist davon unberührt - neben dem Verfahren mit Semikolon gibt es ja auch noch die Alternative, wie beim Recycling mehrere Keys zu verwenden: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drecycling das ist sicher auch eine moeglichkeit. nur finde ich, dass hier dieses yes/no-schema einfach inflationaer missbraucht wird. Begründung? Es ist eindeutig, verständlich und funktionieren tut es auch. Sehe jetzt grade kein Problem damit? ich finde, es ist schlechter Stil, quasi allles auf die Keyseite zu schieben. Aber ja, eindeutig ist es. wie waers mit: recycling = batteries;glass;paper;... nichts spricht dagegen. Ein wenig was schon. Beispielsweise: * Tag-basierte Auswahl (etwa an XAPI: alle Glas-Recyclingstellen bitte) funktioniert nicht * Werkzeuge wie Tagwatch liefern keine wirklich sinnvollen Ergebnisse werkzeuge und software koennen und werden angepasst werden. oder glaubst du wirklich, die ganzen tools sind in den letzten jahren nicht weiterentwickelt worden? Generell: Dumme Software, die eigentlich keine Ahnung von der Bedeutung und Struktur der Tags haben, sondern Schlüssel und Wert jeweils als atomare Einheit betrachten soll, benötigt dann genau diese Information. Das ist also kein Problem lediglich der aktuellen Anwendungen, sondern eine konzeptionelle Frage. es kommt immer auf die anwendung an. fuer manche reicht eine dumme software, fuer manche brauchts etwas mehr. das ist jetzt aber auch schon so... Das wäre jetzt nicht derart wichtig, die Idee ist auch noch bei weitem besser als eine Nodehaufen-Lösung, aber mangels echter Vorteile gegenüber yes/no sehe ich momentan nicht so ganz, warum man nicht einfach das nehmen sollte. ich sehe es als vereinfachung. man fasst zusammen, was zusammen gehoert. ein beispiel: amenity = recycling recycling = batteries;glass;paper ich lese das haupttag amenity, und habe meine grobe einordnung. ich lese das zweite tag, und habe alles, was ich an klassifizierung brauche. das reicht z.B. um ein icon zu zeichnen, oder eine Suchfunktion zu bedienen. Weitere Tags brauch ich mir gar nicht anschauen. wenn das ganze dagegen folgendermassen getaggt ist: amenity = recycling recycling:batteries = yes recycling:glass = yes recycling:paper = yes recycling:cars = no ist das wesentlich aufwendiger zu verarbeiten, ausserdem ist es kein guter Stil, alle moeglichen Werte grundsaetzlich auf die Schluesselseite zu verlegen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Mo November 2 2009 glaubte Guenther Meyer zu wissen: Am Montag 02 November 2009 08:33:32 schrieb Nop: amenity=bakery;postoffice;flowershop opening_hours=Mo-Fr 8:00-19:00;Sa 9:00-16:00 Ist das jetzt: - ein Gebäude mit drei Läden? - ein Laden mit drei Angeboten? - zu wem gehören die Öffnungszeiten? - warum kommt Schmarrn raus, wenn ich das ; bei opening_hours genauso verarbeite wie das ; bei amenity? so wie's da steht? ein laden wo man blumen und brot kaufen kann, und auch postgeschaefte erledigen kann. und dazu die oeffnungszeiten dieses ladens. wo ist das problem? Und was macht man dann, wenn es im Stockwerk darüber ein Bastelgeschäft ist und darüber noch eine Pizzeria? flo -- Aeh Du hast Erfahrung, Diesbezueglich? Du nicht? Doch, aber ich dachte es muss ja nicht jeder so Bloed sein! [Bernd Brodesser und Herbert Steinboeck in suse-talk] ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am 3. November 2009 00:11 schrieb Florian Gross flor...@grossing.de: Und was macht man dann, wenn es im Stockwerk darüber ein Bastelgeschäft ist und darüber noch eine Pizzeria? in diesem Fall definitiv verschiedene Nodes, da ja auch die Layer-Tags unterschiedlich sind (so wie alle anderen Tags auch). Falls sich Deine Frage auf die Adresstags bezieht: sauber wäre wohl eine Relationslösung, wo man diese gemeinsamen Tags als Haus zusammenfasst und nur der Relation mitgibt, gehackt könnte man wohl auch jedem der Nodes (oder Polygone) die kompletten Adressdaten mitgeben, zur Unterscheidung ggf. mit einem Tag für das Stockwerk. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hi! Guenther Meyer schrieb: ich hab das ganze durchaus mal durchgespielt, und denke schon, dass man da zu einem brauchbaren ergebnis kommen kann. nur weil du dir das nicht vorstellen kannst, muss das nicht so sein. Dann stell Deine konsistente Lösung doch mal vor, das ist sicherlich von allgemeinem Interesse. Bisher haben wir nichts Konkretes von Dir gehört. amenity=bakery;postoffice;flowershop opening_hours=Mo-Fr 8:00-19:00;Sa 9:00-16:00 Ist das jetzt: - ein Gebäude mit drei Läden? - ein Laden mit drei Angeboten? - zu wem gehören die Öffnungszeiten? - warum kommt Schmarrn raus, wenn ich das ; bei opening_hours genauso verarbeite wie das ; bei amenity? so wie's da steht? ein laden wo man blumen und brot kaufen kann, und auch postgeschaefte erledigen kann. und dazu die oeffnungszeiten dieses ladens. wo ist das problem? - Und wie stellst Du dann drei Läden in einem Haus dar? - Wie stellst Du es dar, wenn die Postfiliale andere Öffnungszeiten hat (durchaus üblich)? - wie willst Du unterscheiden zwischen einem ; das eine Liste trennt wie beim ersten Tag und einem ; das keine Liste darstellt wie bei den Öffnungszeiten? - und wohin ist eigentlich das Beispiel mit tracktype verschwunden? Da hätte mich Deine Antwort schon interessiert. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Guenther Meyer schrieb: werkzeuge und software koennen und werden angepasst werden. Deshalb schreibe ich ja: Das ist also kein Problem lediglich der aktuellen Anwendungen, sondern eine konzeptionelle Frage. Denn diese pauschale Aussage hier fuer manche reicht eine dumme software, fuer manche brauchts etwas mehr. das ist jetzt aber auch schon so... ist zwar nicht falsch - der entscheidende Punkt ist aber: Um mehrwertige Attribute handhaben zu können, bräuchte man für manche Aufgaben, wo jetzt noch dumme Software reicht, intelligente Software. Software also, die zwischen Freitextattributen, mehrwertigen Attributen und eventuellen Sonderfällen (opening_hours?) unterscheidet und dafür auf eine - nicht existierende - verbindliche Tag-Definitionsbasis angewiesen ist. ich sehe es als vereinfachung. man fasst zusammen, was zusammen gehoert. ein beispiel: amenity = recycling recycling = batteries;glass;paper ich lese das haupttag amenity, und habe meine grobe einordnung. ich lese das zweite tag, und habe alles, was ich an klassifizierung brauche. das reicht z.B. um ein icon zu zeichnen, oder eine Suchfunktion zu bedienen. Weitere Tags brauch ich mir gar nicht anschauen. Inwiefern bedeutet das Ansehen der Werte von 3 Tags, die bereits hübsch getrennt vorliegen, eine Erleichterung gegenüber dem Ansehen von 3 Wert-Teilen eines Tags, dessen Wert hierzu erst noch zerlegt werden muss? wenn das ganze dagegen folgendermassen getaggt ist: amenity = recycling recycling:batteries = yes recycling:glass = yes recycling:paper = yes recycling:cars = no ist das wesentlich aufwendiger zu verarbeiten, Für welche Zwecke? Bei den Beispielen, die mir so einfallen, kann ich da keinen Zusatzaufwand erkennen. Einfacher Fall: Ich will wissen, ob ein Objekt eine Recyclingstelle für (unter anderem) Glas ist. Pseudocode yes/no: wenn objekt.wertVon(amenity) ist recycling und objekt.wertVon(recycling:glass) ist yes dann ... Pseudocode Semikolon: wenn objekt.wertVon(amenity) ist recycling und objekt.wertVon(recycling).trenneAn([whitespace]*;) .enthält(glass) dann ... Sieht ähnlich aus. Wenn überhaupt ist die Notwendigkeit der Trennung des Wertes noch ein zusätzlicher Aufwand. ausserdem ist es kein guter Stil, alle moeglichen Werte grundsaetzlich auf die Schluesselseite zu verlegen. Liest sich für mich ein wenig so, als würdest du als gegeben voraussetzen, dass es sich hierbei um einen Wert handelt. Wenn man diese Ansicht nicht teilt, dann liegt aber auch keine Verlegung auf die Schlüsselseite vor . Diese etwas längere Mail hier soll jetzt nicht so wirken, als wäre ich entschieden gegen mehrwertige Attribute mit Semikolon. Ich sehe nur immer noch nicht wirklich einen Vorteil. Vielleicht hast du ja noch ein konkretes Beispiel, das mir hilft, deinen Standpunkt besser zu verstehen? Das mit dem Stil ist halt so eine eher subjektive Sache... Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Dienstag 03 November 2009 00:24:24 schrieb Martin Koppenhoefer: Am 3. November 2009 00:11 schrieb Florian Gross flor...@grossing.de: Und was macht man dann, wenn es im Stockwerk darüber ein Bastelgeschäft ist und darüber noch eine Pizzeria? in diesem Fall definitiv verschiedene Nodes, da ja auch die Layer-Tags unterschiedlich sind (so wie alle anderen Tags auch). Falls sich Deine Frage auf die Adresstags bezieht: sauber wäre wohl eine Relationslösung, wo man diese gemeinsamen Tags als Haus zusammenfasst und nur der Relation mitgibt, gehackt könnte man wohl auch jedem der Nodes (oder Polygone) die kompletten Adressdaten mitgeben, zur Unterscheidung ggf. mit einem Tag für das Stockwerk. +1 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Dienstag 03 November 2009 00:37:22 schrieb Nop: Hi! eigentlich wollte ich dir gar nicht mehr antworten, aber mir gehts nunmal umk die sache... Guenther Meyer schrieb: ich hab das ganze durchaus mal durchgespielt, und denke schon, dass man da zu einem brauchbaren ergebnis kommen kann. nur weil du dir das nicht vorstellen kannst, muss das nicht so sein. Dann stell Deine konsistente Lösung doch mal vor, das ist sicherlich von allgemeinem Interesse. Bisher haben wir nichts Konkretes von Dir gehört. mal abgesehen davon, dass ich staendig konkrete vorschlaege mache; am besten geht das an einem beispiel: gib mir also ein reell vorkommendes oder zumindest realistisches szenario, meinetwegen auch etwas komplexer, als vollstaendige beschreibung in worten, dann liefer ich dir einen tagging-vorschlag. amenity=bakery;postoffice;flowershop opening_hours=Mo-Fr 8:00-19:00;Sa 9:00-16:00 Ist das jetzt: - ein Gebäude mit drei Läden? - ein Laden mit drei Angeboten? - zu wem gehören die Öffnungszeiten? - warum kommt Schmarrn raus, wenn ich das ; bei opening_hours genauso verarbeite wie das ; bei amenity? so wie's da steht? ein laden wo man blumen und brot kaufen kann, und auch postgeschaefte erledigen kann. und dazu die oeffnungszeiten dieses ladens. wo ist das problem? - Und wie stellst Du dann drei Läden in einem Haus dar? siehe martin. - Wie stellst Du es dar, wenn die Postfiliale andere Öffnungszeiten hat (durchaus üblich)? den vorschlag dazu gabs auch schon mal vor ein paar wochen. - wie willst Du unterscheiden zwischen einem ; das eine Liste trennt wie beim ersten Tag und einem ; das keine Liste darstellt wie bei den Öffnungszeiten? beides ist eine liste mit jeweils gleichwertigen elementen - und wohin ist eigentlich das Beispiel mit tracktype verschwunden? Da hätte mich Deine Antwort schon interessiert. das beispiel erscheint mir unsinnig. die tracktypes sind recht klar definiert. man sollte sich aufgrund der dokumentation durchaus fuer eins davon entscheiden koennen. nur weil listen fuer viele dinge eine einfache und praktische loesung darstellen, heisst das nicht, das sie fuer jedes tag sinnvoll sind! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Dienstag 03 November 2009 00:49:39 schrieb Tobias Knerr: Guenther Meyer schrieb: werkzeuge und software koennen und werden angepasst werden. Deshalb schreibe ich ja: Das ist also kein Problem lediglich der aktuellen Anwendungen, sondern eine konzeptionelle Frage. Denn diese pauschale Aussage hier fuer manche reicht eine dumme software, fuer manche brauchts etwas mehr. das ist jetzt aber auch schon so... ist zwar nicht falsch - der entscheidende Punkt ist aber: Um mehrwertige Attribute handhaben zu können, bräuchte man für manche Aufgaben, wo jetzt noch dumme Software reicht, intelligente Software. Software also, die zwischen Freitextattributen, mehrwertigen Attributen und eventuellen Sonderfällen (opening_hours?) unterscheidet wenn man die daten in osm einigermassen komplett nutzen und auswerten will, braucht man das sowieso. osm ist nunmal ein wust an verschiedenen herangehensweisen. so eine spielwiese ist anfangs schoen und gut, doch irgendwann wird jeder verstehen, dass man mit eindeutigen tags letztendlich schneller und einfacher zum ziel kommt. und das nicht nur als entwickler, sondern auch als mapper - grade als einsteiger. und dafür auf eine - nicht existierende - verbindliche Tag-Definitionsbasis angewiesen ist. um software effektiv schreiben zu koennen, braucht es nunmal saubere und eindeutige definitionen. ich bin nicht der einzige hier, der nach sowas schreit. ich sehe es als vereinfachung. man fasst zusammen, was zusammen gehoert. ein beispiel: amenity = recycling recycling = batteries;glass;paper ich lese das haupttag amenity, und habe meine grobe einordnung. ich lese das zweite tag, und habe alles, was ich an klassifizierung brauche. das reicht z.B. um ein icon zu zeichnen, oder eine Suchfunktion zu bedienen. Weitere Tags brauch ich mir gar nicht anschauen. Inwiefern bedeutet das Ansehen der Werte von 3 Tags, die bereits hübsch getrennt vorliegen, eine Erleichterung gegenüber dem Ansehen von 3 Wert-Teilen eines Tags, dessen Wert hierzu erst noch zerlegt werden muss? EINE zeichenfolge einzulesen und an einem trennzeichen aufzutrennen ist weit weniger aufwaendig, als eine unbekannte zahl von mehreren tags sowohl auf key-, als auch auf value-seite auszuwerten. wenn das ganze dagegen folgendermassen getaggt ist: amenity = recycling recycling:batteries = yes recycling:glass = yes recycling:paper = yes recycling:cars = no ist das wesentlich aufwendiger zu verarbeiten, Für welche Zwecke? in meinem konkreten fall geht es in erster linie darum, pois zu finden und darzustellen. Bei den Beispielen, die mir so einfallen, kann ich da keinen Zusatzaufwand erkennen. Einfacher Fall: Ich will wissen, ob ein Objekt eine Recyclingstelle für (unter anderem) Glas ist. ok, nehmen wir diese beispiel, erst mal den einfachsten fall (das amenity=recycling lass ich mal weg, das ist ja immer gleich): meine methode: recycling = glass 1. key recycling suchen 2. (value aufsplitten, falls liste) 2. wenn gefunden, falls value glass enthaelt - ende. deine methode: recycling:glass = yes 1. key mit anfang recycling suchen 2. wenn gefunden, key am doppelpunkt trennen 3. zweite haelfte des keys auf glass pruefen, falls nein - weiter bei 1. 4. enthaelt wert yes - ende. 5. sonst weiter bei 1. bis gefunden oder ende der tags bei pois mit mehreren werten, bleibe ich innerhalb meines value-arrays, waehrend du mehrere key/value-paare parsen musst. auf mapper-seite ist es auch einfacher, weil man wesentlich weniger tippen muss. Pseudocode yes/no: wenn objekt.wertVon(amenity) ist recycling und objekt.wertVon(recycling:glass) ist yes dann ... Pseudocode Semikolon: wenn objekt.wertVon(amenity) ist recycling und objekt.wertVon(recycling).trenneAn([whitespace]*;) .enthält(glass) dann ... Sieht ähnlich aus. Wenn überhaupt ist die Notwendigkeit der Trennung des Wertes noch ein zusätzlicher Aufwand. bei nur einem wert gibt sich das nicht viel. wenn's mehrere werden machts einen unterschied. ausserdem ist es kein guter Stil, alle moeglichen Werte grundsaetzlich auf die Schluesselseite zu verlegen. Liest sich für mich ein wenig so, als würdest du als gegeben voraussetzen, dass es sich hierbei um einen Wert handelt. Wenn man diese Ansicht nicht teilt, dann liegt aber auch keine Verlegung auf die Schlüsselseite vor . das ist die osm-definiton: key=value das einzige, worauf man sich wirklich verlassen kann hier... ;-) Diese etwas längere Mail hier soll jetzt nicht so wirken, als wäre ich entschieden gegen mehrwertige Attribute mit Semikolon. Ich sehe nur immer noch nicht wirklich einen Vorteil. Vielleicht hast du ja noch ein konkretes Beispiel, das mir hilft, deinen Standpunkt besser zu verstehen? Das mit dem Stil ist halt so eine eher subjektive Sache... siehe oben. klar, worauf ich hinaus will?
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Freitag 30 Oktober 2009 09:14:05 schrieb Nop: Hi! Guenther Meyer schrieb: Am Donnerstag 29 Oktober 2009 23:50:21 schrieb Karl Eichwalder: Guenther Meyer d@sordidmusic.com writes: dann muessen das die anwendungen eben lernen. Es ist nicht ganz trivial, wenn auf einmal listen in bestimmten feldern auftauchen. Wenn man so etwas nicht vorab festlegt, sollte man als mapper nicht die alten daten kaputtmachen, sondern zumindest fuer eine uebergangszeit ein passendes tag verwenden, z.b.: wer macht denn was kaputt? listen gabs in osm schon fast immer. ich kann mich auch nicht daran erinnern, dass jemand mal festgelegt hat, dass es pro key nur einen wert geben darf... Listen wurden noch nie irgendwo ausgewertet - und das hat seinen Grund. nur weil es nicht ausgewertet wird soll es nicht benutzt werden?!? unsinn. es gibt nunmal listen in osm, das ist fakt! ich weiss nicht, warum's andere programme nicht machen; zumindest bei gpsdrive ist es so, dass noch keiner die zeit dazu hatte, bzw. die prioritaeten im moment woanders liegen. geplant ist es aber... Wenn jemand anders einen Node sauber und funktionstüchtig eingetragen hat und Du kommst, machst eine Liste aus einigen Tags und sorgst dafür, daß der Node von keinem Tool und keinem Renderer mehr erkannt wird, so würde ich das durchaus auch als kaputtmachen bezeichen. informationen hinzufuegen und dafuer eine bereits bestehende und oft genutzte methode benutzen nennst du kaputtmachen. ja ne, is klar... relationen sind schoen und gut - fuer manche dinge. bei anderen bringen sie nur unnoetige komplexitaet rein. es ist EIN laden, also reicht ein node. einfacher geht's nicht. Nein, reicht nicht, weil der logische Zusammenhang zwischen mehreren Tags verloren geht. was geht denn verloren?!? Das ist ein leidiges Problem, zu dem es mehrere unterschiedliche Lösungsansätze gibt, z.B. auch den Array-ähnliche Tagstrukturen einzuführen. ja, die gibt es. zumindest ich bevorzuge die einfachste loesung, die mich zum ziel bringt. und das ist in diesem fall nicht die relation. Aber mehrere eindeutige Nodes zu setzen erscheint mir als die vielversprechendste. Dann sind die Daten eindeutig und schlimmstenfalls muß man beim Rendern Objekte zusammenfassen. technisch sehe ich da ueberhaupt keine probleme... Seelig sind... bitte programmier erst mal selber was, bevor du hier mit dummen spruechen kommst! einen string an einem trennzeichen aufsplitten ist sowas von trivial, die resultierenden daten weiterzuverarbeiten ebenso... Vielleicht solltest Du nicht beleidigend werden - vor allem weil er recht hat. :-) ich beleidigend? wer hat denn mit de bloed daherreden angefangen? ausserdem, wenn er recht haben sollte, dann wil ich argumente hoeren und kein seelig sind.. Den String selber aufzsplitten, ist kein Thema. Aber damit ist die Sache noch lange nicht erledigt. - Du mußt jedes Objekt duplizieren, für jeden Eintrag in Deiner Liste einen. Das ist viel komplizierter als einfach eine Folge von Objekten zu was ist daran kompliziert? verarbeiten, was heute alle Tools tun. tun sie das wirklich? - Wenn die Kopien die gleiche ID behalten, funktioierne die meisten Mechanismen in Tools nicht mehr, da sich OSM auf eindeutige IDs geeinigt hat. Wenn sie eine unterschiedlcihe ID bekommen, funktionieren Referenzen nicht mehr - Es ist nicht klar, ob sich andere Tags dann auf alle Einträge in der Liste beziehen oder nur auf einen ja und? wenn ich eine anwendung schreibe, dann ist das absolut meine sache, wie ich das angehe, und wie ich bestimmte probleme loese. bis jetzt scheint das konzept recht gut aufzugehen. Soweit mal die Spitze des Eisbergs. Wenn Du's tatsächlich probierst, dürftest Du noch auf einige interessante Detailproblem stoßen. jeder loesungsweg hat so seine probleme, es gibt keinen, der fuer alles perfekt waere. es haengt halt immer von der gewuenschten anwendung ab. vor allem ist das semikolon als trenner schon lange in osm vorhanden, es gibt sogar einen gewissen konsens dazu. das es bisher nicht so oft benutzt wurde, mag vielleicht auch daran liegen, dass es vor api 0.6 nicht so die notwendigkeit gab. Wenn es einen Konsens dazu gibt, dann den von allen Tools und allen Renderern, daß das keine gute Idee ist und nicht ausgewertet wird. Möglcherweise wissen die Entwickler ja, warum sie sich in dem Punkt ausnahmsweise alle einig sind. :-) im osm gibt es einige dinge die nicht ueberall implementiert sind. zumindest was dieses thema angeht, koennte ich mich nicht dran erinnern, dass das diese schreibweise irgendwann mal von einem entwickler negativ bewertet wurde. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Freitag 30 Oktober 2009 17:16:19 schrieb Tobias Wendorff: Josias Polchau schrieb: das funktioniert bei Restaurants aber nicht die art der küche wird über den cuisine tag festgelegt. wie willst du dann einen china-mann der sowohl chinesisch als auch taiwanesisch kocht taggen? meist macht er es in der selben Küche. Funktionieren tut das schon, aber dann hat man halt zwei gleiche POIs, die sich nur im cuisine-tag unterschieden. Aber ich denke nicht, dass das eine korrekte Vorgehensweise wäre ;-) ganz genau. der lieferservice/schnellimbiss hier um die ecke bietet indisches, italienisches und asiatisches essen an. heisst das, ich soll da sechs nodes hinsetzen, je drei fuer den lieferdienst und je drei fuer zum dort essen? achja, selbst mitnehmen kann man das essen auch, also nochmal drei nodes mehr? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Guenther Meyer schrieb: der lieferservice/schnellimbiss hier um die ecke bietet indisches, italienisches und asiatisches essen an. heisst das, ich soll da sechs nodes hinsetzen, je drei fuer den lieferdienst und je drei fuer zum dort essen? achja, selbst mitnehmen kann man das essen auch, also nochmal drei nodes mehr? Genau. 9 Nodes. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Johann H. Addicks schrieb: der lieferservice/schnellimbiss hier um die ecke bietet indisches, italienisches und asiatisches essen an. heisst das, ich soll da sechs nodes hinsetzen, je drei fuer den lieferdienst und je drei fuer zum dort essen? achja, selbst mitnehmen kann man das essen auch, also nochmal drei nodes mehr? Genau. 9 Nodes. Also ein passendes Beispiel, warum diese Lösung an sich Overkill ist. Mehrere Objekte (Nodes/Ways/Relations) mögen eine gangbare Alternative sein, wenn man Beziehungen zwischen Tags braucht - im Beispiel meinetwegen dann, wenn die Firma einen italienischen Lieferservice anbieten, vor Ort aber nur indisches Essen verkaufen würde. In allen anderen Fällen produziert eine Lösung mit mehreren Objekten nur Probleme: Man verlässt sich auf eine nicht triviale, nicht dokumentierte und in der Praxis nicht vorhandene Vorverarbeitung durch Anwendungen. Man verlässt das für den Mapper intuitivere Konzept, dass ein POI eben auch einem realen Geschäft (etc.) entspricht. Und man macht es ziemlich schwierig, das Konstrukt mit Presets und anderen GUI-Tools zu bearbeiten - für die Zukunftsfähigkeit des Datenmodells ist das aber unerlässlich, und ein auf Tags statt auf mehreren OSM-Objekten basiertes Modell bietet diese Möglichkeit ohne Weiteres. Wenn es einfach (mehrere) mehrwertige Tags gibt, dann sollte die Abbildung auch durch ein Objekt mit entsprechenden Tags geschehen. Wie man mehrwertige Tags nun umsetzt, ist davon unberührt - neben dem Verfahren mit Semikolon gibt es ja auch noch die Alternative, wie beim Recycling mehrere Keys zu verwenden: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drecycling Ein Verfahren mit mehreren Keys - und letztlich Tags - produziert keine technischen Probleme und ist allemal besser als mehrere OSM-Objekte. So etwas wie eine Paketstelle als Zusatzservice im Laden kann man ja gerne als einzelnen Node darstellen (gerade, wenn man der Interpretation folgt, dass sich eine Paketstelle im Laden befindet), aber doch nicht Eigenschaften wie cuisine oder vending. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Montag 02 November 2009 00:12:36 schrieb Tobias Knerr: Also ein passendes Beispiel, warum diese Lösung an sich Overkill ist. Mehrere Objekte (Nodes/Ways/Relations) mögen eine gangbare Alternative sein, wenn man Beziehungen zwischen Tags braucht - im Beispiel meinetwegen dann, wenn die Firma einen italienischen Lieferservice anbieten, vor Ort aber nur indisches Essen verkaufen würde. selbst das koennte man relativ einfach auf einem node abbilden... der grosse vorteil ist halt, ich habe genau ein objekt, das ich betrachten muss, wo alle informationen drin sind. In allen anderen Fällen produziert eine Lösung mit mehreren Objekten nur Probleme: Man verlässt sich auf eine nicht triviale, nicht dokumentierte und in der Praxis nicht vorhandene Vorverarbeitung durch Anwendungen. Man verlässt das für den Mapper intuitivere Konzept, dass ein POI eben auch einem realen Geschäft (etc.) entspricht. Und man macht es ziemlich schwierig, das Konstrukt mit Presets und anderen GUI-Tools zu bearbeiten - für die Zukunftsfähigkeit des Datenmodells ist das aber unerlässlich, und ein auf Tags statt auf mehreren OSM-Objekten basiertes Modell bietet diese Möglichkeit ohne Weiteres. +1 Wenn es einfach (mehrere) mehrwertige Tags gibt, dann sollte die Abbildung auch durch ein Objekt mit entsprechenden Tags geschehen. Wie man mehrwertige Tags nun umsetzt, ist davon unberührt - neben dem Verfahren mit Semikolon gibt es ja auch noch die Alternative, wie beim Recycling mehrere Keys zu verwenden: http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drecycling das ist sicher auch eine moeglichkeit. nur finde ich, dass hier dieses yes/no-schema einfach inflationaer missbraucht wird. wie waers mit: recycling = batteries;glass;paper;... nichts spricht dagegen. prinzipiell halte ich eine vereinheitlichung fuer nichts schlechtes. das macht es fuer alle seiten einfacher... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hi! Guenther Meyer schrieb: Listen wurden noch nie irgendwo ausgewertet - und das hat seinen Grund. nur weil es nicht ausgewertet wird soll es nicht benutzt werden?!? unsinn. es gibt nunmal listen in osm, das ist fakt! Nein. Weil es nicht funktioniert, wird es von keinem Programm ausgewertet und sollte auch nicht benutzt werden. ich weiss nicht, warum's andere programme nicht machen; zumindest bei gpsdrive ist es so, dass noch keiner die zeit dazu hatte, bzw. die prioritaeten im moment woanders liegen. geplant ist es aber... Und sobald es an der Reihe ist und Du es versuchst, wirst Du verstehen: - daß es nur für bestimmte Tags klar und einfach ist was gemeint ist - nur solange genau ein Tag eine Liste enthält, bei mehr als einem ist nicht klar was das bedeuten soll - daß verschiedene Leute das ; mit verschiedenen Bedeutungen einsetzen und Du es deshalb nichts Sinnvolles rauskommt. Hast Du eigentlich jemals in Tagwatch nachgesehen, wie solche Listen überall verwendet werden bevor Du Die Behauptung aufstellst, das sei alles ganz einfach? Wenn jemand anders einen Node sauber und funktionstüchtig eingetragen hat und Du kommst, machst eine Liste aus einigen Tags und sorgst dafür, daß der Node von keinem Tool und keinem Renderer mehr erkannt wird, so würde ich das durchaus auch als kaputtmachen bezeichen. informationen hinzufuegen und dafuer eine bereits bestehende und oft genutzte methode benutzen nennst du kaputtmachen. ja ne, is klar... Ja. Objekte, die einwandrei verarbeitet werden in einen Zustand zu bringen, in dem sie nicht mehr verarbeitet werden können, nenne ich kaputtmachen. Dabei ist es egal, wieviele andere kaputte Objekte es schon gibt. relationen sind schoen und gut - fuer manche dinge. bei anderen bringen sie nur unnoetige komplexitaet rein. es ist EIN laden, also reicht ein node. einfacher geht's nicht. Nein, reicht nicht, weil der logische Zusammenhang zwischen mehreren Tags verloren geht. was geht denn verloren?!? amenity=bakery;postoffice;flowershop opening_hours=Mo-Fr 8:00-19:00;Sa 9:00-16:00 Ist das jetzt: - ein Gebäude mit drei Läden? - ein Laden mit drei Angeboten? - zu wem gehören die Öffnungszeiten? - warum kommt Schmarrn raus, wenn ich das ; bei opening_hours genauso verarbeite wie das ; bei amenity? Oder was ist das: tracktype=grade4; grade3? Das ist ein leidiges Problem, zu dem es mehrere unterschiedliche Lösungsansätze gibt, z.B. auch den Array-ähnliche Tagstrukturen einzuführen. ja, die gibt es. zumindest ich bevorzuge die einfachste loesung, die mich zum ziel bringt. und das ist in diesem fall nicht die relation. Ich bevorzuge die Lösung, die nicht nur im allereinfachsten Fall für ein paar ausgesuchte Tags funktioniert. :-) Wenn es einen Konsens dazu gibt, dann den von allen Tools und allen Renderern, daß das keine gute Idee ist und nicht ausgewertet wird. Möglcherweise wissen die Entwickler ja, warum sie sich in dem Punkt ausnahmsweise alle einig sind. :-) im osm gibt es einige dinge die nicht ueberall implementiert sind. zumindest was dieses thema angeht, koennte ich mich nicht dran erinnern, dass das diese schreibweise irgendwann mal von einem entwickler negativ bewertet wurde. Nicht von einem Entwickler. Von *ALLEN* Entwicklern. Aber vermutlich sind die wohl alle nur zu dumm dazu... :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hallo. Am Freitag, 30. Oktober 2009 schrieb Martin Koppenhoefer: wobei shop:fish=seafish oder shop:wine=local oder shop:wine=barrels oder shop:wine=french vielleicht schon weniger bloedsinnig ist. Und dann shop:wine=local;italian für ein Geschäft das beides hat? ;-)) Gruß, Bernd -- Wo alle das selbe denken, wird nicht viel gedacht. - Karl Valentin signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am Donnerstag 29 Oktober 2009 23:50:21 schrieb Karl Eichwalder: Guenther Meyer d@sordidmusic.com writes: dann muessen das die anwendungen eben lernen. Es ist nicht ganz trivial, wenn auf einmal listen in bestimmten feldern auftauchen. Wenn man so etwas nicht vorab festlegt, sollte man als mapper nicht die alten daten kaputtmachen, sondern zumindest fuer eine uebergangszeit ein passendes tag verwenden, z.b.: wer macht denn was kaputt? listen gabs in osm schon fast immer. ich kann mich auch nicht daran erinnern, dass jemand mal festgelegt hat, dass es pro key nur einen wert geben darf... ausserdem, wenn du was neues fuer eine uebergangszeit einfuehren wirst, wird das nicht funktionieren. denn entweder wird das tag ignoriert, oder es wird von einer kritischen masse benutzt, die anwendungen werde angepasst, und du kriegst es nie wieder raus. das wars dann mit uebergangszeit... lieber gleicht richtig machen und gut is. ausserdem, wie willst sowas sonst mappen? zwei pois fuer einen laden?!? Genau so. Warum denn nicht? Falls notwendig, tust du dann beide wieder in eine relation, wie man das beispielsweise mit strassenschnipseln auch machen sollte. relationen sind schoen und gut - fuer manche dinge. bei anderen bringen sie nur unnoetige komplexitaet rein. es ist EIN laden, also reicht ein node. einfacher geht's nicht. technisch sehe ich da ueberhaupt keine probleme... Seelig sind... bitte programmier erst mal selber was, bevor du hier mit dummen spruechen kommst! einen string an einem trennzeichen aufsplitten ist sowas von trivial, die resultierenden daten weiterzuverarbeiten ebenso... vor allem ist das semikolon als trenner schon lange in osm vorhanden, es gibt sogar einen gewissen konsens dazu. das es bisher nicht so oft benutzt wurde, mag vielleicht auch daran liegen, dass es vor api 0.6 nicht so die notwendigkeit gab. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Hi! Guenther Meyer schrieb: Am Donnerstag 29 Oktober 2009 23:50:21 schrieb Karl Eichwalder: Guenther Meyer d@sordidmusic.com writes: dann muessen das die anwendungen eben lernen. Es ist nicht ganz trivial, wenn auf einmal listen in bestimmten feldern auftauchen. Wenn man so etwas nicht vorab festlegt, sollte man als mapper nicht die alten daten kaputtmachen, sondern zumindest fuer eine uebergangszeit ein passendes tag verwenden, z.b.: wer macht denn was kaputt? listen gabs in osm schon fast immer. ich kann mich auch nicht daran erinnern, dass jemand mal festgelegt hat, dass es pro key nur einen wert geben darf... Listen wurden noch nie irgendwo ausgewertet - und das hat seinen Grund. Wenn jemand anders einen Node sauber und funktionstüchtig eingetragen hat und Du kommst, machst eine Liste aus einigen Tags und sorgst dafür, daß der Node von keinem Tool und keinem Renderer mehr erkannt wird, so würde ich das durchaus auch als kaputtmachen bezeichen. relationen sind schoen und gut - fuer manche dinge. bei anderen bringen sie nur unnoetige komplexitaet rein. es ist EIN laden, also reicht ein node. einfacher geht's nicht. Nein, reicht nicht, weil der logische Zusammenhang zwischen mehreren Tags verloren geht. Das ist ein leidiges Problem, zu dem es mehrere unterschiedliche Lösungsansätze gibt, z.B. auch den Array-ähnliche Tagstrukturen einzuführen. Aber mehrere eindeutige Nodes zu setzen erscheint mir als die vielversprechendste. Dann sind die Daten eindeutig und schlimmstenfalls muß man beim Rendern Objekte zusammenfassen. technisch sehe ich da ueberhaupt keine probleme... Seelig sind... bitte programmier erst mal selber was, bevor du hier mit dummen spruechen kommst! einen string an einem trennzeichen aufsplitten ist sowas von trivial, die resultierenden daten weiterzuverarbeiten ebenso... Vielleicht solltest Du nicht beleidigend werden - vor allem weil er recht hat. :-) Den String selber aufzsplitten, ist kein Thema. Aber damit ist die Sache noch lange nicht erledigt. - Du mußt jedes Objekt duplizieren, für jeden Eintrag in Deiner Liste einen. Das ist viel komplizierter als einfach eine Folge von Objekten zu verarbeiten, was heute alle Tools tun. - Wenn die Kopien die gleiche ID behalten, funktioierne die meisten Mechanismen in Tools nicht mehr, da sich OSM auf eindeutige IDs geeinigt hat. Wenn sie eine unterschiedlcihe ID bekommen, funktionieren Referenzen nicht mehr - Es ist nicht klar, ob sich andere Tags dann auf alle Einträge in der Liste beziehen oder nur auf einen - Wenn mehrere Listen an einem Objekt auftauchen, ist nicht klar ob das dann alternative Werte sein sollen oder eigenständige Listen, die ausmultipliziert werden müssen. Es gibt keine Festlegung über Längenunterschied oder Reihenfolgen - wenn das Objekt von einem Way oder einer Relation referenziert wird, ist nicht klar ob das für alle Kopien gilt oder ob nur bestimmte gemeint sind bzw. es ist nicht möglich, einzelne Listeneinträge einzeln zu referenzieren. Soweit mal die Spitze des Eisbergs. Wenn Du's tatsächlich probierst, dürftest Du noch auf einige interessante Detailproblem stoßen. vor allem ist das semikolon als trenner schon lange in osm vorhanden, es gibt sogar einen gewissen konsens dazu. das es bisher nicht so oft benutzt wurde, mag vielleicht auch daran liegen, dass es vor api 0.6 nicht so die notwendigkeit gab. Wenn es einen Konsens dazu gibt, dann den von allen Tools und allen Renderern, daß das keine gute Idee ist und nicht ausgewertet wird. Möglcherweise wissen die Entwickler ja, warum sie sich in dem Punkt ausnahmsweise alle einig sind. :-) bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Mirko Küster schrieb: Weil es keine einzige Anwendung auswertet und dieser Node komplett tot in der DB gammelt. na danke... zb Osmolt in der kommenden Verison kann das... hab mir solche mühe gegeben ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Karl Eichwalder schrieb: Guenther Meyer d@sordidmusic.com writes: dann muessen das die anwendungen eben lernen. Es ist nicht ganz trivial, wenn auf einmal listen in bestimmten feldern auftauchen. Wenn man so etwas nicht vorab festlegt, sollte man als mapper nicht die alten daten kaputtmachen, sondern zumindest fuer eine uebergangszeit ein passendes tag verwenden, z.b.: shop_list=bicycle;xxx etc. ausserdem, wie willst sowas sonst mappen? zwei pois fuer einen laden?!? Genau so. Warum denn nicht? Falls notwendig, tust du dann beide wieder in eine relation, wie man das beispielsweise mit strassenschnipseln auch machen sollte. das funktioniert bei Restaurants aber nicht die art der küche wird über den cuisine tag festgelegt. wie willst du dann einen china-mann der sowohl chinesisch als auch taiwanesisch kocht taggen? meist macht er es in der selben Küche. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Josias Polchau schrieb: das funktioniert bei Restaurants aber nicht die art der küche wird über den cuisine tag festgelegt. wie willst du dann einen china-mann der sowohl chinesisch als auch taiwanesisch kocht taggen? meist macht er es in der selben Küche. Funktionieren tut das schon, aber dann hat man halt zwei gleiche POIs, die sich nur im cuisine-tag unterschieden. Aber ich denke nicht, dass das eine korrekte Vorgehensweise wäre ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am 29. Oktober 2009 14:10 schrieb Sven Anders s...@anders-hamburg.de: Alternative wäre das wir auf key=value Verzichten und nur noch key eintragen und das würde ich als wirklichen Rückschritt empfinden. Die Alternative ist IMHO shop:fish=yes shop:wine=yes wobei shop:fish=seafish oder shop:wine=local oder shop:wine=barrels oder shop:wine=french vielleicht schon weniger bloedsinnig ist. Es ist bei den yes-Werten ja durchaus in der Vergangenheit schon oefters vorgekommen, dass es im Laufe der Zeit sinnvolle Varianten dazu gab (z.B. -1 fuer oneway) Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Am 29. Oktober 2009 22:54 schrieb Guenther Meyer d@sordidmusic.com: ausserdem, wie willst sowas sonst mappen? zwei pois fuer einen laden?!? ja, das ist in manchen Faellen sicher keine schlechte Loesung, erhaelt den Ueberblick und die Zugehoerigkeit am einfachsten. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
On Thu, Oct 29, 2009 at 02:10:11PM +0100, Sven Anders wrote: Am Mittwoch, 28. Oktober 2009 17:40:10 schrieb Mirko Küster: shop=wine amenity=post_office;bank;atm Klappt z.B. nicht bei Bürgerzentren mit Arzt oder Poststellen in Rathäusern oder anderen öffentlichen Gebäuden. Denn die sind wiederum amenity, was ich ja nur einmal vergeben kann. Genauso wie Operator etc. was ohne Subschlüssel auch nur einmal geht. Komisches Argument. Ansonsnten könnte man auch gleich shop=post_office;bank;atm nehmen, was mit amenitys geht, aber eben wieder nicht mit shop. Die Postagenturen müssen mit allem kompatibel sein. Na Klar warum denn nicht shop=wine;fish für eine Wein-Fischgeschäft. +1 Wenn du bei nicht verwendung des Simikolons einen Fehler siehst ist das schön. Hiflt uns aber in der Praxis nicht weiter, außer du bringst alle dazu den Fehler zu beheben und das ganze auszuwerten. Ansonsten sind Tags mit Semikolon auch weiterhin nur tote Tags. Ich mappe nicht für den Renderer und für Programme die das nicht können. +1 seit der umstellung auf api0.6 kommt man ja oft nicht mehr um die semikolon-schreibweise rum. fuer menschliche augen mag das zum teil recht unuebersichtlich sein, fuer programme eigentlich wesentlich einfacher. aber man muss es halt implementieren (was auch weiter nicht schwer ist)... Alternative wäre das wir auf key=value Verzichten und nur noch key eintragen und das würde ich als wirklichen Rückschritt empfinden. Die Alternative ist IMHO shop:fish=yes shop:wine=yes etc. ist IMHO bloedsinnig! +1 signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Komisches Argument Ist es nicht, den keiner versteht zweimal Amenity durch was auch immer getrennt. Ich verlasse mich nicht darauf das vielleicht irgendwann mal ein Trenner erkannt wird. Na Klar warum denn nicht shop=wine;fish für eine Wein-Fischgeschäft. Weil es keine einzige Anwendung auswertet und dieser Node komplett tot in der DB gammelt. Ich mappe nicht für den Renderer und für Programme die das nicht können. Also alle und damit mappst du in dem Fall für die Tonne Wenn wir das aber haufenweise eintragen, werden die Anwendungsentwickler das schon fixen. Die Anwendungsentwickler müssen ja auch irgendway=yes einbauen. Das wird schon seit Ewigkeiten für paralele refs an Straßen ect. verwendet und die Datenbank ist voll davon. Der Leidensdruck ist schon lange da, fruchtet in dem Fall aber nicht. Da wurden weit weniger verwendete Geschichten schneller eingebaut. Vielleicht ist es ein technisches Problem was desshalb auch bis auf weiteres garnicht umgesetzt werden kann. Das sollte man vorher mal abklären. Es gibt die eine oder andere Karte die zwei refs auswirft, allerdings nur den vollen Wert als reinen Text und inklusive Semikolon. Ein weiteres Problem ist die Zuordnung. Wenn man verschiedene Läden mit verschiedenen Brands und Operatoren verbindet, kann man ohne direkten Zeiger garnicht verknüpfen. Wie kann eine Maschine bitte folgende Shops mit den zugehörigen Operatoren verbinden? shop=wine;chemist amenity=post_office operator=Hermes;Weingut Schulze;Deutsche Post;Schlecker Jetzt lass mal die Postecke noch abweichende Schalterzeiten gegenüber den Öffnungszeiten haben. Sowas ist z.B. bei den Bürgernzentren der Fall. Da ist der Supermarkt immer auf. Dienstag und Donnerstag ist das Bürgerbüro besetzt, Mittwochs der Arzt da. Jeder hat eine eigene Telefonnummer, heißt anders. Bis auf die Adresse haben die nichts gemein. Das alles unverknüpft in einen Tag hauen mag zwar die Information zusammenfassen. Ausser dem Mapper selbst kann das aber keiner mehr dem jeweiligen Teil zuordnen. So eine Matsche ist schlimmer als wie wenn man dafür wie bisher einzelne aber dafür eindutige Einzellnodes setzt und wahlweise noch in so einer Site Relation mit Adresse zusammen hällt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)
Guenther Meyer d@sordidmusic.com writes: dann muessen das die anwendungen eben lernen. Es ist nicht ganz trivial, wenn auf einmal listen in bestimmten feldern auftauchen. Wenn man so etwas nicht vorab festlegt, sollte man als mapper nicht die alten daten kaputtmachen, sondern zumindest fuer eine uebergangszeit ein passendes tag verwenden, z.b.: shop_list=bicycle;xxx etc. ausserdem, wie willst sowas sonst mappen? zwei pois fuer einen laden?!? Genau so. Warum denn nicht? Falls notwendig, tust du dann beide wieder in eine relation, wie man das beispielsweise mit strassenschnipseln auch machen sollte. technisch sehe ich da ueberhaupt keine probleme... Seelig sind... -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
