WISH: URL parameters to position the initial map

[HenrikBengtsson]

Wish

I'm aware that the 'Go to' search box accepts GPS coordinate, e.g. "39.3199,-119.8674". It could be useful to be able to link any specific location, or search query, e.g. to your favorite flying site:

https://flyxc.app/?q=37.531365,-118.279341

PS. Thanks for an awesome project and for making it open source.

[vicb]

Can you expand about your use case.

I'm afraid it might not be an easily discoverable feature - or may you have an idea on how to integrate that in the UI?

FYI I'm planning to add flyxc.app/pilots/<id> and flyxc.app/groups/<id> to open the map on a pilot / group.

[reavis]

I would love to be able to create a direct link that centers the map on my location. I'll be watching this issue for updates.

[HenrikBengtsson]

Can you expand about your use case.

Sometimes you are interested in a flying site rather than a specific pilot, e.g. to check if people a flying right now. It could also be that you know there will be a group of people going to one of your favorite sites. If you want to check that site, you'll have to zoom out, scroll, scroll, ..., scroll, zoom in right now.

Add support for specifying coordinates via URL parameters would align with other free-flying related sites, e.g.

• https://www.spotair.mobi/?lat=19.0617&lng=-100.09047&zoom=14
• https://paraglidable.com/?lat=19.062&lon=-100.090&zoom=14
• https://thermal.kk7.ch/#19.0617,-100.09047,14z
• https://skyvector.com/?ll=19.061704,-100.090468&chart=301&zoom=3
• https://www.opentopomap.org/#marker=16/19.0617/-100.09047
• https://earth.google.com/web/@19.0617,-100.0905,2346.96a,3346.96d,30y,287.99922327h,60t,0r/data=OgMKATA

I'm afraid it might not be an easily discoverable feature - or may you have an idea on how to integrate that in the UI?

I see. Yeah, sorry, I don't know how to implement this.

FYI I'm planning to add flyxc.app/pilots/<id> and flyxc.app/groups/<id> to open the map on a pilot / group.

That sounds like a great, complementary addition.

[vicb]

I see. Yeah, sorry, I don't know how to implement this.

I am not asking you to implement it but if you have ideas about how the UI/UX should look like

Probably at some point flyXC will support flyxc.app/sites/<id>

[reavis]

Since URL paths and parameters are mostly useful to power users, I would suggest updating the URL whenever the map viewport changes. This would allow people to bookmark favorite locations or send links to them without any UI required. You could add a "Bookmark" entry to the menu to make that functionality more clear.

See https://www.google.com/maps/ for an example of updating the URL when the viewport changes and https://www.wrh.noaa.gov/map/ for a bookmark UI. If you could combine both of those features, I think it would be awesome!

For your future pilots and sites features, I would suggest a similar approach. We already have a UI for zooming to a specific pilot who is live tracking. You could add a site selector that works the same way and lists sties based on distance, number of people flying from them, longest flight in progress, etc. If those actions updated the URL, it would allow the same bookmarking and link sharing workflow.

I imagine there are some edge cases related to the pilot selector, since people who haven't flown in the chosen time window don't show up in the list. I have no idea how complex this implementation would be, since I haven't looked at your code yet, but this is the behavior that I think makes sense:

When a pilot who is not tracking is selected via URL, the map zooms to their last trackpoint and the historical tracklog is loaded (assuming you still have the data). If you are discarding tracking data quickly, it may make sense to retain the last trackpoint/message from every pilot. If those options are too complicated, you could just pop up a modal saying that the pilot is not currently tracking or has no trackpoints in the selected time window. I would love it if you could specify a parameter to prevent other live tracks from loading when the pilot URL is used. It would be much clearer for retrieve drivers and would use less data on spotty cell connections if only the selected track were loaded and visible.

Once you have the pilot URLs working, it should be easy to add a section to the logged-in Setup page that displays the URL for the pilot who is logged in, allowing them to copy and paste.

[HenrikBengtsson]

I see. Yeah, sorry, I don't know how to implement this.

I am not asking you to implement it but if you have ideas about how the UI/UX should look like

I'd prefer named longitude and latitude URL parameters, because that invariant to the order of longitude and latitude, e.g.

https://flyxc.app/?lat=19.062&lon=-100.090

If a URL path, then maybe something like:

https://flyxc.app/latlon/19.062,-100.090

Another advantage with URL parameters is that new ones can be introduced, e.g. zoom level.

I like @reavis suggestion;

Since URL paths and parameters are mostly useful to power users, I would suggest updating the URL whenever the map viewport changes. This would allow people to bookmark favorite locations or send links to them without any UI required.

This would also have the advantage of displaying the coordinates, if someone is interested in those.

Probably at some point flyXC will support flyxc.app/sites/<id>

I'm curious, since I've been thinking about site IDs elsewhere, how are you anticipating that a (site, id) database is updated and maintained? There are already so many different site IDs out there, but we lack a canonical standard. One thought I had would be to generate the ID based on the (longitude, latitude) of the main launch, e.g. a 10-character Open Location Code, which has a 14m-by-14m precision all over the world. Another idea is to refer to launch site in OpenStreetMap (e.g. https://www.openstreetmap.org/node/1422613214) - if not there, they can easily be added. The advantage is that the latter could serve as the root source for all flying sites around the world (instead of each website maintain their own).

[vicb]

Lots of great ideas, thanks!

The positions are stored in a in memory DB and not persisted more than 24h - but I don't think it makes sense to center the map to where a pilot flew 1 week ago.

It would be much clearer for retrieve drivers and would use less data on spotty cell connections if only the selected track were loaded and visible.

I plan to make the live track length configurable - older sections would have a lower opacity or not be displayed at all (configurable)

Spotty connection: the live track data are composed of a first full payload + periodic diff payloads. The full payload level of details is reduced for fixed older than 6h. I plan to have a light version with low LOD for spotty connections too.

Another advantage with URL parameters is that new ones can be introduced, e.g. zoom level.

URL segments are actually less flexible, it's much easier to have optional query params. Why would it be problem that query params do not have a fixed order.

I'm curious, since I've been thinking about site IDs elsewhere, how are you anticipating that a (site, id) database is updated and maintained?

I am discussing with wingit. They have a site DB and API, we are probably going to work together. Plus code are a great idea.

OpenStreetMap would be awesome, we'll think about that.

FYI one of the reason why linking to a pilot/site has not yet been implemented is that it would probably up the number of site loads which translate to Google Maps API loads which ultimately translate to $.