I'll focus on the coexistence vs. zone-only aspect, because most of the other problems can indeed be solved or mitigated by choosing a decent zone representation and throwing in some editor support and documentation.
Ben Laenen wrote: >> - zonal mapping makes it more difficult to write software evaluating >> the information, so less people will be able or willing to create >> cool stuff with OSM. Those who still do will have less time for other >> features. > > Let's assume that one day the incredible OSM library will appear that > will solve things like "I have vehicle type X, what are the access > rules on this street?" So you assume that well-designed, liberally licensed (!= GPL) Open Source libraries will exist for all major programming languages and platforms soon? Well, until then, I'll continue to assume that the goal of OSM data being used in creative and unexpected ways is better served by keeping complexity as low as possible instead of adding some more layers of code. >> - some options for zonal mappings (such as polygons) have performance >> disadvantages. This makes providing OSM services more expensive or >> causes slower software. > > You process the data before using it. You're not uploading OSM data in > the xml format from the API directly into your gps either. When routers > use the data it's also by processing the data first to make it usable > to calculate routes. I'm fully aware of that. It's that very processing process that will be slowed down. It's hard to quantify with no real information available, but software that requires frequent updates (rendering, maybe even live rendering) surely won't get faster by adding more preprocessing. > And that's the real issue here: you want the data instantly ready, but > that's not how the data should be in OSM. We map the world, if there's > a zonal restriction, we map it as such. You make it sound as if adding a maxspeed to the road in addition to mapping a maxspeed-limiting zone would somehow not be "mapping the world", when it's really just a different (and more conveniently usable) way of representing reality. >> Therefore, I suggest that you map zones _in addition_ to directly >> adding tags with the information to the streets. > > Duplicate tags are always a bad idea. Redundancy are not necessarily a bad idea if it helps to avoid errors and make processing easier. Also, it's good practice in OSM to add detail _without_ making access to less detailed information harder. That's why we have things like "highway=service + service=driveway". The redundant "highway=service" in this example serves the sole purpose of letting users of the data that don't care for details handle all service ways in a similar manner. Similarly, details about the reason for a restriction (e.g. a zone) should be added in a way that doesn't require additional effort by users of the data who don't care for that additional information. > But in OSM, the data should resemble what's on the ground. If your > purpose is to make a program that shows the traffic signs on a little > screen on your gps, this kind of data is important. So your program wouldn't work if zone information were present in addition to, rather than instead of, traditional way tagging? Tobias Knerr _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
