Парковки access=private надеюсь не будут иметь poi парковки? (мне кажется, что так правильно). Что бы не светились на общих масштабах своим значком, смущая гостей города.
А зачем парковкам наименование =-O ?
Ещё по поводу наименований. Сейчас у школы с забором получается три наименования – одно на заборе, другое на территории, третье на ПОИ. Может тут стоит что-нибудь подчистить? Забор однозначно 
а вот не надо делать школу и забор одним объектом.
Это ещё почему? Такая практика принята в ОСМ, надо просто к ней приспосабливаться. Дороги и трамваи же делают одной линией. Вроде есть и другие примеры. Да и чисто логически хорошо подходит – территория школы определяется забором. Т. е. линия – забор, ограниченная линией площадь – школа. Какбэ всё сходится…
Ну имя-то одно, вот оно и распространяется на все “ипостаси” 
Как иначе выбрать, на кого оно должно распространяться, а на кого нет?
А если имена разные, то и объекты должны быть разные.
Делай тогда линию “забор” без имени и мультиполигон “школа” с именем и этой линией в роли outer.
Ну тут надо какую-то логику применять Чтоб в большинстве случаев давала ожидаемый результат. Забор с именем может где-то и есть (Берлинская стена, например), но это исключение. Поэтому можно при расщеплении комбинированных объектов у забора имя отнимать.
При дублировании полигона точкой у полигона, наверное, тоже можно убрать имя…
Мультиполигон “Школа” – умножение сущностей сверх необходимого…
Кстати, разделение линий по типу тегов дало интересный побочный эффект – появились ошибки, вызванные тем, что на линии дороги были, например, теги highway=residential + landuse=residential. Раньше конвертер это проглатывал, а теперь ругается на незамкнутость линии landuse=residential
Конвертер-то не знает, забор ему попался или что. Поэтому тупо ставит имя.
Как вариант, можно для некоторых типов указывать, что имя им не нужно. Но тогда будет браться имя по умолчанию из typ-файла, и на заборе будет написано “забор”. Не уверен, что так лучше.
Что касается точек, то управление их отображением вообще меняется насройками в навигаторе.
Так как раз будет лучше.
А вот если линия самостоятельная, а не комбинированная, то значит забор таки именованный.
Вроде ведь не сложно при отделении от забора тега “аменити” отделить от него и “нейм”?
ЗЫ. Обычно на заборе другое пишут, но пусть лучше будет написано “забор”
То есть что, имя всегда отдавать полигону, а не линии?
А почему именно ему?
Нет-нет! Не отдавать полигону, а забирать у забора… Только и всего…
Кстати, у сочетания Дом + Магазин Имя оставлять магазину и забирать у дома. А Адрес – наоборот.
И как предлагаешь всё это описывать?
Ну я же не знаю тонкостей
Но мне имхуется, что в момент, когда парсер находит определённое сочетание тегов, то в момент, когда он дублирует линии и раздаёт теги он должен их проанализировать?
Парсер не анализирует теги, он просто создаёт объект, описанный в конфигах
Поэтому и парковки только именные обрабатываются?
Я не знаю что делать. Может менять конфиги, может допиливать программу. Но алгоритм вроде не выглядит нереализуемым…
рисовать забор отдельной линией (в данном случае) – это идти на поводу у конвертера (рендерера). kaas многозначительно поднял палец
Есть 3 идеи:
- Запись в конец .mp-файла, что всё сделано успешно. Например:
print "\n; ### All done!!\n\n";
При массовой обработке вывод в stderr теряется и не понятно, преобразовалась карта успешно или нет.
2) Формирователь POI для polyline, чтобы работало, например, такое:
place island l 0x15 0 1 0x650c,0,1
- Возможность указать в .cfg, что POI формируется для такой пары key-value, даже если у объекта нет имени.
Т.е. чтобы при формировании POI не проверялась “$param{name}”.
Предложил бы еще идею явного указания в конфигурации НЕнаследования имени или адреса объекта, например:
natural water p 0x3f[,priority[,NA]] 0 3 0x650d,0,2[,NA]
где
N - не наследовать имя,
A - не наследовать адрес.
Добавил. Хотя вроде и так всё было понятно.
Тогда надо будет всё по-другому делать. Подумаю
Убрал пока проверку на имя
Попробую что-нть похожее сделать