OSM has some more or less clear criteria to decide if a certain information should be added to it or not. However, these criteria only take a nature of it into account. For example, there is no doubt that store operator is verifiable once it is known. Anyone could confirm that using the same source (store nameplate that refers to a company, open business registry, etc.) But will they do that?

I mean, time passes, store changes its owner. How possible it is that someone will update this kind of information? Definitely, less possible than, say, in a case of changed store name. Simply because it is harder to notice that change than to find out all details when you just going to create a POI.

It doesn’t mean that we should avoid adding this kind of information, but it does mean that an ability to keep a certain fraction of information up to date should be taken into consideration before adding it.

This diary entry is inspired by a question I came across today: “How to/ should we add time zone information to OSM?” My own short answer was “no”. A longer answer is: while OSM is not an authority on keeping reliable time zone information (IANA tzdb is), nobody who uses this information for something important will look for it here. At the same time, OSM can not be an authority exactly because of its nature: “anyone can edit it” (and nobody is truly responsible for data quality, unlike with tzdb, where Paul Eggert is an official responsible person).

So, theoretically, time zone information meets general criteria for data that could be added to OSM database, but it just doesn’t make any sense to add it since nobody can guarantee that it will be up to date and more or less accurate/complete. Here, I’d suggest using another OSM principle that usually refers to new tags: “don’t propose (here - don’t add) anything that you aren’t going to use (here - to keep up to date) by yourself”.

This discussion might be truly endless, at least - while OSM has the same level of order enforcement as it currently has. I’m not claiming that I can say something new on this topic, but I just want to keep some arguments in one place.

There is a set of keys intended for language-specific names - name:<language_code>, such as name:en=*, name:fr=* and so on. OSM Wiki documentation explains its purpose quite clear: these tags should contain the existing commonly used names in corresponding languages (see Names article). It is not just a rule that comes out of nowhere. It originates from a core principle: OSM database should contain real factual information and nothing else.

If we take a look at Berlin, Germany with Overpass query, we’ll see that only about 750 nodes, lines, and areas have English names assigned. Usually, these are amenities, where name contains common nouns. Like:

• Botschaft der Republik Indonesien in Berlin (German),
• Embassy of the Republic of Indonesia in Berlin (English),
• Kedutaan Besar Republik Indonesia di Berlin (Indonesian).

… Zobrazit celý záznam

Всем, наверное, известен ключ tourism=. Но не все, очевидно, понимают его смысл точно. Как это часто бывает, дело в смысловой разнице между английским словом tourism и его аналогом в русском языке.

Россияне и жители некоторых стран бывшего СССР привыкли называть этим словом не рекреационный туризм, то есть путешествия налегке, без специального снаряжения, как англичане и американцы, а спортивный туризм: пешие походы, походы на плотах и байдарках, горные походы и даже альпинистские экспедиции. Это местная языковая особенность русского языка и российской (не исключительно, конечно) культуры. Если вы скажете англоговорящему человеку, что вы любите туризм, он никогда не вообразит вас идущим с рюкзаком по тундре или плывущим на плоту по бурной реке. Он представит вас, например, фотографирующим достопримечательности какого-нибудь города или относительно легко доступные природные достопримечательности. Чтобы рассказать о своем увлечении пешими походами, вам придется упомянуть hiking, а о походах и сплаве на плоту - rafting и white water rafting.

Ровно по этой причине, дословный перевод статей Wiki о тегах вроде tourism=attraction лишен смысла. Для англоговорящего, англоязычная статья читается в контексте того, что он знает о смысле слова tourism в родном языке. А для россиянина требуется давать языковедческое или культурологическое объяснение, касающееся точного смысла слов tourism и attraction, чтобы не возникали ситуации, когда кто-то решит, что речь только о парках аттракционов (на самом деле - о достопримечательностях вообще) или о точках интереса для занимающихся спортивным туризмом вроде порогов и перекатов на речках. Это не всегда очевидно (особенно, если просто изучал язык в школе или институте, но не имеешь опыта его реального применения, где вылезают ошибки из примера выше), но это так.

At least some versions of Maps.me editor (for example, MAPS.ME ios 7.0.4) have a bug, that makes it adding a banner_url= key with a value, that contains a shortened link to some pages, related to Maps.me advertising system.

@Zverik (Ilya Zverev, OSMF Board member, who works for Mail.ru/Maps.me) have assured us in his message on the Russian OSM forum, that it’s a known bug and so on. However, nobody knows, how long some users will keep that buggy version and how long these tags will continue to appear.

Using a simple Overpass query and JOSM, I already have removed about two hundred banner_url= keys from objects, recently added or edited by Maps.me users. It doesn’t take much time, but I’m curious - is there a way to automate it and run a cleanup script, say, once per day?

---

Another question is more of a moral kind. Indeed, Maps.me developers (@Zverik himself) have provided a supervision tool for changesets created by Maps.me app. However, it puts the whole burden of supervision on volunteering mappers, while there is no way to reliably detect some anomalies automatically, it is understandable. But this exact case with banner_url= might not have a large impact (about five wrong tags per day), but it is known for a long time and for anyone familiar with a scripting language, it shouldn’t take much time to develop an automated cleanup tool. But nobody of Maps.me developers did that. That doesn’t seem like a responsible manner of working with OSM data. Keeping in mind, how pushy @Zverik (as a moderator) is about being nice and respectful to others on Russian OSM forum, this situation seems like a significant hypocrisy.

As it was recently discovered, Pokemon Go users have found (or, at least, they think they have) that OSM data affects Pokemon “nests” location. Some of them immediately started adding fake map features. Here are several examples: Washington, Indiana, United States, this user osm.org/user/forever2darkness/ , fake residential areas and footways. (Reported to DWG)

… Zobrazit celý záznam

Reading this thread from the Tagging mail list, I’ve noticed several posts describing a problem of lacking governance, leading to endless (even looped) discussions and other negative consequences for the project. I agree with that because if we really want to create, maintain and improve “the best map of the world”, it is counter-effective to rely on natural evolution only. Obviously, it will take too much time.

But I don’t think that governance requires a government as a group of people, like Mark Bradley have proposed in that thread. It could be enough to have a formal guideline or a declaration of goals. For example, we can endlessly argue about semicolon-delimited values, presenting nicely polished pros and cons. But it is impossible to have a consensus if we don’t have a goal or a guideline to test a certain proposal or a statement against it.

Like, how important is it to be able to query any new tag with an Overpass API? Is Overpass API a key part of the OSM infrastructure, or not? Should we care about having a universal meaning of every tag in any country? Should we care about not having a non-verifiable, vague or relative definition of a tag? What about overlapping definitions? Is it important not to force a data consumer to conduct a detailed research on every tag before he’d be able to use it? Is it acceptable to have a scheme that requires a pre-processing with a spatial query?

Without a common goal, any discussion inevitably degrades into a contest of personal views. A special group of people can’t fix it because they also need something to test everything against it. They can, probably, try to replace it with their wisdom, but it doesn’t seem to be a good idea.

Guidelines could be developed as a GitHub-hosted document(s) to be able to actually develop it and to maintain full control over it, instead of using a bit anarchist Wiki style.

… Zobrazit celý záznam

I’m not really complaining here, at least - since I haven’t stumbled across this problem for several years of being a mapper, but from the point of view of having a better tagging system it worth mentioning. And it is not a proposal. So, it’s just an example. Please, be wise and treat it accordingly.

Man-made structures are super-common landscape features, even far away from the populated areas. And we have numerous tags to indicate such features. However, there is the whole class of man-made objects, barely represented in the OSM: various cables.

We have at least three tags for very specific cable structures: barriers made of poles and a cable, intercontinental communication cables, aerial power lines. At the same time, there is no way to indicate that there is a cable hanging somewhere without knowing it’s a power cable or a barrier. Obviously, there are cases, when these tags are used to map for a renderer because someone wanted to indicate that there is a cable no matter what.

Somehow, we’ve managed to get a decent tag for a pipeline. It doesn’t involve any implications about its purpose or any other property - it’s just a pipeline, nothing more. So, if I don’t know what kind of pipeline is this, it is totally acceptable to tag it using man_made=pipeline and location=overground - that’s what I see.

But there is no way to map a cable, hanging between the poles along the street since, without any special knowledge, you can’t tell, if it’s a temporary power cable, communication fiber-optic cable, analog CCTV cable or something else. Sometimes, it is impossible to tell even if you know a lot about this topic. And it usually doesn’t really matter, what does this particular cable serve for. That’s because this kind of data will always be very fragmentary (unless it’s not imported) and outdated due to lack of public interest.

… Zobrazit celý záznam

Спор о том, что же вносить в name=, а что - нет, вечен, как сам проект OSM. Один из тезисов этого спора звучит так: “Раз это написано на вывеске, значит это название”. Давайте разберемся, почему это мнение ошибочно.

Во-первых, напомню, что тег name= предназначен, в первую очередь, для имен собственных. Только “в первую очередь” а не “исключительно” - потому что в некоторых случаях к собственному имени в проекте принято добавлять определяющее слово, например - в случае name= для дорог, куда попадают также слова “улица”, “переулок” и так далее. Почему мы их туда включаем? Потому что названия дорог в русском языке состоят из имени собственного и имени нарицательного (те самые “улица”, “переулок”) и однозначно идентифицировать дорогу можно, в общем случае, только по полному названию. Но правило от этого не перестает действовать: внесения определяющих слов в name= следует избегать, когда это возможно. И это всегда возможно сделать, когда объект полностью описывается тегами. Почему в OSM важно делать именно так? Потому, что OSM - не карта, на которую смотрят глазами, а база данных, на основе которой делаются самые разные продукты, в том числе - карты. Плюс, это международный проект, а только система тегов обеспечивает независимость от языка (конечно, только если она четко определена).

Например, голубятню следует обозначать building=yes man_made=dovecote а не building=yes name=голубятня - такой подход допустим только в Викимапии или Народной карте Яндекса.

В примере выше всё выглядит очевидным, по крайней мере, для большинства участников. Правда, и на голубятне можно встретить иногда табличку, гласящую “Голубиный питомник № такой-то города Москвы - Московский городской клуб голубеводов”, и кого-то, кто воспринимает всё буквально, может потянуть внести что-то из этого в name=.

… Zobrazit celý záznam

Thanks to this diary entry, I just discovered a Wiki page Date namespace which exists there since 2014 as an improperly published proposal. Basically, it is about an introduction of syntax that supposedly gives us the ability to indicate a date range for virtually any key. Proposed syntax looks like this:

<key>:<year>-<year>=<value>
<key>:<date>--<date>=<value>
<key>:<year>-=<value>
<key>:-<year>=<value>

Unfortunately, I haven’t been aware of this until today, but it’s never too late to address it.

First of all, storing a variable value in a form of colon-delimited suffix (or prefix) is not the same as utilizing a namespace because namespace always serves a purpose of grouping. So, this proposal has nothing to do with a namespace.

The second problem is that variable colon-delimited suffix makes data processing awfully redundant. With a proper namespace suffix, it is easy to compare it with a set of known ones within a simple query, while the date “namespace” syntax requires a complex regex (including an ISO 8601 date format pattern) to find all keys containing it. There is no way to “just” select them all because this scheme does not include a qualifier of any kind. Even a bit improved syntax like <key>:daterange<year>-<year>=<value> would allow way simpler preprocessing, but it didn’t happen.

You can read more detailed explanations of these two main issues on Talk:Proposed features/Date namespace page.

I am perfectly aware of at least one web service, where developers have managed to utilize this data salad, but it only means that they had enough free time on their hands. Anyone who wants to argue is welcome to start from writing an Overpass Turbo query, showing the names of Irish counties for a specific date (say, 1920) and showing it here in comments.

Browsing through the issues at Openstreetmap-carto (also known as OSM Standard style or “Mapnik” style) tracker on GitHub, I came across several issues, both open and closed, touching the topic of rendering vertical man-made structures such as poles, masts, and towers.

Communication engineering was my thing for awhile, so it always strikes me when at least two of these terms - mast and tower - are used in an uncertain manner. In one of the discussions on GitHub, the difference between masts and towers was called “philosophical”. Actually, there is no philosophy (at least if you don’t look at wrong and misleading examples in OSM Wiki). Because of that, I’ve added an engineering definition to pages of man_made=tower and man_made=mast both in English and Russian because what is in the first section of those pages makes zero sense and contradicts the basic principles of tagging, because it uses comparative terms such as “bigger” and “smaller” to distinguish between these structures. Tags tower:construction=guyed* are obviously redundant because if you need that, it means that object must be tagged as a mast, not as a tower.

I didn’t want to rewrite the whole “definition” without discussing it, while I don’t really believe that discussion could be successful, so I just added clear definition in case if someone would prefer it. Just for the reference:

Mast is a vertical man-made structure, supported by the guy lines and the anchoring system.

Tower is a vertical free-standing man-made structure, supported by its own foundation only.

(Anyone can find it even in Wikipedia, so it makes me wondering, how ignorant an author of these OSM Wiki articles was to write that.)

… Zobrazit celý záznam

Reading a pretty long discussion of tagging the Holocaust memorial in Berlin, it surprises me, how unclear our Wiki documentation still is. The main controversy there is about (not) using building=* tags for individual parts of the memorial installation. For those, who are not familiar with this memorial, it mainly consists of rectangular monoliths (stelae) of different height, arranged in rows.

It has been mentioned in that discussion, that current convention about a qualifying feature for using building=* is a presence of room inside the structure (I’d add, that it also applies to “parent structure”, since we still have building=entrance in use), so people can come in and stay inside it, and it’s the purpose of this structure.

Sometimes, it could be an extreme case, like building=roof, where we usually have an open space under the roof instead of an isolated space, forming a room. But unfortunately, both Buildings article and Key:building have almost zero information on this particular topic.

I mean, come on, guys, building=* is among the top tags by usage and it is often misused, but there is no more or less clear definition of it in English documentation. In Russian documentation, due to widespread legal nihilism, we have the first paragraph of the RU:Здания (Russian version of Buildings article) that gives a definition of the term “building” for awhile. German article has a bit shorter explanation as well. English version says something about a couple of special cases (houseboats, for example), but gives no general picture, like if it were obvious. No, it is not, especially in OSM, where terms quite often have own special meaning and definition.

Personally, I don’t see any issue with adding something like that to the English article by myself, except I’m obviously not a native English speaker and my English is American (I had an experience of complaints from a couple of Britons regarding of that).

… Zobrazit celý záznam

Currently, we have acceptable (but not ideal) tagging scheme for access restrictions. I’m talking about access=* key and its values. Here, I want to tell something about an application of this scheme in terms of topology, data interpretation, and data architecture.

OSM documentation says that it may be used on nodes, ways, closed ways (use on relations is unspecified, but it’s not prohibited). And many people take that literally. Let’s review some cases.

access=* is often assigned to a node, representing a barrier. Many mappers have an idea that it is way easier to add this tag to a gate, liftgate or another kind of barrier to indicate that access restriction starts here. In such cases, adding access=* to a highway=* is often omitted. A common argument for omitting it is that usually, navigation software starts the route planning from a point, which is publicly accessible. Then, analyzing the road network, it should avoid crossing those points with access=* restriction, if possible, just like it does with user-defined avoidance marks.

But there is a problem with this method. Having a road, divided into two parts by a node with access=* tag, it is impossible to tell, to which half this restriction is applied. This problem has only heuristical solutions, involving extensive analysis of road network. For example, it will be a nice educated guess to say that restricted portion is often a dead-end comprised of lower rank roads, while unrestricted portion likely has a connection with higher rank roads. But this kind of analysis is a problem with no definite depth, and it still doesn’t give you 100% accurate result, which is unacceptable.

… Zobrazit celý záznam

Proposal procedure is not something required to introduce a new tagging scheme, however, some people are brave enough to start it for tags they want to introduce. But then, they are not obligated to follow this procedure, not only in form of being able to abandon a proposal (which is normal - you don’t have to finish it if you don’t want to) but also in form of disregarding the RFC stage.

RFC stands for Request for Comments. Supposedly, it serves to collect feedback and to correct errors found by reviewers. But currently, proposal author is not obligated to take any feedback into account, even in a simple form of replies on a Talk: page (leave aside actual addressing the issues, mentioned there). Since voters are not always reading Talk: page, they could be unaware of those open issues and cast their votes regardless of that. This makes an RFC stage (and the whole proposal procedure) nothing more than a formality.

My view on it is that voting stage should never be started (allowed to start) without addressing every issue submitted by proposal reviewers. Otherwise, no improvement of proposed scheme is possible if an author is lazy enough.

There is a proposal of healthcare=midwife tag in its voting stage. This proposal says, that “a midwife practice” is something self-explanatory. But this is a good example of bad tag design and here is why.

I understand, that majority of OSM members are men and only a few of them are medical professionals. So, it’s hard to expect that they have a good understanding (especially, in a global scale, which is important since OSM is an international project) of specific healthcare services for females and healthcare services in general.

First of all, “midwife” stands for completely different persons in different countries and medical systems.

• They have different education level (from professional certificate equivalent to Bachelor’s degree from a college or Master’s degree from a university).
• In some countries they are a part of a regular medical system, in some - they represent an “alternative” medical system. There are, probably, countries, where private midwives do not have to have any formal education and they are, practically, witch-doctors.
• In some countries, like Russia, they are basically just a special type of nurse in a maternity hospital. In others, they can work independently and provide an almost full scale of maternity-related medical services. In some African countries, midwives are allowed to do Cesarians, which is unimaginable in the Western medical system, where only MD surgeon can do it.

It means, that in one “midwife practice” women can only receive simple counseling service, in others - they can give birth and so on. All the above means, that there is no common denominator for all these different “midwife practices” except it’s something for women and it is maternity-related. It doesn’t seem like a good base for a single tag. By approving this tag, we’ll get another thing we can put on a map, but can’t really use for any real case without studying different aspects of every national medical system.

… Zobrazit celý záznam

When someone tries to compare OSM.org and any cartographic web service (usually, Google) it is hard to make people trust you when you telling them it’s nothing more than technical website mainly intended for internal use by mappers. Same problem applies to OSM Standard (aka Mapnik) style. Finally, there is something more or less official to show them as a proof.

Andy Allan just gave this reply on question about expanding tile distribution infrastructure. (Full message text with added emphasis.)

We should be clear here - we have more than enough capacity to handle all the traffic generated by our mappers, editing software and every website run by the OSMF, local chapters and local mapping groups. Several times over.

We’ve always allowed other people to use our spare capacity on the tileservers, but recently it’s got completely out of hand. Most of the use of our tileservers has become developers looking for free maps, nothing to do with the rest of the project. Often these are commercial companies who are using our tileservers and selling their apps. Subsidising commercial companies isn’t the best use of community donations and volunteer sysadmin time, when there are many alternative services (such as those run by CartoDB, Stamen, etc) that provide zero-cost map layers based on OSM data anyway.

We do have plans to scale the tile infrastructure later in the year (cascading an old database server), in addition to the current process making sure that our OSMF tileservers are being mainly used for OpenStreetMap related projects.

I just want to keep it here to be able to quote it for any stubborn people, insisting on their own view of OSM infrastructure functions.

GPS tracks, contributed by OSM members still are sometimes very important source of information for mapping. However, built-in OSM database has certain issues, such as inability to delete obviously harmful data, such as airborne tracks, huge wandering spots, created by receivers in standing cars, etc. Currently, all responsibility for GPS data quality is on contributors, since they have to take care of getting rid of wandering spots, super-generalized tracks, tracks with high GDOP and so on before uploading it. While only a few people actually know about all these aspects and care about it. Complexity of track contribution process (at least, it’s not a”one click procedure”) makes fresh tracks more and more rare.

Strava heat map is another (often - way more dense) source of GPS tracks. But it’s limited by running and cycling activities.

For a long time, I’ve been saying, that any more or less popular mobile map/navigation application, which uses OSM data, can help to improve GPS tracks coverage. And being properly developed, it will not require any actions from its user, except giving his permission to record and upload tracks anonymously. It’s an ideal case, where valuable contribution could be fully automated and independent of user’s skills or knowledge. Set of simple filters (GDOP, top speed, geolocation source provider) can reduce consumed traffic and improve data quality.

… Zobrazit celý záznam

Ongoing voting on Education 2.0 proposal have demonstrated, that some OSM members don’t understand the situation with multiple properties. I was a kind of surprised by this lack of understanding, since it is already explained in Wiki, so I want to explain it one more time.

Definitions:

1. Single value stands for key=value case, for example: man_made=tower
2. Value list stands for semicolon-separated list of values, for example: sport=basketball;volleyball
3. Separate keys stand for multiple binary keys for each property, for example: sport:basketball=yes, sport:volleyball=yes

Case (1) is the most simple and traditional in OSM. However, if certain feature uses this tagging style, its value becomes exclusive, which means, there can be only one value. And for certain features it’s completely acceptable, because, for example, man-made structure can’t be a mast and a tower in the same time.

Case (2) was, probably, the first way to find a workaround for non-exclusive values. It’s a straightforward way for those cases, when properties are non-exclusive, which means, certain object can have several properties of one feature. Just like in example above, a pitch could be used for playing basketball and volleyball.

Case (3) is, at first glance, similar to (2). And some people think that it’s only a different tagging style. Indeed, it allows to represent the same situation, but with separate keys (tags) instead of value list in one tag, so semantically it doesn’t have any advantage. It even looks more complicated, because its structure actually consists of three elements, not two: namespace:subkey=boolean_value, where namespace equals to key in case (2), subkey equals to each value from list in case (2) and boolean_value is just yes or no (in case of no, the whole tag is omitted).

Technical side

… Zobrazit celý záznam

Recently, I’ve published several tiles of fresh Sentinel 2 satellite imagery using Nextgis.com free spatial data hosting service. All tiles are available here. Two tiles were published by request, others are covering two major populated territories in Russia - Moscow region and Saint Petersburg region, one tile was randomly picked, it covers western part of Republic Mordovia, famous for endless forests (and one of my goals was to test it as a source of information about logging) and high concentration of prisons, located there. For some tiles, both visible wavelength and visible+NIR composites were made. Workflow of making those composites was quite simple:

1. Make a dump of georeferencing data from any 10m/pix resolution channel image
2. Use convert -combine from ImageMagick to merge single channels into 16-bit per channel RGB image.
3. Use convert -contrast-stretch to manipulate image histogram
4. Put georeferencing information back, save resulting file as 8-bit per channel RGB image, compress it with Deflate or LZW
5. Upload it to Nextgis.com, set up web map and WMS service.

(Steps 1 and 4 were made using GlobalMapper, but could be done using GDAL and Python script.)

I asked people to give me some feedback, however, only one person (not counting those who asked me to make two of those tiles) informed me that he used this information to update forest boundaries, changed by logging and wildfires. I’m obviously doing it not for any kind of reward or acknowledgement, however, I really don’t like to do anything nobody is going to use by whatever reason.

… Zobrazit celý záznam

Case of Maps.me is, in many aspects, similar to cases of Potlatch and iD (on its early stage of deployment), but in certain aspects it is special. At least, in aspect of how frequent those edits are. Since currently it is hard to reach out to every Maps.me editor user, it makes the whole situation a kind of similar to imports, where we have massive amount of data, originally not suitable for OSM, often - with questionable quality (should I remind everybody of TIGER and its consequences for American OSM?), with certain systematic issues.

If this analogy is acceptable, it’s logical to apply certain import guidelines to it. Think about paragraphs 2.9, 1.1, 1.2, 1.4, 1.5, 2.1.

So, if these requirements are acceptable (I mean, nobody thinks it’s impolite to require it) for imports, why it shouldn’t be applied to Maps.me, or whatever editor, which increases involvement of people, unaware of OSM guidelines, or provokes systematic mistakes? I’ve seen comments, where people literally opposed paragraph 2.9:

Take great care to avoid damaging the database and don’t leave a messy import and assume that nameless OpenStreetMap contributors working in iD and Potlatch and will tirelessly complete your work. JOSM is better at for untangling messy data, but it’s still difficult and you should do this work yourself if necessary.

And, by the way, it also says:

If your import does ‘go wrong’, or you needed to interrupt an upload half way through, then this should be reverted promptly. … If you don’t know how to revert an import, don’t do the import in the first place.

When applied to editors, it means, that if it systematically provokes avoidable wrong edits, measures should be taken to prevent them. And developers should be prepared to do a cleanup.

… Zobrazit celý záznam

Some people were quite excited about recent announcement of built-in OSM editor of Maps.me navigation app, but now, first version of it is in use for many weeks, bringing up more and more complains about Maps.me users doing all kinds of unwanted things.

Since pointing on negative facts makes certain people feel offended, I want to clearly explain my position. I agree, that OSM could have more contribution from people, not deeply involved in project. And general idea of enabling them to do such contribution using their favorite navigation app is close to perfect. Maps.me is the first widely used app helping its users to contribute to OSM. This app does have certain nice features such as opening hours entry. I also realize, that it’s only the first version.

However, there are certain flaws, making its future look not that optimistic (at least - in given current situation). I don’t want to try arranging these flaws by its importance, but I’d like to list some.

… Zobrazit celý záznam