These are some ideas I have about how to improve the map and all its related apparatus.
They're all pre-proposal and I usually tinker with the wording a lot over time, since I treat this as a doodle pad before posting the final draft elsewhere.
Thoughts in response are very welcome at any stage of gestation!
NOTE this is a draft hosted on Eteb3's userpage. Please consult Eteb3/eteb3 before editing.
|barrier = boom|
|A chain or cable across a body of water, preventing passage to watercraft or debris. Usually supported by a line of floats or buoys.|
|Used on these elements|
|Status: de facto|
|Tools for this tag|
|Two different features are mapped using this tag. For a lifting barrier across a highway or similar, consider using barrier=lift_gate. See further below.|
A boom is a chain or cable across a body of water, which prevents watercraft, debris or other unwanted objects from passing. It is usually on the surface of the water, supported by floats or buoys.
Booms have several common uses:
|To prevent boats passing down a channel.||Passage blocked to watercraft at the approach to Knottingly weir, West Yorkshire, UK.||maplink|
|To interdict an area of open water or to restrict it for certain users.||Roped swimming area at the Beach Rotana Hotel in Abu Dhabi, UAE.||maplink|
|To stop trash and debris.||Debris catcher upstream of Queen Elizabeth Bridge, Belfast, Northern Ireland.||maplink|
|To stop invasive species such as water hyacinth.||Weed control boom by the aquatic boom company Elastec (of Carmi, IL, USA). Location unknown.||n/a|
Temporary booms are used to prevent the spread of oil spills: they are less likely to be relevant to mappers.
How to map
Draw a way along the barrier location and tag it barrier=boom.
Tags in combination
In addition to barrier=boom, it is helpful to add the OpenSeaMap tag seamark:obstruction:category=boom so that OpenSeaMap renderers can interpret it correctly.
A boom can be assumed to be floating unless submerged. If submerged, you could also add the depth range values (if you know them). This is very useful for navigators.
Minimum and maximum refer to situations where the water is tidal or changes in depth for other reasons. If the depth does not change, the creator of this page suggests giving the same value for each tag, to help with machine parsing.
The tag waterway=floating_barrier has been used around 105 times (at 2020-09-29). The higher number of uses probably doesn't represent greater consensus: the tag occurs only in western Europe, and the vast majority (~85%) are by a single user in the UK.
The tag is likely to be questioned by mappers who would like waterway=* to be reserved for real ways along which water flows (rivers, streams, etc), rather than including features associated with water generally.
Nonetheless, as the alternative tags each use a different key, there is no reason why one feature cannot have both, in addition to the OpenSeaMap tag.
On a highway, etc.
In some dialects a lifting road barrier is called a boom barrier, boom gate, or lifting boom (Wikipedia).
Consider using the more usual barrier=lift_gate for this feature. Around 300,000 nodes have this tag at 2020-09-27, compared with 12 nodes tagged barrier=boom.
Sun-based access times (2019-11-16)
For coding opening times of Muslim places of worship
There are ~5 cases of Muslim prayer times being used in opening times, and hopefully many more as the map grows - Muslims are ~25% of the global population. (It's probably reasonable to suppose that there would be greater use with a documented tag.) Any system developed may have wider applicability.
Muslim prayer times are determined by the sun: dawn, midday, late afternoon, sunset, nightfall. Things are complicated by different definitions of dawn, late afternoon and nightfall among different schools of thought.
There are only a handful of cases, but the practice seems to be to simply list out the times (by their Arabic names, with various transliterations) and rely on a user's local knowledge to interpret these into clock-time. E.g.,
service_times=fajr;zhuhr;asr;maghrib. For practising Muslims this is completely intuitive, and is probably completely adequate in most cases. (It was my practice too, until I was told that it is not consistent with the tagging syntax/policy.)
For anyone trying to code the opening/service times of Muslim places of worship my guess is that the current practice will become de facto. So standardising the approach (particularly spellings) will be useful.
But in the UK (where I'm based) the variety of Muslim practice means the same term can mean slightly different things in mosques just across the street from each other. It would be useful to provide further tags for this.
And, the current practice can't be machine-parsed to give clock-time.
1. Standardise the sun-time values
Adopt the spelling below, which uses the US Library of Congress transliteration, simplified to pure alphabetic:
fajr; zhuhr; asr; maghrib; isha
Rationale: I think it is unrealistic to use English terms, as there is no real English equivalent for most of them. Further, English terms are never used among Muslim speakers of British English (unless self-consciously interpreting the religion to outsiders): the Arabic terms effectively are English words in Muslim contexts (as indeed "Ramadan" is for Brits generally). AFAIK the same applies across other languages except in the Turkic regions.
Of the six current instances of the Arabic terms in the map, three are by contributors with manifestly excellent English, apparently native or bilingual Anglophones.
So granted Arabic, the spelling needs to be consistent.
We should consider additional options to further specify the sun-times:
- Definitions vary for asr ("late afternoon"). I suggest attributes of
asr=2for the two definitions in use. (This is effectively the practice of the Nautical Almanac Office, a government agency in the UK.)
- Definitions also vary for fajr and isha. I suggest attributes with a value of any integer degree of sun's elevation - especially
-6(for dawn/dusk at astronomical/nautical/civil twilight).
- Example tag:
fajr=-18=> Fajr is at beginning of astronomical twilight in the morning.
3. Accept before/after
fajr - 01:00, by analogy with the existing usage
sunset + 01:00. This would be useful for mosques that open, say, 1 hour before dawn prayer is called.
We could adopt a universal (not Muslim-specific) system, using values for sun's elevation instead of the Arabic terms.
*=sun-18AMcould indicate the beginning of astronomical twilight in the morning, and
*=sun-18PMcould indicate beginning of astronomical twilight the following evening.
At the moment I feel this is less suitable:
- It would be unlikely to win much take-up among Muslims who know the 'Arabic sun times' system, as it is too far from their natural language and everyday life.
- Even with the variation in definitions, the Arabic terms are good enough as a first-base solution. We should standardise those first, and also offer tags allowing further specification - if needed, or to enable machine-parsing.
- A universal 'sun's elevation' system will require more technical knowledge (of astronomy and of religio-legal principles) than the vast majority of Muslim mappers are likely to have.
Current usage (Nov 2019)
|Mosque name||Country||OSM datalink||Attributes|
|Mosquée de Fribourg||CH||service_times=Open from Fajr to Isha|
|Kodikuthmala Juma Masjid, Kerala||India||service_times=Fajr, Dhuhr, Asr, Maghrib, Isha'a, Jumua'a|
|Kattungachira Juma Masjid, Kerala||India||service_times=Fajr, Dhuhr, Asr, Maghrib, Ishaa, Jumuaa|
|Mosquée Annajat||Morocco||service_times=Fajr, Dohr, Assr, Maghreb, Ishae|
|Masjid Rahmat Kampung (F) Lembah Klau||Malaysia||service_times=Subuh, Zohor, Asar, Maghrib, & Isya|
|Surau Amanputra||Malaysia||service_times=Subuh to Isya'|