Grenzpunkte auf Staatsgrenzen

Daher dachte ich an das neutrale boundary = state_border wo die Grenzposten abgebaut sind, die Verkehrsregel sich aber ändern.
Damit könnte man selbst in einer einfachen open source Navi schneller eine Meldung generieren.

Können schon, aber wer braucht’s? Normalerweise ist es (Feldwege etc. ausgenommen) nicht zu übersehen, wenn man eine Staatsgrenze überquert. Erstens wegen der expliziten Kennzeichnung (vgl. Posting von hurdygurdyman), zweitens weil sich die Gestaltung der Verkehrszeichen und meist auch die Sprache ändert. Manche Grenzen bemerkt man drittens auch am Straßenbelag. Wenn das Auto auf der - plötzlich ganz anders numerierten - Autobahn über grob verlegte Betonplatten rumpelt, links und rechts Tafeln in einer ungewohnten Schriftart auf die Regeln zur Geschwindigkeit hinweisen, muß das Navi dem Fahrer wirklich noch mitteilen: du bist in Belgien? Und wenn ja, kommt es auf die paar Dekameter an, um die die Grenze vielleicht falsch eingezeichnet ist?

So argumentierend brauch man etliche weitere Dinge die wir erfassen nicht, weil sie ja nicht zu übersehen sind.

Eben. Es ist ja gerade der Sinn einer Karte wie OSM, Dinge zu erfassen, die man auch (egal ob mehr oder weniger deutlich) in der Realität sehen kann.

Gerade für Dinge wie sich ändernde Verkehrsregeln finde ich es durchaus sinnvoll zu erfassen, wo genau sich selbige ändern. Spontan würde mir dabei einfallen, die Regeln wie maxspeed etc. explizit zu taggen.

Zu dem Thema “Grenzpunkt” muß ich schon seit Tagen an diesen wirklich klasse gemachten Krimi denken: http://www.news.de/medien/855284806/zdf-krimi-die-bruecke-zwei-halbe-leichen-sind-nur-der-anfang/1/
Besonders makaber als die Leiche auf eine Bahre gelegt werden soll :wink:

Gruss
walter

Liegt die Dame auf dem Schnittpunkt von Grenzpolygon und Straße oder auf dem neu einzuführenden “Grenzpunkt”? :wink:

Ich verstehe nicht, wozu man den Unterschied macht zwischen dem Schnittpunkt Grenze/Straße und der Stelle, wo sich die Verkehrsregeln ändern. Ist das überhaupt so, dass sich die Regeln erst irgendwo anders ändern als auf der Grenze?

An vielen Stellen ist es egal, weil nur eine halbe Brücke in der Grauzone liegt. An vielen anderen Stellen (an einem Feldweg ganz ohne Zoll z.B.) wüsste man gar nicht, wo man den fiktiven “Grenzpunkt” hinlegen soll. Und an vielen Stellen weiss ich, dass sich die Regeln nicht an der Grenzstation ändern (Der Tunnel hier wird z.B. von schweizer Polizisten befahren, die schweizer Grenzer kontrollieren nördlich des Tunnels, die Italiener haben ihr Häuschen am westlichen Ufer des Sees.)

Grüße, Max

ich glaub ich weiß, was Marek meint. Zuerst hab ich es nicht verstanden, aber heute kam ich drauf. Wenn man bspw bei QGIS mittels “Intersect” ( wenn ich mich recht erinnere) ein Datenextrakt mittels einer Grenze ausschneidet, bekommen die Geometrien, also auch die Straßen, genau auf dem Schnittpunkt mit der Grenze einen Node an dem die Ways enden (naja, in der GIS Welt nicht unbedingt einen Node, aber wenn man sie zurück in *.osm umwandelt, ist da ein Node)
Flächen werden so abgeschnitten, dass innerhalb der Grenze alle Nodes bleiben, ausserhalb der Grenze aber die Nodes durch die Grenze selber ersetzt werden. Damit bleiben auch Flächen intakt.
Bei den OSM Tools ist es ja so, dass man entweder die Geometrien komplett lässt, womit dann die Wege mehr oder weniger weit über die Grenze reichen, oder abschneidet. Beim Abschneiden ist dann zwischem letzten Node der Geometrie und Grenze eine Lücke.

Will ich jetzt bspw ein Navi-Hersteller auf OSM Basis werden und die Länder in meinem super-tollen firmeneignen Format einzeln zum Download anbieten, habe ich ein Problem. Wenn jemand zwei aneinander grenzende Länder runter lädt, würde ich mit OSM Tools entweder Lücken oder überlappende Wege produzieren. Bei der QGIS Variante würde die Situation entstehen, dass man an der Grenze ein DupNode hätte, die man evtl SW-technisch als verbunden ansehen kann. Und wenn so ein Punkt in OSM schon vorhanden wäre und noch dazu einen Tag hätte, könnte man auch etwas unabhängiger von evtl kaputten Grenzen agieren.

Genau dieses Problem mit den abgeschnittenen Grenzen hat mich auch schon länger gestört… Stimmt, daran hätte ich bei diesem Thread nun gar nicht gedacht, aber das würde man natürlich ebenfalls lösen, wenn man bei Wegen, die eine Grenze kreuzen, einen Grenz-Node genau auf der Grenze setzt.

SunCobalt,
Du hast es auf den Punkt gebracht. Nehmen wir an,nicht “nur” ein Navi Hersteller, sondern ein anderer User, z.B. ADAC solche Extrakte vorbereiten wollte:
Wir machen mit einem solchen Schritt, der wirklich schnell von einer Community gemacht werden kann, es einem solchen User viel einfacher.
Ich weiß, dass dies ein Grund ist, der von OSM einige “Kunden” abschreckte, ohne, dass ich hier momentan keine Namen bzw. Details nehmen darf.
Selbst wenn wir es bei einem Waldweg nicht genau wissen, wo exakt der Punkt liegt, bereichern wir damit unsere Datenbank.

Viele Grüße,
Marek

Lass es mich mal umformulieren: Wir machen mit einem solchen Schritt, der wirklich schnell von einem User gemacht werden kann, der Community viel einfacher.

Warum sollte wir tausende nutzlose Punkte setzen und warten, wenn das fix mit QGIS und vermutlich auch anderer Software geht? Meiner Meinung nach ist das eher eine Frage der verfügbaren Tools.

Das ist keineswegs so nutzlos. Wenn ich a z.B. an die Geofabrik-Extrakte denke, die ich ganz gerne nutze, sehe ich durchaus einen Sinn. Dort überlappen benachbarte Länder teilweise, teilweise fehlen auch Stücke von Grenzen etc. Das könnte man mit sauber getrennten Ländergrenzen beheben.

Aber selbst wenn man exakt an den Grenzen schneidet, bleibt immer noch die Frage, was man mit Wegen oder Wegstücken macht, die zum Teil auf beiden Seiten der Grenze liegen. Sicher kann man das mit Tools wie QGIS in irgendwelchen Formaten machen, aber für jemanden, der mit den reinen OSM-Daten weiterarbeiten will und dem es auch auf Dinge wie Node-IDs ankommt (z.B. um die OSM-Daten später so zu verwenden, dass man direkt von der Anwendung zur OSM-Webseite oder dem Editor kommt, um eben jenen Node zu sehen oder zu bearbeiten), sind solche während der Verarbeitung erfundenen, künstlichen Nodes wenig hilfreich.

Vorschlag, da wir mappen, was wir sehen:
“highway=border_sign” auf die Straße an den Standpunkt des Schildes und analog border=* weitere tags.
Dann wäre noch sowas wie border_sign:forward=France usw. denkbar :confused:

edit:
Noch mal nachgedacht:
Man könnte auch boundary=border_sign nehmen, wobei das für jede Art von Grenzkennzeichnung stehen könnte. Der admin_level sollte dazu, um sauber zuordnen zu können. Details überlasse ich aber den Grenzspezialisten.
Bei Erfassung der Grenzschilder hätten wir zumindest an den wichtigen Verbindungen saubere Abgrenzungen. tertiary abwärts würde allerdings wohl überwiegend mangels Markierung fehlen.

admin_level als Detailangabe zu verwenden halte ich auf jeden Fall für sinnvoll - dann kann man das durchaus auch für unterschiedliche Arten von Grenzen verwenden. Das macht z.B. auch wieder Sinn, wenn man an das Ausschneiden von Ländern, Bundesländern oder amerikanischen Bundesstaaten denkt.

Diese bekommen entsprechenden Tag am Anfang und Ende ds Abschnittes wo sie “beidseitig” sind. Ein Importfilter behandelt sie dann entsprechend.

Die Idee mit: boundary=country_border finde ich gut.
Die Idee mit: boundary=border_sign ebenfalls, da die Staatsgrenzen nicht die einzigen Grenzen sind, die es gibt.
Irgendwie denke ich mir, man könnte hierfür über ein Proposal nachdenken.

Grüße,
Marek

-snip-

Ich habe in Google Maps mal geforscht und festgestellt, das zumindest hier zwischen Baden und Elsass sowie der Schweiz die Standpunkte der Grenzschilder nicht immer genau sind, weil sie mal in beide Richtungen an verschiedenen Standorten, mal nur in eine Richtung nicht am genauen Standort und in einem Fall sogar doppelt in eine Richtung stehen. Deshal sollte wir es bei boundary=country_border belassen und ggf. noch country_border=Border_sign zusätzlich als (mögliche) Quelle angeben.
Die Einordnung bei boundary=* hat m.E. den Vorteil, dass die key/value-Kombination den in der Realität oft nicht wahrnehmbaren virtuellen Objekten zugeordnet ist (weil da nicht immer ein Zaun drumherum ist).

edit:
Aber wie sagen wir den Auswertungen, welcher teil des Weges welchem Land zuzuordnen ist und müssen wir das überhaupt? :confused:

Wir müssen es nicht. Beim ausschneiden generiert man Länderpakete. Also weiß man was zusammen gehört. Viele Grüße, Marek

Das:
http://www.openstreetmap.org/?lat=47.593979090452194&lon=7.647559940814972&zoom=17
wird möglicherweise problematisch. Da läuft die zollfreie B317 über Schweizer Gebiet und muss in einem Deutschland-Extrakt zum Routen enthalten sein :confused:

Diese Straße bekommt eben keine Grenzpunkte, obwohl sie auf dem Territorium des Nachbarlandes liegt. Straße und Grenze müssen nicht identisch sein.
Es ist noch ein Vorteil dieser Methode.

Gleiches gilt für die 18178 an der Grenze zwischen Estland und Russland:

http://openstreetmap.org/?lat=57.9087&lon=27.707&zoom=14&layers=M

Da führt auch eine estnische Straße über russisches Gebiet, darf aber von Estland aus befahren werden (man darf aber nicht aussteigen). Der Grenzvertrag ich ohnehin kompliziert…