Reporter@ - Could you please provide a manual repro steps to test this issue from Chrome_TE end. 

Thanks for the report!  I assume that you mean using the arrow keys when focused in the lat/long inputs in the Sensors drawer has a larger step size (1) than you want.

The step size of 1 might be appropriate for some use cases and not others, depending on the scale you are interested in.  Perhaps a better way to suit any scale is to have a small map in the Sensors drawer that could be panned and zoomed?  I'd like to know if this would suit your use case, and if this ticket receives more stars.

Yes! A Map would be amazing to have! Also ability to upload a GPX file to simulate movement and speed would be awesome++! 

Step size of 1 is too large for many cases. For example this is San Francisco 37.7567005,-122.431078. Moving lng by one, changes the map to near Santa Rosa! Usually people don't want to move the location that much. 

It sounds like you're using the increment/decrement to simulate movement. Are you using it in tandem with navigator.geolocation.watchPosition (or something else that periodically requests the user position)?

It seems reasonable to make the lat/lng step something smaller, like 0.001 (which, according to http://www.movable-type.co.uk/scripts/latlong.html is roughly 10m at the equator), if it's being used to simulate walking/biking/driving. We probably want the step to roughly match the granularity of what the Geolocation API gives us (so, if watchPosition would only give you an updated location every km, we would probably limit the step to 0.01). @luoe: Is this something you could look into?

I really like the idea of using a GPX file or a map to simulate movement, but adding (non-manual) movement simulation to the Sensor panel would push this into Feature Request territory. Maybe we could split that off into a separate bug?

Agreed, if most use cases of geo API are walking/biking/driving, we can reduce the default step.  For larger-step use cases, say emulating a satellite movement or Santa tracker, we could support that with Ctrl-up/down.

In the Elements panel sidebar, we actually have different steps for:
Ctrl-up/down: 100
Shift-up/down: 10
None-up/down: 1
Alt-up/down: 0.1

Let's have a similar treatment here.

Also, I created a separate bug for the movement simulation request
https://bugs.chromium.org/p/chromium/issues/detail?id=639392

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/82b72ec0ba6fd4c3f93634993833aa0c5eac0b65

commit 82b72ec0ba6fd4c3f93634993833aa0c5eac0b65
Author: Erik Luo <luoe@chromium.org>
Date: Fri Jan 19 23:49:14 2018

DevTools: enable Alt/Shift/Ctrl scaling for more numeric inputs

In StylesSidebarPane, you can press Arrow keys to increment a numeric value.
Holding Alt/Shift/Ctrl can affect the delta by 0.1/10/100

This CL
- Brings the same ability to 2 clients of UI.bindInput(): Latitude/longitude in
  Sensors and width/height in Device Mode
- Gives Latitude/longitude smaller step sizes of 0.01/1/10.

Bug:  637897 
Change-Id: I3844280a71449ab5021c9aadee9313cb626379b6
Reviewed-on: https://chromium-review.googlesource.com/818535
Reviewed-by: Joel Einbinder <einbinder@chromium.org>
Reviewed-by: Andrey Lushnikov <lushnikov@chromium.org>
Commit-Queue: Erik Luo <luoe@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530662}
[modify] https://crrev.com/82b72ec0ba6fd4c3f93634993833aa0c5eac0b65/third_party/WebKit/Source/devtools/front_end/emulation/SensorsView.js
[modify] https://crrev.com/82b72ec0ba6fd4c3f93634993833aa0c5eac0b65/third_party/WebKit/Source/devtools/front_end/ui/UIUtils.js