The difficulty with this approach is people keep adding data. Which is fine if its high quality but where people are doing tracing on lower quality data you end up with a mess. I think you have to accept that with the OSM approach the data will be of variable quality. Even users with WAAS GPS devices may not realise that WAAS enabled is not the default. As the numbers grow so it becomes more difficult to control the data quality, which is why the idea of taking the geobase data as a base is so attractive. We have the old OSM data available so my preferred approach would be to pull in the geobase data then add in any gps traces and other tags that exist in the OSM datasets over time.
The original OSM Charlemagne was so far off that in parts the geobase Charlemagne was imported. One end was at least a hundred meters off. I've done a clean up based on local knowledge but really it could do with a couple of GPS tracks down all the roads to verify their positions but that again can be done over time and at least its better quality now than it was. My thoughts would be import as quickly as possible then clean up afterwards. That way you avoid helpful users adding more lower quality data in. Perhaps some sort of tag could be added to a road saying verified so that a search could be done for unverified roads close to a geobase import. I don't think there is a perfect answer accepting there is a desire to use existing data that people have spent time inputting. It is difficult telling people we've decided to scrap the bit you spent time inputting. Cheerio John 2009/10/25 Frank Steggink <stegg...@steggink.org>: > Hi John, > > I personally think it would be better to do the cleanup immediately after > the import, or possible during the import. Of course it is very tedious to > do so, and it will slow down the import, but the person who is doing the > import, knows best which roads were omitted. The goal is not to import as > fast as possible (it's not a match), but to get high quality data. > > Here is the process I have done so far. When using the process with > RoadMatcher, I made sure that only missing roads are imported. Since > RoadMatcher isn't working perfectly, I added or removed some features which > should be imported. Then I uploaded the data, and after the upload, I > downloaded the area again, and made the connections. > > Yesterday and today I happened to have imported a few sheets, where I > haven't used RoadMatcher, because it isn't working terribly well. What I > have done is basically Sam's more recent suggestion, to convert the Geobase > data to separate OSM files, and copy the features over which should be > imported. When doing that I made the connections immediately, using the > validator tools in JOSM to ensure that I haven't forgotten anything. > > It is slow, but after a while you get used to it, and you're able to make > more progress. So far, in nearly all of the cases I just extended / > shortened the Geobase segments, because the deviations weren't that big. It > didn't warrant the introduction of new segments, and it is also inevitable > that Geobase data would never be edited by a different person. > > By the way, a tool that is useful, and which now has worldwide coverage is > KeepRight: [1]. It also detects missing intersections / overlapping roads, > and even stuff like one-way dead ends. There are many different checks, > which will all help us improving the data in OpenStreetMap. > > Frank > > [1] http://keepright.ipax.at/ > > John Whelan wrote: >> >> I found both James's and Sam's comments very useful. It gives me a much >> clearer idea of what you are trying to do and the limitations involved. It >> would appear that we have the ability to identify roads omitted from the >> geobase import which means at some point in time given enough resources a >> clean up could be done. Until then as you say areas where one road is >> already in OSM that have a number of residential roads connected to it can >> be cleaned up on an if spotted basis. So be it. >> >> Thanks >> >> Cheerio John >> >> >> >> Adam Dunn wrote: >>> >>> In JOSM, another way to quickly add on to a way like that is to use the >>> select tool to select the way you will be adding on to, holding the shift >>> (or control) key, selecting the last node in the way, then use the draw >>> (add) tool to continue drawing the way. By default, in JOSM, if you have a >>> node selected that only belongs to one way, and you start using the draw >>> tool, that way will be extended, including tags. However, if a node belongs >>> to multiple ways (an intersection), then a brand new way will be created >>> (since it doesn't know which of the ways to extend), and you have to do a >>> combine operation. So selecting a node and a way together tells JOSM which >>> of the ways you want to extend. >>> >>> To copy tags from one way to another, you can use the "paste tags" >>> operation. Select the way to take the tags from, and use the copy operation >>> (ctrl-c). At this point you have the choice of pasting the entire way >>> (ctrl-v), or just pasting the tags (ctrl-shift-v) into an existing way. When >>> you paste tags it will overwrite tags with new values if they already exist, >>> but will leave tags intact if there is no new tag value coming in (there is >>> no dialog to merge, at least on version 2300). One unfortunate aspect of >>> doing this with GeoBase is that GeoBase assigns a new uuid to a way >>> separated by an intersection (ie. a road will be split into separate ways >>> ever time there is an intersection, and each of those ways gets a unique >>> uuid) >>> >>> >> I've learnt over the years with databases that some idiot somewhere >>> >> will invariably want to use a tag like this and not realise that some >>> >> roads >>> >> don't have a value. >>> >>> If "some idiot" is using the OSM data in a manner that assumes some tag >>> exists, then they won't get very far at all. OSM allows anyone to use >>> whatever tags they want, by allowing any combination of keys and values. All >>> tags that are used in OSM are merely *suggestions* and are not mandatory. It >>> would be foolish to assume even the simple such as highway=tertiary will >>> exist on tertiary roads. Having said that, it would be nice to have as much >>> information as possible taken in from government sources. That is why Sam V >>> is advocating making .osm files available for people to obtain, so that >>> people without postgis/sql/roadmatcher experience can still use josm to copy >>> over the stuff that they want. There has been much discussion on how to make >>> this as automatic as possible, but uuid can only do so much.... Anybody can >>> get their hands on the GeoBase data and start copying tags over if they >>> want. The Roadmatcher Excluded files listed in the import spreadsheet >>> represent the roads that were already existing in OSM. >>> >>> It looks like James beat me to the reply, but hopefully this also helps. >>> >>> Adam >>> >>> On Sun, Oct 25, 2009 at 12:51 PM, john whelan <jwhelan0...@gmail.com >>> <mailto:jwhelan0...@gmail.com>> wrote: >>> >>> Looks like I can do an extend and combine in JOSM. >>> >>> Thanks John >>> >>> >>> > On the clean up side is there an easy way to copy the tags on >>> one section of >>> > road onto another? For example when I extend a geobase road up >>> to the old >>> > OSM road I'd like to have the same tags as the other sections >>> of the road. >>> > At a quick glance I can see at least seven sections that need >>> to be added >>> > back in within 600 meters. >>> >>> _______________________________________________ >>> Talk-ca mailing list >>> talk...@openstreetmap.org <mailto:Talk-ca@openstreetmap.org> >>> http://lists.openstreetmap.org/listinfo/talk-ca >>> >>> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Talk-ca mailing list >> Talk-ca@openstreetmap.org >> http://lists.openstreetmap.org/listinfo/talk-ca >> > > _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
