It looks like the "cliff" started out as the "land_area=administrative" relation for Commonia, and then seriously degraded over time. Finally some rather clueless mapper added the "natural=cliff" tag, which doesn't make any sense at all. At least that tag should be removed, and the "land_area" relation in its current state isn't of much use also:

https://tile.opengeofiction.net/util/relation_area.html?q=11034

Would it be worth the effort of repairing and then maintaining it? I don't know.

The OSM software keeps old object versions in the database, with timestamp. So, theoretically it should be possible to extract a snapshot for any given date, with a suitable tool.

But there's also a much easier method: I still have many old export files lying around somewhere, even if they're not available on the backup page anymore. If there's interest, I could upload some of them again. Of course, you'd still have to find a way to render them.

@Yuanls

Probably not, but I don't know.

For local rendering of .osm files, try Maperitive.

Also, let me add that I'm open to replacing the night map by a more convincing one, if someone takes on the effort to create one.

You're correct about the script, but the tags used are

highway=motorway,trunk,primary,secondary,tertiary

The generated image is here:

https://tile.opengeofiction.net/util/NightLights.png

Each pixel's brightness is directly determined by the number of highway nodes projected into that location, with values ranging from 0 - 255 (with the value set to 255 if the node count is higher).

In a first version, I used all types of highways without regard of the tag value. The only reason I didn't use it, was that Roantra came out much to bright because of its comparatively high density of small country roads. IMO it's still too bright, but now more acceptable.

Please try again. All URLs are being redirected to https since yesterday, which doesn't seem to work well with the "remote control" feature. So for now the remote control link has been switched back to use http only.

Maybe someone should do an experiment to find out ...

I guess it was a simple misunderstanding, but it's not true that you aren't allowed to use Romanian language just because someone else already did. Nobody here has a monopoly on using any real world language.

Just imagine we had a rule like this for English. Probably half of all users would be in violation of it.

Oops, forgot to re-enable rendering after doing some maintenance work. Everything should appear soon.

Should be fixed now; was probably a remnant of the earlier flooding. OGF's tile expiry mechanism isn't particularly well suited for the case of flooding, which causes tiles that have been rendered in a flooded state to remain that way after the flooding itself has been fixed.

If there are still flooded tiles (after clearing your browser cache), please let me know.

As wangi and martinum4 said, the relation must be tagged instead of the outer ways. I just want to add that the disappearance has indeed been triggered by an update of the standard layer:

https://github.com/gravitystorm/openstreetmap-carto/blob/master/CHANGELOG.md#v400---2017-05-22

Yes, it does.

@niels20020: some sort of HistoricalMap display can probably be achieved with a Leaflet application that uses Overpass queries, similar to what we recently did with route relations.

I wrote a comment on that page, and the deleted it with a different (non-admin) user, both without problems. So the problem seems to be related to your user account rather then that specific page.

Now I've enabled debug logging for the wiki. Can you please save the page once again, preferably after logging off and clearing the browser cache?

No, I wasn't aware. I assume this is the affected page:

http://wiki.opengeofiction.net/wiki/index.php/User:Myrcia/Bliki/2017/08/28

Has it happened more than once? And what was the text of the error message? Generally, there doesn't seem to be a problem with page creation (just created a new page without problem, and it does show up). Please let me know if it happens again.

No, I don't actually think that interpolation is that complicated. I just wanted to point out that it's unrealistic to assume constant speed over a complete route. (And that the information about staying time at the stops was missing.)

Doing complicated calculations, that's actually what computers are for (and the fact that you used a spreadsheet is proof of that). IMO the preferred method would be the "trip_stop_intervals.txt" approach. That might be still somewhat unrealistic, because the time needed for a trip might vary over a day due to traffic conditions, but I'm OK with ignoring that. Maybe for every route there could be two or three variants.

The most complicated part would probably be to have some kind of "collision detection" to ensure that multiple trains don't occupy the same station or travel in the same location at the same time.

Of course the best method would be to have real-world GPS data, because users want information about the actual location of the train they're waiting for, but as we neither have a real world nor users who depend on that information. (Now that I think about it, not having a real world behind it might be the root cause of many of OGF's problems ...)

BTW, on the route_relations.html page, you can now zoom in to any location, and view the public transport relations of that area by pressing the "reload" button.

Are stops.txt, agency.txt, and routes.txt necessary? I'd think this information would be available directly in the relation/node data.

With stop_times.txt I definitely think more detail is needed. At least the duration of the stops must be known, Moreover, I can imagine lots of situations where some parts of a route allow for higher speed than others. (To make even more complicated: two ore more routes might share a single stop, which could cause waiting times.)

What I actually don't understand is the fact that stop_times.txt specifies fixed "time of day" values instead of just the time difference (in seconds) from the start point.

Entitled or not, it's not a secret that OGF itself is basically a copy of Openstreetmap. All necessary software components are freely available, and the setup process is documented reasonably well.

It might not be normal to demand information and tools for creating a copy, but the good news is that an OGF-like website can be created by copying OSM instead. The information and tools to do it are definitely out there, and the page linked by isleño gives a starting point.

Now I'm not saying that it's easy. In fact, because of the architecture of several different software components working together, it's actually somewhat complicated. Nevertheless, it can be done, but I wouldn't attempt it without a solid base of Unix and RDBMS knowledge.

If the timetable URL is tagged in the route_master relation, then there's no need for a unified naming schema. Having one giant wiki article is probably a bad idea. Of course people need to agree on a standard for the timetable content.

I didn't actually think about scraping the data from the wiki, but rather ad-hoc downloading and extracting whenever a timetable URl is encountered in a relation object. Performance-wise, scraping might be the preferable approach, but that can be added later if it turns out to be necessary. Maybe all pages containing timetables should be put into a common category, so the Mediawiki API can be used to query them.

Another scraping method might be to run an Overpass query on all "route" or "route_master" relation containing the "timetable_url" tag.