Но ведь это неправильно.
Есть стандартная таблица типов:
(ind:$0100; nam:'Мегаполис (свыше 10 млн.)'),
(ind:$0200; nam:'Мегаполис (5-10 млн.)'),
(ind:$0300; nam:'Крупный город (2-5 млн.)'),
(ind:$0400; nam:'Крупный город (1-2 млн.)'),
(ind:$0500; nam:'Крупный город (0.5-1 млн.)'),
(ind:$0600; nam:'Город (200-500 тыс.)'),
(ind:$0700; nam:'Город (100-200 тыс.)'),
(ind:$0800; nam:'Город (50-100 тыс.)'),
(ind:$0900; nam:'Город (20-50 тыс.)'),
(ind:$0a00; nam:'Город (10-20 тыс.)'),
(ind:$0b00; nam:'Населённый пункт (5-10 тыс.)'),
(ind:$0c00; nam:'Населённый пункт (2-5 тыс.)'),
(ind:$0d00; nam:'Населённый пункт (1-2 тыс.)'),
(ind:$0e00; nam:'Поселок (500-1000)'),
(ind:$0f00; nam:'Поселок (200-500)'),
(ind:$1000; nam:'Поселок (100-200)'),
(ind:$1100; nam:'Поселок (менее 100)'),
Почему не пользоваться ею? Тем более, что население в данных OSM фигурирует.
Как это не влияет?
Влияет на способ отображения на карте. Ведь на любой карте есть значки, соответствующие городам с вполне определенным населением.
А у нас получается банальная дезинформация, т.к. город фигурирует как имеющий совершенно другое население.
Нельзя ли эту дезинформацию все-таки поменять на достоверную информацию?
Понимаю, что вопрос не к конвертору (хотя и в нем можно было бы предусмотреть исправление хотя бы некоторых ошибок, коль скоро POI уже плодятся сверх того, что есть в OSM), тогда к кому обращаться, чтобы исправить данные ошибки непосредственно в данных OSM?
Существуют определенные правила хранения и обработки информации необходимые для того, чтобы избежать ее потери при хранении/передаче.
В частности, есть правила хранения текстовых констант (ТК).
При хранении ТК в бинарном файле применяется один из 4-х способов:
- указывается адрес начала и длина,
- указывается только адрес начала, подразумевается, что, зная адрес начала следующей, можно вычислить длину,
- указывается адрес начала. Константа заканчивается разделителем, обычно нулевыми байтом,
- константы идут через разделитель, при этом таблицу адресов должна составлять сама обрабатывающая программа, сканируя область данных на наличие разделителей.
При хранении ТК в текстовом файле задача несколько усложняется, т.к. в качестве разделителя обычно невозможно использовать символ, который не может встретиться в самой константе.
Выходов несколько:
- выбрать несколько символов в качестве разделителей и заменять их внутри констант определенными последовательностями, не допускающими неоднозначности. Применяется, например, в html/xml.
- выбрать символ-разделитель и удваивать его перед помещением внутрь константы. Применяется во многих языках программирования, например в Паскале(').
- выбрать два или более символов разделителей и использовать тот из них, который не встречается в текстовой константе. Применяется, например, в Фортране(’ и ").
- выбрать разделитель среди символов, которые не могут встречаться в образцах текста, помещаемых в константу. Например, в неспециализированном тексте на русском языке не могут встречаться символы |=+{}.
- есть и другие…
В использованном же варианте в качестве левого разделителя используется запятая, а в качестве правого - символ CR. И если применение CR не вызывает возражений для ТК, в которой не может быть деления на строки, то применение запятой - вызывает, и эти возражения я уже изложил выше:
- запятая может встретиться в ТК,
- после запятой ДОПУСТИМО как наличие, так и отсутствие пробела (по ГОСТ), что дает неопределенность, с какой позиции начинать ТК.
Если ориентироваться на стиль MP файла, ТК следует размещать сразу после разделителя “=”, причем в этой строке не должно быть ничего кроме ключевого слова, разделителя и текстовой константы.
В качестве примера можно порекомендовать вместо
EntryPoint=(55.7405521,37.4165066),Техносила
использовать, скажем,
EntryPointCoord=(55.7405521,37.4165066)
EntryPointName=Техносила
