Sorry, I don't understand your process. Nominatim does not use any relations: it returns only nodes and ways for railway stations. Regardless of relation types, you won't get neither "stop_area", nor "site" from it.

Depending on OpenStreetMap in this way, but storing hundreds of overweight relations and hoping nobody touches them, is a way to failure. If not me, then somebody else would fix these relations. I'd suggest you redo the entire process, untying your system from specific collections and using spatial relationships instead. But of course that takes a lot of time.

Proposals don't have to be voted on to take effect. Wiki in general has a little say over OSM data. Site relations has been used for more than ten years, and now there are half a million of these in the database.

How do you reference these relations from your system? If by identifiers, they have stayed the same. If you download a raw planet data and filter relations based on tags, you'll see a great change over the next few weeks.

But I assume you've been using these special tags like "line:SNCF" and that's what broke your app: I didn't remove these tags from new relations. I've just done it: please check how your applications work now.

I'm against reverting relation types, since it breaks virtually every practical application except yours. But I'm willing to find a solution that benefits both your company, my station parser and OpenStreetMap mapping in general.

Ilya

Michael, thank you for this extended explanation. I have learnt a lot from it. I agree that light_rail might be unacceptable for Nuremberg. I change these routes type to train, if the local community agrees with it.

As you might know, I've made a metro validator, which runs for the whole planet, including german cities. It filters networks to process by a "network" tag. If it is hard to impossible in Germany to use this tag alone to choose metro (U-Bahn and in a few cities, S-Bahn) routes, what should I use? Should I create a new tag, e.g. network:type=u-bahn etc.?

Also, why light_rail is wrong for S-Bahn? It is definitely not a subway, and since it has short intervals, not a common train.

Okay, I see U-Bahn and S-Bahn in relation names. Why are they not networks? Naming a "transport and tariff network" with a "network" in the title does not automatically make it a network in OSM terms, just like naming a cafe "restaurant" does not make it a restaurant, and unclassified highways are not really unclassified in many countries. VGN joins many networks: R-Bahn, S-Bahn, U-Bahn, trams and buses. To me they definitely look different. Judging by a translation of the wiki page, it is more of a "parent operator" to operators of these networks, than a network itself.

Yes, I have already done that.

Okay, I am reverting the four railway stations I've modified, but also changing the relations' type to "site". I believe you are relying on relation identifiers, so this should not break anything.

Hi Antoine,

You have been using a stop_area type wrong. That type of relation was made to group elements relevant to transit data: stops, platforms, entrances, stations. Not to group everything in sight, from footways to shops and information signs.

For your use case, the type of relation is "site": osm.wiki/Relations/Proposed/Site . Using it will make it less likely to be changed because it doesn't fit some software that has certain expectations about stop_areas.

I have modified the relations, because stop_areas should not contain railway tracks. There is nothing on that on the corresponding wiki page, and having tracks in a stop_area makes it very hard to process and validate.

Is it okay if I change type=public_transport + public_transport=stop_area to just type=site for the railway stations?

Ilya

Ух ты, точные схемы коллекторов! Понятно, что речной: в нём же река течёт. А ты можешь достать такие же для других районов? Я бы уточнил трассы в OSM.

Не очень понимаю, зачем тебе это и что ты будешь делать с аналогичными «ошибками» в десятках других стран, но поступай как хочешь, я роли в отношениях stop_area в своём валидаторе не использую.

Я за последние две недели смотрел и правил сети метро в нескольких десятках городов. Все сплошь и рядом присваивают роль stop станциям во всех отношениях. Если что-то написано в вики, это ещё не значит, что это принятая практика.

Если станции добавляют в отношения маршрутов с ролью stop, не вижу проблем в этой роли в отношениях stop_area. По-моему, в этих отношениях роли вообще можно наобум выставлять: сочувствую тому потребителю данных, который смотрит на роли.

Sorry for that, repaired just now.

Привет! Подскажи, откуда адреса брал? Кроме как в твоём куске, их нигде нет: может, поможешь другим с их источником?

Hi fantomas, sorry for this. I have an imports account (Zverik_imports), but forgot to change settings in JOSM. I'll be more careful next time.

Насчёт телефона, незачем так строго. Я бы просто обе скобки убрал, потому что они обозначают необязательную часть, а если позвонить +7 21-75-91, получится неудача.

Здравствуйте! Вы в этом пакете правок сделали железную дорогу от Тучково к карьеру целиком мостом. Видимо, случайно понажимали «объединить линию».

Thanks for noticing and sorry for that. The edit was made by hand, so I must have mistyped in that relation tags.

Я не думаю, что знаки про водоохранную зону и шлагбаумы связаны. Знаков полно во всех областях: полагаю, это намёк на то, что машину нельзя мыть и постройки возводить. А шлагбаумы в таком количестве — только в подмосковье.

Про санитарную зону не видел ни одной таблички — везде шлагбаумы в своём стиле, частная территория или просто без объяснения.

Хотя по дереву в access=*#Land-based_transportation стало хуже: например, гужевая повозка едва ли там пройдёт. Ну, решай сам теперь :)