Personally, I think that crossing:island=no should not be added at all as it is implied, at least in Fl and likely the whole US, if a crossing actually has a traffic island then add it. I would also say that crossing:island=yes should only be added if there isn’t a separately mapped traffic island, so footway=traffic_island, if you are mapping to a level of detail (like the PWG bronze tier) that is not high enough to contain separately mapped traffic islands or do not have the imagery quality to do so then add crossing:island=yes if you please, as it is important. But if the traffic island is already separately mapped then adding crossing:island=yes should not be done as it is duplicating information that is already in the pedestrian network. This is a major bug bear of mine when apps like Streetcomplete add this tag and tactile_paving=* to crossings were these are already mapped separately within the pedestrian network. I could see crossing:island=separate as a solution, if it is to much for editors to detect when traffic islands are mapped separately and thus the tag shouldn’t be added, but I would be very unhappy with it, but it would be what it is, and would be better then the plain =yes.
And yes this means that as long as there is one or more separately mapped footway=traffic_island between any two (or more) footway=crossing’s then the crossings have a traffic island and thus crossing:island=yes is not needed as the information is already in the pedestrian network making the addition of the tag duplicate at that point. If you have crossing:island=yes on a crossing that is mapped to a lower level of detail and are bringing the level of detail up to the point where you are mapping the traffic island separately then add the separate footway=traffic_island and remove crossing:island=yes from the crossing ways.
The argument for crossing:island=no is that it indicates a survey has taken place and that there is no crossing island, the lack of a crossing:island tag indicates that a survey has not yet been carried out.
The thing is that most crossings do not have a traffic island, so it is implied to be no. Should we add oneway=no to all non oneway roads just because that would indicate if oneway has been surveyed, I’d argue not. Same logic applies here. If you really want to indicate that a crossing has been surveyed add check_date=*.
it’s not just oneway=no, that’s just the first that came to mind, there is also foot=no on motorways (at least in the US), there is noexit=no, and meany, meany other tags that are implied to be no if not added. The point is that there is existing precedent for things to be simply implied.
Hm, the footway=crossing isn’t the interesting one, but the way connected to it with footway=crossing_island, which the node is not part of.
logically you’d route along;
This doesn’t have a separately mapped traffic island.
footway=sidewalk
(barrier=kerb node and/or way)
footway=crossing which spans over at least one connected node on a e.g. highway=primary
(barrier=kerb)
footway=sidewalk
And if the island is separately mapped:
footway=sidewalk
(barrier=kerb node and/or way)
footway=crossing with exactly one connected node on a e.g. highway=primary
(barrier=kerb)
footway=traffic_island
(barrier=kerb)
footway=crossing with exactly one connected node on a e.g. highway=primary
(barrier=kerb)
footway=sidewalk
Which also means that for any intersection to be logically correct in itself there need to be only separately mapped traffic islands, or none, or some other way to distinguish a mix.
But if the traffic island is already separately mapped then adding crossing:island=yes should not be done as it is duplicating information that is already in the pedestrian network.
should we also not add bridge=yes on highways if there is already a man_made=bridge object?
One could argue that if it’s connected to the highway on both ends, yes.
I don’t know it that’s technically a good idea, or if it’s knowable by software, but logically it seems it is.
To me it’s the same argument as with amenity=school on the building and the surrounding area too, that logically duplicates the school, even if one has no name or other details. The solution is to not tag it twice, or use another tag, landuse=education.
Yes, because it is possible to tag schools on a plot and on a building, which however isn’t the case for a bridge (way with hw=* , vs. area).
To me it’s the same argument as with amenity=school on the building and the surrounding area too, that logically duplicates the school, even if one has no name or other details. The solution is to not tag it twice, or use another tag, landuse=education.
to me the school example is not comparable, as it would be mapping 2 schools, which is not what bridge=yes does, it doesn’t say this is a bridge, it says the road is on the bridge, and if there are two close parallel bridge=yes highways, chances are these are on the same bridge and not two bridges.
The same for traffic_island. crossing:island=yes is not representing a traffic island, it is a property to state the crossing has an island.
Then it is currently impossible to distinguish whether a crossing island needs to be mapped separately, or already is, from looking at the nodes alone.
– Unless we’d introduce the =separate (and maybe there needs to be a way to specify the direction too, for mixed mapping, though I’d argue, let’s just not do that)
Also means that any <e.g. footway>:crossing way needs to 1) have the tag crossing:island=*, and 2) say if it’s separate or not.
Edit:
Come to think of it, there is no value to explicitly say non-separate, the =yes contains too little information to say that one way or another.
So it’d be better to say that =yes is discouraged, and the use of either =separate or “a value for non-separate” is always to be preferred.
Both on the footway=crossing way, and a highway=crossing node.
These are different things in my head, traffic islands ways (footway=traffic_island), if mapped separately are inside of the pedestrian network, so the information is already there when navigating through it but bridge areas are not within the pedestrian, road or any other network, some are physically connected (though vertices), but even that is not guaranteed. On the other had if traffic islands are mapped separately are part of the pedestrian network and thus the information is already there in the network.
yes I agree, that’s why I voted for “Something else” because if we’re micro-mapping I don’t see the point of adding for one and the same feature multiple data
If you only have a footway crossing over a street with two roadways that are only segregated for a traffic island, yes, you can know if it’s missing a footway=traffic_island in the middle.
If there are more than two roadways (slip lane, tram rails), and there is one footway=crossing between only two of them, how do you know if there is or isn’t another island?
The route over footways could be:
sidewalk
crossing A
crossing-node over highway N
crossing A continued
crossing_island
crossing B
crossing-node over tram tracks
crossing B continued
crossing-node over highway S
crossing B continued
sidewalk
Is there an island missing between the tracks and the highway S?
The problem to me is that B spans two highways.
(What if B is split up into multiple parts?)
What could the values on the crossing-nodes be?
(Incomplete list, and some are obviously wrong for the above example):
Which of these cases has a missing island?
Which of these doesn’t have a missing island?
Which of these is wrong, incomplete, or a contradiction?
How sure can we be that the values have been taken correctly – not misinterpreted, tagged for the whole crossing in it’s entirety, or only from one walking direction/perspective?
Which combination should be correct?
Is there any other way to encode the information?
On the crossing-nodes, or on the footway=crossing?
What if the footway=crossing is split up into multiple parts, what if it’s split at a crossing-node?
If the pedestrian features in an area has been mapped to the level of detail where footway=traffic_island is mapped separately then, once the mapping at that level of detail is complete, the footway=traffic_island will be inside of the pedestrian network. If you find an intersection where some of the crossings have been mapped with separate footway=traffic_island but others haven’t then split the ones that haven’t to include the separately mapped footway=traffic_island and at that point they will be included. routers have to assume that if crossing:island=yes is not on the crossings any separately mapped footway=traffic_island are all that there is, if that is wrong then fix it, OSM will always have issues in the data, when you find them you fix them.
As a note, all of my examples are in Miami Dade County as that is the area I know best and do most of my mapping inside of.
Example 1:
My first example is the intersection of Southeast 26th Road and Brickell Avenue, there are several separately mapped footway=traffic_island’s at the intersection, take way 758621030, it is in the median of the road with crossings on either side that themselves connect on the other side of the respective carriageway they are on to separate traffic island.
Example 2:
The second example is the intersection of Southwest 13th Street, Southwest 3rd Avenue, and Southwest 15th Road, this is a roundabout, as a note this roundabout has some funky details like traffic lights on the approaches for the cars that are basically only for the pedestrian crossings. The example way here is way 1232520419, this one is also in the median.
There are other examples if they are needed, there are even some much simpler ones if they are needed.
Because I am intrested to see, how it looks like in other countries. I asked myself. And what to do with this tag, should I get rid of crossing:island=yes, but always visualise to see, what is mapped.
Should I keep it in a experimental preset, therefor ?, in front. But sometimes I need it, to correct tagging and I do not want to detail it more. And must I set it to delete it in the preset when setting footway=traffic_island by leaving the value empty.
<key key="crossing:island" value=""/>
Is this correct? Deleting on such a way. I am not sure.
On the other hand at (orange) there is a crossing:island.
Should I set it on every (orange)? Or with kerb=lowered and not with flush, this is just more detail mapping. If others do it, what to remove or not.
The mapper makes a choice about the detail, but I like to have tools to see them and correct them. Although not go further in detail.
