Just a reminder to everyone: this is a mapping project, to produce a map. It is not a database to be filled with every conceivable piece of information that *could* be useful to someone who probably is not aware of the project whatsoever.
OpenStreetMap
Just a reminder to everyone: this is a mapping project, to produce a map. It is not a database to be filled with every conceivable piece of information that *could* be useful to someone who probably is not aware of the project whatsoever.
Discussion
Comment from lyx on 13 October 2009 at 09:58
Well, its about producing all kinds of maps actually. So everything that has a geographic location and that you (or I or whoever) want to see on a map should go into the database. The maps on the OpenStreetMap website are only a small subset of the maps created from the project data.
Comment from Minh Nguyen on 13 October 2009 at 10:25
As a point of comparison, Google Maps now has parcel data in much of the U.S. Maps aren’t just for streets these days. But out of curiosity, what type of data are you protesting against?
Comment from chillly on 13 October 2009 at 10:27
We're definitely not making *a* map. There are over a many thousands of regular contributors, with widely different reasons for contributing. The data in the database and its accessibility is what makes OSM so valuable to many people, some of whom will use the data without ever producing a map.
Comment from njd27 on 13 October 2009 at 10:40
http://c2.com/xp/YouArentGonnaNeedIt.html
Map first, create architecture only after it is clear it is needed.
Comment from Richard on 13 October 2009 at 13:01
This is way too cryptic a posting. What in particular are you referring to?
Comment from davespod on 13 October 2009 at 13:26
I think (though please correct me if I'm wrong), it is referring to the conversation that has arisen out of Kevin's previous diary post:
@Kevin%20Steinhardt/diary/8271
Comment from Kevin Steinhardt on 13 October 2009 at 13:27
Minh Nguyen: I'm against redundant or otherwise trivial information, that does nothing but waste resources, time and efficiency.
chillly: absolutely, and that's why it's a great project. I just don't believe that one should put information in there only to be used at a later date. It's not a repository; it's advanced cartography.
Richard: I'm referring to the kinds of information that no map using the data currently parses.
Comment from Kevin Steinhardt on 13 October 2009 at 13:34
@davespod: indeed so.
Comment from Richard on 13 October 2009 at 15:11
But you simply can't tell that. OSM is too big for one person to know exactly what maps are out there using the data. I've been involved with the project for five years now and wouldn't even begin to think I could list what's parsed and what isn't - every day something new is announced that surprises me.
And that's a trend that's only increasing. Take a look at http://www.geowiki.com/halcyon/ - fully customisable map rendering using CSS. There are other similar projects, like Cartagen (http://www.cartagen.org/). How do you know that, just because a particular tag isn't selected as part of (say) the cartographic choices made by the default Mapnik layer, or the calculation choices made by CloudMade's routing engine, that someone else isn't doing something really cool with the data? How do you know someone hasn't got a really excellent MapCSS rendering running in an obscure corner of the web, using tags you've never heard of?
An example. In your previous post you said, for example, "the only people of which the tracks=* information is useful to is people like Network Rail or the TOCs". Completely wrong. Our local railway (the 'Cotswold Line', Oxford-Worcester) has extensive single-track sections. If I want to have an informed view of when my train is going to turn up (well, other than "late"), it is enormously useful to know where the single-track sections are. Armed with the knowledge that Wolvercote-Ascott is single-track, and that the live departure board has just shown that a down train has left Hanborough, I know that the up train I'm waiting for isn't going to reach Charlbury for 15 minutes, despite the fact it was meant to be here two minutes ago.
If you remove the tracks=* tag because you don't understand that, I call that vandalism.
(And contrary to your jibe about "personally, I don't think they'll be using OSM any time soon", again, you couldn't be more wrong. The feedback I get about my railway map at http://www.systemeD.net/atlas/ is that it's extensively used in the rail industry; I've received mail from ORR people, NR, TOCs, FOCs, you name it. As it happens it's not based on OSM data, but that's solely for copyright reasons, not for reasons of data quality.)
OSM isn't tidy. It isn't neat. It isn't corraled into a restricted set of features. Stop trying to second-guess what it'll be used for. It never works.
Comment from Tordanik on 13 October 2009 at 15:11
We are creating a database of information that can be used (and is being used) for making maps, but also for routing engines, 3D visualizations, street name lists, etc.. Nobody knows all applications that have been or will be developed using OSM. Therefore, if someone wants to put effort into adding some information to the map, it's best to assume that they have a good reason to do so.
Let's cite the wiki main page here:
"OpenStreetMap creates and provides free geographic data such as street maps to anyone who wants them. The project was started because most maps you think of as free actually have legal or technical restrictions on their use, holding back people from using them in creative, productive, or unexpected ways."
I'm quite sure that discouraging people from adding data if it is not immediately necessary for our current applications will not help to bring along creative and unexpected uses of geographic data.
Comment from RichardB on 13 October 2009 at 17:50
Further to the above comments, I had a look at a couple of the rails where you have already removed tracks=* info. The information was added by someone who runs a company (ITO) that makes maps for people in the transport industry, which are used by many public bodies, including councils and I'm sure the Department for Transport. If he thinks having that information is of use to him, then it's far from clear that the information is "trivial" or "redundant".
And to answer a point in the other thread - yes, some people do play tennis when they're away from home. They might be looking for it if they have a match against the home club. There are namefinder applications which not only search for sports centres by name, but also can find the nearest sports centre to a particular place.
OSM has so many uses that it's difficult to argue that extra tags are trivial or redundant.
Comment from nmixter on 14 October 2009 at 04:54
OSM's greatest strength - it's openness - is also it's greatest weakness. Sometimes maps can look crowded when several people edit an area, and several layers competing with each other. When they are extremely detailed, they aren't useful to anyone because they lack focus. The best cartographic maps are the simple ones. Currently there aren't any good tools for displaying just certain feature unless you have a good programing knowledge. However, there are many promising tools being developed. There needs to be a way to view different layers and extract the data from those layers. That will actually encourage more people to contribute because they can focus on the layers they are interested in while others can focus on other layers.
Comment from robert on 15 October 2009 at 00:35
"Map first, create architecture only after it is clear it is needed."
Needed by whom?
I totally reject the applicability of the 'You arent gonna need it' link here. This is not a small project whose pace is dependent on one or two people's time. The factor limiting mapping speed is people going places. If you go someplace and pick up a useful piece of information, like number of train tracks, it should be entered.
Comment from seav on 15 October 2009 at 05:19
Well, there *are* some geodata stuff that is ill-fit to be included in OSM (in its current schema). DEM data (whether as a grid of points or as contour lines) is one such thing.
Comment from davespod on 15 October 2009 at 10:03
Elevation can be mapped as points, using the "ele" tag. Countour lines are a rendering issue. Is there any other DEM data that could not recorded using the "ele" tag? (This is a genuine question - I know absoutely nothing about DEM.)
Comment from Kevin Steinhardt on 15 October 2009 at 16:18
@davespod The trouble with elevation and height and that lot of data is that it's terribly inaccurate from most devices.
Comment from davespod on 15 October 2009 at 20:28
Kevin, I'm sure you're right. I was just answering seav's point that you can't fit elevation data easily into OSM - you could fit it in, if you could collect it accurately. Thanks for pointing out the accuracy issue, though. I've put the odd ele point in when I feel like it (which is very rarely), and I might reconsider doing so, without reading up a bit more and possibly testing my device!