Osmium can auch das OPL-Format lesen und schreiben. Das ist ganz ähnlich wie ein CSV-Datei mit den üblichen Unix-Tools usw. zu bearbeiten.
Osmium can filter by area (closed ways plus multipolygon/boundary relations): osmium tags-filter ... an/name ... should work.
osmium tags-filter ... an/name ...
You should be able to leave out the second osmconvert call. Osm2pgql uses libosmium to read its input and can read o5m/o5c files. (Osmium can read those files, but not create them.)
You can use osmium fileinfo -e FILE to see a checksum of the contents of each of those files. If they are the same, the is no difference. If they are different you can use osmium diff to see what the differences are. Osmium is available from https://osmcode.org/osmium-tool.
osmium fileinfo -e FILE
There are different ways of encoding OSM data in a PBF file. You can use different block sizes or order the internal string table in different ways. This will result in slightly different file sizes. See https://wiki.osm.org/wiki/PBF_Format for details of the format.
Oh, and I suggest using help.osm.org for questions. Just so this here by chance, on help.osm.org probably more people will see it.
Are you sure the satellite pictures are right and the map is wron? Chances are that the aerial images are wrong. This happens all the time. So unless you can verify using GPS traces, don’t move anything around. For further help I suggest going to https://help.openstreetmap.org/ , that’s a better place to ask then you user diary.
This is an interesting discussion. When I started reading this, I thought about the center of Berlin, and my immediate answer was: Brandenburg Gate. It definitely is not some kind of historic center, because, after all, it is a gate, located at a border. But Berlin is special and the Brandenburg Gate is special. It is the place where East and West meet, so in a way it is in the center. It is historically important as a symbol of the split and re-unification of Berlin. It is definitely the place where crowds gather for important events. The Stadtschloß might have been important once, but it isn’t any more.
I understand the problem, but on the other hand: Where do we stop? Do authors of QA tools like OSM Inspector and Osmose don’t have similar “power”? What about authors of a wiki page? They also can mislead lots of people into mapping something in the wrong way.
In contrast to totally automated edits, we have a human in the loop with Maproulette & Co. So the problem is maybe not on the part of the person creating the challenge, but on the part of the mappers who work on it. Maybe they should have to prove that they know what they are doing?
I think it all leads back to: We need better documentation and especially better best-practice type documentation to teach everybody, regardless which mapping technique they use.
Nice analysis of the different cases of duplicate nodes. But quite expensive to do in the database. I have had a program lying around for a long time that does this analysis directly from the OSM files without any database. It runs in seconds for small extracts and about 12 minutes (on my server) for the planet. I just released it here.
Keys or tags that have wiki pages but do not appear in the database will still appear in taginfo, but with a count of 0. Some of those are just typos etc.
Note that a key or tag that appears only a few times is not necessarily wrong. Say, for instance, a tag to mark a nations capital. There are only on the order of 200 nations in the world, so that tag will not appear more often than that and thats totally fine. Also all data entry has to begin somewhere, so there might be a rather new tag that doesn’t appear often but has good potential. So the count itself can only be one hint that a key or tag might be something we could look at. A mapper still has to look at each and every case and figure out if the key/tag is okay or whether it needs fixing and, in that case, how best to fix it.
Taginfo is a place to find information, think of it as a search engine. It can’t be everything for everybody. This problem is not solved by bringing the wiki content into taginfo. OSM is a complicated place, it doesn’t matter which language you speak, reading a few lines is never enough. You have to read many wiki pages, look at stats, talk with others on mailing lists etc. Taginfo is one of many tool for serious mappers.
I am not sure what exactly you are proposing. Taginfo is translated in many languages and more are always welcome. Taginfo shows its user interface and, if available, the description of a key/tag in the language the user has set in their browser or the language the user chose specifically for taginfo with the drop-down menu. The description for a key/tag is taken from the wiki. If the description is not in the wiki in the language you have set, taginfo falls back to English.
There is one problem: If taginfo doesn’t have its own translation for a language, you cannot switch to that language and so you will not see any descriptions for keys/tags in that language. This was a deliberate choice on my part so as not to confuse the user, because they would switch the language and basically nothing would change, the UI would all be still in English. I don’t think this is a large problem though, because a) we can always add more translations to taginfo (please send them in) and b) for all the languages popular on the wiki, we have translations in taginfo. The language with the most wiki pages where no translation for taginfo is available is Czech with not even 100 wiki pages for keys and tags. In English there are over 2000 wiki pages for keys and tags. So even if that language was available only 5% of the wiki pages have been translated for it. (Statistics from http://taginfo.openstreetmap.org/reports/languages, available languages in taginfo see http://taginfo.openstreetmap.org/taginfo/translations.)
It might well be, that I have neglected to show translated text in some place on taginfo. If thats the case please open an issue at https://github.com/joto/taginfo/issues . Thats also a good place to add any other suggestions for taginfo.
You can store the coordinates as integers and you’ll only need half the space. See the storage/byid stuff in Osmium on how this can be done. The reason this works is that the precision of the coordinates is limited anyway, because internally the OSM server also stores the coordinates as integers.