Comments (7)
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.
from flyxc.
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.
from flyxc.
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.
from flyxc.
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).
from flyxc.
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 $.
from flyxc.
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>
andflyxc.app/groups/<id>
to open the map on a pilot / group.
That sounds like a great, complementary addition.
from flyxc.
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>
from flyxc.
Related Issues (20)
- Live tracking animation
- Drop ionic?
- Saving the devices form without an UUID (samzed)
- Display airspaces along XC planing route
- Make skyways more visible
- REORGANIZE app in 3 pillars
- Add distance guides for triangle
- UX: improve livetrack display to avoid mess on XC days
- Integrate CF Zaraz
- packages of libraries have to be duplicated on top level package.json
- Google login
- PWA: Customize title bar
- PWA: release to app stores
- PWA: paste route (i.e. flyxc URL)
- WISH: URL parameters to set preferences HOT 4
- windy sounding: add rain mm
- WISH: 3D view rotate key alternative HOT 3
- Show dialog when optimizing track is too long
- Adding support for Meshtastic (Bircom) HOT 47
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from flyxc.