Using a phone running Android OS as a data collector for an RTK-enabled GNSS receiver, I ran into a fairly small but annoying inconvenience with getting data files from it on a Windows machine.

On Windows, you can’t mount a phone’s file system as an actual removable drive (don’t confuse that with seeing its file system in the File Explorer), so automating it with built-in command-line file tools isn’t an option. File paths to the data folders of Android apps are ridiculously long, so traversing them manually is another hassle.

However, it’s still possible to do that using the Android Debug Bridge tool, a part of the SDK Platform Tools.

After installing SDK Platform Tools, you should be able to use the adb command in PowerShell or classic Command Prompt batch files.

Knowing the full path to a folder where your data collector app (LocusGIS, SW Maps, etc.) stores files you need to download regularly, you can get a list of that folder’s contents by calling adb shell ls command with the full path to that folder as a parameter.

Downloading a file is as easy as calling adb pull with the full path to the file you want to download. This process can be made more or less interactive if you create a script that lists all the folder contents, then prompts you for a name, and then downloads the file by the name you entered. The target file name or path can also be specified as another parameter. It’s even easier if the data collector app uses the same filename every time, or if you save it under the same name.

For all that to work, you’d have to enable USB debugging on your mobile device and grant permission for the Windows machine to use it when you first attempt to utilize the adb. However, it would save you the hassle of switching on the File Transfer mode every time you want to access the phone’s file system.

… See full entry

It’s relatively common for various national and regional GNSS correction networks to be referenced in a CRS other than WGS84 used in OpenStreetMap. The reason for this practice is that countries and regions use their own coordinate systems, most suitable for the territory they cover.

For example, the Oregon Real-Time GNSS Network (USA) uses NAD83 (2011) epoch 2010.00, according to their website.

It means that any RTK measurement taken while receiving NTRIP correction data from such a network will be referenced to the same CRS. That applies directly to the NMEA data output of the receiver, despite it normally being implied to be in WGS84. The majority of receivers available to amateurs are incapable of being configured to be aware of that. (The only sub-$1k receiver core I’m aware of that can “understand” the NTRIP CRS defined manually is Septentrio Mosaic.)

So, unless you perform a transformation from said CRS to WGS84, your tracks are going to be completely unsuitable for submission into the OSM public tracks database.

However, there’s a pretty straightforward way to perform the required transformation. Unfortunately, it’s “a little” longer than ideal for the exact same reason that NMEA data is implied to be in WGS84, so feeding a NMEA log directly may result in the reader ignoring the input CRS override.

The key tool for this is, coincidentally, JOSM. Here’s the workflow that functions just fine in my experience:

… See full entry

After reading this article How to transform data from NAD83 to WGS84 and based on my personal experience (taking RTK GNSS measurements with multi-frequency multi-constellation receiver hooked up to ORGN NTRIP caster referenced to NAD83(2011) epoch 2010.00), I want to share some notes.

The article suggests QGIS as a tool just to proceed with warning potential users how it could easily go wrong with no warnings. However, it doesn’t provide any methods to verify the results or the method itself except for trusting the process. Since my first attempts (independent from the content of the article) to transform my observations have failed, I was looking for the verification method and found some.

First of all, as far as I understand QGIS uses GDAL/ORG and PROJ. This toolchain has a very useful command projinfo for testing the transformation. You’d need to understand WKT output that it will spit out, but you can much easier spot the situation when it’s going to use a ballpark low-precision transformation.

For instance, this query:

projinfo -s EPSG:6319 -t EPSG:7665

among many other things spits out this string:

Conversion from NAD83(2011) (geog3D) to NAD83(2011) (geocentric) + Inverse of ITRF2008 to NAD83(2011) (1) + Inverse of WGS 84 (G1762) to ITRF2008 (1) + Conversion from WGS 84 (G1762) (geocentric) to WGS 84 (G1762) (geog3D)

It explains in fairly good detail what it’s going to do and has some useful keywords such as geog3D which means that it expects input and provides output in degrees of latitude/longitude as well as ellipsoidal height, see EPSG:6319 for details. It also mentions 0.01 m at the beginning and in the context of OPERATIONACCURACY[0.01] which is pretty self-explanatory.

Then, you can actually attempt transforming an individual set of coordinates using cs2cs. The easiest way is to throw them into its input stream like this using echo:

… See full entry

relation/3823410 Кому-то, как всегда, неудобно воспользоваться Overpass Turbo или осилить пространственные запросы к БД.

Но поскольку уже выросло целое поколение игрунов, для которых не существует критериев правильности вроде отсутствия избыточности и так далее, есть только критерий объема получаемого удовольствия (а любая критика или ограничения - фактор, обратный удовольствию), о чем тут можно спорить?

Recently, user DeadAngel started a thread on the Russian community forum to inform other community members that for a long time, he had been copying addresses from multiple unacceptable (commercial mapping services) and disputed (state property registry) sources. He also used local administration development plans, allowed for use in OSM due to their legislative nature, while he wasn’t aware of that, assuming that all sources aren’t acceptable. He said that he sent a letter to DWG asking to delete his illegal contribution because he eventually understood and acknowledged his wrongdoing.

This is a questionable situation because it is unclear which edits were based on illegal sources (development plans aren’t an illegal source), but the reaction of community members was totally surprising and barely relevant to it.

Indeed, one or two people tried to ask for clarification. However, others came up with a paranoid suspicion that it is not the “real” DeadAngel, but someone who uses his stolen account to harm OSM data, serving the interests of commercial mapping services. They demanded “proof” that he is the “real” DeadAngel, accused him of starting a scandal (while there is no scandal), blackmailing the community (how exactly?), and so on. All for the sake of discrediting a user who acknowledged his unacceptable actions and keeping the precious address data.

… See full entry

As it has been mentioned before, establishing a Telegram channel as a major matter of communication for Russian-speaking OSM community is a questionable step itself since it creates an additional fragmentation and benefits only a certain group of people within this community.

However, this situation got some development recently. Russian communication regulator authority, RKN (actually, the government censorship agency) officially started blocking Telegram messenger communication protocol. Ironically, at the same time, iD got Russian OSM Telegram channel listed on its sidebar, above the link to OSM Russia forum section (which was always the main method of communication), giving a hint of its greater importance.

So, from now on, only those Russian users of those rare internet service providers who haven’t started following the order of RKN or those who are able to set up and use network tunneling services (soon they will be illegal in Russia too) will have an access to Telegram.

Most likely, some commenters might argue that it is so easy to set up a VPN and so on, but that’s not the point. The point is that any random OSM user from Russia should not have to violate (obviously, stupid and unconstitutional, but still existing) law or learn how to be an IT specialist to have an access to community communication channel. It doesn’t mean that some people can’t keep using that channel privately if they want to, but it should not be listed anywhere as a major or preferred channel of communication.

I just noticed an interesting thing. If you want to create a point indicating a garbage dumpster (trash container or whatever similar) using iD with the English language interface, you add a point geometry and then start typing “garbage” in the Search field. Once you’ve typed “gar”, found tagging options will be related to anything “garden” and “garbage”, but there will also be a “ॐ Hindu Temple” as a sixth item. If you type one more letter and make it “garb”, you’ll have everything “garbage”, but Hindu Temple will jump to the second place.

I’m not claiming that I know how it works, but I assume that there are keywords tied to an interface language and to every tag or set of tags for a specific object. They seem to be language-dependent (while it is still possible to type something in German, like “wald”, and get Wood as an option), otherwise, there would be a lot more confusion with similarly spelled keywords from different languages.

However, I don’t see any logic in this specific situation. As Wikipedia says, “Garbhagriha” is a Sanskrit word for a part of a Hindu temple (not even for a temple itself). How often might it be typed in Latin alphabet by iD users? Does it really belong to English interface, keeping in mind that English is not the main language in any of those countries where Hindu religion is prominent enough? It definitely belongs to Hindu and some other languages, but English? By the way, if you try typing “altar” (also a part of a temple in many religions) - nothing related to temples or cathedrals will pop up. Considering this logic, Hindu Temple should not show up on a list after typing “gar” or “garb” in a search form.

Just to be clear: I don’t care if it will continue popping up - it looks amusing to me, not just “wrong”. I’m not going to dig into iD’s complicated structure and register on any translation services to fix that.

Being a distributed crowdsourced project, OSM strongly depends on communication channels to bring the desired level of coordination within communities. However, since there is a high level of independence and autonomy in these communities, it might lead to a situation of scattered and fragmented communication. I’m not proposing anything here, but I still want to bring this issue to attention.

Every technology used for communication (mailing lists, forums, messenger channels, IRC) might have a certain advantage over others, but the thing is that it has nothing to do with its popularity. The dominance of a certain channel within a community has historical roots and relies on a habit. An existing choice might have a justification, but that is not a reason for a particular choice. For example, why Russian-speaking community prefers forum over the mailing lists? Just because several people started using it many years ago. It’s not because it’s easier to search through it or because it has better message formatting features. But there is nothing wrong with it. However, there is one significant bad side.

Commonly used communication channel might get a “fork” just because several people (or even a single person) want to take over it or just because they have different habits. That’s exactly what happened in Russian-speaking community starting a Telegram messenger channel. Those who don’t want to use Telegram or who prefer non-real-time communication (forum or mailing list) over a real-time chat technology, become deprived of a significant part of a communication process.

… See full entry