Re: [Talk-de] Radverkehrsinfrastruktur / Lübecker Modell

[Wolfgang Hinsch]

Am Freitag, 25. Januar 2019, 19:30:54 CET schrieb Hubert87:
> Hallo Georg,
> 
> Am 25.01.2019 um 17:58 schrieb Georg Feddern:
> > Moin,
> > 
> > nun ja - jeder benutzungspflichtige Radweg muss ja "designated"(*)
> > sein - sonst wär er ja nicht benutzungspflichtig.
> 
> Richtig.
> 
> > Andererseits sind ja nicht alle "designated" auch tatsächlich
> > benutzungspflichtig - siehe Querfeldein-Wege.
> > (Hier war die frühere StVO eigentlich besser formuliert m.M.n.)
> 
> Richtig
> 
> > Die Benutzungspflicht ergibt sich ja erst aus der Nähe/Begleitung
> > einer Straße - und kann im Wesentlichen durch "use_sidepath=yes" an
> > der Straße abgebildet.
> > Hierdurch soll ja genau das Wesentliche - nämlich die Vermeidung der
> > Straßenbenutzung beim Routing - erreicht werden.
> 
> Richtig. Der Radweg muss dann aber als eigene Linie eingezeichnet sein.

Wobei sich daraus dann in manchen Innenstadtlagen das Problem ergibt, zu 
welchem Straßenabschnitt jetzt welcher Radwegeabschnitt gehört.

Gerade in engen Innenstadtlagen würde ich daher eher von einem separat 
gemappten Radweg absehen und ihn durch tags darstellen, solange er dem Verlauf  
der Fahrbahn folgt. 

Der Unterschied ist beim Routing maßstabsbedingt praktisch bedeutungslos, 
außerdem entfällt das Problem der Abbildung von Abbiegemöglichkeiten auf der 
linken Seite.

Gruß, Wolfgang


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

Re: [Talk-de] Konfigurationsfehler Apache www.openstreetmap.de (WAS: Deutsche Homepage - Fehlermeldung)

[Wolfgang Hinsch]

Hallo,

Am Samstag, 27. August 2016, 11:06:45 schrieb lars lingner:
> Hallo,
> 
> viele Dank für das Feedback. Die SSL-Config wurde habe ich 
eben
> überarbeitet und jetzt wird die Seite mit A bei sslabs [1] 
bewertet.
> 
> Falls noch weitere Einschränkungen auffallen, bitte melden.

der Ausfall der Suchfunktion ist bekannt?

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

Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland

[Wolfgang Hinsch]

Am Sonntag, 13. März 2016, 14:02:58 schrieb Martin Koppenhoefer:

> +1, wenn Kommunen ihre Routen in OSM haben wollen dann ist das 
keine Frage,
> die uns beschäftigten muss, vielmehr sollten sich dann ggf. die 
Kommunen
> mit dieser Frage beschäftigen, besonders schwierig ist sie aber auch 
nicht
> zu beantworten: entweder machen sie es selbst oder sie beauftragen 
jemanden
> damit oder sie warten, dass es Freiwillige evtl. kostenlos machen.

Wenn diese Routen nachvollziehbar von den Kommunen definiert und unter 
kompatibler Lizenz öffentlich dokumentiert werden, +1

Dann kann der Mapper vor Ort die Eintragungen prüfen. Nicht jede 
prüfbare Eintragung beruht auf einem Schild vor Ort oder der direkten 
Zugängikeit durch den Mapper.

(Busrouten, Eisenbahnrouten, PLZ, Grenzen aller Art, TMC, 
Gebäudeumrisse, Bach- und Flussläufe auf Privatgelände, ...)

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

Re: [Talk-de] ÖPNV-Karte / Darstellung historischer Bahnstrecke

[Wolfgang Hinsch]

Am Samstag, 17. Oktober 2015, 13:02:34 schrieb Rolf Eike Beer:
> Am Samstag, 17. Oktober 2015, 11:25:39 schrieb goegeo:
> > Hallo zusammen,
> > 
> > mir ist aufgefallen, dass in der ÖPNV-Karte eine historische Bahnlinie
> > (blau) angezeigt wird. Es handelt sich um die ehemalige Straßenbahn
> > Flensburg, welche nur bis 1973 bestand. Mag jemand bei der 
Entfernung
> > behilflich sein. Bin im Tagging vom ÖPNV noch recht neu unterwegs. 
Denke
> > aber, dass historische Bahnstrecken nicht in der ÖPNV-Karte 
dargestellt
> > werden sollten.
> 
> Moin,
> 
> geh doch mal bitte etwas ins Detail, z.B. Koordinaten oder oder die id 
eines
> Weges, dann können wir uns das mal ansehen.
> 
> Gruß
> 
> Eike


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

Re: [Talk-de] Fußgänger-Diskriminierung?

[Wolfgang Hinsch]

Am Donnerstag, 16. April 2015, 16:21:22 schrieb Frederik Ramm:
 Hi,
 
 On 04/16/2015 02:48 PM, Roland Olbricht wrote:
  Bei solchermaßen aufgeteilten Straßen gibt es nun die Tendenz, den
  üblicherweise auf einem Straßenschild auf dem Fußweg
  http://wiki.openstreetmap.org/wiki/File:IMG_20150416_125451.jpg
  angebrachten Namen nicht nur zusätzlich auch auf der PKW-Fahrbahn
  unterzubringen, sondern auch vom Fußweg wieder zu löschen.
 
 Ich verstehe nicht ganz, worum es geht - wer löscht hier was?
 
 Grundsätzlich sollten in OSM nur Dinge ein name-Tag haben, die auch so
 heissen.
 
 Wenn ich also frage: Welches Objekt ist die Talstraße, dann möchte ich
 als Antwort nicht den abgetrennten Fussweg entlang der Talstraße haben,
 sondern die Straße selbst.

Das kannst du über eine leichte Modifikation der Abfrage problemlos erreichen, 
wir taggen nicht für Renderer, Router - und auch nicht für bestimmte Abfragen.

 
 Der abgetrennte Fussweg entlang der Talstraße ist in meinen Augen nicht
 die Talstraße und sollte auch nicht dieses name-Tag tragen.

Das sehe ich anders. Wenn der Fußweg zur Straße gehört, trägt er, ebenso wie 
die Fahrbahn, auch den Namen der Straße. Gleiches gilt für einen abgetrennt 
gemappten Radweg.

Die Frage ist nur, ob wir den Namen an alle separaten Objekte taggen, oder 
eine Art Hauptobjekt ernennen, dass den Namen der Straße trägt. Ich sehe 
aber nicht, dass dies grundsätzlich eine Fahrbahn sein muss.

Möglich wäre hier, grundsätzlich in der Straßenmitte den Namen zu taggen, also 
üblicherweise an die Fahrbahn, wenn sie in der Mitte liegt, bei 
Fahrbahntrennung auf eine imaginäre Mittellinie oder ggf. an einen Fußweg, der 
in der Mitte zwischen beiden Fahrbahnen verläuft (in manchen Innenstädten). 
Das würde eine Menge Rendererprobleme lösen. Übrig bliebe aber die Frage, wie 
die einzelnen Linien dann zum Gesamtobjekt Straße zusammengebunden werden.

 
 Das Bild, das Du verlinkt hast, ist mir unklar; hier scheinen Rad- und
 Fussweg entlang der Strasse zu verlaufen und daher m.E. nicht einmal
 eine eigene Geometrie zu verdienen, während das Namensschild nach links
 zeigt und daher einen anderen, im Bild nicht sichtbaren Weg zu betreffen
 scheint?
 
  Der einzige, der mir bisher genannt wurde, sind technische
  Unzulänglichkeiten in einigen Renderern (Unerwünschtes
  Mehrfach-Rendering des Namens). Das würde ich aber nicht als einen
  Grund ansehen, von der On-The-Ground-Regel (Schild steht ja meist im
  Fußweg oder an der Hauswand oberhalb des Fußwegs) abzuweichen und nur
  willkürlich ausgewählte Fahrbahnteile ohne physisch vorhandenes
  Schild mit Namen zu versehen.
 
 Wenn ich Dich richtig verstehe, argumentierst Du, dass aufgrund der
 Platzierung des Schildes viele Straßen in deutschen Innenstädten ihr
 name-Tag nur verdient haben, weil die Gehweg-Geometrie nicht
 eigenständig erfasst ist, und sobald die Gehweg-Geometrie eigenständig
 erfasst wäre, das Schild selbstverständlich für den Gehweg gälte (weil
 es diesem physikalisch näher ist) und nicht für die Straße.
 
 Dieser Argumentation kann ich nicht folgen. Die Platzierung von
 Schildern folgt nicht der Regel das Schild gilt für das Objekt, dem es
 physikalisch am nächsten ist.

+/-1 
Üblicherweise stellt man Schilder schon so auf, dass sie dem benannten Objekt 
möglicht nahe stehen, sonst weiß niemand, welches Schild nun für welche Straße 
gelten soll ;-)

Aus der Lage des Schildes auf dem Fußweg folgern zu wollen, es gelte nur für 
den Fußweg, halte ich allerdings auch für abwegig. Es gilt für das ganze 
Objekt Straße, und wenn wir das Objekt in 6 Wege aufteilen, weil die 
Fahrbahnen getrennt sind und Fuß- und Radwege separate ways erhalten, gilt das 
Schild eben für alle 6 Wege, s. o..

 
  Wenn es keinen triftigen Grund gibt, würde ich das dann gerne im Wiki
  ordentlich dokumentieren, dass der Name an allen Teilen eines
  Straßenzugs vermerkt wird.
 
 Ich habe dabei kein gutes Gefühl. Ich kann mir nicht vorstellen, dass
 das Fussgänger-Routing dadurch wirklich verbessert wird. Da kommen doch
 dann so Instruktionen raus wie folgen Sie 200m lang dem Fußweg
 Hauptstraße. Was ich eigentlich bei einem getrennten, aber zu einer
 Straße gehörigen Fußweg will, ist eine explizite Verknüpfung, die mir
 sagt: Dieser Fußweg gehört zu dieser Straße. Dann kann ich eine
 Routing-Anweisung generieren, die heißt: folgen Sie 200m dem Fußweg
 entlang der vierspurigen Hauptstraße oder so - viel klarer.

Wie verknüpfst du das? Relation street? associated_street?

 
  Es würde das Fußgängerrouting dann enorm erleichtern, wenn man nicht
  darüber spekulieren müsste, welcher Fußweg, gerade in Grenzfällen,
  noch dem Namen einer nahegelegenen Fahrbahn zuzuordnen ist und
  welcher nicht.
 
 Hier argumentierst Du, dass die Software durch eine Änderung in den
 Daten einfacher würde; zugleich hast Du vorhin das ebenso konstruierte
 Argument das Rendering ist einfacher, wenn der Name nur an einer Straße
 steht, als wertlos weggewischt. Genau die Raterei, 

Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

[Wolfgang Hinsch]

Am Sonntag, 5. April 2015, 16:51:16 schrieb fly:
 Hast Du nicht den Datensatz runtergeladen ?
 War da eine Lizenz dabei ?
 
 Falls nicht, hast Du den Satz als CC0 runtergeladen und der bleibt auch
 CC0, selbst wenn die Lizenz jetzt geändert ist.
 

Du meinst wahrscheinlich, ob eine von der auf der Seite zu dem Zeitpunkt 
angegebenen CC0-Lizenz abweichende Angabe im Datensatz war.

(Ganz ohne Lizenz  CC0)

Grundsätzlich ist das erst mal richtig, aber:

Es handelt sich sehr wahrscheinlich um einen Irrtum. Dies ist von uns bemerkt 
worden. Ob wir die Beute trotzdem einfach behalten und verwerten dürfen, ist 
fraglich. Bei der sehr zurückhaltenden OSM-Politik in diesen Bereichen 
zumindest im Projekt eher nein.

Außerdem halte ich es im Sinne eines Miteinanders mit der Verwaltung, bei der 
sich jetzt endlich etwas ändert, für kontraproduktiv, jeden Brocken, der mal 
versehentlich etwas daneben geworfen wurde, sofort mit Zähnen und Klauen zu 
schnappen und festzuhalten. Es gibt mit Sicherheit innerhalb der Verwaltung 
unterschiedliche Positionen und wir würden nur die Fraktion stärken, die 
sowieso der Meinung ist, die Piraten von OSM klauen sofort alles, was nicht 
niet- und nagelfest ist.

Im übrigen ist uns die Verwaltung schon sehr weit entgegen gekommen. Der in 
der Lizenz geforderte Quellenverweis muss nur angegeben werden, wenn er vom 
Datenanbieter bereitgestellt wird, und der schreibt ausdrücklich 
Namensnennung nicht erforderlich. 

Siehe auch Mail vom 2.4.15

Gruß, Wolfgang

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

Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

[Wolfgang Hinsch]

Am Donnerstag, 2. April 2015, 14:22:04 schrieb Johannes Kröger:
  Für die Datenlizenz Deutschland Namensnennung 2.0 finde ich bei uns
  keine belastbare Aussage, ob das Ding nun kompatibel ist oder nicht.
 
 Dito. :( Die Namensnennung im Changeset und der Homepage wird kaum
 gerecht sein, sie infiziert ja die Daten und muss erhalten bleiben.
 
 Sonst wären da wirklich tolle Daten verfügbar, Teile von ALKIS,
 Adressen, Gebäudegrundrisse etc. Die wären toll zum vorsichtigen
 Abgleichen.
 

Möglicherweise ist zwar die Deutschland-Lizenz 2 prinzipiell nicht kompatibel, 
aber in diesem Sonderfall schon. Laut Lizenz müssen die Pflichtangaben vom 
Anbieter der Daten bereitgestellt werden, wenn er sie verlangen will. Dieser 
Anbieter schreibt aber nur Namensnennung nicht erforderlich, ansonsten sehe 
ich da keine weiteren Forderungen.

Ich gehe davon aus, dass hier bewusst verzichtet wird. Darauf deutet auch die 
zunächst genutzte CC0. Dies ist jetzt gewissermaßen die amtliche CC0.

Gruß, Wolfgang

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

Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

[Wolfgang Hinsch]

Hallo,
Am Dienstag, 31. März 2015, 20:27:40 schrieb Johannes Kröger:
 Ich habe zwar noch keine Antwort von irgendwem offiziellen bekommen,
 aber der Datensatz (und die anderen CC0er) ist jetzt wie alles andere
 unter der Deutschlandlizenz. Da hätte ich wohl abwarten sollen, bevor
 ich es geschrieben habe, sorry!
 
 http://suche.transparenz.hamburg.de/dataset/hamburger-strasseninformationsba
 nk-hh-sib
 

Für die Datenlizenz Deutschland Namensnennung 2.0 finde ich bei uns keine 
belastbare Aussage, ob das Ding nun kompatibel ist oder nicht.

Ich vermute mal, dass schon einige Leute munter am Abpinseln sind.

Gruß, Wolfgang

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

Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

[Wolfgang Hinsch]

Am Montag, 30. März 2015, 13:07:00 schrieb Martin Koppenhoefer:
 Am 30. März 2015 um 12:47 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
  Ich frage aber doch mal nach:
  
  Reicht die Lizenz für uns aus?
  

 
 wieso, da steht doch cczero, mit link:
 http://creativecommons.org/publicdomain/zero/1.0/deed.de
 das heisst, es gelten überhaupt keine Auflagen, Du kannst damit machen, was
 Du willst (wie Public Domain). Namensnennung ist nicht erforderlich.

Hups, da hast du recht :)

Ich bin durch das crossposting da etwas von der Schiene gekommen. Es ging in 
einem anderen Thread auf talk-HH darum, ob die noch interessanteren 
Kreuzungsskizzen[1] ausgewertet werden dürfen, die stehen unter der 
Datenlizenz Deutschland – Namensnennung – Version 2.0 [2], bei der ich mir 
nicht so sicher bin.

Gruß, Wolfgang

[1] http://suche.transparenz.hamburg.de/dataset/kreuzungsskizzen-hamburg
[2] https://www.govdata.de/dl-de/by-2-0

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

Re: [Talk-de] [OSM-HH] Hamburger Straßennetz als CC0 veröffentlicht

[Wolfgang Hinsch]

Am Freitag, 27. März 2015, 13:36:25 schrieb Martin Koppenhoefer:
  Am 26.03.2015 um 19:03 schrieb Johannes Kröger
  johannes.kroe...@hcu-hamburg.de:
  
  Besonders bei solchen manuell eingestellten Daten. Sind
  doch alles auch nur Menschen. Es sind nur drei Datensätze mit CC0 im
  Transparenzportal, während alles andere unter der Deutschlandlizenz
  steht. Da sollte man erstmal sichergehen, dass sie wirklich so gedacht
  sind.
 
 wenn sie sie mit dieser Lizenz veröffentlichen dann sollte die wohl auch
 gelten, der Sinn einer Lizenz ist ja gerade, dass man nicht mehr nachfragen
 muss.

Ich frage aber doch mal nach: 

Reicht die Lizenz für uns aus? 

Was ist mit dem Quellenverweis für Abwandlungen, also das, was wir daraus 
machen? 
Wir können das im Kommentar zum Changeset unterbringen, aber derjenige, der 
die Daten von uns runterlädt, hat den Verweis nur, wenn bei jedem Objekt im 
Sourcetag der Quellenverweis auftaucht, was wohl praktisch kaum zu leisten 
ist.

Vor allem aber: Was ist mit Abwandlungen von Abwandlungen (Weiterverarbeitung 
unserer Daten)? 

Reicht ein Quelleneintrag auf der Quellenseite unseres Wiki?

Muss der Downloader in seinen Anwendungen wiederum den Quellenverweis 
mitführen?

Gruß, Wolfgang

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

Re: [Talk-de] heise berichtet ueber osm.org-Routing integration

[Wolfgang Hinsch]

Am Freitag, 20. Februar 2015, 00:32:24 schrieb Patrick Niklaus:
  Ich würde OSRM von der Auswahl entfernen, bis sie z. B. auch
 
 Abbiegerelationen und Anliegerstraßen beachtet, die gehören meiner Meinung
 nach zu den Grundfunktionen.
 
 Falls du Abbiegerelationen findest die nicht funktionieren, dann poste das
 bitte hier [1]. Momentan nicht unterstützt werden lediglich
 Abbiegerelationen bei den via ein Way ist.

Was schade ist, denn an dieser Stelle 

http://www.openstreetmap.org/directions?engine=osrm_carroute=53.60779%2C10.03524%3B53.60774%2C10.03872#map=18/53.60797/10.03697

gibt es dazu keine Alternative. Am Ende der Verkehrsinsel beginnt nahtlos eine 
Busspur, die nicht gequert werden darf. Rechtsabbieger müssen also rechts an 
der Verkehrsinsel vorbei fahren, alle anderen links. Google behilft sich mit 
falscher Straßendarstellung, die können es also auch nicht. Hätte OSM also die 
Nase vorn haben können...

Gruß, Wolfgang


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

Re: [Talk-de] cycleway=track bei Bordstein Trennung

[Wolfgang Hinsch]

Am Montag, 22. Dezember 2014, 13:28:16 schrieb huey212:
 Hallo, folgende Gedanken:
 
 ich mappe sehr viel Radverkehrspezifisches. Da stellt sich mir die
 Frage, was haben Radwege und (Auto-)Fahrbahnen gemeinsam?
 
 -ggf. einen Bordstein,
 -grob den gleichen Verlauf,
 -den gleichen Straßennamen,
 -die gleiche Beleuchtung
 
 Was ist unterschiedlich?
 
 -Der Verlauf im Detail
 -Fahrbahnbelag,
 -Nutzungsvorgaben (access)
 -Einbahnstraßenregelungen (Fast alle straßenbegleitenden
 innerstädtischen Radwege in Deutschland sind Einbahnstraßen! Fußwege
 hingegen nicht.)
 -Spuraufteilung
 -Abbiegebeschränkungen
 
 Ich halte das Anbringen von Fuß- und Radweginformation an der
 Hauptfahrbahn nur bei relativ grobem Mapping für sinnvoll. Sobald es in
 die Details geht sollte die Wege als einzelne Linienzüge erfasst werden.
 Alles andere wird unübersichtlich und ist nicht mehr editierbar (weil zu
 kompliziert). Von einer sinnvollen Auswertung reden wir mal noch gar nicht.

Die sinnvolle Auswertung besteht meistens aus einer Karte oder einem Router.

Die Karte hat, wenn gedruckt oder sonstwie als Übersicht genutzt, einen 
Maßstab, in dem die Symbole von Fahrbahn und Radweg sich gegenseitig 
verdecken. Man kann zwar im Web weiter hineinzoomen, einen Nutzen hätte das 
aber nur für eine Art Straßenkataster, das wir ohnehin nicht leisten können.

Der Router braucht verbundene Wege, um alle Abbiegemöglichkeiten nutzen zu 
können. Das wird häufig ausgelassen, wenn nur auf der Gegenseite ein Weg 
abzweigt.

Die Zuordnung des Radweges zu einer bestimmten Straße ergibt sich im 
innerstätischen Bereich aus der reinen Lage nicht immer. 

Daher meine ich, dass der Radweg, wenn er keine erheblich andere 
Streckenführung als die Straße selbst hat, an sie getaggt werden sollte. Das 
eigenständige Einzeichnen hat in hohen Zoomstufen einen optisch schönen Effekt, 
besonders im Zusammenwirken mit dem Luftbild, ist aber für die meisten 
Auswertungen eher hinderlich.

Als Ausweg bliebe noch, den straßenbegleitenden Radweg, wenn man es denn 
unbedingt möchte (und solange es überhaupt noch so etwas gibt), sowohl als tag 
als auch als eigenständigen Weg einzuzeichnen und dem Auswerter über eine 
Relation (street) oder über ein Tag (?) mitzuteilen, dass er sich hier die für 
ihn günstigere Variante aussuchen kann.

Übrigens gilt für den straßenbegleitenden Fußweg sinngemäß das Gleiche. Wenn 
der Radweg unbedingt ein eigenständiger Weg sein soll, müsste der Fußweg 
analog ebenfalls eigenständig eingezeichnet werden. Die Argumente sind 
letztlich die Gleichen, mit allen Vor- und Nachteilen.

Ob aber 5 Linienzüge im Verlauf einer Straße übersichtlicher als ein einzelner 
sind, muss wohl jeder Mapper für sich selbst entscheiden. Einen guten Editor 
(mit gutem css-Stil) vorausgesetzt, dürfte das Modell mit den Tags 
übersichtlicher darstellbar sein als das Modell mit den separaten Wegen. Dann 
erscheinen die Rad- und Fußwege optisch am Außenrand der Straße. Was bleibt, 
sind die längeren tags, dafür aber alle an einem Way zusammengefasst und nicht 
an 5 Ways verteilt. Auch hier kann ein guter Editor viel Übersicht schaffen.

Wenn wirklich die Straße genau abgemalt werden soll, halte ich eine 
zusätzliche Flächenerfassung für sinnvoller. Letztlich ist das die einzige 
Möglichkeit, in hohen Zoomstufen (und nur dort) die Straße mit allen 
Einzelheiten abzubilden. Auch dann bleibt aber die Frage, wer das eigentlich 
braucht, außer als schöne Ansicht.

Gruß, Wolfgang

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

Re: [Talk-de] cycleway=track bei Bordstein Trennung

[Wolfgang Hinsch]

Am Samstag, 13. Dezember 2014, 00:41:23 schrieb Hubert:
 
 Der Renderer, welcher den Bürgersteig an der Straße darstellen möchte,
 unterdrückt halt alle highway=footway + footway=sidewalk und stellt die
 highway=residential + footway:both=sidewalk entsprechend dar. Z.B. als
 roten Rand. Derjenige, der den Bürgersteig als eigenen Weg darstellen will,
 malt die highway=residential + footway:both=sidewalk als normale Straßen,
 ohne roten Rand, und stellt darfür die highway=footway +
 footway=sidewalk dar. So oder so ähnlich.
 

Damit der Renderer erkennen kann, dass die extra-Fußwege an die Straße gehören 
und er sich somit die (für den Maßstab) passendere Variante aussuchen kann, 
sollten es eine street-Relation geben, in der alle Linien, die zur gleichen 
Straße gehören, erfasst sind. Das erleichtert auch die Zuordung von 
Straßennamen etc. zu separaten Wegen.

Auf dem gleichen Weg kann auch die Diskussion um die separaten oder nicht 
separaten Radwege gelöst werden. Der Datenkonsument kann sich dann frei 
aussuchen, welche Lösung er für sich für geeigneter hält.

Gruß, Wolfgang

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

Re: [Talk-de] Suche Ansprechpartner und Lösungsvorschlag (elotse)

[Wolfgang Hinsch]

Hallo,

Am Mittwoch, 12. November 2014, 09:49:45 schrieb Joachim Kast:

 
  ... denn von dem Network-Vorschlag  halte ich persönlich für nicht optimal
  (Änderung eines Verwendungszweckes eines Tag's, müsste auch erst
  ausführlich diskutiert werden).
 Es mag sein, dass network=* nicht so optimal ist, aber mir fällt
 momentan auch nichts besseres ein. Bei der Analyse der
 network-Werteverteilung [1] findet man jedoch so ein wohlgeordnetes
 kreatives Chaos, dass es auf ein network=eBusinesslotse eigentlich auch
 nicht mehr ankommt.
 
 Ziel dieser wie auch immer aussehenden Kennzeichnung soll sein, die
 dezentral eingegebenen Daten für eine App einzusammeln. Das könnte man
 prinzipiell auch über die Auswertung des Anfangs des Name-Tags bei einer
 einheitlichen Namensgebung machen, aber ich finde eine eigene key/value
 Kombination dennoch besser.
 
 
 Sollte jemand eine optimalere Lösung anstatt network=eBusinesslotse
 haben, dann möge er seinen Vorschlag hier bitte präsentieren.
 

Letztlich läuft es immer wieder auf das gleiche Problem hinaus, über das seit 
mehreren Jahren diskutiert und für das immer wieder eine Lösung abgelehnt 
wurde: Eindeutige Verweise auf OSM-Daten aus anderen Datenbeständen heraus.

Alles schreit nach externen Datenbanken (Nicht alles in OSM kippen), aber 
eine Lösung gibt es bis heute nicht, so dass letztlich Insellösungen gebastelt 
werden, die individuell Tags festlegen, mit denen dann die Daten 
referenzierbar sein sollen. Wenn das so weiter geht, haben wir bald ein 
schönes Sammelsorium von verschiedensten Tags, für jede Anwendung ein paar.

Ich schlage daher vor, über _ein_ objektbezogenes Referenz-Tag nachzudenken, 
dass in eindeutiger Form, wo notwendig, vergeben wird und das dann jeder 
Nutzer für seine Anwendung benutzen kann.

Ich werfe mal ein Tag in den Ring:

externel_reference_id=[nwr]{derzeitige-id-Nummer}

also ein Tag, das bei Bedarf jederzeit mit den Editoren erzeugt werden kann 
und dessen Wert einfach der derzeitigen Objekt-ID entnommen wird,
also z.B. für Ways 

externel_reference_id=w1234567890

ERID im Folgenden

Für Relationen und Nodes eben mit n bzw. r

Ich könnte mir vorstellen, dass es ohne besonderen Aufwand möglich wäre, die 
Editoren entsprechend zu erweitern. Das Tag sollte nur vergeben werden, wenn 
tatsächllich Bedarf für eine externe Refernenz besteht, dann aber einheitlich 
von allen Interessenten nutzbar sein.

Vorteil gegenüber dem heutigen Gebastel: Ein Tag für alle und gut.
Vorteil gegenüber der ID direkt: Wird das Objekt geteilt oder verschmolzen, 
bleibt das Tag im Gegensatz zur ID erhalten, es überlebt auch eine Änderung 
des Datentyps, z.B. von Node auf Way. 

Natürlich bleiben noch Fragen. Was passiert, wenn zwei Referenzobjekte 
verschmolzen werden.

Man könnte die ERIDs dann mit Trennern aufzählen, aber das führt 
möglicherweise zu Datensalat.
Besser wäre es, wenn das neue Objekt eine eigene ERID bekommt oder eine der 
ERIDs fortführt. Die Kontinuität ist gegeben,wenn in der letzten Version der 
untergehenden ERID ein Tag mit einem Hinweis auf die Folge-ERID gesetzt wird.

Eine Abfrage nach einer Referenz muss also immer nach der ERID mit der 
maximalen Versionsnummer suchen. Steht dort ein Verweis auf die neue ERID, 
wird im Datenbestand des Nutzers der Verweis entsprechend aktualisiert und er 
sucht nach dem Datensatz mit der neuen ERID.

Letzlich also: Extern verlinkte Objekte haben 2 zusätzliche Tags (ERID und 
ERID-Version), und damit gut für alle. 

Nur für den Fall, dass der Verweis in ein anders Objekt überführt wurde 
(Verschmelzung etc.), gibt es in der letzten Version des alten Objekts ein 
extra-Tag mit einem Hinweis auf die neue ERID.

Der Vorschlag ist nicht perfekt und nicht zu Ende gedacht. Ich habe das jetzt 
nur mal so aus dem Ärmel geschüttelt, aber wenn echtes Interesse an einer 
endgültigen Lösung besteht, könnte man ein Proposal im Wiki anlegen und die 
Sache von allen Seiten beleuchten.

Gruß, Wolfgang

(der das Problem auch schon hatte)

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

Re: [Talk-de] Karte auf openstreetmap.de defekt

[Wolfgang Hinsch]

Hallo

Am Donnerstag, 23. Oktober 2014, 19:27:07 schrieb Pascal Neis:
 Hi,
 
 Wolfgang Hinsch schrieb:
  Von mir aus kann es auskommentiert bleiben. Wer brauchts?
 
 die Idee dahinter kennst du?
 
 Wir (Frederik  ich) hatten eigentlich vor zwei Jahren [1]
 etwas ähnliches geplant was vor kurzen von jemand anderem unter
 dem Titel Predicting data curation in OpenStreetMap[2] gezeigt
 wurde.
 
 Also auf Basis der Information WO sich jemand die online Karte
 ansieht und den Infos z.B. von der Bevölkerungsdichte Statistiken
 zu generieren wo evtl. eine gute oder schlechte Vollständigkeit
 vorliegt.

 [1] http://www.remote.org/frederik/tmp/ilike.pdf
 [2] https://www.mapbox.com/blog/osm-tracing-candidates/

Diese Idee hätte allgemein ersichtlicher kommuniziert werden sollen. Mein 
persönlicher Eindruck war, dass dieser Spielkram den Gesamteindruck der 
Präsentation der Karte ruiniert hat.

Vielleicht wäre eine geschicktere Gestaltung mit mehr Abstand zu 
Gesichtsbüchern eine Abhilfe gewesen.

Nebenbei: An der Darstellung von Mapbox überrascht mich nichts, außer 
vielleicht, dass die Ex-Position von Lummerland ein Hotspot ist :-)
Die meisten Informationen hätte ich mir auch so vorstellen können.

Außerdem - Der Unterschied zwischen uns und kommerziellen Kartendiensten ist 
ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte ansieht. 
Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust 
hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus meiner 
Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz zum 
kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit aufgelöst 
die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam der 
Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt und 
Akribie aufgenommen wie der Times Square in New York.

Gruß, Wolfgang

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

Re: [Talk-de] Karte auf openstreetmap.de defekt

[Wolfgang Hinsch]

Am Freitag, 24. Oktober 2014, 15:18:06 schrieb Falk Zscheile:
 Am 24. Oktober 2014 15:02 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
  Außerdem - Der Unterschied zwischen uns und kommerziellen Kartendiensten
  ist
  ja gerade der, dass es uns egal ist, wo wer wie oft sich die Karte
  ansieht.
  Bei uns wird da gemappt, wo der Mapper hinfällt (vor Ort ist/Lust
  hat/Luftbilder gut sind/...). Auf sehr lange Sicht ist unser Ziel (aus
  meiner
  Sicht) eine einigermaßen gleichmäßige Erfassung weltweit, im Gegensatz zum
  kommerziellen Anbieter, der sich die Frage stellen _muss_, wie weit
  aufgelöst
  die Karte wo angeboten werden sollte. Bei OSM wird das letzte Wigwam der
  Mohikaner - falls ein Mapper vorbeikommt - mit der gleichen Sorgfalt und
  Akribie aufgenommen wie der Times Square in New York.
  
  
 Aber auch wir haben es mit knappen Ressourcen zu tun (z.B.
 Rechenkapazität). Man könnte also z.B. Regionen identifizieren, wo man
 einen höhere Auflösungen rendert ...

Wobei wir wieder beim Anbieter von Karten sind, nicht bei OSM. Wir schaffen 
eine Geodatenbank. Das Rendern ist nicht Sache von OSM, sondern eine von 
vielen möglichen Anwendungen.

Unsere Karte auf der Hauptseite, en wie de, ist vor allem eine 
Motivationsstütze für die Mapper und nur ganz, ganz nebenbei und unter engen 
Voraussetzungen ein Angebot für die Öffentlichkeit. 

Insofern ist es auch logisch und folgerichtig, dass ein Unternehmen wie Mapbox 
als Datennutzer sich fragt, wo am meisten Nachfrage besteht. 
Überraschenderweise da, wo die meisten Leute in einer einigermaßen 
durchtechnisierten Umgebung leben. Das hätte man auch mit dem Finger im Wind 
erraten können, aber jetzt ist es eben amtlich.

So ähnlich wird Geld mit Verkehrszählungen verbraten. Jeder weiß, dass auf der 
A8 mehr los ist als auf der Dorfstraße von 
Hinterpfaffenburgstedtwinkelstättenhofen. Aber gezählt ist es doch viel 
ordentlicher und amtlicher ;-)

Gegenden, in denen möglicherweise höher aufgelöst gerendert werden _könnte_, 
ergeben sich so durch die Datendichte. Allerdings stellt sich die Frage, ob es 
sinnvoll ist, Gebiete, die schon überproportional erfasst sind, durch weiter 
aufgelöstes Rendern noch weiter zu pushen, so dass dort irgendwann jeder 
Krümel erfasst ist, wogegen in anderen Regionen noch die Straßennamen fehlen 
(Schleswig-Holstein z.B., von Afrika gar nicht zu reden).

Gruß, Wolfgang

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

Re: [Talk-de] Karte auf openstreetmap.de defekt

[Wolfgang Hinsch]

Hi,

Am Mittwoch, 22. Oktober 2014, 13:48:17 schrieb Sven Geggus:
 Sven Geggus li...@fuchsschwanzdomain.de wrote:
  Ich vermute, dass das mit der kaputten Platte auf dem devserver
  zusammenhängt auf dem dieses komische iLike OSM läuft.
 
 Das wars ich hab das fürs Erste mal im Quellcode auskommentiert.
 

Von mir aus kann es auskommentiert bleiben. Wer brauchts?

Gruß, Wolfgang

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

Re: [Talk-de] Einladung und Call for Papers für die Kieler Open Source und Linux Tage

[Wolfgang Hinsch]

Hallo,
nochmal zur Erinnerung:

Wir möchten das OSM-Projekt einladen, bei den Kieler Open Source und
Linux Tagen, einem mittelgroßen Linux-Event in Kiel, mitzumachen.

Hier die Details:

Datum: 
19. September 2014, ca. 8 - 18 Uhr 
20. September 2014, ca. 10 - 18 Uhr 
(20.9. ist SFD)
Ort: Kieler Innovations- und Technologiezentrum (KiTZ), neben der
Christian-Albrechts-Universität

Am Donnerstag, 15. Mai 2014, 16:42:14 schrieb Wolfgang Hinsch:
 Hallo,
 
 ich habe einen OSM-Stand eingetragen.
 
 Wiki-Seite: https://wiki.openstreetmap.org/wiki/KielerLinuxTage
 
 Mitstreiter willkommen!
 
 Gruß, Wolfgang
 


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

Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

[Wolfgang Hinsch]

Am Dienstag, den 03.06.2014, 13:39 +0200 schrieb Martin Koppenhoefer:
 Am 3. Juni 2014 11:30 schrieb Falk Zscheile falk.zsche...@gmail.com:
 
  Ich denke, jetzt hat jeder Interessierte genug Argumente, um sich
  zwischen permessive und yes zu entscheiden, also zwischen quasi
  öffentlichem Raum und privatrechtlich gewährtem Zugang zu wählen.
 
 
 kurz möchte ich hier doch noch zu bedenken geben, dass yes nicht quasi
 öffentlich bedeutet, sondern dass es bedeutet, dass der Zugang öffentlich
 rechtlich gesichert ist. Permissive bedeutet ja, dass man Zugang bekommt,
 nur eben nicht, dass man auch ein sicheres Anrecht darauf hat.
 
  Bei den Aussagen und Folgerungen aus dem BVerfG-Urteil werden wir uns
  wohl nicht einig werden
 
 
 Jein, ich finde das Urteil persönlich ja durchaus begrüßenswert, nur deckt
 sich das nicht mit meiner persönlichen Erfahrung der gelebten Realität. Was
 soll man denn tun, wenn man trotz des Urteils rausgeworfen wird, ggf. von
 der Polizei, die gerufen wurde, weil man der Aufforderung zu gehen nicht
 nachkam, bzw. wenn man gar nicht erst eingelassen wird, und physisch vom
 Wachpersonal am Zugang gehindert wird? Ein Hinweis auf das BVerf.G. Urteil
 wird da doch nur mit Unverständnis quittiert werden. Selbst wenn man auf
 Zugang klagen würde und sogar Recht bekäme, dann wäre dieses Recht für
 den konkreten Fall doch nichts mehr wert, weil seitdem Monate und Jahre
 vergangen sind.

Wie immer ein Problem zwischen Recht haben und Recht bekommen,
zusätzlich möglicherweise noch ein Beweisproblem, wenn die Wachleute
irgendetwas behaupten. Das sollte man aber nicht mit der Rechtslage
vermengen, sonst mappen wir gute, mittlere und böse
Einkaufszentren, eventuell noch nach den Dienstplänen der jeweils
Verantwortlichen ;-)

access versucht, die gesetzlichen Zugangsbestimmungen für Wege
abzubilden (Zitat dt. Wiki)

Möglicherweise fehlt noch ein tag zwischen 
- permissive (jemand erlaubt den Zutritt in der Regel, ggf. während der
Öffnungszeiten, könnte ihn aber verweigern) und 
- yes (jeder hat das Recht, dort zu sein, was aber letztlich auch
Grenzen hat, siehe Sondernutzung)
 
- obligatory_tolerance (Duldungspflicht, es besteht ein Recht, sich
dort aufzuhalten, ggf. innerhalb von Öffnungszeiten, es ist aber nicht
so umfassend wie im Fall von yes) ?

Damit bekäme man auch Wege in den Griff, die sich zwar im Privateigentum
befinden, dennoch aber für den öffentlichen Verkehr freigegeben sein
müssen.

Gruß, Wolfgang


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

Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

[Wolfgang Hinsch]

Hallo,
Am Montag, den 02.06.2014, 10:15 +0200 schrieb Bernd Wurst:
 Hallo.
 
 Am 02.06.2014 08:41, schrieb Falk Zscheile:
  Die Regeln sind jedenfalls deutlich eher die eines privaten Hofs als die
   eines oeffentlichen Raumes / Strasse.
  Mit solch einer Aussage wäre ich in Deutschland vorsichtig. Seit dem
  Fraport Urteil des Bundesverfassungsgerichts[1] reicht es nicht mehr,
  dass ein Einkaufszenrum o. ä. in privater Hand ist um nach Belieben
  Dritte vom Zugang auszuschließen. 
  Jedenfalls wenn diese Dritte ihre
  Grundrechte auf Meinungsäußerungs- und Versammlungsfreiheit dort
  ausüben wollen. Wie es in Italien ist, das weiß ich nicht. Jedenfalls
  sind mit dieser Entscheidung deutlich in Richtung öffentlichen Raum
  gerückt worden. Ich weiß, dass man access=Grundrechtsausübung nicht
  mappen kann, aber den Vergleich Bauernhof--Einkaufszentrum wollte ich
  dann doch hier nicht so stehen lassen.
 
 Das Urteil stützt sich maßgeblich auf den Fakt, dass die Fraport AG zu
 über der Hälfte in Besitz der öffentlichen Hand ist:
 Von der öffentlichen Hand beherrschte gemischtwirtschaftliche
 Unternehmen unterliegen ebenso wie im Alleineigentum des Staates
 stehende öffentliche Unternehmen, die in den Formen des Privatrechts
 organisiert sind, einer unmittelbaren Grundrechtsbindung. (46)

Ja, aber erweitert auf z.B. Einkaufszentren in Randnummer 68 ff. und
noch stärker 98 ff.

 
 In der abweichenden Meinung eines Verfassungsrichters (111 ff) findet
 sich ja grade die Einschätzung, dass bei Betrachtung der Einzelanteile
 jeder öffentliche Anteilseigner nur Minderheitsbeteiligter ist und daher
 das Urteil hätte anders lauten müssen. Typische Einkaufzentren befinden
 sich nicht (überwiegend) in Besitz öffentlicher Anteilseigner sondern
 sind wirklich private Betriebe. Daher lässt sich dieses BVerfG-Urteil
 hier sicherlich nicht übertragen.

Es ist ausdrücklich nicht dafür entschieden, aber u.a. in den
Randnummern s.o. gibt die ganz erhebliche Mehrheit (7:1) der Richter
hier einen deutlichen Hinweis, dass sie diese Bereiche dem freien
Himmel gleichstellt.

 
 Die Ausgangslage ist also anders und IMHO doch eher mit einem Hof zu
 vergleichen. 
-1

 Dass Einkaufszentren ihren Teil zur öffentlichen
 Infrastruktur (Grundversorgung) beitragen und daher nicht nach Belieben
 Leute vom Einkauf in den Geschäften ausschließen können halte ich zwar
 für richtig, aber die Zeiten zu denen geöffnet ist kann der Inhaber
 durchaus verändern. Er kann ja auch von heut auf morgen einfach zumachen
 wenn der Hauptmieter pleite ist.
+1

 
 Ich gehe zumindest davon aus, dass mit nach Gutdünken verweigert werden
 kann nicht unbedingt die individuelle Gesichtskontrolle gemeint ist
 sondern die Tore nach Belieben auch mal geschlossen bleiben können wenn
 der Eigentümer das so will. Oder sich die Öffnungszeiten verschieben
 können. Das Recht, diese Fläche zu nutzen, insbesondere als
 Durchgangsweg, ist nicht öffentlich vorgegeben sondern ist abhängig von
 dem Willen des Eigentümers, dass da jetzt grade jemand laufen können
 soll. Er könnte das auch baulich so umgestalten dass ein direktes
 Durchgehen unattraktiv wird.

Bezüglich der Öffnungszeiten +1

Der Betreiber hat sicherlich das Recht, zu entscheiden, wann er seine
Flächen allgemein zugänglich machen will. Er wird aber sicher nicht
sagen können, Oh nein, da kommt schon wieder X, wir schließen jetzt mal
spontan. Selbst dann, wenn X nicht einkaufen, sondern Flugblätter mit
seiner Meinung verteilen will. Insofern ein sehr interessantes Urteil.

:-)

Allerdings wird es jetzt ziemlich OT.

Gruß, Wolfgang



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

Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

[Wolfgang Hinsch]

Am Sonntag, den 01.06.2014, 22:27 +0200 schrieb Christian H. Bruhn:
 am Donnerstag, 29. Mai 2014 um 13:59 schrieb Bernhard Weiskopf:
 
  Die zeitliche Zutrittsbeschränkung möchte ich in OSM erfassen, damit
  Navigationsgeräte nur zu den Öffnungszeiten hier durchleiten.
 
 Du kannst es gerne eintragen, aber bitte gehe nicht davon aus, das es
 auch nur ein Routingprogramm gibt, welches diese Angabe nutzt.

Das sollte beim Mappen auch nicht das Kriterium sein. Wenn man kein Ei
mappt, kann es auch keine Henne geben - oder so ähnlich ;-)

Gruß, Wolfgang


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

Re: [Talk-de] Wege mit zeitlicher Zutritts-Beschrängung

[Wolfgang Hinsch]

Hallo

Am Freitag, den 30.05.2014, 01:59 +0200 schrieb Martin Koppenhoefer:
 
  Am 29/mag/2014 um 22:55 schrieb Bernhard Weiskopf bweisk...@gmx.de:
  
  Da bei geschlossener Tür niemand und bei offener Tür theoretisch auch andere
  reinkommen, verwende ich für access die allgemeine Form, hier also:
  
  access = no
  access:conditional = yes @ (Mo-Sa 07:00-20:30; PH off)
  barrier = gate
  foot = yes
 
 
 bei einem Einkaufszentrum würde ich statt yes lieber permissive verwenden, 
 weil der Zugang auf Privatgelände normalerweise nicht rechtlich gesichert ist 
 sondern nach Gutdünken verweigert werden kann.

Ich bin mir da nicht so ganz sicher. Das Verweigern nach Gutdünken
könnte diskriminierend sein.

Bei einem Einkaufszentrum gelten andere Regeln als in Wohnzimmer ;-)

Gruß, Wolfgang


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

Re: [Talk-de] Rettet die Kleingarten-Wegenamen

[Wolfgang Hinsch]

Am Montag, den 19.05.2014, 05:50 +0200 schrieb Bernd Wurst:
 Hallo.
 
 Am 19.05.2014 02:14, schrieb Wolfgang Hinsch:
  Der Auswerter für die Navigation kann nur alle Wege im
  Kleingarten rausschmeißen oder mit mit einem Auswahlmenü für 20 Wege
  kommen, weil die Blumennamen so gerne vergeben werden. Deinen
  offiziellen Wegnamen im Kleingarten findet in beiden Fällen kaum einer.
 
 Wenn du es algorithmisch schaffst, die Wege im Kleingarten zu
 identifizieren und gezielt aus dem Suchindex rauszuschmeißen, dann
 sollte es auch gehen die Straßennamen um die Angabe der
 Kleingartenanlage zu erweitern (Rosenstraße, Kleingartenanlage XY).
 Und schon hast du den Nachteil zu einem echten Vorteil gewandelt.
 
 Grade die Kleingartensiedlungen die groß genug für Straßennamen sind,
 haben durchaus auch mal mehrere Eingänge und damit macht es Sinn, gleich
 das richtige Ziel anzusteuern.

Darin sehe ich nicht das Problem. Das Problem besteht darin, dass 
1. private Wegebezeichnungen auch außerhalb von Kleingärten auftreten
können und
2. aus den Daten nicht erkennbar/berechenbar/herleitbar ist, ob der Weg,
der sich in dem Park oder der Kleingartenanlage oder wasauchimmer
befindet, nun einen offiziellen Namen hat oder nicht. Denn auch in
Kleingartenanlagen gibt es stellenweise offizielle Wegebezeichnungen.

Praktische Folge: Der (z.B.) Taxifahrer bekommt entweder eine Hasskappe,
weil er den Namen in seinem OSM-Navi nicht findet, oder weil er den
Namen 10x findet. Im Falle des offiziellen Namens im Kleingartengebiet
mit Zusatz Kglv xx, nicht unterscheidbar von den wirklich lokalen
Kleingartennamen. In beiden Fällen wird er OSM entsorgen.

Ich bin schon konkret darauf angesprochen worden, dass die Daten für
eine professionelle Adresssuche unbrauchbar sind.

Das ist offensichtlich von der Mehrheit bei OSM so gewollt.

Die Straßenlistenauswertung ist übrigens auch recht spaßig, wenn die
Verwaltung 132 Straßennamen kennt, die bei OSM fehlen und in OSM 621
Namen sind, die der Verwaltung fehlen. Ca. 90% dürften Kleingartennamen
sein, der Rest falsche Schreibweisen, ein Bruchteil Fehler der
Verwaltung oder von OSM.

Vielleicht könnte man wenigstens aus der Straßenlistenauswertung alle
Namen in Kleingartengebieten rausschmeißen, dann kann man wieder
vernünftig manuell vergleichen.

Gruß, Wolfgang


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

Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten

[Wolfgang Hinsch]

Am Montag, den 19.05.2014, 09:37 +0200 schrieb Falk Zscheile:


 
 Als Lösung schlagen einige hier vor das vorhandene Tagginschema so zu
 nutzen, dass Irrtümer weitgehend ausgeschlossen werden, insbesondere
 auf der Auswertungsseite zu schauen, ob man dort nicht etwas
 verbessern kann, bevor man daran geht zu sagen name bedeutet etwas
 anderes als name

Wie gesagt, den offiziellen Namen im Kleingartengelände kann keine
Auswertung vom Phantasienamen unterscheiden. Und es gibt auch in anderen
Zusammenhängen privat benannte Wege.

 
 Wenn es wirklich keine Lösung auf der Auswertungsseite gibt, dann
 könnte ich mir auch vorstellen, dass man für nicht amtlich
 registrierte Wege ein name=value und ein official_name=nonexistent
 vergibt, obwohl das auch gegen die OSM-Konvention ist und bei den
 Kartenrenderern vielleicht zu Problemen führt. Es handelt sich bei
 nonexistent ja schließlich nicht um einen echten Namen, sondern um
 eine technische Interpretationsregel.

 Jedenfalls würde ich mich über mehr Beiträge freuen, die über Lösungen
 nachdenken, die nicht die Inhaltsdefinition von name=value berühren.

Oder anders ausgedrückt, mit Zusatztags beschreiben, was name=value
definiert, damit die Mapnik-Karte nicht berührt wird. Obwohl man auch
loc_name rendern könnte, wenn name fehlt. ;-)

Ich vermute mal, dass das für die meisten der Hauptgrund ist.

official_name ist vergeben und sollte nicht umdefiniert werden.

loc_name statt name passt IMO, soll aber nicht benutzt werden.

source:name=inofficial?
name_operator=local?

Gruß, Wolfgang



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

Re: [Talk-de] Privat oder nicht von der öffentlichen Verwaltung benannte Wege, was: Wegenamen in Kleingärten

[Wolfgang Hinsch]

Am Montag, den 19.05.2014, 15:30 +0200 schrieb Martin Koppenhoefer:

 
 Es gibt auch privat benannte Wege, wo dieser Name amtlich und offiziell
 ist, bsp. Inge-Beisheim-Platz in Berlin (super zentral gelegen):
 http://www.openstreetmap.org/?mlat=52.51067mlon=13.37574#map=19/52.51067/13.37574
 
 http://de.wikipedia.org/wiki/Otto_Beisheim
 
 Hintergrund:
 http://www.berlin.de/ba-mitte/bezirk/gedenken/inge_beisheim.html



 
 Da kann sich jeder selbst eine Meinung bilden, nur weil die Kleingärtner
 weniger Geld haben, und deren Namen daher nicht offiziell werden würde ich
 die nicht gleich abwerten ;-)

Stop! Ich will keine Kleingärtner oder ihre Straßennamen abwerten, ich
möchte nur unterscheiden können zwischen ist amtlich oder ist nicht
amtlich. U.a. weil ist amtlich meistens, wenn auch nicht immer ist
eindeutig in der Administration, in (fast) jedem Fall aber ist in der
Liste der Administration.

Wer es für wichtig hält, kann ja taggen, ob der Name privat vergeben und
amtlich anerkannt oder amtlich vergeben und privat anerkannt wurde ;-)

Gruß, Wolfgang




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

[Talk-de] Wegenamen in Kleingärten

[Wolfgang Hinsch]

Hallo,

in vielen Kleingartenanlagen vergeben die Kleingärtner Wegenamen nach
eigenem Ermessen. Das führt dann dazu, dass z.B. der Dahlienweg in HH
10x oder öfter existiert, davon aber nur 1x offiziell von der Stadt
benannt und in öffentlichen Verzeichnissen vorhanden.

Wenn das Tag name für diese Wege benutzt wird, macht das die Navigation
nach OSM-Daten unbrauchbar, für jeden Navi-Benutzer wie für
Rettungsdienste, Taxi etc.

Ich würde vorschlagen, in Fällen, in denen der Name nicht offiziell ist
(es gibt auch offizielle Namen), das Tag loc_name zu benutzen, da der
Namen nur lokal im Bereich der jeweiligen Gartenanlage gilt. Name sollte
dann nicht vergeben werden.

Gegenargument der meisten Mapper dürfte sein: Dann steht der Name aber
nicht in der Karte. 

Das ist einerseits Mapping für den Renderer versus Mapping für den
Router, andererseits On The Ground steht der Name dran, aber er ist On
The Ground ebenfalls nur gültig im lokalen Bereich, nicht etwa
gemeindeweit.

Vielleicht könnte man durch ein Ticket erreichen, dass bei fehlendem
Name-Tag an Verkehrswegen auf ein loc_name-Tag geprüft und dieses in
Z17-19 angezeigt wird.

Meinungen?


Gruß, Wolfgang


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

Re: [Talk-de] Rettet die Kleingarten-Wegenamen

[Wolfgang Hinsch]

Am Sonntag, den 18.05.2014, 21:45 +0200 schrieb Jan Tappenbeck:
 Hallo Wolfgang,
 
 ich weiß einfach nicht, warum Du immer wieder gegen die Namen in den 
 Kleingärten bist. Wenn es Dich für Deine Karten stört, dann rechne diese 
 doch mit einer Datenbankfunktion raus

Blödsinn. Du solltest eigentlich wissen, dass ich das auch ohne deinen
Rat machen würde, wenn es mir darum ginge.

Ich bin nicht gegen Namen in Kleingärten, sondern will nur die
Phantasienamen örtlicher Kleingärtner (und Vergüngungsparks etc.)
eindeutiger von den offiziellen Namen unterscheiden können. Im Moment
sieht es so aus, dass in Aufbereitungen für das Routing alle Namen
innerhalb Kleingärten entweder rausgeschmissen werden müssen, egal ob
sie offiziell sind oder nicht, oder es kommt zu umfangreichen
Auswahllisten. Wenn die Kleingärten die gleiche PLZ haben, hilft auch
eine Auswahlliste nicht weiter, kennt man die PLZ nicht, ist man
aufgeschmissen. Ein Taxifahrer schmeißt nach so einer Erfahrung
OSM-Karten sofort über Bord. Das halte ich für unbefriedigend.


 Solange nicht anderer Missbrauch des Namen-Tags bereinigt ist sollten 
 man sich an den Laubenpiebern nicht vergreifen.
??

  Möchte nur die Benennung 
 der Bushaltestellen am Hamburger ZOB anführen. Die ersten 10-20 Straßen 
 in alphabetischer Reihenfolge für HH sind die Haltestellen dort.

Wenn es dich stört (und falsch ist), ändere es. Nicht meine Baustelle.
Und OT.

 
 Die Frage nach der Benennung der offiziellen Straßennamen ist wer diese 
 durchführt. Bei städtischen Straßen ist das zwangsläufig die öffentliche 
 Verwaltung. Wie ich schon in dem Posting im Forum geschrieben habe 
 (http://forum.openstreetmap.org/viewtopic.php?id=22750 - hier ging es 
 mal wieder um die KLG-Parzellennummern die einige stört und nun 
 gnadenlos auf die schnelle und ohne offizielle Abstimmung umgestellt 
 wurden. Wo sind die Wächter über die Tags und Massenedits??) gibt es in 
 der offiziellen Liste der Hansestadt Lübeck Wege in den Kleingärten 
 (Beispiel Parade 1-7 u.a.http://www.openstreetmap.org/?way=35050005) die 
 ich nur durch Zufall in einem Kleingartengelände gefunden habe.

Genau. Der Auswerter für die Navigation kann nur alle Wege im
Kleingarten rausschmeißen oder mit mit einem Auswahlmenü für 20 Wege
kommen, weil die Blumennamen so gerne vergeben werden. Deinen
offiziellen Wegnamen im Kleingarten findet in beiden Fällen kaum einer.

 
 Was ist mit den Wegen im Forst und im Feld - denen kann ich nicht 
 ansehen, ob diese offiziell sind und dennoch schreibe ich diese in OSM 
 rein. Genauso verhält es sich mit den Klg-Namen.

Auf den ersten Blick kannst du es nicht sehen, richtig. Schreib ihn
ruhig rein. Wenn weitere Erhebungen ergeben, dass er nicht offiziell
ist, kann er immer noch auf ein passenderes *_name-tag verschoben
werden.


Ich könnte übrigens auf meinem Grundstück meine Wege mit
Mönckebergstraße, Heidenkampsweg oder ähnlichem benennen, einen
Pfahl reinrammen und mit einem Holzschild beschriften. Anschließend On
The Ground mappen. Viel Spaß.

Was machen wir eigentlich, wenn tatsächlich irgendwelche Spaßvögel auf
so eine Idee kommen? Das klingt jetzt vielleicht unwahrscheinlich, aber
dem einen oder anderen Oberförster würde ich so was schon zutrauen.

 
 Wenn es einem um die Mehrfachnennung von Namen geht, dann gibt es 
 sicherlich auch Orte, entstanden aus Zusammenlegungen, wo die Dorfstraße 
 mehrfach vorkommt.

Ich weiß, dass in Meck-Pomm wegen einer Zusammenlegung von Gemeinden
ganz genau die Dorfstraße umbenannt wurde, um doppelte Straßennamen zu
vermeiden. In einigen Ländern ist das sogar im Gesetz so vorgesehen, lt.
entspr. Postings hier. Ob das im Meck-Pomm gesetzlich erzwungen wird,
entzieht sich meiner Kenntnis. Vernünftig ist es auf jeden Fall.

 
 Auf der anderen Seite ist OSM doch ein Projekt das für die breite Masse 
 und will sich von den anderen abheben.

Genau. Im Moment hebt es sich dadurch von anderen ab, dass ich mit
meinem Nüvi mit der Garmin-Karte eine Rosenstraße in Hamburg finde. Mit
der OSM-Karte finde ich mit demselben Gerät 9 verschiedene Rosenstraßen.
Ein echtes Alleinstellungsmerkmal. Jetzt frage mal, warum kein
Autohersteller OSM-Karten in sein Navi einbaut.

  Jeder hat andere Interessen - den 
 einen interessieren die Wege und den anderen die anderen. Bei einem 
 Besuch bei den Kleingärtnern war man begeistert das mal einer die Wege 
 alle erfaßt hat.

Wieder nicht zuende gedacht. Mapnik könnte bei fehlendem name-Tag auf
das nächstliegende ausweichen.

  Ich finde es schon sch... genug das durch den o.g. 
 Massenedit plötzlich all die mühsam erfaßten Parzellennummern 
 rausradiert wurden. Das steht noch auf einem anderen Blatt und wird bei 
 uns Thema auf dem nächsten Stammtisch sein..
 

eben, anderes Blatt.

 Also Rettet die Kleingarten-Wegenamen

Unsinn, die will niemand rausschmeißen. Oder sollte sich das nur auf
Mapnik beziehen (für den Renderer... ?)

Die Mehrheit bei OSM geht im Moment den Weg, das Name-Tag zu verwenden.
Die 

Re: [Talk-de] Wegenamen in Kleingärten

[Wolfgang Hinsch]

Am Sonntag, den 18.05.2014, 22:03 +0200 schrieb Mark Obrembalski:
 On 18.05.2014 21:17, Johannes wrote:
  Sehe ich genauso. Wenn etwas keinen amtlichen Namen hat gehört es
  in loc_name rein und name entfernt.
 
 Quatsch! Kein Laden, keine Kneipe hat einen amtlichen Namen. 

Dann mach mal einen Laden ode eine Kneipe auf. Du wirst dich wundern, in
wie viele Verzeichnisse, Anmeldungen, Lizenzen, Genehmigungen ... du den
Namen eintragen musst. Und zwar immer denselben. Aussuchen darfst du ihn
dir selbst, ja. Aber anschließend ist er deine Firma. Kannst du
jederzeit ändern. Aber du wirst dich wundern, in wie viele
Verzeichnisse ... ;-)

Gruß, Wolfgang


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

Re: [Talk-de] Rettet die Kleingarten-Wegenamen

[Wolfgang Hinsch]

Hi, ps:
 Am Sonntag, den 18.05.2014, 21:45 +0200 schrieb Jan Tappenbeck:

   Ich finde es schon sch... genug das durch den o.g. 
  Massenedit plötzlich all die mühsam erfaßten Parzellennummern 
  rausradiert wurden. Das steht noch auf einem anderen Blatt und wird bei 
  uns Thema auf dem nächsten Stammtisch sein..
  

:1,$ s/rausradiert/auf das ref-Tag verschoben/g

Rausradiert wurden sie aus der Mapnik-Karte, nicht aus den Daten.

In Hamburg hat jemand in Alsternähe sämtliche landuse=residential
rausradiert. Aus den Daten rausvandaliert, nicht verschoben. Weil sie
eine Zeit lang in der Mapnik-Darstellung Vorrang vor seinem
leisure=garden hatten.

War ihm nicht grün genug.

Das Argument ist im Grunde das Gleiche.

Manchmal würde ich die Mapnik-Karte am liebsten ganz abschalten...
;-)

Gruß, Wolfgang


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

Re: [Talk-de] Einladung und Call for Papers für die Kieler Open Source und Linux Tage

[Wolfgang Hinsch]

Hallo,

Am Dienstag, den 13.05.2014, 15:54 +0200 schrieb Michael Reichert:
 Hallo,
 
 das kam gerade bei uns vom Wochennotizteam. Wer möchte sicv drum kümmern.

ich habe einen OSM-Stand eingetragen.

Wiki-Seite: https://wiki.openstreetmap.org/wiki/KielerLinuxTage

Mitstreiter willkommen!

Gruß, Wolfgang


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

Re: [Talk-de] maxheight=none

[Wolfgang Hinsch]

Am Montag, den 31.03.2014, 09:58 +0200 schrieb Martin Koppenhoefer:
 Am 31. März 2014 09:50 schrieb Florian Lohoff f...@zz.de:
 
  Auf Straßen an denen keine Brücke drüber ist gehört IMHO nix dran.

 es sind nicht nur Brücken, die ggf. das zur Verfügung stehende
 Lichtraumprofil einschränken, z.B. Allee-Bäume, Straßenbahnoberleitungen
 und Beleuchtungskörper / Ampeln und Schilderbrücken können Hindernisse
 darstellen.
 

Es sollte eine Obergrenze geben für maxheight, z.B. 4,50.
Sondertransporte fahren sowieso nicht nach OSM, auch nicht nach
irgendwelchen anderen Quellen, sondern erkunden die Strecke zeitnah
selbst. Es gibt sonst zu viele Überraschungen durch provisorische
Brücken, Leitungsüberführungen etc. pp., wo der Transport hängen bleiben
könnte.

Übrigens sind Sondertransporte oft nicht nur extrem hoch, sondern auch
extrem breit oder lang. Für die Breite könnte man notfalls noch mappen,
aber wie wollen wir ermitteln, mit welcher Länge man da noch rumkommen
könnte bzw. welchen Balkon man abbauen müsste? ;-)

Gruß, Wolfgang


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

Re: [Talk-de] Noch eine Wappenkarte

[Wolfgang Hinsch]

Hallo Tim,

Am Samstag, den 29.03.2014, 15:05 +0100 schrieb Kolossos:
 Hallo, das Berliner Hackweekend hatte ich mal genutzt die Idee der
 Wappenkarte auf Wikidata-Basis aufzugreifen und in meine
 Koordinatenextraktion der Wikipedia zu integrieren:
 http://toolserver.org/~kolossos/openlayers/kml-on-ol.php?lang=deuselang=dezoom=6lat=50.08584lon=6.63143coats=yes
 
 Das sind jetzt 42.000 Wappen bei 3.5 Mio Artikeln, viel Spaß beim stöbern.

ich würde vorschlagen, dass ihr euch mal überlegt, wie man möglichst
einfach melden kann, dass man Fehler gefunden hat. Ich finde ca. alle 20
Sekunden einen falsch verlinkten Artikel.

Es müsste da eine einfache Möglichkeit geben anzuzeigen, dass das Objekt
hier nicht ist. Häufig kennt man das Objekt gar nicht und weiß nur,
dass es jedenfalls nicht an der eingetragenen Stelle sein kann. Also
eine Meldungsmöglichkeit ohne eine Master-Arbeit in Wiki-Web-Bearbeitung
und Registrierung hier/Registrierung da etc pp.

Etwa so wie die Notes auf OSM.

Gruß, Wolfgang


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

Re: [Talk-de] Postalische Bezeichnung (addr:place -)

[Wolfgang Hinsch]

Hallo Andreas,

Am Freitag, den 28.03.2014, 07:00 +0100 schrieb Andreas Neumann:
 Fehler beim Überprüfen der Signatur
 Fehler bei der Syntaxanalyse --ms010607030705050801080908
 Content-Type: text/plain; charset=ISO-8859-1
 Content-Transfer-Encoding: quoted-printable
 
 
 Fehler beim Überprüfen der Signatur
 Hash: SHA1
 gpg: ASCII-Hülle: 
 Version: GnuPG v1.4.14 (GNU/Linux)
 gpg: ASCII-Hülle: 
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
 gpg: ASCII-Hülle: 
 gpg: Ursprünglicher Dateiname=''
 gpg: Falsch aufgebaute Prüfsumme
 gpg: Keine Signatur gefunden
 gpg: quoted printable Zeichen in der ASCII-Hülle gefunden -
 möglicherweise
 war ein fehlerhafter Email-Transporter(MTA) die Ursache
 gpg: Die Signatur konnte nicht überprüft werden.
 Denken Sie daran, daß die Datei mit der Signatur (.sig oder .asc)
 als erste in der Kommandozeile stehen sollte.
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Einerseits w=E4re addr:place wohl das sinnvollere. Andererseits werten
 viele Programme nur addr:street aus und wie du es ausschreibst w=E4re
 es
 einer Stra=DFe gleichzusetzen.
 
 Jetzt ist die Frage, ob du es syntaktisch korrekt taggen willst oder
 f=FCr die Auswerter.
 
 MfG Andreas
 

so kommt deine Mail bei mir an.

(Evolution 3.2.3)

Gruß, Wolfgang


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

Re: [Talk-de] Visualisierung von (notwendigen) Postdienstleistungen

[Wolfgang Hinsch]

Hallo,

http://www.flosm.de/html/POI-Karte.html

zeigt auch Briefkästen und Postfilialen.

Gruß, Wolfgang




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

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

[Wolfgang Hinsch]

Am Dienstag, den 04.03.2014, 14:33 +0100 schrieb Martin Koppenhoefer:
 Am 4. März 2014 14:26 schrieb chris66 chris66...@gmx.de:
 
 
   Im Prinzip ja, leider sind die Multipolygon-Relationen vollkommen
   unberechenbar und interpretieren teilweise aus eigener Kraft, dass ein
   tag nicht sein soll wo es ist (z.B. wenn man ein Loch hat, welches die
  tags
   des Multipolygons hat, dann wird das als Loch gerendert und die tags des
   Objekts werden offenbar weggeworfen, Beispiel:
   http://www.openstreetmap.org/way/263521637 auch ein Hinzufügen von
   building:part=yes hat leider nichts geändert, es bleibt ein Loch im
   Rendering).
 
  Das ist nie und nimmer ein valides MP. :-)
 
  Wozu soll es überhaupt dienen, wenn das Gebäude keine Löcher hat?
 
 
 
 es sind mehrere Gebäude, die zu einem zusammenkleben bzw. wo eines von
 einem anderen umschlossen ist, unterschiedliche Stockwerkshöhen und ggf.
 Typologie etc., macht also durchaus Sinn, wenn man das aufteilt. Abgesehen
 von diesem Beispiel dürfte es auch noch andere Fäll geben, wo etwas um
 etwas gleiches (im Sinne von bestimmten OSM-tags) herum liegt, also ein
 Teil eingeschlossen ist, aber trotzdem nicht als Loch gerendert werden soll.
 

Also wenn ich das MP richtig verstanden habe, dann gibt es 2
Möglichkeiten: entweder mehrere Outer liegen nebeneinander, ohne sich zu
berühren, oder im Outer liegt ein Inner, dass dann ein Loch bildet. Erst
innerhalb des Lochs kann es wieder ein Outer geben, dass ein Loch im
Loch darstellt und damit wieder zur Fläche gehört.

Ein Outer direkt im Outer ist AFAIK ein Fehler, sowohl nach
OSM-Definition als auch nach postgis.

Gruß, Wolfgang


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

Re: [Talk-de] Ziele [war: Eintrag von Gewann-Namen]

[Wolfgang Hinsch]

Hallo Markus,

Am Freitag, den 28.02.2014, 11:59 +0100 schrieb Markus:
Manuelle Ergänzung
 Am Freitag, den 28.02.2014, 08:50 schrieb Michael Kugelmann:
 Am Freitag, den 28.02.2014, 00:08 schrieb Bernhard Weiskopf:
/Manuelle Ergänzung
 Hallo Bernd,
 
  Ich will für die Benutzer taggen
 
 :-) Das ist m.E. eine gute Einstellung.
 
 Bei allem was wir tun ist die Frage wichtig:
 - wozu?
 - wem nützt es?
 - wie kann ich es am besten umsetzen?

soweit +1

 
 Hallo Michael,
 
  wer sind die user
 
 Das ist eine wesentliche Frage.
 Nur so kann ich von ihnen erfahren, was sie gerne hätten,
 und mir dann überlegen, wie man das gut umsetzen könnte.
 
  Die richtige Denkweise wäre
 
 richtig gibt es immer nur in Bezug auf etwas.
 Für OSM ist der Bezug m.E. immer die Benutzer :-)
 
  OSM sammelt Geo-Daten welche die Wirklichkeit da draußen beschreiben.
 
 OSM ist eine *Weltkarte*.
 /Dafür/ werden Geo-Daten erhoben und in einer DB abgelegt.
 
 *Karte und Daten* ist eine systemische Einheit.
 Das erfordert eine gezielte Zusammenarbeit zwischen denen die Daten 
 sammeln und denen die sie anzeigen, bzw denen die die Karte nutzen :-)

Nein, genau das ist nicht so. Die osm.org (Mapnik-Karten) -
Darstellung ist /eine/ mögliche Interpretation der Daten, die noch dazu
eben /nicht/ ein Aushängeschild oder eine Marke darstellen soll.
Primärzweck ist, die Mapper, insbesondere Anfänger, zu motivieren und
eine großen Anteil von viel benutzen Tags anzuzeigen.

Es gibt noch einen ganzen Haufen anderer Karten. Letztens ist jede Karte
nur eine Auswahl der Daten, und jede Karte hat ihr eigenes Thema.
Deshalb sollten die Tags so genau und sinnvoll wie sachlich möglich
gesetzt werden - im Prinzip ohne Rücksicht auf die Mapnik-Karte.

Das heißt aber nicht, dass damit jetzt jeder seine Tags möglichst
individuell gestalten sollte. Sinnvoll ist natürlich, nach dem Wiki
vorzugehen, soweit die Tags für die Objekte sinnvoll und richtig sind.
Damit wird der größte Teil der Tags auch in der Mapnik-Karte dargestellt
werden. Sollte das aber nicht so sein, sollte - soweit sinnvoll - der
Stil der Karte und nicht das Mappen verändert werden.

 
  eine mögliche Benutzung dieser Daten ist das Rendering mit Mapnik
 
 Mapnik ist /die Karte/ :-)

Eben nicht.

 
 Selbstverständlich /kann/ man aus den Daten auch noch viele und tolle 
 Spezialanwendungen machen: Spezialkarten, Routing, Statistik, ...
 
 Und selbstverständlich brauchen Anwendungen sinnvolle Datenschemen als 
 Grundlage. Deshalb sind Daten(-Struktur) immer als Einheit mit der 
 geplanten Anwendung zu betrachten und zu verstehen - und zu entwickeln 
 und zu verbessern.
 
  Stil
 
 Ein einheitliches Erscheinungsbild hilft OSM als Marke zu etablieren.
 Dabei sind Ziele zu erfüllen wie schnelles Orientieren und Erkennen, 
 schnelles präzises Finden, sinnvolle Verknüpfung von Information, etc.
 Iterativ und gemeinsam ist das Optimum zu finden.
 
 Dabei kann man gute Fremd-Beispiele nutzen und die besten Ideen daraus 
 übernehmen.
 Es macht aber m.E. wenig Sinn, diese nur deshalb nachzuahmen, weil man 
 sie gewohnt ist.
 
 Bei den iterativen Suchprozessen macht es auch Sinn, immer mal wieder 
 etwas ganz anderes auszuprobieren - um die gefundenen Essenzen dann 
 synergetisch in das Produkt zu integrieren.
 Es macht aber m.E. wenig Sinn, viele Skins zu haben.

Ich glaube, du denkst jetzt zu sehr an den Namen OpenStreetMap. Damit
hat es zwar angefangen, aber der Name trifft heute nicht mehr zu.
Eigentlich müsste das ganze Ding jetzt OpenGeoBase heißen, nur ist der
Name nachträglich kaum noch zu ändern.

Will sagen: Wir machen überhaupt keine Karten. Wir machen /nur/ eine
Datenbank. Unsere Karten sind lediglich Beispiele und
Motivationselemente, sonst nichts. Interpretieren kann das jeder, wie er
will und in welchem Stil er Lust hat. Insofern sind unterschiedliche
Skins selbstverständlich.

Sinnvolles Taggen im Stile des Wiki, wenn es passt, ja.

Uminterpretieren, verbiegen, absichtliche Unschärfen, nicht so ganz
passende Tags nehmen, damit etwas dargestellt wird = Taggen für einen
bestimmten Stil eines einzelnen Renderers = Wertlosigkeit der Daten für
andere Anwendungen und keinerlei Weiterentwicklung = nein.

Aus Prinzip andere Tags benutzen, obwohl es geeignete gibt = taggen
gegen den Renderer = auch nein.

 
 - - - -
 
 Zur Frage nach dem Rendering von Gewann-Namen:
 Namen von Gegenden helfen bei der Orientierung.
 Solche Namen auf der Karte zu haben ist ein sinnvolles Anliegen.

Richtig, aber Aufgabe der Renderer = Stil anpassen.
 
 Solange wir dafür kein brauchbares Konzept haben, werden Benutzer immer 
 wieder versuchen, die Namen irgendwie so in die DB zu schreiben 
 /damit/ sie gerendert werden.

Dann werden die entweder korrigiert oder gelöscht.

Gruß, Wolfgang


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

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

[Wolfgang Hinsch]

Am Freitag, den 28.02.2014, 14:27 +0100 schrieb Martin Koppenhoefer:

 s.o., die Schneisen sind auch Teil des Käfertaler Walds (obwohl nicht
 landuse=forest).

Das ist wieder so eine Sache der Definition. Ich würde dazu tendieren,
die Schneise als funktionales Sicherheits-Element des Waldes zu sehen
und damit im landuse=forest einzuschließen. Der Notausgang im Supermarkt
würde auch als Element des Supermarktes bezeichnet werden, obwohl man
auf dem Weg nichts einkaufen kann. Als Verkaufsfläche dagegen fiele er
raus. 

Wenn man zusätzlich landcover=forest mappt, bin ich aber bei dir, die
Schneise nicht im landcover zu lassen.

Gruß, Wolfgang


___
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

[Wolfgang Hinsch]

Am Freitag, den 28.02.2014, 15:46 +0100 schrieb bkmap:
 Die Auswerter sehen aber keinen Unterschied, es sei denn, der Tag ist an
 eine Fläche gebunden. Dann könnte man Rückschlüsse aus der Größe ziehen.
 

+1

Insofern kann es sinnvoll sein, Gebiete mit einheitlichem Namen als
Polygone oder bei großen Gebieten wie dem Schwarzwald als Multipolygone
zur Namenskennzeichnung zu mappen. Das MP kann ja aus bereits
vorhandenen Polygonen zusammengesetzt werden. Dann kann der Renderer
erkennen, in welches Gebiet der Namen gehört und entscheiden, wie
prominent und auseinander gezogen er dargestellt werden soll.

Das ist nicht nur für den Renderer, sondern für jede Auswertung
sinnvoll, die sich mit irgendwelchen Regionalbegriffen, die nicht mit
Verwaltungseinheiten identisch sind, auseinander setzt.

Gruß, Wolfgang


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

Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?

[Wolfgang Hinsch]

Am Freitag, den 28.02.2014, 16:34 +0100 schrieb Martin Koppenhoefer:
 
  Am 28/feb/2014 um 16:00 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
  
  Das ist wieder so eine Sache der Definition. Ich würde dazu tendieren,
  die Schneise als funktionales Sicherheits-Element des Waldes zu sehen
  und damit im landuse=forest einzuschließen. Der Notausgang im Supermarkt
  würde auch als Element des Supermarktes bezeichnet werden, obwohl man
  auf dem Weg nichts einkaufen kann. Als Verkaufsfläche dagegen fiele er
  raus. 
 
 
 Für mich wie im Wiki beschreibt Landuse die tatsächliche Bodennutzung. 
 Vielleicht kann man bei der Schneise noch diskutieren, aber nimm mal 
 Freudenstadt (im Schwarzwald). da passt landuse Forest sicher nicht. Liegt 
 aber im Schwarzwald. Ich würde daher eher einen neuen Key für Gebiete 
 vorschlagen, sowas wie georegion=forest
 name=*

Bei Elementen, die nichts mit dem Wald zu tun haben, sind wir uns einig.
 
 oder evtl. auch location anstatt georegion od. toponym od. natural 
 oder...
 
 Multipolygonrelation ist bei so großen Gebieten allerdings problematisch aus 
 div. Gründen, zB Auffinden, dann fehleranfälligkeit (nur ein Loch macht sie 
 schon ungültig) und die schiere Anzahl an members (OK, könnte man 
 verschachteln), etc
 
 Gelegentlich kam hier schon ein neuer Relationstyp ins Spiel, ein Gebiet zu 
 definieren über einen Haufen von quasi zufälligen Objekten, die noch drin 
 liegen (oder evtl auch role für nicht mehr drin), woraus man dann später ein 
 ungefähres Gebiet errechnen kann.

Man könnte vielleicht so eine Art Tangentenpolygon erfinden. Eine
Figur, die aus Polygonen, einfachen Ways und Punkten besteht. Sie wird
dadurch definiert, dass man eine Linie berechnet, die als Tangente um
alle Elemente außen herumläuft. Außen wird definiert als die andere
Seite der Elemente gegenüber dem geografischen Mittelpunkt.

Bei Polygonen und Wegen wird die Figur berechnet, indem zwischen 2
Elementen immer eine Linie genutzt wird, die die kürzeste Strecke
beschreibt, die 2 Punkte der beiden Elemente verbindet, die aber keine
Linie der Elemente schneidet (außen anliegt). Bei Punkten geht die
Figur genau durch den Punkt. Die Reihenfolge ist von Bedeutung.

Das hat den Vorteil, dass ein Gebiet wie z.B. die Alpen beschrieben
werden kann, ohne einen Riesenhaufen von verschachtelten Multipolygonen
zu erzeugen. Es werden nur ein paar signifikante Elemente benutzt, die
am Rand liegen. 

Für die Alpen könnte das z.B. ein Tangentenpolygon aus 

Nizza - Turin - Como - Verona - Belluno - Llubljana - Wien - Salzburg -
Bregenz - Luzern - Genf - Genoble - Nizza

sein (Vorsicht, nur als Beispiel und GANZ grob). Wobei ich festgestellt
habe, dass es sinnvoll sein könnte, mit outer und inner zu arbeiten,
wobei die Tangente außen am inner vorbeiläuft, es also dazugehört, und
innen am outer, es also ausschließt. 

Damit sollten große Gebiete ohne all zu viel zusätzliche Daten erfassbar
sein. So 100% trennscharf ist so eine Linie ohnehin nicht.

Nur so eine Idee...

Gruß, Wolfgang


___
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

[Wolfgang Hinsch]

Am Freitag, den 28.02.2014, 17:35 +0100 schrieb Bernhard Weiskopf:
 Namen für Gebiete an eine Fläche binden halte ich für absolut notwendig. 
 
 Schließlich soll der Goetheplatz nur in den großen Zoomstufen angezeigt
 werden, der Schwarzwald dagegen nur in mittleren, aber nicht mehr in
 großen. Je nach Flächeninhalt muss man minimale und maximale Zoomstufe für
 das Anzeigen festlegen. (Wenn wir eines Tages bis Zoom = 25 kommen, soll
 Goetheplatz auch nicht mehr angezeigt werden.) 
 
 Das müsste so ähnlich auch bereits mit anderen Objekten, wie Ländernamen,
 Städtenamen usw. umgesetzt sein.

Jetzt vermischst du wieder die Teilnehmer. Der Mapper legt nur fest, was
zum Schwarzwald und was zum Götheplatz gehört.

In welcher Zoomstufe welcher Renderer was anzeigt, muss er - und nur er
- selbst entscheiden. Wenn ich eine Karte von X-Dorf mache und das
mitten im Schwarzwald liegt, würde ich Schwarzwald nicht mehr rendern,
sondern auf den Kartentitel schreiben: X-Dorf im Schwarzwald.

Wenn das Dorf aber am Rande des Schwarzwaldes liegt, und der Schwarzwald
die linke Kartenhälfte ausmacht, würde der Begriff gerendert, unabhängig
vom Maßstab oder Zoomlevel.

Versuche doch einmal, eine Karte selbst zu machen. Beschäftige dich z.B.
mit Maperitive. Dann kannst du auch selbst festlegen, welche Bezeichnung
wo zu stehen hat. Kann ja erst mal der Ortsplan von X-Dorf sein ;-)

Gruß, Wolfgang


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

Re: [Talk-de] Planetarium

[Wolfgang Hinsch]

Am Sonntag, den 23.02.2014, 21:47 +0100 schrieb Johannes:
 Bisher klingt es so als ob alle mit amenity=planetarium zufrieden wären.
 Bisher gibt es also keinen richtigen Konsens für einen solchen Tag.
 Sollte man dafür ein Proposal schreiben? Hat das schon mal jemand
 gemacht, bzw. möchte das jemand freiwillig machen?

Wie richtig willst du denn den Konsens? Eine kurze Frage noch auf
tagging, und dann ab damit ins Wiki, falls keine Proteste kommen.

Für ein einzelnes Tag, für das eine Lösung gefunden wurde, mit der alle
leben können, sollte man den Aufwand nicht übertreiben. Die 5-10
Stimmen, die da noch kommen könnten, fallen bei 1,5 Mio registrierten
Usern nicht wirklich ins Gewicht. Falls das Tag später sich doch noch
ändern sollte, kann man die paar Planetarien notfalls umtaggen.

Wenn über jedes einzelne Tag monatelang diskutiert und abgestimmt wird,
hat Tante G den letzten Wanderpfad Jahrzehnte vor uns erfasst.

Gruß, Wolfgang


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

Re: [Talk-de] Planetarium

[Wolfgang Hinsch]

Am Montag, den 24.02.2014, 13:10 +0100 schrieb Johannes:
 Wenn das bei einem einzelnem Tag nicht üblich ist und man
 anderssprachige nicht fragen braucht, ist's ja in Ordnung.

Die anderssprachigen erreichst du auf Tagging. Englisch zu fragen,
reicht. Wir können ja nicht alle Sprachen abklappern ;-)

Gruß, Wolfgang



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

Re: [Talk-de] Planetarium

[Wolfgang Hinsch]

Am Sonntag, den 23.02.2014, 12:27 +0100 schrieb Martin Koppenhoefer:
 
  Am 23/feb/2014 um 12:14 schrieb Johannes jotpe@gmail.com:
  
  Wenn man sich nicht einig
  werden kann, ob ein Planetarium ein Theater oder ein Museum ist, dann
  scheint amenity=planetarium oder man_made=planetarium eine der besseren
  Ideen zu sein.
 
 
 +1, Kino hat ja auch einen eigenen Tag und wird nicht als Theater getaggt, 
 Museum ist es sicher nicht.

Und ich sehe es immer noch als technisches Museum  ;-)

+1 für amenity=planetarium auch von mir.

Gruß, Wolfgang


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

Re: [Talk-de] Planetarium

[Wolfgang Hinsch]

Am Samstag, den 22.02.2014, 21:07 +0100 schrieb Martin Koppenhoefer:
 Am 22. Februar 2014 20:42 schrieb Johannes jotpe@gmail.com:
 
  Ein Vorschlag von mir:
  tourism=museum
  und
  museum=planetarium
 
  museum als key gibt es ca 160 mal. planetarium ist unter den values
  noch nicht zu finden, dafür aber genauere Infos über das Museum, wie
  railway oder art. Passt also vom Schema gut rein.
 
 
 
 ich finde nicht, dass Planetarium ins Museums-schema passt. Typologisch ist
 das noch eher ein Kino oder gar ein Theater, als ein Museum, ich würde aber
 für einen dedizierten tag plädieren.
 
 -1

tourism=museum
museum=planetarium

passt voll ins Museum. Theater dagegen überhaupt nicht. Planetarium ist
ein technisches Museum, in dem ganz überwiegend der Stand des Wissens
von kosmischen Zusammenhängen visualisiert wird.

Ich sehe da Parallelen z.B. zum Deutschen Museum in München. Sonst
müssten alle Museen mit Technik und/oder Multimedia eine andere
Kategorie bekommen.

Ein Museum muss nicht zwangsläufig eine Staubsammlung sein ;-)


Ein Theater oder Kino dagegen zeigt Unterhaltung, die ganz überwiegend
auf Phantasie beruht. 

Gruß, Wolfgang


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

Re: [Talk-de] D-A-CH

[Wolfgang Hinsch]

Hallo,

Am Donnerstag, den 20.02.2014, 19:55 +0100 schrieb Caronna:
 Am 20.02.2014 17:04, schrieb Frederik Ramm:
  Hi,
 
  für den rein hypothetischen Fall ;) dass ich auf
  download.geofabrik.de auch ein File D-A-CH anbieten würde, statt nur
  entweder die Länder einzeln oder ganz Europa - würde man dann auch noch
  Südtirol mit dazu nehmen, oder eher nicht?
 
 
 D-A-CH... wieso nur diese Kombination (halt mich schon immer bei Navis 
 geärgert) Ich brauchte D + BeNeLux, andere hätten wohl gerne Dänemark 
 dabei, Polen oder die Tschechen.
 

+1

Wie das so ist, wenn man etwas anbietet...
;-)


Schön wäre es, wenn man die runtergeladenen Dateien mit einem Script
zusammenlesen könnte. Dann lädt man einfach benachbarte Files zusammen
und kann seine Kombination selbst bestimmen.

Gruß, Wolfgang


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

Re: [Talk-de] Hack-weekend in Berlin nach der Fossgis

[Wolfgang Hinsch]

Hi Kolossos,

manche Dinge sind so wichtig, die kann man gar nicht oft genug sagen ;-)

Gruß, Wolfgang

Am Donnerstag, den 13.02.2014, 19:08 +0100 schrieb Kolossos:
 Am 22.-23. März wird es im Anschluss an die Fossgis-Konferenz ein
 Hack-weekend geben:
 http://wiki.openstreetmap.org/wiki/Berlin_Hack_Weekend_März_2014
 



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

Re: [Talk-de] Vertikale/horizontale Linienbündel

[Wolfgang Hinsch]

Am Dienstag, den 11.02.2014, 21:47 +0100 schrieb r...@gmx.de:
 Liebe Tagger(innen) und Mapper(außen?),
 
 ich beginne mit dem Fall eines vertikalen Linienbündels,
 d.h. mit mehrstöckigen Wegen: Unten (layer=-1) verläuft
 vielleicht ein Kanal, darüber (layer=0) eine Straße und
 eine Bahnlinie (layer=1).
 
 Ansatzweise gibt es so etwas bei der Minderener Str. in
 Bielefeld http://www.openstreetmap.org/way/48403389
 - aber sicher gibt es bessere Beispiele in Japan.
 
 Wenn die Wege wirklich für längere Zeit exakt
 übereinander verlaufen, wie ist das sinnvoll zu mappen?
 
 Macht es Sinn, dafür eine Relation vbundle zu ersinnen?
 Damit könnte man zwar (zusätzlich zum layer) eine Lagebeziehung
 (über/unter) zwischen den einzelnen Strängen herstellen,
 müsste aber jeweils einen eigenen Streckenzug (way) erstellen.
 Bei Verfeinerungen ist so etwas anfällig. Das Rendern
 ist ohnehin problematisch.

Ich würde den Bündel/Relationsansatz ganz schnell wieder vergessen. Für
jede Etage/Höhenlage einen Layer vergeben und den Filter von JOSM
benutzen. Damit kann man jederzeit einstellen, dass man nur die Objekte
von Layer xx sehen will 
(Filter hinzufügen
 Layer=3
 Filter invertieren)

Ob das Ganze überhaupt sinnvoll ist, wie man es auswertet und was
Renderer anzeigen sollen, ist eine andere Frage.

Gruß, Wolfgang



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

Re: [Talk-de] Luftbild-Versatz - Schachtdeckel

[Wolfgang Hinsch]

Moin,

Am Montag, den 10.02.2014, 19:28 +0100 schrieb Markus:
 N'Abend Dirk,
 
  User A ist sich sicher
  Was genau bedeutet sicher?
 
  Vermutlich „Der User Stand mit perfektem GPX-Fix auf seinem Gerät direkt
  drauf“ :)
 
 *lach* - und was bedeutetperfekt? ;-)

Mal zur Info: In Lübeck sind wir im Besitz der Koordinaten nahezu
sämtlicher Schachtdeckel der Stadt. Die hat ein User genau zu dem Zweck
der Georeferenzierung für alle hochgeladen. Das war vielleicht nicht so
super geschickt, weil es eine 5-stellige Anzahl war, aber die Absicht
war genau dieselbe wie eure.

Derjenige ist an den Marterpfahl gebunden und gesteinigt und geteert und
gefedert worden. Der macht das bestimmt nicht wieder.

Die Punkte wurden gelöscht. Ganz böser Fall von unerlaubtem Import.

Jetzt kann eine handverlesene Anzahl von Mappern in Lübeck Luftbilder
georeferenzieren...

Und nein, ich war es nicht ;-)

Gruß, Wolfgang


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

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

[Wolfgang Hinsch]

Am Mittwoch, den 05.02.2014, 12:20 +0100 schrieb Tobias Knerr:
 Am 05.02.2014 11:10, schrieb Falk Zscheile:
  Aus Sicht von jemanden der on the ground
  mappt gibt es die schon. Darum dreht sich ja der Thread mittlerweile.
 
 Ich finde, die on the ground-Regel wird in dieser Diskussion arg
 überstrapaziert. Nach meinem Verständnis sagt diese Konvention, dass die
 Situation on the ground als Quelle dienen soll. Darauf wendet man dann
 die Taggingregeln an: Beispielsweise, dass Anlieger frei mit dem Wert
 destination gemappt wird, obwohl das nicht wortwörtlich auf dem Schild
 steht. Und eben, dass Abkürzungen ausgeschrieben werden, obwohl das
 nicht wortwörtlich auf dem Schild steht.
 
 Daher sehe ich keinen Widerspruch zwischen der on the ground-Regel und
 der Ausschreiben-Regel. Der entsteht nur dann, wenn man vergisst, dass
 es zwischen der Quelle (d.h. bevorzugt der Realität) und den Tags immer
 einen Übersetzungsschritt gibt.

+1

Gruß, Wolfgang


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

Re: [Talk-de] Luftbild-Versatz

[Wolfgang Hinsch]

Am Montag, den 03.02.2014, 08:05 +0100 schrieb Ronnie Soak:
 Meine Aussage sollte sein: Die Flugplätze bekommt man damit vielleicht sehr
 genau, alles andere ist zu weit weg als dass
 
  die Flugplatzkoordinaten was verbessern könnten...
 
 
 Irgend jemand hatte von einer Stadt doch mal die exakten Koordinaten der
 Gullideckel.
 DAS wäre eine Referenznetz, das dicht genug für eine Luftbildkorrektur
 wäre.
 
 Gibt's wahrscheinlich nur nicht überall.
 

Und beim Hochladen wird auf denjenigen eingeprügelt...

Gruß, Wolfgang


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

Re: [Talk-de] Luftbild-Versatz

[Wolfgang Hinsch]

Am Montag, den 27.01.2014, 20:20 +0100 schrieb Andre Hinrichs:

 Einem einzelnen GPS-Track kann man nicht vertrauen, ob nun aus
 Gründerzeiten oder neuerdings. Daher versuche ich stets Straßen zum
 Ausrichten zu verwenden, wo bereits mehrere Tracks aufgenommen wurden.
 
 Das Problem mit den Häuserschluchten besteht ja im Wesentlichen in den
 großen Städten. Dort findet man jedoch auch häufig vielbefahrene
 Hauptstraßen, an denen man das dann ausrichten kann. Der Versatz der 200
 Meter entfernt liegenden Nebenstraße, die in einer Häuserschlucht
 verläuft, sollte davon nicht wesentlich abweichen. Man kann also die
 dortigen ungenauen Tracks ignorieren.

Das ist aber sehr von den Bing-Bildern abhängig. In HH musst du jede
Kreuzung einzeln positionieren. Da geht es munter 5m nach links, 4m nach
vorn... . Die Bing-Bilder werden nur noch benutzt, weil die Auflösung
besser ist als bei den Bildern des Vermessungsamtes.

Gruß, Wolfgang



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

Re: [Talk-de] Vortrag von Jochen Topf zum OSM-Datenmodell in Hamburg

[Wolfgang Hinsch]

Am Freitag, den 17.01.2014, 10:42 +0100 schrieb Jochen Topf:

 Das tut mir leid. Die HafenCity ist da nur in provisorischen Räumlichkeiten 
 und
 deshalb ist da nichts richtig ausgeschildert. Ich habs auch nicht gleich
 gefunden...

Ja, provisorisch wirkt das wirklich. Die Räumlichkeiten hat die jetzige
HCU allerdings seit mindestens Mitte der 70er Jahre, als sie noch
Fachhochschule für Vermessung, Bauing-Wesen und Architektur hieß. Da
wäre genug Zeit für eine Ausschilderung gewesen...

War trotz der innovativen Beleuchtungseffekte ;) ein interessanter
Vortrag und ein netter Abend.

Vielleicht kannst du, falls der Ton nicht klappen sollte, die Folien
irgendwo hochladen?

Gruß, Wolfgang



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

Re: [Talk-de] OSBs schliessen ohne Kommentar und Username

[Wolfgang Hinsch]

Am Sonntag, den 12.01.2014, 18:56 +0100 schrieb Werner Hoch:
 Am Sonntag, den 12.01.2014, 12:31 +0100 schrieb Florian Lohoff:
  ich sehe hier seit 3 Tagen das irgendjemand einfach ohne irgendwas zu
  machen OSB Bugs schliesst. Die Bugs gehen ohne Username und Ohne
  Kommentar einfach zu. Mittlerweile sind 30 Bugs von mir im Umkreis
  Guetersloh/Rheda-Wiedenbrück geschlossen worde.
  
[...]
  1. Es geht nicht drum die OSB Bugs so schnell es geht einfach
 zuzumachen, das geht schneller - einfach ein drop all tables in
 der Datenbank.
  2. Wenn man Bugs schliesst bitte mit Kommentar was geaendert worden ist
 und vor allem mit Namen. So kann ich denjenigen nichtmal per
 Nachricht wüst beschimpfen was das soll.
 
 Ich habe eine Empfehlung ergänzt, wie bugs geschlossen werden sollen:
 https://wiki.openstreetmap.org/wiki/OpenStreetBugs/Phase_Out#General_hints
 
  Ich würde ja neue Bugs aufmachen in dem Gebiet und denjenigen Wüst
  beschimpfen aber das geht ja bei OSB nicht mehr weil ja voreilig
  das neu eröffnen abgeschaltet worden ist.
 
[...]
 Du nennst es voreilig. Konstruktive Vorschläge für die schrittweise
 Abschaltung sind willkommen. Welcher Zeitraum wäre für dich sinnvoll
 gewesen, in welchen Schritten?

Worin bestand eigentlich das Problem, die bisherigen OSB-Einträge in die
Notes zu übernehmen und dann OSB abzuschalten? Der Aufwand, die OSBs
manuell zu überprüfen und ggf. zu übertragen dürfte in jedem Fall
wesentlich größer sein.

Gruß, Wolfgang




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

Re: [Talk-de] Auto versus PKW im deutschen StVR - war: Parkplatz nur für PKW

[Wolfgang Hinsch]

Hallo

Am Donnerstag, den 09.01.2014, 10:06 +0100 schrieb Ronnie Soak:
 
   Natürlich sinf die boat=no and motor_boat=no an jede
   Strasse taggende darüber unglücklich.
  
 
 
  Macht keine Witze. Ich hatte schon motor_vehicle=no, snowmobile= no an
 innerstädtischen (mitteldeutschen) Servicewegen aufzuräumen.
 Keine Ahnung welches intuitive Template dabei geholfen hat.
 

Man könnte das tagging vereinfachen und die Auswerung trotzdem
komfortabel halten, wenn man ein paar einfache Regeln aufstellt:

1. Ohne Access-Tag ist ein Weg für alles zulässig, was da drauf kann und
generell auf einen solchen Weg darf.

2. Ist ein Weg nur für eine oder wenige Gruppen zulässig, werden die
Gruppen erwähnt. Damit sind alle nicht erwähnten ausgeschlossen.
Beispiel Busspur: psv=yes, das impliziert dann ein Verbot für alle
anderen.

3. Ist ein Weg nur für eine oder wenige Gruppen verboten, werden die
Gruppen genauso erwähnt, aber mit no. Das erlaubt alle davon nicht
betroffenen Gruppen. Beispiel für Gefahrgüterverbot: hazmat=no

Zu überlegen wäre, ob nicht grundsätzlich immer ein access: vorgesetzt
werden soll. Das erleichtert die Erkennung.

access:psv=yes
bzw.
access:hazmat=no

Ansonsten kann das access-Schema genauso benutzt werden. Nur das
vorherige access=no entfällt (es sei denn, es ist wirklich für alle
verboten).

Gruß, Wolfgang


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

Re: [Talk-de] Parkplatz nur für PKW

[Wolfgang Hinsch]

 Man kann auch in Frage stellen, ob denn das hierarchische Modell hinter 
 den Zugangstags nicht vielleicht einfach zu kompliziert ist...
 Vom Gefühl gilt für mich auch eher:
 motor_vehicle=no = motorcar=no v motorcycle=no v hgv=no v bus=no v ... 
   (äquivalentes entsprechend bei yes oder designated).

Ich sehe das eher als Werkzeug-Problem. Sobald die Editoren dafür eine
Funktion anbieten, läuft es.

Gruß, Wolfgang


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

Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)

[Wolfgang Hinsch]

Am Freitag, den 03.01.2014, 12:29 +0100 schrieb Peter Wendorff:
 Hallo Stefan,
 leider beschränkt sich das ja nicht nur auf Kreuzungen: Mittelinseln an
 Fußgängerüberwegen, Bushaltestellen mit deutlichen Buchten, Taxistände,
 Parkhausein-/ausfahrten oder auch nur die Frage, wonach Straßen in
 Fahrbahn-Ways aufgetrennt werden (bauliche Trennung, juristisch bauliche
 Trennung und damit auch durchgezogene Doppellinie,

Das Ding ist nicht tot zu kriegen :-(

Wir haben das vor ca einem 3/4 Jahr hier schon mal durchgekaut.

Juristisch ist eine durchgezogene Doppellinie zwei gemalte Linien zwei
Striche auf der Straße eine Fahrstreifentrennung für den Gegenverkehr
und keine, gar keine, überhaupt keine, in keinster Weise eine bauliche
Maßnahme, Trennung oder sonst was und auch nie nicht niemals sowas
gewesen! 

Das einzige was für Mapper schwer verständlich zu sein scheint, ist der
Gesetzestext.

- Diese Geschwindigkeitsbeschränkung gilt nicht auf Autobahnen
(Zeichen 330.1) sowie auf anderen Straßen mit Fahrbahnen für eine
Richtung, die durch Mittelstreifen oder sonstige bauliche Einrichtungen
getrennt sind.
- Sie gilt ferner nicht auf Straßen, die mindestens zwei durch
Fahrstreifenbegrenzung (Zeichen 295) oder durch Leitlinien (Zeichen 340)
markierte Fahrstreifen für jede Richtung haben.
(§ 3 Abs. 3 c StVO)

Ferner dazu der Satz mit der Doppellinie aus der Anlage zu § 41 Abs. 1
Vorschriftszeichen, Laufende Nummer 68, Erläuterung Nr. 1 StVO
- Die Fahrstreifenbegrenzung kann zur Abtrennung des Gegenverkehrs aus
einer Doppellinie bestehen.

Erläuterung 2 sagt, dass _seitlich_ die Fahrbahn durch eine
Seitenbegrenzungslinie gegen Seitenstreifen oder Sonderwege abgegrenzt
werden kann, das aber nicht als Doppellinie.

Will heißen: Baulich getrennt im ersten Satz (Diese...), wenn
_baulich_ getrennt.
Baulich nicht getrennt im zweiten Satz (Sie gilt ferner...), wenn
_baulich_ nicht getrennt, sondern gemalt. Die zwei bezieht sich auf
die Anzahl der Fahrstreifen (Spuren) pro Richtung und nicht auf die
Anzahl der Striche. Man achte auf die Bezeichnung Fahrstreifen, nicht
Fahrbahnen. Außerdem jede Richtung. Gemeint ist eine Straße
allgemein genannt mindestens 4-spurig. Dort, und nur dort, darf man
außerorts schneller als 100 km/h fahren, wenn nichts dran steht. Egal,
ob in der Mitte ein Strich, 2 Striche, 20 Striche, eine Rasenfläche,
eine Weide mit Kuh, ein Mittelstreifen oder sonstwas ist, wobei für die
Striche der 2. Satz, für Mittelstreifen mit/ohne Weide und Kuh der erste
Satz gilt.

Merke: Hast du in der Mitte 2 Striche, aber für mindestens eine
Fahrtrichtung nur eine Fahrspur, solltest du im Interesse deines
Lappens nicht wesentlich schneller als mit 100 km/h unterwegs sein.
Wenn nichts dransteht.

seufz

Gruß, Wolfgang 




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

Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)

[Wolfgang Hinsch]

Hallo Peter

Am Freitag, den 03.01.2014, 16:59 +0100 schrieb Peter Wendorff:
 Hallo Wolfgang,
 ich wollte das gar nicht wieder aufkochen, sondern nur anmerken, dass
 die Ansichten, wann in OSM der Weg jetzt geteilt wird und wann nicht,
 deutlich auseinandergehen.
 Die Frage ist/wäre nämlich unabhängig von den daraus gezogenen
 Implikationen, denn zwei oneway-ways in OSM lassen noch absolut nicht
 auf irgendeine Höchstgeschwindigkeit schließen, wenn diese nicht
 explizit angegeben ist.
 

Ich wollte hier nur neue Missverständnisse vermeiden.

Übrigens hatten wir eine Einigung: Nur die bauliche Trennung zählt.

Gruß, Wolfgang


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

Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)

[Wolfgang Hinsch]

Hallo,

Am Freitag, den 03.01.2014, 18:08 +0100 schrieb chris66:
 Am 03.01.2014 17:29, schrieb Florian Lohoff:
 
  Was AFAIK fehlt ist ein tag um anzudeuten das zwischen den lanes:forward
  und lanes:backward eine durchgezogene line bzw bauliche trennung
  gibt d.h. ein kreuzen oder wenden nicht moeglich ist.
  
  Flo
 
 Da hilft evntl.
 
 change:lanes:forward=not_left|yes (Beispiel)
 
 weiter.

http://wiki.openstreetmap.org/wiki/Proposed_features/lanes_General_Extension

http://wiki.openstreetmap.org/wiki/Key:change:lanes

Tipp: lanes immer mit forward/backward taggen.

Zur Anzeige von gemappten Fahrspuren gibt es mehrere JOSM-Stile.

Gruß, Wolfgang


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

Re: [Talk-de] [OT] Etrex 30: Sekundengenaue Uhrzeit abfotografieren?

[Wolfgang Hinsch]

Hallo,

Am Dienstag, den 31.12.2013, 14:39 +0100 schrieb Andreas Tille:

 
 Hmmm, bei mir (also in Werkseinstellungen) ist da die Zeit bis
 Sonnenuntergang.  Eine nette Information, die aber eigentlich kein
 Mensch so richtig braucht.  Was bei Dir steht, klingt viel
 interessanter - leider habe ich noch nicht raus, wie ich das ändern
 kann.

Ab Sonnenuntergang muss auf Sportbooten (und nicht nur diesen) die
Positionsbeleuchtung eingeschaltet sein, egal wie hell es zu dem
Zeitpunkt noch sein sollte.

Gruß, Wolfgang


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

Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)

[Wolfgang Hinsch]

Am Dienstag, den 24.12.2013, 10:50 +0100 schrieb Peter Wendorff:
 Am 23.12.2013 07:12, schrieb Wolfgang Hinsch:

  Im Busbahnhof muss die Relation ggf. aufgesplittet werden in mehrere
  Äste. Ähnliches gilt, wenn ein Bus zum Anfahren eines Zwischenziels
  denselben Weg hin- und wieder zurückfährt. Dann muss die Route auf
  mehrere Äste verteilt werden, weil ein way nur einmal in der Relation
  vorhanden sein darf.
 Wer hat dir den den Blödsinn erzählt?
 Natürlich kann ein Weg mehrfach vorhanden sein, insbesondere, aber rein
 technisch gesehen nicht darauf beschränkt, wenn unterschiedliche Rollen
 (z.B. forward/backward) genutzt werden.
 Hab ich mehrfach so gesehen und auch mehrfach selbst so gempapped;
 beschwert hat sich bisher niemand.

Glückwunsch! JOSM reagiert mit einer Fehlermeldung. Ob das Ganze dann
heil in der DB ankommt, möchte ich nicht ausprobieren. Der Vorteil der
neuen Relationen ist ja gerade, dass es eine Relation für eine Strecke
gibt. Daduch kann man die Relation mit der Sort-Funktion sortieren und
ggf. auf die Lücken springen, um sie zu reparieren. Wenn da jetzt wieder
Verzweigungen und mehrfache Wege reinkommen, ist der Vorteil dahin. Dann
hätten wir die alten Relationen lassen können.

 
  Die neuen Bus-Relationen haben lt. Wiki gar keine Role. Da die
  Relationen jeweils einen Weg in einer Richtung beschreiben, kann dieser
  Weg durch eine Kette von Anfangs-/Endpunkten bestimmt und auch berechnet
  werden. Auch deshalb darf es innerhalb derselben Route-Relation keine
  Verzweigungen geben.
 Wenn das so wäre, wär das neue Schema unbrauchbar, denn dass Busse,
 Bahnen, Straßenbahnen etc. Teilstrecken mehrfach befahren ist durchaus
 die Regel.

Die werden als eigene Relationen innerhalb der Route-Master-Relation
eingetragen. Das finde ich auch sinnvoll, denn man muss nicht mehr diese
Spaghetti-Relationen verfolgen. Probleme entstehen, wenn da jetzt wieder
Verzweigungen auftauchen.

Gruß, Wolfgang



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

Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)

[Wolfgang Hinsch]

Am Sonntag, den 22.12.2013, 12:58 +0100 schrieb Florian Lohoff:
 On Sat, Dec 21, 2013 at 12:24:04PM -0800, mmd wrote:
  
  Ich hatte damals an eine reine Web-Anwendung gedacht, mit der man neben
  neuen Relationen auch existierende Relationen einfach durch Drag-und-Drop
  anpassen kann. Also genau so, wie man heute auf osrm.at eine Route mit
  Start/Ziel und Zwischenpunkten zusammenbaut. Passt das Ergebnis, sollte
  automatisch die Relation in der OSM-DB aktualisiert werden können. Alle
  Split-Operationen (die Du wie geschrieben in JOSM händisch machen würdest)
  würden dann automatisch im Hintergrund erfolgen.
  
 
 Ich warne davor das Automatisch zu machen. Das wird diskussionen geben
 ohne ende ob denn das sein muss und jeder kleine fehler würde
 aufgebauscht werden so wie bei allen automatischen aenderungen oder den
 imports.
 
+1

Die Idee klingt zunächst bestechend. Das Problem ist einmal der
berechnete Weg, der Ungenauigkeiten enthalten kann. Das größere Problem
sehe ich in der mangelnden Aktualität. Die Editoren arbeiten immer mit
topaktuellen Daten, die Router hängen ein paar Tage hinterher. Wenn ich
eine Kreuzung umbaue und anschließend die Routen in Ordnung bringen
will, nützt mir das wenig.

Andererseits halte ich es für unsinnig, das Routing im Editor einbauen
zu wollen, denn dann müsste eine viel zu große Datenmenge herunter
geladen werden.

Für den besseren Weg halte ich eine Weiterentwicklung der
Routeneditoren. Im Josm läuft das bei Busrouten schon recht gut.

Dazu würde ich vorschlagen, immer für den ersten Wegeabschnitt jeder
Busroute eine Role start zu vergeben. Dann kann Josm in den neuen
Busrouten die Route entsprechend sortieren. 80% des Aufwands, den ich im
Moment in der Reparatur von Busrouten habe, besteht darin, den
Anfangspunkt zu finden, wenn einige Mapper das Ding durcheinander
gewürfelt haben.

Josm sollte für die neuen Busrouten in der Lage sein, die Route
fortlaufend zu sortieren wie jetzt, aber mit Berücksichtigung der
start-Role, automatisch forward/backward zu entfernen und die
Haltestellen entsprechend der Wege zu sortieren. Da nach dem neuen
Schema immer eine stop_position auf dem Weg liegt, sollte es anhand der
übereinstimmenden Haltestellennamen und der Entfernung möglich sein,
auch die Haltestellen automatisch in die richtige Reihenfolge zu
bringen.

Wenn Josm auf eine Lücke stößt, wird danach weiter sortiert wie jetzt
auch. Der Sprung auf die Lücke ist bereits vorhanden, hier sollte der
herunterzuladende Bereich deutlich verkleinert werden. Es reicht, die
nächsten 20m im Umkreis zu laden. Wenn der Editor positioniert ist, kann
der Mapper eine größere Umgebung manuell herunter laden.

Im Moment ist es so, dass man je nach Ausstattung des Rechners nach 5 -
10 Sprüngen erst einmal den Datenpuffer wegschmeißen muss. Das ist
überflüssige Zeit und Traffic.

Die alten Relationen mögen vordergründig einfacher sein, weil man nach
einem Straßenumbau einfach die Wege irgendwo reinschmeißen kann.
Übersichtlich sind die Relationen auf keinen Fall. 

Der Wartungsaufwand ist bei den neuen Relationen sehr viel kleiner, und
wenn an Josm noch ein bisschen geschraubt wird, sollte es auch für
Anfänger recht einfach sein.

Gruß, Wolfgang


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

Re: [Talk-de] Routenplaner OSRM als ÖPNV Editor (der Weisheit letzter Schluss??)

[Wolfgang Hinsch]

Am Sonntag, den 22.12.2013, 16:51 +0100 schrieb Roland Olbricht:
  80% des Aufwands, den ich im
  Moment in der Reparatur von Busrouten habe, besteht darin, den
  Anfangspunkt zu finden, wenn einige Mapper das Ding durcheinander
  gewürfelt haben.
  
 Das Public-Transport-Plugin kann Routen automatisch sortieren und umdrehen, 
 wenn sie genau falsch herum sortiert sind. Die forward/backward-Rollen 
 sind allerdings für eine eindeutige Sortierung notwendig, vor allem, wenn 
 eine 
 Buslinie z.B. in einem Busbahnhof einen kreisförmigen Weg befährt.

Im Busbahnhof muss die Relation ggf. aufgesplittet werden in mehrere
Äste. Ähnliches gilt, wenn ein Bus zum Anfahren eines Zwischenziels
denselben Weg hin- und wieder zurückfährt. Dann muss die Route auf
mehrere Äste verteilt werden, weil ein way nur einmal in der Relation
vorhanden sein darf.

Die neuen Bus-Relationen haben lt. Wiki gar keine Role. Da die
Relationen jeweils einen Weg in einer Richtung beschreiben, kann dieser
Weg durch eine Kette von Anfangs-/Endpunkten bestimmt und auch berechnet
werden. Auch deshalb darf es innerhalb derselben Route-Relation keine
Verzweigungen geben. Wenn die Relation lückenlos ist, kann sie
automatisch sortiert werden, ggf. anhand des From-tags. Da die
Relationen aber in der Praxis nach einiger Zeit Lücken aufweisen, wäre
es gut, wenn JOSM den Anfangsway automatisch erkennen und dann schon
einmal sortieren könnte, soweit es geht.

Manuell kann man dann auf die Lücken springen und damit auch größere
Routen innerhalb weniger Minuten klären.

Wenn nur die Suche nach dem Anfang nicht wäre...

Ich vergebe inzwischen für den ersten way der Relation die Role
start. 

Gruß, Wolfgang


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

Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was?

[Wolfgang Hinsch]

Hallo,

Am Freitag, den 20.12.2013, 15:08 +0100 schrieb Bernhard Weiskopf:
  Von: Tirkon [mailto:tirko...@yahoo.de]
  Gesendet: Dienstag, 17. Dezember 2013 01:37
  An: talk-de@openstreetmap.org
  Betreff: Re: [Talk-de] Zeitreise ins 4. Jahrhundert oder was?
  ...
  Ein wichtiger Fall, der IMHO gegen eine Aufnahme von Daten sprechen
  könnte, wäre eine Unübersichtlichkeit durch den Gebrauch komplizierter
  Konstrukte, welche die breite Masse der Mapper, von denen wir immer
  noch zu wenig haben, vom Anfassen und Maintainen abhalten könnte.
 
 Das ist doch längst passiert.
 
 In meiner Umgebung sind ein paar breite Hauptstraßen an Kreuzungen
 aufgeteilt in zwei Richtungsfahrbahnen und in der Mitte sind Inseln für
 Fußgänger und Radfahrer. Diese Aufteilung und damit das genauere Eintragen
 von Fuß- und Radwegen würde ich gerne auch in OSM abbilden, wo die Straßen
 zurzeit als jeweils eine durchgehende Linie eingetragen sind.
 
 Da über diese Straßen aber Bus-Relationen führen und nach deren neuen Schema
 die Straßensegmente in der Relationsliste in der richtigen Reihenfolge
 eingetragen werden müssen und das Ganze auch noch für jede Fahrtrichtung
 einzeln, lasse ich das Editieren sein. Das ist mir inzwischen zu aufwändig
 zu pflegen.
 

Wenn das die alten Relationen sind, einfach die neuen Straßen mit
reinkippen. Wenn es die neuen Relationen sind, die 2 oder 3 Wege aus der
einen Richtung entfernen und die neuen Wege dafür reinsetzen. Josm kann
das sogar automatisch sortieren. Das ist eigentlich recht trivial.

Komplizierter sind die tmc-Gebilde. Die versteht inzwischen
wahrscheinlich niemand mehr. Es werden immer mehr, sie sind
unverständlich, umständlich und kaum handhabbar. Es gab da mal einen
Ansatz, das ganze zu vereinfachen in einem einzelnen Tag.

Mit dem Einzeichnen von separaten Parallelwegen verkomplizierst du
übrigens die Daten auch. Ein tag am way für den Radweg sagt klar, für
welche Straße er begleitend ist, wie der Straßennamen zuzuordnen ist
etc. Die Darstellung ist in allen Zoomleveln außerhalb 17+ besser.

Aus der Klemme kann man rauskommen, wenn die cycleway-tags an der Straße
bleiben und eine Street-Relation den separaten cycleway an die Straßen
koppelt. Dann kann der Auswerter je nach Maßstab entscheiden, ob er den
Radweg einzeln zeichnet oder nur das tag auswertet.

Gruß, Wolfgang


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

Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was?

[Wolfgang Hinsch]

Hallo Bernhard

Am Freitag, den 20.12.2013, 17:17 +0100 schrieb Bernhard Weiskopf:
 Hallo Wolfgang,
 
 ich arbeite mit Potlach 2. JOSM hatte ich auf dem alten PC installiert,
 hab's aber kaum benutzt, weil mir die Schrift zu klein war. Eben habe ich
 versucht JOSM zu installieren, ich komme damit aber nicht klar:

Bei der Schrift muss ich im Moment passen.
 
 Es startet mit einem Fenster Veraltete JAVA-Version. Sie verwenden die
 JAVA-Version 1.6.0_06 ... JOSM wird mit dieser Version bald nicht mehr
 funktionieren... JAVA darf ich nicht updaten, sonst läuft ein Programm, das
 ich geschäftlich brauche nicht mehr. Beim Versuch Hintergrundbilder zu laden
 stürzt JOSM ab JOSM is out of memory.

Dafür gibt es den Parameter -Xmxnn. Irgendwo (TM) in deinem System
hast du eine Startdatei, mit der JOSM gestartet wird. Die enthält einen
Aufruf java -jar josm-tested.jar, eventuell noch ein paar Parameter
mehr. Falls der -Xmx da schon drin ist, musst du die nachfolgende Zahl
nn erhöhen, andernfalls den Parameter dazusetzen. nn beschreibt
dabei die maximal zulässige Speichermenge für JOSM in Bytes, bei
angehängtem K oder M in Kilo- oder Megabyte. Der Wert muss natürlich zum
vorhandenen Speicher passen und ein bisschen hätte das System selbst
meistens auch noch gerne. (Bisschen ist weit untertrieben!)

Also: java -Xmx 1000M -jar josm-tested.jar

startet mit 1GB Memory für JOSM. Das ist im Wiki auch noch mal erklärt.
 
 Ist JOSM der einzige Editor, mit dem die OSM-Daten noch editiert werden
 können?

Nein, es gibt auch ID und Potlach. Josm hat aber viel mehr
Möglichkeiten.
 
 OSM hat den Vorteil, dass auch Fußgängerrouting relativ detailliert
 funktioniert. Und die Radwege sind in der Realität teilweise nur in einer
 Richtung erlaubt und etwa 25 m auseinander. In OSM kann man das zurzeit
 nicht erkennen. Wenn ich mit einer Gruppe fahre interessiert mich auch, ob
 zwischen zwei Fahrbahnen, die wir überqueren wollen, eine Insel zum Sammeln
 ist, die ist jetzt gar nicht eingetragen.

Dafür gibt es die Möglichkeit, die Fahrbahnen zu trennen, hier ist ja
eine bauliche Trennung vorhanden, oder das Tag für die Mittelinsel beim
crossing dazuzusetzen. 

highway=crossing
crossing=island

 
 Zurzeit ist Google an vielen Kreuzungen detaillierter inkl.
 Abbiegebeschränkungen und separaten Abbiege-Fahrbahnen. OSM-Router melden
 oft Jetzt rechts abbiegen wenn man nicht mehr auf die separate Fahrbahn
 wechseln kann.

Das liegt an der Qualität des Routing-Programms. Ich fahre mit
Garmin-Navis und OSM-Daten seit mindestens 2009 Auto und habe diese
Probleme nicht. Neben der grafischen Anzeige bekomme abhängig vom
Straßentyp und der gefahrenen Geschwindigkeit die Hinweise 250 - 2500m
vorher.

Das Fahrspurmapping ist ebenfalls schon in Gange, es gibt dazu einiges
im Wiki. In Josm gibt es Stile, mit denen getaggte Fahrspuren angezeigt
werden. Da sind dann auch die Verzweigungen mit drin. Das ist aber alles
noch in den Kinderschuhen.

Gruß, Wolfgang



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

Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was?

[Wolfgang Hinsch]

Hallo,

Am Samstag, den 21.12.2013, 00:47 +0100 schrieb Martin Koppenhoefer:
 
  Am 20/dic/2013 um 19:18 schrieb Wolfgang Hinsch osm-lis...@ivkasogis.de:
  
  highway=crossing
  crossing=island
 
 
 wie passt denn das zu uncontrolled oder traffic_lights? 
 http://taginfo.openstreetmap.org/keys/crossing#values
 
 Das sind doch klar unterschiedliche 
 Kategorien,

Im Prinzip ja, aber die Josm-Standardvorlage macht es genau so.

Vielleicht ist da noch etwas Optimierungsbedarf.

Gruß, Wolfgang



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

Re: [Talk-de] Komplizierte Konstrukte - WAS: Zeitreise ins 4. Jahrhundert oder was?

[Wolfgang Hinsch]

Hallo,

Am Samstag, den 21.12.2013, 02:03 +0100 schrieb Bernhard Weiskopf:
  Am Freitag, den 20.12.2013, 17:17 +0100 schrieb Bernhard Weiskopf:

 Mit Potlach und ID kann man alle Straßen mit neuen Busrelationen aber nicht
 mehr vernünftig editieren. Selbst mit JOSM wird man sich extra um die
 Reihenfolge kümmern müssen. 

Es reicht, den ersten Way nach ganz vorn zu nehmen und auf Sortieren zu
drücken. Allerdings sollten die Ways keine Role haben, zumindest der
Erste, sonst hat Josm Schwierigkeiten. Wenn es nicht richtig sortiert
wird, liegt irgendwo ein Fehler vor. Auf die Lücke springen und darauf
zoomen, dann klärt sich das. Bei mir jedenfalls bisher.

  Das liegt an der Qualität des Routing-Programms. Ich fahre mit Garmin-
  Navis und OSM-Daten seit mindestens 2009 Auto und habe diese Probleme
  nicht. Neben der grafischen Anzeige bekomme abhängig vom Straßentyp
  und der gefahrenen Geschwindigkeit die Hinweise 250 - 2500m vorher.
 
 Die kommen bei OsmAnd und Navigator auch. Da in Großstädten dann aber oft
 einige Kreuzungen dicht hintereinander folgen, kommt kurz vor dem
 tatsächlichen Abzweig zusätzlich die Ansage Jetzt rechts abbiegen. Und
 wenn die separate Abbiegefahrbahn in OSM fehlt, kommt diese Ansage oft zu
 spät.

Garmin sagt vorher schon mal rechts halten, demnächst rechts
abbiegen. Außerdem läuft immer eine große Zahl als Countdown in Metern
bis zur Abbiegung. Die einzige Stadt, in der man sich trotzdem verfährt,
ist Salzburg ;-)

Im übrigen ist es gerade in der Großstadt relativ egal. Wenn man die
eine Abzweigung nicht erwischt hat, soll sich das Navi einen anderen Weg
suchen.

 
 An manchen Kreuzungen in den Großstädten muss man als Fahrradfahrer die
 Seite wechseln und dazu alle Fahrbahnen an einem markierten Übergang
 kreuzen, meistens auch mit traffic_signals. Wenn die Radwege als tags an den
 Straßen hängen kann man das nicht darstellen. 

Na ja, wenn da ein Baucontainer oder der Müllwagen auf dem Radweg steht,
kann man das auch nicht darstellen. Ich sehe das Navi nur als
Hilfsmittel, nicht als Fernsteuerung.

Im übrigen haben wir die crossing-Tags. Das Navi kann so schon
berechnen, wo die Straßenseite gewechselt werden sollte. In vielen
Straßenschluchten kann das Navi ohnehin nicht erkennen, auf welcher
Straßenseite du gerade bist.

 
 Oft liegt ein schmaler Grünstreifen zwischen Radweg und Fahrbahn oder
 mindestens ein hoher Bordstein. Vom Radweg aus ist an vielen Stellen kein
 Linksabbiegen möglich und der Router muss das entsprechend erkennen und
 rechtzeitig auf die Fahrbahn routen oder ähnlich. Das geht am
 übersichtlichsten und fehlerärmsten, wenn die Radwege getrennt gezeichnet
 werden, so wie sie auch in der Natur geführt werden.
 

Das Thema dürfte sowieso in ein paar Jahren durch sein, dann haben alle
Straßen Radspuren. Die Radwege werden vermutlich aussterben.

Gruß, Wolfgang


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

Re: [Talk-de] Zeitreise ins 4. Jahrhundert oder was?

[Wolfgang Hinsch]

Am Dienstag, den 17.12.2013, 00:55 +0100 schrieb Martin Koppenhoefer:
 Am 16. Dezember 2013 19:54 schrieb Eckhart Wörner ewoer...@kde.org:
 
  Hallo Chris,
 
  Am Montag, 16. Dezember 2013, 15:33:36 schrieb chris66:
   Bei Wikipedia gibt's das ja schon, es wird immer schwieriger
   für Anfänger was neues (in entsprechender Relevanzhöhe)
   einzutragen. Mit dem Ergebnis, dass es immer weniger
   Wikipedia-Autoren gibt.
 
  Ja und? Seit wann definieren sich OpenStreetMap und Wikipedia über die
  Menge der Daten?
  Wikipedia hat schon längst erkannt, dass Qualität viel wichtiger ist als
  Quantität, es wird Zeit, dass OSM auch zur Einsicht kommt.

Wikipedia hat im Gegenteil entdeckt, dass der Autorenschwund so
dramatisch ist, dass dringend gegengesteuert wird. Deshalb werden u.a.
einfachere Editoren entwickelt. 
http://www.handelsblatt.com/technologie/it-tk/it-internet/neue-technologie-wikipedia-kaempft-gegen-autorenschwund/8555600.html

Uns würde das noch viel härter treffen. Ein Autor in der
Engelbrechtschen Wildnis oder Lüneburger Heide ist locker durch einen
Autor aus München zu ersetzen. Bei Mappern funktioniert genau das nicht,
und unsere Daten veralten viel schneller.

 
 
 
 ich würde es nicht begrüßen wenn wir in OSM auch anfangen, die Mapper mit
 Relevanzregeln zu vergraulen. 

+1

 Dann lieber die Importe komplett verbieten,
 die haben nämlich große Mitschuld am quantitativen Datenwachstum (auch
 durch zusätzliche tags wie source, Quelldatenset-ids und -klassen, etc.)

Nicht komplett, sondern nur dort, wo die Datendichte den Import nicht
sinnvoll erscheinen lässt.


 
  (Persönlich bin ich z.B. nicht bereit, für OSM zu spenden, solange das
  Geld den Bordsteinkantenmappern zugute kommt.)
 
 
 
 Für Bordsteinkanten gibt es gute Chancen, dass die selbst nach Einführung
 von Relevanzkriterien gemappt werden dürften. Sachen, die nicht direkt
 mit Verkehr zusammenhängen, fielen da vermutlich früher raus.
 Bordsteinkanten (insb. die Lage der abgesenkten) sind wichtig für viele
 Fortbewegungsmittel, Fahrräder, Rollstühle, Kinderwägen, Rollatoren, ...
 daneben sind die Bordsteine die Grenze zwischen Fahrbahn und Gehweg,
 definieren also die Verkehrsflächen.

+1

Mangelnde Toleranz scheint irgendwie eine deutsche Eigenschaft zu sein.
Immer muss etwas geregelt, vorgeschrieben oder verboten werden.

Gruß, Wolfgang



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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege

[Wolfgang Hinsch]

Hallo,

Am Dienstag, den 05.11.2013, 16:26 +0100 schrieb Martin Koppenhoefer:
 Am 4. November 2013 20:19 schrieb Bernhard Weiskopf bweisk...@gmx.de:
 
  Den Wortlaut Der
  Radverkehr  darf  nicht  die  Fahrbahn,  sondern  muss den Radweg benutzen
  finde ich klar formuliert.
 
 
 
 das wäre so sicher klar formuliert, steht aber in der StVO überhaupt nicht
 so drin, oder hast Du mal die passende Stelle?
 
 http://www.gesetze-im-internet.de/stvo_2013/__2.html
 

ich zitiere mich mal:

Na, dann zähl' ich noch mal ein paar Erbsen dazu:

STVO, Anlage 2 (zu § 41 Absatz 1), Abschnitt 5 Sonderwege, Zeichen 237
Radweg

;-)

/

Zitate aus Gesetzen sollten immer die genaue Fundstelle enthalten. Ich
habe auch suchen müssen.

Gruß, Wolfgang


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

Re: [Talk-de] path am Strand fuer den Router ...

[Wolfgang Hinsch]

Hallo,

Am Montag, den 04.11.2013, 23:27 +0100 schrieb Florian Lohoff:
 Hi,
 
 On Mon, Nov 04, 2013 at 08:52:05PM +0100, Martin Raifer wrote:
  Der Weg existiert ja defakto nicht.
  
  Doch.
  
  Ich sehe keinen großen Unterschied zu (teilweise) weglosen
  Wanderrouten im Gebirge. Einfach ein entsprechendes
  trail_visibility-Tag [1] dranhängen und jeder versteht was gemeint
  ist (hier könnte z.B. good passen, falls die Route ansonsten gut
  durch Wegweiser markiert ist).
  
  Die permanente Existenz einer Wegspur sollte keine notwendige
  Voraussetzung für einen Weg i.S.v. OSM sein. Ansonsten dürfte es so
  etwas wie [2] nicht geben, man müsste Wanderwege an Furten zwischen
  den beiden Ufern auftrennen, und und und.
 
 Es darf auch nicht existieren - Hier muesste der router ueber den Strand
 routen koennen. Der Weg existiert nicht sondern in Dänemark ist das
 befahren des gesamten Strandes mit dem Auto erlaubt.
 
 Wir taggen nicht fuer den Renderer und wir taggen auch nicht fuer 
 den Router.

Doch, genau das wird gemacht. Oder hast du schon einmal eine Fährlinie
im Wasser gesehen? Oder im Fluss?

Von Grenzen und PLZ-Gebieten will ich jetzt gar nichts weiter
schreiben...

Ich würde vorschlagen, an den Weg, der ja letztlich da ist, aber nur als
ideale Linie existiert, ein 

highway=virtual
bus=yes
hgv=no
foot=...

oder 
highway=*
waytype=virtual

oder so

zu setzen. Dann wissen alle Renderer, dass es sich um einen Way auf
einer Fläche handelt und können in Abhängigkeit von der Fläche und den
tags entscheiden, ob gerendert werden soll oder nicht.


 
 Wenn der way an die flaeche mit landuse=beach angeschlossen ist, ist
 es technisch moeglich eine route zu finden. 
 

Man sollte nicht vergessen, dass Straßen in einigen Gebieten wie z.B.
Wüsten auch nicht überall einem Weg entsprechen, sondern sich da jeder
seine Spur sucht, auch je nach Befahrbarkeit. Das kann man bei OSM auch
nicht einfach ignorieren und die Wege auf beiden Seiten an die Sahara
anschließen lassen.


Gruß, Wolfgang


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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)

[Wolfgang Hinsch]

Am Sonntag, den 03.11.2013, 21:35 +0100 schrieb Peter Wendorff:
 Kann man das? Spontane Fälle, bei denen ich mir da nicht sicher bin, wie
 das zu tun wäre:
 
 Fall 1) Benutzungspflichtiger Radweg: Taggst du dann bicycle=no an der
 dazugehörigen Straße? Im Grunde genommen schon, denn da darf man dann
 eben nicht Radfahren (solange der Zustand des Radwegs zumutbar ist).
 Fall 2) Benutzungspflichtiger Radweg ohne explizite Erlaubnis in
 Gegenrichtung, aber nur auf einer Seite: Welche Tags kommen dann an die
 Straße?

Noch schöner: Benutzungspflichtiger Radweg links, zusätzlicher Radweg
rechts, beide für beide Richtungen zugelassen, aber nur der linke ist
-s.o.- benutzungspflichtig.

Eigentlich müsste man dann das Rad tragen :-)

Gruß, Wolfgang



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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)

[Wolfgang Hinsch]

Am Sonntag, den 03.11.2013, 22:37 +0100 schrieb Bernhard Weiskopf:
  Spontane Fälle, bei denen ich mir da nicht sicher bin, wie
  das zu tun wäre:
  
  Fall 1) Benutzungspflichtiger Radweg: Taggst du dann bicycle=no an der
  dazugehörigen Straße? Im Grunde genommen schon, denn da darf man
  dann eben nicht Radfahren (solange der Zustand des Radwegs zumutbar
  ist).
 
 In Deutschland: Ja. 
 StVO: Der  Radverkehr  darf  nicht  die  Fahrbahn,  sondern  muss den
 Radweg benutzen. (- Fahrbahbenutzungsverbot)
 

Nee, das war mal.

§2 Abs. 4 Satz 2ff:
Eine Pflicht, Radwege in der jeweiligen Fahrtrichtung zu benutzen,
besteht nur, wenn dies durch Zeichen 237, 240 oder 241 angeordnet ist.
Rechte Radwege ohne die Zeichen 237,
240 oder 241 dürfen benutzt werden. Linke Radwege ohne die Zeichen 237,
240 oder 241 dürfen nur benutzt
werden, wenn dies durch das allein stehende Zusatzzeichen „Radverkehr
frei“ angezeigt ist.


Gruß, Wolfgang


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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)

[Wolfgang Hinsch]

Am Sonntag, den 03.11.2013, 23:59 +0100 schrieb Bernhard Weiskopf:
  Von: Wolfgang Hinsch [mailto:osm-lis...@ivkasogis.de]
  Am Sonntag, den 03.11.2013, 22:37 +0100 schrieb Bernhard Weiskopf:

   StVO: Der  Radverkehr  darf  nicht  die  Fahrbahn,  sondern  muss den
   Radweg benutzen. (- Fahrbahbenutzungsverbot)
  
  Nee, das war mal.
  
  §2 Abs. 4 Satz 2ff:
  Eine Pflicht, Radwege in der jeweiligen Fahrtrichtung zu benutzen, besteht
  nur, wenn dies durch Zeichen 237, 240 oder 241 angeordnet ist.
  Rechte Radwege ohne die Zeichen 237,
  240 oder 241 dürfen benutzt werden. Linke Radwege ohne die Zeichen 237,
  240 oder 241 dürfen nur benutzt
  werden, wenn dies durch das allein stehende Zusatzzeichen „Radverkehr
  frei“ angezeigt ist.
 
 Nee, das ist immer noch so:  Benutzungspflichtige Radwege müssen benutzt 
 werden.
 
 Du hast nur zitiert, was benutzungspflichtig bedeutet, das war hier gar 
 nicht strittig. Es ging ausschließlich um benutzungspflichtige Radwege.
 

Na, dann zähl' ich noch mal ein paar Erbsen dazu:

STVO, Anlage 2 (zu § 41 Absatz 1), Abschnitt 5 Sonderwege, Zeichen 237
Radweg

;-)

Gruß, Wolfgang


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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)

[Wolfgang Hinsch]

Am Freitag, den 01.11.2013, 20:06 +0100 schrieb Bernhard Weiskopf:
  Dann zeige doch mal einen Radweg, der mit oneway=yes getaggt ist, weil er
  straßenbegleitend ist.
 
 Zum Beispiel hier: 
 http://www.openstreetmap.org/?mlat=49.50360mlon=8.49903#map=19/49.50360/8.
 49903
 
 In Mannheim sind etwa die Hälfte der straßenbegleitenden Radwege in beiden
 Richtungen freigegeben, die andere Hälfte nicht.
 
 So auch im o. a. Fall: der südliche Weg darf nur Richtung Osten benutzt
 werden, der nördliche in beiden Richtungen.


Stimmt, kommt häufig vor. Aber ebenso häufig auch nicht.

Vielleicht sollte jeder straßenbegleitende Radweg mindestens vorläufig
ein oneway=yes/no bekommen, damit ersichtich wird, wo das gemappt wurde
und wo nicht.

Gruß, Wolfgang


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

Re: [Talk-de] Fahrradwege taggen, Lübecker Methode

[Wolfgang Hinsch]

Am Samstag, den 02.11.2013, 07:45 +0100 schrieb Dirk Sohler:
 Leo Koppelkamm schrieb:
  Hier die Antwort von Martin vom ADFC:
 
 Als solche behandele ich deine Mail mal :)
 
 
  […] leider kann man ja auf de Mailingliste nicht antworten,
  ohne sich anzumelden.
 
 Dann tu das doch …
 
 
  Erst einmal möchte ich die anmaßende und unzutreffende Kritik
  zurückweisen. Scheinbar sind einige Mitglieder der Liste der Meinung,
  sie seien die Chefs von Openstreetmap und können über alles
  bestimmen, rufen sogar dazu auf, mühsam erarbeitete Daten zu löschen.
 
 Und andere meinen, sie können die mangelnde eigene Infrastruktur
 für ihre Spezialanwendungen durch die OSM-Infrastruktur ersetzen, und
 Tags nach ihrem Gusto inkompatibel und unnötig redundant verändern.
 
 
  [Änderungen] brauchen keine Genehmigung durch die Mailingliste.
 
 Nicht von der Mailingliste an sich, aber solch massive Änderungen
 sollten vorab zumindest mal mittels Proposal oder anderweitig
 vorgestellt werden, und nicht einfach wild ohne Rücksicht auf Verluste
 vorgenommen werden.
 
 
  Jedenfalls solltet Ihr Euch mal überlegen, ob man Lust hätte, seine
  Überlegungen das nächste Mal bei Euch zur Diskussion zu stellen.
 
 Vielleicht „sollte man“ mal überlegen, solche Änderungen nicht nur auf
 einem Stammtisch zu diskutieren, sondern öffentlich online „an
 Prominenter Stelle“ zur Diskussion zu stellen, anstatt einfach – ich
 wiederhole mich da – Tags inkompatibel und redundant für die eigenen
 Anwendungen in ihrer Bedeutung und Verwendung zu verändern.
 
 
  Die ist aber notwendig, damit der Renderer […]
 
 Wir mappen nicht für den Renderer.

Def. Mappen für den Renderer: Inhalte bewusst sachlich verkehrt
darstellen, damit ein bestimmter Renderer etwas im Sinne des Verwenders
darstellt.

Das einzige tag, das _heute_ sich gefestigt hat und anders benutzt wird,
ist cycleway. Aber auch das nicht für den Renderer, sondern weil es
logisch erschien.

Das haben wir aber schon durchgekaut. Irgendwann reicht es. 

Im übrigen wird weder für noch geegen den Renderer gemappt.

Ansonsten wäre es schön, wenn weniger Polemik und mehr konstruktive
Vorschläge kämen.

Gruß, Wolfgang


ps.: Prominentes Beispiel für Mappen für den Renderer: Missbrauch des
name-tag, damit Mapnik Texte darstellt.




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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)

[Wolfgang Hinsch]

Am Samstag, den 02.11.2013, 14:18 +0100 schrieb Masi Master:
 Am 02.11.2013, 09:35 Uhr, schrieb Wolfgang Hinsch  
 osm-lis...@ivkasogis.de:

 
  Vielleicht sollte jeder straßenbegleitende Radweg mindestens vorläufig
  ein oneway=yes/no bekommen, damit ersichtich wird, wo das gemappt wurde
  und wo nicht.
 
 +1 für oneway=yes/no an Radwegen! (-1 für vorläufig)
 Radwege sind nicht einheitlich in 2 Richtungen (bzw. eine Richtung)  
 freigegeben, so dass ein Standardwert (wie bei motorway oder normalen  
 Straßen) überhaupt keinen Sinn macht.
 
 Aber warum nur an straßenbegleitenden?

Weil die nicht straßenbegleitenden in aller Regel wie andere Straßen
auch onewway=no sind.

Ich habe keine Probleme damit, wenn die auch ein oneway bekommen, aber
bei den straßenbegleitenden finde ich es wichtiger.

Gruß, Wolfgang



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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)

[Wolfgang Hinsch]

Am Freitag, den 01.11.2013, 13:45 +0100 schrieb Peter Wendorff:
 Eine Fahrtrichtungsbeschränkung wird über oneway getagged - warum
 sollten wir das jetzt auf einmal weglassen, nur weil man es rein
 theoretisch über die Lage zu einer Straße erraten könnte?

Dann zeige doch mal einen Radweg, der mit oneway=yes getaggt ist, weil
er straßenbegleitend ist.

Gruß, Wolfgang


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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)

[Wolfgang Hinsch]

Am Donnerstag, den 31.10.2013, 20:18 +0100 schrieb Michael Reichert:
 Hallo,
 
 Am 31.10.2013 20:11, schrieb cracklinrain:
  * Oft muss man einen Radweg früher verlassen und auf die Straße fahren,
  damit man in eine andere Straße abbiegen kann. So etwas kann durch
  Taggen an Straßen nicht gelöst werden.
 
 Deshalb gibt es ja die allgemeine Regel:
 
 Ein Weg für alles, wenn es keine bauliche Trennung gibt, zwei oder noch
 mehr Wege, wenn es eine bauliche Trennung gibt.
 
 Bauliche Trennungen:
 Leitplanke: ja
 weißer Strich: nein
 doppelter weißer Strich: allgemeine Uneinigkeit, siehe talk-de-Archiv

Die letzte Diskussion auf talk-de (7/13) hatte ergeben, dass wir hier
ein nein annehmen. Selten, aber wahr  ;-)

 Grünstreifen: eher ja
 Bordstein: für Autos würde ich ja sagen, für Fußgänger nein, bei Radlern
 kommt es auf die Höhe an. Ein Fußgänger kann an einem Bordstein überall
 die Straße überqueren.

alle anderen +1

Gruß, Wolfgang


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

Re: [Talk-de] Datenmodell für straßenbegleitende Wege (war: Fahrradwege taggen, Lübecker Methode)

[Wolfgang Hinsch]

Am Donnerstag, den 31.10.2013, 18:20 +0100 schrieb Stephan Wolff:
 Moin,
 
 für eine brauchbare Fahrradkarte genügt es offensichtlich nicht, wenn 
 Straße und Radweg einzeln erfasst sind (siehe Mapnikkarte mit je nach 
 Zoomlevel sichtbaren, halb überdeckten oder gar nicht sichtbaren 
 straßenbegleitenden Radwegen).
 
 Auch für gutes Fahrradrouting muss man straßenbegleitende von 
 eigenständigen Radwegen unterscheiden können. Mein Garmin-GPS hat mich 
 teils vom Radweg auf die Straße und zurück auf den Radweg geschickt, um 
 wenige Meter in der Kurve abzukürzen.

+1
 
 Das Lübecker-Modell mit dem Tag cycleway:*=sidepath, den Relation für 
 eigenständige Radwege an Straßen und den sidepath:refname=* mit 
 willkürlich gewählten Pseudonamen finde ich seltsam. Ich teile die von 
 Rainer genannten Kritikpunkte.
 
 Wir sollten uns endlich eine bessere Lösung überlegen.

Sofort einverstanden.

 
 Offenbar braucht man die Information, ob ein Radweg straßenbegleitend 
 oder eigenständig ist, und umgekehrt, ob zu einer Straße ein Radweg als 
 eigener way existiert. Dafür wäre je ein einfaches Tag ausreichend.
 
 Brauchen wir eine Relation, die alle Wegsegmente (Straße und Radweg) 
 zusammenfasst?

Das ist sinnvoll, um die zusammengehörenden Elemente zu finden, z.B. ist
der Radweg sonst nicht mit dem Straßennamen verbunden. Außerdem
unterscheidet man dann eindeutig den zufällig in der Nähe verlaufenden
Radweg von dem, der zur Straße gehört, und bei räumlicher Nähe mehrerer
Straßen wird klar, welche Straße gemeint ist. Das ist auch für die
Annahme einer Fahrtrichtungsbeschränkung von Bedeutung.

 
 Brauchen wir eine explizite segmentweise Zuordnung straßenbegleitender 
 Radwege zur Straße?

Das hängt von der Detailmenge ab. Wenn der Radweg segmentweise
detailliert erfasst wurde mit Oberflächenmaterial und ~zustand, sollte
es eine Möglichkeit geben, die Lage der Segmente an der Fahrbahn
abzubilden. Wie oben schon richtig angeführt muss der Radweg in
kleineren Maßstäben zeichnerisch nach außen gerückt werden. Das beste
Mittel dazu ist das Aufnehmen in die Signatur der Straße.

Theoretisch könnte man die Segmente auch aus der geometrischen Lage an
die Fahrbahn rechnen. Probleme entstehen bei Sonderfällen, wenn die
Fahrbahn und die Radwege nicht gerade verlaufen, z.B. sich um
irgendwelche Hindernisse schlängeln und dabei nicht parallel zu einander
sind und die Segmente relativ kurz sind. 
Wir brauchen also eine Methode, die immer funktioniert.

 
 Für straßenbegleitende Fußwege sollte das Modell natürlich auch 
 anwendbar sein.

+1

Fußwege werden leider viel zu wenig in die Überlegungen einbezogen.

Gruß, Wolfgang


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

Re: [Talk-de] Fahrradwege taggen, Lübecker Methode

[Wolfgang Hinsch]

Am Dienstag, den 29.10.2013, 11:04 +0100 schrieb rainerU:
 Hallo,
 
 Am 29.10.2013 00:19, schrieb Wolfgang Hinsch:
  cycleway=track ist unbrauchbar, da in ~50% der Fälle der Radweg nicht
  auf beiden Seiten gleich ist.
 
 Das ist aus meiner Sicht nicht das Thema dieses Threads. Mit dem eingeführten
 und im Wiki [1] dokumentierten Tagging-Schema können die Wege auf beiden 
 Seiten
 einer Straße durchaus differenziert getaggt werden. Was an diesem Lübecker
 Schema aufstößt ist
 
 - Das cycleway-Attribut wird umdefiniert. Standardmäßig wird dort der Typ des
 Radwegs angegeben, in Lübeck wird dort angegeben, auf welcher Seite der Straße
 ein Radweg oder -streifen verläuft.

Das ist nicht ganz richtig. Cycleway wurde zum damaligen Zeitpunkt (Vor
2,5 Jahren, seit dem ist das in Lübeck so üblich) mal mit track/lane und
mal mit left/right genutzt. Der Stammtisdh hat sich dann gemeinsam mit
dem ADFC dafür entschieden, die sinnvollere Variante left/right zu
nehmen, da track/lane sehr häufig seitenrelevant ist.

 
 - Das Schema macht Redundanz zum Prinzip. Wenn cycleway:right und 
 cycleway:left
  vorhanden sind, braucht es nicht noch cycleway=both. Redundanz schadet 
 nichts,
 aber man sollte sie nicht obligatorisch machen. Das riecht förmlich nach 
 Taggen
 für eine Anwendung.

Das wurde so auch nicht benutzt. cycleway:both ersetzt cycleway:left +
cycleway:right, ist also das Gegenteil von Redundanz. Wenn die Wege auf
beiden Seiten gleich sind, wird both benutzt. Das entspricht damit dem
cycleway=*.

 
 - cycleway=no und oneway=no sind zwar überflüssig, werden aber wohl zur
 Fortschritts-/Vollständigkeitskontrolle beim Mappen genutzt. Dafür gibt es
 durchaus plausible Argumente wie die immer mal wiederkehrenden Diskussionen zu
 oneway=no zeigen.

oneway=no ist eine Kennzeichnung für straßenbegleitende Radwege, die für
beide Fahrtrichtungen zugelassen sind. Standardmäßig sind
straßenbegleitende Radwege immer oneway, das wird üblicherweise aber
nicht getaggt. Radfahrer dürfen nur den rechten Radweg benutzen, es sei
denn, es ist anders ausgeschildert.

 
 - Ein  neuer Wert cycleway=sidepath wird eingeführt. Vermutlich will man damit
 Radwege kennzeichnen, die zwar baulich mit der Strasse verbunden sind, aber 
 als
 separater highway=cycleway|track erfasst sind. Das erscheint durchaus 
 sinnvoll,
 hätte aber diskutiert werden müssen.


 
 Letztlich bleibt als klarer und gravierender Verstoß gegen die bisherige 
 Praxis
 das Umdefinieren des Attributs cycleway. Der ganze Wust an redundanten Daten 
 ist
 zwar ärgerlich aber anwendungstechnisch nicht schädlich. Dass ausgerechnet 
 eine
 Radfahrorganisation mit Server- und Netzressourcen so verschwenderisch umgeht,
 verwundert mich allerdings.

Wenn du dich damit näher beschäftigst, wirst du feststellen, dass Lübeck
zu dem Zeitpunkt das besterfasste Radwegenetz bei OSM überhaupt hatte
und heute - jedenfalls bis jetzt - immer noch einen Spitzenplatz
einnimmt. Der ADFC Lübeck hat für OSM das gesamte Radwegenetz Lübecks
komplett abgeradelt und mit Fragebögen detailliert erfasst. Das gibt
zwangsläufig eine Datenmenge, die andernorts mangels detaillierter
Erfassung fehlt. 

Man sollte nicht vergessen, dass der ADFC Bundesverband nach wie vor mit
G* arbeitet. Lübeck hat hier Pionierarbeit geleistet, auch durch die im
Lübecker Raum sehr öffentlichkeitswirksam präsentierte Karte. Auf der
Radmesse 2 Jahre vorher hatten wir mit 2 Leuten am OSM-Stand ~ 5
Gespräche am ganzen Nachmittag. Als die Karte erschien, waren wir am
OSM-Stand mit 6 Leuten den ganzen Tag ausgelastet.

Dass beim Hobeln dann mal Späne fallen, ist nicht immer vermeidbar. Neue
tags erst mal 2 Jahre zu diskutieren und dann mit 12 Leuten abzustimmen,
ist nicht immer praktikabel, und die Abstimmungen sind nicht gerade
überzeugend. Üblicherweise kann man tags ausprobieren, einführen und
dokumentieren. Das ist auch geschehen. Beim tag cycleway ist über das
Ziel hinausgeschossen worden bzw. die Entwicklung hat eine andere
Richtung genommen, das tag könnte man wieder entfernen, es ist sowieso
überflüssig, wenn der Weg entsprechend gemappt ist.

Ich schlage vor, zu überlegen ob das tag cycleway=* nicht generell als
deprecated zu bezeichnen ist. Es stammt aus der Zeit ~2007/8 als man
froh war, dass aus den Daten hervor geht, dass da überhaupt irgendwo ein
Radweg ist. Damals konnte keine Anwendung die Seite unterscheiden. 

Wenn ein Radweg auf beiden Seiten gleich ist, könnte man entweder
cycleway:left und cycleway:right oder cycleway:both benutzen, das wäre
wesentlich eindeutiger.


Gruß, Wolfgang


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

Re: [Talk-de] Fahrradwege taggen, Lübecker Methode

[Wolfgang Hinsch]

Am Mittwoch, den 30.10.2013, 14:25 +0100 schrieb Peter Wendorff:
 Am 30.10.2013 13:29, schrieb Wolfgang Hinsch:
  Am Dienstag, den 29.10.2013, 11:04 +0100 schrieb rainerU:
  [...]
 
  - cycleway=no und oneway=no sind zwar überflüssig, werden aber wohl zur
  Fortschritts-/Vollständigkeitskontrolle beim Mappen genutzt. Dafür gibt es
  durchaus plausible Argumente wie die immer mal wiederkehrenden 
  Diskussionen zu
  oneway=no zeigen.
  
  oneway=no ist eine Kennzeichnung für straßenbegleitende Radwege, die für
  beide Fahrtrichtungen zugelassen sind. Standardmäßig sind
  straßenbegleitende Radwege immer oneway, das wird üblicherweise aber
  nicht getaggt. Radfahrer dürfen nur den rechten Radweg benutzen, es sei
  denn, es ist anders ausgeschildert.
 Oha...
 Entweder ist das hier jetzt verkürzt dargestellt (und es geht um
 cycleway:oneway=no oder sowas in der Art), oder es geht um explizit als
 eigene ways eingetragene Radwege (was so auch nicht deutlich wird aus
 den Mails), oder aber oneway=no wird hier mehrfach verwendet.
 oneway=yes|no bezieht sich erstmal auf die Straße, nicht auf den Radweg
 am Straßenrand oder auf dem Bürgersteig.
 Wenn das tatsächlich jemand anders nutzt, halte ich das für einen Fehler

br. 
;-)

Es ging um straßenbegleitende, eigenständig gemappte Radwege, nicht um
die Straße (Fahrbahn) selbst.

Gruß, Wolfgang


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

Re: [Talk-de] Fahrradwege taggen, Lübecker Methode

[Wolfgang Hinsch]

Am Montag, den 28.10.2013, 13:29 +0100 schrieb Leo Koppelkamm:
 Hallo Liste,
 
 verzeiht falls das schonmal diskutiert wurde, ich konnte nichts dazu finden.
 
 Zum Thema:
 Der ADFC Lübeck hat in Eigenarbeit eine neue Art Fahrradwege zu tagen
 erfunden, die leider komplett inkompatibel mit dem bisherigen Model ist. (
 http://wiki.openstreetmap.org/wiki/DE:Bicycle/Radverkehrsanlagen_kartieren_L%C3%BCbecker_Methode)
 
 Statt cycleway=track benutzen sie jetzt cycleway=both;
 cycleway:right=track, cycleway:left=track.

???

wiki.openstreetmap.org/wiki/DE:Key:cycleway

/Zusätzliche Fahrradwegtags für andere highway-Typen

http://wiki.openstreetmap.org/wiki/Key:cycleway

cycleway=track ist unbrauchbar, da in ~50% der Fälle der Radweg nicht
auf beiden Seiten gleich ist.

Habe ich dich jetzt falsch verstanden oder sind das die Auswirkungen des
letzten Orkans ;-)

Gruß, Wolfgang




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

Re: [Talk-de] Spezialgebiet Fahrrad-Mapping

[Wolfgang Hinsch]

Hallo Alexander,

Am Samstag, den 05.10.2013, 15:42 +0200 schrieb Alexander Lehner:
 

 
 - Der ADFC haette gerne Karten oder Poster auf OSM Basis erstellt. Dazu 
 wurden schon verschiedene Renderer ausprobiert, aber die Projekte sind 
 irgendwann wieder eingschlafen, weil das Aufsetzen eines Renderers 
 ziemlich viel Arbeit ist, bis das Ergebnis den Erwartungen entspricht.

Der ADFC muss da wohl etwas differenzierter gesehen werden. Der
Bundesverband setzt schainbar konsequent auf Google, was bei einigen
Ortsverbänden zu Kopfschütteln führt.

Du kennst
http://www.adfc-sh.de/htdocs/jo-sh/index.php/vor-ort/kreisverband-luebeck/125-luebecker-fahrradstadtplan-erschienen
 ?


Gruß, Wolfgang


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

[Talk-de] Josm ubuntu repository

[Wolfgang Hinsch]

Hallo,
ich bin den Anweisungen auf
http://josm.openstreetmap.de/wiki/Download#Ubuntu gefolgt, bekomme
aber bei der Ausführung von sudo apt-get update die Fehlermeldung 404
not found.

sudo apt-get install josm lädt dann entsprechend die veraltete
Ubuntu-Version.

Ist das Repository abgeschaltet/veraltet und muss nur noch von der
Website entfernt werden?

Gruß, Wolfgang


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

Re: [Talk-de] Josm ubuntu repository

[Wolfgang Hinsch]

Hallo,

Am Sonntag, den 06.10.2013, 00:55 -0700 schrieb Walter Nordmann:
 nö, klappt bei mir prima.
 zeig bitte mal die zeile in sources.list - ich hab da so einen Verdacht.
 
ich bin vorgegangen nach 
http://josm.openstreetmap.de/wiki/Download#Ubuntu

and add the following line:

deb http://josm.openstreetmap.de/apt VERSION universe

Genau die Zeile habe ich aus dem Wiki kopiert und in die Datei reingesetzt.

Erst am Ende, und als das nicht funktionierte, am Anfang.

Das geht aber genau so wenig.

Gruß, Wolfgang


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

Re: [Talk-de] Josm ubuntu repository

[Wolfgang Hinsch]

Hallo,

Am Sonntag, den 06.10.2013, 16:46 +0200 schrieb Frank:
 Am 06.10.2013 16:30, schrieb Wolfgang Hinsch:
 ..
  and add the following line:
 
  deb http://josm.openstreetmap.de/apt VERSION universe
 
  Gruß, Wolfgang
 
 
 Das Wort VERSION soll man durch das Ubuntu-Release ersetzen
 z.B. 13/04 = raring.
 
 Siehe Ordner-Namen in http://josm.openstreetmap.de/apt/dists/
 
aahgr...

ich wusste immer, dass meine Maus zu blöd für cut and paste ist...

;-)

Danke + Gruß,
Wolfgang


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

Re: [Talk-de] ID solved

[Wolfgang Hinsch]

Am Freitag, den 04.10.2013, 06:42 +0200 schrieb Dirk Sohler:
 Wolfgang Hinsch schrieb:
  Ich habe es noch einmal nachgeprüft. Die Webseite läuft komplett auf
  Deutsch, bis ich mich anmelde. Dann schaltet sie um auf Englisch.
 
 Dass du auf https://www.openstreetmap.org/user/USERNAME/account im
 Abschnitt „Bevorzugte Sprachen“ eben diese z.B. mit „de“ (konform nach
 ISO 3166-1) festlegen kannst, weißt du aber, oder?
 
Genau um den Eintrag geht es. Er steht bei mir auf de-DE,en-US,en

...

Jetzt habe ich es verstanden.

Über dem Eintrag steht: Preferred Languages, 
korrekt übersetzt mit Bevorzugte Sprachen

Aus dem Plural habe ich geschlossen, dass man hier eine Rangfolge
festlegen soll: Wenn die Spache 1 vorhanden ist - anzeigen, dann
Sprache 2 etc bis zur Fallback - Sprache, die wohl in jedem Fall
Englisch ist.

Gemeint ist aber Lege die Sprache fest, in der du angesprochen werden
willst

Im Falle Deutsch ist da häufig kein Unterschied. Ich kann mir aber
vorstellen, dass jemand beispielsweise in Nordspanien am liebsten
Catalanisch, dann Kastilisch, dann Englisch hätte. Insofern erschien mir
der Plural in einem internationalen Projekt auch sinnvoll. Dass dann
Vieles auf Englisch erscheint, ist nicht weiter auffällig, da eben nicht
alles übersetzt ist.

In Josm hat es auch funktioniert, allerdings weiß ich jetzt nicht, ob
Josm die Einstellung bei OSM oder die lokale Einstellung auf dem eigenen
Rechner abfragt.

Danke für die Antworten

Gruß, Wolfgang


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

Re: [Talk-de] Deutscher Wandertag

[Wolfgang Hinsch]

Am Freitag, den 04.10.2013, 09:58 +0200 schrieb Thorsten Alge:
 Hallo Liste,
 
 ich habe gerade mit der Organisatorin vom „Deutschen Wandertag 2014“ in
 Bad Harzburg telefoniert um abzustecken ob vielleicht eine Beteiligung
 mit einem OSM-Stand o.ä. möglich wäre. Gesprochen haben wir zunächst
 über geführte „OSM“-Wanderungen und einen Stand am Veranstaltungsort.
 
 Was die Wanderungen angeht, steht das Programm schon fest und das
 Angebot ist bereits groß von daher gibt es da wohl eher wenig Möglichkeiten.
 
 Ein Stand wäre zwar möglich aber die Standgebühren betragen 800,-€ und
 wir müssten Freiwillige haben die ihn vier Tage lang betreiben. Von
 daher wohl auch eher schwierig.

Das würde wohl nur funktionieren, wenn wir Leute finden, die das ganze
von der professionellen Seite sehen und die Gebühren übernehmen, dann
aber auch mit ausstellen, so dass OSM gewissermaßen Gast auf dem eigenen
Stand ist.

Dass ein Freiwilligenprojekt den Wandervögeln Karten hinterherträgt und
dafür noch bezahlt, ist wohl etwas viel verlangt.

Gruß, Wolfgang



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

Re: [Talk-de] ID solved

[Wolfgang Hinsch]

Am Freitag, den 04.10.2013, 11:53 +0200 schrieb Alexander Heinlein:
 On Fri, Oct 04, 2013 at 11:40:34AM +0200, Wolfgang Hinsch wrote:
  Genau um den Eintrag geht es. Er steht bei mir auf de-DE,en-US,en
  
  ...
  
  Jetzt habe ich es verstanden.
  
  Über dem Eintrag steht: Preferred Languages, 
  korrekt übersetzt mit Bevorzugte Sprachen
  
  Aus dem Plural habe ich geschlossen, dass man hier eine Rangfolge
  festlegen soll: Wenn die Spache 1 vorhanden ist - anzeigen, dann
  Sprache 2 etc bis zur Fallback - Sprache, die wohl in jedem Fall
  Englisch ist.
 
 Das hast du denke ich auch richtig verstanden. Ich hab dort angegeben:
 de-DE,de,en-US,en
 Und hier ist iD auch auf deutsch. Anscheinend liegt es bei dir am fehlenden
 de, das de-DE scheint an der Stelle ignoriert bzw. nicht abgefragt zu
 werden. Ob das letztendlich ein Fehler oder aber konform ist, weiß ich
 nicht.

Das ist interessant. Bei mir habe ich es geändert auf de-DE und den
Rest gelöscht. Damit schaltet alles auf Deutsch um.

Irgendwie habe ich das Gefühl, dass hier ein Bug im Spiel ist.

Gruß, Wolfgang


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

Re: [Talk-de] Bevorzugte Sprachen

[Wolfgang Hinsch]

Am Freitag, den 04.10.2013, 13:01 +0200 schrieb Alexander Heinlein:

 
 Wenn ein einzelnes de-DE funktioniert, aber ein am Anfang der Liste
 stehendes nicht, dann klingt das sehr nach einem Bug.
 
 Kann ich hier übrigens reproduzieren. de-DE führt zu einer deutschen
 Übersetzung der Website, de ebenfalls, de-DE,de,en-US,en auch, aber
 de-DE,en-US,en nicht.
 
 Ich vermute das müsste hier berichtet werden:
 http://github.com/openstreetmap/openstreetmap-website/issues
 Möchtest du das tun? Ansonsten trag ich es dort ein.
 

Ich habe bei Github (noch) keinen account, wenn du da schon angemeldet
bis, wäre das insofern einfacher.

Gruß, Wolfgang


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

Re: [Talk-de] Bevorzugte Sprachen

[Wolfgang Hinsch]

Am Freitag, den 04.10.2013, 15:59 +0200 schrieb Alexander Heinlein:
 
 Also laut der Erklärung von tyrasd ist das (zumindest teilweise) so gewollt.
 Das de-DE in de-DE,en-US,en scheint keinen Treffer zu produzieren, da
 die Übersetzung nur für de vorhanden ist, aber nicht für speziellere
 Varianten (auch wenn das in diesem Fall wohl auf die gleiche Übersetzung
 hinauslaufen würde). Daher werden die anderen Einträge in der Liste
 abgearbeitet und schließlich en genommen, für das es eine Übersetzung
 gibt.
 
 Ein einzelnes de-DE hingegen führt zu keinem Treffer, daher wird die
 Sprache genommen, die dein Browser sendet. Und das ist wohl de. Also ist
 es wohl das Beste, dort de einzutragen statt de-DE, oder beides.
 
 Warum nun bei dir die Seite deutsch und der Editor englisch ist, kann ich
 mir nicht erklären und hier auch nicht nachstellen.
 

das hatte ich schon richtig gestellt. Er schaltet nach der Anmeldung
beides auf Englisch.

Ich habe das Problem jetzt gefixt, indem ich die Spracheinstellung
gelöscht habe. Da könnte in der Tat auf der Website mal dokumentiert
werden, was man da eigentlich will. Wenn die Sprache des Browsers
sowieso abgefragt wird, ist das Eingabefeld für 98% der User
überflüssig.

Manchmal sollte man sich vielleicht gar nicht um Abfragen kümmern ;-)

Gruß und nochmals Dank für die Antworten,

Wolfgang



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

Re: [Talk-de] ID

[Wolfgang Hinsch]

Hallo,
Am Donnerstag, den 03.10.2013, 01:03 +0200 schrieb Martin Raifer:
 Am 03.10.2013, 00:49 Uhr, schrieb Wolfgang Hinsch  
 osm-lis...@ivkasogis.de:
 
  Dann hat diese Übersetzung bei mir keine Auswirkungen. Eine Einstellung
  der Sprache habe ich nicht gefunden. Ich sehe nur den englischen Text.
 
 Hm. Komisch. iD übernimmt eigentlich die Sprache, die im OSM-Account  
 (unter Bevorzugte Sprachen bzw. Preferred Languages) eingestellt ist.  
 Ist das bei dir Deutsch (bzw. de oder de-DE)? 

Die Einstellung bei mir ist de-DE,en-US,en

 Wird die restliche  
 OSM-Website auf deutsch angezeigt? Ist nur die Einführung/Walkthrough  
 nicht übersetzt, oder die gesamtem Benutzerelemente von iD?
 

Die OSM-Webseite läuft komplett auf Deutsch. Der ID läuft komplett auf
Englisch.

Gruß, Wolfgang



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

Re: [Talk-de] ID

[Wolfgang Hinsch]

Hallo,

Am Donnerstag, den 03.10.2013, 19:02 +0200 schrieb Martin Raifer:
 Am 03.10.2013, 17:18 Uhr, schrieb Wolfgang Hinsch:
 
  Die Einstellung bei mir ist de-DE,en-US,en
 
  Die OSM-Webseite läuft komplett auf Deutsch. Der ID läuft komplett auf
  Englisch.
 
 Mit dieser Einstellung läuft bei mir (ebenfalls FF20) sowohl die  
 OSM-Webseite als auch iD auf Englisch. Und das wäre gemäß deiner  
 Einstellung im Prinzip auch nicht falsch (weil es keine  
 Deutschland-Deutsche Übersetzung weder von der OSM-Webseite  noch von iD  
 gibt) und du explizit eingestellt hast, dass die generisches  
 Deutsch-Übersetzung nicht verwendet werden soll.
 
 Unerklärbar ist mir aber wieso bei dir die Webseite trotzdem auf Deutsch  
 läuft. Kann das sonst noch jemand nachvollziehen?
 

Ich habe es noch einmal nachgeprüft. Die Webseite läuft komplett auf
Deutsch, bis ich mich anmelde. Dann schaltet sie um auf Englisch. Da ich
mich selten roh anmelde, hatte ich den Unterschied noch nicht bemerkt.

echo $LANG
de_DE.UTF-8

Das funktioniert in sämtlichen Programmen und allen Webseiten, bis auf
OSM, wenn ich mich anmelde.

de_DE ist Posix-Konform, siehe http://de.wikipedia.org/wiki/Locale

Alternativ wäre de_AT für Österreich.

Gruß, Wolfgang


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

Re: [Talk-de] ID

[Wolfgang Hinsch]

Am Freitag, den 04.10.2013, 01:21 +0200 schrieb Wolfgang Hinsch:

 Das funktioniert in sämtlichen Programmen und allen Webseiten, bis auf
 OSM, wenn ich mich anmelde.

Nachtrag: Auch JOSM läuft problemlos auf Deutsch.

Gruß, d.o.


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

[Talk-de] ID

[Wolfgang Hinsch]

Hallo,
der ID hat eine nette Einführung für Anfänger. Gibt es das auch auf
Deutsch oder ist eine Übersetzung geplant? Weiß jemand näheres?

Das würde die Hemmschwelle bei Vielen deutlich senken.

Gruß, Wolfgang


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

Re: [Talk-de] ID

[Wolfgang Hinsch]

Am Mittwoch, den 02.10.2013, 23:53 +0200 schrieb Martin Raifer:
 Hallo!
 
 Am 02.10.2013, 19:14 Uhr, schrieb Wolfgang Hinsch  
 osm-lis...@ivkasogis.de:
 
  der ID hat eine nette Einführung für Anfänger. Gibt es das auch auf
  Deutsch oder ist eine Übersetzung geplant? Weiß jemand näheres?
 
 Welche Einführung meinst du konkret?
 
 Wenn du die interaktive Schritt-für-Schritt Einführung (direkt im iD  
 Editor) meinst, dann sollte diese eigentlich bereits (seit Längerem)  
 komplett übersetzt sein.
 
  Das würde die Hemmschwelle bei Vielen deutlich senken.
 
 Ja! Alles was eventuell bestehende Hemmschwellen gegen das Beitragen bei  
 OSM senken kann ist eindeutig nur positiv zu sehen! :)

Dann hat diese Übersetzung bei mir keine Auswirkungen. Eine Einstellung
der Sprache habe ich nicht gefunden. Ich sehe nur den englischen Text.

Richtige Editoren wie josm laufen bei mir auf Deutsch, ebenso Menüs
etc. . 

Woran könnte es liegen?

opensuse (noch) 12.1
Firefox 20.0

Gruß, Wolfgang


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

Re: [Talk-de] Gebäude, Grundstücke und Institutionen

[Wolfgang Hinsch]

Am Dienstag, den 10.09.2013, 01:28 +0200 schrieb Martin Koppenhoefer:
 Am 10. September 2013 00:57 schrieb Gerhard Hermanns 
 gerhard.herma...@uni-due.de:
 
  Ein schönes Beispiel sind meiner Meinung nach Universitäten mit mehr als
  einem Campus. Alles folgt einer verschachtelten Logik, die ich mit der
  site-Relation abbilden kann: Die Uni besteht aus mehreren Campi, ein
  Campus hat mehrere Gebäude und Parkplätze, die Parkplätze haben Frauen-
  und Behindertenplätze, mehrere Gebäude haben einen gemeinsamen,
  übergeordneten Namen, in den Gebäuden sitzen Institute oder die Mensa usw.
  Hier kann ich dann auch einzelne Nodes für die Einrichtungen verwenden,
  wenn ich nichts anderes habe. Dadurch, dass ich sie in die Relation
  packen kann, werden sie in einer Auswertung trotzdem als zur Uni gehörig
  erkannt.
 
 
 
 für das allermeiste braucht man da allerdings keine site-Relation, das sind
 Fälle die man weitgehend mit Polygonen lösen kann: pro Campus eines, der
 Rest sind dann weitere unabhängige Objekte, räumlich innerhalb des Campus'
 und daher automatisch zugehörig. Das einzige, was man dann mit einer site-
 (oder auch multipolygon-) Relation als zusammengehörig modellieren muss
 sind die einzelnen Campi. Einen node mit entrance=yes/main kann man z.B.
 auch ohne Relation setzen.
 
 Wenn man anfängt, jeden Parkplatz (und schließlich jeden Papierkorb und
 jede Parkbank) in die Site-Relationen einzutragen, obwohl er auch schon
 räumlich auf dem Campus-Gelände liegt, dann wird man über kurz oder lang
 ein paar Dinge vergessen, d.h. es wird unübersichtlich und fehlerträchtig,
 und man kann sich letzten Endes doch nicht auf die Relation verlassen.
 
 Man kann sicherlich für alles eine site-Relation anlegen und tolle Rollen
 etc. vergeben, aber solange es auch ohne geht sollte man das unbedingt so
 machen, weil Relationen zusätzliche Komplexität einführen und tendenziell
 schnell mal kaputt gehen bzw. nicht erweitert werden (Beispiel: ein Mapper
 fügt etwas zur Karte hinzu, übersieht aber die site-Relation und nimmt das
 daher nicht mir rein), um so mehr, als nicht jeder mit JOSM arbeitet ;-)
 

-1

Es ging darum, nicht nur die Uni zu erfassen, sondern auch die einzelnen
Bestandteile der Uni den Fachbereichen etc. zuzuordnen. Spätestens dann
wird das Multipolygon gewöhnungsbedürftig, da hier ein Haufen
Multpolygone übereinander gelegt werden muss.

Im Übrigen ist auch ein Multipolygon nichts anderes als eine Relation.

Multipolygone sollten hauptsächlich benutzt werden, um räumliche
Gegebenheiten darzustellen. Für die Darstellung organisatorischer
Konstrukte ist die Site dem Multipolygon überlegen, weil sie alle Arten
von Objekten einbinden kann, Hierarchien relativ einfach und logisch
abgebildet werden können und beim Rendern weniger fehleranfällig sind.
Ein Multipolygon kann vom Renderer leichter missverstanden werden.

Gruß, Wolfgang



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

Re: [Talk-de] Harzklub Wege (War: Harzer Mappertreffen am 27. Juli 2013 in Sankt Andreasberg)

[Wolfgang Hinsch]

Am Montag, den 29.07.2013, 14:07 +0200 schrieb Martin Koppenhoefer:
 Am 29. Juli 2013 13:12 schrieb Andreas Tille andr...@an3as.eu:
 
  Weiterhin würde ich die Karte gerne bei Zweifeln heranziehen.  Hin und
  wieder ist die Beschilderung nämlich nicht eindeutig / falsch und mir
  ist es schon passiert, daß sich ein Weg verzweigt.  In diesem Fall
  sollte es doch erlaubt sein, die Karte zu konsultieren, welcher Zweig
  denn nun der offiziell richtige ist.
 
  Was ist zu einer solchen Nutzung der besagten Karte zu sagen?
 
 
 
 für OSM ist normalerweise derjenige der richtige Weg, der vor Ort
 ausgeschildert ist, und nicht derjenige, der in einer proprietären Karte
 auftaucht. Aus der Karte darf man AFAIK für OSM nichts übernehmen, sofern
 es nicht ausdrücklich vom Rechteinhaber gestattet wurde, aber man darf
 natürlich reinsehen um zu prüfen, wo man evtl. nochmal eine Begehung vor
 Ort machen sollte. Ob man Wanderrouten überhaupt in OSM aufnehmen darf ist
 sowieso eine Grauzone, da ja bereits die Konzeption einer Route die
 Schöpfungshöhe erreichen dürfte.
 

Das Entnehmen einer Route aus einer Wanderkarte ist in der Regel nicht
zulässig. Erlaubt ist aber das Wandern nach einer Wanderkarte. Entdeckt
man dabei Schilder wie Hula-Hula-Weg entlang des Weges, darf man die
natürlich mappen und anschließend, wenn sich daraus ein im Gelände
gefundener Weg ergibt, eine Relation erzeugen, die die Wegabschnitte
zusammenfasst.

Ist der Weg örtlich nicht markiert oder im Wanderführer steht Wir
folgen Weg A bis zur Abzweigung von Weg B, dem dann bis zur dritten
Milchkanne ..., dann ist die Route für OSM tabu. Weg A, B und die
Milchkanne können natürlich gemappt werden, aber nur unter den
Bezeichnungen und nicht als Route aus Wanderführer X.

Gruß, Wolfgang


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

Re: [Talk-de] OAuth (Gibt OSM auch Daten über die Beitragenden heraus?)

[Wolfgang Hinsch]

Hallo,

Am Montag, den 29.07.2013, 15:24 +0200 schrieb Martin Koppenhoefer:
 
 Il giorno 29/lug/2013, alle ore 15:10, Dirk Sohler s...@0x7be.de ha scritto:
 
  
  Ich hab die Daten nur in JOSM eingetragen.
 
 
 es gab früher in JOSM nur eine Möglichkeit, Nutzer und pw einzutragen, weil 
 dabei das pw im Klartext in den Prefs gespeichert wird, wurde das zunächst 
 etwas entschärft, indem die Prefs im Anhang für bugreports automatisch 
 zensiert wurden (man lernt halt auch als freie Community manchmal erst aus 
 Problemen, wenn sie auftreten), und später OAuth als Alternative 
 implementiert wurde. Letzteres sorgt u.a. dafür, dass das pw nicht mehr klar 
 gespeichert wird, daher ist das unbedingt zu empfehlen!
 

vielleicht etwas OT, aber habe ich die Möglichkeit der verschlüsselten
Eingabe von Passwörtern im Wiki und Forum übersehen, oder gibt es die
wirklich nicht?

Gruß, Wolfgang


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

Re: [Talk-de] Zeitlich beschraenkte Aenderungen der Geodaten

[Wolfgang Hinsch]

Hallo,

Am Montag, den 22.07.2013, 22:36 +0200 schrieb Stefan Keller:
 Hallo Henning,
 
 Es geht nicht darum ein Objekt als X zu taggen, um dann im nächsten
 Tag zu sagen, es ist Y. Und es geht niemandem um den Renderer.
 
 Der aktuelle Vorschlag lautet:
 Ein highway=primary bleibt ein highway=primary.
 Es kann nun unbestrittenermassen vorkommen, dass eine Strasse zeitlich
 angekündigt und befristet für den Verkehr gesperrt ist.
 Das wird dann mit *zusätzlichen* Tags gekennzeichnet.
 Navi- und andere Projekte müssen (bzw. können und sollen) diese
 *zusätzlichen* Tags nicht auswerten.
 
Für diese temporären Umleitungen hat man doch die tmc-tags erfunden.
Lasst die doch endlich mal funktionieren und lasst das Gebastel an den
highways. 

Alles  1 Jahr - tmc 


Gruß, Wolfgang


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

Re: [Talk-de] Datenschutz bei OSM Einträgen

[Wolfgang Hinsch]

Am Dienstag, den 16.07.2013, 16:03 +0200 schrieb Tim Michelsen:
 Hallo,
 ich suche eine Infos, Erklärung oder Richtlinie, welche Eintragungen und
 bis zu welcher Detailtiefe bei OSM erwünscht sind, und ab welchem Punkt
 von einer Eintragung v.a. aus Datenschutzgründen abgesehen werden sollte.
 

So ganz grob unterteile ich in gewerblich/geschäftlich und privat.
Private Daten, die auf Personen hinweisen (Extremfall Klingelschlilder)
mappt, so weit ich bisher gesehen habe, niemand. Geschäftliche Daten wie
Eigentümer (Pizzeria Don Giovanni, Inhaber Giovanni Meyer (frei
gewähltes Beispiel!) fallen nicht unter den Datenschutz, stehen
öffentlich auf dem Ladenschild und können rein. Es kommt immer darauf
an, ob das im Einzelfall Sinn macht oder nicht.

Einige Berufe, z.B. Tierarzt, Anwalt ... haben (zwangsweise) ein Schild
vor dem Haus, wenn sie ihre Praxis zu Hause haben. Da würde ich den
Namen dann mitmappen. Nicht aber, dass sie da auch wohnen, falls ich das
wissen sollte.

Gruß, Wolfgang


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