A while ago I did have a look at the retention rate in the Polish community, where 75% were welcomed and 25% not (see https://lists.openstreetmap.org/pipermail/welcomewg/2013-March/000022.html and the links back from there). There wasn’t an appreciable difference when I looked between 2 and 3 months after the message was sent (or not).

What I didn’t look at that would have been interesting was contribution quality, and I’ve not gone back to look at longer term retention (anyone can do this - just look at new Polish mappers from that period whose UID was divisble by 4 or not).

When are you going to do the pull request to P2 then (which IIRC still creates them)?

:)

… and for the ones that need a physical survey, https://github.com/SomeoneElseOSM/Notes01 (shameless plug) will let you create a GPX file for a Garmin handheld for local surveying or both notes and fixmes.

Assuming you’re talking about directions, use the website that’s providing the directions (whichever one you’re using), not the simplified interface from osm.org.

… or divide by 8 and multiply by 5 :)

For example, on the ground, you can’t distinguish between administrative entity and settlement.

I think you can. To take an example that I used in this “talk” list post earlier today:

https://lists.openstreetmap.org/pipermail/talk/2016-November/077139.html

“Rossnowlagh” is a settlement. It’s got a hotel and a cafe, and lots of other settlementy stuff. “Rossnowlagh Upper” and “Rossnowlagh Lower” don’t have any of these - in fact when I was there there was nothing to indicate they exist at all on the ground.

Alas, the real world has inconsistency in it, and we have to deal with that. Wikipedia isn’t “a database” it is “lots of different databases, with some coherence between them” OSM’s wiki is notoriously a haven for people who want to tell the real world how to behave rather than describe it, so sometimes you have to take what’s written there with a pinch of salt.

Sure, there will be examples where people have added multiple wikipedia keys by accident, but some may be deliberate, and the way to find out is to ask.

Blindly converting wikipedia entries to wikidata entries would have the same problem as adding wikidata without putting much thought into it (see osm.org/changeset/43749373 for a discussion of some of the issues that can occur there - a wikipedian with the best of intentions but no local knowedge missed things that would be obvious to a local).

Unfortunately, there have been so many “mechanical turk” additions of wikidata links to OSM recently by people unfamiliar with the things that they are linking that it’s effectively devalued the ones that existed previously. That’s sad (and is obviously a completely different issue to what you’re talking about here), but it does mean that “wikidata is not the (only) anwer”.

I’d ask the question “what problem are you trying to solve?”. If it’s not broken, don’t try to fix it.

More importantly each wikipedia community is pretty distinct - I can imagine why a community might want to first link to a particular wikipedia language. Here, for example are the wikipedia pages for the country of Serbia in Serbian and Albanian

https://sr.wikipedia.org/wiki/%D0%A1%D1%80%D0%B1%D0%B8%D1%98%D0%B0

https://sh.wikipedia.org/wiki/Srbija

as you can see, the maps are different - one contains Kosovo, one does not. You can’t assume that all wikipedias agree with each other, and if a wikidata entry was created from just one wikipedia entry, then it’ll naturally reflect the biases of that wikipedia entry.

In Kosovo’s case the wikidata entry https://www.wikidata.org/wiki/Q1246 says “not fully-recognised state in Southeast Europe” (which is correct) and “said to be the same as” “Autonomous Province of Kosovo and Metohija (https://www.wikidata.org/wiki/Q1255)”, which is more problematic, because it doesn’t say “said to be the same as by whom”.

It’s also worth mentioning that I’m also seeing wikidata edits locally (to be clear, not from either of the users mentioned above) that seem to be linking “not quite the same thing” in OSM and wikidata, so care is still needed. As I said on the forum link posted above it’s “something that as a community we’d need to discuss”, and that doesn’t appear to be happenong, smiley face or no smiley face.

Those images are 5Mb each. I’d suggest using much, much smaller ones to avoid using up everyone’s mobile bandwidth!

I have not mis-read your post. I am simply suggesting that if you want spam to be removed that you report it somewhere that the admins (who have the ability to delete spam users) will actually see it. Writing a diary entry about it is likely only slightly more effective than pinning a note to a tree in Hyde Park :)

Rather than writing a diary entry suggesting that someone reports the spam that you find, why not report it yourself?

I suspect a number of these problematical names may have been left by MAPS.ME users who don’t actually realise that they’re updating OSM (the app doesn’t make it clear at all). You can monitor and reverts to that via http://mmwatch.osmz.ru/ (helpfully written by one of the authors of MAPS.ME).

My money’s on “stop valve”…

I suspect we’re some way away from worrying about “maximize efficiencies without destroying the dignity of people”. :)

The only “robot mapping” I’ve seen in OSM so far could easily have been labelled “rubbish mapping” - it seems to involve “try and do some basic edge detection and assume that whatever has been found is a road”.

A better approach would simply to ask all mappers - robot, human, feline, canine, whatever - to simply “be honest” - if you’re a robot, say so, and say who your “handler” is (just like with import accounts). If you’re mapping on behalf of a corporation or an organisation, say that too.

Re the deleted mosque - there was an accidental node drag adjacent to it. Fixed in osm.org/changeset/42544694 and the next changeset. I’ve not mentioned it to the mapper; manoharuss is already in conversation and they’re only 9 edits in.

“zebra” is a type of crossing, it’s not in any sense a “reference”.

The list link should be http://resultmaps.neis-one.org/osm-discussions .

There are a couple of problems with client-side rendering - one obvious one is that you need to have something on the client capable of doing the rendering. I’ve certainly seen examples in the past where even a regular desktop PC wasn’t up to the job of processing the data thrown at it.

The other issue is that (excluding the proprietary options) things that might support a vector rendering don’t seem very mature - OsmAnd is about the nearest I’ve found, and I suspect that producing data for a large area would be a challenge (and updating not an option; you’d need to regenerate). tilemaker is another option, but with major caveats (memory use on generation, lack of an “update” option). osm2vectortiles now has lots of documentation to go with it but as I understand it is geared around one rendering only, which isn’t what I’m looking for.

For completeness there’s a list of MB vector tile clients here but (like similar lists in the OSM wiki) there are no clues about which are “finished” and which were “ideas thrown together in a lunchtime”.

Can you suggest anything obvious that I’m missing here?

@BushmanK retagging from “wood=deciduous” to “leaf_type=broadleaved” (which was what some people were doing) was wrong!

1) I obviously am not ‘tagging for the renderer’. You CAN accuse me of tagging for the LSN, but that is different.

No, it’s the same sort of thing as mapping golf courses as “beach” so that it it renders nicely on OSM’s standard map, or mapping farm tracks in Romania as “unclassified roads”, so that a particular router will use them (both of these these things have happened, BTW!).

An “admin_level=10” tag in England means that there’s a parish council. If there isn’t, while it may be useful to say “there is no parish council here” on a description of a relation describing the “hole”, it doesn’t make sense to have an “admin_level=10” tag.

A quick investigation of nominatim’s results will show that “LSN starts with admin_level=10 BoundaryLine areas” isn’t true either (assuming by “LSN” you mean “Nominatim”; and as I said above, that isn’t the only geocoder for OSM either).

It’d be great to fully understand why e.g. https://github.com/twain47/Nominatim/issues/231 happens, but “making up parish councils” doesn’t actually help fix the problem; in fact, as I mentioned in the Forest Town / Hyson Green example above, Forest Town is still geocoded incorrectly, just differently incorrectly.