It appears I've started another long discussion that will resist any attempts to produce a clear answer. I think it's fair to assume that because this is OSM each mapper can decide for him or herself how to map bays and straits. That is, as long as someone with greater power than any of us decodes to revert our additions. When I read that you, Frederik, reverted Daniel's work I was astonished. And you did it without even a comment to him. I'm curious to know, as are Kevin and presumably, Daniel, whether you were acting to enforce some official guideline or rule. Was that a unilateral decision or were others involved with it? If unilateral, I see it as an extremely insensitive move.
To answer Christoph's question about Chickaloon Bay and the node for the same bay, I simply forgot to delete the redundant node after I finished. Interestingly, the label for the new multipolygon fell only slightly to the east of the node so its placement was fairly accurate. However, in order to see the name on that node, one must zoom in so far that you have no idea whatsoever of the physical extent of the actual object. I know, that's a rendering issue. Still, the reason many of us enjoy mapping is so we can see the results of our labors somehow, preferably on a map, so it's a powerful incentive to do things in such a way that results in visualization. There is an enduring tension in the OSM world that we're always seeking to balance and this discussion is largely about where that balance lies. Also, sorry, I cannot see how representing a strait the size and importance of the Shelikof Strait (every Alaskan knows about this famous water passage) with a single way could work. A way is totally inadequate for such a task. Maybe that trick would work for a narrow strait that resembles a fjord but not for one as large as this one. Thanks for the feedback. Dave On Fri, Nov 16, 2018 at 4:12 AM Kevin Kenny <kevin.b.ke...@gmail.com> wrote: > On Thu, Nov 15, 2018 at 3:02 PM Christoph Hormann <o...@imagico.de> wrote: > >> > Even in that extreme example, having the spatial extent adds value. >> >> Data of subjective value for a specific application (like low quality >> label rendering) - yes, obviously. Meaningful additional information >> about the verifiable geography - no, i don't think so. >> > > By 'low quality', I presume you mean 'of a quality that can be achieved > algorithmically rather than by manual label placement by a skilled > cartographer?' Otherwise, what's your approach to higher quality? > > >> What you usually will want to start with is finding the closest point on >> the coastline. You might not want to use the original coastline data >> but pre-process it to some extent to for example eliminate small >> isolated islands. >> >> If you just want to do a primitive importance rating based point label >> rendering like OSM-Carto you will then just take all coastlines within >> something like 3-5 times that distance and make a bay size assessment >> based on that - your choice how fancy you want to make this. Simplest >> version is to use the distance right away but you can easily make this >> a bit more robust. >> >> If you actually want to place a label dynamically procedure will depend >> a lot on the style of label you want to use - horizontal single line, >> multi-line, rotated, curved - font size scaled or characters spaced >> according to the extent of the label. This part can be somewhat akward >> and inefficient because common spatial database systems are not >> specifically designed for this kind of task. What you need to do is >> essentially to 'probe' the coastline environment and determine the >> extent of the bay and where the desired label best fits in there. >> > > I can see how that approach might sort of work in some cases, but it > strikes me as rather brittle. A node anywhere in the middle of the Sea of > Cortez or the Gulf of Aqaba will be close enough to the nearest shoreline > that measuring off 3-5 times the distance will still not span the length of > the waterbody, meaning that identification of it as an area feature will > still be less than what we'd want. A large-scale map of Eilat would still > have a really difficult time - even considering the larger context - > identifying the name of the waterbody off its coast. An area like the > Jamaica Bay example I gave earlier, with many islands and channels in a > tidal wetland, would also be extremely difficult to reason about in that > manner. > > It is only once the spatial extent is determined that a renderer can do a > good job of label placement. Of course, what the renderer does with that > information is highly dependent on the style of label to be used, but any > rendering that's at all more sophisticated than OSM/Carto's 'place a > single- or multi-line upright label on a point' needs the information. > You've given a very clever 'second best' approach to determining that > information when only a point is available - and I'm likely to find myself > using it because of the current state of the map data, so thank you for > that. > > Nevertheless, I think it would be much preferable to allow mappers to > communicate their intent. When mappers add a bay, inlet, gulf, fjörd, ... > to the map, they can be presumed to know what extent they would like the > object to have. What harm does it do if we give them a way to describe that > knowledge to others? Why the insistence on restricting the data model so > that we must use a brittle reconstruction technique rather than allowing > mappers to enter the extent of the object and data consumers to see it? > > The two arguments that I hear so far appear to amount to: > > - if any portion of an object's boundary is spatially indefinite, then > that object may not be represented as an area. > > Farewell to several counties and townships in the northern part of my > state, then. > > - carrying the data for bays is not scalable. > > In that case, we need to open a much broader discussion of general > categories of data that we need to exclude from OSM in order to manage the > size of the data base or the complexity of the computations. I surely don't > want to start seeing conflicts between better- and worse-mapped regions > over perceived inequities in the allocation of server resources! If instead > of data volume, the concern is the complexity of processing large objects, > then it would perhaps be better addressed by a rule that "no area feature > should exceed more than X km², have a mapped boundary length of y km, or > require more than z nodes for its representation" - and then work out how > we want to handle exceptions like countries, large islands, and large lakes > and seas. (That's then the right time to discuss what to do about bays, > straits, estuaries, and similar features.) The argument would also have to > distinguish between the cost of maintaining the data on the server - the > real OSM - and the cost of processing the data in the OSM-Carto rendering > chain - OSM's public face. If there's a way to have the information in the > actual OSM database but not in the main renderer, or have the pipeline > generalize it to a lower-cost but less informative form, that would be > better than discarding it entirely. > > > > _______________________________________________ > Tagging mailing list > Tagging@openstreetmap.org > https://lists.openstreetmap.org/listinfo/tagging > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
