openstreetmap/owg-website

The website for the OSMF Operations Working Group (OWG)

owg-website

This repository holds the website for the OSMF Operations Working Group. We're using a git repo since that's what we're used to. It also allows other people to make pull requests if they want to, sidesteps permissions issues on wikis, and generally just lowers the bar to contribution.

The website contains our monthly reports to the OSMF Board, our policies, and our meeting notes. You can view the website at operations.osmfoundation.org

Contributing to the website

We welcome contributions to our website! Your suggestions will be reviewed by the team and merged where appropriate.

Via github.com

When you're viewing a page, just click on the "Edit" button on the github.com UI, and submit a pull request.

Via prose.io

You can also edit the reports using prose.io, if you'd prefer a wysiwyg editor

Via git

You can clone this repo and make changes locally, if you prefer. All the work happens on the gh-pages branch.

To preview your changes, install the dependencies with

bundle install

and then run

bundle exec jekyll serve -w

The site is then available at http://localhost:4000/ and will update automatically when you change any files.

owg-website's Issues

Create section for incident reports

Now that we have multiple ones, it would be worth creating a section where they can all be viewed.

To-do:

• create section
• create forwards of current URLs

Move repo to openstreetmap/ organization

It would be good to have OpenStreetMap Foundation Operations Working Group reports not under personal account, but at organization.

Tile policy: be clearer about export

The tile policy talks about "calls to /cgi-bin/export". There are two issues with that:

1. It isn't clear from the name that the policy even applies to exports (and not, e.g., the API policy). Should the policy be called "Tile and map image policy" or something like that?
2. It appears that the current OSM web site uses paths like "http://www.openstreetmap.org/export/finish" that do not include the /cgi-bin/ component, hence users might be misled to thinking the policy does not apply to these URLs. Should we perhaps replace "Calls to /cgi-bin/export may only be triggered..." by "Image exports may only be triggered..."?

Turn URLs into links

The index page has the text "https://hardware.openstreetmap.org/", "https://github.com/openstreetmap/operations/issues", "https://uptime.openstreetmap.org/". These should be links with text

set up redirects

assuming #21 happens and the repository moves, we'll need to leave redirects for all the existing pages to prevent breakages.

Nominatim Usage Policy: clarify attribution requirement

Hi folks,

The Nominatim Usage Policy says one of the requirements for Nominatim usage is

Clearly display attribution as suitable for your medium.

However, it's not clear whether this ought to be attribution to Nominatim in some way, or whether it ought to be the same attribution used for all other OpenStreetMap stuff (i.e. as per the OSM copyright page). It seems reasonable to assume it's the latter, as the former is clearly a product of data from the latter, and indeed this is how I've seen it used around the Internet. I think it's probably worth just clarifying that in the usage policy, because the existing wording is slightly ambiguous on that front.

If my assumption there is incorrect, it definitely ought to be specified, because that seems like a change to how most people have been interpreting it!

Cheers,

Curtis

Create PDFs

Everyone loves PDFs, especially when your reporting chain involves email stuff around to one another.

We should be able to generate PDF reports from either the markdown sources or the generated html. A rake task to (re)generate all the PDFs would be sufficient.

Tile Usage Policy: clarify X tiles per Y time

https://operations.osmfoundation.org/policies/tiles/ says

In particular, downloading an area of over 250 tiles at zoom level 13 or higher for offline or later usage is forbidden.

Well OK, but it should say "at a time", or "at one time", and if that "time" is "within the same 30 minutes, hour, day, month or lifetime".

Automatically regenerate site on first of month

Each month's report is set to be published at the end of the month, but this doesn't happen until there's a new commit, triggering the regeneration of the site.

Mention tile-attribution tracking repo on Tile Usage Policy page

https://github.com/openstreetmap/tile-attribution should be mentioned on https://operations.osmfoundation.org/policies/tiles/

Website doesn't show recent posts

I tried to find the recent outage reports (such as 6fd72e7) on the website, but I cannot find them.

On the main page the newest monthly report is July 2021, and on the archive page as well.

Maybe the website doesn't get updated properly?

Link to task tracker

The website doesn't link to our task tracker, at least not from the front page!

Don't contact SysAdmins via the wiki?

We mention the system admins a few times in the Tile Usage Policy and possibly elsewhere in the policies. Should we change that to OWG?

In the past, such decisions may have been made on the basis of the current load on the system. But I feel like nowadays OWG aims to have a more predictable policy-based framework for these kinds of things. Additionally, contacting individual admins via their wiki pages is probably a hit-and-miss process on a good day, and these things would be better directed to an email alias or something similar which can be handled by a group of people.

Atom feed for monthly reports

We should add an atom feed for the monthly reports. This will allow people (e.g. Board members) to keep themselves updated using a variety of tools.

Tile Usage Policy: can I cache them?

Reading https://operations.osmfoundation.org/policies/tiles/ it's not clear to me if it's okay to cache them (eg put a nginx proxy in front of it), ie like a website that would directly load tiles, but rewriting the URLs to refer to my proxy first. There wouldn't be any precaching, so it wouldn't hit the servers any harder than simply having web browsers load them directly.

If it's allowed in principle (and I think it would be, it would only decrease load...) how should I interpret the technical requirements ?

Valid HTTP User-Agent identifying application. Faking another app’s User-Agent WILL get you blocked.

Should I pass on the user's User-Agent, or should I have the proxy send a specific user-agent itself? (eg 'nginx')

If known, a valid HTTP Referer.

"valid" is not necessarily the actual referrer. I wouldn't have a problem just sending the origin of the website as a referrer (eg https://www.example.net/ if that's where the user sees the tiles) but sending the full url might leak some private data. Those considerations are no different than what I would set the Referrer-Policy header too of course.

DO NOT send no-cache headers. (“Cache-Control: no-cache”, “Pragma: no-cache” etc.)

I'm pretty sure I can strip those headers, even if the browser itself does send them (shift-reload).

Cache Tile downloads locally according to HTTP Expiry Header, alternatively a minimum of 7 days.

Seems doable. I'm pretty sure nginx tries to do the right thing out of the box.

Maximum of 2 download threads. (Unmodified web browsers’ download thread limits are acceptable.)

As I wouldn't be prefetching, there wouldn't be more download threads than if the users had connected directly. On the other hand, a mix of real users would be downloading a lot smoother (slower) than a proxyserver in a datacenter. But if I need to strictly enforce this limit, and the cache hit rate isn't high enough.. this might actually make a proxy solution slower than having users connect directly to the tile server and might not make it worth the effort. This would probably require seeing it in practice.