On Aug 24, 2018, at 11:41 AM, Evin Fairchild <evindf...@gmail.com> wrote: > Hey, I totally agree that we need to fix the rendering so that the renderer > will show ref tags on route relations. But until then, it's impractical to > expect people to avoid putting the ref tags on the ways.
Evin, we agree to disagree about "practicality." Defects can be so severe that workarounds cease as solutions. If/as more data entry which tags for the renderer STOPS (no more bandages), and the real wound is seen for what it is (a problem that must be fixed), a much stronger incentive to fix exists. We are not there now because of all the bandages, though we may get there if data entry more fully embraces "don't code for the renderer:" shields don't get rendered properly, routing seems to (or does) fail, etc. Either way (we can't have it both ways), the ONLY eventual solution is to fix what's broken. Mihai broached the topic, again (thank you), here we are. It seems "until then" is good enough for some people. As I can only speak for myself, I say "not good enough for me." Identifying defects is an absolutely critical process in any software endeavor, OSM included. And, as this is a specific/localized problem, I wish to build stronger methodologies in OSM for our ability to identify/recognize ANY problem in our data-to-render pipelines, while being supported by our community in our quest to fix them. My annoyance IS at the renderer itself. "Push for it to get fixed" is exactly what this is. As crucial "render stack coders" (right on, Martijn!), are clearly a critical OSM resource, they can't be expected to service every single problem, so we have what has evolved. But, we must prioritize. This is correct: some defects are purely cosmetic, some are high-priority. There is a rich spectrum of multi-dimensional methods to measure (and hence prioritize) software defects. However, "pretending away" with "it's impractical" and "don't code for the renderer" must be identified as what they are: dancing/hand-waving to buy some time until the demand (to fix defects) catches up with the supply/reality of them actually getting fixed. OSM simply must get better at this. I may not know exactly how today, but decades of improving exactly this process at major software companies tells me that's what this is and that's what we must do. The process remains opaque quite likely deliberately to "obfuscate away" demands on critical resources. Let's open that up, please; Open is our first name. > I do agree with not tagging for the renderer, but I was merely pointing out > that it's impractical to expect EVERYONE to follow it in this case until the > renderer is fixed. To make my point clearly: calling it "impractical" prolongs the problem by winking and nodding at slapping bandages on a wound. The "short-term bandage window" is or should be closed by now. Paul Johnson is right: dinosaurs like ten-year old bugs ought to be fixed. If you want to say "it's impractical to expect..." you can. I am saying "let's be practical by fixing what is broken." That's what works. Really, this is a much wider conversation, as you (Evin) identify about Washington state route shields and Kevin Kenny's recent "resurrection" of similar topics. Yes, the data-to-render pipelines can be complex; I acknowledge that, this is a fundamental "tall mountain" of OSM. But I continue to say "fix bugs, don't bandage them" (rather than wink or say "that's impractical"). Andy's awesome work to streamline mapnik into Carto is an excellent example of this tenet: our project will either learn how to fix complexities in renderers (often by simplification of the codebase), or we will self-destruct in endless discussions like this. I'd much rather take what is known to be a proven successful path. So, let's improve our render-defect fixing pipeline, as it is rather broken. No judgement there, rather identification of problems needing fixing. We've done it before, we'll do it again, only better. SteveA _______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
