Add field for location

  • Resolved saturnz

    (@saturnz)


    2 years, 5 months ago

    Hi,

    I would like to how can I add an input to give the possibility to users to change the weather forecast location. I know that there is geolocation, but if I try this functionality on my computer, it locate me in Paris but I’m not. I hope you can help me with that issue.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Author Uwe Jacobs

    (@uwejacobs)

    This would be a major undertaking since the setup is currently at the backend, not the frontend. I added it to the feature list but I don’t think I will get to it anytime soon unless there are more requests for this feature.

    Also, this setup will drain the 1,000 API calls per day quickly since every user will make 1 to 3 API calls depending on the setup of your weather.

    Thread Starter saturnz

    (@saturnz)

    Well, I hope that one day this option will see the light of day.

    Thanks for your answer, and have good day.

    Cool idea. Challenge in keeping spam-location-submits out. Also making it user-friendly with validating the input to actual geo-data request(and the source of this data to match/validate). Although the plugin is free, the amount of ‘free’ weather-data requests is limited to website-owners.

    Could lead to a lot of filtering of location-submit-abuse intended for sabotage/spam-traffic.

    I had a kind-a-equal situation where the browser-location-feature/setting: should be nice to out-zoom to country-wide forecast in stead of town-name forecast(helps mismatching guest-geo-location town-name results.). Just zoom out to country, would solve the ‘wrong town-name’ results problem(but the wrong town-location-results, remain always within the right country).

    Could also help with lowering total-used API-calls, but this is not equal to your guest-custom-location-submit feature-request.

    Thinking out loud: if the browser its location feature of the guest doesn’t provide data, the plugin could switch back to IP-location data. On the moment IP-location is used by the plugin, the country location(or capital) could be used(in stead of town-name related to IP what is almost always a mismatch).

    Using town-location when browser-location data is available is a more certain condition/situation where guest-location and matching become effective(and so less or no false/wrong location results).

    Plugin Author Uwe Jacobs

    (@uwejacobs)

    I added HTML5 GeoLocation to the search by visitor’s location. Should the user deny the request for his location, the search will fall back to the IP search. Please install version 5.3.2 and give it a try. The HTML5 GeoLocation is much more precise than the IP-based GeoLocation and should also work in a development environment.

    Dear @uwejacobs,

    Thank you for the update with upgrades.

    I can confirm that the popup, for ‘browser-location request’ is working.

    It has only no ‘website-visitor memory-function’. Every time reloading the page, the browser gives the same message(suggestion: store the guest its previous retrieved location-data in a cookie, to prevent a ‘pop-up location-request’ from the browser, each page-load).

    Also the ‘default’ city ‘IP-location’-name, changed from ‘IP-Location city-name’ to default ‘Globe’. Thinking your making ‘Open Weather’ and many web-hosters happy, with this ECO-friendly default-setting ??

    Plugin Author Uwe Jacobs

    (@uwejacobs)

    website-visitor memory-function:
    Caching the data in a cookie makes a lot of sense for stationary devices like servers and desktops but not so much for laptops, tablets, and mobile phones. Unfortunately, there is no reliable way to identify what device OWM Weather is dealing with; every suggestion on the web is more or less a hack. Then is the question of how long should the cookie be valid. A mobile device could be requesting the site from at a different location at a moment’s notice.
    Having said that, html5 introduced a session storage concept. It stores data locally in the browser and expires when the window or tab is closed. This seems to be a good compromise and I will add a caching function based on session storage with one of the next versions.

    IP-location-name:
    The city name ‘Globe’ comes from OpenWeatherMap when neither the GEO-Location nor the IP-location was able to produce a latitude/longitude value. The OpenWeatherMap API description states that it will use a central location and return its weather data. (The same happens when the search criteria is a country, i.e. France. OpenWeatherMap will not return weather data for the whole country; instead, it provides the data for the central location of that country.)

    Plugin Author Uwe Jacobs

    (@uwejacobs)

    FYI: I added a quick test page that shows which locations the GEO- and the IP-based searches come up with: https://ujsoftware.com/owm-weather-blog/geo-and-ip-location-test/

    @uwejacobs Yes, this seems to be the problem.
    The browser-location-popup is a nag in persistence of returning.

    Yes: I think that for OWM-Weather plugin, its worth to store the given browser-location with a refresh-browser-location-time(if setting is enabled). Min/max visitor-browser-location-refresh-rate + ‘Last-used cached-weather-object’ logic, perhaps helps to reuse/combining of ‘aggressive-moving’ visitors and there ‘browser-location-cache’ pop-up on the client-side. trough many rogue-visitors(who just-don’t-care) resulting in a endlessly querying of non-buffered weather-objects…

    Current plugin-condition no-website-visitor becomes happy, with a endless(never quieting) browser-location-popup. Currently the only solution is to force/store allow/block the location-popup at the browser…

    ——————–
    Doesn’t HTML5 support: browser-location-data ‘accessible and allowed’?, before pooling every page-visit? I’m understanding that ‘Visitor-location-caching’ has a shorter ‘usable-lifetime’ than ‘weather-object-caching’.

    *Client-browser-Location-cache-refreshing-time, could be a plugin-setting (some plugin use-cases could require: live, 10 minutes, every-page-hit, once(stored in cookie)).
    *Location-refresh-icon’on/off’ (next to the location-city-name), to disable/enable ‘browser-location-website-request’ feature(and cookie it).
    ——————–

    I think it could also help with the ‘total amount of Open-weather queries’, being generated by unwanted(and unregulated/managed) varieties of Open-weather-queries deriving from visitor-use of this plugin(compliments and thank your making).

    Thank you for the ‘zooming-out’ from ‘town-name’, to ‘planet-name’. This saves the globe ‘OpenWeather-API calls’ and a dramatic improves data-accuracy, when using ‘visitor-location’ feature.
    Almost there!

    I’m looking forward to your replay.
    With kind regards,

    Plugin Author Uwe Jacobs

    (@uwejacobs)

    Hi,

    I just submitted version 5.4.0. It contains the html5 session storage functionality that I mentioned above. It stores the positive and the negative reply for the user’s browser tab until it gets closed. This will cut down on the nagging pop-ups. I would like to start with this approach and see how it goes.

    The Geo-location permission is handled by the browser. If the user does not check “Remember the decision”, he will be asked again at the beginning of every new session. Otherwise, the browser will immediately reply with the location or throw an error regarding the missing permission.

    The OWM weather data is cached by location. In the case of geo-location, this is via the longitude and latitude. If you set the OWM Weather caching to 30 minutes, any stationary geo-location user could generate a maximum of 48 API calls per day.

    Plugin Author Uwe Jacobs

    (@uwejacobs)

    Version 5.6.1 now caches the geo-location (key is IP address and browser string) for 30 days. In a multisite installation, the cache is available to all websites. With this cache, the geo-location is still available after the browser tab closure or when the top-level domain for each website in the network is different.

Viewing 11 replies - 1 through 11 (of 11 total)
  • The topic ‘Add field for location’ is closed to new replies.