Some people advocated migrating preset definitions to Data items - but as someone developing one of editors I just do not see it as a viable solution.

See how some OSM Wiki articles are contradicting each other or end in confusing weird states as result of compromise. Or have temporarily absurd claims before it gets fixed.

That is survivable in documentation treated with some scepticism. That is not viable for editor presets.

Sorry for silly list formatting above. Also, I am not claiming that data items cannot be useful, just explaining why they were completely pointless for me, and this reasons may be shared by some other people.

I’m genuinely interested in knowing why the Data Items was not used to its full potential.

You probably have seen my comments already but for me there are following reasons:

• data quality is lower than in what is specified as parameters of infoboxes (due to serious UX problems - one major part is tracked as https://phabricator.wikimedia.org/T43686 but see also for example osm.wiki/Talk:Data_items#Order )

As watchlisting interface is atrocious damage will be easily missed. I bet I could find silently redefined/broken data item descriptions that were left without reaction if I would cobble together more complex interface (unusable by others due to reliance on scripting).

• data items do not contain anything so structured. In vast majority of uses you would take image and description, which may be as well as taken from infoboxes. Wikibase is complex and allowing storing structured data (sources, qualifiers and many other) which is not used at all in data items as far as I can see.

• In many cases all this data is useful as giving hints and needs to be looked on manually anyway, at which point any benefits of easier automation are completely disappearing and you are left with only disadvantages

For example I use OSM Wiki heavily while developing StreetComplete. Images from OSM Wiki are sometimes useful, but often different are needed. And cropping them is always necessary.

So OSM Wiki illustration are only the first candidate at most.

I could look at data items instead but what is the benefit here? How I would benefit from automation?

The same for goes for descriptions, due to different context StreetComplete needs a bit different descriptions than OSM Wiki (or data items) are using.

I basically gain nothing by interacting with data items (or even lose due to janky interface and some items randomly displaying images at the bottom because Wikibase cannot even display properties in consistent order)

• wikibase API is complex, annoying and troublesome. In comparison using https://github.com/earwig/mwparserfromhell allowed to get me parsed infobox parameters in time that I used in failed attempt to get “required tags” field out of wikibase API. Going by name mwparserfromhell is dealing with a lot of complexity underneath, but as user of this it was really pleasant.

• data stored for example in osm.wiki/Property:P12 is often really dubious and poorly defined to the point that relying on it is a mistake

that are notable to be on OpenStreetMap

I would rather phrase it that OSM has no notability requirements whatsoever

If you are trying to add it to the map, the you need to edit map at osm.org/

talks at SoTM

Thanks, it is nice to hear that you liked it!

Ładne mapowanie!

A jak była to wizyta na miejscu: co chcesz przekazać przez way/606688734 motor_vehicle=official ?

Nie jest tam czasem wjazd samochodami tylko dla mieszkańców, może jakieś szlabany są? Czy na pewno każdy może tam samochodem wjechać?

Gdyby była ochota na jeszcze więcej szczegółów…

Czy node/5750185622 to nie jest czasem wjazd do parkingu podziemnego?

StreetComplete (aplikacja na Androida) też by trochę szczegółów wykryła do uzupełnienia (np. pojemność parkingów rowerowych node/9974830338 )

are we mapping for the renderer?

mapping for renderer is fine, lying to renderer is wrong

mapping correct data in standard format is fine, mapping fake data to force specific display is wrong

Dzięki za dodanie tego!

Innym pomysłem jest też Vespucci, wtedy można mapować z pominięciem uwag. Ale nie wszyscy ten edytor trawią.

Oh, development is definitely slow, new features are rare or just tiny tweaks hard to describe as feature.

But I have no idea why people often make claims about dead project and that nothing at all is being done. It just derails discussion as is trivial to disprove.

And list like yours is actually more impactful (especially as “separate preferences and profile forms” made things worse)

However, we still have an inconvenient registration form. Try to take the place of a beginner and register on the site, for example, from your phone. I’m sure you won’t like something

Oh here I agree. See say https://github.com/openstreetmap/openstreetmap-website/issues/2287 that got WONTFIXed and https://github.com/openstreetmap/openstreetmap-website/issues/3259 that actually got fixed

I am not claiming that OSM website is brimming with new features and that development is going wonderfully. It could be much worse and right now it goes slowly

But things like

we haven’t seen any new feature for years. :-(

are clearly incorrect and easily demonstrable to be false. Even if one limits themself to core website and ignores dependencies like iD and OSM Carto and routers and so on.

There is plenty to criticize and to help (though sadly, sometimes help is rejected) or to work on various projects. There is no need at all to claim untrue things.

For example “Allow users to delete their own accounts” https://github.com/openstreetmap/openstreetmap-website/pull/3398

See https://github.com/openstreetmap/openstreetmap-website/commits/master https://github.com/openstreetmap/openstreetmap-website/pulls

we haven’t seen any new feature for years. :-(

That is untrue. It is possible that nothing that was added is considered as important or major by you.

the idea given by the openstreetmap.org website is that of an abandoned project …

That idea is wrong.

https://addons.mozilla.org/en-US/firefox/addon/openstreetmap-tags-editor/ - English link for FF

I guess that it is time to link https://ourincrediblejourney.tumblr.com/ which lists cases of services breaking promises and turning on users.

In general I would put limited trust into such services, especially ones with inability to download full datasets ( unlike say https://planet.openstreetmap.org/ ) and which are not truly open source.

Questions were previously asked of Mapillary “can I show my photo on a different site” & the answer was to point at the button to download and suggest to use the url for that on the foreign site.

If that was official answer, then it changes things significantly and invalidates also “Unless the URL and its usage terms are documented, you’re not promised anything.”

I just want to say that given FB involvement it was entirely predictable that things will get worse.

But blocking hotlinking is relatively normal. FB refusing to donate bandwidth is not something evil.

Compare say https://operations.osmfoundation.org/policies/tiles/

OpenStreetMap data is free for everyone to use. Our tile servers are not.

It seems that Mapillary has decided that these freely-donated photographs can only be used for it’s benefit.

But you can still follow https://www.mapillary.com/app/?pKey=<16-digit-numeric-ID and download it, right?

I consider FB to be net negative and so on, but I see no reasons to be outraged here.

I fail to understand how this question of which separator to use in a DSV file for simple tabular data still comes up, since it’s been solved for decades

Files which are non-human readable are obnoxious for various reasons, so I am not surprised that https://en.m.wikipedia.org/wiki/Delimiter#ASCII_delimited_text are rarely used in practice.

PS: using tabs instead of comma+quoting+escaping is the opposite of weird, and in general (for what people normally use CSV) it’s a step in the right direction.

But calling it CSV is weird. tab-delimited CSV is not CSV.

I occasionally used such things, and for me CSV (with escaping and comma delimited) is a good format.

Tab delimited is weird, but I guess that something can be cobbled together to use this - especially if it can be assumed that domain names are without tabs or at least escaped.

Providing total sum for all, including domains not listed would be useful if possible to estimate long tail, unless every single domain is published.

14531.99 4641.1 * ? Or as separate entry?

Is it possible for domain to be unknown?