Anyone have experience using this technology?
i.e. field verifications of structures where you need to capture the lat / long of a house that is 1000 feet from the road with limited access.
[GIS] GPS capable rangefinders or cameras that can capture lat / long data from a distance
gps
Related Solutions
This is a fascinating problem where a little analysis can be most revealing.
First consider the effects of elevation. When a mapped unit distance is traversed, and the elevation changes by an amount dz (which for ground-based vehicles is always small compared to the map distance), then the actual distance traversed is very close to sqrt(1 + dz^2). (This would be perfectly accurate when the motion is made perfectly in a straight line. For actual motions over short distances that's usually a good approximation.) Because dz is presumed small, dz^2 is very small and dz^4 is incredibly small. This allows us to approximate the square root by 1 + dz^2/2, because the error made is proportional to dz^4.
Let's run some numbers to get a handle on the sizes of these errors. To make computation easy, choose our units of distance so that the vehicle traverses one unit between each GPS reading. Over the course of n readings, the mapped distance totals n*1 = n and neglects the additional distance from the elevation changes totaling about n * dz^2 / 2. How big might that be? Because dz determines the slope, the error depends on typical slopes. Approximately, a slope of t degrees translates into a value of dz of about t/60. The error relative to the mapped distance therefore equals (approximately)
(n * (t/60)^2 / 2) / n = t^2 / 7200.
For instance, for typical slopes of t = 10 degrees (fairly steep for most vehicles), the relative error equals 10^2 / 7200 = 1/72 = 1.5%.
Notice that this error should be thought of as negative: calculations from the mapped GPS coordinates would underestimate the true distance by this amount.
A similar analysis shows how one could correct a GPS reading based on an appropriate average of slopes encountered during a trip.
What about the other source of error, the measurement error in the GPS itself? This can be thought of as a random "drift" in the discrepancy between the observed GPS coordinates (X,Y) and the correct coordinates (x,y). The drift is a usually manifest as a gradual change in (X-x, Y-y) over time. It does indeed introduce some error, but it usually is not as great as one would think. In an answer at https://stats.stackexchange.com/a/2497, I report a typical 0.5% overestimate of total trip length. It would be difficult to produce an error that not only cancels out the negative error due to ignoring elevation, but also adds 3-5%.
These errors typically do not depend on duration of travel, but they do depend on the route. Normally, though, as a route becomes more tortuous, the GPS readings tend to replace "wiggles" with line segments, once more underestimating the distance. Again it is difficult to see how the GPS could be introducing a net 3-5% overestimate. Several possible alternative explanations are:
The GPS may be subject to unusually erratic conditions, such as those that might be faced by a unit traveling deep within urban clutter.
The distance believed to be correct might actually be incorrect. (For example, a car's tires can wear by 3% - 5% of their diameter during their usable lifetimes, resulting in a 3 - 5% increase in odometer readings. If the odometer is calibrated for a new fully inflated tire but the car is run on worn partly inflated tires to measure a route, it conceivably could overestimate the distance by 5% or more.)
The "correct" distances may have been calculated on a map using a projection with substantial scale error.
In my answer here I use a query to create points along lines with a distinct distance
WITH line AS
(SELECT
your_polylinestring_id,
(ST_Dump(geom)).geom AS geom
FROM your_polylinestring_table),
linemeasure AS
(SELECT
ST_AddMeasure(line.geom, 0, ST_Length(line.geom)) AS linem,
generate_series(0, ST_Length(line.geom)::int, 10) AS i
FROM line),
geometries AS (
SELECT
i,
(ST_Dump(ST_GeometryN(ST_LocateAlong(linem, i), 1))).geom AS geom
FROM linemeasure)
SELECT
i,
ST_SetSRID(ST_MakePoint(ST_X(geom), ST_Y(geom)), 31468) AS geom
FROM geometries
So, obviously you are using a PostGIS/PostgreSQL database, You can import OSM data (with osm2pgsql, osmosis, etc.).
Important is an unique ID. You can use the osm_id coming along when you import the OSM data.
When you have data in geojson format you can use the postgis function ST_GeomFromGeoJSON. Another way: Here is a howTo to convert geojson data to a shapefile. The shapefile you can easily import to postgres/postgis with gdal/ogr, pgadmin or QGIS.
After that you can export your point data as GPX with ogr2ogr. The comments for this GIS SE answer have some useful Information.
ogr2ogr -f GPX points.gpx PG:'host=server user=username dbname=database'
Best Answer
Actually a pretty simplistic application of offset that was implemented early in the commercial GPS era by Trimble and Laser Atlanta.
Check out Laser Atlanta's "Advantage" line, or LTI's TruePulse line. The resulting az/elev/slope distance string provides "offset" from the GPS position collected at the laser head. Using offset the sample point position can be calculated in near real time with a hand held data logger. Or, the "offset" and GPS position can be combined and corrected after collection for more precise results.
Trimble's Pathfinder Office and TerraSync software packages excel at this processing flow.