Android Question How to draw a GPS Route WHITOUT a maps app

[ivan.tellez]

I´m looking at measuring some small routes using GPS, the longest one is like 650 meters, this routes can have several corners. The idea is to have the GPS on and walk the path, click a button on each corner and calc the distances beetween those points. This is already working.

Has anyone drawn GPS data on a canvas? Is there a library or some example code to draw the route scaled to use all the canvas.

Concept:

Thanks

 

[BlueVision]

Hmm...
First thought when I saw the graphic: Looks a bit like "TURTLE", an almost forgotten programming language.
How would I solve the problem? Why always click when you turn? Just write a time log (every 5 seconds?) of the path, measure the distance, the bearing values of the GPS should be enough for the direction information.
The other problem is drawing the path:
- The complete path must be calculated beforehand
- then adjust the scale
- Draw the path on the display using the stored data.
How the drawing is then implemented in detail, there are also several possibilities and approaches. I do not know of a special library for this. I think that is less of a problem than scaling the entire path correctly, which will be the biggest problem. The prerequisite for this is that a corresponding map (I assume this is below) is scaled in such a way that it corresponds in some way with the display dimensions. Then it should be easier to convert the measured distances and trace the path. If this map is "scrollable", this will make things easier.

Somehow I remember a GPS code example by Klaus, in my opinion there was also a map underneath and the distance travelled could be mapped on it.

Have a look here.

This may not necessarily help with your problem, but it may give you an idea of how to solve it programmatically.

 

[BlueVision]

If you want to measure distances and curves you must use an external provider such as:
Googlemaps

I hope I have not completely missed the point and have perhaps not understood something correctly. But in this case I would like to disagree with all due respect. An external provider is not necessary. The pure distance calculation and the calculation of curves can be done with the collected GPS values. Depending on the speed of movement and the measurement rate, one can calculate very accurately.
Of course, the situation is different if you want to relate this data to a map. Of course, Google Maps is then a good choice.

 

[ivan.tellez]

polylines

Sample:

Thanks, but please read the requierements first. This has to be drawn in a canvas and WITHOUT using any "maps" application.

GpsLastLocation.DistanceTo

Again, in the description says that the data capture and distance measurement is already working. (among other reasons, This has to work in an OFF LINE.)

Why always click when you turn? Just write a time log (every 5 seconds?)

Precision, intervals or complex calculations with the bearing, can loose a couple meters each turn, for this app tha is not a good trade for a couple of taps on the screen.

I hope I have not completely missed the point and have perhaps not understood something correctly.

No, it is a good recap, calculating the bounding box of the coordinates set, scale the canvas and draw the llines, you are right, this can be done without the need of external apps or APIs, pure math, that is where Im looking help for.

 

[emexes]

you are right, this can be done without the need of external apps or APIs, pure math, that is where Im looking help for.

Without the need of:
- external apps... tick
- APIs... tick
- pure math... you'll be needing some math, but it's pretty simple stuff

Because you're walking and thus only covering a small distance ("longest one is like 650 meters") then the purest (hardest?) math you'll need is:

one degree of latitude in meters = 40000 km circumference of earth * 1000 meters per km / 360 degrees
one degree of longitude in meters = one degree of latitude in meters * Cos(latitude)

With those two values, you can convert longitude and latitude into meters.

Your GPS API should already be returning decimal degrees ie NOT degrees minutes seconds or degrees decimal_minutes = you can just subtract the numbers to get the "amount" of degrees between two points.

Which reminds me: the other math you'll need is Pythagorus, which is the distance between two points (lat1, lon1) - (lat2, lon2) is calculated by:

40e6 = 40 million = 40000 km circumference of earth * 1000 to convert km to meters

latitude_distance = (lat2 - lat1) * (40e6 / 360) meters
longitude_distance = (lon2 - lon1) * (40e6 / 360) * Cos(lat1) meters '( lat1 and lat2 close enough that will make only a miniscule difference )

distance = Sqrt( latitude_distance ^ 2 + longitude_distance ^ 2) meters

 

[BlueVision]

I agree. The problem is how to interpolate the data that lies between the measuring points but is missing from the measuring protocol. I think a curve interpolation is a very bad choice. Just as well (purely theoretically) the next measuring point could have been generated after completely circling the earth at the speed of light, if the distance between the measurements is large enough.
This is comparable to an MP3 file. The lower the resolution (sampling rate), the more the MP3 file deviates from the actual original. The problem of the digital world. How accurate is accurate? Or how accurate does it have to be to be exact?
Or let's assume that the path takes a slight diversions. A watercourse blocks the way. The last measurement was before the watercourse, the follow-up measurement is on the other bank after crossing a small bridge. This diversions will not be recorded in the measurement protocol. It cannot be interpolated either. Only when the data are then projected onto a map does this problem become apparent...
From this point of view, the interpolation of a distance between two points and the generation of a possible route is even more erroneous than the "rubber band method", which connects these two points directly and by the shortest route.

Of course, this is all highly theoretical. The solution to the problem is perhaps also due to the somewhat diffuse task. If this is defined a little more precisely, then we are no longer beating around the bush here.

As I said, how precise is precise and what do you need this kind of path measurement for? Then we can certainly agree on a functioning procedure that produces satisfactory results and comes very close to reality.

What is the purpose of the task at hand?

 

[emexes]

how to interpolate the data that lies between the measuring points but is missing from the measuring protocol

GPS readings are usually at least one-per-second, so treating the path as a collection of one-second-long straight line segments should be close enough.

The original post talked of clicking a button to mark each corner, and the diagram shows straight-line segments, so the talk of interpolation and curves is probably moot.

Phone GPS is accurate to +/- 1 meter if you're lucky.

 

[emexes]

Has anyone drawn GPS data on a canvas?

The usual "old school" way was to have a scan of your map as a raster image eg tiff, gif, jpeg, and know the (latitude, longitude) coordinates of the four corner points. Then it becomes a simple interpolation to convert (latitude, longitude) into image/canvas (x, y).

Is there a library or some example code to draw the route scaled to use all the canvas.

The way I'd do it is:

- convert all the (latitude, longitude) points into (x meters, y meters)
+++ best use Double; single precision Float is probably not precise enough
+++ note that traditionally latitude ("vertical") is given before longitude, but x ("horizontal") is given before y
- find the minimum and maximum x and y values
- difference those to find the x and y ranges
- calculate the meters-to-pixels scale by:

x_scale = canvas_width / x_range
y_scale = canvas_height / y_range

scale = minimum of x_scale and y_scale    'same scale for x and y is usually a good thing  ?

and then your canvas pixel coordinates are:

x = (longitude converted to x meters - minimum x meters) * scale
y = (latitude converted to y meters - minimum y meters) * scale

 

[TILogistic]

Something simple, needs to be completed.

Public Sub CoordenateToPixels(Lat As Double, Lng As Double, Width As Int, Height As Int) As Object
    Dim x As Float = (Lng + 180) * (Width / 360)
    Dim y As Float = (Height / 2) - (Width * Logarithm(Tan((cPI / 4) + ((Lat * cPI / 180) / 2)),cE) / (2 * cPI))
    Return Array As Double(x, y)
End Sub

 

[William Lancee]

If you have 2 points (in pixels), you can draw the arrows on canvas using this class
https://www.b4x.com/android/forum/t...vas-many-types-of-arrows-at-any-angle.142539/

 

[amorosik]

GPS readings are usually at least one-per-second, so treating the path as a collection of one-second-long straight line segments should be close enough.

The original post talked of clicking a button to mark each corner, and the diagram shows straight-line segments, so the talk of interpolation and curves is probably moot.

Phone GPS is accurate to +/- 1 meter if you're lucky.

Ehhh, you're a little too optimistic
My experience says that a few tens of meters is a better approximation
The meter is approached only with telephones with dual frequency GPS receivers and there are very few

 

[emexes]

Phone GPS is accurate to +/- 1 meter if you're lucky.

Ehhh, you're a little too optimistic
My experience says that a few tens of meters is a better approximation
The meter is approached only with telephones with dual frequency GPS receivers and there are very few

I did say: if you're lucky.

Tens of meters is pretty unlucky, though.

Outside, not moving, with a clear view of the sky, no cloud, and well away from radio reflectors and interference, a decent phone GPS does a remarkable job of working out where it is relative to satellites 20000 km away travelling at 4 km/sec.

I tried it just now with my trusty 2012 iPhone 4s, and got this:



when I stood with the phone directly under the pointy bit of the roof nearest the blue dot, with my back to the house. So with a quarter of the sky blocked by the roof, a metal fence to bounce radio waves about, trees on the fence line and an overcast sky, it's... I just measured 2.8 metres from the pointy bit to the east fence, and the blue dot's perhaps 60% of that, so we're looking at the GPS being off by 1.7 metres. I don't know if that's with or without luck. I do know that I'm out of milk for coffee, so today is looking unlucky here.

The meter is approached only with telephones with dual frequency GPS receivers and there are very few

The iPhone has GPS and GLONASS, but I've never confirmed 100% whether it uses both simultaneously. Rumour was that Apple included GLONASS on the iPhone to get Russian import rules off their back. On a related note, I also heard that phones with Galileo had to initially NOT use Galileo in the US because the FCC hadn't yet dotted i's and crossed t's re: sanctioning Galileo. Bureaucrats, hey?!?! (if the story's true)

I used to use the iPhone heaps for OpenStreetMap mapping and, under the right conditions, it's been superb.

Turning off radio transmitters on the phone helps too. Phone network, WiFi network(s) and Bluetooth vs GPS lightbulb 20,000 km away - that's a bit of a one-sided battle.

 

[emexes]

Ehhh, you're a little too optimistic

You got me intrigued about what a newer phone might do.

Same location test, but with an el-cheapo $79 Nokia C01 bought early this year:



Btw the corner gazebo is no longer there.

 

[emexes]

Phone GPS is accurate to +/- 1 meter if you're lucky.

On a completely separate topic... my parents, both > 80yo, left this morning on a roadtrip around the state. I stuck a SIM in their iPad so that I have a fighting chance of being able to help them when they get lost. Last roadtrip was peppered with phone calls along the lines of: "what street are you on? ... don't know ... how about what town you're in? ... don't know, but it's got a big clock tower". Brilliant.

Now I can do this and know where they are without having to play 20 questions or bang my head against the wall:



I'm guessing they've stopped for lunch, and the east-west accuracy looks like it'd be +/- 1 meter.

 

[BlueVision]

You got me intrigued about what a newer phone might do.

More or less the same result, I am sure. You can't expect that much accuracy by cheap hardware always used in smartphones.
As said above, GPS is more or less only a thing of microseconds, clear view and reflections, amount of satellites used for triangulation and finally some math.

 

[ivan.tellez]

Ehhh, you're a little too optimistic
My experience says that a few tens of meters is a better approximation
The meter is approached only with telephones with dual frequency GPS receivers and there are very few

That is Wrong, the GPS also has an acuracy parameter, it can beas low as 1-2 meters. Depending on various factors, old phones use only 24 satellites, but newer ones had access to newer constellations many more satellites to get a fix faster and more accurate.

 

[ivan.tellez]

Anyway, for the original question. It makes no sense at all the convertion to meters. The steps are:

1. Find the bounding box. (the smallest Lat and smallest Lon in the list, the largest Lat and largest Lon in ther list).
2. Find a scaling factor to avoid distorting the image so we calculate the scaling factor for the x coordinate and the y coordinate:

ScalingFactorX = Canvas.Width / (MaximumLat - MinLat)
ScalingFactorY = Canvas.Height / (MinLon - MinLon)
ScalingToUse As Double = Min(ScalingX, ScalingY)

For longer distances or for northern/soutern locations you can use cos(latitude) as an extra Scalingfactor

3. For Each location, get the X and Y

        Dim X As Int = (Location.Latitude-MinLat) * ScalingToUse
        Dim Y As Int = (Location.Longitude)-MinLon) * ScalingToUse

4. Use the coordinates to Draw the points, Lines, labels, current position , etc.


Note: It needs a little more aritmetic to work with negative lat and Lon
Note. It needs an offset to center the path depending on which ScalingFactor was used (X or Y)

 

[TILogistic]

Anyway, for the original question. It makes no sense at all the convertion to meters. The steps are:

1. Find the bounding box. (the smallest Lat and smallest Lon in the list, the largest Lat and largest Lon in ther list).
2. Find a scaling factor to avoid distorting the image so we calculate the scaling factor for the x coordinate and the y coordinate:

ScalingFactorX = Canvas.Width / (MaximumLat - MinLat)
ScalingFactorY = Canvas.Height / (MinLon - MinLon)
ScalingToUse As Double = Min(ScalingX, ScalingY)

3. For Each location, get the X and Y

        Dim X As Int = (Location.Latitude-MinLat) * ScalingToUse
        Dim Y As Int = (Location.Longitude)-MinLon) * ScalingToUse

4. Use the coordinates to Draw the points, Lines, labels, current position , etc.


Note: It needs a little more aritmetic to work with negative lat and Lon
Note. It needs an offset to center the path depending on which ScalingFactor was used (X or Y)

I would like to see the result of your solution.

regards

 

[emexes]

I would like to see the result of your solution.

That is a trick challenge, right? ?

Spoiler

When compiling, the result would be: invalid number of parentheses
When running, the result would be: divide by zero

 

[emexes]

... the longest one is like 650 meters ... calc the distances beetween those points. ...

Anyway, for the original question. It makes no sense at all the convertion to meters.

1/ the original question spoke of meters and measuring distance, so conversion to meters seemed to make sense at that time
2/ In Spain around latitude 42°, a degree of latitude is the usual nominal ≈111,111 meters, but a degree of longitude is ≈82,572 meters, and thus distance calculation and undistorted x-y plotting are much better done in meters rather than degrees

Note: It needs a little more aritmetic to work with negative lat and Lon

In Spain it works fine. I agree that you'll run into trouble at the north and south poles, and for 0.0002% of the world's land area of three Fijian islands on the other side of the world. My thinking was to keep to a minimal pragmatic solution and away from complexity, in light of "pure math, that is where Im looking help for".

[ tbh the correction for crossing the 180° meridian isn't all that hard, so yes: maybe I should have done it anyway even though it'd probably never be used ? ]

Note. It needs an offset to center the path depending on which ScalingFactor was used (X or Y)

I agree with this too. I'd actually considered doing it pre-emptively at the time, but again: I was thinking to keep things as simple as possible. And for all I knew, you might rather adjust the size of the canvas to suit the track plot, than adjust the position of the track plot to suit the canvas, so I figured I'd leave that decision and its execution to you. ?