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.

But like many things, we need more people coding, and more community support for those who are already coding.

@Andy Allan: as you’re mentioning this point: the pull request to remove those remaining slow parts in the map call is already out there, waiting to be reviewed, merged and deployed: https://github.com/zerebubuth/openstreetmap-cgimap/pull/142

@Komяpa : you’re still very welcomed to rerun your test setup to see how this change affects runtime, see this comment

Looks like you hit one of the hotkeys. Check the data menu

• Set building shape to circle ALT-Z
• Set building shape to rectangle ALT-R

I put together a small Overpass query to find such instances with exactly 1 from, 1 to element and at least 3 way members (that’s close enough for the purpose of this analysis):

http://overpass-turbo.eu/s/xjH

Caveat: query uses not yet released feature count_by_role (will be part of 0.7.55 release)

Actually I didn’t think my mass edits falled in “automated” category mentioned by the code of conduct you quoted.

If you take a look at the scope of said Automated Edits code of conduct, you’ll notice that your blog post exactly matches point 4 in the scope section:

“use of find-and-replace functionality using a standard editor such as JOSM or finding using services such as Overpass API and changing without reviewing cases individually”

It’s really not necessary to remove the trailing „m“ in Osm data for overpass turbo to work. Instead you should convert the relevant ele tags to a number. Roland wrote a blog post about this topic which explains all the details!

http://dev.overpass-api.de/blog/numbers.html

Given how much discussion there was on data privacy issues with regards to Pascal Neis’ HDYC tool (with the result of requiring people to logon and only providing for one user at a time), it’s really intimidating that you manually analyzed the mapping behavior of each and every single top 2000 contributor (!) and put it up out there in public as “Notes” column.

I’m pretty sure things like “sadly deceased Nov. 2016” for sure don’t belong in such a list. Also, I find comments like “badly overnoded import of Fukuoka woods” or “very badly inefficient waterways” not that helpful.

Any chance you remove this information altogether?

@tyr_asd: afaik, JOSM changeset viewer is essentially another frontend for OSMCha, the data source is the same, i.e. geohackers aws feed.