Submarine Telecommunications Cable Landing Stations

Help and support Tagging help & support
1

If this has already been discussed, feel free to direct me to the post.

I am considering adding or revising tags on locations known as Cable Landing Stations (CLS). These are facilities where submarine telecoms cables terminate.

My first question: how should these buildings be tagged? At the moment I am considering:

  1. The site grounds: landuse=industrial + industrial=telecommunication + utility=telecom
  2. The building: building=service + telecom=data_center

Other tags like telecom=exchange aren’t an accurate representation of building function. In fact, telecom=data_center isn’t right either, but it seems the best fit for now. I also realize industrial=telecommunication isn’t currently a valid tag, but I am seeing it in the wild, so I’m just going with the flow.

A classic, stand-alone CLS is a network interconnect point: it would be unusual to install data center equipment like servers or storage arrays at a CLS. For those that know this infrastructure, having a CLS inside a data center building is increasingly common, but the CLS function itself has not changed (i.e., it’s not data center “stuff” going on at a CLS).

This leads me to my second questions: should these facilities be explicitly identified as a CLS? These locations are generally considered sensitive, critical infrastructure and often have national security concerns, so maybe they shouldn’t be explicitly identified. However, it’s not hard to find them: I’ve already looked at a few in OSM that are labeled as CLS in their name or in a note. There are public data sources for these locations inc. FCC filings (for systems landing in the USA) and often local property records from when the site was purchased and developed. I’ve found them on G Maps and there are speciality websites with info about these locations. So maybe attempting to obscure them doesn’t do anything?

Thanks in advance for any advice.

P.S. I have a long career history in telecom (fiber optic and mobile networks) and while not a submarine expert, I know enough that I feel comfortable proposing a sub-key and new values for:

  1. For BMH use: telecom:submarine=beach_manhole (new tag) + manhole=telecom
  2. For CLS building use: telecom:submarine=cable_landing_station (new tag) + building=service

I don’t really like building=service for this particular infrastructure, but as mentioned above building=data_center is misleading. Ideally, there would be a building=telecom and that would cover many situations.

Also, I know telecom=* doesn’t have any sub-keys today, but it seems like adding telecom=beach_manhole and telecom=cable_landing_station might be confusing without the submarine qualifier.

Finally, I personally wouldn’t bother with special PFE and SLTE tags as I doubt many (if any) mappers would drop pins for this type of equipment, but if they did:

  1. For SLTE use telecom=line_terminal (new tag) + manufacturer=* + model=*
  2. For PFE use power=terminal + manufacturer=* + model=*
1 Like
2
  • telecom= : Why is =exchange inaccurate, but =data_center the best fit?
  • building= : Why don’t you like =service ? building= are structures, and =service mean they are used for equipment or machines. There’s no need for =telecom etc, a building= for everything. =data_center is only a special case.
  • telecom:submarine= : No need for this. Whether it’s about this should be interpreted from what telecom= feature it is, or the telecom=cable + location=undersea at the location:transition=yes spatially. When the latter is drawn yet, it could be suggested as eg location:transition=submarine;underground
  • =beach_manhole
    • Overlaps with =manhole
    • =beach should be moved to service= / usage= / etc (appropriateness needs to be discussed), or simply use location:transition=submarine;underground
2 Likes
3

the tags you suggest are not sufficient to identify the site as cable landing station, if you wanted to look for similar sites you could not find them even if they all were tagged with the same tags. Never use a “best fit” tag if you believe it “isn’t right”.
I don’t know tags for these, but if there is nothing established you could make up and add something like man_made=cable_landing_station to make it clearer what it is about.

4

First, thank you very much for responding. I appreciate the suggestions.

In telecom, an exchange has two definitions:

  1. A telephone switching center (also called a Central Office (CO) or Public Exchange) which is a building containing equipment called a circuit_switch (or just switch)
  2. A geographic area defined by a telecoms operator as part of a broader network architecture

exchange goes back to the origins of telephone networks which required a rigid geographic structure due to copper signal transmission distance limitations. Take a look at a map like this one for Germany:

This is an area_code map, but one could also call it an exchange map; e.g., 20 = Western Ruhrgebiet, then exchange 1 (i.e., 0201) = Essen. In the copper days, dialing a phone number was literally dialing the exchange building near the person you wanted to reach. In the Public Switched Telephone Network (PSTN), copper wires are routed from homes and businesses to the nearest exchange.

Today, with modern mobile and VoIP networks having largely replaced copper networks, the exchange and switch are nearly extinct. Unless you are mapping something for a legacy copper network (which includes xDSL), the industry terminology is different:

  1. Hybrid Fiber Coax (HFC) (aka Cable) networks have a head_end building which houses a cable_modem_termination_system (CMTS) (HFC is usually associated with Cable TV companies (aka MSOs))
  2. Fiber to the Premise (FTTP) networks have a point_of_presence (PoP) building which houses an optical_line_terminal (OLT)
  3. 2G / 3G network have a mobile_telephone_switching_office (MTSO) housing a mobile_switching_center (MSC)
  4. 4G / 5G networks don’t map cleanly to exchange concept: it’s all about the core and there isn’t really a standard term for the building… I’ve heard terms like data_center, core_site, MSC and PoP in conversations with mobile operators

This is a long way of saying the word exchange was only ever relevant to copper networks.

data_center has a specific definition that is incorrect for a cable_landing_station. I picked data_center because it seemed the most commonly used in the community for this type of building, not because I thought it was correct.

If I was writing the definition for data_center it would emphasize servers, storage and other “IT equipment” with internal IP / ethernet networking being a supporting function and optical networking simply a byproduct of the site needing external connectivity. I would also move data_center from being a telecom value to a building value (someone else seems to think the same: Tag:building=data_center - OpenStreetMap Wiki ).

If the only function for a site is optical networking (and power supply) as is the case for a cable_landing_station, using data_center confuses things. For example, in long distance fiber networks, there are sites called amplifier or in-line_amplifier (ILA) and there are typically no servers, no storage, minimal IP / ethernet networking, no subscriber-facing equipment. There are probably a few thousand of these buildings around the world and they aren’t a data_center nor an exchange. A cable_landing_station is much closer to in-line_amplifier than data_center or exchange.

building=service is fine, I suppose: it’s what I proposed using in lieu of creating new tags. That said, we have building types for relatively rare locations (e.g., building=ship) and hyper-specific locations (e.g., building=allotment_house), but yet there’s no room for this very common, very important infrastructure category to have its own building type such as building=telecom? Not trying to argue, just pointing out the inconsistency we have in our community.

As for manholes, I think there’s a path with existing tags to create something that makes sense, so I don’t have more thoughts on that.

5

Not much semantics should be ascribed to building tag: broadly, it just means “this building looks like X from outside”, without strictly stating that it (still) has the function X. The canonic example is building=church, which may have been converted to a gallery or shop. The current function of the building should be expressed by other tags, commonly shop, amenity or man_made, placed on the building outline or a point within it.

So, for your case, building=service is probably fine. For example, I map a lot of irrigation canals, whose pumping stations I usually tag as building=service + man_made=pumping_station – not very different from your case.

However, there’s still a gap how to tag those cable landing stations, and at the moment it seems best to use (and perhaps document on Wiki) man_made=cable_landing_station. As a similar case, I looked at underwater power cables, but their endpoints typically end up in a power=substation near the coast, so not much similarity can be drawn with your situation.

6

Thanks for the comment. I don’t disagree with you about the existing tags I suggested: they aren’t a great fit. That said, I didn’t want to just make something up and see what happens.

The feedback from @Kovoschiz was useful. Thinking through their feedback alongside yours, it seems the starting point would be man_made=cable_landing_station and see if it’s adopted frequently enough to be “promoted” into the telecom key. Or does tag adoption into a formal key not work that way?

That said, when you look at what’s going on with the communication key ( Category:Communications - OpenStreetMap Wiki ), there’s clearly a need for a more holistic view of telecoms infrastructure. People are going very deep there: according to Keys | OpenStreetMap Taginfo , there are nearly 500 sub-keys and over 15,000 different key:sub-key:value combinations.

Those using the telecom key appears to be less inclined to invent new values, but many tags overlap with communication even though it appears the intent telecom is to be wired with communication for wireless.

OSM is 22 years old and I imagine if a working group were convened today to create the first telecom tags, they might adopt something that speaks to structures, functions and network types rather than adopting narrow terminology like exchange from copper networks:

  1. telecom:structure=* with values like demarc, cabinet, pedestal, vault, manhole, handhole that are likely modeled as NODE
  2. telecom:function=* with generic values like termination, aggregation, switching, amplification, interconnect that are found in many networks
  3. telecom:network=* with values like mobile, terrestrial, submarine (the network=* is key clearly for transportation)

telecom:function=* + telecom:network=* combined with building=service (or my wish list building=telecom… there are a few tags like this in the wild) and telecom:structure=* + telecom:network=* combined with telecom=line seems like how it might turn out. If this were in place, cable_landing_station would become:

  1. building=service (or ideally building=telecom)
  2. telecom:function=termination;interconnect
  3. telecom:network=submarine;terrestrial
  4. name=Lorem Ipsum CLS

Of course, we aren’t going to revamp telecom in a community thread, just thinking out loud.

1 Like
7

Cool. I see the consensus forming here: building=service + man_made=cable_landing_station has 2 votes. Thanks. I’ll work out how to add it to Key:man_made - OpenStreetMap Wiki.

8

Actually, I think that telecom=cable_landing_station would be better still. I was not aware of the telecom key.

1 Like
9

me to . . . . . (I as well)

10

Although telecom=cable_landing_station is acceptable, I’m wondering if telecom=station + station= should be used, similar to pipeline=substation + substation= + following power=substation

11
  • telecom:structure= Again, this is still duplicating other features. Besides =manhole , =cabinet has man_made=street_cabinet already.
  • telecom:network= : Service vs Infrastructure should be distinguished. =mobile is cellular. =terrestrial and =submarine are the environments of infrastructure. There’s communication:mobile_phone= , and already the mistake of communication:space= mixing up (which can be radio, microwave, or laser). Others can be reviewed together. https://wiki.openstreetmap.org/wiki/Key:communication:*
12

how such building looks like? Do you have photos?

13

The architecture varies. There are several on Wikimedia Commons. Here are three examples:

https://commons.wikimedia.org/wiki/File:KDDI_CHIKURA_Cable_Landing_Station.jpg#/media/File:KDDI_CHIKURA_Cable_Landing_Station.jpg

https://commons.wikimedia.org/wiki/File:ACE’s_Duynefontein_landing_station.jpg#/media/File:ACE’s_Duynefontein_landing_station.jpg

https://commons.wikimedia.org/wiki/File:Danice_Greenland_Connect_Landeyjarsandur_Iceland.JPG#/media/File:Danice_Greenland_Connect_Landeyjarsandur_Iceland.JPG

14

Thanks. Perhaps I failed to get this point across:

if a working group were convened today to create the first telecom tags

I recognize many features exist, but having been added over time by different people in different parts of the key structure, it’s not always easy for mappers and data consumers to find them. There are also overlaps in what exists today; e.g., man_made=street_cabinet is very similar / same as telecom=connection_point.

=mobile, =terrestrial and =submarine each represent a different service AND a unique infrastructure type. This duality (service + infra) is well recognized within the industry. =satellite (rather than =space as suggested in wiki.openstreetmap.org/wiki/Key:communication:*) is a similar dual-use term for service and infra and would be an important and unique fourth value.

15

An observation (not directed at anyone in particular… just putting this out in the world)…

man_made=* seems to have become a catch-all: it’s like having other=* or miscellaneous=* and it’s confusing to many people (not just myself) as the supermajority of OSM features are man made. Why do most other keys exist rather than simply putting roads, buildings and everything else humans have built into man_made=*? I suspect I’m probably the 1,000th person to ponder this and wonder if there will eventually be an attempt to migrate the tags in man_made=* into new tags using appropriate keys.

There are proposals out there for migrations like this. For example, this one discourages use of man_made=street_cabinet + street_cabinet=* in favor of man_made=street_cabinet + utility=* for several utility infrastructure types (including telecom):

While different than retiring a man_made tag, I view this as a starting point for the community to rally around: separating the object / structure from its function / application.

Another is: wiki.openstreetmap.org/wiki/Key:communication:*. This proposal needs refinement (it mixes flavors of radio towers which are being mapped in OSM with whole communications technologies which aren’t things in the physical world), but it represents the seed for migrating some items from man_made=* into a logical tag grouping:

  • man_made=antenna, man_made=communications_tower, man_made=guy_wire and man_made=mast are obvious candidates for man_made retirements
  • man_made=telescope (+ telescope:type=radio) and man_made=satellite_dish are very similar from a structure perspective, but with different technical implementation… so they could be combined in someway and migrated to communications=*
  • Many instances of man_made=tower are in fact communications related: famous landmarks like the Eiffel Tower and Tokyo Tower (aka Japan Radio Tower) house radio, TV and/or mobile network antennas
  • I note the definition for man_made=tower is what is often called a “self-supporting” tower while BT Tower, CN Tower and Telkom Joburg Tower (aka Hillbrow Tower) presumably would be man_made=communications_tower or perhaps they are simply a super-sized man_made=mast (or what’s often called a “monopole” tower)
  • What the community is calling man_made=antenna is more accurately described as a “guyed” tower (or “guyed” mast) and man_made=guy_wire should be associated with with man_made=antenna while an antenna is an object (with many form factors) and function applicable to all the different “tower” structures
  • Another overlap within the current man_made is man_made=telescope (+ telescope:type=optical) which is usually equipment inside man_made=observatory

To be sure, rationalizing man_made is a daunting effort with data usage implications, but it seems worthy of the effort.

IMHO, it would be great if the community could step back and rationalize telecoms infrastructure tags currently spread across telecom=*, communication=* and man_made=* into an easy to understand structure (plus some alignment with seamark:type|cable_submarine), but there may not be interest to do so.

Or maybe this could be solved by having more wiki pages covering domain-specific tagging “standards” so people know how they should tag something using existing tagging schemes? This wouldn’t replace this forum, but I suspect there are many more people who would use a resource like this than would open a community forum account and a create a tagging question post.

I’m also trying to follow GitHub projects like:

  1. KathmanduLivingLabs/OSM-chatbot
  2. hotosm/osm-tagger
  3. gander-tools/osm-tagging-schema-mcp

OSM is an amazing project, but it’s growing more difficult to use given the spread of wild tags.

16

man_made is just fine, as long as you do not try to make it do heavy lifting. As it description says, it covers all “artificial structures other than buildings.” (And a building is defined as something that has a roof and where humans could enter and potentially dwell.)

The idea here is that mappers do not have to be subject matter experts to document what is the function of a man-made structure, and just populate the database with what they see: a tower, a street_cabinet, a manhole. Sure, there are few outliers which should not be there (such as the telescope you mentioned), but I don’t think the key is broken.

Separating the form (building=*, man_made=*) and the function (utility=*, communication=*, power=* etc. ) allows mappers and data consumers to have semantic “layers”. For example, (at least in theory) you could map and/or extract the whole logical structure of a electric power network just by examining objects tagged with utility=power and/or power=*.

The proposal about retagging street cabinets was exactly about that: the “old style” tagging classified the function (or at least, mixed up the form and function) under the street_cabinet=* key. This was identified as broken tagging and duly deprecated.

2 Likes
17

Early preview: for Cable Landing Station, I created:

and:

18

Somewhat embarrassing to admit, but I misunderstood Key:communication:*'s usage at the time I wrote my original “An observation…” Comment above. I can no longer edit that Comment, so adding a new Comment to correct my mistake as well as making a more refined set of observations about towers after digging deeper into available tags.

I didn’t want to simply delete my Comment and add this new one since others had Commented against the original and I also didn’t want to leave my flawed thinking out there. I don’t expect many will read this new version, but at least it’s out there.

An observation (not directed at anyone in particular… just putting this out in the world)…

man_made=* seems to have become a catch-all: it’s like having other=* or miscellaneous=* and it’s confusing to me as the supermajority of OSM features are man made. Why do most other keys exist rather than simply putting roads, buildings and everything else humans have built into man_made=*? I suspect I’m probably the 1,000th person to ponder this and wonder if there will eventually be an attempt to transform how many man_made=* objects are tagged.

For example: Tag:man_made=street_cabinet discourages use of man_made=street_cabinet + street_cabinet=* in favor of man_made=street_cabinet + utility=* for several utility infrastructure types (including telecom). I really like how the community chose to separate the object and function.

Another example: Key:communication:*. This proposal needs refinement (it’s incomplete), but it’s another attempt to divide the object and function.

If we like this separation (and there are many examples, I just picked two related to telecom), then perhaps some objects in man_made=* should be combined with existing functional tags used to differentiate:

  • Combining man_made=antenna, man_made=communications_tower and man_made=mast into man_made=tower seems an obvious move
  • Maybe man_made=lighthouse could also go into man_made=tower and historic=round_tower and historic=tower could go into building=tower + historic=yes (or historic=building) … there may be more opportunities like this

As it stands, the current tower flavors combine structure and function and often overlap with one another:

  • man_made=tower depicted on the man_made=* page is “self-supporting” (or “freestanding”) + “lattice / truss” + “steel” while the man_made=tower page info box shows a watchtower or more specifically “mass-gravity” (or “freestanding”) + “masonry” + “stone & morter”
  • What the community is calling man_made=antenna is a mix of “self-supporting” + “lattice / truss” + “steel” and “tension-supported” (or “guyed”) + “lattice / truss” + “steel”
    • man_made=guy_wire should mostly be associated with “tension-supported”, though a structure like GerbrandyTower would be an exception
    • an antenna is an object (with many form factors) and function applicable to all tower types (and many building types)
  • man_made=mast depicted on man_made=* and man_made=mast is “self-supporting” (or “freestanding”) + “monopole” + “steel” or “concrete”
  • man_made=communications_tower like BT Tower, CN Tower and Telkom Joburg Tower (aka Hillbrow Tower) are unique and also relatively rare compared to other types, but man_made=communications_tower’s distinguishing characteristic appears to be “really big, typically >= 100 m”; of course, there are hundreds of communications-related towers (radio, TV, mobile) that meet this height criteria, so separating design type, construction method and function would improve clarity and searchability
  • man_made=telescope (+ telescope:type=radio) and man_made=satellite_dish are very similar from a structure perspective, but with different technical implementation
  • man_made=telescope (+ telescope:type=optical) is usually equipment inside man_made=observatory

To be sure, rationalizing man_made is a daunting effort with data usage implications, but it seems worthy of the effort. Much of the work has been done with tower:type=*, tower:construction=* and material=* in place for (and presumably other man_made objects have similar supporting tags), but the final step of consolidating these man_made objects hasn’t been taken.

IMHO, it would be great if the community could rationalize telecoms infrastructure tags currently spread across telecom=*, communication=* and man_made=* into an easy to understand structure (plus some alignment with seamark:type|cable_submarine), but there may not be interest to do so.

Or maybe this could be solved by having more wiki pages covering domain-specific tagging “standards” so people know how they should tag something using existing tagging schemes? This wouldn’t replace this forum, but I suspect there are many more people who would use a resource like this than would open a community forum account and a create a tagging question post.

I’m also trying to follow GitHub projects like:

  1. KathmanduLivingLabs/OSM-chatbot
  2. hotosm/osm-tagger
  3. gander-tools/osm-tagging-schema-mcp

OSM is an amazing project, but it’s growing more difficult to use given the spread of wild tags and the different approaches to tagging structure.

19

Is this what you have in mind?

21

Thank you, yes. I have seen this and is a reasonable start. Perhaps I will just contribute to that page and its discussion and see where it goes.