[Talk-de] 2. RFC für Internet Cafes

[Guenther Meyer]

Am Donnerstag 25 Dezember 2008 schrieb Sven Rautenberg:
> Stefan Hirschmann schrieb:
> > Wichtigste Sachen zusammen gefasst:
> > * Zusätzlich zum Tag wird auch der Namespace internet:access= erlaubt.
>
> Das halte ich für großen Blödsinn und extrem überflüssig.
>
> Meine Argumente dagegen:
> 1. OSM kennt keine Namespaces. Alle Keywerte müssen OSM-global unique
> sein, die Datenbank und die API interessieren sich absolut nicht für den
> Doppelpunkt innen drin, und selbst wenn der Doppelpunkt in XML als
> Zeichen für Namespace-Trennung verwendet wird, so gilt dies nicht für
> die aus OSM exportierbaren XML-Dateien, weil der Key dort ein
> Attributwert ist, kein Tag-Name.
>
osm kennt viele dinge nicht, die sinnvoll waeren, vielleicht weil es auch 
bewusst einfach und flexibel gehalten ist.
das heisst aber noch lange nicht, dass man sowas wie z.B. namespaces nicht 
verwenden kann. auch wenn es datenbank und api nicht kann - anwendungen, die 
diese daten nutzen, koennen das sehr wohl auswerten.
ausserdem wird auch die api weiterentwickelt, um dinge zu unterstuetzen, die 
es vorher nicht gab.

> 2. Es ist ebenso unsinnig, für einunddasselbe ZWEI Keys zu erfinden. Das
> bürdet den Mappern auf, sich für eines von beiden zu entscheiden
> (welches nimmt man schlauerweise?), und den Renderern das Verarbeiten
> von zwei Regeln zum Malen der optischen Erscheinung beider Varianten.
>
das mag unsinnig sein, passiert aber.
ausserdem kann es ja durchaus sein, dass etwas neues einfach aus verschiedenen 
gruenden besser passt oder funktioniert, als etwas bereits verwendetes...

> Und da ich im Moment auch nicht erkennen kann, dass sich für den ersten
> Wortbestandteil "internet" so wahnsinnig viele weitere Nutzungen
> aufdrängen, sehe ich nicht ein, warum "internet:access" ein sinnvoller
> Key sein sollte. Sollte es Dinge wie "internet:backbone", "internet:CIX"
> oder "internet:satlink" irgendwann wirklich geben, würde es diese Dinge
> auch als "data_wire", "internet:infrastructure=CIX, operator..." oder
> "building=satellite_uplink" geben können - je nachdem, was zu dem
> Zeitpunkt dann der jeweilige Stand der Diskussion und Tag-Entwicklung ist.
>
du gibst selbst bereits moegliche nutzungen an, kannst dir solche aber nicht 
vorstellen? seltsam...

> Wenn das Namespace-Argument schon irgendwie ziehen soll, dann wäre das
> allerhöchstens für die sich eventuell andeutenden Extrainformationen zu
> "internet_access", also z.B. "internet_access:price" oder
> "internet_access:speed".
daher kommts ja auch urspruenglich...

> Da will man nämlich keine doppelten 
> Doppelpunkte haben.
>
wie meinen?

> > * Es werden versch. Arten des Internets unterschieden.
>
> Ich frage mich, warum es "internet_access=service" gibt. Warum nicht
> "internet_access=public".
>
lies, was auf der wiki seite steht, dann sollte das klar sein.

> Ich würde allerdings vorschlagen, einfach mal Bilder von Beispielen zu
> sammeln. Je mehr Beispiele es gibt, desto klarer wird das Bild, wie
> unterschiedlich auf der Welt Internetzugänge aussehen können, und dann
> kann man anhand der Bilder auch gleich Beispieltagging demonstrieren,
> sollte das Proposal einmal akzeptiert werden.
>
klingt gut. wobei das bei internetzugaengen mit fotos zum teil nicht so 
einfach ist...

> > * Internet_access berücksicht keine Kosten, aber durch Namespace
> > internet: möglich, allgemeine Tags für Internet zu spezifizieren.
>
> Ja, ich bin sehr dafür, keine Preise zu taggen, allenfalls die
> Information, ob ein Angebot kostenlos ist oder nicht.
>
das ist wieder so eine osm-sache... wer haelt was fuer sinnvoll?
ein mindest-tagging ob kostenlos oder nicht halte ich auf alle faelle fuer 
wertvoll. wenn jemand einen sinn darin sieht, exakte preise einzutragen, 
sollte man ihn nicht davon abhalten.

> > * Wichtig: Internet_access ist ein Zusatzattribut. D.h. ein Internet
> > Cafe wird als
> > 	amenity=cafe
> > 	internet_access=terminal
> > getaggt.
>
> Es gibt in OSM keine "Zusatzattribute", nur Attribute, also
> "Hauptattribute". Das Proposal muss also damit klarkommen, dass es auch
> alleinstehend funktioniert.
>
aus anwendungssicht gibt es diese unterscheidung sehr wohl!
dass sich in der datenbank alles auf derselben ebene abspielt, ist schon klar.

aber nimm doch mal das beispiel strassen:
da ist es doch allgemeiner konsens, dass "highway" als haupt- und alles andere 
als nebenattribut gesehen wird. oder etwa nicht?

> Deshalb sollte besser schon jetzt daran gegangen werden, die
> Argumentation so auszurichten, dass dieses Tag sich ausschließlich
> darauf konzentriert, das Vorhandensein des Internetzugangs zu
> dokumentieren, unabhängig von möglichen weiteren Eigenschaften des
> Ortes, die sich in anderen Tags widerspiegeln.
>
genau darum geht's ja. niemand hat bisher was anderes behauptet.

-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 197 bytes
Beschreibung: This is a digitally signed message part.
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20081225/1b3e690a/attachment.sig>