#2844 Patches to add 'Custom' category to poi.dat and Marker Pins

[Huntley Palmer]

Ref a discussion on the forum
these patches add a new category, 'custom' to the Marker pin menu in View-View Options and create a new type, 15, as a custom category for Points Of Interest nav data file: poi.dat.
By appending to the POI file, for example, EGBB Birmingham's published Visual Reference Points:
( At EOF, after Type 14 Villages)

14 6.3787717 -1.9446483 Kumpese 14 6.5569166 -1.6702559 Pechi 15 52.2513 -1.5955 VRP Franklin Resv 15 52.4110 -1.4755 VRP Lichfield Junc 15 52.2745 -1.2939 VRP M6 J3 Bedworth 15 52.3838 -2.0323 VRP M6 HiltonPk Svce 15 52.1537 -1.3648 VRP M40 J15 Warwick 15 52.2055 -1.4835 VRP M40/M42 Intchge 15 52.2055 -1.4835 VRP M40/M42 Intchge 15 52.3612 -1.3833 VRP M42 J10 Tamworth 15 52.1604 -1.5353 VRP Studley

Then Marker Pins for 'Custom' entries can be selected alone or with other Marker Pin categories.

[James Turner]

I'm okay with adding new POI types but I don't like adding a type called 'custom' : can't we make as many new meaningful types as needed? Especially in the case of a VRP this feels like something that is not even really a POI but something more like a nav.dat extension, but I'm okay for it to be in poi.dat for now, but let's make a new type for it 'properly'

[Huntley Palmer]

Any name is fine with me, 'user' occurred to me too. Points-Of-Interest has the advantage of a simpler format: just Lat, Lon and Text description. On the downside it looks as if POI data cannot be extended by the user adding a local file, the way datapoints for nav data can be over-ridden.
Conceivably these flags could be used for more than navigation Visual reference Points e.g ad hoc assembly points during MP get-togethers, they are identified as official VRPs only by the text label. Would 'User-Added' be satisfactory ?
Thanks for looking at this, I'll see if there's any positive reaction on the forum's requesters .

[James Turner]

I think you miss my point: I do NOT want to add a single new 'real type' where we then have to look at the type as part of the label. I'm saying, don't do that, rather define as many new real types as we actually need and keep the label as it should be, with no semantic meaning.

[James Turner]

(We can have tens or hundreds of new POI types if we need them, but I expect we really want to add a handful more, and that's fine)

[Mariusz Matuszek]

James, I don't know if it is even possible to define all possible use cases in advance. On the forum a 'VRP' use case was presented, but there could be others, like (I think already mentioned) parking positions, or gliding competition waypoints, etc.

I understand your dislike of having the type (use case) embedded in the name, but since this would be a new feature, we don't know in advance how it would be used and by whom. These POIs could be very dynamic and short lived by their very nature, so how about allowing just a catch-all type for now and looking at use cases which emerged, say, a year or two from now?

Whether this type is called 'vrp', 'dynamic', 'user', or 'addon-defined' is of lesser importance for now, imho. Or how about defining two new types? 'VRP' and 'dynamic'? Reasoning: vrp's tend to stay the same for a while, so they could already get their own category, the 'dynamic' would be available to see what other use cases develop in time.

I would be happy to use the 'dynamic' category for a one-off MP competition event. In such use case the category doesn't really matter and the names like WPT01, WPT02, etc. are self-explanatory and do not live long anyway.

[James Turner]

Ahh you maybe are unware, there is already a 'waypoint' type indended to be used for pilot / operator defined custom waypoints in a GPS or FMS. (Which most GPSs let you do, of course)

I'd say, let's add VRP as a real type, but also POI.dat to define 'waypoints', but also you shoudl know there is a GPS command for this 'define-user-wpt', what we should problem do is directly expose those to Nasal so an addon could define or update dynamic waypoints.

So:

• Add a new positioned type "VISUAL_REPORTING_POINT' (also happy to add them for IAFs or FAFs if needed)
• allow these to be defined in POI.dat
• allow WAYPOINT types to be defined in POI.dat
• add addCustomWaypoint API to Nasal to define waypoints dynamically (taking a type, ident, lat-lon and name)
• decide if we add a removeCustomWaypoint / updateCustomWaypoint methods as well

How does this sound?

[Huntley Palmer]

Just that 'dynamic' doesn't work for me in this context; I understand it to mean 'in motion' , the opposite of marking a fixed position. Temporary ?

[James Turner]

dynamic is used for both moving (carriers) and temporary / ad-hoc indeed.

[Mariusz Matuszek]

That sounds very good to me. We could also consider having CustomWaypoint volatile, i.e. not stored permanently at all. So if, for example, a set of CWs would be defined by some add-on on init, it would be gone when FG exits (or crashes).

[James Turner]

Yes it seems we have a few different options

• user-defined permanent waypoints (which we already had for years, but not exposed to Nasal, only GPS commands). (Here 'user' includes instruments like FG1000 and add-ons)
• new permanent types defined by poi.dat (VRP, etc: suggestions for types welcome)
• temporary waypoints which are not stored at all : I would do this by having a flag to mark such WPs

Only question for me is if we need dynamic (moving) WPs in this scheme, i.e an 'updateDynamicWaypoint'. Right now we only use this for mobile TACAN (carriers and airbone refuelling), but I wonder if add-ons might be able to do some interesting things with it?

Dynamic waypoints are always 'temporary' BTW: they are created and removed when the owning entity (eg, AITanker or AICarrier) is loaded/unloaded.

The core Nasal API is going to be:

var id = addWaypoint(<type>, <pos-as-geod>, <ident>, <name>,
dynamic = True | False,
temporary = True | False);</name></ident></pos-as-geod></type>

 And then a:

 updateDynamicWaypoint(id, <pos-as-geod>)

Note that the returned ID will be the unique Nav-Cache/DB ID, since unfortunately 'ident' is probably not unqiue.

[Huntley Palmer]

I've bounced this off the forum. It seems to me your Nasal API above covers all the needs, even VRP's could be handled this way without cluttering the Nav data files: for instance a group of reference points could just as easily be shared as a script rather than as a modified poi.dat.

From the forum comments 'dynamic' would be useful, as in 'team leader' / 'pathfinder' marker and also as 'here be a thermal' for group gliding sessions.

Thanks !

[James Turner]

I've done most of this and pushed to next, will need to document the new Nasal APIs.

[Huntley Palmer]

These patches to fgdata/gui/dialogs/view.xml and fgdata/Nasal/markerpins.nas make Visual Reference Points, added as Type 1000, to fgdata/Navaids/poi.dat.gz selectable and visible as desired, Thanks !
Is there "any chance" poi.dat.gz can be added to the navaids that can be appended / overridden by including poi.dat in a custom scenery NavData/poi folder ? That would make sharing markers so much simpler, Extra Thanks !

[James Turner]

I'll patch the dialogs shortly. I thought custom scenery could already extend POI.dat, it might need some work if it's not already supported.

[James Turner]

I'm extending the code to allow multiple POI.dat files ... it's a bit more work than I expect, but should be done by the weekend.

[Huntley Palmer]

Thank You for doing this.

[ranguli]

Hi @jmturner, just checking in to see if there was any update on this and whether we should include it in the 2024.1 release or hold off.

[James Turner]

This is done and already on the 2024.1 branch, I just forogt ot close the ticket.