On Tuesday 01 June 2010, Peter Miller wrote: > We did have a similar discussion in-house at the design stage. We > could of course implement this and the data would then be locked away > into our systems and be hard for others to access and use for other > purposes unless we do further work to ensure that it is. We didn't > want to give any hint of an impression that we were trying to > 'privatise' knowledge about OSM and wanted to get something out fast. > > It would also ensure that the information was not available to others > using other tools unless they went to extra effort to read our files. > > I guess someone could put a monitor onto the minutely feeds to warn > about such changes and request that the change be reverted, but this > seems to be a lot more complicated. > > All in all the proposed approach ensures that this 'intelligence' is > generally available, and will be available on suitable and compatible > license to all. It is also flexible to deal with all sorts of 'mis- > information' which may have a habit of getting into the DB and can > easily be filtered out by people who which to have a more restricted > set of features.
You see, this is the way I looked at it: This way you're taking a list of OSL streets , doing a match and then entering information about the OSL database into OSM (which I'll admit has its advantages as far as data distribution goes). Among the problems will come up is the fact that you don't have _real_ 1:1 correspondence of feature -> feature. There are often many OSM ways corresponding to a single OSL entry. Even things like bridges or speed limit changes cause us to start a new way. Are we supposed to put name:not in all of them? Rather than doing that, I thought: so, let's treat the OSL database as a list. We want to be able to go through the list and for each entry we want to be able to tick it off as "Got that"/"OSL is wrong"/"Acceptable alternate spelling"/"Not appropriate to be an OSM name"/etc , ideally until we have no outstanding disagreements left. In this way, what we'd be doing is making an augmented version of the OSL database, rather than shoving this information into OSM. This is what I've been working on - http://humanleg.org.uk/code/oslmusicalchairs/oslmcscreen_20100601.png [1][2] - is what I have working at the moment. Each box is an OSL entry. . The controls on the right would include the ability to change the status of the OSL entry. I do agree that there are problems with the data being locked away on a separate server, but I thought regular published dumps would help there. After all, it's just an augmented OSL database. I could (and probably will once I get more time) get the matching algorithm to respect the :not entry, which I think is actually a really good idea for OSM in general. Lots of features have common misspellings. robert. [1] - Note the coordinate transform offset. It's just a 27700 -> 4326 srid transform, but it's not working right! Can anyone please help me with this?! [2] - Yes, it has the disadvantage of not being in the same screen as the editor, necessitating a bit of parallel panning. _______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
