On 28/07/09 11:33, Ævar Arnfjörð Bjarmason wrote: > On Tue, Jul 28, 2009 at 9:04 AM, René Affourtit<raffour...@gmail.com> wrote: > > * All the data is losslessly inserted into the database > > This means that we can get waypoint/segment/time/ele/whatever data out > again. It would probably be simplest to do this by having additional > tables equivalent to the node/way tables where a GPX trkseg would be a > way, waypoints nodes and so on.
Track segment information is already preserved, as is elevation data even though we never use it (one day I'll get around to removing it...). > * The data is versioned, and anyone can edit it > > I have a lot of GPX tracks that could be improved, e.g. by deleting > point clouds. I'd like to edit them using normal OSM tools, have those > edits versioned (so they can be rolled back), and have other users do > those fixes for me. Just like with the OSM data I upload. GPS data is one of our fundamental pieces of evidence that we've surveyed things - is that really compatible with allowing people to edit it? Does "editing" the GPS data really make any sense at all? Maybe deletion of points makes sense, but I can't see that changing a point in any way should ever be allowed. > * Users can download GPX traces: > > ** As a point cloud within a bbox > > Like now. > > ** As "all tracks within bbox" > > So that tracks can be distinguished (and hidden) and their metadata > read& edited. > > ** Using other methods > > E.g. "all tracks by user" Bearing in mind of course the privacy issues, at least with regard to legacy traces, including the question of privacy dilution if you make additional information available about the legacy public traces. > Then, instead of deleting traces they (or their segments/points) could > simply be tagged indicating their subjective quality using a free-form > tagging system. You could then just set your editor to ignore those > traces. > > Free-form tags could obviously be used for other purposes, e.g. > marking the trace as surveyed with a given GPS model. Traces already have free form tags which can be edited, although currently only by the person that uploaded them. > Implementing this would require new tables in the database, optional > changes to all editors (since they could keep using /trackpoints), and > new database tables to track GPX data and its history. Does it really need any new tables? I can't see why, unless you really want to pull track segments out into a separate table? What would be in there though other that the track ID and track segment ID - does a GPX file contain any information other than that about a segment? Waypoints is the other things I guess. I have considered adding them in the past but never quite got around to it. There was a historic argument against adding them but I think that can largely be ignored to be honest. > How does this sound? I'm pretty happy with the 0.6 API except for the > GPS bits. I'd like to make GPX a first-class object in OSM and would > be willing to hack the rails port to make that happen (when I have > time). Is anyone else interested in being able to do what I've > described above? The API code is the easy bit - the performance and disk space issues will be the hard problems to solve. If we dropped the (unused and largely useless) elevation field from the points table and added a deleted flag that would keep the disk usage basically stable. The "start point" in the trace table, which isn't very useful, could be replaced by a bounding box to allow bbox queries - that's something that I have been thinking about doing for a while. Performance issues will mainly come into play if you want to do anything that requires cross-checking the point cloud against the trace list to determine what user owns it and/or whether it is public or not. Tom -- Tom Hughes (t...@compton.nu) http://www.compton.nu/ _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk