facebook
Coastline on islands isn't displayed.
Description
I'm not sure if this is a bug or not actually. What I noticed is that if I tag a closed way with "natural=coastline" Rapid adds the nice coastline marks that show what side of the line the water is on. This coastline marker is very useful when mapping the coast I always make sure I don't mess up the coastline especially when it is an international coast... Anyway... When I add the "place=island" to the way to indicate that it is an island the coastline marker goes away. Would it be possible to make the coastline markers show up even when the place=island tag is applied?
Version
2.0.3
What browser are you seeing the problem on? What version are you running?
Chrome v114.0
The OS you're using
mac
Steps to reproduce
After adding the natural=coastline tag:
After adding the place=island tag:
I guess what I would expect is to continue to see the coastline marks no matter what other tags are applied to the way.
The browser URL at the time you encountered the bug
https://mapwith.ai/rapid#background=mml-orto&datasets=fbRoads,msBuildings&disable_features=boundaries&id=w-1&map=19.15/60.29518/19.69900
The auto-detected useragent string for your browser (leave blank if you're manually filling this form out)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
Just checked this functionality vs. v1 and it is not a regression(good!) but I agree it might be nice to see the arrows without needing to delete the 'place=island' tag.
The more I think about it, the more I think we need a series of very specific user preferences in a single panel where things like this can be called out.
I think this happens because both place=island and natural=coastline are 2 different presets, so if a feature has all those tags, the preset matcher could reasonably pick either of those things.
This is a long standing issue with osm's tagging system that if a feature has a lot of tags, the preset matcher will only match one thing.
(I don't see this as an issue with user preferences)
Fair enough! I've been devoting some time to thinking about ways we can allow the user to have more power over rendering data in Rapid, and the idea of a preferences panel has been rolling around in my head.
the island should not be part of the relation of the water body? so should be displayed in another way (water outside) of the perimeter...
the island should not be part of the relation of the water body? so should be displayed in another way (water outside) of the perimeter...
@jjiglesiasg - this is in the ocean. I don't believe that oceans have water body relations necessarily (or do they??). The coastline tag is used along the coast line to define where land masses start and end. In many places along the coast people have used the natural=bay tag to represent the area of the ocean near the land, but I don't think it is necessary. In general Rapid doesn't render the ocean water unless someone has used natural=bay. But the coastline triangle markers are there to indicate that this is a coastline because coastlines are handled differently than other tags in OSM.
I just think it is worth indicating that a line is a coastline no matter what else it is because of the delicate nature of the coastline processing. That's why I was curious about how Rapid was rendering it.
I just think it is worth indicating that a line is a coastline no matter what else it is because of the delicate nature of the coastline processing. That's why I was curious about how Rapid was rendering it.
Yes - sorry I should have said above - I do agree that we should render the directional triangles regardless of what preset the thing gets assigned.
I know it's weird, but this is sort of caused by #719 - where we have different rendering code paths depending on whether a feature is decided to be a line or an area. By adding the place=island tag, it sends this feature to the area code, which isn't equipped to draw line stuff. The goal of #719 is to improve how this works.