Diary Comments added by escada
I wonder why you consider the sidewalks as landuse=residential (and the road not).
If you split up the landuse, it should end at the building. The sidewalks and roads belong to a “landuse=road” which is mapped as area:highway.
Considering the border of landuse=residential as kerb is something I haven’t heard before.
What many mappers do is indeed to have 1 landuse polygon going over roads if the usage stays the same, but let the landuse end outside the road/sidewalk/road side when it is different on both sides of the road. I only know a handful of people that go in more detail and always let the landuse end at the road side. (not the kerb).
Welche navi ? Garmin ? Android app ?
To add to Warin61’s comment:
There are some iPhone apps you can use to add data while you are “in the field”.
I do not have an iPhone myself, but I heard good comments for the following apps:
More apps for iOS can also be found on the wiki
I guess it is indeed fascinating to be able to map totally different objects on 2 different continents.
The great thing about being editor of Mapper of the Month is that via, via you get to know more and more great mappers. I got your name from David Corley awhile back. I had contacted David for an interview 2 years after seeing his kind responses on the Irish mailing list.
Via your interview (and the retweets and likes on Twitter) I got to know other mappers in Africa that maybe one day I will contact for an interview.
Enough about me, keep up the great mapping work !
Sorry, I missed the irony, but I know that some people have disputes with some members of the DWG regarding reverts and possibly blocks as well. Without further context it is hard to know whether you are doing this as a neutral observer or as someone taking sides with the blocked person.
Indeed, I’m not interested in who did the block, but in who was blocked and who(*) requested the block. I assume the DWG is not handling on their own, but that they are processing requests from the community to block people. So perhaps the people that block a lot just process more external requests than the others.
Some people in the above list only served the DWG for a short period (and are no longer part of it), so it is normal they placed less blocks than others.
I like the comment you gave to explain the spikes on the “Mean Block Duration”, I’m missing that kind of additional information on the last two graphs, that’s why they are “useless”. They just give hard numbers without context, the numbers are not explained.
(*) not the actual person, but was it a group consensus, was it 1 person asking it, that kind of stuff.
Since your last two graphs do not take into account the reason for blocking users, they are useless imho. Maybe woodpeck deals with mappers that destroy a lot of data or in a large area.
I see this as a blame game for the DWG, I think you should have focussed on the reason why people get blocked. But as you wrote “Just in case there are some troubles with the DWG (I am looking into it for a friend)”, your investigation seems biased. If you would have revealed the reason why your friend in blocked (did she/he import from copyrighted sources, did she/he vandalise the work of others ?, did she/he add advertisements ?), I might have an idea why you are doing this research.
Perhaps SEO-spam ? A SEO company can make a lot of different accounts, one for each business they want to “add”. See e.g. this discussion on the Australian mailing list
Those people might not be interested in learning how one properly add a business with advertising.
Do you know about the problems of the current state of the AI applied by Facebook where many line-like features were recognized as road (https://forum.openstreetmap.org/viewtopic.php?pid=679826#p679826).
I think armchair mapping is still giving better result at this moment.
So probably in the future AI can be better than humans, but we are not there yet.
In a coordinated effort a couple of years ago (started in Germany, although I had already mapped tens of exits in Belgium before), people started mapping turn:lanes. This included exit lanes.
AFAIK, in Belgium, The Netherlands, Germany (and possible other countries), people opted for 1 or 3 or Paul Johnson’s style (not a huge difference between the 3). Never 2. A “lane is not a separate way”.
So I hope that everybody who thinks 2 is better because it is more appealing, or better for navigation (which it is not – see my comment above), will appreciate the above effort and will keep a consistent way of mapping by not using option 2.
@Andy Allen: to be honest, I’ve never heard that from OsmAnd, nor MagicEarth.
One can also add placement=transition on that short segment. (which is perhaps ignored by all satnav apps)
People have been mapping those things based on https://wiki.openstreetmap.org/wiki/Lanes.
That is not option 2 I think.
Read with great interest and bookmarked for future reference. Thanks for your hard work on Nominatim
AFAIK the German community never placed the junction at the beginning of the lane, at least when people followed the instructions given for the week-assignment on turn:lanes 2 years ago.
The Belgian and Dutch community followed the same rules. I assume the other neighbouring countries did the same.
So the option proposed by Omnific is not how it is done in a certain part of the community.
The difference between theoretical gore and physical gore is harder to see. I guess the junction is typically placed somewhere between those 2 extremes.
When I compare the instructions of e.g. OsmAnd or Magic Earth with the distance signs to the exit or the spoken instructions given by non-OSM navigation systems, the place seems to match.
Hard to tell given the precision of a GPS while you drive around 90km/h
As imagico said, please take a look how the exits are mapped. Are there differences between the different countries ? I think that you should be better informed about how things are done around the world before enforcing your rules upon the rest of the community. Before making a decision I would love to see numbers per country.
I hope you will stop the process of mapping to your rules until there is more clarity.
The German community discussed this topic last June: https://forum.openstreetmap.org/viewtopic.php?id=58116
I have to re-read the thread to remember whether there was any consensus.
OpenStreetMap is about the data to create maps, not about applications. I firmly believe we should focus on data (and perhaps tools to map and to verify the data), but should stay away from apps for end users. There are so many applications of maps, and as Mariàn wrote, there are already plenty of apps out there using OSM data.
There is no reason to compete with those app developers.
I wonder how such a CoC would work on e.g. a Telegram group with the name “OpenStreetMap”. How can you enforce a CoC on a platform that is not under control of the OSMF, but is clearly related to the OSM community ?
Do you see this as a problem ?
Main drawbacks of OsmAnd for editing for me are:
@cm8: please tell me why “diameter” is better than “fire_hydrant:diameter”. I have not heard a single argument that convinces me. What is the quirk, misnomer or bad use of namespace in this case? Is it really a fix or improvement ? Why do we need it to be called diameter ? Why is it better for a mapper to use one over the other.
Why do I have to learn a new mapping scheme ? Is that taking care of mappers ?
@Viking81, as Nakaner wrote, it is not only the hundreds of mappers that have to go through the pain of remapping there stuff, it is also all data consumers that have to add code to use “pressure” besides “fire_hydrant:pressure”. This means creating issue cases, planning, them, developing them, testing them, releasing them and maintaining them without any improvement for the end consumer. This is something each development team hates (I know, I do software development).
You want to change fire_hydrant:pressure to pressure and look for 10 other mappers that agree (and hopefully no one objects). There is no guarantee at all that there won’t be a group of 10 other mappers that will do the opposite within a couple of months or years. Just renaming tags is such a waste of time & resources.
I wish OSM had something similar to Wikidata. Wikidata abstracts the tags away. The have P. Then you can name & describe it however you want, you can add synonyms, translations without any problem. For the all data consumers it remains the same P
I think people assign too much value to how a tag is written. For me there is no difference between pressure and fire_hydrant:pressure. It’s the same. I would happily use one or the other, but there is no reason to replace one with the other.
Another drawback is that you just make the database bigger with another version that is just replacing a tag with a synonym. Whoever is using a template in an editor will hardly notice what the actual tag is, so why would they find “pressure” better ?
BTW, I didn’t vote, because the voting process is no longer working. There are too many different opinions that do not participate in the discussion, and only vote. Or the voting group is not represenative for the community as a whole. I don’t have a solution for those problems. I just vote by using tags (or using the tags my editor gives me).
p.s. Luckily the proposer of the new fire hydrant tagging scheme mapped 1095 hydrants so far. At least s/he would feel to remapping pain as well :-/
@Warin61, do you seriously want me to spend time to retag all 1978 fire hydrants I mapped  in the past, just because 10 mappers decide that fire_hydrant:diameter is not hip anymore and has to be replaced with diameter ?
Do you think I have nothing better to do ? I would rather map another 1978 fire hydrants, than retag the ones I mapped. I noticed you mapped 6 fire hydrants in Sydney, that is a totally different scale
Of course I could use Overpass + Level0 to do the retagging in a few minutes, but still it is a waste of time IMHO.
So I totally agree with Nakaner’s “Avoid changing heavily used tags”.
 http://overpass-turbo.eu/s/sjh (by the way all surveyed in case you wonder)