<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">Am 19. Oktober 2017 um 13:05 schrieb Henrik Vogel <span dir="ltr"><<a href="mailto:raeuberleiter@gmail.com" target="_blank">raeuberleiter@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ich bin stets für one poi= one feature, also aufteilen in 2 nodes.<div class="HOEnZb"><div class="h5"></div></div></blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">es ist halt keine inhärente Eigenschaft, ob etwas ein Feature ist oder nicht, das hängt davon ab, ob der Datenbetrachter es als feature sieht. Eine Hausnummer kann man als feature sehen, oder als Eigenschaft (eines Grundstücks, eines Firmensitzes, etc.).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Ähnlich hier, und meine Interpretation wäre: Bäckerei mit (Eigenschaft) Paketannahme/-abgabe-Funktion für Hermes. Das würde ich evtl. auch davon abhängig machen, wie das organisiert ist: wenn es wirklich 2 Firmen gibt, eine Bäckerei und eine Paket-Annahme und Abgabe station (eigene Kasse bzw. eigene Steuernummer, eigener Firmenname), dann würde ich evtl. auch 2 POIs machen. Wobei es da auch Fälle gibt, z.B. bestimmte Tankstellen, da wird das Benzin mit einer anderen Firma verkauft als Gas, und nochmal eine andere Firma die Dinge aus dem "shop". Trotzdem ist das in OSM besser als 1 node gemappt (zumindest habe ich das bisher so gemacht).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"></div><div class="gmail_extra">Gruß,<br></div><div class="gmail_extra">Martin<br></div></div>