SIDEBAR
»
S
I
D
E
B
A
R
«
Amending an open OSM changeset on command line (by hand)
Jul 25th, 2020 by miki

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:

  • -nv (or –no-verbose): only report errors and basic information
  • -O- (or –output-document=-): write output to standard out (stdout)
  • –user=<user name>: authenticate as <user name> using HTTP Basic authentication
  • –ask-password: ask on command line for HTTP Basic authentication password
  • –post-data=”<data>”: initiate a HTTP POST request with <data> as payload
  • –server-response (or -S): show full HTTP headers of server response

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.

Retrieve changeset metadata

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 &amp; 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]
$

Pinging the changeset with an empty osmChange structure

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]
$

Procedure to change the building

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;

  1. Retrieve current building (GET /way/*)
  2. Modify building data (locally)
  3. Amend changeset (POST /changeset/*/upload)

Retrieving current building (GET /way/*)

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]
$

Modify building data (locally)

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;

  1. removing the <xml> tag (maybe not needed, but it is not mentioned at all in the osmChange documentation)
  2. replacing <osm> with <osmChange>
  3. adding a <modify> element to the <osmChange> element, containing the existing <way>
  4. update the “changeset” attribute to the changeset we’re amending
  5. amending the contents of <way> with the wanted <tag>s

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>+}
$

Amend changeset (POST /changeset/*/upload)

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]

$

Result

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/.

A havfrue stopping by?: Deep Energy pipelay vessel in Esbjerg
Oct 2nd, 2019 by miki

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:
image
image

JV article about ship and ongoing upgrades causing noise.

Havfrue: A Googol-sized Mermaid Facing the Book
Oct 5th, 2018 by miki

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;

Havfrue cable, cloud.google.com

Projected trench of the Havfrue cable as illustrated by cloud.google.com.

Havfrue cable, te.com

Projected trench of the Havfrue cable as illustrated by TE SubCom.

Projected layout of the Havfru cable.

Projected trench of the Havfrue cable as illustrated by submarinecablemap.com.

 

System Details

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.
The application also reveals the following distribution of ownership and control of the main trunk (US<->DK);
  1. each 33.333% ownership

    • AEC2
    • Facebook (via Edge USA/Edge Network Services Limited)
  2. each 16.667% ownership

    • Google (via GU Holdings/Google Infrastructure Bermuda Ltd/affiliate)
    • Optibulk
Ownership of the Blaabjerg landing station will be jointly between the above via the corporations America Europe Connect 2 Denmark ApS (for AEC2) and Edge Denmark (for Facebook) but it will be operated by AEC2.
Other facts from the FCC application:
  • Name: Havfrue (maybe “Havfrue system”?)
  • Design capacity per fiber pair: 18 Tbps
  • Main trunk
    • Fiber pairs: 6
    • Capacity: 108 Tbps
    • Length: 7’211 km
  • Ireland branch
    • Fiber pairs: 6
    • Capacity: 108 Tbps
    • Length: 315 km
  •  Norway branch
    • Fiber pairs: 2
    • Capacity: 12 Tbps
    • Length: 199 km
  • Intended commercial operation: 2019-Q4
  • Landing points:
    • Wall, New Jersey
    • Blaabjerg, Denmark
    • Old Head Beach, Leckanvy, Ireland
    • Kristiansand, Norway
As a spin off of Aqua Comms’ involvment in the Havfrue system they are also connecting Esbjerg to the UK via a new cabled dubbed North Sea Connect.

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.

Bulk Infrastructure

Data Center

Bulk has announced that the Esbjerg data center location will be referred to as DK01 Campus which is described on the about page 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.

Infrastructure

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.

Further Information

News / Press releases

From Stakeholders

Construction Documentation

At Cable Map Sites

National Press

International Press

Other

Project Ember: name of a data center
Aug 20th, 2018 by miki

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:

  • Official in text: “MILJØVURDERING (MV) OG MILJØKONSEKVENSVURDERING (VVM) – ERHVERVSOMRÅDE VED ESBJERG, AFGRÆNSNINGSRAPPORT
  • Filename of distributed PDF: “MV-VVM_afgrænsning.pdf
  • PDF meta data title: “Microsoft Word – Project_Ember_MV-VVM_afgrænsning_v.4.0.docx

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

»  Substance:WordPress   »  Style:Ahren Ahimsa
© 2020 Mikkel Kirkgaard Nielsen, contents CC BY-SA 4.0