On 1 Jun 2010, at 20:08, Robert Scott wrote: > 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.
Great stuff. We would probably be able to work with a dump of excluded OS Locator entries in this DB however users may in the main prefer the convenience/familiarity of working directly in Potlatch or what ever rather than firing up another tool. Let us know when you start getting data into your system and we will see what we can do. There is plenty that we are not testing for. I don't believe that we check if the feature in OSM has a similar bounding box to OS Locator so only a part of the way might have the correct name. Possibly you system can help with that. We also of course completely remove the OS Locator boxes for matching entries which can be problem if one is trying to validate stuff. Fyi, we are also hoping to do a map layer showing OS Vector District data in places where is it not obsured by a buffered OSM way. This would highlight parts of the UK where there is a way in OS Vector District that is not within 8 meters of a way in OSM which might help with some additional error classes. Re multiple ways relating to bridges/speed limits I think our system will respond to a 'not' entry for any part of the bounding box for the associated OS Locator entry, however I have tended to add a 'not' entry to all relevant sections to be sure. A final point - we believe that have solved the name clipping problem on the currently deployed version. We have made the smallest text a bit bigger and have darkened some of the colours. We have not dealt with the other language issues (Gaelic etc). We may come back to that one later. Regards, Peter > > > 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 _______________________________________________ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
