DE talk:Luftraum

Umzug

Ich habe mich daran gemacht, das ganze in ein Proposal umzustricken, so bleibt das ganze nciht nur auf einer deutschen Ebene, sondern man kann sich international daran versuchen es bestmöglichst umzusetzen, das ganze ist hier zu finden: Proposed_features/Airspace

Meinungsbild

ich bin gegen die integration dieser daten in openstreetmap. da die daten sowieso von außen kommen und nicht per crowdsourcing erfasst werden. die luftraumsektoren sind durchaus mit den srtm-höhendaten vergleichbar. eine luftraumkarte kann trotzdem erstellt werden, so wie es die cyclemap mit den höhenlinien oder die reit- und wanderkarte mit den höhenschummerungen macht. außerdem wären die luftraumsektoren so besser vor (versehentlicher) veränderung geschützt. --xylome 07:52, 26 May 2009 (UTC)

Mit dieser Begründung könnten auch Daten von Landesgrenzen, Stadtgrenzen, etc. als in der Datenbank unnütz angesehen werden, die stammen ja auch von den Definitionen der Gemeinden her. Gleiches gilt für Bevölkerungszahlen, die wohl auch kaum von Hand gezählt werden, sondern aus Datenbanken integriert werden um einen gemeinsamen Datenstamm zu haben. TobiBS 14:33, 26 May 2009 (UTC)

Beitrag zurückgezogen Wolfbert 05:11, 18 June 2009 (UTC)

Struktur

Wäre es nicht besser ein Templates analog von DLAND.AIR http://www.flightplanner.de/Download/airspaces/airspace.htm zu verwenden:

Name	Tagging	Used on	Definition	Rendered as	Status	Draft start	RFC start	Vote start	Vote end
Airspace	class, name, callsign, type, frequency, lowerLimitType, lowerLimit, upperLimitType, upperLimit, time_of-activity = *	area	Airspce	*	Draft	2008-12-27	*	*	*

viele Grüsse Andreas

Ich würde das ebenso sehen, das wie oben zu taggen. In diesem Zug sollten auch gleich Pflichtmeldepunkte und Funkfeuer integriert werden. Ich habe mal ein Muster für die CTR Braunschweig und die ED-R 30 nördlich davon gemacht, um damit mal etwas zu experimentieren, herausgekommen ist dabei:

Bzgl. des Vorschlags von oben, ich würde callsign und frequency rauslassen, denn das ist ja nicht immer eindeutig und schon gar nicht zeitlich immer gleich. Was type angeht, soll hier CTR oder nciht getaggt werden, oder wofür ist das gut? Soll in Upper und Lower Limit Type auch die Einheit mit rein? Die time of activity ist auch noch ein für mich fragwürdiger Punkt, wie will man das auch nur halbwegs standardisieren, die Bandbreite der Definition ist da sehr groß.

Bitte meine Bedenken nicht falsch verstehen, ich finde die Idee sehr gut! TobiBS 12:08, 24 May 2009 (UTC)

Rechte

Ich will ja kein Spielverderber sein, aber sind die Daten wirklich frei in dem Sinne, dass man sie in OSM integrieren kann? TobiBS 13:20, 23 May 2009 (UTC)

Quatsch

Sorry, aber ich halte das fuer Quatsch. Erstens mal bist Du als Pilot verpflichtet, aktuelle offizielle Karten zu benutzen, d.h. Du musst, wenn Du nicht im Falle eines Unfalls von der Versicherung weggeschickt werden willst, sowieso die offiziellen Karten kaufen (und ehrlich gesagt, wuerde fuer mich an der Stelle auch das Vertrauen in den Hobbymapper aufhoeren).

Zweitens haben Luftraumdaten in 99% der Faelle NULL Bezug zu irgendwas am Boden (die Grenze des Luftraums ist nicht an einem Fluss oder Waldstueck oder einer Autobahn oder so), d.h. sie haben auch ueberhaupt nichts mit unserem Mapping zu tun. Es ist ueberhaupt kein Problem, die Luftraumdaten in einer separaten Datenbank zu halten und dann auf Wunsch auf einer OSM-Karte einzublenden. (Im Gegensatz zu sowas wie Stadtgrenzen oder so, wo es sinnvoll ist, dass der Fluss, an dem die Grenze entlanglaeuft, und die Grenze selbst in der gleichen Datenbank sind).

Ich zweifle ausserdem daran, dass die Daten wirklich "frei" erhaeltlich sind. Und selbst wenn das so ist, handelt es sich doch um Daten mit einem offiziellen Charakter, die Du nicht jeden Potlatch-User veraendern lassen willst - dafuer ist in OSM kein Platz, in OSM kann jeder alles aendern. Die Luftraum-Begrenzungslinien wuerden im Editor kreuz und quer ueber die Karte laufen und die normalen Nutzer stoeren.

Ich kann nichts Positives daran sehen, Luftraeume in OSM zu haben. (Das gilt uebrigens ebenso fuer Anflug-/Abflugrouten, die Leute z.T. schon mit route=flight mappen - im Gegensatz zum von Dir vorgeschlagenen Luftraumimport haben die das zwar sogar mit GPS aufgezeichnet, aber wenn es nicht gerade das ILS ist, fliegt da ja auch lang nicht jeder Flieger gleich, was soll das also, das ist grad so, als ob ich meine Cross-Country-Fahrt mit dem MTB mappen wuerde.)

--Frederik Ramm 06:55, 7 June 2009 (UTC)

Da ich das ganze schon als Proposal veröffentlicht habe und du dort auch geschrieben hast, habe ich auch dort geantwortet, hielt ich zumindest für sinnvoller, für alle anderen die sich an der Diskussion beteiligen wollen: Proposed_features/Airspace#Unmappable_and_unusable TobiBS 09:26, 7 June 2009 (UTC)

"Erstens mal bist Du als Pilot verpflichtet, aktuelle offizielle Karten zu benutzen." - Gleiches Argument gilt fuer freie Tonne und Openseamap.

"Die Luftraum-Begrenzungslinien wuerden im Editor kreuz und quer ueber die Karte laufen und die normalen Nutzer stoeren" - Das ist in Meinen Augen dann ein Manko der Datenvisualisierung im Editor. Bei mir stoeren Tiefgaragen, die in der gesamten Stadt eingezeichnet wurden und Grenzlinien, die durch alles durchgehen... --Jstein 09:55, 27 May 2010 (UTC)

Teilweise Quatsch

Meinem Vorredner Frederik kann ich beinahe zustimmen: Es gibt meiner Meinung nach durchaus einen Bedarf an aktuellen und kostenlosen Luftraumkarten. Ich persönlich würde die Erstellung einer OSM-basierten Luftraumkarte begrüßen und sie auch nutzen.

Für den Rest seine Ausführungen "full ack":

• Bezug zum Boden fehlt (außer Bezug zu Flughäfen)
• Karte als Overlay ist möglich (eventuell mit anderem Rendering, ähnlich ICAO oder LuGeKa)
• Manipulationsgefahr (un/absichtlich)

Außerdem: Die Daten sind vollständig vorhanden und ändern sich nur selten (und dann mit Ankündigung). Crowdsourcing ist da nicht angebracht.

Fazit: OSM-basierte Luftraumkarte: Ja, Luftraumdaten in OSM-Datenbank: Nein

--JohannesF 11:38, 22 June 2009 (UTC)

Es freut mich, dass wenigstens der Zeck einer freien Luftfahrtkarte erkannt wird, was den Punkt Crowdsourcing angeht, ich kenne keine freie Datenbank in der die Luftraumdaten vorhanden sind, somit bleibt nur das mühsame Extrahieren aus der AIP und ich weiß nicht, ob man das sinnvoll automatisieren kann, insofern ist Handarbeit angesagt.

Was den Bezug zum Boden angeht, der ist teilweise vorhanden, die Definition z.B. von Pflichmeldepunkten basiert fast immer auf Bodenmarken, genauso R-Lufträume, die liegen häufig über Truppenübungsplätzen, etc.

Wenn ich mir Frederiks Ideen für die API 0.7 anschaue, könnte man dann nicht einen Layer des angedachten Konzepts nutzen um die Daten unterzubringen, ich sehe nämlich nicht die Möglichkeiten und Motivation, die Daten extern zu beherbergen, außerdem ist es fraglich, welche Lizenz sie dann irgendwann mal haben, darum denke ich immer noch, dass es das einfachste wäre sie mit in die Datenbank aufzunehmen.

TobiBS 19:54, 28 June 2009 (UTC)