Re: [Talk-at] Fehlerhaftes Multipolygon über Wien?
Das dürfte mit http://www.openstreetmap.org/changeset/51891607 zu tun haben (kein Multipolygon, sondern ein riesiges interkontinentales Polygon). Der zugrundeliegende Fehler in den OSM-Daten wurde mittlerweile schon behoben. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] www.data.gv.at für Verwendung in OSM zugelassen?
Zur CC-BY Thematik siehe auch https://blog.openstreetmap.org/2017/03/18/benutzung-von-cc-by-4-0-daten-in-openstreetmap/?lang=de . 2017-04-13 17:50 GMT+02:00 Robert Kaiser : > somehow_different schrieb: >> >> weitere Recherche hat folgendes zu Tage gefördert >> >> http://wiki.openstreetmap.org/wiki/Contributors#Austria >> >> Dort ist das Bundesportal data.gv.at ausdrücklich als mögliche Quelle >> unter CC BY 3.0 angegeben. Wenn ich mir die Versionshistorie dieser >> Seite anschaue, hat das User "Al."=Andreas Labres dort im Juni 2012 >> ergänzt. Bist das zufällig du? >> >> Dann ergibt sich folgende Frage: Was gilt nun hier? Ist jeglicher >> Inhalt von data.gv.at zur freien Verwendung in OSM verfügbar, oder gilt >> das nur für diejenigen Datensätze die selbst unter CC BY 3.0 dort zu >> finden sind? Für Aufklärung bin ich sehr dankbar. > > > CC-BY 3.0 und CC-BY-SA 2.0 sind ziemlich unterschiedlich zum behandeln. > CC-BY-SA in jeglicher Form ist nicht mit der OSM-Datenbank kompatibel, da > braucht man jedenfalls eine eigene Abmachung. SA würde bedingen, dass es > unter keiner anderen Lizenz als CC-BY-SA weiter verwendet werden darf, und > ODbL ist halt nicht das gleiche (obwohl im Sinn entsprechend). > Bei CC-BY gibt es Diskussionen, weil es an sich kompatibel ist, aber es > nicht 100% klar ist, ob die Nennung nur auf der Wiki-Seite genug ist, um das > BY zu erfüllen, daher ist eine solche Klarstellung grundsätzlich einzuholen. > Ob Andreas Labres die generell eingeholt hat, weiß ich nicht, aber normal > ist es gut, ein dementsprechendes Schriftstück (kann auch elektronisch sein) > zu verlinken, dann ist es klar. > > Zumindest ist das der Stand, den ich gehört habe, ich kann allerdings nicht > für die DWG sprechen, bin nur "auch ein Mapper". > > Grüße, > KaiRo > > > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] LichtKarte lebt?
Hallo Borut, das Projekt wird zwar nicht mehr offiziell von der Uni Heidelberg weiterentwickelt[1], es gibt aber trotzdem Pläne, die für die Lightmap verwendete DB neu aufzusetzen und dann wieder mit Updates zu versorgen. Leider kann man momentan noch keine konkrete Zeitangabe machen, ab wann das wieder aktiv sein wird. [1] http://www.geog.uni-heidelberg.de/gis/online_en.html Martin 2017-01-14 22:26 GMT+01:00 Borut Maricic : > In der Wochennotiz Nr. 335 [1] wurde die LichtKarte erwähnt [2]. > > Da es auf dessen Info-Seite steht, dass sie wöchentlich > aktualisiert wird, bewegte mich das etwas Licht ins Großraum > Leoben zu bringen. Leider merkte ich dann, dass die Karte > mindestens drei Wochen lang nicht aktualisiert wurde. > Anscheinend sind zwei von drei Entwickler nicht mehr mit dem > Geographischem Institut Heidelberg [3] des Uni Heidelberg > alliiert und die E-Mail Adresse des dritten, der eventuell > noch da wäre, zeigt sich als nicht mehr existierend. > > Ist jemandem bekannt, ob dieses Projekt noch lebt? > > [1] http://blog.openstreetmap.de/blog/2016/12/wochennotiz-nr-335/ > [2] http://lightmap.uni-hd.de/?lat=47.380684280633&lon=15.2764892578125&zoom=9 > [3] http://www.geog.uni-heidelberg.de/gis/mitarbeitende.html > > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] historische Namen
>> Kann ein Gipfel in natura und in OSM nicht auch namenlos sein? ^-^ >> Dann wäre evtl. ein "noname=yes" Tag [1] angebracht. > > Dieses tag sehe ich generell skeptisch, weil es in der Realität nicht das > bedeutet, was es bedeuten soll. Und zwar soll es bedeuten, dass das Feature > wirklich keinen Namen hat. Tatsächlich bedeutet es aber nur, dass der Mapper > keinen Namen in Erfahrung bringen konnte. Wirklich? Mir wäre bis jetzt noch kein solcher Fall in OSM bekannt. In jedem Fall wäre das aber meiner Meinung nach ein simpler Taggingfehler (siehe [1]), und man sollte dann den jeweiligen Mapper über die tatsächliche Bedeutung des Tags aufklären. :) > Gerade in OSM haben wir die Verantwortung, altes Namensgut zu recherchieren > und wiederzubeleben, das in herkömmlichen Karten auf Grund kleiner Maßstäbe > weggeneralisiert wurde. Diese Meinung teile ich nicht. OpenStreetMap sollte die gegenwärtige Realität so gut und vollständig wie möglich wiedergeben. Altes Namensgut ist sicherlich erhaltenswert, aber meiner Meinung nach besser in einem speziellen Tag (wohl old_name [2]), oder externem Projekt (z.B. Open Historical Map [3]) aufgehoben. Wir mappen ja auch keine anderen historischen Informationen in OSM (kleines Beispiel: aufgelassene Bahnstrecken mappen wir genau nur dann, wenn „die Bahnstrecke […] als solches noch zu erkennen [ist]“ [4]). Gruß Martin [1] http://wiki.openstreetmap.org/wiki/Key:noname [2] http://wiki.openstreetmap.org/wiki/DE:Key:name [3] http://wiki.openstreetmap.org/wiki/Open_Historical_Map [4] http://wiki.openstreetmap.org/wiki/DE:Tag:railway%3Dabandoned ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Peter Paul
Kann ein Gipfel in natura und in OSM nicht auch namenlos sein? ^-^ Dann wäre evtl. ein "noname=yes" Tag [1] angebracht. [1] http://taginfo.osm.org/keys/noname 2016-12-28 0:18 GMT+01:00 Kevin Kofler : > Martin Raifer wrote: >> was ich nicht ganz nachvollziehen kann: Nur weil ein Name vor ca 200 >> Jahren möglicherweise gebräuchlich war, sollte man diesen nicht >> zwingenderweise heute in OSM eintragen, oder? > > Wenn das der einzige Name dieses Gipfels ist, warum nicht? Sicher besser > als, daß ihn jemand einfach nach sich selbst benennt. > > Kevin Kofler > > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Peter Paul
Zu: > Da der Name Handleinsberg [historisch] belegbar ist werde ich diesen auf der > Karte eintragen. sagst du: > Finde ich gut. was ich nicht ganz nachvollziehen kann: Nur weil ein Name vor ca 200 Jahren möglicherweise gebräuchlich war, sollte man diesen nicht zwingenderweise heute in OSM eintragen, oder? Oder habe ich dich hier falsch verstanden/zitiert? Martin 2016-12-26 18:50 GMT+01:00 ScubbX : > Wie meinst du "wieso"? Ich meine das nur als Beobachtung? > > > > Am 2016-12-26 um 09:47 schrieb Martin Raifer: >> >> Wieso? Dieser historische Name scheint ja aktuell nicht mehr in >> Verwendung zu sein? >> >> >> 2016-12-24 18:55 GMT+01:00 ScubbX : >>> >>> Finde ich gut. >>> >>> Im historischen Orts- und Riednamenverzeichnis vom BEV findet sich an >>> dieser >>> Stelle gar keine Bezeichnung. >>> >>> >>> Am 2016-12-24 um 17:42 schrieb Liberaler Humanist: >>> >>> Auf einer Reproduktion des Franziszeischen Katasters findet sich etwas >>> unterhalb der Name "Handleinsberg" ( Vgl.: >>> https://www.wien.gv.at/kultur/kulturgut/plaene/franziszeisch.html - Man >>> muss >>> heranzoomen). Warum sich der Name nicht mehr in späteren Karten findet >>> ist >>> nicht ersichtlich, da der Gipfel wie am Commons-Foto ersichtlich als >>> solcher >>> klar erkennbar ist und auch auf einer topografischen Karte eine >>> entsprechende Prominenz zeigt ( >>> https://opentopomap.org/#map=17/48.27224/16.31161 ). Da der Name >>> Handleinsberg belegbar ist werde ich diesen auf der Karte eintragen. >>> >>> MfG, LH >>> >>>> Von: realadry >>>> Datum: 24.12.2016 2:20 nachm. >>>> Betreff: Re: [Talk-at] Peter Paul >>>> An: OpenStreetMap AT >>>> Cc: >>>> >>>>> Hallo, >>>>> >>>>> Ich habe ein bisschen in online verfügbaren historischen Karten >>>>> recherchiert und laut dieser Karte [1] von ca. 1941-1945, ist an dieser >>>>> Stelle ein Gipfel markiert mit der Bezeichnung "Schwaben-Ws. 482". >>>>> Ein Vergleich der Höhenlinien mit dem von Friedrich Volkmann geposteten >>>>> screenshot [2], legt nahe, dass es sie hier um den selben Gipfel >>>>> handelt. Die unterschiedliche Höhe (482 vs. 495) liegt vermutlich an >>>>> damalig ungenauen Messmethoden bzw. Veränderung der Landschaft in der >>>>> Zwischenzeit. >>>>> Die Bezeichnung "Peter Paul" hingegen findet sich in keinem Dokument, >>>>> weder historisch noch aktuell. Nur weil jemand diesen Namen auf OSM >>>>> einträgt und sich dadurch verbreitet, macht es ihn noch lange nicht zum >>>>> offiziellen oder gebräulichen Namen. >>>>> >>>>> Weiters: Das erste mal wurde der Gipfel in OSM auf "Peter Paul" benannt >>>>> am 28.Juli 2012 [3]. Das Panoramio Bild wurde aber erst danach, am >>>>> 10.August 2012, hochgeladen. Es ist also naheliegend, dass der Name des >>>>> Gipfels auf dem Bild falsch aus OSM übernommen wurde. >>>>> >>>>> Ich hoffe das sind genug Beweise um zu zeigen, dass dieser Gipfel nicht >>>>> "Peter Paul" heißt, auch wenn es jemand gerne so hätte. ;) >>>>> >>>>> >>>>> >>>>> [1]https://www.wien.gv.at/actaproweb2/benutzung/image.xhtml?id=kfGyc/iEt7fL65LzraHfwuM0+8OkdD4Jp25sfgC2ACs1 >>>>> >>>>> [2]http://www.steige.info/austausch/screenshot_pp.png >>>>> >>>>> [3]http://www.openstreetmap.org/changeset/12521352 >>>>> >>>>> Am 23.12.2016 um 18:50 schrieb grubernd: >>>>>>> >>>>>>> http://www.openstreetmap.org/note/510342 >>>>>> >>>>>> endlich wieder einmal ein Henne-Ei-Problem. >>>>>> >>>>>> Meinung: war unbenannt, also ist eine Namensgebung absolut legitim, da >>>>>> keinerlei Datenvandalismus vorliegt. mittlerweile finden sich einige >>>>>> Hinweise [1][2], dass der Berg auch von anderen so genannt wird, also >>>>>> wurde der Name angenommen. irgendwann ist es egal was einmal die Henne >>>>>> und was das Ei war. >>>>>> >>>>>> ohne Worte für Dinge können wir nicht über diese Dinge reden, denken >>>>>> und >>>>>> uns austauschen. irgendje
Re: [Talk-at] Peter Paul
Wieso? Dieser historische Name scheint ja aktuell nicht mehr in Verwendung zu sein? 2016-12-24 18:55 GMT+01:00 ScubbX : > Finde ich gut. > > Im historischen Orts- und Riednamenverzeichnis vom BEV findet sich an dieser > Stelle gar keine Bezeichnung. > > > Am 2016-12-24 um 17:42 schrieb Liberaler Humanist: > > Auf einer Reproduktion des Franziszeischen Katasters findet sich etwas > unterhalb der Name "Handleinsberg" ( Vgl.: > https://www.wien.gv.at/kultur/kulturgut/plaene/franziszeisch.html - Man muss > heranzoomen). Warum sich der Name nicht mehr in späteren Karten findet ist > nicht ersichtlich, da der Gipfel wie am Commons-Foto ersichtlich als solcher > klar erkennbar ist und auch auf einer topografischen Karte eine > entsprechende Prominenz zeigt ( > https://opentopomap.org/#map=17/48.27224/16.31161 ). Da der Name > Handleinsberg belegbar ist werde ich diesen auf der Karte eintragen. > > MfG, LH > >> Von: realadry >> Datum: 24.12.2016 2:20 nachm. >> Betreff: Re: [Talk-at] Peter Paul >> An: OpenStreetMap AT >> Cc: >> >> > Hallo, >> > >> > Ich habe ein bisschen in online verfügbaren historischen Karten >> > recherchiert und laut dieser Karte [1] von ca. 1941-1945, ist an dieser >> > Stelle ein Gipfel markiert mit der Bezeichnung "Schwaben-Ws. 482". >> > Ein Vergleich der Höhenlinien mit dem von Friedrich Volkmann geposteten >> > screenshot [2], legt nahe, dass es sie hier um den selben Gipfel >> > handelt. Die unterschiedliche Höhe (482 vs. 495) liegt vermutlich an >> > damalig ungenauen Messmethoden bzw. Veränderung der Landschaft in der >> > Zwischenzeit. >> > Die Bezeichnung "Peter Paul" hingegen findet sich in keinem Dokument, >> > weder historisch noch aktuell. Nur weil jemand diesen Namen auf OSM >> > einträgt und sich dadurch verbreitet, macht es ihn noch lange nicht zum >> > offiziellen oder gebräulichen Namen. >> > >> > Weiters: Das erste mal wurde der Gipfel in OSM auf "Peter Paul" benannt >> > am 28.Juli 2012 [3]. Das Panoramio Bild wurde aber erst danach, am >> > 10.August 2012, hochgeladen. Es ist also naheliegend, dass der Name des >> > Gipfels auf dem Bild falsch aus OSM übernommen wurde. >> > >> > Ich hoffe das sind genug Beweise um zu zeigen, dass dieser Gipfel nicht >> > "Peter Paul" heißt, auch wenn es jemand gerne so hätte. ;) >> > >> > >> > [1]https://www.wien.gv.at/actaproweb2/benutzung/image.xhtml?id=kfGyc/iEt7fL65LzraHfwuM0+8OkdD4Jp25sfgC2ACs1 >> > >> > [2]http://www.steige.info/austausch/screenshot_pp.png >> > >> > [3]http://www.openstreetmap.org/changeset/12521352 >> > >> > Am 23.12.2016 um 18:50 schrieb grubernd: >> > >> http://www.openstreetmap.org/note/510342 >> > > >> > > endlich wieder einmal ein Henne-Ei-Problem. >> > > >> > > Meinung: war unbenannt, also ist eine Namensgebung absolut legitim, da >> > > keinerlei Datenvandalismus vorliegt. mittlerweile finden sich einige >> > > Hinweise [1][2], dass der Berg auch von anderen so genannt wird, also >> > > wurde der Name angenommen. irgendwann ist es egal was einmal die Henne >> > > und was das Ei war. >> > > >> > > ohne Worte für Dinge können wir nicht über diese Dinge reden, denken >> > > und >> > > uns austauschen. irgendjemand muss den ersten Schritt tun. unbenannte >> > > Dinge nach dem Entdecker zu benennen ist ja durchaus eine grosse und >> > > anerkannte Tradition in der Kartographie. >> > > >> > > grüsse, >> > > grubernd >> > > >> > > [1] http://www.panoramio.com/photo/76813516 >> > > [2] >> > > >> > > http://www.gipfeltreffen.at/showthread.php?82202-Peter-Paul-Berg-494m-Wienerwald-(5620)/page2 > > > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at > > > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at > ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Höhenlinien
Hab ich zwar noch nie selbst gemacht, aber Garmin .img files kann man meines Wissens nach am besten mit "mkgmap" (https://wiki.openstreetmap.org/wiki/Mkgmap) erstellen. Das benötigt aber ein .osm file als Input (auch für Höhendaten, siehe Seite 34 im Manual: http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf). Dein Shapefile (evtl. vorher in WGS84 umprojezieren) musst du also nur noch in .osm umwandeln. Folgendes Tool könnte dabei behilflich sein: http://wiki.openstreetmap.org/wiki/Shp-to-osm.jar Hoffe das hilft dir weiter. Martin 2016-11-21 14:59 GMT+01:00 Friedrich Volkmann : > On 20.11.2016 13:25, aatdark wrote: >> >> du musst den parameter "-a ELEV" noch dazu schreiben. >> Dann legt er für jede Linie im shp file einen attribut eintrag >> (name:ELEV) mit dem höhen wert an. >> Sonnst verlierst du die höhen information. > > > Funktioniert. > >> in qgis solltest du shp => img convertieren können. >> Mach die shp file einfach mal in qgis auf und versuch mit >> rechtermaustate (im qgis layer view) "save as" ob es dort germin gibt. > > > Gibt es nicht. :-( > > -- > Friedrich K. Volkmann http://www.volki.at/ > Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Maps.ME User: Private Nodes auf OSM-Server
> Getan hat sich von seiten der app-entwickler aber (noch?) nichts. Also, zumindest in dem Punkt mit den falschen "name"-Tags scheint der Entwickler bereits nachgebessert haben: Wenn ich das richtig sehe, kann man seit einiger Zeit (zumindest auf Android) über die Maps.Me-Editierfunktion nur noch die "name:xx"-Tags bearbeiten. Dabei werden offenbar immer die Sprache des jeweiligen Benutzers und die Sprache des jeweiligen Landes standardmäßig angezeigt. Weitere Sprachen lassen sich über einen weiteren Klick hinzufügen. Ganz optimal ist das jetzt allerdings auch nicht, weil man im Bearbeiten-Formular jetzt den eigentlichen "name"-Tag gar nicht mehr sieht, und man so als Anfänger evtl. einen eigentlich nicht unbedingt notwendigen name:xx-Tag zu einem bereits benannten Objekt hinzufügen könnte. (Aber besser als die Situation vorher ist es allemal.) > Ich persönlich habe diese App nicht, und weiß somit nichts über deren > Funktionsweise. Ich empfehle dringend, euch mal die App zumindest zu Testzwecken zu installieren, um euch ein wenigstens grobes Bild über dessen Bearbeitungs-Funktion zu machen. Das beugt Missverständnissen vor und macht es um einiges leichter, mangelhafte Edits von Maps.Me-Benutzern zu verstehen und zu erklären wie man es besser machen könnte. > Es scheint aber, dass die App dem User nicht sagt, was mit den Daten passiert. Das kann ich nicht bestätigen. Nach der ersten Bearbeitung eines Objekts bekommt der User einen riesigen Dialog zu Gesicht, der in großen Lettern erklärt: „Melden Sie sich an, damit andere Benutzer Ihre Änderungen sehen können“. Vielleicht war das in älteren Versionen der Software noch etwas weniger eindeutig formuliert. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Import der Gewässer im Raum Sankt Michael in Obersteiermark
> Blöder weise bringe ich zurzeit kein Script zum Laufen. Ah, ich glaube in der Dokumentation war noch ein alter Prototyp verlinkt, das aktuelle Script befindet sich hier und sollte durchlaufen: https://github.com/mapbox/mapping/blob/master/JOSM/scripts/combine-highways/index.js (Habe auch schon einen Pull-Request erstellt um die Doku zu aktualisieren [1].) Du musst für deine Bedürfnisse das Script noch etwas anpassen. Folgende Schritte sollten genügen: * Zeile 58 auskommentieren, damit das Script auch noch nicht hochgeladede Elemente schluckt. * In Zeile 54 das "highway" durch den entsprechenden tag-key ersetzen und in preserve_type (Zeile 13) die erlaubten tag-values setzen. Alternativ: Die Zeile auskommentieren, dann werden überhaupt alle Ways im Layer zur Zusammenfassung herangezogen. Grüße Martin [1] https://github.com/mapbox/mapping/pull/146 ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Import der Gewässer im Raum Sankt Michael in Obersteiermark
> Ich werde es grob so machen, wie ich in dieser Nachricht > beschrieben habe: > > https://lists.openstreetmap.org/pipermail/talk-at/2015-April/007425.html > > > Jedes Gewässer ist in unzählige kleine Abschnitte zerstückelt. Ich nehme mal an, dieses "Problem" besteht weiterhin in dem Datensatz. Dabei könnte vielleicht folgendes JOSM-Plugin/Script hilfreich sein, das zwar ursprünglich dafür gemacht wurde um zerstückelte Straßenabschnitte zu vereinigen, aber sicher leicht für Gewässer umgeschrieben werden kann: Blog-Artikel: http://www.openstreetmap.org/user/Rub21/diary/37494 Anleitung und Code: https://github.com/mapbox/mapping/tree/master/JOSM/scripts/combine-highways Gruß Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Graphenintegrations-Plattform GIP als OGD
Evtl. könnte folgender Code für QGIS von Anita Graser hilfreich beim Arbeiten mit dem bei GIP verwendeten Daten-Format IDF sein: http://anitagraser.com/2015/07/23/open-source-idf-parser-for-qgis/ Gruß Martin 2015-10-13 22:20 GMT+02:00 Simon Legner : > Hallo, > > die Daten der Graphenintegrations-Plattform GIP sollen »ab Anfang 2016 > als Open Government Data (OGD) veröffentlicht« werden [1]. Es stehen > bereits Testdaten für Testdatensätze in Wien (Bereich > Westbahnhof/Gürtel) und Klagenfurt samt Dokumentation zur Verfügung > [2]. Als Lizenz wird CC BY 3.0 AT verwendet werden. > > Grüße > Simon > > [1] http://gip.gv.at/news/items/gip-als-open-government-data-ogd.html > [2] http://gip.gv.at/ogd.html > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] geoimage.at: Reached counter limit
In der Zwischenzeit kann man auch die Orthofotos von basemap.at [1]
verwenden: Diese sollte eigentlich im Grunde die selben Luftbilder wie
geoimage beinhalten (evtl. sogar mit punktuell noch
aktuelleren/schärferen Bildern aus alternativen Luftbildquellen).
Zusätzlich läuft der Dienst ohne restriktive Nutzungseinschränkungen
und die Bilder sind unter einer offenen Lizenz verfügbar (CC-BY 3.0
AT).
Viele Grüße,
Martin
[1]
http://www.basemap.at/application/index.html#{"center":[1445590,6059660],"zoom":8,"rotation":0,"layers":"000100"}
Verwendung im iD-editor: "Benutzerdefinierter Layer" mit folgender
Kachel-URL:
http://maps.wien.gv.at/basemap/bmaporthofoto30cm/normal/google3857/{z}/{y}/{x}.jpeg
2015-09-27 21:39 GMT+02:00 Simon Legner :
> Hallo,
>
> es ist wieder soweit: Der Aufruf des geoimage.at-WMS liefert »Reached
> counter limit«.
>
> _al, kannst du bitte dein E-Mail vom 2012-07-10 ausgraben und eine
> Freischaltung erreichen?
>
> Danke und Grüße
> Simon
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Details zu "Modified Nodes" herausfinden
Eigentlich nur durch Zufall. Mir wäre kein Weg bekannt, solche Edits einfach zu finden. Hmm… 2015-05-05 21:26 GMT+02:00 Florian Michaeler : > Danke für die Info, darf ich Fragen wie du das Changeset gefunden hast? > > lg > Florian > aka Miflo > > > Am 05.05.2015 um 14:51 schrieb Martin Raifer: >> >> Ein Großteil dieser Modifikationen dürfte in folgendem Changeset >> passiert sein: http://www.openstreetmap.org/changeset/30778709 >> >> 2015-05-05 11:02 GMT+02:00 Florian Michaeler : >>> >>> Hallo, >>> >>> ich war heute eher zufällig auf der OSMstats Seite ( >>> http://osmstats.neis-one.org/?item=countries&country=Austria# ), dabei >>> ist >>> mir aufgefallen, dass am 04.05. in Österreich 34539 Nodes geändert >>> wurden. >>> Da ich ja prinzipiell neugierig bin und die Anzahl so weit über den >>> "üblichen" 5000 - 6000 Änderungen pro Tag ist. >>> Stellt sich mir die Frage, wie man hierzu nähere Details herausfinden >>> könnte? >>> >>> lg >>> Florian >>> aka Miflo >>> >>> --- >>> Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus >>> Schutz ist aktiv. >>> http://www.avast.com >>> >>> >>> ___ >>> Talk-at mailing list >>> Talk-at@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-at >> >> ___ >> Talk-at mailing list >> Talk-at@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-at > > > > --- > Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus > Schutz ist aktiv. > http://www.avast.com > > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Details zu "Modified Nodes" herausfinden
Ein Großteil dieser Modifikationen dürfte in folgendem Changeset passiert sein: http://www.openstreetmap.org/changeset/30778709 2015-05-05 11:02 GMT+02:00 Florian Michaeler : > Hallo, > > ich war heute eher zufällig auf der OSMstats Seite ( > http://osmstats.neis-one.org/?item=countries&country=Austria# ), dabei ist > mir aufgefallen, dass am 04.05. in Österreich 34539 Nodes geändert wurden. > Da ich ja prinzipiell neugierig bin und die Anzahl so weit über den > "üblichen" 5000 - 6000 Änderungen pro Tag ist. > Stellt sich mir die Frage, wie man hierzu nähere Details herausfinden > könnte? > > lg > Florian > aka Miflo > > --- > Diese E-Mail ist frei von Viren und Malware, denn der avast! Antivirus > Schutz ist aktiv. > http://www.avast.com > > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] (no subject)
Falls noch jemand Schwierigkeiten mit dem File hat: Ich habe es schlussendlich hinbekommen, indem ich im GeoTIFF manuell die Lambert-Projektion (EPSG:31287) eingestellt habe. Das geht z.B. mit folgendem gdal_translate Befehl: gdal_translate -a_srs EPSG:31287 -co "TILED=YES" -co "BLOCKXSIZE=128" -co "BLOCKYSIZE=128" -co "COMPRESS=LZW" Grüße Martin 2015-03-19 10:18 GMT+01:00 Martin Raifer : > z.B. liefert "gdallocationinfo -valonly -wgs84 > 15.43753 47.07655" > bei mir eine Höhe von 366m, sie sollte aber eigentlich bei 475 liegen > (Grazer Schloßberg). Der selbe Befehl mit den Koordinaten "15.43344 > 47.07655" (eigentlich mitten in der Mur) liefert dann die gesuchten > 470m. > > Martin > > 2015-03-18 19:56 GMT+01:00 Martin Raifer : >> Version 2.8.1. Als verwendete Projektion wird bei mir folgendes >> angezeigt: "Generated CRS (+proj=lcc +lat_1=46 +lat_2=49 +lat_0=47.5 >> +lon_0=13.33 +x_0=40 +y_0=40 +datum=hermannskogel >> +units=m +no_defs)". Abweichungen stelle ich auch fest, wenn ich mit >> gdallocationinfo (v1.11.0) Höhen auf dem File abfrage. >> >> 2015-03-18 19:30 GMT+01:00 Werner Macho : >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA1 >>> >>> Hi! >>> >>> Welche QGIS Version? Ich hab hier die aktuelle Entwicklerversion und >>> entdecke keinen Versatz. >>> >>> Grüße >>> Werner >>> >>> On 03/18/2015 06:51 PM, Martin Raifer wrote: >>>>> 10x10m Geländemodell >>>> >>>> wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in >>>> QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m >>>> zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas >>>> falsch? Benutzt QGIS eine inkorrekte Projektion? >>>> >>>> Martin >>>> >>>> ___ Talk-at mailing >>>> list Talk-at@openstreetmap.org >>>> https://lists.openstreetmap.org/listinfo/talk-at >>>> >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1.4.15 (GNU/Linux) >>> >>> iEUEARECAAYFAlUJxC0ACgkQDAH1YiCxBgk8eACfeRBBtTLXLJvQxmJhWudw8GPO >>> PHwAmKPtLIfyckPFCVd9Z2fRtb6pHIY= >>> =RiLC >>> -END PGP SIGNATURE- >>> >>> ___ >>> Talk-at mailing list >>> Talk-at@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] (no subject)
z.B. liefert "gdallocationinfo -valonly -wgs84 15.43753 47.07655" bei mir eine Höhe von 366m, sie sollte aber eigentlich bei 475 liegen (Grazer Schloßberg). Der selbe Befehl mit den Koordinaten "15.43344 47.07655" (eigentlich mitten in der Mur) liefert dann die gesuchten 470m. Martin 2015-03-18 19:56 GMT+01:00 Martin Raifer : > Version 2.8.1. Als verwendete Projektion wird bei mir folgendes > angezeigt: "Generated CRS (+proj=lcc +lat_1=46 +lat_2=49 +lat_0=47.5 > +lon_0=13.33 +x_0=40 +y_0=40 +datum=hermannskogel > +units=m +no_defs)". Abweichungen stelle ich auch fest, wenn ich mit > gdallocationinfo (v1.11.0) Höhen auf dem File abfrage. > > 2015-03-18 19:30 GMT+01:00 Werner Macho : >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> Hi! >> >> Welche QGIS Version? Ich hab hier die aktuelle Entwicklerversion und >> entdecke keinen Versatz. >> >> Grüße >> Werner >> >> On 03/18/2015 06:51 PM, Martin Raifer wrote: >>>> 10x10m Geländemodell >>> >>> wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in >>> QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m >>> zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas >>> falsch? Benutzt QGIS eine inkorrekte Projektion? >>> >>> Martin >>> >>> ___ Talk-at mailing >>> list Talk-at@openstreetmap.org >>> https://lists.openstreetmap.org/listinfo/talk-at >>> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.15 (GNU/Linux) >> >> iEUEARECAAYFAlUJxC0ACgkQDAH1YiCxBgk8eACfeRBBtTLXLJvQxmJhWudw8GPO >> PHwAmKPtLIfyckPFCVd9Z2fRtb6pHIY= >> =RiLC >> -END PGP SIGNATURE- >> >> ___ >> Talk-at mailing list >> Talk-at@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] (no subject)
Version 2.8.1. Als verwendete Projektion wird bei mir folgendes angezeigt: "Generated CRS (+proj=lcc +lat_1=46 +lat_2=49 +lat_0=47.5 +lon_0=13.33 +x_0=40 +y_0=40 +datum=hermannskogel +units=m +no_defs)". Abweichungen stelle ich auch fest, wenn ich mit gdallocationinfo (v1.11.0) Höhen auf dem File abfrage. 2015-03-18 19:30 GMT+01:00 Werner Macho : > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi! > > Welche QGIS Version? Ich hab hier die aktuelle Entwicklerversion und > entdecke keinen Versatz. > > Grüße > Werner > > On 03/18/2015 06:51 PM, Martin Raifer wrote: >>> 10x10m Geländemodell >> >> wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in >> QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m >> zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas >> falsch? Benutzt QGIS eine inkorrekte Projektion? >> >> Martin >> >> ___ Talk-at mailing >> list Talk-at@openstreetmap.org >> https://lists.openstreetmap.org/listinfo/talk-at >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.15 (GNU/Linux) > > iEUEARECAAYFAlUJxC0ACgkQDAH1YiCxBgk8eACfeRBBtTLXLJvQxmJhWudw8GPO > PHwAmKPtLIfyckPFCVd9Z2fRtb6pHIY= > =RiLC > -END PGP SIGNATURE- > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] (no subject)
> 10x10m Geländemodell wow, das ist nicht schlecht! Allerdings: Wenn ich das tif-File in QGIS öffne, sehe ich einen (horizontalen) Offset von ca. 30-50m zwischen Höhenmodell und anderen Vergleichsdaten. Mache ich etwas falsch? Benutzt QGIS eine inkorrekte Projektion? Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD Vienna Tree update (?)
Nein, es wurden definitiv schon Bäume aus dem Import gelöscht, z.B. node 2043852983 [0]. Die Zahl der in der Zwischenzeit gelöschten importierten Bäume dürfte in etwa bei 700 liegen. Herausgefunden habe ich das über eine augmented diff[1] Abfrage auf die Overpass API, die den Zustand der OSM zwischen dem 3.12.2012 (also kurz nach dem Import) und heute ausgibt [2] (test-query, siehe Daten-Tab), [3] (alle Änderungen für ganz Wien). Beachtest du vielleicht nicht, dass gelöschte (visible=false) Elemente keine Tags mehr besitzen, welche also von der Vorgängerversion des selben Objekts geholt werden müssen? Ansonsten kann ich mir dein Problem nicht wirklich erklären. Martin [0] http://www.openstreetmap.org/node/2043852983/history [1] http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Augmented_Delta_between_two_dates_.28.22adiff.22.29 [2] http://overpass-turbo.eu/s/8bX [3] http://overpass-api.de/api/interpreter?data=%5Bout%3Axml%5D%5Btimeout%3A225%5D%5Badiff%3A%222012-12-03T00%3A00%3A00Z%22%5D%3B%0Aarea%283600109166%29-%3E.searchArea%3B%0A%28%0A%20%20node%5B%22natural%22%3D%22tree%22%5D%5B%22source%22%3D%22OGD%20Vienna%22%5D%0A%20%20%28area.searchArea%29%0A%20%20%2F%2F%2848.27334658037655%2C16.332828998565674%2C48.27670982090194%2C16.340076327323914%29%0A%20%20%3B%0A%29%3B%0Aout%20meta%3B 2015-03-14 22:04 GMT+01:00 Markus Mayr : > Hallo, Liste! > > Ich tüftle gerade an einem Aktualisierungsprozess für den Wiener OGD > Baumkataster. Dabei möchte ich mithilfe des Full-History-Dumps jene > Bäume erkennen, die zwar ursprünglich importiert, aber von der OSM > Community gelöscht wurden. > Bei der Aufbereitung des History-Dumps für Wien bin ich mir nicht > sicher, ob ich das richtige Ergebnis erhalten habe. > Durch den Vermerk "visible=true/false" wird in einem History-Dump > gekennzeichnet, ob das jeweilige Objekt noch sichtbar ist, oder nicht. > In meinem Ausschnitt von Wien finde ich für Bäume aber ausschließlich > "true". Weiß jemand von einer bestätigten Löschung eines Baumes in Wien > nach dem Import? Ich kann mir nicht vorstellen, dass es nie eine > Löschung gegeben hat? > > lg, Markus > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Fehlerhafte "Turning restrictions" in Wien
> Genau darum geht's mir gerade. Gibt's da irgendeine Möglichkeit false > positives auszumisten und/oder fehlerhafte Regeln zu beanstanden? Ich > hab da jetzt auf die schnell nichts gefunden. Ich würde mich entweder direkt bei User Zartbitter melden: http://www.openstreetmap.org/user/Zartbitter und/oder im Forum-Thread antworten, wo er ursprünglich die Auswertung vorgestellt hat: http://forum.openstreetmap.org/viewtopic.php?id=19834 ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Revert - Connect timed out
> Ich hätte gerne gewusst, was User Petr Slavíček geändert hat: > Er schreibt: "simplify wood Dachstein" > Ich gehe davon aus, dass er die Latschenflächen bereinigt, indem er > massenhaft Punkte gelöscht hat. Ja, das scheint wirklich so zu sein. So hat es vorher ausgesehen: http://overpass-turbo.eu/s/3H1 Zugegebenermaßen sind die Flächen wirklich schon sehr detailiert gemappt, und hier und da scheint auch mal ein größerer Stein als Latsche gurchgegangen zu sein (https://www.openstreetmap.org/way/139254114). Außerdem werden Latschen doch als scrub und nicht als wood getaggt, nicht? Natürlich wäre das trotzdem für kein Grund dafür die Polygone so extrem zu vereinfachen, u.A. mit dem Ergebniss von sich selbst überschneidenden Geometrien. :( > Ich hätte das nun wieder gerne zurückgesetzt. > Versucht habe ich es mit JOSM 7000, und dem Tool Änderungssatz umkehren Bei mir ist ein revert durchgegangen (nach sehr langer Bearbeitungszeit; mit JOSM 7182) - oder meinst du, dass bei dir das Hochladen nicht funktioniert hat? Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] JOSM: Gebäude "ausschalten"
Ich glaube die Filter Funktion ist das richtige für dich: https://josm.openstreetmap.de/wiki/Help/Dialog/Filter Grüße Martin 2014-05-16 9:43 GMT+02:00 Christian Aigner : > Am 16.05.2014 09:29, schrieb Christian Aigner: >> Ich möchte im Moment nur Buslinien editieren. Dazu müssen nur die >> Straßen, Haltestellen und Plattformen sichtbar sein. >> >> Wie kann ich alles andere ausschalten (unsichtbar machen)? >> >> LG, >> Christian > > > Ich hab den MapPaint-Style geändert, aber die Gebäude werden immer noch > grau angezeigt. Kann man das auch noch ausschalten? > > LG, > Christian > > > ___ > Talk-at mailing list > Talk-at@openstreetmap.org > https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] OGD Shapefile -> GPX via JOSM und osmconvert
Mit QGIS (o.Ä.) die Polygone in Punkte umwandeln (Vektor->Geometrie-Werkzeuge->Polygonschwerpunkt), dann erst in JOSM öffnen, … https://gist.github.com/tyrasd/137d1f4f93fbf0330197 (Konvertiert habe ich das mittels osmtogeojson [1] und togpx [2]: `osmtogeojson naturdenkmale.osm | togpx > naturdenkmale.gpx`, weil JOSM anscheinend nur tracks und keine waypoints exportiert‽ – gpsbabel u.Ä. sollten aber auch klappen.) Martin [1] https://www.npmjs.org/package/osmtogeojson [2] https://www.npmjs.org/package/togpx ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vorarlberg: Radwege vom Land erhalten!
2014-04-24 11:56 GMT+02:00 Andreas Labres :
> Ich weiß ja nicht, wie ihr das im Detail macht, aber irgendwie klingt mir das
> nicht nach "Import", sondern nach viel Handarbeit mit halt einer speziellen
> Vorlage.
Würde ich auch so sehen, aber das heißt ja nicht, dass man solche
Mapping-Projekte nicht trotzdem vorher gut planen, koordinieren,
dokumentieren, usw. sollte. ;)
> On 23.04.14 22:15, Michael Maier wrote:
> Bei Beginn des Projektes waren nur 4 Routen-Relationen in der OSM vorhanden
Wie kommst du auf 4 Routen in OSM? Ich zähle aktuell 14 Stück:
http://overpass-turbo.eu/s/39J ;)
Habt ihr euch schon überlegt, was ihr macht, wenn sich die Daten vom
VoGIS nicht mit den bereits bestehenden OSM-Routen decken? Z.B.
Routenverlauf des Bodensee-Radwegs ganz östlich von Bregenz, konkrete
Schreibschweisen von Namen ("Bodensee Radroute" oder
"Bodenseeradweg")…
Ich bin mir nicht sicher, ob die Radweg-Nummern auch in der Praxis
verwendet werden. Die Beschilderungen scheinen zumindest ohne Nummern
auszukommen, und google spuckt bei der Suche nach den entsprechenden
R-Nummern auch nichts aus. Hm… Besser nur als ref:vogis=Rxxx taggen?
Grüße
Martin
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Über Imports
Als Hintergrund wie ich dazu gekommen bin den Artikel zu verfassen: Möglicher Gebäude-Import in Südtirol: https://lists.openstreetmap.org/pipermail/talk-it-southtyrol/2014-April/000129.html ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Ja, es gibt verschiedene Sichtweisen, verschiedene Methoden zu mappen, beide haben ihre Vor- und Nachteile. Was aber nicht OK ist, ist einfach die eine Variante in eine Andere umzumappen, ohne Mehrwert für OSM dabei zu erzeugen. Frederik Ramm hat das vor kurzem so formuliert: What is *not* ok is one person "cleaning up" after the other without actually adding any other improvement. https://lists.openstreetmap.org/pipermail/talk/2014-February/069053.html Ich bitte dich deshalb darum, dein "Aufräumen" in diesem Sinne wieder rückgängig zu machen. Eventuell könnte ich dabei behilflich sein, falls du das noch nie gemacht haben solltest. Schöne Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 27.02.2014, 20:39 Uhr, schrieb Kevin Kofler : Martin Raifer wrote: [in OSM werden Fahrbahnen gemappt] Das tun wir eben nicht, sonst würde in der Stadt jede einzelne Zweirichtungsstraße doppelt gemappt sein […], das ist aber nicht der Fall. Selbst die Überlandstraßen (sind meistens nicht doppelt gemappt. Und meiner Meinung nach ist das auch gut so! Getrenntes Mapping der Richtungsfahrbahnen ist wirklich nur dort sinnvoll, wo es eine bauliche Trennung gibt, z.B. bei Autobahnen. Genau dasselbe gilt auch für die Gehsteige. Ich glaube du verwechselst schlicht den Begriff Fahrbahn mit Fahrspur/Fahrstreifen [1]. Mehrere Fahrbahnen sind per Definition baulich voneinander getrennt! ;) (z.B. Lerchenfelder Straße) So weit ich es am Luftbild beurteilen kann, sieht diese Straße nach einer gewöhnlichen Straße mit nur einer Fahrbahn [1] aus. Außer im Bereich der Kreuzung zur Auerspergstraße [2], aber dort sind in OSM eh zwei Fahrbahnen gemappt. Grüße Martin [1] http://de.wikipedia.org/wiki/Straßenquerschnitt#Fahrbahn [2] http://www.openstreetmap.org/#map=19/48.20681/16.35520 ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 27.02.2014, 20:14 Uhr, schrieb Kevin Kofler : Unlängst hat Wiens Fußgängerbeauftragte Petra Jens in einer TV-Diskussion ausdrücklich betont, daß die Straße eben NICHT nur die Fahrbahn ist (das ist eine sehr autozentrische Sicht), sondern der Gehsteig genauso zur Straße gehört. Wenn wir die Gehsteige aber jetzt alle extra mappen, dann pflegen wir genau diesen autozentrischen "Straße=Fahrbahn" Irrtum. Das stimmt zwar, aber streng genommen mappen wir in OSM als beispielsweise highway=teriary keine "Straße", sondern eben genau eine Fahrbahn! Das wird deutlich, wenn man bedenkt, wo wir die highway-Wege in die einzelnen Richtungen aufsplitten: Immer genau dort, wo eine Straße mehrere (Richtungs-)Fahrbahnen hat. Und genau hier führt dein Argument ins Leere: Denn der Gehsteig ist eben _kein_ Bestandteil der Fahrbahn, sondern von dieser getrennt. Trotzdem möchtest du in OSM einen Gehsteig dann per Zusatz-Tags quasi als Anhängsel der Fahrbahn betrachten. Komisch. Martinn ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 27.02.2014, 19:36 Uhr, schrieb Stefan Tauner : http://666kb.com/i/cm7jwktlnv7yn2lhb.jpg (3),(4) Fußweg quer über geparkte Autos? Bei 3 und 4 werden Anti-Gehsteig-Mapper kein Problem sehen (und ich auch nicht: Überquerung der Straße ist überall möglich und gleichzeitig dient die Straße ja dazu den Gehsteig abzubilden). Eine Querung ist zwar möglich, aber nur für Leute ohne Rollstuhl, Kinderwagen, o.Ä. – das müsste entsprechend getaggt werden. Außerdem: wäre das Queren hier überhaupt erlaubt? Da ist ja nur 15m weiter ein Ampel-geregelter Zebrastreifen… Wenn nein, dann müsste dort sogar noch eine Abbiegebeschränkung (no_straight_on) hin. Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 27.02.2014, 14:47 Uhr, schrieb Kevin Kofler : "aufzuräumen": http://www.openstreetmap.org/changeset/20809099 Ich empfinde die Situation jetzt deutlich schlechter als vorher. Ich habe mir jetzt schnell die Situation am Urban-Loritz-Platz angeschaut, und nach deinem "Aufräumen" finde ich auf die Schnelle folgende Probleme, die vorher nicht vorhanden waren: http://666kb.com/i/cm7jwktlnv7yn2lhb.jpg (1) Fußweg endet im Vakuum? (2) Fußweg endet am Tram-Gleis? (3),(4) Fußweg quer über geparkte Autos? (5),(6) Keine Verbindungen vom Platz zum Geh-/Radweg auf der gegenüberliegenden Straßenseite? Dass vorher die footway=sidewalk bzw. footway=crossing Attribute gefehlt haben stimmt, aber das hätte man doch einfach korrigieren können, ohne blinde Löschwut. :( Dein Vorgehen würde auf Gebäude umgelegt in etwa bedeuten, alle jene Häuser zu löschen, wo noch keine Adressen gesetzt sind. Hast du dich überhaupt zumindest vorher mit dem Mapper, der die Gehsteige gemappt hat unterhalten (User Railjet – er scheint ziemlich erfahren zu sein)? Entschuldige wenn ich das so direkt sage, aber dein Verhalten erscheint mir ziemlich respektlos. Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 26.02.2014, 11:45 Uhr, schrieb Michael Maier: Genau deswegen halte ich sidewalk=* für komplizierte Situation für furchtbar verrückt, Beispiel (Linkskurve): […] Was bei deinem Beispiel noch gar nicht vorkommt, aber die praktische Umsetzung des Gehsteig-als-Tags-Mappings noch einmal deutlich verkompliziert, ist, dass an jeder Stelle wo sich die Eingenschaft auch nur eines der beteiligten Verkehrswege ändert (z.B. Breite oder Beschaffenheit des Gehsteigs, Anzahl der Spuren der Straße) das Gesamtgebilde aufgetrennt werden muss. Nehmen wir als Beispiel folgendes Stück der Leonhardstraße in Graz: http://www.openstreetmap.org/way/110460282 (ca. 250m) - Der südliche Gehsteig hat in etwa auf Höhe der Metzgerei eine kurze Stiege (mit Rampe, aber viel zu Steil für Rollstuhlfahrer), danach folgt ein kleiner Platz mit mehreren Hindernissen (Mistkübel, Fahrradparkplatz), dann folgt ein Stück mit (wegen Parkbuchten und Gastgärten) variierender (ca. 5-6 mal) Breite. Ähnliche Situation am nördlichen Gehsteig. Diese Straße müsste praktisch in 15-20 Stücke zerteilt werden, um alle sidewalk:right/left:* Eigenschaften korrekt zu platzieren. Viel Spaß damit, und beim weiteren Bearbeiten der Straße oder der Gehsteige. Bei getrenntem Gehsteig-als-Way-Mapping ist immer nur derjenige Verkehrsweg genau dort aufgetrennt, wo sich jeweils etwas ändert. Easy. :) Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 25.02.2014, 12:37 Uhr, schrieb realadry : Das mapping soll für einen Computer intuitiv bzw. lesbar sein, nicht für einen Menschen. :D Du machst Witze, oder? ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Am 25.02.2014, 11:33 Uhr, schrieb Friedrich Volkmann : Mit den vielen komplexen Relationen haben wir uns längst von KISS verabschiedet. Das finde ich nicht. Relationen werden aktuell eigentlich nur dort verwendet, wo es schlicht keine einfachere Alternative gibt (wie sollte man sonst Polygone mit Löchern, Abbiegebeschränkungen oder ÖPNV-Routen implementieren?). Außerdem kann im iD-Editor mit all diesen Relationen von puren Anfängern ganz ohne Einlesezeit gearbeitet werden: Bei einfachen Bearbeitungen (z.B. Way Splitten) bekommt der User gar nicht mit, dass eine Relation im Spiel ist, komplexere Bearbeitungen wie ein Gebäude mit Innenhof erstellen funktioniert kinderleicht über das "+" Werkzeug. Editieren ist heute nichts mehr, was ohne Beschäftigung mit der Dokumentation geht. Es geht doch eher darum, wieviel Einarbeitung notwendig sein soll. Ich finde: So wenig wie möglich. Meiner Meinung nach sollte das Walkthrough (z.B. beim ersten Start) von iD ausreichen. 2. Man erhält akkuratere Geometrien. Sehr viele Kreuzungen lassen sich mit den jeweiligen Fußgängerkreuzungsmöglichkeiten gar nicht anders erfassen. Da kommst du aber vom Hundersten ins Tausendste, denn mit der selben Begründung könntest du auch die Fahrspuren einzeln mappen, die Radwege sowieso, samt Abbiegerelationen zu den Fahrspuren, und dann hast du noch das Problem, wo du die Ampeln setzt. Und hast du nicht etwas von KISS geschrieben? OK, du hast vielleicht Recht. Man sollte nicht von Spezialfällen auf die Allgemeinheit schließen (kann man bei einer Kreuzung mit Fußgänger-Mittelinsel von einem Spezialfall sprechen? Hmmm…). Das schwächt mein Argument etwas ab, trotzdem bleibt der Wunsch nach einer in sich konsistenten Lösung. 3. Attribute der Straße treffen oft nicht auf die Gehsteige zu und umgekehrt (z.b. Oberfläche, Breite, Hindernisse, Stufen, etc.). Man _könnte_ vieles davon auch über komplexe Attribute abbilden, aberdas erfordert wieder mehr Einarbeitung -> siehe Punkt 1. Wenn man sich nicht einarbeiten will, kann man diese Attribute für den Gehsteig auch ganz weglassen. Ob er 2m oder 3m breit ist, interessiert sowieso niemanden. Wie bereits oben erwähnt geht es ja darum wie lange man sich einarbeiten muss. Wenn Gehsteige separat gemappt werden kann das was man bereits für die Attributierung von normalen Straßen gelernt hat direkt ohne Neu-Lernen auf die Gehsteige anwenden. Im anderen Fall muss man sich "doppelt" so lange einarbeiten. Man sollte auch bedenken, dass ein Anfänger ja gar nicht wissen kann, dass Gehsteige unter Umständen anders zu behandeln sind als andere Gehwege. 4. Wenn zwischen Straße und Gehsteig sich trennende Elemente (z.B. Bäume einer Allee, kleine Mauer, Randsteine, etc.) befinden können diese auch nicht topologisch korrekt platziert werden ohne separatem Gehsteig. Wenn Bäume oder eine Mauer dazwischen stehen, ist das eine bauliche Trennung und dann ist separates Mapping Konvention. Ist der Bordstein denn keine bauliche Trennung? Oder anders gefragt: Wäre ein Bordstein zwischen den beiden Richtungsfahrbahnen, würde man diese doch auch getrennt mappen, oder? Außerdem findet man in Städten sehr häufig Parkplätze zwischen Straße und Gehsteig, ist das "bauliche" Trennung genug? Für ein gescheites Rollstuhlfahrer-Routing […] Das Rollstuhlfahrerrouting geistert durch die Diskussionen wie der Fuchsbandwurm und die Spinne in der Yuccapalme, die noch nie ein Mensch real gesehen hat. Ich kann dir versichern, dass es aktuell mehrere Projekte gibt, die sich intensiv mit Rohlstuhl-Routing in Zusammenhang mit OSM beschäftigen. Michi (species) kann dir dazu sicher mehr erzählen. Wie du weißt zeichnet sich OSM dadurch aus, dass wir der einzige "Datenlieferant" sind, bei dem Fußgänger wie Rollstuhlfahrer nicht gegenüber Autofahrern diskriminiert werden. Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Mappen von Gehsteigen
Ich war anfangs auch kein Freund des Gehsteig-Mappings. Mittlerweile finde ich aber, dass das sehr wohl sinnvoll sein kann, und zwar aus folgenden Gründen: 1. Es ist einfach intuitiver jeden getrennten Verkehrsweg extra zu mappen: Es benötigt keine Einlese-Arbeit im Wiki (seinen wir mal ehrlich, kein Mensch liest sich das Wiki durch bevor man anfängt zu mappen). KISS [1] 2. Man erhält akkuratere Geometrien. Sehr viele Kreuzungen lassen sich mit den jeweiligen Fußgängerkreuzungsmöglichkeiten gar nicht anders erfassen. 3. Attribute der Straße treffen oft nicht auf die Gehsteige zu und umgekehrt (z.b. Oberfläche, Breite, Hindernisse, Stufen, etc.). Man _könnte_ vieles davon auch über komplexe Attribute abbilden, aber das erfordert wieder mehr Einarbeitung -> siehe Punkt 1. 4. Wenn zwischen Straße und Gehsteig sich trennende Elemente (z.B. Bäume einer Allee, kleine Mauer, Randsteine, etc.) befinden können diese auch nicht topologisch korrekt platziert werden ohne separatem Gehsteig. Für ein gescheites Rollstuhlfahrer-Routing benötigt man relativ detaillierte Daten über die Geometrie und Beschaffenheit der Gehsteige. Ich sehe dafür keine praktikable Alternative zum separaten Gehsteig-Mapping. Natürlich ist in vielen Fällen das Mappen als Attribut der Straße im ersten Moment erstmal "gut genug". Trotzdem finde ich nicht, dass man Leuten, die die Qualität der OSM-Daten verbessern wollen, das verbieten sollte. Ich sehe auch nicht, was denn gegen das Gehsteig-Mapping spricht? Außer, dass man einen etwas längeren Verkehrswege-Graphen zu verwalten hat – aber das scheint bei allen anderen Arten von Micromapping (3D-Gebäude, einzelne Spielzeuge in Spielplätzen, …) ja kein Problem zu sein. Schöne Grüße Martin [1] http://de.wikipedia.org/wiki/KISS-Prinzip ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Adressen mit nur halboffiziellen Straßebezeichnungen
Am 12.02.2014, 19:09 Uhr, schrieb Christian : Hat irgendjemand einen Vorschlag, wie man beide Varianten auffindbar taggen kann? Jeweils zwei Address-Nodes setzen (1x addr:street und 1x addr:place)? So ähnlich wie für Häuser, die an mehreren Straßen Hausnummern haben… Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Salzburger Altstadt
Servus! Hat der Browserintegrierte Editor (iD) derzeit Probleme mit der Darstellung? Ja, das lag an einer ÖPNV-Relation, die fälschlicherweise sich selbst (rekursiv) als Mitglied hatte. Das führt wegen eines Bugs von iD zu einer Endlosschleife. Ich habe die Bus-Route bereits korrigiert und den Fehler bei iD gemeldet [1]; das Editieren mit iD in Salzburg sollte also jetzt wieder funktionieren. Liebe Grüße Martin [1] https://github.com/systemed/iD/issues/2072 ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Haltestellendaten Steiermark
Hallo Andreas,
ich habe deine Mail [1] auf der imports-Liste (betereffend des is_in-Tags)
gesehen, und gedacht ich antworte erstmal nur hier, weil einige Sachen
doch ziemlich lokal sind.
I think the is_in is necessary for the following reason: We only have
boundaries down to the level of communities ("Gemeinden") in OSM, but
the bus stops are often labelled with the name of villages, sub-parts of
the communities, which sometimes don't even have exact boundaries.
Here are some examples, where I think it would be impossible to derive
the "complete name" (town and name of stop) without the is_in-tag:
http://www.openstreetmap.org/node/1487738866: Although this stop is
geographically still in the city of Graz, this stop is in Fölling for
everything related to public transport (most important for tariffs, but
also for a unique name ...).
http://www.openstreetmap.org/node/1801654560: This stop is closer to the
node called "Fölling" in OSM than the above stop, however it is in
"Prellerberg" (there is not even a place in OSM with that name).
Also, das Beispiel mit Fölling ist nicht ganz gut gewählt, weil es neben
dem kleinen Fölling in Weinitzen auch noch das etwas größere Fölling bei
Mariatrost gibt (welches aber bis gerade eben in OSM gefehlt hat). Auf
dieses 2. Fölling beziehen sich aber die Verbundlinie-Daten (siehe:
"Fölling bei Graz").
http://www.openstreetmap.org/node/1735061993: This stop is named after
the community it is in: Rettenegg, BUT:
http://www.openstreetmap.org/node/1735061989: This is the platform for
the other direction, which of course has the same name, but is
geographically already beyond the border in the next community (Sankt
Jakob im Walde).
Die Rohdaten enthalten hier nur "Rettenegg (Stmk)". Das vollständige is_in
hast du dir daraus zusammengebastelt, oder? Hier ist das Problem, das ich
darin sehe: Es gibt dort nur eine Ortschaft namens "Rettenegg"
(http://www.openstreetmap.org/node/240078095, zugleich Gemeinde
Rettenegg). So etwas wie "Rettenegg,Sankt Jakob im Walde,…" gibt es nicht,
die is_in-Information der 2. Haltestelle ist also schlicht falsch.
Ähnliches z.B. hier: http://www.openstreetmap.org/node/728306183: In
Kainbach gibt es kein "Graz" mehr.
One could of course state, that the bus stops should be renamed, but
since that is not within our scope, I still think, the is_in-tag is
required for identificaiton of the bus stops.
Ich bin nicht überzeugt, dass is_in das richtige Tag hierfür ist. Denn:
is_in gibt die geographische Zugehörigkeit eines Objekts an (“The is_in
tag is used to index where a place or feature is.”). Zum Beispiel, um
sicher anzugeben, dass ein Berggipfel in Land A ist, ohne dass die Grenze
zwischen Land A und Land B genauer bekannt ist.
Ich denke, dass das was bei diesem Import als "Ort" angegeben ist, nicht
viel mit "echten" Orten gemein hat. (Du sagst ja selbst, dass diese "Orte"
nur im ÖPNV-Kontext relevant sind). Es sind wohl eher einfach
Tarifzonen-Unterteilungen. Wenn ich also beispielsweise von einer
Haltestelle abfahre, die als "Ort" Fölling hat, kann ich mit einem
1-Zonen-Ticket sowohl nach Graz (Zone 101) als auch in die Zone 203
fahren. Das erklärt auch, wieso einige Haltestellen in der Ragnitz noch
als "Ort" Graz haben.
Dafür das is_in-Tag zu missbrauchen, finde ich nicht gut. Ich würde eher
vorschlagen, ein eigenes Tag dafür zu finden (vielleicht gibt es ja schon
etwas). Wenn man möchte, könnte man dann auch noch für den vollständigen
Namen der Haltestellen ein alt_name=" " hinzufügen.
Liebe Grüße
Martin
[1]
https://lists.openstreetmap.org/pipermail/imports/2013-December/002455.html
___
Talk-at mailing list
Talk-at@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Haltestellendaten Steiermark
Am 28.11.2013, 09:12 Uhr, schrieb Stefan Tiran : Die Haltestellennummer ist auch auf den Aushängefahrplänen (rechts oben) ersichtlich und daher sehrwohl erkenn- und überprüfbar. Hm. In Graz jedenfalls nicht: http://666kb.com/i/cjn9l2o2uvc5i0eih.jpg Und wenn, dann ist wahrscheinlich auch nur die Haltestellen-Nummer und nicht die z.Z. als ref vorgesehene IFOPT-Nummer angegeben, oder? Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Haltestellendaten Steiermark
Am 19.11.2013, 20:29 Uhr, schrieb Manfred Brandl : Bevorrechtigter-IV (Busse) ist möglicherweise zu oft gesetzt. Kann es sein, dass auch andere Verkehrsmittel zu oft gesetzt sind? Beispielsweise hat die Haltestelle Styriastraße (IFOPT: at:46:4765:0:murp) das Attribut Eisenbahn=Ja. Soweit ich mich erinnere habe ich nur Haltestellenpositionen exportiert bei denen wirklich etwas vorbeifahren sollte. Das bedeutet aber nicht immer zwingend, dass die Haltestellenposition auch als solche erkennbar ist. Manche Haltestellenpositionen wird auch nur sehr selten ( einmal jährlich ) bedient. Spontan fällt mir auf, dass Haltestellen, die vor Kurzem verlegt wurden, doppelt enthalten sind. Siehe z.B. die Tramhaltestelle Esperantoplatz/Arbeiterkammer. Schöne Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Haltestellendaten Steiermark
Servus. Klingt super! Ich habe zufälligerweise vor ein paar Wochen einen ähnlichen Haltestellen-Datensatz importiert: [0], vielleicht kannst du dich etwas daran orientieren. Aber leg doch bitte erst mal eine Wiki-Seite für den Import an (siehe [1],[2]). Hier in der E-Mail ist das Ganze leider sehr unübersichtlich. Die nicht mehr bestehenden Haltestellen herauszufiltern halte ich für unbedingt notwendig. Dafür müssen wir uns irgend eine Lösung einfallen lassen. Was das Tagging angeht würde ich folgendes vorschlagen (wobei ich anmerken muss, aus Zeitgründen erstmal nur die bereits konvertierten Daten, also "haltestellen-mitosmtags.osm" angeschaut zu haben): * "no"-Werte (z.B. ferry=no, subway=no) weglassen. * Es gibt Punkte, die für alle Transportmittel den wert "no" haben. Diese sollte man wahrscheinlich herausfiltern. * is_in: wieso? Außerdem scheinen die Werte teilweise auch nicht ganz richtig zu sein. * loc_name / loc_ref: Mir erschließt sich nicht der Nutzen dahinter nicht (siehe auch meine Anmerkungen zu ref weiter unten). * ref:RBL: Dito. Außerdem haben alle Haltestellen eine solche ID, also auch solche, die gar keine RBL-Anzeige haben. Interessant wäre lediglich diese Information (~display_panel~ = yes/no), irgendwelche Unternehmens-interne IDs interessieren keine Sau. * ref: Würde ich nicht importieren. Solche Daten sind später sehr schwer zu erhalten, außerdem sind die Daten praktisch nutzlos (und wenn wirklich jemand diese Unternehmens-internen IDs benötigen sollte, kann er auch auf die Originaldaten zugreifen, dafür müssen sie nicht in OSM sein). In der Vergangenheit wurden solche IDs oft einfach ohne zu überlegen importiert, und stellen bis Heute einen nicht zu vernachlässigenden Ballast dar. Es ist schon so weit, dass diese Daten mühsam wieder nachträglich entfernt werden: [3],[4] (siehe außerdem dazu noch die Diskussion auf talk-de über die IFOPT-IDs [5]). * ref:stop_area: Würde ich aus den selben Gründen nicht importieren. Zur Identifikation von zusammengehörigen Haltestellen dient ja bereits deren identischer Name. Was den Import-Ablauf angeht würde ich sagen, dass ein zweigeteilter gebufferter Ansatz, so wie du ihn beschreibst, gut funktionieren könnte. Es wird aber trotzdem recht viel manuelles Intervenieren notwendig sein. Evtl. könnte man sich mal das Import-Tool OSMLY [6] ansehen. Schöne Grüße Martin PS: Nicht vergessen diesen Import auch noch auf impo...@openstreetmap.org anzukündigen. [0] https://wiki.openstreetmap.org/wiki/AltoAdige_-_Südtirol/SASA_Bus_Stops_Import [1] https://wiki.openstreetmap.org/wiki/Import/Guidelines#Step_3_-_Documentation [2] https://wiki.openstreetmap.org/wiki/Import/Plan_Outline [3] Discarding IDs imported with US-Tiger data: http://gis.19327.n5.nabble.com/Discardable-TIGER-tags-td5718873.html [4] Discarding IDs imported with KSJ2 data: https://lists.openstreetmap.org/pipermail/imports/2013-September/002133.html [5] https://lists.openstreetmap.org/pipermail/talk-de/2013-July/103225.html [6] https://wiki.openstreetmap.org/wiki/OSMLY Am 19.11.2013, 07:45 Uhr, schrieb Andreas Uller : Hallo! Vom Verkehrsverbund Steiermark haben wir Daten zu allen ÖV-Haltestellen in der Steiermark zur Verwendung in der OSM erhalten. Die Daten sind derzeit hier gespeichert: https://github.com/species/Open-Data-Verbundlinie.at Die Lagegenauigkeit ist auf jeden Fall brauchbar, mir sind nur wenige Haltestellen aufgefallen, deren Position nicht genau passt (und auch da sind's nur ein paar Meter daneben). Größter Nachteil aus meiner Sicht: Es sind offenbar auch ehemalige Haltestellen drinnen, die nicht mehr bedient werden (und vor Ort auch nicht mehr als Haltestellen ersichtlich sind). Auch wenn da vielleicht noch eine Konzession existiert, dienen solche nicht-sichtbaren Haltestellen meiner Meinung nach nicht der Orientierung und sollten dann auch nicht in OSM dargestellt werden. Vielleicht hat der Verkehrsverbund da aber noch eine Liste, welche Haltestellen tatsächlich bedient werden und welche nicht. Die Attribute der Haltestellen sind natürlich nicht OSM-konform, in Folge mal meine Analyse der vorhandenen Daten und wie wir das in OSM-Tags umwandeln könnten, bitte um Kommentare! Für den oft bereits vorhandenen Tag ref für die Bezeichnung der Bus- bzw. Bahnsteige (A, B, C, ..., 1, 2, 3, ...) würde ich eine Umbenennung auf loc_ref vorschlagen. Aushangfahrplan: Ist außer bei einer Haltestelle immer Nein -> löschen Bereich Nr.: Hier sind bei größeren Haltestellen mehrere Haltepositionen die in unmittelbarer Nähe liegen zusammengefasst (z.B. Jakominiplatz: 3/6 Richtung Dietrichsteinplatz und 1/7 Richtung Kaiser-Josef-Platz sind ein Bereich, Richtung Hauptplatz ist aber ein eigener Bereich) -> mMn für OSM nicht relevant -> löschen Bevorrechtigter IV (Busse): Ob Busse diese Haltestelle anfahren -> bus=yes/no Buchsatz: Ist außer bei einer Haltestelle immer Ne
Re: [Talk-at] ID_wo_ist_geoimage
Zur Info: Ab jetzt sollte geoimage.at in Österreich wieder als Layer im iD-Editor zur Auswahl stehen. Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Basemap.at
>> http://maps.wien.gv.at/basemap/geolandbasemap/normal/google3857/%1/%3/%2.jpeg > > Wenn ich auf "Get Services" klicke, kommt eine Messagebox: "Download failed: > Not Found" Das kannst du ignorieren, weil das schon die fertige URL ist (dann ist das "get services" nicht notwendig). Bei mir funktionierts jedenfalls: http://666kb.com/i/cipdxlm73u3gmolc3.jpg ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Basemap.at
Welche URL gibt man dann in Merkaartor ein? Versuchs mit Folgendem: http://maps.wien.gv.at/basemap/geolandbasemap/normal/google3857/%1/%3/%2.jpeg Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] batch update auf tags?
Am 16.10.2013, 14:21 Uhr, schrieb Rainer Fügenstein : wie kann man am besten ein batch update auf bestehende tags durchführen? Am besten gar nicht! Außer du erzählst uns, was du genau vorhast. ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Forum statt Mailingliste
Am 16.10.2013, 07:06 Uhr, schrieb Michael Maier : Nein! Nein! Nein! Ich kann nur von mir persönlich sprechen, aber für mich war die "Mailingliste" sehr lange der Grund mich nicht stärker in OSM zu engagieren. Anstatt mich öfter mich mit Anderen auszutauschen habe ich einfach lange mein eigenes Süppchen gekocht bzw. nur über persönliche OSM-Nachrichten Ideen ausgetauscht. Ich finde, dass Mailinglisten im Allgemeinen nicht unbedingt der Kommunikation förderlich sind, für ein so heterogenes Projekt wie OSM. Hier ein paar Gründe, wieso ich das denke: (1) Mailinglisten haben ein antiquiertes Image und sind viel zu kompliziert zu bedienen. (2) Man wird mit Nachrichten zwangsbeglückt (nichteinmal ein opt-out aus Threads ist möglich). (3) Man kann praktisch nicht auf vergangene Nachrichten antworten, die vor der eigenen Anmeldung an die Liste erstellt worden. (4) Nachrichten können nicht korrigiert oder ergänzt werden. Punkt (1) führt dazu, dass nur technisch versierte Benutzer sich überhaupt anmelden. Punkt (2) führt dazu, dass man sich auch als technisch Versierter eher nicht anmeldet, wenn einem nur gewisse Themen einer Liste interessieren würden. Außerdem ist nicht Jeder zu 100% in OSM involviert und möchte Jeder Diskussion folgen. Wenn man als Neuling nur eine kurze Frage hat, aber nach der Anmeldung täglich dutzende Mails eintrudeln fühlt man sich schnell vollgespamt. Punkt (3) ist einfach nur lästig und führt dazu, dass Threads regelmäßig zersplitten. Punkt (4) führt dazu, dass man sich jedes Posting mehrmals überdenkt. Wenn man keine Möglichkeit hat, nachträglich Fehler auszubessern, oder seinen Standpunkt inhaltlich zu ergänzen, überlegt man sich 3 mal ob man überhaupt etwas posten möchte. So geht es mir gerade bei diesem Posting. Damit finde ich, dass damit eine Mailingliste alles andere als eine freundliche Umgebung für "allgemeine Diskussionen" für eine heterogene Gruppe von Leuten ist. (Eine Mailingliste mag ja vielleicht das Richtige für die Linux-Kernel-Entwickler sein (technisch versierte Leute, im allgemeinen alles Leute die sehr stark engagiert sind und man möchte bewusst nicht freundlich für Neulinge sein um das Niveau der Diskussionen hoch zu halten). Aber eben nicht für OSM "talk".) Dies wird unterstützt durch die Erfahrungen, die ich bisher im OSM-Forum gemacht habe. Außerdem habe ich schon von mehreren Leuten gehört, dass sich diese bewusst nicht an Diskussionen beteiligen mochten, weil diese in einer Mailingliste stattfinden… Patentlösung für dieses Problem habe ich natürlich keine. (Sicher hat die Mailingliste auch ihre Vorteile und Foren ihre Nachteile.) OSM ist aber wohl groß genug, mehrere Diskussionsplattformen parallel zu haben. Eine Möglichkeit wäre dann z.B. das "Germany"-Forum in "Germany-Austria-Swizzerland" umzubenennen. Ich finde aber, dass es am wichtigsten ist zu verstehen und zu akzeptieren, dass in den Mailinglisten hauptsächlich nur "Hardliner" aktiv sind, und dadurch Diskussionsergebnisse nicht mehr unbedingt repräsentativ sind. (Gerade deswegen bin ich der Meinung, dass Abstimmungen, Umfragen, o.Ä. wenn immer möglich vermieden werden sollen. Denn wir paar Hansln auf der Mailingliste können nie und nimmer für alle Mapper entscheiden. Was wir aber machen können ist diskutieren und aufgrund von objektiven rationalen Begründungen einen Konsens finden.) Mit liebsten Grüßen Martin, der noch ein letztes mal überlegt, diese Mail trotzdem nicht abzusenden. PS: Ist euch bewusst, dass das Diskussions-Volumen in den OSM-Mailinglisten seit einigen Jahren rückläufig ist, obwohl OSM klarerweise immer noch wächst? Woran das wohl liegen wird? ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Willkommens-Nachricht
Am 16.10.2013, 10:54 Uhr, schrieb Andreas Labres : Was ev. auch sinnvoll wäre: einen für ganz Österreich gültige Willkommens-Nachricht jedem schicken, der neu etwas macht. Müßte nur sehr kurz sein, daher wohl zweistufig, also mit einem Link auf eine Willkommen-Seite, wo dann weitere Infos stehen. Die Italiener schicken seit Anfang 2013 Neu-Usern die folgende Willkommens-Nachricht: https://wiki.openstreetmap.org/wiki/User:Sarchittuorg/Benvenuto Wenn ich das richtig in Erinnerung habe, läuft das Ganze automatisch per Bot ab. Der folgende Account versendet jedenfalls die Nachrichten: http://www.openstreetmap.org/user/OSM%20Italia Falls man das auch in Österreich einführen möchte, würde es sich anbieten sich mit Stefano (http://www.openstreetmap.org/user/sabas88) kurzzuschließen. Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Abstimmung?: Wie man Begegnungszonen in Österreicht taggt
Ich kann mich deiner Analyse und Beurteilung nur anschließen! Allerdings finde ich nicht, dass eine "Abstimmung" zu diesem Zeitpunkt unbedingt notwendig ist. Denn ich hatte nicht den Eindruck, dass sich die Diskussion bereits derart verfahren hat, dass ein Konsens nicht mehr möglich wäre. Ganz liebe Grüße Martin Am 10.10.2013, 20:09 Uhr, schrieb Markus Straub : Hallo, ich würde gerne eine Abstimmung starten, wie wir in Österreich Begegnungszonen taggen - ausgehend von der Diskussion letzte Woche. Bitte lest meine Ausführungen im P.S.-Teil nochmals. Wenn wir uns einigen können würd ich es ins Wiki eintragen, sodass sich 1) alle Mapper und 2) alle die die Daten verwenden wollen auskennen und wir *eine* Tagging-Variante haben. Die Varianten: (1) highway=pedestrian + maxspeed + access (2) highway=living_street + maxspeed (3) highway=residential + maxspeed + 'shared_space' LG, Markus P.S.: Anbei noch meine längliche Begründung, warum imho Variante (2) die beste ist. Ich plädiere für (2), weil - wir in Österreich kurioserweise zwei Varianten von dem, was international Woonerf (NL), Wohnstraße (DE) und Begegnungszone (CH) genannt wird, haben. Und in OSM bis dato highway=living_street genau das meint. Jedes Land mit seinen eigenen Regeln, und bei uns jetzt in zwei Ausformungen. - pedestrian imho zu "stark" ist, weil es alles außer Fußverkehr standardmäßig ausschließt - residential imho zu "schwach" und eine Begegnungszone mit Tempo 30 nicht von einer normalen Straße mit Tempo 30 unterschieden werden kann, weil es (noch) keinen offiziellen Tag wie shared_space=yes gibt. Variante (2) ist kompatibel mit den "alten" Wohnstraßen, und durch einfaches setzen von maxspeed bei neuen Begegnungszonen kann man sie für die Auswertung (z.B. Routing) klar unterscheiden. Im Standardrendering ist zusätzlich auch klar, dass eine Begegnungszone verkehrsberuhigt ist. Im Detail noch kurz erklärt, wie man Variante (2) auswerten für z.B. einen Router auswerten kann: Wohnstraße (AT) === highway=living_street (oneway=yes) --> wird als Wohnstraße erkannt durch fehlende maxspeed oder maxspeed=AT:walk/5/7 --> muss (z.B. fürs Routen) ergänzt werden zu highway=living_street maxspeed=AT:walk (bzw mit einem echten Wert wie 5,7,...) motor_vehicle=destination (oneway=yes) (oneway:bicycle=no) Begegnungszone (AT) === highway=living_street maxspeed=20 (oneway=yes) --> wird als Begegnungszone erkannt durch maxspeed=20/30 --> muss (z.B. fürs Routen) nicht ergänzt werden highway=living_street maxspeed=20 optional: oneway=yes Anbei noch ein paar Links zur Wohnstraße [1], dem Nebeneinanderfahren von Radfahrern [2], Regeln für Radfahrer auf verschiedenen Straßentypen [3] und der Begegnungszone [4]. Shared Space ist eine andere Diskussion, leider gibt es soweit ich weiß noch kein Proposal diesbezüglich. [1] http://www.jusline.at/76b_Wohnstra%C3%9Fe_StVO.html [2] http://www.jusline.at/index.php?cpid=ba688068a8c8a95352ed951ddb88783e&lawid=24&paid=68 [3] https://www.help.gv.at/Portal.Node/hlpd/public/content/194/Seite.1940026.html [4] http://www.kfv.at/verkehr-mobilitaet/begegnungszone/ ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Geoimage.at aktuellere Luftbilder
Als Nachtrag noch schnell ein "Beweisbild": http://tinyurl.com/nkl2p58 ;) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Geoimage.at aktuellere Luftbilder
Am 15.07.2013, 12:59 Uhr, schrieb martin ringer : Wer es noch nicht gemerkt hat, geoimage.at hat bei den Luftbilder gegenüber bing nachgezogen. Jetzt scheint es aber wirklich so weit zu sein! Zumindest in Graz gibt es Neues von geoimage.at. :) Die Bilder sind wahrscheinlich Anfang/Mitte September 2012 aufgenommen worden, soweit ich das eingrenzen konnte. Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Adressen, die nicht auf Straßennamen basieren
2013/7/4 Friedrich Volkmann : > On 04.07.2013 10:28, Andreas Labres wrote: >> Adressen, die nicht auf einen Straßennamen bezug nehmen, sondern auf eine >> Örtlichkeit, müssen mit addr:place gemappt werden. > > Sorry, aber das ist ein Unsinn und ich frage mich, wo du diese Meinung her > hast. Ich muss hier Andreas recht geben: addr:place wurde genau für diese Fälle eingeführt. Diese Ansicht wird unter Anderem von den Entwicklern von Nominatim unterstützt (siehe z.B. den Vortrag von Sarah Hoffmann auf der diesjährigen FOSSGIS [1], ca. min. 12). Das Problem, wieso dieser Fall mit den originalen addr:* Tags abgedeckt werden konnte, und deshalb ein neues Tag eingeführt werden musste ist meiner Ansicht nach folgendes: Ein geocoder wie Nominatim kann nicht Unterscheiden, ob ein addr:hamlet anstatt eines Straßennamens oder zusätzlich zu einem solchen verwendet wird. Da Adressen mit Straßennamen viel häufiger vorkommen wird deshalb angenommen, dass diese Information fehlt, und deshalb z.B. auf den Namen der nächstgelegenen Straße zurückgegriffen. Was fehlte war ein Tag, das angibt, dass bei einer eben _kein_ Straßenname vorliegt. Genau das wird durch das addr:place-Tag gelöst, auch so getaggt und auch so von Nominatim ausgewertet. > Dann hast du noch nicht viel geschaut und vor allem die Diskussionen in > dieser Mailingliste nicht aufmerksam verfolgt. z.B. Message-ID: > <4efa1534.2030...@volki.at> > <4f5cc012.5020...@black.co.at> > <4f638b6f.1010...@volki.at> Kannst du diese message-IDs bitte durch Links auf die jeweilige Konversation im Mailinglisten-Archiv [2] ersetzen? Ich kann so jedenfalls nicht nachvollziehen, welche Diskussionen du meinst. Schöne Grüße Martin [1] http://wiki.openstreetmap.org/wiki/FOSSGIS_2013/Videomitschnitt [2] http://lists.openstreetmap.org/pipermail/talk-at/ ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging: Autostraßen, Grenzübergänge
Am 02.07.2013, 18:52 Uhr, schrieb Norbert Wenzel : Ich war nur dafür die Mautpflicht als eigenes Tag zu führen. Das impliziert keine Aussage ob primaries die Autostraßen sind als trunk geführt werden sollen oder nicht. Stimmt, da habe ich dich leicht missverstanden. Aber du sagst doch selbst. Die *zwei* Werte korrelieren. Das heißt nicht automatisch, dass wir dies Korrelation implizit in unseren Daten abbilden müssen per irgendeiner Definition hier oder im Wiki. Was spricht dagegen diese Dinger explizit zu taggen? Macht allen Datennutzern das Leben leichter und ermöglicht es die kurzen Ausnahmen zu taggen, wo keine Vignettenpflicht gilt. Das war alles was ich mit meiner vorigen Mail ausdrücken wollt. Das stimmt auch wieder. Ich habe auch nichts gegen ein gesundes Maß an Redundanz in unseren Daten, im Gegenteil. Das Problem an Faustformeln im Wiki ist dass dann irgendein funktionaler Analphabet herkommt und meint "aber im Wiki steht man *muss*". Aber wenn du das sehr vorsichtig formulierst, dass es sich um eine Faustregel handelt kann ich damit leben. Natürlich sollte man sich für das Wiki schon eine stichhaltige Formulierung ausdenken. Aber an dem Punkt sind wir noch nicht, oder? ;) Viele Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging: Autostraßen, Grenzübergänge
Am 02.07.2013, 16:52 Uhr, schrieb Norbert Wenzel : Ich denke nicht, dass es sinnvoll ist eine eindeutige Eigenschaft, nämlich die Mautpflicht in Form einer Vignette, mit dem Typ der Straße zu vermengen. Ich würde die Probleme der mautpflichtigen Straßen losgelöst vom Tagging der Straße selbst betrachten wollen. Irgendwie widersprichst du dich hier ein Bisschen selbst: Ob Autostraße oder nicht ist ja auch nur eine weitere "eindeutige" "Eigenschaft" des Wegs. Aber an irgendwelchen Eigenschaften muss man das die Klassifikation ja festmachen. Ich glaube wir sollten kurz etwas ausholen: OpenStreetMap verwendet ja ein recht "flexibles" Straßen-Klassifikationsschema: Das Attribut highway ist das Haupt-Attribut für Straßen und Wege aller Art. Es ist recht allgemein und bestimmt in etwa die Verkehrsbedeutung des jeweiligen Verkehrsweges. Ich finde, dass die Eigenschaft "Autostraße" eher nicht so gut für so eine Klassifikation geeignet ist. Denn auf Bundesstraßen wechseln sich oft kurze Autostraßen-Abschnitte mit oft noch kürzeren nicht-Autostraßen-Abschnitten ab. Obwohl sich die "Verkehrsbedeutung" der Straße nicht ändert (nur die Benutzungs-Bedingungen ändern sich). Außerdem könnten bei so einem Klassifikations-Flickwerk bei der Auswertung der Daten leicht Probleme entstehen (z.B. Renderer: unschöne Artefakte in niedrigen Zoom-Leveln - Router: Zusätzliche unnötige Ansagen/Instruktionen, aufgrund des Wechsels des Highway-Typs, etc.). Die Vignettenpflicht _wäre_ in dieser Hinsicht ein besseres Kriterium, weil sie direkt mit dem Autobahn-/Schnellstraßen-Netz Österreichs korreliert, und dieses auch gut die Verkehrsbedeutung widerspiegelt. Außerdem ist dieses Netz zusammenhängend, es ergeben sich damit auch keine Inseln und die damit verbundenen oben erwähnten Probleme. Ich habe im letzten Absatz bewusst den Konjunktiv verwendet, weil ich konkret die Vignettenpflicht auch nicht als definierende Eigenschaft ansehe, sondern: ob der jeweilige Weg Teil des Autobahn-/Schnellstraßen-Netzes ist oder nicht. (Es soll ja einen kurzen Autobahnabschnitt irgendwo in AT geben, auf dem ausnahmsweise keine Vignettenpflicht gilt). Der Punkt der Vignettenpflicht ist mehr nur als Faustformel zu verstehen. Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Tagging: Autostraßen, Grenzübergänge
Autostraßen Ja, stimmt, der Fall "Bundesstraße im Rang einer Autostraße" scheint im Wiki nicht wirklich bedacht worden zu sein. Jedenfalls wird dafür neben highway=trunk auch das Tag motorroad=yes (http://wiki.openstreetmap.org/wiki/Motorroad) in der Praxis verwendet. highway=trunk wird aber auch für manche Schnellstraßen verwendet. Siehe: http://overpass-turbo.eu/s/rs (rot=primary+motorroad, grün=trunk auf S-Straße, blau=trunk auf B-Straße). Ganz so befriedigend ist die aktuelle Situation also nicht. :/ Ich würde folgendes "System" vorschlagen: Wenn Vignenttenpflichtig (also Autobahn oder Schnellstraße): motorway oder trunk je nach Ausbauzustand, ansonsten primary/secondary/etc. je nach "Wichtigkeit/Kategorie" (B/L/... Straße) und im Falle einer Autostraße diese mit motorroad=yes kennzeichnen. Das wäre also im Prinzip das aktuelle Tagging, außer dass "B-Straßen im Rang einer Autostraße" einheitlich nur mit motorroad=yes getaggt würden. Eine meiner Meinung nach weniger gute Alternative dazu wäre es auch weiterhin alle Autostraßen als trunk taggen, dann bräuchte man aber ein Tag um die Vignettenpflicht zu kennzeichnen (toll=vignette?). (außer Teil der B70 zwischen Gaisfeld und Krems - für mich der typische Kanditat für trunk!) Äh, soweit ich mich erinnern kann ist die B70 in genau dem Abschnitt (zwar 2x2-spurig) aber keine Autostraße, sondern erst bei der Umfahrung von Voitsberg (dort nur 2-spurig), oder täusche ich mich da? Siehe dazu auch folgendes Note: http://www.openstreetmap.org/?note=8722 Viele Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Grenzen
Wir haben doch schon genug name-Keys, z.B. official_name und short_name. Da sollte sich doch für jeden Zweck etwas finden lassen. Z.B. name=Bezirk Möding + official_name=Mödling. Dann wird der Name brauchbar gerendert, und der offizielle(?) blanke Name ist ebenfalls verfügbar. Wäre dann aber feines Tagging-für-den-Render ;) Das sehe ich nicht so. Genau für solche Fälle ist das Namen-Tagging-Schema nämlich gedacht. Beispielsweise ist *official_name* gleich "Republik Österreich" oder "Schweizerische Eidgenossenschaft" aber weil im echten Leben niemand das jeweilige Ding so nennt, schreibt man in den *name* einfach "Österreich" bzw. "Schweiz". Wenn der offizielle Name vom Bezirk Mödling einfach nur Mödling ist, aber fast jeder (inklusive Wikipedia) das Ding "Bezirk Mödling" nennt, dann sollte das IMHO auch so in die jeweiligen Tags. Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Alpenverein verwendet OSM
Die neue Seite des Alpenvereins verwendet OSM! http://www.alpenvereinaktiv.com Das kann ich leider nicht bestätigen. :( Zumindest punktuell (Südtirol, Trentino, Graz & Umgebung, Schladminger Tauern) werden definitiv keine OSM Daten verwendet. Anstatt dessen wird ein zwar recht nett aussehendes, aber qualitativ eher mittelmäßiges Kartenmaterial verwendet. :/ Siehe auch das Impressum (http://www.alpenvereinaktiv.com/de/impressum.html): Kartografie [...] © Copyright Geoinformationen Sämtliche kartografische Daten setzen sich zusammen aus der Kartografie der Alpstein Tourismus GmbH & Co. KG, Immenstadt, den topografischen Karten von www.outdooractive.com sowiefür Deutschland: zusätzlich aus den Daten des Bundesamtes für Kartographie und Geodäsie (www.bkg.bund.de) für Österreich: zusätzlich aus den Daten von © 1996-2012 NAVTEQ. All rights reserved, und für Italien: zusätzlich aus den Daten von © 1994-2012 NAVTEQ. All rights reserved.und © Autonomen Provinz Bozen – Südtirol. All rights reserved. und für die Schweiz: zusätzlich aus den Daten von © 1994-2012 NAVTEQ. All rights reserved. Hiernach dürfte OpenStreetMap überhaupt keine Verwendung finden. Weshalb OSM auf der Karte erwähnt wird ist mir deshalb schleierhaft. Grüße Martin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Waldflächen Steiermark
Am 18.04.2013, 11:45 Uhr, schrieb Michael Maier : Wenn sich keine Konflikte ergeben, hoch damit! Erledigt: http://www.openstreetmap.org/browse/changeset/15771487 ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Waldflächen Steiermark
Mein Sorgen-Polygon[1] umfasst ca. 1/4 der Gesamtfläche der Steiermark. JOSM hat 6 Minuten (!) gebraucht um alles downzuloaden (Und nein, am Internet oder Rechner liegts nicht) - klar gehts, hab gestern dran rumgeschnibbelt. Aber ich finde das nicht mehr Handle-bar, schon garnicht für Otto Normaluser. [1] http://www.openstreetmap.org/browse/relation/276576 229 Members, 58994 Nodes (!) Ich finde auch, dass das mindestens hart an der Grenze des Handhabbarem ist. Im Moment sind es sogar schon 262 Members und 64346 Nodes. Und das ohne die Unmengen an fehlenden Inner-Flächen! Wer sich einen Überblick verschaffen will: [1] http://overpass-turbo.eu/s/1C Wenn teilen, dann nur an tatsächlichen Trennlinien wie Bundesstraßen oder so, die tatsächlich eine Schneise bilden (und eben nicht mitten durch den Wald gehen, solche Bundesstraßen gibt's vereinzelt auch). Das ist auf jeden Fall immer eine gute Option. Gut anbieten würden sich ebenfalls Flussläufe, Bäche, Gebirgsgräte und Ähnliches. Zum Anfang würde ich das Multipolygon an der Stelle, die unter [1] verlinkt ist auftrennen, dort ist der Wald eh natürlich durch das Flussbett [2] getrennt. Diese Auftrennung hätte ich schon vorbereitet, wäre nur noch hochzuladen... [2] http://binged.it/12oZqgP Grüße Martin / tyr_asd ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Definition von highway=track - Was: Re: Tagging: Straßen auf der Donauinsel
Am 11.04.2013, 09:18 Uhr, schrieb Norbert Wenzel : Es ist zwar nicht agricultural use, wie einige tapfere Wikiritter versuchen es einzutragen, aber es ist wohl vergleichbar mit einem Feldweg für einen Bauern nur hier eben als Feldweg für die Wasserbauleute. +1, meiner Meinung nach ist die Definition von highway=track im Wiki sehr ungeschickt, denn es gibt eigentlich recht häufig tracks (Feldwege, Waldwege, u.Ä.) die nicht "hauptsächlich für land- oder forstwirtschaftliche" Zwecke errichtet und benutzt werden: * Bergbau - http://osm.org/go/0I3Dwnx8 * Wasserbau * Militär * Erschließungswege zur Instandhaltung von Freileitungen, Pipelines, etc. * Erschließungswege zur Instandhaltung von (Wasser-, Wind-, ...) Kraftwerken * Zufahrten zu (abgelegenen) Sendeanlagen * Tourismus * ...? Ich möchte zumindest diese Fälle auch im Wiki erwähnen - allerdings wäre wahrscheinlich eine allgemeinere Definition wünschenswert... Grüße Martin / tyr_asd ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] map für turn restrictions QA
http://map.comlu.com/ Weiteres gibt es im Forum: http://forum.openstreetmap.org/viewtopic.php?id=19834 Am 03.02.2013, 00:22 Uhr, schrieb Peter Kössler : Am 02.02.2013 01:15, schrieb Stefan Tauner: gerade in #osm vorbegehuscht: http://mapcomlu.com/ eine karte, die (schadhafte) turn restrictions sehr hübsch visualisiert. Der Link ergibt nur Seitenfehler - Server nicht gefunden!? Peter. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] "Open Gis Data" in Südtirol + Neue Mailingliste talk-it-southtyrol
Hallo, es gibt ein paar Neuigkeiten von südlich des Brenners, die evtl. auch hier interessieren könnten. Und zwar läuft zur Zeit ein Projekt der Provinz Bozen namens "Open Gis Data" [1], [2]. Ziel des Projektes ist es, die GIS-Daten, über welche die Autonome Provinz Bozen verfügt, als Open Data zu veröffentlichen. Im Prinzip geht es dabei die Daten, die die Provinz [3] zur Zeit nur unter einer speziellen Lizenz [4] zur Verfügung stellt. (Aufgrund eines neuen Gesetzes der Regierung Monti müssen solche Daten in Zukunft aber "dem Bürger" offen zugänglich sein). Gerüchteweise ist geplant, "fast alles" als CC0 zu veröffentlichen. Außerdem gibt es seit Kurzem eine neue Mailingliste: talk-it-southtyrol [0], mit der wir versuchen, die bis jetzt wenig organisierte Community etwas zu strukturieren und stärker aufzubauen. Natürlich ist jeder herzlich dazu eingeladen, dort mitzudiskutieren oder sich einfach nur anzumelden, um auf dem Laufenden gehalten zu werden. Liebe Grüße Martin / tyr_asd [1] http://www.tis.bz.it/info/projekte/projekt-sheets/open-gis-data?set_language=de [2] https://opengisdata.eu/ [3] http://www.provinz.bz.it/informatik/themen/landeskartografie.asp (siehe z.B. den GeoBrowser) [4] http://www.provinz.bz.it/informatik/download/Lizenz_Licenza.pdf [0] http://lists.openstreetmap.org/listinfo/talk-it-southtyrol ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Bawag PSK
Am 13.12.2012, 11:20 Uhr, schrieb Norbert Wenzel: Das Problem dabei hab ich ja schon früher geschrieben: wir haben leider keinen direkten Zugang auf die Datenbank. Wir dürfen nur Strings reinwerfen und dabei ist es uns nicht erlaubt zu einem Key mehrere Values zu speichern. Daher geb ich dir Recht, dass die Strichpunktnotation eine Krücke ist, aber eben die einzig erlaubte. Eine zweite Methode hast du ja selbst schon erwähnt: Zwei amenity nodes (nebeneinander um das weitere Editieren nicht unnötig zu verkomplizieren; die Filiale hat ja eine physikalische Ausdenhung, deswegen hat man ja etwas Spielraum beim Platzieren der POIs), die über eine Relation verbunden sind. Wenn du dir OSM Daten lädst und in deine eigene, optimierte Datenbank fütterst, dann musst du halt mehrere Values zum selben Key erlauben und kannst dann dort indizieren, wie du es für dein Service brauchst. Schon klar: Das was du beschreibst, meine ich gerade mit "sehr schwierig". Vor allem im Vergleich zu bereits etablierten Methoden, sich OSM-Daten zu verarbeiten (Overpass-API, XAPI). Klar kann man darüber diskutieren, multiple Werte bei tag-values in der OSM-API zuzulassen. Oder ob man etablierten Tools dahin erweitern sollte, die Strichpunkt-Syntax performant zu unterstützen. Das ist aber eine technische-Diskussion, die besser z.B. in der dev Liste aufgehoben wäre. Tatsache ist, dass beides noch nicht der Fall ist. Bei dem Thread hier ging es aber darum, ein Problem im aktuell bestehenden OSM-Universum bestmöglich zu lösen. Grüße tyr_asd ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Bawag PSK
Am 13.12.2012, 10:37 Uhr, schrieb Norbert Wenzel : [...] aber wenn ich mit den Daten selbst arbeiten will, dann wird's mit getrennten Nodes deutlich schwieriger. Das kann man nicht so verallgemeinern. Es kommt ganz auf die Anwendung darauf an. Wenn man wissen will, wo sich Bank+Post Kombifilialen befinden, ist die Strichpunkt-Notation auf dem ersten Blick vielleicht(!) komfortabler, allerdings ist sie bei dem viel wahrscheinlicheren Anwendungsfall: "Liste aller Postfilialen in X" mit Abstand deutlich unterlegen. Und zwar (wie bereits gepostet wurde) wegen der sehr schwierigen Indizierung der Datenbank nach solchen multiplen POIs. Ich finde schon, dass die Strichpunkt-Notation ihre Daseinsberechtigung hat (z.B. bei Tags wie ref, source, ...), allerdings nicht bei klassifizierenden Tags (wie highway, amenity, natural, landuse, usw.)! Grüße tyr_asd ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
