Re: [Talk-at] Gefahr durch Internet-Bergrouten
Hallo, kleine Anmerkung: opentopomap.org berücksichtigt sac_scale, jedenfalls in 3 Gruppen (T1-2 oder gar nix / T3-4 / T5-6 oder via_ferrata_scale>0) mit unterschiedlicher Punktierung. trail_visibility wird auch ein bisschen dargestellt durch blassere Punkte. Hier eine Gegend mit allen Arten von sac_scales: https://opentopomap.org/#map=16/47.44846/11.78192 Hier ein Weg, der zwischendrin trail_visibility=bad ist: https://opentopomap.org/#marker=16/47.56030/11.56659 Diskussion dazu gabs hier: https://github.com/der-stefan/OpenTopoMap/issues/66 Is halt ein bisschen schwierig, das alles dazustellen, wenn man nicht gerade eine reine Bergwegebene mit roten Strichen über die Karte legen will, mit eigener Symbolik für Schwierigkeit und kleinen Leitern für Klettersteige. Diskutiert wurde das hier: https://github.com/der-stefan/OpenTopoMap/issues/66 Noch eine Karte, die es darstellt wäre der Renderer von Komoot, laut Legende in der Abstufung T1/T2-3/T4-6 https://www.komoot.de/plan/@47.4486458,11.7846715,16z und eigenen Symbolen für Klettersteige: https://www.komoot.de/plan/@47.2692735,11.2701125,19z Grüße Max Am 19.09.20 um 15:29 schrieb Marcus MERIGHI: > hallo, > > fuer mich ist das thema nicht eingeschlafen... hatte aber einiges > nachzudenken: > > 1) ich kenne jetzt sechs faelle, in denen menschen auf von mir >eingetragenen steigen in bergnot gerieten. zum (und mit) glueck in >keinem fall (ganz) schlimme folgen. > 2) ich tagge, soweit mit OSM-tags moeglich, so genau es geht. > 3) wenn ich weiss, dass mein handeln (mapping) unerwuenschte folgen >(bergnot) hat, kann ich dann mein handeln fortsetzen? > 4) das mapping ist nicht das problem, sondern das rendering. >wenn markierte wanderwege auf der gerenderten landkarte gleich >aussehen, wie wilde(ste) steige, dann fuehrt das in die irre >(siehe 3!). > 5) ich moechte weitermappen, muss also versuchen, das rendering zu >verbessern. > > ich habe mir zu diesem zweck eine liste mit mir bekannten renderern > angelegt und mir angesehen, ob diese unterschiede in den tags sac_scale > und trail_visibility darstellen (nix=keine unterscheidung): > > +++ > ( https://wiki.openstreetmap.org/wiki/List_of_OSM-based_services ) > > openstreetmap.org nix > geofabrik.de standard nix > > thunderforest.com/gravitystorm > https://www.thunderforest.com/maps/outdoors/ gut > https://www.thunderforest.com/maps/opencyclemap/ nix > https://www.thunderforest.com/maps/landscape/ nix > https://www.thunderforest.com/maps/transport/ nix > > wanderreitkarte.de gut > outdooractive.com OSM (free) strichstaerke > öpnvkarte.de nix > opentopomap.org nix > hikebikemap.org nix > mapy.cz nix > bergfex.at OSM nix (und alt) > +++ > > bitte gebt bekannt was ich alles vergessen habe! > > mein plan ist, die "hersteller" freundlichst anzuschreiben und auf die > problematik hinzuweisen. > > ich wuerde das schreiben zuvor hier vorlegen. > > was sagt ihr zum vorhaben und zu den details? > > pfirt'eich, marcus > > sk...@ostblock.org (Stefan Kopetzky), 2020.08.29 (Sat) 18:34 (CEST): >> On 27.08.20 19:37, Marcus MERIGHI wrote: >>> Wir hatten hier schonmal eine Diskussion, was in Sachen weglose Anstiege >>> zu bedenken ist: >>> >>> http://osm-talk-at.1116557.n5.nabble.com/Talk-at-Weglose-Anstiege-auf-Berge-eintragen-td2497.html >> >> War eine gute Diskussion, damals. >> >> Das damalige Beispiel (uvm.) hat sich irgendein "User" mit genau einem >> Änderungssatz zu Herzen genommen und da einfach vor kurzem wild >> reingelöscht, was er(?) für keine offiziellen Wege hält >> https://www.openstreetmap.org/changeset/88569171), was ich persönlich >> so, ganz ohne Diskussion für eine grobe Missachtung der Arbeit der >> Vormapper und wg. dem Sockenpupperlaccount, eigentlich für eine Sauerei >> halte. >> >> Ich wär hier für einen Revert. Nicht dass die Wege vorher unstrittig >> wären (access=private, width=0 etc.), aber so ists "keine Art", wie man >> hier sagt. >> >> Lg, >> Stefan > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at > ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Overpass-Integration meldet seit kurzem "Bad-Request" ohne Code-Änderung
Ich hatte heute das gleiche Problem. Bisher wurde das hier akzeptiert: [out:xml][timeout:3000];(node["mountain_pass"="yes"]; node["natural"="saddle"];node["natural"="notch"]; node["natural"="col"]);out body;>;out meta qt; seit 3-7 Tage bekam ich einen Fehler 400 zurück. Lösung war ein zusätzlicher ";" hinter "col"] und vor der Klammer [out:xml][timeout:3000];(node["mountain_pass"="yes"]; node["natural"="saddle"];node["natural"="notch"]; node["natural"="col"];);out body;>;out meta qt; Keine Ahnung, ob das schon immer falsch war und akzeptiert wurde, Gefunden habe ichs durch Vergleich mit dem Ergebnis des Wizards von Overpass Turbo. Grüße Max Am 06.05.2018 um 23:20 schrieb dktue: > Hallo, > > auf der TüBus-Karte [1] funktioniert seit kurzem -- obwohl der Code > nicht geändert wurde -- die Overpass-Abfrage nicht mehr. Der Request > wird mit Status 400 beantwortet. > > Weiß jemand, was sich geändert hat und was ich ändern müsste, damit die > Abfrage wieder funktioniert? > > Viele Grüße > dktue > > [1] http://tübus-karte.de > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgis osm2pgsql issue - zusammenhang
On Thu, 7 Apr 2016, Tobias wrote: Hi, das verwenden den Bayern exports hat tatsächlich mein problem behoben. Was ich noch nicht verstehe ist warum ein falsches poly file beim zuschnitt von Niederbayern auswirkungen auf den Landkreis Landshut hat? Die Niederbayern Geometrie und die Landkreisgeometrie sind doch 2 total unterschiedliche Dinge und km weit auseinander. Wie hängt das zusammen? Gruß und Dank Hi, die (Aussen-)Grenze des Kreises Landshut zu den Kreisen Mühldorf, Erding und Freising ist auch die Grenze zwischen Niederbayern und Oberbayern. Da liegen keine km dazwischen, die liegen auf diesem Stück aufeinander und wenn an der Stelle was kaputtgeht, fehlt dir eben dieser Kreis und der Regierungsbezirk. Deine Punkte sollten jetzt neu auch in Niederbayern (Relation 17593) liegen, dessen Grenze dir vorher gefehlt hat. Ich hab meinen Import schon wieder gelöscht ohne mir die Geometrie anzusehen, aber ich glaube, der Flächeninhalt der kaputten Relation 62657 (Kreis LA) war genauso gross wie der der Relation 62484. 62484 ist die Grenze der kreisfreien Stadt LA, die nicht zum Landkreis gehört und deshalb als "inner" in der Relation 62657 davon ausgenommen ist. Ich vermute, osm2pgsql ist über den offenen äusseren Ring von 62657 gestolpert, hat dann "inner" und "outer" verwechselt und Du hattest zwei deckungsgleiche Polygone für Kreis und Stadt. Dazu passt auch das falsche Ergebnis zum Node 369696958, der sowohl im Kreis als auch in der Stadt lag.. Grüße Max ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] postgis osm2pgsql issue
Am Mittwoch, den 06.04.2016, 20:41 +0200 schrieb Tobias: > Hi, > > ich habe jetzt die Datenbank gedropt und auch das postgis template neu > angelgt > > ... Ich hab auch das Niederbayern-Extrakt importiert und komme auch auf Dein falsches Ergebnis. Vielleicht kann jemand bestätigen, dass im aktuellen Extrakt der Geofabrik der Way 192087308 fehlt. Der ist Teil der Grenze des Landkreises Landshut und von Niederbayern. Falls das Extrakt wirklich kaputt ist, würde ich das Bayern-Extrakt empfehlen und daraus ein grosszügiges Rechteck um Niederbayern ausschneiden. Grüße, Max ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] query in postgis osmosis
Am Dienstag, den 05.04.2016, 20:22 +0200 schrieb Tobias: > > für eine andere Bäckerei: > http://www.openstreetmap.org/way/369696958 > welche Direkt in Landshut liegt bekomme ich mit dem Query: > > SELECT DISTINCT area.osm_id, area.name, area.postal_code > FROM planet_osm_polygon AS area JOIN planet_osm_polygon AS element ON > ST_CONTAINS(area.way, element.way) > WHERE element.osm_id = '369696958' AND (area.postal_code is not null OR > area.boundary = 'administrative') > > folgendes Ergebnis: > -62657;"Landkreis Landshut";"" > -3149176;"";"84030" > -62484;"Landshut";"" > Hi, dann ist aber was schief gegangen mit dem Landkreis. Die Bäckerei kann nicht in Relation 62484 und in Relation 62657 liegen. Landshut ist eine Insel im Landkreis. In meiner DB bekomme ich auch die vermutlich richtigen Ergebnisse (ohne PLZ, die habe ich nicht als eigenes Feld) SELECT DISTINCT area.osm_id, area.name FROM osm_polygon AS area JOIN osm_polygon AS element ON ST_CONTAINS(area.way, element.way) WHERE element.osm_id = '369696958' AND ( area.boundary = 'administrative'); osm_id | name +-- -17593 | Niederbayern -62484 | Landshut osm=> SELECT DISTINCT area.osm_id, area.name FROM osm_polygon AS area JOIN osm_polygon AS element ON ST_CONTAINS(area.way, element.way) WHERE element.osm_id = '142034442' AND ( area.boundary = 'administrative'); osm_id |name -+ -190875 | Altdorf -62657 | Landkreis Landshut -17593 | Niederbayern Grüße, Max ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Straßenbahnen
Am Samstag, den 23.05.2015, 13:04 +0200 schrieb Friedrich Volkmann: On 23.05.2015 12:27, Michael Maier wrote: und das Tiles@Home Projekt eingeschlafen war. Das war nicht eingeschlafen, das hat bis zuletzt bestens funktioniert, und ich hab nie einen Aufruf gesehen, dass mehr Leute gebraucht werden sich zu beteiligen. Es gab auf diversen Listen die Ankündigung [1], dass die ETH Zürich keine Lust mehr hat, Server und Datenverkehr zu betreiben. Da hätte sich jemand melden können, der einen Nachfolger betreiben und betreuen wollte/konnte. Wirklich gut funktioniert hat es zum Schluss allerdings nicht mehr. Das Problem war nicht die Anzahl, sondern die Leistung der Renderer. Unsere Innenstädte lagen ziemlich lange in der Warteschlange, bis sich ein kräftiger Client fand, der sie rendern konnte. Entweder wurden sie aufgrund zu grosser Komplexität gar nicht erst angenommen oder der Client lief in Speicher- und Zeitlimits und gab den Job zurück. Grüße, Max [1] https://www.mail-archive.com/tilesathome@openstreetmap.org/msg06184.html ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Ein Wunsch für openstreetmap.de
Am Donnerstag, den 05.03.2015, 17:55 + schrieb Sven Geggus: Heinz-Jürgen Oertel hj.oer...@t-online.de wrote: Im übrigen, es war ein Wunsch. Für Interessierte an der Geschichte Osteuropas.besonders wünschenswert. Die Lösung im deutschen Stil ist ein Kompromiss und ich finde eigentlich ein ganz guter. Tag zusammen, ich finde auch, den derzeitigen Kompromiss sollten wir lassen. Ziel der Darstellung von name:de ist es, heute gebräuchliche deutsche Namen auf der Karte zu finden, ganz unabhängig davon, ob die Gegend mal von Deutschsprachlern bewohnt war. old_name wäre also das Tag, das eher nicht dargestellt werden soll: Mailand ist üblich, also name:de und soll gerendert werden. Nach Worms im Veltlin wird kaum jemand auf der Karte suchen. Das kann man als old_name:de für historisch orientierte Auswertungen oder Karten erhalten, aber eben nicht auf openstreetmap.de anzeigen. viele Grüße, Max ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebiete bezeichnen
Am Freitag, den 26.09.2014, 10:52 +0200 schrieb Andreas Labres: On 26.09.14 10:05, Fabian Schmidt wrote: Es gibt mindestens eine gelungene Karte mit Labels für Regionen: http://geo.dianacht.de/topo/ , fehlt also nur noch ein geeigneter Umgang mit verschachtelten Regionen. Nett, sehr gelungen! Hohe Tauern... ah, die sieht man wieder nur eine Zoomstufe kleiner, ich nehme an, das ist das Verschachtelungsproblem. Ja, das Verschachtelungsproblem ist nicht wirklich gelöst. Auf der Karte sind nur ca 30 oder 40 Gebirge. Die sind in 3 Gruppen geteilt, 1 Bezeichnungen, die in Zoom9 verschwinden, weil sie dann durch ihre Untergruppen ersetzt werden (Hohe Tauern, Dolomiten) 2 Bezeichnungen, die in Zoom9 auftauchen, weil sie Untergruppen der ersten Gruppe sind (Venedigergruppe, Pragser Dolomiten) 3 Bezeichnungen, die in Zoom 9-12 stehen, weil sie keine Untergruppen haben (Rofan, Stubaier Alpen) Diese Kategorisierung wurde händisch gelöst. Ich musste das nur einmal für ein kleines Gebiet machen und für die 5 Fälle der 1. Gruppe schreibe ich kein Programm. Müsste ich das schreiben, würde ich die Lage abfragen und ratlos vor Gebieten stehen, die sich ganz unhierarchisch überlappen. Und schön wäre natürlich, wenn über allem A L P E N stünde Das wäre vermessen für eine Karte, die nicht mal die Hälfte der Alpen abdeckt ;) Grüße, Max ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eine politisch korrektere Version des deutschen Kartenstils
Am Freitag, den 18.07.2014, 17:38 +0200 schrieb Johannes: Schade, dass das nicht mit Arabisch oder Hebräisch ging (kaputte Reihenfolge Zeilenumbruch bei Wechsel der Schreibrichtung). Hi Johannes, das Problem war grösser, den Zeilenumbruch hätte man einfach vermeiden können. Rechts-Links-Schreiber haben glücklicherweise eine Vorliebe für kurze Namen, ganz im Gegensatz zu Deutschen. name:de umbrechen und name in eine Zeile schreiben sah eigentlich ganz gut aus. Ausserdem gibt es einen Patch für Mapnik, der das Problem mit dem Umbruch gelöst hätte[1]. Aber: Ein wesentliches Merkmal des deutschen Stils ist ja neben den Farben und der Verwendung von name:de auch die Transliteration. Die wird überall dort eingesetzt, wo nur ein z.B. arabischer name-Tag vergeben wurde. Falls wir bei Orten mit vorhandenem name:de das Original mit arabischen Zeichen in Klammern setzen, aber bei anderen Orten ohne name:de die Transliteration, führt das zu einem ziemlich eigenartigen Gemisch der Schriften. Falls wir zusätzlich noch name:en und name:int auswerten, kann wirklich niemand mehr nachvollziehen, was warum auf der Karte steht. Ausserdem müsste man eine Schriftart finden, die alle möglichen exotischen Schriften und lateinische Buchstaben schön darstellt... Grüße, Max [1] http://forum.openstreetmap.org/viewtopic.php?id=25843 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Gletscherspalten in OSM?
Am Dienstag, den 17.06.2014, 12:48 + schrieb Joe: Markus Mayr markus4mayr.lists@... writes: Dann ist das Einzeichnen der einzelnen Spalten vielleicht nicht eine so gute Lösung, da dies falsche Präzision vermittelt. Würde nicht das entsprechende Taggen einer Fläche als Gletscherspaltenzone sinnvoller sein? Ein entsprechendes Schema existiert dazu wohl noch nicht? Gletscherspalten haben aber meist eine typische Rissrichtung, die sehr interessant ist und mit Linien gut gezeigt werden können. Diese Stehen meist mit dem Untergrund im Zusammenhang. Da auf Gletschern ansonsten meist nicht viel steht, sehe ich bezüglich der Komplexität eigentlich kein Problem. Schöner wäre vermutlich (aus meiner sicht), es nicht mit Multipolygonen zu machen, sondern einfach über Layer=1 eine Gletscherspalte darüberzeichnen. Karten, die das nicht interessiert, rendern dann einfach den Gletscher ohne Spalten. Ich finde auch, Richtung der Spalten und Lage von Spaltenzonen sind wichtig und sollten auch in OSM nicht fehlen. An der Darstellung der Multipolygonspalten ist nichts auszusetzen. Das kommt ja auch der Darstellung in Alpenvereinskarten oder der ÖK50 auf austrianmap.at recht nahe. So etwas ähnliches könnte man aber auch mit dem schon genannten natural=crevasse erreichen. Ganz ohne Layer, die Spalten sind ja weder über noch unter der Gletscheroberfläche (zumindest die offenen). Da bräuchte man keine schwer wartbaren MPs hinterlassen und könnte die Spalten sogar besonders darstellen oder auswerten. Momentan schaut da ja einfach nur der Untergrund durch und der Rand ist der normale blaue Saum um die Gletscher. Grüße, Max ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Gletscherspalten in OSM?
Am Montag, den 16.06.2014, 17:51 +0200 schrieb Simon Legner: Hallo zusammen, ich bin zufällig auf dieses Multipolygon gestoßen: http://www.openstreetmap.org/relation/1268124 Wird da versucht, Gletscherspalten in OSM abzubilden? Mir kommt das Gebilde etwas komplex vor … Dummerweise geht auch die Geometrie kaputt, wo sich die Spalten schneiden. http://www.openstreetmap.org/#map=19/46.84907/10.76304 Mapnik reagiert mit gefüllten Karos, andere Auswerter könnten andere Probleme haben... Grüße, Max ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Größere Anzahl neuer/falscher Gipfel
Hallo, das Meinungsbild hier scheint relativ klar zu sein: Manuell korrigieren oder reverten. Ich werde die Seite mit den Korrekturvorschlägen fortführen. Den geplanten anschliessenden Import der Korrekturen werde ich aber nicht machen. Die Vorschlagsliste gibt es auch als Text nach Gebirgsgruppen sortiert. Das mag einem Ortskundigen helfen, die fraglichen Nodes in JOSM zu laden und manuell zu korrigieren. Falls jemand revertieren will: Changeset 22348807 und die 21 folgenden Changesets des gleichen Users. Davor hatte er eine 10-monatige Pause vom Mappen, die Einträge vor der Pause sind auf den ersten Blick sauber. viele Grüße, Max ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Größere Anzahl neuer/falscher Gipfel
Hallo, vielleicht hats der eine oder andere von euch schon im Forum gelesen [1], oder selbst bemerkt: Die Gipfel zwischen Stubai und den Leoganger Steinbergen haben sich stark vermehrt. Ein fleissiger Mapper hat da wohl von basemap.at abgemalt und 500 neue Gipfel eingetragen. Gelegentlich auch schon vorhandene Nodes gelöscht und durch eigenen neuen Nodes ersetzt. Dummerweise ist die Hälfte davon kein Gipfel, sondern eine Höhle, ein Flurname, der Name eines Kars. Wir haben also jetzt auch massig Gipfel in den Tälern stehen. Ein Revert wäre zum einen Schade um die vielen Gipfel und Namen, zum anderen hat der Kollege auch viele doppelte Gipfel entfernt, die wir dann wieder in der Datenbank hätten. Ich hab jetzt mal eine Seite mit den fraglichen Gipfeln erstellt [1], wo man sich durch die Gipfel klicken kann und auswählen kann, ob der Node wirklich ein Gipfel ist, oder eher ein place=locality, ein natural=cave_entrance oder ein natural=saddle. Ausserdem kann man angeben, ob der Node gelöscht werden soll, weil er doppelt eingetragen wurde. Letzteres kommt sowohl bei doppelten Gipfeln vor als auch z.B. in Situationen wo eine Wiese bereits benamt ist und dann noch ein Gipfel gleichen Namens eingetragen wurde. Ich dachte, ich lasse die Seite eine Woche so stehen und lasse die Masse entscheiden, was mit dem Node passieren soll. Danach suche ich mir die bestätigten Nodes raus und tage sie entsprechend. Bei allen anderen übernehme ich entweder den Vorschlag Gipfel oder entferne die Tags ausser ele und name. Dann ist der Gipfel weg, es bleibt aber zumindest der Node erhalten, falls ihn ein anderer Mapper findet. Der Vorschlag bei unbestätigten Gipfeln kommt aus einem eher dummen Algorithmus, der nach der Dominanz des Nodes entscheidet, der sollte also nochmal von einem denkenden Wesen bestätigt werden. Falls jemand nicht so lange warten möchte, oder einen Node anders taggen möchte oder verschieben, kann er das gerne tun, ich schaue mir vor der Änderung den letzten Bearbeiter an und lasse die geänderten Nodes in Ruhe. Trifft dieses Vorgehen auf Zustimmung, oder sollen wir lieber die fraglichen Gipfel so lassen, oder doch reverten? Der fleissige Mapper reagiert übrigens nicht, aber er mappt auch nicht weiter. viele Grüße, Max [1] http://forum.openstreetmap.org/viewtopic.php?id=25466 [2] http://geo.dianacht.de/gipfelpflege/ ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
