@Stalfur I think you will find major parts of Europe disagree with you.

In any case as I’ve pointed out differing numbering schemes etc, can be recorded in level:ref

@joost note that my statement that a large number of the new mappers in the US are SEO spammers is -not- based on the different workday - weekend patterns. It is based simply on the findings of investigating the large increase in incoming new mappers in the states starting end of 2016, which are in the 1000s of SEO spam accounts. If these were filtered out (many different ways possible) you would find the US even more overrepresented as it is.

I’m sure the numbers are accurate for what they are actually measuring (the OS versions of the devices installing via/accessing the play store). That does not mean that they are an accurate measure or proxy for the OS versions of the devices actually in use in one form or the other, which tends to be implied.

The sub 4.4 (non inclusive of 4.4 and mid 2018) portion of installs via the play store is 3% for Vespucci. But I wouldn’t expect most such device owners to install via the play store in the first place (more likely from F-Droid, from our repo, own builds etc).

We don’t have any numbers from any of the other ways of installing and except if we would start to record OS version in changeset tags, which I wouldn’t consider a good idea, we are simply never going to know the details (outside of OS version specific regressions, which has happened now and then :-/).

You are falling for Google marketing.

There is already a level:ref tag defined in SIT that can be added to the level outline for level names or very different numbering.

PS S3DB doesn’t have a level tag and when the concept of levels is used it is as a proxy for the height of the element.

Consider that you have OSM data in some kind of data store and need to determine which languages are supported for your hotel example.

PS: as to the list becoming “long”, all modern editor UIs allow you to select from a list regardless of the underlying data representation.

“schreiben aber lieber auf Baseldytsch” es gibt keine allgemein anerkannte Schriftform des Schweizerdeutschen, was ja Teil des Problems ist.

Das Problem ist eher, dass name:gsw so unspezifisch ist (nur schon in der Schweiz), dass es eigentlich sinnlos ist es in der Form überhaupt zu verwenden.

Im Gegensatz aber zum Gebrauch in FR und DE ist Schweizerdeutsch nicht am aussterben und dass ist vermutlich auch der Grund wieso sich die ISO (und nicht nur die JOSM Entwickler) hauptsächlich daran bei der Auswahl des Kürzels und des Namens gedacht haben.

Es gibt aber keinen Grund wieso wir nicht gsw_CH, gsw_FR, und gsw_DE verwenden könnten, auch wenn das für die Schweiz immer noch beliebig unscharf wäre.

All projects that are in the OpenStreetMap organisation on transifex can (and do share for the majority) translations. That means you can auto-fill exact matches from other projects translations.

For historic reasons the OSM website is translated somewhere else and that would be difficult to change, anything else could likely easily move to transifex.

PS: I’m not a particular transifex fan, but it works well enough for our purposes and avoids us having to run yet another service ourselves.

Sorry but you still haven’t explained -where- you have the issue, in transifex? (can’t reproduce that there), in id (assuming that you are referring to the translations of iD presets) ? or somewhere else?

Could you explain this a bit better? Perhaps with an example?

Thanks

I’ve discussed this with imagico before.

IMHO

• while it can argued that having a non-github like issue tracker would remove the real or imagined bias towards software developers, it is however unlikely that the devs would want to give up the tight integration of the issue tracker with git that github-like systems provide. Having two -different- public issue tracker systems (plus trac for JOSM and itrs internally) would be a step back from what we do today,
• in the end gitlab has exactly the same issues as github and what we would want is something thta allows single sign on with osm,org. That would for example be possible with a self-hosted instance of gitea.

@imagico as you probably can guess, I completely realize the difficulty of selecting “good” imagery (though it might be getting easier over time to do automatically).

On the other hand there -would- be significant value in having a global Sentinel derived layer even if not continuously updated (but at least not totally stale), given that it is afaik currently the open imagery source with the highest nominal resolution. Naturally if the pain is large enough (say China) the imagery can already be used now, but doing so is rather convoluted and likely outside the means of out typical mapper.

I don’t think funding would be a significant hurdle as the benefits are fairly clear, so the WMF and others could likely be convinced that the project makes sense (obviously other free imagery sources could be added where available, but that would be an undertaking with a far larger scope.

You might need be a bit more explicit about what, on topic (current aerial imagery), point there is to lean from Here.

@philippec what exactly did you wanted to convey with the link to a competing company?

@farhadGull as a clarification: no data or imagery from Here is a legit source for OSM editing.

Then: a year from now likely some other imagery provider will likely have more up to date imagery of that location and then somebody else and so. The providers of imagery mosaics update their imagery relatively seldom, as it costs money (in more than one way) and tend to concentrate on regions of the globe where it makes economic sense for them (particularly with respect to higher resolution imagery).

@imagico ever had any thoughts about generating a regularly (automaic updated) global Sentinel-2 layer for OSM use?

Note I wasn’t proposing to automatically delete anything, but simply having less qualms about stuff that is clearly nonsense (and could be included say in a maproulette task or similar for relatively fast review).

I was thinking more of removing stuff that is silly: as in doesn’t have any, even residual, value, like the masses of residentials in rural Texas where there is literally nothing. For example any untouched residential without a name should a deletion candidate (that could likely be further refined by excluding counties that had already been part ot the TIGER improvement program).

While I would agree with iandees that there is lots of “good” TIGER (aka geometry and topology more or less correct), even good TIGER didn’t have speed limits, turn restrictions, lane tags and so on, so we should expect even good TIGER to get touched at some point in time.

The other side of the story is that we know that a fair bit of the data is nonsense, unluckily the hoarding disorder that often manifests itself around imports is stopping us from taking the sane actions to clean up those bits.

Given that you are making good progress (as expected :-)).

When you are done (soon), it might be a good idea to attack https://github.com/openstreetmap/iD/issues/1502