Nick Whitelegg wrote:
>
> While recognising the problem of duplicate tracks I would like to defend
> the 'offline' approach a little.... from a usability point of view I much
> prefer the idea of a 'one pot' program to do all the following:
>
> - read GPS track data
> - allow the user to create segments from the GPS track points
> - upload the data to OSM
> - live edit OSM
>
> This method still guards against 'dodgy' tracks, as the user has to create
> the segments from the raw GPS data. By the same token, it saves the user
> having to use several pieces of software to grab data from the GPS, upload
> to OSM, and edit.
>
There is no mention there of downloading from OSM before editing or
uploading. I still think that this is misguided, and that any defence of
an offline method must also address conflict resolution and versioning.
For an extreme example of what the map would look like under this kind of
scheme, take a look at the poster Steve and I made from raw GPS data.
Erroneous/extreme jumps aside, which of the 203 journeys down Oxford
Street is best, and how do you choose automatically?
> The method could indeed be extended to automatic conversion of a GPS
> track
> to nodes and segments, as the editor could allow the user to filter out
> 'dodgy' points.
>
Again, what happens when an area is being edited by more than one person
at one time?
I've already said - the automated inclusion of 'dodgy points' isn't really
the issue. They can be filtered out. The problem is that (with luck, in
the future) there might be more than one person committing edits to the
same place - how do you propose to deal with this if you've been editing
offline for a significant period of time? At the moment, the online
(applet) method deals with this by restricting the editing process to
small areas, and requiring you to refresh the live data when you move
around. Conflicts can still occur, but they will likely be less drastic.
Tom.
|
