Page 3 of 3 FirstFirst 123
Results 41 to 53 of 53
Like Tree14Likes
  1. #41  
    Quote Originally Posted by Preemptive View Post
    It may be superstition, but I've an idea in my head that having wifi on may help
    It's not superstition, I started a thread https://forums.webosnation.com/palm-...t-working.html back in 2014 when my GLS mysteriously quit working, which as you pointed out here seriously hinders GPS operation. With the help of people like TJ, I realized that GLS seemed to be working fine for other people, just not for me. I never did figure out why it quit working, but a couple of months later it magically returned.

    You can read the gory details in my earlier thread, but the bottom line is, I found and shared a work around posted on another website ... that work around involved disabling GPS and GLS, then turning on your WiFi radio, no connection needed just turn on the radio, then turn your GPS back on ... it worked every time.
  2. #42  
    OK, we know the GPS system is still working. This thread is about the IP location system. This is how to get a rough location via wifi when indoors or waiting for the GPS to lock on. Looking back over the thread, it seems that webOS has a location service. I'm not clear if it's a single service or two, but the result is that the IP service can deliver a rough fix and the GPS is prioritised when available for a more accurate fix.

    We know that George Mari has found a way to fix the Homebrew Googlemaps app, but as the pricing structure for access to the API has changed, this means each user must apply for a developer key and 'personalise' the app. A single built in key might get enough requests from users that the developer gets hit with a large bill...

    So...
    1. Is there a central webOS service (or two) that connects to Google & the GPS sensor to deliver location data to a requesting app?
    2. Or can each app make it's own request to [whatever] location service, using the webOS service only for GPS data?
    3. Or both of the above?

    It seem to me that it would be easier if an individual app just requested a service from the system, but it maybe that 2 or 3 are also true. Where only 2 is true, then each app would need to be fixed if the service API (Google in most cases I guess) changed. If it's a central service, then we only need to fix the webOS service to make all apps work. We could, for instance all request dev keys from google and paste them into an API patch for the webOS location service. The other (ideal?) option is to be able to select from a list of services from other providers. Of course if google is 'hard-coded' in, then it's a bigger fix to create the possible options.

    It's possible that other services are less accurate than Google's, but may be considered good enough if they are free to use and the hassle of signing up to be a developer is likely a step too far for many users.

    I assume that the following have an IP location service available:
    • Mozilla
    • Bingmaps
    • Here
    • (probably not open) Apple
    Last edited by Preemptive; 05/11/2019 at 03:32 PM.
  3. #43  
    Quote Originally Posted by Preemptive View Post
    This thread is about the IP location system
    I don't believe that WebOS ever used any kind of an IP location system, it was all based on cell tower location, unless you call that IP. In our location services menu there are two options, GPS and GLS. Back in 2014 when I was having trouble with GLS I looked into this extensively. At the time TJ confirmed that, on his Pre 2, when he turned off GPS, GLS would locate him at the nearest cell tower. When I found the work around mentioned in my previous thread I did some experimenting. After my GLS suddenly started working again, I tried to figure out exactly what it did. As before, with GPS turned off, GLS would locate me at the nearest cell tower, if I put the phone in airplane mode and then turned on WiFi separately and connected to a router, GLS would no longer work. I'm pretty sure it has nothing to do with IP address other than what the service provider gives you from their cell tower, and that's what Google used for their GLS system, at least on WebOS. I know quite a bit about how GPS works, and if you have GPS turned on in our WebOS location service, the only reason it wanted a rough location from GLS was so that it could use that information to do the math and find the satellites quicker. Of course if you had GPS turned off and GLS turned on, it would locate you at the nearest cell tower and use that rough information for location based services, but it was very rough.

    In my previous post here I was simply confirming that your "superstition" was in fact correct. Turning on the WiFi radio does in fact wake up the GPS receiver on the Pre 2, for some reason. Now that I'm on the Pre 3 I no longer worry about that, I've never even turned on GLS, GPS works fine and very quickly without it.
  4. #44  
    Google Location Service would correlate a WiFi access point list and corresponding signal strength for each SSID with computed estimates of the locations of each access point that are based on locations other devices have reported. Google then uses all of this data to triangulate your nearest position. I suspect if you are using Google and it is showing you a location of a cellular tower it is because some device was reporting that as the GPS coordinates when it reported a list of nearby access points.

    The API endpoint that Google Location Services used to work off of is no longer active. It used Google's Protocol Buffers to serialize the data objects into a compressed packet.

    com.palm.location would talk to the Google Location Service for wifi based locating, and it would also speak to the TIL (telephony interface layer) to get GPS coordinates from that (using either the modem's GPS, or A-GPS from the carrier -- which generally would be a way for the modem's GPS to search a narrow selection of GPS satellites using an almanac instead of trying to scan everything). I think if there was a GPS card in a TouchPad either com.palm.location would handle that, or the TIL would still do that (haven't ever played with that setup).

    My thought for a replacement to com.palm.location would be a service at that address that was 100% plugin based. You'd have a plugin for phone GPS, a plugin for BT GPS, a plugin for some other GPS, an plugins for whatever wifi location services you wanted (I'd probably personally pick Mozilla). The benefit there is that if something changes you just have to re-write the plugin and not the whole bloody service! D-:
    Did you know:

    webOS ran on a Treo 800 during initial development.
    Preemptive likes this.
  5. #45  
    That makes sense, though I suspect creating the plugin system maybe the big job...

    I'm wondering if a hard patch to... say, Mozilla is the quick and dirty solution. Maybe a plugin system is for LuneOS, perhaps back-ported if any legacy devices are still working by then.

    As a side-note: It seems the LuneOS GPS still doesn't work. I wonder if it's the system or a driver thing?
    Last edited by Preemptive; 05/13/2019 at 09:20 PM.
  6. #46  
    Quote Originally Posted by Preemptive View Post
    That makes sense, though I suspect creating the plugin system maybe the big job...

    I'm wondering if a hard patch to... say, Mozilla is the quick and dirty solution. Maybe a plugin system is for LuneOS, perhaps back-ported if any legacy devices are still working by then.

    As a side-note: It seems the LuneOS GPS still doesn't work. I wonder if it's the system or a driver thing?
    Well we have a location service that can use either Google or Mozilla. Based on my experience the Google one is a lot more accurate. GPS just wasn't hooked up yet, but shouldn't be rocket science since we have all the bits in place technically.
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
    Preemptive likes this.
  7. #47  
    Quote Originally Posted by Herrie View Post
    Well we have a location service that can use either Google or Mozilla. Based on my experience the Google one is a lot more accurate. GPS just wasn't hooked up yet, but shouldn't be rocket science since we have all the bits in place technically.
    Through GeoClue, right? I hadn't really looked at GeoClue, but kinda just did now. It looks interesting. I see it has config files. I wonder if it has a more dynamic config that uses a database? (For permissions and such.)
    Did you know:

    webOS ran on a Treo 800 during initial development.
    Preemptive likes this.
  8. #48  
    Quote Originally Posted by dkirker View Post
    Through GeoClue, right? I hadn't really looked at GeoClue, but kinda just did now. It looks interesting. I see it has config files. I wonder if it has a more dynamic config that uses a database? (For permissions and such.)
    Yeah GeoClue as backend. We have a direct LS2 service and one via QtLocation that is used by the browser if I'm correct.

    Sent from my Redmi Note 4 using Tapatalk
    HP Veer (daily driver), HP Pre 3, HP Touchpad Proper 4G/LTE (Sierra MC7710), HP Touchpad 32GB WiFi, Palm Pre 2
    Preemptive likes this.
  9. #49  
    Er...
    Maybe I'm staying the obvious here, but...

    I had a slight embarrassing moment today when someone said, "Just call up Google maps..." I figured maybe I could search for a place, but it got stuck trying to locate me.

    Later, I started the Qt browser and went to the web page - it works fine, including locating me. Of course, it's the web interface.

    So my 2 thoughts are:
    1. the new browser can be used.
    2. What if the app spoofed being the webpage? Or the Android app?
    There may well be ways the second option could be detected / blocked, but they are expecting occasional requests from the webpage or app rather than mass requests from some commercial service, so the usage pattern would match that of any other user.

    Remember the problem is not the API, but Google's charging policy towards private developers (who they assume are making money).
  10. #50  
    Does anyone think it is possible for webOS to send a request to Google that appears to be from the Google Maps webpage?

    There is a google maps search plugin on my browser. If I search with an empty search string, the map delivered is my local area. Perhaps the search is just another page request..?

    Anyway, the returned URL includes the co-ordinates, so could that be read and passed to any app requesting location data? If possible, then we get the free access to the service given to a web browser, but pass a user's location to the webOS service. I know it's a bit of a cheat, but I'm assuming it will be fairly unnoticed, given the number of webOS users. A droplet compared to the tide of millions of daily API requests they must receive.
  11. #51  
    Just to note: searching postal codes via Just Type > Navit Targets hasn't worked for a while. I don't know if it's using an OS service or 'going direct' to... wherever!

    https://www.webos-internals.org/wiki/Application:Navit

    https://www.navit-project.org/index.html
  12. #52  
    The User Group had an online meeting today. This is the summary on the location service. The full log is here (with more technical bits): http://logs.nslu2-linux.org/livelogs...s.20190721.txt

    After some discussion, the situation appears* to be this:

    It is assumed that most apps will request location data from the webOS Location Service (wLS), though it is possible an app could send an API request directly to Google. The advantage of the webOS service is of course that it can acquire data from the GPS receiver, using Google for a 'quick & dirty' fix by wifi location while satellite data is still being sought or if the receiver is inside a building.

    The service is a binary blob. This means that it is difficult to patch (likely decompiling the code would be required, though it's possible that available source code exists somewhere if it was OSS at any point). This means that the idea of spoofing the API request as if it was from a google maps page is probably a non-starter as that will be in the form of an HTML request, not any code that can be compiled to binary.

    There was discussion of existing code for Qt5 mapping apps, but the fundamental problem is with the wLS and is two-fold: (1) The API code is out of date (i.e. broken) and (2) Google now has a more restrictive license that would impose large charges on whoever had the specific developer API key if there were a large number of requests. Likely requests from webOS users is very difficult to estimate, so a risk.

    Therefore the current proposed strategy is:
    1. Rename the original service.
    2. Replace the original service with a new one that queries the renamed original service for GPS data and makes it's own request for wifi location - from a service that replaces the Google one (GLS).
    3. The current suggested service is Mozilla Location Service (MLS), which is still free, though developer keys are no longer being issued (Unfortunately, MLS is not considered to be as accurate as Google). A further suggestion is to use a plugin system so that various service options can be user-selected (this is also the intended approach for LuneOS).
    4. Example code can be published so that if an app is making a direct request, interested parties can patch the app, but it is assumed that fixing the service will automatically fix the majority of apps (as long as the returned data is correctly formatted).

    * correct me if I'm wrong!

    Following item 4, it may be possible to run a search of IPKs of apps that use location services, but forum members are welcome to post the names of apps that do on this thread. Again, those that request data from the OS (likely most of them) should work is the wLS is fixed. The remainder will have to be fixed individually.
    Last edited by Preemptive; 07/21/2019 at 07:48 PM.
  13. #53  
    Another note: Here maps appears to have an API: https://developer.here.com/
    Up to 250K 'transactions' are free. Not sure what counts as a transaction. https://developer.here.com/plans

    Mozilla: https://location.services.mozilla.com/api
Page 3 of 3 FirstFirst 123

Similar Threads

  1. Verizon GPS improved after Bing Maps replaced Google Maps
    By JED-WEB-OS in forum North American Carriers (CDMA)
    Replies: 8
    Last Post: 04/30/2012, 02:57 PM
  2. Anyone update to BING maps and restore google maps
    By mc_gusto in forum Palm Pixi and Pixi Plus
    Replies: 30
    Last Post: 01/12/2012, 07:59 AM
  3. Replies: 28
    Last Post: 11/07/2011, 07:37 AM
  4. bing maps can't find my location
    By Fuzzy Gizmo in forum Palm Pre 2
    Replies: 7
    Last Post: 10/26/2011, 10:24 AM
  5. Bing Maps Auto Location
    By sledge007 in forum HP TouchPad
    Replies: 5
    Last Post: 10/08/2011, 06:13 PM

Posting Permissions