12-03 issue was handled in this operations ticket: https://github.com/openstreetmap/operations/issues/1008

IIRC a well known company did some fairly extensive web page and API scraping over the weekend and was blocked subsequently. (Mentioned in another operations issue)

Spaces in code blocks work just fine, see https://kramdown.gettalong.org/syntax.html#code-blocks

Example:

def what?
  42
end

Switching accounts inside JOSM isn’t exactly a new idea: https://josm.openstreetmap.de/ticket/2710

Why don’t you use josm.home? Seems much easier to me to manage multiple profiles/users… https://community.openstreetmap.org/t/mehrere-josm-profile/74386

My target timeline for the C++ part of the API is no later than Q1/2024, see https://github.com/zerebubuth/openstreetmap-cgimap/issues/286

I don’t know what OWG will eventually come up with. Also sysadmins have the final say on what to deploy at which point in time.

The main purpose of a dispatcher process is to coordinate read and write activities, to make sure that the writing processes (update_from_dir and update_database) don’t overwrite parts of the db files, which are currently being read by other process (such as interpreter or osm3s_query).

Besides witting lots of (mostly very technical) detail information to the log files, the dispatcher doesn’t cause any I/O activity. I have removed the excessive logging in my fork, and it doesn’t really add any value for me.

Also, I wouldn’t simply kill the dispatcher processes, and use the ‘–terminate’ command line option instead.

Regarding downloading clone files, we currently have disk space for around 1-2 days of clone files available on the server. If your download speed is too low, db files might have already been purged from the server before your download has finished! This situation might improve a bit in the next couple of months, though.

Posting your Overpass related questions on “community.osm.org”, and tag them with “overpass” would also work, if you’re not on Slack.

Maybe that’s a good opportunity to work on the underlying infrastructure as well. Turning spinning wheels into faster responses.

I find JOSM’s validator invaluable in such cases - you absolutely ought to be using that to check for problems as you go (even if you’re not using JOSM to edit).

Totally agree here. JOSM reported even some more issues: three relation members should have a member role “inner” instead of “outer”.

By the way, after splitting way 1000494463, you should see one more member in osm.org/relation/15074887 … overall you shouldn’t have to delete any nodes or ways. Splitting up one way and making sure that the right segments are assigned to each of the two relations should do.

To be more specific, JOSM complains about way osm.org/way/1000494463, in particular the part of the way starting out southbound with node osm.org/node/9235211881 … once I remove that node, and everything further south of it, the closure issue is solved. Once option to achieve this is to split way 1000494463 at osm.org/node/9235211880

I think there are more issues, like a non-closed geometry up here: osm.org/relation/12907666#map=16/43.8049/-122.6301 … You need to re-run the validator, once you have fixed all reported issue, as new issues are likely to show up then.

There might be a geometry issue somewhere, as the relation doesn’t render on the standard map anymore. JOSM validator reports those sorts of issues.

We also have an example on the Overpass by example wiki page highlighting the use of regular expressions to render objects according to some date: osm.wiki/Overpass_API/Overpass_API_by_Example#Alternative_that_also_checks_the_syntax_of_the_collection_time

yvecai runs OpenSnowMap… 😉

The goal of the import is to set up a new Overpass db using a recent OSM planet file. As usual, the import process writes all nodes, ways and relations to disk, and includes object metadata (user, timestamp, object version number, …). Once the import has finished, you can use the db to run some queries.

In case you don’t want to go through this process, there’s also some clone database available for download (see docs for details).

Historical object versions is a challenging topic. I reran some tests, starting with a 2012 planet, and subsequently applying daily diffs in PBF format. I ended up processing years 2012-2017 at about 600x speed (1 day = 600 OSM days), with a package size of 3 days. Using the official release is much slower and works with XML files only.

Using a full history planet instead doesn’t work. The importer wasn’t designed with this use case in mind and uses way too much memory.

[…] like an object was created before it’s previous version

That’s exactly the reason why CGImap doesn’t trust the frontend (or former backend) servers to provide accurate timestamps, and delegates all that to the database instead.

An upload is not a changeset… you can have multiple uploads all belonging to the same changeset, as long as you don’t close the changeset.

Before changesets existed, you could still upload one change at a time (which by the way is much slower than the 0.6 diff upload).

I’m using Overpass API for this sort of query. Takes about half a minute on a global scale: https://overpass-turbo.eu/s/1maI

Haha, that would be awesome. Seriously, what I really meant, I used Overpass API rather than Geofabrik extract to fetch relevant data, loaded that data into the OSM tile server docker, and took a browser window screenshot.