@JJIglesias the retention rate has always been low to very low (with some small differences), and youthmappers are no different than other similar sources. The relevant number of concern (new mapper influx) isn’t affected by this in any case, any effect on “large mapper” growth will be longer term, if there is any at all.

I think you might have been overthinking the mobile editor aspect a bit. I can only speak for Vespucci, but the fast thing to do is to add address nodes where the door is on the building outline, the app will automatically add an entrance tag.

Typically given a half regular numbering scheme you will not have to type anything as the number will be predicted. If you need to fix up building outlines later on, having the entrance node already doesn’t really get in the way.

Das osm_ids Objekt ist optional, man kann aktuell aber keine solchen Todos ohne Objektbezug in Vespucci erstellen (normale Notes gehen natürlich auch), aber das Laden (und Abspeichern) geht.

Speichert man eine halb abgearbeitete Todoliste ab, dann sollten die abgearbeiteten Einträge “state”=”CLOSED” haben. Workflow: das Problem ist natürlich, dass es am besten wäre wenn man existierende OSM-Objekte referenziert, das geht im Augenblick nicht mit Features in GeoJSON (da es dort keine id geben muss die man als Referenz verwenden kann.

Muss ich mir mal überlegen ob man was in der Art unterstützen könnte.

Noch als Nachtrag das Dateiformat http://vespucci.io/tutorials/todos/

Zuerst einmal: http://vespucci.io/help/en/19.0.0%20Release%20notes/#support-for-external-measurement-apps

Zum Workflow: wenn ich richtig verstehe generierst du über mehrere Schritte hinweg modifizierte OSM Daten die du dann in Vespucci lädst und vor Ort anpasst. Das scheint mir etwas umständlich, ich hätte eher aus den Geoportal Daten Geojson generiert mit den gewünschten Attributen und die Geojson Schicht dann direkt in Vespucci gebraucht um entweder die Tags upzudaten, oder neue Objekte zu erstellen. Das braucht maximal 2-3 Klicks pro Objekt.

Alternativ oder zusätzlich, kannst du auch einfach eine Todo Liste erstellen, siehe http://vespucci.io/help/en/18.0.0%20Release%20notes/#improved-osmose-and-todo-support Das Format könnte vermutlich auch von deinem Skript erstellt werden, wenn du Interesse hast, bitte melden.

The long tail of values in essentially any “numeric” tag in OSM will contain malformed data that has to be dealt with. How exactly could range from trying to parse them to extract some useful information, to simply ignoring them. What you can’t do is simply assume they will contain well formatted numbers.

We had a discussion back in October in the Swiss community with respect to best practices of mapping individual chargers vs. the area of larger charging facilities. (and tagging the area). See http://lists.openstreetmap.ch/pipermail/talk-ch/2022-October/011686.html It would be nice if we could get general agreement on how to handle detailed vs. rough mapping without losing information.

Some of the issues you have seen in numeric values are “normal” and not specific to charging station tagging, any use will have to normalize these.

PS: I need to remember that we need a plug-in value for authentication, while this is only common right now for Teslas it is likely to become much more common.

Apologies, but from reading the post it isn’t clear if this is official product marketing, aka you announcing this as an Meta employee (or employee of an other related organisation), or something else. I believe a clarification would be in order.

@tg4567 and @jonsger this is already covered in the blog post.

@DeBigC sounds kind of normal and roughly in line with the influx of new mappers we see here osm.org/user/SimonPoole/diary/397810

One time editors have always been common as long as I’ve been involved in OSM and “larger mappers” that is contributors that have turned mapping in to their hobby are rare and I wouldn’t really expect that to change.

The dynamics are naturally going to be different in developing countries.

@pnorman thanks for the numbers, I think they at least indicate that there was something going on with the HOT numbers.

Naturally contributions tend to lag conversion/signup by a fair bit, but on the other hand if we assume that most HOT signups happen immediately at events at which the signups start mapping, those numbers would actually align with the periods we are looking at.

@stevea the point was not that residential areas can’t have names, the question was about using the brand of a development company to nmae them.

From a world wide point of view there may be legal issues.

Guess what mvexels audience here is.

Unluckily it probably has to be said: check your local legislation before using a dash cam in general and specifically for mapillary.

Street name format are not consistent in OSM. 

Best see if you can contact other mappers in the country and get agreement on how to handle them. Potentially it is also a good idea to get input from the Nominatim maintainers.

@dolbr historically financials has always been the largest non-delegated board task (with the exception of actual accounting), because there are a number of things in that space that are difficult to hand off to non-staff / non-officers. Growth is just making it more and more painful (and the specifics of the OSMF naturally don’t make it easier either).

No one disagrees with your opinion that OSMF should be more governance oriented and less of a working board.

Well for starters the board as a whole seems to disagree with that. The last three boards have been substantially more hands on than previous boards going back a decade, not to mention to the communications that refocused from the working group to the board activities over the same time frame.

The map editing software doesn’t have a diary function.

The OSM website has (among other things), a diary function and a way of starting a number of different editing apps on the area that you happen to be viewing.

@mvexel prior to 0.6 there was no grouping of edits. The objects versions had timestamps just as they had now, but as @mmd points out that is all independent of the concept of an “upload” which is not reflected (including in 0.6) in the data model.

It is just an artifact from when changesets were introduced in March 2009 and they were automatically created from the existing edits at the time.

With other words you are being sentimental about something you never actually did, that is create a changeset in 2007.