@joost schouppe, it seems like somehow you didn’t get what I was trying to say about critical data. Some data users just can not afford using “freely deteriorating” data. Or at least, they need the best existing source of a specific type of data. In some cases (such as time zones, for example), OSM automatically can not be the best existing data source exactly because what you’ve said about freely deteriorating information. I have never said that OSM should be an authority, I’m saying that in cases described above, it doesn’t make sense to keep that kind of data that is, at the same time, critical to users and can not be kept up to date in OSM. And no, we don’t need to have an experimental result when data quality criterion sounds like “up to date or nothing”.

@PlaneMad, are you serious when trying to disprove a tendency with a single case? I hope, not, because it is fallacious reasoning.

I’m not saying that only maps.me users do that (that would be stupid to say). I’m not saying that all of them do that (that is stupid as well). My statement is that they more likely do that, and it is not an empirical knowledge, it’s a fact that originates from the whole situation with an editor that is built into a navigation app. Indeed, newbies more likely using iD or maps.me, but that is just an additional factor that only makes a situation worse.

This is quite explainable, how similar changes remain unnoticed by a local community. Supervision tools such as Who Did It treat all changes equally. Editing a node that refers to a bakery isn’t different from editing a node that refers to a city. So, it’s easily getting lost among the other, more complex edits that should be reviewed. Many data consumers know that, so they just don’t sync their own copy of information about administrative boundaries, country names, cities with OSM automatically.

What I’d really like to read in this diary entry to make the story complete, is how these edits were actually spotted. Just by a naked eye, using some tool that helps to watch maps.me users or some other tool we don’t know about?

Regarding of the last sentence, there is a logical fallacy in it. Indeed, similar edits can easily be done using any OSM editor. However, they were made by maps.me, and it correlates with a common feature of many maps.me users: ignorance. Currently, maps.me user can more likely do something similar to it than anyone else. Workaround for that is simple - do not allow to edit anything related to administrative boundaries with this editor, but developers don’t seem to be concerned - it is way easier to “delegate” all responsibility to experienced users.

@ff5722, If it’s about those people who see adding made-up names as a “mission” to help mythical foreigners, only total support of transcription/transliteration (with respect to user’s native language) can actually remove any base for their actions. But it sounds unrealistic. I think, more unrealistic than stricter order enforcement that doesn’t require writing tons of code.

And it is tagging for the renderer/navigator regardless of correct or incorrect transcription/transliteration, exactly because people who do that want to achieve a certain goal linked to rendering and/or name search.

Your analogy with road network seems to be correct, at least - at a certain level. Exactly because of that, humanitarian mapping made almost exclusively remotely always has an inherently lower quality level. But that’s completely different story.

@Glassman, Keepright does basically the same, doesn’t it?

@Warin61, any area where trees were just cut, can easily be identified. If it was somehow recultivated later, it should be re-tagged then. So, I don’t really see an issue here - it is a verifiable condition of an area. This tag might be a bit rough, however, it doesn’t mean it is not verifiable.

While what you’ve proposed is extremely broad, so it makes this kind of tagging practically unusable - it is impossible to find out, what exactly is there at present moment: young planted trees, stumps or whatever.

Using listgeo and geotifcp utilities from LibGeoTIFF you can dump all metadata from any GeoTIFF file and bring in back from dump after editing. I suppose, these two utilities should be a part of FWTools package http://fwtools.maptools.org/ and OSGeo package https://live.osgeo.org/en/index.html https://trac.osgeo.org/osgeo4w/

There are several WMS services, but messing with parameters makes it unusable anyway.

For Landsat, you could try this https://fromgistors.blogspot.com/p/semi-automatic-classification-plugin.html Common problem with Landsat and Sentinel raw data is that it has 16 bit per sample. So, there is no universal way of dealing with histogram stretch to turn 16 bit to 8. You can always use a very rough approach of clipping about 2% of usable data on both ends, but certain scenes will become completely defective after that (blown highlights, lost bright details). To fiddle with black/white point of each channel you have to actually understand the theory behind it. These two links telling some stuff about that (ImageMagick is for regular pictures, but if you know how to use that, you can deal with Landsat too) http://www.imagemagick.org/Usage/color_mods/#levels http://www.imagemagick.org/Usage/color_mods/#histogram

They, indeed, have a WMS service with some sophisticated custom filtering parameters, but that’s nearly unusable for the purpose of mapping.

Thank you. So, now we have infrared composite from USGS and real color from ESA. That’s pretty cool.

For keeping wooded vegetation up to date, I’d recommend using either Landsat 8 or Sentinel 2 imagery - both sources have worse resolution than WorldView (Bing/Mapbox), but usually, more recent images are available.

And regarding of this particular area - this is an extreme example of tagging for the renderer. I’m referring to:

• huge gaps between parcels that don’t exist in reality;
• usage of landuse=farmland intended for agricultural farms, not tree “farms”, unlike landuse=plant_nursery (if it’s a case here) or landuse=logging;
• wrong usage of boundary=administrative like here https://www.openstreetmap.org/way/459711605 ;
• wrong usage of name= like here https://www.openstreetmap.org/way/433058496 .

Sure, nobody can make you follow the rules, but why don’t you do that by yourself? I have provided some links that might help with that.

@SimonPoole, while I totally support your argument about Microsoft having no obligation to provide anything to us, it is a kind of odd to read your “different wording” in the last sentence. This is an example of fallacious reasoning, to be precise - an appeal to accomplishment. I don’t know, why you’ve used this kind of argument.

This interface might be easier to use for downloading. https://landsatlook.usgs.gov/sentinel2/viewer.html Basically, it’s an easier to use front-end to USGS EarthExplorer.

SNAP is supposed to be easy to use, however, there are numerous reports of an abnormal behavior of this software (I mean, it just doesn’t work, lacks some components and so on).

Another alternative to Mapbox Studio is Nextgis.com that allows you to create web maps and data sources accessible via WMS.

Could you share a link to it? There are so many places where Sentinel 2 data is available for download, so it is hard to keep track on them all.

Everything is totally okay with your edits if you have them saved. However, Standard style map is not the main product of OSM, so you shouldn’t be worrying about this particular product. Regarding of checking your edits, it is better to turn on Data layer on osm.org (blue contours will appear as an overlay) and click on object outlines you are concerned about. There could be many reasons for this situation, from cached images in your browser to delays in rendering queue due to some massive edits elsewhere. Again, a bottom line is: you shouldn’t be worrying.

@Carnildo, that is exactly what makes semicolon-delimited lists harder to work with.

To make “any” or “all” query possible, you either have to:

• perform as many queries as arguments are in the original query and do union/intersection on results;
• preprocess all lists to break them down into separate properties (to look exactly like a single-value syntax).

Delimited lists creating a problem where it doesn’t originally exist. And it is not about an “end user”, it is about data consumers who should not (even if they can) go through the hassle of additional preprocessing just because someone thinks that delimited lists look better. The vast majority of OSM tags are, for example, easily queriable by Overpass in a single query or usable directly for style definitions in MapCSS.

There are only a few exceptions where a complex syntax is unavoidable, like working hours or road lanes. Even a road lanes scheme, having a relatively simple syntax, requires a massive regex processing in its stylesheet (check it out here https://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes#Code ), so it illustrates perfectly, how hard it is to deal with delimited lists in values.

@GRUBERND, there is a very clear difference between a personal preference and a practical advantage.

If it’s about a personal preference, people look for arguments in favor of it and refuse anything that is against it without any logical explanation. If it’s about a practical advantage, there should be a definition of goal and logical comparison of features tested against this goal. However, people can obviously have different views on goals.

Here, I’ve described how I understand the goal of this project, so I’m just testing any existing approach against this - there is no element of a personal preference. While you’ve presented your personal views on who should be handling OSM data and who shouldn’t. You’ve also used “an elegance” as a positive feature - that is totally personal and subjective, leave aside that you haven’t defined a goal to test your statements against.

Both variants you’ve presented do work, but your argument is fallacious since it was demonstrated many times that these two variants work differently and require very different effort for certain tasks.

That brings up another question:

What is easier: to find someone who will sacrifice personal time just to “teach” all these numerous tools to understand semicolon-delimited lists or to finally agree together on using single-value tags like namespace:value=yes since it doesn’t require rewriting any tools?

Since OSM is a volunteering project, the latter should be, in theory, significantly easier. Only in theory, because there are so many people who put their views in front of practical reasons.

@GRUBERND, you sound like a programmer supremacist. But it’s an open project, nobody can prevent you from being one.

By “blunt”, I mean that it is the first (and unfortunately, the last) thing anyone could think of when trying to invent a structure for storing multiple values of the same property. It looks simple at first glance, so people just stop thinking about any other options once they’ve got this idea.

Consensus on any question is impossible without a clear and specific goal definition. But when a goal is defined, a consensus is not required since logic invalidates everything that doesn’t fit that goal.

For example, it seems like your conclusion is based on a view, that it is okay for data consumers to use as much preprocessing as required by data structures (like if these structures have some value to preserve it). This view is very common among those OSM members who are programmers themselves. My view on this aspect is different - I’m not assuming that any data user should have any real programming skills. There are tools providing a higher abstraction level of working with OSM data. These tools can, in the most cases, be used without any true programming skill - these are just querying instruments. But semicolon-delimited structures and any structures that must be parsed before use are more or less incompatible with these tools (or require a preprocessing to use them). And since OSM project has only one product - open spatial data, my idea is that we have to think about the usability of it and avoid adding extra barriers for regular data consumers (as an opposite to large companies or geeks who enjoy writing a code).

Unfortunately, “fine” is not necessarily enough. If there is a better data structure that doesn’t have well-known disadvantages of a semicolon-delimited list, it should be used. A semicolon-delimited list is a very blunt thing, that’s why it is not recommended to use it.