Re: [Talk-de] Änderungen highway=living_street / highway=service + living_street=yes
On 16.11.18 13:13, Martin Koppenhoefer wrote: es gibt auch ein Proposal dazu von 2009: https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:living_street%3Dyes das schlägt aber die Kombination unclassivied/living_street für unbenannte Straßen vor die komplett durch eine verkehrsberuhigte Zone hindurchführen, und service/living_street für unbenannte die das nicht tun. Ich würde da hineininterpretieren, dass es trotzdem immer noch um öffentliche Wege geht, und nicht um private Zufahrten? -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gutachten [war: Re: POIs - Details - Gerichtsurteil ]
On 16.11.18 13:38, sepp1...@posteo.de wrote: Auch der Name des Künstlers hat im Operatorfeld nichts zu suchen, sondern maximal in der Beschreibung zum Kunstwerk, wenn das unbedingt sein muss. Ja, dafür haben wir artist_name und artist:wikidata, operator passt dort wirklich nicht. Ich sehe aber auch nicht, dass irgendwo vorher in diesem Thread jemand Künstlernamen in operator= stehen haben wollte. https://wiki.openstreetmap.org/wiki/Tag:tourism=artwork ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relation in verschiedenen Formaten herunterladen
On 03.09.2018 10:17, Markus wrote: > Wenn ich die ID einer Relation habe, > Wo/wie kann ich die Daten in verschiedenen Formaten herunterladen? > (gpx, shape, json, svg, ... > > Beispiel: > Erlangen, ID=62403 > Simmelsdorfer Rundwanderweg Rot 3, ID=969263 für Wanderwege ist es einfach: https://hiking.waymarkedtrails.org/api/details/relation/969263/gpx -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Linien (Zaun, Grenze, Weg) und Fläche [war: Feature Proposal - RFC - Empfehlung zur Verwendung von Multipolygonen]
On 27.11.18 14:50, Florian Lohoff wrote: A) Wiese = eingezäunte Weide Weidewiese kann grösser/kleiner sein als die umzäunte Fläche. Weidezäune sind meist variabel. Die Grasfläche geht meist über den Zaun hinaus (Wegrand) Letzteres stelle ich mal in Frage - meist ist das eben dann die Bankette der Straße und eben nicht mehr teil der Weide. Wenn man Weide als "Da wo Tiere weiden können" definiert endet das ja am Zaun:) Ich sehe den typischen, fest installierten Weidezaun auch als Begrenzung der Weide an (und die jederzeit versetzbaren Stahlspieße mit Isolatoren gehören eh nicht gemappt). Natürlich gibt es auch da Ausnahmen, zB. wenn durch die abgezäunte Fläche noch entlang des Zauns ein Wirtschaftsweg verläuft, oder wenn eine große Weidefläche auch intern in kleinere umzäunte Parzellen geteilt wird. In der Regel definiert aber der Zaun klar die Weidegrenze, und steht bei zwei aneinander grenzenden Weidestücken unterschiedlicher Eigentümer auch klar auf der entsprechenden Grenze. Und ein Zaun hat, anders als vielleicht bei einer Einfriedung mit einer Mauer oder einer Hecke, auch keine nennenswerte Fläche. Auch wenn man also im prinzip geometrisch argumentieren kann, dass der Zaun "außen" und die eigentliche Weidefläche "innen" ist, und somit eine räumliche Trennung zwischen dem umgebenden Land, dem Zaun, und der Weide besteht: in der Praxis kann ein Zaun kaum als flächiges Objekt angesehen werden das eine eigene Lücke zwischen Weide und umgebendem Landuse verdient ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mitbetreuer für die Chemnitzer Linux-Tage gesucht
On 03.01.19 13:37, André Riedel wrote: Hallo, für die diesjährigen Chemnitzer Linux-Tage suchen wir noch Mitstreiter, welche uns am OpenStreetMap-Stand unterstützen. Diese finden am 16. und 17. März statt. Weitere Informationen findet ihr im Wiki. Schade dass sich das am 16. mit der FOSSGIS in Dresden überschneidet. Ich überlege gerade für den 17. noch einen Abstecher für den Rückweg aus Dresden einzuplanen, wirklich festlegen kann ich mich da aber noch nicht ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hat der Renderer Probleme?
On 04.01.19 14:37, Nordpfeil wrote: Hallo zusammen, gibt es nur "den" Renderer. nein, natürlich nicht. Wenn man zB. ungeduldig ist und "sofort" sehen möchte wie das im aktuellen OSM-Carto Stil aussieht (oder auch in anderen Stilen) kann sich den entsprechenden Bereich auch zB. auf meinem Druckserver rendern lassen: https://print.get-map.org/ In der Regel hängt meine Planet-Datenbank nur ein bis zwei Minuten hinterher (grüne Kurve): https://print.get-map.org/munin/localdomain/localhost.localdomain/osm_lag.html und neue Carto OSM Versionen installiere ich normalerweise auch sehr Zeitnah. Vorteil: * es wird nichts gecached, jeder Renderauftrag wird direkt aus dem aktuellen DB-Stand erzeugt. Nachteil: * keine Tiles/kein Tileserver, es wird immer genau für die jeweilige Papiergröße und den gewählten Kartenausschitt in einem Rutsch gerendert * keine direkte Kontrolle des Zoomfaktors ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hat der Renderer Probleme?
On 04.01.19 15:59, Frederik Ramm wrote: Ich hatte bei der Weihnachts-Druck-Aktion neulich ein bisschen das Problem, dass der Carto-Stil nicht richtig mit dem Scale-Faktor zusammen arbeitet. Die Entscheidung, ab wann Fontgrößen für Flächen erhöht werden sollen, scheint unabhängig vom Scalefaktor getroffen zu werden. Da gibt es mindestens drei Probleme die ich mal gründlicher angehen muss: * PDF und SVG werden mit dem Standard-Scalefactor gerendert, der ist aber nicht wirklich passend da die Druckauflösung ja eigentlich deutlich höher ist als die von Mapnik und Cairo angenommenen 72 bzw 96 dpi (kann mir nie merken welches welche ist) * Bei der PNG Ausgabe passe ich tatsächlich den Scale Factor an um auf 300 dpi zu kommen, wenn das PNG aber zu groß wird und entweder zu viel Speicher verbraucht oder an das harte Cairo-Limit von ca. 30k*30k Pixeln stößt falle ich zurück auf 72dpi * Bei der PNG-Variante mit Scale Factor != 1 gibt es irgendwo in dem ganzen Stack ein Rundungsproblem bei den Schriftgrößen. Hier zum Beispiel fällt es besonders auf, die Größen der Halos sind durchgehend richtig, die eigentliche Beschriftung dagegen wechselt in der Größe relativ willkürlich von Buchstabe zu Buchstabe https://print.get-map.org/results//043939_2018-12-29_21-14_westen.8bit.png Ich habe auch mal versucht bei den PDFs und SVGs am Scale Factor zu drehen, aber die Ergebnisse dabei gingen so überhaupt nicht in die Richtung in die ich eigentlich wollte ... Leider ist da auch die Mapnik-Dokumentation nicht wirklich hilfreich (wie in so vielen Dingen). Ich habe auch schon mal kurz darüber nachgedacht "einfach" die MinScaleDenominator und MaxScaleDenominator Atribute in den XML-Stylefiles für höhere Auflösungen "on the fly" per XML-Parser anzupassen ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hat der Renderer Probleme?
On 04.01.19 16:21, Christoph Hormann wrote: Diese Entscheidungen werden auf Grundlage von way_area/NULLIF(!pixel_width!::real*!pixel_height!::real,0) gefällt. Es wäre eigentlich sinnvoll, statt der Normalisierung mittels !pixel_width!/!pixel_height! mit !scale_denominator! zu arbeiten. Müsste nur mal jemand umrechnen. Siehe auch: https://github.com/gravitystorm/openstreetmap-carto/issues/2524 Ah, interessant. Also tatsächlich eine Stelle wo einfach andere Ausgabemedien nicht wirklich vorgesehen sind ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] fire_hydrant:pipe_diameter
On 04.04.19 16:16, Rolf Eike Beer wrote: Der Rohrdurchmesser ist in der Regel sowieso nicht ersichtlich, da Überflurhydranten i.d.R. kein Schild haben. das kann ich für "meine" Gegend eher nicht so bestätigen, bis auf wenige Ausnahmen haben auch die Überflur-Hydranten in meiner Nachbarschaft Schilder. -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] B96n teilweise freigegeben, Cache TTL
On 25.02.19 10:49, Viktor via Talk-de wrote: > - Sind Wildbrücken unsichtbare Objekte? sieht so aus, zumindest in den Mapnik-Kartenstilen deren Quellcode öffentlich verfügbar ist finde ich in keinem davon Regeln in denen "wildlife_crossing", oder überhaupt "wildlife" zu finden wäre. Auch auf der Taginfo Seite dazu finden sich unter "Projekts" nur Projekte, die allgemein "mam_made=*" auswerten, aber nicht konkret "man_made=wildlife_crossing": https://taginfo.openstreetmap.org/tags/man_made=wildlife_crossing#projects Bei bisher nur etwas über 600 Einträgen weltweit scheint das Interesse noch nicht groß genug zu sein. PS: ich muss auch zugeben, dass ich keine Idee habe wie man so etwas überhaupt optisch darstellen sollte (also zusätzlich zu tunnel/bridge und forrest/scrub/grass ...) ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsberuhigter Bereich - maxspeed
On 09.04.19 11:33, Florian Lohoff wrote: In Österreich ist es explizit erwähnt - In Deutschland kann man die Definition des verkehrsberuhigten Bereich so interpretieren. Wenn das nicht für den Fahrenden sondern den ruhenden und erschließenden Verkehr ist kann IMHO da kein quer oder Durchgangsverkehr erlaubt sein. Gegenbeispiel: https://osm.org/go/0GwAqppMc?m= Hier ist die Gutenbergstraße durchgehen verkehrsberuhigt, auch über die Wittekindstraße hinweg. D.h. auf der Wittekindstraße steht da in beiden Richtungen ca. 10m vor der Kreuzung ein blaues Schild, man muss (in der erlebten Praxis eher: müsste) dort also einmal auf Schrittgeschwindigkeit runter, aber es ist klar zur Durchfahrt gedacht. Inwieweit so eine Konstruktion sinnvoll ist sei jetzt mal dahingestellt ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte mit shop=yes Orten
On 28.08.19 23:52, Hauke Stieler wrote: Moin, aber auch ein Geschäft an/in einer Tankstelle geht doch genauer als "ja, da ist ein Geschäft" oder nicht? Manchmal ist ja ein halber Supermarkt drin, manchmal aber auch nur ein kleiner Laden mit Snacks und Getränken. Finde nicht, dass das ein false-positive ist, auch das Wiki verstehe ich so, dass es durchaus genauer geht [0]. Und wenn man nichts genaueres weiß/erkennen kann, dann ist das leider so, aber immerhin hat man es versucht ;) da muss man unterscheiden ob das ein gemeinsamer Knoten ist, mit amenity=fuel shop=yes oder ob neben dem Tankstellen-Node, oder innerhalb des Tankstellen- Gebäudes, noch ein zusätzlicher shop-Knoten angelegt ist. Ein shop=yes an amenity=fuel bedeutet einfach nur: an der Tanstellen- Kasse bekommt man auch andere Sachen als nur Benzin und vielleicht noch Öl. Ein shop=convenience würde ich da persönölich erst zusätzlich anlegen wenn das auch als andere Marke beworben wird, auch wenn es nur einen gemeinsamen Kassierer gibt, also zB. aktuell bei den Kooperationen von Aral und ReweToGo ... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers und OSM
On 09.10.19 21:29, Hartmut Holzgraefe wrote: Das macht die Ladezeiten kürzer, und auch das API war (ist?) schlanker als bei OpenLayers. Solange man nicht zB. auch WMS/WFS Services mit einbinden will/muss halte ich persönlich Leaflet für die bessere Wahl ... ich hab da auch mal irgendwann zu beiden Bibliotheken "Step by Step" Guides gemacht um meine Gehversuche zu dokumentieren. Die OpenLayers Variante ist allerdings wirklich schon "gut abgehangen" und basiert noch auf OpenLayers 2.10 https://openlayers-steps.osm-baustelle.de/ https://leaflet-steps.osm-baustelle.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OpenLayers und OSM
osm.org verwendet seit einem halben Jahrzehnt +, leaflet und nicht OL. Simon, was war der Grund für diesen Wechsel? Und was sind die konkreten Haupt-Vorteile von LL? Leaflet ist, oder war zumindest zum Zeitpunkt der Umstellung, leichtgewichtiger als OpenLayers. Während Openlayers alle Funktionalität in einer großen Bibliothek bündelte (oder hat sich das in späteren Releases geändert) kommt Leaflet erst einmal nur mit den absolut notwendingen Basics an Bedienelementen und nur mit Unterstützung von einfachen PNG-Kartenkacheln, alles andere kann und muss als Plugin hinzugeladen werden. Das macht die Ladezeiten kürzer, und auch das API war (ist?) schlanker als bei OpenLayers. Solange man nicht zB. auch WMS/WFS Services mit einbinden will/muss halte ich persönlich Leaflet für die bessere Wahl ... Womit arbeitet OSM.de ? Wenn ich das richtig sehe mit einem kurzen Blick auf "View Source" im Broswer, dann immer noch mit OpenLayers 2.12 -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 36C3 [Was: Weihnachtskarten 2019]
On 19.12.19 19:29, Michael Reichert wrote: Hallo, vielen Dank für das rege Interesse. Wir haben die Karten aller 34 Empfänger heute gedruckt und zur Post gebracht. für 36C3 Besucher gibt es dann auch in Leipzig wieder die Chance auf gedruckte Karten, dieses Jahr am OSM-Schiff im OpenInfrastructure Bereich ... (Wenn der Drucker nicht wieder rumzickt wie in Heidelberg. Mein Erstatzteuldepot habe ich dementsprechend aufgerüstet) -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dienstleister für OSM-Kartendruck im Großformat
On 13.02.20 16:42, Michael Reichert wrote: Falls der Gebiet nicht zu groß ist, empfehle ich https://print.get-map.org/. Erzeuge dort die Druckvorlage als PNG-Grafik. Damit kannst du in einen Copyshop deiner Wahl gehen und sie ausdrucken. Das wäre die billigste Lösung. Potsdam in maximaler Größe / Auflösung würde da zB. so aussehen: https://print.get-map.org/maps/103397 Wenn das ganze "mehr fancy" sein soll als einfach auf Papier, dann beiten sich auch die verschiedenen online Poster-/Fotobuch-Druckdienste an (PosterXXL, MyPoster, ...), da gibt es dann auch die Möglichkeit auf andere Materialien wie Hartschaum, Acrylglas, Aluminium, Leinwand oder Folie zu drucken ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] w...@noreply.openstreetmap.org
On 15.01.20 10:34, Markus wrote: Ich schreibe ihm jetzt mal und erkläre ihm das Ganze, und dass er das natürlich bitte nicht löschen solle ;-) und warum nicht öffentlich als Antwort auf den Changeset-Kommentar? Wenn nur PT-53 weiß, was es mit diesen Linien ohne weitere Tags auf sich hat, dann besteht weiterhin die Möglichkeit, dass sie von jemandem anderen gelöscht werden. Unter anderem weisen ja auch die verschiedenen Validatoren auf solche scheinbar bedeutungslosen Einträge hin und schlagen vor, sie zu entfernen. Ich würde sowas auch löschen wenn ich zufällig irgendwo darüber stolpere ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Carsharing-Stationen Cambio und Stadtmobil Stuttgart
On 2020-11-20 14:26, Holger Bruch wrote:
> Erfreulicherweise haben Cambio und Stadtmobil Stuttgart reagiert. Cambio
> gestattet die Nutzung ihrer Auskunfts-API, um Carsharing-Stationen in OSM zu
> übernehmen, Mail siehe unten.
super, ich habe auch gleich eine Station gefunden die hier in Bielefeld
noch nicht erfasst war.
Schade beim Cambio-Api nur, dass zwar in der JSON-Antwort zu finden ist
welche Fahrzeugarten an den jeweiligen Stationen zu finden sind, nicht
aber die Anzahl. Aber irgendwas ist ja immer ;)
PS: hier das quick PHP Script mit dem ich das Cambio-Format in OSM
XML gewandelt habe um die Daten in JSOM laden zu können:
$lat, "lon" => $lon, "name" => $station["name"]];
}
$id = -1;
echo "\n";
echo "\n";
echo " \n";
foreach ($out as $node) {
echo "\n";
echo " \n";
echo " \n";
echo "\n";
$id--;
}
echo "\n";
--
hartmut
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de
