from:"715371"

Moin,

Am 07.02.2015 um 11:20 schrieb Michael Reichert:
 Hallo,
 
 Am 2015-02-06 um 19:21 schrieb Manuel Reimer:
 On 02/06/2015 02:43 PM, Norbert Renner wrote:
 Zumindest im Bodenseekreis [1] sind das nicht nur allgemeine
 Richtungsweiser, sondern es sind konkrete, für Radfahrer besonders
 geeignete Verbindungen ausgeschildert, mit kleinen Richtungspfeilen an
 jeder Abzweigung [2].

 Das ist eine Meinung eines Landkreises welche Wege besonders geeignet
 sein *könnten*. Jemand anderes könnte wieder andere Meinungen haben.
 Machen wir dann für alle diese Möglichkeiten Relationen?
 
 In Karlsruhe gibt es im Stadtgebiet (wie auch im Umland) diese
 grün-weißen Radroutenschilder. Es sind keine Routen (also mit Symbolen
 und Namen wie Albtalradweg, sondern einfach das Fahrrad-Äquivalent zu
 den Pkw-Wegweisern). Beispiel:
 http://www.mapillary.com/map/im/_Fe4KAuHVBlr0aZwgGLxoQ [1]

Zwischendrin gibt es aber Schilder, die lediglich angeben, wo die Route
entlang führt, ohne eine Nennung des Ziels.

Der entscheidende Unterschied ist aus meiner Sicht, dass die Route in
Wirklichkeit selbst ein Netz ist. Als wir das in Bremen diskutiert
hatten, habe ich deshalb lange überlegt, ob die Route wirklich eine
Route sei, weil sie nicht von A nach B geht, keine Anfangs- und
Zielpunkte hat.

Nur am Rande: Routen können nun einmal auch Alternativrouten haben und
das hätte diese Route beliebig viele.

 Ich habe vorgestern bei einigen dieser
 Strecken lcn=yes an den Ways ergänzt, eine Routenrelation fände ich
 jedoch übertrieben, denn die Routen sind sparsam ausgeschildert.

Bei lcn=yes sehe ich das Problem, dass man nicht weiß, weshalb der
getaggte Weg nun diesen Tag trägt. Schließlich weiß man es ja, wenn man
das systematisch erfasst. Bzw. man kann es herausbekommen, wenn man
nachfragt. Scheinbar ist in Deutschland die Gestaltung der Schilder auch
relativ ähnlich.

Aber grundsätzlich fände ich es interessant eine gute Umsetzung mit
Hilfe von lcn=* zu sehen.

LG
Tobias

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

Re: [Talk-de] Wieder einmal lcn Sammelrelationen

Am 06.02.2015 um 19:21 schrieb Manuel Reimer:
 On 02/06/2015 02:43 PM, Norbert Renner wrote:
 Zumindest im Bodenseekreis [1] sind das nicht nur allgemeine
 Richtungsweiser, sondern es sind konkrete, für Radfahrer besonders
 geeignete Verbindungen ausgeschildert, mit kleinen Richtungspfeilen an
 jeder Abzweigung [2].
 
 Das ist eine Meinung eines Landkreises welche Wege besonders geeignet
 sein *könnten*. Jemand anderes könnte wieder andere Meinungen haben.
 Machen wir dann für alle diese Möglichkeiten Relationen?

Gilt das nicht für jede Rad-/Wanderroute?

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

Re: [Talk-de] Wieder einmal lcn Sammelrelationen

Am 02.02.2015 um 19:43 schrieb Michael Reichert:
 Hallo,
 
 Am 2015-02-01 um 17:53 schrieb fly:
 Zumindest im Südwesten werden mal wieder alle Linien die einem
 lcn-Netzwerk angehören in Sammelrelationen gesteckt und diese wiederum
 sogar in Elternrelationen [1].

 Hat sich da eine andere Philosophie durchgesetzt und sind solche
 Sammelrelationen mittlerweile akzeptiert ?
 
 Diese Sammelrelationen sind nicht nötig. Es gibt ja das Tag
 cycle_network=*, das ich soeben auf
 https://wiki.openstreetmap.org/wiki/Cycle_routes gefunden habe. Es
 scheint zwar nur in den USA verwendet zu werden, aber das spricht nicht
 gegen die Verwendung von cycle_network=Radverkehrsnetz Landkreis
 Heilbronn. Sollte eine Routenrelation oder ein Wegweise mehreren Netzen
 angehören, kann man diese mit Semikolon trennen. Die Overpass-API
 unterstützt reguläre Ausdrücke, MapCSS, CartoCSS und Maperitive auch.
 
 Ich frage mich eigentlich, ob man solche Kreisradverkehrsnetze überhaupt
 mappen sollte. An den Radwegweisern ist mir bisher (in
 Baden-Württemberg) noch keine Netzangabe aufgefallen. We map what's on
 the ground?

In NRW hat man die Radrouten mit ref=NRW. Das steht auch nicht auf den
Schildern.

Außerdem haben diese Relationen meist ein name-Tag. Ich würde auch
bezweifeln, dass es einzelne Radrouten bzgl. der Kreise gibt. (Die
Unterteilung in mehrere Relationen halte ich aber aus technischen
Gründen für sinnvoll.)

Man könnte also vielleicht besser die Tags ref=* und name=* weglassen
und dafür dann cycle_network=* nutzen.

Die Elternrelationen sind nicht wirklich wichtig. Auch aus technischer
Sicht. Oder liege ich da falsch?

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

Re: [Talk-de] Wieder einmal lcn Sammelrelationen



Am 08.02.2015 um 16:28 schrieb Manuel Reimer:
 On 02/08/2015 12:03 PM, 715371 wrote:
 Das ist eine Meinung eines Landkreises welche Wege besonders geeignet
 sein *könnten*. Jemand anderes könnte wieder andere Meinungen haben.
 Machen wir dann für alle diese Möglichkeiten Relationen?

 Gilt das nicht für jede Rad-/Wanderroute?
 
 Zu einer Rad- oder Wanderroute gehört schon etwas mehr als nur eine
 Handvoll Wegweiser. Hier ist eine feste Wegführung vorgesehen, die mit
 festen Zeichen (Zahlen, Symbolen, Buchstaben, ...) auf ihrer ganzen
 Länge markiert ist. Üblicherweise mit dem Ziel entweder Information zu
 vermitteln (dann oft Tafeln im Wegverlauf) oder an besonders schönen
 Orten vorbeizuführen.

Die Schilder haben auch immer die gleiche Form, Farbe, Schrift,...
Gestaltung. Und ein Ymbol gibt es auch: Ein Fahrrad.

 Ein mehr oder weniger wahllos verlaufendes Netz ist genauso
 interessant wie das Straßennetz an sich.

Im Prinzip ist aber doch egal wie die Qualität der Wahl ist. Wenn
irgendein Verein sich eine Route auswählt, kann die Auswahl auch
schlecht gefunden werden.

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

Re: [Talk-de] F: Kreuzungsfreiheit bei trunk

2015-01-18 Diskussionsfäden 715371

Hi,

dieser trunk hat einen Bürgersteig und Radweg:

https://www.openstreetmap.org/way/124713629

Wo würdet ihr die Grenze ziehen - würdet hier jemand das als
highway=primary taggen?

LG
Tobias

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

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

2014-12-30 Diskussionsfäden 715371

Moin,

Am 30.12.2014 um 14:12 schrieb Wolfgang Hinsch:
 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.

+1000

LG
Tobias

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

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

2014-12-22 Diskussionsfäden 715371



Am 21.12.2014 um 15:20 schrieb Hubert:
 Hallo,
 
 Am Samstag, 20. Dezember 2014 02:44 schrieb 715371 osmu715...@gmx.de:
 
 Das muss der Mapper Vor Ort entscheiden. Mir hilft immer die Frage,
 ob es von der Rennleitung Ärger geben würde, wenn man dort auf der
 Straße fährt/geht, Benutzungspflicht vorrausgesetzt.

 Die Benutzungspflicht ist ja nur bei separatem highway relevant. Wenn
 man cycleway=* benutzt hat Benutzungspflicht eine deutlich geringere
 Bedeutung (es gibt noch nicht einmal einen Tag dafür - soweit mir
 bekannt).
 
 Für einen Renderer kann es zu Beispiel auch interressant sein, wenn er denn 
 benutzungspflichtige und nicht benutzungspflichtige Radwege unterscheiden 
 möchte. Aber einen eigenen Tag dafür kenne ich auch nicht, nur die Versuche 
 indierekt über bicycle=use_sidepath oder durch die Unterscheidung von 
 bicycle=official/designated und bicycle=yes. Ein eigener Wert (z.B. 
 bicycle=mandatory/obligatorry o.ä.) schein wohl überfällig, aber das ist ein 
 anderes Thema.

+1
Die Info ruft dann zwar nicht mehr Fehler hervor, wenn sie fehlt, aber
ist natürlich immer noch interessant.

bicycle=mandatory/obligatorry wäre in dem Kontext zumindest ein Tagging
über das ich noch nicht nachgedacht habe.

Problem ist vielleicht, dass es alleine am Radweg keine access-Bedeutung
hat/haben könnte.

 
 Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander
 zu vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde.

 Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine
 Stärke.

 Na ja. Das problem, das hier gelöst wird entsteht doch nur durch das
 doppelte Erfassen.
 
 Das hängt davon ab, was man als Problem identifiziert. Für mich ist es das 
 beide Modelle (an die Straße taggen, eigener Weg) sinnvoll sind. Daher wird 
 wohl schon deit 2011 () darüber gestritten ws denn nun besser ist. Ende offen 
 wie man sieht.

Und dazwischen sind auch alle Meinungen möglich.

Hast du die Hauptprobleme, die seitdem diskutiert wurden irgendwo
dokumentiert? Oder weißt du, ob es so etwas gibt? Wenn sich diese
Diskussion immer wieder wiederholt, ist das auch nicht sehr produktiv.
Eure/Unsere Meinungen und Vorschläge würde ich sonst gerne einmal
zusammenfassen.

 Im Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der
 Gehweg dort aufhören und an der Straße ist ein sidewalk=* auch noch
 nicht gemappt.

 Es ging mir um das Problem. Wenn ich es heute noch einmal machen würde,
 dann würde ich den anschließenden Radweg nicht separat erfassen, weil
 es dafür keinen Grund gibt, und dann den Radweg an der Straße enden
 lassen.
 
 Dann stellt sich aber die Frage aber wann ein cycleway=track oder sidewalk=* 
 nicht mehr an die Straßé getagged wird. Bordstein? Rasenfläche? Graben? 
 Geländer?

Graben, Rasenfläche - Trennung
Bordstein, Geländer ist diskutabel, weil es eher auf die Situation ankommt.

 Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer
 dieterdre...@gmail.com:
 da finde ich cycleway/sidewalk=separate_way oder ähnliches besser.



 jein, ich wäre eher für eine Relation, dann ist die
 Zusammengehörigkeit eindeutig. separate_way hat das Problem, dass
 man erstens auch nicht genau weiss, welcher way, und zweitens
 bezieht
 man sich mit einem tag auf einen anderen way, den es zu einem
 späteren Zeitpunkt vielleicht schon gar nicht mehr gibt. Zwar könnte
 man fordern, wer den Gehweg verändert muss halt auch noch die Straße
 anschauen (und auch wenn das im Prinzip schon genau das Problem ist,
 so kann man es für Straßen vielleicht noch tolerieren), aber wenn
 man
 sowas erstmal eingeführt hat (tags die sich auf andere in der Nähe
 liegende, nicht genau spezifizierte/verlinkte Objekte beziehen),
 dann
 verbreitet sich das Prinzip vermutlich noch weiter auf andere Arten
 von Objekten. Das ist ein bisschen so ähnlich wie forward-Angaben
 auf einem Node.

 Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B
 sidewalk=* und Zugehörigkeit zu einer (street-)Realtion nicht
 unbedingt auch einen seperat eingezeichneten Gehweg haben müssen.
 D.h. ein Datenauswerter müsste erst nachsehen ob die (street-)
 Relation zu der die Straße gehört und dann ob in der Relation auch
 noch ein Mitglied ist, welches ein Gehweg ist. Das klingt für mich 
 kompliziert bis unmöglich.

 Und wenn er dann nachgeschaut hat, entscheidet er ob z.B. cycleway=lane
 oder sidewalk=right an dieser Stelle nun gerendert wird.
 
 Hast du da mal ein Beispiel, wie das gehen soll, mit OsmAnd, Maperitive und 
 Tilemill sehe ich da keine Chance das hinzubekommen. Und das Problem des 
 separaten/doppelten mappens entsteht bei Radwegen ja maximl bei 
 cycleway=track/opposite_track. =lane wird ja unbestritten (glaub ich) an die 
 Straße gemappt.

Ich musste jetzt auch lange nachdenken, was ich damit sagen wollte,
entschuldige! Ich habe in diesem Zusammenhang beim Rendern irgendein
weiteres Problem vermutet.

 Weil es dabei auch noch auf die Seite ankommen könnte, wäre vielleicht
 ein

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

2014-12-19 Diskussionsfäden 715371

Am 19.12.2014 um 23:58 schrieb Hubert:
 Hallo,
 ich habe einmal auf meiner Wiki Seite 
 (https://wiki.openstreetmap.org/wiki/User:Hubert87/DoubleRepresentation) ein 
 paar mögliche Kombinationen niedergeschrieben. Ich bitte um viel Feedback auf 
 der entsprechenden Diskussionsseite.
 
 Außerdem:
 Am Donnerstag, 18. Dezember 2014 02:27 schrieb osmu715...@gmx.de:
 Was dann aber noch fies bleibt, sind solche Wege die erst
 straßenbegleitend sind und dann nicht mehr (weil deutlich zu weit weg).

 https://www.openstreetmap.org/way/202894636
 
 Ja, solche Dinge sind wirklich schwierig zu entscheiden. 


 Das muss der Mapper Vor Ort entscheiden. Mir hilft immer die Frage, ob es von 
 der Rennleitung Ärger geben würde, wenn man dort auf der Straße fährt/geht, 
 Benutzungspflicht vorrausgesetzt.

Die Benutzungspflicht ist ja nur bei separatem highway relevant. Wenn
man cycleway=* benutzt hat Benutzungspflicht eine deutlich geringere
Bedeutung (es gibt noch nicht einmal einen Tag dafür - soweit mir bekannt).

 
 Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu
 vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde.
 
 Ich finde genau in solchen Fällen hätte das doppelte Erfassen seine Stärke. 

Na ja. Das problem, das hier gelöst wird entsteht doch nur durch das
doppelte Erfassen.

 Im Moment sieht es ja (auf der Hauptkarte) so aus, als würde auch der Gehweg 
 dort aufhören und an der Straße ist ein sidewalk=* auch noch nicht gemappt.

Es ging mir um das Problem. Wenn ich es heute noch einmal machen würde,
dann würde ich den anschließenden Radweg nicht separat erfassen, weil es
dafür keinen Grund gibt, und dann den Radweg an der Straße enden lassen.

 
 Am Donnerstag, 18. Dezember 2014 18:42 schrieb fly 
 lowfligh...@googlemail.com:
 da finde ich cycleway/sidewalk=separate_way oder ähnliches besser.
 
 Ich glaube, so arbeitet das Lübecker Schema bei seperat gemappten Radwegen. 
 Dort wird aus dem cycleway=track dann ein cycleway=sidepath. Das ist zwar 
 ein gangbarer Weg, hat für mich aber dann einen Nachgeschmack, wenn das 
 gemacht wird, um das Einzeichnen von doppelten Linien (auf opencyclemap.org) 
 zu verhindern. Wenn es allerding gemacht wird, da es sich aus einem höherem 
 Schema so ergibt, dann ist es (auf einmal) Ok.

Ich halte beides für nicht so gelungen. cycleway=* ist für mich ein Key
mit dem man die Fahrradinfrastruktur an der Straße erfasst und würde es
so verstehen, dass es zwei Radwege dort gibt, wenn es an der Straße
einen cycleway=* gibt und daneben noch einen
highway=path/cycleway/(footway).

Daher sollte man IMHO für so etwas etwas anderes verwenden.

Was in dem Kontext halt auch ungünstig ist: Die Bedeutung von footway=*
ist nicht analog zu cycleway=*. cycleway eine weitere Bedeutung zu
geben, macht es nicht einfacher.

 Am Donnerstag, 18. Dezember 2014 18:52 schrieb Martin Koppenhoefer 
 dieterdre...@gmail.com:
 da finde ich cycleway/sidewalk=separate_way oder ähnliches besser.



 jein, ich wäre eher für eine Relation, dann ist die Zusammengehörigkeit
 eindeutig. separate_way hat das Problem, dass man erstens auch nicht
 genau weiss, welcher way, und zweitens bezieht man sich mit einem tag
 auf einen anderen way, den es zu einem späteren Zeitpunkt vielleicht
 schon gar nicht mehr gibt. Zwar könnte man fordern, wer den Gehweg
 verändert muss halt auch noch die Straße anschauen (und auch wenn das
 im Prinzip schon genau das Problem ist, so kann man es für Straßen
 vielleicht noch tolerieren), aber wenn man sowas erstmal eingeführt hat
 (tags die sich auf andere in der Nähe liegende, nicht genau
 spezifizierte/verlinkte Objekte beziehen), dann verbreitet sich das
 Prinzip vermutlich noch weiter auf andere Arten von Objekten. Das ist
 ein bisschen so ähnlich wie forward-Angaben auf einem Node.
 
 Ein Problem mit Relationen sehe ich auch darin, das Straßen mit z.B 
 sidewalk=* und Zugehörigkeit zu einer (street-)Realtion nicht unbedingt auch 
 einen seperat eingezeichneten Gehweg haben müssen. D.h. ein Datenauswerter 
 müsste erst nachsehen ob die (street-)Relation
zu der die Straße gehört und dann ob in der Relation auch noch ein
Mitglied ist, welches ein Gehweg ist. Das klingt für mich kompliziert
bis unmöglich.

Und wenn er dann nachgeschaut hat, entscheidet er ob z.B. cycleway=lane
oder sidewalk=right an dieser Stelle nun gerendert wird.

Weil es dabei auch noch auf die Seite ankommen könnte, wäre vielleicht
ein ganz anderer Tag als bisher vorgeschlagen besser. Z.B.
separate_cycletrack=left/right/both
und analog das für footway
separate_sidewalk=left/right/both

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

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

2014-12-19 Diskussionsfäden 715371



Am 09.12.2014 um 13:17 schrieb Hubert:
 Ich kenne ein paar (eche/reine) Radwege, welche mit highway=cycleway getaggt 
 sind. Allerdings habe ich Bauchschmerzen, enge Bordsteinradwege mit 
 highway=cycleway + cycleway=sidewalk/crossing zu taggen. Das sieht dann doch 
 sehr seltsam aus, auch wenn es unter einem systematischen Gesichtspunkt 
 logisch wäre.

Mir fehlt hier noch die Diskussion weshalb man nun etwas separat
erfassen sollte bzw. nicht.

Ein Bordstein ist zwar eine bauliche Trennung, aber man kann sie
erwarten und stellt für Radfahrer kein Hindernis dar, wenn an den zu
erwartenden Stellen (z.B. Mündungen von anderen Straßen) die Bordsteine
abgesenkt sind. Oder das zumindest so vorkommt, so dass man die
straßenbegleitenden Wege ohne Komplikationen befahren kann.

Bei Rollstuhlfahrern mag das anders aussehen. Ich finde aber, dass man
(in D-Land) eher als default annehmen sollte, dass alles
Rollstuhlfahrergerecht ist und Rollstuhlfahrer an z.B. einer Kreuzung
oder Einmündung alles machen können. Wenn das nicht der Fall sein
sollte, sollte man sich nach einem Tagging umschauen oder ggf. eine
Relation einführen, die der restriction-Relation ähnelt.

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

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

2014-12-17 Diskussionsfäden 715371

Am 17.12.2014 um 15:05 schrieb Martin Koppenhoefer:
 Am 17. Dezember 2014 um 02:17 schrieb 715371 osmu715...@gmx.de:

 Wird
 der Gehweg an Stellen, wo keine im Detail keine Bordsteintrennung
 besteht,
 dann mit der Straße vereint?

 Wie meinst du das?

 
 
 ohne das erste keine ;-)

Entschuldige, ich stand auf dem Schlauch. :) Wenn ich das richtig
verstehe, dass aus einer geraden Straße dann ein Zick-Zack-Weg daraus
wird, wäre ich eher für eine area-relation. ;)

Ich hatte das bisher immer so gelöst, dass dann wirklich ein Weg zur
Straße führt. Allerdings bei Radwegen und nur dort, wo es einen
Unterschied gemacht hatte. Allgemein bei abgesenktem Bordstein, würde
ich das dann auch so machen. Ich wüsste nicht was dagegen spricht.

 Wenn nur noch eine Bordsteintrennung besteht werden die Wege an die
 Straße angeschlossen und mit sidewalk bzw. cycleway weiter getaggt.
 
 ach so, ich hatte den Thread bisher so gelesen, dass eine Bordsteintrennung
 schon als getrennt interpretiert wird, und mich dann auf Stellen bezogen,
 wo der Bordstein verschwindet bzw. bündig ist mit Straße und Gehweg. Das
 kommt gelegentlich mal vor, ist aber nicht besonders üblich (normalerweise
 reduziert sich nur die Bordsteinhöhe, Stichwort abgesenkt).

Ich würde oben die Modelle mischen, weil ich dort nicht am Bordstein
trenne.

Ich glaube aber, dass man Gehwege hinter abgesenkten Bordsteinen
weiterhin als eigenen Weg erfassen würde und dann mit einem orthogonalen
Weg zur Fahrbahn verbinden würde.


 IMHO: Bordsteintrennungen zu erfassen ist nicht besonders sinnvoll.
 Meist sind die Verkehrsanlagen so gebaut, dass man an den passenden
 Stellen die Straße überqueren kann.
 
 naja, gerade da, wo die Verkehrsanlagen aus irgendeinem Grund nicht optimal
 gebaut sind, würde man ja von solchen gemappten Details profitieren, z.B.
 beim Routing. Man sollte hier auch im Hinterkopf behalten, dass OSM ein
 weltweites Projekt ist.

OK. Das Problem ist soweit noch unklar. Aber ich denke, dass man es mit
dem Taggen an die Straße auch probieren kann:

Wenn man einen nicht abgesenkten Bürgersteig auf der rechten Seite hat
und von der linken Seite eine Straße mündet. Könnte man entweder durch
Tags ergänzend zum Bürgersteig sagen, dass der Bordstein auf dem Stück
auf der rechten Seite nicht abgesenkt ist. Der Algorithmus nimmt dann
die Kante und sagt, wenn der Wert bis zum Abbiegen da ist, kann man den
Bürgersteig mit entsprechenden Verkehrmitteln (z.B. Rollstuhl) nicht
benutzen.

Ansonsten würde ich zumindest in D-land davon ausgehen, dass
Bürgersteige abgesenkt sind, wenn man in eine andere Straße abbiegen möchte.

 . Aus meiner Sicht ist es die Frage, ob für Radfahrer oder
 Fußgänger bereits Bordsteine Grund für separate Erfassung sind.
 
 
 
 ja genau. Ich halte es persönlich so, dass ich mich nicht darum kümmere,
 vor allem nicht im Graphen-Modell (highway-key), also die Fußwege als
 implizitiert durch die Straße sehe (weil man eben auch an jeder Stelle
 queren kann, zumindest physisch*, als Erwachsener ohne besondere
 körperliche Andersartigkeit). Da es aber einige Mapper gibt, die das anders
 sehen, muss man sich zwangsläufig damit auseinandersetzen ;-)

+1

 Wenn es ums Flächenmappen (von Wegen/Straßen) geht, dann würde ich auf
 jeden Fall Gehweg und Straße getrennt erfassen.

Na ja. Fahrspuren erfasst man ja auch nicht getrennt, obwohl man kurz
vor der Ampel nicht mehr wechseln kann.

Getrennt erfassen hat aber gerade dann Probleme (was das Modell
anbelangt), sobald es immer wieder Verbindungen zwischen zwei Spuren
gibt. Siehe z.B. Verkehrsinseln und Mehrzweckspur in der
Fahrbahnmitte. Das ist exotisch, aber bei Gehwegen ist es aus meiner
Sicht einigermaßen analog.

 * Verkehrsrechtlich sieht es wohl so aus, dass man theoretisch innerhalb
 von x Metern von einem gekennzeichneten Fußgängerüberweg, diesen verwenden
 muss.

Das wäre aus meiner Sicht aber in keinem Modell ein Problem, dass man
nicht einfach umsetzen kann: Nähe nächstes crossing=*  x. Und dann
weiß man ob man an der Stelle so rüber darf. Es gibt sonst ja auch Wege,
die einem quasi das überqueren nahelegen, wo allerdings nur zwei
gegenüber liegende Straßen aufeinandertreffen. Genauso ist das dann
auch, wenn es keinen Knoten gibt.

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

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

2014-12-17 Diskussionsfäden 715371

Am 17.12.2014 um 15:11 schrieb Martin Koppenhoefer:
 das ist so viel doppelte Erfassung, wie z.B. amenity=bank, atm=yes auf
 einem Objekt und amenity=atm auf einem anderen darinliegenden doppelte
 Erfassung ist. Das eine Tag an der Straße sagt: die Straße hat einen
 Gehweg, das andere Tag auf dem Fußweg sagt: ich bin ein Fußweg.

Zwei Geldautomaten. Zumindest in der Hälfte aller Möglichkeiten.

Das Zuordnungsproblem könnte es bei zwei Banken nebeneinander zumindest
auch theoretisch...

Aber ehrlich gesagt, würde ich es daran nicht scheitern lassen.

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

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

2014-12-17 Diskussionsfäden 715371

Moin,

Am 18.12.2014 um 01:35 schrieb Hubert:
 Nur weil die in der Nähe liegende Straße einen Fußweg auf der Seite
 hat, wo auch ein Fußweg separat gezeichnet ist, bekommt man noch keine
 eindeutige Zuordnung in allen Fällen
 
 Eine direkt Zuordnung ist m.M. nach auch garnicht nötig, damit zumindest
 Renderer und Router das vernünftig hinbekommen. Bei echten eigenständigen
 Wegen würde ja das footway=sidewalk am Gehweg fehlen und an der Straße auch
 kein sidewalk=* gemappt werden. 

Was dann aber noch fies bleibt, sind solche Wege die erst
straßenbegleitend sind und dann nicht mehr (weil deutlich zu weit weg).

https://www.openstreetmap.org/way/202894636

Daher ist es aus meiner Sicht schwer die beiden Modelle miteinander zu
vereinen, auch wenn ich gerade das an Huberts Ansatz gut finde.

Möglicherweise ist der Punkt aber auch nicht so wichtig, weil das beim
Rendern vielleicht niemanden interessiert.

Zum Routen bräuchte man dann aber wieder alle Typen, weil sonst Inseln
entstehen können.

 Am Mittwoch, 17. Dezember 2014 22:27 schrieb 715371 osmu715...@gmx.de:
 Ich hatte das bisher immer so gelöst, dass dann wirklich ein Weg zur
 Straße führt. Allerdings bei Radwegen und nur dort, wo es einen
 Unterschied gemacht hatte. Allgemein bei abgesenktem Bordstein, würde
 ich das dann auch so machen. Ich wüsste nicht was dagegen spricht.
 
 +1. Ich denke hier z.B. an T-Kreuzungen, wo ich das so machen. Bei absenkten
 Bordsteinen hat man in den meisten Fällen ja eine Ausfahrt, die man mappen
 könnte, oder es ist tatsächlich ein Überqeurungs an genau der Stelle
 vorgesehen.

Ausfahrten verdichten auf jeden Fall schon die Wechselmöglichkeiten
sehr. Die könnte man auch mit geringerer Fehlerquote vom Luftbild
erfassen. Wenn man eine Gegend zu kennen glaubt, könnte das dann schon
ausreichen.

Gute Nacht
Tobias

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

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

2014-12-16 Diskussionsfäden 715371

Moin,

Am 16.12.2014 um 13:13 schrieb Martin Koppenhoefer:
 evtl interessiert auch die area relation in diesem Zusammenhang.

Solche Relation an jeden Radweg zu machen wäre auf jeden Fall sehr
aufwändig.

 Wie machen die Leute, die die Fußwege explizit mappen, das eigentlich mit
 den anderen Attributen der Straße? Name, ref, oneway, wikipedia, etc.? 


 Ist width auf dem highway=straße die Breite mit Gehweg oder ohne? 

Bei mir würde sich das analog zu lanes auf die Fahrbahn beziehen. Die
Summe der Breiten ist aus meiner Sicht nicht wichtig, wenn man aus den
Einzelwerten auch auf die Summe schließen kann. Auch wenn man das mit
JOSM aus meiner Sicht hinreichend einfach erfassen kann, habe ich das
noch nicht viel gemacht - und werde ich wohl auch erst einmal nicht.

Die Auffassung darüber wird aber sehr unterschiedlich sein. Es gibt
Mapper, die bei highway=cycleway für die Radwegbreite width benutzen,
was OK wäre, wenn derselbe Weg nicht auch nocht den Gehweg
identifizieren würde.

 Wird
 der Gehweg an Stellen, wo keine im Detail keine Bordsteintrennung besteht,
 dann mit der Straße vereint?

Wie meinst du das?

Wenn nur noch eine Bordsteintrennung besteht werden die Wege an die
Straße angeschlossen und mit sidewalk bzw. cycleway weiter getaggt.

IMHO: Bordsteintrennungen zu erfassen ist nicht besonders sinnvoll.
Meist sind die Verkehrsanlagen so gebaut, dass man an den passenden
Stellen die Straße überqueren kann. Ähm, ich meine natürlich das ist
total sinnvoll und ich würde gerne einen Tag für Schlaglöcher
vorschlagen: barrier=pothole ;)

 Ich verstehe zwar schon den Vorteil, wenn man einzelne Wege zeichnet
 (intuitiver, geometrische Details lassen sich anders gar nicht abbilden,
 abweichende Surface und maxspeed Angaben sind einfacher zu mappen, etc.),
 aber es gibt so oder so an manchen Stellen Brüche (in der Logik/Konsistenz).

Genau. Diese Brüche in den Modellen gibt es bei (eigentlich) jedem
Modell. Aus meiner Sicht ist es die Frage, ob für Radfahrer oder
Fußgänger bereits Bordsteine Grund für separate Erfassung sind.

LG

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

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

2014-12-16 Diskussionsfäden 715371

Am 16.12.2014 um 23:28 schrieb Hubert:
 Das Problem mit der Zuordnung der Fußwege zur Straße, bzw. umgekehrt empfinde 
 ich als nicht so extrem. Über sidewalk=right/left/both bekommt man das schon 
 hin. 

Aber das ist doch doppelte Erfassung. Wobei es natürlich stimmt, dass
man einen Tag an beiden Wegen benötigt.

 Allerdings hat man spätestens dann doppelte (eigntlich dann vierfache) 
 Arbeit, wenn man aus Rücksicht auf den Datenauswerter andere Tags verwenden 
 möchte. (z.B. statt sidewalk=* footway:*=sidewalk, wo ich mir dabei noch 
 nicht sicher bin.)

Die Arbeit sollte man sich machen. Es wäre tatsächlich schöner, wenn die
Relation besser unterstützt würde. wikipedia, name, old_name etc sind
schon ein ganz guter Grund.

Aber weil es so aufändig ist, sollte man sich beim separaten Erfassen
IMHO auch auf die wirklich getrennten Rad- und Fußwege beschränken.

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

Re: [Talk-de] Bearbeitung von Landnutzungen im ländlichen Raum.

2014-12-16 Diskussionsfäden 715371

Am 13.12.2014 um 09:39 schrieb Martin Koppenhoefer:
 tendenziell sollte es keine gemeinsamen Nodes zwischen Flächen und Flüssen 
 oder Straßen im Linienmodell geben (beides kann auch zusätzlich als Fläche 
 gemappt werden wo Verbindungen dann Sinn machen)

+1

Was vielleicht auch noch wichtig ist: Benutze JOSM, da kannst du mit Alt
+ X Flächen entlang eines Weges aufteilen.

Größere Straßen können auch mal von jeder Art landuse ausgespart werden.
Der landuse sollte dann entlang von Grundstückgrenzen gemappt werden.
Manchmal sind das Zäune, Hecken etc

natural kann auch überlappend auf einem landuse sein. Aber da gab es vor
ein paar Monaten noch sehr unterschiedliche Meinungen drüber.

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

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

2014-12-10 Diskussionsfäden 715371

Moin,

Am 10.12.2014 um 16:37 schrieb Hubert:
 Entschuldigung für die lange Antwort und ich hoffe die Formatierung passt 
 dieses mal.

Bei mir ebenso. ;)

 Am Dienstag, 9. Dezember 2014 17:55 schrieb 715371 osmu715...@gmx.de:
   Mit Taginfo kann man folgende Zahlen ermitteln:
   
   Separat erfasst:
   footway=sidewalk   143 686
   footway=crossing86 541
   
   An Straße erfassst:
   sidewalk=none  222 954
   sidewalk=both  143 254
   sidewalk=right  63 796
   sidewalk=left   30 027
   ...
   footway=both12 357
   ...
   
   Wenn man sich vor Augen führt, wie stark segmentiert das separate
   Erfassen ist, kann man footway=crossing auch weglassen und
   footway=sidewalk wenigstens halbieren, weil auf ein sidewalk=both etwa
   zwei highway=footway gerechnet werden müssen.
 
 Hmm. Ich hätte jetzt eine andere Schlussfolgerung gezogen, nämlich dass man 
 die Zahlen bei sidewalk=* verringern müsste und zwar Aufgrund von 
 Wegtrennungen durch turn:lanes, parking:lane, maxspeed, etc.
 Einen Faktor mag ich jedoch nicht abschätzen.

Vielleicht kann man die Segmentierung bei separaten Wegen ja durch
footway=crossing abschätzen. Das könnte die Zahl der separat erfassten
Wege noch einmal verringern.

Aber ich kenne auch viele separat erfasste Wege die länger sind als die
dazugehörigen Fahrbahnwege.

Es bleibt irgendwie schwer zu vergleichen.

   Alle übrigen Wege, die nicht diese Tags haben, haben keine weitere
   Berücksichtigung verdient - weil sie falsch getaggt sind.
   
   Allerdings ist die Qualität der Beiträge, die ich gesehen habe, nicht
   ausreichend. Meistens fehlen Verbindungen zwischen Fahrbahn und
   straßenbegleitenden Wegen. Ich habe das an sehr vielen Stellen
   festgestellt. Es ist eben nicht einfach mal eben damit getan einen Weg
   einzuzeichnen und ihn richtig zu taggen.
 
  + 1. Da Stimme ich dir voll zu. Das korregiert man dann einfach. Ich sag nur 
 highway=road

Stimmt. So funktioniert OSM. Es ist nicht beim ersten Mal erfassen schon
komplett etc

   Aus meiner Sicht müsste ein Schema einen einfachen Zugang anbieten.
   Das tut es nicht. Es macht nur alles komplizierter und aufwändiger.
   Wenn man es an die Straße taggt ist das nicht so.
 
 Ja stimmt, aber man hat auch weniger Informationen. Ich denke man sollte die 
 Sache sequenziel aufbauen. Einer fängt einfach an, und nach und nach wird es 
 mehr (und leider auch komplizierter).
 Im speziellen Fall schwebt mir als Kompromis eine Art Doppelrepresentation 
 vor. Also sowohl sidewalk=* als auch highway=footway + footway=sidewalk. Wie 
 genau das ausehen kann, muss noch diskutiert warden. Das seperate Eintragen 
 einfach zu untersagen, ist natürlich die einfachere Lösung.

Eine Doppelrepräsentation würde das Problem mit dem Rendern lösen, das
ich für wichtig halte.

So richtig elegant finde ich das nicht. Und es gibt auch einige Mapper,
die das komplett ablehnen. Zumindest habe ich das in den Diskussionen zu
den Proposals von damals gelesen.

 In der Forum Diskussion wurde eine Möglichkeit vorgestellt, wie ein Router 
 bei highway=footway + footway=sidewalk durch schlagen von Orthogonalen alle x 
 Meter eine ständige Querungsmöglichkeit schafft.

Wobei dann auch solche Dinge wie barrier=retaining_wall/fence etc
berücksichtigt werden müssten. Wenn jemand z.B. keine turn-restriction
gemappt hat, weil er es ja separat eingezeichnet hat und es deshalb
nicht geht, würde das sonst zu Fehlern führen - so würde ich mir das
ad-hoc vorstellen.

   Vom Ansatz her ist es aus meiner Sicht zu detailliert, wenn man die
   Bordsteinkante als Anlass für einen eigenen Weg nimmt. Es wäre
   eleganter zu sagen, dass dort ein Bürgersteig ist (mit sidewalk=both).
   In der Praxis gibt es unvorhersehbare Probleme, die das Problem einer
   Bordsteinkante übertreffen (siehe oben).
 
 Da bin ich anderer Meinung. Klar gibt es Probleme, aber die kann man zu 
 lösen. Das Versuche ich hier. Ich halte es für besser eine Nachfrage (hier 
 das seperate Mappen) zu befriedigen, als etwas zu verbieten. Das Eintragen 
 von als sidewalk=* ist aus meiner Sicht nur eine unzureichende Möglichkeit.

OK. Es kommt definitiv auf die Situation an. Wenn eine Straße nur einen
Bürgersteig hat, dann genügt sidewalk=*.

Wenn der Fußweg von der übrigen Anlage getrennt ist, kann es sich
hingegen lohnen, die Wege separat einzuzeichnen.

Deshalb wäre es wohl auch nicht im Sinne der OSM separates erfassen
generell zu verbieten, sondern nur in bestimmten Situationen.

   Auf höheren Zoomstufen erkennt man nur noch Radwege - keine
   Straßennamen oder überhaupt den Unterschied zwischen eigenständigen
   Wegen und Straßenbegleitenden. Als Radfahrer ist meist mehr als nur
   die Radfahranlage interessant.
  
 Das mit den Straßennamen ist abschicht und der besseren Lesbarkeit 
 geschuldet. Bei den Unterschied der Darstellungen gibt es ab Zoomlevel 17 die 
 straßenbegleitenden highway=path/cycleway und sonst cycleway=* ohne 
 cycleway=track/sidepath. Bei Zoomlevel 15/16

[Talk-de] building=boat/ship [was Re: cycleway=track bei Bordstein Trennung]

2014-12-10 Diskussionsfäden 715371

Moin,

mir ist in der Diskussion mit Hubert aufgefallen, dass es Boote/Schiffe
gibt, die als building getaggt sind.

Am 10.12.2014 um 16:37 schrieb Hubert:
 Am Dienstag, 9. Dezember 2014 17:55 schrieb 715371 osmu715...@gmx.de:
   Schiffe als Gebäude einzuzeichnen scheint ja laut Wiki OK zu sein -
   auch wenn ich das ein wenig zweifelhaft finde. ;)

 Hängt glaube ich davon ab ob es sich noch bewegt. Es gibt in Rostock
ein paar Museumsschiffe die ständig vor Ankerleigen.
 OT: Und auch dort bleiben solltenm, da sie sonst sinken.
(http://www.spiegel.de/panorama/fahrt-zur-verschrottung-georg-buechner-vor-polen-gesunken-a-902980.html)

Kenne ich aus Bremen auch. Allerdings nur fast immer am selben Ort.
Irgendwann ist eines der Schiffe verlegt worden, die als Gebäude getaggt
sind. Es kommt dann halt doch vor.

Bei Taginfo habe ich keine besseren Tags mit Suche nach ship und boat
gefunden. Bisher werden Schiffe wohl als building=boat oder
building=ship getaggt.

Es wäre aus meiner Sicht schöner so etwas wie man_made=ship/boat zu
benutzen - der building-key ist dafür auf jeden Fall nicht so passend.
Gab es da bisher schon Ansätze? Was haltet ihr davon?

LG
Tobias

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

Re: [Talk-de] Verkehrsinseln und Mehrzweckspur in der Fahrbahnmitte

2014-12-10 Diskussionsfäden 715371

Hallo Tirkon,

Am 10.12.2014 um 17:07 schrieb Tirkon:
 715371 osmu715...@gmx.de wrote:
 
 hast du Koordinaten (für's Luftbild) oder ein Foto?
 Dieser Radweg begleitet den hier in Frage stehenden Straßenabschnitt:
 http://www.openstreetmap.org/way/206038204#map=15/53.4776/7.3942

Ersteinmal würde ich IMHO so Abbiegespuren wie diese hier

https://www.openstreetmap.org/way/260670943

mit turn:lanes (https://wiki.openstreetmap.org/wiki/Key:turn:lanes)
erfassen.

Ansonsten würde ich den Vorschlag von Martin als elegant empfinden.
Durch das Tagging könnte man diese Mittelspur, falls interessant, auch
mal auswerten.

Du könntest es aber aus meiner Sicht bezüglich der Fahrspuren
(zumindest ersteinmal) so lassen.

LG
Tobias

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

Re: [Talk-de] Abbiegespuren mit Fahrradspur

2014-12-09 Diskussionsfäden 715371

Am 09.12.2014 um 08:55 schrieb Martin Vonwald:
 Am 8. Dezember 2014 um 11:55 schrieb 715371 osmu715...@gmx.de:
 
 Am 07.12.2014 um 19:26 schrieb Martin Vonwald:
 Ok. Warum man hier cycleway:width und nicht einfach width verwendet,
 verstehe ich zwar nicht, aber wenn es so sein soll - bitte.

 Weil sich cycleway:width auf den Radweg bezieht
 
 
 Es ist ein highway=cycleway.

... der einen Gehweg mit Radweg - oder umgekehrt - identifiziert.

 und width sich auf den
 gesamten Weg (eingeschlossen Fußweg/Bürgersteig beziehen würde).

 
 Mein Informationsstand ist, dass sich width bei Fahrbahnen immer auf die
 Fahrbahn bezieht und den Gehsteig nicht miteinbezieht.

Der Gehsteig wird auch mit highway=cycleway, foot=designated
beschrieben. Beides ist keine Fahrbahn.

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

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

2014-12-09 Diskussionsfäden 715371



Am 09.12.2014 um 13:17 schrieb Hubert:
 Hallo,
 
 danke für die Antworten.
 
 Am Montag, 8. Dezember 2014 19:34 schrieb fly lowfligh...@googlemail.com:
   Ich habe zumindest path=sidewalk/crossing schon öfter verwendet.
   Reinen cycleways begegne ich äußerst selten.
   
   cu fly
 
 Ich kenne ein paar (eche/reine) Radwege, welche mit highway=cycleway getaggt 
 sind. Allerdings habe ich Bauchschmerzen, enge Bordsteinradwege mit 
 highway=cycleway + cycleway=sidewalk/crossing zu taggen. Das sieht dann doch 
 sehr seltsam aus, auch wenn es unter einem systematischen Gesichtspunkt 
 logisch wäre.

+1

highway=cycleway habe ich auch vor einiger Zeit schon bei
straßenbegleitenden Radwegen benutzt, aber wie schon beschrieben: Es hat
kaum Vorteile und ist kaum fehlerfrei möglich.

 Die Einschätzung würde ich noch teilen. Allerdings kann sich das noch 
 änderen, oder es ändert sich gerade. Ich sehe sehr viele Gegenden, wo es kein 
 sidewalk=* an der Straße gibt, aber der Bürgersteig schon als highway=footway 
 eingetragen ist, allerdings ohne footway=sidewalk

Mit Taginfo kann man folgende Zahlen ermitteln:

Separat erfasst:
footway=sidewalk143 686
footway=crossing 86 541

An Straße erfassst:
sidewalk=none   222 954
sidewalk=both   143 254
sidewalk=right   63 796
sidewalk=left30 027
...
footway=both 12 357
...

Wenn man sich vor Augen führt, wie stark segmentiert das separate
Erfassen ist, kann man footway=crossing auch weglassen und
footway=sidewalk wenigstens halbieren, weil auf ein sidewalk=both etwa
zwei highway=footway gerechnet werden müssen.

Alle übrigen Wege, die nicht diese Tags haben, haben keine weitere
Berücksichtigung verdient - weil sie falsch getaggt sind.

Allerdings ist die Qualität der Beiträge, die ich gesehen habe, nicht
ausreichend. Meistens fehlen Verbindungen zwischen Fahrbahn und
straßenbegleitenden Wegen. Ich habe das an sehr vielen Stellen
festgestellt. Es ist eben nicht einfach mal eben damit getan einen Weg
einzuzeichnen und ihn richtig zu taggen.

 
   In D ist es halt so, dass man als Fußgänger am Straßenrand (außerorts
   dann auch nur auf einem bestimmten), auf dem Bürgersteig oder auf
   einem straßenbegleitenden Gehweg gehen muss (bis auf Ausnahmen wie für
   die Mitführung von Sperrgut etc). Zum anderen müssen Kinder bis 8
   Jahre auf dem Gehweg Radfahren. Rollstuhlfahrer haben nur mit
   Bordsteinkanten ein Problem und von Blinden scheint weder bekannt zu
   sein wie sie sich fortbewegen, noch was beim Routing wichtig für sie
   ist.
   
   Rollstuhlfahrer: Sollten kein Problem mit sidewalk=* haben, weil bei
   solch einem Tagging zu erwarten ist, dass man bei Kreuzungen,
   Hauseinfahrten etc einen entsprechend abgesenkten Bordstein vorfindet.
   Ansonsten wäre ein Beispiel schön.
   
   Blinde: Werden schon irgendwie den Bürgersteig finden, schließlich
   gibt es da ja auch noch andere Probleme wie Passanten, Pfeiler für
   Verkehrsschilder, Fahrradwege.
   Soweit ich das mal gehört habe, sind für Blinde POIs wie Parkbänke
   wichtig.
   
   Normale Fußgänger: Sind die Mehrheit und können mit entsprechendem
   Abstand zur Ampel nahezu überall Straßen überqueren.
 
 Soweit teile ich die Einschätzung. Allerdings ist mir das etwas zu sehr 
 Renderer/Router orientiert. Klar, das sind die beiden wichtigsten Nutzer der 
 Daten, aber die Erfassung sollte dann doch auf höheren Grundlagen 
 stattfinden. 

Aus meiner Sicht müsste ein Schema einen einfachen Zugang anbieten. Das
tut es nicht. Es macht nur alles komplizierter und aufwändiger. Wenn man
es an die Straße taggt ist das nicht so.

   Fahrradfahrer: Wenn man das weiter Spinnt, kommt man bei Radfahrern zu
   dem Problem, dass sie überwiegend auf beiden Seiten Einbahnstraßen
   vorfinden und beim Routing dann große Umwege genommen werden, bis man
   an eine Kreuzung zum Wenden kommt.
 
 Das hängt ganz vom Router ab. Oder vom Radfahren. Bei einem Borstein kann Ich 
 zwar vom Radweg auf die Straße wechseln, nicht aber von der Straße auf den 
 Radweg

Ohne abzusteigen... Der gesamte Bereich müsste für Fußgänger zugänglich
gemacht werden. So ein paar Einfahrten und Kreuzungen genügen da nicht.
Man müsste den Straßenraum als Einheit, als gesamtes erfassen. Fußgänger
dürften überall hin und würden nur noch von Barrieren aufgehalten - die
dann zusätzlich erfasst werden müssen.

Nicht, dass ich mir so etwas wünschen würde.

   IMHO ist es in Städten mit engen Straßen absurd Bürgersteige saparat
   zu erfassen. Dauernd parkt jemand wo er nicht darf den Radweg zu
   (Autos Fahrräder etc), Bürgersteige sind für Kinderwagen zu eng, weil
   Autos dort illegal parken (oder zwei Passanten passen nicht
   nebeneinander), Bordsteinkanten sind weder als abgesenkt noch als
   Normales Hindernis erkennbar usw. Also macht es bitte nicht zu
   kompliziert!
 
 Gab es nicht mal fälle wo Schiffe usw. eingezeichnet wurden? So ganz kann ich 
 der Argumentation nämlich nicht folgen. Soll man denn an den Stellen gar 
 keinen

Re: [Talk-de] Abbiegespuren mit Fahrradspur

Am 07.12.2014 um 19:26 schrieb Martin Vonwald:
 Ok. Warum man hier cycleway:width und nicht einfach width verwendet,
 verstehe ich zwar nicht, aber wenn es so sein soll - bitte.

Weil sich cycleway:width auf den Radweg bezieht und width sich auf den
gesamten Weg (eingeschlossen Fußweg/Bürgersteig beziehen würde).

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

Re: [Talk-de] Abbiegespuren mit Fahrradspur

Am 07.12.2014 um 19:26 schrieb Martin Vonwald:
 Hi!
 
 Am 6. Dezember 2014 um 02:04 schrieb 715371 osmu715...@gmx.de:
 
 Was ist eigentlich mit solch einem Problem:


 https://wiki.openstreetmap.org/wiki/File:Bremen_street_with_cycleway_lane_between_car_lanes.jpg

 turn:lanes=left|through|cycleway:through|right ?

 
 Bitte fangt nicht an, die Bedeutung von turn zu verändern. Im Beispiel wäre
 es turn:lanes=left|through|through|right +
 bicylce:lanes=...|...|designated|yes

BTW: Wie würdet ihr den Radweg am Gehweg erfassen? Eigener Weg oder
cycleway=track? Wobei letzteres nicht geht, weil ja schon cycleway=lane.

Was, wenn der cycleway=track nur durch Bordstein von der Fahrbahn
getrennt wäre?

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

Re: [Talk-de] Abbiegespuren mit Fahrradspur



Am 08.12.2014 um 16:42 schrieb Hubert:
 Hallo,
 
 Am 8. Dezember 2014 12:05 schrieb 715371 osmu715...@gmx.de:
   BTW: Wie würdet ihr den Radweg am Gehweg erfassen? Eigener Weg oder
   cycleway=track? Wobei letzteres nicht geht, weil ja schon
   cycleway=lane.
 
 Ich würde dort den Radweg seperat mit highway=cycleway/path + ... eintragen 
 und den Radfahrsteifen als cycleway=lane.
 (Alternative kann ich mir auch cycleway:right=lane;track vorstellen, wobei 
 ich bezweifel, dass das Richtig interpretiert wird.
 Oder auch cycleway:lanes=...|...|lane|... und cycleway:right=track)

Wenn es keinen Grünstreifen gäbe, wäre die highway-Lösung aus meiner
Sicht nicht unbedingt OK.

Was ich mir wünschen würde, wäre ein gescheites Tagging für
cycleway=lane;track. Man kann natürlich sagen, dass lane irgendwo auf
die Fahrbahn gehört. Genauer könnte man das dann mit
bicycle:lanes=...|... sagen. Und man könnte auch sagen, dass
cycleway=track neben die Fahrbahn gehört. Vielleicht wäre das eine Lösung.

BTW: Mit einem anderen Mapper sammle ich in Bremen zZ noch Beispiele:
https://wiki.openstreetmap.org/wiki/Bremen/Radverkehrsanlagen

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

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

Moin,

Am 08.12.2014 um 16:50 schrieb Hubert:
 Hat dort jemand eine Idee. In der genannten Diskussion lief es darauf
 hinnaus, dass 3 Typen von Gehwegen unterschieden werden müssen.
 Eigenständige Gehwege, straßenbegleitende Gehwege mit abgesetzter Führung
 (Grünstreifen, Zaum, o.ä.) und straßenbegleitende Gehwege mit enger Führung,
 aka Bürgersteige (nur durch Bordstein getrennt, wechseln auf die Fahrbahn
 jederzeit möglich).
 Bei Radwegen sehe ich die Problemtik ähnlich gelagert. Meinungen? Gedanken?

Danke Hubert, den Thread kannte ich noch nicht. Deine Analyse würde ich
im groben auch teilen.

Ich habe den Thread grob durchgelesen, aber auch vorher schon eine
ziemlich statische Meinung gehabt - an der hat sich eigentlich nichts
geändert.

Eigenständige Gehwege - eigener Weg
Straßenbegleitende Gehwege mit abgesetzter Führung - (*)
Straßenbegleitende Wege mit enger Führung - sidewalk=*

(*) Entscheidend ist: Was ist die Trennung?
Bordstein - sidewalk=*
Parkstreifen - sidewalk=*
Grasstreifen mit Bäumen - sidewalk=*
Grasstreifen mit mehr 5m Abstand von Fahrbahn - eigener Weg
Grünstreifen aus Sträuchern - eigener Weg
Zaun - eigener Weg

Und was eine Hand voll Bordstein-Bürgersteigmappern schon selber erkannt
hat: Es geht nicht ohne foot=use_sidepath.

Soweit ich das Konzept für Gehwege an die Straße Taggen überblicke, wäre
es doch auch dort denkbar auf einzelne Personengruppen eingehen zu können.

Ansonsten habe ich den Eindruck, dass die Mehrheit gegen das separate
Erfassen ist, wenn es nur eine Bordsteintrennung gibt. Könnte man das
nicht entsprechend deprecaten?

In D ist es halt so, dass man als Fußgänger am Straßenrand (außerorts
dann auch nur auf einem bestimmten), auf dem Bürgersteig oder auf einem
straßenbegleitenden Gehweg gehen muss (bis auf Ausnahmen wie für die
Mitführung von Sperrgut etc). Zum anderen müssen Kinder bis 8 Jahre auf
dem Gehweg Radfahren. Rollstuhlfahrer haben nur mit Bordsteinkanten ein
Problem und von Blinden scheint weder bekannt zu sein wie sie sich
fortbewegen, noch was beim Routing wichtig für sie ist.

Rollstuhlfahrer: Sollten kein Problem mit sidewalk=* haben, weil bei
solch einem Tagging zu erwarten ist, dass man bei Kreuzungen,
Hauseinfahrten etc einen entsprechend abgesenkten Bordstein vorfindet.
Ansonsten wäre ein Beispiel schön.

Blinde: Werden schon irgendwie den Bürgersteig finden, schließlich gibt
es da ja auch noch andere Probleme wie Passanten, Pfeiler für
Verkehrsschilder, Fahrradwege.
Soweit ich das mal gehört habe, sind für Blinde POIs wie Parkbänke wichtig.

Normale Fußgänger: Sind die Mehrheit und können mit entsprechendem
Abstand zur Ampel nahezu überall Straßen überqueren.

Fahrradfahrer: Wenn man das weiter Spinnt, kommt man bei Radfahrern zu
dem Problem, dass sie überwiegend auf beiden Seiten Einbahnstraßen
vorfinden und beim Routing dann große Umwege genommen werden, bis man an
eine Kreuzung zum Wenden kommt. Wenn da jetzt wer etwas implementiert,
dass eine Pseudo-Verbindung zwischen Rad-/Gehweg und Straße
interpoliert, würde ich gerne genauer wissen wie Fehleranfällig das ist.
Außerdem dürfen Radfahrer in D per default auf der Straße fahren.

IMHO ist es in Städten mit engen Straßen absurd Bürgersteige saparat zu
erfassen. Dauernd parkt jemand wo er nicht darf den Radweg zu (Autos
Fahrräder etc), Bürgersteige sind für Kinderwagen zu eng, weil Autos
dort illegal parken (oder zwei Passanten passen nicht nebeneinander),
Bordsteinkanten sind weder als abgesenkt noch als Normales Hindernis
erkennbar usw. Also macht es bitte nicht zu kompliziert!

Renderer: Vielleicht ist ja schon einmal bei der opencyclemap.org
aufgefallen, dass die Renderer prinzipiell ein Problem mit separaten
Wegen haben. Bei niedrigen Zoomstufen wandern die separat
eingezeichneten Radwege zur Mitte der Straße und sehen nicht
professionell aus:
https://osm.org/#map=14/53.0912/8.7965layers=C
Bei niedrigen Zoomstufen kann man dann ohne Luftbild oder Ortskenntnis
einfach nicht mehr erkennen, ob zwischen Straße und Gehweg eine Hecke
steht oder nicht - kann ich da gerade jemanden Absetzen? (Das ist auch
das Niveau auf dem andere hier argumentieren).
https://osm.org/#map=18/53.08995/8.78780layers=C

Analog zu den turn:lanes, lanes usw. Sollte es auch bei Bürgersteigen
und Radwegen gemacht werden. Bei motorisierten Fahrzeugen scheint das
mit baulicher Trennung ja wohl auch relativ verständlich zu sein.

LG
Tobias

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

Re: [Talk-de] Verkehrsinseln und Mehrzweckspur in der Fahrbahnmitte

Hallo Tirkon,

hast du Koordinaten (für's Luftbild) oder ein Foto?

Am 09.12.2014 um 00:44 schrieb Tirkon:
 Sie wird immer wieder durch bepflanzte
 Verkehrinseln unterbrochen, wobei teilweise eine Überquerungshilfe für
 Fu0gänger/Radfahrer eingebettet ist. 

Das klingt nach baulicher Trennung. Daher tendiere ich zu den separat
eingezeichneten Wegen pro Fahrtrichtung.

 Die Mehrzweckspur dient laut Presse
 zum Ein- und Ausfädeln von Linksabbiegern auf/von
 Grundstückseinfahrten und kleinen Nebenstraßen sowie zum
 gelegentlichen Überholen. 

Überholen klingt irgendwie nach keiner baulichen Trennung.

Wenn ohnehin von beiden Seiten alle Ziele erreicht werden können, sähe
ich aber auch nichts gegen eine ein-Weg-Lösung.

Ohne mehr Information würde ich mich aber nicht festlegen wollen.

LG
Tobias

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

Re: [Talk-de] Abbiegespuren mit Fahrradspur

2014-12-05 Diskussionsfäden 715371

Moin,

Am 05.12.2014 um 20:48 schrieb Tobias Knerr:
Am 05.12.2014 18:56, schrieb fly:
Am 05.12.2014 um 16:10 schrieb Tobias Knerr:
* Im Sinne unserer damaligen Diskussion, ob left/right nicht besser wäre
als forward/backward: Wie mappe ich Radwege, die in beide Richtungen
nutzbar sind?

Entweder als separaten Weg und bicycle=use_sidepath oder mit einer
Kombination aus left/right + forward/backward.

Ich denke hier natürlich konkret an den Fall, dass ich diesen Radweg in
die *:lanes=* mit einbauen will. Wie habe ich mir diese Kombination
vorzustellen? Es muss ja weiterhin bicycle:lanes:forward/backward
verwendet werden, oder?

Was ist eigentlich mit solch einem Problem:

https://wiki.openstreetmap.org/wiki/File:Bremen_street_with_cycleway_lane_between_car_lanes.jpg

turn:lanes=left|through|cycleway:through|right ?

Analog zu cycleway:lanes*=* kann ich mir auch sidewalk:lanes*=* und
parking:lane:lanes*=* vorstellen

Mein Problem ist hier nur der Umgang mit Barrieren álà kerb oder auch
unterbrochene fence_type=railing

Falls das konsensfähig ist, wäre es natürlich eine schöne Möglichkeit.

Das Problem der Interaktion mit explizit eingetragenen Barrieren gibt es
ja ohnehin auch beim klassischen sidewalk- und parking:lane-Tagging. Und
bei separaten Ways hat man ganz andere, viel größere Probleme...

Würdet ihr Barrieren wie Zäune, die zwischen Fahrbahn und Radweg
(cycleway=track) stehen, als eigene Wege oder Knoten erfassen oder
irgendwie anders? Ich gehe davon aus, dass cycleway=track gemappt ist.

* Zumindest, so lange es nicht ausdrücklich definiert ist, halte ich es
nicht für selbstverständlich, dass die access-Angaben Auswirkungen auf
die Breite etc. haben. Radspuren sind ja nicht dasselbe wie eine Spur
mit voller Breite, die für Radfahrer ist (leider ;-)). Siehst du das anders?

Für die Breite gibt es width:lanes*=*

Das weiß ich. Es geht mir um die Default-Breite, denn wer will schon bei
einem stinknormalen Radweg die Breite taggen?

Gibt es. Z. B. hier:
https://www.openstreetmap.org/way/293395597

LG
715371

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

[Talk-de] Änderungen im Wiki auf DE:Key:cycleway

2014-09-18 Diskussionsfäden 715371

Moin,

mir ist aufgefallen, dass es in der letzten Zeit einige, aus meiner
Sicht fragwürdige, Änderungen an der Wikiseite DE:Key:cycleway gab.

Mal abgesehen davon, dass ich da ohnehin einiges für umständlich
geschrieben halte, beginnt der einleitende Satz/Absatz schon ziemlich
unklar, weil nicht zwischen highway=cycleway und cycleway=*
differenziert wird.

Neu hinzugefügt worden ist z.B.

Als straßenbegleitender Fahrradweg ist ein Radweg definiert, der auf
ganzer Länge im Abstand von unter 5 m neben einer Fahrbahn verläuft.

Gilt das auch international? Ist die Aussage auf dieser Seite relevant?

Ansonsten erinnern mich die neuen Beiträge eher an eine unvollständige
Zusammenfassung einer Diskussion.

Eventuell könnte man dort ja mal aufräumen.

Wie seht Ihr das?

LG
715371

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

Re: [Talk-de] Veggiekarte.de

2014-08-11 Diskussionsfäden 715371

Hi,

Am 11.08.2014 um 14:59 schrieb Tobias Knerr:
 Am 11.08.2014 14:43, schrieb André Riedel:
 Gibt es eigentlich eine Unterscheidung zwischen Viele
 vegetarische/vegane Gerichte und Salat+EinOderZweiAndereGerichte ?
 
 Da kommt es jetzt darauf an, wie man die Definition liest. Es heißt ja
 für yes: full options available (i.e. several proper meals not just
 side salads in restaurants or a baked potato in a pub ...)
 
 Insofern könnte man durchaus argumentieren, dass
 Salat+EinOderZweiAndereGerichte nicht für yes reicht.

Könnte man da nicht noch etwas genauer werden?
yes, falls es in jedem Gang (Getränke eingeschlossen), den der POI
anbietet wenigstens mehr als eine (Auswahl)möglichkeit gibt. So war das
doch bestimmt eigentlich gemeint.

Eine schärfere Regelung für yes würde auch evtl einen weiteren Wert wie
limited oder ähnliches überflüssig machen.

IMHO würde ich es vom Tagging her schöner finden, wenn für yes nur die
Existenz gefordert wird. Also nicht several (was ja mindestens 2
entspricht). So Wörter wie several provozieren hier unnötig Differenzen.

 Zufriedenstellend ist das nicht, denn dann geht der wichtige Unterschied
 zwischen überhaupt keinen Optionen und wenig Optionen verloren. Aber
 wenn man ein minimales Angebot und ein sehr reichhaltiges beide mit yes
 versieht, dann ist das auch nicht ideal.
 
 Eigentlich bräuchte man einen zusätzlichen limited-Wert zwischen no
 und yes.

Ich vermute mal, dass das dann auf Definitionen hinausläuft wie
mindestens die Hälfte aller angebotenen Gerichte/Gänge/Getränke ist
vegetarisch.

LG
715371

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

Re: [Talk-de] Veggiekarte.de

2014-08-10 Diskussionsfäden 715371

Hi,

Am 10.08.2014 um 20:43 schrieb Norbert Kück:
 Das kann gründlich schief gehen: Wenn der vegi-Mapper sich z.B. hier auf
 die Datenbasis verlässt, wird es extrem schwierig:
 http://www.veggiekarte.de/#18/53.07812/8.80108 :-))

Die Datenbasis ist doch OK. Siehe
http://www.scharfrichter-lounge.de/menues/data/12/07/SR_Karte_Jul12web.pdf
bzw.
https://www.openstreetmap.org/node/613437404

Für Vegetarier gibt es sogar zwei Würste! Die kann man wohl mit anderen
Speisen kombinieren.

Daher kann man schon mal diet:vegetarian=yes taggen.
https://wiki.openstreetmap.org/wiki/Key:diet:vegetarian

LG
715371

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

Re: [Talk-de] Veggiekarte.de

2014-08-10 Diskussionsfäden 715371

Am 10.08.2014 um 20:43 schrieb Norbert Kück:
 Das kann gründlich schief gehen: Wenn der vegi-Mapper sich z.B. hier auf
 die Datenbasis verlässt, wird es extrem schwierig:
 http://www.veggiekarte.de/#18/53.07812/8.80108 :-))

+1
Update: Sorry, wer lesen kann... diet:vegetarian, ist IMHO wohl schon
OK, aber das ist ja gar nicht getaggt. Für diet:vegan=yes könnte die
Speisekarte aber deutlich mehr Auszeichnungen bekommen. Und Gerichte:
Von 9 Würsten ist dann nur noch eine vegan.

Es ist IMHO also nicht so klar, ob man nun diet:vegan=yes taggen kann.

LG
715371

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

Re: [Talk-de] Veggiekarte.de

2014-08-10 Diskussionsfäden 715371

Am 10.08.2014 um 22:10 schrieb Norbert Kück:
 am 10.08.2014 21:19 schrieb 715371:
 Speisekarte aber deutlich mehr Auszeichnungen bekommen. Und Gerichte:
 Von 9 Würsten ist dann nur noch eine vegan.
 Ich gestehe, die Speisekarte nicht gelesen zu haben - ich kenne den
 Laden. Man darf zweifeln, ob sich echte Veganer wirklich wohl fühlen,
 wenn sie zwischen diesen Fleischmassen ihre verirrte Veganwurst suchen
 sollen. :-)

Stimmt. :)

Aber die Kombi cuisine=sausage und diet:vegan=yes ist schon bemerkenswert.

Soetwas könnte man ja für eine Empfehlung auch berücksichtigen.

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

Re: [Talk-de] Radweit routen löschen? (WAS: Radweit)

2014-08-05 Diskussionsfäden 715371

Am 05.08.2014 um 17:58 schrieb Henning Scholland:
 Am 04.08.2014 um 21:50 schrieb Michael Reichert:
 Kennt ihr Routenabschnitte von Radweit-Routen, an denen
 Radweit-Aufkleber oder Schilder angebracht sind? Ich würde die nicht
 ausgeschilderten Routen in den nächsten Wochen löschen, da sie nicht der
 Wirklichkeit entsprechen. We map what's on the ground!
 
 Machst du dann gleich bei highway=proposed und anderen Dingen in OSM
 weiter, die nicht On the Ground sind?
 
 Ansonsten fände ich es sehr schade, wenn die Übereinkunft, dass nur
 falsches gelöscht wird und der Rest ungetaggt wird außer Kraft gesetzt wird.

Proposed sollte aber IMHO am besten dann benutzt werden, wenn Gelder
bewilligt sind und nicht noch über Alternativen abgestimmt werden muss.

Sonst: Ist halt auch die Frage woher solche Daten kommen sollen.
Baupläne sind doch bestimmt per se erst einmal nicht Lizenz-kompatibel,
oder?

Wie ist das denn bei Radweit mit der Lizenz? Gibt es da eine? Wenn sie
vom Urheber in die OSM geladen werden, wäre das dann OK? - Finde ich
jetzt nicht unbedingt so klar, würde beim letzten aber auch dazu
tendieren, dass da OK sein müsste.

LG
715371

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

Re: [Talk-de] Radweit

2014-08-01 Diskussionsfäden 715371

Am 01.08.2014 um 14:19 schrieb Sven Geggus:
 Andreas Neumann andr-neum...@gmx.net wrote:
 
 Mal als Frage: Werten die Router pauschal alle route=bicycle aus, oder
 nehmen sie nur bekannt network=* in die Routenplanung mit auf?
 
 Ich denke das muss man die jeweiligen Authoren fragen. Bei brouter kann man
 das (ignore cr) komplett abschalten.  Richards cycle.travel berücksichtigt
 sie nach meinem Gefühl zwar, aber nicht sehr stark.

Der BikeCityGuide bevorzugt Strecken die in einer Relation mit
network=lcn/rcn... sind oder halt lcn/rcn... direkt am Weg haben, weiß
ich aus recht zuverlässiger Quelle.

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

Re: [Talk-de] Radweit (War: Was tu, wenn ein user permanent Daten zerstört?)

2014-07-31 Diskussionsfäden 715371

Am 31.07.2014 um 22:42 schrieb Sarah Hoffmann:
 Also: sobald ulemm seine Fernradrouten durchgehend mit Aufklebern verziert 
 und das auch pflegt, dann können wir diskutieren, ob es nicht Sinn macht,
 die Routen aufzunehmen. Solange sie nur auf seiner privaten Website 
 existieren, ist der Fall aber glasklar: sie gehören nicht in OSM.

Ich will nicht ausschließen, dass es so weit kommt, aber im Moment
scheint er dazu noch nicht in der Lage zu sein.

Vermutlich ändert er die OSM erst einmal so, dass er seine zukünftigen
Routen mit der http://www.hikebikemap.de/ planen kann.

Da fällt mir auch gerade auf, dass die Karte gar nicht cycleway=*
rendert. Was erklären würde weshalb er so strikt gegen das
an-die-Straße-taggen ist.

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

[Talk-de] Was tu, wenn ein user permanent Daten zerstört?

2014-07-30 Diskussionsfäden 715371

Hi,

ich habe bereits hier

http://forum.openstreetmap.org/viewtopic.php?id=26366

und in einer E-Mail an die Data working group auf das Verhalten von dem
user ulamm hingewiesen (von dort habe ich bisher keine Antwort erhalten).

ulamm hat im letzten Monat unzählige Straßen in Bremen editiert und
dabei diverse Fehler produziert. Seine Änderungen sind aus meiner Sicht
sehr eigenwillig. Teilweise orientiert er sich nicht am Wiki und taggt
diverse Objekte um. Dazu zählen dann auch Tags wie highway=bicycle_road.

Da ich ihn inzwischen persönlich kennengelernt habe, sehe ich keine
Hoffnung, dass diese Person in der Lage ist, mit Vorsicht Daten in der
OSM zu editieren. Er gibt regelmäßig vor, sich auszukennen, nach
oberflächlicher Prüfung erhärtet sich seine Aussage jedoch nicht.

Ein kleiner Erfolg war, ihm zu erklären, dass er für seine Änderungen
nicht iD nutzen sollte, da dieser kein Debugging hat.

Ich bin nicht bereit mit diesem user weiterhin zu kommunizieren, da er
nicht zu einer normalen Kommunikation in der Lage zu sein scheint. Dinge
wie andere permanent zu unterbrechen, vom Thema abzuschweifen und andere
nicht zu Wort kommen lassen möchte ich nicht tolerieren - vor dem
Hintergrund, dass sich diese Person als Mapper auch nicht anders verhält.

Ich bitte um Sperrung.

Über eure Meinung und Erfahrungen würde ich mich trotz meiner inzwischen
feststehende Meinung sehr freuen.

Viele Grüße
715371

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

Re: [Talk-de] Was tu, wenn ein user permanent Daten zerstört?

2014-07-30 Diskussionsfäden 715371

Moin,

Am 30.07.2014 um 14:00 schrieb Norbert Kück:
 Dem User Ulamm musste ich auch schon hinterher wischen und war froh, die
 entsprechenden Geometrien (Kulturdenkmale) im Originalzustand zu
 bevorraten. Dabei hat er Geometrien nicht nur verformt, sondern auch
 zerteilt - ungünstig bei Flächen.
 
 am 30.07.2014 11:31 schrieb 715371:
 Ich bin nicht bereit mit diesem user weiterhin zu kommunizieren, da er
 nicht zu einer normalen Kommunikation in der Lage zu sein scheint. Dinge
 wie andere permanent zu unterbrechen, vom Thema abzuschweifen und andere
 nicht zu Wort kommen lassen möchte ich nicht tolerieren - vor dem
 Hintergrund, dass sich diese Person als Mapper auch nicht anders verhält.
 Ja, so ist er. Ulamm ist unter diesem Namen auch in der Wikipeda tätig
 und für dieses Verhalten bekannt. Er ist nicht böswillig, aber er tut
 sich schwer, Argumente anderer und Regeln zu akzeptieren - leider ein
 anstrengender Umgang. Er ist fleißig, was in diesem Zusammenhang
 manchmal ein Nachteil ist.

Wie seid Ihr damit in der Wikipedia umgegangen? Ich vermute mal, dass es
einfach eine nicht endende Diskussion oder einen edit-war gab.

Mag sein, dass das in der Wikipedia noch verkraftbar ist. In der OSM
gibt es ja immer das Problem, dass an einem Knoten mehr Objekte hängen,
als man erwarten würde und sich dann erst einmal umschauen muss.

Das reverten in der OSM scheint mir derzeit unmöglich. Das sind 70
Änderungssätze und es kommen ständig welche nach. Wenn man dann bei
einem nicht weiter kommt, weil dazwischen ein CS fehlt (von wem konnte
ich nicht herausfinden), bleibt man schließlich auf dem Müll sitzen.

Aber vor allem: ulamm ändert sein Verhalten scheinbar gar nicht. Er
verbessert seine Edits durch die Kritiken, die wir ihm geben teilweise
und liest auch im Wiki nach - vielen Blödsinn kann man aber nach wie vor
finden. Man kann eben auch nicht auf alles aufmerksam machen.

Aus meiner Sicht darf jeder eine Menge kaputt machen. Ich habe auch kein
Problem damit, so etwas zu fixen. Aber wer seine Ohren auf Durchzug
stellt und extrem Fleißig weiter Schrott produziert, dem kann niemand in
der OSM hinterher fixen.

Andere Mapper-Neulinge fragen am Anfang wenigstens nach warum etwas so
gemacht wurde, wie es in der OSM ist. ulamm ist einfach gestartet und
hat korrekte Dinge umgetaggt, Knoten verschoben und dann nicht
verstanden, dass die Dinge vorher korrekt waren. Trotz mehrerer Ansätze,
scheint er dieses Problem immer noch nicht verstanden zu haben und
weicht stattdessen auf abwegige Themen aus oder ignoriert alles was dazu
gesagt wird.

Schlussendlich werden Vorwürfe herausgehauen, für irgendetwas
verantwortlich zu sein oder etwas geändert zu haben.

 Ulamm nennt sich Hobbygeograf und zeichnet teils recht umfängliche
 Karten. Kann es sein, dass ihm der Unterschied zwischen OSM und seiner
 Malerei nicht klar ist?

Ähnlich wie hier

http://forum.openstreetmap.org/viewtopic.php?id=25719

hat ulamm auch beim Stammtisch durchblicken lassen, dass die OSM für ihn
eine Karte ist und alles andere weniger zählen würde.

ulamm selbst hat mir gesagt, dass er Karte(n) von Bremen gezeichnet
hätte und dass das Erfassen der Fahrradinfrastruktur in Bremen ja
vernachlässigt sei. Wahrscheinlich hat er eben solche
Fahrradinfrastrukturkarten von Bremen gezeichnet und versucht nun das
was er da gemalt hat in die OSM zu pressen.

Seine Ortskunde über die Fahrradinfrastruktur ist sehr umfangreich, was
für die OSM hätte hilfreich sein können.

Viele Grüße
715371

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

Re: [Talk-de] Was tu, wenn ein user permanent Daten zerstört?

2014-07-30 Diskussionsfäden 715371

Am 30.07.2014 um 15:53 schrieb Norbert Kück:
 Er ist seit 4 1/2 Jahren dabei. :-(

Stimmt. Aber dazwischen war mindestens ein Jahr lang Pause bis es vor
ein paar Monaten/Wochen los ging. Bis dahin gab es etwa 30 CS.

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

Re: [Talk-de] place=municipality für Gemeinden verwenden?

Am 15.07.2014 09:33, schrieb Frederik Ramm:
 Hallo,
 
 On 07/15/2014 08:18 AM, Florian Lohoff wrote:
 Die Ortsteile von place=village sollten nicht mit place=suburb
 getaggt werden. Es genügt place=neighbourhood.
 
 Woran machst du dieses fest? Neighbourhood ist von der bedeutung im
 Englischen eher deutlich unter suburb angesiedelt, zumindest nach
 meinem Sprachverständnis.

Ja. Aber Dorf und urban passen doch schon nicht zusammen.

So sehr unterscheidet sich neighbourhood doch auch nicht von
Nachbarschaft. Ich kenne das so, dass man die Leute, die am anderen Ende
der gleichen Straße (was auch mehr als 500m sein können) wohnen, noch
Nachbarn nennt. Und im dörflichen/städtischen Sprachgebrauch sind halt
dann die Bewohner der umliegenden Häuser Nachbarn. Keine Ahnug wie das
ethymologisch ist, aber ich tippe mal darauf, dass neighbourhood eher
aus dem ländlichen kommt und auch im städtischen gebraucht wurde.

Beim googlen finde ich das hier
(http://www.koeblergerhard.de/der/DERN.pdf) - Achtung:Kaputte Sonderzeichen:

„Nachbar
, M., £Person die unmittelbar
neben einer anderen Person wohnt oder
Grundeigentum hat‹, mhd. n—chbŒre, n—ch-
bŒr, M., £der in der N
⌂
he wohnende, An-
wohner, Nachbar‹, zu ahd. n—hgibŒr (nach
765?), n—hgibŒro (E. 8. Jh.), M., £Nach-
bar‹, as. n—hbŒr, M., £Nachbar‹, westgerm.
*nÅhwagabŒr, *nÅhwagabŒrÌ n, M., £einer
der nahe ein Haus hat, einer der nahe
wohnt‹, s. nach, (ge,) Bauer “

Warum sollte das im englischen anders sein? Ist halt auch extrem relativ
so ein Begriff. In der Stadt hat man halt 1000+ Nachbarn. Auf dem Land
ist unmittelbar auch deutlich weiter gefasst. Leute die in der nächsten
Parallelstraße wohnen sind dann auch noch Nachbarn.

Ungünstig ist, dass neighbourhood/Nachbarschaft auf sehr
unterschiedlichen Ebenen gebraucht wird. Benachbarte Städte oder auch
benachbarte Länder. Und wenn es Nachbarn gibt, gibt es u.U. auch eine
Nachbarschaft. Ich sehe da jetzt in Nachbarschaft/neighbourhood noch
nicht so einen festen Begriff wie Stadt/town.

 Ehrlich gesagt, nach *meinem* Sprachverständnis wäre etwas, was
 suburbs *oder* neighbourhoods hat, niemals ein village.

Solange man alle Orte, die an die 1 Einwohner haben, als
place=village auffasst und sich in zwei Ortsteile aufteilen lassen, die
auch direkt nebeneinander liegen, ist es doch eventuell noch möglich
place=neighbourhood innerhalb von Dörfern zu benutzen.

Anders herum: Wie sollte man solche Ortsteile sonst bezeichnen?

Zweimal place=village wäre nicht so sinnvoll, wenn solche Orte sonst
auch nicht als zwei wahrgenommen werden.

Und nach meinem Verständnis könnte man ein Dorf auch als Nachbarschaft
(also auch als neighbourhood) auffassen.

 Ins Deutsche getragen, wäre das so, wie wenn man von Vierteln eines
 Dorfs spricht (ich kenne Stadtviertel - aber Dorfviertel?), oder von
 einem Dorf, das Vorstädte hat.

+1

Die typische oder gängige Vorstellung von einem Dorf ist wohl auch eine
durch Felder isolierte Ansiedlung mit vielleicht 10 Straßen. Wer in 500m
Abstand auf einem Hof lebt, wohnt in der Regel meinem Sprachgebrauch
nach nicht mehr im Dorf. Das kann man dann aus meiner Sicht auch nicht
als place=neighbourhood bezeichnen.

Im Wiki ist das durch die Aufteilung nach Einwohnerzahlen aber alles
nicht so deutlich formuliert, finde ich. Da kann man doch argumentieren:
place=hamlet geht nicht, weil die Einwohner noch mit zum Dorf zählen.

Gut. In diesem Beispiel geht eventuell auch noch place=farm. Aber was
passiert, wenn dort drei unterschiedlich benannte Höfe nebeneinander
liegen? Wäre für mich vom Sprachverständnis wohl place=hamlet. Manchmal
ist das in meinem Verständnis aber auch ein Ortsteil (was sich aus
meiner Sicht mehr auf Verwaltungsgrenzen bezieht).

Solange wir place=hamlet/village/town/city nach Bevölkerungszahl, in die
auch umliegende Dörfer hineinzählen, verteilen, haben wir einen Dualismus.

 Ich weiss, dass wir in OSM suburb für Stadtteil mißbrauchen, aber
 selbst ein Dorf, das Stadtteile hat, wäre mir neu.

+1

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

Re: [Talk-de] Ortsteil im addr: namespace Re: place=municipality für Gemeinden verwenden?

Am 15.07.2014 11:20, schrieb Florian Lohoff:
 Postalisch ist das natürlich Rheda-Wiedenbrück und so habe ich das auch
 auf allen Adressnodes. Aber die Autobahn A2 teilt Rheda (Evangelisch) ganz 
 deutlich vom katholischen Wiedenbrück - 2 Schützenvereine, 2 Innenstädte.

Wäre halt die Frage, wann man sich sinnvoll über Verwaltungseinheiten
hinwegsetzen kann.

2 Innenstädte klingt natürlich nach zweimal place=town/village

 Wenn man aber mal den Blick in andere Datenbestände wirft könnte es spannend 
 sein
 auch die Ortsteile mit in die Adressen zu packen. addr:ortsteil - Aber was 
 passt
 da? 

Gab es nicht addr:suburb? Das würde doch im Zweifel besser passen.

 suburb ist ja falsch, neighbourhood noch mehr.

place=suburb wäre aus meiner Sicht nicht falsch, wenn man vorher sagt,
dass es nun eine Stadt ist.

Mal ein anderes Beispiel: Hamburg ist ja auch so ein Fall. Da gab es
vorher Hamburg, Harburg und weitere. Nun ist alles Hamburg. Und Harburg
ein Stadtteil. Die beiden sind ehemals getrennten Orte/Städte sind durch
die Elbe getrennt.

Wie ist es heute? Ich bin auch eher ortsfremd, würde aber sagen, dass
Hamburg das übergeordnete kulturelle und politische Zentrum ist. Mag ja
sein, dass es da noch deutliche Innenstadtzüge in Harburg gibt.

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

Re: [Talk-de] Ortsteil im addr: namespace Re: place=municipality für Gemeinden verwenden?

Am 15.07.2014 13:10, schrieb Florian Lohoff:
 suburb ist nur komplett falsch. Ein suburb ist kein Ortsteil sondern eine 
 Vorstadt.

Sorry, da war ich ganz falsch unterwegs.

Ich hatte mir mal angeschaut was die so zu Stadtteilen von z.B.
Manchester schreiben. Da wurde dann auch district in dem Kontext benutzt.

Dann müsste man wohl in Städten für Stadtteile place=district nehmen.


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

Re: [Talk-de] place=municipality für Gemeinden verwenden?



Am 15.07.2014 13:12, schrieb Florian Lohoff:
 Ich habe kleinere landuses die haben alle keinen namen. Namen für die 
 Orte/Ortsteile
 hänge ich nur an die Administrativen Grenzen bzw die place nodes.
 
 Umfassende Landuses die über hunderte ha gehen halte ich für reichlich kaputt.

+1

IMHO: landuse mit name=* kann man mal machen, aber nur wenn man keine
Zeit hat eine Grenze zu zeichnen oder einfach keine Ahnung.

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

Re: [Talk-de] Ortsteil im addr: namespace Re: place=municipality für Gemeinden verwenden?



Am 15.07.2014 13:18, schrieb Martin Koppenhoefer:
 
 
 Am 15/lug/2014 um 13:10 schrieb Florian Lohoff f...@zz.de:

 suburb ist nur komplett falsch. Ein suburb ist kein Ortsteil sondern eine 
 Vorstadt.
 
 
 jein, bekanntes Problem, dass OSM suburb nicht so verwendet, wie es der 
 Sprachbedeutung nach wäre (sub urbs = unterhalb einer Stadt, weniger als 
 Stadt, Vorstadt ohne städtischen Charakter / Funktionen,...), sondern 
 allgemein für alle Stadtteile

So hatte ich place=suburb bisher verwendet.

In dem Kontext verstehe ich aber place=district nicht. Wäre das eine
Zusammenfassung aus mehreren Stadtteilen zu einer Verwaltungseinheit?

Mit Beispiel wird es bei mir schwierig, weil die meist sehr individuell
sind. Ich probiere es mal mit Bremen West:

https://www.openstreetmap.org/relation/1943540

Wie man sehen kann, enthält das Gebiet einige Stadtteile.

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

Re: [Talk-de] place=municipality für Gemeinden verwenden?

Am 15.07.2014 16:19, schrieb Florian Lohoff:
 Bei extrem großen Firmen mache ich das mal auf landuse=industrial - Da macht
 es ja auch keinen Sinn das auf einzelnen Gebäuden zu machen wenn sowas sich
 über 50-100 Gebäude erstreckt etc.

Wobei das natürlich mit neutraleren und offiziellen Bezeichnungen wie
z.B. Industriegebiet Pusemuckel konkurriert. Wenn man das fortführen
würde, bekäme jede Firma sein eigenes landuse mit name, weil alle
anderen das ja auch haben. Oder am besten die Variante mit landuse am
Knoten, damit der POI auch wirklich überall gerendert wird.

Aber ist halt auch die Frage inwiefern Kartenbetrachter Firmen zur
Orientierung benötigen. Wenn man am großen Bayer Firmenlogo vorbei
fährt, wäre es ja schon gut, das auch auf seiner Karte zu finden.

LG

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

Re: [Talk-de] Ortsteil im addr: namespace Re: place=municipality für Gemeinden verwenden?



Am 15.07.2014 16:22, schrieb Florian Lohoff:
 On Tue, Jul 15, 2014 at 02:12:52PM +0200, 715371 wrote:
 So hatte ich place=suburb bisher verwendet.

 In dem Kontext verstehe ich aber place=district nicht. Wäre das eine
 Zusammenfassung aus mehreren Stadtteilen zu einer Verwaltungseinheit?

 Mit Beispiel wird es bei mir schwierig, weil die meist sehr individuell
 sind. Ich probiere es mal mit Bremen West:

 https://www.openstreetmap.org/relation/1943540

 Wie man sehen kann, enthält das Gebiet einige Stadtteile.
 
 Bei places sind wir aber ausserhalb von Verwaltungsgeschichten. Das wären
 admin_levels - place= gibt ja nur das ggfs zentrum einer fläche an
 und die hierarchie über eben die place tags d.h.

Hierarchie hätte man aber auch durch admin_levels selbst und dann auch
noch von Verwaltungsflächen, die innerhalb von anderen liegen.

place-Tags braucht man in diesem Zusammenhang aus meiner Sicht (außer
als label - nur dann ohne place=*) nicht mehr.

Oder gibt es da Gegenbeispiele?

Um die place-Tags kommt man aber nicht herum - ist ja klar. Nur könnte
man da ja vielleicht noch einmal aufräumen. Z.B. ist es keine useful
combination die Bevölkerungszahl noch einmal am place-Knoten zu haben,
wenn es an der Grenze bereits ist. Das führt nur zur doppelt-Zählung -
ist aber hilfreich, solange es keine Grenzen in der OSM zu dem Ort gibt.

Wenn place=district nicht unterhalb von city in der Hierarchie
angeordnet wird - über suburb - dann ist der Tag ohnehin über, weil das
Dingen nur Verwaltungsspezifisch existiert - zumindest in Deutschland.

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

Re: [Talk-de] place=municipality für Gemeinden verwenden?

2014-07-14 Diskussionsfäden 715371

Hallo Tirkon,

Am 15.07.2014 00:09, schrieb Tirkon:
 Moin,
 
 place=municipality kommt englischen Wiki vor, im deutschen jedoch
 nicht: 
 http://wiki.openstreetmap.org/wiki/Key:place
 http://wiki.openstreetmap.org/wiki/DE:Key:place
 
 In Deutschland kommt das Tag weniger als 30 Mal vor. Wäre es nicht das
 treffendere Tag für Gemeinden, die derzeit zumeist mit place=village
 getaggt werden? place=village scheint mir eher dann zutreffend, wenn
 es innerhalb eines offiziellen place=suburb weitere baulich
 geschlossene Ortsteile laut Ortseingangsschildern gibt. 
 
 Das Problem bei place=municipality für Gemeinden ist aber, dass dann
 der Gemeindename selbst in der höchsten Zoomstufe auf osm.org nicht
 mehr gerendert wird, deren Ortsteile (place=suburb) hingegen schon.

Die Ortsteile von place=village sollten nicht mit place=suburb getaggt
werden. Es genügt place=neighbourhood.

 Wir taggen zwar nicht für den Renderer aber damit wäre die
 Orientierung in den höheren Zoomstufen komplett weg. Wenn municipality
 für Gemeinden verwendet werden soll, müssten sie spätestens zusammen
 mit den suburbs gerendert werden, besser noch früher.

place=municipality scheint aus meiner Sicht ein Sammeltag für Orte zu
werden, die nicht in place=town oder place=village passt.

Ich bin da noch nicht überzeugt von, aber beim rendern sollte
place=municipality aus meiner Sicht wie place=town gerendert werden. Bei
höheren Zoomstufen sollte es aber eher verschwinden.

 Für place=town ist angegeben, dass es für Orte mit mehr als 10.000
 Einwohner angemessen sei. Darüber hinaus soll es sich um Städte
 handeln. 
 Was aber ist mit einer Gemeinde, die 20.000 Einwohner hat
 und dort die Großklinik für die umliegenden (auch kreisfreien)
 Städte (und einen Landkreis) angesiedelt ist, die alle kein
 Krankenhaus aufweisen und die Gemeinde zudem Einkaufszentren und große
 Gewerbegebiete aufweist? 

Dann ist es nach dem bisherigen Schema place=town. Wäre es aus meiner
Sicht nach deiner Beschreibung auch noch mit 9000 Einwohnern (einige
würden das auch noch doller aufweichen). Die Ortsteile wären nach dem
alten Schema dann place=suburb.

Aus meiner Sicht ist place=municipality eine Verwaltungseinheit, die
mehrere Ortskerne hat und die Verwaltung auf diese aufteilt.

Beispiel:
https://de.wikipedia.org/wiki/Hiddenhausen#Gemeindegliederung

Ich vermute mal, dass place=municipality nun nicht place=town ersetzt,
sondern ähnlich wie place=county (Kreis) benutzt wird. Das würde dann
auch heißen, dass Ortsteile die sonst als place=suburb getaggt wurden
nun wieder als place=town/village/hamlet etc getaggt werden.

LG
715371

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

Re: [Talk-de] barrier= e.g. bollard / ohne access

2014-07-13 Diskussionsfäden 715371

Moin Florian,

Am 13.07.2014 18:54, schrieb Florian Lohoff:
 Irgendwie f�nd ich es ja schön wenn die regel w�re das ein barrier
 immer die Verkehrsarten listed die erlaubt sind/bzw physikalisch durch
 gehen. 

Ich würde davon ausgehen, dass folgendes immer gilt, wenn nicht näher
spezifiziert:

foot=yes
bicycle=yes

Im Wiki sagen die das auch so und anders.
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dbollard

Auf jeden Fall müsste/könnte man dann motorcar=permissive taggen, wenn
der Poller herausnehmbar ist, denke ich.

LG 715371

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

Re: [Talk-de] Wie exakt Landnutzungsflächen eintragen?

2014-07-05 Diskussionsfäden 715371



Am 05.07.2014 12:51, schrieb Martin Koppenhoefer:
 
 
 Am 05/lug/2014 um 09:15 schrieb Joerg Fischer o...@jfis.de:

 Unschön ist, wenn von mir sauber getrennte Flächen ständig wieder
 aneinander geklatscht werden.

Liegen die Flächen denn in der Realität auch nebeneinander?

Aus meiner Sicht ist landuse eher nicht für Mikromapping gedacht. Aber
Ausnahmen bestätigen die Regel.

 wenn die Flächen auch in der Realität direkt aneinander grenzen finde ich 
 gemeinsame Nodes das bessere Modell als 2cm Luft dazwischen

+1

Angenommen es möchte jemand den landuse korrigieren, weil die Luftbilder
seit dem letzten Bearbeiten mehr hergeben, dann ist bei geteilten Knoten
nur noch die Hälfte der Arbeit nötig.

Ob eine Fläche an eine andere grenzt kann man beim Survey oder per
Luftbild wohl herausfinden. Das ist dann auch noch einmal zusätzliche
Information.

Zuletzt ist es auch einfacher, Flächen die aneinander liegen Knoten
teilen zu lassen.

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

Re: [Talk-de] Tagging für Geocaches

2014-06-02 Diskussionsfäden 715371

Am 02.06.2014 02:30, schrieb Michael Kugelmann:
 Am 31.05.2014 15:33, schrieb Droelfzehn (aka Michael):
 [...viele sinnvolle Argumente...]

Ein paar sind sinnvoll - ein paar nicht (z.B. die Lizenzbedenken). Aber
theoretisch wäre es noch denkbar traditionelle Caches in die OSM
aufzunehmen. Insgesamt wäre das aber keine große Bereicherung. Daher +1
für Geocaches sollten nicht in die OSM.

 BTW: die Diskussion gab es vor 2 Jahren oder so bereits schon mal.
 Damals war den Konsens eindeutig: Geocaches gehören nicht nach OSM.

Wie angekündigt arbeite ich daran, die Diskussion (von der ich bisher
nichts wusste) diesmal zugänglicher zu machen.

https://wiki.openstreetmap.org/wiki/User:U715371/Geocaching

LG
715371

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

[Talk-de] Tagging für Geocaches

Moin liebe Mapper und Geocacher,

ich bin bei der Benutzung von OSMAnd über die Auflistung der POIs
Geocache gestolpert.

Dann habe ich im Wiki und per Google nach Tagging-Vorschläge für
Geocaches gesucht, aber keine gefunden. Gibt es Vorschläge für das
Erfassen von Geocaches?

Falls es das bisher nicht gibt, werde ich mich in Zukunft einmal damit
beschäftigen. Möglicherweise sind die Lizenzen die größeren Probleme. So
viele werden ja nicht als public domain verfügbar sein. Aber ich kann ja
bei meinen eigenen Caches schon einmal anfangen.

LG
715371

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

Re: [Talk-de] Tagging für Geocaches

Am 31.05.2014 15:01, schrieb Andreas Goss:
 Wenn es dahingehend bisher nichts gibt, wäre die erste Frage denke ich
 nicht **wie** sie erfasst werden sollen, sondern **ob** sie überhaupt
 in der OpenStreetMap Datenbank erfasst werden sollen.
Wenn sie nicht erfasst werden sollten, könnte man ja auch im Wiki eine
Seite anlegen und dort auch schreiben weshalb sich Mapper dagegen
ausgesprochen haben.

Gibt es die schon?

LG
715371

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

Re: [Talk-de] Tagging für Geocaches

Am 31.05.2014 15:33, schrieb Droelfzehn (aka Michael):
 Hallo Mapper und Cacher,
 
 ich bin beides (:-D) und der Meinung Geocaches haben NICHTS in OSM zu
 suchen, weil:
 
 1) Es gibt spezifische Plattformen, die sich explizit mit diesem Thema
 beschäftigen.

Ja, aber Groundspeak hält geschätzt 98% des Marktanteils. Ich habe nicht
vor das durch eine neue Plattform zu ändern, aber erst einmal ausloten,
ob und welche Caches überhaupt denkbar wären.

Im Gelände vorhanden sind sie, allerdings nicht ohne weiteres
verifizierbar. Nicht-Cacher müssten sich um die Aktualität nicht sorgen,
wenn jemand (ein Mapper) erfahren möchte, ob ein Cache aktiv ist, könnte
der das auch per Anfrage an den Ersteller oder andere Bearbeiter.

 2) Wer will den Verwaltungsauffwand erbringen?

siehe unten

  2a) Es müsste permanent gepflegt werden ob ein Cache aktiv, inaktiv
 oder archiviert ist.

Eine entsprechende Anwendung, die die OSM-Daten benutzt, könnte das
gewährleisten, wenn sie analog wie die Wheelmap zulässt Daten zu
editieren und zu erstellen.

  2b) Es gibt verschiedene Arten Caches: Tradis, Multis, Mysteries,
 Letterboxes, Events, u.v.m.
 Alleine was Events angeht wäre der Aufwand immens, da diese
 - in der Regel - nur an einem bestimmten Tag, in einem definierten
 Zeitfenster stattfinden.

+1 IMHO sind Events keine guten Kandidaten für die OSM.

  2c) Es gibt verschiedene Cachegrößen: Nano (meist als Mikro
 bezeichnet), Mikro, Small, Regular, Large und not listed.
Soll das auch getagged werden? Wenn ja: Wer macht die
 Wartung, wenn der Owner die Cachegröße ändert?!

Siehe unten (nächster Punkt).

  2d) Groundspeak (www.geocaching.com) - größte Cachingplattform -
 untersagt explizit die Nutzung der Daten auf externen Seiten. Andere
 glaube ich auch.

Sogar opencaching.de wäre nicht OSM-kompatibel.

Das wäre aber eigentlich nicht schlimm, weil das zugleich erst einmal
deinen gesamten Kritikpunkt 2 erledigen würde.

Ob man für Caches Importe zulässt, könnte man ja noch einmal überdenken.
Tendenziell würden deine Kritikpunkte aus 2 auch sehr dagegen sprechen.

 Meine Meinung ist: OSM braucht keine Caches! 

Da bin ich noch nicht 100%ig von überzeugt.

- Aber Cacher brauchen
 OSM!!! ;-)

+1

 Anmerkung am Rande: Durch das Cachen bin ich zu OSM gekommen, da ich oft
 Wege gefunden habe, die in der Karte nicht eingezeichnet waren und habe
 dann, mit meinem neuen GPS-Gerät, angefangen die Wege nachzupflegen.

Das habe ich schon oft gehört. Ich bin ein Mapper, der auch cacht.

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

Re: [Talk-de] Tagging für Geocaches

Am 31.05.2014 16:08, schrieb Christoph (TheFive@OSM):
 Ich bin auch als Hobby Cacher zu OSM gekommen.
 
 Selbst wenn wir die differenzierten Caches Mappen könnten, erscheint mir das 
 sinnlos.
 
 Die Software zum cachen greift entweder bei GroundSpeak zu (dann NUR bei 
 Groundspeak, weil die das so wollen), oder
 sie nutzt das API der offenen Plattform OpenCaching.de (ich glaube 
 opencaching.com von Garmin war ne Todgeburt).
 
 (Es gibt auch Software die macht unerlaubterweise Websiten Grabbing).

Ja. Ich habe bei opencaching.de noch nicht angefragt ob so etwas ein
Problem wäre - könnte ich mir aber kaum vorstellen. Die Caches bei
Groundspeak sind ja ohnehin aus Lizenzgründen nicht verlinkbar und ganz
sicher ist das auch nicht willkommen.

 
 Wer Cachen will, nutzt dieses Software, und es erscheint mir nicht sinnvoll, 
 das diese auch noch anfangen OSM APIs einbauen, um auf
 von Hand portierte Daten zurückzugreifen. Dann besser die Arbeit in die 
 OpenCaching Plattform stecken, um einen offenen Kontrapunkt zum 
 kommerziellen System zu schaffen.

Die älteren Versionen von c:geo haben soweit ich mich erinnere noch
nicht so viele Service-Anbieter unterstützt wie die neue.

Die OSM-API wäre für die sicherlich kein Problem.

 
 Wenn die Software am Ende prima das OSM API und das OpenCaching API bedienen 
 kann, noch besser. Es müssen ja nicht alle offenen Daten in einer
 DB Stecken.

Im Prinzip hat man mit opencaching.de dann ja auch schon so eine
entsprechende Datenbank. Public Domain sind die Daten bei OSM ja auch
nicht, also sage ich jetzt mal salopp, dass das ähnlich ist.

Das spricht natürlich auch nicht so richtig für Caches in OSM.

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

Re: [Talk-de] Tagging für Geocaches