ich editiere oft das (zumeist englische) Wiki, wenn mir etwas auffällt, allerdings setze ich nie oder nur in seltenen Ausnahmefällen tags auf “deprecated”, weil es dafür selten Konsens gibt (sollte man m.E. auf jeden Fall vorher ankündigen und diskutieren).
Egal was im Wiki steht, mitdenken muss man immer.
Ein besserer Schlüssel als “Windel”=ja/nein wäre z.B. “Wickelmöglichkeit”=ja/nein
z.B. diaper_changing_table=yes/no
@Discostu36: Abgesehen davon dass es einen großen Haufen Arbeit erfordert nutzt so eine Karte in der Praxis ggf. weniger als man denkt:
Beispiel Kinderarzt: In vielen Regionen nehmen die keine neuen Kinder an bzw. nur ein Arzt in der Region. D.h. egal welchen du anrufst, jeder wird dir die Nummer von dem einzigen im Umkreis von zig km geben der aktuell neue Kinder annimmt. Dafür braucht man keine Karte die zudem gar nicht so aktuell sein kann.
Beispiel Kindergarten: Bei uns aktuell 3 Jahre Vorlaufzeit für die Anmeldung, also spätestens bei Geburt. Wer später kommt hat keine Auswahl, braucht also auch keine Karte.
Beispiel Windelwechseln: Das musst du da machen wo es nötig ist. Und wenn es nötig ist geht es fast überall
Beispiel Spielplätze: Die allermeisten sind wenn überhaupt dann ohne hilfreiche Detail-Eigenschaften getaggt. Das nutzt gerade mit Kleinkindern nichts. Daher schauen alle Eltern die ich kenne vor dem Urlaub bei einer bekannten Spielplatzbewertungsseite vorbei.
Beispiel Restaurants: Ich habe in den letzten Jahren praktisch nie ein Restaurant in D erlebt in dem es keine Hochstühle gab, von der Dönerbude bis zum Sterne Restaurant war das kein Problem.
lass dir das “Projekt” nicht schlechtreden, fange einfach an, Probleme lösen sich nach und nach.
Ich würde es eventuell nicht nur auf Babys beschränken, sondern eine Kinderkarte (Babys mit eingeschlossen) machen.
Damit erhöht sich auf jedenfall der Anwenderkreis…
So eine Karte kannst Du Dir mit Mapperkenntnissen und ohne Programmierfähigkeiten zumindest grob in Minuten selbst stricken. Dazu schreibst Du alle key=value Kombinationen hintereinander, die in der Karte auftauchen sollen, und verbindest sie mit " OR ":
amenity=kindergarten OR leisure=playground OR highchair=* OR key4=value4 OR …
Dann gehst DU auf https://overpass-turbo.eu/ Dort zoomst Du die Karte auf das zu betrachtende Gebiet (nicht zu groß) und klickst dann links oben auf “Wizard” In das sich öffnende Fenster schreibst Du diesen Ausdruck und klickst links oben auf “Ausführen”. Ein wenig warten und Deine Karte ist fertig. Hier ist sie für “amenity=kindergarten OR leisure=playground OR highchair=*”: https://overpass-turbo.eu/s/BpZ
Eventuell lohnt sich dort eine Anfrage. Wenn ich es richtig verstanden habe, ist das Teil auch leicht erweiterbar. Man braucht also nicht wieder bei Null anzufangen, insbesondere nicht Webspace für eine neue Karte organisieren und einen Webserver aufsetzen. Zeitweise war das Projekt offline. Die Beschreibung im Wiki ist nicht mehr ganz aktuell: https://wiki.openstreetmap.org/wiki/DE:OpenStreetBrowser
OSM ist nicht nur eine Datenbank für die POI-im-Umkreis-Suche. Das Vorhandensein von Ärzten ist ein Standortfaktor (gegenüber weiteren Anfahrtswegen). Für solche Analysen und manch andere, verrücktere Anwendung ist man froh, dass die Mapper in OSM oft auch nur des Mappens wegen mappen.
Zudem sollte man bedenken, dass solch eine, wenn auch technisch simpel gestrickte Karte, Leuten, die der Außenwirkung des Projekts Schaden zufügen, Wind aus den Segeln nimmt. Denn es sind genau die, die daherkommen und behaupten dass OSM voll frauenfeindlich sei, weil wir ja keine/zu wenig Kinderärzte, Spielplätze usw. mappen. [1]
Viele Grüße
Michael
[1] Ich teile diese Auffassung nicht und halte die Argumente für ziemlich flach und rückwärtsgewandt.
Wenn “die” die Frauenfreundlichkeit an der Zahl der gemappten Kinderärzte und Spielplätze messen, dann könnten wir auch noch auf die vielen gemappten Küchenstudios und Kirchen (klick) hinweisen
Mir schwebt schon länger ein Detailrendering für Spielplätze vor, das eine Symbolisierung des detaillierten playground-Schemas beinhaltet. Idealerweise so wie die waymarkedtrails-overlays. Sowas könnte man in dem Kontext auch angehen.
Finde ich auch einen wichtigen Punkt, war tatsächlich einer der Auslöser, wie ich auf diese Idee gekommen bin.
Ich habe die Wiki-Seite etwas überarbeitet. Auch wenn es noch keine (vollständige) Karte gibt, möchte ich dazu ermutigen, schon fleißig Informationen mit diesen Tags in OSM einzutragen.
Als Admin vom OpenStreetBrowser helfe ich gerne dabei, die Kategorie zu verbessern. Was fehlt denn? Gebt mir am besten eine Liste von Tags Der OpenStreetBrowser ist übrigens - so wie Overpass Turbo - nur ein Frontend für die Overpass API.
Tatsache. Ich hatte nur die Englischsprachige aktualisiert, die Deutsche hab ich vergessen. Mach ich beizeiten.
Die Wiki-Seite hast du ja schon entdeckt. Dort findest du alle Tags, die wir zusammengetragen haben. Die Frage ist allerdings, ob eine „Baby-Karte“ und eine „Kinder-Karte“ nicht voneinander getrennt werden sollten. Denn bei Kindern im Grundschulalter brauche ich den ganzen Windel-, Still- und Kinderwagen-Kram ja nicht, hätte dafür aber evtl. gerne Grundschulen, Freizeitparks, Jugendzentren, Schwimmbäder, bestimmte Arten von sports_centre etc.
Kann OpenStreetBrowser denn grundsätzlich alles, was ich im Wiki-Artikel vorschlage? Also gibt es z. B. die Möglichkeit, einen POI einzufärben, je nachdem wie viele aus einer bestimmten Liste von Tags “=yes” als Wert haben? Dann würde ich evtl. doch anfangen, zu versuchen, auf dieser Plattform das Konzept nach und nach umzusetzen.
Es wurden jetzt am Ende (noch) nicht alle ursprünglichen Ideen umgesetzt. Zum Teil werden sie in einer zukünftigen Version hinzukommen, zum Teil wurden sie aber auch aus unterschiedlichen Gründen weggelassen.
Die Performance, wenn bei angezeigten Markern die Karte bewegt wird, ist noch suboptimal. Wer Erfahrungen hat, wie man das verbessern kann, kann sich sehr gerne einbringen.
Die Wiki-Seite wird gerade von mir vollständig neu geschrieben. Wenn Sie fertig ist, soll sie natürlich alle Tags dokumentieren, die von der Karte ausgewertet werden.
Mithilfe kann natürlich in vielen Bereichen gebraucht werden, zum Beispiel in folgenden:
Bitte entsprechende POIs anlegen bzw. die entsprechenden Tags benutzen. Die Datenlage ist im Moment noch sehr dünn:
Kinderärzte (healthcare=doctor mit healthcare:speciality=paediatrics)
Nein, MarkerCluster reduziert “nur” die Anzahl der unter LL anzuzeigenden Daten erheblich. Es sollte doch bekannt sein, dass mit zunehmender Anzahl von Objekten die Performance des Browsers, der das Zeug ja darstellen muß, extrem nachlässt.
Bei meiner 2. Lösung, die ich wohl bald bei der aS-Karte verwenden werde, erfolgt dagegen das “Clustern” bereits auf dem Datenserver, was noch mehr Leistung bring. Nur ist das nicht gerade einfach. Falls die Overpass-Api sowas kann, wäre das extrem empfehlenswert.
Du liegst richtig. Markercluster habe ich nicht implementiert da bisher auch noch nicht so gewohlt. Die wiedeeholten Requests gegen die Overpass API sind das Problem, denn wegen denen geht die Performance in den Keller. Es existiert dafür schon ein Algorithmus, welcher die Performance deutlich steigert, jedoch ist dieser aufgrund des Issues auf https://github.com/babykarte/babykarte.github.io/issues/37 von mir deaktiviert worden. Mein Algorithmus kann nämlich nichts mit Rauszoomen anfangen und die Daten werden unvollständig. Das ist ein etwas schwierigeres Problem, dass sich eig. einfach lösen ließe, würde man meiner Meinung nach den Request zu Overpass überladen. Allerdings möchte ich eine überproportional lange Request-Url vermeiden. Ich habe aber auch einen workaround dafür gefunden, dieser geht ein Mittelweg zwischen guter Performance bei anderen Interaktionen mit dem Kartenausschnitt und schlechter Performance wie es aktuell bei der Babykarte der Fall ist.
So ein Statement abzugeben, ohne die Software zu kennen, ist mMn etwas gewagt.
Da du die “Schwächen” der Overpass-Api, die für massenhafte zeitkritische Abfragen nicht so richtig geeignet ist, sowieso nicht beseitigen kannst, kannst du zumindest auf der Browserseite was machen.
Ich würde MarkerCluster testen und danach eine Aussage zur Performance machen.
btw: Eine Karte mit hunderten von Symbolen, die sich auch noch überdecken, ist eh nicht verwendbar. Das macht nur bei höheren Zoomstufen Sinn.
Auch hier würde Clustern für erheblich mehr Übersichtlichkeit sorgen.