Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Intents with geo: scheme to set accuracy ground truth location #528

Closed
gdt opened this issue Jun 21, 2021 · 7 comments
Closed

Support Intents with geo: scheme to set accuracy ground truth location #528

gdt opened this issue Jun 21, 2021 · 7 comments
Milestone

Comments

@gdt
Copy link

gdt commented Jun 21, 2021

I'd like to try out the accuracy function in GPSTest, but it seems the only way is to type in coordinates. (There's also a QR code icon, but trying to read the README and linked pages didn't explain that, even though clicking on it gave enough hints.)

I'd like to be able to set a point from a file. There are multiple possible options, and probably more:

  • let GPSTest find a file, which should be geojson Point, with one point, and read it
  • as above but select the point by name from multiple
  • accept a geo share target, so one can load a gpx in osmand (e.g., exported from one's database of points) and share it and select GPSTest as the target. On receiving a point GPSTest should go into accuracy mode with that point.

Probably the share target is the least code for the most usefulness.

This really should be a 3D point, in WGS84 lat/lon/hae. But, for geojson, GPSTest should be ok with ITRF2014 or ITRF2008 instead.

@barbeau
Copy link
Owner

barbeau commented Jun 22, 2021

@gdt See https://github.com/barbeau/gpstest/blob/master/ACCURACY.md, which explains the current options (including reading geo: URI from QR Code as well as the SHOW_RADAR intent from other apps). I just added a link to this from the README to make it easier to discover in the future.

After you take a look at that let me know if you thinks that satisfies the use cases here.

@barbeau barbeau added this to the Nice to have milestone Jun 22, 2021
@gdt
Copy link
Author

gdt commented Jun 22, 2021

I am not finding out how to do what I want. I have a position in some other app (e.g. osmand as a gpx, which I created from my points database in qgis) and I tap the object and then I click share, and I get a (special because it's osmand) submenu for a bunch of methods. One of them is geo: and I click that and then I am asked which app to send the geo URI to. I see osmand, vespucci, and things like that, but I do not see GPSTest. So while I could scan a geo QR code, I can't just send a geo URI to GPSTest.

I was not previously familar with the RADAR intent. Is this part of AOSP, or is it a proprietary dependency? (I also don't get the impression benchmap is open source.)

@barbeau barbeau modified the milestones: Nice to have, v3.9 Jun 23, 2021
@barbeau
Copy link
Owner

barbeau commented Jun 23, 2021

I have a position in some other app (e.g. osmand as a gpx, which I created from my points database in qgis) and I tap the object and then I click share, and I get a (special because it's osmand) submenu for a bunch of methods. One of them is geo: and I click that and then I am asked which app to send the geo URI to. I see osmand, vespucci, and things like that, but I do not see GPSTest.

Thanks! These specific steps help. Yes, I don't think it should be too bad to add this given the infrastructure I already have for reading QR codes and SHOW_RADAR. I'll take a closer look.

I was not previously familar with the RADAR intent. Is this part of AOSP, or is it a proprietary dependency? (I also don't get the impression benchmap is open source.)

Google defined this for interacting with Google Maps on Android, but it's open in the sense that any app can send or receive this info. You can think of it as an alternate version of an Intent that uses the geo URI. The end result is effectively the same as the above behavior you describe using the geo URI.

@barbeau barbeau changed the title Read geojson or use share method to set reference location for accuracy Support Intents with geo: scheme to set accuracy ground truth location Jun 23, 2021
@gdt
Copy link
Author

gdt commented Jun 23, 2021

Thanks! These specific steps help. Yes, I don't think it should be too bad to add this given the infrastructure I already have for reading QR codes and SHOW_RADAR. I'll take a closer look.

Great. That should resolve my actual need, and take away the bizarreness that you can scan a QR of a geo: but not deal with it normally.

I was not previously familar with the RADAR intent. Is this part of AOSP, or is it a proprietary dependency? (I also don't get the impression benchmap is open source.)

Google defined this for interacting with Google Maps on Android, but it's open in the sense that any app can send or receive this info. You can think of it as an alternate version of an Intent that uses the geo URI. The end result is effectively the same as the above behavior you describe using the geo URI.

So it's sort of open in that anybody can send it, but it's sort of not in a same-but-different to deal with google maps rather than any geo app, encouraging people to write google-specific code :-(

I wonder if google maps can take the geo URI and if so, if the RADAR support can be removed as duplicative.

@barbeau
Copy link
Owner

barbeau commented Jun 23, 2021

I wonder if google maps can take the geo URI and if so, if the RADAR support can be removed as duplicative.

It's pretty straightforward to support both, so it's not a issue. IIRC BenchMap already supported SHOW_RADAR which is why I started there.

@barbeau
Copy link
Owner

barbeau commented Jun 24, 2021

So the only issue here is that as @gdt noted in #529 (comment), in RFC5870 the geo: URI altitude is WGS84 ortho height, which we can't currently support until #530 is implemented or support in an Android Location API exists.

Looking at OsmAnd, it seems to only share lat and lon and not altitude, so I'm inclined right now to just support importing lat and lon but not alt from geo: URIs (as opposed to supporting importing altitude as HAE, which wouldn't comply with RFC5870).

@gdt
Copy link
Author

gdt commented Jun 24, 2021

Your proposal to just drop altitude from geo: sounds sensible, and useful incremental progress. It would be nice if the accuracy screen was clear about 2D vs 3D, but I'm guessing if I saw the 3D version I 'd realize it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants