OpenStreetMap
Cambridge is not that bad, but it's a while away from lint-free. One problem in the area is the use of tracks=n on railways, which causes a lint warning to appear as the tracks key is inactive and has been abandoned; I'm considering removing the offending key--and if anyone has any objections to such an action, you know where to message me.
Discussion
Comment from SK53 on 12 October 2009 at 20:16
tracks=* is used over 4500 times in Europe, so I think describing it as abandoned is a little harsh. It is very useful when it is too difficult or time consuming to map multi-track railway lines, and conversely tracks=1 removes any ambiguity for single track lines which have been surveyed in detail. For instance I am have recently been using it for lines of tramway where I have not split the tracks (necessary for getting tram stop access right.
Comment from RichardB on 12 October 2009 at 20:28
Don't remove information just because "lint" warnings appear. To be honest, any key may be used - the lint renderers should probably be updated to add tracks=x as a commonly used tag, and in this case it clearly adds extra information
Comment from Kevin Steinhardt on 12 October 2009 at 20:30
To be honest, should have checked Tagwatch beforehand. Someone rewrite the code for the lint engine, please. (I've had enough lint for today)
Comment from Kevin Steinhardt on 12 October 2009 at 20:31
Bene re: @SK53: I wasn't describing it as abandoned; osm.wiki/Proposed_features/tracks was.
Comment from davespod on 13 October 2009 at 08:21
I am concerned about this so-called "de-linting". You seem to be removing useful information other mappers have recorded. For example, here you have removed the "sport" tag, listing the sports that take place at a sports_centre:
osm.org/browse/way/4196931/history
The Maplint layer is supposed to be a tool for spotting _potential_ problems. The map will never be "lint-free".
By all means tidy up, but please do not remove information from the map, that other mappers have worked hard to collect, and may be of use to someone.
Also, where you are adding road names to roads that look like spurs (not sure if that is the right term here) to residential roads, are you actually surveying these on the ground? It is not uncommon for such roads to have different names to the roads they feed off, and it may simply be that the original mapper had a road name missing from their notes and did not get round to resurveying, so entering the same name as the road they feed off may be wrong, unless you check the situation on the ground. For example:
osm.org/browse/way/3875464/history
Comment from Andy Allan on 13 October 2009 at 09:44
osm.wiki/Good_practice says "Don't remove tags that you don't understand". That applies equally well to the warnings from validators - just because they don't understand the tags, doesn't mean they are wrong!
Comment from Kevin Steinhardt on 13 October 2009 at 09:55
Alright; put your Shift key away. As a perfectionist, faults like the ones you've all described are something I have a severe problem with and I will try and control my eradication habits. As for references, all my edits can and have been proved from reliable sources: whether
that be from some vent of open data or local knowledge that is rather large to fit in that
little box. If you all want to continue to row over who's done what and this and that, that's fine but I'm just here to deploy my knowledge and help out with creating an open map that'll still be relevant in decades to come--and I do hope it is still there. Rights of way don't just disappear, unless the County close them that is
Comment from Kevin Steinhardt on 13 October 2009 at 13:22
@SK53 and @RichardB: the only people of which the tracks=* information is useful to is people like Network Rail or the TOCs; personally, I don't think they'll be using OSM any time soon.
@davespod: not meaning to be a pessimist about the whole map, but do you really think someone's going to want to find not only a sports centre that they've never been to (e.g. searching for it directly, which will never be implemented) but a specific sport taking place at that amenity. Hey; I'm in the mood for some tennis in this alien city. Let's search the map to find something near me. I'm just in a real mood to play tennis.
And what I mean by searching directly is that I can go, for instance, to the search box and find something scarily specific. I always wanted to have something like coffee=*, where * is replaced by the cost of a standard takeaway mug of filter coffee or something. One could then write an iPhone app that finds your location, queries the database and finds you the cheapest coffee nearabouts. Obviously, this would be unfeasible to implement: the fluctuating price of coffee is but one factor.
Comment from davespod on 13 October 2009 at 13:24
I have obviously caused offence, and that was not my intention, so apologies for that. I certainly have no intention of having a row. I was simply providing some examples of what I was concerned about.
I am glad your edits to road name are based on reliable non-copyright sources. I was not trying to suggest they were not. I asked the question simply because it can be tempting to assume that when a road, with a missing name tag, appears to be a spur of another road that it has the same name, which is not always the case. I am glad that is not the case here.
I am not sure what you mean by a fault in this context. Along with many, many mappers (including those who have made a much bigger contribution than my piddling efforts), I do not regard Map Features as exhaustive, nor necessarily as prescriptive. However, even putting that aside, the "sport" tag I referred to is documented there. The only issue I could see with the particular instance I referred to was using commas instead of semi-colons to delimit the values. So, if you want to clean up the data, why not just change them to semi-colons instead of deleting the whole tag and losing the information someone has gone to the effort of collecting?
I am not trying to belittle your efforts to improve the map or the data. I welcome all genuine efforts to make OSM better, including yours. I just don't want anyone else's efforts to go to waste (unless there is a really good reason).
Comment from Kevin Steinhardt on 13 October 2009 at 13:30
To be honest, I got rid of that tag because I didn't know what to do with 'indoor hall'. Yeah; I'm a bit weird like that. I know it's the wrong attitude, but if something can't be corrected it shouldn't be there. (general rule across life)
Comment from daveemtb on 13 October 2009 at 19:55
Interesting perspective. Can I make a small request? That you don't go deleting data I've entered because you believe it isn't correct in some way but you can't think of a way to correct it?
I'm not a fan of meaningless mess being entered into the database, but I can easily imagine searching for all the places to play tennis (or actually, for me, something much more obscure, model aircraft flying) in a new town when I move there. Please don't delete meaningful data just because you can't imagine someone using it.
It is widely stated on the wiki that OSM is not to be restricted to map features only, and people can add data that isn't there. While I don't like the inconsistent data this produces, it allows people to map things that no-ones agreed a tagging scheme for, and that's useful. With the tagwatch facilities we have, hopefully things will become more consistent in time.
Lastly, all the validators have serious flaws in them. Please don't change data that makes perfect sense just because a validator like lint doesn't like it. As an example, the JOSM validator complained about tertiary roads with no reference recently. In the UK most tertiary roads do not have any publically available reference. That doesn't means someone should go change them to unclassified.
Comment from Kevin Steinhardt on 13 October 2009 at 20:15
Don't get me started on JOSM. No plugin works, whatsoever; my Mac refuses to let it use plugins. I wouldn't mind having the wmsplugin (correct; yeah?) but I can't. As for inconsistency, I thought we had a tag proposal scheme in place for new tags; I wonder why we don't have a problem with things like plurals, as is a problem in other folksonomy projects.
Comment from Bobkare on 23 October 2009 at 10:35
Hi
As the author of the not-in-map_features check in maplint I just want to say I'm horrified anybody would consider it an error that some tag trips it.
It's meant to be a _NOTICE_ that something _MIGHT_ be weirdly tagged (the main usecase is actually things like higwey=residentiel which obviously should be corrected...)
Yes, there should be a better source of data for this, but that doesn't exist yet. If you want to fix this you're welcome to have a shot, but don't vandalise the data in the mean time just because the validator isn't perfect.