Peter Wendorff wrote: > There are two big differences between CSS and the proposed relation stuff. > 1) The inventors of CSS provided a working implementation for core CSS > features > 2) For a considerably long time css was used only very sparse and most > of the time with a html4 styling "fallback". > > Nobody arguments about the proposed use of relations per se, but it's > far from enough to propose something. > 1) Proposing one option is not the same as deprecating another, and > that's what some want to do here. > 2) Support in editor software does not rely on fixed rules only to use > relations, so that could be added even before "switching", and both > variants may co-exist for some time. > > The arguments mainly are: > relations are the better data model > therefore let's deprecate ref tags on ways. > > instead of: > relations are the better data model > let's make editors great enough that relations are on top of that easier > to use for mappers > let's make the API better by fixing the performance issues that occur > regularly when dealing with big relations (or very long ways) > Let's then encourage by arguments instead of rules to use relations - as > there's no good counter argument any more: At this stage they are as > easy to use, better to maintain and the cleaner data model. > > This is a big difference. > The first approach is what's tried here, and get's bad critics from some > others, because "usually" these attempts end up with new proposals and > questions to the old developers "why don't you support that? it's the > 'only' way to do it right" - or something like that.
I could agree with a lot here, but there are several points, where I think you're wrong. 1) Deprecating something does _not_ mean deleting this stuff, or completely throwing out a support for it. 2) I don't think anyone is actually proposing to completely deprecate the concept of adding the ref tags directly to ways (or even purge the data). The question was raised about, what's the point of keeping refs on ways, if the same information is already (more easily) maintained in the relation. I've tried to explain, why I personally think that "duplicating data allows you to do cross-checks for conflicts" is simply a bad reason. On the other hand, the backwards compatibility with tools used by data producers, as well as consumers, _is_ a good reason, but... 3) ...that's why we're having this discussion, isn't it? I don't think that attitude like "Go away and don't come back until you've coded editors support, API changes, osm2pgsql patches, ..." If you shouldn't come here with an (incomplete) idea and cooperate with others on improving/completing and realizing it, OR after a short discussion admit that it would need actually more work than you thought and it's not worth it... then, what's the point of this mailing list? I thought this is how the community should work - not everybody knows perfectly everything, but together... Best regards, Petr Morávek aka Xificurk
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
