Dichtgedrängte POIs

Also bei uns ist die Postfiliale am gemeinsamen Eingang mit Supermarkt, Bäckerei und Fleischer. Wenn ich das alles an das Gebäude hefte, überschreiben sich die shop=* - außer dem sind sie räumlich in dem Gebäude aufgeteilt. Selbst ein shop=* mit Postfiliale hat einen abgetrennten Bereich für die Post.

Ich hatte hier den Fall, dass ein Geschäft im Bahnhof gleichzeitig Kiosk, Bistro, Ticketschalter, Paketshop, Bankfiliale, Touristeninformation und Autovermietung ist. Alles in Personalunion in den selben Räumlichkeiten.

Suchfunktion via Osmand, deswegen frage ich. Gibst Du Supermarkt an und bist mit dem Rad unterwegs, dann würdest Du teilweise für drei Tage einkaufen, so leer ist die Karte Wenn man das mit den Postoffices kapiert hat, dann sieht das plötzlich ganz anders aus.

Dass die Welt woanders anders funktioniert, ist für dich nicht vorstellbar? Das sind Dörfer mit 20 - 40 Häusern, die teilweise alle 20km kommen.

Oder sollte die Frage sein: was muss bei Osmand geändert werden, damit er alles findet?

Ich habe gerade in meinem Osmand unter „POIs anzeigen“ den Haken bei „Gemischtwaren- und Lebensmittelgeschäft“ gesetzt, darauf werden sowohl shop=supermarket als auch shop=convenience mit orangen Kullerchen markiert. Ersterer mit Einkaufswagen, letzterer mit Einkaufskorb. Selbsterklärend.

Wenn das Postoffice auch Waren des täglichen Bedarfs führt, gehört shop=convenience dran (ist ja auch, soweit ich sehe). Bei der gezielten Suche nach „Supermarkt“ wird aber wohl nur shop=supermarket gefunden.

Deine Läden markiert mein Osmand alle mit der beschriebenen Einstellung, in Scourie findet er sogar zwei unterschiedliche:

Taggingmäßig würde ich das vermutlich sogar an denselben Node setzen, wenn es eine einzige Einrichtung ist: amenity=post_office + shop=convenience + opening_hours=* etcetera.

–ks

verwendest du dann eine art layer tagging? du brauchst ja irgendwie die 3. ebene um klarzumachen, dass sie sich zwar an zweidimensional an einem ort befinden, aber nicht in der 3… blöd wirds bloss wenn du dadurch dann auf einmal eine Uhr z.B. auf den Ubahnsteig verlegst - wie verhinderst du das?

Ich glaube, da war „übereinander“ im Sinne von „aufeinander“ gemeint, nicht räumlich übereinander. Schließlich geht es immer noch um kleine Dorfläden mit Postschalter, die werden kaum mehrstöckig angelegt sein.

–ks


amenity=post_office_table
ele =1.2+offset(basement)

PS: und ja, ich meine in JOSM einfach die Punkte aufeinander übereinander :wink:

  • Mast

man_made=mast
height=3.2

  • Mülleimer

amenity=waste_basket
min_height=0.5
height=1

  • Uhr

amenity=clock
min_height=2.25
height=2.75
clock:diameter=0.5

  • Überwachungskamera

man_made=surveillance
min_height=2.9
height=3

soviel zum Thema aufeinander übereinander :smiley:

Und wie willst du die zwei unterschiedliche man_made oder amenity auf einem node mit deinen Angaben unterbringen?

nix “ein” node: “vier” (getrennte) nodes übereinander aufeinander :wink:
und wie das funktioniert, hat wambacher ein paar posts weiter vorne schon erklärt…

Das hatte ich vorhin schon mit JOSM probiert… es geht…

node setzen, Key + Value vergeben, node kopieren, node an Quellposition einfügen, einen der Nodes auswählen, Key + Value ändern… und so weiter… Im Prinzip kann man so Punkte “stapeln”. Der JOSM-Validator nörgelt aber (zu recht?) rum…

Sven

wie schon gesagt, der vorschlag ist nicht von mir … aber die “one feature, one osm object” regel besagt, ja, dass es keine mehrere Haupt-Elemente-Tags an einem Objekt geben darf, also muss man “stapeln” (danke für das Wort)

Wer das später mal editieren will, weil der Laden einen neuen Inhaber oder die Uhr eine neue Anzeige hat, wird sich freuen, wie einfach er den richtigen Node selektiert bekommt.

Ja, man kann das machen, wenn man glaubt, dass man für die Ewigkeit mappt und das niemals wieder jemand anzufassen hat.

–ks

Ja, ich weiß, daß ist eine wirklich böse Methode, eben aus diesem Grund… Ich wollte auch nur aufzeigen, daß es prinzipiell geht… und JOSM nörgelt da auch (zurecht?) rum…

…oder man findet in JOSM eine gescheite Möglichkeit, das komfortabel zu erfassen, zu warten und zu verändern. Letztendlich wird es in JOSM mit Linien und Relationen auch gemacht, daß mehrere Elemente lagegleich sind. Bei Linien kann man beliebig viele aneinanderkleben, ohne daß die Tags vereinigt werden. Bei Punkten hingegen nicht… eigentlich nicht wirklich logisch… Aber OSM und Logik… :wink:

Sowas ist aber ein Fall, wo es eigentlich parallel eine relationale Sachdatenbank geben müsste/könnte/sollte, in der die entsprechende Information steckt. Abgrage der Information aus der Sachdatenbank–> Anzeige der korispondierenden Geodatenbankinformationen auf der Karte. Das führt aber zu einem erheblichen Mehraufwand an Rechenleistung bei der Abfrage… und andererseits alles in einer Key/Value - Kombination zu packen, wird auch nicht gehen…

Sven

Selektieren ist nicht schwer, wenn man weiß wie das in JOSM geht. Braucht man ohnehin öfter, weil vielfach mehrere Linien aufeinander liegen. Das Problem wird sein, dass man zunächst gar nicht sieht, dass da noch weitere Nodes drunter liegen.

Darüber wird ein Mapperkollege, der mit iD arbeitet, sicher sehr froh sein. Ich bin höchst beruhigt. </ironie off>

Ich persönich arbeite auch mit JOSM und weiß, wie es da geht. Aber auch mit dieser Selektionsmöglichkeit ärgere ich mich, wenn mich andere dazu zwingen, sie zu benutzen. Beim Erfassen von Wanderwegrelationen zum Beispiel. Sind die ways selbständig, muss ich nur zehn oder zwanzig auf einmal per Anklicken selektieren und kann sie dann in einem Schwung in die Relation kippen. Sind sie mit Flächen verklebt, muss ich jeden einzelnen Way-Abschnitt mühsam mit der mittleren Maustaste aus zehn verfügbaren Optionen (mit landuse-Multipolygonen, versteht sich) herauspicken, das dauert mindestens fünf Mal so lange. Bei einem nicht schlimm, aber mach das mal auf zwanzig Streckenkilometern, dann wirst du wahnsinnig.

Bittebittebitte alles so leicht wie möglich selektierbar halten. Dankedankedanke.

–ks

Ist mir bekannt. Aber dein Gebäude mit allem was es beinhaltet gemeinsam zu taggen kann nur Probleme bereiten. Klar kann ich einzelne Abfragen machen, die sogar gefunden werden.
Ich kann auch einzelne POI in einem Gebäude setzen. Ob nun die Postfiliale 0,5 m neben dem Lotto-Verkauf und dieser 1 m neben dem Tante Emma Laden liegt oder beide einzeln im Gebäude Tante Emma Laden liegen. Ist auf alle Fälle sinnvoller zu editieren und auch auszuwerten und “anzuzeigen”.

Wie genau ist eigentlich ein node in Bezug auf seine Koordinate zum Nachbarnode: 1 mm, 1 cm?
Wie genau können wir den node nach der Koordinate eintragen?

Wie mit 6 m breite Straßen die gemeinsam auf der Wald- und Wiesenkante verlaufen.

Wenn es sich aber nunmal nur um einen Laden (also, ein Schalter, eine Kasse, etc.) handelt, ist es doch Unsinn, mehrere POIs zu setzen. Nein, nicht nur Unsinn, sondern eigentlich grob falsches Tagging für [die Osmand-Suche|whatever]. Denn damit verhindere ich im Zweifelsfall, dass ein Auswerter, der das kann, mir die Möglichkeit bietet, nach Lebensmittelgeschäften [mit|ohne] Postfiliale zu suchen. Vielleicht hab ich ja was dagegen in einem Laden einzukaufen, in dem auch Briefe verschickt werden :stuck_out_tongue: Jedenfalls sollte man nicht nur, weil vielleicht manche Auswerter zu blöd dafür sind (bei amenity+shop geht’s ja meistens noch, bei shop=a;b;c leider seltener…) anfangen, was zu taggen, was da garnicht ist.