Which coordinates are used?

[Eveline van den Boom]

I noticed some inaccuracies for information in The Netherlands and was wondering which coordinates are used for the airports position.

For example the latitude and longitude of EHST in OpenAIP are based on the center of the main runway. The Aerodrome Reference Point is slightly more to the north.

I have made a change request but I'm wondering what the rule is here. Looks like the AIP data from the Netherlands is not ingested automatically.

Is this common practice or should I continue posting change requests so coordinates align with the ARP?

[openaip net]

Hi there.

Yes, there may be a differences between official AIP ARPs and openAIP ARPs. AIP data is currently only auto-ingested for UK airspaces. US, CA (and every source that provides detailed data on airspaces and airports) will follow. 

Technically, best would be to correct the "invalid" openAIP ARPs to match the official ones. I suppose the reasons for this are manifold because contributors may also create airports from the satellite view without having the 

official AIP at hand or it may also not exist. In this case, I assume the "best way" to get the ARP right is to use the center of the main runway.

So, if you have the AIP at hand and you if you can find the time, you are welcome to update the ARPs with the official coordinates! Let me know if you need any help or if you have any questions.

Cheers,

Stephan

[Peter Kemme]

Hi,

as a lot of official ARP coordinates are somewhere in the vicinity of the RWY. I´ve modified a lot of ARP´s in the last 10 years to the position of the middle of the main runway.

It is here at EHST the same. The official ARP is about 200m north of the official RWY, somewhere in the crops. From my point of view this does not make sense at all.

Peter

[Eveline van den Boom]

Hi Peter,

I was afraid you were going to say this. Because the whole idea of an ARP is having a reference point that never changes, regardless of what happens at the airport: building a new terminal, move the main runway, break down and build a new control tower. Although it's initial location may be selected with some sense of logic, e.g. center of the field, mid of the runways, after time it may be a random point and that's perfectly fine. If I measure the distance between EHST and EHLE, I measure between their respective ARP's and expect the same result now as in the future. Distances and bearings are also published on airport charts, instrument procedures etc. 

My problem is that I try to use latitude/longitude of airports to identify small airports. I'm considering to replace my old OurAirports database with user changes to OpenAIP. Most GA airports have no consistent naming or standardized identifier, like an ICAO code. They only thing I can use to distinguish them is their location. I'm building a script that checks for each OpenAIP airports latitude/longitude if there's already an airfield at that place and if so, to ignore the new entry. Ideally I should be able to set the allowance to 100 meter. But that's not possible if ARP's get dragged around the airports from one arbitrary location to another. 

Maybe it's an idea to record the ARP's somewhere in the OpenAIP database and never to change them, unless there is a change in the actual AIP. Or keep an extra attribute that holds the definition of the latitude/longitude presented (actual ARP, center of the runways as determined by the editor, calculated somehow etc.)?

Regards,

Eveline

[openaip net]

Hi again,

currently, the openaip database contains both ARP "types", i.e. "center of the main runway" and the official ARP from the AIP. Due to the history of openaip the "center of the main runway" type  is used more than the actual official one. Given the fact that there also can be multiple ARPs for a single airport (see EDDF) and the current model does not provide multiple ARPs at all, I would like to keep it "as is" and set the airport's ARP in openaip at the center of the main runway. Sure, this will require changes if the main runway changes and does not align with the official AIP but the benefit of this is, that each user, at least in most cases, can assume a runway at this position during flight.

I also think that there are quite a lot of small airports (ULM) out there that don't have an official ARP at all. In this case, the most logical position would be to also set it at the center of the main runway.

Overall, the actual "change rate" of each airport's ARP (at least in openaip) is very slow. If you run into problems with you specific use-case, we can also discuss this via direct messages. Maybe we can find a solution for that.

Cheers,

Stephan

[Eveline van den Boom]

Hi Stephan,

What I was trying to accomplish was merging a database with OurAirports data with OpenAIP. Matching for ICAO airports is no problem of course. But everything else has no identifier in the OpenAIP database. Only way to match them is by latitude/longitude (with a small margin). Eventually I figured it out, the code has become quite complex but the matching seems to work now. 

Just one suggestion to make these kinds of tasks easier; maybe you can add a field for the local airport identifier to the database? For example the FAA LID in the U.S. That would have helped a great deal. 

Regards,

Eveline

[openaip net]

Hi Eveline,

glad to hear that your back on track with your task and all seems to work out. Regarding the FAA LID: can you point me to a source where those are defined for at least US airports? I have
to read more about this before adding it to the model. Since we already have ICAO, IATA and a custom "generic" identifier, it seems like adding another identifier field that should be filled with
data is a tad too much... I suppose it would be more beneficial to have a good data coverage for ICAO and IATA codes. 

Cheers,

Stephan