Re: [Tagging] Using multipolygons to map bays in Alaska
I have been following this discussion with interest since I would also like to have bays and straits represented by some sort of polygon/area instead of just nodes. However, I also agree that having overlapping relations containing hundreds to thousands of natural=coastline ways would tax many data users, and be prone to getting errors from mappers who edit coastlines. As a sort of compromise at least for bays (gulfs, inlets, fjords, coves), how about we just map them as a single way across the mouth of the bay and not as a way-polygon nor type=multipolygon relation? And then we set the direction of the way such that the right-hand side of the way points to the bay-side (just like the right-hand side of natural=coastline ways point to the seaward side). I know that some people would not like this at all because this is mapping an arbitrary and fuzzy water boundary. But this avoids creating overlapping relations and reduces the technical problem to just maintaining a single way per bay. And for map users and renderers that care about the polygonal extent of bays, either for labeling purposes or other applications (like calculating approximate areas), constructing the approximate polygon for the bay is an easier GIS operation (just concatenate that single way with the adjacent bay-side coastline ways) than trying to guess that polygon from a possibly poorly placed node. If people think this is a good idea, we can even extend this to straits: just map the ends of the strait with two such ways and combine them into a relation and tag that relation with natural=strait. (At least this relation will just contain 2 or a few simple ways instead of also including many coastline ways.) I guess we would also need to have a new type=* for these relations, perhaps type=water_extent or something else? ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
W dniu 17.11.2018 o 12:27, Frederik Ramm pisze:
> But I felt in this situation, they had overstepped their mandate,
> *especially* because they were not reacting to something that people
> were doing, but actively creating a new feature ("hey, you can now have
> huge named bays") and at the same time adding the data to OSM to
> illustrate their new feature.
The reality is more complex, so I'd like to show the other part of this
story.
During one of my map reviews around the world I have encountered Port
Phillip Bay (near Melbourne) not being rendered. This is quite old bay
relation - it has 3 years now:
https://www.openstreetmap.org/relation/1221199
I was interested how this water area is named and it looked bizarre for
me that this information is completely invisible on default map. Using
areas for bays was documented on the wiki, the numbers were OK and still
raising, the patch was soon accepted, so it all looked OK for me.
> And let's be totally clear here: A nice label on the sea is all that
> Daniel wanted. He's not a maritime scientist who for some reason needs
> the exact extent of Bothninan Bay - he went through the time-consuming
> exercise of combining more than 1600 coastline pieces into one huge
> polygon which is difficult to handle for data processors and editors
> alike JUST TO PLACE A LABEL.
Nope, having a sane label was just a part of my motivation. It was also
"eating my own dog food", which I do with some features just to see how
does it really work.
When I saw a random dot somewhere inside big water body as a result of
asking Nominatim instead of a general shape I expected, I was disgusted
and frustrated. It didn't make sense for me to shrink a 2D place with
size of a country into 0-dimensional object, placed there without any
clear reason and without a hope for any sane data operation other than
name searching. I was also happy that this place will be much closer to
reality after this fix - you don't need to be a scientist to appreciate
that.
> It is only a matter of time until they start labelling natural=sea
> polygons and people then create relations with 100,000 members for the
> Atlantic.
I really hope one day we will have some conventions for bigger water
objects. Limited testing on something smaller and more solid like bays
was also one of my goals. Currently OpenStreetMap seems to be completely
unprepared for _any_ large scale mapping (other than countries and some
natural areas), so I doubt it will be anytime soon.
This includes not only geometry problems (sorry - a node for entire Asia
looks like a joke!), but also lack of convention for tagging biggest
rivers, lack of idea how to tag and render generic names of biggest
areas (3 languages in Belgium as name=* is quite strange, but which and
how many languages should we display for Atlantic?), lack of convention
for mountain ranges, geographical regions and so on...
But since we've made conventions for such artificial objects like road
types, it's possible that one day we will have some global (sic!)
agreement. IMO it's like 5 years perspective if everything goes smooth
(which I don't think is realistic vision, unfortunately, ~10 years is
much more probable).
> (1) the OSM-Carto project and Daniel have overstepped their mandate as
> the maintainers of our style, and should have sought a wider consensus
> on this before acting;
For me a project as big and distributed as OSM is rather ecosystem than
a single project. Any action can have unexpected consequences, but lack
of action will also have serious consequences. Constant discussing
everything and care taken for every small detail almost killed OSM Carto
in 2015. It took years to make more people contribute again. I hope this
new team will find good balance and will upset people less than currently.
> (2) the decision they have made is not a good solution for the
> cartographic problem they wanted to solve;
Nobody is forced by documentation to choose this or the other solution,
so now we have a chance to see how people will use these tools. At least
they have a real choice now and I believe this will help OSM to grow in
a more organic way.
> (3) the decision they have made will lead to people creating huge
> polygons that will often break, make coastline editing harder, and have
> at least one totally made-up edge.
Almost every water body connected to another (river/sea, lake/river,
bay/ocean, and even stream/river) has at least one unverifiable border,
because - well... - you can't see the ground truth on the water; unless
there's a dam for example. We just ignore it for small water bodies and
the whole coastlines. However it does not seem to me as a sustainable
solution, we need some convention.
Every country or national park border is a fragile large beast, which
may be only approximately visible on the ground. You might see some
boundary markers, but mostly there is no continuous line and we are
connecting the dots at best or using some docum
Re: [Tagging] Using multipolygons to map bays in Alaska
On Sun, 18 Nov 2018 at 05:09, Frederik Ramm wrote: > > Oh yes, certainly. Of course, in the concrete example at hand, > re-tracing the whole boundary of the Gulf of Bothnia as a new way would > have been worse (and impossible due to the 2000 node limit), and not > even re-using the nodes would have been unspeakably worse. On Sun, 18 Nov 2018 at 05:21, Christoph Hormann wrote: > a possible partial conclusion here where most of us can agree on: That > bays and straits above a certain > size - be that a few tens of km or even 100-200km - should not be > mapped with a polygon. On Sun, 18 Nov 2018 at 06:36, Paul Allen wrote: > The node and area give different results in some circumstances and could, > given > improvements in rendering, give even greater differences in their output > in the future. > > You point out that neither a new polygon that shares nodes with coastline > ways nor a complex > relationship are going to play nicely with the toolchain. Being a bear of > little brain, and lazy to > boot, my first thought would be a crude polygon approximating the > coastline. It would have few > enough nodes that it would be renderable but approximate the coastline > sufficiently well for label > placement. > > I still like a polygon even if the water in the bay looks no > different from the ocean because using the query tool on the polygon will > bring up an approximation > to the extent of the bay. > Still following with interest & had a thought, which, although definitely not a perfect answer, *may* (sort of!) satisfy everybody? When we look at Bothnia, https://www.openstreetmap.org/#map=5/62.928/25.177, the first thing I notice is the line of the 24 nautical mile (?) international maritime boundary, in both the Bay & Gulf. Would it work to use that boundary line as the outer of a very large, but also quite simple polygon, as the boundary of the Gulf (or Bay) of Bothnia? No, it's not perfect as the Bay should indeed meet the coastline, but it will show that this area is the Bay of Bothnia. Another question going back to the River Plate that I mentioned the other day https://www.openstreetmap.org/#map=8/-35.131/-57.237. It is clearly labelled as Rio de la Plata, but when you zoom in, the labelling doesn't follow you eg https://www.openstreetmap.org/#map=10/-34.9607/-57.7945 Should it? If I want to zoom in & look at the waters of BA, then I'd like it to say that i'm looking at the River Plate. Is that a system issue, or some thing to do with Carto? Thanks Graeme ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
Despite the remaining problem of just how best to map the Iarge Alaskan bay that started this conversation, it's been very interesting. For now, I'll just let it remain as a node and hope that a better label rendering solution for a water body as large as Cook Inlet comes along during my lifetime. I will decide whether to use multipolygons to show smaller bays and straits on a case by case basis. Thanks to all for your contributions. Alaska Dave On Sun, Nov 18, 2018 at 4:51 AM Paul Allen wrote: > On Sat, Nov 17, 2018 at 9:30 PM Kevin Kenny > wrote: > >> >> It is sounding as if Frederik and Christoph are willing to tolerate >> limited experiments as long as we mostly don't damage the coastline, >> > > Life would be so much easier if we had a sandbox. > > >> and keep our areas small enough not to break the toolchain. >> > > I was contemplating generalizing Cardigan Bay. Maybe a few dozen nodes. > But now you've made me > worry that it's not just the node count I should be concerned about but > also the size of the area > enclosed. Like I said, if only we had a sandbox... > > -- > Paul > > ___ > 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
Re: [Tagging] Using multipolygons to map bays in Alaska
On Sat, Nov 17, 2018 at 9:30 PM Kevin Kenny wrote: > > It is sounding as if Frederik and Christoph are willing to tolerate > limited experiments as long as we mostly don't damage the coastline, > Life would be so much easier if we had a sandbox. > and keep our areas small enough not to break the toolchain. > I was contemplating generalizing Cardigan Bay. Maybe a few dozen nodes. But now you've made me worry that it's not just the node count I should be concerned about but also the size of the area enclosed. Like I said, if only we had a sandbox... -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Sat, Nov 17, 2018 at 3:36 PM Paul Allen wrote: > You point out that neither a new polygon that shares nodes with coastline > ways nor a complex > relationship are going to play nicely with the toolchain. Being a bear of > little brain, and lazy to > boot, my first thought would be a crude polygon approximating the > coastline. It would have few > enough nodes that it would be renderable but approximate the coastline > sufficiently well for label > placement. Provided the carto didn't render the bay in a different colour > or with a visible border it > would handle label placement nicely (particularly if the renderer's > placement algorithms > improved in the future) without looking fugly. I must be wrong about > this, though, because I > recall an earlier post in this thread pointing out where somebody had done > something very like > that and denounced it as a crime against humanity. > That's what I meant when I discussed 'generalizing' the way. 'Generalization' is a GIS-speak term for reducing point count and resolution to make an object suitable for rendering at larger scale. So all that appears to leave is a node with sub-tags of bay=small, > bay=intermediate, bay=large and > bay=supersize to control the size of the label whilst the mapper controls > the position of the label by > guessing where the node ought to go. I still like a polygon even if the > water in the bay looks no > different from the ocean because using the query tool on the polygon will > bring up an approximation > to the extent of the bay. > It is sounding as if Frederik and Christoph are willing to tolerate limited experiments as long as we mostly don't damage the coastline, and keep our areas small enough not to break the toolchain. I'm satisfied with that as an answer for now. If using areas has the advantages that you and I think it does, then it'll win out over time. If it has the difficulties that Frederik and Christoph fear, then mappers won't adopt it and the discussion will be moot. And I surely sympathize with their woes about managing large objects! I've had to repair ones like Lake Huron (relation 1205151, but please don't overload the server by trying to fetch it!) a time or two, myself, and it's painful, what with the server timeouts and all. (There was a serious proposal floated at one point to make the Great Lakes 'natural=coastline', for just that reason, but I seem to recall that it foundered on topology. The only way to handle it would have been to extend the coastline all the way up the St. Lawrence, Niagara, Detroit, St. Clair, Mackinac and St. Mary's Rivers, and make all the islands in the Great Lakes 'coastline' as well - effectively inverting the topology of everything in contact with the lakes. So for the moment, I'll confine any experiments to objects the size of Jamaica Bay, while leaving Hudson Bay or the Gulf of Mexico, or even the Long Island Sound, to a later time. I'm convinced that sooner or later we will need a better general solution than just placing a node - as I said, I'd really like a paper map of Helsinki or Tallinn to label the Gulf of Finland. But I don't yet have really good ideas about how to upgrade the technology to get there with large objects - a few half-baked ones, but I'm rather a long way from trying them yet. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Sat, Nov 17, 2018 at 7:09 PM Frederik Ramm wrote: > > My argument was that if you can get away with using a single node for > labelling, then you don't have to burden all those 1,400 coastline ways > with one (or two or three) extra relation memberships and that would be > preferable. > I agree entirely with that sentiment, because I'm lazy (but I dress it up by telling people that I work smarter, not harder). If you can get the exact same result by two different methods and one of those methods requires a lot less work than the other, then of course you should go for the one that is less work. But it's rarely the exact same result when dealing with bays, as Kevin (amongst others) has pointed out. The node and area give different results in some circumstances and could, given improvements in rendering, give even greater differences in their output in the future. You point out that neither a new polygon that shares nodes with coastline ways nor a complex relationship are going to play nicely with the toolchain. Being a bear of little brain, and lazy to boot, my first thought would be a crude polygon approximating the coastline. It would have few enough nodes that it would be renderable but approximate the coastline sufficiently well for label placement. Provided the carto didn't render the bay in a different colour or with a visible border it would handle label placement nicely (particularly if the renderer's placement algorithms improved in the future) without looking fugly. I must be wrong about this, though, because I recall an earlier post in this thread pointing out where somebody had done something very like that and denounced it as a crime against humanity. So all that appears to leave is a node with sub-tags of bay=small, bay=intermediate, bay=large and bay=supersize to control the size of the label whilst the mapper controls the position of the label by guessing where the node ought to go. I still like a polygon even if the water in the bay looks no different from the ocean because using the query tool on the polygon will bring up an approximation to the extent of the bay. -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
[Tagging] Proposed features/Boat school - RFC
I've made a proposal to tag boat school quite similar other schools, e.g. amenity=ski_school. I've tried to keep the tagging as small as possible since schools can give more information on their own webpages. Please have a look at https://wiki.openstreetmap.org/wiki/Proposed_features/Boat_school Otto Wyss -- Alte Landstr. 81b 8800 Thalwil otto.w...@orpatec.ch 078 874 77 73 ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Saturday 17 November 2018, Kevin Kenny wrote: > > This request also has nothing to do with relations that are large > enough to break the tools. I'm confining my request here to features > that are relatively small in extent - perhaps up to a few tens of km > on a side. Maybe with all disagreement we have a possible partial conclusion here where most of us can agree on: That bays and straits above a certain size - be that a few tens of km or even 100-200km - should not be mapped with a polygon. As Frederik explained there are very good arguments for that even without taking into account the verifiability question. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
Hi, On 11/17/18 19:36, Kevin Kenny wrote: > You're welcome to this particular opinion in your personal capacity and > are free to argue the point as passionately as you care to. Why, thank you ;) > When you have your DWG hat on I don't, and never had in this whole discussion. > A minority of > users (including myself), whose number appears to be growing, find that > sharing boundary ways among multipolygons creates a structure that > actually is easier to enter, edit and maintain than the one that appears > from multiple retraced ways over the same nodes, or worse, independently > traced ways that are approximating the same boundary in the field. Oh yes, certainly. Of course, in the concrete example at hand, re-tracing the whole boundary of the Gulf of Bothnia as a new way would have been worse (and impossible due to the 2000 node limit), and not even re-using the nodes would have been unspeakably worse. My argument was that if you can get away with using a single node for labelling, then you don't have to burden all those 1,400 coastline ways with one (or two or three) extra relation memberships and that would be preferable. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33" ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Saturday 17 November 2018, Kevin Kenny wrote: > > As we say in German: Umgekehrt wird ein Schuh draus. > > We seem to be up against a cultural difference. English has proverbs > like 'don't throw the baby out with the bath water,' and 'the perfect > is the enemy of the good.' It means more or less: That idea makes more sense the other way round. Literally: It will turn into a shoe the other way round. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Sat, Nov 17, 2018 at 1:45 PM Christoph Hormann wrote: > As we say in German: Umgekehrt wird ein Schuh draus. We seem to be up against a cultural difference. English has proverbs like 'don't throw the baby out with the bath water,' and 'the perfect is the enemy of the good.' ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Saturday 17 November 2018, Kevin Kenny wrote: > The discussion of indefinite objects falls in the same category in my > mind. We shouldn't have to discard what is known or defined about an > object because some other part of the object is unknown or > indefinite. As we say in German: Umgekehrt wird ein Schuh draus. You should not need to add non-verifiable data to the database to be able to map verifiable knowledge of the geography and see it in OSM-Carto. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Sat, Nov 17, 2018 at 6:29 AM Frederik Ramm wrote: > Another pet peeve of mine is a dislike of what I call "relation mania", > where we have land boundaries that can easily be part of 20 different > relations on different admin levels and other boundary types. It's bad > enough on land, and makes editing harder for everyone; > You're welcome to this particular opinion in your personal capacity and are free to argue the point as passionately as you care to. When you have your DWG hat on, might I ask you to acknowledge that there is a diversity of opinion in the community on this topic? A minority of users (including myself), whose number appears to be growing, find that sharing boundary ways among multipolygons creates a structure that actually is easier to enter, edit and maintain than the one that appears from multiple retraced ways over the same nodes, or worse, independently traced ways that are approximating the same boundary in the field. Land use, land cover, and cadastral boundaries (such as administrative regions) in particular appear to be well served by this sort of topological approach. Today, the difficulty seems to depend partly on the editor in use. JOSM and Meerkartor handle it quite well indeed; iD and Potlatch still struggle - and that may be part of the reason behind the "it makes editing harder" argument. (There's a chicken-and-egg situation there too: some edittors support it badly, so people argue that it shouldn't be done, so those editors continue to support it badly.) If the idea becomes more relevant, the tools will improve. Given that there is some history of arbitrary decisions in this particular arena, may I make the plea in advance that the technique not be summarily suppressed until there is more experience with how it works out in the places where it's being tried? I know you've managed to exercise such restraint in the past; you've personally disagreed with at least one import that I've conducted and nevertheless allowed it to stand. This request also has nothing to do with relations that are large enough to break the tools. I'm confining my request here to features that are relatively small in extent - perhaps up to a few tens of km on a side. The larger of them would be represented as multipolygons in any case because their bounding ways have too many nodes to be handled gracefully. ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Sat, Nov 17, 2018 at 10:23 AM Paul Allen wrote: > On Sat, Nov 17, 2018 at 11:29 AM Frederik Ramm > wrote: > >> I do agree that while we should not "map for the renderer" >> > > I would modify that a little. We shouldn't LIE for the renderer. Given > two, equally valid (documented, > accepted, supported) tagging schemes we are at liberty to choose which to > use, and our choice may > be influenced by the rendition of one or more renderers. But that's a > side-issue. > This! The purpose most mappers have, when deciding to include an object, is that the object should be rendered somewhere. I don't say here, 'rendered in OSM-Carto', I say 'rendered somewhere'. I'm entirely willing to do my own custom rendering for objects of special interest. But, when I've asked questions of the form, "how can I most effectively tag objects of type A from objects of type B, because I wish to render them differently on my own maps?" (Example: the access=permit kerfuffle), I've repeatedly been met with an argument that I'm tagging for the renderer. It is not 'tagging for the renderer' to make the observation that no conceivable renderer can make a decision based on data that are not on the map! The discussion of indefinite objects falls in the same category in my mind. We shouldn't have to discard what is known or defined about an object because some other part of the object is unknown or indefinite. We can't map what is known if we've thrown it away. I don't want to throw away St. Lawrence County because nobody has ever surveyed a line through the swamps of the St. Regis basin, and I likewise don't want to throw away Jamaica Bay (or for that matter, the Gulf or Bothnia) because we don't have a 100% agreed-on field-verifiable bright line across their mouths. I recognize that the Gulf of Bothnia may fall afoul of technological limitations, and I've conceded that point, but in cases where we won't cause widespread breakage, it surely makes sense to do what can be done with the imperfect information at our disposal! ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Sat, Nov 17, 2018 at 6:29 AM Frederik Ramm wrote: [longish observation blaming OSM Carto for the fact that people were coming to map bays as areas...] > So, long story short, a couple of "my" maps suddenly started to show > ugly dark-blue patches e.g. across the bay of Biscay, or the Gulf of > Bothnia. That's how I noticed and investigated what was happening, and I > found that Daniel had added the Gulf of Bothnia polygon to accompany the > newly-introduced OSM-Carto feature of rendering bay names depending on > the size of the area. > In my case, OSM Carto had very little to do with it. As I discussed in earlier messages, my motivation is that I render a fair number of maps, moslty for my own use and my friends, on actual dead-trees paper (or more often Tyvek, which I suppose you could call 'dead-dinosaurs paper'). I do want my maps to show the names of significant geographic features that appear on them, even if the region of interest of the paper map includes only a small portion of a large feature. I could not figure out a way to do that without defining area features as areas. Doing so runs afoul of Christoph's pronouncement that no area features should be mapped as areas unless every metre of a border was field-verifiable. I found that pronouncement quite disturbing, since I live in a region where there are significant administrative regions whose borders are indefinite. (I recognize that there's a cultural difference here: the chaotic American approach to such matters is, "we'll survey it if it ever becomes important enough that someone will pay for the survey." Where is the precise boundary in the swamps of the St. Regis River basin? Nobody much cares. The county line is surveyed and monumented where people do care.) If that pronouncement were carried out to the letter, a couple of counties in my part of the world would have to be reduced to nodes. In the case of an ugly dark-blue patch over the Gulf of Bothnia or the Bay of Biscay, I'd definitely have directed my annoyance at the renderer. When I've done my own rendering, I've never distinguished inland from ocean waters by colour - precisely because it unduly emphasizes the arbitrary lines between them, which occur at every river mouth, estuary, and yes, bay. Whether OSM-Carto encourages, discourages or is neutral toward the style in question is something that is of no concern to me. he went through the time-consuming > exercise of combining more than 1600 coastline pieces into one huge > polygon which is difficult to handle for data processors and editors > alike JUST TO PLACE A LABEL. > I have found that when anyone is advancing an argument with the word 'just' in it, that the word is demanding a suspension of disbelief, and the position would be more accurately stated without it. Deferring the discussion of data processing to a later paragraph, let me translate. _He went through that difficult and time-consuming exercise to place a label._ Can you see how that sounds different? It is not an arrogant assertion that your assessment of the importance of the task is more valid than his. It leaves open the possibility that the presence of the label was important enough to him that it was worth going through that work to allow for it. Objects in the real world have names. One of the functions of a map is to inform its users of the names of the objects that it displays. Surely maps have many other functions, but connecting the displayed objects to human language and the human sense of orientation is one of them. It is hard to find a map, anywhere, that does not have labels for named objects because that is a critically important part of what a map does. In my particular use case, a node label would be useless to me. I do render large-scale maps that often contain a small piece of a much larger objects. Having a node with the object's name somewhere far beyond the boundaries of the region of interest is worthless to me. That is why I favour carrying area features as areas rather than nodes, always. (It also gives a more sophisticated renderer than Mapnik many more options for resolving conflicting labels.) Maps from before the OSM era did this pretty much universally. Returning to my Jamaica Bay example, https://caltopo.com/l/EQA0 shows the meeting point of four sheets in the old USGS 7.5-minute topographic series. You'll see that all four of the sheets have labeled 'JAMAICA BAY', even though the quadrangle to the northwest has only a little triangle of it in one corner and the one to the southwest has only a narrow strip along its eastern margin. That's because it is a locally important feature - and assigning it a name truly is important. It is the feature that dominates the landscape of those who live by it. If I were to be producing almost any map of that area by hand methods, the ocean, the bay and the airport are surely the first three features I'd sketch in, and the labels I would least want to lose. It is only a matter of tim
Re: [Tagging] Using multipolygons to map bays in Alaska
Regarding labeling, the name must be attached to something. If there is no real
thing to attach the name to, a dummy node ore way or area is used. I don’t have
a principal preference for that.
A node can be placed precisely where you want the name to appear, then the
label appearance could be modified by the renderer according to the context,
e.g. shorelines.
A way could be useful for curved straits, the renderer could use the relation
between way and shorelines to do nicely curved and sized renderings, including
repetitions in separate sections.
An area outlining the rough shape of the bay could be handy for oddly shaped
bays or gulfs, making the names more easier to render, including size and
repetitions.
Looks all equally valid and doable to me.
Mvg Peter Elderson
> Op 17 nov. 2018 om 13:18 heeft Christoph Hormann het
> volgende geschreven:
>
>> On Saturday 17 November 2018, Frederik Ramm wrote:
>>
>> I do agree that while we should not "map for the renderer" it is good
>> to have a central map that provides valuable feedback, and keeps
>> mappers from, say, introducing random highway types by simply not
>> rendering them. But I felt in this situation, they had overstepped
>> their mandate, *especially* because they were not reacting to
>> something that people were doing, but actively creating a new feature
>> ("hey, you can now have huge named bays") and at the same time adding
>> the data to OSM to illustrate their new feature.
>
> Indeed.
>
> And to make this very clear once again - no one suggested so far to
> universally disallow mapping bays using polygons.
>
> What has been said is that mapping bays with a node is the most common,
> most widely accepted and (in my opinion) in the vast majority of cases
> the most suitable way of mapping bays, in particular larger ones. And
> OSM-Carto should support mappers in this practice and not steer them to
> change it.
>
> OSM-Carto has historically for as long as i can remember supported nodes
> and polygons equally for features where both variants are commonly
> accepted methods to map something - housenumbers is the most prominent
> example probably - which can be mapped both on an address node or on a
> building and are shown in both cases with no preference for either of
> them. The same is perfectly appropriate to do for bays. What however
> is not appropriate is to incentivize mapping bays with polygons by
> labeling them from polygons in a different form that in particular for
> large bays is more suitable and attractive than when mapped with nodes.
> Or like for straits to label them when mapped with polygons but not
> show them at all when mapped with a linear way.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (office=diplomatic)
On 2018-11-17 16:35, Paul Allen wrote: > On Sat, Nov 17, 2018 at 3:52 AM Graeme Fitzpatrick > wrote: > >> Should EU:NATO be a colon or a semi-colon? > > According to the French, it should be EU;OTAN. :) If you are going to pick nits, get it right... In French it is UE;OTAN >)___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (office=diplomatic)
The proposal specifies English—mi scuzi—прошу прощение—Entschuldigen Sie bitte :-) Sent from my iPhone > On Nov 17, 2018, at 8:35 PM, Paul Allen wrote: > >> On Sat, Nov 17, 2018 at 3:52 AM Graeme Fitzpatrick >> wrote: >> > >> Should EU:NATO be a colon or a semi-colon? > > According to the French, it should be EU;OTAN. :) > > -- > Paul > ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting - (office=diplomatic)
On Sat, Nov 17, 2018 at 3:52 AM Graeme Fitzpatrick wrote: Should EU:NATO be a colon or a semi-colon? > According to the French, it should be EU;OTAN. :) -- Paul ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
Hi Frederik (and, of course, everyone else). I appreciate your expanded
explanation on this.
On Sat, Nov 17, 2018 at 11:29 AM Frederik Ramm wrote:
>
> So, long story short, a couple of "my" maps suddenly started to show
> ugly dark-blue patches e.g. across the bay of Biscay, or the Gulf of
> Bothnia. That's how I noticed and investigated what was happening, and I
> found that Daniel had added the Gulf of Bothnia polygon to accompany the
> newly-introduced OSM-Carto feature of rendering bay names depending on
> the size of the area.
>
An unpleasant surprise. I can understand why you wouldn't be happy. I
wasn't, and still am not happy
with the icon recently added for outdoor seating areas: it incorporates an
umbrella but most outdoor
seating areas in my part of the world are not covered. I contemplated
removing outdoor seating areas
I myself had mapped as I considered the icon to be very misleading but I
never contemplated removing
outdoor seating others had added even if I knew they were not covered.
Of course I can adapt my map styles, and have indeed done so, as I often
> have to do when mappers change their behaviour. But I was pissed off
> nonetheless; I felt that OSM-Carto is just one rendering project and
> does not (and should not) have the authority to steer what mappers do.
> There are many other people interpreting our data and they should not be
> forced to jump whenever OSM-Carto decides they want to change something.
>
There I start to part company with you. Your thinking there means we can't
ever change anything
about OSM Carto, or the way features are tagged. OSM is a dynamic, living
entity. Like all living
entities, stasis ultimately means death.
I do agree that while we should not "map for the renderer"
I would modify that a little. We shouldn't LIE for the renderer. Given
two, equally valid (documented,
accepted, supported) tagging schemes we are at liberty to choose which to
use, and our choice may
be influenced by the rendition of one or more renderers. But that's a
side-issue.
> it is good to have a central map that provides valuable feedback, and
> keeps mappers
> from, say, introducing random highway types by simply not rendering
> them.
>
I don't have a problem with "you can now have huge, named bays." Actually,
since I live a mile from
the biggest bay in Wales (Cardigan Bay) I think that's a nice feature to
have. But I wouldn't be happy
if it rendered in an ugly way. A better placement/size of the label would
be a good thing. Maybe even
a very faint (and optional, perhaps visible only on things like OpenSeaMap)
line denoting the
boundary between bay and ocean. The ugly thing you described would be
sub-optimal.
But I felt in this situation, they had overstepped their mandate,
> *especially* because they were not reacting to something that people
> were doing, but actively creating a new feature ("hey, you can now have
> huge named bays") and at the same time adding the data to OSM to
> illustrate their new feature.
>
That's a circular argument, though. Nobody is mapping something because
the carto doesn't
render it. Therefore the carto shouldn't render it because nobody is
mapping it. Therefore
nothing should ever change because we have everything we will ever need
right now and it is
perfect. That's not the case, nor will it ever be the case.
I think a better argument is to look outside of OSM and see what other maps
do. The editor
layer index gives access to several out-of-copyright maps of the area of
Cardigan Bay, and they
all label it as such, and their label placement and size depends upon the
geometry of the bay.
I think having the toolchain compute the label placement from an
(admittedly somewhat
inaccurate polygon) is better than me imagining the polygon and computing a
node position
myself. The former allows for an appropriate size of label (much as the
label on woodland
depends on the size of the woodland) whereas with a node we'd require
sub-tags such as
"bay=small" analogous to "place=hamlet"). An area allows later mappers to
see what border was
used and, if better information becomes available simply tweak it rather
than trying to guess how
the node position was determined. Just plonking a node down is the
ultimate in lossy compression
of information.
> Another pet peeve of mine is a dislike of what I call "relation mania",
> where we have land boundaries that can easily be part of 20 different
> relations on different admin levels and other boundary types. It's bad
> enough on land, and makes editing harder for everyone; when I saw the
> Gulf of Bothnia polygon (which *already* is large enough for the web
> site to time out when you want to show the history) I thought: Is this
> *really* necessary if all you want is a nice label written on the sea?
>
I agree that there seems to be a tendency to be over-enthusiastic about
relations where a simple
polygon seems (to me) to be adequate. But that's probably because I don't
understa
[Tagging] Definitive mapper-feedback style (was: Re: Using multipolygons to map bays in Alaska)
On 17/11/2018 11:27, Frederik Ramm wrote: ... it is good to have a central map that provides valuable feedback, and keeps mappers from, say, introducing random highway types by simply not rendering them. I'd agree there, and unfortunately the OSM-Carto style isn't fit for purpose as that. It has too many conflicting goals (including "looking nice"), is far too central-European-city centric and bluntly doesn't support enough zoom levels for the details that mappers are adding in 2018 to appear (yes, you can use the OSM Carto style with zoom levels > 19 but you won't get any extra features appearing at those zoom levels, or changes to the width of features). OsmaRender used to have that role, even if it didn't always "look nice" (ahem - http://3.bp.blogspot.com/-BAxv_qi34yA/T2FK7q0NfpI/AG8/mZ8VKF4nHWc/s1600/geosuck-0002b.png ). Unfortunately I'm not aware of a style that "shows everything" in 2018. There are many different maps for different sorts of data (lots of transport maps, some 3d ones, etc.) but no "shows everything if you zoom in enough" style. Or am I missing something? Best Regards, Andy ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
On Saturday 17 November 2018, Frederik Ramm wrote:
>
> I do agree that while we should not "map for the renderer" it is good
> to have a central map that provides valuable feedback, and keeps
> mappers from, say, introducing random highway types by simply not
> rendering them. But I felt in this situation, they had overstepped
> their mandate, *especially* because they were not reacting to
> something that people were doing, but actively creating a new feature
> ("hey, you can now have huge named bays") and at the same time adding
> the data to OSM to illustrate their new feature.
Indeed.
And to make this very clear once again - no one suggested so far to
universally disallow mapping bays using polygons.
What has been said is that mapping bays with a node is the most common,
most widely accepted and (in my opinion) in the vast majority of cases
the most suitable way of mapping bays, in particular larger ones. And
OSM-Carto should support mappers in this practice and not steer them to
change it.
OSM-Carto has historically for as long as i can remember supported nodes
and polygons equally for features where both variants are commonly
accepted methods to map something - housenumbers is the most prominent
example probably - which can be mapped both on an address node or on a
building and are shown in both cases with no preference for either of
them. The same is perfectly appropriate to do for bays. What however
is not appropriate is to incentivize mapping bays with polygons by
labeling them from polygons in a different form that in particular for
large bays is more suitable and attractive than when mapped with nodes.
Or like for straits to label them when mapped with polygons but not
show them at all when mapped with a linear way.
--
Christoph Hormann
http://www.imagico.de/
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Using multipolygons to map bays in Alaska
Hi,
On 11/17/18 01:51, Paul Allen wrote:
> I'd find that bad enough even had he been right in his interpretation.
> Given how he has explained
> it so far,
...
Jumping back in here after a while, and assuming that the "he" here is
talking about me, let me offer a bit of backstory and explain why I am
unhappy about all this.
I'm doing a fair bit of map rendering myself, using a wide array of
different map styles, either self-made or made by others, and including
OSM-Carto.
OSM-Carto does two particular things with water rendering that not every
map necessarily does:
1. They use the same colour for the sea as for inland water areas.
2. They don't actually draw sea polygons; they have a blue map
background and then draw the land mass in grey on top of it.
While the wiki has been advising against rendering natural=bay in a
solid blue fill for a while (actually since Chris Hormann added a note
to that regard in January 2016), it used to make sense to disregard this
advice because you'd have many natural=bay areas that were not on the
sea but adjacent (e.g. Botany Bay used to be like that for a long time)
giving you white spots on your map otherwise. (OSM-Carto wouldn't have
this issue because their background was blue, but if you chose to have a
white map with sea polygons drawn you'd see it.)
So, long story short, a couple of "my" maps suddenly started to show
ugly dark-blue patches e.g. across the bay of Biscay, or the Gulf of
Bothnia. That's how I noticed and investigated what was happening, and I
found that Daniel had added the Gulf of Bothnia polygon to accompany the
newly-introduced OSM-Carto feature of rendering bay names depending on
the size of the area.
Of course I can adapt my map styles, and have indeed done so, as I often
have to do when mappers change their behaviour. But I was pissed off
nonetheless; I felt that OSM-Carto is just one rendering project and
does not (and should not) have the authority to steer what mappers do.
There are many other people interpreting our data and they should not be
forced to jump whenever OSM-Carto decides they want to change something.
I do agree that while we should not "map for the renderer" it is good to
have a central map that provides valuable feedback, and keeps mappers
from, say, introducing random highway types by simply not rendering
them. But I felt in this situation, they had overstepped their mandate,
*especially* because they were not reacting to something that people
were doing, but actively creating a new feature ("hey, you can now have
huge named bays") and at the same time adding the data to OSM to
illustrate their new feature.
Another pet peeve of mine is a dislike of what I call "relation mania",
where we have land boundaries that can easily be part of 20 different
relations on different admin levels and other boundary types. It's bad
enough on land, and makes editing harder for everyone; when I saw the
Gulf of Bothnia polygon (which *already* is large enough for the web
site to time out when you want to show the history) I thought: Is this
*really* necessary if all you want is a nice label written on the sea?
And let's be totally clear here: A nice label on the sea is all that
Daniel wanted. He's not a maritime scientist who for some reason needs
the exact extent of Bothninan Bay - he went through the time-consuming
exercise of combining more than 1600 coastline pieces into one huge
polygon which is difficult to handle for data processors and editors
alike JUST TO PLACE A LABEL.
It is only a matter of time until they start labelling natural=sea
polygons and people then create relations with 100,000 members for the
Atlantic.
If you are not interested in labels, then this is wrong because of the
side effects.
If you *are* interested in labels, then this is wrong because (a) it
means that you have to go through this huge exercise just to place a
label, and (b) the label will vanish as soon as someone breaks the
polygon by e.g. creating a small self-intersection along one of the 1600
coastline bits. It will probably be gone more often that it is there.
Summing up, my opinion is
(1) the OSM-Carto project and Daniel have overstepped their mandate as
the maintainers of our style, and should have sought a wider consensus
on this before acting;
(2) the decision they have made is not a good solution for the
cartographic problem they wanted to solve;
(3) the decision they have made will lead to people creating huge
polygons that will often break, make coastline editing harder, and have
at least one totally made-up edge.
And, I have to admit,
(4) Frederik has been an utter dick to try and start the discussion by
deleting the Bothany Bay polygon, instead of simply raising it here. It
was wrong, I'm sorry.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org ## N49°00'09" E008°23'33"
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/taggi
Re: [Tagging] Using multipolygons to map bays in Alaska
On Saturday 17 November 2018, Kevin Kenny wrote: > [...] > If I cannot be given an answer to such a concrete problem, I will not > accept that the reason is that I am too stupid or unskilled to > understand your superior wisdom. [...] To be clear i am not attempting to somehow proove something in this discussion. I provide advise how to approach the verifiable mapping of bays. That advise is and has always been (quoting here from my first reply): "My suggestion is and has always been to map bays with nodes in those cases where this - together with the coastline - perfectly documents the verifiable information available on the geometry of the bay" The existence of situations where this is not the case would not in any way invalidate my advise. And mappers following my advise or not for whatever reason is perfectly fine for me. That being said looking at the Jamaica Bay situation - i think we can agree that this is a hard case for labeling independent of how the bay is mapped in particular also on maps showing the entire bay because it is next to impossible to label the bay with a single label without undesirable collisions with other features. In contrast to other bay labeling cases i have not actually dealt with this kind of situation before. Still i think this is solvable and if someone would ask to contract me for developing a solution for this i would be highly interested because this would likely also touch several problems that are of significant use in cartographic generalization in general. A significant part of the problem is that with the current node placement it is borderline ambiguous if Jamaica Bay refers to the whole bay and Grassy Bay is only a part of it or if both refer to parts of the bay. To relatively robustly identify that is likely the tricky part. Apart from that the key here would be to identify the various islands within the bay to be within the bay and not part of the limitation of the bay. Once this is done and you have also analyzed the various sub-bays in the east (which look all relatively simple) you know the water at the western edge of your map sheet belongs to Jamaica Bay and the problem is solved. Not sure if that convinces you - as said my argument is not based on the claim that nodes are universally sufficient to document verifiable knowledge about bays. But in any case i want to be clear about one thing: > If it is a project that aspires to describe the whole world, it will surely have failed in that place. This is not what OpenStreetMap aims to do. This might be wikipedia's goal but OSM tries to collect verifiable knowledge about the geography of the world. That the existence of Jamaica Bay is part of that is not in dispute but still it is important to make that distinction. -- Christoph Hormann http://www.imagico.de/ ___ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
