<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hallo,</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Bei einfachen Stationen finde ich es echt sinnlos, da mehrere Stop areas zu machen, da ich den Sinn der Stop area so verstehe, dass man damit eben verschiedene Haltepunkte, die zur selben Station gehören zusammenfasst. Die Stop area-group macht für mich nur
Sinn, wenn es entweder zwei verschiedene Stationen mit ihren eigenen Stop-areas sind, die sehr nahe zusammen liegen (so könnte man Stationskomplex-Teile mit verschiedenen Namen zusammenfassen), oder, wenn es, wie etwa beim Hauptbahnhof verschiedene Berehe
gibt, zwischen denen ein Umstieg einer Pilgerreise ähnelt (U1-Zug Bhst 3ff / Fernbusse-Straßenbahn...)</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Aber so in Öffitypen aufgesplittet ergibt es für mich in Sachen GeoDB keinen Sinn. Wenn das so in einer Datenbank für etwa ein RBL erfasst wäre, ok, aber nicht in der OSM. Vor allem, was macht der gute User, wenn Bus- und Tram-Station Dekungsgleich sind?</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Man könnte den User der das macht aber auch mal fragen, warum. Und ob er es nicht vielleicht zumindest etwas geographischer angehen könnte.</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Falls es sich dabei um den User Diego Sanguinetti handelt, der scheint für diese MAPS.me subway Gruppe zu mappen. Die haben ja leider auch eine eigene Vorstellung wie die Daten aussehen sollen...</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Mit freundlichen Grüßen</div>
<div style="font-family: Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
RobinD (emergency99)</div>
<div>
<div id="appendonsend"></div>
<div style="font-family:Calibri,Helvetica,sans-serif; font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Von:</b> andreas wecer <andreas.wecer@gmail.com><br>
<b>Gesendet:</b> Samstag, 4. Jänner 2020 08:50<br>
<b>An:</b> OpenStreetMap AT <talk-at@openstreetmap.org><br>
<b>Betreff:</b> Re: [Talk-at] Stop area groups</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div dir="ltr">Ich habe mich auch gerade über die Verschachtelung bei diesem Node hier gewundert:
<div><a href="https://www.openstreetmap.org/node/5959356915">https://www.openstreetmap.org/node/5959356915</a><br>
</div>
<div><br>
</div>
<div>Der bus_stop "Baden Landesklinikum" ist Teil der stop_area Relation "Baden Landesklinikum (bus)", die nur aus diesem Node besteht und wiederum wie die direkt nebenan liegende Relation "Baden Landesklinikum (WLB)" zur stop_area_group "Baden Landesklinikum"
gehört.</div>
<div>Die Suffixe tauchen nur in den stop_area Relationen und nicht in den konkreten Stop-Nodes auf, also ist die Struktur an sich schon nachvollziehbar, aber ohne mich näher mit dem public_transport Thema beschäftigt zu haben, würde ich erwarten, dass stop_area_group
komplexe Stationen übersichtlicher machen und nicht einfache komplexer machen sollte.</div>
</div>
</div>
</div>
</div>
</body>
</html>