I created this image with data from Overpass API, dated 2012-10-01. Maybe that’s a good alternative to downloading GBs worth of data for a full history planet. Earliest possible date is Sep 12, 2012.

In fact, you can do it also in iD as described in the many Github issues on this topic. I’m providing a short summary of all the steps needed:

1. Type in 46.7138607,12.3411447 in the search bar, hit enter, then select the “location” in search results.
2. Press Ctrl+Shift+L to toggle the location panel in the lower right corner
3. Press “+” a few times to zoom in. Your location should still be in the middle of the screen.
4. Add your node in the center of your screen. Make sure your node is selected, then double check the location panel, if it’s matching your location. If not, keep moving the node as needed.

Somehow I’m missing the bigger picture here. Should site owners check this information to evaluate their own resource usage and find out how they compare to others?

Forgot the way id? https://overpass-turbo.eu/s/1jD2

As I see it, GDPR support is a multi-month project that requires a lot of coordination and communication with all possible stakeholders. What we have right now is a description of the “to be” state, but we don’t know yet how to get there with the least amount of disruption.

To make that happen you need a proper project plan, i.e. a detailed plan of how these changes will be implemented and in what order, by whom, etc. And most importantly, you need someone to coordinate the overall effort and have overall responsibility for the outcome (yes, that would be you, OSMF board). It’s just ridiculous to put that burden on the maintainers or any third-party contractor, and everyone knows it.

You probably still recall the discussion we’ve had in https://github.com/zerebubuth/openstreetmap-cgimap/issues/144 and concerns that have been raised there, in particular by zerebubuth, which questioned the whole approach.

In the end, I didn’t see much convincing arguments how we could possibly implement the suggested changes without causing at least some breakage in the ecosystem. The proposal is unfortunately very light on this very important change management topic (I hope I don’t misrepresent this part, it’s been a while since I last looked into it).

I truly hope someone finds a way forward that works for everyone involved. Maybe talk to the EWG, they’re always looking for new exciting topics for subcontracting.

Why on earth would any volunteer developer spend time on a task that the OSMF board decided to outsource to a paid contractor?

Maybe talk to the EWG folks, as they have this topic on their agenda anyway: https://wiki.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2022-05-23#Response_to_OSM-Carto_Frustration

In addition, maybe get in touch with OWG, as they’re looking into vector tiles right now, see https://github.com/openstreetmap/operations/issues/565 … A key resource from planetiler already joined that discussion. I believe this was one of the projects mentioned on one of your screenshots.

OSMF choosing to focus only on database/API

I’m a bit lost on this one. EWG recently granted some funds to assess and estimate efforts related to potential future data model changes. Beyond that, I’m not aware of much of an OSMF involvement here (or I may have possibly missed it somehow…). Is this what you had in mind?

https://help.openstreetmap.org/questions/84625/calculation-of-area-of-nodes-in-osm has some more ideas (duplicate post by OP)

Tiles are mostly served by Fastly CDN these days. IIRC, tile_logsonly includes tiles which haven’t been cached by the CDN and need to be re-rendered. This might result in quite some skewed data. I’d highly recommend to get in touch with @pnorman to discuss those topics before starting actual implementation work.

One thing I found particularly troubling was the project’s inability to acquire and retain talent in the area of cartographic design, as well as the state of the underlying rendering technology [mapnik].

Quoting from the blog post:

If a map design project outgrows the technical framework it is based on, like OSM-Carto increasingly did in 2016, this is a huge problem. Not only because it technically makes it harder to implement design wise necessary or desired changes, but also because it makes contributing increasingly unattractive for the most qualified designers who strive for excellence in design. A map design project where the appearance of the map is not primarily determined by the conscious decision of designers about how they want the map to look, but by the limitations of the software used, is destined for mediocrity and is never going to be a balanced map well serving its design goals.

And yes, I do realize this is a very different discussion than the one in this OSM diary.

Nobody posted this yet, so here we go: http://blog.imagico.de/openstreetmap-carto-an-update-on-the-project/

StreetComplete queries Overpass on the fly so yes, if you add opening hours every subsequent query from StreetComplete will see it.

That’s not correct anymore for some time now. StreetComplete uses the OSM API to fetch all data in a bounding box, then performs some post processing on the mobile device. So data will be even more up to date, as the OSM API doesn’t have any delay at all.

You should check out Protomaps, it’s really easy to use, very fast, and doesn’t require any email registration like the Export Tool. You can even upload your own shape file.

Supported formats include raw data osm.pbf format (https://protomaps.com/downloads/osm ) as well as vector tile formats (see https://protomaps.com/downloads )

Re.: “Deleting a diary post”: you need to get in touch with a moderator (or administrator). Both roles can hide diary posts, as well as hide any comments.

You can also find plenty of example queries:

• on the OSM Wiki: osm.wiki/Overpass_API/Overpass_API_by_Example
• on the dev blog: https://dev.overpass-api.de/blog/

I’d recommend adding four leading space characters in each line to fix the formatting of your queries. Also, putting your queries on the OSM Wiki might be a good idea.

Without 4 leading spaces

( way[“highway”~”unclassified|residential|tertiary|secondary”]“postal_code”!~”.*”; );

With 4 leading spaces

(
  way["highway"~"unclassified|residential|tertiary|secondary"]["postal_code"!~".*"](area.searchArea);
);

In case this temp layer thing should be part of the osm.org stack, this has been suggested by a several people in the past. Frequently mentioned use cases are facilitating imports, QA, approval workflows, conflation. All the usual suspects.

None of this is really feasible, as the entire stack (including all data consumers) is not prepared for such things. And it would certainly be a huge effort to add it.

The comments seem to be correct, I don’t see any changes affecting the area of Taiwan: achavi (experimental fork), changeset map (experimental fork).

The most notable effect is the drop off in new contributors in the 2nd half of 2021 […]

I’m not exactly sure if maps.me ever supported Basic Auth. In any case their “automated sign up process” was likely impacted by a security fix in https://github.com/openstreetmap/openstreetmap-website/issues/3241 some time around July 2021.

By the way, Organic maps fixed the issue pretty much on the same day.