On Thursday 30 April 2009, you wrote: > 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.
Well, short answer: yes, I do assume that library will be made one day. Longer answer: currently we have such a thing in all software making use of OSM now, each with it's own interpretations, which aren't necessarily correct (and I'm sure it often isn't). So do we just let all those programs develop their own code (which may be incorrect, certainly not correct for the entire world concerning all different tagging methods in each country) or do we do what makes sense: make one library for all to use. And what the form of that library should be, I don't know. That's open for discussion. > 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. You're really making a problem out of nothing. I'll assure you that this will add practically no extra time. These are simple rules that take virtually no time. Perhaps the main calculation problem is that you need to go from country boundaries to the roads inside it since you need to know what set of rules apply. But that's not some specialty from this library, all programs should do that right now already (but don't) to know default speed limits and access rules. > 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. Only in your definition of "convenient" and "usable". IMHO it's much more convenient to tags zones as one entity since it can then refer to for example municipality decrees which in turn helps to maintain it later on. > Redundancy are not necessarily a bad idea if it helps to avoid errors > and make processing easier. No, redundancy is always a bad idea. Tags will eventually start to contradict each other, and removing redundancy will improve maintainability. > 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. Granted, and I've added a few times a tag like "maxspeed:zone=yes" as well. But from the moment we're talking about slightly more complex zonal restrictions, we end up adding the same set of tags to a lot of ways, and then the only sensible thing to do is to remove duplication and put it together, which in this case is a good thing (and doesn't have anything to do with "relations as categories") since the situation in real life combines it together as well in one zone. Ben _______________________________________________ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
