@Magick93 there is no local imagery available for the Valais. What is more problematic that essentially all of the global mosaics have issues with very mountainous regions so that even non-cloudy bits tend to not work so well.

Clifford I assume the ~10% difference between total new mappers and messages are mainly SEO accounts? That would line up with what I saw checking new signups over all of the states for a couple of weeks.

I wouldn’t be too concerned about some slowdown in growth rates, we’ve had that on and off the whole time. We actually had the same effect globally in 2019, a small part of it was the tail of the large maps.me influx and to be expected, a further part would seem to be HOT et al loosing some of their attraction.

I sent 1’280 mails vs 1’383 in 2018 so again mirroring the slowdown (no actual SEO spammers in that though), very comparable base populations btw.

Can you explain how a user of the plugin is shown the relevant Facebook terms of use including the privacy relevant bits? I’ve installed the plugin and even with a lot of hunting I wasn’t able to find any relevant information (naturally the terms should be shown on install in any case, but cutting you some slack there).

And, would be totally inappropriate to inquire, who actually financed Kaart the development of the plugin?

Early OSM had nearly no buildings and, given that other things had been mapped, works perfectly well without them (there are actually certain operators of OSM based services that throw them away as their first step of processing). Mapping a hospital as a node with corresponding tags looses no important functionality, just some eye candy.

Why we got to the point in which lots of new contributors and even in the mean time seasoned ones believe that buildings are essentially the first thing you should spend time after adding motorways, is a long and dreary story. And yes I mapped lots and lots of buildings, but fully aware that this is mainly just for looks.

Could please everybody stop feeding the troll?

Maxar has neither indicated any specific region or technical issues as the reason for their issues, and further it is clear that proxying/caching would not solve the issues of bad actors overusing services (see the problems we have with the cache network for the standard style tiles).

And the other part of the discussion https://github.com/MarcusWolschon/osmeditor4android/issues/775

@Stereo we have over a decade with “per editor app” keys (bing) and that has worked reasonably well (at least for those that have bothered to get their own keys).

Longer term probably per user keys are the way to go. Writing a small web app that gets an api key and stores it in the user prefs shouldn’t be a big issue allowing all editors to access it (I’m not holding my breath on that actually happening though).

See https://github.com/osmlab/editor-layer-index/pull/548

@adamant1 you yourself should perhaps be a bit more careful, I haven’t seen anything in woodpecks post that would even remotely add up to slander.

@Adamant1 for accuracies sake, neither of the current developers had anything to do with the creation of iD as a concept nor with the couple of initial releases of the product. We don’t even know if the current vision for iD even continues to include OSM.

On more fundamental issue: there is no roadmap for vector tiles because there is no clear strategy on what services the OSMF should be providing and for which audience and how these should be differentiated (or not) from commercial offerings.

Once that is laid down, -then- it makes sense to determine how technically we can provide such services if they are a required by the overall strategy.

This is no different for vector tiles that it is for say, geocoding.

Unluckily the board has refused for the larger part of a decade to even acknowledge that the question exists.

Just to nitpick: Waze is essentially the same age as OSM and was mostly successful due to a completely different focus. Naturally people tend to lump everything loosely associated with “maps” in to the same pile, but no, there is no reason to consider Waze as a role model for OSM.

Just as a note: the (legal) privacy concerns are no different with wikimedia commons than with any other 3rd party, in particular any other US based 3rd party, that we asking our contributors to involuntarily submit their data to.

A proper solution needs to be opt-in and there needs a way to

• record the consent in a fashion that can’t be tampered with
• revoke it if the contributor wishes to

Simon

OK, the custom presets are currently stored in the Vespucci directory together with any presets automatically generated from taginfo (so Vespucci/autopreset and in the autopreset.xml). You can either simply exit vespucci and then delete the autopreset.xml file, or edit the specific preset out of it, to get rid of any unwanted entries.

If you simply want to delete the preset from the most recently used display, simply long press on it.

If you believe it i necessary to add an UI for this, could you pls open a ticket on the Vespucci repo.

Preferences / Presets Select the “Delete” entry from the menu for the preset you want to delete.

See also: http://vespucci.io/help/en/Presets/ (the Presets preference is no longer in the Advanced Preference, but otherwise the content is correct).

OSM geometries already have a timestamp and if the datum used to determine the coordinates was actually WGS84 there wouldn’t be a problem.

The authors point, which doesn’t get across so well, is that in some circumstances we are using sources that are not actually using WGS84 and are offset to it. This makes after the fact correction based on shifts relative to WGS84 difficult.

If you want to do the opposite, you have to store the original date and compute the delta for every single node in the database.

Well we already have the date for every coordinate in the database, including all historic versions.

@SimonPoole Which attribute seems ok for you to store the point accuray?

I would invent something for the tag and use

https://www.topografix.com/GPX/1/1/#type_fixType

dgps to indicated that it is a differential gps generated position.

And what I wanted to mention you can tag the tracks on upload, which likely won’t help very much, Further you could set attributes for the track points that make the situation clearer too https://www.topografix.com/GPX/1/1/#type_wptType but again if that is really useful is a different question.

@StephaneP IMHO currently the differences tend to be so small (with the exception of AUS as mentioned where you probably could detect the difference between a very well traced building from 2007 or so and now), that it is not a real issue. However as we know -when- a node was added, in principle we could apply a cumulative correction at point in time when the difference has become too great (we likely wouldn’t want to do that for other reasons though).

“Professional” surveyors typically don’t have the problem as they are not trying to produce a global, easy to consume geo-dataset, so it is completely OK for them to use whatever the national datum is.

@StephaneP you simply need to convert to WGS84 / re-project tiles and the like, or your GPS tracks (which btw should be in WGS84 too), before using them for tracing adding them to OSM.

Yes, that -does- have the effect that older OSM data will be slightly off compared to a remeasurement of the same object later, but the only country where that would be a significant concern, over the time spans we are currently looking at, is Australia.