On Mon, Nov 23, 2020 at 2:57 PM Frederik Ramm <frede...@remote.org> wrote:
> Now, you might smirk and say "let's fix the tools then", but until the > tools are fixed - which might take years -, you've made life a hell of a > lot harder for anyone editing or quality monitoring in the whole area. > > And all for what - a nice blue label in the bay? > TL;DR: I understand the technical problems. Don't let the technical problems block the discussion for people who might be able to develop technical solutions. Back when this discussion started, it started because you deleted a relation for the Gulf of Bothnia, entirely without warning, without discussion, and without mentioning it in public even afterward until it was noticed and you were called on it in public. Generally speaking, it was accepted, ex post facto, as an emergency measure needed to rescue the servers from a performance trap, and most of us were willing to accept a temporary moratorium on creating large area relations because of the technical complications. That issue became complicated because others chimed in and started to argue that, rather than being a measure to rescue the servers from trouble, it was actually a reflection of a universally accepted policy that every millimetre of an area feature's boundary must be unambiguously defined and visible on the ground, and the discussion rapidly deteriorated because that definition, taken to its logical extreme, would exclude virtually all rivers, lakes and streams from being distinct bodies of water, would entirely exclude features such as bays, isthmi, peninsulae, and so on from ever being mapped regardless of size or obvious closure, and in general would dismiss topology as being entirely unimportant. The arguments went as far as to have one user advance the claim that a number of counties and townships north of me should not be mapped, despite having well-defined borders in the inhabited regions, because portions of their boundaries have never been successfully surveyed. But somehow, those voices never gained entirely the upper hand. If so, features like `bay`, `peninsula`, `strait`, `isthmus`, `ridge`, `valley` and so on would all bear prominent warnings on the Wiki that it is inappropriate to map them. Somehow, the people who loudly proclaim that objectivity and observability require that every feature be bright-line observable in the field cannot bring themselves to do that, or know that the community would reject it. For myself, I've deferred to you on the matter - including refraining from mapping even small features like Jamaica Bay ( https://www.openstreetmap.org/#map=12/40.6125/-73.8082) - despite the fact that the specific feature is reasonably sized, local, quite different from the Atlantic Ocean (calm water, much lower salinity, much greater tidal range, and a very different ecosystem) and that I would very much like at some point to produce a detailed paper map of my boyhood home town ( https://www.openstreetmap.org/relation/174930) including, of course, labeling the waterways that lie only partially within its neatline. I'm willing to accept for now that OSM cannot cope with that requirement and I'll have to develop another system alongside OSM and manage multiple map layers to produce such a thing. That sort of desire - wishing to include some information about long routes or about area features that are large, diffuse, imprecisely defined, or otherwise difficult - appears to be fairly commonplace, given the number of words that have been expended on the subject here and elsewhere. Those of us to whom the topology of area features is important - for instance, because we produce paper maps and wish to produce normal rendering, including labeling, of area features that extend outside the neatline - rapidly grew frustrated, and eventually the discussion died from exhaustion, as discussions on this list usually do. Meanwhile, there's no indication to mappers (for example, warnings in the popular editors) that creating enormous area features is inappropriate because of inability of the tools to deal with them. Moreover, those who actually have the technical expertise to experiment with solutions to the problem feel stymied at every turn by the gatekeepers - who may also have the technical expertise, but have a different opinion of the problem's importance. I've talked off-list with several skilled programmers and data analysts who definitely believe that even if a solution were to be developed, it would be rejected. There is certainly zero interest from the gatekeepers in maintaining a discussion of the requirements for such a thing - it turns into 'I haven't seen a good enough solution yet, and I'll know it when I see it,' without an answer to, 'in what way is a given proposal unsatisfactory and how might it improve?' There's a natural temptation to transform, 'this problem is too hard for me to solve in the time I have available' into 'this problem is too hard in relation to its importance', to 'this problem is unimportant to me, and you shouldn't work on it either.' The gatekeepers do good enough work in general that I'm even willing to accept, 'this problem is too hard in relation to its importance and we will not consider solutions that are offered and prefer not to address it,' but then the project really ought to define these objects as being out of scope. In that case, though, I think that the tool developers really have to be open to the concept of layers. When mappers are going to the effort of doing these things, it's because they want to have them. A directive of, "you should not want to map this feature," will be controversial to say the least. People map complex features such as the huge one in Alaska that kicked off the current round of this discussion, or smaller but still troublesome ones like https://www.openstreetmap.org/relation/6360587#map=10/43.3696/-74.0561, because they're actually there in the field. All of the small parcels that make up the latter are signed, at the very least where they front along a road, trail or waterway. The large whole is united by a name, an officer who manages it, a management plan, a web site, and so on - and the locals think of it as a single object despite its diffuse structure. Objects with that complex a topology present management problems. Agreed. But I don't know _how_ many arguments I've been in where someone who really has the management problems on his mind instead argues that the object in some way doesn't exist or isn't deserving of mapping. It's really important to keep the two arguments separate, or it starts to come across as, 'the data model is fine. Fix your country, or fix your world view (or the world view of your users).' At the very least, document that the creation of large multipolygons for indefinite features is considered inappropriate, and why, and enlist the aid of the maintainers of the editors to warn about the issue. Otherwise, you'll continue to see that people do it because they want to see the features on the map and are ignorant of the possible effects. -- 73 de ke9tv/2, Kevin
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
