SIDEBAR
»
S
I
D
E
B
A
R
«
DK01 Campus: Bulk Infrastructure Building Site
Nov 4th, 2020 by miki

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.

Fiber Network

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 (mermaid) – New Jersey/Dublin/Kristianssand

    Havfrue

  • Havhingsten (sea horse)  – Newcastle/Dublin

    Havhingsten

  • Havsil (sea herring) – Kristianssand/Hanstholm

    Havsil

Location

The location in Esbjerg is indicated by the orange area outline on the map below, courtesy of OpenStreetMap.

Construction Site Photos

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.

VCTA Detour Wednesday/Omvejsonsdag – new paths for your wheels
Sep 24th, 2020 by miki

The Danish Cyclists’ Federation (Cyklistforbundet) throws a yearly month long event called BIKE TO WORK (“Vi Cykler Til Arbejde” aka. VCTA) nudging employees of Danish workplaces to use their bike for commuting. Teams are formed by the employees and team statistics are available both internally and between workplaces for the teams to compete in the number of kilometres travelled and number of active days. See f.x. the statistics for the two teams of my employer Vestergaard. Of course my outdoor, social, competitive, and sometimes a bit extreme, mindset can’t miss such a chance to commit to an all-in full month bike relay race with myself and some distant (300 km to HQ) colleagues. As a part of the VCTA month of cycling one day is designated to taking an unknown route to work, dubbed “Detour Wednesday” (“Omvejsonsdag“). This is to inspire the individual to find new routes and get some fresh input on the surroundings. This year it was Wednesday September 23th, and the event even includes a draw of an electric powered bike amongst participants documenting their detour appropriately. For your enjoyment, below are some visual impressions from my nice detour in the Tjæreborg/Bramming area (of Western Jutland, Denmark). Even though I have been to all these places before by various different means (running, cycling, car, motorcycle), you do sense a place a lot different on the bike than by other means.

All The Maps

Being the dev/hacker/tinkerer/geo person that I am, although not extremely well-versed in HTML/javascript, I have also made a quick throw together of a visualisation on top of Leaflet and OpenStreetMap of the tracks I’ve recorded during VCTA. Find it at tools.mikini.dk/vcta, and source code at gitlab.com/mikini/vcta.

My VCTA tracks pr. 2020-09-24 visualised by some hackish javascript on tools.mikini.dk/vcta (code).

Out

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

Home

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

Tracks

The tracks as recorded by Endomondo; The tracks as recorded by OpenTracks (Application: F-Droid, Github, Google Play, OSM Dashboard: F-Droid, Github, Google Play).

Outgoing track as recorded by OpenTracks.

Homegoing track as recorded by OpenTracks.

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

OSM Use & Attribute: Bisnode Navne & Numre Erhverv website
Mar 28th, 2019 by miki

OSM Use & Attribute?

I regularly stumble upon maps which I cane recognize as derived from OpenStreetMap. Usually by map style, the level of detail or by seeking out details I know is only present in OSM. I usually inspect the attribution and license accompanying the material to assess whether it is prepared by an organisation who understands the needs to and cares about having its chain of copyright somewhat traceable. I’ll attempt to do a small concise writeup of the findings going along this in the future. Maybe I’ll be able to produce a series of “OSM Use & Attribute” posts?

Quite randomly the first one became the Danish company Bisnode.dk using OSM tiles from Mapquest (the ones who fled from an open approach in 2015) to indicate locations in the commercial and subscription-required yellow pages product named Bisnode Navne & Numre® Erhverv (aka. erhverv.nnmarkedsdata.dk).

Attribution Compliance Analysis

For reference: OSM’s Copyright and License page

Below is a screen-shot from within the walled garden, and the actual link leading to the page (accessible to me because I’m the owner of the company in question).

Bisnode obviously uses Mapquest as supplier of their maps. Mapquest do make sure to display a nice and prominent copyright attribution line in the map with text linking to respectively Mapquest’s Mapbox attribution page (“MAPBOX” text), OpenStreetMap’s about page (“OPENSTREETMAP” text) and Mapquest’s TOS (“TERMS” text).

The OSM attribution doesn’t comply exactly with the words of the OSM attribution instructions; to use the text “© OpenStreetMap contributors” and make it clear that data is distributed under the ODbL license (suggested done by linking to the OSM copyright page which only happens indirectly through the about page). This is almost fulfilled on the 3rd Party Notices and Licences which is, however, buried behind the long read of the Mapquest TOS, and where the attribution strangely becomes the rather twisted “© Open Street Map and Contributors”. Who are OSM beyond its contributors? And why doesn’t Mapquest know the correct name of the project? Is it to prevent search engine hits of the more unique concatenation of the three words? That’s a guess.

Strangely an almost similar text but also with a reference to the ODbL is to be found in the “Mapbox Streets” section of the Mapbox attribution page.

Tile Server Compliance Analysis

For reference: OSM/OSMF’s Tile Usage Policy

The tiles are obviously rendered using the Mapquest cartography and thus can be served only by Mapquest.

 

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