Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 15.12.2012 07:59, Günther Zin. wrote:

Gibt's da für solche Auswertungen, die sicher nicht täglich gemacht
werden, dann nicht (z.B. in Postgis) wunderbare Funktionen zur
Umkreissuche (z.B. Radius- oder Box-Definition) oder die Prüfung, ob ein
Node in einer Fläche ist?


Wenn es solche Funktionen nicht gibt, kann man sie sich schreiben. Nur wirst 
du aus der Distanz zwischen 2 Nodes keine eindeutigen Schlüsse ziehen können.



Bei solchen Auswertung halte ich die Verwendung
von Site-Relationen auch für vertretbar.


Site-Relationen geben an, was zusammengehört, nicht was am selben Ort ist. 
Du müsstest schon beide obigen Ansätze kombinieren, und das alles nur weil 
dir der Strichpunkt nicht gefällt.



Es ist auch möglich, im Renderer eine eigene Signatur zu definieren für
  kombinierte Bank+Post-Filialen.


Gute Idee. Dann machen wir auch gleich eine eigene Signatur für
Tankstelle+Post, eine für Tankstelle+Supermarkt, eine für Trafik+Post,
eine für Bäcker+Post, eine für Supermarkt+Post usw.


Wer ist "wir"? In einer Openpostmap wird das alles erwünscht sein.

--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Günther Zin .]

Am Fr, 14.12.2012, 18:14, schrieb Friedrich Volkmann:
> On 14.12.2012 12:31, Günther Zin. wrote:
>
>> Wo ist das denn wirklich wichtig zu wissen, dass beide im gleichen
>> Laden beisammen sind?
>>
>
> Z.B. damit man mit einer Auswertung die Filialen herausfinden kann, wo
> beide beisammen sind.

Gibt's da für solche Auswertungen, die sicher nicht täglich gemacht
werden, dann nicht (z.B. in Postgis) wunderbare Funktionen zur
Umkreissuche (z.B. Radius- oder Box-Definition) oder die Prüfung, ob ein
Node in einer Fläche ist? Bei solchen Auswertung halte ich die Verwendung
von Site-Relationen auch für vertretbar.
Die wichtigere Frage ist meiner Ansicht nach aber: was gibt's in dieser
Gegend, und nicht ob beides am selben Schalter behandelt wird.

> Und auch weil es klarer ist:  1 Objekt real <-> 1 Objekt in OSM
>
>
> Es ist auch möglich, im Renderer eine eigene Signatur zu definieren für
>  kombinierte Bank+Post-Filialen.

Gute Idee. Dann machen wir auch gleich eine eigene Signatur für
Tankstelle+Post, eine für Tankstelle+Supermarkt, eine für Trafik+Post,
eine für Bäcker+Post, eine für Supermarkt+Post usw.


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 14.12.2012 12:31, osmgz wrote:

Zwei amenity nodes
(nebeneinander um das weitere Editieren nicht unnötig zu verkomplizieren;
die Filiale hat ja eine physikalische Ausdenhung, deswegen hat man ja etwas
Spielraum beim Platzieren der POIs), die über eine Relation verbunden sind.


Nein, den Spielraum hat man nicht, denn der Node soll in der Mitte liegen,
oder vielleicht in der Nähe des Eingangs, jedenfalls nicht irgendwo.


Wieso hat man den Spielraum nicht? Ist doch meiner Ansicht nach egal, ob der 2. 
Node dann 3m weiter rechts ist. Das Bedienpult für Postverkehr kann durchaus im 
Geschäft an einer anderen Stelle sein.


Ist es im konkreten Fall nicht.  Hier ist die Position in der Realität genau 
die selbe, und daher sollte sie auch in OSM die selbe sein.


Wenn es 2 verschiedene Schalter sind, muss man halt nach den Umständen 
entscheiden.



Wusste gar nicht, dass Normalisierungen bei OSM eine derart starke Rolle 
einnehmen.


Tun sie eh nicht. Aber *wenn* man den Strichpunkt wegen 
Normalisierungsregeln ablehnt (Mail von Erwin am 11.12. um 05:51), dann muss 
man das gleiche auch mit die Alternativen tun.



In anderen Bereichen wird bewusst auf Redundanz gesetzt, um die 
Übersichtlichkeit zu steigern.


Ich bin generell ein Gegner von Redundanz, aber das wär eine andere Diskussion.


Wo ist das denn wirklich wichtig zu wissen, dass beide im gleichen Laden 
beisammen sind?


Z.B. damit man mit einer Auswertung die Filialen herausfinden kann, wo beide 
beisammen sind.


Und auch weil es klarer ist:  1 Objekt real <-> 1 Objekt in OSM

Es ist auch möglich, im Renderer eine eigene Signatur zu definieren für 
kombinierte Bank+Post-Filialen.



Meine andere Frage nochmals: wie taggt man dann unterschiedliche Öffnungszeiten 
für die beiden übersichtlich, so dass die Öffnungszeiten dann auch noch 
maschinell auswertbar bleiben?
(das ist nicht aus der Luft gegriffen; siehe mein anderes Mail dazu)
Es gibt sicher auch noch andere Tags (z.B. "brand", "name") die unterschiedlich 
sein können.


In so einem Fall wird man wohl 2 Nodes machen müssen. Oder wenn möglich 1 
Fläche für die Hauptfunktion und 1 Node für die Nebenfunktion.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[osmgz]

 Hallo!
 
 
Am Freitag, 14. Dezember 2012 01:36 CET, Friedrich Volkmann  
schrieb: 
 
> On 13.12.2012 12:19, Martin Raifer wrote:
> > Zwei amenity nodes
> > (nebeneinander um das weitere Editieren nicht unnötig zu verkomplizieren;
> > die Filiale hat ja eine physikalische Ausdenhung, deswegen hat man ja etwas
> > Spielraum beim Platzieren der POIs), die über eine Relation verbunden sind.
> 
> Nein, den Spielraum hat man nicht, denn der Node soll in der Mitte liegen, 
> oder vielleicht in der Nähe des Eingangs, jedenfalls nicht irgendwo.

Wieso hat man den Spielraum nicht? Ist doch meiner Ansicht nach egal, ob der 2. 
Node dann 3m weiter rechts ist. Das Bedienpult für Postverkehr kann durchaus im 
Geschäft an einer anderen Stelle sein.

> Man müsste die Nodes deckungsgleich platzieren, und das läuft gerade der 
> Normalisierung entgegen, die als Argument gegen die Strichpunktnotation 
> erachtet wurde. Genauer gesagt ist die 4.NF verletzt, da die Nodes die 

Wusste gar nicht, dass Normalisierungen bei OSM eine derart starke Rolle 
einnehmen. In anderen Bereichen wird bewusst auf Redundanz gesetzt, um die 
Übersichtlichkeit zu steigern.

> gleichen Koordinaten haben. Für die Normalisierung müsste man einen einzigen 
> Node anlegen mit Koordinaten und Name, und 2 Relationen, davon eine für 
> amenity=bank und eine für amenity=post_office, jeweils nur mit dem einen 
> Node als Member. Ob die zwei Relationen übersichtlicher oder leichter zu 
> editieren sind als ein Tag mit Strichpunkt, sei dahingestellt. Sicher ist, 
> dass weder ein Tool noch ein Renderer diese Relation derzeit unterstützt, 
> und somit ist eine mangelnde Unterstützung des Strichpunkts kein Argument.

Um beide Einzelsymbole (wenn sich nicht allzu nah beieinander sind) in der 
Karte angezeigen zu lassen braucht es keine Unterstützung für die Relationen 
oder ein doppeltes amenity-Tag.
Und dass beide Nodes an exakt der selben Position sind, ist keine gute Idee. Da 
sind wir uns einig.

Wo ist das denn wirklich wichtig zu wissen, dass beide im gleichen Laden 
beisammen sind?

> > Bei dem Thread hier ging
> > es aber darum, ein Problem im aktuell bestehenden OSM-Universum bestmöglich
> > zu lösen.
> 
> Siehe oben - das OSM-Universum lässt keine bessere Lösung als die 
> Strichpunkt-Notation zu.

Zulassen? Gibt es nur eine Lösung? Meiner Ansicht nach bleibt es eine 
Ermessens-Frage, die jeder Mapper im Einzelfall beantwortet.

Meine andere Frage nochmals: wie taggt man dann unterschiedliche Öffnungszeiten 
für die beiden übersichtlich, so dass die Öffnungszeiten dann auch noch 
maschinell auswertbar bleiben?
(das ist nicht aus der Luft gegriffen; siehe mein anderes Mail dazu)
Es gibt sicher auch noch andere Tags (z.B. "brand", "name") die unterschiedlich 
sein können.

Grüße
Günther

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 13.12.2012 12:19, Martin Raifer wrote:

Zwei amenity nodes
(nebeneinander um das weitere Editieren nicht unnötig zu verkomplizieren;
die Filiale hat ja eine physikalische Ausdenhung, deswegen hat man ja etwas
Spielraum beim Platzieren der POIs), die über eine Relation verbunden sind.


Nein, den Spielraum hat man nicht, denn der Node soll in der Mitte liegen, 
oder vielleicht in der Nähe des Eingangs, jedenfalls nicht irgendwo.


Man müsste die Nodes deckungsgleich platzieren, und das läuft gerade der 
Normalisierung entgegen, die als Argument gegen die Strichpunktnotation 
erachtet wurde. Genauer gesagt ist die 4.NF verletzt, da die Nodes die 
gleichen Koordinaten haben. Für die Normalisierung müsste man einen einzigen 
Node anlegen mit Koordinaten und Name, und 2 Relationen, davon eine für 
amenity=bank und eine für amenity=post_office, jeweils nur mit dem einen 
Node als Member. Ob die zwei Relationen übersichtlicher oder leichter zu 
editieren sind als ein Tag mit Strichpunkt, sei dahingestellt. Sicher ist, 
dass weder ein Tool noch ein Renderer diese Relation derzeit unterstützt, 
und somit ist eine mangelnde Unterstützung des Strichpunkts kein Argument.



Bei dem Thread hier ging
es aber darum, ein Problem im aktuell bestehenden OSM-Universum bestmöglich
zu lösen.


Siehe oben - das OSM-Universum lässt keine bessere Lösung als die 
Strichpunkt-Notation zu.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Norbert Wenzel]

On 12/13/2012 12:19 PM, Martin Raifer wrote:

Am 13.12.2012, 11:20 Uhr, schrieb Norbert Wenzel:

Das Problem dabei hab ich ja schon früher geschrieben: wir haben
leider keinen direkten Zugang auf die Datenbank. Wir dürfen nur
Strings reinwerfen und dabei ist es uns nicht erlaubt zu einem Key
mehrere Values zu speichern. Daher geb ich dir Recht, dass die
Strichpunktnotation eine Krücke ist, aber eben die einzig erlaubte.


Eine zweite Methode hast du ja selbst schon erwähnt: Zwei amenity nodes
(nebeneinander um das weitere Editieren nicht unnötig zu
verkomplizieren; die Filiale hat ja eine physikalische Ausdenhung,
deswegen hat man ja etwas Spielraum beim Platzieren der POIs), die über
eine Relation verbunden sind.


Ja, aber du musst schon alles lesen was ich schreib. Ich schrieb auch, 
warum ich zwei räumlich getrennte Nodes für schlecht halte:


On 12/13/2012 10:37 AM, Norbert Wenzel wrote:> Und wenn die Punkte nicht 
exakt dieselbe Koordinaten haben, dann brauch

> ich erst wieder Heuristiken um zu erkennen, ob diese Punkte noch
> zusammengehören, oder nur sehr nah sind, weil bspw. zwei Geschäfte in
> einem Haus untergebracht sind.

Und wie ich auch schon gesagt hab. Ein Strichpunkt ist wesentlich 
leichter auszuwerten als eine site=* Relation und die braucht man um zu 
erkennen, dass es eben exakt eine Filiale ist und nicht zwei getrennte 
Geschäfte nebeneinander.


Norbert



___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Martin Raifer]

Am 13.12.2012, 11:20 Uhr, schrieb Norbert Wenzel:
Das Problem dabei hab ich ja schon früher geschrieben: wir haben leider  
keinen direkten Zugang auf die Datenbank. Wir dürfen nur Strings  
reinwerfen und dabei ist es uns nicht erlaubt zu einem Key mehrere  
Values zu speichern. Daher geb ich dir Recht, dass die  
Strichpunktnotation eine Krücke ist, aber eben die einzig erlaubte.


Eine zweite Methode hast du ja selbst schon erwähnt: Zwei amenity nodes  
(nebeneinander um das weitere Editieren nicht unnötig zu verkomplizieren;  
die Filiale hat ja eine physikalische Ausdenhung, deswegen hat man ja  
etwas Spielraum beim Platzieren der POIs), die über eine Relation  
verbunden sind.


Wenn du dir OSM Daten lädst und in deine eigene, optimierte Datenbank  
fütterst, dann musst du halt mehrere Values zum selben Key erlauben und  
kannst dann dort indizieren, wie du es für dein Service brauchst.


Schon klar: Das was du beschreibst, meine ich gerade mit "sehr schwierig".  
Vor allem im Vergleich zu bereits etablierten Methoden, sich OSM-Daten zu  
verarbeiten (Overpass-API, XAPI).


Klar kann man darüber diskutieren, multiple Werte bei tag-values in der  
OSM-API zuzulassen. Oder ob man etablierten Tools dahin erweitern sollte,  
die Strichpunkt-Syntax performant zu unterstützen. Das ist aber eine  
technische-Diskussion, die besser z.B. in der dev Liste aufgehoben wäre.  
Tatsache ist, dass beides noch nicht der Fall ist. Bei dem Thread hier  
ging es aber darum, ein Problem im aktuell bestehenden OSM-Universum  
bestmöglich zu lösen.


Grüße
tyr_asd

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Norbert Wenzel]

On 12/13/2012 11:02 AM, Martin Raifer wrote:

Am 13.12.2012, 10:37 Uhr, schrieb Norbert Wenzel
:

[...] aber wenn ich mit den Daten selbst arbeiten will, dann wird's
mitgetrennten Nodes deutlich schwieriger.


Das kann man nicht so verallgemeinern. Es kommt ganz auf die Anwendung
darauf an. Wenn man wissen will, wo sich Bank+Post Kombifilialen
befinden, ist die Strichpunkt-Notation auf dem ersten Blick
vielleicht(!) komfortabler, allerdings ist sie bei dem viel
wahrscheinlicheren Anwendungsfall: "Liste aller Postfilialen in X" mit
Abstand deutlich unterlegen. Und zwar (wie bereits gepostet wurde) wegen
der sehr schwierigen Indizierung der Datenbank nach solchen multiplen POIs.


Das Problem dabei hab ich ja schon früher geschrieben: wir haben leider 
keinen direkten Zugang auf die Datenbank. Wir dürfen nur Strings 
reinwerfen und dabei ist es uns nicht erlaubt zu einem Key mehrere 
Values zu speichern. Daher geb ich dir Recht, dass die 
Strichpunktnotation eine Krücke ist, aber eben die einzig erlaubte.


Wenn du dir OSM Daten lädst und in deine eigene, optimierte Datenbank 
fütterst, dann musst du halt mehrere Values zum selben Key erlauben und 
kannst dann dort indizieren, wie du es für dein Service brauchst.


Und die ganze Indizierung einer Datenbank nach entweder post_office oder 
bank nutzt nichts, wenn ich für eine Bank- & Postfiliale 
amenity=post_and_bank erfinden muss. Oder so abstruse Tagkombinationen 
wie amentiy=bank & postal_service=yes & priority_postal_service = main 
oder sonstwas in der Art.


Wie auch schon weiter oben geschrieben: postal_service ist toll für den 
Fleischhauer der zwei Pakerl am Tag annimmt, aber wenn das Geschäft 
gleichbedeutend Bank und Post ist, dann bleibt imo nur die Erfindung 
einer neuen amenity. Und da würd ich dann doch post_office;bank vor 
post_and_bank bevorzugen.


Norbert


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Martin Raifer]

Am 13.12.2012, 10:37 Uhr, schrieb Norbert Wenzel  
:
[...] aber wenn ich mit den Daten selbst arbeiten will, dann wird's mit 
getrennten Nodes deutlich schwieriger.


Das kann man nicht so verallgemeinern. Es kommt ganz auf die Anwendung  
darauf an. Wenn man wissen will, wo sich Bank+Post Kombifilialen befinden,  
ist die Strichpunkt-Notation auf dem ersten Blick vielleicht(!)  
komfortabler, allerdings ist sie bei dem viel wahrscheinlicheren  
Anwendungsfall: "Liste aller Postfilialen in X" mit Abstand deutlich  
unterlegen. Und zwar (wie bereits gepostet wurde) wegen der sehr  
schwierigen Indizierung der Datenbank nach solchen multiplen POIs.


Ich finde schon, dass die Strichpunkt-Notation ihre Daseinsberechtigung  
hat (z.B. bei Tags wie ref, source, ...), allerdings nicht bei  
klassifizierenden Tags (wie highway, amenity, natural, landuse, usw.)!


Grüße
tyr_asd

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Norbert Wenzel]

On 12/13/2012 10:16 AM, Werner Macho wrote:

Also - wenn zwei nodes am selben Ort sind und beschriftet bzw gezeichnet
werden sollen dann gibts im GIS eigene Algorithmen die das trennen und
nebeneinander darstellen.
Ich weiss zwar nicht ob sowas für OSM schon implementiert ist aber so
schwierig sollte das doch nicht sein oder?


Mapnik hat soweit ich weiß eine einfache first-come first-served Regel 
wo solange gezeichnet wird, solange noch Platz ist.


Aber unabhängig davon was Mapnik macht bringt der Algorithms ja nur was 
fürs Rendern. Aber wenn ich mit den Daten arbeite brauch ich erst wieder 
eine Verbindung dieser beiden Nodes, die mir erlaubt zu erkennen, dass 
es in Wirklichkeit eine Filiale ist.


Da ist ein einfaches Trennen am Semikolon deutlich einfacher und 
schneller als eine site=* Relation o.ä. auszuwerten.
Und wenn die Punkte nicht exakt dieselbe Koordinaten haben, dann brauch 
ich erst wieder Heuristiken um zu erkennen, ob diese Punkte noch 
zusammengehören, oder nur sehr nah sind, weil bspw. zwei Geschäfte in 
einem Haus untergebracht sind.


Also aus Renderingsicht ist es wohl egal ob man die Nodes trennt (und 
man kann immer noch "schöne" Karten erstellen) aber wenn ich mit den 
Daten selbst arbeiten will, dann wird's mit getrennten Nodes deutlich 
schwieriger.


Norbert


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Werner Macho]

Hi!

Also - wenn zwei nodes am selben Ort sind und beschriftet bzw gezeichnet
werden sollen dann gibts im GIS eigene Algorithmen die das trennen und
nebeneinander darstellen.
Ich weiss zwar nicht ob sowas für OSM schon implementiert ist aber so
schwierig sollte das doch nicht sein oder?

lg Werner


2012/12/13 Norbert Wenzel 

> On 12/13/2012 09:31 AM, Andreas Labres wrote:
>
>> Was würdest Du Dir vom Renderer erwarten, wenn Du amenity=bank;post_office
>> schreibst? Dass er die beiden Icons hernimmt und ein neues, kombiniertes
>> draus
>> macht?
>>
>
> Vom Renderer erwart ich mir gar nichts. Das ist dasselbe wie zwei Nodes
> knapp nebeneindander zu setzen. Einer gewinnt bzw. beide sind nicht
> erkennbar weil übereinander gezeichnet. Beides wird der Filiale genauso
> nicht gerecht.
>
> Ich denke aber einem User der Daten ist es zumutbar am Semikolon zu
> trennen und sich dann dafür zu entscheiden was er will (oder im Bedarf auch
> beides speziell zu kennzeichnen, weil ihn gerade diese
> Gemeinschaftsfilialen interessieren).
> OT: Imo sollte das OSM XML wenn es vom Server generiert wird automatisch
> trennen und dann halt an einem Node zwei Tags mit amenity=* erzeugen
> solange es keine andere Möglichkeit gibt mehrere gleiche Daten an ein
> Objekt zu hängen.
>
> Norbert
>
>
> __**_
> Talk-at mailing list
> Talk-at@openstreetmap.org
> http://lists.openstreetmap.**org/listinfo/talk-at
>
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Norbert Wenzel]

On 12/13/2012 09:31 AM, Andreas Labres wrote:

Was würdest Du Dir vom Renderer erwarten, wenn Du amenity=bank;post_office
schreibst? Dass er die beiden Icons hernimmt und ein neues, kombiniertes draus
macht?


Vom Renderer erwart ich mir gar nichts. Das ist dasselbe wie zwei Nodes 
knapp nebeneindander zu setzen. Einer gewinnt bzw. beide sind nicht 
erkennbar weil übereinander gezeichnet. Beides wird der Filiale genauso 
nicht gerecht.


Ich denke aber einem User der Daten ist es zumutbar am Semikolon zu 
trennen und sich dann dafür zu entscheiden was er will (oder im Bedarf 
auch beides speziell zu kennzeichnen, weil ihn gerade diese 
Gemeinschaftsfilialen interessieren).
OT: Imo sollte das OSM XML wenn es vom Server generiert wird automatisch 
trennen und dann halt an einem Node zwei Tags mit amenity=* erzeugen 
solange es keine andere Möglichkeit gibt mehrere gleiche Daten an ein 
Objekt zu hängen.


Norbert


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Andreas Labres]

Was würdest Du Dir vom Renderer erwarten, wenn Du amenity=bank;post_office
schreibst? Dass er die beiden Icons hernimmt und ein neues, kombiniertes draus
macht?

Ich halte die zwei POIs schon für das probateste Mittel. Sonst müsste man ein
amenity=post_and_bank erfinden... und das war früher bei jedem Postamt so,
vielleicht geht's dort über kurz oder lang eh wieder hin...

/al

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Norbert Wenzel]

On 12/13/2012 08:55 AM, Andreas Labres wrote:

Also für so "Gemeinschaftsfilialen" von Bawag-PSK und (echtem) Postamt würde ich
zwei POIs setzen, damit kann ein Renderer wiedergeben, dass es dort eine Bank
/und/ ein Postamt gibt, eine Suchfunktion (z.B. eines Navis) funktioniert usw.


Aber damit führst du einen Fehler in den Daten ein, nur weil der/die 
Renderer dumm sind. Denn eine Gemeinschaftsfiliale ist ja *eine* 
Filiale, an einem Punkt mit einer Adresse usw. Das entspricht ja dann 
dem von mir scherzhaft vorgeschlagenem Taggen der linken und rechten 
Lade unterm Schalter, wo die eine für die Post und die andere für die 
Bank ist.


Das kann ja auch nicht der Weisheit letzter Schluss sein denk ich.

Norbert


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Andreas Labres]

Also für so "Gemeinschaftsfilialen" von Bawag-PSK und (echtem) Postamt würde ich
zwei POIs setzen, damit kann ein Renderer wiedergeben, dass es dort eine Bank
/und/ ein Postamt gibt, eine Suchfunktion (z.B. eines Navis) funktioniert usw.

/al

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Günther Zin .]

Hallo!

Am Mi, 12.12.2012, 09:13, schrieb Daniel Kraft:
> Allerdings kenne ich auch Fälle von solchen Post-Partnern, wo es
> durchaus Sinn machen würde, zu taggen, dass "zusätzlich" postal_service
> angeboten wird.  (Das Beispiel, das ich im Hinterkopf habe, ist der Spar
> in Hieflau; dort ist derzeit ein eigener Node für das post_office
> innerhalb des building für den Spar gesetzt.)

Die Idee mit dem zusätzlichen Node ist keine schlechte Idee, finde ich.
Bei uns gibt es einen Post-Partner (Tankstelle), die zwar Post-Dienste
anbietet, aber zu anderen (eingeschränkten) Zeiten als den
Tankstellenbetrieb. Wie sollte das dann beim selben Node ausschauen
(postal_services:opening_hours=... ?)
Bei dieser Tankstelle ist es übrigens zwar die selbe Person aber ein
eigener Schalter, bei dem man sich getrennt anstellen muss.
Erledigt später mal eine andere Firma die Postdienste, muss man diesen
einen Node (mit PLZ usw.) nur zur anderen Firma weiterschieben.

Ich bin für den eigenen Node.

Grüße,
Günther


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Daniel Kraft]

On 12.12.2012 08:51, caigner wrote:
> Nachdem die Postfiliale in Kaltenleutgeben zugesperrt wurde, gibt es jetzt 
> eine Trafik im Ort, die
> Post-Services anbietet.
> Also wäre so ein postal_service=yes gar keine so schlechte Idee.

Find ich auch!

Zwar denke ich, dass die Antwort auf meine ursprüngliche Frage wirklich
eher ein gleichbedeutendes amenity=bank;post_office ist (da es bei der
Bawag PSK, so wie ich es sehe, wirklich zwei gleichbedeutende Aufgaben
sind, die an ein und demselben Schalter (auch nicht zwei Hälften ;))
erfüllt werden.

Allerdings kenne ich auch Fälle von solchen Post-Partnern, wo es
durchaus Sinn machen würde, zu taggen, dass "zusätzlich" postal_service
angeboten wird.  (Das Beispiel, das ich im Hinterkopf habe, ist der Spar
in Hieflau; dort ist derzeit ein eigener Node für das post_office
innerhalb des building für den Spar gesetzt.)

Liebe Grüße,
Daniel

-- 
http://www.domob.eu/
OpenPGP: 3316 E372 FA0F A249 CEC2  A750 1D5C 2AF7 05C5 F263
--
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[caigner]

Nachdem die Postfiliale in Kaltenleutgeben zugesperrt wurde, gibt es jetzt eine 
Trafik im Ort, die
Post-Services anbietet.
Also wäre so ein postal_service=yes gar keine so schlechte Idee.

LG,
Christian

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 12.12.2012 05:53, Erwin Pleyer wrote:

Nochmal ein Bsp.
Source=survey; geoimage.de 
.de ist natürlich falsch.
Update tab_xy set source=geoimage.at  where source like
?geoimage.de 
Dieses Update würde zwar das .de ersetzen, es wären aber alle anderen
sources weg.


update tab_xy set source=replace(source,'geoimage.de 
','geoimage.at ')


Mit regular expressions geht es noch sauberer.

--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Norbert Wenzel]

On 12/12/2012 05:53 AM, Erwin Pleyer wrote:

Nochmal ein Bsp.
Source=survey; geoimage.de 
.de ist natürlich falsch.
Update tab_xy set source=geoimage.at  where source
like ?geoimage.de 
Dieses Update würde zwar das .de ersetzen, es wären aber alle anderen
sources weg. Es konnte durchaus auch Bing;geoimage.de
 heißen, viele Möglichkeiten gibt es.
Ein Update würde daher mehr kaputt machen.


Naja, wenn man falschen Code schreibt, dann kommt Mist raus. Wenn ich rm 
-Rf / eingeb, dann ist auch die Datenbank hin und das ist nicht das 
Problem der Strichpunktnotation.


Soll heißen, wenn ich mit strichpunktgetrennten Werten rechnen muss (und 
ja, das muss ich in OSM im Moment auf jeden Fall) dann kann ich so ein 
Update einfach nicht schreiben. Es komplizierter zu machen ist natürlich 
nicht mehr so schnell, aber Effizienz ist ja nicht die absolute Zeit die 
ein Befehl braucht sondern das Verhältnis zur Minimalzeit die ein Befehl 
brauchen kann um eine Operation *richtig* und *vollständig* zu 
durchzuführen.


Im konkreten Fall denk ich ist das postal_service Tag eine gute Idee, 
wenn der Fleischhauer im Ort der nebenbei zwei Packerl am Tag annimmt 
tatsächlich keine vollwertige Postfiliale ist. Für solche Fälle bietet 
sich das Zusatztag einfach an. Wie das bei den neuen Bawag/Post-Filialen 
ist weiß ich nicht. Da könnte es imo sein, dass es eine vollwertige 
Postfiliale und eine vollwertige Bawagfiliale ist die sich räumlich 
tatsächlich am selben Punkt befindet. Das spräche dann doch wieder dafür 
die amenities gleichberechtigt per Semikolon zu trennen.


Das ist natürlich alles aus DB Sicht nicht schön und schon gar nicht die 
reine Lehre, aber da wir halt in OSM erstmal keinen direkten Zugriff auf 
die DB haben sondern einen Datensatz bekommen bzw. eingeben können der 
ausschließlich aus Key=Value Paaren besteht, bleibt einem nichts anderes 
übrig als die Werte, die sich auf ein Objekt beziehen in einem Value zu 
trennen.


Also mir erscheinen diese Semikola auf jeden Fall besser als entweder 
zwei künstliche Nodes zu erzeugen für ein physisches Objekt (ok, man 
könnte sagen die linke Lade am Schalter gehört zur Post und die rechte 
zur Bawag, aber das ist irgendwie sinnlos) oder eben ein *willkürliche* 
Reihung vorzunehmen, was die Hauptfunktion eines Geschäfts ist und was 
nur nebenbei rennt. Wenn das nicht offensichtlich ist, wie beim 
Fleischhauer im Beispiel oben, dann würde mich diese bewusste 
Ungenauigkeit in den Daten, nur um Leuten das Parsen zu vereinfachen, 
auf jeden Fall mehr stören, als dass der Aufwand ein korrektes Parsing 
zu schreiben. ("Wir taggen nicht für den Renderer und schon gar nicht 
für faule Programmierer". ;-))


Norbert


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Erwin Pleyer]

Nochmal ein Bsp.
Source=survey; geoimage.de
.de ist natürlich falsch.
Update tab_xy set source=geoimage.at where source like ?geoimage.de
Dieses Update würde zwar das .de ersetzen, es wären aber alle anderen sources 
weg. Es konnte durchaus auch Bing;geoimage.de heißen, viele Möglichkeiten gibt 
es.
Ein Update würde daher mehr kaputt machen.




Friedrich Volkmann  schrieb:

On 11.12.2012 21:59, Erwin Pleyer wrote:
> Beispiel: Update tab_xy Set vehicle = Landwirtschaft where vehicle like
> “?agriculture?“
> Ich weiß, der Syntax stimmt nicht zu 100 Prozent, aber wie schön gesagt,
> Update-abfragen können nicht eindeutig angewandt werden.

Verstehe ich nicht genau. Wo ist das Problem bei so einem Update, und wofür 
brauchst du den überhaupt?

> Sortierungen können auf den Tag mit 2 werten durch ; getrennt nicht
> angewandt werden.

Nochmal: Was ist die Alternative?

> Zumindest nicht per Datenbank-abfragen, per Scripte geht viel mehr, macht es
> aber um vieles schwieriger und für viele nicht anwendbar.

Für Datenbankabfragen brauchst du auch schon irgendeine Form von Script.

> Noch eine frage, wie willst du verschiedene Operatoren von den Banken oder
> der Post eindeutig zuweisen, wenn sie durch ; getrennt sind? Sicher,
> 1 Operator zu 1 amenity, wieder ein Script nötig. Wer garantiert die richtige
> Reihenfolge in den Tags?

Im konkreten Fall gibt es nur 1 Operator, nämlich die BAWAG PSK. Es ist ja 
nicht so, dass vormittags einer von der BAWAG am Schalter sitzt und 
nachmittags einer von der PSK, sondern es ist ein und dasselbe Unternehmen.

-- 
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

_

Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 11.12.2012 21:59, Erwin Pleyer wrote:

Beispiel: Update tab_xy Set vehicle = Landwirtschaft where vehicle like
“?agriculture?“
Ich weiß, der Syntax stimmt nicht zu 100 Prozent, aber wie schön gesagt,
Update-abfragen können nicht eindeutig angewandt werden.


Verstehe ich nicht genau. Wo ist das Problem bei so einem Update, und wofür 
brauchst du den überhaupt?



Sortierungen können auf den Tag mit 2 werten durch ; getrennt nicht
angewandt werden.


Nochmal: Was ist die Alternative?


Zumindest nicht per Datenbank-abfragen, per Scripte geht viel mehr, macht es
aber um vieles schwieriger und für viele nicht anwendbar.


Für Datenbankabfragen brauchst du auch schon irgendeine Form von Script.


Noch eine frage, wie willst du verschiedene Operatoren von den Banken oder
der Post eindeutig zuweisen, wenn sie durch ; getrennt sind? Sicher,
1 Operator zu 1 amenity, wieder ein Script nötig. Wer garantiert die richtige
Reihenfolge in den Tags?


Im konkreten Fall gibt es nur 1 Operator, nämlich die BAWAG PSK. Es ist ja 
nicht so, dass vormittags einer von der BAWAG am Schalter sitzt und 
nachmittags einer von der PSK, sondern es ist ein und dasselbe Unternehmen.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 11.12.2012 20:51, David Hopfmueller wrote:

Zumindest auf Ebene des DBMS hat Erwin nicht Unrecht, wenn einer der
durch das Semikolon getrennten Werte als Filter verwendet werden soll.
Da bleibt Dir nämlich nur mehr ein teures LIKE, egal ob beim Auswerten
(SELECT) oder Pflegen (UPDATE).


Das ist SQL. OSM ist zunächst mal ein Datenbestand, der an keine spezielle 
Datenbank gebunden ist. Auf openstreetmap.org sind die Daten in einer 
PostgreSQL-Datenbank gespeichert, aber runterladen tust du sie als XML, und 
du kannst das XML direkt auswerten (z.B. mit DOM in einer beliebigen 
Programmiersprache) oder in ein anderes XML umformen oder in eine Oracle DB 
speichern oder wieder in Postgre oder wohin auch immer. Auswertung mittels 
SQL ist also nur eine von vielen Möglichkeiten.


Speziell zu LIKE ist zu sagen: Wenn es "teuer" ist, dann in der Performance, 
nicht wie vorhin behauptet hinsichtlich Schwierigkeit.


Und selbst die Performance muss nicht schlecht sein, es gibt function based 
indexes und in Oracle zusätziich text indexes. Aber das ist eh alles egal, 
denn zeitkritische Anwendungen gehen sowieso auf aufbereitete Daten.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Erwin Pleyer]

Noch eine frage, wie willst du verschiedene Operatoren von den Banken oder der 
Post eindeutig zuweisen, wenn sie durch ; getrennt sind? Sicher, 1 Operator zu 
1 amenity, wieder ein Script nötig. Wer garantiert die richtige Reihenfolge in 
den Tags?

Schönen Abend noch
Erwin




David Hopfmueller  schrieb:

Friedrich Volkmann wrote:
> On 11.12.2012 19:10, Erwin OSM wrote:

>> Nur weil die Strichpunkt-Notation üblich ist, muss sie eben noch lange
>> nicht
>> gut sein. Ich bin der Meinung, dass diese Notation schwer auszuwerten
>> und zu
>> pflegen ist, eine einzelne Erfassung wäre nur von Vorteil.
> Was ist daran schwer auszuwerten? Z.B. in Perl: @werte = split /;/, $wert
> Und warum schwer zu pflegen? Das ist bereits die dritte Behauptung, zu
> der du keine Begründung anführst.

Zumindest auf Ebene des DBMS hat Erwin nicht Unrecht, wenn einer der
durch das Semikolon getrennten Werte als Filter verwendet werden soll.
Da bleibt Dir nämlich nur mehr ein teures LIKE, egal ob beim Auswerten
(SELECT) oder Pflegen (UPDATE).


_

Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Erwin Pleyer]

Beispiel: Update tab_xy Set vehicle = Landwirtschaft where vehicle like 
“?agriculture?“
Ich weiß, der Syntax stimmt nicht zu 100 Prozent, aber wie schön gesagt, 
Update-abfragen können nicht eindeutig angewandt werden.
Sortierungen können auf den Tag mit 2 werten durch ; getrennt nicht angewandt 
werden.
Zumindest nicht per Datenbank-abfragen, per Scripte geht viel mehr, macht es 
aber um vieles schwieriger und für viele nicht anwendbar.




Friedrich Volkmann  schrieb:

On 11.12.2012 19:10, Erwin OSM wrote:
> Am 11.12.2012 09:05, schrieb Friedrich Volkmann:
>> On 11.12.2012 05:51, Erwin Pleyer wrote:
>>> Eines der wichtigen Prinzipien bei Datenbanken ist, niemals mehr als eine
>>> Info in ein Feld zu schreiben! Kann man in allen Lehrbüchern lesen.
>>
>> Dabei geht es um die Normalisierung relationaler Datenbanken. OSM ist
>> keine relationale Datenbank.
>>
>> Außerdem ist die Strichpunkt-Notation in OSM längst üblich. Es gibt keinen
>> Grund, es ausgerechnet im konkreten Fall anders zu machen.
>>
> Dieses Prinzip liese sich aber auch auf die OSM-Datenbank anwenden, was
> sicherlich von Vorteil wäre.

Du kannst ja gern einen Vorschlag machen, wie das gehen soll.

Die Werte in den Key zu verschieben (postal_service=yes) ist jedenfalls 
keine allgemeine Lösung, denn schon bei alt_name=Name1;Name2 oder 
vehicle=delivery;agricultural funktioniert das nicht.

> Nur weil die Strichpunkt-Notation üblich ist, muss sie eben noch lange nicht
> gut sein. Ich bin der Meinung, dass diese Notation schwer auszuwerten und zu
> pflegen ist, eine einzelne Erfassung wäre nur von Vorteil.

Was ist daran schwer auszuwerten? Z.B. in Perl: @werte = split /;/, $wert

Und warum schwer zu pflegen? Das ist bereits die dritte Behauptung, zu der 
du keine Begründung anführst.

-- 
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

_

Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[David Hopfmueller]

Friedrich Volkmann wrote:
> On 11.12.2012 19:10, Erwin OSM wrote:

>> Nur weil die Strichpunkt-Notation üblich ist, muss sie eben noch lange
>> nicht
>> gut sein. Ich bin der Meinung, dass diese Notation schwer auszuwerten
>> und zu
>> pflegen ist, eine einzelne Erfassung wäre nur von Vorteil.
> Was ist daran schwer auszuwerten? Z.B. in Perl: @werte = split /;/, $wert
> Und warum schwer zu pflegen? Das ist bereits die dritte Behauptung, zu
> der du keine Begründung anführst.

Zumindest auf Ebene des DBMS hat Erwin nicht Unrecht, wenn einer der
durch das Semikolon getrennten Werte als Filter verwendet werden soll.
Da bleibt Dir nämlich nur mehr ein teures LIKE, egal ob beim Auswerten
(SELECT) oder Pflegen (UPDATE).


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 11.12.2012 19:10, Erwin OSM wrote:

Am 11.12.2012 09:05, schrieb Friedrich Volkmann:

On 11.12.2012 05:51, Erwin Pleyer wrote:

Eines der wichtigen Prinzipien bei Datenbanken ist, niemals mehr als eine
Info in ein Feld zu schreiben! Kann man in allen Lehrbüchern lesen.


Dabei geht es um die Normalisierung relationaler Datenbanken. OSM ist
keine relationale Datenbank.

Außerdem ist die Strichpunkt-Notation in OSM längst üblich. Es gibt keinen
Grund, es ausgerechnet im konkreten Fall anders zu machen.


Dieses Prinzip liese sich aber auch auf die OSM-Datenbank anwenden, was
sicherlich von Vorteil wäre.


Du kannst ja gern einen Vorschlag machen, wie das gehen soll.

Die Werte in den Key zu verschieben (postal_service=yes) ist jedenfalls 
keine allgemeine Lösung, denn schon bei alt_name=Name1;Name2 oder 
vehicle=delivery;agricultural funktioniert das nicht.



Nur weil die Strichpunkt-Notation üblich ist, muss sie eben noch lange nicht
gut sein. Ich bin der Meinung, dass diese Notation schwer auszuwerten und zu
pflegen ist, eine einzelne Erfassung wäre nur von Vorteil.


Was ist daran schwer auszuwerten? Z.B. in Perl: @werte = split /;/, $wert

Und warum schwer zu pflegen? Das ist bereits die dritte Behauptung, zu der 
du keine Begründung anführst.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Stefan Tauner]

On Tue, 11 Dec 2012 19:10:02 +0100
Erwin OSM  wrote:

> Dieses Prinzip liese sich aber auch auf die OSM-Datenbank anwenden, was 
> sicherlich von Vorteil wäre.
> 
> Nur weil die Strichpunkt-Notation üblich ist, muss sie eben noch lange 
> nicht gut sein. Ich bin der Meinung, dass diese Notation schwer 
> auszuwerten und zu pflegen ist, eine einzelne Erfassung wäre nur von 
> Vorteil.

inwiefern key=tag1;tag2 schwieriger zu verarbeiten sein soll, als
key:1=tag1 key:2=tag2, mußt du mal erklären. beides hat seine
anwendungsfälle in osm (letzteres bei mehreren adressen pro element zb,
dort geht es aber auch nicht anders, denn dort müssen mehrere keys
miteinander verknüpft werden). beides hat vor- und nachteile und
beides benötigt eine extra behandlung beim iterieren über die tags. im
konkreten fall überwiegen deutlich die vorteile eines strichpunktes
IMHO.

das beste is natürlich keys so weit zu spezialisieren, daß eine
überlappung nicht auftritt, wie von al vorgeschlagen.

-- 
Kind regards/Mit freundlichen Grüßen, Stefan Tauner

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Erwin OSM]

Am 11.12.2012 09:05, schrieb Friedrich Volkmann:

On 11.12.2012 05:51, Erwin Pleyer wrote:
Eines der wichtigen Prinzipien bei Datenbanken ist, niemals mehr als 
eine

Info in ein Feld zu schreiben! Kann man in allen Lehrbüchern lesen.


Dabei geht es um die Normalisierung relationaler Datenbanken. OSM ist 
keine relationale Datenbank.


Außerdem ist die Strichpunkt-Notation in OSM längst üblich. Es gibt 
keinen Grund, es ausgerechnet im konkreten Fall anders zu machen.


Dieses Prinzip liese sich aber auch auf die OSM-Datenbank anwenden, was 
sicherlich von Vorteil wäre.


Nur weil die Strichpunkt-Notation üblich ist, muss sie eben noch lange 
nicht gut sein. Ich bin der Meinung, dass diese Notation schwer 
auszuwerten und zu pflegen ist, eine einzelne Erfassung wäre nur von 
Vorteil.


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Erwin OSM]

Am 11.12.2012 12:46, schrieb Stefan Tiran:

Andreas Labres wrote:

Ich würd einen neuen Tag erfinden "bietet auch Post-Dienstleistungen an".

postal_service=yes oder sowas.

+1

Das würde zumindest die Situation in Österreich sehr gut abbilden.

Liebe Grüße,
Stefan


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

+1

Träfe auch auf viele Situationen in Deutschland zu. Auch dort gibt es 
Supermärkte mit Postabteilungen.


Grüße
Erwin

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Stefan Tiran]

Andreas Labres wrote:
> Ich würd einen neuen Tag erfinden "bietet auch Post-Dienstleistungen an".
> 
>postal_service=yes oder sowas.

+1

Das würde zumindest die Situation in Österreich sehr gut abbilden.

Liebe Grüße,
Stefan


___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Andreas Labres]

Ich würd einen neuen Tag erfinden "bietet auch Post-Dienstleistungen an".

   postal_service=yes oder sowas.

Das kann man dann mit einem

   shop=grocery|supermarket|whatever (in Mauerbach isses glaub' ein 
Installateur).

oder einem

   amenity=bank

zusammen einsetzen.

Und wegen dem Strichpunkt muß ich Felix recht geben, das ist eine nicht
funktionierende Krücke, die sich noch nie wirklich durchgesetzt hat. Es gibt die
Idee zwar schon lange, aber ebenso lange funktioniert sie eben auch nicht.

/al

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 11.12.2012 05:51, Erwin Pleyer wrote:

Eines der wichtigen Prinzipien bei Datenbanken ist, niemals mehr als eine
Info in ein Feld zu schreiben! Kann man in allen Lehrbüchern lesen.


Dabei geht es um die Normalisierung relationaler Datenbanken. OSM ist keine 
relationale Datenbank.


Außerdem ist die Strichpunkt-Notation in OSM längst üblich. Es gibt keinen 
Grund, es ausgerechnet im konkreten Fall anders zu machen.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Erwin Pleyer]

Hallo Leute, nur ein,kurzer Beitrag von meiner Seite.

Eines der wichtigen Prinzipien bei Datenbanken ist, niemals mehr als eine Info 
in ein Feld zu schreiben! Kann man in allen Lehrbüchern lesen.

Dies würde aber durch das trennen mit ; geschehen.
Ich halte das für sehr bedenklich.

Schönen Tag aus dem tief verschneiten Kufstein.




Friedrich Volkmann  schrieb:

On 10.12.2012 23:58, Felix Hartmann wrote:
>>> In Graz wurden anscheinend vor Kurzem einige Bawag-Filialen umgebaut,
>>> und haben jetzt einen einzigen kombinierten Schalter sowohl für die
>>> Bank als auch Post. Wie schlagt ihr vor, das zu taggen? amenity=bank
>>> und amenity=post_office geht ja nicht gleichzeitig
>>
>> Aber klar geht das gleichzeitig: amenity=bank;post_office
>>
>> Dass Mapnik das nicht anzeigt, liegt nur daran, dass er Schrott ist. Die
>> Strichpunkt-Notation ist nun wirklich nichts Neues.
>>
> Ich hoffe das ist ironisch gemeint, die Strichpunkt-Notation, ist Schrott,
> weil quasi nicht auswertbar. Alleine schon weil weitere Tags dann keinen
> klaren Bezug haben.

Das ist mit allen Tagkombinationen so und hat mit dem Strichpunkt nichts zu 
tun. amenity=bank;post_office ist äquivalent amenity=bank + 
amenity=post_office, und das ist nicht mehr und nicht weniger auswertbar als 
etwas wie amenity=bank + shop=post_office.

-- 
Friedrich K. Volkmann http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

_

Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 10.12.2012 23:58, Felix Hartmann wrote:

In Graz wurden anscheinend vor Kurzem einige Bawag-Filialen umgebaut,
und haben jetzt einen einzigen kombinierten Schalter sowohl für die
Bank als auch Post. Wie schlagt ihr vor, das zu taggen? amenity=bank
und amenity=post_office geht ja nicht gleichzeitig


Aber klar geht das gleichzeitig: amenity=bank;post_office

Dass Mapnik das nicht anzeigt, liegt nur daran, dass er Schrott ist. Die
Strichpunkt-Notation ist nun wirklich nichts Neues.


Ich hoffe das ist ironisch gemeint, die Strichpunkt-Notation, ist Schrott,
weil quasi nicht auswertbar. Alleine schon weil weitere Tags dann keinen
klaren Bezug haben.


Das ist mit allen Tagkombinationen so und hat mit dem Strichpunkt nichts zu 
tun. amenity=bank;post_office ist äquivalent amenity=bank + 
amenity=post_office, und das ist nicht mehr und nicht weniger auswertbar als 
etwas wie amenity=bank + shop=post_office.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Felix Hartmann]

On 10.12.2012 20:29, Friedrich Volkmann wrote:

On 10.12.2012 20:08, Daniel Kraft wrote:

In Graz wurden anscheinend vor Kurzem einige Bawag-Filialen umgebaut,
und haben jetzt einen einzigen kombinierten Schalter sowohl für die
Bank als auch Post.  Wie schlagt ihr vor, das zu taggen? amenity=bank
und amenity=post_office geht ja nicht gleichzeitig


Aber klar geht das gleichzeitig: amenity=bank;post_office

Dass Mapnik das nicht anzeigt, liegt nur daran, dass er Schrott ist. 
Die Strichpunkt-Notation ist nun wirklich nichts Neues.


Ich hoffe das ist ironisch gemeint, die Strichpunkt-Notation, ist 
Schrott, weil quasi nicht auswertbar. Alleine schon weil weitere Tags 
dann keinen klaren Bezug haben.



___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Daniel Kraft]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/12/12 20:29, Friedrich Volkmann wrote:
> On 10.12.2012 20:08, Daniel Kraft wrote:
>> In Graz wurden anscheinend vor Kurzem einige Bawag-Filialen
>> umgebaut, und haben jetzt einen einzigen kombinierten Schalter
>> sowohl für die Bank als auch Post.  Wie schlagt ihr vor, das zu
>> taggen?  amenity=bank und amenity=post_office geht ja nicht
>> gleichzeitig
> 
> Aber klar geht das gleichzeitig: amenity=bank;post_office

Stimmt, jetzt im Nachhinein betrachtet war das direkt eine blöde
Frage ;)  Oder zeigt, dass frischer Input ganz gut sein kann!

Bei amenity= hab ich bisher noch nie an den Strichpunkt gedacht (nur
bei Klassikern wie vielleicht cuisine= oder so).

Danke, die Variante gefällt mir gut! :)

> Dass Mapnik das nicht anzeigt, liegt nur daran, dass er Schrott
> ist. Die Strichpunkt-Notation ist nun wirklich nichts Neues.

Das ist mir eh egal, nur wie gesagt, auf ; bin ich zuerst nicht gekommen.

Liebe Grüße,
Daniel

- -- 
http://www.domob.eu/
OpenPGP: 3BA2 3DDB 7758 F010 BDAB 0DCF 527E 79BA A3B5 3998
- --
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQxj3oAAoJEFJ+ebqjtTmYRPQP/R3gfYn5v2V4RAK766VWJQb3
fS+i6EB1wQxwjBONlkXym8G1KirYqdKGIFTb+y/GwvGDKOEQsC4Ho3ARtfZx0tSG
nLw7xghWEwgciD5FzpzaxT3hmdaNQUJDZLLYunTK23q7WzGifrWA8YqaQ+bIgXeg
fmWb+05adpSHaiUJ0TZ6Sa9I+ajyvzyPtsG3Bmno/Zdwcm/Le4oOKfK1etDVBbvZ
LrWJYFSbBFnzfQcZPJWVk+42oVWduwrArUEUmWGoBpmU1tQWIcrUVk2kdozSElS+
Ky6QijCo4gtWZ5r990krxcgUNOHtcAvMIrKGEeDf3Zea0NcbChYUE782TAICAds7
SoDmKavR0jOBuohXjmwmXmbHmlhw/2OIpmzQ8zIQD+w81gDFI4f68dnifcJ9wmvZ
pQeQ6w8Zfc1HjXPlP2IODuTtT9TthL5Udl+q2nO+7bHy9vW0OGN415smAXTyiQcs
7gHaHlW1HKk6qsmDF9Cvn+zRWFqSepp8YkxI27Vkd7RHeCXPcIhlwrerFWc+fITZ
+wV7tOcjhqQ3fXyLRWMxvCxpdTma0/4Y2hoFbaIX19wH1AdZ4V11NL8bUeLvG7Ou
UpbxhntkYTj/djLvOJ6i13wMwitplicppl41whgd5RHkFceonLXw0apGqwFNbUNn
zKKfnHYa8Pg/2UKPxlyk
=BhP4
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

Re: [Talk-at] Bawag PSK

[Friedrich Volkmann]

On 10.12.2012 20:08, Daniel Kraft wrote:

In Graz wurden anscheinend vor Kurzem einige Bawag-Filialen umgebaut,
und haben jetzt einen einzigen kombinierten Schalter sowohl für die
Bank als auch Post.  Wie schlagt ihr vor, das zu taggen?  amenity=bank
und amenity=post_office geht ja nicht gleichzeitig


Aber klar geht das gleichzeitig: amenity=bank;post_office

Dass Mapnik das nicht anzeigt, liegt nur daran, dass er Schrott ist. Die 
Strichpunkt-Notation ist nun wirklich nichts Neues.


--
Friedrich K. Volkmann   http://www.volki.at/
Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria

___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at

[Talk-at] Bawag PSK

[Daniel Kraft]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi!

Eigentlich wollte ich das am Donnerstag am Grazer Stammtisch
ansprechen, aber mir ist leider was dazwischen gekommen ... deshalb
poste ich meine Frage mal hier:

In Graz wurden anscheinend vor Kurzem einige Bawag-Filialen umgebaut,
und haben jetzt einen einzigen kombinierten Schalter sowohl für die
Bank als auch Post.  Wie schlagt ihr vor, das zu taggen?  amenity=bank
und amenity=post_office geht ja nicht gleichzeitig, obwohl es für mich
logisch wäre, nicht zwei separate Nodes zu taggen.  Immerhin ist es ja
tatsächlich *ein* Gebäude und sogar nur *ein* Schalter.

Was denkt ihr dazu?  Ich finde (leider), dass sowohl Bank als auch
Post relativ wichtige POIs sind ... und deshalb möchte ich auch auf
keinen Fall nur eins davon taggen.

Liebe Grüße,
Daniel

- -- 
http://www.domob.eu/
OpenPGP: 3BA2 3DDB 7758 F010 BDAB 0DCF 527E 79BA A3B5 3998
- --
Done:  Arc-Bar-Cav-Hea-Kni-Ran-Rog-Sam-Tou-Val-Wiz
To go: Mon-Pri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQxjNBAAoJEFJ+ebqjtTmYMsAP/3az+DsDxJf8Rlb1lcbDzFll
T+fPd13rB/xpHclb6RV3fRgkh8TLHIH0KNBvHc7d86cWZPoyEDZIvNXFjwbgnfqQ
ObnwUN5LNTjWDRWt18t7QzitweZWJfdL3Sa7E0s4E/PGqrP7Zv6WLuUOZGS2kuLX
7H6nmk+f4d/U1bPeQfnrQVc9kz5fpDHhONB6TNOWBz+ioFb7cI3kSNu4p3IhP7tl
Nbmh6AGvT3ktUU3Vvh7ZQzsiryBTF8A8Fp6wpK2P1lInp90jQHsmNXxdeQffs+ZP
5iEB3V73eogQ4yK/7TK7LUynM+oPKlgVE/DkDKmusMesiCFGdUbX0itFJOzjuFUq
BOtIhz+i14yaD8Z78zgAkwjuA//GP+HTnFTZW2ZxqhT0QQnxHtBtJByVxKT4E8iM
SwdYzHqoORYiA7/h+0+XLMARQkHdbHjW6i0u807aodaB95GVr9eTCemilJivWz1Z
IYdd/HY9x4ZdYpk2g68j8sDh0vo4a4GClQrp5GGynNfZ3NIdT+9MiXiTIwoxloxI
9Y/1yCLl9YFtsDg1ZWIfpxQ3hY0BVc5+TqyAsMjqitoZYxuesBP1nYMf9GzXS4bG
B63mJMdeAup98u6HANjhJ0zcEs/3rXTlIcN+KoBxIQxGuQwgjMPDPx1vzOhiMPZX
EspO6/czfa4zxXeX+957
=K2D6
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature
___
Talk-at mailing list
Talk-at@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-at