path measuring tool

[jrf]

Please create a path measuring tool for the general use case illustrated in the  gmapPedometer. This is useful for assessing the distance between things and for assessing alternative routes.

Features:

• a modal tool button like the existing panning-hand and drag-rectangle buttons
• when in this mode, a single click in the map places the next vertex in the path.
• while moving the mouse in this mode, a line is displayed between the most recently placed vertex and the mouse, and when the mouse leaves the map pixel extent, the line freezes in place between the most recently placed vertex and the pixel closest to the exit point. When the mouse re-enters the map pixel extent, the line jumps to the new mouse pixel location.
• double-clicking ends the path
• click-holding and dragging a vertex repositions the vertex
• some action must insert a vertex between two existing vertex. Ideally, this would be double-clicking on the line segment itself. If this is not feasible, then find some other intuitive way to "break" a line segment by inserting a vertex that the user can reposition as needed, e.g. right click on a vertex and choose "add vertex to the right" or "add vertex to the left"
• a vertex can be deleted by right-clicking on it and choosing from a menu "delete this vertex"
• a path can be deleted by right-clicking on any vertex and choosing "delete entire path"
• each vertex should have a graphically polished little marker that includes the distance in kilometers and miles from the beginning of the path up to that point
• each line segment should have a graphically polished label aligned with the line that shows the length in kilometers and miles for that one line segment
• after place one path, the user can place additional paths on the same map
• the paths stay on the map across zooms, pans, and even window refreshes (perhaps by stuffing in a cookie?)
• the paths only go away when the user closes the window

[camerons]

This email thread should help with calculating distance:  http://www.arcknowledge.com/gmane.comp.gis.mapbuilder.devel/2006-10/msg00068.html

[camerons]

Almost all of this is already coded in the vector branch - for creating a feature on a vector layer. All that is required is for the rendering of the vector to include distance calculations and markers.

[jrf]

Regarding error: off the top of my head, 5% error at 1:1000 scale seems like a good target.

Computing distance between points usually requires getting unprojected spherical coordinates, which is trivial for epsg:4326 and for layers that offer pixel-to-lon-lat methods. For layers that do not offer such a method, the path measuring tool simply won't work. That's is acceptable (to me) for this release.

Here's some python for computing the distance. I'm sure similar is generically available in javascript.

import math

earth_radius = 6372.795  # radius of the earth in kilometers

def point_point_distance(lon1, lat1, lon2, lat2):
    """compute distance from one spherical coordinate location to another; 
       input measured in degrees; output in kilometers"""
    lat1 = float(lat1) * math.pi / 180.0  # convert to radians
    lon1 = float(lon1) * math.pi / 180.0
    lat2 = float(lat2) * math.pi / 180.0
    lon2 = float(lon2) * math.pi / 180.0
    radians = 2 * math.asin(math.sqrt(math.sin((lat1 - lat2)/2)**2 + \
                                      math.cos(lat1) * math.cos(lat2) * \
                                      math.sin((lon1 - lon2)/2)**2))

    return radians * earth_radius

[openlayers]

How much would it complicate things to allow it to measure distances only from the start point? To work much as is described above, but to always draw from, and measure from, the first point clicked, instead of from the last point clicked?

There seem to me to be two primary uses for a measurement tool - accumulating distances along a route, for which the approach described would work best, and measuring distances to one or more places from a single starting location.

If we build separate controls to handle each, they'd share nearly all of their code. So maybe we want one control that can be configured to work one way or the other, or separate controls that derive from a common base, or maybe we'd do best to make them completely separate.

[crschmidt]

I'm not aware of anyone actively working on this for 2.6.

[bartvde]

Chris, Tim is implementing this in the next few weeks on a contract to one of my customers. So maybe the target could be 2.6 instead of future?

[bartvde]

See also ticket:1241