OpenStreetMap

Tordanik's Diary Comments

Diary Comments added by Tordanik

Post When Comment
Mehr Sichtbarkeit für OSM Apps / More visibility for OSM apps

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. :)

Who do you work for?

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.

Bridge Tagging Enhancements

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.

OSMversary, 15 years

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

Openstreetmap-Carto – Democracy Or anarchy?

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.

Renningen Street Completed!

Congratulations, that’s a cool feat!

W3W bei der Bundesautobahnmeisterei

@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.

Pizza Compass using OSM?

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.)

Open source Lover here :) (First Diary: Not 100% sure about this feature,but still wanted to give it a try )

Welcome! Open Source is a treasure we all benefit from and OSM contributions are a fantastic way to pay the favour forward. It’s great to see your enthusiasm! :)

The use of Free and Open Source Software in the OpenStreetMap Foundation

IMO, the chat issue has slipped through the cracks because the proprietary tools are run by entities other than the OSMF. Nevertheless, it has a greater impact on a regular OSM contributor (as opposed to an OSMF working group member) who wishes to use FOSS than many of the tools listed in the report. So while it may not fit the scope of the report well, I believe that bridging existing communities with a Matrix server is the way forward, and that the OSMF should help make that happen.

I also agree with some of the criticism of the community Index, especially given that it is – through iD – arguably part of the OSM website. Before this discussion, it always recommended proprietary platforms over our own, self-hosted ones, and it still does so by default unless a local community explicitly requests a different prioritization.

Changing the proposal process from "For/Against" to "pick you preferred option"

in practice it can leave the mappers and data consumers with no way to map something

Wiki voting isn’t the only way for a tagging idea to become established. There’s also the option of establishing a tag through usage in the database and applications.

As such, the wiki process as it stands isn’t designed to always produce a winner. The purpose of wiki voting is just to speed up the process for cases where a good solution is obvious.

In those clear-cut cases, it wouldn’t be worth it to wait for a de facto consensus to emerge, as that might mean a few years of ambiguity and slower progress. But when there is no clear best solution, there is some value in the slower approach of gaining mindshare among mappers and developers until the idea becomes established: It means that the tagging idea will actually have to prove itself to some extent. It may well turn out that none of the initial tagging suggestions was a good one because a proper solution requires, for example, better editors or improvements to the data model first, which cannot be brought about with voting alone.

New major feature: Create your own links!

This is awesome, thanks a lot! I’ll make sure to drop by the issue tracker if I discover any bugs. So far it works like a charm!

New major feature: Create your own links!

I can only speak for myself, but I’d find support for tags useful. In addition to the OSM Wiki and Taginfo, I’d also use the feature for Taghistory and Overpass Turbo, and I’d probably define a few links to frequently-used Taginfo subpages for my own use as well. (Overpass is one-way, sadly – you can get there with an URL containing a key and/or value, but it instantly forwards you to a different URL.)

Would the extension be able to understand that {osm_tag_key} can be used together with {osm_tag_value} as well as by itself? Or would there be a separate parameter for the key-only case vs. the key-of-a-tag case?

New major feature: Create your own links!

This is a great feature, thank you! I expect myself to get a lot of mileage out of the various id parameters as well as osm_user_name. :)

Is there a chance that we’ll see additional bracket parameters in the future? For example, I often find myself switching between different pages for tags (i.e. key and value somewhere in the URL) as well as keys, and this seems like it would fit the concept.

Summary Report on OSMF Chair's Outreach Jan-early Apr 2020

Rob, be assured that members of the board spend thousands of hours on the community’s communication channels, at OSM events, and in direct conversations with other members of the community. This may not be explicitly labelled “outreach”, and we aren’t usually writing blog posts about it because it’s just a normal part of daily life for us. Still, it serves many of the same purposes of keeping an ear to the community’s concerns and informing our next steps on the board.

Allan’s outreach strategy complements our usual methods in that it reaches some people who we otherwise don’t hear from as much (and vice versa, of course). Our 2019 Pre-F2F and Pre-SotM surveys had similar benefits in unlocking input from additional corners of the community.

But please don’t assume that we don’t listen as a matter of course, and that this is more than the tip of the iceberg. If any of the community members who read this have something to share: You don’t have to wait for us to call you! Your views are valuable, so please don’t hesitate to discuss them publicly on one of OSM’s platforms, or to approach the board or one of its members directly if you prefer.

Descriptions of OSM tags in any language using Wikidata

It’s definitely a cool demonstration of what’s possible with Wikidata! I’d like to see more projects make use of the many links between the OSM and Wikidata ecosystems, so in that light, it’s no doubt a great project. :)

When it comes to the reliability of the resulting translations, though, I feel SomeoneElse’s objections are, at least currently, justified. It’s true that there ought to be a semantic equivalence between a tag and the linked Wikidata item, but wiki editors are often tempted to link items that don’t match precisely. To use an example from your post, traffic_calming=chicane is linked to “chicane”, defined as “artificial feature creating extra turns in a road, used in motor racing and on streets to slow traffic for safety”. But as far as I know, the traffic_calming key is not intended for motor racing, which would make this a false equivalence.

There are also cases where the Wikidata definition is a good match, but translated terms can still be misleading. For example, you mention footway=sidewalk and Q177749, where the German label is “Gehweg”. This term is ambiguous: While it often means “sidewalk”, it can also mean “footpath” – which might lead to incorrect use of the tag.

Thought experiment: What if values had no keys?

I also tend to find the “artificial buckets” annoying. Not only do they make tags harder to remember and cause discussions about which bucket to put something in almost every time we invent a new tag, they can also lead to misunderstandings about the meanings of a tag. Particularly infamous in this regard is the “natural” key, which has a tendency to make people assume that they are only allowed to tag “natural water” or “natural peaks” with those tags.

In theory, it would be possible to get rid of the problem without an API change by introducing a special key such as “feature”. The values of that key would then be the feature’s type such as “park” or “farmyard”. Replace the arbitrary small buckets with a single big bucket. But it would still be a massive change that is unlikely to ever happen, sadly.

Units in OpenStreetMap

Personally, I try to always add units to avoid any ambiguity. Sure, defaulting to SI units makes sense. But when some keys want meters as the default (e.g. maxheight), others want kilometers (e.g. distance), and again others want centimeters (e.g. the proposed step length), then mistakes will happen. Always adding the unit is easy and fixes that issue.

Units in OpenStreetMap

Personally, I try to always add units to avoid any ambiguity. Sure, defaulting to SI units makes sense. But when some keys want meters as the default (e.g. maxheight), others want kilometers (e.g. distance), and again others want centimeters (e.g. the proposed step length), then mistakes will happen. Always adding the unit is easy and fixes that issue.

New road style for the Default map style - the first version

@escada: Sure, you will get different results depending on whom you ask. But it’s not automatically true that Germans will prefer orange-red motorways. I’m German, but I’ve never had much exposure to Michelin maps. (I’m probably too young.) So to me, blue seems like a perfect colour for motorways.