Хотя по дате в имени файла - да.

postal_code не относится к адреске.
Этим тегом отмечают улицы вдоль которых стоят дома с одним почтовым адресом.
Имхо какая-то костыльная хрень

Посмотри на оф.сайте.
Его колбасило намедни

ну вот в вики написано - что вдоль дороги или для зоны https://wiki.openstreetmap.org/wiki/RU:Key:postal_code я тут просто наткнулся на деревню где так обозначено и озадачился, может это действительно более верное, а то я обычно ставил через addr:

А теперь найди какое-нить хотя б одно применение или задумку применения этого тега в реальных алгоритмах... :)

ну если такой вариант устраивает, то и gpx в точности так же можно "чинить"

определение почтового индекса по территории, в одном месте только поставить нужно, а не на каждый домик. вопрос был в обозначении postal_code или addr:postalcode, надо или вики в соответствие привести или в базе поправить, чтобы было единообразно

Видимо, какой-то глюк:

В этом файле timestamp=2020-08-12
http://download.geofabrik.de/russia/central-fed-district-updates/000/001/737.state.txt

А в этих одинаковый timestamp=2020-08-14
http://download.geofabrik.de/russia/central-fed-district-updates/000/001/738.state.txt
http://download.geofabrik.de/russia/central-fed-district-updates/000/001/739.state.txt
http://download.geofabrik.de/russia/central-fed-district-updates/000/001/740.state.txt

Если завтра не изменится, то надо будет багрепорт накатать

Простите как просто "контрольная сумма" исправит файл?
Не... Есть варианты, не небольших объёмах данных, который по "контрольной сумме" позволяют "чинить". Но это скорее исключения, чем правило.

Просто контрольная сумма призвана просто показать наличие "плохих данных" не более.

А дальше - учитывая что csv или xml - это "human-readable format" открываем и ручками просматриваем... Или не ручками, а зная его внутреннюю структуру, натравливаем валидатор каждой строки и в зависимости от силы повреждений либо чиним либо выкидываем невалидное. Спасая то, что можно спасти.

В бинарный форматах это сделать сложнее. Из-за того что там плотность информации на 1 бит выше. И потеря даже 1 бита более критична чем в текстовых форматах с повышенной избыточностью.

@cupivan Стандартный метод наследование адреса из контура. Т.е. рисуем контур на него ставим кроме стандартных еще тег addr:postcode и он, таким же образом как и вся остальная адреска, наследуется объектом из контура.
Postalcode излишен

В принципе да, но софт, который распарсивает xml может не ожидать его неоконченности и будут проблемы у софта, в то время как при чтении FIT ещё до того как начать парсить можно получить гарантированно верный признак исправности файла и парсить его штатными средствами или зная что он битый пытаться парсить его осторожно

"контрольные суммы" не предназначеня для того, чтобы чинить - они могут быть индикатором наличия ошибок передачи в данных

контрольная сумма не является объектом избыточности данных, она признак того как дальше читать файл - штатно не боясь словить сегфолт или аккуратно, по шагам ловя исключения

ну где-то так да,
хотя считать образанный гпх можно любым хмл парсером, кторый SAX например, потом пересохранить

большо плюс миенно хмля именно в универсальности самого формата, хотя ее не всегда, конечно, правильн оиспользуют

Увы и Ах. но нет. Контрольная сумма это просто "флаг" что с большой долей вероятности данные не повреждены.

Отметьте. ВЕРОЯТНОСТЬЮ!

Да. XML это более в описанию структуры и иерархии. То что в него всё подряд пытаются завернуть - увы и ах. Но он и там всё же справляется.

да уж... все плюются, но используют...

Хмл можно ручками починить.
Кучу gpx за навителом в свое время так и чинил.
А вот из бинаря получить данные без спец.инструментария уже сложно