Ah, I hate replying to myself. Another issue is relationship of street data to other features from Canvec. I'm pretty sure that e.g. bridges are aligned between road data and river and railroads in GeoBase. I'm also pretty sure it's not the case for a lot of current OSM data.
One other idea that applies here would be to run a "reverse" RoadMatcher - replace current data with GeoBase, and then run RoadMatcher to pick/fix up updated road segments from OSM. There you have it - consistent foundation combined with fresher OSM data done in a more automated way. Michael. On Fri, Jun 12, 2009 at 07:48:21PM -0700, Michael Barabanov (michael.baraba...@gmail.com) wrote: > There's an additional complication for adding UUIDs: different > topologies, for e.g. dual carriageways. I'm seeing a lot of cases where > OSM has a single way for a stret, but Geobase has two. So, assigning UUIDs > can not be a mechanical process. In fact, I'll argue that matching > Geobase UUIDs is similar to throwing out exising data for a way and > adding it in these cases, if not positionally, then topologically. > And intersections of dual carriageways with smaller roads make it even > more complicated - every little piece has a separate UUID. > > Speaking of quality, while positionally OSM data can even be more > accurate (I've seen a couple places already), topological-correctness > wise it does not approach GeoBase data. Duplicated nodes, overlapping > ways, crossing ways, unattached ways are all too common. For > auto-routing maps, this is a huge problem. > Same applies to naming of streets (St. vs Street and such) and road > classification. > > It's definitely possible to get to the desired state (first-hand > OSM-mapping derived data combined with systematic, UUID-enabled, QA-assured > base from > GeoBase) using the "preserve existing" approach, but really, we should > ask ourselves, what's easier and gets to this state sooner: > > 1) start fresh (streets/road-wise), enjoy correct topology and overall > consistency for the whole Canada from the start, and correct/add to > out-of-date data from GeoBase. > > 2) do a lot of, and I mean a LOT of manual fixes that often amount to > the same -- see what I started with. > > Perhaps it's too late to have this discussion (I'm pretty new to OSM, BTW), > but to me it seems very tempting to be able to have a really good map right > now, > with very little effort, and incrementally fix it subsequently. I think this > also makes the bidirectional exchange with GeoBase a lot more realistic. > > All this said, the areas I've imported all follow preserve-existing > approach (see user "mbiker"). I've also started to fix up topology, and > that's what prompted the above. > > Michael. > > On Fri, Jun 12, 2009 at 09:54:28PM -0400, Richard Degelder > (rtdegel...@gmail.com) wrote: > > William Lachance wrote: > > > > Look at this from another angle: Should we split up all the existing OSM > > road data that people have put in to add in GeoBase UUID information? > > > > The simple answer is that at some point we are going to have to. > > > > If we want to add the attributes available from GeoBase, and to be able to > > update it from future GeoBase updates, then we are going to have to find a > > way to add the GeoBase UUID information and, to do so, split the ways into > > the came segments that GeoBase uses. If we do it manually, which will be a > > lot of work, or someone develops a script to do it we are going to have to > > do it to utilize the data available from GeoBase for the map. Not doing it > > means we cannot import the GeoBase UUID an cannot benefit from the other > > attributes available within the GeoBase data which will leave us with two > > classes of roadways, those that have all of the current data available and > > those that are going to require that users manually add any additional > > details in order for them to appear. > > > > At some point we are going to have to go through the entire data set within > > Canada in OSM and look to add the GeoBase UUID and any additional data from > > GeoBase. We will not need to give attribution to GeoBase for data submitted > > from users nor the method that the GeoBase data was recorded but we will > > have to insert the GeoBase UUID for those segments. From that point those > > ways originally created by users will be handled exactly the same as every > > other segment originating from GeoBase. > > > > > > > > Michael Barabanov suggested: > > > > Let me be a devil's advocate here for a while. The 2 alternatives > > that make more sense are > > > > - Delete the existing street data and start fresh with GeoBase, and always > > maintain the UUIDs properly. Given how many inconsistencies/topology > > errors there are in OSM data for Greater Vancouver, it may just be > > the right thing to do. > > Otherwise we'll be spending months joining exising OSM data to newly > > imported segments. Not a great way to spend resources. > > > > - Don't pay attention to preserving UUIDs/segments, and re-run > > RoadMatcher when we need to import more data. > > > > What we're doing right now is neither here nor there. No benefit of > > GeoBase/UUIDs for existing OSM data and confused renderers for the > > imported GeoBase ones. > > > > Michael. > > > > I would suggest that we do neither. Although the GeoBase data is generally > > very good, frequently excellent, there are times where it is wrong or less > > than ideal. This can be for a number of reasons, many not within the > > control of GeoBase either. Where we have had good people working on OSM, > > using GPS tracks as the basis of their work, we usually also get pretty good > > quality, maybe not to the exacting quality that GeoBase has the potential to > > get. When we started the import we agreed that we would preserve the user > > generated data as much as possible. One of the guidelines for mass imports > > also is to preserve user generated data. Where the user generated data is > > faulty or wrong then we are going to replace it, in the same way that we > > would if we were manually editing the data. > > > > One of the reason that the GeoBase data may not accurately reflect what is > > really there is because it is only updated periodically. Thus new roadways, > > changes to existing roadways, and other changes are only going to be > > reflected in the GeoBase data sporadically. It takes time for the original > > data to be transferred up from the municipal level, where much of it > > originates, through the provincial level and finally into GeoBase itself and > > allow GeoBase to release a new update for the province. We want to have > > users continue to map and add to the map to keep it really up to date. > > > > Some of the data within GeoBase is also pretty old and generated from poor > > quality sources, some simular to the Yahoo! satellite imagery that we also > > have access to. If we can get a local mapper to correct the data then it > > can be better than the original GeoBase data and improve the map. I will > > frequently take good locally generated data over that from GeoBase and so I > > would be very reluctant to support the idea of wiping out locally generated > > data in favour of that from GeoBase. > > > > If, on the other hand, we ignore the preservation of the UUIDs and segments > > and instead merge them then we are going to go through a great deal of work > > every time we want t add a new feature from GeoBase. Are we going to create > > the new GeoBase compatible data set on the OSM servers, and then merge the > > data again afterwards? The history of the areas we do that in is going to > > take up far more resources than keeping the current GeoBase UUID data as > > part of the map. > > > > Richard Degelder > > > _______________________________________________ > > 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
