from:"Peter Wendorff"

Hallo Bernd,
entschuldige bitte - das war tatsächlich Bernhard - Schande über mein
Haupt; In der Thread-Ansicht war das so weit nach rechts gerutscht, dass
ich nur noch auf das Bern| geachtet habe. :/

Gruß
Peter

Am 26.02.2014 16:01, schrieb Bernd Wurst:
 Ich mach ja kein Tofu normalerweise aber hier kann ich nicht Sachbezogen
 antworten:
 
 Du legst mir in den Mund, dass ich irgendwas über irgend einen
 Goetheplatz geschrieben hätte. Habe ich nie. Ich weiß nichts von einem
 Goetheplatz.
 
 Lass das bitte.
 
 
 Am 26.02.2014 11:57, schrieb Peter Wendorff:
 Am 26.02.2014 11:20, schrieb Bernd Wurst:
 Hallo Peter.

 Zunächst: Watch your tone. Ehrlich.


 Am 26.02.2014 11:00, schrieb Peter Wendorff:
 Hallo Bernd,
 was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete
 Fragen stellen kann, was da was ist oder sein soll.
 Dass ein Name am Goetheplatz fehlt, hattest du geschrieben.

 Nein, habe ich nicht geschrieben.
 Stimmt, du hattest nur gefragt (Mail von gestern, 25.2., 23:12):
 Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits
 bekannten Platzes auf der Karte erscheint?
 Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt.

 Vielleicht hab ich da also einen konkreten Fehlerfall reininterpretiert,
 den es nicht einmal gab oder gibt - dann entschuldige ich mich für den
 Ton (erlaube mir aber, die Frage zu stellen, was du damit eigentlich
 erfragen wolltest).

 Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert
 werden sollte, hast du hier auch schon lesen können.

 Ja, betrifft mich aber null komma gar nicht.
 Sondern? Was betrifft dich denn dann? Denn die Frage hast du ja schon
 gestellt, zumindest ist die Mail bei mir so eingegangen. Was genau du
 brauchst, hast du ja nicht geschrieben - ich weiß nur, dass es um
 irgendeinen der Goetheplätze geht, die es gibt.

 Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen,
 die nur auf Hörensagen beruht, weil niemand außer dir das direkt
 überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig).

 Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle
 Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach
 irgend einen x-beliebigen Waldweg an.
 Das Waldweg-Thema ist ein anderes und doch geklärt - da fehlt noch die
 Render-Regel, die beim Catch-All weggefallen ist, da kann man gucken, ob
 es ein Ticket gibt und bei Bedarf eins erstellen, einen Patch einreichen
 etc., darauf habe ich mich aber nicht bezogen.

 Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen -
 jedenfalls ist das meistens der Fall.
 Soviel also zu deiner Frage was denn noch.

 Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer
 name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein*
 area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben
 kein area-Tag.
 das area-Tag ist nicht ausschlaggebend fürs Rendering; es ist aber
 notwendig, um ein lineares feature als Fläche darzustellen.

 waldwege: Da fehlt die Rendering-Regel, Goetheplatz: da fehlt das Wissen
 darüber, was da überhaupt drangetagged ist - und das verweigerst du ja
 weiterhin (oder es interessiert dich tatsächlich nicht mehr).

 Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige
 wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man
 machen, muss dann aber auch alle etablierten Werte berücksichtigen.
 Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein.

 Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf
 zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich
 bitte auch darum kümmern dass das gefixed wird.
 Ich glaube, bei konkreten Fehlermeldungen (wie gesagt: ich red vom
 Goetheplatz) würde das jemand übernehmen; spätestens auf eine direkte
 Bitte hin. Aber aus wagen Aussagen ein Ticket zu bauen ist etwas mehr
 Arbeit als sich bei github anzumelden.

 Wer das verbockt hat hat im Zuge dessen etliche andere Fehler behoben
 und damit die Gesamtlage im Rendering eher verbessert; zumindest aber
 langfristig eine richtige Grundlage gelegt, um gezielt eine korrekte
 Darstellung genau da zu erzielen, wo sie gewünscht wird.

 Wenn Du mit github ein Problem hast, frag doch einfach freundlich nach,
 beschreibe das Problem konkret und so, wie du es auch in ein Ticket
 schreiben würdest, und bitte darum, dass daraus jemand ein Ticket macht,
 ich bin sicher, dass dir das nicht verwehrt wird.

 Gruß
 Peter

 ___
 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 mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0

+1
insbesondere würde das auch Tippfehler in Straßennamen einzelner
Adressen visualisieren.

Gruß
Peter

Am 26.02.2014 22:50, schrieb Florian Lohoff:
 On Wed, Feb 26, 2014 at 09:38:39PM +0100, Gertrud Simson wrote:
 Außerdem gibt es jetzt eine alternative Version, in der statt des ersten
 der letzte Buchstabe des Straßennamens ausgewertet wird. Dies ist geeignet
 für Länder, wo viele Straßen mit dem gleichen Buchstaben beginnen (z.B. in
 Frankreich Rue ...).
 
 Ich würde ein MD5 oder aehnlichen Hash verwenden über den Straßennamen
 und darauf das meinswegen erste Zeichen.
 
 Damit ist es egal an welcher stelle des strings eine veränderung
 eintritt.
 
 Flo
 
 
 
 ___
 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] Access-Tags

Hallo Christian,
ich gebe dir nur zum Teil recht; die Tabelle war mir im Übrigen neu.

Zunächst eine Frage: Welche Anwendung hält sich an diese Tabelle?
Und gleich darauf aufbauend: gibt es eine maschinenlesbare Version, oder
muss jede Anwendung jede mögliche Änderung der Tabelle wieder manuell
einbauen?
Eine solche Tabelle ist wertlos, wenn Routing-Software sie nicht einsetzt.

Offensichtlich gibt es aber irgendein Projekt, dass sie einsetzt, aber
nicht auf der Seite genannt wird - die Formulierung designated - same
as yes but this road can optionally be prefered by some of your
metrics. deutet jedenfalls darauf hin.

Abgesehen davon ist ein Kernproblem der default-Frage nicht geklärt: Wie
erkenne ich als Mapper (!), ob ich bei einer bestimmten Straße nochmal
nachgucken sollte, was gilt, oder ob die default-Werte gelten?

Dass Routingsoftware die Default-Werte annimmt ist ja schön und gut -
aber wie unterscheidet man zwischen default und fehlend? Das ist nämlich
leider nicht möglich.
Für die Routingsoftware ist das egal - die muss mit fehlenden Daten
irgendwie halbwegs sinnvoll umgehen können und entsprechend defaults
annehmen; aber besser wäre es, wenn die Route nicht auf Annahmen,
sondern auf vorhandene Daten gestützt werden könnte.

Blöderweise gibt es aber eben mehrere verschiedene default-Semantiken:

1) Was nimmt Routingsoftware X an, wenn keine Angabe in den Daten steht?
   Diese Frage lässt sich mit einer solchen Tabelle dokumentieren und
   beantworten; notwendig dafür wäre aber auch die Angabe der Router,
   die sich danach richten, denn natürlich ist es keine völlig
   unsinnige Entscheidung, highway=track nur im Notfall in die
   Auto-Route mit einzubeziehen, womit es meist access=destination
   entsprechen dürfte.
2) Was ist ohne besondere Ausschilderung gültig?
   Bezieht sich neben den access-Tags insbesondere auch auf
   Geschwindigkeitsbegrenzungen, hat aber mit OSM und dem Mapping
   eigentlich wenig zu tun, sondern entspricht weitgehend (1) für
   Software, die sich an die Regeln hält.

Was ausgeschildert dransteht würde ich aber immer auch so eintragen.
Wenn an einer Straße innerorts (in DE) ein Tempo-50-Schild dransteht,
dann trage ich das so auch ein - obwohl innerorts per default 50 gilt.
Denn falls irgendwann die Geschwindigkeit generell auf 30 gesenkt werden
sollte, gelten bestehende Schilder mit 50 weiterhin. Es ändern sich also
die Regeln genau für die Fälle, wo dies nicht dransteht.

Aus den Gründen finde ich die Tabelle einen guten Ansatz - aber nur,
wenn die Erklärung dazu passt, und die fehlt bisher. Wer großflächig an
Bundes- und Landstraßen maxspeed=100 tagged, nur weil kein Schild
dransteht, erzeugt Probleme für mögliche Anpassungen der
Höchstgeschwindigkeit, z.B. auf 70, was jetzt schon auf einem großteil
der Landstraßen gilt.

Gruß
Peter

Am 27.02.2014 11:22, schrieb chris66:
 Am 27.02.2014 07:58, schrieb Manuel Reimer:
 
 Also eigentlich ein access = yes um alles zu erschlagen. Im Wiki wird von
 der Kombination access = yes aber abgeraten. Wie ist es also richtig und
 vollständig wenn man einen Waldweg mit oben genannten Schildern taggen will
 ohne unnötig viel Tag-Wirrwarr zu produzieren? Gilt bei Access-Tags alles
 was nicht verboten ist, ist erlaubt oder muss alles was erlaubt ist dran
 stehen? Wenn letzteres: Muss dann auch an jedem highway = residential die
 ganze Access-Tag-Flut dranstehen und wenn nein: Warum nicht?
 
 Moin,
 es gibt im Wiki eine Tabelle[1] mit den default-access-rights pro
 Wegklasse.  Das Setzen expliziter Tags ist also nur bei abweichenden
 Beschränkungen notwendig.
 
 Das OSM Verkehrszeichentool unterstützt bei der Findung der korrekten
 Tags:
 
 http://osmtools.de/traffic_signs/?signs=260,1026-37
 
 Chris
 
 [1]
 http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions
 
 
 
 
 ___
 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] Access-Tags

Am 27.02.2014 12:59, schrieb Falk Zscheile:
 Denn die Zugangsregeln nach den LWaldG variieren von Bundesland zu
 Bundesland.
Bewusst provokant:
Mit dem Argument kann man aber auch die Defaults für Staaten weglassen -
denn auch die variieren von Staat zu Staat.
Oder andersrum: So wie es eine Tabelle für Defaults pro Staat gibt,
könnte es auch eine verfeinerte Tabelle für weitere Gliederungsebenen
geben, in Deutschland eben Bundesländer.

Nur sinkt die Wahrscheinlichkeit, dass Anwendungen so etwas in dem
Detailgrad unterstützen, natürlich weiter.

Gruß
Peter

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

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

2014-02-26 Diskussionsfäden Peter Wendorff

Hallo Bernd,
was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete
Fragen stellen kann, was da was ist oder sein soll.
Dass ein Name am Goetheplatz fehlt, hattest du geschrieben.
Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert
werden sollte, hast du hier auch schon lesen können.

Wenn das nicht korrekt dargestellt wird, ist das meines Erachtens ein
Fehler im aktuellen Rendering - dann muss man eine entsprechende
Fehlermeldung machen; auch dazu wäre ein konkreter Verweis auf eine
Stelle in der Karte sinnvoll.

Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen,
die nur auf Hörensagen beruht, weil niemand außer dir das direkt
überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig).

Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen -
jedenfalls ist das meistens der Fall.

Soviel also zu deiner Frage was denn noch.

Gruß
Peter

Am 26.02.2014 08:46, schrieb Bernd Wurst:
 Hallo.
 
 Am 26.02.2014 08:31, schrieb Walter Nordmann:
 Bernhard Weiskopf wrote
 Wie trägt man das jetzt ein? Genügt name = ... nicht mehr?
 Ja, name=* reicht nicht mehr aus - und das ist gut so!
 
 Ja, aber selbst highway=... und name=... reicht scheinbar nicht aus? Was
 denn noch? render_this_name=yes oder wie? :-)
 
 
 
 ___
 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] Keine Namen in Mapnik und anderen Karten

2014-02-26 Diskussionsfäden Peter Wendorff

Am 26.02.2014 11:20, schrieb Bernd Wurst:
 Hallo Peter.
 
 Zunächst: Watch your tone. Ehrlich.
 
 
 Am 26.02.2014 11:00, schrieb Peter Wendorff:
 Hallo Bernd,
 was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete
 Fragen stellen kann, was da was ist oder sein soll.
 Dass ein Name am Goetheplatz fehlt, hattest du geschrieben.
 
 Nein, habe ich nicht geschrieben.
Stimmt, du hattest nur gefragt (Mail von gestern, 25.2., 23:12):
 Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits
 bekannten Platzes auf der Karte erscheint?
 Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt.

Vielleicht hab ich da also einen konkreten Fehlerfall reininterpretiert,
den es nicht einmal gab oder gibt - dann entschuldige ich mich für den
Ton (erlaube mir aber, die Frage zu stellen, was du damit eigentlich
erfragen wolltest).

 Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert
 werden sollte, hast du hier auch schon lesen können.
 
 Ja, betrifft mich aber null komma gar nicht.
Sondern? Was betrifft dich denn dann? Denn die Frage hast du ja schon
gestellt, zumindest ist die Mail bei mir so eingegangen. Was genau du
brauchst, hast du ja nicht geschrieben - ich weiß nur, dass es um
irgendeinen der Goetheplätze geht, die es gibt.

 Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen,
 die nur auf Hörensagen beruht, weil niemand außer dir das direkt
 überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig).
 
 Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle
 Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach
 irgend einen x-beliebigen Waldweg an.
Das Waldweg-Thema ist ein anderes und doch geklärt - da fehlt noch die
Render-Regel, die beim Catch-All weggefallen ist, da kann man gucken, ob
es ein Ticket gibt und bei Bedarf eins erstellen, einen Patch einreichen
etc., darauf habe ich mich aber nicht bezogen.

 Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen -
 jedenfalls ist das meistens der Fall.
 Soviel also zu deiner Frage was denn noch.
 
 Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer
 name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein*
 area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben
 kein area-Tag.
das area-Tag ist nicht ausschlaggebend fürs Rendering; es ist aber
notwendig, um ein lineares feature als Fläche darzustellen.

waldwege: Da fehlt die Rendering-Regel, Goetheplatz: da fehlt das Wissen
darüber, was da überhaupt drangetagged ist - und das verweigerst du ja
weiterhin (oder es interessiert dich tatsächlich nicht mehr).

 Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige
 wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man
 machen, muss dann aber auch alle etablierten Werte berücksichtigen.
 Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein.
 
 Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf
 zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich
 bitte auch darum kümmern dass das gefixed wird.
Ich glaube, bei konkreten Fehlermeldungen (wie gesagt: ich red vom
Goetheplatz) würde das jemand übernehmen; spätestens auf eine direkte
Bitte hin. Aber aus wagen Aussagen ein Ticket zu bauen ist etwas mehr
Arbeit als sich bei github anzumelden.

Wer das verbockt hat hat im Zuge dessen etliche andere Fehler behoben
und damit die Gesamtlage im Rendering eher verbessert; zumindest aber
langfristig eine richtige Grundlage gelegt, um gezielt eine korrekte
Darstellung genau da zu erzielen, wo sie gewünscht wird.

Wenn Du mit github ein Problem hast, frag doch einfach freundlich nach,
beschreibe das Problem konkret und so, wie du es auch in ein Ticket
schreiben würdest, und bitte darum, dass daraus jemand ein Ticket macht,
ich bin sicher, dass dir das nicht verwehrt wird.

Gruß
Peter

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

Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

2014-02-25 Diskussionsfäden Peter Wendorff

Hallo Bernhard,
warum sollte area=yes, name=foo denn gezeichnet werden?
area=yes sagt schließlich nichts anderes aus, als dass ein OSM-Objekt,
das nicht aufgrund irgendwelcher anderer Attribute eindeutig als Linie
oder Fläche zugeordnet werden kann, definitiv eine Fläche ist.
So kann man dicke Stadtmauern, Hecken, Wälle, Deiche etc. als Fläche
einzeichnen.
Mehr tut area=yes aber nicht, und wenn das tatsächlich DER Indikator in
Mannheim ist, um die benannten Blöcke darzustellen, dann ist das ein
Problem.

Für einen Platz wie den Goetheplatz kommt das name-Tag aber eigentlich
auch nicht vom area=yes, sondern vom highway=residential, oder
highway=pedestrian, denn die werden mit Namen gerendert (sowie einige
andere highway-Werte auch). area=yes entscheidet allerdings darüber, ob
der Name entlang der Linie (nämlich z.B. bei einer ringförmigen Straße)
oder auf der Fläche (eben bei Plätzen oder als Fläche eingetragenen
Straßen) auf der Karte erscheinen soll.

DASS der Name dargestellt wird, hat aber mit area=yes|no nichts zu tun.

Der Goetheplatz ist also highway=pedestrian, wenn er Fußgängerzone ist,
amenity=parking, wenn es sich um einen Parkplatz handelt, alternativ
Marktplatz oder was auch immer - was es eben ist.
Wenn kein Tag passt, brauchen wir dafür ein Neues, aber das hat mit dem
Rendern der Namen nicht viel zu tun (obwohl dann eben neuerdings für ein
neues Tag auch eine neue Render-Regel notwedig wäre, und das ist gut so).

Gruß
Peter


Am 25.02.2014 23:12, schrieb Bernhard Weiskopf:
 In Mannheim ist Mapnik zurzeit kaum noch zu gebrauchen.
 
 Die Wohnstraßen der Vororte tragen noch Namen. Aber die Quadrate der
 gesamten Innenstadt sind namenlos und die Straßen in den
 Naherholungsgebieten zwischen den Vororten (highway = track) werden nun auch
 namenlos angezeigt, obwohl sie Straßennamen tragen, bei Fußwegen (path oder
 footway) mit Namen genauso.
 
 Sogar bei öffentlichen Zufahrtswegen zu Höfen (highway = service) wird der
 Straßenname nicht mehr angezeigt.
 
 Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits
 bekannten Platzes auf der Karte erscheint?
 Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt.
 
 Bernhard
 
 
 -Ursprüngliche Nachricht-
 Von: Frederik Ramm [mailto:frede...@remote.org]
 Gesendet: Dienstag, 25. Februar 2014 22:35
 An: talk-de@openstreetmap.org
 Betreff: Re: [Talk-de] Keine Namen in Mapnik und anderen Karten

 Hi,

 On 25.02.2014 22:18, Bernhard Weiskopf wrote:
 Kennt jemand den Grund, warum die Karten kaum noch Texte enthalten
 sollen?

 Das ist eine Suggestivfrage. Es gibt keinen Grund, warum die Karten kaum
 noch Texte enthalten sollen, denn die Karten sollen nicht kaum noch Texte
 enthalten.

 Unser Mapnik-Stylesheet hat historisch eine sogenannte catch-all-Regel
 für Dinge mit Namen enthalten. Diese Regel besagte, vereinfacht gesagt:
 Egal was es ist, wenn es einen Namen hat, dann schreib ihn irgendwie
 hin.

 Das führte immer wieder zu seltsamen Stilblüten in den Karten -
 irgendjemand zeichnet z.B. ein boundary=air_traffic,
 name=Flugbeschränkungsgebiet R123, und obwohl Mapnik keine Render-
 Regeln für Flugbeschränkungsgebiete hat, hat er trotzdem schön irgendwo
 entlang einer unsichtbaren Linie Flugbeschränkungsgebiet R123
 geschrieben.

 Das war unerwünscht; erwünscht ist vielmehr (in aller Regel), dass Namen
 nur für exakt die Objekte auf der Karte erscheinen, die selbst auch
 gezeichnet werden.

 Dazu müssen also die catch-all-Regeln entfernt und durch spezielle
 Beschriftungsregeln für genau die gezeichneten Objekte ersetzt werden.

 Das ist im großen und ganzen auch gelungen, aber einige Labels sind dabei
 unter die Räder gekommen - die meisten unabsichtlich; in einigen Fällen
 war es vielleicht wirklich nicht beabsichtigt, einen bestimmten Objekttyp
 einzuzeichnen.

 Also, langer Rede kurzer Sinn: Keine Panik, sie sind nicht hinter Dir her,
 und
 über kurz oder lang wird das alles wieder gut.

 Bye
 Frederik

 --
 Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09 E008°23'33

 ___
 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 mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Der VRR Stellt sich vor

2014-02-22 Diskussionsfäden Peter Wendorff

Hallo Christoph,
generell interessiert wär ich schon, aber ich sträube
mich noch ein bisschen vor dem Aufwand mit Anfahrt
aus Paderborn und Abends zurück. ;)

Eingetragen hab ich mich vor allem deshalb nicht bisher,
weil noch einige Termine offen sind für die Woche,
auf die ich keinen Einfluss habe; das sollte sich aber
bis Dienstag erledigt haben.

Außerdem bin ich als nun eigentlich kein Vertreter der
lokalen Community.

Ich trag mich aber mal als vielleicht ein vorerst.

Gruß
Peter



Am 22.02.2014 17:53, schrieb Christoph (TheFive@OSM):
 Hi,
 
 der VRR (Verkehrsverbund Rhein Ruhr) möchte enger mit OSM Zusammenarbeiten, 
 und hat uns angeschrieben.
 
 Die Einladung ging schon über diverse lokale Mailinglisten und ist auch schon 
 im Forum geposted worden.
 
 Da die Teilnahme von OSM noch Potential nach oben hat, nutze ich noch einmal 
 Talk-DE damit das auch überall
 ankommt.
 
 Organisation unsererseits findet hier:
 http://wiki.openstreetmap.org/wiki/VRR/Zusammenarbeit
 Statt, da ist auch das Einladungsschreiben.
 
 Der VRR hätte gerne in 4 Tagen eine erste Rückmeldung ob wir als Hunderschaft 
 oder mit 1nem Abgesandten kommen.
 
 
 
 Christoph 
 
 
 
 ___
 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] D-A-CH

2014-02-21 Diskussionsfäden Peter Wendorff

Hallo Frederik,
wie groß ist denn der Nachteil beim Zusammenbauen? Das Script, das Du
angibst, ist ja erstmal nicht so besonders kompliziert; wie viel
Laufzeit und Speicher kostet es, entsprechende Extrakte zusammenzubauen?

Naiv und ohne Details des osmosis-codes zu kennen müsste doch eigentlich
(wenn man voraussetzen kann, dass die Versionen aller Objekte in allen
Teilextrakten zusammenpassen) einmal durch alle osm/pbf-Dateien geparst
werden, während die bereits übernommenen ObjektIDs gespeichert sind.

Das ist also weitgehend lineare Laufzeit in der Größe der
Eingabedateien; und wenn man möchte, kann man statt einer Ergebnisdatei
ja auch direkt die weitere Verarbeitung - DB-Import etc. anhängen.

Eine Umsetzung für unterschiedliche Shells (notfalls einschließlich
Windows) sollte auch machbar sein.

Wenn also der Overhead zumindest bestimmter Nachbarextrakte nicht zu
groß ist, ist es vielleicht eine Überlegung wert, so 'ne Art
Download-Paket-Option anzubieten: Man lade DE, A, CH in einen Ordner, in
dem auch das merge-Script liegt und starte das Script (das kann für
langsame Netzwerkverbindungen bei Bedarf auch schon während des
downloads loslaufen); der Rest ergibt sich von selbst.

Oder übersehe ich dabei was wichtiges?

Gruß
Peter

P.S.: Deshalb sind natürlich manche Extrakte, gerade für Kontinente etc.
trotzdem sinnvoll, weil es bei denen für die Speicherung der schon
übernommenen Objekte schon für einen nicht allerneuesten Heim-PC elend
viel Speicher braucht...

Am 20.02.2014 23:25, schrieb Frederik Ramm:
 Hallo,
 
 On 20.02.2014 21:59, Christian H. Bruhn wrote:
 Ist der Bedarf nach DACH-Daten tatsächlich so groß? Oder wollen die
 Leute nicht eher BYBWACH?
 
 Das ist ja schon das Alpen-Extrakt ;)
 
 Der Bedarf nach DACH ist zumindest der am häufigsten geäußerte. Ich
 hab mich bislang immer geziert, weil ich wusste, dass dann natürlich all
 die Fragen nach Benelux, Deutschland+Polen, Ostsee-Anreinerstaaten und
 und und kommen.
 
 Im Grunde kann man sich benachbarte Regionen mit Osmosis zusammenbauen,
 hier z.B. ein Skript für ein
 Benelux+Niedersachsen+Nordrheinwestfalen+Rheinlandpfalz-Extrakt:
 
 SCHNIPP
 
 #!/bin/sh
 
 set -e
 
 BASE=http://download.geofabrik.de/europe;
 PIECES=germany/niedersachsen germany/nordrhein-westfalen
 germany/rheinland-pfalz belgium netherlands luxembourg
 OUTPUT=meinfile.osm.pbf
 OSMOSIS=/srv/osmosis/bin/osmosis
 
 # hierunter nix aendern
 
 NUM=0
 MERGE=
 OSMOSISFLAGS=
 export NUM MERGE OSMOSISFLAGS
 
 for p in $PIECES
 do
NUM=`expr $NUM + 1`
wget -qO$NUM.osm.pbf $BASE/$p-latest.osm.pbf
OSMOSISFLAGS=$OSMOSISFLAGS --read-pbf $NUM.osm.pbf $MERGE
MERGE=--merge
 done
 $OSMOSIS $OSMOSISFLAGS --write-pbf $OUTPUT
 
  SCHNAPP
 
 Das sollte eigentlich auch die wegen Überschneidung doppelten Ways
 richtig rauswerfen.
 
 Bye
 Frederik
 


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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-17 Diskussionsfäden Peter Wendorff

Ähm?
Sorry, kann mir irgendjemand erklären, wie Dirk das hier meint? Ich
versteh's immer noch nicht.
Ich versuch noch einmal, meine Verständnisschwierigkeiten zwischen den
Zeilen deutlich zu machen.

Am 17.02.2014 18:51, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Und wie kommen dann die Kacheln zum Browser des Nutzers?
 
 Die entsprechenden Daten werden über die API abgerufen, die
 entsprechende Kachel verlinkt, und der Browser stellt sie dar.
Wer ruft jetzt welche Daten wo ab? Wie sieht der Link aus, den der
Browser dann aufruft, bevor er die daraus bezogene Kachel darstellt?

 Es geht hier AUSSCHLIEẞLICH um den Abruf der Daten für die
 entsprechende Kachel aus der API. Nicht um das Einbinden, den URL, oder
 das Rendern der Wbesite im Browser. Da ist eine komplett andere
 Baustelle.
Nein, ist es nicht, denn der Abruf der Daten aus der API, wie du es
bezeichnest, ist doch genau die Kachel. Der Abruf passiert gerade - und
zwar ausschließlich - über die URL, die eingebunden wird; der
entsprechende Schlüssel müsste also an die URL angehängt werden, und
damit für den Browser ersichtlich sein (sagte ich das nicht bereits?).

Die zwei möglichen technischen Alternativen, die ich sehe, sind:
1) Sitzungsschlüssel zwischen Server und serverseitiger Anwendung (bzw.
Server und closed-source-komponente) aushandeln, damit dann clientseitig
den Key verschlüsseln. Aufwand: Das ganze durchs CDN propagieren etc.,
und bei langem Aufenthalt auf der Seite muss der Schlüssel auch noch
regelmäßig neu ausgehandelt werden, damit er nicht geklaut werden kann;
2) Der jeweilige Webserver muss als Proxy für die auf seinen Seiten
ausgelieferten Tiles fungieren, also nicht mehr der Browser läd von
tile.osm.org, sondern der webserver von meineseite.de läd von
tiles.osm.org und gibt die Kacheln dann unter tiles.meineseite.de
weiter. Machbar, aber problematisch, was a) Traffic insgesamt b)
komplexität auf OSM-Administrationsseite, c) Aktualität von Kacheln und
vor allem d) Komplexität für den kleinen Webseitenbetreiber, der mal
eben eine Karte einbinden will, angeht.
Insbesondere letzteres ist immer noch ein häufig genutztes Argument für
die Google-Maps-API, obwohl das bisher nicht mehr stimmt - mit der
Lösung wäre das nur allzu wahr.

 P.S.: Ja, man kann das ohne lösen,  indem tatsächlich die
 Webseiten-Serveranwendung direkt mit dem Tileserver redet,
 verschlüsselt ein Sitzungstoken aushandelt
 
 Na ja, oder eben dass in der Konfiguration des Wbeservers – bzw. genau
 genommen in dem Teil der Webanwendung, die auf dem Server, außerhalb
 des Zugriffs durch den USer, der API-Key hinterlegt ist.
Du hast immer noch nicht erklärt, wie der API-Key dann ohne Zugriff des
Users dazu führen soll, dass eben der User die Kacheln sehen kann -
warum die beiden mir einleuchtenden Varianten, die du da im Kopf haben
könntest, nicht funktionieren, hab ich oben erklärt.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Also kannst Du Anwendung und Browser voneinander unterscheiden?
Spannend...
Am UA-String ja offensichtlich nicht, denn dann könnte ja auch weiterhin
jede Anwendung sich einen Browser-UA-String suchen und den nutzen, ohne
dass das ein Problem wäre.

Abgesehen davon: Was ist ein Browser, was eine Anwendung?
Ist eine Facebook-App ein Browser, wenn sie Links verfolgt? Ist
Thunderbird ein Browser, weil man auch innerhalb von Thunderbird unter
Nutzung der Gecko-Engine Webseiten direkt öffnen kann?
Ist ein Browser-Plugin für Mails noch ein Browser? ist ein
Browserplugin, das die vorhandene Adressbuchfunktion um eine Karte
erweitert, die die Kontakte darauf darstellt?

Inwiefern würde eine solche Lösung das Verfahren einfacher,
fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter machen?

Gruß
Peter

Am 16.02.2014 12:27, schrieb Dirk Sohler:
 Christoph schrieb:
 Verstehe ich das richtig ?
 Du möchtest jedem user einen account verpassen? Das muss dann
 konsequenterweise auch bei Browsernutzung passieren.
 
 Jedem User, der eine Anwendung != Browser benutzt, die auf die API
 zugreift.
 
 Grüße,
 Dirk
 
 
 
 ___
 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] Mapnik Administration blockt QLandkarteGT

Hallo Dirk,
das ist uns und auch den Admins schon klar, dass man das umgehen kann.
Und auch, dass mutwillige Sabotage, zu der ich das zählen würde, damit
nicht ausschließen kann.

Die Pflicht zu einem gültigen UA-String hat aber nicht in erster Linie
den Hintergrund, böswillige Nutzer wie dich ;) direkt zu kriegen,
sondern gutwillige Entwickler, die zurecht erstmal davon ausgehen, dass
sie testweise und für Software, die mal eine Handvoll Kacheln braucht,
die öffentlichen osm-kacheln nutzen dürfen, darauf hinweisen zu können,
dass ihre Software eben wohl doch nicht nur eine Handvoll Kacheln zieht.

Insbesondere ist eben auch nicht ein Programm betroffen, was ähnlich zu
einem Browser genau die Kacheln herunterläd, die zur Darstellung der
Karte gebraucht werden - solange das Programm nicht verkauft wird, ist
dies eine analoge und normalerweise tolerierte Anwendung (vorausgesetzt,
die Attributierung ist korrekt).

Hier geht es aber um ein Programm, das unter anderem den Massenhaften
Download tausender Kacheln erlaubt, und genau das ist nicht mehr erlaubt.

Wenn Du persönlich wget anweist, sich als Firefox oder sonstwas
auszugeben, verstößt Du persönlich genauso gegen die Tile Usage Policy,
denn die besagt ganz eindeutig, dass ein sinnvoller, korrekter UA
gesendet werden soll, der die Identifikation der Anwendung erlaubt. Mit
gesundem Menschenverstand weißt vermutlich auch du, dass damit nicht
gemeint ist, dass sich ScrapeOSM (tm) als wget ausgeben darf, selbst
wenn es sich um ein Shellscript handelt, das wget für den eigentlichen
Download nutzt.

Da jetzt weiter zu diskutieren hilft auch nicht besonders - ganz
auszuschließen ist Missbrauch nicht, sicher; aber nur weil nicht jeder
Diebstahl aufgeklärt wird, verlangst du ja auch im Strafrecht nicht,
Diebstahl zu erlauben, oder?

Es geht nicht um die einwandfreie Identifikation eine Clients, sondern
um das Finden von möglicherweise ungünstig programmierten Anwendungen,
und wie du am Beispiel von QLandkarte merkst, scheint auch die
Weigerung, einen sinnvollen UA-String anzugeben, nicht sicher vor dem
Block zu schützen.

Du hast immer noch keine Alternative ohne Account-Pflicht (die ja, wie
wir bereits festgestellt haben, auch nicht funktioniert, solange online
ohne Account Kacheln dargestellt werden können sollen) vorgestellt. Bis
dahin brauchen wir glaub ich kaum weiterzudiskutieren.

Gruß
Peter

Am 16.02.2014 12:39, schrieb Dirk Sohler:
 Simon Poole schrieb:
 - zu behaupten, dass eine Massnahme nicht funktionieren kann
 
 Bitte genau lesen. Ich wies jedenfalls völlig richtig darauf hin, dass
 der User-Agent nicht dazu geeignet ist, einen zugreifenden Client
 (anders als ein Token oder besser ein Useraccount) einwandfrei zu
 identifizieren, und daher als alleiniges Erkennungsmerkmal schlicht
 ungeeignet ist.
 
 Ich könnte wget anweisen, sich als „wget/1.15“ auszuweisen, oder aber
 auch als „Skynet/1.0“ oder als ein aktueller Firefox. In allen drei
 Fällen kann ich massenhaft scriptgesteuert Kacheln runterladen, bis die
 Leitung glüht, und im letzten Fall kann ich nicht mal gesperrt werden
 (IPs lassen sich wechseln), und alle drei Varianten ist der
 entstandene Traffic sogar ein paar Byte je Abruf größer als ohne UA.
 
 Die Maßnahme an sich funktioniert in einem gewissen Rahmen, nur stützt
 sie sich auf etwas, das vom Konzept her von Grund auf als technisch
 komplett unverifiziert einzustufen ist.
 
 Grüße,
 Dirk
 
 
 
 ___
 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] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 15:13, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Also kannst Du Anwendung und Browser voneinander unterscheiden?
 
 Mittels anwendungsspezifischem Token, der aufgrund der API nur durch
 entsprechende Header übermittelt werden kann eher, als über einen
 simplen String, in den jeder reinschreiben kann, was er will.
Wenn jemand fälschen will, dann ist das auch da kein Problem, den Token
zieh ich mir eben von osm.org direkt.
Dazu gehört dann außerdem noch die Authentifizierung über alle
Tilecache-Instanzen etc pp - nicht grade wenig Aufwand für minimal mehr
Hilfe.
 
 
 Abgesehen davon: Was ist ein Browser, was eine Anwendung?
 
 Stelle dich doch bitte nicht bitte dümmer, als du bist.
 
 Hier: Browser = Das Ding, mit dem du im WWW (!= „das Internet“) Seiten
 aufrufen kannst, und eben auch die OSM-Seite;
also:
Firefox, Thunderbird, Thunderbird-Adressbuch mit OSM-Karten-Erweiterung
(gibt's die? wär praktisch...),
Internet-Explorer, jede Anwendung, die die entsprechende
IE-ActiveX-Komponente benutzt, um Webseiten darzustellen,
wget (cool, kann www-Seiten aufrufen...),
...
 und Anwendung: Spezielles
 Programm, das zum Abruf der OSM-Kacheln über die OSM-API verwendet
 wird, ohne darüber hinaus andere Dienste im Internet (vgl. WWW) nutzen
 zu können.
Okay, also wenn meine App Twitternachrichten und OSM-Kacheln darstellt,
ist es demnach ein Browser?

 
 Ist [beliebige Anwendung] ein Browser, wenn sie Links verfolgt?
 
 In dem hier verwendeten Zusammenhang ist eine Anwendung dann ein
 Browser, wenn sie die WWW-Seite benutzt. Wenn sie die API benutzt,
 nein. 
Und wo ist der Unterschied zwischen WWW-Seite und API?
Du bist ja derjenige, der mit Umgehungsmöglichkeiten argumentiert.
Wenn ich also www.osm.org mit entsprechendem permalink aufrufe und alle
damit verbundenen Kacheln mit runterlade, ist das wieder ok? wenn ich
das hundertmal tue, auch?

Aber da du nur provozieren willst, brauche ich dir das sicher
 nicht zu erklären, da du es bereits weißt.

Ich will nicht provozieren.
Du kritisierst eine seit langem angewandte Praxis, die weitgehend
funktioniert; und hängst die auch noch an einem Fall auf, der
offensichtlich ja eben sogar gefunden wurde.
Du äußerst aber Kritik, ohne einen funktionierenden und mit vertretbarem
Aufwand umsetzbaren Gegenvorschlag anzubringen.

 Inwiefern würde eine solche Lösung das Verfahren einfacher,
 fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter
 machen?
 
 Die Vorteile eines anwendungsspezifischen Tokens sind, sofern der Token
 geheim bleibt (Closed-Source oder sonstwie verschlüsselt, und nicht
 einfach so durch andere Nutzbar, oder über Sniffer aus den übertragenen
 Datenpaketen auslesbar), dass die Anwendung zuverlässig identifiziert
 werden kann.
CLosed-Source - cool, also auch noch alle OpenSource-Software im
OSM-Ökosystem rausschmeißen, weil damit das System nicht funktioniert.
Ich glaube, du hast das Grundprinzip immer noch nicht verstanden, und
das heißt Fairness und Offenheit.

Das Tool von Github kann keiner mal eben forken, weil das Token nicht
drin ist (und nicht drin sein kann, denn sonst wär das ja nicht mehr
verschlüsselt), dafür muss man sich zusätzlich bei OSM anmelden -
wunderbar... - aber irgendwie eben nicht Offen.

 Die Vorteile eines „Accountzwangs“ bei einer Anwendung (vgl. Definition
 weiter oben) ist, dass man eindeutig einen Useraccount identifizieren
 kann, und man diesen Gezielt sperren kann. Natürlich kann ein Anwender
 sich einfach einen neuen Account anlegen, aber ein Entwickler kann auch
 seiner Anwendung den Firefox-UA-String verpassen.
 
 Aber mal andersherum gefragt: Inwiefern ist alleinig die Auswertung
 eines simplen Strings fälschungssicher? Was hindert einen Entwickler,
 der alle Tiles runterladen will eher daran, das technisch umzusetzen?
 Ein beliebig änderbarer String, eine App-Registrierung um einen Token
 zu bekommen, oder die Notwendigkeit eines Useraccounts?
Abgesehen vom Aufwand auf dem Server, um die Token-Lösung einzusetzen -
wie würdest du das für, sagen wir, JOSM umsetzen wollen? Steht der Token
im Code und damit im SVN? Steht der Token nur im Build und auch da
Verschlüsselt? Wie passt das dann mit OpenSource zusammen? Soll sich
jeder Entwickler, der mal einen Patch einreicht, extra registrieren?

Und wenn ja, dann haben wir entsprechend hunderte Registrierungen, was
hindert dich als denjenigen, der sich hier als der Böse aufspielt, der
alles aushebeln kann, daran, deine Anwendung hundertmal zu registrieren
und und den Token immer wieder zu wechseln?

Sorry, irgendwie überzeugt mich das noch nicht.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 16:34, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Du hast immer noch keine Alternative ohne Account-Pflicht
 […] vorgestellt.
 
 Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key), wie
 bereits mehrfach erwähnt.
Wie bereits mehrfach erwähnt untauglich, solange du keine Lösung für den
Overhead in der Infrastruktur und zusätzlich gerade bei
OpenSource-Software für folgende Probleme präsentierst:

- Wie verhinderst Du, dass Leute wie Du dann hundert API-Keys für eine
Anwendung nutzen?
- Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal was
committen, einen eigenen entwicklerspezifischen API-Key haben müssen?
bzw. wenn Du das nicht für notwendig hältst,
- wo steht der API-Key in einer OpenSource-Anwendung, wenn nicht im
Quelltext-Repository?

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 17:13, schrieb Dirk Sohler:
 Peter Wendorff schrieb:
 Am 16.02.2014 16:34, schrieb Dirk Sohler:
 Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key),
 wie bereits mehrfach erwähnt.

 Wie bereits mehrfach erwähnt untauglich, solange du keine Lösung für
 den Overhead in der Infrastruktur […] präsentierst:
 
 Sicherheit und Komfort schließen sich leider gegenseitig aus :(
 
 
 - Wie verhinderst Du, dass Leute wie Du dann hundert API-Keys für eine
 Anwendung nutzen?
 
 Genau so, wie die OSM-Admins aktuell Missbrauch verhindern: Gar nicht.
Also bietest Du als Alternative für ein nur sehr eingeschränkt
funktionierendes System ein System, was genauso eingeschränkt
funktioniert, aber zusätzlichen Organisationsoverhead benötigt - hüpsch...
 
 
 - Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal was
 committen, einen eigenen entwicklerspezifischen API-Key haben müssen?
 
 Bereits nötiger User-Account.
Häh? Ich red von JOSM-Entwicklern, die am JOSM-Code arbeiten, nicht die
mit JOSM osm-Daten hochladen.
JOSM ist hier nur ein Beispiel von vielen Programmen, die irgendwo
OSM-Tiles benutzen, QLandkarteGT passte nur deshalb nicht, weil da ja
offensichtlich praktisch nur ein Entwickler dransitzt.

 - wo steht der API-Key in einer OpenSource-Anwendung, wenn nicht im
 Quelltext-Repository?
 
 Anwendungen müssen eine Funktion behalten, über die der Anwender
 entweder selbst einen API-Key eingeben kann, oder ein vorhandener
 Useraccount kann für den Zugriff auf die API verwendet werden.
Also nicht für jeden Entwickler einen Key, sondern sogar für jeden User.
Wie sieht das dann jetzt mit Privacy aus? Du möchtest also jeden
einzelnen User tracken können (denn nichts anderes tust du damit).

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 20:26, schrieb Dirk Sohler:
 Frederik Ramm schrieb:
 Und genau diese Leute sind auch die, die trivialerweise Deine API
 Key-Vorschläge umgehen. Was soll denn an dem API Key besser sein
 
 Einen API-Key muss man beantragen, ggf. mit Authentifizierung 
Wie soll die funktionieren?

Mit Mailadresse? gut, krieg ich tausende, und irgendwer muss sich darum
kümmern, darunter die fake- und wegwerfadressen rauszufiltern - das
Problem haben wir schon mit dem UA-String, also verbessert es nicht.

Mit Persönlichen Daten? Post-Ident? Und das auch noch weltweit? Viel
Spaß. Abgesehen vom finanziellen ein enormer logistischer Aufwand.
oder
 sonstiger Validierung, und ist mit wesentlich mehr Aufwand verbunden,
 als ein paar Zeichen in eine Variable zu schreiben.
Eben: Der Aufwand ist immens, sobald man ernsthaft authentifizieren
wollte, und da den vermutlich niemand wirklich machen will (und außerdem
ja auch noch die Webseiten funktionieren sollen). Die Fragen in
Kombination mit OpenSource-Software haben wir ja an anderer Stelle
bereits angerissen.

Welche Lösung genau schlägst Du vor, und warum ist sie besser als die
(natürlich nicht perfekte) aktuelle Vorgehensweise?

Betrachte dabei:
- Aufwand auf Administrativer Seite von OSM (technisch und ständig
personell)
- Kosten auf beiden Seiten (OSM und Entwickler und Nutzer entsprechender
Anwendungen)
- Vereinbarkeit mit Offenheit von OSM und so weiter.

Ich weiß, ich hab die Frage schon mehrfach gestellt in diesem Thread,
aber bisher flamest du weiter über den ach so schlechten status-quo,
ohne diese Frage zu beantworten.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

Am 16.02.2014 22:59, schrieb Dirk Sohler:
 Henning Scholland schrieb:
 Was wäre denn jeweils die dahinterstehende Anwendung?
 
 Die PHP- Python- Ruby- oder Wasauchimmer-Anwendung, die dafür sorgt,
 dass beim Aufruf eine Seite generiert und an den Browser gesendet wird.
 
 
 Wenn der nun an jeden Tileaufruf ein key=12345 dran hängt hilft das
 genau 0,0 mehr als die aktuelle Methode.
 
 Darum wird das auch in der dahinterstehenden Anwendung erledigt. Da
 bekommt der Nutzer nichts von mit.
Ach?
Und wie kommen dann die Kacheln zum Browser des Nutzers?

Bisher kriegt der Browser von der Webanwendung auf dem Server den
Befehl, Kartenkacheln von einem anderen Server (nämlich dem
osm-tileserver) abzurufen und anzuzeigen.

Wenn der Webserver den key=12345 dranhängt, du sonst aber nichts
änderst, dann bekommt also in Zukunft der Browser (!) den Befehl,
Kacheln von einem anderen Server abzurufen, und dabei den key=12345 zu
benutzen.
Ach so... stimmt, dann weiß das also der Browser, und ach so, dann weiß
ich als böser Angreifer das aber auch, weil was der Browser tut, kann
ich mir angucken; und ich muss damit nichtmal einen Browser im engeren
Sinne benutzen; ein HTTP-Aufruf reicht.

Denken wir also mal nach: Dan kriegt also der Nutzer doch was davon mit.

Gruß
Peter

P.S.: Ja, man kann das ohne lösen,  indem tatsächlich die
Webseiten-Serveranwendung direkt mit dem Tileserver redet, verschlüsselt
ein Sitzungstoken aushandelt, nur dieses an den Browser sendet und in
der Server-Server-Kommunikation dann aushandelt, welche Kacheln wie
dabei heruntergeladen werden dürfen/sollen, aber abgesehen davon, dass
das nun wirklich irre aufwändig ist, funktioniert es nicht für statische
Webseiten, die zwar eine Slippy-Map anzeigen, aber eben keinen
serverseitigen Code ausführen; und damit gerade für die kleinen Seiten,
die durchaus gewollt erlaubt sind, zum Teil unbrauchbar.

 
 
 Grüße,
 Dirk
 
 
 
 ___
 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] Mapnik Administration blockt QLandkarteGT

Am 17.02.2014 01:23, schrieb NopMap:
 
 Hi!
 
 Um mal wieder einen konstruktiven Vorschlag ins Spiel zu bringen: Es wäre
 technisch möglich, einen korrekten User Agent und eine Entlastung der Server
 miteinander zu verbinden.
 
 Das könnte so ähnlich funktionieren wie auf meinem Server:
 - eine Massendownloader-Applikation identifziert sich mit ihrem User Agent
 - der Server leitet alle Aufrufe mit den User Agents bekannter Downloader
 z.B. mit einem Rewrite auf eine andere URL um, die nur vorhandene Tiles
 ausliefert aber kein Rendern auslöst. Das erzeugt keine nennenswerte Last
 - Aufrufe mit fehlenden oder unbekannten Agents oder Browser laufen normal
 weiter und werden wie gehabt ab einer bestimmten Anzahl von Anfragen
 gedrosselt
 
 Vorteile:
 - Server wird von unnötigen Renderanfragen entlastet
 - korrekter User Agent und Kooperation werden belohnt
 - in vorgerenderten oder häufiger angesehenen Gebieten liegen die Tiles
 sowieso auf dem Server rum
 
 Nachteil:
 - Funktioniert nicht in den höchsten Zoomleveln
Weiterer Nachteil:
Funktioniert nur, solange tatsächlich die Render-Queue das (einzige)
Argument ist, die Usage Policy so auszulegen wie sie ausgelegt ist.

Wenn es zusätzlich darum geht, den Traffic auf sinnvolle Anwendungen zu
beschränken, hilft das natürlich nicht. Da kenne ich aber die Kosten
oder Sponsoring-Regelungen der entsprechenden Serverstandorte nicht, ob
das ausreicht.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-15 Diskussionsfäden Peter Wendorff

Am 15.02.2014 12:45, schrieb Dirk Sohler:
 hike39 schrieb:
 Mit Version 1.7.6 von QLandkarteGT stellt der Entwickler die
 Unterstützung von OSM-Karten ein.
 
 Pfui :(
 
 
 Die Brgründung:
 .
 here is a quick release to end the OSM misery. I am still not
 convinced that transmitting the user-agent string does really help to
 prevent any misuse. […]
 
 Damit hat er KOMPLETT recht. Der User-Agent sagt absolut rein GAR
 NICHTS darüber aus, welcher Client auf den Server zugreift, da der
 User-Agent ohne weiteres verändert werden kann.
Richtig ist vermutlich, dass es Missbrauch nicht verhindert.
Unabsichtlichen Missbrauch verhindert es jedoch schon, denn einige
Entwickler kommen ja erst durch die Blockade auf die Idee, dass da
Server dahinterstecken, die nicht unlimitiert sind, und dass ein
Missbrauch in gewissem Ausmaß zu vermeiden ist.

Die OSM-Tiles sind eben gerade kein Freibier-Service für alle
einschließlich Entwickler, die ihren Kunden genrne kostenlose Karten
ohne Mehraufwand anbieten wollen.

Was hat QLandkarte noch für Layer?
Nur die OpenCycleMap - na hübsch...
da ist ja die Aussage von der Webseite nur minimal übertrieben  to
display your GPS data on a variety of maps.
Klar, das geht - aber dafür jedesmal die TMS-URL selbst raussuchen? Das
kann doch auch nicht die Lösung sein; zumal die Anwendung dabei ja
trotzdem blockiert bleiben dürfte für alle TMS, die entsprechende
Vorgaben machen.

 
 Die Verantwortlichen bei OSM sollten sich das aussperren anhand eines
 simplel zu manipulierenden Strings noch mal gut überlegen, wenn sie
 weiterhin ernst genommen werden wollen.
Niemand sagt, dass das System so bombensicher ist. Natürlich kann auch
das umgangen werden, aber hier gibt es gibt nunmal zwei konfliktierende
Probleme dabei:
Variante 1) gar nicht blockieren: halten die Server nicht aus.
Variante 2) Anwendungen blockieren, die Missbrauch betreiben - das wird
gemacht. Notwendig ist dafür die Identifikation der Anwendung, mehr wird
nicht gefordert; das ist dem QLandkarte-Entwickler offensichtlich zu viel.
Variante 3) User identifizieren mit allem drum und dran - das ist zum
Glück nicht die angewandte Variante, denn die hätte tatsächlich in
Sachen Datenschutz etc. enorme Probleme.

Meine Version von QLandkarteGT hat OSM noch mit drin, aber wenn OSM in
Zukunft rausfliegt, dann müsste eigentlich auch die OpenCycleMap, die
einzige andere vorkonfigurierte Karte, demnächst rausfliegen - denn die
Usage Policy von Andy Allan [1] ist in der Hinsicht identisch: Your
application must provide honest http referer and/or user-agent headers

[1] http://www.thunderforest.com/terms/

Im Ergebnis dürfte rein rechtlich QLandkarte damit weitgehend ohne
Karten dastehen, nur setzt Andy die Regeln für die OCM offensichtlich
nicht so streng durch, und wie das mit anderen Karten ist, weiß ich nicht.

Den Admins einen Vorwurf zu machen halte ich an der Stelle aber für
falsch - zumindest, wenn kein gangbarer Alternativweg aufgezeigt wird,
und den sehe ich bei euch nicht.

 Ich hoffe, jemand forkt QLandkarteGT, und baut die OSM-Unterstützung
 wieder ein. Am besten mit durch den User änderbarem User-Agent-String,
 um zukünftigen bekloppt-heiten der OSM-Admins entgegenzuwirken.
Wie gesagt: Eine Lösung für die OSM-Infrastruktur wäre besser, als
Admins als bekloppt darzustellen - die machen das genauso freiwillig wie
du freiwillig mappst (vermute ich), und machen dabei einen ziemlich
guten Job. Bekloppt wäre, wenn sie einfach alles blockieren, weil
irgendwer Mist baut. Bekloppt wäre aber erst recht, wenn sie gar nichts
blockierten und auf der Webseite keine Kacheln mehr ankämen, weil die
Server überlastet sind.

Nicht bekloppt ist, sinnvolle Regeln aufzustellen und diese auch anzuwenden.
Sinnvollere Regeln zu fordern ist okay, aber nicht, ohne da auch
konkrete Vorschläge zu machen. Mir fallen keine ein - dir ja
offensichtlich schon; ich bin gespannt.

Gruß
Peter

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

Re: [Talk-de] Mapnik Administration blockt QLandkarteGT

2014-02-15 Diskussionsfäden Peter Wendorff

Hi,
klar - aber die online-Karten-Funktion ist damit faktisch tot.

Gruß
Peter

Am 15.02.2014 16:58, schrieb Michael Reichert:
 Hallo,
 
 Am 15.02.2014 16:53, schrieb Peter Wendorff:
 Was hat QLandkarte noch für Layer? Nur die OpenCycleMap - na 
 hübsch... da ist ja die Aussage von der Webseite nur minimal 
 übertrieben  to display your GPS data on a variety of maps.
 
 In QLandkarteGT kann man auch Karten im Garmin-Format (ohne
 Kopierschutz) anzeigen, z.B. die Freizeitkarte.
 
 Viele Grüße
 
 Michael
 
 ___
 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] OSM --- Wikipedia

2014-02-08 Diskussionsfäden Peter Wendorff

Hallo Steffen,
für eigentlich alle Karten gilt, dass die sich nicht direkt live an der
Haupt-Datenbank von OSM bedienen, schon bei den Daten nicht.
Bis deine Änderungen also in einer Karte X auftauchen, muss folgendes
Passieren:
- Du musst hochgeladen haben (okay, davon gehen wir mal aus)
- Der OSM-Server muss die Änderung veröffentlicht haben, das passiert
etwa einmal pro Minute sowie einmal am Tag
- Wenn der Server, der die Karte X rendert, aktuell ist, versucht er,
jede Minute die Änderungsdatensätze einzulesen, einige wenige machen das
eben aber auch mit den täglichen. Wenn deine Änderung also in den
Updates ist, und die sind hier gelesen worden, dann liegt das in der
Datenbank für die Wikipedia-Karte
- Die Wikipedia-Karte wird jetzt wieder von einer Render-Software
erstellt. Die wiederum erkennt, wo sich in der Datenbank was geändert
hat und rendert nacheinander die Betroffenen Kacheln neu. Wenn sich also
grade viel ändert, kann auch das wieder etwas dauern.

Letztendlich ist das bei den Karten auf osm.org immer das gleiche, aber
da das eben alles unterschiedliche Server und Systeme sind, die Last
unterschiedlich und so weiter, kann sich das durchaus deutlich
unterscheiden.

Gruß
Peter

Am 08.02.2014 14:26, schrieb Caronna:
 weis das jemand?
 Ich habe in OSM ne Änderung vorgenommen, OSM hat die auch nach n paar
 Augenblicken angezeigt.
 Wikipedia zeigt ja auf Wunsch auch die OSM Karte an, nur Änderungen
 dauern wohl mehr als etwas länger, gibt es da ein Grund für? greift
 WIkipedia nicht direkt aus OSM zu und lagert die Karten zwischen?
 
 Grüße aus der Eifel
 Steffen
 
 
 ___
 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] Mapnik Administration blockt QLandkarteGT

2014-02-07 Diskussionsfäden Peter Wendorff

Hallo Alex,

Ja, das ist bei osm.org letztlich genauso.

Kacheln in detaillierteren Zoomstufen werden auf Abruf gerendert. Also:
Wenn Du da hinsurfst, wird die Kachel in die Render-Queue reingeschoben,
die Software erzeugt ein Bild und das wird ausgeliefert.
Ja, da wird auch was gespeichert und bei erneutem Abruf direkt wieder
ausgeliefert, aber vieles kommt eben durchaus direkt (Abwägung zwischen
Speicherplatz und Rechenlast).

Wenn Du im Browser surfst, hast Du einen begrenzten Bildschirm.
Selbst bei einer HD-Auflösung von 1920x1080 und einer Karte im Vollbild
sind das gerademal rund 8*4=32 Kacheln, die du gleichzeitig sehen kannst.
Mit wildem verschieben des Kartenausschnitts wirds etwas mehr, aber das
hält sich im Rahmen.

Wenn Du jetzt aber Deutschland siehst und die Software läd z.B. bis z17
alle Kacheln, die dahinterliegen mit runter, sind das exponentiell
mehr Kacheln (mit jedem zoomlevel vervierfacht sich ja die Anzahl, und
das überlastet natürlich auf Dauer die Server.

Software, die das tut, wird deshalb blockiert, wenn sie dadurch den
Serverbetrieb stört oder zu stören droht; und auf Serverseite sind dabei
auch gute von schlechten Nutzern einer Software nicht zu
unterscheiden - es wäre also technisch nicht möglich, die App X nur für
Funktion Y zu blockieren, Funktion Z aber zuzulassen.

Die Daten sind frei, und wer eine solche Funktionalität anbieten will,
soll entweder einen Renderer in die Software einbauen oder sich irgendwo
einkaufen, was Serverlast für Download und Rendering angeht.

Du meinst nun, die vorgerenderten Kacheln wären besser als das, was du
lokal auf dem Smartphone erzeugst, und lädst die Kacheln auch noch
selbst runter: Nichts spräche dagegen, wenn du dir stattdessen die Daten
runterladen und die Kacheln lokal am Desktop rendern würdest, um sie
dann aufs Smartphone zu ziehen, und es spricht auch nichts dagegen, wenn
z.B. QLandkarte genau das unterstützen würde.

Gruß
Peter

Am 07.02.2014 16:15, schrieb Alexander Lehner:
 
 
 On Fri, 7 Feb 2014, Sven Geggus wrote:
 
 hike39 ho...@hike.de wrote:

 Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass
 OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert
 werden?

 Das Problem ist nicht die Onlinenutzung, das Problem ist der Massenhafte
 Kacheldownload, dennd er zerstört das Konzept des on demand rendering.

 Ich verwende für meine Tourenplanung (Fahrrad und Wandern) das Programm
 Viking. Das lädt wie ein Browser Kacheln nur on Demand runter. Sowas darf
 IMO nicht geblockt werden.

 Als Admin von tile.openstreetmap.de ist mir aber insbesondere locus
 auch
 schon negativ aufgefallen. da werden tiles nicht nur on demand geladen
 sondern massenhaft untergeladen.
 
 tangoGPS bzw. foxtrotGPS machen das ebenfalls so (Region auswaehlen,
 angeben bis zu welcher Zoomstufe man tiles runterladen will).
 
 Ich nutze diese Programme sehr gern auf meinem 'Smartphone', weil die
 fertig gerenderten Karten einfach schoener sind als die lokal gerenderten.
 Zu Hause die Kacheln runterladen und beim Mountainbiken im Wald, wo's
 kein UMTS gibt, hat man die Karten parat. Ist schon nett.
 
 @Sven: Worin besteht das Problem des On-Demand Rendering bei
 Massendownloads? Da kenne ich den Mechanismus dahinter zu wenig.
 Ist das bei openstreetmap.org genauso?
 
 Die Datenmenge kann es wahrscheinlich nicht sein, das sind 100-400MB,
 die laedt man sich einmal im Vierteljahr runter und gut ists.
 
 A.
 
 
 ___
 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] St.-ZickeZacke-Str.

2014-02-06 Diskussionsfäden Peter Wendorff

Ich weiß nicht, ob du das mitgekriegt hast, aber Dr. steht auch im
Englischen nicht nur für Drive. Zugegeben - da heißt es dann Doctor,
nicht Doktor...

Ob die Kirche Sankt Maria in Deutschland zu Santa Maria oder Saint Maria
werden sollte, selbst in einer anderen Sprache, halte ich im übrigen für
Diskussionswürdig, oder würdest Du anstatt Saint Paul’s Cathedral in
London Sankt Paul's Cathedral in deiner deutschen Sprachausgabe hören
wollen? Entweder doch vermutlich Sankt Pauls-Kathedrale, oder aber den
Eigennamen Saint Paul’s Cathedral - aber nicht so 'nen komischen Mix
weil die TTS natürlich nur teilweise übersetzen kann (und wird).
Klar: Lässt sich durch Angabe unterschiedlicher name:[lang]-Werte lösen
- aber wenn die nicht da sind, hilfts eben nicht.

Richtig ist: Wenn du der TTS-Engine per Software mitteilen kannst, in
welcher Sprache der Name geschrieben ist, dann kann sie darauf eingehen,
für Webseiten auf Deutsch kann man dazu den englischen Eigennamen der
Kirche in ein entsprechendes html-Tag mit lang=en kapseln. Für den
Name-Tag ist das schon schwieriger, weil die Sprache nicht bekannt ist.
Das geht also nur, wenn die Sprache durch die Namensgleichheit mit einem
lokalisierten name-Tag identifiziert werden kann; und da dann auch die
Abkürzungen unterschiedlich sind, wär ich mir bei z.B. einer
südamerikanischen Kirche nicht sicher, ob der Name jetzt im Original
Spanisch, Portugisisch oder Deutsch ist, lässt sich anhand des St aber
nicht unbedingt ablesen - die Frage, in welcher Sprache der Text sich
insgesamt bewegt, ist eben gerade bei Eigennamen KEIN Hinweis darauf,
was korrekt wäre im Kontext des Namens.

Gruß
Peter

Am 06.02.2014 18:46, schrieb Fabian Schmidt:
 
 Am 05.02.14 schrieb Peter Wendorff:
 
 Eine TTS-Software, sie in dem Sinne gut ist wie du dir das vorstellst,
 gibt es vermutlich nicht, was nicht an der Faulheit der Entwickler
 liegen dürfte.
 
 Für TTS muss ich wissen, in welcher Sprache ich mich bewege. Dann kann
 ich je nach Sprache auch wahlweise Dr.-Doktor oder Dr-drive expandieren.
 
 Siehe dafür http://mary.dfki.de:59125/
 - Sprache bits3-hsmm de male hmm
   Willkommen in Dr.-Wendorff-Stadt!
   (aus St. wird scht)
 - Sprache cmu-bdl-hsmm en_US male hmm
   Welcome to Mulholland dr!
   (aus St. wird saint)
 
 
 Gruß, Fabian.
 
 
 ___
 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] St.-ZickeZacke-Str.

2014-02-06 Diskussionsfäden Peter Wendorff

Und wie viel Auswertung verlangst du für jede Software?
Wir sind uns doch einig, dass es nicht schwieriger für Mapper ist, die
ausgeschriebene Fassung in den name-Tag zu schreiben.
Für Software ist es einfach, eine vorhandene Langform bei Bedarf abzukürzen.
Damit eine Software - egal welche - die Kurzform korrekt verlängern
kann, muss sie
1) die Sprache kennen, das ist nur selten direkt der Fall,
alternativ
1a) aus der Lage die Sprache erraten - das geht, erfordert aber eine
entsprechende Heuristik sowie eine geometrische Abfrage, wo der Name auf
der Welt vorkommt,
2) Kommt ein Name mit einer entsprechenden Abkürzung in einem Gebiet
vor, in dem eigentlich eine andere Sprache vorherrscht, so muss der
Mapper dies wissen und entgegen deiner Regel die Langform eintragen,
weil jede Heuristik oder Sprachsuche sonst fehlschlagen muss.

Mit (2) wird deine Regel also zu:
Die Langform in name schadet nicht, aber für bestimmte Abkürzungen (im
Deutschen mindestens Dr. für Doktor, St. für Sankt und Str. für Straße,
wobei bei einem str am ende des Wortes auf keinen Fall der Punkt
vergessen werden darf), ist es in Ordnung die Abkürzung als Abkürzung zu
belassen, weil wir von Softwareentwicklern entsprechende
Auswertungsintelligenz erwarten.

Alleine für deine erste Näherung (und dass das auch nur eine Näherung
ist, betonst du ja), braucht jede Software also entweder eine Verbindung
zum Netz oder eine Datenbank, die eine Zuordnung zwischen Land und
Sprache(n) zu bilden.
Das erfordert aber schon, dass ich zu dem Namen das Land kenne, sonst
brauch ich auch noch eine Zuordnung von Koordinatenbereichen zum Land
(oder direkt zur Sprache), denn im Zweifelsfall gibt es in den OSM-Daten
keine Informationen zum Land, weil diese z.B. nur eine Stadt abdecken,
und auch addr:country nicht belegt ist.

Noch mal: Ich weiß, dass das möglich ist; erst Recht mit Referenz auf
fremde Quellen; aber wofür OSM nutzen, wenn wir hinterher wikipedia,
ethnologue.com und alles mögliche andere brauchen, um die Daten nutzen
zu können.

Ich hab nichts dagegen, Daten einzusparen, wo sie wirklich sinnlos sind
- z.B. in der aktuellen und wiederkehrenden Diskussion um
Mengen-Relationen; aber hier ist es sehr wenig bis gar kein Aufwand, der
viel bis sehr viel Aufwand auf anderer Seite spart und außerdem in OSM
alleine eine eindeutige Situation schafft, die keinen
Interpretationsspielraum braucht, erst recht keine Drittquellen.

Gruß
Peter

Am 06.02.2014 23:20, schrieb Fabian Schmidt:
 
 Am 06.02.14 schrieb Peter Wendorff:
 
 Ich weiß nicht, ob du das mitgekriegt hast, aber Dr. steht auch im
 Englischen nicht nur für Drive. Zugegeben - da heißt es dann Doctor,
 nicht Doktor...
 
 Probier es aus: das DFKI interpretiert Welcome to Dr. Mulholland! als
 Doctor.
 
 Klar: Lässt sich durch Angabe unterschiedlicher name:[lang]-Werte lösen
 - aber wenn die nicht da sind, hilfts eben nicht.
 
 Entweder interpretiere ich die Sprache richtig, dann weiß ich, was die
 Abkürzung heißt. Oder ich spreche den Namen falsch aus und hab damit ein
 größeres Problem als mit dem Unterschied Saint - Sankt.
 
 Für den
 Name-Tag ist das schon schwieriger, weil die Sprache nicht bekannt ist.
 Das geht also nur, wenn die Sprache durch die Namensgleichheit mit einem
 lokalisierten name-Tag identifiziert werden kann;
 
 Einfacher ist, anderswo anhand der Sprachgrenzen rauszufinden, was denn
 dort gesprochen werden kann, in erster *Näherung* schau ich bei
 ethnologue.com o.ä., welche Hauptsprache es in dem Land gibt.
 
 wär ich mir bei z.B. einer südamerikanischen Kirche nicht sicher, ob
 der Name jetzt im Original Spanisch, Portugisisch oder Deutsch ist,
 lässt sich anhand des St aber nicht unbedingt ablesen
 
 San und São haben kein t, die Sprachgrenze in Südamerika ist sehr klar,
 und warum sollte der Name deutsch sein?
 
 
 Gruß, Fabian.
 
 
 ___
 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] St.-ZickeZacke-Str.

2014-02-05 Diskussionsfäden Peter Wendorff

Geht es nur um zwei Fälle?

Es gibt in diesem Thread im Grunde zweieinhalb Meinungen, würde ich sagen:
1) on-the-ground: ich trage ein, was auf dem Schild steht
2) on-the-ground übersetzt: ich trage ein, was auf dem Schild steht,
aber in der ausgeschriebenen Fassung
2,5) on-the-ground manchmal übersetzt: ich trage ein, was auf dem Schild
steht, aber in der ausgeschriebenen Fassung - außer bei str. am Ende
oder Dr. und St. am Anfang.

Variante (1) und (2,5) haben beide das Problem, dass eine Kurzform eben
nicht ohne zusätzliches Wissen (und auch nicht mit generellen Regeln) in
die Langform übersetzt werden kann.
Ich beschränke mich bei den Beispielen mal auf die für (2,5)
problematischen, damit ist (1) auch widerlegt.

Ich weiß, dass ich hier Beispiele konstruiere, aber du behauptest ja,
die Verlängerung wäre eindeutig.

Die Draco-Malfoy-Straße, abgekürzt Dr.-Malfoy-Str.
Der Drees-Müller-Platz, abgekürzt Dr.-Müller-Pl.
Die Stefan-Effenberg-Gasse, abgekürzt. St.-Effenberg-Gasse
Der Stefan-Radoslav-Platz, abgekürzt St.-Radoslav-Platz
...

beliebig erweiterbar.

Echte Beispiele:

Stefan-Zweig-Straße, u.a. in Leipzig:
http://open.mapquestapi.com/nominatim/v1/search.php?polygon=1q=Stefan-Zweig-Stra%C3%9Fe,+Leipzig

Ich weiß - die Abkürzungen wären doof, aber über Sinn oder Unsinn von
Schildern wollten wir uns ja nicht streiten, und denen trau ich vieles zu.
Ich weiß auch, dasss Stefan oft mit S abgekürzt wird und nicht mit St,
aber Fehler auf Schildern sind auch keine besonders seltene Ausnahme.

Gruß
Peter

Am 05.02.2014 13:42, schrieb Martin Raifer:
Ich möchte noch einmal die eigentlich schon in meinem Anfangsposting in
den Raum gestellte These/Frage wiederholen:

Wieso schreiben wir in OSM Straßennamen nicht wie ihn praktisch Jeder in
Texten schreiben würde? So, wie er in Tageszeitungen vorkommt, so wie er
in Enzyklopädien vorkommt, so wie er in Broschüren vorkommt, so wie er
auf offiziellem Briefpapier vorkommt, so wie er am Straßenschild stehen
würde wenn dort nicht aus Platzgründen abgekürzt werden müsste, …?

Es ist meiner Meinung nach nicht sinnvoll Mappern irgendwelche von der
Realität abweichende Regeln aufzudrücken, die weder intuitiv sind noch
aus anderen Gründen gerechtfertigt. Vor allem nicht für so etwas
alltägliches wie den Namen eines Dinges hinzuschreiben. KISS [2]

Es geht doch praktisch fast nur um zwei Fälle: St. und Dr.. Beides
sind in gewisser Weise Titel von Personen, die im echten Leben fast
immer abgekürzt werden. Verwechslungen können unter Berücksichtigung des
Kontextes (Name eines Ortes oder Straße) ausgeschlossen werden. (z.B.:
St. steht laut Duden [1] für Sankt, Stück oder Stunde. Letztere beiden
können bei Straßen oder Orten nicht vorkommen.)

Liebe Grüße
Martin

[1] http://www.duden.de/rechtschreibung/St_
[2] https://de.wikipedia.org/wiki/KISS-Prinzip

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

Re: [Talk-de] St.-ZickeZacke-Str.

2014-02-05 Diskussionsfäden Peter Wendorff

Am 05.02.2014 18:01, schrieb Martin Raifer:
 Text-to-Speech
 
 Gute Text-to-Speech Software sollte aber mit diesen Abkürzungen locker
 umgehen können. Und wenn nicht, dann bedarf es für die jeweilige
 Anwendung schlicht eines Post-Processing Schritts, der die Abkürzungen
 entsprechend expandiert.
Gute Text-to-Speech-Programme können auch nicht ohne weiteres St. zu
wahlweise Santa, Santo, Sankt oder Saint expandieren, und auch dann
müsste die Text-To-Speech-Engine herausfinden, dass es sich um eine
Örtlichkeit handelt, sonst ist auch noch Stück unter den Möglichkeiten.

Über den deutschen Sprachraum hinaus kommen noch Street, Strada und
vermutlich etliche mehr dazu; dann entsprechend auch Drive für den
Doktor und vieles mehr.

Eine TTS-Software, sie in dem Sinne gut ist wie du dir das vorstellst,
gibt es vermutlich nicht, was nicht an der Faulheit der Entwickler
liegen dürfte.

Gruß
Peter

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

Re: [Talk-de] St.-ZickeZacke-Str.

2014-02-04 Diskussionsfäden Peter Wendorff

Hi,
ich glaube, niemand will verbieten, die Kurzform in name zu erfassen,
die Frage ist aber doch, was ist das Ziel?

Eine St.-Hedwig-Kirche ist besser als eine namenlose Kirche, aber eine
Sankt-Hedwig-Kirche wäre eben noch besser - Gründe sind bereits
mehrfach genannt in diesem Thread.

Wenn jetzt jemand die St.-Hedwig-Kirche einträgt, kann das jemand
anderes verbessern, wenn er mehr weiß.
Wenn aber jemand die St.-Hedwig-Kirche einträgt, obwohl er den langen
Namen weiß, dann ist das schade.
Deshalb ist es eben sinnvoll, das auch als Regel aufzustellen: Nach
Möglichkeit bitte die ausgeschriebene Fassung des Namens in name eintragen.

Ich trage auch einen möglicherweise falschgeschriebenen Namen ein, wenn
mir jemand aus dem Kopf sagt, wo ein bestimmtes Geschäft ist, aber den
Namen nur im Wortklang kennt; wenn ich einen Verdacht habe, eben mit
fixme (sonst aber auch ohne). Genauso würde ich ein St.-Sowieso
eintragen, wenn ich die Langfassung eben nicht aus eigenem Wissen daraus
erzeugen kann.

Gruß
Peter

Am 04.02.2014 00:24, schrieb Falk Zscheile:
 Am 3. Februar 2014 21:19 schrieb Florian Schäfer florian-schae...@gmx.net:
 Am 03.02.2014 17:38, schrieb Martin Koppenhoefer:

 Allein schon daher bin
 ich für die ausgeschriebene Schreibweise im tag name (wg.
 internationaler
 Konsistenz/gleichem Vorgehen, s.o.), es gibt aber noch mehr Beispiele.

 +1

 Ein weiteres Beispiel wäre da die St.-Exupéry-Straße, der ich neulich auch
 begegnet bin.
 Da ist es durch die Bekanntheit des Namensgebers noch relativ einfach, aber
 wie wäre es mit der St.-Denis-Straße, St.-Martin-Straße oder
 St.-Paul-Straße? Die gibt es teilweise entweder als Sankt-Straße oder als
 Saint-Straße (insbesondere im französischen Grenzbereich).

 Ich finde auch, dass der eindeutige (= ausgeschriebene) Name ins name-Tag
 gehört, alles andere in short_name u.Ä.

 
 Hier ist doch gerade das Problem: Ein Mapper, der vor dem
 Straßenschild steht und St.-Denis-Straße liest kann nicht sagen, ob
 St. ein Saint oder ein Sankt ist. Deswegen kann er nur
 St.-Denis-Straße eintragen. Ein anderer, der sich daran stört kann
 das dann klarstellen, indem er long_name richtig ausfüllt.
 
 Dieses vorgehen hat drei Vorteile:
 1. Der Erfasser vor Ort (on the ground) muss sich keine weiteren
 Gedanken um die Bedeutung der Abkürzung (hier St.) machen, er kann
 dies anderen überlassen. Es ist für ihn also einfach, Daten auch in
 Regionen zu erfassen, die er nicht so gut kennt.
 2. Die Differenzierung zwischen verschiedenen Namensvarianten in der
 Erfassung im Datenschema erleichtert die Arbeitsteilung: Einer kann
 sich um die Erfassung vor Ort kümmern, ein anderer Straßenlisten
 auswerten. Dass sich beide nicht in die Quere kommen Da stand aber
 St. Schon, aber St. heißt immer Sankt und soll ausgeschrieben
 werden., dafür sorgt die Erfassung in unterschiedlichen Tags: name,
 long_name und ggf. auch short_name.
 3. Der Datenauswerter hat die Wahl, welche der beiden Infos er für
 sich und seine Anwendung am Besten geeignet hält.
 
 Falk
 
 ___
 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] St.-ZickeZacke-Str.

2014-02-04 Diskussionsfäden Peter Wendorff

Gerade am Beispiel von Kirchen gibt es aber häufig beide Schreibweisen
on the ground:
St. Hedwig am Straßenschild, Sankt Hedwig im Schaukasten.

Dazu noch die Abkürzungen katholische Kirche (bzw. kath. Kirche) auf
Straßenschildern, wenn es nur eine gibt im Ort.

Bei Straßen wirds seltener, aber auch da kommen unterschiedliche
Schreibweisen vor (die Annette-von-Droste-Hülshoff-Straße in Warburg ist
oder war zumindest mal mit zwei Schildern ausgeschrieben - einmal
abgekürzt: A. v. Droste-Hülshoff-Str., einmal ausgeschrieben wie oben.
Wenn es einen Grund gab, dann vermutlich den, dass das lange Schild an
'ner Hauswand hing, das kurze aber auf 'nem Pfeiler, der bei der
Langform vermutlich umgekippt wäre.

Abgesehen davon, dass man keine Chance hat, aus A. v. Droste-Hülshoff
Annette von abzulesen (wenn man nicht im Deutschen und der deutschen
Lyrik vorgebildet ist), ist hier schon die on-the-ground-Regel zum
Scheitern verurteilt - oder willst Du jetzt diejenigen verteidigen, die
die Straße splitten und die beiden Hälften unterschiedlich benennen,
weil die ja unterschiedlich ausgeschildert sind?

Gruß
Peter

Am 04.02.2014 09:48, schrieb Falk Zscheile:
 Am 4. Februar 2014 09:05 schrieb Peter Wendorff wendo...@uni-paderborn.de:
 Hi,
 ich glaube, niemand will verbieten, die Kurzform in name zu erfassen,
 die Frage ist aber doch, was ist das Ziel?

 So ist es.
 
 Eine St.-Hedwig-Kirche ist besser als eine namenlose Kirche, aber eine
 Sankt-Hedwig-Kirche wäre eben noch besser - Gründe sind bereits
 mehrfach genannt in diesem Thread.

 Wenn jetzt jemand die St.-Hedwig-Kirche einträgt, kann das jemand
 anderes verbessern, wenn er mehr weiß.
 Wenn aber jemand die St.-Hedwig-Kirche einträgt, obwohl er den langen
 Namen weiß, dann ist das schade.
 
 Schade wäre es, wenn sich beide darüber in die Haar bekommen, weil der
 eine sagt St.-Hedwig-Kirche steht aber im Schaukasten. Andere der
 andere sagt: Schon richtig, aber ausgeschrieben ist es einfach
 besser. Da ist es doch besser wenn ich name=St.-Hedwig-Kirche lese zu
 ergänzen long_name=Stankt-Hedwig-Kirche. Und wenn ich
 name=Stankt-Hedwig-Kirche lese zu ergänzen
 short_name=St.-Hedwig-Kirche. In beiden fällen sollte ich mir denken
 Oh, das scheint vor Ort so zu stehen -- aber die Langform bzw. die
 Kurzform ist (mir) wichtig -- ich trage die mal noch ein. Schön, dass
 es dafür ein Tag gibt, dann ist für andere (einigermaßen) eindeutig,
 was mir wichtig ist.
 
 Das Probelem was wir bei OSM haben ist das Folgende: Unsere Tags
 entwickeln sich und oft werden erst im Nachhinein Bedürfnisse
 sichtbar, an die man am Anfang nicht gedacht hat. Das ist bei OSM
 normal und gehört zum Prinzip. Eine andere (nicht ganz so schöne)
 Eigenschaft von OSM ist es den status quo möglichst aufrecht zu
 erhalten[1], wie es geht: Ins name-Tag kommt nur was vor Ort steht.
 Ins name-Tag kommt der ausgeschriebene name. Die meisten wehren sich
 dagegen das Datenschema weiter auszudifferenzieren und für bessere
 Eindeutigkeit zu sorgen, also Tags zu schaffen, die klarer machen, was
 gemeint ist: short_name, long_name, official_name etc. Mit anderen
 Worten wir treten auf der Stelle, weil name=value je nach User
 wahlweise die Bedeutung short_name, long_name, official_name oder name
 (im Sinne von on the ground) haben kann. Das macht auch die Auswertung
 für Anwendungen schwierig, wenn man etwas anderes oder mehr will als
 einen irgendwie schon richtigen Namen.
 
 Ich bin dafür name im Sinne von on the ground zu verstehen, weil dies
 die (fast) einzige Regel ist, die wir haben, die jeder kennt, die
 zudem auch schon sehr alt ist, wiedergibt, wie wir vorgehen, wenn es
 keine Listen und ähnliches gibt und schließlich wäre das Tag
 on_th_ground_name=value etwas sperrig :-)
 
 Gruß
 Falk
 
 [1] Das soll kein persönlicher Angriff gegen Personen sein, die hier
 entsprechende Argumente vortragen, sondern ist als allgemeine soziale
 Tatsache gemeint. Vgl. dazu meinen Vortrag im letzten Jahr auf der
 FOSSGIS 2013.
 
 ___
 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] St.-ZickeZacke-Str.

2014-02-03 Diskussionsfäden Peter Wendorff

Hi,
die lange Form.
Die abgekürzte Variante in OSM zu haben hat seine Berechtigung, weil
bzw. wenn sie das ist, was man vor Ort auf dem Straßenschild sieht.
An der Adresse sieht man aber meist gar nichts, die Zuordnung kann zudem
über die naheliegende Straße erfolgen durch auswertende Software.

Gruß
Peter

Am 03.02.2014 10:59, schrieb malenki:
 On  02.02.2014 20:35, Peter Wendorff wrote:
 
 häufiger Streitfall. Ich persönlich plädiere für
 name=Sankt-ZickeZacke-Straße und short_name=St.-ZickeZacke-Straße.
 
 Was davon verwendest du für addr:street= ?
 
 
 
 ___
 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] St.-ZickeZacke-Str.

2014-02-03 Diskussionsfäden Peter Wendorff

Am 03.02.2014 18:34, schrieb Tobias Knerr:
 Es gibt aber auch (mit vertretbarem Aufwand) unauflösbare Abkürzungen im
 normalen Sprachgebrauch.

Es sagt ja niemand etwas dagegen, dass es vereinzelt die Kurzformen
gibt. Das lässt sich sowieso nicht vermeiden, und ist besser als kein
Name. Wenn jemand die korrekte Langfassung also nicht kennt, soll er die
kurze eintragen. Nach Möglichkeit die Langfassung zu nutzen ist in dem
Kontext dann eine sehr einfache Regel.

Gruß
Peter

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

Re: [Talk-de] Stolperstein-Relationen entsorgen?

Am 02.02.2014 09:25, schrieb Steffen:
 --- Original Nachricht ---
 Absender: Peter Wendorff
 Datum: 31.01.2014 09:14
 Wenn Sammelrelationen nicht gewünscht sind, dann sollte es technisch
 verhindert werden solche anzulegen.
 Da bin ich aber auf einen Lösungsansatz gespannt.
 Beispiel Buslinien:
 - keine Sammelrelation, weil die Reihenfolge der Objekte relevant ist
 - kein Objekt in der Relation braucht eine spezielle Rolle.
 
 Ein Lösungsansatz wäre es doch schon die Mitglieder einer Relation in
 Abhängigkeit des Typs zu beschränken. Und warum sollte nicht auch eine
 Rolle obligatorisch sein. Wenn man dies im JOSM schon hinterlegt, wäre
 dies doch mal ein Anfang.
Also Pflicht-Rolle?
Kein Problem:
relation: type=menge (falls set schon explizit blockiert ist)
gaaanz viele Elemente drin, und immer
role=member

cool - ätsch ;)

abgesehen davon, dass - wie bereits beschrieben, eine Relation ohne
Rollen auch durch eine Bedeutung der Reihenfolge als solche einen
Mehrwert bilden kann - wie eben bei den Buslinien.

 Ich bin kein Datenbankprogrammierer, aber es gibt bestimmt andere die da
 noch andere Lösungen haben.
Es geht nicht um Datenbankprogrammierung, sondern um schlichte Logik.
Ein Konzept, das unsortierte Mengen verbietet, sortierte Mengen aber
erlaubt, erfordert eine Möglichkeit, das voneinander zu unterscheiden.

Da alle sortierten Mengen auch unsortierte Mengen sind (bzw. als solche
betrachtet werden können), muss man den echten Unterschied erkennen
können. Mach dir keinen Kopf drum, wie man das in der Programmierung
umsetzen könnte, sondern stell dir vor, du hast keine Sprachkenntnisse,
siehst also nur Tags, die für dich keine Bedeutung haben (!), und sollst
entscheiden, ob es sich um eine sortierte oder unsortierte Menge handelt.

Gruß
Peter

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

Re: [Talk-de] Was ist Openstreetmap wert?

Nun ja...
da die meisten von uns ja nun keine Angestellten im GIS-Bereich sind,
geschweige denn eine entsprechende Ausbildung genossen haben, hinkt der
Vergleich auch dann etwas - wobei sicherlich die meisten aufgrund von
Erfahrung und Motivation nicht als ahnungslose Deppen in die Berechnung
eingehen sollten ;)

Gruß
Peter

Am 01.02.2014 16:09, schrieb Dirk Sohler:
 Roland Olbricht schrieb:
 OpenStreetMap ist keine handelbare Sache.
 
 Mal angenommen, es wäre eine.
 
 Gibt es eine Statistik darüber, wieviele Mannstunden bis zum aktuellen
 Datenbankstand für OSM aufgewendet wurden? Das müsste man nur mit den
 Kosten pro Stunde für einen Angestellten im GIS-Bereich verrechnen, und
 hätte dann zumindest – wenn auch recht grob – den reinen „Materialwert“
 des Planet-Files :)
 
 Grüße,
 Dirk
 
 
 
 ___
 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] Exportfunktion auf der OpenStreetMap.org Seite

Hi,
Sinnvoll ist das nicht, aber es hat schon einen Grund, warum das nicht geht.
Dass die GUI dazu keinen Hinweis gibt und einfach immer Mapnik ausgibt,
ist doof und IMHO ein Fehler, dass die anderen Karten keine
Exportfunktion anbieten, ist schade, aber abgesehen davon in Ordnung.

Gruß
Peter

Am 02.02.2014 18:31, schrieb Thorsten Alge:
 Hi,
 
 auf der Seite von OpenStreetMap gibt es eine Exportfunktion mit der man
 den aktuellen Kartenausschnitt als Bild exportieren kann. Allerdings ist
 der Export im im Standard-Mapnik Design statt in dem aktuell
 ausgewählten – macht irgendwie nicht viel Sinn, oder?
 
 Gruß
 
 Th.
 
 ___
 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] St.-ZickeZacke-Str.