This post is a rescue mission for a quite old comment I’ve made on the Danish computer science publication version2.dk. As the publication is beginning to put up pay-walls around their articles I’ll repost comments here to keep my own writing out in the open.
It is a comment to an article detailing how the Danish telecom company TDC (previous state driven monopoly Tele Danmark) fails to adhere to the GPL license when distributing a network device built on the GNU/Linux distribution OpenWRT containing large amounts of GPL licensed software.
Link to original comment: version2.dk/artikel/tdc-vi-har-dummet-os-med-open-source-licens-140230#comment-304571
Reproduction of original Danish text:
15. april 2015 kl. 12:05 “..som GPL V2 ellers lægger op til..” Kan ikke lade være med at finde det påfaldende at man er så skrigende subjektiv i rapporteringen når man forholder sig til brud på copyright. Virksomhedernes holdning skinner selvfølgelig igennem, men en neutral presse burde rapportere mere objektivt end dette. Den selvsamme forseelse ville man formentlig kalde pirateri og opfatte som vækst/samfunds/forretnings-undergravende, hvis det drejede sig om systematisk copyright-brud på proprietær software som et specifikt og veldefineret firma tjener penge på. Men fordi dette er fri software(/open source), som kun har potentiale til at komme hele menneskeheden til gode, så opfattes licensen som noget der er “lagt op til”. Det er jo hovedrystende forudindtaget. Bestemmelserne i GPL er selvfølgelig lige så gyldige som ethvert andet sæt betingelser en ophavsretsindehaver kunne finde på at videredistribuere sit værk under. Angående sagens substans er betingelserne i GPL v2 klare og veldefinerede og har været det siden 1991. Det kommer ikke bag på nogen der har fingrene i sovsen, heller ikke sagem/sagemcom som har været med længe, at brugeren skal gøres opmærksom på at et produkt indeholder GPL-software, og at kildekoden der anvendes i produktet skal gøres tilgængelig for brugeren. Alt andet er klaphatteri og klamp, usympatisk, undergravende og uden respekt for det arbejde der profiteres af ved at anvende fri software som grundlag for sin kommercielle eksistens. Man må følge reglerne eller lade være med at lege med hvis man ikke er i stand til at sætte sig ind i dem, det forlanger virksomhederne også selv af deres kunder. Godt at se at der er velvilje fra TDC, det burde bare have foregået på forkant i stedet for bagkant. Håber dog de får fat i nogle mere kompetente mennesker at spørge end dem der har svaret “Boksen kører BUSYBOX Linux”, ellers er det op ad bakke. Mikkel
“..som GPL V2 ellers lægger op til..”
Kan ikke lade være med at finde det påfaldende at man er så skrigende subjektiv i rapporteringen når man forholder sig til brud på copyright. Virksomhedernes holdning skinner selvfølgelig igennem, men en neutral presse burde rapportere mere objektivt end dette.
Den selvsamme forseelse ville man formentlig kalde pirateri og opfatte som vækst/samfunds/forretnings-undergravende, hvis det drejede sig om systematisk copyright-brud på proprietær software som et specifikt og veldefineret firma tjener penge på. Men fordi dette er fri software(/open source), som kun har potentiale til at komme hele menneskeheden til gode, så opfattes licensen som noget der er “lagt op til”. Det er jo hovedrystende forudindtaget. Bestemmelserne i GPL er selvfølgelig lige så gyldige som ethvert andet sæt betingelser en ophavsretsindehaver kunne finde på at videredistribuere sit værk under.
Angående sagens substans er betingelserne i GPL v2 klare og veldefinerede og har været det siden 1991. Det kommer ikke bag på nogen der har fingrene i sovsen, heller ikke sagem/sagemcom som har været med længe, at brugeren skal gøres opmærksom på at et produkt indeholder GPL-software, og at kildekoden der anvendes i produktet skal gøres tilgængelig for brugeren.
Alt andet er klaphatteri og klamp, usympatisk, undergravende og uden respekt for det arbejde der profiteres af ved at anvende fri software som grundlag for sin kommercielle eksistens. Man må følge reglerne eller lade være med at lege med hvis man ikke er i stand til at sætte sig ind i dem, det forlanger virksomhederne også selv af deres kunder.
Godt at se at der er velvilje fra TDC, det burde bare have foregået på forkant i stedet for bagkant. Håber dog de får fat i nogle mere kompetente mennesker at spørge end dem der har svaret “Boksen kører BUSYBOX Linux”, ellers er det op ad bakke.
Mikkel
I took the chance on a summer day last year, 2019-06-20, to take a peek at the construction site of the Norwegian Bulk Infrastructure data center DK01 Campus being built in Kjersing, Esbjerg, Denmark. The pictures were stowed away until now but I think they deserve to be set free, so here goes.
The data center is a part of Bulk Infrastructure’s involvement in the Havfrue/AEC-2 subsea cable system (link to a previous blog post with details), built in cooperation with Google and Facebook, which is going to land on the Western shore of Jutland in the near future (ready for service expected in 2020-Q3). Bulk Infrastructure is going to build and operate an extension of the main cable trunk (with reduced capacity) to Norway and its datacenters present there.
It seems the DK01 Campus data center is going to act as an exchange point between other fiber networks Bulk is involved in and also landing in Esbjerg;
Havfrue
Havhingsten
Havsil
The location in Esbjerg is indicated by the orange area outline on the map below, courtesy of OpenStreetMap.
Arriving to the area from the highway driving along the Kjersing Ringvej the site is partly visible at your left hand.
Taking the 3rd exit in the roundabout onto Guldborgsundvej and turning the first left corner the site is just in front of you on the right.
Getting close the inner construction work is visible through the still open facade.
Stepping out and taking a snapshot closer to the fence.
Walking around the end of the building. Small compartments are visible.
At the other side there’s some foundation extending from the tall white wall barely visible. It is probably going to have lighter walls erected. Could be administration offices, where the high ceiling room with walls already standing is the main data center hall.
A lot of temporary arrangements on site for the construction period and site protection.
For the guests, like me, there is even a nice information board with outline map showing some details. As anticipated, offices on left side of the data center hall (right side of the building in the yellow marking, map is facing North, most pictures taken South-West). And also smaller rooms in the hall itself in the Northerne end of the building that we saw above. This is probably to be able to segment co-located equipment for restricting access.
My VCTA tracks pr. 2020-09-24 visualised by some hackish javascript on tools.mikini.dk/vcta (code).
The start of the Wadden Sea dykes at Roborg near Tjæreborg. National cycle route 1 (N1 – Vestkystruten) runs along here. Location: 55.45083;8.56325
In front of Sneum Sluse, where Sneum Å joins the sea. Location: 55.43321;8.60780
Along the dyke between Sneum Sluse and Darum. Approximate location: 55.42917;8.62244
Crossing Sneum Å again, this time in-land approximately 12 km upstream from Sneum Sluse. Location: 55.49637;8.69648
Following national cycle route 6 (N6 – Esbjerg-København) and regional cycle route 10 heading back towards Ålbæk, Opsneum and Tjæreborg. Location: 55.49874;8.69664
Outgoing track as recorded by OpenTracks.
Homegoing track as recorded by OpenTracks.
Looking at weather forecasts in my native Denmark I have always noticed a location reference used by DMI, Danmarks Meteorologiske Institut (en:Danish Meteorological Institute). Somehow I managed to not look into the details of that before now.
But this morning while scouting for rain showers and trying out the forecast on the new website of Yr (the long time open data weather service from Norwegian Broadcasting Corporation (NRK) and the Norwegian Meteorological institute (MET)), as kindly suggested by the YR main site which uses the old site by default, I saw the same reference included in the URL.
A closer look at different service’s forecast URLs for my usual whereabouts in Tjæreborg, Denmark, Europe, Earth reveals (se summary below) that they all share this reference and that it stems from the GeoNames.org (wikipedia article) database’s integer reference to the location:
This particular piece of data is described as a field in the “geoname” table of the GeoNames.org main database, and referred to as “geonameid” in the documentation:
geonameid : integer id of record in geonames database
The contents of the GeoNames.org database is licensed under the Creative Commons Attribution 4.0 International (aka. “CC BY 4.0”, SPDX ID:”CC-BY-4.0″) and available both for your own download and perusal (documentation here) or using web services on geonames.org.
Note, however, that GeoNames.org accumulates a wealth of data sources that according to the OpenStreetMap project might contain copyrighted data. Together with the attribution requirements of its CC BY license this causes OpenStreetMap to not accept data from GeoNames.org into the project’s, ODbL licensed, database.
Fun fact: in Norwegian “yr” actually means drizzle (da:støvregn) Practical hint: OpenSearch entry for GeoNames.org: http://www.geonames.org/opensearch-description.xml (to add in current browser: go here->find “Plugins”->click “opensearch plugin”)
$ wget -q -O- "https://secure.geonames.org/get?geonameId=2611610&username=demo" <?xml version="1.0" encoding="UTF-8" standalone="no"?> <geoname> <toponymName>Tjæreborg</toponymName> <name>Tjæreborg</name> <lat>55.46457</lat> <lng>8.57968</lng> <geonameId>2611610</geonameId> <countryCode>DK</countryCode> <countryName>Denmark</countryName> <fcl>P</fcl> <fcode>PPL</fcode> <fclName>city, village,...</fclName> <fcodeName>populated place</fcodeName> <population>2146</population> <adminCode1 ISO3166-2="83">21</adminCode1> <adminName1>South Denmark</adminName1> <asciiName>Tjaereborg</asciiName> <alternateNames>Tjaereborg,Tjæreborg</alternateNames> <elevation/> <srtm3>12</srtm3> <astergdem>11</astergdem> <continentCode>EU</continentCode> <adminCode2>561</adminCode2> <adminName2>Esbjerg Kommune</adminName2> <alternateName lang="post">6731</alternateName> <alternateName lang="unlc">DKTJA</alternateName> <alternateName lang="link">https://en.wikipedia.org/wiki/Tj%C3%A6reborg%2C_Denmark</alternateName> <alternateName>Tjæreborg</alternateName> <timezone dstOffset="2.0" gmtOffset="1.0">Europe/Copenhagen</timezone> <bbox> <west>8.57175</west> <north>55.46907</north> <east>8.58762</east> <south>55.46008</south> <accuracyLevel>0</accuracyLevel> </bbox> </geoname> $
$ wget -q https://download.geonames.org/export/dump/DK.zip $ unzip DK.zip Archive: DK.zip inflating: readme.txt inflating: DK.txt $ grep ^2611610 DK.txt 2611610 Tjæreborg Tjaereborg Tjaereborg,Tjæreborg 55.46457 8.57968 P PPL DK\ 21 561 2146 12 Europe/Copenhagen 2017-10-18 $
WARNING: as OSM user “mmd” wisely points out (in comment to OSM diary for this post) the sort of thing described here is dangerous to do by hand, and should not be done on the main production instances (there are testing instances for playing around with the API, a little documentation here). He also points out that the feature packed JOSM editor actually supports continuing a changeset regardless of where it has been initiated. So if you just need to continue working on a changeset (but remember the 1 hour idle timeout) be sure to check out the JSOM upload documentation. Thanks mmd, for being the sane voice ;).
During an editing session the Android OpenStreetMap editor Vespucci crashed on me, which made the mapping UI unusable (objects greyed out and unable to select or edit, had to purge all data to recover functionality). Luckly, I could still navigate the menus, upload changes and opt to not close the changeset. Now, I had long wondered whether the OSM API allowed to continue amending changes to an open changeset from some other editor, so the quest began.
I had the intention of adding a tag representing the name of a building in Esbjerg known as “ISC Huset” (ISC is an engineering consultancy, see wikipedia, and more about the construction), which houses a number of healtcare clinics. The building’s address is Borgergade 70, 6700 Esbjerg (current address node).
This blog post willl attempt to actually add the tag by hand on the command line.
References to OSM objects used:
Option summary for GNU wget used to do HTTP requests below:
NOTE: I’ve broken some long output lines replicated below to make it fit the blog, but inserted an escape character (\) before the inserted newline to help copy’n’pasting.
Lets start by looking at the changeset’s metadata.
This can be done by issuing an unauthenticated GET request to the “/api/0.6/changeset/<changeset id>” endpoint.
Note that the ‘changeset’ element has the attribute ‘open=”true”‘ required to be able to modify the changeset. The editor used to create the changeset needs to have done this without explicitly closing it (Vespucci & JOSM closes by default but can be configured not to, iD always closes).
$ wget -nv -O- http://api.openstreetmap.org/api/0.6/changeset/88490797 <?xml version="1.0" encoding="UTF-8"?> <osm version="0.6" generator="CGImap 0.8.3 (802 thorn-02.openstreetmap.org)" copyright="OpenStreetMap and contributors"\ attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/"> <changeset id="88490797" created_at="2020-07-25T09:51:30Z" open="true" user="mikini" uid="2051"\ min_lat="55.4654072" min_lon="8.4378053" max_lat="55.5258532" max_lon="8.4639026" comments_count="0" changes_count="68"> <tag k="source" v="survey;research"/> <tag k="locale" v="da-DK"/> <tag k="created_by" v="Vespucci 14.1.4.0"/> <tag k="comment" v="Details at Klevestien & Borgergade in Esbjerg and Tarp."/> </changeset> </osm> 2020-07-25 14:26:52 URL:http://api.openstreetmap.org/api/0.6/changeset/88490797 [709] -> "-" [1] $
To test that the changeset is open, and that we can authenticate correctly, lets try amending it with an empty osmChange structure.
This can be done by issuing an authenticated POST request to the “/api/0.6/changeset/<changeset id>/upload” endpoint.
This also seem to reset the 60 minute timer used for auto-closing the changeset (see mention of “idle timeout” in changeset wiki article).
$ wget -nv -O- --user=mikini --ask-password https://api.openstreetmap.org/api/0.6/changeset/88490797/upload --post-data="<osmChange></osmChange>" Password for user ‘mikini’: Authentication selected: Basic realm="Web Password", charset="UTF-8" <?xml version="1.0" encoding="UTF-8"?> <diffResult version="0.6" generator="CGImap 0.8.3 (8531 thorn-03.openstreetmap.org)" copyright="OpenStreetMap and contributors"\ attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/"/> 2020-07-25 14:27:20 URL:https://api.openstreetmap.org/api/0.6/changeset/88490797/upload [278] -> "-" [1] $
The API’s “changeset/<changeset id>/upload” method supports only modifications encoded in the osmChange format which requires changes to be described as complete way/node/relation objects. That is, you can not ask the API to “add this tag to this way”, you need instead to describe the modified way completely saying “this way now looks like this”, including anything (like node references or existing tags) that was not modified. So to make a modificatino to the building’s way we need to retrieve the current version, modify it as needed and upload the complete new way.
Thus the procedure contains these steps;
This can be done by issuing an unauthenticated GET request to the “/api/0.6/way/<way id>” endpoint.
The stdin splitter ‘tee’ is used here to both show the result in terminal and put it into file 185369466_v3.osc that we can use for amending the way with the wanted modifications.
$ wget -nv -O- http://api.openstreetmap.org/api/0.6/way/185369466|tee 185369466_v3.osc <?xml version="1.0" encoding="UTF-8"?> <osm version="0.6" generator="CGImap 0.8.3 (28697 thorn-01.openstreetmap.org)" copyright="OpenStreetMap and contributors"\ attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/"> <way id="185369466" visible="true" version="3" changeset="84400254" timestamp="2020-04-30T09:35:21Z" user="mikini" uid="2051"> <nd ref="1959614623"/> <nd ref="1959614727"/> <nd ref="6299449794"/> <nd ref="1959614650"/> <nd ref="1959614630"/> <nd ref="6299449793"/> <nd ref="1959614765"/> <nd ref="7466482063"/> <nd ref="7466482064"/> <nd ref="7466482065"/> <nd ref="7466482062"/> <nd ref="1959614729"/> <nd ref="1959614623"/> <tag k="building" v="yes"/> </way> </osm> 2020-07-25 14:54:30 URL:http://api.openstreetmap.org/api/0.6/way/185369466 [769] -> "-" [1] $
Now we need to build an osmChange file out of the existing <way>…</way> element from the output above describing the wanted building. This involves;
Use your favorite editor (emacs would be my preference) to load the 185369466_v3.osm file, make the modifications and save it as 185369466_v4.osc. OSM tags are a XML empty-element tags containing the OSM tag’s key and value in the “k” and “v” attributes, thus the “name” tag of the building I needed to add would be ‘<tag k=”name” v=”ISC Huset”/>’, I also added some other related tags (“source:name” and “website”).
The finished .osc file now looks like this;
$ cat 185369466_v4.osc <osmChange> <modify> <way id="185369466" visible="true" version="3" changeset="88490797" timestamp="2020-04-30T09:35:21Z" user="mikini" uid="2051"> <nd ref="1959614623"/> <nd ref="1959614727"/> <nd ref="6299449794"/> <nd ref="1959614650"/> <nd ref="1959614630"/> <nd ref="6299449793"/> <nd ref="1959614765"/> <nd ref="7466482063"/> <nd ref="7466482064"/> <nd ref="7466482065"/> <nd ref="7466482062"/> <nd ref="1959614729"/> <nd ref="1959614623"/> <tag k="building" v="yes"/> <tag k="name" v="ISC Huset"/> <tag k="source:name" v="sign;website"/> <tag k="website" v="https://www.isc.dk/isc-huset-esbjerg/"/> </way> </modify> </osmChange> $
Wdiff’ing against the .osm source shows exactly what changed (additions between “{+” & “+}”, removals between “[-” & “-]”);
$ wdiff 185369466_v3.osm 185369466_v4.osc [-<?xml version="1.0" encoding="UTF-8"?> <osm version="0.6" generator="CGImap 0.8.3 (28697 thorn-01.openstreetmap.org)" copyright="OpenStreetMap and contributors"\ attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">-]{+<osmChange> <modify>+} <way id="185369466" visible="true" version="3" [-changeset="84400254"-] {+changeset="88490797"+} timestamp="2020-04-30T09:35:21Z" user="mikini" uid="2051"> <nd ref="1959614623"/> <nd ref="1959614727"/> <nd ref="6299449794"/> <nd ref="1959614650"/> <nd ref="1959614630"/> <nd ref="6299449793"/> <nd ref="1959614765"/> <nd ref="7466482063"/> <nd ref="7466482064"/> <nd ref="7466482065"/> <nd ref="7466482062"/> <nd ref="1959614729"/> <nd ref="1959614623"/> <tag k="building" v="yes"/> {+<tag k="name" v="ISC Huset"/> <tag k="source:name" v="sign;website"/> <tag k="website" v="https://www.isc.dk/isc-huset-esbjerg/"/>+} </way> [-</osm>-] {+</modify> </osmChange>+} $
Now, we’ll again use the changeset upload method but this time supplying our actual osmChange elemet in the .osc file.
The output is a bit elaborate, because I had enabled full output from wget while debugging what changes to the <way> element was needed for the server to accept the upload (only the “changeset” attribute needs to match the open changeset as outlined in the “Modify building data” above). I’ve highligted the actual server response telling that the changes were accepted and way #185369466 is now at v4.
$ wget -S -O- --user=mikini --ask-password https://api.openstreetmap.org/api/0.6/changeset/88490797/upload --post-file=185369466_v4.osc Password for user ‘mikini’: --2020-07-25 15:44:41-- https://api.openstreetmap.org/api/0.6/changeset/88490797/upload Resolving api.openstreetmap.org (api.openstreetmap.org)... 130.117.76.12, 130.117.76.13, 130.117.76.11, ... Connecting to api.openstreetmap.org (api.openstreetmap.org)|130.117.76.12|:443... connected. HTTP request sent, awaiting response... HTTP/1.1 401 Unauthorized Date: Sat, 25 Jul 2020 13:44:41 GMT Server: Apache/2.4.29 (Ubuntu) Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Expect-CT: max-age=0, report-uri="https://openstreetmap.report-uri.com/r/d/ct/reportOnly" WWW-Authenticate: Basic realm="Web Password", charset="UTF-8" Cache-Control: no-cache Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Expect-CT: max-age=0, report-uri="https://openstreetmap.report-uri.com/r/d/ct/reportOnly" Content-Length: 22 Content-Type: text/plain; charset=utf-8 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Authentication selected: Basic realm="Web Password", charset="UTF-8" Reusing existing connection to api.openstreetmap.org:443. HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Sat, 25 Jul 2020 13:44:42 GMT Server: Apache/2.4.29 (Ubuntu) Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Expect-CT: max-age=0, report-uri="https://openstreetmap.report-uri.com/r/d/ct/reportOnly" Content-Encoding: identity Cache-Control: private, max-age=0, must-revalidate Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Expect-CT: max-age=0, report-uri="https://openstreetmap.report-uri.com/r/d/ct/reportOnly" Vary: Accept-Encoding Content-Type: application/xml; charset=utf-8 Keep-Alive: timeout=5, max=99 Connection: Keep-Alive Transfer-Encoding: chunked Length: unspecified [application/xml] Saving to: ‘STDOUT’ - [<=> ] 0 --.-KB/s <?xml version="1.0" encoding="UTF-8"?> <diffResult version="0.6" generator="CGImap 0.8.3 (8537 thorn-03.openstreetmap.org)" copyright="OpenStreetMap and contributors"\ attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/"> <way old_id="185369466" new_id="185369466" new_version="4"/> </diffResult> - [ <=> ] 353 --.-KB/s in 0s 2020-07-25 15:44:42 (20,3 MB/s) - written to stdout [353] $
That was it, the building is now named in OSM, in a changset amended by hand.
Take a look at https://www.openstreetmap.org/way/185369466/.
Came by Esbjerg Harbour on September 24th 2019 and saw what was obviously a cable ship docked at the quay. A giant ship and I immediately thought that the mermaid might be closing in on Jutland. Some quick drive-by pictures and vessel details below:
New sighting on 2019-11-03:
JV article about ship and ongoing upgrades causing noise.
Update: Jeg mødte Richard i Odense, fik lov at sponsorere FSF og fik en GNU med hjem!
Mikkel & RMS (og GNU)SDU, Odense
Rygterne har lydt noget tid, men nu er det officielt at formand for og stifter af Free Software Foundation, den ideologiske ophavsmand til GNU-projektet og højlydt fortaler for softwarebrugeres frihed og privatliv i den digitale verden, Richard Stallman besøger Danmark med en række åbne og gratis foredrag dette forår.
Det er Stallmans dedikerede arbejde med fri software og GNU-projektet fra starten af 1980’erne, herunder udformning af softwarelicenser som GNU GPL og udviklingsværktøjer som GNU Compiler Collection (GCC) og GNU Emacs, der er grundlaget for en stor del af det der i offentligheden i dag bedst kendes som “open source”. I Stallmans og GNUs terminologi benævnes det dog retteligt “fri software” (på engelsk: “free software”) for at fremhæve at etablering og bevarelse af softwarens, og slutbrugeren af dens, frihed er det egentlige rationale for at give kildekoden fri.
Kernen Linux er frigivet under GNU GPL og er både inspireret af og anvender GNU-projektets arbejde direkte, og er en vigtig del af et komplet GNU-system (også kendt som GNU/Linux eller en “Linux-distribution”).
Stallman kommer på en veritabel Danmarksturne med start i Aalborg mandag d. 6. maj 2019 og ender i København fredag d. 10. maj 2019. Foredragsrækken er arrangeret af innovationsnetværket for IT, InfiniIT, som inkluderer de store IT-universiteter i Danmark.
Den samlede foredragsrække er som følger:
16:00-19:00
16:00-18:00
(ændrede lokationsoplysninger ikke opdaterede her)
Kilder: FSF: Where in the world is Richard Stallman?, InfinIT-arrangementer, IDA-søgning, PROSA-arrangementer
Begivenhederne er også tilføjet den åbne kalender GriCal: grical.org/s/?query=%40DK.
De primære kilder er hovedsageligt på engelsk:
2020-11-25 add news item about cable extension to Copenhagen, add Bulk data center blog link 2019-06-04 add details of Bulk data center in Esbjerg and infrastructure, add local news items about construction start 2019-05-08 add system summary from FCC application, elaborate on landing point discrepancies between FCC/cablemap, link to docs describing seg. 5 cable lay schedule 2019-03-06 fix links to submarinecablemap.com and some press, add info from TE Subcom experience doc., some general touch ups 2019-01-22 change “Danish Press Coverage” to “National Press”, add “International Press”, add some National about datacenter prospects & International Press items about contractors choosen 2018-10-05 initial commit
Europe, Denmark and my local neighbourhood of Western Jutland is going to get its connectivity boosted by the Havfrue transatlantic cable system being built by a consortium consisting of Google, Facebook, Aqua Comms and Bulk Infrastructure. To quote the announcement done by Google;
To increase capacity and resiliency in our North Atlantic systems, we’re working with Facebook, Aqua Comms and Bulk Infrastructure to build a direct submarine cable system connecting the U.S. to Denmark and Ireland. This cable, called Havfrue (Danish for “mermaid”), will be built by TE SubCom and is expected to come online by the end of 2019. Google blog post, 2018-01-16
Digging into the details first reveals the projected trench as illustrated in below by some of the stakeholders;
Projected trench of the Havfrue cable as illustrated by cloud.google.com.
Projected trench of the Havfrue cable as illustrated by TE SubCom.
Projected trench of the Havfrue cable as illustrated by submarinecablemap.com.
EDIT 2020-11-25: Additionally in 2019-06-21 Interxion announced a direct connection between the AEC2 landing site in Blaabjerg to its two datacenters in Ballerup/Copenhagen.
More digging into the Danish parts reveals that most sources mention Blåbjerg (Blaabjerg) as the Danish landing point for Havfrue (just as TAT-14), although ComputerWorld DK (see National Press below) relays the information that it will land at Endrup (where COBRAcable is terminated). However, a FCC application dated 2018-05-25 SCL-00214S (pdf) refers to it as the “Havfrue system” and specifically states that a new cable landing station will be constructed in Blaabjerg (as well as in Leckanvy, Ireland and Kristiansand, Norway);
The Havfrue system will consist of three segments. (1) The Main Trunk will connect the existing cable landing station at Wall, New Jersey with a new cable landing station to be constructed at Blaabjerg, Denmark. (2) The Ireland Branch will connect a new cable landing station to be constructed at Old Head Beach, Leckanvy, Ireland with a branching unit on the Main Trunk. (3) The Norway Branch will connect a new cable landing station at Kristiansand, Norway with a branching unit on the Main Trunk.
Google is currently also projecting its own private subsea cables, some of the rationale behind their mixed private/consortium/lease approach are disclosed in blog post from 2018-07-17 announcing the Dunant cable, which is the first Google private transatlantic subsea cable projected to connect Virginia Beach and France.
EDIT 2020-11-25: see blog post detailing my visit to the construction site in June 2019
Bulk has announced that the Esbjerg data center location will be referred to as DK01 Campus which is described on the about page (EDIT 2020-11-25: now has its own page with different wording) as follows:
Bulk’s DK01 Campus, Esbjerg, southwest Denmark, will be a scalable Carrier Neutral Colocation data center ready for customers Q4 2019. Esbjerg is becoming a highly strategic data center location with several subsea fiber systems terminating within or nearby. These include Havfrue (US, Ireland, Norway, Denmark), Havhingsten (Ireland, Denmark), Cobra (Holland, Denmark), Skagerrak 4 (Norway Denmark), DANICE (Iceland, Denmark) and TAT-14 (United Kingdom, France, the Netherlands, Germany, and Denmark). Combined with excellent terrestrial connectivity, this will make Esbjerg the main international entry point to the Nordics and enable the Bulk DK01 campus to be the natural traffic exchange point.
An article (translated) in the local newspaper JydskeVestkysten first revealed the exact location of the center and renderings of its visual appearence and construction. The location is in Kjersing industrial area North of Esbjerg.
A further map of the Bulk connections between Norway, Denmark and Ireland has been revealed in an article of Capacitymedia and on Bulk’s own fiber networks page. Also a partnership with Amazon about delivering both connectivity and datacenter infrastructure for AWS has been announced.
Taking a deeper look into the meta data of the document containing the Environmental Assessment (Danish: “miljøvurdering” shortened “MV”) and Environmental Impact Assessment (Danish: “miljøkonsekvensvurdering” or “vurdering af virkningerne på miljøet” shortened “VVM”) of the announced data center in Esbjerg reveals an interesting embedded title of the document which has not been carried out into other publicly used references.
The embedded PDF title of the document uses the “Project Ember” term which has not been indicated by other sources than articles in the JydskeVestkysten newspaper. The paper cite municipal sources but the municipality has not used the name directly in any of their communications.
The report authored by consultants COWI contains the following naming:
Below a dump of the full meta data:
$ pdfinfo MV-VVM_afgr%c3%a6nsning.pdf Title: Microsoft Word – Project_Ember_MV-VVM_afgrænsning_v.4.0.docx Author: lojo Creator: PScript5.dll Version 5.2.2 Producer: Acrobat Distiller 15.0 (Windows) CreationDate: Fri May 25 15:49:44 2018 ModDate: Fri May 25 15:49:44 2018 Tagged: no UserProperties: no Suspects: no Form: none JavaScript: no Pages: 25 Encrypted: no Page size: 595.22 x 842 pts (A4) Page rot: 0 File size: 234728 bytes Optimized: yes PDF version: 1.5
2019-06-03 add (local|national) press items about bulk data center (follow this in post about Havfrue, no further updates here), minor text fixes 2019-03-07 add local and national press items announcing cancellation of project 2019-02-27 add local press item about property value, environmentalist opposition and local educational initiatives 2019-02-21 add local press item about unsatisfied land owners 2019-01-22 add official approval of plans, fix original chronology of Official Documentation items, add (local|national|international) press items about a.o. announcement of Bulk Infrastructure datacenter 2018-12-19 add documentation and local press items about postponed permit decision from municipality 2018-11-30 add a bunch of local press items, and archaeological section to documentation 2018-10-04 add local and national press item about Amsterdam trip and announcing Facebook as the developer 2018-09-06 add local press item about downscaling and older national press, reorder press items (top=latest) 2018-08-19 add local press item and Official Documentation section about housing abandonment 2018-08-01 add local press item with letter to editor 2018-06-13 updated with 1 new local + 1 new national press, rewrite first paragraphs, mention project name, mention DDI trade association, mention investindk & havfrue cable 2018-06-12 initial commit
The local media of Western Jutland, JydskeVestkysten, has spearheaded the coverage of an interesting technology related story over the last weeks. The Esbjerg municipality planning departments has started to reveal details of the preparations for the development of an industrial site on a large swath of land just outside of Esbjerg seemingly for the purpose of a hyperscale data center of the proportions employed by FANG sized (Facebook, Amazon, Netflix, Google) organizations. According to the media the project is by some municipal sources referred to as “Project Ember“. I have been unable to confirm this name from official documentation yet released or any other sources.
Neither the newly formed trade association named Danish Data Center Industry (DDI/DanishDCI) (in Danish: “Datacenter Industrien“) or the state’s Invest in Denmark office has brought any more light to the issue. The former has, however, tweeted a couple of times about it when it hit the national media and the latter has brought forward a vague hint that Western Denmark is an “attractive data centre hub“. I’m not in any doubt that this is partly driven by the announcement of the “HAVFRUE consortium“, which includes Facebook, that they intend to install a 108 Tb/s transatlantic cable crossing from New Jersey to Ireland and Esbjerg, as also announced by Invest in Denmark in January.
Below is an outline of the area in question (on an OpenStreetMap based map using the umap project) that I have drawn from the only geographical details yet leaked which is contained in the meeting agenda mentioned below. See also a visualisation of the area on a photo taken by local photographer Christer Holte.
I have collected links to all official documentation I have been able to locate and to press coverage below, and intend to keep updating this post as details is being revealed.
<br />
See full screen
