@Adrian 2 , I don’t think that the availability of free (government) correction services is relevant to this matter. I use what’s available because it’s convenient. If there weren’t free access in my state, I’d find a different way. There are services like RTK2GO. Someone could spend an extra equivalent of $300 and set up their own base station. And so on.

The minimum goal of using RTK is to accurately measure the shape. However, even though the accurate location of that shape is only the secondary goal, the steps to improve location accuracy are technically too simple to neglect and skip. I’d go far enough to say that it’s irresponsible because it means knowingly introducing data with a systematic error. (The only nuance is that a “wrong” untransformed CRS could sometimes be negligibly different in the metrological meaning of that term from the desired variant of WGS84.)

It is, in fact, a complex problem to figure out which CRS and epoch to use as a transformation target. However, it would be wrong to choose it arbitrarily, without declaring the criteria for the solution first. Otherwise, it’s arbitrary.

For a future hypothetical scenario of added support for the fourth coordinate (time), we can fairly simply list at least some criteria to help with not turning everything existing prior to that into dead data. But those criteria might be visibly different for OSM geometry and user-submitted tracks.

Since I was talking about tracks in this post, the question that must be answered regarding that is: “What target CRS/epoch should be used to transform a track to emulate what (infinitely precise and accurate for the sake of an idealized hypothesis) standalone GPS receiver would output if we used it to record it?” In the case of tracks, the precise collection date is already embedded in it. In other words, it’s about bringing data to the common expectation.

@StephaneP,

To explain why I am convinced that it’s a general assumption, I’d like to quote this: osm.wiki/OSM_XML#Contents If anyone wants to argue about this matter or present an “alternative view” on that, they are welcome to start by listing any existing provisions for any other CRSs in the data storage, handling, and export mechanisms.

@StephaneP I don’t “think” OSM is using WGS84; it’s a general assumption/historical practice (and also a huge architectural flaw, for the exact reason you mentioned) that isn’t enforced in any meaningful manner.

Until there is any sort of provision for handling the CRS metadata you suggested adding, it would be pointless to do so. Pointless, because instead of increasing practical certainty, it would do that only formally. To do it practically, it would require either (or both) OSM database to support on-the-fly transformation together with the correct handling of such metadata, or a solid awareness of OSM data users (including every OSM editing software) of data being stored in different CRSs. Without that, data stored in a CRS other than the assumed one would not get properly transformed/

Transforming data to match the general assumption, on the other hand, eliminates one layer of uncertainty and the currently inevitable data handling error. If in the future, provisions for real-time transformations, time-based CRSs, and multiple CRS data storage are created, I’d be happy to get back to this question. Until then, it’s (unfortunately) nothing but philosophical discussion. I’m not a core services developer, nor can I become one, so that’s not something I can influence directly.

@Javier_Jimenez, I’m not sure what you are talking about. I didn’t suffer from any lack of information about the CRS used by ORGN; it’s pretty clearly documented on their website, which I linked above.

So, this data isn’t stored in OSM, but elsewhere; that map only uses OSM as a background.

@Firefishy Absolutely, it works great. Besides, there are cheaper modules (WITMOTION) available for half of the mentioned price, so it’s fairly possible to build your own base + rover kit for about $250, even if there is no good free NTRIP coverage in the area.

I simply don’t appreciate people lying and misrepresenting things, like you did in your post.

And your fake “compassionate” appeal to made-up emotions doesn’t work, it’s a middle school mean girl rhetoric, it’s pretty pathetic for a grown-up man to use it.

OSM tolerates “bullshit” and protects those who generate it, except for the most blatant cases of large-scale vandalism, under the unfalsifiable pretext of “Everyone who created an account (including those who did it with ulterior motives) can become a valuable active mapper!” Or under another pretext of “Everyone must be able to have fun mapping (even if it creates the lowest possible quality data, discouraging those who produce quality data or want to use OSM data for their project without creating a massive heuristic filter for garbage)!”

There aren’t any barriers for anyone who has a computer or a smartphone (even vagrants have them now) to do mapping if they want, unless they simply don’t know about OSM. Even in 2015, there weren’t a lot of technical obstacles.

It just sounds like someone really wants those cake pops, attention from the government, etc. Or to LARP a hero of truth and be praised for that.

@gdt, I’ll quote myself:

This is something that OSM (database) doesn’t take into account at all.

So, there are no provisions for this. And I never claimed there are any. If you are confusing what I did say about importing an overlay and something about storing the epoch reference in the database, I don’t know why would you think I meant the latter.

No, I didn’t get a null transform.

Don’t you think someone who even looked into this matter should be able to do something as simple as comparing the output and/or overlaying the data? Doesn’t seem like you read what I said carefully or at all.

Well, “having the best data” and “not caring about the intricacies of tagging” are deeply contradictory things. You can’t have good data (that can be interpreted uniformly and non-ambiguously) without a good tagging scheme.

@TomH , edit wars mainly happen because people have strong opinions about the mapped object in question, or when it’s about the quality of the edits (that might or might not be subjective). So, I don’t see a logical reason to think that a more straightforward way to do reverts will have any additional effect on people’s desire to fight over edits that already exists.

It’s pretty alarming that the term “violence” that has an absolutely clear meaning for centuries, being ingrained in criminal codes and legal language of many countries and cultures (including those using different languages but having the same semantic concept, like “насилие” in Russian, “violencia” in Spanish, etc) is used for something quite different in the context of something that has to be as clear as possible (CoC, community rules, etc.). I obviously don’t know what’s the intention of doing it, but I know the effect of it: a temporary elevation of the significance of the negative behavior in question. There’s no question that calling people names and doing other things like that is a bad thing, it’s rude, it’s unacceptable. But making it sound as if using rude and offensive expressions equals attacking someone physically isn’t the right thing to do for multiple reasons: first of all, it is demagoguery by nature (not necessarily by intention), second - it quickly leads to desensitization due to the overuse of the term, third (but not last) - it degrades the importance of the actual violence. Suggesting that words equal physical force intentionally is something that belongs to certain political ideologies and politics is something that ruins everything. I really hope that it’s just a figure of speech and there’s no ulterior motive behind it. But even in that case, it’s better to revise this approach for the sake of clarity and consistency.

… and of course, some Russian-speakers showed up to add a transliteration for the name.

This comparison by design can’t bring any conclusive results because of two fundamental metrological factors. - Unknown accuracy can only be measured against the reference data with known (higher) accuracy. It is impossible to measure it having three devices with unknown accuracy. - Smoother track doesn’t necessarily means better accuracy - it could be caused by filtering that doesn’t improve anything rather than visual appearance. In fact, filtering can create false perception of the higher accuracy while distorting data instead of improving it. Smoother appearance is highly deceiving. So, making comparisons like that might be fun, but it’s far from being practical, leave aside being scientific. And “scientific” doesn’t mean “fancy”, it means “conclusive and reliable” (and that’s the only way to achieve that).

Since the test happened in the US, there should be some high-accuracy GIS data available from DOT or another agency that could and must be used as a reference to measure everything else against it.

This reference to “gate codes” seems like a suggested solution for a non-existent problem. Because if someone wants to make confidential information public, there are millions of ways to do it and OSM is probably one of the last ones.

First of all, let me point at this OSM Wiki page: osm.wiki/Aviation It contains some brief but valuable information. “Real pilots”, whoever it may be, according to FAA (and other aviation authorities), must only use charts and navigation data published by authorized parties (see https://www.faa.gov/air_traffic/flight_info/aeronav/digital_products/aero_guide/ and further links). Therefore, they might be using OSM only when they, for example, drive to the airport by car. Otherwise, they’d be committing a violation. Sure, they might also be checking OSM-based maps to figure out some ground features related to the flight plan, but not for the actual navigation.

I’m not sure what “codes” and “key locations” mean, but most of the navigational information is practically public, so it makes no sense to create any secrecy around it. The actual secret information is secret, so it is practically impossible that it will show up in OSM.

Дорога, которая отмечена линейным объектом - это корректная, но неполная топология. Полную топологию могут, например, образовывать вместе с ней метаданные (тег, обозначающий ширину). Некорректная топология отличается от неполной тем, что из некорректной можно сделать неоднозначный, но логически верный вывод о пространственных свойствах объекта, а из неполной топологии вывод сделать нельзя, потому что та или иная информация просто отсутствует. Проиллюстрирую. Контур леса сам по себе - некорректная но полная топология, потому что мы не знаем, что именно обводили - стволы или кроны. Дорога в виде линии - корректная но неполная топология, потому что мы знаем точно, что линия обозначает середину дороги, а не один из ее краев. Так что, пытаясь визуализировать это, мы сознательно делаем допущение о ширине, которое не противоречит данынм. А что нам делать с лесом - мы не знаем. Алгоритмы рендеринга не могут делать топологию в базе корректной или нет, они могут делать отображение этой топологии корректным или нет.

Как всегда, сторонников того или иного подхода следует спросить, ради чего они хотят делать так или иначе. Потому что ситуация, когда дорога совпадает с краем леса, служит единственной цели - упрощению задачи для рисующего (но не для тех, кто будет редактировать после него), то есть служит лени и эгоизму автора. Выкручиваться, конечно, можно сколько угодно, выдумывая полу-фантастические и фантастические поводы. Для корректной топологии выдумывать поводы не нужно, потому что факт, что обозначение дороги линией делается по осевой, которая не может быть физически той же линией, что “край леса” - неоспорим, даже если решить, что край леса - это край крон, нависающих над дорогой.

Контр-аргумент про “мы же не рисуем под рендер” будет логически ошибочен, потому что в случае X-plane рендер вскрывает несовершенство топологии (которое оказывается естественным образом скрыто в двумерном рендере), отображая то, что есть в базе. А другой рендер пытается, путем внедрения костыля, это компенсировать.

Performing an appropriate shift to compensate for the tectonic movement is technically possible when a dataset retains just one little bit of metadata: acquisition date.

This is the case where presenting any kind of global statistics as an argument is fundamentally fallacious, regardless of cumulative or not, what scale was used for a chart and so on.

It is fallacious because there is no evidence that increasing number is a result of a tendency on the DWG side. There is no “too many” or “too few” - there are multiple individual cases that lead to as many blocks as needed (excluding the undiscovered ones). Although, there might be some local clusters of reasons why blocks have been issued. Such as spam, Pokemon Go vandalism (something totally new, isn’t it?), use of illegal sources to improve the data for the commercial purpose, edits war over disputed territories. If there is an increase of vandalism related to any third-party services, it is actually an indirect proof that the number of data users grows. (Yes, it happens. No, I don’t know how many of these cases led to a block or has been found.)

So, I suggest abstaining from any negative assumptions and presenting it as a false dichotomy of “getting more users” versus “blocking more users”. If it is necessary to block someone to maintain data integrity and quality as well as project reputation - it’s totally fine. By the way, data quality degradation caused by systematic vandalism is among the reasons why loyal users might become discouraged and lose their motivation.

If you are aware of any case when a user has been blocked without any significant reason - let everybody know about it. If you think that the practice of blocking users is not transparent enough - let everybody know about your concern. But saying something as vague as “oh, maybe it’s too much”, even in a context of growing number of blocks per unit of time, is, again, fallacious and counter-productive.

I really hope that there is no post-modernist ideology involved here, such as “any user, even one who has effectively and systematically demonstrated uncooperative and even hostile behavior together with harmful actions, can be transformed into a valuable community member”. But if there is something like that behind this diary entry, I suggest presenting an accurate evidence of such possibility. Even several anecdotes could be sufficient since it makes no sense to expect a scientifically correct proof.