I’ve been a heavy OSMCAL user for years. It has helped me organize and participate in all sorts of events, such as local community meetups, OSMF working group meetings, hack weekends and conferences. Thank you for creating this tool!

Danke für diesen Katalog, das ist die schickste Lösung zum Stöbern in OSM-Apps, die ich bisher gesehen habe! Und als Autor von TTTBot freut es mich natürlich besonders, dass etwas von der damaligen Arbeit wiederverwendet werden konnte. :)

The ODbL sounds good when framed in terms of abstract goals: Let people know about the community which made your product possible and give something back.

But in practice, I feel it mostly results in bureaucracy and missed opportunities. It means that time which could have been spent on building stuff must instead be spent on wrangling legal issues. It means that we cannot fully cooperate with government organizations which want to release their data in the public domain. It means that it’s a common occurrence that someone with an idea for a genuinely nice project writes to some OSMF contact email and we have to respond with “sorry, it’s understandable that you can’t comply with ODbL in your situation, but we can’t make an exception for you. You’ll have to do without OSM.”

Ultimately, I just hate having to tell people they can’t do this cool thing with OSM, so I wish my contributions could simply be used by everyone with no legal strings attached.

Nice detail, and having a separate element for the bridge itself definitely makes it much cleaner to add tags to it!

I think bridge:structure is still used in combination with man_made=bridge, though. Unlike name or ref (where the bridge: prefix is purely for disambiguation with the street’s name), I don’t think it’s supposed to be shortened when used on a bridge polygon.

And I thought I had an old account. That’s really impressive! :) Belated congratulations to your OSMversary!

I don’t think democracy is well suited for software development or map style design, and autocratic projects are quite common and successful in the open source world.

But: What makes this model work is credible competition. Forks allow the community to assert control when maintainers steer a project in the wrong direction. And in the case of osm-carto, the OSMF provides substantial support (technical resources and visibility) which is not available to a fork. This raises the bar for competing efforts.

Having read through the GitHub issue reinforces my impression that the goals of osm-carto and what we expect from the osm.org default style aren’t fully aligned. I consider it unfortunate that osm.org showcases an increasingly smaller fraction of the work mappers put into the OSM database. And I would appreciate a larger community of contributors to the default osm.org style, even at some risk of “mediocrity in design”.

How to move forward from here is an open question. While I agree with the principle outlined by Amanda – that the OSMF shouldn’t be too deeply involved –, I’m afraid that we’re already involved to a substantial degree by strongly favoring osm-carto over other projects. We need to figure out how to lower the bar for new map styles to make it onto osm.org.

Congratulations, that’s a cool feat!

@domih: Der große Pferdefuß ist, dass die Firma hinter W3W das Eigentum an der Liste der Wörter für sich beansprucht (und auch den Rest der Welt mit fragwürdigen Patentansprüchen davon abhält, die Idee einfach mit einer anderen Liste von Wörtern umzusetzen – technologisch wäre das ja nicht weiter schwer).

Deshalb muss eine Übersetzung von W3W-Wortgruppen in Koordinaten und umgekehrt immer über die kommerziellen Dienste dieser einen Firma laufen. Und rein mit Open-Source-Software kann man diese Art der Ortsangabe von daher natürlich auch nicht umsetzen.

W3W-IDs dürfen wegen dieser Rechtslage nicht in OSM eingetragen werden und ein größerer Erfolg von W3W könnte OSM und freier Kartensoftware schaden, weil wir dabei insofern außen vor wären. Von daher hoffe ich, dass der von Peda entdeckte Schildbürgerstreich eine Ausnahme bleibt.

Yes, you could build something similar using Overpass API. Query all features matching your search criteria around your current location (you could use “around”, but a bounding box query should actually be faster and good enough) and sort the results by distance from your current location in your own code.

Defining sensible search criteria would be a bit of a challenge. At minimum, you’d want features where the cuisine or name tag contains “pizza”, with some tolerance for spelling variation. However, you would inevitably miss some places that serve pizza, but don’t advertise this in their name and are tagged with a different (or no) cuisine.

(Btw, cool project, but not exactly FLOSS – non-commercial use only.)