Re: [Talk-de] addr:phone vs. phone
Hallo, Martin Koppenhoefer schrieb: Übrigens, (das schreibe ich Dir nicht zum ersten Mal), ist das Hauptobjekt das Grundstück (zumindest hat das die Adresse), und nicht das Gebäude. Das Gebäude ist Teil des Grundstücks. Das stimmt so nicht: Gebäude und Grundstück haben keine 1:1-Beziehung! - Das Grundstück hat eine Flurstücksnummer - Das Gebäude / Gebäudeteil / der Hauseingang haben die Hausnummer und somit die Adresse Es gibt die Kombinationen: - Mehrere Hausnummern (Adressen) auf einem Grundstück (Flurstücksnummer) (1:n) - Ein Gebäude mit einer Adresse erstreckt sich über mehrere Grundstücke (unterschiedliche Flurnummern) (n:1) - Eine Hausnummer auf einem Grundstück (1:1) - wahrscheinlich gibt es auch noch n:n (ein Gebäude mit mehreren Eingängen = Adressen auf unterschiedlichen Grundstücken) Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am 8. Februar 2010 09:52 schrieb Stefan Dettenhofer (StefanDausR) o...@dentro.info: Hallo, Martin Koppenhoefer schrieb: Übrigens, (das schreibe ich Dir nicht zum ersten Mal), ist das Hauptobjekt das Grundstück (zumindest hat das die Adresse), und nicht das Gebäude. Das Gebäude ist Teil des Grundstücks. Das stimmt so nicht: Gebäude und Grundstück haben keine 1:1-Beziehung! - Das Grundstück hat eine Flurstücksnummer ja, auch, das ist aber eine Katasternummer (Identifikation der Parzelle, diese Teil einer Flur, dann Gemarkung...), nicht das selbe wie eine Grundstücksnummer. - Das Gebäude / Gebäudeteil / der Hauseingang haben die Hausnummer und somit die Adresse Das ist Länderrecht (oder sogar kommunal?) und vermutlich unterschiedlich geregelt. Ich beziehe mich oben auf Berlin. Quelle hier: http://www.stadtentwicklung.berlin.de/service/gesetzestexte/de/download/geoinformation/Vorschriftensammlung/7_1.pdf Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Das ist Länderrecht (oder sogar kommunal?) und vermutlich unterschiedlich geregelt. Ich beziehe mich oben auf Berlin. Quelle Glaube kommunal, hier unsere Besttimmungen dazu: (Hausnummernverordnung) Auf Grund des § 27 Absatz 3 des Thüringer Gesetzes über die Aufgaben und Befugnisse der Ordnungsbehörden (Ordnungsbehördengesetz OBG-) vom 18. Juni 1993 (GVBl, S.323), geändert durch Gesetz vom 24.10.2001 (GVBl. S. 265), vom 20.06.2002 (GVBl. S. 247) erläßt die Stadt Roßleben als Ordnungsbehörde folgende Verordnung: § 1 Geltungsbereich, Zweck (1) Diese ordnungsbehördliche Verordnung gilt für das gesamte Gebiet der Stadt Roßleben, sofern in den nachfolgenden Bestimmungen nicht ausdrücklich etwas anderes geregelt ist. (2) Diese ordnungsbehördliche Verordnung dient der einheitlichen Vergabe von Hausnummern an Gebäudegrundstücken, zur Wahrung der öffentlichen Ordnung und Sicherheit sowie der Gewährleistung der rechtzeitigen Erreichbarkeit durch Rettungsdienste und Feuerwehr. § 2 Vergabe der Hausnummern (1) Jedes Gebäudegrundstück erhält in der Regel eine Hausnummer. Bei Häusern mit mehreren Eingängen bzw. Treppenhäusern, zwischen denen keine allgemein zugängliche Verbindung besteht, erhält jeder Eingang eine gesonderte Hausnummer. Bilden mehrere Gebäude eine wirtschaftliche Einheit, erhalten sie eine gemeinsame Hausnummer. Von mehreren auf einem Grundstück errichteten Gebäuden erhält jedes wirtschaftlich selbstständige Gebäude eine eigene Hausnummer. (2) Das Sachgebiet Liegenschaften der Stadt Roßleben teilt die Hausnummer zu. Bei der Errichtung von Neubauten werden die festgesetzten Hausnummern dem Grundstückseigentümer auf Antrag schriftlich mitgeteilt. Bestehen für bereits bebaute Grundstücke, die unter diese Verordnung fallen, keine Hausnummern, erfolgt die Festsetzung durch die Stadt Roßleben. § 3 Pflichten des Eigentümers Der Eigentümer des Gebäudes, für welches das Sachgebiet Liegenschaften der Stadt Roßleben eine Hausnummer zugeteilt hat, ist verpflichtet, die Hausnummer innerhalb von 8 Wochen nach Erhalt der Mitteilung, bei Neubauten spätestens bis zum Bezug des Gebäudes, gemäß § 2 Abs. 2 auf seine Kosten zu beschaffen und entsprechend den Bestimmungen dieser Verordnung und etwaigen weiteren Auflagen ordnungsgemäß anzubringen und zu unterhalten. § 4 Anbringen der Hausnummern (1) Die Hausnummer ist an der Straßenseite des Gebäudes an gut sichtbarer Stelle anzubringen. Befindet sich der Hauseingang an der Straßenseite, ist sie unmittelbar rechts neben der Eingangstür in Höhe der Oberkante der Tür anzubringen. Befindet sich die Eingangstür nicht an der Straßenseite, ist die Hausnummer straßenseitig an der Eingangstür nächstliegenden Ecke des Gebäudes anzubringen. Würde die Einfriedung eine gute Sicht von der Straße auf die am Gebäude angebrachte Hausnummer verhindern, ist sie unmittelbar rechts neben dem Eingang der Einfriedung zur Straße hin anzubringen. (2) Aus Gründen der Übersichtlichkeit sind für Häuserblöcke oder Hausgruppen zusätzlich zu den einzelnen Nummern an sichtbarer Stelle die Hausnummern zusammengefasst anzubringen. (3) Es kann eine andere Art der Anbringung zugelassen oder angeordnet werden, wenn dies in besonderen Fällen, insbesondere zur besseren Sichtbarkeit der Hausnummer, geboten ist. § 5 Gestaltungsvorschriften Die Hausnummern müssen gut lesbar sein. Für die Zahlen wird eine Mindesthöhe von 70 mm und für die Buchstaben eine Mindesthöhe von 50 mm vorgeschrieben. Die Lesbarkeit der Hausnummer ist durch den Eigentümer zu gewährleisten. § 6 Änderung von Hausnummern (1) Bei der Änderung der bisherigen Hausnummer finden die §§ 2 bis 5 entsprechende Anwendung. Zur besseren Orientierung kann die alte Hausnummer für die Dauer höchstens von einem Jahr ab Vergabedatum am Haus bzw. am Grundstück belassen werden. Sie ist in rot so durchzustreichen, dass sie noch lesbar ist. Nach Ablauf dieses Zeitraumes ist die alte Hausnummer zu entfernen. (2) Bei notwendiger Erneuerung der Hausnummer tritt an die Stelle der Mitteilung nach § 2 Abs. 2 Satz 3 die Aufforderung der Stadt an den Eigentümer, die Hausnummer zu erneuern. Im Übrigen finden die §§ 2 bis 5 entsprechende Anwendung mit der Maßgabe, dass die vom Eigentümer zu tragenden Kosten auch die Aufwendungen beinhalten, die in unmittelbarem Zusammenhang mit der Erneuerung der Hausnummer am Haus entstehen. § 7 Ausnahmen Auf schriftlichen Antrag kann die Abt. Liegenschaften der Stadt Roßleben Ausnahmen von den Bestimmungen dieser Verordnung zulassen. § 8 Ordnungswidrigkeiten (1) Ordnungswidrig im Sinne von § 50 des Ordnungsbehördengesetzes (OBG) handelt, wer 1. vorsätzlich oder fahrlässig entgegen § 3 sein Haus nicht auf eigene Kosten mit der dem Grundstück vom Sachgebiet Liegenschaften der Stadt Roßleben zugeteilten Hausnummer versieht, 2. die Hausnummer nicht gem. § 5 von der Straße aus erkennbar und lesbar anbringt und erhält oder 3. die Hausnummer entgegen den Bestimmungen in § 4
Re: [Talk-de] addr:phone vs. phone
Am 8. Februar 2010 16:05 schrieb Mirko Küster webmas...@ts-eastrail.de: § 2 Vergabe der Hausnummern (1) Jedes Gebäudegrundstück erhält in der Regel eine Hausnummer. Bei Häusern mit mehreren Eingängen bzw. Treppenhäusern, zwischen denen keine allgemein zugängliche Verbindung besteht, erhält jeder Eingang eine gesonderte Hausnummer. Bilden mehrere Gebäude eine wirtschaftliche Einheit, erhalten sie eine gemeinsame Hausnummer. Von mehreren auf einem Grundstück errichteten Gebäuden erhält jedes wirtschaftlich selbstständige Gebäude eine eigene Hausnummer. Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Hallo, wenn ich das richtig gesehen habe, wurde gerade beim Thema: Ruhr2010-barrierefrei als Tag für Telefonnummern addr:phone angegeben. Wem das nicht, wie mir, egal ist, ob addr:phone oder phone getagt wird, kann sich ja schnell einschalten. Liebe Grüße Christian Harald Schwarz schrieb: Hallo zusammen, danke für eure Hinweise. Ich werde nochmal darüber nachdenken. Der Grund für meine Nutzung von addr:phone, addr:fax, addr:email liegt in dem was ich unter einer Adresse verstehe: Alles womit ich eine Person oder eine Institution erreichen, bzw. Kontakt aufnehmen kann. Wenn unter Adresse nur Informationen verstanden werden, mit denen ein Objekt lokalisiert bzw. per Brief angeschrieben, also adressiert werden kann, dann passen natürlich obige Kontaktinformationen nicht ins addr:* Schema. Es hängt also ganz davon ab, welchen Blick man auf eine Adresse wirft um zu entscheiden was ins Schema gehört und wie man es tagt. Mit freundlichen Grüßen Harald Schwarz OSM: black_bike OSM-Wiki: BlackBike Original-Nachricht Datum: Sun, 7 Feb 2010 09:10:53 +0100 Von: André Riedel riedel.an...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: [Talk-de] addr:phone vs. phone Am 6. Februar 2010 13:01 schrieb Mirko Küster webmas...@ts-eastrail.de: Am 06.02.2010 12:42, schrieb Harald Schwarz: Ich finde hier kann man mal Adressdaten vereinheitlichen und sollte in Zukunft dafür allgemein addr:* einsetzen. Und für die Zukunft wäre das addr:* Schema viel besser. Die form mit addr: davor ist mir in der Praxis noch nie unter gekommen, ist glaube ich auch garnicht dokumentiert. Anders phone, fax, email, die ich so auch nutze. Welchen Vorteil versprichst du dir durch verwendung von addr:phone anstatt von phone? Zumal eine Telefonnummer nichts mit einer Anschrift zu tun hat, wofür das Schema entwickelt wurde. Eine Telefonnummer kann auch mal unabhängig von einer Adresse auftauchen, bspw. bei einem Audioguide oder als Informationshotline. Ich bin der Meinung, man sollte addr:* nicht sinnlos erweitern, nur damit die Kontaktdaten alle bei einander stehen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Mirko Küster webmas...@ts-eastrail.de [Mon, Feb 08, 2010 at 02:53:45AM CET]: [...] Nun meine Überlegung. Warum erweitern wir nicht einfach das Objekt selbst und ermöglichen so mit zusätzlichen Sets, Groups, Name Wumpe, die Eigenschaften gleich direkt am Objekt zu belassen, vermeiden Redundanzen und erschlagen Krücken durch Tagüberschneidungen? Das könnte jetzt mal vereinfacht so aussehen: way id='123456' version='1' nd ref='1' / nd ref='2' / nd ref='3' / nd ref='4' / tag k='building' v='yes' / tag k='addr:postcode' v=12345' / tag k='addr:country' v='DE' / tag k='addr:street' v='Straße' / tag k='addr:city' v='Musterstadt' / tag k='addr:housenumber' v='1' / object group id='123456.001' / tag k='amenity' v='bank' / object group id='123456.001' / object group id='123456.002' / tag k='amenity' v='bank' / object group id='123456.002' / /way Mal vorsichtig gefragt. Redest Du hier einer syntaktisch bedeutsamen Einrückung wie bei Python das Wort oder wolltest Du nicht hier ein paar Tags offen lassen/schachteln? Ist mir ja schon klar, dass OSM nicht streng XML folgt, aber sowas wie mehrere Tags mit identischem Inhalt/identischer ID finde ich schon ungebräuchlich. Ich weiß nun nicht wie schwierig das ist um es in einer zukünftigen API vorzusehen. Ansich wäre es ja nur eine neue Tagrule und eine Erweiterung der ID, um die Gruppen Sub ID anhängen zu können. Ich denke mal die IDs sind begrenzt, wo es haken wird. Als Erweiterung der bestehenden Syntax kann das gehen und es kann dann nützlich sein, wenn das Gesamtgebilde nicht eine Relation sein soll (wie ein landuse=farmland mit mehreren Gebäuden drin). Man muss aber bedenken, dass durch so eine Schachtelung nicht so leicht m:n-Relationen abbildbar sind wie bei ... naja ... Relationen. Deshalb sehe ich sie nur als Ergänzung und nicht als Ersatz. [...] Um Grundstücke gehts wie gesagt erstmal garnicht. Sondern um das Problem mit dutzenden Nutzungen im eigentlichen Gebäude oder anderen Objekte und eben die damit auflaufenden Probleme. Grundstücke sind wieder ne andere Geschichte. Das bisherige Vorgehen ist ja, das über räumliche Zugehörigkeit zu regeln, also ein Gebäudeumriss mit verschiedenen Knoten für die Bäckere^H^H^H^H^H^H^HTeig- warenfiliale, Pos^H^H^HSchreibwarenladen mit gelber Theke, Spielhölle und Boutique. Natürlich stößt das an Grenzen, aber ich bin nicht überzeugt, dass die Repräsentation in der Datenstruktur, die Du vorschlägst (so ich sie richtig verstanden habe) gegenüber räumlicher Ordnung und Relationen einen wesentlichen Vorteil bietet. Wenn die Editorschnittstelle davor das Entscheidende ist, ist das Datenmodell dahonter doch ohnehin zweitrangig (zumindest wenn es zu wenig anfängerfreundlich erscheint). -- 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] addr:phone vs. phone
Mal vorsichtig gefragt. Redest Du hier einer syntaktisch bedeutsamen Einrückung wie bei Python das Wort oder wolltest Du nicht hier ein paar Tags offen lassen/schachteln? Ist mir ja schon klar, dass OSM nicht streng XML folgt, aber sowas wie mehrere Tags mit identischem Inhalt/identischer ID finde ich schon ungebräuchlich. Das war nur so eine Idee, ich bin kein Programmierer. Als Erweiterung der bestehenden Syntax kann das gehen und es kann dann nützlich sein, wenn das Gesamtgebilde nicht eine Relation sein soll (wie ein landuse=farmland mit mehreren Gebäuden drin). Man muss aber bedenken, dass durch so eine Schachtelung nicht so leicht m:n-Relationen abbildbar sind wie bei ... naja ... Relationen. Deshalb sehe ich sie nur als Ergänzung und nicht als Ersatz. Das soll es sein, eine Ergänzung für die vielen einfachen Fälle, wo es die große Relation nicht braucht, die viele eben gleich bleiben lassen. Das bisherige Vorgehen ist ja, das über räumliche Zugehörigkeit zu regeln, also ein Gebäudeumriss mit verschiedenen Knoten für die Bäckere^H^H^H^H^H^H^HTeig- warenfiliale, Pos^H^H^HSchreibwarenladen mit gelber Theke, Spielhölle und Boutique. Die Räumliche Zuordnung über Relation macht ja vielleicht bei einem riesen Einkaufszentrum oder anderen großen Sachen noch Sinn. Daneben hats aber in der Masse viele Lädchen oder Nutzer in kleinen Häusern. Ich hatte ja immer wieder das Beispiel der Postbank in der Postagentur, das zusammen in einem Laden der mehreres anbietet. Das spielt sich alles auf etwa 60m² ab. Da hast du das kleine Häuschen und darüber eine riesen POI Wolke, redundante Adressen etc. Die Zoomstufe dafür wurde noch garnicht erfunden. In Osmarender hast du Brei, in Mapnik garnichts, es verdrängt sich alles. Für solche Sachen reicht es die einzelnen Nutzungen einfach ans Gebäude hängen zu können. Da brauchst du auch keine Räumliche zuordnung. Und vielleicht ist dann diese Gruppierung auch ein besserer Ansatz das Renderer das auch sauberer Ordnen können. Denn die Position wäre dann egal, alles kann sauber platziert werden. Bei POI Wolken wird einfach nur verdrängt. Natürlich stößt das an Grenzen, aber ich bin nicht überzeugt, dass die Repräsentation in der Datenstruktur, die Du vorschlägst (so ich sie richtig verstanden habe) gegenüber räumlicher Ordnung und Relationen einen wesentlichen Vorteil bietet. Wenn die Editorschnittstelle davor das Entscheidende ist, ist das Datenmodell dahonter doch ohnehin zweitrangig (zumindest wenn es zu wenig anfängerfreundlich erscheint). Mir ist es ja im grunde egal wie es gelöst wird. Nur Fakt ist, die Relation in der jetzigen Form ist für viele Sachen weit drüber. Und in der jetzigen Form für viele ein Grund einen Bogen drumherum zu machen, andere zerhauen sie unbewusst. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Moin Loide (sowie sehr geehrte Damen und Herren), eigentlich gibt es das Format ja schon, das Rad braucht man nicht erfinden, würde ich sagen, und heißt JSON (JavaScript Object Notation). http://www.json.org/example.html (oben z.B.) Das wird u.a. bei AJAX- Web-Applikationen ständig verwendet. Das Format kann man umgießen, also in einen einzelnen Text-String quetschen (dann wäre es sogar kompatibel mit der v0.6 API von OSM), oder automatisch eingerückt darstellen, wie es beliebt. Es bietet hierarchische Struktur, Listen/ Arrays, Hashes, verschachtelte Datenstrukturen, also eigentlich alles, was man braucht und als Skript-Programmierer schon seit Jahrzehnten kennt. Schnittstellen/ Libraries zu allen gängigen Programmiersprachen sind vorhanden (C/C++, Java, Python, PHP, Flash ActionScript, Perl, etc). Was man dabei zunächst verlöre, wenn die Datenbank damit nicht umgehen kann, wäre die 1:1-Beziehung zwischen k,v-Werten und Darstellung. Aber zum Glück gibt es ja PostgreSQL, dafür gibt es sicher irgendwo eine native Umsetzung? Wenn nicht, kann man das mit einer klassischen rekursiven Datenstruktur mit ID-Pointern (wie bei Dateisystem-Inoden) auch mit jeder Wald- und Wiesen-Datenbank definieren. Ob expliziter Zugriff auf jedes Unter-Element per Datenbank performant ist, ist eine andere Frage. Aber vielleicht wäre so eine Umsetzung auch die Lösung für viele Spezial-Abfragen, bei denen man heute erst einmal einen eigenen Tag-Parser braucht, oder sehr viele Ergebnisse verwirft, weil man nicht nach einem spezifischen Namensraum fragen kann. Aber definitiv wäre das der systematischere Ansatz. Meine 2 inflationären Centavos aus der 26°C warmen DomRep, Jochen On Lun 08 Feb 2010, Johannes Huesing wrote: Natürlich stößt das an Grenzen, aber ich bin nicht überzeugt, dass die Repräsentation in der Datenstruktur, die Du vorschlägst (so ich sie richtig verstanden habe) gegenüber räumlicher Ordnung und Relationen einen wesentlichen Vorteil bietet. Wenn die Editorschnittstelle davor das Entscheidende ist, ist das Datenmodell dahonter doch ohnehin zweitrangig (zumindest wenn es zu wenig anfängerfreundlich erscheint). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am Montag 08 Februar 2010 22:29:13 schrieb Jochen Plumeyer: Moin Loide (sowie sehr geehrte Damen und Herren), eigentlich gibt es das Format ja schon, das Rad braucht man nicht erfinden, würde ich sagen, und heißt JSON (JavaScript Object Notation). http://www.json.org/example.html (oben z.B.) Das wird u.a. bei AJAX- Web-Applikationen ständig verwendet. Das Format kann man umgießen, also in einen einzelnen Text-String quetschen (dann wäre es sogar kompatibel mit der v0.6 API von OSM), oder automatisch eingerückt darstellen, wie es beliebt. klar koennte man das. man koennte aber auch xml verwenden. ich denke das gibt sich nicht viel... json ist halt kompakter, aber dafuer auch nicht so gut menschenlesbar. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] addr:phone vs. phone
Am 6. Februar 2010 13:01 schrieb Mirko Küster webmas...@ts-eastrail.de: Am 06.02.2010 12:42, schrieb Harald Schwarz: Ich finde hier kann man mal Adressdaten vereinheitlichen und sollte in Zukunft dafür allgemein addr:* einsetzen. Und für die Zukunft wäre das addr:* Schema viel besser. Die form mit addr: davor ist mir in der Praxis noch nie unter gekommen, ist glaube ich auch garnicht dokumentiert. Anders phone, fax, email, die ich so auch nutze. Welchen Vorteil versprichst du dir durch verwendung von addr:phone anstatt von phone? Zumal eine Telefonnummer nichts mit einer Anschrift zu tun hat, wofür das Schema entwickelt wurde. Eine Telefonnummer kann auch mal unabhängig von einer Adresse auftauchen, bspw. bei einem Audioguide oder als Informationshotline. Ich bin der Meinung, man sollte addr:* nicht sinnlos erweitern, nur damit die Kontaktdaten alle bei einander stehen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Hallo zusammen, danke für eure Hinweise. Ich werde nochmal darüber nachdenken. Der Grund für meine Nutzung von addr:phone, addr:fax, addr:email liegt in dem was ich unter einer Adresse verstehe: Alles womit ich eine Person oder eine Institution erreichen, bzw. Kontakt aufnehmen kann. Wenn unter Adresse nur Informationen verstanden werden, mit denen ein Objekt lokalisiert bzw. per Brief angeschrieben, also adressiert werden kann, dann passen natürlich obige Kontaktinformationen nicht ins addr:* Schema. Es hängt also ganz davon ab, welchen Blick man auf eine Adresse wirft um zu entscheiden was ins Schema gehört und wie man es tagt. Mit freundlichen Grüßen Harald Schwarz OSM: black_bike OSM-Wiki: BlackBike Original-Nachricht Datum: Sun, 7 Feb 2010 09:10:53 +0100 Von: André Riedel riedel.an...@gmail.com An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: [Talk-de] addr:phone vs. phone Am 6. Februar 2010 13:01 schrieb Mirko Küster webmas...@ts-eastrail.de: Am 06.02.2010 12:42, schrieb Harald Schwarz: Ich finde hier kann man mal Adressdaten vereinheitlichen und sollte in Zukunft dafür allgemein addr:* einsetzen. Und für die Zukunft wäre das addr:* Schema viel besser. Die form mit addr: davor ist mir in der Praxis noch nie unter gekommen, ist glaube ich auch garnicht dokumentiert. Anders phone, fax, email, die ich so auch nutze. Welchen Vorteil versprichst du dir durch verwendung von addr:phone anstatt von phone? Zumal eine Telefonnummer nichts mit einer Anschrift zu tun hat, wofür das Schema entwickelt wurde. Eine Telefonnummer kann auch mal unabhängig von einer Adresse auftauchen, bspw. bei einem Audioguide oder als Informationshotline. Ich bin der Meinung, man sollte addr:* nicht sinnlos erweitern, nur damit die Kontaktdaten alle bei einander stehen. Ciao André ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- NEU: Mit GMX DSL über 1000,- ¿ sparen! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Der Grund für meine Nutzung von addr:phone, addr:fax, addr:email liegt in dem was ich unter einer Adresse verstehe: Alles womit ich eine Person oder eine Institution erreichen, bzw. Kontakt aufnehmen kann. Wir sammeln Geodaten. Adressen sind eigentlich fest an Grundstücke oder Gebäudeteile vergebene Merkmale. Geplante aber unbebaute Grundstücke haben auch fest vergebene Adressen, die wir hier allerdings nicht hinterlegen. Sehen oder wissen wir ja meistens sowieso nicht und wir verwalten die ja nicht sondern pflegen den aktuell vorhandenen Bestand. Unsere Möglichkeiten geben es aber schlicht nicht her ein Grundstück zu definieren, dem als Member die Gebäude und darunter wiederum die einzelnen Nutzer als Gruppen anzulegen. Deswegen machen wir für alles einen POI und da muss dann jedesmal extra die Adresse dazu oder der POI irgendwie verknüpft werden. Kontaktdaten sind kein Bestandteil der eigentlichen Adresse, das sind frei wählbare Kontaktmöglichkeiten eines einzlenen Nutzers oder einer Sache, die vollkommen unabhängig von Adressen laufen. Auch Gegenstände oder Nutzer ohne Adresse können einen Kontakt haben. Automaten, Imbissstände, Informationsangebote... Kontaktdaten passen daher nicht wirklich ins Adressschema. Und weil es Kontakte sind, hat man es glaube auch mal mit dem Namensraum contact:* probiert. Das hat sich allerdings auch nicht weiter verbreitet. Andere Projekte machen ebenso Extrawürste mit Namensräumen. Braucht aber keiner, eim simples phone für eine Telefonnummer reicht. Keep it simple. Da wo es nicht nötig ist brauchts keine unnötig aufblähten und verkomplizierten Tags. Vor allem wenn diese dann derzeit ohne Editorunterstützung auskommen muss und wieder dutzende Tippfehler ansaugt. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Mirko Küster webmas...@ts-eastrail.de [Sun, Feb 07, 2010 at 02:02:46PM CET]: [...] Und weil es Kontakte sind, hat man es glaube auch mal mit dem Namensraum contact:* probiert. Das hat sich allerdings auch nicht weiter verbreitet. Andere Projekte machen ebenso Extrawürste mit Namensräumen. Braucht aber keiner, eim simples phone für eine Telefonnummer reicht. Keep it simple. Hab jetzt nicht nachgeschaut, ob das vorkommt, aber was würde man bei phone=* im Zusammenhang mit amenity=phone erwarten? Die Nummer einer anrufbaren Telefonzelle, die Nummer der zugehörigen Störungsstelle, oder eine nähere Beschreibung des Telefons (ähnlich wie natural=wetland, wetland=marsh)? -- 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] addr:phone vs. phone
Mirko Küster webmas...@ts-eastrail.de [Sun, Feb 07, 2010 at 02:02:46PM CET]: [...] Und weil es Kontakte sind, hat man es glaube auch mal mit dem Namensraum contact:* probiert. Das hat sich allerdings auch nicht weiter verbreitet. Andere Projekte machen ebenso Extrawürste mit Namensräumen. Braucht aber keiner, eim simples phone für eine Telefonnummer reicht. Keep it simple. Hab jetzt nicht nachgeschaut, ob das vorkommt, aber was würde man bei phone=* im Zusammenhang mit amenity=phone erwarten? Die Nummer einer anrufbaren Telefonzelle, die Nummer der zugehörigen Störungsstelle, oder eine nähere Beschreibung des Telefons (ähnlich wie natural=wetland, wetland=marsh)? Was du da erwartest weiß ich nicht. Ich würde darunter die Nummer einer anrufbaren Zelle verstehen, da phone nunmal für die Telefonnummer steht. Für einen Spezialfall wie Telefonzelle muss man dann mit Zusatzangaben entsprechend abgrenzen. service:phone Störung, emergency:phone Notruf etc. Da hat sich noch keiner weiter Gedanken gemacht. Bei der Telefonzelle hat man es sich aber auch wieder zu einfach gemacht. Eigentlich sind das ja call box, telephone booth, telephone box, phone box. Während man nur phone ja eigentlich normal im contact nutzt. Das ist wieder so eine unnötige hausgemachte Überschneidung. Ansonsten hast du genauso wie bei access die gleiche Grütze. Neutrale einfache Tags wie bicycle=yes, die sich eigentlich schön global einsetzen lassen, für den einen Spezialfall wie eben access auf ewig festgenagelt. Dafür muss man dann jeglicher anderen Verwendung wieder einen extra Namensraum verpassen oder gar einen ganz neuen Tag erfinden. Extrem häßlich, aber wohl nicht mehr zu ändern. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am 7. Februar 2010 14:02 schrieb Mirko Küster webmas...@ts-eastrail.de: Unsere Möglichkeiten geben es aber schlicht nicht her ein Grundstück zu definieren, dem als Member die Gebäude und darunter wiederum die einzelnen Nutzer als Gruppen anzulegen. ach so? Unsere Möglichkeiten geben das nicht her? Kann man mit Relationen doch problemlos machen. Auch Gegenstände oder Nutzer ohne Adresse können einen Kontakt haben. Automaten, Imbissstände, Informationsangebote... Kontaktdaten passen daher nicht wirklich ins Adressschema. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
ach so? Unsere Möglichkeiten geben das nicht her? Kann man mit Relationen doch problemlos machen. Ihr und eure Relationen... kompliziert, von vielen gemieden und alles andere als die ultimative Lösung für alles. Ja ich kann eine Site für ein Grunstück anlegen, und ja, ich kann dann eine Buildung machen. Das kann ich schön verschachteln. Ist aber sowas von anfällig und für viele zu kompliziert. Editorunterstützung garnicht bis kompliziert. Mit solchen Konstrukten nagelst du dir einen enormen Pflegeaufwand an die Backe. Ich würde da gerne einen anderen Weg gehen. Tag Set oder Group am Objekt selbst. Hauptobjekt Buildung mit seiner Adresse und vielleicht anderen Angaben und darunter für jeden Nutzer ein Set. Das erbübrigt dutzende Redundanzen und Einzelnodes, sowie Semikolonorgien, die sich maschinell auch nicht mehr Ordnen lassen und von der korrekten Eintragsreihenfolge des Nutzers abhängen. Im Set hast du das Problem nicht. Da kannst du meinetwegen das Set amenity=bank und das Set amenity=post_office als Postagentur in einem Objekt haben, beides jeweils mit seinen eigenen Angaben und ohne Überschneidungen. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am 7. Februar 2010 17:10 schrieb Mirko Küster webmas...@ts-eastrail.de: ach so? Unsere Möglichkeiten geben das nicht her? Kann man mit Relationen doch problemlos machen. Ihr und eure Relationen... kompliziert, von vielen gemieden und alles andere als die ultimative Lösung für alles. dann schreib doch bitte nicht, dass _unsere_ Möglichkeiten das nicht hergeben. Ja ich kann eine Site für ein Grunstück anlegen, und ja, ich kann dann eine Buildung machen. Das kann ich schön verschachteln. Ist aber sowas von anfällig und für viele zu kompliziert. Editorunterstützung garnicht bis kompliziert. Du übertreibst m.E. maßlos: was soll an der Relation kompliziert sein? Die Zugehörigkeit wird an jedem Objekt angezeigt. Mit solchen Konstrukten nagelst du dir einen enormen Pflegeaufwand an die Backe. wieso? Von selbst geht das nicht kaputt... Ich würde da gerne einen anderen Weg gehen. Tag Set oder Group am Objekt selbst. Hauptobjekt Buildung mit seiner Adresse und vielleicht anderen Angaben und darunter für jeden Nutzer ein Set. Das erbübrigt dutzende Redundanzen und Einzelnodes, sowie Semikolonorgien, die sich maschinell auch nicht mehr Ordnen lassen und von der korrekten Eintragsreihenfolge des Nutzers abhängen. Im Set hast du das Problem nicht. Da kannst du meinetwegen das Set amenity=bank und das Set amenity=post_office als Postagentur in einem Objekt haben, beides jeweils mit seinen eigenen Angaben und ohne Überschneidungen. Soll das dann auch wieder mit Relationen gemacht werden, oder was sind diese sets? Das ist doch Schnee von Morgen, davon höre ich zum ersten Mal, und weder Editoren noch API verstehen das. Wieso das einfacher oder überhaupt was anderes als ne Relation sein soll, ist mir auch nicht klar geworden. Übrigens, (das schreibe ich Dir nicht zum ersten Mal), ist das Hauptobjekt das Grundstück (zumindest hat das die Adresse), und nicht das Gebäude. Das Gebäude ist Teil des Grundstücks. Von daher sollte es eigentlich ganz einfach sein: Siterelation, Grenze ist das Grundstück, dieses erhält die Adresse, darauf liegen die Gebäude (mit ggf. Adresszusätzen die nur gebäudeweise gelten) und die Nutzungen (oder, wenn man es gerne kompliziert hat: die Nutzungen in den Gebäuden). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Du übertreibst m.E. maßlos: was soll an der Relation kompliziert sein? Die Zugehörigkeit wird an jedem Objekt angezeigt. Für dich ist das nicht kompliziert. Aber wie oft laufen Leute auf für die das nicht so ist, die Relationen meiden oder unbewusst kaputt machen? Aktuell haben wir doch wieder mal verschwundene Relationen auf der Liste. wieso? Von selbst geht das nicht kaputt... Doch, wenn irgendwein Tool Mist baut. Ansonsten braucht bloß einer einen Weg teilen, den Dialog nicht verstehen und wieder hats einen Fehler. Relationen fliegen einem permament um die Ohren. Ein Horror wenn jedes Gebäude eine hätte. Da bist du mehr mit fixen als mit anlegen beschäftigt. Ich habe vor einem halben Jahr aufgehört zu zählen, wie oft beispielsweise Busrelationen kaputt gingen. Soll das dann auch wieder mit Relationen gemacht werden, oder was sind diese sets? Das ist doch Schnee von Morgen, davon höre ich zum ersten Mal, und weder Editoren noch API verstehen das. Wieso das einfacher oder überhaupt was anderes als ne Relation sein soll, ist mir auch nicht klar geworden. Eben keine Relationen die wieder als eigenes Objekt dutzende andere Objekte mit Rollen zusammen kitten. Genau das solls nicht sein. Objekte wie jetzt auch, nur vom editor unterstützt die Möglichkeit ein eigenes Set oder Schachtel ins Objekt bringen. Nehmen wir als Vergleich einen Osmarender Style. Der hat eine Hauptschachtel die grob den Hauptag beschreibt. Darunter jeweils eine eigene Schachtel für jeweilige Defintionen die aber so immer in Verbindung mit Hauptobjekt bleibt. Im Moment geht pro Nutzung immer nur eine einzige Schachtel. So könntest du alles in einem Objekt halten, hast keine Überschneidungsprobleme mit gleichen Tags und brauchst auch keine zusätzlichen virtuellen Objekte wie Relationen. Haus Adresse +Set 1 Bank Kontakt etc. +Set 2 Post Bank Kontakt etc. Klar wird das noch nicht unterstützt. Man ruht sich ja noch auf den Beschränkungen und den Relationen aus. Das muss man erstmal audkaspern. Übrigends ist die Idee auch nicht neu. Kam früher schonmal und andere haben auch schon in der Richtung nachgedacht. Übrigens, (das schreibe ich Dir nicht zum ersten Mal), ist das Hauptobjekt das Grundstück (zumindest hat das die Adresse), und nicht das Gebäude. Das Gebäude ist Teil des Grundstücks. Erstens schreibe ich dir zum 1000 male das ich das weiß und zweitens interessiert das jetzt garnicht. Der Normale Mapper ist froh wenn er ein Gebäudepolygon zusammen hat. In Grundstücken braucht man in der Breite noch nicht zu denken. Das machst du, ich machs auch, vielleicht noch zehn oder zwanzig andere. Die Masse packt es mangeles besserer Daten ans Haus oder einen Node. Von daher sollte es eigentlich ganz einfach sein: Siterelation, Grenze ist das Grundstück, dieses erhält die Adresse, darauf liegen die Gebäude (mit ggf. Adresszusätzen die nur gebäudeweise gelten) und die Nutzungen (oder, wenn man es gerne kompliziert hat: die Nutzungen in den Gebäuden). Es ist für die breite Anwenderschaft eben alles andere als leicht. Es hat schon Seltenheitswert, wenn ich mal auf so eine Realtion stoße. Die Masse legt einfach Einzelobjekte. Ich nutze das auch nicht. Ich sehe wie andere Relationen permanent kaputt gehen. Solange das nicht sicherer wird oder eben eine andere Lösung kommt, mache ich einen Bogen darum. Verhunzte Objekte habe ich schnell wieder aus dem Backup geholt oder zurückgestellt. Bei Relationen ist es bei jeder einzelnen ne schöne Bastelarbeit. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
moin On 07.02.2010, at 12:06, Harald Schwarz wrote: Hallo zusammen, danke für eure Hinweise. Ich werde nochmal darüber nachdenken. Der Grund für meine Nutzung von addr:phone, addr:fax, addr:email liegt in dem was ich unter einer Adresse verstehe: Alles womit ich eine Person oder eine Institution erreichen, bzw. Kontakt aufnehmen kann. Wenn unter Adresse nur Informationen verstanden werden, mit denen ein Objekt lokalisiert bzw. per Brief angeschrieben, also adressiert werden kann, dann passen natürlich obige Kontaktinformationen nicht ins addr:* Schema. Es hängt also ganz davon ab, welchen Blick man auf eine Adresse wirft um zu entscheiden was ins Schema gehört und wie man es tagt. also der logik halber müsstest du dann auch addr:name vorschlagen. den wenn du nen gebäude mit mehreren mietern hast wird dir der rest der adresse nicht wirklich weiter helfen ;-) cu assetburned smime.p7s Description: S/MIME cryptographic signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am 7. Februar 2010 18:25 schrieb Mirko Küster webmas...@ts-eastrail.de: Soll das dann auch wieder mit Relationen gemacht werden, oder was sind diese sets? Eben keine Relationen die wieder als eigenes Objekt dutzende andere Objekte mit Rollen zusammen kitten. Genau das solls nicht sein. Objekte wie jetzt auch, nur vom editor unterstützt die Möglichkeit ein eigenes Set oder Schachtel ins Objekt bringen. m.E. rufst Du im Endeffekt nach einem einfachen Typ von Relation (der einfach ist, da er eingeschränkte Möglichkeiten hat, und z.B. nur eine feste Art von Rolle, um die man sich nicht kümmern braucht, weil der Editor das macht, könnte man z.B. Gruppe nennen) mit bedienerfreundlicher Editorunterstützung. Nichts dagegen, im Gegenteil, nur solange man das nicht programmiert bleibt es halt Wunschdenken. Diese Gruppen könnten z.B. den Effekt haben, dass alle Mitglieder bei Selektion markiert sind (oder eine Selektionsbox drumrum haben oder so), man könnte Gruppen gruppieren (also verschachteln), Gruppen zum Bearbeiten öffnen und wieder schließen, ohne dass man sie gleich ungruppieren muss, etc. Erstens schreibe ich dir zum 1000 male das ich das weiß und zweitens interessiert das jetzt garnicht. Der Normale Mapper ist froh wenn er ein Gebäudepolygon zusammen hat. In Grundstücken braucht man in der Breite noch nicht zu denken. Das machst du, ich machs auch, vielleicht noch zehn oder zwanzig andere. Die Masse packt es mangeles besserer Daten ans Haus oder einen Node. wenn man sich hier schon grundlegende Gedanken macht, kann man ruhig auch gleich sinnvolle Hierarchien vorschlagen, also z.B. Grundstück Gebäude Einheit (Laden, Wohnung, Büroeinheit) ggf. Untereinheit (Raum, Zimmer, Saal) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
m.E. rufst Du im Endeffekt nach einem einfachen Typ von Relation (der einfach ist, da er eingeschränkte Möglichkeiten hat, und z.B. nur eine feste Art von Rolle, um die man sich nicht kümmern braucht, weil der Editor das macht, könnte man z.B. Gruppe nennen) mit bedienerfreundlicher Editorunterstützung. Nichts dagegen, im Gegenteil, nur solange man das nicht programmiert bleibt es halt Wunschdenken. Meine Überlegung hat so garnichts mit einer Relation zu schaffen. Das wäre eigentlich nur eine Erweiterung der Objekte die wir haben. Völlig unabhängig von Relationen. Die sollen ja vorhande Objekte ansich fassen. Ich will die Möglichkeiten des Objektes selbst etwas erweitern. Wir haben jetzt z.B. ein Gebäude mit seinen üblichen Eigenschaften: way id='123456' version='1' nd ref='1' / nd ref='2' / nd ref='3' / nd ref='4' / tag k='building' v='yes' / tag k='addr:postcode' v=12345' / tag k='addr:country' v='DE' / tag k='addr:street' v='Straße' / tag k='addr:city' v='Musterstadt' / tag k='addr:housenumber' v='1' / /way Dieses Konstrukt ist natürlich begrenzt. Du kannst ihm nicht zweimal amenity, phone whatever verpassen. Ein Tag geht nur einmal, ein zweiter Wert würde den alten einfach überschreiben. Zu der Zeit wo man noch andere Sorgen und wenige Details hatte hats gereicht. Deswegen sind wir gezwungen alles einzeln abzulegen, gewisse Redundanzen zu schaffen, Krücken wie die Semikolongeschichte zu bauen und das dann ggf. wieder über ein neues Objekt, eben die Relation, wieder zu vereinen. Damit fahren wir aber eigentlich mit Kirche, Marktplatz und Rathaus ums Dorf. Nun meine Überlegung. Warum erweitern wir nicht einfach das Objekt selbst und ermöglichen so mit zusätzlichen Sets, Groups, Name Wumpe, die Eigenschaften gleich direkt am Objekt zu belassen, vermeiden Redundanzen und erschlagen Krücken durch Tagüberschneidungen? Das könnte jetzt mal vereinfacht so aussehen: way id='123456' version='1' nd ref='1' / nd ref='2' / nd ref='3' / nd ref='4' / tag k='building' v='yes' / tag k='addr:postcode' v=12345' / tag k='addr:country' v='DE' / tag k='addr:street' v='Straße' / tag k='addr:city' v='Musterstadt' / tag k='addr:housenumber' v='1' / object group id='123456.001' / tag k='amenity' v='bank' / object group id='123456.001' / object group id='123456.002' / tag k='amenity' v='bank' / object group id='123456.002' / /way Ich weiß nun nicht wie schwierig das ist um es in einer zukünftigen API vorzusehen. Ansich wäre es ja nur eine neue Tagrule und eine Erweiterung der ID, um die Gruppen Sub ID anhängen zu können. Ich denke mal die IDs sind begrenzt, wo es haken wird. Das schwierigste wird die Umsetzung im Editor sein. Aber wenn ich den Relationseditor sehe, scheint es da fähige Leute zu geben die das können. Dann ist natürlich auch die Frage wie Renderer das dann auswerten. Nur schlimmer kann es für die im Grunde auch nicht kommen. Die haben meist unzusammenhängende POI Wolken liegen und müssen herumrechnen, verdrängen etc. Vielleicht würde eine saubere Gruppierung sogar eine besser Grundlage schaffen. wenn man sich hier schon grundlegende Gedanken macht, kann man ruhig auch gleich sinnvolle Hierarchien vorschlagen, also z.B. Grundstück Gebäude Einheit (Laden, Wohnung, Büroeinheit) ggf. Untereinheit (Raum, Zimmer, Saal) Um Grundstücke gehts wie gesagt erstmal garnicht. Sondern um das Problem mit dutzenden Nutzungen im eigentlichen Gebäude oder anderen Objekte und eben die damit auflaufenden Probleme. Grundstücke sind wieder ne andere Geschichte. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am 8. Februar 2010 02:53 schrieb Mirko Küster webmas...@ts-eastrail.de: Meine Überlegung hat so garnichts mit einer Relation zu schaffen. Das wäre eigentlich nur eine Erweiterung der Objekte die wir haben. Völlig unabhängig von Relationen. Die sollen ja vorhande Objekte ansich fassen. Ich will die Möglichkeiten des Objektes selbst etwas erweitern. ich denke, wir schreiben da etwas aneinander vorbei, IMHO beschreibst Du einen Typ Relation, indem Du dem Way die Fähigkeiten von Relationen geben willst (Du nennst die Relation Way, aber im Prinzip ist es eine Relation, die zusätzlich zu den Nodes auch noch Ways enthält. Wenn Du die Nodes und die Richtung weglassen würdest, wäre es nicht so kompliziert ;-) Dieses Konstrukt ist natürlich begrenzt. Du kannst ihm nicht zweimal amenity, phone whatever verpassen. ... Krücken wie die Semikolongeschichte zu bauen die Lösung hast Du ja selbst schon geschrieben: mit dem Semikolon als Trenner kann man mehrere Werte an einen Schlüssel hängen. Die Nachteile sind, dass man a) bei den übrigen Tags z.T. nicht klar ist, für welchen Wert sie gelten sollen (oder für alle?) b) die derzeitigen Anwendungen nicht damit klar kommen Dann ist natürlich auch die Frage wie Renderer das dann auswerten. um Renderer geht es hier m.E. nur nachgeordnet Um Grundstücke gehts wie gesagt erstmal garnicht. Sondern um das Problem mit dutzenden Nutzungen im eigentlichen Gebäude oder anderen Objekte und eben die damit auflaufenden Probleme. Grundstücke sind wieder ne andere Geschichte. Sobald Du von Adressen und Hausnummern sprichst, geht es im Prinzip um Grundstücke. Solange man die nicht hat oder grob rekonstruieren kann (geht oft über Zäune, Mauern und andere Grenzen, auch wenn das nicht zwangsläufig parzellenscharf ist), kann man die Information auch als Punkt anbringen, oder eben an andere POI oder Gebäudeumrisse dort hängen. Das kann m.E. aber nur ein Zwischenschritt sein, als Ziel sehe ich schon die Grundstücke - die sind in unserer Weltordnung nunmal die Einheit in diesem Bereich: Häuser kommen und gehen, Grundstücke sind erstaunlich konstant (klar, es gibt auch Gegenbeispiele wie z.B. Flurbereinigung, das sind aber langsame, seltene (derzeit) und transparente (idealerweise) Prozesse, die öffentlich ablaufen). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
ich denke, wir schreiben da etwas aneinander vorbei, IMHO beschreibst Du einen Typ Relation, indem Du dem Way die Fähigkeiten von Relationen geben willst (Du nennst die Relation Way, aber im Prinzip ist es eine Relation, die zusätzlich zu den Nodes auch noch Ways enthält. Wenn Du die Nodes und die Richtung weglassen würdest, wäre es nicht so kompliziert ;-) Ja, im übergeordneten Sinn ist es eine Relation aber diese Erweiterung des eigentlichen Objektes hat nichts mit der in OSM gebräuchlichen Form einer Relation zu tun. Der Way wird nur um eine Schachtel erweitert, statt dafür wieder eine eigene extra Relation zu benutzen. Ich würde das Kind dann auch gerne von dieser Bezeichnung fernhalten, das alleine lässt manchen schon wegrennen. Teilweise zu Recht. die Lösung hast Du ja selbst schon geschrieben: mit dem Semikolon als Trenner kann man mehrere Werte an einen Schlüssel hängen. Die Nachteile sind, dass man a) bei den übrigen Tags z.T. nicht klar ist, für welchen Wert sie gelten sollen (oder für alle?) b) die derzeitigen Anwendungen nicht damit klar kommen Eben deswegen ist das Semikolon eine Krücke und keine Lösung, sollte es auch nicht werden. Bei mehreren Werten muss der Anwender peinlich darauf achten das Werte in der richtigen Reihenfolge zueinander stehen. Aus der Praxis wissen wir wie anfällig sowas ist. Semikolon ist eine Sackgasse und halbgare Notlösung. Das müsste man mal richtig an den Eiern packen. Sobald Du von Adressen und Hausnummern sprichst, geht es im Prinzip um Grundstücke. Zum x ten male. Es geht mir nicht um Grundstücke und deren Nummern. Grundstücke und deren Grenzen sind Luxusdetails die nur wenige bringen können. Wer solche Daten erbringt der weiß auch wie, die Masse interessierts erstmal nicht. Die ist froh eine Gebäudekoordinate oder sogar eine Form zu haben. Da klemmts erstmal primär. Grundstücke werden für die Masse erst interesannt, wenn es auch entsprechende Grundlagen gibt. Beispielsweise flächendeckende Luftbilder. Abseits der Ballungsgebiete wirds da auch zukünftig zappenduster aussehen. AeroWest nützt mir z.B. garnichts. Alte Goggle Bilder bedingt, da hats hier seit jeher nur für die 10 Jahre alten gereicht. Bleiben nur die LVA, aber da wird man noch lange nichts reißen. Oberpfalz war Glück. Bayern kann es sich leisten, andere müssen Geld verdienen. Es ging hier um Kontaktdetails und eben Probleme wie Tagüberschneidungen. Ja, Adressen = Grundstück, haben wir bis zum erbrechen durchgekaut. 99% können aber Grundstück nicht und haben nur Gebäude (Koordinate). Erstmal muss man das Gebäude und anderes lösen. Und das mit einer Methode, bei der auch Joe the Mapper problemlos loslegen kann. Auch wenn das manche hier immer wieder gerne ausblenden. Die Masse sind hier keine Informatiker oder Profis. Über weitergehendes wie aus Daten ne Karte machen reden wir gleich garnicht. Da verzweifle ich aktuell alle 5 Minuten dran. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] addr:phone vs. phone
Am Montag 08 Februar 2010 02:53:45 schrieb Mirko Küster: Nun meine Überlegung. Warum erweitern wir nicht einfach das Objekt selbst und ermöglichen so mit zusätzlichen Sets, Groups, Name Wumpe, die Eigenschaften gleich direkt am Objekt zu belassen, vermeiden Redundanzen und erschlagen Krücken durch Tagüberschneidungen? +1 Das könnte jetzt mal vereinfacht so aussehen: way id='123456' version='1' nd ref='1' / nd ref='2' / nd ref='3' / nd ref='4' / tag k='building' v='yes' / tag k='addr:postcode' v=12345' / tag k='addr:country' v='DE' / tag k='addr:street' v='Straße' / tag k='addr:city' v='Musterstadt' / tag k='addr:housenumber' v='1' / object group id='123456.001' / tag k='amenity' v='bank' / object group id='123456.001' / object group id='123456.002' / tag k='amenity' v='bank' / object group id='123456.002' / /way ich nehme mal an, das 123456 in den groups bezieht sich auf die way id. dann kannst du die genauso gut weglassen, denn die ist durch den way ja bereits gegeben (zumindest in der xml-darstellung; wie das die datenbank speichert - keine ahnung). aber die idee, tags innerhalb eines objekts - sei es jetzt node oder way - zu gruppieren, ist etwas, das ich schon lange vermisse. bisher versucht man sowas mehr schlecht als recht in das key/value-schema zu pressen. manche versuchen das auch mit semikolons. als reine auflistung, was fuer viele faelle ausreichend ist, finde ich das durchaus sinnvoll, aber sobald man eben verschiedene attribute gruppieren oder sortieren will, braucht's was anderes. andererseits, wenn ich's mir recht ueberlege, ist das sehr aehnlich zu relationen, aber doch etwas anders... ich bin dafuer, neben node,way und relation den typ group einzufuehren, der nichts anderes macht, als zusammengehoerende attribute eines objekts zu gruppieren. das wuerde nebenbei auch einige probleme mit vielen pseudo-keys erschlagen, die man dann gar nicht mehr braucht... Um Grundstücke gehts wie gesagt erstmal garnicht. Sondern um das Problem mit dutzenden Nutzungen im eigentlichen Gebäude oder anderen Objekte und eben die damit auflaufenden Probleme. Grundstücke sind wieder ne andere Geschichte. grundstuecke sind eben keine andere geschichte! ob jetzt gebaeude, grundstueck, briefkasten oder schiessmichtot, es sind alles objekte mit eigenschaften. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
