Przejdź do głównej zawartości



I am looking for a way of making an API call and obtain a list of routes that started within a given location and ended within a given location:

Inputs or columns from data table

Input variable the departure place: Lat range and Long range Input variable for arrival place: Lat range and Long range Input variable (range) for the duration of the trip Filtering per vehicle type, avoid certain routes per multiple variables….. Timespan for the search (data start and date end).

Output:

List of all the trips existing for the above, including :

date and times polyline format if possible Name of roads, turn left/right Speeds on the streets (optional)

Does anyone know if at all possible?






Bing StreetSide to odpowiednik Google Street View, który można używać do mapowania w OpenStreetMap. Istnieje plugin MicrosoftStreetside do JOSMa, ale niestety u mnie nie działa ze względu zależność od JavaFX/widoki 360.

Poradziłem sobie za pomocą użycia pluginu Utilsplugin2.
  • Edit => Preferences (F12) => Utilsplugin2 settings
  • Należy dodać nowy wiersz klikając z nazwą Bing StreetSide oraz url https://www.bing.com/maps?cp={#lat}%7E{#lon}&lvl=19.0&style=x.
    W razie problemów można edytować plik customurl.txt. Dla Linuksa z Flatpakiem jest on w ~/.var/app/org.openstreetmap.josm/data/JOSM/plugins/utilsplugin2/customurl.txt.
  • Należy wybrać Bing StreetSide w Data => Select custom URL
  • Teraz można otworzyć Bing StreetSide za pomocą Data => Open custom URL (Shift+H)
Jeżeli w danym miejscu jest dostępny StreetSide to zostanie otwarty. Jeżeli nie to otworzy się mapa z ulicami na niebiesko w miejscach, gdzie jest dostępny.


Produced by Anil Üçtepe; Successful producer Anıl Üçtepe, “Electronic Music is Popular After the Pandemic” evaluated the position of electronic music after the pandemic and its effects on the music world. Producer Anıl Üçtepe explains; “After the pandemic, electronic music is in vogue. The basis of this situation I think there are two reasons. The first is due to the pandemic. announced all over the world The Corona Virus pandemic has caused everyone to stay away from their social life and to close in on themselves. it happened. With the decrease of the effects of the pandemic, a search for a new living space was started. electronic music The second reason why it has received more attention after the pandemic is related to the nature of electronic music. It is purely entertainment-oriented and offers the opportunity to be spiritually connected to the purest form of music. this is our It was what we needed most after the pandemic. Therefore, I can say that the interest has doubled.” to their statements gave place. “Pandemic Away, Electronic Music Unites” The relationship between pandemic and electronic music by Anıl Üçtepe; “The pandemic has, above all, distanced people from each other. humanity’s best This was the main effect. In addition to the physiological effects of the disease, the sociological effects also cause great destruction. created. It is also said to have great psychological effects. All factors Considering this, we can see more clearly that people need to hold on to something in order to have fun. Electronic music, due to its adaptability to the digital world, is accessible to a much wider audience. achieved success. While the pandemic is tearing people away from entertainment, electronic music has made this pursuit of entertainment oversupplied. If I had to roughly evaluate the relationship between the pandemic and electronic music; ‘Pandemic distanced them away, and electronics united them by removing the distances between them.” in his words He stated that electronic music offers an alternative to the sociological and psychological effects of the pandemic. “There is Fun in the Nature of Electronic Music” In evaluations about the nature of electronic music Producer Anıl Üçtepe in his statements; “Electronic music is inherently fun and pandemic I attribute this much interest to this situation. electronic music; into action It has entertaining, action-initiating, entertaining and satisfying data. All this after the pandemic It’s what we all need the most. Get away from living in our homes and take a breath outside When we tried to buy it, what we were looking for started to be entertainment. Here is electronic music, in accordance with its natural structure. it can more than meet the demand for entertainment.” He placed his words.










Visiting new places can be incredibly exciting and rewarding. It allows you to expand your horizons, learn about different cultures, and experience new things. It can also be a great opportunity to open new roads for yourself and others. Exploring uncharted territory can lead to personal growth and the discovery of new opportunities. It can also inspire others to do the same, leading to a ripple effect of exploration and discovery. Traveling can also help to break down barriers and create a deeper understanding and appreciation for the world and its inhabitants. Overall, visiting new places is a wonderful way to explore, learn, and grow.




Querying elements from osm and doing practical things with them is really a useful and fun way of code “hacking” for me. In this case, I wanted to show farmers markets with a reactive map like leaflet like I’ve done before in my journal entries. In this case, I wanted to make it easy to browse the times, seasons, and contact info for farmers markets in the Anchorage, Alaska area. I think with some refinement this map could be useful to sellers and buyers to determine which farmers markets they can fit into their schedules.
library(tidyverse)
library(osmdata)
library(leaflet)
library(htmlwidgets)


marketplace <- opq(c(xmin = -150.494625, ymin = 60.771028, xmax = -148.866047, ymax = 61.550720)) %>%
  add_osm_feature("amenity", "marketplace") %>%
  osmdata_sf()

marketplace_points <- marketplace$osm_points

greenLeafIcon <- makeIcon(
  iconUrl = "https://leafletjs.com/examples/custom-icons/leaf-green.png",
  iconWidth = 38, iconHeight = 95,
  iconAnchorX = 22, iconAnchorY = 94,
  shadowUrl = "https://leafletjs.com/examples/custom-icons/leaf-shadow.png",
  shadowWidth = 50, shadowHeight = 64,
  shadowAnchorX = 4, shadowAnchorY = 62
)

content <- paste(sep = "<br/>",
                 paste0("<b><a href='", marketplace_points$website,"'>", marketplace_points$name, "</a></b>"),
                 paste("<i>", marketplace_points$description, "</i>"),
                 #paste(marketplace_points$addr.housenumber, marketplace_points$addr.street),
                 #paste(marketplace_points$addr.city, marketplace_points$addr.state, marketplace_points$addr.postcode),
                 paste("Phone:", marketplace_points$phone),
                 paste("Email:", marketplace_points$email),
                 #paste("Hours:", marketplace_points$opening_hours),
                 paste( paste0("<b><a href='", marketplace_points$website,"'>", "Website", "</a></b>"))
)


(m <- leaflet(marketplace$osm_points) %>%
  addTiles() %>%
  addMarkers(icon = greenLeafIcon,
             popup = lapply(content, htmltools::HTML)))

saveWidget(m, "farmers_markets.html")
#write.csv(marketplace_points, file = "marketplace_points.csv")







Bing StreetSide is alternative to Google Street View which can be used for OpenStreetMap mapping. There is a MicrosoftStreetside plugin for JOSM but it doesn’t work for me due to dependencies of JavaFX/360 views.

I have managed to use it via Utilsplugin2.
  • Edit => Preferences (F12) => Utilsplugin2 settings
  • Add new row with name Bing StreetSide and url https://www.bing.com/maps?cp={#lat}%7E{#lon}&lvl=19.0&style=x.
    In the case of issues one can edit customurl.txt. For Linux/Flatpak it’s located at ~/.var/app/org.openstreetmap.josm/data/JOSM/plugins/utilsplugin2/customurl.txt.
  • Choose Bing StreetSide in Data => Select custom URL
  • Now you can see Bing StreetSide via Data => Open custom URL (Shift+H)
If StreetSide is available at given location it will be displayed. Otherwise map is shown with streets colored blue where it’s available.


Das Thema ist mir zu komplex, um es (gleich) in englisch zu schreiben. Ich bin auch kein Experte, kenne nicht mal die Probleme und Notwendigkeiten so genau. Das hier ist also eher ein Brainstorming mit einigen Schlagworten:
  • Anything will be an area
  • There has always be Vector Tiles
  • Don’t tag vor the Vector Tiles
  • Make the problem to the solution
Area als neuen Objekt-Typ ist nur Tagging-Sugar, die Verpackung wird einsichtiger, der Inhalt bleibt. Ein Kreisverkehr braucht kein area=no mehr, der Spielplatz keine identischen End-Nodes. Trotzdem bin ich dafür. Einige Editoren haben Areas ja auch schon im Interface. Ich sehe in Zukunft immer mehr Areas, auch für Wege. Am Ende ist jeder Fleck Erde Teil irgend eines Areas. Das ist gut für zoomed Rendern, für Rollstuhl-Karten und 3D Rendern. Es ist nur schlecht für rooting; vielleicht sollte im Way-Object eine Hilfe sein, eine Liste zu den anschließenden Wegen.

Vektor Tiles sind im Kern geordnete Informationen für ein Gebiet. Die brauchte man auch schon bei den ersten Bitmap-Renderern. Aus der Tagging-Anarchie wurden, und werden, Objekte in Layer gefiltert. Und dabei wird entschieden, was überhaupt sichtbar wird! Erst im nächsten Schritt werden die Objekte zu sichtbaren Linien, Flächen oder 3D Objekten. Daher dürfen Vektor Tiles nicht das aussehen festlegen und auch nicht bestimmen, was auf die Karte kommt. Allerdings gibt es “normale” Objekte, die jeder braucht und Seltene für Spezial-Karten. Mein Ansatz wäre: Immer zwei Tile-Dateien bereit zu stellen, eine die kompakt alles “normalerweise” notwendige enthält und eine mit wirklich dem ganzen Rest; schräge Sachen notfalls in einen Layer “sonstiges”. Den muß der Rendere dann nach dem Tagging der Objekte selbst sortieren.

“Don’t tag for the renderer!” sollte jeder kennen. Wird das in Zukunft auch für die Erstellung der Vektor Tiles gelten? Denn dabei wird schon viel geprüft und entschieden. Ein Editor könnte diesen Schritt transparent machen und das Objekt darstellen, wie und wo es in Tiles erscheinen würde. Dann ist es nicht mehr weit, bis man “direkt” in der Tile Editiert. Am Ende könnte das bisherige Tagging-Durcheinander komplett entfallen.

Aus dem offenen Tagging eine Zuordnung zu den Render-Layern zu schaffen ist auch heute schon notwendig. Allerdings kann hier jeder Renderer machen was er will. Wenn das schon für die Vektor-Tile gemacht wird, wird es vereinheitlicht/zentralisiert. Die meisten, aber nicht alle wird das freuen, erst recht, wenn das dann schon im Editor erzwungen wird. Nein, freie Tags müssen bleiben. Auch wenn die Vector-Tile die nicht “brauchen” kann, müssen sie mitgenommen werden. Der Renderer hat dann das Problem aber auch die Freiheit.
Zurück zum Data Model

Die Way-Nodes als Liste in das Way-Objekt scheint mir ok zu sein. Wenn der Weg jetzt einen Zebrastreifen hat, ist das ein eigenständiges Node-Object. Oder nenne wir es vielleicht gleich POI-Object! Nur hat dieses dann keine eigene Geo-Position sondern eine Referenz auf den Way und in die Liste dort.

Die Object IDs machen Probleme? Können wir sie vielleicht ganz los werden? Ich kann mir nicht vorstellen, das jeder Renderer immer alle World-Objekte scannt um die aus dem benötigten Gebiet zu finden; da gibt es schon Indizierungen, 2D Bäume oder so was. Ist das im Grunde genommen nicht schon eine Einteilung in Tiles? Wenn wir das Datenmodel schon so gestallten, dass die Objekte in Tiles-Datensätze sortiert sind würden die erwähnten Rechenprobleme würden doch entfallen. Ja, an den Grenzen gibt es viel Hirnschmalz einsetzen. Ds muß ja jetzt jeder Vektor-Tile-Builder auch schon schaffen.

Die Way-IDs sind also eher kleine Indices in die Tile-Lokale-Datenbank. Node IDs braucht es garnicht mehr? Zum Karten Rendern vielleicht nicht, aber für Busslinien etc. schon. Referenzen in Relationen brauchen ggf. neben der Objekt-ID auch die Tile-“ID”. Wenn die OSM-Objekte schon in Tiles sortiert sind kann man sie gut auf verschiedene Rechner verteilen. Editieren im Datensatz aktualisiert quasi sofort die Vektor Tile.

Natürlich sollte der editierende Mensch nicht auf die Tile-Grenzen achten müssen. Ja aber wie sollte dann das OSM-API aussehen? Immer noch nur lat/lon oder schon Tile-bezogen? Denkbar ist beides. IDs werden weiter benötigt. Wenn sie aber schon “Tile.Nr” sind, muß der Editor das auch können. Und wenn ein Objekt über die Tile-Grenze geschoben wird?! Wenn ein Way über nicht nur ein bisschen über die Tile-Grenze ragt? Wenn der oben genannte Zebrastreifen ausgerechnet in der benachbarten Tile ist? Vielleicht brauchen Tiles einen gewisse Überschneidungsbereich und wenn der nicht reicht, wird der Way automatisch gesplittet in Zwei. Wenn eine Relation POIs in ganz Europa auflistet? Sind Tile.ID stabile Referenzen? Als Byte-Offset nicht; und ein Objekt-Index nur, wenn gelöschte Objekte nicht neu vergeben werden. Sollten Objekte besser Rückwärts-Referenzen zu ihren Relationen haben?
So einfach ist das alles nicht, wie ich das hier erträume !!!

Welches Zoom-Level meine ich? Na so 18 vielleicht? Dann kommt man schnell an einzelne Daten. Und wenn die Dateien zu klein und zu viele werden kann man je 4 oder 16 Zusammen fassen, aber so, das nach dem Laden die einzelnen (PBF-)Teile wieder unabhängig verarbeitet werden können. Ob man das auch bis zum World-File treiben sollte? Warum nicht? Über Changesets möchte ich aber lieber nicht nachdenken.

Da war noch die Küstenlinie der Kontinente. Erst mal Teilstücke als Way. Mit Links zu den Nachbarstücken? Relationen für die Teile eines Bezirks oder Lands? Super Relationsbaum bis zu “Australien”?

Ich lege diesen Text jetzt mal hier offen ab; er kann sich aber noch ändern!





Der “gute Wanderweg” ist ja fast immer ein Pfad, Tracks sind nicht so beliebt und dürfen auch bei Premiumwegen nicht zu oft vorkommen. Und bei Pfaden fehlen mir oft: Ein Tag, dass die Attraktivität einstuft, unabhängig von den schon vorhandenen Tags (s.u.). Da könnten eingehen: schöne Aussicht, Schatten im Sommer, etwas Licht im Winter, interessante Wegführung, Nähe zum rauschenden Bach. Wie man so etwas definieren könnte, ist nachzulesen auf den Seiten der Weg-Zertifizierer (also Wander-Institut etc.).

Wir haben ja eigentlich schon eine ganze Menge an Tags, die die Attraktivität beschreiben können: die Breite, die glatte Wegoberfläche und die Sichtbarkeit (Visibility). Hier scheint mir der Haken zu sein, dass die meisten Renderer diese Tags gar nicht auswerten. Und wozu trägt man Tags ein, wenn sie in den Karten nicht auftauchen? Änderungen am Rendern könnte also helfen.

Trotzdem meine ich, dass es für Apps wie Komoot nicht einfach ist, einen “schönen” Wanderweg per Autorouter zu erzeugen. Und die Zukunft der Wanderkarte liegt ja irgendwo bei diesen Apps.

Ich würde mir ein neues Tag für Premium-Eigenschaften wünschen, das widerspiegelt, ob ein Pfad von einem normalen Wanderer als “Traumpfad” oder als “langweilig und öde” eingestuft wird - also eine Art von Grade 1 - Grade 5.




Heute war ich mal seit längerem wieder mappen, mit StreetComplete. Dabei ist mir aufgefallen, dass hier in Holzlar schon viel gemappt wurde :) Gibt es eigentlich in Holzlar eine kleine Mapping-Community?






Auf den ersten Blick sieht es im Oktober 2022 so aus, als wäre das Gebiet Vorholz zwischen Alzey und Kirchheimbolanden eine 1a Wandergegend. Wenn man sich dann die Relationen der Wege ansah bekam man Zweifel: Viele Lücken. Und daraus folgend auch Sackgassen, da freut sich der Wanderer.

Ich habe in der VG Alzey-Land angerufen und von einer sehr kompetenten Mitarbeiterin erfahren, dass sich bei der Gemeinde schon der Förster gemeldet hatte, weil er verzweifelte Wanderer im Wald sah, die sich nicht zurechtfanden. Prima. Und dann sagte sie, dass eigentlich alle Wege abgekündigt seien, evtl. könnten einige der NW-Wege bestehen bleiben, die R-Wege und der Kneipp-Napoleon würden eingestellt.

Gerade um den letzteren (K-N) ist es schade, denn der hat schöne Schilder, ist aufwändig gemacht. Er ist fast der Hauptweg im Gebiet. Aber er hat auch viele Sackgassen in der Relation.

Was tut nun der OSM-Mapper? Ich habe für die NW-Wege die Relationen repariert, da war noch eine Karte des Soll-Zustands zu finden. Die R-Wege bekamen das Präfix “Disused”, der K-N wurde etwa zur Hälfte gelassen. Damit ist keine Arbeit endgültig weg, aber die Karten werden von Karteileichen befreit.

Warum keine Reparatur der Relation für R und K-N? Es sind keine Soll-Zustände mehr zu finden, damit müsste die Reparatur die Sackgassen komplett löschen. Damit wird aber eine echte Reparatur immer schwieriger. Oder aber man muss im Feld suchen, wo man noch vollständige Beschilderungen findet, dann geht es. (Letzte Änderung am 14.1.23, die Änderungen an der OSM sind jetzt drin)



Mein Sohn Linus ist inzwischen sieben und ich schaue mal wieder hier rein…

Ich bin inzwischen ständig mit OSM unterwegs. OSMAnd hat alle früheren Navis abgelöst, auch für die Fahrt in den Urlaub.

Okay, keine Verkehrsinfos und Langzeitbaustellen stehen auch oft nicht in der Karte. Aber seit ich die Funktion zum temporären Sperren einer Straße in OSMAnd gefunden habe, macht mir das auch keine Kopfschmerzen mehr.

Nun muss ihc nicht mehr “gegen” OSMAnd fahren, wenn ich einer Baustelle ausweiche.

Streetcomplete ist ebenfalls sehr oft an. Ich liefere im Moment Tageszeitungen in Beckum aus, und wo es die Zeit zulässt, aktualisiere ich auf dem Weg Kartendaten. Straßenoberflächen, Geschosszahlen von Gebäuden, Hilfen für Blinde an Übergängen, etc. etc.

Es gibt noch so viel zu tun … Geil!