On Tue, Nov 24, 2020 at 9:23 AM Christoph Hormann <o...@imagico.de> wrote:
> The problem we have here is that of a widening gap between the goals and > aspirations of the mapper community - which naturally grow as OSM grows in > ambitions - and the abilities and engagement in the non-mapping part of the > community to develop and satisfy similar ambitions in cartographic quality > without outsourcing the hard part of that work to the mappers. Too many > people have followed the illusion for too long that the large corporate OSM > data users will provide the necessary support in that field while it turns > out (non-surprisingly in my eyes) that they have neither an interest in > above average cartographic quality nor in substantially sharing methods and > competency in the little work they do in that domain. > (Brief summary: 1. Many area features are indefinite only at margins that do not have a significant deleterious effect on statistics when analyzed or on the understanding of the map when rendered. 2. Topology still matters - for analyzing or rendering them. 3. Algorithm development needs data to chew on. Blocking the data while waiting for the algorithms is a 'deadly embrace.' 4. Mappers are continuing to enter the data for approximate regions because they understand 1.-3. above. 5. Which argument are you willing to give up in order not to argue against all progress in this domain?) In my earlier message, I was speaking not as a mapper looking to enter data, nor as a map user looking for a pretty rendering - although I wear both those hats from time to time - but as a newly-retired applied mathematician (A.B., mathematics, Dartmouth College, MS in electrical engineering, Arizona State University, PhD, computer science, University of Illinois, about forty years of experience with GE, Northrop, Honeywell, and others), with a reasonable background in computational geometry, thinking of what challenges I ought to tackle next. Given that one of my principal avocations is hiking, my chief rendering interest is not with an endlessly-panning map, as useful as that is; it is with paper maps where labeling must conform with the neatline. For those maps, simply placing a point for 'label painting' near the center of an indefinite feature is not sufficient. Instead, a first step has to be calculating the intersection of the area feature with the region of interest, leading to one of the results: (a) the area is totally within the region; (b) the area is totally outside the region and may be discarded; (c) the area intersects the region partially and one or more regions of intersection must have labels placed individually. The 'one or more' arises from the fact that a non-convex area feature or a non-convex region of interest (a rectangle, for instance, with a corner cut out for placement of a legend) may yield more than one polygon of intersection. You have on several occasions advanced the argument that the central label should be enough for this and made a contention that I don't understand about projecting from the central label of a bay onto the shoreline to reconstruct the area. With that contention came the implication that the topological information about an indefinite area would not be needed, if only the renderers and data analysts worked hard enough. Unless you can provide me with literature citations to what you have in mind, I'm afraid that I'll have to dismiss your claim as hand-waving. As far as I can tell, there is no known way to achieve the result that mappers want - or at least I want - without the detailed geometry of the partially indefinite area. If you can provide such citations, I'm eager to follow up with you! I should digress into the phrase, 'partially indefinite,' that I've already been using. For the contentious areas such as the Red Sea, the indefinite portion about which the controversy arises is typically small, and typically of a nature where a rough approximation is acceptable to all users. There is no controversy arising from the shoreline of the Red Sea except for a trivial amount of border. Very few claim that the Red Sea exists only as a social construct. Scientists discuss its hydrology and ecology in contradistinction to that of the region of the Indian Ocean to which it connects. Mariners speak of Port Sudan, Jeddah, Sharm al-Sheikh, or Eilat as Red Sea ports (Eilat may be further specialised as being a port on the Gulf of Aqaba, a smaller area that is similarly well-defined; the relation is one of hierarchy rather than exclusion. (Moving somewhat to the northwest, I've seen papers on hydrology that have tabulated observations in rows labeled 'Ionian Sea', 'Ægean Sea', 'Tyrrhenian Sea', 'Adriatic Sea', and so on. There is _some_ shared understanding that those words have meanings.) 'Partially indefinite' extends to other features such as peninsulæ (a mirror image of bays - the indefinite boundary is one of land rather than water); straits (indefinite water margins at both ends); isthmi (indefinite land margins at both ends); and even rivers and lakes (indefinite at river mouths, lake inlets and outlets; confluences where tributaries enter, and divergences where distributaries leave). It even extends to political boundaries. There are a number of townships and even counties in my part of the world where the political boundaries are well known, surveyed, and monumented in the inhabited regions, but have never been successfully surveyed; knowing where the line is in the woods and swamps is simply not worth the cost of mounting a survey. (The general attitude has been, "if it ever becomes an issue, we'll sort it out.") https://caltopo.com/map.html#ll=43.91623,-74.49297&z=14&b=t indicates one example, where - on an official topo map from the US Geologic Survey - the cartographer has indicated the political boundary as 'INDEFINITE BOUNDARY' and even indicated an error of closure at the northern corner of the township. This is NOT a bad splice between two map sheets; note that streams, lakes, contour lines, are continuous. The discontinuity of the grid lines arises from the fact that one map sheet shows coordinates in NAD83 (nearly the same as WGS84) while the other is NAD27. The error of closure arises from projecting the boundaries of incomplete surveys that yielded inconsistent results. Still, if you follow the indefinite line around, you eventually come to where it transects the hamlet of Oxbow, https://caltopo.com/map.html#ll=43.43812,-74.49185&z=14&b=t, east of Rudeston and southeast of Piseco, where the town line is indeed signed on the highway (source: personal observation). The inhabitants of Oxbow no doubt care very much about which township collects their property taxes and maintains their roads; whose justice of the peace adjudicates their minor disputes, officiates at their marriages, and so on; whose town clerk maintains their vital statistics. The reductio-ad-absurdum of your argument would say that the township of Arietta must not be mapped as other than a point feature because large portions of its boundary are indeterminate. The townsfolk would disagree, in light of the fact that such a mapping loses the information of where the town line is, in the places where that's known perfectly well. Returning to the main point, I don't see how to approach the problem of rendering partially indefinite areas without the geometry of what is known precisely, and some approximation to the indefinite margins so that the areas present a closed, non-self-intersecting topology. Without that information _somewhere_, there's no place to start from! I would also appreciate some sort of deprecatory tag (`boundary=indefinite` on the way, perhaps, or a role of `outer:indefinite` or `inner:indefinite` on the way within the relation) to indicate where a particular way is arbitrarily added in order to give a partially-indefinite region a complete topology. A renderer is free to refrain from rendering indefinite margins, or to treat them differently in the rendering (like the narrower dashed line and the callout, 'INDEFINITE BOUNDARY' in the government topo above). Statistical analysis is free to make the boundary 'fuzzy' and explore how moving it will affect results. If you find even this approach unacceptable, your argument presents us with an insoluble 'chicken and egg' problem. Without the data, there is no foundation on which to develop and explore how rendering and statistical algorithms, both known and yet to be developed, perform against the real world. Without the algorithms already in place, you argue, the data ought not to be provided. In my opinion, the solution of 'outer:indefinite' and 'inner:indefinite' on the role makes more sense, since an object that is indefinite with respect to one object may be perfectly definite with respect to another. Whether a particular bit of coastline on the Bar al-Mandab Strait is or is not fronting on the Red Sea does not make it any less the shoreline of Yemen or Djibouti. You have also, in the past, argued passionately against 'foreign keys' being present in OSM (for instance, labeling waters in the US with their 'reach codes', which are digital identifiers identifying stream and river segments that are used in diverse government systems in the US) in order to connect it with non-OSM databases. This argument also forecloses on the idea that perhaps mappers should record the topology of these areas externally to OSM , while renderers or analysts should somehow fuse the multiple sources in their rendering or analysis. This combination of constraints feels as if you are arguing against the existence of the Red Sea or the Town of Arietta for some other reason, and using whatever argument will block it in the moment. We can't enter the data regarding indefinite features in OSM. We can't connect to the data regarding indefinite features outside OSM. We can't develop the algorithms without real data to prove them against. We can't have the actual data in the database until the algorithms are developed to consume the data. What, pray tell, may we do? All I hear from you is arguments against this and that. They are diverse and, taken together, are comprehensive enough, that in the absence of a proposed path forward among them, it is tempting to dismiss them as simple obstructionism. That's what mappers are doing. They're mapping indefinite area features because they see the potential benefits of doing so, even if the algorithmics have yet to catch up with them. Until and unless you offer a better alternative, they will continue to work around your objections. Note that I am not arguing in favor of anything that I have done on the map. In the vanishingly rare cases where I have adjusted a indefinite margin of an object, I've provided detailed discussion of why I believe that the line is the "best possible from the available information," citing sources. https://www.openstreetmap.org/user/ke9tv/diary/391486 and https://www.openstreetmap.org/user/ke9tv/diary/42951 are examples). I've refrained from entering any new indefinite objects at Frederik's request, which at the time appeared to be made in his official capacity as DWG member or as OSM board member. (Whether the request actually reflected an official position or was instead made in his personal capacity remains unclear to me.) While I've argued about the definition of 'coastline' here, I've not moved the coastline in the estuarine environment other than to correct obvious errors in the boundary between land and water. The argument (which I've heard in the past, and don't recall from whom) that I'm advancing this argument to justify in retrospect damage that I've already done to the map does not hold water. So, how do we move forward? Dismissing the Red Sea as a mere social construct is unlikely to achieve consensus. Moreover, social constructs are part of what we map; we live in the human world as well as the physical one. Objects have names; regions have political boundaries; amenities draw tourists; historic sites enjoy protection; and we map all those things. The human world is a world of ambiguity. We can, and should, try to make the map as definite as possible. We must not discard the human view in doing so. -- 73 de ke9tv/2, Kevin
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
