Nein. Dein passiv aggressiver Ton passt hier echt nicht rein. Wenn du ein Problem hast, mach halt ein Issue auf Github auf und schildere dort sachlich dein Problem, ohne zu unterstellen, dass die Maintainer oder Admins die letzten Deppen sind, die es einfach nicht gebacken kriegen.

Also mit Bild innen und Link außen tut das ohne Probleme: http://www.disturbancesinthewash.net/journal/2012/8/11/how-to-add-an-image-with-link-in-markdown.html

That’s just spam!

Looking at the huge number of communication channels on osm.wiki/Contact_channels and all related sites mentioned there, I think that would be quite a massive task.

Unlike the mailing list archive with its single server and uniform access, each platform has some different kind of API, if at all. Some platforms might require you to sign up first (e.g. Slack), and scraping websites might violate their ToUs.

Lots of project related communication also happens on various issue tracker (Github, Trac, etc.), and keeping track of them isn’t exactly trivial.

Also, people sometimes use different nicknames on different platforms, which makes it a bit more difficult to link profiles.

To sum up, we’re probably looking at hundreds if not thousands of different channels that would need to be covered for a somewhat comprehensive view. And all that keeps changing over time.

Pretty obvious I would say. Mailing lists are 1870’s technology, and lots of people use different communication channels today that are more familiar and convenient to them. I for one find it quite annoying that I cannot edit my mailing list posts after sending. If there’s one thing those figure are not indicative for, is that the overall osm project related traffic is declining. It’s simply spread across so many more channels.

The phrase “….” is repeated 5 times.

Not sure where you’re getting this, the original doesn’t have that sentence repeated. Maybe some glitch in your translation tool?

Testing continues on the OSM Dev server now: https://upload.apis.dev.openstreetmap.org/

See this link for details.

Das Thema wird bereits im Forum diskutiert, bitte dort weitermachen: https://forum.openstreetmap.org/viewtopic.php?pid=715532

Case insensitive wildcard search for a relation name isn’t really that difficult:

rel["name"~"härnö trail",i];
out geom;

overpass * does not search case-insensitive

That’s also incorrect. Please check out the documentation first next time before posting.

Your example query uses “2010-08-01T00:00:00Z” as date along the comment “Find data in view at any point in time”. That’s not quite accurate, since Overpass API only includes data since the ODbl license change, which is 2012-Sep-12.

See osm.wiki/Overpass_API/Overpass_QL#date:

There is no attic data in the OpenStreetMap database with a date earlier than 2012-09-12T06:55:00Z (1347432900 in epoch seconds). This date corresponds to the first change included in the ODbL compliant planet file. Use of an earlier date setting is technically possible, but doing so will always return the database state as of 2012-09-12T06:55:00Z.

No, it’s not in production. You’re getting some Rails issue here, probably due to the server move. https://help.openstreetmap.org/questions/64900/huge-error-when-saving

I think I still have to read just the top relation node from OSM API because overpass does not include the last edit time for the relation,

There’s really no need for OSM API for your use case. All you have to do is to use out meta; instead of out body; and you should be all set.

[out:json]; rel(5173237); (._;>;); out meta;

If you don’t need to resolve relation members, try rel(5173237);out meta;

Please take a look at the docs for more details.

It’s not a license thing, for sure. As I said, it’s about the usage policy, and the purpose for which you use the API. The policy states: The editing API is provided in order to edit the map data, not for read-only purposes or projects.

From your description it doesn’t sound like you’re editing the map, but it’s rather some pulling OSM data and doing some local analysis thing, which is not permitted according to this policy.

i don’t recommend using the Osm api for your project, as it would violate the usage policy: https://operations.osmfoundation.org/policies/api/

Thanks a lot for taking the time to test different scenarios and providing some feedback here. Much appreciated.

This project started in December 2017 as a complete redesign of the current Rails based implementation with a special focus on backwards compatibility and performance. It leverages mass database operations wherever possible. My main motivation to start this project was probably my dissatisfaction with the current performance.

The idea to move the changeset upload to cgimap is not really new: it was first mentioned in some 2011 EWG chat protocols and later appeared in the GSoC 2017 + 2018 proposals, which unfortunately nobody accepted as a challenge. This project is pretty much independent of any GSoC, though. zerebubuth was helping quite a bit to fit the new implementation into the current cgimap, and getting it technically “ready for deployment”.

PS: Everyone can still help out! The more testers we have, the more potential issues we can discover at an early stage! Thanks to all testers providing feedback so far.

Remove all those ({{bbox}}) and your query will be much faster.

Try nwr instead of node to also include ways and relations, and finally out center meta; to get all center points of those hits. Export to gpx and everything else should be as described in your blog post.

Apologies, I really don’t intend to hijack this blog post…

@Andy Allan:

Secondly, it’s crucial for all editing software that it provides read-after-write consistency, so that when a changeset is saved, the next /map request is guaranteed to contain that fresh data.

Just wanted to add a short remark about this point. There’s really a rather small but noticeable replication delay, which is typically in the range of 1, maybe 2 seconds. Some applications like the iD editor introduced an artificial wait time of about 2.5 seconds to be sure that the /map call they use to re-populate the editor contains all data which has just been uploaded. Still, in some exceptional cases, the data might not be replicated yet.

Please see https://github.com/openstreetmap/iD/issues/1646 for more details and further discussion.

Sure, it doesn’t address the caching part. Otoh, such a cache will be incredibly difficult (and expensive) to keep in sync and given that we’ll hopefully end up with very small database times and the expected savings being relatively smaller, I would reevaluate this topic once changes are in place.