die haben eine Adresse, Straße und Hausnummer, mindestens werden Grundstücke nummeriert oder auch Gebäude (das legt die Gemeinde im Rahmen des Landesrechts fest, von Bundesseite ist mind. die Nummerierung des Grundstücks gefordert), ggf. kann auch vorgesehen sein, dass Zugänge z.B. zu Treppenhäusern, eigene Nummern bekommen können.
Da muss ich Dir widersprechen, mit unit wird gem. englischem Wiki eine Gebäudeeinheit bezeichnet, die z.B. über einen separten Eingang oder ein separates Treppenhaus erreichbar ist und mehrere Appartements, Wohnungen oder Büros beinhalten kann … das ließe sich vom Prinzip auch auf verschiedene Einheiten einer Fabrik anwenden, die durch separate Gates erreichbar sind.
addr:unit macht dann trotzdem nur Sinn für einen Fabrikteil, nicht als “Tor 3”,
Das liegt daran, dass Nominatim grundsätzlich keine barrier-Objekte in den Index aufnimmt. Wenn ich so durch die Daten gucke, scheint es zumindest für barrier=gate und barrier=toll_booth durchaus sinnvoll, das mal zu ändern. Der Missbrauch in Form von name=Gate scheint sich auch in Grenzen zu halten.
Bezüglich des Namens gehört ‘Tor 3’ auf keinen Fall in irgendein addr:*-Tag. Es ist nicht Bestandteil der offiziellen Addresse, sondern benennt ein Objekt, das unter der Adresse zu finden ist. Die Firma REYHER würde man in obrigem Beispiel ja auch nicht in ein addr:*-Tag verschieben. name=Tor 3 passt schon. barrier=gate + ref=3 wäre theoretisch besser, weil man dann auch Übersetzungen machen könnte. Allerdings praktisch wird das keiner so weiterverarbeiten. Da der barrier-Node geografisch auf den Firmengelände (also dem benannten landuse=industrial) zu finden ist, kann der Geocoder dann auch einfach ableiten, dass Tor 3 zur Firma REYHER gehört. Keine weiteren Angaben nötig.
1 Like
m.E. will man da eher keine Übersetzungen machen, das ist ein Name 
Das steht z.B. teilweise auf Straßenschildern, und kann nur erkannt werden wenn man es nicht übersetzt (oder wenn der Nutzer es rückübersetzen kann, aber dann braucht er auch keine Übersetzung)
Und wie bereits geschrieben, Tor 3 bezeichnet nicht unbedingt ein barrier=gate sondern (wenn man an eine große Fabrik und einen wichtigen Eingang denkt) vielmehr einen größeren Bereich, vermutlich überdacht mit Einfahrten und Fußgängereingängen, Platz für Kontrollen und Security, vielleicht auch Badgelesern, etc. also mehrere barrier=gate im OpenStreetMap-Sinn
plus die 20 Zeichen die man noch tippen muss 
Ich weiß nicht, ob barrier da sinnvoll ist. Ich fände es gut wenn entrance-Nodes gefunden würden bei der Suche (können dann ja auch einen Namen und/oder ref haben), aber ein Industriegelände kann potentiell sehr viele Gates haben. Ich weiß nicht, ob man die bei einer Suche finden möchte, ist vermutlich Geschmackssache.
Aber wenn mich das Routing fragen würde: Möchtest Du zum “Haupteingang”, oder “Serviceingang”? Dann wäre das bei mehr als einem Eingang definitiv sinnvoll. Wenn hingegen alle Tore erscheinen, müssten zum Auseinanderhalten schon wirklich alle eine Referenz haben 
Bei großen Betriebsgelände ist das so üblich.
Ja, was das Haupttag betrifft, wäre ich da auch eher für entrance=* + name=*. Der Name ‘Tor 3’ bezieht sich ja eher auf die Funktion des Eingangs und ist unabhängig vom Typ der tatsächlich installierten Barriere (der dann noch mit barrier=* zusaẗzlich spezifiziert werden kann). Nebenbei ist entrance=* auch gleich so definiert, dass es auf dem Umriss des Gebäudes/Geländes sein muss, wo es hineinführt. Das ist wichtig, um es richtig auswerten zu können.
entrance ist aber auch gerade noch kein Tag, was Nominatim auswertet. Es wäre also die Frage, ob man das eine oder andere (oder beide) einbaut. Im Augenblick scheint ein zusätzlicher entrance-Tag an benannten barrier=gate eher die Ausnahme zu sein.
man kommt letztlich immer auf das selbe:
bzw. je nach Funktion ein anderes value
bzw. müssen nicht alle Eingänge einen Namen/Referenz haben sondern nur die Relevanten 