User talk:Eupeodes/Geohashing Map

Talk about version 1 on User talk:Eupeodes/Geohashing Map/v1

Comments by Sourcerer

Hi - An interesting new version. The calendar view is useful, as is the hide/show feature.

I have found some small problems ...

1. When I click on "Meetup", there is a missing leading zero in the month, like this 2016-1-01 52 0.
2. I really miss "Street View" which is incredibly useful for finding access paths but your link to Google Maps fixes that.
3. The glat and glon parameters don't seem to be working yet.
4. Will you be bringing back the Mo, Tu, We style option instead of the date based view?
5. Could you use a cookie to save the view state? I prefer hybrid.

Thanks, Happy New Year and keep up the good work --Sourcerer (talk) 06:01, 1 January 2016 (EST)

I Will reply to the points later, but I can already say that I will fix all except street view within a few days --Eupeodes (talk) 06:08, 1 January 2016 (EST)

Here a response in more detail:

1. Missing zero is added
2. I can understand, that is why I included the link to Google Maps. I was a bit held back by the google maps api which I was using, now I use openLayers.
3. Nope, have to implement them still
4. I can do that I guess
5. Might be a cookie, might be a login. And at least I will add the url param for map type again to the system

Ow, and the old site is also still working. It can be found at http://v1.geohashing.info. --Eupeodes (talk) 13:21, 1 January 2016 (EST)

The view state can not yet be saved in a cookie, but can be added as an url parameter (type=(sat|hyb|map), or just (sat|hyb|map) in the short url format. --Eupeodes (talk) 04:16, 3 January 2016 (EST)

Glat and glon/glng are back, and also in the short notation, see the help function on the site --Eupeodes (talk) 14:48, 10 January 2016 (EST)

Cookie option is also back --Eupeodes (talk) 15:16, 11 January 2016 (EST)

Wrong date on marker

The points on the map are showing up as of 7AM Pacific, for 45,-122, but they are tagged with a "3" instead of a "4". (Today is the 4th.) Jiml (talk) 10:22, 4 January 2016 (EST)

I can't reproduce this. If you switch to showing the day of the week, does it show the right value then? --Eupeodes (talk) 10:30, 4 January 2016 (EST)

No, it actually showed Sunday when I did that! Jiml (talk) 10:43, 4 January 2016 (EST)

Can you please tell me the operating system, browser and timezone settings you use? That might help me in troubleshooting this issue. https://geohashing.info/20160104/s/45,-122 --Eupeodes (talk) 10:46, 4 January 2016 (EST)

It happens at the W30/W29 boundary. https://geohashing.info/?lat=45&lon=-31 MacOS X, Firefox, PST (UTC-8) Jiml (talk) 10:49, 4 January 2016 (EST)

A shift around the W30/W29 boundary is normal, East you should see a day later than west. But is seems there is some major error with handling dates, any timezone west of the GMT-line gets wrong data. Just pushed the fix into production --Eupeodes (talk) 11:04, 4 January 2016 (EST)

Thanks! Looks much better! Jiml (talk) 11:36, 4 January 2016 (EST)

Date parameter bug

This example - https://geohashing.info/?date=2016-01-02&lat=51.5&lon=1.5 - should load Jan 02 but it loads today's date. --Sourcerer (talk) 11:44, 5 January 2016 (EST)

Indeed, changed something in preparation for storing settings in a cookie which broke the data parameter. Fixed it now. --Eupeodes (talk) 11:59, 5 January 2016 (EST)

Geohashing day 2008

The coordinates on geohashing.info seem to be wrong for 2008-05-21 52 0. Yet more work for you! Sorry. --Sourcerer (talk) 15:41, 17 January 2016 (EST)

Thanks for the report, something went wrong before 2008-05-27 (the start of the W30 rule). I have fixed it, but browser side caching might be a problem now. So to see the proper data you need to clear your cache. I will add a notice about this to the site tomorrow.--Eupeodes (talk) 16:43, 17 January 2016 (EST)

Saved Settings and URL Parameters

I'm wondering if parameters passed in the URL should take precedence over saved settings. After I saved my settings, the URL parameters stopped working until I cleared the saved ones.

I've started dabbling with my own calculator at User:Sourcerer/KML tool. I seem to be replicating most of the bugs you've had and creating a few new ones of my own. All quite interesting. --Sourcerer (talk) 16:14, 20 January 2016 (EST)

Url params should take precedence. And the code suggest they do. Here url parameters do take precedence. Can you give an example url which fails in combination with the saved settings? --Eupeodes (talk) 16:28, 20 January 2016 (EST)

• First I loaded up 52, 1 and saved my settings.
• Next I loaded up 52, 11 but it did not show Magdeburg. The view was still at 52, 1.
• Finally I deleted the cookie and refreshed 52, 11. It now shows Magdeburg.

I don't think the particular settings are important. I tried a couple of combinations and they all showed this behaviour. I hope this is clear. --Sourcerer (talk) 17:55, 20 January 2016 (EST)

The specific numbers indeed did not matter, but I found what is going on. Will take some time to fix, so I hope I can fix this misbehaviour of the website tonight. You can follow the status of this issue on https://github.com/Eupeodes/gh/issues/8 --Eupeodes (talk) 02:49, 21 January 2016 (EST)

Solved --Eupeodes (talk) 11:13, 21 January 2016 (EST)