Re: [Talk-de] Schreibfehler in deutschem Copyright-Text

[Georg Feddern]

Moin,

da wir ja alle vier immer von der gleichen Seite

www.openstreetmap.org/copyright

reden:
Kann es sein, dass je nach Browsereinstellung/-sprache bei Dir der 
englische Text angezeigt wird?


Gruß
Georg

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Schreibfehler in deutschem Copyright-Text

[Andreas Schmidt]

Hi Volker,

auf dieser Adresse ist der deutsche Text:
http://www.openstreetmap.org/copyright

und dort ist dieser Tippfehler:


Mit freundlichen Grüßen
Andreas Schmidt


Am 16.04.2015 um 08:18 schrieb Volker Schmidt:
> Bin vielleicht ein bisschen langsam:
> kannst du bitte das URL der verweisenden Seite angeben, die den zitierten
> *deutschen* Text enthaelt:
> "Du kannst dies tun, indem du auf www.openstretmap.org/copyright <
> http://www.openstreetmap.org/copyright> verlinkst."
> Die in der urspruenglichen message (Mark, 15 April 2015 at 19:03) als
> verweisend angegebene Seite http://www.openstreetmap.org/copyright ist in
> englischer Sprache und enthaelt den falschen link nicht.
>
> 2015-04-15 20:05 GMT+02:00 Georg Feddern :
>
>> Am 15.04.2015 um 19:24 schrieb Volker Schmidt:
>>
>>> Der Fehler hat sich auch schön verbreitet: auf Anhieb 275 Ergebnisse bei
>>> Google.
>>>
>>> Auf welcher Seite ist der Original-Fehler?
>>> (Du hast die Ziel-Seite angegeben, nicht die mit dem fehlerhaften link)
>>>
>> Wie Mark es korrekt schreibt:
>> Die "Zielseite" enthält den Schreibfehler im _Text_ :
>>
>> Zitat:
>> "Du kannst dies tun, indem du auf www.openstretmap.org/copyright <
>> http://www.openstreetmap.org/copyright> verlinkst."
>>
>> Der dahinterliegende Link ist allerdings korrekt.
>>
>> Gruß
>> Georg
>>
>> ___
>> Talk-de mailing list
>> Talk-de@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-de
>>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de



signature.asc
Description: OpenPGP digital signature
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Schreibfehler in deutschem Copyright-Text

[Volker Schmidt]

Bin vielleicht ein bisschen langsam:
kannst du bitte das URL der verweisenden Seite angeben, die den zitierten
*deutschen* Text enthaelt:
"Du kannst dies tun, indem du auf www.openstretmap.org/copyright <
http://www.openstreetmap.org/copyright> verlinkst."
Die in der urspruenglichen message (Mark, 15 April 2015 at 19:03) als
verweisend angegebene Seite http://www.openstreetmap.org/copyright ist in
englischer Sprache und enthaelt den falschen link nicht.

2015-04-15 20:05 GMT+02:00 Georg Feddern :

> Am 15.04.2015 um 19:24 schrieb Volker Schmidt:
>
>> Der Fehler hat sich auch schön verbreitet: auf Anhieb 275 Ergebnisse bei
>> Google.
>>
>> Auf welcher Seite ist der Original-Fehler?
>> (Du hast die Ziel-Seite angegeben, nicht die mit dem fehlerhaften link)
>>
>
> Wie Mark es korrekt schreibt:
> Die "Zielseite" enthält den Schreibfehler im _Text_ :
>
> Zitat:
> "Du kannst dies tun, indem du auf www.openstretmap.org/copyright <
> http://www.openstreetmap.org/copyright> verlinkst."
>
> Der dahinterliegende Link ist allerdings korrekt.
>
> Gruß
> Georg
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.

[gmbo]

Dass in den USA die Sani Statiionen so wenig beschrieben sind ist kein 
Grund alles darauf zu reduzieren.
Schau dir die Portale der Camping- und Wohnmobilkataloge in Deutschland 
an dann siehst du was dort alles angegeben wird.



Die Toplevel Tags reichen für ein einfaches Rendering, aber was gibt dir 
das Recht, deshalb zu einem frühen Zeitpunkt weltweit einen 
Automatischen Edit anzustoßen wo du dich noch nicht einmal ausreichend 
mit dem Thema beschäftigt hast.


Du stellt mir die lapidare Frage
Können wir mit dem Editieren mit den Grundtags beginnen, auch wenn den 
Zusatztags noch im Unklaren sind
und hast schon längst einen automatischen Edit angestoßen, der mehrere 
vorher gebrauchte Tags umschreibt.
Dabei werden auch Zusatztags benutzt die du vorgestern anscheinend 
gewürfelt hast.


Ich finde das schade, da du dich ja anscheinend noch nicht einmal 
ausreichend mit dem Thema beschäftigt hast.
Sonst hättest du wenigstens auf die Bilder auf der englischen Talkseite 
beschreiben können.


Wenn du meinst die Toplevel reichen, aber gleichzeitig meinst, dass es 
zu Kompliziert ist Die Unterschiede darzustellen, dann könnte ich 
behaupten warum taggen wir die Entsorgungsstationen überhaupt.
Jeder gute Campingplatz hat eine und wenn man ankommt  wird man schon 
erkennen ob das mit meinem Campingfahrzeug geht.


Ich habe versucht mit dir über Grundlagen zu diskutieren, aber darauf 
bekomme ich dann die Antwort, dass es zwischen uns keine vernünftige 
Diskussionsbasis gibt, weil es die Sprachbariere gibt und das Thema 
Abwasser ja erheblich stinkt und man deshalb manches lieber nicht 
beschreibt,
Wie taggst du eigentlich waste=excremente um,welches ja genauso oft 
vorkommt wie waste=gray_water oder waste=chemical_toilet?



Im Moment fühle ich mich deshalb ziemlich hintergangen.

Wie ich schon in der Diskussionsseite des Wikis auf die Frage 
geantwortet habe bin ich auf keinen Fall für einen automatischen Edit.


Aber anscheinend muß man das System OSM und die Lücken kennen um 
weltweit etwas ändern zu können.


Warum bist du daran interressiert, diesen Tag so schnell in eine dir 
genehme Form zu bringen.

Dann bemühe dich darum dies zu erklären.

Mit welchem Kreis ist der Edit besprochen?
Wo ist dokumentiert was durch was ersetzt wird?

Ich bin wie ich mehrfach erwähnte für ein einheitliches Taggen.
Aber dann sollte es vernünftig und verständlich beschrieben sein. Nach 
Möglichkeit nicht nur Englisch(oder US - Amerikanisch)
Auch bei heiklen Themen sollte auf Hintergründe eingegangen werden um 
auch Mappern, die sich nur wenig mit dem Thema beschäftigt haben, die 
Möglichkeit des Mappens  zu geben.


Gisbert









Am 15.04.2015 um 19:37 schrieb Bryce Nesbitt:

You can also see how others are tagging Sanitary Dumps:
http://www.sanidumps.com/maps/index.php?id=18


---
The top level tags "sanitary_dump_station" are enough for rendering.

However someone with a given style of boat or motorhome can use use
only some of the sites.
They may have boat holding tank needing a pumpout, a boat or motorhome
with a cassette, or a motorhome with a gravity fed hose.
These are incompatible systems.  A given site may accept one, two or
three of the systems.

A given site may restrict or even ban tank holding chemicals, but
these rules are complex and hard to tag.  I prefer just a warning that
a given site may have a restriction that needs to be checked locally.

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Schreibfehler in deutschem Copyright-Text

[Georg Feddern]

Am 15.04.2015 um 19:24 schrieb Volker Schmidt:

Der Fehler hat sich auch schön verbreitet: auf Anhieb 275 Ergebnisse bei
Google.

Auf welcher Seite ist der Original-Fehler?
(Du hast die Ziel-Seite angegeben, nicht die mit dem fehlerhaften link)


Wie Mark es korrekt schreibt:
Die "Zielseite" enthält den Schreibfehler im _Text_ :

Zitat:
"Du kannst dies tun, indem du auf www.openstretmap.org/copyright 
 verlinkst."


Der dahinterliegende Link ist allerdings korrekt.

Gruß
Georg
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.

[Bryce Nesbitt]

You can also see how others are tagging Sanitary Dumps:
http://www.sanidumps.com/maps/index.php?id=18


---
The top level tags "sanitary_dump_station" are enough for rendering.

However someone with a given style of boat or motorhome can use use
only some of the sites.
They may have boat holding tank needing a pumpout, a boat or motorhome
with a cassette, or a motorhome with a gravity fed hose.
These are incompatible systems.  A given site may accept one, two or
three of the systems.

A given site may restrict or even ban tank holding chemicals, but
these rules are complex and hard to tag.  I prefer just a warning that
a given site may have a restriction that needs to be checked locally.

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

[Rolf Eike Beer]

Am Mittwoch, 15. April 2015, 15:00:40 schrieb fly:
> Fände es ja schön wenn auch alle meine Fragen beantwortet werden.
>
> Insgesamt scheint ja leider kaum Diskussionsbereitschaft vorhanden zu
> sein und auf meine Vorschläge wird sich gar nicht erst eingelassen

Wie es in den Wald schallt… Für meinen Geschmack nehmt ihr euch da beide 
nichts.

Es sind diverse Gegenargumente gekommen, auf die auch nicht wirklich 
eingegangen wurde. Ich persönlich bin da eher leidenschaftslos, und am 
Tagging-Schema auch nicht beteiligt gewesen, also versuche ich es jetzt 
nochmal von "neutraler" Seite aus. Wenn hier beiden Seiten die Lust am 
Diskutieren vergeht kann ich es aber vollkommen verstehen, als wirklich 
konstruktiv habe ich nur wenige Teile der ganzen Diskussion empfunden.

> Am 15.04.2015 um 09:27 schrieb Alexander Matheisen:
> > On Di, 2015-04-14 at 22:34 +0200, fly wrote:
> >> Am 14.04.2015 um 21:13 schrieb Michael Reichert:
> >>> Am 2015-04-14 um 19:43 schrieb fly:
>  railway:signal:main:state:forward=*
> >>> 
> >>> Lass mich raten, das Signal stammt von rayquaza und ist – für
> >>> OpenRailwayMap-Verhältnisse – schon ewig gemappt?
> >> 
> >> Nein, nur meiner Logik entsprungen.
> > 
> > du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang
> > sei, oder wie soll ich das jetzt verstehen?
> 
> Naja, war ja ein Volltreffer und wie willst Du es denn anders
> interpretieren ohne die fehlenden Information der Sonderbehandlung ?

Ich kann mich Michaels Verwunderung hier nur anschließen. Warum soll man 
virtuelle Probleme diskutieren, wenn du doch genug echte Probleme ausgemacht 
haben willst? Lasst uns dann doch auch bitte realitätsnahe Probleme 
diskutieren, Streitpunkte gibt es ja scheinbar genug, das man nicht noch 
unnötig neue erfinden muss.

> >>> Das sind Versuche,
> >>> Signale zu mappen, die für verschiedene Richtungen gelten und am selben
> >>> Mast hängen. Es hat sich nie durchgesetzt (das
> >>> railway:signal::state:forward/backward=* werten wir nicht aus und
> >>> wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz
> >>> nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung,
> >>> der andere für die andere Richtung.
> >> 
> >> Habe ich das im Wiki überlesen ?
> >> Welche Gründe sprechen denn dafür ?
> > 
> > Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene
> > Richtungen eingetragen werden können, würde die Tags noch komplizierter
> > machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns
> > entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt
> > kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder?
> 
> Wie kürzere Tags. Mir geht es um die nutzlose Wiederholung. In
> Sonderfällen wird dann erweitert. Das heißt doch noch lange nicht, dass
> immer die Richtung im Tag benötigt wird.

Die Richtung würde nur dann nicht benötigt, wenn in beide Richtungen das 
gleiche Signalbild gezeigt würde. Das ist so unwahrscheinlich, das man es 
völlig ignorieren kann. Also braucht es immer die Richtung.

> >> Mapped Ihr dann auch noch den Masten ?
> >> 
> >> Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher
> >> komplizierter.
> > 
> > Ich finde es deutlich komplizierter, als zwei Nodes zu mappen.
> 
> Wenn es nicht dokumentiert ist, verwirren zwei Punkte. Selbst wenn es
> dokumentiert ist, müß es erst gefunden und gelesen werden. Sonst schlägt
> Ihr ja auch vor alle Signale auf einen Pubkt zu mappen, nur bei der
> Richtung soll dann Schluß sein ?

Es gibt zwei Möglichkeiten:

1) beides an einem Node, dann heißt das jeweil eine Tag-Ebene mehr. Fände ich 
prinzipiell auch gut, weil es z.B. Schneepflug-Signale gibt, die quasi 
ausschließlich im Doppel auftreten: ein Mast, an einer Seite steht "hoch", an 
der anderen Seite "runter". Wenn man das sinnvoll vereinheitlichen kann: 
gerne, immer her damit. Wie würdest du denn so ein Signal eintragen?

Hier siehst du sowas bildlich:

http://walter-klan.de/signale/08)_ne-signale.html#Ne_7

2) 2 Nodes wie gehabt. Kürzere Tags, dafür liegt das halt nicht direkt 
übereinander.

[Signalrelationen]

> Zumindest Links wären dann wohl angebracht.

Kann ich mir nichts drunter vorstellen, insofern würde ich das auch lesen. 
Nach meiner Erfahrung ist aber alles, was man ohne Relation erschlagen kann, 
ein Gewinn. associatedStreet ist schon schlimm genug, da muss man nicht noch 
mehr von dem Zeug erfinden.

> >> Was war denn jetzt an meinen Vorschlägen jetzt falsch ?
> >> 
> >> state:main:forward=* resp. state:main=*
> >> height[:TYPE][:DIRECTION] resp. height[:TYPE]
> >> 
> >> Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ?
> >> (railway:signal:main:state=*)
> > 
> > Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein
> > Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor
> > du solchen Unsinn schreibst.
> 
> Siehe zB :lanes-Tagging
> 
> Was ist bitte an folgendem Beispiel Unsinn ?
> 
> railw

Re: [Talk-de] Schreibfehler in deutschem Copyright-Text

[Volker Schmidt]

Der Fehler hat sich auch schön verbreitet: auf Anhieb 275 Ergebnisse bei
Google.

Auf welcher Seite ist der Original-Fehler?
(Du hast die Ziel-Seite angegeben, nicht die mit dem fehlerhaften link)

Volker

2015-04-15 19:03 GMT+02:00 Mark Obrembalski :

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hallo!
>
> Im deutschsprachigen Text von
>
> http://www.openstreetmap.org/copyright
>
> ist ein blöder Schreibfehler, es wird nämlich als zu verlinkende Seite
>
> www.openstretmap.org/copyright (ein e zuwenig in der street)
>
> angegeben. Vielleicht liest ja einer der Macher hier mit - ansonsten
> und allgemein: Wo kann man einen solchen Fehler melden oder direkt
> korrigieren?
>
> Gruß,
> Mark
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBAgAGBQJVLpnQAAoJEBrjxFVQEkD/Q+YP/0gKbjq8Vu8QN1261ijsguRf
> KA8LSpm79mjjFv+usqjfDg+bJuzQpOFnX4TwnHHLXo0tZBL9j+mLY7COYaCcY6mK
> Z4o58vUSp+19jYHWRsNWoGAKh0DZ2J5nKpXiA9PlcOC77AYQs2UAmFCeM8pl9weB
> 0DzINg+bKTp87Wf1nAWlxJDtTiPqWKIUhs6Aev3fwTkStnpOClT8O8vTdse2t179
> GENAQiTeVNQYxTH/HCW5bhtcvVt6aORcvkbV1F/2TXBADOlmkMfDQ8joo0y6Jw/P
> WZW4eCyccqoSGJmG9QxyazwMCnO8wuT97R0LQZDRKQL6fAHj1a2Thd4L6mlXApvN
> BA9u9Z+GO3kNX6sYOnEt1ZxvxSzMx//gcOKf+gi9efCKewx+iEzCqmMtfPvBIuQt
> vsS+Q/AiYHRew6Clj/56T5Yda/0f5CZyOJ7Q+AlerKkHoDf8E2mfuQFazoGFbTwS
> CLah/srevKWej7mmik/zWczOYnsPIzsiqN+pq5qlhinQes7CKdAf3PuXjSfGCBya
> OpB4sZZ6YZk2iim7L1gRe7lF7NkXCSkCCkNMfUrRc77ubn6fTTglxNw59amX28jn
> FICvyiOWD1xtaYYhL2YtRlxf+bD/JP7TLiKcNfkWq7fZs5w1aea9+iLiNAtj8gqV
> IAYdXXF7thBp//wR4bOV
> =2VNC
> -END PGP SIGNATURE-
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Schreibfehler in deutschem Copyright-Text

[Mark Obrembalski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hallo!

Im deutschsprachigen Text von

http://www.openstreetmap.org/copyright

ist ein blöder Schreibfehler, es wird nämlich als zu verlinkende Seite

www.openstretmap.org/copyright (ein e zuwenig in der street)

angegeben. Vielleicht liest ja einer der Macher hier mit - ansonsten
und allgemein: Wo kann man einen solchen Fehler melden oder direkt
korrigieren?

Gruß,
Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJVLpnQAAoJEBrjxFVQEkD/Q+YP/0gKbjq8Vu8QN1261ijsguRf
KA8LSpm79mjjFv+usqjfDg+bJuzQpOFnX4TwnHHLXo0tZBL9j+mLY7COYaCcY6mK
Z4o58vUSp+19jYHWRsNWoGAKh0DZ2J5nKpXiA9PlcOC77AYQs2UAmFCeM8pl9weB
0DzINg+bKTp87Wf1nAWlxJDtTiPqWKIUhs6Aev3fwTkStnpOClT8O8vTdse2t179
GENAQiTeVNQYxTH/HCW5bhtcvVt6aORcvkbV1F/2TXBADOlmkMfDQ8joo0y6Jw/P
WZW4eCyccqoSGJmG9QxyazwMCnO8wuT97R0LQZDRKQL6fAHj1a2Thd4L6mlXApvN
BA9u9Z+GO3kNX6sYOnEt1ZxvxSzMx//gcOKf+gi9efCKewx+iEzCqmMtfPvBIuQt
vsS+Q/AiYHRew6Clj/56T5Yda/0f5CZyOJ7Q+AlerKkHoDf8E2mfuQFazoGFbTwS
CLah/srevKWej7mmik/zWczOYnsPIzsiqN+pq5qlhinQes7CKdAf3PuXjSfGCBya
OpB4sZZ6YZk2iim7L1gRe7lF7NkXCSkCCkNMfUrRc77ubn6fTTglxNw59amX28jn
FICvyiOWD1xtaYYhL2YtRlxf+bD/JP7TLiKcNfkWq7fZs5w1aea9+iLiNAtj8gqV
IAYdXXF7thBp//wR4bOV
=2VNC
-END PGP SIGNATURE-

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.

[gmbo]

Hallo Martin,
vielen Dank für das Einmischen.

Am 15.04.2015 um 12:14 schrieb Martin Koppenhoefer:

Am 14. April 2015 um 17:33 schrieb gmbo :


Leider führe ich die Diskussion mit einem Amerikaner allein und auf jede
Frage oder Anregung die ich stelle kommen mindestens 3 unerklärte neue
Zusatztaggingvorschläge, die nichts mit der vorherigen Frage zu tun hat und
für mich dann noch verwirrender ist, da mein Englisch nicht so gut ist.
Manchmal habe ich den Eindruck, dass in den Staaten völlig andere Systeme
benutzt werden.



soweit ich Bryce verstehe scheint es unterschiedliche Grundkonzepte zu
geben, sein Tagging geht um die Anbindungsart (welche Art Verbindung /
Anschluss um Flüssigkeit & Feststoffe zu transferieren), während Gisbert,
soweit es Bryce versteht, wohl gerne die Verbindungsart und die Stoffe die
man entsorgen kann, in einem tag verquicken würde.
Es gibt warscheinlich gar nicht so große Unterschiede, deshalb gehe ich 
davon aus, dass es auch ein gemeinsames Tagging gibt.

Im Proposel gibt es nur
amenity=sanitary_dump_station.

Dann das ganze zum Anhängen an eine bestehende Einrichtung also Camping- 
Wohnmobilstellplatz und Häfen.

sanitary_dump_station=yes
Beides sagt aus, daß es eine Entsorgungsstation gibt.

Da es aber  verschiedene Arten der Entsorgung gibt sind noch 2 
Zusatztags dazugenommen worden.

sanitary_dump_station:suction=yes
sanitary_dump_station:gravity=yes
diese beiden Tags sagen für mich nur aus, daß in dem ersten Fall 
abgesaugt wird und im 2. Fall die Entsorgung durch ablassen der 
Flüssigkeit geschieht. Also für mich nur die Beschreibung der Technik 
bei der Entsorgung.


Deshalb habe ich die Bilder die ich im letzten Jahr von solchen 
Stationen gemacht habe hochgeladen und eine Tabelle in seine 
Diskussionsseite geladen mit der Bitte diese so zu beschreiben wie er 
sie sieht um Differenzen zu finden.

Bilder fand er nicht gut und stellte 3 Videos vor.
Dabei gab es dann den Tag sanitary_dump_station:pumpout=yes der auf 
meine Frage warum er jetzt dies benutzt  wurde daraus dann pump_out.
Als ich ihm dann erklärte, dass ich für die Suche nach neuen Begriffen 
Taginfo benutze und da in dem Fall dann einzig Habor:pump-out gefunden 
hätte hat er es dann mit Bindestrich geschrieben.


Ich habe dann versucht die englische Wikiseite zu überseztzen , die aber 
täglich ein bisschen geändert wird.

Dann habe ich ein paar Prinzipbilder , natürlich aus meiner Sicht erstellt.
Die sollten aber eigentlich auch zwischen hier und den Staaten 
übereinstimmen, denn die Videos zeigen eigentlich die selbe Art von 
Fahrzeugen.  Und ob es drüben ein Bajonet am Entsorgungsschlauch gibt 
oder ob der Schlauch mit einer anderen Art an das Fahrzeug angebracht 
wird sollte fürs taggen egal sein.
Die für mich wichtige Frage, ob man die in den neueren Fahrzeugen 
verwendeten Kassettentanks auch über das gleiche Loch in welches der 
Adapter für das Auslassende passt, entsorgt werden kann hat er noch 
nicht beantwortet.
Natürlich ist unstrittig, dass die Entsorgungseinlässe, die ca. 1 m hoch 
liegen nicht für die Schlauchentsorgung funktionieren, und man diess 
anders beschreiben muß.
Da es sich dabei aber nicht nur um hochgelegte Auslassbecken oder 
spezielle Toiletten handelt sondern auch um extra hochgezogene Rohre ist 
der von ihm kurzerhand erstellte Tag sanitary_dump_station:basin=yes 
irreführend.


Anscheinend gibt es da eben das Problem, dass man nicht das Becken , 
welches wenn es in den Boden eingelassen ist andere 
Entsorgungsmöglichkeiten bietet als wenn es In einem Gebäude 1m hoch an 
der Wand hängt, beschreiben darf sondern das was dort entsorgt wird.




Ausserdem gefällt ihm der tag "sanitary_dump_station:chemical_toilet" nicht
so gut, weil er da Verwechslungsgefahr mit chemischen Toiletten zur
Benutzung durch Menschen sieht.
chemical_toilet ist der zur Zeit am häufigsten benutzte Tag bei der 
Entsorgung

Sieser wurde bisher mit
amenity=waste_disposal
waste=chemical_toilet getagt.

Daher hatte ich diesen vorgeschlagen.
Ich habe aber auch vorgeschlagen ganz auf den Tag zu verzichten da 
eigentlich 90% der hiesigen Entsorgungsstationen chemische Zusätze in 
den Fäkalien zulassen. Es gibt in Europa auf Länderebene Unterschiede 
welche Gifte enthalten sein dürfen, Aber das weiß man recht schnell wenn 
man in ein anderes Land reist.
Da es aber bei uns Biologische Klärwerke gibt, die durch die 
Zugelassenen Chemikalien ihre Funktion verlieren bat ich um ein Tagg wie 
chemicals_ban oder forbit.
Er führte daraufhin den Tag chemicals_restrictet ein und meite in den 
USA gäbe es nur Beschränkungen aber keine Verbote, außer in einigen 
Staaten, dort aber dann komplett.

Das wäre aber ja maximal ein Tag der dann hier anders wäre als drüben.
Sie könnten ja auch nebeneinander existieren.

Gruß
Gisbert





___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

[fly]

Fände es ja schön wenn auch alle meine Fragen beantwortet werden.

Insgesamt scheint ja leider kaum Diskussionsbereitschaft vorhanden zu
sein und auf meine Vorschläge wird sich gar nicht erst eingelassen


Am 15.04.2015 um 09:27 schrieb Alexander Matheisen:
> On Di, 2015-04-14 at 22:34 +0200, fly wrote:
>> Am 14.04.2015 um 21:13 schrieb Michael Reichert:
>>> Am 2015-04-14 um 19:43 schrieb fly:
>>>
 railway:signal:main:state:forward=*
>>>
>>> Lass mich raten, das Signal stammt von rayquaza und ist – für
>>> OpenRailwayMap-Verhältnisse – schon ewig gemappt?
>>
>> Nein, nur meiner Logik entsprungen.
> 
> du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang
> sei, oder wie soll ich das jetzt verstehen?

Naja, war ja ein Volltreffer und wie willst Du es denn anders
interpretieren ohne die fehlenden Information der Sonderbehandlung ?

>>> Das sind Versuche,
>>> Signale zu mappen, die für verschiedene Richtungen gelten und am selben
>>> Mast hängen. Es hat sich nie durchgesetzt (das
>>> railway:signal::state:forward/backward=* werten wir nicht aus und
>>> wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz
>>> nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung,
>>> der andere für die andere Richtung.
>>
>> Habe ich das im Wiki überlesen ?
>> Welche Gründe sprechen denn dafür ?
> 
> Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene
> Richtungen eingetragen werden können, würde die Tags noch komplizierter
> machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns
> entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt
> kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder?

Wie kürzere Tags. Mir geht es um die nutzlose Wiederholung. In
Sonderfällen wird dann erweitert. Das heißt doch noch lange nicht, dass
immer die Richtung im Tag benötigt wird.

>> Mapped Ihr dann auch noch den Masten ?
>>
>> Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher
>> komplizierter.
> 
> Ich finde es deutlich komplizierter, als zwei Nodes zu mappen.

Wenn es nicht dokumentiert ist, verwirren zwei Punkte. Selbst wenn es
dokumentiert ist, müß es erst gefunden und gelesen werden. Sonst schlägt
Ihr ja auch vor alle Signale auf einen Pubkt zu mappen, nur bei der
Richtung soll dann Schluß sein ?

>> Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch
>> die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir
>> können jedes Signal einzeln eintragen.
> 
> Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter
> auf diversen Kanälen diskutiert und sowohl für Mapper als auch die
> Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust,
> dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt
> plötzlich meinst, das Taggingschema der Signale in Frage zu stellen.

Zumindest Links wären dann wohl angebracht.

>>
>> Was war denn jetzt an meinen Vorschlägen jetzt falsch ?
>>
>> state:main:forward=* resp. state:main=*
>> height[:TYPE][:DIRECTION] resp. height[:TYPE]
>>
>> Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ?
>> (railway:signal:main:state=*)
> 
> Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein
> Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor
> du solchen Unsinn schreibst.

Siehe zB :lanes-Tagging

Was ist bitte an folgendem Beispiel Unsinn ?

railway=signal
signal:main=*
state=*
height=*
ref=*
direction=95

>>> Lektüreempfehlung:
>>> http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf
>>> :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert
>>> für Nicht-Bahnaffine.
>>
>> Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und
>> versuche dann mein Glück
>>
>> Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese
>> ja auch nicht die gesamte STVO um eine Ampel bzw Verkehrsschild einzutragen.
> 
> Wenn du ein wenig im Internet recherchieren würdest, würdest du recht
> schnell auf einfachere Erklärungen stoßen. Wikipedia ist ein guter
> Anfang, ebenso die auf den ORM-Wikiseiten bei jedem Signal vorhandenen
> Links zu weiterführenden Informationen. Wenn du dennoch damit
> überfordert bist, dann lass es doch einfach. Es zwingt dich doch
> niemand, Bahnsignale einzutragen.

Genau, es sind alles Links zu externen Seiten, und auch dort nur
Fachabkürzungen und weitere Links. Zu den Beispielen am Ende habe ich
schon Kommentare abgegeben.

Das ist mir alles doch recht dürftig und absolut nicht für eine größere
Gemeinschaft geeignet. Unter solchen Voraussetzungen frage ich mich halt
warum das alles in OSM soll. TMC wurde ja schon erwähnt als
abschreckendes Beispiel.

fly

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] Ankündigung: Aufzeichnung Radio-OSM Folge 042 am Montag 20.4.2015

[Michael Kugelmann]

FYI: wir planen im Moment die aktuelle Folge 042 mit der "Antwort auf 
alle Fragen in OSM"  ;-)  am Montag Abend 20.04.2015 aufzuzeichnen.

http://podcast.openstreetmap.de/ueber/

Dieses Mal ist wieder ein Streaming via Xenim vorgesehen 
(http://streams.xenim.de/osm/) so dass ein "live zuhören" möglich sein 
sollte. Wer via Mumble aktiv teilnehmen will findet die Info hierzu 
unter http://podcast.openstreetmap.de/mitmachen/ .


Die geplanten Themen findet Ihr wie immer im Trello (ist noch nicht 
abgeschlossen und entwickelt sich gerade noch): 
https://trello.com/b/YvlitJTs/radioosm-contentplanung.



Grüße,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description

[Michael Kugelmann]

Am 15.04.2015 um 10:34 schrieb Jo:

Sind das nicht die tags die man im GPX XML findet?

+1
Deswegen auch mit Tendenz zum löschen, vermutlich "versehentlich 
hereingekommen".

Kann man mal den Original-Autor fragen was das Tag soll?


Grüße,
Michael.


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.

[Martin Koppenhoefer]

Am 14. April 2015 um 17:33 schrieb gmbo :

> Leider führe ich die Diskussion mit einem Amerikaner allein und auf jede
> Frage oder Anregung die ich stelle kommen mindestens 3 unerklärte neue
> Zusatztaggingvorschläge, die nichts mit der vorherigen Frage zu tun hat und
> für mich dann noch verwirrender ist, da mein Englisch nicht so gut ist.
> Manchmal habe ich den Eindruck, dass in den Staaten völlig andere Systeme
> benutzt werden.
>


soweit ich Bryce verstehe scheint es unterschiedliche Grundkonzepte zu
geben, sein Tagging geht um die Anbindungsart (welche Art Verbindung /
Anschluss um Flüssigkeit & Feststoffe zu transferieren), während Gisbert,
soweit es Bryce versteht, wohl gerne die Verbindungsart und die Stoffe die
man entsorgen kann, in einem tag verquicken würde.

Ausserdem gefällt ihm der tag "sanitary_dump_station:chemical_toilet" nicht
so gut, weil er da Verwechslungsgefahr mit chemischen Toiletten zur
Benutzung durch Menschen sieht.

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] neuer Key für Entsorgungsstationen sanitary_dumping _station.

[Martin Koppenhoefer]

Am 14. April 2015 um 17:33 schrieb gmbo :

> http://wiki.openstreetmap.org/wiki/Proposed_features/Sanitary_Dump_Station
>
> Ich kann zum Beispiel den Unterschied
> sanitary_dump_station:suction=yes und sanitary_dump_station:pump-out=yes
> nicht erkennen.
>


da scheint es auch gar keinen zu geben. "suction" (Absaugen) steht hier:
http://wiki.openstreetmap.org/wiki/Tag:amenity%3Dsanitary_dump_station#Tagging_the_Facility_Type
als Erklärung für "pump-out" (auspumpen), auf der Wikiseite kommt das Wort
sonst nicht vor. Laut taginfo kommt der tag "sanitary_dump_station:suction"
weltweit 6 mal vor (pump-out 9x)


Es wäre schön wenn es noch andere Camper oder Bootsführer gäbe, die dort
> mit drüber schauen.
>


+1

ich kenne mich da leider gar nicht aus, melde mich hier nur zu Wort, weil
Bryce mich um Hilfe gebeten hatte, die Sprachbarrieren zu überwinden, er
kann wohl etwas Deutsch, es reicht aber nicht, um die Diskussion auf
Deutsch zu führen. Soweit ich das verstanden habe will er gerne das tagging
vereinheitlichen und dokumentieren, weil es wohl derzeit sehr fragmentiert
ist. Er versucht daher ein allgemeingültiges Schema zu etablieren, das man
weltweit einsetzen kann.

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description

[Martin Koppenhoefer]

Am 15. April 2015 um 08:56 schrieb Martin Vonwald :

> Weil die Unsitte in weiten Bereichen OSMs einzieht, dass
> jedes Tag unbedingt sofort überall diskutiert, abgesegnet und dokumentiert
> werden muss. Dem ist nicht so! Es ist von Vorteil, etwas zu diskutieren
> (mit Leute die Ahnung von dem Thema haben und nicht den lautesten Schreiern
> in irgendeinem Forum oder einer tollen Mailingliste). Es ist von großem
> Vorteil, Tags zu dokumentieren (ist aber nicht verpflichtend - NICHTS ist
> in OSM verpflichtend, oder bezahlt mich jemand dafür?). Es war nie, ist
> nicht und wird - solange ich dabei bin - nicht erforderlich sein, von
> irgendjemanden irgendeine Zustimmung zu irgendeinem Tag einzuholen.
>


jein. Ich fände es ehrlich gesagt schon ein Problem, wenn die Offenheit des
Projektes dadurch gefährdet würde, dass (hypothetisch) absichtlich
undokumentierte Codes zur Anwendung kämen, um den Inhalt der tags zu
verschleiern, z.B. proprietarymaps:123:12=Q34F5 (rein fiktives Beispiel).
Deshalb kann ich Deine Ausführungen nicht pauschal unterschreiben, finde im
konkreten Fall aber die Schwelle noch nicht überschritten.

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

[Martin Koppenhoefer]

Am 15. April 2015 um 09:27 schrieb Alexander Matheisen <
alexandermathei...@ish.de>:

> Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter
> auf diversen Kanälen diskutiert und sowohl für Mapper als auch die
> Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust,
> dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt
> plötzlich meinst, das Taggingschema der Signale in Frage zu stellen.
>



für Mapper ist das m.E. einfacher als 2 und mehr genau übereinander
liegende Nodes, die man einerseits nicht so einfach erstellen kann
(manuelle Koordinateneingabe erforderlich), und wo man später leicht die
weiteren Nodes übersieht. Wenn man hingegen nebeneinanderliegende Nodes
mappt, stimmt es topologisch nicht (sind ja nicht mehrere Positionen
sondern dieselbe).
Für Auswerter könnte man es banal so machen: jede Node-relation wird zu
einem eigenen Node an derselben Stelle umgewandelt (wobei man dann an
dieser Stelle topologisch wieder ein Problem einführt, aber als Resultat
nichts schlechteres erhält als bei genau übereinanderliegenden Nodes, und
einen Vorteil hat gegenüber "dicht" beieinanderliegenden Nodes) --- oder
man müsste sich was eigenes überlegen ;-).

Praktikabel ist das in jedem Fall.

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description

[Jo]

Sind das nicht die tags die man im GPX XML findet? Die haben tatsächlich
nichts verloren in OSM.

Polyglot

2015-04-15 9:40 GMT+02:00 Peter Barth :

> Hallo,
>
> Martin Vonwald schrieb:
> > Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die
> Tags
> > in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben
> > undokumentierte Tags. C'est la vie! [...]
>
> sry Martin, aber dem kann ich mich nicht anschließen da die Tags
> offensichtlicher Schwachsinn sind und die im Betreff genannten wohl auch
> etwas zu kurz greifen: ele=0. mitten im Ösiland? name=nXY? Die
> beiden zumindest sind dokumentiert und wie gesagt offensichtlicher
> Schwachsinn. Und ganz ehrlich, bei nem Tag-namen *_symbol hört sich das
> schon nach Tagging für irgendeinen Renderer an. Wenn dann ein
> "City (Small)" an einem Wald klebt ..
>
> Gruß,
> Peda
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
>
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

[Alexander Matheisen]

On Di, 2015-04-14 at 22:34 +0200, fly wrote:
> Am 14.04.2015 um 21:13 schrieb Michael Reichert:
> > Am 2015-04-14 um 19:43 schrieb fly:
> >> Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer:
> >>> Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig 
> >>> namespace-Tags begegnen, dann ist es doch leicht anders:
> >>>
> >>> emergency=fire_hydrant
> >>> fire_hydrant:type=underground
> >>>
> >>> railway=signal
> >>> railway:signal:...
> >>
> >> railway:signal:main:state:forward=*
> > 
> > Lass mich raten, das Signal stammt von rayquaza und ist – für
> > OpenRailwayMap-Verhältnisse – schon ewig gemappt?
> 
> Nein, nur meiner Logik entsprungen.

du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang
sei, oder wie soll ich das jetzt verstehen?

> > Das sind Versuche,
> > Signale zu mappen, die für verschiedene Richtungen gelten und am selben
> > Mast hängen. Es hat sich nie durchgesetzt (das
> > railway:signal::state:forward/backward=* werten wir nicht aus und
> > wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz
> > nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung,
> > der andere für die andere Richtung.
> 
> Habe ich das im Wiki überlesen ?
> Welche Gründe sprechen denn dafür ?

Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene
Richtungen eingetragen werden können, würde die Tags noch komplizierter
machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns
entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt
kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder?

> Mapped Ihr dann auch noch den Masten ?
> 
> Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher
> komplizierter.

Ich finde es deutlich komplizierter, als zwei Nodes zu mappen.

> Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch
> die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir
> können jedes Signal einzeln eintragen.

Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter
auf diversen Kanälen diskutiert und sowohl für Mapper als auch die
Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust,
dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt
plötzlich meinst, das Taggingschema der Signale in Frage zu stellen.

> >> Wenn möglich sollte doch der ein oder andere Tag auch mit weniger
> >> Pre-/Postfixen auskommen (siehe auch :lanes-Tagging).
> >>
> >> state:main:forward=*
> >>
> >> bzw wenn möglich sogar nur
> >>
> >> state=*
> >> height[:TYPE][:DIRECTION]
> >> Eindeutig ist das ganze doch schon durch railway=signal
> >>
> >>> Das macht die Zuordnung "interessiert mich der key" für den Benutzer 
> >>> etwas 
> >>> einfacher, aber andere Dinge wir "ref" fallen da trotzdem aus der 
> >>> Reihe[1]. 
> >>
> >> Welche Benutzer*innen meinst Du ?
> >>
> >> Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen
> >> Schlüssel schon eine Menge Platz aus und die wichtige Information steht
> >> am Ende.
> >>
> >>> Ich sehe nicht, dass der Verzicht auf "railway:" bei den key-Namen eine 
> >>> große 
> >>> Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das 
> >>> überblicken kann, zu Kollisionen mit anderen Taggings führen würde.
> >>
> >> Wolltest wohl "zu keinen Kollisionen" schreiben
> >>
> >> Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal
> > 
> > An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in
> > eckigen Klammern):
> > - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken)
> >   [distant]
> > - ein Geschwindigkeitsanzeiger [speed] und/oder
> >   Geschwindigkeitsvoranzeiger [speed_limit]
> > - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road]
> > - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger
> >   [route](bei Streckenverzweigungen und mancherorts auch bei
> >   Gleiswechseln)
> > - eine Haltetafel [stop] (die mit dem H)
> > - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals
> >   [minor].
> 
> Was war denn jetzt an meinen Vorschlägen jetzt falsch ?
> 
> state:main:forward=* resp. state:main=*
> height[:TYPE][:DIRECTION] resp. height[:TYPE]
> 
> Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ?
> (railway:signal:main:state=*)

Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein
Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor
du solchen Unsinn schreibst.

> > Lektüreempfehlung:
> > http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf
> > :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert
> > für Nicht-Bahnaffine.
> 
> Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und
> versuche dann mein Glück
> 
> Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese
> ja auch nicht die gesamte STVO um eine Amp

Re: [Talk-de] [Talk-at] wpt_symbol, wpt_description

[Peter Barth]

Hallo,

Martin Vonwald schrieb:
> Bitte Leute*, besinnt euch auf die Grundprinzipien von OSM! Stehen die Tags
> in irgendeinem Konflikt mit existierenden? Nein? Dann sind es eben
> undokumentierte Tags. C'est la vie! [...]

sry Martin, aber dem kann ich mich nicht anschließen da die Tags
offensichtlicher Schwachsinn sind und die im Betreff genannten wohl auch
etwas zu kurz greifen: ele=0. mitten im Ösiland? name=nXY? Die
beiden zumindest sind dokumentiert und wie gesagt offensichtlicher
Schwachsinn. Und ganz ehrlich, bei nem Tag-namen *_symbol hört sich das
schon nach Tagging für irgendeinen Renderer an. Wenn dann ein 
"City (Small)" an einem Wald klebt ..

Gruß,
Peda


___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de