In OSM, everything is made by simple people. If someone wants to add/update wikipedia/wikidata tag, one does that. So, there is no update period or something. If you are aware of missing information, you can add it by yourself - there is no need to wait for somebody to do that.

The second rule doesn’t actually fit any method, based on neural networks. Simply because neural networks are trained on certain datasets and they can only make decisions based on that training, but nobody can explain exactly which criteria they use to make decisions. So, in case of OSM, only one thing is really required and important - ability to revert any specific changes if the result of those changes seems harmful to data integrity.

@migurski,

I’d leave it to you since you love automation and so on: analyze a number of changesets in any area of Africa or Central America (Haiti, for example) within HOT/missing maps operation and outside of it. The fact, that HOT/missing maps operation is required for a certain area serves as the best evidence that there are not enough local mappers.

You can call for another operation and update it, but since HOT is emergency-related, you can’t just do it whenever you like (or you have to make up a reason for it). Between those operations, there are virtually zero edits. When were the last operation in Haiti and when - the one before it? Krymsk (the small town in Russia, where massive flood happened in 2012) is another example - Russian mappers were mobilized to map it, they did it really well, then it was abandoned since no more emergency situations occurred there. Keeping things up to date means being able to react to real-world changes more or less immediately, not working in a mapping raid style every time when flood, earthquake or something else happens. Missing Maps project is a bit different, but it has the same intermittent raid-style impact by its nature.

Do I have to explain further? I guess, no. Feel free to ignore this logic like you did before.

I’m perfectly aware, that it feels more important when you are not just editing some map, but also saving lives or something. Probably, it is possible to attract more people with this motivation. But it is impossible to call any region (especially, outside the not-so-developed countries) “an area of emergency”, which makes this approach limited by design. I’m not trying to say that HOT is bad or something, but it’s only better than nothing when it comes to a situation of emergency.

I’m don’t want to defend the idea of “robots versus mappers”, however, there is something in direction of wider usage of more advanced technologies like automated imagery classification. And AI (or classic methods of photogrammetry) can definitely help here, at least, in the aspect of filling huge gaps in barely populated areas. It is the different issue than one Michal Migurski is trying to explain, but there is strong default prejudice (echoing in this diary entry too) against automatically generated data (even in cases when it’s not about any kind of direct import).

It is quite funny that crisis mapping was mentioned by Michal as a good way, while it is a proven fact, that any local map, improved by the whole bunch of volunteers, becomes outdated immediately after HOT operation is formally finished. Exactly because local mappers, who can keep it more or less up to date, do not exist. So, after reading a statement like that, I see no credibility in any other words of its author, since it’s not even a fallacy or demagoguery (something pretending to be true), it’s just false, unreasonable, illogical.

Personally, I wouldn’t say that street view is a lifesaver. At least because the amount of important data we can extract from it is in huge disproportion with its cost. I mean, having an all-weather rig of six high-resolution cameras mounted on a vehicle to read street names, really? Leave aside that in certain types of populated areas it doesn’t help at all, you just can’t see anything like that from a roadway. So, that’s a waste of money anyway.

There is a lot of space for new methods and new technologies. Some craft mapper attitude (like certain Luddism) can get in the way of it. But if mappers are really open to learning new, more effective technologies, it could really bring the situation to the new level. And yes, to keep data up to date we need more information. But it shouldn’t be a pile of trash to sort in search of a couple of valuable grains (it’s about maps.me contribution and “community extension”) - it’s about, for example, automated track collection, which does not depend on user’s skill.

@joost schouppe,

I’m very sorry that I have to point on that, but this is a kind of demagoguery: > It is just as obvious that maps.me introduces a whole lot of new problems, as that it is probably the biggest community expansion thing to happen recently.

It can’t be a “community expansion” since those people, who adding “Mom’s house” have no idea they are a part of some community (and you’ve just admitted that in the second comment). In Russian, this situation is called “you marrying them without their presence”.

So, how about to stop using obviously false statements to support your point (which is reasonable in general and it doesn’t really need any demagogic arguments in its support)?

First of all, you shouldn’t really care about how it’s rendered on a map since everything is okay with a data. Standard style tries to look good, but it’s still just a technical map, not trying to pretend like it’s a political, topographical or some other specific type of map.

relation/136712#map=11/44.9706/-93.2616 - Minneapolis relation/136612#map=11/44.9397/-93.1061 - Saint Paul

As you can see, both boundaries have similar border type and administrative level. But what’s different, can you guess? It’s a size (I mean, width).

“My Diary” is a kind of blog, intended for sharing all sorts of information with other OSM project members. All diary entries are visible to everybody on this page, just like a news feed. There is no search, categorization, tags and other things to present any information in any kind of systematic form.

If you log into OSM Wiki here osm.wiki/ , your user page will be like this osm.wiki/User:DougPeterson . And then, you can create any page there to keep important data, not as a blog, but as a documentation, since Wiki is for documentation. To create a page, you need to log in first, then - go to an address you want, like osm.wiki/User:DougPeterson/Imagery_shifts and click “Create” or “Create Source” next to the search bar in the top right corner. This page will be searchable, you can track changes and history. Pages you’ve created or edited will be listed here: osm.wiki/Special:Contributions/DougPeterson

Using my “follow the error” principle of OSM Wiki improvement, I’ve added several notes to Using Imagery article.

Just in case, wouldn’t it be more convenient to keep information like that on a personal OSM Wiki page?

@dieterdreist,

Thank you. To summarize that, I’d say, that current description of this tag is, at the same time, too broad and too narrow. Too broad to reflect any specific service, since midwife provides very different service in different countries. Different up to no similarity at all and this tag will be used for all of them, despite the definition. Too narrow, since it restricts the definition to a random (on a global scale) subset of midwife services.

@Omnific,

Maps.me is a good tool in hands of an experienced mapper like you or any other person. And exactly by this reason, it’s awful in hands of any person who has no idea about OSM: maps.me editor was designed by OSM geeks, who can barely imagine (or who don’t care about it) what could be done when such clueless person uses it.

@SomeoneElse,

It could be a bad choice of key name, but it was approved and it actually doesn’t really matter, how to call this key. It’s a UK-specific thing, so it would better stay in a separate dedicated key.

Actually, Wiki doesn’t declare https://wiki.openstreetmap.org/wiki/Tag:crossing=zebra as an obsolete tag - it only calls it “UK shortcut”, while current tagging scheme encourages usage of crossing_ref= to indicate UK-specific properties such as zebra, tiger, and so on (which makes perfect sense to do).

However, the coexistence of shortcuts and detailed tagging scheme creates an ambiguity because, in other countries, where “zebra” is only a variant of road marking, shortcut tag https://wiki.openstreetmap.org/wiki/Tag:crossing=zebra usually does not make any sense. In the UK, this shortcut doesn’t stand for just a type of road marking - it’s a pedestrian-only crossing without a traffic light, marked with zebra stripe pattern. So, when someone outside the UK uses https://wiki.openstreetmap.org/wiki/Tag:crossing=zebra just because it’s among the other presets of the iD editor, this mapper likely adds incorrect information since zebra-marked crossing is not necessarily uncontrolled.

Yes, it’s always possible to say, that mappers should be responsible for that. But since this thing is both country-specific and obviously provoking wrong tagging, it makes perfect sense to get rid of this ambiguity in presets in favor of the more detailed current scheme. It also would help to process data, since UK-specific crossing_ref= tag can be just completely disregarded outside the UK (because it doesn’t carry any valuable information), while currently, anyone who wants to find all uncontrolled crossings outside the UK, has to use some sort of telepathy to guess, if this specific crossing was actually marked according to UK-specific meaning of https://wiki.openstreetmap.org/wiki/Tag:crossing=zebra or it’s just some amateur tagged it with iD preset.

Keeping this shortcut there seems like a disregard of international nature of the OSM project in favor of nation-specific tradition. Doesn’t sound good for me.

It doesn’t seem like correct practice to use junctions as a reference because ramps located above the ground are usually shifted on satellite imagery due to parallax, caused by off-nadir view angle. Aligning images of ramps to tracks makes only those ramps positioned correctly - everything on the ground level gets proportionally shifted. Only ground-level features should be used for imagery alignment in case of off-nadir view angle.

I had an idea that Mapbox employees are a bit more professional in the aspects of imagery handling and basics of photogrammetry (actually, this is “Trigonometry 101” problem).

@woodpeck,

You have to keep in mind, that OSM data isn’t something used solely for navigation. Therefore, assumptions like that (more common for older, primitive tagging schemes and a bit less common for some newer ones) are quite harmful in this case. So, yes, it makes perfect sense to think at least one step forward before proposing same old-style tagging scheme which can’t actually describe anything without using (usually, non-existent) external references.

@schleuss, Using Google Street View, you can see these dots are actually a kind of cones, similar to traffic cones, but they look brown, not orange. Have no idea what it is.

I can confirm that - rusty full-scale airplane model is a firefighting training range, and these are not boards surrounding it - these are hoses drying in the sun (I’ve never seen a 25 meters long board, flexible enough to be bent so freely). Worm-shaped dot figures in the retention reservoir on the other side of the road to the west look way more intriguing.

There is certain controversy about translation, transcription and transliteration in OSM.

First of all, name:code= keys are intended for existing names only, which means, that certain place in, say, Nepal, known only by name in Nepali, but not known by any English name, should not be tagged with name:en=, filled with Nepali→English transcription or transliteration. Renderers or data pre-processors can do automated transliteration if it’s required. Only a few places in the world actually have names in foreign languages, other names are usually just transliterated/transcripted as needed.

However, missing national names should be added (preferably, by native speakers), where places have name:en= only or name= in English (which is totally wrong).

@Warin,

Let me politely dismiss some of your arguments, starting from the end. :)

Speed limits are just several conditions and numbers, so, even if we don’t have any structure to keep these numbers in OSM, it’s a question of navigator/router settings. And these numbers and conditions are not that diverse. I mean, there is no country, where speed limit depends on a Moon phase. Plus, it’s quite easy to obtain existing conditions from third-party sources, at least, for more or less developed countries.

Farm buildings are not an amenity, therefore, a general description is way more acceptable than in a case of some place, where goods being sold or services being provided.

Highways are classified as “secondary”, “primary” and so on according to its role in a road network, regardless of any physical properties. And there are special tags for surface and other properties. It is wrong to assume, that highway classification has any defaults for physical properties, even if there is a strong correlation within certain countries.

And I already explained once, why “classification” of stores does not make any sense in a global scale, while local people can be totally okay with it.

But the case of midwife office is way worse even comparing to a supermarket because for true supermarkets only certain details would be different (if it’s not a tiny store, called “supermarket” for whatever reason, as it happens sometimes in Russia). Psychological support service and a place, where a woman can give birth or even have a Cesarean are more different than two huge stores with alcohol department and without it, aren’t they?

@SomeoneElse,

Indeed, https://wiki.openstreetmap.org/wiki/Tag:wood=deciduous should be re-tagged into https://wiki.openstreetmap.org/wiki/Tag:leaf_cylcle=deciduous without any automatic global assumptions about leaf_type.

But if there were people who can’t read, it’s a separate issue from changing old scheme into a new one. They are equally capable of adding any other wrong tags.

My point here is that there were traditional arguments like “new scheme is too complicated”, “nobody will use that”, and so on.