Re: [Talk-de] highway=crossing -> highway=traffic_signals

[bergaufsee via Talk-de]

Hallo,

Am 24.05.20 um 20:30 schrieb Florian Lohoff:
> Hi,
>
> On Sat, May 23, 2020 at 04:48:17PM +0200, Volker via Talk-de wrote:
>> Hat das vielleicht etwas hiermit
>> https://forum.openstreetmap.org/viewtopic.php?id=69290
>>  zu tun? Das Proposal ist allerdings
>> rejected.https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only
>> 
> Das will ich nicht ausschliessen. Kann es sein das irgendein validator
> oder QA tool das als Fehler raus wirft und änderungen Analog des
> proposals empfiehlt?

Osmose gibt das als Hinweis "*Möglicherweise* fehlende
highway=traffic_signals in der Nähe" raus
https://osmose.openstreetmap.fr/de/errors/?item=2090=2

>
> Ich sehe halt Änderungen im routing weil natürlich eine Ampelkreuzung
> anders als Fußgängerampeln bewertet werden. D.h. bestimmte routen 
> werden "länger" bzw langsamer.

Ich bevorzuge zwar auch highway=crossing + crossing=traffic_signals,
wenn aber doch jede Ampel einen highway=traffic_signals erhält, dann
sollte ein node mit crossing=traffic_signals OHNE
highway=traffic_signals sich wenigstens nicht mehr verkehrsverzögernd in
Navis bemerkbar machen und nodes mit traffic_signals=crossing_only eine
geringere Verzögerung, dann könnte es evtl. passen.

Was mich allerdings stört, wenn ein alleinstehender node
highway=crossing zu highway=traffic_signals geändert wird, dann fehlt
mir irgendwie der Fußgänger-/Radfahrerüberweg und bringt da eine
Inkonsistenz rein

Bernd




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

Re: [Talk-de] highway=crossing -> highway=traffic_signals

[Florian Lohoff]

Hi,

On Sat, May 23, 2020 at 04:48:17PM +0200, Volker via Talk-de wrote:
> Hat das vielleicht etwas hiermit
> https://forum.openstreetmap.org/viewtopic.php?id=69290
>  zu tun? Das Proposal ist allerdings
> rejected.https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only
> 

Das will ich nicht ausschliessen. Kann es sein das irgendein validator
oder QA tool das als Fehler raus wirft und änderungen Analog des
proposals empfiehlt?

Ich sehe halt Änderungen im routing weil natürlich eine Ampelkreuzung
anders als Fußgängerampeln bewertet werden. D.h. bestimmte routen 
werden "länger" bzw langsamer.

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Talk-de] highway=crossing -> highway=traffic_signals

[Volker via Talk-de]

Hat das vielleicht etwas hiermit
https://forum.openstreetmap.org/viewtopic.php?id=69290
 zu tun? Das Proposal ist allerdings
rejected.https://wiki.openstreetmap.org/wiki/Proposed_features/traffic_signals%3Dcrossing_only


Am 23.05.2020 um 13:37 schrieb Florian Lohoff:
> Hi,
> ich sehe in den letzten Wochen immer mehr mapper die Fußgängerampeln
> umtaggen von
>
>   highway=crossing
>   crossing=traffic_signals
>
> zu
>
>   highway=traffic_signals
>   +++
>
> Gibts da irgendeinen Grund für? Ich halte das für falsch aber vielleicht
> vertue ich mich da ja auch. Mir ist das nur aufgefallen weil dadurch die
> travel zeiten im routing hoch gehen weil ein highway=traffic_signals
> anders bewertet wird als crossing=traffic_signals - Was ja auch richtig
> ist.
>
> Ist das eine Koordinierte aktion? Ist das ein validator der das als
> Fehler auswirft?
>
> Flo
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-de] highway=crossing -> highway=traffic_signals

[Florian Lohoff]

Hi,
ich sehe in den letzten Wochen immer mehr mapper die Fußgängerampeln
umtaggen von 

highway=crossing
crossing=traffic_signals

zu 

highway=traffic_signals
+++

Gibts da irgendeinen Grund für? Ich halte das für falsch aber vielleicht
vertue ich mich da ja auch. Mir ist das nur aufgefallen weil dadurch die
travel zeiten im routing hoch gehen weil ein highway=traffic_signals
anders bewertet wird als crossing=traffic_signals - Was ja auch richtig
ist.

Ist das eine Koordinierte aktion? Ist das ein validator der das als 
Fehler auswirft?

Flo
-- 
Florian Lohoff f...@zz.de
UTF-8 Test: The  ran after a , but the  ran away


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

Re: [Talk-de] highway=emergency_access_point

[Thorsten Alge]

> So wie oben von Dir oben angegeben. Bei der Abgleichsaktion [1] im Raum
> Karlsruhe wird name nicht verwendet, da auf den Schildern nur die Nummer
> steht.
>
> Bei dieser Gelegenheit möchte ich kurz darauf aufmerksam machen, dass
> ich Ende des Monats die OSM-Community bei einem Rettungspunkte-Workshop
> [2] des KWF vertrete. Hierfür mache ich momentan eine Qualitätskontrolle
> und schreibe bei festgestellten Unstimmigkeiten gezielt einzelne Mapper
> an. Die Punkte im Harz wurden 2009 importiert und 2013 etwas angepasst.
> Dieses Schema mit dem Namen stammt von einen einzelnen Mapper und könne
> ebenso wie der Note (keine Gewähr für Richtigkeit des
> Notfallrettungspunktes) entfernt werden. Falls die Landesforsten
> zustimmen, wäre auch eine Anreicherung der Punkte mit der Beschreibung
> (z.B bei GS-324: "L519, Parkplatz Abzweig Odertal") in description
denkbar.
>
> Da die Punkte im Harz lagemäßig stimmen, konzentriere ich mich derzeit
> vor allem auf doppelte und wirklich falsche Rettungspunkte.

Da muss ich wiedersprechen. Die Position weicht häufig um ±100m ab. Ich
habe schon einige korrigiert da sie häufig weiter von der Straße weg
liegen als bei den importierten Koordinaten angegeben.

Bei einer Handvoll Rettungspunkte habe ich auch keine Übereinstimmung in
den Daten der FOrsten finden können. Alle die es in den Liste der
Forsten gibt, habe ich entsprechend mit dem OHA oder GS davor versehen.
Diese die nur eine Nummer als Referenz haben, konnte ich nicht finden.

http://overpass-turbo.eu/s/cv9

> Anfang Dezember werde ich von dem Workshop berichten und auch eine
> Diskussion zur Vereinheitlichung und Qualitätssicherung der
> Rettungspunkte anstoßen.

Werde das im Auge behalten. Würde diese im Harz auch gerne weiter
verbessern. Die Angabe 'keine Gewähr für Richtigkeit des
Notfallrettungspunktes' habe ich bereits entfernt da diese dort
definitiv nicht hingehört.


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

Re: [Talk-de] highway=emergency_access_point

[Thorsten Alge]

>> name-Tag was die Angabe der Referenz im Namen eigentlich nötig macht.
>
> Dann wäre es doch gut, wenn osmand bei fehlendem Namen die Referenz
anzeigt.
>
> Jemand hat vor ein paar Stunden aber schon einen Bugreport geöffnet:
> https://github.com/osmandapp/Osmand/issues/1873

Ja, das war ich.

>> Leider ist im Wiki nicht klar angegeben, wie das name-Tag hier verwendet
>> werden soll. Die Bezeichnung 'Notfallrettungspunkt Nr.' im Namen halte
>> ich für unnötig redundant. Die Referenz im Namen ist ebenfalls
>> redundant, macht diese bei Offline-Karten wie OsmAnd aber zumindest
nutzbar.
>>
>> Wie sollten diese nun korrekt getaggt werden?
>
> Ich sehe das gewünschte Tagging wie du. Name ist name, ref ist referenz.
> Wenn das Ding keinen Klartextnamen hat, sollte dieser leer bleiben. Wenn
> eine Anwendung diese nicht unterstützt, muss die Anwendung geändert
werden.
>

Sehe ich eigentlich auch so.


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

Re: [Talk-de] highway=emergency_access_point

[Thorsten Alge]

Die Nummern sind tatsächlich nicht doppelt. Wenn es einen GS-123 gibt,
gibt es keinen OHA-123. Die Frage ist nur, macht man sich jetzt die
Arbeit die Namen zu korrigieren da ich denke, sie sollten keinen Namen
haben – als Kompromiss vielleicht die Referenz auch als Namen.

On 2015-11-06 09:34, uwe_sennew...@hotmail.com wrote:
> Also wenn du der Berkwacht helfen willst erfasse
>
> highway=emergency_access_point
> name=Notfallrettungspunkt Nr. GS-123
> ref=GS-123
>
> denn einen Punkt mit
>
>name=Notfallrettungspunkt Nr. 123
>
> wirst du im Harz öfters finden und nicht jeder wird im Landkreis Goslar
> liegen.
> Wir wollen ja Daten erfassen die Menschen nutzen können , was die
> Rendere daraus machen
> ist durch die Programmierer zu klären.
>
>
>
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] highway=emergency_access_point

[Rolf Eike Beer]

Am Samstag, 7. November 2015, 15:53:07 schrieb Thorsten Alge:
> Die Nummern sind tatsächlich nicht doppelt. Wenn es einen GS-123 gibt,
> gibt es keinen OHA-123. 

Vielleicht nicht in den angrenzenden Landkreisen. Aber selbst innerhalb von 
Niedersachsen gibt es definitiv Wiederholungen.

> Die Frage ist nur, macht man sich jetzt die
> Arbeit die Namen zu korrigieren da ich denke, sie sollten keinen Namen
> haben – als Kompromiss vielleicht die Referenz auch als Namen.

http://wiki.openstreetmap.org/wiki/Name#Name_is_the_name_only

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] highway=emergency_access_point

[uwe_sennew...@hotmail.com]

Also wenn du der Berkwacht helfen willst erfasse

highway=emergency_access_point
name=Notfallrettungspunkt Nr. GS-123
ref=GS-123

denn einen Punkt mit

   name=Notfallrettungspunkt Nr. 123

wirst du im Harz öfters finden und nicht jeder wird im Landkreis Goslar liegen.
Wir wollen ja Daten erfassen die Menschen nutzen können , was die Rendere 
daraus machen
ist durch die Programmierer zu klären.



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

Re: [Talk-de] highway=emergency_access_point

[Martin Koppenhoefer]

Am 6. November 2015 um 09:39 schrieb Holger Jeromin :

> Ich sehe das gewünschte Tagging wie du. Name ist name, ref ist referenz.
> Wenn das Ding keinen Klartextnamen hat, sollte dieser leer bleiben. Wenn
> eine Anwendung diese nicht unterstützt, muss die Anwendung geändert werden.
>


+1, wie immer

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

Re: [Talk-de] highway=emergency_access_point

[Joachim Kast]

Hallo Thorsten,

> ich habe mal eine Frage zum Thema Notfallrettungspunkte und der
> Verwendung des name-Tags. Im Wiki ist ein Schild von einem Rettungpunkt
> mit einer Ortsbezeichnung (Alter Lorscher Weg) und einer Referenznummer
> (HP 108) angegeben. Mappen würde ich das wie folgt:
> 
>   highway=emergency_access_point
>   name=Alter Lorscher Weg
>   ref=HP 108
> 

+1

> Im Harz enthalten die Rettungspunkte keine Ortsbezeichnung und sind fast
> alle wie folgt getaggt (Beispiel: GS-123):
> 
>   highway=emergency_access_point
>   name=Notfallrettungspunkt Nr. 123
>   ref=GS-123
> 
> Leider nutzen die meisten Anwendungen (u.a. OsmAnd) leider nur das
> name-Tag was die Angabe der Referenz im Namen eigentlich nötig macht.
> Für die Bergwacht, welche diese für die Suche vermisster Personen in
> OsmAnd nutzen möchte, ist es ohne die Referenz im Namen unbrauchbar.
> Diese wie in diesem Beispiel anzugeben ist aber auch nicht hilfreich.

Nominatim und OsmAnd werten ref bei der Suche aus. Bei OsmAnd werden
auch die Rettungspunkte wie z.B. KA-1155 bei entsprechender POI-Auswahl
(Klartext "Rettungspunkt") korrekt beschriftet incl. operator angezeigt.
In der Detailanalsicht eines POI ist auch description sichtbar.

> 
> Leider ist im Wiki nicht klar angegeben, wie das name-Tag hier verwendet
> werden soll. Die Bezeichnung 'Notfallrettungspunkt Nr.' im Namen halte
> ich für unnötig redundant. Die Referenz im Namen ist ebenfalls
> redundant, macht diese bei Offline-Karten wie OsmAnd aber zumindest nutzbar.
> 
> Wie sollten diese nun korrekt getaggt werden?

So wie oben von Dir oben angegeben. Bei der Abgleichsaktion [1] im Raum
Karlsruhe wird name nicht verwendet, da auf den Schildern nur die Nummer
steht.

Bei dieser Gelegenheit möchte ich kurz darauf aufmerksam machen, dass
ich Ende des Monats die OSM-Community bei einem Rettungspunkte-Workshop
[2] des KWF vertrete. Hierfür mache ich momentan eine Qualitätskontrolle
und schreibe bei festgestellten Unstimmigkeiten gezielt einzelne Mapper
an. Die Punkte im Harz wurden 2009 importiert und 2013 etwas angepasst.
Dieses Schema mit dem Namen stammt von einen einzelnen Mapper und könne
ebenso wie der Note (keine Gewähr für Richtigkeit des
Notfallrettungspunktes) entfernt werden. Falls die Landesforsten
zustimmen, wäre auch eine Anreicherung der Punkte mit der Beschreibung
(z.B bei GS-324: "L519, Parkplatz Abzweig Odertal") in description denkbar.

Da die Punkte im Harz lagemäßig stimmen, konzentriere ich mich derzeit
vor allem auf doppelte und wirklich falsche Rettungspunkte.

Anfang Dezember werde ich von dem Workshop berichten und auch eine
Diskussion zur Vereinheitlichung und Qualitätssicherung der
Rettungspunkte anstoßen.

Viele Grüße
Joachim

[1] https://wiki.openstreetmap.org/wiki/Forstrettungsschilder_DRK_Karlsruhe

[2] http://forum.openstreetmap.org/viewtopic.php?pid=552925#p552925

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

Re: [Talk-de] highway=emergency_access_point

[Holger Jeromin]

Thorsten Alge wrote on 05.11.2015 23:23:

> ich habe mal eine Frage zum Thema Notfallrettungspunkte und der
> Verwendung des name-Tags. Im Wiki ist ein Schild von einem Rettungpunkt
> mit einer Ortsbezeichnung (Alter Lorscher Weg) und einer Referenznummer
> (HP 108) angegeben. Mappen würde ich das wie folgt:
> 
>   highway=emergency_access_point
>   name=Alter Lorscher Weg
>   ref=HP 108
> 
> Im Harz enthalten die Rettungspunkte keine Ortsbezeichnung und sind fast
> alle wie folgt getaggt (Beispiel: GS-123):
> 
>   highway=emergency_access_point
>   name=Notfallrettungspunkt Nr. 123
>   ref=GS-123
> 
> Leider nutzen die meisten Anwendungen (u.a. OsmAnd) leider nur das
> name-Tag was die Angabe der Referenz im Namen eigentlich nötig macht.

Dann wäre es doch gut, wenn osmand bei fehlendem Namen die Referenz anzeigt.

Jemand hat vor ein paar Stunden aber schon einen Bugreport geöffnet:
https://github.com/osmandapp/Osmand/issues/1873

> Für die Bergwacht, welche diese für die Suche vermisster Personen in
> OsmAnd nutzen möchte, ist es ohne die Referenz im Namen unbrauchbar.
> Diese wie in diesem Beispiel anzugeben ist aber auch nicht hilfreich.
> 
> Leider ist im Wiki nicht klar angegeben, wie das name-Tag hier verwendet
> werden soll. Die Bezeichnung 'Notfallrettungspunkt Nr.' im Namen halte
> ich für unnötig redundant. Die Referenz im Namen ist ebenfalls
> redundant, macht diese bei Offline-Karten wie OsmAnd aber zumindest nutzbar.
> 
> Wie sollten diese nun korrekt getaggt werden?

Ich sehe das gewünschte Tagging wie du. Name ist name, ref ist referenz.
Wenn das Ding keinen Klartextnamen hat, sollte dieser leer bleiben. Wenn
eine Anwendung diese nicht unterstützt, muss die Anwendung geändert werden.

-- 
Grüße
Holger Jeromin


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

[Talk-de] highway=emergency_access_point

[Thorsten Alge]

Hallo Liste,

ich habe mal eine Frage zum Thema Notfallrettungspunkte und der
Verwendung des name-Tags. Im Wiki ist ein Schild von einem Rettungpunkt
mit einer Ortsbezeichnung (Alter Lorscher Weg) und einer Referenznummer
(HP 108) angegeben. Mappen würde ich das wie folgt:

highway=emergency_access_point
name=Alter Lorscher Weg
ref=HP 108

Im Harz enthalten die Rettungspunkte keine Ortsbezeichnung und sind fast
alle wie folgt getaggt (Beispiel: GS-123):

highway=emergency_access_point
name=Notfallrettungspunkt Nr. 123
ref=GS-123

Leider nutzen die meisten Anwendungen (u.a. OsmAnd) leider nur das
name-Tag was die Angabe der Referenz im Namen eigentlich nötig macht.
Für die Bergwacht, welche diese für die Suche vermisster Personen in
OsmAnd nutzen möchte, ist es ohne die Referenz im Namen unbrauchbar.
Diese wie in diesem Beispiel anzugeben ist aber auch nicht hilfreich.

Leider ist im Wiki nicht klar angegeben, wie das name-Tag hier verwendet
werden soll. Die Bezeichnung 'Notfallrettungspunkt Nr.' im Namen halte
ich für unnötig redundant. Die Referenz im Namen ist ebenfalls
redundant, macht diese bei Offline-Karten wie OsmAnd aber zumindest nutzbar.

Wie sollten diese nun korrekt getaggt werden?

Glück Auf

Thorsten

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Georg Feddern]

Moin,

Am 19.05.2015 um 00:08 schrieb 715371:


Am 15.05.2015 um 18:34 schrieb Florian Lohoff:

On Thu, May 14, 2015 at 07:28:19PM +0200, 715371 wrote:


So wie ich dich verstehe, möchtest du da Überholmöglichkeiten sehen,
ohne dass man in den Gegegenverkehr fährt, oder?

Nicht zwangsläufig - Es gibt in meinen Augen auch 2 Spurige Trunks -
Lange z.b. die B50 bei Simmern. Die müsste mittlerweile auch 4 Spurig
sein.

Und diese?
https://www.openstreetmap.org/way/46988406/history#map=18/52.49357/7.32926


ich hätte die gesamte Strecke als primary belassen.
Mir fehlt da die (verkehrsrechtliche) Trennung des Gegenverkehrs - und 
eine übergeordnete Bedeutung über andere primary ist in dem Bereich auch 
nicht gegeben.



D.h. 2+1 wäre OK, aber komplett höhen-/kreuzungsfrei alleine würde dir
nicht reichen. Also eine Mittellinie, die nicht durchgezogen ist, ist
für highway=trunk nicht OK.

Oder soll das ganze auf so etwas hinauslaufen, dass man sich anschaut,
ob noch mehr Sachen erfüllt sind und dann eher aus dem Bauch, aber
relativ frei entscheiden?

Relativ frei würde ich nicht sagen. Aber sowas wie

- Kreuzungsfrei
- Mehrspurig je Fahrtrichtung
- Mittelleitplanke/Doppelte Mittellinie
- Kraftfahrtstraße

Wenn 3 von 4 Kriterien erfüllt sind ist es ein Trunk - so mal ins
unreine Gedacht.

IMO: Eine durchgezogene Mittellinie wäre statt doppelter auch OK.
Allerdings wäre dann die Frage, ob man weitere Kriterien brauch wie
mindestens zwei Anschlussstellen.

Für das 2+1-System würde man Mehrspurig je Fahrtrichtung auch bereits
ein wenig aufweichen. Eingeschränkt auf Deutschland würde derzeit
kreuzungsfrei die wichtigste Eigenschaft sein.


Nicht nur die wichtigste - für mich ist sie zwingend erforderlich.
Von daher gehören für mich zusätzlich 2 der 3 anderen Kriterien erfüllt und


trunks wie diese

http://www.openstreetmap.org/#map=19/52.61961/8.36607

sind in Deutschland ja zur Zeit die Ausnahme.


und für mich ein No-Go.

Georg

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Martin Koppenhoefer]

Am 19.05.2015 um 08:37 schrieb Georg Feddern o...@bavarianmallet.de:

 trunks wie diese
 
 http://www.openstreetmap.org/#map=19/52.61961/8.36607
 
 sind in Deutschland ja zur Zeit die Ausnahme.
 
 und für mich ein No-Go.


sehe ich wegen der Kreisverkehre auch als primary und nicht als trunk, eine 
Straße, die die Vorfahrt nicht hat, ist nicht autobahnähnlich


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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[715371]

Am 19.05.2015 um 08:37 schrieb Georg Feddern:
 eine übergeordnete Bedeutung über andere primary ist in dem Bereich auch
 nicht gegeben.

Die Straße ist schon ziemlich gut ausgebaut. Was ist an der Straße
gegenüber z.B. dieser hier

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

nicht übergeordnet?

 
 D.h. 2+1 wäre OK, aber komplett höhen-/kreuzungsfrei alleine würde dir
 nicht reichen. Also eine Mittellinie, die nicht durchgezogen ist, ist
 für highway=trunk nicht OK.

 Oder soll das ganze auf so etwas hinauslaufen, dass man sich anschaut,
 ob noch mehr Sachen erfüllt sind und dann eher aus dem Bauch, aber
 relativ frei entscheiden?
 Relativ frei würde ich nicht sagen. Aber sowas wie

 - Kreuzungsfrei
 - Mehrspurig je Fahrtrichtung
 - Mittelleitplanke/Doppelte Mittellinie
 - Kraftfahrtstraße

 Wenn 3 von 4 Kriterien erfüllt sind ist es ein Trunk - so mal ins
 unreine Gedacht.
 IMO: Eine durchgezogene Mittellinie wäre statt doppelter auch OK.
 Allerdings wäre dann die Frage, ob man weitere Kriterien brauch wie
 mindestens zwei Anschlussstellen.

 Für das 2+1-System würde man Mehrspurig je Fahrtrichtung auch bereits
 ein wenig aufweichen. Eingeschränkt auf Deutschland würde derzeit
 kreuzungsfrei die wichtigste Eigenschaft sein.
 
 Nicht nur die wichtigste - für mich ist sie zwingend erforderlich.

+1 Das wäre für Deutschland aus meiner Sicht eine sinnvolle Regelung.

 Von daher gehören für mich zusätzlich 2 der 3 anderen Kriterien erfüllt und

Weil Doppellinien laut VwV-StVO nur bei mehr als lanes=2 genutzt werden,
müsste man die Liste oben bereinigen, weil prinzipiell sonst nur 1 oder
3 Kriterien erfüllt werden können.

(siehe
http://www.verwaltungsvorschriften-im-internet.de/bsvwvbund_26012001_S3236420014.htm
zu Zeichen 295)

Gibt es denn ansonsten einen Unterschied zwischen doppelter und
einfacher Linie? Die doppelte scheint ja genauso wie die einfache unter
Zeichen 295 erfasst zu sein.

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Georg Feddern]

Moin,

Am 19.05.2015 um 13:56 schrieb 715371:

Am 19.05.2015 um 08:37 schrieb Georg Feddern:

eine übergeordnete Bedeutung über andere primary ist in dem Bereich auch
nicht gegeben.

Die Straße ist schon ziemlich gut ausgebaut. Was ist an der Straße
gegenüber z.B. dieser hier

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

nicht übergeordnet?


Dass die beiden Strecken 88 km auseinanderliegen ...
Siehe 
https://www.openstreetmap.org/way/46988406/history#map=18/52.49357/7.32926


In diesem Bereich meint ganz konkret von Anfang bis Ende der als trunk 
getaggten Strecke und ihren regionalen Bezug in der Verkehrsführung.
Ein überregionaler Bezug ist ja eh nicht gegeben, da die Strecke 
überregional ja eh nur mit primary angebunden ist.
Nur dann wurde ich diese Strecke ausnahmsweise mal als trunk statt als 
primary taggen trotz in meinen Augen nicht ausreichender Kriterien.
Das sehe ich dort in der Region aber nicht gegeben - primary reicht 
absolut als übergeordnete Einstufung.



Relativ frei würde ich nicht sagen. Aber sowas wie

- Kreuzungsfrei
- Mehrspurig je Fahrtrichtung
- Mittelleitplanke/Doppelte Mittellinie
- Kraftfahrtstraße


IMO: Eine durchgezogene Mittellinie wäre statt doppelter auch OK.
[...]
Eingeschränkt auf Deutschland würde derzeit
kreuzungsfrei die wichtigste Eigenschaft sein.

Nicht nur die wichtigste - für mich ist sie zwingend erforderlich.

+1 Das wäre für Deutschland aus meiner Sicht eine sinnvolle Regelung.


Von daher gehören für mich zusätzlich 2 der 3 anderen Kriterien erfüllt und

Weil Doppellinien laut VwV-StVO nur bei mehr als lanes=2 genutzt werden,
müsste man die Liste oben bereinigen, weil prinzipiell sonst nur 1 oder
3 Kriterien erfüllt werden können.

(siehe
http://www.verwaltungsvorschriften-im-internet.de/bsvwvbund_26012001_S3236420014.htm
zu Zeichen 295)

Gibt es denn ansonsten einen Unterschied zwischen doppelter und
einfacher Linie? Die doppelte scheint ja genauso wie die einfache unter
Zeichen 295 erfasst zu sein.



Ich kenne als Unterschied nur die Regelung, dass die Doppellinie von 
keinem Fahrzeugteil (z. B. Rückspiegel) überragt werden darf.
Insofern hatte ich das IMO: Eine durchgezogene Mittellinie wäre statt 
doppelter auch OK gedanklich bereits mit einbezogen.


Gruß
Georg

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[715371]

Am 15.05.2015 um 18:34 schrieb Florian Lohoff:
 On Thu, May 14, 2015 at 07:28:19PM +0200, 715371 wrote:
 Nein - Das willst du auch nicht. Es gibt manchmal gute gründe Dinge
 anders als üblich zu taggen. Weil es dem Verkehrsaufkommen entspricht,
 der regionalen Klassifizierung einer Straße etc.

 So wie ich dich verstehe, möchtest du da Überholmöglichkeiten sehen,
 ohne dass man in den Gegegenverkehr fährt, oder?
 
 Nicht zwangsläufig - Es gibt in meinen Augen auch 2 Spurige Trunks -
 Lange z.b. die B50 bei Simmern. Die müsste mittlerweile auch 4 Spurig
 sein. 

Und diese?
https://www.openstreetmap.org/way/46988406/history#map=18/52.49357/7.32926

 
 D.h. 2+1 wäre OK, aber komplett höhen-/kreuzungsfrei alleine würde dir
 nicht reichen. Also eine Mittellinie, die nicht durchgezogen ist, ist
 für highway=trunk nicht OK.

 Oder soll das ganze auf so etwas hinauslaufen, dass man sich anschaut,
 ob noch mehr Sachen erfüllt sind und dann eher aus dem Bauch, aber
 relativ frei entscheiden?
 
 Relativ frei würde ich nicht sagen. Aber sowas wie
 
 - Kreuzungsfrei
 - Mehrspurig je Fahrtrichtung
 - Mittelleitplanke/Doppelte Mittellinie
 - Kraftfahrtstraße
 
 Wenn 3 von 4 Kriterien erfüllt sind ist es ein Trunk - so mal ins
 unreine Gedacht.

IMO: Eine durchgezogene Mittellinie wäre statt doppelter auch OK.
Allerdings wäre dann die Frage, ob man weitere Kriterien brauch wie
mindestens zwei Anschlussstellen.

Für das 2+1-System würde man Mehrspurig je Fahrtrichtung auch bereits
ein wenig aufweichen. Eingeschränkt auf Deutschland würde derzeit
kreuzungsfrei die wichtigste Eigenschaft sein.

trunks wie diese

http://www.openstreetmap.org/#map=19/52.61961/8.36607

sind in Deutschland ja zur Zeit die Ausnahme.

 
 Aber am Ende ist es doch auch eine regionale Entscheidung. Es gibt
 bestimmt Gebiete wo ALLES so gut Ausgebaut ist. Da ist nicht
 alles sofort Trunk sondern die mit der wirklichen übergeordneten
 Bedeutung. In anderen Bereichen mit schlechter Infrastruktur wie
 z.b. Lippe ist es viel schneller mal ein Trunk weil es eben schnell
 übergeordenete Bedeutung bekommt. Und z.b. die erwähnte
 Ostwestfalenstraße hat ganz deutlich übergeordeneten Charakter.

Wobei es highway=primary auch schon tun würde, um den übergeordneten
Charakter zu erfassen. Was das Wiki anbelangt müsste highway=trunk
weniger von der Rolle der Bedeutung bestimmt werden. Bei Autobahnen kann
man sich in Deutschland natürlich schlicht am Autobahnschild orientieren.

 Am Ende sind die die OSM Klassifizierungen regional unterschiedlich.

Das kommt natürlich auch auf die Konsumenten an. Innerhalb Deutschlands
sollte man aber einigermaßen klare Regeln finden können.

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Martin Koppenhoefer]

Am 14. Mai 2015 um 15:09 schrieb Florian Lohoff f...@zz.de:

 Router nehmen nicht nur Geschwindigkeiten sondern auch Straßenklassen
 zur priorisierung. Auf einem trunk maxspeed=50 kommt man tendentiell ja
 auch schneller vorran als auf einem residential maxspeed=50.



ja klar, je nach Situation wird man die Klassen taggen, sofern es eine
Umfahrung gibt würde ich der Ortsdurchfahrt auch eher was niedrigeres
geben, aber bitte nicht die Kontinuität des Netzes unterbrechen, und im Ort
die Durchgangsstraße herunterstufen, wenn es keine Alternativen gibt.

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Martin Koppenhoefer]

Am 14. Mai 2015 um 16:15 schrieb Michael ohr...@gmail.com:

 Mir so etwas in Richtung wie übergeordnete Bedeutung (blöder Ausdruck,
 ich weiß, aber mir fällt gerade nichts besseres aus). Ich bin halt eher ein
 Freund davon, nach der Verkehrsbedeutung zu mappen.

  Ich fände es nicht schlimm, wenn eine primary auf einem Teilstück das
 kreuzungsfrei / autobahnähnlich ausgebaut ist, zu einem trunk würde.


 Bei autobahnähnlich bin ich ja voll dabei. Aber nehmen wir mal an, die
 Umgehungsstraße zwischen Pusemuckel-West und Pusemuckel-Ost ist
 kreuzungsfrei ausgebaut, aber nur zweistreifig. Da wäre da für mich ein
 trunk trotzdem fehl am Platz. Wenn man nur die Höhenfreiheit als
 Argument nimmt, wäre das aber trunk.



OK, +1

Hier mal ein Beispiel, wo es oft wechselt von trunk zu primary und zurück,
sowohl die B27 (Tübingen Richtung Balingen) als auch die B28 um Reutlingen,
und wo ich das auch gerechtfertigt finde, und ein Informationsgewinn da ist:
http://www.openstreetmap.org/#map=13/48.4680/9.1313

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Florian Lohoff]

Hi,

On Thu, May 14, 2015 at 11:32:22AM +0200, Martin Koppenhoefer wrote:
 Am 14. Mai 2015 um 11:25 schrieb Michael ohr...@gmail.com:
 
  Gerade Ortsumgehungen sind ja oft kreuzungsfrei ausgebaut, für mich ist
  das aber noch kein trunk.
 
 warum? Was fehlt denen?
 
 Ich fände es nicht schlimm, wenn eine primary auf einem Teilstück das
 kreuzungsfrei / autobahnähnlich ausgebaut ist, zu einem trunk würde.

So habe ich das auch an der Ortsumgehung Rheda-Wiedenbrück der B64
gelöst. Jeweils aus Münster oder Lippstadt kommend wird die B55/B64 da
von 2 zu 4 Spurig - mit Mittelleitplanke, Kreuzungsfrei und ohne
Geschwindigkeitsbeschränkung. Da wechselt das tagging heute auf Trunk.
Da wo die 4 Spurigkeit endet endet auch im moment der trunk.

Auf dem Teilstück trunk gibt es dann auch die Autobahnauffahrt
Rheda-Wiedenbrück auf die A2 die ganz klar wie ein Autobahnkreuz als
Kleeblatt ausgeführt ist.

Flo
-- 
Florian Lohoff f...@zz.de
 We need to self-defense - GnuPG/PGP enable your email today!


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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Michael]

Am 14.05.2015 um 11:32 schrieb Martin Koppenhoefer:

Am 14. Mai 2015 um 11:25 schrieb Michael ohr...@gmail.com:


Gerade Ortsumgehungen sind ja oft kreuzungsfrei ausgebaut, für mich ist
das aber noch kein trunk.


warum? Was fehlt denen?


Mir so etwas in Richtung wie übergeordnete Bedeutung (blöder Ausdruck, 
ich weiß, aber mir fällt gerade nichts besseres aus). Ich bin halt eher 
ein Freund davon, nach der Verkehrsbedeutung zu mappen.



Ich fände es nicht schlimm, wenn eine primary auf einem Teilstück das
kreuzungsfrei / autobahnähnlich ausgebaut ist, zu einem trunk würde.


Bei autobahnähnlich bin ich ja voll dabei. Aber nehmen wir mal an, die 
Umgehungsstraße zwischen Pusemuckel-West und Pusemuckel-Ost ist 
kreuzungsfrei ausgebaut, aber nur zweistreifig. Da wäre da für mich ein 
trunk trotzdem fehl am Platz. Wenn man nur die Höhenfreiheit als 
Argument nimmt, wäre das aber trunk.


Von der B19 bei Aalen habe ich jetzt leider kein Bild gefunden. Dafür 
aber die B12: 
https://d1cuyjsrcm0gby.cloudfront.net/AE1iLOTwPwhmMAReWroXLw/thumb-1024.jpg
Das ist derzeit als primary getaggt. Wenn die Bedeutung von trunk 
ausgeweitet würde das wohl darunter fallen.


Grüße,
Michael

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Florian Lohoff]

On Thu, May 14, 2015 at 11:29:42AM +0200, Martin Koppenhoefer wrote:
 Am 14. Mai 2015 um 11:02 schrieb Florian Lohoff f...@zz.de:
 
  trunk war in der ursprünglichen OSM definition die Kraftfahrtstraße,
  d.h. Kreuzungsfrei ausgebaut aber eben keine Autobahn.
 
  Diese definition ist aufgeweicht worden denn nicht alles was
  Kreuzungsfrei ist auch eine Kraftfahrtstraße ist.
 
 jein, zumindest in den letzten 7 Jahren war man sich eigentlich einig, dass
 Kraftfahrstraßen nicht automatisch als trunk übersetzt werden können. Daher
 hat man ja extra den tag motorroad=yes eingeführt. trunk sollen
 autobahnähnliche Straßen sein, die eben keine Autobahnen sind (da bin ich
 dann wieder bei Dir).

Eben - Anfaenglich war das aber Kraftfahrtstraße - trunk - Das hat
sich dann vor etlichen Jahren eben aufgeweicht als motorroad=yes kam
(Was ja dann noch mehr impliziert wie bicycle=no, minspeed=60 etc)

  Klassifiziert ist als der standard. Gerade innerorts entspricht
  oft die Straßenklassifizierung nicht dem Ausbauzustand.
 
 innerorts würde ich nur dann trunk setzen, wenn man sich gefühlt auf
 einer Art Autobahn befindet, also weder Gehwege da sind, noch Fahrräder
 oder Kreuzungen / Ampeln (ggf. in Ausnahmefällen).

Da ging es weniger um trunks 

 Der Eingriff ist hier m.E. am besten, die zulässige Höchstgeschwindigkeit
 zu taggen (z.B. 50), damit werden die innerörtlichen Straßen normalerweise
 ausreichend benachteiligt, sofern es auch eine Umfahrung gibt.

Router nehmen nicht nur Geschwindigkeiten sondern auch Straßenklassen 
zur priorisierung. Auf einem trunk maxspeed=50 kommt man tendentiell ja
auch schneller vorran als auf einem residential maxspeed=50.

Flo
-- 
Florian Lohoff f...@zz.de
 We need to self-defense - GnuPG/PGP enable your email today!


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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[715371]

Am 14.05.2015 um 16:15 schrieb Michael:
 Am 14.05.2015 um 11:32 schrieb Martin Koppenhoefer:
 Am 14. Mai 2015 um 11:25 schrieb Michael ohr...@gmail.com:

 Gerade Ortsumgehungen sind ja oft kreuzungsfrei ausgebaut, für mich ist
 das aber noch kein trunk.

 warum? Was fehlt denen?
 
 Mir so etwas in Richtung wie übergeordnete Bedeutung (blöder Ausdruck,
 ich weiß, aber mir fällt gerade nichts besseres aus). Ich bin halt eher
 ein Freund davon, nach der Verkehrsbedeutung zu mappen.

In Gegenden, wo man solche Straßen baut, sind aber auch nicht so häufig
andere wichtige Straßen. Aus meiner Sicht wird die Anzahl der
Konflikte überschaubar sein.

Aber die Frage ist halt, welche Eigenschaften kann man von einem trunk
überhaupt erwarten? Schnellstraße? Wenn die Mindestgeschwindigkeit aus
motorway=yes/no impliziert wird, hätte man da ein gutes Kriterium.
Welche Verkehrsmitteln drauf fahren dürfen ist ohnehin durch access
klar. Überholverbote kann man auch gesondert erfassen. Anzahl der Spuren
mit lanes. Beschilderung ist in der Praxis nicht immer gleich und im
Wiki wird das auch nicht eindeutiges Merkmal genannt.

Was bleibt ist also der Blick in die Karte. Weil diese Straßen, die
Kreuzungsfrei sind eigentlich nie mit benachbarten Straßen verbunden
sind - wegen kreuzungfreiheit - würde sich die trunk-Darstellung wegen
übergeordneter Bedeutung eher lohnen. Und das wäre dann ja auch der
Zweck. So eine Straße hat ja gerade keine Kreuzungen, weil sie nicht so
sehr durch Anlieger benutzt werden soll.

Aus meiner Sicht kann es da also nur noch um den Verkehrsfluss gehen, oder?

 Von der B19 bei Aalen habe ich jetzt leider kein Bild gefunden. Dafür
 aber die B12:
 https://d1cuyjsrcm0gby.cloudfront.net/AE1iLOTwPwhmMAReWroXLw/thumb-1024.jpg
 Das ist derzeit als primary getaggt. Wenn die Bedeutung von trunk
 ausgeweitet würde das wohl darunter fallen.

Für den gezeigten Ausschnitt ja, aber wenn die Auffahrt nicht
kreuzungsfrei/höhenfrei ist - man also anhalten muss - wäre das gesamte
Teil kein trunk mehr. Die Sache ist an der Stelle, dass man so Straßen,
die nur teilweise höhenfrei sind, alle Nase lang findet. Komplett
kreuzungsfrei/höhenfrei ist wesentlich seltener.

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Rolf Eike Beer]

Am Donnerstag, 14. Mai 2015, 16:15:35 schrieb Michael:
 Am 14.05.2015 um 11:32 schrieb Martin Koppenhoefer:
  Am 14. Mai 2015 um 11:25 schrieb Michael ohr...@gmail.com:
  Gerade Ortsumgehungen sind ja oft kreuzungsfrei ausgebaut, für mich ist
  das aber noch kein trunk.
  
  warum? Was fehlt denen?
 
 Mir so etwas in Richtung wie übergeordnete Bedeutung (blöder Ausdruck,
 ich weiß, aber mir fällt gerade nichts besseres aus). Ich bin halt eher
 ein Freund davon, nach der Verkehrsbedeutung zu mappen.
 
  Ich fände es nicht schlimm, wenn eine primary auf einem Teilstück das
  kreuzungsfrei / autobahnähnlich ausgebaut ist, zu einem trunk würde.
 
 Bei autobahnähnlich bin ich ja voll dabei. Aber nehmen wir mal an, die
 Umgehungsstraße zwischen Pusemuckel-West und Pusemuckel-Ost ist
 kreuzungsfrei ausgebaut, aber nur zweistreifig. Da wäre da für mich ein
 trunk trotzdem fehl am Platz. Wenn man nur die Höhenfreiheit als
 Argument nimmt, wäre das aber trunk.

Laut dem Wiki ist die Eingliederung als autobahnähnliche Straße machgeblich. 
Dafür braucht es nach meinem Verständnis:

-höhenfreie Anbindung (d.h. keine Ampeln und Kreuzungen)
-keine Fahrten im Gegenverkehr (d.h. aber _nicht_ notwendigerweise baulich 
getrennte Fahrbahnen)

Ein guter Hinweis, aber nicht zwingend überall vorhanden, sind die Ausfahrt-
Schilder. Die sind nur auf solchen Straßen zulässig.

Eike

signature.asc
Description: This is a digitally signed message part.
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Florian Lohoff]

Hola,

On Wed, May 13, 2015 at 11:10:26PM +0200, 715371 wrote:
 Moin,
 
 mich würde interessieren, welche Straßen ihr als highway=trunk taggen
 würdet.

trunk war in der ursprünglichen OSM definition die Kraftfahrtstraße,
d.h. Kreuzungsfrei ausgebaut aber eben keine Autobahn.

Diese definition ist aufgeweicht worden denn nicht alles was
Kreuzungsfrei ist auch eine Kraftfahrtstraße ist.

(Nicht alles was hinkt ist ein Vergleich).

Am Ende ist das aber auch Egal. Das ist wie bei der definition von track
vs. service. Es gibt Kriterien die das einfach machen und es gibt
Anhaltspunkte.

- Mehrspuriger Ausbau, Kreuzungsfrei, keine Autobahn - trunk

 Vielleicht könnte man sich ja auf eine konkretere Empfehlung als bisher
 einigen, die dann auch expliziter formuliert wird. Im Moment wäre das
 aus meiner Sicht so etwas wie: Als highway=trunk werden alle
 höhenfreien Straßen erfasst.

Nein - Das willst du auch nicht. Es gibt manchmal gute gründe Dinge
anders als üblich zu taggen. Weil es dem Verkehrsaufkommen entspricht,
der regionalen Klassifizierung einer Straße etc.

Als Beispiel:

In Ostwestfalen haben wir uns mal drauf geeinige das wir Kreisstraßen 
als tertiary erfassen die aber auch auf unclassified runter oder auch 
secondary hochklassifizieren wenn der Ausbauzustand das unterstreicht.
Dann setzen wir aber einen note auf dem/den ways warum das anders
Klassifiziert ist als der standard. Gerade innerorts entspricht
oft die Straßenklassifizierung nicht dem Ausbauzustand. Wenn man dann 
nicht eingreift kommt es zu total unsinnigem Routing und am Ende
auch einer konzentration von Verkehr auf völlig ungeeigneten
wegen.

Flo
-- 
Florian Lohoff f...@zz.de
 We need to self-defense - GnuPG/PGP enable your email today!


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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Martin Koppenhoefer]

Am 14. Mai 2015 um 11:25 schrieb Michael ohr...@gmail.com:

 Gerade Ortsumgehungen sind ja oft kreuzungsfrei ausgebaut, für mich ist
 das aber noch kein trunk.



warum? Was fehlt denen?

Ich fände es nicht schlimm, wenn eine primary auf einem Teilstück das
kreuzungsfrei / autobahnähnlich ausgebaut ist, zu einem trunk würde.

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Michael]

Hallo,

Am 13.05.2015 um 23:10 schrieb 715371:

mich würde interessieren, welche Straßen ihr als highway=trunk taggen
würdet.


Autobahnähnlich ausgebaute Straßen, die keine Autobahn sind.


In anderen Ländern wie Großbritannien wird highway=trunk anscheinend
komplett anders verwendet. Ich spare mir da mal die Links.


Soweit ich weiß kommt das Konzept der trunk roads aus Großbritannien.
Dort sind das Straßen, die explizit so klassifiziert wurden, da sie für
den überregionalen Verkehr ein Netzwerk bilden (oder so ähnlich).

Dazu gibt es in anderen Ländern inklusive Deutschland eben keine direkte
Analogie, dementsprechend wird das sehr unterschiedlich gehandhabt.


Vielleicht könnte man sich ja auf eine konkretere Empfehlung als
bisher einigen, die dann auch expliziter formuliert wird.


Eigentlich fand ich die bisherige Definition gar nicht so unklar. Ob das 
bei einer Änderung besser wird, wage ich aber mal zu bezeifeln.



Im Moment wäre das aus meiner Sicht so etwas wie: Als highway=trunk
werden alle höhenfreien Straßen erfasst.


Da finde ich höhenfrei schon mal alles andere als klar. Bis vorhin hat 
mir der Begriff überhaupt nichts gesagt. Spontan hätte ich auch das 
Gegenteil darunter verstanden - nämlich dass eine höhenfreie Kreuzung 
eben keine Brücke hat.


Aber auch inhaltlich finde ich es keine gute Idee. Nach dieser 
Definition würde manche Bundesstraße plötzlich für ein Stück von 
primary zu trunk und dann wieder zurück wechseln. Gerade 
Ortsumgehungen sind ja oft kreuzungsfrei ausgebaut, für mich ist das 
aber noch kein trunk.


Als entsprechendes Beispiel fällt mir die B19 von Aalen nach Heidenheim 
ein (http://www.openstreetmap.org/#map=13/48.7856/10.1296). Unter- und 
Oberkochen werden kreuzungsfrei umfahren, in Königsbronn gibt es dann 
aber eine klassische Ortsdurchfahrt.


Grüße,
Michael

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

Re: [Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[Martin Koppenhoefer]

Am 14. Mai 2015 um 11:02 schrieb Florian Lohoff f...@zz.de:

 trunk war in der ursprünglichen OSM definition die Kraftfahrtstraße,
 d.h. Kreuzungsfrei ausgebaut aber eben keine Autobahn.

 Diese definition ist aufgeweicht worden denn nicht alles was
 Kreuzungsfrei ist auch eine Kraftfahrtstraße ist.



jein, zumindest in den letzten 7 Jahren war man sich eigentlich einig, dass
Kraftfahrstraßen nicht automatisch als trunk übersetzt werden können. Daher
hat man ja extra den tag motorroad=yes eingeführt. trunk sollen
autobahnähnliche Straßen sein, die eben keine Autobahnen sind (da bin ich
dann wieder bei Dir).



 Klassifiziert ist als der standard. Gerade innerorts entspricht
 oft die Straßenklassifizierung nicht dem Ausbauzustand.



innerorts würde ich nur dann trunk setzen, wenn man sich gefühlt auf
einer Art Autobahn befindet, also weder Gehwege da sind, noch Fahrräder
oder Kreuzungen / Ampeln (ggf. in Ausnahmefällen).




 Wenn man dann
 nicht eingreift kommt es zu total unsinnigem Routing und am Ende
 auch einer konzentration von Verkehr auf völlig ungeeigneten
 wegen.



Der Eingriff ist hier m.E. am besten, die zulässige Höchstgeschwindigkeit
zu taggen (z.B. 50), damit werden die innerörtlichen Straßen normalerweise
ausreichend benachteiligt, sofern es auch eine Umfahrung gibt.

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

[Talk-de] highway=trunk - Höhenfreie zweistreifige Straße

[715371]

Moin,

mich würde interessieren, welche Straßen ihr als highway=trunk taggen
würdet.

Konkret geht es mir um Straßen, die bei Wikipedia Höhenfreie
zweistreifige Straße genannt werden:

http://de.wikipedia.org/wiki/Autobahn%C3%A4hnliche_Stra%C3%9Fe#H.C3.B6henfreie_zweistreifige_Stra.C3.9Fe

Das wären also Straßen die auf jeden Fall immer Einfädelungs- oder
Abbiegestreifen besitzen. Hier ein paar davon:

* B 85 bei Schwandorf:
https://www.openstreetmap.org/#map=18/49.34582/12.14301
* N 4 bei Nürnberg: https://www.openstreetmap.org/#map=17/49.39091/11.04532
* B 4 bei Oberwohlsbach:
https://www.openstreetmap.org/#map=16/50.3081/11.0283
* B 210 bei Jever: https://www.openstreetmap.org/#map=15/53.5615/7.9454
* L 810 bei Wilhelmshaven:
https://www.openstreetmap.org/#map=16/53.5768/8.0592

Die Kriterien im Wiki unterscheiden sich auch kaum von der einzigen
Anforderung höhenfrei. Z.B. soll man sie anhand der Fahrbahnmarkierung
und der Ausfahrtschilder erkennen können. Siehe z.B. hier
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dtrunk#International_equivalence

In anderen Ländern wie Großbritannien wird highway=trunk anscheinend
komplett anders verwendet. Ich spare mir da mal die Links. In Polen
konnte ich zumindest einen highway=trunk finden, der nicht Einbahnstraße
ist:
* https://osm.org/#map=16/52.7437/15.1641

International und National scheint highway=trunk extrem unterschiedlich
genutzt zu sein. Diskussionen auf den betreffenden Wiki-Seiten spiegeln
das auch wider.

Nun zu Straßen, die ich nicht für trunks halte, weil sie nicht höhenfrei
sind. Manche sind davon dennoch als highway=trunk erfasst.
* https://www.openstreetmap.org/#map=17/49.59812/9.70309
* https://www.openstreetmap.org/#map=18/49.85593/10.02077

Noch ein Beispiel aus dem Wiki:
https://wiki.openstreetmap.org/wiki/Attributierung_von_Stra%C3%9Fen_in_Deutschland#Beispiele_f.C3.BCr_die_Notwendigkeit_eines_flexiblen_Einordnens_von_Stra.C3.9Fen
Für den Grötzinger Tunnel wird empfohlen, dass highway=primary statt
highway=trunk wegen nur einer Fahrbahn verwendet werden sollte.

Vielleicht könnte man sich ja auf eine konkretere Empfehlung als bisher
einigen, die dann auch expliziter formuliert wird. Im Moment wäre das
aus meiner Sicht so etwas wie: Als highway=trunk werden alle
höhenfreien Straßen erfasst.

LG
Tobias

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

[Talk-de] highway=escape (war: Wochennotiz Nr. 234 6.1.–12.1.2015)

[Michael Kugelmann]

Am 16.01.2015 um 09:51 schrieb wn reader:
die Wochennotiz Nr. 234 mit allen wichtigen Neuigkeiten aus der 
OpenStreetMap Welt ist da:

http://blog.openstreetmap.de/blog/2015/01/wochennotiz-nr-234/
im Bezug auf  highway=escape  ( 
http://www.openstreetmap.org/user/jgpacker/diary/28379 )   ein Hinweis:
mir ist eingefallen, dass es solche Wege am 
https://de.wikipedia.org/wiki/Zirler_Berg gibt.


Allerdings werden sie in der OSM-Standard-Karte nicht gerendert, wenn 
man den Datenlayer anschaltet sind sie aber sichtbar.

https://www.openstreetmap.org/#map=17/47.28190/11.22931layers=D


Grüße,
Michael.


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

Re: [Talk-de] highway=escape (war: Wochennotiz Nr. 234 6.1.–12.1.2015)

[Tom Pfeifer]

Michael Kugelmann wrote on 2015-01-20 17:58:

Am 16.01.2015 um 09:51 schrieb wn reader:
im Bezug auf  highway=escape  ( 
http://www.openstreetmap.org/user/jgpacker/diary/28379 )   ein Hinweis:
mir ist eingefallen, dass es solche Wege am 
https://de.wikipedia.org/wiki/Zirler_Berg gibt.

Allerdings werden sie in der OSM-Standard-Karte nicht gerendert, wenn man den 
Datenlayer anschaltet sind sie aber sichtbar.
https://www.openstreetmap.org/#map=17/47.28190/11.22931layers=D


Rendering wird diskutiert:
https://github.com/gravitystorm/openstreetmap-carto/issues/1239

tom


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

Re: [Talk-de] Highway Shields (Strassennummern)

[Martin Koppenhoefer]

Am 13. Januar 2014 22:12 schrieb Peter Wendorff wendo...@uni-paderborn.de:

 Hi,
 jetzt fängst du aber mit Ausweichtaktiken an.
 Es fehlt doch offensichtlich ganz generell an der Softwareunterstützung
 für mehrwertige Tags, da ist ref doch bei weitem kein Einzelfall, oder
 hat sich das mittlerweile so stark gewandelt?

 Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten:

 amenity=parking;fuel (4523, wobei viele davon vom AND-Import kommen)



kompletter Unfug m.E., das sollten 2 Objekte sein, ein Parkplatz/haus und
eine Tankstelle innerhalb dessen.



 amenity=restaurant;cafe (44)



44 Stück sind ja nicht gerade überwältigend, kann man m.E. besser über
cuisine-tag und ggf. weitere Verfeinerungen zum Angebot lösen. Viele
Restaurants schmeissen einen auch nicht raus, wenn man nur was trinken
will, trotzdem taggen wir die nicht mit amenity=restaurant;pub


amenity=restaurant; pension



sind für mich auch 2 POIs (eine Pension, darin ein Restaurant, oder
schlafen die Leute auf den Tischen im Restaurant?)



 amenity=pub;restaurant;bar



dito



 amenity=hospital; univeristy



auch da (Unikrankenhaus) würde ich die Uni und das Krankenhaus als 2
Objekte taggen.



 amenity=bank;atm



sind 2 features m.E. ein way (bank), darin ein node (atm)



 amenity=restaurant;bistro



was ist ein amenity=bistro? Kommt 16x vor, lt. Wiki sollen Bistros
allerdings als amenity=cafe getaggt werden. Gibt's dazu ein Proposal oder
sonst eine Definition?



 amenity=bench;shelter



eine überdachte Sitzbank? Wären m.E. building=roof und amenity=bench, oder
ggf. amenity=bench, shelter=yes?



 amenity=drinking_water; waste_disposal



abartig
 ...

die ganze Liste sieht so aus, als könnte man das jeweils besser ohne
Semikolon repräsentieren, weil man sonst bei den weiteren tags auch wieder
das Problem hat, dass man nicht weiss, zu welchem Objekt sie gehören (sehr
oft sind das nicht kombinierte Objekte (Schweizer Taschenmesser) sondern
mehrere Objekte, die der Mapper zusammengefasst hat, weil sie sich im
selben Raum befinden.


highway=residential;unclassified (134x laut taginfo)
 highway=path;track (68x laut taginfo)
 highway=traffic_signals;crossing (62x)
 highway=unclassified;residential (44)
 highway=residential;track (43)



sind wohl fixmes, wo unerfahrene Mapper Straßen-ways kombiniert haben,
die nicht kombiniert werden konnten.



 Das sind offensichtlich gar nicht so viele, aber ich will nicht wissen,
 wie oft eins von beidem weggelassen wird, weil es eben keine
 Unterstützung für die Kombitags gibt, oder wie oft eine Einrichtung aus
 demselben Grund doppelt in OSM auftaucht.


im Einzelnen:
residential;unclassified (und vice versa): unclassified (die höhere Straße
gewinnt in OSM).
path;track: unmöglich, entweder schmaler als ein Auto (path) oder nicht
(track).
residential;track: unmöglich, entweder Land- und Forstwirtschaftlicher Weg
oder Wohnstraße



 Hotel/Restaurant ist häufig kombiniert, und oft lässt es sich eigentlich
 nicht sinnvoll räumlich trennen.



oft/meist haben die sogar getrennte Eingänge. Sind praktisch immer
getrennt: Schankstube und Zimmer.



 Cafe/Restaurant dürfte noch ähnlich oft vorkommen.

 weitere Kombinationen, die bestimmt häufig sind:
 Sauna und Schwimmbad



Sauna im Schwimmbad



 Sauna und Fitness-Studio



Sauna im Fitness-Studio



 Mülleimer und Straßenlaterne (auch wenn beides oft nicht eingetragen wird)



wobei das nicht zusammengehört, m.E. 2 nodes. Wenn Du darauf hinauswillst,
dass die Laterne am gleichen Mast hängt wie der Mülleimer, dann mappe doch
als erstes mal den Mast ;-)




 Und ich finde die Situation eigentlich unbefriedigend, dass ich einen
 Laden, der mittags warme Küche hat, abends als Kneipe läuft und spät
 abends bzw. am Wochenende zur Disco mutiert, nicht gleichzeitig als
 alles taggen kann.



kannst Du ja, conditional tags.




 Sollen wir jetzt zusätzliche Tags für gängige Kombinationen finden?
 Ich bin mir nicht sicher, ob das wirklich die bessere Lösung wäre




wie gesagt, das meiste sind keine Kombinationen, nur in OSM ;-)

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

Re: [Talk-de] Highway Shields (Strassennummern)

[Hartmut Holzgraefe]

On 01/14/2014 02:23 PM, Martin Koppenhoefer wrote:

 amenity=restaurant; pension

 sind für mich auch 2 POIs (eine Pension, darin ein Restaurant, oder
 schlafen die Leute auf den Tischen im Restaurant?)

hatte gerade wieder die Variante das der Frühstücksraum
von Hotel X abends zu Weinstube Y mutiert und über Nacht
wieder zurück ... ;)

  http://osm.org/go/0HoHiHDDG?m=

Aber selbst das sind zwei Nodes für mich ...

-- 
hartmut

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

[Talk-de] Highway Shields (Strassennummern)

[Frederik Ramm]

Hallo,

   in Nordamerika sind sie ganz wild darauf, richtige highway shields
zu zeichnen. Bei denen hat ein- und dieselbe Strasse manchmal 8
verschiedene Nummern, die noch dazu jeweils in unterschiedlichen Arten
von Kaestchen zu zeichnen sind.

http://elrond.aperiodic.net/shields/?zoom=14lat=39.76391lon=-86.02913layers=B0

ist ein schoenes Beispiel, und hier

http://vimeopro.com/openstreetmapus/state-of-the-map-us-2013/video/68097487

ein Talk von Phil Gold, in dem er erklaert, wie er mit Hilfe von Python
und fiesen Hacks mit planet_osm_rels solche komplizierten Shields bastelt.

Bei uns hingegen scheint diese Thematik niemand hinter dem Ofen
hervorzulocken. Ich bin da jetzt kein Experte, aber dieses Stueck
Autobahn in der Bildmitte hier

http://www.openstreetmap.de/karte.html?zoom=13lat=48.7544lon=9.02627layers=B000TT

ist z.B. gleichzeitig A81 und A8. Es ist im Stil ueberhaupt nicht
benummert, weil bei uns die Nummern nicht nach Relationen, sondern nach
ref-Tags gesetzt werden, und das ref fuer diese Autobahn ist
offenbar A 8;A 81. Der Stil hat aber keine Shields fuer 8-stellige
Nummern, und daher kommt hier gar nix ;)

Hat sich jemand schonmal Gedanken gemacht, wie man das loesen sollte -
sollen wir einfach auch auf den amerikanischen Zug mit aufspringen, oder
waere das fuer D-A-CH-Verhaeltnisse mit Kanonen auf Spatzen geschossen?

(Ich poste das hier auch mal ins Forum, weil ich weiss, dass da ein paar
Routenspezialisten unterwegs sind.)

Bye
Frederik

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

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

Re: [Talk-de] Highway Shields (Strassennummern)

[Martin Vonwald]

Hi!

Am 13. Januar 2014 20:05 schrieb Frederik Ramm frede...@remote.org:

 Ich bin da jetzt kein Experte, aber dieses Stueck
 Autobahn in der Bildmitte hier


 http://www.openstreetmap.de/karte.html?zoom=13lat=48.7544lon=9.02627layers=B000TT

 ist z.B. gleichzeitig A81 und A8. Es ist im Stil ueberhaupt nicht
 benummert, weil bei uns die Nummern nicht nach Relationen, sondern nach
 ref-Tags gesetzt werden, und das ref fuer diese Autobahn ist
 offenbar A 8;A 81. Der Stil hat aber keine Shields fuer 8-stellige
 Nummern, und daher kommt hier gar nix ;)


Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich
Gedanken darüber machen den verschiedensten Tools und Anwendungen den
Umgang mit Strichpunkt-separierten Werten beizubringen.

Beste Grüße,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Highway Shields (Strassennummern)

[Frederik Ramm]

Hi,

On 13.01.2014 20:13, Martin Vonwald wrote:
 Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich
 Gedanken darüber machen den verschiedensten Tools und Anwendungen den
 Umgang mit Strichpunkt-separierten Werten beizubringen.

Oder man geht komplett vom ref weg, zumindest bei Autobahnen und
Bundesstrassen, und rendert die Nummern nach Mitgliedschaft in einer
Routenrelation, das ginge auch. Bei Buslinien taggen wir ja auch nicht
an die Strasse dran bus=Bus 171;Bus 59; Bus 28 ;)

Bye
Frederik

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

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

Re: [Talk-de] Highway Shields (Strassennummern)

[Peter Wendorff]

Hi,
jetzt fängst du aber mit Ausweichtaktiken an.
Es fehlt doch offensichtlich ganz generell an der Softwareunterstützung
für mehrwertige Tags, da ist ref doch bei weitem kein Einzelfall, oder
hat sich das mittlerweile so stark gewandelt?

Beispiele bei der Suche nach amenity-Keys, die ein Semikolon enthalten:

amenity=parking;fuel (4523, wobei viele davon vom AND-Import kommen)
amenity=restaurant;cafe (44)
amenity=restaurant; pension
amenity=pub;restaurant;bar
amenity=hospital; univeristy
amenity=fast_food;cafe
cuisine=italian;ice_cream
amenity=fuel; garage
amenity=fuel;compressed_air
amenity=pharmacy;post_office;vending_machine
amenity=bank;atm
amenity=restaurant;bistro
amenity=bench;shelter
amenity=drinking_water; waste_disposal
amenity=bank;post_office
amenity=post_office;bank
amenity=parcel_box;post_box
amenity=cafe;pub;restaurant
amenity=post_box; telphone
amenity=restaurant;biergarten
amenity=vending_machine;waste_basket
amenity=hospital; pharmacy
amenity=fitness_center;sauna
amenity=restaurant;pub
amenity=pub;restaurant
amenity=restaurant; hotel
tourism=guest_house; hotel
amenity=nightclub;pub
amenity=cafe;post_office
amenity=theatre;cinema
amenity=theatre; school
amenity=cafe;arts_centre
shop=kiosk;car_repair
amenity=doctors; dentist
amenity=recycling;waste_container
amenity=language_school;something else (!!! ;) )
amenity=doctors; pharmacy
amenity=fuel;compressed_air;car_wash
amenity=bar;restaurant (71)
amenity=public_building; toilets
amenity=waste_basket;bench
amenity=waste_basket;recycling (170)
amenity=place_of_worship;graveyard
amenity=cafe;pub;nightclub
amenity=restaurant;guest_house
amenity=bench;fountain
amenity=public_building; social_facility
amenity=college;education_centre
cuisine=pizza;kebab
amenity=bar;community_centre
amenity=restaurant;ice_cream
amenity=bar;nightclub
amenity=kindergarten;school
amenity=bar;casino
amenity=charging_station;bicycle_parking
amenity=toilets;shower
amenity=swimming_pool;sauna;gym
amenity=school;place_of_worship (88)
amenity=parking;restaurant;fuel (50)

highway=residential;unclassified (134x laut taginfo)
highway=path;track (68x laut taginfo)
highway=traffic_signals;crossing (62x)
highway=unclassified;residential (44)
highway=residential;track (43)

Das sind offensichtlich gar nicht so viele, aber ich will nicht wissen,
wie oft eins von beidem weggelassen wird, weil es eben keine
Unterstützung für die Kombitags gibt, oder wie oft eine Einrichtung aus
demselben Grund doppelt in OSM auftaucht.

Hotel/Restaurant ist häufig kombiniert, und oft lässt es sich eigentlich
nicht sinnvoll räumlich trennen.
Cafe/Restaurant dürfte noch ähnlich oft vorkommen.

weitere Kombinationen, die bestimmt häufig sind:
Sauna und Schwimmbad
Sauna und Fitness-Studio
Mülleimer und Straßenlaterne (auch wenn beides oft nicht eingetragen wird)

Und ich finde die Situation eigentlich unbefriedigend, dass ich einen
Laden, der mittags warme Küche hat, abends als Kneipe läuft und spät
abends bzw. am Wochenende zur Disco mutiert, nicht gleichzeitig als
alles taggen kann.

Sollen wir jetzt zusätzliche Tags für gängige Kombinationen finden?
Ich bin mir nicht sicher, ob das wirklich die bessere Lösung wäre

Gruß
Peter



Am 13.01.2014 20:30, schrieb Frederik Ramm:
 Hi,
 
 On 13.01.2014 20:13, Martin Vonwald wrote:
 Wie ich erst vor kurzem auf tagging schrieb: schön langsam sollte man sich
 Gedanken darüber machen den verschiedensten Tools und Anwendungen den
 Umgang mit Strichpunkt-separierten Werten beizubringen.
 
 Oder man geht komplett vom ref weg, zumindest bei Autobahnen und
 Bundesstrassen, und rendert die Nummern nach Mitgliedschaft in einer
 Routenrelation, das ginge auch. Bei Buslinien taggen wir ja auch nicht
 an die Strasse dran bus=Bus 171;Bus 59; Bus 28 ;)
 
 Bye
 Frederik
 


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

Re: [Talk-de] highway=abandoned

[tumsi]

 Original-Nachricht 
Betreff: Re: [Talk-de] highway=abandoned
Datum: Wed Aug 21 2013 20:19:21 GMT+0200
Von: Michael von Glasow mich...@vonglasow.com
An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org


ich meine, es gab schon einige Diskussionen darüber, ob man
historische Daten in OSM aufnehmen sollte, und wenn ich mich richtig
entsinne, ist die mehrheitliche Aussage, dass nur das gemappt wird, was
vor Ort noch real existiert. (Ausnahmen gibt es vielleicht noch für
Objekte, die im Bau oder geplant sind, also in absehbarer Zeit echte
Objekte werden.)


Das kann ich nachvollziehen, wenn ich z.B. an Diskussionen denke, die in 
Bezug auf das Eintragen von temporären Veranstaltungen 
(Weihnachtsmräkte, regelmäßige Flohmärkte etc) auftreten.



Wenn vor Ort noch Reste der Straße vorhanden sind (zum Teil bleiben ja
stillgelegte Straßen noch lang bestehen und es wird nur an der Zufahrt
eine Absperrung hingesetzt), sehe ich es noch als gerechtfertigt an, so
etwas zu mappen - aber eben nur, solange vor Ort noch Reste einer Straße
erkennbar sind. Von mir aus kann dann auch noch ein old_ref/old_name-Tag
daran hängen, das tut nicht weiter weh.


Vollkommen einverstanden damit...


Wenn an der Stelle aber inzwischen nur noch Wiese, Wald oder gar ein
Neubaugebiet ist, sind das nur noch historische Daten. Mag sein, dass
auch die interessant sind, aber das gehört IMHO dann nicht mehr in OSM.
Wer sich für solche Daten interessiert, kann sich ja einen OSM-Klon
hochziehen und mit historischen Daten befüllen, dann auch noch mit Tags,
von wann bis wann das Objekt existierte...


Sehe ich ebenfalls so. An eigentlich allen Stellen, die ich gesehen 
habe, ist heute entweder Wiese oder Wald, Bebauung oder ein vollkommen 
anderer Straßenverlauf, der den alten komplett überdeckt (z.B. [1]).


Auch ist für mich die Quelle der Daten nicht klar. Klar, kann das eigene 
Erinnerung sein, aber der neue Straßenverlauf existiert geschätzt 
mindestens 10 Jahre. Ich werde den Nutzer mal anschreiben (Anmeldung 
März 2013).


Viele Grüße,
Constanze


[1] http://www.openstreetmap.org/browse/way/231558005


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

Re: [Talk-de] highway=abandoned

[Martin Koppenhoefer]

Il giorno 22/ago/2013, alle ore 09:43, tumsi tu...@gmx.de ha scritto:
 
 ich meine, es gab schon einige Diskussionen darüber, ob man
 historische Daten in OSM aufnehmen sollte, und wenn ich mich richtig
 entsinne, ist die mehrheitliche Aussage, dass nur das gemappt wird, was
 vor Ort noch real existiert.
 
 Das kann ich nachvollziehen, wenn ich z.B. an Diskussionen denke, die in 
 Bezug auf das Eintragen von temporären Veranstaltungen (Weihnachtsmräkte, 
 regelmäßige Flohmärkte etc) auftreten.


ein typisches Beispiel ist da z.B. das Burning Man Festival, das es schon seit 
Urzeiten in osm gibt, das es jedes Jahr nur für kurze Zeit gibt, und das 
jeweils an (geringfügig) anderem Ort stattfindet. Das wurde bisher immer vor 
allem positiv kommentiert


 
 Wenn vor Ort noch Reste der Straße vorhanden sind (zum Teil bleiben ja
 stillgelegte Straßen noch lang bestehen und es wird nur an der Zufahrt
 eine Absperrung hingesetzt), sehe ich es noch als gerechtfertigt an, so
 etwas zu mappen - aber eben nur, solange vor Ort noch Reste einer Straße
 erkennbar sind. Von mir aus kann dann auch noch ein old_ref/old_name-Tag
 daran hängen, das tut nicht weiter weh.


Reste wird es wohl fast immer geben, nur erkennt die evtl. nicht jeder


 Wenn an der Stelle aber inzwischen nur noch Wiese, Wald oder gar ein
 Neubaugebiet ist, sind das nur noch historische Daten.


Ein Neubaugebiet dürfte einer der Fälle sein
 Mag sein, dass
 auch die interessant sind, aber das gehört IMHO dann nicht mehr in OSM.
 Wer sich für solche Daten interessiert, kann sich ja einen OSM-Klon
 hochziehen und mit historischen Daten befüllen, dann auch noch mit Tags,
 von wann bis wann das Objekt existierte...
 
 Sehe ich ebenfalls so. An eigentlich allen Stellen, die ich gesehen habe, ist 
 heute entweder Wiese oder Wald, Bebauung oder ein vollkommen anderer 
 Straßenverlauf, der den alten komplett überdeckt (z.B. [1]).
 
 Auch ist für mich die Quelle der Daten nicht klar. Klar, kann das eigene 
 Erinnerung sein, aber der neue Straßenverlauf existiert geschätzt mindestens 
 10 Jahre. Ich werde den Nutzer mal anschreiben (Anmeldung März 2013).
 
 Viele Grüße,
 Constanze
 
 
 [1] http://www.openstreetmap.org/browse/way/231558005
 
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] highway=abandoned

[Martin Koppenhoefer]

zu früh losgeschickt 

Il giorno 22/ago/2013, alle ore 12:14, Martin Koppenhoefer 
dieterdre...@gmail.com ha scritto:

 
 
 Il giorno 22/ago/2013, alle ore 09:43, tumsi tu...@gmx.de ha scritto:
 
 ich meine, es gab schon einige Diskussionen darüber, ob man
 historische Daten in OSM aufnehmen sollte, und wenn ich mich richtig
 entsinne, ist die mehrheitliche Aussage, dass nur das gemappt wird, was
 vor Ort noch real existiert.
 
 Das kann ich nachvollziehen, wenn ich z.B. an Diskussionen denke, die in 
 Bezug auf das Eintragen von temporären Veranstaltungen (Weihnachtsmräkte, 
 regelmäßige Flohmärkte etc) auftreten.
 
 
 ein typisches Beispiel ist da z.B. das Burning Man Festival, das es schon 
 seit Urzeiten in osm gibt, das es jedes Jahr nur für kurze Zeit gibt, und 
 das jeweils an (geringfügig) anderem Ort stattfindet. Das wurde bisher immer 
 vor allem positiv kommentiert
 
 
 
 Wenn vor Ort noch Reste der Straße vorhanden sind (zum Teil bleiben ja
 stillgelegte Straßen noch lang bestehen und es wird nur an der Zufahrt
 eine Absperrung hingesetzt), sehe ich es noch als gerechtfertigt an, so
 etwas zu mappen - aber eben nur, solange vor Ort noch Reste einer Straße
 erkennbar sind. Von mir aus kann dann auch noch ein old_ref/old_name-Tag
 daran hängen, das tut nicht weiter weh.
 
 
 Reste wird es wohl fast immer geben, nur erkennt die evtl. nicht jeder
 
 
 Wenn an der Stelle aber inzwischen nur noch Wiese, Wald oder gar ein
 Neubaugebiet ist, sind das nur noch historische Daten.
 
 
 Ein Neubaugebiet dürfte einer der Fälle sein, dass wirklich die Spuren 
 komplett verwischt sind, ansonsten wird es wohl praktisch immer noch 
 irgendwelche Spuren geben von Straßen oder Bahnlinien



  
 
 Wer sich für solche Daten interessiert, kann sich ja einen OSM-Klon
 hochziehen und mit historischen Daten befüllen, dann auch noch mit Tags,
 von wann bis wann das Objekt existierte...


gibt es schon ohm die Open historical Map, hat auch eine eigene ML auf dem OSMF 
 Server
 
 Sehe ich ebenfalls so. An eigentlich allen Stellen, die ich gesehen habe, 
 ist heute entweder Wiese oder Wald, Bebauung oder ein vollkommen anderer 
 Straßenverlauf, der den alten komplett überdeckt (z.B. [1]).


Überdeckung heißt ja, dass es noch Spuren gibt, wenn auch Unterirdisch?



 Auch ist für mich die Quelle der Daten nicht klar.


das ist ja kein Problem, es reicht aus, dass die Quellen zulässig sind und 
demjenigen klar, der das einträgt ;-)


 Ich werde den Nutzer mal anschreiben (Anmeldung März 2013).


ja, mach das, ist die beste Herangehensweise und m.E. das erste, was man bei 
Zweifeln tun sollte

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

Re: [Talk-de] highway=abandoned

[Garry]

Am 21.08.2013 14:16, schrieb Alexander Lehner:


Das taete mich auch interessieren - ich hab hier eine stillgelegte, 
teils abgerissene, teils zum Radweg umfunktionierte
Bahnstrecke die als abandomed markiert ist. Ist zwar historisch 
interessant, aber ich frage mich auch, woher der Autor eigentlich 
diese Daten hat?
Ehmaligen Bahntrassen lassen sich meist relativ leicht im Gelände 
erkennnen. Dazu geben alte Karten und Bilder, Schattierungen in 
Luftaufnahmen etc. Auskunft über den ehmaligen Verlauf. Und Zeitzeugen 
gibt es meist auch noch genügend.


Garry

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

Re: [Talk-de] highway=abandoned

[Bernhard Weiskopf]

Hallo an alle,

solange alte Strukturen, z. B. Straßen oder Gebäude, noch auf Luftbildern
erscheinen könnten, lösche ich sie nicht, sondern setze vor die relevanten
Tags abandoned: 

Dann werden diese Strukturen von den Renderern nicht mehr dargestellt, aber
von den Editoren. So kann nicht mehr vorkommen, dass jemand das nicht mehr
Existente von einem alten Luftbild ausgehend wieder einträgt.

Ich habe aber auch schon mal eine nicht mehr existente Straße eingetragen,
von der man praktisch nichts mehr sieht. Parallel dazu stehen aber noch alte
Baumreihen und ähnliches und die Linie, die nur im Editor zu sehen ist,
dient als Hilfslinie zum Ausrichten der parallelen Strukturen.

Viele Grüße

Bernhard



 -Ursprüngliche Nachricht-
 Von: tumsi [mailto:tu...@gmx.de]
 Gesendet: Mittwoch, 21. August 2013 13:31
 An: talk-de@openstreetmap.org
 Betreff: [Talk-de] highway=abandoned
 
 Hallo zusammen,
 
 Ich bin gerade in meiner Region auf neue Edits gestossen, wo alte und
 mittlerweile teilweise nicht mehr existierende Straßen gemappt wurden.
 Getaggt sind diese Linien mit highway=abandoned und old_ref=xyz. Ich
 finde das ganze etwas seltsam, vor allem, wenn man vor Ort nicht einmal
 mehr erkennen kann, dass dort irgendwann einmal Straßen existierten!
 Welchen Wert hat das ganze in der Datenbank? Ich mappe doch auch keine
 Gebäude, die abgerissen wurden und an deren Stelle nun neue Gebäude
 stehen...
 
 Wie seht ihr das?
 
 Viele Grüße,
 Constanze
 
 ___
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-de


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

[Talk-de] highway=abandoned

[tumsi]

Hallo zusammen,

Ich bin gerade in meiner Region auf neue Edits gestossen, wo alte und 
mittlerweile teilweise nicht mehr existierende Straßen gemappt wurden. 
Getaggt sind diese Linien mit highway=abandoned und old_ref=xyz. Ich 
finde das ganze etwas seltsam, vor allem, wenn man vor Ort nicht einmal 
mehr erkennen kann, dass dort irgendwann einmal Straßen existierten! 
Welchen Wert hat das ganze in der Datenbank? Ich mappe doch auch keine 
Gebäude, die abgerissen wurden und an deren Stelle nun neue Gebäude 
stehen...


Wie seht ihr das?

Viele Grüße,
Constanze

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

Re: [Talk-de] highway=abandoned

[Alexander Lehner]

On Wed, 21 Aug 2013, tumsi wrote:


Hallo zusammen,

Ich bin gerade in meiner Region auf neue Edits gestossen, wo alte und 
mittlerweile teilweise nicht mehr existierende Straßen gemappt wurden. 
Getaggt sind diese Linien mit highway=abandoned und old_ref=xyz. Ich finde 
das ganze etwas seltsam, vor allem, wenn man vor Ort nicht einmal mehr 
erkennen kann, dass dort irgendwann einmal Straßen existierten! Welchen Wert 
hat das ganze in der Datenbank? Ich mappe doch auch keine Gebäude, die 
abgerissen wurden und an deren Stelle nun neue Gebäude stehen...


Wie seht ihr das?


Das taete mich auch interessieren - ich hab hier eine 
stillgelegte, teils abgerissene, teils zum Radweg umfunktionierte
Bahnstrecke die als abandomed markiert ist. Ist zwar historisch 
interessant, aber ich frage mich auch, woher der Autor eigentlich diese 
Daten hat?


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

Re: [Talk-de] highway=abandoned

[Volker Schmidt]

 Das taete mich auch interessieren - ich hab hier eine stillgelegte, teils
 abgerissene, teils zum Radweg umfunktionierte
 Bahnstrecke die als abandomed markiert ist. Ist zwar historisch
 interessant, aber ich frage mich auch, woher der Autor eigentlich diese
 Daten hat?


Ich habe - in Italien, wo ich wohne -  mehrere alte, stillgelegte, und mehr
oder weniger noch im Verlauf erkennbare Bahnstrecken in OSM eingetragen.
Dass Interesse ist einerseits natuerlich historisch, aber vor allem auch
nuetzlich, wenn es sich um Wiederverwendung der alten Bahntrasse dreht: Von
den drei Faellen, die mir spontan einfallen, sind alle teilweise zu
Radwegen oder Radrouten geworden. Wo (noch) keine neue Nutzung vorliegt,
habe ich einfach nur einen way mit railway=abandoned eingetragen.
Allerdings sind praktisch ueberall noch deutliche Spuren des alten Verlaufs
auf den Lufbildern zu erkennen - die sind die Quelle der Informationen in
meinem Fall.

Fuer eine der drei existiert auch eine relation (1860446) als ehemalige
Bahnstrecke. Dabei handelt es sich um eine in Italien relaitiv bekannte
ehemalige Strecke, die - hoffentlich in absehbare Zukunft - eine komplette
Radroute wird.
Fuer die Radroute - wo sie schon existiert -  existiert eine getrennte
relation 2375471.

Das tagging ist dummerweise nicht einheiltich durchgefuehrt. Da gibt es
verschiedene Ansaetze.

Beispiel fuer den Ansatz ohne relation: ehemalige Vorort.Bahn in Padova.
Dort habe ich noch keine ralation verwendet, aber highways mit
railway=abandoned getaggt  (Beispiel:
http://www.openstreetmap.org/browse/way/135251969)

Von dieser Kategorie gibt es viele, teilweise auch grenz-uberschreitende.
Eine weitere die mir gerade einfaellt, ist die beruehmte Parenzana (
https://de.wikipedia.org/wiki/Parenzana) in Italien -Slowenien - Kroatien
(ex k.u.k. Bahnstrecke). In OSM relation 1775016, in diesem Falle als
regional cycle network.

Auf jeden Fall wuerde ich alte Bahnstrecken, wo im Gelaende noch erkennbar,
als solche eintragen.

Volker
(Padova, Italien)
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] highway=abandoned

[Michael von Glasow]

Hallo,

ich meine, es gab schon einige Diskussionen darüber, ob man 
historische Daten in OSM aufnehmen sollte, und wenn ich mich richtig 
entsinne, ist die mehrheitliche Aussage, dass nur das gemappt wird, was 
vor Ort noch real existiert. (Ausnahmen gibt es vielleicht noch für 
Objekte, die im Bau oder geplant sind, also in absehbarer Zeit echte 
Objekte werden.)


Wenn vor Ort noch Reste der Straße vorhanden sind (zum Teil bleiben ja 
stillgelegte Straßen noch lang bestehen und es wird nur an der Zufahrt 
eine Absperrung hingesetzt), sehe ich es noch als gerechtfertigt an, so 
etwas zu mappen - aber eben nur, solange vor Ort noch Reste einer Straße 
erkennbar sind. Von mir aus kann dann auch noch ein old_ref/old_name-Tag 
daran hängen, das tut nicht weiter weh.


Wenn an der Stelle aber inzwischen nur noch Wiese, Wald oder gar ein 
Neubaugebiet ist, sind das nur noch historische Daten. Mag sein, dass 
auch die interessant sind, aber das gehört IMHO dann nicht mehr in OSM. 
Wer sich für solche Daten interessiert, kann sich ja einen OSM-Klon 
hochziehen und mit historischen Daten befüllen, dann auch noch mit Tags, 
von wann bis wann das Objekt existierte...


Grüße
Michael

On 21/08/13 13:30, tumsi wrote:

Hallo zusammen,

Ich bin gerade in meiner Region auf neue Edits gestossen, wo alte und 
mittlerweile teilweise nicht mehr existierende Straßen gemappt wurden. 
Getaggt sind diese Linien mit highway=abandoned und old_ref=xyz. Ich 
finde das ganze etwas seltsam, vor allem, wenn man vor Ort nicht 
einmal mehr erkennen kann, dass dort irgendwann einmal Straßen 
existierten! Welchen Wert hat das ganze in der Datenbank? Ich mappe 
doch auch keine Gebäude, die abgerissen wurden und an deren Stelle nun 
neue Gebäude stehen...


Wie seht ihr das?

Viele Grüße,
Constanze





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

[Talk-de] Highway=Track nicht befahrbar

[wwl]

Hallo,
ich habe gerade folgendes Problem das ich mehrere Straßen/Wege, die zwar 
Schotterwege(3-4m breit) sind aber die eigendlich Residential sein 
sollten und auch Wohnhäuser beinhalten, taggen muss. Ich habe nun 
versucht sie mit

highway=track
tracktype=grade2
zusetzen. Dies bewirkt aber auf Maps wie map.project-osrm das sie bei 
der Verkehrsführung nicht berücksichtigt werden.


Wie tagge ich die richtig?

Christian

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

Re: [Talk-de] Highway=Track nicht befahrbar

[Manuel Reimer]

wwl usenet at schani.com writes:
 ich habe gerade folgendes Problem das ich mehrere Straßen/Wege, die zwar 
 Schotterwege(3-4m breit) sind aber die eigendlich Residential sein 
 sollten und auch Wohnhäuser beinhalten, taggen muss. Ich habe nun 
 versucht sie mit
 highway=track
 tracktype=grade2

Falscher Ansatz. highway=track heißt nicht, dass das ein Schotterweg, sondern
ein Wirtschaftsweg ist. Die können auch geteert sein und haben manchmal sogar
besseren Zustand als manche Straße in einer Ortschaft.

Soll heißen: Das Track hat überhaupt nichts mit der Oberfläche des Weges zu
tun. Dafür gibt es das surface-Tag.

 Wie tagge ich die richtig?

highway=residential
surface=gravel
name=[Hier Straßenname eintragen]

Gruß

Manuel


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

Re: [Talk-de] Highway=Track nicht befahrbar

[wwl]

schrieb Manuel Reimer:

wwl usenet at schani.com writes:

ich habe gerade folgendes Problem das ich mehrere Straßen/Wege, die zwar
Schotterwege(3-4m breit) sind aber die eigendlich Residential sein
sollten und auch Wohnhäuser beinhalten, taggen muss. Ich habe nun
versucht sie mit
highway=track
tracktype=grade2


Falscher Ansatz. highway=track heißt nicht, dass das ein Schotterweg, sondern
ein Wirtschaftsweg ist. Die können auch geteert sein und haben manchmal sogar
besseren Zustand als manche Straße in einer Ortschaft.

Soll heißen: Das Track hat überhaupt nichts mit der Oberfläche des Weges zu
tun. Dafür gibt es das surface-Tag.


Wie tagge ich die richtig?


highway=residential
surface=gravel
name=[Hier Straßenname eintragen]

Gruß

Manuel


OK das leuchtet ein.

Danke

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Martin Koppenhoefer]

Am 17. Mai 2012 19:52 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 Bleibt die Frage, wie detailliert man werden *muss*. Wenn ich detailliert
 sehen will, wie ein Gebiet aussieht, dann brauche ich keine von jemandem
 abgemalte Variante, sondern kann ein Luftbild verwenden.


solange Du das so siehst brauchen wir im Prinzip nicht
weiterzudiskutieren, ich mache mir aber trotzdem mal die Mühe und
versuche, Dich vom Gegenteil zu überzeugen. Ein Luftbild ist keine
Alternative zu einer Karte sondern eine Ergänzung. Sehr viele Dinge
kann man darauf aber nicht erkennen oder nur, wenn man weiss, dass sie
da sind. Das geht los mit Wegen durch Gebäude (wo ich diese Woche
kartiere ist das die halbe (Alt-)-Stadt), mit Dingen die entscheidend
sind für die Navigation aber zu klein, um aufzutauchen (z.B. Poller),
vor allem aber auch Informationen wie Namen, Objektklassen
(Beschreibungen, was etwas ist) und Zusatzattribute, Zusammenhänge,
etc.

Es gab schon immer detaillierte Karten und ihre Berechtigung haben sie
durch Luftbilder nicht verloren. Geodatenbanken gehen da noch einen
Schritt weiter und erlauben eine Strukturierung und Attributierung der
Daten auch jenseits dessen, was man räumlich auf einer Karte
darstellen kann.


 Welcher Einsteiger soll sich in dem Linienverhau, der da für einen einzigen
 Straßenverlauf eingezeichnet wird, noch zurechtfinden?


mit der Area-Relation werden die Linien auf ein Mindestmaß reduziert,
weil Querlinien zum Schließen der Flächen wegfallen. Da hat man dann
lediglich die beiden äusseren Kanten als Begrenzung. Evtl. könnte man
diese als Gehwege benutzten zum Routing, dann wären es gleich viele
Linien wie es jetzt schon da gibt, wo die Gehwege explizit gezeichnet
werden.

Es geht bei den Highway-Flächen aber auch um Ästhetik. Manchen Leuten
ist das wichtiger, andere finden das vernachlässigbar. M.E. sind
Ästhetik und Karten aber seit jeher eng verbunden. Abseits von Straßen
sind Verkehrsflächen eben oft nur unzureichend oder gar nicht linear
repräsentierbar.


 Was muss ich als Mapper tun, wenn ich via GPS diesen Straßenverlauf anders
 erfasst habe, bzw. wenn etwas neues gebaut wurde, und ich das einzeichnen
 will?


Was meinst Du mit via GPS? In diesen Maßstäben kannst Du es mit
Consumer-GPS vergessen, Du machst Dir am besten Fotos zur
Unterstützung und zeichnest Freihand, sofern es keine hochaufgelösten
Luftbilder gibt.


 Ist ab dann der von $LUFTBILD abgepinselte Verlauf als einzig richte Lösung
 felsenfest zementiert oder darf ich meine Beobachtungen noch einzeichnen?


Man braucht keine Luftbilder, man muss die Örtlichkeit gut kennen. Es
reichen gute OSM-Karten aus, um weitere Details einzuzeichnen, man
muss nur wissen, was man wo unterbringen will.


 Wenn ich meine Beobachtungen und Änderungen einbringe: Muss ich das rein
 optische Gepinsel dann auch nachziehen oder darf man das genau so (falsch)
 stehen lassen, wie es steht?


polemische Frage, weil ich davon ausgehe, dass jeder so gut er kann
kartiert. Ist aber natürlich immer ein iterativer Prozess, wo man
hofft, dass es im Laufe der Zeit immer besser wird.


 Und vor allem: Was tun, wenn jemand ein Gebiet mit dieser Überdetaillierung
 verschlimmbessert hat, die zugrundeliegenden Wege aber mittlerweile
 mehrfach geändert und verbessert wurden? Darf man die falschen
 highway-Flächen nach einer angemessenen Zeit auch raushauen?


Überdetaillierung? Über was? Über dem, was für Routing nötig ist? Oder
für eine Weltkarte?
Raushauen? Klingt schon wieder abwertend. Die meisten Mapper finden es
sicher nicht besondes toll, wenn Du ihre Details raushaust.
Konstruktiver wäre es, das zu verbessern oder falls Du keine Lust dazu
hast wenigstens zu warten, dass jemand anderes es verbessert.

Gruß Martin

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Manuel Reimer]

Volker Schmidt wrote:

Das muss einfacher gehn, oder es wird im Zweifelsfall von nur wenigen
Experten benutzt.


Sehe ich auch so.


Highway=steps mit width ist voeelig ausreichend. Wenn ich eine breite,
gebogene Monumentaltreppe habe, zerlege ich sie in mehrere ways, jeder z.B.
10m breit und ordne die ways entsprechend an.


Volle Zustimmung. Wobei man hier eventuell sogar für ganz wenige Fälle 
tatsächlich eine Fläche malen könnte, diese aber dann lediglich für die Optik 
einzeichnet (ählich wie bei breiten Flüssen). Die Treppe, die dann eventuell 
auch ein Routing-Programm nutzt, dann weiterhin als Weg einzeichnen.


Aber es geht noch viel übler:

http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway

Geht definitiv auch mit width= und wäre dann auch für den Einsteiger noch 
verständlich. Wenn man sowas liest, dann fragt man sich, was OSM eigentlich ist. 
Ein Projekt, welches eine Landkarte erstellen will, oder ein Projekt, das eine 
Landschaft abmalt.


IMHO sollte Mapnik unbedingt so erweitert werden, dass es mit width= umgehen 
kann. Meinetwegen auch nur im höchsten Zoom-Modus. So würde man solchen 
Forderungen schon im Voraus den Wind aus den Segeln nehmen.


Gruß

Manuel


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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Martin Koppenhoefer]

Am 17. Mai 2012 13:30 schrieb Manuel Reimer manuel.s...@nurfuerspam.de:
 Highway=steps mit width ist voeelig ausreichend. Wenn ich eine breite,
 gebogene Monumentaltreppe habe, zerlege ich sie in mehrere ways, jeder
 z.B.
 10m breit und ordne die ways entsprechend an.
 Volle Zustimmung.


ich bleibe dabei, 10 Treppen mit 10m Breite sind nicht dasselbe wie
eine Freitreppe mit 100m Breite. Abgesehen davon geht es praktisch
nicht, eine 100m breite Treppe, die nur relativ kurz ist, so genau zu
positionieren, dass sie lagerichtig eingezeichnet ist (da geringste
Abweichungen bereits riesige Auswirkungen haben). Die Anschlüsse von
evtl. seitlich mündenden Wegen sind ausserdem dann ziemlich anders,
wenn es auf dem Weg vom Rand zur Mitte weitere Treppen oder Wege gibt,
kann man es in bestimmten Fällen mit dieser Methode sowieso nicht
richtig abbilden.


 Aber es geht noch viel übler:
 http://wiki.openstreetmap.org/wiki/Proposed_features/area:highway

 Geht definitiv auch mit width= und wäre dann auch für den Einsteiger noch
 verständlich.


es geht alles mit width, ist aber gerade dann wenig sinnvoll, wenn
es sich um Kurven und Ausbuchtungen handelt, da müsste man zig.
Segmente zeichnen. Sobald man an der Form interessiert ist, und diese
von der üblichen Straße abweicht (also nicht einfach eine mehr oder
weniger gleichbleibende Breite hat), sind Flächen wünschenswert, z.B.
in mittelalterlichen Stadtkernen (aber nicht nur da).


 Wenn man sowas liest, dann fragt man sich, was OSM eigentlich
 ist. Ein Projekt, welches eine Landkarte erstellen will, oder ein Projekt,
 das eine Landschaft abmalt.


Es ist halt der übliche Konflikt, verschiedene Leute wollen
unterschiedliches mit den Daten anstellen, und haben daher auch
unterschiedliche Vorstellungen, wie diese repräsentiert werden sollen.
OSM ist jedenfalls keine Landkarte sondern eine Geodatenbank.
Landkarte suggeriert (unter anderem) einen bestimmten Maßstab, auf
den (m.E. jedenfalls) OSM nicht festgelegt werden sollte. Es gibt
neben Landkarten z.B. auch Lagepläne. Da ist ein ganz anderer
Detailgrad vonnöten im Vergleich zu einer Landkarte 1:5 oder
1:20.


 IMHO sollte Mapnik unbedingt so erweitert werden, dass es mit width= umgehen
 kann. Meinetwegen auch nur im höchsten Zoom-Modus. So würde man solchen
 Forderungen schon im Voraus den Wind aus den Segeln nehmen.


Bestimmte Dinge wie Topologie (was ist wo angeschlossen, z.B. Platz an
Häuser, was liegt wo dazwischen oder auf oder unter, etc.) sind in
einem abstrakten Modell mit width und linearen Wegen teilweise nicht
umzusetzen.

Ich wünsche mit mehr Toleranz. Die highway-areas, auf deren Proposal
Du oben verweist, kollidieren nicht mit dem Graphenmodell. Sie sind
wie bei Flüssen zusätzlich zu sehen, und wenn Du eine Landkarte
erstellen willst, kannst Du sie einfach weglassen.

Gruß Martin

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Manuel Reimer]

Martin Koppenhoefer wrote:

es geht alles mit width, ist aber gerade dann wenig sinnvoll, wenn
es sich um Kurven und Ausbuchtungen handelt, da müsste man zig.
Segmente zeichnen. Sobald man an der Form interessiert ist, und diese
von der üblichen Straße abweicht (also nicht einfach eine mehr oder
weniger gleichbleibende Breite hat), sind Flächen wünschenswert, z.B.
in mittelalterlichen Stadtkernen (aber nicht nur da).


Bleibt die Frage, wie detailliert man werden *muss*. Wenn ich detailliert sehen 
will, wie ein Gebiet aussieht, dann brauche ich keine von jemandem abgemalte 
Variante, sondern kann ein Luftbild verwenden. IMHO sollte sowas ohnehin einmal, 
ähnlich wie bei Google-Maps, als alternativer Layer auf osm.org angeboten werden.



Ich wünsche mit mehr Toleranz. Die highway-areas, auf deren Proposal
Du oben verweist, kollidieren nicht mit dem Graphenmodell. Sie sind
wie bei Flüssen zusätzlich zu sehen, und wenn Du eine Landkarte
erstellen willst, kannst Du sie einfach weglassen.


Die Flüsse sind im Gegensatz zu diesem Straßen-Verhau noch verständlich und 
handhabbar.


Welcher Einsteiger soll sich in dem Linienverhau, der da für einen einzigen 
Straßenverlauf eingezeichnet wird, noch zurechtfinden?


Was muss ich als Mapper tun, wenn ich via GPS diesen Straßenverlauf anders 
erfasst habe, bzw. wenn etwas neues gebaut wurde, und ich das einzeichnen will?


Ist ab dann der von $LUFTBILD abgepinselte Verlauf als einzig richte Lösung 
felsenfest zementiert oder darf ich meine Beobachtungen noch einzeichnen?


Wenn ich meine Beobachtungen und Änderungen einbringe: Muss ich das rein 
optische Gepinsel dann auch nachziehen oder darf man das genau so (falsch) 
stehen lassen, wie es steht?


Und vor allem: Was tun, wenn jemand ein Gebiet mit dieser Überdetaillierung 
verschlimmbessert hat, die zugrundeliegenden Wege aber mittlerweile mehrfach 
geändert und verbessert wurden? Darf man die falschen highway-Flächen nach 
einer angemessenen Zeit auch raushauen?


Die Frage ist hier, wie auch in anderen Themen, immer: Ab welcher Komplexität 
werden Einsteiger abgeschreckt? Ab dem Zeitpunkt, ab dem man erstmal eine 
Schulung bräuchte, bevor man bei OSM anfangen kann, hat das Projekt etwas 
grundsätzlich falsch gemacht.


Genau eine solche Abschreckungswirkung sehe ich aber in diesem Proposal für 
abgemalte Landschaften. Wenn jemand eigentlich nur in seinem Wohnblock eine 
Straße korrigieren wollte, statt einer Linie dort aber 5 oder 6 nebeneinander 
vorfindet, dann kann er entweder lange nach dem Hintergrund suchen, oder er 
überlegt sich nochmal, ob er wirklich einen Weg ändern wollte.


Gruß

Manuel


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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Volker Schmidt]

 Welcher Einsteiger soll sich in dem Linienverhau, der da für einen
 einzigen Straßenverlauf eingezeichnet wird, noch zurechtfinden?


*1

Ich habe gerade auf diese Seite:
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/area:highway
einen Diskussionsbeitrag gesetzt OSM ist kein CAD
Trifft voll und ganz auch hier zu.

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Tobias Knerr]

Am 17.05.2012 20:12, schrieb Volker Schmidt:
 Welcher Einsteiger soll sich in dem Linienverhau, der da für einen
 einzigen Straßenverlauf eingezeichnet wird, noch zurechtfinden?

Das Konzept area:highway ergänzt zu jedem highway-Way noch eine Fläche.
Wenn Flüsse verständlich und handhabbar sind, dann ist es auch
area:highway, denn es ist dasselbe Konzept.

Dass in dem Screenshot auf der Proposal-Seite als eine Fläche für eine
Straße verwendet wird, liegt daran, dass der Mapper dort Gehsteige als
eigenen highway=* einzeichnet. Ob man das machen soll, wäre hier aber
wirklich off-topic. Klar: _wenn_ es mehr als ein highway pro Straße
gibt, dann kommt natürlich auch mehr als ein area:highway in Frage.

 Ich habe gerade auf diese Seite:
 https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/area:highway
 einen Diskussionsbeitrag gesetzt OSM ist kein CAD
 Trifft voll und ganz auch hier zu.

Trifft weder hier noch dort zu. OSM ist eine geographische Datenbank und
Straßen-/Treppenflächen sind geografische Daten.

Es gibt gute Argumente dafür, andere Sachen mit höherer Priorität zu
mappen. Aber dafür, diesen Daten die Eignung für OSM prinzipiell
abzusprechen, sehe ich keine Grundlage.

Gruß,
Tobias

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Manuel Reimer]

Tobias Knerr wrote:

Das Konzept area:highway ergänzt zu jedem highway-Way noch eine Fläche.
Wenn Flüsse verständlich und handhabbar sind, dann ist es auch
area:highway, denn es ist dasselbe Konzept.


Nein. Flüsse gibt es vergleichsweise wenige und die paar, die in meiner Gegend 
als Fläche gemappt sind, bei denen ist das auch durchaus angebracht, da der 
Fluss eine Breite hat, die durchaus beträchtlich ist.


Wenn jetzt aber in jedem Wohngebiet für jede Straße statt einer Linie plötzlich 
drei oder gar 5 (mit Fußwegen links und rechts) gezeichnet werden, dann wird das 
beim Überblick über ein Wohnviertel schon mehr als unübersichtlich.



Trifft weder hier noch dort zu. OSM ist eine geographische Datenbank und
Straßen-/Treppenflächen sind geografische Daten.


Und spätestens wenn jemand anfängt, die Gänseblümchen in seinem Garten zu 
mappen, werden wir feststellen, dass es nicht sinnvoll ist, das ganze beliebig 
detailliert zu machen.


Gruß

Manuel


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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Michael Kugelmann]

Am 15.05.2012 20:48, schrieb Masi Master:
http://wiki.openstreetmap.org/wiki/DE:Stairs_modelling (ist sogar auf 
der steps-Seite verkinkt)
Es ist zwar noch nichts konkretes, aber es lohnt sich bestimmt es zu 
taggen, auch wenn es (noch) nicht gerendert wird.
Boh! Man erlaube mir einen offenen Kommentar dazu: das ist m.E. 
s kompliziert, dass ein normaler Mapper so etwas nie freiwillig 
verwenden wird: Berge von Attribute und eine super lange Seite mit 
Erklärungen schreckt Leute ab. = Ich halte den Vorschag für 
?fragwürdig? (oder wie auch immer ich das bezeichnen soll) = sollte 
ggf. noch mal überdacht werden (KISS).



Grüße,
Michael.


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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Raimond Spekking]

Am 15.05.2012 12:31, schrieb Michael Kugelmann:
 Hallo,
 
 nachdem ich große Lücken auf dem Olympiagelände in Barcelona gab, habe
 ich am Wochenende mal mithilfe der Bing-Luftbilder etwas
 gemappt/überarbeitet/ergänzt:
 http://www.openstreetmap.org/?lat=41.36477lon=2.151114zoom=18layers=M
 Zum Glück hatte ich von meinem Besuch nach der SOTM 2010 noch relativ
 gute Erinnerungen (bzw. auch Fotos/Tracks).
 
 Was aber noch offen ist:
 es gibt dort sehr breite Treppen auf der Fläche. Diese sind geschätzt
 bis zu 100m lang.
 Wie tagge ich diese? Ich bin eigentlich kein Freund von
 Flächenmalerei, aber in dem Fall frage ich mich, ob ich eine Fläche
 malen soll und diese mittels area = yes und highway = steps
 kennzeichnen soll (entsprechend den highway = pedestrian).
 

Reicht denn für den Moment nicht ein zusätzliches width=100?


Ich hoffe einfach mal, dass künftig Renderer den width-Wert auswerten
und vernünftig darstellen.

Von Treppenflächen habe ich bisher Abstand genommen.

Ähnlich lang ist z.B. die Treppe vom Kölner Hauptbahnhof zur Domplatte.
ME enthält http://www.openstreetmap.org/browse/way/16248862 alle
relevanten Parameter.

Raimond.




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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Tobias Knerr]

Am 16.05.2012 11:25, schrieb Raimond Spekking:
 Reicht denn für den Moment nicht ein zusätzliches width=100?
 
 Ich hoffe einfach mal, dass künftig Renderer den width-Wert auswerten
 und vernünftig darstellen.
 
 Von Treppenflächen habe ich bisher Abstand genommen.
 
 Ähnlich lang ist z.B. die Treppe vom Kölner Hauptbahnhof zur Domplatte.
 ME enthält http://www.openstreetmap.org/browse/way/16248862 alle
 relevanten Parameter.

ME nein. Ein width reicht zur exakten Modellierung in einem bebauten
Gebiet nur, wenn 1. die Fläche rechteckig ist und 2. der Way dann auch
perfekt im richtigen Winkel eingezeichnet wird.

Punkt 1 kommt nur selten überhaupt vor (dein Beispiel hat nach Osten
variable Breite) und Punkt 2 ist schwierig umsetzbar, vor allem
verglichen mit dem vergleichsweise simplen Einzeichnen einer Fläche
zusätzlich zum Way.

Das ist also auch nicht wirklich ein Renderer-Problem, an Treppenflächen
führt in meinen Augen kein Weg vorbei. Woran es fehlt ist eben eine
einfach zu handhabende Umsetzung und zugängliche Dokumentation davon.

Kommt sicher irgendwann, aber wohl erst wenn es auch Renderer-Entwickler
mit Interesse am Thema gibt.

Gruß,
Tobias

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Martin Koppenhoefer]

Am 16. Mai 2012 08:50 schrieb Michael Kugelmann michaelk_...@gmx.de:
 http://wiki.openstreetmap.org/wiki/DE:Stairs_modelling (ist sogar auf der
 steps-Seite verkinkt)
 Boh! Man erlaube mir einen offenen Kommentar dazu: das ist m.E. s
 kompliziert, dass ein normaler Mapper so etwas nie freiwillig verwenden
 wird:


das ist der 3D-Teil. Eine Treppe in OSM einzutragen ist überhaupt
nicht kompliziert:

1. Man erstellt eine Relation, mit den tags type=area, highway=steps,
und idealerweise noch step_count (Anzahl der Steigungen)

2. Man zeichnet die 1. Trittstufe (den vorderen, vertikalen Teil der
untersten Stufe, also wo es zum ersten Mal nach oben geht) als way und
fügt sie in die Relation ein, als Rolle gibt man lower an.

3. Man zeichnet die letzte Trittstufe (den vorderen, vertikalen Teil
der obersten Stufe) als way und fügt sie mit der Rolle upper in die
Relation ein.

Fertig.

Optional kann man noch die seitlichen Grenzen zeichnen und mit der
Rolle lateral einfügen, braucht man aber nur in Ausnahmefällen, wenn
das keine geraden Linien sind.

Worauf man achten sollte ist, dass die untere Linie (lower) und die
obere Linie (upper) der Einfachkeit halber aus der selben Anzahl nodes
bestehen sollten.

Wenn die Treppe Podeste hat (also es zwischendrin mal eben wird für
ein paar Meter), dann zerlegt man sie einfach in mehrere Teile. Ob man
dazu besser verschiedene Relationen anlegt, oder das in einer machen
kann, können wir ja mal diskutieren.

Wenn ich oben schrieb Trittstufe dann meinte das eigentlich die
vorderste Kante des Auftritts (manche Treppen haben ja auch
Unterschneidungen).

Gruß Martin

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Martin Koppenhoefer]

Am 16. Mai 2012 15:46 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 Worauf man achten sollte ist, dass die untere Linie (lower) und die
 obere Linie (upper) der Einfachkeit halber aus der selben Anzahl nodes
 bestehen sollten.


was auch nicht schlecht wäre ist, wenn die beiden Ways (oben und
unten) jeweils in dieselbe Richtung zeigen. Wenn einer von links nach
rechts und der andere von rechts nach links geht, könnte es beim
Rendern Probleme geben (andererseits können die Leute hier, die gut
programmieren können, so was sicher einfach automatisch entdecken und
einen der Wege umdrehen, man müsste ja nur jeweils die Enden verbinden
und sehen, ob sich die Verbindungen schneiden).

Gruß Martin

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Tobias Knerr]

Am 16.05.2012 15:46, schrieb Martin Koppenhoefer:
 das ist der 3D-Teil. Eine Treppe in OSM einzutragen ist überhaupt
 nicht kompliziert

Es geht sogar einfach als way mit highway=steps. ;)

Die Frage ist, wie man zusätzliche Information reinbekommt - nämlich:
* die von der Treppe eingenommene Fläche
* die Anordnung der Stufen innerhalb dieser Fläche

 1. Man erstellt eine Relation, mit den tags type=area, highway=steps,
 und idealerweise noch step_count (Anzahl der Steigungen)
 
 2. Man zeichnet die 1. Trittstufe (den vorderen, vertikalen Teil der
 untersten Stufe, also wo es zum ersten Mal nach oben geht) als way und
 fügt sie in die Relation ein, als Rolle gibt man lower an.
 
 3. Man zeichnet die letzte Trittstufe (den vorderen, vertikalen Teil
 der obersten Stufe) als way und fügt sie mit der Rolle upper in die
 Relation ein.

Wie ergibt sich daraus die Anordung der Stufen, sobald man auch Treppen
mit gebogenen Stufen mappt? Ich sehe da keine offensichtliche
Berechnungsvorschrift.

Gruß,
Tobias

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Martin Koppenhoefer]

Am 16. Mai 2012 16:07 schrieb Tobias Knerr o...@tobias-knerr.de:
 Die Frage ist, wie man zusätzliche Information reinbekommt - nämlich:
 * die von der Treppe eingenommene Fläche
 * die Anordnung der Stufen innerhalb dieser Fläche


die Fläche ergibt sich aus der Relation (obere und untere Kante werden
vorgegeben und bei Bedarf auch die Seiten). Die Stufen sind mit
gleichbleibendem Auftritt (Länge in Gehrichtung einer Stufe)
gedacht, d.h. es sind Parallelen (es werden in der Auswertung einfach
die einzelnen Punkte des oberen und unteren ways jeweils der Reihe
nach verbunden und zu Interpolation der Zwischenwerte durch ein
(step_count -1) Teile geteilt.

übrigens: man wird sowieso kaum die echten Stufenbreiten so rendern
können, dass man alle Stufen einzeln sieht (je nach Zoomstufe
natürlich), und die Stufenbreiten sind normalerweise so um die 27-30
cm, bei Freitreppen ggf. auch etwas mehr, z.B. 33/15 klingt typisch
(je flacher die Treppe ist, um so breiter müssen auch die Stufen
werden). Die genaue Angabe der Stufenanzahl könnte man für normale
Treppen also praktisch auch weglassen und es machte kaum einen
Unterschied.

Für den _sehr_ seltenen Fall von Stufen unterschiedlicher Breite (ist
im Prinzip ein Planungsfehler) müsste man halt notfalls jede Stufe
einzeln mappen. Das parametrisch erfassen zu wollen (mit letztlich
unendlich vielen Möglichkeiten) erscheint mir noch unrealistischer zu
sein.


 Wie ergibt sich daraus die Anordung der Stufen, sobald man auch Treppen
 mit gebogenen Stufen mappt? Ich sehe da keine offensichtliche
 Berechnungsvorschrift.


durch gebogene Stufen (welche mit gekurvter Aufsichtslinie?) ändert
sich nichts. Die werden wie immer in OSM durch Polygonzüge soweit
angenähert, dass sie halbwegs rund erscheinen. Die sind normalerweise
auch gleich breit, oder hast Du ein Gegenbeispiel?

Je mehr Punkte die untere (bzw. obere) Linie hat, um so mehr empfiehlt
es sich, sie andere Linie durch Parallelverschiedung (JOSM-Tool, kann
Potlatch glaub ich auch) und ggf. anschließendes Punkteverschieben zu
generieren, dann stimmt auch die Punktanzahl).

Hier z.B. eine große Frei-Treppe mit Bögen im Grundriss:
http://maps.google.it/maps?hl=dell=41.897751,12.497902spn=0.000983,0.000982t=kdeg=90z=20

man kann gut erkennen, dass das kein Hexenwerk ist.

Hier ist eine Treppe mit asymetrischen Seiten:
http://maps.google.it/maps?hl=dell=41.899779,12.486152spn=0.000731,0.001321t=kz=20

Gruß Martin

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Georg Feddern]

Moin,

Am 16.05.2012 16:07, schrieb Tobias Knerr:

Wie ergibt sich daraus die Anordung der Stufen, sobald man auch Treppen
mit gebogenen Stufen mappt? Ich sehe da keine offensichtliche
Berechnungsvorschrift.



Meines Wissens:

A)
Gebogene Treppenstufen-Vorderkanten benötigen entsprechend gebogene 
lower/upper-Linien.
Die Stufen werden dann entsprechend der Abstände der zueinander 
passenden nodes verteilt - deshalb möglichst gleiche Anzahl der Nodes in 
upper/lower Linien.
Damit sind dann auch in der Mitte tiefe Stufen und seitlich weniger 
tiefe Stufen möglich.


B)
Gebogene Seiten der Treppe benötigen entsprechend gebogene lateral-Linien.

Kombination aus A) und B) sollte auch möglich sein - zumindest lässt 
sich sowas ja geometrisch konstruieren.


Gruß
Georg


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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Jimmy_K]

Am 16.05.2012 15:46, schrieb Martin Koppenhoefer:
 Am 16. Mai 2012 08:50 schrieb Michael Kugelmann michaelk_...@gmx.de:
 http://wiki.openstreetmap.org/wiki/DE:Stairs_modelling (ist sogar auf der
 steps-Seite verkinkt)
 Boh! Man erlaube mir einen offenen Kommentar dazu: das ist m.E. s
 kompliziert, dass ein normaler Mapper so etwas nie freiwillig verwenden
 wird:

 das ist der 3D-Teil. Eine Treppe in OSM einzutragen ist überhaupt
 nicht kompliziert:

 1. Man erstellt eine Relation, mit den tags type=area, highway=steps,
 und idealerweise noch step_count (Anzahl der Steigungen)

 2. Man zeichnet die 1. Trittstufe (den vorderen, vertikalen Teil der
 untersten Stufe, also wo es zum ersten Mal nach oben geht) als way und
 fügt sie in die Relation ein, als Rolle gibt man lower an.

 3. Man zeichnet die letzte Trittstufe (den vorderen, vertikalen Teil
 der obersten Stufe) als way und fügt sie mit der Rolle upper in die
 Relation ein.

 Fertig.

 Optional kann man noch die seitlichen Grenzen zeichnen und mit der
 Rolle lateral einfügen, braucht man aber nur in Ausnahmefällen, wenn
 das keine geraden Linien sind.

 Worauf man achten sollte ist, dass die untere Linie (lower) und die
 obere Linie (upper) der Einfachkeit halber aus der selben Anzahl nodes
 bestehen sollten.

 Wenn die Treppe Podeste hat (also es zwischendrin mal eben wird für
 ein paar Meter), dann zerlegt man sie einfach in mehrere Teile. Ob man
 dazu besser verschiedene Relationen anlegt, oder das in einer machen
 kann, können wir ja mal diskutieren.

 Wenn ich oben schrieb Trittstufe dann meinte das eigentlich die
 vorderste Kante des Auftritts (manche Treppen haben ja auch
 Unterschneidungen).

 Gruß Martin

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


Ist somit im prinzipiellen Aufbau das selbe wie der Link (nur mit
Relationen aufgebaut).
Fehlt es in deiner Auflistung, oder gibt es keinen klassischen Way mit
highway=steps? Ich könnte mir vorstellen, dass dies noch viele Router
aus dem Konzept bringt.

LG Jimmy

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Volker Schmidt]

Mein Standard_Kommentar: don't overdo it.

Wir wollen eine Landkarte machen, OSM ist kein CAD-Ersatz.

Das muss einfacher gehn, oder es wird im Zweifelsfall von nur wenigen
Experten benutzt.

Highway=steps mit width ist voeelig ausreichend. Wenn ich eine breite,
gebogene Monumentaltreppe habe, zerlege ich sie in mehrere ways, jeder z.B.
10m breit und ordne die ways entsprechend an.

Gruss

Volker

2012/5/16 Jimmy_K jimm...@gmx.at

 Am 16.05.2012 15:46, schrieb Martin Koppenhoefer:
  Am 16. Mai 2012 08:50 schrieb Michael Kugelmann michaelk_...@gmx.de:
  http://wiki.openstreetmap.org/wiki/DE:Stairs_modelling (ist sogar auf
 der
  steps-Seite verkinkt)
  Boh! Man erlaube mir einen offenen Kommentar dazu: das ist m.E.
 s
  kompliziert, dass ein normaler Mapper so etwas nie freiwillig
 verwenden
  wird:
 
  das ist der 3D-Teil. Eine Treppe in OSM einzutragen ist überhaupt
  nicht kompliziert:
 
  1. Man erstellt eine Relation, mit den tags type=area, highway=steps,
  und idealerweise noch step_count (Anzahl der Steigungen)
 
  2. Man zeichnet die 1. Trittstufe (den vorderen, vertikalen Teil der
  untersten Stufe, also wo es zum ersten Mal nach oben geht) als way und
  fügt sie in die Relation ein, als Rolle gibt man lower an.
 
  3. Man zeichnet die letzte Trittstufe (den vorderen, vertikalen Teil
  der obersten Stufe) als way und fügt sie mit der Rolle upper in die
  Relation ein.
 
  Fertig.
 
  Optional kann man noch die seitlichen Grenzen zeichnen und mit der
  Rolle lateral einfügen, braucht man aber nur in Ausnahmefällen, wenn
  das keine geraden Linien sind.
 
  Worauf man achten sollte ist, dass die untere Linie (lower) und die
  obere Linie (upper) der Einfachkeit halber aus der selben Anzahl nodes
  bestehen sollten.
 
  Wenn die Treppe Podeste hat (also es zwischendrin mal eben wird für
  ein paar Meter), dann zerlegt man sie einfach in mehrere Teile. Ob man
  dazu besser verschiedene Relationen anlegt, oder das in einer machen
  kann, können wir ja mal diskutieren.
 
  Wenn ich oben schrieb Trittstufe dann meinte das eigentlich die
  vorderste Kante des Auftritts (manche Treppen haben ja auch
  Unterschneidungen).
 
  Gruß Martin
 
  ___
  Talk-de mailing list
  Talk-de@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-de
 

 Ist somit im prinzipiellen Aufbau das selbe wie der Link (nur mit
 Relationen aufgebaut).
 Fehlt es in deiner Auflistung, oder gibt es keinen klassischen Way mit
 highway=steps? Ich könnte mir vorstellen, dass dies noch viele Router
 aus dem Konzept bringt.

 LG Jimmy

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

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Rainer Knaepper]

Am 15.05.2012 12:36, schrieb Martin Koppenhoefer:

Am 15. Mai 2012 12:31 schrieb Michael Kugelmannmichaelk_...@gmx.de:

es gibt dort sehr breite Treppen auf der Fläche. Diese sind geschätzt bis zu
100m lang.
Wie tagge ich diese? Ich bin eigentlich kein Freund von Flächenmalerei,
aber in dem Fall frage ich mich, ob ich eine Fläche malen soll und diese
mittels area = yes und highway = steps kennzeichnen soll (entsprechend
den highway = pedestrian).



damit wäre die Treppe unterspezifiziert, weil nicht klar ist, in
welche Richtung die Treppe geht. Es gibt bereits Vorschläge im Wiki,
wie man das mappen könnte, z.B. relation type=area (proposed) und in
OSM-4D auf einer Unterseite.

step_count wäre auch nicht falsch m.E.
Um das Routing problemlos zu ermöglichen ggf. zusätzlich die Lauflinie
(die geht normalerweise durch die Mitte der Stufen) als gerichteten
Vektor einzeichnen.


Nuja, wo ist hier der Laufweg?

http://wiki.openstreetmap.org/wiki/File:Langtreppe_DSC01808_osm.jpg

Es ist reiner Zufall, daß da auch gerade ein Rollifahrer im 
Bild war -  für die ist sowas eher eine langgestreckte 
Barriere, kein Weg.


--

Rainer


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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Martin Koppenhoefer]

Am 16. Mai 2012 19:33 schrieb Volker Schmidt vosc...@gmail.com:
 Mein Standard_Kommentar: don't overdo it.

 Wir wollen eine Landkarte machen, OSM ist kein CAD-Ersatz.

stimmt zwar, aber große Freitreppen sind schon auch in Stadtplänen
Standard, vor allem in den Maßstäben, die wir in OSM haben. Einzelne
Treppen mit Breiten nebeneinander finde ich Murks, das ist Tagging für
die Renderer, und passt nur dann, wenn man seine Treppen wie Mapnik
einstellt ;-) Da hat man dann viele kleine Treppen in der db wo es
eigentlich eine große ist.


 Das muss einfacher gehn, oder es wird im Zweifelsfall von nur wenigen
 Experten benutzt.


wie gesagt, es ist extrem einfach. 2 ways, also die obere und untere
Kante der Treppe, beides in eine Relation packen, 2 tags dazu, fertig.
Mit dem parallele Ways tool kann man das in 20 Sekunden erstellen,
gerade ausprobiert ;-)

Gruß Martin

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Martin Koppenhoefer]

Am 16. Mai 2012 21:14 schrieb Rainer Knaepper sm...@gmx.de:
 Nuja, wo ist hier der Laufweg?

 http://wiki.openstreetmap.org/wiki/File:Langtreppe_DSC01808_osm.jpg

 Es ist reiner Zufall, daß da auch gerade ein Rollifahrer im Bild war -  für
 die ist sowas eher eine langgestreckte Barriere, kein Weg.


Freitreppen auf Plätzen haben natürlich dasselbe Problem wie die
Plätze selbst auch: sie sind nicht geeignet für Routing im
Kantenmodell.

Gruß Martin

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Tobias Knerr]

Am 16.05.2012 16:59, schrieb Martin Koppenhoefer:
 die Fläche ergibt sich aus der Relation (obere und untere Kante werden
 vorgegeben und bei Bedarf auch die Seiten). Die Stufen sind mit
 gleichbleibendem Auftritt (Länge in Gehrichtung einer Stufe)
 gedacht, d.h. es sind Parallelen (es werden in der Auswertung einfach
 die einzelnen Punkte des oberen und unteren ways jeweils der Reihe
 nach verbunden und zu Interpolation der Zwischenwerte durch ein
 (step_count -1) Teile geteilt.

In den Fällen, wo das so funktioniert, stimme ich dir völlig zu. Das
setzt aber voraus, dass der obere und untere Way gleich viele Nodes
haben. Davon kann man im Allgemeinen nicht ausgehen.

Diese Diskussion gab es in ähnlicher Form auch hier schon:
http://forum.openstreetmap.org/viewtopic.php?id=13904

Im Grunde sind die einzigen Ideen bisher, gleiche Nodezahlen
vorzuschreiben (m.E. keine gute Lösung), oder aber die Paare manuell
zuzuordnen - letzteres entweder per Tags (m.E. auch keine gute Lösung)
oder weiterer verbindender Ways analog zur Lauflinie (denkbar).

 übrigens: man wird sowieso kaum die echten Stufenbreiten so rendern
 können, dass man alle Stufen einzeln sieht (je nach Zoomstufe
 natürlich)

Ich mache 3D-Rendering. Bei mir sieht man alles. ;)

Das Problem der Linienführung für die Stufen hätte man aber auch im
2D-Rendering.

 Für den _sehr_ seltenen Fall von Stufen unterschiedlicher Breite (ist
 im Prinzip ein Planungsfehler) müsste man halt notfalls jede Stufe
 einzeln mappen.

Den Fall würde ich auch außen vor lassen.

 durch gebogene Stufen (welche mit gekurvter Aufsichtslinie?) ändert
 sich nichts. Die werden wie immer in OSM durch Polygonzüge soweit
 angenähert, dass sie halbwegs rund erscheinen. Die sind normalerweise
 auch gleich breit, oder hast Du ein Gegenbeispiel?

Mir geht es eher darum, dass in solchen Fällen das Problem mit den nicht
gleich detaillierten oberen und unteren Ways auftritt (s.o.). Ohne
Krümmung ist es egal, wie man obere und untere Knoten zuordnet, das
Ergebnis ist dasselbe.

Gruß,
Tobias

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[fly]

On 16/05/12 21:14, Rainer Knaepper wrote:
 Am 15.05.2012 12:36, schrieb Martin Koppenhoefer:
 Am 15. Mai 2012 12:31 schrieb Michael Kugelmannmichaelk_...@gmx.de:
 es gibt dort sehr breite Treppen auf der Fläche. Diese sind geschätzt bis zu
 100m lang.
 Wie tagge ich diese? Ich bin eigentlich kein Freund von Flächenmalerei,
 aber in dem Fall frage ich mich, ob ich eine Fläche malen soll und diese
 mittels area = yes und highway = steps kennzeichnen soll (entsprechend
 den highway = pedestrian).


 damit wäre die Treppe unterspezifiziert, weil nicht klar ist, in
 welche Richtung die Treppe geht. Es gibt bereits Vorschläge im Wiki,
 wie man das mappen könnte, z.B. relation type=area (proposed) und in
 OSM-4D auf einer Unterseite.

 step_count wäre auch nicht falsch m.E.
 Um das Routing problemlos zu ermöglichen ggf. zusätzlich die Lauflinie
 (die geht normalerweise durch die Mitte der Stufen) als gerichteten
 Vektor einzeichnen.
 
 Nuja, wo ist hier der Laufweg?
 
 http://wiki.openstreetmap.org/wiki/File:Langtreppe_DSC01808_osm.jpg
 
 Es ist reiner Zufall, daß da auch gerade ein Rollifahrer im Bild war -  für 
 die
 ist sowas eher eine langgestreckte Barriere, kein Weg.
 

Schönes Bild !

Der Rolli und die nicht abgesenkten Bordsteine am Zebrastreifen.


Im Ernst, hier sind die Grenzen des Proposals und es muß be jeder Änderung der
Stufenanzahl eine neue Fläche gebildet werden. Die mir in meiner Gegend
bekannten interessanten Treppen sind leider auch alle in ihrer Form sehr 
spezifisch.

Beispiel:
http://www.badische-seiten.de/bild/freiburg/augustinerplatz.php
http://www.freiburg-geniessen.de/de/freiburg/clips/augustinerplatz.jpg
http://fudder.de/artikel/2009/06/17/augustinerplatz-die-saeule-der-tristesse/

mal aus drei Perspektiven. Man achtet auch auf die obersten beiden Stufen im
mittleren Bild.

Gruß
fly

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Jimmy_K]

Am 16.05.2012 21:36, schrieb fly:
 On 16/05/12 21:14, Rainer Knaepper wrote:
 Am 15.05.2012 12:36, schrieb Martin Koppenhoefer:

 Nuja, wo ist hier der Laufweg?

 http://wiki.openstreetmap.org/wiki/File:Langtreppe_DSC01808_osm.jpg

 Es ist reiner Zufall, daß da auch gerade ein Rollifahrer im Bild war -  für 
 die
 ist sowas eher eine langgestreckte Barriere, kein Weg.

 Schönes Bild !

 Der Rolli und die nicht abgesenkten Bordsteine am Zebrastreifen.


 Im Ernst, hier sind die Grenzen des Proposals und es muß be jeder Änderung der
 Stufenanzahl eine neue Fläche gebildet werden. Die mir in meiner Gegend
 bekannten interessanten Treppen sind leider auch alle in ihrer Form sehr 
 spezifisch.

 ...
 Gruß
 fly

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


Es ist nicht für jede Stiege eine neue Fläche erforderlich:
lower: geht entlang der untersten Stiege solange sie annähernd die volle
Höhe hat
upper: geht über die volle Länge
Man müsste für diesen Fall nur die Seiten taggen, was aber in dem
einen Vorschlag vorkommt.

LG Jimmy

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

[Talk-de] highway = steps auch für eine Fläche?

[Michael Kugelmann]

Hallo,

nachdem ich große Lücken auf dem Olympiagelände in Barcelona gab, habe 
ich am Wochenende mal mithilfe der Bing-Luftbilder etwas 
gemappt/überarbeitet/ergänzt: 
http://www.openstreetmap.org/?lat=41.36477lon=2.151114zoom=18layers=M
Zum Glück hatte ich von meinem Besuch nach der SOTM 2010 noch relativ 
gute Erinnerungen (bzw. auch Fotos/Tracks).


Was aber noch offen ist:
es gibt dort sehr breite Treppen auf der Fläche. Diese sind geschätzt 
bis zu 100m lang.
Wie tagge ich diese? Ich bin eigentlich kein Freund von 
Flächenmalerei, aber in dem Fall frage ich mich, ob ich eine Fläche 
malen soll und diese mittels area = yes und highway = steps 
kennzeichnen soll (entsprechend den highway = pedestrian).


Kommentare erbeten.


Grüße,
Michael.

PS: das it ein touristisch sehr gut besuchter Ort wo es gute Luftbilder 
gibt und wo noch jede Menge Details gemappt werden können (viel Fußwege 
fehlen noch) = wenn es also jemand langweilig ist und er nicht weiss wo 
er etwas machen soll, dort ist ein (m.E.) dankbarer Ort...



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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Martin Koppenhoefer]

Am 15. Mai 2012 12:31 schrieb Michael Kugelmann michaelk_...@gmx.de:
 es gibt dort sehr breite Treppen auf der Fläche. Diese sind geschätzt bis zu
 100m lang.
 Wie tagge ich diese? Ich bin eigentlich kein Freund von Flächenmalerei,
 aber in dem Fall frage ich mich, ob ich eine Fläche malen soll und diese
 mittels area = yes und highway = steps kennzeichnen soll (entsprechend
 den highway = pedestrian).


damit wäre die Treppe unterspezifiziert, weil nicht klar ist, in
welche Richtung die Treppe geht. Es gibt bereits Vorschläge im Wiki,
wie man das mappen könnte, z.B. relation type=area (proposed) und in
OSM-4D auf einer Unterseite.

step_count wäre auch nicht falsch m.E.
Um das Routing problemlos zu ermöglichen ggf. zusätzlich die Lauflinie
(die geht normalerweise durch die Mitte der Stufen) als gerichteten
Vektor einzeichnen.

Gruß Martin

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

Re: [Talk-de] highway = steps auch für eine Fläche?

[Masi Master]

Hi,
schau mal hier:
http://wiki.openstreetmap.org/wiki/DE:Stairs_modelling (ist sogar auf der  
steps-Seite verkinkt)
Es ist zwar noch nichts konkretes, aber es lohnt sich bestimmt es zu  
taggen, auch wenn es (noch) nicht gerendert wird.


Am 15.05.2012, 12:31 Uhr, schrieb Michael Kugelmann michaelk_...@gmx.de:


Hallo,

nachdem ich große Lücken auf dem Olympiagelände in Barcelona gab, habe  
ich am Wochenende mal mithilfe der Bing-Luftbilder etwas  
gemappt/überarbeitet/ergänzt:  
http://www.openstreetmap.org/?lat=41.36477lon=2.151114zoom=18layers=M
Zum Glück hatte ich von meinem Besuch nach der SOTM 2010 noch relativ  
gute Erinnerungen (bzw. auch Fotos/Tracks).


Was aber noch offen ist:
es gibt dort sehr breite Treppen auf der Fläche. Diese sind geschätzt  
bis zu 100m lang.
Wie tagge ich diese? Ich bin eigentlich kein Freund von  
Flächenmalerei, aber in dem Fall frage ich mich, ob ich eine Fläche  
malen soll und diese mittels area = yes und highway = steps  
kennzeichnen soll (entsprechend den highway = pedestrian).


Kommentare erbeten.


Grüße,
Michael.

PS: das it ein touristisch sehr gut besuchter Ort wo es gute Luftbilder  
gibt und wo noch jede Menge Details gemappt werden können (viel Fußwege  
fehlen noch) = wenn es also jemand langweilig ist und er nicht weiss wo  
er etwas machen soll, dort ist ein (m.E.) dankbarer Ort...



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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Chris66]

Am 26.11.2011 10:50, schrieb Chris66:

 Bugreport an ORS und Cloudmade unterwegs.

Beide haben sich gemeldet mit der Ankündigung eine Lösung zu
entwickeln.

Im Prinzip ist die Lösung trivial:
if relation=multipolygon und highway-Tag is
set then vererbe das highway-Tag (und access-Tags) zu den
outer-members.

Chris


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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Stephan Wolff]

Moin!

Am 24.11.2011 17:46, schrieb Chris66:

Am 24.11.2011 17:24, schrieb Martin Koppenhoefer:


weshalb ich immer predige über so toll
gemappte Plätze bitte die Laufwege reinzumalen...


Es gibt aber keine Laufwege, man kann kreuz und quer
über den Platz laufen.


Trotzdem könnte man natürlich virtuelle Wege über den Platz in der 
Datenbank ablegen, um dem Router eine Wegberechnung zu ermöglichen oder 
zumindest deutlich zu erleichtern. Virtuelle Wege ließen sich leicht 
durch ein Zusatztag von realen Wegen unterscheiden.


Ähnliches verfahren wir in OSM an anderer Stelle:
- Fährverbindungen werden als Linie erfasst, obwohl es keine Wege auf 
der Wasserfläche gibt und die tatsächliche Fahrstrecke variiert.
- Kreuzungen von Straßen mit getrennten Fahrbahnen werden meist als zwei 
Doppellinien mit vier Kreuzungspunkten eingetragen, obwohl die gesamte 
Kreuzungsfläche befahren wird.


Viele Grüße
Stephan


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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Jo]

Hier habe ich auch was ähnliches gemacht:

http://www.openstreetmap.org/?lat=50.882087lon=4.714648zoom=18layers=M

Die Büsse fahren über ein ganz grosse betonierte Flache. Um ihre Routes
aber schön dar zu stellen un kontinu zu machen, habe ich auch service ways
benötigt. Keine Ahnung ob das auch als mappen für den Renderieres bestimmt
würde.

Jo

2011/11/27 Stephan Wolff s.wo...@web.de

 Moin!

 Am 24.11.2011 17:46, schrieb Chris66:

 Am 24.11.2011 17:24, schrieb Martin Koppenhoefer:

  weshalb ich immer predige über so toll
 gemappte Plätze bitte die Laufwege reinzumalen...


 Es gibt aber keine Laufwege, man kann kreuz und quer
 über den Platz laufen.


 Trotzdem könnte man natürlich virtuelle Wege über den Platz in der
 Datenbank ablegen, um dem Router eine Wegberechnung zu ermöglichen oder
 zumindest deutlich zu erleichtern. Virtuelle Wege ließen sich leicht durch
 ein Zusatztag von realen Wegen unterscheiden.

 Ähnliches verfahren wir in OSM an anderer Stelle:
 - Fährverbindungen werden als Linie erfasst, obwohl es keine Wege auf der
 Wasserfläche gibt und die tatsächliche Fahrstrecke variiert.
 - Kreuzungen von Straßen mit getrennten Fahrbahnen werden meist als zwei
 Doppellinien mit vier Kreuzungspunkten eingetragen, obwohl die gesamte
 Kreuzungsfläche befahren wird.

 Viele Grüße
 Stephan



 __**_
 Talk-de mailing list
 Talk-de@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/talk-dehttp://lists.openstreetmap.org/listinfo/talk-de

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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Chris66]

Am 25.11.2011 18:05, schrieb Martin Koppenhoefer:

 Oder sollten die Router das fixen und wir schreiben ein bug-ticket?

Natürlich ist es Aufgabe der Router auch MPs zu berücksichtigen.

Bugreport an ORS und Cloudmade unterwegs.

Chris


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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Chris66]

 Zumindest ORS bestätigt schonmal meine Vermutung:
 
 http://129.206.229.146/openrouteservice/index.php?start=6.896588,52.22121end=6.895124,52.22036pref=Pedestrianlang=de
 
 Kurzer Blick auf die kommerzielle Konkurrenz:
 
 Bei google sind Fläche und Wege separat eingezeichnet, somit Routing
 problemlos.

Cloudmade (Data for routing is for 15-th of September):

http://maps.cloudmade.com/?lat=52.219788lng=6.894479zoom=17directions=52.22035,6.89515,52.22043,6.89618travel=footstyleId=1opened_tab=1

 Weiss jemand, ob aktuelle Router damit klarkommen (wenn die Tags nur 
in der Relation sind)?

ich denke damit ist die Frage beantwortet. ;-)

Christian


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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Martin Koppenhoefer]

Am 25. November 2011 15:08 schrieb Chris66 chris66...@gmx.de:
 http://maps.cloudmade.com/?lat=52.219788lng=6.894479zoom=17directions=52.22035,6.89515,52.22043,6.89618travel=footstyleId=1opened_tab=1

 Weiss jemand, ob aktuelle Router damit klarkommen (wenn die Tags nur 
 in der Relation sind)?

 ich denke damit ist die Frage beantwortet. ;-)


Ja, sieht so aus, danke für die Recherche, Chris. Zum Glück haben wir
Mischmasch-Multipolygone, wir sollten (?) also für highway-areas die
highway und area-tags am outer lassen. (Btw.: in dem Beispiel ist das
Mapping allerdings irgendwie Murks, die Häuser sollten einen
gemeinsamen/überlagerten way mit der highway-area haben, da diese bis
an die Häuser rangeht (Topologie)).

Gruß Martin

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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Martin Koppenhoefer]

Am 25. November 2011 18:03 schrieb Martin Koppenhoefer dieterdre...@gmail.com:
 wir sollten (?) also für highway-areas die
 highway und area-tags am outer lassen.


Oder sollten die Router das fixen und wir schreiben ein bug-ticket?
(Leider kann ich es nicht selber fixen, allzu schwer stelle ich mir
das allerdings nicht vor, da es schon einigen Code für Multipolygone
zu geben scheint, ist glaube ich mehr eine Frage, ob man dran denkt).

Gruß Martin

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

[Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Martin Koppenhoefer]

Ein Punkt, der mich gelegentlich ohne Ergebnis zum Nachdenken bringt
sind Multipolygone, die Highway-areas darstellen. Weiss jemand, ob
aktuelle Router damit klarkommen (wenn die Tags nur in der Relation
sind)?

Gruß Martin

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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Chris66]

Am 24.11.2011 16:39, schrieb Martin Koppenhoefer:

 Ein Punkt, der mich gelegentlich ohne Ergebnis zum Nachdenken bringt
 sind Multipolygone, die Highway-areas darstellen. Weiss jemand, ob
 aktuelle Router damit klarkommen (wenn die Tags nur in der Relation
 sind)?

Vermutlich nicht.
Leider sind die Online Router Monate im Datenrückstand so dass ich's
grad nicht testen kann.

ORS:   18-10-2011
YOURS: 28-06-2011
Cloudmade: ???

Chris


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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Chris66]

Am 24.11.2011 16:51, schrieb Chris66:
 Vermutlich nicht.

mal ebend Garmin-Karten via BaseCamp getestet:
Sowohl Karten die mit den Default-mkgmap-Rules erstellt wurden als
auch mein derzeitiger Favorit, die Freizeitkarte Deutschland
schaffen es noch nicht mal über normale (area=yes, kein MP)
Pedestrian-Areas zu routen.

Chris


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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Andreas Neumann]

On 11/24/2011 05:06 PM, Chris66 wrote:
 Am 24.11.2011 16:51, schrieb Chris66:
 Vermutlich nicht.
 mal ebend Garmin-Karten via BaseCamp getestet:
 Sowohl Karten die mit den Default-mkgmap-Rules erstellt wurden als
 auch mein derzeitiger Favorit, die Freizeitkarte Deutschland
 schaffen es noch nicht mal über normale (area=yes, kein MP)
 Pedestrian-Areas zu routen.

 Chris
Das Problem besteht schon lange, weshalb ich immer predige über so toll
gemappte Plätze bitte die Laufwege reinzumalen...

MfG Andreas



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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Martin Koppenhoefer]

Am 24. November 2011 17:06 schrieb Chris66 chris66...@gmx.de:
 Am 24.11.2011 16:51, schrieb Chris66:
 Vermutlich nicht.

 mal ebend Garmin-Karten via BaseCamp getestet:
 Sowohl Karten die mit den Default-mkgmap-Rules erstellt wurden als
 auch mein derzeitiger Favorit, die Freizeitkarte Deutschland
 schaffen es noch nicht mal über normale (area=yes, kein MP)
 Pedestrian-Areas zu routen.


klar, _über_ die areas geht natürlich nicht, aber am Rand entlang?
D.h. die area wie einen geschlossenen Linienzug um den Platz rum
interpretiert, das sollte normalerweise der Fall sein.

Gruß Martin

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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Chris66]

Am 24.11.2011 17:24, schrieb Martin Koppenhoefer:

 klar, _über_ die areas geht natürlich nicht, aber am Rand entlang?
 D.h. die area wie einen geschlossenen Linienzug um den Platz rum
 interpretiert, das sollte normalerweise der Fall sein.

Nein, auch nicht am Rand entlang:
http://up.picr.de/8840518htn.png

 weshalb ich immer predige über so toll
 gemappte Plätze bitte die Laufwege reinzumalen...

Es gibt aber keine Laufwege, man kann kreuz und quer
über den Platz laufen.

Chris


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

Re: [Talk-de] highway=pedestrian und area=yes im Multipolygon und Routing

[Chris66]

 Ein Punkt, der mich gelegentlich ohne Ergebnis zum Nachdenken bringt
 sind Multipolygone, die Highway-areas darstellen. Weiss jemand, ob
 aktuelle Router damit klarkommen (wenn die Tags nur in der Relation
 sind)?

 Vermutlich nicht.
 Leider sind die Online Router Monate im Datenrückstand so dass ich's
 grad nicht testen kann.
 
 ORS:   18-10-2011
 YOURS: 28-06-2011
 Cloudmade: ???

Ok, hab ein schönes Beispiel gefunden (Oude Markt Enschede):

http://www.openstreetmap.org/browse/relation/1669112

Zumindest ORS bestätigt schonmal meine Vermutung:

http://129.206.229.146/openrouteservice/index.php?start=6.896588,52.22121end=6.895124,52.22036pref=Pedestrianlang=de

Kurzer Blick auf die kommerzielle Konkurrenz:

Bei google sind Fläche und Wege separat eingezeichnet, somit Routing
problemlos.

Christian


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

Re: [Talk-de] highway=axis

[Kay Drangmeister]

Am 01.07.2011 00:44, schrieb Frederik Ramm:

PS: Gibt es das eigentlich ueberhaupt, dass Strassen und Schienen
ueber die gleiche Bruecke fuehren?


http://maps.google.de/maps?q=w%C3%BCrzburghl=deie=UTF8ll=49.798952,9.923677spn=0.001314,0.002411sll=51.151786,10.415039sspn=21.675837,39.506836t=hz=19

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

Re: [Talk-de] highway=axis

[Heiko Jacobs]

Am 01.07.2011 00:44, schrieb Frederik Ramm:

PS: Gibt es das eigentlich ueberhaupt, dass Strassen und Schienen ueber
die gleiche Bruecke fuehren? Ich kenne, zumindest in Deutschland,
glaub ich nur separate Bruecken, selbst
wenn beides direkt benachbart ist.


Ein besonders schönes Drehbrücken-Exemplar mit Gleisen nicht in der
Fahrbahn (wie bei der Wintersdorfer Brücke bspw.):
http://www.brueckenweb.de/2content/datenbank/bruecken/2brueckenblatt.php?bas=4861


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

Re: [Talk-de] highway=axis

[Garry]

Am 01.07.2011 00:44, schrieb Frederik Ramm:



PS: Gibt es das eigentlich ueberhaupt, dass Strassen und Schienen 
ueber die gleiche Bruecke fuehren? Ich kenne, zumindest in 
Deutschland, glaub ich nur separate Bruecken, selbst wenn beides 
direkt benachbart ist.



Die hier auch falls die noch nicht dabei war:
http://www.brueckenweb.de/2content/datenbank/bruecken/2brueckenblatt.php?bas=2682
bzw.
http://www.openstreetmap.org/?lat=54.054882lon=13.786542zoom=18layers=M
OSM-gerecht.

Garry

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

Re: [Talk-de] highway=axis

[Wolfgang]

Hallo,
Am Mittwoch, 6. Juli 2011 00:50:43 schrieb M∡rtin Koppenhoefer:

 
 einerseits sehe ich es gerade bei Autobahnen schwierig an, dort vor
 Ort genaue Maße zu erheben,

damit hast du recht, die wenigsten Mapper werden die Gelegenheit eines Staus 
nutzen und schnell die Mittelstreifenbreite mit dem Zollstock mappen
;-)

 und andererseits hast Du diese Breite
 automatisch, indem Du dem Abstand der highway-ways jeweils die halbe
 Breite abziehst. 

Im Prinzip ja, aber bedingt durch die praktische Mapping-Genauigkeit schwankt 
dieser Wert zu stark.

 Der Sinn könnte darin bestehen, über einen weiteren
 Wert die Plausibilität der Straßen-tags und -lage zu schätzen, aber da
 kommt wieder Punkt 1 ins Spiel: die Mittelstreifenbreite kannst Du
 schwer messen.

+1. Vorausgesetzt man bekommt, auf welchem Weg auch immer, hier genauere 
Daten, könnte man durch eine Abstandsberechnung der 3 Ways die Plausibilität 
der Ways zueinander prüfen und so zumindest einen Teil der Fehler mit einem 
Tool markieren.

 die Luftbilder die wir haben, werden ziemlich sicher auch in
 Deutschland irgendwann besser werden, wenn die Ämter das irgendwann
 mal rausgeben. 2-3 Meter sind m.E. im Autobahnbereich schon sehr gut,
 wenn wir das überall hinbekämen wäre ich ziemlich zufrieden.

Es wäre auch denkbar, dass man sich mal entschließt, die Koordinaten 
rauszugeben, wenn man irgendwann in den Amtsstuben schnallt, dass die 
Geheimhaltung eigenlich nur die Ämter selbst schädigt.

 
  zudem soll hier eine imaginäre Mittellinie gezeichnet
  werden, die es in der Realität gar nicht gibt.
 
 damit meinst Du den highway-way. Davon werden wir uns so schnell
 sicher nicht verabschieden, d.h. den braucht man auf jeden Fall. Das
 ist die Fahrbahnmitte, die ist zwar nicht markiert, aber geben tut
 es die natürlich auch in der Realität.

Ich habe nicht vor, das Mappen der Einzelfahrbahnen abzuschaffen. In den 
größeren Maßstabsstufen und für die Router hat das ganz klare praktische 
Vorteile.

 Die Fahrbahnmitte sehe ich bei 2 und 4 Spuren auf der gestrichelten
 Linie, bei 3 Spuren in der Mitte der mittleren Spur. Finde ich
 problemlos umzusetzen, während die Achse meistens schlechter zu
 erkennen ist, sowas hier ist natürlich nochmal ein Sonderfall:
 http://maps.google.com/maps?hl=dell=42.277158,14.018211spn=0.001046,0.002
 642t=kz=19
 http://maps.google.com/maps?ll=42.011694,13.807771spn=0.002101,0.005284t
 =kz=18
 
 die Spuren behalten normalerweise ihre Breite, die Mittelachse ändert
 Ihre Breite öfters mal, sieh mal was hier z.B. los ist (in der Gegend
 gibts noch mehr krasse Stellen):
 http://maps.google.com/maps?hl=dell=40.685438,14.761569spn=0.004288,0.010
 568t=kz=17
 

Im Bereich von Fahrbahntrennungen hast du damit durchaus recht. Hier macht es 
u.U. auch Sinn, auf eine Mittelachse zu verzichten und den einzelnen Ways zu 
folgen.

 PS: Meiner Meinung nach kann man mit der Relation mehr aussagen,
 besser rendern und routen und hat weniger Arbeit, aber mir ist es im
 Prinzip egal wenn Du gerne die Trennflächen als Linien erfassen
 willst, und man die Tags halbwegs verstehen kann, auch ohne Übersetzen
 ins Deutsche, dann kann und will ich Dich nicht davon abhalten.

+1, ich hatte nicht vor, etwas gegen deine Nutzung von Relationen zu sagen.

Über die Tags werde ich mal nachdenken, der Begriff centreline z.B. scheint 
doch günstiger zu sein.

Gruß, Wolfgang

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

Re: [Talk-de] highway=axis

[T. Clormann]

Hallo,
Am Freitag 01 Juli 2011 00:44:23 schrieb Frederik Ramm:

 PS: Gibt es das eigentlich ueberhaupt, dass Strassen und Schienen ueber
 die gleiche Bruecke fuehren? Ich kenne, zumindest in Deutschland, glaub
 ich nur separate Bruecken, selbst wenn beides direkt benachbart ist.

und noch ein Beispiel dazu:

zwischen Dänemark und Schweden führen Autobahn und Eisenbahn übereinander
über dieselbe Brücke:

http://tools.geofabrik.de/map/?type=Geofabriklon=12.83855lat=55.57586zoom=13

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

Re: [Talk-de] highway=axis

[Wolfgang]

Hallo,
Am Montag, 4. Juli 2011 02:35:53 schrieb M∡rtin Koppenhoefer:
 Am 1. Juli 2011 06:26 schrieb Wolfgang wolfg...@ivkasogis.de:
  Hallo,
  
  Am Freitag 01 Juli 2011 01:27:44 schrieb M∡rtin Koppenhoefer:
  vermutlich hast Du Dir die relation area nicht angesehen, 
  
  Das ist eine Möglichkeit, die ich aber aus Gründen der Zweckmäßigkeit für
  ungünstig halte. Bei unserer Erfassungsqualität schwankt diese Area
  gewaltig in der Breite, während in der Realität der Mittelstreifen über
  (mindestens) viele Kilometer die gleiche Breite hat., was durch das
  width-Tag wesentlich besser erfasst wird.
 
 das width-tag willst Du wo genau anbringen?

damit ließe sich die Breite des Bereiches zwischen den Fahrbahnen kennzeichnen 
(Mittelstreifen). Der Wert wird durch das Regelprofil festgelegt und ist auf 
langen Strecken einheitlich.
 
  Lineare Bauwerke wie Straßen oder Mittelsteifen lassen sich durch die
  real als Mittelleitplanke vorhandene Achse besser abbilden als durch
  eine Fläche.
 
 bei meinem Modell werden sie weder als Linie noch als Fläche
 gezeichnet, sondern über tags sowie die Lage zwischen 2 ways indirekt
 beschrieben.

Das Problem dabei ist, dass hier ein relativ kurzes Maß über 2 relativ ungenau 
bestimmte Werte festgelegt werden soll, und das geht in der Regel schief. 
Unsere Lage der Fahrbahnen der Autobahnen schwankt gegenüber den Luftbildern 
ständig hin und her, abgesehen von der ungenauen Lage der Luftbilder selbst, 
die aus GPS-tracks abgeleitet wird, die selbst wiederum eine Unsicherheit von 
2-3m im Mittel haben, zudem soll hier eine imaginäre Mittellinie gezeichnet 
werden, die es in der Realität gar nicht gibt. Meistens läuft die Linie auf 
dem Trennungsstreifen zwischen Haupt- und Überholfahrstreifen. Das ist aber 
weder bei 2 noch bei 3 Spuren die geometrische Mitte, vorausgesetzt, dass die 
Autobahn eine Standspur hat, die meines Wissens noch gar nicht getaggt wird. 
Hinzu kommt, dass OSM mit ausschließlich geraden Verbindungslinien arbeitet, 
die in den real gemappten Kurven der Praxis um bis zu 5m um die Mitte 
schwanken.

Du willst also einen Wert, der zwischen 1 und 3 Meter beträgt, aus 2 Messungen 
ableiten, die im Einzelwert eine Unsicherheit von 3-5m haben, und das Ganze 
über eine Strecke von mehreren 100km. Mit einer so ermittelten Fläche liegst 
du um Lichtjahre schlechter als ein über den Daumen gepeiltes Ergbnis, alles 
andere wäre reines Glück.

Deine Methode könnte funktionieren, wenn wir die Achsdaten (Kurvenbänder) der 
Autobahn hätten. Aber selbst dann wäre es durch die Brust ins Auge, denn der 
eigentliche geometrische Ort der Autobahn ist der Achspunkt. Alle anderen 
Werte werden davon abgeleitet. Nicht nur zur Bauzeit, sondern immer. Jede 
Kilometrierung bezieht sich auf die Autobahnachse. Und dieser Punkt befindet 
sich in der Regel unter der Leitplanke oder wenige cm daneben und ist damit 
relativ einfach und sicher zu mappen.

Wie wolltest du denn beispielsweise Kilometertafeln an der Autobahn 
aufstellen, wenn jede Fahrspur für sich berechnet würde? Die Länge der 
Fahrbahnen ist je nach Kurvenanzahl und -Radius zwangsläufig nicht gleich. Die 
Autobahnachse ist kein theoretischer Wert und nicht nur zur Bauzeit, sondern 
ständig vorhanden und gültig. Alle Maßnahmen, die eine Autbahn betreffen, 
stützen sich immer und zu jeder Zeit auf diese Ache, von der Unfallmeldung 
über Hindernisbeseitigung und Pflege bis zur (Aus-) Bauausschreibung. Außerdem 
ist die Achse in der Realität besser zu erkennen als z.B. jede Gemeindegrenze, 
ganz zu schweigen von der Fahrbahnmitte.

Gruß, Wolfgang

ps.: Das mit der Brückenrelation habe ich mir noch einmal durchgesehen. Man 
könnte da einiges draus machen, auch wenn noch nicht alles zu Ende gedacht 
ist. Ich komme da wahrscheinlich demnächst mal mit einem Vorschlag. Den werde 
ich dann aber testweise sofort umsetzen, denn ich halte nicht so viel davon, 
Vorschläge für 3 Jahre im Wiki schlummern zu lassen. Lieber machen und in der 
Praxis verbessern, als theoretisch totdiskutieren. Kompatibel muss es natülich 
sein.

d.o.

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

Re: [Talk-de] highway=axis

[M∡rtin Koppenhoefer]

Am 6. Juli 2011 00:15 schrieb Wolfgang wolfg...@ivkasogis.de:
 das width-tag willst Du wo genau anbringen?

 damit ließe sich die Breite des Bereiches zwischen den Fahrbahnen kennzeichnen
 (Mittelstreifen). Der Wert wird durch das Regelprofil festgelegt und ist auf
 langen Strecken einheitlich.


einerseits sehe ich es gerade bei Autobahnen schwierig an, dort vor
Ort genaue Maße zu erheben, und andererseits hast Du diese Breite
automatisch, indem Du dem Abstand der highway-ways jeweils die halbe
Breite abziehst. Der Sinn könnte darin bestehen, über einen weiteren
Wert die Plausibilität der Straßen-tags und -lage zu schätzen, aber da
kommt wieder Punkt 1 ins Spiel: die Mittelstreifenbreite kannst Du
schwer messen.


 Unsere Lage der Fahrbahnen der Autobahnen schwankt gegenüber den Luftbildern
 ständig hin und her, abgesehen von der ungenauen Lage der Luftbilder selbst,
 die aus GPS-tracks abgeleitet wird, die selbst wiederum eine Unsicherheit von
 2-3m im Mittel haben,


die Luftbilder die wir haben, werden ziemlich sicher auch in
Deutschland irgendwann besser werden, wenn die Ämter das irgendwann
mal rausgeben. 2-3 Meter sind m.E. im Autobahnbereich schon sehr gut,
wenn wir das überall hinbekämen wäre ich ziemlich zufrieden.


 zudem soll hier eine imaginäre Mittellinie gezeichnet
 werden, die es in der Realität gar nicht gibt.


damit meinst Du den highway-way. Davon werden wir uns so schnell
sicher nicht verabschieden, d.h. den braucht man auf jeden Fall. Das
ist die Fahrbahnmitte, die ist zwar nicht markiert, aber geben tut
es die natürlich auch in der Realität.


 Meistens läuft die Linie auf
 dem Trennungsstreifen zwischen Haupt- und Überholfahrstreifen. Das ist aber
 weder bei 2 noch bei 3 Spuren die geometrische Mitte, vorausgesetzt, dass die
 Autobahn eine Standspur hat, die meines Wissens noch gar nicht getaggt wird.


Standspuren und Belag ausserhalb der Fahrbahn sorgen zugegebenermaßen
für gewisse Unschärfen, aber dem wird sich beim Detailierungswunsch
der Mapper sicher auch noch irgendwann jemand annehmen. Ob diese
Straßenlinie jetzt in der Mitte des asphaltierten Bereichs (erkennbar
in Luftbildern) oder in der der Fahrbahn läuft, spielt kaum eine
Rolle, vor allem, solange kein Spurmodell verbreitet ist.


 Hinzu kommt, dass OSM mit ausschließlich geraden Verbindungslinien arbeitet,
 die in den real gemappten Kurven der Praxis um bis zu 5m um die Mitte
 schwanken.


m.E. sollte man Kurven so fein es geht annähern, diese eckigen Kurven
sehen in der Tat schlecht aus und sorgen auch geringfügig für
Lageungenauigkeiten.


 Du willst also einen Wert, der zwischen 1 und 3 Meter beträgt, aus 2 Messungen
 ableiten, die im Einzelwert eine Unsicherheit von 3-5m haben, und das Ganze
 über eine Strecke von mehreren 100km. Mit einer so ermittelten Fläche liegst
 du um Lichtjahre schlechter als ein über den Daumen gepeiltes Ergbnis, alles
 andere wäre reines Glück.


wieso aus 2 Messungen? Jeder Track ist eine Messung, auf Autobahnen
hast Du meistens viele davon.


 Außerdem
 ist die Achse in der Realität besser zu erkennen als z.B. jede Gemeindegrenze,
 ganz zu schweigen von der Fahrbahnmitte.

Die Fahrbahnmitte sehe ich bei 2 und 4 Spuren auf der gestrichelten
Linie, bei 3 Spuren in der Mitte der mittleren Spur. Finde ich
problemlos umzusetzen, während die Achse meistens schlechter zu
erkennen ist, sowas hier ist natürlich nochmal ein Sonderfall:
http://maps.google.com/maps?hl=dell=42.277158,14.018211spn=0.001046,0.002642t=kz=19
http://maps.google.com/maps?ll=42.011694,13.807771spn=0.002101,0.005284t=kz=18

die Spuren behalten normalerweise ihre Breite, die Mittelachse ändert
Ihre Breite öfters mal, sieh mal was hier z.B. los ist (in der Gegend
gibts noch mehr krasse Stellen):
http://maps.google.com/maps?hl=dell=40.685438,14.761569spn=0.004288,0.010568t=kz=17

Gruß Martin

PS: Meiner Meinung nach kann man mit der Relation mehr aussagen,
besser rendern und routen und hat weniger Arbeit, aber mir ist es im
Prinzip egal wenn Du gerne die Trennflächen als Linien erfassen
willst, und man die Tags halbwegs verstehen kann, auch ohne Übersetzen
ins Deutsche, dann kann und will ich Dich nicht davon abhalten.

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

Re: [Talk-de] highway=axis

[M∡rtin Koppenhoefer]

Am 1. Juli 2011 06:26 schrieb Wolfgang wolfg...@ivkasogis.de:
 Hallo,
 Am Freitag 01 Juli 2011 01:27:44 schrieb M∡rtin Koppenhoefer:
 vermutlich hast Du Dir die relation area nicht angesehen, 
 Das ist eine Möglichkeit, die ich aber aus Gründen der Zweckmäßigkeit für
 ungünstig halte. Bei unserer Erfassungsqualität schwankt diese Area gewaltig
 in der Breite, während in der Realität der Mittelstreifen über (mindestens)
 viele Kilometer die gleiche Breite hat., was durch das width-Tag wesentlich
 besser erfasst wird.


das width-tag willst Du wo genau anbringen?


 Lineare Bauwerke wie Straßen oder Mittelsteifen lassen sich durch die real als
 Mittelleitplanke vorhandene Achse besser abbilden als durch eine Fläche.


bei meinem Modell werden sie weder als Linie noch als Fläche
gezeichnet, sondern über tags sowie die Lage zwischen 2 ways indirekt
beschrieben.

Gruß Martin

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

Re: [Talk-de] highway=axis

[Schlauchboot]

Frederik Ramm wrote:
 
 Der Plan ist, dass man langfristig eine Bruecke nicht als Eigenschaft 
 einer Strasse erfasst, wie wir das im Moment tun, sondern als eigenes 
 Bauwerk.
 

Klingt gut. Mir gehen nämlich die selbst bei fehlender baulicher Trennung
zunehmend als separate highways kartierten Radwege eben wegen der
Brückenproblematik langsam auf den Senkel...


--
View this message in context: 
http://gis.638310.n2.nabble.com/highway-axis-tp6532661p6540415.html
Sent from the Germany mailing list archive at Nabble.com.

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

Re: [Talk-de] highway=axis

[Stephan Wolff]

Moin!

Am 01.07.2011 06:03, schrieb Wolfgang:


Brücke am Museumshafen in Lübeck (als einzige richtig dargestellt)
http://www.openstreetmap.org/?lat=53.872488lon=10.682243zoom=18layers=M


Ob die Darstellung richtig oder zumindest besser als andere ist, kann
man diskutieren. Eine Drehbrücke mit zwei getrennten Fahrbahnen und
einem Bahngleis auf der nördlichen Fahrbahn wird als zwei
nebeneinanderliegende Straßenbrücken mit unterschiedlichem Namen und
einer Straßenbahnbrücke auf der Nordfahrbahn gezeichnet. In z=18 bilden
die zwei Fahrbahnen optisch eine Einheit. Würde man z=20 rechnen hätte
man mit den Fußwegen vier getrennte Brücken. Aber eine Interpretation
durch einen Renderer sollte ohnehin nicht entscheidend für die
Datenbankerfassung sein.

Die Nordfahrbahn ist erfasst als
bridge=yes
electrified=no
highway=secondary
layer=1
maxspeed=50
name=Drehbrücke
oneway=yes
railway=tram
source:maxspeed=DE:urban

Dass Bahngleise als railway=rail und nicht als railway=tram bezeichnet 
werden, hatten wir vor wenigen Tagen geklärt.
Für railway und highway würde ich zwei ways über dieselben nodes 
anlegen, damit die tags electrified, maxspeed, oneway richtig 
zugeordnet werden können.
Weder Brücke noch Straße oder Bahn haben den Namen Drehbrücke. Nord- 
und Südhälfte derselben Brücke sollten nicht verschiedene Namen haben.

bridge=swing und description=Drehbrücke wären sinnvoll.

Auch in der Umgebung wird teilweise nur eine Karte gemalt. Nördlich der
Brücke gibt es den Fluss namens Hansahafen der entgegen der Trave
in derselben Wasserfläche fließt.

Viele Grüße
Stephan


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