Talk:MENTZ GmbH/Modellierungsvorschläge Indoor

Fußwege

Aufzug

Dass bei Aufzügen zwei (oder mehr) Elemente highway=elevator bekommen, widerspricht DE:One_feature,_one_OSM_element. Wie wäre es, nur am node highway=elevator zu lassen, bei den Flächen ist die Information durch levelpart=elevator_platform ja auch schon gegeben. - Species 16:06, 22 December 2015 (UTC)

Danke für den Hinweis, das ist eine gute Idee. Ich warte noch weitere Rückmeldungen ab; wahrscheinlich werden wir es dann zukünftig so umsetzen. -- drolbr_mdv.

Vielen Dank für diese Klarstellung.

Warum seit diesem Edit das Tagging mit area=yes vorgeschlagen wird, erschließt sich mir nicht recht. Das dürfte bei building:part=* überflüssig sein. Beste Grüße, --Marsupium (talk) 15:55, 15 October 2016 (UTC)

Problematische Nutzung von building:part und: Neues Tag für Unterführungen

Der Schlüssel building:part wurde im Zusammenhang mit Simple 3D Buildings erfunden und etabliert, wo er eine klare Bedeutung sowie entsprechende Nutzungsvorschriften hat – z.B. dass diese Flächen innerhalb eines building-Fläche liegen müssen. MENTZ scheint diesen Schlüssel nun in einer abweichenden Bedeutung zu nutzen, etwa für Indoor-Elemente wie Aufzüge, die nur manchmal einen Einfluss auf die äußere Form eines Gebäudes haben, oder auch für Tunnel. Ließe sich da nicht vielleicht eine andere Lösung finden? --Tordanik 11:47, 29 May 2017 (UTC)

Da gebe ich dir absolut Recht. Das halte ich auch für höchst problematisch. Um Unterführungen als Fläche zu modellieren, gibt es by the way mittlerweile das Tag man_made=tunnel (analog zu man_made=bridge), was ich für das Eintragen einer Unterführung als sinnvoll erachte. Aus meiner Sicht kann die Nutzung von building:part=* damit für alle Unterführungen bzw. Teile von Unterführungen, die nicht in einem Gebäude (bspw. einem Empfangsgebäude) liegen, entfallen. Ebenso die Nutzung der überflüssigen area=yes und tunnel=yes, da area=yes für man_made=tunnel implizit ist. man_made=tunnel passt auch deswegen besser als tunnel=yes, weil man_made=tunnel den Tunnel selbst beschreibt. tunnel=yes beschreibt hingegen dass etwas (anderes!) (bspw. ein linienförmiger highway=footway) innerhalb eines Tunnels liegt. area=yes + tunnel=yes würde demnach einfach nur eine Fläche beschreiben, die in einem Tunnel liegt. Das ist so suboptimal. Tja; wenn jetzt doch nur jemand von Mentz hier mitlesen würde... --Lukas458 (talk) 19:53, 12 January 2023 (UTC)

Treppen-Way jetzt mit einem oder zwei Levels?

Die deutsche und die englische Version dieser Seite unterscheiden sich. Laut der deutschen Version soll die Treppe selbst, d. h. der Way mit highway=steps zwei Levelangaben erhalten, also z. B. -1;0 wenn die Treppe die Level -1 und 0 verbindet. Laut der englischen Version dieser Seite soll nur das unterste verbundene Level beim Way eingetragen werden. Ich frage mich nun, was besser ist. Ich würde ja für beide Level plädieren. Dass ist glaube ich auf der deutschen Seite auch nachträglich bereits geändert worden. LG, -- Lukas458. 19:33, 26 June 2017 (UTC)

Ich würde mich dem Plädoyer für beide Level anschließen, da so Kompatibilität mit Simple Indoor Tagging gewährleistet ist. --Tordanik 15:48, 27 June 2017 (UTC)

ref:pt_id

Wieso wird bei den Beacons (übrigens gerade nur auf der englischen Seite eingetragen) ref:pt_id empfohlen, wenn es schon ref:IFOPT gibt?

Hat sich keiner an ref:IFOPT erinnert oder ist es so damit es an Orten mit anderem System verwendet werden kann (es wäre ja in jedem Fall sinnvoll, direkt zu wissen, welche Art von Referenz es ist, muss es unbedingt immer ref:pt_id sein? Kann man anderswo nicht jeweils dann ref:{irgendwas anderes} wenn es nicht eine IFOPT ist nutzen, und sonst ref:IFOPT, statt überall das gleiche ref:pt_id zu nutzen?)?