http://silicon-verl.de/home/flo/tmp/20151218/ Hier eine einfach Auswertung der Zeilen in den .txt files: 16843 Regierungsbezirk Detmold 4629 Kreis Herford 3757 Kreis Höxter 3049 Kreis Lippe 3045 Rödinghausen 2940 Bielefeld 2403 Kreis Minden-Lübbecke 2175 Borgentreich 1217 Petershagen 1137 Kreis Gütersloh 868 Kreis Paderborn 654 Werther 560 Bad Driburg 547 Willebadessen 536 Porta Westfalica 531 Spenge 529 Horn-Bad Meinberg 523 Herford 515 Halle (Westfalen) 479 Leopoldshöhe 470 Extertal 442 Oerlinghausen 354 Bad Oeynhausen 346 Barntrup 333 Bünde 292 Beverungen 249 Bad Wünnenberg 236 Paderborn 227 Büren 224 Blomberg 218 Kalletal 167 Vlotho 136 Brakel 123 Höxter 121 Lemgo 110 Minden 108 Altenbeken 104 Detmold 99 Warburg 99 Kirchlengern 88 Löhne 75 Stemwede 67 Hiddenhausen 64 Lichtenau 55 Lübbecke 44 Bad Salzuflen 43 Lügde 41 Salzkotten 33 Preußisch Oldendorf 32 Dörentrup 29 Schlangen 19 Borgholzhausen 18 Espelkamp 16 Steinhagen 16 Hövelhof 14 Delbrück 13 Hüllhorst 13 Hille 12 Rahden 11 Nieheim 10 Augustdorf 9 Marienmünster 6 Steinheim 6 Lage 6 Enger 5 Schloß Holte-Stukenbrock 5 Schieder-Schwalenberg 2 Borchen 2 Bad Lippspringe 1 Langenberg 0 Versmold 0 Verl 0 Rietberg 0 Rheda-Wiedenbrück 0 Herzebrock-Clarholz 0 Harsewinkel 0 Gütersloh -- Florian Lohoff f@zz.de We need to self-defend - GnuPG/PGP enable your email today!
Hallo Florian, ich hab mir grad mal die Bielefelder Liste angeschaut. Gleich der erste Eintrag http://localhost:8111/load_object?objects=w5056091,w114285590 verweist auf einen highway=pedestrian & area=yes der mit einem highway=residential verbunden ist, das sollte doch eigentlich richtig sein? Gruß Ingo Am 18. Dezember 2015 um 11:27 schrieb Florian Lohoff <f@zz.de>:
http://silicon-verl.de/home/flo/tmp/20151218/
Hier eine einfach Auswertung der Zeilen in den .txt files:
16843 Regierungsbezirk Detmold 4629 Kreis Herford 3757 Kreis Höxter 3049 Kreis Lippe 3045 Rödinghausen 2940 Bielefeld 2403 Kreis Minden-Lübbecke 2175 Borgentreich 1217 Petershagen 1137 Kreis Gütersloh 868 Kreis Paderborn 654 Werther 560 Bad Driburg 547 Willebadessen 536 Porta Westfalica 531 Spenge 529 Horn-Bad Meinberg 523 Herford 515 Halle (Westfalen) 479 Leopoldshöhe 470 Extertal 442 Oerlinghausen 354 Bad Oeynhausen 346 Barntrup 333 Bünde 292 Beverungen 249 Bad Wünnenberg 236 Paderborn 227 Büren 224 Blomberg 218 Kalletal 167 Vlotho 136 Brakel 123 Höxter 121 Lemgo 110 Minden 108 Altenbeken 104 Detmold 99 Warburg 99 Kirchlengern 88 Löhne 75 Stemwede 67 Hiddenhausen 64 Lichtenau 55 Lübbecke 44 Bad Salzuflen 43 Lügde 41 Salzkotten 33 Preußisch Oldendorf 32 Dörentrup 29 Schlangen 19 Borgholzhausen 18 Espelkamp 16 Steinhagen 16 Hövelhof 14 Delbrück 13 Hüllhorst 13 Hille 12 Rahden 11 Nieheim 10 Augustdorf 9 Marienmünster 6 Steinheim 6 Lage 6 Enger 5 Schloß Holte-Stukenbrock 5 Schieder-Schwalenberg 2 Borchen 2 Bad Lippspringe 1 Langenberg 0 Versmold 0 Verl 0 Rietberg 0 Rheda-Wiedenbrück 0 Herzebrock-Clarholz 0 Harsewinkel 0 Gütersloh
-- Florian Lohoff f@zz.de We need to self-defend - GnuPG/PGP enable your email today!
_______________________________________________ OSM mailing list OSM@gt.owl.de http://gt.owl.de/cgi-bin/mailman/listinfo/osm
On Fri, Dec 18, 2015 at 01:14:02PM +0100, SaWaTec (Ingo Wakop) wrote:
Hallo Florian, ich hab mir grad mal die Bielefelder Liste angeschaut. Gleich der erste Eintrag http://localhost:8111/load_object?objects=w5056091,w114285590 verweist auf einen highway=pedestrian & area=yes der mit einem highway=residential verbunden ist, das sollte doch eigentlich richtig sein?
Der ist nicht verbunden - der geht auf der Kante lang. D.h. die Straße geht auf der Aussenkante der Fläche weiter. Wenn man davon ausgeht das highways nicht überlappen sollen dann ist das schon aus dem Grund kaputt. Da liegt ein highway=residential über/unter einem highway=pedestrian. Renderingtechnisch halte ich das für kaputt weil 2 gleichwertige Objekte ohne layer übereinanderliegen. Das Ergebniss im rendering wird nicht vorhersagbar sein, bzw vom ordering in der config abhängen. Es gibt ggfs. einen Grund das so zu lassen. Routingengines die aus ihrem Graphen highway=* area=yes rauswerfen. Also d.h. kein Routing über die Fläche bzw über die Außenkante können. Meines Wissens nach können das die gängigen routing engines d.h. die routen zumindest auf der Außenkante der Fläche. Flo -- Florian Lohoff f@zz.de We need to self-defend - GnuPG/PGP enable your email today!
Ah, alles klar danke Ingo Am 18. Dezember 2015 um 14:34 schrieb Florian Lohoff <f@zz.de>:
On Fri, Dec 18, 2015 at 01:14:02PM +0100, SaWaTec (Ingo Wakop) wrote:
Hallo Florian, ich hab mir grad mal die Bielefelder Liste angeschaut. Gleich der erste Eintrag http://localhost:8111/load_object?objects=w5056091,w114285590 verweist auf einen highway=pedestrian & area=yes der mit einem highway=residential verbunden ist, das sollte doch eigentlich richtig sein?
Der ist nicht verbunden - der geht auf der Kante lang. D.h. die Straße geht auf der Aussenkante der Fläche weiter. Wenn man davon ausgeht das highways nicht überlappen sollen dann ist das schon aus dem Grund kaputt.
Da liegt ein highway=residential über/unter einem highway=pedestrian.
Renderingtechnisch halte ich das für kaputt weil 2 gleichwertige Objekte ohne layer übereinanderliegen. Das Ergebniss im rendering wird nicht vorhersagbar sein, bzw vom ordering in der config abhängen.
Es gibt ggfs. einen Grund das so zu lassen. Routingengines die aus ihrem Graphen highway=* area=yes rauswerfen. Also d.h. kein Routing über die Fläche bzw über die Außenkante können.
Meines Wissens nach können das die gängigen routing engines d.h. die routen zumindest auf der Außenkante der Fläche.
Flo -- Florian Lohoff f@zz.de We need to self-defend - GnuPG/PGP enable your email today!
_______________________________________________ OSM mailing list OSM@gt.owl.de http://gt.owl.de/cgi-bin/mailman/listinfo/osm
Am 18.12.2015 um 14:34 schrieb Florian Lohoff:
On Fri, Dec 18, 2015 at 01:14:02PM +0100, SaWaTec (Ingo Wakop) wrote:
Hallo Florian, ich hab mir grad mal die Bielefelder Liste angeschaut. Gleich der erste Eintrag http://localhost:8111/load_object?objects=w5056091,w114285590 verweist auf einen highway=pedestrian & area=yes der mit einem highway=residential verbunden ist, das sollte doch eigentlich richtig sein? Der ist nicht verbunden - der geht auf der Kante lang. D.h. die Straße geht auf der Aussenkante der Fläche weiter. Wenn man davon ausgeht das highways nicht überlappen sollen dann ist das schon aus dem Grund kaputt.
Da liegt ein highway=residential über/unter einem highway=pedestrian.
Renderingtechnisch halte ich das für kaputt weil 2 gleichwertige Objekte ohne layer übereinanderliegen. Das Ergebniss im rendering wird nicht vorhersagbar sein, bzw vom ordering in der config abhängen.
Es gibt ggfs. einen Grund das so zu lassen. Routingengines die aus ihrem Graphen highway=* area=yes rauswerfen. Also d.h. kein Routing über die Fläche bzw über die Außenkante können.
Meines Wissens nach können das die gängigen routing engines d.h. die routen zumindest auf der Außenkante der Fläche.
Flo
Hallo, die verbleibenden beiden Verklebungen in Enger sind ja auch zwei highway=pedestrian-Areas die an einer Straße kleben: Steinstraße mit Barmeierplatz und Königin-Mathilde-Platz: http://overpass-turbo.eu/?q=LyoKVGhpcyBoYcSGYmVlbiBnxI1lcmF0ZWQgYnkgdGhlIG92... (keine Shortlinks mehr?) Das wollte ich gerade eigentlich korrigieren und musste feststellen, dass mir doch nicht so recht klar ist wie. Noch ist mir keine Lösung gekommen die unterm Strich eine Verbesserung darstellt. Überlegungen bisher: - Die Areas komplett von der Straße trennen. Da geht natürlich jegliche Information verloren, dass da eine Verbindung besteht. Das mit Pfaden da irgendwie dranzustitchen wäre jetzt auf mehreren Ebenen einfach nur häßlich. Zumal es von den Plätzen ja nicht separate Verbindungswege zur Straße gibt. - Straße über den/die Plätze führen, nicht aber über die Kante und dann an den beiden Schnittpunkten eine Verbindung machen. So war jetzt mein eigentlicher Plan. Das löst allerdings nicht das Problem, dass da dann wieder zwei Straßen auf einer Ebene übereinanderliegen. Das mittels layer=... zu lösen sehe ich in dem Fall eher als Hack bzw. Mappen für den Renderer an, weil ich da keine zwei Ebenen in der Realität sehe. Außerdem müsste man beim Königin-Mathilde-Platz tierisch aufpassen, dass der nicht plötzlich in der Tiefgarage steckt. ;) Gibt's hierfür irgendeine schöne Lösung? Andreas
On Tue, Dec 22, 2015 at 06:41:27PM +0100, tabris wrote:
Das wollte ich gerade eigentlich korrigieren und musste feststellen, dass mir doch nicht so recht klar ist wie. Noch ist mir keine Lösung gekommen die unterm Strich eine Verbesserung darstellt. Überlegungen bisher: - Die Areas komplett von der Straße trennen. Da geht natürlich jegliche Information verloren, dass da eine Verbindung besteht. Das mit Pfaden da irgendwie dranzustitchen wäre jetzt auf mehreren Ebenen einfach nur häßlich. Zumal es von den Plätzen ja nicht separate Verbindungswege zur Straße gibt. - Straße über den/die Plätze führen, nicht aber über die Kante und dann an den beiden Schnittpunkten eine Verbindung machen. So war jetzt mein eigentlicher Plan. Das löst allerdings nicht das Problem, dass da dann wieder zwei Straßen auf einer Ebene übereinanderliegen. Das mittels layer=... zu lösen sehe ich in dem Fall eher als Hack bzw. Mappen für den Renderer an, weil ich da keine zwei Ebenen in der Realität sehe. Außerdem müsste man beim Königin-Mathilde-Platz tierisch aufpassen, dass der nicht plötzlich in der Tiefgarage steckt. ;)
Gibt's hierfür irgendeine schöne Lösung?
Nein - Ich habe auch so 2-3 dinger dieses Typs bei denen ich nicht so wirklich weiss wie es gehen soll. Auf der Kante ist falsch weil eben dann die fläche nur bis zur mitte geht. Durch die Fläche führen halte ich nur für richtig wenn die highway typen identisch sind. D.h. highway=pedestrian geht durch eine Fläche die pedestrian/area=yes ist - Das würde ich sagen ist legitim und das würde ich dann an den Kanten auch mit nodes verbinden. Das kann dann auch im selben layer sein. Ein highway=residential kann nicht durch ein highway=pedestrian/area=yes gehen - Das wäre ja ein typenkonflikt. Bei so einem Konstrukt würde ich das vermutlich entkleben und dann verbindungen schaffen da wo sie Sinn machen z.b. an den Ecken oder so ... Flo -- Florian Lohoff f@zz.de We need to self-defend - GnuPG/PGP enable your email today!
participants (3)
-
Florian Lohoff -
SaWaTec (Ingo Wakop) -
tabris