Re: [Talk-de] Meine letzten Edits
Hallo Michael, overpass-Turbo nimmt (nach meinem letzten Stand) den sichtbaren Kartenausschnitt automatisch als Bounding-Box an. Wenn du da also nur einen Ausschnitt anzeigst, in dem es keine entsprechenden Änderungen gibt, kommt von overpass-turbo nichts zurück. Soweit rauszoomen, bis du die ganze Welt oder aber zumindest den Ausschnitt siehst, in dem du bearbeitet haben kannst, sollte helfen. Gruß Peter Am 03.10.2016 um 17:31 schrieb mipo...@web.de: Hallo, ich bekomme von https://overpass-turbo.eu/ Rückmeldungen "Diese Karte ist leer (received empty dataset)", nachdem ich eine der beiden Abfragen (s.u.)dorthin kopiere und "Ausführen" klicke. Wo ist mein Fehler? Danke. Michael Abfrage gmbo / Gisbert: [timeout:80]; // Datum ggf. anpassen node [tourism=caravan_site](newer:"2015-05-01T07:00:00Z")(user:gmbo) ({{bbox}})->.newnodes; // Ausgabe .newnodes out meta; Abfrage Heinz-Jürgen - Tag weglassen: [timeout:100]; // Datum ggf. anpassen node (newer:"2016-08-01T07:00:00Z")(user:Heinz) ({{bbox}})->.newnodes; // Ausgabe .newnodes out meta; ___ 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: [OSM-talk] Spoken street names
Am 22.08.2016 um 19:21 schrieb Štefan Baebler: Having TTS to hear the street names is very nice, but hearing them correctly pronounced would be even better. There was an attempt at it: https://wiki.openstreetmap.org/wiki/Proposed_features/Phonetics But AFAIK there was no outcome from that proposal. Did anyone really investigate how bad using common phonetic rules PER LANGUAGE on osm names? For many names that should work I think, at least when the right language is detected correctly. That, on the other hand, could be hinted by using the corresponding name:[lang] tags (name:de, name:en, ...), probably even when the main language might be redundant. regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Help needed for mapping missing navigation data in Germany
Hallo Nikhil, ich habe mir eure osm-navigation-map mal angeguckt, und mir sind so ein paar Dinge aufgefallen: - Reviewed by [OSM username]: Warum dann nicht mit login bei OSM verknüpft und so gesichert. Ich will niemandem was unterstellen, aber einen anderen Usernamen anzugeben ist nach meinem Geschmack zu einfach. (offensichtlich mit [1] schon bekannt und geplant) - Warum muss der Benutzername mehrfach angegeben werden? (siehe auch erster Punkt). - "prohibitory--no-entry--de" [2] ist offensichtlich noch nicht lokalisiert, allerdings finde ich das auch nicht im Code auf Github, was das sein soll. Wenn ich das richtig vermute, ist das in diesem Fall ein Fehler, bei dem mir die Rückmeldemöglichkeit fehlt, denn offensichtlich ist ein Bahnübergang (Andreaskreuz neben der Schranke gut zu erkennen) falsch erkannt worden, denn der Bahnübergang existiert in OSM bereits, der wäre also ein Duplikat. - Was genau validiert man auf dieser Karte? In [3] gibt es einen "information--parking--de"-Punkt (offensichtlich auch noch nicht sinnvoll lokalisiert). Das Bild zeigt den Parkplatz südlich des Le-Mans-Walls, der sauber und ordentlich eingetragen ist. Ist das jetzt "valid" (Bilderkennung korrekt, Daten korrekt in OSM)), "Redundant" (Bilderkennung korrekt, aber schon seit langem in OSM) oder "Invalid" (hier fehlt sicher kein Parkplatz)? - Warum gibt es den Button "Delete"? Was lösche ich damit? Oder soll das grau bedeuten, dass das gar nicht möglich ist grade? Alles in allem sieht das schon recht gut aus, damit arbeiten würde ich aber erst, wenn mindestens das OSM-Login eingebaut ist. Viele Grüße Peter [1] https://github.com/mapbox/osm-navigation-map/issues/45 [2] http://mapbox.github.io/osm-navigation-map/#18.76/51.71489/8.75186 [3] http://mapbox.github.io/osm-navigation-map/#19.01/51.71507/8.75039 Am 19.08.2016 um 11:08 schrieb Nikhil Prabhakar: Hallo, wir möchten euch für alle Gedanken und Vorschläge danken die uns erreicht haben. Um die Bedenken und das Feedback der Community zu adressieren haben wir einen detaillierten und überarbeiteten Plan für unsere Arbeitsabläufe erstellt, wie wir auch schon in unserem Tagebuch-Post [1] angegeben haben. Wir planen diesem während all unserer Arbeiten zu folgen. Wir freuen uns über jedes Feedback und alle Vorschläge zu diesem Arbeitsplan. Wir würden uns über euren Support und eure Mitarbeit bei diesem Vorhaben sehr freuen und hoffen, dass wir das Ziel dieses Mappingprojekts klar machen konnten: OpenStreetMap zur besten Karte zu machen :) [1] Tagebuch-Post - https://www.openstreetmap.org/user/nammala/diary/39255#comment35719 PS: Wir haben den Bug-Report auf der OSM navigation map korrigiert. Ihr könnt die Karte über http://mapbox.github.io/osm-navigation-map erreichen Beste Grüße, Nikhil Prabhakar U ___ 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: [OSM-talk] Freeing JavaScript on the OSM Homepage?
Hi unaware, there is an open issue [1] about that already since some months, but you have to be calm and wait for it to happen - or help on your own by submitting a pull request for a (partial) solution. regards Peter [1] https://github.com/openstreetmap/openstreetmap-website/issues/879 Am 20.01.2016 um 19:37 schrieb unaw...@sigaint.org: Dear community, I noticed some issues on the JavaScript of the OSM Homepage. Explicitly, I am refering to http://www.openstreetmap.org/assets/application-493a26542d1a58f893bae08f4aa9910495c3a14cfc60db9be9b878202547a7c1.js and http://www.openstreetmap.org/assets/index-31bba8593ce3fd4ccd6c585180f31149973b722e3839d9a1e294fdc406c86b6e.js . 1. This "code" is unreadable and therefore can not be considered as free software, even if it says being licensed under a free license. 2. Some of the licensing just says "MIT license" without giving a link to the full license. This term is according to https://www.gnu.org/licenses/license-list.en.html unclear. I am explicitly missing links to the license at some parts of the "code" and a link to a source code that is readable and trivial and does the same as this "code", that can be edited and shared. I assume most of you heared about the free software foundation and it's goals and (mostly) identify with them? One of their goals is to free JavaScript, see: https://www.gnu.org/philosophy/javascript-trap.en.html https://www.gnu.org/software/librejs/free-your-javascript.html Question: has this been discussed already? What do you think of the goal to free JavaScript for OSM? And who is able to do that? Personally I would love to help if I were a programmer being able to do that... Best regards unaware ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Neue Farben im osm.org Kartenstil?
Hallo Manuel, umgetagged werden muss natürlich nicht, Tags sollten darstellen, was vorhanden ist, und sich gerade nicht an der Darstellung in einer Karte orientieren. Gruß Peter Am 01.11.2015 um 11:22 schrieb Manuel Reimer: Hallo, ich hatte ja erste Bedenken ich habe beim Eintragen einen Fehler gemacht, aber das scheint sich wohl über die ganze Karte durchzuziehen. Aktuell werden die Straßen etwas "farbloser". Zumindest in meiner Region gibt es so Langsam nurnoch weiße Straßen und die farbige Unterscheidung geht verloren. Woran liegt's? Mal wieder Anpassungen am Stil? Muss jetzt irgendwie umgetaggt werden oder ist das mit den farblosen Straßen so gewollt? Gruß Manuel ___ 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] Public Transport - Haltestelle ohne Linie / Austragen oder belassen
Hallo Nzara, mit dem Argument ist aber auch die Haltestelle ohne ausgehängtem oder irgendwo bekanntem Fahrplan nicht zwingend keine Haltestelle mehr - weil z.B. ein Busunternehmen seine Fahrgäste individuell informiert, dass und wann ihr Bus an dieser Haltestelle abfährt. Warum ist also der Fahrplan, den man kennen muss, Indiz für eine als solche gültige (public-transport-)Haltestelle, das Haltestellenschild aber nicht? Gruß Peter Am 13.10.2015 um 17:42 schrieb Nzara: Für mich ist eine Haltestelle ein Ort, wo ein Bus fahrplanmässig hält. Wenn kein Bus mehr hält, ist das ein Mast mit irreführender Bezeichnung. Mit public_transport hat es jedenfalls nichts mehr zu tun. Anderseits sehe ich, gerade in ländlichem Gebiet, fahrplanmässige Haltestellen ganz ohne Infrastruktur - die lokale Bevölkerung weiss einfach wo sie stehen muss. Hier sehe ich dann die public_transport tags auch ohne Infrastruktur gerechtfertigt. Aus der Tatsache, dass die Haltestelle in keiner Relation mehr auftaucht, kann man nicht viel schliessen -- ausser dass sich noch niemand die Mühe gemacht Buslinien vollständig in Relationen abzubilden. In OSM kann man eben aus dem Fehlen von Daten nicht auf die Nicht-Existenz in der Realität schliessen. Gruss Nzara Am 12.10.2015 um 20:40 schrieb Florian Lohoff: Hi, mir ist hier ein Changeset aufgefallen in dem eine Haltestelle/stop_position entfernt wurde die defakto existiert. Also da steht ein Bushaltestellenschild. Der User der die entfernt hat sagt das diese Haltestelle nicht mehr angefahren wird. Jetzt bin ich eigentlich geneigt die trotzdem in den Daten zu lassen - Defakto existiert dort ja eine Haltestelle. Die ist dann halt in keiner relation. Oder bin ich da auf dem Holzweg? Am Ende kann man ja gar nicht verhindern das der nächste die wieder einträgt. ___ 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] Liste aller Kirchen in Deutschland
Nicht einmal das alleine, denke ich. Auch eine Kapelle wird ja als Platz der Verehrung/Anbetung genutzt, gerade die vielen Marien- und sonstwie-Kapellen der Katholiken. Das ist deshalb, denke ich, nochmal eine andere Kategorie, die eher im katholischen Kirchenrecht verankert wäre - und ob man das in allgemeinen Tags in OSM abbilden kann/sollte, weiß ich nichtmal. Gruß Peter Am 09.10.2015 um 11:12 schrieb Martin Koppenhoefer: sent from a phone Am 08.10.2015 um 23:51 schrieb Helmut Kauer: in der katholischen Kirche wird ein Gebäude zur Kirche durch die Weihe. ja, aber das betrifft das amenity=place_of_worship, nicht den Gebäudetyp, der mit Building ausgedrückt wird Gruß Martin ___ 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] Liste aller Kirchen in Deutschland
Hi, bei deiner Abfrage fallen mir spontan die Varianten ein, die ich auch zu Kirchen zählen würde, die aber die Kirche nicht im Namen tragen: - Dom, z.B. "Stephansdom" in Wien, - Kathedrale, z.B. "Christuskathedrale" - Basilika, z.B. "Liebfrauenbasilika" - Münster, z.B. "Liebfrauenmünster" in Ulm Gruß Peter Am 06.10.2015 um 21:04 schrieb Jo: Ich werde auch mal versuchen mich zu vergallopieren... Ich habe diesen Overpass API query erstellt: [timeout:450]; area[name="Mönchengladbach"]->.country; ( node (area.country) ["name"~"[Kk]irche"]; way (area.country) ["name"~"[Kk]irche"]; relation (area.country) ["name"~"[Kk]irche"]; node (area.country) ["building"="church"]; way (area.country) ["building"="church"]; relation (area.country) ["building"="church"]; ); out meta; ; out meta; Damit soll es möglich sein alle Kirche zu finden, auch die die noch nicht völlig korrekt in OSM eingetragen sind, weil auch straßen und bushaltestellen mit Kirche in den Namen gefunden werden. Ich werde vorschlagen um gleich auch wikidata tags ein zu tragen. Die meiste Kirchen haben auch Artikel auf Wikipedia, und wenn nicht ist es ziemlich einfach ein Wikidata item zu erfassen, mittels: http://tools.wmflabs.org/wikidata-todo/quick_statements.php CREATE LASTLde"Sankt Laurentiuskirche" LASTDde"Kirche in Odenkirchen" LASTLen"Saint Laurentius church" LASTDen"church in Odenkirchen, Germany" LASTP31Q16970# church LASTP17Q183 # Germany LASTP825Q17590# Lawrentius of Rome (Zwischen LAST P... und Q... sind TAB Karakter, keine Leerzeichen) https://www.wikidata.org/wiki/Q21072103 https://www.openstreetmap.org/way/293096035/history Ziemlich mehr Arbeit, aber so wird es möglich sein um alle zurückzufinden die nach demselber Heiligen genennt sind. Polyglot (Mein Deutsch ist leider nicht so gut) 2015-10-06 19:21 GMT+02:00 Florian Lohoff: On Tue, Oct 06, 2015 at 02:12:23PM +0200, dktue wrote: Hallo zusammen, ich möchte gerne alle Kirchen in Deutschland mit Hilfe der OSM-Daten identifizieren. Leider ist das nicht ganz trivial, denn amenity=place_of_worship ist auch für viele Gemeindehäuser und andere Entitäten getaggt. Das offensichtliche building=church hingegen ist leider nur wenig verbreitet. Hat jemand eine Idee, wie ich automatisiert möglichst viele Kirchen sicher identifizieren kann? Ich nehme auf diese Mail bezug weil sich ja eine Wochenaufgabe herauskristallisiert die ich noch nicht so ganz sehe. Der Punkt ist das ein building=church sich auf die Gebäudeform bezieht. Das muss nicht zwangsmäßig ja noch ein amenity=place_of_worship haben. Dazu kann auch der amenity als POI auf einem Node innerhalb des Gebäudes liegen und das Gebäude trägt eben das building=church (Ich bin ein großer Freund davon POI informationen auf extra nodes abzulegen). D.h. ich finde hier werden tag klassen vermischt. Es geht um Kirchen - in ihrer Funktion oder als Gebäude? Ich habe in der Nachbarschaft mind. 2 Kirchen die mittlerweile "entweiht" und verkauft sind. Von aussen eindeutig als Kirche zu identifizieren jedoch einmal ein Restaurant und das andere ist ein Wohngebäude. Beide haben sogar noch einen Glockenturm etc ... Ich hätte auf den beiden auch ein building=church gesetzt ... D.h. wenn man das vernuenftig macht und POI und Gebäude trennt müsste das ein building=church amenity=place_of_worship place_of_worship=church sein ... Damit kann man das auch "self-contained" trennen. D.h. ein Gebäude mit building=church und innerhalb einen node der eben den amenity trägt. Oder vergallopier ich mich da gerade? Flo -- Florian Lohoff f...@zz.de We need to self-defense - GnuPG/PGP enable your email today! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iQIVAwUBVhQDF5DdQSDLCfIvAQoSEQ//WynvnF9kTPdfJ87L90QnvuIbOek/tZxh CaNq89/qYS1GlRqQFrAc+NMZSj2NRxVhJ25j/ADunhp04+Y++Xiim/ibqvyx8QsY UW9SPzQQKrtFQu7XhN1ZDN7CnNuPQgbubhHiHx9MPTx0166kdmX4C+1kg2/B0XKR z764w/4p9PcsVEJ5+gXlfT+zeVHgsQw451GTEx5nKeHZgSZ+MBuzYbU7Rc2MvPbI ew1TiosvGbJPL1Yk6YsLiq/0emoHakGqjNZ4Z/MHVpMbrBbMDEci9ss2/Dbhuynt UpE8wVAxBCP8OXMlQXhprPkxb6dUvTJz4eCLSpXP1ZgblVsEB8K6OaY93w65Ookj OfzQJWvGPlLH82MOaTrNNrZRPEq0n9j0ZVnsTzPwG8MpZa4XxPa8i0wyJ29o4HyR I/vbrEN6SogePtSF9UVYDNMm/PQSNRNGTTlG+nE+XnOgfvzcJ3D1WI+H6hARRE8b WNilcu1jNp93NOlHfo9b+UGZUSDmha3Pl3pkvwgG4jaPYzeNfULaRzNZF0GN1+jZ z+lPJ5LQQ6dFnu67NyPE3Nrzl3mCT5wh+3c4TFW+dsmZGVl3aEIeYzMaA9YXlaqA eAFLdlV70s11Sp6RovRsGCfH/BB9OHyosKsqaQLe0qGhmxgedU2TcC3E9BfdJtLs 4MBJ1B+/tY0= =Q6iT -END PGP SIGNATURE- ___ 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] Kurz-URL
Hallo Markus, ich kann selbst kein Ruby, aber ich tippe auf [1]. Zumindest ist das das richtige GIT-Repository für den Code, und der sieht so aus, als würd das passen ;) Gruß Peter [1] https://github.com/openstreetmap/openstreetmap-website/blob/d4d1527a92f23f973b405cea42bef8009ce9f4c4/lib/short_link.rb Am 17.03.2015 um 11:12 schrieb Markus: OSM bietet auf der Kartenseite Kurz-URLs an. Wie funktioniert das? Wo finde ich den Code, der das Handling für OSM.org erledigt? Mit herzlichem Gruss, Markus ___ 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] App für Android
zum Sammeln speziell von Hausnummern und Straßen find ich Keypadmapper3 immer noch ziemlich gut, manuelles korrigieren am Rechner hinterher ist trotzdem notwendig, dafür ist die Bedienung im Vorbeigehen kein Problem. Gruß Peter Am 16.02.2015 um 21:37 schrieb Michael: Hallo Ihr lieben Openstreetmapper! Ich bin jetzt ein neuer Besitzer eines Android Smatphones mit größerem Display. Welche Apps könnt Ihr empfehlen, speziell für OSM? Den MapFactor GPS Navigator habe ich schon installiert. Gibt es eine App um schnell mal einen Straßennamen oder eine Hausnummer einzutragen? Welche Apps sind speziell für Technikfreaks noch sinnvoll? Liebe Grüße Michael ___ 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: [OSM-talk] Error when Exporting from Share icon
Hi, What if the osm website would allow custom renderings within predefined zoom levels by default, stitching together existing tiles in that case, which should require much less resources than a complete custom render, even when cutting down to non-tile boundaries. For current browsers it should be possible to do that with javascript at the browser a well. If we still want to allow the custom zoom rendering, a fallback to the current solution might be possible, but a UI that makes clear that some predefined zoom levels are to be preferred might, I guess, solve most of our requests by accident as most users probably aren't that specific in the zoom they query for. What do you think about that idea? regards Peter Am 26.01.2015 um 13:40 schrieb Tom Hughes: On 26/01/15 12:00, Paul Norman wrote: On 1/26/2015 2:58 AM, Dave F. wrote: I don't know when it was last reviewed, but does this error have bit of a sensitive trigger? Has the server that runs the process been upgraded so it can handle a greater number of requests? If so, could the error's cut in point be relaxed? The thresholds for each server have been adjusted multiple times and will probably continue to be so. Even if the load cutoff is increased there will be times when individual render requests are rejected for a few days in a row - stylesheet updates being the main one. It is considered more important to update the map rendering than to do a custom render. Personally I don't have many problems generating a custom render from osm.org, but I'm on a different timezone and keep different hours, which makes it hard to compare. I also get directed to a different server much of the time. I suspect main difference is that you're hitting orm and Dave is hitting yevaud. There is an ops ticket open for our efforts to get yevaud upgraded to improve the performance: https://github.com/openstreetmap/operations/issues/5 Tom ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Imports] amenity=bicycle_repair_station :::: only 18 so far
Hi, Adding option 4, already used on many other imports: Use some externa repository for manual checkup, as done e.g. for fuel stations [1], where the list of fuel stations was spread via wiki and some other tool I don't recall exactly. This allows to verify the progress (let importing users add a link to the objects after their import), and it allows to verify the data. I remember we checked most of the items on different sources as well, like websites and aerials (you see fuel stations on imagery usually). regards Peter [1] http://wiki.openstreetmap.org/wiki/Fuel_Station_Data_Germany#Tankpool24.de Am 26.01.2015 um 19:14 schrieb Dave Corley: -- Message: 5 Date: Mon, 26 Jan 2015 18:27:43 +0100 From: JB jb...@mailoo.org mailto:jb...@mailoo.org To: winfi...@gmail.com mailto:winfi...@gmail.com, OpenStreetMap talk mailing list talk@openstreetmap.org mailto:talk@openstreetmap.org Subject: Re: [OSM-talk] [Imports] amenity=bicycle_repair_station only 18 so far Message-ID: 54c6790f.1040...@mailoo.org mailto:54c6790f.1040...@mailoo.org Content-Type: text/plain; charset=UTF-8; format=flowed Le 26/01/2015 17:59, Jo a écrit : It would indeed be preferable to use OSM Notes for that purpose. Ho crap. Instead of importing 500 low-quality POI, just import 500 low-quality notes… So that only the notes DB is a dump, but not the main one. Sorry for the bad energy, but please do not consider the note feature as a second level one. And for the fun, please close the 10 closer to your location :-) As I see it there are 3 options here 1. Do an import, but its not accurate enough for an import - 500 POI's will never be fully vetted. 2. Add a note so that someone can map it either from imagery or a ground survey - 500 notes will get checked by individual mappers. 3. Do nothing, stick the data in a drawer and never use it - 500 pieces of data never get used by anyone To me the only logical choice is #2 when you data is not accurate enough for an import but the data itself is useful and something which is wanted All that is needed is a disclaimer added to the note something to the effect of This note is based off an inaccurate source. The bicycle repair station is located somewhere within 30 meters of this note. If you can easily identify the station, please map it and close this note. If note, please add a comment saying it needs a ground survey. This doesn't need to be very complicated. Dave ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Tag:highway=traffic_signals / wiki page inkonsistnet
Ich weiß nicht genau, wie Router das momentan zählen, aber Probleme sehe ich eigentlich höchstens bei geteilten Richtungsfahrbahnen an einer oder beiden Straßen. Ansonsten tagge ich: 1) highway=traffic_signals am Kreuzenden Knoten der beiden Straßen, mit der Interpretation: Diese Kreuzung ist (für den Hauptfahrweg) durch eine Ampel geregelt) 2) highway=crossing, crossing=traffic_signals an der Querung (für Fußgänger und/oder Radfahrer), also meist leicht abseits des kreuzenden Nodes der beiden Hauptfahrwege. Die Folge: - Fußgängerquerungen lassen sich so präziser beschreiben, insbesondere da, wo nicht an allen vier Armen der Kreuzung eine direkte Querung möglich ist, als wen man die mit am mittelpunkt der Kreuzung einträgt - Das Routing für Autofahrer muss jetzt nur noch eine Verkehrsampel berücksichtigen. Einziges Problem: Wird auch eine Fußgängerquerung (crossing=traffic_signals) ohne eingetragener Ampel (highway=traffic_signals) alleine mit Zeitverlust bestraft werden Ampeln noch teurer als bisher, da sie nun meist 3fach gezählt werden. Ansonsten bzw. nichtsdestotrotz halte ich es für die korrekteste Lösung. Gruß Peter Am 03.11.2014 um 21:19 schrieb chris66: Am 03.11.2014 15:12, schrieb Martin Koppenhoefer: Zu der Wikiseite möchte ich anmerken, dass das hier im Falle von Abbiegern von primary auf secondary die Ampel zweimal zählt: http://wiki.openstreetmap.org/w/images/d/dc/Traffic_signals_example_3.png Mir fällt hier auch keine Ampelpositionierung ein, so dass bei jeder Abbiegung jeweils nur einem Ampel im Weg liegt. Davon abgesehen sollten Navis hier etwas mehr Fuzzy Logik anwenden also z.B. eine zweite Ampel innerhalb von 10 Meter Wegstrecke nicht noch einmal für die Penalty zählen. Chris ___ 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] OSM quo vadis - OSM-Account für Workshop
Hallo Markus, die Herausforderungen, die du ansprichst, sind richtig, aber es sind eben auch Herausforderungen. Richtig ist auch, dass wir aufpassen müssen, nicht nur für IT-Nerds, wie du das ausdrückst, nutzbar zu sein, aber trotzdem: Ein gewisses Mitdenken zumindest kann man erwarten. Einen Benutzernamen und Passwort auszudenken sowie ein Formular und E-Mails zu benutzen, die - so hoffe ich, ohne es aktuell geprüft zu haben - selbst erklären, was zu tun ist, erfordert als Grundwissen eigentlich nur die Benutzung des Webbrowsers und des eigenen E-Mailprogramms, und darüber hinaus Lesekompetenz, um zu verstehen, was erklärt wird. Wenn wir da was verbessern können, sollten wir das tun, aber wenn - abgesehen von Verbesserungen bei diesen Erklärungen - dies schon eine Hürde in Bezug auf das Verständnis oder die Fähigkeiten des Nutzers darstellt, dann kann das fürs Tagging nicht funktionieren. Dann ist meines Erachtens erstmal der richtigere Weg, die Nutzer zum Fehlermelden via Notes aufzufordern. Gruß Peter Am 23.09.2014 um 10:20 schrieb Markus: Hallo Stephan, Wir müssen bei OSM nicht jeden haben. Doch: OSM - die freie Weltkarte ist ein Projekt von freien Bürgern für freie Bürger :-) Die Herausforderung ist: - simple Frontends - intuitiv bedienbare GUI-Editoren - intuitiv bedienbare Qualitätswerkzeuge - verständliches nachvollziehbares Datenschema - verständliche gut organisierte Doku Nur Menschen mit lokalem Wissen können die Datenbasis verbessern. Wir müssen aufpassen, dass OSM nicht nur für IT-Nerds nutzbar ist, denn diese in Kombination mit lokalem Wissen sind dünn gesät ;-) (aber ds sprengt jetzt diesen Thread etwas) Gruss, Markus ___ 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] OSM quo vadis - OSM-Account für Workshop
Hallo Frank, daran ist natürlich nichts falsch, und ich tu das selbst, wo ich kann - aber je nach Kompetenz des Neulings, und darunter insbesondere Lesekompetenz, erfordert das mehr oder weniger enge Betreuung. Manchmal kann man Leute an lokale mapper verweisen, manchmal kann man das selbst in die Hand nehmen - und manchmal wird das scheitern. Auf einer Messe gehen Leute dann aber ja zügig weiter. Wenn da nicht (wie bereits erwähnt) direktere Kontakte für später vermittelt werden, ist eben niemand da, der bei Fragen hilft, sobald die Leute dann auf einmal alleine dransitzen. Gerade was das Mappen angeht ist OSM doch immer noch etwas, wo man recht viel lesen muss, gerade am Anfang. Was bedeutet welcher Tag? Die Presets von iD und JOSM nehmen einem hier schon recht viel ab, aber eben doch nicht alles. Am Stand hat einem eben doch keiner gezeigt, was ein Konflikt ist, warum ich Routen kaputtmache und der validator mich davor warnt etc.. Ich weiß von einigen, die an solchen nachträglichen Problemen gescheitert wären. Das lässt sich meines Erachtens nur entweder durch einen dauerhafteren Kontakt zu erfahreneren Mappern, oder aber dadurch beheben, dass der Neuling aktiv nachfragt oder recherchiert, ohne direktem Kontakt zwangsläufig textuell, und das erfordert die von mir vorher geforderte grundlegende Lesekompetenz. Wie gesagt: Mit direkter Betreuung sieht das wieder anders aus, aber ich bezweifle, dass die normalerweise funktioniert (bin da aber vielleicht auch ländlich geprägt). Gruß Peter Am 23.09.2014 um 11:18 schrieb Falk Zscheile: Was ist so verkehrt daran, dass Markus die Leute an die Hand nimmt? Mir ist jemand, der schon einmal in OSM unter Anleitung editiert hat lieber, als jemand, der gar nicht hineingeschnuppert hat, weil im die Zeit oder der Mut dazu gefehlt hat. Es gibt Menschen, die sich besser dabei fühlen, wenn ihnen bei den ersten Gehversuchen jemand über die Schulter schaut. Ich finde dass sogar gut, schließlich werden so vielleicht die gröbsten Anfängerfehler vermieden. Gerade bei älteren Semestern konnte ich beobachten, dass sie mit dem Einstieg bei OSM zögern, weil sie nichts falsch machen wollen. Einige sind nur dabei, weil sie am Anfang jemanden hatten, den sie direkt fragen konnten. Wenn wir in Richtung wir brauchen niemanden, der sich nicht allein anmelden kann/will argumentieren, dann ist das meines Erachtens ein falscher elitärer Ansatz. Falk Am 23. September 2014 10:59 schrieb Michael Reichert naka...@gmx.net: Hallo, Am 2014-09-23 um 10:56 schrieb Peter Wendorff: die Herausforderungen, die du ansprichst, sind richtig, aber es sind eben auch Herausforderungen. Richtig ist auch, dass wir aufpassen müssen, nicht nur für IT-Nerds, wie du das ausdrückst, nutzbar zu sein, aber trotzdem: Ein gewisses Mitdenken zumindest kann man erwarten. Einen Benutzernamen und Passwort auszudenken sowie ein Formular und E-Mails zu benutzen, die - so hoffe ich, ohne es aktuell geprüft zu haben - selbst erklären, was zu tun ist, erfordert als Grundwissen eigentlich nur die Benutzung des Webbrowsers und des eigenen E-Mailprogramms, und darüber hinaus Lesekompetenz, um zu verstehen, was erklärt wird. Wenn wir da was verbessern können, sollten wir das tun, aber wenn - abgesehen von Verbesserungen bei diesen Erklärungen - dies schon eine Hürde in Bezug auf das Verständnis oder die Fähigkeiten des Nutzers darstellt, dann kann das fürs Tagging nicht funktionieren. Dann ist meines Erachtens erstmal der richtigere Weg, die Nutzer zum Fehlermelden via Notes aufzufordern. +1 Viele Grüße Michael -- Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Account für Workshop
Am 21.09.2014 um 21:07 schrieb Norbert Kück: Hallo Markus, am 21.09.2014 20:26 schrieb Markus: Also eine passende wegwerf-email besorgt und damit registriert. Aber OSM will mir eine Bestätigungsmail schicken - und die kommt bei mir natürlich nicht an... Wieso natürlich? Wenn Du beim Anbieter keine Weiterleitung auf Deine Adresse eingerichtet hast, musst Du die Nachricht auf seiner Website abholen. Wegwerfadressen sind übrigens nicht gut, weil sie die Benachrichtigungsfunktion von OSM (User zu User) unmöglich machen. Was nun? Das Problem hatte ich nicht, weil ich unter eigener Domain viele E-Mail-Konten einrichten kann. Vermutlich kannst Du Dich bei OSM einloggen, um die E-Mail-Adresse zu ändern - wäre ja blöd, nur wegen eines Tippfehlers einen Account zu verbrauchen. Einige Kost-Nix-Anbieter haben eine Alias-Funktion, auch GMX? Hat GMX auch. Gruß Peter Gruß nk ___ 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: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
Hi Per, thanks for your reply to the thread here. My suggestion regarding GPS traces would be twofold: 1) it would be great to have more gps traces alltogether in general, so a general upload of traces would be ideal, but it requires teaching the users about the danger of it, and uploading traces should probably be under a collective account of your company to obfuscate personal home locations and such. Another idea here would be to cut the first and last parts of traces to obfuscate this. 2) Whenever a speed limit has been submitted the note you create from that should ideally link to the corresponding gps track. This would enable to get the direction directly (no heading necessary) and - if the speed is included by at least relative timestamps in the trace - the speed limit might be better to locate if the driver adjusts his speed according to the current limit (which often is the case I think). Both of this requires a really careful information of the user as those data in theory may contain or leak private information. regards Peter Am 08.09.2014 um 17:05 schrieb Per Rosengren: Hi all! I work together with Erik Matsson who also have written in this thread (in August). For those of you who haven’t read his message, we work at Appello that owns the navigation application Wisepilot. It is through Wisepilot those anonymous notes have been posted. First of all, thanks for your input. All ideas about how we can improve the quality of the notes are very much appreciated. We have made some first changes on the server side of our application based on your input. We will also make further improvements as we are releasing new client versions. We have changed so that only registered and authenticated users are allowed to post notes for now. Hopefully we can later allow anonymous notes to be posted again when we have made some more improvements to prevent spam notes (sanity checks, more useful info in the notes and provide the users with more information about what happens when they post a note). Notes about wrong/missing speed limit now looks like in the example below (always in English). We changed the message to make it clearer that the reported speed is what it should be changed to in the map data. We also made it clear that it is reported using Wisepilot and added a link to our site if someone wants to contact us. = Reported and assumed correct speed limit is 30 km/h. Reported using Wisepilot map reporter Created by www.appello.com = If a user tries to report speed limits like 15, 25, 35 km/h we ignore the note and do not post it (still possible when mph). Also, in upcoming releases of the client we will try to make something smart so that km/h or mph is automatically selected depending on the user’s position (at least make it more clear what one is reporting). Like Andreas Vilén suspected, our default position was sometimes used when posting a note. It is users who have not yet gotten a real GPS fix (probably in combination with that they do not understand the reporting functionality). In coming releases of our client we will add a check in the clients that it is not a simulated position but a real GPS fix (we also think of adding the GPS accuracy to the note). To prevent old clients from reporting the default positions we now ignore notes with a position that is near the default position. In coming client releases we will also check the heading and add that to the notes as well (like Christian Quest suggested, N, NW, etc). If you have ideas related to sharing GPS traces it would be interesting to hear about them, as this is a feature we plan to add. Don’t hesitate to contact us if you have questions or ideas of how we can make things better. Best regards, Pelle -- Per Rosengren Deputy Head of Engineering Location: Appello | Göteborg | Sweden Phone: +4670-6858253 Mail: per.roseng...@appello.commailto:per.roseng...@appello.com Web: www.appello.comapplewebdata://D15576C0-CD44-42A9-B5CC-684A0DB0D998/www.appello.com%20 [Description: cid:image001.png@01CD2D3A.F4FA4D50] ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Adding Wikidata tags to 70k items automatically
Hi Janko, something like that was proposed on the wikidata side already if I remember right. The idea was to store some kind of query on wikidata, e.g. the Overpass-Permanent-ID [1], which would be used exactly as you say: it can fetch the arbitrary object(s) that match and should match; independent of changing OSM object ids, splits or other stuff like that. I don't find the right page where that happend, probably my memory is corrupted ;) regards Peter [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID Am 31.08.2014 um 16:46 schrieb Janko Mihelić: Hi Frederik, great post. I always thought wikidata tags would be a first step to a new database that OSM needs, and which would be something like Wikidata is to Wikipedia. A database that classifies and categorizes elements in OSM. In my opinion a slightly modified version of Wikibase could be enough. It would have combinations of tags and areas where that category applies. If we had a database item in our potential OSM-wikibase that said all primary highways with ref 55 in the UK and then offload the proprietary identifiers there, I think no one would mind. Another problem this potential database solves is the often quoted relations aren't categories. We could make an item HSBC ATM machines and add a few tags that define an element as a HSBC ATM machine (amenity=atm + operator=HSBC, or amenity=atm + ref:HSBC=34 or whatever) Even wikidata tags that we are discussing could be deprecated if we had such a database. We would have our own identifiers (O3489 instead of Q23489) and those identifiers would link to wikidata as well as to other databases. If we don't make our own database that categorizes our tags and elements, someone else will do it. In this case, it's Wikidata, which is better then the rest because it is crowdsourced, it has an open license for it's data, and it has opensource software for it's database and user interface. So if I'm not mistaken, we could fork their project if that was needed. But if I could choose, we would have our own. Janko Mihelić 2014-08-30 23:40 GMT+02:00 Frederik Ramm frede...@remote.org: Hi, On 08/29/2014 08:10 PM, Rob Nickerson wrote: Lets just step back and reflect on this for a minute. My overarching concern is that if this import is done, future imports will use the but we also have Wikidata links argument for justification. What we have here is a third-party database whose object identifiers we add to OSM as tags in order to make linking things easier. This is something that has often been requested by people but never been granted on a large scale because we always said that it would be an abuse of our database and our mapper's patience to offload everyone's and their dog's linking requirements onto us. Imagine every single stretch of road being tagged with three different proprietary (or at least competing) identifiers of traffic information providers, or similar payload tacked onto OSM. I'm not saying no to a Wikidata import but I would like the proponents to state clearly what makes this import special - why this and not, for example, Ordnance Survey TOIDs or IDs of Mapillary photos? I would like to define high hurdles for such an import. The import costs us a lot (in terms of mappers having to spend time to understand the tags and know how to handle them when they edit an object, more quality checks, etc.), and it must be proven - or at least expected - to offset that cost by making itself useful. It's ok of this particular import clears the hurdles but at least I can then use the hurdles if the next guy in line comes along and wants to import his keys too. Also, I note that Rob wrote: We have our own restrictions (verifiable on the ground, not changing to frequently) in OSM. A link to wikidata allows us to continue with these restrictions but still allow people to get at interesting non-geographic data. And Andrew said: A few more points: This isn’t a deletionists’ charter and we shouldn’t rush to unload any tagging onto Wikidata without discussing the removal very carefully. I am personally very much in favour of unloading non-geo-database tagging elsewhere. We started with marking restaurants (useful) and recording their names (also useful), classing them into fast-food or proper restaurants, then tagging what cuisine they have and how to contact them for booking a table, and meanwhile we're recording whether they have vegan food and what their opening times are and whetehr you can pay with bitcoin. We don't currently have anywhere to offload that information which is all useful for certain use cases, but once we have a working integration, I should very much hope that stuff like the menu and the opening times will be recorded either in OSM or in Wikidata but not both. Allow me one question in that matter as a Wikidata ignorant though: Are there any notability rules in Wikidata? For example, if
Re: [OSM-talk] Introducing Fix waterway direction
Am 28.08.2014 um 21:48 schrieb Peter Barth: Hi, Christoph Hormann schrieb: Great to see the waterways are getting some attention. Does this only analyze SRTM elevations at start and end point or are the surrounding waterways considered? currently start and end point only. I have code to do more, but for the easy tasks that was not necessary as I have a fairly high number of true positives. If a waterway meets another waterway at one side but is unconnected at the other for example this is usually a strong indicator for the direction independent of the elevations data (which is only helpful usually in mountain areas). Actually I found many streams where start and end point are not connected to anything at all. However, for those cases (not mountain areas) the aerials didn't help neither in most cases ;) But as I'd like to get a mostly complete waternetwork for another project, I'm planning on extending the challenge at some point. In terms of usability it would of course be good if you could see the direction in MapRoulette so you can verify the data without actually loading it in the editor. Serge suggested this, too. But I did never understand what the direction would tell the user? Does it denote the current way's direction or the supposed correct direction? How would the user know? And my biggest concern is, that in many cases you need aerial anyway to be really sure. Anyways, would be happy to add this, once I got, how this should be done :) You may add arrows in both directions, color-coded for assumed and current (and explained in the challenge description on the top right) regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
Hi, A distinction between field notes and armchair IMHO goes too far. Instead a kind of field flag might help, which can be seen as this note has to be reviewed by someone with detailled on-the-ground knowledge or being present on the ground. On the other hand there's the problem of an increasing number of notes. I see two different problems here. 1) Too many notes I cannot solve: Motivation goes down, and I start to close notes just to get rid of them although they are neither solved nor correctly identified as being invalid. This is an individual problem for each (maintaining) mapper. I would like to see something like hide this node for me, perhaps with an optional ...until it is changed or commented by someone else. This would allow armchair mappers to clean up the notes as far as possible without being disturbed by irrelevant notes being processed already. 2) What is the purpose of notes? There are private notes of mappers for themself to fix problems later; often these aren't explained in detail as the mapper relies on his memory to understand it. Those might be solved by allowing private notes as mentioned by others. There are bug notes, where something is wrong in the map in contrast to missing notes, where something is missing. Both may be valuable, some for locals, some for armchair mappers, some for both, and others for nobody. The distinction between armchair and field is difficult. Of course there are Germans or HOT-people who armchair-map somewhere else in the world or something like that, but I don't think it would solve the issue. I think, although those don't call themself armchair-mappers, most of these issues arise where someone checks his own city, or the region around for bugs. Bugs where the mapper might go to in the field if necessary, if not now, then in the next weeks or months, becoming a field mapper by doing that. Moreover most armchair mappers (I hope) are field mappers in their local area. It would therefore require to decide about my own field mapping area versus the rest of the world to show or hide the one or the other set of nodes. To conclude: I think there's the chance for improvement of the notes system, but closing notes should be done with care, and only where it is clear that the note is either solved or unsolvable/wrong. regards Peter Am 10.08.2014 um 14:10 schrieb Matthijs Melissen: I see a lot of comments like this. The underlying problem seems to be that it is not clear whether notes are meant for armchair mappers, or for surveyors in the field. I think both types of notes are useful: that way the notes can serve as a two-way communication between mappers in the field (for example novices who don't know how to edit the map themselves) and armchair mappers (who might want to communicate with mappers in the field if they are unable to do a field check themselves at that moment). So the solution might be very simple: make two types of notes, 'desk' notes and 'field' notes. The desk notes can be handled by armchair mappers. The field notes need a check in the field. Notes created by anonymous users should be desk notes by default, and if information is missing, the armchair mapper should be able to turn it into a field note. The notes JB refers seem to be field-type notes. I think they are useful, and I think it's not helpful if armchair mappers try to close all of them without doing a survey. Anyone think a split in field and desk notes is a good idea? Implementation of this should be easy. -- Matthijs On 10 August 2014 11:50, JB jb...@mailoo.org wrote: Hello, I think I will reopen the debate here, by asking a simple question: how many of those saying hey, let this note open, it does no harm to anybody have actually browsed a country for its opened notes and tried to close them? How many have done the same with openstreetbugs during its last year of life? If you have not, let me tell you, loud and clear: the note database will become unusable soon. When you browse 10 notes and are forced to leave 9 open because it does provide no clean information, you just stop trying. That is why during OSB close up, I found so many notes of that kind (continue the path, this is wrong, this does not exist, etc.), that where just not clear enough, or where just too old (the correction had been done without OSB), and most of them where more than 2 years old. And this is why OSB was a mess in the end. I have tried to keep the DB clean in France, am still trying by beeing less narrow-minded, but I just see its quality decreasing every day. So I do not have the exact number, but adding some 10s of little valued notes every week saying this speed limit may be wrong, some of them added by error (not along a highway) does not seem an improvement to the notes DB to me. JB. Le 10/08/2014 09:42, Martin Koppenhoefer a écrit : Il giorno 09/ago/2014, alle ore 13:56, Norbert Wenzel norbert.wenzel.li...@gmail.com ha scritto:
Re: [Talk-de] shop=pharmacy Tag enfernen, wenn amenity=pharmacy vorhanden
Hi, der Wheelmap-Visitor sollte meines Wissens nur für wheelchair=yes|no|limited eingesetzt werden. Natürlich taucht der trotzdem als letzter Bearbeiter auf, wenn die wheelmap amenity=pharmacy auch nur als solches erkennt und bearbeiten lässt, aber ich bezweifle, dass sie der Ursprung der Tags ist. Gruß Peter Am 04.08.2014 um 09:27 schrieb Andreas Goss: Ich hatte mir nach dem Kommentar im Diary das Ganze mal etwas genauer angeschaut und es scheint vorallem in Deutschland vorzukommen. http://www.openstreetmap.org/user/AndiG88/diary/23443#comment27423 Bei genauerem hinsehen wurde dann auch klar warum: wheelmap_visitor Von daher jetzt meine Frage, wäre es in Ordnung, wenn ich in Deutschland mit einem mass edit überall den shop=pharmacy Tag entferne, WENN amenity=pharmacy vorhanden ist? Siehe: http://overpass-turbo.eu/s/4rC http://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dpharmacy __ openstreetmap.org/user/AndiG88 wiki.openstreetmap.org/wiki/User:AndiG88 ___ 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] shop=pharmacy Tag enfernen, wenn amenity=pharmacy vorhanden
Das versteh ich jetzt nicht, Dein Bild zeigt vier davon, die alle vor der Bearbeitung durch wheelmap_visitor schon amenity=pharmacy als Tag besaßen. Inwiefern wäre jetzt wheelmap_visitor die Quelle des Tags, wenn nur ein völlig anderes Tag, nämlich wheelchair=* hinzufügen, und das Objekt sonst unverändert mit dem vorher schon vorhandenen amenity=pharmacy belassen? Gruß Peter Am 04.08.2014 um 10:21 schrieb Andreas Goss: Einfach mal zufällig reingeklickt: http://i.imgur.com/xDpZ3Bh.png Nicht die einzig Quelle dieses Tags, aber vermutlich der Grund warum Deutschland hier besonders hervorsticht. Hi, der Wheelmap-Visitor sollte meines Wissens nur für wheelchair=yes|no|limited eingesetzt werden. Natürlich taucht der trotzdem als letzter Bearbeiter auf, wenn die wheelmap amenity=pharmacy auch nur als solches erkennt und bearbeiten lässt, aber ich bezweifle, dass sie der Ursprung der Tags ist. Gruß Peter ___ 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] shop=pharmacy Tag enfernen, wenn amenity=pharmacy vorhanden
Hi, mea culpa, entschuldigt bitte; hatte irgendwie nur nach amenity=pharmacy geguckt, und das war ja schon da (evtl. in der irrigen Annahme, dass jemand das wegnähme, wenn er was alternatives dazu einfügt) Gruß Peter Am 04.08.2014 um 12:27 schrieb Holger Jeromin: Peter Wendorff wrote on 04.08.2014 11:16: Das versteh ich jetzt nicht, Dein Bild zeigt vier davon, die alle vor der Bearbeitung durch wheelmap_visitor schon amenity=pharmacy als Tag besaßen. Inwiefern wäre jetzt wheelmap_visitor die Quelle des Tags, wenn nur ein völlig anderes Tag, nämlich wheelchair=* hinzufügen, und das Objekt sonst unverändert mit dem vorher schon vorhandenen amenity=pharmacy belassen? Guck nochmal genauer hin. Zusätzlich mit wheelchair kam der shop hinzu. Siehe auch: http://osm.mapki.com/history/node.php?id=904149172 definitiv ein bug der behoben werden muss, wenn er überhaupt noch aktuell ist. Ist immerhin über 3 Jahre her. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
Sorry, there are QA tools to detect where speed limits are missing? Can you give me a link? And - if it's not self explaining: how should that work? I don't see any way to detect missing speed limits in the data beyond cases where those are implicit defaults, like 100 on non-trunk roads away from built up areas in Germany (which is complicated enough to derive from the data), or 130 for trunk roads (although most often there are lower limits), or 50 in cities (as the most often down-signed default). So if there is any QA tool that detects that, I fear it uses third party sources, a reporting system similar to the notes feature, but using a different channel, or it is restricted to some cornercases only. I doubt there is something like that which could make notes about speed limit errors in osm obsolete. IMHO notes are to be checked in person on the ground usually. If there's nobody in France to do that, yes, then notes will remain in the database for a long time, but basically they stay correct: Here is something missing or wrong, please check that on the ground. regards Peter Am 29.07.2014 um 11:09 schrieb JB: I don't necessarily want to analyse once more how the notes are opened, closed or not closed and to what aim, nor analyse the end of OpenStreetBug life and the quality of the remaining bugs, but in France, I have never ever seen anyone comment on someone else's note (or « resurvey »). The only comments I have seen were from the note opener, when prompted by a potential corrector. So a note which indicates « probably 90km/h here » or « speed limit is not 0km/h » may remain there for years (yes, years), demotivate potential note closers, never be closed. I do not think they participate to a high quality note db. There are quality assessments tools around that allow contributors to detect where speed limits are missing. JB, with perhaps some bad faith in there, but not that much. Le 29/07/2014 10:19, Steve Doerr a écrit : On 29/07/2014 08:32, JB wrote: Anyway, as for most notes concerning speed limits, if you do no have the beginning and the end of the limit, at least in France, the information is quite useless. Are we all armchair mappers now? Surely the note should prompt someone local to go out to the location and find out where the speed limit starts and ends? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Incorrect speed limit anonymous notes - who is behind that?
Hi Shaun, if I understand these maps correctly, they show streets without a maxspeed tag, but not msising maxspeed restrictions under the assumption of a national default or something like that (although it seems not so show any missing maxspeed in Germany, so there might be something like that applied). If maxspeed is and should be applied on any street, this works, but only until speed limits change. If you imply the default according to highway class and location, it fails as many roads do follow these defaults and cannot be counted as missing, nor is it possible to decide where else a maxspeed is missing then. In any case reporting missing maxspeeds will work only until the speed limit is changed on the ground as it is even more difficult (if possible) to detect where there are errors (!) in existing speed limits. regards Peter Am 29.07.2014 um 13:10 schrieb Shaun McDonald: Hi Peter, The following ITO Map shows missing maxspeed tags where there isn’t any purple (mph maxspeed) or dark green (km/h maxspeed) colour: http://www.itoworld.com/map/125?lon=-0.08316lat=51.51851zoom=14open_sidebar=map_keyfullscreen=true If you want to see the current speed limits see: http://www.itoworld.com/map/124?lon=-0.08316lat=51.51851zoom=14open_sidebar=map_keyfullscreen=true Clicking the maps gives more info in the sidebar. Shaun Disclaimer: Employee of ITO World who produce the maps above. On 29 Jul 2014, at 11:49, Peter Wendorff wendo...@uni-paderborn.de wrote: Sorry, there are QA tools to detect where speed limits are missing? Can you give me a link? And - if it's not self explaining: how should that work? I don't see any way to detect missing speed limits in the data beyond cases where those are implicit defaults, like 100 on non-trunk roads away from built up areas in Germany (which is complicated enough to derive from the data), or 130 for trunk roads (although most often there are lower limits), or 50 in cities (as the most often down-signed default). So if there is any QA tool that detects that, I fear it uses third party sources, a reporting system similar to the notes feature, but using a different channel, or it is restricted to some cornercases only. I doubt there is something like that which could make notes about speed limit errors in osm obsolete. IMHO notes are to be checked in person on the ground usually. If there's nobody in France to do that, yes, then notes will remain in the database for a long time, but basically they stay correct: Here is something missing or wrong, please check that on the ground. regards Peter Am 29.07.2014 um 11:09 schrieb JB: I don't necessarily want to analyse once more how the notes are opened, closed or not closed and to what aim, nor analyse the end of OpenStreetBug life and the quality of the remaining bugs, but in France, I have never ever seen anyone comment on someone else's note (or « resurvey »). The only comments I have seen were from the note opener, when prompted by a potential corrector. So a note which indicates « probably 90km/h here » or « speed limit is not 0km/h » may remain there for years (yes, years), demotivate potential note closers, never be closed. I do not think they participate to a high quality note db. There are quality assessments tools around that allow contributors to detect where speed limits are missing. JB, with perhaps some bad faith in there, but not that much. Le 29/07/2014 10:19, Steve Doerr a écrit : On 29/07/2014 08:32, JB wrote: Anyway, as for most notes concerning speed limits, if you do no have the beginning and the end of the limit, at least in France, the information is quite useless. Are we all armchair mappers now? Surely the note should prompt someone local to go out to the location and find out where the speed limit starts and ends? ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Bltzer auf Weg oder nicht?
Hallo Ronnie, also im Code des OsmandMapCreators sehe ich eine Auswertung genau der enforcement-Relationen, nämlich hier [1]. Ich würde das so interpretieren, dass Relationen (Z. 127) mit type=enforcement und enforcement=maxspeed (Z. 138) besitzen, durchaus berücksichtigt werden sollten, und zwar werden alle Nodes (keine Ways etc!, Z. 144) mit er Rolle from (Z. 140) mit einem speedCamera-Attribut ausgezeichnet. Dieser Code ist jedoch erst seit dem 1. März 2014 in github, möglicherweise sind deine/eure Tests, dass Osmand das nicht unterstützt, deshalb veraltet. Vielleicht lohnt es sich also, mit einer aktuellen Karte, notfalls mit dem osmandmapcreator aus dem git-repository selbst erzeugt, nochmal zu testen. Gruß Peter [1] https://github.com/osmandapp/OsmAnd-tools/blob/2d7f1eefea915e5f619cd19c297434122b0d7ab8/OsmAndMapCreator/src/net/osmand/data/preparation/IndexRouteCreator.java#L125 Am 21.07.2014 09:08, schrieb Ronnie Soak: Hallo, deutsches [1] und englisches [2] Wiki divergieren hinsichtlich der Benutzung des highway=speed_camera tags. Auf der englischen Seite steht, das tag gehört an die Kamera (= an ihren Aufstellungsort), deren Bezug zu einem Weg dann per relation (type=enforcement) dazu. Im deutschen Wiki wird die Relation zwar erwähnt, dafür fehlt der Hinweis, die Kamera an ihrem eigentlichen Platz zu mappen. Stattdessen gibt es unten einen Absatz, der beschreibt man möge doch auf einen Knoten auf dem Weg mappen, damit OSMAND damit umgehen kann. Könnte ich da mal ein Meinungsbild haben, ob das jetzt a) plumpes Taggen für einen speziellen Router ist und aus dem Wiki entfernt werden sollte b) zwar plumped tagging für eine speziellen Router ist, aber aus anderen Gründen trotzdem vernünftig ist und man das drinlassen sollte (als deutsche Sonderlösung gekennzeichnet) c) die Funktionsfähigkeit von OSMAND wichtig genug ist, unser Taggingschema daran anzupassen und auch die internationale Community anzusprechen um es im engl. Wiki zu ändern. (Ja, ich meine das Ernst.) Gruss, Chaos ___ 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] wie tagge ich Zeltplätze?
Falsch, wieso muss jedes Tag gerendert werden? Und wieso in jeder Karte? Routen z.B. (Bus, Wanderwege etc) sind auf der allgemeinen Karte nicht sichtbar, und würden da eher stören, weil die vergleichsweise voll ist; in den Spezialkarten sind die aber super. Abbiegebeschränkungen kann man rendern, muss man aber nicht - die sind insbesondere fürs Routing interessant. Tagging-Schemata für Adressen (über Hausnummern hinaus; also z.B. associated street, addr:street, addr:postcode, addr:city, ...) sind, wenn überhaupt notwendig, für die übliche Karte uninteressant in der Darstellung, aber eine gute Sache für Geocoding, Suche und ähnliches. Wenn man das - wie du vorschlägst - mit einem (!) Rendering-Vorschlag abtut, kann man nur eine Karte berücksichtigen. Die nächste Karte benutzt Symbolpatterns statt Farben, die wieder nächste muss noch im Vier-Farb-Druck oder in Graustufen funktionieren, und noch eine andere beschränkt sich auf dieses eine Feature und hat deshalb überhaupt kein Problem, eine konfliktfreie Darstellung zu finden. Gruß Peter Am 08.07.2014 07:16, schrieb Markus: Moin Henning, gute Idee: osm-Dateien ins wiki laden oder man taggt ein Beispiel in OSM Service Render mir mal die folgende osm-Datei in render-style Zu jedem Tagging-Vorschlag gehört immer auch ein *Rendering-Vorschlag* mit Rendering-Regeln, Icons, Flächen-Farben und -Mustern. Nur so kann man sehen, wie das Grün vom Campingplatz mit dem Grün von Wald, Wiese, Fussballplatz, Kinderspielplatz, etc. zusammenspasst. Und was es für einen Unterschied macht, welche Flächen man wie übereinander zeichnet oder ausschneidet (Teilmenge, Schnittmenge, Vereinigungsmenge, A ohne B, Differenzmenge). Gruss, Markus ___ 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] Reisebüro mit DB-Kartenverkauf. Wie eintragen?
Hallo Manuel, das würde ich gar nicht mit eintragen - sonst müsstest du das konsequent gleich für jede Flug- und Fernbusgesellschaft, Reederei und Bahngesellschaft etc. eintragen; und Gebühren sind bei vielen wenn nicht allen Reisen, die du übers Reisebüro buchst, vorhanden - ob die dann Gebühr genannt werden oder die Provision direkt eingepreist ist, ist ja irrelevant. Sogar die Bahn-Schalter selbst nehmen ja Aufpreise gegenüber dem Kauf am Automaten. Das dürfte sich praktisch nicht abbilden lassen; insofern würd ichs weglassen. Gruß Peter Am 05.07.2014 11:17, schrieb Manuel Reimer: Hallo, viele Reisebüros (in Deutschland) bieten auch Beratung zu Bahnfahrten an und verkaufen auch Bahntickets. Gibt es schon einen Taggingvorschlag wie man das bei einem Reisebüro mit hinterlegen kann? Zumindest das Reisebüro, bei dem ich bisher meine Tickets gekauft habe, verlangt seit neuestem auch eine Gebühr für den Kartenverkauf und Fahrplanauskünfte. Wie würde man diese Gebühr hinterlegen? Danke im Voraus Gruß Manuel ___ 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: [OSM-talk] Come back Osmarender, all is forgiven!
Hi, I agree that the render-all-approach is useful in some cases, but - on which ones? In low zoom levels (z0-15) it tends to get overwhelmingly cluttered by features while on the other hand lots of them have to be dropped at random because of geometric restrictions - there's limited space on the canvas, and nothing will change that. In high zoom levels I would like to see something like that, but usually that's beyond z18, probably even beyond z19. Perhaps we shouldn't cry to get osmarender back but instead to get a vector rendering solution for high zoom levels, rendering in the browser and allowing the user to define what should be rendered and what should not. I'm not entirely sure how that would look like, but a long list (with filtering capability) of items to show or hide might be a starting point, and if you really want you could check all and get your unusable cluttered map - but you may be able to specify exactly what you want to see rendered (and, who knows, perhaps even how it's diplayed). regards Peter Am 23.06.2014 13:56, schrieb SomeoneElse: There have been lots of changes to the standard style sheet recently (e.g. [1]). The resulting map looks much nicer (farmland and other landuse much less glaring, names that really make no sense to be shown on a general map aren't). There have however been some unintended consequences of the changes. A number of abandoned railways near me were edited from abandoned to disused; I'm guessing that it might be because of the recent changes. Changeset comments along the lines of changed to X so that it renders and I know we're not supposed to tag for the renderer but what's the point in mapping a feature which then doesn't appear are relatively common. The question, I suspect is what is the Standard style on the OSM website for? It used to be for mappers, but a nice rendering; one that you might actually use as a punter too. Back when Osmarender [3] existed, that was the if you want to see everything render, look at the instead option. The removal of features (see [2]) that people actually use means that the Standard style isn't really for mappers any more - it's a nice (very nice, actually) generic map style, but not one that you can use to make sure that what you've mapped is technically correct (e.g. joined polygons up properly). So, where's the replacement for Osmarender? I'm sure that someone, somewhere, will have created a CartoCSS style file that is much closer to show everything than openstreetmap-carto currently is. Currently for my own use I'm still using the standard style but at database update adding back in some of the recent removals (see [4] - it also does some England and Wales rights-of-way stuff). However, as the standard style becomes nicer it's becoming increasingly clear that it's not the best place to start from. The question is, what is? Cheers, Andy [1] https://lists.openstreetmap.org/pipermail/talk/2014-June/069959.html [2] https://github.com/gravitystorm/openstreetmap-carto/pull/542 [3] http://wiki.openstreetmap.org/wiki/Osmarender [4] https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Worldwide non-surveyed tag edits
Hi, I think two issues are mixed here that shouldn't be. One thing is the question about mechanical edits, the other thing is more about unifying edits. The latter occurs most often on mechanical edits, but it seems the two issues are seen as equal what I don't think they are. I would combine both to algorithmic edits. It's not different wether I use overpass, josm selection by filters and beyond that mouse and keyboard to change all tags from A to B or to delete objects that correspond to a certain condition or if I do that using a fully automatted script. In both cases it's dangerous to make a mistake. And in neither case I can or do any individual check for each object. In both cases - but, yes, even more on the bot/script way of doing that stuff, is the danger to make errors. The first error class is a technical one, which is more likely on the script approach then on the nearly-manual mass editing. The other class of errors occurs earlier: When deciding to make an edit. Changing amenity=restaurante to amenity=restaurant (no idea if that's a common real-world bug) seems to be clearly a good way to achieve, and there are typos that are definitivly typos. But where does a typo get a semantical difference? Sometimes even people unify stuff by look-alike semantical identity, which, looking more closely on the issue isn't. In these cases we have a problem in the tagging perhaps, but not at first a problem of synonymous tags, but about IF they have the same meaning. To conclude: There are IMHO at least two reasons why large scoped edits should be discussed and therefore be in some kind of policy: If you fail on a large edit, you break a large amount of data. That's why you should let others look and verify what you're going to 1) make sure no technical bug appears 2) make sure you didn't oversee something, e.g. a different meaning of a tag or tag combination. regards Peter Am 11.06.2014 15:06, schrieb Jochen Topf: On Mi, Jun 11, 2014 at 01:55:41 +0200, Christoph Hormann wrote: On Wednesday 11 June 2014, Jochen Topf wrote: I think the mechanical edits policy has stepped over the line here. A mechanical edit is one where somebody uses a special program that, based on some simple criteria, does *automatic* changes. Using existing tools like JOSM and XAPI to find problems, looking at them manually and doing edits, is not a mechanical edit and should not fall under that policy. And i think it does not. The policy is probably not worded in the clearest possible way but it has always been my interpretation that the key question is if the modifications made to the database are individually verified by the mapper, not if you use some fancy filtering to find those objects you want to modify. I think we are probably in agreement here. My looking at them manually might be a very bad wording, but it meant the same as your much better individually verified. But the policy first disallows all of this and then makes the exception if you check each individual action caused by this then its okay. Thats the wrong way around. It means I have to defend myself when doing this. It means I have to prove that I am not doing anything wrong. Of course I have to verify that what I am doing is okay, that is the default anyway. But we are still measuring with two different sticks if we single out edits based on filters or whatever and not treat them like edits based on 20 year old sat images or whatever. Jochen ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Falsches Kartenmaterial Google statt OSM
Hallo Helmut, die Karten die da angezeigt werden sind dann auch OSM-Karten, das große google-Logo kommt von der Javascript-Bibliothek, die die für die Anzeige nutzen. Die Attribution für OSM fehlt aber schlichtweg, was nicht okay ist. Gruß Peter Am 29.05.2014 11:11, schrieb Helmut Kauer: Griaß eich, bin gerade auf /http://www.deine-berge.de/[1] gelandet. Dort kann man bei den Karten OSM abrufen und landet bei google. Hab den Seitenbetreiber bereits angemailt. Gruß Helmut ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ARD Ratgeber: Internet - Alternativen zu Google-Maps Open Source
Danke für den Link, Fazit: OSM schneidet schon verdammt gut ab. Selbst bei deren eigener Zählung Co-Sieger; und wenn der Tippfehler nicht gewesen wäre (bei dem sie durchaus recht haben, was die Benutzerfreundlichkeit angeht), und wenn sie nicht ausgerechnet den Openrouteservice erwischt hätten als Routenplaner, dann wäre OSM eindeutig als Sieger daraus hervorgegangen. Natürlich ist die Stichprobe zu klein - aber ich würde das positiv sehen: Wir als OSM sind schon verdammt gut mittlerweile. ;) Gruß Peter Am 24.05.2014 21:25, schrieb Andreas Goss: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-100.html ## Direktlinks: Alternativen zu Google-Maps: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-106.html Deeplink: Open Source: http://www.daserste.de/information/ratgeber-service/internet/sendung/wdr/sendung-vom-24052014-110.html ___ 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: [OSM-talk] OSM France BANO project... openaddresses in France
Hi Christian, The BANO data is licensed under ODbl, but the database does not conform to the Contributor terms, right? That's why importing or adding it to OSM is not possible IMHO. Adding it to (the osm installation of) nominatim on the other hand is a bad idea, I think: IMHO nominatim.openstreetmap.or should rely on OSM as a data source as pure as possible. Adding different data sets might be useful to add information not possible or out of scope of the osm database (like importance factors using the wikipedia links), but BANO is a different thing. If the BANO addresses are free and open enough for OSM, we should encourage to work on bringing them to the OSM database itself (provided, they are GOOD enough as well). How should anybody in France get motivation to collect more addresses for the osm database itself, if anything is available in BANO already? Nominatim as well as the maps presented by the project on osm.org IMHO should show the strengths of OSM, and not lie about it by presenting stuff that's not part of OSM (like addresses from different databases). regards Peter P.S: Of course this is not meant to deal with the software as such, but for the installations/instances officially part of OSM. Feel free to set up an BANO nominatim server to show the strength of BANO instead. Am 24.05.2014 11:57, schrieb Christian Quest: I'm happy to announce that we have finished our first building phase of the BANO (Base d'Adresses Nationale Ouverte) the first french adresses dataset available under an open license (ODbL). It contains data from: - OSM - available opendata datasets - automatically collected cadastre data The first experimental dataset are available for download at http://bano.openstreetmap.fr/data/ as: - shapefiles - csv files - github projet based on the csv files (this allows to have diff and archives of all versions) on https://github.com/osm-fr/bano-data This dataset has even been published on our national opendata portal: https://www.data.gouv.fr/dataset/base-d-adresses-nationale-ouverte-bano The global database contains around 17M addresses, and the current output dataset is around 12M addresses. It would be really great if this dataset could be added to Nominatim to extend its geocoding capabilities in France where we only have around 2M addresses currently. We're not pushing the community to import these data in OSM, but to fill the holes in street names first. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM France BANO project... openaddresses in France
Hi Christian, (shortening the last message to comment on some parts only) Am 24.05.2014 16:04, schrieb Christian Quest: BANO is not designed to be used as an import source for OSM. It uses sources (opendata, cadastre) that can be imported in OSM. These sources have been used over the past years and will still be used to add addresses in OSM, one at a time, or street by street which will take years before completion. So, BANO is there to allow to use all the available address data right now without having to wait years to get them cleanly added to OSM. I agree - but why should anybody add the data manually to osm if it's even not visible any more where data is missing, as in Nominatim both sources look the same. This has one good side effect... reduce the pressure on massive address imports in OSM and give us the opportunity to improve the quality thru survey prior to add it to OSM. I agree if you propose BANO as a data source for any private or third party setup of nominatim or openstreetmap data, but I oppose it to be used in the projects instances. Mappers detect errors and missing data while using these instances. I add missing streets occasionally after I failed to find them in OSM - using the map renderings, nominatim or other tools. I wouldn't even detect that they are missing when nominatim would return the results from another source. 2014-05-24 12:58 GMT+02:00 Peter Wendorff wendo...@uni-paderborn.de: Adding it to (the osm installation of) nominatim on the other hand is a bad idea, I think: IMHO nominatim.openstreetmap.or should rely on OSM as a data source as pure as possible. Adding different data sets might be useful to add information not possible or out of scope of the osm database (like importance factors using the wikipedia links), but BANO is a different thing. If the BANO addresses are free and open enough for OSM, we should encourage to work on bringing them to the OSM database itself (provided, they are GOOD enough as well). How should anybody in France get motivation to collect more addresses for the osm database itself, if anything is available in BANO already? I'm pushing the french community to be more motivated on having all streets and all streets name in OSM (BANO allowed us to detect 40% missing streets or street names) more than adding addresses without surveying them. Great - but I fear, the availability of third data sources like BANO through the usual tools destroys motivation again, the motivation get's an extrinsic one, because the intrinsic need of mappers to get rid of errors and missing results using OSM is missing due to results returned out of the BANO data. I agree to motivate to collect BETTER address data... it we collect the same data with the same quality level it looks to me more losing our time than anything else. Mappers are better than you might think. Collecting the same data with the same quality level is not possible. 1) the data is checked in reality = so survey on the ground increases quality with respect to errors. 2) the data is correct at the date of the survey = where it is done it's more up to date than any imported data, but of course only where it is done. 3) When a mapper goes out to add streets and house numbers, it's easy to collect any other stuff where there is no other data source available. post boxes, benches, vending machines, opening hours, surface of the streets and much more stuff that increases quality. In contrast importing data is restricted to the data contained in the data source. P.S: Of course this is not meant to deal with the software as such, but for the installations/instances officially part of OSM. Feel free to set up an BANO nominatim server to show the strength of BANO instead. In that case remove geonames and TIGER address search from osm.org Nominatim instance. On osm.org Genonames is a different search result set, distinct from Nominatim, there are two different query results returned. This is a good way to go, and yes, it might an idea to do the same with BANO - but that's not what you proposed: it's not adding the BANO data to Nominatim. regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Hausnummern-Mapping
Am 24.05.2014 10:17, schrieb Bernhard Weiskopf: Von: Andre Hinrichs [mailto:andre.hinri...@gmx.de] 1.) Fehlende Hausnummern: Manchmal steht die Hausnummer nicht am Haus, sondern nur klein in der Nähe des Briefkastens. stimmt Oft helfen Internet-Suchmaschinen: 1. Namen an der Klingel oder am Briefkasten gelesen - Danach suchen 2. Suche nach vermuteten Hausnummern Irgendwo (Telefon-Verzeichnisse oder sonstwo) werden weitere Adressdaten damit verknüpft gefunden. Diese Informationen sind nur meistens entweder falsch oder nicht als Quelle erlaubt. Ich weiß - theoretisch kann man hier Einzelfall und damit zu geringe Menge übernommener Daten annehmen, aber das gälte eben nur im Einzelfall; Internetsuche als Quelle zu nutzen läuft, auf OSM insgesamt gesehen, eben doch zu einer Übernahme zu vieler Daten hinaus, und damit wäre das nicht mehr erlaubt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hausnummern-Mapping
Einfach Mapping-Spaziergang nach Müllabfuhr-Kalender planen ;) Gruß Peter Am 24.05.2014 12:23, schrieb Michael Reichert: Hallo, Am 24.05.2014 12:18, schrieb simson.gert...@gmail.com: Noch ein Geheimtipp: Häufig steht die Hausnummer auch auf der Mülltonne (entweder ganz groß oder auch als kleiner Aufkleber vom Entsorgungsunternehmen) und kann eine vermutete Hausnummer bestätigen. Wenn man an die Mülltonne einigermaßen legal rankommt (und die nicht weit im Privatgrundstück steht, das man nicht betreten darf), wäre das eine Option. Ich glaube aber, dass man beim Mülltonnenmappen noch auffälliger ist, als nur mit Klemmbrett oder Smartphone unterwegs zu sein. Viele Grüße Michael ___ 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] Wegenamen in Kleingärten
Am 18.05.2014 15:37, schrieb Wolfgang Hinsch: Hallo, in vielen Kleingartenanlagen vergeben die Kleingärtner Wegenamen nach eigenem Ermessen. Das führt dann dazu, dass z.B. der Dahlienweg in HH 10x oder öfter existiert, davon aber nur 1x offiziell von der Stadt benannt und in öffentlichen Verzeichnissen vorhanden. Wenn das Tag name für diese Wege benutzt wird, macht das die Navigation nach OSM-Daten unbrauchbar, für jeden Navi-Benutzer wie für Rettungsdienste, Taxi etc. Ich würde vorschlagen, in Fällen, in denen der Name nicht offiziell ist (es gibt auch offizielle Namen), das Tag loc_name zu benutzen, da der Namen nur lokal im Bereich der jeweiligen Gartenanlage gilt. Name sollte dann nicht vergeben werden. Aber das sind offizielle Namen. Das Gelände ist dann ein Privatgelände des Kleingartenvereins, der deshalb die Namenshoheit über die darüber verlaufenden Privatwege hat. Es gibt auch Städte, in denen 30 Restaurants mit dem Namen McDonalds existieren - ganz offiziell. Gegenargument der meisten Mapper dürfte sein: Dann steht der Name aber nicht in der Karte. Das ist einerseits Mapping für den Renderer versus Mapping für den Router, andererseits On The Ground steht der Name dran, aber er ist On The Ground ebenfalls nur gültig im lokalen Bereich, nicht etwa gemeindeweit. Du nimmst hier eine willkürliche Perspektive mit dem Fokus asuf die Gemeinde an. International haben wir auch Fernstraßen, die vermutlich mehrfach vorkommen, und etliches mehr. Vielleicht könnte man durch ein Ticket erreichen, dass bei fehlendem Name-Tag an Verkehrswegen auf ein loc_name-Tag geprüft und dieses in Z17-19 angezeigt wird. loc_name ist der lokal genutzte Name, aber es wird ja nicht regional bzw. nicht-lokal dann gar kein Name genutzt. Es geht doch nicht darum, mit loc_name einen über-lokal genutzten Namen zu vermeiden, sondern eine Verdrängung dessen zu vermeiden. Wenn etwas einen Namen hat, sollte es auch in OSM einen Namen haben - und nicht nur einen official_, log_ oder alt_name. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] OSM France BANO project... openaddresses in France
I agree that it's unlikely to drop the share-alike clause in future. But nevertheless there may be another license, and this has to be possible even for imports. In fact, third data sources must agree to be published under ODBL (as that's the current license) and the owner has in fact to agree with the Contributor terms, which includes the relicensing term as stated there. It's not the importing osm user alone who has to agree to the CT, but the vendor of the imported data as well. If they do, import can be done. If not, then not. The contributor terms basically state that anyone who agrees is aware of and allows the data imported to osm to be relicensed later under some conditions to any license that fulfills some other conditions. This IMHO (but I am not a lawyer) includes CC-0 and PD, and as far as I know includes licenses requiring attribution - with the waiver that attribution for each contributor may be given indirectly by linking to the general osm copyright page. It may not include any license with any additional restrictions. CC-BY as such allows the licensor to define how attribution must be given, so it may be okay for imports - or not. CC-BY-SA without modifications is not okay as the share-alike does not include any other license (sometimes apart from later versions of cc-by-sa itself). regards Peter Am 16.05.2014 10:22, schrieb Pieren: On Fri, May 16, 2014 at 7:57 AM, Jean-Marc Liotier j...@liotier.org wrote: We are not going to comply with hypothetical licenses that may or may not appear in the future. +1 We already get feedbacks from contributors refusing to change the share-alike condition. And I cannot imagine that OSM will forbid external sources fully compatible with the current licence just for the hypothetical case of a possible licence change in the future. Or try to change the licence now. It would be interesting to see if you will find 2 third of active contributors accepting to remove the share-alike attribution. Or in a similar way you consider imports and by honesty, inform the current contributors that if they don't accept to remove the share-alike in the future, they should stop now. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] This has to stop: User Diaries Spam
Hi David, that's right and that's why I would prefer a good way to moderate the diaries directly, too. But nevertheless the value of a spam entry in the diaries is increased by tools like this because deletion would require deletion at at least two places. regards Peter Am 15.05.2014 00:33, schrieb David Earl: Just to say, @osmblogs is not the diaries, it is just a conversion of the osm aggregate blogs RSS feed, using ifttt.com. If spam were not in the RSS feed it would not be on twitter either. David ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Command-line program to remove untagged, unconnected nodes from .osm file
Unfortuately you're wrong here, as it does not keep untagged, but connected nodes. regards Peter Am 14.05.2014 11:16, schrieb Dominik George: Hi, I am trying to find a way to get rid of untagged, unconnected nodes in a .osm file. I know JOSM can do this but I need a command-line application. I've been trying to do it with osmosis and osmfilter without success (pattern *=* not allowed). Any ideas? If your data file is well-formed, a simple grep will do: grep -v node .*/ Cheers, Nik ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] 3D-Mapping
Am 07.05.2014 18:20, schrieb Thorsten Alge: Ich wuerde jemanden, der sehr viel Aufwand in Details steckt und auch offensichtlich ausreichend Grundwissen beim Editieren besitzt, nicht gleich an den Pranger stellen. Sonst landen wir in der gleichen Situation wie Wikipedia. Sehe ich auch so. Neben Worst-of-OSM wäre ein Art-in-OSM Blog eig. auch ganz cool. Diese easter-eggs könnte man meiner Meinung nach ruhig ein dreivirtel Jahr belassen - ist ja immer nett über sowas zu stolpern. Und einen Export + Screenshot kann man ja dann in dem Blog auch längerfristig Archivieren. Denke so viel künstlerisches Talent sollte man auch positiv würdigen und eine Zeit lang belassen. Nur wenn es tatsächlich Probleme bereitet sollte man früher agieren. -10 Diese Easter-Eggs sind nicht immer nur Häuser, sondern gerne auch mal zusätzliche oder falsche Straßen, nicht routingfähige Strecken oder sonst was - vorgestern gab es im Chat das Beispiel, wo jemand rund um ein Haus einen Parkplatz-Weg als Autobahn eingetragen hat, sah hübsch aus, war aber eben völlig falsch. Ein dreiviertel Jahr drinlassen bedeutet, dass die Daten für 9 Monate falsch in der Datenbank stehen, falsch auf der Online-Karte und falsch im Routing liegen. Dass sie für vermutlich ein weiteres Jahr auf den meisten Offline-Navis falsch drauf sind, und ein weiteres Jahr auf gedruckten Karten. Jeder Tag, den die Daten falsch in der Datenbank stehen, vervielfacht die Anzahl der offline-Daten, die aus den falschen Daten erzeugt werden, und nichtmal alle Mapper aktualisieren osmand-Karten und ähnliches alle paar Wochen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik nicht für MOB AC und Oruxmap
Hallo tshrub, die Tile-Usage Policy gibt es schon ziemlich lange, das ist vermutlich nicht das Problem. Für Anwendungen, die sehr wenig oder durch sehr wenige genutzt werden, fällt das aber nicht unbedingt sofort auf, ein Grund, warum Mobac und Orux maps zunächst bei dir funktioniert haben dürften. Seitens OSM ist das völlig in Ordnung: Das Projekt sagt zur Nutzung der Kacheln ganz klar, dass das massenhafte herunterladen nicht erlaubt ist. Wer da nicht hingehört hat, das sind die Entwickler von Mobac und Orux - zumindest eben zunächst. Die sind dann darauf hingewiesen worden und irgendwann wurden die Anwendungen gesperrt. Würde OSM das nicht tun, wären die Server irgendwann überlastet oder nicht mehr finanzierbar, weil jeder exzessiv die Daten nutzen würde wie er möchte. Insofern: Ja, die Sperre kommt von OSM, aber Nein: nicht unerwartet oder unangekündigt, und nicht unvorhersehbar. Was das mit neuen Geräten zu tun hat, weiß ich nicht - die Sperre von OSM hat jedenfalls nichts mit deinem Gerät zu tun, sondern alleine mit genau den beiden Programmen. Zu kurz gedacht ist das - und nimm mir das nicht übel - höchstens von dir und eben von den Entwicklern der Anwendungen: Von dir, weil Du dir (bisher) keine Gedanken darüber machst, warum diese Sperren notwendig sein könnten, sondern dich gleich bei OSM beschwerst (die Apps wären die richtigere Anlaufstelle, obwohl dir hier sicher auch geholfen wird, wenn jemand helfen kann und du konkrete Fragen stellst - z.B. hast du schon einen Grund für die Fehlfunktion deiner Anwendung und eine mögliche Lösungsstrategie (update) gekriegt). Von den Entwicklern der Anwendung, weil sie nicht mit so großen Nutzerzahlen gerechnet haben ursprünglich - oder, weil sie die Usage Policy bewusst ignoriert haben. Zu kurz gedacht von OSM wäre, wenn jeder Tiles in beliebiger Menge herunterladen könnte; denn dann bestünde die Möglichkeit, dass die Server für niemanden mehr bezahlbar bliebe, was im Endeffekt schlimmer ist als ein paar Anwendungen auszusperren, die sich meinen über Regeln hinwegsetzen zu können. Gruß Peter Am 30.04.2014 10:52, schrieb tshrub: Am 30.04.2014 08:42, schrieb Simon Poole: Am 30.04.2014 02:45, schrieb tshrub: ... Kennt jemand ggf. eine Möglichkeit, Mapnik in o.g. wieder nutzen zu können? Aktuelle Versionen der Apps zu nutzen. Alte Version der Apps sind gesperrt weil Sie sich nicht an die tile usage policy gehalten haben, logisch ... die gabs wohl noch nicht so IMHO sollen bei den beiden erwähnten Programmen das bei neueren Version behoben sein. beim MOB AC habe ich ein Update gemacht - ohne Ergebnis bzgl. Problems. Vielleicht müsste man ihn einmal komplett inkl. Einstellungen von der Platte löschen ... Allg. ist das aber Seitens OSM nicht ok. Kommt der Dongel nicht von da? Wieso sehe ich nicht, was ich online sehe kann auf den Geräten? Das lief doch vorher. Wieso wird man gezwungen, neue Geräte zu kaufen? M.E. hier zu kurz gedacht. Gruß, t. ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Tags = Schlagwörter
Nochmal hallo. Nachdem die Diskussion ja doch nicht so eindeutig verläuft wie ich zunächst erwartet hätte (gegen die Übersetzung des Wortes Tag bzw. Tags, hier noch ein paar weitere Argumente: - Das Wiki ist teilweise übersetzt, normalerweise wird aber auch hier und auch auf den deutschsprachigen Seiten der Begriff Tag verwendet, soweit ich das sehe. Da damit die primäre Dokumentations-Resource für Mapper keine Übersetzung verwendet, sollte IMHO auch eine Software wie JOSM keine Übersetzung verwenden. - Im Gespräch mit anderen Mappern - ob im Chat, im Forum, auf den Mailinglisten oder anderswo wird üblicherweise das Wort Tag einfach genutzt. Zugegeben: Das sind meist Mapper, im Durchschnitt vermutlich auch eher erfahrenere - trotzdem sind Anfänger auch hier mit dem Wort so konfrontiert. Deshalb halte ich die Übersetzung für falsch. Die Fachsprache von OSM existiert, und sie gezielt vor Anfängern zu verstecken hilft meines Erachtens nicht. Wenn sie tatsächlich die Einstiegshürde verringern sollte (möglich, aber ich würde nicht darauf wetten), dann wird die Hürde zwischen Anfänger und Fortgeschrittenem entsprechend höher. Gruß Peter Am 27.04.2014 13:59, schrieb Frederik Ramm: Hallo, gerade ist mir aufgefallen, dass mein JOSM, wenn ich ihn auf Deutsch einstelle, die Tags neuerdings als Schlagwörter bezeichnet. Findet irgendjemand das gut (bzw. findet irgendjemand das besser als Eigenschaften)? Gibt es irgendwo, unabhängig vom konkreten Fall JOSM, einen Konsens oder zumindest eine Diskussion dazu? Gibt es andere Software oder Dokumentation im OSM-Umfeld, in der Tags als Schlagwörter bezeichnet werden? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM: Tags = Schlagwörter
Hi, ist mir bisher noch nicht aufgefallen, aber halte ich für irreführend. Tags im Allgemeinen können Schlagwörter sein, in OSM sind sie mehr als das, sie sind Attribute. Ein Schlagwort ist eben keine Eigenschaft, kein Attribut, sondern eher eine Assoziation, ein Suchbegriff oder ähnliches. Das Ziel in OSM wäre ja im Grunde eine eindeutige Beziehung Tag(s) - Eigenschaft(en), wo man also aus den Tags Eigenschaften der Realität ableiten kann und andersherum aus der Realität die notwendigen/sinnvollen Tags ableiten könnte. Wären Tags Schlagworte, dann wäre beide Richtungen dieser Beziehung undeutlicher als sie sein sollten. In der Realität sind manche Tags so schwammig definiert oder so schwammig interpretiert, dass der Begriff schon fast stimmt - aber das sind schnell genau die Diskussionsfälle, die schwieriger anzuwenden und noch schwieriger zu mappen sind, wenn man gute OSM-Daten erzeugen will. Insofern halte ich Schlagwort für die denkbar falsche Angabe, erst Recht im Editor, wo es falsche Vorstellungen gerade bei unerfahrenen Mappern wecken könnte. Gruß Peter Am 27.04.2014 13:59, schrieb Frederik Ramm: Hallo, gerade ist mir aufgefallen, dass mein JOSM, wenn ich ihn auf Deutsch einstelle, die Tags neuerdings als Schlagwörter bezeichnet. Findet irgendjemand das gut (bzw. findet irgendjemand das besser als Eigenschaften)? Gibt es irgendwo, unabhängig vom konkreten Fall JOSM, einen Konsens oder zumindest eine Diskussion dazu? Gibt es andere Software oder Dokumentation im OSM-Umfeld, in der Tags als Schlagwörter bezeichnet werden? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik ohne Richtungspfeile
Dieses ewige Gejammere geht mir auf den Sack, sorry. Im alten Stil wurden ähnlich wie jetzt immer wieder neue Wünsche geäußert: Bitte dies darstelle, bitte jenes darstellen. Das Einarbeiten dieser Wünsche wurde denen, die es überhaupt tun, zu kompliziert, weil die Stildateien immer größer und unhandlicher wurden. Es hätte also drei Möglichkeiten gegeben: 1) Jemand anderes hätte die Arbeit übernommen - das ist zumindest sehr lange nicht passiert 2) Der Stil wäre einfach nicht mehr geändert worden (damit hätten wir das gleiche Problem wie jetzt bei jedem neuen Tag oder Taggingschema) 3) Man packt das ganze neu an und macht dabei diverse Dinge sauberer und aus dem Grunde auf Dauer besser handhabbar. Da (1) und (2) nicht passiert ist, sich aber jemand an (3) herangewagt hat, gibt es jetzt also einen neuen Stil, an dem lange gearbeitet wurde, bevor er öffentlich sichtbar gemacht wurde, und der erstaunlich nah am alten Layout dran ist. Der Wechsel ist vom August 2013. Seitdem sind laut GitHub 500 Fehlermeldungen und Verbesserungsvorschläge eingereicht und davon über die Hälfte erledigt worden, immerhin von einer Reihe von Leuten, vn denen insbesondere Andy (gravitystorm) und dann mit großem Abstand math1985 aktiv sind. Die Stile sind - insbesondere technisch gesehen - nicht identisch. Das ist gewollt und richtig so. Früher wurde der name-Tag immer dargestellt. Wenn Platz auf der Karte ist und ein Objekt einen Namen hat, dann zeige den Namen. Um dann gezielt zu sagen: Aber Namen von Parkbänken sollen eben gerade nicht dargestellt werden, weil die (außer vielleicht in z19) sonst alles andere verstecken, hätte man das sozusagen ändern müssen in Zeige alle Namen, solange die nicht zu einer Parkbank gehören. Aus einer einfachen Regel wird bei ein paar Dutzend solcher Ausnahmen dann schnell ein schwerfälliges, langsam berechnetes etwas, und herauszufinden, wo man eine Änderung einpflegen muss, ist schwer. Stattdessen ist viel Arbeit reingesteckt worden, um ein möglichst ähnliches Kartenbild andersherum zu erreichen: Statt: Rendere alle Namen außer [lange liste von ausnahmen] soll also jetzt da stehen Rendere namen von [lange liste von Dingen, deren Namen dargestelllt werden müssen - und, was noch besser ist: das lässt sich jetzt shcön aufteilen in mehrere Regeln: Rendere Namen von Grenzen schön jeweils 'innen', Rendere Namen von Geschäften Zeige Hausnummern in Schriftart X und Größe Y, Geschäfts-Namen aber in X und Größe W und so weiter. Das macht das Pflegen des Stils einfacher, aber neben der Frage: was lässt man bewusst weg (und guckt mal, ob jemand hinterher danach fragt), ist die Umformulierung nicht so einfach, denn Rendere alles außer... erfordert nur ein Wissen über die Ausnahmen, während Rendere genau... voraussetzt, dass man letztlich jedes Tag, das man darstellen will, kennt und angeben kann. Insofern ist gewollt, gut und richtig, dass wir alle Auffälligkeiten wie fehlende Beschriftungen etc. melden und mitteilen. Sich aber zu beschweren, vorher sei alles besser gewesen setzt meiner Meinung nach voraus, das zu beweisen. Ich vermute, der alte Mapnik-Stil ist heute langsamer in der Darstellung (ganz wage Vermutung aus den mir bekannten technischen Unterschieden, was Datenbank-Abfragen angeht), und er ist bestimmt in 'nem halben oder ganzen Jahr auch besser als der alte. Nein: Die Maintainer des alten Stils wollten nicht mehr daran weiterarbeiten und hätten das vermutlich auch nicht mehr besonders aktiv gemacht. Um also die Behauptung aufzustellen, dass der neue Stil dauerhaft schlechter ist als der alte, und euch damit die Rechtfertigung zu verdienen, möglicherweise zu meckern, bitte ich dann darum, Fehler im alten Stil zu korrigieren - der Code ist auch da frei verfügbar. Ansonsten: Fehler finden ist gut, Fehler melden auch - dafür gibt's den Bugtracker bei Github; Fehler laut an alle rauszuschreien aber nicht da, wo sie behoben werden könnten, hilft aber kaum, sorry. Gruß Peter [1] https://github.com/gravitystorm/openstreetmap-carto/graphs/contributors Am 24.04.2014 21:56, schrieb Dirk Sohler: Holger Jeromin schrieb: http://bl.ocks.org/tyrasd/raw/6164696/#17.00/50.75168/6.02481 Vorher war die Grenzbeschriftung total nutzlos, jetzt sehr hilfreich. Also entweder gut beschriftete Grenzen und komplett unbeschriftete Tunnel, oder beschriftete Tunnel und eher schlecht beschriftete Grenzen. … und ein Stück weiter oben das Labyrinth und die Taverne sind auch unbeschriftet. Nur wegen schönen Bäumen und grenzen Lohnt das imho nicht bei all den Nachteilen. Grüße, Dirk ___ 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] Mapnik ohne Richtungspfeile
Am 25.04.2014 09:53, schrieb Andreas Labres: On 23.04.14 21:42, Peter Körner wrote: Das kann man halt auch anders formulieren: An wie viele Objekte wurde kein name eingetragen (sondern note, description, ...), weil's auf der Karte doof ausschaute. Schon, aber name ist definiert als der /darzustellende/ Name. ? Wo ist das so definiert? Ich versuch mal aus dem Wiki zu zitieren: [1]: To provide details of the name for a feature included in OpenStreetMap. - nix mit Darstellung, [1]: Key name: The common default name. (Note: For disputed areas, please use the name as displayed on e.g. street signs for the name tag. - auch da steht nichts von Darstellung für die Karte. Deutsche Seite zum Key Name: [2] Der Schlüssel name dient dazu, den Namen eines Objekts in OpenStreetMap anzugeben - auch da steht nichts zur Beschriftung eines Objekts in der Karte, sondern es geht um den Namen des Objekts. [2] Key name: Die allgemeine Bezeichnung - halte ich für zu schwammig übersetzt und zu leicht falsch zu interpretieren, aber trotzdem steht auch hier nichts von der Darstellung oder dem darzustellenden Namen. Aber da Namen ja wirklich eine komplexere Sache sind, gibt es ja noch die allgemeine Seite zum Thema, auch da wieder Englisch [3], Deutsch [4] und andere: [3] sagt: We use name=* to tag the name of things. We tag names of roads, pubs, railway stations, parks, buildings and anything which has a name. See more at Map Features#Name -nix mit Darstellung. [3] stellt außerdem klar, dass keine Abkürzungen verwendet werden sollen. [3] sagt ganz deutlich: Name is the name only. The names should be restricted to the name of the item in question only and should not include categories, types, descriptions, addresses or notes. If something really doesn't have a name, don't add one to OpenStreetMap., und hier kommen wir zum Kern des Problems: ein Name ist ein Name ist ein Name - keine Beschreibung, keine Bezeichnung, um beschreibend auf etwas zu verweisen, sondern ein Name. Insofern ist's schon ok, dass ein Renderer, der möglichst alle Namen darstellen will (so Platz ist), die dann eben auch darstellt. Und wenn's ein Name sein soll, der definiert, aber nicht dargestellt werden soll, gibt's dafür z.B. loc_name (IMO). Wer sagt denn so 'nen Blödsinn? loc_name ist für den lokal bekannten Namen. Wenn ich eine Karte von meinem Dorf machen möchte, will ich den loc_name darstellen - zusätzlich oder statt des überregional bekannten, und genau dafür ist der da. Entscheidet doch bitte nicht beim Mappen, wie ihr Dinge dargestellt sehen wollt, entscheidet, was ihr da eintragt. Wenn ihr den Namen eintragt, gehört der in name. Wenn es zusätzlich(!) einen lokal verwendeten Namen gibt, gehört der in loc_name; wenn es zusätzlich einen internationalen Namen gibt, dann kommt der in int_name - und so weiter. Deine Aussage: ...wenn's ein Name sein soll, der definiert, aber nicht dargestellt werden soll,... vermischt die Zuständigkeiten: Wenn Du auf die Darstellung Einfluss nehmen willst, beteilige dich am Render-Stil, wenn Du mappen willst, mappe die Tatsachen. Es gibt beim Mappen immer auch Entscheidungen zu treffen, was korrekt ist und was nicht. Die Darstellung in EINER oder einer Handvoll Karten ist jedenfalls keine, die meines Erachtens gültig ist. Vielleicht ein blödes Beispiel, aber POIs, für die der Renderer (konkret osm.org) kein Icon hat, stellt er * wenn er eine Adresse hat mit der Hausnummer * wenn nicht, dann nicht dar. Führt dann dazu, dass in einer Mall oder Einkaufsstraße zig mal die Hausnummer steht... Wäre es nicht sinnvoll, wenn dort wenigstens die Namen stünden? Für Geschäfte ja, aber das führt dann zu einer sinnvollen Regel, Stelle Namen von shop=* grundsätzlich dar, nicht zu Stelle alle Namen dar. Stell dir vor, diese Mall hat aus einer Laune heraus aufgestellte Bänke alle benannt. Diese Namen werden von niemandem benutzt, nicht zur Orientierung verwendet und gar nichts, sie stehen aber auf kleinen Schildern an der Bank (und sind in dem Fall mal nicht die Widmung, die es ja oft gibt, aber die kein Name ist). Wäre es nicht sinnvoll, in der Mall alle Namen von Geschäften, aber eben gerade keinen Namen von Bänken zu sehen? Bei unserer Renderertechnik würden alle Namen zudem meist dazu führen, dass einige zufällig weggelassen würden - aus Platzgründen. Willst Du die Karte dann wirklich ein paar Bänke mit Namen anzeigen lassen, die Läden nebenan aber nicht - nur weil da der Zufall und die genaue Platzierung in Kombination mit evtl. der Objekt-ID (wegen der Reihenfolge, in der Objekte durch den Renderer verarbeitet werden) das so entschieden hat? Sorry, aber meldet doch einfach Features, deren Namen dargestellt werden sollen - aber an der richtigen Stelle, und ohne Gejammer, dass die da oben beim Style-Code immer alles schlechter machen würden. Gruß Peter [1] http://wiki.openstreetmap.org/wiki/Name [2] http://wiki.openstreetmap.org/wiki/DE:Key:name [3] http://wiki.openstreetmap.org/wiki/Names [4]
Re: [Talk-de] Mapnik ohne Richtungspfeile
Am 25.04.2014 11:52, schrieb Martin Koppenhoefer: Am 25/apr/2014 um 10:25 schrieb Peter Wendorff wendo...@uni-paderborn.de: The names should be restricted to the name of the item in question only and should not include categories, types, descriptions, addresses or notes. If something really doesn't have a name, don't add one to OpenStreetMap., wobei das manchmal auch mMn zu restriktiv gesehen wird, z.B. bei Restaurants, da ist der Name oft einschl. einer Kategoriebezeichnung (zBGasthaus zum Ochsen und nicht nur (je nach Fall kommt das zwar auch vor) zum Ochsen). Macht ja auch keinen Sinn, z.B. name=für angewandte Kunst zu taggen, wenn es name=Museum für angewandte Kunst heißen sollte. Beim Gasthaus zum Ochsen kann ich mir beides vorstellen - sowohl, dass das Gasthaus zum Ochsen heißt als auch, dass es Gasthaus zum Ochsen heißt. Ein Museum für angewandte Kunst, das irgendwo den Namen für angewandte Kunst trägt, musst Du mir zeigen (in dem speziellen Fall würd ich es dem Museum als angewandte Kunst durchgehen lassen, beim Museum für Völkerkunde würd ich die Verantwortlichen des Namens für Völkerkunde mal zum Psychiater schicken. Bei Ministerien, Museen oder Universitäten lässt das kaum einer weg, bei Restaurants und Cafés aber öfters. Die Universität Paderborn heißt aber auch Universität Paderborn - und nicht Universität, und die Leipniz Universität Hannover heißt auch nicht Leipzig oder Leipzig Hannover, sondern genau so: Leipniz Universität Hannover. Eine Kneipe kann auch einfach Die Kneipe oder Kneipe heißen - aber nur weil es eine Kneipe ist, heißt sie noch nicht so - und auch nicht, weil die Säufer um die Ecke eben in die Kneipe gehen. Trotzdem ist ein Name ein Name, und nicht eine Bezeichnung, die man zur Kommunikation nutzt. Manchmal ist das nicht eindeutig, manchmal ist es nicht so richtig gut vor Ort zu erkennen - aber gegen Fehler sagt ja auch niemand was. Ich gebe dir recht: manchmal wird das zu restriktiv gesehen, ABER ich schränke das ein: manchmal wird zu viel nachträglich als Fehler behandelt und der entsprechende Mapper dementsprechend angeschrieben. Die Grundsätze, was ein Name ist, sollten wir dagegen eher zu restriktiv als zu offen beschreiben - zusammen mit der zwangsläufigen Interpretation von Mappern kommt dann eher was sinnvolles dabei raus, als wenn man alle Toleranzen direkt offiziell erlaubt (beachtet die Anführungszeichen). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Labeling Features
Hi again, yes, ignore them. JOSM warns about nearly everything - especially anything that might be a common mistake. If you would edit in your home town you would know the labels, and as they are very important information, josm asks you to add them. But if you're not able to, just ignore it. The same holds for other warnings as well, but make sure you know what JOSM talks about as sometimes it's useful to spot errors you made before. regards Peter P.S.: I don't know how, but you managed to send your response to the talk-list address. For others: see Khushdeeps missing mail below. Am 15.04.2014 04:37, schrieb khushi malhotra: Hi Peter, Thanks for your reply. To follow up, when I try to upload the completed task, I get a warning message under the Validation Results tab in JOSM, which says no labels have been provided for the I digitized. Should I just ignore these messages and continue to upload? Thanks, Khushdeep On Mon, Apr 14, 2014 at 3:15 PM, Peter Wendorff wendo...@uni-paderborn.dewrote: Hi Khushdeep, welcome to OSM. There is no information about street names and such in aerial imagery. Tracing from imagery is therefore done when you got the information out of the images. Labels are not part of these tasks. Of course if you were there, mapping as a local, not remotely, you should of course add as much information as possible, especially street names and so on, but as a remote mapper this is usually impossible and for that reason not part of the tasks. Perhaps the HOT guidelines should be adjusted if they don't make that clear. regards Peter Am 14.04.2014 21:00, schrieb khushi malhotra: Hi everyone, I am new to HOT, and I tried to complete one of the mapping tasks for the CAR region. Here is my question: I digitized a few roads and buildings, but I did not understand where to get information to label the digitized features, as I did not see any labels for roads or buildings on the imagery data (which I expected would have them). I did not want to mark the task as completed without first labeling the features correctly. Where can I get this information? I use Bing, OSM and MapQuest Aerial. I've checked OSM documentation, but I am unable to find the answer. Please pardon my ignorance! Thanks for your feedback! Khushdeep ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Labeling Features
Hi Khushdeep, welcome to OSM. There is no information about street names and such in aerial imagery. Tracing from imagery is therefore done when you got the information out of the images. Labels are not part of these tasks. Of course if you were there, mapping as a local, not remotely, you should of course add as much information as possible, especially street names and so on, but as a remote mapper this is usually impossible and for that reason not part of the tasks. Perhaps the HOT guidelines should be adjusted if they don't make that clear. regards Peter Am 14.04.2014 21:00, schrieb khushi malhotra: Hi everyone, I am new to HOT, and I tried to complete one of the mapping tasks for the CAR region. Here is my question: I digitized a few roads and buildings, but I did not understand where to get information to label the digitized features, as I did not see any labels for roads or buildings on the imagery data (which I expected would have them). I did not want to mark the task as completed without first labeling the features correctly. Where can I get this information? I use Bing, OSM and MapQuest Aerial. I've checked OSM documentation, but I am unable to find the answer. Please pardon my ignorance! Thanks for your feedback! Khushdeep ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Announce: Mapnik-de: Schöneres Rendering von Sportplätzen
Hi, im Prinzip eine Möglichkeit - aber funktioniert die unterschiedliche Farbgebung für unbekannte Sportarten vernünftig, was die Erkennbarkeit auf der Karte angeht? Mit eingezeichneten Linien ist ein Fußballplatz bzw. ein Tennisplatz jeweils als solcher erkennbar; aber ohne? Bei unbekannten oder nicht unterstützten Sportarten sind Sportplätze jetzt auch noch farblich unterschieden. Zumindest sollte dann ein Sport-Icon drauf oder sowas in der Art. Gruß Peter P.S.: Irgendwelche Einwände, Rugby/Football-Diamanten auch mit Linien einzuzeichnen? Ja, das wäre nochmal spannender in Sachen Ausrichtung ;) Am 08.04.2014 12:26, schrieb Sven Geggus: Holger Jeromin mailgm...@katur.de wrote: Hat einen Aschefussballplatz, der wird leider nicht rotbraun gerendert :-) Hm, die Regeln sehen so aus und sind unverändert aus dem französischen Stil übernommen: Style name=sports-surface filter-mode=first Rule maxscale_zoom16; Filter([angle_diff] gt; 85) and ([angle_diff] lt; 95) and ([sport] = 'soccer') and ([surface] = 'grass')/Filter PolygonSymbolizer fill=#54a854 / /Rule Rule maxscale_zoom16; Filter([angle_diff] gt; 85) and ([angle_diff] lt; 95) and ([sport] = 'tennis') and ([surface] = 'grass')/Filter PolygonSymbolizer fill=#54a854 / /Rule Rule maxscale_zoom16; Filter([angle_diff] gt; 85) and ([angle_diff] lt; 95) and ([sport] = 'tennis') and ([surface] = 'clay')/Filter PolygonSymbolizer fill=#cc7e66 / /Rule /Style Vielleicht sollte man das einfach in soetwas umändern: Style name=sports-surface filter-mode=first Rule maxscale_zoom16; Filter([angle_diff] gt; 85) and ([angle_diff] lt; 95) and ([surface] = 'grass')/Filter PolygonSymbolizer fill=#54a854 / /Rule Rule maxscale_zoom16; Filter([angle_diff] gt; 85) and ([angle_diff] lt; 95) and ([surface] = 'clay')/Filter PolygonSymbolizer fill=#cc7e66 / /Rule /Style Dann wäre die Sportart egal. Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 03.04.2014 16:38, schrieb chris66: Am 03.04.2014 10:01, schrieb Manuel Reimer: Was mich daran stört: Ich hätte gerne die normale Straßenlinie erhalten. Ist highway=pedestrian auf die Fläche überhaupt korrekt? Darf die Fläche an die zuführenden Straßen angeschlossen sein? Sie muss angeschlosssen werden, sonst funktioniert das Routing nicht mehr. Geroutet wird übrigens ...bei allen momentan bekannten auf OSM-Daten eingesetzten Routern am Rand der Fläche entlang. Ein Routing über Plätze wäre denkbar, Algorithmen existieren dafür (aus anderen Bereichen). Auch ein entsprechendes Preprocessing, das aus Plätzen für den Router Kreuzungen macht, ist durchaus im Rahmen des Möglichen. Kann ich den Wegverlauf einfach als weiteres highway=pedestrian in Form einer Linie oben drüberlegen? Wo gehört dann der name dran? Ist unschön, aber verbessert das Routing. Wir taggen nicht falsch für den Router! (genausowenig wie für's Rendering). Eigentlich müsste man das gerade bei Plätzen konsequent durchziehen, jedenfalls überall da, wo keine eindeutigen Wege über den Platz existieren (Rinnstein links und rechts der Fahrbahn oder ähnliches). Nur so wird irgendwann ein Router-Entwickler anfangen, sich darum zu kümmern. Wichtig: Fläche mit Linie verbinden, sonst gibt es Routing-Inseln. Richtig. Den Namen würde ich an die Linie machen. Die Frage halte ich generell für die schwierigste dabei. Wenn die Marktstraße über den Marktplatz führt, gebe ich dir recht. Wenn die Marktstraße durch den Marktplatz unterbrochen wird, dann nicht (und dann ist eine Linie über den Marktplatz auch nicht auf einmal Marktplatz). Wenn die Marktstraße zum Marktplatz führt und die Rathausstraße auf der anderen Seite weitergeht - welchen Namen würde bei dir dann die Linie bekommen? KORREKT ist die Linie nur, wenn sie als Straße existiert (und zwar unterscheidbar vom Platz; bei Fußgängerzonen oft nicht der Fall). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Flächenmapping so korrekt? Wie korrigieren?
Am 03.04.2014 21:16, schrieb Martin Koppenhoefer: Am 03/apr/2014 um 18:48 schrieb Peter Wendorff wendo...@uni-paderborn.de: Wir taggen nicht falsch für den Router! (genausowenig wie für's Rendering). yep, richtig allerdings schon auch für den Router. Wieso hältst Du das für falsch? Gegen eine existierende (!) lineare Spur über den Platz habe ich nichts, das würd ich auch eintragen - also wenn die z.B. markiert ist, durch Bordsteine, Rinnsteine, Straßenmarkierung etc. Falsch halte ich es, wenn es sich um offene Plätze handelt, bei denen Autos eben einfach nur die gerade Linie zwischen Ein- und Ausgang nutzen, ohne dass dies vorgeschrieben oder markiert wäre - gerade beim Marktplatz in der Fußgängerzone durchaus denkbar und üblich. Wie tagst Du dann ohne linearen way eine Einbahnstraße in der Fußgängerzone? Wenn es eine Einbahnstraße ist, dann gibt es üblicherweise auch einen definierten Fahrweg und der kann als solcher ja auch wie üblich eingetragen werden. Ist aber die Durchfahrt verboten oder nur für Lieferverkehr erlaubt, gibt es einen solchen Fahrweg z.T. eben nicht, sondern der Platz ist bzgl. der Nutzung durch Fahrzeuge auf der ganzen Fläche gleichwertig, dann ist eben auch ein Weg drüber in OSM fehl am Platz, der in dem Fall nämlich nur den Router zufriedenstellt, der die direkte Verbindung zwischen Ein- und Ausfahrtspunkt dann nicht berechnen muss, sondern vorgekaut kriegt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Foursquare and OSM Note Instructions
Hi, IMHO missing stuff is some kind of error and it might be correct to store that information in a note. But it's more complex than just add a note and we'll do the rest. Adding a note even as a personal note for adding it later is a valid action, if e.g. don't have the time to do more now or don't have an editor at hand - provided I'm going to resolve that myself later. Adding a note that something is missing in some place is valid, if I know that there's something missing, but don't exactly know where it is (only very rough location, only know that there's one shop missing, but don't know any details yet,...). Here the note is a temporal thing to be replaced after an on-the-ground visit. Adding a note where adding the feature itself is too complex for my own experience (e.g. holes in buildings missing (multipolygons), route relations with missing detours...) is valid. What's not wanted - but better than nothing - are examples like the ones you refer to in your later mail: here is address x, here's my business: foo-store, ..., these should be as simple to be added directly as to add the note, and therefore yes, it would be better the people would add them directly to the osm database instead. On the other hand it depends... OSM has lot's of contributors joining osm, adding their own business as a single-node item, and never doing more. If we motivate these people to add more stuff around, e.g. to improve routing to their business, to get a better looking map around their business or something like that it's great, but if we have more mappers that don't come back at all, why should that be preferred over adding a note, that there's a business missing? I prefer a note over a florist mapped as supermarket, as it's easier to solve the note (if all necessary information is included) than to find errors in wrong data like that. tl;dr: it's not as easy as to say register and add yourself, it's more complex, but missing stuff is an error in OSM, something that has to be fixed and in general *might be* valid use cases for an osm note. regards Peter Am 28.03.2014 03:50, schrieb Jason Ward: Hi Team, I've been doing some SuperUser edits in 4sq recently and poked my head into the OSM page they hold on their site (https://foursquare.com/about/osm) and its slightly at odds with the messaging I have been using when resolving notes I have deemed as irrelevant to use and I thought I'd clarify with this group to see whether I need to: a) Adjust my messaging when resolving notes [1]; OR b) Don't resolve notes that indicate something should be added or is an ommission; OR c) Ask 4sq to amend their copy to better reflect OSM Note usage. So. The OSM Wiki [2] for notes indicates in its first para that notes are for errors and I have taken that quite literally when assessing notes and in resolving something that is missing from OSM I have indicated that notes are for errors. My behaviour may be having a negative effect on these note authors coming from 4sq so I'm keen to ensure I don't unecessarily turn people away from OSM if I shouldn't be. Any thoughts here? Is the first para in the OSM Wiki at odds with the Dos and Don't section on the same page? One suggests errors and the other suggest errors and missing information. [1]: I usually resolve Notes with Business Details suggesting that they are for Errors rather than Ommissions. [2]: http://wiki.openstreetmap.org/wiki/Notes Cheers, Jason ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Foursquare and OSM Note Instructions
Well, it's not errors only, but notes of course. My argument goes into: it might be useful to add a note *about* an error, too. It's best to fix errors immediately, of course; but it's better to document them for later to fix than to do nothing and forget about it. Therefore notes are like an issue tracker, containing tasks to be done (like resurvey at arrival of new imagery), bugs to fix (like shop has been closed; intersection is a roundabout now,...) and enhancements (here the business X is missing). Anything fits into notes as it would fit into an issue tracker; but like in an issue tracker it's best t solve issues directly, which might even make opening the issue in the tracker (opening the note in osm) obsolete at all. The Foursquare (and similar) case for trivial notes like business missing here is address X is like a typo in a UI translation file of a software: it is more easy to fix it than to file an issue - at least, when you have an account already and know how to use the tools. Our own todo list is perfect to add to the notes - but it requires to write notes in a way that others can understand, because it's a PUBLIC issue tracker. The same way I can add my personal tasks in a software project to the global issue tracker I can do it with notes, too - it must be clear what is to be done, and it should not be more work with an issue tracker than it would be without. regards Peter Am 28.03.2014 10:03, schrieb Jóhannes Birgir Jensson: Perhaps it is because English is not my native language but I understand a Note to be a comment, whether about missing data or wrong data or in fact, as I've sometimes done, a note about imagery missing for a future imagery refresh. I mapped my hometown last summer and one part of it was missing good imagery, so I added a note there (a cluster of 3 newly built streets) which was something like imagery missing - resurvey when updated which I then resolved a few weeks back when I noticed the imagery had been updated for that part. Thus these notes form a sort of to-do list where the doing can't be done at this point in time. It is quite curious to name them Notes when they are then understood to be Errors. Or are they Notes? --Jói Þann 28.03.2014 08:32, JB reit: Err, some thoughts after some heavy note-closing in France. Le 28/03/2014 09:14, Peter Wendorff a écrit : Adding a note even as a personal note for adding it later is a valid action, if e.g. don't have the time to do more now or don't have an editor at hand - provided I'm going to resolve that myself later. Dos and don'ts section does not validate this in the wiki : « Don't use it to put your personal notes here. ». Rather use personal stuff like gpx files or whatever. Many personal notes just get forgotten (where is this filtering tool showing _my_ notes? Ha, doesn't exist, I forgot…) Adding a note that something is missing in some place is valid, if I know that there's something missing, but don't exactly know where it is (only very rough location, only know that there's one shop missing, but don't know any details yet,...). Here the note is a temporal thing to be replaced after an on-the-ground visit. Sure, but I've never seen an answer to a note asking for re-surveying, excepted for the creator when asked for details. In my opinion, just congesting the database. Don't want to go too fast, as I presenting some work done on notes in France at SotM-FR next week-end, but forecast some additional info on my diary page afterwards. JB. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] OSM-Blog ist manchmal schwierig zur verfolgen ;-)
Vielleicht sollte man den Twitter-Bot an der Stelle abschwächen und moderieren, so dass neue User erst eine Twitterfreigabe kriegen nach Prüfung durch bereits geprüfte andere Mapper oder so. Gruß Peter Am 27.03.2014 09:04, schrieb Christoph: Ja das spam Problem auf dem Blog ist in diesem schon mehrfach angesprochen worden. Die Admin versuchen Spam accounts maximal schnell rauszuwerfen, allerdings kanndas - wie das Beispiel zeigt - schwierig sein. Blöd ist das die Tweets dann trotzdem in Twitter stehen bleiben. Sent from my iDingens Am 27.03.2014 um 07:37 schrieb Elstermann, Mike mike.elsterm...@itc-halle.de: Siehe hier: http://geoobserver.wordpress.com/2014/03/27/osm-blog/ Schönes WE und Happy Mapping ;-) ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Blog ist manchmal schwierig zur verfolgen ;-)
Hi, ich denke, es sind zwei Dinge, die man angehen könnte: 1) Spam in den blogs, 2) Spam aus den Blogs auf Twitter. Während Spam in den Blogs zwar blöd ist und nervt, beschränkt sich der weitgehend (ich weiß; RSS-Feeds gibt's auch, trotzdem) auf ein Pull-Medium: Den sehe ich dann, wen ich da nachgucke. Auf Twitter dagegen würde es für mich eher dazu führen, eben diesem Twitter-Account nicht mehr zu folgen. Insofern kann man das im Grunde als zweistufige Veröffentlichung betrachten: a) user X schreibt etwas in seinen user-blog b) der blog-artikel wird durch den bot getwittert. Natürlich wäre es gut, schon bei (a) hinreichend zu filtern. Da der Blog aber immerhin unter der Kontrolle von OSM steht, ist das auch nachträglich noch möglich, während man aus Twitter nichts mehr rauskriegt ohne weiteres. Deshalb wäre mein Vorschlag (und IFTTT spricht da erstmal nicht dagegen und könnte weiter eingesetzt werden mit einer zusätzlichen Bedingung) der folgende: a') user X schreibt etwas in seinen user-blog a2) andere osm-user können den blog-post als spam oder nicht-spam markieren (nicht bewerten, nur als spam markieren). b') der bot twittert, und zwar: wenn der user keine spam-bewertung hat und mindestens eine positive Bewertung hat, dann ja. Wenn der Blogpost positiv bewertet wurde (und noch nicht als Spam), dann ja. Sonst nein. Auslösendes Event dabei ist einerseits das schreiben eines blogposts und zweitens die Einordnung eines Posts als Spam oder nicht. Ich weiß, dass dafür eine entsprechende Bewertungsfunktion in die blogs eingebaut werden müsste; aber die Logik fürs Twittern zumindest wäre unproblematisch, und die Bewertung würde über die Meldungen von Spam-Accounts im Wiki hinaus eine komfortablere Möglichkeit für die Moderation durch authorisierte User/Admins erlauben. Die von dir genannten Heuristiken kann man auch nutzen, klar; aber Heuristiken haben immer die Tendenz, schiefzugehen; sei es ein Offline-Tool, das dann meine gesammelten blogposts aus dem Urlaub hintereinanderweg in meinem userblog veröffentlicht, seien es ähnliche Inhalte, die durch ein heiß diskutiertes Zitat mit kurzen Kommentaren dazu immer wieder auftauchen oder ähnliches. Spamfilterung muss automatisch gehen, aber so ganz automatisch geht es eben meist noch nicht, und gerade fürs Twittern würde ich persönlich weniger Tweets mit einem viel geringeren Spam-Anteil bevorzugen. Gruß Peter Am 27.03.2014 10:38, schrieb Andreas Labres: On 27.03.14 09:42, Peter Wendorff wrote: Vielleicht sollte man den Twitter-Bot an der Stelle abschwächen und moderieren, so dass neue User erst eine Twitterfreigabe kriegen nach Prüfung durch bereits geprüfte andere Mapper oder so. Naja, ich glaub nicht, dass das realistisch umsetzbar ist. Das wird über IFTTT automatisch rausgehaut und fertig. Wenn, dann müßte man beim Erstellen der Blogs ansetzen und dort so eine Art Auto-Moderation machen, also zu prüfen - werden von einem User zu viele Blogs in kurzer Zeit erzeugt - sperren - werden im Zeitraum von verschiedenen Usern öfter Blogs mit ähnlichem Inhalt erzeugt - sperren - werden Inhalte von schon gesperrten Usern von anderen wieder erzeugt - sperren Aber wie immer, Spamfilterung muss automatisch gehen. /al ___ 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] Aktuelle Anleitung OSM mit Mapnik rendern?
Hallo Manuel, passt vermutlich nicht ganz ideal, weil es eher auf Tileserver abzielt, aber die Software ist ja weitgehend dieselbe, insofern hilft dir [1] vielleicht weiter. Gruß Peter [1] http://switch2osm.org/ Am 24.03.2014 06:57, schrieb Manuel Reimer: Hallo, gestern hat mir das beständige Weigern des OSM-Tileserver, mir den gewünschten Ausschnitt als SVG zu erzeugen, einige Stunden Zeit gekostet. Ganz davon abgesehen, dass ich letztlich eine Zoomstufe nehmen musste, die eigentlich nicht optimal ist. Das Teilen-Interface in der Webseite scheint kaputt zu sein. Beim rauszoomen wird der Maßstab korrigiert, beim Reinzoomen aber nicht. Selbst der korrigierte Wert rendert kein SVG, dass der Darstellung in der Webseite entsprechen würde. Um bei Bedarf einen Ausschnitt nach SVG zu rendern, möchte ich deshalb einmal versuchen einen eigenen kleinen Render-Server aufzusetzen. Ich hatte sowas schonmal am Laufen, aber das ist lange her und hat damals auch nicht wirklich zufriedenstellend funktioniert. Wo finde ich eine aktuelle Anleitung dafür? Laufen muss das ganze letztlich auf einem Linux-System. Danke im Voraus Gruß Manuel ___ 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: [OSM-talk] Newbie alert
Am 19.03.2014 18:03, schrieb Bryce Nesbitt: On Thu, Mar 13, 2014 at 2:53 AM, SomeoneElse li...@mail.atownsend.org.ukwrote: Bryce Nesbitt wrote: The entry level editor could reasonably limit new users to entry level edits. Messing with anything with a relation is not a first edit kind of activity. What if the entry level editor said hey, this is too complex, map something else and gain some experience and come back to this section. The barrier is still low. Saying you can't update anything that involves a relation rules out rivers and streams (borders), roads (turn restrictions), and many types of landuse and buildings (multipolygons). I don't think that it's feasible. You've taken the proposal farther than I intended. Certainly adjusting the geometry of a boundary should be just fine for everyone. --- Let's take Stack Exchange, a Question Answer site, as a possible model. A new user can vote up *any* answer. However, it requires a reputation level of something like 100 to vote *down* a question. This reflects that voting down has some social cost, and it takes some time for new users to become familiar with the community norms. --- For OpenStreetMap the moment a new user *deletes* a member of a border relation something might pop up: *Feature locked: this type of edit requires more editing experience. Please see here for details.* Some remarks here: 1) it's not possible to pop up anything as the editor not necessarily knows anything about the user at the time of the edit, this is known only when uploading - and then it's too late. In contrast it's perfect for a new user to change a local copy of osm, as long as it's not uploaded. Not only have you prevented a messy deletion, you've given the new user something to strive for (unlocking the capability). You have made some of the new users to leave as they don't want to edit any relation, they wanted to fix the street - and they never cared about the turn restriction, which shouldn't have been changed by their edit. They wanted to fix the street, but didn't know or didn't want to do anything with the bus route. I dispute that this is any sort of barrier to a new editor. A new editor (particularly a non-geek editor) may well feel comforted that they are in an environment where the sharpest knives are locked away, at least until they are ready to use them. And you're teaching at a teachable moment. If it were that easy I would agree. Unfortunately we don't have knives and spoons in our toolbox, we have only a spoon, but the data we are working on, the food we eat when editing the data, contains salad (ways and nodes independent of relations) as well as chilli (the relations with their content) and unfortunately cherries as well - where you don't know if the stone is left inside or not. Newbies don't expect the stone to be hidden in the cherry, the don't expect to break anything by only changing a way; and it's hard to explain why some streets are allowed to be edited and others are not. Why some buildings are allowed to add and others are not (as they are part of an associated-street relation for example). --- Another possible model is OK Cupid, where users must pass a short quiz to access features. For OpenStreetMap that could mean a quick educational quiz on relations. A user trying to make an edit that requires relation experience would be directed to the quiz. The moment they answer the questions correctly their account is permanently unlocked with regard to relation editing. In this approach one quiz would handle all editing platforms, and the rejection of an edit would happen at the API level. The editors would only need to format the API error message for viewing (perhaps with a i18n layer for translations). Knowing about relations does not necessarily mean to know how to detect them in any editor or how to prevent breaks inside - and the other way around. regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Mein Forum-Account gesperrt?
Hi Fred, ich befürchte, das ist ein anderes, größeres Problem und hat absolut nichts mit dir zu tun. Ich bin im Forum nicht eingelogged und bekomme dieselbe Meldung, die angegebene mailadresse sieht auch nicht korrekt aus (@na1400.info). Sieht also eher nach einem fetten Problem mit der Forendomain oder dem Server aus als nach einem bösen Admin, der dich gesperrt hat. Insofern komm wieder runter, niemand von OSM will dir was böses und ich vermute, auch niemand hat dich gesperrt. Gruß Peter Am 18.03.2014 09:46, schrieb Fred Jelk: Was zum Teufel? Wieso wurde mein Account im Forum gesperrt? Ich habe noch nie gespammt oder sowas... http://i.imgur.com/Tw39dum.png Langsam aber sicher nervt mich das Ganze hier: Gegen Spammer wird nicht vorgegangen (oder zum Teil bleibt Spam x Tage lang vorhanden - vorallem in den Blogs). Aber andererseits werde ich gesperrt... wegen was eigentlich? Ich habe höchstens mal (etwa vor 1 Jahr oder sogar länger) das eine oder andere Programm/Projekt oder GPS-Empfänger oder Artikel über OSM in den News mal gepostet. Aber sicher nicht gespammt... Naja, zum Glück gibt es andere OpenSource-Projekte (hat dann zwar nichts mit OSM zu tun, aber mir kann es egal sein). Wenn die Sperre bis heute Nachmittag noch aktiv ist, bin ich weg von OSM. So kann man auch Leute vergraulen. Ich habe in OSM mehrere 1000 Edits. Das meiste in meiner Gegend ist von mir. Aber soll sich halt jemand anders um diese Gegend kümmern. Danke an denjenigen Deppen, der mich gesperrt hat! ___ 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] Mein Forum-Account gesperrt? Geht anscheinend wieder
Hi, einzeln freischalten sollte nicht notwendig sein; es handelt sich wohl um ein Problem mit IP-basierten Sperren in Kombination mit einem NAT-Proxy. Bei einigen hilft wohl Shift+F5 bzw. das Leeren des Browsercaches. Gruß Peter Am 18.03.2014 13:16, schrieb Fred Jelk: Bei mir geht's wieder. Und auch bei vielen anderen - es sind jedenfalls viele online. Möglicherweise müssen sie alle User einzeln freischalten (was mich zwar wundern würde), und es wurden zuerst jene freigeschaltet, die sich per Mail beschwerten. Rest erfolgt nach und nach (reine Spekulation meinerseits). Am 18.03.2014 13:07, schrieb chris66: Am 18.03.2014 12:29, schrieb Fred Jelk: Forum ist wieder online. Nack. Unfortunately everyone receives a 'you are banned' message. This is an error! We are working hard on a solution. Sorry for any inconvenience. Entzugsgrüße, Chris ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 3D: Wie Gebäude am Hang taggen?
Hi, Obwohl die Daten ungenau sind, wäre aber doch eine erste Näherung zumindest die, bei Anwendung von Höhendaten das 3D-Modell da auf Bodenhöhe (entsprechend dem Geländemodell zu platzieren, wo der Eingang sitzt. Angenommen, jemand würde ein gebäude mit kellern eintragen, würde das dadurch passen. Angenommen, das Gebäude stünde an einem sehr gleichmäßigen Hang, der dadurch tatsächlich durch die vorhandenen Daten abbildbar wäre, würde es auch noch passen. Tut das soweit schon irgendein 3D-Renderer? Gruß Peter Am 17.03.2014 16:19, schrieb Martin Koppenhoefer: Am 17. März 2014 13:44 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Gibt es denn wenigstens einen Renderer, der bereits irgendwelche Geländedaten mit einbezieht? bei den bisher frei verfügbaren Quellen wie SRTM und Aster gibt es jedenfalls sicher keine Hoffnung, dass damit solche Details wie ein halb eingegrabenes Gebäude wiedergegeben werden könnten (Zu geringe Auflösung). Es gibt aber durchaus Renderer, die diese Quellen miteinbeziehen, aber das hilft eher bei der Orientierung im großmaßstäblicheren Einsatz, nicht bei der Ansicht des einzelnen Gebäudes. Gruß Martin ___ 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] Notes-RSS-Feed
Hallo Andreas, Die verlinkte API-Seite enthält sowieso sofort eine permanente Weiterleitung zur Webseite per 304. Insofern geht der Link letztlich nicht mehr in die API, obwohl du natürlich recht hast, dass das auch in den Feeds behoben werden sollte, um zusätzliche Seitenaufrufe zu ersparen. Was das Erwirken einer Änderung angeht: Den Code der Webseite inklusive API findest Du unter [1], da gibt's dann auch einen Issue-Tracker [2]. Idealerweise findest und behebst du den Fehler* natürlich direkt ;) alternativ kannst du auch per Ticket darauf aufmerksam machen. Gruß Peter * ein Fehler ist es ja eben nicht, denn es entspricht mit der Weiterleitung vollständig dem HTTP-Protokoll. [1] https://github.com/openstreetmap/openstreetmap-website/ [1] https://github.com/openstreetmap/openstreetmap-website/issues Am 15.03.2014 18:20, schrieb Andreas Neumann: Moin, wo muss ich mich melden, um im Notes-RSS-Feed[0] der API eine Änderung zu erwirken? Mich nervt etwas, dass die Links zu den Notes in die API geht und nicht zur Website. Oder gibt es einen RSS-Feed für Notes in einem Gebiet, der dieses Feature bietet? MfG Andreas [0] z.B. http://api.openstreetmap.org/api/0.6/notes.rss?bbox=10.824,50.636,10.968,50.75 ___ 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: [OSM-talk] OpenStreetMap Isn't All That Open, Let's Change That and Drop Share-Alike
Hi Jukka, although I'm curious about an answer from someone who's more competent in the legal things, I'm not sure with your argument here. ODBL does not require Share-Alike for produced works. The map, even when based on OSM data is a produced work. Therefore even if the map is based on osm data, it's not share-alike, and any data based on the map IMHO cannot be share-alike too. Let's assume the opposite: - The map is a produced work and may be published on any license (more restrictive as well as more open than ODBL), so let's assume the map is CC-BY (without Share-Alike), - Then from CC-BY it follows that anyone could derive other stuff from that map without being obliged to follow any share-alike clause. So if anyone would require data gathered on top of an osm map to be share-alike, he's wrong (or ODBL contradicts itself in this example in some way). As I assume the ODBL to be checked many times, I assume yet that therefore your implication chain to be wrong and new data collected on top of an osm based produced work is not tainted with share-alike from ODBL. Nevertheless I am not a lawyer, so someone else may proove me wrong If I am. You mention Google Maps as a possible alternative to prevent this problem. I disagree here, too. If you're talking about a substantial amount of data derived from (or above) an OSM based map, the same would be forbidden with google maps data, too. As the terms of service of google state (German version): Sofern Sie zuvor keine schriftliche Genehmigung von Google bzw. dem Anbieter der betreffenden Inhalte erhalten haben, dürfen Sie (a) den Inhalt weder ganz noch teilweise kopieren, übersetzen, abändern oder abgeleitete Werke daraus erstellen translated by me: without written permission of Google or the affected data providers your are not allowed to copy (in parts or as a whole), translate or modify the content or produce derived works from it. Therefore the same as for OSM holds for any content of Google Maps, and you probably should think about using Google as an alternative from a legal point of view. regards Peter Am 14.03.2014 14:17, schrieb Jukka Rahkonen: Simon Poole wrote: One thing I would like to hear about in this context of this discussion, are examples of concrete use cases that are not happening because of share alike and that are in general things that the community would like to support (so not evil corp can't take the data now and keep it). Concrete in the sense that they are uses that really would happen if share alike would be dropped, not we can build a straw man that shows how bad share alike is. Hi Simon, We have considered that we cannot use OpenStreetMap as a background map in any of the applications where users are sending location aware information back to administration. For showing existing data it would be OK but not for gathering data from users because user could locate a place corner of Annankatu and Merimiehenkatu http://osm.org/go/0xPLoLTa0?m= by looking at the OSM map. The interpretation of ODbL is that this location is derived from OSM data and thus the database of the administration would become ODbL. It could be OK in some use cases but some data are confidential and ODbL is not an option. Therefore we do not use OSM at all. We use our own services and Google Maps. This is a concrete example. However, changing the interpretation of ODbL into georeferencing locations by looking at OSM map does not yield a derivative database would not necessarily change the situation in Finland any more because since 2012 most raster and vector data from the National Land Survey of Finland have been open data under attribution-only license. Because of this using the data is simple. This has also helped OSM because raster maps and aerial images can be utilized for digitizing and vector data imports have started this year. Jukka Rahkonen- ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Hochsitze / Bitte um Entfernung von Daten
Hi, momentan aktiv ist er ja offensichtlich rund um Hannover, da gibt's doch, soweit ich weiß, einen recht aktiven Stammtisch [1], der sich laut Wiki morgen trifft. Eventuell bietet es sich an, da einen Kontakt herzustellen, die Leute vom Stammtisch vorzuwarnen und ihn dahin einzuladen. Was die Sache angeht: - Dürfen nicht gemapped werden ist schonmal fraglich bis unmöglich; aber worauf bezieht er sich da? - Straftaten: was für Straftaten? Wie motiviert? Inwiefern durchs Mapping erst möglich gemacht oder erleichtert? Die Argumentation der Straftaten ist die des Internet-in-Suchmaschinen-Filterns: Wenn Google keine Kinderpornos anzeigt oder Provider die bekannten Domains sperren, gibt es bestimmt auch keine mehr... Andererseits klingt das ja nach jemandem, der entweder offizielle Funktion hat oder aber als Jäger, Förster etc. darin involviert ist. Entsprechender Kontakt kann ja eigentlich nicht schaden. Gruß Peter [1] http://wiki.openstreetmap.org/wiki/Stammtisch_Hannover Am 13.03.2014 12:06, schrieb Frederik Ramm: Hallo, die DWG war vor einiger Zeit mal in einen Edit-War involviert, in dem ein Nutzer Waldwege und ähnliches gelöscht hat, was er für schädlich hielt (nach dem Motto: da ist gar kein richtiger Weg, nur ein Trampelpfad, und das Wild wird durch die Wanderer verjagt usw.usw.). Die DWG hat den Nutzer damals gebeten, das eigenmäctige Löschen von solchen Daten zu unterlassen und einige Löschungen revertiert. Nun erhalte ich (als der User, der den Revert gemacht hat) eine Nachricht von dem, der damals die Löschungen vorgenommen hat: == Sehr geehrter Nutzer, Sie haben bei OSM jagdliche Hochsitze im Bereich des Velber Holzes (südlich Harenberg) kartiert. Ich möchte Sie hiermit bitten, diese Punkte wieder zu entfernen, da es dadurch zu erheblichen Problemen kommt. Es gab bereits erfolgte Straftaten, die durch eine anonyme Organisation dort verübt wurde. Somit danke ich Ihnen für das kurzfristige entfernen. Bei Rückfragen danke ich Ihnen für eine Kontaktaufnahme. MfG, Fidibus21 == Ich weiss nicht ganz, wie ich darauf reagieren soll. Einerseits nervt es mich, dass er nicht locker lässt. Diese Hochsitze sind nunmal da, also können sie auch gemappt werden. Andererseits ist es ja eigentlich gerade erwünscht, wenn man mit Daten unzufrieden ist, dass man dann mit den anderen Mappern darüber spricht, statt alles gleich zu löschen. Ich finde das aber mit den Straftaten ein bisschen komisch, das klingt, als wollte man den Mapper unter Druck setzen und ihn zum Mittäter machen, wenn er nicht freiwillig seine Hochsitze löscht... Bye Frederik ___ 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] Bodendenkmal wie geht das? (nachtrag)
Am 11.03.2014 15:15, schrieb Caronna: Am 07.03.2014 20:52, schrieb Peter Wendorff: Hallo Steffen, ich weiß kein Tag dafür; eventuell muss man auch ein neues dafür erfinden; aber eine Burg ist ein Gebäude (und ohne Gebäude keine Burg), eine Ruine hat zumindest Reste davon (also meist zumindest Mauern oder Mauerreste). ich war mal vor Ort! Es ist noch einiges zu erkennen, viel mehr als in der Zeitung stand. Reste von der Wallanlage sind deutlich zu erkennen. Ich hab mal eine Foto bei Wikipedia reingestellt Link? Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reihenhäuser / 3D-Tagging // Re: 1000 Hausnummern
Hallo Ralf, Selbst tagging NUR für den Renderer wäre im Grunde doch okay. Problematisch wird es, wenn NUR für den Renderer, aber GEGEN korrekte Daten oder GEGEN andere Anwendungen getagged wird. Das, wo taggen für (und natürlich insbesondere NUR für) den Renderer, kritisiert wird, betrifft vor allem falsche Tags, um richtige Darstellungen zu erzielen, also: - Wer das Sandloch auf dem Golfplatz als Strand einträgt, macht was falsch - das ist kein Strand, sondern ein Sandloch-auf-dem-Golfplatz. - Wer eine Straße mit access=no kennzeichnet, um zu verhindern, dass Routing-Programme Autos vor der eigenen Haustür vorbeiführen, macht was falsch. - Wer eine Firma, die Einkaufswagen herstellt, als Supermarkt einträgt, damit ein entsprechendes Icon auf der Karte auftaucht, der macht was falsch, denn das ist kein Supermarkt, sondern ein Einkaufswagen-Hersteller. Wer aber Daten zum dreidimensionalen Aussehen von Häusern einträgt, der trägt zunächst mal Fakten ein, die für sich genommen sinnvoll sind. Theoretisch könnte man sich sogar vorstellen, danach zu routen: Folgen Sie der Straße bis zum einzigen Haus mit Walmdach auf der linken Seite, und gehen Sie dann rechts querfeldein... Gruß Peter Am 09.03.2014 00:18, schrieb Ralf GESELLENSETTER: Am 08.03.2014 21:10, schrieb Martin Koppenhoefer: +1, reihenhäuser würde ich als aneinanderhängende Einzelhäuser mappen In diesem Schema gibt es sogar side_hipped (Typ 2.2): http://wiki.openstreetmap.org/wiki/DE:OSM-4D/Roof_table Vielleicht könnte es Sinn machen, für jede Siedlung eine Default-Definition für das Aussehen der Häuser festzulegen. Oder man greift wie oben angegeben auf einen Code zurück, mit dem die gängigsten Hausarten schnell beschrieben werden können. Und schließlich: 3D-Tagging ist Tagging NUR für den Renderer, oder? Gruß Ralf ___ 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] Bodendenkmal wie geht das?
Wobei das Bodendenkmal natürlich KEINE Burg ist, denn sie existiert ja nicht mehr, wenn ich die Mail richtig verstanden habe. Insofern bitte nicht als Burg eintragen, und IMHO auch nicht als Ruine. Gruß Peter Am 07.03.2014 13:53, schrieb Archer: In OpenStreetMap sind so viele Daten enthalten, dass es unmöglich ist, alles auf einer Karte darzustellen. Die Macher der Standardkarte von openstreetmap.org haben sich wohl dagegen entschieden, Burgen darzustellen. Verbesserungsvorschläge für den Kartenstil auf openstreetmap.org kann man hier einbringen: https://github.com/gravitystorm/openstreetmap-carto/issues Die Karte von openstreetmap.de stellt alte Burgen als Symbol dar, wenn sie richtig getaggt wurden: http://openstreetmap.de/karte.html Außerdem gibt es noch die Geschichtskarte, die ebenfalls auf OpenStreetMap-Daten basiert, hier werden historische Objekte besonders hervorgehoben: http://geschichtskarten.openstreetmap.de/historische_objekte/ Bitte beachte, dass Burgen mit historic=castle + castle_type=defensive + (falls Ruine): ruins=yes getaggt werden, siehe hier: http://wiki.openstreetmap.org/wiki/Historical_Objects/Map_Properties Außerdem sollten im Namen eines Objektes auch wirklich nur der Name und keinerlei darüber hinausgehende Informationen wie Wüstung, Bodendenkmal o.ä. stehen. Das sollte man über weiterführende Tags abbilden, siehe auch: http://wiki.openstreetmap.org/wiki/DE:Names#name_ist_nur_der_Name Für geschützte Gebiete gibt es folgendes Taggingschema: http://wiki.openstreetmap.org/wiki/DE:Tag:boundary%3Dprotected_area Gruß Archer Am 7. März 2014 12:26 schrieb Caronna eifelhu...@gmx.de: Hallo, ich brauchte noch mal Hilfe. Simmerath hat ein Bodendenkmal unter Schutz gestellt: http://www.openstreetmap.org/#map=19/50.58976/6.31062 in Josm hab ich das eingetragen, auch in Potlach ist da nun zu erkennen, nur in OSM nicht. Ich habe es mal als Kreis dargestellt, weil ich dachte ein Punkt kommt nicht so einfach durch. Problem ist auch das das Bodendenkmal, eine alte Burganlage, so gut wie nicht zu erkennen ist (soll vor 20 Jahren noch anders gewesen sein, Gräbern sollen noch deutlich zu erkennen gewesen sein, evtl auch Mauerreste) Eigentlich hätte ich den Ort gerne durch eine Schraffierung gekennzeichnet, finde aber nicht dazu. Grüße aus der Eifel Steffen ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bodendenkmal wie geht das?
Hallo Steffen, ich weiß kein Tag dafür; eventuell muss man auch ein neues dafür erfinden; aber eine Burg ist ein Gebäude (und ohne Gebäude keine Burg), eine Ruine hat zumindest Reste davon (also meist zumindest Mauern oder Mauerreste). Vielleicht hat jemand eine Tag-Idee für dich, sonst such dir ein Neues. Und ja: dargestellt wird das dann immer noch nicht vermutlich; aber nicht alles kann und sollte auf der osm-mapnik-Karte auftauchen; dann wär die zu voll. Gibt es dazu vielleicht 'ne Hinweistafel oder so? dann könnte man darüber vielleicht zu einer Lösung kommen. Gruß Peter Am 07.03.2014 17:10, schrieb Caronna: Am 07.03.2014 14:20, schrieb Peter Wendorff: Wobei das Bodendenkmal natürlich KEINE Burg ist, denn sie existiert ja nicht mehr, wenn ich die Mail richtig verstanden habe. Insofern bitte nicht als Burg eintragen, und IMHO auch nicht als Ruine. schwer zu sagen! das geübte Auge soll das noch erkennen können! War wohl eine Motte, also eine Ringanlage mit Befestigung aus Holz. Ist nicht ganz unbedeutend. Wie würdest dus denn eintragen? Grüße aus der Eifel Steffen ___ 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: [OSM-talk] No Changeset Comments from iD
IMHO commit comments are very useful if done right. Some comments are as useless as no comment (e.g. changes, more changes and so on), but asking/reminding/triggering users to give a comment at least increases the ratio of given comments; and hopefully that could increas the ratio of useful comments, too. regards Peter Am 06.03.2014 07:53, schrieb Clifford Snow: Why do I see so many new mappers make edits without a commit comment? Is it because iD doesn't prompt for a commit message? iD issue 1488 is open but not acted upon. I wonder why. Is it because the developers don't think commit comments are needed? I'm wondering what the community thinks. Are commit comments needed? Clifford ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Wald aufteilen um Namen anzuzeigen?
Das liegt daran, dass zu viele zu lange Multipolygone falsch getagged haben und die Render das als Fallback entsprechend angewandt haben. Faktisch dennoch ein Bug und als solchen würd ich ihn auch behandeln. Das Problem dürfte allerdings eher in osm2pgsql als an Mapnik oder dem Kartenstil liegen - oder aber an dessen Konfiguration im osm-default-style-Setup. Am besten also: Bug-report beim osm-default-style und bei osm2pgsql; entweder wird das im style auf osm2pgsql geschoben, oder bei osm2pgsql gibt es eine Konfigruation, um das umzustellen, und darüber wird das Problem gelöst. Letzte und schlechteste Variante: Die Admins entscheiden sich bewusst, den Fehler in Kauf zu nehmen und wollen das fallback für viele andere Fälle beibehalten, in denen tatsächlich fälschlicherweise an inner/outer die Tags der Relation drangepappt oder wiederholt worden sind. Gruß Peter Am 04.03.2014 13:49, schrieb Martin Koppenhoefer: Am 4. März 2014 13:41 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Stimmt im Prinzip. Bevor ich aber irgendwelche Flächen ohne landuse rumstehen lassen würde, würde ich hier die kleine Redundanz in Kauf nehmen und ergänzend zum Multipolygon allen Untereinheiten noch ein landuse=forest geben. Im Prinzip ja, leider sind die Multipolygon-Relationen vollkommen unberechenbar und interpretieren teilweise aus eigener Kraft, dass ein tag nicht sein soll wo es ist (z.B. wenn man ein Loch hat, welches die tags des Multipolygons hat, dann wird das als Loch gerendert und die tags des Objekts werden offenbar weggeworfen, Beispiel: http://www.openstreetmap.org/way/263521637 auch ein Hinzufügen von building:part=yes hat leider nichts geändert, es bleibt ein Loch im Rendering). Gruß Martin ___ 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] Eintrag von Gewann-Namen
Am 28.02.2014 00:08, schrieb Bernhard Weiskopf: Hätte ich gerne geschrieben, ich habe aber keine (im Wiki definierten) Regeln gefunden. Gruß Bernhard PS: Ich will für die Benutzer taggen (tagging for users) Super Einstellung - aber die Benutzer der Tags sind - Entwickler von Routern - Entwickler von Karten-Designs - Entwickler von anderen Anwendungen, die das nutzen. Deren Produkte werden dann von anderen Nutzern wiederum genutzt, und das sind die, die du meinst. Das Taggen für letztere ist aber unmöglich ohne Absprache mit den Entwicklern (ersteren Benutzern); und ein falsches oder ungenaues Taggen, damit es dargestellt wird, ist zwar für ein paar der letzteren Nutzer aber gegen erstere. Für die Nutzer taggest du, wenn Du korrekt taggst, genau so wie die Tags es aussagen. Noch mehr für die Nutzer kannst Du tun, wenn Du das so machst, dass es mit der Absicht der Entwickler zusammenpasst. Wenn also ein Entwickler auf seiner Karte Gewanne darstellen will, soll er das können, indem er und du die selben Regeln und Tags dafür benutzt. Wenn ein Entwickler das aber nicht will, soll er auch das aus den Tags herauslesen können. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Hallo Bernd, entschuldige bitte - das war tatsächlich Bernhard - Schande über mein Haupt; In der Thread-Ansicht war das so weit nach rechts gerutscht, dass ich nur noch auf das Bern| geachtet habe. :/ Gruß Peter Am 26.02.2014 16:01, schrieb Bernd Wurst: Ich mach ja kein Tofu normalerweise aber hier kann ich nicht Sachbezogen antworten: Du legst mir in den Mund, dass ich irgendwas über irgend einen Goetheplatz geschrieben hätte. Habe ich nie. Ich weiß nichts von einem Goetheplatz. Lass das bitte. Am 26.02.2014 11:57, schrieb Peter Wendorff: Am 26.02.2014 11:20, schrieb Bernd Wurst: Hallo Peter. Zunächst: Watch your tone. Ehrlich. Am 26.02.2014 11:00, schrieb Peter Wendorff: Hallo Bernd, was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete Fragen stellen kann, was da was ist oder sein soll. Dass ein Name am Goetheplatz fehlt, hattest du geschrieben. Nein, habe ich nicht geschrieben. Stimmt, du hattest nur gefragt (Mail von gestern, 25.2., 23:12): Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits bekannten Platzes auf der Karte erscheint? Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt. Vielleicht hab ich da also einen konkreten Fehlerfall reininterpretiert, den es nicht einmal gab oder gibt - dann entschuldige ich mich für den Ton (erlaube mir aber, die Frage zu stellen, was du damit eigentlich erfragen wolltest). Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert werden sollte, hast du hier auch schon lesen können. Ja, betrifft mich aber null komma gar nicht. Sondern? Was betrifft dich denn dann? Denn die Frage hast du ja schon gestellt, zumindest ist die Mail bei mir so eingegangen. Was genau du brauchst, hast du ja nicht geschrieben - ich weiß nur, dass es um irgendeinen der Goetheplätze geht, die es gibt. Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen, die nur auf Hörensagen beruht, weil niemand außer dir das direkt überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig). Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach irgend einen x-beliebigen Waldweg an. Das Waldweg-Thema ist ein anderes und doch geklärt - da fehlt noch die Render-Regel, die beim Catch-All weggefallen ist, da kann man gucken, ob es ein Ticket gibt und bei Bedarf eins erstellen, einen Patch einreichen etc., darauf habe ich mich aber nicht bezogen. Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen - jedenfalls ist das meistens der Fall. Soviel also zu deiner Frage was denn noch. Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein* area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben kein area-Tag. das area-Tag ist nicht ausschlaggebend fürs Rendering; es ist aber notwendig, um ein lineares feature als Fläche darzustellen. waldwege: Da fehlt die Rendering-Regel, Goetheplatz: da fehlt das Wissen darüber, was da überhaupt drangetagged ist - und das verweigerst du ja weiterhin (oder es interessiert dich tatsächlich nicht mehr). Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man machen, muss dann aber auch alle etablierten Werte berücksichtigen. Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein. Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich bitte auch darum kümmern dass das gefixed wird. Ich glaube, bei konkreten Fehlermeldungen (wie gesagt: ich red vom Goetheplatz) würde das jemand übernehmen; spätestens auf eine direkte Bitte hin. Aber aus wagen Aussagen ein Ticket zu bauen ist etwas mehr Arbeit als sich bei github anzumelden. Wer das verbockt hat hat im Zuge dessen etliche andere Fehler behoben und damit die Gesamtlage im Rendering eher verbessert; zumindest aber langfristig eine richtige Grundlage gelegt, um gezielt eine korrekte Darstellung genau da zu erzielen, wo sie gewünscht wird. Wenn Du mit github ein Problem hast, frag doch einfach freundlich nach, beschreibe das Problem konkret und so, wie du es auch in ein Ticket schreiben würdest, und bitte darum, dass daraus jemand ein Ticket macht, ich bin sicher, dass dir das nicht verwehrt wird. Gruß Peter ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Update JOSM Mappaint Style Coloured Streets 2.0
+1 insbesondere würde das auch Tippfehler in Straßennamen einzelner Adressen visualisieren. Gruß Peter Am 26.02.2014 22:50, schrieb Florian Lohoff: On Wed, Feb 26, 2014 at 09:38:39PM +0100, Gertrud Simson wrote: Außerdem gibt es jetzt eine alternative Version, in der statt des ersten der letzte Buchstabe des Straßennamens ausgewertet wird. Dies ist geeignet für Länder, wo viele Straßen mit dem gleichen Buchstaben beginnen (z.B. in Frankreich Rue ...). Ich würde ein MD5 oder aehnlichen Hash verwenden über den Straßennamen und darauf das meinswegen erste Zeichen. Damit ist es egal an welcher stelle des strings eine veränderung eintritt. Flo ___ 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] Access-Tags
Hallo Christian, ich gebe dir nur zum Teil recht; die Tabelle war mir im Übrigen neu. Zunächst eine Frage: Welche Anwendung hält sich an diese Tabelle? Und gleich darauf aufbauend: gibt es eine maschinenlesbare Version, oder muss jede Anwendung jede mögliche Änderung der Tabelle wieder manuell einbauen? Eine solche Tabelle ist wertlos, wenn Routing-Software sie nicht einsetzt. Offensichtlich gibt es aber irgendein Projekt, dass sie einsetzt, aber nicht auf der Seite genannt wird - die Formulierung designated - same as yes but this road can optionally be prefered by some of your metrics. deutet jedenfalls darauf hin. Abgesehen davon ist ein Kernproblem der default-Frage nicht geklärt: Wie erkenne ich als Mapper (!), ob ich bei einer bestimmten Straße nochmal nachgucken sollte, was gilt, oder ob die default-Werte gelten? Dass Routingsoftware die Default-Werte annimmt ist ja schön und gut - aber wie unterscheidet man zwischen default und fehlend? Das ist nämlich leider nicht möglich. Für die Routingsoftware ist das egal - die muss mit fehlenden Daten irgendwie halbwegs sinnvoll umgehen können und entsprechend defaults annehmen; aber besser wäre es, wenn die Route nicht auf Annahmen, sondern auf vorhandene Daten gestützt werden könnte. Blöderweise gibt es aber eben mehrere verschiedene default-Semantiken: 1) Was nimmt Routingsoftware X an, wenn keine Angabe in den Daten steht? Diese Frage lässt sich mit einer solchen Tabelle dokumentieren und beantworten; notwendig dafür wäre aber auch die Angabe der Router, die sich danach richten, denn natürlich ist es keine völlig unsinnige Entscheidung, highway=track nur im Notfall in die Auto-Route mit einzubeziehen, womit es meist access=destination entsprechen dürfte. 2) Was ist ohne besondere Ausschilderung gültig? Bezieht sich neben den access-Tags insbesondere auch auf Geschwindigkeitsbegrenzungen, hat aber mit OSM und dem Mapping eigentlich wenig zu tun, sondern entspricht weitgehend (1) für Software, die sich an die Regeln hält. Was ausgeschildert dransteht würde ich aber immer auch so eintragen. Wenn an einer Straße innerorts (in DE) ein Tempo-50-Schild dransteht, dann trage ich das so auch ein - obwohl innerorts per default 50 gilt. Denn falls irgendwann die Geschwindigkeit generell auf 30 gesenkt werden sollte, gelten bestehende Schilder mit 50 weiterhin. Es ändern sich also die Regeln genau für die Fälle, wo dies nicht dransteht. Aus den Gründen finde ich die Tabelle einen guten Ansatz - aber nur, wenn die Erklärung dazu passt, und die fehlt bisher. Wer großflächig an Bundes- und Landstraßen maxspeed=100 tagged, nur weil kein Schild dransteht, erzeugt Probleme für mögliche Anpassungen der Höchstgeschwindigkeit, z.B. auf 70, was jetzt schon auf einem großteil der Landstraßen gilt. Gruß Peter Am 27.02.2014 11:22, schrieb chris66: Am 27.02.2014 07:58, schrieb Manuel Reimer: Also eigentlich ein access = yes um alles zu erschlagen. Im Wiki wird von der Kombination access = yes aber abgeraten. Wie ist es also richtig und vollständig wenn man einen Waldweg mit oben genannten Schildern taggen will ohne unnötig viel Tag-Wirrwarr zu produzieren? Gilt bei Access-Tags alles was nicht verboten ist, ist erlaubt oder muss alles was erlaubt ist dran stehen? Wenn letzteres: Muss dann auch an jedem highway = residential die ganze Access-Tag-Flut dranstehen und wenn nein: Warum nicht? Moin, es gibt im Wiki eine Tabelle[1] mit den default-access-rights pro Wegklasse. Das Setzen expliziter Tags ist also nur bei abweichenden Beschränkungen notwendig. Das OSM Verkehrszeichentool unterstützt bei der Findung der korrekten Tags: http://osmtools.de/traffic_signs/?signs=260,1026-37 Chris [1] http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions ___ 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] Access-Tags
Am 27.02.2014 12:59, schrieb Falk Zscheile: Denn die Zugangsregeln nach den LWaldG variieren von Bundesland zu Bundesland. Bewusst provokant: Mit dem Argument kann man aber auch die Defaults für Staaten weglassen - denn auch die variieren von Staat zu Staat. Oder andersrum: So wie es eine Tabelle für Defaults pro Staat gibt, könnte es auch eine verfeinerte Tabelle für weitere Gliederungsebenen geben, in Deutschland eben Bundesländer. Nur sinkt die Wahrscheinlichkeit, dass Anwendungen so etwas in dem Detailgrad unterstützen, natürlich weiter. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Hallo Bernd, was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete Fragen stellen kann, was da was ist oder sein soll. Dass ein Name am Goetheplatz fehlt, hattest du geschrieben. Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert werden sollte, hast du hier auch schon lesen können. Wenn das nicht korrekt dargestellt wird, ist das meines Erachtens ein Fehler im aktuellen Rendering - dann muss man eine entsprechende Fehlermeldung machen; auch dazu wäre ein konkreter Verweis auf eine Stelle in der Karte sinnvoll. Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen, die nur auf Hörensagen beruht, weil niemand außer dir das direkt überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig). Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen - jedenfalls ist das meistens der Fall. Soviel also zu deiner Frage was denn noch. Gruß Peter Am 26.02.2014 08:46, schrieb Bernd Wurst: Hallo. Am 26.02.2014 08:31, schrieb Walter Nordmann: Bernhard Weiskopf wrote Wie trägt man das jetzt ein? Genügt name = ... nicht mehr? Ja, name=* reicht nicht mehr aus - und das ist gut so! Ja, aber selbst highway=... und name=... reicht scheinbar nicht aus? Was denn noch? render_this_name=yes oder wie? :-) ___ 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] Keine Namen in Mapnik und anderen Karten
Am 26.02.2014 11:20, schrieb Bernd Wurst: Hallo Peter. Zunächst: Watch your tone. Ehrlich. Am 26.02.2014 11:00, schrieb Peter Wendorff: Hallo Bernd, was hältst Du davon, konkrete Probleme zu verlinken, damit man konkrete Fragen stellen kann, was da was ist oder sein soll. Dass ein Name am Goetheplatz fehlt, hattest du geschrieben. Nein, habe ich nicht geschrieben. Stimmt, du hattest nur gefragt (Mail von gestern, 25.2., 23:12): Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits bekannten Platzes auf der Karte erscheint? Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt. Vielleicht hab ich da also einen konkreten Fehlerfall reininterpretiert, den es nicht einmal gab oder gibt - dann entschuldige ich mich für den Ton (erlaube mir aber, die Frage zu stellen, was du damit eigentlich erfragen wolltest). Dass das zusammen mit highway=pedestrian und area=yes korrekt gerendert werden sollte, hast du hier auch schon lesen können. Ja, betrifft mich aber null komma gar nicht. Sondern? Was betrifft dich denn dann? Denn die Frage hast du ja schon gestellt, zumindest ist die Mail bei mir so eingegangen. Was genau du brauchst, hast du ja nicht geschrieben - ich weiß nur, dass es um irgendeinen der Goetheplätze geht, die es gibt. Wer aber sollte jetzt ein Ticket aufgrund einer Fehlermeldung aufmachen, die nur auf Hörensagen beruht, weil niemand außer dir das direkt überprüfen kann (denn Goetheplatz gibt's schon ganz schön häufig). Ich habe nur von einigen Waldwegen gesprochen. Eigentlich sind es alle Waldwege. Ich kann dir hunderte Links schicken. Oder du schaust einfach irgend einen x-beliebigen Waldweg an. Das Waldweg-Thema ist ein anderes und doch geklärt - da fehlt noch die Render-Regel, die beim Catch-All weggefallen ist, da kann man gucken, ob es ein Ticket gibt und bei Bedarf eins erstellen, einen Patch einreichen etc., darauf habe ich mich aber nicht bezogen. Also: Gib uns einen Link und es wird jemand versuchen, dir zu helfen - jedenfalls ist das meistens der Fall. Soviel also zu deiner Frage was denn noch. Die Frage war ganz konkret: Was ist bei einem normalen Weg denn außer name noch nötig um ein Redering des Namens zu erwirken. Dass es *kein* area-Tag geben soll konnte man hier heraus lesen. Aber meine Wege haben kein area-Tag. das area-Tag ist nicht ausschlaggebend fürs Rendering; es ist aber notwendig, um ein lineares feature als Fläche darzustellen. waldwege: Da fehlt die Rendering-Regel, Goetheplatz: da fehlt das Wissen darüber, was da überhaupt drangetagged ist - und das verweigerst du ja weiterhin (oder es interessiert dich tatsächlich nicht mehr). Meine Mutmaßung ist ja, dass hier der Style von highway=* auf einige wenige explizit eingetragene Werte eingeschränkt wurde. Das kann man machen, muss dann aber auch alle etablierten Werte berücksichtigen. Bisher scheint track kein gültiger Wegtyp in diesem Sinne zu sein. Ich seh's irgendwie nicht ein, für ein Problem einen Bugreport [1] auf zu machen das derart offensichtlich ist. Wer das verbockt hat, soll sich bitte auch darum kümmern dass das gefixed wird. Ich glaube, bei konkreten Fehlermeldungen (wie gesagt: ich red vom Goetheplatz) würde das jemand übernehmen; spätestens auf eine direkte Bitte hin. Aber aus wagen Aussagen ein Ticket zu bauen ist etwas mehr Arbeit als sich bei github anzumelden. Wer das verbockt hat hat im Zuge dessen etliche andere Fehler behoben und damit die Gesamtlage im Rendering eher verbessert; zumindest aber langfristig eine richtige Grundlage gelegt, um gezielt eine korrekte Darstellung genau da zu erzielen, wo sie gewünscht wird. Wenn Du mit github ein Problem hast, frag doch einfach freundlich nach, beschreibe das Problem konkret und so, wie du es auch in ein Ticket schreiben würdest, und bitte darum, dass daraus jemand ein Ticket macht, ich bin sicher, dass dir das nicht verwehrt wird. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Keine Namen in Mapnik und anderen Karten
Hallo Bernhard, warum sollte area=yes, name=foo denn gezeichnet werden? area=yes sagt schließlich nichts anderes aus, als dass ein OSM-Objekt, das nicht aufgrund irgendwelcher anderer Attribute eindeutig als Linie oder Fläche zugeordnet werden kann, definitiv eine Fläche ist. So kann man dicke Stadtmauern, Hecken, Wälle, Deiche etc. als Fläche einzeichnen. Mehr tut area=yes aber nicht, und wenn das tatsächlich DER Indikator in Mannheim ist, um die benannten Blöcke darzustellen, dann ist das ein Problem. Für einen Platz wie den Goetheplatz kommt das name-Tag aber eigentlich auch nicht vom area=yes, sondern vom highway=residential, oder highway=pedestrian, denn die werden mit Namen gerendert (sowie einige andere highway-Werte auch). area=yes entscheidet allerdings darüber, ob der Name entlang der Linie (nämlich z.B. bei einer ringförmigen Straße) oder auf der Fläche (eben bei Plätzen oder als Fläche eingetragenen Straßen) auf der Karte erscheinen soll. DASS der Name dargestellt wird, hat aber mit area=yes|no nichts zu tun. Der Goetheplatz ist also highway=pedestrian, wenn er Fußgängerzone ist, amenity=parking, wenn es sich um einen Parkplatz handelt, alternativ Marktplatz oder was auch immer - was es eben ist. Wenn kein Tag passt, brauchen wir dafür ein Neues, aber das hat mit dem Rendern der Namen nicht viel zu tun (obwohl dann eben neuerdings für ein neues Tag auch eine neue Render-Regel notwedig wäre, und das ist gut so). Gruß Peter Am 25.02.2014 23:12, schrieb Bernhard Weiskopf: In Mannheim ist Mapnik zurzeit kaum noch zu gebrauchen. Die Wohnstraßen der Vororte tragen noch Namen. Aber die Quadrate der gesamten Innenstadt sind namenlos und die Straßen in den Naherholungsgebieten zwischen den Vororten (highway = track) werden nun auch namenlos angezeigt, obwohl sie Straßennamen tragen, bei Fußwegen (path oder footway) mit Namen genauso. Sogar bei öffentlichen Zufahrtswegen zu Höfen (highway = service) wird der Straßenname nicht mehr angezeigt. Wie trägt man zukünftig den Goetheplatz ein, damit der Name des allseits bekannten Platzes auf der Karte erscheint? Ich nehme an, der Name von area = yes wird dann nicht mehr angezeigt. Bernhard -Ursprüngliche Nachricht- Von: Frederik Ramm [mailto:frede...@remote.org] Gesendet: Dienstag, 25. Februar 2014 22:35 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Keine Namen in Mapnik und anderen Karten Hi, On 25.02.2014 22:18, Bernhard Weiskopf wrote: Kennt jemand den Grund, warum die Karten kaum noch Texte enthalten sollen? Das ist eine Suggestivfrage. Es gibt keinen Grund, warum die Karten kaum noch Texte enthalten sollen, denn die Karten sollen nicht kaum noch Texte enthalten. Unser Mapnik-Stylesheet hat historisch eine sogenannte catch-all-Regel für Dinge mit Namen enthalten. Diese Regel besagte, vereinfacht gesagt: Egal was es ist, wenn es einen Namen hat, dann schreib ihn irgendwie hin. Das führte immer wieder zu seltsamen Stilblüten in den Karten - irgendjemand zeichnet z.B. ein boundary=air_traffic, name=Flugbeschränkungsgebiet R123, und obwohl Mapnik keine Render- Regeln für Flugbeschränkungsgebiete hat, hat er trotzdem schön irgendwo entlang einer unsichtbaren Linie Flugbeschränkungsgebiet R123 geschrieben. Das war unerwünscht; erwünscht ist vielmehr (in aller Regel), dass Namen nur für exakt die Objekte auf der Karte erscheinen, die selbst auch gezeichnet werden. Dazu müssen also die catch-all-Regeln entfernt und durch spezielle Beschriftungsregeln für genau die gezeichneten Objekte ersetzt werden. Das ist im großen und ganzen auch gelungen, aber einige Labels sind dabei unter die Räder gekommen - die meisten unabsichtlich; in einigen Fällen war es vielleicht wirklich nicht beabsichtigt, einen bestimmten Objekttyp einzuzeichnen. Also, langer Rede kurzer Sinn: Keine Panik, sie sind nicht hinter Dir her, und über kurz oder lang wird das alles wieder gut. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Der VRR Stellt sich vor
Hallo Christoph, generell interessiert wär ich schon, aber ich sträube mich noch ein bisschen vor dem Aufwand mit Anfahrt aus Paderborn und Abends zurück. ;) Eingetragen hab ich mich vor allem deshalb nicht bisher, weil noch einige Termine offen sind für die Woche, auf die ich keinen Einfluss habe; das sollte sich aber bis Dienstag erledigt haben. Außerdem bin ich als nun eigentlich kein Vertreter der lokalen Community. Ich trag mich aber mal als vielleicht ein vorerst. Gruß Peter Am 22.02.2014 17:53, schrieb Christoph (TheFive@OSM): Hi, der VRR (Verkehrsverbund Rhein Ruhr) möchte enger mit OSM Zusammenarbeiten, und hat uns angeschrieben. Die Einladung ging schon über diverse lokale Mailinglisten und ist auch schon im Forum geposted worden. Da die Teilnahme von OSM noch Potential nach oben hat, nutze ich noch einmal Talk-DE damit das auch überall ankommt. Organisation unsererseits findet hier: http://wiki.openstreetmap.org/wiki/VRR/Zusammenarbeit Statt, da ist auch das Einladungsschreiben. Der VRR hätte gerne in 4 Tagen eine erste Rückmeldung ob wir als Hunderschaft oder mit 1nem Abgesandten kommen. Christoph ___ 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: [OSM-talk] Not attaching polygons to roads
Hi Frederik, I agree - but only in parts. If the other mapper shares nodes between the road and the field, and the field is surrounded (and tagged as such) with a fence, so the field is e.g. landuse=farmland, barrier=fence, then this is an error in the map as it states that the fence is in the middle of the street or it's not possible to decide where relative to the street the fence is. In this case dividing them without adding new features IMHO is fixing a bug in the map data, and joining a fence with a way along several nodes in a line is an error - if not vandalism when doing it repeatingly while igoring personal messages according to the same issue. Nevertheless of course you're right: Changing the way of mapping without adding value/improvement (!) is not okay. regards Peter Am 20.02.2014 23:40, schrieb Frederik Ramm: Hi, On 20.02.2014 23:04, Dave F. wrote: There's a general consensus that attaching polygons to ways that represent roads was a bad idea. Not really. There is not a consensus but a ceasefire. Everyone is free to map this as they like, and to change it if there's a need - e.g. someone else has connected the field to the road, now you want to map the fence, so you need to split it apart. That's ok. Similarly, someone re-doing the whole area from better imagery or whatever has every right to map as he pleases - if they thing they can be more efficient by joining boundaries, more power to them. What is *not* ok is one person cleaning up after the other without actually adding any other improvement. I.e. if the other guy has connected the fields and the roads and you have been *only* pulling them apart without contributing anything else to the area in question, then you should have let them be; on the other hand, if the other guy has merged fields and roads that previously were separate, then they shouldn't have done that. This whole question is essentially a matter of taste, and you are allowed to map according to your taste, and discouraged from enforcing your taste for others. Bye Frederik ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Not attaching polygons to roads
Am 21.02.2014 10:44, schrieb Pieren: On Fri, Feb 21, 2014 at 9:19 AM, Peter Wendorff wendo...@uni-paderborn.de wrote: If the other mapper shares nodes between the road and the field, and the field is surrounded (and tagged as such) with a fence, so the field is e.g. landuse=farmland, barrier=fence, then this is an error in the map as it states that the fence is in the middle of the street or it's not possible to decide where relative to the street the fence is. That's maybe an original issue with landuse polygons. Once you go to this level of details (fence), the border line between landuse's is not a clear sharp line. As suggested by Shaun, once you add fences and detach the farmland, you should also fill the gap created and make the landuse=highway. People detaching landuse from road lines are most of the time doing half of the job. I may agree here, but in OSM I think doing half the job is better than mapping wrong stuff. OSM is a database, not (only) a map, and there isn't something like once you go to this level of details. Let's extend the example slightly: Let there be from left to right a field, a fence, a street, a hedge and a park. Let the fence in addition be not around the field, but only at the borderline to the street (so it's not a tag on the field polygon any more, while the hedge surrounds the park (where entrances are mapped as such on nodes). Now Mapper A starts mapping with low detail from aerial imagery: he draws a polygon for the field, another polygon for the park, and a way for the street, and tags it as landuse, leisure and highway respectively. He omits the fence and the wall. As you said, this is perfectly valid (although it's a little bit ugly to detect that it's not a park directly beside a field, because you would have to create the corresponding buffer for the highway for that; it's not possible to calculate the exact area of the field, as we're wrong by 6 meters for half the street width.) Mapper B is on the ground a while later and recognizes that there's a fence and a hedge. Adding the hedge seems to be easy: she adds the barrier=hedge-tag to the park. Adding the fence is easy, too, but how to do this? She definitively has to draw a new way as there's no geometry matching the fence. But where? By the rules applied in this scenario up to now it would be fine to add the fence as a way sharing the nodes that are already shared by park, highway, hedge and field. But what happens when doing this? There is a set of nodes that is hedge and fence. Might be possible: I would interpret this as a fence inside a hedge, which is possible and well known in the wild. But what's the matter with the highway? well... then the highway must be in between the hedge with fence and the field with the wall... Well - wait... it could be a fence on top of a wall instead - now the fence is on the other side of the way... Or it could be a fence in the middle of the street - strange... In fact the map says, there's a fence, a wall and a street's center line at the same position. Independent of the level of detail I would assume for the application this is simply wrong, and keep in mind: the coordinates are in a level of detail of 10cm or better, with no way to see what level of detail is ment by any particular mapper with any particular object. Let's invite Mapper C. He - as you suggests would like to clean up the mess produced by A and B, and it's going to be hard work. Without being on the ground it seems to be possible to detach the park with the hedge from the way on the first glance, but damn it - what to do with the wall? Isn't it wrong to detatch the fence if it might be possible that in fact the fence is on top of the wall? If so it would be necessary to detatch the fence, too and let fence and wall share nodes. If not, this would create a different but completely wrong situation. So nothing can be made better without being on the ground. C decides to take his bike and and ride a whole day to that place as unfortunately there's no active mapper any more (A and B stopped mapping months ago). Now he knows what's the situation on the ground and has to detatch lines from each other, stumbling over several ugly issues in the osm editor software available: - How to select one of many ways sharing the same nodes? - how to minimize breaking object history - but remapping everything would be more simple to do. If A and B would have drawn lines in parallel, leaving a gap for the highway in between it would be much easier. Changing the way of mapping without adding value/improvement (!) is not okay. At least, new contributions shouldn't decrease the quality. +10, but filling the map without empty gaps isn't a good measurement of quality. regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] D-A-CH
Hallo Frederik, wie groß ist denn der Nachteil beim Zusammenbauen? Das Script, das Du angibst, ist ja erstmal nicht so besonders kompliziert; wie viel Laufzeit und Speicher kostet es, entsprechende Extrakte zusammenzubauen? Naiv und ohne Details des osmosis-codes zu kennen müsste doch eigentlich (wenn man voraussetzen kann, dass die Versionen aller Objekte in allen Teilextrakten zusammenpassen) einmal durch alle osm/pbf-Dateien geparst werden, während die bereits übernommenen ObjektIDs gespeichert sind. Das ist also weitgehend lineare Laufzeit in der Größe der Eingabedateien; und wenn man möchte, kann man statt einer Ergebnisdatei ja auch direkt die weitere Verarbeitung - DB-Import etc. anhängen. Eine Umsetzung für unterschiedliche Shells (notfalls einschließlich Windows) sollte auch machbar sein. Wenn also der Overhead zumindest bestimmter Nachbarextrakte nicht zu groß ist, ist es vielleicht eine Überlegung wert, so 'ne Art Download-Paket-Option anzubieten: Man lade DE, A, CH in einen Ordner, in dem auch das merge-Script liegt und starte das Script (das kann für langsame Netzwerkverbindungen bei Bedarf auch schon während des downloads loslaufen); der Rest ergibt sich von selbst. Oder übersehe ich dabei was wichtiges? Gruß Peter P.S.: Deshalb sind natürlich manche Extrakte, gerade für Kontinente etc. trotzdem sinnvoll, weil es bei denen für die Speicherung der schon übernommenen Objekte schon für einen nicht allerneuesten Heim-PC elend viel Speicher braucht... Am 20.02.2014 23:25, schrieb Frederik Ramm: Hallo, On 20.02.2014 21:59, Christian H. Bruhn wrote: Ist der Bedarf nach DACH-Daten tatsächlich so groß? Oder wollen die Leute nicht eher BYBWACH? Das ist ja schon das Alpen-Extrakt ;) Der Bedarf nach DACH ist zumindest der am häufigsten geäußerte. Ich hab mich bislang immer geziert, weil ich wusste, dass dann natürlich all die Fragen nach Benelux, Deutschland+Polen, Ostsee-Anreinerstaaten und und und kommen. Im Grunde kann man sich benachbarte Regionen mit Osmosis zusammenbauen, hier z.B. ein Skript für ein Benelux+Niedersachsen+Nordrheinwestfalen+Rheinlandpfalz-Extrakt: SCHNIPP #!/bin/sh set -e BASE=http://download.geofabrik.de/europe; PIECES=germany/niedersachsen germany/nordrhein-westfalen germany/rheinland-pfalz belgium netherlands luxembourg OUTPUT=meinfile.osm.pbf OSMOSIS=/srv/osmosis/bin/osmosis # hierunter nix aendern NUM=0 MERGE= OSMOSISFLAGS= export NUM MERGE OSMOSISFLAGS for p in $PIECES do NUM=`expr $NUM + 1` wget -qO$NUM.osm.pbf $BASE/$p-latest.osm.pbf OSMOSISFLAGS=$OSMOSISFLAGS --read-pbf $NUM.osm.pbf $MERGE MERGE=--merge done $OSMOSIS $OSMOSISFLAGS --write-pbf $OUTPUT SCHNAPP Das sollte eigentlich auch die wegen Überschneidung doppelten Ways richtig rauswerfen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik Administration blockt QLandkarteGT
Ähm? Sorry, kann mir irgendjemand erklären, wie Dirk das hier meint? Ich versteh's immer noch nicht. Ich versuch noch einmal, meine Verständnisschwierigkeiten zwischen den Zeilen deutlich zu machen. Am 17.02.2014 18:51, schrieb Dirk Sohler: Peter Wendorff schrieb: Und wie kommen dann die Kacheln zum Browser des Nutzers? Die entsprechenden Daten werden über die API abgerufen, die entsprechende Kachel verlinkt, und der Browser stellt sie dar. Wer ruft jetzt welche Daten wo ab? Wie sieht der Link aus, den der Browser dann aufruft, bevor er die daraus bezogene Kachel darstellt? Es geht hier AUSSCHLIEẞLICH um den Abruf der Daten für die entsprechende Kachel aus der API. Nicht um das Einbinden, den URL, oder das Rendern der Wbesite im Browser. Da ist eine komplett andere Baustelle. Nein, ist es nicht, denn der Abruf der Daten aus der API, wie du es bezeichnest, ist doch genau die Kachel. Der Abruf passiert gerade - und zwar ausschließlich - über die URL, die eingebunden wird; der entsprechende Schlüssel müsste also an die URL angehängt werden, und damit für den Browser ersichtlich sein (sagte ich das nicht bereits?). Die zwei möglichen technischen Alternativen, die ich sehe, sind: 1) Sitzungsschlüssel zwischen Server und serverseitiger Anwendung (bzw. Server und closed-source-komponente) aushandeln, damit dann clientseitig den Key verschlüsseln. Aufwand: Das ganze durchs CDN propagieren etc., und bei langem Aufenthalt auf der Seite muss der Schlüssel auch noch regelmäßig neu ausgehandelt werden, damit er nicht geklaut werden kann; 2) Der jeweilige Webserver muss als Proxy für die auf seinen Seiten ausgelieferten Tiles fungieren, also nicht mehr der Browser läd von tile.osm.org, sondern der webserver von meineseite.de läd von tiles.osm.org und gibt die Kacheln dann unter tiles.meineseite.de weiter. Machbar, aber problematisch, was a) Traffic insgesamt b) komplexität auf OSM-Administrationsseite, c) Aktualität von Kacheln und vor allem d) Komplexität für den kleinen Webseitenbetreiber, der mal eben eine Karte einbinden will, angeht. Insbesondere letzteres ist immer noch ein häufig genutztes Argument für die Google-Maps-API, obwohl das bisher nicht mehr stimmt - mit der Lösung wäre das nur allzu wahr. P.S.: Ja, man kann das ohne lösen, indem tatsächlich die Webseiten-Serveranwendung direkt mit dem Tileserver redet, verschlüsselt ein Sitzungstoken aushandelt Na ja, oder eben dass in der Konfiguration des Wbeservers – bzw. genau genommen in dem Teil der Webanwendung, die auf dem Server, außerhalb des Zugriffs durch den USer, der API-Key hinterlegt ist. Du hast immer noch nicht erklärt, wie der API-Key dann ohne Zugriff des Users dazu führen soll, dass eben der User die Kacheln sehen kann - warum die beiden mir einleuchtenden Varianten, die du da im Kopf haben könntest, nicht funktionieren, hab ich oben erklärt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik Administration blockt QLandkarteGT
Also kannst Du Anwendung und Browser voneinander unterscheiden? Spannend... Am UA-String ja offensichtlich nicht, denn dann könnte ja auch weiterhin jede Anwendung sich einen Browser-UA-String suchen und den nutzen, ohne dass das ein Problem wäre. Abgesehen davon: Was ist ein Browser, was eine Anwendung? Ist eine Facebook-App ein Browser, wenn sie Links verfolgt? Ist Thunderbird ein Browser, weil man auch innerhalb von Thunderbird unter Nutzung der Gecko-Engine Webseiten direkt öffnen kann? Ist ein Browser-Plugin für Mails noch ein Browser? ist ein Browserplugin, das die vorhandene Adressbuchfunktion um eine Karte erweitert, die die Kontakte darauf darstellt? Inwiefern würde eine solche Lösung das Verfahren einfacher, fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter machen? Gruß Peter Am 16.02.2014 12:27, schrieb Dirk Sohler: Christoph schrieb: Verstehe ich das richtig ? Du möchtest jedem user einen account verpassen? Das muss dann konsequenterweise auch bei Browsernutzung passieren. Jedem User, der eine Anwendung != Browser benutzt, die auf die API zugreift. Grüße, Dirk ___ 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] Mapnik Administration blockt QLandkarteGT
Hallo Dirk, das ist uns und auch den Admins schon klar, dass man das umgehen kann. Und auch, dass mutwillige Sabotage, zu der ich das zählen würde, damit nicht ausschließen kann. Die Pflicht zu einem gültigen UA-String hat aber nicht in erster Linie den Hintergrund, böswillige Nutzer wie dich ;) direkt zu kriegen, sondern gutwillige Entwickler, die zurecht erstmal davon ausgehen, dass sie testweise und für Software, die mal eine Handvoll Kacheln braucht, die öffentlichen osm-kacheln nutzen dürfen, darauf hinweisen zu können, dass ihre Software eben wohl doch nicht nur eine Handvoll Kacheln zieht. Insbesondere ist eben auch nicht ein Programm betroffen, was ähnlich zu einem Browser genau die Kacheln herunterläd, die zur Darstellung der Karte gebraucht werden - solange das Programm nicht verkauft wird, ist dies eine analoge und normalerweise tolerierte Anwendung (vorausgesetzt, die Attributierung ist korrekt). Hier geht es aber um ein Programm, das unter anderem den Massenhaften Download tausender Kacheln erlaubt, und genau das ist nicht mehr erlaubt. Wenn Du persönlich wget anweist, sich als Firefox oder sonstwas auszugeben, verstößt Du persönlich genauso gegen die Tile Usage Policy, denn die besagt ganz eindeutig, dass ein sinnvoller, korrekter UA gesendet werden soll, der die Identifikation der Anwendung erlaubt. Mit gesundem Menschenverstand weißt vermutlich auch du, dass damit nicht gemeint ist, dass sich ScrapeOSM (tm) als wget ausgeben darf, selbst wenn es sich um ein Shellscript handelt, das wget für den eigentlichen Download nutzt. Da jetzt weiter zu diskutieren hilft auch nicht besonders - ganz auszuschließen ist Missbrauch nicht, sicher; aber nur weil nicht jeder Diebstahl aufgeklärt wird, verlangst du ja auch im Strafrecht nicht, Diebstahl zu erlauben, oder? Es geht nicht um die einwandfreie Identifikation eine Clients, sondern um das Finden von möglicherweise ungünstig programmierten Anwendungen, und wie du am Beispiel von QLandkarte merkst, scheint auch die Weigerung, einen sinnvollen UA-String anzugeben, nicht sicher vor dem Block zu schützen. Du hast immer noch keine Alternative ohne Account-Pflicht (die ja, wie wir bereits festgestellt haben, auch nicht funktioniert, solange online ohne Account Kacheln dargestellt werden können sollen) vorgestellt. Bis dahin brauchen wir glaub ich kaum weiterzudiskutieren. Gruß Peter Am 16.02.2014 12:39, schrieb Dirk Sohler: Simon Poole schrieb: - zu behaupten, dass eine Massnahme nicht funktionieren kann Bitte genau lesen. Ich wies jedenfalls völlig richtig darauf hin, dass der User-Agent nicht dazu geeignet ist, einen zugreifenden Client (anders als ein Token oder besser ein Useraccount) einwandfrei zu identifizieren, und daher als alleiniges Erkennungsmerkmal schlicht ungeeignet ist. Ich könnte wget anweisen, sich als „wget/1.15“ auszuweisen, oder aber auch als „Skynet/1.0“ oder als ein aktueller Firefox. In allen drei Fällen kann ich massenhaft scriptgesteuert Kacheln runterladen, bis die Leitung glüht, und im letzten Fall kann ich nicht mal gesperrt werden (IPs lassen sich wechseln), und alle drei Varianten ist der entstandene Traffic sogar ein paar Byte je Abruf größer als ohne UA. Die Maßnahme an sich funktioniert in einem gewissen Rahmen, nur stützt sie sich auf etwas, das vom Konzept her von Grund auf als technisch komplett unverifiziert einzustufen ist. Grüße, Dirk ___ 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] Mapnik Administration blockt QLandkarteGT
Am 16.02.2014 15:13, schrieb Dirk Sohler: Peter Wendorff schrieb: Also kannst Du Anwendung und Browser voneinander unterscheiden? Mittels anwendungsspezifischem Token, der aufgrund der API nur durch entsprechende Header übermittelt werden kann eher, als über einen simplen String, in den jeder reinschreiben kann, was er will. Wenn jemand fälschen will, dann ist das auch da kein Problem, den Token zieh ich mir eben von osm.org direkt. Dazu gehört dann außerdem noch die Authentifizierung über alle Tilecache-Instanzen etc pp - nicht grade wenig Aufwand für minimal mehr Hilfe. Abgesehen davon: Was ist ein Browser, was eine Anwendung? Stelle dich doch bitte nicht bitte dümmer, als du bist. Hier: Browser = Das Ding, mit dem du im WWW (!= „das Internet“) Seiten aufrufen kannst, und eben auch die OSM-Seite; also: Firefox, Thunderbird, Thunderbird-Adressbuch mit OSM-Karten-Erweiterung (gibt's die? wär praktisch...), Internet-Explorer, jede Anwendung, die die entsprechende IE-ActiveX-Komponente benutzt, um Webseiten darzustellen, wget (cool, kann www-Seiten aufrufen...), ... und Anwendung: Spezielles Programm, das zum Abruf der OSM-Kacheln über die OSM-API verwendet wird, ohne darüber hinaus andere Dienste im Internet (vgl. WWW) nutzen zu können. Okay, also wenn meine App Twitternachrichten und OSM-Kacheln darstellt, ist es demnach ein Browser? Ist [beliebige Anwendung] ein Browser, wenn sie Links verfolgt? In dem hier verwendeten Zusammenhang ist eine Anwendung dann ein Browser, wenn sie die WWW-Seite benutzt. Wenn sie die API benutzt, nein. Und wo ist der Unterschied zwischen WWW-Seite und API? Du bist ja derjenige, der mit Umgehungsmöglichkeiten argumentiert. Wenn ich also www.osm.org mit entsprechendem permalink aufrufe und alle damit verbundenen Kacheln mit runterlade, ist das wieder ok? wenn ich das hundertmal tue, auch? Aber da du nur provozieren willst, brauche ich dir das sicher nicht zu erklären, da du es bereits weißt. Ich will nicht provozieren. Du kritisierst eine seit langem angewandte Praxis, die weitgehend funktioniert; und hängst die auch noch an einem Fall auf, der offensichtlich ja eben sogar gefunden wurde. Du äußerst aber Kritik, ohne einen funktionierenden und mit vertretbarem Aufwand umsetzbaren Gegenvorschlag anzubringen. Inwiefern würde eine solche Lösung das Verfahren einfacher, fälschungssicherer, sinnvoller oder sonst irgendwie erstrebenswerter machen? Die Vorteile eines anwendungsspezifischen Tokens sind, sofern der Token geheim bleibt (Closed-Source oder sonstwie verschlüsselt, und nicht einfach so durch andere Nutzbar, oder über Sniffer aus den übertragenen Datenpaketen auslesbar), dass die Anwendung zuverlässig identifiziert werden kann. CLosed-Source - cool, also auch noch alle OpenSource-Software im OSM-Ökosystem rausschmeißen, weil damit das System nicht funktioniert. Ich glaube, du hast das Grundprinzip immer noch nicht verstanden, und das heißt Fairness und Offenheit. Das Tool von Github kann keiner mal eben forken, weil das Token nicht drin ist (und nicht drin sein kann, denn sonst wär das ja nicht mehr verschlüsselt), dafür muss man sich zusätzlich bei OSM anmelden - wunderbar... - aber irgendwie eben nicht Offen. Die Vorteile eines „Accountzwangs“ bei einer Anwendung (vgl. Definition weiter oben) ist, dass man eindeutig einen Useraccount identifizieren kann, und man diesen Gezielt sperren kann. Natürlich kann ein Anwender sich einfach einen neuen Account anlegen, aber ein Entwickler kann auch seiner Anwendung den Firefox-UA-String verpassen. Aber mal andersherum gefragt: Inwiefern ist alleinig die Auswertung eines simplen Strings fälschungssicher? Was hindert einen Entwickler, der alle Tiles runterladen will eher daran, das technisch umzusetzen? Ein beliebig änderbarer String, eine App-Registrierung um einen Token zu bekommen, oder die Notwendigkeit eines Useraccounts? Abgesehen vom Aufwand auf dem Server, um die Token-Lösung einzusetzen - wie würdest du das für, sagen wir, JOSM umsetzen wollen? Steht der Token im Code und damit im SVN? Steht der Token nur im Build und auch da Verschlüsselt? Wie passt das dann mit OpenSource zusammen? Soll sich jeder Entwickler, der mal einen Patch einreicht, extra registrieren? Und wenn ja, dann haben wir entsprechend hunderte Registrierungen, was hindert dich als denjenigen, der sich hier als der Böse aufspielt, der alles aushebeln kann, daran, deine Anwendung hundertmal zu registrieren und und den Token immer wieder zu wechseln? Sorry, irgendwie überzeugt mich das noch nicht. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik Administration blockt QLandkarteGT
Am 16.02.2014 16:34, schrieb Dirk Sohler: Peter Wendorff schrieb: Du hast immer noch keine Alternative ohne Account-Pflicht […] vorgestellt. Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key), wie bereits mehrfach erwähnt. Wie bereits mehrfach erwähnt untauglich, solange du keine Lösung für den Overhead in der Infrastruktur und zusätzlich gerade bei OpenSource-Software für folgende Probleme präsentierst: - Wie verhinderst Du, dass Leute wie Du dann hundert API-Keys für eine Anwendung nutzen? - Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal was committen, einen eigenen entwicklerspezifischen API-Key haben müssen? bzw. wenn Du das nicht für notwendig hältst, - wo steht der API-Key in einer OpenSource-Anwendung, wenn nicht im Quelltext-Repository? Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik Administration blockt QLandkarteGT
Am 16.02.2014 17:13, schrieb Dirk Sohler: Peter Wendorff schrieb: Am 16.02.2014 16:34, schrieb Dirk Sohler: Anwendungsspezifischer Token (oder Entwicklerspezifischer API-Key), wie bereits mehrfach erwähnt. Wie bereits mehrfach erwähnt untauglich, solange du keine Lösung für den Overhead in der Infrastruktur […] präsentierst: Sicherheit und Komfort schließen sich leider gegenseitig aus :( - Wie verhinderst Du, dass Leute wie Du dann hundert API-Keys für eine Anwendung nutzen? Genau so, wie die OSM-Admins aktuell Missbrauch verhindern: Gar nicht. Also bietest Du als Alternative für ein nur sehr eingeschränkt funktionierendes System ein System, was genauso eingeschränkt funktioniert, aber zusätzlichen Organisationsoverhead benötigt - hüpsch... - Wie verhinderst Du, dass sich alle Entwickler, die in JOSM mal was committen, einen eigenen entwicklerspezifischen API-Key haben müssen? Bereits nötiger User-Account. Häh? Ich red von JOSM-Entwicklern, die am JOSM-Code arbeiten, nicht die mit JOSM osm-Daten hochladen. JOSM ist hier nur ein Beispiel von vielen Programmen, die irgendwo OSM-Tiles benutzen, QLandkarteGT passte nur deshalb nicht, weil da ja offensichtlich praktisch nur ein Entwickler dransitzt. - wo steht der API-Key in einer OpenSource-Anwendung, wenn nicht im Quelltext-Repository? Anwendungen müssen eine Funktion behalten, über die der Anwender entweder selbst einen API-Key eingeben kann, oder ein vorhandener Useraccount kann für den Zugriff auf die API verwendet werden. Also nicht für jeden Entwickler einen Key, sondern sogar für jeden User. Wie sieht das dann jetzt mit Privacy aus? Du möchtest also jeden einzelnen User tracken können (denn nichts anderes tust du damit). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik Administration blockt QLandkarteGT
Am 16.02.2014 20:26, schrieb Dirk Sohler: Frederik Ramm schrieb: Und genau diese Leute sind auch die, die trivialerweise Deine API Key-Vorschläge umgehen. Was soll denn an dem API Key besser sein Einen API-Key muss man beantragen, ggf. mit Authentifizierung Wie soll die funktionieren? Mit Mailadresse? gut, krieg ich tausende, und irgendwer muss sich darum kümmern, darunter die fake- und wegwerfadressen rauszufiltern - das Problem haben wir schon mit dem UA-String, also verbessert es nicht. Mit Persönlichen Daten? Post-Ident? Und das auch noch weltweit? Viel Spaß. Abgesehen vom finanziellen ein enormer logistischer Aufwand. oder sonstiger Validierung, und ist mit wesentlich mehr Aufwand verbunden, als ein paar Zeichen in eine Variable zu schreiben. Eben: Der Aufwand ist immens, sobald man ernsthaft authentifizieren wollte, und da den vermutlich niemand wirklich machen will (und außerdem ja auch noch die Webseiten funktionieren sollen). Die Fragen in Kombination mit OpenSource-Software haben wir ja an anderer Stelle bereits angerissen. Welche Lösung genau schlägst Du vor, und warum ist sie besser als die (natürlich nicht perfekte) aktuelle Vorgehensweise? Betrachte dabei: - Aufwand auf Administrativer Seite von OSM (technisch und ständig personell) - Kosten auf beiden Seiten (OSM und Entwickler und Nutzer entsprechender Anwendungen) - Vereinbarkeit mit Offenheit von OSM und so weiter. Ich weiß, ich hab die Frage schon mehrfach gestellt in diesem Thread, aber bisher flamest du weiter über den ach so schlechten status-quo, ohne diese Frage zu beantworten. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik Administration blockt QLandkarteGT
Am 16.02.2014 22:59, schrieb Dirk Sohler: Henning Scholland schrieb: Was wäre denn jeweils die dahinterstehende Anwendung? Die PHP- Python- Ruby- oder Wasauchimmer-Anwendung, die dafür sorgt, dass beim Aufruf eine Seite generiert und an den Browser gesendet wird. Wenn der nun an jeden Tileaufruf ein key=12345 dran hängt hilft das genau 0,0 mehr als die aktuelle Methode. Darum wird das auch in der dahinterstehenden Anwendung erledigt. Da bekommt der Nutzer nichts von mit. Ach? Und wie kommen dann die Kacheln zum Browser des Nutzers? Bisher kriegt der Browser von der Webanwendung auf dem Server den Befehl, Kartenkacheln von einem anderen Server (nämlich dem osm-tileserver) abzurufen und anzuzeigen. Wenn der Webserver den key=12345 dranhängt, du sonst aber nichts änderst, dann bekommt also in Zukunft der Browser (!) den Befehl, Kacheln von einem anderen Server abzurufen, und dabei den key=12345 zu benutzen. Ach so... stimmt, dann weiß das also der Browser, und ach so, dann weiß ich als böser Angreifer das aber auch, weil was der Browser tut, kann ich mir angucken; und ich muss damit nichtmal einen Browser im engeren Sinne benutzen; ein HTTP-Aufruf reicht. Denken wir also mal nach: Dan kriegt also der Nutzer doch was davon mit. Gruß Peter P.S.: Ja, man kann das ohne lösen, indem tatsächlich die Webseiten-Serveranwendung direkt mit dem Tileserver redet, verschlüsselt ein Sitzungstoken aushandelt, nur dieses an den Browser sendet und in der Server-Server-Kommunikation dann aushandelt, welche Kacheln wie dabei heruntergeladen werden dürfen/sollen, aber abgesehen davon, dass das nun wirklich irre aufwändig ist, funktioniert es nicht für statische Webseiten, die zwar eine Slippy-Map anzeigen, aber eben keinen serverseitigen Code ausführen; und damit gerade für die kleinen Seiten, die durchaus gewollt erlaubt sind, zum Teil unbrauchbar. Grüße, Dirk ___ 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] Mapnik Administration blockt QLandkarteGT
Am 17.02.2014 01:23, schrieb NopMap: Hi! Um mal wieder einen konstruktiven Vorschlag ins Spiel zu bringen: Es wäre technisch möglich, einen korrekten User Agent und eine Entlastung der Server miteinander zu verbinden. Das könnte so ähnlich funktionieren wie auf meinem Server: - eine Massendownloader-Applikation identifziert sich mit ihrem User Agent - der Server leitet alle Aufrufe mit den User Agents bekannter Downloader z.B. mit einem Rewrite auf eine andere URL um, die nur vorhandene Tiles ausliefert aber kein Rendern auslöst. Das erzeugt keine nennenswerte Last - Aufrufe mit fehlenden oder unbekannten Agents oder Browser laufen normal weiter und werden wie gehabt ab einer bestimmten Anzahl von Anfragen gedrosselt Vorteile: - Server wird von unnötigen Renderanfragen entlastet - korrekter User Agent und Kooperation werden belohnt - in vorgerenderten oder häufiger angesehenen Gebieten liegen die Tiles sowieso auf dem Server rum Nachteil: - Funktioniert nicht in den höchsten Zoomleveln Weiterer Nachteil: Funktioniert nur, solange tatsächlich die Render-Queue das (einzige) Argument ist, die Usage Policy so auszulegen wie sie ausgelegt ist. Wenn es zusätzlich darum geht, den Traffic auf sinnvolle Anwendungen zu beschränken, hilft das natürlich nicht. Da kenne ich aber die Kosten oder Sponsoring-Regelungen der entsprechenden Serverstandorte nicht, ob das ausreicht. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik Administration blockt QLandkarteGT
Am 15.02.2014 12:45, schrieb Dirk Sohler: hike39 schrieb: Mit Version 1.7.6 von QLandkarteGT stellt der Entwickler die Unterstützung von OSM-Karten ein. Pfui :( Die Brgründung: . here is a quick release to end the OSM misery. I am still not convinced that transmitting the user-agent string does really help to prevent any misuse. […] Damit hat er KOMPLETT recht. Der User-Agent sagt absolut rein GAR NICHTS darüber aus, welcher Client auf den Server zugreift, da der User-Agent ohne weiteres verändert werden kann. Richtig ist vermutlich, dass es Missbrauch nicht verhindert. Unabsichtlichen Missbrauch verhindert es jedoch schon, denn einige Entwickler kommen ja erst durch die Blockade auf die Idee, dass da Server dahinterstecken, die nicht unlimitiert sind, und dass ein Missbrauch in gewissem Ausmaß zu vermeiden ist. Die OSM-Tiles sind eben gerade kein Freibier-Service für alle einschließlich Entwickler, die ihren Kunden genrne kostenlose Karten ohne Mehraufwand anbieten wollen. Was hat QLandkarte noch für Layer? Nur die OpenCycleMap - na hübsch... da ist ja die Aussage von der Webseite nur minimal übertrieben to display your GPS data on a variety of maps. Klar, das geht - aber dafür jedesmal die TMS-URL selbst raussuchen? Das kann doch auch nicht die Lösung sein; zumal die Anwendung dabei ja trotzdem blockiert bleiben dürfte für alle TMS, die entsprechende Vorgaben machen. Die Verantwortlichen bei OSM sollten sich das aussperren anhand eines simplel zu manipulierenden Strings noch mal gut überlegen, wenn sie weiterhin ernst genommen werden wollen. Niemand sagt, dass das System so bombensicher ist. Natürlich kann auch das umgangen werden, aber hier gibt es gibt nunmal zwei konfliktierende Probleme dabei: Variante 1) gar nicht blockieren: halten die Server nicht aus. Variante 2) Anwendungen blockieren, die Missbrauch betreiben - das wird gemacht. Notwendig ist dafür die Identifikation der Anwendung, mehr wird nicht gefordert; das ist dem QLandkarte-Entwickler offensichtlich zu viel. Variante 3) User identifizieren mit allem drum und dran - das ist zum Glück nicht die angewandte Variante, denn die hätte tatsächlich in Sachen Datenschutz etc. enorme Probleme. Meine Version von QLandkarteGT hat OSM noch mit drin, aber wenn OSM in Zukunft rausfliegt, dann müsste eigentlich auch die OpenCycleMap, die einzige andere vorkonfigurierte Karte, demnächst rausfliegen - denn die Usage Policy von Andy Allan [1] ist in der Hinsicht identisch: Your application must provide honest http referer and/or user-agent headers [1] http://www.thunderforest.com/terms/ Im Ergebnis dürfte rein rechtlich QLandkarte damit weitgehend ohne Karten dastehen, nur setzt Andy die Regeln für die OCM offensichtlich nicht so streng durch, und wie das mit anderen Karten ist, weiß ich nicht. Den Admins einen Vorwurf zu machen halte ich an der Stelle aber für falsch - zumindest, wenn kein gangbarer Alternativweg aufgezeigt wird, und den sehe ich bei euch nicht. Ich hoffe, jemand forkt QLandkarteGT, und baut die OSM-Unterstützung wieder ein. Am besten mit durch den User änderbarem User-Agent-String, um zukünftigen bekloppt-heiten der OSM-Admins entgegenzuwirken. Wie gesagt: Eine Lösung für die OSM-Infrastruktur wäre besser, als Admins als bekloppt darzustellen - die machen das genauso freiwillig wie du freiwillig mappst (vermute ich), und machen dabei einen ziemlich guten Job. Bekloppt wäre, wenn sie einfach alles blockieren, weil irgendwer Mist baut. Bekloppt wäre aber erst recht, wenn sie gar nichts blockierten und auf der Webseite keine Kacheln mehr ankämen, weil die Server überlastet sind. Nicht bekloppt ist, sinnvolle Regeln aufzustellen und diese auch anzuwenden. Sinnvollere Regeln zu fordern ist okay, aber nicht, ohne da auch konkrete Vorschläge zu machen. Mir fallen keine ein - dir ja offensichtlich schon; ich bin gespannt. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnik Administration blockt QLandkarteGT
Hi, klar - aber die online-Karten-Funktion ist damit faktisch tot. Gruß Peter Am 15.02.2014 16:58, schrieb Michael Reichert: Hallo, Am 15.02.2014 16:53, schrieb Peter Wendorff: Was hat QLandkarte noch für Layer? Nur die OpenCycleMap - na hübsch... da ist ja die Aussage von der Webseite nur minimal übertrieben to display your GPS data on a variety of maps. In QLandkarteGT kann man auch Karten im Garmin-Format (ohne Kopierschutz) anzeigen, z.B. die Freizeitkarte. Viele Grüße Michael ___ 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] OSM --- Wikipedia
Hallo Steffen, für eigentlich alle Karten gilt, dass die sich nicht direkt live an der Haupt-Datenbank von OSM bedienen, schon bei den Daten nicht. Bis deine Änderungen also in einer Karte X auftauchen, muss folgendes Passieren: - Du musst hochgeladen haben (okay, davon gehen wir mal aus) - Der OSM-Server muss die Änderung veröffentlicht haben, das passiert etwa einmal pro Minute sowie einmal am Tag - Wenn der Server, der die Karte X rendert, aktuell ist, versucht er, jede Minute die Änderungsdatensätze einzulesen, einige wenige machen das eben aber auch mit den täglichen. Wenn deine Änderung also in den Updates ist, und die sind hier gelesen worden, dann liegt das in der Datenbank für die Wikipedia-Karte - Die Wikipedia-Karte wird jetzt wieder von einer Render-Software erstellt. Die wiederum erkennt, wo sich in der Datenbank was geändert hat und rendert nacheinander die Betroffenen Kacheln neu. Wenn sich also grade viel ändert, kann auch das wieder etwas dauern. Letztendlich ist das bei den Karten auf osm.org immer das gleiche, aber da das eben alles unterschiedliche Server und Systeme sind, die Last unterschiedlich und so weiter, kann sich das durchaus deutlich unterscheiden. Gruß Peter Am 08.02.2014 14:26, schrieb Caronna: weis das jemand? Ich habe in OSM ne Änderung vorgenommen, OSM hat die auch nach n paar Augenblicken angezeigt. Wikipedia zeigt ja auf Wunsch auch die OSM Karte an, nur Änderungen dauern wohl mehr als etwas länger, gibt es da ein Grund für? greift WIkipedia nicht direkt aus OSM zu und lagert die Karten zwischen? Grüße aus der Eifel Steffen ___ 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] Mapnik Administration blockt QLandkarteGT
Hallo Alex, Ja, das ist bei osm.org letztlich genauso. Kacheln in detaillierteren Zoomstufen werden auf Abruf gerendert. Also: Wenn Du da hinsurfst, wird die Kachel in die Render-Queue reingeschoben, die Software erzeugt ein Bild und das wird ausgeliefert. Ja, da wird auch was gespeichert und bei erneutem Abruf direkt wieder ausgeliefert, aber vieles kommt eben durchaus direkt (Abwägung zwischen Speicherplatz und Rechenlast). Wenn Du im Browser surfst, hast Du einen begrenzten Bildschirm. Selbst bei einer HD-Auflösung von 1920x1080 und einer Karte im Vollbild sind das gerademal rund 8*4=32 Kacheln, die du gleichzeitig sehen kannst. Mit wildem verschieben des Kartenausschnitts wirds etwas mehr, aber das hält sich im Rahmen. Wenn Du jetzt aber Deutschland siehst und die Software läd z.B. bis z17 alle Kacheln, die dahinterliegen mit runter, sind das exponentiell mehr Kacheln (mit jedem zoomlevel vervierfacht sich ja die Anzahl, und das überlastet natürlich auf Dauer die Server. Software, die das tut, wird deshalb blockiert, wenn sie dadurch den Serverbetrieb stört oder zu stören droht; und auf Serverseite sind dabei auch gute von schlechten Nutzern einer Software nicht zu unterscheiden - es wäre also technisch nicht möglich, die App X nur für Funktion Y zu blockieren, Funktion Z aber zuzulassen. Die Daten sind frei, und wer eine solche Funktionalität anbieten will, soll entweder einen Renderer in die Software einbauen oder sich irgendwo einkaufen, was Serverlast für Download und Rendering angeht. Du meinst nun, die vorgerenderten Kacheln wären besser als das, was du lokal auf dem Smartphone erzeugst, und lädst die Kacheln auch noch selbst runter: Nichts spräche dagegen, wenn du dir stattdessen die Daten runterladen und die Kacheln lokal am Desktop rendern würdest, um sie dann aufs Smartphone zu ziehen, und es spricht auch nichts dagegen, wenn z.B. QLandkarte genau das unterstützen würde. Gruß Peter Am 07.02.2014 16:15, schrieb Alexander Lehner: On Fri, 7 Feb 2014, Sven Geggus wrote: hike39 ho...@hike.de wrote: Was ist Eure Meinung hierzu. Muss man demnächst damit rechnen, dass OSMAnd, OSMPad, Locus und wie die Apps alles heissen auch blockiert werden? Das Problem ist nicht die Onlinenutzung, das Problem ist der Massenhafte Kacheldownload, dennd er zerstört das Konzept des on demand rendering. Ich verwende für meine Tourenplanung (Fahrrad und Wandern) das Programm Viking. Das lädt wie ein Browser Kacheln nur on Demand runter. Sowas darf IMO nicht geblockt werden. Als Admin von tile.openstreetmap.de ist mir aber insbesondere locus auch schon negativ aufgefallen. da werden tiles nicht nur on demand geladen sondern massenhaft untergeladen. tangoGPS bzw. foxtrotGPS machen das ebenfalls so (Region auswaehlen, angeben bis zu welcher Zoomstufe man tiles runterladen will). Ich nutze diese Programme sehr gern auf meinem 'Smartphone', weil die fertig gerenderten Karten einfach schoener sind als die lokal gerenderten. Zu Hause die Kacheln runterladen und beim Mountainbiken im Wald, wo's kein UMTS gibt, hat man die Karten parat. Ist schon nett. @Sven: Worin besteht das Problem des On-Demand Rendering bei Massendownloads? Da kenne ich den Mechanismus dahinter zu wenig. Ist das bei openstreetmap.org genauso? Die Datenmenge kann es wahrscheinlich nicht sein, das sind 100-400MB, die laedt man sich einmal im Vierteljahr runter und gut ists. A. ___ 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] St.-ZickeZacke-Str.
Ich weiß nicht, ob du das mitgekriegt hast, aber Dr. steht auch im Englischen nicht nur für Drive. Zugegeben - da heißt es dann Doctor, nicht Doktor... Ob die Kirche Sankt Maria in Deutschland zu Santa Maria oder Saint Maria werden sollte, selbst in einer anderen Sprache, halte ich im übrigen für Diskussionswürdig, oder würdest Du anstatt Saint Paul’s Cathedral in London Sankt Paul's Cathedral in deiner deutschen Sprachausgabe hören wollen? Entweder doch vermutlich Sankt Pauls-Kathedrale, oder aber den Eigennamen Saint Paul’s Cathedral - aber nicht so 'nen komischen Mix weil die TTS natürlich nur teilweise übersetzen kann (und wird). Klar: Lässt sich durch Angabe unterschiedlicher name:[lang]-Werte lösen - aber wenn die nicht da sind, hilfts eben nicht. Richtig ist: Wenn du der TTS-Engine per Software mitteilen kannst, in welcher Sprache der Name geschrieben ist, dann kann sie darauf eingehen, für Webseiten auf Deutsch kann man dazu den englischen Eigennamen der Kirche in ein entsprechendes html-Tag mit lang=en kapseln. Für den Name-Tag ist das schon schwieriger, weil die Sprache nicht bekannt ist. Das geht also nur, wenn die Sprache durch die Namensgleichheit mit einem lokalisierten name-Tag identifiziert werden kann; und da dann auch die Abkürzungen unterschiedlich sind, wär ich mir bei z.B. einer südamerikanischen Kirche nicht sicher, ob der Name jetzt im Original Spanisch, Portugisisch oder Deutsch ist, lässt sich anhand des St aber nicht unbedingt ablesen - die Frage, in welcher Sprache der Text sich insgesamt bewegt, ist eben gerade bei Eigennamen KEIN Hinweis darauf, was korrekt wäre im Kontext des Namens. Gruß Peter Am 06.02.2014 18:46, schrieb Fabian Schmidt: Am 05.02.14 schrieb Peter Wendorff: Eine TTS-Software, sie in dem Sinne gut ist wie du dir das vorstellst, gibt es vermutlich nicht, was nicht an der Faulheit der Entwickler liegen dürfte. Für TTS muss ich wissen, in welcher Sprache ich mich bewege. Dann kann ich je nach Sprache auch wahlweise Dr.-Doktor oder Dr-drive expandieren. Siehe dafür http://mary.dfki.de:59125/ - Sprache bits3-hsmm de male hmm Willkommen in Dr.-Wendorff-Stadt! (aus St. wird scht) - Sprache cmu-bdl-hsmm en_US male hmm Welcome to Mulholland dr! (aus St. wird saint) Gruß, Fabian. ___ 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] St.-ZickeZacke-Str.
Und wie viel Auswertung verlangst du für jede Software? Wir sind uns doch einig, dass es nicht schwieriger für Mapper ist, die ausgeschriebene Fassung in den name-Tag zu schreiben. Für Software ist es einfach, eine vorhandene Langform bei Bedarf abzukürzen. Damit eine Software - egal welche - die Kurzform korrekt verlängern kann, muss sie 1) die Sprache kennen, das ist nur selten direkt der Fall, alternativ 1a) aus der Lage die Sprache erraten - das geht, erfordert aber eine entsprechende Heuristik sowie eine geometrische Abfrage, wo der Name auf der Welt vorkommt, 2) Kommt ein Name mit einer entsprechenden Abkürzung in einem Gebiet vor, in dem eigentlich eine andere Sprache vorherrscht, so muss der Mapper dies wissen und entgegen deiner Regel die Langform eintragen, weil jede Heuristik oder Sprachsuche sonst fehlschlagen muss. Mit (2) wird deine Regel also zu: Die Langform in name schadet nicht, aber für bestimmte Abkürzungen (im Deutschen mindestens Dr. für Doktor, St. für Sankt und Str. für Straße, wobei bei einem str am ende des Wortes auf keinen Fall der Punkt vergessen werden darf), ist es in Ordnung die Abkürzung als Abkürzung zu belassen, weil wir von Softwareentwicklern entsprechende Auswertungsintelligenz erwarten. Alleine für deine erste Näherung (und dass das auch nur eine Näherung ist, betonst du ja), braucht jede Software also entweder eine Verbindung zum Netz oder eine Datenbank, die eine Zuordnung zwischen Land und Sprache(n) zu bilden. Das erfordert aber schon, dass ich zu dem Namen das Land kenne, sonst brauch ich auch noch eine Zuordnung von Koordinatenbereichen zum Land (oder direkt zur Sprache), denn im Zweifelsfall gibt es in den OSM-Daten keine Informationen zum Land, weil diese z.B. nur eine Stadt abdecken, und auch addr:country nicht belegt ist. Noch mal: Ich weiß, dass das möglich ist; erst Recht mit Referenz auf fremde Quellen; aber wofür OSM nutzen, wenn wir hinterher wikipedia, ethnologue.com und alles mögliche andere brauchen, um die Daten nutzen zu können. Ich hab nichts dagegen, Daten einzusparen, wo sie wirklich sinnlos sind - z.B. in der aktuellen und wiederkehrenden Diskussion um Mengen-Relationen; aber hier ist es sehr wenig bis gar kein Aufwand, der viel bis sehr viel Aufwand auf anderer Seite spart und außerdem in OSM alleine eine eindeutige Situation schafft, die keinen Interpretationsspielraum braucht, erst recht keine Drittquellen. Gruß Peter Am 06.02.2014 23:20, schrieb Fabian Schmidt: Am 06.02.14 schrieb Peter Wendorff: Ich weiß nicht, ob du das mitgekriegt hast, aber Dr. steht auch im Englischen nicht nur für Drive. Zugegeben - da heißt es dann Doctor, nicht Doktor... Probier es aus: das DFKI interpretiert Welcome to Dr. Mulholland! als Doctor. Klar: Lässt sich durch Angabe unterschiedlicher name:[lang]-Werte lösen - aber wenn die nicht da sind, hilfts eben nicht. Entweder interpretiere ich die Sprache richtig, dann weiß ich, was die Abkürzung heißt. Oder ich spreche den Namen falsch aus und hab damit ein größeres Problem als mit dem Unterschied Saint - Sankt. Für den Name-Tag ist das schon schwieriger, weil die Sprache nicht bekannt ist. Das geht also nur, wenn die Sprache durch die Namensgleichheit mit einem lokalisierten name-Tag identifiziert werden kann; Einfacher ist, anderswo anhand der Sprachgrenzen rauszufinden, was denn dort gesprochen werden kann, in erster *Näherung* schau ich bei ethnologue.com o.ä., welche Hauptsprache es in dem Land gibt. wär ich mir bei z.B. einer südamerikanischen Kirche nicht sicher, ob der Name jetzt im Original Spanisch, Portugisisch oder Deutsch ist, lässt sich anhand des St aber nicht unbedingt ablesen San und São haben kein t, die Sprachgrenze in Südamerika ist sehr klar, und warum sollte der Name deutsch sein? Gruß, Fabian. ___ 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] St.-ZickeZacke-Str.
Geht es nur um zwei Fälle? Es gibt in diesem Thread im Grunde zweieinhalb Meinungen, würde ich sagen: 1) on-the-ground: ich trage ein, was auf dem Schild steht 2) on-the-ground übersetzt: ich trage ein, was auf dem Schild steht, aber in der ausgeschriebenen Fassung 2,5) on-the-ground manchmal übersetzt: ich trage ein, was auf dem Schild steht, aber in der ausgeschriebenen Fassung - außer bei str. am Ende oder Dr. und St. am Anfang. Variante (1) und (2,5) haben beide das Problem, dass eine Kurzform eben nicht ohne zusätzliches Wissen (und auch nicht mit generellen Regeln) in die Langform übersetzt werden kann. Ich beschränke mich bei den Beispielen mal auf die für (2,5) problematischen, damit ist (1) auch widerlegt. Ich weiß, dass ich hier Beispiele konstruiere, aber du behauptest ja, die Verlängerung wäre eindeutig. Die Draco-Malfoy-Straße, abgekürzt Dr.-Malfoy-Str. Der Drees-Müller-Platz, abgekürzt Dr.-Müller-Pl. Die Stefan-Effenberg-Gasse, abgekürzt. St.-Effenberg-Gasse Der Stefan-Radoslav-Platz, abgekürzt St.-Radoslav-Platz ... beliebig erweiterbar. Echte Beispiele: Stefan-Zweig-Straße, u.a. in Leipzig: http://open.mapquestapi.com/nominatim/v1/search.php?polygon=1q=Stefan-Zweig-Stra%C3%9Fe,+Leipzig Ich weiß - die Abkürzungen wären doof, aber über Sinn oder Unsinn von Schildern wollten wir uns ja nicht streiten, und denen trau ich vieles zu. Ich weiß auch, dasss Stefan oft mit S abgekürzt wird und nicht mit St, aber Fehler auf Schildern sind auch keine besonders seltene Ausnahme. Gruß Peter Am 05.02.2014 13:42, schrieb Martin Raifer: Ich möchte noch einmal die eigentlich schon in meinem Anfangsposting in den Raum gestellte These/Frage wiederholen: Wieso schreiben wir in OSM Straßennamen nicht wie ihn praktisch Jeder in Texten schreiben würde? So, wie er in Tageszeitungen vorkommt, so wie er in Enzyklopädien vorkommt, so wie er in Broschüren vorkommt, so wie er auf offiziellem Briefpapier vorkommt, so wie er am Straßenschild stehen würde wenn dort nicht aus Platzgründen abgekürzt werden müsste, …? Es ist meiner Meinung nach nicht sinnvoll Mappern irgendwelche von der Realität abweichende Regeln aufzudrücken, die weder intuitiv sind noch aus anderen Gründen gerechtfertigt. Vor allem nicht für so etwas alltägliches wie den Namen eines Dinges hinzuschreiben. KISS [2] Es geht doch praktisch fast nur um zwei Fälle: St. und Dr.. Beides sind in gewisser Weise Titel von Personen, die im echten Leben fast immer abgekürzt werden. Verwechslungen können unter Berücksichtigung des Kontextes (Name eines Ortes oder Straße) ausgeschlossen werden. (z.B.: St. steht laut Duden [1] für Sankt, Stück oder Stunde. Letztere beiden können bei Straßen oder Orten nicht vorkommen.) Liebe Grüße Martin [1] http://www.duden.de/rechtschreibung/St_ [2] https://de.wikipedia.org/wiki/KISS-Prinzip ___ 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] St.-ZickeZacke-Str.
Am 05.02.2014 18:01, schrieb Martin Raifer: Text-to-Speech Gute Text-to-Speech Software sollte aber mit diesen Abkürzungen locker umgehen können. Und wenn nicht, dann bedarf es für die jeweilige Anwendung schlicht eines Post-Processing Schritts, der die Abkürzungen entsprechend expandiert. Gute Text-to-Speech-Programme können auch nicht ohne weiteres St. zu wahlweise Santa, Santo, Sankt oder Saint expandieren, und auch dann müsste die Text-To-Speech-Engine herausfinden, dass es sich um eine Örtlichkeit handelt, sonst ist auch noch Stück unter den Möglichkeiten. Über den deutschen Sprachraum hinaus kommen noch Street, Strada und vermutlich etliche mehr dazu; dann entsprechend auch Drive für den Doktor und vieles mehr. Eine TTS-Software, sie in dem Sinne gut ist wie du dir das vorstellst, gibt es vermutlich nicht, was nicht an der Faulheit der Entwickler liegen dürfte. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] St.-ZickeZacke-Str.
Hi, ich glaube, niemand will verbieten, die Kurzform in name zu erfassen, die Frage ist aber doch, was ist das Ziel? Eine St.-Hedwig-Kirche ist besser als eine namenlose Kirche, aber eine Sankt-Hedwig-Kirche wäre eben noch besser - Gründe sind bereits mehrfach genannt in diesem Thread. Wenn jetzt jemand die St.-Hedwig-Kirche einträgt, kann das jemand anderes verbessern, wenn er mehr weiß. Wenn aber jemand die St.-Hedwig-Kirche einträgt, obwohl er den langen Namen weiß, dann ist das schade. Deshalb ist es eben sinnvoll, das auch als Regel aufzustellen: Nach Möglichkeit bitte die ausgeschriebene Fassung des Namens in name eintragen. Ich trage auch einen möglicherweise falschgeschriebenen Namen ein, wenn mir jemand aus dem Kopf sagt, wo ein bestimmtes Geschäft ist, aber den Namen nur im Wortklang kennt; wenn ich einen Verdacht habe, eben mit fixme (sonst aber auch ohne). Genauso würde ich ein St.-Sowieso eintragen, wenn ich die Langfassung eben nicht aus eigenem Wissen daraus erzeugen kann. Gruß Peter Am 04.02.2014 00:24, schrieb Falk Zscheile: Am 3. Februar 2014 21:19 schrieb Florian Schäfer florian-schae...@gmx.net: Am 03.02.2014 17:38, schrieb Martin Koppenhoefer: Allein schon daher bin ich für die ausgeschriebene Schreibweise im tag name (wg. internationaler Konsistenz/gleichem Vorgehen, s.o.), es gibt aber noch mehr Beispiele. +1 Ein weiteres Beispiel wäre da die St.-Exupéry-Straße, der ich neulich auch begegnet bin. Da ist es durch die Bekanntheit des Namensgebers noch relativ einfach, aber wie wäre es mit der St.-Denis-Straße, St.-Martin-Straße oder St.-Paul-Straße? Die gibt es teilweise entweder als Sankt-Straße oder als Saint-Straße (insbesondere im französischen Grenzbereich). Ich finde auch, dass der eindeutige (= ausgeschriebene) Name ins name-Tag gehört, alles andere in short_name u.Ä. Hier ist doch gerade das Problem: Ein Mapper, der vor dem Straßenschild steht und St.-Denis-Straße liest kann nicht sagen, ob St. ein Saint oder ein Sankt ist. Deswegen kann er nur St.-Denis-Straße eintragen. Ein anderer, der sich daran stört kann das dann klarstellen, indem er long_name richtig ausfüllt. Dieses vorgehen hat drei Vorteile: 1. Der Erfasser vor Ort (on the ground) muss sich keine weiteren Gedanken um die Bedeutung der Abkürzung (hier St.) machen, er kann dies anderen überlassen. Es ist für ihn also einfach, Daten auch in Regionen zu erfassen, die er nicht so gut kennt. 2. Die Differenzierung zwischen verschiedenen Namensvarianten in der Erfassung im Datenschema erleichtert die Arbeitsteilung: Einer kann sich um die Erfassung vor Ort kümmern, ein anderer Straßenlisten auswerten. Dass sich beide nicht in die Quere kommen Da stand aber St. Schon, aber St. heißt immer Sankt und soll ausgeschrieben werden., dafür sorgt die Erfassung in unterschiedlichen Tags: name, long_name und ggf. auch short_name. 3. Der Datenauswerter hat die Wahl, welche der beiden Infos er für sich und seine Anwendung am Besten geeignet hält. Falk ___ 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