Import von "Staging Areas" auf dem Gelände des Frankfurter Flughafens

Hallo,

auf dem Gelände des Frankfurter Flughafens wurden rund 1000 Ways mit aeroway=staging_area importiert: overpass turbo - das ist der DWG zufällig aufgefallen, weil diese Ways später wieder gelöscht und durch neue ersetzt wurden. Was haltet ihr von diesen Daten - ist dieser Import sinnvoll?

Ich lade auch den verantwortlichen Mapper via Changeset: 178050925 | OpenStreetMap hierher ein (ich hätte eigentlich erwartet, dass er diese Diskussion hier selber beginnt).

Bye
Fredeirk

Hi Frederik,

I thought I had already given you enough answers.

Yes - the lines are visible. They describe the areas in which equipment may be parked without obstructing an aircraft. I have received this data from FRAPORT. There was a correction to the first delivery, as the markings around the T3 are now finalized. As it was difficult to delete individual changes, I deleted the entire changeset and reinserted it with the new information.

Wenn jemand einen Nutzen aus diesen “staging areas” zieht, von mir aus gern.

Was mich hier viel mehr stört, dass ich eine Unmenge nicht geschlossener Polygone darunter finde, die, wenn ich die Intension korrekt verstanden habe, sich gegenseitig überlagern. Ich kann mir beim besten Willen nicht vorstellen wie das funktionieren kann.
Wenn wir so was in OSM haben wollen, dann bitte korrekt und nutzbar. In diesem Zustand qualifiziert die technische Qualität das in meinen Augen als Müll.

5 Likes

Was any of your both mechanical edits discussed ahead of time? If so, please point to that discussion.

1 Like

No - I didn’t know that’s necessary to discuss this. I thought it is an important information like the position lines

The reason it must be discussed is not to judge how important these are, but because it is an import. If you had surveyed them yourself it would not be required to discuss.

1 Like

I observed this data by myself

These are two completely different statements.

5 Likes

In order for OpenStreetMap to be a suitable vehicle for this data, everybody should be able to obeserve and correct this data. For example, if FRAPORT, when they want to change staging areas, first have to go onto the field and change some paint markings, then it could make sense for us to keep the data in OSM - because OSMers could observe the paint markings. If, on the other hand, this is data that only FRAPORT has and nobody can “correct” it by looking at paint markings, then it makes little sense to maintain the data in OSM - OSM would then be reduced to “transporting” someone else’s data and that’s not what we do.

6 Likes

“everybody” is always relativ to the context. We have to assume at least a certain level of knowledge and (Fach-) competence. Not everybody understands railway or waterway traffic rules and signs. And here, you/we should at least read the relevant rules for Fraport Apron Drivers as described for example in “Refresher Training Apron Driver`s License (PDF)
§4 Street types and airport specific markings - Staging areas (pages 29ff) describes how staging areas are marked on the ground, and that there are two different types of restrictions to consider:

  1. Height restrictions
  2. Use/time restrictions

The osm ways created by @Alex0708 are a wild mixture of borderlines that may be used/needed to describe these areas with and without restrictions.
Let us look for example at a specific parking position V168 (center line aeroway=parking_position):

This seems to be the outer border of the staging area for V168 not regarding any restrictions:

I guess, that this part might be height restricted,

and this part probably represents a use/time restriction, none of which is reflected in osm tags.

@klik already mentioned, that a lot of the “staging area” osm ways are not closed, and overall they seem to be (incomplete) borders of different restriction areas.

1 Like

I highly doubt that, since your lines do not match the paintings on aerial pictures, see below.

The discussion is required to find out all the issue before hand and not only afterwards like now. The stuff you imported is mainly “trash” from OSM perspective. That doesn’t mean those features should not be in OSM. Adding them would be fine. But you might need to get the quality to a certain level.

You might want to discuss as well with the community, how this is going to be mapped best. Like map an area or map the lines. My suggestion: Do it for one stand, discuss it with the community. If “everyone” is fine with the way how to keep the data in OSM, document it and then think about how to get all the stands/gates mapped.

It may not match your version of aerial pictures, but it looks different (OK except for the incompleteness) in the iD editor with Hesse DOP 20 images:

The geometry has changed between both versions of aerial pictures, but i don’t know which is more recent.

“trash” is a little harsh. I would call it more like raw material which needs a lot of refinement. If we will add the different restrictions areas, they have at least to be attributed with meaningful tags.

1 Like

Ok - I will remove this entries. The data were handover by IFM - the FRAPORT department who is responsible for all geo information- so it shouldn’t be trash. Yes - they have some more details - like Abstellfläche A or B or C - maybe this represents the time restriction, …

The information represents the red painted lines. If they are overlapped by other lines, the last closing line is missing. To close the lines and create real polygons is not difficult - but I believe, this is not the main issue.

There are also misalignments compared to Hessen DOP20.

I don’t think so. There are a bunch of areas (seems like the whole stand). There are some dashed lines. There are a bunch of solid lines. Any many more. Everything tagged as aeroway=staging_area. Sure we have ATYL, but even ATYL should be in a way you can make sense out of it. That’s why I suggested to first think about how to add it.

Exactly.
The first issue is the license. If you got any kind of data from third party, the granted license should be documented in our wiki.
The second issue is the concept of how all those data should be kept in OSM. I would think those should be areas and somehow they lack differentiation.
The third issue then would be the quality, but this will result out of (2).

2 Likes

Hi @aighes - just a quick note about the comparison between the lines I configured and the lines drawn on the map.
These were changed in 2022. This means that the lines on the aerial photo are out of date and the lines I drew are correct.