Talk:Tag:sport=free flying

From OpenStreetMap Wiki
Jump to navigation Jump to search

use leisure=pitch?

Should we also use leisure=pitch for all free_flying sites?

Question about free_flying:site_orientation=*

The tag free_flying:site_orientation=* is almost tagged with a comma, if there are multiple values. Should it not be tagged with a semicolon? Because on other tags, if there are multiple values, they are always separated with a semicolon. And I think, to be consistent, it should separated by semicolon also on this tag. --Efred 09:37, 21 August 2012 (BST)

I don't care wether it is ; or , sletuffe 15:48, 21 August 2012 (BST)
I like consistency. Semicolon++. --DaniloB 23:06, 21 August 2012 (BST)
Updated the wiki page. --DaniloB (talk) 22:41, 28 August 2018 (UTC)

"free_flying" VS "Paragliding"

"free_flying" isn't used in English. What you're describing is referred to in English as "Paragliding". SomeoneElse (talk) 21:30, 30 August 2013 (UTC)

"free_flying" is complete incorrect in my opinion. In English, this is "paragliding". In German and English the word "Freeflying" means something different: a skydiving discipline! Please look on the English and German Wiki page for "freeflying". Free_flying seems to be incorrect, misleading and nonsense. See Freeflying (English) and Freeflying (German) Thuringian (talk) 20:56, 4 January 2022 (UTC)

FWIW, SomeoneElse and Thuringian, there is precedent for the use of "free flight" as an umbrella term for foot launch aircraft, at least in the USA. See for example this USHPA page, or the freeflight reddit. -- Gwicke (talk) 02:06, 9 March 2025 (UTC)

free_flying:site=toplanding

Yeah, it's been 4 years and I should have said so earlier, but imho free_flying:site=toplanding should be deprecated in favor of free_flying:site=landing since I don't see why a top landing wouldn't be a landing in the first place (optionnaly with an ele=* if you feel like it.) sletuffe (talk) 12:37, 13 September 2016 (UTC)

That sounds reasonable to me. --DaniloB (talk) 22:39, 28 August 2018 (UTC)
Marked it as deprecated in the description. Not sure what the proper process is. --DaniloB (talk) 23:09, 4 February 2021 (UTC)

"landing" means landing on a height remarkable lower than takeoff height. "toplanding" is for experienced people only and requires special skill and training. The height for toplanding may be higher than the takeoff height. This difference is VERY important, otherwise it creates a danger for the inexperienced people. I am a paraglider. --Thuringian (talk) 20:37, 4 January 2022 (UTC)

free_flying:site=packing

Hello,

I would suggest the tag free_flying:site=packing to specify packing area on landing or take off where those space are designated and even compulsory.

For example, the landing of Doussard, is stricly delimited (you can even see it from imagery, it is the east part on the side of the gravel and bench). It would be interesting to have this information for flight preparation.

Sounds good to me. I also know some sites that have a dedicated packing area. --DaniloB (talk) 23:06, 4 February 2021 (UTC)

free_flying:site=groung_handling and ground_handling=permissive

Hello again,

I would also suggest the tag free_flying:site=ground_handling to specify a training area that is flat to train the "handling" of the paraglider. These can be strictly delimited area or permissive on some landing area as long no one is going to land. For landing where ground handling is permissive I suggest to add gound_handling=permissive on the landing area.

To differentiate this area from the landing by name I suggest adding a name like "Ground handling area of <site name>". --Futur3r (talk) 15:22, 4 February 2021 (UTC)

I think this is resolved with the addition of free_flying:ground_handling=yes|no|permissive. -- Gwicke (talk) 01:59, 9 March 2025 (UTC)

companies producing / shops selling equipment

How to tag a company or shop ? see Key:aerospace:product taginfo :sales

Shop=free_flying has 13 uses. Which is probably 13 more then there is for whatever random, useless, nonsense namespace scheme your trying to push by asking. BTW, you should sign your comment. --Adamant1 (talk) 06:00, 1 May 2021 (UTC)

free_flying:speedflying=yes/no

Hello,

I would suggest the tag free_flying:speedflying=yes/no. Speedflying locations may not be suitable for paragliding and vice versa. --SergienkoMike (talk) 03:48, 15 July 2021 (UTC)

SergienkoMike, I like the idea & use of a key (easier to extend, e.g. with a "permissive" value). Would it make sense to potentially add similar keys for free_flying:hang-gliding and free_flying:paragliding in the future? Should those be at the top level of the free_flying hierarchy? My gut sense would be yes to both, but curious what people think. -- Gwicke (talk) 01:57, 9 March 2025 (UTC)
There are already tags for handggliding, and paragliding, and also rigid, which applies to handggliding, I'm not sure why there are two of them.
I'm not sure what you mean by top of the hierarchy. These are all tags that are attributes of a location. As far as I understand there isn't any hierarchy.
Also, I would like to know, I've seen that you talk about the permissive value in a lot of your comments, but it doesn't seem to make a lot of sense to me in the context that you brought it up. in the context of speed flying, what would it even mean for a site to be speed flying permissive? Hardcover2452 (talk) 10:17, 9 March 2025 (UTC)
Hardcover2452, good point about the existing tags (e.g. free_flying:paragliding=yes). So free_flying:speedflying=* fits the same pattern. Re hierarchy, I meant the colon-delimited key structure. So free_flying:site= vs. a hypothetical free_flying:site:something=. I know they are just strings to the DB, but the structure is relevant to how we humans think about it, and also to how autocomplete works in editors.
Re permissive speed flying, I am thinking of the situation where speed flying is not officially supported by the site / club, but is also not strictly illegal. For example, we have a local launch where speed flyers usually do not have the glide to reach any official LZ. As a result, we cannot support speed flying at this site, and make as much clear in our site guide. However, the *launch* is public land, and we as a club do not have the authority to make speed flying illegal. Speed flyers still launch there, but then typically end up landing in illegal / dangerous places, for example on train tracks. Perhaps "discouraged" would be an even better value than "permissive" in that (I think fairly common) case? -- Gwicke (talk) 16:48, 9 March 2025 (UTC)
About the hierarchy, I understand what you're saying, but I'm not sure it fits the current mapping method here, which seems to not have any hierarchy, and I'm not sure that introducing it really benefits the current situation.
about the permissive value. I understand what you're saying. It does make sense. I'm just from a region without any official landing or take-off spots and therefore everybody has to make their own decisions about what's right. And in my region the mapping mostly applies to whether the conditions allow or don't allow it. So if this makes sense to you in your region, I would say go ahead and update the wiki.
As for updating the wiki, please try to keep it as backwards compatible as possible, even if you do plan to use a bot to update some of the places. That's what I did, because there are some automated systems that might use this data. For example, some of the fields that are not relevant I marked as deprecated but kept them in the wiki and any field that I changed I made sure that old values can still be applied and understood. Hardcover2452 (talk) 17:25, 9 March 2025 (UTC)

Combined Sites, Safety & No-landing Zones

What about locations that can be used both as a launch and as a toplanding area? Should two separate nodes / areas be created? Or should there be one tag for both?

Maybe the tagging schema should be adapted: 

- free_flying:takeoff=yes/no/permissive
- free_flying:landing=yes/no/permissive
- free_flying:ground_handling=yes/no/permissive

(Or maybe namespaced below `free_flying:site:`)

This way, multiple site types can be mapped on a single object. --DaniloB (talk) 14:59, 3 October 2021 (UTC)

I like the proposed tagging scheme, since it would also add the ability to mark up no-landing zones (see next section). However, this would require a migration of existing usage. How would such a migration work? Could it be automated? Gwicke (talk) 18:00, 2 December 2023 (UTC)
Also, is anyone aware of existing map consumers that depend on the current site markup scheme? I suspect most might only look for sport=free_flying, but could be wrong.
More generally, what is the process for agreeing on tag changes like this? Just "be bold", update the documentation & migrate existing usage with a bot or similar? -- Gwicke (talk) 18:00, 28 March 2024 (UTC)
For automatic migrations, https://github.com/matkoniecz/osm_bot_abstraction_layer has a library, and an example migration script. So I think that part is doable.
However, there are around 3.5k uses of free_flying:site, mostly in Europe. There might be automatic sync pipelines creating sites in Scandinavia based on flight data. These would need to be updated if the site tagging scheme changed. The bot library README suggests discussing tag changes on the OSM forum. -- Gwicke (talk) 20:17, 28 March 2024 (UTC)
See my comment in the thread right below. I think we should go with DaniloB's proposal, and I am willing to look into automating the migration. -- Gwicke (talk) 01:45, 9 March 2025 (UTC)
I'm not sure I see why this is better than just using semi-colons to separate different options within the site tag. It is generally agreed upon as a way to do it in OSM and it saves us from the trouble of having to change all the existing mapping and I think it makes it somewhat easier to digest the data. I think it also makes it easier to map. The more tags you have to remember and think about and give value to, the more complicated it is for manual mapping. Hardcover2452 (talk) 10:11, 9 March 2025 (UTC)
How would you map a location as "not allowed to ground handle" with semi-colons based tagging? I would find `free_flying:landing=permissive` and `free_flying:ground_handling=no` quite clear. Or sites where launch is allowed, but toplanding is not allowed? That would be `free_flying:takeoff=yes` and `free_flying:landing=no`. (Edit: Ah, I see that this was already discussed below and resulted in a proposal.) --DaniloB (talk) 21:23, 12 March 2025 (UTC)

No-landing sites / zones & safety tag

Hi, many paragliding / free flight communities maintain maps both of landing zones (primary & bail-out), but also of no-landing zones. No-landing zones are usually about hostile land owners, issues with animals, or dangerous areas. An example of such a map for the Bellingham area is here.

What are people's thoughts on supporting some form of no-landing zone markup in OSM? As a strawman, perhaps free_flying:site=no-landing? Gwicke (talk) 17:57, 2 December 2023 (UTC)

Sounds like a good idea, I would also like to also add a no takeoff zone (free_flying:site=no-takeoff?) as I have come across some areas that look like a good takeoff but past incidents showed that they are too dangerous. --Hardcover2452 (talk) 19:14, 8 December 2023 (UTC)
Circling back to this, I am leaning towards going with the preceding proposal by DaniloB along the lines of free_flying:landing=yes/no/permissive/dangerous. This seems more future proof to me, and there is already similar precedent for ground handling. This also seems to be more in line with how the access tag is used, for example.
Hardcover2452, I know the "dangerous" value was added to the ""free_flying:site"" value docs in the meantime, but it seems that would also benefit from being clear about *what* is dangerous in that place (landing / launching / ground handling?). I am willing to look into migrating existing usages with a bot.
Thoughts / concerns anyone? If there are no objections in the next week or two, I will go ahead & update the docs / start working on migrating existing usage with a bot. -- Gwicke (talk) 01:43, 9 March 2025 (UTC)
I think that splitting the safety issue into landing and take-off and other types of sites just makes it more complicated. Generally in our sport, if a site is unsafe to take-off in or land in, it's going to be unsafe to the other as well. So there isn't really a point in making that a different tag.
As far as ground handling I don't think there's any point to address whether it's safe or not because generally speaking it's just about the skill and the weather condition of the user. So there isn't really anything that you can say about whether a site is dangerous or not for ground handling.
I also think that keeping the safety rating a bit more generic and not specifying whether it's dangerous for landing or take-off is better because, as I said, generally speaking, if one is dangerous, the other is also dangerous. We don't want a situation where something is marked as dangerous for landing and then someone decides to take off from it, but it's also dangerous for takeoff.
As for changing things with a bot, I think that will be great but maybe in the future as I do plan on making a few more changes and making this wiki make more sense and be more future proof before doing any widespread changes. Hardcover2452 (talk) 10:01, 9 March 2025 (UTC)
Hardcover2452, re complexity, I think both separate tags and multi-valued tags have their pros and cons. Multiple values and Semi-colon value separator describe some of the trade-offs pretty well. In more concrete terms, one hope I have is for flight instruments / apps like XCtrack to eventually display LZs (and takeoffs, no-lzs etc) marked up in OSM. In the case of XCTrack, that would require openandromaps to include the "free_flying:site" tag, which is not yet the case. Looking at their tag mapping XML, I see hacks like "value='put_in;egress'" for whitewater sites, which to me suggests that multi-values using semicolons are not that easily supported. Tags / sites with multiple values would likely just be missing from the exported map. Other consumers will have similar limitations, especially outside of very specific / popular top level tags.
That said, I broadly agree with your point about keeping things simple & minimizing change. Lets maybe brainstorm some concrete examples & how they would work out in practice below. -- Gwicke (talk) 18:03, 9 March 2025 (UTC)

Given the way I use these tags, I agree having a way to mark bailout landing sites (we tend to call them “emergency landing [zone]s” where I live) would be useful. I don’t think it is necessary to move to multiple tags for that. Regardless of whether the solution to this problem ends up being multiple tags or a new subtag, I am interested to use it. Perhaps the unsafe subtag is already sufficient for that purpose and it’s just a matter of making the documentation clearer.

I see how moving to multiple tags would be helpful to tag forbidden area. However I am not sure tagging such areas is practical or useful. I know burnair has something like that (e.g. https://www.burnair.cloud/?layer=lz&id=76#15/46.334235100762/8.016891794064 or https://www.burnair.cloud/?layer=lz&id=497#15/46.906205269684/8.3978719518366) but that always seems a little weird to me. Where do we stop? I think it generally makes more sense to mark places that are known to be good for taking off / landing than to mark the ones that are not. In my experience, the reason for forbidden landing is usually related to the attitude of the owner (which I am not sure is something really mappable on OSM, same as controlled airspace) or the presence of animals or actively cultivated fields (which is often temporary and subject to change but easy to assess in real time).

The way we manage sites in my area I don’t think we would use “forbidden area”.

FWIW this is how we do it at the moment: https://umap.openstreetmap.fr/en/map/vol-libre-jura_980516#11/47.3111/7.3293

On the other hand, an argument for not splitting into multiple tags is that it will cause more work/churn both for OSM contributors (or did you plan to mass edit the world to comply with the new way to tag these sites?) and consumers who already rely on the current tagging scheme.

So overall I think it’s -1 for me for multiple tags (at least on the basis discussed above) and +1 for having a standardised way to tag emergency landings.

--User:Krunch 12:58, 14 March 2025 (Europe/Zurich)

I think that the move to multiple tags over multiple values is beneficial, sure it comes with a cost but it helps align better with common practices in OSM, it also means that external systems that digest this data are less likely to fail (since multiple values tend to be less supported) It is true that editing existing spots would be a lot of work, but all of our changes should be backwards compitable, meaning that even if we don't modify them they should still be accuratly explained in the wiki.
We already discussed the possible overlap of the safety tag with the more general suitability tags (ie "free_flying:landing=*) and I do think that the distinction is important. An example that was give was that there could be an emergency field that is completely safe but the owners do not allow regular use of. In a situation like this it shouldn't be marked as unsafe but it should still be clear that it should be avoided because of non-safety issues.
As for mapping ares to avoid. I think this is critical, I myself saw a case where there was an old ridge soaring site that was used for year, but one day the clif broke in a way that now causes that entire site to be filled with rotors. The issue is that some people didn't notice the change and went there anyway. Over the years you still have people asking about the site because it still looks like a very viable area. Having this site be marked as dangerous with a small description or something could actually save lifes and if not that, at least improve everyones knowledge. So this would be the use case, we are not talking about marking every little spot, but just having a way to warn others of places that are already causing issues.
--Hardcover2452 (talk) 15:47, 14 March 2025 (UTC)
I think the way to address the safety concern you describe is best done by: (a) putting up a physical sign on location (b) advertising the problem in the publications of the local club/federation (c) monitoring the area on OSM to remove attempts to (re-)add the takeoff site. If you get in the habit of adding negative areas on OSM it's hard to figure out when to stop, it gives a potential false sense of security ("this area is not marked as dangerous, so it should be safe" vs "this area is not marked as safe, so I should figure out why that is") and you open yourself to all kind of liability issues. Are there precedents for this kind of things on OSM in other domain area?
--User:Krunch 18:00, 14 March 2025 (Europe/Zurich)
I understand what you are saying, I just don't think that it can always apply, I'll explain. In my country there are no official sites, there are a few that are somewhat recognized by the local authorities but even then, the local authorities don't really care about the sport and mostly just allow it to happen. This means that in most sites you are not legally allowed to put up a sign, nor is there a club that manages the site or really any site (also, there aren't any clubs really) So while options A and B are ideal, they just don't apply in this situation. As for option C, it would require a much more significant amount of effort to monitor OSM rather then map once.
I think that the false sense of security argument can be made about really any mapping we are doing, even mapping good sites can be argued as a possible false sense of security, especially if they are not maintained (for example a site that was mapped years ago but is no longer safe)
I agree that it can be a bit of a slippery slope to map unsafe areas, but I also think that a scenario where this becomes an issue is very unlikely and also easily delt with. So I would rather try this option out rather then avoid it on a slippery slope fallacy.
As for liability, I don't see how that can be an issue? how is it different then marking "safe" sites, if anything marking a site as safe is much more problematic as you are assuring the reader that they are safe. But in anycase nothing we map on OSM opens us up to any liability, we are not telling pilots what to do, just offering collective information. --Hardcover2452 (talk) 00:20, 15 March 2025 (UTC)
Krunch, at least in the area I live and fly most (NW USA / BC Canada), it is common practice for clubs to maintain no-LZ and bailout ("emergency") LZ information for XC pilots. Currently, this is done through a combination of ad-hoc google earth projects (e.g. this one for the area around Bellingham, and in some cases site guides, or videos walking through a google earth project. These only contain noteworthy sites that are relevant to XC pilots - the "where do we stop" has not been an issue in practice. For example, these include sites that look like great LZs, but the owner asked very explicitly for no paraglider to land there again. Ignoring such rules creates trouble both for the offending pilot, but also for the local community, and can endanger access elsewhere. Temporary restrictions (like the presence of animals or crop) are not usually reflected, unless there are very specific local issues beyond what is obvious to most pilots.
I would like to move away from site-specific maps and videos, and instead integrate this information in OSM. Among other benefits, this can allow instruments or apps like XCTrack to display LZ information in flight, so that XC pilots can take into account local guidance even when they are looking for an LZ in an area they are less familiar with, far away from their takeoff. -- Gwicke (talk) 17:20, 14 March 2025 (UTC)

Change proposal by Gwicke and Hardcover2452 March 11th, 2025

Early Discussion

Site markup use cases / examples: please feel free to edit inline / add to this!

  • No landing: Often looks like a great place to land, but strictly disallowed by owners, animal issues, or other rules. Frequency: Common, numerous local examples.
    • Multiple Values: free_flying:site=landing_prohibited (enables value autocomplete for landing*) or free_flying:site=no_landing
    • Multiple Keys: free_flying:landing=no
  • Bailout LZ: Not recommended for regular use for safety and/or access political reasons, but viable when necessary. Frequency: Common, numerous local examples.
    • Multiple Values: free_flying:site=landing_bailout or free_flying:site=landing_discouraged?
    • Multiple Keys: free_flying:landing=bailout or free_flying:landing=discouraged?
  • Mixed, e.g. safe LZ, but dangerous launch: Example would be a meadow above a slope that has obstructions or unusual turbulence in the typical post-launch flight path. Frequency: Likely less common, but I imagine the example to be quite realistic with "alm" mountain meadows in the alps. No concrete site example.
    • Multiple Values: free_flying:site=landing;takeoff_dangerous?
    • Multiple Keys: free_flying:landing=yes and free_flying:takeoff=dangerous?

-- Gwicke

Firstly, awesome work. I really appreciate all the research you put into it.

Secondly, now that I see what you're talking about and I understand the issues with multi-value keys, I think you're right, going for the approach of multiple tags instead of multiple values is probably preferable, especially if it could in the future help support platforms that could be useful. We might want to consider standardizing an approach for values that separate legality from practicality. For example, if we're talking about a landing site, it is very useful to know whether it is dangerous or very hard to land in, or is it illegal or against the owner's wishes. Maybe we can have each tag only talk about the legality of it, so free_flying:landing=yes would indicate that you are legally allowed to land, "no" would mean that you are not legally allowed to, and "permissive" would be the grey area (maybe legal but the owner might still be mad, maybe legally ambiguous, etc) and we can also have a free_flying:safe tag that might have values such as "yes" "no" and "risky" where yes would be the assumed default, no would indicate that this site should not be used and risky would mean that you should be careful and avoid if possible. As for multiple values, I think you ate right with the hierarchy. So free_flying:site:landing=yes/no/permissive and the same for other types of sites. Same thing for safety, so you could just map free_flying:safe=no to indicate that this site is completely unsafe, but you could also map just free_flying:safe:takeoff=no to indicate that only takeoff is unsafe and other options ate assumed safe.

As for fields that must have multiple values, such as direction, I'm not sure what would be the best approach. Using MV seems to be used a lot for the direction tag but it is not officially standardized, but from what you showed me I would argue that it might be better to use a numeric scheme where the direction would be mapped as direction=* is a single value and any further values should be direction:1=* direction:2=* etc. So I think we should go with the numerical approach.

Please let me know if you think this is a good idea and if you do I will go to the wiki, update it and then we can further discuss if there are any changes that need to be done or anything that needs to be further detailed. Hardcover2452 (talk) 02:40, 10 March 2025 (UTC)

Hardcover2452, if we want downstream systems like XCTrack to consume and display this data, then I think keeping things simple is important. For an initial decision on whether to consider a site for say a landing, a simpler scale like "yes / no / discouraged" might be a better starting point than resolving things really fine grained by legality vs. safety vs. community expectations / rules (which are often not legally binding) etc. Such a scale can be more easily mapped to say a green / orange / red color scheme for display, with limited logic. Greater detail can still be provided in other tags, like the description, access tags, or perhaps more specialized free_flying:* sub-tags like the safety tag you proposed, but it will take a while to add that information to many sites, and likely even longer for consumers like XCTrack to use it. And there is a lot of devil in those details. In many cases, I suspect a description might be more useful than trying to fit that subtlety into tags. This question reminds me a lot of the discussion around access tags, in which Minh Nguyen made the point about summary vs. detail, and practical applications in routing in particular.
Re namespacing (free_flying:site:* vs. free_flying:*): Looking at what is currently at the free_flying: level, I am leaning slightly more towards making the site keys top level. From the perspective of someone not familiar with the current scheme (new user), I have a hard time justifying why say takeoff should be a "site" sub-property, but many of the other properties should not be. They all seem to describe a site in various ways, and for example the existing top level "ground_handling" and "ridge" seem semantically very close to "takeoff" - basically describing what you can do at this site. Shorter keys are slightly faster to read and type, too. If we wanted more namespacing for autocomplete, then it seems some of the other keys should perhaps be namespaced too (e.g. paragliding / hanggliding / rigid / tandem).
I would also tend towards a shorter tagging scheme. Concepts might start to overlap (e.g. site-related tags and safety-related tags), and in that case flat is simpler. --DaniloB (talk) 21:26, 12 March 2025 (UTC)
Direction fields are definitely tricky. IMHO, they are perhaps a more legitimate and established use for multiple values. Consumers will need special logic for directions anyway, and the move to the generic direction field can actually be a boon here, by potentially enabling reuse. I would also expect support for this to happen later in most consumers.
Re drafting, maybe we can work out one complete proposal here on the talk page first, so others have an opportunity to weigh in as well? Happy to do a first pass later today. -- Gwicke (talk) 16:43, 10 March 2025 (UTC)

Summary of proposed changes

  • Separate tags for site types / usages: free_flying:site=takeoff|landing|... -> free_flying:takeoff=yes|no|discouraged, free_flying:landing=yes|no|discouraged, ...
  • Add free_flying:speedflying, to complement the existing craft types paragliding, hanggliding etc. Previously discussed in Talk:Tag:sport=free_flying#free_flying:speedflying=yes/no
  • Add top-level free_flying:unsafe tag for specifically calling out safety issues. This existed as "unsafe" site type before, but is now much expanded.


Updated draft tag description

Related amenities
Tag Description
sport=free_flying This is the main tag for a free flying site. Multiple sports are supported separated by semicolons, but many consumers (apps etc) only handle one sport value at a time.
free_flying:takeoff=* A takeoff / launch site.
  • yes - Launching is legal & the site is well suited
  • no - Launching is not allowed or the site is not suited or unsafe.
  • discouraged - Launching might be possible, but there are issues around access, suitability or safety. Usually, more detail is provided in the description tag, and/or a linked website.
free_flying:landing=* A landing site, including top landing spots.
  • yes - Landing is legal & the site is well suited
  • no - Landing is illegal, or the site is unsuitable or unsafe.
  • discouraged - Landing might be possible, but there are issues around access, suitability or safety. Typical value for marking up "bailout" landing zones. Usually, more detail is provided in the description tag, and/or a linked website.
free_flying:towing=* A site meant for free flying towing (usually it is also the landing spot and can be marked as a landing as well).
  • yes - Towing is well supported and legal.
  • no - Towing is illegal or the site is unsuitable or unsafe.
  • discouraged - Towing is possible, but there are issues around access, suitability or safety. Usually, more detail is provided in the description tag, and/or a linked website.
free_flying:ridge=* Whether this place can have suitable conditions for ridge soaring. Please also mark takeoff / landing abilities. Most ridge soaring sites support top landing.
  • yes - This site has ridge soaring conditions often or is otherwise used mostly for ridge soaring.
  • no - This site rarely has ridge soaring conditions.
  • potential - This site has ridge soaring conditions sometimes but is mostly used in other ways.
free_flying:ground_handling=* Use this tag to describe if the site is suitable for ground handling, and possibly short training hops.
  • yes - Ground handling is allowed, and the site is suitable.
  • no - Ground handling is forbidden, or the site is not suitable.
  • permissive - Ground handling is possible, but might be restricted to certain times or only with special permission.
free_flying:training=* A site that is suitable for training but not flying (large grass fields with no obstacles, small hills to jump from, etc). Usually also suitable for ground handling (see above).
  • yes - Training is allowed, and the site is suitable.
  • no - Training is forbidden, or the site is not suitable or dangerous.
  • permissive - Training is possible, but might be restricted to certain times or only with special permission.
free_flying:packing=* A dedicated area to fold or prepare paragliders and/or hang-gliders, usually aside a landing or take off.
  • yes - Packing allowed / encouraged.
  • no - Packing disallowed / discouraged.
free_flying:paragliding=* Is this site legal and suitable for paragliders?
  • yes - Site is legal and suitable for paragliders.
  • no - Site is illegal or not suitable for paragliders.
  • discouraged - Site might be usable for paragliders, but there are issues. Usually, more detail is provided in the description tag, and/or a linked website.
free_flying:hanggliding=* Is this site legal and suitable for hanggliders?
  • yes - Site is legal and suitable for hanggliders.
  • no - Site is illegal or not suitable for hanggliders.
  • discouraged - Site might be usable for hanggliders, but there are issues. Usually, more detail is provided in the description tag, and/or a linked website.
free_flying:rigid=* Is this site legal and suitable for rigid hanggliders?
  • yes - Site is legal and suitable for rigid hanggliders.
  • no - Site is illegal or not suitable for rigid hanggliders.
  • discouraged - Site might be usable for rigid hanggliders, but there are issues. Usually, more detail is provided in the description tag, and/or a linked website.
free_flying:speedflying=* Is this site legal and suitable for speedflying?
  • yes - Speedflying is allowed, and the site is suitable.
  • no - Speedflying is not allowed, or the site is not suitable.
  • discouraged - Speedflying might be possible, but there are issues. Usually, more detail is provided in the description tag, and/or a linked website.
free_flying:official=* Use this tag to describe if the site is official (meaning legal and maintained)
  • yes - This site legally allows pilots to use it and is maintained.
  • no - This site is either not maintained or not specifically legally approved (might still be legal depending on local laws)
free_flying:unsafe=* Whether this place is unsafe. Can be used to mark spots that can seem enticing or were used in the past and are now known to be unsafe or spots that are unsafe for specific activites (see sub-tags)
  • yes - This spot is unsafe and should be avoided.
  • no - This spot is not known to be unsafe.
  • discouraged - This spot is known to have issues that can affect safety in a significant way or is known to have higher crash rates. If possible it should be avoided.

This tag can be further specified by adding sub-tags. For example free_flying:unsafe:landing=yes would indicate that only landing is unsafe here, sub-tags would have priority over the main tag.

direction=* Use this tag to specify in which wind directions this site is usable.

Use "-" to specify a clock-wise range of wind directions. Use ";" to specify multiple values (see Multiple values)

Here are some examples but read the direction page for more details on how to use this tag.

  • N NE E SE S SW W NW
  • 0 45 90 135 180 225 270 315
  • N-E S-NW
  • 22-112;SSW-WNW
direction:ideal=* Same usage as direction but to further specify only the ideal wind direction for this site.

For example a site might be usable in the range N-S in which case it would have direction=N-S but in eastern winds the site gives the best results and so it would also have direction:ideal=E

surface=* Use this tag to specify the surface conditions of the site, specifically the are that the wing and the pilot will be touching or standing on. This can be useful for pilots to understand the expected wear in the wing and possible issues. This is especially important for free_flying:ground_handling where the wing might be on the ground for a significant duration.
frequency=* What radio frequency do the local pilots use to communicate. Multiple values can be added with a ";" seperator. Please see the frequency page for more info.
wind_speed=* The range of wind speeds that this site is usable at. This normally hold two numeric values with a dash and a unit suffix (e.g., "mph", "knots", "ms")—except for kmh, which uses no suffix. Include a space between the number and the unit (e.g., "wind_speed=5-10 mph" rather than "wind_speed=5-10mph"). For 5-10 kmh it should simply be "wind_speed=5-10". This tag can be further specified for which type of flying it relates to be adding ":" for example "wind_speed:paragliding=0-20"
wind_speed:ideal=* Same as the "wind_speed" tag, but to specify ideal conditions. For example a site might be flyable at all winds between 0 to 25 kmh but only at 10-15 kmh it gets ideal conditions.
opening_hours=* This tag specifies at which times this site is usable and accessible, this is in regard to legal usability or accessibility. This tag is not meant to specify at which times this site is fly-able.
free_flying:guest-guidelines=* Whether guests (pilots who don't fly this site often and are not member of the local club) have to take notice of a guest guide. In combination to this website=* might be useful.
free_flying:school=yes A free flying school (paragliding/hanggliding/...)
free_flying:repair=yes A free flying repair shop (paragliding/hanggliding/...)
free_flying:shop=yes A free flying resseller shop. (You can buy paragliders, equipment, harnest, ...)
free_flying:club=yes A free flying club (paragliding/hanggliding/...)
free_flying:tandem=yes A place where you can pay to have a tandem flight with professional pilots
Deprecated tags
Tag Description
free_flying:site=* DEPRECATED

Use this tag to describe the type of site. Currently used values are: takeoff - A takeoff site

landing - A landing field (includes top-landing sites)

towing - A site meant for free flying towing (usually it is also the landing spot)

training - A site that is suitable for training but not flying (large grass fields with no obstacles, small hills to jump from, etc)

packing - A dedicated area to fold or prepare paragliders and/or hang-gliders, aside a landing or take off.

unsafe - A site that is generally agreed to be unsafe (history of crashes or unpredictable conditions) it should be avoided even if it looks usable.

free_flying:site_orientation=* DEPRECATED USE direction

Take off orientation (N / NE / E / SE / S / SW / W / NW) If multiple orientations are possible, separate them with a semicolon (;)

free_flying:no-flight-time=* DEPRECATED USE opening_hours

A time in which the take off, the landing or the towing-place is not allowed to use. Use no if the place might be used the whole year, eg.: free_flying:no-flight-time=01.04-30.06 free_flying:no-flight-time=no

Proposal discussion

Some notes / questions:

Some possible values other than yes/no


Not sure I would decide to put "suggestive" tags like "possible", "discouraged"... Seems heavily dependent on your flying skills more than facts --Nemesuisse (talk) 17:52, 12 March 2025 (UTC)

Nemesuisse I agree that something like "discouraged" is a bit subtle, and ultimately pilots need to make their own decisions. One case where I do hope to use it is for "bailout" landing zones. Those are frequently difficult or more dangerous to land (which can to some degree be compensated for by skill), but in some cases property owners are also only okay with occasional use. High volume use could shut down access entirely in those cases. Detail on these finer points can be provided in the description, linked website, or perhaps access tags. Hopefully, at least some pilots will take that extra information into account. However, for a quick lookup in say an app like xctrack, "yes"-"discouraged"-"no" could be displayed as green-orange-red, so that a pilot could quickly prefer a "green" landing over an "orange" one even if they do not have the time to look into details. -- Gwicke (talk) 20:25, 12 March 2025 (UTC)
Nemesuisse I agree with Gwicke. I think that the whole idea is to have this grey-area value that would leave it up to the reader to take more care about their decisions. And local mappers will be able to decide not to use it if it does not apply. I think it is also worth mentioning that in countries where this sport is not very developed and lacks official sites, you can end up with plenty of sites that are in this grey-area of suitability. --Hardcover2452 (talk) 00:26, 13 March 2025 (UTC)
As a thought experiment, I do wonder a bit if moving from "yes|discouraged|no" even more towards a "quality" scale could help capture overall site fitness a bit better, with clearer connotations. As a strawman example: free_flying:takeoff=good|acceptable|problematic|no. With "yes" mapping to "good" by default. This would still be fairly easy to map to a green-yellow-orange-red color scale for display purposes. I am not necessarily convinced this is better than the current proposal, but I think it is interesting to explore the what-if. Thoughts? -- Gwicke (talk) 06:02, 13 March 2025 (UTC)
Gwicke, I think that 3 levels is ideal as anything more just adds too much ambiguity. As for the symantics, I think that while "yes" "discouraged" and "no" might not be as good as "good" "problematic" and "no" keeping in line with other conventions is more important as the former still provide the information in a clear enough way. --Hardcover2452 (talk) 00:47, 14 March 2025 (UTC)

training vs ground_handling

  • Deprecate training & expand "ground_handling" to include small training hops?
    • Current uses of free_flying:site=training frequently reference ground handling, but there are also quite a few dedicated "training hills", especially in France and Germany. "training" usually implies "ground handling", but the reverse is not always true in the sense of more significant flights. So keep both for now?

"training hills" would be usefull in France and other countries that allow "self-training" before being qualified pilot. --Nemesuisse (talk) 17:52, 12 March 2025 (UTC)

I would also keep both. A training hill needs a slope while a groundhandling site could be completely flat if the wind is often suitable. --DaniloB (talk) 21:45, 12 March 2025 (UTC)

  • (Default) This site never has ridge soaring conditions.
    • Would it make sense to drop the "default" here? Most sites that do not say anything about ridge soaring will still be ridge soarable sometimes.
      • Resolved, we dropped the default values. -- Gwicke (talk) 20:27, 12 March 2025 (UTC)

free_flying:guest-guidelines=

Difficulty Rating

One aspect that is not yet covered here is the difficulty. There could be sites that could be used as launch location, but only for experienced pilots. While other sites can be used by beginners without any problems. (Note: This is not necessarily about safety, but mostly about required skills.) Are there already tagging schemas for this? --DaniloB (talk) 21:53, 12 March 2025 (UTC)

DaniloB I will say that in my country this sport does not have a locally adopted rating, so I can't really add any useful opinions here. I know that Gwicke<nowiki> also suggested it, so maybe it is worth it for you two to brainstorm something. The only issue that I can see with mapping the rating is that it should probably be clear that only an official rating should be mapped, as to not leave it open for anyone to guess at the rating that they think the site is. Again, I'm not sure how it works so maybe I'm off, but I would guess that it would be closely related to the "free_flying:official" tag as if the site is not official it probably won't have an official rating. So you might consider making it a sub-tag of "free_flying:official" --Hardcover2452 (talk) 00:40, 13 March 2025 (UTC)
One option I can think of would be to mark advanced launches that average pilots should perhaps not consider as "discouraged", and add details on special skills required or risks in the description and/or linked website. In my area, the launches requiring the highest skills tend to be unofficial, and do not have a rating. The vast majority of official sites are also fairly beginner friendly, mostly P2 level (novice pilot) and P3 (intermediate / IPPI 3-4). Conditional rules like "P2 with supervision, or P3+ solo" are also pretty common.
I think it might help to identify an actual consumer / use case for structured rating information before introducing special tags for it. How such a consumer uses the information will likely inform how the information needs to be structured to be useful. Until then, lets maybe continue to add it in the description, and get current consumers to actually expose at least that? -- Gwicke (talk) 03:46, 13 March 2025 (UTC)
Looking around, paraglidingmap.com has a "difficulty field", with values "easy", "medium", and presumably "hard". paragliding365.com has similar difficulty levels, separate for takeoff & landing. Depends quite a bit on conditions of course, so not sure how useful such a simple rating really is. They explicitly avoid getting into ratings, which makes the problem simpler. Instead, paraglidingmap has a free-form "rules" field, although that seems to be used very similar to "notes", the equivalent of "description". Gives the detail view a bit more structure. -- Gwicke (talk) 04:20, 13 March 2025 (UTC)
I am personally against adding any sort of rating to the mix, I think it can be controversial and not that useful. --Hardcover2452 (talk) 00:47, 14 March 2025 (UTC)
Shouldn't the "difficulty" topic be a separate discussion? In any case, I think that if we do add a difficulty tag, it needs to also explicitly mention where that rating comes from. There are many different "standards" for that. I don't think OSM is the right place to add a new one or unify them all. But we can provide a source. Perhaps something like "difficulty:paraglidingmap.com:medium", "difficulty:burnair:einfach",... --User:Krunch 13:09, 14 March 2025 (Europe/Zurich)
Thinking about this some more, I don't think we can generally copy content from other providers without their consent. Meaning my proposal above is probably not OK (i.e. we can't just import difficulty ratings from other websites). If there are some difficulty scales that are somewhat objective and better documented than "this website says so" (maybe something similar to Key:sac_scale) or Key:mtb:scale), I am interested to hear about them. -- User:Krunch on 2025-03-14 18:11 Europe/Zurich

"official" and "club"

In the suggestion, there is both "free_flying:official=yes|no" and "free_flying:club=yes". However, how would one tag the name of the club that maintains an official site? The "free_flying:club" tag seems to be geared more towards a "club house" or a location where one can book tandem flights. Maybe something like "free_flying:official:club=*" or "free_flying:managing_club=*" should be added? --DaniloB (talk) 21:53, 12 March 2025 (UTC)

DaniloB<nowiki> From looking at some mapped sites that use the "free_flying:club" tag I think they are using a combo of "operator" and "website" to indicate the club. but I don't have much experience with clubs so maybe I'm missing something. --Hardcover2452 (talk) 00:40, 13 March 2025 (UTC)
+1 to the operator / website combo. Both are already called out as a useful combo in the tag description sidebar, and a section at the top. Should we make these more prominent, perhaps by integrating them into the table below?
Another general key that could perhaps be useful to mention is "frequency" for the site radio frequency. -- Gwicke (talk) 03:46, 13 March 2025 (UTC)
Adding it to table sounds like a good idea, but if we are reaching the point of the table being quite large, maybe we can split it further. We can have an initial table of "core" tags, this would be tags that are essential or very important, then a second table with "extra" information. As for frequency, I think that is a good idea. Gwicke let me know if you think this is a good idea, if so I will split the table and add the frequency tag. --Hardcover2452 (talk) 00:47, 14 March 2025 (UTC)

General discussion

Gwicke I updated the table, I think it looks really good, awesome work. I think going with "discouraged" over "maybe" makes more sense, it is more widely used and while it might be a bit strong, I do think it applies well to the place I put it in. From the list of possible values past "yes" or "no" I think that only the "discouraged" and "permissive" ones make sense, I did also use "potential" on the ridge soaring key as for that one specifically I think it fits the best.

I see the use case of having both ground handling and training keys, while it is probably not a common situation, I do think this distinction makes sense to keep.

about "free_flying:guest-guidelines" I have no idea, I never used it or have been in a situation where it would make sense. but someone added it and it doesn't really hurt to keep it. I think we should leave it as it is.

What do you think? --Hardcover2452 (talk) 03:03, 11 March 2025 (UTC)

Thanks Hardcover2452, agreed with most your points and changes. Using "discouraged" works for me, and should be a good fit for bailouts, and also the glider type keys.
I am wondering if the "unsafe" tag is as important now that each key has a "discouraged" option too. If a site is especially unsafe to launch for example, I would lean towards tagging it as "free_flying:takeoff=discouraged", and then saying something about the dangers in the description and (if available) linked site guide. If taking off is basically never safe, then "free_flying:takeoff=no" makes sense too, in my view. Somewhat related, while thinking about alternatives to "maybe" and "discouraged", I was wondering whether representing site rating / difficulty could make sense. CIVL IPPI levels for example could be used. Locally in the US, sites have minimum pilot ratings, which reflect a site's challenges / dangers / required skills. Most are very accessible (P2 or P3, equivalent to IPPI 2 to 4), but some difficult ones are also rated P4 (IPPI 5). -- Gwicke (talk) 03:36, 11 March 2025 (UTC)
Gwicke about the unsafe tag, I personally think that it is very important. I have some sites that I will use it on as I think it serves a few goals:
  • To mark spots that changed (cliff fell) and are now known to be actually dangerous, but they look nice and they have a history so some pilots still go there. Marking them as not just "unsuitable" but actually unsafe, helps alert the pilots to reconsider, it also helps future pilots to avoid these spots (somthing that a lighter "unsuitable" ie "no" can be more easily dismissed)
  • I plan to help implement a more obvious distinction in OSMAnd for spots that are marked as unsafe, helping pilots quickly recognize places to avoid. This can apply to any system that might decide to look for this "free_flying:unsafe" tag for quick and easy filtering and warning
  • There is also the issue that a spot might look great for landing or takeoff or anything else, but there might be hidden dangers. Using unsafe explicitly states that this isn't a legal issue, or a practicality issue, it is a matter of your personal safety. I know quite a few pilots that would easily ignore "unsuitable" but would reconsider "unsafe"
It is my opinion that a clear distinction around safety issues is crititcal.
As for site rating / difficulty, they vary between countries and communities. In my community there was an attempt in the past to classify difficulty for sites and it ended up being a very controversial issue. I recommend avoiding any sort of rating and instead leave that up to the description if someone wants to specify their own/local rating. --Hardcover2452 (talk) 04:01, 11 March 2025 (UTC)
Re safety vs. "no", are you expecting that some users would prefer to basically ignore a hard "no" tag by default, and instead focus on a safety tag instead, where it exists? Would those users be more or less likely to read descriptions / site guides? -- Gwicke (talk) 04:38, 11 March 2025 (UTC)
On the default values ("assumed"), would you be okay with dropping those? If a tag is not set, then I think "no information" is safer to assume than a specific value. In some cases, assumptions would also imply the wrong thing. For example, many takeoffs can be top landed, even if that is not explicitly called out. As long as landing is not explicitly discouraged or disallowed ("no"), pilots should be free to use their own judgement. Similar for ground handling etc. -- Gwicke (talk) 05:38, 11 March 2025 (UTC)
I see the changes you made about the safety issue, while I still think that making a clear seperation for safety issues is important, I respect your opinion. I removed the "assumed" comment, I think you are right about leaving it to the reader to assume in case of a lack of information.
I think keeping the unsafe tag is important.
What do you think of the current table then? Gwicke
--Hardcover2452 (talk) 11:52, 11 March 2025 (UTC)
Hardcover2452, the current table looks good to me. Thank you for fleshing this out with me! For next steps, lets perhaps give others a bit more time to weigh in - perhaps a week or so? Is there another place we should announce this? I can look into migration tooling in the meantime. /cc DaniloB, Kjon, Geozeisig Mateusz Konieczny, Futur3r, Pyrog, Thuringian, SergienkoMike, Adamant1 -- Gwicke (talk) 16:00, 11 March 2025 (UTC)
Awesome! I'm very happy I got to have some brainstorming with you! As for others, sure, let's say that if we don't get any new input by the 18th we will just go a head and put the new table into place (I'm not aware of any other space to announce this)
About mass migration, I don't have the experience or knowledge to do that so I will leave that up to you. I will manually migrate some places that I mapped. I highly suggest that all deprecated tags be left as-is as to not mess with unknown systems that might use them and if we do that all of our modifications should be 100% backwards compatible (I think)
Regarding mass migration, I don't have practical experience with it, but please check https://wiki.openstreetmap.org/wiki/Automated_edits and https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct first. --DaniloB (talk) 22:01, 12 March 2025 (UTC)
DaniloB yup I saw those & looked at some previous mass edit requests & the associated bots. I do not have practical experience with mass editing / bots either, but am happy to look into it. The main potentially breaking change is the free_flying:site migration. On the editor side, I am mainly aware of OSMAnd and Vespucci which both have templates for new site creation that need updating. I briefly looked at the code in OSMAnd so far, and updating that seems fairly doable. Either way, if editors are not updated right away, then the main consequence would be that older tags would be created for a bit longer. This can however be fixed up by re-running the bot later.
On the consumer side, I believe most are still looking at sport=free_flying only. Is anyone aware of a map consumer that currently uses free_flying:site information? -- Gwicke (talk) 03:13, 13 March 2025 (UTC)
Gwicke great work :) --Hardcover2452 (talk) 16:50, 11 March 2025 (UTC)
Sounds good, Hardcover2452! I changed the heading above the edited table & added a short change summary, and also reached out to a few frequent editors of free_flying:* sites. -- Gwicke (talk) 21:19, 11 March 2025 (UTC)
Great work from contributors here ;) --Nemesuisse (talk) 17:52, 12 March 2025 (UTC)

Great work, thanks Gwicke and Hardcover2452 for picking this up and coming up with this proposal (which is much better than the previous state)! --DaniloB (talk) 21:53, 12 March 2025 (UTC)

User:Gwicke explicitly asked me for feedback (presumably because I have been editing these tags a fair bit). I sent it privately but I figured it also belongs here. I struggle a bit with these Talk pages so I apologise if my points are redundants. You are welcome to reformat what I wrote here if you think I am doing it wrong. I also think splitting this proposal into multiple ones might make it easier to contribute meaningfully to this/these discussions.--User:Krunch 12:58, 14 March 2025 (Europe/Zurich)

Thank you for the input, I agree that it has been hard to follow, so I made some changes in hopes that it will be a bit more readable now.
I hope you don't mind, I split your original input and responded separately --Hardcover2452 (talk) 15:47, 14 March 2025 (UTC)

Gwicke, DaniloB, Krunch, Nemesuisse - If you have anymore input please add it, if not I will make the edits we discussed on the 22nd --Hardcover2452 (talk) 22:46, 16 March 2025 (UTC)

"free_flying:site_orientation" Why not just use "direction"?

I suggest moving over to the "direction" tag, it is standardized with a very well documented page. Why duplicate, right? Hardcover2452 (talk) 18:34, 2 December 2023 (UTC)

SGTM, but there are quite a few existing sites using "free_flying:site_orientation": https://overpass-turbo.eu/s/1EvV. Are there ways to migrate those automatically? -- Gwicke (talk) 19:03, 8 December 2023 (UTC)
Probably with some scripting but I wouldn't dare do it myself :P --Hardcover2452 (talk) 19:16, 8 December 2023 (UTC)
I don't see an official way to mark multiple valid wind directions with the "direction" tag, which is almost always done with "site_orientation". There's the "angle-angle" notation, which is confusing (no indication whether the angle is CW or CCW), and there's only some discussion about semicolon-separated values in the talk page --Wavexx (talk) 13:03, 13 October 2024 (UTC)

As far as I understand, all fields are generally agreed to have multiple values separated by semi-colons. As for the clockwise or counterclockwise, I think it's clockwise, as far as I can tell from all the different tools. Maybe it should be added to the direction page for clarity. Hardcover2452 (talk) 01:35, 6 February 2025 (UTC)

Never mind, it is clearly stated in the directions page that it is clockwise. (See " Field of view of a tourism viewpoint") Hardcover2452 (talk) 01:39, 6 February 2025 (UTC)

If "direction" allows for non-consecutives angles (i.g. "E;SW"), switching to "direction" is OK I guess. --Nemesuisse (talk) 17:27, 12 March 2025 (UTC)

I wonder if it would be good to differentiate between ideal and workable directions. Many locations have an ideal direction, and some directions that could work but that might require more skills, or are more risky. Often this is visualized using green and yellow colors around a compass. Any thoughts? Maybe "direction=*" for the workable directions and "direction:ideal=*" for the ideal directions? --DaniloB (talk) 21:55, 12 March 2025 (UTC)

DaniloB This is a great idea, it seems that the tag "direction:ideal" is not used anywhere else but I also couldn't find any sub-tags that are in use that would make sense. So I will add this to the table, if anyone objects please comment. --Hardcover2452 (talk) 00:50, 13 March 2025 (UTC)
+1, nice idea! Should be fairly straightforward to surface in a paragliding-specific web map view, and it can refine "is this site flyable right now / tomorrow" logic. Wind strength information would be nice to have too, but better first walk, then run? -- Gwicke (talk) 04:00, 13 March 2025 (UTC)
Adding to the table split that I referenced, I think wind strength could be added, the only question is how useful is it really, and should it also have a sub-tag for ideal strength. To me personally I don't see it being useful, but if anyone here thinks it really should be added, I don't see why not. --Hardcover2452 (talk) 00:51, 14 March 2025 (UTC)
Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Talk:Tag:sport%3Dfree_flying&oldid=2823925"