Note that those glagolitic scripts in Baška are only on few dozen pieces of artwork, representing our Croatian (far) past history… (e.g. https://www.info-krk.com/en/baska/culture/265/baska-s-glagolitic-alphabet-trail).

In other words, you’d never see Glagolitic script in Croatia in actual use outside of museum piece, or piece of art (made to evoke memory of ancient history) - so think of it perhaps like a Egyptian hieroglyphs younger brother.

Is a font needed for that? Perhaps for inscription=* tag in those dozen cases? But it looks like overkill to me…

Well, I hope you guys are right. I still think UI changes at this point (instead of doing them several months down the road) are unnecessary risk taking, as the project needs to get buy-in not just from progressives but also from conservatives too (and they might dislike changing their habits), and there is no guarantee that this new code will actually get used by OSM (once feature parity is accomplished and code published; that will be hugest decision in OSM since OdBL-license schism since its inception, and opinions on that already seem polarized).

I’m in support of python version, if baby steps of walking before running reduce the changes of rejection, I’d consider them.

To me, the main points are:

• is the new python code easier to maintain then older ruby on rails? That is IMHO the main breaking point, and it would depend mostly on OSM Ops team decision, and pool of new wannabe-ops-volunteers that it might produce (one of OSM main bottlenecks).
• does the new design allow more features to be more easily implemented, and are more people willing to volunteer their time more to do so? This is what most of the community is rooting for, and why this project is a big deal (obviously the language choice, but also to underlying design choices. And adrenaline rush of new developer willing to add new stuff is big in itself!)
• can it be run / tested in parallel with current production code (this is huge issue, as Ops want the code to have proven reliability before even considering to look at it. It is also a reason why keeping with same PostgreSQL schema allowed this project to proceed - if NorthCrab were to insist on original noSQL ideas, that would IMHO be insta-killer for the project adoption)
• is the the new code faster / uses less resources? Obviously, this is easily shown by benchmarks, and more objective than most, so everybody will like that (provided it delivers on those promises)
• UI design changes - meh. You could do such UI design changes on current backend too. It is non-issue why someone would walk this project (instead of just much more simple PR doing proposed HTML/CSS UI changes to current Ruby code). But as any design change, it can be disliked by some, which would prolong (or even reject in extreme cases) time for adoption of whole project. And this high-risk / low-gain is the issue I’ve tried to warn about. (although I might be wrong about my estimates, of course – I’d actually love if they were wrong)

While I agree that improving usability should be one of the goals down te road, I’d highly suggest that you initially focus only on replicating existing functionality with same UI and not “also on improving the user-facing interface and experience”. The reasons being:

• it will be much harder for people to compare if new code is working equivalently to old code if they display UI differently, which will lead to more doubt and less acceptance
• not everyone will agree that new UI is better (for a lots of reasons: some prefer compactness to visual fluff, some just have mechanical memory of using old UI, some might disagree on what looks better etc.) - so trying to force modified UI in addition to changed codebase will inevitably result in less buy-in: so people will vote not only on technical merits (speed improvements, improved code readability and maintainability, allowing much wider developer base) but on their UI preference, and that will always be less than 100% on any change, no matter how good it is.

Once the new code (which looks and works just like the old code) is accepted to be new mainstream; then you should start on changing UI to be more usable.

More discussion about the issue on https://community.openstreetmap.org/t/on-replacing-basic-auth-with-oauth-2-0/108288

What, no infinite-loop recursive references? I’m somewhat disappointed ;-)

yes, it seems to be offline. Source is still available should you want to bring up your instance: osm.wiki/Meet_Your_Mappers

We may end up largely abandoning the @OpenStreetMap twitter account for those kinds of reasons anyway.

Good riddance, I’d say.

I’d love it even more love if https://twitter.com/OSM_Tech announcements would switch over to Mastodon, too (or anything else open which i can RSS or follow via API); not being able to follow them is annoying.

So, does that “Taghistory’s web interface is updated now to also fetch taginfo’s chronology data if available” mean that taghistory now too only works for “most frequent tags”?

I.e. https://github.com/tyrasd/taghistory/issues/34

Regarding performance problems, it might be network and/or device speed related.

If there’s anything I can do to test this locally, let me know. I’ve also got a chromebook and a couple of old laptops here that might show the same issue and show what is “eating all the pies” in the site itself.

@SomeOneElse you can press “F12” in your desktop browser and choose “Lighthouse” (for Chrome/Chromium) or “Performance/Web Developer” (for Firefox), and look (or share) the results. “First Contentful Paint” and “Time to Interactive” are good general metrics to look at. (There are lots of details to see where the problem if those are too big.)

@Firefishy: there are also web-based tools to analyze where is slowdown, e.g. https://pagespeed.web.dev/analysis/https-community-openstreetmap-org-t-performance-issues-with-discourse-3-0-8182-11/llr6v442j1?form_factor=mobile

on 3G mobile network, it says 4.5s for First Contentful Paint. There are other detailed tools like https://gtmetrix.com/ or (now requiring login, grrr - I’ve quite like it before, though) webpagetest.org

How much of that is fixable by non-discourse developers is questionable, though. But one might check if there are any low-hanging fruits.

It is in particular a bad match for StreetComplete (as it is not working in background at all, and is based on user input, not automatic data acquisition).

It was suggested before; see this comment and answers below for original blog post and various issues with that approach: https://github.com/streetcomplete/StreetComplete/issues/1630#issuecomment-663978436

I see it has few uses now and is only ranked “in use”.

It means it was tagged under osm.wiki/Any_tags_you_like policy (since at least 2009 it seems: https://taginfo.openstreetmap.org/keys/camping#chronology) , and someone finally had enough time to document it at wiki in 2020.

If its usage continues to grow, one day it will be eligible for most-coveted status “de-facto”, see osm.wiki/Tag_status

“approved” status just means there was some discussion, and dozen or two people didn’t find big problems with that idea. You’ll have to look at taginfo statistics on the side to decide how popular it is indeed. “de-facto” however means it is actively used by tens of thousands of people, despite never been been officially proposed via osm.wiki/Proposal_process (so “de-facto” is beefed-up “in-use”; and “approved” might be closed to “in-use” or “de-facto”, depending on the usage statistics)

The purpose proposal process and “approved” status is there to find out more obvious problems, work out some kinks, perhaps gets extended a little bit to cover less popular use cases, and to give it more exposure. As such, due to “more eyes will see more problems” paradigm, it will often (but not always) produce somewhat better results then ATYL and “in-use” (depending on luck, how simple the tag is and how experienced and much effort person inventing the tag has put into it). So that is why it is preferred. But it requires much more effort and time, so it is always a hard choice…

Having said that, “camping=yes/no” on areas seems simple enough to me, so I don’t see any barriers on using it, especially since it has been documented on the wiki and nobody raised concerns in last 2+ years.

There does seem to be a proposal page for the wiki, too, but it has no information.

hmmm, where exactly, I’m not seeing it?

In order to gain visibility, it should be marked under “see also” on tourism=campsite.

Thanks, good catch, I’ve linked it now.

Also, if you’re interested, usually you’ll get more exposure (and thus more chance for useful answer) for your tagging issues if you ask tagging questions in forum https://community.openstreetmap.org/c/general/tagging/70

That might be too much exposure sometimes, though. I’ve only stumbled on this blog entry by chance as it was featured in OSM Weekly, so, glad I could help.

I would also want something for “in designated sites only” for forests that have “yellow post sites” or the examples in Maroon Bells-Snowmass Wilderness above. The word “designated” wouldn’t cut it since it has different implications.

Why do you think “camping=designated” would have different implications? It looks reasonable to me. It would be good to document on the wiki what you used it for, if you end up doing it. But if only specific sub-areas have allowed camping, I’d indeed use “camping=designated” just on those smaller areas where it is signed, instead of marking much larger area and “camping=dispersed” (which I’d probably use only if the areas were not fixed, as described on the wiki)

there exist osm.wiki/Key:camping

so I guess marking the area and tagging it with camping=no would be what you want (you can also add other tags that may apply of the camping is prohibited for specific reason, e.g. boundary=protected_area or leisure=nature_reserve etc.)

However, this makes me wonder how applications such as StreetComplete and EveryDoor got to such a big userbase quickly

I can give my experience… I’ve love (especially offline) PWAs, but online map-based ones are not really ideal use; they seem clunky and slow. (personally I’ve found user experience using MapComplete on mobile, in several of the free web browsers from f-droid that I’ve tried, to be sub-par, especially when compared to StreetComplete)

So being mostly-offline with some preparations (so no data charges, no huge battery drain) with fast resposiveness and beautiful and simple UI is certainly huge boon– but the biggest thing is in fact versatility.

StreetComplete for example has “Overlay mode” which is somewhat similar to MapComplete themes (i.e. it covers only one thing: one overlay only covers shops, other only cycling infrastructure, yet other only road surfaces etc.) – while those are more powerful than “Quest mode”, I find that I use Overlays waaaay less then regular (somewhat less-powerful) StreetComplete quests. (and both StreetComplete modes are equally fast and user friendly, so that eliminates that factor from the equation)

The reason being that I’m not interested in only one thing. I’m very interested in dozen of them. And having to constantly switch from overlay to overlay every hundred meters is so painful overhead (each overlay change requires 4 clicks!) that I simply give up on it. With StreetComplete quests on the other hand, I can enable dozen of them and very quickly answer all of them using same interface with no overhead at all. It is a pleasure to use and covers dozen(s) of my interests at once.

Same thing with EveryDoor - it allows me add, remove, edit or move any POI quickly. While it does have 4 separate modes, they are all single-click away, and I spend most time in only one of them (either “amenity mode” if area is weakly mapped, or “micromapping mode” if it is well-mapped).

The ease of accomplishing ALL that one wants from single place is overwhelmingly attractive to me.

As another example of that psychology effect, when I take a two-week vacation for cyclotouring, I’ll depend on OsmAnd and offline maps. Not because it is the best source of data (it isn’t), but because it is offline, and everything is in one familiar place.

I find even the idea that I should download, learn and use dozen of different apps for that one trip, each made exclusively for one city or region or county (so that I would use each of them at most for a day or two) is so ludicrous and tiring that no amount of high quality curated and guaranteed up-to-date data that they provide would be able to make up for that lack of convenience and win me over. Hey, I’d probably stick to OsmAnd even if the app with perfect data was country-wide (and not only because they’re rarely open source, which I hugely prefer, but also because they’d either have to be extremely basic thus lacking much of the info I want, or they’d have to be as complex as OsmAnd and it would take me weeks just to learn to use them efficiently)

I wish municipals paying for making of those apps would realize that and instead of paying developers to creates myriad of the navigation apps, they’d pay them for syncing their high-quality data periodically to OSM instead.

While majority deprecation proposals are problematic, the ones I find most offending are “rename” ideas, e.g. “let’s make a tag with identical meaning like previous tag, but this new one being tidier/clearer/in better hierarchy”.

Especially since they very often quite happily ignore (or hugely downplay) all the problems that “tidiness” brings when applied to tags that are already in use:

• people engaging in discussion have to waste their time explaining why that is bad idea (lest bad idea comes into practice!) thus leaving them less time to do more productive OSM-related things

• wiki editors will have more work to do which could’ve avoided (especially as almost always there will be people to disagree, change and revert pages etc so endless cycle of watching wiki pages and fixing them will ensue).

• regular map editors will now have more work, as they will have to consult multiple wikis to decide which one is correct, lookup the wiki recheck their memory which of the tags they remember is the favored one. And even if editor have extra support for deprecated features, it is still more work as they would have to confirm that changes.

• Unless exactly 100% of all mappers agreed (which never happens in reality), there will be edits with old tags as well as new ones, re-editing with new values, reverting to old values, potential for edit wars etc. Wasted time and effort by all parties involved in the best case, community schism and lost good editors in the worst.

• editor programmers will have more work, as they would have to add support for new tag and remove support for old tag. And sometimes also they will have to add code to deprecate/warn on old tag and suggest new one, with explanations.

• editor support channels (as well as regular forum / mailing lists) will have more work, as people will become confused and unsure, and it will have to be explained to them

• data consumers will have more work, as instead of supporting one tag, they will have to support two of them (and have special cases how to handle inconsistencies if both are present but claim different things).

• QA tools writers will have more work to add new checks and document them

• even people wanting to see only a new tag will have a lot more work – and vast majority of them will give up before promise of “better future” (i.e. only new tags remaining) is accomplished: making issues PR for all editors, contacting users adding old tags (e.g. manually of from custom presets make in the past as they have a solution that works and never heard of the change, or older version of software, or because they are not convinced new tags are better, or …), updating all online (and offline) documentations / slides / video presentations / … (or at least remove / mark them as obsolete, thus destroying useful information)

• and the list goes on…

And all of that just for the promise that “well maybe sometime in the future, decades along the road, one raw tag might be slightly more readable, at least according to some users”.

In short

There is lot of pain associated with deprecating things. That does not mean that the deprecations should never be done, but instead that all those pains must be taken into account, resources allocated to address them, and that deprecation request should proceed only if advantages that depreciation bring overweight (hopefully by a big margin!) those disadvantages.

ObXKCD:

It seems opening trac ticket has worked in the past for cleaning spam accounts. Perhaps do it again? https://trac.openstreetmap.org/ticket/5276

Richard: thanks for warning, I did not mean for it to sound like I could speak for anybody else but myself on my personal page. I was trying to convey that some (currently small, as most don't have any idea at all) subset of contributors are having problems with ODbL move; not that *everyone* involved with legal issues have to feel the same ("my") way. I've reworded that paragraph now to make it clearer what exactly I'm talking about; I hope it no longer feels insulting (again, sorry for that, that was not intention at all. In my defense, English is not my primary language, and sometimes I miss finer nuances and implications of specific wordings)

Valent: ok, radim na tome. Malo je obilnije da bi bilo razumljivije laicima, pa ce trebati koji dan.